„Die Komplexität neuer Maschinengenerationen verlangt nach der Ergänzung von Hochsprachen und mathematischen Simulations-Tools.“ Stefan HoppeRedaktion IEE/Renate Schildheuer
Herr Hoppe, zur SPS IPC Drives gibt es Twincat 3.1 in einer neueren Version. Gemessen an den üblichen Innovationszyklen eigentlich etwas schnell.
2010 hatten wir einen Technical Preview gezeigt, das unsere Kunden am liebsten sofort eingesetzt hätten. Verfügbar war Twincat 3 für erste Anwender dann ab dem dritten Quartal 2011 – für die breite Öffentlichkeit Anfang 2012. Twincat 3.1 haben wir im Frühjahr 2013 zur Hannover Messe präsentiert – dazu bringen wir nun ein Update. Das Innovationstempo mag insgesamt zügig erscheinen, zeigt aber auch die Dynamik der Beckhoff-Kunden. Sie wollen möglichst schnell die Vorteile der angekündigten Releases nutzen.
Das war schon beim Wechsel von Twincat 2 auf Twincat 3 der Fall, der ja keine kleine Evolution mit wenigen Features, sondern ein sehr großer Wurf mit revolutionären Ansätzen war, wie der Möglichkeit, Binär-Code erstellt in verschiedenen Programmiersprachen zu modularisieren, wiederzuverwenden und bei Bedarf per E-Mail oder USB-Stick direkt an und in die Maschine zu bringen. Diese binären Module kann der Programmierer aus einer Bibliothek zusammenstellen und mit eigenem Know-how ergänzen. Zusätzlich zu IEC 61131-3 lassen sich Module auch in C/C++ programmieren und Matlab zur Problemlösung nutzen – ganz zu schweigen von der Multicore-Unterstützung.
Welches sind denn die wesentlichen Neuerungen?
Das ist zum Beispiel der Support von harter Echtzeit unter x64-Betriebssystemen oder die Unterstützung der Windows-CE-Plattform. Mit Twincat 3.0 haben wir zwar schon Multicore-Funktionalität eingeführt – seit Twincat 3.1 unterstützen wir zusätzlich die CPU-Core-Isolation: Der Projektierer kann darüber dediziert festlegen, welche Cores eines Prozessors mit Twincat-Echtzeit laufen und welche weiterhin explizit nur für das Windows-Betriebssystem zur Verfügung stehen. Die Twincat-Runtime nutzt dann diese Windows-Cores überhaupt nicht – umgekehrt sieht das Betriebssystem die Cores mit exklusiver Twincat-Nutzung gar nicht. Hinzu kommen eine verbesserte Anbindung an Microsofts Team Foundation Server und Sub-Version, was die Aufteilung und Zusammenführung von großen Projekten erleichtert. Sehr hilfreich für Erweiterungen und Optimierungen vor Ort ist darüber hinaus der überarbeitete Projektvergleich.
Wir konnten schon immer SPS-Code von Version 1 zu Version 2 vergleichen. Mit Twincat 3.1 lässt sich jetzt auch die komplette Konfiguration der I/O-Ebene und sämtliche Achsparameter der Antriebe vergleichen. Wenn in einer Anlage künftig nach einer Änderung irgendwas nicht mehr funktioniert, kann vor Ort der komplette Projektstand verglichen werden. Unsere Scope-Funktionalität ist nun auch in die Visual Studio Shell eingebunden – eine einzige Plattform für alle Produkte erleichtert das Engineering. In Summe sind sehr viele Erweiterungen in das Update eingeflossen.
„Den meisten Anwendern reicht bei SPS-Programmen der 32-Bit-Adressraum.“ Stefan Hoppe
Wer braucht den erweiterten Adressraum der 64-Bit-Version?
Den meisten Anwendern reicht bei SPS-Programmen der 32-Bit-Adressraum. Mit der Umsetzung des x64-Support kommen wir nun dem Bedarf der IT-Seite entgegen: Vision-Systeme und diverse Scada-Hersteller benötigen den größeren Adressraum.
Und diese Funktionen stehen jetzt zur SPS IPC Drives zur Verfügung?
Wir liefern bereits aus. Seit Ende Oktober ist nun auch für kleine Embedded-Geräte die Twincat-3.1-Laufzeit auf dem ersten ARM-Controller CX9020 mit Windows CE verfügbar. Das gilt ebenso für die High-End-Embedded-PCs der Serie CX2000. Hier haben uns die erst spät für Windows CE verfügbaren Board-Support-Packages zeitlich ausgebremst.
Welchen Stellenwert hat denn ein durchgängiges Engineering bei der neuen Version?
Das war bereits bei Twincat 3 ein Kernpunkt beim Design. Wir unterstützen durchgängiges Engineering über zahlreiche Standard-Schnittstellen, zum Beispiel das Import-/Exportformat der PLCopen. Aus der vorherigen Twincat-2-Welt haben wir das ECAD-Import-/Export-Tool übernommen. Damit lassen sich direkt aus der ECAD-Engineering-Umgebung heraus Einstellungen für Twincat vornehmen.
Bei vielen Maschinenbauern ist das mechanische CAD-System federführend. Wie integrieren Sie die dort entstehenden Daten, die für das Steuerungsprojekt relevant sind?
Viele Maschinenbauer haben die Konfiguration ihrer Maschinen und Komponenten bereits in einer Datenbank oder Excel abgelegt. Diese Quellen können wir über das Twincat Automation Interface einlesen und das Engineering quasi fernsteuern, das heißt Projekte automatisch generieren. Das vereinfacht das Engineering, da der Projekteur nicht mehr vor dem Rechner sitzen und alles mit der Maus einzeln durchklicken muss. Und weniger manuelle Tätigkeiten bedeuten weniger Fehler.
Wie funktioniert das konkret?
Durch den Datenimport über das Automation Interface kann der Maschinenbauer eine komplette Maschine automatisiert aufsetzen. Das beinhaltet die Engineering- und Konfigurationsdaten ebenso wie SPS-Code, inklusive Variablen, Motoreinstellungen und der Zuordnung mit der physikalischen Klemmenebene. Sogar welcher Core den jeweiligen Programmteil bearbeiten soll, lässt sich zuordnen.
Wer muss sich wem anpassen, was die Schnittstelle betrifft?
Wir haben ein Import-/Exportformat definiert, das viele Unternehmen implementiert haben, vor allem Großkunden. Ob sich in Zukunft im Engineering-Bereich andere standardisierte Engineering-Automation-Schnittstellen entwickeln, hängt auch davon ab, ob und welche Standardisierungsorganisationen zusammenarbeiten. Eine Kombination aus AutomationML und OPC-UA wäre aus meiner Sicht als OPC-Präsident Europe eine sinnvolle Lösung.
Twincat ist eng mit Visual Studio von Microsoft verzahnt. Nutzen die Automatisierer überhaupt diese Entwicklungsplattform?
Twincat integriert sich in Visual Studio – man muss sich aber nicht vorstellen, dass sich nun jeder erst ein Visual Studio kaufen muss. Wer klassisch in IEC-Sprachen programmieren will, braucht überhaupt kein Visual Studio; nichts zusätzliches von Microsoft. Twincat funktioniert dann wie jedes andere, eigenständige Engineeringtool. Technisch basiert es auf der kostenlosen Microsoft Visual Studio Shell. Nur Anwender, die zusätzlich in den Hochsprachen C# und C++ programmieren wollen, benötigen ein Visual-Studio-Paket, in das sich Twincat wiederum integriert.
Das Geschäftsmodell von Microsoft bei der Visual Studio Shell hat für uns gepasst. Es ist kostenlos, wird gepflegt und bietet einen direkten Zugang zum Support und zum Source-Code. Also warum sollten wir Zeit verschwenden, eine eigene Shell zu programmieren? Als Alternative hätten wir uns auch in Eclipse einbinden können. Die Open-Source-Umgebung mit Java-Touch kommt aber ebenso aus der IT-Welt, wirft somit die gleiche Fragestellung auf: Ist die Automatisierungswelt reif für IT-Editoren? Da Beckhoff schon immer auf Microsoft-Basis arbeitet und wir sowieso auch C++ einbinden wollten, war es logisch und richtig, die Visual Studio Shell zu nutzen.
Wie groß ist der Anteil an Beckhoff-Kunden, die Twincat als klassisches IEC-Entwicklungs-Tool nutzen, ohne die Extensions wie C++ und Matlab und Integration in Visual Studio?
Historisch ist der Anteil von C- und Matlab-Anwendern natürlich noch klein im Verhältnis zu dem Pool an IEC-Programmierern. Aus meiner Sicht bieten uns die Extensions die Möglichkeit, in ganz andere Märkte vorzudringen. Es gibt eine riesige Masse an Programmierern, die mit irgendwelchen Tools in den kleinsten Embedded-Bereichen C++ programmieren. Ihnen fehlen gute Debug-Möglichkeiten und eine saubere Engineering-Plattform. Mit Twincat können diese Entwickler nun C-Code implementieren. Ohne zusätzlichen Aufwand lässt sich die Software anschließend im Kernelmode eines Betriebssystems unter Echtzeitbedingungen installieren, inklusive aller Debug-Monitor-Möglichkeiten. In diesem Segment punkten wir gerade.
Ihre Wettbewerber und auch Beckhoff preisen die Matlab/Simulink-Anbindung und die C++/C#-Programmierung als wichtiges Feature an – im Einsatz haben es anscheinend aber nur wenige Anwender.
Das muss man differenziert sehen: Zunächst überzeugen wir ja niemanden, bestehenden SPS-Code mit Hot-Download-Funktionalitäten gegen C-Code zu ersetzen. Aber das Interesse an Matlab ist gewaltig. Das sehen wir an den ständig ausgebuchten Seminaren zu diesen Themen, die Kunden mit unterschiedlichen Intentionen besuchen.
„Das Interesse an Matlab ist gewaltig. Das sehen wir an den ständig ausgebuchten Seminaren zu diesen Themen.“ Stefan HoppeRedaktion IEE/Renate Schildheuer
Es gibt Anwender, die den bestehenden SPS-Code mit ein bisschen C erweitern möchten, weil sich mathematische Formeln damit einfacher umsetzen lassen. Andere starten Projekte komplett neu in C, viele auch direkt in Matlab, da sie für die Umsetzung ihrer Innovationen komplexe mathematische Modelle simulieren und komplexe Regelungsstrategien benötigen. Im Vergleich zu anderen Lösungen am Markt ist unsere Matlab-Integration deutlich einfacher und flexibler im Engineering. Ein Beispiel: Unsere Matlab-Modellierung ist Hardware-unabhängig, die resultierenden Software-Module können beliebig oft instanziert werden. Die grafische Darstellung der Module und die Debug-Möglichkeit haben wir in unsere Twincat-Umgebung integriert – das hebt uns deutlich von anderen ab.
Bei all den Technologiepaketen und Erweiterungen – eine wesentliche Komponente fehlt: die Twincat-Visualisierung. Wieso schlägt Beckhoff darum einen Bogen?
Wir werden auch das Thema irgendwann angehen – die Visual Studio-Integration bietet dafür sicherlich eine gute Basis, die heute schon von vielen Kunden für eigene UI-Implementierungen genutzt wird. Kunden können aber auch verschiedene Scada-Hersteller wählen, die unsere ADS-Protokollschicht adaptiert haben und sich damit an unsere Steuerung andocken können – OPC, vor allem UA, bietet auch die Anbindung an Scada-Systeme. Es gibt also verschiedene Lösungswege zu einem UI.
Eine tiefe Integration, was das Engineering betrifft, ist das aber nicht.
Ein typisches Projekt besteht aus der Programmierung der Steuerungslogik und dem Design der Bedienoberfläche. Diese beiden Schritte ergeben sich immer, auch wenn wir selbst ein Visualisierungs-Paket anbieten würden. Generell steigt die Bedeutung des Designs bei einem Projekt. Aber wie gesagt: Ein eigenes UI-Packet wäre sicherlich eine sinnvolle Abrundung.
Neben dem HMI gibt es andere, spannende Puzzle-Steine, etwa die Bildverarbeitung. Gerade die Multicore-Prozessoren und C++-Anbindung erschließen interessante Optionen. Mit unserer Lösung lässt sich C-Code generieren, der direkt aus dem Kernelmode auf eine TCP-Leitung zugreift, um Kamerabilder zu empfangen und auszuwerten.
Steht die Maschinenvisualisierung nicht vor einem Evolutionssprung? Die Stichworte sind hier Multitouch und Mehrfingerbedienung.
Die Visualisierung wird in Zukunft definitiv mehr auf Usability-Aspekte abgeklopft. Künftig steht die Vereinfachung und Reduzierung der Oberflächen auf die wesentlichen Aspekte im Vordergrund. Smartphone- und Tablet-Bedienung lösen gerade ein Umdenken aus.
Mit welchen Konsequenzen?
Es wird weiterhin an Maschinen und in der Fertigungsindustrie ein Anzeigegerät oder mehrere geben, eben mit Multitouch. Ganz anders die Situation bei sehr dezentralen Kleinst-Embedded-Anlagen. Hier fällt das Display und Monitor vielleicht ganz raus. Die Bedienung wandert auf das Smartphone – entweder das eigene à la ‚Bring your own Device‘ oder auf ein vom Arbeitgeber bereitgestelltes Gerät. Solche Szenarien sehen wir in verschiedenen Ausprägungen teilweise schon heute.
„Unsere Binär-Code-Modularisierung ist praktisch die Umsetzung der App-Philosophie.“ Stefan HoppeRedaktion IEE/Renate Schildheuer
Tablet, Smartphone als Bediengeräte: Das schreit förmlich nach Apps. Welche Erfahrungen haben Sie gesammelt?
Gegenfrage: Haben wir mit dem Twincat-3-Binärmodul-Ansatz nicht genau das App-Konzept umgesetzt? Zugegeben, es braucht eine Twincat Runtime. Aber das ist bei Apple, Android und Microsoft identisch. Eine App aus dem Windows-Store läuft nur auf einer Windows-Plattform und eine Apple-App eben nur auf einem Apple-Device. Theoretisch können Kunden mit Twincat 3 Module schreiben und bei Bedarf als Binär-Code an jemand anderen weitergeben, verteilen. Wir kommen hier aber in andere Fragestellungen, wie Haftung und Software-Pflege.
Bei Windows XP läuft 2014 der Support aus. Spüren Sie bei Beckhoff eine Migrationswelle?
Von heute auf morgen setzt niemand ein anderes Betriebssystem ein. Das passiert nur, wenn eine neue Maschinengeneration aufgelegt wird. Maschinen im Produktivbetrieb, die mit allen Security-Mechanismen ausgestattet sind, bei denen im Normalfall nicht monatlich Security Patches aufgespielt werden. Wenn eine Maschine, die mit Windows XP Embedded oder XP Professional ausgerüstet ist, sowieso seit einigen Jahren kein Security-Patch gesehen hat, dann ist es dem Betreiber egal, ob der Support ausläuft oder nicht – er hat ihn die letzten Jahre auch nicht genutzt.
Dem Endanwender kann es egal sein, dem Maschinenbauer nicht.
Der Maschinenbauer kündigt den Support für dieses Betriebssystem ab und entwickelt die nächste Maschinengeneration auf dem aktuellen Betriebssystem. Das passiert nicht erst jetzt, gewissermaßen 5 vor 12, sondern findet zumindest bei unseren Kunden schon seit geraumer Zeit statt. Sie profitieren davon, dass wir als Microsoft Embedded Gold Partner frühzeitig die Betriebssysteme implementieren und testen können. Das gibt Anwendern genügend Vorlauf und Sicherheit, entsprechend zeitig auf neue Betriebssysteme zu migrieren, unabhängig vom Auslaufen des Supports.
Viele Twincat-Anwender sind bereits vor Jahren von XP Embedded auf Windows Embedded Standard 2009 umgestiegen, was Support bis zum 08.01.2019 liefert. Viele haben bei neuen Maschinen auf Windows 7 Embedded gewechselt, weil sie die höhere Flexibilität haben wollten, beispielsweise bei der Internationalisierung ihrer Images. So konnten sie Sprachpakete für Türkisch oder Chinesisch selbst einbinden, ohne dass wir das als OEM hätten machen müssen – der Extended Support für WES 7 endet am 13.10.2020.
Windows CE, Windows 7, Windows 8 plus die jeweiligen Embedded Editionen. Haben Sie bei den vielen Versionen und Derivaten noch den Überblick?
Ja, die unterschiedliche Namensgebung mit jedem Versionswechsel von CE, Windows 7 und den Embedded-Versionen verwirrt. Interessanterweise führt die Namensvielfallt dazu, dass eigentlich alle – Kunden, wir und selbst Microsoft intern – nur von CE, Embedded und dem Big Windows sprechen. Mehr Kernel gibt es eigentlich nicht und jeder weiß, was gemeint ist.
Alles andere ist Marketing?
Der Rest sind Variationen, Funktionen rausnehmen, das eine skalierbar machen, das andere nicht. Ein Beispiel: Ein Windows Embedded Standard 7E unterstützt zwar Gesten, aber kein Multitouch. Das ist Windows Embedded Standard 7P vorbehalten. Und Windows 8 Embedded heißt eben nicht mehr, was logisch wäre, Windows Embedded Standard 8. Die Microsoft-Strategien haben jetzt mit dem aktuellen Release die 8 wieder vor das Standard gezogen.
Herrscht nicht generell die Philosophie vor, nur jedes zweite Windows zu nutzen? Demnach floppt Windows 8.
Nein, wir haben konkrete Anfragen zu Windows 8, halten uns derzeit aber noch zurück, weil ein bestimmter Punkt für unsere Anwender in der Industrie suboptimal ist. Ganz konkret betrifft das den Aktivierungsmechanismus von Windows 8, der einen Verbindungsaufbau der jeweiligen Maschine mit dem Microsoft-Server verlangt – oder eben das Xcopy einer eindeutigen Datei für den IPC. Das Verfahren mag für Consumer vielleicht gar nicht schlimm sein, für das Cloning von Images für einen Serienmaschinenbauer und für den Service an der Maschine ist das schlichtweg untragbar. Das bedeutet aber nicht, dass wir uns nicht schon längst auf die neue Betriebssystem-Generation vorbereitet hätten. Twincat 3 läuft natürlich auch unter Windows 8 – wir warten nur auf eine praktikable Lösung von Microsoft.
Stefan Kuppinger
(sk)
