AWS IoT SiteWise による設備総合効率 (OEE) の計算

はじめに

このブログ記事は、AWS IoT SiteWise での設備総合効率 (OEE) の使用に関するシリーズの第2回目です。この投稿では、AWS IoT SiteWise のネイティブ機能を使用して OEE を計算し、エンドツーエンドのソリューションとして計算値を収集、保存、変換、表示する方法を詳しく説明します。このプロセスを説明するユースケースとして、空港に設置された手荷物処理システム (BHS) を取り上げます。ユースケースの詳細については、まずこのシリーズのパート1、「AWS IoT SiteWise による総合設備効率（OEE）ガイド」をお読みください。

さらに、OEE 要素を自動化して、製薬、食品、飲料業界の製造生産ラインなど、他の多くのユースケースでこのソリューションの実装を効率化する方法についても説明します。このブログで説明されている概念を実践しやすいように、合成データを AWS IoT SiteWise にストリーミングし、本ブログで説明する計算を使用して OEE ダッシュボードを作成できるコードリポジトリも提供しています。

ユースケース

OEE の計算を掘り下げる前に、基準系として使用する例を確認しましょう。この例は BHS で、OEE 計算に必要なデータポイントは、荷物を運ぶ回転式コンベア（カルーセル）内の BHS に設置されたハードウェアから収集されます。ハードウェアは4つのセンサーで構成されています。モーター監視用の振動センサー2つ、コンベア監視用のスピードセンサー1つ、手荷物の処理量をカウントする光電センサー1つです。

ソリューションのアーキテクチャは次のとおりです。

センサーデータは、AWS パートナーの CloudRail を通じて収集および整形されます。CloudRail のソリューションを利用すると、IIoT データの収集と AWS IoT SiteWise へのストリーミングが大幅に簡素化されます。この統合は、CloudRail 管理ポータルから直接設定できます。このアーキテクチャには、センサーデータを S3 バケットを経由して他の AWS サービスで利用できるようにするための追加コンポーネントが含まれています。

AWS IoT SiteWise の前提条件

データを AWS IoT SiteWise に送信する前に、モデルを作成してそのプロパティを定義する必要があります。前述のように、次の測定値（機器からのデータストリーム）をもつ、4つのセンサーを1つのモデルにグループ化します。

Model:Carousel

Asset Name: CarouselAsset

Property {

Measurement: Photo.Distance

Measurement: Speed.PDV1

Measurement: VibrationL.Temperature

Measurement: VibrationR.Temperature

}

測定値に加えて、アセットモデルにいくつかの属性（静的データ）を追加します。属性は、OEE 計算に必要な様々な値となります。

Model:Carousel

Asset Name: CarouselAsset

Property {

Attribute: SerialNumber

Attribute: Photo.distanceBase

Attribute: Photo.distanceThold

Attribute: Speed.max_speed_alarm

Attribute: Speed.min_speed_alarm

Attribute: Vibration.max_temp_c_alarm

Attribute: Ideal_Run_Rate_5_min

}

それでは、AWS IoT SiteWise コンソールに進み、空港の BHS を表すカルーセルモデルとアセットを作成しましょう。

左側のナビゲーションメニューを開き、ビルド、モデル、モデルの作成の順に選択して、このモデルの属性と測定値を定義します。

アセットモデルの作成について詳しくは、ドキュメントをご覧ください。

OEE の計算

OEE の定義とその構成要素を見てみましょう。

OEE の標準計算式は次のとおりです。

BHS のパラメータ定義を見てみましょう。OEE パラメータの詳細については、ドキュメントをご覧ください。

• Ideal_Run_Rate: このケースの理想的な実行速度は 300 bags/hour で、これは 0.83333 bags/second に相当します。この値はシステムによって異なるため、製造元から入手するか、現場での観測性能に基づいて取得する必要があります。

Availability

Availability = Run_time/(Run_time + Down_time)

BHSには4つのセンサーがあり、そのセンサーのどの測定値（温度、振動など）を計算に含めるかを定義する必要があります。2つの振動センサーからの温度（摂氏）と速度センサーからの回転式コンベアの速度 (m/s) によって、稼働状況が決まります。

正しく動作するための許容値は、アセットモデルの以下の属性に基づいています。

Vibration.max_temp_c_alarm = 50

Speed.min_speed_alarm = 28

Speed.max_speed_alarm = 32

それでは、BHS の現在の状態を次のような数値コードで提供するデータ変換 Equipment_State を定義してみましょう。
1024 – マシンはアイドル状態です
1020 – システムの異常動作、高温、または定義された正常範囲外の速度値などの障害
1000 – 計画的な停止
1111 – 通常運転

この簡略化されたユースケースでは BHS のアイドル状態は定義されていませんが、他のデータストリームを AWS IoT SiteWise に統合することで、例えば、プログラマブルロジックコントローラー (PLC) や、人間のオペレーターがシステムのアイドル状態かどうかを入力するシステムから情報を登録することも可能です。

変換を追加するには、AWS IoT SiteWise コンソールでモデルに移動し、編集を選択します。変換の定義までスクロールし、名前、データ型 (ダブル) を入力し、それぞれのフィールドに次の数式を入力します。

Equipment_state =

if((Speed.PDV1>Speed.max_speed_alarm) or (Speed.PDV1<Speed.min_speed_alarm) or (VibrationL.Temperature>Vibration.max_temp_c_alarm) or (VibrationR.temperature>Vibration.max_temp_c_alarm),1020).elif(eq(Speed.PDV1,0),1000,1111)

数式は、コンソールに入力すると次のようになります。UI は、数式の構築を支援するため、モデルで既に定義されている属性や測定値が提案表示されます。

Equipment_State の定義が完了したら、BHS の他の状態を捕捉するため以下のように派生する変換を作成します。変換は他の変換を参照できます。

次のメトリクスを定義して、マシンデータを時系列で集計します。各メトリクスの時間間隔は同じにしてください。

Fault_Time = statetime(Fault) – The machine’s total fault time (in seconds)

Stop_Time = statetime(Stop) – The machine’s total planned stop time (in seconds)

Run_Time = statetime(Running) – The machine’s total time (in seconds) running without issue.

Down_Time = Idle_Time + Fault_Time + Stop_Time – The machine’s total downtime

モデルのメトリクスの定義は次のようになります。

Quality

Quality = Successes / (Successes + Failures)

ここでは、何が成功と失敗を構成するのかを定義する必要があります。このケースでの計測単位はバッグ数ですが、バッグの個数計数が成功した場合とそうでない場合をどのように定義すれば良いでしょうか。BHS の4つのセンサーから得られる測定値とデータを使用します。

バッグの数は、光電センサーが提供している距離を見てカウントされます。つまり、バンドを通過する物体があると、センサーは「ベース」距離よりも小さい距離を報告することを利用します。これはバッグの通過数を算出する簡単な方法ですが、同時に、測定の精度に影響を与えうる複数の条件を考慮する必要があります。

品質計算には以下のモデル属性を使用します。

Photo.distanceBase = 108

Photo.distanceThold = 0.1

Photo.DistanceBase は、センサーの前に物体がないときにセンサーによって報告される距離です。この値は定期的に校正して調整する必要がある場合があります。振動や位置ずれなどの要因により、バッグが誤検出される可能性があるためです。
Photo.DistanceThold は、センサーの感度の閾値を定義するのに使用されます。これにより、ゴミや小さな物体（バッグのアタッチメントやベルトなど）が通常のバッグのようにカウントされるのを防ぐことができます。

次に、バッグカウント用に2つの変換を設定します。

Bag_Count = if(Photo.Distance < Photo.distanceBase,1,0)

Dubious_Bag_Count = if((gt(Photo.Distance,Photo.distanceBase*(1-Photo.distanceThold)) and lt(Photo.Distance,Photo.distanceBase*0.95)) or (Speed.PDV1>Speed.max_speed_alarm) or (Photo.Distance>Photo.distanceBase),1,0)

Bag_Count は光電センサーの前を通過する全てのバッグをカウントし、Dubious_Bag_Count は次の2つの異常と判定する条件下でバッグとして検出されたオブジェクトをカウントします。

1. 検出される距離が基準距離の 95% から 90% の範囲に入るものです。これは、小さな物体や測定値のごくわずかな変動、振動による変化、またはセンサーが正しく取り付けられていないことを考慮したものです。
2. 回転式コンベアの速度が定義された制限を超えた時にカウントされたバッグです。この状態では、センサーは回転式コンベア上で隣接するバッグをカウントできない可能性があります。

注:上記の条件は単純なルールであり、より良い結果を得るには、ベースの距離と閾値をフィールドデータで検証および分析することで適切な値を設定する必要があります。

成功と失敗をメトリクスとして以下のように定義します。

Successes = sum(Bag_Count) – sum(Dubious_Bag_Count)

Failures = sum(Dubious_Bag_Count)

最後に、OEE Quality をメトリクスとして以下のように定義します。

Quality = Successes / (Successes + Failures)

他のすべてのメトリクス定義と同じ時間間隔を使用することを忘れないでください。

Performance

Performance = ((Successes + Failures) / Run_Time) / Ideal_Run_Rate

Quality の計算から成功と失敗のメトリクスを、Availability からの Run_Time のメトリクスを取得できます。従って、必要なのは ideal_run_rate_5_min です。このシステムでは、この値は 300 bags/hour = 0.0833333 bags/second となります。

OEE Value

Availability、Quality、Performance が決まったので、OEE の最後のメトリクスを次のように定義します。

OEE = Availability * Quality * Performance

変換とメトリクスの定義を簡素化

変換とメトリクスとして定義される OEE コンポーネントを、AWS コンソールを使用する代わりにプログラムで定義することもできます。これは、Equipment_State の変換や Dubious_Bag_Count の変換のように複数の変数を含む複雑な式がある場合に特に便利です。また、自動化されたソリューションは手動ソリューションよりもエラーが発生しにくく、複数の環境で一貫して構成できます。Python 用 AWS SDK (Boto3) を使用してこれを行う方法を見てみましょう。

まず、変換/メトリクス計算で参照する測定値と属性のプロパティ ID、およびモデル ID を特定します。

次に、メトリクス/変換の JSON を定義します。例えば、BHS の Equipment_State を計算する新しい変換を作成するには、以下の属性が必要です。

Vibration.max_temp_c_alarm

Speed.max_speed_alarm

Speed.min_speed_alarm

And the following measurements:

VibrationL.Temperature

VibrationR.Temperature

Speed.PDV1

以下に示す構造に従ってファイルを作成します。必ず、propertyId を置き換えて、equipment_state.json という名前で保存してください。

{
     "name": "Equipment_State",
     "dataType": "DOUBLE",
     "type": {
       "transform": {
         "expression": "if((var_speedpdv1>var_speedmax_speed_alarm) or (var_speedpdv1<var_speedmin_speed_alarm) or (var_vibrationltemperature>var_vibrationmax_temp_c_alarm) or (var_vibrationrtemperature>var_vibrationmax_temp_c_alarm),1020).elif(eq(var_speedpdv1,0),1000,1111)",
         "variables": [
           {
             "name": "var_vibrationrtemperature",
             "value": {
               "propertyId": "b9554855-b50f-4b56-a5f2-572fbd1a8967"
             }
           },
           {
             "name": "var_vibrationltemperature",
             "value": {
               "propertyId": "e3f1c4e0-a05c-4652-b640-7e3402e8d6a1"
             }
           },
           {
             "name": "var_vibrationmax_temp_c_alarm",
             "value": {
               "propertyId": "f54e16fd-dd9f-46b4-b8b2-c411cdef79a2"
             }
           },
           {
             "name": "var_speedpdv1",
             "value": {
               "propertyId": "d17d07c7-442d-4897-911b-4b267519ae3d"
             }
           },
           {
             "name": "var_speedmin_speed_alarm",
             "value": {
               "propertyId": "7a927051-a569-41c0-974f-7b7290d7e73c"
             }
           },
           {
             "name": "var_speedmax_speed_alarm",
             "value": {
               "propertyId": "0897a3b4-1c52-4e80-80fc-0a632e09da7e"
             }
           }
         ]
       }
     }
}

主となる expression は次のとおりです。

if((var_speedpdv1>var_speedmax_speed_alarm) or (var_speedpdv1<var_speedmin_speed_alarm) or (var_vibrationltemperature>var_vibrationmax_temp_c_alarm) or (var_vibrationrtemperature>var_vibrationmax_temp_c_alarm),1020).elif(eq(var_speedpdv1,0),1000,1111)

update_asset_model_sitewise.py というスクリプトの入手と、AWS IoT SiteWise にデータをストリーミングする方法の詳細については、こちらのパブリックリポジトリにアクセスしてください。

次に、モデル ID と以前に定義したファイルの名前を引数として、次のスクリプトを実行します。

#python3 update_asset_model_sitewise.py --assetModelId [Asset Model ID] --property_file [JSON File defining the new property] --region [AWS Region]

スクリプトが正常な応答を返した後、作成した新しいプロパティ ID は、前述のように AWS コンソールから直接取得できます。もしくは、AWS CLI を使用して更新されたモデル定義をクエリし、jq ユーティリティを使用して結果をフィルタリングすることでも取得できます。

#aws iotsitewise describe-asset-model --asset-model-id [model ID] | jq .'assetModelProperties[] | select(.name=="Equipment_State_API")'.id

その後、他の変換やメトリクスについても同じプロセスを繰り返して、OEE の計算に必要なすべてのコンポーネントを作成できます。

AWS IoT SiteWise アセットモデルの更新の詳細については、API リファレンスをご覧ください。

まとめ

このブログ記事では、AWS IoT SiteWise のネイティブ機能を使用して、実際のシナリオのセンサーデータを使用して OEE を計算し、物理システムから洞察に満ちた情報を取得する方法について説明しました。パブリックリポジトリで入手可能なデータを特定しながら、OEE の主要な要素である Availability、Quality、Performance を定義しました。最後に、計算とその自動化方法について詳しく説明しました。

読者の次のアクションとして、ここで紹介した内容をさらに発展させて、OEE 計算プロセスを独自のユースケースに適用すること、さらに、提供されている自動化ツールを使用して、産業システムを正確に監視するのに役立つデータ生成を簡素化および合理化していくことをお勧めします。

使用できるデータがない場合は、このパブリックリポジトリに概説されている手順に従い合成データで AWS IoT SiteWise を使い、OEE が提供する洞察に満ちた情報を発見することをお勧めします。

著者について

この記事は Calculating Overall Equipment Effectiveness (OEE) with AWS IoT SiteWise の日本語訳です。IoT Consultant の正村 雄介が翻訳しました。