Embedded firmware that's documented, maintainable, and built to live for ten years.
Industrial firmware isn't a script that works on delivery day. It's a complex system, on Zephyr, FreeRTOS or Linux, that has to keep running after ten years of series production, update securely in the field, report telemetry statistics on how it behaves, and withstand a regulatory environment that keeps moving (CRA, IEC 62443).
Expertise led by Hugues Orgitello, electronic-design engineer and founder of AESTECHNO Montpellier (10+ years of experience, certified CAP'TRONIC instructor).
- IEC 62304
- IEC 62443
- ETSI EN 303 645
- Cyber Resilience Act (CRA)
- MCUboot
- RAUC
Industrial firmware has to outlive its team
An industrial product stays in series production 5 to 15 years. During that period the team that designed it can change three times over. Firmware that can only be maintained by its original author is hidden technical debt, and it surfaces at the worst possible moment, when a critical customer asks for an urgent fix.
At AESTECHNO, with over 10 years of experience in embedded design, we write firmware that's documented in intent: why this architecture choice, why this timing, why this interrupt priority. The code itself stays conventional and readable. A successor team can take over in a few weeks, not six months. See our complete guide: Industrial embedded software guide.
Secure OTA: not optional, mandatory
From 2027, the Cyber Resilience Act (CRA) requires every connected product to support security updates for the expected product lifetime. Without secure OTA, no industrial IoT product will be sellable in Europe.
We systematically integrate: secure boot anchored in hardware (chain of trust verified at every startup), ECDSA signature on every OTA image (MCUboot for MCU, RAUC for Linux), encrypted storage for secrets, TLS 1.3 for all network communication, and IEC 62443 alignment for industrial products.
Handling the CVEs raised by the SBOM requires an operational prioritization layer, a point validated by Thierry Durand of Embedded Expertise, our independent peer in embedded cybersecurity: scanning with Grype or Trivy is only the first step; the real engineering work is prioritization and remediation steering in the product's operational context. See our article on industrial IoT cybersecurity.
Remote updates and telemetry: staying in control of the fleet
A connected product does not stop at delivery: you need to fix it, improve it and know how it behaves in the field. At AESTECHNO, we build remote updates (OTA) and telemetry statistics into the firmware itself, on Zephyr as well as FreeRTOS. A remote update must be able to fail without bricking the device: a signed image, verified before installation, with a way back to the previous version if the new firmware does not boot correctly.
Telemetry answers a different question: what is actually happening across the fleet? Depending on the product, the firmware can report operating statistics such as reset causes, the installed version, battery state or radio link quality. That data tells you when to roll out a fix, confirms that an update went through, and flags a problem before it reaches the customer. See also our article on embedded DevOps and CI/CD.
RTOS choice: Zephyr, FreeRTOS, NuttX, Linux
Picking an RTOS or embedded operating system isn't ideological, it follows from the product's constraints: memory footprint, target certification, driver ecosystem, real-time requirements.
On constrained MCUs (Cortex-M0/M4 with 64-256 KB of RAM), Zephyr offers the most modern ecosystem and the best long-term maintainability. FreeRTOS, lighter and very widespread, carries complex firmware just as well: we develop on both, and our products in production run on both. The choice between them depends on the drivers available for the MCU, the existing code base and the target certification, not on how complex the project is. For embedded Linux (Cortex-A, MPSoC), Yocto with a clean BSP and an SBOM (CycloneDX, SPDX) is our default choice on any product expected to clear CRA compliance. In Q1 2026, we delivered a Jetson Orin NX project with a fully customized BSP, developed on Yocto for an industrial customer. See our article: Embedded Linux distributions comparison.
IEC 62304 compliance, for medical
When firmware ships inside a medical device, IEC 62304 adds strict documentation discipline: software classification (A, B, C by patient impact), requirements ↔ code traceability, SOUP management (Software of Unknown Provenance, i.e. third-party libraries), validated update process.
Our approach: structure the firmware in components with clear criticality, isolate Class C functions in a dedicated module (qualified under IEC 62304), handle the rest as Class A/B with ISO 13485-grade rigour. This keeps the qualification effort to the strict regulatory minimum. We have designed CI/CD pipelines for multiple projects, with auto-deployment conditional on complete test validation: to servers or to the Play Store depending on the product. See: Embedded DevOps and CI/CD.
FAQ
- Embedded Linux or RTOS? How do you decide?
The simple rule: if the product needs a complete network stack (TCP/IP, TLS, multitasking), a rich graphical UI, or a file system, Linux. If the product is hard real-time (latency < 1 ms), low-power (sub-mA on average), or safety-critical, RTOS. Many industrial projects combine both: an MPSoC with Linux on the application side and a companion MCU (Zephyr or FreeRTOS) for real-time functions. See Zephyr, FreeRTOS or Linux for real-time embedded.
- Do you develop complex firmware on FreeRTOS or Zephyr?
Yes. We develop complex firmware on FreeRTOS as well as Zephyr, and our products in production run on both. Project complexity does not decide between the two RTOSes: FreeRTOS is light and very widespread, Zephyr brings an integrated driver model and network stack. We choose based on the drivers available for the MCU, the customer's existing code and the target certification. See Zephyr, FreeRTOS or Linux for real-time embedded.
- Do you provide remote updates and telemetry?
Yes. We build remote updates (OTA) and telemetry statistics into the firmware. Updates are signed and verified before installation; depending on the product, telemetry reports indicators such as reset causes, the installed version or battery state, so fixes can be steered across the deployed fleet.
- How do you handle CVEs that surface after deployment?
Automatic SBOM generation (CycloneDX) at every build, continuous scanning (Grype, Trivy), and, this is the key work, prioritization by operational context: what's the real attack surface of this CVE on this product deployed at this customer? Most CVEs raised by a raw scan aren't exploitable in the product's context, but they clutter reports. We work with Thierry Durand (Embedded Expertise) on this prioritization discipline.
- Can you take over an existing firmware that needs fixing?
Yes. Taking over a failing or drifting electronics project is one of our typical cases. We start with a structured technical diagnostic (architecture, code quality, technical debt, observed failure modes), then propose a costed stabilization plan before any long-term commitment. See our article: Taking over a failing electronics project.
Très bonne collaboration avec AESTECHNO ! Une équipe à la fois sympathique, efficace, flexible et réactive. Leur expertise, aussi bien en conception électronique, qu'en développement logiciel et mise au point système, a été un véritable atout pour la réussite du projet. Je recommande sans réserve.
Medical
Designing a medical device isn't about retrofitting an industrial board. It's about embedding patient safety, software traceability and risk management into every architectural decision, from specification to MDR technical file. At AESTECHNO, with a team bringing 10+ years of design experience and 65 projects delivered since 2022, we've developed medical-class specialized lighting and designed numerous products compliant with CE and international standards.
Hardware
A PCB delivered by us is a PCB you can manufacture at scale, certify at its first test campaign, and assemble in the factory without surprises. EMC, IPC standards and DFM are built into the schematic, not added after the prototype smokes. Our hardware engineering services are contracted on the board we deliver, not on the hours we spend on it.
Industrialization
The classic trap: a working prototype that needs six months and a re-spin to hold up in series production. At AESTECHNO, our technical signature is the opposite. DFM, IPC standards and testability are integrated into the initial schematic. The prototype is already a manufacturable board. We deliver a pre-production optimized working prototype on the first attempt; 100% success rate on CE/FCC certifications, across dozens of campaigns run over more than 10 years of practice.