Es braucht ein ganzes Dorf: Warum Entwickler eine ... · Dieses Konzept lässt sich am besten am...

6
Virtuelle Instrumente in der Praxis VIP 2016 169 Embedded Design Es braucht ein ganzes Dorf: Warum Entwickler eine Softwareplattform mit einem robusten Ökosystem benötigen Jeffrey Phillips National Instruments Corporation, Austin, USA Kurzfassung „Es braucht ein ganzes Dorf.“ Auch wenn sich dieses afrikanische Sprichwort eigentlich darauf bezieht, dass für die Erziehung und gesunde Entwicklung eines Kindes neben dem engeren Familienkreis auch die Unterstützung des Umfelds nötig ist, lässt sich dieses Kon- zept doch genauso gut auf die Technikwelt übertragen. Das Tempo und die Erwartungen einer vernetzten Welt haben sich rasant auf die Design- und Prüfanforderungen von Ent- wicklungssystemen ausgewirkt, für deren Erfüllung es heute mehr denn je eines ganzen „Dorfes“ an Software bedarf. Die Entwicklungssoftware von heute lässt sich im Großen und Ganzen in zwei Bereiche einteilen: Auf der einen Seite steht die Spezialisierung, d.h. Software, die für eine ganz bestimmte Aufgabe oder Hardware entwickelt wurde. Auf der anderen Seite findet sich die sogenannte Abstraktion, wobei ein ursprünglich komplexes Konzept schematisch verein- facht wird, damit sich bestimmte Aufgaben schneller lösen lassen. Allerdings bleiben dabei detaillierte Informationen zur zugrundeliegenden Funktionsweise verborgen, sodass keine Low-Level-Steuerung möglich ist. Jeder Anbieter, der behauptet, beide Bereiche mit einer einzigen Software abdecken zu können, ist entweder naiv oder hat schlichtweg keine Ahnung – beides keine guten Voraussetzungen. Unabhängig davon, ob die Entscheidung nun auf Spezialisierung oder Abstraktion fällt, Anbieter müssen die Interoperabilität ihrer Werkzeuge gewährleisten, denn ansonsten lastet der Integrationsaufwand allein auf den Schultern des Anwenders. Abstract “It takes a village.” While this African proverb generally refers to the need for an influen- tial infrastructure beyond the immediate family for the healthy development of a child, you might be surprised to learn that this same concept can be extended to the engineering world. The pace and promise of a connected world have rapidly escalated the demands on the design and test of engineering systems, and now, more than ever, it takes a village – a village of software. Today’s engineering software has typically evolved along two diverg- ing paths. Along one path, you will find specialization – software designed for a specific task or type of hardware. Along the other path, you will find abstraction – a simplified interface to a once complex concept that makes it easier to accomplish the task faster, but at the price of removing low-level control. Any vendor that claims to solve these chal- lenges with a single software is either confused or naïve. I am not sure which one is worse, but know that whichever path you choose, you must demand interoperability or risk bear- ing the burden of integration yourself.

Transcript of Es braucht ein ganzes Dorf: Warum Entwickler eine ... · Dieses Konzept lässt sich am besten am...

Virtuelle Instrumente in der Praxis VIP 2016

169

Embedded Design

Es braucht ein ganzes Dorf: Warum Entwickler eine Softwareplattform mit

einem robusten Ökosystem benötigen

Jeffrey PhillipsNational Instruments Corporation, Austin, USA

Kurzfassung„Es braucht ein ganzes Dorf.“ Auch wenn sich dieses afrikanische Sprichwort eigentlichdarauf bezieht, dass für die Erziehung und gesunde Entwicklung eines Kindes neben demengeren Familienkreis auch die Unterstützung des Umfelds nötig ist, lässt sich dieses Kon-zept doch genauso gut auf die Technikwelt übertragen. Das Tempo und die Erwartungeneiner vernetzten Welt haben sich rasant auf die Design- und Prüfanforderungen von Ent-wicklungssystemen ausgewirkt, für deren Erfüllung es heute mehr denn je eines ganzen„Dorfes“ an Software bedarf.

Die Entwicklungssoftware von heute lässt sich im Großen und Ganzen in zwei Bereicheeinteilen: Auf der einen Seite steht die Spezialisierung, d.h. Software, die für eine ganzbestimmte Aufgabe oder Hardware entwickelt wurde. Auf der anderen Seite findet sich diesogenannte Abstraktion, wobei ein ursprünglich komplexes Konzept schematisch verein-facht wird, damit sich bestimmte Aufgaben schneller lösen lassen. Allerdings bleiben dabeidetaillierte Informationen zur zugrundeliegenden Funktionsweise verborgen, sodass keineLow-Level-Steuerung möglich ist. Jeder Anbieter, der behauptet, beide Bereiche mit einereinzigen Software abdecken zu können, ist entweder naiv oder hat schlichtweg keineAhnung – beides keine guten Voraussetzungen. Unabhängig davon, ob die Entscheidungnun auf Spezialisierung oder Abstraktion fällt, Anbieter müssen die Interoperabilität ihrerWerkzeuge gewährleisten, denn ansonsten lastet der Integrationsaufwand allein auf denSchultern des Anwenders.

Abstract“It takes a village.” While this African proverb generally refers to the need for an influen-tial infrastructure beyond the immediate family for the healthy development of a child, youmight be surprised to learn that this same concept can be extended to the engineeringworld. The pace and promise of a connected world have rapidly escalated the demands onthe design and test of engineering systems, and now, more than ever, it takes a village – avillage of software. Today’s engineering software has typically evolved along two diverg-ing paths. Along one path, you will find specialization – software designed for a specifictask or type of hardware. Along the other path, you will find abstraction – a simplifiedinterface to a once complex concept that makes it easier to accomplish the task faster, butat the price of removing low-level control. Any vendor that claims to solve these chal-lenges with a single software is either confused or naïve. I am not sure which one is worse,but know that whichever path you choose, you must demand interoperability or risk bear-ing the burden of integration yourself.

Jeffrey Phillips

170

Embe

dded

Des

ign

Aus Erfahrungen lernenWie die Erfahrung immer wieder zeigt, ist das Zusammenführen unterschiedlicher Soft-warewerkzeuge von konkurrierenden Anbietern mühselig und teuer, wobei die eigentlicheMammutaufgabe darin besteht, die Interoperabilität zu gewährleisten. Dabei lässt sich dieseam einfachsten erreichen, wenn die verschiedenen Werkzeuge mit ein und derselben Platt-form erstellt und anschließend um ein dynamisches Ökosystem erweitert werden, welchesanwendungsbezogenes IP (intellectual property, geistiges Eigentum) und spezialisierteFunktionen bereitstellt. Dieses Konzept lässt sich am besten am Beispiel des Betriebssys-tems verdeutlichen.

Bereits vor Jahrzehnten zeigte Microsoft mit Windows die Vorteile einer einheitlichenPlattform, die auf standardisierten Kommunikationsprotokollen und einer gemeinsamenInfrastruktur – dem PC – basierte. Das Ergebnis war eine gemeinsame Oberfläche, die ein-fach erweitert werden konnte, wodurch sich die Hardwareplattform des PCs wesentlich effi-zienter nutzen ließ. Im Laufe der Zeit löste der Universal-PC, ausgestattet mit individuellerSoftware, immer mehr Punktlösungen, wie z.B. Registrierkassen, ab. Wenn man so will, hatApple das Plattformkonzept mit seinem Betriebssystem iOS auf die nächste Stufe gehoben.Denn das, was das iOS so erfolgreich machte, ist sein robustes Ökosystem, das auf der Stan-dardinfrastruktur aufsetzt.

Um eine maximale Interoperabilität zu gewährleisten und Entwurfsprozesse so effizient wiemöglich zu gestalten, muss Software von Anfang an richtig und mit Blick auf die Anwen-deranforderungen konzipiert werden. Aus diesem Grund macht NI sich die Vorteile des PC-Betriebssystems zunutze und überträgt sie auf seine Entwicklungssoftware.

Der Nutzen eines EntwicklungsbetriebssystemsObwohl es sich bei den oben genannten Beispielen um kommerzielle Betriebssysteme han-delt, lässt sich dennoch eine Analogie zu Entwurf und Test von Entwicklungssystemen her-stellen. Denn genau wie ein kommerzielles Betriebssystem die Interaktion zwischenAnwender und PC vereinfacht, dient auch das Entwicklungsbetriebssystem als Soft-wareplattform, mit der sich die Interaktion zwischen Anwender und dem in der Entwick-lung befindlichen System standardisieren und vereinfachen lässt.

Ein echtes Entwicklungsbetriebssystem ist eine Sammlung technischer Komponenten oderGrundbausteine, mit denen sich Softwareprodukte für unterschiedliche Problemstellungenentwickeln lassen. Diese Grundbausteine sind in der einen oder anderen Form in nahezujeder Entwicklungssoftware zu finden und zwar als Benutzeroberflächenelemente zurVisualisierung von Daten, IP für die Signalverarbeitung, Compiler-Architekturen zur Opti-mierung von Programmcode für unterschiedliche Prozessoren sowie Sprachstrukturen,Treiber-APIs und Bereitstellungsarchitekturen. Jedoch kommt es darauf an, wie diese Bau-steine miteinander kombiniert werden. Denn daraus ergibt sich erst, wie produktiv und effi-zient Aufgaben gelöst werden können. Für eine High-Level-Architektur zur Testablaufsteu-erung müssen diese Bausteine nicht nur völlig anders miteinander kombiniert werden alsfür eine interaktive Hardware- oder Datenerfassungskonfiguration, auch die Abläufe, Skins,IP und das Interaktionsdesign unterscheiden sich voneinander.

Der wahre Nutzen eines Entwicklungsbetriebssystems liegt im ganzheitlichen Konzept dieserSoftwarewerkzeuge. Denn so lassen sich mit einer einzigen Plattform hochspezialisierte Pro-dukte wie Hardwaretreiber oder Software für die Bereitstellung und Verteilung von Systemenerstellen, genauso wie konfigurationsbasierte High-Level-Systeme zur Testablaufsteuerung,Cloud-basierte Analyseschnittstellen und sofort einsatzbereite Online-Zustandsüberwa-

Warum Entwickler eine Softwareplattform mit einem robusten Ökosystem benötigen

171

Embedded Design

chungsprogramme. Außerdem stehen hochgradig benutzerspezifische Entwicklungsumge-bungen zur Verfügung, die sowohl eine produktivitätssteigernde grafische Programmierungals auch eine ANSI-C-Programmierung erlauben. Dabei sind alle für die Anwendungsent-wicklung benötigten Komponenten und Funktionen von Grund auf für eine einfacheZugänglichkeit und nahtlose Integration konzipiert. Und da die einzelnen Komponenten allemit derselben Plattform erstellt wurden, ergeben sich für Anwender direkte und indirekteVorteile.

Bild 1: Vergleich eines kommerziellen Betriebssystems mit einem Entwicklungsbetriebssystem

Jeffrey Phillips

172

Embe

dded

Des

ign

Bild 2: NI TestStand und NI Measure

Schnellere EinarbeitungIm Softwarebereich ist heute ein klarer Trend zu beobachten: Anwender wollen immer leis-tungsstärkere Software, die gleichzeitig einen leichteren Einstieg und mehr Bedienfreund-lichkeit ermöglicht. Ein plattformbasierter Ansatz, wenn er denn richtig umgesetzt wird,bietet hier den Vorteil einer einfacheren und kürzeren Einarbeitung. Denn da die gemeinsa-men Funktionen auf denselben Grundbausteinen basieren, müssen Anwender sich nur ein-mal mit diesen Elementen vertraut machen, wenn sie mehrere Softwarewerkzeuge in einemSystem kombinieren, da das Interaktionsprinzip plattformübergreifend gleich ist. Darüberhinaus lassen sich diese Grundbausteine während des Entwurfsprozesses an die jeweiligeAufgabe anpassen, sodass eine individuell zugeschnitte Lösung entsteht.

InteroperabilitätAufgrund der zunehmenden Komplexität heutiger Lösungen müssen immer häufiger ver-schiedene Softwaresprachen sowie Entwicklungsumgebungen und -ansätze miteinanderkombiniert werden. Dabei fallen nicht unerhebliche Integrationskosten an, die künftig nochweiter steigen werden. Der plattformbasierte Ansatz sorgt hier in vielfacher Weise für einevereinfachte Integration und damit eine verbesserte Interoperabilität. Da alle Produkte das-selbe integrierte IP und dieselben APIs nutzen, lässt sich Programmcode in hohem Maßewiederverwenden, ohne dass dieser umgeschrieben oder umgestaltet werden muss. Diessorgt sowohl auf Unternehmens- als auch auf Einzelnutzerebene für erhebliche Kostenein-sparungen bei der Integration. Zudem ermöglicht der Plattformansatz die Verbindung vonSpezialisierung und Abstraktion. Denn zunächst kann mithilfe der Plattform eine hochspe-zialisierte Software für eine bestimmte Aufgabe entwickelt werden, sei es für die Datenpro-tokollierung, Offline-Datenkorrelation und -analyse oder auch Testablaufsteuerung, diesich dann um ein Werkzeug mit höherem Abstraktionsgrad erweitern bzw. in dieses integ-rieren lässt. So steht Anwendern für jeden Aspekt ihres Projekts genau das passende Werk-zeug zur Verfügung, ohne dass ein nennenswerter Integrationsaufwand samt Kostenanfällt.

ÖkosystemFür jede erfolgreiche Software gilt: Ohne das entsprechende Ökosystem würde sie baldwieder von der Bildfläche verschwinden, denn keine wirklich erfolgreiche, professionelleSoftware kann isoliert existieren. Ein Ökosystem ist nicht nur hinsichtlich der Support-

Warum Entwickler eine Softwareplattform mit einem robusten Ökosystem benötigen

173

Embedded Design

möglichkeiten und Beispielcodeerstellung von unschätzbarem Wert, sondern auch was dasNetworking und Weiterempfehlungen betrifft. Der wichtigste Aspekt ist jedoch die Erweite-rung der Plattform um hochspezialisiertes IP, das vom Plattformanbieter selbst nicht bereit-gestellt werden kann. Ein gutes Beispiel ist hier der App Store von Apple. Die Entwicklervon Apple sind keine Experten in den Bereichen Fitness oder Wettervorhersagen. Sie stellenjedoch die grundlegende Plattform bereit, die vom Ökosystem stetig um neue und speziali-sierte Funktionen, in diesem Fall Apps, erweitert wird.

Der plattformbasierte Entwicklungsansatz begünstigt nicht nur Erweiterungen durch dasÖkosystem, er bietet auch eine vereinfachte Schnittstelle für die Integration weiterer Tech-nologien. Das Grundprinzip der Plattform besteht darin, dass die einzelnen Kernfunktionenund -bestandteile als wiederverwendbare Einheiten konzipiert sind. Das bedeutet, dass siein verschiedenen Produkten eingesetzt und für spezifische Anforderungen weiterbearbeitetwerden können. Dies lässt sich aber nur effektiv realisieren, wenn die Kernfunktionen auferweiterbaren APIs basieren, die es Entwicklungsteams ermöglichen, Funktionen auszu-bauen und anzupassen. Dank dieser APIs ist das Ökosystem in der Lage, Funktionen bereit-zustellen, die genau auf die jeweiligen Anforderungen von Anwendungen, Unternehmenoder Kunden zugeschnitten sind.

Realisierung eines EntwicklungsbetriebssystemsNI hat im August 2016 auf dem jährlich stattfindenden Anwenderkongress NIWeek erst-mals sein neues NI Software Technology Preview Program vorgestellt, das Kunden einenfrühzeitigen Einblick in zukünftige NI-Technologien und -Funktionen bietet. Damit unter-streicht das Unternehmen sein mittlerweile mehr als 30-jähriges Engagement für den tech-nologischen Fortschritt im Mess- und Automatisierungsmarkt. Das Programm stellt anhandverschiedener Software-Builds neue Funktionen vor, die sich derzeit in der Entwicklungbefinden und auf die Lösung unterschiedlicher Problemstellungen ausgerichtet sind, u.a.:

• Entwicklung benutzerspezifischer Oberflächen für Desktop und Web• Steuerung, Visualisierung und Dokumentierung von Systemen• Entwicklung von Multimedia-Lernprogrammen innerhalb von Produkten• Datenanalysen und -verwaltung auf dem Desktop und Server• Programmierung mit konfigurationsbasierter Software

Diese Problemstellungen ziehen sich durch viele unterschiedliche Branchen und könnenmithilfe verschiedener Produkte individuell gelöst werden. Auch hier bietet der plattform-basierte Ansatz unschlagbare Vorteile, da alle im Rahmen des Software Technology Previewvorgestellten Funktionen und Technologien einfach und nahtlos in die Softwareprodukteder NI-Plattform integriert werden können.

Das Software Technology Preview Program richtet den Blick zwar auf zukünftige Entwick-lungen und Software-Releases, allerdings gibt es bereits heute Lösungen, die von den Vor-teilen einer gemeinsamen Plattform profitieren. Ein Beispiel ist VeriStand 2016, eine High-Level-Softwareumgebung für Echtzeitprüfanwendungen, mit der sich einfach zu integrie-rende grafische Benutzeroberflächen erstellen lassen. Und natürlich die Systemdesignsoft-ware LabVIEW 2016, die dieses Jahr ihr 30-jähriges Jubiläum seit der Markteinführung vonLabVIEW 1.0 für Macintosh Plus feiert und mit einem innovativen Kommunikationsproto-koll aufwartet, mit dem sich Daten zwischen parallelen Programmabschnitten über eineeinzelne Kanalverbindung übertragen lassen.

Jeffrey Phillips

174

Embe

dded

Des

ign

Bild 3: VeriStand UI Manager und LabVIEW 2016

ZusammenfassungMan muss es ganz klar sagen: Eine effektive Softwareplattform zu entwickeln, ist keineleichte Aufgabe. Aber genau das ist der Anspruch, den Softwarehersteller heute erfüllenmüssen, denn nur so lassen sich die zunehmend komplexer werdenden Herausforderungenbewältigen, denen Kunden gegenüberstehen. Unternehmen, die ihre wertvolle Zeit undEnergie immer noch mit Einzelpunktlösungen und den damit verbundenen Integrationspro-blemen verschwenden, anstatt die eigentlichen Aufgaben zu lösen, sollten daher einenplattformbasierten Ansatz in Erwägung ziehen. Denn mit einer Plattform, die über einrobustes Ökosystem verfügt und zu jeder Zeit die passenden Werkzeuge bereitstellt, sindAnwender sowohl für heutige Herausforderungen als auch für die Anforderungen zukünfti-ger Technologien bestens gerüstet.