Jul 072010
 

Das Projekt der modell(-bau-)basierten Eisenbahnsteuerung ist ab sofort auf SourceForge als Open Source verfügbar. Die Startseite ist unter http://sourceforge.net/p/mrw/wiki/Home/ erreichbar. Der Quellcode und die Schaltungen können aus dem Subversion-Repository heruntergeladen werden.

Viel Spaß!


Anzeige:



Apr 012010
 

Seit der Veröffentlichung von EJB3.0 ist der Umgang mit Persistenz erheblich vereinfacht worden. Hintergrund ist die Verwendung sog. POJOs (Plain Old Java Object), die den Entwicklungsvorgang erheblich vereinfachen. Völlig in den Hintergrund ist dabei die Verwendung sog. POPOs (Plain Old Paper Object) geraten. Gerade diese Variante wurde schon von den alten Ägyptern eingesetzt. Es ist der Nachweis gelungen, dass die Persistenz über mehrere tausend Jahre erhalten bleibt. Den Beweis, die Persistenz über diesen Zeitraum aufrecht erhalten zu können, müssen die POJOs noch erbringen, ist die damit einhergehende Technologie erst ein paar Jahrzehnte alt.

Ein POPO wird angelegt.

Bild 1: Ein POPO beim Anlegen. Dieses wird später offline gestellt, um gezielt einen Nachschub-Auftrag durchführen zu können.


Anzeige:




POPOs stehen in ihrer Funktionalität den POJOs in nichts nach, sind doch alle Patterns gemäß des CRUD-Paradigmas verwendbar. Selbst das redundante Schreiben und getrennte Aufbewahren ist damit möglich und somit auch das Lesen parallelisierbar. Auch Transaktionen mit Commit und Rollback stellen kein Problem dar. Einzig die Zugriffszeit ist mit POPOs ein Problem. Der größtenteils biomechanische Zugriff kann unter Umständen mehrere Minuten bis Stunden dauern. Gerade hier spielt die Parallelisierbarkeit mit enormen Zeitgewinn zu Lasten der Betriebskosten eine wesentliche Rolle. Typischerweise sind auch die räumlichen Erfordernisse größer als bei POJOs, wenngleich die klimatischen Bedürfnisse z.B. an Trockenheit und Lichteinflüsse vergleichbar sind.

Ein Storage für POPOs

Bild 2: Dieses Bild zeigt ein Storage für POPOs. Es ist deutlich erkennbar, dass Zugriffe hierauf parallel ablaufen können. Auch der größere Platzaufwand lässt sich hier unschwer erkennen.

Auch in heutiger Zeit sind POPOs nicht aus dem Alltagsleben wegzudenken. Es gibt sogar Varianten für den Embedded Bereich. Auch das Offline-Stellen für z.B. Nachschub-Aufträge lässt sich realisieren und sind sogar praktikabler, als POJO-Varianten. Insgesamt darf man gespannt sein,wie lange sich diese Technologie halten wird.

Ein POPO wird zum Löschen vorgemerkt.

Bild 3: Dieses POPO ist für das endgültige Löschen vorgemerkt. Dieser Vorgang kann durch ein Rollback wieder rückgängig gemacht werden.


Modellbasierte Firmware-Generierung

 ATmega, CAN-Bus, Eclipse, Eingebettete Systeme, MDSD, Modellbau  Kommentare deaktiviert für Modellbasierte Firmware-Generierung
Nov 182008
 

Auf dem Yakindu-Tag wurde die modell(-bau-)getriebene Eisenbahnsteuerung vorgestellt. Dabei wurde der Gleisplan schon modellgetrieben generiert. Bisher war die Firmware der CAN-Knoten als Referenzimplementierung noch klassisch implementiert. Die Kommandoverarbeitung in der Firmware der CAN-Knoten war ein unschönes Stück Spaghetti-Code. Aus diesem Grund wurde ein Zustandsdiagramm gefertigt, das die Betriebszustände der CAN-Knoten enthält. Die eingehenden Kommandos sind als Zustandsübergänge modelliert. Aus diesem Diagramm wird mit Hilfe von openArchitectureWare der Code für die Kommandoauswertung generiert.

Der generierte Code enthält zwar relativ viele Callbacks und switch/case-Anweisungen und bläht den Binärcode um ca. 1,5 KByte auf. Das ist aber nicht weiter schlimm, da jetzt noch Platz für ca. 18 KByte im Flash des ATmega32 vorhanden ist. Ein weiterer Vorteil ist, dass der generierte Code wesentlich übersichtlicher aussieht. Änderungen und Erweiterungen der Steuerkommandos lassen sich jetzt viel leichter einpflegen. Die Integration des generierten Codes in den bestehenden Firmware-Rahmen gestaltete sich als unproblematisch, da der restliche klassisch implementierte Teil nur aus Service-Methoden zur Ansteuerung der Hardware dient.


Anzeige:

Was nützen die smartmontools?

 Linux, Systemmanagement  Kommentare deaktiviert für Was nützen die smartmontools?
Jul 232008
 

Jede Festplatte besitzt einen eingebauten Standard, der vielleicht Jemandem beim Booten als BIOS-Meldung aufgefallen ist, aber noch nicht aktiv genutzt hat: Das S.M.A.R.T. Es ist eine Abkürzung für Self-Monitoring, Analysis and Reporting Technology. Es handelt sich dabei um die Möglichkeit, den Zustand der Festplatte zu überwachen. Hier werden Werte wie Start/Stop-Zyklen, Betriebssystunden und Fehlerzähler verwaltet. Da heutzutage jede Festplatte über diesen Standard verfügt, macht es gerade in IT-Infrastrukturen Sinn, diese Werte permanent zu überprüfen. Selbst bei Desktop-Rechnern oder Laptops macht es Sinn, von Zeit zu Zeit über diesen Standard den Zustand der Festplatte abzufragen.

Unter Linux gibt es für die automatische Überwachung die sog. smartmontools. Diese haben das Abfragetool smartctl, was den Zustand einer Platte abfragen kann. Ferner gibt es noch einen Daemon, der in regelmäßigen Abständen den Zustand der Festplatte(n) abfragt und im Fehlerfalle sogar eine EMail verschickt. Dadurch ist eine engmaschige Überwachung der Festplatten gewährleistet. Einer Studie von Google zufolge, kann auf diesem Wege ein Ausfall einer Festplatte zu 64% Wahrscheinlichkeit rechtzeitig vorhergesagt werden. Häufigster Indikator ist das Bad-Block-Remapping. Wird ein Festplattensektor schadhaft, verwendet die Festplatte automatisch einen Alternativblock. Dieser Vorgang wird von SMART mitgezählt. Häufen sich Remappings, wird es Zeit, die Platte auszuwechseln. Auch ein relativer langsamer Temperaturanstieg über Wochen ist ein Indikator für ein baldiges Ableben der Mechanik. Platten in kühlen Umgebungen (z.B. durch eine Klimaanlage) sollten nicht über 40 Grad überschreiten, tun sie es trotzdem, kann das ein Indikator für einen baldigen Ausfall sein. Was durch S.M.A.R.T nicht erfasst werden kann, ist der Ausfall der Elektronik.

Ich kann nur Jedem IT-Verantwortlichen die smartmontools ans Herz legen. Mir selbst haben die Tools schon viele Crashes vorhergesagt und größeren Schaden abgewendet. Gerade Betreiber von Root-Servern sollten auf den Einsatz der smartmontools nicht verzichten, da gerade dort die eingesetzten Festplatten nicht redundant in RAID-Verbünde eingegliedert sind.

Quellen:
http://labs.google.com/papers/disk_failures.pdf
http://smartmontools.sourceforge.net

Beispiel für ein Mail-Script:

SMART_MSG=/tmp/smart.msgcat > $SMART_MSG

echo "======================================================================" >>$SMART_MSG

# Append the output of smartctl -a to the message:

/usr/sbin/smartctl -a -d $SMARTD_DEVICETYPE $SMARTD_DEVICE >> $SMART_MSG

echo "======================================================================" >>$SMART_MSG

echo "-- " >>$SMART_MSG

echo "System administrator" >>$SMART_MSG

# Now email the message to the user at address ADD.  Solaris and

# other OSes may need to use /bin/mailx below.

/usr/bin/mail -s "$SMARTD_SUBJECT" $SMARTD_ADDRESS < $SMART_MSG

rm $SMART_MSG

und die Einbindung in die smartd-Konfiguration über die Datei smartd.conf:

/dev/sda -d ata -S on -m <EMail-adresse-des-Admins> -a -M exec /root/bin/smartmail.sh

Prototypen der CAN-Controller

 ATmega, CAN-Bus, Eingebettete Systeme, Modellbau  Kommentare deaktiviert für Prototypen der CAN-Controller
Jul 102008
 

Nach der Entwicklung der CAN-Controller, wird jetzt als nächster Schritt das Bauen der Prototypen angegangen. An ihnen kann man das erste Mal testen, wie sich mehrere CAN-Controller an einem Bus verhalten. Erwartungsgemäß funktioniert der CAN-Bus mit mehreren Teilnehmern gemäß Spezifikation. Auch das Flashen einer neuen Firmware funktioniert einwandfrei. Dabei wird ein Bootloader verwendet, der die Firmware über den CAN-Bus entgegennimmt.

Auf dem Bild kann man vier CAN-Teilnehmer erkennen. Man kann inzwischen auch von den itemis Hardware Labs Lünen sprechen.

itemis Hardware Labs Lünen

Als nächster Schritt wird ein Platinen-Layout entwickelt, um die endgültigen CAN-Controller zu erhalten. Desweiteren werden jetzt die Schaltungen für die Leistungselektronik entwickelt. Schließlich sollen die CAN-Controller ja eine Modellbahn steuern.

Subversion im Alltag

 Linux, Systemmanagement  Kommentare deaktiviert für Subversion im Alltag
Jul 032008
 

Subversion wird seit acht Jahren entwickelt und hat im Februar 2004 die erste stabile Version 1.0 erreicht. In dieser Zeit wurden viele Entwickler von den Vorzügen von Subversion überzeugt. Wer CVS kennt, wird sich als Entwickler nicht wensentlich umgewöhnen müssen, da das Konzept Copy-Modify-Merge gleich geblieben ist. Administrativ hat sich allerdings Einiges geändert. Die Versionsdaten werden wie in einer Datenbank gespeichert. Die Backend-Schnittstelle ermöglicht es, verschiedene Backends zu verwenden. Der Vorteil gegenüber CVS ist hier, dass die Dateien nicht direkt manipuliert werden können, da sie nur als Binärdaten vorliegen. Bei CVS werden in einer ASCII-Datei Diffs gespeichert, sodass Manipulationen möglich sind.

In der Praxis hat sich Subversion durch die Stabilität bewährt. Der Verwaltungsaufwand ist nur minimal. Nach dem Einrichten mit svnadmin kann man sofort arbeiten. Es gibt aber noch ein paar Tipps, wie man durch Feintuning die Disziplin der Entwickler fördern kann. Zwei herausragende Punkte sind einerseits die Commit-Meldungen und andererseits die anonymen Commits. Unter Subversion sind leere Commit-Meldungen möglich. Möchte man die Entwicklungsgeschichte nachverfolgen, sind leere Kommentare teilweise frustrierend. Wenn Dutzende von Revisions committed wurden, ohne dass sich scheinbar was geändert hat, muss man ein Difftool bemühen, um Änderungen nachverfolgen zu können. Ähnlich verhält es sich bei anonymen Usern. Subversion lässt bei falscher Konfiguration anonyme Commits zu.

Um leere Commit-Meldungen zu unterbinden gibt es das Mittel der Hook-Skripte. Diese werden zu bestimmten Zeitpunkten während eines Commits aufgerufen. Dadurch können Plausibilitätschecks durchgeführt werden und ggf. ein Commit verhindert werden. Baut man in den sog. pre-commit-hook eine Prüfung ein, die eine leere Meldung verhindert, bleiben die Log-Meldungen deutlich informativer

Das folgende Beispiel zeigt das pre-commit-Skript. Es überprüft, ob mindestens 15 Zeichen und alphanumerischer Text eingegeben wurde.

#!/bin/bash

REPOS="$1"
TXN="$2"

LOG=`svnlook log -t "$TXN" "$REPOS"`
COUNT=`echo $LOG |wc -c`

# Check for at least some chars.
if [ $COUNT -lt 15 ]
then
echo 1>&2
echo 1>&2  "Need at least 15 characters for commit message!"
exit 1
fi

# Check for some clear text characters
echo "$LOG" | grep "[a-zA-Z0-9]" > /dev/null && exit 0
echo 1>&2
echo 1>&2  "Need a clear text message!"
exit 1

Die Konfiguration, um anonyme Commits zu verhindern, muss im Apache erfolgen. In unserer Firma authentifiziert und authorisiert Apache gegen OpenLDAP. Hier kann eine Authentifizierung erzwungen werden und anonymer aber lesender Zugriff erlaubt werden. Bei Schreibzugriffen wird eine Authorisierung gegen eine LDAP-Gruppe durchgeführt.

Die Konfiguration für ein vollständiges Subversion-Repository sieht wie folgt aus:

<IfModule mod_dav_svn.c>

<Location /subversion/webdev>>
        DAV svn
        SVNPath /data/subversion/webdev
        Options +Indexes
        Allow from all

        AuthType Basic
        AuthName "Subversion Repository: webdev"

        AuthzLDAPAuthoritative off
        AuthBasicProvider ldap
        AuthLDAPURL "ldap://master.domain.de slave.domain.de/ou=Users,dc=domain,dc=de?uid?sub?(objectClass=*)"
#       <LimitExcept GET PROPFIND OPTIONS REPORT>
                Require ldap-group cn=webdev,ou=Groups,dc=domain,dc=de
#       </LimitExcept>
        AuthLDAPGroupAttribute memberUid
        AuthLDAPGroupAttributeIsDN off
        SSLRequireSSL
<Location>
</IfModule>

Diese Konfiguration verlangt eine Authorisierung gegen die LDAP-Gruppe webdev. Soll lesender anonymer Zugriff gestattet werden, müssen die # entfernt werden. Zusätzlich wird durch die Direktive SSLRequireSSL SSL-Verschlüsselung verlangt.

Quellen:
www.apache.org
subversion.tigris.org