Der Entwicklungsprozess. Oder wie entwickle ich ein eingebettetes System?

Transkript

1 Der Entwicklungsprozess Oder wie entwickle ich ein eingebettetes System?

2 Einleitung Problemstellung erläutern, Eine Entwicklungsprozess ist ein Prozess, der beschreibt, wie man eine Entwicklung anzugehen hat, er beschreibt die Art und Weise des Vorgehens angefangen bei der Idee und der Planung bis hin zum Prototyp oder gar bis zur Serienreife. Das Problem bei den Entwicklungsprozessen ist, daß sie so aufgebaut sein müssen, daß sie möglichst effektiv sind. Diese Effektivität ist in der Industrie von sehr großer Bedeutung, da eine Entwicklung weniger kostet je effektiver und schneller sie ist. Es heißt also den Prozess so zu gestalten, daß der Kosten- und Zeitaufwand möglichst gering bleiben. Es gibt mehrere Wege, wie man einen solchen Prozess aufbaut. Dazu gehört einmal der klassische Entwicklungsprozess, zum anderen der CASE basierte Ansatz mit Prototyping bzw. Rapid Prototyping. Hier sind als erstes Anforderungen dargestellt, die an und von einen Entwicklungsprozess gemacht werden. Im Anschluß daran wird zuerst der klassische Entwicklungsprozess betrachtet, danach die CASE basierten Arten. Im Anschluß daran werden die verschiedenen Möglichkeiten noch einmal gegenübergestellt, und miteinander verglichen. Der Steuergeräteentwicklungsprozess beschreibt den Weg von der Idee bis hin zum Prototypen oder dem Seriengerät.

3 Anforderungen Anforderungen an einen Entwicklungsprozess Die Industrie stellt an die Entwicklung eines Bauteils oder Gerätes besondere Anforderungen. Dazu gehören in erster Linie, daß das Gerät am Ende der Entwicklung so funktioniert, wie man sich das gedacht hat. Des weiteren sollten natürlich die Kosten der Entwicklung möglichst gering gehalten werden. Das erreicht man dadurch, daß man einzelne Entwicklungsschritte einspart, oder den Prozess so gestaltet, daß diese Schritte erst gar nicht mehr auftreten können. Diese Abkürzung des Prozesses hat den Vorteil, das die Entwicklung schneller abgeschlossen ist. Die Schnelligkeit ist eine weitere Forderung der Industrie an den Prozess. Anforderungen von einem Entwicklungsprozess Auch ein Entwicklungsprozess hat Anforderungen an die Entwickler. Wenn ein Prozess einmal steht, und die Entwicklung angelaufen ist, lassen sich Änderungen nur schwer durchführen. Die Entwickler sollten also bei der Entwicklung eines Prozesses schon eine genaue Vorstellung davon haben, was später das Ziel der Entwicklung sein soll. Kurzfristige Änderungen sind meistens nur schwer oder gar nicht mehr realisierbar. Zielsetzung Das Ziel ist es, einen idealen Entwicklungsprozess zu schaffen, der mit möglichst geringen Kosten bei optimalem Ergebnis auskommt. Zur Kostenreduktion eignet sich beispielsweise die Verbesserung der Kommunikation durch die Verwendung von CASE Tools oder die Vermeidung von Arbeitsschleifen in dem Prozess.

4 Entwicklungsprozesse Entwicklungsprozesse beschreiben die Vorgehensweise bei der Entwicklung von neuen Geräten oder neuer Software. Die Prozessprinzipien lassen sich auf sehr viele andere Entwicklungen übertragen. Hier wird beispielsweise die Entwicklung eines Software-Tools zu einer gegebenen Hardware betrachtet. Dabei treten folgende Gruppen auf: Der Entwickler der Hardware, der Software Entwickler und der Auftraggeber, der die Hardware zusammen mit der Software benutzen möchte. Hardware und Software sollen im fertigen Zustand den Vorstellungen und der Idee des Auftraggebers entsprechen. Dabei gibt es verschiedene Möglichkeiten die Idee des Auftraggebers umzusetzen. Der klassische Entwicklungsprozess Entwicklung Im klassischen Entwicklungsprozess wird die Entwicklung ohne die Verwendung von sogenannten CASE-Tools durchgeführt. Im ersten Schritt wird vom Auftraggeber versucht, die Idee in einem Lastenheft niederzuschreiben. Man spricht hierbei auch von einer informellen Anforderungsspezifikation. Das Problem liegt jetzt darin, die Idee des Verhaltens eindeutig und vollständig zu formulieren. Grade die Eindeutigkeit leidet unter der Verwendung der menschlichen Sprache, die mehrdeutig ist. Es gibt praktisch keine Möglichkeit zu überprüfen, ob das Lastenheft die Idee wirklich richtig und korrekt beschreibt. In dem nächsten Schritt wird das Lastenheft in eine Softwarelösung umgesetzt. Dieser Schritt wird meistens nicht in der Firma des Auftraggebers durchgeführt, sondern an einen Software Entwickler weitergegeben. Dieser programmiert die in dem Lastenheft angegebene Software. Ist das Lastenheft in Software umgesetzt, beginnt für den Auftraggeber die schwierige Aufgabe zu überprüfen ob die Umsetzung richtig durchgeführt worden ist. Konkret heißt das, es muß überprüft werden, ob das verhalten der Software der Beschreibung im Lastenheft und damit der Idee entspricht. Ist dies nicht der Fall kann man die auftretenden Fehler in drei Fehlerklassen unterscheiden:

5 Klasse 1: Das Verhalten war nicht eindeutig im Lastenheft beschrieben. Der Programmierer hat dem Text im Sinne des Auftraggebers falsch interpretiert und umgesetzt. Klasse 2: Das Verhalten war nicht vollständig im Lastenheft beschrieben. Der Programmierer hat versucht, die fehlende Beschreibung durch seine Vorstellung zu ergänzen und diese in die Software umzusetzen. Klasse 3: Der Programmierer hat Programmierfehler gemacht. Das heißt, das Verhalten war richtig beschrieben und wurde auch richtig verstanden, aber falsch in der Programmiersprache umgesetzt. Die Fehler der beiden ersten Fehlerklassen sind Fehler, die der Auftraggeber gemacht hat und auch verantworten muß. Nur für Fehler der dritten Fehlerklasse kann man dem Programmierer verantwortlich machen. Die Frage nach der Verantwortlichkeit ist jedoch zweitrangig. Vor Serienanlauf sollten alle Fehler gefunden und beseitigt sein. Simulation und Fehlerbeseitigung Das Software Tool wird zuerst in einer Simulationsumgebung am PC oder an einer Workstation getestet. Dazu hat man auf dem Rechner eine Umgebung geschaffen, die die spätere Einsatzumgebung simuliert. Dazu gehören unter anderem alle Ein und Ausgabe Schnittstellen, die in der späteren Einsatzumgebung vorhanden sind. Diese Schnittstellen müssen mit allen ihren Eigenschaften, also Ansprechverhalten, Zeitverläufe und auch der hardwarebedingten Mängel simuliert werden. Je genauer die Simulation am Rechner ist,.desto eher kann man Fehler finden und beseitigen. Dieser Test an einer Simulationsumgebung ist gewissermaßen ein Grobtest, um grundsätzliche Mängel und grobe Fehler zu beseitigen. Wenn in der Simulation am Rechner Mängel gefunden werden, müssen diese beseitigt werden. Oft kann es vorkommen, daß man erst in der Simulation Mängel bemerkt, die von so grundlegender Natur sind, daß das Lastenheft entsprechend geändert werden muß. Man springt also, wenn Fehler auftreten, oft ein paar Stufen in der Entwicklung zurück und beginnt von neuem. Dieses Verfahren ist im Stadium der Simulation schon recht zeitaufwendig. Im zweiten Schritt der Simulation wird die Software mit Hilfe eines Mustergerätes getestet. Hier sind alle Schnittstellen, die vorher nur simuliert wurden real vorhanden. Zum Teil erkennt man erst jetzt Fehler. Diese Fehler traten im vorherigen Schritt noch nicht auf, da die Simulation nicht alle Hardwarebedingungen exakt genug nachstellen kann. Hat man einen

6 Fehler gefunden, beginnt ein langwieriger Zyklus. Der Fehler wird dem Software Entwickler mitgeteilt, der ändert die Software so ab, daß seiner Meinung nach der Fehler behoben ist. Die neue Software wird wieder in das Mustergerät eingebaut und erneut getestet. Wenn der Fehler nicht behoben ist, oder durch diese Änderung andere Probleme auftreten, dann wird erneut der Entwickler beauftragt den Fehler zu beheben. Fehlerbeseitigung ist in diesem Stadium sehr zeit- und kostenaufwendig. In der Praxis wird aber grade dieser Zyklus sehr häufig durchlaufen. Am Ende der Testphase, wird versucht, das Verhalten durch Veränderung der Parameter optimal auf das Zielgerät abzustimmen. Man verwendet hierzu sogenannte Applikationssysteme. Selbst in dieser Phase können noch Fehler aufgedeckt werden. Deren Änderung ist äußerst langwierig und kostspielig.

7 CASE Der Problempunkt beim klassischen Entwicklungsprozess liegt in der Umsetzung des Lastenheftes in ein konkretes Modell. Die Umsetzung ist langsam und schwierig, und das Modell orientiert sich meist an der verwendeten Programmiersprache und nicht am Problem. Ist für die Umsetzung ein Software Entwickler eingesetzt, der nicht in dem Unternehmen des Auftraggebers ab, so kommt noch die Problematik der räumlichen Entfernung hinzu. Sie erschwert den Informationsaustausch zwischen dem Verfasser des Lastenheftes und dem Implementierer. Dadurch werden Fehler aus den ersten beiden Kategorien oft erst zu spät erkannt. Genau an diesem Problempunkt wird durch die Verwendung von CASE (Computer Aided Systems Engineering) Werkzeugen angesetzt. Man unterscheidet zwei verschiedene Arten: Werkzeuge zur Entwicklung zeitkontinuierlicher, reglungstechnischer Systeme und Werkzeuge zur Entwicklung zustandsbasierter Modelle. Für die meisten Steuergeräte müssen jedoch sowohl kontinuierliche als auch zustandsbasierte Modell entwickelt werden. Man spricht dann von hybriden Modellen. In diesem Fall werden beide Werkzeuge kombiniert eingesetzt. Abstrakte Modellierung Beide Werkzeugtypen ermöglichen die Erstellung von abstrakten Modellen. Statt konkreter Programmiersprachen stehen abstrakte, graphische Beschreibungsmechanismen, wie Zustandsautomaten, Datenflußdiagramme oder Blockdiagramme zur Verfügung. Die Beschreibung erfolgt also auf einer höheren Ebene und ist damit wesentlich problemorientierter. Das Lastenheft kann somit schneller in ein abstraktes Modell umgesetzt werden. Die Modellerstellung erfordert auch keine Programmierkenntnisse im klassischen Sinne. Das Modell kann direkt vom jeweiligen Fachmann in der Firma des Auftraggebers erstellt werden. Eine Entsprechende Schulung im Umgang mit den CASE Werkzeugen muss allerdings vorausgehen. Trotz der graphischen Beschreibung sind die oben genannten Techniken als Formal oder zumindestens semi formal anzusehen. Das heißt, die Modelle haben weitestgehend eine formale, eindeutige Semantik. Dadurch werden Fehler der ersten beiden Fehlerklassen weitestgehend ausgeschlossen. Das Verhalten ist exakt beschrieben und kann nicht missinterpretiert werden. Die Nachteile der menschlichen Sprache fallen weg. Voraussetzung ist aber weiterhin, daß das Problem richtig in das abstrakte Modell umgesetzt wurde. Das mit

8 Hilfe eines CASE Werkzeugs erstellte Modell stellt somit, im Gegensatz zum Lastenheft, eine semi-formale Spezifikation dar. Gibt man nun dieses Modell, anstatt des Lastenheftes, dem Software Entwickler als Anforderungsspezifikation, so sind zumindestens Fehler der Klasse 1 ausgeschlossen. Voraussetzung für diese Annahme, ist aber, daß der Software Entwickler diese semi formale Spezifikation versteht und lesen kann. Simulation Die oben genannten Werkzeuge unterstützen aber nicht nur die abstrakte, semi formale Spezifikation des Lastenheftes, sondern auch die Validierung der erstellten Modelle gegenüber dem Lastenheft und letztendlich gegenüber der Idee, die man im Kopf hat. Obwohl die Umsetzung auf einer höheren, problemorientierten Ebene geschehen ist, lassen sich Abweichungen bei der Umsetzung nicht vermeiden. Deshalb ist es wichtig, daß die Vollständigkeit und die Korrektheit der CASE Modelle gegenüber dem textuellen Lastenheft, bzw. gegenüber der Idee, die hinter dem Lastenheft steht, getestet wird, bevor die Modelle zu dem Software Entwickler zur Implementierung gegeben werden. Die Validierung erfolgt dabei grundsätzlich zweistufig.: Zuerst testet man das Modell in einer am PC oder an einer Workstation geschaffenen Umgebung. Dazu gehören einfache Steuerund Reglungsmodelle, aber auch mehr oder weniger komplexe Umgebungsmodelle. Diese Umgebungen werden auch mit den CASE Werkzeugen beschrieben. Werden bei dieser graphischen Simulation Fehler entdeckt, so können diese sehr viel schneller beseitigt werden, als wenn die Fehler erst bei dem Software Entwicker oder noch später bemerkt würden. Dieses ist eine Möglichkeit Zeit einzusparen, indem man die Idee erst einmal testet, bevor diese zur Implementierung gegeben wird. Später werden diese Umgebungsmodelle durch echte Hardware ersetzt. Man spricht dann von Hardware in the Loop Simulation. Durch die Simulation werden nicht in erster Linie Umsetzungsfehler entdeckt, sondern meist Mehrdeutigkeiten und fehlende Festlegungen im Lastenheft. Oft werden auch Fehler im Lastenheft oder generelle Probleme der Idee entdeckt. Mit Hilfe der Idee wird also eine Funktionsfindung und absicherung erreicht. Rapid Prototyping Durch Simulation am Rechner im Labor können natürlich nicht alle Fehler erkannt werden. Insbesondere bei dynamischen Systemen ist eine Abarbeitung in Echtzeit am realen Prozeß unumgänglich. Die Interpretation der Modelle in konkrete Programmiersprachen erlaubt jedoch keine Abarbeitung in Echtzeit. Dazu müssen die graphischen Modelle in konkrete

9 Programmiersprachen übersetzt werden und in ein Echtzeitbetriebssystem eingebettet werden. Auf geeigneten Rechnern können die übersetzten Modelle dann getestet werden. Dies erfolgt zuerst im Labor und dann in einem realen Versuchsträger. Wir sprechen hierbei von Rapid Prototyping. Durch Rapid Prototyping können die zu entwickelnden Funktionalitäten schon in einer sehr frühen Phase im Fahrzeug erlebt werden. Die Validierung der erstellten Modelle kann sehr realitätsnah durchgeführt werden. Zusammen mit der abstrakten Beschreibung können sehr schnell alternative Ideen real erprobt werden, ohne daß der Software Entwickler beteiligt ist. Dadurch ist gewährleistet, daß nur abgesicherte Modelle als Anforderungsspezifikation zum Entwickler gelangen. Die Anzahl der Änderungsschleifen über den Software Entwickler kann insgesamt deutlich reduziert werden. Der CASE basierte Entwicklungsprozess Zusammengefaßt sieht der CASE basierte Prozeß folgendermaßen aus. Im Mittelpunkt stehen die mit Hilfe der CASE Werkzeuge erstellten abstrakte Modelle. Im Gegensatz zu den konkreten Modellen können diese schneller und ohne detaillierte Programmierkenntnisse erstellt werden. Dies muß, mit entsprechender Unterstützung, in den Fachabteilungen des Unternehmens erfolgen. Mit Hilfe von Simulation und Rapid Prototyping Techniken werden die erstellten Modelle dann validiert und abgesichert. Dadurch können Mehrdeutigkeiten und fehlende Beschreibungen im Lastenheft aufgezeigt werden. Erst die abgesicherten Modelle werden beim Software Entwickler implementiert.

10 Vergleich der Prozessarten Die Vorteile des CASE orientiertem Ansatzes liegen auf der Hand. Durch die CASE Werkzeuge erstellen abstakten Modelle sind eindeutiger als das Lastenheft. Dadurch kommt es zu weniger Missverständnissen und dadurch zu einer deutlichen Zeiteinsparung. Außerdem erlauben die CASE Werkzeuge eine eindeutige Trennung von Algorithmus und Implementierung. Dadurch wird dem Entwickler auch eine eindeutige Trennung von den verschiedenen Fehlerquellen in den verschiedenen Versuchsstadien ermöglicht. Diese Trennung erhält besondere Bedeutung vor dem Hintergrund, daß Algorithmenspezifikation und Implementierung oft von unterschiedlichen Personen durchgeführt werden. Der Prototyp Ansatz ermöglicht eine Minimierung des Koordinationsaufwands und damit eine Minimirung des Koordinationsaufwands und damit eine Minimirung der Entwurfszeit. Eine Entwicklung im Stile des klassischen Entwicklungsprozessens kann aber auch von Vorteil sein, wenn das Projekt zum Beispiel nicht so groß ist oder in einem kleinerem Betrieb, wo die technischen Möglichkeiten für Prototyping nicht vorhanden sind.

11 Inhalt EINLEITUNG...2 ANFORDERUNGEN...3 ANFORDERUNGEN AN EINEN ENTWICKLUNGSPROZESS...3 ANFORDERUNGEN VON EINEM ENTWICKLUNGSPROZESS...3 ZIELSETZUNG...3 ENTWICKLUNGSPROZESSE...4 DER KLASSISCHE ENTWICKLUNGSPROZESS...4 Entwicklung...4 Simulation und Fehlerbeseitigung...5 CASE...7 Abstrakte Modellierung...7 Simulation...8 Rapid Prototyping...8 Der CASE basierte Entwicklungsprozess...9 VERGLEICH DER PROZESSARTEN...10 INHALT...11