JP2008226005A - 制御ソフトウェア部品の配布管理システム - Google Patents

Abstract

【課題】資産として管理された制御ソフトウェア部品がどのように修正・改造され、どのリビジョンがどの装置開発にて利用されたかを簡単に確認できるようにする。
【解決手段】部品開発者Ｆ１が作成した関連性の高く一緒に再利用されることが多い制御ソフトウェア部品とそれに関連したドキュメント類を、“資産部品プロジェクト”として取りまとめ、部品管理サーバ３に保存する。資産部品プロジェクトは、リビジョンで管理される。装置開発者Ｆ４は、開発パソコン４を用いて公開が許可されたリビジョンを見ることができ、自らが開発しようとする装置Ａの装置要件を作成し、サーバに要求することで特定装置向け部品セットを取得する。部品管理サーバは、取得元である資産部品プロジェクトのリビジョン、取得に用いられた装置要件と、取得された部品に関連づけられたトレースＩＤが関連づけた履歴情報を格納する。
【選択図】図１

Description

この発明は、装置／設備の制御に用いられる機器制御システムの分野における、制御ソフトウェア部品の配布管理システムに関するものである。

工場に設置される検査装置や設備装置は、産業用制御装置が機器制御プログラムを実行することにより制御される。産業用制御装置の具体例は、プログラマブルコントローラである。工場の設備担当者や生産技術担当者などのプログラマブルコントローラのユーザは、プログラマブルコントローラに任意の制御を実行させるために、プログラミングツール装置にてラダープログラムを予め作成し、その作成したラダープログラムをプログラマブルコントローラに格納する。プログラマブルコントローラは、ラダープログラムをサイクリックに実行し、検査装置や設備装置を任意に制御する。

最近では、プログラマブルコントローラの制御内容の一部が違っていても、既存のラダープログラムの一部を必要に応じて編集や修正等を施して、つまりラダープログラムを再利用して、プログラミング作業を効率化することが図られている。その際、プログラム部品管理ツール装置にて、再利用の対象となるプログラムをデータベース化することも図られている。

ラダープログラムに代表される機器制御ソフトウェアの部品化・再利用化については、一般的にIEC61131規格で定義された”ファンクションブロック”の仕組みを用いて実現されている。ファンクションブロックにより、ラダープログラムと変数のカプセル化が実現され、ラダープログラムを部品として再利用することが可能になっている。変数は、例えばプログラマブルコントローラの制御対象である入出力接点などである。また、ラダープログラムの一部を必要に応じて編集や修正等を施す際に、そのプログラム上の複数箇所に現れる複合処理をそれぞれ簡単なマクロ演算部品の図形で置き換えることにより、図形表示されたプログラムについての一部編集や一部変更等の簡素化を図ることも知られている（特許文献１参照）。

また、近年、製品ラインアップの共通性と差異性とを分析し、効果的なソフトウェア資産の形成を目指す“プロダクトライン・ソフトウェア・エンジニアリング”（以下、ＰＬＳＥと省略）と呼ばれる手法が提唱されている。一方、ラダープログラムが用いられる機器制御システムの分野では、製品ラインナップを充実させてユーザのニーズに対応できるように、大部分は同一であるが部分的に差異のあるシステムを多数開発しているケースが多い。そこで、係るシステムを制御するためのラダープログラムの設計・開発に対しても、ＰＬＳＥ適用の有効性が期待される。

また、サーバからプログラムを配信したり、その配信したプログラムのバージョン（リビジョン）の管理をしたりするものとしては、例えば特許文献２に開示された発明がある。
特開平６−２３０８０４号公報 特開平７−２２５６７９号公報

しかし、このような分析に基づくプログラム部品化を行う上で、ファンクションブロックによる方法では以下に示す問題を有する。すなわち、複数の類似した装置開発で利用可能な標準部品がいったん整備されても、個々の装置開発において部品を利用する際に、その装置特有の要件にもとづいて部品に変更を加える必要が生じることが多い。従って、標準部品の利用が進むに伴い、標準部品から派生された部品が多く作成され実際の装置に利用されてしまうため、事実上ソフトウェア部品を管理できなくなってしまう。

この問題を解決するため、装置特有の要件に従った部品の変更と再利用を管理するため、ＰＬＳＥ手法に基づいて予め装置要件に基づく変更点を標準部品に組み込んでおき、装置開発での利用時には組み込まれた変更点を選択するだけで必要な部品が取得できるようにした部品管理手法とその支援システムが試行されつつある。本発明者らは、その実現手段のひとつとして、プログラム部品のバリアビリティーポイント（変化点）を定義し、あらかじめラダープログラム中に、その一部を変形するためのマクロ記述を組み込み、与えるパラメータセットを変更してマクロ処理を実行することで、一部が変形したプログラム部品を生成する手法を提案した（特願２００５−２８８８５８号）。これにより、マクロ処理を実行して生成された最終的なラダープログラムは、不要なラダー回路は削除され、適用するアプリケーションに必要十分なラダー回路から構成されたものになり、プログラムの規模を可及的に縮小し実行時間性能の向上を図ることができるという作用効果を奏する。

しかしながら工場設備などの分野では、一般的に生産技術部門が標準部品の整備・管理し、各装置・設備の開発者がそれを利用して開発が行われる。このように標準部品を整備する主体と、部品を利用して装置・設備を開発し運用する主体は異なることが多いため、上述の先願発明のように装置要件に基づく標準部品の自動変更機能を備えた部品管理環境だけでは、標準部品の各装置の制御プログラムでの利用を管理することが十分に行なえないことがある。

また、工場設備などの分野における特徴的な制御ソフトウェアの運用として、装置の運用現場において保全、改善、ＶＥ活動が挙げられる。これらの活動では設備・機器を運用しながらその制御ソフトウェアに対して、経年変化などにより発生する故障の予防措置や、発生したトラブルへの対策の埋め込み、生産設備の能力向上のための改良といった修正が加えられる。こうした保全、改善、ＶＥ活動で行われる修正の中には、当該装置だけにではなく標準部品にも反映させることが必要な重大なものもあるが、上述した処理する主体が異なることなどの要因により、標準部品のどのリビジョンから派生された部品が、どの装置の制御プログラムに利用されているかを管理することが困難なため、特許文献２等の技術を用いても、実現に供し得ないものとなる。さらにまた、同様の理由から標準部品に欠陥等が見つかり修正を行なった場合などに、更新した標準部品を装置の制御プログラムに対して反映することも困難である。

この発明は、資産として管理された制御ソフトウェア部品がどのように修正・改造され、どのリビジョンがどの装置開発にて利用されたかを簡単に確認できる制御ソフトウェア部品の配布管理システムを提供することを目的とする。

この発明による制御ソフトウェア部品の配布管理システムは、（１）ＰＯＵやファンクションブロック等の機器制御プログラム用の制御ソフトウェア部品が格納された部品管理サーバと、その部品管理サーバにネットワークを介して接続される第１部品取得クライアントと、を備え、制御ソフトウェアは、一緒に再利用されることが多いものをひとくくりにまとめた資産部品プロジェクト単位で管理されると共に、リビジョンが管理される。そして、第１部品取得クライアントは、資産部品プロジェクトに対して、資産部品プロジェクトで定義された装置要件モデルを元に、開発対象の特定装置の装置要件を作成しそれを元に部品管理サーバに要求することによって特定装置向け部品セットを取得する機能を有し、部品管理サーバは、第１部品取得クライアントが部品管理サーバから特定装置向け部品セットを取得すると、取得元である資産部品プロジェクトのリビジョンと、取得に用いられた装置要件と、取得された部品に関連づけられたトレースＩＤとを関連づけた配布履歴情報を格納するようにした。

制御ソフトウェア部品は、実施形態の資産部品に対応する。第１部品取得クライアントは、実施形態の装置開発者Ｆ４が使用する装置制御プログラム開発装置４に実装された第１部品取得クライアント１５に対応する。この発明によれば、装置開発者が第１部品取得クライアントを利用することで装置要件を作成して特定装置用の部品セットを取得することができる。

（２）また、別の解決手段としては、ＰＯＵやファンクションブロック等の機器制御プログラム用の制御ソフトウェア部品が格納された部品管理サーバと、その部品管理サーバにネットワークを介して接続される第１部品取得クライアントと、その部品管理サーバにネットワークを介して接続される第２部品取得クライアントと、を備え、前記制御ソフトウェアは、一緒に再利用されることが多いものをひとくくりにまとめた資産部品プロジェクト単位で管理されると共に、リビジョンが管理されるようにした。そして、第１部品取得クライアントは、資産部品プロジェクトに対して、資産部品プロジェクトで定義された装置要件モデルを元に、開発対象の特定装置の装置要件を作成し、それを元に作成した特定装置向け部品セットを前記部品管理サーバにアップロードする機能を有し、第２部品取得クライアントは、前記部品管理サーバで公開されている装置要件の中から任意のもの指定することで、その要件が表す特定装置の開発に必要な特定装置向け部品セットを前記部品管理サーバから取得する機能を有し、部品管理サーバは、第２部品取得クライアントが特定装置向け部品セットを取得すると、取得元である資産部品プロジェクトのリビジョンと、取得に用いられた装置要件と、取得された部品に関連づけられたトレースＩＤとを関連づけた配布履歴情報を格納するようにした。

制御ソフトウェア部品は、実施形態の資産部品に対応する。第２部品取得クライアントは、実施形態の第２部品取得クライアント１６に対応する。この発明によれば、装置要件を設定する知識を有していない装置開発者であっても、簡単に特定装置用の部品セットを取得することができる。

（３）上記の（１）または（２）の発明を前提とし、制御ソフトウェア部品は、特定装置にダウンロードして動作させるバイナリー自体にトレースＩＤが含められるように構成され、特定装置に利用されているソフトウェアを構成する部品に埋め込まれたトレースＩＤをキーにして、当該部品の生成元である資産部品プロジェクトのリビジョンと、取得時に指定された装置要件を検索する手段を備えるとよい。

（４）上記の（１）または（２）の発明を前提とし、管理サーバに格納された配布履歴情報に基づき、指定された任意のリビジョンの資産部品プロジェクトに含まれる制御ソフトウェア部品の配布先を検出する手段を備えるとよい。

上記の発明によれば、装置の要件を指定するだけでその装置の開発に必要な一揃いの制御ソフトウェア部品セット（以下、特定装置向け部品セットと呼ぶ）が、資産部品セットの中から選択・変形されて取得できるような資産部品構成環境に対して、部品の管理サーバを導入することにより、資産として管理された制御ソフトウェア部品がどのように修正・改造され、どのリビジョンがどの装置開発にて利用されたかを簡単に確認できる。

「装置要件モデル」とは、製品（装置）ラインナップにおける製品（装置）のバリエーションを表現した分析モデルを指す。ＰＬＳＥ手法の「特性モデル」は「装置要件モデル」の１種である。また、「装置要件」とは、「装置要件モデル」に基づいて、具体的に製品（装置）を決定するための属性値の集合を表す。

本発明は、資産として管理された制御ソフトウェア部品がどのように修正・改造され、どのリビジョンがどの装置開発にて利用されたかを簡単に確認できる。

図１は、本発明が適用される環境の一例を示している。部品開発現場に配置される部品開発装置１と、部品管理現場に配置される部品配布管理装置２及び部品管理サーバ３と、各装置開発現場に配置される装置制御プログラム開発装置４，５と、がインターネット６を介してデータの送受を可能としている。

まず、各現場で作業するアクター（システムユーザ）について説明する。部品開発者Ｆ１は、資産部品（部品）の開発を行なうソフトウェア開発者であり、装置の製品ラインナップ全般に関する実装上の知識を有する人である。この部品開発者Ｆ１は、具体的には生産技術部門の開発者等である。

部品開発現場では、部品開発者Ｆ１が部品開発装置１を操作してＰＬＣの機器制御ソフトウェアの再利用部品たる「部品」（ファンクションブロック等）を作成する。通常、係る部品を作成する場合、１つの部品のみを作成することはなく、一緒に再利用されることが多いソフトウェア部品をひとくくりとした「資産部品プロジェクト」を、複数の部品開発者Ｆ１たちが作成する。そこで、これら複数の部品開発者Ｆ１たちは、後述するリビジョン管理を行ないながら、資産部品プロジェクトの開発・修正・更新作業を実行していく。

部品配布管理者Ｆ２は、装置開発者Ｆ４，Ｆ５に対して部品配布を司る権限を有した管理者を言う。図２では、部品配布管理者Ｆ２は、部品開発者Ｆ１とは別の現場に存在するように記載したが、実際には部品開発者Ｆ１のうちの一人（リーダ等）が兼任しても良い。この部品配布管理者Ｆ２が、制御ソフトウェア用の部品の装置開発者Ｆ４，Ｆ５への配布管理と、配布履歴の参照・検索を行なう。部品の修正・更新が行われた場合には、配布履歴を元に必要な装置開発者Ｆ４，Ｆ５に更新連絡を行なう。この部品配布管理者Ｆ２は、具体的には生産技術部門の管理者等である。

システム管理者Ｆ３は、部品管理サーバ３のメンテナンスを行なう。具体的には、バックアップやリストアを行なったり、不要データを削除するなどの様々なデータベース管理を行なったりする者である。これら部品配布管理者Ｆ２とシステム管理者Ｆ３とが、部品の管理を行なう。

装置開発者Ｆ４，Ｆ５は、特定の装置開発（当該装置の制御プログラムの開発）を行なうソフトウェア開発者である。装置開発者Ｆ４，Ｆ５は、配布された制御ソフトウェア用の部品を取得し、実際の装置制御プログラムの開発を行なう。開発対象の装置の装置要件モデルである装置ラインナップにおけるバリエーション、つまり、その装置がどのような入出力機器をいくつ必要かなどのバリエーションの知識を有しており、制御プログラムに必要な資産部品プロジェクト（必要な部品セット）を知っていて、係る開発対象装置の装置要件の指定をすることができる人（Ｆ４）と、係る知識が無くて開発装置の装置要件を指定できない人（Ｆ５）がいる。装置要件を指定できない装置開発者Ｆ５は、部品配布管理者Ｆ２によって予め部品管理サーバ３に登録されたその装置に必要な資産部品郡を取得し、制御プログラムの開発をする。

上記の部品開発装置１，部品配布管理装置２，装置制御プログラム開発装置４，５は、パーソナルコンピュータに所定のアプリケーションプログラムをインストールすることで実現できる。

部品開発装置１は、ラダー開発ツール装置１１と資産部品構成ツール装置１２を備える。ラダー開発ツール装置１１は、ラダープログラムを開発するためのツール装置である。資産部品構成ツール装置１２は、関連性が高く一緒に再利用されることが多い制御ソフトウェア部品（ＰＯＵ）群とそれに関連したドキュメントファイル類を、“資産部品プロジェクト”として整備するソフトウェアである。この資産部品構成ツール装置１２は、“資産部品プロジェクト”の編集・デバッグ機能と、それを部品管理サーバ３に保存するリビジョン管理クライアント機能を有する。ファンクションブロック等の再利用可能な部品自体の作成等も、この資産部品構成ツール装置１２により行なわれる。

部品管理サーバ３は、部品管理サーバソフトウェア１３がインストールされている。この部品管理サーバソフトウェア１３は、資産部品プロジェクトの変更管理／リビジョン管理機能、および再利用部品の配布／配布履歴管理機能をコンピュータに実現するものである。

部品配布管理装置２は、部品配布管理クライアント１４と、第１部品取得クライアント１５と、を備えている。部品配布管理クライアント１４は、部品配布管理者Ｆ２が、部品管理サーバ３で管理された資産部品プロジェクトの任意のリビジョンを、装置開発者Ｆ４，Ｆ５に対して配布指定するクライアント・ソフトウェアである。本実施形態では、この機能はサーバのＷｅｂアプレットとして実装され、Ｗｅｂブラウザ上で実行される。

また、部品配布管理装置２の第１部品取得クライアント１５は、部品管理サーバ３上の資産部品プロジェクトに定義されている装置要件モデルに基づき、装置要件を作成して特定装置向け部品セットを生成し、部品管理サーバ３にアップロードするのに使用するクライアント・ソフトウェアである。

装置要件の指定を行なう装置開発者Ｆ４が使用する装置制御プログラム開発装置４は、ラダー開発ツール装置１２と、第１部品取得クライアント１５と、を備えている。本装置４に実装されたラダー開発ツール装置１２は、特定の装置（図示の場合、装置Ａ）用の制御プログラムを作成・編集し、その制御プログラムを当該特定の装置の動作を制御するＰＬＣにダウンロードする。第１部品取得クライアント１５は、装置開発者Ｆ４が、部品管理サーバ３上の資産部品プロジェクトに定義されている装置要件モデルに基づき、開発しようとする装置要件を作成して特定装置向け部品セットを取得するのに使用するクライアント・ソフトウェアである。そして、装置開発者Ｆ４は、取得した特定装置（この場合、装置Ａ）向け部品セットを利用し、ラダー開発ツール装置１２を使用して特定装置用の制御プログラムを作成する。

装置要件の指定を行なう知識のない装置開発者Ｆ５が使用する装置制御プログラム開発装置５は、ラダー開発ツール装置１２と、第２部品取得クライアント１６と、を備えている。本装置５に実装されたラダー開発ツール装置１２は、特定の装置（図示の場合、装置Ｂ）用の制御プログラムを作成・編集し、その制御プログラムを当該特定の装置の動作を制御するＰＬＣにダウンロードする。第２部品取得クライアント１６は、装置開発者Ｆ５が、部品管理サーバ３上で部品配布管理者Ｆ２が予め作成しておいた装置要件に基づいて、特定装置向け部品セットを取得するのに使用するクライアント・ソフトウェアである。本実施形態では、この機能はサーバのＷｅｂアプレットとして実装され、Ｗｅｂブラウザ上で実行される。そして、装置開発者Ｆ５は、取得した特定装置（この場合、装置Ｂ）向け部品セットを利用し、ラダー開発ツール装置１２を使用して特定装置用の制御プログラムを作成する。

次に、部品管理サーバ３におけるユーザアカウントの管理について説明する。本実施形態では、部品のリビジョン管理／配布管理を実現するために、部品管理サーバ３では、各開発者や管理者のロール（役割）ごとに以下に示すようなユーザアカウントの管理が行なわれる。なお、アカウントは下記のロールのうちのいずれかまたは複数を持ち、保有するロールにより利用できる部品管理サーバ３のサービスが制限される。

システム管理者Ｆ３は、部品管理サーバ３のシステムメンテナンスを行うスーパーユーザーであるので、システムに対する全操作権限をもっている。

部品配布管理者Ｆ２は、部品管理サーバ３に格納されたコンテンツに関する全権限を持つ管理者であるので、部品管理サーバ１３がクライアントに提供するすべてのサービスを実行することができる。さらに、部品配布管理者Ｆ２は、すべての資産部品プロジェクトとその構成物、およびユーザアカウント情報に対して参照・編集権限を持っている。さらにまた、部品配布管理者Ｆ２は、部品配布管理クライアント１４によりユーザアカウントの追加・変更・削除を行なうことができる。これにより、部品管理サーバ３に登録された資産部品プロジェクトに対して参照可能なユーザ（部品開発者Ｆ１，装置開発者Ｆ４，Ｆ５）を追加したり制限したりすることができる。

部品開発者Ｆ１は、資産部品プロジェクトの変更管理／リビジョン管理に必要なサーバサービスが利用できる。換言すると、部品開発者Ｆ１は、部品配布管理者Ｆ２における配布権限がない。さらに、部品配布管理者Ｆ２がユーザアカウント個別に行なう設定により、アクセスできる資産部品プロジェクトが制限される。一例を示すと、食品包装機械用の資産部品プロジェクトの部品開発者は、それとは異なる基板検査装置の資産部品プロジェクトにアクセスできないようにすることなどである。

装置要件を作成して部品を取得する装置開発者Ｆ４は、部品配布管理者Ｆ２によって許可された資産部品プロジェクトを参照し、そこに定義されている要件モデルに基づいた装置要件を作成することで、その要件が表現する装置の開発に必要な特定装置向け部品セットを取得することができる。具体的には、装置要件の指定を行なって特定装置向け部品セットを取得、および特定装置向け部品セットの取得をするのに必要なサーバサービスのみが利用できる。さらに、部品開発者Ｆ１と同様に、部品配布管理者Ｆ２がユーザアカウント個別に行なう設定により、参照することができる資産部品プロジェクトが制限される。つまり、取得できる資産部品プロジェクトが制限され、自己に関係のない資産部品プロジェクトについては参照することができない。

装置要件の指定を行わない装置開発者Ｆ５は、自ら装置要件を作成するのではなく、部品配布管理者Ｆ２が予め用意した装置要件から選択して、その装置の開発に必要な特定装置向け部品セットを取得する装置開発者であるため、当該特定装置向け部品セットの取得で必要なサーバサービスのみが利用できる。さらに、部品配布管理者Ｆ２がユーザアカウント個別に行なう設定により、取得時に選択できる装置要件が制限される。つまり、取得できる資産部品プロジェクトが制限され、自己に関係のない資産部品プロジェクトについては参照することができない。

以下、具体的な作業・処理を説明しつつ、部品開発装置１，部品配布管理装置２，部品管理サーバ３並びに装置制御プログラム開発装置４，５の具体的な機能について説明する。

図２は、資産部品プロジェクトの変更管理の処理を示している。この変更管理は、一般的に行なわれている公知のリビジョン管理と同様である。すなわち、特定の製品ラインナップに属する複数の製品で再利用される制御ソフトウェア部品をとりまとめた“資産部品プロジェクト”は、資産部品構成ツール装置１１を用いて部品開発者によって作成され、部品管理サーバ３に登録されることで、変更管理対象となる。

資産部品構成ツール装置１１は、部品開発者Ｆ１からの入力に従い、以下の処理を実行する。すなわち、資産部品構成ツール装置１１は、作成した資産部品プロジェクトをインターネット６介して部品管理サーバ３へ登録する。また、資産部品構成ツール装置１１は、部品管理サーバ３にアクセスし、その部品管理サーバ３で管理されている資産部品プロジェクトの最新版や任意のリビジョンの資産部品プロジェクトを取得できる。

さらに、資産部品構成ツール装置１１は、変更した資産部品プロジェクトの部品管理サーバ３への反映を行なうことができる。本実施形態では、部品管理サーバ３から取得した資産プロジェクトを修正した場合、修正部分に関する情報を部品管理サーバ３に登録する。さらに、資産部品構成ツール装置１１は、資産部品プロジェクトの変更履歴を閲覧したり、資産部品プロジェクトに対して複数人が同時に編集処理をしたりすることができる。

部品管理サーバ３は、資産部品構成ツール装置１１から資産部品プロジェクトの登録を受けた場合、新規な者か否かを判断し、新規なものの場合には、リビジョンを付与するとともに、そのリビジョンと資産部品プロジェクトを関連づけて保存する。また、新規でない場合には、登録済みの最新版の資産部品プロジェクトの内容と、今回受け付けた資産部品プロジェクトを比較し、相違部分がある場合には、改良されたとして異なる部分に関する情報をリビジョン情報とともに保存する。なお、リビジョン（版，バージョン）の付与システムについては、従来と同様であるので、その詳細な説明を省略する。

本実施形態では、資産部品プロジェクトに、要件モデル（ＰＬＳＥ手法における特性モデルなど）が定義されている。そして、その要件モデルに基づいて装置要件（製品ラインナップでその製品を特定する属性値の集合、例えば「搬送機の軸数」や「ワーク検出センサ数」、「電断対策機能の有無」など）を作成することで、その装置に必要な部品セットが取得できるように、資産部品プロジェクトが構成されていることを前提としている。

部品管理サーバ３に登録された資産部品プロジェクトの中から特定の装置開発に必要な一揃いの特定装置向け部品セットは、インターネット６を介して装置制御プログラム開発装置４，５に配布される。部品配布管理者Ｆ２と装置開発者Ｆ４，Ｆ５との間における配布形態は、（１）装置開発者Ｆ４が取得時に装置要件を指定し、該当する資産部品プロジェクトを配布する形態（図３〜図５参照）と、（２）部品配布管理者Ｆ２が装置要件を予め指定しておき、対応する資産部品プロジェクトを配布する形態（図６〜図８参照）と、の２つがある。

上記の（１）の形態は、部品配布管理者Ｆ２が装置開発者Ｆ４に対して資産部品プロジェクトを公開しておき、装置開発者が自ら要件モデルを元に装置要件を作成して必要な特定装置向け部品セットを取得する形態である。つまり、装置開発者Ｆ４自らが、資産部品と共に整備されていた要件モデルを元に、開発対象の装置要件を作成して、特定装置向け部品セットを得る配布形態であり、これは部品配布管理者Ｆ２が、資産部品プロジェクトの特定のリビジョンに公開フラグをつけておき、それを装置開発者Ｆ４が取得してローカル環境で特定装置向け部品セットの生成・取出しを行なうことで実現する。

具体的には、以下の手順で実行される。すなわち、図３中の（ａ）に示すように、部品配布管理者Ｆ２は、部品配布管理クライアント１４を用いて、資産部品プロジェクトの公開指定を行なう。つまり、公開しようとする資産部品プロジェクトの“参照を許可する装置開発者リスト”に公開先の装置開発者のユーザアカウントを追加し、さらにその資産部品プロジェクトのリビジョン一覧から公開しようとするものに、“公開フラグ”を設定する。公開フラグが振られたリビジョンは、要件指定を行なう第１部品取得クライアント１５を用いて装置開発者ロールのアカウントでログインしたときに、取得対象として見えるようになる。

係る公開指定を行なうための部品配布管理クライアントと部品管理サーバの処理機能は、図４に示す処理フローを実行するようになっている。すなわち、まず、部品配布管理装置２の部品配布管理クライアント１４は、その部品配布管理装置２の入力装置から入力されたユーザアカウントとパスワードを受け取り、部品管理サーバ３にログインする（Ｓ１）。

これを受けた部品管理サーバ３は、部品配布管理クライアント１４から入力されたユーザアカウントとパスワードからユーザ認証を実施し（Ｓ１０）、認証の要否を判断する（Ｓ１１）。認証できない場合には、部品配布管理装置２の表示画面に認証できなかったことを表示する。この表示は、エラーメッセージの表示のように積極的な表示はもちろんのこと、入力されたユーザアカウントとパスワードの表示を消去する場合も含む。このように認証が得られなかった場合、部品配布管理者Ｆ２は、部品配布管理クライアント１４から再度ログインすることになる。

一方、部品管理サーバ３は、部品配布管理者の認証がとれた場合（処理ステップ１１の分岐判断でＯＫ）、登録されている資産部品プロジェクトとその全てのリビジョンの一覧を作成する（Ｓ１２）。この作成した一覧は、ｗｅｂアプレットの機能により、部品配布管理装置２の表示装置に表示される。

部品配布管理クライアント１４は、部品配布管理者Ｆ２からの入力を受け、部品配布管理装置の表示装置に表示された資産プロジェクトのうち、特定の資産プロジェクト中の“参照を許可する装置開発者リスト”に、配布先にする装置開発者のアカウントを登録する（Ｓ２）。このアカウント情報は、部品管理サーバ３に送られる。

部品管理サーバ３は、指定された資産部品プロジェクトの“参照を許可する装置開発者リスト”に、部品配布管理クライアント１４により送られた装置開発者のアカウントを追加する（Ｓ１３）。

部品配布管理クライアント１４は、資産部品プロジェクトの特定のリビジョンに、公開フラグを設定する（Ｓ３）。つまり、資産部品プロジェクトは、必要に応じて改訂が行なわれ、複数のリビジョンが存在することがある。そして、例えば、最新のリビジョンのものは開発中で公開できないような場合、それ以前のリビジョンについて公開フラグを設定する。

部品管理サーバ３は、この公開フラグの設定にともない、自己に格納された公開フラグに関する情報が更新され、これ以後、部品管理サーバ３では、指定された資産部品プロジェクトの指定されたリビジョンに公開フラグが設定されたものについて、“参照を許可する装置開発者リスト”に登録されている装置開発者からの取得が可能になる（Ｓ１４）。つまり、係る装置開発者に対する配布が可能となる。

図３中の（ｂ）に示すように、装置開発者Ｆ４は、装置制御プログラム開発装置４を操作し、第１部品取得クライアント１５を用いて装置要件の指定を行ない、上記の手順により配布可能となった特定装置向けの資産部品プロジェクト（所望のリビジョン）を取得する。次いで、図３中の（ｃ）に示すように、装置開発者Ｆ４は、取得した資産部品プロジェクト（特定装置向けの部品セット）を用い、ラダー開発ツール装置１２にて特定装置の制御プログラムの開発を行なう。

係る装置開発者Ｆ４が、装置要件を指定して部品を取得するための第１部品取得クライアント１５と部品管理サーバ３の処理機能は、図５に示す処理フローを実行するようになっている。つまり、以下の操作をウィザード形式でシーケンシャルに実施するようになる。

すなわち、まず、装置制御プログラム開発装置４の第１部品取得クライアント１５は、その装置制御プログラム開発装置４の入力装置から入力されたユーザアカウントとパスワードを受け取り、部品管理サーバ３にログインする（Ｓ２０）。

これを受けた部品管理サーバ３は、第１部品取得クライアント１５から入力されたユーザアカウントとパスワードからユーザ認証を実施し（Ｓ１５）、認証の要否を判断する（Ｓ１６）。つまり、ユーザアカウントとパスワードの関係が正しいか否かと、ユーザアカウントが装置要件を指定する装置開発者として登録されているか否かを判断する。そして、認証できない場合には、装置制御プログラム開発装置４の表示画面に認証できなかったことを表示する。この表示は、エラーメッセージの表示のように積極的な表示はもちろんのこと、入力されたユーザアカウントとパスワードの表示を消去する場合も含む。このように認証が得られなかった場合、装置開発者Ｆ４は、第１部品取得クライアント１５から再度ログインすることになる。

一方、部品管理サーバ３は、装置開発者の認証がとれた場合（処理ステップ１６の分岐判断でＯＫ）、認証したユーザに対して参照が許可されている資産部品プロジェクトの、公開フラグが設定されているリビジョンの一覧を作成する（Ｓ１７）。

第１部品取得クライアント１５は、装置開発者Ｆ４からの入力に従い、資産部品プロジェクト並びにそのプロジェクトのリビジョンを指定する（Ｓ２１）。つまり、“装置開発者Ｆ４”ロールのみを持つユーザアカウントでログインしているときには、公開フラグが設定された（ＯＮになっている）プロジェクトのリビジョンのみが装置制御プログラム開発装置４の表示画面に表示されるようになっているので、装置開発者Ｆ４は、その表示された資産部品プロジェクトの中から、自己が設計しようとする制御プログラムに必要なものを指定する。

そして、第１部品取得クライアント１５は、指定された資産部品プロジェクトのリビジョンを部品管理サーバ３へ対して要求し取得する（Ｓ２２）。この要求を受け取った部品管理サーバ２は、要求された資産部品プロジェクトのリビジョンを送信する（Ｓ１８）。

次いで装置制御プログラム開発装置４の第１部品取得クライアント１５は、装置開発者Ｆ４からの入力に従い資産部品プロジェクトに含まれる要件モデルをもとに装置要件を作成し（Ｓ２３）、装置要件に合致する特定装置向け部品セットを生成する（Ｓ２４）。そして、生成した部品個々にトレースＩＤを付与する（Ｓ２５）。このとき、「資産部品プロジェクト名称」，「資産部品プロジェクトのリビジョン番号」，「装置要件名称」，「装置要件の内容のコピー」，「部品セットの名称リストとトレースＩＤリスト」，「生成元の資産部品の名称」を含む生成履歴情報が作成される。

第１部品取得クライアント１５は、これらの情報を部品取り出し履歴として部品管理サーバ３へ送信する（Ｓ２６）。部品管理サーバ３は、送信されてきた履歴情報を、そのユーザの部品取得履歴に記録する（Ｓ１９）。この部品管理サーバ３への取得記録の送信に成功したことを条件に、第１部品取得クライアント１５は、部品管理サーバ３から生成した特定装置向け部品セットを取り出すことができる。すなわちラダープログラミングツール装置で利用可能な形式へエクスポートすることができるようにしている。このようにすることで、部品管理サーバ３は、どの特定装置向け部品セットをどのユーザに配布したかの情報を確実に知ることができる。

一方、上述した（２）の配信形態は、部品配布管理者Ｆ２があらかじめ特定装置向け装置要件の作成を行なってそれを部品管理サーバ３に登録しておき、装置開発者Ｆ５がそれを元に特定装置向け部品セットを取得する形態である。この配布形態によれば、装置開発者が簡単に特定装置向け部品セットを取得できる。

具体的には、以下の手順で実行される。すなわち、図６中の（ｄ）に示すように、部品配布管理者Ｆ２は、部品配布管理クライアント１４を用いて部品管理サーバ３に登録されている資産部品プロジェクトを取得する。

そして、部品配布管理者Ｆ２は、第１部品取得クライアント１５により、特定装置向け部品セットを作成する（図６中の（ｅ））。次いで、部品配布管理者Ｆ２は、部品配布管理クライアント１４を用いて、部品管理サーバ３に対して特定装置向け部品セットのリリース登録をする（図６中の（ｆ））。

係る部品配布管理者Ｆ２が特定装置向け装置要件の作成とリリース登録を行なうための部品配布管理装置２に実装された第１部品取得クライアント１５と、部品管理サーバ３徒の処理機能は、図７に示す処理フローを実行するようになっている。すなわち、まず、部品配布管理装置２の部品配布管理クライアント１４は、その部品配布管理装置２の入力装置から入力されたユーザアカウントとパスワードを受け取り、部品管理サーバ３にログインする（Ｓ３０）。

これを受けた部品管理サーバ３は、第１部品取得クライアント１５から入力されたユーザアカウントとパスワードからユーザ認証を実施し（Ｓ４０）、認証の要否を判断する（Ｓ４１）。つまり、入力されたユーザアカウントが、登録された部品配布管理者ロールのものか否か並びにその遊佐―座アカウントとパスワードの対応が正しいか否かを判断する。

認証できない場合には、部品配布管理装置２の表示画面に認証できなかったことを表示する。この表示は、エラーメッセージの表示のように積極的な表示はもちろんのこと、入力されたユーザアカウントとパスワードの表示を消去する場合も含む。このように認証が得られなかった場合、部品配布管理者Ｆ２は、部品配布管理クライアント１４から再度ログインすることになる。

一方、部品管理サーバ３は、部品配布管理者の認証がとれた場合（処理ステップ４１の分岐判断でＯＫ）、認証したユーザに対して参照が許可されている資産部品プロジェクトの、全てのリビジョンの一覧を作成する（Ｓ４２）。この一覧は、部品配布管理装置２の表示画面に表示される。

第１部品取得クライアント１５は、部品配布管理者Ｆ２からの入力に従い、資産部品プロジェクト並びにそのプロジェクトのリビジョンを指定する（Ｓ３１）。つまり、“部品配布管理者Ｆ２”ロールを持つユーザアカウントでログインしているときには、全ての資産部品プロジェクトの全てのリビジョンが部品配布管理装置２の表示画面に表示されるようになっているので、部品配布管理者Ｆ２は、その表示された資産部品プロジェクトの中から、任意のものを指定する。

そして、第１部品取得クライアント１５は、指定された資産部品プロジェクトのリビジョンを部品管理サーバ３へ対して要求し取得する（Ｓ３２）。この要求を受け取った部品管理サーバ２は、要求された資産部品プロジェクトのリビジョンを送信する（Ｓ４３）。

次いで部品配布管理装置２の第１部品取得クライアント１５は、部品配布管理者Ｆ２からの入力に従い資産部品プロジェクトに含まれる要件モデルをもとに装置要件を作成し（Ｓ３３）、装置要件に合致する特定装置向け部品セットを生成する（Ｓ３４）。そして、生成した部品個々にトレースＩＤを付与する（Ｓ３５）。このとき、「資産部品プロジェクト名称」，「資産部品プロジェクトのリビジョン番号」，「装置要件名称」，「装置要件の内容のコピー」，「部品セットの名称リストとトレースＩＤリスト」，「生成元の資産部品の名称」を含む生成履歴情報が作成される。

第１部品取得クライアント１５は、作成された特定装置向け部品セットを部品管理サーバ３へアップロードする（Ｓ３６）。部品管理サーバ３は、アップロードされた特定装置向けの部品セットを保存する（Ｓ４４）。

その後、第１部品取得クライアント１５は、必要に応じてアップロードした特定装置向け部品セットに対し、取得を許可する装置開発者Ｆ５のアカウントを設定する（Ｓ３７）。これにより、部品管理サーバ３は、アップロードされた特定装置向け部品セットを、Ｓ３７で指定された装置開発者Ｆ５に対して公開するようになる（Ｓ４５）。

上記の特定装置向け部品セットの作成とリリース登録が完了すると、図６に示す（ｇ）の装置開発者Ｆ５による特定装置向け部品セットの取得が行なえる。係る装置開発者Ｆ５が特定装置向け部品セットを取得するための第２部品取得クライアント１６と部品管理サーバ３の処理機能は、図８に示す処理フローを実行するようになっている。つまり、以下の操作をウィザード形式でシーケンシャルに実施するようになる。

すなわち、まず、装置制御プログラム開発装置５の第２部品取得クライアント１６は、その装置制御プログラム開発装置５の入力装置から入力された装置開発者Ｆ５のユーザアカウントとパスワードを受け取り、部品管理サーバ３にログインする（Ｓ５０）。

これを受けた部品管理サーバ３は、第２部品取得クライアント１６から入力されたユーザアカウントとパスワードからユーザ認証を実施し（Ｓ６０）、認証の要否を判断する（Ｓ６１）。つまり、ユーザアカウントとパスワードの関係が正しいか否かと、ユーザアカウントが装置要件を指定しない装置開発者として登録されているか否かを判断する。そして、認証できない場合には、装置制御プログラム開発装置５の表示画面に認証できなかったことを表示する。この表示は、エラーメッセージの表示のように積極的な表示はもちろんのこと、入力されたユーザアカウントとパスワードの表示を消去する場合も含む。このように認証が得られなかった場合、装置開発者Ｆ５は、第２部品取得クライアント１６から再度ログインすることになる。

一方、部品管理サーバ３は、装置開発者Ｆ５の認証がとれた場合（処理ステップ６１の分岐判断でＯＫ）、認証したユーザに対して参照が許可されている特定装置向け部品セットの一覧を作成する（Ｓ６１）。この一覧は、装置制御プログラム開発装置５の表示装置に表示される。

第２部品取得クライアント１６は、装置開発者Ｆ５からの入力に従い、表示された取得可能な特定装置向け部品セットの一覧を任意のものを指定する（Ｓ５１）。そして、第２部品取得クライアント１６は、指定された特定装置向け部品セットを部品管理サーバ３へ対して要求し取得する（Ｓ５２）。この要求を受け取った部品管理サーバ２は、要求された特定装置向け部品セットを送信する（Ｓ６３）。

次いで装置制御プログラム開発装置５の第２部品取得クライアント１６は、ダウンロードした特定装置向け部品セットを保存する（Ｓ５３）。また、部品管理サーバ３は、ダウンロードが完了したならばの、配信した特定装置向け部品セットについての情報をユーザの部品取得履歴に記録する。このようにすることで、部品管理サーバ３は、どの特定装置向け部品セットをどのユーザに配布したかの情報を確実に知ることができる。

また、装置開発者Ｆ４，Ｆ５は、部品管理サーバ３上にリリースされている特定装置向け部品セットの最新版に加え、過去に当該装置開発者が取得したことがあるリビジョンについても履歴を表示し、それを取得することができる。

部品配布管理者Ｆ２は、上述した機能に加え、特定装置向け部品セットのリリース取り消し権限と、並びにリリースされている特定装置向け部品セットへのアクセス権設定権限を備えている。

すなわち、部品配布管理者Ｆ２は、部品配布管理クライアント１４により、リリース済みの特定装置向け部品セットの任意のリリースリビジョンを、リリース取り消し（装置開発者が取得できないようにする）ことができる（リリース取り消し権限）。また、部品配布管理者Ｆ２は、部品配布管理倉案と１４により、指定したリリース済みの装置要件ごとに、それを取得することができる装置開発者アカウントを制限することができる（リリースされている特定装置向け部品セットへのアクセス権設定）。

図９は、上記の各装置１，２，４，５が部品管理サーバ３にアクセスして資産部品プロジェクトの登録・改良を行なったり、資産部品プロジェクトから特定装置向け部品セットを生成したり、取得したりする処理の一例を示している。

図示するように、新規に資産部品プロジェクトを作成した部品開発者Ｆ１は、資産部品構成ツール装置１２を用いて部品管理サーバ３の資産部品リポジトリ１３ａにその資産部品プロジェクトを登録する。この登録に伴い、部品管理サーバ３は、リビジョンとしてＲ１．０を付与している。

この資産部品プロジェクトに対し、複数の部品開発者Ｆ１が取得して修正したものを部品管理サーバ３の資産部品プロジェクト１３ａに登録することで、修正内容を反映する。修正する都度、リビジョンが付与される。

部品配布管理者Ｆ２は、この資産部品プロジェクトの任意のリビジョン（図では、Ｒ１．２とＲ１．３）に対し、公開フラグの設定を行なう。これにより、装置開発者Ｆ４は、公開フラグが振られた資産部品プロジェクトのリビジョンを取得して装置要件を指定し、特定装置向け部品セットを取得する。

また、部品配布管理者Ｆ２は、任意のリビジョンを取得し、特定装置向け部品セットを生成し、登録することができる。図の例では、リビジョンＲ１．１に基づいて、バージョン１．０の装置Ａ向け部品セットを登録し、リビジョンＲ１．２に基づいて、バージョン１．０の装置Ｂ向け部品セットを登録している。この登録された部品セットは、配布が許可された装置開発者Ｆ５が取得できる。また、登録された特定装置向け部品セットは、資産部品プロジェクトの改訂に伴いバーションアップされる。

次に、本実施形態における部品の配布履歴の管理について説明する。部品管理サーバ３は、装置要件を指定する第１部品取得クライアント１５による取得記録の送信があったとき、並びに、装置要件を指定しない第２部品取得クライアント１６によるダウンロードが行なわれたときに、送信／ダウンロードした特定装置向け部品セットについての取得履歴を作成する。

本システムでは、資産部品の配布先を検索することができる。ある時点の資産部品に不具合があった場合、不具合連絡と更新版の再配布を目的として、その資産部品から派生された特定装置向け部品セットを取得した装置開発者を検索することができる。

係る配布先の検索は具体的には、以下の手順を実行するようになっている。すなわち、まず、部品開発者Ｆ１が資産部品構成ツール装置１１を用いて、不具合が混入しているプロジェクトの特定のリビジョンを取得し、その不具合内容を確認する。次いで、部品開発者Ｆ１が、取得したプロジェクトについて資産部品構成ツール装置１１を用いて、不具合が混入している資産部品の変更履歴を表示し、変更履歴から同じ内容の（同じ不具合を含む）資産部品が含まれるプロジェクトのリビジョン番号を特定する。

そして、部品開発者から問題のあるプロジェクトのリビジョン番号について連絡を受けた部品配布管理者Ｆ２は、部品配布管理クライアント１４の配布先検索機能を用いて、そのプロジェクトリビジョンから派生された特定装置向け部品セットを取得した装置開発者を一覧表示させて確認する。この検索の際に使用する検索キーは、
資産部品プロジェクト名
資産部品プロジェクトのリビジョン（複数指定可）
装置要件の名称（無指定可）
である。

また、本実施形態では、配布する資産部品にトレースＩＤを埋め込むと共に、取得履歴情報にトレースＩＤを格納するようにしたため、そのトレースＩＤをキーにして検索することで、配布した特定装置むけ部品の装置開発現場の追跡や、装置運用現場で問題が発見された部品の出所である資産部品の検索などのトレースが行なえる。

まず、トレースＩＤの埋め込みは、以下の手順により実行される。すなわち、トレースＩＤは、以下の条件に合致する際にグローバルに一意なＩＤを部品（ＰＯＵ、ファンクションブロック）毎に対して生成し付与する。
・装置要件の指定を行なって特定向け部品セットを取得したとき
・特定装置向け装置要件の作成とリリースの作業において、特定装置向け部品セットを生成するとき

そして、付与されたトレースＩＤは、部品管理サーバ３に取得履歴を送信する際、または特定装置向け部品セットをサーバにリリース登録する際に、下記の情報と関連付けて部品管理サーバ３に記録される。
資産部品プロジェクト名称
資産部品プロジェクトのリビジョン番号
装置要件の名称
装置要件のコピー
部品（ファンクションブロック）名称
部品（ファンクションブロック）のトレースＩＤ
生成元の資産部品名称

上記のようにして付与・保存されたトレースＩＤから派生元である資産部品の参照（現象の発生元の特定）は、以下の手順で行なう。つまり、生産ラインや装置の運用現場で発見された制御ソフトウェア部品が、どの資産部品プロジェクトのいつのリビジョンから、どのような装置要件に基づき生成されたものかを検索ことができる。

まず、装置開発者Ｆ４，Ｆ５は、問題のある制御ソフトウェア部品のトレースＩＤを確認し、部品管理者Ｆ２に連絡する。連絡を受けた部品管理者Ｆ２は、部品配布管理クライアント１４を用いてトレースＩＤをキーにして、トレースＩＤと関連付けて記録された履歴情報を検索する。そして、部品管理者Ｆ２は、検索した情報をもとに不具合内容と修正依頼を部品開発者Ｆ１に対して行う。

本発明が適用されるシステム全体の一実施形態を示す図である。 資産部品プロジェクトの登録・変更管理を説明する図である。 部品の配布管理を説明する図である。 部品配布管理クライアントと部品管理サーバの機能を示すフローチャートである。 第１部品取得クライアントと部品管理サーバの機能を示すフローチャートである。 部品の配布管理を説明する図である。 第１部品取得クライアントと部品管理サーバの機能を示すフローチャートである。 第２部品取得クライアントと部品管理サーバの機能を示すフローチャートである。 部品配布の仕組みを説明する図である。

符号の説明

１ 部品開発装置
２ 部品配布管理装置
３ 部品管理サーバ
４，５ 装置制御プログラム開発装置

Claims (4)

1. ＰＯＵやファンクションブロック等の機器制御プログラム用の制御ソフトウェア部品が格納された部品管理サーバと、その部品管理サーバにネットワークを介して接続される第１部品取得クライアントと、を備え、
   前記制御ソフトウェアは、一緒に再利用されることが多いものをひとくくりにまとめた資産部品プロジェクト単位で管理されると共に、リビジョンが管理され、
   前記第１部品取得クライアントは、前記資産部品プロジェクトに対して、その資産部品プロジェクトで定義された装置要件モデルを元に、開発対象の特定装置の装置要件を作成しそれを元に部品管理サーバに要求することによって特定装置向け部品セットを取得する機能を有し、
   前記部品管理サーバは、前記第１部品取得クライアントが部品管理サーバから特定装置向け部品セットを取得すると、取得元である資産部品プロジェクトのリビジョンと、取得に用いられた装置要件と、取得された部品に関連づけられたトレースＩＤとを関連づけた配布履歴情報を格納する
   ことを特徴とする制御ソフトウェア部品の配布管理システム。
2. ＰＯＵやファンクションブロック等の機器制御プログラム用の制御ソフトウェア部品が格納された部品管理サーバと、その部品管理サーバにネットワークを介して接続される第１部品取得クライアントと、その部品管理サーバにネットワークを介して接続される第２部品取得クライアントと、を備え、
   前記制御ソフトウェアは、一緒に再利用されることが多いものをひとくくりにまとめた資産部品プロジェクト単位で管理されると共に、リビジョンが管理され、
   前記第１部品取得クライアントは、前記資産部品プロジェクトに対して、その資産部品プロジェクトで定義された装置要件モデルを元に、開発対象の特定装置の装置要件を作成し、それを元に作成した特定装置向け部品セットを前記部品管理サーバにアップロードする機能を有し、
   前記第２部品取得クライアントは、前記部品管理サーバで公開されている装置要件の中から任意のもの指定することで、その要件が表す特定装置の開発に必要な特定装置向け部品セットを前記部品管理サーバから取得する機能を有し、
   前記部品管理サーバは、前記第２部品取得クライアントが特定装置向け部品セットを取得すると、取得元である資産部品プロジェクトのリビジョンと、取得に用いられた装置要件と、取得された部品に関連づけられたトレースＩＤとを関連づけた配布履歴情報を格納する
   ことを特徴とする制御ソフトウェア部品の配布管理システム。
3. 前記制御ソフトウェア部品は、前記特定装置にダウンロードして動作させるバイナリー自体にトレースＩＤが含められるように構成され、
   前記特定装置に利用されているソフトウェアを構成する部品に埋め込まれたトレースＩＤをキーにして、当該部品の生成元である資産部品プロジェクトのリビジョンと、取得時に指定された装置要件を検索する手段を備えたことを特徴とする請求項１または２に記載の制御ソフトウェア部品の配布管理システム。
4. 前記管理サーバに格納された配布履歴情報に基づき、指定された任意のリビジョンの資産部品プロジェクトに含まれる制御ソフトウェア部品の配布先を検出する手段を備えたことを特徴とする請求項１または２に記載の制御ソフトウェア部品の配布管理システム。

Images