Linux SBCは、組み込み製品の開発でかなり便利な選択肢です。評価ボードを用意して、イメージを書き込み、EthernetをつないでSSHで入る。簡単なサービスならその日のうちに動かせます。試作の段階では、このスピードは大きな価値があります。アプリケーション担当者は早く動作確認ができ、顧客にも実機に近いデモを見せられます。
ただし、Linux SBCをそのまま量産製品の中に入れられるかというと、話は別です。机の上で動いたボードが、工場の制御盤、屋外設備、店舗端末、医療カート、IoTゲートウェイ、スマートディスプレイの中で同じように安定するとは限りません。製品化に近づくほど、CPU性能よりも、電源、熱、ストレージ、BSP、インターフェース、更新方法、製造検査のほうが問題になりやすいです。
この記事では、Linux SBCを組み込み製品に使うときに、エンジニアとして実際に見ておきたいポイントを整理します。カタログスペックの比較というより、試作から量産へ進める前の確認メモに近い内容です。
最初に見るべきものはCPUではない
Linux SBCを選ぶとき、最初にCPUの型番、コア数、クロック、メモリ容量を比較したくなります。もちろん性能は重要です。画像処理、AI推論、大量の通信処理、ブラウザUIなどがあるなら、CPUやGPUの余裕は必要です。
しかし、多くの組み込み製品では、CPUが最初のリスクになるとは限りません。むしろ、必要なインターフェースが足りない、電源入力が製品環境に合わない、熱が逃げない、ストレージが長期間の書き込みに耐えない、BSPの品質が十分でない、といった問題のほうが後から効いてきます。
ボードを選ぶ前に、まず製品の使われ方を確認したほうがよいです。
- 製品は屋内で使われるのか、屋外で使われるのか
- 電源は5V、12V、24V、または広い入力範囲が必要なのか
- ディスプレイやタッチパネルが必要なのか
- 現場機器とはRS485、CAN、USB、Ethernetのどれで接続するのか
- 設置後に作業者が簡単に触れる場所にあるのか
- ネットワークが切れたとき、ローカル処理を続ける必要があるのか
- 同じハードウェアを何年くらい供給する必要があるのか
これらの答えが曖昧なままボードを決めると、後でカスタム基板、ケーブル、筐体、ソフトウェア更新方式まで見直すことになります。Linux SBCは便利ですが、製品要求の代わりにはなりません。
Linux SBCは部品ではなく、システムの一部として見る
Linux SBCを単独のボードとして見ると、HDMI、USB、Ethernet、GPIO、カメラ、Wi-Fiなどが載っていて、かなり完成されたものに見えます。しかし製品の中では、その周囲に電源基板、筐体、表示パネル、アンテナ、センサー、リレー、端子台、ケーブルハーネス、放熱部材、製造治具が存在します。
つまり、SBCそのものよりも、製品全体として成立するかが重要です。開発ボードではUSBコネクタが使いやすい位置にあっても、最終製品では背面の防水コネクタに引き出す必要があるかもしれません。HDMIで評価していた画面が、量産ではLVDSやMIPI DSIになることもあります。5V入力で動いていたボードを、24V産業用電源から動かす必要が出ることもあります。
| 確認項目 | 見るべき内容 | 後で問題になりやすい点 |
|---|---|---|
| 電源 | 入力電圧、突入電流、瞬断、逆接、サージ | 現場電源で起動しない、再起動を繰り返す |
| 熱 | 最終筐体、周囲温度、無線モジュール、CPU負荷 | 机上では安定しても筐体内で熱暴走する |
| BSP | kernel、bootloader、device tree、driver | 特定のI/Oや表示が長時間動作で不安定になる |
| ストレージ | eMMC、SD、NVMe、ログ量、書き込み頻度 | ログ肥大化、ファイル破損、寿命不足 |
| 製造検査 | 書き込み、MAC、シリアル番号、I/O検査 | 手作業が増え、検査時間と不良流出が増える |
BSPは「起動した」だけでは足りない
Linux SBCでよくある誤解は、OSが起動すればBSPはほぼ終わり、という考えです。実際には、起動は最初の確認にすぎません。量産品で必要なのは、周辺機能が安定して動き、異常状態から戻り、長期間の運用に耐えることです。
例えばEthernetが一度リンクアップするだけでは不十分です。ケーブルを抜き差ししたとき、ネットワークが一時的に落ちたとき、DHCPが遅れたとき、再起動を100回繰り返したときにも問題がないかを見る必要があります。Wi-FiやLTEモジュールも同じです。電波が弱い場所、基地局切り替え、SIM認識、モデムリセット、ソフトウェアからの復旧手順まで確認したほうがよいです。
ディスプレイ製品なら、解像度、タイミング、タッチ座標、バックライト制御、スリープ復帰後の表示を確認します。産業用ゲートウェイなら、RS485、CAN、GPIO、watchdog、RTC、ストレージマウント、電源断後の起動を確認します。
私なら、最低でも次のような観点でBSPを見ます。
1. 電源投入からアプリ起動までの時間
2. bootloaderの設定と復旧手段
3. device treeと実際の配線の一致
4. Ethernet、Wi-Fi、LTEの再接続動作
5. watchdogによる復旧
6. GPIO、UART、I2C、SPIなどの割り当て
7. display、touch、camera、audioの安定性
8. sudden power loss後のファイルシステム状態
9. kernel更新時の手順
10. 量産イメージの再現性試作用BSPと量産用BSPは別物だと考えたほうが安全です。試作用は「機能が動くこと」を見せます。量産用は「悪い条件でも壊れにくいこと」を確認します。
ストレージの書き込み量は早めに見る
Linux製品では、ストレージ問題が開発後半や出荷後に出ることがあります。開発中はログを多めに出し、SDカードで気軽に評価し、SQLiteやローカルDBへ頻繁に書き込むことがあります。短期間なら問題が見えません。
しかし製品は数年動き続けることがあります。ネットワークが切れたらデータをローカルに蓄積します。ログが肥大化すればルートファイルシステムを圧迫します。頻繁な同期書き込みはeMMCやSDカードの寿命に影響します。電源断のタイミングが悪ければ、設定ファイルやDBが壊れることもあります。
そのため、Linux SBCを製品に使うなら、書き込みポリシーを早めに決めるべきです。どのディレクトリが書き込み可能か、ログはどのサイズでローテーションするか、デバッグログは量産で無効になるか、設定保存はどのタイミングで行うか、データベースはどの程度の頻度でflushするかを確認します。
SDカードは開発では便利ですが、量産品では慎重に扱ったほうがよいです。交換できる構造ならまだしも、筐体内部に入っていて現場交換が難しい場合は、eMMCや産業用グレードのストレージを検討する価値があります。
電源断は例外ではなく通常イベント
組み込み製品では、電源がきれいに落ちるとは限りません。作業者が電源を抜く、ブレーカーが落ちる、バッテリー電圧が下がる、制御盤の電源が一括で切られる。こうしたことは普通に起こります。
Linux SBCは、一般的なPCのように常に正常シャットダウンできる前提で設計すると危険です。突然の電源断に対して、ファイルシステム、設定ファイル、更新処理、ログ書き込みがどうなるかを確認しておく必要があります。
特にソフトウェア更新中の電源断は重要です。更新に失敗して起動不能になると、現場に行って復旧しなければならない可能性があります。遠隔地に設置される製品では、これは大きなコストです。
可能であれば、A/B rootfs、rollback、recovery partition、署名付き更新を検討します。製品価格や用途によっては簡易的な方式で十分な場合もありますが、失敗時の戻し方だけは設計段階で決めておくべきです。
筐体内の熱は評価ボード単体では分からない
Linux SBCは、机の上で動かすと問題なく見えることが多いです。空気が流れ、周囲に熱源がなく、ケーブルも自由に配置できます。しかし製品では、プラスチック筐体、金属ケース、ディスプレイ裏、密閉ボックス、制御盤内など、条件が変わります。
CPU、PMIC、Ethernet PHY、Wi-Fiモジュール、LTEモジュール、eMMC、電源ICは熱を持ちます。特に無線通信やディスプレイがある製品では、負荷のかけ方によって温度が大きく変わります。
熱評価は、できるだけ最終筐体に近い状態で行うべきです。実際の入力電圧、実際のケーブル、実際のアプリケーション負荷、想定する周囲温度を使います。Linux側でCPU governorやthermal throttlingを設定できますが、放熱経路が弱い場合、ソフトだけで解決するのは難しいです。
熱でCPUがスロットリングしても問題ない製品もあります。一方で、リアルタイムに近いデータ処理や映像処理を行う製品では、性能低下が機能問題になります。温度だけでなく、温度上昇時の処理能力も見る必要があります。
インターフェース定義は曖昧にしない
「シリアル通信が必要」「GPIOが必要」「画面をつなぐ」といった書き方では、量産設計には足りません。RS232なのかRS485なのか、絶縁が必要なのか、端子台なのかコネクタなのか、ケーブル長はどれくらいか、終端抵抗をどうするかで回路も筐体も変わります。
Linux側のデバイス名も意外と重要です。複数のUSBシリアルやUARTを使う場合、起動順や接続順でデバイス名が変わると、アプリケーションが間違ったポートを開くことがあります。udev rulesやdevice tree aliasなどで安定した名前を決めておくと、後のトラブルを減らせます。
インターフェースごとに、少なくとも次を確認します。
- 電気仕様
- コネクタ形状
- 外部に露出するかどうか
- ESDやサージ対策
- 絶縁の必要性
- Linux上のデバイス名
- 製造検査での確認方法
- 現場での診断方法
標準SBCで足りない場合、カスタムキャリアボードや完全カスタムSBCを検討します。標準ボードでソフトウェアを先に進め、量産では製品に合わせたインターフェースにする流れはよくあります。Avontekのような会社は、こうしたLinux SBC開発、BSP対応、カスタムボード、製造面の調整をまとめて扱う場面で関わることがあります。詳しくはAvontekを確認できます。
セキュリティは出荷イメージから始まる
Linuxは便利ですが、設定を間違えると不要なリスクも増えます。開発中はSSHを開け、rootログインを有効にし、固定パスワードを使い、デバッグサービスを動かすことがあります。開発中なら仕方ない場面もありますが、そのまま出荷してはいけません。
量産イメージでは、不要なサービスを止め、デフォルトパスワードを削除し、リモートアクセスを制限します。更新ファイルには署名を付け、デバイスごとの認証情報を分け、ログに秘密情報が残らないようにします。
顧客ネットワークに接続する製品では、開いているポート、外部接続先、通信プロトコルを説明できる必要があります。工場や医療、商業施設では、IT部門から確認されることも多いです。ここで答えられないと、製品自体は完成していても導入が止まることがあります。
製造検査は後付けにしない
Linux SBC製品は、アプリが動けば終わりではありません。量産では、イメージを書き込み、MACアドレスやシリアル番号を設定し、I/Oを検査し、結果を記録し、出荷状態に整える必要があります。
製造検査を後から考えると、治具でアクセスできない信号、手作業が多い書き込み手順、検査できないI/Oが出てきます。これは製造時間と不良流出の原因になります。
典型的な検査フローは次のようになります。
1. bootloaderとLinux imageを書き込む
2. serial number、MAC address、製品設定を書き込む
3. RAMとstorageを確認する
4. Ethernet通信を確認する
5. Wi-Fi、Bluetooth、LTE moduleを確認する
6. RS485、RS232、CAN、GPIO、relayを確認する
7. display、touch、camera、audioを確認する
8. watchdogとreboot動作を確認する
9. 検査結果をserial numberと紐づけて保存する
10. factory modeを閉じ、出荷用設定に切り替える製品の台数が少ない場合は簡易的な検査でもよいかもしれません。ただし、同じ手順で繰り返せることが重要です。作業者の経験に依存する検査は、台数が増えると問題になります。
標準SBC、キャリアボード、完全カスタムの選び方
Linux SBCを製品に使う方法はいくつかあります。標準SBCをそのまま使う方法、compute moduleとカスタムキャリアボードを使う方法、完全にカスタムSBCを作る方法です。
標準SBCは開発が早いです。試作、社内設備、少量生産、筐体自由度が高い製品では十分な場合があります。初期コストも低く、ソフトウェア開発をすぐに始められます。
カスタムキャリアボードは、プロセッサ部分のリスクを抑えつつ、電源、コネクタ、I/O、取り付け穴、製造検査ポイントを製品に合わせたい場合に向いています。Linux SBC開発ではよく使われる現実的な中間案です。
完全カスタムSBCは、筐体制約、コスト、長期供給、特殊インターフェース、量産性を重視する場合に向いています。初期開発は重くなりますが、不要な部品を減らし、製品に最適化できます。
| 方式 | 向いているケース | 注意点 |
|---|---|---|
| 標準Linux SBC | 試作、少量生産、社内用装置 | 供給継続性、筐体適合、不要I/O |
| カスタムキャリアボード | compute moduleを使いながら製品I/Oを合わせたい場合 | モジュール供給、コネクタ設計、BSP調整 |
| 完全カスタムSBC | 量産、特殊形状、コスト最適化、長期供給 | 初期開発費、検証期間、部品選定 |
製品化前の最後の確認
Linux SBCを量産製品に採用する前に、私は次の項目を確認します。
- 必要なインターフェースが電気的にも機械的にも定義されている
- BSPが初回起動だけでなく、異常系でも確認されている
- 最終筐体に近い状態で熱評価をしている
- 電源断、瞬断、再起動の動作を確認している
- ストレージの書き込み量とログ管理が決まっている
- リモート更新の失敗時に戻せる手段がある
- 出荷イメージのセキュリティ設定が整理されている
- 製造検査の手順が現実的で、結果を記録できる
- 主要部品やボードの供給期間を確認している
- 現場で診断するためのログや状態表示がある
どれも特別な話ではありません。しかし、これらを後回しにすると、製品の後半で大きな修正になります。Linux SBCは開発を速くしてくれますが、製品化の確認作業まで省略できるわけではありません。
まとめ
Linux SBCは、組み込み製品にとって強力なベースになります。ネットワーク、ストレージ、UI、プロトコル変換、リモート保守など、多くの機能を短期間で実装できます。特に、ソフトウェアを早く動かして検証したいプロジェクトでは大きな助けになります。
一方で、量産製品として見るなら、ボード単体の便利さだけでは判断できません。電源、熱、BSP、ストレージ、インターフェース、更新、セキュリティ、製造検査を含めて、製品全体で評価する必要があります。
良いLinux SBC製品は、スペックが派手なものとは限りません。現場で安定して起動し、必要なI/Oが確実に動き、異常時に復旧でき、遠隔更新に耐え、製造時に再現性を持って検査できるものです。
組み込み製品では、試作が動くことと、現場で長く動くことの間に大きな差があります。その差を埋めるのが、地味ですが重要なエンジニアリング作業です。Linux SBCをうまく使うには、便利な開発ボードとして見るだけでなく、製品の一部として最後まで面倒を見る姿勢が必要だと思います。