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.

4,8/5 auf Trustpilot · 224 Bewertungen
Einzeln oder im Bundle
.NET Standard 2.0 / .NET Framework 4.7.2+
20+ OPC UA Companion SDKs
6 Branchenbundles
Essential in jedem OPC UA SDK Abo inklusive
Corporate Member OPC Foundation

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.

Program.cs — Machinery Co-SDK (OPC 40001-1)
// 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.

OpcMachineryServer — Spec + Basisstandards ab Werk
Identification typisiert — kein NodeId-String im Code
Spec-Updates via Paket-Update, keine Migration
Program.cs — ISA-95 JobControl Co-SDK (OPC 10031-4)
// 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.

OpcISA95JobOrder + verschachtelte Companion-Typen typisiert
Kein Object-Bag, kein Field-Serialisierungs-Boilerplate
MES-Kernszenario ab Werk — Store, Start, Abort, Update
AcmeCncManager.cs — Companion-Spec + Ihr Modell
// 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.

OpcMachineryServer + Ihr NodeManager — ein Aufruf
Modell = Single Source of Truth, keine Nacharbeit
Vererbung von Co-SDK-Klassen für eigene Typen

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.

NuGet-Install · Build · läuft

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.

Compile-time · statt Callback 23 Uhr

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.

20+ Co-SDKs · 6 Bundles

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.

Modell = 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.

Spec-Update · Paket-Update · fertig

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.

Support-Team · Entwicklerkontakt

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.

Weltkonzerne

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.

Working-Group-Mitglieder

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.

Systemintegratoren

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.

Feedback aus einer Companion Working Group
»Was uns begeistert hat, ist die durchgängige Typisierung — bis in die Methoden-Parameter hinein. Statt Array rein, Array raus bekommt man die Argumente so ausgeliefert, wie die Spec sie gemeint hat.«
OPC Foundation
OPC UA Companion Working Group Name auf Anfrage
Kistler
Starrag
Tornos
MHJ-Software
Glen Dimplex
senswork
Parallel Informatik
Intronik

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.

Filter
24 von 24 sichtbar
OPC 10000-100
Devices (DI)
Gerätemodell für alle OPC-UA-fähigen Geräte — die gemeinsame Basis fast aller Companion Specs.
Teil der Basis. Mit jedem OPC UA SDK Abo inklusive.
Standard
OPC 30000
Industrial Automation (IA)
Grundtypen für industrielle Automatisierung — Sensoren, Aktoren, Controller.
Teil der Basis. Mit jedem OPC UA SDK Abo inklusive.
Standard
ISA-95
ISA95 Object Model
Semantik zwischen MES und ERP — Materialien, Personal, Equipment, Prozesssegmente.
Teil der Basis. Mit jedem OPC UA SDK Abo inklusive.
Standard
OPC 10031-4
ISA95 JobControl
Auftragsabwicklung und Job-Steuerung gemäß ISA-95 Part 2 — Version 2.
Teil der Basis. Mit jedem OPC UA SDK Abo inklusive.
Standard
OPC 40001-1
Machinery
Generisches Maschinenmodell — Basis für das UMATI-Nameplate und alle branchenspezifischen Maschinen-Specs.
Teil der Basis. Mit jedem OPC UA SDK Abo inklusive.
Machinery
OPC 40001-101
Machinery ProcessValues
Prozessvariablen von Maschinen — Temperatur, Druck, Drehzahl in Companion-konformer Struktur.
Baut auf: Devices (DI), IRDI Dictionary, PADIM
Machinery Machinery
OPC 40001-102
Machinery Jobs
Maschinenaufträge — Job-Anlage, -Statusverfolgung und -Ergebnisrückmeldung.
Baut auf: ISA95 JobControl
Machinery Machinery
OPC 40001-103
Machinery Result
Strukturierte Ergebnis- und Messdaten aus Maschinenprozessen — Basis für Qualitätsdaten.
Standalone. Benötigt kein weiteres Co-SDK.
Machinery Machinery
OPC 40001-4
Machinery Energy Management
Energieverbrauch je Maschine — Erfassung, Klassifizierung, Monitoring als Machinery-konforme Erweiterung des ECM-Modells.
Baut auf: Devices (DI), Energy Consumption Management (ECM), Industrial Automation (IA)
Machinery Smart Energy
OPC 40501
MachineTool
Werkzeugmaschinen — CNC, Fräsen, Drehen. Produktion, Werkzeugverwaltung, Achsen, OEE-Basisdaten.
Baut auf: Devices (DI), Industrial Automation (IA), ISA95 JobControl, Machinery, Machinery Jobs
Smart Factory Automotive Smart Factory Automotive
OPC 40502
CuttingTools
Schneidwerkzeuge — Werkzeuggeometrie, Standzeiten, Schnittparameter. Ergänzt MachineTool.
Baut auf: Devices (DI), General Motion Systems (GMS), Industrial Automation (IA), ISA95 JobControl, MachineTool, Machinery, Machinery Jobs, Machinery Result
Smart Factory Automotive Smart Factory Automotive
OPC 40210
General Motion Systems (GMS)
Motion-Systeme — Antriebe, Servomotoren, Aktoren und Motion-Controller in einheitlichem Modell. Grundlage für Kinematik in Werkzeugmaschinen und Handhabung.
Teil der Basis. Mit jedem OPC UA SDK Abo inklusive.
Machinery Smart Factory
OPC 40100-1
MachineVision
Bildverarbeitung in der Fertigung — Konfiguration, Rezepte, Inspektionsergebnisse.
Baut auf: Devices (DI)
Smart Factory Smart Factory
OPC 40010-1
Robotics
Industrieroboter und Roboterzellen — herstellerunabhängig. MotionDevice, Controller, Safety-States.
Baut auf: Devices (DI)
Smart Factory Logistics Smart Factory Logistics
OPC 30200
PackML
Verpackungsmaschinen nach PackML-State-Modell — Zustände, Modi, Alarme, Produktionsraten.
Standalone. Benötigt kein weiteres Co-SDK.
Logistics Logistics
OPC 30570
AutoID Devices
Identifikationsgeräte — RFID-, Barcode- und QR-Code-Leser mit einheitlichem Interface.
Baut auf: Devices (DI)
Logistics Logistics
OPC 30081
PADIM
Process Automation Devices — Feldgeräte in der Prozessindustrie mit IEC-61987-Semantik.
Baut auf: Devices (DI), IRDI Dictionary
Automotive Prozessindustrie Automotive
IEC 61360
IRDI Dictionary
Standardisierte Merkmals-Bibliothek — eindeutige Bezeichner (IRDI) für Eigenschaften und Einheiten.
Standalone. Benötigt kein weiteres Co-SDK.
Prozessindustrie Smart Energy Smart Energy
OPC 40223
Pumps & Vacuumpumps
Pumpen und Vakuumpumpen — Kreiselpumpen, Verdrängerpumpen, Vakuumsysteme. Einheitliches Modell für Prozessanlagen und Vakuumtechnik.
Baut auf: Devices (DI), Machinery
Prozessindustrie Machinery
OPC 40570
Wire Harness
Kabelbaum-Fertigung — Baugruppen, Prüfergebnisse, Prozessdaten für die Wire-Harness-Produktion, insbesondere in der Automobilindustrie.
Baut auf: Devices (DI), ISA95 JobControl, Machinery, Machinery Jobs, Machinery Result, Wire Harness VEC
Automotive
OPC 40570
Wire Harness VEC
VEC-Datenmodell (Vehicle Electric Container) — standardisierter Datenaustausch für die Kabelbaum-Konstruktion und -Fertigung nach PROSTEP iViP.
Standalone. Benötigt kein weiteres Co-SDK.
Automotive
OPC 34100-1
Energy Consumption Management (ECM)
Energieverbrauchs-Modell für Maschinen und Anlagen — Basis für ISO-50001-Reporting.
Baut auf: Devices (DI), Industrial Automation (IA)
Smart Energy Smart Energy
OPC 40100-6
Laser Systems
Lasersysteme — Quellen, Scanner, Prozessparameter für Schneiden, Schweißen, Markieren.
Baut auf: Devices (DI), Industrial Automation (IA), Machinery, MachineTool
Laser & AM
OPC 40100-7
Additive Manufacturing
3D-Druck-Anlagen — Bauaufträge, Prozessdaten, Materialhandling für additive Fertigung.
Baut auf: Devices (DI), Industrial Automation (IA), IRDI Dictionary, ISA95 JobControl, MachineTool, Machinery, Machinery Jobs, Machinery ProcessValues, PADIM
Laser & AM

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.

Was Sie bekommen
Form
Typisierte .NET-Klassen je Spec — ein Namespace, fertige Knoten- und Typdefinitionen, kein NodeSet-Import-Boilerplate
Beispiele
Opc.UaFx.Machinery · Opc.UaFx.MachineTool · Opc.UaFx.ISA95.JobControl
Server-API
Eigene Server-Klassen wie OpcMachineryServer + passende NodeManager (z.B. OpcMachineryJobsNodeManager)
Modell-Vorlage
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 aus
Erweiterbar
Eigene Typen per Vererbung von den Co-SDK-Klassen
ohne erneuten NodeSet-Import
Voraussetzung & Lieferung
Basis
OPC UA SDK — als Voraussetzung.
Co-SDKs setzen darauf auf, ersetzen es nicht
Distribution
Je Co-SDK ein eigenes NuGet-Paket — installieren, Namespace importieren, einsatzbereit
Versionierung
Eigene Paket-Version je Co-SDK, an die Spec-Version gebunden · Spec-Updates kommen als Paket-Updates, alte Stände bleiben verfügbar
Standard
Jede Co-SDK-Version referenziert ihre konkrete OPC-Foundation-Spec
Updates & Support
Im laufenden Abo inklusive — keine separate Lizenz je Spec-Update
Wie Co-SDKs aufeinander aufbauen
Vereinfachtes Schichtenmodell zur Veranschaulichung — Companion Specifications referenzieren sich gegenseitig, eine spezifische Spec baut typischerweise auf mehreren darunterliegenden auf. Konkrete Abhängigkeiten und der jeweilige Stand entwickeln sich mit der OPC Foundation weiter — die NuGet-Pakete bringen die jeweils nötigen Abhängigkeiten automatisch mit.
Basis
OPC UA Core — Fundament für jedes OPC UA Modell. Vom OPC UA SDK mitgeliefert.
Essential
Querschnitts-Specs — Machinery, ISA95 JobControl, IA, DI und ISA95. Werden von vielen Specs vorausgesetzt. Mit jedem OPC UA SDK Abo inklusive.
Bundle
Branchen-Bundles — thematisch gebündelte Specs für Machinery, Smart Factory, Automotive, Logistics und Smart Energy.
Spezifisch
Einzelne Co-SDKs — eine konkrete Spec, granular kombinierbar. Bringt ihre Abhängigkeiten zu Essential- und Bundle-Layern selbst mit. Beispiel MachineTool (OPC 40501): ein NuGet-Paket — Machinery Jobs aus dem Machinery-Bundle sowie Machinery, ISA95 JobControl, IA und DI aus Essential kommen automatisch mit.
Dominik Scharnagl

„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-SDKs

Bereit, 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.