Companion Specifications —
schon fertig. Sie schreiben Geschäftslogik.
20+ Companion Specifications als typisierte .NET-Klassen — Machinery, Robotics, MachineTool, PackML und mehr. Spec-konform, versioniert, modellierbar,
mit einem Import einsatzbereit.
Die Spec kommt als Paket.
Sie schreiben, was Sie damit tun.
Drei Szenarien aus der Praxis — vom Machinery-Server über den MachineTool-Client bis zur dynamischen Instanziierung aus Ihrer eigenen NodeSet-Vorlage.
// Machinery server (OPC 40001-1) — spec included out of the box
// NuGet: Opc.UaFx.Advanced.Machinery
using Opc.UaFx;
using Opc.UaFx.Machinery;
// No NodeSet handling — OpcMachineryServer brings the spec along
using var server = new OpcMachineryServer();
server.Start();
// Your machines: typed Identification (compiler-checked)
var cnc = new MyMachineNode(name: "CNC-042");
cnc.Identification.Manufacturer.Value = "Acme Werkzeugbau GmbH";
cnc.Identification.SerialNumber.Value = "SN-2026-042";
cnc.Identification.YearOfConstruction.Value = 2026;
cnc.Identification.ProductInstanceUri.Value = "urn:acme:cnc-042";
Machinery ohne NodeSet-Boilerplate — Spec ist im Server.
Der OpcMachineryServer bringt das Machinery-NodeSet (OPC 40001-1) samt Basisstandards (DI) ab Werk mit — kein manuelles OpcNodeSet.Load(...), kein Nachziehen bei Spec-Updates. Ihre Maschinen-Nodes bekommen typisierte Property-Zugriffe: machine.Identification.Manufacturer, SerialNumber, YearOfConstruction, ProductInstanceUri — jeder Zugriff Compiler-geprüft.
// MES: send a new job order to a machine (typed)
// NuGet: Opc.UaFx.Advanced.ISA95.JobControl
using Opc.UaFx;
using Opc.UaFx.Client;
using Opc.UaFx.ISA95.JobControl;
using var client = new OpcClient("opc.tcp://cnc-5x-01:4840");
client.Connect();
// Build the job order as a typed C# object
var jobOrder = new OpcISA95JobOrder
{
JobOrderID = "JO-2026-042",
StartTime = DateTime.UtcNow,
Priority = 5,
JobOrderParameters = new[] {
new OpcISA95Parameter { ID = "Material", Value = "AlMg3" },
new OpcISA95Parameter { ID = "Losgröße", Value = 42 },
},
};
// Hand it to the machine's JobOrderReceiver
client.CallMethod(receiverObjectId, storeAndStartMethodId, jobOrder);
MES-Integration ab Werk — Job Orders als typisierte C#-Objekte.
Der Kern-Use-Case von ISA-95 JobControl ist die MES↔Maschine-Kommunikation. Statt einen Job Order als Object-Bag zu bauen und field-für-field zu serialisieren, geben die Co-SDK-Klassen (OpcISA95JobOrder, OpcISA95Parameter, OpcISA95WorkMaster, …) den vollständigen Objektgraph typisiert vor — jede Property Compiler-geprüft, jeder Sub-Type wieder eine C#-Klasse. Das SDK übernimmt die OPC-UA-Encodierung; Ihr MES-Code sieht nur C#-Objekte.
// Your SiOME model on a Machinery base — the Co-SDK handles the rest
// NuGet: Opc.UaFx.Advanced.Machinery
using Opc.UaFx;
using Opc.UaFx.Server;
using Opc.UaFx.Machinery;
internal class AcmeCncManager : OpcNodeManager
{
public AcmeCncManager()
: base("http://acme.example/cnc/")
{
}
// Your NodeSet modeled in SiOME — single source of truth
protected override IEnumerable<OpcNodeSet> ImportNodes()
{
yield return OpcNodeSet.Load(@"AcmeCNC.NodeSet2.xml");
}
}
// Machinery spec + your model on top, in a single call
using var server = new OpcMachineryServer(new AcmeCncManager());
server.Start();
Companion-Spec + Ihr Modell = fertiger Server.
Der OpcMachineryServer-Konstruktor nimmt zusätzliche OpcNodeManager mit — für Ihre in SiOME modellierten Extensions. Machinery-Basis kommt vom Co-SDK, Ihr Adressraum-Modell wird via ImportNodes() geladen. Optionale Children, die Sie im Modell ausgeklammert haben, bleiben draußen — das SDK folgt der Modell-Vorlage exakt. Eigene Node-Typen entstehen per Vererbung von den Co-SDK-Klassen, ohne den NodeSet-Import zu wiederholen.
Sechs Gründe, die den Unterschied machen
Jeder dieser Punkte adressiert ein reales Problem, das Entwicklerteams begegnet, wenn sie Companion Specifications selbst umsetzen.
Wochen kürzer bis zum ersten Release
Eine Companion Specification selbst umzusetzen bedeutet: XML-Schema lesen, NodeSet verdrahten, ObjectTypes implementieren, Method-Handler ausprogrammieren, Events typisieren. Das Co-SDK hat das bereits getan — Sie starten auf der grünen Wiese.
Typsicher statt Runtime-Überraschungen
Jede Klasse, jede Property, jede Method-Signatur — alles typisiert. Falsche Zuweisungen fängt der Compiler, nicht der Kunde im Feld, nicht das Abnahmeprotokoll.
Einzeln oder im Bundle. Sie entscheiden.
Jedes Co-SDK ist einzeln lizenzierbar — oder gebündelt, wenn Sie mehrere Specs einer Branche brauchen. Kein Zwangskauf von Kompletten, wenn Sie nur eine Spec benötigen.
Ihr Modell ist die Vorlage
Eigenes NodeSet in SiOME modelliert — mit Companion-Basistypen als Grundlage? Das Co-SDK instanziiert zur Laufzeit exakt wie modelliert. Optionale Children, die Sie ausgeklammert haben, bleiben draußen. Eigene Typen ergänzen Sie per Vererbung — das Modell bleibt Single Source of Truth.
Versioniert und gepflegt
Die OPC Foundation aktualisiert Companion Specifications regelmäßig. Wir ziehen nach — Sie aktualisieren das Paket, starten den Server, die neue Version ist produktiv. Kein Migrationsprojekt, kein NodeSet-Merge.
Support aus dem Entwicklerteam
Support-Anfragen zum Co-SDK werden vom Team beantwortet, das die SDKs entwickelt und pflegt — kurze Wege, technisch fundierte Antworten, keine Ticket-Kaskade über externe Callcenter.

Für jede Branche das passende Informationsmodell
Jedes Co-SDK deckt genau eine Companion Specification ab — typisiert, versioniert, modellierbar. Filtern Sie nach Branche, um Ihre zu finden.
Spec nicht dabei? Wir entwickeln Co-SDKs auch nach Kundenanforderung — auf Basis einer bestehenden Companion Specification oder Ihres eigenen NodeSets. Co-SDK anfragen →
In zwei Fragen zum Angebot.
Jedes Co-SDK gibt's ausschließlich als Abo — kündbar nach Mindestlaufzeit, royalty-free im laufenden Vertrag, Updates und Support immer inklusive. Jedes Angebot ist auf Ihre Auswahl gerechnet — kein Pauschalpreis.
Einzelentwickler oder Standortlizenz
Ein Entwickler an einem Arbeitsplatz — oder alle Entwickler an einem Standort. Sie wählen, was zu Ihrem Team passt.
Client-Only oder Client + Server
Nur Daten auslesen — oder lesen und bereitstellen. Der Deployment-Typ bestimmt Ihre Lizenz.
Royalty-free. Unbegrenzt Anwendungen.
Im laufenden Abo deployen Sie so viele Anwendungen wie Sie wollen — keine Stücklizenzen, keine Runtime-Gebühren.
Bereit für ein Angebot? Wählen Sie Ihre Co-SDKs im Katalog oben aus — wir führen Sie in zwei Schritten durch die Qualifizierung.
Was in einem Co-SDK steckt
Typisierte .NET-Wrapper über offizielle NodeSets, mit Modell-Vorlagen und Vererbung — gebaut auf das OPC UA SDK. Hier die Substanz unter dem Katalog: was Sie installieren, worauf es aufsetzt, welche Reife jede Spec hat.
Opc.UaFx.Machinery · Opc.UaFx.MachineTool · Opc.UaFx.ISA95.JobControlOpcMachineryServer + passende NodeManager (z.B. OpcMachineryJobsNodeManager)OpcNodeModel als Konstruktor-Argument steuert die Optional-Children eines typisierten Nodes (.OmitOptionals(), .CreateOptionals()) und richtet die Struktur mit .CreateLike(importedTemplate) exakt an eine importierte SiOME- / NodeSet-Vorlage ausohne erneuten NodeSet-Import
Co-SDKs setzen darauf auf, ersetzen es nicht
Alles was Sie zum Loslegen brauchen
NuGet Packages
Alle Co-SDKs als NuGet-Pakete — direkt installieren, Namespace importieren, loslegen. Wie bei allen Traeger-SDKs mit 30-Minuten-Testlizenz, ohne Registrierung.
Zu NuGetBeispiel-Repos auf GitHub
Lauffähige Szenarien pro Co-SDK — Client und Server, C# und VB.NET, Modell-Vorlage inklusive. Erste Repos verfügbar, Katalog wächst laufend.
GitHub öffnenOPC UA SDK Dokumentation
Co-SDKs setzen auf das OPC UA SDK auf — die Client- und Server-Doku zeigt, wie Sie die Modelle in Ihre Anwendung einbinden.
Docs öffnenCompanion Specifications
Die Original-Dokumentation der OPC Foundation — jede Spec mit Informationsmodell, ObjectTypes und Methoden-Signaturen.
Zu den Specs
„Companion Specifications sollten nicht bei jedem Kunden neu gebaut werden. Mit den Co-SDKs haben wir das einmal gemacht — typisiert, versioniert, modellierbar."
Dominik Scharnagl Geschäftsführer & CTO, Traeger GmbH — Architekt der Co-SDKsBereit, Companion Specifications auszuliefern
statt zu implementieren?
Wählen Sie Ihre Co-SDKs im Katalog aus — in zwei Schritten zum Angebot. Oder sprechen Sie direkt mit uns.
Die Co-SDKs sind neu — das Fundament nicht.
Companion Specifications sind ein Spezialgebiet. Diese drei Nutzergruppen haben die Co-SDKs früh in die Hand genommen — aus guten Gründen.
Pilotprojekte & interne Evaluierung
Die ersten globalen Industriekonzerne setzen die Co-SDKs in Pilotprojekten ein — um Companion-Konformität in ihren eigenen Anlagen und Fertigungsstrecken zu evaluieren.
Referenzimplementierung für eigene Standards
Unternehmen, die leitende Angestellte in OPC-Foundation-Working-Groups entsenden, nutzen die Co-SDKs für Messe-Demonstratoren und Referenzprojekte — genau auf den Specs, an denen ihre Kollegen mitschreiben.
Kundenlösungen auf Co-SDK-Basis
Integratoren bauen auf den Co-SDKs eigene Produkte und Kundenlösungen auf — weil die Modell-Basis gesetzt ist und sie ihre Wertschöpfung in der Fachlogik statt in der Spec-Umsetzung leisten können.