Today, an intelligent robotic platform simultaneously has to run real-time multi-axis motion control, processes multiple data streams from various sensors including 2D and 3D vision cameras and/or LIDAR.
How the Modular Concept Can Help You Build a Future-Proof and Secure Robotic Computing Platform
Q&A with Claire Liu, Senior Market Segment Manager – Robotics | congatec
First, tell us about yourself and your role with congatec.
I’ve been with congatec since 2022, focusing on embedded computing solutions for robotics applications. My background centers on analyzing market trends, key technologies, and the technical requirements of customers in this field. I’m driven by a strong passion for advancing robotics, particularly in how modular computing platforms can enable more secure and scalable system designs. I’m excited to share the insights we’ve gained at congatec and how they can help robotics companies make informed decisions around their next-generation computing architectures.
What are the biggest changes you have seen in robotics?
A few years ago, a robot controller only had to manage motion sequences. Today, an intelligent robotic platform simultaneously has to run real-time multi-axis motion control, processes multiple data streams from various sensors including 2D and 3D vision cameras and/or LIDAR, executes AI inference for object detection and classification and takes care of simultaneous localization and mapping (SLAM) in mobile robots. And tomorrow, the technical requirements are changed, the computing platform will need to support vision-language-action models, multimodal perception, and the ability to execute more complicated tasks more intelligently autonomously. That is a fundamentally different design challenge, and it exposes the limitations of both full-custom boards and standard off-the-shelf solutions when considering parameters such as scalability, security, product lifetime, and return on investment.
Why do standard off-the-shelf SBC and full-custom boards fall short for robotics scalability and security today?
This is a question we get asked constantly, and the answer really clarifies why Computer-on-Modules have become a compelling architectural choice. Let me take each option in turn.
Off-the-shelf commercial SBC are not always a suitable form factor for every robotic application. Reasons for this include that they don’t provide the required interfaces tailored for every application. Standard off-the-shelf boards solve the time-to-market problem but introduce a different one: they cannot easily be adapted to specific interface requirements. For low volume or simplistic requirements, the Standard SBC makes sense.
On the other hand, full-custom board designs can be optimized for a single application but lack the flexibility to be adapted for different use cases. Each new application would require starting a new design from scratch, even when only minor interfaces or connectors change, not to mention if a new CPU has to be integrated. Although a custom design offers high price efficiency when produced in large volumes, the design efforts and development costs may be too high for most robotic applications. You also have to consider development time. In our fast-moving world, where new silicon generations emerge every year, you are faced with a constant stream of redesigns. You may not be agile enough to meet evolving market demands.
From a security standpoint, custom designs also mean custom security work: you own every layer of the stack, including managing BIOS updates, firmware patches, and driver vulnerabilities yourself. For most robotics companies, those volumes and margins simply do not provide the optimal ROI. If you want to sell into the EU, for example, you have to fulfill the Cyber Resilience Act (CRA), which puts high demands on cyber security.
So what is the alternative for designers?
A modular approach with standardized Computer-on-Modules (COMs) delivers the entire computing core-processor, memory, high-speed interfaces, BIOS, and drivers — as a single off-the-shelf building block. The robotics vendor’s engineering effort is focused exclusively on the custom carrier board, which houses the application-specific interfaces and I/Os their robot needs.
The upgrade story is where this really becomes compelling for physical AI and sensor fusion workloads, specifically. When a new processor generation delivers more AI inference performance, many using a COM architecture can upgrade to the new capabilities without redesigning their board. On the hardware side all you have to do is exchange the standardized modules. The same carrier board investment and the same mechanical enclosure — but with substantially more AI headroom to support denser sensor arrays, more sophisticated fusion algorithms, or new perception capabilities.
Do you have a real-world example of a successfully built scalable, future-proof robot using COMs — and what specifically did they gain?
Our customer ANYbotics is one of the examples of leveraging the COM concept. They are a Swiss company building autonomous inspection robots — the ANYmal series — for complex, hazardous, and explosive industrial environments. The demands on the computing platform are challenging.
Real-time motion control, path planning, situational awareness, obstacle avoidance, and the flexibility to integrate new AI capabilities as they emerge-all on a COM structure. ANYbotics chose congatec's application-ready COMs as their integrated computing platform for navigation, path planning, and real-time motion control.
What did they gain? Three things stand out. First, they were able to focus entirely on their core competencies. Second, the modular approach gave them optimized cost, performance, and power balance from day one. Third — and this is the dimension that matters for the scalability and can be upgraded to the latest processor technology by replacing the module as technology evolves.
congatec offers a real-time hypervisor as another modular component, how is this particularly beneficial for secure robot design?
Think of it like this: if the Computer-on-Module is the brain of the robot, the real-time hypervisor is the part of that brain that prevents one thought from interfering with another.
In a modern robot arm, for example, you might need to run real-time motion control, AI inference for object detection and classification, a human-machine interface, and an IIoT connectivity gateway. Traditionally, each of these would have required a dedicated hardware controller. With a real-time hypervisor running on a single high-performance COM all of these workloads can be consolidated onto one hardware platform, each running in its own isolated virtual machine.
System consolidation reduces the number of physical hardware- fewer hardware means fewer potential points of failure and a smaller attack surface. And hardware-level isolation between workloads means that even if an attacker finds an entry point in, say, the IIoT gateway, they cannot pivot into the critical motion control layer. That isolation is enforced at the hypervisor level, below the operating system, making it extremely difficult to subvert.
Are there other major security concerns that should be addressed during design phase?
The Cyber Resilience Act (CRA), is genuinely one of the most important regulatory shifts for any robotics company with European ambitions. The CRA is a European Union regulation that establishes cybersecurity requirements for all products with digital elements, whether hardware, software, or a combination of both, intended for placement on the EU internal market. Compliance with the CRA will become mandatory for obtaining the CE mark, which is essential for accessing the European market. Non-compliance can result in significant penalties.
The CRA, entered into force in December 2024 to define cybersecurity as a mandatory market entry requirement, embedded directly into the CE marking framework that already governs product safety in Europe. This regulation will be fully enforced starting December 11, 2027, giving manufacturers a clear timeline to align their processes and products with these requirements. So, if you are a US robotics manufacturer selling or planning to sell into any EU member state, this regulation applies to you.
What are some key CRA Compliance Dates for US Manufacturers?
September 11, 2026 -Initial CRA obligations take effect, requiring compliance with reporting requirements.
December 11, 2027-.Full enforcement begins. Any product “placed on the market” in EU after this date, regardless of its original launch date, must comply with the CRA.
What makes the CRA different from previous directives is its lifecycle scope. It is not enough to build a secure product at launch. Robotic companies must maintain security across the entire product life cycle, providing updates, monitoring vulnerabilities, and documenting and reporting mechanisms that make every software component traceable.
For US robotic companies, the clock is already running. Robotics product development cycles can take more than 12 months.
Companies that start designing for CRA compliance and implementing modular architecture now will gain a significant competitive advantage over those who treat it as an afterthought. Modular architecture helps keep systems secure throughout their entire lifecycle and provides a foundation for future hardware updates, extending the overall system’s lifespan.
What are the misconceptions US robotics companies hold about the CRA — and how does a modular COM-based approach help address the real requirements?
There are three misconceptions we encounter and each of them can be genuinely costly if left uncorrected.
Misconception one: "The CRA only applies to internet-connected IoT devices." This is incorrect. The regulation covers a broad spectrum of "products with digital elements, " which means hardware or software that processes, stores or transmits data. For example, industrial robots with network connectivity are squarely in scope. There are category differences in conformity assessment rigor, but robotics manufacturers should assume they fall under the act and seek qualified legal and technical guidance.
Misconception two: "We can continue selling our product as long as we don't change it
At first glance, this seems plausible. Article 69(2) of the CRA includes a transitional rule: products placed on the market before December 11, 2027 only fall under the CRA if they are substantially modified afterward. But the key legal concept is not “modification”—it is “placed on the market.”
The EU Blue Guide distinguishes between:
Placing on the market: a one-time event per individual unit, when it is first supplied in the EU.
Making available on the market: all subsequent distribution of that same unit.
The transitional rule applies only to individual units already placed on the market before the deadline. For example, a unit shipped to a distributor before December 11, 2027 remains covered—even if sold to an end customer later. That later sale is merely “making available.”
By contrast, any unit first supplied after December 11, 2027 is a new placing on the market and must fully comply with the CRA—even if it is identical to earlier units. The European Commission’s FAQ makes this explicit: the regulation applies to individual units, not product types.
Misconception three: "We will manage all security obligations in-house." The CRA requires active reporting of exploited vulnerabilities to relevant authorities within 24 hours of discovery, continuous post-market monitoring, timely vulnerability remediation, and ongoing security updates throughout the product lifecycle. That is a sustained operational commitment, not a one-time engineering task. At congatec, we issue regular updates for BIOS, firmware, and drivers in our COMs-offloading some share of that compliance burden directly from the OEM. Our modular architecture means that when a new security patch or processor generation is required, the update path is a module swap, not a full product redesign.
Looking ahead, what practical advice would you give to a robotics engineering team that wants to start building security and CRA compliance into their next design today?
My first piece of advice is: start now. The CRA's full enforcement date of December 2027 sounds distant, but when you account for hardware development cycles, compliance documentation, conformity assessment, and the time needed to build security into software stacks properly, it is not. Companies that begin CRA-aware design in 2026 will be in a fundamentally better position than those who begin in 2027.
Second, choose your computing platform and embedded partner with security in mind — not just performance. Ask your module vendor: how do you handle BIOS and firmware updates? What is your security lifecycle policy? Do you have a partner ecosystem that supports CRA compliance tooling? Are you certified to a cybersecurity standard like IEC 62443? These questions will separate vendors who treat security as a product feature from those who treat it as a compliance checkbox.
Third, evaluate whether a real-time hypervisor belongs in your architecture. For any robot that runs multiple workloads — motion control, AI inference, IIoT connectivity, HMI — workload consolidation via hypervisor not only helps to simplify your system and reduce hardware BOM costs, it also enforces the hardware-level isolation that is under a security-by-design mandate
Finally, do not treat security as a one-time engineering effort. The CRA requires ongoing monitoring, vulnerability reporting, and patching throughout the product lifecycle. Build that operational capability into your organization now and partner with a COM vendor who has already built it into theirs.
What should engineering teams actually look for in an embedded computing platform — and how do you match the right hardware to the right robotic application?
This is a question that comes up constantly as robotics engineering teams start evaluating Edge AI: it depends on where your robot operates and what it needs to do locally. AI TOPs is a simplified metric that measures how many operations AI hardware can perform in a second. However, AI TOPs do not differentiate between the quality or type of operation being performed, and shouldn’t be the only metric. When evaluating an embedded computing platform, you should ask your vendor to run real-life benchmarks in the first place. But you also need to put thermal budget, form factor, memory bandwidth, and long-term availability into consideration. A good partner will support you with these questions.
At congatec, we cover a broad range of demands: For high-end intelligent robots where maximum bandwidth matters, COM-HPC Client modules like the conga-HPC/cPTL are your best option. You get PCIe Gen5 connectivity for external sensors and up to 96GB of high-bandwidth LPDDR5x memory —— which is critical when you are feeding its 120 TOPS GPU during complex inference.
For edge robotics where space and vibration resistance are the primary engineering constraints - a COM-HPC Mini form factor- conga-HPC/mIQ-X is built precisely for this workload in a 95×70mm footprint. conga-HPC/mIQ-X is based on the Qualcomm® Dragonwing™ IQ-X Series, it delivers up to 12 Qualcomm® Oryon™ CPU cores , a 45 TOPS Qualcomm® Hexagon™ NPU, and a high-performance Adreno™ GPU within low power envelope suited for sustained mobile operation. Two 4-lane CSI interfaces support multi-camera sensor fusion natively, USB4 covers high-bandwidth peripheral connectivity, and the Qualcomm Spectra ISP brings hardware-accelerated image signal processing directly into the pipeline.
For teams with existing carrier board designs who want to add modern Edge AI capability without a full redesign, a COM Express Type 6 module like the conga-TC1000r offers a practical "drop-in" upgrade path — and for harsh environments specifically, a rugged variant with wide-range power supply and an industrial temperature range of -40°C to +85°C to withstand industrial environment
For edge robotics, where space and ultra-low power consumption are the primary engineering constraints, a SMARC module like the conga-SMX95 based on the NXP i.MX 95 is worth consideration. At just 3–8W and 82×50mm, it integrates a 6-core ARM Cortex-A55 application processor , the NXP eIQ® Neutron NPU for on-device ML inference and dual Gigabit Ethernet with TSN, providing essential computing and AI capability in a small package.
Claire Liu is Senior Product Marketing Manager for Industrial Automation & Robotics. Claire is an experienced product marketing manager with over 15 years global experience in the embedded computing industry with a focus on edge AI and robotics. She started her embedded career in 2007 at Kontron. Prior to joining congatec, Claire supported Adlink as Product Marketing Manager for AI/Robotics and IoT.
For more information visit congatec’s robotics page
The content & opinions in this article are the author’s and do not necessarily represent the views of RoboticsTomorrow
Featured Product
