Companion Specifications —
already built.
You write business logic.

20+ Companion Specifications as typed .NET classes — Machinery, Robotics, MachineTool, PackML, and more. Spec-compliant, versioned, modelable,
ready to use with a single import.

4.8/5 on Trustpilot · 224 reviews
Individually or bundled
.NET Standard 2.0 / .NET Framework 4.7.2+
20+ OPC UA Companion SDKs
6 Industry bundles
Essential included in every OPC UA SDK subscription
Corporate Member OPC Foundation

The spec ships as a package.
You write what you do with it.

Three real-world scenarios — from the Machinery server to the MachineTool client to dynamic instantiation from your
own NodeSet template.

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 without NodeSet boilerplate — the spec is in the server.

The OpcMachineryServer brings the Machinery NodeSet (OPC 40001-1) along with its base standards (DI) out of the box — no manual OpcNodeSet.Load(...), no catching up on spec updates. Your machine nodes get typed property access: machine.Identification.Manufacturer, SerialNumber, YearOfConstruction, ProductInstanceUri — every access compiler-checked.

OpcMachineryServer — spec + base standards out of the box
Identification typed — no NodeId string in your code
Spec updates via package update, no 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 = "BatchSize", Value = 42 },
    },
};

// Hand it to the machine's JobOrderReceiver
client.CallMethod(receiverObjectId, storeAndStartMethodId, jobOrder);

MES integration out of the box — job orders as typed C# objects.

The core use case of ISA-95 JobControl is MES↔machine communication. Instead of building a job order as an object bag and serializing it field by field, the Co-SDK classes (OpcISA95JobOrder, OpcISA95Parameter, OpcISA95WorkMaster, …) define the complete object graph in a typed form — every property compiler-checked, every sub-type its own C# class. The SDK handles the OPC UA encoding; your MES code only ever sees C# objects.

OpcISA95JobOrder + nested companion types, fully typed
No object bag, no field-serialization boilerplate
MES core scenario out of the box — Store, Start, Abort, Update
AcmeCncManager.cs — Companion spec + your model
// 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 + your model = a finished server.

The OpcMachineryServer constructor takes additional OpcNodeManager instances — for your extensions modeled in SiOME. The Machinery base comes from the Co-SDK, and your address-space model is loaded via ImportNodes(). Optional children you left out in the model stay out — the SDK follows the model template exactly. Custom node types are created by inheriting from the Co-SDK classes, without repeating the NodeSet import.

OpcMachineryServer + your NodeManager — one call
Model = single source of truth, no rework
Inherit from Co-SDK classes for your own types

Six reasons that make the difference

Each of these addresses a real problem that development teams hit when they implement Companion Specifications themselves.

Weeks sooner to your first release

Implementing a Companion Specification yourself means: read the XML schema, wire up the NodeSet, implement the ObjectTypes, code out the method handlers, type the events. The Co-SDK has already done that — you start on a clean slate.

NuGet install · Build · runs

Type-safe instead of runtime surprises

Every class, every property, every method signature — all typed. The compiler catches wrong assignments, not the customer in the field, not the acceptance report.

Compile-time · not an 11 pm callout

Individually or bundled. You decide.

Each Co-SDK is licensable on its own — or bundled, when you need several specs from one industry. No forced purchase of the full set when you only need a single spec.

20+ Co-SDKs · 6 bundles

Your model is the template

Modeled your own NodeSet in SiOME — built on companion base types? The Co-SDK instantiates at runtime exactly as modeled. Optional children you left out stay out. You add your own types by inheritance — the model stays the single source of truth.

Model = single source of truth

Versioned and maintained

The OPC Foundation updates Companion Specifications regularly. We keep pace — you update the package, start the server, and the new version is in production. No migration project, no NodeSet merge.

Spec update · Package update · done

Support straight from the development team

Support requests for the Co-SDK are answered by the team that builds and maintains the SDKs — short paths, technically grounded answers, no ticket cascade through external call centers.

Support team · Developer contact

The Co-SDKs are new — the foundation isn't.

Companion Specifications are a specialist field. These three groups picked up the Co-SDKs early — for good reasons.

Global corporations

Pilot projects & internal evaluation

The first global industrial corporations are running the Co-SDKs in pilot projects — to evaluate companion conformance across their own plants and production lines.

Working group members

Reference implementation for their own standards

Companies that send senior staff to OPC Foundation working groups use the Co-SDKs for trade-show demonstrators and reference projects — on exactly the specs their colleagues help author.

System integrators

Customer solutions built
on Co-SDKs

Integrators build their own products and customer solutions on the Co-SDKs — because the model base is set, letting them add their value in the domain logic rather than in implementing the spec.

Feedback from a Companion Working Group
“What impressed us is the end-to-end typing — right down to the method parameters. Instead of array in, array out, you get the arguments delivered exactly as the spec intended them.”
OPC Foundation
OPC UA Companion Working Group Name on request
Kistler
Starrag
Tornos
MHJ-Software
Glen Dimplex
senswork
Parallel Informatik
Intronik

The right information model for every industry

Each Co-SDK covers exactly one Companion Specification — typed, versioned, modelable. Filter by industry to find yours.

Filter
24 of 24 visible
OPC 10000-100
Devices (DI)
Device model for all OPC UA-capable devices — the common foundation of almost all Companion Specs.
Essential member. Included with every OPC UA SDK subscription.
Standard
OPC 30000
Industrial Automation (IA)
Base types for industrial automation — sensors, actuators, controllers.
Essential member. Included with every OPC UA SDK subscription.
Standard
ISA-95
ISA95 Object Model
Semantics between MES and ERP — materials, personnel, equipment, process segments.
Essential member. Included with every OPC UA SDK subscription.
Standard
OPC 10031-4
ISA95 JobControl
Order processing and job control per ISA-95 Part 2 — Version 2.
Essential member. Included with every OPC UA SDK subscription.
Standard
OPC 40001-1
Machinery
Generic machine model — foundation for the UMATI nameplate and all industry-specific machine specs.
Essential member. Included with every OPC UA SDK subscription.
Machinery
OPC 40001-101
Machinery ProcessValues
Process variables of machines — temperature, pressure, speed in a Companion-compliant structure.
Builds on: Devices (DI), IRDI Dictionary, PADIM
Machinery Machinery
OPC 40001-102
Machinery Jobs
Machine jobs — job creation, status tracking and result feedback.
Builds on: ISA95 JobControl
Machinery Machinery
OPC 40001-103
Machinery Result
Structured result and measurement data from machine processes — foundation for quality data.
Standalone. No other Co-SDK required.
Machinery Machinery
OPC 40001-4
Machinery Energy Management
Energy consumption per machine — capture, classification, monitoring as a Machinery-compliant extension of the ECM model.
Builds on: Devices (DI), Energy Consumption Management (ECM), Industrial Automation (IA)
Machinery Smart Energy
OPC 40501
MachineTool
Machine tools — CNC, milling, turning. Production, tool management, axes, OEE base data.
Builds on: Devices (DI), Industrial Automation (IA), ISA95 JobControl, Machinery, Machinery Jobs
Smart Factory Automotive Smart Factory Automotive
OPC 40502
CuttingTools
Cutting tools — tool geometry, tool life, cutting parameters. Complements MachineTool.
Builds on: 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 systems — drives, servomotors, actuators and motion controllers in a unified model. Foundation for kinematics in machine tools and handling.
Essential member. Included with every OPC UA SDK subscription.
Machinery Smart Factory
OPC 40100-1
MachineVision
Machine vision in manufacturing — configuration, recipes, inspection results.
Builds on: Devices (DI)
Smart Factory Smart Factory
OPC 40010-1
Robotics
Industrial robots and robot cells — vendor-independent. MotionDevice, controller, safety states.
Builds on: Devices (DI)
Smart Factory Logistics Smart Factory Logistics
OPC 30200
PackML
Packaging machines following the PackML state model — states, modes, alarms, production rates.
Standalone. No other Co-SDK required.
Logistics Logistics
OPC 30570
AutoID Devices
Identification devices — RFID, barcode and QR code readers with a unified interface.
Builds on: Devices (DI)
Logistics Logistics
OPC 30081
PADIM
Process Automation Devices — field devices in the process industry with IEC 61987 semantics.
Builds on: Devices (DI), IRDI Dictionary
Automotive Process Industry Automotive
IEC 61360
IRDI Dictionary
Standardized property library — unique identifiers (IRDI) for properties and units.
Standalone. No other Co-SDK required.
Process Industry Smart Energy Smart Energy
OPC 40223
Pumps & Vacuumpumps
Pumps and vacuum pumps — centrifugal pumps, positive displacement pumps, vacuum systems. Unified model for process plants and vacuum technology.
Builds on: Devices (DI), Machinery
Process Industry Machinery
OPC 40570
Wire Harness
Wire harness manufacturing — assemblies, test results, process data for wire harness production, particularly in the automotive industry.
Builds on: Devices (DI), ISA95 JobControl, Machinery, Machinery Jobs, Machinery Result, Wire Harness VEC
Automotive
OPC 40570
Wire Harness VEC
VEC data model (Vehicle Electric Container) — standardized data exchange for wire harness design and manufacturing per PROSTEP iViP.
Standalone. No other Co-SDK required.
Automotive
OPC 34100-1
Energy Consumption Management (ECM)
Energy consumption model for machines and plants — foundation for ISO 50001 reporting.
Builds on: Devices (DI), Industrial Automation (IA)
Smart Energy Smart Energy
OPC 40100-6
Laser Systems
Laser systems — sources, scanners, process parameters for cutting, welding, marking.
Builds on: Devices (DI), Industrial Automation (IA), Machinery, MachineTool
Laser & AM
OPC 40100-7
Additive Manufacturing
3D printing systems — build jobs, process data, material handling for additive manufacturing.
Builds on: Devices (DI), Industrial Automation (IA), IRDI Dictionary, ISA95 JobControl, MachineTool, Machinery, Machinery Jobs, Machinery ProcessValues, PADIM
Laser & AM

Spec not listed? We also develop Co-SDKs to customer requirements — based on an existing Companion Specification or your own NodeSet. Request a Co-SDK →

Two questions to your quote.

Every Co-SDK is available as a subscription only — cancelable after the minimum term, royalty-free while the contract runs, updates and support always included. Every quote is calculated on your selection — no flat rate.

Single developer or site license

One developer at one workstation — or all developers at one site. You choose what fits your team.

Client-only or client + server

Just read data — or read and provide it. The deployment type determines your license.

Royalty-free. Unlimited applications.

While your subscription runs, you deploy as many applications as you want — no per-unit licenses, no runtime fees.

Ready for a quote? Select your Co-SDKs in the catalog above — we'll walk you through qualification in two steps.

What's inside a Co-SDK

Typed .NET wrappers over official NodeSets, with model templates and inheritance — built on the OPC UA SDK. Here's the substance beneath the catalog: what you install, what it builds on, how mature each spec is.

What you get
Form
Typed .NET classes per spec — one namespace, ready-made node and type definitions, no NodeSet-import boilerplate
Examples
Opc.UaFx.Machinery · Opc.UaFx.MachineTool · Opc.UaFx.ISA95.JobControl
Server API
Dedicated server classes like OpcMachineryServer + matching NodeManagers (e.g. OpcMachineryJobsNodeManager)
Model template
OpcNodeModel as a constructor argument controls the optional children of a typed node (.OmitOptionals(), .CreateOptionals()) and aligns the structure exactly to an imported SiOME / NodeSet template with .CreateLike(importedTemplate)
Extensible
Your own types by inheritance from the Co-SDK classes
without importing the NodeSet again
Requirement & delivery
Base
OPC UA SDK — as a prerequisite.
Co-SDKs build on it, they don't replace it
Distribution
One dedicated NuGet package per Co-SDK — install, import the namespace, ready to use
Versioning
A dedicated package version per Co-SDK, tied to the spec version · Spec updates arrive as package updates, older versions stay available
Standard
Every Co-SDK version references its specific OPC Foundation spec
Updates & support
Included while your subscription runs — no separate license per spec update
How Co-SDKs build on each other
A simplified layer model for illustration — Companion Specifications reference one another, and a specific spec typically builds on several underlying ones. The concrete dependencies and their respective status evolve with the OPC Foundation — the NuGet packages bring the required dependencies along automatically.
Base
OPC UA Core — the foundation for every OPC UA model. Shipped with the OPC UA SDK.
Essential
Cross-cutting specs — Machinery, ISA95 JobControl, IA, DI and ISA95. Required by many specs. Included with every OPC UA SDK subscription.
Bundle
Industry bundles — thematically bundled specs for Machinery, Smart Factory, Automotive, Logistics and Smart Energy.
Specific
Individual Co-SDKs — one specific spec, granularly combinable. Brings its own dependencies on the Essential and Bundle layers. Example MachineTool (OPC 40501): one NuGet package — Machinery Jobs from the Machinery bundle plus Machinery, ISA95 JobControl, IA and DI from Essential come along automatically.
Dominik Scharnagl

„Companion Specifications shouldn't be rebuilt for every customer. With the Co-SDKs, we did it once — typed, versioned, modelable."

Dominik Scharnagl Managing Director & CTO, Traeger GmbH — architect of the Co-SDKs

Ready to ship Companion Specifications
instead of implementing them?

Select your Co-SDKs in the catalog — two steps to your quote. Or talk to us directly.