JP6792125B1 - エッジシステム、エッジシステムの制御方法、エッジシステムの制御に用いるコンピュータプログラム、及び、その記録媒体 - Google Patents

Abstract

【課題】初期導入時等のシステム設定における工数の低減を図る。【解決手段】オーケストレーション技術により論理的に割り当てたハードウェアリソースを用いてコンテナを動作させることにより所定の機能を実現するエッジ端末により構成されるエッジシステムであって、前記エッジ端末は、所定の設定情報に基づいて、対応するイメージを、イメージレジストリから取得し、取得した前記イメージを用いて、前記エッジ端末へとデプロイを行い設定処理を行う、エッジシステムが提供される。【選択図】図６

Description

本発明は、コンテナオーケストレーション技術を利用したエッジシステム、エッジシステムの制御方法、エッジシステムの制御に用いるコンピュータプログラム、及び、その記録媒体に関する。

工場や建設現場等のローカル環境において、所定の作業を行う作業機器に関連する情報をセンサにより取得し、取得されたセンサ情報の監視や、センサ情報に基づいた作業機器の制御を、ネットワーク側、すなわちクラウドから行うシステムが知られている。しかしながら、この種のシステムにおいて作業機器やセンサの数が多数となると、センサ情報のデータ量や処理負荷の増大に伴い、ネットワーク負荷の増大、処理時間の遅延の問題が生じる。また、情報セキュリティ等の懸念も存在する。そこで、センサ情報の処理をネットワークの末端（エッジ）であるローカル環境、例えば、工場内などにおいて行うエッジシステムが検討されている。

一方、ローカル環境においてセンサ情報の取得や解析などを行う技術が近年注目されており、エッジコンピューティング又はＭＥＣ（Mobile Edge Computing）等と呼ばれている。このとき、ローカル環境に配置される機器は、エッジ端末又はＭＥＣ等と呼ばれる。ところで、エッジ端末において、多数の機能を実現しようとすると、ホストＰＣにインストールされたＯＳ（オペレーションシステム）上において、複数のアプリケーションを動作させることとなる。しかしながら、複数のアプリケーションを同時に動作させる場合には、ＯＳにおけるシステムリソースをアプリケーション間で共有する必要があるため、ＯＳ毎にアプリケーションの設計を変更しなければならず、開発負担が大きい。

そこで、エッジ端末のＯＳ上で論理的な区間を作り、その区画内で、アプリケーション本体に加えてアプリケーションの動作に必要な環境をまとめたコンテナアプリケーションを展開（デプロイ）する技術が知られている。この技術によれば、ＯＳ上のリソースを論理的に分離して複数のコンテナに使用させることができる。そのため、アプリケーションの設計のＯＳ依存性が低減し、システム開発の負担を軽減することができる。このようなコンテナ技術は、ＯＳ上にインストールされるコンテナ管理ソフトによって実現される。コンテナ管理ソフトの一例として、Ｄｏｃｋｅｒなどがあげられる（例として、特許文献１）。

近年、コンテナ技術の進化や、システムの冗長化の要望に伴って、ネットワーク接続、記憶領域、及び、ホストＰＣの設定が複雑化しており、複数のコンテナアプリケーションをスケジューリングする必要性が高まっている。そこで、これらの設定を自動的に行いコンテナアプリケーションの管理を統合的に行うオーケストレーションツールの開発が進められている。

オーケストレーションツールが用いられることにより、複数のコンテナアプリケーションのデプロイ、実行、管理及びスケジューリングなどを容易に行うことができるため、さらにシステム開発の負担が軽減されている。コンテナオーケストレーションツールとしては、Ｋｕｂｅｒｎｅｔｅｓ、Ａｐａｃｈｅ Ｍｅｓｏｓなどが知られる。

国際公開第２０１８／００３０２０号

エッジ端末においては、ＯＳ、コンテナエンジン、オーケストレーションツールをインストールした後に、さらに、個々の制御を行うコンテナをデプロイする必要がある。しかしながら、エッジシステムを構成するエッジ端末が多数存在する場合には、エッジシステムの初期導入時においてソフトウェア設定をエッジ端末において行う必要がある。そのため、多数の工数を要するおそれがあるだけでなく、それぞれの設定作業が異なるため設定誤りなどが生じるおそれがある。

本発明は、このような課題を解決することを目的としており、エッジシステムの初期導入時等のシステム設定の工数の低減を図ることができる。

上述の課題は、以下の構成を有するシステム等により解決することができる。

すなわち、本発明の一態様に係るシステムは、オーケストレーション技術により論理的に割り当てたハードウェアリソースを用いてコンテナを動作させることにより所定の機能を実現するエッジ端末により構成されるエッジシステムであって、前記エッジ端末は、所定の設定情報に基づいて、対応するイメージを、イメージレジストリから取得し、取得した前記イメージを用いて、前記エッジ端末へとデプロイを行い設定処理を行う。

本発明の一態様によれば、ローカル環境において、設定サーバが、記憶している設定情報に応じて、ネットワーク上のイメージレジストリに記憶されているイメージの中から初期設定等のシステム設定の際に必要なファイルをエッジ端末に転送することで、エッジ端末におけるデプロイが行われる。ここで、エッジ端末のそれぞれについての設定を個々に行う場合には、多くの工数を要してしまう。これに対して、本発明においては、ローカル環境内に設けられる設定情報を利用して設定を行うことができるため、エッジ端末の設定を誤りなく行うことができ、また、工数の低減を図ることができる。

図１は、第１実施形態に係るエッジシステムを示すブロック図である。 図２は、ＭＥＣのハードウェア構成図である。 図３は、ＭＥＣのソフトウェア構成図である。 図４は、オーケストレーションツールが用いられる場合のＭＥＣのソフトウェア構成図である。 図５は、ＭＥＣの設定情報を示すテーブルである。 図６は、ＭＥＣの設定制御を示すフローチャートである。 図７は、デプロイされるプログラムの一覧を示すテーブルである。 図８は、第２実施形態に係るエッジシステムを示すブロック図である。 図９は、複合機の構成を示すブロック図である。 図１０は、ＭＥＣの設定情報を示すテーブルである。 図１１は、第２実施形態に係るＭＥＣの設定制御を示すフローチャートである。

以下、図面を参照して、本発明の第１実施形態について説明する。

（第１実施形態）
図１は、本発明の実施形態に係るエッジシステムを備える監視システムの構成を示すブロック図である。この図に示されるように、監視システム１００において、ローカル環境１１に設けられたエッジシステム１０は、ＷＡＮ（Wide Area Network）１３に接続され、ＷＡＮ１３を介してターミナル１４及び、イメージレジストリ１５と通信可能に構成されている。

エッジシステム１０は、一例として、工場や建設現場などのローカル環境１１において、製造工程や建設工程などの監視をするとともに、これらの工程に用いられる作業機器を制御するシステムである。エッジシステム１０は、通信や制御などの複数の機能を実現する複合機１２により構成され、本実施形態においては、１つの複合機１２によって構成されている。なお、複合機１２は、ＭＥＣ１６、作業機器１７、センサ１８を備える。また、エッジシステム１０は、無線通信又は有線通信によりＷＡＮ１３と接続される。なお、ＷＡＮ１３は、その一部または全部が移動体通信ネットワークにより構成されてもよい。また、本実施形態においては１つの複合機１２を備えるシステムを例示したが、このような構成に限定されず、複数の複合機１２を備えるシステムとしてもよい。

ＷＡＮ１３には、ターミナル１４、及び、イメージレジストリ１５が接続される。エッジシステム１０、ターミナル１４、及び、イメージレジストリ１５は、ＷＡＮ１３を介して相互に通信できる。

ターミナル１４は、ディスプレイ、ＣＰＵ（Central Processing Unit）及びＧＰＵ（Graphics Processing Unit）、メモリ、ネットワークインターフェースなどを備える機器であり、ＷＡＮ１３を介してエッジシステム１０と接続され、エッジシステム１０から送信される監視結果を表示する。ターミナル１４は、例えば、パーソナルコンピュータ、スマートフォン、及び、タブレット端末などの表示部を備える情報端末である。

イメージレジストリ１５は、一例としては汎用的なデータサーバである。後述のように、エッジシステム１０を構成する複合機１２の一部であるＭＥＣ１６においては、コンテナオーケストレーション技術を用いてコンテナが実行されており、イメージレジストリ１５には、ＭＥＣ１６にデプロイされるコンテナのイメージが記憶されている。オーケストレーションツールを実現する手段としてbitbucket又はConcourse CI等のシステム環境構築ツールを用いてもよい。

イメージレジストリ１５に記憶されているコンテナのイメージは、ＷＡＮ１３を介してエッジシステム１０へと送信されて、複合機１２のＭＥＣ１６においてデプロイされる。

ここで、ＭＥＣ１６について詳細に説明すれば、ＭＥＣ１６は、エッジ端末の一例であって、コンテナオーケストレーション技術を用いて制御されるコンテナにより、作業機器１７の制御やセンサ１８により取得されるセンサ情報の収集などを行う。ＭＥＣ１６は、ＣＰＵ及びＧＰＵ、メモリ、及び、ネットワークインターフェースなどを備える機器であり、記憶されたプログラムを実行可能に構成されている。ＭＥＣ１６は、汎用的なコンピュータを用いて構成してもよいし、専用端末であってもよい。

ＭＥＣ１６には、ＯＳ（Operating System）上に、コンテナオーケストレーションを実現するミドルウェアがインストールされている。そして、ＭＥＣ１６においては、所定の機能を実現するコンテナがデプロイされる。なお、ＭＥＣ１６については、後に、図２を用いてハードウェアの構成を説明し、図３を用いてソフトウェアの構成を説明する。

ＭＥＣ１６は、主に、ローカル環境１１内における作業機器１７の制御情報や、センサ１８により取得されるセンサ情報などについて監視や機械学習などを行う。ＭＥＣ１６は、無線通信又は有線通信を介して、監視結果や機械学習により得られる学習済みモデルなどを、ターミナル１４へ送信する。

作業機器１７は、ローカル環境１１内における製造工程や建設工程の１つまたは複数において用いられる機器であり、例えば、工場におけるロボットアームや建設現場におけるトラック等の中・大型機器から、半導体基板から成るディスプレイモジュール等の小型機器まで様々である。

センサ１８は、作業機器１７に直接又は間接的に関連する情報を取得する機器であり、例えば、カメラや赤外線センサなどである。センサ１８は、取得したセンサ情報をＭＥＣ１６に出力する。

図２は、ＭＥＣ１６のハードウェア構成図である。

ＭＥＣ１６は、全体を制御するＣＰＵ及びＧＰＵ等により構成される制御部２１と、ＲＯＭ（Read Only Memory）、ＲＡＭ（Random Access Memory）、ハードディスク又はストレージ等により構成され、プログラムや各種のデータ等を記憶する記憶部２２と、外部機器とのデータの入出力を行う入出力ポート２３と、他のＭＥＣ１６と通信を行う通信部２４と、ディスプレイ、ＬＥＤ、又はスピーカ等からなりデータに応じた表示を行う表示部２５と、外部からの入力を受け付ける入力部２６と、を備える。制御部２１、記憶部２２、入出力ポート２３、通信部２４、表示部２５、及び、入力部２６は、バス接続により互いに通信可能に構成されている。なお、このハードウェア構成は、ＦＰＧＡ、ＧＰＵ−ＣＵＤＡ等の半導体回路に用いられるプログラムによって所定の機能を実行するハードウェア回路でもよい。

図３は、ＭＥＣ１６のソフトウェア構成図である。

ＭＥＣ１６は、ハードウェア３１の上に、Ｌｉｎｕｘ（登録商標）等のオペレーションシステム（ＯＳ）３２がインストールされている。オペレーションシステム３２においては、汎用ミドルウェア３３に加えて、コンテナエンジン３４、及び、コンテナエンジン３４とともに動作するオーケストレーションツール３５がインストールされている。

ＭＥＣ１６においては、コンテナエンジン３４、及び、オーケストレーションツール３５によって、コンテナ３６のデプロイ及び実行がなされる。コンテナ３６には、所定の機能を実現するアプリケーション（ＡＰＬ）３７に加えて、コンテナエンジン３４の動作仕様に従いアプリケーション３７の動作に主に用いられる専用ミドルウェア（ＭＷ）３８が含まれる。なお、ミドルウェア３８は、ライブラリなどを含んでもよい。

ハードウェア３１は、図２に示されたハードウェア構成を備える。これらのハードウェア３１のリソースを用いて、ＭＥＣ１６は所定の動作を行うことができる。

オペレーションシステム３２は、ＭＥＣ１６におけるソフトウェア構成の基本システムである。オペレーションシステム３２によって、ＭＥＣ１６の全体の動作が制御される。

汎用ミドルウェア３３は、一般に、オペレーションシステム３２のベンダーなどにより提供される機能ブロックであり、図２に示された通信部２４による通信機能や、表示部２５による表示動作、入力部２６からの入力制御などの、基本的な動作を実現するための機能ブロックである。さらに詳細には、汎用ミドルウェア３３は、ＭＥＣ１６における全体のソフトウェアにおいて、アプリケーションフレームワーク、データベース、及び、スクリプト型プログラミング言語のエンジン等であって、ソフトウェア構成において基本的な動作を実現する。汎用ミドルウェア３３は、プラットフォームと称されることもある。

コンテナエンジン３４は、オペレーションシステム３２にインストールされるミドルウェアの１つであって、コンテナ３６を動作させるエンジンである。詳細には、コンテナエンジン３４は、コンテナ３６内のミドルウェア３８に含まれる設定に基づいて、ハードウェア３１及びオペレーションシステム３２のリソースをコンテナ３６へ割り当てる。

オーケストレーションツール３５は、コンテナエンジン３４に対してハードウェア３１などのリソースの割り当てを行わせる機能ブロックである。オーケストレーションツール３５によって、１つ又は複数のコンテナ３６がポッド（図３において不図示）と称される単位にまとめられ、各ポッドが論理的に異なるエリアであるノード（図３において不図示）にデプロイされる。オーケストレーションツール３５による動作の詳細については、後に図４を用いて説明する。なお、コンテナエンジン３４、及び、オーケストレーションツール３５は、ミドルウェアと称されることもある。

コンテナ３６は、所定の機能を実現するアプリケーション３７だけでなく、ライブラリなどのミドルウェア３８を含む。コンテナ３６は、コンテナエンジン３４によって割り当てられたハードウェア３１及びオペレーションシステム３２のリソースを用いて動作する。コンテナエンジン３４によるコンテナ３６へのリソースの割り当ては、コンテナ３６内のミドルウェア３８に含まれる設定ファイルなどに基づいて行われる。このように、リソース管理がコンテナエンジン３４によって保証されるため、コンテナ３６の動作の環境依存性を低下させることができる。なお、コンテナ３６は、機械学習、ブロックチェーン、メッセージサービス、認証サービスなどのアプリケーションのプログラムを含んでいる。

図４は、オーケストレーションツール３５が用いられる場合のコンテナ３６の動作環境となるＭＥＣ１６の概略構成図である。なお、この図に示されるコンテナの数などは一例である。

オーケストレーションツール３５は、コンテナエンジン３４が割り当てるハードウェアリソースを管理する。オーケストレーションツール３５により管理される論理的な空間は、クラスタと称される。本実施形態においては、オーケストレーションツール３５は、ＭＥＣ１６のハードウェアリソースを用いてクラスタを形成する。

オーケストレーションツール３５は、コンテナ３６の実行環境の管理を、ノード４１と称される単位で行う。同時に、オーケストレーションツール３５によって、ノード４１の全体の動作を管理するマスタ４２が設けられる。

ノード４１においては、この図の例においては、２つのポッド４１１がデプロイされている。ポッド４１１は、複数のコンテナ３６からなる所定のサービスを実現する機能ブロックであり、この図の例では、ポッド４１１は、２つのコンテナ３６を有する。ポッド４１１は、オーケストレーションツール３５によってコンテナ３６を管理する単位となる。ノード４１内におけるポッド４１１の全体の動作は、ポッド管理ライブラリ４１２により制御される。

ポッド管理ライブラリ４１２は、論理的に割り当てられたハードウェアリソースをポッド４１１（コンテナ３６）に使用させるためのコンテナランタイム４１２１、マスタ４２からの制御を受け付けるエージェント４１２２、及び、ポッド４１１間やノード４１とマスタ４２との間などの通信を行うネットワーク（ＮＷ）プロキシ４１２３などを有する。このような構成を備えるポッド管理ライブラリ４１２によって、ポッド４１１は、同一のノード４１内のポッド４１１や、他のノード４１のポッド４１１などと相互に通信しながら、ハードウェアリソースを用いて、所定の機能を実現する。

マスタ４２は、ポッド４１１のデプロイを行うアプリサーバ４２１、アプリサーバ４２１によるコンテナ３６のデプロイ状況を管理するマネージャ４２２、いずれのノード４１にコンテナ３６を配置するかを決定するスケジューラ４２３、及び、データの共有を行うデータ共有部４２４などを含む。なお、マスタ４２は、ポッド４１１がオーケストレーションされるエッジシステム１０の運用中においては、クラスタを構成する各ノード４１における処理負荷が一定となるようにポッド４１１の削除やデプロイを行うことができるので、高メンテナンス性を実現することができる。

図５は、複合機１２の設定に用いられるプロファイル構成を示す表である。なお、このプロファイル構成は一例であって、他の情報が含まれていてもよい。

この図では、複合機１２に関するプロファイル構成として、複合機１２を構成するＭＥＣ１６、作業機器１７、及び、センサ１８に関するハードウェア情報が示されている。

ＭＥＣ１６に関する情報には、ＣＰＵ（制御部２１）やメモリ（記憶部２２）などの一般的なハードウェア情報に加えて、インストールされているＯＳ、オーケストレーションソフト、コンテナエンジンなどの情報が含まれる。なお、ＯＳ、オーケストレーションソフト、コンテナエンジンは、初期段階においてＭＥＣ１６にインストールされていないことがある。

作業機器１７に関する情報には、機器種別や、どの作業工程で使用されるかが示されている。この例においては、ベルトコンベアによる工程１−２に用いられることが示されている。

センサ１８に関する情報には、センサの種類やその仕様（スペック）が示されている。この例においては、振動センサであり３次元での計測が可能であることが示されている。

なお、複合機１２が、作業機器１７やセンサ１８を有していない場合には、プロファイル構成においてはそれらの構成は記載されておらず、作業機器１７やセンサ１８などを備えていないことが示されている。

図６は、設定サーバによるＭＥＣ１６の初期設定等における設定制御を示すフローチャートである。この設定制御は、イメージレジストリ１５とＭＥＣ１６とが相互に連携して行われる。なお、ＭＥＣ１６は、設定制御の前においてはＯＳ等がインストールされていない状態であるが、ＰＸＥ（Preboot eXecution Environment）機能などを用いて自律的に動作する設定サーバを備えているものとする。設定サーバは、ＭＥＣ１６に対してネットワークインターフェースを経由してブートローダを起動させて、所定の設定制御を行わせることができる。このような構成において、ＭＥＣ１６は、設定サーバが主体となってイメージレジストリ１５からデータを取得して、ＭＥＣ１６内のローカル環境において動作環境を構築する。

ステップＳ６０１において、設定サーバは、記憶しているプロファイル構成に基づいて、ＭＥＣ１６における必要なイメージファイルを判断する。

ＭＥＣ１６がＯＳ、オーケストレーションソフト、コンテナエンジンなどが未搭載である場合には、設定サーバは、これらのプログラムが必要であると判断する。また、これらのプログラムが最新のバージョンでない場合には、設定サーバは、最新のプログラムへのアップデートプログラムが必要と判断する。同様に、設定サーバは、作業機器１７の種別や工程に応じた制御プログラムや、センサ１８の種類や仕様に応じた解析プログラムなどを実行するポッド４１１を、ＭＥＣ１６にデプロイする必要があると判断する。また、設定サーバは、ＭＥＣ１６のＣＰＵやメモリなどのハードウェア３１の構成に応じて、必要ファイルを適宜判断する。

ステップＳ６０２において、設定サーバは、イメージレジストリ１５とＭＥＣ１６との間に通信リンクを確立する。

ステップＳ６０３において、設定サーバは、ステップＳ６０１において判断された必要なイメージファイルのうち、ブートローダやＢＩＯＳなどの主にハードウェア３１の制御に用いるソフトウェアに関するイメージファイルを、イメージレジストリ１５に要求する。

ステップＳ６０４において、イメージレジストリ１５は、設定サーバからの要求に応じたイメージファイルを、ＭＥＣ１６に送信する。この処理により、イメージレジストリ１５においても、ＭＥＣ１６で用いられるプログラムが認識される。

ステップＳ６０５において、設定サーバは、ステップＳ６０１において判断された必要なＯＳのイメージファイルを選択すると、ステップＳ６０６において、そのイメージファイルをイメージレジストリ１５に要求する。

ステップＳ６０７において、イメージレジストリ１５は、設定サーバからの要求に応じたＯＳのイメージファイルを、ＭＥＣ１６に送信する。この処理により、イメージレジストリ１５においても、ＭＥＣ１６で用いられるプログラムが認識される。

ステップＳ６０８においては、ＭＥＣ１６は、ステップＳ６０４において送信されたハードウェア３１の制御に関するイメージファイルに加えて、ＯＳのインストールを行う。そして、ＭＥＣ１６は、そのローカル環境においてファームウェア及びＯＳのインストールが完了すると、ステップＳ６０９において、設定サーバにＯＳのインストールの完了の通知を送信する。

なお、ＭＥＣ１６のＯＳが最新である場合には、ステップＳ６０６〜Ｓ６０９の処理は省略され、ＭＥＣ１６のＯＳが最新ではない場合には、設定サーバは、ＯＳのバージョンアップに必要なイメージファイルを送信する。

ステップＳ６１０において、設定サーバは、ＭＥＣ１６に必要なオーケストレーションツール、及び、機械学習エンジン等を選択すると、ステップＳ６１１において、イメージレジストリ１５に対して、これらのイメージファイルを要求する。

そして、イメージレジストリ１５は、ステップＳ６１２において、ＭＥＣ１６にオーケストレーションツールを送信し、ステップＳ６１３において、ＭＥＣ１６に機械学習エンジン等に関するイメージファイルを送信する。

ステップＳ６１４において、ＭＥＣ１６は、そのローカル環境においてオーケストレーションツール、及び、機械学習エンジン等のインストールが完了すると、ステップＳ６１５において、設定サーバに、オーケストレーションツール、及び、機械学習エンジンのインストールの完了を通知する。

ステップＳ６１６において、設定サーバは、ＭＥＣ１６に必要なポッド４１１を選択すると、ステップＳ６１７において、イメージレジストリ１５に対して、これらのイメージファイルを要求する。

そして、ステップＳ６１８において、イメージレジストリ１５は、要求されたイメージファイルをＭＥＣ１６に送信すると、ステップＳ６１９において、ポッド４１１がデプロイされる。そして、ステップＳ６２０において、設定サーバは、ポッドのデプロイ状態をイメージレジストリ１５に送信する。このようにして、図４に示されるような、オーケストレーションツール３５が用いられる場合のコンテナ３６の動作環境が構築される。

なお、本実施形態においては、設定ファイルは、ＭＥＣ１６に記憶されたがこれに限らない。設定ファイルは、ネットワーク側においてイメージレジストリ１５に記憶されていてもよい。このような場合には、ＭＥＣ１６の設定サーバは、イメージレジストリ１５との通信の確立後に、イメージレジストリ１５の記憶する設定ファイルに基づいて、環境設定を行ってもよい。

このようにして、エッジシステム１０においては、ＭＥＣ１６に記憶されているプロファイル構成に基づいて、イメージレジストリ１５から必要なイメージファイルがＭＥＣ１６にインストールされることで、設定処理を行うことができる。

このような設定処理は、エッジシステム１０の初期状態における設定に限られず、設定変更時に行われてもよい。すなわち、ＭＥＣ１６に記憶されているプロファイル構成が修正されると、ＭＥＣ１６が備える設定サーバが主体となって、イメージレジストリ１５から必要なイメージを取得し、そのローカル環境にインストールを行う。設定変更において一部の機能を変更前のシステム構成から流用できる場合には、新たにイメージレジストリ１５からのイメージを再取得する必要がないので、処理負荷や通信負荷を軽減することができる。また、ＯＳやオーケストレーションツールの欠陥が見つかった場合に、ＯＳやオーケストレーションツールの再インストール処理を、この設定処理により行ってもよい。

また、上述の設定制御では、設定処理はＭＥＣ１６内に設けられる設定サーバは、ＯＳやミドルウェアがインストールされていない状態で自律的に動作するものとしたが、これに限らない。エッジシステム１０の設定変更時においては、設定サーバと同等の機能を、ポッド４１１により実現してもよい。設定サーバの機能を有するポッド４１１は、設定変更時においてはコンテナ３６に加え、コンテナエンジン３４やオーケストレーションツール３５を変更できる。さらに、設定サーバの機能を有するポッド４１１は、ＯＳやミドルウェア上におけるメモリ操作とは異なり、物理アドレスを直接的に指定することにより、オペレーションシステム３２やハードウェア３１に関するプログラムの更新を行うことができる。

図７には、本実施形態における設定処理により設定されるプログラムの一覧が示されている。この図に示されるように、設定サーバによって、大きく、アプリケーションと、ミドルウェア／プラットフォームとについて設定制御がなされる。

アプリケーションには、一般的なアプリケーションに加えて、機械学習（AI, ML(Machine Learning）、例えば、TensorFlow, Caffe2, PyTorch等）、ブロックチェーン（Blockchain、例えば、Ethereum, Hyperledger等）、メッセージサービス（Messaging、例えば、Kafka, Elastic Search, Logstash, Kibana等）、認証サービス（Authentication、例えば、OpenLDAP, OpenID等）が含まれる。

ミドルウェア／プラットフォームには、アプリケーションフレームワーク（App Framework、例えば、React JS, React Native, .Net Core, Spring等）、サービスのルーティングを行う機能ブロック（Service Broker, API Gateway、例えば、API Management Software等）、データベース（DB(Database)、例えば、MySQL, MongoDB, SQLite等）、システム環境の継続的な自動化と継続的な監視を行う機能ブロック（CI/CD、例えば、Concource CI等）、コンテナエンジン、コンテナオーケストレーションツール（Container, Container Orchestration、例えば、Docker, Kubernetes等）、スクリプト型プログラミング言語（Programming Language、例えば、Python, Node.js, Javascript（登録商標）, Go, C#, C++等）、インフラストラクチャ管理を行う機能ブロック（Infrastructure Management、例えば、OpenStack, Terraform, VMware, KVM, VirtutalBox等）、回路等用のファームウェア（Circuit, Onboarding、例えば、FPGA, GPU-CUDA等）、オペレーティングシステム（OS、例えば、Linux（登録商標）, Kernel等）が含まれる。

これらの図７に示されるソフトウェアは、初期設定や設定変更時等において、設定ファイルに示されるプロファイル構成に従って、設定サーバによってデプロイすることができる。

第１実施形態によれば以下の効果を得ることができる。

第１実施形態のエッジシステム１０によれば、ＭＥＣ１６が有する設定サーバは、設定情報に基づいてＭＥＣ１６の設定に必要なプログラムを判断し、必要と判断されたプログラムに応じたイメージをイメージレジストリ１５から取得する。そして、取得されたイメージを用いて、ＭＥＣ１６のプログラムが設定される。このような構成となることで、ＭＥＣ１６の設定は設定情報だけを用いればよいことになるので、複数のソフトウェアをインストールするための工数は不要になり、設定誤りなどの生じるおそれを低減することができる。

また、第１実施形態のエッジシステム１０によれば、ＭＥＣ１６と一体となってセンサ１８が設けられており、設定情報にはセンサ１８に関する情報が記憶されている。エッジシステム１０においては、種々のセンサ１８が用いられており、その制御プログラムは異なる。しかしながら、設定情報にセンサ１８の情報を記憶することにより、センサ１８が必要とする制御プログラムをＭＥＣ１６にインストールすることができるので、初期設定の工数を低減することができる。また、設定変更時においては、プロファイル構成の修正を行うことによりＭＥＣ１６のプログラムの更新を行うことができるので、設定の管理が容易になる。

なお、本実施形態においては、エッジシステム１０が、ＭＥＣ１６と、作業機器１７、及びセンサ１８を備える複合機１２から構成されものとして説明したが、本発明はこのような構成に限定されない。従って、ＭＥＣ１６のみを備えるエッジシステム１０として構成してもよいし、ＭＥＣ１６と他の任意の構成との組合せとして複合機１２を構成してもよい。また、同一の又は異なるそれらの複合機１２を複数備えるシステムとして構成してもよい。

（第２実施形態）
第１実施形態においては、１つの複合機１２によって構成されるエッジシステム１０について説明したが、これに限らない。本実施形態においては、親子関係を構成する複数の複合機１２によって構成されるエッジシステム１０について説明する。

図８は、本発明の実施形態に係るエッジシステムを備える監視システムの構成を示すブロック図である。

この図に示されるように、エッジシステム１０は、通信や制御などの複数の機能を実現する複合機１２により構成されている。エッジシステム１０においては、親機である第１世代の第１複合機１２Ａに対して、子機となる第２世代の第２複合機１２Ｂ、及び、第３複合機１２Ｃが接続され、さらに、第２複合機１２Ｂには孫機である第３世代の第４複合機１２Ｄが接続されている。

なお、本実施形態においては、親機、子機、及び、孫機の３世代の複合機１２によってエッジシステム１０が構成される例を説明するが、任意の世代数の複合機１２によってエッジシステム１０を構成してもよい。また、エッジシステム１０を構成する複合機１２の数も任意である。

図９は、複合機１２の詳細な構成を示す図である。この図によれば、ＭＥＣ１６内にイメージレジストリ８１が設けられている。そして、このイメージレジストリ８１は、クラウド上のイメージレジストリ１５と同等の機能を有し、必要なイメージファイルを記憶する。

以下においては、親機であるＭＥＣ１６Ａのイメージレジストリ８１Ａに記憶されているイメージを用いて、子機であるＭＥＣ１６Ｂの初期設定を行う例について説明する。

図１０は、設定サーバに記憶される複合機１２のプロファイル構成を示す表である。なお、このプロファイル構成は一例であって、他の情報が含まれていてもよい。以下においては、ＭＥＣ１６Ａのイメージレジストリ８１Ａが、ローカル環境の構成に必要な全てのイメージファイルを記憶している例について説明するが、ＭＥＣ１６Ａ〜１６Ｄが、それぞれにおいてプロファイル構成を記憶していてもよい。

この図では、複合機１２Ａ〜１２Ｄに関するプロファイル構成として、複合機１２を構成するＭＥＣ１６、作業機器１７、及び、センサ１８に関するハードウェア情報が示されている。複合機１２Ａ〜１２Ｄに関するそれぞれの情報は、第１実施形態の図５に示されたプロファイル構成と同等のものである。

図１１は、親機であるＭＥＣ１６Ａによる子機であるＭＥＣ１６Ｂの設定について説明する。なお、この処理の前段において、ＭＥＣ１６Ａのイメージレジストリ８１Ａには、ローカル環境の構成に必要な全てのイメージファイルを記憶しているものとする。すなわち、第１実施形態の設定制御におけるイメージレジストリ１５とＭＥＣ１６との間と同等の処理が、第２実施形態の設定制御においては、ＭＥＣ１６Ａのイメージレジストリ８１Ａと、ＭＥＣ１６Ｂとの間において行われる。

この設定制御においては、ステップＳ１１０１〜Ｓ１１２０の処理は、第１実施形態における図６に示される設定制御のステップＳ６０１〜Ｓ６２０に相当する。なお、ＭＥＣ１６Ａ〜ＭＥＣ１６Ｄのプロファイル構成は、ＭＥＣ１６Ａにおいて一元管理されているので、ＭＥＣ１６Ｂは、ステップＳ１１０１においてＭＥＣ１６Ａから自身に関するプロファイル構成を取得する。

このように構成することで、それぞれのＭＥＣ１６Ｂにおいて、プロファイル構成に基づいて、必要なイメージファイルをＭＥＣ１６Ａ内のイメージレジストリ８１Ａから取得し、そのイメージファイルを用いた設定を行うことができる。

ＭＥＣ１６Ｂは、自身の有するイメージレジストリ８１Ｂに設定に必要なイメージファイルを記憶しているので、例えば、一部の機能が故障して再インストールや再デプロイが必要な場合には、他のＭＥＣ１６Ａのイメージレジストリ８１Ａや、ネットワーク上のイメージレジストリ１５と通信する必要がない。そのため、再インストールや再デプロイに要する時間の短縮化を図ることができる。

また、図１１に示されたステップＳ１１０１〜Ｓ１１２０の処理はこの例の順に行われる必要はなく、これらの処理の順序を変更してもよい。一例としては、ＭＥＣ１６Ｂは、まず、必要なイメージの判断（Ｓ１１０１）、ＯＳの選択（Ｓ１１０５）、オーケストレーションツール、機械学習エンジンの選択（Ｓ１１１０）、ポッド４１１の選択（Ｓ１１１６）を行う。そして、ＭＥＣ１６Ｂは、通信の確立（Ｓ１１０２）をした後に、イメージの要求（Ｓ１１０３）、ＯＳイメージの要求（Ｓ１１０６）、オーケストレーションツール、機械学習エンジンの要求（Ｓ１１１１）、ポッド４１１の要求（Ｓ１１１７）を行う。ＭＥＣ１６Ａは、これらの要求に応じて、必要なイメージの送信（Ｓ１１０４）、ＯＳイメージの送信（Ｓ１１０７）、オーケストレーションツールの送信（Ｓ１１１２）、機械学習エンジンの送信（Ｓ１１１３）、ポッド４１１の送信（Ｓ１１１８）を行う。そして、ＭＥＣ１６Ｂは、これらのイメージを取得すると、ＯＳのインストール（Ｓ１１０８）、オーケストレーションツール、機械学習エンジンのインストール（Ｓ１１１４）、ポッド４１１のデプロイ（Ｓ１１１９）を行い、それらの完了通知（Ｓ１１０９、Ｓ１１０５）を行う。最終的に、ＭＥＣ１６Ｂの設定サーバは、ポッド４１１の配置状態をＭＥＣ１６Ａに送信する（Ｓ１１２０）。

このように構成することで、選択処理（Ｓ１１０１、Ｓ１１０５、Ｓ１１１０、Ｓ１１１６）、要求処理（Ｓ１１０３、Ｓ１１０６、Ｓ１１１１、Ｓ１１１７）、送信処理（Ｓ１１０４、Ｓ１１０７、Ｓ１１１２、Ｓ１１１３、Ｓ１１１８）、及び、インストール処理（Ｓ１１０８、Ｓ１１１４、Ｓ１１１９）を、それぞれにおいて集中的にまとめて行うことで、設定制御の短時間化を図ることができる。

第２実施形態によれば、以下の効果を得ることができる。

第２実施形態のエッジシステム１０は、複数の親子関係のＭＥＣ１６を有しており、それぞれのＭＥＣ１６はイメージレジストリ８１を有している。このような構成となることにより、子機であるＭＥＣ１６Ｂは、初期設定において必要なファイルを親機であるＭＥＣ１６Ａから取得する。したがって、例えば、子機であるＭＥＣ１６Ｂにおいて一部の機能が故障して再インストールや再デプロイが必要な場合には、親機であるＭＥＣ１６Ａのイメージレジストリ８１Ａや、ネットワーク上のイメージレジストリ１５と通信する必要がないので、再インストールや再デプロイに要する時間の短縮化を図ることができる。

以上、本発明の実施形態について説明したが、上記実施形態は本発明の適用例の一部を示したに過ぎず、本発明の技術的範囲を上記実施形態の具体的構成に限定する趣旨ではない。

１０ エッジシステム
１１ ローカル環境
１２ 複合機
１５、８１ イメージレジストリ
１６ ＭＥＣ（エッジ端末）
１７ 作業機器
１８ センサ
１００ 監視システム

Claims (9)

1. オーケストレーション技術により論理的に割り当てたハードウェアリソースを用いてコンテナを動作させることにより所定の機能を実現するエッジ端末により構成されるエッジシステムであって、
   前記エッジ端末は、
   所定の設定情報に基づいて、対応するイメージを、イメージレジストリから取得し、
   取得した前記イメージを用いて、前記エッジ端末へとデプロイを行い設定処理を行い、
   前記エッジ端末は、さらに、所定機能を備えた機器を備え、
   前記設定情報は、前記機器に関する情報を含む、エッジシステム。
2. 請求項１に記載のエッジシステムであって、
   前記機器は、センサであり、
   前記エッジ端末は、前記センサに応じたイメージを用いて、デプロイを行う、エッジシステム。
3. 請求項１又は２のいずれか１項に記載のエッジシステムであって、
   前記イメージレジストリは、前記エッジシステムとネットワークを介して接続される、エッジシステム。
4. 請求項１乃至３のいずれか１項に記載のエッジシステムであって、
   前記エッジシステムは、複数の前記エッジ端末により構成され、
   前記イメージレジストリは、前記エッジ端末が有する、エッジシステム。
5. 請求項４に記載のエッジシステムであって、
   一の前記エッジ端末は、
   前記設定情報に基づいて、対応するイメージを、他の前記エッジ端末が有する前記イメージレジストリから取得する、エッジシステム。
6. 請求項５に記載のエッジシステムであって、
   前記一のエッジ端末と前記他のエッジ端末とは親子関係にある、エッジシステム。
7. オーケストレーション技術により論理的に割り当てたハードウェアリソースを用いてコンテナを動作させることにより所定の機能を実現するエッジ端末により構成されるエッジシステムの制御方法であって、
   前記エッジ端末は、
   所定の設定情報に基づいて対応するイメージを、イメージレジストリから取得するステップと、
   取得した前記イメージを用いて、前記エッジ端末へとデプロイを行い設定処理を行うステップと、を有し、
   前記エッジ端末は、さらに、所定機能を備えた機器を備え、
   前記設定情報は、前記機器に関する情報を含む、エッジシステムの制御方法。
8. オーケストレーション技術により論理的に割り当てたハードウェアリソースを用いてコンテナを動作させることにより所定の機能を実現するエッジ端末により構成されるエッジシステムの制御方法の制御に用いられるコンピュータプログラムであって、
   前記コンピュータプログラムは、前記エッジ端末に対して、
   所定の設定情報に基づいて対応するイメージを、イメージレジストリから取得させるステップと、
   取得した前記イメージを用いて、前記エッジ端末へとデプロイを行わせ設定処理を行わせるステップと、を有し、
   前記エッジ端末は、さらに、所定機能を備えた機器を備え、
   前記設定情報は、前記機器に関する情報を含む、エッジシステムの制御に用いられるコンピュータプログラム。
9. オーケストレーション技術により論理的に割り当てたハードウェアリソースを用いてコンテナを動作させることにより所定の機能を実現するエッジ端末により構成されるエッジシステムの制御方法の制御に用いられるコンピュータプログラムを格納した記録媒体であって、
   前記コンピュータプログラムは、前記エッジ端末に対して、
   所定の設定情報に基づいて対応するイメージを、イメージレジストリから取得させるステップと、
   取得した前記イメージを用いて、前記エッジ端末へとデプロイを行わせ設定処理を行わせるステップと、を有し、
   前記エッジ端末は、さらに、所定機能を備えた機器を備え、
   前記設定情報は、前記機器に関する情報を含む、コンピュータプログラムを格納した記録媒体。

Images