Steffen A. Mork

Modellbasierte Server-Konfiguration auf TMF/Xtext umgestellt

Seit etwa zwei Jahren wird die IT-Infrastruktur der itemis mithilfe der modellbasierten Server-Konfiguration verwaltet. Vorteil dieser Methode ist, dass aus einer zentralen Übersicht der Server-Landschaft – dem Modell – die Konfigurationsdateien eines jeden Servers generiert werden. Dabei werden auch Abhängigkeiten berücksichtigt, die sich z.B. durch verwendete Dienste auf unterschiedlichen Servern ergeben. Im Modell werden alle Server, deren Hardware und die installierten Dienste eingetragen. Daraus können andere Server Dienste in Anspruch nehmen. Es können aber auch zwecks der zentralen Funktionsüberwachung mittels Nagios oder MRTG die Konfiguration der Überwachungsdienste so generiert werden, dass sie immer dem Realzustand entsprechen. Dazu ist das Modell der Sollzustand, durch das Generieren der Konfiguration und das Deployment wird dieser Sollzustand in den Istzustand überführt. Ein solcher Vorgang dauert ca. eine Minute für das Generieren und bis zu zehn Minuten für das Deployment. Ein weiterer Vorteil ist der einheitliche Qualitätsstandard, der sich durch das Generieren der Konfiguration ergibt.

Die bisherige Variante der modellbasierten Server-Konfiguration benutzte UML2 als Metamodell. Diese Vorgehensweise hat den Nachteil, dass das Modell nur durch ein GUI-Tool bearbeitet werden kann. Änderungen am Metamodell sind nur schwerfällig umsetzbar. Auch das Generieren dauert auf Grund des umfangreichen UML-Metamodells relativ lange. Der zwingende Einsatz einer GUI erschwert auch das Ändern des Modells bei Remote-Zugriff über Fernwartung.

Aus diesem Grund wurde die modellbasierte Server-Konfiguration auf TMF/Xtext umgestellt. Das Metamodell ist jetzt eine textuelle DSL, die mithilfe einer Grammatik erstellt wurde. Änderungen an diesem Metamodell bedeuten Änderungen an der Xtext-Grammatik. Dieser Vorgang ist leichtgewichtig und kann schnell durchgeführt werden. Das Modell selbst liegt textuell vor. So kann man selbst mit einfachen Editoren (z.B. vi) remote das Modell ändern, die Konfiguration generieren und deployen. Natürlich muss auf den von Xtext generierten Editor mit Code Completion und Syntax Highlighting nicht verzichtet werden. Ein weiterer Vorteil ist, dass der Generierungsvorgang ca. fünf Mal schneller geworden ist, dabei aber wesentlich mehr Sonderfälle berücksichtigt.

Die Umstellung musste behutsam erfolgen. Ein Komplettdeployment an den Produktivsystemen wäre im ersten Anlauf vermutlich schief gegangen, wären vorher die Generate beider Metamodellvarianten nicht sorgfältig Server für Server verglichen worden. So konnten Fehler im neuen Modell (eine XMI-Darstellung musste in eine textuelle Modellrepräsentation überführt werden) und Fehler im Generator im Vorfeld erkannt und behoben werden.

Insgesamt hat sich der Umstieg gelohnt, da TMF/Xtext ein geniales, einfach zu bediendendes Werkzeug darstellt und somit eine schwergewichtige Modellrepräsentation in eine leichtfüßige Anwendung überführt werden konnte.

Posted in Eclipse, Systemmanagement | No Comments »

Modellbahnsteuerung auf Yakindu-Tag vorgestellt

Am 04.09.2008 fand in Lünen anlässlich der Preisverleihung für die Initiative “Land der Ideen” der Yakindu-Tag statt. Bei dieser Gelegenheit wurde die Steuerung einer Modellbahn vorgestellt. Teile der Software sind modellgetrieben entwickelt worden. Die Steuerung basiert auf unterschiedlichen Modulen, die an CAN-Knoten angeschlossen werden. Diese Module können unterschiedliche Steuerungs- und Meldungsaufgaben übernehmen. Derzeit gibt es drei unterschiedliche Module:

• Lichtsignalmodul
• Weichenmodul zur Schaltung und Lagemeldung
• Gleismodul mit Gleisbesetztmeldung

Die Konfiguration der CAN-Knoten wird modellgetrieben vorgenommen. Über ein CAN-RS232-Gateway ist die Modellbahnanlage mit einem Rechner verbunden. Auf diesem Rechner können Fahrstraßen ausgewählt und geschaltet werden. Dabei werden besetzte Gleise berücksichtigt. Auch die Unterscheidung zwischen einer Bahnfahrt und einer Rangierfahrt schlägt sich bei der Wahl der Signalbilder nieder. Weitere Sicherungsmaßnahmen werden beim Schalten der Fahrstraße berücksichtigt: Kann eine Weiche (z.B. durch einen Defekt) nicht gestellt werden, merkt das der CAN-Knoten und meldet dieses zurück. Die Fahrstraße wird dann nicht freigeschaltet. Auch ein manueller Eingriff in die Fahrstraße durch Schalten einer Weiche, schaltet die Fahrstraße sofort ab. Die Steuerungs-Software in den CAN-Knoten ist in C entwickelt. Die Steuerungs-Software auf dem Rechner ist Java-basiert. Als GUI-Framework wird Eclipse-RCP eingesetzt. Die Gui ist zu Teil ebenfalls modellbasiert generiert.

Ein weiteres Feature ist die Möglichkeit, die CAN-Knoten mit neuer Firmware ausstatten zu können. Um dies zu erreichen, wurden die Microcontroller der CAN-Knoten mit einem Bootloader ausgestattet, der über CAN-Bus die Firmware updaten kann. So kann die Modelleisenbahn bequem vom Rechner aus mit einer neuen Firmware ausgestattet werden.

Die Steuerung ist nicht DCC-kompatibel. Ziel war nicht, ein Konkurrenzsystem zu entwickeln. Vielmehr ging es bei dieser Steuerung um eine Machbarkeitsstudie. Hierbei war vor Allem die Rückmeldefähigkeit interessant. Diese ist im DCC-Standard noch nicht festgeschrieben. Die Wahl, CAN zu nehmen hat sich als vorteilhaft erwiesen: Der CAN-Bus ist robust, ausgereift und preiswert. Der Verkabelungsaufwand hät sich in Grenzen. Dabei ist zu beachten, dass zwischen der Anlagensteuerung und der Fahrsteuerung unterschieden werden muss. Beides ist per DCC machbar, es wurde aber nur die Anlagensteuerung umgesetzt. Die Steuerung der Lokomotiven erfolgt nach wie vor klassisch. Diese kann also analog, wie auch digital über DCC erfolgen. Die Gleisbesetztmeldung unterstützt beides.

Posted in Eingebettete Systeme, Embedded, Modellbau | 1 Comment »

Ubuntu – Eine Erfolgsstory im eigenen Unternehmen

Vor einem Jahr hat unser Unternehmen eine neue IT-Infrastruktur in Betrieb genommen. Grund genug zu hinterfragen, ob die Umstellung erfolgreich war. Nachdem entschieden war, dass fünf neue Server samt weiterer Infrastruktur wie z.B. unterbrechnungsfreie Stromversorgungen, angeschafft werden sollen, kam die Frage auf, welches Betriebssystem dafür benutzt werden sollte. Die Frage ob Microsoft oder Linux genutzt werden sollte stellte sich gar nicht erst, da ausreichend Linux-Know-How zur Verfügung stand. Ferner sind die Fernwartungsmöglichkeiten unter Linux deutlich höher. Eine Sicherheitsabwägung zwischen Windows und Linux gibt es nicht, da auch unter Linux nicht minder häufig viele Patches und Updates auf Grund von Sicherheitslücken notwendig sind.

Blieb also noch die Frage, welche Linux-Distribution gewählt werden sollte. Hier war zuerst die Wahl zwischen SuSE bzw. openSuSE und Debian. Debian hat gegenüber SuSE den Vorteil, dass langfristig die Upgrades wesentlich wartungsärmer ausfallen, als unter SuSE. Wer z.B. schon mal von SuSE 9.2 auf SuSE 10.1 ein Upgrade durchgeführt hat, weiß wovon die Rede ist. Ein Debian-basiertes System hat deutlich weniger Probleme mit Upgrades selbst über mehrere Jahre hinweg. Grund hierfür ist ein ausgereiftes und durchdachtes Paketmanagement, das es selbst nach Jahren ermöglicht, aktuelle Software samt Abhängigkeiten zwischen unterschiedlichen Paketen zu pflegen. SuSE hat den Vorteil, dass die angebotenen Software-Pakete aktueller sind. Gerade bei relativ neuer Hardware spielt das eine Rolle. Hier lag Debian z.T. erheblich zurück, war vor einem Jahr nur die Distribution Sarge aktuell und der Nacholger Etch ließ noch auf sich warten. Ferner konnte Debian nicht mit einer stabilen 64-Bit-Variante für Opterons aufwarten.

Hier kam Ubuntu auf den Plan. Ubuntu basiert mit seinem Paketmanagement auf Debian, weist aber eine deutlich höhere Aktualität in der Software auf. Ferner gab es auch eine stabile 64-Bit-Variante. Genutzt haben wir den Ubuntu-Server-Zweig. Daduch konnte eine sehr schlanke Basisinstallation erfolgen, die nur ca. 600 MByte umfasst. Denn: Jede Software, die nicht installiert ist, kann nicht durch Sicherheitslücken auffallen. Im Gegensatz dazu SuSE oder SLES, welche aus Bequemlichkeit das Rundum-Sorglos-Paket – also nahezu alles – installieren. Ob das dann wirklich sorglos ist, muss danach entschieden werden.

Sicherlich hat Ubuntu noch Probleme bei der Hardware-Erkennung. Hier ist SuSE eindeutig besser. Das trifft sowohl auf alte Hardware (“attic hardware”) zu, als auch auf sehr neue Hardware. Hier ist Ubuntu eher am Mainstream orientiert. Ist aber erst einmal ein funktionierendes Ubuntu lauffähig, kann es fast nur noch mutwillig die Arbeit verweigern.

Die Erstinstallation umfasste Ubuntu Edgy Eft und wurde inzwischen ohne Probleme auf Gutsy Gibbon aktualisiert. Jeder Server hat also schon zwei Upgrades hinter sich. Nachdem auf einem Staging System die kleinere Probleme bei neueren Konfigurationsdateien erkannt wurden, konnten diese komfortabel per modellgetriebener Serverkonfiguration bei den Upgrades anderer Server umgangen werden. Das Staging System läuft auf einer virtuellen Maschine, wodurch keinerlei Hardware-Anschaffung nötig waren. Einer der vielen Vorteile der Virtualisierung – aber das nur am Rande.

Abschließend lässt sich sagen, dass ein Umstieg auf Ubuntu die richtige Entscheidung war. Es liegt eine wartungsarme Distribution vor, die Sicherheitsupdates mit nur kleiner Zeitverzögerung nach Bekanntwerden aktualisiert. Im Alltag haben sich nahezu keine Probleme in Sachen Stabilität gezeigt. Insofern kann man Ubuntu alles Gute für die weitere Zukunft wünschen.

Posted in Systemmanagement | No Comments »

Ja steh’ ich im Wald hier?

Ich habe ja schon über die technischen Details einer Modelleisenbahnsteuerung berichtet. Damit man auch etwas zum Testen hat, braucht man natürlich auch eine Anlage. Bestandteil dieser Anlage ist natürlich auch die Modelllandschaft. Ein Teil wird derzeit aufgeforstet, wie auf dem Bild zu erkennen ist:

Dieses Bild zeigt nur einen Ausschnit meiner neuen Modelleisenbahnanlage. Es sind schon 300 Bäume gepflanzt worden. Am Wochenende werden die nächsten 100 Stecktannen den Wald vergrößern. Natürlich werden noch weitere Bilder folgen und Berichte über den Ausbauzustand der Microcontroller-Steuerung werden ergänzt.

Posted in Modellbau | No Comments »

Modellgetriebene Serverkonfiguration

In der Regel sind die Anwendungsfälle für modellgetriebene Architekturen ist der Software-Entwicklung zu finden. Es gibt aber auch die Möglichkeit, die Konfiguration für eine ganze Server-Landschaft zu generieren. Zu diesem Zweck wird die Server-Landschaft als UML2-Modell modelliert. Dieses Modell entspricht dem Sollzustand. Um diesen in den Istzustand zu überführen, werden mittels openArchitectureWare aus dem Modell Konfigurationsdatien erzeugt. Für jeden Server entsteht so ein Verzeichnisbaum. Dieser Verzeichnisbaum wird mit scp -r auf die Zielmaschine kopiert. Danach wird ein Deploy-Script aufgerufen, das die betroffenen Dienste über die neue Konfiguration informiert.

Das Modell erfasst dabei sowohl Hardware, als auch Dienste. Die Hardware muss erfasst werden, wenn die Funktionstüchtigkeit überprüft werden soll. Dazu gehören Temperaturstände, Fehlerzustände von Festplatten, die über S.M.A.R.T. abgefragt werden können und auch Füllstände von Partitionen. Dabei kann eine langfristige Erfassung mit MRTG erfolgen, mit der auch Trends erfasst werden können. Eine schnelle Erfassung kann mit Nagios erfolgen. Das nützt besonders dann, wenn tatsächlich etwas schlagartig ausfällt.

An Software-Diensten werden folgende Dienste mitkonfiguriert:

• Nagios/MRTG/SNMP
• DHCP
• LDAP
• Apache/Webalizer
• PAM über LDAP, passwd oder NIS
• smartmontools
• 3ware RAID-Controller
• NTP
• SSL
• APC UPS Daemon

Alle diese Dienste sind mehr oder weniger miteinander verwoben. So liefert DHCP auch Informationen über NTP oder DNS aus. Auch der Apache kann sich unter Umständen an andere Dienste (z.B. LDAP) hängen. Auch Master-Slave-Konfigurationen sind möglich. Insbesondere bei OpenLDAP kann dieses Feature genutzt werden.

Es stellt sich die Frage, welche Vorteile die modellgetriebene Serverkonfiguration hat. Sicherlich ist dieser Weg sehr individuell und in ihrer ersten Form an die Gegebenheiten unserer eigenen Infrastruktur angepasst. Es hat sich gezeigt, dass ein großer Vorteil dann besteht, wenn Abhängigkeiten zwischen mehreren Servern bestehen. Dazu ist vor Allem Nagios, MRTG und SNMP zu nennen. Aber auch die Master-Slave-Konfiguration von LDAP, die auch als Load Balancing für die LDAP-Apache-Authentifizierung genutzt werden kann. Gegenüber dem klassischen Systemmanagement hat dieser Ansatz den Vorteil, dass ein Sollzustand definiert wird und nicht ein Istzustand ergründet wird, auf dem weitergearbeitet wird. Denn dieser Zustand kann auch schon fehlerhaft sein. Desweiteren lassen sich Unterlassungsfehler und Copy/Paste-Fehler vermeiden, was insgesamt die Qualität der Konfiguration steigert.

Unsere IT hat mit diesem Ansatz gute Erfahrungen gemacht, sodass die modellgetriebene Serverkonfiguration seit fast einem Jahr produktiv genutzt wird.

Posted in Systemmanagement | No Comments »

Embedded World 2008: Modell(-bau-)getriebene Eisenbahnsteuerung

Kann man modellgetrieben eine Modelleisenbahnsteuerung aus Mikrocontrollern bauen? Dieser Frage gehen Entwickler des Yakindu-Projektes nach. Hintergrund ist, dass eine digitale Ansteuerung der Weichen und Signale über konventionelle Mittel sehr teuer ist. Eine digitale Steuerung hat aber den Vorteil, dass der Verdrahtungsaufwand minimiert wird. Dieser fällt deswegen unangenehm auf, weil ein Großteil der elektrischen Verkabelung kopfüber geschehen muss. Hier setzt die Idee an, die Mikrocontroller bequem an einem ergonomischen Arbeitsplatz zu bauen und nur die fertigen Module kopfüber zu montieren und anzuschließen. Als Mikrocontroller werden von ATmel die ATmega32 eingesetzt. Diese sind vielseitig einsetzbar und es gibt sehr viele fertige freie Tools, um diese Controller zu programmieren. Zusätzlich gibt es eine große Auswahl an weiteren Spezial-ICs, wie z.B. den CAN-Controller MCP2515.

An den Mikrocontrollern sollen spezielle Ansteuerungsmodule verwendet werden. So können unterschiedliche Aufgaben an die Microcontroller vergeben werden, ohne jeweils eine spezielle Hardware bauen zu müssen. Dazu erhalten die Microcontroller eine universelle Firmware. Diese wird dann so konfiguriert, wie der Anschluss der Ansteuerungsmodule erfolgt. Als Ansteuerungsmodule sind derzeit geplant:

• Lichtsignal-Ansteuerung, im Prinzip eine einfache LED-Ansteuerung
• Magnetartikel-Ansteuerung. Darüber werden Weichen und Formsignale angesteuert.
• Gleisabschnitt-Steuerung mit Gleisbesetztmeldung
• JTAG-Modul zum Debuggen

Die drei letzten Module werden direkt mit den einzelnen Ports des ATmega gekoppelt ein Port fällt für spezielle Aufgaben weg, da z.B. die Microcontroller untereinander kommunizieren müssen. Diese Kommunikation soll über CAN-Bus erfolgen. Dieser ist sehr robust gegenüber Störungen und gilt nach 20 Jahren als ausgereift. Es gibt günstige Bauteile, die die Kommunikation auf physikalischer Ebene übernehmen. Darin enthalten ist z.B. eine Fehlerkorrektur über CRC und das Protokoll-Handling. Bei einem ATmega32 bleiben so drei Ports für die Module frei, was den individuellen Verbau der Module ermöglicht.

Als zweite Software-Komponente neben der Microcontroller-Firmware gibt es das Frontend. Diese GUI-Applikation ermöglicht die bequeme Ansteuerung der Microcontroller mit einer Visualisierung als Stellwerk. Insbesondere ist hier die Fahrstraßenschaltung zu nennen. Durch Anklicken von Stützpunkten welche die Route definieren und anschließender Auswahl von Rangieren oder Fahrt, wird eine freie Gleisroute vom Anfangspunkt über die Stützpunkte zum Endpunkt gesucht, danach die Weichen und Signale geschaltet und die Gleisabschnitte unter Fahrstrom gesetzt. Diese Applikation ist mit Eclipse und dem SWT/RCP-Framework umgesetzt. So kann das Stellwerk plattformunanhängig eingesetzt werden.

Zum Schluss bleibt die Frage offen, was daran modellgetrieben ist? Die gesamte Modellbahnanlage wird in einem EMF-Modell nachmodelliert. Daraus wird die Gesamtkonfiguration für die Microcontroller generiert sowie die GUI für das Stellwerk. Das generierte Gleisschema wird dann durch den universellen Router-Algorithmus für die Fahrstraße ergänzt. Dieser wertet noch Informationen aus, wie Langsamfahrstellen und bevorzugte Fahrwege an Weichen. In der Zukunft ist geplant, die Modellierung mittels GMF zu erreichen, weil die Eingabe über EMF gerade bei einer Modelleisenbahn wenig intuitiv ist.

Posted in Embedded, Modellbau | No Comments »

Embedded World 2008: ATmega jetzt auch mit integriertem CAN-Controller

Seit Neuestem bietet ATmel auch eine Variante ihres erfolgreichen ATmega Mikrocontrollers mit integriertem CAN-Controller an. Laut Dokumentation ist die Spezifikation zwar noch vorläufig, es ist aber erkennbar, dass ATmel weitere Unterstützung im Automotive-Bereich liefern will. Derzeit sind drei Varianten (AT90CAN32, AT90CAN64 und AT90CAN128) aufgelistet, die sich in der Größe des Flash-Speichers, EEPROMs und des SRAMs unterscheiden. Der Mikrocontroller ist im 64-Pin TQFP lieferbar und hat sechs 8-Bit-IO-Ports zur Verfügung. Ansonsten enthält der Mikrocontroller die üblichen Baugruppen, die man von den bekannten ATmels gewohnt ist: Timer, PWM, JTAG, ISP, UART, um nur einige zu nennen.

Hier ist die (vorläufige) Spezifikation zu finden:
http://www.atmel.com/dyn/resources/prod_documents/doc7682.pdf

Posted in Embedded | No Comments »

Mikrokopter

Der Mikrokopter ist ein Beispiel dafür, was man mit den ATmel ATmega Microcontrollern machen kann. Vier überkreuz positionierte Propeller geben den Auftrieb. Die Lagereglung wird über Beschleunigungssensoren an die drehzahlgeregelten Motoren für die Propeller weitergereicht. Als Bonbon ist noch ein GPS-Positionsmelder eingebaut. So kann ein Mikrokopter relativ ortsfest im Rahmen der GPS-Genauigkeit gehalten werden. Zusätzlich ist noch ein Kompass und ein Drucksensor zur Höhenmessung eingebaut. Eine lagegeregelte 3D-Kamera samt Brille runden das Gesamtbild ab. Jeder Motor hat seinen eigenen ATmega, der die Solldrehzahl umsetzt. Ein zentraler ATmega übernimmt den Rest der Lageregelung.

Unter http://www.mikrokopter.com/ucwiki/ sind mehrere beeindruckende Videos untergebracht.

Posted in Embedded | No Comments »

CAN-Protokoll im Linux Kernel

Heute wurde bekanntgegeben, dass ab der Linux-Version 2.6.25-rc1 Unterstützung für den CAN-Bus aufgenommen wurde. Die Unterstützung sieht derzeit so aus, dass CAN als zusätzliches Protokoll benutzt wird. So wird die schon bekannte Schnittstelle mittels socket(), read() und write() angesprochen. Die Unterstützung für Devices sieht im Moment leider ein wenig mager aus: Außer einem virtuellem Device steht im Moment kein Treiber zur Verfügung. Es wäre vielleicht denkbar, eigene Hardware unter Benutzung des CAN-Controllers MCP2515 zu bauen, die man z.B. über USB anspricht.

Interessanterweise wurde die Implementierung von Volkswagen beigesteuert. Ob allerdings ein “Treiber für Autos” entwickelt wird, oder Embedded Linux in VWs Einzug hält, ist derzeit offen.

Heise-Meldung:
http://www.heise.de/newsticker/meldung/103552

Nähere Erläuterung zur CAN-Integration
http://lwn.net/Articles/253425/

Posted in Embedded | No Comments »