loader image

Home → Blog →

The Machine From 2008 Doesn’t Speak OPC UA. Now What?

“too long,
didn’t read”

1

Most machines older than OPC UA can still deliver their data. A gateway reads the controller in its own language (Modbus, Siemens S7, EtherNet/IP and others) and repub­lishes the values as OPC UA. The machine and its controller stay untouched.

2

The gateway is the easy part. The work is deciding which values matter, what they mean and what to call them. A list of trans­lated register addresses is a start. Mapping it to a stan­dard infor­ma­tion model, such as the OPC UA for Machinery building blocks, makes the data usable by soft­ware that has never seen your machine.

3

Not every machine is worth the effort. Start from one use case, check what the controller exposes, and read before you write. Where nothing digital exists, or the machine leaves the plant soon, the retrofit can cost more than the data returns.

the machine
without OPC UA

Lucas Wolf, Tech­nical Content Manager @Open Industry 4.0 Alliance

October 14th

THE MACHINE THAT WAS HERE FIRST.

Every plant has one. It runs, it earns money, and its controller was built when nobody was plan­ning for a data plat­form. The paint on the cabinet is older than the plant’s IT strategy.

OPC UA, the vendor-neutral indus­trial commu­ni­ca­tion stan­dard of the OPC Foun­da­tion, was released in 2008. A machine from that year left the factory at the same time as the stan­dard entered the market, so its controller most likely speaks some­thing older. The data is in there, in the controller’s memory. The system that now asks for it speaks a different language.

For a mid-sized manu­fac­turer, this machine is rarely the problem on paper. It works, it is paid for, and nobody wants to replace a working line to get a dash­board. For an inte­grator, it is the first thing on the site visit list and the last thing anyone has docu­men­ta­tion for. Both sides end up with the same ques­tion. How do you get this machine’s data into a modern system, and is it worth doing?

Before answering that, it helps to know what the modern system expects.

THE MACHINE THAT WAS HERE FIRST.

Every plant has one. It runs, it earns money, and its controller was built when nobody was plan­ning for a data plat­form. The paint on the cabinet is older than the plant’s IT strategy.

OPC UA, the vendor-neutral indus­trial commu­ni­ca­tion stan­dard of the OPC Foun­da­tion, was released in 2008. A machine from that year left the factory at the same time as the stan­dard entered the market, so its controller most likely speaks some­thing older. The data is in there, in the controller’s memory. The system that now asks for it speaks a different language.

For a mid-sized manu­fac­turer, this machine is rarely the problem on paper. It works, it is paid for, and nobody wants to replace a working line to get a dash­board. For an inte­grator, it is the first thing on the site visit list and the last thing anyone has docu­men­ta­tion for. Both sides end up with the same ques­tion. How do you get this machine’s data into a modern system, and is it worth doing?

Before answering that, it helps to know what the modern system expects.

WHAT THE STAN­DARD ASKS OF A MACHINE.

OPC UA orga­nizes data in an address space, a hier­archy much like files and folders. A client can browse it, read and write values according to access permis­sions, subscribe to values and be noti­fied when they change, receive events, and call methods the server offers. A client can also discover which servers exist on the network and what they support.

Those prop­er­ties explain why the stan­dard travels so well. OPC UA is plat­form inde­pen­dent and runs on anything from PC hard­ware and cloud servers to PLCs and micro-controllers. It also carries secu­rity with it: appli­ca­tions iden­tify each other with certifi­cates, messages can be signed and encrypted, users can be required to log in, and activity can be logged for an audit trail.

A 2008 machine offers none of this on its own. It offers a controller with memory addresses and a protocol that was built for a plant network that nobody expected to reach beyond the factory fence. What­ever sits between the machine and the modern system has to play the role of an OPC UA server on the machine’s behalf.

That role is the trans­la­tion layer.

HOW A TRANS­LA­TION LAYER WORKS.

In industry slang, a plant that already exists and runs is called brown­field, as opposed to a new build on a green field. The usual way to bring a brown­field machine into an OPC UA envi­ron­ment is a gateway: a piece of soft­ware on a small edge computer next to the machine. It talks to the controller in the controller’s own protocol, reads values at an interval, and offers them to the rest of the network as an OPC UA server.

The OPC Foun­da­tion publishes an open-source example, the UA Edge Trans­lator, and its list of supported proto­cols reads like a tour of a typical shop floor. It covers Modbus over TCP and over serial lines, Siemens S7, Rock­well EtherNet/IP, Beck­hoff ADS, HTTP and OPC Classic. Several drivers carry the label “exper­i­mental”, among them Mitsubishi’s MC protocol. Reading such a label before you plan a project costs nothing. The soft­ware runs in a container on ARM and x64 hard­ware, on Windows and Linux, which means the edge computer can be small.

The project describes its purpose as the common brown­field case: connecting many assets with many different inter­faces and trans­lating their data into an OPC UA infor­ma­tion model. It also names the economic argu­ment. If the data is normal­ized at the edge, it does not have to be normal­ized later in the cloud, and the know-how of the people who under­stand the machines, often found only on site, goes into the mapping.

Two details from that docu­men­ta­tion show what brown­field looks like in prac­tice.

OPC Classic is the Windows-only prede­cessor of OPC UA, built on Microsoft’s COM and DCOM tech­nology. Old machines and old soft­ware may offer it. The OPC Foun­da­tion provides wrap­pers to connect Classic and UA prod­ucts. In the Edge Trans­lator, Classic support is limited to a native Windows x86 instal­la­tion, with the Classic server on the same computer. Old data sources can tie the new trans­la­tion layer to an old computer.

The second detail is that reading from a controller can require changing settings on the controller. For Siemens S7-1200 and S7-1500 CPUs, the docu­men­ta­tion lists steps such as permit­ting PUT/GET access from a remote partner. Such a change belongs in a conver­sa­tion with whoever is respon­sible for secu­rity, before the project starts.

Once the trans­la­tion layer runs, any OPC UA client can browse the machine’s data, and the machine has an address space for the first time. Whether anyone can make sense of that address space is the next problem.

WHAT 40001 MEANS.

A gateway delivers what the controller holds, and the controller holds numbers at addresses. Register 40001 might be a temper­a­ture in tenths of a degree, a part counter or a status word. Outside the team that programmed the machine, nobody knows without a docu­ment.

The trans­la­tion layer needs that knowl­edge as input, in a machine-read­able form. The Edge Trans­lator takes it as a Thing Descrip­tion, a JSON file from the W3C Web of Things stan­dard that lists every value with its address, data type and way of reading. That file also carries the details that cause trouble in real projects: scaling factors, and the byte and word order in which a multi-register value is stored.

The file can come from several places. The best source is the machine vendor, and the project’s docu­men­ta­tion lists the order of pref­er­ence. A vendor-supplied Thing Descrip­tion comes first. An Asset Admin­is­tra­tion Shell with an Asset Inter­face Descrip­tion comes next, and the project’s tooling can convert it directly. After that comes an OPC UA NodeSet for the device class, and then the vendor’s register list. The AAS appears on that list for a reason: it is the same container OI4 members use to describe assets in a stan­dard­ized way, and a machine builder who ships one has answered most of this section’s ques­tions before you ask.

For a 2008 machine, the real­istic sources are further down the list. The PLC engi­neering project is one of them. The tooling reads exports from Siemens TIA Portal, Rock­well Studio 5000 and Beck­hoff TwinCAT, so a PLC program that survived also preserved most of the address list. If neither exists, the register table in the manual is the last resort. The project’s docu­men­ta­tion says to check every address against the manual and a live reading before produc­tion use, even when an AI assis­tant drafted the file.

At this point you have values with names. That is progress, and it is still a private vocab­u­lary.

FROM TAGS TO A MACHINE.

Tags sorted by address mean some­thing to the person who wrote the file. A system that has never seen your machine cannot know that “Zaehler_Gut” is the good-part counter. What turns the list into some­thing share­able is an infor­ma­tion model that many parties have agreed on.

OPC UA calls these Companion Spec­i­fi­ca­tions, and they exist so that inter­op­er­ability reaches the semantic level, beyond the trans­port. For machines, the broadest one is OPC UA for Machinery, devel­oped with the VDMA, where around 40 working groups and more than 600 compa­nies are involved in the Companion Spec­i­fi­ca­tions work. It is written for machine tools, injec­tion moulding machines, wood­working machines, pack­aging machinery and others, and it defines building blocks that you can use on their own. The published ones cover machine iden­ti­fi­ca­tion, compo­nent iden­ti­fi­ca­tion, a listing of the machine’s items, machine state, and coun­ters for oper­a­tion and life­time. Further facets for moni­toring and noti­fi­ca­tions are part of the spec­i­fi­ca­tion.

For a brown­field machine, three of those blocks do most of the work. Iden­ti­fi­ca­tion answers what the machine is. State tells you whether it is running, waiting or stopped. Coun­ters give you the numbers that produc­tion reporting wants. A 2008 machine that presents itself through the same blocks as a new one can be read by the same soft­ware.

The prac­tical route runs through two more pieces of the same toolbox. The Edge Trans­lator can trans­form data into Companion Spec­i­fi­ca­tions, and the OPC Foundation’s UA Cloud Library offers the NodeSet files of those spec­i­fi­ca­tions for machine-read­able down­load. A companion tool, the UA WoT Mapper, lets you drag a value from your Thing Descrip­tion onto the matching type of the infor­ma­tion model.

Iden­ti­fi­ca­tion comes first for a reason. The OI4 Master Asset Model template exists for the same ques­tion: what is this thing, and how does the rest of the system recog­nize it?

That covers how a machine can look. The next ques­tion is which machines deserve the work.

WHEN IT PAYS, AND WHEN IT DOESN’T.

No stan­dard answers this for you, so here are the ques­tions worth asking.

Start with the use case. A machine whose data nobody asks for needs no trans­la­tion. A machine that causes down­time, or blocks a reporting line, has a reason. Pick the use case first and then the values it needs, which are often a handful: state, coun­ters, a few process values. That keeps the mapping work small.

Then check what the controller exposes. If the values sit at known addresses in a controller with a supported protocol, the work is mostly mapping. If the address list is lost, the work is detec­tive work. If the machine has no digital inter­face at all, only relays and hard­wired signals, the only route is sensors added in the cabinet, and that is a hard­ware project with its own budget. At that point, compare it to the value of the data honestly.

Read before you write. OPC UA can write values, and the Edge Trans­lator supports it. Reading is the safe place to start. Writing to a controller from a new system changes what the machine does, and that deserves its own safety review.

Look at the machine’s remaining life. If it leaves the plant in two years, the trans­la­tion layer may not repay itself on that machine alone. The mapping to a stan­dard model keeps its value, because the next machine can be exposed through the same model.

Treat secu­rity as part of the design. The OPC UA protec­tions described earlier cover the OPC UA connec­tion. The stretch between gateway and controller still speaks the old protocol with the old protocol’s protec­tions, so the gateway belongs close to the machine, inside its network zone.

Some machines will fail one of these tests, and that result is useful too. A machine that is not worth connecting can stay as it is, and the budget goes to the ones that are.

WHERE THE DATA GOES NEXT.

Once the machine speaks OPC UA, there are two ways to get its data to the systems that want it. In client-server commu­ni­ca­tion, a system connects to the machine’s server and asks for what it needs. Each noti­fi­ca­tion goes to one client, with guar­an­teed delivery. That suits a MES that reads a machine’s state every few seconds, or an engi­neer who wants to browse the address space.

Publish-subscribe, called PubSub in the stan­dard, was opti­mized for many-to-many setups. The machine’s side publishes messages to a message-oriented middle­ware, such as a broker, without knowing who is listening. Subscribers state which data they are inter­ested in and receive it without knowing where it came from. That suits the situ­a­tion where a dash­board, a main­te­nance system and an analytics project all want the same counter.

Which one fits depends on how many consumers your data has. Many plants end up using both, and the gateway can serve them in parallel.

WHO DOES WHAT.

A brown­field project involves three parties, and the work divides along familiar lines.

The oper­ator knows what the machine does and what data would change a deci­sion. That is the use case, and no one else can supply it. The inte­grator knows the proto­cols, sets up the trans­la­tion layer and handles the network and the controller access. The machine builder, if still around, holds the docu­ments that make the mapping accu­rate: register lists, scaling, the meaning of status words.

Projects slow down at the handover between these three. The oper­ator says “I need the counter”, the inte­grator asks “which register?”, and the builder answers three weeks later with a PDF. A shared descrip­tion format helps because it turns each ques­tion into a file that can be passed along. That is also where an alliance like OI4 earns its place: oper­a­tors, inte­gra­tors and machine builders sit in the same work­groups, and the formats they agree on shorten those three weeks.

BEFORE YOU BUY A GATEWAY

Take the oldest machine that still matters. Write down three values you wish you had from it, and where each one lives in the controller.

If you can do that in an after­noon, the project is small. If you cannot, that is the project, and finding out costs nothing yet. If someone in the plant already reads numbers off the machine’s display and types them into a sheet, you have found your first use case.

The machine will keep running either way. What remains open is whether its data joins the rest of the plant, and a deci­sion like that is cheap to prepare. Bring the machine, the controller type and your three values to a call in one of the work­groups. OI4 brings manu­fac­turers, tech­nology providers and inte­gra­tors together, and someone in the room has prob­ably faced the same controller. You can also meet us at one of our events.