Das kleine Ingenieurbüro

Details zu relevanten Projekten

OSIRIS
Am Institut für Regelungstechnik wurde ein Echtzeitkern iRMX80 von Intel in einem Drittmittelprojekt, der Entwicklung einer autonomen Containerrangierlokomotive eingesetzt. Dieses Multitasking weckte mein Interesse. Reverse Engineering ergab, daß der Kern in PL/M geschrieben und kompiliert war, 8kByte Platzbedarf für Code. Im Rahmen einer Studienarbeit habe ich einen funktionsähnlichen, der Aufgabenstellung besser angepassten Kern mit nur noch 2k Codebedarf und gegenüber iRMX80 halbierter Interruptantwortzeit entwickelt. Für meine eigenen Weiterentwicklungen habe ich das Message-Passing-Kommunikationsschema des Kerns durch ein Semaphorensystem ersetzt und die Z80-Erweiterungen des Befehls- und Registersatzes verwendet, dieser Kern benötigte nur noch etwas mehr als 1k. Ich nanne ihn OSIRIS, offiziell als Akronym für 'Operating System for Intelligent Realtime Interrupt Service', eigentlich aber als historisch passenden Namen - die Entwicklungsumgebung von Intel hieß nämlich ISIS
STATE, ca. 1983
Boolesche Logik, endliche Automaten und PALS / GALS waren die Auslöser für dieses Projekt: In den diversen Hardwareprojekten im RWTH- und ELSA-Umfeld der frühen 80er Jahre ärgerte mich, daß man endliche Automaten auf Papier nett grafisch beschreiben konnte, auch gelang die manuelle Überführung in Boolesche Logik, die man dann per PALASM in programmierbare Hardware gießen konnte, es blieb in dieser Zeit der nicht-grafischen Computer aber die wichtigste und plausibelste Form des Entwurfes ein Stück Papier: der Graph des Zustandsautomaten.
Angeregt durch die Lektüre von 'Compilerbau' von Norbert Wirth (ETH Zürich), dem Vater der Sprache Pascal, habe ich dann eine Sprache entworfen, in der man die Zustandsgraphen beschreiben konnte und in Gleichungen für PALs umsetzen konnte.
Heute würde man ähnliche Probleme in VHDL lösen.
Der Compiler wurde in C geschrieben, lief unter CP/M 2.2 auf einer Z80, später auf PC, ich habe es bis zu Linux portiert, verfügbar auf Anfrage.
Virtualisiertes CP/M, ca 1983
Für ein CP/M-System zur Strömungsmessung an einer Gasturbine, letztendlicher Auftraggeber war das Institut für Dampf- und Gasturbinen der RWTH Aachen, bestand die Anforderung, den Rechner wegen der einstreuempfindlichen Sensoren nahe an das Meßobjekt heranzubringen, dabei aber in diesem Labor keine Diskettenlaufwerke (Festplatten gab es in diesem Marktsegment noch nicht) einzusetzen, da diese den Lärm/Druckwellenpegel und den Ölnebel nicht vertrügen. Wir haben 2 Maschinen geliefert. Die im Backend hatte ein normales Disketten-BIOS und lud einen Extender, der auf Kommandos der seriellen Schnittstelle lauschte, das Frontend hatte ein an den Extender angepasstes BIOS und kommunizierte sämtliche IO-Anforderungen über die serielle Leitung. So lief das BDOS und das Anwenderprogramm auf dem Frontend und wickelte die Massenspeicher- und Konsolen-IO über das Backend ab. Der Bediener saß bequem am Backend, hinter der Tür brüllte die Turbine.

Eigentlich ein Vorläufer von VmWare oder Network Attached Storage.

FORTH
Forth als ultrakompakte Interpiler-Hochsprache (mit RPN-ähnlicher Postfix-Notation) erregte mein Interesse, ich habe mich eine Weile damit beschäftigt.
Ein Studienfreund hat damals mit ELSA eine Terminalkarte herausgebracht, die auch schwarz-weiß-Vollgrafik konnte : TIPS 100. Um nicht Pixeldaten über die viel zu langsame serielle Schnittstelle zu übertragen, habe ich einen FORTH-Interpiler mit Grafikprimitiven geschrieben, mit dem die Grafikkommandos in Hochsprache abgesetzt werden konnten:
1 paintcol 10 10 50 60 drawline
malte z.B. eine Linie aus weißen (Farbe 1 in paintcol) Pixeln von Koordinate (10,10) nach (50,60)
Das ganze gibt es erheblich verfeinert heute noch : PostScript, die elementare Druckdatenbeschreibungssprache, ist im wesentlichen ein FORTH-Dialekt
Medizinische Meßtechnik - Intrazelluläre Aktionspotentiale
Im Auftrag des Institutes für Pharmakologie an der Universität zu Köln entwickelte ich einen mehrkanaligen Transientenrecorder auf Z80-CP/M-Basis : Der erste Kanal hatte 2 Abtastphasen, 100k Abtastungen/sec [ksps] für die schnelle Depolarisationsphase (intrazelluläres Aktionspotential) des zu untersuchenden Muskelgewebes, danach 10ksps für die erheblich langsamere Reoplarisation. Der zweite Kanal tastete mit 4ksps den Kraftsensor, der die Muskelkraft maß, ab. Mit diesem Setup passten die Daten einer Messung in die 32 kByte verfügbaren Speichers.
Medizinische Meßtechnik - Akustisch evozierte Potentiale
Im Auftrag des Institutes für Physiologie an der Universität zu Köln mußten schwache Potentiale gemessen und über viele Zyklen gemittelt werden. Dazu habe ich eine Speicherkarte entwickelt, die Meßdaten entgegennimmt und mit den bereits gespeicherten Werten autonom verrechnen kann, sozusagen ein kleiner spezieller Vektorrechner. Die Steuerungslogik dieses Projektes basierte auf der oben beschriebenen Sprache STATE zur Beschreibung und bearbeitung von Zustandsautomaten.
Alarmierungssystem für Großrechner
ELSA hatte für eine Firma APOLLO-Computer eine Box entwickelt, die aus einer Z-80-Universalprozessorkarte, einer Notstromversorgung und einem damals hochmodernen 300-Baud-Modem bestand, sie erhielt Daten von einer Applikation auf dem Großrechner. Damit konnten Stromausfälle, Zeitüberschreitungen von Rechnerjobs oder auch Jobendenachrichten erkannt werden. Auf solche Ereignisse hin sollte jeweils ein hinterlegter Operator per Telefon angerufen werden, eine Jobverwaltung fütterte also eine Anrufverwaltung. Die Verwaltungssoftware habe ich geschrieben, sie dazu bediente sich meines Echtzeitkernes OSIRIS. Bei einer Installation dieser Box bin ich auch einmal in die heiligen Hallen des NIXDORF-Rechenzentrums in Paderborn gelangt. Spätere Versionen nutzten ein Sprachausgabe / DTMF-Eingabesystem von SpeechDesign, noch später wurde das System eingesetzt, um BTX-Seiten periodisch testweise abzurufen und bei deren Nichtverfügbarkeit den Operator zu alarmieren.
Medizinische Meßtechnik - Vielkanalerfassung
Wieder für die Uni Köln wurde ein Meßsystem entwickelt, welches 256 Kanäle gleichzeitig mit 1000 Samples /sec mit 8 bit abtasten konnte. Der Prozessor spielte nur noch eine Rolle bei der Datenkommunikation, der eigentliche Meßdatentransfer in den 1MB großen Speicher lief per DMA
Power-FET-Switchmode-Technologie
Mit der Verfügbarkeit von Power FET-Transistoren (HEXFET, International Rectifier) und schnellen Dioden wurden hochfrequente Schaltnetzteile praktikabel. Geräte kleinerer Leistung habe ich u.a. für ELSA entwickelt. Als Diplomarbeit habe ich dann einen drehstromgespeisten Pulsgenerator mit Leerlaufspannungen bis zu 300V gebaut, welcher einstellbare rechteckige Strompulse von bis zu 10A und Pulsweiten herunter bis zu 100ns liefern konnte. Mit diesem Pulsgenerator wurden im Werkzeugmaschinenlabor der RWTH die Ursachen für den Erosionswerkzeugverschleiß untersucht.
Medizinische Meßtechnik - Vielkanalerfassung (1993)
Wieder für die Pharmakologie in Köln habe ich das Nachfolgesystem für HAL3 entwickelt, die 4 Sekunden Meßzeit reichten nicht aus, um komplette Arrythmieereignisse zu speichern. Das System besteht aus einem Frontend, welches die Daten erfaßt und in einem 32MB großen Speicher ablegt. Ein Backend-PC unter Linux, über ein 10Base2-Ethernet ans Frontend gekoppelt, steuert die Funktionen und ruft die Meßdaten ab. Zusätzlich zur reinen Datenerfassung wurde auch Auswerte- und Präsentationssoftware geliefert. Frontendsoftware in x86 Assembler und C, Backend in C, GUI in tcl/tk sowie native X11-Software in C
SCADA - Berliner Wasser Betriebe (1987-1995)
Für die Berliner Wasser Betriebe, Bereich Abwasserentsorgung, habe ich von 1987 - 1995 mit Mitarbeitern ein System zur Verteilung von Meßdaten entwickelt : Das System bestand aus VME-Unix-Rechnern als Netzknoten. Diese Netzknoten standen in den Kopfstationen der Abwasserpumpwerksgruppen, einer stand noch in der Zentrale. Jeder Netzknoten hatte ein LAN- und mehrere WAN-Anschlüsse und fungierte u.a. als Router. Weiterhin hatten alle Knoten in den Kopfstationen eine Kommunikationsverbindung zu einer Gruppe von SPS, je eine SPS in jedem Pumpwerk. Die Beobachtungs- und Bedienstationen waren PC mit einer speziellen Grafikkarte die über das jeweilige LAN auf den Netzknoten zugreifen konnten.
Um jedem PC Zugriff auf jedes SPS-Meßdatum zu ermöglichen und trotzdem zu vermeiden, daß Meßdaten mehr als je einmal auf einer der kapazitätskritischen WAN-Verbindungen übertragen wurden, wurde auf jedem Netzknoten ein Meßdaten-Routerprozeß gestartet, an dem sich die PC als Datenverbraucher anmelden konnten, ebenso meldeten sich die Nachbar-Netzknoten als potentielle Datenquellen und -senken an. Ein eventueller lokaler SPS-Koppelprozeß meldete sich an diesem Routerprozeß als Datenquelle an
Forderte ein PC ein Meßdatum an so ermittelte der Prozeß, welcher der angemeldeten Prozesse - ein Nachbarknoten oder der lokale SPS-Prozeß - das Datum liefern konnte, forderte es von dort an und trug es in seiner Tabelle die Datenquellen/Senkenverbindung ein.
Nachfolgende Meßdatenlieferungen wurden an die angeschlossenen Datenverbraucher ausgeliefert.
Forderte ein weiterer lokaler Datensenkenprozeß (PC) eine bereits unterstützte Variable an, so wurde er nur als weitere Senke in der Variablenliste eingetragen und erhielt ab da alle Aktualisierungen dieser Variable, ohne daß auf den Weitverkehrsstrecken mehr Last entstand
Aus diesem Verhalten stammte auch der Arbeitsname NTO des Projektes - Network Transport Optimizer
Auf den PCs waren einzelne Prozeßschaubilder mit Hintergrundbild, Symbolgrafiken Skripten und Variablenlisten hinterlegt. Beim Öffnen eines Prozeßschaubildes wurde die Liste der benötigten Variablen beim lokalen Netzknoten abgefordert, die eintreffenden Meßdaten triggerten Skripte, die z.B. Symbolbilder austauschten (Schieber offen statt Schieber geschlossen) oder Meßwerte in vorbereiteten Feldern darstellten, Farbumschläge markierten Betriebszustände.
Später wurde das System um Zusatzprozesse zum Berechnen von abgeleiteten Prozeßvariablen erweitert. In 1995 wurde ein neu von den BWB eingesetztes STEP-7/SUN -basiertes System von SIEMENS mit angeschlossen, da die Siemens-Lösung die nicht-lokale Anzeige von Prozeßdaten noch nicht unterstützte.
Steuerung für die chemische Industrie
In der Endzeit des Eisernen Vorhangs erhielten wir einen Auftrag, eine Anlage mit 5 Produktionslinien zur Herstellung von Emulsionspolymeren zu automatisieren : Wäge, Mischprozesse, danach Führung der Polymerisationsreaktion mit Temperaturregelung und kontinuierlicher Monomerdosierung, abschließend Kühlung, Filterung und Abpumpen des Produktes ins Produktlager.
Wir waren Subunternehmer eines Exportunternehmens welches wegen zufriedenstellender Vorprojekte und einem deutlich anderen Preisniveau als dem anderer Prozeßtechnikanbieter den Zuschlag bekam - wegen der strengen Devisenbewirtschaftung war Wirtschaftlichkeit oberstes Gebot.
Für den Leitrechner, welcher die Lagerverwaltung und -abrechnung sowie die Datenspeicherung und Rezepturverwaltung übernahm, kam UNIX V.4 auf 68040/VME der Firma FORCE zum Einsatz, jede Prozeßlinie wurde mit einem 68040/VME-Rechner unter PDOS, einem kleinen Echtzeitsystem, mit Prozeßperipherie ausgestattet.
Unter meiner Leitung entstand ein objektorientiertes, verteiltes Steuerungssystem. Jede Komponente der Anlage ist als Objekt modelliert, kann mit Nachrichten angesprochen werden und antworten.
Die verschiedenen persistenten Objekte sind in Objektmanager-Prozessen instantiiert, in welchen die Logik (Methoden) der Objekte realisiert war. Low-Level-Objekte in Assembler, Hi-Level-Objekte in FORTH. Jeder Objektmanager liste bei Start seine Instanzentabelle, welche z.B. für einfache Ventile aus Objektname, Steuerbit, Polarität, Stellungsfühlerbit, dessen Polarität sowie den Anfangszustand enthält und instantiiert damit die Objekte.
Ferne (auf einem anderen Knoten instantiierte) Objekte werden durch einen Netzwerk-Objekt-Manager auf dem betrachteten Knoten vertreten, welcher die Objektnachrichten per Netzkommunikation zum Netzwerk-Objekt-Manager des Knotens, auf dem das Objekt instantiiert ist, weiterleitet.
Fertigungschargen sind als transiente Objekte angelegt, welche bei Chargenstart instantiiert und bei Chargenende gelöscht werden.
Grafische Benutzeroberflächen waren damals teuer und unausgereift, wir haben eine CURSES-ähnliche Benutzeroberfläche geschaffen. Objekte können rechteckige, mit Ein-und Ausgabefeldern versehene Bedienpanels anlegen und dem Screenmanager bekanntmachen. Ein mit dem Screenmanager verbundenes ASCII-Terminal kann diese Panels beliebig stapeln und verschieben, das oberste Panel hat immer den Focus. Ein Bediener kann sich so z.B. seine Charge und den dazu gehörigen Temperaturregler gleichzeitig sichtbar auf den Schirm holen.
Der Temperaturregler hat auch eine applikationsspezifische Besonderheit zu bieten: Eine kritische Phase der Reaktion ist der Start der Polymerisation. Nachdem die initale Wasser+Radikalbildner+Tensid-Füllung des Reaktors auf Solltemperatur hochgeheizt ist, beginnt die kontinuierliche Dosierung des kalten Monomers. Bei ca. 60 K Temperaturdifferenz zum Reaktor und 0.5kg/sec benötigt der Reaktor ca 40 kW Heizleistung, um seine Temperatur zu halten. Sobald die Polymerisation startet, liefert diese annähernd 100kW, so daß netto 60 kW abgeführt werden müssen. Der Reaktor ist mit einem Heiz/Kühlwassermantel umkleidet, dessen Solltemperatur vom eigentlichen Reaktor-Temperaturregler vorgegeben wird. Erschwerend kommt hinzu, daß der Reaktor nach je ca 10 Chargen gereinigt wird, in frühen Chargen dieses Zyklus ist der Wärmewiderstand zwischen Wassermantel und Reaktorinhalt niedrig und steigt mit jeder Charge ohne Reinigung an - der Regler trifft also auf recht unterschiedliche Bedingungen.
Wir messen daher in der Aufheizphase der Startfüllung die Aufheizgeschwindigkeit und ermitteln daraus den aktuellen Wärmewiderstand, dieser fließt auch in die I- Zeitkonstante des Reglers ein.
Zum Start der Dosierung greifen wir in den I-Teil des Hauptreglers ein und stellen dort eine Soll-Temperatur ein, die passend zum Reaktorzustand annähernd die benötigten 40 kW Wärmeübergang liefert. Sobald wir den für den Polymerisationsstart typischen steilen Temperaturanstieg beobachten, greifen wir erneut ein und belegen den I-Teil mit der Wassermantel-Temperatur vor, die für die Abfuhr der netto 60kW erforderlich ist. Damit halten wir das geforderte enge Temperaturprofil problemlos ein.
AIX-basiertes Telex-Front-End für den Interbanksektor
Echtzeitsystem für hyperstone-Prozessor
Die Architekten der Nixdorf-Prozessoren, Otto Müller mit seiner Frau Ilse, schufen 1990 einen genialen 32bit-Prozessor, den hyperstone. Eine befreundete, als Ausgründung von ELSA entstandene Firma, intercope electronics, nutzte diesen, um eine aktive ISDN-Karte zu entwickeln, die aus der hohen Rechenleistung extrem hohe Kompressionsraten in den Datenkanälen realisierte, was bei 64kbit/s-B-Kanälen sehr deutlich wurde.
Den angeblich portablen Echtzeitkern von hyperstone haben wir nie auf unserer Hardware zum laufen bekommen, also habe ich einen Kern nach meinen OSIRIS-Konzepten auf dieser ungewöhnlichen Architektur (gecachte Registersätze mit variabel großen Registerframes, dadurch so gut wie kein Load-Store-Overhead für calls, eine so einfache wie geniale Timerstruktur) implementiert. Interrupt-Antwortzeiten von wenigen Mikrosekunden, Timerauflösung von einer Mikrosekunde, keine Timer-Fehlerverschleppung, und das 1992 mit 40MHz Takt, waren das grandiose Ergebnis.

Für dieses System habe ich dann auch eine Protokollstack-Architektur entwickelt, die es ermöglichte, dynamisch Protokollstacks für einzelne Verbindungen nach Art des OSI-Schichtenmodells aufzubauen. Einzelne der Protokollmodule wie z.B. X.75, oder auch die Gerätetreiber der ISDN-Chips habe ich dann auch implementiert. Den Hyperstone Prozessor gibt es als Intellectual Property bei einem fabless Hersteller immer noch

Technologietransfer mit indischem Partner
Für eine befreundete Firma habe ich in 1993 und 1994 versucht, komplexe Engineeringaufgaben von gut ausgebildete Teams im 'Billiglohnland' Indien bearbeiten zu lassen. Obschon grundsätzlich erfolgreich ergab sich, daß der Aufwand dafür nicht zu unterschätzen ist - es bedarf dauerhaft eines 'Wanderers zwischen den Welten', der sowohl die Problematik und die Rahmenbedingungen der Realisierung durchgängig versteht als auch mit beiden Seiten barrierefrei kommunizieren kann. Zusammen mit der zwangsläufig etwas geringeren Effektivität einer solchen geteilten Entwicklung wird ein solches Konstrukt erst ab einer gewissen Projektgröße wirtschaftlich.
Software-Zulieferer für ELSA
1995 hatte ELSA, ein Aachener EDV-Hersteller, der von der Industrieelektronik kommend mit PC-Grafiksystemen und Datenkommunikation groß geworden war, einen frühen ISDN-Router auf Basis zweier gekoppelter 80188 im Programm. Für embedded-Produkte mußten andere Plattformen her, Intel bediente mit seinen x86 Prozessoren einen ganz anderen Markt. Die Wahl fiel auf den Hitashi SH2, einen leistungsfähigen RISC-Prozessor. In dieser Plattformumstellung habe ich das Cross-Development auf Basis der gcc-Compilersuite unter Linux eingeführt, um die Vorteile einer unixoiden make-Welt für das Cross-Development zu nutzen.
In einer Arbeitsgruppe mit ELSA-Mitarbeitern habe ich dann die neue Software-Architektur der ISDN-Produkte mit eigenem Prozessor spezifiziert.
Auf diese Architektur angepasst habe ich dann mein OSIRIS-Betriebssystemmodell mit passenden Schnittstellen versehen und für SH2 implementiert. Es erhielt den Namen IOS.
Auf dieser Plattform wurde als erstes Produkt der Router Lancom 1000 realisiert. Ein Versuch brachte folgendes Ergebnis : Es wurde eine Serie von 1000 ping-Paketen auf den Router per 10-base-T Ethernet abgesendet. Der alte, 188-basierte Router, beantwortete 40, ein Konkurrenzprodukt 65 Pakete, der Lancom 1000 beantwortete alle!
In der Weiterentwicklung der Modems und der ISDN-Kombisysteme (Router + Telefonanlage in einem System)wurde CLIP, die Anzeige der Rufnummer des Anrufers auf dem gerufenen Telefon eine geforderte Funktion. Die notwendige Implementierung einer V.23 Modulation habe ich auf Basis von DDS-Algorithmik realisiert. Die gemeinsame Funktion einer Box als ISDN Router und - Telefonanlage wurde leider später fallengelassen.
Mit steigenden Stückzahlen der Consumerprodukte entstand die Idee, einen ELSA-spezifischen Controller mit Maskenrom anfertigen zu lassen, auf dem eine große Palette von Produkten, wie Modems, Terminaladapter, Router aufgesetzt werden konnten. Im Maskenrom sollten Funktionen enthalten sein, mit denen unabhängig vom hergestellten Produkt Fertigungstests und initales Laden einer Firmware möglich sein sollten. Dazu habe ich eine Laderarchitektur mit bedinger Verzweigung entwickelt. Man konnte ein externes serielle Rom mit 3 Kontakten (RESET,CLOCK,DATA) anklemmen und damit in einem Schritt nach der Platinenfertigung den initalen good/bad-Test, einen tiefergehenden Test und das Programmieren der Firmware realisieren.
Der Dienstleister erhielt keinen tieferen Einblick in die ELSA- Technologie als unbedingt nötig, insbesondere keine Sourcen. Firmwareupdates oder Erweiterungen des Testumfanges für die laufende Fertigung wurde durch Austauschen des Roms der Teststationen realisiert, keine fehlerträchtigen Kopier- und Zusammenstellaktionen beim Dienstleister.
Mit dem Zusammenbruch der ELSA - sie hatte in ihrem volumenstärksten Segment, den Grafikkarten, den Markt falsch eingeschätzt, wurde diese Technologie dort nicht mehr eingesetzt. Der Datenkommunikationsbereich von ELSA lebt aber weiter, als DEVOLO für den Consumer- und LANCOM für den Routerbereich.
AIRBUS : Mitarbeit an AFDX, 1998
Ein engagierter Mitarbeiter bei Airbus begann die Idee, 100baseTX Ethernet als Bussystem in Luftfahrzeugen einzusetzen, auch in den entsprechenden Normierungsgremien voranzutreiben. Wir haben anfangs in etlichen Sessions einige der heute in AFDX realisierten Mechanismen, wie z.B. tabellengesteuertes Multicasting im Switch oder die Verkehrsklassen mit ihren getrennten Link-Last-Kontingenten zur Vermeidung von Buszusammenbrüchen entworfen. Nachdem so ein machbar erscheinendes Grundkonzept zusammen war, bekam ich den Auftrag, ein Demonstratorsystem dazu zu realisieren. Dieses bestand aus ein paar Datenquell(Joystick)- und Senken(gesteuertes Fadenkreuz)applikationen, passenden Statistikdisplays (Frame Rate, Latency ..) sowie den zu simulierenden AFDX-Switches als Linux-Kernelmodule. Diese hatten virtuelle Netzwerkports für lokale Datenquellen und -senken sowie physische Ports (DEC 21140 TULIP für gute Performance) für inter-node-Kommunikation.
Das gesetzte Ziel wurde erreicht - das Gefühl zu vermitteln, daß Ethernet, welches generell vom Hauch der Unzuverlässigkeit umweht wird, trotzdem für die Backbonekommunikation eines Flugzeuges geeignet ist.
Aufgrund politischer Entscheidungen bei Airbus - Frankreich bemüht sich erheblich stärker, Technologieführerschaft zu erlangen als Deutschland - wanderte die AFDX- Weiterentwicklung zu Thales. Inzwischen fliegt diese Technik - im A380.
LXCO : Entwicklung einer Network-Attached-Storage-Appliance
Der Fluch der Quartalsberichterstattung : MYLEX, der bekannte Hersteller von RAID-Subsystemen, hat nach ein paar schlechten Quartalen eine interessante Entwicklung auf Eis gelegt und die Mitarbeiter entlassen: Ein System, welches Festplatten im Netz verfügbar macht, heute allgemein als NAS (Network Attached Storage) bekannt. Nun soll diese Entwicklung als Joint Venture mit dem deutschen Distributor Lobster in Deutschland weitergehen. Dieses Joint Venture wird als LXCO aus der Taufe gehoben, ich fliege zur Ist-Zustandserhebung nach Kalifornien.
Für das geplante Projekt existieren 2 Hardwareplattformen, Intel 960 und PowerPC, beide mit mangelhafter Hardware-Entwicklungsdoku und unbrauchbarer Software. Entwickelt wurde unter VxWorks, als NAS-Applikation soll eine von CrosStor, einem Sun-Spinoff zugekaufte Software laufen.
In Berlin wird die neue Entwicklungstruppe hochgezogen, ich leite die Softwareentwicklung, im Frühjahr 99 holen wir die Assets aus Kalifornien.
In mehreren mehrwöchigen Sessions bei CrosStor versuche ich erfolglos, die Software stabil zu bekommen - unmöglich. Die Unterstützung von WindRiver, dem Hersteller von VxWorks, bei der Portierung seines Systems auf die inzwischen erneuerte PowerPC Plattform ist nahe null, die Dokulage zur Unterstützung bei der Erstellung eines eigenen sog. Board-Support-Packages erschreckend mau.
Zwischenzeitlich wird MYLEX von IBM geschluckt - dort braucht man deren RAID-KnowHow. Um einen Interessenskonflikt mit der IBM Boulder - die auch gerade an NAS arbeitet - zu vermeiden schenkt IBM seine Anteile an Lobster. Schön für Lobster, leider sind wir damit den Marketing-Kanal los.
Wegen der Probleme mit WindRiver entscheiden wir, den eigenen Realtime-Kern einzusetzen und die Handvoll an benötigten Calls ins VxWorks zu emulieren. Das erhöht unsere Chancen bei der Fehlersuche in der CrosStor Applikation massiv, sind wir doch jetzt Herr der Systemressourcen. Trotzdem stürzt das Zeug weiter ab, auf jeden in der Source erkannten und nachgewiesenen Fehler hin werden wir mit einem neuen Release beworfen, welches andere Fehler macht. Noch verhallen meine Vorschläge, doch Linux zu portieren und mit SAMBA als NAS anzubieten ungehört.
Das ändert sich : CrosStor will massiv Geld, ein Termin ist abgelaufen und wir haben nicht gekündigt. Da wird CrosStor zur Marktbereinigung des Speichermarktes von EMC gekauft. Daher bietet man uns an, aus dem Vertrag mit CrosStor auszusteigen - ohne weitere Zahlung. Nun kommt mein Vorschlag mit Linux besser an.
Inzwischen ist die DotCom-Blase geplatzt, Lobster verabschiedet sich mit einem hässlichen Konkurs aus der Realität. Der Käufer der Lobster ist eigentlich nur am Verlustvortrag und dem ihm persönlich bekannten Hardwareentwickler interessiert. Trotzdem bekommen wir die Linux-Version zum Laufen, das ist aber dann nicht mehr das Business der LXCO...
Skills : Debugging in fremden Systemen, Linux Portierung, produktive Arbeit in US-English, Perl ...
AIRBUS : Anpassungsmodul zwischen Luftfahrtdatenbus ARINC429 und TTP für Kabinendruckregelung
AIRBUS Deutschland ist noch Systemführer für Klimatisierung. In Flugzeugen wird kontrolliert Zapfluft aus den ersten Verdichterstufen zum Belüften der Flugzeuge eingesetzt, die Druckregelung geschieht auf der Auslassseite mit sogenannten Outflow-Valves, die bei Airbus beidseitig am Heck sind. Eine Arbeitsgruppe möchte ihr Regelungssystem mit dem ARINC3000-Simulator, den Airbus gekauft hat, betreiben. Dazu gibt es PCI-Interfacekarten für den ARINC429-Bus, die Treiber laufen unter RTLinux.
In diesem Projekt schreibe ich einen RTLinux Kerneltreiber, der zwischen der ARINC4219-Karte und dem TTP (Time Triggered Protocol)-Interface, an dem die Ventilsimulation hängt, den Datentransfer bewerkstelligt.
Entwicklung eines Sandstrahlautomaten für ALMAG
Für die mittelständische Präzisionsdreherei ALMAG Präzisionstechnik habe ich einen Sandstrahlautomaten mit einer 2-D-Steuerung entwickelt, mit dem gedrehte und gefräste Flachstrahldüsenrohlinge im Düsenspalt mit reproduzierbarem Abtrag entgratet werden. In diesem Projekt habe ich Maschine und Steuerung entwickelt.
Zwei Hartmetall-Strahldüsen fahren auf einem Kreuztisch mit IGUS-Lineargleitlagern, der über Faltenbälge annähernd staubfrei gehalten wird und bearbeiten dort die in einer 10x10-er Matrix eingelegten Düsen. Die Anlage ist unterdruckbeaufschlagt, um die Freisetzung von Strahlmittelstaub zu minimieren. Antrieb erfolgt über getriebeuntersetzte 5-Phasen-Schrittmotoren, die von einem Mehrachsen-Schrittcontroller am Parallelport eines PC getaktet werden. Auf dem PC läuft RTLinux, welches sicherstellt, daß der im Kernel laufende Motion-Controller regelmäßig Rechenzeit bekommt. Der Motion-Controller verbraucht ca 2% der Rechenzeit einer 1GHz CPU.
Die Programmiersprache zur Bewegungssteuerung ist an DIN 66025 angelehnt, mit Erweiterungen für Unterprogrammaufrufe.
Portierung IOS auf ARM7
Aus der Insolvenz der ELSA AG 2002 ist durch Management-Buyout die LANCOM GmbH entstanden, die das Geschäft mit professioneller Datenkommunikation weiterführt. Teil der von ELSA übernommenen intellectual Property ist die Betriebssystemplattform IOS. LANCOM plant eine neue Produktreihe mit einem Prozessor, dessen Ahnen Intel mit der Übernahme von DEC erworben hatte - den StrongARM IXP425. Für diese neue Plattform habe ich für LANCOM Bootlader und Echtzeitkern entwickelt.
IT-Unterstützung für die Rügen Fisch Gruppe
  • Administration von Win-NT und Linux-Servern
  • Betrieb von Mail-Servern
  • Pflege und Weiterentwicklung der IT-Landschaft
  • Aufbau und Pflege von WLAN-Netzen, internen Firewalls, etc
  • Virtualisierung von Altsystemen
  • Anwenderunterstützung
  • Support bei Fehlern der STEP7-Steuerungstechnik
  • Netzwerk-Anbindung und Fernwartung von Tochterunternehmen
  • Entwicklung und Betrieb von Auftragsannahme und Rechnungsversand nach EDIFACT
  • Entwicklung und Betrieb einer integrierten Lösung für Kreditversicherungsüberwachung und Factoring-Datenkommunikation
  • Entwicklung und Betrieb von Barcode-Identifikation der Fertigprodukte
  • Entwicklung und Betrieb scannergeführter Produktionssteuerung für manuell hergestellte Produktgruppen
  • Entwicklung und Betrieb einer Tourenplanungslösung
  • Vorbereitung einer Lösung für elektronische Lieferscheine
  • Entwicklung scannergeführter Kommissionierung im Lagerbereich
  • Entwicklung und Betrieb einer Produktrückverfolgungslösung
  • Entwicklung und Betrieb einer Energieoptimierung zur Reduktion von Lastspitzen im Energieversorgungnetz
  • Erweiterungen der vorhandenen ERP-Lösung mittels Web-Technologie

Skills :

  • IT-Administration
  • Mail, Spamfilterung, postfix
  • Oracle, SQL
  • Netzwerke, Router
  • Virtualisierung, VmWare, KVM
  • APACHE, CGI, Perl
  • EDIFACT : INVOIC, ORDERS, DESADV, PRICAT etc
  • Hardwareentwicklung Scannerterminals, ATMEL AVR
  • SPS, STEP7, SCADA

Pflege und Weiterentwicklung einer Broadcast-Fax und -Mail Lösung bei der Deutschen Telekom

Mail, SCO Unixware, Linux, Perl

Modernisierung des 256-Kanal-Biomapping-Systems, Prof. Dr. Dhein, Herzzentrum Leipzig

Systems-On-A-Chip, VHDL, ALTERA CYCLONE + MAX FPGA / CPLD

CERP : ERP mit Projektverwaltung
Entwicklung, Einführung und Betrieb einer kundenspezifischen ERP-Lösung mit Projektplanung und -abwicklung für REWAsolar
  • Verwaltung von Warenbestand und Warenzulauf, Zuordnung von vorhandener oder kommender Ware zu Projekten, Lieferscheine, Warenstorni, Inventuren
  • Übernahme von XML-Stücklisten aus externem Planungsprogramm mit Artikelnummernmapping der Fremdartikel
  • Verwaltung von externen Dienstleistungsaufträgen mit Terminkoordination zu Projektterminen
  • Kostenzuordnung zu Lagerware / Projekten
  • Datenexport zu Fibu/Steuerberater
  • Faktura mit Sonderfällen (Abschlagsrechnungen, §13b UStG etc)
  • Integriertes Dokumentenmanagement
  • Controlling und Berichtsfunktionen
  • Projektbezogenes Kommunikationsjournal
  • Provisionsverwaltung
  • Seriennummernverwaltung
  • Realisierung als LAMP-Applikation in Perl
  • Fernzugriff durch ssh-Tunnel
  • .. to be continued