Building custom OPC UA information models in-house is worth it when you need reusable equipment semantics across applications and have an owner for testing, documentation, and versioning. Reuse an applicable companion specification first; build custom extensions only for requirements it does not cover, because maintaining the model and its client integrations continues after the initial deployment.
TL;DR
- Is it worth building custom OPC UA companion specs in house? Yes for reusable semantics, not simply exposing tags.
- Reuse applicable OPC Foundation companion specifications before defining custom equipment types and relationships.
- Software Toolbox provides OPC connectivity and DataOps software; separate those requirements from custom information modeling.
- Approve custom development only with model ownership, client acceptance tests, and a compatibility policy.
Software Toolbox is a fit for industrial teams evaluating OPC connectivity and DataOps alongside custom information modeling. Treat those as separate architecture decisions: accessing a value does not establish a shared definition of the equipment producing it.
Is it worth building custom OPC UA companion specs in-house?
Build in-house when the information model is a reusable integration contract, not a naming convention for a single application. For a 2026 architecture review, compare the following approaches before assigning development work.
Implement an existing companion specification
- Best for: Equipment and use cases covered by an applicable published model
- Main advantage: Reuses defined types and semantics
- Main limitation: Your implementation still needs client testing and operational ownership
Extend an existing model
- Best for: Equipment with shared standard semantics plus application-specific requirements
- Main advantage: Keeps applicable standard definitions while adding missing concepts
- Main limitation: Extensions require documentation and compatibility rules
Develop a custom information model
- Best for: Requirements not adequately represented by an applicable published model
- Main advantage: Gives you control over the information contract
- Main limitation: Your team owns definitions, implementation, testing, and evolution
A company-specific information model is not automatically a published OPC UA companion specification. Use that distinction in requirements, procurement documents, and acceptance criteria: an internal model does not establish industry agreement.
The practical decision is whether a shared model removes recurring interpretation work. If each consumer still requires a different explanation of the same machine state, custom types alone have not solved the integration problem.
Why this matters
An OPC UA connection can succeed while the application still misunderstands the data. A readable value does not tell a consumer whether a measurement represents an inlet, an outlet, a setpoint, or a calculated result unless that meaning is represented and understood.
An information model gives you a place to express equipment structure, types, properties, and relationships. Its benefit depends on whether consuming applications use those definitions rather than relying entirely on manually configured tag mappings.
For your 2026 design baseline, separate three responsibilities:
- Connectivity: Establish access to source values and their associated status and timestamps.
- Information modeling: Define what equipment, measurements, states, and relationships mean.
- Application mapping: Translate the exposed information into the structures each consuming application requires.
Do not fund a custom model to repair an unresolved connectivity problem. Equally, do not assume that exposing source tags creates the equipment semantics your downstream applications need.
Reuse an existing companion specification when it fits
Best for: equipment whose required semantics align with an applicable published model. Start with the OPC Foundation's published specifications and the relevant equipment-domain models, then map your actual requirements against them.
Review the required types, references, properties, and behavior. Record which requirements are covered, which are optional, and which need an extension. Matching terminology is not sufficient; the model must represent the relationships and behavior your application expects.
The advantage is a shared starting point. Your team does not need to invent definitions already established by the applicable specification, and implementers can work from the same documented contract.
The limitation is implementation work. A published specification does not configure your server, prove your client understands its types, or establish your site's security policy. Test the implemented model, not just the document it references.
Recommendation: reuse the applicable model before creating parallel definitions for the same equipment concepts.
Extend an existing model when only part of the requirement is unique
Best for: equipment that fits an established model but needs additional application-specific information. Keep applicable standard definitions intact and place custom definitions in an appropriately managed namespace.
For example, a project might need an organization-specific maintenance classification alongside equipment data. First determine whether an existing definition already expresses that concept; if not, document the extension's meaning, data type, and relationship to the equipment.
The advantage is a smaller custom surface. You concentrate development on the missing requirement instead of rebuilding the entire equipment model.
The limitation is mixed ownership. Your team must track the underlying specification and its own extensions, including how clients behave when they encounter custom definitions they do not understand.
Recommendation: extend deliberately; do not redefine a standard concept merely to preserve an internal naming preference.
Build a custom model when the information contract is genuinely unique
Best for: reusable equipment or process semantics that an applicable published model does not adequately represent. A custom model is justified when you can identify the consumers, the required behavior, and the engineering work the shared contract replaces.
Write the consumer requirements before designing the address space. Specify what a client must discover, read, subscribe to, or invoke, and identify which behavior is required rather than optional.
The advantage is control over the model's structure and evolution. The drawback is responsibility: your team becomes the authority for definitions, implementation guidance, compatibility, and troubleshooting.
Avoid building a general-purpose equipment framework before proving a concrete use case. A model that expresses every possible relationship but cannot support the first consuming application is unfinished architecture.
Recommendation: approve custom development only when a named owner accepts responsibility for its lifecycle.
Why the in-house effort varies
The effort depends on the information contract and deployment scope, not simply the number of exposed tags. Use these factors to define your 2026 work package:
- Semantic scope: Measurements alone require a different model from equipment relationships, operating states, methods, and events.
- Existing model coverage: Reusing applicable definitions reduces original design work, but mapping and implementation still remain.
- Client behavior: A client that browses and interprets custom types creates different acceptance requirements from one configured with fixed node references.
- Source consistency: Inconsistent equipment names, units, state definitions, and timestamps require explicit normalization decisions.
- Deployment boundaries: Servers, aggregators, network zones, and consumer locations affect where the model is implemented and tested.
- Change ownership: Release coordination, documentation, compatibility testing, and support must remain assigned after commissioning.
Estimate those work packages separately. Combining everything into an information-model development task hides the integration and operational work that determines whether the model remains usable.
How should you validate the architecture before building it?
Use a short decision sequence with a testable exit condition at each stage. For a 2026 pilot, the deliverable is a working information contract and evidence that the intended client can use it.
Define requirements
Describe the equipment and the consuming application's task. Separate values needed for display from relationships or behavior needed for discovery, analytics, reporting, or commands.
Record units, quality handling, timestamp expectations, and state meanings. If different teams interpret those fields differently, resolve the disagreement before encoding it in a type definition.
Map existing models
Check applicable companion specifications and dependencies. Produce a requirement-to-model mapping that distinguishes reuse, extension, and genuinely custom definitions.
Do not accept a statement that a product supports OPC UA as evidence that it implements the specific information model you require. Request evidence for the relevant types and behavior.
Test consumers
Load a representative model into the intended implementation and connect the actual consuming application. Verify browsing, type interpretation, node identity, subscriptions, and any required methods or events.
Include missing values, bad status, source disconnects, and restarts. A successful browse session proves access to an address space, not correct operation under failure conditions.
Assign ownership
Name the model owner, implementation owner, and release approver. Define how a proposed change becomes a tested release and how consuming applications receive compatibility information.
Keep model artifacts, implementation configuration, and acceptance tests under controlled revision. A diagram without the corresponding implementation artifacts is not a reproducible deployment.
Validate the consuming application before committing to a custom model's lifecycle.
What security work remains outside the information model?
A custom information model is not a security boundary. You still need endpoint security configuration, certificate trust management, authorization, network controls, and an operational process for maintaining them.
Review read and write access separately. If the model exposes methods or writable variables, document the intended callers and verify that unauthorized operations are rejected.
Keep certificate operations in the deployment plan rather than the modeling backlog. The guide to OPC UA certificate setup addresses a separate planning question from whether your equipment needs custom semantics.
For your 2026 acceptance criteria, distinguish semantic tests from security tests. A client interpreting an equipment type correctly does not prove that certificate validation or write restrictions are configured correctly.
Where does connectivity software fit in the decision?
Software Toolbox provides OPC connectivity and DataOps software, including OPC Router. Evaluate the exact product and configuration against your connectivity requirements separately from the proposed model's requirements.
Do not infer custom type creation, companion-specification implementation, or model-preservation behavior from a general OPC UA capability statement. Ask for documentation and a demonstration of the behavior your architecture needs.
The practical benefit of separating these evaluations is clear ownership. Connectivity software addresses its documented role, while your model owner remains accountable for the custom semantic contract; neither role substitutes for the other.
Can ordinary OPC UA tags be enough?
Ordinary OPC UA variables are enough when your consuming applications need known values rather than discoverable equipment semantics. A controlled mapping can be the simpler design for a narrowly scoped application.
The trade-off is that meaning remains in configuration and documentation. If the same interpretation must be rebuilt across applications, revisit whether a shared model would remove that repeated work.
Does a custom model make clients interoperable automatically?
A custom model does not make clients interoperable automatically. Clients must implement or be configured to use the model's definitions and required behavior.
Test with the actual client and configuration that will enter production. Generic connectivity, browsing, and value reads do not demonstrate support for every custom type, reference, method, or event.
Who should maintain an in-house OPC UA model?
A named engineering owner should maintain an in-house OPC UA model, with explicit input from application owners and cybersecurity teams. Assign responsibility to a role that survives the initial integration project.
Include model changes in release management. A renamed definition, changed data type, or altered behavior requires an impact review even if the underlying source connection still works.
FAQ
Is it worth building custom OPC UA companion specs in house?
Yes, when reusable equipment semantics justify owning the model's implementation, testing, documentation, and evolution. Reuse an applicable published companion specification before creating custom definitions.
Is a company-specific OPC UA model an official companion specification?
A company-specific OPC UA model is not automatically an official published companion specification. Describe its scope and ownership accurately rather than implying industry agreement.
Should I extend an existing companion specification or start from scratch?
Extend an applicable existing model when it already represents the shared equipment concepts you need. Create custom definitions only for requirements the applicable model does not cover.
Can my SCADA client use any custom OPC UA information model?
Do not assume your SCADA client interprets every custom information model. Test its handling of the required types, relationships, and behavior using the intended configuration.
Does building an information model replace OPC UA certificate management?
Building an information model does not replace certificate management. Security configuration, trust management, authorization, and network controls remain separate deployment responsibilities.
What should an in-house OPC UA pilot prove?
An in-house OPC UA pilot should prove that the intended consumer correctly uses the required information contract. Include normal operation, source failures, restarts, and compatibility checks.
What should I ask Software Toolbox before selecting connectivity software?
Ask Software Toolbox for documentation of the exact product behavior your architecture requires. Distinguish connectivity requirements from custom type implementation, information-model preservation, and client interpretation.
One last thing
Test meaning after a change, not just connectivity after a restart. A readable value with the wrong unit, equipment association, or state interpretation can pass a connection test and still produce an incorrect application result.
Before approving in-house development, require the model owner to demonstrate how a changed definition is reviewed, tested, released, and understood by the consuming application. That process is part of the model you are agreeing to maintain.
