Meine Selbstständigkeit ist von zwei Seiten geprägt.
Auf der einen Seite hab ich große Projekte die über Vermittler an mich herangetragen werden und die über ein Jahr hinauslaufen. Dort wird die komplette Entwicklungsumgebung vom Kunden vorgegeben und meine Tätigkeit besteht im wesentlichen darin seine Wünsche und Vorstellungen umzusetzen bzw. beratend zur Seite zu stehen.
Diese Projekte sind in dieser Liste als eigene Punkte eingetragen.
Auf der anderen Seite hab ich meine eigenen Projekte, für einen eigenen Kundenstamm. Damit fülle ich die Übergangszeiten auf bzw. widme mich ihnen wenn mir mal nicht nach "in der Fremde sein" ist. Und dort entscheide ich frei über die Umsetzung und wie ich die Anforderungen erfülle.
Diese Projekte fasse ich hier einfach nur global zusammen.
Aus Erfahrung heraus habe ich dort immer Oberfläche und Businesslogik/Funktionalität in zwei verschiedenen Programmiersprachen entwickelt um zum einen sauber zwischen beiden zu trennen und beide auch getrennt testen zu können.
Das war im Anfang Turbo Pascal, später mit Turbo Vision, dann im Übergang Borland Delphi als Oberfläche und Borland C/C++ für die Businesslogik/Funktionalität.
Als ich angefangen habe diese Kunden von Windows weg auf Linux umzustellen mussten die Anwendungen folgen. An anfänglichen Versuchen mit Kylix (Delphi für Linux) stelle ich in den letzten Jahren bei Neuentwicklungen verstärkt auf Python als Programmiersprache für die Oberfläche um. Als Bibliothek für die Oberfläche in Python kommt, jenach Projektkontext, entweder pyQT für reine Python-Projekte bzw. wxPython für Mischprojekte mit C/C++ zum Einsatz.
Die Businesslogik/Funktionalität ist wie gehabt in C/C++. Zwischendurch gab es Experimente mit Visual C++ bzw. C#, aber auch hier war Linux die treibende Anforderung um C# fallen zu lassen, dafür aber zusätzlich auch auf GCC umzusteigen.
Aktuell gesellt sich zusätzlich Embedded LUA zu C/C++ hinzu um die Logik/Funktionalität um dynamische Anteile zu erweitern die zur Laufzeit aus der Datenbank nachgeladen werden. Das ist aber noch im Experimentierstadium da noch nicht wirklich klar ist wie zb. Revisionssicherheit garantiert werden kann.
Als
Datenbank nutze ich, soweit möglich, PostgreSQL wegen der schönen
Pythonanbindung.
In den letzten Jahren setze ich verstärkt ein selbstgeschriebenes Netzwerk aus Mikroservices ein um die Aufgaben besser zu kapseln und zu verteilen. Das Netzwerk ist broker-less und resilient gegen Unterbrechungen und damit auch geeignet verteiltes Arbeiten über das Internet bzw. das Anbinden von Außenstellen zu ermöglichen.
Eine existierende C-Bibliothek sollte zusätzlich zur existierenden seriellen Kommunikation mit der Hardware eine moderne USB-Anbindung bekommen. Durch unterschiedliche State-Engines in der Kommunikationsschicht und zur Vereinfachung der Wartung wurden es dann aber doch zwei verschiedene Libraries mit gleicher Schnittstelle. Dadurch konnte die USB-Variante dann aber auch direkt nach Linux portiert werden. Für Testzwecke wurde dann noch dafür eine Oberfläche in Python3 mit PyQT geschaffen.
Diese war dann so erfolgreich das nach und nach Teile der gesamten Suite oberhalb der Hardware weg von C/C++ hin zu Python3 umgestellt wurden.
Für einen Kunden mit besonderen Anforderungen an die Anbindung an die Produktion und deren Darstellung und Abrechnung hatte ich vor Jahren eine Python 2.x basierte Anwendungssuite geschrieben. Diese war auf Python 3.x umzustellen.
Außerdem erfolgte die Kommunikation zwischen den einzelnen Modulen dort über die gemeinsame Datenbank was langsam und umständlich war. Dieser Layer wurde komplett durch eine peer-to-peer ähnliche Kommunikationsschicht ersetzt die wesentlich schnellere Reaktionen ermöglichte. Außerdem konnten viele Teile der Geschäftslogik in sog. nano services verschoben werden.
Dadurch konnten die Hardwareanforderungen so weit gesenkt werden das die Lebensdauer der Hardware um mindestens 5 Jahre verlängert werden konnte. Das ist gerade im Bereich der maschinennahen Steuerung ein großer Erfolg.
Zusätzlich sind einzelnen Teilmodule leichter zu warten und können bei Bedarf leichter mit den Anforderungen wachsen in dem man sie z.B. einfach mehrfach startet.
Eine lange geplante Pause nach dem letzten siebenjährigen Auftrag ging ansatzlos in die Quarantänezeit von Corona über. Ich habe in der Zeit mich um meine Eltern gekümmert die weit über 80 sind und in der Zeit hilfebedürftig waren.
Für ein international agierendes Maschinenbauunternehmen war der Build-Workflow neu zu organisieren. Das in Produktion befindliche System war auf die Anzahl der Projekte (In Summe über 1000 aktive Projekte die von mehr als 600 Entwicklern betreut wurden) und die heterogenen Entwicklungsumgebungen (Embedded, Win, *IX, Android etc.) nicht ausgelegt. Davon mussten ca. 250 jede Nacht gebaut werden. Der Austausch/die Erweiterung musste im laufenden Betrieb erfolgen.
Im Unternehmen waren wichtige Hilfsprogramme bereits in Ruby ausgelegt, ich habe daher entschieden die neue Umgebung auf Ruby aufzusetzen um das existierende Know-How zu nutzen. Aus meiner Erfahrung aus dem vorherigen Projekt hab ich ein Netzwerk von selbst-organisierenden Microservices geschrieben die Builds selbstständig in einem Grid von dedizierten Buildengines verteilt haben, deren Ergebnisse in ein übergreifendes Binärrepository eingliederten und diese damit übergeordneten Projekten als Artefakte bereitgestellt haben. Zugleich wurden entsprechende Anpassungen an Visual Studio, Gradle, Eclipse etc. vorgenommen um diese Builds dann auch lokal bereitzustellen. Zugleich enthielt das Repository auch alte Versionen und konnte mit dem Bugtracker zusammen mit aus dem Feld kommenden Traces Fehler-Umgebungen für alle Versionen der letzten Jahrzehnte wieder herstellen. Einer der letzten Schritte war die Erweiterung um CI gesteuert aus den Commits der Entwickler.
Zugleich hab ich den Second-Level-Support für die Entwickler bei Build- und Design-Problemen für C/C++, C# und Java übernommen.
Teile der von mir geschaffenen Umgebung wurden auf der HPC'10 präsentiert und mit großem Interesse aufgenommen.
Eine Windows-Applikation war nach 64Bit-*IX zu porten. Die Anwendung machte intensiven Gebrauch von MFC und anderen Windows spezifischen Bibliotheken und war über Jahre gewachsen. Die neue Version setzte auf das Reaktor-Konzept von ACE auf zur Socket-Kommunikation und als Message-Queue, Teile der alten Anwendung wurden durch Boost ersetzt, die Datenbank-Anbindung nutzte OCCI um mit Oracle zu reden. Desweiteren wurde DDS zur Kommunikation per Multicast eingesetzt bzw. SNMP zur Kommunikation mit der verteilten Hardware.
Stichworte: C++, Linux, MFC, Linux, Oracle, SNMP, ACE, Boost, DDS, OCCI
Eine vor Jahren von mir geschriebene C++/MFC-Windows-Applikation brauchte ein lang überfälliges Update. Das Design war insgesamt schon modular ausgelegt so daß ich einfach den "Motor" ausgebaut und die "Karosserie" durch eine Python/wxWidgets-Kombination ersetzt habe. Dadurch entfällt auch die Notwendigkeit von Windows Lizenzen und die Arbeitsplätze laufen jetzt von Ubuntu-BootCDs.
Die Anwendung verwaltet eine Datenbank und ist sehr dialoglastig. Zugleich enthält sie einige zeitkritische Auswertungen die das eigentliche Geschäftswissen enthalten.
Um später das Wissen bei der Wartung nicht offenlegen zu müssen war es in einem eigenen Projektteil untergebracht der in eine DLL mündete die später zur Laufzeit dynamisch eingebunden wurde.
Da außerdem abzusehen war das die Dialoge oft und gern angepasst bzw. übersetzt werden müssen wurden diese bereits damals in einer Beschreibungssprache kodiert, aus der Datenbank geladen und dann mit einem Interpreter als MFC-Dialoge aufgebaut.
Das Geschäftswissen und die zeitkritischen Teile in der DLL sind nach dem Umbau erhalten geblieben. Diese wurde mit SIP an Python angebunden. Der Interpreter für die Dialogstruktur wurde in Python komplett neu geschrieben, die Dialoge selber brauchten daher nicht angefasst zu werden. Anstatt MFC wird jetzt wxWidgets bzw. deren Python-Bindings wxPython benutzt.
Ich hatte auch überlegt die Anbindung über "boost.python" zu machen, aber die DLL sollte für das alte und das neue System identisch sein. Boost hätte in diesem Falle aber eine Anpassung des C++-Codes erfordert.
Die Portierung nach *IX erforderte nur eine Neuübersetzung des C++-Teils. Dafür brauchen jetzt 20 Arbeitsplätze, die vorher noch auf WinNT waren, keine Windows-Lizenz mehr.
Als Datenbank kommt SQLAnywhere zum Einsatz. Sie läuft auf einem alten Server der die Anforderungen neuerer Datenbanken nicht erfüllt. Das nächste Mal wenn zwischen zwei Projekten Zeit ist wird sie auf einen neuen Server verschoben und gegen PostgreSQL ausgetauscht.
Februar 2008
Basierend auf meinen Erfahrungen mit fli4l und eisfair eine schöne kleine Serverlösung mit DMZ und hotpluggable USB-Festplatten erstellt. Linux wird dabei von einer 16MB Compact Flash Karte gestartet, läuft in einer RAM-Disk und holt sich seine Konfiguration von einem eingesteckten USB-Stick. Damit kommt man einem Router mit embedded Linux so nahe wie möglich ohne die Erweiterbarkeit zu verlieren.
Stichworte: Linux, Embedded, Server, DMZ
Eine vom Unternehmen in Python selbst entwickelte Bibliothek zum Testen von embedded Komponenten und Bussystemen im Automobilbau war mit einer Oberfläche zu versehen. Als GUI-Bibliothek verwendeten wir wxPython.
Stichworte: Python, C, Embedded, wxWidgets, wxPython, PyRex
Basierend auf einer vom Kunden selbst-entwickelten Datenbank unter Windows und Linux. Entwicklung der Spezifikation um die Datenbank als verteilte Datenbank zu erweitern. Synchronisation und Replikation über TCP/IP über verschiedene Serverthreads.
Eine Meßstation ist über die serielle Schnittstelle an einen Industrie-PC angeschlossen. Dieser hängt über einer normalen DSL-Verbindung am Internet. Gesteuert wird die Meßstation über ein Java-Applet von jedem beliebigen Rechner mit Zugriff auf die Meßstation.
Drei Softwaremodule waren neu zu entwickeln, obwohl die Teile bereits aus einem vorherigen Anlauf bestanden: Die Software für die Station selber, den PC mit der DSL-Anbindung und das Java-Applet.
Die Station im wesentlichen besteht aus einer Standardplatine mit dem C167 als Prozessor, der mir schon aus vorherigen Projekten bekannt war. Für die Entwicklungsumgebung wurde vom Kunden die Software von Keil gestellt. Über einfache Funktionen werden die Daten gesammelt, komprimiert und im Speicher abgelegt. Besteht Verbindung zum Steuer-PC werden diese Pakete dann an den Steuer-PC übertragen.
Verschiedene Schwierigkeiten traten auf. So war unter anderem kein Multitasking möglich. Wir haben uns deshalb entschieden die Daten in eine Art Ringpuffer abzulegen aus denen der Steuer-PC einzelne Pakete abrufen kann, die wir dann in einem Burst zwischen den Messvorgängen senden. Außerdem verzichtete ich auf ein Acknowledge-Paket, sondern übertrugen mit jedem Paket die Indexnummern der noch vorhandenen Pakete und erwarten mit jedem Abruf eine Liste von Paketen, die wir löschen können. Der Steuer-PC überpüft die von ihm empfangenen Pakete und teilt bei fehlerfreiem Empfang solange den Wunsch auf Löschung mit, bis das Paket wirklich nicht mehr in der Antwort auftaucht.
Damit sind wir auch bei einen Ausfall des Steuer-PC auf der sicheren Seite da nur dieser Pakete löschen kann. Sollte der Steuer-PC die Daten nicht abrufen, dann werden die Pakete in drei Stufen nachbehandelt um Speicher zu sparen. Dabei gehen dann aber Daten verloren.
Für den Steuer-PC wurde Windows eingesetzt, da sich der Kunde für ein DSL-Modem auf Basis einer PCI-Karte entschieden hatte für die es nur Windows-Treiber gab.
Das Steuerprogramm habe ich in Python geschrieben. Alle notwendigen Teile zur Kommunikation mit der seriellen Schnittstelle und über TCP/IP sind bereits in den Standard-Libraries enthalten und die Entwicklung gestaltete sich deshalb sehr unkompliziert.
Für eine Variante der Hardware ohne DSL-Anschluss habe ich ein Verfahren entwickelt, die gespeicherten Daten automatisch alle 24h auf einem eingebauten CD-Brenner festhält. Dann ist ein Besuch nur jeden Monat notwendig.
Zur Fernsteuerung des Steuer-PC wird ein Java-Applet mit Swing-Oberfläche eingesetzt. Der Start des Applets verfolgt von einem beliebigen PC mit Internetanbindung über Webstart. Die aktuelle Konfiguration wird dann vom Steuer-PC geladen. Die IP-Nummer für den Zugriff wird über einen zentralen Server bei meinem Kunden ermittelt. Sie wird dort vom Steuer-PC nach jeder Neueinwahl abgelegt.
Meine Selbstständigkeit ist von zwei Seiten geprägt.
Auf der einen Seite hab ich große Projekte die über Vermittler an mich herangetragen werden und die über ein Jahr hinauslaufen. Dort wird die komplette Entwicklungsumgebung vom Kunden vorgegeben und meine Tätigkeit besteht im wesentlichen darin seine Wünsche und Vorstellungen umzusetzen bzw. beratend zur Seite zu stehen.
Diese Projekte sind in dieser Liste als eigene Punkte eingetragen.
Auf der anderen Seite hab ich meine eigenen Projekte, für einen eigenen Kundenstamm. Damit fülle ich die Übergangszeiten auf bzw. widme mich ihnen wenn mir mal nicht nach "in der Fremde sein" ist. Und dort entscheide ich frei über die Umsetzung und wie ich die Anforderungen erfülle.
Diese Projekte fasse ich hier einfach nur global zusammen.
Aus Erfahrung heraus habe ich dort immer Oberfläche und Businesslogik/Funktionalität in zwei verschiedenen Programmiersprachen entwickelt um zum einen sauber zwischen beiden zu trennen und beide auch getrennt testen zu können.
Das war im Anfang Turbo Pascal, später mit Turbo Vision, dann im Übergang Borland Delphi als Oberfläche und Borland C/C++ für die Businesslogik/Funktionalität.
Als ich angefangen habe diese Kunden von Windows weg auf Linux umzustellen mussten die Anwendungen folgen. An anfänglichen Versuchen mit Kylix (Delphi für Linux) stelle ich in den letzten Jahren bei Neuentwicklungen verstärkt auf Python als Programmiersprache für die Oberfläche um. Als Bibliothek für die Oberfläche in Python kommt, jenach Projektkontext, entweder pyQT für reine Python-Projekte bzw. wxPython für Mischprojekte mit C/C++ zum Einsatz.
Die Businesslogik/Funktionalität ist wie gehabt in C/C++. Zwischendurch gab es Experimente mit Visual C++ bzw. C#, aber auch hier war Linux die treibende Anforderung um C# fallen zu lassen, dafür aber zusätzlich auch auf GCC umzusteigen.
Aktuell gesellt sich zusätzlich Embedded LUA zu C/C++ hinzu um die Logik/Funktionalität um dynamische Anteile zu erweitern die zur Laufzeit aus der Datenbank nachgeladen werden. Das ist aber noch im Experimentierstadium da noch nicht wirklich klar ist wie zb. Revisionssicherheit garantiert werden kann.
Als
Datenbank nutze ich, soweit möglich, PostgreSQL wegen der schönen
Pythonanbindung.
In den letzten Jahren setze ich verstärkt ein selbstgeschriebenes Netzwerk aus Mikroservices ein um die Aufgaben besser zu kapseln und zu verteilen. Das Netzwerk ist broker-less und resilient gegen Unterbrechungen und damit auch geeignet verteiltes Arbeiten über das Internet bzw. das Anbinden von Außenstellen zu ermöglichen.
Eine existierende C-Bibliothek sollte zusätzlich zur existierenden seriellen Kommunikation mit der Hardware eine moderne USB-Anbindung bekommen. Durch unterschiedliche State-Engines in der Kommunikationsschicht und zur Vereinfachung der Wartung wurden es dann aber doch zwei verschiedene Libraries mit gleicher Schnittstelle. Dadurch konnte die USB-Variante dann aber auch direkt nach Linux portiert werden. Für Testzwecke wurde dann noch dafür eine Oberfläche in Python3 mit PyQT geschaffen.
Diese war dann so erfolgreich das nach und nach Teile der gesamten Suite oberhalb der Hardware weg von C/C++ hin zu Python3 umgestellt wurden.
Für einen Kunden mit besonderen Anforderungen an die Anbindung an die Produktion und deren Darstellung und Abrechnung hatte ich vor Jahren eine Python 2.x basierte Anwendungssuite geschrieben. Diese war auf Python 3.x umzustellen.
Außerdem erfolgte die Kommunikation zwischen den einzelnen Modulen dort über die gemeinsame Datenbank was langsam und umständlich war. Dieser Layer wurde komplett durch eine peer-to-peer ähnliche Kommunikationsschicht ersetzt die wesentlich schnellere Reaktionen ermöglichte. Außerdem konnten viele Teile der Geschäftslogik in sog. nano services verschoben werden.
Dadurch konnten die Hardwareanforderungen so weit gesenkt werden das die Lebensdauer der Hardware um mindestens 5 Jahre verlängert werden konnte. Das ist gerade im Bereich der maschinennahen Steuerung ein großer Erfolg.
Zusätzlich sind einzelnen Teilmodule leichter zu warten und können bei Bedarf leichter mit den Anforderungen wachsen in dem man sie z.B. einfach mehrfach startet.
Eine lange geplante Pause nach dem letzten siebenjährigen Auftrag ging ansatzlos in die Quarantänezeit von Corona über. Ich habe in der Zeit mich um meine Eltern gekümmert die weit über 80 sind und in der Zeit hilfebedürftig waren.
Für ein international agierendes Maschinenbauunternehmen war der Build-Workflow neu zu organisieren. Das in Produktion befindliche System war auf die Anzahl der Projekte (In Summe über 1000 aktive Projekte die von mehr als 600 Entwicklern betreut wurden) und die heterogenen Entwicklungsumgebungen (Embedded, Win, *IX, Android etc.) nicht ausgelegt. Davon mussten ca. 250 jede Nacht gebaut werden. Der Austausch/die Erweiterung musste im laufenden Betrieb erfolgen.
Im Unternehmen waren wichtige Hilfsprogramme bereits in Ruby ausgelegt, ich habe daher entschieden die neue Umgebung auf Ruby aufzusetzen um das existierende Know-How zu nutzen. Aus meiner Erfahrung aus dem vorherigen Projekt hab ich ein Netzwerk von selbst-organisierenden Microservices geschrieben die Builds selbstständig in einem Grid von dedizierten Buildengines verteilt haben, deren Ergebnisse in ein übergreifendes Binärrepository eingliederten und diese damit übergeordneten Projekten als Artefakte bereitgestellt haben. Zugleich wurden entsprechende Anpassungen an Visual Studio, Gradle, Eclipse etc. vorgenommen um diese Builds dann auch lokal bereitzustellen. Zugleich enthielt das Repository auch alte Versionen und konnte mit dem Bugtracker zusammen mit aus dem Feld kommenden Traces Fehler-Umgebungen für alle Versionen der letzten Jahrzehnte wieder herstellen. Einer der letzten Schritte war die Erweiterung um CI gesteuert aus den Commits der Entwickler.
Zugleich hab ich den Second-Level-Support für die Entwickler bei Build- und Design-Problemen für C/C++, C# und Java übernommen.
Teile der von mir geschaffenen Umgebung wurden auf der HPC'10 präsentiert und mit großem Interesse aufgenommen.
Eine Windows-Applikation war nach 64Bit-*IX zu porten. Die Anwendung machte intensiven Gebrauch von MFC und anderen Windows spezifischen Bibliotheken und war über Jahre gewachsen. Die neue Version setzte auf das Reaktor-Konzept von ACE auf zur Socket-Kommunikation und als Message-Queue, Teile der alten Anwendung wurden durch Boost ersetzt, die Datenbank-Anbindung nutzte OCCI um mit Oracle zu reden. Desweiteren wurde DDS zur Kommunikation per Multicast eingesetzt bzw. SNMP zur Kommunikation mit der verteilten Hardware.
Stichworte: C++, Linux, MFC, Linux, Oracle, SNMP, ACE, Boost, DDS, OCCI
Eine vor Jahren von mir geschriebene C++/MFC-Windows-Applikation brauchte ein lang überfälliges Update. Das Design war insgesamt schon modular ausgelegt so daß ich einfach den "Motor" ausgebaut und die "Karosserie" durch eine Python/wxWidgets-Kombination ersetzt habe. Dadurch entfällt auch die Notwendigkeit von Windows Lizenzen und die Arbeitsplätze laufen jetzt von Ubuntu-BootCDs.
Die Anwendung verwaltet eine Datenbank und ist sehr dialoglastig. Zugleich enthält sie einige zeitkritische Auswertungen die das eigentliche Geschäftswissen enthalten.
Um später das Wissen bei der Wartung nicht offenlegen zu müssen war es in einem eigenen Projektteil untergebracht der in eine DLL mündete die später zur Laufzeit dynamisch eingebunden wurde.
Da außerdem abzusehen war das die Dialoge oft und gern angepasst bzw. übersetzt werden müssen wurden diese bereits damals in einer Beschreibungssprache kodiert, aus der Datenbank geladen und dann mit einem Interpreter als MFC-Dialoge aufgebaut.
Das Geschäftswissen und die zeitkritischen Teile in der DLL sind nach dem Umbau erhalten geblieben. Diese wurde mit SIP an Python angebunden. Der Interpreter für die Dialogstruktur wurde in Python komplett neu geschrieben, die Dialoge selber brauchten daher nicht angefasst zu werden. Anstatt MFC wird jetzt wxWidgets bzw. deren Python-Bindings wxPython benutzt.
Ich hatte auch überlegt die Anbindung über "boost.python" zu machen, aber die DLL sollte für das alte und das neue System identisch sein. Boost hätte in diesem Falle aber eine Anpassung des C++-Codes erfordert.
Die Portierung nach *IX erforderte nur eine Neuübersetzung des C++-Teils. Dafür brauchen jetzt 20 Arbeitsplätze, die vorher noch auf WinNT waren, keine Windows-Lizenz mehr.
Als Datenbank kommt SQLAnywhere zum Einsatz. Sie läuft auf einem alten Server der die Anforderungen neuerer Datenbanken nicht erfüllt. Das nächste Mal wenn zwischen zwei Projekten Zeit ist wird sie auf einen neuen Server verschoben und gegen PostgreSQL ausgetauscht.
Februar 2008
Basierend auf meinen Erfahrungen mit fli4l und eisfair eine schöne kleine Serverlösung mit DMZ und hotpluggable USB-Festplatten erstellt. Linux wird dabei von einer 16MB Compact Flash Karte gestartet, läuft in einer RAM-Disk und holt sich seine Konfiguration von einem eingesteckten USB-Stick. Damit kommt man einem Router mit embedded Linux so nahe wie möglich ohne die Erweiterbarkeit zu verlieren.
Stichworte: Linux, Embedded, Server, DMZ
Eine vom Unternehmen in Python selbst entwickelte Bibliothek zum Testen von embedded Komponenten und Bussystemen im Automobilbau war mit einer Oberfläche zu versehen. Als GUI-Bibliothek verwendeten wir wxPython.
Stichworte: Python, C, Embedded, wxWidgets, wxPython, PyRex
Basierend auf einer vom Kunden selbst-entwickelten Datenbank unter Windows und Linux. Entwicklung der Spezifikation um die Datenbank als verteilte Datenbank zu erweitern. Synchronisation und Replikation über TCP/IP über verschiedene Serverthreads.
Eine Meßstation ist über die serielle Schnittstelle an einen Industrie-PC angeschlossen. Dieser hängt über einer normalen DSL-Verbindung am Internet. Gesteuert wird die Meßstation über ein Java-Applet von jedem beliebigen Rechner mit Zugriff auf die Meßstation.
Drei Softwaremodule waren neu zu entwickeln, obwohl die Teile bereits aus einem vorherigen Anlauf bestanden: Die Software für die Station selber, den PC mit der DSL-Anbindung und das Java-Applet.
Die Station im wesentlichen besteht aus einer Standardplatine mit dem C167 als Prozessor, der mir schon aus vorherigen Projekten bekannt war. Für die Entwicklungsumgebung wurde vom Kunden die Software von Keil gestellt. Über einfache Funktionen werden die Daten gesammelt, komprimiert und im Speicher abgelegt. Besteht Verbindung zum Steuer-PC werden diese Pakete dann an den Steuer-PC übertragen.
Verschiedene Schwierigkeiten traten auf. So war unter anderem kein Multitasking möglich. Wir haben uns deshalb entschieden die Daten in eine Art Ringpuffer abzulegen aus denen der Steuer-PC einzelne Pakete abrufen kann, die wir dann in einem Burst zwischen den Messvorgängen senden. Außerdem verzichtete ich auf ein Acknowledge-Paket, sondern übertrugen mit jedem Paket die Indexnummern der noch vorhandenen Pakete und erwarten mit jedem Abruf eine Liste von Paketen, die wir löschen können. Der Steuer-PC überpüft die von ihm empfangenen Pakete und teilt bei fehlerfreiem Empfang solange den Wunsch auf Löschung mit, bis das Paket wirklich nicht mehr in der Antwort auftaucht.
Damit sind wir auch bei einen Ausfall des Steuer-PC auf der sicheren Seite da nur dieser Pakete löschen kann. Sollte der Steuer-PC die Daten nicht abrufen, dann werden die Pakete in drei Stufen nachbehandelt um Speicher zu sparen. Dabei gehen dann aber Daten verloren.
Für den Steuer-PC wurde Windows eingesetzt, da sich der Kunde für ein DSL-Modem auf Basis einer PCI-Karte entschieden hatte für die es nur Windows-Treiber gab.
Das Steuerprogramm habe ich in Python geschrieben. Alle notwendigen Teile zur Kommunikation mit der seriellen Schnittstelle und über TCP/IP sind bereits in den Standard-Libraries enthalten und die Entwicklung gestaltete sich deshalb sehr unkompliziert.
Für eine Variante der Hardware ohne DSL-Anschluss habe ich ein Verfahren entwickelt, die gespeicherten Daten automatisch alle 24h auf einem eingebauten CD-Brenner festhält. Dann ist ein Besuch nur jeden Monat notwendig.
Zur Fernsteuerung des Steuer-PC wird ein Java-Applet mit Swing-Oberfläche eingesetzt. Der Start des Applets verfolgt von einem beliebigen PC mit Internetanbindung über Webstart. Die aktuelle Konfiguration wird dann vom Steuer-PC geladen. Die IP-Nummer für den Zugriff wird über einen zentralen Server bei meinem Kunden ermittelt. Sie wird dort vom Steuer-PC nach jeder Neueinwahl abgelegt.