compare · South Africa
OPC UA vs OPC Classic: Migration and Training in SA
OPC UA vs OPC Classic for South African learners and sites: compare migration options, data mapping, certificates, history, alarms and practical training.
OPC UA vs OPC Classic is a decision about application compatibility, supported platforms, data meaning and security management. OPC UA provides a platform-independent architecture and a migration path from Classic. Moving to it still requires you to verify what each client uses, which features the proposed server implements and how the operating system, applications and data stores will be maintained.
For a South African brownfield site, there is no universal migration deadline or standard two-year project window. Base the programme on documented product support, operational requirements and the actual dependencies at the site. For a learner, the useful outcome is being able to explain and test an exchange rather than repeating that one protocol is old and the other is new.
This site has a commercial connection to PLC Simulator. Its related HMI and alarm exercises can support foundational learning, but they are not native OPC UA or OPC Classic endpoints. The illustrations are conceptual learning scenes, not screenshots of a migration or validated production architecture.
What OPC Classic and OPC UA describe
The OPC Foundation's Classic overview describes specifications based on Windows COM/DCOM. Data Access, or DA, exchanges values with time and quality information. Alarms and Events, or A&E, addresses alarm and event information. Historical Data Access, or HDA, defines access to historical time-stamped data. These are distinct capabilities that need separate attention during a migration.
The same overview describes OPC UA as a platform-independent architecture integrating Classic functionality. That describes the architecture's scope, not a promise that every UA product implements every service. A server that exposes current values may not provide the historical access or alarm features required by an existing client.
| Migration question | Evidence needed from the existing system | Evidence needed from the proposed system |
|---|---|---|
| Current values | Used items, types, units, quality and timing | Equivalent supported values and interpretation |
| Historical queries | Query use, time ranges and storage ownership | Supported access and a plan for existing records |
| Alarms and events | Events, state handling and operator actions | Supported event model and tested behaviour |
| Writes | Permitted writers and application response | Equivalent permissions and command behaviour |
| Application support | Exact application and operating-system versions | Documented compatible versions and features |
| Security | Current identities, access and maintenance arrangements | Supported policies, trust management and permissions |
Use this table to identify workstreams. Do not merge them into one “OPC connection” task that becomes complete as soon as a client displays a number.
DCOM hardening is a compatibility issue, not a removal announcement
Microsoft's KB5004442 DCOM hardening guidance documents phased changes, with mandatory hardening from 14 March 2023. It also describes diagnostic events for applications using an insufficient activation authentication level. This is not an announcement that DCOM has been removed from Windows.
Review the vendor's supported application and operating-system combinations. Determine whether updates, configuration changes or replacement software are required for the installed products. Do not use an unverified prediction about Windows as the basis for a plant shutdown date, and do not plan a migration around disabling security hardening.
Build a lifecycle record for the actual installation
List the host operating system, OPC server, clients, drivers, database and engineering tools. Attach support evidence for the versions actually installed. A statement about a product family may not apply to an older release or to an optional driver supplied by another vendor.
Record the owner of each dependency and the consequence if it becomes unavailable. A report used once a month can be missed in daily observation but still matter to the business. Interview the people who use those outputs and compare their answers with the configuration and application inventory.
For course buyers, ask whether the instructor distinguishes protocol concepts from product lifecycle advice. A useful course should identify the versions in its lab and explain which conclusions can be transferred to other environments.
Three migration approaches to compare
A native UA client and server pairing is one option where both applications support the required exchange. Another is an interoperability component that preserves part of the Classic arrangement. A third is a broader replacement project that changes the historian, HMI or other applications as well as the communication interface.
The OPC Foundation's process-automation white paper describes wrappers connecting Classic servers to UA clients and proxies connecting Classic clients to UA servers. This provides a basis for staged migration. It does not mean every bridge supports every DA, HDA or A&E function your applications need.
Keeping a bridge does not remove every old dependency
Identify where the Classic-facing component runs and what it still depends on. A UA-facing connection can reduce the number of clients directly using the old interface while leaving the original server and its host in service. Document that residual dependency instead of reporting the whole system as migrated.
Check licensing, supported data types, diagnostic access, buffering, restart and maintenance arrangements for the proposed component. A bridge can be useful when it solves a defined compatibility problem. Its presence is not automatically either wasteful overhead or a complete solution.
Separate communication changes from application replacement
Changing the communication interface and replacing the historian at the same time increases the number of behaviours that need explanation if a test fails. Where practical and approved, stage changes so that their effects can be identified. The site's operational constraints determine the feasible sequence.
For each stage, describe the starting state, change, acceptance evidence and recovery route. A phased plan should reduce uncertainty, not merely spread the same undefined work across several calendar entries.
Native OPC UA on a controller needs model-specific checks
Do not assume every modern PLC has an enabled UA server with the same capacity and security features. Confirm the exact model, firmware, engineering software, licence if required and supported services. Include the load imposed by clients and the other work performed by the controller.
For a concrete correction, Rockwell's September 2025 OPC UA in Logix controllers manual documents support enabled from version 36 firmware for the covered implementation, with model restrictions. It also distinguishes version 36 server-or-client operation from simultaneous operation starting with version 37. The earlier blanket claim of native ControlLogix 5580 support from version 32 was incorrect.
Use the manual for the selected controller and release rather than extending those details to every Logix generation. A gateway or aggregation service may still serve a purpose, such as consolidating access or meeting requirements beyond the controller's implementation. Compare the actual architecture and its supported capabilities.
The OPC UA basics guide explains nodes, namespaces, updates and data quality. Those concepts help interpret a capability document before choosing hardware or a specialised course.
Create a dependency inventory before counting tags
Tag count alone hides how data is used. One value may feed an operator display, a report and a calculation, each with different timing or quality expectations. Likewise, a single application may use both current values and historical queries. Record the relationships as well as the list of items.
Consider a fictional installation with five consumers. The operator application reads status and issues authorised requests. A historian collects current values and queries an existing historical service. An alarm console consumes events, an MES application reads current data, and a report application queries history.
| Fictional consumer | Dependency to verify | Separate acceptance evidence |
|---|---|---|
| Operator application | Current-value reads | Correct display with units and quality |
| Operator application | Writes | Permitted request and confirmed application response |
| Historian | Current-value collection | Correct collection and missing-data handling |
| Historian | Historical queries | Required interval retrieved with correct interpretation |
| Alarm console | Alarm/event exchange | Defined condition and operator action sequence |
| MES application | Current-value reads | Correct downstream calculation or decision |
| Report application | Historical queries | Required report reproduced and reviewed |
That is five consumers but seven dependency rows. Neither number is a tag count. If only the operator display has been tested, the other dependencies remain open even when the new server is reachable.
Give each row a status that preserves unknowns
Use statuses such as not tested, passed, failed and awaiting evidence, with a named reviewer and test record. Do not convert “the vendor says it should work” into a passed test. Record whether an unsupported feature needs a changed design or further clarification.
Add a column for consequences and priorities. A low-frequency operation may be more consequential than a frequently refreshed dashboard. Agree the required acceptance evidence with the people responsible for operations, applications and data use.
Verify data equivalence, not just matching item counts
Create an explicit mapping between the old item and the proposed UA node. Include data type, units, scaling, valid range, quality interpretation, timestamps and access direction. State where any conversion happens. A conversion applied in both a gateway and a client can produce a plausible-looking but wrong value.
Do not describe Classic as necessarily a flat list with no useful metadata. Its DA specification includes quality and time information, and implementation details need inspection. Similarly, a UA address space is not automatically a rich model of your entire plant. Evaluate what the selected server actually exposes.
Fictional unit-conversion acceptance worksheet
The following invented observations illustrate why equal raw numbers are not enough. Assume the old application displays the engineering units shown, and the proposed source documents the stated units or scaling. These are exact teaching values, not measurements from a real migration.
| Item | Old engineering value | Proposed source value | Conversion to old units | Comparison |
|---|---|---|---|---|
| Shaft speed | 1,500 rev/min | 25 rev/s | Multiply by 60: 1,500 rev/min | Agrees numerically |
| Temperature | 22.4 degrees Celsius | 224 tenths of a degree Celsius | Multiply by 0.1: 22.4 degrees Celsius | Agrees numerically |
| Pressure | 4 bar | 400 kPa | Multiply by 0.01: 4 bar | Agrees numerically |
| Flow | 5 cubic metres/hour | 5 litres/minute | Multiply by 0.06: 0.3 cubic metres/hour | Does not agree |
For flow, one litre is 0.001 cubic metres and there are 60 minutes in an hour. Five litres per minute therefore becomes 0.3 cubic metres per hour. Copying the raw number 5 onto a display labelled cubic metres per hour would conceal the mismatch.
Three rows agree numerically after the declared conversion. That does not establish that the migration is 75 percent complete. Quality, timestamps, permissions, update behaviour and the other dependency rows have not been proven by this worksheet. A conversion check is one part of acceptance evidence.
Test more than one value and one operating condition
Choose representative values and boundary cases from the actual application requirements. Include unavailable data and any supported status distinctions that consumers use. A value that matches while quality is invalid should not be silently treated as a valid process measurement.
Record how timestamp meaning is preserved. A source timestamp, a server timestamp and the time a report is generated are different concepts. Document the comparison rule so that a reviewer knows whether an apparent difference is expected or a defect.
Node identity needs a deliberate client strategy
The OPC Foundation's NodeId definition explains that a namespace index may change across future sessions, while the namespace URI and identifier form the persistent identity elements described there. A client should not assume a saved numeric namespace index remains valid indefinitely.
The BrowseName definition also states that different nodes may have the same BrowseName. Replacing every stored NodeId with a bare BrowseName is therefore not a general solution to identity problems. Use the server's documented model and an appropriate client resolution strategy.
Treat model changes as changes to an interface
Record the model version and mappings used during acceptance. Ask the supplier how supported upgrades affect identifiers, types and relationships. Test the consumer after an approved model change rather than assuming a successful browse operation proves its bindings remain correct.
A migration can legitimately expose a different model. If so, document the intended mapping and review its consumers. The goal is not to preserve every old spelling at any cost; it is to preserve or deliberately change the application's meaning with evidence.
Manage trust, identity and permissions separately
The OPC UA application-authentication model describes certificate validation and trust lists, including certificate authorities. Trust is an administrative decision, not an instruction to accept any certificate presented at first contact. Check the authentication behaviour of the actual transport and products in use.
Application trust, user identity and permission to perform an operation are different checks. A trusted application should receive only the access required for its role. Successful connection does not imply permission to write every exposed value, and a read-only reporting role should not inherit engineering permissions for convenience.
Plan certificate maintenance before cutover
Record certificate owners, renewal procedures and the products' supported recovery process. Establish who may change trust lists and how authorised changes are reviewed. Test certificate replacement in the appropriate lab or maintenance process; do not wait for an unexpected expiry to discover that a client needs intervention.
The Foundation's security guidance distinguishes signing from encryption and cautions against automatically trusting certificates. Signing addresses integrity; confidentiality requires encryption. A perceived connection delay is not sufficient evidence for removing confidentiality protection from a production exchange.
Investigate the actual delay and reconnect behaviour with the responsible engineering and security teams. Choose supported policies and permissions that meet the security objectives and operational requirements. Do not infer that anonymous user access means every network user automatically has unrestricted control; verify the configured rights and application trust as separate matters.
Historical data and alarms need their own acceptance work
Changing a current-value connection does not demonstrate access to existing history. Identify the owner and format of the historical store, the required queries and the retention arrangements. If records are moved, establish how completeness, time interpretation, duplicates and retrieval will be checked.
Keep access migration separate from storage migration in the plan. A new client might access an existing history service through a supported bridge, or a project might replace the store. These options have different work and recovery requirements. Confirm what the actual proposal includes.
For alarms, document the condition, event information and permitted operator actions that matter to the application. Test the agreed sequence and reconcile the results with the old behaviour or an approved change. A client receiving one event is not proof of complete alarm-state handling.
The HMI vs SCADA selection guide explains why history, alarms and operating responsibilities belong in the requirements. For related foundational practice, review PLC Simulator's alarm-management exercises. They do not prove native OPC A&E or UA event interoperability.
Plan cutover and recovery around operational ownership
Define who may authorise each migration stage and what evidence they need. Include a clear decision point if mandatory tests fail. A rollback plan should identify the known configuration to restore, required backups and how operators will know which application is authoritative.
Where parallel comparison is appropriate, control the roles of both systems. Duplicating observation for a defined test is different from allowing two independent applications to issue commands. Prevent unintended competing writers through the approved architecture and procedures; do not rely on people remembering which screen is the new one.
After cutover, monitor the behaviours that acceptance testing identified as important. Resolve unexplained gaps or mapping discrepancies before treating the old path as disposable. Confirm that retained records and recovery material remain usable under the agreed maintenance arrangement.
South African course and project questions
For training in Johannesburg, Pretoria, Durban, Cape Town or online, ask which client/server pair each learner uses. Confirm whether the course covers only current values or also includes history, events, identity and diagnostic work. The location and the word “advanced” do not establish those outcomes.
Use the industrial networking training guide to compare prerequisite knowledge and practical evidence. The SCADA training guide helps connect communication skills to the wider operator and data-management tasks. Select the course that addresses your current responsibilities and the equipment you need to understand.
For a project quotation, request an explicit inventory and scope, including bridges, licences, application changes, testing, training and support. Check remote-support access and on-site availability for the actual location. Do not use unsupported claims about municipal, mining or petrochemical adoption as a substitute for your site's evidence.
Related HMI simulator practice can help you explain displayed values and operator tasks. Use a supported OPC client/server lab for certificate, subscription and native protocol exercises. Keep those learning outcomes distinct in your portfolio.
Common OPC migration questions
Must every OPC Classic system be replaced immediately?
Set the decision using supported versions, security requirements, operational consequences and a tested migration plan. There is no universal South African deadline established by the protocol name alone.
Can I connect an OPC UA client to a Classic server?
A supported wrapper may provide that connection. Verify the exact capabilities and dependencies; exposing current values does not automatically cover all historical and alarm functions.
Does OPC UA automatically move historical records?
No. Determine whether the project changes only access or also the data store, then test the required queries and any record transfer separately.
Is a BrowseName safer to store than a NodeId?
A bare BrowseName is not a globally unique node identity. Use the documented model and a client strategy that handles namespaces and intended model changes correctly.
Can an AI assistant create the migration plan?
It can help organise an inventory and test matrix if given the exact versions and requirements. Ask for primary sources and clearly marked unknowns. Have the responsible application, operations and security owners verify consequential decisions.
Can I learn these concepts without a physical PLC?
A suitable software client/server lab can support protocol-specific learning where the required features are implemented. General HMI or PLC simulation is useful related practice but does not automatically provide native OPC connectivity.