Vor fast 30 Jahren wurde das Konzept der virtuellen Maschine allgemein bekannt im damaligen UCSD-Pascal auf dem Apple, dessen Pascal-Compiler den sog. p-Code erzeugte, der schließlich auf diversen CPUs lauffähig war. Dass das Konzept keineswegs veraltet ist, zeigen uns die entsprechenden modernen Varianten z.B. in Java und .NET/C#. Diesen Sprachen ist gemeinsam, dass sie universelle, grundsätzliche Programmieranweisungen kodieren und die virtuelle Maschine entsprechend viel Bytecode interpretieren muss, um eine vollständige Applikation auszuführen. Daher rührt die im Vergleich zu direkt in Maschinencode übersetzten Programmen verlangsamte Ausführung. Bei Java wird diesem Problem inzwischen mit speziellen, Maschinencode erzeugenden Compilern oder speziellen, Java-Bytecode ausführenden Prozessoren begegnet. Bytecode für Softwaremodule Aus den Erfahrungen mit zigtausenden geschriebenen Programmzeilen in VisualBasic, C/C++ und Java in den vergangenen Jahren kristallisierte sich bei MFP eine neue Sicht für die Struktur von Anwendungsprogrammen heraus. Nicht die Kombination der einzelnen Programmanweisungen einer beliebigen Hochsprache war relevant, sondern die Organisation der Bibliotheken mit den vielen, im Idealfall für mehrere Projekte geeigneten und für unterschiedliche Betriebssysteme verfügbaren Softwaremodulen. So entstand aus der gewünschten überschaubaren Verwaltung von Softwaremodulen eine Strukturierung über Bytecode, die einen entsprechenden Interpreter und ergänzende Ablaufelemente (If, Then, Else, GoTo, ….) nahe legte. Entstanden ist schließlich UMAS (Universelles Modulares Applikations-System), bestehend aus einem Compiler, der Bytecodes aus einer an C++ orientierten Skriptsprache erzeugt, und virtuellen Maschinen, die auf Windows und Linux lauffähig sind und die zurzeit immer noch wachsenden Programmbibliotheken beherbergen. Implizit war gleichsam der Anspruch, die Sprachelemente, deren Pendants die Softwaremodule in den virtuellen Maschinen sind, beliebig erweitern zu können. So entstand ein Compiler, der seinen verarbeitbaren Befehlsvorrat über externe XML-Dateien erhält und beliebig auf zukünftige Programmentwicklungen anpassbar ist. Optimiert für die Anwendung Die Softwaremodule, die über einen spezifischen Bytecode adressiert und parametriert werden, sind an der Anwendung orientiert und im Vergleich zu sonst üblichen, z.B. in Java kodierten, Programmelementen funktional deutlich mächtiger, so dass man dagegen die Laufzeitverzögerungen durch die vir-tuellen Maschinen vernachlässigen kann. Mit UMAS entwickelte Programme sind also nicht langsamer als direkt in C/C++ geschriebene. Bei MFP wurde die Chance genutzt, UMAS zusätzlich mit den Sprachelementen zu versorgen, die man bei der Entwicklung von Anwendungsprogrammen immer vermisst hat bzw. nur umständlich programmieren konnte. Dazu gehörte in erster Linie der einfache Zugriff auf andere virtuelle Maschinen, unabhängig davon, ob sie auf demselben PC laufen oder über das Netzwerk erreichbar sind. So öffnet sich der Weg für neue Konzepte in der Gestaltung von Anwendungen. Das Konzept verteilter Anwendungen Bei UMAS werden die Ressourcen der virtuellen Maschinen in Gruppen unterteilt und die Anwendung in darauf zugeschnittene Anwendungsmodule gegliedert. Die Unterteilung ist grundsätzlich ausgelegt, und zwar in Automatisierung (Messen, Steuern, Regeln), Visualisierung (Mensch-Maschine-Interface) und Datenbankanbindung (ODBC-Schnittstelle und XML-Datenhaltung). Jede virtuelle Maschine hat einen direkt adressierbaren Datenspeicher (Datenpool), der über einen integrierten Server von anderen virtuellen Maschinen über TCP/IP-Kommunikation erreichbar ist (Bild 2). Um die Abläufe an die zeitlichen Randbedingungen einer Automatisierung anzupassen, wird nur der Datenpool des Automatisierungsmoduls öffentlich gemacht und als gemeinsamer Speicher für alle Module genutzt. So greift das Automatisierungsmodul direkt (schnell) auf den Arbeitsspeicher zu, während Visualisierung und Datenbankanbindung am Server hängen und beliebig im lokalen Netzwerk platziert sein können, über Router auch im Internet. Mit einem Monitorprogramm kann der Inhalt des Datenpools über die TCP/IP-Kommunikation ausgelesen oder auch verändert werden, wenn das Automatisierungsmodul entsprechende Zugriffe erlaubt. Selbstredend wird dieses Konzept durch einfache UMAS-Sprachelemente unterstützt. Jede virtuelle Maschine hat einen Peripheriecode, z.B. MSR1, MMI3 oder DBA7. Eine Variable mit dem Namen myVar01 in der virtuellen Maschine MSR1 wird aus allen anderen virtuellen Maschinen über den direkten Zugriff mit MSR1:myVar01 erreicht. Ähnlich einfach wurde das Starten von Threads in der eigenen oder in anderen virtuellen Maschinen gestaltet. Integration von Geräten über ASAM GDI Während sich viele andere Integrationskonzepte auf betriebssystemspezifische Methoden ab-stützen (z.B. OPC), wurde für UMAS ein Konzept gewählt, das die Unabhängigkeit vom Betriebssystem in den Vordergrund stellt. Damit stehen die Geräte grundsätzlich für alle virtuellen Maschinen zur Verfügung, unter Windows, Linux oder auch Echtzeitbetriebssystemen. Das Konzept des ASAM GDI sieht vor, die Geräteeinbindung in einen betriebssystemunabhängigen Gerätetreiber (Kodierung der Gerätestruktur und der Kommunikationsprotokolle) und einem betriebssystemabhängigen Plattformadapter (konkreter Datenaustausch mit dem Gerät) zu unterteilen (Bild 3). Gerätetreiber werden also, beim ASAM in C/C++, vom Gerätespezialisten programmiert und der Zugriff auf die Peripherieschnittstelle vom Betriebssystemspezialisten. Ein weiterer Vorgang der Modularisierung, der gerade bei den häufigeren Treiberkonzeptänderungen der Windows-Betriebssysteme (Legacy, WDM, signierte Vista-Treiber) die Entwicklungsarbeiten kanalisiert und eine optimale Aufgabenteilung erlaubt. Von der Programmierung zur Konfiguration Bei MFP sieht man die Ent-wicklung von UMAS als den ersten wichtigen Schritt einer grundsätzlichen Strukturveränderung bei Anwendungsprogrammen. Mit konsequenter Fortsetzung der Modularisierung hin zu beliebig kombinierbaren Anwendungsmodulen wird ein Umstieg von individuell zugeschnittenen auf individuell konfigurierbare Programme erreicht. Die Konfiguration kann aber, im Gegensatz zur Programmierung, wieder dem Anwender zugemutet werden, wodurch sich mit dem Einsatz entsprechender Hilfsmittel für die Konfiguration eine hohe Flexibilität bei Reduktion der Entwicklungskosten ergibt. Derzeit wird bei MEP die klassische SPC-Software (Statistic Process Control) zur Qualitätssicherung neu strukturiert und in ein übergreifendes Konzept eines modularen MES (Manufacturing Execution System) mit Maschinen-, Personal- und Betriebs-datenerfassung eingebunden, das vom Anwender selbst auf seine Randbedingungen zugeschnitten (konfiguriert) werden kann. Ohne UMAS würde eine entsprechende Neugestaltung ein Vielfaches an Zeit und Aufwand mit sich bringen.
MFP GmbH
