Unstrukturierte Automatisierungssoftware ist ein organisatorisches Risiko: sie bremst jedes neue Projekt, macht Entwicklerfluktuation teuer und erschwert es, Produktionsvorfälle schnell einzugrenzen, zu erklären und sauber abzuschließen.
- Das Zeugwerk Framework gibt jedem Projekt und jedem Entwickler dieselbe bewährte Struktur. Einarbeitung in Tagen statt Monaten. Serviceeinsätze und Übergaben kosten weniger.
- Das Framework liefert antriebsbasierte Bewegungssteuerung: Schon ab 1-10 Achsen übersteigen die NCMotion-Einsparungen die Framework-Lizenzkosten - und skaliert bis über 100 Achsen im Produktionseinsatz auf einem Standard-Beckhoff-PC.
- Eine Toolchain, ein verantwortliches Team - nur Tools, Entwicklungsunterstützung oder schlüsselfertige Maschine.
- Ab 100 Runtimes wird der vollständige Framework-Quellcode bei jedem Release in Ihr eigenes Git ausgeliefert. Kein Vendor-Lock-in.
Wer das Strukturproblem von Leuten gelöst haben möchte, die es bereits für sich selbst gelöst haben - Zeugwerk ist der richtige Ausgangspunkt.
Der Anruf, den niemand will
„Die Maschine steht. Was ist passiert?"
Ein Entwickler öffnet eine Remoteverbindung zu einem laufenden Produktionssystem. Keine Logdateien. Das einzige Diagnosewerkzeug ist die TwinCAT-Online-Ansicht. Einen Breakpoint setzen ist keine Option - die SPS anhalten heißt die Maschine anhalten. Also liest sich der Entwickler durch einen Sequenz-Funktionsbaustein, den jemand geschrieben hat, der vor zwei Jahren das Unternehmen verlassen hat - auf der Suche nach dem Zustand, in dem die Maschine stehengeblieben ist.
Dieses Szenario spielt sich in der Automatisierung ständig ab. Es ist kein Zeichen von Inkompetenz. Es ist das Fehlen von Struktur.
Warum das immer wieder passiert
Automatisierungssoftware wurde nie als Software Engineering behandelt, sondern wie Verdrahtung.
Das gedankliche Modell, das SPS-Programmierung geprägt hat - Kontaktpläne, direkte I/O-Manipulation, Logik die die physische Schaltanlage spiegelt - wurde für eine andere Ära der Maschinenkomplexität entworfen. Es funktionierte, als eine Maschine dreißig I/O-Punkte hatte und einen Entwickler, der sein ganzes Leben dabei sein würde. Es funktioniert nicht, wenn eine Maschine vierhundert I/O-Punkte hat, ein Motion-System, ein Vision-System und ein Software-Team, das alle paar Jahre wechselt.
Die Branche weiß das. Die meisten Automatisierungstechniker haben es gespürt. Aber Toolchain, Ausbildung und Projektzeitpläne drängen alle in dieselbe Richtung: bringen, ausliefern, weitermachen. Die strukturellen Schulden häufen sich unsichtbar an - bis die Maschine in der Produktion stehenbleibt und niemand den Code schnell genug lesen kann, um das Problem zu beheben.
Woher Zeugwerk kommt
Wir haben Zeugwerk gebaut, weil wir selbst auf der Empfängerseite dieses Problems standen.
Das Framework begann nicht als Produkt. Es begann als die interne Architektur, die wir entwickelt haben, weil wir es satt hatten, Zylinderlogik bei jedem Projekt neu zu implementieren, Entwickler einzuarbeiten, die Monate brauchten um projektspezifische Konventionen zu verstehen, und Code auszuliefern, der bei der Inbetriebnahme funktionierte, den aber niemand - einschließlich uns - zwei Jahre später anfassen wollte.
Die Toolchain drumherum - Creator, Twinpack, DevTools - kam aus derselben Quelle. Jedes Tool existiert, weil wir es brauchten und es nicht gab.
Diese Herkunft ist wichtig, denn sie bedeutet: das Framework wurde auf echten Maschinen validiert, bevor es an irgendjemanden verkauft wurde. Es ist nicht die Methodik eines Beratungsunternehmens. Es ist kein Framework, das von Leuten entworfen wurde, die Automatisierung von außen studiert haben. Es ist die Architektur, die auf den Maschinen eingesetzt wird, die wir heute noch liefern und warten. Team kennenlernen →
Was ein Framework tatsächlich ändert
Ein Framework ist ein Vertrag. Wenn jedes Projekt in Ihrer Organisation derselben Architektur folgt, können Entwickler fremden Code lesen, bestehende Projekte erweitern und neue Kolleginnen und Kollegen in Tagen statt Monaten produktiv machen.
Das Zeugwerk Framework gibt Teams eine definierte Hierarchie - Application, Units, Equipment - die durch das Typsystem erzwungen wird, nicht durch Konvention. State Machines haben einen definierten Lebenszyklus. Sequenzen lesen sich wie geordnete Schrittlisten. Equipment wird aus getesteten Bausteinen instanziiert, nicht aus dem Gedächtnis neu implementiert. Logging schreibt strukturierte Einträge mit Millisekundenauflösung - ohne externe Tools oder Performance-Einbuße.
Der häufigste Einwand: „Wir haben laufenden Code. Wir können nicht alles neu schreiben." Das müssen Sie nicht. Das Framework lässt sich in eine bestehende TwinCAT-Solution integrieren. Sie führen es Unit für Unit ein - neue Funktionalität in der Zeugwerk-Struktur, Legacy-Code unberührt.
Vollständiges technisches Argument →
Warum nicht einfach ein eigenes Framework bauen?
Manche Teams tun das. Es dauert länger als erwartet, kostet mehr als geplant, und produziert etwas, das für das Team funktioniert, das es gebaut hat - und für niemanden sonst.
Ein Framework ist keine Sammlung von Basisklassen. Es ist eine Menge von Entscheidungen - über Hierarchie, State-Machine-Lebenszyklus, Fehlerfortpflanzung, Logging, Simulation, Namenskonventionen - die konsistent getroffen und über Zeit gepflegt werden. Diese Entscheidungen gut zu treffen erfordert, genug Maschinen gebaut zu haben um zu wissen, welche davon wichtig sind. Die Pflege dieser Entscheidungen erfordert dedizierten Aufwand, der mit der Projektlieferung konkurriert.
Die Teams, die eigene Frameworks bauen, enden typischerweise mit etwas, das das unmittelbare Problem löst und ein neues schafft: eine proprietäre Architektur, die neue Entwickler von Grund auf lernen müssen, ohne Dokumentation, ohne Community und ohne jemanden, der dafür verantwortlich ist, sie aktuell zu halten.
Das Zeugwerk Framework wird von dem Team gepflegt, das es auf Live-Projekten einsetzt. Wenn ein neues Antriebsprotokoll gebraucht wird, wird es hinzugefügt. Wenn sich ein Muster als falsch herausstellt, wird es korrigiert.
Warum nicht einfach einen TwinCAT-Contractor engagieren?
Das ist möglich. Ein externer Dienstleister schreibt TwinCAT-Code. Ob dieser Code lesbar, wartbar oder strukturell konsistent mit dem Rest Ihrer Codebasis ist, hängt vollständig davon ab, wen Sie beauftragen und ob Sie die interne Expertise haben, das zu beurteilen.
Das strukturelle Problem in Automatisierungssoftware ist kein Mangel an Leuten, die SPS-Code schreiben können. Es ist ein Mangel an gemeinsamen Standards dafür, wie guter SPS-Code aussieht. Ein Contractor, der ohne Framework arbeitet, trifft dieselben architektonischen Entscheidungen von Projekt zu Projekt, die auch Ihr eigenes Team trifft - und die Ergebnisse sind genauso inkonsistent.
Wenn Zeugwerk Software liefert, ob als eigenständiger Auftrag oder als Teil einer schlüsselfertigen Maschine, wird sie gegen eine definierte Architektur geliefert, die Ihr Team lesen, erweitern und warten kann, nachdem wir den Auftrag beendet haben. Das ist der Unterschied.
Geringere TwinCAT-Lizenzkosten
Ein Designziel des Zeugwerk Frameworks ist es, die Anzahl der TwinCAT-Zusatzlizenzen zu reduzieren, die eine Maschine benötigt. TwinCAT überzeugt mit seinem modularen Lizenzmodell - aber genau diese Modularität bedeutet, dass sich die Kosten über viele Runtimes hinweg schnell summieren können. Wo das Framework eine Funktionalität direkt abdeckt, muss sie nicht separat bei Beckhoff lizenziert werden.
Bewegungssteuerung ist das am einfachsten quantifizierbare Beispiel. TwinCAT NC/PTP (NCMotion) ist eine Zusatzlizenz, die pro Runtime und gestaffelt nach Achsanzahl sowie Plattformstufe berechnet wird - und bei Maschinen mit höherer Achsanzahl oder Leistungsstufe summieren sich diese Kosten schnell. Eine Zeugwerk-Framework-Lizenz im Tier 1-25 Runtimes kostet 434 € pro Runtime pro Runtime. Eine einzelne Maschine mit antriebsbasierter Bewegungssteuerung kann allein durch eingesparte NCMotion-Lizenzen mehr einsparen, als die gesamte Framework-Lizenz kostet.
Das Framework liefert Bibliotheken, die Servoantriebe und EtherCAT-Schrittmotorklemmen direkt über deren bordeigene Motion-Controller ansteuern - ohne NCMotion-Task. Technische Details →
Die Hardwarekosten sinken mit. Ein breiteres Spektrum an Antrieben und Klemmen kommt in Frage - nicht nur solche, die eng mit NCMotion verzahnt sind, und in der Regel zu geringeren Stückkosten. Und weil die Bewegungsberechnung im Antrieb verbleibt, läuft der PLC auf einem Industrie-PC mit niedrigerer Plattformstufe.
Zeugwerk betreibt produktive Maschinen mit mehr als 100 Achsen auf einem einzigen High-Performance-PC der Plattformstufe 80 - ohne eine einzige NCMotion-Lizenz.
Wenn Sie die Maschine brauchen, nicht nur die Werkzeuge
Das Framework gibt Ihnen die Bausteine für bessere Maschinen. Aber manche Projekte beginnen mit einer anderen Frage: „Wer baut die Maschine?"
Gemeinsam mit unseren Engineering-Partnern Plötzeneder GmbH und Hinstech GmbH liefert Zeugwerk schlüsselfertige Maschinen aus einer Hand: Mechanik, Elektrik und Software. Keine Übergabeverluste zwischen Disziplinen. Kein gegenseitiges Schuldzuweisen, wenn etwas nicht passt. Ein Team, das den gesamten Leistungsumfang verantwortet.
Was die Partnerschaft abdeckt:
- Maschinenbau und Prozessentwicklung: Die Plötzeneder GmbH entwickelt und baut seit 1977 Sondermaschinen mit besonderer Erfahrung in der Pharma- und Medtechbranche. Sie verantwortet den mechanischen Leistungsumfang vom ersten Konzept bis zur fertigen Fertigungsdokumentation.
- Elektrotechnik und CE-Konformität - Die Hinstech GmbH übernimmt Hardwaredesign, Schaltpläne, Schaltschrankbau und CE-Konformitätsbewertung. Die gelieferte Maschine ist sicher, dokumentiert und vom ersten Tag an CE-konform.
- Automatisierungssoftware - Zeugwerk liefert die SPS-Applikation auf Basis des eigenen Frameworks. Strukturierter, getesteter und dokumentierter Code - keine Einwegprojektlösung, sondern Software, die Ihr Serviceteam auch nach der Übergabe warten und erweitern kann.
Die drei Disziplinen arbeiten von einer gemeinsamen Projektdefinition aus. Mechanische Schnittstellen sind definiert, bevor die elektrische Verlegung beginnt. Die elektrische Topologie ist bekannt, bevor Software-I/O-Listen geschrieben werden. Änderungen laufen durch ein koordiniertes Team - nicht über drei separate Posteingänge.
Als zertifizierter Beckhoff Solution Provider bleibt die Software im etablierten Beckhoff-Ökosystem. Standardlizenzierung. Standardwerkzeugkette. Keine exotischen Abhängigkeiten, die Ihre Serviceorganisation noch nie gesehen hat.
Sprechen Sie mit uns über Ihr Projekt →
Was Kunden erfahren haben
Durch die Einführung von modernen Software-Paradigmen wurde die team- und projektübergreifende Software-Erstellung erst sinnvoll möglich, was für uns völlig neue Perspektiven hinsichtlich Weiterentwicklung und Nachnutzung jedes einzelnen Software-Projektes eröffnete!
— Edmund Jenner · Nordfels GmbH
Die Einführung des Zeugwerk-Frameworks kam für uns genau zum richtigen Zeitpunkt. So konnten wir unsere standortübergreifenden Harmonisierungsbestrebungen erheblich beschleunigen. Insbesondere für die Projektierung unserer Serienmaschinen, die aus ähnlichen Maschinenelementen in verschiedenen Varianten gefertigt werden, bietet das Framework unschätzbare Vorteile bei der Umsetzung.
— Josef Unterrainer · Development Department · Durst Group
Warum Zeugwerk
Das strukturelle Problem in der Automatisierungssoftware ist real, gut verstanden und weitgehend ungelöst - nicht weil die Lösung schwer zu beschreiben wäre, sondern weil sie eine nachhaltige Investition erfordert, die sich die meisten Teams nicht Projekt für Projekt leisten können.
Es ist keine Methodik, die von Leuten verkauft wird, die Automatisierung von außen betrachten. Es ist eine Architektur, die von dem Team gepflegt wird, das sie noch heute auf realen Maschinen einsetzt - und das noch immer mit den Konsequenzen leben muss, wenn etwas nicht stimmt.
Kurz zusammengefasst
Meistens treffen bei uns mehrere dieser Bedarfe gleichzeitig zu statt eines einzelnen Klischees. Wenn Sie unsicher sind, wo Sie landen, melden Sie sich - dann ordnen wir es gemeinsam.
60-Tage-Testversion herunterladen → Dokumentation lesen → Unsere Dienstleistungen → Kontakt aufnehmen →