Mobiler Rangierassistent

Einsatz von Java und GPRS auf PDAs
Kommentare

Die Entwicklung einer dialogorientierten Anwendung für PDAs stellt für sich schon eine Herausforderung dar: Benutzerergonomie trotz eingeschränkter Display-Fläche, Software-Updates, geringe Rechenleistung und begrenzter Speicher – um nur einige Punkte zu nennen – müssen für eine professionelle Anwendung auf mobilen Endgeräten berücksichtigt werden. Die Java- und GPRS-basierte Anwendung CDD (Cargo Digitale Datenkommunikation) ist eine solche Anwendung und bei der Railion Deutschland AG im Einsatz.

Im Dezember 2001 schrieb die damalige Deutsche-Bahn-Tochter DB Cargo (heute Railion Deutschland AG) das System CDD aus. Aufgrund auslaufender Funklizenzen musste das gesamte Altverfahren MDE (Mobile Datenerfassung) abgelöst werden. Eine Umrüstung des Altverfahrens auf eine neue Funktechnologie – unter Beibehaltung der restlichen Komponenten – war nicht möglich. Die Ausschreibung von CDD umfasste neben der Einführung und dem Betrieb der Funktechnologie GPRS folgende weitere Pakete:

  • Industrietaugliche PDAs (IP-Schutzklasse 54) und Kommunikationsserver zur Anbindung an die bestehenden Backend-Systeme
  • Client-Server-Software-System, mit dem die bestehende fachliche Anwendung des Altverfahrens neu abgebildet und zum Teil erweitert werden sollte
  • Betriebsführung des gesamten Systems
  • Die bestehende Verarbeitungslogik der Backend-Systeme sollte weiter verwendet werden, wobei die notwendigen Anpassungen im Produktumfeld Natural/Adabas, Cobol/DB2, MQ Series, OS/390 außerhalb des Projektes CDD umgesetzt wurden.
Funktionsumfang & Projektdurchführung

Die Anwendung CDD unterstützt die Produktionsprozesse der Railion-Mitarbeiter in den Rangierbahnhöfen sowie die Bedienfahrten zu Kunden, an die Wagen zugestellt oder abgeholt werden. In allen Fällen müssen produktionsrelevante Daten vor Ort erfasst und zeitnah an die verarbeitenden Systeme weitergegeben werden. So werden zum Beispiel die Kundeninformationssysteme mit aktuellen Statusmeldungen zum Transport versorgt.

Neben der Unterstützung der Fachprozesse umfasst das System CDD unter anderem das System-Management (Softwareverteilung und Bestandsführung), die fachliche und technische Protokollierung und die Telefoniefunktionalität (parallel zum Anwendungsbetrieb auf dem Endgerät). CDD wurde mit Ausnahme der GPRS-Bereitstellung von DB Systems – dem Systemhaus der Deutschen Bahn – als Generalunternehmer mit Unterstützung von Subunternehmern, wie der iteratec GmbH abgewickelt.

Basisanforderungen an das zu entwickelnde System

Aus einer Machbarkeitsstudie zur Ablösung des Altverfahrens resultierten grundlegende Anforderungen. Unter anderem waren dies:

  • Java auf dem Handheld: Die Anwendung auf dem Handheld muss in Java entwickelt werden, da deren Lauffähigkeit – ohne große Anpassungen – auch auf Desktop Clients gewährleistet sein muss.
  • GPRS ist als Funktechnologie zu verwenden. Zurzeit der Umsetzung des Systems stellte sie die stabilste Technologie mit größtmöglicher Abdeckung und höchster Bandbreite dar.
  • Die Anwendung ist mit einer grafischen Benutzeroberfläche auszustatten, die Elemente wie Listen, Menüs, Pull-down-Boxen, Tabellen usw. anbietet.
  • Das mobile Endgerät ist ein PDA mit einer IP-Schutzklasse von mindestens 54. Als Betriebssystem soll PocketPC 2000 zum Einsatz kommen.
  • Das Handheld ist mit einer Tastatur ausgestattet, mit der numerische und alphanumerische Zeichen eingegeben werden können. Darüber hinaus unterstützt die Tastatur Navigations- und Funktionstasten.
  • Die Anwendung ist sowohl über Touch Screen als auch über die Tastatur bedienbar.
  • Das Handheld und die Anwendung unterstützen Telefoniefunktionalität.
  • Software-Updates können über LAN via Docking-Station oder über die Funkstrecke erfolgen.
Projektsteckbrief Anzahl Endgeräte: 2000 Zu verarbeitendes Transaktionsvolumen über die Funkstrecke: 50 MB pro Tag über alle produktiven Handhelds Anzahl Dialoge: 26 Anzahl Masken: 78 Lines of Code (Client): 101.852 (ohne Kommentare) Funktechnologie: GPRS Produktumfeld (Endgerät): Windows CE/PocketPC mit Personal Java VM
Architekturtreibende Anforderungen – grundsätzliche Designentscheidungen

Das abzulösende Altsystem hatte eine textbasierte Oberfläche ähnlich einer 3270 Host-Anwendung. Das neue System sollte dem Benutzer eine ansprechende grafische Benutzeroberfläche bieten. Aufgrund dieser Rahmenvorgaben und der Prämisse, das System in Java zu entwickeln, wurde die Entwurfsentscheidung „Personal Java auf dem Handheld “ getroffen, da mit der damals zu Verfügung stehenden J2ME und CDC/MIDP 1.0 die Basisanforderungen nicht abgedeckt werden konnten. Eine weitere Entscheidung, die es zu treffen galt, war die Auswahl der zu benutzenden Oberflächenbibliotheken. Anfänglich wurde getestet, ob AWT- oder Light-weight-GUI-Komponenten zum Einsatz kommen sollten, also solche, welche sich nicht auf native Peers des unterliegenden Systems stützen, sondern rein in Java implementiert sind. Hierfür wurden einige Oberflächenprototypen entwickelt und deren Verhalten analysiert. Ein Überblick ist in Tabelle 1 dargestellt. Letztlich musste aus Performancegründen AWT eingesetzt werden, da dieses durch die nativen Peers erheblich schneller reagierte als reine Light-weight Java Wigdets. Allerdings stellte sich später heraus, dass die AWT-Oberflächenelemente nicht die gesamten Anforderungen des entwickelten GUI-Styleguides abdecken konnten und so wurden noch zusätzliche Elemente wie Tabellen und Image-Buttons implementiert. Leider war zum Testzeitpunkt im März 2002 die SWT-Bibliothek für ARM-basierte Handhelds unter Windows CE noch nicht stabil genug, um in einem Produktivsystem eingesetzt werden zu können.

Tabelle 1: Oberflächenbibliotheken für Personal Java
Produktname Ausführbarkeit auf Zielsystem Größe der Bibliotheken Reaktionszeit der Oberfläche Oberflächenelemente
AWT X (integriert) schnell (++) wenige (-)
LwVCL X 152 KB (194 KB mit lwext.jar ) akzeptabel (+) viele (++)
Swing X (nicht sinnvoll) ca. 2 MB sehr langsam (—) sehr viele (+++)
SWT [SWT für Pocket PC] X 569 KB schnell (++) viele (++)
Thinlet X 38 KB langsam (o) einige (+)
Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -