Mit 2000 Prüfingenieuren ist die GTÜ die größte amtlich anerkannte Kfz-Überwachungsorganisation freiberuflicher Kfz-Sachverständiger. Zu ihren Leistungen zählen beispielsweise Hauptuntersuchungen (HU), Abgasuntersuchungen (AU) und Kfz-Gutachten.

GRIPS steht für „GTÜ Recherche- und Informationssystem für Prüfingenieure und Sachverständige“ und ist als ein Nachschlagewerk für den täglichen Gebrauch konzeptioniert. In diesem finden sich beispielsweise Prüfanweisungen und technische Informationen, die für die Kfz-Untersuchungen in den Werkstätten oder Autohäusern vor Ort benötigt werden. Darüber hinaus enthält GRIPS Vorlagen und Formulare, Aus- und Fortbildungsunterlagen sowie ein Adressverzeichnis.

GRIPS ist wie viele vergleichbare Systeme historisch gewachsen. Anfangs bestand es aus umfassenden Papierordnern, für die mehrmals jährlich „Updates“ in Form von Blattsammlungen verschickt wurden. Diese Papiere galt es, per Hand in die Ordner einzusortieren. Ende der neunziger Jahre wurde GRIPS dann auf HTML umgestellt. Die Inhalte wurden mit einem HTML-Editor bearbeitet und in Form von statischen HTML-Dateien in einer Ordnerstruktur abgelegt. Das manuelle Einsortieren der Blätter gehörte damit der Vergangenheit an. Updates wurden auf CDs geliefert, die den kompletten GRIPS-Ordner, knapp 400MB an Daten, enthielten. Zusätzlich zu den CDs gab es Online-Updates. Anhand des Änderungsdatums der HTML-Dateien war das System recht einfach in der Lage, die Veränderungen gegenüber dem letzten Update zu identifizieren und damit die Datenmenge gering zu halten. Dennoch konnte ein Update bis zu 10MB umfassen.

Die Lösung mit statischen HTML-Seiten bot zwar viele Vorteile gegenüber den Papierordnern, stieß über die Jahre aber ebenfalls an Ihre Grenzen. Fragestellungen wie beispielsweise „Welche Fehler traten häufig an Fahrzeugen des Herstellers x, Modellreihe y, ab Baujahr 2005 auf“ lassen sich mit einem statischen, auf HTML basierenden System nicht beantworten. Der übliche Weg, um derartige Fragestellungen beantworten zu können, ist eine Datenbank-Anwendung mit Web-Frontend, die zwingend einen entsprechenden Datenbank- und Web-Server voraussetzt.

Die Navigation entstand zu einer Zeit, als es den Firefox noch nicht gab und war wie auch die Suchfunktion mit JavaScript realisiert. Daher funktionierte GRIPS nur mit dem Internet Explorer. So bot die Suchfunktion nicht den gewohnten Komfort aktueller Searchengines – beispielsweise war die Sortierung der Ergebnisse nach Relevanz nicht möglich.

Der Überarbeitungs- und Freigabeprozess für die Inhalte war ebenfalls aufwendig und umständlich, da er nicht von der Software unterstützt wurde. Stattdessen wurden Dokumente per E-Mail hin- und hergesendet und das Feedback anschließend manuell eingearbeitet. Die Design-Richtlinien der GTÜ wurden dabei nur bedingt eingehalten. Ein Relaunch erschien allerdings aufgrund der vielen zu ändernden HTML-Dokumente mühsam und wurde daher lange Zeit hinausgeschoben. Gleichzeitig stieg die Datenmenge in GRIPS stark an, da jedes einzelne HTML-Dokument die gesamte Navigation des Systems enthielt. Die große Datenmenge machte Neuinstallation und Daten-Updates daher immer aufwendiger.

Eine reine Online-Lösung schied als Alternative aus, da in ländlichen Gebieten häufig kein DSL verfügbar und die UMTS-Netzabdeckung mangelhaft ist. Selbst vorhandene Breitbandzugänge befinden sich in der Regel nicht in den Werkstätten selbst sondern im Verwaltungsgebäude. Die neue Lösung sollte demnach genau wie die alte HTML-Lösung lokal auf den Notebooks funktionieren – ohne Internetverbindung.

Den Verantwortlichen bei der GTÜ war klar, dass ein Content Management System viele der Anforderungen erfüllen würde. Allerdings warfen Installation und Betrieb eines CMS auf 2000 Windows-Notebooks gleich mehrere kritische Fragen auf:

Es galt, die Kommunikation der Systeme untereinander zu kären.

Die Installation sollte möglichst simpel sein. Bei Problemen sollte das System einfach erneut installiert werden können.

Content Management Systeme gehören gemeinhin zu einer kostspieligen Softwaregattung. Die Lizenzkosten lassen sich allerdings mit Open-Source-Software elegant umgehen. In die engere Auswahl kamen die Systeme TYPO3, OpenCms und Zope. Alle genannten Systeme bieten den notwendigen Funktionsumfang, wobei TYPO3 dank der vielen leistungsfähigen Extensions einen deutlichen Vorsprung verbuchen konnte. Letztlich entscheidend für TYPO3 war jedoch die einfache Installation, da komplette XAMPP-Pakete inklusive TYPO3 zur Vefügung stehen, die mit wenigen Klicks auf Windows-Systemen installiert sind.

Das TYPO3-basierte GRIPS besteht aus einem zentralen Master-System, auf dem alle Inhalte gepflegt werden und aus ca. 2000 Slave-Systemen auf Notebooks mit jeweils lokalem TYPO3-Server. Das Master-System ist im Web erreichbar, Inhalte sind allerdings nur für GTÜ-Vertragspartner nach einer Authentifizierung zugänglich. Der gesamte Datenbestand umfasst derzeit ca. 300MB verteilt auf rund 2000 Seiten. Aufgrund der Datenmenge ist es nicht möglich, im 14-Tage-Rhythmus alle Inhalte zu verteilen, denn dies hätte pro Monat Traffic von 2 * (300MB * 2000) = 1,2TB bedeutet. Daher wurde ein Verfahren implementiert, das ausschließlich die Änderungen an den Inhalten überträgt.

So genannte Update-Pakete werden auf dem Master skriptgesteuert oder manuell erzeugt. Die Update-Pakete enthalten je nach Typ alle oder die seit einem bestimmten Zeitpunkt geänderten Inhalte. Zu diesem Zweck wurde ein Verfahren implementiert, das an gängige Backup-Konzepte aus dem IT-Management angelehnt ist. Drei Typen von Updates werden dabei unterstützt:

• Voll-Updates (enthalten alle Inhalte, ca. 300 MB, ungefähr alle 4 Monate auf CD-ROM)
• Differenz-Updates (enthalten nur die geänderten Inhalte seit dem letzten Voll-Update, können nach Bedarf angefertigt werden)
• Inkrement-Updates (enthalten nur die geänderten Inhalte seit dem letzten Update, ca. 5 – 10MB, ungefähr alle zwei Wochen)

Die Updates werden über eine GTÜ-Software automatisch an die Notebooks verteilt und stehen zusätzlich als Download zur Verfügung.

Um einen Slave auf dem aktuellen Stand zu halten, ist alle zwei Wochen die Installation des jeweiligen Inkrement-Updates notwendig. Die Datenmenge bleibt dabei in einem Rahmen, der auch über ISDN- oder gar Modem-Verbindungen noch gut zu handhaben ist.

Die Differenz-Updates dienen dazu, auf den Slaves die Neu- oder Wiederinstallation zu vereinfachen – lediglich die letzte CD-ROM und das letzte Differenz-Update müssen installiert werden. Differenz-Updates können auch eigens erzeugt werden, um sich gegebenenfalls die Installation einzelner Inkrement-Updates zu sparen.

Eine wichtige Anforderung war, verschiedene Versionen von Inhalten im Frontend miteinander vergleichen zu können, so wie man es von der Versionierungs-Ansicht im TYPO3-Backend kennt. Damit wird für Kunden und Prüfingenieure transparent gemacht, wann und wie sich Prüfungsrichtlinien geändert haben.
Die Differenzansicht wurde als Front-End Plugin realisiert, das verschiedene Versionen einer Seite anzeigt und auf einen Klick die Versionen miteinander vergleicht. Dabei werden gelöschte Texte in rot und hinzugefügte in grün dargestellt. Die zugehörige Extension wird im ersten Quartal 2008 im TER veröffentlicht.

Die Nutzer des Systems sollten in der Lage sein, persönliche Favoriten abzulegen. Da die Nutzer nicht immer mit dem gleichen Computer arbeiten, sollten diese Favoriten auf jedem der 2000 Slave-Systeme und zusätzlich auf dem Master verfügbar sein. Die Nutzer können über eine Extension ihre persönlichen Favoriten festlegen, die in einer Datenbank gespeichert werden. Alle Änderungen an der Datenbank werden mit dem Master-System repliziert und von dort an alle Slave-Systeme verteilt. Damit findet jeder Nutzer seine gewohnte Arbeitsumgebung vor, unabhängig davon, an welchem Rechner er sich anmeldet.

In Phase 1 entspricht der Funktionsumfang von TYPO3-GRIPS der alten Version auf Basis statischer HTML-Dateien. Benutzer und Redakteure gewinnen jedoch deutlich mehr an Komfort. Ab Frühsommer 2008 startet Phase 2 – dann wird GRIPS um diverse Oracle Datenbank-Anwendungen erweitert, die ebenfalls auf der Master-Slave Architektur aufsetzen. Die Anwendungen werden dann gezielte Abfragen auf den Slaves ermöglichen, zum Beispiel „Wo findet sich der EOBD (Electronic on Board Diagnostic) Anschluss für die Abgasprüfung bei Hersteller x Modell y?“ Die Daten dafür stammen aus einer zentralen Oracle-Datenbank aus der GTÜ-Zentrale in Stuttgart und werden über den gleichen Mechanismus auf die Slaves verteilt.