Anforderungsszenarien für ARM-Entwicklungstools mit Lösungen
Fortsetzung des Artikels von Teil 5
Variante 3: Große Komplexität, viele Änderungen – Hier kommt die UML ins Spiel
Die Bestandteile der Lösung im Einzelnen:
- Keil Compiler IDE
- Keil Realtime Lib
- Evaluation-Board
- U-Link
- Embedded-Display Builder
- ARM-Schulung (Offene Schulung)
- RTOS-Start-up-Workshop (Inhouse)
- Workshop »ARM Real-Time Lib« (Inhouse),
- Gesamtkosten ca. 16500 EUR
Eine vergleichbare Lösung ist auch auf Basis der ARM-Tools von IAR in Kombination mit »embOS« als Laufzeitumgebung denkbar.
Diese Variante basiert auf folgenden Anforderungen:
- Hardware Architektur: Für das Projekt ist eine mittelgroße Produktionsstückzahl (ca. 10000 pro Jahr) geplant. Der Endpreis liegt bei ca. 2500 € pro Gerät, damit fallen die Kosten für die Rechner-Architektur mit ins Gewicht. Trotzdem hat sich das Produkt-Management dafür entschieden, nicht an Speicher und Rechenleistung zu sparen.
- Laufzeitarchitektur-Anforderungen: In wenigen Nebenläufigkeiten gibt es hohe Echtzeitanforderungen, darüber sind weitere Nebenläufigkeiten vorhanden, die jedoch mit Reaktionszeiten im 100-ms-Bereich recht geringe Zeitanforderungen haben. Es wird mehrere Produktvarianten geben und innerhalb des Produktes mehrere Betriebsmodi (Service- und Diagnose-Modus, Kalibrierungs-Modus, StandBy-Modus, Datenabgleichs- und Lademodus, etc.). Durch die daraus resultierenden Abhängigkeiten und Sonderzustände entsteht erfahrungsgemäß eine große Komplexität.
- Lebensdauer des Produktes: Als Produktlebensdauer sind ca. acht Jahre projektiert. Während dieser Zeit steigen die Anforderungen erfahrungsgemäß kontinuierlich an. Weiterentwicklungen müssen auf Basis von ausgelieferten Produkten geschehen, das Produkt muss Upgrades zulassen. Wartbarkeit und Erweiterbarkeit müssen über den ganzen Lebenszyklus gesichert sein.
- Standards: Einige Varianten des Produkts werden als Halbzeug gefertigt und von verschiedenen Endkunden in deren Produkte integriert. Einige der Kunden fordern die Einhaltung des »MISRA«-Standards, zudem sind Schnittstellen (z.B. »CAN Open«) zu definieren und einzuhalten.
- Time To Market: Bis zur geplanten Markteinführung sind es noch zwölf Monate. Es stehen vier Entwickler im Software-Engineering zur Verfügung. Bisher hat es immer wieder Änderungen in letzter Minute gegeben, weil das Bedienkonzept oder andere Dinge nicht den Erwartungen entsprachen. Sorgfältig erstellte Pflichtenhefte konnten die Anzahl der Änderungsanforderungen in der Vergangenheit nicht senken.
- Qualität: Ausfälle des Systems können zu hohen Imageverlusten führen. Derzeit ist die Firma für die Robustheit der Systeme bekannt, vor allem auch für die gute Bedienphiliosophie.
- Erfahrung: Erfahrung in der Anwendung der Hochsprache ANSI-C auf verschiedenen Hardwareplattformen ist vorhanden, jedoch nicht mit der ARM Architektur. Erfahrungen mit dem Einsatz eines RTOS oder anderen Werkzeugen zum Architekturdesign sind teilweise auf Basis des RTOS »embOS« vorhanden.
- Budget: Es steht ein Budget für die Anschaffung von Entwicklungstools zur Verfügung. Darüber hinaus ist das Management zu Investitionen für notwendige Software-Engineering-Maßnahmen bereit, wenn diese die Qualität und die Liefertreue sichern.
Und so sieht der Vorschlag einer Entwicklungsumgebung aus, welche sich an den obigen Anforderungen orientiert: Vor dem Hintergrund von acht Jahren Lebensdauer, der gewünschten hohen Qualität und der besonderen Anforderungen an Variantenreichtum und Modi der Anwendung ist mit einem sehr komplexen Architekturdesign zu rechnen. Um dennoch Wartbarkeit und Änderbarkeit über den gewünschten langen Zeitraum sicher zu stellen, kommt die UML als grafische Modellierungssprache zum Einsatz. Mit einem Modellierungstool erlaubt die UML, Prototypen in kurzer Zeit zu modellieren. Auf diese Weise sollen Test der Bedienphilosophie früher im Designablauf erfolgen, um eventuelle Änderungswünsche so früh wie möglich zu erhalten.
Jobangebote+ passend zum Thema
- Anforderungsszenarien für ARM-Entwicklungstools mit Lösungen
- Andreas Willert
- Diese Tools sind immer ratsam
- Variante 4: Viel IP im Spiel, komplexe Anforderungen, Dokumentation existenziell – das ganz große Paket
- Anforderungsszenarien für ARM-Entwicklungstools mit Lösungen
- Variante 3: Große Komplexität, viele Änderungen – Hier kommt die UML ins Spiel
- Variante 2: Viele Tasks, hoher Qualitätsanspruch – C reicht gerade noch aus, aber ein RTOS muss sein
