Zeitdruck versus Anforderungen = Risiko
Embedded-Entwicklung: Wenn sich Anforderungen ändern
Fortsetzung des Artikels von Teil 1
Aussitzen - aber richtig!
Features sollen austauschbar sein
Aus den vorangegangenen Schritten ist zu ersehen, dass jeder Block so flexibel wie möglich vorgesehen ist. Im jetzigen Schritt geht es darum, dieses Konzept auf alle Aspekte des Produkts auszudehnen. Alle Features lassen sich auf ähnliche Weise behandeln - zumindest diejenigen Merkmale, die das Embedded-Design betreffen.
Zu fragen ist beispielsweise, ob die Bedienoberfläche mit Berührungstasten oder mit modernen kapazitiven Sensoren realisiert werden soll. Soll der Speicher für die Rezeptdatenbank mit 8 KByte internem Flash-Speicher implementiert werden oder ist eine austauschbare SD-Card vorzuziehen, auf die der Anwender neue Rezepte laden kann? Besitzt das Umluftsystem einen Lüfter oder mehrere (für verschiedene Temperaturzonen)? Für jedes Feature sollte man einen »Wrapper« definieren.
Diese äußere Hülle macht es möglich, die Details des jeweiligen Features zu verändern, während die vom System wahrgenommene Schnittstelle die gleiche bleibt. Der am Beispiel der Temperatur gewählte Weg kann auch bei allen anderen Produkt-eigenschaften angewandt werden. Ein Weg hierhin führt über die Einrichtung von »Feature-Objekten«, welche die Algorithmen und Details enthalten, aber die Ergebnisse auf die immer gleiche und leicht weiterverarbeitbare Weise an die Steuerungslogik weitergeben.
Wenn es beispielsweise nötig ist, dass das Display Meldungen auf Englisch, Französisch, Chinesisch oder Koreanisch ausgibt, würde das Feature-Objekt eine Property für die Displaysprache besitzen und über eine Funktion »void setLanguage(char newLang)« verfügen. Zum Hinzufügen weiterer Sprachen müsste nicht die Steuerungslogik verändert werden, sondern lediglich die unteren Ebenen der Displayfunktion. Wie steht es aber bei einer tiefgreifenden Änderung am Produkt, wenn beispielsweise anstatt einer durchgehenden Temperaturzone mehrere Temperaturzonen gewünscht sind?
Selbst bei einer solch bedeutenden Modifikation würden nur die betroffenen Teile der Temperatur-, Heiz- und Lüfterblöcke aktualisiert, möglicherweise ergänzt durch eine neue Steuerungsfunktion. Es wäre jedoch in jedem Fall unnötig, alles zu ändern. Allerdings könnte man hier noch eine weitere Verbesserung erzielen, indem man in einer Brainstorming-Session sämtliche Eventualitä-ten auslotet und alle potenziell betroffenen Elemente in einer Art »Feature-Block« zusammenfasst. Ziel dieser Maßnahme ist die Bündelung aller Teile, an denen sich radikale Änderungen mit begrenzten Auswirkungen auf das gesamte System durchführen lassen.
Als weiterer positiver Nebeneffekt kommt hinzu, dass die Feature-Objekte in hohem Maße wiederver-wendbar sind, wenn man sie so konzipiert, dass die in ihnen vorgenommenen Änderungen vom übrigen System abgeschirmt sind. Die gleiche Flexibilität für Änderungen im System steht dann auch künftigen Systemen zur Verfügung.
Arbeiten mehrere Teams an verschiedenen, aber miteinander zusammenhängenden Produkten, bietet dieses Konzept die Möglichkeit, Know-how untereinander auszutauschen, besonders wenn die Produkte auf einer ähnlichen Struktur aufbauen. Alle bisherigen Beschreibungen eignen sich für praktisch jedes Design mit einem oder mehreren Mikrocontrollern beliebigen Typs und von beliebigen Herstellern.
Interessant wird es natürlich, wenn der programmierbare Baustein selbst so flexibel ist, dass im Prinzip jede denkbare Änderung, sogar fundamentale Modifikationen an der Hardware und an den Verbindungen, innerhalb des Bausteins durchführbar sind. Ein Beispiel für solch einen Baustein ist das »PSoC 3« (Programmable System-on-Chip) von Cypress.
Dessen Architektur enthält analoge Blöcke und Subsysteme mit flexiblen Routing- und Multiplexing-Ressourcen sowie programmierbare digitale Blöcke mit einer noch flexibleren Interconnect-Struktur. Verknüpft (respektive überwacht) wird alles von einer weiterentwickelten Version des Mikroprozessors »8051«. Dieser kann die konfigurierten Mixed-Signal-Fähigkeiten nicht nur überwachen und steuern, sondern bei Bedarf auch neu konfigurieren und buchstäblich neu »verdrahten«.
Mit dem »PSoC Creator« steht eine integrierte Entwicklungsumgebung (IDE) bereit. Die IDE ist so strukturiert, dass sie ein auf Wrappern basierendes Design der beschriebenen Art ermöglicht und Komponenten aus elementaren Logikfunktionen beisteuert - bis hin zu kompletten kapazitiven Berührungssensoren. Die Fähigkeit, diese Komponenten umgehend hinzuzufügen und auszutauschen, macht das Wesen des PSoC-3-basierten Designs aus. Wenn sich Designer an die zuvor beschriebene Vorgehensweise halten, können sie diese Architektur in vollem Umfang ausschöpfen.
Objektorientiert?
Kundige Leser werden bemerkt haben, dass die geschilderten vier Schritte offensichtlich zu einem »objektorientierten« Design hinführen. Speziell: einem Design aus Objekten, die ihre spezifischen Daten und ihre Implementierung vor der Außenwelt verbergen. Tatsächlich nutzen Verfechter der objektorientierten Programmierung seit Jahrzehnten die angeführten Vorteile dieses Konzepts, also abgemilderte Auswirkungen von Änderungen an einzelnen Teilen auf das Gesamtsystem und verbesserte Wiederverwendbarkeit.
Die meisten neuen oder abgewandelten Programmiersprachen bieten deshalb strukturelle Unterstützung für das objektbasierte Design. Über Erfolg oder Misserfolg eines objekt-orientierten Designs entscheidet allerdings nicht die Sprachwahl, denn keine Sprache kann einen Programmcode, der ohne fundiertes Design heruntergeschrieben wurde, in einen Erfolg ummünzen.
Die beschriebenen Vorteile lassen sich somit auch mit jeder Sprache erzielen - die Entscheidung fiel für C einfach wegen der großen Verbreitung dieser Sprache. Eines der besten objektorientierten Designs, mit denen der Autor je zu tun hatte, war mit »PL/M« von Intel auf einem »80C86«-Prozessor implementiert, und sein Erfolg resultierte allein aus dem Design. Die Sprache war nicht mehr als ein Schritt aus der Assembler-Ebene heraus.
Jobangebote+ passend zum Thema
- Embedded-Entwicklung: Wenn sich Anforderungen ändern
- Aussitzen - aber richtig!
Lesen Sie mehr zum Thema
