Paketkollisionen auf altem 10mbit Hub mit AUI
Guten Morgen und vorweg ja wir haben sowas noch im Einsatz.
Folgende Situation, wir haben hier noch son Asbach Yellowcable H1 Bus am Start.
(Über Vampir Klemmen mit Repeatern verbunden)
Dies wird endlich auch modernisiert. Aber um für Ausfallsicherheit zu sorgen bis es soweit ist,
will ich die Knotenpunkte redundant vor liegen haben.
Der Haupt Repeater an dem 2 der 3 ComServer laufen. Wird über ein 15Pol AUI Kabel
an einen 10MBit Hub angeschlossen. Der dann an einen Auto Sensing fähigen 10/100Mbit
Switch angeschlossen wird/wurde. Was ja bedeutet das er sich die Geschwindigkeit und den
Modus ob halb oder Vollduplex automatisch auswählt.
Welcher die Verbindung mit dem Hausnetz herstellt. Soweit so gut es läuft!
Wir haben allerdings Paket Kollisionen auf den Repeatern. Gleichzeitig ist der H1 Bus mit dem
Leitstand und den dortigen Steuerungs PCs verbunden.
Die Haustechnik liegt mir deswegen nun in den Ohren, das ihre Hochregal Steuerung die
daran angebunden ist Zeitverzögerungen besitzt - die sie sich nicht erklären können.
Ob es je anders war wage ich zu bezweifeln. Aber sie haben halt Störungen auf der Leitung.
Und schieben das auf das Netzwerk.
In einem Test um die Technik dahinter etwas besser zu verstehen habe ich mir hier mit einem
Allied TeleSyn AT-MR820TR Hub ein Testszenario aufgebaut um zu testen, wie das Verhalten
in ähnlicher Steckweise wie im Hochregal Lager zu Stande kommen kann. Das Ergebnis war,
ohne große Last läuft das ganze reibungslos! Kopiere ich aber Daten über den Hub - rauscht
die Lastanzeige auf Vollauslastung & ich erhalte massive Kollisionen auf der LED.
Dies änderte sich nicht egal ob ich einen anderen Switch eingebunden habe an dem ich die
Ports einstellen konnte (Netgear JGS524E-200EUS) oder über direkt Anbindung zweier Notebooks
auf ebenfalls verschiedener Geschwindigkeit mit 10/100 Mbit halb und Vollduplex / Autosensing.
Sobald ein Copy Job gestartet wurde, war der Hub so ausgelastet das er nonstop Kollisionen aufzeigte.
Ich habe mit so alter Technik wenig am Hut gehabt bisher. Habe aber nun die Vermutung das es sich
bei den paar Kollisionen auf dem H1 Bus (der HUB dort ist ein anderer) um normale Technologie bedingte
Kollisionen handelt die eben auftreten wenn der Datenstrom eine gewisse Auslastung überschreitet.
Die Kollisionen wären eben die einfachste Erklärung gewesen, das die Steuerung lahmt. Bis zb. eine
Gassen Freigabe weiter gegeben und zurück gemeldet wurde (dauert manchmal bis zu 5 Sekunden).
Wenn ich das nämlich richtig sehe ist das CSMA/CD verfahren so aufgebaut das eben ein Timeout
erzeugt wird. Wenn nun der Bus also zu stark ausgelastet ist (zu viele Zugriffe o.ä) könnte der
Hub also überlastet sein - was dann in das H1 Netz einstreut & eben das Netz lahmlegt.
Weil das Kollsionspaket ja auf niederer Ebene als Broadcast auf alle Ports durchstrahlt.
Nur das ist eben bloß eine Vermutung. Kann im Live Betrieb schlecht testen
Falls wer ne Idee hat oder die Theorie bestätigen könnte - wäre ich happy. Darüber kriegt man nämlich
kaum noch Infos außer: "Sowas gibt´s nicht mehr oder wenn dann im Museum..."
War schon tot als ich meine Ausbildung anno 2000 angefangen habe.
Danke im Voraus.
Folgende Situation, wir haben hier noch son Asbach Yellowcable H1 Bus am Start.
(Über Vampir Klemmen mit Repeatern verbunden)
Dies wird endlich auch modernisiert. Aber um für Ausfallsicherheit zu sorgen bis es soweit ist,
will ich die Knotenpunkte redundant vor liegen haben.
Der Haupt Repeater an dem 2 der 3 ComServer laufen. Wird über ein 15Pol AUI Kabel
an einen 10MBit Hub angeschlossen. Der dann an einen Auto Sensing fähigen 10/100Mbit
Switch angeschlossen wird/wurde. Was ja bedeutet das er sich die Geschwindigkeit und den
Modus ob halb oder Vollduplex automatisch auswählt.
Welcher die Verbindung mit dem Hausnetz herstellt. Soweit so gut es läuft!
Wir haben allerdings Paket Kollisionen auf den Repeatern. Gleichzeitig ist der H1 Bus mit dem
Leitstand und den dortigen Steuerungs PCs verbunden.
Die Haustechnik liegt mir deswegen nun in den Ohren, das ihre Hochregal Steuerung die
daran angebunden ist Zeitverzögerungen besitzt - die sie sich nicht erklären können.
Ob es je anders war wage ich zu bezweifeln. Aber sie haben halt Störungen auf der Leitung.
Und schieben das auf das Netzwerk.
In einem Test um die Technik dahinter etwas besser zu verstehen habe ich mir hier mit einem
Allied TeleSyn AT-MR820TR Hub ein Testszenario aufgebaut um zu testen, wie das Verhalten
in ähnlicher Steckweise wie im Hochregal Lager zu Stande kommen kann. Das Ergebnis war,
ohne große Last läuft das ganze reibungslos! Kopiere ich aber Daten über den Hub - rauscht
die Lastanzeige auf Vollauslastung & ich erhalte massive Kollisionen auf der LED.
Dies änderte sich nicht egal ob ich einen anderen Switch eingebunden habe an dem ich die
Ports einstellen konnte (Netgear JGS524E-200EUS) oder über direkt Anbindung zweier Notebooks
auf ebenfalls verschiedener Geschwindigkeit mit 10/100 Mbit halb und Vollduplex / Autosensing.
Sobald ein Copy Job gestartet wurde, war der Hub so ausgelastet das er nonstop Kollisionen aufzeigte.
Ich habe mit so alter Technik wenig am Hut gehabt bisher. Habe aber nun die Vermutung das es sich
bei den paar Kollisionen auf dem H1 Bus (der HUB dort ist ein anderer) um normale Technologie bedingte
Kollisionen handelt die eben auftreten wenn der Datenstrom eine gewisse Auslastung überschreitet.
Die Kollisionen wären eben die einfachste Erklärung gewesen, das die Steuerung lahmt. Bis zb. eine
Gassen Freigabe weiter gegeben und zurück gemeldet wurde (dauert manchmal bis zu 5 Sekunden).
Wenn ich das nämlich richtig sehe ist das CSMA/CD verfahren so aufgebaut das eben ein Timeout
erzeugt wird. Wenn nun der Bus also zu stark ausgelastet ist (zu viele Zugriffe o.ä) könnte der
Hub also überlastet sein - was dann in das H1 Netz einstreut & eben das Netz lahmlegt.
Weil das Kollsionspaket ja auf niederer Ebene als Broadcast auf alle Ports durchstrahlt.
Nur das ist eben bloß eine Vermutung. Kann im Live Betrieb schlecht testen
Falls wer ne Idee hat oder die Theorie bestätigen könnte - wäre ich happy. Darüber kriegt man nämlich
kaum noch Infos außer: "Sowas gibt´s nicht mehr oder wenn dann im Museum..."
War schon tot als ich meine Ausbildung anno 2000 angefangen habe.
Danke im Voraus.
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 328567
Url: https://administrator.de/contentid/328567
Ausgedruckt am: 25.11.2024 um 12:11 Uhr
10 Kommentare
Neuester Kommentar
Hi,
schau mal hier, bei einer spontanen Suche gefunden:
yellow cable collision detection
Dort steht jetzt zwar nicht die Welt erklärt, aber es hat doch meine Erinnerung bestätigt:
In den alten Ethernet-Medien (Coax) sind Kollisionen by design im Programm.
E.
schau mal hier, bei einer spontanen Suche gefunden:
yellow cable collision detection
Dort steht jetzt zwar nicht die Welt erklärt, aber es hat doch meine Erinnerung bestätigt:
In den alten Ethernet-Medien (Coax) sind Kollisionen by design im Programm.
E.
Zitat von @TechnoX:
Guten Morgen und vorweg ja wir haben sowas noch im Einsatz.
Der dann an einen Auto Sensing fähigen 10/100Mbit
Switch angeschlossen wird/wurde.
Guten Morgen und vorweg ja wir haben sowas noch im Einsatz.
Der dann an einen Auto Sensing fähigen 10/100Mbit
Switch angeschlossen wird/wurde.
Vorsicht, einen Auto-MDIX-fähigen 100MBit/s Switch gab es zur damaligen Zeit sicher noch nicht
Die Hubs/Switche hatten immer einen dedizierten Uplink-Port, der mechanisch und nicht dynamisch gedreht ist, damit man ein normales Patchkabel zum Verbinden von mehreren Switchen/Hubs nehmen konnte.
Andernfalls muss ein (gutes), altes Crossover-Kabel her, damit man die Geräte miteinander verbinden kann.
Auch sollte man die Auto-Switche auf den Ports fest auf 10MBit/s einstellen, wenn man weiß, dass die Geräte daran nur 10MBit/s können.
Hallo,
ein Paar Infos zur Klarstellung:
Thick Ethernet ist der "Handelsname" für einen Ethernet-Verkabelungs-Standard (10Base5) mit einer Übertragungsgeschwindigkeit von 10 Mbit und einer max. Segmentlänge von 500m. https://de.wikipedia.org/wiki/10BASE5
Siemens Sinec H1 ist ein Feldbus-Protokoll der Firma Siemens zur Vernetzung von (SPS-) Steuerungen. Der "Vorläufer" von Profinet. Dieser Feldbus nutzt als Topologie den Bus mit 10Base5 Thick Ethernet - auch als "Yellow Cable" bekannt (doppelt geschirmtes Coax-Kabel 50 Ohm, Knotenanschluß über AUI-Kabel).
Sinec H1 ist protokolltechnisch nicht gleich ("Büro-") Ethernet!
Kollisionen sind in einem Hub-basierten Ethernet prinzipbedingt. Das ist die Grundlage des Zugriffsverfahrens CSMA/CD ( https://de.wikipedia.org/wiki/Carrier_Sense_Multiple_Access/Collision_De ... ) bei Ethernet. Damit ist Ethernet ein nichtdeterministisches Übertragungsverfahren. Dh., man kann nicht vorherseagen, wann ein Datenpaket übertragen wird. Damit "disqualifiziert" sich das ("Büro"- ) Ethernet für zeitkritische Anwendungen. Um dieses Problem zu lösen, wurden spezielle (Feldbus-)Protokolle auf Basis von Ethernet entwickelt. Eines der ersten war Sinec H1. Heute gibt es unter dem Oberbegriff "Industrial Ethernet" eine ganze Reihe. ZB. ProfiNet, EtherNet/IP, Ethernet Powerlink oder EtherCAT ( https://de.wikipedia.org/wiki/Industrial_Ethernet ).
Prinzipbedingt kann ein Hub-basiertes Ethernet nur zu 20-30% ausgelastet werden (liegt am CSMA/CD-Zugriffsverfahren). Ist die Auslastung größer kommt es zwangsläufig zu Paketverlusten. Die einzige Lösung ist die Verkleinerung der Kollisionsdomänen durch Segmentierung des Netzes.
Jürgen
PS Und natürlich beherrscht 10Base5 keine Autonegotation zur Aushandlung von Übertragungsgeschwindigkeit und kein Auto-MIDI für gekreuzte oder nicht-gekreuzte Ports. Es muß alles fest (von Hand) eingestellt sein.
Und in einem Hub-basiertem Netz gibt es nur eine Übertragungsgeschwindigkeit! Bei einem H1-Bus also 10Mbit. Die Kopplung mit dem "restlichen" Netz muß über einen Switch erfolgen.
PPS: Steuerungs-Kommunikation und Datei-Transfer in einem 10Base5-Netz ohne Switching ist ein "no go"!! --> Paketverluste
ein Paar Infos zur Klarstellung:
Thick Ethernet ist der "Handelsname" für einen Ethernet-Verkabelungs-Standard (10Base5) mit einer Übertragungsgeschwindigkeit von 10 Mbit und einer max. Segmentlänge von 500m. https://de.wikipedia.org/wiki/10BASE5
Siemens Sinec H1 ist ein Feldbus-Protokoll der Firma Siemens zur Vernetzung von (SPS-) Steuerungen. Der "Vorläufer" von Profinet. Dieser Feldbus nutzt als Topologie den Bus mit 10Base5 Thick Ethernet - auch als "Yellow Cable" bekannt (doppelt geschirmtes Coax-Kabel 50 Ohm, Knotenanschluß über AUI-Kabel).
Sinec H1 ist protokolltechnisch nicht gleich ("Büro-") Ethernet!
Kollisionen sind in einem Hub-basierten Ethernet prinzipbedingt. Das ist die Grundlage des Zugriffsverfahrens CSMA/CD ( https://de.wikipedia.org/wiki/Carrier_Sense_Multiple_Access/Collision_De ... ) bei Ethernet. Damit ist Ethernet ein nichtdeterministisches Übertragungsverfahren. Dh., man kann nicht vorherseagen, wann ein Datenpaket übertragen wird. Damit "disqualifiziert" sich das ("Büro"- ) Ethernet für zeitkritische Anwendungen. Um dieses Problem zu lösen, wurden spezielle (Feldbus-)Protokolle auf Basis von Ethernet entwickelt. Eines der ersten war Sinec H1. Heute gibt es unter dem Oberbegriff "Industrial Ethernet" eine ganze Reihe. ZB. ProfiNet, EtherNet/IP, Ethernet Powerlink oder EtherCAT ( https://de.wikipedia.org/wiki/Industrial_Ethernet ).
Prinzipbedingt kann ein Hub-basiertes Ethernet nur zu 20-30% ausgelastet werden (liegt am CSMA/CD-Zugriffsverfahren). Ist die Auslastung größer kommt es zwangsläufig zu Paketverlusten. Die einzige Lösung ist die Verkleinerung der Kollisionsdomänen durch Segmentierung des Netzes.
Jürgen
PS Und natürlich beherrscht 10Base5 keine Autonegotation zur Aushandlung von Übertragungsgeschwindigkeit und kein Auto-MIDI für gekreuzte oder nicht-gekreuzte Ports. Es muß alles fest (von Hand) eingestellt sein.
Und in einem Hub-basiertem Netz gibt es nur eine Übertragungsgeschwindigkeit! Bei einem H1-Bus also 10Mbit. Die Kopplung mit dem "restlichen" Netz muß über einen Switch erfolgen.
PPS: Steuerungs-Kommunikation und Datei-Transfer in einem 10Base5-Netz ohne Switching ist ein "no go"!! --> Paketverluste
Hallo,
das die Technik nicht mehr produktiv eingesetzt werden sollte weißt du ja selber....
Aber schön zu lesen das es noch im Einsatz ist....
Stell den Switch auf 10 MBit/s Halfduplex und schau ob es geht, evtl sogar 10 Full.
Das 15 Polige Kabel ist auf was für einen Stecker terminiert? RJ45 ?
oder D-Sub? und vom HUB auf Netzwerk? Coax oder RJ45?
Wenn durch einen Copy Job im selben NETZ die Last zu hoch steigt solltest und das Netz in VLAN's teilen und den Traffic in dem betreffenden Netz mit QoS priorisieren oder wenn möglich komplett physikalisch trennen....
brammer
das die Technik nicht mehr produktiv eingesetzt werden sollte weißt du ja selber....
Aber schön zu lesen das es noch im Einsatz ist....
Stell den Switch auf 10 MBit/s Halfduplex und schau ob es geht, evtl sogar 10 Full.
Das 15 Polige Kabel ist auf was für einen Stecker terminiert? RJ45 ?
oder D-Sub? und vom HUB auf Netzwerk? Coax oder RJ45?
Wenn durch einen Copy Job im selben NETZ die Last zu hoch steigt solltest und das Netz in VLAN's teilen und den Traffic in dem betreffenden Netz mit QoS priorisieren oder wenn möglich komplett physikalisch trennen....
brammer
Hallo @brammer,
10Base5 arbeitet nur mit Halb-Duplex.
Das Endgerät ist bei 10Base5 immer über ein 15-poliges AUI-Kabel an den Tansceiver (D-Sub) angeschlossen. Der ist - wie @TechnoX richtig beschreibt - über eine "Vampir-Klemme" mit dem Yellow-Cable verbunden.
Um ein 10Base5-Segment mit einem anderen Segment zu verbinden, braucht man immer einen Repeater, der auf der einen Seite einen AUI-Anschluß hat und auf der anderen Seite zB. einen RJ45-Anschluß. Früher hatten die Ethernet-HUBs (laut OSI-Modell Repeater) oft neben den RJ45-Ports auch noch einen BNC- (Thin Ethernet 10Base2 ) und/oder einen AUI-Anschluß als Uplink-Port.
Jürgen
PS. VLANs gibt es bei 10BaseX- Netzen nicht. Dazu braucht man einen Switch und dann hat man auch kein CSMA/CD mehr und auch keine Kollisionen.
Stell den Switch auf 10 MBit/s Halfduplex und schau ob es geht, evtl sogar 10 Full.
10Base5 arbeitet nur mit Halb-Duplex.
Das 15 Polige Kabel ist auf was für einen Stecker terminiert? RJ45 ?
oder D-Sub? und vom HUB auf Netzwerk? Coax oder RJ45?
oder D-Sub? und vom HUB auf Netzwerk? Coax oder RJ45?
Das Endgerät ist bei 10Base5 immer über ein 15-poliges AUI-Kabel an den Tansceiver (D-Sub) angeschlossen. Der ist - wie @TechnoX richtig beschreibt - über eine "Vampir-Klemme" mit dem Yellow-Cable verbunden.
Um ein 10Base5-Segment mit einem anderen Segment zu verbinden, braucht man immer einen Repeater, der auf der einen Seite einen AUI-Anschluß hat und auf der anderen Seite zB. einen RJ45-Anschluß. Früher hatten die Ethernet-HUBs (laut OSI-Modell Repeater) oft neben den RJ45-Ports auch noch einen BNC- (Thin Ethernet 10Base2 ) und/oder einen AUI-Anschluß als Uplink-Port.
Jürgen
PS. VLANs gibt es bei 10BaseX- Netzen nicht. Dazu braucht man einen Switch und dann hat man auch kein CSMA/CD mehr und auch keine Kollisionen.
ja das gute alte Thick Ethernet... danke für die schönen Bildchen
CDMA heißt Collision detect Multiple Access. Man versucht das Medium zu belegen und stellt dabei fest ob eine Kollision vorliegt oder nicht. Also ob ein Multiple Access vorlag.
Wenn eine Kollision vorliegt sollten beide Sender eine zufallsgesteuerte Wartezeit einlegen, und dann erneut senden. Grundlagen des "Alohanet", so auch vorhanden in allen Koax-Netzwerken. Ich meine die höchste effektive Datentransferrate lag da so bei ca. 30% der verfügbaren Bandbreite mit dem Standardalgorihmus - wenn alles in Ordnung war. Das sind 300 KB/Sekunde.
Ich hab in der Coax-Zeit Netze administriert, und es kam leider immer wieder vor, daß ein Transceiver defekt war und ständig Kollisionen verrusacht hat. Sehr zum Leidwesen der anderen Anwender...
CDMA heißt Collision detect Multiple Access. Man versucht das Medium zu belegen und stellt dabei fest ob eine Kollision vorliegt oder nicht. Also ob ein Multiple Access vorlag.
Wenn eine Kollision vorliegt sollten beide Sender eine zufallsgesteuerte Wartezeit einlegen, und dann erneut senden. Grundlagen des "Alohanet", so auch vorhanden in allen Koax-Netzwerken. Ich meine die höchste effektive Datentransferrate lag da so bei ca. 30% der verfügbaren Bandbreite mit dem Standardalgorihmus - wenn alles in Ordnung war. Das sind 300 KB/Sekunde.
Ich hab in der Coax-Zeit Netze administriert, und es kam leider immer wieder vor, daß ein Transceiver defekt war und ständig Kollisionen verrusacht hat. Sehr zum Leidwesen der anderen Anwender...
Hallo @TechnoX,
eine Zeichnung sagt mehr als tausend Worte.
Was aus Deinen "tausend" Worten aber immer noch nicht hervor geht, ist, ob Ihr das Sinec H1-Protokoll zwischen den Steuerungen im Hochregallager nutzt oder ob Ihr "nur" 10Base5 als Ethernet-Verkabelung einsetzt.
Und noch einmal: der Transceiver ist ein Transceiver und kein Repeater. Ein Repeater arbeiter auf Schicht 1 des OSI-Modells und ein HUB ist ein Multiport-Repeater.
Das Bild zeigt den Aufbau einer Ethernet-Schnittstelle im OSI-Modell. Die AUI-Schnittstelle entspricht dem MII.
https://de.wikipedia.org/wiki/Media_Independent_Interface
https://de.wikipedia.org/wiki/Attachment_Unit_Interface
https://de.wikipedia.org/wiki/Medium_Dependent_Interface
Das Ethernet-Segment, auf dem die Steuerungen miteinander kommunizieren sollte als eigenständige Kollisionsdomäne gestaltet werden und keinen anderen Datenverkehr transportieren.Prinzipbedingt kommt es bei 10BaseX-Ethernet immer zu Kollisionen und bei einer Auslastung >= 20-30% zu Paketverlusten. Bei Zeitkritischer Kommunikation muß man den Datenverkehr soweit reduzieren, das es zu keinen bzw sehr wenigen Kollisionen kommt. Wenn die Kollisions-LED permanent leuchtet ist das Segment einfach Überlastet und die Steuerungen können in dem vorgegebenen Zeitfenster keine Informationen austauschen, weil sie keinen Zugriff auf das Medium erhalten (CSMA/CD). Natürlich kann auch eine Komponente (Netzwerkinterface) defekt sein. Das bekommt man aber durch einfaches Austauschen heraus.
Jürgen
eine Zeichnung sagt mehr als tausend Worte.
Was aus Deinen "tausend" Worten aber immer noch nicht hervor geht, ist, ob Ihr das Sinec H1-Protokoll zwischen den Steuerungen im Hochregallager nutzt oder ob Ihr "nur" 10Base5 als Ethernet-Verkabelung einsetzt.
Und noch einmal: der Transceiver ist ein Transceiver und kein Repeater. Ein Repeater arbeiter auf Schicht 1 des OSI-Modells und ein HUB ist ein Multiport-Repeater.
Das Bild zeigt den Aufbau einer Ethernet-Schnittstelle im OSI-Modell. Die AUI-Schnittstelle entspricht dem MII.
https://de.wikipedia.org/wiki/Media_Independent_Interface
https://de.wikipedia.org/wiki/Attachment_Unit_Interface
https://de.wikipedia.org/wiki/Medium_Dependent_Interface
Das Ethernet-Segment, auf dem die Steuerungen miteinander kommunizieren sollte als eigenständige Kollisionsdomäne gestaltet werden und keinen anderen Datenverkehr transportieren.Prinzipbedingt kommt es bei 10BaseX-Ethernet immer zu Kollisionen und bei einer Auslastung >= 20-30% zu Paketverlusten. Bei Zeitkritischer Kommunikation muß man den Datenverkehr soweit reduzieren, das es zu keinen bzw sehr wenigen Kollisionen kommt. Wenn die Kollisions-LED permanent leuchtet ist das Segment einfach Überlastet und die Steuerungen können in dem vorgegebenen Zeitfenster keine Informationen austauschen, weil sie keinen Zugriff auf das Medium erhalten (CSMA/CD). Natürlich kann auch eine Komponente (Netzwerkinterface) defekt sein. Das bekommt man aber durch einfaches Austauschen heraus.
Jürgen
Zitat von @GrueneSosseMitSpeck:
ja das gute alte Thick Ethernet... danke für die schönen Bildchen
CDMA heißt Collision detect Multiple Access. Man versucht das Medium zu belegen und stellt dabei fest ob eine Kollision vorliegt oder nicht. Also ob ein Multiple Access vorlag.
Yuup, ala "trial and error", frei nach dem Motto, ich sende jetzt einfach mal mein Paket, wenn knallt, probier ich noch mal usw....ja das gute alte Thick Ethernet... danke für die schönen Bildchen
CDMA heißt Collision detect Multiple Access. Man versucht das Medium zu belegen und stellt dabei fest ob eine Kollision vorliegt oder nicht. Also ob ein Multiple Access vorlag.
Aber so war das damalige Design leider.