ãƒŸãƒ‹ãƒãƒ¥ã‚¢å·¥å ´ スマートファクトリーへの道

1. はじめに

本記事は、OpenShift Advent Calendar 2024 の12月23日の記事です。

みなさん、こんにちは。
ソリューションアーキテクトの小野です。
エッジコンピューティング厨です。

突然ですが…
我々はついにオフィスに工場を導入しました！
どーん！

おもちゃのミニチュアですが、実際の工場で使用されているPLCという設備で動作するようになっています。
いや〜、ハードウェアって、格好良いですね！

この工場の導入の背景には、昨年、ドイツのとある製造業のお客様の工場を見学させていただいたことにあります。その工場がとても刺激的で、その知見を日本に持ち帰って、みなさまに日本でも簡単に体験してもらえる環境を作れないかな、と思ったのがきっかけです。

昨今、製造業においても、市場のニーズや世界情勢の変化へ臨機応変に対応することが求められています。

その中で、従来の”カイゼン”による生産性向上に加えて、柔軟性や持続可能性の向上には、デジタル技術の活用が不可欠です。リーン生産によるカイゼンを継続するだけでは、どうしても限界があります。

そこで、IoTやAIなどのITの技術と、ロボットなどに代表されるOT（Operational Technology）の技術をシームレスに統合した、IT/OT融合、という考え方が着目されています。

本記事では、

IT/OT融合の定義と、世の中の動向を俯瞰した上で、僕たちが導入したミニチュア工場を通じて、レッドハットの実現するIT/OT融合の世界の片鱗を簡単に体験いただきたいなと思います。

本記事が、みなさんのIT/OT融合のイメージを具体化するお役立ちができたら幸いです。

2. IT/OT融合の動向

IT/OT融合というキーワードについて、インターネット上でさまざまな記事が存在します。
関係者の方は見聞きする機会も多いんじゃないでしょうか。

ただ、僕自身、この言葉を見て思ったのは、「融合と連携の違いってなんだろう」ということです。ネットでさまざまなスマートファクトリーの記事を目にします。でも、これって、融合なのかな、と。ここ数年ずっと考えてきました。

そこで、前述のドイツ出張の体験も踏まえて自分なりに整理してみたいと思います。

IT（情報技術）とOT（運用技術）の「融合」とは

IT/OT「融合」…融合というからには、

それぞれの独立した領域を保ちながら、データやシステムの一部を「共有」して、 業務の効率化や生産性の向上を目的に、究極的にはITとOTの双方のスペシャリティを持った同一または仮想的なチームで推進すること

くらい言っても良いじゃないでしょうか。

一方で、IT/OT「連携」というと、なんとなく、ITのチームとOTのチームがそれぞれ疎結合な印象を受けます。融合と連携では、微妙にゴールが違う気がするんです。

連携のゴールは、ITとOTがそれぞれの「独自性を保ちながら協力する」こと

であるのに対し、

融合は、ITとOTの境界がなくなり、一体化したシームレスなシステムやプロセスとして機能する状態を目指すこと

…なイメージです。

もう少し言うと、

• 連携のゴールは、業務の効率化や迅速な意思決定
• 融合のゴールは、より高度な自律化や、スマートファクトリーなどの先進的なシステムの実現

にあると言えます。

みなさんは、「連携」ですか？それとも、「融合」ですか？

ちなみに、IT/OT融合なOT製品とは、もはやITの影を感じることのないくらい当たり前にITが溶け込んでるOT製品、ということなのかも...汗

レッドハットの取り組み

こんなIT/OT融合の取り組みにおいて、レッドハットは何ができるのか？僕らとしては、やっぱり、みなさんにもっとアプリケーションに集中して欲しい！と思うわけです。

今年、「ソフトウェアファースト」という書籍の第二版が出版されたりしました。ハードとソフトが密結合して、ハード単位で提供される製品が多い組み込みの世界こそ、そして、こと日本においては、特にソフトウェアファーストという考え方が重要なんじゃないか！と、個人的に強く思います。

ITでもOTでも、アプリケーションを試しながら試行錯誤を早く回し、良いものはすぐに他の拠点へスケールしてノウハウを伝播できる…そんな体験を軸にして、スマートファクトリーを効率良く推進できるようにするのが、レッドハットのソリューションの基本です。言い方を変えれば、縁の下の力持ち的なポジションです。

そこで、レッドハットでは、IT/OT融合のプラットフォーム、というコンセプトで、お客様が、ITのアプリケーションもOTのアプリケーションも、共通のプラットフォーム上で動作させ、効率良く運用できるソリューションを提供します。

僕は、このプラットフォームで得られる体験を、よく「スマホみたいな世界観」と言います。

例えば、スマホアプリを試すみたいに、みなさんが使用している産業用パソコンへ、産業用のソフトウェアを簡単に配備でき、機能の改善やセキュリティパッチの適用、機能の追加を柔軟に行えたら、色々な運用課題に対処できそうじゃないですか？

こんなスマホみたいな世界観は、まさに産業オートメーション製品で実現されようとしています。

PLCをソフトウェアで定義する

レッドハットは、昨年より、Intel、レッドハットと、グローバルのコントロールベンダの3社で、Virtual PLCの実現を推進しています。

www.redhat.com

www.redhat.com

Virtual PLCは、従来、専用ハードウェアで提供されてきたPLCを、汎用ハードウェア、つまり産業用PC上のソフトウェアとして提供する取り組みです。

従来のPLCは、専用のWindowsのクライアントツールとして提供されるIDEを用いて制御プログラムを開発し、IDEからPLCに、開発した制御プログラムを書き込んで動作させるのが一般的です。ちなみに、制御プログラムの動作環境はRTOSが採用されます。

Virtual PLCは、その制御プログラムやプログラムの実行環境をコンテナイメージの単位でパッケージ化し、PodmanやMicroShift（小型デバイス向けの軽量OpenShift）といったコンテナの管理環境へ展開されます。また、コンテナ化に伴い、IDEもWeb IDEになってたりします。

すでに、CodesysやSchneider Electricといった企業が、Virtual PLCの提供を開始しました。

www.codesys.com www.redhat.com

なお、PLCのような決定論的なワークロードを汎用Linuxで安定して動作させるために、Intel ECI(Edge Controls for Industrial)というオープンソースの提供するドライバの利用が推奨されます。参考までに、こちらのホワイトペーパーをリンクしておきます。

PLCの制御プログラムをコンテナ化することで、制御プログラムの展開の柔軟性の向上や展開作業の効率化が可能です。でも、PLCの制御プログラムの展開が柔軟になると何が嬉しいの？と思うかもしれません。

このメリットは大きく3つがよく取りあげられます。

①PLCのハード故障時の駆けつけ保守のコスト削減

従来のPLCで、HA構成を組むことが可能な製品も少なくありません。たとえば、ハードウェアが1台故障した際に、予備系のPLCが主系へ昇格し、設備の稼働を継続させる、という具合です。しかし、電力プラントなど、無人の環境で、かつ全断による社会的影響が大きいような設備では、ダウンタイムの長期化は命取りです。故に、PLCが片系運転となった際は、早期に両系運転へ復帰できるように、人が現地へ駆けつけて、故障したPLCを交換する作業を行っていたりします。

この課題に対し、PLCがコンテナとして動作して制御プログラムの展開を効率良く行えることで、たとえば、予備系のハードを2台以上配置し、片系運転のリスクを回避することができます。
これにより、故障したPLCを、まとめて決められた日に一括交換する、といった対応が可能になります。

その結果、人の派遣コストを減らし、コストを最適化できるよね？という点が、一つ目のメリットです。

www.youtube.com

www.redhat.com

②ハードウェア集約によるハードウェアコストの削減や、配線変更のしやすさの向上

PLCは一般に、工程毎やロボットなどの設備毎に配置されます。そして、PLCと設備の間には、多くの配線が複雑に絡み合っているのをよく目にします。工場のフィールドには、多くのハードウェアが存在し、その管理はとても煩雑です。

実際、我々のミニチュア工場の環境は、せいぜい10台くらいのハードウェアしかないのに、すでに配線が複雑怪奇になりつつあります。片付けられない人がチームにいないので、なんとか救われてますが...

ハードウェアが増えると、もちろん配線も更に複雑になってくるので、ラインの組み替えなど、配線変更が伴うような作業が一筋縄ではいきません。よく、夏休みの間にライン組み替えに対応しているお話を耳にしますが、将来的にその頻度が多くなってくると、それだけ設備の稼働率に響いてきます。

Virtual PLCは、コンテナとして共通のハードウェア環境で複数台のPLCを実行できることで、必要なハードウェアの数を減らし、ハードウェアの管理コストの削減につながります。そして、ハードウェアが減るに伴って、配線を簡素化でき、それがダウンタイムの短縮につながり、設備稼働率の向上に寄与する、という点が二つ目のメリットです。

③変種変量生産の生産能力の向上!?

昨今、顧客のニーズへ柔軟に対応するために、同じシリーズの製品でも、製品毎に仕様が異なるということが珍しくありません。製品の品種が多いと、それだけ、製造計画にばらつきが生まれます。たとえば、今日は品種Aが100台、品種Bが500台、明日は品種Aを10,000台製造する、と言うように、日によって製造台数が異なるようなケースがあり得ます。

いわゆる変種変量生産に対応するために、大量生産に向いてるライン生産でなく、セル生産への切り替えが進められています。

セル生産を自動化するために、多くのロボットの整備が進められています。しかし、従来のPLCでは、どうしてもロボット一台に対して、一つの役割しか持たせることができません。

変種変量生産で大量生産に対応するためにはどうすれば良いでしょうか？...そう、大量のロボットを整備すれば良いのです(爆)。 しかし、現実には、ロボットへの投資規模が大きくなりコストが最適化されない、また、ロボットを設置するスペースが枯渇する、電気代も高くなる…、といった問題も出てきます。

そこで、Virtual PLCです。
コンテナのメリットにより、制御プログラムの変更や更新を柔軟に行えるならば、ロボット一台の役割を柔軟に変更し、一台の同じロボットに複数の異なる仕事を任せることができるんじゃないか...？ということで、そのような期待の元、海外の一部の企業でもPoCの動きがチラ見えし始めています。

Virtual PLCが、既存のロボットの再利用性を向上させる...僕個人は、まるでロボットのリソースプール化や！と、一人で勝手に興奮を抑えられない模様です。

そして、妄想は尽きない...

このような「スマホみたいな世界観」の実現する姿は、「アプリを色々試しやすくなる」だけではありません。

さらにでかいことを言うと、Amazonや楽天のように、スマホアプリで商品を注文すると、いつまでに商品が手元に届くのか瞬時に画面に表示され、実際に配達される…こんな世界観が製造業のサプライチェーンでも実現できたら、多くの企業の競争力の向上に繋がりませんか？

僕は最近ユニクロのUTime!というスマホアプリで、ペットの犬のオリジナルTシャツを作るのにハマっています。 スマホアプリでTシャツのデザインをして、オーダーボタンを押すと、いつまでにTシャツが届くのかスマホアプリに表示されます。 こんな世界観が、もっと多くのモノづくりに広がったら、世の中変わる気がします。

実際の製造業では、営業からの注文オーダが入ってから、さまざまな工程で人手による確認と調整が行われます。ロットの生産計画の確認、部品表から部品在庫の確認、設備や人のスケジュールの作成、設備へのセットアップ、原価への反映、製品価格の確定、流通計画、などなど…

それらが裏で全て自動化されるイメージです。つまり、製品を納品するまでに介在する人による確認・調整のプロセスが、データ連携で自動化される世界観の実現です。これは、エンドユーザに対して圧倒的なリードタイムを提供し、エンドユーザの体験を変容することになる…まさに、製造DXの究みじゃないか！！

しかし、現実はそう簡単ではありません。
こんな夢のようなサプライチェーンを構築するには、企業間のデータ共有も必要となります。
これは、なかなかハードルが高いなぁ...と。

そうした企業間のデータ共有のあり方は、欧州のManufacturing-Xというデータ共有基盤の構築を図るプロジェクトで推進されています。でも、いきなり企業間でデータを共有し合う姿を目指すのはなかなか勇気が要ります。故に、最初はもちろん自社内がスコープになりますよね。

アプリだけでなく、データ連携を効率化し、IT（経営、計画）とOT（現場）をシームレスにしていく活動も、製造DXの重要な取り組みです。この部分は、レッドハットの提供する様々なミドルウェア製品が色々役に立つのですが、その話はまた今度、深掘りしたいと思います。

Linux Foundation配下に「margo」設立

そんな中、今年、Linux Foundation配下に、突如「margo」というプロジェクトが設立されました。これは、グローバルの様々なコントロールベンダーが推進するプロジェクトで、オープンな技術をベースとしたプラットフォームの相互運用性を実現する、標準化の取り組みです。

現状は、以下の図にあるような構成の元で、プラットフォームのインタフェース仕様が定義されています。ぱっと見わかる方にはわかると思いますが、コンテナやKubernetesといったクラウドネイティブな技術がベースとなってます。

ハードウェアビジネスからソフトウェアビジネスへ、モノ売りからコト売りへのシフト…そのような新たなビジネスモデルへの挑戦に向けて、産業オートメーションの変革がまさに議論されてます。

margo.org

3. ソフトウェアファーストでミニチュア工場をスマート化してみよう！

長々とIT/OT融合の動向を書いてしまいましたが...汗

みなさん、ここからが本番です！
ここからは、みなさんに、IT/OT融合によるソフトウェアファーストな世界観を簡単に体験してもらいたいと思います。

本デモの目的と流れは以下です。

デモは、以下の動画から視聴できます！
ショート版は1.5分で概要だけわかるようにしてます。
詳細を見てみたい方はフル版をご視聴ください。(11分程度あります)

ショート動画(約1.5分):

www.youtube.com

フル動画(約11.5分):

youtu.be

⚠︎音声付きですので注意！また、字幕ONで見ていただくと見やすいかなと思います。

ミニチュア工場について簡単に解説

ミニチュア工場についての解説は、弊社の工場長が以下のブログを書いてくれてます。詳細は、こちらをご参照ください！

rheb.hatenablog.com

ここでは、デモを理解いただく上で、最低限の情報をまとめておきます。
まず、ミニチュア工場は、大きく5つの設備で構成されています。

1. 自動倉庫

倉庫には、赤・青・白の3色のボールが3つずつ、合計9つあります。これらのボールを一つずつ出庫し、搬送ロボットへ引き渡す工程です。デフォルトでは、白のボールから出庫し、白が3つ出庫されたら、赤が出庫される。赤の出庫が終われば、青が出庫される...というように、白、赤、青の優先度でボールを出庫するように実装されています。この辺の、出庫したいボールの色の優先度は、PLC内のパラメータを変更することで、調整できます。

2. 搬送ロボット

搬送ロボットは、倉庫から出庫されたボールを加熱装置へ引き渡す工程です。

3. 加熱装置

加熱装置では、ボールごとに決められた秒数だけ、擬似的に加熱処理を行います。加熱時間は、PLC内のパラメータで管理されていますが、デフォルトでは変更できません。

強制的に変更することは可能です

4. 研磨装置

研磨装置では、ボールごとに決められた秒数だけ、擬似的に研磨処理を行います。研磨時間は、加熱装置と同様に、PLC内のパラメータで管理されていますが、デフォルトでは変更できません。

強制的に変更することは可能です)

5. 仕分け装置

最後に、仕分け装置は、研磨加工したボールを、赤、青、白の決められた箇所に仕分けして格納する工程です。ボールの色の特定には暗明センサーが使用されます。

この5つの装置が連携して、ミニチュア工場が動作します。
工場の動作には、三菱電機のMELSEC Qシリーズを使用し、同様に三菱電機の表示器であるGOTを使用して、PLCのパラメータの変更や工場の稼働・停止を制御できます。また、Red Hat Device Edgeをインストールするデバイスとして、本デモでは、Advantech UNO-137を使用しています。

PLCのデータを取得するためには、制御プログラムが、PLC内の各レジスタを、どのような用途で利用しているのか、事前に把握しておく必要があります。一般に、PLCの制御プログラムを実装する際には、各レジスタの用途をコメントとして残しておくと思います。このコメントをPLCのIDEからエクスポートして、以下のように、エクセルか何かで整理しておくことをオススメします。

ちなみに、このミニチュア工場では、2106点くらい使用しています。

なお、ミニチュア工場には、倉庫からボールを出す出庫モードと、仕分けされたボールを倉庫へ戻す入庫モードの2つのモードが実装されていますが、本デモでは出庫モードのみ使用しています。

最後に、ミニチュア工場の動作フロー (出庫時) をまとめると、以下の通りです。

以降、本デモの構成やどう実装しているのかについて簡単に解説します！

デモの解説

アプリのインストール

みなさんが初めてスマホを手にした時って、どんなことを試しましたか？
多くの方は、App Storeなどにどんなアプリがあるのか眺めてみて、面白そうなアプリをインストールして試してみたと思います。

このように、ソフトウェアファーストでは、アプリをすぐに試せるようにする仕組みがとても重要です。

本デモでは、その仕組みを、Red Hat OpenShiftとRed Hat Device Edgeを連携させて実現しています。

以下に、簡単な構成を示します。

OpenShiftには、自身の外側にある複数のKubernetes環境を一元管理する「Red Hat Advanced Cluster Management for Kubernetes(RHACM)」という機能があります。RHACMは、OpenShiftの追加機能として提供され、管理対象の環境にラベルを付与して、そのラベルを指定することで、どの環境にアプリを配信するのか制御できます。

本デモでは、産業用PCにインストールされたRed Hat Device Edgeを、RHACMの管理下に置き、産業用PC毎に固有のラベルを付与して、アプリを配信する対象の産業用PCを特定する、という仕組みで実装されています。

また、OpenShiftには、もともとアプリをカタログとして公開する機能があります。このカタログの機能を活用し、RHACMの設定を固めて、OpenShift上にカタログとして公開することで、カタログの操作で、産業用PCへアプリを配信することができます。

一方、Red Hat Device Edgeは、「MicroShift GitOps」という、Gitリポジトリに配置されたアプリの構成情報をデバイスへ同期するためのコントローラをオプションとして提供しています。この仕組みを使うと、アプリの管理者がアプリをカタログとしてOpenShift上に公開した後、アプリの細かい修正や機能追加をしたいときに、再度カタログへ修正版を公開し、ユーザのカタログ操作で更新してもらうのでなく、管理者自身で人知れず行いたい、というケースに対応できます。

つまり、本デモでは、以下のシナリオでアプリを運用することとしています。

• アプリの大きな更新は、アプリの管理者が修正版をカタログに公開し、ユーザがセルフサービスで実際のアプリケーションに適用する（App Storeでアップデートボタンを押すイメージ）
• ユーザに気づかれない様に細かい修正を反映したい、という際は、アプリの管理者が、Gitリポジトリ上のアプリの構成情報を修正する（スマホアプリのWebviewで表示されるコンテンツが、微妙に更新されるイメージ）

このような、Gitリポジトリでの管理や操作を中心に、アプリを運用する方法を「GitOps」と呼びます。

ここまでの情報を整理すると、一つ目のデモでは、以下の流れで、産業用PCへのアプリの配信を実現しています。

1. RHACMが産業用PCを管理し、各デバイスにはそれぞれラベルが付与されている
2. ユーザは、カタログの操作の中で、ラベルを指定し、インストールボタンをクリックする
3. 指定されたラベルに対応する産業用PCへ、MicroShift GitOpsの設定が配信される
4. 産業用PCは、適用されたMicroShift GitOpsの設定に基づき、Gitリポジトリからアプリの構成情報を取得する
5. 産業用PCは、MicroShiftの機能を使って、取得した構成情報に基づき、アプリを起動する

アプリの設定作業の自動化

よくあるエンタープライズ向けの業務アプリは、インストールした後、アプリの設定作業が必要です。
だけど、スマホアプリって、インストールしたら特に難しい設定もなく、すぐに利用できますよね？

アプリを簡単に利用できるようにするには、設定作業を自動化して、人のスキルギャップを埋めたり、アプリを利用開始するまでの時間を短縮したりする工夫がとても大切です。

レッドハットは、IT/OT融合プラットフォームに対応するアプリを増やすために、多くのパートナーさんとの協業を進めています。その中でも、今回のデモは、「たけびし」という会社の「DeviceGateway」というアプリを利用しています。

DeviceGatewayは、レッドハット認定コンテナとして公開されています。 また、Red Hat Device Edgeを産業用PCに組み込んだ形でのご提供も可能です。興味のある方はぜひ見てみてください！

tv.redhat.com

www.faweb.net

このDeviceGatewayは、専用のWebコンソールがDeviceGateway毎に提供され、設備との通信設定や、設備から取得したデータをITシステムと連携する設定などを行えるようになっています。しかし、DeviceGateway 1台ずつ設定する作業は、結構大変です。設定自体は超簡単なのですが、台数が増えてくると時間がどうしてもかかります。

そこで、レッドハットとたけびしとの協業で、このDeviceGatewayの設定作業を自動化するソリューションを開発し、今回のデモで活用しています。

今回のデモでは、協業のソリューションを応用して、DeviceGatewayの設定作業をGitOpsの方法で行えるように拡張しています。

DeviceGatewayは、設定された情報を設定ファイルとして内部で保持します。この設定ファイルは、Webコンソールの操作で、ローカルにエクスポートできるようになってます。今回は、DeviceGatewayの横に一台コンテナを追加し、DeviceGatewayの設定ファイルがエクスポートされたら、Gitリポジトリに自動バックアップするように、機能をちょっとだけ拡張しました。

そして、GitリポジトリにあるDeviceGatewayの設定ファイルの中で、一つマスターとするものを指定すると、本番環境のDeviceGatewayに、マスターとした設定ファイルが適用される、という仕組みを実装してみました。

マスターとする設定ファイルは、以下のような感じで指定できます。Kubernetesには、自身のAPIを拡張して、カスタムのAPIを追加できる機能があります。その仕組みを利用して、Kubernetesが、DeviceGatewayの設定の状態を管理するようにしています。

apiVersion: dgw.io/v1
kind: DeviceGatewayAutomationAgent
metadata:
  name: setting
spec:
  gitRepo: "https://gitlab.com/yono1/dgw-auto-config-setting-files"
  gitFilePath: "dgw-settings"
  gitFileName: "export_all.dxg" -> ここに複数台へ適用したい設定ファイル名を指定する
  applicationName: "dgw"
  namespace: "cps"

本デモの実装で面倒だったのは、ミニチュア工場自体が会社にあって、リモートから開発作業を進めるのが難しかったことです。僕の家には、DeviceGatewayの開発環境があるのですが、何回もDeviceGatewayの設定を変えて動作検証を繰り返していると、開発環境で固めた設定ファイルをローカルにエクスポートし、本番環境にコピーして、DeviceGatewayに適用する、という作業が地味に苦痛でした。

この仕組みを取り入れたことで、家でDeviceGatewayを検証する→会社に来た時に、本番環境のDeviceGatewayに設定が反映されている！という感じで、ちょっとだけ開発作業を効率化できた気がします。

ITシステムと設備の連携

ここまでの流れで、アプリを産業用PCへインストールして、設定が完了したら、ミニチュア工場をちょっとだけ賢くしてみましょう。

今回のデモでは、設備とITシステムとを連携させる、という方法で、ミニチュア工場を賢くします。

ミニチュア工場には、前述のとおり、赤・青・白の3色のボールが存在します。これらを「品種」とみなし、品種毎にITシステム側で納期が管理されていることを想定して、その納期情報を設備と連携させてみました。

動作の流れは、以下のとおりです。

1. 生産管理の担当者が、生産管理システムへ、品種毎に製造オーダと納期情報を登録する
2. 生産管理システムの情報をMES(Manufacturing Execution System: 製造実行システム)と連携させて、製造オーダから製造ロットを作成し、ボタンを押すと自動的に作業計画が自動出力される
3. 設備を稼働させると、MESの作業計画とPLCが連携し、納期順にボールが倉庫から出庫される

設備とITシステムの連携には、OPC-UAという産業系の標準プロトコルを採用しています。OPC-UAは、クライアント-サーバの構成で、産業設備のデータを外部のシステムと連携できるプロトコルです。最近は、OPC-UAサーバの機能が具備されたPLCも少なくありません。しかし、世の中には、導入以降、20年以上使い続けられているPLC、というのも多いのが実情です。昔からある工場の設備は、そもそもOPC-UAに対応していないケースがよくあります。

そんなときに、たけびしのDeviceGatewayを利用すると、たけびしのDeviceGatewayが旧型のPLCと連携して、上位システム側にOPC-UAサーバとして振る舞う構成を実現できます。多くのメーカーのPLCやセンサーなどと簡単な設定で連携できる様々なドライバーを内包しているのが、DeviceGatewayの便利なところです。
そして、ITシステム側は、OPC-UAクライアントとして、DeviceGateway経由で、PLC内のレジスタの値の読み書きを行います。

まとめると、以下の構成で、ITシステムで管理される計画値を元に、設備を動作させることができました。

まとめ

本稿では、レッドハットのオフィスに常設しているミニチュアの工場を使って、ソフトウェアファーストで工場をスマート化する様子を体験いただきました。

ご覧いただいたように、まだまだ拡張の余地はたくさんあります。我々、レッドハット工場 生産技術部のメンバーは、日々スマートファクトリーに向けて試行錯誤を繰り返しています。
そんな中で、LLMとも友達になれました。その辺も、今度、近況報告できたらなと思います。

ちなみに、次は、ボールにQRでも貼ってトレーシングできるようにしたり、画像AIと連携させて製品検査の工程を追加したりしたいなぁ、とアイディアは尽きません。
ミニチュア工場を軸としたアイディアソンやIT/OT融合のワークショップなんかも開催させていただいたりしてますので、興味のある方がいましたら、ぜひご連絡いただけると嬉しいです。

また、今回見ていただいたようなソフトウェアファーストな考え方は、工場だけでなく、さまざまな取り組みにも、もちろん応用できます。
ぜひ、「スマホみたいな世界観」を一緒に議論しましょう！

最後に、宣伝！
2月13日のオンライン開催の「Virtual IT Expo 2024冬」というイベントに出展します。

promotion.itmedia.co.jp

オンラインですが、ミニチュア工場のデモや、もう少し詳しい事例の紹介なども行います。興味のある方はぜひお越しくださいー！

それでは！