PDF laden - Noser Engineering AG
Werbung
mehr als nur software KNOW-HOW 22 Datenbank im technischen Umfeld Noser Engineering AG CH-8404 Winterthur CH-3048 Worblaufen CH-6036 Dierikon CH-1003 Lausanne D-81369 München www.noser.com Talackerstrasse 99 Arastrasse 6 Industriestrasse 9 Rue du Petit-Chêne 22 Engelhardstrasse 10 Tel. 052 234 56 11 Tel. 031 917 52 11 Tel. 041 450 08 11 Tel. 021 318 82 11 Tel. 089 76 70 43 11 Fax 052 234 56 22 Fax 031 917 52 22 Fax 041 450 08 22 Fax 021 318 82 12 Fax 089 76 70 43 12 E-Mail [email protected] E-Mail [email protected] E-Mail [email protected] E-Mail [email protected] E-Mail [email protected] m e h r a l s n u r s o f t w a r e Einleitung Heute werden auch in technischen Systemen zunehmend Standardwerkzeuge wie Browser und Datenbanken eingesetzt. Dies ist vor allem auf die immer grösser werdende Leistungsfähigkeit und die zunehmende Standardisierung von technischen Hardwareplattformen und Betriebssystemen im industriellen Umfeld zurückzuführen. Im vorliegenden KNOW-HOW wird ein Beispiel für die Integration einer Datenbank zur dynamischen Steuerung eines Verkaufsprozesses in einem Fahrkartenautomaten für den öffentlichen Verkehr beschrieben. auch für andere Services verwendet werden. Der «Generic Control Process» (GCP) ist für die Bedienerführung und den Verkaufsprozess zuständig. Alle Abfragen auf die Datenbank erfolgen zentral über den Tarifprozess, der alle Daten zur kmBerechnung, Preisermittlung und zum Programmablauf liefert: Folgende Vorteile sprechen für den Einsatz einer Datenbank im technischen Umfeld: • Datensicherheit • Datenverwaltung, Backup • Umfangreiche Funktionalität für die Datenauswertung • Flexibler Ausbau Die Nachteile sind: • Geschwindigkeit • Lizenzkosten • Ressourcenbedarf Systemkonzept Die Architektur der Betriebssoftware der Fahrkartenautomaten basiert auf einem Komponenten-Framework. Es definiert die Basisinterfaces für auf CORBA aufgesetzte ClientServer-Komponenten und enthält vorgefertigte Implementationen wie: • Naming Service • Alarm Handler • Process Manager • Watch Dog etc. Abb. 1: Übersicht Komponentenframework Abb. 1 zeigt vereinfacht die Funktionsweise des Komponentenframeworks für eine einfache Applikation. Die Pfeile illustrieren den Kontrollfluss bei einer typischen Aufstartsequenz für zwei Komponenten X und Y, die in derselben Reihenfolge gestartet werden, wie sie in der Komponentenliste aufgeführt sind. Einzelne Komponenten können entweder direkt zur Ansteuerung eines Gerätes (Display, Printer etc.) oder aber Abb. 2: Tarifprozess Der Tarifprozess ist, wie Abb. 2 zeigt, in drei hierarchische Ebenen aufgeteilt. 1. In der untersten Ebene befindet sich TIS/P, das bestehende Transportinformationssystem des Kunden. In diesem Programmteil werden die Wegentfernungen und Preise berechnet. 2. Das Kundeninformationssystem (KIS) bildet die zweite Ebene. Dort werden primär aufgrund der vom Kunden gewählten Relation die zulässigen Tarifebenen (Verbünde) und Tarife bestimmt. Aus den möglichen Angeboten wird das günstigste ausgewählt. Zusätzlich dazu liefert das KIS aus der Datenbank die Informationen für den Bildschirmaufbau, die Maskenfolge und die Event-Behandlung. 3. SWBKIS übernimmt die Anbindung des Tarifprozesses an den CORBA-Softwarebus des Automatenframeworks. Dieser Teil des Prozesses ist, im Gegensatz zu den darunterliegenden Ebenen, nicht mehr multiuserfähig, sondern speichert gewisse Zustände aus den letzten Abfragen, damit nicht bei jedem Aufruf alle Informationen über den CORBA-Softwarebus an den ‚Generic Control Process’ (GCP) weitergeleitet werden müssen. Datenbank Der Einsatz von Oracle als Datenbank war für die hier vorgestellte Realisierung gegeben, da das vom Kunden gelieferte TIS/P-Modul über Pro*C/C++ mit Oracle kommuniziert. Es zeigte sich zudem, dass auch Oracle lite nicht eingesetzt werden konnte, da dazu kein Pro*C/C++ -Interface existiert. Bei der Implementation der übrigen Teile des Tarifprozesses wurde auf eine grösstmögliche Portierbarkeit des Codes geachtet. Die Datenbanktabellen sind, abhängig von der Aufgabe, in mehrere unabhängige oder nur lose gekoppelte Bereiche unterteilt: • Bereich für die eigentliche Entfernungs- und Preisberechnung: Dieser Bereich wurde ohne Änderung aus der bestehenden Kundenapplikation übernommen und wird nur vom TIS/P-Teil der Applikation referenziert (s. Abb. 2, TIS/P). • Bereich für die dynamische Steuerung der Bedieneroberfläche mit sprachabhängiger Textanzeige: Die Basismasken des Systems werden mit einem Editor erstellt und in einer Layoutdatei abgelegt. In der Layoutdatei sind alle Anzeigeobjekte (Buttons, Textfelder, Grafikfelder, Hintergrundbereiche etc.) mit einem Identifier abgelegt, über den die Attribute des Objekts verändert werden können. In der Datenbank ist ein Objektattribut über «maske.tarifsystem. objektid.attributid» referenzierbar. Nach einem Maskenwechsel werden alle Objekte tabellengesteuert befüllt. • Tabelle für die Ablage der verkauften Fahrkarten: Die Daten in dieser Tabelle werden jeweils bei Tagesabschluss zu Buchhaltungs- und Statistikzwecken auf das Hostsystem des Kunden übertragen. Abb. 4: Fahrkarte Datenbankaufruf Im bestehenden TIS/P-Teil (s. Abb. 2, TIS/P), der vom Kunden stammt, wird Pro*C/C++ als Interface zu Oracle verwendet. if (vverbund_tg == nverbund_tg) { EXEC SQL INSERT INTO LOVVERBUND VALUES(0,1,NULL,NULL,NULL, :verbund,USERENV('TERMINAL')); if (sqlca.sqlcode != 0) { /* Fehler in SQL-Statement */ return (-1); } EXEC SQL COMMIT WORK; } Abb. 5: Embedded SQL-Statements Abb. 3: Bedieneroberfläche • Die Behandlung der Fahrkartenlayouts erfolgt analog zur Bedieneroberfläche. Die Basislayouts werden im Editor erstellt und die einzelnen Druckobjekte werden vor dem Druck kontextabhängig befüllt. • Die zentrale Funktion des Kundeninformationssystems ist die dynamische Berechnung der zulässigen Fahrkartengattungen auf der Basis der gewünschten Kundenrelation und den Tarifbestimmungen in den regionsabhängigen Verbünden. Abb. 6: Ablauf des Entwicklungsprozesses mit Pro*C/C++ m e h r a l s n u r s o f t w a r e m e h r a l s n u r s o f t w a r e Im neu entwickelten KIS (s. Abb. 2, KIS) wird die Datenbank über ODBC aufgerufen. Die ODBC-Aufrufe der Datenbank werden über eine Datenbankklasse ausgeführt, die vom Komponentenframework zur Verfügung gestellt wird. StrListList aResult; ostringstream sqlStatement; try { sqlStatement.str(""); sqlStatement << "select DISTANZ from RESULTAT " << "where TTY=USERENV('TERMINAL')"; pDB->simpleSelect( sqlStatement.str().c_str(), aResult); } catch (ErrorElement) { throw UngueltigeDaten(errSQL, sqlStatement.str().c_str()); } Typ Oracle 8i Access 2000 Numerisch NUMBER(Scale) SINGLE, DOUBLE, SHORT, LONG Beispiel: NUMBER(9) NUMBER(9,2) Beispiel einer generierten Sequenznummer von 20 Stellen: NUMBER(20) Text VARCHAR2(Size) Size: maximal 2000 Zeichen VARCHAR(Size) Size: maximal nur 255 Zeichen. Datumsabfragen Direkt via SQL Statement Die Applikation muss selber Systemzeit lesen und in das amerikanische Datumsformat (mm/dd/yy) umwandeln. Dann kann eine SQL Abfrage mit dem umgewandelten Datum erfolgen. Abb. 7: ODBC-Aufruf der Datenbank „SYSDATE between ....“ Mit der TO_DATE Bei Maskenwechseln sind oft sehr viele Datenbankabfragen notwendig, um alle Tarifinformationen und Anzeigeelemente zu bestimmen. Deshalb ist die Geschwindigkeit der Abfragen entscheidend, um vertretbare Systemantwortzeiten zu erhalten. In der Praxis hat sich gezeigt, dass die grösste zeitliche Verzögerung bei der Verarbeitung des Befehls in der Datenbank auftritt. Alle andern Verzögerungen, wie die CORBAAufrufe oder die dynamische Speicherverwaltung bei der Resultattabelle sind dagegen vernachlässigbar. Während der Implementation des Systems wurde in mehreren Durchläufen die Performance verbessert. Den grössten Einfluss auf die Geschwindigkeit hatten die Erweiterung des Hauptspeichers von 64 MB auf 128 MB und die Vereinfachung der Abfragen. Letzteres wurde dadurch erreicht, dass die Datenbank von der ursprünglichen Normalform schrittweise mit redundanter Information versorgt wurde, damit «Joins» von grossen Tabellen vermieden werden konnten. Portierbarkeit In einem zweiten Automatenprojekt konnte die Portierbarkeit des Tarifprozesses auf eine andere Datenbank getestet werden. In diesem Projekt gab es keine Kundenvorgabe bezüglich Distanz- und Preisberechnung. Es wurde deshalb ACCESS, das im System ohnehin schon in einigen Standardkomponenten zur Anwendung kommt, als Datenbank ausgewählt. Die grundsätzliche Vorgabe war somit, einen möglichst grossen Teil des früheren Systemkonzepts zu übernehmen, aber mit ACCESS als Datenbank. Der Portierungsprozess verlief ziemlich rasch und problemlos. Wichtig ist aber, beim Einsatz von ODBC folgende Unterschiede zu beachten: Noser Engineering AG CH-8404 Winterthur CH-3048 Worblaufen CH-6036 Dierikon CH-1003 Lausanne D-81369 München www.noser.com Talackerstrasse 99 Arastrasse 6 Industriestrasse 9 Rue du Petit-Chêne 22 Engelhardstrasse 10 Je nach gewünschtem Wertebereich und Präzision muss ein Datentyp ausgewählt werden. Ist kein nummerischer Datentyp vorhanden, muss der Wert in einem VARCHAR(20) gespeichert werden. Tel. 052 234 56 11 Tel. 031 917 52 11 Tel. 041 450 08 11 Tel. 021 318 82 11 Tel. 089 76 70 43 11 Umwandlung kann das Datumsformat komfortabel gewandelt werden Stored Procedures Datenmenge Wird unterstützt Wird nicht unterstützt Für grosse Datenmengen geeignet. Beispiel Grösse der Datenbank mit einem umfangreichen Tarifsystem inkl. MMI Steuerung: 500MByte Für kleinere bis mittelgrosse Datenmengen geeignet Beispiel Grösse der Datenbank mit einem kleinen Tarifsystem inkl. MMI Ablauf: 1.4 MByte Beurteilung Die Datenbank als zentrales Steuerelement des automatisierten Verkaufsprozesses hat sich als flexibles Werkzeug erwiesen, das dem Kunden in Zukunft breite Möglichkeiten zur selbständigen Anpassung des Systems an neue Anforderungen erlaubt. Autoren: Beat Salzmann Dipl. El. Ing. HTL Fax 052 234 56 22 Fax 031 917 52 22 Fax 041 450 08 22 Fax 021 318 82 12 Fax 089 76 70 43 12 Bruno Tischhauser Dipl. El. Ing. ETH E-Mail [email protected] E-Mail [email protected] E-Mail [email protected] E-Mail [email protected] E-Mail [email protected] m e h r a l s n u r s o f t w a r e
