Fertigung

Wie arbeiten wir als Engineering-Dienstleister für OEMs?

Als Engineering-Dienstleister für OEMs arbeiten wir als externes Entwicklungsteam für ein Produktprogramm.

Unsere Kunden sind Maschinenbauer, Modulhersteller und Chiphersteller in der industriellen Automatisierung. Produkt und Kunde bleiben bei Ihnen; wir übernehmen die Teile, die dauerhaftes Spezialwissen brauchen:

• Firmware, Middleware und Anwendungen, ohne Betriebssystem, auf einem RTOS, unter Linux oder Windows
• Integration von Echtzeit-Ethernet und Feldbus, mit einem Open-Source-Stack oder einem kommerziellen, den Sie schon lizenzieren
• Gerätetreiber, Board Support Packages und die Echtzeitoptimierung, mit der sie einen Zyklus halten
• Obsoleszenzbewertung und Neuentwurf, wenn ein Teil abgekündigt wird
• eigene E/A-Geräte, Steuerungsknoten, Gateways und Netzwerk-Master, wo ein Standardteil nicht reicht
• Vorzertifizierung und Unterstützung bei der Konformität, bis zum Zertifikat, aber ohne das Zertifikat selbst
• Schulung Ihrer Ingenieure, gemeinsamer Aufbau der ersten Implementierung und danach Third-Level-Support, während Ihr Team den First-Level-Support leistet
• die IIoT-Ebene, die das Ergebnis in ein Netz oder in die Systeme eines Kunden bringt

Die meisten Projekte beginnen abgegrenzt: ein Protokoll, eine Baugruppe oder eine Migration. Hat sich die Zusammenarbeit bewährt, wird daraus ein dauerhaft beauftragtes Team. Die Seite zur Zusammenarbeit beschreibt die Formen der Zusammenarbeit und wie sie abgerechnet werden.

Der Druck ist ähnlich, wo immer Sie in dieser Kette stehen: ein Produkt auszuliefern, das in drei Jahren noch aktuell wirkt, ohne jedes nötige Spezialgebiet im eigenen Haus aufzubauen.

Warum braucht ein Maschinenbauer so viele Protokolle?

Die Maschine wird in mehr als einen Markt verkauft, und jeder Markt hat sich auf eine andere Schnittstelle festgelegt.

Von einer Maschine für die DACH-Region wird meist PROFINET erwartet, von derselben Maschine für Nordamerika meist EtherNet/IP. EtherCAT taucht überall dort auf, wo die Bewegung eng koordiniert ist, Ethernet POWERLINK dort, wo der Maschinenbauer beide Enden der Linie liefert und einen Open-Source-Stack möchte, und ein wachsender Teil der Käufer fragt nach OPC UA zusätzlich zu einem davon.

Diese Bandbreite im eigenen Haus abzudecken heißt, drei oder vier Spezialgebiete für Arbeit zu besetzen, die nur gelegentlich anfällt, und jedes hat seinen eigenen Konformitätszyklus. Ein großer Teil unserer OEM-Arbeit füllt genau diese Lücke: Wir tragen die Protokollvarianten und den Prüfzyklus, und Ihre Ingenieure bleiben an der Maschine.

Bei welchen Teilen der Arbeit können Sie unterstützen?

Bei jedem Spezialgebiet im Produkt: einer Protokollvariante, einem Knoten, einem Treiber, einem abgekündigten Teil, einem Konformitätsdurchlauf.

• Eine Protokollvariante. Ihr Team hat sie nicht. Ein Markt öffnet sich, der Käufer erwartet eine Schnittstelle, die Sie nie ausgeliefert haben, und dafür einzustellen steht in keinem Verhältnis zur Arbeit. Wir ergänzen die Variante in Ihrem vorhandenen Produkt und bringen sie durch den Prüfzyklus.
• Ein Knoten in der Maschine eines anderen. Ein Gerät, das in einem Netz korrekt erscheinen muss, das ihm nicht gehört: Slave an einem Bus, manchmal Master einer Unterebene darunter, oft mit einer Brücke zu UART, I²C, CAN oder einem seriellen Instrument auf der anderen Seite. Beide Muster zeigen die Seiten zu Verpackungsmaschinen und Materialfluss und Intralogistik im Zusammenhang.
• Eine Schnittstelle für Antrieb oder Drehgeber. Ein Komponentenhersteller, dessen Teil als Slave mit geringem Ressourcenbedarf an Echtzeit-Ethernet erscheinen soll, oder eine Zelle, deren koordinierte Bewegung von der Ebene darüber erreichbar sein muss.
• Ein abgekündigtes Teil. Eine Abkündigung für ein Bauteil in einem Produkt, das noch verkauft wird, und die Entscheidung, wie viel des Entwurfs mitwandern muss.
• Ein Gerät vor der Konformitätsprüfung. Vorbereitung, Testdurchläufe im eigenen Labor mit den Testsuiten und Unterstützung bis zur Einreichung beim akkreditierten Labor.
• Ein Gerät, das gebaut werden muss. Ein eigenes E/A-Gerät, ein Steuerungsknoten, ein Gateway oder ein Netzwerk-Master, aufgebaut von der Portierung des Stacks und der Inbetriebnahme der Baugruppe an, nicht ein angepasster Referenzentwurf.
• Aufbau Ihres Teams. Ihre eigenen Ingenieure werden eingearbeitet: Schulung auf dem Protokoll oder der Plattform, dann gemeinsamer Entwurf und Aufbau der ersten Implementierung, damit das Wissen bei Ihrem Team bleibt. Danach übernehmen wir den Third-Level-Support, während Ihr Team den First-Level-Support leistet.
• Kapazität für Validierung und CI. Ingenieure, die Ihr Validierungsteam verstärken, oder die Test- und CI-Pipeline, die Testsuiten, Regressionstests und Zeitprüfungen bei jedem Build ausführt und nicht erst beim Release.
• Eine Produktlinie, die Daten liefert. Eine installierte oder neue Maschine, die eine Sicht auf sich selbst über OPC UA oder MQTT braucht, für MES, ERP oder Serviceplattform eines Kunden.

Die folgenden Abschnitte behandeln die vier dieser Punkte, zu denen die meisten Fragen kommen.

Wie kommt ein Stack durch die Konformitätsprüfung?

Konformität wird vom Beginn der Arbeit an als Prozess geführt und nicht am Ende als Ereignis behandelt.

Wir bereiten das Gerät vor, führen die Testsuiten des Herstellers im eigenen Labor mit den Konfigurationen aus, die das Zertifikat abdecken wird, beheben, was sie zutage fördern, und unterstützen die Einreichung. Das Zertifikat selbst stellt das akkreditierte Prüflabor der Protokollorganisation aus. Kein Entwicklungsdienstleister stellt es aus, auch wir nicht. Unser Team hat Ethernet POWERLINK, PROFINET und PROFIBUS auf mehreren Chipfamilien durch diesen Zyklus gebracht, für Chiphersteller und für Maschinenbauer: FPGA-Familien mit dem Master unter Windows, Linux und ohne Betriebssystem; eine Familie von Anwendungsprozessoren, für die der Hersteller schon einen Controlled Node auslieferte und wir den Managing Node auf Echtzeit-Linux portiert haben; einen industriellen Kommunikations-IC; und eine PROFIBUS-Schnittstelle an einem Druckmessumformer, also dieselbe Disziplin an einem einzelnen Instrument statt an einer Steuerung. Die Arbeit an PROFIBUS und PROFINET wurde in einem von PI akkreditierten Labor geprüft. Die Arbeit an POWERLINK nutzte openPOWERLINK, nichts am Ergebnis war also an uns gebunden.

Die Konfigurationen sagen mehr über einen Stack als das Zertifikat. Wir prüfen bis 250 µs mit 3 bis 10 Knoten bei 32 Byte Prozessdaten je Knoten, 1 ms mit 10 bis 20 Knoten bei 64 bis 128 Byte und 5 ms mit 30 Knoten bei 128 bis 256 Byte. Welche davon ein bestimmter Baustein erreicht, hängt vom Chip ab und davon, ob der Master ohne Betriebssystem, auf dem RTOS eines Herstellers oder auf Echtzeit-Linux läuft.

Was machen Sie auf der Antriebs- und Bewegungsseite?

Wir integrieren auf Komponentenseite, entwickeln Motorsteuerungen und bauen die Gateway-Ebene über dem eigenen System eines Antriebsherstellers.

• Integration auf Komponentenseite. Optische Drehgeber, als Slaves mit geringem Ressourcenbedarf an Echtzeit-Ethernet und Feldbus gebracht, für einen Drehgeberhersteller, dessen Teile in Textil-, Verpackungs-, Aufzugs- und Inkjet-Druckmaschinen eingebaut werden.
• Motorsteuerung. Über POWERLINK und PROFINET auf einem industriellen Kommunikations-IC, bis zu einem funktionierenden Machbarkeitsnachweis.
• Sercos und die Ebene darüber. Die Integration von Sercos-Slaves bleibt beim Antriebshersteller; es ist ein vertikales Ökosystem, und dort gehört sie hin. Bei einer Robotersteuerung mit einem Sercos-Servosystem war unsere Arbeit die Ebene darüber: das Gateway und das OPC-UA-Informationsmodell, mit denen die Zelle von außen lesbar und koordinierbar wurde, dazu die Interoperabilitätsdemonstration über TSN, die das belegt hat. Diese Form aus Edge und Gateway ist typisch für unsere Arbeit in Antriebsökosystemen.

Was passiert, wenn ein Teil abgekündigt wird?

Wir bewerten zuerst das Teil und klären dann den Umfang von Ersatz oder Migration.

Eine Abkündigung kommt für ein Produkt, das sich bestens verkauft, und die Frage ist, wie viel des Entwurfs mitwandern muss. Manchmal genügt ein direkter Ersatz mit einer Treiberänderung. Manchmal hat das Ersatzteil andere Peripherie, und die Firmware muss darum herum überarbeitet werden. Diese Bewertung macht aus der Entscheidung eine abgegrenzte Entwicklungsaufgabe. Wie diese Arbeit abläuft, beschreibt die Seite zum Obsoleszenzmanagement. Drei Formen, die sie bei uns hatte:

• Ein abgekündigtes Gerät eines Drittanbieters zur Signalerfassung, ersetzt durch eine Baugruppe mit 40 analogen Eingangskanälen, jeder Kanal dreifach differenziell vervielfältigt und an BNC-Buchsen für das Oszilloskop sowie an ein nachgelagertes Modul ausgegeben, mit erhaltenem Signal-Rausch-Abstand, erhaltener Signalintegrität und Polarität.
• Die Migration einer FPGA-Familie über eine ganze Baugruppenfamilie für einen Hersteller von Verpackungs- und Lebensmittelmaschinen, mit der Steuerung von Sensoren, Aktoren und Automatisierungsnetz auf einem aktuellen Baustein.
• Eine abgekündigte SPS samt ihrer Software auf eCos-Basis, ersetzt durch eine Zynq-Plattform mit Echtzeit-Linux und einer Soft-SPS-Runtime nach IEC 61131-3, die mit Geräten, die an ihrem Platz blieben, über PROFIBUS spricht.

Es gibt weitere. Diese drei zeigen die Bandbreite, von einer neuen Baugruppenrevision bis zu einer Steuerung samt Runtime, die unter einer laufenden Linie ersetzt wird.

Lässt sich IIoT in eine Produktlinie nachrüsten, die schon im Feld ist?

Meist ja, und ohne die Steuerungslogik anzufassen.

Eine installierte Maschine, die schon über einen Feldbus oder einen Diagnoseanschluss meldet, kann über ein Gateway eine Sicht auf sich selbst über OPC UA oder MQTT bekommen. Das ist eine weit kleinere Änderung als ein Umbau der Steuerungsarchitektur. Bei Maschinen, die noch auf dem Reißbrett stehen, ist es günstiger, die Schnittstelle von Anfang an einzuplanen. Beide Wege beschreibt die Seite zu Industrial IoT.

Wie entstehen Leistungsdaten, die die Ingenieure eines Kunden prüfen können?

Wir erzeugen sie während der Integration, sodass die Ingenieure, die die Arbeit gemacht haben, die Zahlen schreiben.

Zwei davon sind als eigenes technisches Material der Hersteller erschienen:

• TSN in einem OPC-UA-Stack. Wir haben TSN in einen Open-Source-Stack integriert und die Benchmarks dazu gefahren.
• OPC UA auf einem TSN-Chip. Dieselbe Arbeit von der anderen Seite, auf der eigenen TSN-Lösung eines Chipherstellers.

Daten, die von den Ingenieuren der Integration geschrieben wurden, sind etwas anderes als Marketingtext, und für einen Modul- oder IC-Hersteller sind sie oft das, was ein Design-in tatsächlich voranbringt.