Das TwinCAT Component Object Model (TcCOM) Konzept

Das TwinCAT Component Object Model definiert die Eigenschaften und das Verhalten der Module. Das vom „Component Object Model“ (COM) von Microsoft Windows abgeleitete Modell beschreibt die Art und Weise, wie verschiedene Software-Komponenten, die unabhängig voneinander entwickelt und kompiliert wurden, zusammen arbeiten können. Damit das möglich ist, müssen ein genau definierter Verhaltensmodus und die Beachtung von Schnittstellen des Moduls definiert werden, so dass sie interagieren können. Eine solche Schnittstelle ist damit beispielsweise auch ideal um Module unterschiedlicher Hersteller in Interaktion zu setzen.

TcCOM macht Anleihen bei COM (Component Object Model aus der Microsoft Windows-Welt), wobei lediglich eine Untermenge von COM verwendet wird. Allerdings enthält TcCOM im Vergleich zu COM zusätzliche Definitionen, die über COM hinausgehen, z.B. die Modul Zustandsmaschine.

Überblick und Verwendung von TcCOM Modulen

Einleitend hier ein Überblick, der die einzelnen Themen leichter verständlich machen soll.

Ein oder mehrere TcCOM Module werden in einem Treiber zusammengefasst. Dieser Treiber wird vom TwinCAT Engineering mittels des MSVC Compilers erstellt. Die Module und Schnittstellen werden in einer TMC (TwinCAT Module Class) Datei beschrieben. Die Treiber mit ihrer TMC Datei können nun zwischen den Engineering Systemen ausgetauscht und kombiniert werden.

Mittels des Engineerings werden nun Instanzen von diesen Modulen erstellt. Zu diesen gibt es eine TMI Datei. Die Instanzen können parametriert und untereinander mit anderen Modulen oder zu dem IO verknüpft werden. Eine entsprechende Konfiguration wird auf das Zielsystem übertragen und dort ausgeführt.

Dabei werden entsprechende Module gestartet, die sich beim TwinCAT-ObjectServer anmelden. Das TwinCAT XAR sorgt auch für die Bereitstellung der Prozessabbilder. Module können den TwinCAT-ObjectServer nach einer Referenz auf ein anderes Objekt in Bezug auf eine bestimmte Schnittstelle fragen. Wenn sie eine solche Referenz erhalten, können sie die Methoden der Schnittstelle auf der Modulinstanz aufrufen.

Die folgenden Abschnitte konkretisieren die einzelnen Themengebiete.

ID Management

Es werden verschiedene Typen von IDs für die Interaktion der Module untereinander und auch innerhalb der Module verwendet. TcCOM verwendet GUIDs (128 Bit) sowie 32 Bit lange Ganzzahlen.

TcCOM verwendet

• GUIDs für: ModulIDs, ClassIDs und InterfaceIDs.
• 32 Bit lange Ganzzahlen werden verwendet für: ParameterIDs, ObjectIDs, ContextIDs, CategoryID.

Schnittstellen

Eine wichtige Komponente von COM, und damit auch von TcCOM, sind Schnittstellen.

Schnittstellen definieren einen Satz Methoden, die zusammengefasst werden, um eine bestimmte Aufgabe zu erfüllen. Eine Schnittstelle wird mit einer eindeutigen ID (InterfaceID) referenziert, die bei gleichbleibender Schnittstelle niemals geändert werden darf. Dank dieser ID können verschiedene Module feststellen, ob sie mit anderen Modulen zusammenarbeiten können. Gleichzeitig kann der Entwicklungsprozess unabhängig erfolgen, wenn die Schnittstellen fest definiert sind. Änderungen an Schnittstellen führen also zu unterschiedlichen IDs. Im TcCOM Konzept ist deswegen vorgesehen, dass InterfaceIDs andere (ältere) InterfaceIDs überlagern können ( „Hides“ in der TMC Beschreibung / im TMC Editor). Auf diese Weise stehen zum einen beide Varianten des Interfaces bereit, zum anderen wird aber auch immer klar, welches die aktuellste InterfaceID ist. Das gleiche Konzept gibt es auch für die Datentypen.

TcCOM selber definiert bereits eine ganze Reihe an Schnittstellen, die in manchen Fällen vorgeschrieben (z.B. ITComObject), aber in den meisten Fällen optional sind. Viele Schnittstellen machen nur in bestimmten Anwendungsbereichen Sinn. Andere Schnittstellen sind dermaßen allgemein, dass sie häufig wiederverwendet werden können. Kunden-definierte Schnittstellen sind vorgesehen, so dass z.B. zwei Module eines Herstellers in der Lage sind, miteinander in Verbindung zu treten.

• Alle Schnittstellen werden von der grundlegenden Schnittstelle ITcUnknown abgeleitet, die, wie die entsprechende Schnittstelle von COM, die grundlegenden Dienste zur Abfrage von anderen Schnittstellen des Moduls (TcQueryInterface) und zur Steuerung der Lebensdauer des Moduls (TcAddRef und TcRelease) bereitstellt.
• Die ITComObject-Schnittstelle, die von jedem Modul implementiert sein muss, enthält Methoden um auf den Namen, die ObjectID, die ObjectID des Parent, die Parameter und die Zustandsmaschine des Moduls zuzugreifen.

Einige allgemeine Schnittstellen werden von vielen Modulen verwendet:

• ITcCyclic wird von Modulen, die zyklische aufgerufen werden sollen („CycleUpdate“), implementiert. Mit Hilfe des ITcCyclicCaller Interfaces einer TwinCAT-Task kann sich das Modul anmelden um zyklische Aufrufe zu erhalten.
• Durch die ITcADI-Schnittstelle kann auf Datenbereiche eines Moduls zugegriffen werden.
• ITcWatchSource wird standardmäßig implementiert und erlaubt unter anderem ADS-DeviceNotifcations zu erhalten.
• Die ITcTask-Schnittstelle, die von den Tasks des Echtzeitsystems implementiert wird, stellen Informationen bezüglich der Zykluszeit, der Priorität und anderer Informationen zur Task zur Verfügung.
• Die Schnittstelle ITComObjectServer wird vom ObjectServer implementiert und von allen Modulen referenziert.

Es wurden bereits eine ganze Reihe allgemeiner Schnittstellen definiert. Allgemeine Schnittstellen haben den Vorteil, dass deren Verwendung den Austausch und die Wiederverwertung von Modulen unterstützt. Nur dann, wenn keine geeigneten allgemeinen Schnittstellen bestehen, sollten eigene Schnittstellen definiert werden.

Class Factories

Für die Erzeugung von in C++ Modulen werden sogenannte „Class Factories“ verwendet. Alle Module, die in einem Treiber sind, besitzen eine gemeinsame Class Factory. Die Class Factory meldet sich einmal beim ObjectServer an und bietet ihre Dienste für die Erstellung bestimmter Modulklassen an. Die Modulklassen sind durch die eindeutige ClassID des Moduls gekennzeichnet. Wenn der ObjectServer ein neues Modul anfordert (auf Grundlage der Initialisierungsdaten des Konfigurators oder durch andere Module während der Laufzeit), wählt das Modul die richtige Class Factory auf Grundlage der ClassID aus und veranlasst die Erzeugung des Moduls über seine ITcClassFactory-Schnittstelle.

Modul-Lebensdauer

Auf ähnliche Weise wie im Falle von COM wird die Lebensdauer eines Moduls über einen Verweiszähler (RefCounter) bestimmt. Jedes Mal, wenn eine Schnittstelle eines Moduls abgefragt wird, wird der Verweiszähler inkrementiert. Er wird wieder dekrementiert, wenn die Schnittstelle freigegeben wird. Eine Schnittstelle wird auch bei der Anmeldung eines Moduls beim ObjectServer abgefragt, (die ITComObject-Schnittstelle), so dass der Verweiszähler zumindest auf eins steht. Bei der Abmeldung wird er erneut dekrementiert. Wenn der Zähler den Wert 0 erreicht, löscht das Modul sich selbst automatisch - normalerweise nach der Abmeldung beim ObjectServer. Wenn aber bereits ein anderes Modul einen Verweis hält (einen Schnittstellenzeiger besitzt), dann besteht das Modul weiter - und der Schnittstellenzeiger bleibt so lange gültig, bis dieser Zeiger auch freigegeben wird.