ARTIFICIAL INTELLIGENCE


Designing physical AI for the model you haven’t met yet


Physical AI is creating a lifecycle mismatch between rapidly changing machine learning models and long-lived embedded systems. Engineers need to be ready for this.


A


n industrial machine can remain deployed for a decade, but its AI workload may change several times during that same period. That difference matters because embedded hardware has traditionally been designed around relatively stable processing requirements. Physical AI challenges that assumption. Today’s vision model may become tomorrow’s multimodal application. A convolutional neural network could give way to a transformer, large language model (LLM), or sensor-fusion pipeline. The compute platform selected during development can therefore become a future redesign constraint.


Engineers therefore face two lifecycle questions: can today’s compute platform support tomorrow’s workloads, and can the compute platform itself be replaced without redesigning the machine?


The hidden cost of changing compute


Changing an AI compute platform rarely means replacing one component. It can trigger changes across the carrier board, thermal design, drivers, software and validation process. That creates a form of migration debt. The deeper compute is embedded within a product architecture, the more expensive it is to change direction. Engineers already consider power, performance, interfaces, cost and availability when selecting embedded hardware. Compute replaceability deserves a place on that list.


The question is simple: how much of the existing design survives if the AI platform changes?


One answer is greater modularity at the compute layer. System-on-smodules (SoMs) separate carrier-board development from fast-moving processor technology. A modular compute architecture can isolate processor changes from the rest of the machine. Compatible mechanical dimensions, connector placement, power delivery and I/O mapping can allow the carrier board to remain stable while compute evolves.


SiMa.ai’s Modalix MLSoC (Machine Learning System-on-Chip) and Modalix SoM illustrate this approach. The company designed the Modalix SoM as a pin-compatible replacement for NVIDIA’s Jetson Orin NX and Nano system-on-module form factor. For compatible carrier-board designs, that approach can reduce the amount of hardware redesign required when migrating between AI compute platforms. Hardware compatibility, however, only solves half the problem.


Protecting software investment A processor swap can preserve the PCB but still force engineers to rebuild the software stack. That can erase much of modular hardware’s advantage. Software portability therefore becomes an integral part of compute replaceability.


Avnet’s 2026 survey found that 38 per cent of engineers cited integration with existing tools as a key AI design challenge. The survey included approximately 1,200 engineers worldwide. That integration problem can become more signifi cant when the underlying hardware changes during the product lifecycle.


Highly custom CUDA and TensorRT code may require platform-specifi c replacements, as migration can preserve


16 OCTOBER 2026 | ELECTRONICS FOR ENGINEERS


model assets and application logic while still requiring workarounds for hardware-specifi c dependencies. Engineers should always validate migrated code against their legacy codebase, libraries, drivers and deployment pipeline.


Preparing for tomorrow’s AI workloads


AI workloads are becoming increasingly diffi cult to predict over the lifetime of an embedded system.


A product designed today may begin with object detection, then add speech, language, or multimodal reasoning during its deployed lifetime. If those changes require new carrier boards and wholesale software rewrites, the original processor decision can restrict the product roadmap. That risk also changes how lifecycle cost should be measured. Can the system absorb a different workload, processor, or software stack without redesigning everything around it?


For physical AI, that increasingly means separating long-lived product infrastructure from fast-moving compute. The best compute architecture may not simply be the one that runs today’s model effi ciently. It may be the one that leaves engineers the most cost-effective route to tomorrow’s.


Page 1  |  Page 2  |  Page 3  |  Page 4  |  Page 5  |  Page 6  |  Page 7  |  Page 8  |  Page 9  |  Page 10  |  Page 11  |  Page 12  |  Page 13  |  Page 14  |  Page 15  |  Page 16  |  Page 17  |  Page 18  |  Page 19  |  Page 20  |  Page 21  |  Page 22  |  Page 23  |  Page 24  |  Page 25  |  Page 26  |  Page 27  |  Page 28  |  Page 29  |  Page 30  |  Page 31  |  Page 32  |  Page 33  |  Page 34  |  Page 35  |  Page 36  |  Page 37  |  Page 38  |  Page 39  |  Page 40  |  Page 41  |  Page 42