Mehr Komfort mit C++

 Eingebettete Systeme  Kommentare deaktiviert für Mehr Komfort mit C++
Jun 212008
 

In der Elektronikpraxis ist ein Artikel von mir erschienen, der sich mit der Verwendung von C++ im Embedded Systems beschäftigt. Obwohl mit C++ schon seit über 20 Jahren entwickelt wird, hält diese Sprache nur langsam in die Mikrocontroller-Programmierung Einzug. Sie enthält aber viele Sprachkonstrukte die die Qualität der Firmware erheblich verbessern kann und dem Entwickler die Arbeit vereinfacht. Ein Grund für die zögerliche Nutzung liegt im höheren Ressourcen-Bedarf. Viele moderne Mikrocontroller haben diese Hürde aber nicht mehr.

Der gesamte Artikel kann hier eingesehen werden: http://www.elektronikpraxis.vogel.de/themen/embeddedsoftwareengineering/implementierung/articles/120537/


Anzeige:

Was haben reale Anforderungen mit Modellbau zu tun?

 Modellbau, Requirements, Systemmanagement  Kommentare deaktiviert für Was haben reale Anforderungen mit Modellbau zu tun?
Jun 122008
 

Auf den ersten Blick scheinen Modellbau und Anforderungsverwaltung (= Requirements Engineering) nichts miteinander zu tun zu haben, aber bei der Erstellung der Stellwerks-Software wird deutlich, wie viel Komplexität hinter diesem Thema steckt. Beim Entwurf einer Modellbahnsteuerung stand am Anfang die Idee, möglichst kostengünstig mit Standardtechnologien eine Steuerung zu entwickeln, um simpel Weichen schalten zu können. Dabei stand im Wesentlichen die Technik im Vordergrund. Nach und nach hat sich gezeigt, dass es die Software-Steuerung am Front-End in sich hat.

Anfangs stand die Darstellung des Soll-Zustand im Vordergrund. Es wurde über Start/Via/Ziel-Checkboxen ein Fahrtweg vorgegeben. Dieser soll so eingestellt werden, dass nur freie Gleise benutzt werden. Wurde eine freie Fahrstraße gefunden, sollen die Weichen geschaltet und die Signalfreigabe erteilt werden. Diese Anforderung war für den Anfang schnell implementiert. Bei genauerer Betrachtung zeigt sich, dass die Darstellung des Ist-Zustandes inkl. des Soll-Zustandes für den Benutzer erforderlich ist. Beim Studium von Berichten, wie realen Stellwerke funktionieren, hat sich gezeigt, dass das Thema sehr komplex ist. Die erste Idee war insofern nicht falsch angedacht. Tatsächlich erfolgt beim Suchen einer Fahrstraße erst eine Route, die frei ist. Diese muss durch das Stellen von Weichen erreicht werden. Dieser Vorgang heißt in der Realität Weichenumlauf. Hierbei ist der Vorgang an sich interessant, weil eine Rückmeldung erfolgen muss, dass die sog. Weichenendlage erreicht ist. Danach wird die Weiche verschlossen. Dieser mechanische Vorgang soll verhindern, dass sich durch die Erschütterung des darüberfahrenden Zuges die Weiche verstellt und somit den Zug zur Entgleisung bringt. Desweiteren ist eine versehentliche Umstellung durch den Fahrdienstleiter im Stellwerk dadurch nicht mehr möglich. Der mechanische Verschluss ist im Modellbau nicht möglich, wohl aber die Rückmeldung. Ein einfacher Schalter soll das Durchbrennen des Antriebes verhindern. Somit ist nur eine Spule unter Strom. Es lässt sich also mit einem hochohmigen Strom festellen, in welcher Lage sich die Weiche befindet ohne die Weiche durch den Strom selbst zu stellen. Somit kann diese Information dafür ausgewertet werden, ob eine Fahrstraße korrekt geschaltet wurde.

Erst danach kann eine Gleisfreigabe erfolgen. Die Realität weicht an dieser Stelle erheblich vom Modell ab. Die Gleisfreigabe erfolgt in der Realität durch Signale. Diese haben eine sog. punktuelle Zugbeeinflussung. Überfährt man ein auf rot stehendes Signal, löst ein unter dem Signal angebrachter Schwingkreis an der Lok eine Zwangsbremsung aus. Beim Modellbau sind Signale eher Kosmetik, allerdings kann keine Lok fahren, wenn kein Strom auf dem Gleis anliegt. Somit werden der Optik halber erst die Signale gestellt und danach erfolgt die Gleisfreigabe über das Aufschalten von Fahrstrom.

Jeder dieser Vorgänge ähnelt einer Transaktion so wie wir es aus der Informatik her kennen. Ein Vorgang (Weichenschalten) muss vollständig erfolgreich ausgeführt werden. Erst danach darf der nächste Vorgang (Signale schalten) folgen, denn sonst würde der Zug schon die Freigabe erhalten, während sich noch fatalerweise die Weichen schalten. Ist ein Vorgang nicht erfolgreich, müssen ggf. Vorgänge zurückgenommen werden. Weichen müssen nicht wieder zurückgestellt werden, wohl aber Signale und die Gleisfreigaben.

Die Steuerungs-Software muss diesen Anforderungen Rechnung tragen. Die Mikrocontroller müssen sowohl für eine korrekte Ansteuerung der Geräte (Weichen, Signale und Gleise) sorgen, eine korrekte Zustandsmeldung liefern und Zustandsmeldungen korrekt melden. Die Steuerungs-Software am Front End muss diese Meldungen korrekt darstellen und Fehlbedienungen ausschließen. Speziell bei der Fehlbedienung kommt eine Simulation des Verschlusses ins Spiel. Ist eine Fahrstraße erst einmal eingestellt, dürfen alle beteiligten Geräte nicht mehr verstellt werden. Mangels mechanischen Verschlusses kann das bei Modellweichen durch manuelles Verstellen trotzdem passieren. In diesem Fall muss eine dadurch betroffene Fahrstraße sofort deaktiviert werden. Desweiteren spielt das visuelle Feed-Back eine entscheidende Rolle. Da Mechanik im Spiel ist, dauert das Einstellen der Fahrstraße ggf. mehrere Sekunden. Dieser Vorgang muss auf der GUI dargestellt werden, ohne dass diese dadurch bedienungsunfähig wird. Das wird durch Multi-Threading erreicht. Das Versenden von Schaltkommandos wird in einem eigenen Thread durchgeführt. Diese Kommandos werden pro Vorgang in Batches zusammengefasst. Das Empfangen von Rückmeldungen erfolgt wiederum in einem eigenen Thread. SWT kann architekturbedingt nur Änderungen an der eigenen GUI im Haupt-Thread durchführen. Somit ist Message Passing nötig, um Zustandsänderungen in der GUI des Haupt-Threads visualisieren zu können. Optisch wird das so dargestellt, dass der Gleisplan in schwarz-weißen Strichen dargestellt wird. Durch Loks belegte Gleise werden immer orange dargestellt. Eine sich schaltende Fahrstraße ist schwarz-gelb. Weichen im Umlauf haben blinkende Weichennummern (in einem weiteren Thread als TimerTask implementiert). Ist die Fahrstraße erfolgreich eingestellt, wird diese grün dargestellt. Diese Darstellung ähnelt der eines voll-elektronischen Stellwerks der Realität. Hier werden weitere Sicherungsmaßnahmen genutzt, die im Modellbau schlicht Overkill wären: Ein Farbbalken, der zeigen soll, dass der Bildschirm auch wirklich alle Farben zeigen kann. Das alles nochmal als blinkender Farbbalken. Zusätzlich ist der darstellende Rechner mit zwei Grafikkarten ausgestattet, welche das Gleiche darstellen müssen.

Somit zeigt sich, dass Sicherungstechnik der Realität auch im Modellbau Anwendung findet. Viele Anforderungen zeigen sich erst währen der Implementierungsphase. Man muss einerseits den Entwicklungsprozess darauf abstimmen, andererseits muss die Architektur der Software so gestaltet sein, dass sich erweiterte Anforderungen leicht ergänzen lassen.

Quellen:
http://www.stellwerke.de
http://www.uni-stuttgart.de/iev/index.htm?/vwi/lupse/LUPSE.HTM

Fallstricke bei der Mikrocontroller-Programmierung

 ATmega, Eingebettete Systeme, Modellbau  Kommentare deaktiviert für Fallstricke bei der Mikrocontroller-Programmierung
Jun 052008
 

Seit geraumer Zeit programmiere ich mit einem Kollegen der itemis AG an einer Mikrocontroller-gesteuerten Modellbahnanlage. Im Großen und Ganzen ging die Entwicklung sehr zügig voran. Es kam aber zu einigen Fallstricken, über die ich hier gerne mal berichten möchte. Zuerst bleibt zu erwähnen, dass die Entwicklungsumgebung für die AVR-Mikrocontroller recht gut sind. Die Gesamtanlage ist ein relativ komplexes System. In der Kette wurden Stellwerkssoftware in Java, ein Übertragungskanal über RS232-Schnittstelle an ein CAN-Gateway mit ATmega32 und MCP2515 gekoppelt. Daran sind mehrere CAN-Knoten derselben Hardware miteinander gekoppelt. Die Firmware ist C programmiert. Die Entwicklung aller Komponenten kann sowohl unter Windows, als auch unter Linux erfolgen. Linux hat den Vorteil, dass auch mal Remote entwickelt werden kann.

Nachdem die erste Schaltung gesteckt war, wurde schnell deutlich, dass die Kommunikation zum CAN-Controller nicht mehr stattfand. Offensichtlich ist die Kommunikation über das SPI zusammengebrochen. Ein kurzes Kontrollprogramm zeigt mithilfe eines Oszilloskops, dass die Verbindung tatsächlich zusammengebrochen ist. Ein genauer Blick ins Datenblatt des ATmega32 zeigte schnell, woran es lag: Es gibt einen Pin names Slave Select, der das SPI-Interface von außen in den Slave-Modus versetzen kann. In diesem Fall war er als offener Eingang – also ohne Anschluss – konfiguriert und beschaltet. Die Lösung bestand darin, das /CS-Signal für den MCP2515 als Ausgang daran anzuschließen.


Anzeige:


Ein weiterer Punkt war, dass ein CAN-Knoten nach kurzer Betriebszeit nur durch einen Kaltstart wiederzubeleben war. Die Ursache war schnell gefunden: Als Takt wurde der Taktausgang des MCP2515 verwendet. Der Taktausgang ist nach einem Reset per Default eingeschaltet, kann aber per Software ausgeschaltet werden. Wenn der Takt erst einmal aus ist, besteht per Software keine Möglichkeit mehr, den Takt zu reaktivieren. Ein eigener Quartz für den ATmega32 bestätigte die Vermutung. Warum der Takt ungewollt ausgeschaltet wurde, wurde nicht geklärt. Vermutlich wurde durch eine Race Condition das entsprechende Register mit falschen Daten beschrieben. Ein ausführlicher Code Audit hat das Problem behoben, denn der CAN-Knoten funktioniert jetzt einwandfrei.

Zum guten Schluss haben wir noch ein Problem gehabt, dessen Lösung sich lange hingezogen hat: Es gingen CAN-Frames verloren. Das kann sehr unangenehm sein, denn es wird ein Messaging System vorausgesetzt, dass sich dadurch auszeichnen soll, dass nicht dauernd Informationen und Zustände abgefragt werden sollen (Polling). Es darf also keine Information verloren gehen. Interessanterweise ist dieser Effekt gehäuft beim Konfigurieren der CAN-Knoten aufgetaucht. In diesem Fall ist sporadisch ein Reset aufgetaucht. Ein Reset war nach der Konfiguration gewollt. Dieser hier tauchte aber während der Konfiguration auf. Die erste Vermutung, dass ein fehlkonfigurierter Interrupt eine nicht konfigurierte Interrupt Service Routine anspringt, hat sich nicht erhärtet. Woher kommt aber der Reset? Ein dummer Zufall brachte des Rätsels Lösung, als im Millisekunden genauen Logfile eine Pause von etwa 700 Millisekunden nach dem Ende der Konfigurierung auftauchte. Das ist gefährlich nahe am Timeout des Watchdogs, der mit einer Sekunde aktiv war. Laut Datenblatt dauert das Speichern eines Bytes im EEPROM 8.5 Millisekunden. Das Speichern einer Flash Page (128 Bytes) hingegen nur etwa fünf Millisekunden. In dieser Zeit kann kein Watch Dog Reset durchgeführt werden. Die Lösung bestand also darin, während dieser Zeit den Watch Dog zu deaktivieren. Eines hat die lange Suche aber noch gebracht: Der Code ist jetzt wesentlich effizienter und aufgeräumter.


Anzeige:


Zusammenfassend kann man feststellen, wie eng gerade in Embedded Systems alle Komponenten miteinander abgestimmt sein müssen. Zwei scheinbar unabhängige Komponenten (Watch Dog und EEPROM) haben letztlich doch miteinander zu tun. Es lohnt sich immer, bei Problemen zuerst in Ruhe (!) einen Blick in die Datenblätter zu werfen. Wie bei der SPI-Schnittstelle kommt man dann schnell auf die Lösung. Wenn man mit Interrupts arbeitet, muss man ein Gespühr für Nebenläufigkeit (Threads) haben. So kann man das Zeitverhalten einschätzen und Race Conditions vermeiden. Dead Locks treten hierbei mit geringerer Wahrscheinlichkeit auf, sind aber nicht unmöglich. Dieser kann auf den ATmega Controllern wenigstens mit dem Watch Dog aufgelöst werden. Alles in Allem braucht man einen klaren Kopf und die Geduld, auf die Lösung des Problems hinzuarbeiten.

Erfahrungen mit der OpenSSL Schwachstelle unter Debian

 Linux, Systemmanagement  Kommentare deaktiviert für Erfahrungen mit der OpenSSL Schwachstelle unter Debian
Mai 282008
 

Am 13.05.2008 kam eine Meldung über den Heise-Ticker, dass Debian durch einen Patch eine Schwachstelle bei der Schlüsselgenerierung eingepflegt hat. Das Brisante daran ist, dass dieser Patch vor nahezu zwei Jahren eingespielt wurde.

Was passiert genau dabei? Der Patch hat dafür gesorgt, dass der Zufallszahlengenerator aus den Prozess-IDs gefüttert wird. Der Wertebereich ist unter Linux mit 1-32767 äußerst eingeschränkt. Jede Software, die diesen Generator benutzt, erzeugt somit schwache Schlüsselpaare. Dazu gehört z.B. SSH. Jeder Rechner, der nach dem September 2006 mit Debian oder Ubuntu installiert wurde, generiert somit bei der Installation ein schwaches Host-Key-Pärchen. Jeder Benutzer, der unter Ubuntu oder Debian einen neuen Private Key zum Einloggen generiert hat, hat somit auch ein schwaches Schlüsselpärchen generiert. Damit können die Schlüssel sehr schnell geknackt werden.

Was heißt das in der Konsequenz? Das heißt, dass alle mit Debian oder Ubuntu erzeugten Schlüssel die nach dem September 2006 generiert wurden neu generiert werden müssen. Macht man über den üblichen Weg ein Software Upgrade, wird das für die SSH Host Keys automatisch erledigt. Loggt man sich danach auf so einem aufgefrischtem Rechner ein, wird man abgewiesen mit dem Hinweis, dass in der known_hosts-Datei der Schlüssel nicht mehr passt. Der Eintrag in dieser Datei sollte daher gelöscht werden. Das SSH-Paket hat jetzt ein neues Tool: ssh-vulnkey, mit dem die Schlüssel in der authorized_keys-Datei überprüft werden können. Schwache Schlüssel sollten aus dieser Datei entfernt werden. Zusätzlich lässt ein SSH-Daemon diese Schlüssel beim Einloggen nicht mehr zu. Das Neugenerieren eines Schlüssels ist dabei kein Problem. Eher ist es problematisch, dass der Public Key auf Dutzenden von Rechnern untergebracht sein kann. Ein weiteres Problem sind SSL-Zertifikate, so wie sie für Webseiten verwendet werden. Selbst, wenn man keine selbstsignierten Zertifikate verwendet und Zertifikate kauft, wird der Private Key selbstgeneriert. In der Konsequenz müssen nicht nur die Zertifikate neu generiert bzw. gekauft werden, sondern der Private Key muss komplett neu samt Certificate Request generiert werden.

In einem Unternehmen wie itemis mussten nicht weniger als 30 Zertifkate neu generiert werden. Diese mussten natürlich auch auf den Hosts installiert werden. Hierbei kam wenigstens die modellgetriebene Serverkonfiguration unterstützend zum Einsatz. Die Entwicklungsrechner haben zwar selbstsignierte Zertifikate, aber gerade für die öffentlich zugänglichen Server mussten neue Zertifkate gekauft werden. Zusätzlich kam die Überprüfung der SSH-Schlüssel. Die Software-Upgrades haben die Host Keys automatisch erneuert. Die Überprüfung und der Ersatz der User-Schlüssel hat aber sehr viel mehr Aufwand gekostet. Alles in Allem hat dieser Vorgang zwei Tage Arbeit gekostet.

Hat sich der Aufwand gelohnt? Wer hier nein sagt, handelt schlichtweg grob fahrlässig! Im Moment ist es nur Aufwand. Aber langfristig möchte man sich nicht der Gefahr aussetzen, dass Daten ausspioniert werden oder gar Rechner gehackt werden. Die heutige Meldung begründet diese Sorge. Es lassen sich ohne wenig Probleme von außen Rechner ermitteln, die sich hacken lassen!

Wer mehr zu diesem Thema lesen möchte und wie man mit dieser Schwachstelle umgeht, können Sie hier lesen:
http://www.heise.de/security/Der-kleine-OpenSSL-Wegweiser–/artikel/108001

Es gibt auch ein Tool, das schwache Schlüssel ausfindig machen kann. Es hat aber den Nachteil, dass es nicht alle Schlüssel erkennt. Im Zweifel sollte man lieber einen Schlüssel zu viel als zu wenig neu generieren:
http://security.debian.org/project/extra/dowkd/dowkd.pl.gz

Modellbahnsteuerung fertig entwickelt

 ATmega, Eingebettete Systeme, Modellbau  Kommentare deaktiviert für Modellbahnsteuerung fertig entwickelt
Mai 232008
 

Die Schaltung, um Weichen und Signale über Mikrocontroller zu steuern ist jetzt fertig entwickelt. An einem Steckbrett wurde ein Steuerungsknoten und ein Gateway zusammengebaut und programmiert. Das Gateway ist ein Protokollumsetzer. Die CAN-Frames werden vom PC über RS232 zu diesem Gateway getunnelt und von dort aus über den CAN-Bus weitertransportiert. Die Kommunikation ist dabei bidirektional. Dabei ist zu beachten, dass die Steuerungsknoten sich nicht untereinander unterhalten, sondern jede Information an das Gateway schicken. Das Schalten von Weichen und die Gleisbesetztanzeige werden auch schon korrekt im controller verarbeitet. Jetzt müssen die mehrere Prototypen auf testweise auf Laborplatinen gelötet werden.


Anzeige:


Danach muss die Leistungselektronik entwickelt werden. Diese übernehmen die eigentliche Ansteuerung der Weichen und Signale. Diese Aufgabe ist reine Fleißarbeit. Denn es müssen mindestens 15 Steuerungsknoten, vier Gateways und unzählige Module zur Ansteuerung gelötet werden.

schaltung.jpg

Das Bild zeigt links unten das unscheinbare Steckbrett. Auf der linken Hälfte des Bretts ist der Steuerungsknoten auf der rechten das Gateway. Dieses kommuniziert mit einer kleinen Zusatzplatine über die serielle Schnittstelle am PC mit der Steuerungssoftware. Die Steuerungssoftware kann man auf dem linken Monitor erkennen. Der rechte Monitor zeigt die Entwicklungsumgebung Eclipse. Am rechten Bildrand kann man ein MacBook erkennen. Auf diesem läuft die Entwicklungsumgebung, um die Firmware der Mikrocontroller über JTAG zu debuggen.

Die Steuerungssoftware kommuniziert bereits mit den Mikrocontrollern und kann schon Aufgaben verteilen. Die Steuerungsaufgaben werden in mehreren Stapeln verarbeitet. So dürfen erst Signale geschaltet werden, wenn alle Weichen die gewünschte Fahrstraße eingestellt haben. Erst danach kommt die Gleisfreigabe.

Ubuntu – Eine Erfolgsstory im eigenen Unternehmen

 Linux, Management, Systemmanagement  Kommentare deaktiviert für Ubuntu – Eine Erfolgsstory im eigenen Unternehmen
Feb 292008
 

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.