Startseite > Messen + Testen > Sensorik > Modellbasierte Sensorentwicklung

Entwickler-Interview

Modellbasierte Sensorentwicklung

26. Juli 2017, 16:11 Uhr | Constantin Tomaras

▶ Diesen Artikel anhören

Fortsetzung des Artikels von Teil 3

Konsolidierung im Sensormarkt?

Apropos Größe, wie sieht es denn da bei der Firmware aus?

HOLLENBACH: Im Prototyping ist die Größe erst einmal zweitrangig. Die zentrale Frage hierbei „Können wir die Funktion herstellen?“ wird im Zusammenspiel von Hard- und Software beantwortet.

Kommen wir dem endgültigen Produkt näher, dann wird die Frage nach der Codegröße interessanter: Oft ist der generierte Code nur wenig größer, dafür gut zu warten. Auch können verschiedene Implementierungen aus dem Modell abgeleitet und verglichen werden - was mitunter zu Überraschungen führen kann. Manchmal liefert dieser Ansatz ein Ergebnis, das mit Blick auf die Größe selbst erfahrene Programmierer unterbietet.

Wir haben das exemplarisch für das Lösen eines linearen Gleichungssystems auf der Matlab Expo vorgestellt.

Bleiben wir bei der Vielfalt: Stört Sie die Vielfalt bei den Schnittstellen nicht?

SCHWABE: Doch, diese erhöht die Komplexität unserer Produkte oder begrenzt deren Nutzen bei unseren Kunden. Aus diesem Grund sehen wir auch, dass hier eine Konsolidierung einsetzt. In unserem Tagesgeschäft merken wir sehr schnell, dass die Bereitschaft der Kunden, sich mit proprietären, hausgemachten Lösungen auseinandersetzen zu müssen, eher gering ist.

Ganz ähnlich ist das auch bei der Software: Wir beobachten, dass viele offene, frei verfügbare Umgebungen, wie etwa Python, großen Zulauf erhalten. Solche Tools sind auch ideal für die internationale Maker-Szene, die wir nicht nur wahr, sondern sehr ernst nehmen. Denn hier entwickeln sich einige sehr interessante Anwendungen für unsere Technologien.

Es bleibt aber oft noch ein weiter Schritt von solch einer Lösung hin zu einer für die Massenproduktion.

Wie sehen Sie denn die Entwicklung neuer Sprachen für embedded Systeme?

HOLLENBACH: Hier ist C – mit all seinen Vor- und Nachteilen – unangefochtener Platzhirsch. Wir sehen nicht, dass sich das auf absehbare Zeit ändern wird. Was wir an Veränderungen feststellen können: Einige der Nachteile von C werden inzwischen durch zusätzliche Tools ausgeglichen, wie etwa durch Verifikationstools rund um MISRA. Hier geschieht einiges, insbesondere bei der Integration in die Entwicklungsumgebungen. Bei diesen ist momentan Eclipse weit verbreitet.

Bei der Software, die auf dem Host-Rechner läuft, ist eine ähnliche Dominanz nicht abzusehen.

Bewegen sich die Programmieroberflächen im Sensormarkt auch dorthin?

SCHWABE: Lassen Sie mich da einen Vergleich mit dem Mikrocontroller-Markt ziehen: Vor zehn Jahren gab es viele proprietäre Lösungen am Markt – heute hat sich das auf die ARM-Kerne reduziert. Das ergibt auch Sinn, denn ARM liefert neben dem Kern-Design eine qualitativ hochwertige Toolchain, mit der Firmware für verschiedenste Applikationen optimiert werden kann. Das liefert kein anderer Mikrocontroller-Hersteller in dieser Form.

Sensoren unterscheiden sich allerdings in einem wesentlichen Punkt: Die Differenzierung eines Sensors erfolgt über seine technische Implementierung. Um die Schnittstellen nochmals aufzugreifen: Welchen Mehrwert und welche Differenzierung schafft es denn wirklich, wenn drei, vier oder noch mehr Kommunikationsprotokolle im Sensor bereitgehalten werden?

Welches Protokoll wird sich Ihrer Meinung nach durchsetzen?

SCHWABE: Auch das ist natürlich eine schwer zu beantwortende Frage. Für bestimmte Applikationen wird es sicherlich standardisierte Schnittstellen geben. Ein möglicher Kandidat dafür ist I²C. Er ist stark im Powerbereich etabliert und schon allein durch den derzeitigen Standardisierungsgrad engere Wahl.