Kontron: +55 % beim Ergebnis

Die Kontron AG, spezialisiert auf Industrie PCs und embedded Lösungen, hat ihre dynamische Geschäftsentwicklung auch im 2. Quartal weiter fortgesetzt und Umsatz aber vor allem Gewinne kräftig steigern können.

Effizient Gerätesoftware zu entwickeln bedeutet, sich auf die wesentlichen Aufgaben zu konzentrieren – die Applikation. Wiederkehrende Probleme lassen sich durch Verwendung von Frameworks, Bibliotheken und Komponenten elegant lösen. Es gilt, das Rad nicht zweimal zu erfinden.

Mit 111,7 Mio. Euro lagen die Erlöse um 20 % über dem Vorjahreszeitraum (93,3 Mio. Euro), währungsbereinigt lag die Steigerung sogar bei 24 %. Im 1. Halbjahr stieg der Umsatz damit auf 207,6 Mio. Euro gegenüber 179,9 Mio. Euro im Vorjahreszeitraum. Auch der Auftragsbestand erreichte mit 256,7 Mio. Euro gegenüber 219,6 Mio. Euro zur Jahreswende ein neues Rekordniveau.
Noch stärker hat der IPC-Anbieter beim Ergebnis zulegen können: Mit einem EBIT von 10,4 Mio. Euro lag Kontron im 2. Quartal 55 % über dem Vorjahreszeitraum (6,7 Mio. Euro). Für das 1. Halbjahr ergibt sich ein Gesamt-EBIT von 17,2 Mio. Euro gegenüber 11,8 Mio. Euro im Vorjahreszeitraum. Kontron führt diese Entwicklung insbesondere auf sein "Profit Improvement Programm" zurück. Sehr positiv hat sich dementsprechend auch der Periodenüberschuss entwickelt, der im 2. Quartal auf 7,9 Mio. Euro gegenüber 4,6 Mio. Euro im Vorjahreszeitraum um 71 Prozent gestiegen ist. Im 1. Halbjahr lag der Periodenüberschuss bei 12,8 Mio. Euro gegenüber 8 Mio. Euro im Vorjahreszeitraum.
Wichtigster Treiber des zukünftigen weiteren Wachstums wird nach Unternehmenseinschätzung die ATCA-Technologie sein, die nicht nur in der Telekommunikations-Industrie, sondern zunehmend auch in neuen Anwendungen wie der Sicherheits- und Medizintechnik zum Einsatz kommen wird.

Um in einem hart umkämpften Markt bestehen zu können, müssen Embedded-Lösungen in kurzer Zeit den sich ändernden Anforderungen entsprechend entwickelt werden. Aus diesem Grund muss die Software oft parallel zur Hardware entstehen. Eine klare und modulare Architektur erfüllt die Forderung nach Flexibilität. Module lassen sich nach Bedarf ergänzen und wieder herauslösen. Eine maßgeschneiderte Architektur reduziert die Entwicklungszeit signifikant. Das Motto ist: »Das Rad nicht zweimal neu erfinden«.

Viel Zeit und Aufwand lässt sich einsparen, wenn bekannte Lösungen und Standards verwendet werden. Vorgefertigte Lösungen, Standardprozesse sowie gut definierte und dokumentierte Schnittstellen bietet das »Apparatus Framework « (AF) der Firma bbv Software Services. Dieses in C++ geschriebene Framework lässt sich auf verschiedenen Echtzeitbetriebssystemen einsetzen und ist kostenlos unter apfw.sourceforge. net erhältlich.

Auf der Basis des AF sollen Designer Applikationen schnell und einfach entwickeln können. Da das Framework funktionell mächtige Schnittstellen zur Verfügung stellt, muss sich ein Entwickler nicht mit dem Betriebssystem und dessen Eigenheiten befassen. Somit kann er fokussiert an der eigentlichen Kernaufgabe arbeiten, der Applikation. Apparatus- Framework unterstützt diverse Echtzeitbetriebssysteme, zusätzlich wird Windows als Betriebssystem abstrahiert. Daher kann der Designer die Applikation auf Windows entwickeln. Daraus resultieren einige entscheidende Vorteile:

  • mächtige Werkzeuge sind verfügbar,
  • teure Werkzeuge entfallen (Embedded-Emulator),
  • kurzer Entwicklungszyklus,
  • Simulation ist möglich und
  • unabhängig von der Hardware.

Für Windows sind mächtige Software-Tools erhältlich, welche den Entwicklungsprozess unterstützen. Mit ihnen ist die Möglichkeit, ein System zu beobachten, um ein Vielfaches besser, weil genügend Ressourcen und mächtige Tools auf dem PC vorhanden sind, um Log- Daten aufzuzeichnen und Code zu tracen. Im Embedded- Umfeld sind dazu ein Debugger und ein Emulator notwendig, die leider im Allgemeinen teuer und weniger leistungsfähig sind als Windows-Tools. Oft stehen auch nicht genügend Embedded- Werkzeuge für jeden Entwickler bereit. Tools für den PC sind viel kostengünstiger und können in ausreichender Zahl besorgt werden. Im Embedded-Umfeld dauert der Entwicklungszyklus wesentlich länger, weil zusätzlich zum Cross-Kompilieren die Software auf das Gerät gebracht werden muss. So lässt sich erst nach kompliziertem und zeitaufwendigem Download das Verhalten testen und analysieren. Wird die Software auf dem PC entwickelt, kann dies entfallen. Oft unterschätzt man den zusätzlichen Aufwand, die Hardware in Betrieb zu nehmen oder diese für verschiedene Konfigurationen anzupassen.

Fortsetzung (Seite 1/3)12 | 3nächste Seite >>

Das Apparatus-Framework unterstützt verschiedene Kommunikationsmedien und -protokolle, zum Beispiel TCP/IP, CAN, CANopen sowie serielle Protokolle. Damit sich die Kommunikationsmodule flexibel einsetzen lassen, sind die Protokolle strikt von physikalischen Devices getrennt. Folglich ist der Einsatz von Protokollen auf diversen Kommunikationsmedien ohne großen Aufwand realisierbar. Im Framework sind weitere Devices wie Watchdog, Konsole und ein Powerfail-sicheres Dateisystem enthalten.

Die Architektur ist so gestaltet, dass sich Devices und Kommunikationsprotokolle einfach ergänzen lassen. Entwicklung und Implementierung sind besonders einfach, weil viele Pattern in AF vorhanden sind und genutzt werden können. Auch eigene STL-Funktionen stellt das Framework zur Verfügung. Diese Funktionen offerieren dieselbe Schnittstelle wie die bekannte STL, allerdings verzichtet bbv gänzlich auf dynamischen Speicher, um die Stabilität zu garantieren. Speichergrößen werden während der Kompilierung festgelegt. Tasks kommunizieren mittels eines eingebauten Messagesystems.

In der Entwicklungsphase der Applikation ist es hilfreich, die gesendeten und empfangenen Messages aufzuzeichnen und zu analysieren. Die Sende- und Empfangsqueue jeder Task kann zur Laufzeit des Systems zur Liste der überwachten Tasks hinzugefügt oder entfernt werden. So sendet der Logger die Messages via serielle Schnittstelle zu einem Terminal. Dieser Mechanismus ist eine günstige Möglichkeit, die Software zu beobachten und Abläufe nachzuvollziehen. Auch eignet er sich bestens für eine Diagnose im Feld unter Echtzeitbedingungen. Oft lässt sich so der Einsatz teurer Debug-Werkzeuge einsparen.

Komplett getestet

Das komplette Apparatus- Framework ist mittels Unit- Tests getestet, um die Qualität des Frameworks zu garantieren. Korrekturen und Erweiterungen einzelner Komponenten, Patterns und Devices lassen sich somit einfach und schnell testen. Das Konzept der Unit-Tests ist problemlos auf die zu entwickelnde Applikation ausdehnbar. So lässt sich die Güte einzelner Module der Applikation mittels Unit- Tests überwachen und sicherstellen. Natürlich müssen die Testfälle für die Applikation selbst geschrieben und unterhalten werden.

AF bietet ein breites Spektrum von Funktionen an. Um eine funktionelle, Ressourcen sparende Lösung zu erreichen, kann man das Framework individuell auf die jeweiligen Bedürfnisse abstimmen. Parametriert wird das Framework mittels eines intuitiven Konfigurationstools. Das Apparatus-Framework ist eine Open-Source-Lösung, sämtlicher Code unterliegt dem LGPL-Model (Lesser General Public License). Da der komplette Code offen liegt, lässt sich dieser erweitern und gegebenenfalls speziellen Bedürfnissen anpassen. Auch bindet sich das Framework dadurch an keine bestimmten Tools und Betriebssysteme.

Geplant ist, AF zu erweitern, um Multicore-Applikationen zu unterstützen. Außerdem ist passend zum Apparatus- Framework eine generische Hardware-Simulation angedacht. Die Simulation wird mittels XML-Dateien der Hardware angepasst. Eine maßgeschneiderte Hardwaresimulation für ein neues Projekt ist somit einfach und schnell erstellt. Die XML-Beschreibung ist außerdem Basis, um den I/O-Controller zu generieren.

Ralf Higgelke, Design&Elektronik (01/2007)

<< vorherige Seite1 | 2 | 3

All diese Argumente drängen den Einsatz einer Simulation auf. Da jede Embedded-Applikation mit ihrer Umwelt interagiert, muss in der Windows-Umgebung dieses Umfeld simuliert werden, um die Applikation unter realistischen Bedingungen zu entwickeln. Das Apparatur- Framework unterstützt dies (Bild 1).

Eine Simulation der Umgebung bietet zahlreiche Vorteile. So ist eine Simulation verhältnismäßig einfach und schnell erstellt. Dagegen muss die Hardware im Allgemeinen erst entwickelt werden und steht oft erst zu einer späteren Projektphase zur Verfügung. Ein weiterer wichtiger Vorteil ist die Flexibilität einer Simulation. So ist es viel aufwändiger, die Hardware zu ändern, als die Simulation einem neuen Umfeld anzupassen. Eine Simulation kann recht einfach verschiedene Hardwarevarianten abdecken und durch unterschiedliche Konfigurationen verschieden parametrierte Geräte darstellen. Des Weiteren ist eine Simulation beliebig oft kopierbar – teures Duplizieren der Hardware- Funktionsmuster entfällt.

Applikation und Simulation kommunizieren mittels TCP/IP miteinander. Dadurch lassen sich Simulation und Applikation auf zwei verschiedenen Rechnern ausführen. Eine Simulation ist bestens dafür geeignet, funktionelle Abläufe zu simulieren, für zeitkritische Abläufe stößt sie aber an ihre Grenzen. Daher ist es unumgänglich, die Software auch auf der realen Hardware zu testen.

Pattern verkürzen Entwicklung

Doch zurück zum Apparatus- Framework. Darin sind diverse Software-Pattern implementiert, wodurch sich die Entwicklungszeit deutlich reduziert, weil geleistete Arbeit wiederverwendet werden kann. Weil der verwendete Code zuverlässig ist, sinkt das Projektrisiko. Er ist mehrfach getestet und hat sich im täglichen Einsatz bewährt. Im AF sind folgende Pattern enthalten: Singleton-, Timer-, Watchdog-, Factory- und State-, String- Compression- und Observer/ Observable-Pattern.

Diese sollen im Folgenden kurz besprochen werden. Um die Funktion eines Gerätes zu überwachen, wird in Embedded-Softwareprojekten üblicherweise der Hardware- Watchdog des Mikrocontrollers eingesetzt. Dieser Ansatz ist nicht vollkommen, weil sich zwei Tasks gegenseitig blockieren können, auch wenn das Betriebssystem und große Teile der Software einwandfrei funktionieren. Watchdog- Pattern erkennen solche Zustände und leiten gegebenenfalls eine geeignete Fehlerbehandlung ein. Mittels des Factory-Pattern wird die Applikation kontrolliert gestartet.

Der Start erfolgt in drei Hauptschritten: Registrierung, Initialisierung und Freigabe. Eine solche Granulierung in drei Phasen ist notwendig, um die komplexen Abhängigkeiten beim Start eines Systems zu kontrollieren und geordnet den Betrieb aufzunehmen. Analog zum Start des Systems funktioniert dessen Shutdown.

<< vorherige Seite1 | 23nächste Seite >>