RDS-Projekt |
#9 Projektintegration |
|
von Martin Arend
Da der Decoder nicht von einem Programmierer, sondern von insgesamt acht
Studenten realisiert wurde, war ein "Projektintegrator" notwendig.
Dessen Aufgaben waren es
die Gesamtkoordination des Projektes durchzuführen,
eine zeitliche Planung zu erstellen und dessen Einhaltung
zu gewährleisten,
die Zuweisung der Ressourcen,
das Definieren der teilprojektübergreifenden
Schnittstellen und die Einhaltung der Definition,
das Programmieren der "Include"-Dateien,
das Testen der einzelnen Module,
das Motivieren der einzelnen Programmierer,
das Erstellen der Internetseiten und der Dokumentation.
In der freien Wirtschaft wäre das der Job des Teamleiters, oder
des Chefs der Abteilung.
Die Koordination der einzelnen Projekte lief dabei erstaunlich gut, und
das Programm lies sich, mit tatkräftiger Unterstützung von
Herrn Prof. Vogl wenn wir wirklich nicht mehr weiterwußten, auch
ohne große Reibereien bei den Schnittstellen zusammensetzen.
Der Arbeitsaufwand war allerdings beträchtlich. Das Programmieren,
Testen und Zusammensetzen der einzelnen Programmteile bis einschließlich
dem Erstellen der HP-Vee-Oberfläche bis hin zur "Abnahme" des
funktionsfähigen RDS-Decoders durch Herrn Prof. Vogl dauerte ca.
300 Stunden.
Für die Erstellung der HTML-Seiten und der Dokumentation fielen
weitere 50 Stunden an.
Vor fast einem Jahr schlug uns Prof. Vogl in seiner Vorlesung Digitale
Signalverarbeitung I vor, die im siebten Semester fällige
Studienarbeit als Teamarbeit zu realisieren.
Nichts ahnend, was genau da auf uns zukommen würde willigten wir
begeistert ein. Schließlich, so stellten wir uns vor, ist eine
Arbeit im Team einfacher zu erledigen, als Einzeln oder in
Zweiergruppen.
Im Wintersemester 1999/2000 kam dann die Ernüchterung. So
kompliziert hatten wir uns das Projekt nicht vorgestellt. Ein
Projektintegrator war schnell gefunden, auch ein Spezialist für
die Codierung und ein weiterer für die analoge Vorverarbeitung.
Der Rest der Projekte war ebenfalls recht schnell vergeben. Doch dann
ging es ans eingemachte. Literaturrecherche, im Internet nach
Unterlagen suchen, Spezifikationen durchlesen, ein erster Zeitplan.
Und immer wieder Besprechungen und nur ein Thema: RDS.
Auch in den Vorlesungen kamen wir immer wieder auf das Projekt
zurück, und die Nachmittage verbrachten wir immer häufiger
im DSV-Labor. Ein Mann war zwischen Mitte November und Ende Dezember
immer wieder gefragt: Prof. Dr. Vogl. Ein Kommentar von ihm
drückte schließlich die zwischenzeitlich herrschende
Stimmung aus :"Wenn ich gewußt hätte, worauf ich mich da
einlasse, dann hätte ich mir das anders überlegt."
Probleme blieben nicht aus. Das Projekt lief auf einem der sechs
Laborrechner einwandfrei, aber auf keinem anderen, Fehler schlichen
sich ein, eine Projektdatei verschwand ganz, zum Glück gab es
ein Backup. Und immer wieder der Befehlssatz der nicht das zuließ
was man eigentlich programmieren wollte. HP-Vee wollte auch ganz neu
erlernt werden, und auch hier steckte die Tücke im Detail. Trotz
zweimaliger Kontrolle fand sich ein Fehler im Modified Julian Day erst
am vorletzten Tag vor der Abgabe.
Dann das Zusammensetzen der Teilprojekte. Variablennamen tauchten
doppelt auf, die Syntax paßte nicht, also wurde das erste
Konzept wieder umgeschmissen und ein neues erstellt. Teilprojekte
hielten sich nicht an die Spezifikationen und mußten umgeschrieben werden,
andere hielten sich nicht an die Namensgebung und die vorgegebene Verzeichnisstruktur,
auch hier verging wertvolle Zeit beim Suchen und Rekonstruieren, da der betreffende Student
gerade an diesem Nachmittag nicht im Labor war.
Schließlich die ersten Erfolge. Die Costas-Schleife rastete ein,
der Bittakt wurde ordentlich zurückgewonnen, eine erste
Decodierung war möglich, die HP-Vee Oberfläche stand im
groben. Es knirschte zwar immer noch der Sand im Getriebe, aber RDS
rollte. Fehler für Fehler wurde beseitigt und schließlich
tauchte er auf, der erste Sendername auf der HP-Vee-Oberfläche.
Das Datum war zwar noch recht seltsam, auch die alternativen Frequenzen
noch recht ungeordnet, aber der Radiotext informierte uns schon
über Hörertelefone, e-mails und Programminhalte der Sender.
Stück für Stück des Gesamtprojekts wurde zusammengesetzt,
jetzt motivierten die (Teil-)Erfolge das Team, und in die Programmiersprache
und deren Tücken waren wir längst eingearbeitet, so daß
die letzten Fehler recht schnell beseitigt waren.
Und dann standen wir am 21. Dezember mit Sektgläsern in der Hand
um den fertigen RDS-Decoder, und Prof. Vogl zeigte uns die
Möglichkeiten die wir mit diesem Programm haben, und
erläuterte uns noch einmal die Grundlagen und die
Vorlesungsinhalte der Digitalen Signalverarbeitung, die wir für
unser Projekt benötigt haben.
Gelernt haben wir bei diesem Projekt fürs Leben: die Teamarbeit.
Die Erleichterungen die es dadurch gibt, aber auch die Stellen, an
denen es Schwierigkeiten geben kann, wie z.B. die Schnittstellen.
Am Schluß kam ein Decoder heraus, der sich im Funktionsumfang
hinter einem in einem HiFi-Gerät enthaltenen nicht verstecken
muß. Der Hardwareaufwand ist zugebenermaßen deutlich
umfangreicher (PC, analoger Mischer, DSP, Netzteil, Verkabelung, ...),
dafür ist er aber deutlich flexibler und ermöglicht viele
Messungen die an einem Fertigprodukt nicht möglich wären.
Brauchen Sie ein eingespieltes Entwicklungsteam für DSP-Software?
Wir wüßten da eines...
Ein großes Dankeschön geht an Herrn Prof. Dr. Vogl für die Unterstützung bei der
Programmierung des RDS-Decoders, da er sich trotz seines Freisemesters immer wieder die Zeit genommen
hat, uns bei Problemen zu helfen.
Ein weiteres Dankeschön an Herrn Saffert, und alle Laboringenieure die uns betreut und nach besten
Kräften unterstützt haben.
Und schließlich ein Dankeschön an das Team, für die gute und reibungslose Zusammenarbeit.
|