事例：ロボットの予防保全
図3は、IoTソリューションの実際の例として、ロボットの故障を防ぎ継続的な運転を保証するために定期的なメンテナンスを実施する「ロボットの予防保全注10」（PM：Preventive Maintenance）の仕組みを示したものである。
図3 ロボットの予防保全
出所 山本 宏（IBM）『Experimental IIRA adaptation to the actual IoT solution』、2016年6月3日
通常の工場では、ロボットが1時間も停止してしまうと、その損害額は約数千万円〜数億円にまで及ぶと言われている。
図3は、このようなロボットの故障予防メンテナンスシステムを実現した例である。具体的には、すべてのロボットにアコースティック・センサー〔AEセンサー注11〕を付けて、そのAEセンサーが収集したデータ（Friction Energyデータ：ひずみエネルギーデータ）を分析し、ロボットに異変が生じ、壊れる予兆があることが検出された場合には、アラート（Crack Alert、警報）を発生して、ロボットが故障することを事前に防ぐ。
あるいは、ゲートウェイ（図3に示すアドバンテック社のWise 3000）を経由してモバイル通信（3G/4G）でクラウド上のアプリケーション（IBM Bluemix注12）などと連携させて、対応することなどが検討されている。
このアプリケーションでは、現在動作しているロボットに対して影響を与えない（あるいはシステムに影響を与えない）ことが求められているところから、一気にではなくインクリメンタルなアプローチ（フェーズ1、フェーズ2、 ……というように順次追加し、対応していくアプローチ）が取られている。
このため具体的には、フェージング・アプローチ（ここでは、3つのフェーズによるアプローチ）によって対応している。
例えば後述する図5に示すように、フェーズ1はデモのフェーズで、まずIoTビジネスの価値に関する可能性の検証を行う。フェーズ2の生産のフェーズでは、障害が予測される場合に備えて、EAM（企業資産管理）やERP（企業資源管理）と連携すること、すなわちショップ・フロア（生産現場）とオフィス・フロアの統合・連携が検討されている。
フェーズ3では、ロボットに取り付けたすべてのセンサーからのデータを統合して分析し、ロボットが壊れ始める予兆をとらえるだけでなく、その分析に基づいて現場環境がロボットに与える影響も含めて解析する。
IIS開発のフェージング・アプローチとビューポイント
次に、新しいIISを開発する場合に、3つのフェージングアプローチと、前述したビューポイントの関係を見てみよう。
〔1〕ユーセージ・ビューポイント
最初のユーセージ・ビューポイント、すなわち開発するIISを利用面からの視点（例：佐藤くんの視点）から見てみると、前述した図2および図4に示す5つの要素がある。
図4 ユーセージ・ビューポイントの例（佐藤くんの場合）
出所 山本 宏（IBM）『Experimental IIRA adaptation to the actual IoT solution』、2016年6月3日
具体的に佐藤くんは、①システムとしては「ロボットの故障予防メンテナンス」を担当している。②パーティとしては、メンテナンスグループAに所属し、③ロール（役割）としては、現場のラインでロボット100台のメンテナンスを行う仕事を担当している。④アクティビティ（具体的動作）としては、アラート（警報）が発生した場合をトリガー（契機）として、メンテナンスのワークフロー（業務手続の流れ）を動作させる。このワークフローの一環の作業として、佐藤くんがメンテナンスすることになるが、実際にメンテナンスしようとした場合、現場では、メンテナンス時間が設定（計画メンテナンス）されており、このような時間の制約（コンストレイン）のもとに、メンテナンスが行われることが規定されている。
このように、アクティビティとして、計画メンテナンスによるロボット・システムの状況を事前に分析した結果があるので、ロボット・システムについて、例えば3番のロボットと21番のロボット、30番のロボットがおかしい（故障の予兆がある）ということがわかっている。そのため、メンテナンスの時間を大幅に削減（50％削減と仮定している）することが可能となる。
これを具体的に実行する⑤タスク（作業）として、IBMは図4の（注）に示すように、3つのタスク（IoTソリューション）を提案しているが、これは、スリーアイ（3I）注13とも呼ばれ、IISを構築するうえで重要なソリューションの1つとなっている。
このように、ユーセージ・ビューポイントでは、IISを設計する際に、50％もメンテナンス時間を削減できる（すなわちメンテナンス・コストの削減）効果があることが重要なポイントとなっている。
〔2〕ファンクショナル・ビューポイント
（1）3つのフェーズ
次に、図5に、IISを機能面の視点から見るファンクショナル・ビューポイントの例を示す。図5の左側には、IIRA Version 1.7における5つのファンクショナル・ドメインを示す。
図5 ファンクショナル・ビューポイントの例
出所 山本 宏（IBM）『Experimental IIRA adaptation to the actual IoT solution』、2016年6月3日
このファンクショナル・ドメインを、ファンクショナル・ビューポイントのフェージングに対応させると、図5の右図に示すように、フェーズ1（デモのフェーズ）、フェーズ2（生産のフェーズ）、フェーズ3（複数センサーデータの統合・分析のフェーズ）というような「IoTソリューション成熟度モデル」となる。
フェーズ1には、①データをセンス（収集）し（制御する部分）、②次にそれらのデータを分析するインフォメーション部、③そして佐藤くんが登場（活躍）するワークフロー・アプリケーションの部分があるが、IISの基本機能はこれだけで実現できることになる。
フェーズ2では、IISを実際に生産（プロダクション）に適用するので、まずセキュリティ機能が求められる。さらに、①ロボットの制御（アクチュエーション）用にPLCが必要となるので、PLCとの連携が必要になる。また、②ビジネスの場合、保守運用部門のミッションである企業レベルのアセット・マネージメントに必ず影響が出てくるので、ここが重要となる。
また、図5は実際の本番のIISシステムであるので、③オペレーション（運用）が重要となる。オペレーションとしては、具体的に、IISで使用されているゲートウェイやアンプなどのファームウェアのアップデート、あるいはシステムの診断（Diagnosis）や、モニタリング（監視）なども必要となる。
フェーズ3としては、マルチセンサー・インテグレーションが求められ（現場に配置されている多数のロボットに付けられているセンサーデータを統合するなど）、新しいデータソースの制御や収集したデータの分析（インフォメーション部）を行う必要がある。
このようなフェーズ1、フェーズ2、フェーズ3の流れは、IoTソリューションの成熟度モデル（Maturity Model）とみなすことができ、深さをもったソリューション・モデルと位置付けることができる。
図5は、IIRAに基づいて策定されたものであるが、実際の現場でIISを構築する際に使用するドキュメントと非常に近いものとなっている。この図5に、さらに時間軸が加われば、まさに実際のIISのソリューションであり、製品のロードマップそのものとなる。
（2）IIRAとエコシステムの構築
なお、製造業における各社では、システムを構築する場合には、必ず図5のようなロードマップを作るが、各社がもっているロードマップとIIRAに基づいたロードマップでは大きな違いがある。すなわち、IoTのソリューション（IIS）を作る場合には、1社の方針に基づいて構築される企業情報システムと異なって、IISシステムを構築するためには、センサーやロボットなども含めて、多様な技術要素や運用方法が求められるため1社で作ることは難しい。このため必ず複数の会社からの提案をベースにしたエコシステムとならざるを得ない。
そこで、あるIoTソリューションやロードマップをつくる際に、IICに参加している国際的な複数の会社などの提案や実績をもとにして構築されたテストベッドなどを通して策定された、IIRAに基づくテンプレート（ひな形）を使うと、複数の会社で共通のコンセンサス（合意）が得られやすくなる。このように、IIRAはエコシステムの構築に向けた1つのメソドロジー（Methodology、体系づけた方法論）ともなっているのである。
〔3〕インプリメンテーション・ビューポイント
次に、目的とするIISを構築するために、具体的なソフトウェアやハードウェア、サービスなどを、どのように組み込んで（実装して）システムを構築するかという、インプリメンテーション・ビューポイント（図6）を見てみよう。
図6 インプリメンテーション・ビューポイント
出所 山本 宏（IBM）『Experimental IIRA adaptation to the actual IoT solution』、2016年6月3日
IIRAでは、すでに確立しているアーキテクチャ・パターンとして、図6の左上に示す5つのパターンが示されているが、ここでは、このうち、①データをセンス（収集）するエッジ・ティア、②データを分析するプラットフォーム・ティア、③EAM（企業資産管理）を含むエンタープラズ・ティアの3階層（スリー・ティア）構成を示している。
この3階層のアーキテクチャ・パターンは、それぞれ前述した、IBMの3I（スリーアイ）に対応付けることができる（図6）。
次に、インプリメンテーション・ビューポイントにおいて、なぜこのようなアーキテクチャ・パターンが必要なのか、その決定要因を見てみることにしよう。
〔4〕決定要因は何か
図6の左下の図は、ロボットの状態を示す曲線で、縦軸にエネルギー（フリクション。dBs）、横軸に使用時間（h）を示したものである。図6のケースでは、ロボットの状態が悪くなって、縦軸のエネルギーのデータのボリューム（積分値）が上がってきたときにアラート（警報：図6の○印）が発生する場合を示している、しかし、実際にロボットが壊れるまでの時間（稼働を停止するまでの時間）には、アラートが発生してから1週間あるいは数週間というように時間の間隔に幅がある。このように実際には時間の余裕があるので、この図6に示すプラットフォーム・ティアで分析しても、間に合うのである。
このように、どのようなアーキテクチャ・パターンを使用するかということは、アラート後にどれぐらいの時間の即時性が求められるかが、非常に大きな決定要因になってくる。これが、今までの企業情報システムとIoTシステムの大きな違いなのである。
今後の展開：新しいビジネス展開とオープン・イノベーション
これまで解説してきた中で一番重要なことは、IoTシステムとは、CPSを実現するソリューションであるため、「サイバーとフィジカルを一緒になって行わなければならない」ということである。
すなわち、IIRAは機械技術者やエレクトロニクス技術者、情報技術者など異なるバックグラウンドをもつ技術者にとっての共通リファレンスであることが非常に重要なことなのである。（終わり）
▼ 注10
ロボットの予防保全：Preventive Maintenance for Robot、ロボットの故障予防メンテナンス。ロボットの故障を防ぎ運転を保証するために定期的なメンテナンスを実施すること。
▼ 注11
AEセンサー：Acoustic Emission（AE）センサー。アコースティック・エミッション（AE：Acoustic Emission）とは､材料が変形する場合などに、内部に蓄えていたひずみ（弾性）エネルギーを音波（弾性波、AE波）として放出する現象のことである。このAEセンサーの波（データ）は、数M〜数GHzの高い周波数成分をもっている。
▼ 注12
IBM Bluemix：さまざまなアプリケーションを構築、管理、実行するためのオープン・スタンダードとクラウドをベースとし、IBMで開発されたプラットフォーム。Bluemixを使用すると、組織や開発者は迅速かつ容易にクラウド上でアプリケーションを作成したり、展開したり管理したりすることができる。
▼ 注13
スリーアイ（3I）とは、①‘Instrumented’は、ロボットに付けたセンサーからデータを収集すること、②‘Intelligence’は、収集したセンサーデータを解析・分析すること、③‘Interconnected’は、アプリケーションあるいは、他のバックアップ・システムなどと相互接続し連携すること、となっている。
