Davie Street Enterprises (DSE) 社は、ケーススタディーとして用意された、実際の問題を抱えた架空の企業です。DSE 社は、この 1 年でモダナイゼーションに取り組み、大きく前進してきました。同社は、IT インフラストラクチャーの大部分を自動化し、DevSecOps を使用して開発プロセスを全面的に刷新し、より効率的なサプライチェーンマネジメントを実現するため、部品供給 (PAS) システムも再構築しました。DSE 社は、このような成功を受け、同社の変革計画に関してはこれまでよりも少し自信を持っています。 

しかし、冷静に考えてみると、倉庫業務の刷新には非常に大きな課題があり、どのように対処すればよいのかわからない状態です。この記事では、DSE 社が Red Hat とベンダーのエコシステムを利用し、予知保全機能を追加してインダストリー 4.0 を導入する計画をどのように立てていくのかを紹介します。

インダストリー 4.0 とは?

インダストリー 4.0 は「第4次産業革命」とも呼ばれ、従来の製造業および業界の慣習における、自動化、通信、および自己監視の進化 を指します。

製造メーカーは、新たな効率化、高品質化を図り、顧客のニーズにもさらに対応していけるように、組み込みセンサーからロボットまで、モノのインターネット (IoT) や人工知能/機械学習 (AI/ML) を工場に統合しています。

問題

工場の運用は、PAS、DevSecOps プロセス、自動化を新規導入することで、これまで以上に効率的になりました。このように需要が増加し、工場の操業に負荷がかかり続けています。 

工場運用ディレクター、Stephanie Wilson 氏は、週次のグローバル生産報告書を見て気になる点がありました。中国の工場は、設備の故障で週の半分は停止していました。この事象は、Wilson 氏がこれまでに訴え続けてきたことを見事に再現しています。 

最初に、この障害についてリアルタイムで知ることができませんでした。週次レポートを見るまで、この障害について気づくことができませんでした。第二に、この障害が原因で、注文対応に深刻な負荷がかかります。Wilson 氏は、これは許容範囲を超えているため、不満を募らせていました。同氏は、製造関連の専門家のユーザーグループで、インダストリー 4.0 や、製造プロセスのあらゆる場面で、リアルタイムに情報を入手できる機能について耳にしていました。

今回の機能停止をきっかけとして、DSE 社のチーフアーキテクト、Daniel Mitchell 氏および CIO、Monique Wallace 氏とミーティングを招集しました。このミーティングでは、機械の停止や、今回の停止が原因の生産スケジュールの問題について説明しました。また、インダストリー 4.0についても簡単に紹介し、また、機能停止が引き起こす問題をどのように解決できるかについても説明しました。会議の一環として、設計中の新しいスマートウィジェットへの対応に必要な変更点についても議論します。 

モダナイゼーションが進むにつれて、大きな副次的な効果として、ウィジェットへの需要が増大しています。スマートウィジェットは、ウィジェット業界に大きな変化をもたらすでしょう。スマートウィジェットは、一般的なウィジェットがインテリジェント化されたものです。 

一意の ID が割り当てられた、このスマートウィジェットはネットワークに接続されており、現在の説明やステータスなどの情報を提供します。また、このウィジェットを使用すると、DSE が障害のあるウィジェットを、作成日、工場、工場のライン番号、稼働状況から追跡できるように一連の情報を入手できます。

DSE のこれらからが楽しみです。この打ち合わせをきっかけに、Wilson 氏は、世界中にあるすべての工場の運用に対してインダストリー 4.0 テクノロジー導入の許可を得ました。このように許可が得られたことに歓喜しているのですが、今後はどうしたらいいのかという、疑問が残ります。

インダストリー 4.0 へ出発

DSE 社の CIO、Wallace 氏と、チーフアーキテクト、Mitchell 氏、直属のリードアーキテクトを集めてミーティングを開催しました。 

今回のミーティングは、アーキテクトを集めて、現在のツール、ベンダー、すでに導入されている機能を評価し、Wilson 氏が定義した新しい要件を検証して、既存のツールやベンダーをまとめて使用することで、この新しいインダストリー 4.0 の要件に対応できるかを判断することが目的となっています。 

インダストリー 4.0 について学ぶにつれて、インダストリー 4.0 戦略を成功させるには、オペレーションテクノロジー (OT) チーム、情報技術 (IT) および事業部が連携しあうことが重要だと理解するようになりました。 

Figure 1. 図 1

上の図 1 は、典型的な インダストリー 4.0 のリファレンスアーキテクチャーを示しています。アーキテクチャーのコンポーネントのいずれかで、生データを収集する必要があります。 

このコンポーネントは通常、OT チームの責任下になります。OT は、製造ラインを動かすプログラムロジックコントローラ (PLC) を所有しており、また、PLC や製造ラインの機器を監視するコントロールセンターも運用しています。OT チームは、PLC のネットワークアクセス以外に、IT チームとのやり取りが必要になることはほとんどありません。 

インダストリー 4.0 戦略を成功させるには、組織内の他のメンバーや IT チームがその PLC データを利用できるように OT チームは PLC データを公開する必要があります。データが収集されたら、そのデータを処理するコンポーネントに共有する必要があります。このレベルでのデータの処理には、機器から送られてくる計測データのクレンジング、集計、フィルタリングなどが含まれます。不良または無効なデータでネットワークを輻輳させる必要はありません。 

最後の部分、そしておそらく最も価値のある部分ですが、取得した生のデータをインサイトに変えていき、その情報をもとにプロセス制御ポイントを動かしたり、その情報を実際にアクションを起こす人材に報告します。 

プロセス制御ポイントの運用は、インダストリー 4.0 の中でも非常に高度な部分で、OT チームのメンバーは、ここまではまだ対応するつもりはありません。問題の発生時に製造ラインを制御する方法を理解する知能がコンピューターモデルにあると確信できないからです。ただし、OT チームは、予知保全のユースケースの実装に対して、十分な PLC データを提供したいとも考えています。現時点では、OT と IT のみが必要で、事業部は必要ありません。

ソフトウェアとエコシステムの構築

このようなソフトウェアとエコシステムの構築プロジェクトはどのように開始したらいいのでしょうか? 

リファレンスアーキテクチャーの次のレベルまで掘り下げると、インダストリー 4.0 プロジェクトが複雑であることがわかります。組織間の境界を超えるだけでなく、ソフトウェアと機器が連携するベンダーやサプライヤーのエコシステムも必要です。 

Figure 2.

図 2

図 2 に示すように、PLC は小規模なファクトリサーバー (別称: ゲートウェイ) と通信する必要があります。ゲートウェイデバイスは、製造現場の厳しい環境に耐えられるように、堅牢化していく必要があります。 

また、この計測データの収集、フィルタリング、集約ソフトウェアスタックだけでなく、セキュアで安定したオペレーティングシステムも必要です。データは、収集してフィルタリングされると、データレイクの保存する必要があります。機械学習モデルなどのシステムは、このデータレイクで、データにアクセスしてさまざまなユースケースに対応します。 

このようなプロジェクトの開始にあたり推奨される事項の 1 つとして、既存のツールや機能を評価するという点がありました。幸い、OT チームは最近、通常の OPC (Object, Linking and Embedding for Process Control [OLE]) Windows ベースのプロトコルから、OPC Unified Architecture (UA) の使用まで、すべての回線の PLC を更新し、PLC は HTTP を介して通信できるようになりました。 

Red Hat OpenShift を使用したコンテナーオーケストレーション

このデータは、HTTP 経由で、社内の他のユーザーと簡単に共有できるようになりました。また、IT チームは、Red Hat OpenShift およびコンテナーオーケストレーションを導入した最初のDevSecOps プロジェクトを実装しました。 

HPE Edgeline Converged System を使用したデータセンターのニーズへの対応

また、IT チームは、データセンターのニーズに関して、Hewlett Packard Enterprise (HPE) と非常に強力な関係を築いています。パズルの最後の部分として、同社は長い間、統計、分析ニーズのほぼすべてを SAS に頼ってきました。 

業界全体でも、社内でも、機械学習向けにパブリッククラウドベースのサービスを利用する動きが強まっています。この内容はロードマップに含まれてはいますが、同チームはこれが正しいプロジェクトであるとは感じていません。インダストリー 4.0 を実現するためには、多くの要素が必要となるため、できるだけシンプルにしたいと考えています。今の所、すべてを地域のデータセンターに格納し、後でパブリッククラウドに移行していくということです。 Figure 3. 図 3

Red Hat 担当者からRed Hat Edge Reference Architecture for manufacturing に関するプレゼンテーションを受けたことを思い出しました (上図 3 を参照)。同じような 3 層構造のアーキテクチャーで、Red Hat OpenShift は 3 層すべてを動かすことができました。IT の観点からは、このアーキテクチャーにより、Edge ゲートウェイからデータセンターに至るまで共通のプラットフォームをサポートできます。 

また、ソフトウェアアプリケーションとネットワークの管理と保護がはるかに簡素化されます。また、エッジで Red Hat OpenShift を使用すると、データセンターアプリケーションを記述する開発者は、同じ DevSecOps の方法論とツールを使用してエッジアプリケーションを作成できます。

Red Hat にはすでに HPE と強力な協力関係があり、Red Hat OpenShift とRed Hat Enterprise Linux (RHEL) の両方が HPE Edgeline Converged System シリーズをサポートしています。この強力なシリーズは、データセンターのような電源および管理機能を提供しますが、DSE 社の製造工場の厳しい条件に対応できるように、より小型で堅牢な形式となっています。 

SAS Viya を使用した新しいモデルのデプロイ

DSE 社では、この 発表 から OpenShift で実行されている SAS Viya についても情報を取得しました。DSE のデータセンターではすでに、RHEL 上に SAS Viya を大規模に展開しています。SAS Viyaは、数時間ではなく数秒で結果を得ることができる大規模な並列処理に対応しています。さらに、意思決定の再現性、説明可能性、透明性、信頼性を高めるためのガバナンスが組み込まれています。 

DSE 社では、インダストリー 4.0 に着手した他の企業から、新しいモデルを導入して運用するのは困難になる可能性があると聞いていました。ですが、IT 開発チームはすでに SAS に精通しているため、OpenShift 上の SAS Viya にスケーラブルで運用可能なモデルを構築、展開することで、この作業が非常にわかりやすく簡単になります。 

DSE 社では、今回の調査をもとに、HPE、Red Hat、SAS が協力し、インダストリー 4.0 への道を歩み始めることができると確信しています。最終的に、DSE 社は、予知保全のユースケースを解決するための出発点として、独自のリファレンスアーキテクチャを構築します。 

以下の図 4 は、作成したリファレンスアーキテクチャーを示しています。  Figure 4.

図 4

予知保全のユースケースへの対処

DSE 社は、リファレンスアーキテクチャーを構築し、適切なベンダーを特定したことで、インダストリー 4.0 およびその計画への最初の一歩を踏み出す準備ができています。まだ課題は多くありますが、これが正しいアプローチであると確信しています。 

DSE チームは、1 つの製造ラインで、試験的に予知保全のユースケースに対応する予定です。部品の温度、振動、活動時間など、どのような計測データが必要かを判断します。次に、Red Hat AMQ on OpenShift を使用してすべてのコレクションおよびフィルター機能を構築する必要があります。データのフィルタリングが済むと、SAS Viya の機能を使用してデータを保存して、予測モデルのトレーニングに使用します。

このパイロットでは、ユースケースとテクノロジーを実証します。パイロットが完了したら、パイロットから工場内のすべてのラインにどのように展開していくかをまとめた展開計画を作成します。 

次のステップ

これが順調に展開が進むと、スマートウィジェットのプランニングを開始できます。スマートウィジェットでは、さまざまなアプローチが必要となる場合があり、当然ながら事業部の参加も必要になります。スマートウィジェットにより、新たに課題が出てきますが、今回の最初のプロジェクトで得た教訓は、将来の IoT やエッジのユースケースにも必ず役に立ちます。

DSE 社のこれまでの変革について見逃した内容がある場合には、一箇所に 過去の記事 をまとめていますので参照してください。こちら で、エッジコンピューティングに関する情報を確認することをお勧めします。


About the author

John Senegal is an ecosystem solution architect who works with strategic global partners to build joint and ecosystem solutions. His technology focus is around the AI/Ml and edge/ IoT partner ecosystems.

Read full bio