デバイスプロファイル技術専門委員会

IoTアプリケーションを構築するためのモータのアプリケーションプロファイルの提案
報告書

2018 12月 25日 発行

デバイスプロファイル技術専門委員会

モータのアプリケーションプロファイルとIoTアプリケーションの検討

来
Ver.

日付

改訂箇所

1.0

2018年12月25日

全頁

歴
改定内容

第1版の発行目次
1

はじめに ······················································································································· 4

1.1

本報告書の目的 ············································································································· 4

1.2

デバイスプロファイル委員会の従来の活動 ········································································· 4

1.3

スマートマニュファクチャリング関連の活動と本委員会のモータのアプリケーションプロファイルの検討 ································································································································ 52モータのアプリケーションプロファイルとIoTアプリケーションの検討の目的とその出口 ·············· 6

2.1

IoTの本質とは ·············································································································· 6

2.2

IoTアプリケーションの課題····························································································· 6

2.3

検討のためのアプローチ ································································································· 6

2.4

前提としているシステム ································································································· 6

2.5

検討の出口（目標） ······································································································· 8

2.6

アプリケーションのメリット ··························································································· 8

2.7

業界（モータメーカ）間の協調領域 ·················································································· 93

アプリケーションの種類 ·································································································· 9

4

既存のモータのプロファイルの規格と本委員会が検討するアプリケーションプロファイルとの比較10

4.1

既存のモータのプロファイルの規格 ················································································· 10

4.2

本委員会が検討するアプリケーションプロファイル ···························································· 104.2.1

可変速駆動システム（PDS）関連規格の現状 ································································ 11

4.3

既存のデバイスプロファイルとそのアプリケーション ························································· 14

4.4

既存のデバイスプロファイルとアプリケーションプロファイルとの比較 ································· 15

5

アプリケーションの検討 ································································································· 17

5.1

IoTアプリケーション実行時のシステム構成 ······································································· 17

5.2

PLCを介して上位PCがモータデータを取得する方式 ··························································· 17

5.2.1

データ取得方式の分類 ······························································································ 175.2.2

方式１：ファンクションブロックを使うPLCを介した通信方式 ········································ 195.2.3

方式２：ORiNを利用するPLCを介した通信方式 ···························································· 20

5.2.4

方式３：インタフェースを利用する通信基板による通信方式 ··········································· 215.2.5

方式４：オープンプラットフォームを利用するPLCを介した通信方式 ······························· 22

5.3

モータのIoTアプリケーション（例の１）：エネルギー管理 ·················································· 23

5.4

モータのIoTアプリケーション（例の２）：保守 ································································· 25

5.4.1

事後保全のアプリケーション ····················································································· 27

5.4.2

時間基準予防保全 ···································································································· 27

5.4.3

状態基準予防保全 ···································································································· 27

5.4.4

保守アプリケーションの機能 ····················································································· 28

5.5モータのIoTアプリケーション（例の３）：工場内の稼働管理 ··············································· 29

6

今後の進め方 ················································································································ 31

6.1

今後の課題 ·················································································································· 31

6.2

今後の進め方 ··············································································································· 31

報告書：デバイスプロファイル技術専門委員会

1

はじめに

1.1

本報告書の目的

モータを利用するドライブシステムでは、従来よりネットワーク団体やIEC、ISOなどが規格を定め、そのプロファイルを規定している。それらのプロファイルには、デバイスプロファイルとLCM（ライフサイクルマネジメント）のためのプロファイルとがある。デバイスプロファイルは、ドライブシステムを制御するためのプロファイルであり、モータの回転のトルク、加速度、速度を制御するためのデータである。また、LCMプロファイルでは、モータを工場に導入してから保守までのLCMに必要なモータに関するデータを定めている。
一方、工場の製造ラインをIoTを利用して運用するアプリケーションでは、モータから取得して利用するデータの種類がこれらのプロファイルとは異なる。本書ではIoTを利用するアプリケーションを構築するために、プロファイルを定義することを提案する。さらに、メーカが異なっても、また、モータの種類が異なっても共通のアプリケーションが利用できるようにすることを図り、そのためのアプリケーション
プロファイルの規格化を提案する。各社のモータのデータが共通に利用できることが、ユーザメリットであり、さらにここで提案するアプリケーションプロファイルが広く利用されることにつながり、IoTを利用したビジネスが広がることを期待する。
以下、本文書では、プロファイルの種類を次の３種類に分類し用語を統一する。
-

デバイスプロファイル
モータを制御するために使用されるデータの規定。PDS（可変速駆動システム、PDS：Power
Drive Systemとも呼ぶ）と上位のコントローラ間とで通信するためのデータの規定もデバイスプロ
ファイルの中に含む。

-

LCMプロファイル
LCMのためのデータの規定。

-

アプリケーションプロファイル
IoTを利用するアプリケーションで利用するためのデータの規定

1.2

デバイスプロファイル委員会の従来の活動

デバイスプロファイル技術専門委員会（以下、デバイスプロファイル委員会）は、制御盤内に使用される機器間の通信の規格を検討するために設置された。
本委員会は日本電機工業会（以下、JEMA）の技術専門委員会の中の低圧開閉保護機器グループに属し、これまで通信規格と電気製品の電子辞書（製品の通信とLCMプロファイル）について検討して来た。その内容は次のようなものである。
（１）通信規格の制定、確認IEC 62026シリーズ（低圧開閉装置及び制御装置−. コントローラ−装置間インタフェース（CDI））.
（２）デバイスプロファイル全般の内容検討
IEC 61915シリーズ（低圧スイッチギヤと制御装置 -ネットワーク化された産業機器のデバイスプ
ロファイル）（３）電子辞書（CDD：Common Data Dictionary）規格の内容検討
IEC 62683（低圧スイッチギヤと制御装置 -情報交換のための製品データと特性）
また、上記と関連する次のテーマでのIECの動きについて情報収集して来た。
4

報告書：デバイスプロファイル技術専門委員会

Digital Factory（デジタルファクトリー）
Energy Efficiency（エネルギー効率）
1.3

スマートマニュファクチャリング関連の活動と本委員会のモータのアプリケーションプロファイルの検討
JEMAのスマートマニュファクチャリング特別委員会は、第4次産業革命への対応方法を示すという日本
電機工業会の会員のニーズに応えるために、2015年8月に発足した。スマートマニュファクチャリング特別委員会は、FBM（Flexible Business and Manufacturing）を提案し、2030年の製造業のあり方を描いた。また、FBMのモデルや、FBMの具体例の検討（制御盤2030、及び、製造業のサービス化）を検討して来た。
このようなIoTによるビジネス変革という上位からの検討とともに、実際の製品に適用するIoTアプリケーションという下からの検討も必要になる。今回、本委員会は下からのアプローチとして、モータのアプ
リケーションプロファイルとIoTアプリケーションを検討することとした。従来から通信や電子辞書を検討して来た本委員会では、これらの活動と共通するテーマを持つモータのアプリケーションプロファイルとIoTアプリケーションの検討が可能であると考えた。

5

報告書：デバイスプロファイル技術専門委員会

2

モータのアプリケーションプロファイルとIoTアプリケーションの検討の目的とその出口

2.1

IoTの本質とは

IoTについて検討している様々な製品や実証試験を俯瞰すると、IoTとはデータの収集、分析、利用に関している。データ収集時のシーン、フェーズ、場所、周辺機器、用途によってデータの種類が異なり、そこで得られるデータは、場合によってデータの品質が異なっている。
OT/IT（OT: Operational Technology）で得られたデータを分析する段階では、様々なデータ解析手法と技術が統合される。従来未解決だった課題に対して、データを利用してその解決を目指し、次の利用段階
へとデータを送り、各々の利用段階でデータが共有される。
IoTのアプリケーションの開発においては、概念的なIoTによる課題の解決をより具体的にして理解を深めるため、実証試験等によりビジネスの実現を図っている。
2.2

IoTアプリケーションの課題

IoTアプリケーションを実現するためには、データ取得に関して次のような点を決めて行くことが必要となる。
- どんなデータを得るのか？
- いつデータを得るのか？
- データはどこから取得するのか？
- データは何のために利用されるのか？
データ（データとして定義されるデータの集まり：Semantics）の意味を明確にするため、データの名前、タイプ、単位、品質などを定義する必要がある。また、データを複数のアプリケーションで利用するために、ID、インタフェース、プロトコルなどを定義する必要がある。
2.3

検討のためのアプローチ

本委員会で対象とする領域に適したアプローチが必要である。そこでは、アプリケーションの代表的な例を挙げ、価値（ユーザメリット）を実例で示し、アプリケーションに関する疑問点に答え、課題を洗い出し、方向性を示す。ここで検討する対象の領域を本委員会に参加する委員の専門領域に関連した分野とし、デバイスプロファイル、電子辞書のLCMに関連した分野とする。対象とする製品は、JEMAの代表的な取扱い製品であるモータとすることとした。IoTアプリケーションを選定する際には、机上で仕様の検討が可能な一般的なアプリケーションの範囲とすることとした。
以上のようなアプローチで、企業間に共通するテーマを持つ協調領域では、仕様の標準化を目指す。企
業別に個別に検討すべき内容は、企業間の競争領域として仕様の多様化を図れる仕組みを考慮する。
以上のアプローチにより、これまで検討されて来なかった領域に道を開き、将来はより汎用的な仕様へと展開することを期待する。
2.4

前提としているシステム

図2-1に示すように、本検討で前提にしているシステムは、工場内に設置したパソコン上でアプリケー
ションが動作し、工場内のネットワークを介してモータのコントローラと本体のセットがパソコンに接続し、モータのデータを利用してユーザにメリットを提供するシステムである。
モータのデータを利用したIoTアプリケーション次のようの種類に分類されると考えられる。
6

報告書：デバイスプロファイル技術専門委員会- 工程・進捗管理- 生産管理- ボトルネック検出・設備効率向上のためのモニタリング- エネルギー管理（電力・熱エネルギー）- 保守・メンテナンス

図2-1

モータのアプリケーションプロファイルとIoTアプリケーションの検討とその出口

このようなアプリケーションの仕様を検討することにより、モータから取得すべきデータの仕様が決まる。アプリケーションの仕様を具体的にすると、モータのデータ仕様もさらに具体的になる。このようにITを利用してモータから取得すべきデータをここで、モータのアプリケーションプロファイルと呼ぶ。

7

報告書：デバイスプロファイル技術専門委員会

2.5

検討の出口（目標）

以上のようなモータのデータを利用したアプリケーションにおいて、検討の出口（目標）として置いた
項目を図2-1に白抜き字で示す。アプリケーションの仕様検討とそのアプリケーションを実現するためのプロファイルを提案することを目標とする。将来、企業の個別の開発によりサービスビジネスを生み出すことを念頭に置いている。さらに、工業データの所有権（ユーザの所有権とメーカのデータ所有権）を尊重し、データの所有権が守られるような配慮が必要である。ここでは、メーカやモータの種類が異なっても、さらに、ネットワークの種類が異なっても同じ形式のモータデータが同じ品質で取得できることを目標とする。
一方、アプリケーションを具体的に検討して行くと、モータやアプリケーションの種類により、プロフ
ァイルの仕様が個別に必要になる場合も予想されるが、ここでの最初の一歩として、協調領域として検討
でき、各社に共通するアプリケーションとプロファイルに範囲を絞って提案する。
現在、世界のIoTの活用をめざす団体が、新しいビジネスを創生しようとする動きがある。いずれの団
体も、テストベッドや実証実験の場を作り、新たなビジネスのユースケースを生もうとする活動である。
モータデータを利用するアプリケーションは、今後、色々な団体から提案されて来ると予想される。工業会などが協調領域で課題を検討する場で、このような検討をスタートさせ、世界の流れに追いついて行きたいと考える。将来の理想像を設定することにより、従来は検討できなかった検討を実施することが可能性になると考える。
さらに、最終的な出口として、IoTアプリケーションのためのモータのアプリケーションプロファイル
をIEC規格などの形で標準化することを設定する。
ここではモータ単体からのデータだけでなく、モータ周辺の電流センサ、振動センサなどの外付けのセンサや空冷用のファンを含むプロファイルの検討も実施する。
2.6

アプリケーションのメリット

ここで検討するアプリケーショのメリットをベンダやユーザなどのそれぞれの立場から見てまとめると
次のようになる。
モータベンダにとっては、モータの標準化されたデータを提供することだけが必要となり、ユーザごとの個別対応が不要となる。また、IoTアプリケーションに対応できる付加価値のあるモータを提供することができる。
モータを選定する技術者にとっては、モータの仕様がベンダに関わらず共通となり、選定がしやすくなる。
ユーザにとっては、システムを設計、構築した際に得られたデータがシステムの改変後もそのまま継承できる。ユーザ自らがデータを定義、収集して、アプリケーションの入力データとする作業が不要となる。
モータに関連するサービスの提供者には、標準化されたインタフェースが前提となり、サービス提供者
が独自に構築する価値の創造に集中できる。
制御システム提供者は標準化されたインタフェースを持つだけで良く、個別対応が不要になる。
IoTアプリケーションの提案に対してユーザから意見を得るためには、アプリケーションのメリットを分かり易く提示することが必要である。そのために、アプリケーションの機能をビジュアルに示したり、実証実験で評価してもらうことが必要になる。
8

報告書：デバイスプロファイル技術専門委員会

2.7

業界（モータメーカ）間の協調領域

モータのアプリケーションの協調領域と競争領域を分類すると次のような項目が考えられる。
（１）モータのIoTアプリケーションの協調領域
・モータのIoTアプリケーションの実現可能性の検証
・モータIoTのアプリケーションのメリットに対するユーザの理解の場の提供
・モータのアプリケーションプロファイルの日本発のIEC規格化
・ユーザとメーカをつなぐクラウドに要求される事項の検討（２）モータのIoTアプリケーションの競争領域
・差別化：メーカに独自なモータ性能、機能の提供・メーカによるサービスビジネスの実現
・IoTアプリケーションが利用できる、付加価値のあるモータの提供

3

アプリケーションの種類
モータのデータを利用してどのようなアプリケーションが可能になるかを挙げる作業は、創造性が必要とされる作業であり、アプリケーションを漏れなく挙げるための方法論はない。
アプリケーションの種類を挙げる作業で、FILED system （ 注１ ） を紹介する資料 （ 注２ ） の中に、FILED
systemがどのようなアプリケーションを提供できるかを挙げた例がある。ここに示された「現場で役立つ
アプリケーション」には、「予防保全」「稼働率向上、高効率生産」「動作の最適化」「アダプティブコ
ントロール」「高度なトレーサビリティ」「かゆい所に手が届くミニアプリ」がある。
このようなアプリケーションの中で、本委員会では、委員の専門範囲から具体的な仕様まで検討可能なアプリケーションとして、表3-1に示す3つのアプリケーションに絞った。それらは、「保守」「工場内の稼働上状況表示」「エネルギー監視」である。これらはFIELD systemの資料の中で例示されたアプリケー
ションの分類と比較した。これらの比較から、本委員会で検討した3つのアプリケーションの範囲がIoTア
プリケーションの中で、特に偏ってはいないと考えることができる。

（注１）FUNUCが提案するIoTとAIにより製造現場を賢くしようとするシステム。 FIELD system (FANUCIntelligent Edge Link & Drive system)（注２）http://www.meti.go.jp/committee/sankoushin/shojo/johokeizai/bunsan_senryaku_wg/pdf/003_06_00.pdf

9報告書：デバイスプロファイル技術専門委員会

表 3-1

IoT アプリケーションの種類（注１）

保守

予防保全

本委員会で検討した
IoTアプリケーション
保守ソフトウェア

稼働率向上

稼働率向上、高効率生産

工場内の稼働状況表示

最適な稼働

動作の最適化

エネルギー監視制御

アダプティブコントロール-

トレーサビリティ

高度なトレーサビリティ-

アプリ開発効率向上

かゆい所に手が届くミニアプリ-

アプリケーションの分類

IoTアプリケーションの例（注）FANUC FIELD System 資料に一部追加して作成した。

4

既存のモータのプロファイルの規格と本委員会が検討するアプリケーションプロファイルとの比較

4.1

既存のモータのプロファイルの規格第１章でも簡単に述べたが、プロファイルには次の２種類がある。
（１）デバイスプロファイル（Devicd Profile）
モータの可変速駆動システムのために定められたプロファイルで、試運転・運転・メンテナンス（Commission/Operation/Maintenance）の時に使うモータ制御で、主にモータの位置、速度、加速度を制御するために使用される標準化されたプロファイルである。動的なデータであり、モータの挙動によりデータが変化する。また、可変速駆動システムと上位のコントローラ間の通信に使用されるデータについても規定している。
（２）LCMプロファイル（電子辞書CDD:Common Data Dictionary）におけるプロパティ項目のリスト）
製品のLCMに関わるデータを示し、製品計画（製造ラインの計画）、設計、製品の選定から廃棄までのすべてフェーズに利用する静的なデータである。
試運転・運転・メンテナンス時に使うモータ制御の目的には、情報不足である。
モータのデバイスプロファイルは既に産業用ネットワークを推進するコンソーシアム、団体、企業などが提供している。また、LCMプロファイルもIECやヨーロッパの規格で規定されている。
4.2

本委員会が検討するアプリケーションプロファイル

当委員会が提案するアプリケーションプロファイルは、表4-1に点線で囲んだ領域に示すIoTアプリケー
ションに必要なアプリケーションプロファイルである。既存のデバイスプロファイルがモータのトルク、加速度、速度を制御するにために使うプロファイルであるのに対して、アプリケションプロファイルとは、工場内に設置したパソコン上で動作するアプリケーションのために必要なデータに関して規定するアプリ
ケーションプロファイルである。

10

報告書：デバイスプロファイル技術専門委員会

表4-1
No .

プロファイルの種類と目的

プロファイルの種類
デバイス プロファイル

1 (De vice Pro fileまたは、Commu nication Prof ile）

アプリケーションプロファイル
2（Aplication Prof ile）

LCMプロファイル
3 （ライフサイクルマ ネジメントのためのプロファイル）

具体例

用途の説明

・ IEC 618 00 -7シリーズ（PDSに関する共通
インタフェース および
プロファイル仕様）
な どで 定める
プロファイル・ モータの状態監視や制御のために使う
・ アプリケーションを限定しな いため、な るべく広い用途に適するようにな るべく広範囲のデータを設定で きることを目指す・ 電力監視のアプリケーションのためのプロファイル（電力・運転・停止データ）
・ 保守のアプリケーションのためのプロファイル（製品ID、運転・ 停止・故障
な ど）・ アプリケーションのために、必要な データと形式を指定（ 電力監視アプリケーションで 5 分～6 分に１回サンプリングする電力、電流、回転数な ど）・ IEC電子辞書
ECl@ssなど

・ 工場の製造設備のライフサイクル
マ ネジメントに利用するため、保守用部品を、メーカーによな らい共通のプロパティを使って 選定する

：本委員会で検討するプロファイル
4.2.1
4.2.1.1

可変速駆動システム（PDS）関連規格の現状
デバイスプロファイルの成立

図4-1に既存のモータのプロファイル規格の成立の経緯について示す。ISO 15754-1にプロファイルの定義が記載されている。このISO 15754-1がプロファイルに関する規格の出発点になっている。

プロファイルの定義：ISO 15754-1
・デバイスプロファイル（Device Profile）-通信プロファイル（Communication Profile）
を含むもの-通信プロファイルを含まないもの
図4-1

規定の
具体化

具体的な規定◆各種の通信コンソーシアムのプロファイル◆PDS（モータ可変速駆動システム）のプロファイル

既存のモータのプロファイル規格成立の経緯

11報告書：デバイスプロファイル技術専門委員会

4.2.1.2

可変速駆動システム（PDS）に関するIEC規格

図4-2、および、図4-3にモータのPDS関連の規格をまとめた図である。
IEC 61800-7（Generic Interface and use of profiles for power drive systems）
IEC 61800-7-1（Interface definition）
AnnesA
Mapping of Profile type 1（CiA 402）
Annex B
Mapping of Profile type 2（CiP Motion）
Annex C
Mapping of Profile type 3（PROFIdrive）
Annex D
Mapping of Profile type 4（SERCOS）
IEC 61800-7-200（Profile specifications）
IEC 61800-7-201
Profile type 1（CiA 402）
IEC 61800-7-202
Profile type 2（CiP Motion）
IEC 61800-7-203
Profile type 3（PROFIdrive）
IEC 61800-7-204
Profile type 4（SERCOS）
IEC 61800-7-300（Mapping of profiles to network technologies）
IEC 61800-7-301
Mapping of profile type 1 to・ CANopen
・ CC-Link IE・ EPA・ EtherCAT・ ETHERNET
Powerlink
IEC 61800-7-302
Mapping of profile type 2 to・ DeviceNet・ ControlNet
・ EtherNet/IP
IEC 61800-7-303
Mapping of profile type 3 to・ PROFIBUS
・ PROFINET
IEC 61800-7-304
Mapping of profile type 4 to・ SERCOS I + II・ SERCOS III
・ EtherCAT

図4-2

IECモータ関連のデバイスプロファイル規格の一覧（出典：IEC CDV 618007-201 2014）12報告書：デバイスプロファイル技術専門委員会

１．PDS関連の概要
規格番号

名称

61800-1

一般要求事項-低電圧直流可変速駆動システムの定格仕様

61800-2

一般要求事項-低電圧交流可変速駆動システムの定格仕様

61800-3

EMC要求事項および試験方法

61800-4

一般要求事項-1000Vを声35kV以下の交流可変速駆動システムの定格仕様

61800-5

安全要求事項61800-6

負荷債務および対応する電流定格の種類の決定方法

61 80 0- 7

PDSに関する共通インタフェース およびプロファイルの仕様

61800-8

電力インタフェースの電圧仕様

61491

コントローラとドライブ間のリアルタイムシリアル通信

２．IEC 61800-7の内訳
規格番号

名称

61 80 0- 7- 1

基本的な インタフェース の定義

61 80 0- 7- 2

プロファイルタイプ

61 70 0- 7- 3

個別のネットワーク技術に対するマッピング

３．61800-2，及び、61800-3の内訳
規格番号

名称

IEC 61 80 0-7 -2 01

PDSの基本的な インタフェース の定義-プロファイル type 2（CiA 4 02 のプロファイル）

IEC 61 80 0-7 -2 02

PDSの基本的な インタフェース の定義-プロファイル type 2（CIP Mo tionのプロファイル）

IEC 61 80 0-7 -2 03

PDSの基本的な インタフェース の定義-プロファイル type 3（PRO FIdriveのプロファイル）

IEC 61 80 0-7 -2 04

PDSの基本的な インタフェース の定義-プロファイル type 4（SERCOSのプロファイル）

IEC 61 80 0-7 -3 01

PDSの基本的な インタフェース の定義-マ ッピング： プロファイル type 1（ CANope n、CC-Lin kIE、EPA、
Ethe rCAT、ETHERNET Po werlinkのプロファイル）

IEC 61 80 0-7 -3 02

PDSの基本的な インタフェース の定義-マ ッピング： プロファイル type 2（ Device Net、Co ntrol Ne t,
EterNet/ IP、のプロファイル）

IEC 61 80 0-7 -3 03

PDSの基本的な インタフェース の定義-マ ッピング： プロファイル type 3（ PRO FIB US、
PROFINETのプロファイル）

IEC 61 80 0-7 -3 04

PDSの基本的な インタフェース の定義-マ ッピング： プロファイル type 4（ CERCO S Ⅰ+ Ⅱ
、CERCO S Ⅲ、ETh erCATのプロファイル）

図4-3

IECの既存モータ関連デバイスプロファイルの構成

IEC 61800-7では、PDSに共通するプロファイルについて規定している。ネットワークのコンソーシアム
ごとに定めているPDSのデバイスプロファイルは、IEC 61800-7シリーズに規定されている。IEC 61800-7-1には各種のネットワークに共通する概念（Generic PDS interface）について記載されている。
4.2.1.3

デバイスプロファイルを使った通信

デバイスプロファイルは、オートメーションシステムを構築する上での基本概念である。通信の規定に従って製品の入力部に通信でアクセスすることにより、共通の出力を指定することができる。
ユーザはA社の製品が壊れた場合、B社の製品で代替できるかどうかをデバイスプロファイルから判定でき、マニュアルを見なくとも制御することができる。エラーコードにおいても、規格に準拠した製品であれば共通のエラーコードを表示する。
4.2.1.1

IDについてデバイスプロファイルでは、デバイスのIDにより製品を区別し管理する。
13

報告書：デバイスプロファイル技術専門委員会制御に使うIDとLCMのアセットマネジメント（資産管理）に使うID（LCMプロファイル）が異なるコ
ード番号となっている場合がある。
4.2.1.2

エネルギー管理のアプリケーションのためのプロファイル

エネルギー管理については、アプリケーションプロファイルが規定されている。エネルギー管理では、
省エネルギーの達成度を示すKPI（Key Performance Indicator）を定めている。
4.2.1.3

LCMプロファイル

IECでは、電子辞書としてLCMプロファイルを規定し、保守部品の選定を目的としている。
図4-4は、オートメーションのための通信、制御に使用するデバイスプロファイルとLCMプロファイル
について、製品の導入から時間経過ととともに、どのように利用するかのイメージをまとめたものである。
デバイスプロファイルはLCMプロファイルより、データの項目が多く、図では幅の広い矩形で示している。

デバイスプロファイル（オートメションのための通信、制御に使用）
LCMプロファイル （ライフサイクルマネジメントに使用）
CDD（Common Data Dictionary 電子辞書）

設備計画 稼働開始
図4-4
4.3

稼働終了

保守終了

時間

設備利用の時間経過とデバイスプロファイルとLCMプロファイル

既存のデバイスプロファイルとそのアプリケーション

既存のデバイスプロファイルの規格で定義しているアプリケーションとそのプロファイルを図4-5に示す。これらのPDSのデバイスプロファイルでは、モータという製品をトルク、回転速度、加速度からなると定義し、そのアプリケーションでは、トルク制御のアプリケーション、速度制御のアプリケーション、加速制御のアプリケーションが示され、それらのアプリケーションを実現するために必要なプロファイルを規定している。モータをトルク、回転速度、加速度を供給する物理的な製品と考えれば、このようなプ
ロファイルの考え方にたどり着くと考えられる。

14

報告書：デバイスプロファイル技術専門委員会

制御装置

アプリ
ケーション
制御
プログラム

PDS インタフェース

PDSの基本的な制御機能

指令値：速度
速度制御

指令

トルク
制御

M

フィード
バック

S

状態

図4-5
4.4

速度制御システム アプリケーションの例（出典：IEC 61800-7-1の図を改変）

既存のデバイスプロファイルとアプリケーションプロファイルとの比較

表4-2は、IEC61800-7-1に記載された、既存の速度制御のためのデバイスプロファイルの一部である。
表4-2

速度制御システムのためのデバイスプロファイルの例（出典：IEC 61800-7-1の表を改変）

No. 設定 オブジェクト
1 速度センサ実測値
2 センサモード
3 速度要求値
4 速度window
5 速度window時間
6 速度閾値時間
7 最大すべりpage
8 トルク指令値
9 最大トルク
10 極性
11 最大motor velocity
12 最大回転速度
13 加速プロファイル
14 減速プロファイル
15 急停止加速度
16 動作プロファイルタイプ
一方、本委員会で検討する、IoTアプリケーションのために必要なデータという視点で見たアプリケー
ションプロファイルの例を表4-3に示す。例えば、エネルギー管理に必要なデータは、モータ１台ごとの15

報告書：デバイスプロファイル技術専門委員会

定期的な（およそ6秒間隔（1分間のデータのサンプル数が10個のデータ））瞬時電力である。
保守アプリケーションに必要なデータは、モータ１台ごとの状態（運転中か、停止中か、故障中か）というデータをおよそ1秒間隔でとらえたデータになると予想される。
表4-2に示す既存のデバイスプロファイルと、表4-3に示すアプリケーションプロファイルは、その目的から、異なる仕様になっていることが分かる。
表4-3

IoTアプリケーションに必要なアプリケーションプロファイルのイメージ

No. IoTアプリケーション
1

取りたいデータ

データの例

サンプリング時間の例

モータの消費電力

瞬時電力（kW）

6秒間隔

モータの消費電力量

消費電力量（kWh）

1分間隔

3

モータの状態

運転・停止・故障

1秒間隔

4モータのID

メーカ・形式・Ver

1日1回

運転開始時刻時分秒

運転終了時刻時分秒

2

5

エネルギー管理

保守

6

運転時間

7

動作環境

温度・湿度・振動

1分間隔

8モータの状態（その１）

運転・停止・故障

1秒間隔

モータの状態（その２）回転数・正転・反転

1秒間隔

運転開始

運転開始時刻

時分秒

11

運転終了

運転終了時刻時分秒

12モータの状態（その１）

運転・停止・故障

1秒間隔

モータの状態（その２）回転数・正転・反転

1秒間隔

運転開始時刻時分秒

運転終了時刻

時分秒

9
10

13
14
15

工程・進捗管理

設備効率

運転時間

16

報告書：デバイスプロファイル技術専門委員会

5

アプリケーションの検討

5.1

IoTアプリケーション実行時のシステム構成

図5-1にIoTアプリケーションを実行する際のシステム構成の例を示す。
クラウドの仕様について検討することは、本委員会の範囲外とするが、この図ではIoTアプリケーショ
ンの概要を説明するために、最上位にあるクラウドまでを示している。本図では、クラウドへ接続するためにはユーザの許可を得るものとする。工場内のIoTアプリケーションはパソコン（PC）上で動作し、モータメーカがアプリケーションを製作して、工場のユーザに提供すると想定する。PCが通信によりモー
タからのデータを取得するデータは、ネットワークの種類が異なっても同じ仕様のデータとすることを目標とする。モータのデータを生成する機器には、インバータ、サーボコントローラ、通信ボード（現状では通信の教育用として提供されているような通信ボード （注3））、無線でモータのデータを送信するセン
サ、さらには、現在世界の半導体メーカが開発していると言われているIoTチップなどを想定する。
モータには、センサや補機が付いている場合も想定する。補機として、冷却用のファン、センサとして熱電対のような温度センサ、モータ電線の絶縁を測定するセンサ、電流センサなどが想定される。

図5-1
5.2
5.2.1

IoTアプリケーションを実行する時のハードウェア構成

PLCを介して上位PCがモータデータを取得する方式
データ取得方式の分類

モータを使ったシステムの多くの例で、ネットワークの中にPLCが存在している。そのため、IoTアプ
リケーションを検討するための前提条件として、上位のPCがPLCの下に設置されているモータをアクセスしてデータを取得できるかどうかを検討することが必要である。ここでは、PLCを介して上位のPCがPLC
17

報告書：デバイスプロファイル技術専門委員会の下のモータにアクセスしてデータを取得することが可能と考えられる4方式のアイデアを示す。このようなアイデアのいくつかが将来には実現可能になると考える。
表 5-1

No.

PLC を介して上位 PC がモータデータを取得する方式の案

モータデータを取得する方式

特長

実現可能性

1

＜方式1＞
Function Blockを利用

Function Blockが利用可能なPLCに共通に使える方式

試作評価して可能性を検証可能

2＜方式2＞
ORiNを利用

モータデータのアドレスをモータ1台ずつ設定してデータ取得

実現可能

3

＜方式3＞
インタフェースボードを利用

現在、世界で開発されているという
IoTチップを利用して、本方式のコスト削減が必要

試作評価して可能性を検証可能

4＜方式4＞FA-ITオープンプラットフォームを利用

三菱電機より提案されたプラットフォーム

プラットフォーム
確立後に可能18

報告書：デバイスプロファイル技術専門委員会

5.2.2

方式１：ファンクションブロックを使うPLCを介した通信方式

図 5-2 にファンクションブロック（Function Block）（注４）を使う方式（表 5-1 の方式 1）を示す。この例では、PLC のプログラム内にモータ１個に対して１個のファンクションブロックを入れることにより、モータデータを PC に送信する。ファンクションブロックは、モータのデータをその内部にコピーして持っており、上位 PC との通信タイミングに合わせてモータデータを上位に送信する。この方式では、通信にリアルタイム性が必要な場合も対応が可能と考えられ、PLC の制御プログラムに影響を与えないようにすることが可能と考えられる。
PLCの種類や、ネットワークの種類に合わせて、ファンクションブロックを製作する。ファンクション
ブロックにパラメータを設定することにより、PCとの通信条件を設定する。工場内のネットワークの種類によっては、上位PCからファンクションブロックに対してデータ送信を要求して、データを送信する
場合と、上位からのデータ送信要求がなくとも、一定周期でファンクションブロック側から上位PCへとデータを送信する場合との両方の例が考えられる。
将来、IoTアプリケーションを立ち上げるための協調領域の実証実験として、ファンクションブロック
を工業会等で試作するなどの方法が考えられる。

図5-2

＜方式１＞

ファンクションブロックを利用してモータデータを取得する方式（注４）シーケンスプログラム内で繰り返し使用する回路ブロックを部品化して、シーケンスプログラムの中で流用できるようにしたもの

19

報告書：デバイスプロファイル技術専門委員会

5.2.3

方式２：ORiNを利用するPLCを介した通信方式

図5-3にロボット工業会のORiN（注5）を利用して、モータデータを取得する方式（表5-1の方式2）を示す。
ORiN協議会に参加する企業は、各種のメーカのPLCと通信するためのソフトウェア（ORiNでは、プロバイダと呼ぶソフトウェア）を開発しており、ORiNを利用することにより、上位PCとPLCが通信する。こ
の方法は現状の技術で実現可能であり、生産設備ごとの多様な通信方式にORiNを介して対応できる。
この方式では、PLC内の何番地のメモリにどのモータの何のデータがあるかを個別に設定して、データを取得することが必要になる。このため、設定作業が必要となるが、モータのIoTアプリケーションの付加価値が、設定作業の工数を上回る場合には、モータIoTアプリケーションを利用することが可能となる。

図5-3

＜方式2＞

ORiNを利用してモータデータを取得する方式（注５）ロボット工業会のORiN協議会が提唱する通信ソフトウェア。パソコンによるロボットの制御機能の開発からスタートし、現在は各種の産業製品と通信してデータ収集する機能を持つ。

20

報告書：デバイスプロファイル技術専門委員会

5.2.4

方式３：インタフェースを利用する通信基板による通信方式

図5-4は、将来安価な価格で提供されるIoTチップ（１個100円程度のコストと言われる）を使った通信ボードにより、イーサネットとシリアル通信を同時に実行するような構成（表5-1の方式3）が想定できる。
シリアル通信では、現状のPLCとモータ間で行われている通信をそのままの形で実行して、PLCによる制御動作を実行し、送受信されているモータデータをIoTチップにより解析して、得られたデータを上位PCに送信することが可能となる。必要に応じて通信ボード上でデータの１次処理を実行する。イーサネット
ベースの通信では無線の利用も考えられる。

図5-4

＜方式3＞

インタフェースボードを利用してモータデータを取得する方式

21報告書：デバイスプロファイル技術専門委員会

5.2.5

方式４：オープンプラットフォームを利用するPLCを介した通信方式

図5-5にEdgecross（注5）などのオープンプラットフォームを利用する方式（表5-1の方式4）を示す。このようなオープンプラットフォームの例では、一番下位の階層にコントローラ、ドライブ、機械ツール、センサ、ロボットが位置し、ネットワークの種類によらず、データコレクタという通信ソフトウェアを介してデータが収集され、それらのデータを利用するアプリケーションが動作する。このようなプラットフォームが利用可能になれば、モータデータを取得してIoTアプリケーションを動作させることができるようになると考えられる。

図5-5

＜方式4＞

Edgecrossなどのオープンプラットフォームを利用してデータを取得する方式（出典：Edgecrossコンソーシアムより

22

https://www.edgecross.org/ja/edgecross/）報告書：デバイスプロファイル技術専門委員会

5.3

モータのIoTアプリケーション（例の１）：エネルギー管理

以下に、モータデータを利用するIoTアプリケーションの具体例を示す。ここでは、主に、本委員会で検討が可能なエネルギー管理（モータIoTアプリケーション（その１））と保守（モータIoTプリケーショ
ン（その２））について示す。
図5-6に、モータのデータを使ったエネルギー管理の意味について示す。日本の全電力消費量の中でモータが消費する電力が示す割合は、57.3％を占めるとのデータがある。そのため、モータからのデータを使ってエネルギー管理を実施した場合、57.3％の電力エネルギーの課題について詳細に分析することが可能となる。さらに、モータの分野でIoTアプリケーションが利用可能になれば、将来モータのIoTアプリケーションの手法をモータ以外の製品（照明、電熱、IT機器など）に展開することが期待される。

2005年総使用電力量
9996億kWh

日本全体の電力の57.3％をモータが消費

その他
15%

IT機器
5%

動力
33%

モータで57.3％の電力を消費電熱
9%モータの電力を監視することに

照明
14%

意味がある

空調・冷蔵関連24%

図5-6

モータ電力測定によるエネルギー管理の意味

図5-7にエネルギー管理のモータIoTアプリケーションの概要を示す。エネルギーアプリケーションの機
能は、パソコンの画面に表示される画面の動作によってその概要を示すことが可能である。パソコンはネットワークを経由して、エネルギー管理のアプリケーションのために定めたアプリケーションプロファイ
ルで指定されるデータをモータから取得する。モータはメーカやモータの種類を問わず、同じ種類のデー
タが同一水準の品質でデータが得られるものとする。

23

報告書：デバイスプロファイル技術専門委員会

発電機

電力監視画面

LOC

LOC

発電機
高圧
分岐盤

予備線

本線

２系

１系
LOC

LOC

LOC

LOC

LOC

LOC

LOC

LOC

LOC

LOC

LOC

LOC

LOC

LOC

LOC

LOC

LOC

LOC

複電同時優先
本線
１系
コン
デンサ

１系
予備

１系
予備

１系
3φ
500KVATR

１系
3φ
500KVA
TR

１系
No.2
UPS
入力

予備

１系
No.1
UPS
入力

2系
No.1
UPS
入力

UPS
入力
切替盤

2系
No.2
UPS
入力

2系
3φ
500KVA
TR

2系
予備

2系
予備

2系
コン
デンサ

2系
3φ
500KVA
TR
No.1
UPS
入力

No.2
UPS
入力

図5-7

エネルギー管理アプリケーションの要素

図5-8に、現在市場に提供されているエネルギー管理のソフトウェアの例を示す。このエネルギー管理のソフトウェアは、モータから直接取得されるエネルギーデータではなく、工場内に電力を測定するセン
サを配置し、電力データのためのネットワークを経由して取得されている。
現在値表示機能は、工場内のどこでどれだけのエネルギー（ここでは電力）が使用されているかをリア
ルタイムに示す画面である。工場内の場所を示すために、工場内の電力の配線系統図の上に電力の現在値を示している。配線系統図の上に示す場合だけでなく、工場内のマップに電力の現在値を示す方法も考えられる。
トレンドグラフ画面は、過去にどのモータがどれだけの電力を使ったかの履歴を示す画面である。モータ１個ごとの履歴を示すことも可能であり、また、モータをグループにまとめ、グループごとの履歴を示すこともできる。モータをグループ化することにより複数のモータからなる設備（工作機械やロボット、コンベヤなど）の履歴や、工場のラインごとの履歴、工場全体の履歴を表示することが可能となる。
帳票機能では、電力使用量の積算値を示す。積算値は、１時間あたりの電力量、１日当たりの電力量、
１ヶ月当たりの電力量として、工場内のエネルギー管理を実施する単位で表示し、エネルギー管理のための指標であるKPI（Key Performance Indictor：評価値）を求めることが可能となる。

24

報告書：デバイスプロファイル技術専門委員会

90

発電機

電力監視画面

LOC

LOC

発電機
高圧
分岐盤

80

予備線

本線

70

２系

１系
LOC

LOC

LOC

LOC

LOC

LOC

LOC

LOC

LOC

LOC

60

LOC

LOC

LOC

50

LOC

LOC

LOC

LOC

LOC

40
複電同時優先
本線
１系
コン
デンサ

１系
予備

１系
予備

１系
3φ
500KVA
TR

１系
No.2
UPS
入力

１系
No.1
UPS
入力

予備
2系
No.1
UPS
入力

2系
No.2
UPS
入力

2系
3φ
500KVA
TR

2系
予備

2系
予備

30

2系
コン
デンサ

20
１系
3φ
500KVA
TR

UPS
入力
切替盤

2系
3φ
500KVA
TR
No.1
UPS
入力

10

No.2
UPS
入力

0
1

2

3

4

5

6

7

8

9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

モータ別消費電力履歴
日付：11月29日
No.

装置

単位：kWh
モータ

時間
13

14

15

16

17

18

19

20

21

22

23

24

1

コンベア1

0

0

0

0

0

0

0

5

100

90

90

50

110

100

115

108

107

80

40

0

0

0

0

0

2 搬送ライン

コンベア2

0

0

0

5

100

90

90

50

110

100

115

108

107

80

40

0

0

0

40

0

0

0

0

0

3

分岐用

0

0

0

0

0

0

0

5

5

100

90

90

50

110

100

115

108

107

80

40

0

0

0

0

位置決め装置

0

0

0

0

0

0

0

5

100

90

90

50

110

100

115

108

107

80

40

0

0

0

0

0

回転軸

0

0

0

0

0

0

0

5

100

90

90

50

110

100

115

108

107

80

40

0

0

0

0

0

6

位置決め装置

0

0

0

0

0

5

100

90

90

50

110

100

115

108

107

80

40

0

0

0

0

0

0

0

7 フライス盤

X軸

0

0

0

0

0

0

0

5

100

90

90

50

110

100

115

108

107

80

40

0

0

0

0

0

8

Y軸

0

0

0

0

0

0

0

5

100

90

90

50

110

100

115

108

107

80

40

0

0

0

0

0

9

1軸

0

0

0

0

0

0

0

5

100

90

90

50

110

100

115

108

107

80

40

0

0

0

0

0

10

2軸

0

0

0

0

0

0

0

5

100

90

90

50

110

100

115

108

107

80

40

0

0

0

0

0

3軸

0

0

0

0

0

0

0

5

5

100

90

90

50

110

100

115

108

107

80

40

0

0

0

0

4軸

0

0

0

0

0

0

0

5

100

90

90

50

110

100

115

108

107

80

40

0

0

0

0

0

13

5軸

0

0

0

0

0

0

5

100

90

90

50

110

100

115

108

107

80

40

0

0

0

0

0

0

14

6軸

0

0

0

0

0

5

100

90

90

50

110

100

115

108

107

80

40

0

0

0

0

0

0

0

4
5

11
12

旋盤

ロボット１

1

2

3

4

5

6

7

8

9

10

11

12

図5-8
5.4

エネルギー管理アプリケーションの主な機能

モータのIoTアプリケーション（例の２）：保守

次にモータの保守のIoTアプリケーションについて述べる。JEMAのスマートマニュファクチャリング特別委員会が発行した2015年度版の「製造業2030」（注６）に保守の分類の記述がある。図5-9はそこに掲載された保守の方式を示す。

事後保全(BM) 1(Breakdown Maintenance)
保全方式

2
時間基準予防保全(TBM)(Time Based preventive Maintenance)

予防保全(PM)(Preventive Maintenance)3
状態基準予防保全(CBM)(Condition Based preventive Maintenance)
図5-9

保守の方式

（注６）https://www.jema-net.or.jp/Japanese/info/download/160527.pdf
25

報告書：デバイスプロファイル技術専門委員会

図5-10 保守IoTアプリケーション実行時のハードウェア構成
表5-2

保守アプリケーションの場合のアプリケーションプロファイルの例

No.

保守の方式

アプリケーションの機能

プロファイルの例

1 事後保全・故障検出
・故障表示・通報
・故障履歴

・運転・停止・故障
・故障モード・異常検出
振動、温度、音響
絶縁抵抗
・モータID

2 時間基準予防保全

・運転時間計測・運転時間積算・予防保全時期表示

・運転時間
・環境データ
温度、振動、音、
絶縁
・モータID

3 状態基準予防保全

・運転状態計測
・運転状態トレンド・予防保全時期表示

・運転状態
温度、振動、音、
絶縁
・保守履歴

図5-10は、保守アプリケーションを実行する際のハードウェア構成の例を示す。表5-2に示す3種類に分類された保守の方式では、どのようなアプリケーションがあり、そのためにはどのようなアプリケーショ
ンプロファイルがが必要になるかの概要を示したものである。
図5-10に示すハードウェア構成は、基本的には、図5-1に示すIoTアプリケーションの全般のハードウェ
26

報告書：デバイスプロファイル技術専門委員会

ア構成と同一である。図5-1と異なる点は、保守アプリケーションにおいては、モータの寿命データの活用が重要であり、モータメーカからモータ個別の寿命データを提供可能な構成を示す。保守アプリケーシ
ョンにおいては、寿命データを示すことによりユーザにとっての価値が増大する。また、メーカにとっても、モータ個別の寿命データが保守アプリケーションを通じて、クラウドなどを経由して取得できれば、保守部品事業の効率化に役立つ。このようなWin-Winの関係を構築することにより、メーカの保守ビジネ
スは現状の段階から次の段階へと進むことが可能になると考えられる。
一方、ユーザとメーカをネットワークでつなぐためには、セキュリティの対策と産業データの所有権の課題の解決が必要となる。保守アプリケーションを実現するためには、その接続方法に賛同する業界内での調整、方式の確立が必要になる。
5.4.1

事後保全のアプリケーション

表5.2に保全の3種類の方式に分類した、保全のアプリケーションとアプリケーションプロファイルの検討結果をまとめた。今後、本委員会では、保全アプリケーションの詳細を検討して、プロファイルの詳細な仕様へと進む予定である。事後保全のアプリケーションでは、設備の停止時間を短くするため、故障の検出をリアルタイムで行い、故障発生を担当者に通報する機能が必要になる。さらに、故障の発生頻度の履歴を見ることにより、設備の真の故障対策へとつなげることが可能になる。
このようなアプリケーションを実現するためには、故障を検出するための、「運転・停止・故障」デー
タ、故障がどのようなモードで発生したか、故障までに至らなくとも、異常データを検出することが必要になる。さらに、代替え部品の手当のため、故障した部品のIDを検索するシステムへの接続機能が必要と
なる。
5.4.2

時間基準予防保全

時間基準予防保全では、該当のモータの運転時間の累積を求めることが必要である。このため、運転時間を計測し、そのデータを積算する機能が必要である。また、予防保全作業を実施するための時間を設定して、その時間に近づいたら、画面表示や通報機能により、設備の停止を避ける機能が必要となる。
ここでは、予防保全を実施すべき時間をどのように設定するかが課題となる。モータの種類により、業界の保全実施のための標準時間を求めるか、メーカごとに推奨の保全時間を提供するか、あるいは、5.4節に記載したような、IoTを利用して、メーカとユーザを接続する方式も考えられる。
このような機能を実現するため、運転時間データ、使用環境のデータ（温度、振動、音、絶縁など）、
モータIDなどのデータが必要になると考えられる。今後、当委員会では、これらのプロファイルの詳細化の作業を実施する予定である。
5.4.3

状態基準予防保全状態基準予防保全では、モータの状態を検出し、運転状態の良し悪しを判定し、保全作業を実施すべきかどうかを表示、通報する機能が必要となる。また、運転状態のトレンドを示す機能（モータの運転状態
が時間とともに低下しているのか、あるいは、一定な状態なのか、日によって状態が変化するのかを示す
機能）、予防保全を実施すべき時期を表示通報するための機能が必要になる。このため、モータの運転状
態を示すデータ、モータの使用環境を示すデータ（温度、振動、音、絶縁など）、保守履歴を示すデータが必要になる。
27

報告書：デバイスプロファイル技術専門委員会

5.4.4

保守アプリケーションの機能

保守アプリケーションの機能をその概要から詳細へ検討して行くために、保守アプリケーションの画面を収集することが役立つ。図5-11は、現状の市販の保守アプリケーションの画面を集めたものである。今後、このような画面の検討から、保守アプリケーションの機能の詳細を検討して行く。
ファイル

ホーム

挿入

デザイン

画面切り替えアニメーション

メニュー

アニメーション

校閲

表示

書式

警報履歴画面現在値■警報検索

30分デマンド値

検索

警報レベル

1

警告

2000年1月1日0時

発生日時

9999

重故障

2018年12月30日24時

電力量履歴
警報履歴
システム設定

警報名称

～

N o.

状態

建屋1室温低下発生

モータ1温度上昇

復旧■警報検索
N o. 警報レベル

発生日時

警報名称

状態

1 警告

20 18年1 2月30 日11時5 2分

建屋1室温低下

復旧

2 軽故障

20 18年1 2月28 日10時3 9分

コンベア停止復旧

3 重故障

20 18年1 2月25 日10時3 7分

圧縮機故障

復旧

4 軽故障

20 18年1 2月25 日10時3 7分

コンベア停止発生

5 軽故障

20 18年1 2月25 日10時3 3分

モータ１温度上昇

復旧

6 重故障

20 18年1 2月25 日10時3 2分

圧縮機故障

発生

7 警告

20 18年1 2月25 日11時5 2分

建屋1室温低下発生

8 警告

20 18年1 2月22 日8時50 分

圧力油油面低下復旧

9 警告

20 18年1 2月21 日8時31 分

圧力油油面低下発生

1 0 軽故障

20 18年1 2月18 日13時4 5分

モータ１温度上昇

発生

1 1 軽故障

20 18年1 2月15 日17時2 5分

ポンプ1停止復旧

1 2 警告20 18年1 2月14 日20時1 8分

モータ１温度上昇

復旧

1 3 警告20 18年1 2月14 日13時5 2分

モータ１温度上昇

発生

1 4 重故障

20 18年1 2月10 日16時5 2分

圧縮機故障

復旧

1 5 軽故障

20 18年1 2月10 日15時3 1分

ポンプ1停止発生

警報履歴画面

設備保守履歴入力画面

設備管理の例
図5-10 保守アプリケーションの主な機能

28

報告書：デバイスプロファイル技術専門委員会

5.5

モータのIoTアプリケーション（例の３）：工場内の稼働管理

モータからのデータにより、工場内の設備の稼働状況を管理するアプリケーションは、設備の稼働状況
を直接的に収集する方式ではなく、設備の状況を間接的に把握したり、設備の中のモータだけに限って把握することによるもので、IoTアプリケーションとして発展の可能性がある。
モータは工場内に複数箇所に設置されており、モータがあれば（モータがありさえすれば）工場内の稼働状況を工場全体に亘って管理することの可能性があり、工場の種類によっては有効な方法になる可能性がある。
工場内の稼働状況が適正かどうかを判別する方式として、画像センサのデータにより工場内の稼働状況
が、適、不適であるとの判断情報を収集して、自立学習の経験を積むことにより、AI活用して学習する可能性がある（図5-11）。
工作機械やロボットにおいては、工作機械のコントローラやロボットコントローラの稼働状況が適正かどうかを判定することができる。また、工作機械のコントローラやロボットコントローラを経由せずに、それらの機械の中のモータの稼働のデータを直接に取ることで、工場内の設備の稼働をモータから見た視点で一元的にとらえることが可能となる。
AIの進化と相まって、今後上記のようなアプローチで工場内の稼働状況をモニタし、問題があればアラームを出し、工場内のどこに改善の余地があるかを判定するアプリケーションを作ることができると予想される。

図5-11 モータの稼働データを利用した工場設備の稼働状況管理の例
図5-12も同様で、工場内のモータの運転時間、モータの回転数、モータの電力消費が工場内の設備稼働の状況を表すデータであり、工場内の稼働状況が良いか、悪いかの判断を提供することにより、機械の自己学習が可能になると考えられる。
29

報告書：デバイスプロファイル技術専門委員会

図5-12 モータの稼働データを利用した工場設備の稼働状況管理の例30

報告書：デバイスプロファイル技術専門委員会

6

今後の進め方6.1

今後の課題

本委員会では以上のように3つのアプリケーションを検討したが、今後アプリケーションの実現に向かうために、次のような課題があると考える。
モータのアプリケーションプロファイルは、既存のPDSのデバイスプロファイルやLCMプロファイルでは、カバーできていない内容を含んでいる。モータのアプリケーションプロファイルを決めるために、
IoTアプリケーションのためのデータの定義が必要となる。
これらを実現して行くためには、モータの周辺機器や工場内の使用環境などでの実証を含めた検討が必要になると考える。
6.2

今後の進め方

上記の課題を踏まえ、今後これらの課題を解決するために、次のように進めることが必要になる。
-3つのアプリケーションごとのアプリケーションプロファイルの定義-アプリケーションとモータとのインタフェース検討-アプリケーションプロファイルのデータの定義
実使用環境においては、次の検討が必要になる。
-モータのLCMプロファイルの定義-デバイスプロファイルとLCMプロファイルとの関係の検討
アプリケーションの実証試験によりユーザメリットの検証が必要になる。
-IT（監視ソフト）とOP（現場データ）の融和-IT・OTのインタフェースの標準化
また、将来、さらに多くのアプリケーションに適用するための汎用的な展開を期待する。
図6-1に今後の本委員会の中期的な進め方をまとめた。最初に①で示すモータアプリケーションプロフ
ァイルとIoTの検討により、プロファイルの具体的な仕様をまとめる。その後②で示すアプリケーションの実証試験の段階へ進み、実証試験が可能になった段階で③のユーザからの評価を得るというステップで検討を進めることが可能となる。
アプリケーションプロファイルは、共通となるプロファイルと、個別のアプリケーションごとに必要となるプロファイルの組み合わせとして構成することができる。また、モータの周辺機器からのデータをモータ本体と同列に扱えるようにする工夫が必要である。アプリケーションの実証試験においても、モータは多様な機能を果たしており、それらの機能を分類してとらえることが必要になると考えられる。ユーザの評価により、アプリケーションの機能とアプリケーションプロファイルの見直しが必要になり、①→②→③→①と何回かループを経る見直し調整が必要になると考えられる。
また、最終的な目標として、モータのアプリケーションプロファイルを④規格化（IEC規格）すること
を掲げる。

31

報告書：デバイスプロファイル技術専門委員会③ユーザからの評価
ユーザA
エネルギ
機能A

ユーザB
エネルギ
機能C

ユーザC
保全
機能B

ユーザD
保全
機能A

②アプリ実証試験
エネルギー管理
アプリケーション機能A 機能B
機能C

保全
アプリケーション機能A 機能B
機能C

稼働管理
アプリケーション機能A 機能B
機能C

アプリケーションに共通なプロファイル

エネルギー管理のためのプロファイル

保全のためのプロファイル

その他
アプリケーション

④規格化
IEC規格

①プロファイル検討

稼働状況モニタのためのプロファイル

その他のプロファイルプロファイル
図6-1

今後の進め方（中期計画）

表6-1に今後の作業の一例を示すために、電力監視アプリケーションのためのアプリケーションプロフ
ァイルの項目を示した。今後、これらのプロファイルの具体的な仕様をアプリケーションの機能と結び付けて検討して行く。
表6-1
No.

エネルギー測定場所

1 電力の受電点

アプリケーションプロファイルの仕様検討の例

エネルギー管理の目的

3

4

5

6

設備
及び、設備中のモータ

プロファイルの例
測定データ

測定内容

測定間隔

電源監視ユニット

電力量計のパルス

受電電力

2分30秒ごと
30分単位のデマンドデータ

電力量演算ユニット

電圧・電流・力率

設備毎の電力10分トレンドデータ

モータからのデータ

電圧・電流・力率

モータ毎の電力

10分トレンドデータ
設備の目的に合った時間間隔（1秒・1分・6分・10分）

稼働状況の監視モータからのデータ

電力
回転速度
温度
振動
状態

稼働状況の
設備の目的に合った時間間隔
リアルタイム表示 （1秒・1分・6分・10分）

稼働時間・生産量の記録

モータからのデータ

運転開始時刻運転終了時刻運転回数
運転時間

設備の目的に合った時間間隔（1秒・1分・6分・10分）

モータからのデータ

電力
回転速度
温度
振動
状態

稼働状況の
Big Data分析

設備の目的に合った時間間隔（1秒・1分・6分・10分）

工場全体の電力管理

2
消費電力の大きな設備
及び、設備中のモータ

測定機

省エネルギーのための管理

製造条件の記録

報告書の完成後に、JEMAに設置されている関連の委員会に対して本委員会の活動内容とその目的、今
32

報告書：デバイスプロファイル技術専門委員会

後の進め方について理解を得て、意見をもらうとともに、連携して行くことを希望している。さらに、この委員会活動への協力メンバーを増やす検討を進めて行きたい。

33

報告書：デバイスプロファイル技術専門委員会

デバイスプロファイル技術専門委員会

氏名

委員一覧

組織名

(委員長)

李

天兵

オムロン株式会社(副委員長)

山田隆雄

富士電機株式会社

(委員)

山口

肇

寺崎電気産業株式会社

山口健二

パナソニック株式会社

野辺武

一般社団法人

日本電気制御機器工業会（パナソニック株式会社）

（事務局)

梁田

哲男

株式会社日立産機システム

渡邊哲徳

株式会社日立産機システム

大橋博章

三菱電機株式会社

高橋一郎

一般社団法人日本電機工業会

上記の委員名簿は，組織名の五十音順，氏名の五十音順にて記載した。

34