この記事の前提
- C-1〜C-3で扱ったSBCの分類と選定観点を引き継ぎます
- 回路設計の手順ではなく、SBC／SoM／フル自社設計の境界を整理します
- 製品ごとの供給期間、温度範囲、認証情報は、採用時点の公式資料で確認します
はじめに
前回までで、学習用SBC（C-2）と用途特化SBC（C-3）を見てきました。今回は「試作はSBCで動いた。では製品はどう作るのか」という問いを考えます。
キーワードはSoM（System on Module）／COM（Computer on Module）とキャリアボードです。産業機器でも使われる「二階建て」の設計を、Raspberry Pi Compute Module（CM4／CM5）を入口に整理します。
一枚完結のSBC、役割を分けるSoM
一般的なSBCは、SoC、DRAM、電源回路、ストレージ、外部コネクタを1枚にまとめています。SoM／COM方式では、演算の中核と製品固有部分を2枚に分けます。
- SoM側：SoC、DRAM、電源管理、必要に応じてeMMCや無線回路などを集約し、モジュールとして購入する
- キャリアボード側：製品に必要なI/Oコネクタ、電源入力、PHY、センサー、リレー、表示器、基板形状などを設計する
DDR配線やSoC周辺の電源設計など、難度の高い領域をモジュールベンダーへ寄せ、自社は製品固有回路へ集中できます。ただし、高速I/Oをキャリアへ引き出す場合、その配線設計や電源・EMC評価まで不要になるわけではありません。
Raspberry Pi Compute Module：身近なSoM
Compute Module 4は、Raspberry Pi 4と同じBCM2711を搭載したSoMです。通常のSBCと比べると、製品組み込み向けの性格が見えてきます。
| 観点 | Raspberry Pi 4 Model B | Compute Module 4 |
|---|---|---|
| ストレージ | microSD | eMMC搭載品、またはeMMCなしのLite |
| 外部コネクタ | USB、HDMI、Ethernetなどを実装 | 信号を2個のB2Bコネクタへ引き出す |
| 構成選択 | 主にRAM容量 | RAM、eMMC容量、無線有無の組み合わせ |
| 無線 | 搭載 | 搭載／非搭載を選択可能 |
| 基板設計 | SBCをそのまま使う | 公式IO Boardまたは自社キャリアが必要 |
| 生産継続 | モデルごとに確認 | 少なくとも2034年1月までと公式に案内 |
手元のCompute Module 4です。表面にSoCとメモリが集約され、裏面の2個のB2Bコネクタでキャリアボードへ信号を引き出しています。
Lite版はeMMCを搭載せず、SDインターフェースをキャリア側へ引き出します。「Liteなら必ずmicroSDを使う」という意味ではなく、ストレージ回路をキャリア側で設計する選択です。
Compute Moduleは、Raspberry PiのOS資産を活かしつつ、必要なコネクタと基板形状を製品側で決められる中間解です。公式IO BoardでソフトウェアとI/Oを評価し、その後に自社キャリアへ移る流れを作れます。Compute Module公式資料には、IO Boardを参照設計として利用する考え方も示されています。
産業用SoM／COMの世界
モジュールとキャリアを分ける考え方はRaspberry Pi固有ではありません。産業分野には、標準規格に基づくものと、ベンダー独自仕様のものがあります。
- 標準規格系：SMARC、Qseven、COM Express、COM-HPCなど
- ベンダー独自系：NXP i.MX、TI Sitara、ST STM32MP、ルネサスRZ系などを搭載した各社SoM
標準規格は、機械寸法、コネクタ、信号配置などを共通化し、製品の拡張や移行をしやすくすることを狙っています。ただし、同じ規格名でもピンタイプ、対応信号、消費電力、冷却条件、BSPが異なります。規格品なら無条件で差し替えられるわけではありません。
たとえばCOM ExpressやCOM-HPCでは、モジュールと用途固有のキャリアを組み合わせる構成が規格化されています。
産業向けSoMでは、次の情報が選定の中心になります。
- 生産継続方針と変更通知
- 商用／工業用などの動作温度範囲
- Linux BSP、Yoctoレイヤー、セキュリティ更新の提供方針
- 回路図、レイアウトガイド、適合性資料
- 不具合解析、PCN、代替品などの技術支援
価格だけでなく、設計資料、保守、供給管理を含めて比較する必要があります。
SBC直載せ、SoM、フル自社設計を比べる
| 観点 | SBCを組み込む | SoM＋自社キャリア | SoCから自社設計 |
|---|---|---|---|
| 初期開発 | 小さく始めやすい | キャリア設計が必要 | DDR・電源を含めて大きい |
| 形状自由度 | SBC形状に依存 | キャリア側で調整可能 | 最も高い |
| 単価 | SBC価格に依存 | モジュール＋キャリア | 数量と設計償却に依存 |
| 供給管理 | SBC単位 | SoMとキャリア部品 | 全部品を自社管理 |
| 環境条件 | モデル仕様に依存 | 条件に合うSoMを選ぶ | 自社で設計・検証する |
| ソフトウェア | 配布OSを使いやすい | BSPとキャリア差分が必要 | BSP立ち上げ範囲が最大 |
数量だけで自動的に決まるものではありません。開発人数、発売時期、必要認証、更新期間、基板面積、調達方針を含めた総コストで判断します。
SoM採用で残る仕事
- キャリア設計：PCIe、MIPI、USB、Ethernetなどは、モジュールのデザインガイドに従って配線する
- 嵌合と固定：B2Bコネクタ、スペーサー、ねじ、筐体を含めて振動・衝撃を評価する
- 熱設計：SoMの温度範囲だけでなく、負荷、ヒートスプレッダ、筐体内温度で確認する
- 書き込みと復旧：eMMC、ブートローダー、量産イメージの書き込み方法と、失敗時の復旧経路を決める
- BSPの評価：カーネル、Device Tree、ブートローダー、更新頻度、ライセンス、脆弱性対応を確認する
- 変更管理：SoMリビジョンと自社キャリア、OSイメージの対応表を維持する
CM4／CM5のeMMC書き込みでは、ホストPCからUSBデバイスモードで接続するrpibootなどが使われます。手作業で1台書けることと、製造ラインで同じ結果を再現できることは別なので、シリアル番号、検査、ログ保存まで含めて工程を設計します。
現場コラム：「基板はできたがLinuxが起動しない」
SoMを採用しても、自社キャリアの構成をLinuxへ伝える仕事は残ります。ブートローダーとDevice Treeは、使用するUART、ストレージ、Ethernet PHY、GPIO、電源制御などを知らなければなりません。
ハードウェア設計とBSPを別々に進めると、「基板完成後にDevice Treeの情報が足りない」と分かることがあります。設計初期から、回路信号名、Linux上のデバイス名、Device Treeノード、評価方法を対応づけておくと、立ち上げが楽になります。
ここが本シリーズ第2部、ブートとDevice Treeの主戦場です。
候補SoMの資料で先に見るところ
候補SoMの製品ページを開き、次の4点を探してみてください。
- データシートとキャリア設計ガイド
- 生産継続期間と変更通知の方針
- BSPのソースと更新履歴
- eMMC・ブートローダーの書き込み／復旧手順
見つからない項目は、量産前にベンダーへ確認すべき項目です。
まとめと次回（第1部完）
- SoM／COM方式は、演算の中核と製品固有のキャリアを分ける構成
- 高難度部分を減らせる一方、高速I/O、熱、量産書き込み、BSP評価は残る
- SBC直載せ／SoM／フル自社設計は、数量だけでなく開発・供給・保守を含めて選ぶ
これで第1部「ボードの地図」は完成です。次回からは第2部として、電源ONからアプリが動くまでのブートへ潜ります。まずC-5で全体の見取り図を作ります。