駐車場の満空表示灯（満／空灯）の発光色をカラーセンサで外付け読み取りし、満車・空車状態をIoTデータとして取得する実証（PoC）の設計書。
- ステータス: PoC 実証フェーズ（LTE-M 版の試作機で試験中、LoRaWAN 版を実装中）
- 最終更新: 2026-09-29
- 管理: GitHub（本設計書・Issues・実装コードを同一リポジトリで管理）
駐車場の満空状態を取得する一般的な方法は、各車室へのセンサ設置や、入退場ゲートと連動した在車台数カウントである。これらは駐車場設備側ですでに処理されており、外部から新規に取得しようとすると設備への介入が必要になる。
一方、多くの駐車場では満空状態が「満／空」表示灯として可視化されている。本PoCは、この既存の表示灯を外側から読み取ることで、設備に手を加えずに満空データを取得できないかを検証する。
- 満空表示灯の発光色を外付けカラーセンサで読み取り、「満／空」を判定できることを確認する。
- 設備（制御盤・配線）に一切介入しない、外付け・単機能・設置容易な構成で成立することを示す。
- 取得したデータを既存のデータ基盤（FIWARE Orion / NGSIv2）に連携できる見通しを得る。
- 長期間の安定運用・耐久性の実証（PoC期間は数週間〜数ヶ月を想定。電池容量はそれ以上の余裕あり）。
- ソーラー等による自立電源での無人長期運用（将来オプションとして記載のみ）。
- 全表示方式への対応（後述のとおり「色切替型」に限定）。
- 製品化・量産設計・外部提供。
調査の結果、世の中の満空表示灯は概ね以下の4タイプに分類される。
| タイプ | 説明 | 本PoCでの扱い |
|---|---|---|
| 色切替型 | 同一表示面で赤（満）↔緑（空）など色が変わる。LED式の主流。 | 対象（本命） |
| フルドット型 | フルドットLEDで満/空/混/閉やアイコン・文字を表示。 | スコープ外（将来検討） |
| 回転式（メカ式） | 物理的に板が回転して満/空を切替。非発光。 | スコープ外（光で読めない） |
| 多階・複合表示型 | 立体駐車場で階別満空を1枚に集約表示。 | スコープ外（多点必要） |
- 対象は 色切替型（赤=満／緑=空 など、色で状態が変わるLED式） に限定する。
- 表示方式を絞らないと実証設計が発散するため、まず最も普及している方式で成立性を確認する。
- 設置にあたり、表示灯設置者の貼り付け許可は得られている前提とする。
- PoC初期は 2〜3現場 を想定。
- 目的は「現場ごとの光条件下で赤緑判定が安定するか」のパターン収集。
カメラで表示灯を撮影する方式ではなく、表示灯の発光面にカラーセンサを直接貼り付け、その一点の色と明るさを読む方式を採用する。
| 課題 | カメラ方式 | センサ直貼り方式 |
|---|---|---|
| 設置位置 | 表示灯前方に設置場所と画角確保が必要 | 発光面に密着、位置問題なし |
| 外光・昼夜 | 露出・白飛び・反射の影響を受ける | 黒カッティングシート積層で外光を物理的に遮断 |
| 遮蔽 | 車両の通過で視界が遮られる | 密着のため遮蔽の影響なし |
| 処理負荷・電力 | 画像処理が必要で消費電力大 | 色の閾値比較のみ、超低消費 |
センサ部は数mm角のチップだが、現場設置では Grove - I2C Color Sensor V3.0 を含む小型パッチユニットを、透明テープと黒カッティングシートの積層で発光面に固定する。
対象満空灯の構造（PoC 初回現場）
- 表示面 385×391 mm、透明アクリルカバー、額縁で縁を覆う構造。
- 縁へのクリップ固定は不可。吸盤は落下リスクがあり採用しない。
- 透明テープで面全体を固定し、落下リスクをゼロにする（安全上最重要）。
- 黒カッティングシートが遮光層を兼ね、外光の混入を抑える。
表示灯の発光面（透明アクリル）
┌─────────────────────────────┐
│ 満／空 の光 │
└──────────────┬──────────────┘
│ 光
┌──────────────▼──────────────┐ ← 透明テープで全面固定
│ 黒カッティングシート（遮光） │
│ ┌─────────────┐ │
│ │ Grove Color │ ← 受光部 │
│ │ Sensor V3.0 │ │
│ └──────┬──────┘ │
└──────────┼──────────────────┘
│ Grove 4芯ケーブル
ESP32本体（別筐体）へ
受光位置
- 画像分析の結果、LED 配列上では 下から2行目・左から2列目 付近が推奨。
- 黒シートにセンサ受光窓を切り抜き、Grove Color Sensor V3.0 の受光部を窓に合わせる。
運用上の留意
- 発光面に乗るのはパッチのみ。ESP32 本体・電源は Grove ケーブルで分離し、表示灯裏や柱に固定する。
- 脱着はテープを剥がすだけ。仮設 PoC 用途に適合する。
- パッチは数 cm 角程度で、385 mm 面に対して面積比は小さく視認性への影響は限定的。
- カラーセンサが返す R・G・B 値を比較し、
R - G ≥ threshold なら満（赤）、G - R ≥ threshold なら空（緑）と判定。 - R と G の差が一定閾値未満の場合は「不明」とし、消灯・遷移中の誤判定を回避する。
- 現場ごとの閾値はサーバ側パラメータとして保持し、端末/サーバ双方で判定可能にする。
[満空灯の発光面] 赤=満 / 緑=空
│ 光
▼
[センサパッチ] Grove Color Sensor V3.0 + 黒シート積層固定
│ Grove I2C ケーブル
▼
[XIAO ESP32S3 + Grove Shield] 赤か緑か判定・送信 ← 電源: LiPo 電池（§6）
│ LTE-M / Wi-Fi: MQTT over TLS LoRaWAN: AWS IoT Core for LoRaWAN（#40）
▼
[AWS IoT Core] 受け口（ルールでトリガー）
│
▼
[AWS Lambda] ブリッジ（ペイロード変換 → NGSIv2 upsert） ※現在はスタブ（受信ログを CloudWatch Logs に記録するだけ）。本実装は #7
│
▼
[FIWARE Orion] 満空を登録
│
▼
[STH-Comet] 履歴蓄積・読み取り精度の検証
端末は Orion に直接書き込まない。MQTT ペイロードの変換と NGSIv2 への upsert は Lambda（ブリッジ）が担う。
- 端末は「生のセンサ値（RGB＋輝度）」と「端末内の暫定判定結果」の両方を送信する。
- サーバ側は生値で再判定も、端末判定の採用も選べる。
- 現場別閾値テーブルをサーバに持ち、必要なら端末にも配信。判定ロジックを端末/サーバどちらに寄せるかを後から変更可能にする。
通信モジュールごとに版を分ける。ビルド環境（PlatformIO env）で版を選び、モジュールの自動判別や共存はしない（Grove UART ポートを LTE-M と LoRaWAN で排他利用するため）。
| 版 | モジュール | 状況 | 使い分け |
|---|---|---|---|
| LoRaWAN 版 | Grove Wio-E5（STM32WLE5JC、技適付き） | 実装中（#40） | 本流。現場にゲートウェイを置ける場合。送信が短く電池に有利 |
| LTE-M 版 | M5Stack SIM7080G CAT-M Unit（M5STACK-U128）+ SORACOM SIM（plan-D / plan-KM1） | 実装済み・現地試験済み | LoRaWAN でどうしても通信できない場合 |
| Wi-Fi | ESP32-S3 内蔵 | ファーム対応済み | Wi-Fi を使える環境 |
- LTE-M 版は、送信するときだけロードスイッチ基板で LTE-M の電源を入れる（#88、基板評価中）。モデム内蔵の TLS で AWS IoT Core に直接つなぐ。旧方式のラッチングリレー（#46）は廃止した（経緯: docs/25-low-power-phase2-hardware-cutoff.md §2）。
- 送信データは判定結果＋生値のみで極小（数百バイト程度）。LoRaWAN の典型的なペイロードにも収まる。
- ファームの env と設定は firmware/README.md を参照。
- 満空フラグをNGSIv2でOrionにupsert。
- PoC段階では標準データモデルにこだわらず、独自エンティティ（例:
ParkingStatusSensor）にstatus（満/空/不明）・生センサ値・タイムスタンプを載せる。 - STH-Cometで履歴化し読み取り精度を検証。方式確定後に
OffStreetParking等の標準属性へマッピングし直す。 - 投入は既存の moc-skill / GeonicDB CLI で運用可能。
| 部品 | 型番 | 入手先 | 価格 | 備考 |
|---|---|---|---|---|
| マイコン | Seeed XIAO ESP32S3（無印） | 秋月電子 | ¥1,480 | 技適取得済(217-230892)。BAT はパッドのみ（JST 非搭載） |
| Grove Shield | Grove Shield for XIAO（103020312） | Seeed JP 等 | 約¥700 | 8×Grove（I2C×2・UART×1）。BAT パッド・充電管理付き |
| カラーセンサ | Grove - I2C Color Sensor V3.0（101021133） | Seeed Studio 等 | 約¥600 | VEML6040 搭載。I2C 0x10。Grove コネクタ内蔵 |
| センサ接続 | Grove 4芯ケーブル 50〜100cm | Seeed / Amazon 等 | 約¥200〜400 | 標準配線（ピン入替不要。wiring.md） |
| 閾値調整用ポテンショメーター | Grove - Rotary Angle Sensor | Seeed 等 | — | 現地での判定閾値の調整用（#60）。調整後は外してよい |
| バッテリー | LiPo 3.7V 4,400mAh 保護回路内蔵 JST-PH | ストロベリーリナックス | ¥550 | Grove Shield の BAT パッドへ JST で接続 |
| 配線・防水箱・固定材 | Grove ケーブル、IP65 樹脂箱、透明テープ・黒カッティングシート等 | Seeed / ホームセンター | 約¥2,000〜3,000 | 詳細は docs/hardware.md 参照 |
通信モジュール（版ごとにどちらか）
| 部品 | 型番 | 入手先 | 価格 | 備考 |
|---|---|---|---|---|
| LoRaWAN モジュール | Grove - Wio-E5 | Seeed 等 | — | LoRaWAN 版。Grove UART 接続。常時通電 |
| LTE-M モジュール | M5Stack SIM7080G CAT-M Unit（M5STACK-U128） | スイッチサイエンス | ¥6,908 | LTE-M 版。Grove UART 接続 |
| SIM | SORACOM IoT SIM plan-D / plan-KM1 | SORACOMストア | ¥990（初期）+ ¥192/月〜 | LTE-M 版。ドコモ / KDDI 回線 |
| LTE-M 電源スイッチ基板 | 自作小基板 rev A（TI TPS22918、hardware/lte-power-switch/） | JLCPCB（基板 + 実装） | $20.14（5 枚、送料込み） | LTE-M 版。LTE-M の電源を送信時だけ入れる（#88）。rev A は Grove コネクタのピン番号が鏡像で、普通のケーブルでは使えない。rev B（2026-10-12 発注、$30.61）で直した |
- 詳細な選定経緯・調達先 URL は docs/hardware.md・docs/bom.md を参照。
- マイコン: カメラ不要なため無印 XIAO ESP32S3 で十分（Sense 版は不要）。LiPo 充電管理は Grove Shield 側にある。
- センサ: Grove - I2C Color Sensor V3.0（VEML6040 搭載）。
- 接続方式: センサ・通信モジュール・LTE-M 電源スイッチ基板はすべて Grove で接続する（ピン入替・はんだ付け不要）。汎用性と組み立ての容易さを両立させ、LoRaWAN 版と LTE-M 版で構成を揃える。
- バッテリー: LiPo 電池を Grove Shield の BAT パッドに JST で接続（XIAO 本体には JST コネクタ非搭載）。モバイルバッテリーはオートパワーオフおよびパススルー時の瞬断が問題になるため不採用。
- **LiPo 電池（3.7V 4,400mAh、保護回路内蔵）**を Grove Shield for XIAO の BAT パッドに JST で接続して運用する（はんだ付け前にテスターで極性を確認）。電源を引ける現場では USB 給電でも可。
- 電池で動かしているとき、ESP32-S3 と Grove の各ポート（センサー・LTE-M を含む）は、Shield 上の降圧コンバーター（ETA3410）の 3.3V を共有する。5V 系統は無効で、昇圧回路は使わない（docs/hardware.md）。
- LTE-M モジュールは、送信するときだけロードスイッチ基板で通電する（#88、基板評価中）。
- 起床間隔は 5 分（
PSS_SLEEP_SECONDS=300）。LTE-M 版は状態が変わったときだけ送信し、変わらなければ約 66 分に 1 回だけ定期送信する（PSS_CHANGE_ONLY_SEND=1、PSS_HEARTBEAT_CYCLES=12）。満空情報に秒単位の即時性は不要なので、この遅延は許容できる。
実測値（2026-09-29、xiao-s3-aws-lte-relay-pot、U200-1A 高速ロガーで約 44.5h 記録。詳細: docs/74-brownout-conclusions.md §4）:
| 項目 | 実測値 |
|---|---|
| Deep Sleep 中の電流 | 0.43 mA |
| 送信する起床 1 回（起床〜LTE 接続〜MQTT 送信〜切断〜Deep Sleep） | 16.8 秒・0.446 mAh |
| 送信しない起床 1 回（センサー読み取りのみ） | 4.8 秒・0.0475 mAh |
稼働日数の目安（LiPo 実効 3,960 mAh = 4,400 mAh × 90%）:
| シナリオ | 稼働日数 |
|---|---|
| 状態変化なし（約 66 分に 1 回の定期送信のみ） | 約 122 日 |
| 状態変化 1 日 20 回 | 約 98 日 |
| 毎回送信（worst case） | 約 29 日 |
電池残量と充電の目安: LTE-M 版は、電池の電圧が下がると LTE の送信時にブラウンアウトリセットが起き始める。1 回だけなら実害はほぼないが、そのまま放置すると送信できなくなる。1 回目のブラウンアウト（テレメトリの resetReason=brownout）を「すぐ充電」の合図として扱う。実際に使える日数は、上の表より短くなる（docs/74-brownout-conclusions.md §3.1）。
LoRaWAN 版: 送信が短く、TLS も不要なので、LTE-M 版より消費は小さい見込み（未実測、#40）。ゲートウェイを置ける現場では LoRaWAN を優先する（§4.3）。
将来の長期自立運用フェーズでのオプションとして記載のみ。初期PoCでは以下の理由で不採用とする。
- ソーラーパネルが現時点で比較的高価。
- 駐車場の設置状況により十分な日照が得られるか不明で、現地確認が前提。
- PoC段階では長期安定運用が要件外。
採用する場合の候補・留意点:
- 候補: MOTTERU MOT-SOLAR24（最大24W, USB-A, IP65）、Anker Solix PS30（27W, IP65）等。
- IP65防水はパネル部のみの製品が多く、パネルのみ屋外・バッテリ/ESP32は防水箱に収納。
- ソーラー併用時はバッテリーの「パススルー充電対応」「充放電切替時の出力瞬断なし」「低負荷時も高効率な充電制御IC(MPPT等)」を満たす機種を現物確認。
| 区分 | 状況 |
|---|---|
| 満空灯を後付け読み取りする事業・製品 | 見当たらない（応用先として空いている） |
| ほぼ同じ個人試作 | 1件あり。機器の電源ランプの色をカラーセンサ(S11059)＋ESP32で読む試作。「消灯=黒」の判定に課題。本設計の「差が小さければ不明」処理の妥当性を裏付け |
| 上位概念（表示灯の後付けIoT化） | 確立済み。PATLITE WDシステム（信号灯の後付けIoT化）等の製品、複数の特許が存在。技術的成立性は実証済み |
- 「光センサで人間用表示灯を外側から読みIoT化する」技術自体は枯れており、成立性は担保されている。
- 「駐車場満空灯 × 自治体オープンデータ／FIWARE連携」という応用は明確な先行事例が見当たらず、応用先として空いている。
- PoCで確かめるべきは技術成立性ではなく「現場光条件での赤緑安定判定」に集約される。
- 生値の分離: Grove Color Sensor V3.0（VEML6040）の R/G/B/W 生値が、満（赤）と空（緑）で十分なマージンを持って分離するか。透明カバー越し・拡散材ありの実機で確認。
- 2状態以外の表示: 消灯・点滅・整備中・深夜消灯等が現場にあるか棚卸しし、判定テーブルに「不明」状態を持たせる。
- 電源運用: 電池の電圧が下がったときにブラウンアウトが起き始める残量の確認（LTE-M 版、docs/74-brownout-conclusions.md §2.4）。LoRaWAN 版の消費電力の実測（#40）。
調査した米国特許 US11962293B2「Passive optical sensors」の権利範囲を確認した結果:
- この特許の新規部分は「受動回路（FET＋蓄電）で、リレー接点ON/OFFのようなバイナリ出力を無電源で作る」という回路構成にある。「ランプを光で読む」という目的自体は権利化されていない。
- 本PoC方式は「能動的なマイコン(ESP32)＋デジタルI2Cカラーセンサ＋ソフトウェア判定」であり、構成・動作原理が別物。抵触する見込みは低い。
- むしろ本方式は、当該特許が「従来技術（課題あり）」と位置づけるデジタルセンサ側であり、特許の新規部分の外側にある。
- ESP32＋カラーセンサでランプ色を読む構成は公知（個人事例あり）。
リスク評価:
- PoC段階（社内技術検証）: 試験・研究目的の実施に当たり、特許侵害の問題はほぼ生じない（一般論。最終判断は弁理士領域）。
- 事業化段階: 以下を実施。
- 受動光センサ特許の他、PATLITE WDシステム関連等の関連特許を調査。
- 国内特許（対応日本出願・別の国内特許）の有無を確認。
- 弁理士によるFTO（Freedom to Operate）確認。
取得したセンサデータは NGSIv2 エンティティ ParkingStatusSensor として FIWARE Orion に登録する。センサ1台 = エンティティ1件の 1:1 構成で、駐車場の集約や台数管理は行わない。端末の MQTT ペイロード（raw・timestamp 等）と NGSIv2 属性名（rawSensor・dateObserved 等）は異なるため、AWS Lambda（ブリッジ）で変換する。将来的に OffStreetParking（FIWARE Smart Data Models）へマッピングする想定だが、PoC段階では ParkingStatusSensor 単体で完結させる。
詳細は docs/data-model.md を参照。
タスクは GitHub Issues で管理しています。全体ロードマップは Issue #22 を参照。
| Milestone | 状況 | 残っている主な Issue |
|---|---|---|
| M1: 試作1台 通電 | 完了 | — |
| M2: クラウド E2E | 端末 → AWS IoT Core → Lambda（スタブ）まで完了 | #7 Lambda の本実装（NGSIv2）、#27 組織クラウド環境 |
| M3: 現場 PoC | 進行中 | #8 生値分離テスト、#2 棚卸し |
マイルストーン外の主な進行中の作業: #40 LoRaWAN 版、#12 筐体。
parking-status-sensor/
├── README.md # 本設計書
├── AGENTS.md # 開発運用（GitHub Flow・ドキュメント運用）
├── docs/
│ ├── hardware.md # 部品選定・給電経路・稼働日数試算
│ ├── bom.md # 詳細BOM（試作1台）
│ ├── schematic.md # 回路図
│ ├── wiring.md # 組み立て手順・実物確認
│ ├── data-model.md # NGSIv2 エンティティ設計
│ ├── iot-core.md # AWS IoT Core 設計（#4）
│ ├── aws-admin-handoff.md # AWS 管理者向けセットアップ手順
│ ├── sync-delivery-design.md # 送信確認・再送（sync ledger）の設計
│ ├── power-measurement.md # 消費電力の計測手順
│ ├── NN-*.md # Issue ごとの設計・調査（例: 74-brownout-conclusions.md）
│ └── datasheets/ # 回路図・データシート
├── firmware/ # ESP32 ファームウェア（PlatformIO、版ごとの env）
├── hardware/
│ └── flame-sensor-case/ # Grove センサ用ケースの 3D モデル（第三者作品・CC BY 4.0、#3）
├── bridge/ # Lambda ブリッジ（現在はスタブ → #7 で本実装）
├── infra/ # AWS IoT Core・Cognito のプロビジョニングスクリプト
└── tools/
├── power-logger/ # U200-1A 電源ロガー（通常・高速モード）
├── log-viewer/ # CloudWatch Logs 閲覧用 iOS アプリ
├── soracom/ # SORACOM SIM の状態確認
├── mosquitto/ # ローカル MQTT ブローカー（開発用）
└── ipad-sign-simulator/ # 満空表示灯を iPad 画面で模擬する検証用アプリ（#54）