Ausgabe 2/ Robotik Die Rolle der Software. Achim Jungfleisch Mehr Transparenz des Energieverbrauchs

Transkript

1 Achim Jungfleisch Mehr Transparenz des Energieverbrauchs Robotik Die Rolle der Software Neuheiten Automatisierungstreff und Embedded World A8100 Ausgabe 2/ 2010

2 Optimale Ausnutzung Ramon Barth der Multi-Core-Technologie PC-basierte Steuerungssysteme ermöglichen es, dass Anwender mit Hilfe der IEC Programmier sprachen und unterstützen den Softwaremodulen performante und effiziente Lösungen entwickeln können. Funktionen, wie Motion Control, Nockenschaltwerke und Streckensteuerung, die sonst durch spezielle Hardware zu realisieren sind, bildet zum Beispiel Twincat als reine Softwarekomponenten auf Standard-PC-Hardware ab. Dementsprechend profitierte dieses Software system so über die Jahre von der Kontinuität der Windows-Versionen und der stetig wachsenden PC-Hardware-Rechenleistung, ohne im Kern erweitert worden zu sein. Die wesentlichen Neuerungen der Version 3 der PC-basierten Steuerungstechnik betreffen die Engineering-sowie die Laufzeitumgebung, sodass sich jetzt die aktuellen CPU-Generationen optimal nutzen lassen. Systeme so gut wie möglich nutzen zu können, sind alle Anwendungen möglichst modular in Threads beziehungsweise Tasks aufzuteilen (Bild 2). Monolithische Programme werden zwar weiterhin funktionieren, aber sie werden die vorhandene Rechenkapazität zu einem immer geringer werdenden Teil nutzen können. Aktive Unterstützung von 64-Bit-Betriebssystemen Aufgrund der sinkenden Kosten für dynamischen Arbeitsspeicher und dem zunehmenden Speicherbedarf der Anwendungen, wie HD-Videobearbeitung, haben neue PC zunehmend Speicher mit mehr als 4 GB. Da dies die theoretische Grenze des Adressraums einer 32-Bit-CPU ist (in Aktuell sind nicht nur Doppelkern- CPU, sondern auch Vierfach- beziehungsweise Achtfach-Kerne zu vertretbaren Kosten erhältlich. Diese Entwicklung kommt den software-basierten Automatisierungslösungen entgegen, da diese in der Lage sind, Aufgaben und funktionale Einheiten, wie HMI, SPS- Control, SPS-Runtime und NC, je nach Anzahl der verfügbaren CPU-Kerne zu verteilen (Bild 1). Durch entsprechende Konfigurations- und Diagnosewerkzeuge erleichtert Beckhoff [1] dem Anwender die Nutzung von Multi-Core-Systemen. Mehrere Kerne effizient nutzen So lassen sich im Twincat System Manager zum Beispiel die Laufzeiten der Echtzeit-Tasks beobachten und Prioritäten beziehungsweise Ablaufreihenfolgen der Tasks manuell konfigurieren. Mit konfigurierbaren Core-Affinitäten kann man Tasks statisch einem Core zuordnen, sodass sich mit vorgefertigten Profilen wieder eine klassische Einteilung in SPS- Ramon Barth ist Leiter der Software- Entwicklung System, HMI und Echtzeit bei der Beckhoff Automation GmbH in Verl. r.barth@beckhoff.com Bild 1. Aufteilung funktionaler Einheiten auf verschiedene Rechnerkerne und NC-Laufzeitsysteme realisieren lässt. Für die Entwickler von Echtzeit- beziehungsweise SPS-Anwendungen vollzieht sich der Umstieg von Single-Core-Systemen zu Dual-Core-Systemen nahtlos. Die Echtzeit-Laufzeitumgebung nutzt weiterhin nur eine CPU, sodass bestehende SPS-Projekte ohne Vorteilsverlust 1:1 transferierbar sind. Bei Twincat XAR stellt jeder genutzte Core den optimalen Systemtakt in Abhängigkeit der Zykluszeit seiner Tasks ein. Das spart Rechenleistung und senkt den Energiebedarf. Da das Softwaresystem nicht genutzte CPU-Zeit für Windows-Anwendungen zur Verfügung stellt, kann das Windows-Betriebssystem die Anwendungs-Threads auf die verfügbaren CPU verteilen. Diese Threads laufen physikalisch parallel ab und die CPU-Hardware wird optimal genutzt. Um in Zukunft auch Multi-Core- physikalischer Realität stehen tatsächlich ca. 3,5 GB zur Verfügung), arbeiten moderne PC zunehmend mit einem 64-Bit- Betriebssystem. 64-Bit-Windows nutzt einen Modus moderner x86-cpu, der es erlaubt, 32-Bit-Applikationen unverändert parallel zu 64-Bit-Applikationen zu nutzen. Diese Betriebsart ermöglicht somit einen sanften Übergang von 32- nach 64-Bit-Umgebungen. AMD nennt diesen Prozessormodus 64-Bit-Longmode, während Intel dieses Feature unter dem Begriff IA-32e Mode anbietet. Beide Technologien sind kompatibel und bieten als Sub-Modi den 32-Bit-Kompatibilitätsmodus und den 64-Bit-Modus. In Anlehnung an die x86- Historie der betreffenden Prozessoren nennt Microsoft diesen Betriebsmodus in aktuellen Entwicklungswerkzeugen x64. Aufgrund der genannten Prozessoreigenschaften kann Windows in der 8 Heft 2/2010

3 64-Bit-Version 32- bzw. 64-Bit-Anwendungen ablaufen lassen. Hierbei müssen 32-Bit-Anwendungen leichte Geschwindigkeitseinbußen hinnehmen, da alle Zugriffe auf das 64-Bit-Betriebssystem von 32 Bit auf 64 Bit umzusetzen sind. Gerätetreiber, die im Kernelmode ablaufen, müssen, wie das Betriebssystem, für x64 kompiliert und darüber hinaus auch signiert sein. Die Signierung ermöglicht es, die Herkunft eines Gerätetreibers eindeutig zu bestimmen und somit ein Laden von schadhaftem Code in den Adressraum des Betriebssystems zu verhindern. Für x64 kompilierte Programme arbeiten in einem 64-Bit-Adressraum und haben Zugriff auf zusätzliche acht 64 Bit breite General Purpose Register. Weiterhin sind die vom x86 bekannten Register ebenfalls 64 Bit breit. Die Segmentregister entfallen bzw. haben mit Ausnahme vom GS-Register zur Adressierung von Betriebssystemstrukturen keine Bedeutung. Im 64-Bit-Modus ergeben sich aufgrund oben genannter Eigenschaften je nach Anwendung Vor- und Nachteile bezüglich der Leistungsfähigkeit des Gesamtsystems. Zum einen stehen mehr Speicher und mehr Register zur Verfügung, zum anderen ist der kompilierte Code auch signifikant größer, was wiederum einen größeren Bedarf an Speicher und Cache bedeutet. Ein allgemeiner Leistungsgewinn kann sich unter dem Strich nur ergeben, wenn alle Features konsequent genutzt werden oder eine Anwendung zwingend einen größeren Adressraum benötigt. Für automatisierungstechnische Anwendungen reicht in den meisten Fällen Highlights auf einen Blick Die dritte Software-Generation von Twincat für die PC-basierte Steuerungstechnik erweitert die Automatisierungswelt um viele Funktionen. Der Obergriff für diese neue Technologie lautet: Extended Automation (XA). Diese enthält die XA Architecture, die sich wiederum aus den Komponenten XA Engineering und XA Runtime zusammensetzt. Mit Twincat 3 und der Extended Automation Technology (XAT) stehen der Automatisierungswelt neben den objektorientierten Erweiterungen der IEC , mit C und C++ auch die Sprachen der IT-Welt zur Verfügung. Die Integration von Matlab/Simulink ermöglicht zudem den Einsatz in wissenschaftlichen Bereichen. Und das alles in nur einer Engineering-Umgebung. Lauffähig sind die Module in den unterschiedlichen Sprachen in einer gemeinsamen Runtime (Bild 3). Mit der Extended Automation Architecture (XAA) werden die von Twincat bekannten Features weiter fortgeführt und alle verbreiteten Feldbusse unterstützt. Dabei ist Motion Control von Point-to-Point-Bewegungen bis hin zur CNC weiterhin möglich. Die Scientific-Automation-Themen, wie Robotik, Messtechnik und Condition Monitoring, erweitern die reine Automatisierungstechnik. So lassen sich auch hier weitere der Adressraum eines 32-Bit-Systems. Aufgrund des erweiterten Adressraums Programmiersprachen, wie C/C++ und Matlab/Simulink, nutzen. Die Extended-Automation-Engineering- Umgebung (XAE) ist das verbreitete Microsoft Visual Studio. Beckhoff hat in diese Entwicklungsumgebung neben den schon vorhandenen C/C++-Sprachen auch die IEC Programmiermöglichkeit integriert. Die Vorzüge des IT- Frameworks werden so für die Automatisierung nutzbar gemacht. In der Extended Automation Runtime (XAR) werden alle in IEC , C/C++ oder Matlab/Simulink geschriebenen Module in Echtzeit abgearbeitet. Hierbei kommt die bewährte Twincat-Echtzeiterweiterung für Microsoft-Betriebssysteme zur Anwendung. Die Tasks können mit einer Zykluszeit von 50 μs und kleinem Jitter bearbeitet werden. Zudem ist es möglich, bestimmte Tasks auf unterschiedlichen Kernen einer Multicore-CPU auszulagern, was die Performance der PC-Steuerung weiter steigert. Wie leistungsfähig das System ist, hat ein Benchmark gezeigt, bei dem 1000 SPS-Befehle auf einer Test-Hardware mit einem Intel-Prozessor Core i7 950, 3,07 GHz, einem Nvidia 9800 Graphikadapter und vier physikalischen Kernen mit je einem SPS-Laufzeitsystem, abgearbeitet wurden (Bild 4). ergibt sich allerdings ein größeres Potenzial für Anwendungen, wie Condition Monitoring oder digitale Bildanalyse, die der PC neben seinen bisherigen Aufgaben mit erledigen kann. Beckhoff fasst diese Technologien unter dem Begriff Scientific Automation zusammen. Twincat 3 gibt es in einer 32- sowie einer 64-Bit-Version, sodass es sowohl das Potenzial von aktuellen als auch von zukünftigen Prozessoren nutzt. Bild 2. Dialog für die Verteilung von Tasks auf Rechnerkerne Optimale Nutzung moderner Prozessorarchitekturen Neben der stetig steigenden Rechenleistung ist die Kompatibilität zwischen CPU- Generationen ein wesentliches Merkmal der x86-architektur. X86-Prozessoren der neuen Generation sind immer noch in der Lage, Programme auszuführen, die für die Intel-8086-CPU von 1978 kompiliert wurden. Aus Kompati bi litätsgründen nutzen viele 32-Bit Anwen dungen bis heute nur den Befehlsumfang bzw. die Eigenschaften einer CPU. Zwar werden selbst bei diesen Programmen Geschwindig- Heft 2/2010

4 Bild 3. Um die Twincat-3-Runtime offener und flexibler zu gestalten, wurde sie modularisiert. Sie stellt nun eine Umgebung zur Verfügung, in der eine SPS, eine NC, eine CNC oder aus C-Code generierten Modulen zum Beispiel durch Matlab/Simulink ablaufen können keitszuwächse mit jeder neuen Prozessorgeneration erreicht, allerdings wird die Kapazität neuer Prozessorarchitekturen immer weniger genutzt. Erschwerend kommt hinzu, dass ein Mikro-Code manche Kompatibilitätsfunktion in aktuellen Prozessoren emuliert, was zu leichten Performanceverlusten führen kann. Abhilfe schafft hier unter Umständen Hyperthreading. Dies verbessert die Ressourcen-Nutzung durch Pa rallelisierung, soweit die betreffende Software dies unterstützt. Optimal lässt sich die zur Verfügung stehende Rechenleistung mittelfristig nur durch die Verwendung der neuen Befehlssätze nutzen. Unter diesem Gesichtspunkt wurde Twincat XAR grundlegend überarbeitet und kann optional für aktuelle CPU-Typen beispielsweise bezüglich der Fließkommaberechnungen und der Nutzung des CPU-Caches, angepasst werden. C/C++ in der Automatisierungstechnik Oft ist es eine Frage der Philosophie, welche Programmiersprache genutzt wird. Technologisch ist C/C++ den IEC konformen [2] Sprachen überlegen. Aufgrund der weiteren Verbreitung gibt es ein großes Angebot an Compilern, die wiederum im Allgemeinen den effizienteren Zielcode als das IEC Pendant generieren. So bietet zum Beispiel Intel einen C/C++-Compiler an, der die jeweils aktuelle Prozessorgeneration optimal ausnutzt. Über die x86/x64-plattform hinaus gibt es C-Compiler für alle erdenklichen CPU bzw. Microcontroller. Auch die weitergehenden Sprachmittel von C++ bieten dem Software-Entwickler eine bessere Unterstützung für die Erstellung objektorientierter Anwendungen als IEC Trotzdem ist aufgrund der Historie und des Angebots von grafischen Programmiersprachen die Unterstützung der IEC eine wesentliche Komponente von Twincat 3. Für die Unterstützung der modularen Programmierung werden für die IEC-Sprachen objektorientierte Erweiterungen implementiert und die Kombination von C/C++-Modulen mit IEC Modulen kann durchaus sinnvoll sein. In der Version 3 vereint Twincat die Vorteile einer SPS (Online Change, Monitoring usw.) mit der Flexibilität und der Verbreitung von C/C++. Die wesentliche Komponente ist hierbei das Laufzeitsystem mit integriertem Echtzeit-Debugger. Die Integration des vom Anwender erstellten C/C++-Codes in das Softwaresystem unterstützt eine Framework-Bibliothek. Für die Code-Generierung wird der in Microsoft Visual 2010 enthaltene Compiler genutzt. Der Zielcode wird nach der Kompilierung in Form von dynamisch ladbaren Bibliotheken (DLL) in das Echtzeitlaufzeitsystem geladen. Der Anwender ist somit in der Lage, Twincat mit gleichberechtigten Programm-Modulen zu erweitern und die Echtzeitanwendung lokal wie über Fernzugriff zu überwachen und zu debuggen. Bild 4. Bei dem Benchmark führten alle Laufzeitsysteme gleichzeitig den identischen Benchmarktest durch. Das Ergebnis zeigt, dass die Twincat Multicore-Unterstützung die Performance-Steigerung linear zur Anzahl der CPU-Cores ermöglicht Literatur [1] Beckhoff Automation GmbH, Verl: [2] IEC : Programmable controllers Part 3: Programming languages. Genf/ Schweiz: Bureau Central de la Comission Electrotechnique Internationale Heft 2/2010

5 Vier Fragen an Ramon Barth, Leiter Software-Entwicklung bei Beckhoff Automation Was hat es mit der Extended Automation Architecture (XAA) auf sich? R. Barth: Bei Twincat 3 ging es darum, dass seit 1996 bestehende System zu erweitern und zu verbessern. Unsere Software ist nun konsequent in Module aufgeteilt. Für die Kommunikation haben wir mit TcCom eine auf Microsoft-Technologie basierende Interface-Konversation entwickelt. Auch Kunden können mithilfe des Twincat Automation Device Driver eigene und gleichberechtigte Module beisteuern, zum Beispiel für Antriebe oder Feldbusse. So haben wir zum Beispiel auch unsere Safety-Lösung als Modul in Twincat 3 integriert. Was für Auswirkungen hatte dies auf die Runtime-Version von Twincat 3? R. Barth: Entwicklungsziele der neuen Runtime-Lösung von Twincat 3 (XAR) waren noch mehr Modularität und Rechenleistung. Ein wesentlicher Teil von XAR ist die Multicore-Unterstützung. Das 1996 entstandene Twincat war noch auf Single-Core-Prozessoren ausgelegt. Dazu musste das Software- Design angepasst werden. Bei Twincat 3 lassen sich die Tasks den Cores zuordnen oder umgekehrt. Der Vorteil dabei ist, dass sich der Rechenzeitbedarf für die einzelnen Komponenten entkoppelt. So kann zum Beispiel ein Core für Control-Aufgaben genommen werden, der nächste für Motion Control. Mithilfe von Hyperthreading werden dann noch aus vier tatsächlichen Cores acht virtuelle. Welche Vorteile bietet die Integration der Entwicklungsumgebung XAE in Microsoft Visual Studio? R. Barth: Unsere Entwicklungsumgebung ist skalierbar vom einfachen Visual- Studio-Rahmen bis zur kompletten IT-Welt. Dementsprechend können unsere Anwender mit Twincat Standard die IEC Entwicklungsumgebung, unseren System Manager und den Visual-Studio-Rahmen nutzen oder mit Twincat Integrated die komplette Visual-Studio-Software, um damit die IT-Welt mit unserer Automatisierungs-Software zu verheiraten. Twincat ist dann eine der Komponenten von Visual Studio. Somit schreiben die Anwender in Visual Studio unter Nutzung der Online- Features des Debuggers ein SPS-Programm nach IEC Standard. Visual Studio bietet die entsprechende Infrastruktur zum Datenaustausch. Der wesentliche Vorteil ist dabei das Zusammenwachsen mit den anderen Microsoft-Tools. Dies zeigt sich zum Beispiel darin, dass wir für die Visualisierung in vielen Anwendungen empfehlen können, auf Standard-IT-Tools zuzugreifen. So werden neue, in Visual Studio integrierte Editoren und Designer auch die Silverlight-Technologie unterstützen, mit der webbasierte Programmierung ermöglicht wird. Welche Programmiersprachen unterstützen Sie? R. Barth: Für unsere modular erweiterbare Entwicklungsumgebung setzen wir nun auf objektorientierte Eigenschaften. Neben den fünf IEC Programmiersprachen betrifft das auch C/C++ als sechste Sprache. Hier nutzen wir den Standard-Compiler von Microsoft, um Automatisierungsaufgaben mit Echtzeit- Anforderungen in C++ lösen zu können. Dieser C/C++-Compiler hat sich bereits millionenfach in IT-Anwendungen bewährt. Damit erweitern wir die vorhandene C/C++-Umgebung mit automatisierungstechnischen Feinheiten, wie der Real - time-library. Als dritte Möglichkeit können unsere Kunden ein Programm mit Matlab/ Simulink erzeugen. Mithilfe einer Framework Library wird der Code in ein Twincat- Modul umgewandelt. So kann man ein Modul erzeugen, ohne programmieren zu müssen. Heft 2/2010