サプライチェーン OTA とオーナーシップパターン

コンテキスト

FlexGalaxy.AI は、デバイスがエンドユーザーに届くまでに複数の組織を経由するマルチパーティサプライチェーンに対応しています。典型的なチェーンには、ソフトウェア開発者、ロボットメーカー、1社以上のディストリビューター、およびエンドユーザーが含まれます。各当事者はそれぞれ独自の FlexGalaxy アカウントを持ち、デバイスに対して異なるレベルの可視性と制御を必要とします。

このパターンは、サプライチェーンシナリオで生じる5つの横断的関心事に対処します：

  1. 登録時の自動 OTA — デバイスがプラットフォームに初めて登場した際に、正しいソフトウェアを自動的に受信します

  2. 属性ベースのポリシーターゲティング — ポリシーは個々のデバイス ID ではなくデバイスクラスを対象とするため、デバイスが存在する前に作成できます

  3. クロスアカウント OTA — あるアカウントのソフトウェア開発者が公開したアーティファクトが、別のアカウントが所有するデバイスにデプロイされます

  4. インストール追跡とライセンスカウント — 開発者は、何台のデバイスにソフトウェアがインストールされたか、何件のライセンスを発行すべきかを把握する必要があります

  5. マルチティアデバイススコーピング — デバイスはメーカーからディストリビューター、エンドユーザーへと移動し、各ティアは自身が所有または運用するデバイスのみを参照できます

ユーザーストーリー

ソフトウェア開発者（SyriusSoft）は倉庫ナビゲーションソフトウェアを開発しています。ロボットメーカー（RoboMake）は AMR ロボットを製造しています。RoboMake はすべてのロボットに SyriusSoft のナビゲーションソフトウェアをプリインストールした状態で出荷したいと考えています。ロボットは地域ディストリビューターを通じて販売され、ディストリビューターがエンドユーザーに販売します。

具体的な数値：

当事者

役割

ロボット数

SyriusSoft

ソフトウェア開発者

0（ソフトウェアの公開のみ）

RoboMake

ロボットメーカー

AMR-X1 ロボットを100台製造

中国ディストリビューター

地域ディストリビューター

20台を受領

日本ディストリビューター

地域ディストリビューター

60台を受領

米国ディストリビューター

地域ディストリビューター

15台を受領

シンガポールディストリビューター

地域ディストリビューター

5台を受領

倉庫 A

エンドユーザー（日本ディストリビューターの顧客）

30台を購入

工場 B

エンドユーザー（日本ディストリビューターの顧客）

15台を購入

アクターとアカウント

アクター

アカウント種別

役割

FlexGalaxy サービス

SyriusSoft

開発者アカウント

ナビゲーションソフトウェアアーティファクトと OTA ポリシーを公開

OTAForge（パブリッシャー）、TrustMint（ライセンス発行者）

RoboMake

メーカーアカウント

ロボットを製造し、登録し、リセラーに配布

DeviceAdmin、Provisioning Service

ディストリビューター

RoboMake 組織配下のメンバーアカウント

割り当てられたロボットを受領し、エンドユーザーに再販

DeviceAdmin（スコープ付きビュー）

エンドユーザー

スタンドアロンまたはメンバーアカウント

ロボットを運用し、OTA アップデートを受信

DeviceAdmin、OTAForge（DDI ポーリング）

アカウント階層

SyriusSoft (Developer Account)
├── Publishes: AMR-X1 Nav Software v3.0
└── Policy: "Install on all AMR-X1 rev≥r3"

RoboMake (Maker Account / Organization Root)
├── 100 AMR-X1 robots enrolled
│
├── China Distributor (Member Account)
│   └── 20 robots transferred
│
├── Japan Distributor (Member Account)
│   ├── 15 robots (retained)
│   ├── Warehouse A (End User Account)
│   │   └── 30 robots transferred
│   └── Factory B (End User Account)
│       └── 15 robots transferred
│
├── US Distributor (Member Account)
│   └── 15 robots transferred
│
└── Singapore Distributor (Member Account)
    └── 5 robots transferred

パターン

1. Auto-OTA on Enrollment

工場作業員が DeviceAdmin を通じて新しいロボットを登録すると、デバイスは手動の介入なしに正しいソフトウェアを自動的に受信します。

仕組み

Factory Worker              DeviceAdmin         Provisioning       OTAForge          Robot
     │                          │                 Service             │                │
     │  Enroll AMR-X1-001       │                    │                │                │
     │  (serial, type, model)   │                    │                │                │
     │─────────────────────────►│                    │                │                │
     │                          │  POST /enroll      │                │                │
     │                          │───────────────────►│                │                │
     │                          │                    │                │                │
     │                          │                    ├── ThingsBoard: create device    │
     │                          │                    ├── hawkBit: create target        │
     │                          │                    ├── DotID: create M2M client      │
     │                          │                    │                │                │
     │                          │  credentials       │                │                │
     │                          │◄───────────────────│                │                │
     │                          │                    │                │                │
     │                          │                    │  New target    │                │
     │                          │                    │  event         │                │
     │                          │                    │───────────────►│                │
     │                          │                    │                │                │
     │                          │                    │                │  Evaluate      │
     │                          │                    │                │  policies vs   │
     │                          │                    │                │  new target    │
     │                          │                    │                │  attributes    │
     │                          │                    │                │                │
     │                          │                    │                │  Match found → │
     │                          │                    │                │  auto-create   │
     │                          │                    │                │  rollout       │
     │                          │                    │                │                │
     │                          │                    │                │  DDI: pending  │
     │                          │                    │                │  deployment    │
     │                          │                    │                │◄───────────────│
     │                          │                    │                │                │
     │                          │                    │                │  Download +    │
     │                          │                    │                │  install       │
     │                          │                    │                │───────────────►│
     │                          │                    │                │                │
     │                          │                    │                │  Feedback:     │
     │                          │                    │                │  success       │
     │                          │                    │                │◄───────────────│

  1. 工場作業員が DeviceAdmin を通じてロボットをシリアル番号、タイプ（amr）、モデル（X1）、ハードウェアリビジョン（r3）とともに登録

  2. DeviceAdmin が Provisioning Service に委譲し、ThingsBoard、hawkBit（OTAForge 経由）、および DotID にレコードを作成

  3. 新しい hawkBit ターゲットが OTAForge のポリシー評価エンジンをトリガー

  4. OTAForge がターゲットの属性をアクティブなロールアウトポリシーと照合

  5. 一致するポリシーがこのターゲットのロールアウトを自動作成

  6. ロボットが OTAForge の DDI proxy をポーリングし、保留中のデプロイメントを検出し、アーティファクトをダウンロードしてインストール

  7. ロボットが DDI フィードバックを通じてインストール成功を報告

初回登録後のフロー全体はゼロタッチです。

OTAForge ポリシーエンジン

OTAForge は hawkBit のネイティブな自動割り当てを独自のポリシーエンジンに抽象化しています。これが重要な理由は以下の通りです：

  • hawkBit の自動割り当ては、単一のディストリビューションセットが紐付いたターゲットフィルターを使用しており、より豊富なポリシーロジック（メンテナンスウィンドウ、バッテリー閾値、段階的ロールアウト）を表現できません

  • OTAForge のポリシーエンジンは Policy Service のロールアウトポリシーを評価し、完全な制約ボキャブラリー（ターゲット選択、メンテナンスウィンドウ、バッテリー閾値、同時実行制限、段階的デプロイメント）をサポートします

  • OTAForge は hawkBit の自動割り当てを公開機能ではなく、実装の詳細として扱います

2層属性評価

ポリシー評価は静的ターゲティングと動的制約に分かれます。ThingsBoard と hawkBit はすでにデバイス属性を保存しており、OTAForge はそれを活用します — このデータを複製する必要はありません。

ソース

属性の例

性質

設定者

ThingsBoard

type, model, revision, capabilities, zone, site

静的（プロビジョニング時に設定、変更はまれ）

Provisioning Service

hawkBit

controller_id, target_type, firmware_version, update_status

ほぼ静的。firmware_version は OTA 後に更新

Provisioning Service + OTAForge（インストール後）

DeviceAdmin（ランタイム）

battery_level, task_status, connectivity

動的（リアルタイムテレメトリ）

デバイス（MQTT 経由）

評価ループ：

  1. 静的ターゲティング（どのデバイスか？）— OTAForge が ThingsBoard と hawkBit の属性をクエリして候補ターゲットセットを構築します。これにより、ロールアウトの対象となるデバイスが決定されます。

  2. 動的制約（いつ、どのような条件で？）— 各候補に対して、OTAForge は DeviceAdmin からリアルタイムの状態を確認します：バッテリーレベル、アクティブなタスクステータス、現在時刻とメンテナンスウィンドウの比較。これにより、ロールアウトを今実行するか延期するかが決定されます。

静的な部分は ThingsBoard と hawkBit にすでに保存されている属性を活用します。動的な部分は OTAForge がその上に追加する新しいロジックです。

2. Attribute-Based Policy Targeting

ソフトウェア開発者（SyriusSoft）はロボットが存在する前に OTA ポリシーを作成します。ポリシーはデバイス ID ではなく、デバイス属性を対象とします。

ポリシー表現

Target: type = "amr" AND model = "X1" AND revision >= "r3"
Action: Install distribution set "NavSoft-v3.0"
Constraints:
  - Battery > 50%
  - Not executing a contract
  - Maintenance window: 00:00–06:00 local time

属性ソース

属性

設定者

タイミング

値の例

manufacturer

Provisioning Service

登録時

RoboMake

type

Provisioning Service

登録時

amr

model

Provisioning Service

登録時

X1

revision

Provisioning Service

登録時

r3

firmware_version

OTAForge（DDI フィードバック）

各アップデート後

2.5.0

capabilities

Provisioning Service

登録時または組み立て時

["navigation", "picking"]

account_id

Provisioning Service

登録時または移転時

acc-robo-001

org_id

Org Service

組織メンバーシップ作成時

org-robomake

なぜ属性ベースなのか

アプローチ

問題点

デバイス ID によるターゲティング

開発者はデバイスが存在する前にデバイス ID を知る必要がある

アカウントによるターゲティング

粒度が粗すぎる — アカウント内のすべてのデバイスタイプに影響する

属性によるターゲティング（採用）

開発者がデバイスクラスを記述し、プラットフォームが動的にマッチング

RoboMake がロボット AMR-X1-042 を type=amr, model=X1, revision=r3 で登録すると、OTAForge のポリシーエンジンが SyriusSoft の既存ポリシーと照合し、ロールアウトを自動作成します — SyriusSoft がこの特定のデバイスを一度も見たことがなくても。

3. Cross-Account OTA

SyriusSoft（アカウント S）がアーティファクトとポリシーを公開し、RoboMake（アカウント M）がデバイスを登録します。これらは異なるアカウントです。プラットフォームは Marketplace の「Get」アクションを通じてこの境界を橋渡しします。

「Get」アクション

「Get」はアカウント管理者（または委任による組織全体のソフトウェア/サービス管理者）がリスティングに対して実行する Marketplace アクションです。「Get」は何もデプロイしません — そのアカウントのスコープ内でソフトウェアの OTA ポリシーを作成する能力をアンロックします。

SyriusSoft                    Marketplace                   RoboMake Admin
     │                             │                             │
     │  Publish listing:           │                             │
     │  "NavSoft v3.0 for          │                             │
     │   AMR-X1 rev≥r3"            │                             │
     │────────────────────────────►│                             │
     │                             │                             │
     │                             │  Browse / search            │
     │                             │◄────────────────────────────│
     │                             │                             │
     │                             │  "Get" NavSoft v3.0         │
     │                             │  Scope: [org-wide]          │
     │                             │◄────────────────────────────│
     │                             │                             │
     │                             │  Grant: OTAForge may now    │
     │                             │  create policies for        │
     │                             │  NavSoft targeting           │
     │                             │  RoboMake org devices       │
     │                             │──────────────────────►OTAForge
     │                             │                             │
     │                             │  Admin creates rollout       │
     │                             │  policy for NavSoft          │
     │                             │◄────────────────────────────│

「Get」アクションは管理者にスコープの選択を提示します：

"Get" NavSoft v3.0
├── Apply to: ○ This account only
│             ○ Organization-wide (all member accounts)
└── [Confirm]

すべてのクロスアカウント OTA — OEM パートナーシップを含む — は「Get」フローに従います。直接付与のための別のバックチャネルはありません。

デバイスバウンドソフトウェア vs アプリケーションソフトウェア

すべてのソフトウェアがデバイス移転後に同じように動作するわけではありません。プラットフォームは2つのカテゴリを区別します：

カテゴリ

例

誰が「Get」するか

ポリシーターゲット

ライセンス

移転後の OTA

デバイスバウンド

RobotOS、ブートローダー

メーカー

manufacturer = "RoboMake"

永久、無料

常に継続 — ポリシーは所有アカウントではなくメーカー属性を対象とする

アプリケーション

NavSoft、分析エージェント

必要とする誰でも

アカウントまたは組織スコープ（「Get」時に選択）

開発者のライセンスポリシーに準拠

新しいオーナーが「Get」した場合のみ

デバイスバウンドソフトウェアは、ロボットの所有者に関係なく変更されない manufacturer 属性を対象とします。RoboMake がオペレーティングシステムを「Get」し、manufacturer = "RoboMake" を対象とするポリシーを作成すると、そのポリシーはすべての RoboMake ロボットに永久に一致します — メーカーからディストリビューターからエンドユーザーへのすべての移転を通じて。伝播ロジックは不要です。

アプリケーションソフトウェアはアカウントまたは組織スコープを対象とします。デバイスが組織外のアカウントに移転した場合、新しいオーナーは独自にソフトウェアを「Get」する必要があります。これにより、各オーナーに明示的な同意制御が付与されます。

バージョンスコーピング

ソフトウェア開発者は Marketplace リスティングを作成する際にバージョンスコーピングを設定します。これにより「Get」が将来のバージョンをカバーするかどうかが制御されます：

開発者設定

「Get」の動作

全バージョン

新バージョンはポリシーターゲティングに自動的に利用可能 — 再「Get」不要

メジャーバージョンのみ

「Get」は v3.x をカバー。v4.0 は新たな「Get」が必要

特定バージョン

各バージョンに明示的な「Get」が必要

これにより開発者はアップグレードパスを制御できます — 無料ツールは全バージョンをカバーする一方、有料製品はメジャーバージョンごとに再「Get」（および再ライセンス）を要求する場合があります。

4. Installation Tracking and License Counting

SyriusSoft は2つの情報を必要としています：

  1. 何台のデバイスに自分のソフトウェアがインストールされたか？（OTA 追跡）

  2. 何件のライセンスを発行/カウントすべきか？（ライセンス管理）

これらは異なるサービスによって追跡されます：

関心事

サービス

メカニズム

OTA インストールステータス

OTAForge

デバイスからの DDI フィードバック（成功/失敗/進行中）

ライセンス発行

TrustMint

ライセンスが作成されデバイスアイデンティティに紐付け

ビジネスダッシュボードの集約

Marketplace

開発者ポータルが OTAForge + TrustMint データを集約

ThingIO は純粋にデバイステレメトリ（バッテリー、位置、センサー）に特化しています。ビジネスメトリクス — インストール数、ライセンス利用率、「Get」分析 — は Marketplace 開発者ポータルによって集約され、OTAForge と TrustMint のレポーティング API を呼び出します。

インストールとライセンスのタイムライン

イベント

トリガー

OTAForge

TrustMint

ロボット登録

Provisioning Service

ターゲット作成

—

ポリシー一致

OTAForge ポリシーエンジン

ロールアウト作成

—

ダウンロード開始

DDI ポーリング

ステータス: ダウンロード中

—

インストール完了

DDI フィードバック: 成功

ステータス: インストール済み

ライセンス発行ポリシーに依存

インストール失敗

DDI フィードバック: エラー

ステータス: 失敗、リトライポリシー適用

—

ライセンス取消

管理者アクションまたはポリシー

—

ライセンス取消

ポリシー駆動型ライセンス発行

ライセンス発行トリガーはハードコードされていません — ソフトウェアタイプとライセンスタイプによって異なります。ソフトウェア開発者は Marketplace リスティングを作成する際にライセンス発行ポリシーを定義します。TrustMint はこのポリシーを参照してライセンスを発行するタイミングを決定します。

Software/Applet ID
    → query software type + license type
        → query license issuance policy
            → apply policy to determine trigger event

ソフトウェアタイプ

ライセンスタイプ

発行トリガー

例

ファームウェア

デバイス単位の永久ライセンス

OTA インストール成功時

RobotOS v2.0 — DDI が成功を報告した時にライセンス発行

SaaS アプレット

サブスクリプション

明示的なアクティベーション時

分析エージェント — デバイスが初回実行後にライセンス API を呼び出す

マップデータ

アップデート単位の消費型

ダウンロード完了時

ビル A フロアプラン — ダウンロードごとにライセンスを消費

ML モデル

デバイス単位、バージョン固定

OTA インストール成功 + モデル検証時

障害物検出器 — モデルがセルフテストに合格後にライセンス発行

これは Marketplace リスティングにライセンスポリシーの定義を含める必要があることを意味します。開発者はライセンスの発行方法とタイミングを指定せずにオファーを公開することはできません。

開発者の可視性

SyriusSoft は Marketplace 開発者ポータルを通じてビジネスデータの集約を参照できます：

メトリクス

ソース

ポリシーに一致したデバイス総数

OTAForge（ロールアウトターゲット）

成功したインストール数

OTAForge（DDI フィードバック）

失敗したインストール数

OTAForge（DDI フィードバック）

アクティブなライセンス数

TrustMint

インストールの経時トレンド

Marketplace ポータル（OTAForge データを集約）

ライセンス利用率

Marketplace ポータル（TrustMint データを集約）

「Get」件数と採用状況

Marketplace ポータル（自身のデータ）

5. Multi-Tier Device Scoping

デバイスがサプライチェーンを移動するにつれて、所有権の移転と可視性ルールが変化します。

所有権の移転

移転

メカニズム

発生する処理

メーカー → ディストリビューター

DeviceAdmin POST /devices/{id}/transfer

Provisioning Service が ThingsBoard テナント、hawkBit ターゲット属性、DotID M2M クライアントスコープを更新し、旧クレデンシャルを失効

ディストリビューター → エンドユーザー

同一の移転 API

同一のクレデンシャルローテーション。デバイスはエンドユーザーのアカウントにスコープされる

各移転は device provisioning パターンに従います：ThingsBoard デバイスが新しいテナントに移動し、hawkBit ターゲット属性が更新され、DotID M2M クライアントがローテーションされ、device.transferred イベントが Kafka に発行されます。

移転シーケンス

Japan Distributor           DeviceAdmin        Provisioning        Backend Systems
       │                        │                Service                 │
       │  Transfer 30 robots    │                   │                    │
       │  to Warehouse A        │                   │                    │
       │  (batch)               │                   │                    │
       │───────────────────────►│                   │                    │
       │                        │  For each device: │                    │
       │                        │──────────────────►│                    │
       │                        │                   ├── TB: move tenant  │
       │                        │                   ├── hawkBit: update  │
       │                        │                   ├── DotID: rotate    │
       │                        │                   │   M2M client       │
       │                        │                   │                    │
       │                        │                   │  device.transferred│
       │                        │                   │───────────────────►│ Kafka
       │                        │                   │                    │
       │                        │  Transfer complete│                    │
       │                        │◄──────────────────│                    │
       │  200 OK (batch result) │                   │                    │
       │◄───────────────────────│                   │                    │

可視性ルール

Org Service がアカウント階層をモデル化します。IAM Identity Center がクロスアカウントの可視性を付与します。ルールは以下の通りです：

  • 下方向の可視性 — 親アカウントは子アカウントのデバイスを参照できます（読み取り専用）

  • 兄弟間の可視性なし — ディストリビューター同士はお互いのデバイスを参照できません

  • 上方向の可視性 — デフォルトでは付与されません。エンドユーザーはメーカーの他のデバイスを参照できません

アクター

参照範囲

台数

メカニズム

SyriusSoft

インストール + ライセンスメトリクス（集約レベル、デバイスレベルではない）

—

OTAForge + TrustMint レポーティング

RoboMake

全ディストリビューターにわたる全100台のロボット

100

Org Service（組織ルート）+ IAM Identity Center（下方向の読み取り専用）

中国ディストリビューター

自社の20台のロボットのみ

20

アカウントスコープの DeviceAdmin

日本ディストリビューター

自社の15台 + 倉庫 A の30台 + 工場 B の15台

60

Org Service（親）+ IAM Identity Center（子への読み取り専用）

米国ディストリビューター

自社の15台のロボットのみ

15

アカウントスコープの DeviceAdmin

シンガポールディストリビューター

自社の5台のロボットのみ

5

アカウントスコープの DeviceAdmin

倉庫 A

自社の30台のロボットのみ

30

アカウントスコープの DeviceAdmin

工場 B

自社の15台のロボットのみ

15

アカウントスコープの DeviceAdmin

移転後の OTA 継続性

デバイス移転後の OTA の動作はソフトウェアカテゴリに依存します：

  • デバイスバウンドソフトウェア（OS、ブートローダー）— ポリシーは変更されない manufacturer 属性を対象とします。OTA はすべての移転を通じて自動的に継続し、新しいオーナーによるアクションは不要です。

  • アプリケーションソフトウェア — ポリシーはソフトウェアを「Get」したアカウントまたは組織にスコープされます。デバイスが同じ組織内のアカウントに移転する場合（かつ「Get」が組織全体だった場合）、OTA は継続します。デバイスが組織外のアカウントに移転する場合、新しいオーナーが OTA を再開するために独自にソフトウェアを「Get」する必要があります。

テレメトリ移転ルール

デバイスがアカウント間で移転する際、過去のテレメトリデータの取り扱いはテレメトリタイプに依存します。移転ルールは Policy Service に保存され、移転フロー中に Provisioning Service によって実行されます。

テレメトリタイプ

移転時の処理

根拠

デバイスヘルス / 診断

デバイスに付随

安全性と保証 — 新しいオーナーは完全な履歴が必要

運用メトリクス（バッテリーサイクル、モーター稼働時間、エラー件数）

デバイスに付随

メンテナンススケジューリングには完全な履歴が必要

アラートとインシデント記録

デバイスに付随

新しいオーナーは過去のインシデントを把握する必要がある

タスク実行ログ

移転元アカウントに残留

タスクデータはそれを指示したオペレーターに帰属する

位置 / 軌跡履歴

移転元アカウントに残留

施設レイアウト情報を含む可能性がある

アプリケーション固有のテレメトリ

アプリごとに設定可能

アプリ開発者がポリシーを通じて移転ルールを定義

テレメトリ移転ポリシーは device.transferred イベントの処理中に参照されます。Provisioning Service が適用可能なルールに従って ThingsBoard テナント間のデータ移動（または保持）をオーケストレーションします。

関連サービス

サービス

プレーン

このパターンにおける役割

DeviceAdmin

データ

登録 UI、移転 API、デバイスフリートビュー

OTAForge

データ

アーティファクトストレージ、ポリシーエンジン、自動ロールアウト、DDI プロキシ、インストール追跡

ThingIO

データ

デバイステレメトリのみ（バッテリー、位置、センサー）— ビジネスメトリクスは対象外

DotID

アイデンティティ

アカウント認証、M2M クライアントライフサイクル

Org Service

アイデンティティ

アカウント階層（メーカー → ディストリビューター → エンドユーザー）

IAM Identity Center

アイデンティティ

クロスアカウントの読み取り専用可視性付与

Marketplace

エコシステム

「Get」アクション（クロスアカウント OTA 同意）、開発者ポータル（ビジネスメトリクス集約）

TrustMint

—

インストール成功時のライセンス発行

Provisioning Service

—

マルチシステムデバイス登録とクレデンシャル管理

Policy Service

ガバナンス

ロールアウトポリシーの保存と評価

設計上の決定

以下の疑問が設計中に提起され、解決されました：

#

疑問

決定

根拠

1

OTAForge の自動割り当て：独自ポリシーエンジン vs hawkBit ネイティブ？

独自ポリシーエンジン。 OTAForge は2層属性評価によるカスタム評価ループを構築 — ThingsBoard/hawkBit 属性からの静的ターゲティング、DeviceAdmin ランタイム状態からの動的制約。

hawkBit のネイティブな自動割り当てでは、メンテナンスウィンドウ、バッテリー閾値、段階的ロールアウトを表現できない。

2

クロスアカウント OTA：Marketplace「Get」vs Org Service 直接付与 vs 両方？

Marketplace「Get」のみ。 すべてのクロスアカウント OTA — OEM パートナーシップを含む — は「Get」アクションを使用。直接のバックチャネルなし。

単一の一貫した同意モデル。「Get」スコープ（アカウント vs 組織全体）が柔軟性を提供。デバイスバウンドソフトウェアは manufacturer 属性を対象とするため、伝播ロジックなしで移転を通じて持続する。

3

ライセンス発行トリガー：登録 vs インストール vs アクティベーション？

ポリシー駆動型、リスティング単位。 開発者は Marketplace リスティング作成時にライセンス発行ポリシーを定義。TrustMint はこのポリシーを参照。

異なるソフトウェアタイプには異なるトリガーが必要（ファームウェア：インストール時、SaaS：アクティベーション時、マップデータ：ダウンロード時）。単一のハードコードされたトリガーではすべてのケースに対応できない。

4

ThingIO のスコープ：IoT テレメトリのみか、ビジネスメトリクスも含むか？

IoT テレメトリのみ。 ビジネスメトリクス（インストール、ライセンス、「Get」分析）は Marketplace 開発者ポータルによって集約。

ビジネスデータはデバイスよりもソフトウェアに近い。Marketplace ポータルが OTAForge と TrustMint のレポーティング API を呼び出す。ThingIO はデバイスデータに集中。

5

移転時のテレメトリ履歴：デバイスに付随、残留、それとも分割？

タイプ依存、ポリシー駆動型。 移転ルールは Policy Service に保存され、移転時に Provisioning Service が実行。デバイスヘルスはデバイスに付随、タスクログは移転元に残留、アプリテレメトリは設定可能。

異なるテレメトリタイプには異なる所有権とコンプライアンス特性がある。単一のルールではすべてのタイプに対応できない。

帰結

利点

  • ゼロタッチソフトウェアインストール — デバイスは登録時に正しいソフトウェアを自動的に受信し、手動でのロールアウト作成や CI/CD との結合は不要です

  • デプロイ前のポリシー作成 — ソフトウェア開発者は属性ベースのターゲティングを使用して、ターゲットデバイスが存在する前に OTA ポリシーを作成しテストできます

  • アーティファクト公開とロールアウトの分離 — CI/CD パイプラインがアーティファクトを公開し、ポリシーがいつどこにデプロイするかを決定します。これらは異なるアクターが所有する別々の関心事です

  • きめ細かなマルチティア可視性 — サプライチェーンの各当事者は、自身が所有または管理するデバイスのみを正確に参照でき、Org Service の階層と IAM Identity Center の付与によって強制されます

  • 一貫した移転メカニズム — デバイスの所有権移転は、Provisioning Service を通じて ThingsBoard、hawkBit、および DotID をアトミックにオーケストレーションする単一の API コールです

  • 分離された追跡 — OTA インストールステータス（OTAForge）とライセンスカウント（TrustMint）は別々の関心事であり、独立した進化と異なるビジネスモデルを可能にします

トレードオフ

  • アプリケーション OTA には「Get」が必要 — デバイスが元の組織外のアカウントに移転した場合、新しいオーナーは OTA を再開するために独自にアプリケーションソフトウェアを「Get」する必要があります。デバイスバウンドソフトウェア（OS）は manufacturer 属性を対象とするため影響を受けません

  • ポリシーターゲティングの精度 — 属性ベースのターゲティングは、登録時の正確で一貫した属性値に依存します。デバイスが誤った model や revision で登録された場合、ポリシーは一致しない（または誤って一致する）ことになります

  • 移転のレイテンシ — 各デバイスの移転は3つのシステム（ThingsBoard、hawkBit、DotID）にまたがる補償トランザクションであり、加えて移転ルールに基づくテレメトリ移行も含まれます。多数のデバイスのバッチ移転には相当な時間がかかる場合があります

  • ライセンスポリシーの複雑さ — 開発者はリスティング作成時にライセンス発行ポリシーを定義する必要があります。不正確なポリシー設定は、時期尚早なライセンス発行やライセンス発行の欠落につながる可能性があります

  • テレメトリ移転ルール管理 — タイプ依存のテレメトリ移転ルールは運用の複雑さを増します。ルールの誤設定はデータ損失やアカウント間のデータ漏洩につながる可能性があります