Computereinsatz im Verkehrswesen der DDR
Computereinsatz im Kraftverkehr war in der DDR eher selten, jedoch gab es auch in diesem Bereich einige interessante Lösungen.
Einsatzbeispiele im Straßenverkehr
Taxameter BOTAX80
(Alias BOTAX 80, BOTAX-80)
Das "Wissenschaftlich-Technische Zentrum Kraftverkehr Dresden" mit seiner Außenstelle in Erfurt entwickelte Mitte der 1980er Jahre
ein computergesteuertes Gerät namens BOTAX80, das - in Taxis eingebaut - die zurückgelegten Kilometer und den Fahrpreis ermittelte.
Taxameter gab es auch schon zuvor, aber nicht mit Computersteuerung.
Erst in den 1980er Jahren wurde die Computertechnik dann so klein und preiswert, dass man sie in das Cockpit von PKWs einbauen konnte.
Das BOTAX80 wurde mechanisch anstelle des Autoradios verbaut.
Die Produktion des BOTAX80 übernahm ab 1985 das Wissenschaftlich-Technische Zentrum der Bahn in Meiningen.
Taxameter Botax80
| Rückseite des Botax80 |
Taxameter Botax80 |
Gefahrene Kilometer und Preis wurden auf Siebensegmentanzeigen (LED) angezeigt, eine gedruckte Rechnung war nicht vorgesehen.
Über den Vorwahldrehschalter (VWDS) konnten die vier Tarifstufen (Stadt Tag/Nacht, Fern Tag/Nacht) gewählt werden,
außerdem gab es Tasten für Preisaufschläge, z.B. für Nachtfahrten oder beim Fahren mit Anhänger.
Der Sicherheitsschlüssel an der Gerätefront betätigte einen Mikrotaster, der die Abrechnungsdaten nach Auslesen zum Schichtschluss zurücksetzte.
Den passenden Schlüssel hatte nur die Einsatzstelle/Dispatcher, wo die Abrechnung gemacht wurde (=autorisierter Zugriff).
Ein eingebautes Relais steuerte die Taxischildbeleuchtung auf dem Dach.
Botax80-Prozessorkarte
| Netzteil und Speicherbatterie des Botax80 |
Im Inneren des Gerätes werkelte ein Mikroprozessor U880,
begleitet von 4 KByte (max. 8 KByte) Festwertspeicher (EPROM), 1 KByte RAM, zwei PIOs U855
und einem CTC U857.
Bei Leiterplatten ab Version 3 konnte eine SIO U856 nachgerüstet werden,
mit Hinblick auf eine künftige maschinelle Auslesung des Gerätes.
Da nur wenige Peripherieschaltkreise verbaut waren, hatte der Entwickler auf den Einsatz von Bustreiber verzichtet.
Erhöhter Aufwand musste hingegen für die Stromversorgung getrieben werden, um elektrische Störungen durch das Starten des Autos zu unterdrücken.
Um die Daten auch bei leerem oder ausgebauten Akku des Autos zu erhalten, war eine Batterie eingebaut.
Diese Batterie entstammte der Produktion von Herzschrittmachern.
Für den BOTAX (genauso wie für den PMM100) wurde Exemplare benutzt,
die die geforderten Toleranzen für einen medizinischen Einsatz nicht erfüllten.
Die Geschwindigkeitsinformation wurde an einem Zwischenstück ermittelt, das zwischen Tachowelle und Tachometer geschraubt wurde
und die Drehbewegungen der Tachowelle über einen rotierendem Magnet an einen Hallsensor (B461G) gab, der sie in elektrische Impulse umwandelte.
Die Wegdrehzahl (Anzahl Tachowellenumdrehungen pro Kilometer) musste für jeden Fahrzeugtyp auf dem Rollenprüfstand individuell ermittelt werden
und wurde in das Gerät programmiert (CMOS-RAM), hier kam auch wieder der autorisierte Zugriff via Sicherheitsschlüssel zum Einsatz.
Botax80-Wegsensor
| Botax80-Wegsensor |
Die Software für den BOTAX wurde auf einem MRES-Computer geschrieben,
wobei auch dessen Fähigkeit der In-Circuit-Emulation (Ersetzung des Prozessors im BOTAX durch ein Adapterkabel zum MRES) genutzt wurde.
Die Rechnerkarte wurde als "Bordmikrorechner" (BMR) bezeichnet und kam außer im BOTAX80 auch im Diagnosegerät UDS80 zum Einsatz,
außerdem versuchsweise in einem Fahrtenschreiber für LKW (BMR-LKW).
Auch vom versuchsweisen Einsatz eines BOTAX auf dem Fährschiff der Strecke Saßnitz-Trelleborg zur Optimierung des Kraftstoffverbrauchs wurde berichtet.
Während der Produktion des BOTAX gab es mehrere Überarbeitungen des Gerätes.
In der Serienproduktion bzw. dem Feldeinsatz stellten sich doch Schwachpunkte heraus, die durch neue Geräterevisionen beseitigt wurden.
Der 15polige EFS-Stecker war eine Forderung des Produzenten für die Prüfung der Baugruppe.
Er wurde erst mit Version 3 der Leiterplatte eingeführt.
Die Berliner Verkehrsbetriebe waren der 1985 Vorreiter im produktiven Einsatz der BOTAXen, ab 1989 war das Gerät dann landesweit flächendeckend in der DDR im Einsatz.
Es existieren heute noch ein paar BOTAX80, erfreulicherweise sogar einige in funktionsfähigem Zustand, aber keins mehr im produktiven Einsatz.
Taxameter BOTAX2000
(Alias BOTAX 2000, BOTAX-2000)
Es gab vom BOTAX80 eine (ebenfalls rechnergesteuerte) Nachfolgeentwicklung namens BOTAX2000,
die leider nicht über das Entwicklungsstadium hinaus kam.
Gegenüber dem BOTAX80 hatte der BOTAX2000 eine vom Grundgerät abgesetzte Bedieneinheit mit LCD-Anzeige und eigenem U8047 Prozessor.
Damit konnte das Grundgerät irgendwo im Auto untergebracht werden und blockierte nicht mehr den Platz des Autoradios.
Die Abrechnungsdaten wurden über ein Betriebsdatenterminal Robotron BDT K8902
zur automatischen Weiterverarbeitung ausgelesen.
Im Rechnermodul war die stromsparende CMOS-Version des Prozessors U880 sowie CMOS-RAM verbaut.
Außerdem fand zur Reduzierung der Anzahl diskreter Bauelemente, zur Wegstreckenzählung und zur Kommunikation mit dem Bedienteil
und den Betriebsdatenterminal ein GateArray U5201/115 Verwendung.
Das BOTAX2000 gilt heute als ausgestorben.
Elektronischer Fahrscheindrucker FABUS 1
(Alias FABUS1, FABUS-1, Fahrschein)
Dieses Gerät stellte die Ablösung der mechanischen Fahrscheindrucker in den Omnibussen des DDR-Kraftverkehrs dar.
Entwickler war das "Wissenschaftlich-Technische Zentrum Kraftverkehr Dresden", Serienproduzent das Verkehrskombinat Gera.
Die ersten Geräte kamen ab 1987 in den probeweisen Einsatz, ein Jahr später begann die Serienproduktion, die dann bis 1990 lief.
Gerät FABUS1
| FABUS1, Ansicht von rechts |
FABUS-Fahrscheinrolle |
Der FABUS wurde aus dem 24V-Bordnetz des Busses gespeist und besaß zur Steuerung einen Mikroprozessor U880.
Die Weginformationen wurden, wie beim Botax, mittels eines Drehsensors vom Tachometer abgenommen.
Die Schnittstelle mit dem Bediener wurde durch die Tastatur sowie eine vierstellige Siebensegmentanzeige gebildet,
die Tasten für erstere entstammten der Produktion der Robotron-Tastatur K7637.
Von einer Rolle im Inneren des Geräts wurde der Fahrscheinstreifen abgespult, mithilfe eines senkrecht gestellten 9-Nadel-Druckkopfes,
der samt seiner Farbbandkassette der Produktion der K631x-Drucker entnommen wurde, bedruckt und anschließend vom Fahrer abgerissen.
Da die Bedruckung des Streifens einzeilig war, konnte auf eine Bewegung des Druckkopfes verzichtet werden.
Das für die Fahrscheine eingenommene Geld wurde im akkugestützten SRAM gespeichert und am Schichtende protokolliert.
Mitte der 1990er Jahre wurden die letzten FABUS außer Dienst genommen.
Es existieren heute noch einige wenige Exemplare, erfreulicherweise zwei sogar funktionsbereit.
Universelles Diagnosesystem UDS80
(Alias UDS 80, UDS-80)
Hierbei handelte es sich um ein kleines computergesteuertes Gerät, das in Fahrzeugen (LKW, Traktoren, Mähdrescher) zum Einsatz kam
und Daten über das Fahrzeug lieferte, beispielsweise die Motorleistung und die Bremswege.
Diese Daten waren für die Reparaturmannschaft interessant.
Ob UDS80 bis heute überlebt haben, ist unbekannt.
Steuerungen für Lichtsignalanlagen
(Alias VSS 5000, VSS-5000, Lichtsignalanlage, Lichtsignalgeber)
Die ersten Verkehrskreuzungen wurden, falls Verkehrsschilder nicht ausreichten, von Polizisten per Handzeichen geregelt.
Später erfand man Verkehrsampeln (Lichtzeichen oder mechanische Zeichen), die manuell von einem Polizisten bedient wurden.
Mit der wachsenden Verbreitung der der Automatisierungstechnik lag es nahe, diese Arbeit an ein eigenständig laufendes Gerät zu delegieren.
Zunächst waren dabei die Signalzeiten und die Schaltreihenfolge fest vorgegeben.
Mit wachsendem Verkehrsaufkommen ergab sich die Notwendigkeit, die Zeiten und Schaltfolgen vom fließenden Verkehr abhängig zu machen,
gleichzeitig das Risiko von Fehlern aber gering zu halten: die Geräte wurden immer komplizierter.
In den 1980er Jahren hielt dann auch in der DDR diesem Themenfeld die Computertechnik Einzug.
Arbeiteten die Ampelkreuzungen zunächst noch voneinander losgelöst, ging der Trend dazu über, mehrere Kreuzungen zu Synchronisieren
und möglichst optimale (Zeit- und Treibstoff-sparende) Verkehrsflüsse zu erzeugen.
Dies bedingte natürlich das Verlegen entsprechender Leitungen von den Ampelkreuzungen zu den Zentralen.
Das Grüne-Welle-System zeigte auf drei speziellen weißen Ampeln oder auf einer Ziffernanzeige Richtgeschwindigkeiten an,
die, wenn man sich an sie hielt, ein Überfahren der kommenden Ampel ohne Anhalten ermöglichten.
Im nächsten Automatisierungsschritt strebte man die Kopplung der einzelnen Steuerungen mit einer Zentrale an.
Auf diesem Weg berichteten die Steuerungen selbständig über aufgetretene Probleme (z.B. durchgebrannte Lampen) und es gab auch zunehmend die Möglichkeit,
die Programme der Steuerungen aus der Ferne in gewissen Grenzen zu beeinflussen, außerdem in der Zentrale einen Überblick über die aktuelle Verkehrslage zu bekommen.
Die Geräte L6000, Z500 und Z50L fasste man unter der Bezeichnung VSS5000 (VSS=Verkehrssteuersystem) zusammen.
Steuergerät ES3
(Alias ES 3, ES-3)
(ES vermutlich für "Elektronische Steuerung")
Diese vom Geräte- und Reglerwerk Leipzig in den 1970er Jahren gebauten Geräte
wurden zur Steuerung von Ampelkreuzungen eingesetzt.
Augenscheinlich konnte sie in der maximalen Ausbaustufe 108 Lampen schalten und
unter Zuhilfenahme eines externen Vorschaltgeräts auch Induktionsschleifen bedienen.
Eine Schaltuhr war ebenfalls eingebaut, was auf eine Uhrzeit-abhängige Beeinflussung der Ampelphasen hinweist.
Ampelsteuerung ES3, ein paar Abdeckungen fehlen.
| Sloteinheit der ES3 |
Typenschild einer ES3 von 1981
| Ankopplungseinheit für Induktionsschleifen |
Die ES3 besaß keinen Computer, sondern war aus TTL-Schaltkreisen aufgebaut.
Die Programmierung der Ampelphasen und -Zeiten erfolgte über Lötbrücken auf speziellen Programmkarten.
Eine Elektronikkarte aus der ES3
| Eine Elektronikkarte aus der ES3 |
Eine Elektronikkarte aus der ES3
| ES3-Programmkarte |
Vor der ES3 hatte es eine Steuerung namens ES2 gegeben.
Nachfolger der ES3 war Mitte der 1980er Jahre die computergesteuerte L6000.
Es ist davon auszugehen, dass ES3 heute nicht mehr im produktiven Einsatz sind.
Augenscheinlich haben zwei Exemplare in Sammlerkreisen überlebt, davon eins funktionsfähig.
Steuergerät L500
(Alias L 500, L-500, LD 50, LD-50, LDM 61, LDM-61)
Dieses vom Geräte- und Reglerwerk Leipzig gebaute Gerät
diente der Optimierung des Verkehrsflusses mit dem Ziel, Fahrzeit und Kraftstoff einzusparen.
Dazu bewirkte es Veränderungen der Ampelphasen (Dauer, Reihenfolge, verkehrsabhängiges Abschalten) sowie bei Bedarf eine schnelle Durchfahrt von Rettungskräften.
Bis zu fünfzehn L500 arbeiteten dazu über DNÜ-Netzwerkverbindung bzw. V.24 zusammen.
Steuergerät L500
| L500, Frontblenden abgenommen |
L500-Bedieneinheit |
Im L500 befanden sich mehrere Steckkarten eines anscheinend von GRW selbst erfundenen Bussystems.
Über Triac-Stufen steuerte das L500 direkt die Lichtsignale (bis zu 96 Ampelköpfe mit Fahrzeug- oder Fußgängerampeln sowie Räumpfeile, 50...100W pro Lampe) an.
Zum Anschluss von vier Verkehrsdetektoren LD50 (extern) und einen vierfachen LDM61 (intern) standen vier Kanäle bereit.
Sechzehn Drucktasten für Fußgängerampeln und sechs steuerbare Sonderlampen (z.B. Grün-kommt-bald-Anzeige für Fußgänger) waren möglich.
Im Zuge der Selbstdiagnose wurden natürlich das Schaltverhalten der Ampelphasen sowie die Funktionsfähigkeit der Lampen überwacht.
Per interner Uhr und internem Kalender konnten Zeit- und Tagesabhängige Schaltphasen definiert werden.
CPU-Karte des L500
| TRIAC-Karte des L500 |
Im Vergleich zum L6000 wirkt die Technik des L500 filigraner und moderner.
Die Art des Prozessors wurde auch gegenüber der L6000 geändert:
in der L500 arbeiteten sechs Einchipmikrorechner, drei weitere in den externen Geräten.
Bislang ist es leider noch nicht gelungen, Einsatzorte von L500 zu ermitteln.
Ob irgendwo ein L500 überlebt hat, ist ebenfalls unbekannt. Vermutlich werden heute keine mehr im produktiven Einsatz sein.
Steuergeräte L4000 (LSA4000) und L4100 (LSA4100)
(Alias L 4000, L-4000, Lichtsignalanlage 4000, LSA4000, LSA 4000, LSA-4000, L 4100, L-4100, LSA4100, LSA 4100, LSA-4100, LSA 4004, LSA-4004, L 5000, L-5000)
Mit Verfügbarwerden des U808-Prozessors und des ZE1-Platinensatzes
machten sich die Hochschule für Verkehrswesen und die Stadtdirektion Straßenwesen Dresden (Abt. Signalanlagen) ans Werk,
eine Mikrorechner-gesteuerte Lichtsignalanlage zu konstruieren.
Gegenüber älteren Ampelsteuerungen (die Stadtdirektion Straßenwesen hatte bereits 10 Jahre zuvor Ampelsteuerungen auf Basis von Transistorlogik, z.B. LSA3, entwickelt)
hatte die neue den Vorteil, dass das Ablaufprogramm nicht mehr durch Lötbrücken eingestellt,
sondern in Form von Software abgelegt war, was Änderungen (z.B. bei längeren Straßenbauarbeiten) durch einfaches Ersetzen des Speichers
(der bereits in der Zentrale vorbereitet wurde) stark erleichterte.
Außerdem konnten in den kleinen Speicherchips platzsparend mehr Funktionen untergebracht werden als bei konventionellen Anlagen zuvor.
Ampelsteuerung L4100 (Rechnereinheit)
| Rückseite der Rechnereinheit der L4100 |
Also die erste L4000 1979 in produktiven Betrieb ging, war sie die älteste Ampelsteuerung mit Rechner in der DDR
und zugleich eins der ersten OEM-Projekte auf Basis ZE1.
Bis zum Jahr 1988 wurden mindestens 22 Exemplare produziert und ausschließlich in Dresden eingesetzt.
Es gab auch eine leicht geänderte Variante L4004.
L4100 war die modernisierte Version der L4000, unterschied sich u.a. in der Geometrie des Bedienteils.
Die hier beschriebenen Informationen gelten sinngemäß für alle Typen.
Bedienteile von L4100 und L4000 im Größenvergleich |
Wie auch die anderen Ampelsteuerungen wurde die L4000 in Kellern oder in speziell dafür gebauten Häuschen oder in Garagen untergebracht.
Automatische Rückmeldungen an eine Zentrale bei Störungen waren mit der L4000/L4100 noch nicht möglich.
Synchronisierung mit Nachbarkreuzungen (Grüne Welle) wurden mittels eines zusätzlichen Geräts, dem Synchronkoordinator, bewerkstelligt.
Für verkehrsabhängige Schaltungen standen für die Fußgänger Drückkontakte, für die Straßenbahnen Leitungskontakte und für Autos Induktionsschleifen zur Verfügung.
Die interne Uhr ermöglichte eine zeitgesteuerte Einschaltung der Ampelanlage oder zeitabhängige Programme.
Die L4000 war in zwei Metallrahmen eingebaut, wobei der eine im oberen Teil die Netzteile und das Bedienfeld enthielt, im unteren Teil den Rechner und Logikkarten.
Im zweiten Rahmen waren die Leistungsbaugruppen in Form von Relais sowie die Lampenstromüberwachungen untergebracht.
An Signalgebern konnten angeschlossen werden:
- maximal 18 KFZ-Ampeln (mit je 3 Lampen)
- maximal 13 Fußgänger-Ampeln (mit je 2 Lampen) und
- maximal 7 Straßenbahnampeln (mit je 4 Lampen)
Vom bei Robotron Riesa produzierten ZE1-Mikrorechnersystem
wurden die beiden Prozessorkarten, zwei ROM-Karten zu je 2 KByte Kapazität und zwei RAM-Karten zu 1 KByte bzw. 0,5 KByte Kapazität übernommen.
Die Peripheriekarten fertigte die Stadtdirektion Straßenwesen Dresden selber,
das war bei ZE1-Systemen auch stets so vorgesehen.
Die erste Peripheriekarten wurden auf Universalplatinen aufgebaut, mit gelöteter Verdrahtung.
Ab 1981 wurden auch spezifische Leiterplatten gefertigt.
Rechnereinschub der L4100 |
Steuerkarteneinschub der L4100
| Steuerkarteneinschub der L4100 für sechs KFZ-Ampeln und sechs Räumpfeile |
Aufbau auf universeller Leiterplatte von 1980
| Aufbau auf spezifischer Leiterplatte von 1981 |
Die Software der L4000 befand sich verteilt auf zwei Leiterplatten mit je acht EPROMs U552.
Später ersetzte man beide Leiterplatten durch eine Karte mit nur noch 1 EPROM U2716, was die Programmierung sehr erleichterte.
Zur Programmierung der U552 diente ein K1510-OEM-Rechner, an dem Bildschirm,
Tastatur, Bedieneinheit,
Lochbandtechnik angeschlossen waren.
Die späteren U2716-EPROMs wurden stattdessen auf einem MC80.21-Computer programmiert.
Schwachstelle der L4000 blieb ihr Verhalten bei Stromausfällen.
Zu Beginn der Entwicklung wurde versucht, das Programm nur im flüchtigen RAM zu halten.
Schnell kam die Erkenntnis, das es besser war, es in EPROMs abzulegen, um ständiges Neu-Eintippen nach Stromausfällen zu vermeiden.
Da die Uhr der L4000 softwareseitig im Rechner lief und der Rechner keine Akkustützung besaß, war ihr Inhalt nach einem Stromausfall weg.
Die L4000 startete daher nach Stromausfällen nicht wieder von allein, sondern musste vorort nach Eingabe der Uhrzeit manuell wieder aktiviert werden.
Auch wenn die L4000 ab 1984 durch die leistungsfähigere L6000 Konkurrenz bekamen, blieben sie weiterhin im Einsatz, noch bis nach dem Jahr 2000.
Dann wurden sie schrittweise durch moderne westliche Steuerungstechnik ersetzt.
Heute sind keine L4000 mehr im produktiven Einsatz.
An einem Nachfolgetyp L5000 wurde Ende der 1980er Jahre in Dresden bereits entwickelt, die ging aber,
bedingt durch das Ende der DDR und die damit plötzlich verfügbare westdeutsche Signaltechnik (Siemens, Signalbau Huber) nicht mehr in Serienfertigung.
Ein nicht mehr funktionsfähiges Exemplar einer L4100 ohne Relaisrahmen hat im Rechenwerk Halle überlebt.
Die L4000 gilt, mit Ausnahme eines Bedieneinschubs, als ausgestorben.
Steuergerät L6000
(Alias L 6000, L-6000, LM 6000, LM-6000)
Das Geräte- und Reglerwerk Leipzig baute (wahrscheinlich ab 1984) die computerbasierte L6000
zur Steuerung großer Ampelkreuzungen als Nachfolger der ES3.
Durch die eingesetzte Software ermöglichte sie komplexe Schaltfolgen bei maximaler Funktionssicherheit
und konnte ohne Änderung der Verdrahtung auf neue Situationen angepasst werden.
Steuergerät L6000
| Steuergerät L6000, einige Frontklappen geöffnet |
Sloteinheit einer L6000
| Typenschild einer L6000 von 1986 |
Die L6000 wurde entweder auf ein Betonfundament unter eine Haube aus Kunststoff in der Nähe der Kreuzungen aufgestellt
oder auf ein Metallgestell in nahegelegenen Gebäuden: letzteres war klimatisch und servicetechnisch günstiger.
Solche Gebäude konnten angemietete Keller sein, Garagen oder speziell für die Ampelsteuerungen gebaute Häuschen.
Ein für die Ampelsteuerung errichtetes Gerätehäuschen
| In dieser Garage "wohnte" auch einst eine L6000 |
Der Rechner als zentraler Bestandteil der Anlage war als Steckkartensystem in DDR-Einschubrahmentechnik ausgeführt,
auf der Prozessorkarte arbeiteten ein Mikroprozessor U880,
eine SIO U8560 und ein CTC U857.
Es wurden zwei RAM-Karten (mit je 2 KByte Größe in 8x U202D) gesteckt, außerdem vier EPROM-Karten mit (mit je 8x 1 KByte Größe).
Weiterhin eine Karte, die die Echtzeituhr für zeitabhängige Ampelschaltungen beinhaltete;
ihre Uhrzeit wurde mit Siebensegmentanzeigen VQE24 angezeigt.
Zeitgesteuert konnte bewirkt werden, dass die Ampeln nachts dunkler leuchteten als am Tag.
Auch eine zeitgesteuerte oder verkehrsgesteuerte Deaktivierung (meist verbunden mit Gelb-Blinken)
oder ein zeitgesteuerter Programmwechsel konnten aktiviert werden.
Außerdem konnte die Beleuchtung von Straßenschildern zeitgesteuert aktiviert werden.
L6000-Prozessorkarte PCP04
| Echtzeituhr LZG01. Grün die Stützakkus. |
8-KByte-ROM-Karte PRO12
| 2-KByte-RAM-Karte PRA01 |
In den Baugruppenebenen unter dem Rechner befanden sich Triac-bestückte Module für die Ansteuerung der Signallampen.
In den Verkehrsampeln waren entweder Haushalt-übliche 220V-Lampen (25...400W) verbaut oder Halogenlampen mit Vorschalttrafo,
wobei ersteres günstiger war, da Ausfälle der Lampen dann sicher detektiert werden konnten.
Zumindest die Lampen für die Rotanzeige wurden elektronisch überwacht: Ausfälle wurden automatisch an die Zentrale gemeldet.
Pro L6000 konnten bis zu 128 Lampenkanäle einzeln gesteuert werden, die projektbezogen auf folgende Lichtsignale verteilt wurden:
- KFZ-Ampeln (mit 3 Lampen)
- Fußgänger-Ampeln (mit 2 Lampen)
- Radfahrer-Ampeln (mit 2 Lampen)
- Räumpfeil (mit 1 Lampe)
- Straßenbahnampeln (mit 4 Lampen)
- Richtgeschwindigkeitsanzeigen (mit 3 oder 26 Lampen)
Bei Verzicht auf die Lampenausfall-Überwachung konnten zwei Lampen pro Lampenkanal geschaltet werden.
Außerdem gab es besondere Triac-Module, die zwei separat überwachte Lampen pro Kanal ermöglichten.
Um die Lebensdauer der Lampen zu verlängern, wurde beim Einschalten die Spannung per Phasenanschnitt allmählich erhöht.
Bei Ausnutzung aller Lampenkanäle konnte der Stromverbrauch der Anlage auf 7 kW anwachsen, was dann einen Drehstromanschluss erforderte.
Bei Bedarf konnte in die L6000 ein Stromzähler eingebaut werden, um die Kosten für den Stromverbrauch gegenzurechnen,
speziell wenn sie in Kellern von Häusern untergebracht war.
Vier Triac-Module
| Schalteinrichtung für Verkehrszeichenbeleuchtung |
Bei Bedarf konnten bis zu 16 in die Straßen eingelassene Induktionsschleifen bedient werden,
um verkehrsabhängige Grünphasenlängen, verkehrsabhängige Schaltfolgen oder verkehrsabhängige Programmauswahl zu realisieren.
Wurden noch mehr Induktionsschleifen gebraucht, wurde deren Vorverarbeitung in externen Schaltkästen untergebracht.
Für Fußgänger und Radfahrer waren Drücktaster an den Ampeln vorgesehen, außerdem automatische Oberleitungskontakte für die Straßenbahnen.
Und es gab Steuerkästen, an denen die Polizei per Schlüsselschalter den Normalverkehr auf rot schalten konnte,
um Sonderfahrzeugkolonnen schnellstmöglich durchzuschleusen.
Externer Induktionsschleifenkasten
| Schaltbox für die Polizei |
Eine serielle Datenübertragung diente der Koordinierung mehrerer Anlagen oder ganzer Straßenzüge ("grüne Welle" mit bis zu sechzehn L6000)
und der Anbindung an einen Verkehrsleit- und Überwachungsrechner Z500 über eine max. Distanz vom 20 km.
Die Software bestand aus dem Steuerprogramm sowie vielen Tabellen mit Konfigurationsdaten, alles in EPROMs abgelegt.
Der Bequemlichkeit wegen wurde die Software meist extern (per MC80 oder später per PC) erstellt,
auf EPROMs gebrannt und dann nur noch vorort in die L6000 gesteckt.
Eine Vorort-Programmentwicklung per LM6000 war aber auch möglich, dazu wurde eine der Steuerkarten in der L6000 durch eine EPROMer-Karte ersetzt,
außerdem die Service-EPROM-Karten mit der entsprechenden Software gesteckt.
Von einer Leitzentrale aus konnte bei Bedarf zwischen verschiedenen Ablaufprogrammen umgeschaltet werden (z.B. bei Straßensperrungen, Staus).
Bei Erkennung technischer Störungen war eine automatische Umschaltung in einen Notlaufmodus (bis hin zur Selbstabschaltung) vorgesehen.
So reagierte die Anlage z.B. auf Kurzschlüsse der Grünleitungen sich kreuzender Straßen mit sofortiger Selbstabschaltung,
ebenso beim Ausfall von Rot-Lampen.
Servicegerät LM6000
| Rückseite des LM6000, geöffnet |
LM6000-Bedienteil |
Die Anlage besaß ein eingebautes Bedien- und Anzeigefeld, das dem Servicepersonal vorbehalten war.
Außerdem konnte bei Benutzung einer zusätzlichen ROM-Karte ein Servicegerät LM6000 angesteckt werden,
mit dem die Anlage im Einzelschrittbetrieb gefahren und Hardwarefehler diagnostiziert werden konnten,
außerdem konnte damit eine Programmierung der EPROMs bewerkstelligt werden.
Für elektrische Messungen an Karten stellte das GRW Verlängerungskarten bereit,
mit denen der Prüfling zugänglich gemacht und die Bussignale abgegriffen werden konnten.
Verlängerungskarte mit Messbuchsen
| Verlängerungskarte |
Die Geräteabwärme wurde über eingebaute Ventilatoren abgeführt.
Für den Betrieb im Winter besaß das Gerät eine interne temperaturgesteuerte Elektroheizung.
War die L6000 in freistehenden Gebäuden untergebracht,
hatte man meist zusätzlich noch einen externen Elektroheizer (Eisenbahnheizer) im Raum verbaut.
Die Lüfterbank mit den beiden Heizstäben |
Als bedarfsweises Zubehör waren vorgesehen:
Die L6000 wurde vor allen in Großstädten eingesetzt, dies ist z.B. für Leipzig, Dresden (hier 64 Stück), Erfurt, Chemnitz, Halle, Magdeburg, Rostock, Stralsund und Zwickau belegt.
Im Laufe der Zeit gab es Weiterentwicklungen an der Technik:
die beiden 2-KByte-RAM-Karten wurden durch eine mit 4 KByte Größe (16x U214D) abgelöst und das 5V-Netzteil wurde überarbeitet.
In den 1990er Jahren kam eine ROM-Karte heraus, die nur noch 1 großen EPROM (i27256 oder i27512) beinhaltete
und die vier bisherigen ROM-Karten ersetzte, außerdem eine RAM-Karte mit nur noch 1 großen RAM-IC darauf.
Teilweise hatte man dazu von den alten ROM- und RAM-Karten die seltenen Busstecker abgelötet, um diese auf den neuen Karten wieder zu verwenden.
Auch vom Einsatz von DCF77-Funkuhrkarten in den 1990ern wurde berichtet.
neue RAM-Karte PRA03
| neue ROM-Karte |
Augenscheinlich sind heute keine L6000 mehr im produktiven Einsatz:
in den 2010er Jahren wurden die letzten außer Betrieb genommen und durch moderne Technik ersetzt.
Das passierte primär, weil die Verfügbarkeit von Ersatzteilen nicht mehr gewährleistet werden konnte,
da der Hersteller ja bereits Anfang der 1990er Jahre in Konkurs ging.
Eine L6000 steht heute als Exponat im Rechenwerk Halle,
eine weitere im Elektromuseum Erfurt, eine dritte bei einem Privatsammler.
Leitzentrale Z50L
(Alias Z 50 L, Z-50-L)
Diese Anlage wurde vom Geräte- und Reglerwerk ab wahrscheinlich 1987 produziert
und diente als Kopfstation zur zentralen Koordinierung vieler Ampelanlagen in großen Städten.
Sie definierte Strategien abhängig von den Verkehrssituationen.
Computer Z50L |
Vermutlich hat keine Z50L bis heute überlebt.
Hat jemand nähere Informationen oder Bilder zur Z50L?
Unterzentrale Z500
(Alias Z 500, Z-500)
Diese Rechner wurden vom Geräte- und Reglerwerk Leipzig ab 1985 gebaut
und im Straßenverkehr als übergeordnete Leitrechner zur Bündelung von bis zu 30 (bei Leistungsreduzierung sogar bis 160) Steuereinheiten L6000 eingesetzt.
Sie wurde aber auch in der Gewächshaus-Automatisierungsanlage GWA5000 benutzt.
Die Z500 war entweder als höchstes Gerät in einer hierarchischen Ampelanlage in Betrieb oder als untergeordnetes Gerät unterhalb einer Leitzentrale Z50L.
Dabei bewirkte die Z500:
- das Grüne-Welle-Fahren
- die Protokollierung der Zustände aller Steuereinheiten L6000
- Entgegennahme der Störungsmeldungen der L6000
- Statistische Erfassung der Auslastung der Straßen
- verkehrsabhängige Anpassung der Ampelanlagen
Computer Z500 |
Der Rechnerkern war aus GRW-spezifischen Leiterplatten aufgebaut,
die mit Robotron-Leiterplatten (K1520) ergänzt wurden.
Dazu gehörten ein Farbgrafikbildschirm K7226,
eine Lochband-Stanzer/Leser-Einheit oder Magnetbandeinheit sowie ein Drucker K6313.
Z500-RAM-Karte |
Die Z500 hat sich als technischer Fehlschlag herausgestellt, der zur vielen Problemen beim Anwender führte:
- Sie neigte dazu, sich programmseitig aufzuhängen und dabei auch die L6000 zu blockieren.
- Es kam im Langzeitbetrieb zu sporadischen Hardwarefehlern (Geräte schalteten sich einfach ab)
- Da die gesammelten Daten nur im RAM gehalten wurden, gingen diese Daten bei obigen Problemen verloren.
- Die Speicherung und Weiterverarbeitung der Daten über Magnetkassetten war unzureichend unterstützt.
- Kaum dass der Z500 im Handel war, wurde seine Entwicklung eingestellt, Fehler wurden nicht mehr behoben.
Das führte dazu, dass die Z500 keine große Verbreitung (nachgewiesen sind immerhin Einsätze in Berlin und Dresden) fand
und die verkauften Geräte sehr schnell wieder außer Betrieb genommen wurden.
Anfang der 1990er Jahre dürften bereits keine mehr im produktiven Einsatz gewesen sein.
Stattdessen wurde auf westliche Geräte (Siemens, Signalbau Huber, UniComp) unter Beibehaltung der L6000 umgestellt.
Vermutlich hat keine Z500 bis heute überlebt.
Automatisierte Tankstelle
In der DDR war es üblich, dass die Betankung (oder zumindest das Ablesen und Rückseiten der Preisanzeige)
vom Tankwart gemacht wurde, der auch gleich das Geld entgegen nahm, das Wechselgeld zurück gab
und auf Wunsch auch eine Quittung ausschrieb.
Bei der klassischen Zapfsäule wurde der Durchfluss des Treibstoffs mechanisch gemessen und auf einer Rollenanzeige angezeigt.
Mit dem Einhängen der Zapfpistole in die Zapfsäule wurde die Pumpe angeschaltet und eine Lampe auf der Zapfsäule leuchtete auf,
die den Tankwart auf den Plan rief.
Nach der Bezahlung stellte der Tankwart mit einer ansteckbaren Kurbel das Zählwerk auf Null und der nächste Kunde konnte tanken.
Den Treibstoff lieferte die Firma Minol, die auch Betreiber der öffentlichen Tankstellen war.
Der Preis pro Liter Treibstoff war konstant und an allen öffentlichen Tankstellen gleich.
An jeder Zapfsäule konnte man nur 1 Treibstoffart bekommen.
In den 1980er Jahren wurden in der DDR unter der Bezeichnung "ATDE" (Automatische Tankdatenerfassung) auch rechnergesteuerte Tankanlagen entwickelt.,
Tankautomat 1
Ende der 1980er Jahre entwickelte der VEB VAKA Halle, alleiniger Hersteller der DDR-Zapfsäulen, eine automatisierte Zapfsäule für Tankstellen.
Das System war zunächst nicht für öffentliche Tankstellen gedacht, sondern für die - damals recht häufigen -
innerbetriebliche Tankstellen, mit denen die Dienstwagen betankt wurden.
Dazu bekam die Zapfsäule einen Mikrorechner (auf Basis des Einchipmikrorechners UB8830),
der die Treibstoffmenge nun elektronisch erfasste.
Als Mengenanzeige diente ein durch einen Schaltkreis UL7211D angesteuertes vierstelliges LCD-Display;
auf eine Preisanzeige hatte man verzichtet.
Rechnergesteuerte Zapfsäule, Phantombild |
Prozessorkarte der Zapfsäule
| Rückseite der Displaykarte |
Seitlich an der Zapfsäule befand sich ein Magnetkartenleser Robotron K6503,
durch den vor dem Betanken eine Tankkarte (Magnetkarte) durchzuziehen war, wodurch der Automat entriegelt wurde.
Kopf der Zapfsäule mit dem Magnetkartenleser |
Automatische Betriebstankstellen waren in der DDR extrem selten.
Bis heute hat davon wahrscheinlich nur der Bedienkopf einer Zapfsäule überlebt.
Tankautomat 2
Im nächsten Schritt wurde die Möglichkeit einer automatisierten Abrechnung geschaffen.
Ausgangspunkt war die elektronische Zapfsäule B50 des VEB VAKA Halle,
diesmal bestückt mit einem zweizeiligen LCD-Display (32 Stellen) zur Anzeige von Menge und Preis.
Den Rechnerteil samt Software lieferte Robotron Zella-Mehlis.
Tanken an einer automatisierten DDR-Tankstelle
| Betankung an einer automatisierten DDR-Tankstelle |
Die Zapfsäule war über ein Betriebsdatenterminal K8902 per Netzwerk (IFLS) mit
dem zentralen Auswertecomputer verbunden und lieferte dort ihren Daten ab.
Dabei konnten maximal zwei Zapfsäulen vom einen K8902 gesteuert werden,
das K8902 war vermutlich nicht in die Zapfsäule eingebaut, sondern separat.
Die Zapfsäulen konnten zeitweise autonom arbeiten, da die K8902 die Möglichkeit
zum Zwischenspeichern und kumulieren von Daten besaßen.
Als Auswertecomputer konnte beim kleinen Tankstellen ein Bürocomputer K8915 dienen,
der mit einem Drucker K6313 ergänzt wurde.
Für größere Anwendungen waren stattdessen die großen Datenerfassungs-Basisrechner
A5222, A5223
oder A6422 vorgesehen.
Die Autofahrer identifizierten sich an dem System mit Hilfe einer Magnetkarte oder ein Lochkennkarte,
ggf. durch Eintippen eines persönlichen Kennwortes.
Über Tasten konnten der Tankstellenbetreiber bei Bedarf den Treibstoffpreis ändern und kumulierte Daten jeder Zapfsäule anzeigen.
Die Basissoftware auf den Betriebsdatenterminals K8902 war IDA.
Auf dem Auswerterechner K8915 wurde vermutlich das Betriebssystem SCP benutzt,
auf den großen Auswerterechnern die dort üblichen Echtzeit-Betriebssysteme.
Es ist davon auszugehen, dass nur sehr wenige dieser Anlagen in der Praxis eingesetzt wurden.
Allen Anschein nach ist diese Variante der automatisierten Betankung heute mit allen Komponenten ausgestorben.
Elektronischer Parkscheingeber
Automatisiert gedruckte Parkscheine waren in der DDR eigentlich nicht üblich.
Wenn es sich um gebührenpflichtigen Parkplatz handelte, war der üblicherweise eingezäunt und es gab es einen Platzwart, der die Parkzettel ausstellte,
damit handelte es sich um einen bewachten Parkplatz und im Schadensfall war der Fahrer versichert.
Mit der deutschen Einheit (und auch mit der daraufhin stark ansteigenden Zahl an Autos und dem knapper werdenden Angebot an Parkplätzen)
wurde es im Osten des Landes Mode, vielerorts Parkuhren als lokalen Geldeinnahme aufzustellen, ohne dabei Geld für einen Parkwart auszugeben.
Die Lösung war ein Automat, der nach Münzeinwurf einen (meist zeitlich begrenzten) Parkschein ausspuckte,
den der Fahrer sichtbar in seinem Auto hinterlegen musste und der vom patroullierenden Ordnungsamt bzw. der Polizei kontrolliert
und bei Fehlen oder Ungültigkeit finanziell bestraft wurde.
Zella-Mehliser Parkscheingeber
| Zella-Mehliser Parkscheingeber |
Da Robotron Zella-Mehlis, zu diesem Zeitpunkt wahrscheinlich bereits privatisiert,
durch die Betriebsdatenterminals bereits Erfahrungen mit der Fernerfassung von Daten hatte,
entwarf dieser Betrieb auch einen computergesteuerten Parkscheingeber.
Es ist nicht auszuschließen, dass es bei Konstruktion und Produktion Partnerfirmen (Joint Venture) gab.
Am Gerät war per Tastendruck die gewünschte Parkdauer auszuwählen,
der Automat forderte daraufhin das Einwerfen der Münzen und druckte bei Erreichen des geforderten Betrags den Parkschein aus.
Das Gerät konnte wahlweise mit oder ohne Geldrückgabe arbeiten.
Das Gerät akzeptierte maximal fünf Münzsorten (geprüft auf Größe, Gewicht, Magnetismus und Prägung) und konnte drei Münzsorten als Wechselgeld zurückgeben.
Um den Betrieb auch in der kalten Jahreszeit sicherzustellen, hatte das gerät eine Heizung eingebaut.
Zur Bedienung bei Dunkelheit war die anzeige flutlicht-beleuchtet.
Welche Technik im Gerät verbaut wurde, ist leider bislang nicht ermittelbar.
Ob der Parkscheingeber jemals produktiv eingesetzt wurde, ist unbekannt.
Wenn, dann sicher nur in ganz kleiner Stückzahl.
Der Zella-Mehliser Parkscheingeber gilt heute als ausgestorben.
Programme zur Tourenplanung
Um möglichst Zeit- und Kraftstoff-optimal zu fahren war es sinnvoll,
die Anfahrtreihenfolge bei komplexen Transporten (mit mehreren Anlieferungsstellen) entsprechend zu planen.
Erste Programme dazu gab es für die ESER-Großrechner.
In den 1980er Jahren waren dann auch Bürocomputer leistungsfähig genug, solche Aufgaben zu übernehmen.
Voraussetzung dafür war eine Datenbank, die die Strecken zwischen den einzelnen Anfahrtpunkten kannte.
Grob konnte man diese aus Landkarten heraus ermitteln, die Protokollierung von echten Fahrten brachte dann noch wesentlich genauere Werte.
Mähdrescher-Bordcomputer
Informationen zu diesen landwirtschaftlichen Geräten gibt es auf einer eigenen Seite.
Kransteuercomputer
Mit der Möglichkeit des Einbaus in Autokränen entwickelte Robotron einen Steuerrechner,
der die maximale Belastbarkeit des Krans ermittelte.
Informationen zu diesem Gerät gibt es auf einer eigenen Seite.
Einsatzbeispiele im Bahnverkehr
Informationssystem RISMU
In Mukran (nahe Saßnitz) wurde Anfang der 1980er Jahre für den Güterverkehr ein großer Fährhafen gebaut, hauptsächlich zum Güteraustausch mit der Sowjetunion.
Im Jahr 1986 wurde der Hafen in Betrieb genommen, neben dem zivilen Hafen gab es auch einen militärischen.
Da die Sowjetunion einen andere Spurbreite bei der Eisenbahn benutzte, mussten die Waggons im Hafen umgespurt werden.
Im zivilen Hafen wurde 1985 ein Rechnersystem aufgebaut, das eine automatisierte Waggonlogistik bei der Eisenbahn ermöglichen sollte.
Es ging darum, vorort die Zusammenstellung der Waggons der Güterzüge zu erfassen und zentrale Planungen mit den Daten durchzuführen.
Der Name RISMU stand für "Rechnergestütztes Informationssystem Mukran".
Alle Arbeiten in Umladung, Umachsung und Fährbereich wurden in RISMU abgebildet:
Von der Ankunft der Züge bis zur Abfahrt der Fähren und in umgekehrter Richtung.
Auch die Frachtabrechnung der Fähren lief über dieses System.
Mit dem Ende der DDR wurde der Fährhafen privatisiert, Mitte der 1990er Jahre ein Terminal für Personenverkehr gebaut.
Das RISMU-System wurde noch bis 1995 weiter betrieben und dann außer Betrieb genommen.
Die Güterfährverbindung nach Klaipeda wurde im Jahr 2013 eingestellt.
Rechenzentrum
In einem Rechenzentrum in Mukran wurde ein ESER-Großrechner EC1056 betrieben,
der zur Erhöhung der Ausfallsicherheit als Zwillingsmaschine ausgeführt war.
Auf einem Großrechner lief das aktive System, auf dem anderen das inaktive.
Beide fragten gegenseitig alle 30 Sekunden die Funktionsfähigkeit ihres Zwillings ab.
Wenn das aktive System auf Anfragen des inaktiven Systems nicht antwortete, wurde das inaktive zum aktiven System.
Wenn ein der fünf Fähren in Mukran abfuhr, fand eine Datenübertragung mit Klaipeda (damals in der Sowjetunion, heute Litauen) statt.
Ebenso wenn eine Fähre in Klaipeda abfuhr, erhielt Mukran eine Datenübertragung.
Es wurden Daten zur Fracht ausgetauscht, die dann direkt in das RISMU-System gingen.
Man wusste also schon 20 Stunden vor Ankunft der Fähren (eine Fahrt dauerte 20 Stunden), was an Waren kommt und wie die Waggons bearbeitet werden mussten.
Die Software, die auf dem Großrechner und auf den Bürocomputern lief, wurden von der Deutschen Reichsbahn geschrieben: arbeitsteilig in Berlin, Dresden und Halle.
Im Gegensatz zu der sonst auf Großrechnern üblichen Stapelverarbeitung lief auf den RISMU-Großrechnern ein Echtzeitsystem.
Datenstationen
An den Großrechner waren über Multiplexer Bürocomputer A5120 angekoppelt.
Auf den Arbeitsplatzrechnern liefen Programme, auf denen die Bediener im Zusammenspiel mit dem Großrechner Umladung und Umachsung planen konnten,
außerdem erfolgte das Ausdrucken von Ladelisten, Umladungsaufträgen bis hin zu den Frachtpapieren für die Fähren.
Jede Bewegung von Waggons und Ladungen wurden so in Echtzeit festgehalten.
Mobilgeräte
Da Bahnmitarbeiter sowieso ein Sprechfunkgerät mit sich trugen, bot es sich an, dieses für eine drahtlose Datenübertragung zu benutzen.
Dazu entwickelte das Wissenschaftlich-Technische Zentrum der Reichsbahn in Meinigen einen mobilen Computer:
Das batteriegespeiste Gerät wurde an einem Riemen vor dem Bauch getragen und war per Kabel mit dem Funkgerät (U700-Serie vom Funkwerk Köpenick) verbunden.
RISMU-Terminal |
Prozessorkarte des RISMU-Terminals
| Steuerkarte des RISMU-Terminals |
Es besaß eine Folientastatur zur Eingabe und ein LCD-Dotmatrix-Display zur Ausgabe.
Als Prozessor agierte ein Einchipmikrorechner UB8840, seine Software befand sich in einem EPROM.
Verbreitung / Verbleib
Wahrscheinlich war der Güterbahnhof in Mukran der einzige Bahnhof der DDR, wo dieses System eingesetzt wurde, es stellte also eine Art Pilotprojekt dar.
1995 wurde das RISMU-System außer Betrieb genommen und die meiste Technik verschrottet.
Ein Großrechner der RISMU-Zentrale steht heute als Ausstellungsstück im Nixdorf-Museum Paderborn.
Von den Mobilgeräten haben bis heute zwei Exemplare überlebt.
Mangels restlicher Geräte ist an eine Wiederinbetriebnahme aber nicht zu denken.
In der Bundesrepublik gab es in den 1980er Jahren ein ähnliches Pilotprojekt am Rangierbahnhof Seelze.
DDG2000
(Alias DDG 2000, DDG-2000)
Im Jahr 1984 gab es eine Veröffentlichung in einer Zeitung zu einem funkgesteuerten Rechnersystem der Bahn namens
DDG2000 (Datendialoggerät 2000), entwickelt im Zentralen Forschungsinstitut des Verkehrswesens der DDR.
Das System bestand aus einer Basisstation DFK (Datenfunkkonzentrator) und bis zu 16 Datenfunkterminals DFT,
die mit einer Geschwindigkeit von 1200 Baud kommunizierten.
Eine konkrete Anwendung wurde nicht angegeben, stattdessen allgemein Transport- Umschlag- und Lagerprozesse aufgeführt.
Ob dieses System letztlich in RISMU integriert wurde, konnte noch nicht nachgewiesen werden, es ist aber anzunehmen.
Rechnergestützte Wagenüberwachung RWÜ/RESEG
Der Hafen in Rostock mochte dem in Mukran nicht nachstehen und entwickelte ebenfalls ein rechnergestütztes System.
Projekt RESEG
Das Projekt begann mit einer rechnergesteuerten Wageneingangserfassung namens RESEG.
Dazu wurde als Zentralrechner ein Bürocomputer A5120 eingesetzt,
der unter dem Betriebssystem SIOS lief und mit einem Lochbandleser gekoppelt war.
Die Daten der Waggons wurden dezentral auf Lochband gestanzt, zur Zentrale gebracht und in den A5120 eingelesen.
Mangels Festplattenlaufwerk wurden sie auf Disketten abgelegt, was aber mit einigen Nachteilen verbunden war:
- Langsam
- geringe Kapazität
- Verschleiß
Projekt RWÜ
Ende der 1980er Jahre wurde die Technik wesentlich aufgerüstet:
zwei Kommerzielle Basisrechner A6402 wurden angeschafft,
die die oben genannten Nachteile der Diskettenlaufwerke überwanden und für gegenseitige Redundanz sorgten.
Die Rechner liefen unter einem Echtzeitbetriebssystem (wahrscheinlich MOOS oder OMOS).
Über Netzwerk (möglicherweise eine SCOM-LAN-Lösung)
wurden mehrere Bürocomputer A5120 als Datenterminals angekoppelt.
Verbreitung / Verbleib
Bislang ist nur der Einsatz an dieser einen Stelle bekannt.
Wahrscheinlich wurden alle Komponenten der Anlage in den 1990er Jahren verschrottet.
Wer hat Bilder bzw. Informationen dazu?
Rechnergestützte Dispatcherzentrale (RDZ/RZV)
Die Deutsche Reichsbahn hatte ein Interesse daran zu wissen, wie die aktuelle Lage auf dem Schienennetz war
(Sicherung des Personen- und Güterverkehrs, insbesondere des Kohletransports im Winter),
um die Auslastung des Streckennetzes und ihrer Schienenfahrzeuge zu optimieren und Verspätungen zu vermeiden.
Außerdem sollte der Energiebedarf durch optimale Nutzung der Loks (Vermeidung unnötiger Anfahrten) gesenkt werden.
Zusätzliche Anforderung war, dass es zu keinen Halten der Interzonenzüge (bei den Dispatchern hießen diese „Zitteraal“) kommen sollte,
da damit immer ein sehr hoher Aufwand verbunden war, rechtzeitiges Bestellen der Transportpolizei, die den Zug umstellen mussten,
Verspätungen für alle anderen Züge, da nicht im Bahnhof gehalten werden durfte, diverse Stellungnahmen warum und wieso usw.
Traditionell wurde das so gemacht, dass Tagesfahrpläne von einer Zentrale geschrieben und an das Personal verteilt wurden,
wann welcher Zug wo entlang fahren sollte.
Das Personal auf den Stellwerken meldete dann per Wechselsprechanlage, wann der Zug tatsächlich vorbei fuhr und ob es eventuelle Störungen gab.
Außerdem wurden die Züge vom Stellwerkspersonal in Meldebücher eingetragen.
Die Dispatcher-Zentrale notierte die Gespräche und benutzte die Informationen für weitere Planungen.
Dieses Verfahren funktionierte durchaus, hatte aber den Nachteil, dass es relativ langsam war:
Die Informationen in der Zentrale waren mindestens eine halbe Stunde alt, zeigten also eher einen Zustand der Vergangenheit statt die aktuelle Lage.
1979 wurde im Zentralen Forschungsinstitut des Verkehrswesens ein FuE-Projekts beim
Ministerium des Verkehrswesens beantragt, die Technologie (IfE, Institut des Eisenbahnwesens) und die Technik
(ZPA, später ZMR Zentrum für Mikroelektronik und Rechentechnik) für eine rechnergestützte Dispatcherzentrale (RDZ) der DR durchzuführen.
IfE und ZPA waren Struktureinheiten innerhalb des Zentralen Forschungsinstituts des Verkehrswesens (ZFIV).
Das Projekt wurde genehmigt und lief zuerst von Mitte 1979 bis 1983 und wurde dann auf Grund von Änderungen beim Einsatz
der zentralen Rechentechnik (DEC PDP11/34 anstatt Robotron KRS) um ein Jahr verlängert,
sodass die Übergabe der ersten RDZ zum 07.10.1984 in Erfurt erfolgen konnte.
Eine RDZ bestand aus einem Doppelrechnersystem (heiße Redundanz) in der Zentrale,
dem Datenübertragungssystem auf Basis TMF, den Informationserfassungsgeräten in den Stellwerken
sowie der Dispatcherzentrale mit den Bildschirmarbeitsplätzen der Dispatcher und den
Farbbildschirmen zur Anzeige der Betriebslage der überwachten Strecken.
RDZ-Gleisbildanzeige auf einem Terminal |
Die RDZ wurde als Informationssystem konzipiert, ohne sicherheitsrelevante Eingriffe in den Bahnverkehr zu ermöglichen.
Dadurch entfielen für die Anlage wesentliche Sicherheitsprüfungen, die von einer erheblichen Dauer gewesen wären
und von den wenigen Mitarbeitern im Projekt auch nicht hätten bearbeitet werden können.
Die Übermittlung der Dispositionsentscheidungen der Dispatcher erfolgte deshalb auf herkömmlicher Weise an die verantwortlichen Fahrdienstleiter vorort.
Mit der Anlage in Erfurt wurde die Strecke Gerstungen bis Leuna-Nord und die angrenzenden Abschnitte auf den Zulaufstrecken überwacht.
1986 wurde die zweite RDZ auf der gleichen technischen Basis in Halle übergeben, nur in der Zentrale mit Rechnern PDP11/44 anstatt PDP11/34.
Im März 1988 ging das System in Halle dann in den Dauerbetrieb.
Mit dieser RDZ wurden die Strecke Leuna-Nord bis Lutherstadt-Wittenberg und die Strecken nach Leipzig und Köthen überwacht.
Auf Grund der veralteten Mikrorechner K1510 in den Informationseingabegeräten (IEG)
und den damit verbundenen Beschaffungsproblemen wurde parallel zu den Arbeiten für die RDZ Halle im ZFIV/ZPA bereits an
einer neuen Generation von IEGs auf Basis des Robotron Rechnersystems K1520 gearbeitet.
Ziel war es damit auch eine Zugnummernmeldeanlage zu integrieren, für die der Datenaustausch direkt zwischen den Stellwerken ermöglicht werden musste.
Die Reichweite des Systems war zunächst nicht landesweit angesetzt, sondern entsprechend der Reichsbahndirektionen.
Es wurden ab 1984 mehrere solcher Systeme in Betrieb genommen: zunächst in Erfurt (220 Streckenkilometer) und Halle,
später in Leipzig und mehrere in Berlin.
Auch für Magdeburg befand sich ein System in Planung, wurde aber bis 1990 nicht mehr realisiert.
Stattdessen wurde dieses System dann von Siemens gebaut und ging Mitte der 1990er Jahre in Betrieb.
Die Systeme wurden datentechnisch untereinander verbunden und konnten so an den Übergabepunkten automatisch Züge von einem System in das nächste übernehmen.
Wieviele Stellwerke von einem System maximal verwalten werden konnten, ist nicht bekannt.
Die RDZ in Halle hatte ca. 70 Stellwerke angeschlossen und deckte damit das Umland bis Köthen, Wittenberg, Leipzig, Bad Dürrenberg und Eisleben ab.
Die RDZ war vermutlich das erste System seiner Art in Europa.
Mitte der 1980er Jahre Baute ITT ein Leitsystem in Wien für die Österreichische Bahn.
Dieses System bestand auch aus einem Doppelrechnersystem der Serie PDP11.
Die Rechner besaßen bereits für die Anzeigen vollgrafische Adapter (Bildwiederholspeicher), so dass dann auch die Darstellung
der Zugläufe grafisch auf Farbbildschirmen erfolgen und direkt vom zentralen Rechnersystem gesteuert werden konnte.
RDZ-Zentrale
Die Zentrale bestand aus zwei Teilen: einem Kleinrechenzentrum
und einem meist in einem anderen Gebäude befindlichen Dispatcherarbeitsraum.
Im Laufe des Jahres 1980 wurde mit der Konzipierung und Entwicklung der Ausgabegeräte für die Zentrale begonnen.
Die technologischen Anforderungen an das System ließen sich nur mit einer mehrfarbigen Anzeige gewährleisten.
Da es von Robotron zu diesem Zeitpunkt keine entsprechenden Monitore gab, wurde eine Eigenentwicklung vorgenommen.
Als Steuerrechner wurde der K1520 vorgesehen, da es klar war, dass der K1510 eigentlich nur ein Einstieg und eine Übergangslösung sein konnte.
Somit wurde sowohl die Hardware für den K1520-Rechner als auch die Steuersoftware entwickelt.
Die Ansteuerung von Seiten der PDP11 erfolgte über eine serielle Schnittstelle.
Auf Grund der knappen Speicherbauelemente wurde die Software soweit optimiert, bis sie auf einem 1-KByte-EPROM (U 2708) passte.
Die Monitore wurden aus Fernsehgeräten vom Typ Colortron 3000 des Fernsehgerätewerks Stassfurt gebaut.
Dazu hatte RAME ein fast randloses Gehäuse konstruiert, sodass die Geräte unter dem Einsatz von Texturblech-Gehäusen
direkt aneinander aufgestellt werden konnten.
Nach der Präsentation einer Bildschirmausgabe mit einem Simulationsprogramm war Alfred Neumann
(im ZK der SED für die Bahn zuständig) von der RDZ so begeistert, dass er die RDZ zum Staatsplanthema erhob.
Das war damals die höchste zu erreichende Stufe für ein ziviles FuE-Projekt und bedeutete vordringlichen Bedarf.
Damit wurde es nicht nur möglich, die für Erfurt benötigten Colortron-3000-Farbfernseher mit Toshiba-Bildröhre aus dem
Bevölkerungsbedarf direkt ab Werk in Stassfurt abzuholen, sondern es erfolgte die Beschaffung einer anderen zentralen Rechentechnik,
so dass nun statt KRS4200, die Robotron
auch nicht liefern konnte, PDP11/34 unter größter Geheimhaltung geliefert wurden.
Die neue Technik brachte dann nicht nur Vorteile.
Die Entwickler des Softwarepakets mussten sich in das neue Betriebssystem RSX11/M einarbeiten.
Unterlagen dafür waren kaum verfügbar.
Der Rechnertyp war in verschiedenen Betrieben in der DDR im Einsatz.
Da sie unter Umgehung des US-Embargos beschafft wurden, war das jedoch öffentlich nicht bekannt.
So musste bei auftretenden Problemen immer über das Ministerium eine Anfrage gestartet werden,
wer in der Nähe so einen Rechner hat und mit wem man über die Programmierung sprechen durfte.
Die VT100-Terminals in der RDZ Erfurt wurden zur Tarnung mit dem Robotron-Schriftzug überklebt.
Zutritt zum Rechnerraum, wo die zwei PDP11 standen, hatte natürlich nur das gesondert überprüfte Wartungspersonal der SFM.
Für die Rechnerkopplung der beiden PDP11 hatte eine niederländische Firma eine Zusatzplatine entwickelt,
die die Umschaltung bei einer Störung vornahm.
Die Prozesssignale wurden parallel aufgelegt und für die Umschaltung der Peripherie wurde eine Steuereinheit entwickelt,
die in eine störungsfreie Umschaltung ermöglichte.
Dafür mussten verfügbare Relaisplatinen von Robotron verwendet werden, die den Nachteil hatten, dass sie keine Umschaltkontakte hatten.
So musste nicht nur ein IEG-Gehäuse dafür verbaut, sondern auch ein Mechanismus zur Steuerung der Umschaltung gebaut werden,
damit alle Anschlüsse zeitrichtig und ohne unzulässige Erdschleifen umgeschaltet werden konnten.
Für die Auslösung der Umschaltung wurde das BUSY-Signal der Zusatzplatine des PDP11 genutzt.
Die zentralen Rechner liefen im 24x7-Betrieb, es war auch ein Diesel-Notstromaggregat dafür eingeplant.
RDZ-Dispatcherraum (Überwachungszentrale ÜZ)
Hier arbeiteten an Computerterminals:
- Zugdispatcher (Optimieren der Auslastung des Schienennetzes)
- Triebfahrzeugdispatcher (Optimieren der Auslastung der Loks)
- Fahrdienstdispatcher
- Brigadedispatcher (Planen der Belegschaft des Bahnhofs)
- Fahrplanaufbereitung (Erstellung künftiger Fahrpläne)
Im Vorfeld wurden die Zugdaten in das System eingespeist (Zugnummer, Länge, Last, Achsen).
Von den Stellwerken wurden weitere Daten geliefert, die im Dispatcherraum visualisiert wurden.
Dispatcherraum (historische Aufnahme)
| Anzeige auf einem Dispatcherbildschirm |
Im Dispatcherraum befanden sich vier K1520-Rechner,
die die Daten der Kleinrechner des Rechenzentrums zu farbigen Monitorbildern aufbereiteten
und diese den Mitarbeitern auf acht großen Bildschirmen (umgebaute Colortron-Fernseher, sowjetische Farbbildschirme oder SONY-Bildschirme) zur Verfügung stellten.
Die Informationsdarstellung auf den Bildschirmen erfolgte bei den frühen RDZ-Systemen im Textmodus,
entweder in Listenform oder als pseudografische Darstellung, wobei die Aktualisierung alle 20 Sekunden erfolgte.
Bei den späteren Systemen (Berlin) war auch eine grafische Darstellung möglich.
RDZ-K1520-Rechner
| Anzeige auf einem altersschwachen Bildschirm |
RDZ-K1520-Rechner
| RDZ-K1520-Rechner, Rückseite |
Bei den neueren RDZ-Anlagen (Bezirk Berlin) erfolgte eine Ablösung der importierten Technik durch DDR-Produkte:
es wurde vom Einsatz von Robotron-Farbbildschirmen K7226,
Schwarzweiß-Bildschirmen K7222 sowie Druckern K6313 berichtet.
In den 1990er Jahren wurden die Dispatcherarbeitsplätze dann durch westliche PCs ersetzt.
Zur Anlage gehörten mindestens zwei Drucker: einer für Abfragen/Statistikdrucke/Fahrplanaufbereitung und einer für den Belegblattdruck.
Die beiden Drucker konnten sich im Fehlerfall gegenseitig ersetzen.
RDZ-Kleinrechenzentrum
Das Rechenzentrum war als typisch fensterloser Bau mit einem großen Hauptraum ausgeführt,
mit schalldämmendender Wandverkleidung, Klimatisierung und Ständerfußboden zum Verbergen der Kabel.
Die Belegschaft des Rechenzentrums bestand aus 10 Leuten, zuzüglich Wartungspersonal.
Arbeit in einem RDZ-Rechenzentrum |
In den Bauunterlagen zur RDZ Halle war zunächst der Robotron R4000 als Leitrechner angegeben.
Stattdessen wurden amerikanische PDP11/44-Rechner eingesetzt, die in Österreich vorgeblich für "medizinische Zwecke" beschafft wurden
und dann heimlich in die DDR kamen, da dieser Export in die DDR offiziell durch das COCOM-Embargo verboten war.
Die Kosten für die Anlage lagen bei über 1 Million D-Mark pro Rechenzentrum, das Ministerium für Staatssicherheit wickelte diesen Kauf ab.
In der System-Dokumentation der Reichsbahn wurden Hinweise auf den Hersteller der Rechner vermieden.
Da das Rechenzentrum innerhalb der gesicherten Bezirksdirektion der Reichsbahn lag und nur einem kleinen Personenkreis zugänglich war,
hatte man beim Hallenser System darauf verzichtet, die Typenschilder an den Geräten zu entfernen, wie dies beim Erfurter System passiert war.
RDZ-Doppelrechner
| RDZ-Doppelrechner |
Kabel an der Rückseite der Leitrechner
| Notfall-Umschaltvorrichtung |
Aus Sicherheitsgründen war der Leitrechner doppelt ausgeführt und schaltete im Fall eines Rechnerausfalls automatisch auf das Schwestergerät um.
Ein dritter Rechner stand für Testzwecke zur Verfügung.
Am Leitrechner waren mehrere Terminals mit Schwarzweiß-Bildschirmen (westliche Geräte des Typs CIT101) angekoppelt.
Die Software für die PDP-Rechner befand sich auf 14-Zoll-Wechselplatten; jedem Rechner waren zwei Wechselplattenlaufwerke zugeordnet.
Mehrere Schränke mit Übertragungsgeräten waren für die Anbindung der Stellwerke zuständig.
Dieses System nannte sich VWT72, war ebenfalls doppelt ausgeführt und mit automatischen Umschalteinrichtungen versehen.
Das Übertragungsverfahren zu den Stellwerken basierte auf Fernschreibertechnologie,
konnte außer mit einfachen Stromschleifen auch über Trägerfrequenztechnik erfolgen.
Letzteres ermögliche die Nutzung eines Leitungspaares für gleich mehrere Stellwerke,
was beim sternförmigen Aufbau des Netzes den Bedarf an Kabeln stark reduzierte.
Die Datenübertragung zwischen der RDZ-Zentrale und den IEG erfolgte nach dem Master-Slave-Prinzip,
d.h. die Zentrale fragte nacheinander die Stellwerksrechner ab.
Außerhalb des aktiven Betriebs gab es im Rechenzentrum noch einen Programmierrechner (zum Erstellen der EPROMs für die Stellwerke),
ein IEG für Diagnosezwecke sowie einen K1520-Rechner, der für Prüfzwecke den PDP-Leitrechner emulieren konnte.
Ein VWT72-Schrank
| Programmierrechner |
Das Anfahren der Anlage wurde durch das Wartungspersonal gemacht.
Lief die Anlage stabil, wurde die Bedienung an die Dispatcher übergeben.
Zur Kopplung mit den anderen RDZ-Rechenzentren wurden zu späterer Zeit VAX-Rechner nachgerüstet, die das DECnet auf TCP/IP umsetzten
und dieses über spezielle Übertragungsschränke mit den Fernleitungen verbanden.
RDZ-Informationserfassungsgeräte
In jedem zur Zentrale gehörigen Stellwerk (das konnten über 70 Stück sein) befand sich ein Rechner (Informationserfassungsgerät IEG),
der die Informationen des eigenen Stellwerks sammelte und per Fernleitung an das Rechenzentrum schickte.
Zunächst wurde hierzu ein modifiziertes PBT4000 von Robotron
und kurz darauf ein auf die Belange der Reichsbahn zugeschnittener K1510-OEM-Rechner benutzt,
bei noch späteren Systemen übernahmen ein ebenso bahn-spezifischer K1520-OEM-Rechner diese Funktion.
Manchmal wurden diese Rechner in den Aufenthaltsräumen der Stellwerke aufgestellt, manchmal in separaten Räumen.
Typisches Reichsbahn-Stellwerksgebäude |
IEG-Tastatur, IEG-Bildschirm und Zugfunk-Bediengerät
| Unscheinbarer Würfel: der IEG-Rechner |
IEG-Tastaturen
| Übertragungseinheit VWT6 |
Innenansicht des IEG-Rechners
| Rückseite des IEG-Rechners |
ausgebautes IEG-Rack |
Es gab vier Varianten der IEG:
- IEG-M
Für manuelle Bedienung mit Bildschirm und mit kleiner Tastatur.
- IEG-A
Für automatischen Betrieb ohne Bildschirm und Tastatur.
- IEG-A/M
"Vollausrüstung" für sowohl automatischen Betrieb als auch für manuelle Eingriffe mit Bildschirm und kleiner Tastatur.
- IEG-S
Wie IEG-A/M, aber zusätzlich mit einer alphanumerischen Tastatur.
Platinenbestückung des K1510-IEG:
Name | Kürzel | Funktion
|
---|
K2511 | ZVE | Prozessorkarte, Teil 1
|
K2011 | ZVE | Prozessorkarte, Teil 2
|
K3810 | PFS | 4 KByte-ROM-Karte (1-3 Stück)
|
K8512 | OSS | 4 KByte-RAM-Karte
|
K2012 | EZU | Echtzeituhr
|
6521.026-01384 | AFM | Bahn-spezifische Karte zur Fernverbindung (max. 2 Stück)
|
K7013 | ATA | Tastaturcontroller
|
K7010 | ABS | Bildschirmkarte
|
6521.026-01385 | DATI | Bahn-spezifische Karte zur Fernverbindung
|
K9212.02 | DEI | Digitale Eingabekarte, 16 Bit zum Anschluss der örtlichen Prozesssignale (max. 12 Stück)
|
Die Informationen über die Zugfahrten wurden potentialfrei aus der Sicherungstechnik abgegriffen.
Da die verschiedensten Bauformen von Stellwerken vorhanden waren, mussten auch Hebelstellwerke berücksichtigt werden.
Dazu wurden entsprechende Kontakte auf den Hebeln nachgesetzt.
Da nicht alle Informationen bei einem Befehlsstellwerk anlagen, mussten die Wärterstellwerke auf dem Bahnhof ebenfalls angeschlossen werden.
Die Informationen wurden auf Bahnhofsebene mittels eines Tonfrequenz-Multiplex-Fernwirksystem (TMF) zum IEG übertragen
und mit den E/A-Baugruppen des K1510-Rechners verbunden.
Die Übertragung der Daten vom IEG zur Zentrale erfolgte mit der analogen Vierdraht-Wechselstrom-Telegrafieanlage VWT72 des
VEB RFT Fernmeldewerk Leipzig.
Die Anlage gestattet neben den Vierdraht-Betrieb auch einen Zwei-Draht-Betrieb auf normalen Fernmeldekabeln und sogar auf Freileitungen.
Die Bereitstellung der erforderlichen Leitungen war damals ein großes Problem.
Es gab einen Abschnitt in der RBD Erfurt, wo tatsächlich Freileitungen für die Datenübertragung genutzt werden mussten.
Beide Übertragungssysteme hatten keine handelsüblichen Schnittstellen, um mit Rechnersystemen zu kommunizieren.
Deshalb wurden zu diesem Zweck die Adapter für das IEG und ein Umsetzer für den PDP11 im Rahmen der Arbeiten an der RDZ entwickelt.
Die IEGs wurden bei RAME Meiningen für die RDZ montiert.
RAME wurde als Rationalisierungsmittelbau der DR gegründet, befand sich Anfang der 80er Jahre gerade im Aufbau
und wurde bei Gründung des WTZ-DR in das WTZ eingegliedert.
Das Verfahren der Zuglaufverfolgung der RDZ beruhte auf logischen Fortschaltkriterien.
D.h. wenn ein Zug unterwegs war, konnte man z.B. bei Auflösung einer Fahrstraße im Bahnhof davon ausgehen, dass sich der Zug im nächsten Streckenabschnitt befand.
Deshalb waren zuerst nur an den Einbruchstellen in den Überwachungsbereich Tastaturen und Bildschirme an den IEGs vorgesehen.
Da sich das bei der Konzipierung der RDZ als nicht ausreichend herausstellte, wurde 1981/82 noch zusätzlich eine kleine Hilfstastatur
zur Eingabe von Zugnummern und dedizierter Meldungen (im Rahmen einer Neuerervereinbarung) entwickelt.
Über die digitalen Eingabebaugruppen wertete der Rechner die Stellung der Weichen und Signale und die Strecken-Freimeldeanlage aus,
weitere Informationen konnten über die Tastatur eingegeben werden.
Anschließend wurden die Informationen über die Fernschreibschnittstelle des Rechners an ein externes Gerät namens VWT6
(das Trägerfrequenztechnik beinhaltete und die Nutzung derselben Fernleitung für gleich mehrere Stellwerke ermöglichte) ausgegeben,
woraufhin die Informationen dann in Richtung Rechenzentrum geschickt wurden.
Weiterhin befanden sich in dem schrankartigen IEG-Rechner ein TMF-Einschub, der einen direkten automatischen Datenaustausch mit den Nachbar-Stellwerken ermöglichte
(z.B. zur Anbindung eines kleineren benachbarten Stellwerkes ohne eigenes IEG), außerdem natürlich die Stromversorgungsmodule.
Zum IEG-Rechner gehörten ein Bildschirm ANA
und eine bahnspezifische Tastatur, weiterhin ein oder zwei Anschlussgeräte VTW72 zur Fernverbindung mit der Zentrale.
Offener IEG-Rechner |
Da die Zugnummern und die Durchfahrtreihenfolge in der Zentrale vorlagen, war eine Zug-Identifizierung in den Stellwerken nicht notwendig.
Hatte ein Zug einen Bahnhof verlassen, machte er beim nächsten Stellwerk über das TMF automatisch mit einen Signalton auf sich aufmerksam.
Die IEGs der zweiten Generation (RDZ Berlin) nannten sich IES und waren Systeme aus dem Automatisierungsrechnerprogramm
des Elektro-Apparate-Werk Berlin, das auf dem K1520-Robotron-System basierte.
Auf diesen Rechnern war zumindest geplant, ein Echtzeitbetriebssystem einzusetzen
(Basis KOMI bzw. KOMINET von der TU Dresden, Sektion 9).
Verbleib
RDZ-Anlagen waren eine lange Zeit in Betrieb: sie überlebten auch die Auflösung der DDR und den Übergang des Betreibers zur Deutschen Bahn.
Die Anlage auf dem Bahnhof Halle war bis Januar 2015 (also 31 Jahre lang!) im produktiven Einsatz.
Um die Anlage am Leben zu halten, war geschultes internes Wartungspersonal notwendig,
denn außerhalb der Bahn war diese Generation an Rechentechnik kaum noch anzutreffen.
Bis 2016 wurde das System in Halle noch nicht-produktiv weiter betrieben (Verbindungen getrennt, Rechner liefen noch),
dann wurde es ausgemustert und durch neue Technik (LeiBIT-System) ersetzt.
Ein Teil der Geräte des Systems wird seitdem im Rechenwerk Halle ausgestellt,
einige Geräte gingen an das Bahnmuseum Halle.
Über das Schicksal der Anlagen in Erfurt und Berlin ist bislang nichts bekannt.
Vermutlich wurden sie bereits verschrottet und durch neue Systeme ersetzt.
Mikrorechnergesteuerte Halbschrankenanlage
Schrankenanlagen wurden in der DDR meist mit einfacher Relaistechnik gesteuert.
Ende der 1980er Jahre bildete sich auch hier die Idee heraus, die Steuerung künftig durch Computer vornehmen zu lassen.
Ein Prototyp wurde dazu unter Beteiligung der TU Dresden gebaut.
Da man dem Computer nicht recht traute und die ganze Sache durchaus sicherheitskritisch war,
ließ man den Prototyp der Computersteuerung probeweise parallel zur herkömmlichen Schrankentechnik laufen, um nachzuweisen, dass er sich identisch verhielt.
Über diesen Betriebsversuch hinaus war das Projekt vermutlich nie gekommen.
Die computergesteuerte Halbschrankenanlage der DDR gilt heute als ausgestorben.
Punktförmige Zugbeeinflussung PZ80
(Alias PZ 80, PZ-80, PZ80R, PZ 80 R, PZ 80R, PZ-80R, PZ-80-R)
Bereits zu Beginn des 20. Jahrhunderts forschte man an Systemen, um Eisenbahnzüge bei Fehlverhalten des Lokführers
oder bei Fehlstellungen von Signalen vor Schäden zu bewahren, hauptsächlich beim Überfahren roter Signale oder beim Fahren mit zu hoher Geschwindigkeit.
In den 1930er Jahren entstand daraus ein produktives System namens INDUSI.
Dazu wurden an den Gleisen, insbesondere vor Haltesignalen, induktive Resonatoren (elektrische Schwingkreise, die keine eigene Stromversorgung benötigten, sogenannte Gleismagnete) angebracht.
Diese Resonatoren wurden bei auf grün stehendem Signal kurzgeschlossen, damit unwirksam gemacht.
Man entschied sich, zunächst drei Frequenzen (500 Hz, 1000 Hz, 2000 Hz) zu benutzen, um drei unterschiedliche Funktionen am Zug hervorrufen zu können.
Die drei notwendigen Frequenzen waren auf der Lok zu erzeugen, zunächst mit mechanischen Generatoren und Relais.
Eine per PZ80 überwachte Lok: BR243 |
1985 hielt in der DDR auch bei diesem System die Mikroelektronik (allerdings ohne Prozessorsteuerung) Einzug in Form des Systems PZ80, das auf den Lokomotiven montiert wurde.
Hersteller war das Geräte- und Reglerwerk Teltow.
Die Anlage bestand aus:
- einem zentralen Steuerschrank (zentrale Informationsverarbeitung ZIV)
- einem oder zwei Bediengeräten (auf jedem Führerstand eins).
- einer Schaltergruppe im Führerpult
- Geschwindigkeitsmesseinrichtung bzw. Wegstreckenmesseinrichtung (140 Impulse pro Radumdrehung, 4 Geber)
- Sensoren für die Magnetresonatoren (drei Schwingkreise, die nahe an ihren Resonanzfrequenzen 500 Hz + 100 Hz + 200 Hz erregt wurden, 200 mA) und sich bei Vorbeifahrt am Resonator entsprechend verstimmten.
- Sensoren für den Bremsdruck (Bremsen-Funktionsfähigkeits-Überwachung, Einstellung einer definierten Bremskraft bei Zwangsbremsungen)
PZ80-Geschwindigkeitsanzeige
| Prüfgerät für PZ80 für den Reparaturservice |
PZ80-Steuerschrank
| PZ80-Geschwindigkeitsmess- und Registriereinheit |
Folgende Situationen/Funktionen deckte das PZ80 ab:
- Weiterfahren bei Halt zeigenden Signalen
- Das Überschreiten der an der Strecke angezeigten Höchstgeschwindigkeit
- Das Überschreiten der für den Zug erlaubten Höchstgeschwindigkeit (abhängig von der Höchstgeschwindigkeit der Lok, ihrem Bremsverhalten und der im Fahrplan vorgeschriebenen Höchstgeschwindigkeit), max. 180 km/h
- Das Nicht-Beachten von Langsamfahrstellen
- Das Nicht-Beachten von Überwachungssignalen an Bahnübergängen
- Prüfung der Wachsamkeit des Zugführers bei Vorsignalen
- Registrieren des Zugverhaltens auf Papier: wie bei einem Fahrtenschreiber.
In der Bedieneinheit PZ80R waren zunächst die Grundeigenschaften des Zuges einzugeben, unter Nutzung der dekadischen Schalter: BRA=Bremsart und BRH=Bremshundertstel.
Das Bediengerät enthielt eine zweistellige Siebensegmentanzeige zur Anzeige der Fahrgeschwindigkeit.
Ein Signalgeber machte bei Fahrfehlern oder bei Warnungen akustisch aufmerksam.
Bediengerät PZ80R |
Der Störbetrieb-Schalter setzte bei Bedarf die Überwachung außer Betrieb, z.B. bei Fehlfunktion des Systems oder bei Rangierbetrieb.
Dabei wurde auch ein Überfahren roter Signale gestattet, die Höchstgeschwindigkeit aber auf 40 km/h begrenzt.
Eine per PZ80 erstellte Fahrtregistrierung |
Heute sind PZ80 nicht mehr im produktiven Einsatz, modernere Zugbeeinflussungssysteme übernehmen stattdessen diese Arbeit.
Es ist davon auszugehen, dass in Traditionsvereinen der Bahn einige PZ80-Geräte bis heute überlebt haben.
Elektronische Platzkartenreservierung EPLA
Informationen zu diesem bei der Deutschen Reichsbahn benutzen System gibt es auf einer separaten Seite.
Mikrorechnergesteuerter Schalterdrucker MSD
Informationen zu diesem bei der Deutschen Reichsbahn benutzen System gibt es auf einer separaten Seite.
Fahrkartenautomat MFA
Informationen zu diesem bei der Deutschen Reichsbahn benutzen Gerät gibt es auf einer separaten Seite.
Einsatzbeispiele in der Seefahrt
Ladungscomputer LC80 (alias Ladungscomputer Z80)
(Alias Ladungsrechner, LC 80, LC-80)
(nicht zu verwechseln mit dem namensgleichen Lerncomputer LC80)
Der LC80 war ein von der Neuererabteilung der "Deutfracht / Seereederei" in Rostock Marienehe
entwickelter Computer zur Berechnung der optimalen Position von Fracht auf Schiffen.
Damit ein Schiff stabil im Wasser liegt, muss die Fracht so angeordnet sein (Trimmung), dass das Schiff keine Neigung hat.
Anfangs wurden dies per Hand auf Papier, später per Taschenrechner ermittelt.
In den 1980er Jahren ersann man dann eine computergestützte Lösung dafür.
Der Rechner hatte kein Gehäuse und war in einem Gestell, ähnlich einem K1520-Käfig, am Schreibtisch des Ladungsoffiziers (Chiefmate) angebaut.
Die Platinen waren vermutlich auf dem NANOS-System aufgebaut, hatten zumindest eine ähnliche Größe.
Die Tastatur war eine einfache Matrix aus grünen Tasten mit den Zahlen 0-9, Enter und Löschen.
Die Anzeige erfolgte auf einem mit grünen LED-VQAs bestückten Display, das dreizeilig (X-, Y- und Z-Achse) war
und die Lagewerten und die entsprechende Tonnage des jeweiligen Ladungsteiles angezeigte.
Außerdem wurde ein Drucker SD1132 zur Ausgabe benutzt.
Einige Bauteile für den Rechner wurden von Robotron zugeliefert.
Einzugeben waren jeweils das Gewicht des Containers, die X- Y- und Z-Koordinate, was bei der Vielzahl an Containern ziemlich aufwändig war.
Der LC80 war wahrscheinlich nur nur auf älteren Stückgutschiffen im Einsatz.
Bei den Containerschiffen erfolgte die Beladung samt Ladungsberechnung von Land aus
und die Stabilitätsberechnungen wurden nur noch an Bord überprüft, aber nicht mehr selbständig berechnet.
Die Stabilität der Schiffe wird auch heute noch auf gleiche Weise errechnet, indem man für jedes Ladungsteil - heute Container -
die Tonnage und die Lage im Schiff (X-, Y- und Z-Wert, entsprechend Länge, Breite und Höhe vom Schiffsmittelpunkt entfernt) angibt.
Bei Containern ist das relativ einfach.
Der LC80 lief nicht sehr stabil und stürzte des Öfteren ab.
Daher hatten sich die Chiefmates meistens nicht auf den Rechner verlassen und alles noch einmal per Hand nachgerechnet.
Dem LC80 war damit keine größere Verbreitung beschieden:
nach ca. 100 produzierten Exemplaren wurde die Herstellung eingestellt.
Die LC80 waren vermutlich bis Ende der 1980er Jahre im produktiven Einsatz und wurden dann ausgemustert und verschrottet.
Heute gilt der LC80 gilt als ausgestorben.
Hat irgendwo so ein Gerät überlebt oder hat ein Foto davon?
Automatisierungsanlage E8100
(Alias E 8100, E-8100, SES 6000, SES-6000)
Nachdem es bereits Erfahrungen mit dem Einsatz von Ursadat 4100 auf Schiffen gab,
stellte EAW Mitte der 1980er Jahre mit der E8100 ein spezielles Automatisierungssystem
für die Frachtschiffe der Saturn-Klasse ("Wilhelm Pieck", "Ernst Thälmann", "Otto Grotewohl" und "Walter Ulbricht") vor,
das als Bestandteil in ein "System der Schiffsautomatisierung" namens SES6000 eingegliedert war.
E8100-Anlage |
Schiffsbrücke mit E8100
| E8100-Warte |
Eins der Schiffe mit E8100 |
Die E8100 bestand aus:
- Maschinenüberwachungsanlage E8100-MÜA, eine Art Prozessleitsystem für das Schiff.
Von autarken Prozessstationen wurden Daten gewonnen und in der Zentrale auf dem Bildschirm dargestellt.
Im Fehlerfall wurde automatisch Ingenieuralarm ausgelöst.
- Sicherheitssystem der Hauptantriebsanlage E8100-SSH
Diese Anlage reduzierte die Leitung der Antriebsanlage bzw. schaltete sie ab, wenn kritischen Grenzen des Maschinenbetriebs überschritten wurden.
- Manöverregistrieranlage E8100-MRA, quasi der Flugschreiber fürs Schiff:
Kommandos und Maschinendaten wurden erfasst und automatisch und autonom auf einem Drucker ausgegeben.
In den Anlagen wurden sowohl 8-Bit-Rechner als auch 16-Bit Rechner benutzt.
Es ist nicht auszuschließen, dass die Anlagen mit P8000-Computern arbeiteten.
In den Schiffen der Saturn-Klasse sollten alle Möglichkeiten der Energieeinsparung und der Technisierung des Schiffsbetriebes einfließen.
Letztendlich zeigte es sich aber, dass die Anlagen für die damalige Zeit zu komplex waren.
Vermutlich haben keine E8100 bis heute überlebt.