Mi Smart Camera（ミヤカメラ）技術実装の完全解説

ハードウェア・ソフトウェア・クラウドの3観点から、工業レベルのMi Smart Cameraの作り方を解説する。屋内PTZカメラを軸に、デュアルカメラなど形態の違いも説明する。

2024年11月10日テクノロジー , 音声/映像 6 分で読めます

本稿では、ハードウェア設計、ソフトウェアアーキテクチャ、クラウドサービスの3つの観点から、工業レベルのMi Smart Camera（ミヤスマートカメラ）製品をどのように作るかを体系的に整理する。主に屋内PTZカメラを軸に、銃球一体型（デュアルカメラ）などの形態の違いも併せて解説する。

本稿で扱う技術スタックについては、以前のブログ記事でそれぞれ特集しているので、あわせて参照されたい：

音声/映像の基礎とデジタル表現 — サンプリング、符号化、色空間などの基本概念
P2P 技術の紹介 — NAT越え、ホールパンチングの原理
HLS とクラウドストレージ — ストリーミングのセグメント保存と再生
Matter プロトコルの紹介 — Mi IoT SPEC との比較

                            ┌─────────────┐
                            │   レンズモジュール   │
                            │ (Lens+CMOS) │
                            └──────┬──────┘
                                   │ MIPI CSI
┌─────────┐    I2S     ┌──────────┴──────────┐     SDIO/USB     ┌──────────┐
│ マイク   │───────────►│                      │◄───────────────►│  Wi-Fi   │
│ (MIC)   │            │     主制御 SoC       │                 │  モジュール│
└─────────┘            │  (SigmaStar/Ingenic) │                 └──────────┘
                       │                      │     SPI/eMMC
┌─────────┐    PWM     │  CPU + ISP + NPU    │◄───────────────►┌──────────┐
│ スピーカー│◄──────────│  + ビデオエンコーダ   │                 │  Flash   │
│(Speaker) │    DAC    │                      │                 │(NOR/NAND)│
└─────────┘            └──┬───┬───┬───┬──────┘                 └──────────┘
                          │   │   │   │
                    GPIO  │   │   │   │ DDR
              ┌───────────┘   │   │   └────────┐
              │               │   │            │
        ┌─────┴─────┐   ┌────┴───┴──┐    ┌────┴────┐
        │  赤外線LED  │   │ PTZモーター │    │  DDR    │
        │  IR LED   │   │ (PTZ)     │    │  メモリ  │
        │  + IR-CUT │   │ ステッピング│    │         │
        └───────────┘   └───────────┘    └─────────┘

主制御チップはカメラの中核であり、1つのチップにCPU、ISP（画像信号プロセッサ）、ビデオエンコードエンジン、NPU（AI推論）などのモジュールを集積する必要がある。

一般的なソリューション：

チップ	メーカー	CPU	NPU演算能力	映像能力	適用シーン
SSC337DE	SigmaStar	Cortex-A7 デュアルコア	0.5~1 TOPS	3MP@30fps H.265	低中端PTZカメラ
SSC377	SigmaStar	Cortex-A7 デュアルコア	~2 TOPS	5MP@30fps H.265	中高端/デュアルカメラ
T40XP	Ingenic	MIPS XBurst2 デュアルコア	3.2 TOPS	5MP@30fps H.265/H.264	高端/AI強化型
T31	Ingenic	MIPS XBurst シングルコア	限定的	3MP@25fps	低コスト/低消費電力

選定のポイント：

ISPの品質：画質（ノイズ低減、ワイドダイナミックレンジ、3D-DNR）に直結する
エンコーダ能力：複数ストリームの同時エンコード対応が必要（メインストリーム + サブストリーム + AIフレーム）
NPU演算能力：実行できるAIモデルの数を決定する（人型+顔認識には ≥1 TOPS が必要）
メモリ帯域幅：ビデオ+AI+ISPの同時動作には高い帯域幅が要求される

タイプ	容量	説明
DDR2	64MB	低端機種、基本映像のみに十分
DDR3/DDR3L	128~256MB	主流ソリューション、映像+AI+P2P対応
LPDDR4	256~512MB	高端デュアルカメラまたはマルチタスクシーン

メモリの用途配分（128MBの場合）：

Linuxカーネル + ユーザ空間：~30MB
ビデオエンコードバッファ（メイン/サブストリーム）：~40MB
ISP画像パイプラインバッファ：~20MB
AI推論テンソルバッファ：~20MB
P2P/ネットワークバッファ：~10MB
予備/フラグメント：~8MB

タイプ	容量	代表的な用途
SPI NOR Flash	8~32MB	bootloader + kernel + rootfs（軽量システム）の格納
SPI NAND Flash	128~256MB	完全なシステム + モデルファイル + 録画キャッシュの格納
eMMC	512MB~8GB	高端ソリューション、ローカル録画対応
TFカードスロット	ユーザー着脱可能	ローカル録画保存（最大256GB）

パーティション設計（SPI NAND 128MB 代表的な構成）：

┌──────────────────────────────────────────────────────┐
│ boot (1MB) │ kernel (4MB) │ rootfs (40MB) │ data (80MB) │
│  U-Boot    │   uImage     │  squashfs     │  jffs2/ubifs │
└──────────────────────────────────────────────────────┘

rootfs：読み取り専用のsquashfs。停電によるシステム破損を防止する。
data：書き込み可能パーティション。設定ファイル、AIモデル、ログなどを格納。
A/Bデュアルパーティション構成によりOTAでの文鎮化防止。

型番	メーカー	解像度	画素サイズ	適用シーン
SC3336	SmartSens	3MP (2304x1296)	2.5μm	主流家庭用
SC5235	SmartSens	5MP (2592x1944)	2.0μm	高精細ソリューション
IMX307	Sony	2MP (1920x1080)	2.9μm	星光級ナイトビジョン
OS04A10	OmniVision	4MP (2560x1440)	2.0μm	中高端

選定の考慮点：

画素サイズ：大きいほど入射光量が多く、夜間撮影の品質が向上する
感度：低照度下でのノイズを決定する
シャッターモード：Rolling shutter（低コスト）vs Global shutter（動体撮影時に歪みが生じない）
インターフェース：MIPI CSI-2、2-lane または 4-lane
消費電力：製品全体の熱設計に影響する

パラメータ	代表値	説明
焦点距離	3.6mm / 2.8mm	焦点距離が短いほど画角が広い
絞り	F2.0 / F1.6	絞りが大きいほど入射光量が多く、夜間撮影に有利
画角	水平 110°~130°	家庭用は一般的に ≥110° が求められる
IR-CUT	デュアルフィルター切替	昼間は赤外光をカットして自然な色を再現し、夜間はフィルターを外して赤外感光を強化
フォーカス	固定焦点	家庭用PTZカメラは一般的に固定焦点でコスト削減

レンズマウント仕様：一般的にM12（Sマウント）を採用。ネジ式で焦点調整後、接着剤で固定する。

ソリューション	周波数帯	説明
RTL8189FTV	2.4GHz	低コストSDIOインターフェース、802.11 b/g/n対応
RTL8733BU	2.4G + 5G + BLE	デュアルバンド+Bluetooth、USBインターフェース、Bluetooth対応ネットワーク設定
SSW101B	2.4GHz	SigmaStar組み合わせソリューション、SDIO

選定のポイント：

スループット：1080P@30fps H.265メインストリームは約2~4Mbps、安定したWi-Fi帯域幅が必要
耐干渉性：家庭の2.4G帯域は混雑しているため、MIMOまたは5G帯域対応が必要
消費電力：製品全体の発熱に影響する
Bluetoothネットワーク設定：デュアルモードチップでBLEネットワーク設定が可能、ユーザー体験が向上する

PTZカメラの機械構造により、水平回転（Pan）と垂直チルト（Tilt）を実現する：

パラメータ	水平（Pan）	垂直（Tilt）
モータータイプ	ステッピングモーター	ステッピングモーター
回転範囲	360°	90°~120°
ステップ角	通常 1/16 マイクロステップ	同左
減速比	ギア減速	ギア減速
原点復帰方式	フォトカプラ/ホールセンサー	同左
ドライバIC	MS41929など	同左

制御ロジック：

電源投入時に原点センサーによりゼロ位置を決定する
Appから回転角度コマンドを送信し、ステッピングパルス数に変換する
プリセット位置、クルーズ、追跡などの高度な機能に対応する
ノイズ最適化が必要（マイクロステップ駆動 + 減速比設計）

銃球一体型の違い：デュアルカメラ形態は通常、固定広角レンズ1つ + 可変焦点PTZレンズ1つで構成され、両者が連携して「全体追跡＋クローズアップ撮影」を実現する。

昼間モード：                        夜間モード：
┌─────────┐                    ┌─────────┐
│  レンズ   │                    │  レンズ   │
│  ↓      │                    │  ↓      │
│ IR-CUT  │ ← フィルターでIR遮断 │ IR-CUT  │ ← フィルター退避
│ (遮断)  │                    │ (退避)  │
│  ↓      │                    │  ↓      │
│ CMOS    │                    │ CMOS    │ ← 850nm/940nm赤外光を受光
└─────────┘                    └─────────┘
                                   ↑
                               IR LED 補光

850nm赤外線LED：わずかな赤色光があり、補光距離が長い
940nm赤外線LED：肉眼では完全に見えず、隠蔽性が要求されるシーンに適する
IR-CUT切替器：ISPが環境照度に応じて自動制御で切り替える

コンポーネント	仕様	説明
マイク	エレクトレット/MEMS	拾音、泣き声検出、双方向通話に使用
スピーカー	8Ω 1W~2W	通話再生、アラームサイレンに使用
オーディオCodec	主制御内蔵 / 外付けES8388など	ADC（マイク→デジタル）+ DAC（デジタル→スピーカー）
エコーキャンセル	ソフトウェアAECアルゴリズム	通話時にスピーカー音がマイクに回り込むのを抑制

通話経路：App音声 → P2P → デバイスデコード → DAC → スピーカー；デバイスMIC → ADC → AEC → エンコード → P2P → App

ソリューション	入力	説明
DC 5V/2A	Micro-USB / USB-C	屋内PTZカメラ標準電源
DC 12V/1A	DC丸型コネクタ	屋外銃型カメラ、PoE給電
バッテリー給電	18650リチウムイオン電池パック	低消費電力バッテリー機、PIR起動

電源経路：

USB 5V → DCDC (3.3V/1.8V/1.2V) → SoC / DDR / Wi-Fi / Motor / IR LED
              └→ LDO（アナログ回路へ：CMOS sensor, Audio Codec）

注意事項：

モーター起動時の瞬間電流が大きいため、余裕を持った設計が必要
IR LEDは大電流 → 独立したMOS FETスイッチで制御
デジタルGNDとアナログGNDを分離し、オーディオと画像への干渉を回避する

要素	説明
材質	ABS / PC+ABS（難燃等級V0）
放熱	主制御チップに放熱グリス+ヒートシンク、または筐体自体で放熱
防塵	レンズパネルを密閉し、ほこりの付着を防止
防水（屋外）	IP65/IP66等級、Oリングによる密閉
アンテナ配置	Wi-Fiアンテナをモーターや金属部品から遠ざけ、遮蔽を防止
TFカードスロット	隠しスロット + イジェクト機構
インジケーター	ステータスLED（青/橙）、コマンドで消灯可能

┌─────────────────────────────────────────────────────────────┐
│                   App 層 / クラウド                           │
│     Mi Home App  │    Xiaomi Cloud Storage  │  IoT プラットフォーム  │
└────────────┬────────┴────────┬────────┴────────┬────────────┘
             │ P2P (MISS)      │ HTTPS           │ MQTT
             │                 │                 │
┌────────────┴─────────────────┴─────────────────┴────────────┐
│                     デバイス側ソフトウェアスタック                │
├─────────────────────────────────────────────────────────────┤
│  ┌──────────┐  ┌──────────┐  ┌─────────┐  ┌─────────────┐ │
│  │ MISS P2P │  │ クラウド  │  │ IoT     │  │  OTA Client │ │
│  │ SDK      │  │ アップロード│  │ SPEC    │  │             │ │
│  │          │  │ モジュール │  │         │  │             │ │
│  └────┬─────┘  └────┬─────┘  └────┬────┘  └──────┬──────┘ │
│       │              │             │               │        │
│  ┌────┴──────────────┴─────────────┴───────────────┴──────┐ │
│  │                  ビジネスロジック層 (C/C++)                │ │
│  │  音声/映像収集 │ エンコード管理 │ 保存管理 │ AI スケジューリング │ PTZ 制御   │ │
│  └────────────────────────┬────────────────────────────────┘ │
│                           │                                  │
│  ┌────────────────────────┴────────────────────────────────┐ │
│  │              ミドルウェア / HAL 層                         │ │
│  │  ISP ドライバ │ エンコーダ API │ Audio API │ GPIO │ Motor │ NPU │ │
│  └────────────────────────┬────────────────────────────────┘ │
│                           │                                  │
├───────────────────────────┴──────────────────────────────────┤
│                   Linux Kernel (4.9 / 5.x)                   │
│  V4L2 │ ALSA │ SPI │ I2C │ SDIO │ USB │ MTD │ NetFilter    │
├─────────────────────────────────────────────────────────────┤
│                    Bootloader (U-Boot)                        │
└─────────────────────────────────────────────────────────────┘

なぜLinuxを選ぶのか：

成熟して安定しており、ドライバが豊富
コミュニティのサポートが充実しており、チップメーカーがBSP（Board Support Package）を提供
マルチスレッド/マルチプロセスに対応し、カメラの複雑な処理に適する
オープンソースで、カスタマイズとトリミングが可能

Buildrootビルドシステム：

Buildrootは、軽量な組み込みLinuxルートファイルシステムを構築するために使用される。Yoctoよりも軽量でビルドが高速である。

# 代表的なビルド手順
$ make <board>_defconfig    # ボード設定をロード
$ make menuconfig           # カーネル/ユーザ空間パッケージを設定
$ make                      # コンパイルしてファームウェアを生成

# 成果物
output/images/
├── u-boot.bin              # Bootloader
├── uImage                  # Linux カーネル
├── rootfs.squashfs         # 読み取り専用ルートファイルシステム
└── userdata.ubifs          # 書き込み可能データパーティション

システムトリミングのポイント：

不要なカーネルモジュール（USB gadget、Bluetoothプロトコルスタックなど）を削除
完全なcoreutilsの代わりにBusyBoxを使用
Cライブラリにはmusl libcを選択（glibcより約2MB小さい）
kernel printkを無効にしてシリアル出力のオーバーヘッドを削減

電源投入 → BootROM → U-Boot → Kernel → Init → 業務プロセス
│               │          │        │       │
│ (~10ms)       │(~500ms)  │(~2s)   │(~1s)  │(~2s)
└───────────────┴──────────┴────────┴───────┴──────── 合計 ~6s で映像出力

高速起動の最適化手段：

U-Boot：不要なデバイス検出をスキップし、カーネルを直接ロード
Kernel：未使用ドライバを削除し、initスクリプトではなくinitramfsを使用
ユーザ空間：ISP + エンコーダを優先的に起動し、AI/P2Pモジュールは遅延ロード
目標：電源投入から最初のフレーム出力まで ≤3秒

ファームウェアの書き込みは工場の生産段階で行われる：

書き込み方式	説明	適用シーン
USB書き込み	PCがUSB経由でデバイスに接続し、チップメーカーの書き込みツールを使用	工場量産
SDカード書き込み	ファームウェアをTFカードに入れ、デバイス電源投入時に自動書き込み	小ロット/研究開発
UART書き込み	シリアルポート + TFTPでファームウェアをダウンロード	デバッグ/文鎮化復旧
ネットワーク書き込み	ネットワーク経由でファームウェアを一括配信	大規模生産ライン

量産書き込みフロー：

ファームウェア書き込み → デバイス固有情報(DID/MAC/Key)書き込み → 機能セルフチェック → ラベル貼付・入庫

各デバイスは出荷時に以下を書き込まれる：

DID（Device ID）：Mi Homeプラットフォームにおける一意のデバイス識別子
MACアドレス：Wi-Fiモジュールの物理アドレス
デバイスキー：Xiaomiクラウドとの安全な通信に使用

Xiaomiはカメラエコシステム向けに、包括的な開発キット MIKE（Mi IPC Kit Environment） を提供している。これは、チップレベルのアダプテーションから上位のビジネスAPIまでをカバーする完全なチェーンである：

                                              ┌─────────────────────────────┐
┌───────────────────────────────────────────┐ │                             │
│              MIKE 上位 API                 │ │                             │
│  (統一ビジネスインターフェース：AV、AI、保存、ネット設定など) │ │                             │
├───────────────────────────────────────────┤ │                             │
│               ミドルウェアモジュール          │ │      Tools ツールキット        │
│  ┌──────┐ ┌────┐ ┌─────┐ ┌────┐ ┌─────┐ │ │                             │
│  │ MISS │ │ OT │ │クラウド│ │ネット│ │録画  │ │ │  Emulator（デバイスシミュレータ） │
│  │(P2P) │ │サービス│ │保存  │ │設定 │ │     │ │ │  Monitor（実行時監視）          │
│  └──────┘ └────┘ └─────┘ └────┘ └─────┘ │ │  Auto Test（自動化テスト）        │
│  ┌─────┐ ┌──────┐ ┌─────┐ ┌───────────┐ │ │  Logger Debugger（ログデバッグ）│
│  │ OTA │ │ 再生  │ │コーデック│ │ローカルAI│NAS │ │ │                             │
│  └─────┘ └──────┘ └─────┘ └───────────┘ │ │  全層にわたり以下をサポート：      │
├───────────────────────────────────────────┤ │  - ビジネス層の機能シミュレーションとデバッグ │
│            チッププラットフォーム適応層 (HAL)   │ │  - ミドルウェアモジュールの独立テスト      │
│       SigmaStar │ Ingenic │ 他プラットフォーム    │ │  - プラットフォーム適応層の検証          │
└───────────────────────────────────────────┘ └─────────────────────────────┘

MIKEの各モジュールの役割：

モジュール	説明
MISS（P2P）	ストリーミング伝送SDK。デバイスとApp間の音声/映像/コマンドチャネルを担当
OTサービス	デバイスのネットワーク接続ハートビート、オンライン状態維持
クラウド保存	イベント録画のセグメント暗号化アップロード
ネットワーク設定	Wi-Fi APスキャンコード/BLEネットワーク設定フロー
録画	ローカルTFカード録画管理（連続/イベント録画）
OTA	ファームウェアアップデート（A/Bパーティション、差分アップデート）
再生	クラウド/ローカル録画のタイムライン再生
コーデック	音声/映像のエンコード/デコードラッパー（H.265/Opus）
ローカルAI	人型/顔/ペット/泣き声などのモデル推論スケジューリング
NAS保存	ローカルネットワーク上のNASデバイスへの映像保存（SMB/NFS）
チッププラットフォーム適応層	異なるSoCのISP/エンコーダ/NPU差異を隠蔽し、統一HALを提供
Tools	ビジネス層/ミドルウェア/プラットフォーム適応層にわたる開発デバッグツールセット：Emulator（PC側デバイスシミュレータ）、Monitor（実行状態監視）、Auto Test（自動化テストフレームワーク）、Logger Debugger（ログ取得と分析）

MIKEの設計により、ビジネス開発者はチップの差異を意識することなく、上位APIを通じて機能開発を完了できる。同時にToolsツールキットはPC上でのデバイス動作シミュレーションをサポートし、開発デバッグ効率を大幅に向上させる。

P2Pの基本原則（NATタイプ、UDPホールパンチング、STUN/TURN）については P2P技術の紹介を参照。ここではXiaomiカメラの具体的な実装に焦点を当てる。

MISS（MIoT Streaming SDK） はXiaomiが開発したP2Pストリーミング伝送SDKであり、C言語で実装され、クロスプラットフォーム（デバイス側Linux + App側iOS/Android）に対応する。MIKEスイートの中核となる通信モジュールである。

┌──────────────────────────────────────────┐
│             MISS SDK (上位インターフェース)   │
│  チャネル作成 │ データ送信 │ データ受信 │ イベントコールバック  │
├──────────────────────────────────────────┤
│            チャネル管理 / スケジューリング層    │
│   コネクション管理 │ 再接続戦略 │ トラフィック制御 │ QoS     │
├──────────────────────────────────────────┤
│            P2P 伝送層（プラグイン可能）        │
│  ┌────────┐  ┌────────┐  ┌────────────┐ │
│  │  TUTK  │  │  ShangYun │  │ Xiaomi自研P2P│ │
│  │(Kalay) │  │        │  │            │ │
│  └────────┘  └────────┘  └────────────┘ │
├──────────────────────────────────────────┤
│              ネットワーク層 (UDP/TCP)       │
└──────────────────────────────────────────┘

┌──────────┐         ┌──────────────┐         ┌──────────┐
│  カメラ   │         │  P2P サーバー  │         │  App     │
└─────┬────┘         └──────┬───────┘         └─────┬────┘
      │  1. 登録・オンライン      │                      │
      │──────────────────────►│                      │
      │                       │                      │
      │                       │   2. デバイスアドレス問合せ │
      │                       │◄─────────────────────│
      │                       │                      │
      │                       │   3. デバイスIP/ポートを返却│
      │                       │─────────────────────►│
      │                       │                      │
      │          4. NAT越え / P2P直接接続              │
      │◄════════════════════════════════════════════►│
      │                                              │
      │    5. P2Pが失敗した場合、中継サーバー経由 (Relay)  │
      │◄═══════════[ Relay Server ]═══════════════►│

MISS SDKは複数の論理チャネルを同一のP2P接続で多重化する：

チャネル	用途	特徴
ビデオチャネル	メイン/サブストリーム伝送	高帯域幅、フレーム欠落許容
オーディオチャネル	通話音声	低遅延優先
コマンドチャネル	制御命令（PTZ、スクリーンショットなど）	信頼性のある伝送
ファイルチャネル	録画再生/ダウンロード	信頼性のある伝送、レジューム機能対応
アラームチャネル	イベントプッシュ	低遅延

プラグイン可能な設計により：

TUTK（Kalay）：グローバルノードをカバー、海外での接続成功率が高い
ShangYun：国内ノードが高密度に配置され、低遅延
Xiaomi自研：制御性が高く、継続的に最適化
SDK層が自動的に最適なエンジンを選択し、ビジネス層に対して透過的

Mi Smart Cameraは2つのネットワーク設定モードに対応する：

┌───────────┐                              ┌───────────┐
│  Mi Home App│                              │   カメラ   │
└─────┬─────┘                              └─────┬─────┘
      │                                          │
      │  1. AppがQRコードを生成                     │
      │     (Wi-Fi SSID + Password + Tokenを含む) │
      │     スマホ画面に表示                        │
      │                                          │
      │                              2. カメラ電源投入│
      │                                 カメラがスマホの │
      │                                 QRコードをスキャン│
      │                                          │
      │         3. カメラがQRコードを解析、            │
      │            Wi-Fi認証情報を取得、              │
      │            ルーターに接続                     │
      │                                          │
      │  4. カメラがルーターに接続後、                  │
      │     ローカルネットワーク/クラウド経由でAppとハンドシェイク│
      │◄────────────────────────────────────────►│
      │                                          │
      │  5. デバイスをMi Homeアカウントにバインド      │
      │─────────────(クラウド)──────────────────►│

利点：追加のハードウェア（Bluetoothチップ）が不要で、カメラ自身の機能でネットワーク設定を完了できる。

1. AppがBLE経由でデバイスを発見
2. BLEチャネルでWi-Fi SSID + Passwordを送信
3. デバイスがWi-Fiに接続
4. クラウド経由でバインド完了

利点：カメラの映像に依存せず、暗所や遮蔽されたシーンでもネットワーク設定が可能。デュアルモードWi-Fi+BLEチップのソリューションに適する。

MIoT SPECのデータモデル（Device → Service → Property/Action/Event）とMatterプロトコルのClusterモデルは設計思想が非常に似ている。詳細な比較については Matter プロトコルの紹介を参照。

カメラはMi Homeデバイスとして、MIoT SPECプロトコルで定義されたService/Property/Action/Eventを実装する必要がある。

カメラの代表的なSPEC定義：

Device: camera
├── Service: camera-control
│   ├── Property: on (bool)              — カメラのON/OFF
│   ├── Property: night-shot (enum)      — ナイトモード (自動/ON/OFF)
│   ├── Property: watermark (bool)       — ウォーターマークON/OFF
│   ├── Action: start-recording          — 録画開始
│   └── Action: stop-recording           — 録画停止
│
├── Service: ptz-control
│   ├── Property: pan-position (int)     — 水平角度
│   ├── Property: tilt-position (int)    — 垂直角度
│   ├── Action: rotate (direction, speed)— 回転
│   └── Action: go-to-preset (id)       — プリセット位置へ移動
│
├── Service: motion-detection
│   ├── Property: sensitivity (enum)     — 感度 (低/中/高)
│   ├── Property: detection-area (struct)— 検出エリア
│   └── Event: motion-detected           — 動体検知イベント
│
├── Service: ai-detection
│   ├── Property: human-detect-on (bool) — 人型検出ON/OFF
│   ├── Property: face-detect-on (bool)  — 顔検出ON/OFF
│   ├── Property: pet-detect-on (bool)   — ペット検出ON/OFF
│   ├── Property: cry-detect-on (bool)   — 泣き声検出ON/OFF
│   ├── Event: human-detected            — 人型検出イベント
│   ├── Event: face-detected             — 顔検出イベント
│   ├── Event: pet-detected              — ペット検出イベント
│   └── Event: cry-detected              — 泣き声検出イベント
│
├── Service: storage
│   ├── Property: sd-card-status (enum)  — TFカードステータス
│   ├── Property: cloud-storage-on (bool)— クラウド保存ON/OFF
│   └── Action: format-sd-card           — TFカードフォーマット
│
└── Service: indicator-light
    └── Property: on (bool)              — インジケーターON/OFF

デバイスは MQTT プロトコルを介してXiaomi IoTクラウドとの長期間接続を維持し、プロパティ変更やイベントを報告する。Appから送信される制御コマンドもMQTT → デバイスの経路で伝達される。

クラウドストレージのビデオセグメント化と再生メカニズムはHLSプロトコルの設計思想（ビデオを小さなセグメントに分割 + インデックスリスト）と類似している。詳細は HLSとストリーミング保存を参照。

Xiaomiクラウドストレージサービスは、カメラの録画セグメントをクラウドにアップロードし、ユーザーはAppで再生できる。

カメラ側：
  ISP → YUV420 → エンコーダ(H.265, 20fps) → リングバッファ → イベントトリガー → セグメント(10秒/片) → HTTPS アップロード

アップロードフロー：
  1. イベントトリガー（動体検知/AI検出/ユーザー手動）
  2. リングバッファからイベント前後のビデオセグメントを切り出し
  3. セグメントを暗号化（AES-128）
  4. HTTPS POSTでXiaomiクラウドストレージにアップロード
  5. サーバーがインデックス情報を返却、デバイスがイベントメタデータを報告

再生フロー：
  Appがタイムラインを要求 → クラウドがビデオセグメントリストを返却 → AppがHTTPSでストリーム受信 → 復号・再生

リングバッファ：メモリに最新10~30秒のビデオを保持し、イベント発生時に過去までさかのぼれるようにする
エンドツーエンド暗号化：ビデオはデバイス側で暗号化され、クラウド側では復号不可。ユーザー側のキーで復号
レジューム機能：ネットワーク変動時に未完了のセグメントを自動再送
トラフィック制御：帯域幅に応じてアップロードビットレートを動的調整（サブストリーム/メインストリーム）

アルゴリズム	入力	推論ハードウェア	フレームレート	説明
人型検出	ビデオフレーム（サブストリーム 640x360）	NPU	10~15fps	画面内に人がいるか判定
顔認識	人型領域の切り抜き画像	NPU	必要に応じてトリガー	他人/家族の識別
ペット検出	ビデオフレーム	NPU	10~15fps	猫/犬の検出
泣き声検出	オーディオフレーム (16kHz PCM)	CPU/DSP	リアルタイム	乳児の泣き声認識
動体検知	フレーム差法	CPU	メインストリームフレームレート	計算量の少ない基本検出

モデル訓練（クラウドGPU）
    │
    ▼ モデル量子化/変換（浮動小数点→INT8）
    │
    ▼ チップメーカーツールチェーン変換（ONNX → チップ固有形式）
    │  - SigmaStar: IPU Toolkit → .img model
    │  - Ingenic: Magik → .bin model
    │
    ▼ モデルファイルをファームウェア data パーティションにパッケージング
    │
    ▼ デバイス側NPU Runtimeがモデルをロードして推論

ISP出力 YUVフレーム
    │
    ├──► メインストリームエンコード (1080P/1296P) ──► P2P/録画
    │
    └──► サブストリーム (360P/VGA) ──► AI前処理 (Resize/Norm)
                                    │
                                    ▼
                              NPU推論 (人型/ペット)
                                    │
                                    ▼
                              後処理 (NMS/閾値フィルタリング)
                                    │
                                    ├──► 目標検出 → イベント報告 + クラウド保存
                                    ├──► 顔領域 → 切り抜き → 顔認識モデル
                                    └──► 目標なし → 次のフレームを待機

音声AI（泣き声検出） はビデオパイプラインとは独立して、オーディオスレッド内で動作する：

MIC → ADC → 16kHz PCM → スライディングウィンドウフレーム化 → 特徴抽出(MFCC) → 分類モデル → 泣き声/非泣き声

OTAはスマートデバイスの継続的な改善の基盤であり、アップデートプロセスの安全性と信頼性を確保する必要がある。

┌───────────┐         ┌──────────────┐         ┌───────────┐
│ Xiaomi OTA │         │    カメラ     │         │ Mi Home App│
│  サーバー   │         │              │         │           │
└─────┬─────┘         └──────┬───────┘         └─────┬─────┘
      │                      │                       │
      │  1. アップデート確認（定期/プッシュ）               │
      │◄─────────────────────│                       │
      │                      │                       │
      │  2. 新バージョン情報 + ダウンロードURLを返却       │
      │─────────────────────►│                       │
      │                      │                       │
      │  3. ファームウェアパッケージをダウンロード (HTTPS)│
      │─────────────────────►│                       │
      │                      │                       │
      │               4. ファームウェア署名検証 (RSA/ECDSA)│
      │                      │                       │
      │               5. 予備パーティションに書き込み (A/B)│
      │                      │                       │
      │               6. 起動パーティション切替、再起動     │
      │                      │                       │
      │               7. 起動成功 → 新バージョンを報告    │
      │◄─────────────────────│                       │
      │                      │                       │
      │                      │  8. Appにアップデート完了表示│
      │                      │──────────────────────►│

仕組み	説明
A/Bデュアルパーティション	新ファームウェアを予備パーティションに書き込み、検証成功後にのみ切替
Watchdog	起動後正常に動作しない場合、ハードウェアウォッチドッグがロールバックをトリガー
起動カウンター	連続起動失敗N回で自動的に旧パーティションにフォールバック
ファームウェア署名	RSA/ECDSA署名検証により改ざんを防止
停電復旧	書き込み中の停電は現在稼働中のパーティションに影響しない

帯域幅とアップデート時間を節約するため、差分アップデート（delta OTA）に対応：

サーバー側で新旧ファームウェアのbsdiffを実行し、差分パッケージを生成（通常はフルパッケージの10%~30%）
デバイス側は差分パッケージを受信後、現在のパーティションデータと組み合わせて完全な新ファームウェアをパッチ
ハッシュ一致を検証してから書き込み

音声/映像のデジタル化の基本概念（サンプリング、量子化、符号化、色空間）については音声/映像とそのデジタル表現を参照。

光 → レンズ → CMOS Sensor → ISP → エンコーダ → ストリーム出力

ISP Pipeline:
  Raw Bayer → 黒レベル補正 → 欠陥画素補正 → Demosaic → ホワイトバランス →
  色補正 → Gamma → ノイズ低減(2D/3D-DNR) → シャープネス → YUV出力

主流のXiaomiカメラは YUV420 色空間（YUV420の詳細な説明は音声/映像基礎を参照）、H.265 ビデオエンコード、Opus オーディオエンコード、ビデオフレームレート 20fps を使用する。

マルチストリーム設計：

ストリーム	解像度	色空間	フレームレート	エンコード	ビットレート	用途
メインストリーム	1920x1080 / 2304x1296	YUV420	20fps	H.265	1~4 Mbps	P2P高画質視聴、クラウド保存
サブストリーム	640x360	YUV420	15fps	H.265	200~500 Kbps	P2Pスムーズ視聴（弱時）、AI推論入力
JPEGストリーム	1920x1080	—	必要に応じて	JPEG	—	スクリーンショット、カバー画像

MIC → ADC (16kHz/16bit) → AEC(エコーキャンセル) → ANR(ノイズ低減) → AGC(ゲイン制御) → エンコード(Opus)

オーディオエンコードには Opus を採用。これはオープンソースでロイヤリティフリーのエンコード形式であり、低ビットレート音声（6kbps）から高ビットレート音楽（510kbps）までの全シーンをカバーし、エンコード遅延はわずか5msと、リアルタイム通話に非常に適している。

AEC（Acoustic Echo Cancellation）：通話シーンでは必須、スピーカーのエコーを除去
ANR（Automatic Noise Reduction）：環境ノイズを除去
AGC（Automatic Gain Control）：自動的にゲインを調整し、音量の大小を最適化

録画戦略：
  ├── 連続録画：7x24時間の循環書き込み、容量がいっぱいになると最も古いファイルを自動的に上書き
  └── イベント録画：イベント検出時のみ録画、容量を節約

ファイル構成：
  /mnt/sdcard/record/
  ├── 2024/11/10/
  │   ├── 14/            # 時間単位のディレクトリ
  │   │   ├── 00.mp4     # 1分ごとに1ファイル
  │   │   ├── 01.mp4
  │   │   └── ...
  │   └── 15/
  └── index.db           # SQLiteインデックス、タイムライン検索を高速化

テスト項目	方法	判定基準
ビデオ画質	標準カラーチャートに合わせて自動分析	色/コントラスト/解像度が基準値を満たすこと
赤外線ナイトビジョン	暗箱環境でIR LEDの明るさを確認	均一な照明、ケラレがないこと
PTZ動作	全範囲回転、ステップ数を検出	位置決め精度 ≤1°、動作がスムーズであること
マイク	標準音源を再生、録音を検出	SNR ≥ 40dB
スピーカー	テスト音声を再生	音割れなし、音量が基準値を満たすこと
Wi-Fi	指定APに接続、スループットを測定	≥ 10Mbps
TFカードスロット	テストカードを挿入、読み書き検証	速度 ≥ 10MB/s
ボタン/リセット	押下検出	GPIOレベルが正しく変化すること
消費電力	各シナリオでの電流測定	スタンバイ <2W、動作時 <5W

テスト	条件	要件
高温エージング	50°Cで連続48h動作	フリーズなし、画面異常なし
低温起動	-10°Cでのコールドスタート	正常に映像出力
電圧変動	4.5V ~ 5.5V	安定動作
停電テスト	ランダム停電 1000回	システムが正常起動、ファイルシステムに破損なし
Wi-Fiローミング	信号減衰/回復	自動再接続、P2P復旧
長期連続運転	30日間連続動作	メモリリークなし、サービスが終了しない

工業レベルのMi Smart Camera製品は、ハードウェアからソフトウェア、クラウドに至るまで、非常に広範な技術スタックを必要とする：

ハードウェア: SoC選定 → センサー → 光学 → 構造 → 電源 → 無線
ソフトウェア: OS/BSP → ISPチューニング → エンコード → P2P → AI → IoT → OTA
クラウド: ネットワーク設定 → デバイス管理 → クラウド保存 → メッセージプッシュ → OTA配信
生産: 書き込み → ID書き込み → 自動化テスト → エージング → パッケージング

中核となる課題は、限られたハードウェアリソース（数百MHzのCPU + 百数MBのメモリ）のもとで、ビデオ収集エンコード、AI推論、P2P伝送、クラウド保存アップロード、IoT通信などの複数のリアルタイムタスクを同時に稼働させ、7x24時間の安定動作を保証することである。これには、緻密なリソーススケジューリング、厳格なメモリ管理、そして堅牢な異常復旧メカニズムが必要となる。

本稿では、これまでのブログで個別に紹介してきた技術知識を、一つの完全な製品シナリオに統合した：

音声/映像のデジタル化におけるサンプリング、YUV420、H.265エンコード → カメラのビデオ収集とエンコードパイプライン
P2P技術におけるNAT越え → MISS SDKのマルチエンジンP2Pアーキテクチャ
HLSストリーミングにおけるセグメント保存 → クラウド保存のセグメントアップロードとタイムライン再生
Matterプロトコルにおけるデバイスモデル → Mi IoT SPECのService/Property/Action設計

参考資料