Zuletzt aktualisiert: 05.12.2016
Aquaristik
Modellbau
Software
3D-Druck
Garten
Sonstiges
Kontakt
Impressum

Programmierung und Echtzeit

In folgendem Artikel möchte ich diverse Leser verschiedener Fachrichtungen auf einen Nenner bringen und ihnen verdeutlichen, wieviel die Fachrichtungen mit den anderen zu tun haben.
Hierbei geht es sowhol um die unterschiedlichen Fakultäten als auch um die Entwicklungen der Programmierung und Software aus Richtung verschiedener Computer- und Rechnersysteme.

Dass sich mittlerweile das Feld der Mathematik über die Informatik hin zur Mechatronik vereint hat, ist auch den mittlerweile Älteren in diesem Fachgebiert bewusst geworden. Die Physik am Ende des Strangs in Richtung Elektrotechnik und die Mathematik am Ende des Strangs in Richtung der Arithmetik bilden heutzutage die Endpfeiler für diverse Softwareentwicklungen. Doch auch die Physik kann ohne die Mathematik nicht leben, die Mathematik könnte ohne tatsächliche Anwendungsgebiete im alltäglichen Leben nur als Religion bezeichnet werden und wäre ohne wirkliche Anwendungen nutzlos. Die Anwendungsgebiete an sich verschwimmen immer mehr.

Dieses Verschwimmen zeichnet sich auch in der Art der Programmierung auf verschiedenen Zielsystemen ab.

Stand-alone-Anwendungen:
Hiermit hat quasi alles angefangen, immer länger werdende Befehlsketten wurden zusammengebaut und sollten auf einem einzelnen Computer bestimmte stupide Aufgaben sequentiell abarbeiten, um nicht länger Menschen als Arbeitskräfte die Nerven zu rauben und Flüchtigkeitsfehler zu vermeiden. Zwei Rechner nebeneinander mit diesem Stand-alone-Programm verdoppelten die Leistung.

Betriebssysteme:
Nun hatte man das Problem, dass man viele Stand-alone-Anwendungen hatte, die aber teilweise auf den selben Funktionen basierten. Auch kamen immer mehr Hersteller von Endgeräten ins Spiel. Hier begann man, die Funktionalität der Anwendung und die Funktionalität der Endgeräte zu trennen und kapselte es in einem sogenannten Betriebssystem. Man musste sich keine Gedanken mehr um die Darstellung von Text auf einem Bildschirm machen, indem man die Pixel einzeln einfärbte. Auch Drucker, Speicher und diverse andere Geräte konnte man über definierte APIs (Application Programming Interface) ansprechen, ohne sich über deren Problemstellungen und Verhalten Gedanken zu machen. Man konnte noch schneller diverse Programme entwickeln, das Betriebssystem übernahm standardisierte Abläufe und Funktionen.

Multitasking:
Jetzt hatte man es schon geschafft, viele Menschen durch Software einzusparen, doch man wollte mehr. Während man 20 Seiten auf dem Drucken drucken lassen wollte, wollte man schon anfangen, die nächste Seite zu tippen. Man hätte es so lösen können, dass man dies dem Drucker überläßt, ihm die 20 Seiten Daten sendet und er sich um das Drucken kümmert. Allerdings hätte dann der Hersteller des Druckers das Problem gehabt, den Druckauftrag über 20 Seiten auf dem Drucker speichern zu müssen, ggf. auch für 2000 Seiten. Der Aufwand wäre enorm. Der Hersteller des Druckers hat diese Aufgabe abgelehnt und dem Betriebssystem auferlegt.
Hätte man hier keine Lösung gefunden, müßte der Mitarbeiter bei jedem Ausdrucken warten. Doch der Hersteller von Betriebssystemen hat eine Lösung gefunden in Form des Multitaskings.
Hierzu wird das Programm zum Tippen der Seiten kurz unterbrochen, alle Daten im Speicher gesichert, und kurz zum Programm des Ausdruckens umgeschaltet, es wird kurz gedruckt, dann aber wieder zum Programm zum Tippen zurückgesprungen und dem Benutzer ermöglicht, weiter zu Tippen. Diese Wechsel gehen so schnell, dass man den Eindruck hat, dass beide Programme irgendwie gleichzeitig ablaufen. Diesen Wechsel ermöglicht uns ein Betriebssystem, der Entwickler des Stand-alone-Programms bekommt davon gar nichts mit, er geht fest davon aus, ein sequentielles Programm entwickelt zu haben. Praktisch sieht das anders aus, man kann etliche Programme parallel starten, alle laufen quasi gleichzeitig, jedes bei genauerem Hinsehen immer nur ein winzig kleines Stückchen. Beim Drucken wurden früher häppchenweise neue Daten gesendet, heutzutage hat man aufgrund des Speicherüberflusses teilweise doch den zuerst abgelehnten Weg eingeschlagen und speichert sich die 2000 Seiten Daten auf dem Drucker.

Webapplikationen und Client-Serveranwendungen:
Wenn man etwas abschweift, ist es bei dieser Art von Anwendungen ähnlich wie bei den Stand-alone-Anwendungen. Webbapplikationen sind zwar etwas komplizierter, weil man auf einmal zwei aktuelle Programmteile hat, die sich gegenseitig beeinflussen und man als Entwickler wissen muss, wann man sich wo im Code befindet. Verfielfacht man dies auf parallel laufende Programme, so hat man denselben Effekt wie beim Betriebssystem, dass alle gleichzeitig laufen, viele Nutzer melden sich gleichzeitig an und es laufen unterschiedliche Programme. Darunter liegt auch wieder ein Betriebssystem.

Multithreading:
Den Effekt, mehrere Programme parallel laufen zu haben, wollten auch die Entwickler in ihren Programmen nutzen, nicht nur, wenn das Betriebssystem es wollte. So hat man es durch das Multithreading ermöglicht, mit der ähnlichen Funktionsweise wie beim Multitasking, je nach Programmiersprache mehr oder weniger kompliziert. Von diesem Trend ist man jedoch mehr oder weniger wieder abgekommen, außer man hat Software, wo solch ein Anwendungsfall ganz offensichtlich ist. Man ist davon abgekommen, weil das Betriebssystem selbst und die verwendete API zu eigenen Threads neigt und man zu ereignisorientierten Entwicklungen überging. Man wartet dabei im Stand-alone-Programm auf ein Ereignis des Benutzers, jedoch nicht dadurch, dass man in einer Schleife auf eine Eingabe wartet. Stattdessen wartet man dadurch, dass man von der API ein Event bekommt und darauf reagiert. Somit überwacht im Hintergrund wieder das Betriebssystem den Benutzer, somit kann auch dort noch mehr Parallelisierung stattfinden und das eigens implementierte Konstrukt wird eher überflüssig.

Nun haben wir die Informatiker und Mathematiker komplett abgdeckt, andere Neuerungen kann man in diesem Bereich leider nicht vorweisen, denn sie lassen sich alle auf diese Teile abstrahieren. Egal ob Handy-"Apps", Datenbankserver oder Cloud-Anwendungen, im Grunde bestehen alle aus Stand-alone-Anwendungen, Webapplikationen oder einem Mischkonstrukt. Alle beteiligten Rechner tragen ein Programm in sich, darunter ein Betriebssystem.

Die Elektriker, Elektroniker und Entwickler von Mikrocontrollern oder Entwicklern aus der Automatisierungstechnik sind froh, wenn sie mit dieser Welt der Informatik nicht viel zu tun haben, fühlen sich aber übergangen, wenn sie die Entwicklungen der Informatik vorgehalten bekommen ohne ihre eigenen Entwicklungen präsentiert zu bekommen.
Hier kommt man jedoch ebenfalls aus der Richtung, Arbeitszeit und Arbeitskräfte einzusparen. Ein kleiner Baustein sollte eine UND-Verknüpfung und eine ODER-Verknüpfung leisten, indem man einfach einen Schalter umlegt, dann wurde es immer aufwendiger, ganze logische Verknüpfungsnetze sollten programmierbar sein, um Maschinenabläufe so abzubilden.
Sehr viel Elektronik und Standardisierung war nötig, und viele Vorbilder aus der Informatik, irgendwann sollte es auch egal sein, ob man einen Schritt- Gleichstrom, Asynchron- oder Synchronmotor anschließt, eine standardisierte API sollte leisten, dass der Entwickler einer Maschine um ein Endgerät namens Motor keinen Kopf mehr machen muss.
Zugegeben, dieser Weg ist in der Maschinenbranche weit gewesen und ist längst noch nicht zuende, doch bereits jetzt steht die Consumerbranche vor der Tür, und sie klopft bereits immer heftiger daran, es wird erwartet, dass ganze Maschinen mit "Apps und Co" funktionieren. Dies ist ein Problem, denn die Software aus dieser Branche ist noch gar nicht dafür vorbereitet. Um die beiden Welten trotzdem zueinander zu bringen hat man sich Schlagworte wie Industrie 4.0 einfallen lassen.

Nun stecken wir in einem Dilemma, denn die Welten aus Consumer-Elektronik, Webapplikationen, Cloud-Computing und "Apps" treffen auf eine Welt aus bitorientierten Statusworten, Programmabläufen, Motoransteuerungen und Schaltkreisen.

Das Ganze könnte man jetzt abwertend oder aufwertend interpretieren, je nachdem aus welcher Richtung der Leser kommt, doch man kann die beiden Richtungen auch anders sehen:
  • Die Informatik wird es ohne Elektronik nicht schaffen, einen Motor vernünftig anzusteuern. Man hat sich massiv auf Multitasking spezialisiert, verläßt sich aber durch die Gerätehersteller darauf, dass die Signale in irgendeiner Form verarbeitet werden und irgendwann zu einem positiven oder negativen Ergebnis des zweiten Tasks kommen, nämlich ausgedruckte Seite oder Papierstau.
  • Die Elektroniker und Automatisierungtechniker wollen Maschinen entwickeln, werden jedoch dazu gedrängt, ihre eigenen Lösungswege über den Haufen zu werfen, und durch Lösungen aus Consumer-Elektronik und Multitasking zu ersetzen.

Niemand weiß, wer das Match zuerst eröffnet hat oder was dazu geführt hat, die beiden Welten aufeinander zu hetzen, doch es ist eröffnet. Keiner der beiden hat den kompletten Überblick über beide Welten, sie müssen zusammenfinden, man kann sich jedoch nur über Gemeinsamkeiten zusammenschließen und darüber eine Vereinigung erzielen.

Über welche Gemeinsamkeit man beide Welten zusammenführen kann, ist im Artikel "Echtzeitprogrammierung und Multitasking" beschrieben.
Copyright © 2016 Evolutec Alle Rechte vorbehalten.