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.
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.
// 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.
// 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.
// 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.
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.
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.
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.
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.
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.
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.

The right information model for every industry
Each Co-SDK covers exactly one Companion Specification — typed, versioned, modelable. Filter by industry to find yours.
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.
Opc.UaFx.Machinery · Opc.UaFx.MachineTool · Opc.UaFx.ISA95.JobControlOpcMachineryServer + matching NodeManagers (e.g. OpcMachineryJobsNodeManager)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)without importing the NodeSet again
Co-SDKs build on it, they don't replace it
Everything you need to get started
NuGet packages
All Co-SDKs as NuGet packages — install directly, import the namespace, get going. As with all Traeger SDKs, with a 30-minute trial license, no registration.
Go to NuGetSample repos on GitHub
Runnable scenarios per Co-SDK — client and server, C# and VB.NET, model template included. First repos available, the catalog keeps growing.
Open GitHubOPC UA SDK documentation
Co-SDKs build on the OPC UA SDK — the client and server docs show how to wire the models into your application.
Open docsCompanion Specifications
The original OPC Foundation documentation — every spec with its information model, ObjectTypes, and method signatures.
To the specs
„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-SDKsReady 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.
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.
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.
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.
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.