Objektorientierung und modellbasierte Werkzeuge

Anbieter zum Thema

Linutronix GmbH

Parasoft® Deutschland GmbH

Grundentscheidungen

Aufgrund der sehr verwobenen Struktur nach Bild 1 war relativ schnell klar, dass aus dem bestehenden Produkt eigentlich nur die Erfahrungen im Betrieb von elektrischen Kleinantrieben übernommen werden konnten. Alle Teile der Software mussten neu entworfen werden.

Eine Aufgabe war daher die Suche nach einer Prozessorplattform für die speziellen Anforderungen von integrierbaren Kleinantrieben. Die Andere die Suche nach einer geeigneten Entwurfs-Methodik, verbunden mit der Suche nach geeigneten Werkzeugen, die es erlauben würden, die Grundentscheidungen aus dem Entwurf auch in der Implementierung abzusichern.

Abweichend vom bisherigen Vorgehen sollte ein objektorientierter Ansatz verfolgt werden, auch um den Entwurf über die Mechanismen der UML zu strukturieren.

Bereits bisher kamen für die Entwicklung der signalverarbeitenden Softwareteile in der Regelung und Positionsauswertung TargetLink für die Code-Erzeugung aus SIMULINK Modellen zum Einsatz. Dieser Ansatz eignet sich aber nicht, um die eher eventbasierten Softwareteile aus der Treiber-Schicht, dem Parameterhandling, der Kommunikation und auch der Antriebssteuerung zu beschreiben und dann auch zu Implementieren.

Nach einer ersten Evaluation und auf der Basis der Erfahrungen aus früheren Projekten [1] fiel die Entscheidung auf Rhapsody bzw. für die Embedded Version wie sie von der Fa. Willert angeboten wird. Hauptargumente waren:

• Arbeitet nativ im OO Entwurf

• Unterstützung von typischen Embedded Plattformen auch in C bei guter Lesbarkeit

• Ausreichende Durchgängigkeit vom Entwurf bis in die Implementierung

• Guter Einstieg möglich, da wenig Legacy Anteile zu übernehmen

Es war aber von Beginn an klar, dass damit auch eine erhebliche Lernkurve sowohl hinsichtlich der Bediensicherheit des Werkzeugs, als auch in der Entwurfsmethodik anstehen würde. Klar war daher auch, dass wir uns einen erfahrenen Partner für die anstehenden Kernthemen suchen mussten, den wir in der Fa Tieto bzw. Tieto Embedded Systems – heute b1 Engineering Solution fanden.

Architektur & Design

Basierend auf der erarbeiten Spezifikation, den Use-Cases des Systems, und den Erkenntnissen aus dem Bestandssystem entstand zunächst eine Grobarchitektur:

• Aufteilung der Gesamtfunktion in Pakete und z.T. auch schon in Objekte

• Definition der treibenden Aktivitäten des Systems

• Klärung der Datenverwaltung bzgl. des Umgangs mit den Parametern und deren Speicherung

Umsetzung

Angewandte Muster waren die Schichtbildung (Layering) mit insbesondere einer eindeutigen Zuordnung von Verantwortlichkeiten für die Kapselung der µController typischen Peripherieeinheiten im HAL und einer darauf aufsetzenden Middleware Schicht. Die Middleware Schicht stellt deutlich abstrahierte Informationen wie die Motorgeschwindigkeit als Ergebnis unterschiedlichster Sensorsysteme zur Verfügung, oder errechnet Stellgrößen aus allgemeinen Vorgaben, wie z.B. die passende Ansteuerung für den angeschlossenen Motor aus der Sollspannung des Reglers.

Um eine Signalflussrichtung entgegen den definierten Abhängigkeitsbeziehungen zu realisieren, wurde das Publish/Subscribe-Pattern bzw. Beobachter-Muster verwendet. Dazu registrieren Informations-Konsumenten aus höheren Schichten Callback-Funktionen und Instanz-Zeiger bei den Informations-Produzenten in den niedrigeren Schichten. Dieses Pattern wird gleichermaßen für den Übergang zwischen Interrupt-Kontext und Task-Kontext, als auch zwischen Task-Kontexten verwendet. Um die Nebenläufigkeiten zu beherrschen, wird in den Callback-Funktionen daher im Allgemeinen ein Event der Laufzeitumgebung an die adressierte Objekt-Instanz versendet. Es ist vielfach ausreichend, genau einen Subscriber bereits während der Initialisierung zu registrieren.

Die Aktivitäten des Systems können aufgeteilt werden in die streng zeitlich getriebenen Aktivitäten einerseits:

• Der Timerinterrupt für die Motorregelung (100µs, synchron zu PWM)

• Ein Timerinterrupt mit 1ms Zykluszeit für Diagnoseaufgaben

Beide werden über einen Interrupt angestoßen und auch im Interrupts Kontext ausgeführt. Entworfen werden diese signalverarbeitenden Systemteile in SIMULINK und über TargetLink in C-Code mit einer zum Systementwurf passenden Schnittstellengestaltung überführt.

Auf der anderen Seite stehen die eher reaktiven Aktivitäten:

• Externe Ereignisse wie z.B. der Empfang einer kompletten Botschaft aus den Kommunikations-Stacks (die Verarbeitung der einzelnen Zeichen z.B. der RS232 Schnittstelle werden komplett im Schnittstelleninterrupt-Kontext ausgeführt).

• Time-outs über einen niedriger priorisierten Timer

In beiden Fällen wird der Interrupt-Kontext verlassen und ein Event ausgelöst, der typisch über eine Zustandsmaschine bearbeitet wird. Die Modellierung der Interaktion kann hier vorteilhaft über Kommunikationsdiagramme, die Systemreaktion über Zustandsmaschinen entworfen werden.

(ID:44055654)