Startseite > Halbleiter > Erfolgreiches Design ohne Rücksicht auf sich ändernde Anforderungen

Embedded-Entwicklung

Erfolgreiches Design ohne Rücksicht auf sich ändernde Anforderungen

8. Juni 2010, 17:15 Uhr | Jon D. Pearson, Cypress Semiconductor

▶ Diesen Artikel anhören

Fortsetzung des Artikels von Teil 4

Schaffung der Voraussetzungen für austauschbare Features

Aus den Schritten 2 und 3 ist zu ersehen, dass für jeden Block ein Maximum an Flexibilität vorgesehen wird. 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 beispielsweise 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 Features angewandt werden. Ein Weg hierhin führt über die Einrichtung von ‚Feature-Objekten‘, die 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, mit der die Displaysprache eingestellt wird. 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 werden? Selbst bei einer solch bedeutenden Modifikation würden nur die betroffenen Teile der Temperatur‑, Heiz‑ und Lüfter-Blö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 radikale Änderungen mit begrenzten Auswirkungen auf das System insgesamt durchgeführt werden können.

Als weiterer positiver Nebeneffekt kommt hierbei hinzu, dass die Feature-Objekte in hohem Maße wiederverwendbar sind, wenn man sie so konzipiert, dass die in ihnen vorgenommenen Änderungen vom übrigen System abgeschirmt werden. Die gleiche Flexibilität für Änderungen im System wird nämlich auch künftigen Systemen geboten. Arbeiten mehrere Teams an verschiedenen, aber miteinander zusammenhängenden Produkten, bietet dieses Konzept die Möglichkeit, Technologie und Innovationen untereinander auszutauschen, besonders wenn die Produkte auf einer ähnlichen Struktur aufbauen.