Manufacturing

How does an OEM product engineering engagement work?

We work as the outside engineering bench for an OEM product programme.

This is for machine builders, module makers and IC vendors in industrial automation. You keep the product and the customer; we take the parts that need a standing specialism:

• firmware, middleware and applications, on bare metal, an RTOS, Linux or Windows
• real-time Ethernet and fieldbus integration, on an open-source stack or a commercial one you already license
• device drivers, board support packages and the real-time tuning that makes them hold a cycle
• obsolescence assessment and redesign when a part goes end-of-life
• purpose-built IO devices, control nodes, gateways and network masters where an off-the-shelf part will not do
• pre-compliance testing and conformance support, up to but not including the certificate itself
• training your engineers on the technology, building the first implementation with them, then third-line support behind their first line
• the IIoT layer that gets the result onto a network or into a customer’s systems

Most engagements start scoped: one protocol, one board or one migration. They become a retained bench once the fit is proven. The engagement page sets out the modes and how they are priced.

The pressure is much the same wherever you sit in that chain: ship a product that still looks current three years from now, without standing up, in-house, every specialism it needs.

Why does one machine builder need so many protocols?

The machine is sold into more than one market, and each market has settled on a different interface.

A machine sold into DACH is generally expected to speak PROFINET; the same machine sold into North America is generally expected to speak EtherNet/IP; EtherCAT turns up wherever the motion is tight, Ethernet POWERLINK where the builder supplies both ends of the line and wants an open-source stack, and a growing share of buyers ask about OPC UA on top of any of them.

Covering that range in-house means keeping three or four specialisms staffed for work that only arrives intermittently, and each one carries its own conformance cycle. Much of our OEM work is exactly this gap: we carry the protocol variants and the test cycle, and your engineers stay on the machine.

Which slices of the work can you support?

Any one specialism inside the product: a protocol variant, a node, a driver, an end-of-life part, a conformance run.

• A protocol variant. Your team does not carry it. A market opens up, the buyer expects an interface you have never shipped, and hiring for it is out of proportion to the work. We add the variant to your existing product and take it through the test cycle.
• A node in a third-party machine. A device that has to appear correctly on a network it does not own: a slave on one bus, sometimes a master of a sub-hierarchy beneath it, often bridging to UART, I²C, CAN or a serial instrument on the other side. Both patterns are shown in context on the packaging machinery and material handling pages.
• A drive or encoder interface. A component maker who needs their part to present as a small-footprint slave on real-time Ethernet, or a cell that needs a coordinated motion system reachable from the layer above it.
• An end-of-life part. A component notice on a product that is still selling, and a decision to make about how much of the design moves.
• A device facing conformance. Preparation, in-house test runs against the suites, and support through submission to the accredited laboratory.
• A device to build. A custom IO device, control node, gateway or network master built from the stack port and board bring-up upward, instead of a reference design adapted to fit.
• Team bring-up. Your own engineers brought up to speed. Training on the protocol or platform, then designing and building the first implementation alongside your team so the knowledge stays with them. We hold third-line support afterwards while your team runs first line.
• Validation and CI capacity. Engineers added to your own validation team, or the test and continuous-integration pipeline that runs the suites, the regression set and the timing checks on every build, not just at release.
• A product line reporting data. An installed or new machine that needs an OPC UA or MQTT view of itself for a customer’s MES, ERP or service platform.

The sections below take the four of those that come with the most questions attached.

How does a stack get through conformance testing?

Conformance is managed as a process from the start of the work, not handled as an event at the end.

We prepare the device, run the vendor test suites in-house against the configurations the certificate will cover, fix what they surface, and support the submission. The certificate itself is issued by the protocol organisation’s accredited test laboratory. No engineering firm issues it, including us. Our team has taken Ethernet POWERLINK, PROFINET and PROFIBUS through that cycle on several silicon families, for silicon vendors and for machine builders: FPGA families running the master on Windows, Linux and bare metal; an applications-processor family where the vendor already shipped a controlled node and we ported the managing node onto real-time Linux; an industrial communications IC; and a PROFIBUS interface on a pressure transmitter, which is the same discipline applied to a single instrument instead of a controller. The PROFIBUS and PROFINET work was tested at a PI-accredited laboratory. The POWERLINK work used openPOWERLINK, so nothing in the result was locked to us.

The configurations say more about a stack than the certificate does. We test to 250 µs with 3 to 10 nodes at 32 bytes of process data per node, 1 ms with 10 to 20 nodes at 64 to 128 bytes, and 5 ms with 30 nodes at 128 to 256 bytes. Which of those a given part reaches depends on the silicon, and on whether the master runs bare metal, on a vendor RTOS or on real-time Linux.

What do you do on the drive and motion side?

We do component-side integration, motor-drive control, and the gateway layer above a drive vendor's own system.

• Component-side integration. Optical rotary encoders brought onto real-time Ethernet and fieldbus as small-footprint slaves, for an encoder manufacturer whose parts ship into textile, packaging, elevator and inkjet printing machinery.
• Motor-drive control. Over POWERLINK and PROFINET on an industrial communications IC, taken to a working proof of concept.
• Sercos, and the layer above it. Sercos slave integration stays with the drive vendor; it is a vertical ecosystem and that is the sensible place for it. On a robot controller running a Sercos servo system, our work was the layer above: the gateway and the OPC UA information model that made the cell readable and coordinatable from outside, plus the interoperability demonstration over TSN that proved it. That edge-and-gateway shape is what most drive-vertical work looks like for us.

What happens when a part goes end-of-life?

We assess the part first, then scope the replacement or the migration.

A component notice arrives on a product that is selling perfectly well, and the question is how much of the design has to move. Sometimes it is a drop-in replacement and a driver change. Sometimes the replacement part has a different peripheral set and the firmware has to be reworked around it. That assessment is what turns the decision into a scoped piece of engineering. The obsolescence management page covers how that work runs. Three shapes it has taken for us:

• A discontinued third-party signal-collection device replaced with a 40-channel analog input board, each channel triple-replicated differentially and fed out to oscilloscope BNC and to a downstream module, holding signal-to-noise, integrity and polarity across the change.
• An FPGA family migration across a family of boards for a builder of packaging and food-processing machinery, moving sensor, actuator and automation-network control onto a current part.
• A discontinued PLC replaced together with its eCos-based software by a Zynq platform running real-time Linux and an IEC 61131-3 soft-PLC runtime, talking PROFIBUS to equipment that was staying put.

More exist. These three show the range, from a board respin to a controller and its runtime replaced underneath a working line.

Can IIoT be added to a product line already in the field?

It usually can, and without touching the control logic.

An installed machine that already reports through a fieldbus or a diagnostic port can be given an OPC UA or MQTT view of itself through a gateway, which is a far smaller change than re-architecting the controller. For machines still on the drawing board, it is cheaper to design the interface in from the start. Both routes are covered on the industrial IoT page.

How do you produce performance data a customer’s engineers can check?

We generate it during the integration, so the engineers who did the work write the numbers.

Two of those went out as the vendors’ own technical material:

• TSN into an OPC UA stack. We integrated it into an open-source stack and ran the benchmarks behind it.
• OPC UA into TSN silicon. The same work from the other side, on a silicon vendor’s own TSN solution.

Data written by the engineers who did the integration is a different artefact from marketing copy, and for a module or IC vendor it is often the thing that actually moves a design-in.