Über die Winterprobleme der Bahn

Es gibt keinen Zweifel daran, dass die Betriebsqualität der Bahn in den letzten Wochen ziemlich unterirdisch war und viele Reisende unter Verspätungen und Zugausfällen gelitten haben. Ebenfalls gibt es wenig Ausreden dafür, dass der Umgang mit dieser Wettersituation durch die DB AG verbesserungswürdig ist.

Allerdings greifen die in den Medien hinauf- und herunterdiskutierten Analysen und Begründungen oftmals zu kurz und werden der hohen Komplxität des Systems "Bahn" nur unzureichend gerecht.

Im Folgenden werde ich einige Aspkete des Problems tiefergehender beschreiben und versuchen, einige der medialen Grauzonen etwas zu erhellen.

Akt 1 - die eingefrorenen Weichen

Ein häufiger Vorwurf an die Bahn ist der, dass sie die Wartung der Infrastruktur und insbesondere der Weichen vernachlässige. Es wird gerne angeführt, dass sie zu wenig oder zu schwache Weichenheizungen einsetze, wodurch Weichen einfrören und den Betrieb behindern.

Dies ist so nicht richtig. Auf fast allen wichtigen Hauptstrecken sind die häufig befahrenen Weichen mit Weichenheizungen ausgerüstet und die funktionieren nach meiner Beobachtung auch ziemlich gut. Diese sind allerdings prinzipbedingt nur dafür geeignet, frisch gefallenen Schnee oder Flugschnee zu verflüssigen oder sich niederschlagendes Wasser flüssig zu halten. Und dies funktioniert üblicherweise auch! Das Problem ist ein anderes: Insbesondere schnellfahrende Züge sammeln ziemlich viel Flugschnee unter dem Fahrzeug an, der sich nach und nach verdichtet und zu Eis wird. Diese Eisbrocken, manche so groß wie Bierkästen, lösen sich gerne dann, wenn der Zug über eine Weiche fährt und es dabei rumpelt und wackelt. Und einige der Brocken landen dann auch zielsicher in deren beweglichen Teilen. Diese Eismengen durch die Weichenheizung wegzutauen dauert so lange, dass man im dicht befahrenen deutschen Netz zwischendurch mindestens einmal die Weiche umstellen müsste. Und genau das geht dann schief, weil das Erreichen einer gesicherten Endlage der Weiche eben durch die Eisbrocken blockiert ist. Das ist kein neues Phänomen, sondern so alt wie die Eisenbahn selbst.

Allerdings gibt es heute einen wesentlichen Unterschied zu früher: Früher waren die Stellwerke in Bahnhöfen und an der freien Strecke mit Personal besetzt. Ließ sich eine Weiche nicht umstellen, gab es dort entweder einen Bahnwerker, der mit Schippe und Besen die Weiche freikehren konnte oder aber der Fahrdienstleiter ließ sich persönlich herab, und übernahm den Job. Heute werden viele Stellwerke ferngesteuert, oft aus Betriebszentralen, mehrere 100 km entfernt. Dies ist durchaus sinnvoll, denn der damit erzielte Rationalisierungseffekt hilft mit, die Betriebskosten für die Infrastruktur in einem irgendwie beherrschbaren Rahmen zu halten. Solche Störungen, die sich nur durch Manpower und physisches Vor-Ort-Sein lösen lassen, werden durch diese Betriebsorganisation allerdings zum Problem.

Wie führt diese Situation nun zu Verspätungen?

Einerseits durch die Weichenstörung an sich, wenn Züge dadurch entweder gar nicht mehr oder z.B. eingleisig verkehren müssen und somit die Streckenkapazität deutlich reduziert wird

Andererseits werden einige Weichen bei Winterwetter vorsichtshalber gar nicht mehr umgstellt. Sie werden dann auf einen Fahrweg festgelegt, der für alle Züge geeignet ist. Auf den Unterwegsbahnhöfen von einigen Schnellfahrstrecken bedeutet dies, dass alle Züge auf den außenliegenden Bahnsteiggleisen verkehren. Dies wiederum bedeutet, dass sie von den mittig liegenden, durchgehenden Hauptgleisen abzweigen müssen, was oft nur mit 60 km/h oder 80 km/h möglich ist. Ein ICE, der sonst mit 250 km/h oder 300 km/h durch den Bahnhof durchfährt, muss also abbremsen und dann wieder beschleunigen, was deutlich Zeit frisst.

Abhilfe wäre nur möglich, wenn man in der Winterzeit für kritische Betriebsstellen zusätzliche Instandhaltungskräfte vorhalten würde, die ortskundig sind und ohne lange Anfahrtswege schnell mal eine Weiche freischippen bzw. freikehren können. Aber das kostet Geld - und offenbar ist es betriebswirtschaftlich günstiger, ausgefallene und verspätete Züge in Kauf zu nehmen. Vielleicht wäre es aber an der Zeit das Problem volkswirtschaftlich zu sehen. Und dann könnte sich sowas plötzlich doch lohnen.

Akt 2 - winteruntaugliche Fahrzeuge

Ebenfalls oft gehört ist der Vorwurf, diese neumodischen Züge wären nicht mehr robust genug für einen Wintereinsatz. Ich bin der Meinung: Das stimmt sogar. In der Tat sind viele moderne Triebwagen empflindlicher als eine gute alte russische Diesellok oder eine Einheits-Eletrolok von 1956.

Allerdings haben sich auch die Anforderungen an moderne Fahrzeuge deutlich kompliziert. Ein aktueller ICE soll nicht nur 300 km/h fahren können, dabei laufruhig sein, klimatisiert und kompatibel zu Strom- und Signalsystemen in vier Ländern, er muss zudem auch leicht sein, günstig in Anschaffung und Unterhalt und bestimmte Normen zu Crashsicherheit, EMV und Geräuschentwicklung erfüllen. Bei Nahverkehrsfahrzeugen kommt die oftmals geforderte Niederflurigkeit hinzu, die zwar das Einsteigen für mobilitätseingeschränkte Fahrgäste einfacher macht, aber die Bodenfreiheit der Fahrzeuge reduziert und sie anfälliger für das Steckenbleiben bei stark zugeschneiten Gleisen macht. Diese teilweise einander widersprechenden Anforderungen lassen sich nur erfüllen, wenn man die Konstruktion in Richtung der technologischen Grenzen verschiebt. Solche Konstruktionen sind dann typischerweise anfälliger gegen äußere Einflüsse, wie z.B. die Einschläge von den o.g. Eisbrocken, die sich während der Fahrt lösen. Unter einer älteren Lok gab es einfach keine Einrichtungen, die sich davon nennenswert beeinflussen ließen - 8 mm - 10 mm dicken Stahlblechen ist der Einschlag eines Eisbrockens relativ egal.

Ganz anders verhält es sich mit aktuellen Fahrzeugen, deren Bauch mit Antennen, Antriebscontainern, Kabelverbindungen und Leitungen gespickt ist und wo immer öfter auch Materialen wie GFK und Aluminium eingesetzt werden.

Hier hilft nur

a) die Reduktion der Höchsgeschwindigkeit - momentan auf 160 km/h oder 200 km/h - um die Auswirkungen der Einschläge zu mindern (was allerdings wieder Verspätungen verursacht)

b) die Vorhaltung einer ausreichenden Betriebsreserve, um ausgefallene Zuggarnituren zu ersetzen

c) eine Durchleuchtung aller Schwachstellen, um bei zukünftigen Fahrzeugen die Problembereiche entschärfen zu können.

Insbesonder mit Punkt b) hat die Bahn momentan ein massives Problem. Zum einen zwingt auch hier die Betriebswirtschaft, möglichst wenig Reserve vorzuhalten, die sonst ungenutzt herumsteht. Zum anderen hat die Bahn aktuell ein permanentes Verfügbarkeitsproblem bei den ICE-T und ICE-3. Da bei diesen Baureihen die Radsatzwellen zu schwach dimensioniert sind, müssen diese Fahrzeuge sehr oft zur Durchsicht in die Werkstatt, was die verfügbare Fahrzeugdecke reduziert. Diese reicht schon unter entspannten Verhältnissen kaum aus, um den tägichen Bedarf zu decken. Kommen dann noch Ausfälle durch Schäden dazu, sind entfallende Züge vorprogrammiert. Bei den älteren IC-Garnituren sieht es nicht anders aus. Hier bleibt nur die Hoffnung, dass sich nach Umbau der ICE-3 und ICE-T auf neue Radsatzwellen die Situation Sommers wie Winters allmählich entschärft. Dies wird aber erst in der Mitte dieser Dekade spürbar werden. Langfristig muss die Bahn endlich die seit Jahren in der Diskussion stehenden ICX bestellen, die die erste Generation ICE und die IC-Garnituren ablösen sollen.

Bei Punkt c) muss man sich allerdings wirklich fragen, wieso manche moderneren Fahrzeuge solch auffällige Schwachstellen aufweisen. So sieht man insbesondere im Winter häufig Züge mit offenen Bugklappen herumfahren, wodurch die Kupplung in der Fahrzeugschnauze komplett vereist und die ICE-2, ICE-3 und ICE-T-Halbzüge nicht mehr wie fahrplanmäßig vorgesehen gekuppelt werden können. Auch dies führt zu Ausfällen und massiven Verspätungen. Ist es so unverhältnismäßig aufwändig, sowohl Bugklappen als auch Kupplungen beheizbar auszuführen? Ebenso auffällig sind die zahlreichen Ausfälle von Antriebsanlagen insbesondere bei der S-Bahn Berlin. Diese scheinen sehr anfällig für Flugschnee und Feuchigkeit zu sein und sind damit offensichtlich nicht "bahnfest".

Akt 3 - Zusammenfassung

Mein Resümee aus den obigen Ausführungen und die daraus entstehenden Forderungen ergeben sich wie folgt:

• Der personelle Rückzug aus der Fläche funktioniert für den Normalbetrieb, kommt aber an seine Grenzen bei besonderen Witterungsbedingungen - bei diesen muss die Bahn zwingend zusätzliches Personal bereitstellen, um Störungen schneller beheben zu können
• Die Fahrzeugreserven sind insbesondere im Fernverkehr gefährlich gering. Hier wäre der Bahn angeraten, die Kapazitätsreserven aufzustocken und möglichst schnell den Engpass bei der IC/ICE-Flotte zu reduzieren. Auch die Neubeschaffung der ICX muss jetzt zügig durchgeführt werden.
• Bei den bestehenden Fahrzeugen müssen die Schwächen analysiert und zügig behoben werden.

Sendepause

Aus privaten Gründen habe ich momentan leider nicht so viel Blog-Zeit, wie ich gerne hätte, daher schleppt es hier etwas mit Postings.

Demnächst erscheint aber mal wieder was - und zwar ein Beitrag zum Unterschied zwischen generischen und spezifischen Systemspezifikationen. Und weil der von mir kommt, natürlich am Beispiel der Eisenbahntechnik. Genauer: Warum sich Systemspezifikationen von Fahrzeugsteuerungssystemen von denen der ortsfesten Leit- und Sicherungstechnik üblicherweise erheblich unterscheiden.

Weihnachten is' da lang!

Da hat der Steve mich ein bisschen enttäuscht, zumindest, wenn man meine Hoffnungen von letzter Woche zu Grunde legt. Das neue iLife '11 ist ja ganz nett - aber damit über die Hälfte des Special Events zu füllen, fand ich etwas übertrieben.

Sehr viel lieber hätte ich noch mehr über Mac OS X 10.7 "Lion" erfahren. Und vor allem darüber, was der Löwe so unter der Haube hat. Darüber gab es ja nur zwei indirekte Hinweise: Erstens, dass man in Zukunft seine Arbeit nicht mehr explizit speichern muss und zweitens (hängt damit zusammen), dass Programme exakt so wieder hochkommen, wie man sie verlassen hat. Das kann man natürlich auch rein auf Applikationsebene oder durch zusätzliche Mid-Level APIs im OS realisieren, aber: so wie ich Apple einschätze, werden sie sowas weiter unten im Betriebssystem reinlöten.

Vielleicht liege ich mit der folgenden Einschätzung komplett daneben, aber vielleicht auch nicht. Und selbst wenn, erlaube ich Apple großmütig, sich an meinen Vorstellungen zu orientieren. :-)

Meiner Meinung nach könnten die oben genannten Features auf umfangreiche Änderungen am Dateisystem hindeuten, mit dem solcherlei ergötzliche Funktionalität quasi gratis und franko verfügbar würde. Würde man ein Dateisystem (nein, ich sage nicht ZFS) einsetzen, das Snapshots auf Dateiebene (geht das mit ZFS? Und wenn nein, gibt es ein Dateisystem, das das kann?) ermöglicht, wäre es ein Leichtes nach jeder substanziellen Änderung der Anwendunsgdaten einen solchen anzulegen.

Dadurch könnte der Zustand der Anwendung quasi-kontinuierlich gesichert werden (unendliche Photoshop-Historie, anyone?), ohne dass der Platzverbrauch dafür komplett durch die Decke geht. Der automatische Restore des Anwendungszustands nach Neustart ist dabei nur ein schnieker Nebeneffekt. Ein solches Konzept würde auch die folgenden Nettigkeiten ermöglichen:

• Nahtlose Integration in Timemachine: die zurückliegenden Snapshots werden auf das TM-Volume repliziert, idealerweise unter Nutzung von blockweisen De-Duplication-Features des Dateisystems. Damit könnte man vermeiden, dass eine 2-byte-Änderung in einer 1 GB großen Datei bedeutet, dass 1 GB auf das Backup-Medium geschaufelt werden müssen.
• Die Verfügbarkeit definierter Snapshots könnte das Syncing (ja, genau das, worauf ich bei der Keynote den ganzen Abend gewartet habe, himmelherrgott...) mit mobilen Geräten oder "der Cloud" deutlich vereinfachen. Entsprechende Konzepte gibt es ja z.B. schon bei GitHub oder ähnlichen verteilten Versionsverwaltungen.
• Apropos GitHub: Wenn man eine Datei innerhalb eines solchen Konzepts unter einem anderen Namen abspeichert, könnte man das mit ein bisschen gutem Willen als Branch der originalen Datei ansehen. Und was sich dann an Sharing- und Merging-Features ergeben würde, sprengt gerade ein bisschen meine Vorstellungskraft.

Keine Ahnung, wie Apple dieses Thema wirklich angehen wird. Aber es sieht hinterher wahrscheinlich auch noch gut aus.

Was ich mir von Steve wünsche

Morgen um 19:00 Uhr soll es soweit sein: Steve Jobs wird in Cupertino irgendetwas präsentieren, das mit dem Mac und einem Löwen zu tun hat. Aller Voraussicht nach dürfte es sich bei diesem Etwas um einen ersten Blick auf Mac OS X 10.7 handeln, das sehr wahrscheinlich den Codenamen "Lion" tragen wird. Glaubt man dem letzten Stellengesuch von Apple, soll dieser Release etwas "revolutionär neues" beinhalten.

Wenn ich es mir aussuchen dürfte, dann hätte ich gerne die folgende Revolution:

Generisches, universelles Syncing, über alle Device- und Netzwerkgrenzen hinweg. Das, was iSync mal hätte werden können, aber nie wurde.

Ich stelle mir etwas vor, dass es mir ermöglicht, ausgewählte Daten immer und überall verfügbar zu haben. Egal, ob ich zu Hause bin, im Zug oder im Café unterwegs. Egal, ob auf dem iPhone, iPod oder MacBook. Ich will meine Filme sehen können, egal wo ich bin, ich will an meine Dokumente kommen, meine Adressen, meinen Kalender und meine Musik - ohne wissen zu müssen, ob man jene Information über iTunes und Kabel abgleichen muss und die andere übers Netz, mit iDisk oder DropBox. Ohne Gedanken verschwenden zu müssen, ob der Kram in der Cloud liegt oder auf einer Festplatte irgendwo. Ohne Utilities von Klitsche A und ohne Anmeldung bei Google. Dafür aber mit Verschlüsselung, Versionsverwaltung, Data-Deduplication und Integration in TimeMachine.

Mal sehen, was der Steve mir morgen davon erfüllt.

Wie die Eisenbahn funktioniert (ganz grob)

Gespräche mit Freunden sind ja immer großartig. Durch ein solches Gespräch kam ich ja neulich schon darauf, was Systems Engineering eigentlich ist. Diesmal ging es bei ein paar Bieren darum, wie die Eisenbahn funktioniert. Nicht im Detail, sondern eher ganz, ganz grob und allgemein, aus der Vogelperspektive. Als Vergleichsgegenstand habe ich mich auf den Straßenverkehr bezogen, denn den kennt ja fast jeder. Sei es als Fußgänger, Radfahrer oder Autofahrer.

Kurze These:

• Im Straßenverkehr ist erstmal alles erlaubt und möglich, so lange es nicht untersagt oder reglementiert ist
• Bei der Eisenbahn ist erstmal alles untersagt, bis es explizit erlaubt wird

Längere Erklärung:

Der Straßenverkehr basiert auf vielen individuellen Einzelentscheidungen der Verkehrsteilnehmer. Ich als z.B. Autofahrer kann zunächst mal vollkommen frei entscheiden, wann ich losfahre, wohin ich fahre, welchen Weg ich dabei wähle und wie schnell ich unterwegs sein will. Einschränkungen dieser Freiheit finden auf zwei Arten statt: Einerseits durch Regeln und Verbote, andererseits durch sicherheitsgerichtete Notwendigkeiten. In die erste Kategorie fallen beispielsweise Ampeln (der Fachmann sagt Lichtsignalanlagen oder Lichtzeichenanlage), die konkurrierende Wünsche zur Benutzung eines Stücks Straße (z.B. der nachfolgenden Kreuzung) aufdröseln, Geschwindigkeitsbeschränkungen oder Einbahnstraßenregelungen. Ein Beispiel für die zweite Kategorie ist das Abstandshalteverfahren, das jeder Autofahrer mehr oder weniger gut automatisch ausführt und das verhindert, das sich die Leute massenhaft gegenseitig hinten reinfahren.

Rein und Raus oder Durch und Weg

Dieses Posting dreht sich zumindest indirekt um Stuttgart 21, das heiß diskutierte und heftig umstrittene Bahnhofs-Neubauprojekt in der Schwaben-Metropole der Hauptstadt Baden-Württembergs. Und da man bei dem Thema quasi sofort auf dünnem Eis steht, gibt's zunächst mal folgenden Disclaimer: Ich selbst habe zu dem Vorhaben zwar ein Baugefühl, aber keine (eisenbahntechnisch-)fachlich fundierte Meinung. Dies liegt vor allem daran, dass ich die verschiedenen, zusammengehörigen Neubauprojekte noch nicht genau genug verstanden und analysiert habe, um dieses Bauchgefühl entweder zu untermauern oder zu revidieren. Dieser Beitrag enthält also kein Bekenntnis zu der einen oder der anderen Position.

Der Sinn dieses Postings liegt vielmehr darin, dass ich mit zwei etwas durcheinandergehenden Aussagen zu Kopf- und Durchgangsbahnhöfen aufräumen möchte, die mir kürzlich begegnet sind. Vielleicht hilft dieser Beitrag, die Diskussionen an anderer Stelle zu versachlichen. Hier nun die beiden Aussagen, mit denen ich mich auseinandersetzen will:

1. "Durch moderne Fahrzeugtechnik verursachen Kopfbahnhöfe nicht mehr so viel Zeitverlust." - Dieser Aussage würde ich eher zustimmen. Ein Großteil der Fern- und Nahverkehrszüge fährt heute als Triebwagen oder als Wendezug. Erstere haben sowieso einen Führerraum hinten und vorne. Bei Letzteren ist an einem Zugende die Lok und am anderen ein Steuerwagen, der die Lok am anderen Ende fernsteuert. Damit entfällt die zeitraubende Notwendigkeit, nach Einfahrt des Zuges die eine Lok ab- und die andere ankuppeln zu müssen. Ausserdem spart man sich die kapazitätsfressenden Rangierfahrten, um die Loks in die bzw. aus der Abstellanlage zu bekommen. Heute kann man einen Zug in einem Kopfbahnhof etwa in der Zeit abfertigen, die nur wenig über der liegt, die man eh zum Reisendenwechsel braucht. Allerdings ist der Fahrtrichtungswechsel nicht immer unproblematisch. Beim Aufrüsten des anderen Führerraums kann es durchaus zu Störungen kommen, die eine Weiterfahrt verzögern können. Das ist aber - zum Glück - nur sehr selten der Fall.
   


2. "Durch moderne Signaltechnik lassen sich Fahrgeschwindigkeiten auch bei Kopfbahnhöfen erhöhen." - Diese Aussage ist hingegen eher kritisch zu sehen. Grundsätzlich ist es so, dass die Obergrenze der Fahrgeschwindigkeit durch die Trassierungsparameter (also die geometrische Raumkurve) der Gleise und Weichen bestimmt ist. Kurz: Je enger die Radien sind, desto langsamer muss man fahren, damit Seitenbeschleunigung und Ruck nicht zu groß werden. Daran kann auch die Signaltechnik erstmal nichts ändern. Erschwerend kommt hinzu, dass bei Kopfbahnhöfen oftmals recht gedrungene Spurpläne mit kleinen Abzweigradien üblich sind. Schnellfahren ist damit ganz prinzipiell schon schwieriger, als bei gestreckten Durchgangsbahnhöfen.
   
   Erschwerend kann bei älterer Signaltechnik nun allerdings hinzukommen, dass man die aus der Trassierung vorgegebene Obergrenze der Fahrgeschwindigkeit nicht ausreizen kann. Dies liegt daran, dass man aus Vereinfachungsgründen beispielsweise auf allen Fahrwegen pauschal 40 km/h vorgibt, obwohl man auf einzelnen Fahrbeziehungen durchaus z.B. 60 km/h fahren könnte. In diesem Fall kann eine erneuerte Signaltechnik tatsächlich Vorteile bewirken.
   
   Ein Problem haben aber alle Kopfbahnhöfe, egal wie modern die Signaltechnik ist: Bei der Einfahrt in Stumpfgleise (also Gleise mit Prellbock am Ende) ist - zumindest im Bereich der ehemaligen Deutschen Bundebahn - ab einem bestimmten Punkt (meist am Bahnsteiganfang) nur noch eine Geschwindigkeit von 30 km/h zulässig [Ril301, 301.0301, S. 4], [Ril408, 408.0451]. Das ist ziemlich wenig, wenn man bedenkt, dass modernes Fahrzeugmaterial bei optimalen Verhältnissen auch dann zielsicher zum Stehen gebracht werden kann, wenn man am Bahnsteiganfang noch 80 oder 100 km/h drauf hat. Zusammenfassung: Der Einfluss moderner Signaltechnik auf die Betriebsabwicklung von Kopfbahnhöfen ist eher gering.
   

Weiterhin hat ein Kopfbahnhof den immanenten Nachteil, dass die Zulaufstrecken immer nur in einer Richtung direkt zum Bahnhof führen können. Kommt man aus einer der "falschen" Richtungen, muss man zwingend immer einmal um den Pudding fahren. Bei Durchgangsbahnhöfen hat man immerhin schon mal zwei Himmelsrichtungen, aus denen man direkt zum Bahnhof kommt. Diese Eigenschaft kann aber - je nach lokalen Gegebenheiten - sehr unterschiedlich ausgeprägt sein. In weit dies in Stuttgart relevant ist, möchte ich aus o.g. Gründen hier nicht bewerten.

[Ril301] Richtlinie 301: Signalbuch; Hrsg.: DB Netz AG, 2008
[Ril408] Richtlinie 408: Züge fahren und Rangieren, Hrsg.: DB Netz AG, 2009

Warum die Angst vor Google Streetview lächerlich ist

Heute gibt es mal nichts zum Systems-Engineering, sondern einen kurzen Exkurs in ein Thema, das mich in den letzten Wochen wirklich aufgeregt hat: Die irrationale, medial aufgebauschte Panikmache vor Google Streetview.

Man hatte ja zeitweise den Eindruck, dass - sobald der Dienst online ist - Einbrecher sofort flächendeckend alles mitgehen lassen, was nicht angedübelt und/oder bei drei auf den Bäumen ist. Auch werden alle Mitmenschen, die es mit der Treue nicht so randscharf nehmen, sofort auffliegen, die Scheidungsraten werden explodieren und subsequent eine Generation verwahrloster Kinder heranwachsen.

Das alles wird nicht passieren, denn:

1. Google Streeview ist nicht live (ja, es gibt wirklich Leute, die das glauben. Wenn man denen GoolgeEarth zeigt, gehen die auch raus und winken nach oben [der Gag ist schamlos aus Bits und So #213 geklaut]). Einbrecher interessieren sich aber im Allgemeinen nicht für zwei Jahre alte Fotos.
2. Einbrecher interessieren sich auch im Speziellen nicht primär für die Fassade eines Hauses. Sondern dafür, wer wann wo nicht daheim bzw. anwesend ist. Hint: StreetView ist nicht live.
3. Viel interessanter für dunkle Gesellen ist übrigens Google Maps oder Google Earth. Da kann man nämlich schick von oben sehen, was hinter der Hecke, hinter dem Haus und neben dem Grundstück so los ist.
4. Auch heute kann man sich schon einen Eindruck von der Lage und dem Aussehen eines Hauses verschaffen! Ehrlich! Das geht! In Echtzeit! Und sogar in 3D! Die Dienste die man dazu braucht heißen "Hingehen" und "Anschauen". Es gibt sogar ein Upgrade für die Speicherung der Bilder, aber dafür braucht man Zusatzhardware. Die ist unter dem Namen "Fotoapparat" im Fachhandel erhältlich.
5. Und zuletzt: Wenn man durch Streetview beim Fremdgehen ertappt wird, geschieht einem das a) zu recht und b) ist das arg peinlich, oder?

Und um den Paranoikern noch eins mitzugeben: Hier wohnt Frau Merkel. Viel Spaß in der kardiologischen Notaufnahme.

Lückenschlussmaßnahme

Oder: "Ceci n'est pas une pipe."

Immer, wenn mich jemand fragt, was ich "so beruflich mache", dann finde ich das relativ schwer zu erklären. Vor einigen Tagen saß ich mit einem fachfremden Freund bei einigen Bieren zusammen und kam dabei auf folgende Erklärung: Ich versuche, Lücken klein zu halten. Prinzipiell geht es beim Systems-Engineering und insbesondere beim Anforderungsmanagement genau darum. Ich versuche das in den folgenden Absätzen zu erklären.

Als Einstieg will ich ein Gedankenkonstrukt vorstellen, dass sich mit den grundlegenden Unterschieden zwischen der Realität und der Vorstellung der Realität auseinandersetzt.

Prinzipiell ist es so, dass jedes reale Objekt ziemlich komplex ist, auch ein einfaches, wie z.B. die Mehrfachsteckdose, an die mein Notebook gerade angeschlossen ist. Alleine die äußere Form der Steckdose ist in der Realität wahrscheinlich zu kompliziert, um sie vollständig zu beschreiben.

"Moment mal, das ist doch nur ein Kasten!" mag man jetzt einwenden, aber genau das stimmt eben nicht. Die Steckdose ist in der Realität kein Kasten (oder Quader, um es korrekt zu bezeichnen). Die 12 Kanten - die dann genau gerade sein müssten - sind alles andere als genau gerade, sondern um zehntel Millimeter gebogen und geschwungen, durch Fertigungsungenauigkeiten, Temperatureinflüße oder weil man sich irgendwann mal aus Versehen draufgesetzt hat. Geht man noch näher heran, stellt man fest, dass die Oberfläche leicht aufgeraut ist, also aus Millionen und Abermillionen von kleinen Einbuchtungen besteht. Alleine die daraus entstehende dreidimensionale Fläche vollständig zu beschreiben, dürfte nicht mehr machbar sein.

Dennoch reicht es in der überwiegende Zahl der Fälle aus, wenn man die Steckdose als Kasten auffasst, der 15 Zentimeter lang ist, 5 cm breit und 3 cm hoch und aus rauem Plastik. Dieses einfache Modell repräsentiert alle Eigenschaften hinreichend genau um beispielsweise zu entscheiden, ob man das Teil hinter den Fernseher gefummelt bekommt oder eben nicht.

Will sagen: Was wir im Kopf haben, ist niemals das Ding an sich oder eine vollständige, identische Abbildung davon, sondern ein vereinfachtes Modell. Anders könnten wir mit der Komplexität unserer Welt gar nicht umgehen. Und das gilt nicht nur für Mehrfachsteckdosen, Legosteine und Vollkornschrippen, sondern erst recht für Verkehrsflugzeuge, das Handynetz oder Hochgeschwindigkeitszüge. Es hat aber genau so auch für die Beziehung zur Freundin, die Dynamik in unseren sozialen Netzen oder für unser politisches System Gültigkeit.

Wenn wir über Sachverhalte nachdenken, sie kommunizieren oder dokumentieren, machen wir das anhand von vereinfachten Modellen.

Nach [STA] machen dabei die folgenden drei Merkmale ein Modell aus:

• Abbildung: Ein Modell ist eine Repräsentation eines wie auch immer gearteten Objektes
• Vereinfachung: Das Modell gibt nur die für die momentane Aufgabenstellung relevanten Eigenschaften wieder
• Pragmatik: Das Modell ist nur für einen bestimmten Zeitraum, für bestimmte Nutzer und unter bestimmten Randbedingungen anwendbar

Das trifft es eigentlich ziemlich gut.

Gut, aber was hat das nun alles mit der Ausgangsfragestellung zu tun?

Dazu ein kurzer Exkurs in die technische Welt. Dort macht man oftmals genau das, was ich zwei Absätze weiter oben beschrieben habe: Man durchdenkt, kommuniziert und dokumentiert komplexe technische Systeme. In meinem konkreten Fall mache ich das überwiegend für Systeme, die es noch nicht gibt. Ich erstelle Anforderungsspezifikationen; das sind Dokumente, die beschreiben, was ein zukünftiges System einmal machen soll.

Anders als bei der Mehrfachsteckdose von oben steht dabei meist nicht die äußere Form im Mittelpunkt der Betrachtungen, sondern das Verhalten eines Systems. Und auch hier gilt: Das Verhalten der Systeme ist in der Realität mit all den physikalischen Eigenschaften, allen Abhängigkeiten und Emergenzen viel zu komplex, um es vollständig zu beschreiben.

Deswegen werden auch hierbei Modelle verwendet, überwiegend jedoch implizit. Z.B. dadurch, dass jeder Beteiligte - ob er will oder nicht - ohnehin ein gedankliches Modell des zukünftigen Systems in seinem Kopf hat oder dadurch, dass man durch z.B. eine schriftliche Dokumentation ein solches implizites Modell erschafft.

Das Problem dabei ist nun, dass alle diese Modelle - wie oben festgestellt - Vereinfachung des realen Systems darstellen, dieses also nicht 100%ig genau beschreiben. Es verbleibt eine Lücke zwischen dem System, so wie es durch das Modell abgebildet ist und dem System, wie es später in der Realität einmal tatsächlich sein wird. Das bedeutet auch, dass das Verhalten eines Systems in dieser Lücke undefiniert ist.

Und genau das kann zum Problem werden. Die Systeme, mit denen ich mich beschäftige haben ziemlich oft Sicherheitsverantwortung (im Sinn der Betriebssicherheit), was bedeutet, dass ein funktionales Fehlverhalten unangenehme Folgen kann. Entweder, weil die Aufzugsteuerung plötzlich entscheidet, die Kabine trotz offener Tür losfahren zu lassen. Oder weil die Waschmaschine nicht erkennt, dass mehr Wasser nicht hineinpasst und dieses sich daraufhin in der Küche verteilt. Und bei den oben angesprochenen Hochgeschwindigkeitszügen und Verkehrsflugzeugen kann ein funktionales Fehlverhalten dann nicht nur unschön werden, sondern katastrophale Folgen haben.

Und damit kommen wir endlich zu dem, was ich "so beruflich mache". Ich versuche, die Lücke zwischen Modell und Realität an den entscheidenden Stellen so klein wie möglich zu halten. Damit soll hinreichend unwahrscheinlich werden, dass das, was da drin dann eben nicht definiert ist, etwas wirklich Schlimmes anrichtet.

Eine wirtschaftliche - nennen wir es mal "Herausforderung" - ist dabei, dass das um so aufwändiger (und damit: teurer) wird, je kleiner die Lücke schon ist. Es ist daher sinnvoll, erst einmal die Bereiche des Systemverhaltens zu identifizieren, die potenziell bedeutend für die Sicherheit und Benutzbarkeit des zukünftigen Systems sind. In diesen Bereichen gibt man sich bei der Spezifikation der Anforderungen dann besondere Mühe, wohingegen in den eher unwichtigen Bereichen auch ein stark vereinfachtes Modell des zukünftigen Systems ausreicht (siehe die Steckdose oben, siehe Bild unten).

Realität und Modell, mal ganz einfach

Eine Möglichkeit, an den entscheidenden Stellen eine sehr gute Abbildung des zukünftigen Systemverhaltens zu erreichen, besteht darin, sich ganz explizit auf Modelle zu stützen. Wenn man eh ein Modell in den Köpfen der Beteiligten erzeugen muss, bietet es sich an, dieses gleich mittels einer für Alle gleichen Vorlage zu tun.

Diese Modell bestehend dabei üblicherweise nicht aus Pappe und Sperrholz, sondern es sind virtuelle Modelle, die in einer spezifischen Modellierungssprache beschrieben sind. Ein Beispiel für eine solche Modellierungssprache auf Systemebene ist die Systems Modeling Language (SysML), die als erweiterte Teilmenge von der Object Management Group spezifiziert wird.

In loser Folge möchte ich daher an dieser Stelle Ansätze zur Beschreibung von Systemen durch die SysML vorstellen. Im Vordergrund sollen dabei die Erfahrungen stehen, die ich in den letzten Jahren mit dieser Beschreibungssprache gesammelt habe. In einer Art Vermittlung von Best-Practices möchte ich gerne zeigen, wie sich bestimmte, immer wiederkehrende Aufgabenstellungen am einfachsten und elegantesten lösen lassen.


Literaturquellen:
[STA] Stachowiak, Herbert: Allgemeine Modelltheorie. Springer, Wien, 1973

Null-Punkt-Vier

Ich habe jetzt zwei Wochen lang die Version 0.4 des iSync-Plugins getestet und es scheint soweit gut zu funktionieren. Jetzt macht nur einer meiner Geburtstagseinträge Probleme. Alle anderen werden in beiden Richtungen einwandfrei synchronisiert. Eine Verbesserung um 75%!

Wie gehabt gibt es den Installer für das Plugin und die Projektdatei für den iSync Plug-In Maker.

Nokia 6700 iSync-Plugin (zip-Archiv)
Projektdatei (zip-Archiv)

Feedback ist wieder gerne gesehen. Lizenz ist wieder die GPLv3.

Weiße Leoparden

Ach ja: Ich bin leider noch nicht auf 10.6 umgestiegen. Daher kann ich auch nicht prüfen, ob/warum/wann/weshalb/unter welchen Umständen/wtf das Plugin dort nicht funktioniert.

"Wenn ich mal mehr Zeit habe" [tm] mach ich das Upgrade und dann kann (vielleicht) auch irgendwann die Schneekatze mit dem Nokia 6700.

Andere Möglichkeit: Wenn ich die 0.4 fertig habe, kann irgendwer das iSync-Plugin-Maker Projekt runterladen und auf 10.6 ein Plugin erstellen. Vielleicht hilft das ja schon. So wegen Binärkompatibilität und so.

Nach langer Stille der Schuß

Jaja, ich weiß. Lange nix gepostet und so.

Mein Fehler.

Aber danke für die Kommentare zum Nokia-6700-Plugin! Auf Grund der Rückmeldungen arbeite ich gerade an einer Version 0.4, die ein bisschen besser mit Geburtstagen klarkommen sollte. Stay tuned.

Übrigens: ein Update der Nokia-Firmware auf die Version V 10.50 hat bei mir auf einen Schlag sämtliche Sync-Probleme via Bluetooth hinweggefegt. Das Ganze rockt jetzt recht stabil. Die Probleme einiger User mit Kommentaren bei Kontakten konnte ich übrigens bei mir nicht nachvollziehen. Aber ich bleibe dran.