Real-time Ethernet stack integration services develop, port, tune and pre-compliance test a device's protocol layer.
This is for device manufacturers, machine builders and silicon vendors. We develop, port, tune and pre-compliance test PROFINET (including IRT class C), EtherCAT, Ethernet POWERLINK, EtherNet/IP and IEEE 802.1 TSN on FPGA, SoC, applications-processor, MCU and real-time Linux platforms. Our team has delivered software masters at 80 µs cycle time, and multi-vendor PROFINET IRT register control with application synchronisation within 3 µs where hardware acceleration carries the timing. The engagement is usually one of these shapes: - **A stack is developed or ported** onto your platform and handed over with its build environment. - **A stack you already have is tuned** until it holds the cycle your application needs. - **A part that has never run industrial Ethernet is brought up** as a reference integration a vendor can publish, with a sample framework their customers can start from. - **Your engineers are trained** on the platform and protocol, with the first implementation built alongside them. In each case the protocol layer is ours and the product stays yours, and the work runs from protocol selection through pre-compliance testing: - **Selection** weighs your installed base, target markets, silicon roadmap and certification cost, and ends in a prototype on your hardware rather than a recommendation slide. - **Porting** covers the stack, the driver beneath it and the build environment around it. - **Tuning** is measurement work: cycle time and jitter under load, not at idle, on the hardware that will ship. What we do not do is commission a plant. We build the layer inside your product and integrate and test it with your engineers, onshore during integration and test and remotely afterwards.Each of them is the right answer somewhere, and the deciding constraint is usually not the protocol.
It is the installed base your customer already runs, and what their procurement documents name. | Protocol | What selects it | | --- | --- | | PROFINET | The broadest by installed base, covering discrete and process automation in one protocol, with IRT for the isochronous end | | EtherCAT | Device density and the shortest motion cycles. On the controller side silicon vendors supply no master, so EtherCAT master integration services means taking a third-party MainDevice stack and making it run correctly alongside your application | | EtherNet/IP | What North American procurement most often names | | POWERLINK | The licence model matters, and an open-source stack can be maintained in-house | | TSN | Underpins converged networks going forward, but it is a layer beneath these rather than a replacement for them | Our team has shipped device and master work across all of these families, so the selection conversation is not a pitch for whichever one we know. Where the requirement is a long sensor run at low power instead of a fast cycle, the decision sits at the physical layer, 10BASE-T1L and Ethernet-APL, not the protocol above it.Datasheets and delivered systems diverge here, so we quote from measured runs.
As an example, for POWERLINK managing nodes, our team extended openPOWERLINK's standard test setup into the application groups customers actually build for: *250 µs* for motion and robotics with 3 to 10 controlled nodes at 32 bytes per cycle, *1 ms* for machine IO with 10 to 20 nodes at 64 to 128 bytes, and *5 ms* for process automation with 30 or more nodes at 128 to 256 bytes. Those three points describe the actual trade: cycle time, node count and payload per cycle move together, and any figure quoted without the other two is incomplete. On the master side, a tuned real-time Linux with a driver written for determinism reaches an 80 µs network cycle. Windows is a different problem with a different answer, and it is covered on the [system software](/services/system-software/) page, not glossed here. ## What sets the jitter you can actually hold?The hardware sets it, more than the operating system does, once the NIC is doing its part.
- **With hardware-timed transmit.** Our measured network jitter is *40 ns* on a tuned real-time Linux with an Intel i210 card. Published figures for this class of design usually sit nearer *100 ns*, and the gap is deliberate: a specifiable number has to carry buffer for process and model variation, where a measured one does not. Both are valid; they answer different questions. - **Without it, or with it disabled.** The same software holds around *20 µs*. That is the figure for a generic NIC without hardware launch timing, and it is a useful floor to know, because it is what a software-only design gets no matter how well the scheduler is tuned.We measure it on the path the device will actually run on.
PTP and IEEE 1588 integration is straightforward to claim and easy to get wrong, because a sync guarantee is only as good as the weakest hop. One ordinary switch in the middle of an otherwise capable network removes it. We measure sync accuracy at every hop and report where it degrades. The same applies to TSN. Qbv gate schedules have to be computed, pushed to every switch, and then verified against what the network does under load. The verification step is the one most often skipped, and it is the one that catches the misconfiguration. ## Is TSN ready to standardise on?The profile industrial buyers were waiting for now exists.
- **What changed.** IEC/IEEE 60802, the TSN profile for industrial automation, was published in June 2026. Before it, "TSN support" on a datasheet could mean almost any subset of the IEEE 802.1 features, and two compliant devices could still fail to interoperate. A named profile is what makes a procurement requirement writable. - **What did not.** A network does not become conformant because a profile now exists. We test against the equipment you actually run and report where it meets the profile and where it does not, so the gap is known before it is designed around. ## What does pre-compliance testing save?Pre-compliance testing saves a booking, and usually a launch date.
A conformance run is a multi-day lab engagement, quoted per device by the test lab and charged by effort. Several test iterations happen inside one booking, but a device that fails and has to be re-submitted is quoted again, against a schedule that has already been announced to customers. We run PROFINET, EtherCAT, EtherNet/IP and POWERLINK devices against the protocol organisation's own certification test bundles and netload classes in-house first, using the same tools the accredited lab will use. The formal attempt is then not the first time anyone has seen the device fail. The certificate is still issued by the accredited lab. ### Frequently asked questions **Who does real-time Ethernet stack work for a device manufacturer?** We do, as the protocol layer inside your product rather than as a system integrator on your customer's floor. Your team keeps the application and the customer relationship. We take the part that needs a standing specialism, integrate and test it with your engineers onshore and remotely, and stay behind it as third-line support. **Can a standard PC act as an industrial Ethernet master?** Yes, with a tuned real-time Linux and a driver built for determinism. Our team has built custom NIC drivers reaching an 80 µs network cycle without socket buffers. Where the NIC supports hardware-timed transmit, network jitter comes down to tens of nanoseconds; on a generic NIC without it, the same software holds around 20 µs. **Which hardware should we choose?** Ask this early, because the route decides the achievable cycle more than any later tuning does. FPGA fabric gives the tightest timing at the cost of toolchain and bring-up effort. An SoC with a real-time subsystem gives application headroom alongside deterministic timing. A dedicated communications IC solves conformance in silicon and ties you to one part. We size the trade against your volumes, your cycle and your service life. **Do you work on our silicon or only on reference platforms?** Both. Our team has shipped real-time Ethernet on Altera Cyclone III, IV GX and V SoC, on Xilinx Spartan, Artix and Zynq, on STMicroelectronics parts, on an NXP Arm SoC, on a TI Sitara applications processor and on a dedicated industrial communications IC. We port to new parts as launch enablement for vendors. **Can you train our engineers rather than just deliver the code?** Yes, and it helps to say what training does and does not achieve. The first return is a shared vocabulary and a shared basis for design decisions, so your team and ours are not solving the same problem in two languages, and the questions that would otherwise surface late get asked early. From there your engineers can take on integration, troubleshooting, first-line support and application-level customisation on their own. Depth in a protocol stack itself is built across years and several products rather than in one course, which is why training is paired with third-line support behind your first line. **How long does it take to add a protocol to a device?** It depends on the architecture, the platform, whether you are using a third-party stack, and whether the silicon is a new family port or a migration of one already supported. Two reference points from our own work. A PROFINET IO-Device built on a third-party stack, with your existing application logic migrated into function blocks rather than rewritten, is typically around eight weeks. Stack porting and development from scratch is more like twenty-four. **What drives the cost of adding a protocol?** Four things, and only one of them is our engineering. The implementation route sets the floor, because a software stack on a standard MAC, an SoC with protocol acceleration and a dedicated communications IC are different orders of cost in both silicon and effort. The stack licence comes next, and its shape matters more than its headline, because a development licence is often free while production licensing is seated per node, so your volumes decide what it actually costs. Certification is a multi-day lab booking charged by effort, plus the certificate fee. Then the engineering, which scales with whether this is a new silicon family or a migration of one already supported. We will not quote a stack vendor's numbers for them. Tell us the protocol, the platform and the volumes and we will size the whole picture with you. **Do you handle certification?** No. We prepare a device through pre-compliance testing and accompany the formal test. The certificate itself is issued by the protocol organisation's accredited lab. ### References - IEC 61158 / IEC 61784 — industrial communication network standards - IEEE 802.1Q (TSN: 802.1Qbv, 802.1AS) — time-sensitive networking - IEC/IEEE 60802 — TSN profile for industrial automation - PROFINET specification — PROFIBUS & PROFINET International (PI) - EPSG DS 301 — Ethernet POWERLINK communication profile - EtherCAT Technology Group (ETG) — EtherCAT specification and conformance - IEEE 802.3cg — 10BASE-T1L single-pair Ethernet ## Fieldbus & Device Networks URL: https://aeicor.com/services/fieldbus-device-networks/ Industrial fieldbus integration services for device makers and OEMs. CANopen, CAN FD/J1939, Modbus, IO-Link, AS-i and PROFIBUS DP/PA brought up on your hardware, with the device description files and conformance pre-testing that have to ship alongside them. ## What do industrial fieldbus integration services cover?Industrial fieldbus integration services port and bring up a device's communication stack on your hardware.
This is typically for device manufacturers, machine builders and instrument makers. We port and bring up CANopen, CAN FD and J1939, Modbus RTU and TCP, IO-Link, AS-i and PROFIBUS DP on your hardware, author the device description files that have to ship with them, and run the conformance test cases in-house before you book the lab. As an example, our team has delivered PROFIBUS PA interfaces for process pressure transmitters, carried PROFIBUS PA and DP segments forward unchanged through a controller platform replacement, and built CAN node software for marine and off-highway vehicle systems that transfers directly to J1939 and ISOBUS work. The engagement usually falls into one or more of these shapes: - **A device stack is ported** onto your MCU, SoC or FPGA and handed over with its build environment, brought up against real bus traffic and not a simulator. - **The master side is built**, where your product drives a segment instead of sitting on one. Fieldbus master development covers the mixed case too, a device that is a slave upward and a master downward. - **Configuration and compliance files are produced.** IODD device description development for IO-Link, EDD for process instruments, GSD for PROFIBUS DP, and FDT/DTM device driver development where a plant's frame application is the way in. - **A PC-side configuration and diagnostic tool is created**, the application that commissions, parameterises and diagnoses your device on the bus. - **The network and controller are chosen.** Fieldbus controller selection consulting that ends in a prototype on your hardware rather than a recommendation slide. - **Your engineers are trained** on the bus you have chosen, with the first device brought up alongside them. We do not commission machines or plants. The communication layer inside your product is ours to build and test, and we do that with your engineers, onshore while integration and test are running and remotely afterwards.Yes, often: the constraints that produced fieldbus have not gone away.
- **The constraints still hold.** A device network is chosen against device count, cable budget, power envelope, connector cost and what the customer's installed base already runs. On those terms a two-wire IO-Link drop or a CANopen segment is still the cheapest way to reach a sensor, and real-time Ethernet sits above them, not in place of them. - **Most machines run more than one.** They will keep doing so. Our work is usually adding one network to a product that already speaks another, so the effort goes into what the second network does to the timing, the power budget and the data model of a device that was designed around the first. ## What does a fieldbus device stack port involve?A port gets a protocol running correctly on a particular part.
The stack has to fit the memory the part actually has. The timing has to hold when the bus is busy, not only when it is idle. The object dictionary or process image has to match what the master expects. And the device has to behave when a segment is misconfigured, because in the field it will be. It is the same discipline our team applies on the Ethernet side, where communication stacks have been taken through conformance testing on several silicon families. Both ask one question: does this device behave correctly as a participant, under load, on a network the customer controls.A description file decides whether an engineer in the field can use your device without calling you.
An IODD, EDD or GSD is what a configuration tool reads to learn your parameters, their units, their permitted ranges and how to present them. Get it wrong and the device works while being unusable: - Parameters that display without units. - Ranges that let the controller write a setting at start-up that the firmware rejects. - A diagnostic code the tool cannot name. As an example, for IO-Link the description file is the manufacturer's responsibility. The consortium publishes the editor and the IODD-Checker that validates the result, and a manufacturer's declaration of conformity ships with the device. We author against the tools that will read the file, then validate on the frame applications a customer actually runs. FDT/DTM device driver development applies the same discipline to a frame application instead of a description file.Pre-testing saves a booking, and usually a launch date.
The consortiums say so themselves. CAN in Automation maintains the official certification laboratory for CANopen conformance approval, and its own guidance is to send pre-tested devices in. IO-Link, PI and the other bodies work the same way, with a checker or a test tool available to the manufacturer long before the formal attempt. We run your device against those test cases in-house, on real bus traffic, so problems surface during pre-testing and not at the formal attempt. The certificate is issued by the consortium's accredited lab, never by us. ## What to consider for a device that speaks to two networks?Two networks on one device is an architecture decision before it is a stack decision.
- **Shared state.** A device on two networks has to resolve shared state that a single-network device never faces: two masters with different ideas about the same object, or two cycles that were never designed to coexist. Deciding which side owns a parameter, and what the other side sees when it changes, is part of the design step. - **Where it becomes a gateway.** Where the answer is a translating device instead of a dual-stack one, the work moves to [device and network integration](/services/device-network-integration/), which covers architectures spanning several devices and networks rather than one device's protocol layer. ## Who develops the communication stack for a process transmitter?We do, and it is the protocol integration part of any transmitter project.
That is process transmitter device stack development, backed by the delivered PROFIBUS PA example above. A transmitter project splits three ways, and the split decides which of the three you need: | Target component | What it needs | | --- | --- | | The communication stack | Protocol integration (this page) | | The device itself: the board, the sensor front end, the firmware and the enclosure | [embedded systems](/services/embedded-systems/) | | The control application that consumes the measurement and acts on it | [control software](/services/control-software/) | Most transmitter projects need at least two of the three, and the scope follows from which parts those are. ### Frequently asked questions **Who does fieldbus stack work for a device manufacturer?** We do, as the communication layer inside your product rather than as an integrator on your customer's floor. Your team keeps the application, the sensor design and the customer relationship. We take the bus interface, bring it up and test it with your engineers onshore and remotely, and stay behind it as third-line support. **Is fieldbus not a legacy technology by now?** No. CANopen, CAN FD and J1939, IO-Link, Modbus and AS-i are specified in new builds every year, because they fit the device count, cable budget and power envelope the application actually has. Real-time Ethernet did not replace them; it sits above them. **How is this different from your real-time Ethernet work?** Primarily the protocol family. Fieldbus devices typically carry a smaller footprint than a real-time Ethernet device, lower payload volumes, slower refresh rates, tighter processing budgets and a lower cost per node, but the engineering discipline is the same, a stack, a driver beneath it and measured behaviour under load. Real-time Ethernet is covered on its own page. **Do you supply the stack, or do we license it?** Commercial stacks come with support and a licence, per product or per node. Open-source implementations remove the licence fee and leave you the maintenance. Some networks have no usable open option at all. We size that against your volumes and your service life, then port whichever you pick. We do not license or resell a stack ourselves. **Who writes the IODD, and do we own it?** You own it, and the responsibility for it sits with you as the device manufacturer. We author and validate it as part of the engagement and hand over the sources, so a later firmware revision does not need us. **Can you train our engineers rather than only deliver the code?** Yes. We offer protocol and technology training as a standalone engagement, and your engineers work alongside ours during development and integration on the first device. From there they can take on integration, troubleshooting and first-line support themselves. Depth in a stack is built across products rather than in one course, which is why training comes paired with third-line support behind your first line. **Do you certify the device?** No. We run the conformance test cases in-house so the formal attempt is not the first one, and we support the submission. The certificate is issued by the consortium's accredited lab, not by us. **Do you also build or migrate the soft-PLC on the device?** Yes, but as part of our control software integration, not this page. This page carries the fieldbus network across, as in the delivered EOL example above, where the PROFIBUS PA and DP segments moved onto new hardware unchanged. The soft-PLC and control application itself is covered on its own page, and the two are commonly scoped together on a controller platform migration. **Do you commission the machine the device goes into?** No. We build and test the communication layer inside your product, and integrate and test it with your engineers. Plant and machine commissioning stays with whoever owns that contract. ### References - IEC 61158 / IEC 61784 — industrial communication network standards, which allocate the protocol Types this page's networks sit under - CiA 301 — CANopen application layer and communication profile - CAN in Automation (CiA) — CANopen conformance test plan and the certification laboratory that issues the approval - SAE J1939 — CAN-based communication for commercial vehicles - IEC 61131-9 — IO-Link single-drop digital communication interface - IO-Link Consortium — IODD specification, the IODD-Checker validation tool and the manufacturer's declaration that ships with a device - IEC 62026-2 — AS-Interface - IEC 61784-1 CPF 3 — PROFIBUS DP communication profile ## Protocol Migration URL: https://aeicor.com/services/protocol-migration/ Fieldbus to Ethernet migration services for device makers and OEMs. We migrate a device onto a new network without rewriting the application logic that took years to get right. ## What do fieldbus to Ethernet migration services cover?Fieldbus to Ethernet migration services migrate a device from a legacy network onto industrial Ethernet.
This is typically for device manufacturers, machine builders and instrument makers. We migrate a device from a legacy network, CANopen, PROFIBUS DP, a serial link or HART, onto POWERLINK, EtherCAT, PROFINET, Modbus TCP or Ethernet-APL, and we carry the application logic across without rewriting it. The engagement usually falls into one or more of these shapes: - **An assessment before anyone commits.** What changes, what carries, and what the new network costs in cycle time, node count and payload, ending in a prototype running on your hardware. - **One product, one new network.** The whole migration of a single device or controller, from stack replacement through to acceptance at production speed. - **The carry-across only**, where you already have the new platform and need the accumulated logic ported onto it correctly. - **A dual-running period**, old and new coexisting while the installed base ships, with a planned cutover in place of a flag day. - **Re-testing on the new network.** Conformance pre-testing and acceptance for a migration somebody else performed. - **Your engineers taken through it.** Training runs alongside the first product's migration, with support behind your team as later products move. We move the product and the devices around it. We do not run floor migrations or commission machines. Our engineers work alongside yours through integration and acceptance, onshore for that phase and remotely after it. ## What changes in a migration, and what carries across?The stack, the driver and the timing budget change; the application logic and the data model carry across.
Four things change, and only the first is the protocol: 1. The stack changes. 2. The driver beneath it changes. 3. The application logic above it is ported, not rewritten. 4. The timing budget the whole product was designed around moves. The timing budget is the one that surprises programmes. A new network does not simply run faster; it changes the relationship between cycle time, node count and payload per cycle, and a device that was comfortable at one point on that curve can be marginal at another. Those three are specified figures for each protocol, so the assessment starts there and then measures your actual device against it. What usually carries across untouched is your accumulated engineering investment: the processing logic, the device data model, the calibration and parameter sets, and the meaning of your diagnostics.We migrate CANopen, PROFIBUS DP, serial and HART devices onto POWERLINK, EtherCAT, PROFINET, Modbus TCP and Ethernet-APL.
Six pairs come up repeatedly, and each has its own character: - **CANopen to POWERLINK or EtherCAT.** The most common request, driven by node count and cycle time. The object dictionary is the part that carries across most cleanly; the timing assumptions buried in the application are the part that usually does not. As an example, our team has taken a device network from CANopen to POWERLINK and held a *2 ms* cycle on the result. - **POWERLINK to EtherCAT.** Rarely about capability and usually about a customer's installed base or a procurement document. The two are close enough that the work concentrates on the process image and the master relationship. - **PROFIBUS DP to PROFINET.** The best-supported path in the industry, because both live under the same organisation and the migration was planned for. The GSD becomes a GSDML, and the device model largely survives. - **Serial to Modbus TCP.** The register map carries across almost unchanged, which makes this look like the easy one. The difficulty arrives later, when the application meets a TCP link that fails differently from an RS-485 one. A serial timeout and a dropped TCP socket are different failure events, and application code written for one does not handle the other correctly. - **HART to Ethernet-APL.** The instrument migration, and the one where the physical layer is the point: two wires carrying power and data into a hazardous area under the 2-WISE intrinsic-safety concept, with the digital data HART already carried finally arriving at full rate instead of through a 4-20 mA loop. | From → to | Transfers easily | Where the work is | | --- | --- | --- | | CANopen → POWERLINK or EtherCAT | The object dictionary | The timing assumptions in the application | | POWERLINK → EtherCAT | Most of the device; the two are close | The process image and the master relationship | | PROFIBUS DP → PROFINET | The device model; the GSD becomes a GSDML | Little: the best-supported path | | Serial → Modbus TCP | The register map | Handling TCP link failures | | HART → Ethernet-APL | The digital data HART already carried | The physical layer | ## Can the existing hardware carry the new stack?Often it cannot, and that is the first thing the assessment establishes.
Industrial Ethernet asks for more than a fieldbus did: a MAC and usually two ports with an integrated switch so the device can sit in a line topology, more flash and RAM for the stack, and for the isochronous protocols, silicon with protocol acceleration or an FPGA behind it. An MCU chosen years ago for a CANopen node rarely has any of that. So a fieldbus to Ethernet migration is frequently a board change as well, and the assessment is where that gets decided, before any hardware is committed to. Where the hardware is being replaced anyway, the two jobs are cheaper together: [embedded systems](/services/embedded-systems/) covers the new board, and [obsolescence management](/services/obsolescence-management/) covers the case where a discontinued part forced the change in the first place. ## Should I migrate the device, or put a proxy in front of it?Sometimes the proxy is the right answer, and we will say so.
PROFINET defines the proxy in its own specification: a device on the Ethernet network that represents a whole PROFIBUS segment behind it, so existing slaves keep running unmodified. Gateways do the equivalent job for other pairs. - **What it buys.** Nothing is re-certified, nothing is re-tested, and a working segment stays working. - **What it costs.** It carries process data reliably and often carries little else. Diagnostics, parameterisation and device-specific services frequently do not survive the translation, so the engineer at the controller loses visibility of the device behind it. It adds a translation hop the original design did not have, and it leaves the obsolete network in the field, where the parts still have to be bought and the skills still have to be kept. The practical test is what you are selling. A machine builder keeping a plant running chooses the proxy. A device manufacturer whose customers now specify Ethernet gets no benefit from one, because their product is still a PROFIBUS product. If the proxy is the answer, the work belongs to [device and network integration](/services/device-network-integration/).A migration starts certification again.
A device that was certified on PROFIBUS DP is not certified on PROFINET, and the test suite it has to pass belongs to the new network, not the old one. Migration budgets commonly miss this, and it surfaces late, after the schedule is already public. We run the new network's conformance test cases in-house before the lab is booked, on the migrated device itself. The certificate is issued by the accredited lab, as it was the first time. ## When is a migration the wrong answer?A migration is the wrong answer when the network is not the constraint.
- **A part went end-of-life.** If a product is being forced onto new hardware because a controller, processor or FPGA went end-of-life, that is a platform problem and it belongs on [obsolescence management](/services/obsolescence-management/), where the network and the logic both stay put. - **Several devices have to interoperate.** If the real requirement is that several devices on different networks must interoperate, that is [device and network integration](/services/device-network-integration/) and nothing needs migrating at all. We say so at the assessment stage, because the expensive version of this mistake is discovering it after the stack has been replaced. ## How do you keep the installed base supported during a migration?We do not require the installed base to move.
A fleet in the field is still generating revenue and still under support obligation, so a migration that strands it has failed regardless of how well the new variant works. The practical answer is a period where both variants are built and supported from one codebase, with the network layer isolated well enough that the difference stays contained instead of spreading through the application. The isolation has two benefits: it makes the current migration containable, and it makes the next one cheaper, because vendor module lifecycle schedules are often out of your control.Device network integration services cover the gateways, translation layers and tests that make several devices behave as one system.
This is meant for machine builders, device manufacturers and system integrators. As an example, our team has delivered gateway hardware holding a *2 ms* cycle across *eighteen* units on one machine, and has demonstrated Sercos III interoperating with OPC UA over TSN. The engagement usually falls into one or more of these shapes: - **A gateway that does not exist yet.** Modbus CANopen gateway integration, or any other pair where the off-the-shelf box maps the registers but not the behaviour. - **One box, several stacks.** Multi-protocol industrial gateway development where two or more protocols share a processor and hold incompatible ideas about when they get it. - **Analogue and serial devices brought forward.** 4-20 mA sensor to fieldbus integration, RS-485 serial device integration, and HART device data integration where the digital data already exists and never arrives anywhere useful. - **Interoperability testing.** Two vendors' devices run against each other properly, before a commissioning window discovers the problem. - **Your device inside someone else's architecture.** Device integration and test, with our engineers alongside yours during the phase where it matters. - **An edge device at the boundary.** Industrial edge device development in its southbound sense, a box that collects and normalises from the device side. We do not commission plants, floors or machines. The translation layer, the mapping and the test rig inside your product or your machine are ours to build, and we integrate and test them with your engineers, onshore while that phase is running and remotely afterwards. Two boundaries, because two of our pages sit close to this one. Against [real-time Ethernet](/services/real-time-ethernet/): that page is one device's protocol layer, this one is the architecture across several. Against [industrial IoT and edge integration](/services/industrial-iot/): that page runs northbound, data becoming information for MES, ERP and cloud, while this one runs southbound, protocol to protocol, toward the devices.A catalogue gateway fits more often than buyers expect, and we evaluate that with you during design.
| What the job needs | Catalogue gateway | Custom device | | --- | --- | --- | | Process data between two common protocols | Fits | Overkill | | An update rate that absorbs a translation hop | Fits | Overkill | | The diagnostics of the device behind it | Drops them | Carries them | | A pairing nothing off the shelf maps | No mapping | Built for it | | A coherent snapshot across two cycle rates | Samples | Reconciles | | Device state and parameterisation across the crossing | Values only | All of it | | A box that ships inside your product | Third-party part number | Yours | | Behaviour mapped, not registers | Not modelled | Designed | Specifying a catalogue part is a legitimate outcome of that call, and it is cheaper than anything we could build. The same question for a northbound gateway, one publishing to MES, ERP or cloud, is answered on [industrial IoT and edge integration](/services/industrial-iot/), where the catalogue is different and so is the test. ## What are the common pitfalls in gateway development?Data translation is typically straightforward, while timing, state and failure are the critical parts.
We reproduce on the bench what the plant will do, and write down in the test plan what it cannot.
Yes, one purpose-built device usually replaces them, and the saving compounds across the machine's service life.
- **What a mixed cabinet carries.** Four vendors' IO modules, a serial converter and a protocol gateway mean four supply chains, four end-of-life exposures, four sets of firmware, and a commissioning procedure that has to account for all of them. - **What one purpose-built device removes.** Most of the above, once the interfaces are the ones the machine actually uses instead of the ones the catalogue happened to offer. - **Which parts we do.** The gateway and network side of the consolidation is this page; the device itself, board, enclosure and firmware, is [embedded systems](/services/embedded-systems/). The two are usually scoped together. ## How do you integrate instruments that are already digital?We read the digital data the loop already carries and patch it onto the same data network backbone.
For example, HART has carried digital diagnostics over the 4-20 mA loop for decades, and in most plants that data is never read, because reading it needed a handheld and a person standing next to the instrument. Bringing it onto a network is a small piece of engineering relative to the diagnostic value it unlocks, and it pairs naturally with the two-wire Ethernet path on [protocol migration](/services/protocol-migration/) when the loop itself is being replaced. ### Frequently asked questions **Who builds a gateway between two industrial networks?** We do, as a device inside your machine or your product rather than as an integrator on your customer's floor. Your team keeps the machine and the customer relationship. We take the translation layer, the mapping and the test rig, work through integration with your engineers onshore and remotely, and stay behind it as third-line support. **How is this different from real-time Ethernet integration work?** Scope. Real-time Ethernet is one device's protocol layer, done properly. This page is the architecture across several devices and several networks, where the hard part is what happens between them rather than inside any one of them. Most integration work sits on a real-time Ethernet layer underneath it. **What is the difference between this and IIoT edge integration?** Direction. This page translates protocol to protocol, OT to OT, southbound toward the devices. Industrial IoT and edge integration translates data to information, OT to IT, northbound toward MES, ERP and cloud. A single project often needs both, but they are different disciplines with different failure modes. **Do you write Sercos device stacks?** No. Sercos slave-stack work for a device typically sits with that device's own manufacturer, often built on a vendor-supplied module or IP core. Our Sercos work is gateway and interoperability integration, making a Sercos III segment interoperate with the rest of an architecture, and our team has demonstrated exactly that alongside OPC UA over TSN. **Can you work with our architecture if you are not allowed to see it?** Yes, and it changes the test plan rather than the engineering. Where the target architecture cannot be replicated in our lab, we build against the specification and the device documentation, reproduce what we can, and write the remainder into a test plan for the integration window. We say which parts are verified and which are assumed, in writing, before the integration window opens. **Do you commission the installation?** No. We deliver the integration and test the solution with your engineers, then hand it to the team that commissions the installation. We do not do plant, floor or machine commissioning, and we do not run FAT or SAT. ### References - IEC 61158 / IEC 61784 — the communication profiles a gateway maps between - IEC 62443-3-2 — risk assessment for zones and conduits, which is what a gateway becomes once it crosses a segment boundary - IEC 61131-9 — IO-Link, the usual entry point for sensor-level integration - NAMUR NE 107 — diagnostic status signalling, the vocabulary a bridged instrument's health has to survive in - CiA 309 — CANopen access from other networks, the specification behind the CANopen side of a gateway - Modbus Application Protocol — the register and data model a Modbus gateway maps between - IEC 62541 — OPC UA, the usual northbound interface above a protocol gateway ## OPC UA & Information Modelling URL: https://aeicor.com/services/opc-ua/ OPC UA information modelling consulting for device makers and OEMs. We design the address space, apply or extend the companion specification, and build the servers and clients that expose it. ## What does OPC UA information modelling consulting cover?OPC UA information modelling consulting designs the address space from the machine's real signals.
This is for device manufacturers, machine builders and software vendors. We design the address space from the machine's real signals, apply or extend the IEC 62541 companion specification that fits it, and build the servers and clients that expose it. Our own modelling tool generates NodeSet2 from base and companion specifications; it produced the *EUROMAP 79* robot model for a delivered plastics and rubber machine. The engagement usually falls into one or more of these shapes: - **A model for a new product.** OPC UA system design and architecture, from the machine's signals to a NodeSet2 a customer's MES can browse. - **A companion specification applied properly.** IEC 62541 companion specification work, including extensions for signals the specification does not cover. - **Server or client development.** OPC UA server and client development on embedded, Linux or Windows platforms. - **One endpoint over many machines.** OPC UA aggregating server development, where the machines already speak OPC UA and the problem is fan-in. Our team has built the layer through which a remote ERP subscribed to several machines on one production line. - **A migration.** OPC DA to OPC UA migration, or EUROMAP OPC UA version migration where the companion spec moved underneath a shipped product. - **The security model.** OPC UA security model implementation, certificate and trust list management, and the policy migration described below. We do not commission plants. The model, the server and the security design inside your product or platform are ours to build, and we test them with your engineers onshore and remotely.The information model, and it decides whether everything downstream is cheap or expensive.
Two vendors' machines that both expose typed, companion-spec models can be consumed by one MES integration. The same two machines exposing bare tag lists need one integration each, then another when either changes. The cost does not appear at the machine; it appears every time somebody has to consume it. OPC DA to OPC UA migration is modelling work, not a protocol swap. A DA tag list carries the plant's meaning implicitly, in naming conventions and in the knowledge of the people who built it. We make that meaning explicit as typed, structured data. Wrapping the same tag list in an OPC UA server without doing so carries the same problem forward. ## Which companion specification applies to my machine?Start by looking: most machine categories now have one, and building a private model beside it is a decision.
Plastics and rubber machinery has the EUROMAP series, and our delivered work sits there: EUROMAP 83 for the general type definitions, 77 for the injection moulding machine to MES interface, 79 for robots and handling devices. Machine tools have umati. VDMA has published across a long list of sectors, and the OPC Foundation maintains the full register. Two things regularly need deciding: - **How to extend the model where the specification does not reach**, designed against the spec's own type system, not a set of extra tags bolted on beside it. - **What happens when the companion spec moves version** underneath a product already in the field. EUROMAP OPC UA version migration is a dedicated exercise, because a customer's MES integration is bound to the types you shipped.The choice narrows once volume and support obligations are considered, and the licence rarely decides it.
| Stack | What it is | When we reach for it | | --- | --- | --- | | **open62541** | C99 under an open licence, with no runtime or per-node fee. Its sample server carries an OPC Foundation certification, and the project documents server binaries well under 100 kB depending on the model they carry, which matters on a constrained device | Our default where it fits, and it fits often. It carried the delivered plastics and rubber machine work. The project's own guidance is to talk to a commercial vendor for a mission-critical product, and we repeat that guidance | | **S2OPC** | A formal, security-focused pedigree: CSPN certification from ANSSI, an EN 50128 SIL2 lineage | Where a certified, secure stack matters more than the smallest footprint. Our own secured OPC UA PubSub demonstrator over TSN was built on it | | **node-opcua** | A Node.js implementation | The platform is already Node.js, or the client is a web application | | A commercial SDK | A support contract, a longer feature surface, certification artefacts and somebody to call, at a licence cost usually per product or per node | A machine builder shipping in volume with a long service obligation, where it can be the cost-effective answer | We do not resell any of them. We port and integrate whichever you choose, and we give our recommendation on which and why before you decide. ## What makes an OPC UA server slow?Usually the access pattern, and occasionally the stack's own address-space design.
A client that polls reads every configured tag on a fixed interval whether or not anything changed, so five hundred tags across twenty machines produce the same load at three in the morning as they do mid-shift. Subscriptions with monitored items invert that: the server watches the values and notifies the client when they move, which is what the services were designed for. - **The address-space design** is the smaller of the two effects. A static, compiled-in address space is marginally faster than one that has to fetch each value from an external store on every read. - **The tuning that gets skipped.** Sampling interval and publishing interval are two different settings and are routinely set to the same number. Queue size and the discard policy decide which values in a burst are kept. A deadband stops a noisy analogue value generating traffic that nobody reads. The model itself is the other half. An address space that is deep, flat in the wrong places or built from thousands of untyped variables is expensive to browse and to subscribe to, and no amount of client tuning recovers it. This is a second reason the modelling comes first.No, and the two meet at the data layer.
- **What the model generates for a twin.** A typed structure with real semantics that something else can subscribe to. That is the foundation, and it is a capability we have delivered, including a EUROMAP 79 robot model produced by our own modelling tool. - **What it does not do.** OPC UA modelling does not include building Asset Administration Shells, behavioural or simulation models, or working on twin platforms such as Azure Digital Twins, MindSphere or Predix. The word "twin" gets stretched to cover all of these, so it matters which part of the design each piece actually covers. ## What has changed in OPC UA security?The SHA-1 policies are deprecated, and Basic256Sha256, Aes128_Sha256_RsaOaep and Aes256_Sha256_RsaPss are the live path.
A deployment still running either of the older two is running on something the standard has withdrawn. | Security policy | Status | Why | | --- | --- | --- | | Basic128Rsa15 | Deprecated since OPC UA 1.04 | SHA-1, and RSA PKCS#1 v1.5 padding | | Basic256 | Deprecated since OPC UA 1.04 | SHA-1 | | Basic256Sha256 | Current | The RSA baseline most stacks ship | | Aes128_Sha256_RsaOaep | Current | The replacement for Basic128Rsa15 | | Aes256_Sha256_RsaPss | Current | AES-256 with RSA-PSS signatures | | Original ECC policies (nistP256, nistP384, brainpoolP256r1, brainpoolP384r1, curve25519, curve448) | Deprecated | Replaced by the AES-GCM and ChaCha-Poly variants below | | ECC AES-GCM and ChaCha-Poly variants (e.g. ECC_nistP256_AesGcm) | Current | Elliptic-curve keys; check stack support before choosing | The operational side is harder than the cryptographic side. Certificate and trust list management is what typically fails, often in year three, when a certificate expires on a machine nobody has logged into since commissioning. We treat certificate renewal and distribution as a deliverable, and where PubSub is in play, the security key service is part of the same design. ## When does OPC UA need TSN underneath it?OPC UA needs TSN when data has to arrive deterministically, within a bounded latency.
OPC UA PubSub over TSN integration is where the modelling and the network meet: the same information model, published over PubSub with a bounded delivery time. Our team has integrated OPC UA with TSN on an NXP i.MX Arm SoC under openIL, and a [secured PubSub demonstrator](https://www.youtube.com/watch?v=ryDe6tkwNsQ) held a 1 ms cycle with security active. Below that sits the determinism engineering itself, the gate schedules, the drivers and the measurement, which is [real-time Ethernet](/services/real-time-ethernet/) work, not data modelling. And where the requirement calls for DDS's fine-grained, per-topic QoS control (reliability, durability, deadline) instead of OPC UA PubSub's simpler publish/subscribe, the architecture belongs to a different family of middleware, which is what [data distribution](/services/data-distribution/) covers. ### Frequently asked questions **Who designs an OPC UA information model for a machine builder?** We do, working from your machine's real signals. Your team keeps the machine, the control logic and the customer relationship. We take the model, the server and the security design, build them with your engineers, and stay behind them as third-line support. **Do you build the MES, or connect our machines to one?** The machine side, and the client where it ships as a product. We build the server and the information model that a customer's MES can browse, and we will develop an OPC UA client into a software platform. Selecting, configuring and commissioning an MES on a plant floor stays with the MES integrator's contract, and we work alongside them during integration and test. **What's the difference between OPC UA and DDS?** They are different kinds of thing. OPC UA is a model and is transport-independent; DDS couples the model to its transport through RTPS. Putting both on one page conflates a modelling standard with middleware. Data distribution has its own page. **Does OPC UA PubSub need a broker?** No, not necessarily. PubSub Part 14 defines both a brokerless UDP multicast mapping and a broker-based mapping over MQTT or AMQP. Which one fits depends on the network. Peer-to-peer on a local segment usually wants UDP multicast, while reaching beyond it needs a broker. **We already have OPC UA servers on our machines. Do we need a gateway?** Probably not a translation gateway. Where the machines already speak OPC UA, an aggregating server acting as a client to each of them gives one endpoint without converting anything, and the output is still OPC UA. If that data still needs to reach an ERP or BI system that does not speak OPC UA itself, closing that last gap is edge conversion, not aggregation, and it is industrial IoT and edge integration work, covered on its own page. A gateway, translating between the other protocol and OPC UA, is what you need when something in the estate does not speak OPC UA at all. **Can you train our engineers on the model as well as hand it over?** Yes, and it changes the economics more than usual, because a model gets extended every time the product does. Your engineers work with ours on the first version, then own the resulting NodeSet2 model. We stay behind them for the companion-spec and security questions that come up later. **Do you certify our OPC UA implementation?** No. We build it, test it against the companion specification and support a certification submission. Certification is issued by the OPC Foundation's process, not by us. ### References - IEC 62541 — OPC Unified Architecture, supplying the address space, type system and services every companion specification is written in - EUROMAP 83 — general type definitions for plastics and rubber machinery - EUROMAP 77 / 79 — injection moulding machine to MES, and robots and handling devices - OPC 10000-2 — the OPC UA security model, including the policies a modern deployment is expected to run - open62541 — the open-source IEC 62541 implementation we build on, whose sample server carries an OPC Foundation certification - S2OPC — open-source OPC UA implementation with CSPN certification from ANSSI and an EN 50128 SIL2 pedigree, used on our secured PubSub over TSN demonstrator - node-opcua — open-source Node.js/TypeScript OPC UA implementation, the fit for a JavaScript platform or client ## Data Distribution & Messaging URL: https://aeicor.com/services/data-distribution/ Broker vs brokerless industrial data architecture. We design and build the data-centric middleware and publish-subscribe layer that carries production data between machines, with configurable delivery guarantees per topic. ## What do you cover under broker and brokerless industrial data architecture?Broker vs brokerless industrial data architecture: it is the first decision in any industrial publish-subscribe design.
We make it against latency, participant count and failure behaviour rather than against the library that was prototyped with. Our delivered proof here is an engine-room control system built on a DDS backbone. The engagement is usually one of these shapes: - **The architecture decision on its own.** Broker or brokerless, argued against your requirements and recorded with the reasoning. - **A DDS backbone.** DDS backbone industrial work from topic and type design through to a running system, including mobility and engine-room cases where redundancy is the point. - **MQTT with real state.** MQTT Sparkplug B industrial data distribution, with the birth and death semantics that separate it from plain MQTT. - **A real-time production data pipeline.** Machine-to-machine communication and device-to-device industrial data exchange at rates a request-response design cannot hold. - **Bridging control and telemetry.** Where a brokerless control layer and a brokered telemetry layer both exist, the mapping between them. Topics, types, delivery guarantees and failure behaviour, in that order. A publish-subscribe architecture for industrial data is a set of promises about what happens when a subscriber is slow, when a publisher dies, when a participant joins late and wants history, and when a link comes back after being gone. Those promises are configuration in most middleware, and they are often left at the default. We specify them per flow, because a setpoint and a diagnostic log do not want the same reliability, durability or deadline. We do not commission plants or machines. The distribution layer inside your product or your platform is ours to design and build, and we prove it under participant churn and link loss with your engineers, onshore while that phase is running and remotely afterwards.A broker is often the right answer when the extra hop fits inside the latency budget.
It gives you one place to observe, authorise and buffer, and a topology that a firewall and an IT department can reason about. | When | Not when | | --- | --- | | Telemetry | The extra hop no longer fits inside the latency budget | | Store-and-forward across an unreliable link | The broker becomes a single point of failure the system cannot tolerate | | Anything crossing a site boundary | Participant count and message rate make it the bottleneck everything else queues behind | The right-hand column is the set of conditions that justify DDS and the configuration work it brings with it: discovery is peer to peer, delivery is direct, and the guarantees are expressed per topic instead of per broker. ## What does quality of service decide in a DDS system?Quality of service decides whether the system degrades or fails.
- **Reliability** decides whether a lost sample is retransmitted or forgotten. - **Durability** decides whether a subscriber that joins late gets history or starts blank. - **Deadline** states the rate a subscriber is entitled to expect, which is what turns a slow publisher into a reported fault rather than a silent one. - **Liveliness** decides how quickly a dead participant is noticed. - **History** decides how much is kept while a subscriber is behind. These settings cascade: a domain-wide default is a starting point, and the entity closer to the data, the writer or reader QoS, is what actually wins. A domain default applied to every flow either spends resources on traffic that does not need them or starves traffic that does. A lot of the value in a DDS engagement is in that configuration table. ## Which DDS implementation is suitable for us?The trade-offs are the same ones a fieldbus or real-time Ethernet stack faces.
There are a few attributes to consider besides the licence. | Implementation | Licence | What to consider | | --- | --- | --- | | FastDDS · Cyclone DDS · OpenDDS | Open source | All three run down to embedded Linux and RTOS targets, so the common assumption that DDS needs server-class hardware is mistaken. Footprint and the discovery traffic a constrained node has to absorb are the primary constraints, and both are measurable. We typically start from FastDDS, for the ROS 2 reason below | | RTI Connext | Commercial, usually per product or per node | The largest commercial vendor. A licence buys a support contract, certification artefacts for regulated programmes and dedicated support. For a product with a long lifecycle and a service obligation attached, it can be the cost-effective option over the life of the programme | The platform question and the licence question are the same question, because the constrained target is usually what narrows the field first. We size both against your volumes and your hardware, then build on whichever you pick. We do not license or resell a DDS implementation ourselves. ## Can a DDS system span more than one site?A DDS system does not span more than one site by default.
DDS discovery is scoped to one multicast domain, which in practice means one site or one VLAN. Participants find each other automatically inside it and not at all outside it.Data distribution sits above the network and beside the information model.
- **What sits beneath it.** The determinism that lets a distribution layer meet a deadline is engineered at the network: gate schedules, drivers, measurement. That work sits with [real-time Ethernet](/services/real-time-ethernet/). - **What sits beside it.** The typed, browsable description of what a machine means, which a supervisory system browses rather than subscribes to, is [OPC UA and information modelling](/services/opc-ua/). The three are usually all present. What decides which one owns a given flow is whether the consumer needs to browse it, subscribe to it, or be guaranteed it by a deadline. ### Frequently asked questions **Who designs a broker vs brokerless industrial data architecture?** We do. It is the first decision in any industrial publish-subscribe design, and we make it with you against latency, participant count and failure behaviour, not against the library that was prototyped with. **Have you delivered DDS in production?** Yes. An engine-room control system was built on a DDS backbone, and that is the delivered proof behind this page. **Do you do ROS 2 work?** We design and build DDS backbones that ROS 2 can sit on, and FastDDS is a deliberate choice on our side for exactly that reason. **What about DDS in vehicles and aerospace?** Standards and architecture work, not a delivered system. The architecture is public, OMG published DDS-TSN 1.0, and AUTOSAR Adaptive specifies a DDS binding. We design against both, though we have not built an inter-vehicle or flight system ourselves. **Is this not the same conversation as OPC UA?** No. OPC UA is a model and is transport-independent; DDS couples its model to RTPS. DDS pairs naturally with MQTT and Sparkplug B, which are also transports with opinions. Information modelling has its own page. **Should we choose OPC UA, DDS or MQTT/Sparkplug B?** By what the consumer needs, not by preference. OPC UA gives a typed, browsable information model over a connection a supervisory system queries or subscribes to. MQTT and Sparkplug B give a lightweight publish-subscribe transport with no model of its own, which is why Sparkplug adds the state and structure a plain MQTT payload lacks. DDS gives peer-to-peer delivery with per-topic QoS control and no broker in the loop. Most estates end up running more than one, and the boundary is usually who is subscribing and how fast. **How much latency does a broker add?** It depends on the broker software, the hardware underneath it and the number of hops in your topology, so a single published number would mislead more than it helps. We measure it against your own architecture at the design stage. **Does DDS support security and encryption?** Yes, through the DDS-Security specification, which defines authentication, access control and encryption as separate pluggable services and not one fixed mechanism. Which plugins a design needs depends on the threat model, and we scope that alongside the topic and QoS design. **How do you debug a publish-subscribe system once it is in production?** With the same discipline as the QoS design itself. Liveliness and deadline settings turn a silent failure into a reported one, and protocol-level tools exist for both transports, from an RTPS traffic dissector to plain MQTT client tools for topic-level inspection. What we design in from the start is which of those signals actually reaches an operator. **How do you migrate a system from request-response to publish-subscribe without a rewrite?** Incrementally, and usually behind a bridge rather than in one cutover. The existing request-response path keeps running while topics are migrated one at a time and verified against it before it is retired, so a failure in the new design shows up as a mismatch rather than an outage. **Can you train our engineers, not just hand over the code?** Yes, as the training, co-development and long-term support offering above describes. Your engineers work through the topic and QoS design alongside ours on the first system, then take on extension and first-line support themselves, with our third-line support behind them for as long as the system runs. ### References - OMG DDS — the Data Distribution Service specification, and RTPS as its wire protocol - OMG DDS-TSN 1.0 — how a DDS deployment maps onto TSN scheduling, published April 2023, Beta2 May 2024 - Sparkplug B — the payload and state specification that gives plain MQTT the birth, death and rebirth semantics industrial data needs - ISO/IEC 19464 — AMQP, where a durable queue and not a topic is the right shape - OMG DDS-Security — authentication, access control and encryption as separate pluggable services rather than one fixed mechanism - IEC 62541 — OPC UA, the transport-independent information modelling standard ## Industrial IoT & Edge Integration URL: https://aeicor.com/services/industrial-iot/ Brownfield IIoT retrofit engineering and greenfield edge integration. We get machine data northbound into MES, ERP and cloud, and audit the connected product against CRA and IEC 62443 obligations. ## What does industrial IoT and edge integration cover?Industrial IoT and edge integration covers everything between a machine's control layer and the business systems that consume it.
That means collection, normalisation, a data model worth consuming, transport northbound, and the security and compliance posture that lets any of it leave the plant. There are three entry points into that work. Brownfield IIoT retrofit engineering on lines that cannot stop. Greenfield edge integration on products being designed now. And a CRA compliance audit for industrial devices, which become regulated products the moment they are connected. This page runs northbound, data becoming information for MES, ERP and cloud; [device and network integration](/services/device-network-integration/) runs southbound, protocol to protocol, between devices. Our team has built OPC UA to MQTT connectors for a remote-service platform on agricultural machinery, integrated OPC UA into Azure, delivered Node-RED modules into a customer's cloud, and built a central gateway that lets any remote ERP pull live data from several machines over OPC UA, in place of the customer's legacy MQTT bridge. The engagement is usually one of these shapes: - **An edge gateway or edge device.** Edge gateway development and industrial edge device development in its northbound sense, thin or thick depending on where the processing belongs. - **A bridge between two data worlds.** OPC UA to MQTT bridge development, OPC UA to HTTP REST bridge work, or a DDS to OPC UA gateway. - **Getting an installed line to talk.** Industrial network gateway retrofit and brownfield asset connectivity, without controller replacement. - **The enterprise hop.** MES ERP OT integration edge gateway work, and the OT/IT convergence design around it. - **Cloud telemetry and command.** Machine-to-cloud integration, device-to-cloud telemetry and cloud-to-device command and control. - **An audit.** Industrial device security audit against IEC 62443, and CRA readiness on a product that is already shipping. An installed estate has to give up its data without being replaced. A new product has to be born connected and compliant. Or an existing connected product has to be audited against obligations that arrived after it shipped. We do not commission the plant. We build a proof of concept, turn it into a deployable solution, and hand it to the commissioning party, with our engineers working alongside yours through integration and test.The CRA requires a secure update path, vulnerability handling and a generated SBOM, for the product's whole supported life.
Regulation (EU) 2024/2847 has applied vulnerability and incident reporting duties since 11 September 2026, with full enforcement from 11 December 2027, and it covers products with digital elements placed on the EU market. Each of the three has to hold in the field: the update path on units already deployed, the vulnerability process with somebody behind it, and the bill of materials generated rather than hand-written.The retrofit runs alongside the controllers and never in the control path, so the line keeps running.
It is additive: OPC UA connectivity for existing production lines is built alongside the controllers, not through them, reading what is already there and publishing it northbound. Nothing about the machine's control behaviour changes, which is what makes the change schedulable in a maintenance window instead of a shutdown. Where a data path already exists, such as a legacy MQTT bridge, it is replaced in stages: the new path reads alongside it, runs in parallel while the old path stays primary, and switches over in one planned window with the old path kept as a fallback.The economics reverse: designing the data model, security posture and update path in costs a fraction of retrofitting them.
| | Retrofit | Greenfield | | --- | --- | --- | | What constrains the design | Equipment that already exists | Yours to set | | What needs to be engineered | Working around the existing constraints | Designing the data model, the security posture and the update path in, at a fraction of what they cost later | The data model, the security posture and the update path are one design conversation, not three, because each constrains the others. What a device reports shapes what a secure update has to touch, and both shape what evidence a CRA audit will later ask for. Greenfield designs are routinely under-invested here, on the assumption that connectivity can be added at the end. It can, but retrofitting it costs substantially more, particularly once a CRA obligation attaches to a fleet that has no update mechanism. ## When is an off-the-shelf edge gateway the right answer?A catalogue gateway fits when the protocol pair is standard and nothing about the data model has to be designed.
Vendors including Hilscher and HMS Networks (Anybus) sell edge gateways covering the common fieldbus-to-MQTT and fieldbus-to-OPC UA combinations, and for a single machine on a well-known protocol a catalogue part is usually the right call and often the cost-effective one. Specifying one is a legitimate outcome of an assessment, and we will say so before any design work starts. Where cost is the deciding factor, a software-only connector on existing hardware is a third option and is frequently cheaper than either. Custom engineering earns its cost when one of three things is true: - The combination is not one anybody sells. - The gateway has to sit inside your product with your service story behind it, instead of beside it in a cabinet as a third-party part number. - The data model has to be designed for the consumer rather than generated from the controller's default tags. The equivalent question on the southbound side, protocol to protocol between devices, is answered on [device and network integration](/services/device-network-integration/). ## Where is the handoff boundary between edge and cloud?The boundary is placed on latency, on bandwidth, and on where trust has to stop.
Thin edge thick edge architecture is driven by those three factors, not picked as a product category. A thin edge collects and transports, and the analysis happens in the cloud. A thick edge runs the analysis locally and sends the conclusions. Most real systems sit between the two and move along that range over their service life, which is why we treat it as a cloud-edge continuum instead of two fixed places.Machine condition monitoring and automated inspection are engineered into the machine or the product.
That means multi-channel acquisition, on-machine signal processing, and a transport design to filter and send the essential data upstream for analysis. As an example, our team has built acquisition and transport designs correlating piezo vibration, current and temperature at the drive and fan ends sub-second at the controller, and line-scan inspection systems classifying a moulded consumer product at production rate. Condition monitoring and in-line inspection are two disciplines, and they sit on one page because our engineering underneath both is shared: sensing choice, sample rate, correlation, and what leaves the machine. Monitoring watches the machine's own health over time. Inspection judges each part the machine produces. The engagement is usually one of these shapes: - **A readiness assessment.** A predictive maintenance readiness assessment or machine health assessment and audit that states what the machines can already support, including when the answer is "not much yet". - **The acquisition layer.** Multi-channel data acquisition with sensor placement, sample rate and channel correlation designed around the fault. - **On-machine processing.** Vibration analysis for predictive maintenance and motor current signature analysis run at the machine, so a developing fault shows in a trend held locally instead of waiting for the next bulk upload. - **Data reduction and transport.** What is kept at full rate, what is aggregated, what is sent upstream, and over which transport. - **An in-line inspection system.** Automated optical inspection integration, from image acquisition on the line's own camera stack through to classification at line rate. - **An online condition monitoring system, end to end**, built inside the machine, including the third-party sensing units, gateways and analytics backends it has to work with. Note that we do not sell an off-the-shelf monitoring product. Four decisions sit behind all of them, and they are taken in this order: 1. Which fault you are trying to catch. 2. Where you have to sense to see it. 3. How fast you have to sample before it becomes invisible. 4. What analysis runs on the result. Most projects start at the last one, but it needs the insight generated from the previous three steps. A model cannot recover information that was never sampled. The sample rate follows from the fault's P-F interval: the time between the point where the fault becomes detectable and the point where the machine fails. A rate chosen to suit a historian's ingest budget can miss that interval entirely, and the dataset then holds no trace of the fault. Most of the value we add is upstream of the analytics, in the acquisition and transport design. We do not instrument plants or commission machines. The monitoring layer inside your machine or your product is ours to design and build, and we integrate and test it with your engineers, onshore while that phase is running and remotely afterwards.The sampling design can be revisited, but the data-reduction half of it is irreversible.
Once a machine has aggregated a signal to a one-minute average and discarded the rest, the transient that was the early warning is gone. The data-reduction decision is a design commitment, and it is made per signal, not per system. Some channels justify full-rate capture and a fast transport, and most do not. In practice the bands fall out at roughly 100 ms, 40 ms, 10 ms and 1 ms depending on what the signal is for, and the transport selection follows from the band: | Data-reduction band | Transport | | --- | --- | | Slow | An OPC UA history read against the controller | | Fast | A publish-subscribe path: OPC UA PubSub, MQTT or DDS | | Correlation-critical | Read from the PLC directly | Those paths are established in the readiness assessment, before anything is committed, because they decide what the backend can be asked to do afterwards. That is where this work meets [OPC UA modelling](/services/opc-ua/) above it and [real-time Ethernet](/services/real-time-ethernet/) beneath it.You do, or your data platform does.
We design the acquisition and transport layer to feed a historian, an MES or a named analytics backend, and we treat that target as given. Selecting and operating it is a platform decision with its own procurement. Where a controller exposes what is needed, the acquisition layer works across PLC brands, because it runs over standard paths and not through vendor-specific tooling. ## Where does in-line inspection differ from condition monitoring?The measurement is an image, and the judgement is per part instead of per trend.
- **Image processing first.** Most in-line inspection is image processing. The camera vendor supplies an SDK and an imaging stack, usually OpenCV-based, and thresholding, morphology and dimensional checks on that stack resolve the majority of defect classes without any model at all. That is the first thing we try, because it is faster to build, cheaper to run and easier for a quality team to explain. - **A trained classifier second.** It goes in where image processing cannot separate the classes: variable, natural or textural defects where the rule is not expressible as a threshold. When that step is needed we train the model against your labelled examples, and we benchmark the architecture against the number of examples it needs. A heavier model that classifies marginally better but needs several times the labelled examples is the wrong choice for a deployment that has to produce those examples on a running line. As an example, our team has built a line-scan inspection system for a moulded consumer product, separating correctly formed units from partially formed, empty and incomplete ones.It gets retrained, and we design for that from the start.
A product change, a lighting change or a line-rate change can all move a classifier's accuracy, and on a running line at least one of the three will happen. The same benchmarking process runs again against fresh labelled examples, so the model size sets the number of training iterations and the cost of each round of change. Your team is typically the one producing those examples on a running line, and once the architecture is established the retraining can be done by the same team.We cover custom BSP, industrial SoC selection and embedded firmware development for device makers, machine builders and silicon vendors.
We select the part, design and bring up the board, write the board support package for the peripherals the reference design does not cover, and build the firmware above it. Our team has shipped this work on Xilinx Zynq, Altera Cyclone parts, TI Sitara and Renesas RZ/N-class silicon. The engagement is usually one of these shapes: - **A device you have not built yet.** Custom device development from silicon selection and industrial PCB design through bring-up to shipping firmware. - **A third-party board, brought to life.** Board bring-up and hardware validation on hardware you already have, including the peripherals the reference design does not document. - **A BSP for a new part.** Custom BSP industrial SoC work, which is most of what "porting Linux" means in practice. - **Firmware onto new silicon.** Firmware porting industrial SoC-side, where the application is proven and the platform underneath it changed. - **A reference design for a vendor.** Silicon vendor reference design and BSP work, so a new part arrives with something a customer can build on. - **The radio.** Wireless industrial device design across BLE, Zigbee and wireless HART, industrial Wi-Fi, RF front-end design, or UHF RFID reader development. Most embedded projects run into trouble one layer below the application: a peripheral with no driver, a BSP that boots but drops interrupts, or firmware that behaves on the bench and misses its deadline in a cabinet at temperature. That layer is the work we take on: - **Silicon selection**, which constrains every decision made after it. - **Board design and bring-up**, to the point where the software team can treat the hardware as known-good. - **The BSP**, covering the peripherals a reference design leaves out. - **Firmware**, across bare metal, RTOS and embedded Linux. - **Peripheral bus integration** across I²C, SPI and UART, along with the memory interfaces, Ethernet PHYs and high-speed signals that account for a large share of the defects and rework found during bring-up. What we do not do is commission machines or plants. We build the device inside your product and integrate and test it with your engineers.A timing guarantee moves into hardware when the deadline is tighter than a software scheduler can honour.
Jitter matters more than throughput here. On tuned real-time Linux with a driver written for determinism, the practical boundary sits in the tens of microseconds of jitter, which is where our delivered NIC driver figure in the FAQ below sits. Below that band the timing moves into hardware, and there is more than one route: | Route | Example part | What it does | | --- | --- | --- | | FPGA fabric | Cyclone 10 GX with PCIe | Holds the timing while software handles everything without a deadline | | SoC with a real-time subsystem | PRU-ICSS on TI Sitara parts | Does the same job on one device | | Dedicated real-time Ethernet controller | ADI fido5100 · fido5200 | Puts the protocol timing in silicon | | NIC that timestamps and launches frames in hardware | Intel i210 | Removes the same jitter from a standard host without any programmable fabric | | SoC-FPGA | Cyclone V SoC (Arm Cortex-A9) · Zynq | Puts Arm cores and fabric on one device, so the software and the timing share one chip | Which route is suitable depends on volumes, protocol and the timing and processing budget. The same reasoning is why some of our work runs on hybrid arrangements such as an x86 host with an FPGA across PCIe, brought up as one platform. On TI Sitara parts our team integrates TI's PRU-ICSS protocol firmware with the customer's application, builds the interface between the Arm and PRU sides, and tests the combination until the defects that only appear under real traffic are isolated and closed.Low-power design changes the architecture decision and part selection as well as the optimisation level.
A low-power embedded design changes which silicon is eligible, how the radio duty-cycles, whether a peripheral can stay enumerated between samples, and what the firmware is allowed to do while nothing is happening. Three things have to be designed into the hardware rather than added later: - **Power domains that can be switched**, so peripherals and whole sections can be turned off and brought back predictably, with the sequencing, inrush and oscillator start-up that implies. - **A way to keep time while it sleeps**, usually a low-power real-time clock or a separate always-on timer domain, because the main oscillator is usually disabled in deep sleep modes. - **Headroom for peak current**, because a weakening battery can still run the board at rest and then sag when the radio or an actuator draws its peak. Local storage capacitance, or a staggered power-on sequence, holds that peak so a critical function does not fail first. Small form-factor board design tightens the same loop again, because thermal headroom is low at that size. Both constraints set the silicon and topology choices.We build the device itself: the board, the sensor front end, the firmware, the enclosure and the power budget.
A process transmitter programme splits three ways and most need at least two of them. Its communication stack is [fieldbus and device networks](/services/fieldbus-device-networks/), and the control application that consumes the measurement and acts on it is [control software](/services/control-software/). ### Frequently asked questions **Who develops custom BSPs and firmware for industrial devices?** We do. We select the part, design and bring up the board, write the board support package for the peripherals the reference design does not cover, and build the firmware above it, for device makers, machine builders and silicon vendors. Our team has shipped this work on Xilinx Zynq, Altera Cyclone parts, TI Sitara and Renesas RZ/N-class silicon. **Do you design the hardware as well, or only the software?** Both, and we prefer them together, because the driver and BSP constraints are cheapest to satisfy while the schematic is still open. We can also join once the hardware exists and take only the BSP, firmware and bring-up layers. **Which silicon families have you worked on?** Xilinx Zynq and Spartan, Altera Cyclone V SoC and Cyclone IV GX, MAX 10, ARM Cortex-M and Cortex-A parts, TI Sitara, Renesas RZ/N-class parts, STMicro parts on RF work, Intel Atom and Raspberry Pi. Our team also ports to parts it has not used before, which is routine work as launch enablement for a vendor. **Do you cover drivers and middleware as well?** Yes, and they have their own page. The device's own firmware is covered here. Host-side drivers, Windows and Linux kernel work, RTOS driver porting, middleware and real-time platform tuning are covered under system software, because they are a different discipline. **Can you meet hard real-time deadlines under Linux?** Within limits. On tuned real-time Linux with a driver written for determinism, our custom NIC drivers hold an 80 µs network cycle at 20 µs jitter. That is the same band open-source EtherCAT masters reach on PREEMPT_RT, where published evaluations report 100 µs cycles with jitter in the tens of microseconds. Below that band, or where jitter has to be sub-microsecond, it needs specialised hardware or a NIC that timestamps in hardware. **How does part lifecycle affect silicon selection?** It is one of the inputs we weigh, alongside toolchain and supply, and published dates from the vendor make it checkable. We track each vendor's published commitment for the specific parts on your shortlist, but we cannot quote a vendor's roadmap on their behalf. For example, in April 2026 Altera extended lifecycle support for Agilex, MAX 10 and Cyclone V through 2045, after being spun out of Intel in 2025. Dates like that do move, which is why we re-check them at each design review instead of relying on a roadmap seen once. **How do you assure compatibility when porting firmware to new silicon?** We start by fixing the interface. The driver and BSP layer absorbs what changed between the old part and the new one, and the application above it is regression-tested against the same test suite on both platforms before cutover. **Can you review a schematic and pin-mux before we send a board to fab?** Yes, on hardware you or a partner designed, as a lighter-weight version of the same board work covered above. ### References - IEC 62443-4-1 / -4-2 — secure product development lifecycle and technical security requirements for components, which a connected device is built against - IEC 61131-9 — IO-Link, a common device-level interface on an industrial instrument - IEEE 802.15.4 / Bluetooth Low Energy — the short-range radios behind most industrial wireless device work - IPC-2221 / IPC-6012 — generic standard on printed board design, and qualification and performance requirements for rigid printed boards - JEDEC JESD22 / IEC 60068 — environmental and thermal stress test methods for electronic components and equipment - Yocto Project — build system for custom Linux distributions and reproducible BSP build environments ## Drivers, System Software & Real-Time Platforms URL: https://aeicor.com/services/system-software/ Cross-platform driver development for industrial devices and the platforms that host them. NDIS miniport and intermediate drivers, Linux kernel drivers, RTOS porting, and real-time platform tuning. ## What does driver and system-software work cover?Cross-platform driver development for industrial devices covers middleware and the operating systems that host them.
That means driver development on both sides of the kernel boundary, the packet or transfer path beneath a protocol stack, the scheduler and interrupt behaviour that sets jitter, and the middleware above it. A typical real-time Linux optimisation we deliver runs an 80 µs network cycle at 20 µs jitter with a custom NIC driver. The engagement is usually one of these shapes: - **A Windows driver.** NDIS miniport driver development where the device is the adapter, an intermediate driver where it has to sit over one, or a kernel-mode driver for a device that is not a network adapter. - **A Linux kernel driver.** Linux kernel network driver development, or device and platform drivers across bulk, serial, network and hybrid FPGA-attached hardware. - **Real-time tuning and validation.** Real-time platform tuning and validation, measured under load, with the configuration and the numbers handed over together. - **An RTOS port.** FreeRTOS driver porting, eCos RTOS development, Zephyr, micro-C/OS or SYS/BIOS TI-RTOS work, usually after a platform migration. - **A platform migration.** Windows IoT Enterprise LTSC migration for a machine builder whose release is out of support. - **Redundancy.** High-availability industrial control redundancy, where the requirement is that a node failure is survivable, not merely detected. The distinction between a typical embedded systems scope and this one is that [embedded systems](/services/embedded-systems/) covers the software running on the device's own silicon, while this service includes the software the host runs to talk to it. Many products need both, and the same engineers often do both, but they are separate disciplines with separate development and failure modes.Windows does not hold a deadline in the way the question usually means, and a qualified answer is more useful.
Windows runs a 15.6 ms tick by default and can be configured down to 1 ms. That is timer resolution, not cycle time, and the two are different quantities. For a worked example, openPOWERLINK's Windows-only platform documents an achievable cycle above 10 ms for a pure-software stack. That 10 ms is not a floor imposed by the timer. It follows from network size and PDO configuration: | Cycle | Nodes sustained | | --- | --- | | Around 1 ms | One or two | | 5 ms | Three to five | | 10 ms | Ten or more, with substantial TPDO and RPDO configurations | So it is a design-input dependent criterion, not a fixed limit. This is fixed with a hybrid architecture, where the communication controller moves out of Windows entirely onto bare-metal silicon, in this case an FPGA running a soft processor, and Windows samples network data at 1 ms to 5 ms depending on network size while determinism stays in hardware. Extending the same openPOWERLINK example, the Windows platform reaches 250 µs with an external PCIe-based NDIS miniport solution against above 10 ms in pure software. This is a result from an open-source implementation, with published numbers, cited here as confirmation of the architecture. ## Which NDIS driver class should my network device use?It depends on whether the adapter is dedicated or shared, and the two classes trade determinism against flexibility.
- **A miniport driver** manages the physical adapter directly. It is preferred when the requirement is dedicated real-time performance, because every additional layer in the path is another queue that can hold your frame. - **An intermediate driver** is a protocol driver on its upper edge and a virtual miniport on its lower, sitting over a real miniport, which is how several applications can share one adapter. That sharing is the right choice when the requirement is virtualisation. We deliver both classes.A Windows platform migration is mostly planning the lockdown rebuild, not porting the application.
A machine builder still shipping on a Windows IoT release that Microsoft discontinued typically has that platform because it still works, but it does not receive security updates, and it may fail a customer's procurement review. A planned phase-out means migrating to Windows IoT Enterprise LTSC, where the dates are the selling point: the 2021 release is supported to 2032 and the 2024 release to 2034. The primary migration target is rarely the application. It is the lockdown configuration that made the old machine behave like an appliance, covering Unified Write Filter, Shell Launcher, Assigned Access, Keyboard Filter, Device Guard and Credential Guard, plus drive encryption where the device holds customer data. That configuration is rebuilt against the new release.The difference is architectural: Windows queues deferred work and preempts by priority, while real-time Linux shortens its non-preemptible sections.
On Windows the determinism-critical behaviour (the packet path for both is drawn under [What does driver and system-software work cover?](#what-does-driver-and-system-software-work-cover)) lives in deferred procedure call and interrupt-level queuing, and in how a priority thread is allowed to preempt. Real-time Linux attacks the same problem by shortening the kernel's non-preemptible critical sections, so what improves is worst-case latency under load; average throughput can be slightly lower as a result. Our measured jitter on a tuned real-time platform is under 20 µs under load, and the OSADL QA farm's continuous testing under timer, memory, network and filesystem stress is the public corroboration for that class of result. The two directions of the data path are optimised differently. On the receive side, optimisation means moving to a zero-copy mechanism such as AF_XDP, or to poll mode such as DPDK where the hardware or the OS does not support it, trading optimisation against portability. On the transmit side three mechanisms are in current use: launch time on Intel i210 and i225 parts, time-based scheduling as IEEE 802.1Qbv standardised it, and the Linux ETF and taprio queueing disciplines that drive it. The determinism engineering above that layer, covering gate schedules, benchmarking and hop-by-hop verification, is covered on [real-time Ethernet](/services/real-time-ethernet/). ## What is involved in porting a driver to an RTOS?The same OS driver challenges are solved against a vendor HAL instead of a kernel driver model.
The core device-control logic reuses well. Four things do not carry over: 1. The memory model becomes static instead of dynamic. 2. Interrupt handling becomes chip-specific. 3. DMA descriptor handling is rewritten against the HAL. 4. A change requires a full rebuild and reboot, where a kernel module could have been reloaded live. The trade is even. There is no kernel-version compatibility churn to track, which is a real saving over a product's life, and there is vendor HAL lock-in instead, which is a real cost. ### Frequently asked questions **Who does cross-platform driver development for industrial devices?** We do. One device made to work properly under Windows, Linux and an RTOS, covering NDIS miniport and intermediate drivers, Linux kernel network and device drivers, RTOS driver porting, and the real-time tuning underneath all of them. A typical real-time Linux optimisation we deliver runs an 80 µs network cycle at 20 µs jitter with a custom NIC driver. **Which is the right OS for a real-time industrial product?** It depends on the deadline, and often either can be made to work. Where determinism is tight, the reliable pattern is to move the time-critical path off the general-purpose operating system, onto an FPGA or a dedicated controller, and let Windows or Linux handle everything without a deadline. **Do you publish a Windows versus Linux latency comparison?** No. A single head-to-head number does not transfer well, because the result depends on the hardware, the driver and the tuning far more than on the operating system name. Real-time extensions for Windows are current products, so a Windows platform can be made deterministic. We publish our own measured figures and describe the difference architecturally. **How is this different from your embedded systems services?** They intersect, but each needs a different discipline. Embedded systems is the device's own software, running on the device's own silicon. This service is the host operating system's software, meaning the driver, the kernel path and the scheduler. **We are still on a discontinued Windows IoT release. Is that urgent?** It is dated, but not urgent. Windows 10 IoT Enterprise LTSC 2021 is supported to 2032 and Windows 11 IoT Enterprise LTSC 2024 to 2034, so a migration planned now buys a decade. Scheduling it now, while the release is supported, makes the upgrade a planned one. **What does driver development cost, and how long does it take?** A Windows NDIS driver, a Linux kernel driver and a real-time tuning pass are different pieces of work on different platforms, so one figure would cover none of them. We estimate it at the enquiry stage against the device class and which platforms your customers require. **Can you keep an out-of-tree Linux driver compatible across kernel versions?** Yes, and it is the ongoing cost this class of driver carries. An out-of-tree driver has to be rebuilt and sometimes reworked against each kernel it targets, which is why we treat kernel-version tracking as part of long-term support. **Do you tune PREEMPT_RT for our specific hardware, or is it generic?** Hardware-specific. PREEMPT_RT sets the ceiling on what is achievable, but the actual worst-case latency comes from your platform's interrupt controller, its DMA behaviour and the other peripherals sharing the bus, so the tuning pass is measured on your hardware under your load, not applied from a generic configuration. **What happens when we move from one Windows IoT LTSC release to the next?** The lockdown configuration is rebuilt against the new release instead of carried over, because Unified Write Filter, Shell Launcher, Assigned Access and the rest are reconfigured per release. Drivers are the other item to check, since a driver signed and tested against one release is not guaranteed on the next without revalidation. ### References - Microsoft Learn — NDIS driver classes, timer resolution and the Windows IoT Enterprise LTSC lifecycle dates - openPOWERLINK Windows platform documentation — the cycle times achievable with a software-only stack against a PCIe NDIS miniport solution - OSADL QA Farm — continuous latency measurement of real-time Linux under timer, memory, network and filesystem load - IEEE 802.1Qbv — time-based scheduling, the standardised form of the launch-time mechanism these drivers drive ## SCADA, DCS & Control Application Development URL: https://aeicor.com/services/control-software/ SCADA software development for machine builders. The supervisory, control and diagnostic application layer, built into your machine or product and handed over with it. ## What does SCADA software development for machine builders cover?SCADA software development for machine builders covers the application layer and the middleware above a machine's real-time control.
That means supervisory logic, the diagnostics that explain what went wrong, the HMI through which both are reached, and the data collection that feeds the systems above. DCS work runs alongside it on this page and achieves a different goal. SCADA supervises and reports on a process that a controller runs. A DCS distributes the control itself across the process, and what we build there is a component inside it, while you own the architecture. The engagement is usually one of these shapes: - **A supervisory application for a machine.** SCADA software that ships as part of the product instead of being specified at the site. - **A component inside a distributed architecture.** DCS system design and component development, where you own the architecture and need one part of it built. - **Soft-PLC work.** IEC 61131-3 soft-PLC development, or soft-PLC runtime integration and migration where a runtime targets a different platform or is embedded into your own product, including running it as the controller on a PROFIBUS, PROFINET, EtherCAT or EtherNet/IP network. - **One application, several PLC brands.** Multi-vendor PLC integration for machine builders, which is nearly always a customer-driven requirement. - **Diagnostics and HMI.** Machine diagnostics and monitoring application development, and industrial HMI application development, usually together. - **The data collection layer.** Data collection application development where the machine has to feed an MES, an ERP or a historian above it. The edge-to-cloud half of that path is described in [industrial IoT](/services/industrial-iot/). The data model is the part most often underestimated. A tag list assembled during commissioning works until someone adds a machine variant, integrates an MES, or has to explain why two screens disagree. Designing the model at the start keeps the next variant an extension instead of a rebuild. We do not commission control systems on a plant floor. The application layer inside your machine or your product is ours to build, and we integrate and test it with your engineers onshore and remotely.We treat the controller interface as a normalised hand-off boundary, so the brand-specific part is an adapter.
The application above it does not change. A machine builder selling into several plants meets several controller estates, and the alternative is a maintained variant per brand. The abstraction is usually attempted late, after a few variants are already integrated and have drifted apart. Designed in from the start it is a bounded design exercise. Retrofitted, it first requires working out what each variant actually does, which is the time-consuming part.Safety application software sits alongside machine control, developed against the functional-safety standards the machine has to meet, such as IEC 61508 and IEC 62061.
- **Developed to the functional-safety standard.** Safety application software follows the same engineering discipline as machine control, plus what the standard adds for the target safety integrity level: a defined safety lifecycle, independent verification and validation, and documentation for each phase. - **Evidence built from the start.** That evidence is normally built against a certification body's guidance from the start of the project rather than assembled at the end. Bodies such as TÜV SÜD offer paid assessment support during development, which is the usual pattern and is what keeps late deviations small. We develop the software and prepare the evidence; we do not issue the certificate. - **Safety over the network is part of network design.** A safety layer proving itself end to end over an ordinary control network is engineered as part of the network design, and sits with [real-time Ethernet](/services/real-time-ethernet/) and [device and network integration](/services/device-network-integration/).The control software covers the control application that consumes a transmitter's measurement and acts on it.
Because a process transmitter project splits across three of our service pages, the transmitter's own communication stack is covered in [fieldbus and device networks](/services/fieldbus-device-networks/), and the device itself, meaning the board, sensor front end, firmware and enclosure, is covered in [embedded systems](/services/embedded-systems/). Most transmitter projects need at least two of the three. ## What do you cover as part of the control application development service?We cover development of the control software and middleware and support what we built; we do not cover plant-scale commissioning.
- **What we cover.** We design, build, integrate and test the application, and we support what we built for as long as the support agreement runs. That includes the data model, the runtime work, the diagnostics and the HMI, and it includes working alongside your engineers through integration and acceptance. - **What we do not.** Plant-scale commissioning, floor maintenance, or generalist management consultancy around an automation estate. Where a project needs a plant-side integrator, we say so at the proposal stage. On multi-vendor work we build a proof of concept, turn it into a deployable solution, and hand it to the party that commissions it, with onshore integration support where it is needed. ### Frequently asked questions **Who does SCADA software development for machine builders?** We do, as an application layer inside your machine or product. We build control software, covering SCADA software development for machine builders, DCS component development, soft-PLC integration, and the diagnostic and HMI software that ships with a machine. We do not commission control systems on factory floors, and we do not take on plant-side maintenance. **Do you commission SCADA systems on a plant floor?** No. We develop the application and integrate and test it with your engineers. Plant, floor and machine commissioning, FAT and SAT, and factory-floor maintenance stay with the existing contractor. For multi-vendor work we build a proof of concept, turn it into a deployable solution, and hand it over. **How is this different from your system software service?** System software is the platform underneath, meaning the drivers, the kernel path, the RTOS and the real-time tuning that decide whether a cycle holds. This service is the application above it, meaning the supervisory logic, the soft-PLC application, the diagnostics and the HMI. A soft-PLC project often needs both, and they are scoped as separate pieces of work. **Do you also build test and measurement software?** Yes, and it has its own page. Supervisory control and automated test share almost no vocabulary, proof or procurement path, which is why they are separated. End-of-line and functional test systems are covered on the test systems page. **Do you certify safety applications?** No. We develop control and safety application software against the relevant functional-safety standards and take it through pre-certification testing. Certification is issued by an accredited test laboratory. **How is a soft-PLC runtime licensed?** Per node or per copy, the same shape as a fieldbus or real-time Ethernet stack licence. The licence is the runtime vendor's and not ours, and it is estimated against your production volumes as part of runtime selection. **Can IEC 61131-3 logic move between different soft-PLC runtimes?** Partly. IEC 61131-3 standardises the programming languages, structured text, function block diagram, ladder and the rest, so the logic itself is portable in principle. What does not travel automatically is the runtime-specific IO mapping, vendor libraries and timing behaviour around it, and re-verifying those is real work even when the logic compiles unchanged. **Is a soft-PLC on embedded Linux faster than on Windows, or the other way round?** Linux, in the general case, and the runtime vendors document it themselves. CODESYS states that its Windows runtime has soft real-time properties with latency and jitter in the range of several milliseconds, which rules it out for typical motion applications, while its Linux runtime can be paired with a real-time extension. Windows is the usual home for the engineering and visualisation tools, not for the runtime holding the cycle. Before integration we settle this from the real-time requirements of your system and from measurements from your platform, instead of a generalised benchmark number. **How do you handle diagnostics when a soft-PLC runtime fails in the field?** The failure behaviour is specified alongside the normal behaviour, in the same data model. If a runtime goes silent, or keeps reporting its last known state after a fault, it is harder to diagnose than one that reports a clear failure, so we integrate and verify the runtime's watchdog, heartbeat and last-value handling as part of the design instead of leaving them at the runtime's default settings. **Do you manage control logic versioning and rollback?** Yes, as part of the delivery discipline. Application sources are version controlled, and each handover is a tagged release package with a defined rollback path. ### References - IEC 61131-3 — programming languages for programmable controllers, and the basis of a soft-PLC runtime - IEC 61508 / ISO 13849 — functional safety for control systems and machinery, which safety application software is developed against - IEC 62541 — OPC UA, the usual interface between a control application and everything above it - ISA-95 / IEC 62264 — enterprise-control integration, where a supervisory layer meets MES ## Obsolescence Management & Platform Migration URL: https://aeicor.com/services/obsolescence-management/ Two halves of the same problem. Legacy PLC obsolescence management when a part disappears, and platform migration when a controller, OS or FPGA family ends, with the function and the logic preserved in both. ## What does legacy PLC obsolescence management cover?Legacy PLC obsolescence management covers the whole distance from the first lifecycle notice to shipping the replacement.
Two things have to survive that distance unchanged: what the equipment does, and the application logic accumulated inside it. As an example, our team has delivered form-fit-function replacement boards across a ten-board family moving from a Spartan-class FPGA to an Artix-class successor, with nothing the machine could observe changing. The engagement is usually one of these shapes: - **An audit before it is urgent.** Obsolescence risk audit and BOM screening, which is far cheaper than reaching the same finding under a notice deadline. - **A notice that has arrived.** EOL, PCN or PDN. PCN PDN response engineering, establishing what it affects, what it costs, and which path to take. - **A bridge.** Last-time-buy bridge engineering, with the quantity justified against the redesign timeline. - **A replacement board.** Form-fit-function replacement PCB work, or drop-in replacement components where the change has to be invisible. - **A platform move.** Controller and OS platform migration, VxWorks, eCos or SYS/BIOS onto Linux or FreeRTOS, or SoC and FPGA family migration. - **A kernel move.** Linux kernel version migration for device drivers, which stays a contained job until the drivers are out of tree. - **Ongoing cover.** Long-term product support for an embedded product, so the next notice arrives against a plan that already exists. Screening a bill of materials against lifecycle status catches an at-risk part early. When a notice arrives, we run an assessment before any purchase order is committed. Last-time-buy stock is estimated against the redesign it is buying time for, and a substitution is complete only after it has been re-verified against the envelope the original was accepted under. In every case the result has to be indistinguishable from the original where it matters, with evidence that can be retraced. We do not commission machines or plants. The replacement design, the migration and the evidence behind them are ours to produce, and we integrate and test with your engineers onshore and remotely. ## Why is a platform migration planned differently from a component EOL?The difference is what triggers them.
A component end-of-life arrives as a letter with a date on it. A platform ending has to be assembled from several sources: the RTOS vendor's roadmap, the FPGA family's last order date, and the end of the kernel's long-term support (LTS). The second is more predictable, which also makes it easier to postpone. Either way, both end in the same place: the same function, on new hardware or a new platform, with the logic preserved.It is derived backwards from the redesign, not forwards from current consumption.
- **What that avoids.** A common miscalculation, buying a round number of years of demand, which either strands capital in stock that outlives the product or runs out during a redesign that took longer than the optimistic estimate. - **What it depends on.** How long the replacement will genuinely take to design, qualify and ramp, plus the margin you want between the replacement reaching production and the stock running dry.We make the published support date part of the design checklist and track it through production.
We re-check it when the vendor landscape changes. For example, Altera, independent again since 2025, extended lifecycle support for its Agilex, MAX 10 and Cyclone V families through 2045 in April 2026. For anyone doing FPGA lifecycle and long-term availability planning, a published date that far out is a real input. That does not remove the need to plan. It changes what the plan is: with a twenty-year horizon the risk moves from the silicon to the toolchain, the build environment and the people who understand the design. A rebuildable build environment is therefore another deliverable on every engagement we take. ## What does re-qualification after a component substitution require?Re-qualification proves that the substitution changed nothing it was not allowed to change.
In practice that is three things: - **EMC re-verification.** - **Environmental re-testing** against the original envelope. - **Functional-safety re-verification** against IEC 61508, where the component sits in a safety-related loop.Automated test equipment development covers four parts: the fixture, the interface to the unit, the sequencer and the output.
Each is designed and verified separately because each can fail on its own. A fixture that holds the unit and makes contact. An interface that decides whether that contact yields a valid measurement. A sequencer that runs the plan and decides pass or fail. And the output, which determines whether the result is usable downstream. The engagement is usually one of these shapes: - **A complete end-of-line station.** End-of-line functional test system development for a part entering production, hardware and software. - **The fixture on its own.** Test jig and fixture development where the test plan exists and the mechanics do not. - **The DUT interface.** Device under test interface design, where contact, protection and repeatability are the engineering. - **The software over your instruments.** Test sequencing and measurement software, so a bench of scripts becomes one station with one result format. - **An inherited station.** Taking over something already in production and establishing what it measures today. Contact repeatability is the most common source of trouble in production. A station that measures reliably on a bench and drifts on a line has usually not lost its instruments; the contact has changed, and the software has no way to detect it unless it was designed to.We treat contact quality as a measured quantity, so wear shows up as measurable drift before it causes false rejects.
A fixture makes contact thousands of times, and the resistance of that contact drifts well before it fails outright. A station with no allowance for this reports a gradual increase in marginal units, which then gets investigated as a manufacturing problem. The design answer is a known-good reference the station checks itself against, plus thresholds that separate a failing unit from a failing fixture, both specified as part of the test plan. The insertion count also sets the contact plating, hard gold over nickel for low-level signals, and whether contacts are field-replaceable.The sequencer is configured to define what happens outside the happy path, and hands back a consumable result.
- **Fault handling.** Running a passing sequence is straightforward. A production station also has to handle a unit that does not respond, an instrument returning nonsense, a fixture that is half-closed, and an operator intervening mid-sequence. Each of those ends in a defined, recorded state rather than an exception. - **The output.** A per-unit result that reaches the plant's systems in a form they already consume gets used, while an incompatible log file does not integrate well. This is usually done via live data collection similar to [OPC UA or northbound integration](/services/industrial-iot/).Test systems borders embedded systems and protocol conformance work, and stops short of supervisory control.
| Test target | Where it is scoped | Why | | --- | --- | --- | | The device or unit being tested | [embedded systems](/services/embedded-systems/) | It is frequently a device of that kind, which is useful when deciding what to measure and where the failures are likely to be | | The communication interface | [real-time Ethernet](/services/real-time-ethernet/) · [fieldbus](/services/fieldbus-device-networks/) | The test plan draws on the conformance pre-testing we do there | | Supervisory control | [control software](/services/control-software/) | It is not part of automated test systems because the buyers share almost no vocabulary and no procurement path | We build and hand over the station and the interface along with the test system. Installation and commissioning on a production floor stays with the existing contractor team, and our engineers work alongside yours through integration and acceptance. ### Frequently asked questions **Who does automated test equipment development?** We do, for tier suppliers, device manufacturers and engineering providers, covering end-of-line functional test systems, the jigs and fixtures beneath them, and the sequencing and measurement software that makes a station repeatable. As an example, our team builds automotive test jigs for tier-1 engineering providers as an ongoing service. **What do you cover as part of the ongoing test-jig service?** New stations for new parts, changes to existing stations when a part or a test plan changes, fixture refurbishment as contact wear accumulates, and support on stations already running in production. **Do you provide automated test systems as part of DCS or SCADA control software?** No. Control software is the supervisory and control application for a machine. This is test and measurement, and the two are separated because the buyers share no vocabulary and no procurement path, even though the engineering underneath overlaps. **Do you calibrate or certify the test station?** We build the station, establish its repeatability and document it. Where a measurement has to be traceable to a standard, calibration is performed by an accredited body. We design for it, but do not certify it. **Can you take over an existing test system?** Usually. The first task is establishing what the current station measures today, which is a normal starting point on any inherited equipment. **Do you install the station on the production line?** We build it, integrate and test it with your engineers, and hand it over. Installation and commissioning on a production floor stays with the existing contractor team. **What does an end-of-line test station cost, and what is the lead time?** A fixture surviving thousands of insertions and a bench of scripts brought under one sequencer are different pieces of work, so a rate card would misprice both. We estimate each against the DUT, the volume and the test plan at the enquiry stage. **What framework do you use to run the sequencing software?** We do not resell sequencing software. We build into the framework your setup already uses, for example NI TestStand with LabVIEW or LabWindows/CVI, OpenHTF, a pytest-based Python harness, or Vector CANoe and vTESTstudio where the test is of an automotive bus, with instrument control over SCPI and VISA. Which one it is follows from your instruments and your volumes. The discipline that matters is the failure handling, covering a fixture half-closed, an instrument returning nonsense and an operator intervening mid-sequence, each ending in a defined, recorded state. This discipline travels across whichever environment the project calls for. **What contact materials do you use for high-insertion-count fixtures?** Depends on the insertion count and the signal requirement. Gold plating, usually hard gold over nickel, suits low-current and low-voltage signals and high insertion counts, because the contact resistance stays low and the surface does not oxidise. Tin and palladium-nickel are the lower cost alternatives, used where the signal carries enough current and voltage to break through an oxide film and the required cycle life is lower. The choice follows from the insertion-count requirement in the test plan. **How do you plan support for regulatory traceability in the per-unit result?** The output format is defined against what your compliance requirement has to capture, and the per-unit record is designed to reach the plant's systems in a form they consume, which the traceability offering above covers. We do not hold or claim a specific regulatory certification ourselves. **What cycle time or throughput do your automotive test jigs achieve?** Throughput is derived against the part and the line rate at the design stage, so a figure from one station does not carry across to another. **How do you establish test coverage and build a fault-injection matrix?** Coverage starts as a list of the failure modes the station has to catch, taken from the design and from field returns, and each one is mapped to the test step that detects it. It is then verified on the built station by forcing those conditions through the fixture, a shorted pin, an open contact, an out-of-range supply, and checking that the station reports the expected failure. Anything that passes when it should have failed is a coverage gap, and it is closed before the station is accepted. **How do you catch a test station drifting after it has been running for years?** By having the station measure a known-good reference unit on a set interval and trending the result, so a slow change in contact resistance shows on that trend before it reaches the units, instead of surfacing as a batch of marginal parts blamed on manufacturing. On a station that was not built that way, we add the reference measurement and a scheduled check, along with an insertion count on the fixture, during refurbishment. ### References - IEC 61010-1 — safety requirements for electrical equipment for measurement, control and laboratory use - ISO/IEC 17025 — the competence requirement that sits behind an accredited calibration, and the reason calibration is not ours to perform - IEC 61000-4 series — electromagnetic immunity testing, which a measurement station is designed to operate within - IPC-9252 — requirements for electrical testing of unpopulated printed boards - JEDEC JESD22-A104 — temperature cycling, used in burn-in and soak sequencing --- # Industries ## Manufacturing URL: https://aeicor.com/industries/manufacturing/ Whether you build machines, modules or silicon, we help you get ahead in your target market. Firmware and protocol depth, obsolescence cover, and the IIoT capability to keep your products current. ## 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](/engagement/) 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. | Market or requirement | Interface usually expected | | --- | --- | | DACH and much of the EU | PROFINET | | North America | EtherNet/IP | | Tight coordinated motion | EtherCAT or POWERLINK | | Builder supplies drive and controller both | POWERLINK | | Legacy and cost-sensitive installed base | PROFIBUS, Modbus RTU or TCP, CANopen | | Line data to MES or ERP | OPC UA, increasingly with a companion specification | 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.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](/industries/packaging-machinery/) and [material handling](/industries/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 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](/services/industrial-iot/) that proved it. That edge-and-gateway shape is what most drive-vertical work looks like for us.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](/services/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](/services/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. ### Frequently asked questions **Whose name goes on the result?** Yours. We build to your specification as your engineering partner, and we never approach your customer. We do not sell competing products into your market. **Who owns the code you write?** You do, on the terms agreed at the start of the engagement. Where the work sits on an open-source stack such as openPOWERLINK or open62541, the result is not locked to us either, which is part of why those stacks get chosen. **Can you work with a stack that is already licensed?** Yes. A good share of our work is integrating a commercial stack you already own onto your hardware. You choose the stack; making it meet its timing on the chosen silicon is our half of the job. **Do you issue conformance certificates?** No, and no engineering firm can. Certificates are issued by the protocol organisation's accredited test laboratory. We prepare the device, run the test suites in-house first, and support the submission. **How small can a first engagement be?** One protocol, one board or one obsolescence assessment. Most retained relationships here started as a scoped piece of work. ### References - IEC 61158 / IEC 61784 — the fieldbus and real-time Ethernet protocols named on this page, and the profiles that say which parts of them each one uses - IEC 61784-3 — the functional-safety communication profiles layered on top, including openSAFETY - IEC 61131-3 — the PLC programming languages a soft-PLC runtime implements - IEC 62541 — OPC UA, including the PubSub part used for TSN work - IEC/IEEE 60802:2026 — the TSN profile for industrial automation, which fixes the option set a converged plant network can require - IEC 62402 — obsolescence management as a discipline - PROFIBUS and PROFINET conformance is carried out by test laboratories accredited by PI, the protocols' governing organisation; the certificate is issued by that laboratory, not by us ## Automotive Electronics URL: https://aeicor.com/industries/automotive-electronics/ Embedded and communication engineering inside automotive electronics, for tier-1 and tier-2 development groups re-platforming onto zonal architectures. Bus and network integration, diagnostics, and the process evidence their OEM customer will audit. ## How does an embedded engineering engagement with a tier supplier work?We build the embedded and communication layers inside automotive electronics.
This is for tier-1 and tier-2 development groups. You keep the component and the OEM relationship; we take the parts that need a standing specialism: - CAN and CAN FD, LIN, FlexRay and single-pair Automotive Ethernet integrated at node level onto your device and its silicon - AUTOSAR Classic and Adaptive platform work, including the communication and diagnostic stacks - purpose-built ECU nodes and in-vehicle gateways, developed from silicon bring-up and stack port upward - UDS diagnostic services, over CAN or over DoIP where the backbone has moved to IP - validation capacity and the CI pipeline that runs the bus, diagnostic and timing checks on every build - the process evidence that has to be produced alongside the software instead of assembled afterwards Most of that is component development to your own specification, delivered as your engineering partner. The [engagement page](/engagement/) sets out the modes and how they are priced. ## Why has the re-platforming changed what gets outsourced?The hard part moved, from the wiring decision to the software architecture.
Any one of the component's layers: the bus, the middleware, the diagnostic stack, the capacity to validate them.
- **An unfamiliar bus.** Your team has not shipped it before. CAN FD on a part that used to run classic CAN, or a first single-pair Ethernet node, taken from silicon bring-up to a device that behaves under real bus load. It also runs the other way: a FlexRay node on a platform still in production, where the specialism is getting harder to staff. - **A third-party network.** A component that has to participate correctly on an architecture you do not control, including the gateway cases where it bridges two of them. - **A zonal backbone.** The middleware layer an Adaptive platform runs on, and the scheduled network underneath it, taken from standards documents to something that holds under real traffic. - **A diagnostic stack moving transport.** UDS that worked over CAN and now has to answer over DoIP, with the addressing, discovery and session handling that change with it. - **AUTOSAR integration capacity.** Configuration and integration work on Classic or Adaptive, alongside your own platform team. - **Validation and CI capacity.** Engineers into your validation team, or the pipeline that runs the regression and timing checks per build. - **Your own engineers.** Brought up to speed. Training on the bus, platform or diagnostic stack, then building the first implementation alongside your team. We hold third-line support afterwards while your team runs first line. - **A whole component.** A whole component built to your specification, with the OEM relationship staying yours. ## What does node-level bus integration involve?It gets a protocol running correctly on a particular device and its silicon.
That is a narrower and more exacting job than it sounds. The stack has to fit the part, the timing has to hold under real bus load, the diagnostics have to answer the way the tester expects, and the whole thing has to behave on a busy network as well as on the bench. It is the same discipline we apply on the industrial side, where our team has taken communication stacks through conformance testing on several silicon families. A CAN or LIN node in a vehicle and a fieldbus node on a machine are different networks with the same underlying question: does this device behave correctly as a participant, under load, on someone else's network.A middleware layer carries it, over a network that agrees to be predictable.
The middleware decides which service talks to which. Both halves are now public standards, no longer per-programme design decisions. AUTOSAR Adaptive specifies a DDS binding for the middleware half. IEEE 802.1 time-sensitive networking covers the other half at the link layer, and the OMG published DDS-TSN 1.0 in April 2023, revised as Beta2 in May 2024, setting out how one maps onto the other.UDS is unchanged in what it does, but increasingly it no longer travels over CAN.
As the vehicle backbone moves to IP, the same diagnostic services are carried over DoIP, and the transport change is more consequential than it first appears. Addressing, discovery, session handling and security all behave differently. Work that assumes CAN transport tends to need rethinking, not porting. ## How do you produce the process evidence an OEM audit expects?Alongside the software, because on a tier-1 platform the evidence gates the work.
Three assessments read the same trail: - **Automotive SPICE**, which suppliers are assessed against. - **ISO 26262**, which brings functional safety with its own artefact expectations. - **ISO/SAE 21434**, which has added cybersecurity engineering to the same list. None of that is unusual or unreasonable. It is how the sector manages risk across a supply chain it cannot inspect directly. In practice that means the traceability from requirement to test result is built as the work proceeds, on your process and in your toolchain, so what reaches an assessment is your evidence trail with our work inside it.Yes, and that is deliberate.
Vehicle electronics and industrial automation have converged on the same problems: deterministic Ethernet, time synchronisation, service-oriented communication, functional safety and cybersecurity obligations arriving together. The bus names differ. The engineering underneath is portable, which is why our [embedded systems](/services/embedded-systems/) and [real-time Ethernet](/services/real-time-ethernet/) work spans both. ### Frequently asked questions **Do you work directly with vehicle OEMs?** Usually not. Most of our automotive electronics work is for tier-1 and tier-2 engineering groups, building components to their specification as their partner. The OEM relationship stays with them. **Which buses do you integrate at node level?** CAN and CAN FD, LIN, FlexRay, and single-pair Automotive Ethernet. The work is protocol integration onto a specific device and silicon as a node on the network, which is the same discipline we apply to industrial fieldbus and real-time Ethernet. **What is different about zonal architectures in practice?** Compute consolidates, and functions that had their own ECU become services reached over a network. The communication and middleware layer moves from being plumbing to being the thing the programme is organised around. **Have you shipped a DDS system in a vehicle programme?** No. Our delivered data-distribution work is outside automotive, and the vehicle side of it is architecture and standards work — mapping topics and their quality-of-service settings onto a TSN schedule, and integrating the DDS binding AUTOSAR Adaptive specifies. Anyone claiming a fleet of DDS-coordinated production vehicles should be asked the same question. **Is this the same as your automotive plant page?** No. This page is about electronics inside the vehicle. Networking, end-of-line test and traceability on the factory floor are covered under automotive plants. ### References - ISO 11898 — CAN and CAN FD - ISO 17458 — FlexRay, still carried on chassis and safety domains of platforms already in production - ISO 14229 (UDS) — unified diagnostic services - ISO 13400 (DoIP) — diagnostics carried over IP - IEEE 802.3bw / 802.3bp — 100BASE-T1 and 1000BASE-T1 single-pair Automotive Ethernet - IEEE 802.3cg — 10BASE-T1S, the short-reach single-pair link used at the zonal edge - IEEE 802.1Q — time-sensitive networking, including the 802.1Qbv scheduled traffic that gives a message its own window on a shared backbone - OMG DDS-TSN 1.0 — how a DDS deployment maps onto TSN scheduling, published April 2023, Beta2 May 2024 - ISO 26262 — functional safety for road vehicles, defining ASIL levels - ISO/SAE 21434 — automotive cybersecurity engineering - Automotive SPICE — the process assessment model OEMs audit suppliers against ## Food Processing URL: https://aeicor.com/industries/food-processing/ The protocol, instrument and data layer beneath food and beverage lines, built for MES vendors, machine builders and integrators, from intake instruments and inspection systems through to MES and ERP. ## How does a food processing line engineering engagement work?We build the layer beneath a food or beverage line, from instrument access up to the traceability stream.
It reaches from the instruments on the line up into MES and ERP: the protocol access interfaces, the recipe and batch data model above them, and the lot genealogy behind both. This is for MES vendors, machine builders and integrators delivering into a plant. You keep the product and the plant relationship; we take the parts that need a standing specialism: - access interfaces to intake and in-process instruments over POWERLINK, PROFINET, CANopen, Modbus RTU and TCP and serial links - OPC UA from the automation application and PLC, and the gateway that merges several machines into one subscribable view - purpose-built nodes and gateways where no off-the-shelf part fits - recipe and changeover logic moved out of PLC code into an ISA-88 batch model - lot and batch capture at the station, with the genealogy model behind it - inline inspection that feeds state back to actuators in real time - training your engineers on the technology, building the first implementation with them, then third-line support behind their first line The [engagement page](/engagement/) sets out the modes and how they are priced. ## Why does the layer below an MES need separate engineering?The two jobs are different: an MES owns the data model, the layer below it owns instrument access.
An MES vendor's product is the data model and what the plant does with it, and it is the question we are asked most on a food line. Ours is everything below that: getting at the instruments and controllers in the first place, over whatever they actually speak, and presenting a merged, trustworthy stream upward. The machine builder owns the machine and its mechanical hygienic design; the integrator owns the plant-side delivery and commissioning.Any one of the layers below the MES: instrument access, a merged view, recipe logic, traceability, inline inspection.
- **An unreadable instrument.** A weighing, feed, temperature, moisture or inspection device on a protocol the rest of the system does not speak, that has to appear upward as ordinary data. - **A merged view across machines.** A gateway that lets a remote system request, subscribe to and receive live data from a group of machines without polling each one. - **A device to build.** A purpose-built node or gateway built from the stack port and board bring-up upward. - **Recipe logic outgrowing its PLC.** Hard-coded changeover and segregation logic migrated into an ISA-88 batch model, one product family at a time. - **Traceability for a recall.** Lot capture at the station plus the genealogy model that resolves an ingredient lot forward to every pallet. - **Inline inspection at the station.** Camera or sensor systems feeding state back to actuators fast enough to reject or correct the unit in place. - **Team bring-up.** Your own engineers brought up to speed. Training, then building the first implementation alongside your team, with third-line support behind them afterwards. ## What does the instrument and protocol layer cover?It covers whatever the line already speaks, which on a real floor is four or five protocols at once.
Intake weighing and feed instruments, in-process temperature and moisture measurement, and inspection systems arrive on POWERLINK, PROFINET, CANopen, Modbus RTU or TCP, or a plain serial link, and the automation application and its PLC sit above them on OPC UA.It lets the line act at the station instead of at the end of it.
Camera or sensor systems at the station feed state back to the actuators while the unit is still in place. As an example, on a moulded frozen confectionery line we built a line-scan camera system for an MES provider that monitors output state and feeds back in real time to actuators and quality systems: correctly formed, half filled, empty, stick missing. Inspection of that kind belongs where the unit is made, because the value is in rejecting or correcting it before more work goes into it. ## Who specifies what has to survive the washdown?We do, where it concerns the layer we design.
That means selecting the ingress rating for enclosures and connectors to IEC 60529, and to IP69K per ISO 20653 in the wet zone, and cabling rated for the wash chemistry and the thermal cycling, in place of standard industrial parts, then designing the electrical and network layer to meet it. We work to 3-A Sanitary Standards and EHEDG guidance where the equipment sits in that zone. Two boundaries sit around that: - **Hygienic mechanical design** covers material finish, drainage angles and crevice-free construction. That is the machine builder's discipline and it stays with them. - **Installation and on-site commissioning** are the integrator's. We supply the specification, the design and the compliance case, and their team puts it in. Our own contribution is the electrical, network and embedded layer that has to survive the same environment and the same wash cycle.In stages, one product family at a time.
Most lines already run some recipe logic hard-coded into PLC programs after years of successive changes. We move that logic into an ISA-88 batch and recipe model incrementally, validating each family against the running line before cutover, so a controller replacement is never a precondition for getting to data-driven recipes. ## What data model sits behind ingredient-to-pallet traceability?A parent-child lot genealogy, structured so it can trace forward and not only log backward.
We engineer the controls, drive-synchronisation and network layer inside printing machinery.
This is for the machine builders, converters and retrofitters whose presses they are. You keep the machine, the brand and the end customer; we take the parts that need a standing specialism: - coordinated motion and drive synchronisation on PROFINET IRT, POWERLINK or EtherCAT - sensor-path handling, so a reading is qualified before it is allowed to move an axis - purpose-built multi-function IO devices, drive interfaces and gateways that replace several off-the-shelf modules at once - migration off an ageing fieldbus onto real-time Ethernet, carrying your processing logic across without rewriting it - a second network on an existing control product, so one product line serves plants that expect different interfaces - obsolescence work and controls retrofit on installed machinery, staged so the press is proven at speed before the old controls come out - training your engineers on the technology, building the first implementation with them, then third-line support behind their first line Our team has extensive experience with domain-specific machine vendors in this sector, on new builds and on retrofits. The [engagement page](/engagement/) sets out the modes and how they are priced. ## Why is the controls specialism bought in rather than staffed?The work arrives in bursts, and the people who do it are hard to keep busy between them.
Coordinated motion on a press is a networking and embedded problem before it is a mechanical one: everything upstream (tension, speed, ink, substrate) arrives at the same two questions, whether the command reaches the drive in time and whether the reading it came from was real. The engineers who answer those well are hard to keep busy inside one machine programme. The same arithmetic covers the rest of this page. Adding POWERLINK alongside PROFINET is weeks of specialist work and then nothing for a year. So is a controller family going end-of-life, or a first custom IO device, or a migration off a fieldbus that has served the machine for fifteen years. Each is a project with a beginning and an end, on a machine that is otherwise yours. ## Which slices of the work can you support?Any one of the parts that decide accuracy at speed: the motion network, the sensor path, the controls generation.
- **Coordinated motion on a new machine.** The network engineered so the synchronised axes share one isochronous clock phase and setpoints land in a known slot every cycle. Register control, shaftless drive coordination and cross-cutting are all this problem wearing different clothes. - **A lying sensor path.** Mark, edge or length-error qualification, so a wrong reading is classified as a fault instead of being chased into a correction that wastes web. - **A cabinet of hardwired IO.** Several off-the-shelf modules replaced by one purpose-built multi-function device, cutting the wiring loom back to a network drop. - **A fieldbus that has to be migrated.** Migration onto real-time Ethernet, with your processing logic and IP carried across to new sensors, controllers and protocols. - **An end-of-life part.** A chip, controller or electronics notice on a press that is still selling, assessed before anything is redesigned. - **A second network on an existing product.** The same control product taught to speak PROFINET and POWERLINK, or EtherCAT, so it can be sold into plants that expect different things. - **A controls retrofit on installed machinery.** A new drive network and control hardware under an unchanged mechanical machine, commissioned in stages. - **Team bring-up.** Your own engineers brought up to speed. Training, then building the first implementation alongside your team, with third-line support behind them afterwards. ## How do you design for accuracy at web speed?We hold the measurement-to-setpoint path inside a jitter budget the correction interval can absorb.
That path decides it, not the drive's own loop. If its jitter is comparable to the correction interval, the machine corrects against stale positions and hunts. We engineer the network so the coordinated axes share one isochronous clock phase and the correction lands in a known slot every cycle, which is why the synchronisation figure matters more than raw cycle time. On delivered work that means clock synchronisation below 1 µs across the axes, 3 µs worst case, with the correction path inside a jitter budget under 5 µs. Register control is the best-known case, and the same budget governs shaftless drive coordination, cut-to-mark and cross-cutting on a converting line, and any splice or turret sequence tied to machine state.We handle it at the sensor edge, before a reading is allowed to move an axis.
A ghost mark, a missed mark, a stretched repeat length or a mis-tracked edge all present as a sudden deviation. Readings are qualified against the expected geometry and window before they are allowed to move an axis, so a wrong one is classified as a fault and reported. ## How do you build one machine for plants that expect different networks?One control product carries both stacks, and the choice follows what the builder needs to own.
Where one company supplies both the drive and the controller, an open-source stack lets them own that product line end to end without a dependency they did not choose. Where the drive comes from a third party and the plant's installed base is PROFINET, the certified commercial path is the right one. As an example, the same OEM control our team worked on supports PROFINET and POWERLINK, and on the POWERLINK builds the drives and the measurement systems were both on that network. We also work with third-party stacks a builder has already licensed. The decision is theirs; our part is making the chosen one hold its timing on their hardware.We scope how much of the control system has to move with the obsolete part.
The mechanical machine usually has years left. Sometimes it is a drop-in replacement and a driver change; sometimes the replacement has a different peripheral set and the firmware has to be reworked around it. We assess first, so the decision is scoped engineering. The [obsolescence management](/services/obsolescence-management/) page covers how that work runs.Replacing the control and network layer without disturbing the machine around it.
New drive network and control hardware, the machine's own logic re-implemented against them, and commissioning staged so the press is proven at speed before the old controls are removed. The acceptance criterion is the same as on a new build: the machine holds its accuracy at production speed, measured the way it was measured before. ## What other press and converting problems can you help solve?We cover the rest of the press too, and stay with a builder's programme across several of these.
A builder already has their own answer to most of the list below, and where we come in is usually one of them, on their terms. - **Tension control** across unwind, process and rewind, where the same synchronisation quality decides whether a thin substrate survives a speed change. - **Shaftless drive coordination**, replacing a mechanical line shaft with an electronic one, which is where most retrofits actually start. - **Splice and turret sequencing** on running webs, a timing problem tied to machine state rather than to a control loop. - **Cut-to-mark and cross-cutting** on converting lines, the same sensor-to-actuator path as register with a knife at the end of it. - **Web guiding and edge tracking**, the same qualification discipline applied to a different sensor. - **Inspection and defect logging** on the running web, where the reporting path must stay clear of the isochronous one. - **Line data upward** to supervisory and MES layers over OPC UA, again without any of it touching the isochronous path underneath. ## What has to be true of the network before coordinated motion works?Three things have to be true: a common clock, a matching topology, and a device description treated as an interface.
All three are settled at commissioning, and not typically by product selection. 1. **A common clock.** Every device in the control loop has to sit inside its domain. A device that is merely on the same wire but outside the domain will appear to work and will drift. Each protocol gets there differently: EtherCAT distributes a reference time from one clock and each slave corrects itself against it, PROFINET IRT runs a sync domain with a sync master and a scheduled transmission phase, and POWERLINK gives every node its slot in a cycle the managing node polls. Same requirement, three mechanisms, and the commissioning check is the same in all three: is every device that matters actually inside the domain. 2. **A physical topology matching the engineered one.** Isochronous schedules are computed against a specific wiring layout, so the machine has to be cabled the way the engineering says, and the network has to be able to prove it was. 3. **The device description.** It is an interface, not a detail. Every protocol has its own form of this file (GSDML on PROFINET, ESI on EtherCAT, XDD on POWERLINK) and it defines how a device's data is laid out to everything else on the network. Changing that layout is a compatibility event, not a firmware detail: it is how a routine drive replacement turns into a re-commissioning job. Each protocol implements those three differently, and the mechanisms are covered on the [real-time Ethernet](/services/real-time-ethernet/) page.We build the OPC UA and PackML state and data layer inside packaging machinery.
This is for the OEMs and line integrators. You keep the machine, the brand and the end customer; we take the parts that need a standing specialism: - PackML state and mode models over OPC UA, implemented consistently across the machines of a line - machine-to-MES interfaces, including companion-spec information models - the gateway and sensor I/O layer beneath both, aggregating dense low-level streams onto a fixed cycle - purpose-built nodes and gateways, developed from board bring-up and stack port upward - migration off CANopen or an older fieldbus onto real-time Ethernet, carrying the machine's behaviour across - training your engineers on PackML, OPC UA or the network stack, building the first implementation with them, then third-line support behind their first line We do not install or commission lines on a plant floor. Where the work has to be integrated and tested, our team works with your engineers, onshore during integration and test and remotely for the rest. The [engagement page](/engagement/) sets out the modes and how they are priced.Inconsistency compounds across a line whose machines have no shared state model.
Three builders' machines and three ideas of what "running" means, where a plant typically prefers one OEE number. Every report above the line then has to reconstruct what happened instead of just consuming the logs, and reconstructions go wrong in critical cases, when two machines change state within the same second. A shared state model solves this without increasingly complex reporting mechanisms, and it is targeted engineering that a machine programme needs once in a few years. The same is true of the layer underneath it: a gateway which has to 2 ms cycle across several thousand points, or a network migration off a fieldbus the machine has run on for a decade. ## Which slices of the work can you support?Any one of the machine's layers: the state model, the MES interface, the IO gateway, the network.
- **A machine using PackML.** The state and mode model implemented over the existing control logic, without rewriting the sequence. - **Several builders, one line.** The same model applied across machines that were never specified together, so the line reports as one. - **A machine-to-MES interface.** OPC UA and companion-spec information modelling, on the machine side or the integration side. - **Sensor I/O outgrowing the controller.** Dense low-level streams aggregated at a gateway and published on a fixed cycle. - **A device to build.** It does not exist yet. A purpose-built node or gateway, built from board bring-up upward. - **A fieldbus that has to be migrated.** CANopen or an older fieldbus onto real-time Ethernet, with the machine's behaviour carried across. - **Team bring-up.** Your own engineers brought up to speed. Training, then building the first implementation alongside your team. ## What does a shared state model change on the line?A stoppage has an owner the moment it happens.
When every machine exposes the same states and modes (drawn in the figure under [the engagement section](#how-does-opc-ua-and-packml-engagement-for-packaging-machinery-work)), the line reports which machine changed state first and why, instead of an operator reconstructing it afterwards. That also makes line-level logic simpler, because starve and block conditions become readable machine states instead of heuristics built on sensor timing. ## How is dense per-machine sensor I/O gathered without losing determinism?We aggregate the sensor streams at the gateway and publish them on a fixed cycle.
The number of sensor streams, not the control loop, is now what sets the load. Many low-level serial and I2C sensor streams are collected on the device, timestamped locally and published upward on a fixed cycle, so the controller sees one bounded, predictable input per cycle. That structure is what let a delivered machine hold a 2 ms cycle across several thousand points without the aggregation becoming the bottleneck.A custom node is purpose-built, and usually one of two types: a device node or a gateway.
As an example, our team built both for one packaging machine builder, often deployed on the same floor but doing different jobs: - **A real-time Ethernet node** bridging down to UART and I2C for sensor and actuator control on a 2 ms cycle, delivered as a migration from CANopen. The machine kept its behaviour and changed its network. - **A gateway that is a slave on one network and master of a sub-hierarchy beneath it**, used for conveyor and motion control. That one is covered on the [material handling](/industries/material-handling/) page, since conveyor control is its main use. Both are OEM product work. The builder's machines and their customers are theirs; we build the node. ## How do you stop a format changeover becoming an engineering job?Changeover cost is decided at design time, long before the format changes.
It is set by how the machine's format parameters and state handling were structured in the first place. We keep format-dependent values as parameters against a fixed state model, so a new SKU is a data change and a validation pass rather than new sequence logic. Because the states are standard, the MES can then drive and record the changeover instead of watching it happen.A fixed vocabulary, and the legal moves between its terms.
The states include Idle, Starting, Execute, Holding, Suspending, Stopping, Aborting, Completing, Resetting and Clearing, and the value is that they mean the same thing on every machine that implements them. "Holding" on the filler and "Holding" on the case packer describe the same condition, so a line controller and an MES can reason about both without a translation table per supplier. The transitions are as important as the names. Because the legal moves are defined, a line can be interlocked on states instead of ad-hoc signals, and a machine added later into the line inherits the same contract without needing its own sequence logic. ### Frequently asked questions **Who implements PackML on a packaging machine, the builder or a supplier?** The builder owns the machine and its sequence; we build the state and data layer inside it. Our customers here are packaging machinery OEMs and the integrators assembling lines from several builders' machines. The builder owns the machine, the brand and the end customer. We do not install or commission lines on a plant floor, though our team works with your engineers onshore during integration and test. **Why standardise on PackML if our machines already report status?** Because "already reporting" differs per builder. PackML gives every machine the same states and modes, so line-level OEE and stoppage attribution are read directly rather than inferred from three vendors' conventions. **Can PackML be added to machines that were not built with it?** Usually yes. The state model can be implemented in a layer above the existing control logic, mapping what the machine already knows into the standard states without rewriting its sequence. **How much sensor and actuator I/O can this layer carry?** Our team has delivered gateway work managing up to several thousand actuators and sensors on a machine at millisecond cycles, over real-time Ethernet with serial and I2C beneath it. The constraint is the aggregate bus and cycle budget, more than any individual sensor. **What happens to our machine behaviour if we move off CANopen?** It comes across. Our team has delivered exactly that migration onto POWERLINK, where the machine kept its behaviour and changed its network. EtherCAT is the other common target, and often the easier one from CANopen, because CoE carries the CiA profiles a machine is already built around, including CiA 401 for IO and CiA 402 for drives. Either way the sequence logic is the builder's IP and a migration is a port of it, not an opportunity to rewrite the machine. ### References - ISA-88 / PackML — packaging machine state and mode models - OPC UA (IEC 62541) — machine-to-MES interfaces and companion specifications - IEC 61158 / IEC 61784 — industrial fieldbus and industrial Ethernet - ISA-95 / IEC 62264 — enterprise-control (MES) integration ## Textile URL: https://aeicor.com/industries/textile/ Deterministic motion, spindle-level monitoring and embedded control designed into textile machinery, for the OEMs, integrators and MES providers who build and ship it: EtherCAT drive synchronization, the per-spindle detection layer, and the data path their machine presents to a mill. ## How does a textile machinery engineering engagement work?We engineer the motion, monitoring and embedded control layer inside textile machinery.
This is for the machine builders, integrators and MES providers whose product it is. That means EtherCAT (IEC 61158 Type 12) synchronization across hundreds to thousands of spindle and drive axes, per-spindle fault detection, and the data path the machine presents upward. You keep the machine, the brand and the mill; we take the parts that need a standing specialism: - deterministic motion networks sized for the axis count the frame actually runs - the per-spindle acquisition and detection layer, designed into your machine - purpose-built multi-function IO devices, drive interfaces and gateways - retrofit kits that bring an installed machine onto the plant network, packaged for your service organisation to fit - obsolescence work when a controller or component generation ends before the frame does - training your engineers on the technology, building the first implementation with them, then third-line support behind their first line We do not install or commission machines in a mill. Where a design has to be integrated and tested, our team works with your engineering team: onshore during integration and test, remotely for the rest. The [engagement page](/engagement/) sets out the modes and how they are priced.Mills now buy on quality and uptime, and both are decided at the spindle.
A frame runs continuously with hundreds to thousands of positions. A break or a developing bearing fault costs output until someone finds it. A machine that names the position, and not just the frame, shortens that search. Per-spindle detection has moved from an option to an expectation because of it. The engineering behind it is networking and embedded work, not mechanical work, and it arrives in bursts: a monitoring generation added, a frame moved off an ageing fieldbus, or a controller taken through an end-of-life notice. Each is a project with a beginning and an end, on a machine that is otherwise yours. ## Which slices of the work can you support?Any one of the layers inside the frame: the motion network, the monitoring layer, the IO, the controller generation.
- **A motion network that must scale.** The segment engineered so the synchronised axes share one clock phase and setpoints land in a known slot, and so adding axes does not step down the control rate for the ones already running. - **A monitoring layer.** For a machine that does not have it yet. Per-spindle sensing and embedded detection designed into the frame, with the fault classes and the reporting path defined against your machine. - **A retrofit kit.** For the installed base. Edge sensing, a gateway and a calibration pass, packaged so it can be fitted inside a maintenance stop. - **A fieldbus that has to be upgraded.** Migration onto real-time Ethernet, with your processing logic and IP carried across to new sensors, controllers and protocols. - **A cabinet of hardwired IO.** Several off-the-shelf modules replaced by one purpose-built multi-function device, cutting the loom back to a network drop. - **An end-of-life part.** A chip, controller or electronics notice on a frame that is still selling, assessed before anything is redesigned. - **Team bring-up.** Your engineering team brought up to speed. Training, then building the first implementation alongside your team, with third-line support behind them. ## Which protocols and bus systems turn up on a textile machine?A textile machine carries more than the motion bus, and rarely all from one generation.
EtherCAT and Sercos III appear where a builder has specified a coordinated motion package, and Sercos in particular tends to arrive as part of a drive vendor's own offering. Modbus RTU and Modbus TCP are widespread on spindle-level monitoring and basic control, especially on cost-effective machinery from builders outside Europe and North America, and they are not going anywhere. IO-Link covers the sensor layer beneath either. The controller itself is usually programmed in the IEC 61131-3 languages regardless. Most of the work is at the joins: getting a monitoring layer that speaks Modbus and a motion layer that speaks EtherCAT to produce one coherent picture of the machine, and then presenting that upward over OPC UA without disturbing either.We integrate four signal sources, grouped by what each detects: process faults, machine state and equipment health.
They differ in cost per spindle and in the fault classes they detect reliably. The machine integration decision is yours; our part is the acquisition path and the detection logic around the signals available. - **Traveller speed: process faults.** A Hall-effect or proximity sensor measures each traveller's movement directly. Loss of movement indicates a yarn break, reduced speed indicates slack, and an abnormal speed excursion indicates a tension or traveller anomaly. Comparing positions across a frame of near-identical spindles detects more than any single-position threshold, which makes this the most direct per-spindle channel. - **Drive and controller feedback: machine state.** Drive status, actual-speed feedback and fault codes show whether a spindle or frame is running, stopped or starting, and separate a genuine stop from a yarn fault. How fine-grained that is depends on how the drives are organised. - **Motor-current signature: equipment health.** The drive is already there, so current is the cheapest channel. It shows motor and drive-train health, start and stop transients and frame-level load anomalies. Whether it can single out one spindle's yarn fault depends on the drive architecture. - **Vibration and acoustic: equipment health.** Vibration trends bearing degradation, imbalance, misalignment and looseness, evaluated against ISO 20816 where it applies. Acoustic sensing adds evidence of friction and impacts.We make the fitting sequence part of the design, so it does not become a commissioning problem.
Wiring and edge hardware are specified to go in first; the per-spindle baselines then calibrate against the running machine in a short pass afterwards. That keeps the work inside the maintenance stop the mill already schedules, instead of creating a separate downtime event, which is usually what a builder has to promise before a mill will agree to a retrofit at all. Whoever fits it, your service engineers or the integrator, is following a defined sequence, and our team works behind them on the design and the test. ## What do you cover on the drive side?We cover the device layer that feeds motion and the control layer that runs it.
- **Encoder integration**, which is where a lot of textile motion actually gets its feedback. Our team has integrated optical rotary encoders as small-footprint slaves on real-time Ethernet and fieldbus for an encoder manufacturer whose parts ship into textile machinery alongside packaging, elevators and inkjet printing. That is device-level protocol work rather than a mill installation, and it is the same job whichever machine the encoder ends up in. - **Drive control above it.** Our team has designed and integrated motor drive control systems onto specific platforms over real-time Ethernet: the control implementation on the builder's chosen hardware, on the network the machine runs. - **On Sercos III the boundary is narrower.** Slave-side integration is largely kept in-house by the drive vendors, so where we add value is at the edges, in gateways and in making a motion system interoperable with OPC UA instead of in the drive stack itself. ## How does textile spindle monitoring on EtherCAT scale with spindle count?Spindle monitoring scales by segmentation: every spindle added to a segment spends part of the same cycle budget.
Axis count is usually the binding constraint, not any single drive loop. The design question a frame poses is how many segments the monitoring and motion traffic needs, and where the split between them falls. What sets the target is the spindle itself: a ring frame runs up to roughly 20,000–25,000 rpm, so one revolution takes 2.4 to 3 ms, and a cycle under a millisecond gives several samples per revolution, enough to see a break or a developing fault while it happens.We engineer the controls and networking layer of material-handling systems.
This is for the system integrators and equipment builders whose floor it is, and the work is conveyor control integration, AS/RS and AGV control design, and the industrial Ethernet and safety networking underneath them. The layer is a specific one: - The network design. - The control structure. - The device and gateway layer. - The safety communication that rides with it. Installation, site commissioning and the end customer stay with the integrator. Where the design has to be integrated and tested, our team works with your engineers, onshore during integration and test and remotely for the rest. Intralogistics is an integration discipline more than a machinery one. The conveyor works, the crane works, the vehicles work; the engineering question is whether they hand a load to each other reliably at throughput, and whether the network can prove they did. That question is answered in the design, which is why it is the part that gets outsourced. ## What sets the network budget in a material-handling system?Node count and topology set it, not the fastest device on the floor.
A sorter diverting at speed needs its decision inside a fixed window, and every zone added to the segment eats into it. We design the segments and the traffic split up front so that extending the system later adds nodes without pushing the existing zones out of their cycle budget, which is the difference between a spur being a week's work and a re-commissioning. A multi-tier conveyor and lift our team built faced exactly this: 18 lanes merging across two levels, held in step on a 2 ms POWERLINK cycle.The handover point is the harder part of an AGV deployment; navigation rarely is.
A vehicle and a fixed conveyor have to agree on state there. We design the interface at the fleet-manager level and model the handover explicitly (requested, granted, occupied, cleared) so the transfer is interlocked instead of being driven by a timer, which is what stops a load being placed onto a station that has not finished releasing the last one. Our work is the interface and the logic above it. Fleet-management software itself is a different business, and the vendors who build it are the people we work alongside. What varies between projects is the interface; the handover model stays the same. Our team has built the vehicle side as well, including the control system for a line-following AGV that reads its route from markers in the floor.On the same wire, in most modern builds.
A safety protocol carries its own integrity checks end to end, so the network beneath it does not have to be trusted and a separate safety network is no longer the default answer. openSAFETY (IEC 61784-3-13) is the clearest example, because it is bus-independent. Our team has ported it onto a customer's own board and taken it through SIL2 pre-certification testing, and later worked on a fire-safety system where it ran across both POWERLINK and PROFINET segments. That was not intralogistics work, but it is the same discipline a conveyor or AS/RS safety layer needs. Two boundaries apply here: - **Pre-certification testing is not certification.** The assessment belongs to an accredited body. - **On driverless vehicles the personnel-safety stop is a certified duty** under ISO 3691-4 in Europe and ANSI/ITSDF B56.5 in North America, which is a separate question from obstacle detection using ultrasonic, lidar or vision sensors.It is starting to change what the fleet layer knows, but not what the safety layer may conclude.
Wireless location tracking over 5G and Wi-Fi is being demonstrated for floor-level material handling. The interlock at the handover point still has to be provable on its own terms. We treat a location feed as useful context for traffic management and not as a substitute for the interlock. ## How do you design for a system that keeps growing?We keep the control structure per zone, identical and parameterised.
Material-handling systems are commissioned in phases and then extended for years. - **What an extension represents.** Adding an aisle or a spur is a configuration and a network-budget check, with no new one-off logic, and the safety validation stays limited to the zone that changed instead of covering the whole floor. - **When it is accounted for.** At the design step, while the first phase is still on paper, and not after the extension is needed during operation. The same reasoning drove an EtherCAT motion platform our team built to be configured into several machine geometries instead of rebuilding per machine. ### Frequently asked questions **Do you install and commission material-handling systems on site?** No. We engineer the control, network and safety layer and prove it with your team; the floor installation, the site commissioning and the end customer stay with the integrator or builder. Where a design has to be integrated and tested we work alongside your engineers, onshore during integration and test and remotely for the rest. **Can equipment from different builders run under one control scheme?** Yes. The usual approach is protocol bridging at the controller instead of standardising the floor, so each supplier's equipment keeps its native interface while the sequence above it is coherent. **Does safety need its own separate network?** No. Safety telegrams ride the standard industrial Ethernet as a black channel, because the safety layer proves integrity end to end, so one physical network carries both control and safety traffic. **Do you certify the safety functions you engineer?** No. Certification is an accredited body's judgement, never a supplier's. What we do is design the safety communication layer and take it through pre-certification testing, so what reaches the assessment has already been exercised before the assessment sees it. **How do AGV fleets fit into a fixed conveyor system?** Through the fleet manager, not vehicle by vehicle, which makes it another participant in the plant data layer, so handover points between fixed equipment and vehicles are sequenced, not just timed. **What if the fleet manager does not support VDA 5050?** Then the handover is built against that vendor's own interface, usually a REST or MQTT API, and the state model above it stays the same. VDA 5050 shortens the specification work; it is not a precondition, and a proprietary fleet interface is still a bounded piece of engineering once the handover states are agreed. ### References - IEC 61158 / IEC 61784 — industrial fieldbus and industrial Ethernet standards - IEC 61508 / ISO 13849 — functional safety for machinery control systems - IEC 61784-3-13 (openSAFETY) — bus-independent safety communication profile - ISO 3691-4 and ANSI/ITSDF B56.5 — driverless industrial truck safety - VDA 5050 — the AGV/AMR fleet-interface specification, carried over MQTT - OPC UA (IEC 62541) — equipment data to WCS/WMS layers - ISA-95 / IEC 62264 — enterprise-control system integration ## Automotive URL: https://aeicor.com/industries/automotive/ The plant-floor network, test-system and embedded layer beneath an automotive production line: deterministic networking, end-of-line testers and traceability paths, engineered for the MES vendors, line integrators and manufacturing engineering groups who deliver into vehicle plants. ## How does an automotive plant-floor network integration engagement work?We engineer the deterministic networks, test systems and protocol bridges under an automotive production line.
This is for vehicle OEMs, their tier suppliers, and the MES vendors and line integrators delivering into those plants. You keep the line, the plant relationship and the production schedule; we take the parts that need a standing specialism: - deterministic segments for robot cells, conveyors and vision stations over PROFINET (IEC 61158) and IEEE 802.1 TSN, engineered to a cycle-time budget - gateways and protocol bridges between new cells and an installed base of PLCs, drives and legacy fieldbus - end-of-line and in-process testers, covering firmware, fixture control and the results pipeline into MES - the station-level capture path that carries per-part genealogy upward over OPC UA - safety communication on the control network, taken through pre-certification testing - training your engineers on the technology, building the first implementation with them, then third-line support behind their first line We do not commission lines on the plant floor. That belongs to the integrator or the plant's own engineering group. Where the work has to be integrated and tested, our team works with your engineers, onshore during integration and test and remotely for the rest. The [engagement page](/engagement/) sets out the modes and how they are priced.Often a platform vendor instead of the plant itself.
An MES supplier winning a line needs the layer beneath their product built and proven: PLCs, I/O devices and gateways spanning legacy and current networks, with the floor data streams merged and presented in a form their platform can consume. That is the part we build. Digesting the data is their product, and the customer relationship stays with them. The same applies to line integrators and to tier suppliers' manufacturing engineering groups. We are the engineering bench behind the delivery, not a competing bidder for it. That also decides how the work is staffed: our engineers sit with yours during integration and test, and the people on the plant floor are still your people. ## How do new lines exchange data with installed plant equipment?Most plants run several protocol generations side by side, and that usually needs a bridge, not a migration.
PROFINET on European floors, EtherNet/IP on North American ones, EtherCAT where a cell needs tight coordinated motion, and legacy fieldbus on installed machinery that is not moving. Instead of a forklift upgrade of the floor, we design protocol gateways and bridges that let new deterministic lines exchange data with existing PLCs and drives, and engineer the TSN and industrial-Ethernet segments to hold their cycle-time budget as cells are added. What we hand over is a device and a design; putting it on the floor is the integrator's step.We engineer the tester firmware, fixture control and results pipeline so coverage grows without stretching cycle time.
EOL testers turn into the bottleneck when every vehicle is a variant. Three things keep the cycle time flat: - Parameterised test sequences per variant. - Deterministic fixture I/O. - Pass/fail and measurement data streamed straight into MES. ## How is per-part traceability captured without slowing the line?We instrument stations to publish part-level data over OPC UA (IEC 62541) into an ISA-95 MES layer.
The genealogy in question is per-part build genealogy: which components, which process settings and which test results went into each individual part, and into the vehicle it ended up in. It is what a targeted recall runs on, which is why the traceability expectations in the automotive quality standards reach every station from press shop to dispatch, well beyond final assembly. Each part therefore carries a complete build record, captured in the background of the normal station cycle, not as an added test step.We separate them in the network design.
A station publishing per-part genealogy sits on the same infrastructure as the cell's motion traffic, and the two have nothing in common except the wire. The design question is whether the traceability path can be added, extended and occasionally broken without any of that reaching the cell. - **How it is done.** The segmentation has to be settled before the data question, and IEC 62443 is the standard that defines how: zones with a declared conduit between them, in place of a flat floor where an MES query and a drive setpoint traverse the same path. - **Why it pays off.** It is what makes the traceability layer safe to change, and that matters because traceability requirements change far more often than robot cells do. - **What it is not.** This is segmentation of the plant network, a different subject from the zonal E/E architecture inside the vehicle, covered on the [automotive electronics](/industries/automotive-electronics/) page.On the control network, in most modern builds.
A safety protocol carries its own integrity checks end to end, so the network beneath it does not have to be trusted and a second physical network is no longer the default answer. Robot cells make this a design task, rather than inheriting: guarding, interlocks and e-stops are re-arranged whenever a cell is re-tooled, and the safety communication has to stay provable across each change. Our part is the communication layer and the pre-certification testing that exercises it. Our team has ported a bus-independent safety profile onto a customer's own board and taken it through SIL2 pre-certification. The certificate itself is an accredited body's to issue, and the safety case for an installed line stays with whoever owns that installation. ### Frequently asked questions **Do you commission production lines on the plant floor?** No. We engineer the network, device and test layer and prove it with your team; installation and site commissioning belong to the integrator or the plant's own engineering group. Our team works onshore during integration and test and remotely for the rest of a programme. **We need new robot cells to exchange data with an installed PLC base. What can you support us with?** The device and protocol part. We design and build the gateways and bridges between PROFINET, EtherNet/IP, EtherCAT and legacy fieldbus, and engineer the segments so the new line holds its cycle-time budget against installed equipment. Cell installation, floor wiring and the production changeover are the integrator's, and we work behind them while it happens. **We supply the MES. What part of this do you do, and what stays with us?** We build the layer underneath, meaning the PLC, I/O device and gateway integration across legacy and new networks, merging the floor data streams and presenting them to your platform. Digesting that data is your product, and the customer relationship stays with your team. We work as your engineering partner, not as a second integrator in front of your customer. **Do you build the end-of-line testers or only the networking?** Both. We deliver EOL and in-process tester firmware, fixture control and the results pipeline into MES, alongside the line network they run on. **How does per-part traceability reach our MES/ERP?** Station-level capture is published over OPC UA (IEC 62541) to an ISA-95 MES layer, giving genealogy from press shop to dispatch without adding station cycle time. **Do you certify the safety functions on a line?** No. We design the safety communication layer and take it through pre-certification testing so it is exercised before it is assessed; the certificate is issued by an accredited body, and the safety case for the installed line stays with whoever owns that installation. ### References - IEC 61158 / IEC 61784 — industrial communication network standards (PROFINET) - IEEE 802.1 TSN — time-sensitive networking for converged plant networks - IEC/IEEE 60802:2026 — the TSN profile for industrial automation, which fixes the option set a plant network can require of its equipment - IEC 61508 / ISO 13849 — functional safety for machinery control systems - ISO 10218 — safety requirements for industrial robots and robot systems - OPC UA (IEC 62541) — MES / OT data integration - ISA-95 / IEC 62264 — enterprise-control (MES) system integration - IEC 62443 — network segmentation for plant networks that reach plant IT ## Plastics & Injection Molding URL: https://aeicor.com/industries/plastics-injection-molding/ EUROMAP OPC UA integration for plastics and rubber machinery, built for the machine vendors and integrators whose cells they are: machine-to-MES interfaces, robot and auxiliary connectivity, and a route onto OPC UA for cells still exchanging data as files. ## How does a EUROMAP OPC UA injection molding integration engagement work?We engineer the data interfaces of plastics and rubber machinery cells.
This is for the machine vendors, integrators and MES suppliers whose products they are. You keep the machine, the plant relationship and the software your customer bought; we take the interface layer: - EUROMAP 77 machine-to-MES and EUROMAP 79 robot interfaces, built into the machine or consumed during integration - the rest of the cell mapped into one OPC UA address space, so the MES sees one cell instead of multiple devices - a gateway route onto OPC UA for installed machines still exchanging data as files - an aggregating server or gateway where an ERP or group reporting layer has to subscribe to many machines at once - training your engineers on OPC UA and information modelling, building the first implementation with them, then third-line support behind their first line We do not install or commission cells on a moulder's floor. Where the interface has to be integrated and tested, our team works with your engineers, onshore during integration and test and remotely for the rest. The [engagement page](/engagement/) sets out the modes and how they are priced.EUROMAP 63 exchanges files on a shared directory; EUROMAP 77 is a live OPC UA model instead.
The machine writes files, something else reads them, and it works well enough for shift reporting. It was never built for cycle-level monitoring or for reacting to an event while the cycle is still running. EUROMAP 77, at Release 1.01, gives a live OPC UA information model of the machine, which the MES can browse and subscribe to. Cell state arrives as structured, timestamped data rather than a parsed file, per-cycle parameters become visible, and event-driven reaction becomes possible. The practical consequence is that a new integration stops being a one-off parser, which is also why an installed base of 63 machines is better gatewayed than replaced.EUROMAP specifications are OPC UA companion specifications, published jointly with the OPC Foundation.
OPC UA itself (IEC 62541) supplies the address space, the type system and the services; a companion specification supplies the vocabulary for one kind of machine, so that two vendors' injection moulding machines describe themselves the same way and an MES can consume either without a custom mapping. Within the family: - **EUROMAP 83** carries the general type definitions the others build on. - **EUROMAP 77** covers the machine-to-MES interface. - **EUROMAP 79** covers the robot and handling-device relationship. - **The EUROMAP 82 series** covers the peripheral devices around the cell. - **The EUROMAP 84 series** covers extrusion lines. Knowing which specification owns which part of a cell is most of the scoping conversation, because a gap in that map is where a custom interface ends up being written.Any one of the interfaces around the cell: the machine's own, the peripherals, an installed EUROMAP 63 machine.
- **A companion-spec interface.** On your machine. An OPC UA server built into the product, modelled to EUROMAP 77 over the EUROMAP 83 types, so the machine arrives on site already speaking what the MES expects. - **Multi-vendor integration.** The same modelling work from the other side, where the job is making a mixed installed base present one interface upward. - **The cell around the machine.** Robot, dryer, temperature control and material handling brought into one address space. - **An installed EUROMAP 63 machine.** A gateway route onto OPC UA without touching the controller. - **One ERP, many machines.** One aggregating endpoint instead of an integration per machine. - **Team bring-up.** Your own engineers brought up to speed. Training on OPC UA and information modelling, then building the first implementation alongside your team. ## How is the information model built onto the machine?We build it on an open-source stack, against the companion specification.
It is then integrated into the machine so third-party consumers can rely on it. As an example, our team built an OPC UA information model for a plastics and rubber machine on open62541, the open-source OPC UA stack supported by OSADL, and integrated it onto the machine so that the customer's own third-party consumers, an MES among them, could pull data from it reliably. The request came jointly from the machine vendor and the plant running it, which is the usual arrangement when an interface has to satisfy both the builder and whoever the builder's customer has already bought software from. Our team has also produced a EUROMAP 79 robot information model using our own modelling tooling, published for any other user to start from. EUROMAP 79 is still at release-candidate status, which matters before a programme commits to it. ## How does the rest of the cell get onto one interface?The companion specifications reach most of it, and a gateway covers the rest.
A moulding cell is the machine plus a robot, a dryer, temperature control and often material handling, each with its own protocol and its own idea of what a cycle is. - **EUROMAP 79** covers the robot relationship directly. - **The EUROMAP 82 series** covers peripheral devices. - **Everything no companion specification reaches** is mapped into the same OPC UA address space through a gateway. The MES then sees one cell instead of multiple devices it has to correlate. ## How do you keep the data path out of the control loop?Data collection sits beside the control loop and reads state the controller already produces.
The machine's own control loop stays untouched. The collection path publishes on its own schedule and never inserts itself into the cycle-critical path. That separation is what lets monitoring, MES connectivity and later analytics be added to a running cell without a fresh validation of the machine's timing. ## How does an ERP subscribe to machines across several factories?One endpoint serves them all, instead of one integration per machine.
It can be done in two ways: - **An OPC UA aggregating server** acts as a client to the machines' own OPC UA servers and re-exposes their nodes in a single address space, which is the right choice once the machines speak OPC UA natively. - **An aggregating gateway** does the same job but converts first, which is what a mixed estate needs while EUROMAP 63 machines are still in it. In practice a plastics group has both, and the gateway feeds the server's address space. Our team has built central OPC UA gateways of this kind, letting a remote enterprise system subscribe to several machines at once instead of each being wired up separately. Across sites the modelling is the easy half. The harder questions are transport and segmentation: which network the subscription crosses, what is exposed at each site boundary, and how the path is kept separate from anything the cells depend on. That is the same discipline as the control-and-data separation above, applied at the plant boundary instead of the machine.We do the control and connectivity engineering inside agricultural machinery.
This is for the OEMs whose machines they are. You keep the machine, the brand and the dealer network; we take the parts that need a standing specialism: - the machine-end connector that carries a working machine's data to a remote-service platform - control retrofits that move a machine off an obsolete or closed platform onto one the OEM can keep maintaining - telemetry that survives an intermittent link, and the fleet view a builder can turn into a service offering - CAN-based machine and implement interfaces, ISO 11783 ISOBUS and SAE J1939, bridged to the modern control and data layer - purpose-built control nodes and telemetry gateways, developed from board bring-up and stack port upward - training your engineers on the platform, building the first implementation with them, then third-line support behind their first line We do not build machines and we do not sell a telemetry product. Where a design has to be integrated and tested, our team works with your engineers, onshore during integration and test and remotely for the rest. The [engagement page](/engagement/) sets out the modes and how they are priced. ## Why does a controller replacement pull telemetry and compliance with it?Obsolescence, telemetry and compliance share one root: a machine that outlives the electronics inside it.
Builders in this sector rarely have a control problem specific to agriculture. They have a controller that went end of life two supplier generations ago, a machine that disappears the moment it leaves the yard, and a compliance date approaching. The answer to all three is the same, a control platform the OEM can still open in five years, which is why they are cheaper to answer at once than one at a time. That is why a retrofit and a telemetry project usually want to be the same project. The moment the control platform is being touched is the cheapest moment to add the data path and the secure update mechanism the Cyber Resilience Act will ask for, and the most expensive version of both is the one retrofitted onto a fleet that has already shipped. ## Which slices of the work can you support?Any part that is going obsolete or is yet to go live: the controller, the data path, the bus interface.
- **An end-of-life controller.** A machine still selling on a part that cannot be bought, assessed before anything is redesigned. - **Reporting from the field.** The machine-end data path to a remote-service or fleet platform, designed around an intermittent link. - **An implement interface.** J1939 or ISOBUS node-level work, bridged to whatever the control and data layer above it has become. - **A closed platform migration.** Control moved onto an open controller and toolchain, or the proprietary part isolated behind an interface so it can be replaced later. - **A device to build.** A purpose-built control node or telemetry gateway, built from board bring-up upward. - **Team bring-up.** Your own engineers brought up to speed. Training, then building the first implementation alongside your team, with third-line support behind them. ## How does a working machine reach a remote-service platform?A connector in the machine speaks to both ends, the machine bus and the remote platform.
The typical shape is a platform vendor assembling remote connection, remote debugging, fault resolution and remote operation for complex machines, which is then sold to the OEMs who build them. The machine's control data is exposed over OPC UA; the platform ingests over MQTT; and the join between the two is the part that has to be engineered. Our team built exactly that piece. At the time nothing joined the two sides: no companion specification, no reference implementation, and standards on both sides written for a plant floor with a fixed network rather than for a machine on an intermittent cellular link.The job is getting a protocol running correctly on a specific device, as a node on a third-party network.
That is the whole job: - The stack has to fit the part. - The timing has to hold under real bus load. - The device has to behave on a busy network as well as on the bench. ISOBUS (ISO 11783) is built on SAE J1939, so a J1939 node is the same work with a different application layer above it. As an example, our team has delivered CAN bus integration on farm and load-vehicle electronics, and SAE-level control integration on marine systems. The node-level discipline transfers across any of these networks; what changes is the application layer above it. Where a programme needs ISOBUS certification or Task Controller job data, the boundaries should be set early. Both are answered in the FAQ below.We design around the gaps, so a machine out of coverage still produces a complete record.
Coverage is intermittent, power is the machine's own, and the environment is dust, vibration and temperature swing, so buffering becomes the design centre: the edge device records the machine's data continuously and reconciles when a link appears, rather than sampling only while connected. Anything that assumes a live connection produces a fleet view with holes in it exactly where the interesting failures happened.We move control onto platforms with a documented supply horizon and an open toolchain.
The target matters more than the retrofit, so that is where we spend the assessment. It means the next revision is an engineering task the OEM can schedule, not a search for a discontinued part. Where a proprietary controller has to stay for now, we isolate it behind an interface so replacing it later is a contained change instead of a second migration. ## What does connecting a machine add to the compliance picture?A machine that carries data off itself becomes a product with digital elements, so the CRA applies.
That pulls the EU Cyber Resilience Act's obligations onto it alongside existing CE marking: - Secure update paths. - Vulnerability handling. - A documented software bill of materials. We build that in at the platform level while the control work is happening, because retrofitting a secure update mechanism onto a shipped fleet costs considerably more. ## What does the Cyber Resilience Act mean for a machine builder?It sets two fixed dates, and the decisions that meet them are taken years earlier.
Regulation (EU) 2024/2847 has applied vulnerability and incident reporting duties since 11 September 2026, with full enforcement on 11 December 2027, and it covers products with digital elements sold into the EU. For agricultural machinery that increasingly means the telemetry unit and the controller, not just the cab display, and the secure-update, SBOM and vulnerability-handling design behind them.We engineer the control network inside a mobility platform: redundancy, signalling paths and acquisition.
What we take is the network, the redundancy scheme and the acquisition inside your product. For a rolling-stock builder, a shipyard or an airframe integrator that means: - **The protocol and network layer**, from stack port and board bring-up through to a running redundant control network. - **The supervisory and information layer**, where operator stations and monitoring systems read the platform without joining the control loop. - **The acquisition layer**, where distributed IO is read, timestamped and carried to where the record is stored. - **Integration and test with your engineers**, onshore and remote, against real equipment. - **Training and third-line support** afterwards, behind your own first line. You keep the platform, its qualification, its operator relationship and its domain expertise. We do not commission on the vessel, the train or the aircraft. Where a design has to be integrated and tested, our team works with your engineers, onshore during integration and test and remotely for the rest. The [engagement page](/engagement/) sets out the modes and how they are priced.It is a standing specialism that a platform builder needs intermittently.
A shipyard, a rolling-stock builder or an airframe integrator employs deep expertise in propulsion, structures, braking and certification. Communication stacks, redundancy schemes and real-time network engineering are needed intensely during a programme and then not again for years, which makes them expensive to keep in-house and easy to let decay between programmes. The second pressure is that the platforms outlive their electronics by a wide margin. A control system specified today will see its processors, its network silicon and possibly its protocol go end of life while the vehicle is still in service. Someone has to carry it forward, and the original design team is usually long since assigned elsewhere.Any one of the layers inside the platform: the control network, the signalling path, the machinery interface, the acquisition.
- **Redundant control networks.** Redundancy engineered at three levels: redundant masters on the control network, redundant servers for the supervisory layer, and dual-redundant physical links between them. Each level fails over on its own, so a cut cable, a failed interface or a lost controller degrades the system by one element instead of dropping a section of the platform. - **Signalling and interlock paths.** Deterministic data paths where a missed cycle is a safety event rather than a quality one, built on real-time Ethernet with a dual-master arrangement so control has a standby ready to take the cycle. - **Machinery and engine-room integration.** Packaged equipment communicating over the bus its supplier ships, integrated at the controller so each segment keeps its native protocol and cycle while the controller publishes one normalised view upward. - **Acquisition and time sync.** Distributed IO read and timestamped against a common clock, so records from units in different parts of the platform can be compared afterwards. - **Operators and ground systems.** OPC UA and DDS layers carrying state outward, engineered so a subscriber can be added without disturbing the control cycle beneath it. ## How is redundancy engineered so no single fault stops control?Redundancy is engineered at three levels: the master, the link and the node.
Each level fails independently of the others. A standby master takes over the cycle when the active one stops. Traffic reroutes onto the surviving path when a link breaks. A node with two interfaces stays on the bus with one port down. None of these depends on the others, which is what stops a single fault cascading. Time synchronisation is what makes a takeover continuous instead of a restart. PTP keeps the standby aligned with the active node, so it assumes the cycle already in phase with the rest of the network. A publish and subscribe backbone does the same job by ranking its publishers: subscribers move to the standby writer on the next sample, without waiting for a supervisory system to notice the failure. Scaling changes how the nodes find each other. A small system can let every node discover every other node directly. Across several segments that full-mesh discovery becomes hard to maintain, so discovery moves to a central server, which can itself be made redundant. Joining nodes learn the topology from a known point, and commissioning becomes a controlled step instead of a broadcast storm. ## What does real-time signalling demand that ordinary control does not?A guarantee that holds under fault, not only under load.
Signalling data paths are engineered with two masters arranged so that control is never waiting for a single node to be replaced, and on real-time Ethernet the cycle is short enough that a takeover completes inside the tolerance the application allows. Our team has delivered signalling-side real-time control of this shape on an Ethernet POWERLINK network with a redundant dual-master arrangement. The protocol matters less than the property being bought, which is that the network has a designed behaviour when a master disappears. The newer question in this sector is information exchange rather than control. Railway operators are standardising the interfaces between signalling equipment and the systems that supervise it, and OPC UA is being adopted as the transport for it. Our own recent work here is a proof of railway real-time information exchange over OPC UA. In open source, Systerel also publishes that its S2OPC stack sits in signalling supervision gateways and on EULYNX-compliant platforms, which is useful corroboration that the direction is real and not a single operator's preference.At the controller, without demanding a common bus.
A thruster drive arrives on CANopen, a packaged auxiliary on Modbus TCP, a motion axis on EtherCAT. Each segment keeps its native protocol and its own cycle, and the controller publishes a normalised view of all of them onto the backbone, so operator and monitoring layers see one consistent system regardless of what each package speaks underneath. This is also where wiring gets simplified. Equipment with every sensor and actuator hardwired back to a central cabinet is a commissioning burden and a maintenance burden for the whole service life, and moving to distributed IO on a network removes both. For cases where the interface mix is known up front, one purpose-built device carrying the protocols and interfaces the platform actually needs can replace several off-the-shelf modules, taking out cost and shrinking the obsolescence surface at the same time. ## What is involved in onboard acquisition and time synchronisation?Acquisition reads distributed IO reliably; time synchronisation makes the records comparable.
- **Acquisition** is reading distributed IO reliably from units spread across a platform, on the respective interfaces each unit provides, at a rate that does not lose events. - **Time synchronisation** is making the resulting records comparable, which means every unit timestamping against one shared clock. The second is what decides whether the data is useful afterwards. Two units recording the same event against unsynchronised clocks produce a record that cannot be ordered, and no post-processing recovers that ordering. It is why the telemetry standards governing airborne acquisition carry time representation inside the packet structure itself, not left to the application.Rail, marine, engine-room and airborne systems; road-vehicle electronics is a different engagement.
The common property is a platform that moves, cannot be serviced while operating, and carries equipment from several suppliers that has to behave as one system. Road vehicles have their own pages and their own buyer. If you are building ECUs, in-vehicle networks or domain controllers, [automotive electronics](/industries/automotive-electronics/) is the one you want. If you are building plant that manufactures vehicles, that is [automotive](/industries/automotive/). ### Frequently asked questions **Do you commission systems on the vessel, the train or the aircraft?** No. We build the control and communication layer inside your product and test it with your engineers, onshore during integration and remotely afterwards. Commissioning on the platform belongs to you or to your integrator, who holds the operator relationship and the site qualification. Where a problem is traced back to our layer during commissioning, we are behind your first line for it. **Can a control system for a moving platform run on standard industrial hardware?** Often yes, and it is usually the better answer for serviceability. We have delivered control nodes on Linux industrial PCs and on VME hardware, which keeps the platform maintainable and the software stack under the builder's own control instead of inside a supplier's closed product. The qualification requirements of the domain decide how far that goes, and those are yours to state before the architecture is fixed. **What happens when the active controller fails?** Another one takes over the cycle, provided the failover was designed into the system. On a publish and subscribe backbone we rank redundant publishers so subscribers move to the standby on the next sample, without waiting for a supervisory system to notice. The same discipline applies at the link and server levels, each failing over on its own. **Can you work with equipment that is already built and running an older bus?** Yes, and this is most of the work in the mobility sector. Equipment with twenty years of service ahead of it is migrated instead of replaced, so the processing logic and the operator's own intellectual property are migrated to current controllers and protocols. Where the equipment cannot be touched at all, a gateway exposes it upward and the equipment itself is left alone. **Can you train our engineers, not just hand over the layer?** Yes, as the training, co-development and support offering above describes. We train your team on the stack and the configuration we deliver, build the first implementation alongside them, and then sit behind their first line as third-line support for as long as the product ships. On a platform with a thirty-year service life, the knowledge has to stay in your organisation. ### References - OPC UA (IEC 62541) — supervisory and information exchange, including the information-model layer above the control network - OMG DDS — real-time publish and subscribe data distribution between control and monitoring nodes - IEEE 1588 (PTP) — precision time synchronisation across redundant links and distributed acquisition units - IEC 61158 / IEC 61784 — industrial fieldbus and real-time Ethernet standards - IEC 61162-450 — Ethernet interconnection of shipboard navigation equipment - EULYNX — the European initiative standardising interfaces between signalling equipment and control systems - IRIG 106 — the telemetry standard governing airborne data acquisition and recording, including its time-stamping provisions