STM32MP25 Architecture and DO-160 Planning for an Air Cargo Telemetry Gateway

Project in a Nutshell: A European operator in pharmaceutical air freight came to Promwad to design the next generation of an in-flight telemetry gateway for their active temperature-controlled container. The system had to bridge industrial sensors inside the unit to a cloud platform over cellular connectivity and meet RTCA DO-160 requirements for airborne equipment. Promwad ran a full-scope architecture and feasibility engagement: hardware, firmware, software, mechanical, and certification planning. The client received a complete, execution-ready engineering package built around a heterogeneous STM32MP25-based system-on-module, a cellular IoT path, and a costed test and certification plan.

Client & Challenge

The client is a European operator in pharmaceutical air freight. They build active temperature-controlled containers used to ship biologics, vaccines, and other high-value pharmaceutical cargo in commercial aircraft cargo holds. In this market, a single spoiled shipment can mean a six- or seven-figure write-off and a regulatory compliance failure. 

For their next-generation container, the client needed a redesigned onboard telemetry gateway. It sits inside the unit for the entire journey, including the flight phase. It collects data from all onboard subsystems (sensors, battery and power management, autonomous temperature controllers) and forwards it to the cloud over cellular when a link is available. During flight, it must shut down all wireless transmission, a non-negotiable rule for any device in a commercial aircraft cargo hold. 

What makes this design class hard is the stack of constraints the gateway has to clear at once: 

• Operate from −20 °C to +70 °C and pass RTCA DO-160 environmental tests. 

• Keep industrial sensor polling deterministic regardless of Linux load. 

• Lose no telemetry under power-source switching of up to 250 ms. 

• Reconnect to cellular networks automatically and resiliently. 

• Survive aircraft vibration and pass EMC scrutiny inside a tight mechanical envelope. 

The client had a clear product vision but no in-house team with the combined embedded, aviation compliance, and cellular IoT depth to take it into a defensible design. They came to Promwad to formalize the architecture, validate it against every constraint before any prototype was built, and deliver a complete engineering package ready for execution. 

Solution

Promwad's team handled hardware, firmware, Linux software, mechanical design, and certification planning in one coordinated workstream. No domain owned a constraint in isolation. 

Promwad has shipped products under multiple regulated-industry standards, including IEC 62304 for medical device software and IEC 61508 for industrial functional safety. The same discipline applies to DO-160: design for certification from the start, not test for it at the end.

Architecture and Key Decisions

The architecture rested on five decisions, each made with explicit rationale and tradeoffs documented for the client.

Heterogeneous compute with workload separation. A Cortex-A35 plus Cortex-M33 SoC was chosen over a single application processor because sensor polling on industrial buses has timing requirements that a general-purpose Linux scheduler cannot guarantee under load. Putting the polling loop on the M33 with FreeRTOS isolates it from anything happening on the Linux side. RPMsg over the inter-processor communication controller (IPCC) gives a structured channel for telemetry to flow up to the A35 for routing and forwarding. 

Dedicated cellular module instead of an on-board modem. The Digi XBee 3 Cellular module handles cellular access, MQTT, and TLS on its own MicroPython runtime. This adds a UART hop between the gateway service and the cloud, but it removes a class of risk. Hard guarantees around radio shutdown in flight mode are easier to deliver when the radio is a discrete component with controllable power, and modem behavior stays decoupled from any firmware update on the main system-on-module. 

Compliance treated as part of the engineering plan, not a separate workstream. The test and certification plan included external laboratory categories, lead times, retest probability assumptions, and a contingency model. This made the path to a certifiable product visible at the start of execution. 

Business Value

The engagement converted a product vision into an execution-ready engineering package. Four outcomes the client took into the next phase: 

• Architecture validated on paper. Every binding constraint (aviation environment, in-flight radio shutdown, brown-out tolerance, deterministic sensor polling, cellular resilience) mapped to an architectural choice with documented rationale. 

• Expensive decisions locked early. Compute platform, cellular strategy, power architecture, and software domain split, all decided before any hardware was fabricated. 

• Certification path costed and timelined. External lab fees, retest probability, and parallelization options modeled, so the cost of compliance was visible at the start of execution rather than discovered six months in. 

• Risks made visible, not implied. A structured risk register covering hardware, mechanical, and program domains, each item paired with a mitigation strategy. 

More of What We Do for Functional Safety

• Industrial Controller Development: end-to-end development of PLC, I/O, and DAQ controllers with RTOS/Linux, multi-protocol connectivity, and field-ready designs.

• Dual-MCU Railway BMU: NXP S32K-based battery management architecture for SIL2 certification and EN 50155-compliant railway systems. 

• IEC 61508 Functional Safety Guide: how IEC 61508 compliance is integrated into product design, from concept through certification..