Cloud Service
AWS IoT SiteWise
産業設備のデータを収集し、資産モデルとして構造化して蓄積・可視化するマネージドな産業IoTサービス。
- 1.工場やプラントの設備データを収集し、資産モデルで構造化して時系列に蓄積する産業IoTサービス。
- 2.ゲートウェイでOPC-UAなどの産業プロトコルからデータを取り込み、計測式メトリクスで集計できる。
- 3.蓄積したデータはSiteWise MonitorのダッシュボードやAPIで可視化・分析できる。
解決する課題
- 工場やプラントの設備データが機器ごとにバラバラな形式・プロトコルで散在し、横断的に集約・分析できない
- センサーから上がる時系列データを構造化し、設備の階層(ライン、装置、部品)に対応づけて意味のある形で扱いたい
- 稼働状況やKPIを把握するためのダッシュボードや集計を、独自開発の負担なく短期間で用意したい
主要概念と用語
- 資産(アセット): 物理的な設備や機器をデジタル上で表現した単位。センサーや装置を1つの資産として扱う
- アセットモデル: 資産の共通テンプレート。プロパティや階層関係を定義し、同種の設備に再利用する
- プロパティ: 資産が持つ値の定義。生データを受け取るメジャーメント、定数のアトリビュート、計算式のトランスフォームや時間集計のメトリクスがある
- アセット階層: 資産同士の親子関係。ラインの下に装置、装置の下に部品といった構造を表現する
- ゲートウェイ: 現場のエッジで動作し、産業プロトコルからデータを収集してクラウドへ送る仕組み
- OPC-UA: 産業機器で広く使われるデータ通信の標準プロトコル。ゲートウェイの主要な取り込み元になる
- SiteWise Monitor: 収集したデータを表示するダッシュボードを、コード不要で作成できる機能
- ポータル / プロジェクト: SiteWise Monitorでダッシュボードを整理し、現場担当者と共有する単位
仕様・制限・クォータ
- フルマネージドで提供され、データの取り込み層・蓄積層・可視化層をサービス側が運用する。利用者はサーバー管理を意識しない
- データはアセットモデルとプロパティで構造化され、生の計測値だけでなく変換式や時間ウィンドウ集計を定義して派生値を持てる
- 取り込みはエッジのゲートウェイ経由のほか、APIによる直接書き込みや他のIoTサービスからの連携にも対応する
- 時系列データには保持の考え方があり、直近データ向けの層と長期保存向けの層を使い分けられる
- アセット数、プロパティ数、API呼び出しレートなどには上限がある。具体的な数値は変動するため、最新値は公式ドキュメントで確認する
内部の仕組み
AWS IoT SiteWiseは、現場のデータ取り込みからクラウドでの蓄積・可視化までを一連の流れとして提供します。エッジに配置したゲートウェイがOPC-UAなどの産業プロトコルで機器と通信し、計測値を収集してクラウドへ送ります。送られたデータはアセットモデルで定義した構造に従って格納され、単なる数値の羅列ではなく、どの設備のどのプロパティの値かが意味づけされた状態で蓄積されます。
プロパティには、生データをそのまま受け取るメジャーメントのほか、複数の値から計算するトランスフォームや、一定の時間ウィンドウで平均・合計・最大などを求めるメトリクスを定義できます。これにより、稼働率や生産量といった指標をサービス側で自動計算させられます。蓄積された時系列データは、直近のアクセスに適した層と長期保存に適した層に整理され、用途に応じて参照されます。可視化はSiteWise Monitorのダッシュボード、またはAPI経由で外部の分析・可視化ツールと連携して行います。
同種の設備が多い現場では、まずアセットモデルをテンプレートとして設計し、そこから個々の資産を量産するのが定石です。プロパティや階層をモデル側に集約しておくと、設備が増えても一貫した構造で取り込めて運用が安定します。
設計パターン / ベストプラクティス
- 設備の物理的な構造(ライン、装置、部品)をアセット階層として表現し、現場の実態に沿ったモデルを作る
- 稼働率や生産量などの指標は、アプリ側で都度計算せずトランスフォームやメトリクスでサービスに計算させる
- エッジでの前処理やバッファリングにゲートウェイを活用し、通信が途切れても取りこぼしを抑える
- 現場担当者向けの可視化はSiteWise Monitorで素早く用意し、高度な分析は他の分析サービスへデータを連携する
- アラート条件は、しきい値を超えた値を検知して通知やワークフローへつなげる設計にする
運用・監視
- CloudWatchでデータ取り込みのスループットやAPIのエラー、スロットリングを監視する
- ゲートウェイの稼働状態と通信状況を確認し、現場とクラウド間のデータ欠落を早期に検知する
- アセットモデルの変更が既存の資産に与える影響を把握し、プロパティ追加や式の修正は段階的に適用する
- 取り込み失敗時に備え、エッジ側のバッファや再送、エラーハンドリングを設計しておく
コスト
- 主なコストはデータの取り込み量、蓄積しているデータ量、プロパティの計算処理、API呼び出し、ダッシュボードの利用などの組み合わせで構成される
- メトリクスやトランスフォームの計算頻度・件数が増えるとコストに影響するため、本当に必要な集計に絞る
- 直近データと長期保存データの層を使い分け、高速層に不要に長くデータを置かないようにする
- 料金は変動するため、最新の単価は公式の料金ページで確認する
セキュリティ
- アクセス制御はIAMで行い、最小権限の原則に従って資産やプロパティへの操作権限を付与する
- 保存データはKMSで暗号化され、通信はTLSで保護される
- SiteWise MonitorのポータルへのアクセスはIAM Identity Centerなどの認証と連携し、利用者ごとに参照範囲を制御する
- 操作の監査にはCloudTrailを利用し、誰がいつ何を操作したかを記録する
Well-Architected の観点
- 運用上の優秀性: 設備データの収集・構造化・可視化をマネージドに提供し、産業IoT基盤の自前構築と運用の負担を減らす
- 信頼性: エッジのゲートウェイによるバッファリングと再送で、通信断時のデータ取りこぼしを抑える
- パフォーマンス効率: 直近データと長期データの層分けにより、リアルタイム参照と過去分析の双方を効率良く扱う
試験で問われるポイント
- 工場やプラントの産業設備データを収集・モデル化・可視化する用途ならIoT SiteWiseを選ぶ
- OPC-UAなどの産業プロトコルからの取り込みはエッジのゲートウェイ経由で行う点を押さえる
- 生データだけでなく、アセットモデルとメトリクス/トランスフォームでKPIを構造化・自動計算できる
- コード不要のダッシュボードはSiteWise Monitorである点を覚える
関連サービス・比較
| 観点 | IoT SiteWise | IoT Core |
|---|---|---|
| 主な役割 | 産業設備データの収集・モデル化・可視化 | デバイスとクラウドのメッセージ仲介 |
| データの扱い | アセットモデルで構造化し時系列に蓄積 | メッセージを受け取り他サービスへ転送 |
| 取り込み元 | OPC-UAなどの産業プロトコル中心 | MQTTなどのIoTプロトコル中心 |
| 可視化 | SiteWise Monitorで標準提供 | 可視化は別サービスで構成 |
ハンズオン / CLI例
# アセットモデルを作成(温度プロパティを持つテンプレート)
aws iotsitewise create-asset-model \
--asset-model-name "PumpModel" \
--asset-model-properties '[{"name":"Temperature","dataType":"DOUBLE","type":{"measurement":{}}}]'
# モデルから資産を作成
aws iotsitewise create-asset \
--asset-name "Pump-001" \
--asset-model-id <asset-model-id>
# プロパティの直近の値を取得
aws iotsitewise get-asset-property-value \
--asset-id <asset-id> \
--property-id <property-id>
AWS Service
AWS IoT SiteWiseを実務で読む
TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。
解決すること
IoT
比較で見る軸
クラウド: AWS / カテゴリ: IoT / 難易度: intermediate
導入後に効く点
ゲートウェイでOPC-UAなどの産業プロトコルからデータを取り込み、計測式メトリクスで集計できる。
先に潰すリスク
サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。
- クラウド
- AWS
- カテゴリ
- IoT
- 難易度
- intermediate
- 関連資格
- SAA-C03
- 設計柱
- operational
判断チェックリスト
- 自社の用途が「IoT / operational」に近いか確認する。
- 強みである「工場やプラントの設備データを収集し、資産モデルで構造化して時系列に蓄積する産業IoTサービス。」が本当に評価軸になるか確認する。
- 注意点の「サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。」を運用で吸収できるか確認する。
- 公開値や仕様値は、対象プラン・対象機種・対象リージョンまで確認する。
- 既存システム、ID、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
- 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。