„Siehe, sie sind ein Volk und nur eine Sprache haben sie alle“ (Genesis 11, 6). So weit, so gut. Aber: Schon im nächsten Vers findet der Herr plötzlich Gefallen daran, die Sprache der Menschen zu verwirren – als Strafe für den menschlichen Geltungsdrang. Die babylonische Sprachverwirrung ward geboren, der Turmbau zu Babel scheiterte. Wenn Uwe Steinkrauß, Executive Director der ascolab GmbH im Innovations- und Gründerzentrum Nürnberg-Fürth-Erlangen (IGZ), Laien vor sich hat und ihnen in Kürze erklären will, was seine Firma ausmacht – „Was wir machen, sieht man nicht“ –, greift er gerne zum Alten Testament und Pieter Bruegels d. Ä. gemeinhin bekanntem Gemälde „Der Turmbau zu Babel“ (1563).
„Interpretieren Sie das Bild ruhig als Synonym für die Situation in der Automatisierungstechnik“, so Steinkrauß, „Die verschiedenen Sprachen und Protokolle der einzelnen Automatisierungskomponenten stellen die Industrie vor die gleichen Probleme wie damals die Sprachenvielfalt die Babylonier: Keiner versteht mehr den anderen.” Die Systeme unterschiedlicher Hersteller können oftmals nicht oder nur mit erheblichem Aufwand miteinander kommunizieren. Beispiel Automobilindustrie: Förderband, Montage-, Schweiß- und Lackierroboter ... – wo man auch hinschaut, Fertigungsgeräte und -systeme, die von verschiedensten Herstellern kommen, die alle ihre eigene Sprache sprechen, die aber trotzdem ständig miteinander kommunizieren und Daten untereinander austauschen müssen.
Für Steinkrauß hat der automatisierungstechnische Turm zu Babel drei Etagen: „Das Erdgeschoss mit der so genannten Feldebene, wo es – meist in Echtzeit – um sehr, sehr schnelle Kommunikation geht. Im ersten Stock befindet sich dann die Produktionsebene, wo wir zu den PCs und Bedienpanels kommen. Auf dieser Ebene geht es darum, zu visualisieren, was im Erdgeschoss passiert. Darüber, im zweiten Stock haben wir dann die Unternehmens- und Leitstandebene, wo ich nicht mehr sehe, was unten passiert, sondern nur noch das Endergebnis.“ Signale und Messwerte im Erdgeschoss, Microsoft Windows-Applikationen im ersten Stock und darüber schließlich Oracle, SAP und Co. in der zweiten Etage – so könnte es der IT-interessierte Laie für sich zusammenfassen.
Wer im Treppenhaus wohnt, tut sich schwer, seine Wohnung zu zeigen. Und Steinkrauß lebt mit der ascolab GmbH genau im Treppenhaus zwischen Erdgeschoss und ersten Stock. Diesen Teil des Turms, so heißt es hinter vorgehaltener Hand, kennt in Europa niemand besser als das vierköpfige ascolab-Team. Hier wohnt der Schnittstellen-Babelfisch der Automatisierungstechnik für die Kommunikation zwischen Erdgeschoss und erstem Stock, zwischen den Signalen und Messwerten auf der Feldebene und deren Visualisierung auf Windows-PCs. Steinkrauß aber widerspricht – und verweist erst einmal auf die Rolle der OPC Foundation. „1996 gründeten die großen Hersteller in der Automatisierungstechnik die OPC Foundation – mit dem Ziel, mit der OPC-Schnittstelle einen Standard für die Anschaltung verschiedenster Geräte auf der Feldebene der Automatisierungstechnik an Windows-Systeme zu etablieren.“
Mittlerweile gehören über 350 Hersteller der OPC Foundation an. Die OPC Foundation ist damit die am schnellsten wachsende Organisation, die es je in der Automatisierungsbranche gab. Mehr als 3.000 Produkte mit OPC-Schnittstelle sind mittlerweile am Markt verfügbar. Innerhalb von nur fünf Jahren konnte sich OPC als der unangefochtene Standard zwischen der Feldebene im Erdgeschoss und einer Visualisierung in der ersten Windows-Etage durchsetzen – ein für die Verhältnisse in der Automatisierungstechnik enorm schneller Durchbruch angesichts der langen Investitions- und Innovationszyklen.
Wesentlichen Anteil am schnellen Durchbruch von OPC dürfte auch die Zertifizierungsstrategie gehabt haben: Hersteller, die ihre Geräte mit einer OPC-Schnittstelle ausstatten möchten, können auf ein kostenfreies Softwaretool der OPC Foundation zurückgreifen, das Funktion für Funktion aufruft, jeden Rückgabewert überprüft und so vollständig die Schnittstellenkonformität testet. „Wer sich mit Programmierung auskennt, weiß: So eine Software ist ein Moloch, eine echte Sisyphusarbeit.“ Steinkrauß muss es wissen, denn: Der Zuschlag zur Entwicklung der Software ging an die ascolab GmbH. Und: Mit einem solchen Job wird man schnell zum Nabel der Welt auf der OPC-Landkarte. Wer sonst – außer den Programmierern der Testsoftware für eine Zertifizierung – steht schon vor der Aufgabe, die volle Bandbreite einer Spezifikation zu nutzen? Steinkrauß: „Das führt manchmal auch zur Fehlinterpretation, wir wären eine offizielle Zertifizierungsstelle. Das sind wir aber nicht. Allerdings dürften wir in der Tat in Europa das Unternehmen mit dem größten Know-how in Sachen OPC sein.“ Bei Verständigungsschwierigkeiten werden die Erlanger gern um Rat gefragt; die weltweite Programmierelite der Automatisierungstechnik gibt sich hier schon mal die Klinke in die Hand. „Dazu könnte ich Ihnen jetzt doch was zeigen“, fällt Steinkrauß ein. Den großen Konferenzraum des IGZ. Mitte September 2004 saßen dort für mehrere Tage die Softwarearchitekten der weltgrößten Hersteller, diskutierten auf Einladung von Siemens und ascolab wie sich die Zukunft der Automatisierung in den nächsten fünf Jahren verändern wird.
Solche Treffen wie dieses erste Unified Architecture Workgroup-Meeting in Europa sind keine Kaffeekränzchen. Nichts weniger als der Bauplan für die Kommunikation in der Automatisierungstechnik in den nächsten Jahren wird auf solchen Treffen skizziert und verabschiedet. Denn der Turm zu Babel ist eine Dauerbaustelle: Auf der Feldebene werden die Steuerungen immer mächtiger, vermögen Dinge zu verrichten, die früher dem ersten Stock vorbehalten waren. Mit dem Siegeszug des Internets kommt gleichzeitig auf allen drei Ebenen neues Baumaterial mit ins Spiel – und warum nicht darüber diskutieren, ob es sich lohnt, über die OPC-Schnittstelle einen Blick in Zimmer ohne Windows oder in das zweite Stockwerk zu werfen? Technik bleibt nicht stehen, ist nie statisch.
Steinkrauß: „Der Industrie ist es mit der OPC-Schnittstelle gelungen, in sehr kurzer Zeit ein Esperanto für die herstellerübergreifende Kommunikation zwischen der Feld- und der PC-basierten Visualisierungsebene in der Automatisierungstechnik zu etablieren. Im Weiteren geht es jetzt darum, dass der Wortschatz mit der technologischen Weiterentwicklung Schritt hält und dass man schaut, welcher Grammatik und welcher Wörter es bedarf, um vielleicht auch über den bisherigen Horizont hinaus kommunizieren zu können. Mit ascolab erstellen wir zwar weder dieses Wörterbuch noch die Grammatik, das ist Aufgabe der Foundation. Aber wir sind über unsere Mitgliedschaft in den Arbeitskreisen der Foundation und unsere Tätigkeit in der Pflege der Testsoftware für die Zertifizierungen immer direkt an der Quelle, was neue Entwicklungen und Know-how angeht.“
Bleibt die Frage: Von was lebt ein Unternehmen, an deren Testsoftware in der Automatisierungstechnik zwar praktisch kein Weg vorbeiführt – eine Software aber, die über die OPC Foundation den Entwicklern kostenfrei zur Verfügung gestellt wird? Wer an Lizenzgebühren denkt, liegt falsch. Auch die Pflege des Tools wirft nicht solche Erträge ab, dass man davon leben könnte. Steinkrauß: „Unser Ruf im Markt speist sich gewiss in ganz erheblichem Maße aus unserer Arbeit für die OPC Foundation, aus unserer Arbeit an der Testsoftware für die Zertifizierung und unserer Arbeit in den Arbeitskreisen. Umsatz- und ertragsmäßig aber macht dieses Foundation-nahe Geschäft heute nicht einmal zwanzig Prozent aus. Geld verdient ascolab mit Entwicklung, IT-Beratung und Services; etwa mit Machbarkeitsstudien und Projektierungsleistungen. Hier, und das können wir ohne Übertreibung sagen, zählen wir zu den allerersten Adressen, an die sich in Europa die Hersteller in der Automatisierungstechnik bei OPC-spezifischen Aufgaben- und Fragestellungen wenden.”
„Interpretieren Sie das Bild ruhig als Synonym für die Situation in der Automatisierungstechnik“, so Steinkrauß, „Die verschiedenen Sprachen und Protokolle der einzelnen Automatisierungskomponenten stellen die Industrie vor die gleichen Probleme wie damals die Sprachenvielfalt die Babylonier: Keiner versteht mehr den anderen.” Die Systeme unterschiedlicher Hersteller können oftmals nicht oder nur mit erheblichem Aufwand miteinander kommunizieren. Beispiel Automobilindustrie: Förderband, Montage-, Schweiß- und Lackierroboter ... – wo man auch hinschaut, Fertigungsgeräte und -systeme, die von verschiedensten Herstellern kommen, die alle ihre eigene Sprache sprechen, die aber trotzdem ständig miteinander kommunizieren und Daten untereinander austauschen müssen.
Für Steinkrauß hat der automatisierungstechnische Turm zu Babel drei Etagen: „Das Erdgeschoss mit der so genannten Feldebene, wo es – meist in Echtzeit – um sehr, sehr schnelle Kommunikation geht. Im ersten Stock befindet sich dann die Produktionsebene, wo wir zu den PCs und Bedienpanels kommen. Auf dieser Ebene geht es darum, zu visualisieren, was im Erdgeschoss passiert. Darüber, im zweiten Stock haben wir dann die Unternehmens- und Leitstandebene, wo ich nicht mehr sehe, was unten passiert, sondern nur noch das Endergebnis.“ Signale und Messwerte im Erdgeschoss, Microsoft Windows-Applikationen im ersten Stock und darüber schließlich Oracle, SAP und Co. in der zweiten Etage – so könnte es der IT-interessierte Laie für sich zusammenfassen.
Wer im Treppenhaus wohnt, tut sich schwer, seine Wohnung zu zeigen. Und Steinkrauß lebt mit der ascolab GmbH genau im Treppenhaus zwischen Erdgeschoss und ersten Stock. Diesen Teil des Turms, so heißt es hinter vorgehaltener Hand, kennt in Europa niemand besser als das vierköpfige ascolab-Team. Hier wohnt der Schnittstellen-Babelfisch der Automatisierungstechnik für die Kommunikation zwischen Erdgeschoss und erstem Stock, zwischen den Signalen und Messwerten auf der Feldebene und deren Visualisierung auf Windows-PCs. Steinkrauß aber widerspricht – und verweist erst einmal auf die Rolle der OPC Foundation. „1996 gründeten die großen Hersteller in der Automatisierungstechnik die OPC Foundation – mit dem Ziel, mit der OPC-Schnittstelle einen Standard für die Anschaltung verschiedenster Geräte auf der Feldebene der Automatisierungstechnik an Windows-Systeme zu etablieren.“
Mittlerweile gehören über 350 Hersteller der OPC Foundation an. Die OPC Foundation ist damit die am schnellsten wachsende Organisation, die es je in der Automatisierungsbranche gab. Mehr als 3.000 Produkte mit OPC-Schnittstelle sind mittlerweile am Markt verfügbar. Innerhalb von nur fünf Jahren konnte sich OPC als der unangefochtene Standard zwischen der Feldebene im Erdgeschoss und einer Visualisierung in der ersten Windows-Etage durchsetzen – ein für die Verhältnisse in der Automatisierungstechnik enorm schneller Durchbruch angesichts der langen Investitions- und Innovationszyklen.
Wesentlichen Anteil am schnellen Durchbruch von OPC dürfte auch die Zertifizierungsstrategie gehabt haben: Hersteller, die ihre Geräte mit einer OPC-Schnittstelle ausstatten möchten, können auf ein kostenfreies Softwaretool der OPC Foundation zurückgreifen, das Funktion für Funktion aufruft, jeden Rückgabewert überprüft und so vollständig die Schnittstellenkonformität testet. „Wer sich mit Programmierung auskennt, weiß: So eine Software ist ein Moloch, eine echte Sisyphusarbeit.“ Steinkrauß muss es wissen, denn: Der Zuschlag zur Entwicklung der Software ging an die ascolab GmbH. Und: Mit einem solchen Job wird man schnell zum Nabel der Welt auf der OPC-Landkarte. Wer sonst – außer den Programmierern der Testsoftware für eine Zertifizierung – steht schon vor der Aufgabe, die volle Bandbreite einer Spezifikation zu nutzen? Steinkrauß: „Das führt manchmal auch zur Fehlinterpretation, wir wären eine offizielle Zertifizierungsstelle. Das sind wir aber nicht. Allerdings dürften wir in der Tat in Europa das Unternehmen mit dem größten Know-how in Sachen OPC sein.“ Bei Verständigungsschwierigkeiten werden die Erlanger gern um Rat gefragt; die weltweite Programmierelite der Automatisierungstechnik gibt sich hier schon mal die Klinke in die Hand. „Dazu könnte ich Ihnen jetzt doch was zeigen“, fällt Steinkrauß ein. Den großen Konferenzraum des IGZ. Mitte September 2004 saßen dort für mehrere Tage die Softwarearchitekten der weltgrößten Hersteller, diskutierten auf Einladung von Siemens und ascolab wie sich die Zukunft der Automatisierung in den nächsten fünf Jahren verändern wird.
Solche Treffen wie dieses erste Unified Architecture Workgroup-Meeting in Europa sind keine Kaffeekränzchen. Nichts weniger als der Bauplan für die Kommunikation in der Automatisierungstechnik in den nächsten Jahren wird auf solchen Treffen skizziert und verabschiedet. Denn der Turm zu Babel ist eine Dauerbaustelle: Auf der Feldebene werden die Steuerungen immer mächtiger, vermögen Dinge zu verrichten, die früher dem ersten Stock vorbehalten waren. Mit dem Siegeszug des Internets kommt gleichzeitig auf allen drei Ebenen neues Baumaterial mit ins Spiel – und warum nicht darüber diskutieren, ob es sich lohnt, über die OPC-Schnittstelle einen Blick in Zimmer ohne Windows oder in das zweite Stockwerk zu werfen? Technik bleibt nicht stehen, ist nie statisch.
Steinkrauß: „Der Industrie ist es mit der OPC-Schnittstelle gelungen, in sehr kurzer Zeit ein Esperanto für die herstellerübergreifende Kommunikation zwischen der Feld- und der PC-basierten Visualisierungsebene in der Automatisierungstechnik zu etablieren. Im Weiteren geht es jetzt darum, dass der Wortschatz mit der technologischen Weiterentwicklung Schritt hält und dass man schaut, welcher Grammatik und welcher Wörter es bedarf, um vielleicht auch über den bisherigen Horizont hinaus kommunizieren zu können. Mit ascolab erstellen wir zwar weder dieses Wörterbuch noch die Grammatik, das ist Aufgabe der Foundation. Aber wir sind über unsere Mitgliedschaft in den Arbeitskreisen der Foundation und unsere Tätigkeit in der Pflege der Testsoftware für die Zertifizierungen immer direkt an der Quelle, was neue Entwicklungen und Know-how angeht.“
Bleibt die Frage: Von was lebt ein Unternehmen, an deren Testsoftware in der Automatisierungstechnik zwar praktisch kein Weg vorbeiführt – eine Software aber, die über die OPC Foundation den Entwicklern kostenfrei zur Verfügung gestellt wird? Wer an Lizenzgebühren denkt, liegt falsch. Auch die Pflege des Tools wirft nicht solche Erträge ab, dass man davon leben könnte. Steinkrauß: „Unser Ruf im Markt speist sich gewiss in ganz erheblichem Maße aus unserer Arbeit für die OPC Foundation, aus unserer Arbeit an der Testsoftware für die Zertifizierung und unserer Arbeit in den Arbeitskreisen. Umsatz- und ertragsmäßig aber macht dieses Foundation-nahe Geschäft heute nicht einmal zwanzig Prozent aus. Geld verdient ascolab mit Entwicklung, IT-Beratung und Services; etwa mit Machbarkeitsstudien und Projektierungsleistungen. Hier, und das können wir ohne Übertreibung sagen, zählen wir zu den allerersten Adressen, an die sich in Europa die Hersteller in der Automatisierungstechnik bei OPC-spezifischen Aufgaben- und Fragestellungen wenden.”
