JP6927557B2 - 管理システム - Google Patents

Description

本発明はデータ処理技術に関し、特に管理装置、管理システム、管理方法およびコンピュータプログラムに関する。

本発明者は、複数のタスクを半順序関係で整列したワークフローを使用して、分散した環境で自律的に動作する個々のエージェントを全体として協調して動作するよう制御する技術を提案している（例えば特許文献1参照）。

特開２０１５−２０４０１３号公報

近年、センシング技術の向上により、モノやサービスの生産現場の状態を示すデータがリアルタイムに把握できるようになってきている。しかし、上記生産現場の状態を示す個々のデータがバラバラに管理されていたのでは、それらのデータに基づいて、製品や仕掛品を改善することは難しく、また、生産プロセスのイノベーションを生み出すことは難しいと本発明者は考えた。

本発明は上記課題を鑑みてなされたものであり、主な目的は、工場のロット管理の生産システムや建築現場の作業等で遂行される複数のタスクであり、所定の成果物を生産するために予め順序関係が定められた複数のタスクについて、個々のタスクの遂行過程で得られる様々なデータを、その後の利活用に資する態様で管理する技術を提供することである。

上記課題を解決するために、本発明のある態様の管理装置は、所定の順序で遂行されるべき複数のタスクについて、各タスクの遂行に際して得られたデータをタスク単位にまとめたタスクデータを保持するタスクデータ保持部と、複数のタスクのうち少なくとも１つのタスクの遂行に関連する外部機器から送信された、１つのタスクの開始を示すデータを取得するとともに、１つのタスクの終了を示すデータを取得する取得部と、１つのタスクの開始を示すデータが取得された場合、１つのタスクに関するタスクデータに開始時刻を記録し、１つのタスクの終了を示すデータが取得された場合、１つのタスクに関するタスクデータに終了時刻を記録する更新部と、を備える。更新部は、１つのタスクの開始を示すデータが取得された後、１つのタスクの終了を示すデータが取得される前に、１つのタスクの遂行に関するデータが取得された場合、１つのタスクに関するタスクデータに遂行に関するデータを記録する。

本発明の別の態様は、管理システムである。この管理システムは、所定の順序で遂行されるべき複数のタスクのうち少なくとも１つのタスクの遂行に関連する機器と、管理装置と、を備える。管理装置は、複数のタスクそれぞれの遂行に際して得られたデータをタスク単位にまとめたタスクデータを保持するタスクデータ保持部と、機器から送信された、１つのタスクの開始を示すデータを取得するとともに、１つのタスクの終了を示すデータを取得する取得部と、１つのタスクの開始を示すデータが取得された場合、１つのタスクに関するタスクデータに開始時刻を記録し、１つのタスクの終了を示すデータが取得された場合、１つのタスクに関するタスクデータに終了時刻を記録する更新部と、を含む。更新部は、１つのタスクの開始を示すデータが取得された後、１つのタスクの終了を示すデータが取得される前に、機器から送信された、１つのタスクの遂行に関するデータが取得された場合、１つのタスクに関するタスクデータに遂行に関するデータを記録し、機器は、１つのタスクを遂行する機器であるタスク遂行装置と、タスク遂行装置に接続された通知装置とを含む。タスク遂行装置は、本装置の動作状態に基づく制御信号が入力され、その制御信号に基づいてオン／オフするスイッチを含む。通知装置は、スイッチと接続され、スイッチのオン／オフ状態を示す状態信号を出力するフォトカプラと、フォトカプラから出力された状態信号に基づくデータを１つのタスクの遂行に関するデータとして出力する出力部と、を含む。

本発明のさらに別の態様は、管理方法である。この方法は、所定の順序で遂行されるべき複数のタスクについて、各タスクの遂行に際して得られたデータをタスク単位にまとめたタスクデータを保持するタスクデータ保持部を備えるコンピュータが、複数のタスクのうち少なくとも１つのタスクの遂行に関連する外部機器から送信された、１つのタスクの開始を示すデータを取得するステップと、１つのタスクの開始を示すデータが取得された場合に、１つのタスクに関するタスクデータに開始時刻を記録するステップと、外部機器から送信された、１つのタスクの終了を示すデータを取得するステップと、１つのタスクの終了を示すデータが取得された場合に、１つのタスクに関するタスクデータに終了時刻を記録するステップと、を実行し、１つのタスクの開始を示す情報が取得された後、１つのタスクの終了を示す情報が取得される前に、１つのタスクの遂行に関するデータが取得された場合、１つのタスクに関するタスクデータに遂行に関するデータを記録するステップをさらに実行する。

なお、以上の構成要素の任意の組合せ、本発明の表現を、プログラム、プログラムを格納した記録媒体などの間で変換したものもまた、本発明の態様として有効である。

本発明によれば、所定の成果物を生産するために予め順序関係が定められた複数のタスクについて、個々のタスクの遂行過程で得られる様々なデータを、その後の利活用に資する態様で管理することができる。

分散協調制御の事例１を示す図である。 分散協調制御の事例１を示す図である。 分散協調制御の事例２を示す図である。 実世界ＯＳによる制御範囲を模式的に示す図である。 前提技術のＩＯＴ機器制御システムを示す図である。 図５のワークフロー管理装置の機能構成を示すブロック図である。 前提技術のワークフローを模式的に示す図である。 ＩＯＴ機器制御システムの動作を示すシーケンス図である。 モノを製造するプロジェクトの一例を示す図である。 図９のプロジェクトにおけるスケジュールの一例を示す図である。 図９のプロジェクトにおけるスケジュールの一例を示す図である。 図１１（ａ）のスケジュールによるタスクの遂行過程を模式的に示す図である。 第１実施例のプロジェクト管理システムの構成を示す図である。 図１３の管理装置の機能構成を示すブロック図である。 複数のタスクの遂行順序を定めたデータの例を示す図である。 タスクデータの例を示す図である。 プロジェクトの遂行過程を模式的に示す図である。 第２実施例のタスク遂行側機器の構成をブロック図である。

（前提技術の概要説明）
まず、前提技術の概要として、複数のタスクを半順序関係で整列したワークフローベースのシステムデザインを説明する。プロジェクトであれ定型業務であれ、順序づけられたタスクの集合という意味でのワークフローは、何らかの仕事を体系立てて整理し、理解し、実行するための基本的な認識の単位である。ワークフローは、ワークフローを構成する個々のタスクに対して、実際にタスクを遂行するリソースを割り当てていき、一連の作業、サービスを実現する。

実際にタスクを遂行するリソースは、例えば人、プログラム、機器等であってよく、以下「エージェント」とも呼ぶ。特に、インターネット等のネットワークに接続されて外部機器と通信可能なエージェントを「ＩＯＴ（Internet Of Things）機器」とも呼ぶ。

様々なセンサやコントローラ、アクチュエータ等、膨大な数のエージェントを対象として、あるワークフローにおいてこれらの制御を行う場合に、各エージェントの並列作業を効率的に管理する手法は、これまで十分な提案がなされていない。ワークフロー内のタスク間の関係は、線形順序（すなわち全順序）ではなく半順序構造を持つことがある。例えば、あるタスクの後に実行可能な複数のタスクがあり、これら複数のタスクのどちらが先に実行されてもよいことがしばしばある。これら複数のタスクは並列関係と言え、各タスクの遂行を並列実行することができる。この並列性は、同じタスクが割り当てられた複数のエージェント間でのタスク遂行の並列性とは次元が異なる。

ワークフローが定めるタスクを、実行順序を制御するための因果順序のシンボルとして用いる場合に「タスクステージ」と呼ぶ。ワークフローの各タスクステージに対応するエージェントの活動は、個々のノード（例えばエージェントが実装されたセンサ等、各種機器）において自律動作を行うプログラムとして記述されていることが前提となる。個々のノードは、現在どのタスクステージであるかを示す情報を取得し、そのタスクステージに対応する個々のエージェントプログラムを起動する。また、個々のエージェントはタスクステージに対応する処理が終了したことをワークフロー側へ報告し、次のタスクの指示を待つ。

ワークフローにもとづいて、実世界のエージェント個々によるタスクの実行順序を制御する機能を「タスクマネージャ」と呼ぶ。タスクマネージャは、ワークフローの実行エンジンとも言え、今どのタスクステージを実行すべきであるかをエージェントへ通知する。さらにタスクの完了通知をエージェントから受け取り、適宜タスクステージを進める。このように、タスクマネージャとエージェント間にはタスク管理のためのデータフローが生じる。

以下、分散した環境で自律的に動作する個々のエージェントを、全体として協調して動作するよう制御することを「分散協調制御」とも呼ぶ。前提技術ではワークフローを使用して分散協調制御を実現する。また、分散協調制御により、自律した個々のエージェントを全体として協調動作させるシステムを「自律分散協調システム」とも呼ぶ。前提技術では、ネットワークを介して結ばれたＩＯＴ機器の間での分散協調的ワークフローの管理技術を提案する。

自律分散協調システムでは、個々のエージェント間におけるデータストリームの意味でのデータフローも重要になる。例えば、あるタスクステージにおける計測タスクや計算タスクの実行結果は、その結果を入力とする別のタスクステージにおける計算タスクや制御タスクへ受け渡さなければならない。また、このようなエージェント間のデータフローはタスクマネージャを経由する必要はない。

前提技術では、タスクマネージャとエージェント間のデータフロー、および、あるエージェントと別のエージェント間のデータフローをパブリッシュ・サブスクライブ（以下「ＰＵＢーＳＵＢ」とも呼ぶ。）のスキームを使って実現する。ＰＵＢ−ＳＵＢスキームは、送信元と送信先でデータを共有するために、ブローカと呼ばれる特殊なエージェントを用いる。

送信先の主体に対して渡すべきデータにトピックと呼ばれるタグを付加し、トピックを付加したデータをブローカへ送信する送信元の主体はパブリッシャと呼ばれる。また、特定のトピックが付加されたデータの転送リクエストをブローカへ登録する主体（すなわちデータの送信先の主体）はサブスクライバと呼ばれる。ブローカへパブリッシュされたデータのうち、サブスクライバが登録したトピックを有するデータを、ブローカはサブスクライバへ配信する。

ＰＵＢ−ＳＵＢは、アドレス等の概念なしに必要なデータを必要な所に、多対多で送ることができるスキームである。前提技術では、タスクマネージャとエージェント間においてタスクステージに関する管理情報を転送するための管理ブローカと、複数のエージェント間でタスク遂行に必要なデータを転送するためのデータブローカの２つを使用するシステムを提案する。

タスクマネージャとエージェントの基本的な動作を説明する。
（１）タスクマネージャは、管理ブローカに、現在実行可能なタスクステージ名をパブリッシュする。エージェントは、予め自分の遂行するタスクステージ名をブローカへ登録しておき、登録したタスクステージ名がパブリッシュされると、その事実を管理ブローカからサブスクライブしてタスクを遂行する。タスクの遂行が終了したエージェントは、タスクステージの終了と必要な管理情報を管理ブローカへパブリッシュするとともに、必要なトピックを付して他のエージェントによるタスク遂行用のデータをデータブローカへパブリッシュする。

（２）タスクマネージャは、タスクステージの遷移可否を判断する。これを決めるのがタスク遷移述語である。タスク遷移述語は、エージェントから受け付けたタスク終了情報や管理データなどにもとづいて、次のタスクステージへ遷移してよいかを判定するプログラムである。

例えば、エージェントとしてのセンサを数百個設置して所定の環境状態（温度等）を計測し、環境状態の平均値を求めて何らかの制御を実行するシステムを考える。このシステムのタスクマネージャには、半数のセンサが計測（すなわちタスク処理）を終了してタスク終了情報を送ってくれば、次のステージに遷移してよいことを定めるタスク遷移述語を実装してもよい。また、分散ストリーム計算においては、計算が無事終了したことを示すタスク終了情報の受け付けをもってステージの遷移を決定するタスク遷移述語を実装してもよい。また、計算が異常終了した旨のタスク終了情報を受け付けた場合に、通常のワークフローから非常用のワークフローへ遷移する等の分岐の判断についてもタスク遷移述語に実装する。

（３）上記（１）（２）のプロセスを繰り返すことで、タスクマネージャはタスクステージ毎に実世界のエージェントとのハンドシェイクを遂行していく。この場合、タスクステージ間の並列性は、複数のタスクステージ名を並列してパブリッシュすることで実現される。また、同じタスクステージに属する複数のエージェントは、実世界において並列にタスクを遂行する。エージェント間の並列処理は、順序が入れ替わったり遅延があったとしても、タスクマネージャによる判定結果には影響がない。これは、人間によるプロジェクト管理においても、ワークフローを用いた分散協調制御においても同様である。

次に分散協調制御の事例を説明する。
事例１．センサによる機器の管理とエネルギー会計の制御：
この例では、複数の温度センサと複数の照度センサのデータから、平均温度と最小照度を計算し、それをもとにコントローラがエアコンと照明を制御する。また、エアコンと照明の稼働状態にもとづいてエネルギー消費を計算し、その計算結果をステークホルダへ通知する処理を制御する。

図１は、事例１の制御のためのタスクステージと、各タスクステージへのリソースマッピングを示している。事例１では、センサ（図中の「Ｓ」）によるデータ収集のタスクステージに対して複数のセンサが割り当てられている。また、各タスクステージに対するリソースの割当は固定的である。図２は、ブローカを介したデータ連携を模式的に示している。事例１では、タスクマネージャと実世界エージェント間のステージ管理を仲介する管理ブローカであるステージブローカと、複数のエージェント間のデータフローを仲介するデータブローカの２つが、制御フローとデータフローのそれぞれをＰＵＢ−ＳＵＢスキームで仲介する。

図２では、複数のエージェント間のデータフローをシーケンス図で示している。シーケンス図の特性上、矢印の記載位置（上下関係）により処理の前後関係があるように見えるが、実際には並列実行される処理を含む。例えば、センサから計算ノードへのデータの転送はどの順序で実行されてもよい。また、計算ノード１、２からそれぞれコントローラ１、２への計算結果の転送も順序に依存しない。なお旧来のアクティビティ図は、図１の図式と同様に見えるが、制御のメカニズムは定式化されていない。

事例２．内装工事のワークフローとタスク管理：
図３は、マンション等の内装工事のプロジェクトを簡略化して示している。ここでは、タスクの遂行リソース（実世界エージェント）を電気工、配管工、床工、壁貼り工、塗装工とする。また、図３に示すプロジェクトが部屋の数だけあるとする。この場合、図３のワークフローを制御する複数のタスクマネージャを並行して動作させ、各エージェントは、各タスクマネージャからの指示にしたがって特定の部屋の作業を実施する。実際には、各エージェントは、ＰＣやスマートフォン、タブレット端末等の情報端末を保持し、タスクマネージャは当該情報端末との間でタスクステージ情報を送受する。

各エージェントは、割り当てられた部屋の担当タスクが終了すると、その終了の事実を情報端末へ入力し、タスクマネージャは各エージェントの情報端末からの終了通知にもとづいてタスクステージを適宜進行させる。各エージェントは、別の部屋の担当タスクを、それが遂行可能な状態にあるならば着手する。遂行可能な状態にあるとは、すなわち前段階のタスクステージが終了し、タスクマネージャから別の部屋のタスクに対応するタスクステージの開始が通知されたことである。このようにヒューマン・エージェント（人が保持する情報端末を含む）は、タスクマネージャからステージの着手可能信号を受け取ることを契機としてタスクに着手する。

本発明者が考えるリアルワールド・オペレーティングシステム（以下「実世界ＯＳ」とも呼ぶ。）は、実世界のエージェントの複雑で分散協調的な相互作用を、これまでに述べたタスクマネージャの機能を中核にして、ワークフロー単位で管理し、実行させるための仕組みである。これからのＩＯＥ（Internet Of Everything）時代には、分散環境にある様々な自律的エージェントが同期し、協調し、全体としてワークフローとしてデザインされたサービスを提供することが求められる。実世界ＯＳは、膨大なエージェントが結びついた様々なシステムを設計、実装、管理するための基幹プラットフォームになる。

図４は、実世界ＯＳのビジョンを示し、実世界ＯＳによる制御範囲を模式的に示す。図の左側は仮想領域であり、シミュレーションによる仮想エージェントを含む。また図の右側は実世界エージェントの管理領域である。図４で示すように、タスクマネージャはエージェントベースのシミュレーションのコアエンジンになり、また、実世界エージェントの制御エンジンにもなる。これにより、仮想世界でのエージェントベースモデリングから、実世界でのエージェントコンピューティングまでシームレスに繋ぐことができる。シミュレーションによる設計と実世界エージェントを対象としたワークフローの管理の間で、仮想世界でシミュレーションをしたワークフローとプログラムとしてのエージェントを、実世界のエージェントに部分的に入れ替えること（部分実装）を行いながら、プロトタイピングを様々に行う設計方式が可能となり、最終的には実世界エージェントの管理のための動的な設計図として、エージェントベースのシミュレーションが残る。

実世界ＯＳが、ＩＯＴエージェントに対して分散協調制御を実行することで提供可能なサービスの例として、以下の（１）〜（７）が想定される。
（１）センサリング＆コントロール系サービスとして、ＨＥＭＳ、ＢＥＭＳ、ＣＥＭＳでのエネルギーセンサリングとそれによる機器制御のサービス、また、家やオフィス、コミュニティにおける見守りサービスやセキュリティサービスを提供する。
（２）データの分散検索系サービスとして、複数の病院の電子カルテの並列検索サービスを提供する。
（３）ビジネスデータ処理系サービスとして、図１〜図３で示すような自律分散的なビジネスデータ処理を提供する。

（４）安心安全やコミュニティ系のサービスとして、４−１）災害時のデータ収集とデータ共有サービス、４−２）災害時の電子カルテサービス、４−３）日常的なコミュニティでのアンケート調査と、調査結果の共有および加工サービスを提供する。
（５）センサリング＆統計・会計処理系サービスとして、ＨＥＭＳ、ＢＥＭＳ、ＣＥＭＳでのエネルギーセンサリングにもとづくエネルギー統計サービスや会計処理サービスを提供する。
（６）ライフログ系サービスとして、様々なライフログの収集・利用システムを提供する。
（７）ファクトリー系サービスとして、工場のエネルギー管理システムから工場のセンサネットワークを提供する。

このように、生活世界や産業社会の諸サービスは多かれ少なかれＩＯＴエージェントを利活用した自律分散協調システムとしてデザインできる。その自律分散協調システムの設計、実装、制御を支援することが実世界ＯＳの重要なミッションとなる。なお、実世界におけるＩＯＴエージェントの複雑な相互作用をバーチャルにデザインし、エミュレーションによるテストを行いつつ、徐々に実世界エージェントに置き換えていくこと、そして最終的に実世界エージェントによる自律分散協調システムを実現するという新しいシステム開発手法も想定される。

（前提技術の詳細説明）
以下では、上記の概要で説明した分散協調制御を実現するワークフロー管理装置を詳細に説明する。図５は、前提技術のＩＯＴ機器制御システム１０を示す。ＩＯＴ機器制御システム１０は、自律分散協調システムを具現化した情報処理システムである。ＩＯＴ機器制御システム１０は、ＩＯＴ機器１１、ワークフロー管理装置１２、ステークホルダ端末１３、ブローカ１５を備える。

ＩＯＴ機器１１は、実世界に存在する複数種類のエージェント機器である。各ＩＯＴ機器１１は、インターネットに接続されており、それぞれ自律して動作する。例えば、ワークフロー管理装置１２から通信網を介してステージが通知された場合に、そのステージに対応する動作を実行するものであり、この動作を実行するためのプログラム（およびプログラムを実行するためのＭＰＵ等）を搭載したものであってよい。前提技術のＩＯＴ機器１１は、センサ機器２０、計算ノード３０、コントローラ４０、サービス機器５０を含む。

センサ機器２０は、公知の種々のセンサを備える機器である。例えばセンサ機器２０は、周囲の環境状態を検出し、その環境状態を示す情報を出力する。また例えば、周囲の環境状態が特定の状態になった場合にその事実を検出し、出力する。前提技術のセンサ機器２０は、複数の温度センサ２２と複数の照度センサ２４を含む。例えば、工場に設置された数百個の温度センサを含み、また、オフィスビルのある居室に設置された数十個の照度センサを含む。

計算ノード３０は、各種の計算処理を実行する情報処理装置である。計算ノード３０は、温度計算ノード３２、照度計算ノード３４、会計計算ノード３６を含む。温度計算ノード３２は、複数の温度センサ２２により計測された温度にもとづき平均温度を計算し、照度計算ノード３４は、複数の照度センサ２４により計測された照度にもとづき最小照度を計算する。会計計算ノード３６は、エアコンの設定温度と、照明のオンオフ状態にもとづいて、所定のエネルギー会計計算を実行する。例えば、エネルギーの消費量や消費金額等を算出し、またエネルギー簿記を実行する。

サービス機器５０は、電気やガス等のエネルギーを消費しつつ生活世界や産業社会の諸サービスをユーザへ提供する機器であり、エネルギー消費機器とも言える。サービス機器５０は、エアコン５２と照明５４を含む。コントローラ４０は、サービス機器５０の動作を制御する制御機器である。コントローラ４０は、エアコンコントローラ４２と照明コントローラ４４を含む。エアコンコントローラ４２は、エアコンの設定温度を制御し、照明コントローラ４４は、照明のオンオフを制御する。

ワークフロー管理装置１２は、概要で説明したタスクマネージャと実世界ＯＳを具現化した情報処理装置である。ワークフロー管理装置１２は、ワークフローで定められたタスクステージ（以下、単に「ステージ」と呼ぶ。）の遷移にしたがって、複数のＩＯＴ機器１１の動作を制御する。ワークフロー管理装置１２の詳細な機能は後述する。なおワークフロー管理装置１２の物理的な態様に制限はなく、例えばＰＣやサーバでもよく、マイクロコントローラ、シングルボードコンピュータであってもよい。

ステークホルダ端末１３は、ＩＯＴ機器１１が設置された企業の担当者等、所定のステークホルダーにより操作される情報端末である。ステークホルダ端末１３は、会計計算ノード３６による計算結果であるエネルギー会計情報を取得し、適宜ディスプレイ等に表示させる。

ブローカ１５は、ＰＵＢ−ＳＵＢスキームにより装置間でのデータ送受を仲介する装置である。ブローカ１５は、公知のメッセージキュー製品やメッセージ指向ミドルウェアにより実現されてもよい。図５の各装置は、ＬＡＮ・ＷＡＮ・インターネット等の通信網を介し、ブローカ１５が定める通信プロトコルにしたがってＰＵＢ−ＳＵＢのスキームにてブローカ１５と通信し、装置間でデータを送受する。

ブローカ１５は、ステージブローカ１６とデータブローカ１７を含む。ステージブローカ１６は、上述の管理ブローカであり、ワークフロー管理装置１２と各ＩＯＴ機器１１間におけるステージの開始・終了に関する管理情報の送受を仲介する。データブローカ１７は、ＩＯＴ機器１１同士、または、ＩＯＴ機器１１とステークホルダ端末１３間におけるデータの送受を仲介する。

ここでＩＯＴ機器制御システム１０では、ワークフロー管理装置１２が管理するワークフローがどのようなステージを有するか、また、各ステージにおいてエージェントがどのような処理をすべきかが予め決められ、ＩＯＴ機器１１の製造者に公開される。各ＩＯＴ機器１１は、ワークフロー管理装置１２から特定のステージが通知された場合に、そのステージに応じた処理を行うよう実装される。

例えば、後述の温度収集ステージについて、周囲の温度を取得するタスクを実行すべきであることが予め定められ、公開される。温度センサ２２は、温度収集ステージの通知をサブスクライブしたことを契機に、周囲の温度を測定し、タスクの終了をステージブローカ１６へパブリッシュし、測定した温度をデータブローカ１７へパブリッシュするよう実装される。また後述の平均温度計算ステージについて、複数の温度データの平均を算出するタスクを実行すべきであることが予め定められ、公開される。温度計算ノード３２は、平均温度計算ステージの通知をサブスクライブしたことを契機に、複数の温度センサ２２が測定した温度の平均値を算出し、タスクの終了をステージブローカ１６へパブリッシュし、算出した平均温度をデータブローカ１７へパブリッシュするよう実装される。

図６は、図５のワークフロー管理装置１２の機能構成を示すブロック図である。ワークフロー管理装置１２は、通信部６０、制御部７０、データ記憶部８０を備える。通信部６０は、所定の通信プロトコルにしたがって外部装置とデータを送受する。例えば、予め定められたメッセージプロトコルにしたがって、ステージブローカ１６とのＰＵＢ−ＳＵＢスキームでのデータ送受を実行する。

制御部７０は、ワークフロー管理装置１２の動作を制御する。また、ワークフロー管理、言い換えれば、複数のＩＯＴ機器１１を分散協調制御するためのデータ処理を実行する。データ記憶部８０は、制御部７０によるデータ処理において参照され、また更新される各種データを記憶する記憶領域である。

本明細書のブロック図で示す各ブロックは、ハードウェア的には、コンピュータのＣＰＵやメモリをはじめとする素子や機械装置で実現でき、ソフトウェア的にはコンピュータプログラム等によって実現されるが、ここでは、それらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックはハードウェア、ソフトウェアの組合せによっていろいろなかたちで実現できることは、当業者には理解されるところである。

例えば、制御部７０の各機能ブロックに対応するソフトウェアモジュールを備えるアプリケーションプログラムがワークフロー管理装置１２にインストールされてもよい。そして、ワークフロー管理装置１２のＣＰＵが、各ソフトウェアモジュールをメモリに読み出して実行することにより、制御部７０の各機能ブロックの機能が発揮されてもよい。また、データ記憶部８０の各機能ブロックは、ストレージやメモリ等の記憶装置がデータを記憶することにより実現されてもよい。

データ記憶部８０は、ワークフロー情報保持部８２とステージ情報保持部８４を含む。ワークフロー情報保持部８２は、ワークフロー情報として、ワークフローが定める各ステージの前後関係と、各ステージから次のステージへ移行させる条件を保持する。典型的な移行条件は、ステージに予め対応づけられたタスクを終了したエージェントから、当該ステージのタスクを終了した旨の通知を受け付けることである。

ただし、複数のエージェントが１つのステージのタスクを並列実行する場合、当該ステージから次のステージへの移行条件として、一部のエージェントからタスク終了通知を受け付けたことをもって次のステージへの以降を許可得することを定めることができる。言い換えれば、タスクを実行させた複数のエージェントの全てからタスク終了通知を受け付けなくても、複数のエージェントのうち所定数以上のエージェントからタスク終了通知を受け付ければ次のステージへ移行させることを定めることができる。

図７は、前提技術のワークフローを模式的に示す。前提技術のワークフローは、概要で説明した事例１（例えば図１）に対応する形で、複数のステージ間の遷移を定め、また複数種類の実世界エージェントの動作を制御する。

ワークフロー情報保持部８２は、各ステージの前後関係として、ワークフロー開始後に、温度収集ステージ１００と照度収集ステージ１０２に移行すること、温度収集ステージ１００の次が平均温度計算ステージ１０４であることを示す情報を保持する。また、平均温度計算ステージ１０４の次がエアコン制御ステージ１０８であり、エアコン制御ステージ１０８の次がエネルギー会計計算ステージ１１２であることを示す情報を保持する。また、照度収集ステージ１０２の次が最小照度計算ステージ１０６であり、最小照度計算ステージ１０６の次が照明制御ステージ１１０であり、照明制御ステージ１１０の次がエネルギー会計計算ステージ１１２であることを示す情報を保持する。また、エネルギー会計計算ステージ１１２の終了によりワークフローが終了することを示す情報を保持する。

またワークフロー情報保持部８２は、温度収集ステージ１００から平均温度計算ステージ１０４への移行条件として、１００個の温度センサ２２のうち５０個以上の温度センサ２２から温度測定タスクの終了が通知されることを定めている。また、平均温度計算ステージ１０４からエアコン制御ステージ１０８への移行条件として、温度計算ノード３２から平均温度計算タスクの終了が通知されることを定めている。また、照度収集ステージ１０２から最小照度計算ステージ１０６への移行条件として、２０個の照度センサ２４のうち１５個以上の照度センサ２４から照度測定タスクの終了が通知されることを定めている。また、最小照度計算ステージ１０６から照明制御ステージ１１０への移行条件として、照度計算ノード３４から最小照度計算タスクの終了が通知されることを定めている。

図６に戻り、ステージ情報保持部８４は、ワークフローが現在どのステージであるかを示すステージ情報を保持する。ステージ情報には、ワークフローのステージがそれまでとは異なる新たなステージに移行した場合に、新たなステージの識別情報（名称やＩＤ等）が記録される。

ステージ情報は、現在のステージとして、複数のステージが同時に記録されることを許容する。図７の例では、温度収集ステージ１００〜平均温度計算ステージ１０４〜エアコン制御ステージ１０８と、照度収集ステージ１０２〜最小照度計算ステージ１０６〜照明制御ステージ１１０が並列して進められる。したがってステージ情報保持部８４は、現在のステージが温度収集ステージ１００であり、かつ、照度収集ステージ１０２、最小照度計算ステージ１０６、照明制御ステージ１１０のいずれかでもあることを示すステージ情報を保持し得る。またステージ情報保持部８４は、現在のステージが照度収集ステージ１０２であり、かつ、温度収集ステージ１００、平均温度計算ステージ１０４、エアコン制御ステージ１０８のいずれかでもあることを示すステージ情報を保持し得る。

制御部７０は、ステージ通知部７２、終了通知受付部７４、移行判定部７６、ステージ更新部７８を含む。ステージ通知部７２は、ステージ情報保持部８４に保持されたステージ情報を監視し、ステージ情報が更新された場合に、現在のステージを示す情報（以下「現在ステージ情報」と呼ぶ。）をステージブローカ１６へ送信する。これにより、現在のステージを１つ以上のＩＯＴ機器１１へ通知し、現在のステージに応じた動作を１つ以上のＩＯＴ機器１１に並列実行させる。

ステージ通知部７２が送信する現在ステージ情報は、現在のステージを識別可能な情報（例えばステージ名称やＩＤ）を含む。例えば、現在のステージの識別情報を示すトピックを付加したメッセージである。その一方、ＩＯＴ機器１１の動作態様を指定する内容は現在ステージ情報から排除されている。例えば現在ステージ情報は、ＩＯＴ機器１１の動作を直接的に規定するコマンドや、ＩＯＴ機器１１の動作時に参照され、ＩＯＴ機器１１の動作を間接的に規定するパラメータを含まない。このようにワークフロー管理装置１２は、ＩＯＴ機器１１に対して現在のステージを通知しつつ、現在のステージに対する具体的な動作は各ＩＯＴ機器１１の実装に委ねる。これにより、ＩＯＴ機器制御システム１０における各ＩＯＴ機器１１の独立性を高め、またセキュリティを高める。

終了通知受付部７４は、各ＩＯＴ機器１１から送信された動作終了通知をステージブローカ１６から受信する。動作終了通知は、ワークフローの現在のステージに対応する処理、言い換えれば、現在のステージで実行するよう定められたタスクが終了したことを示す情報であり、「タスク終了通知」とも言える。動作終了通知は、ＩＯＴ機器１１側で動作を終了したステージの識別情報を含むものであってよい。ただし動作終了通知は、ＩＯＴ機器１１におけるタスク処理で得られたデータ、例えば温度データや平均温度データを含まない。これらのデータは、データブローカ１７を介して、ＩＯＴ機器１１同士で送受される。これにより、ワークフロー管理装置１２は、ステージの開始、終了、移行判断に専念することができる。

移行判定部７６は、終了通知受付部７４における動作終了通知の受信状況にもとづいて、ワークフローの現在のステージについてワークフロー情報保持部８２に保持された次のステージへの移行条件が充足されたか否かを判定する。移行判定部７６は、移行条件が充足されたことを検出すると、移行元のステージと移行先のステージの組み合わせをステージ更新部７８へ通知する。

例えば、温度収集ステージ１００から平均温度計算ステージ１０４への移行条件として、１００個の温度センサ２２のうち半分の温度センサ２２から温度測定タスクの終了が通知されることを定めることができる。この場合、移行判定部７６は、温度収集ステージ１００の動作が終了した旨を示す動作終了通知が５０個以上受信された場合に上記移行条件が充足されたと判定してもよい。同様に、照度収集ステージ１０２から最小照度計算ステージ１０６への移行条件として、２０個の照度センサ２４のうち１５個以上の照度センサ２４から照度測定タスクの終了が通知されることを定めることができる。この場合、移行判定部７６は、照度収集ステージ１０２の動作が終了した旨を示す動作終了通知が１５個以上受信された場合に上記移行条件が充足されたと判定してもよい。

ステージ更新部７８は、現在のステージの移行条件が充足されたことが移行判定部７６により判定された場合に、現在のステージを次のステージへ進めるようステージ情報保持部８４に保持されたステージ情報を更新する。具体的には、移行判定部７６から移行元ステージと移行先ステージの組み合わせが通知された場合に、ステージ情報に記録された移行元ステージを、移行先ステージへ切り替えるようステージ情報を更新する。

またステージ更新部７８は、複数のステージが現在のステージとしてステージ情報に記録されている場合、それら複数のステージのうち移行判定部７６から通知された移行元ステージを、移行先ステージへ切り替えるようステージ情報を更新する。その一方、複数のステージのうち移行元ステージとして指定されないステージは、ステージ情報に記録されたままとし、すなわち現在のステージとして維持する。

例えば、現在のステージが温度収集ステージ１００と照度収集ステージ１０２であり、温度収集ステージ１００の移行条件のみが充足された場合、ステージ更新部７８は、現在のステージを平均温度計算ステージ１０４と照度収集ステージ１０２とするようステージ情報を更新する。その後、平均温度計算ステージ１０４の移行条件のみが充足された場合、ステージ更新部７８は、現在のステージをエアコン制御ステージ１０８と照度収集ステージ１０２とするようステージ情報を更新する。このように、複数のステージを並列して進めるようワークフローが規定されている場合、ＩＯＴ機器１１の動作制御および次のステージへの遷移を、並列するステージ毎に独立して実行する。

以上の構成によるＩＯＴ機器制御システム１０の動作を以下説明する。
図８は、ＩＯＴ機器制御システム１０の動作を示すシーケンス図である。図８は、図７のワークフローにしたがってワークフロー管理装置１２がＩＯＴ機器１１を制御する際の動作を示している。また図８は、概要で説明した事例１（例えば図２）に対応する。シーケンス図上、並列するステージ（例えば照度収集ステージ１０２と平均温度計算ステージ１０４等）の処理に前後関係があるように見えるが、並列するステージの処理は結果として前後関係が生じるものの、本質的には同時並列的に実行される。

前提として、ＩＯＴ機器１１のそれぞれは、自身が動作すべき特定のステージに対して予め定められたトピック名をステージブローカ１６およびデータブローカ１７に事前に登録しておく。これにより、各ＩＯＴ機器１１は、上記特定のステージの開始を示すメッセージ、また、タスクを実行するために必要なデータを含むメッセージのサブスクライバとして動作する。また各ＩＯＴ機器１１は、上記特定のステージに対応する動作が実装される。例えば、温度センサ２２は、温度収集ステージの開始を示す所定のトピック名をステージブローカ１６に登録しておき、また、温度収集ステージにおいて温度測定処理を実行するよう定めたプログラムを搭載している。

ワークフロー管理装置１２は、定期的に、もしくは、ユーザの指示に応じて図７のワークフローを開始する。ワークフロー管理装置１２のステージ更新部７８は、現在のステージを、温度収集ステージ１００および照度収集ステージ１０２とするようステージ情報を更新する。ステージ通知部７２は、温度収集ステージを示すトピックを付加した現在ステージ情報をステージブローカ１６へパブリッシュし（Ｓ２）、それとともに照度収集ステージのトピックを付加した現在ステージ情報をステージブローカ１６へパブリッシュする（Ｓ４）。

複数の温度センサ２２のそれぞれは、温度収集ステージを示すトピックが付加された現在ステージ情報をステージブローカ１６からサブスクライブし（Ｓ６）、周囲の温度を測定する。そして、温度測定結果を示すトピックを付加し、温度データを本文に含むメッセージをデータブローカ１７へパブリッシュする（Ｓ８）。各温度センサ２２は、温度収集ステージについての動作終了通知をステージブローカ１６へパブリッシュし（Ｓ１０）、ワークフロー管理装置１２の終了通知受付部７４は、各温度センサ２２からの動作終了通知をステージブローカ１６からサブスクライブする（Ｓ１２）。

これに並行して、複数の照度センサ２４のそれぞれは、照度収集ステージを示すトピックが付加された現在ステージ情報をステージブローカ１６からサブスクライブし（Ｓ１４）、周囲の照度を測定する。そして、照度測定結果を示すトピックを付加し、照度データを本文に含むメッセージをデータブローカ１７へパブリッシュする（Ｓ１６）。各照度センサ２４は、照度収集ステージについての動作終了通知をステージブローカ１６へパブリッシュし（Ｓ１８）、ワークフロー管理装置１２の終了通知受付部７４は、各照度センサ２４からの動作終了通知をステージブローカ１６からサブスクライブする（Ｓ２０）。

ワークフロー管理装置１２の移行判定部７６は、温度収集ステージについての動作終了通知の受信状況に応じて、温度収集ステージ１００から平均温度計算ステージ１０４への移行条件が満たされたと判定する。例えば、数百個の温度センサ２２のうち移行条件が定める個数である５０個の温度センサ２２からパブリッシュされた５０個の動作終了通知をサブスクラブした場合に、移行条件が満たされたと判定する。ステージ更新部７８は、現在のステージを温度収集ステージ１００から平均温度計算ステージ１０４へ切り替えるようステージ情報を更新する。これに並行して、移行判定部７６は、照度収集ステージについての動作終了通知の受信状況に応じて、照度収集ステージ１０２から最小照度計算ステージ１０６への移行条件が満たされたと判定する。例えば、数十個の照度センサ２４のうち移行条件が定める個数の照度センサ２４からパブリッシュされた当該個数の動作終了通知をサブスクラブした場合に、移行条件が満たされたと判定する。ステージ更新部７８は、現在のステージを照度収集ステージ１０２から最小照度計算ステージ１０６へ切り替えるようステージ情報を更新する。

このように前提技術のワークフローでは、複数のステージ間の実行順序（言い換えれば前後関係）として半順序関係を規定することを許容する。例えば、温度収集ステージ１００と照度収集ステージ１０２は半順序関係である。すなわち、これらのステージ間の実行順序は一意に定められておらず、ステージ間の実行順序を比較することはできない。言い換えれば、どちらのステージを先に開始してもよく、どちらのステージを先に終了してもよい。また、温度収集ステージ１００の次の平均温度計算ステージ１０４と照度収集ステージ１０２も半順序関係である。すなわち、これらのステージ間の実行順序は一意に定められておらず、ステージ間の実行順序を比較することはできない。既述したように、このようなステージ間の順序関係はワークフロー情報保持部８２に保持される。

ステージ更新部７８は、ワークフロー情報保持部８２に保持された順序関係を参照し、温度収集ステージ１００から平均温度計算ステージ１０４への移行条件が満たされた一方、照度収集ステージ１０２から最小照度計算ステージ１０６への移行条件が満たされていない場合、ワークフローの現在ステージが平均温度計算ステージ１０４であり、かつ、照度収集ステージ１０２でもあることを示すようステージ情報を更新する。すなわち、温度収集ステージ１００・平均温度計算ステージ１０４側のステージ移行と、照度収集ステージ１０２・最小照度計算ステージ１０６側のステージ移行を独立して実行する。

温度計算ノード３２は、温度測定結果を示すトピックが付加された複数の温度データをデータブローカ１７からサブスクライブする（Ｓ２２）。照度計算ノード３４は、照度測定結果を示すトピックが付加された複数の照度データをデータブローカ１７からサブスクライブする（Ｓ２４）。

ワークフロー管理装置１２のステージ通知部７２は、平均温度計算ステージを示すトピックを付加した現在ステージ情報をステージブローカ１６へパブリッシュし（Ｓ２６）、温度計算ノード３２はその現在ステージ情報をステージブローカ１６からサブスクライブする（Ｓ２８）。温度計算ノード３２は、複数の温度センサ２２で測定された温度にしたがって平均温度を算出し、平均温度計算結果を示すトピックを付加し、平均温度データを本文に含むメッセージをデータブローカ１７へパブリッシュする（Ｓ３０）。温度計算ノード３２は、平均温度計算ステージについての動作終了通知をステージブローカ１６へパブリッシュし（Ｓ３２）、ワークフロー管理装置１２の終了通知受付部７４はその動作終了通知をステージブローカ１６からサブスクライブする（Ｓ３４）。エアコンコントローラ４２は、平均温度計算結果を示すトピックが付加された平均温度データをデータブローカ１７からサブスクライブする（Ｓ３６）。

これに並行して、ワークフロー管理装置１２のステージ通知部７２は、最小照度計算ステージを示すトピックを付加した現在ステージ情報をステージブローカ１６へパブリッシュし（Ｓ３８）、照度計算ノード３４はその現在ステージ情報をステージブローカ１６からサブスクライブする（Ｓ４０）。照度計算ノード３４は、複数の照度センサ２４で測定された照度にしたがって最小照度を算出し、最小照度計算結果を示すトピックを付加し、最小照度データを本文に含むメッセージをデータブローカ１７へパブリッシュする（Ｓ４２）。照度計算ノード３４は、最小照度計算ステージについての動作終了通知をステージブローカ１６へパブリッシュし（Ｓ４４）、ワークフロー管理装置１２の終了通知受付部７４はその動作終了通知をステージブローカ１６からサブスクライブする（Ｓ４６）。照明コントローラ４４は、最小照度計算結果を示すトピックが付加された最小照度データをデータブローカ１７からサブスクライブする（Ｓ４８）。

ワークフロー管理装置１２の移行判定部７６は、平均温度計算ステージについての動作終了通知の受信状況にしたがって、平均温度計算ステージ１０４からエアコン制御ステージ１０８への移行条件が満たされたと判定する。ステージ更新部７８は、現在のステージを平均温度計算ステージ１０４からエアコン制御ステージ１０８へ切り替えるようステージ情報を更新する。これに並行して、移行判定部７６は、最小照度計算ステージについての動作終了通知の受信状況にしたがって、最小照度計算ステージ１０６から照明制御ステージ１１０への移行条件が満たされたと判定する。ステージ更新部７８は、現在のステージを最小照度計算ステージ１０６から照明制御ステージ１１０へ切り替えるようステージ情報を更新する。

ワークフロー管理装置１２のステージ通知部７２は、エアコン制御ステージを示すトピックを付加した現在ステージ情報をステージブローカ１６へパブリッシュし（Ｓ５０）、エアコンコントローラ４２はその現在ステージ情報をステージブローカ１６からサブスクライブする（Ｓ５２）。エアコンコントローラ４２は、温度計算ノード３２で決定された平均温度にしたがってエアコン５２の新たな設定温度を決定し、その設定温度で動作するようエアコン５２を制御する（Ｓ５４）。この例ではエアコンコントローラ４２とエアコン５２が直接接続されるが、データブローカ１７を介して間接的に接続されてもよい。

エアコンコントローラ４２は、エアコン制御結果を示すトピックを付加し、新たな設定温度を本文に含むメッセージをデータブローカ１７へパブリッシュする（Ｓ５６）。また、エアコンコントローラ４２は、エアコン制御ステージについての動作終了通知をステージブローカ１６へパブリッシュし（Ｓ５８）、ワークフロー管理装置１２の終了通知受付部７４はその動作終了通知をステージブローカ１６からサブスクライブする（Ｓ６０）。

これに並行して、ワークフロー管理装置１２のステージ通知部７２は、照明制御ステージを示すトピックを付加した現在ステージ情報をステージブローカ１６へパブリッシュし（Ｓ６２）、照明コントローラ４４はその現在ステージ情報をステージブローカ１６からサブスクライブする（Ｓ６４）。照明コントローラ４４は、照度計算ノード３４で決定された最小照度にしたがって照明５４のオンもしくはオフを決定し、照明５４を点灯もしくは消灯させる（Ｓ６６）。この例では照明コントローラ４４と照明５４が直接接続されるが、データブローカ１７を介して間接的に接続されてもよい。

照明コントローラ４４は、照明制御結果を示すトピックを付加し、照明５４のオンオフ状態を本文に含むメッセージをデータブローカ１７へパブリッシュする（Ｓ６８）。また、照明コントローラ４４は、照明制御ステージについての動作終了通知をステージブローカ１６へパブリッシュし（Ｓ７０）、ワークフロー管理装置１２の終了通知受付部７４はその動作終了通知をステージブローカ１６からサブスクライブする（Ｓ７２）。

会計計算ノード３６は、エアコン制御結果を示すトピックが付加された設定温度データをデータブローカ１７からサブスクライブする（Ｓ７４）。これに並行して、会計計算ノード３６は、照明制御結果を示すトピックが付加された照明オンオフ情報をデータブローカ１７からサブスクライブする（Ｓ７６）。

ワークフロー管理装置１２の移行判定部７６は、エアコン制御ステージについての動作終了通知の受信状況にしたがって、エアコン制御ステージ１０８からエネルギー会計計算ステージ１１２への移行条件が満たされたと判定する。また移行判定部７６は、照明制御ステージについての動作終了通知の受信状況にしたがって、照明制御ステージ１１０からエネルギー会計計算ステージ１１２への移行条件が満たされたと判定する。ステージ更新部７８は、エアコン制御ステージ１０８からエネルギー会計計算ステージ１１２への移行条件が満たされ、かつ、照明制御ステージ１１０からエネルギー会計計算ステージ１１２への移行条件も満たされた場合に、現在のステージを、エアコン制御ステージ１０８および照明制御ステージ１１０から、エネルギー会計計算ステージ１１２へ切り替えるようステージ情報を更新する。

このように前提技術のワークフローでは、複数のステージ間の実行順序として半順序関係を規定することを許容する。例えば、エアコン制御ステージ１０８と照明制御ステージ１１０は半順序関係である。すなわち、これらのステージ間の実行順序は一意に定められておらず、ステージ間の実行順序を比較することはできない。言い換えれば、どちらのステージを先に開始してもよく、どちらのステージを先に終了してもよい。またここでは、エネルギー会計計算ステージ１１２は、エアコン制御ステージ１０８と照明制御ステージ１１０の両方が終了したことを条件として実行可能である。既述したように、このようなステージ間の順序関係はワークフロー情報保持部８２に保持される。

ステージ更新部７８は、ワークフロー情報保持部８２に保持された順序関係を参照し、エアコン制御ステージ１０８からエネルギー会計計算ステージ１１２への移行条件が満たされた一方、照明制御ステージ１１０からエネルギー会計計算ステージ１１２への移行条件が満たされていない場合に、エアコン制御ステージ１０８が終了した状態であり、かつ、照明制御ステージ１１０でもあることを示すようステージ情報を更新する。その後、照明制御ステージ１１０からエネルギー会計計算ステージ１１２の移行条件が満たされると、ステージ更新部７８は、現在のステージをエネルギー会計計算ステージ１１２へ切り替えるようステージ情報を再度更新する。これにより、ワークフローをエネルギー会計計算ステージ１１２へ移行させる。

ワークフロー管理装置１２のステージ通知部７２は、エネルギー会計計算ステージを示すトピックを付加した現在ステージ情報をステージブローカ１６へパブリッシュし（Ｓ７８）、会計計算ノード３６はその現在ステージ情報をステージブローカ１６からサブスクライブする（Ｓ８０）。会計計算ノード３６は、エアコンコントローラ４２で決定されたエアコン５２の設定温度と、照明コントローラ４４で決定された照明５４のオンオフにしたがって、エネルギー会計計算処理を実行する。会計計算ノード３６は、エネルギー会計計算結果を示すトピックを付加し、エネルギー会計データを本文に含むメッセージをデータブローカ１７へパブリッシュする（Ｓ８２）。また、会計計算ノード３６は、エネルギー会計計算ステージについての動作終了通知をステージブローカ１６へパブリッシュする（Ｓ８４）。

ワークフロー管理装置１２の終了通知受付部７４は、エネルギー会計計算ステージについての動作終了通知をステージブローカ１６からサブスクライブする（Ｓ８６）。移行判定部７６がエネルギー会計計算ステージ１１２からエンドステージへの移行条件が満たされたと判定すると、ワークフロー管理装置１２における図７のワークフローの１サイクルの処理が完了する。なお、所定時間（１０分等）が経過するたびに、ワークフロー管理装置１２は図７のワークフローの処理を繰り返してもよく、すなわち、図８に示す動作を定期的に繰り返してもよい。

ステークホルダ端末１３は、エネルギー会計計算結果を示すトピックが付加されたエネルギー会計データをデータブローカ１７からサブスクライブし（Ｓ８８）、そのデータを所定の記憶装置に記憶させる。ステークホルダ端末１３は、会計計算ノード３６から定期的に通知されるエネルギー会計データを蓄積してもよく、複数回に亘り通知されたエネルギー会計データを１日単位や１月単位で集計する処理を実行してもよい。また、その集計結果を所定の記憶装置に記憶させ、また、ディスプレイや印刷装置へ出力してもよい。

前提技術のワークフロー管理装置１２は、並列する複数のステージのタスクを複数のエージェントに並列して割当て、各エージェントにタスクを並列して実行させる。また、並列する各ステージを次のステージへ進めるか否かを、タスク割当先の各エージェントが互いに独立して送信するタスク終了通知の受信状況にもとづいて決定する。これにより、制御対象のエージェント数が増加しても、各エージェントを協調動作させたサービスの提供を効率的に実現することができる。すなわち、１つのサービス提供のために実行すべき複数のタスクの処理順序を半順序で定義可能にすることで、多数のエージェントによるタスク処理を効率的に制御し、効率的なサービス提供を実現する。

例えば、あるステージの移行条件として、当該ステージのタスクを割当てた複数のエージェントのうち所定数のエージェントからタスク終了通知を受け付けた場合に次のステージへ移行することを定めることができる。この場合、具体的にどのエージェントからタスク終了通知を受け付けたかにはよらず、受信したタスク終了通知の個数が所定数に達したことを契機にステージ移行がなされる。これにより、タスク終了通知の送信元がエージェントＡである場合の処理、エージェントＢである場合の処理等、多くの種類の処理を定義する必要がなく、制御対象のエージェント数が増加しても、各エージェントを協調動作させたサービスの提供を効率的に実現することができる。

また、前提技術のＩＯＴ機器制御システム１０では、ワークフロー管理装置１２とＩＯＴ機器１１間のデータフローのためのステージブローカ１６と、ＩＯＴ機器１１同士のデータフローのためのデータブローカ１７を別個に設けた。これにより、中継対象のデータの特性に合わせて、パフォーマンスやセキュリティ等の設定を最適化したブローカを設けることができ、システム全体のパフォーマンスやセキュリティを効果的に高めることができる。例えば、ステージブローカ１６は、パフォーマンスよりもセキュリティを重点的に高めた設定とすることが望ましい。その一方、データブローカ１７は、仲介するデータ数の多寡やデータサイズの大小に応じた設定がなされてもよく、仲介するデータの特性に応じて複数のデータブローカ１７を設けてもよい。

以上、本発明を第１実施例をもとに説明した。この実施例は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。以下変形例を挙げる。

第１の変形例を説明する。上記前提技術では、ワークフロー管理装置１２による制御対象のエージェントとしてＩＯＴ機器１１を示したが、概要の事例２で示したように、エージェントは人であってもよい。この場合、ワークフロー管理装置１２は、人が保持する情報端末に対して現在のステージを通知してもよい。この情報端末は、通知されたステージに応じたタスクの内容をディスプレイに表示させてもよい。人（すなわちタスク作業者）は、タスクが完了するとその旨を情報端末へ入力し、情報端末はワークフロー管理装置１２へタスク終了通知を送信し、ワークフロー管理装置１２は、そのタスク終了通知にしたがってステージを進行させてもよい。

第２の変形例として、ステージの移行条件を含むタスク遷移述語について付言する。ワークフロー情報保持部８２は、各ステージについて定められたタスク遷移述語を保持し、ステージ更新部７８は、タスク遷移述語にしたがって各ステージの移行態様を決定する。タスク遷移述語には、ステージ移行に関する様々なＡＮＤ条件、ＯＲ条件、ＮＯＴ条件を記述可能である。

あるステージのタスク遷移述語は、移行条件が満たされた場合に次のステージへ移行することを定め、かつ、現在のステージ情報を外部へ通知後（もしくは現在のステージへ移行後）の所定時間内に次のステージへの移行条件が満たされない（例えばタイマによるタイムアウトを検出した）場合に、代替的・例外的なステージ移行を実行することを定めてもよい。所定時間内に次のステージへの移行条件が満たされないとは、例えば、ＩＯＴ機器１１からのタスク終了通知を待つべき所定の待機時間が経過した場合である。同様に、タスク遷移述語は、タスクを実行したＩＯＴ機器１１から異常を示すタスク終了通知が返された場合に、代替的・例外的なステージ移行を実行することを定めてもよい。

ステージ更新部７８は、所定時間内に移行条件が満たされない、または異常を示すタスク終了通知が返された場合に、代替的・例外的なステージ移行を実行してもよい。代替的・例外的なステージ移行は、それまでのワークフロー、もしくはそれまでとは異なるワークフローの特定のステージへ移行することでもよい。例えば、ワークフロー管理装置１２が複数のワークフローによる外部機器の制御を並行して実行する場合に、どのワークフローで例外やエラーが検出された際にも、例外処理用の共通のワークフローの特定のステージへ移行することを規定したものでもよい。本変形例によると、ワークフローにおける多様なステージ遷移を実現でき、また、ワークフローによる外部機器制御に要求される様々なエラー処理、例外処理に柔軟に対応できる。

第３の変形例を説明する。上記前提技術では言及していないが、ワークフロー管理装置１２により制御対象となるＩＯＴ機器１１は、複数のタスクステージに対応した複数の機能を備えてもよく、それら複数の機能を呼び出すための複数のＡＰＩを備えてもよい。複数のＡＰＩは、例えば、ワークフロー管理装置１２からステージＡの開始が通知された場合に呼び出されるインタフェースＡと、ステージＢの開始が通知された場合に呼び出されるインタフェースＢを含んでもよい。これにより、物理的に１つのＩＯＴ機器１１に複数種類の役割（すなわちタスク）を実行させることができる。

例えば、１つのＩＯＴ機器１１が、複数種類の環境情報を検知するマルチセンサ機器の場合に、温度収集ステージ１００を通知することで温度センサ２２として機能させ、また、照度収集ステージ１０２を通知することで照度センサ２４として機能させることができる。また例えば、１つのＩＯＴ機器１１が、複数機器を集中制御するコントローラの場合に、エアコン制御ステージ１０８を通知することでエアコンコントローラ４２として機能させ、また、照明制御ステージ１１０を通知することで照明コントローラ４４として機能させることができる。

なお、１つのＩＯＴ機器１１は、１つのワークフロー管理装置１２で動作する複数のワークフロー、または、複数のワークフロー管理装置１２で動作する複数のワークフローからステージの通知を受け付け、各ワークフローから通知されたステージに応じたタスクを実行してもよい。すなわち、１つのＩＯＴ機器１１によるサービスを複数のワークフローが利用してもよい。

また、ＩＯＴ機器１１は、ワークフローとステージの組み合わせを単位としてタスクを識別してもよく、言い換えれば、ワークフローとステージの組み合わせと、実行すべきタスクとの対応関係を保持してもよい。この場合、ワークフロー管理装置１２は、ワークフローの識別情報とステージの識別情報の組み合わせを、現在ステージ情報としてＩＯＴ機器１１へ送信してもよい。ＩＯＴ機器１１は、呼び出し元のワークフローが異なれば、同じステージ名が通知されても異なるタスクを実行してもよく、逆に、呼び出し元のワークフローが異なれば、異なるステージ名が通知されても同じタスクを実行してもよい。

第４の変形例を説明する。上記前提技術では、ブローカを介したメッセージ技術により、ワークフロー管理装置１２とＩＯＴ機器１１間のデータフローと、複数のＩＯＴ機器１１間のデータフローを実現したが、他の技術によりデータを送受してもよい。例えば、データの送信元装置と送信先装置間で公知のユニキャスト通信、マルチキャスト通信、Ｐ２Ｐ通信を実行してもよい。また、公知のデータ共有技術を使用してもよい。また、一方の装置がクラウドシステムへデータをアップロードし、他方の装置がクラウドシステムからデータをダウンロードすることで、情報通知およびデータ共有を実現してもよい。

（第１実施例の概要説明）
工場におけるロット管理の生産システムや建築現場における作業等、様々なプロジェクトは、複数のタスク（前提技術のステージに対応）の集合を、プロジェクトの開始から終了まで、半順序構造で順序づけたものとして把握される。実施例のプロジェクトは、製品・サービス・所産等の所定の成果物を創造するために実施される有期性の業務を意味する。また、前提技術のワークフローにしたがって所定の成果物を生産する活動とも言える。プロジェクトは、例えば、工場での一品生産を含み、工場でのロット単位あるいは製造番号単位で各タスクが実行される生産システムを含む。また、建築現場における内装工事のようなサービスプロセスを含み、躯体工事のような建設プロセスを含む。さらにまた、様々なサービスの提供プロセス等、多彩な活動を含む。

従来、プロジェクトにおけるタスクの遂行は人が中心となっており、また、タスクの遂行場所も限定されていた。しかし、ＩｏＴ時代には、タスクの遂行は人だけでなく、様々なハードウェア、ソフトウェア、およびそれらの協働により遂行されうる。さらにタスクの遂行場所も限定されない。このようなネットワーク上のタスクを含むプロジェクトの遂行と管理に関して、本発明者は以下の２つが要請されると考えた。

（１）プロジェクトを構成する個々のタスクが自律分散的にその活動を行うことを、プロジェクト全体として適切に管理することが必要になる。この管理は、例えば、機械の管理に用いられるシーケンス制御よりも自律分散的なものである必要がある。また、タスクの遂行状態を管理するためには、その遂行状態を見える化し、把握可能にすることが必要となる。とりわけ、個々のタスクの開始と終了を人間が管理するプロジェクトでは、各タスクの遂行状態を見える化し、把握可能にすることがきわめて重要である。

（２）個々のタスクの遂行中に生じる様々な情報をタスクと紐づけて管理することは、モノやサービスの生産プロジェクトにおける品質管理や、プロセスイノベーション、さらに生産したモノやサービスに問題が生じた場合のトレーサブルなプロセス管理に必須となる。センシング技術の向上により、工場や様々なサービス生産の現場で多くのデータがリアルタイムに把握できるようになっても、検出された様々なデータを個々のタスクに紐づけることができなければ、検出されたデータに基づいて、製品や仕掛品を改善することは難しい。また、生産プロセスのイノベーションを生み出すことも難しい。しかし、現状は、個々のタスクの遂行中に生じる様々な情報を、遂行中のタスクと紐づけて管理することが十分になされているとは言えない。

ここでプロジェクトの事例を説明する。図９は、モノを製造するプロジェクトの一例を示す。同図のプロジェクトでは、１）鉄板の切削加工タスク、２）銅板の切削加工タスク、３）切削された銅板と鉄板のプレスタスク、４）プレスされた板の塗装タスクが遂行される。鉄板切削加工タスクと、銅板切削加工タスクは、半順序の関係であり、並行して実行可能である。ただし、この事例では、１台の切削加工装置で、鉄板切削加工タスクと銅板切削加工タスクを順次実行し、すなわち鉄板切削加工タスクと銅板切削加工タスクを同時実行することはない。

図１０は、図９のプロジェクトにおけるスケジュールの一例を示す。同図では、図９のプロジェクトを識別子「Ｐ１」で表している。また、鉄板切削加工タスク（所要時間は２時間）を識別子「Ａ」、銅板切削加工タスク（所要時間は１時間）を識別子「Ｂ」、プレスタスク（所要時間は１時間）を識別子「Ｃ」、塗装タスク（所要時間は１時間）を識別子「Ｄ」で表している。このスケジュールでは、最初の２時間で鉄板切削加工タスクが遂行され（Ｐ１：Ａ）、以降１時間ごとに、銅板切削加工タスク（Ｐ１：Ｂ）、プレスタスク（Ｐ１：Ｃ）、塗装タスク（Ｐ１：Ｄ）の順に遂行されていき、開始から５時間後にプロジェクトが終了する。

ところで、現実のプロジェクトでは様々な理由で計画とのずれが生じる。例えば、工作機械（切削加工装置等）が故障等により停止することがある。また、機械や職人等の資源が他のプロジェクトへ優先的に割り当てられ、本プロジェクトのタスクの遂行が遅延することもある。そのため、タスクの開始と終了を把握可能にすることは生産管理においてきわめて重要である。

図１１も、図９のプロジェクトにおけるスケジュールの一例を示す。同図では、図９のプロジェクトが３回実行され、３つの成果物が生産される場合のスケジュールを示している。図１１（ａ）〜（ｃ）で示すように、切削加工装置１台、プレス装置１台、塗装装置１台の場合に３つのプロジェクト（それぞれのＩＤはＰ１、Ｐ２、Ｐ３）を遂行するには資源のスケジューリングが必要となり、また、タスクに対する資源割当基準の種類によって異なるスケジュールが導かれる。

図１１（ａ）は、「最長タスク優先スケジューリング」を適用したスケジュールを示している。図１１（ａ）では、同じ資源を使用する複数のタスクがあれば所要時間が相対的に長いタスクに優先的に資源を割り当てている。図１１（ｂ）は、「最短タスク優先スケジューリング」を適用したスケジュールを示している。図１１（ｂ）では、同じ資源を使用する複数のタスクがあれば所要時間が相対的に短いタスクに優先的に資源を割り当てている。図１１（ｃ）は、「ワークフロー順かつ最長タスク優先スケジューリング」を適用したスケジュールを示している。図１１（ｃ）では、可及的に多くのプロジェクトでタスクを実行することを優先し、その上で、同じ資源を使用する複数のタスクがあれば所要時間が相対的に長いタスクに優先的に資源を割り当てている。

図１２は、図１１（ａ）のスケジュールによるタスクの遂行過程を模式的に示す。同図では、３つのプロジェクト（Ｐ１、Ｐ２、Ｐ３）それぞれについて、１時間を１Ｔｉｃｋ（時間単位）として、上から下へ時系列にタスクの遂行過程を示している。また、完了したタスクを網掛けで示している。このような単純な事例においても各タスクの進行状況は複雑であるが、実際には１プロジェクトあたり数百のタスクが存在することがあり、また、数十から数百のプロジェクトが並行して稼働することがある。したがって、モノやサービスを生産する実際のプロジェクトにおいて、タスクの遂行プロセスを可視化して管理することは容易でなかった。

本実施例では、所定の成果物（サービス等の無体物を含む）を生産するためのプロジェクトを構成する複数のタスクについて、個々のタスク遂行時に発生した様々な情報を管理する情報処理装置（以下「管理装置」とも呼ぶ。）を提案する。実施例の管理装置は、プロジェクト管理装置とも言え、タスク遂行情報管理装置とも言える。実施例の管理装置は、ネットワーク上の人、モノ、ソフトウェアが混在しつつタスクが遂行される環境下で、各タスクの区切りを明確にしてタスク自体の見える化を実現する。同時に、プロジェクトにおけるタスク進行と、個々のタスク内部で得られる様々な計測情報とをＩｏＴを用いてタスク単位でパッキング（データ梱包）する。これにより、プロジェクトで生み出される部品・製品・サービスと各タスクとの紐付けを可能にする。

個々のタスクに紐付けられ管理されるべき情報は、当該タスクの担当者や担当機械のようなタスクで利用されるファブリケーション生産サービスに関する物的資本（生産機械）や人的資本（担当者や職工）に関する情報を含んでもよい。また、タスクで加工される物質や原料に関する情報、廃棄物や屑等の出力情報、サービスを提供される顧客の情報、生産管理のための機械の稼働情報、品質管理のための計測情報を含んでもよい。さらにまた、タスク遂行の現場でタスクに結びつけられる様々な情報を含んでもよく、例えば、タスクでの付加価値生産に関わる簿記データであり、実物簿記形式での生産の複式記述を含んでもよい。これらの情報を、個々のタスクにきちんと紐づけることで、後述するように様々な分析が可能となる。

今日、ビックデータ等、様々な形で計測されている多くのデータは、プロジェクト全体に紐づけられることはあっても、個々のタスクに紐づけられることはまれである。その背後には、タスクの数が数百から数万にも及ぶプロジェクトにおいて、各タスクに情報を紐付け管理する管理装置（タスク遂行情報管理装置）の不在がある。実施例で提案する管理装置は、この課題に答えることを１つの目的とする。

実施例の管理装置は、（１）ステージによるタスクの並列かつ順序づけられた実行の管理、（２）プロジェクトの遂行に関して得られる情報の、タスクを単位としたパッキング（データ梱包）とその管理、の２つの機能を実現する。このうち（１）の機能は、前提技術に記載のワークフロー管理装置により実現される。以下では（２）の機能を説明する。

複数のタスクで構成されるプロジェクトの遂行過程では、様々な情報がそれぞれのタスクに関連して得られ或は使用される。これらの情報は正しくそれに関連するタスクに紐づけられる必要がある。実施例では、個々のタスクに関連した情報は、それぞれのタスクの遂行に際して実空間上で得られ、得られた情報が管理装置において適切にデータ梱包される。これにより、プロジェクトを構成する各々のタスクの開始と終了をそれぞれのタスクの側で管理しつつ、管理装置側でもその情報を把握し、さらにタスク内部で計測されるタスクの遂行に関する諸データをタスク単位で収集し管理することができる。

既述したように、実施例では、プロジェクトの各タスクの情報として、タスク名情報、タスクの上で加工等の作業がなされるロット情報、タスクの開始情報、タスクの終了情報を一つのまとまったロットの作業・計測データのパッキング（以下「タスクデータ梱包」とも呼ぶ。）として認識するための枠組みを導入する。この枠組みを「タスクデータの梱包枠組」とも呼ぶ。

タスクデータの梱包枠組は、プロジェクトＩＤ（後述のプロジェクトインスタンスＩＤ）・タスクＩＤの組みにより識別される。プロジェクトＩＤは、ロット単位で生産活動が行われるプロジェクトであればロットＩＤでもよく、プロジェクトで最終的に生産される成果物のＩＤ（製造番号等）でもよく、プロジェクトが提供するサービスのＩＤでもよい。実施例では、同じプロジェクト（言い換えれば同じワークフロー）が実行される場合でも、タスクの遂行単位（タイミングやロット等）が異なれば、異なるプロジェクトＩＤ（後述のプロジェクトインスタンスＩＤ）を付与する。タスクＩＤは、プロジェクトを構成する複数のタスクのうち１つのタスクをユニークに識別可能なＩＤである。プロジェクトＩＤとタスクＩＤの組に対して、様々な計測データが紐づけられることにより、生産やサービスに関するデータをリアルタイムに見える化することができる。また後述するように、様々な計測データを、組織内および組織間での品質管理やカイゼンのための分析に用いることができる。

タスクデータの梱包枠組は、タスクの遂行が開始した日時と終了した日時に関する情報、当該タスクで必要とするファブリケーションサービスなどのサービスに用いられる物的資源（機械装置等）と人的資源（職工や担当者等）の情報を必須の情報として含む。これにより、タスクへの資源割当とタスクの遂行状態との見える化が可能となる。タスクの遂行に関して収集された諸情報は、タスクデータの梱包枠組によって、当該プロジェクトでのタスク遂行（例えば仕掛品の加工や何らかのサービスの提供）における担当者や、製品、仕掛品、サービスに関する諸情報を正しくタスクに紐づけて管理することが可能になる。

タスクデータの梱包枠組において各タスクに紐づけられ管理される情報は以下を含む。
１）タスクの開始と終了の時間情報。
２）タスク遂行のためのファブリケーションサービスなどのタスク機能の遂行サービスで用いられる機械装置（物的資源）や職工や担当者（人的資源）の割当情報。
３）機械装置を用いるタスクの場合、当該タスクでの加工に用いられた資源としての工作機械の作動状況。
４）タスクでの加工品の品質等に関する諸計測情報。
５）タスクでの生産に関する原価計算情報。
６）タスク遂行時の温度・湿度などの環境情報。
７）その他タスクの状態や状況を示す様々な情報。
なお、上記５）については、本発明者が提案した情報システムおよびエネルギー情報の記録装置（国際公開第２０１３／１６８４１９号）を参照。国際公開第２０１３／１６８４１９号の内容は参照により本明細書に組み込まれる。

以下、プロジェクトの雛形として、プロジェクトを構成する複数のタスクの順序関係を定めたデータを「プロジェクトタイプ」とも呼ぶ。また、特定のプロジェクトタイプにしたがってモノやサービスを生産するために、当該プロジェクトタイプに対して、物的資源（原料や部品、工作機械等）や人的資源を割り当てたものを「プロジェクトインスタンス」とも呼ぶ。プロジェクトタイプとプロジェクトインスタンスを区別しない場合、単に「プロジェクト」と呼ぶ。なお、後述のプロジェクトインスタンスＩＤは、１つのプロジェクトタイプに対して物的資源や人的資源を割り当てる生産計画システムが発行・採番してもよく、生産計画システムから製造現場および管理装置１２２へ通知されてもよい。

（第１実施例の詳細説明）
図１３は、第１実施例のプロジェクト管理システムの構成を示す。プロジェクト管理システム１２０は、管理装置１２２、メッセージブローカ１２３、状態通知装置１２６で総称される状態通知装置１２６ａ、状態通知装置１２６ｂ、状態通知装置１２６ｃ、バーコードリーダ１２８で総称されるバーコードリーダ１２８ａ、バーコードリーダ１２８ｂ、バーコードリーダ１２８ｃを備える。これらの装置は、ＬＡＮ・ＷＡＮ・インターネット等を含む通信網１２４を介して接続される。

管理装置１２２は、前提技術のワークフロー管理装置１２に対応する情報処理装置である。管理装置１２２は、プロジェクトと、そのプロジェクトを構成する複数のタスクに関する情報を管理する情報処理装置である。管理装置１２２の詳細は後述する。

メッセージブローカ１２３は、メッセージングサービスを提供し、クライアント装置間でのメッセージの交換を仲介する情報処理装置である。具体的には、メッセージブローカ１２３は、所定のプロトコル（例えばＭＱＴＴ（MQ Telemetry Transport）プロトコル）にしたがって、クライアント装置から送信（パブリッシュ）されたメッセージを受け付けて蓄積する。ここでメッセージにはトピック名が付与される。メッセージブローカ１２３は、トピック名を指定したサブスクライブ要求をクライアント装置から受け付ける。メッセージブローカ１２３は、サブスクライブ要求で指定されたトピック名が付与されたメッセージを要求元のクライアント装置へ送信する。

管理装置１２２と状態通知装置１２６は、メッセージブローカ１２３に対するクライアント装置として動作し、メッセージブローカ１２３を介してメッセージを送受する。例えば、状態通知装置１２６は、タスクに関するデータをメッセージブローカ１２３へパブリッシュし、管理装置１２２は、タスクに関するデータをメッセージブローカ１２３からサブスクライブする。

バーコードリーダ１２８は、タスクのＩＤ、タスクの対象となるロットのＩＤ、工作機械（言い替えればタスクへの投入資源）のＩＤを、タスクの遂行場所（例えば工場の製造ライン等）に予め設けられたバーコードから読み込む。これらのＩＤは、タスクごと、ロットごと、工作機械ごとに予め定められる。また、実施例のロットは、１つのプロジェクトの１つのタスクにおける作業単位であり、ロットのＩＤは、当該１つのタスクの成果物に付与されるロット番号であってもよい。

状態通知装置１２６は、タスク遂行時に生じた様々な情報であり、タスク遂行の状態、状況、環境等を示すデータ（以下「タスク状態データ」とも呼ぶ。）をメッセージブローカ１２３へ送信する。状態通知装置１２６は、バーコードリーダ１２８と接続される装置（ＰＣ等）を含む。この装置は、バーコードリーダ１２８で読み取られたデータ（例えばタスクＩＤ、ロットＩＤ、工作機械ＩＤ等）を含むメッセージをメッセージブローカ１２３へ送信する。

また、状態通知装置１２６は、タスクの開始時に押すべき開始ボタンと、タスクの終了時に押すべき終了ボタンとを備える開始・終了通知装置を含む。開始・終了通知装置は、開始ボタンが押下された場合に、タスクの開始を示すメッセージ（例えばタスクの開始日時を示すメッセージ）をメッセージブローカ１２３へ送信する。その一方、終了ボタンが押下された場合に、タスクの終了を示すメッセージ（例えばタスクの終了日時を示すメッセージ）をメッセージブローカ１２３へ送信する。

また、状態通知装置１２６は、タスクが遂行される環境（温度・湿度等）、機器（工作機械）の状態や、タスクの成果物の状態（塗装むら等）を検知する様々な計測機器（センサ等）を含む。計測機器は、検知した環境、機器、成果物の状態を示すメッセージをメッセージブローカ１２３へ送信する。また、状態通知装置１２６は、タスクの遂行に関与すべき作業者により操作されるＰＣ、スマートフォン、タブレット端末を含む。例えばＰＣは、作業者から入力された操作に対応するメッセージや、作業者により入力されたデータを含むメッセージをメッセージブローカ１２３へ送信する。

状態通知装置１２６ａとバーコードリーダ１２８ｂは、１つのプロジェクトの第１のタスクを遂行する側の装置（例えば図９の鉄板切削加工タスクおよび銅板切削加工タスクの遂行に関連する装置）である。状態通知装置１２６ｂとバーコードリーダ１２８ｂは、上記１つのプロジェクトの第２のタスクを遂行する側の装置（例えば図９のプレスタスクの遂行に関連する装置）である。状態通知装置１２６ｃ、バーコードリーダ１２８ｃは、上記１つのプロジェクトの第３のタスクを遂行する側の装置（例えば図９の塗装タスクの遂行に関連する装置）である。なお、タスク・ロット・工作機械のＩＤをバーコードから読み取ることは一例であり、公知の方法により、タスク・ロット・工作機械のＩＤが状態通知装置１２６から管理装置１２２へ通知されてよい。

図１４は、図１３の管理装置１２２の機能構成を示すブロック図である。管理装置１２２は、制御部１３０、記憶部１３２、通信部１３４を備える。制御部１３０、記憶部１３２、通信部１３４は、前提技術におけるワークフロー管理装置１２の制御部７０、データ記憶部８０、通信部６０に対応する。図１４には不図示だが、制御部１３０は、図６に記載した制御部７０内の機能を含んでよく、記憶部１３２は、図６に記載したデータ記憶部８０内の機能を含んでよい。すなわち、第１実施例の管理装置１２２は、前提技術のワークフロー管理装置１２の機能を含んでもよい。

記憶部１３２は、タスク順序記憶部１３６とタスクデータ記憶部１３８を含む。タスク順序記憶部１３６は、前提技術のワークフロー情報保持部８２に対応し、プロジェクトタイプを構成する複数のタスクの遂行順序を保持する。図１５は、複数のタスクの遂行順序を定めたデータの例を示す。同図は、図９のプロジェクト事例におけるタスクの実行順序を示しており、言わばワークフローを示している。タスク順序記憶部１３６は、プロジェクトを構成する複数のタスク間の順序関係（全順序関係または半順序関係）を定めたデータを保持してもよい。なお、タスク順序記憶部１３６は、複数種類のプロジェクトタイプ（言い換えればワークフロー）を保持してもよい。例えば、製品Ａの製造工程を定めた第１のプロジェクトタイプ（すなわち複数のタスクの遂行順序）と、製品Ｂの製造工程を定めた第２のプロジェクトタイプを保持してもよい。

図１４に戻り、タスクデータ記憶部１３８は、既述した梱包枠組が適用されるデータであり、プロジェクトインスタンスが遂行される中で、そのプロジェクトインスタンスを構成する複数のタスクそれぞれの遂行に際して得られたデータをタスク単位にまとめたタスクデータを保持する。図１６はタスクデータの例を示す。タスクデータは、タスクＩＤとプロジェクトインスタンスＩＤの組をキーとし、タスクの開始日時および終了日時、投入資源のデータ、工作機械の状態を示すデータ、センサ等による計測値や環境の状態を示すデータを含む。詳細は後述するが、１つのタスクデータの複数の情報項目は、１つのタスクの遂行中の異なる時点で生成され、１つのタスクデータに順次記録される。

図１４に戻り、制御部１３０は、タスク遂行状況取得部１４０、タスクデータ更新部１４２、タスクデータ出力部１４４を含む。タスク遂行状況取得部１４０は、プロジェクトを構成する複数のタスクのうち１つのタスクの遂行に関連する外部機器から送信された、１つのタスクの開始を示すデータを取得するとともに、１つのタスクの終了を示すデータを取得する。

例えば、図９の鉄板切削加工タスクに関連する状態通知装置１２６（ここでは開始・終了通知装置とする）において開始ボタンが押された場合、状態通知装置１２６ａは、鉄板切削加工タスクの開始日時を示すメッセージをメッセージブローカ１２３へパブリッシュする。タスク遂行状況取得部１４０は、上記開始日時を示すメッセージのトピック名を指定した購読要求を予めメッセージブローカ１２３に登録しておき、上記開始日時を示すメッセージをメッセージブローカ１２３からサブスクライブする。

また、タスク遂行状況取得部１４０は、プロジェクトを構成する複数のタスクのうち１つのタスクの遂行に関連する外部機器から送信された、１つのタスク遂行における状態や状況に関するタスク状態データを取得する。例えば、図９の鉄板切削加工タスクに関連する状態通知装置１２６（ここではセンサとする）は、自機で検出した周囲の温度を示すメッセージをタスク状態データとしてメッセージブローカ１２３へパブリッシュする。タスク遂行状況取得部１４０は、上記温度を示すメッセージのトピック名を指定した購読要求を予めメッセージブローカ１２３に登録しておき、タスク状態データをメッセージブローカ１２３からサブスクライブする。

タスクデータ更新部１４２は、１つのタスクの開始を示すデータが取得された場合、当該タスクに関するタスクデータに開始時刻を記録し、１つのタスクの終了を示すデータが取得された場合、当該タスクに関するタスクデータに終了時刻を記録する。また、タスクデータ更新部１４２は、１つのタスクの開始を示すデータが取得された後、当該タスクの終了を示すデータが取得される前に、当該タスクの遂行に関するタスク状態データが取得された場合、当該タスクに関するタスクデータにタスク状態データを記録する。

実施例では、タスクの開始を示すデータ、タスクの終了を示すデータ、タスク状態データ（以下、これらを総称して「通知データ」とも呼ぶ。）のいずれにも、プロジェクトインスタンスＩＤとタスクＩＤの組が設定される。既述したように、プロジェクトインスタンスＩＤは、タスクの対象を示す識別子である。例えばタスクの成果物の識別子であってもよく、製造番号であってもよく、ロット番号（ロットＩＤ）であってもよい。タスクデータ更新部１４２は、タスク単位（言い換えればタスクＩＤ単位）かつタスクの対象単位（言い換えればプロジェクトインスタンスＩＤ単位）にタスクデータを設定し、タスク単位かつタスクの対象単位のタスクデータに、開始時刻、終了時刻、タスク状態データを順次記録する。

具体的には、タスクデータ更新部１４２は、通知データがサブスクライブされた場合に、その通知データに設定されたプロジェクトインスタンスＩＤとタスクＩＤの組に基づいて、タスクデータ記憶部１３８に保持された複数のタスクデータの中から更新対象のタスクデータを識別する。通知データに設定されたプロジェクトインスタンスＩＤとタスクＩＤの組を有するタスクデータが存在しない場合、タスクデータ更新部１４２は、通知データに設定されたプロジェクトインスタンスＩＤとタスクＩＤの組をキーとする新たなタスクデータをタスクデータ記憶部１３８に格納する。

タスクデータ更新部１４２は、１つのタスクのＩＤが登録後（すなわちタスクデータの生成後）、当該タスクの開始を示すデータが取得される前に、プロジェクトインスタンスＩＤおよびタスクＩＤが一致する当該タスクのタスク状態データが取得された場合、当該タスクのタスクデータにタスク状態データを追加することを抑制してもよい。また、タスクデータ更新部１４２は、１つのタスクの終了を示すデータが取得された後、言い換えれば、１つのタスクの終了時刻を記録後に、プロジェクトインスタンスＩＤおよびタスクＩＤが一致する当該タスクのタスク状態データが取得された場合、当該タスクのタスクデータに、タスク状態データを追加することを抑制してもよい。これにより、タスク遂行に直接関係がないタスク状態データをタスクデータから除外し、後の分析の正確度を高めることができる。

タスクデータ出力部１４４は、タスクデータの閲覧要求を受け付けた場合に、タスクデータ記憶部１３８に格納された複数のタスクデータのうち閲覧要求で指定された条件に合致するタスクデータを抽出し、閲覧要求元の装置（不図示のＰＣ等）へ送信する。タスクデータの閲覧要求では、タスクデータの抽出条件として、１つ以上のタスクＩＤ、１つ以上のプロジェクトインスタンスＩＤ（ロットＩＤ等）、工作機械のＩＤ（言い換えれば投入資源の識別子）のうち少なくとも１つが指定されてもよい。例えば、タスクデータの抽出条件として１つのタスクＩＤが指定された場合、タスクデータ出力部１４４は、指定されたタスクＩＤを含むタスクデータであり、プロジェクトインスタンスＩＤが異なる複数のタスクデータを抽出してもよい。

また、タスクデータ出力部１４４は、タスクデータの閲覧要求に応じて特定のタスクデータ（ここでは「第１タスクデータ」と呼ぶ。）を抽出した場合に、タスク順序記憶部１３６に保持されたプロジェクトタイプにおける複数のタスクの実行順序を参照して、第１タスクデータの前のタスクデータ（ここでは「第２タスクデータ」と呼ぶ。）、および／または、後のタスク（ここでは「第３タスクデータ」と呼ぶ。）をさらに抽出してもよい。タスクデータ出力部１４４は、第１タスクデータに加えて、第２タスクデータおよび／または第３タスクデータを閲覧要求元の装置へ送信してもよい。さらにタスクデータ出力部１４４は、第１タスクデータ、第２タスクデータ、第３タスクデータの順序関係（言い換えれば前後関係）を示す態様で、これらのタスクデータを並べた画面データを閲覧要求元の装置へ送信して表示させてもよい。

さらにまた、タスクデータ出力部１４４は、プロジェクトインスタンスの進捗状況を示すプロジェクトインスタンスリストの閲覧要求を外部装置から受け付けてもよい。タスクデータ出力部１４４は、タスクデータ記憶部１３８に記憶された複数のタスクデータを、プロジェクトインスタンスＩＤ単位に集計してもよい。そして、複数のプロジェクトインスタンスそれぞれの進捗状況をプロジェクトインスタンスリストの各レコードに設定して、プロジェクトインスタンスリストのデータを閲覧要求元の装置へ送信してもよい。ここで、プロジェクトインスタンスの進捗状況は、例えば、未開始のタスク（開始時刻が未記録のタスク）、遂行中のタスク（開始時刻が記録済、終了時刻が未記録のタスク）、終了済のタスク（終了時刻が記録済のタスク）を区別可能に示すものであってもよい。これにより、各プロジェクトインスタンスの進捗状況の見える化を実現できる。

この場合、管理装置１２２は、プロジェクトインスタンスＩＤの発行主体である生産計画システム等から通知されたプロジェクトインスタンスＩＤと、プロジェクトタイプとの対応関係を予め保持してもよい。また、プロジェクトインスタンスＩＤをキーとして生産計画システム等から対応するプロジェクトタイプの情報を取得してもよい。タスクデータ出力部１４４は、プロジェクトインスタンスＩＤに対応するプロジェクトタイプが定める複数のタスクの順序情報をタスク順序記憶部１３６から取得してもよい。そして、プロジェクトインスタンスを構成する複数のタスクをプロジェクトタイプが定める順序に整列させたデータであり、未開始のタスク、遂行中のタスク、終了済のタスクを異なる態様に設定したデータ（例えば図１５のワークフローを示すＧＵＩデータ）をプロジェクトインスタンスリストに設定してもよい。

以上の構成によるプロジェクト管理システム１２０の動作を説明する。ここでは、図９で示した事例に基づいて、物作りの工程を構成する複数のタスクの開始と終了を正しく識別し、各タスクに対して、各タスクで加工される生産ロットと、加工機械の稼働状況を紐付ける例を示す。

図１７は、プロジェクトの遂行過程を模式的に示す。ここでは、鉄板切削加工タスクと銅板切削加工タスクを同一の切削加工装置（Ｃｕｔｔｉｎｇ Ｍ１）が遂行し、鉄板切削加工タスク、銅板切削加工タスク、プレスタスク、塗装タスクの順にプロジェクトが進行する。本事例では、４つのタスクに亘る共通のプロジェクトインスタンスＩＤとしてロットＩＤ（ｌｏｔ Ｐ１）が使用される。なお、プロジェクトインスタンスＩＤは、実際のプロジェクト（工場や生産現場等）におけるＩＤの体系に応じて定められてよく、例えば、各タスクの成果物が異なるロット番号で管理される場合、ロット番号とは異なるプロジェクトインスタンスＩＤが使用されてもよい。

まず、鉄板切削加工タスクの作業者は、工作機械バーコード（Ｃｕｔｔｉｎｇ Ｍ１）、ロットバーコード（ｌｏｔ Ｐ１）、タスクバーコード（Ｓｔｅｅｌ Ｃｕｔｔｉｎｇ）をバーコードリーダ１２８ａに読み取らせる。バーコードリーダ１２８ａと接続された状態通知装置１２６ａは、バーコードリーダ１２８ａで読み取られた工作機械・ロット・タスクのＩＤを示すタスク識別メッセージをメッセージブローカ１２３へパブリッシュする。管理装置１２２は、メッセージブローカ１２３からタスク識別メッセージをサブスクライブし、工作機械・ロット・タスクのＩＤを含むタスクデータ１５０をタスクデータ記憶部１３８に新たに格納する。

鉄板切削加工タスクの作業者は、工作機械（Ｃｕｔｔｉｎｇ Ｍ１）による鉄板切削加工を始める際に、状態通知装置１２６ａの開始ボタン（Ｓ）を押下する。状態通知装置１２６ａは、ロット・タスクのＩＤに加えて、鉄板切削加工タスクの開始時刻（典型的には現在時刻）を示すタスク開始メッセージをメッセージブローカ１２３へパブリッシュする。管理装置１２２は、メッセージブローカ１２３からタスク開始メッセージをサブスクライブし、ロット・タスクのＩＤにより識別されるタスクデータ１５０に鉄板切削加工タスクの開始時刻を記録する。

本事例の状態通知装置１２６ａには、工作機械の状態や環境の状態を検知する１つ以上の計測機器（センサ等）が含まれる。状態通知装置１２６ａとしての各計測機器は、工作機械（Ｃｕｔｔｉｎｇ Ｍ１）の動作状態、切削むらの状態、温度・湿度等をタスク状態データとして検出する。状態通知装置１２６ａとしての各計測機器は、ロット・タスクのＩＤに加えて、タスク状態データを含むタスク状態メッセージをメッセージブローカ１２３へ自律的にパブリッシュする。管理装置１２２は、メッセージブローカ１２３からタスク状態メッセージをサブスクライブし、ロット・タスクのＩＤにより識別されるタスクデータ１５０にタスク状態データ（タスクデータ１５０のＭ１稼働データ、切削むら計測データ、温度・湿度・環境情報）を記録する。

鉄板切削加工タスクの作業者は、工作機械（Ｃｕｔｔｉｎｇ Ｍ１）による鉄板切削加工が終了すると、状態通知装置１２６ａの終了ボタン（Ｅ）を押下する。状態通知装置１２６ａは、ロット・タスクのＩＤに加えて、鉄板切削加工タスクの終了時刻（典型的には現在時刻）を示すタスク終了メッセージをメッセージブローカ１２３へパブリッシュする。管理装置１２２は、メッセージブローカ１２３からタスク終了メッセージをサブスクライブし、ロット・タスクのＩＤにより識別されるタスクデータ１５０に鉄板切削加工タスクの終了時刻を記録する。

続いて、銅板切削加工タスクの作業者は、工作機械バーコード（Ｃｕｔｔｉｎｇ Ｍ１）、ロットバーコード（ｌｏｔ Ｐ１）、タスクバーコード（Ｃｏｐｐｅｒ Ｃｕｔｔｉｎｇ）をバーコードリーダ１２８ａに読み取らせる。バーコードリーダ１２８ａと接続された状態通知装置１２６ａは、バーコードリーダ１２８ａで読み取られた工作機械・ロット・タスクのＩＤを示すタスク識別メッセージをメッセージブローカ１２３へパブリッシュする。管理装置１２２は、メッセージブローカ１２３からタスク識別メッセージをサブスクライブし、工作機械・ロット・タスクのＩＤを含むタスクデータ１５２をタスクデータ記憶部１３８に新たに格納する。

銅板切削加工タスクの作業者は、工作機械（Ｃｕｔｔｉｎｇ Ｍ１）による銅板切削加工を始める際に、状態通知装置１２６ａの開始ボタン（Ｓ）を押下する。状態通知装置１２６ａは、ロット・タスクのＩＤに加えて、銅板切削加工タスクの開始時刻を示すタスク開始メッセージをメッセージブローカ１２３へパブリッシュする。管理装置１２２は、メッセージブローカ１２３からタスク開始メッセージをサブスクライブし、ロット・タスクのＩＤにより識別されるタスクデータ１５２に銅板切削加工タスクの開始時刻を記録する。

鉄板切削加工タスクの遂行時と同様に、状態通知装置１２６ａとしての１つ以上の計測機器は、工作機械（Ｃｕｔｔｉｎｇ Ｍ１）の動作状態、切削むらの状態、温度・湿度等をタスク状態データとして検出する。状態通知装置１２６ａとしての各計測機器は、ロット・タスクのＩＤに加えて、タスク状態データを含むタスク状態メッセージをメッセージブローカ１２３へ自律的にパブリッシュする。管理装置１２２は、メッセージブローカ１２３からタスク状態メッセージをサブスクライブし、ロット・タスクのＩＤにより識別されるタスクデータ１５２にタスク状態データ（タスクデータ１５２のＭ１稼働データ、切削むら計測データ、温度・湿度・環境情報）を記録する。

銅板切削加工タスクの作業者は、工作機械（Ｃｕｔｔｉｎｇ Ｍ１）による銅板切削加工が終了すると、状態通知装置１２６ａの終了ボタン（Ｅ）を押下する。状態通知装置１２６ａは、ロット・タスクのＩＤに加えて、銅板切削加工タスクの終了時刻を示すタスク終了メッセージをメッセージブローカ１２３へパブリッシュする。管理装置１２２は、メッセージブローカ１２３からタスク終了メッセージをサブスクライブし、ロット・タスクのＩＤにより識別されるタスクデータ１５２に銅板切削加工タスクの終了時刻を記録する。

続いて、プレスタスクの作業者は、工作機械バーコード（Ｐｒｅｓｓ Ｍ）、ロットバーコード（ｌｏｔ Ｐ１）、タスクバーコード（Ｐｒｅｓｓｉｎｇ）をバーコードリーダ１２８ｂに読み取らせる。バーコードリーダ１２８ｂと接続された状態通知装置１２６ｂは、バーコードリーダ１２８ｂで読み取られた工作機械・ロット・タスクのＩＤを示すタスク識別メッセージをメッセージブローカ１２３へパブリッシュする。管理装置１２２は、メッセージブローカ１２３からタスク識別メッセージをサブスクライブし、工作機械・ロット・タスクのＩＤを含むタスクデータ１５４をタスクデータ記憶部１３８に新たに格納する。

プレスタスクの作業者は、工作機械（Ｐｒｅｓｓ Ｍ）によるプレス加工を始める際に、状態通知装置１２６ｂの開始ボタン（Ｓ）を押下する。状態通知装置１２６ｂは、ロット・タスクのＩＤに加えて、プレスタスクの開始時刻を示すタスク開始メッセージをメッセージブローカ１２３へパブリッシュする。管理装置１２２は、メッセージブローカ１２３からタスク開始メッセージをサブスクライブし、ロット・タスクのＩＤにより識別されるタスクデータ１５４にプレスタスクの開始時刻を記録する。

本事例の状態通知装置１２６ｂには、工作機械の状態や環境の状態を検知する１つ以上の計測機器（センサ等）が含まれる。状態通知装置１２６ｂとしての各計測機器は、工作機械（Ｐｒｅｓｓ Ｍ）の動作状態、プレスむらの状態、温度・湿度等をタスク状態データとして検出する。状態通知装置１２６ｂとしての各計測機器は、ロット・タスクのＩＤに加えて、タスク状態データを含むタスク状態メッセージをメッセージブローカ１２３へ自律的にパブリッシュする。管理装置１２２は、メッセージブローカ１２３からタスク状態メッセージをサブスクライブし、ロット・タスクのＩＤにより識別されるタスクデータ１５４にタスク状態データ（タスクデータ１５４のプレス機械稼働データ、プレスむら計測データ、温度・湿度・環境情報）を記録する。

プレスタスクの作業者は、工作機械（Ｐｒｅｓｓ Ｍ）によるプレス加工が終了すると、状態通知装置１２６ｂの終了ボタン（Ｅ）を押下する。状態通知装置１２６ｂは、ロット・タスクのＩＤに加えて、プレスタスクの終了時刻を示すタスク終了メッセージをメッセージブローカ１２３へパブリッシュする。管理装置１２２は、メッセージブローカ１２３からタスク終了メッセージをサブスクライブし、ロット・タスクのＩＤにより識別されるタスクデータ１５４にプレスタスクの終了時刻を記録する。

続いて、塗装タスクの作業者は、工作機械バーコード（Ｐａｉｎｔｅｒ Ａ）、ロットバーコード（ｌｏｔ Ｐ１）、タスクバーコード（Ｐａｉｎｔｉｎｇ）をバーコードリーダ１２８ｃに読み取らせる。バーコードリーダ１２８ｃと接続された状態通知装置１２６ｃは、バーコードリーダ１２８ｃで読み取られた工作機械・ロット・タスクのＩＤを示すタスク識別メッセージをメッセージブローカ１２３へパブリッシュする。管理装置１２２は、メッセージブローカ１２３からタスク識別メッセージをサブスクライブし、工作機械・ロット・タスクのＩＤを含むタスクデータ１５６をタスクデータ記憶部１３８に新たに格納する。

塗装タスクの作業者は、工作機械（Ｐａｉｎｔｅｒ Ａ）による塗装処理を始める際に、状態通知装置１２６ｃの開始ボタン（Ｓ）を押下する。状態通知装置１２６ｃは、ロット・タスクのＩＤに加えて、塗装タスクの開始時刻を示すタスク開始メッセージをメッセージブローカ１２３へパブリッシュする。管理装置１２２は、メッセージブローカ１２３からタスク開始メッセージをサブスクライブし、ロット・タスクのＩＤにより識別されるタスクデータ１５６に塗装タスクの開始時刻を記録する。

本事例の状態通知装置１２６ｃには、工作機械の状態や環境の状態を検知する１つ以上の計測機器（センサ等）が含まれる。状態通知装置１２６ｃとしての各計測機器は、工作機械（Ｐａｉｎｔｅｒ Ａ）の動作状態、ペイントむらの状態、温度・湿度等をタスク状態データとして検出する。状態通知装置１２６ｃとしての各計測機器は、ロット・タスクのＩＤに加えて、タスク状態データを含むタスク状態メッセージをメッセージブローカ１２３へ自律的にパブリッシュする。管理装置１２２は、メッセージブローカ１２３からタスク状態メッセージをサブスクライブし、ロット・タスクのＩＤにより識別されるタスクデータ１５６にタスク状態データ（タスクデータ１５６の塗装むら計測データ、温度・湿度・環境情報）を記録する。

塗装タスクの作業者は、工作機械（Ｐａｉｎｔｅｒ Ａ）による塗装処理が終了すると、状態通知装置１２６ｃの終了ボタン（Ｅ）を押下する。状態通知装置１２６ｃは、ロット・タスクのＩＤに加えて、塗装タスクの終了時刻を示すタスク終了メッセージをメッセージブローカ１２３へパブリッシュする。管理装置１２２は、メッセージブローカ１２３からタスク終了メッセージをサブスクライブし、ロット・タスクのＩＤにより識別されるタスクデータ１５６に塗装タスクの終了時刻を記録する。

図１７の事例では、タスクの開始と終了を人が状態通知装置１２６ａへ入力したが、タスクの開始と終了が自動で検出されてもよい。具体的には、工作機械がタスクの処理を開始する際に（例えばＣｕｔｔｉｎｇ Ｍ１が切削加工処理の開始指示を受け付けた際に）、当該工作機械もしくは工作機械に接続された状態通知装置１２６ａが、タスク開始メッセージを自律的にメッセージブローカ１２３へパブリッシュしてもよい。同様に、工作機械がタスクの処理を完了した際に、当該工作機械もしくは工作機械に接続された状態通知装置１２６が、タスク終了メッセージを自律的にメッセージブローカ１２３へパブリッシュしてもよい。

タスクデータ１５０、タスクデータ１５２、タスクデータ１５４、タスクデータ１５６に示すように、図１７の事例では、Ｐ１というプロジェクトインスタンスＩＤ（例えばロットＩＤ）と、「Ｓｔｅｅｌ Ｃｕｔｔｉｎｇ」等のタスクＩＤの組がタスクデータの梱包枠組となり、この梱包枠組に対して、生産機械や職工等の物的・人的資源の情報、タスクの作業開始時刻、作業終了時刻等、様々なデータが紐付けて記録される。

各タスクデータにおいて必須かつ基本となる項目は、タスクの進行に必要な資源情報（例えば工作機械の識別子）と、タスクの開始日時と終了日時の情報である。これらの情報は、計画時点で想定されているとしても、実際には様々な要因でずれが生じる。これらの情報を記録することで、ロット毎（もしくはプロジェクトインスタンス毎）のタスクの進行状況や資源の割り当て情報を正確に把握することができる。

また、図１０にも関連するが、図１７の事例では、鉄板切削加工タスクが、２時間で完了予定のところ２時間３０分かかっている。実施例の管理装置１２２では、ロット単位（プロジェクトインスタンス単位）かつタスク単位でタスク遂行情報をまとめて蓄積するため、例えば図１７で示すように、計画装置（不図示）で作成された計画データとタスクデータとを比較することも容易になる。

管理装置１２２においてタスク毎にパックしたタスクデータはさらに、（１）複数のプロジェクトインスタンスにおけるタスク単位のデータ解析、（２）複数のプロジェクトインスタンスにおける資源単位でのデータ解析、（３）プロジェクトインスタンス単位のサプライチェーンにおけるデータ利用、を支援することができる。以下具体的に説明する。

（１）複数のプロジェクトインスタンスにおけるタスク単位のデータ解析：
同じプロジェクトタイプに基づくプロジェクトインスタンスで記録されたタスクデータであり、例えば、同じモノまたはサービスの生産に関するタスクデータをプロジェクトインスタンスを横断して収集することで、モノやサービスの改善につながる知見を様々に収集できる。例えば図１７の事例では、タスクＩＤ「Ｐａｉｎｔｉｎｇ」をキーとしてタスクデータを抽出することにより、プロジェクトインスタンス横断的に塗装工程の色むらを解析できる。また例えば、１００個のプロジェクトインスタンスの塗装タスクを比較し、色むらの大きなタスクを特定し、その原因が、温度であること或は特定の塗装工の仕事であること等の原因分析が可能になる。同様に切削工程のむらや、プレス工程のむら等についても、複数のプロジェクトインスタンスを横断して他の測定データとの比較を行うことで原因の解析が可能となる。

（２）複数のプロジェクトインスタンスにおける資源単位でのデータ解析：
切削加工装置やプレス装置等の機械装置の資源や、塗装工等の人的資源に関して、それらに関連したデータを横断的に解析することもまた、プロセスイノベーションやタスクの改善の為に重要である。例えば、着目した切削加工装置、プレス装置、あるいは塗装工に関する諸データをプロジェクトインスタンス横断的またはタスク横断的に分析し、他の装置や他の塗装工の仕事（品質等）と比較することで、資源固有の問題や改善点を見いだすことが可能となる。

（３）プロジェクトインスタンス単位のサプライチェーンにおけるデータ利用：
製造工程やサービス工程に関する様々なデータはサプライチェーンの中で管理され、製品やサービスに問題が発見された際には、複数の組織に跨がるサプライチェーンのデータを遡って（トレースバックして）問題がどこで生じたかを見いだすこと、言い換えれば、トレーサビリティを確保することが今後ますます重要となる。

ところで、サプライチェーンは、あるプロジェクトで製造された半製品（部品）が、次のステップの製造過程において投入原料として用いられるという形で接続される。このサプライチェーンを、最終製品を起点としてトレースバックしていき、最終製品の部品や、部品の部品、さらには部品の原料、部品の製造工程のデータを知る事は、最終製品に異常が生じた時の品質改善や原因の特定に必須となる。また、そのために、部品製造のプロジェクト情報を梱包したもの（すなわちタスクデータ）を単に保存するだけでなく、それが改竄されていない事の保証もまた必要となる。

このような改竄がなされないことを保証するシステムとして従来はトップダウンの巨大な管理システムが構築されることが多かった。しかし、実施例の管理装置１２２で生成されるタスクデータを、改竄不可能にし、かつ、製品からトレースバックすることのできるトレーサビリティのあるデータとして組織の壁を越え利活用するためには、近年着目されているブロックチェーン技術が好適である。なお、改竄不可能とは、仮にタスクデータが改竄された場合にその事実を検出可能という意味である。

具体的には、各タスクについて生成されたタスクデータに対して次のステップにてブロックチェーンを生成してもよい。
ステップ１）当該の企業で生成したプロジェクトインスタンス単位の梱包データを圧縮暗号化する。プロジェクトインスタンス単位の梱包データ（以下「プロジェクトデータ」とも呼ぶ。）は、タスクデータ記憶部１３８に記憶された複数のタスクデータの中から特定のプロジェクト（例えば当該企業が他企業へ出荷する部品のうち特定の１個の製造プロジェクトインスタンス）に紐付く複数のタスクデータをプロジェクトインスタンスＩＤまたはロットＩＤをキーとして抽出したものであってもよい。なお、暗号化は例えば公開鍵暗号を用いれば多量のプロジェクトに対しても簡単に暗号圧縮ができる。

ステップ２）暗号圧縮化したプロジェクトデータのハッシュ値を計算する。
ステップ３）サプライチェーンの次のステップの他企業（言い換えれば部品出荷先の他企業）に対して、部品とともに、２）で算出した当該部品のハッシュ値を渡す。すなわち、出荷対象の部品毎に、部品固有のプロジェクトデータを圧縮暗号化し、ハッシュ値を求め、そのハッシュ値を部品とともにサプライチェーンの次のステップに渡す。
ステップ４）サプライチェーンの次のステップの企業は、当該企業におけるプロジェクトインスタンス単位の梱包データ（すなわちプロジェクトデータ）を圧縮暗号化する際に、３）で渡された部品のハッシュ値を一緒に梱包して圧縮暗号化する。これにより、サプライチェーンの前工程で製造された部品のハッシュ値が一緒に保存される。以下、サプライチェーンが終了するまで、２）〜４）を繰り返す。これにより、サプライチェーンの前工程で製造された部品のハッシュ値が、後工程で製造された部品のハッシュ値に組み込まれる。

仮にサプライチェーンの最終製品に異常があり、サプライチェーンを遡って部品等のデータ（例えばタスクデータ等）を検証する必要が生じた場合、当該部品の圧縮梱包データ（すなわち圧縮暗号化されたプロジェクトデータ）の提供を受け、そのハッシュ値を計算し、それが過去受け渡されたハッシュ値と一致することを検証することにより、プロジェクトデータが改竄されていないことを確認できる。その上で、契約に基づいて、暗号と圧縮を解除することで改竄されていない事が保証されたデータ（すなわち平文のプロジェクトデータ）を入手できる。このように、実施例のデータ梱包技術とブロックチェーン技術とを組み合わせることで、サプライチェーンに関わる複数の企業が各々分散してデータを保管しつつも、サプライチェーン全域に渡りトレーサビリティを確保することができる。

既述したように、管理装置１２２は、プロジェクトインスタンスＩＤの発行主体である生産計画システム等から通知されたプロジェクトインスタンスＩＤと、プロジェクトタイプとの対応関係を予め保持してもよい。また、プロジェクトインスタンスＩＤをキーとして生産計画システム等から対応するプロジェクトタイプの情報を取得してもよい。これにより、プロジェクトインスタンスの成果物である製品に不具合があった場合に、当該プロジェクトインスタンスのＩＤに紐付けられたタスクデータを確認することに加えて、当該プロジェクトインスタンスと同じプロジェクトタイプに基づく他のプロジェクトインスタンスのタスクデータを確認することができる。例えば、同じプロジェクトタイプに基づく複数のプロジェクトインスタンスに亘って、特定のタスクＩＤのデータが工作機械の異常を示す場合、その特定のタスク（工作機械）が製品不具合の原因であると推定できる。

なお、管理装置１２２のタスクデータ出力部１４４は、特定のプロジェクトインスタンスＩＤを指定する検索要求を受け付けると、そのプロジェクトインスタンスＩＤに対応付けられたタスクデータを横軸方向に並べ、当該プロジェクトインスタンスと同じプロジェクトタイプに基づく他のプロジェクトインスタンスを縦軸方向に並べた２次元の表情報を検索結果として要求元の装置へ送信してもよい。この表情報では、同じプロジェクトタイプに基づく複数のプロジェクトインスタンスにおける同一タスクの情報が縦一列に並び、プロジェクトインスタンス横断的な比較や確認を支援できる。

以上、本発明を第１実施例をもとに説明した。この実施例は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。以下変形例を挙げる。

第１変形例を説明する。バーコードリーダ１２８は、タスクの遂行（部品製造等）において投入される資源（例えば原料、部品等）に付与されたＩＤ（ロットＩＤ等）を所定のバーコードから読み取ってもよく、状態通知装置１２６は、投入資源のＩＤを管理装置１２２へ通知してもよい。管理装置１２２は、タスクにおける投入資源のＩＤを当該タスクのタスクデータに記録してもよい。或るタスクのタスクデータに記録される投入資源のＩＤは、典型的には、より以前に実行されたタスクであり、すなわち投入資源の製造タスクにおけるプロジェクトＩＤ（プロジェクトインスタンスＩＤとも言える）に相当する。この態様によると、プロジェクトインスタンスの成果物である製品等で異常が発生した場合に、プロジェクトインスタンスのタスクフローを遡って各タスクのタスクデータを確認することが容易になり、トレーサビリティを確保しやすくなる。

第２変形例を説明する。上記実施例では、状態通知装置１２６がメッセージブローカ１２３へパブリッシュするメッセージ（通知データ）に、プロジェクトインスタンスＩＤとタスクＩＤが設定されることとした。変形例として、温度・湿度等の環境状態を示すメッセージでは、タスクＩＤが指定される一方、プロジェクトインスタンスＩＤが未指定であってもよい。ここでタスクＩＤは、状態通知装置１２６（工作機械やセンサ等を含む）の種類、設置場所等に基づいて予め決定されておけばよい。

管理装置１２２のタスクデータ更新部１４２は、プロジェクトインスタンスＩＤが未指定のメッセージが取得された場合、そのメッセージが示すタスクＩＤが設定されたタスクデータをまず抽出し、その中から開始日時が設定済、かつ、終了日時が未設定の１つ以上のタスクデータを更新対象として抽出してもよい。タスクデータ更新部１４２は、更新対象の１つ以上のタスクデータのそれぞれに、メッセージが示す環境状態データを設定してもよい。この態様によると、センサが状態通知装置１２６として機能する場合に、当該センサはプロジェクトインスタンスＩＤを取得する必要がなく、当該センサ自体が直接ネットワークに接続してメッセージをパブリッシュすることの実現を容易なものにできる。

第３変形例を説明する。上記実施例では言及していないが、前提技術のＩＯＴ機器制御システム１０と同様に、管理装置１２２は、タスクの開始を指示する開始指示メッセージをメッセージブローカ１２３へパブリッシュし、タスク遂行側機器（例えば作業者のＰＣやタブレット端末、工作機械等）は、開始指示メッセージをメッセージブローカ１２３からサブスクライブする構成であってもよい。この場合、管理装置１２２は、タスク遂行側機器（状態通知装置１２６）からタスク終了通知を受け付けた場合、タスク順序記憶部１３６を参照して次に実行すべきタスクを識別し、識別したタスクの開始を指示する開始指示メッセージをパブリッシュしてもよい。また管理装置１２２は、タスク開始メッセージの送信時に、開始対象タスクのタスクデータにおける開始日時を設定してもよい。

（第２実施例の概要説明）
第２実施例の概要を説明する。上記第１実施例のタスクデータにおける特に重要なデータとして、工作機械の動作状態を示すデータ（以下「機器動作状態データ」とも呼ぶ。）がある。例えば図１７の事例では、鉄板切削加工タスクが、２時間で完了予定のところ２時間３０分かかっているが、この原因を特定するために、切削加工装置「Ｃｕｔｔｉｎｇ Ｍ１」の機器動作状態データが有用である。

一般的な工作機械では、工作機械の内部状態がパトランプの点灯状態に反映される。そこで第２実施例では、工作機械の動作状況を示すために普遍的に用いられているパトランプの点灯状態を示すリレーの電圧データをフォトカプラで取得し、それをメッセージブローカ１２３へパブリッシュすることで、任意の場所に設置されたシステム（例えば管理装置１２２）において工作機械の動作状況を検出する技術を提案する。ただし第２実施例の技術の適用範囲は、工作機械におけるパトランプ情報の取得に制限されず、内部状態をリレーのチャンネルにアナログ出力可能な機械であれば広く適用可能である。

このようなリレー接点の利用は、もともとアナログな外部表示器（パトランプ等）などを点灯させることで機械装置の内部状態を表示することを想定したものである。第２実施例では、シーケンサーのプログラムやフロントパネルでの設定により柔軟に機械装置の内部状態をリレー設定情報として表現し、管理装置１２２等がＩｏＴデータとしてリレー設定情報を取得し、機械装置の内部状態を判別（記録）することが可能になる。

なお、第２実施例の技術は、本来のリレー接点の利用の延長であり、外部装置を直接駆動する代わりに、フォトカプラを経由してその信号を取得するものであるため、機械装置メーカが定める規約（メンテナンス契約等）に抵触しないというメリットがある。第２実施例で提案する機械装置の内部状態の取得方法は、工作機械のみならず、様々な種類のタスク遂行機器（制御盤等）に対して適用可能である。

（第２実施例の詳細説明）
図１８は、第２実施例のタスク遂行側機器の構成をブロック図である。同図の構成は、図１３のタスク遂行側機器に適用可能である。タスク遂行側機器は、工作機械１６０と状態通知装置１２６を備える。工作機械１６０は、図１７の事例では切削加工装置、プレス装置、塗装装置が該当する。

工作機械１６０は、制御部１６２、リレー１６４、パトランプ１６６を含む。制御部１６２は、工作機械１６０の動作全般を制御し、タスク遂行のための処理（例えば鉄板および銅板の切削加工処理）の動作を制御する。また制御部１６２は、工作機械１６０の動作状態（異常の有無等）を管理する。パトランプ１６６は、工作機械１６０の動作状態を外部の作業者等へ提示する表示器であり、警告灯とも言える。制御部１６２は、工作機械１６０の動作状態に応じて、パトランプ１６６の表示態様（例えば点灯の有無、点灯または点滅の種別、色等）を制御するための制御信号を出力する。

リレー１６４は、制御部１６２から入力される工作機械１６０の動作状態に基づく信号に応じて開閉する。実施例では、リレー１６４に、工作機械１６０の動作状態に応じた表示態様となるようにパトランプ１６６を制御するための制御信号が入力される。リレー１６４は、その制御信号にしたがってパトランプ１６６の表示態様を切り替える。リレー１６４は、開閉状態を切り替えることにより、パトランプ１６６へ入力される電圧を変化させる。これにより、上記制御信号で指定された態様にてパトランプ１６６が点灯または消灯する。

状態通知装置１２６は、フォトカプラ１７０、メッセージ生成部１７２、メッセージ出力部１７４を備える。フォトカプラ１７０は、工作機械１６０のリレー１６４と接続され、リレー１６４の開閉状態を示す状態信号を出力する。状態信号は、工作機械１６０において制御部１６２からリレー１６４へ印加された電圧または電流の状態を示す信号と言え、工作機械１６０においてリレー１６４からパトランプ１６６へ印加された電圧または電流の状態を示す信号とも言える。

メッセージ生成部１７２は、フォトカプラ１７０から出力された状態信号に基づいて、工作機械１６０の状態を示すタスク状態データを生成し、タスク状態データ、タスクＩＤ、プロジェクトインスタンスＩＤを含むメッセージを生成する。例えば、メッセージ生成部１７２は、状態信号の複数種類の態様（内容）と、管理装置１２２への複数種類の通知内容との対応関係を予め保持し、実際の状態信号の態様に対応する通知内容をタスク状態データとして設定したメッセージを生成してもよい。また、メッセージ生成部１７２は、状態信号の複数種類の態様と、パトランプ１６６の複数種類の表示態様との対応関係を保持してもよい。メッセージ生成部１７２は、実際の状態信号の態様に対応するパトランプ１６６の表示態様を識別し、識別したパトランプ１６６の表示態様を示すメッセージを生成してもよい。

さらにまた、メッセージ生成部１７２は、状態信号の複数種類の態様と、工作機械１６０の複数種類の動作状態との対応関係を保持してもよい。メッセージ生成部１７２は、実際の状態信号の態様に対応する工作機械１６０の動作状態を識別し、識別した動作状態を示すメッセージを生成してもよい。メッセージ生成部１７２は、工作機械１６０の動作状態を検出し、または、パトランプ１６６の表示態様を検出する状態検出部として機能すると言える。

メッセージ出力部１７４は、メッセージ生成部１７２により生成されたメッセージをメッセージブローカ１２３へパブリッシュする。当該メッセージをサブスクライブした管理装置１２２は、メッセージ内の接点データを図１６の機械稼働データとして、メッセージで指定されたタスクデータに記録する。なお、図１６の機械稼働データは、図１７における「Ｍ１稼働データ」「プレス機械稼働データ」等が該当する。なお、管理装置１２２は、接点データの種類と、パトランプ１６６の表示態様との対応関係、または、接点データの種類と、工作機械１６０の動作状態との対応関係を保持してもよい。管理装置１２２は、接点データに対応するパトランプ１６６の表示態様を示すデータ、または、接点データに対応する工作機械１６０の動作状態を示すデータをタスクデータに記録してもよい。

第２実施例の状態通知装置１２６は、工作機械１６０のリレー１６４内部の接点の状態を、フォトカプラ１７０を用いて電気的に絶縁しつつ取得する。これにより、リレー１６４内部の接点の状態を取得する際の安全性を高め、工作機械１６０のメーカが定める規約（安全基準等）からの逸脱を回避できる。

以上、本発明を第２実施例をもとに説明した。この実施例は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。

変形例として、工作機械１６０は、リレー１６４に代えて他の種類のスイッチを使用してもよく、例えば半導体スイッチ（ＭＯＳＦＥＴ、ＩＧＢＴ等）を使用してもよい。この場合、状態通知装置１２６のフォトカプラ１７０は、半導体スイッチのオン／オフ状態に応じた状態信号を出力してもよい。また、状態通知装置１２６は、フォトカプラ１７０に代えて他の種類の絶縁素子を使用してもよい。

上述した実施例および変形例の任意の組み合わせもまた本発明の実施の形態として有用である。組み合わせによって生じる新たな実施の形態は、組み合わされる実施例および変形例それぞれの効果をあわせもつ。請求項に記載の各構成要件が果たすべき機能は、実施例および変形例において示された各構成要素の単体もしくはそれらの連携によって実現されることも当業者には理解されるところである。

１２０ プロジェクト管理システム、 １２２ 管理装置、 １２３ メッセージブローカ、 １２６ 状態通知装置、 １３６ タスク順序記憶部、 １３８ タスクデータ記憶部、 １４０ タスク遂行状況取得部、 １４２ タスクデータ更新部、 １６０ 工作機械、 １６４ リレー、 １６６ パトランプ、 １７０ フォトカプラ、 １７２ メッセージ生成部、 １７４ メッセージ出力部。

Claims (1)

1. 所定の順序で遂行されるべき複数のタスクのうち少なくとも１つのタスクの遂行に関連する機器と、
   管理装置と、を備え、
   前記管理装置は、
   前記複数のタスクそれぞれの遂行に際して得られたデータをタスク単位にまとめたタスクデータを保持するタスクデータ保持部と、
   前記機器から送信された、１つのタスクの開始を示すデータを取得するとともに、前記１つのタスクの終了を示すデータを取得する取得部と、
   前記１つのタスクの開始を示すデータが取得された場合、前記１つのタスクに関するタスクデータに開始時刻を記録し、前記１つのタスクの終了を示すデータが取得された場合、前記１つのタスクに関するタスクデータに終了時刻を記録する更新部と、を含み、
   前記更新部は、前記１つのタスクの開始を示すデータが取得された後、前記１つのタスクの終了を示すデータが取得される前に、前記機器から送信された、前記１つのタスクの遂行に関するデータが取得された場合、前記１つのタスクに関するタスクデータに前記遂行に関するデータを記録し、
   前記機器は、前記１つのタスクを遂行する機器であるタスク遂行装置と、タスク遂行装置に接続された通知装置とを含み、
   前記タスク遂行装置は、本装置の動作状態に基づく制御信号が入力され、その制御信号に基づいてオン／オフするスイッチを含み、
   前記通知装置は、
   前記スイッチと接続され、前記スイッチのオン／オフ状態を示す状態信号を出力するフォトカプラと、
   前記フォトカプラから出力された状態信号に基づくデータを前記１つのタスクの遂行に関するデータとして出力する出力部と、を含むことを特徴とする管理システム。

Images