Component planning for an industrial edge-AI device should focus on interfaces, power, cooling and version relationships between compute module and carrier board, not just a compute-performance headline. This article addresses industrial hosts and boards, not AI-model benchmarking or a promise of complete software and system delivery.
1. Define the module–carrier division
List responsibilities for compute module, carrier, storage, external interfaces and auxiliary power. Identify what the module provides, what the carrier implements and what depends on firmware or platform configuration.
NVIDIA's archived Jetson Linux r36.4.3 adaptation guide covers carrier adaptation, pin multiplexing and platform configuration, illustrating why physical connectors alone do not define an interface.[1] It is cited as a fixed-version example, not as the latest software or a universal rule for every edge platform.
2. Record interface and software versions together
For cameras, networking, storage and expansion, identify protocol or signal type, port count, connection, cable and software-support conditions. Matching physical formats do not automatically establish matching protocols or functionality.
Conceptual relationship for planning, not a manufacturing diagram:
Sensors/network ↔ carrier interfaces ↔ compute module ↔ storage/output; input power → conversion and monitoring → module/peripherals; platform configuration and firmware ↔ defined hardware revision.
Board links require complete mating identities and relevant documentation rather than only a family name.[4]
3. Plan power by operating state and sequence
Record input range, continuous and dynamic compute/peripheral loads, sequencing, allowed reset behavior and thermal conditions. One module power label does not define every rail current or include every peripheral and startup event.
External components, layout and thermal requirements in power-module documentation still apply to the carrier implementation.[2] Supporting capacitors also need selection against actual conditions. No unmeasured peak-power, efficiency or temperature figures are supplied here.
4. Treat mechanics, cooling and service as one configuration
Describe enclosure, orientation, ambient conditions, cooling, connector access and field replacement. If module or cooling hardware changes, review whether prior evidence remains applicable.
A practical sequence fixes module and carrier versions, reviews interfaces and power, checks mechanical and thermal implementation, then verifies application software with real loads. One successful startup does not cover sustained operation, load changes or maintenance.
5. Maintain module and critical-part records
| Block | Components/documents | Project inputs | Lifecycle concern |
|---|---|---|---|
| Compute/carrier | Module, board links and platform documents | Exact identities and hardware/software versions | Controlled configuration and change owner |
| External interfaces | Transceivers, connectors, cables and protection | Protocols, ports, signals and service | Mating parts and compatibility verification |
| Power | Conversion, monitoring and passives | Input, load, startup and thermal conditions | Alternatives must cover real operation |
| Storage/expansion | Memory, interfaces and mounting | Function, interface and software dependencies | Same package does not establish replacement |
| Mechanical/thermal | Fixing, cooling and structural information | Space, environment and replacement method | Reconfirmation after changes |
| Purchasing | BOM, official status and orders | Quantity, timing, revision and source | Notices trigger review |
6. Keep the BOM aligned with platform changes
Connect manufacturer notices to the exact affected part and project revision before choosing design, verification or purchasing actions.[3] An unapproved candidate is not an established second source. Hardware/software-dependent substitutions should not be decided solely from a purchasing parameter table.
Provide MISUXIN with the carrier BOM, module revision, interfaces, power and environment. Discussion centers on components and documentation; public platform references are not represented as MISUXIN system-performance or compatibility tests.
References
[1] NVIDIA. Jetson Orin NX and Nano Series — Module Adaptation and Bring-Up. Archived Jetson Linux r36.4.3; carrier-board adaptation, pinmux and platform configuration. Not a statement of the latest software release.
[2] Texas Instruments. TPSM53604 — power-module datasheet. Revision C; electrical characteristics, application guidance, external components, layout and thermal considerations.
[3] Texas Instruments. Product change notification and discontinuation information. Notice content, affected products and notification process. Manufacturer-specific timelines are not generalized.
[4] Samtec. QSH product and mating documentation. Prints and footprints, full mated sets and configuration-specific test reports.
Related reading S03 (earlier) · S08 · S10
Sources checked: 19 September 2026. Templates and conceptual relationships are editorial aids; confirm individual applications against manufacturer documents and project conditions.