08.08.1993 / 1995 / 1997 / 2001
Mit immer komplexer werdenden Maschinen wurde rasch der Ruf nach einfacherer Erstellung, flexiblerer Einstellung und leichterer Modifizierbarkeit laut. Die bis dato auschließlich benutzten mechanischen (z.B. Nockenwelle) und elektropneumatischen (z.B. fest verdrahtete Relais) Steuerungen waren hierzu nicht geeignet.
Eine Lösungsmöglichkeit kam ab 1970 aus der EDV, die je nach eingegebenen Programm verschiedene Funktionen auf der gleichen Hardware ausführen konnte.
Die erste eingesetzte "programmierbare" Steuerung war eine Ansammlung von Relais, deren Verbindungen untereinander von einer Relaiseingangsschaltung geschaltet werden konnte, die wiederum von den Löchern einer Lochkarte ein- und ausgeschaltet wurden.
Im Zuge der Weiterentwicklung der Elektronik wurden dann µController eingesetzt, die erstmal das Prädikat "programmierbare Steuerung" verdienten. Hieraus entwickelten sich im Zuge einer Spezialisierung die heute bekannten PLCs (auch SPS genannt).
Das Universalwerkzeug Computer entwickelte sich parallel weiter (GroßEDV, Notebooks, PersonalComputer). Es wurden auch immer wieder komplexe Steuerungsaufgaben computergesteuert realisiert, für die eine Lösung mit den spezialisierten PLC-Steuerungen nicht möglich, zu aufwendig oder zu teuer gewesen wäre. Der Hauptschwachpunkt hierbei war die mangelnde elektrotechnische Stabilität.
Mit der Einführung der Feldbussysteme, bei denen dezentrale intelligente Einheiten mit einem zentralen Anschlußkabel verbunden sind, änderten sich die Einsatzmöglichkeiten einer universellen Steuerung dramatisch. Nun mußte die Steuerung nicht mehr zwingenderweise mit der Maschine verbunden sein, und damit den mechanischen und elektrischen Bedingungen dieser Maschine genügen, sondern konnte entfernt in einer Warte stehen. Die damit geänderten Umgebungsbedingungen ermöglichten den Einsatz von preisgünstigen und universellen Komponenten.
Ohne meinen Kollegen aus dem mechanischen Bereich weh tun zu wollen, ist eine komplexe Verarbeitungsmaschine über Ihren gesamten Lebenszyklus von ca. 10 Jahren hin gesehen (Konzept, Planung, Konstruktion, Aufbau, Inbetriebnahme, Kundeninstallation, Produktion, Wartung, Update und Adaption, Reparatur, Recycling) in erheblichen Maß von Software abhängig.
Keiner kann nach einer bestimmten Zeit sagen, ob der damals zugekaufte Funktionsbaustein in einer zu ersetzenden PLC noch funktioniert, ob das aktuelle CAD- System die alten Daten lesen kann oder ob der Hersteller der verwendeten Visualisierung überhaupt noch existiert.
Mein ältestes, noch zu wartendes Projekt, stammt aus dem Jahr 1981 und daraus die Schlußfolgerungen:
Texte und Daten sind in einem langfristig lesbaren Format wie ASCII/ANSI (fließtext- oder tabellenorientiert), Bilder in einer rasterorientierten Format zu speichern. Die hierfür notwendigen Algorithmen sind Allgemeingut und müssen Bestandteil der Standardsoftware sein.
Zeichnungen, Bilder, Texte, Datenbanken und SourceCode auf neue "Standard"- Software anzupassen ist hierbei möglich, die Anpassung der neuen Software an damals benutzte Formate jedoch nicht.
Für die Elektronik heißt dieses, daß alle notwendigen Algorithmen und Hardwaredriver im SourceCode einer langfristig unterstützten Programmiersprache vorhanden sein müßen. Die Anpassung an neue Elektronik und neue Interfaces ist deutlich einfacher, als entsprechende Hardware von vor 10 Jahren zu bekommen.
Kennt noch einer die non-plus-ultra Programmiersprache ADA aus dem Jahr 1990, die hervorragende Datenbank BTRIEVE, das ehemalige TP1-Protokoll, das Wordstar Fileformat oder das Bildformat EXP? Wer ist heute noch in der Lage, alle bisherigen Versionen der Microsoft "Standardformate" *.DOC und *.XLS fehlerfrei zu lesen und zu schreiben?
Ein Hochsprachencompiler ist damit während des kompletten Lebenszykluses das am meisten benutzte Werkzeug, und das nicht nur zur üblichen Programmpflege der Eingabeprogramme, sondern auch zur Umrechnung und Anpassung der Daten an neue Visualisierungen, Datenbanken, CAD-Systeme, Elektronikteile, etc.
Meine Wahl ist recht frühzeitig auf die Programmsprache "C" und deren Weiterentwicklung C++ gefallen. Obwohl ich mit Nostradamus nicht verwandt bin, hat sich diese Wahl bewährt und scheint sich auch in Zukunft zu bewähren.
Mein Konzept ist nun, diesem Hauptwerkzeug C-Compiler auch weitere, bisher unübliche Aufgaben zu übergeben, und damit den Großteil der Arbeit für eine komplexe Verarbeitungsmaschine in einem Werkzeug zu integrieren.
Beim Nutzen der Vorteile dieses Verfahrens lassen sich sowohl Entwicklung als auch Wartung deutlich einfacher realisieren und werden in ihrem Zusammenhang deutlich überschaubarer.
Das Prinzipschema demonstriert die Möglichkeiten der verschiedenen Abhängigkeiten einer unverketteten Verarbeitungstation:
Je nach zu realisierender komplexer Verarbeitungsmaschine können diese Abhängigkeiten einfach, mehrfach oder verknüpft auftreten. Bei der Verkettung mehrerer komplexer Verarbeitungsmaschinen sind diese zuerst einzeln zu betrachten und dann über Bridgefunktionen zu koppeln.
BDE Betriebsdatenerfassung CTR Controlling DAQ Data Aquisition / Datenerfassung DBMS Datenmangementsystem / Datenbank DFÜ Datenfernübertragung (email, internet, fax, bulletinboard, brief) EKF Materialeinkauf FS Fileserver / Netzwerk VIS Gesamtvisualisierung / Auswertung / ISO900x WFM Workflowmanager MWU MainWorkunit MAU MaterialAdaptionUnit / Materialveredelung OUT Ausgangslogistik
Aus Übersichtlichkeitsgründen wurde darauf verzichtet, die Verbindungen der einzelnen Controlunits zueinander und / oder zu einer zentralen Datenablage bzw. Fileserver zu zeichnen.
Auffällig bei komplexen Verarbeitungsmaschinen ist die hohe Anzahl der zu implementierenden Interfaces/Schnittstellen zwischen den einzelnen Komponenten.
Jeder, der schon einmal eine Schnittstelle entwickelt hat (möglichst noch mit den Vorgaben "dynamisch anpassbar" und "zukunftssicher"), wird mir zustimmen, daß dieses ein recht lustiges Unterfangen ist. Das Karrussel der "Standardinterfaces" wie OLE, OPC, IPX, TCP/IP, ModBus, ODBC, DAQ und wie sie alle heißen, dreht sich immer schneller. Kaum ein Monat vergeht, indem nicht irgendwelche Normierungsinstitute oder Hersteller, Erweiterungen und neue "Standards" präsentieren.
In einer komplexen Verarbeitungsmaschine eine ganze Reihe verschiedenster Interfaces über Jahre hinweg zu pflegen, bedingt einen fast nicht mehr handzuhabenden Aufwand. Besonders viel Spaß macht dann die Fehlersuche, wenn ein Bit nach Passieren dreier verschiedener Schnittstellen, aber nur eine davon ist geändert worden, plötzlich einen anderen Wert hat, wobei die Änderung gar nichts damit zu tun hat.
Sieht man sich dann auch noch das dynamische Laufzeitverhalten an (bestes Beispiel hier ist OPC), dann sollte man vielleicht doch auch andere Lösungsmöglichkeiten überdenken.
Ich bin für einen monolithischen Aufbau. Der Hochsprachencompiler kann dann bei einem neuen Compilerlauf veränderte Interfaces automatisch erkennen und entsprechend systemweit anpassen.
Im klassischen Maschinenbau werden die "Elektrofuzzis" nicht gut von den "Mechanikheinis" angesehen. Das muß historische Gründe haben, weil es bei fast allen mir bekannten Firmen mehr oder weniger ausgeprägt ist, ein Ursprung ist mir jedoch nicht bekannt.
Als Selbstschutz der Elektriker wird daher die mystische Ablaufsteuerung häufig überbewertet. Absolutstabilität, Echtzeitverhalten, ständige Verfügbarkeit sind hier die Schlagworte. Inwieweit die Praxis hier der Theorie entspricht, läßt sich durch die Erfahrungswerte der Software- und Wartungskosten gängiger PLCs leicht beurteilen.
Legt man die in diesem Aufsatz angesprochenen Punkte zu Grunde, stellt man fest, daß:
Zur effizienten Inbetriebnahme und Adaption von Maschinen muß die Ablaufsteuerung allerdings "online" ohne jeglichen Compilerlauf, Maschinenupdate oder Datenübertragung programmierbar sein.
Ca. 1983 stieß ich auf einen Artikel in einem Computermagazin (wahrscheinlich Schneider CPC) über eine tabellengetriebene Heizungssteuerung unter CPM. Diese Idee, sowohl Parameter als auch Programm online verändern zu können, faszinierte mich.
Eine erste Implementation zur tabellengetriebenen Berechnung von komplexen mathematischen Formeln auf einem Sharp PC war während meines Studiums recht erfolgreich.
Die erste komplexe Maschinenrealisierung hiermit waren 1989 die LOS Buchbindereimaschinen, wobei hier die Ablauftabellen aus Geschwindigkeits- und Speicherplatzgründen im C-Source-Code implementiert waren. Hiermit konnte man die Ablaufsteuerung recht leicht erstellen, allerdings nicht online ändern, da dann ein Compilerlauf notwendig war.
1995 erarbeitete ich nach einem erweiterten Konzept von Hr. Obrecht, iAR GmbH, die erste online veränderbare Maschinensteuerung, bei der sowohl Programme als auch Parameter und Daten während des Processes beliebig anpassbar sind. Dieses Produkt wird laufend weiterentwickelt und ist als MPC Solution auch heute noch die flexibelste und schnellste Möglichkeit einer reinen Maschinensteuerung.
Im Rahmen meines Ingenieurbüros habe ich ab 1995 mehrere kleinere Projekte realisiert, die alle software- und berechnungsdominierend waren. Da hier der jeweilige Hochsprachencompiler (C++, Java, TurboPascal) das hauptsächlich eingesetzte Werkzeug war, wurde die Ablaufsteuerung als SourceCode mit eingebunden. Da alle diese Projekte objektorientiert waren und eine Datenbankanbindung benötigten, wurden auch die Tabellen der Ablaufsteuerung in einer Datenbank verwaltet und die einzelnen Elemente als Objekte implementiert.
Hiermit waren alle Elemente online durch Datenbankzugriffe modifizierbar, die Steuerungsengine ist als Source-Code-Bibliothek (und damit wie gefordert weitestgehend zukunftssicher) in das jeweilige Projekt einbindbar.
"Der menschliche Geist ist üblicherweise nicht in der Lage, hochkomplexe Zusammenhänge in ihrer Gesamtheit zu erfassen, vielmehr ist es eine Abhängigkeit zwischen Erreichtem, Ideen, Versuch und Irrtum."
Diese von mir zusammengefaßte Aussage des Naturwissenschafters Hoimar von Ditfurth läßt sich eindeutig auch in der komplexen Maschinenentwicklung nachweisen. Hinzu kommt, daß realisierte komplexe Systeme ein gewisses "Eigenleben" entwickeln, auf das weitere Realisierungen aufbauen.
Eine zufriedenstellende Realisierung eines neuen komplexen Systemes in Bezug auf Funktionalität, Resourceneinsatz und Entwicklungszeit per Pflichtenheft, Projektplanung und Managementbesprechungen ist mir persönlich nicht bekannt. Jeder Entwicklungsleiter kennt diese Problematik aus eigener leidvoller Erfahrung.
Meines Erachtens ist der beste Weg, neue komplexe Systeme zu entwicklen, das "Lego" System. Ähnlich den Teilen des Spielwarenherstellers Lego (auch für Erwachsene zur Steigerung der Kreativität immer wieder empfehlenswert), wird das neue System aus vorgefertigten Bauteilen zusammengestellt. Während des Prototypenaufbaus kann beliebig schnell auf notwendige Änderungen reagiert werden. Der entstandene Prototyp ist zwar etwas ungeschliffen, aber man kann damit "spielen" und weitere Verbesserungen einbauen. Entstandene Baugruppen können weitestgehend ohne Zerstörung getrennt, modifiziert und wieder zusammengebaut werden.
Jeder verwendete Lego-Baustein hat eine Funktion (Fenster, Gartenzaun, Rad, Drehkupplung) und ein Interface (Anzahl der Befestigungsknöpfe). Die Implementation ist allerdings fest vorgegeben, eine Änderung hierbei bedingt schon Gewalt (z.B. mit einer Säge).
Als Beispiel zur Umsetzung auf Maschinenelemente dient ein Pneumatikzylinder:
Ein Pneumatikzylinder hat ein mechanisches Interface (Befestigung, Druckluftanschluß). Zur Funktion wird ein Pneumatikschalter (Ventil) benötigt, der ebenfalls ein mechanisches, als auch ein elektrisches Interface hat. Zum selbstüberwachenden Betrieb gehören hierzu noch Stellungsschalter, seien es induktive Näherungs- oder Magnetschalter. Zur Einstellung können Pneumatikzylinder noch mit Druckminderern, Endlagendämpfung, Zuluft- und Abluftdrosseln ausgestattet sein.
Neben Teile-, Elektrik- und Pneumatikdokumentation und der elektrischen Ansteuerung (werden an anderen Stellen in diesem Aufsatz angesprochen) und des mechanischen Interfaces (ist Aufgabe der Mechanikkonstruktion und wird hier nicht behandelt), ist die Softwareansteuerung als Objektbeispiel prädestiniert.
Während in gängigen Ablaufsteuerungen die Befehle für das Schalten des Ventiles, die Überprüfungen der Stellungen und die Überwachungszeiten hierfür quer durch das Ablaufprogramm verteilt sind, ist es sinnvoll, diese an zentraler Stelle zusammen zufassen, nämlich im Objekt Zylinder.
Dieses Objekt hat als Parameter die Befehlssequenz zum Ein- und Ausschalten und die jeweiligen Stellungsmeldungen. Zusätzlich können hierbei zentral und damit einmalig, die jeweiligen Überwachungs- und Verzögerungszeiten angegeben werden.
Das Objektinterface hat im primitivsten Umfang die Befehle Ein / Aus und die Rückmeldungen IstEin / IstAus. Die aufrufende Software braucht sich um die Internas dieses Objektes nicht mehr zu kümmern (Objektkapselung). Es liefert einen Ein-Befehl und wartet auf die Rückmeldung. Das Objekt selbst überprüft, ob der Befehl korrekt abläuft (wenn in Aus steht, dann Ein, Aus-Stellungsmeldung muß gehen, Ein-Stellungsmeldung muß innerhalb einer bestimmten Zeit kommen, zusätzliche Verzögerungszeiten werden berücksichtigt, etc.).
Auftretende Fehler (Kabelbruch, Laufzeit, Mechanikfehler) werden somit zentral, selbstständig und kontinuierlich überwacht. Eine Fehlermeldung kommt nach einmaliger Einstellung der Objektparameter ohne weiteres Zutun des Programmierers und erleichtert sowohl Inbetriebnahme, Wartung als auch Fehlersuche.
Zusätzlich kann ein Objekt weitere erleichternde Funktionen bieten, wie z.B. kontinuierliche Bewegung des Zylinders zur einfachen Einstellung von Druckminderer und Drosseln, und dieses ohne zusätzlichen Aufwand des Ablaufprogrammieres.
Stufe 1: Maschinenbedienung
Der Maschinenbediener hat für den nicht automatisierten Materialfluß zu sorgen. Bei Produktionsmaschinen, an denen Bediener unter Zeitdruck arbeiten, steigen die Bedienerfehler etwa quadratisch zu der Anzahl der zu versorgenden Bedienelementen an.
Dieses ist auch nicht weiter verwunderlich und auch leicht nachvollziehbar, wenn man sich selbst mal das Vergnügen gönnt, sich dieser Dauerbelastung auszusetzen. Aus diesem Grunde sollen in dieser Stufe möglichst wenig Bedienelemente notwendig sein (z.B. 3 Lampen und 4 Taster).
Stufe 2: Ablaufprogrammierung + Wartungsdienst
Der Wartungstechniker mit ausreichend Kenntnis der Verfahrenstechnik muß hier die Funktionen finden, die ihm ermöglichen, Fehlersituationen einfach zu erkennen und zu beseitigen.
Auf der gleichen Ebene wird bei der Maschineninbetriebnahme die Ablaufsteuerung programmiert, so daß durch diese enge Verkettung, gleichzeitig Ablaufsteuerung und Wartungsdienstvisualisierung erzeugt werden können und damit aus einem Guß und auf dem gleichen Niveau sind.
Stufe 3: Maschinenberechnungen + Datenkopplung
Hier werden vom Entwicklungsingenieur die in der Stufe 2 benötigten Platzhaltervariablen (z.B. eine einzustellende Motorposition) durch Vorgabe von externen Daten, Maschinenparameter und verfahrenstechnischen Vorschriften berechnet und übergeben.
Stufe 4: Anwenderbedienung
Hier wird vom Applikationsingenieur eine dem kundenspezifischen System entsprechende fehlertolerante Benutzeroberfläche implementiert. Hierzu gehören z.B. vertriebsorientierte, ISO900x, Logistik, Systemintegration und Systemanalyse Anforderungen.
Die Dokumentation ist der natürliche Feind eines Ingenieurs. Jede "geniale" Realisierung muß dann nochmal mit verständlichen Worten an anderer Stelle beschrieben werden. Erstens ist Prosa mehr die Aufgabe anderer Berufsgruppen, zweitens werden Informationen an verschiedenen Stellen mehrfach erfaßt.
Diese "Mehrfachhaltung" von Informationen bedingt immer wieder Korrelationsprobleme (unterschiedliche Informationen), Updateprobleme (nur teilweise vorhande Informationen) und lästigen Mehraufwand (und damit gelegentlich gar nicht vorhandene Informationen).
Wenn zum Beispiel nach Aufbau einer Baugruppe feststeht, daß von einer Klemme X1 ein mindestens 6poliges, ölresistentes Kabel für 24V Signale zu einer Klemme X2 gelegt werden muß, so liegen hier der Kabeltyp, der Querschnitt und die Verbindungen fest. Bei konsequenten Einsatz von objektorientierten Standardelementen (z.B. Kabel nach DIN-Farbcode) kann diese Information tabellenbezogen in einer Datenbank verzeichnet werden.
Hieraus kann man ableiten, daß Pin 3 dieses Kabels das Signal "Schlitten vorne" führt und die Kabelfarbe gelb hat. Der zusätzliche Aufwand für den Ingenieur, neben der üblichen Eingabe der Signalbeschreibung auch Kabeltyp, Verbindung und Pinnummer einzugeben, ist minimal, aber damit ist diese Information eindeutig festgeschrieben. Muß er jedoch das ElektroCAD System starten und diese Information hier zeichnerisch festhalten, ist der Aufwand deutlich größer.
Kommt im Zuge der Entwicklung noch eine zusätzliche Baugruppe an dieser Klemme hinzu, ist die Dokumentationsaufgabe noch einfacher (nur Pinnummer und Referenzen auf vorhandene Kabeltypen und Verbindungen bzw. Klemmen). Im einem zusätzlich zu startendem CAD-System kann es sein, daß durch die zusätzlichen Pins Verschiebungen der bereits zu zeichnenden Elemente notwendig sind, evtl. sogar Elementumbenennungen. Das ist dann der Hauptgrund, warum solche Arbeiten "auf später" verschoben und gelegentlich dann auch "vergessen" werden.
Je kleiner die Stückzahlen, je wertvoller die Produkte und je komplexer der Maschinenanlauf, desto häufiger kommt die Diskussion über "intelligente" NotAus-Schalter auf.
Wenn "drüben" einer schreit, dann sucht man nicht den richtigen NotAus-Kreis 2a, sondern schlägt auf den Nächstgelegenen. D.h. alle erkennbaren NotAus-Schalter müssen im gleichen Kreis wirksam sein.
Ein NotAus mit vielleicht 20 verschiedenen Zwischenprodukten einer komplexen Verarbeitungsmaschine ist teuer. Die Entfernung dieser Zwischenprodukte, der Wiederanlauf und die erneute Produktion, ggf. vielleicht die Wiederherstellung teilweise produzierter, nicht mehr beschaffbarer Rohmaterialien, ist noch teuerer.
Übliche Sensoren werden vom NotAus-Kreis nicht betroffen, dieser Zustand ist konstant. Leider genügen fast alle gängigen Actoren mit ihren Enable, Inhibit oder Reseteingängen (Ventilsteuerungen, Servos) nicht den gesetzlichen NotAus- Bestimmungen.
Diese Actoren werden über ihre Enableeingänge im Moment des NotAus abgeschaltet (Reaktionszeit < 1ms), zusätzlich wird die Spannungsversorgung dieser Actoren mit abgeschaltet (Reaktionszeit ca. 20ms). Ab hier ist die Elektronik "safe", allerdings ist die Wiedereinschaltung mit einer neuen Synchronfahrt verbunden.
Eine weitere Möglichkeit besteht darin, die Actorenausgangskreise über zusätzliche, sicherheitsrelevante, Kontakte abzuschalten (z.B. einem Drehstrommotor die Phasen über einen, im Schutzkreis liegenden, Schütz wegzunehmen). Der hierbei entstehendene elektrische Aufwand ist gegen den erreichten Nutzen abzuwägen. Leider sind nicht alle Actorenausgangskreise unterbrechungssicher und intelligente Actoren erkennen dieses als seperat zu quittierendes Fehlersignal.
Bei komplexen Systemen wird aufgrund der hohen Funktionsdichte auch der Platz für die elektrischen und pneumatischen Verbindungen immer knapper, die Anzahl der in der Maschine zu verlegenden Leitungen wird immer größer.
Ziel der Verdrahtung ist, so bald als möglich an einen Feldbusknoten zu kommen, um die Leitungsanzahl zu reduzieren.
Zwischenklemmungen sind zu vermeiden, als Faustregel gilt: max 1 Klemmung pro Signal. Der Platz für Stecker ist meistens nicht vorhanden, aber meines Erachtens nach kann man von einem Elektriker verlangen, beim Austausch eines induktiven Näherungsschalters 3 verschiedenfarbige Adern wieder korrekt anzuklemmen.
Für wirklich notwendige Zwischenklemmungen müßen aus Platzgründen meist offene Klemmen ohne Klemmkasten genügen. Wenn man davon ausgeht, daß die Maschine im Betrieb geschlossen ist, was ja aufgrund des mechanischen Gefährdungspotentiales immer der Fall sein wird, ist laut EN und DIN nur ein Schutz gegen zufällige Berührungen vorzusehen (spricht IP21). Diese Schutzvorschrift ("Bitte vor Öffnen des Gehäuses den Netzstecker ziehen") wird hauptsächlich im Konsumerbereich (Fernsehen, Bohrmaschine) angewendet, im Maschinenbau ist dieses eher unüblich. Hinzu kommt, daß beim Öffnen der Maschinenabdeckungen meist noch ein NotAus ausgelöst wird, so daß diese Klemmen danach auch spannungsfrei sind.
Der Glaubenskrieg zwischen Schraubklemmen mit Aderendhülsen und Federkontakttechnik dürfte meines Erachtens nach bald vorbei sein. Aufgrund meiner persönlichen Erfahrungen setze ich mittlerweise ausschließlich das CAGE Clamp System von Wago ein.
Für komplexe Verarbeitungsmaschinen werden immer mehr Positioniersteuerungen notwendig, teilweise aus verfahrenstechnischen Gründen, teilweise zur Anpassung an immer kleiner werdenden Produktionsstückzahlen, teilweise auch zum leichteren mechanischen Aufbau.
Aufgrund des recht hohen Preises für gängige Servoantriebe, der hohen Anzahl von teilweise bis zu 30 gesteuerten Achsen und den von der Mechanik vorgegebenen Platzverhältnissen muß hier eine neue Lösung gesucht werden.
Bis zur Freigabe eines echtzeitfähigen und ausreichend schnellen (< 1ms) Bussystemes dürfen sicherheits- und zeitrelevante Funktionen nicht in zentralisierten Einheiten verwendet werden.
Es ist auch deutlich sinnvoller und leichter implementierbar, diese Funktionen auf spezialisierte und integrierbare Hardwareeinheiten zu vergeben. Als Beispiel sei hier eine Motorsteuerung genannt, die nach Vorgabe von Position, Geschwindigkeit und Beschleunigung selbst die jeweilige Rampensteuerung und den Regelmechanismus enthält.
Durch Implementation eines im Source-Code verfügbaren Drivers können hier alle Vorteile der aktuellen verfügbaren Hardware genutzt werden, gleichzeitig ist damit aber auch eine relative Systemunabhängigkeit zu den eingesetzten Komponenten gewährleistet.
Programmierqualifikation:
Wenngleich die Ablaufprogrammierung, wenn auch ungewohnt, deutlich erleichert wird, ist die Systemprogrammierung und -anpassung ein Abbild des zu erstellenden Systemes und bedingt daher einen erfahrenen Ingenieur mit entsprechender Kenntnis der verwendeten Verfahrenstechnik. Die fundierte Kenntnis der einzusetzenden Hochsprache muß vorausgesetzt werden.
Hardwareanpassung:
Da alle Hardwaredriver im Source-Code implementiert sein sollen, kommt neben den Vorteilen der hochdynamischen Ansteuerung und größtmöglicher Flexiblität der Nachteil hinzu, daß man sich seinen Driver selbst schreiben muß. Softwaremodule der Hardwarehersteller für gängige Platformen sind leider nicht verwendbar, da diese üblicherweise nicht im Source-Code geliefert werden.