JP2019075077A - ワークフローエンジンフレームワーク - Google Patents

Abstract

【課題】動的エンジンコンポーネントの有機的な構成を通じて目的に合う、クロスドメイン適応型のワークフロー実行プラットフォームを提供する。【解決手段】フレームワーク１０は、ユーザーによって定義されたワークフローの実行に必要なワークフロー属性明細コンポーネントとエンジンコンポーネントが含まれた資源を管理する資源管理部、属性明細コンポーネントを組み立て、ワークフローの実行に必要なエンジンコンポーネントを動的に組み合わせてワークフロー明細にしたがって必要なエンジンコンポーネントコンテナを構成してエンジンを生成するシステム構成部、ワークフロー属性明細に定義された方式により前記システム構成部によって生成される一つ以上のエンジンを駆動して実行を制御するシステム制御部を備える。【選択図】図１

Description

本発明はワークフローおよびフレームワーク技術に関するものであって、具体的には、多様な業務ドメインまたは目的ドメインのワークフローを処理するために、動的エンジンコンポーネントの有機的な構成を通じて単一ドメイン適応型の、ひいてはクロスドメイン適応型のワークフロー実行プラットフォームを作ることができる、ワークフローエンジンフレームワークに関するものである。

ワークフロー技術とは、文書、情報、タスクなどを一連の業務手続き規則による処理のために、あるユーザー（アプリケーション）から他のユーザーに伝達するビジネスプロセスの自動化技術を意味する。特にデータ基盤サービスワークフロー生成手続きは次のとおりである。まず、データソースとそのデータソース収集方法を決定する。収集されたデータの処理方法を決定して分析方法を決定する（例えば、機械学習、予測、知識推論などによる分析）。分析された結果をサービスするための方法を決定する。この該当ワークフローを実行するために必要なエンジンを構成し、エンジン間の連係方法を定義することによってワークフロー生成手続きが完了する。

最近、多様な事物に人工知能を付与するいわゆる知能型事物インターネットが注目されている。特に、多数の異種事物インターネット領域を包括する知能型インターネットの応用（例えば、スマートシティ）のためには、異種の事物知能領域を統制および管理、制御できるシステムが必要である。また、多様な業務ドメイン（例えば、エネルギー、ヘルス、交通・教育・電力プラン卜など）を知能的に処理しなければならない問題が発生する可能性がある。一つの業務ドメイン内においても、データの発生とアクションが起きるデバイスから、データを処理し伝達、即刻的な分析、判断するエッジ（ｅｄｇｅ）と複雑な分析と応用が起きるクラウド（ｃｌｏｕｄ）まで、多様な目的ドメインが存在し得る。また、業務ドメインや目的ドメイン内でも、空間の分類による空間ドメイン、時間の分類による時間ドメインが存在し得る。その他にデータ処理ドメイン、学習ドメイン、予測ドメイン、サービスドメインなど、多様な方法ドメインが存在し得る。したがって、このような複雑な多種の多階層ドメイン（以下、クロスドメイン）を効果的に統制し管理、制御するための一元化された方法およびシステムが必要である。

一方、事物インターネットを通じて収集されるビッグデータに含まれたインサイトを素早く抽出してビジネスとつなぎ合わせるために、事物インターネットデータからインサイトを抽出し分析して、迅速かつ正確な意志決定を支援するための多様な技術が開発されている。このためには、リアルタイムアナリティクスのためのストリーム処理技術とリアルタイム予測／分析のためのプラットフォーム技術の裏付けが必ず必要である。

また、最近急浮上している機械学習技術をＩｏＴビッグデータ分析に活用してワークフローを設計する必要性が大きくなりつつあり、また多様な目的と分野のＩｏＴドメインが生成するにつれて、これらを有機的に統合してよりインサイトのある分析やサービスを可能にする、一元化されたプラットフォーム技術が必要となっている。しかし、従来のワークフロー技術では、デバイス、データ、ドメインにより異なる特性を有するＩｏＴビッグデータと機械学習を結合するには限界がある。

前述した限界と問題点の克服のために、エンジンコンポーネントの有機的な構成を通じて各ドメインの目的に合うワークフローを生成して実行することができ、容易に他のドメインに適用して他のドメインに適合した（ドメイン適応型の）ワークフローを生成し実行することができ、特にクロスドメインに対応するために統合的に制御および管理できる一元化されたシステムが必要である。

したがって、本発明は動的エンジンコンポーネントの有機的な構成を通じて目的に合う、ドメイン適応型の、ひいてはクロスドメイン適応型のワークフロー実行プラットフォームを作るためのワークフローエンジンフレームワークを提案しようとする。

前記課題を解決するための本発明の一側面によると、ユーザーによって定義されたワークフローの実行に必要なワークフロー属性明細コンポーネントとエンジンコンポーネントが含まれた資源を管理する資源管理部；属性明細コンポーネントを組み立て、ワークフローの実行に必要なエンジンコンポーネントを動的に組み合わせてワークフロー明細にしたがって必要なエンジンコンポーネントコンテナを構成してエンジンを生成するシステム構成部；ワークフロー属性明細に定義された方式により前記システム構成部によって生成される一つ以上のエンジンを駆動して実行を制御するシステム制御部を含む、ワークフローエンジンフレームワークが提供される。

また、本発明の他の側面によると、前記ワークフローエンジンフレームワークが二以上の異なる単一ドメインにそれぞれ割り当てられ、これら単一ドメインワークフローエンジンフレームワークとネットワークに連結されて、ユーザーが定義したクロスドメインワークフローによりクロスドメインに含まれた各単一ドメインに必要なエンジンを配布する単一ドメインを決定するクロスドメイン融合システムが含まれる、クロスドメイン適応型ワークフローエンジンフレームワークが提供される。

エンジンコンポーネントの有機的な構成を通じて、各ドメインが解決しようとする分野と目的に合うワークフローを生成して実行することができ、容易に他のドメインに適用して他のドメインに適合したワークフローを生成して実行することができる。すなわち、多様な業務ドメインまたは目的ドメインで類似する問題の解決のための実行プラットフォームを容易に構成することができるように、エンジンコンポーネントを動的にリサイクルできるドメイン適応型ワークフローエンジンフレームワークを容易に構成することができる。また、クロスドメイン知識融合ブレインをさらに含むことによって、クロスドメイン適応型ワークフローエンジンフレームワークを構成することができる。ひいては、ＩｏＴ、ビッグデータ、機械学習を結合して分析する大容量データのリアルタイム分析サービスにおいて、特定の問題の解決のために開発した機械学習モデルおよびビッグデータ分析モデルをコンポーネントを具現して管理することができる。

多様な人工知能サービスやアプリケーションが要求される環境で応用別に個別のソリューションを開発せず、追加に必要なコンポーネントを開発して追加に搭載するか既開発されて搭載されたコンポーネントをリサイクルすることによって、新しいワークフローを満足するワークフロー実行エンジンセットを構成／実行できるフレームワークを具現することができる。

本発明に係るワークフローエンジンフレームワークの概要図。 システム構成部３０の細部構成図。。 システム定義編集機７０の構成を説明するためのＧＵＩ画面の例示図。 ワークフローを構成するエンジンに対する明細からエンジンを構成する手続きを示した図面。 図１のワークフロー構成部３６により構成可能なワークフロー実行インスタンスの例示としてのエンジンの構成図。 単位処理器を搭載したエンジン構成の一例を示した図面。 図６に例示したデータ処理エンジンの具体的な実施形態図。 単位処理器を搭載したエンジン構成の他の例を示した図面。 一つ以上のエンジンがパイプライン方式で連結されるワークフローの実行システムの構成を示した図面。 一つ以上のエンジンが多数類型のデータ経路を通るワークフローの実行システムの構成を示した図面。 ＩｏＴおよび人工知能基盤の照度／温度制御ワークフローサービスシナリオの説明図。 ディープランニング基盤の交通速度モニタリングサービスシナリオの説明図。 図１１のワークフローエンジンフレームワーク１０の内部構成。 クライアントやユーザーに対するサービスを提供するエンジンであって、知能サービスを提供するためのサービングエンジンの構成の例示を示した図面。 図１２のワークフローエンジンフレームワーク１０の内部構成。 クロスドメインワークフローエンジンフレームワーク構成の例を示した図面。 クロスドメインワークフローの実行手続きを示した図面。 スマートシティを達成するためのシナリオを説明するための図面。 図１８のスマートシティを達成するために構成したワークフローエンジンフレームワークの一実施形態。 図１９に示したワークフロー９４のスマート街路灯制御推薦エンジン構成の一実施形態。

図１は、本発明のワークフローエンジンフレームワークの一実施形態を示す構成図である。本発明のワークフローエンジンフレームワーク１０は基本として、−実行する作業（ワークフロー）の構造と明細を作成するシステム定義編集機７０、−ユーザーがシステム定義編集機７０を通じて作成するワークフロー明細（＝エンジン明細。すなわち、ワークフローを構成する一つ以上のエンジンで構成された明細）の各エンジンコンポーネントを定義するための属性に関連した属性明細コンポーネントとワークフローの実行を遂行するエンジンを構成するエンジン構成品と言えるエンジンコンポーネント、そして、既に作成されたワークフロー明細インスタンスなどの資源を管理する資源管理部２０、−ワークフロー属性明細を組み立て、ワークフローの実行に必要なエンジンコンポーネントを動的に組み合わせて構成し、ワークフローを遂行するエンジンインスタンス３２（以下、「エンジン」と混用される）を構成するシステム構成部３０、−前記システム構成部３０により生成されたエンジン（インスタンス）３２、−資源管理部２０、システム構成部３０、エンジン３２の実行を制御するシステム制御部４０を含む。

ワークフローエンジンフレームワーク１０において、ユーザーは所望するシステムを作るために一つ以上のエンジンで構成されるワークフローを定義する。ここで、ワークフローは一つ以上のエンジンに対する定義で構成されるが、この「エンジンに対する定義」は、エンジンコンポーネントを入れるためのエンジンコンポーネントコンテナとエンジンコンポーネントコンテナに入るエンジンコンポーネントの組み合わせを意味する。エンジンコンポーネントコンテナは一つ以上の入力器（ｒｅａｄｅｒ）コンポーネント、出力器（ｗｒｉｔｅｒ）コンポーネント、実行器（ｒｕｎｎｅｒ）コンポーネント、処理器（ｏｐｅｒａｔｏｒ）コンポーネント、制御器（ｃｏｎｔｒｏｌｌｅｒ）コンポーネントの組み合わせで作ることができる。これら一つ以上の入力器コンポーネント、出力器コンポーネント、実行器コンポーネント、処理器コンポーネント、制御器コンポーネントは、それぞれコンポーネントの性質を決定する属性を定義するための属性明細コンポーネントと、コンポーネントの実際の具現体に該当する実行コンポーネントの組み合わせで作られる。一例として、実行コンポーネントは、Ｊａｖａ、Ｃ＋＋などのクラスに該当するものであり、属性明細コンポーネントはクラスの生成子に含まれ得る生成子パラメーターまたは生成子パラメーターが入れられるクラスに該当する。このような方式で生成された実行システムの定義に該当する一つ以上のエンジンに対するワークフローを定義することによって動的に実行エンジンを構成して、多様な目的の業務ドメインに必要なワークフローシステムを作ることができる。

図２は、図１のシステムの具体的な構成および追加可能な構成要素を示している。

前記システム構成部３０により動的に生成されたエンジンコンポーネントの組み合わせで構成されたエンジン３２がエンジンインスタンス（結果として完成されて実行されたエンジン）の形態で保存される実行インスタンス部５０；資源管理部２０で管理される属性明細コンポーネント６２とエンジンコンポーネント６４が物理的にまたは仮想的に保存される空間であるコンポーネント部６０；そして、システム定義編集機７０からワークフロー明細の入力を受けてシステム構成部３０に伝達する役割をするフロントエンド７７がさらに含まれ得る。

フロントエンド７７はクライアントから要請を受けて処理をするためのプロセスの実行を媒介する役割を遂行し、ユーザー管理や保存所管理などの多様な要請に対応する役割を遂行する。フロントエンド７７の例えば一般的なアプリケーションサーバー、ウェブ基盤のＲＥＳＴ ＡＰＩを提供するウェブアプリケーションサーバー、または一般的なソケット通信基盤の受信者（ｌｉｓｔｅｎｅｒ）モジュールを含んだシステムであり得る。場合によっては、フロントエンド７７はシステム定義編集機７０またはフレームワーク１０を構成しているバックエンドと異なるネットワーク上で実行されることも可能である。

図１、図２のワークフローエンジンフレームワーク１０の本格的な説明に先立って、フレームワーク１０で実行システムを駆動するための一連の作業明細を定義するワークフローを作成し、これをフレームワーク１０で駆動するように指示するためにフロントエンド７７に要請する役割を遂行するシステム定義編集機７０について先に説明する。

システム定義編集機７０は所望の業務に対する細部ドメインを定義し、各ドメインに対して処理すべき作業の構造（ワークフロー構造）を定義し、この構造に合うようにエンジンコンポーネントを選定してワークフローの実行流れを定義し、各エンジンコンポーネントの具体的な明細を作成する機能を遂行する。このために、フレームワーク（特に、資源管理部２０）から属性明細コンポーネントとエンジンコンポーネントを照会することができる。

ここで「作業の構造」は、例えば、特定の事物インターネットプラットフォームからのデータ収集、データ処理、学習などの過程であり、これらを順次処理することはワークフローの実行流れに該当し得る。「コンポーネントの明細」とは、データをいずれから持ってきてどのような処理過程を経、いずれに送り出すかに対する作業を遂行するために、いずれのデバイスから収集するのか、連結方法は何であるか、データを受けてメモリーに置くのか保存所に入れるのか、メモリー情報は何であるか、保存所の位置はどこであるのかなど、各要素コンポーネントに対する具体的な定義事項を意味する。

ユーザー（データ科学者、モデル開発者、ビジネス開発者など）は、システム定義編集機７０を通じて、ワークフローを構成するエンジンコンポーネント６４とそのエンジンコンポーネントの特性を決定するパラメーターを定義できる属性明細コンポーネント６２を規約に沿って定義し、またコンポーネントと属性明細のペアを定義し、編集することができる。

図３は、システム定義編集機７０の構成を説明するためのＧＵＩ画面７１の例示図である。このＧＵＩ画面７１を説明することによって、システム定義編集機７０の構成および作用に対する説明を代替する。

ＧＵＩ画面７１には、機能メニュー７２、エンジン類型選択部７３、コンポーネント選択部７４、コンポーネント属性照会／編集部７５、ワークフローインスタンス保存／照会部７６が含まれる。

機能メニュー７２は、システム定義編集機７０の各種機能を選択するメニューであって、例えばＮｅｗ（ワークフロー新規作成）、Ｏｐｅｎ（保存されたワークフローの読み込み）、Ｓａｖｅ（ワークフロー保存）、Ｒｕｎ（ワークフローの実行）、Ｒｅｓｕｌｔ（実行結果を見る）、Ｈｅｌｐ（ヘルプ）等の機能を選択するメニューで構成され得る。

エンジン類型選択部７３は、各種のエンジンの類型を提示し、ユーザーがこれらのうち必要なものを選択することができるようにする。エンジンの類型としては、例えば、リアルタイムストリーム処理エンジン、配置分析エンジン、要求型（ｏｎ−ｄｅｍａｎｄ）データ処理エンジン、評価エンジン、配置データ積載エンジン、ストリーム機械学習予測エンジン、要求型（ｏｎ−ｄｅｍａｎｄ）融合サービングエンジンなどがある。

コンポーネント選択部７４は、ユーザーがコンポーネントタイプと各タイプ別エンジンコンポーネントを選択することができるように、コンポーネントタイプ別に多様なエンジンコンポーネント目録を提供する。下記の表１はコンポーネント選択部７４で提示されるコンポーネントタイプとエンジンコンポーネント目録の例示である。

コンポーネント属性選択／編集部７５は、コンポーネント選択部７４で選択されたエンジンコンポーネントの属性（Ｐｒｏｐｅｒｔｉｅｓ）が提示され、ユーザーは属性を照会してこれを選択および編集することができる。

ワークフローインスタンス選択部７６は、既製作されたワークフローが保存された目録が表示される。これらのうちリサイクルを所望するワークフローを選択して再編集をするか、そのままフレームワーク１０に実行要請をすることができる。リサイクルの単位はワークフロー全体であってもよく、またはワークフローに含まれた単一エンジン別に再活用して編集や実行に活用してもよい。

このようなシステム定義編集機７０でワークフロー明細ファイルが作成されると、これは図１に示したフレームワーク１０のシステム構成部３０に提出される。このとき、フロントエンド７７がワークフロー明細の入力を受けてシステム構成部３０に伝達する役割をすることができる。

再び図１と図２に参照すると、フレームワーク１０の資源管理部２０はワークフローの実行に必要なコンポーネントを管理する機能を遂行する。資源管理部２０は、具体的には図２に示したように、−ワークフローインスタンスのコンポーネント特性または属性を決定する属性明細が含まれた属性明細コンポーネント６２とその目録を管理（アップデートを含む）する属性明細コンポーネント管理部２２、−実行のためのコンポーネント（エンジンコンポーネント）とその目録を管理（アップデートを含む）するエンジンコンポーネント管理部２４を含む。

また、既に作成されて保存されたワークフロー明細インスタンスを管理するワークフロー明細インスタンス管理部２６をさらに含むことができる。このワークフロー明細インスタンス管理部２６は、システム定義編集機７０の要請により（例えば、図３のワークフローインスタンス選択部７６を通じて）、ワークフロー明細インスタンスを後で活用できるように保管および管理する。

また、図１でシステム構成部３０は、作成されたワークフローの実行に必要なコンポーネントを生成する機能を遂行する。システム構成部３０はフロントエンド７７から渡されたワークフロースペック（明細）により必要なエンジンコンポーネントコンテナ３２を構成してエンジンインスタンスを生成する。

図２を参照して詳察すると、システム構成部３０は、−システム定義編集機７０から受信した実行プラットフォーム構成ワークフロー明細を属性明細コンポーネントにバインディングして一連の属性明細コンポーネントを生成するワークフロー属性明細組立部３４、−組み立てた属性明細コンポーネント６２から、定義されたエンジンコンポーネント情報を抽出して属性明細コンポーネント６２とエンジンコンポーネント６４をバインディングする過程を通じて、一連のエンジンコンポーネントを構成してワークフロー実行プラットフォームを構成するワークフロー構成部３６を含む。

ワークフロー属性明細組立部３４は、実行プラットフォームを構成するためのワークフロー明細を属性明細コンポーネント６２にバインディングして一連の属性明細コンポーネントインスタンスを生成する。ワークフロー属性明細組立部３４により生成される属性明細コンポーネント６２の例えば、ＧｏｏｇｌｅのＰｒｏｔｏｂｕｆメッセージ客体、ＳｃａｌａのＣａｓｅ Ｃｌａｓｓ、ＪａｖａのＰｒｏｐｅｒｔｙ客体などが挙げられる。

ワークフロー構成部３６は、ワークフローを構成するエンジンコンポーネント６４とこのエンジンコンポーネント６４の特性を決定するパラメーターを定義した属性明細コンポーネント６２をバインディングし、バインディング過程を通じて生成したエンジンコンポーネントのインスタンスをエンジンコンテナにバインディングすることによって、ワークフローを実行するための一連のエンジンインスタンスが含まれるワークフロー実行インスタンス部５０を動的に構成する。ワークフロー実行インスタンス部５０には、ワークフロー構成部３６により動的に生成された一つ以上のエンジン３２が作られて実行される。一つのワークフローを実行するために生成されたこれらのエンジン３２は、一つの独立したプログラムパッケージとして同じコンピューティングマシンまたはネットワークに連結されたコンピューティングマシン上に配布されて実行されるか、仮想マシン単位でパッケージングされて異なる物理的コンピューティングマシンに配布され得る。

図１と図２のシステム制御部４０は、前記システム構成部３０が生成したエンジンインスタンス３２を処理手続きに合うように駆動し、また駆動されたエンジンインスタンス３２を終了させる役割を遂行するなど、本発明のフレームワークの核心役割を遂行するモジュールである。また、ワークフロー属性明細に定義された方式によりワークフロー実行インスタンス部５０内に作られる一つ以上のエンジン３２を駆動して実行を制御する。換言すると、システム制御部４０がワークフロー実行インスタンス部５０にワークフローの実行要請をすると、ワークフローが実行される。これによって、所望するいかなるドメインに対してもユーザーによって作成されたワークフローが達成しようとする目的を達成することができる。

例えばシステム制御部４０は、多数の異なる類型をデータ出発地（ｓｏｕｒｃｅ）と終着地（ｄｅｓｔｉｎａｔｉｏｎ）とする一つ以上のエンジン３２が、互いにパイプライン方式で実行されるように制御することができる。または多数の異なる類型をデータ出発地と終着地とする一つ以上のエンジンが、同時に実行されるように制御することができる。多様な類型のエンジン構成については詳細に後述する。

図４は、システム定義編集機７０で作成されたワークフロー明細からエンジン３２を構成する手続きを図示する。

まず、システム構成部３０のワークフロー構成部３６は、ワークフロー明細の入力を受けて（３４０）、これから、エンジンを構成するエンジンコンポーネントに対する属性明細が入れられる一連の属性明細コンポーネントインスタンスを生成する（３４２）。この時、使用される属性明細コンポーネント６２は、ＧｏｏｇｌｅのＰｒｏｔｏｂｕｆメッセージやＳｃａｌａのＣａｓｅ Ｃｌａｓｓ、その他、プログラム言語上で値を入れることができる「Ｃｌａｓｓ」であり得る。

生成した属性明細コンポーネントインスタンスをエンジンコンポーネント６４の生成子パラメーターと指定してエンジンコンポーネントインスタンスを生成する（３４４）。

エンジンを構成する制御器、入力器、実行器、出力器、単位処理器を含むエンジンインスタンスが生成されると、これらをエンジンコンポーネントコンテナインスタンス生成子パラメータとして、エンジンコンポーネントコンテナ３１に動的バインディングしてエンジンインスタンスを生成する過程（３４６）を通じてエンジンインスタンスを生成する。ワークフロー上のすべてのエンジンの定義に対してエンジンインスタンス３２が生成され、生成されたエンジンインスタンスはワークフロー実行インスタンス部５０で実行及び管理される。

このような図４の手続きでもって、ワークフロー実行インスタンスを動的に構成する。ここで一つのエンジンは仮想マシンの形態で定義され構成され得る。

図５〜図１０は図１で言及したワークフロー構成部３６により構成されるワークフロー実行インスタンスの例示として、多様なエンジン３２構成の方式を図示する。

図５に示した基本的なエンジン３２は、一つ以上のデータ出発地（ｓｏｕｒｃｅ）からデータを持ってくる入力器（ｒｅａｄｅｒ）３２２、内部で処理したデータを一つ以上のデータ終着地に出力する一つ以上の出力器（ｗｒｉｔｅｒ）３２４、入力したデータを処理するための別途の実行プログラムまたはプラットフォームを実行したりセッションを管理する実行器（ｒｕｎｎｅｒ）３２６、このようなデータを入力器を通じて入力して実行器上で処理し、これを出力するための一連の制御を担当する制御器（ｃｏｎｔｒｏｌｌｅｒ）３２８で構成される。

前記コントローラ（制御器）３２８は、前記入力器３２２、出力器３２４、実行器３２６、および下記の単位処理器３２３を利用した一連の処理過程を制御する機能を遂行する。入力器３２２にデータソース（出発地）からデータを読み込むとの入力要請をし、実行器３２６に入力器を通じて読み込んだデータを処理フレームワークを駆動して処理して出力器に送るとの処理要請をし、出力器３２４に処理完了したデータをデータ終着地に書き込ませるとの出力要請をする。

エンジン３２の入力器３２２は、インメモリーバッファーやキャッシュ、ファイルシステム、メッセージングシステム、データベース、ネットワークドライバーのうちいずれか一つのタイプのデータ保存所（図示しない）からデータを読み込む機能を遂行する。同様に、出力器３２４はインメモリーバッファーやキャッシュ、ファイルシステム、メッセージングシステム、データベース、ネットワークドライバーのうちいずれか一つのタイプのデータ保存所（図示しない）にデータを書き込む機能を遂行する。単位処理器３２３は、データを受けて加工して送りだす機能を遂行する。例えば、データマイニングで言及している精製／統合／縮小／変換方法に含まれた多様なデータ処理機能の具現体であり得る。実行器３２６はデータを処理するために必要なすべてのプログラムや外部プラットフォーム／フレームワークであり得、ビッグデータ処理のためのＳｐａｒｋ、ディープランニング分析のためのＣａｆｆｅ、Ｔｅｎｓｏｒｆｌｗのようなディープランニングプラットフォーム、Ｊｅｎａのような知識処理エンジンのうち一つと連動したり、これを実行するためのコネクターや制御器、セッション管理器などであり得る。

一方、制御器３２８は、図５、６のように、入力器３２２、一つ以上の単位処理器３２３ａ〜ｃ、出力器３２４の順でノードが構成される場合に、データを順次パイプライニングして次のノードに伝達する方式で実行するように制御する順次処理方式、それぞれのノードが同時に実行されるようにする同時処理方式、この二つを結合した同時／順次処理方式などを利用して制御することができる。

図６は、図５の基本的なエンジン３２を構成する方式のうち、入力されたデータを制御器３２８により処理する一連の過程を、一つ以上の連続した単位処理器（ｕｎｉｔ ｏｐｅｒａｔｏｒ）３２３ａ−ｃを利用して順次パイプライン方式でデータ処理をして、出力器３２４まで伝達するように構成されたエンジンを図示する。制御器３２８は、入力器３２２にデータ出発地からデータを読み込むとの入力要請をし、実行器３２６にデータ処理のためのフレームワークを駆動して入力器を通じて読み込んだデータを処理するように処理器実行要請をし、各単位処理器３２３ａ−ｃにパイプライン処理実行要請をし、出力器３２４に処理完了したデータをデータ終着地に書き込ませるとの出力要請をする。図６の構成方法によると、多様な単位処理器を組み合わせて活用して多様なドメインの目的に合う処理を容易に遂行できる。単位処理器３２３ａ−ｃは、一般的なデータマイニングの技法に該当する、精製、縮小、統合、変換のための方法の具現体であり得る。

図７は、図６に例示したデータ処理エンジンの具体的な実施形態を示す。データを処理するためのＳｐａｒｋフレームワークを実行し、ファイルやＪＤＢＣ、Ｋａｆｋａなどからデータを読み込む入力器（Ｒｅａｄｅｒ）を通じてデータを読み込んで特定のコラムを削除（ｒｅｍｏｖｅ）する単位処理器（ｏｐｅｒａｔｏｒ）と、併合（ｃｏｎｃａｔｅｎａｔｉｏｎ）および欠測値インピュテーション（ｉｍｐｕｔａｔｉｏｎ）単位処理器、正規化（ｓｃａｌｉｎｇ）単位処理器、精製（ｆｉｌｔｅｒ）単位処理器、ピボット（ｐｉｖｏｔ）単位処理器を通じてファイル、ＪＤＢＣ、Ｋａｆｋａなどに出力する出力器（ｗｒｉｔｅｒ）を含むデータ処理エンジンを構成することができる。

図８は、図６の制御器３２８が単位処理器３２３ａ〜ｃを駆動する他の方式のエンジンであって、入力器３２２からデータを受けて一連の単位処理器が順次パイプライニングによるデータを処理する方式と共に、一つ以上の単位処理器が駆動されて同時処理を実行するように制御する方式のエンジン構成を図示する。

以上で説明した多様な構成のエンジン３２の他の実施形態として、実行器３２６を、ＣａｆｆｅまたはＴｅｎｓｏｒｆｌｏｗのようなディープランニングフレームワーク、ＳｐａｒｋまたはＨａｄｏｏｐ ＭａｐＲｅｄｕｃｅのようなビッグデータ処理フレームワーク、ＲまたはＰｙｔｈｏｎのような分析フレームワークなどの多様な処理フレームワークやソフトウェアプログラムと連動するようにまたはこれらを含むように構成することができる。

さらに他の実施形態として、前記説明したエンジン３２を、同一システム内の多様なデータ経路をデータ出発地および終着地として使用する入力器と出力器を搭載するように構成することができる。すなわち、インメモリーバッファー／キャッシュ、ファイルシステム、メッセージングシステム、データベース、ネットワークなどの多様な論理的ドライバー概念のソース（同一システムに含まれる）をデータ出発地および終着地と定義し、これらからデータの入力を受け、これらにデータを出力するように入力器と出力器を構成してエンジンを構成することができる。

さらに他の実施形態として、前記説明したエンジン３２を、異なるシステムまたはネットワークに存在するデータ経路をそれぞれデータ出発地と終着地として使用するエンジンを構成することができる。このために、入力器と出力器に対する設定に、ネットワークアドレス情報やホスト情報、遠隔ドライバー情報を含ませることができる。異なるデータ出発地と終着地を入力器と出力器に別個で使うことによって、エンジンをデータ出発地と終着地間でのストリーム処理エンジンやデータ経路上のフィルターのように活用できるのである。

図９は、多数のワークフロー実行エンジン３２ａ〜ｃが構成される場合に、一つのエンジンの出力器から出力されるデータの終着地が他のエンジンの入力器のデータ出発地にパイプライン方式で伝達されるようにデータ伝達経路３３８が使用される実施形態を図示する。ここでデータ伝達経路３３８は例えばＫａｆｋａであり得る。図９のような構成を利用することによって、複数の異なる用途のワークフロー処理をするエンジン３２ａ〜ｃが協力して複雑なワークフローを実行することが可能である。

また、図９において、一つ以上のエンジン３２ａ〜ｃは互いに異なる物理的環境（例えば、ネットワーク、クラスターなど）に置かれ得、異なる種類の実行器で構成することが可能である。例えば、最初のエンジン３２ａはデータを処理する実行器を連動し、二番目のエンジン３２ｂはディープランニングフレームワークを連動するという場合、前記データ伝達経路３３８により異なる環境で複雑な問題を解決するための一つのワークフローを実行することが可能である。この時、それぞれのエンジンは、同時実行、一つずつ順次的実行、または特定の時点による個別的実行のいずれも可能である。

図１０は、一つ以上のエンジン３２ａ〜ｃが異なる類型のデータ伝達経路（例えば、ファイルシステム伝達経路３４０とネットワークストリーム伝達経路３４２）をデータ出発地および終着地別にパイプライニング処理する方式でワークフローの実行システムを構成した例を図示する。この場合、各エンジン内の入力器と出力器は複数で構成される。ここでファイルシステム伝達経路３４０は、バッチ伝達経路を意味し、ネットワークストリーム伝達経路３４２はリアルタイム伝達経路を意味する。図１０の方式によって、リアルタイム処理とバッチ処理が同時に可能なラムダアーキテクチャーのような構造のワークフローシステムを構成することができる。

以上で説明した本発明のフレームワークの構成および作用に対する理解を助けるために、具体的なワークフローサービスシナリオを紹介する。

図１１は、ＩｏＴおよび人工知能基盤の照度／温度制御ワークフローサービスシナリオの説明図である。ワークフローエンジンフレームワーク１０は、建物内の温度センサ８１からの温度センシング値を受信して、フレームワーク１０内に生成されたエンジンを通じて所定のワークフローを実行してスマート電球８２を制御して最適照度の調節を遂行し、スマートシステム冷暖房機８３を制御して最適温度の調節を遂行する。

「８０」は、温度センサ８１から流入するデータを入力として、予測モデルによって未来、例えば今後１時間後の温度の変化を予測し、予測温度に適合した照度の設定とエアコン温度の制御設定値を推論して、これをスマート電球８２の照度調節とスマートシステム冷暖房機８３の温度設定値として伝送する照度および温度制御人工知能サービスを示している。

図１２は、ディープランニング基盤の交通速度モニタリングサービスシナリオの説明図である。本発明のワークフローエンジンフレームワーク１０は、特定の地域の交通現場に構築されている交通速度センサ（シミュレーター）８４から速度情報の伝送を受けて、フレームワーク１０内に生成されたエンジンを通じて所定のワークフローを実行して実行データを該当地域に構築されている交通速度予測知能サービス８５に提供して、運行中の車両のダッシュボード８７またはスマートフォンの画面８８を通じてモニタリングするようにすることができる。車両８７またはスマートフォン８８を通じてモニタリングされる内容は、「８６」のように例えば特定の地域の地図に表示される交通速度情報である。

図１３は図１１のワークフローエンジンフレームワーク１０の内部構成を説明する。ワークフローエンジンフレームワーク１０で生成されたエンジンにインヂェスチャン（Ｉｎｇｅｓｔｉｏｎ）／データ／予測エンジン５２とサービングエンジン５３が含まれている。

インヂェスチャン／データ／予測エンジン５２の構成要素は次のとおりである。
５２２：ウェブサービスポートを開いて入ってくるデータを読み込むストリーム入力器
３３８：ストリームデータを読み込んで一定の個数になると入力器５２２、オペレーター５２３ａ〜ｆ、出力器５２４を順次処理するようにするコントローラ（制御器）
５２３ａ：データのうち温度値が位置したコラムを抽出するオペレーター（処理器）
５２３ｂ：特定値の範囲に値を正規化するオペレーター
５２３ｃ：コラムを列に、または列をコラムに変換するオペレーター
５２３ｄ：伝達された値を指定された機械学習モデルを利用して予測／判断するオペレーター
５２３ｅ：逆正規化のために特定値の範囲に値を還元するオペレーター
５２３ｆ：予測結果で生成された複数の値のうちラベル値が含まれた特定のコラムを抽出するオペレーター
５２４：最終値をストリームエンジン（例えば、Ｋａｆｋａ）で書き込む出力器
５２６：オペレーターが実行され得るようにする環境を提供する実行器
サービングエンジン５３の構成要素は次のとおりである。
５ 3 2 ：ストリームエンジンから必要な時ごとに値を読み込む入力器
５３８：Ｒｅｓｔ Ｒｕｎｎｅｒ５３６で実行中のウェブサーバー上の特定のウェブポートを通じて要請がきた時に入力器３４２を通じてインヂェスチャン（Ｉｎｇｅｓｔｉｏｎ）／データ／予測エンジン５２の処理結果値を読み込んでデータベースを参照して最適値を検索して応答するように、一連の流れを制御するコントローラ

温度センサ８１の温度センシング値がＲＥＳＴ信号でインヂェスチャン／データ／予測エンジン５２に入力され、システム定義編集機７０を通じて設計された多数の処理器を経て処理され、出力された予測結果値は保存所から読み込まれてサービングエンジン５３に伝達されて温度センサ８１の温度センシング値に応じてスマート電球８２が制御されて自動照度調節をするようになる。

図１４は、クライアントやユーザーに対するサービスを提供するエンジンであって、知能サービスを提供するためのサービングエンジンの構成例示を示している。入力器３２２、多数のパイプライン処理器３２３ａ〜ｃ、出力器３２４、実行器３２６、制御器３２８の構成要素は、図８で説明された内容と類似している。ただし、図１４のサービングエンジンは、図１１および図１３のワークフローサービスにおけるサービスの実行をサービスする機能のために構成される。図１４に各コンポーネントと連動する外部システム、Ｓｐａｒｋ、Ｔｅｎｓｏｆｌｏｗ、Ｊｅｎａ（ｔｉｍｅ）、ＲＥＳＴ Ｓｅｒｖｅｒ、Ｊｅｎａ（ｓｐａｃｅ）、Ｊｅｎａ（ｄｏｍａｉｎ−ｓｐｅｃｉｆｉｃ）が表示されている。

サービングエンジンの制御器は、Ｓｐａｒｋのような実行器で構成されたエンジンから処理したデータを読み込むかテンソルフローのようなディープランニングフレームワークを実行器で構成したエンジンから処理したデータを読み込む入力器と、その値を利用してオントロジー基盤推論を遂行する処理器と、その結果をＲＥＳＴインターフェースを通じてサービスする実行器でエンジンを構成することによって、知能的サービスを提供することができる。

図１５は図１２のワークフローエンジンフレームワーク１０の内部構成を説明する。ワークフローエンジンフレームワーク１０で生成されたエンジンに、１３８２個のＬｉｎｋの交通センサ８４から５分単位で時間／速度／ＴＲＶがリアルタイムで伝送されると、これを読み込んでＴｅｎｓｏｒｆｌｏｗ ＲＮＮ動作のためのＬｉｎｋ別２４時間シリーズ（ｔｉｍｅ ｓｅｒｉｅｓ）データを前処理し伝送するデータエンジン５４と、Ｔｅｎｓｏｒｆｌｏｗ ＲＮＮ動作のためのＬｉｎｋ別２４ ｔｉｍｅ ｓｅｒｉｅｓを受信して１５分後の予測値を出力する予測エンジン５５が含まれている。

データエンジン５４には、図５〜８と類似するように、入力器５４２、制御器５４８、実行器５４６、処理器５４３ａ〜ｆが含まれる。予測エンジン５５の場合にも図５〜８と類似するように入力器５５２と制御器５５８が含まれるが、実行器の代わりに、ＲＮＮ（循環神経網）基盤の予測を遂行するテンソルフロー（Ｔｅｎｓｏｒｆｌｏｗ）５５５が含まれる。

図１６は、以上で説明した多数の単一ドメイン適応型ワークフローエンジンフレームワーク１０をネットワークを通じて協力的に連結して、クロスドメイン適応型のワークフローエンジンフレームワークシステムを動的構成するための方法を図示する。図１のワークフロー構成の対象がクロスドメインに該当する場合に、一つ以上の単一ドメイン適応型ワークフローエンジンフレームワーク１０を総括的に管理して制御するためのクロスドメイン融合システム１０’をさらに含み、クロスドメイン適応型ワークフローエンジンフレームワークを具現することができる。

クロスドメイン融合システム１０’は基本として、図１または図２の単一ドメインワークフローエンジンフレームワーク１０と類似する構成および機能を有し、多様なドメインを統合して階層化する役割をすることによって、クロスドメインワークフローの実行に関連する資源を管理し、各ドメインにクロスドメインワークフローの一部をワークフローとして割り当て、これを各ドメインのフレームワーク上で実行させるシステムである。したがって、クロスドメイン融合システム１０’は、クロスドメイン資源管理部２０’、クロスドメインシステム構成部３０’、クロスドメインシステム制御部４０’を含む。

前述した概念のシステム定義編集機７０’を利用してユーザーがワークフローを定義して、データ収集はいずれのセンサーから取得するのか、モデルはいずれを選択するのか、エンジンを生成して適切なところに配布することなどの要請が入れられたワークフロー明細を作成すると、クロスドメイン融合システム１０’はシステム定義編集機７０’で定義されたワークフローにより、該当するドメインに必要なエンジンを配布するドメインを決定する。この時、エンジン配布決定の基準は例えば、特定エンジンの使用がいずれのドメインに最適であるか、このエンジンの実行のための構成品が該当ドメインに存在するのか、ネットワークの負荷、性能、ネットワーク内の距離などを考慮する。

クロスドメイン資源管理部２０’は、多数の単一ドメインワークフローエンジンフレームワーク１０（図１または図２参照）の資源管理部２０から周期的にワークフロー資源の報告を受け、これらを更新して管理することを遂行する。例えば、ワークフロー資源は、ワークフローの実行のためのコンポーネント資源、ネットワーク連結情報、ハードウェア資源情報、仮想マシンの仕様情報、組織の構成情報、組織の使用可能デバイス情報、使用可能状態のうち一つ以上であり得る。また、クロスドメイン資源管理部２０’は、各ドメインから受けた資源情報を通じて使用できるコンポーネントとハードウェア、ネットワーク情報、ドメイン内のデバイス情報などを周期的に更新して維持する。資源管理部２０’が管理する資源は例えば、各ドメイン別エンジンコンポーネント目録、費用算定のための資料、ドメイン間の信頼度などである。

クロスドメインシステム構成部３０’は、システム定義編集機７０’から受けたクロスドメインワークフローインスタンス明細を処理するために、クロスドメイン資源管理部２０’から使用可能な資源がある位置と連結方法などを参照して、一つのクロスドメインワークフローインスタンス明細を多数の単一ドメインワークフロー明細に分割し、各単一ドメインワークフローエンジンフレームワーク１０に配布する。各ドメインのワークフローエンジンフレームワーク１０は各自のドメインに割り当てられたエンジンを動的に構成する。

クロスドメインシステム制御部４０’は、一つ以上の単一ドメインワークフローエンジンフレームワーク１０によって生成されたそれぞれのワークフロー実行システム、すなわち、ドメインに配布された一つ以上のエンジンの実行の開始、終了などの制御のために、それぞれ単一ドメインワークフローエンジンフレームワーク１０上のシステム制御部４０に実行の制御を要請することによって、クロスドメイン上にワークフロー実行システムを駆動し終了することを遂行する。

各ドメインのワークフローエンジンフレームワーク１０は、各自のドメインに割り当てられたエンジンを動的に構成した後、クロスドメインシステム制御部４０の実行要請によってエンジンを駆動して処理を遂行する。このとき、エンジン間のデータの伝達は、図１０で言及した通り、ネットワークドライバーを通じて直接遂行されてもよく、分散メッセージキューのようなメッセージングシステム、その他の分散ファイルシステムなどの多様なデータ経路のうち一つ以上を利用して伝達してもよい。各単一ドメインワークフローエンジンフレームワーク１０のシステム制御部４０は、エンジンの進行状況や完了などの信号を再びクロスドメイン融合システム１０’のクロスドメインシステム制御部４０’に伝達する。

クロスドメイン資源管理部２０’は各ドメインから受けた資源情報、すなわち、使用できるコンポーネントとハードウェア、ネットワーク情報、ドメイン内のデバイス情報などを各単一ドメインワークフローフレームワーク１０に要請して最新の資源情報を維持する。また、クロスドメインシステム構成部３０’はクロスドメインワークフローを遂行するにおいて、一つ以上のドメインワークフローエンジンフレームワーク１０に最適なエンジンワークフローを配置するために、クロスドメインワークフローを一つ以上のドメインワークフローに分割する。このために、クロスドメインシステム構成部３０’は、クロスドメイン資源管理部２０’に各単一ドメインワークフローエンジンフレームワーク１０に対する最新の資源情報を要請して、図１７の段階２６０による最適なエンジンの配布政策にしたがって各単一ドメインワークフローエンジンフレームワーク１０上で構成されるべきエンジンを決定する過程を通じて、前記一つ以上のドメインワークフローに分割する作業を完成する。次いで、クロスドメインシステム構成部３０’は、分割された各ドメインワークフローを各単一ドメインワークフローエンジンフレームワーク１０に送り、一つ以上のドメイン上にクロスドメインワークフローを遂行（ｐｅｒｆｏｒｍ）するためのエンジンを実行（ｅｘｅｃｕｔｅ）できるシステムを動的に構成する。

各単一ドメインワークフローエンジンフレームワーク１０は、自分が有する資源の目録をクロスドメイン融合システム１０’に登録し、周期的に更新を要請する。ここで資源の目録はワークフローの実行のためのコンポーネント資源目録であり得、ネットワーク連結情報、ハードウェア資源情報、仮想マシンの仕様情報、組織の構成情報、組織の使用可能デバイス情報、使用可能状態などがさらに該当し得る。

図１７は、図１６のクロスドメイン融合システム１０’でワークフロー明細を受けてこれを効果的に配布して実行するための実行手続きを図示する。この時のワークフローは、解決しようとする問題や応用により単一ドメインまたはクロスドメイン適応型ワークフローであり得る。

まず、システム定義編集機７０’でワークフロー生成手続きによって一連のワークフローを決定し、これを構成するエンジンを作るためのエンジンコンポーネントコンテナ群が含まれたワークフロー明細を定義する（１００）。クロスドメイン融合システム１０’がシステム定義編集機７０’からワークフロー明細を受けると、ワークフロー明細に設定されたエンジンコンポーネントコンテナをいずれのドメインに配布するのか配布位置を決定し、配布する過程（２００）に進行する。ワークフロー上で必要とするエンジンに対する明細がドメインに配布されると、単一ドメインに対するまたはクロスドメインに対するワークフローを実行するためのすべての準備が完了し、最後に該当ワークフローを実行する（３００）。

クロスドメイン融合システム１０’でクロスドメインシステム構成部３０’が各エンジンコンポーネントコンテナの配布位置を決定し、配布する過程（２００）を具体的に説明すると次のとおりである。

まず、各エンジンに必要なデータの最初出発地（エンジンが収集しなければならないデータの位置。例えば、特定のＤＢ、センサ位置など）と最終到着地（例えば、他のエンジンに対するデータ出発地、または保存所位置）が同一ドメインに存在するのか把握する（２１０）。この時、データの出発地と到着地は事物インターネット機器やデータベースのような構造化されたデータ保存所、ファイルシステムなどであり得、ウェブサービス終端になってもよい。

データの出発地と到着地が同一ドメインに存在すると、該当ドメイン内の資源を利用して最初のデータの出発地から最終到着地までの一連のエンジン構成が可能であるかを資源管理部を照会して判断する（２２０）。もし、エンジン構成が可能であれば（例えば、該当ドメインの資源レジストリにエンジン構成が可能なエンジンコンポーネントがすべて存在する場合）、該当ドメインにエンジンを動的に構成するようにエンジン明細を配布して（２３０）ワークフローが実行され得るようにする。

再び（２１０）段階に戻って、前記エンジンのデータ出発地と到着地が同一ドメインに属さない場合に、または段階（２２０）で該当ドメイン内の資源を利用してエンジンコンポーネントコンテナの構成が可能であるか判断した結果、構成不可と判断されると、同一のコンポーネント構成が可能な他のドメインを検索して（資源管理部を検索）、代替可能な候補ドメイン群を決定する段階（２４０）に進行する。

候補ドメイン群が決定されると、それらのうち代替ドメインを決定するために費用算定を遂行する（２５０）。この時、費用はネットワークトポロジー上の距離、ネットワーク処理量、予想遅延時間などのようなネットワーク伝達費用の算定額、使用できるコンピューティング資源の量、ドメイン間の信頼度のうち一つ以上を組み合わせて計算することができる。

次に、計算した費用をもって配布ドメインの選定政策を適用して配布しなければならない最適なドメインを選定する（２６０）。この時、ドメイン選定政策は、各ドメインの資源に対して同一比率または同一量で配分されるようにする公正配分政策、エネルギー効率性を考慮した最適エネルギー政策、ドメイン別に優先順位をつけて配分する優先順位政策などであり得る。費用、政策の段階の順序は非順序的である。

ワークフロー上で必要とするすべてのエンジンに対する明細が該当ドメインに配布されると（２３０）、該当ドメインまたはクロスドメインに対するワークフローを実行するためのすべての準備が完了したのであり、最終的にワークフローを実行する（３００）。クロスドメイン融合システム１０’にあるシステム制御部４０’の実行指示がコントロールチャネルを通じて各単一ドメインフレームワーク１０のシステム制御部４０構成部３０に伝達されて実行される。

図１６と図１７のクロスドメイン適応型ワークフローエンジンフレームワークに対する理解のために、具体的な関連シナリオとシステム構成を説明するための図面（図１８〜２０）を通じてより詳しく説明する。

図１８は、スマートシティを達成するためのシナリオを説明するためのものである。まず、スマートシティは、最適な（スマート）公共エネルギーの需給制御と公共交通制御、そして、その他の分野の最適制御を通じて達成することができる。そのうち、最適な公共エネルギーの需給制御は、公共エネルギー需給政策により最適な公共エネルギー需要制御と供給制御を通じて達成することができる。ここでスマート公共エネルギー需要制御は、最適な街路灯制御と霧制御（例えば、霧除去装置の制御）、その他の最適な公共装置制御を通じて達成することができる。このうち、最適な街路灯制御は、予測された道路別交通量、予測された気象状態による最適な道路交通制御政策を参照して達成することができる。道路別交通量予測は、道路別交通量をモニタリング結果を参照して予測に活用して達成することが可能である。

図１９は、図１８のスマートシティを達成するために構成したクロスドメインワークフローエンジンフレームワークの一実施形態を図示する。

まず、道路交通量モニタリングは、多様な交通センサーからセンシングデータを収集するエンジンと、この収集エンジンが収集したセンシング情報を読み込んで、総計、平均のような交通量統計のためのオペレーション処理をする交通量統計処理エンジンと、外部の要請に対して交通量統計処理結果を応答する交通量統計サービングエンジンで構成された道路交通量モニタリングワークフロー９１を通じて、エンジンフレームワークで実行することによって目的とするシステムを構成することができる。

次いで、道路別交通量予測は、前記道路交通量モニタリングワークフロー９１の交通センサ情報収集エンジンと収集されたセンシング情報を予測に必要な入力データの形態で処理し、処理したデータを読み込んで機械学習基盤の予測を実行する交通量予測エンジンと、予測結果を外部の要請により応答する交通量予測サービングエンジンで構成された道路別交通量予測ワークフロー９２を定義し実行することによって、目的とするシステムを動的に構成することができる。

気象予測は、気象情報を収集して適切に処理する気象情報収集エンジンと、機械学習モデル基盤で気象を予測する気象予測エンジンと、気象予測結果をサービスするための気象予測サービングエンジンで構成された気象予測ワークフロー９３を定義し実行することによって、目的とするシステムを構成することができる。

道路交通制御政策は、特定の状況に該当するコンテクストを入力として、規則に基づいた推論または推薦（ｒｅｃｏｍｍｅｎｄａｔｉｏｎ）オペレーションを通じて知識ベースや機械学習などを利用して最適な道路交通制御政策を抽出状況別道路交通制御推薦エンジンを含む道路交通制御ワークフロー９０を定義し実行することによって、目的を達成するためのシステムを構成することができる。

スマート街路灯制御は、前述した交通量予測サービングエンジンと気象予測サービングエンジンに、それぞれ道路格別交通量予測結果と気象予測結果を質疑するためのオペレーションとその結果を前記状況別道路交通制御推薦エンジンに提供して、必要な道路交通制御を推論して得るためのオペレーションを含んで外部の要請に応答するスマート街路灯制御推薦エンジンを生成するスマート街路灯制御ワークフロー９４を定義し実行することによって、目的を達成するためのシステムを構成することができる。

その他に説明していない図１８に図示されたシナリオは、前記と類似する方法でそれぞれのワークフローを構成することによって、それぞれの目的を達成するシステムを動的に構成することができる。

図２０は、図１９に示したシナリオのうち、スマート街路灯制御のためのワークフロー９４構成でスマート街路灯制御推薦エンジン構成の一実施形態を例示する。スマート街路灯制御推薦エンジンは、外部の要請に応答するためのＲＥＳＴｆｕｌ Ｓｅｒｖｅｒ３２５を駆動するためのＲｕｎｎｅｒコンポーネント３２６と、ＲＥＳＴｆｕｌサーバー３２５で要請が入ってきた時に気象予測結果を照会するオペレーターを通じて気象予測エンジン９３’に質疑して予測する結果を持ってくるオペレーター３２３ａと、交通量予測エンジン９２’に質疑することによって今後道路別交通量予測結果を質疑して持ってくるオペレーター３２３ｃ、各オペレーターが取得した結果を受けて状況情報を生成し、生成した状況情報を利用して状況別道路交通制御推薦エンジン９０’に質疑することによって状況に合う道路別交通制御を得、そのうち街路灯制御政策を抽出してＲＥＳＴ Ｓｅｒｖｅｒ３２５に伝達するオペレーター３２３ｂとこれらＲｕｎｎｅｒ３２６とＯｐｅｒａｔｏｒとの間の論理の流れ関係を制御するＣｏｎｔｒｏｌｌｅｒ３２８で構成することができる。

再び図１７のクロスドメインワークフローの実行手続きに戻って、一連のワークフローの実行のための必要エンジンコンポーネントコンテナ群の決定（１００）を遂行した後、各エンジンコンポーネントコンテナに対する配布位置決定および配布のための手続き（２００）のうち、代替候補ドメイン決定のための基準となる費用算定（２５０）および最適な候補ドメイン決定（２６０）について各シナリオ別に補充説明する。

道路交通制御ワークフロー９０での状況別道路交通制御推薦エンジンの場合に、その推薦結果が街路灯制御推薦と直結されるため、ドメイン間の信頼度優先の加重値政策によるエンジン配布が遂行される。

道路交通量モニタリングワークフロー９１でのセンシングデータ収集エンジン、交通量統計処理エンジン、交通量統計サービングエンジンについては、リアルタイムモニタリングのためにエンジン配布時にネットワーク伝達費用と使用可能コンピューティング資源優先の加重値政策によりエンジンを配布する。

道路別交通量予測ワークフロー９２の道路交通量モニタリングワークフローの交通量予測エンジンと交通量予測サービングエンジンは、収集エンジンの収集結果を利用して予測を遂行しなければならないため、収集エンジンが配布されたドメインとのネットワーク費用を優先としてエンジンを配布する。

気象予測ワークフロー９３において、気象情報はセキュリティー上重要な情報ではないため、使用できるコンピューティング資源を優先してエンジンを配布する。

スマート街路灯制御推薦エンジンが含まれたスマート街路灯制御ワークフロー９４では、それぞれの質疑対象エンジンが他のドメインに配布されており、重要な情報を含んでいるため、ドメイン間の信頼度優先の加重値政策によりエンジンを配布する。

以上の構成およびプロセスを通じて、事物インターネット、ビッグデータ、機械学習を結合して分析する大容量データのリアルタイム分析サービスなどにおいて、特定の問題の解決のために開発した機械学習モデルおよびビッグデータ分析モデルをコンポーネントを具現して管理することができる。また、多様な業務や目的ドメインで類似する問題の解決のための実行プラットフォームを容易に構成することができるように、前記コンポーネントを動的にリサイクルできる単一ドメインまたはクロスドメイン適応型ワークフローエンジンフレームワークを具現することができる。

Claims (20)

1. ワークフローの実行に必要なワークフロー属性明細コンポーネントとエンジンコンポーネントが含まれた資源を管理する資源管理部、
   属性明細コンポーネントを組み立て、ワークフローの実行に必要なエンジンコンポーネントを組み合わせてワークフロー明細にしたがって必要なエンジンコンポーネントコンテナを構成してエンジンを生成するシステム構成部、
   ワークフロー属性明細に定義された方式により前記システム構成部によって生成される一つ以上のエンジンを駆動して実行を制御するシステム制御部を含む、ワークフローエンジンフレームワーク。
2. 前記システム構成部によって生成されたエンジンコンポーネントの組み合わせで構成されたエンジンが保存される実行インスタンス部をさらに含む、請求項１に記載のワークフローエンジンフレームワーク。
3. 前記資源管理部は
   ワークフローインスタンスのコンポーネント属性を決定する属性明細が含まれた属性明細コンポーネントを管理する属性明細コンポーネント管理部、
   実行のためのエンジンコンポーネントを管理するエンジンコンポーネント管理部を含む、請求項１に記載のワークフローエンジンフレームワーク。
4. 前記資源管理部は
   既に作成されて保存されたワークフロー明細インスタンスを管理するワークフロー明細インスタンス管理部をさらに含む、請求項３に記載のワークフローエンジンフレームワーク。
5. 前記システム構成部は
   ワークフロー明細を属性明細コンポーネントにバインディングして属性明細コンポーネントを生成するワークフロー属性明細組立部、
   組み立てた属性明細コンポーネントから、定義されたエンジンコンポーネント情報を抽出して属性明細コンポーネントとエンジンコンポーネントをバインディングする過程を通じてエンジンを構成してワークフロー実行プラットフォームを構成するワークフロー構成部を含む、請求項１に記載のワークフローエンジンフレームワーク。
6. 前記ワークフロー構成部は
   ワークフローを構成するエンジンコンポーネントとこのエンジンコンポーネントの特性を決定するパラメーターを定義する属性明細コンポーネントの規約に沿ってエンジンコンポーネントと属性明細コンポーネントをバインディングして、ワークフローを実行するためのエンジンが保存されるワークフロー実行インスタンス部をさらに含む、請求項５に記載のワークフローエンジンフレームワーク。
7. 前記ワークフロー明細はシステム定義編集機によって定義されて前記システム構成部に提出されるものの、このシステム定義編集機は
   各種エンジンの類型を提示してユーザーがこれらのうち必要なものを選択することができるようにするエンジン類型選択部、
   ユーザーがコンポーネントタイプと各タイプ別エンジンコンポーネントを選択することができるように、コンポーネントタイプ別に多様なエンジンコンポーネント目録を提供するコンポーネント選択部、
   コンポーネント選択部で選択されたエンジンコンポーネントの属性が提示され、ユーザーは属性を照会してこれを選択および編集することができるようにするコンポーネント属性選択／編集部を含む、請求項１に記載のワークフローエンジンフレームワーク。
8. 前記エンジンは、
   一つ以上のデータ出発地からデータを持ってくる入力器、
   前記入力器からデータを受けて処理する一つ以上の単位処理器、
   内部で処理したデータを一つ以上のデータ終着地に出力する一つ以上の出力器、
   入力したデータを処理するための別途の実行プログラムまたはプラットフォームを実行したりセッションを管理する実行器、
   このようなデータを入力器を通じて入力して実行器上で処理し、これを出力するための一連の制御を担当する制御器を含む、請求項１に記載のワークフローエンジンフレームワーク。
9. 前記制御器は、
   前記入力器、単位処理器、出力器の順でノードが構成される場合に、データを順次パイプライニングして次のノードに伝達する方式で実行するように制御する順次処理方式、それぞれのノードが同時に実行されるようにする同時処理方式、この二つを結合した同時／順次処理方式のうちいずれか一つで制御を実行する、請求項８に記載のワークフローエンジンフレームワーク。
10. 前記制御器は
    一つ以上の単位処理器が前記入力器からデータを受けて順次パイプライニングによるデータを処理すると共に、一つ以上の単位処理器が駆動されて同時処理を実行するように制御する、請求項８に記載のワークフローエンジンフレームワーク。
11. 前記ワークフローエンジンフレームワークに一つ以上の前記ワークフロー実行エンジンが含まれ、
    この場合、多数のエンジン間パイプライン方式で伝達されるようにデータ伝達経路が使用される、請求項８に記載のワークフローエンジンフレームワーク。
12. 前記一つ以上のエンジンは互いに異なる物理的環境に位置し、異なる種類の実行器を含む、請求項１１に記載のワークフローエンジンフレームワーク。
13. 前記データ伝達経路は一つ以上の異なる類型のデータ伝達経路を含む、請求項１１に記載のワークフローエンジンフレームワーク。
14. ワークフローの実行に必要なワークフロー属性明細コンポーネントとエンジンコンポーネントが含まれた資源を管理する資源管理部；属性明細コンポーネントを組み立て、ワークフローの実行に必要なエンジンコンポーネントを組み合わせてワークフロー明細にしたがって必要なエンジンコンポーネントコンテナを構成してエンジンを生成するシステム構成部；ワークフロー属性明細に定義された方式により前記システム構成部によって生成される一つ以上のエンジンを駆動して実行を制御するシステム制御部を含む単一ドメインワークフローエンジンフレームワーク、
    前記単一ドメインワークフローエンジンフレームワークと連結されて、定義したクロスドメインワークフローによりクロスドメインに含まれた各単一ドメインに必要なエンジンを配布する単一ドメインを決定するクロスドメイン融合システム（１０’）を含む、クロスドメイン適応型ワークフローエンジンフレームワーク。
15. 前記クロスドメイン融合システムは
    単一ドメインワークフローエンジンフレームワークの資源管理部からワークフロー資源の報告を受け、これらを更新し、各ドメインから受けた資源情報を通じて使用できるコンポーネントとハードウェア、ネットワーク情報、ドメイン内のデバイス情報を更新するクロスドメイン資源管理部、
    クロスドメインワークフロー明細を処理するために、一つのクロスドメインワークフロー明細を多数の単一ドメインワークフロー明細に分割して各エンジンコンポーネントコンテナの配布位置を決定して配布するクロスドメインシステム構成部を含む、請求項１４に記載のクロスドメイン適応型ワークフローエンジンフレームワーク。
16. 前記クロスドメイン融合システムは、クロスドメインに含まれた各単一ドメインに必要なエンジンを配布する単一ドメインを決定するために
    １）各エンジンに必要なデータの出発地と到着地が同一ドメインに存在するのか把握する手段、
    ２）エンジンのデータ出発地と到着地が同一ドメインに存在すると該当ドメイン内の資源を利用してエンジン構成が可能であるかを判断する手段、
    ３）エンジン構成が可能であれば、該当ドメインにエンジンを構成するようにエンジン明細を配布する手段、
    ４）手段１）の判断結果、エンジンのデータ出発地と到着地が同一ドメインに存在しない場合に、または手段２）でエンジン構成が不可であると判断されると、同一エンジンコンポーネントの構成が可能な他のドメインを検索して代替可能な候補ドメイン群を決定する手段、
    ５）候補ドメイン群が決定されると、それらのうち代替ドメインを決定するために費用算定を遂行し、配布ドメイン選定政策を適用して配布しなければならない最適なドメインを選定する手段を含む、請求項１４に記載のクロスドメイン適応型ワークフローエンジンフレームワーク。
17. 前記ワークフロー明細は、システム定義編集機によって定義されて前記クロスドメイン融合システムに提出されるものの、このシステム定義編集機は
    各種エンジンの類型を提示してユーザーがこれらのうち必要なものを選択することができるようにするエンジン類型選択部、
    ユーザーがコンポーネントタイプと各タイプ別エンジンコンポーネントを選択することができるように、コンポーネントタイプ別に多様なエンジンコンポーネント目録を提供するコンポーネント選択部、
    コンポーネント選択部で選択されたエンジンコンポーネントの属性が提示され、ユーザーは属性を照会してこれを選択および編集することができるようにするコンポーネント属性選択／編集部を含む、請求項１４に記載のクロスドメイン適応型ワークフローエンジンフレームワーク。
18. 前記エンジンは、
    一つ以上のデータ出発地からデータを持ってくる入力器、
    前記入力器からデータを受けて処理する一つ以上の単位処理器、
    内部で処理したデータを一つ以上のデータ終着地に出力する一つ以上の出力器、
    入力したデータを処理するための別途の実行プログラムまたはプラットフォームを実行したりセッションを管理する実行器、
    このようなデータを入力器を通じて入力して実行器上で処理し、これを出力するための一連の制御を担当する制御器を含む、請求項１４に記載のクロスドメイン適応型ワークフローエンジンフレームワーク。
19. ユーザーによって定義されたワークフローの実行に必要なワークフロー属性明細コンポーネントを組み立て、ワークフローの実行に必要なエンジンコンポーネントを動的に組み合わせてエンジンコンポーネントコンテナを構成してワークフロー実行エンジンを生成する方法であって、
    ワークフロー明細の入力を受けて、これから、エンジンを構成するエンジンコンポーネントに対する属性明細が入れられる属性明細コンポーネントインスタンスを生成する段階、
    生成した属性明細コンポーネントインスタンスをエンジンコンポーネントの生成子パラメーターと指定してエンジンコンポーネントインスタンスを生成する段階、．
    エンジンコンポーネントコンテナにバインディングしてエンジンコンポーネントコンテナインスタンスを生成子パラメーターとして、エンジンを生成する段階を含む、ワークフロー実行エンジンの生成方法。
20. 請求項１４に記載されたクロスドメイン適応型ワークフローエンジンフレームワークに含まれた前記クロスドメイン融合システムが、クロスドメインに含まれた各単一ドメインに必要なエンジンを配布する単一ドメインを決定する方法であって、
    １）各エンジンに必要なデータの出発地と到着地が同一ドメインに存在するのか把握する段階、
    ２）エンジンのデータ出発地と到着地が同一ドメインに存在すると、該当ドメイン内の資源を利用してエンジンの構成が可能であるかを判断する段階、
    ３）エンジン構成が可能であれば、該当ドメインにエンジンを構成するようにエンジン明細を配布する段階、
    ４）段階１）の判断結果、エンジンのデータ出発地と到着地が同一ドメインに存在しない場合に、または、段階２）でエンジン構成が不可であると判断されると、同一エンジンコンポーネント構成が可能な他のドメインを検索して代替可能な候補ドメイン群を決定する段階、
    ５）候補ドメイン群が決定されると、それらのうち代替ドメインを決定するために費用算定を実行し、配布ドメイン選定政策を適用して配布しなければならない最適なドメインを選定する段階を含む、エンジン配布ドメイン決定方法。

Images