JP2016170547A - 制御システム、その管理サーバ装置、支援装置 - Google Patents

Abstract

【課題】管理サーバ装置側で、コントローラ側のプログラムを確実に管理できるようにする。
【解決手段】管理サーバ３０において、登録部５２は、支援装置１０から任意に作成／編集された任意の制御装置のプログラム（プロジェクト）の登録依頼があると、プログラム情報記憶部５１における該任意の制御装置に対応するプログラムとして、該登録依頼されたプログラムを記憶する。登録済情報付与部５３は、該登録部５２によってプログラム情報記憶部５１に登録された、上記登録依頼されたプログラムに対して、所定の登録済情報を付与する。支援装置１０の許可判定部６２は、上記登録済情報が付与されていないプログラムによって任意の制御装置のプログラムを更新することは、許可しない。
【選択図】図２

Description

本発明は、制御装置のプログラムを作成させる支援装置と、このプログラムを管理するサーバ装置を有する制御システムに関する。

プログラマブルコントローラは、停止状態であれば、プログラミング支援装置（以下、支援装置と記述）で作成されたプログラムをそのままダウンロードすることができるのが一般的である。そのため、複数のエンジニアが１つのコントローラに対してプログラム更新する場合、上書きされるという課題があり、特許文献１の発明では、他の支援装置によってプログラム更新が行われたことを検出する方法が提案されている。

また、コントローラが稼働状態におけるプログラム更新については、支援装置をコントローラに接続し、照合によって、支援装置のプロジェクトとコントローラ内のプロジェクトが一致していることを確認した後、その状態で変更を実施してコントローラにダウンロードする方法がとられている。また、特許文献２の発明では、識別子を利用することで、稼働中のプログラムから変更されたことを保障することで上記変更をオフラインにて行える方法が提案されている。

ここで、従来、例えば図９に示すような構成、すなわち支援装置５０とＰＬＣ６０に加えて更に管理サーバ７０が設けられた構成が知られている。
支援装置５０では、そのユーザ（プログラム開発者など）によって、任意のＰＬＣ（プログラマブルコントローラ）用のプログラムが、任意に作成される。支援装置５０は、プログラム作成の為のユーザ支援機能を有する。作成されたＰＬＣ用プログラム（制御プログラム等）は、支援装置５０からＰＬＣ６０へダウンロードされ、ＰＬＣ６０はこのＰＬＣ用プログラムを記憶して実行することで、不図示の各種制御対象機器の制御を行う。

その後、任意のときに、支援装置５０において、ユーザが、上記作成されたＰＬＣ用プログラムの更新（バージョンアップ版の作成など）を行う場合がある。これは、現在、ＰＬＣ６０に記憶されて実行されているＰＬＣ用プログラムに基づいて、更新版を作成する必要がある。

ここで、支援装置５０には、基本的に、全ての更新版が記憶されている。例えば、あるＰＬＣ用プログラムについて、その初版、２版、３版、４版、５版というようにバージョンアップされてきていた場合、これら全てが支援装置５０に記憶されている。そして、仮にＰＬＣ６０に５版のプログラムが記憶されて運用されている状態であったならば、次のバージョンアップ版の作成は、５版のプログラムに基づいて行う必要がある。しかしながら、バージョンが多すぎて、ユーザが管理し切れない場合がある。

この問題に対して、上記管理サーバ７０を設けられていた。管理サーバ７０は、図示のプロジェクト管理情報７１を保持している。プロジェクト管理情報７１は、各ＰＬＣが現在記憶・実行しているＰＬＣ用プログラムのプロジェクトを、記憶するものである。但し、これは、プログラム更新毎に、逐一、手作業によって登録するものである。

尚、上記プロジェクトは、実体としては、上記ＰＬＣ用プログラム（制御プログラム等）のソースコードや、このソースコードをコンパイルして成る機械語オブジェクト等が含まれる、例えばフォルダ等であるが、この例に限らない。

そして、任意のＰＬＣ６０のプログラムを更新する場合には、ユーザは、まず、このＰＬＣ６０に応じたプロジェクトを、プロジェクト管理情報７１から取得して支援装置５０に保存する操作を行う。そして、このプロジェクトのソースコードから更新版のソースコードを作成する。正常であれば、ＰＬＣ６０側では５版のプログラムによって制御実行されている状況では、プロジェクト管理情報７１には５版のプロジェクトが格納されているはずであり、そのソースコード（５版のソースコード）に基づいて更新版（６版）のソースコードが作成されることになる。これによって、例えば、誤って４版のソースコードに基づいて更新版のソースコードが作成されるような事態が起こることを防止することができる。

尚、支援装置５０では、ＰＬＣ用プログラム一式やその管理情報等を、プロジェクトとして管理している。つまり、支援装置５０において、ユーザは、任意のＰＬＣ用プログラムのソースコードを作成する。支援装置５０のコンパイラ機能は、このソースコードを、ＰＬＣで実行可能な形式である機械語オブジェクトに変換する。支援装置５０は、これらソースコードと機械語オブジェクトと管理情報一式を、まとめて、プロジェクトとして管理している。尚、管理情報とは、例えば、そのプロジェクトが格納されるフォルダのフォルダ名（図示のPri01、Pri01’、PriXXなど）等であるが、この例に限らない。そして、このフォルダを管理サーバ７０に転送して上記プロジェクト管理情報７１に上書き記憶させるものである。

上記プロジェクト管理情報７１へのプロジェクトの登録・更新は、各支援装置５０のユーザが手作業によって行う。基本的には、任意の支援装置５０のユーザが、ＰＬＣ６０のプログラムを更新する毎に、このプロジェクトを管理サーバ７０に転送して、プロジェクト管理情報７１における当該ＰＬＣ６０に対応するプロジェクトを、最新版の（つまり、現在、ＰＬＣ６０に記憶されている）プログラムのプロジェクトに更新させる。

但し、この例に限らない。上記説明は、管理サーバ７０と支援装置５０とがネットワーク等を介して通信できる構成である場合を前提としているが、この例に限らない。管理サーバ７０と支援装置５０とが通信できない構成である場合もあり得る。この様な構成の場合には、例えば、上記プロジェクト管理情報７１に対する上記手作業によるプロジェクト登録作業は、ユーザが、支援装置５０から上記更新版のプロジェクトを可搬型記憶媒体（メモリカードなど）にコピーして、この可搬型記憶媒体を管理サーバ７０のところまで持っていって管理サーバ７０に接続する。そして、この状態で、上記可搬型記憶媒体に記憶されている上記更新版プロジェクトを、上記プロジェクト管理情報７１に記憶する。

また、上記プロジェクト管理情報７１に登録されているプロジェクトを取得する際も、上記可搬型記憶媒体にプロジェクトをコピーして、この可搬型記憶媒体を支援装置５０のところまで持っていって支援装置５０に接続することで、支援装置５０に転送することになる。

尚、ＰＬＣ６０のプログラム更新は、ユーザが任意の更新版のソースコードを作成して、これが上記機械語オブジェクトに変換されて、この機械語オブジェクトがＰＬＣ６０にダウンロードされて既存の機械語オブジェクトと置き換えられることで、実現される。

尚、上記ＰＬＣ用プログラムの管理については、上記の一例に限らず、例えば、WindowsのＶＳＳ（Microsoft Visual SourceSafe）に代表されるように構成管理ツールを利用して管理を行う方法であっても構わない。ＶＳＳなどの構成管理ツールでは、ダウンロードすべき検証済の最新のプロジェクトの管理が可能である。

しかし、何れの方法であっても、結局、プロジェクト管理情報７１へのプロジェクトの登録・更新は、人間が手作業で行うことになり、プロジェクトを管理する人とプログラムを更新する人が異なる場合もあり、ミスが生じることが起こり得ることになる。例えば、ＰＬＣ６０のプログラムを４版から５版に更新する作業を行ったにも係わらず、その後、プロジェクト管理情報７１のプロジェクトを更新し忘れた為、プロジェクト管理情報７１には４版のプロジェクトが登録されたままの状態となる。

この為、その後、ユーザが、プログラム更新の為にプロジェクト管理情報７１からプロジェクトを取得すると、４版のプロジェクトが取得されることになり、４版のソースコードに基づいて更新版のソースコードが作成されることになる。

あるいは、何等かの原因によってＰＬＣ６０が保持するプログラムが消えてしまう場合がある。この場合、プロジェクト管理情報７１のプロジェクトの機械語オブジェクトを、ＰＬＣ６０にダウンロードすることで、プログラムを復活させることになるが、上記の状況では、５版のプログラムで運用していたＰＬＣ６０に対して、４版のプログラムがダウンロードされることになる。

上記のような状況では、管理しているプロジェクトとコントローラで実際に動作しているプロジェクトとが異なるため、管理しているプロジェクトで、設備の変更や、不具合対策などで、プログラムを変更した場合、コントローラに変更したプロジェクトが正常にダウンロードできないなどの問題が発生する。

特開2008-282362号公報 特開2013-168031号公報

上記のように、従来技術では、管理サーバ７０に登録されているプロジェクトと、コントローラ（ＰＬＣ６０）が保持・運用しているプログラムとが一致するようにする必要があるが、その為には例えばプログラム更新が行われる都度、ユーザが上記手作業による管理サーバ７０への登録作業を確実に行うことが必要である。しかしながら、一般的に、ユーザが手作業で行うことには、ミスがつきものである。

例えば、図９の従来技術では、プロジェクト管理の操作とプログラム更新の操作は、連動せずに、それぞれ単独の機能として実行される。そのため、検証済のプロジェクトを管理サーバ７０に登録したにも係わらず、管理されているプロジェクトとは別のプロジェクトでＰＬＣ６０のプログラム更新を行うことや、支援装置５０において管理サーバ７０から取得したプロジェクトを編集してＰＬＣ６０のプログラム更新を行うことが可能となっている。

また、このような場合に、コントローラ内のプログラムと管理しているプロジェクトのプログラムを一致させるには、プログラム更新を行ったプロジェクトをユーザが管理サーバ７０に再登録する必要があるが、再登録を忘れたり、ミスを犯しやすくなり、管理サーバ７０で管理されているプロジェクトが、コントローラで動作しているプログラムと一致しない状態に成り易いという問題がある。

また、ＰＣ等の分野においては、プログラムをサーバに登録し、サーバからネットワークを介して直接、端末等へプログラム配信する方法が行われている。これは、上記管理サーバ７０からネットワークを介してＰＬＣ６０に対してプログラム（機械語オブジェクト）を直接配信することに相当する。しかしながら、制御システムの分野においては、ネットワーク上にプログラムそのものを伝送するのは、セキュリティ上好ましくないばかりか、低速ネットワーク等の場合、プログラムサイズが大きいと帯域を圧迫することによるパフォーマンス低下の問題もある。

尚、制御システムでは、低速ネットワークに複数のＰＬＣが接続された構成があり、上記方法を用いる場合、管理サーバ７０もこの低速ネットワークに接続することになる。
この為、制御システムにおいては、コントローラが設置されている場所において、支援装置とコントローラをケーブル等で直接接続して、支援装置からコントローラにプログラムをダウンロードすることで、プログラム更新が行われる場合が殆どであり、上記サーバから直接配信する方法を適用することが困難である。

本発明の課題は、制御装置のプログラムを作成させる支援装置と、このプログラムを管理する管理サーバ装置を有する制御システムに関して、管理サーバ装置側で、制御装置側のプログラムを確実に管理できるようにする制御システム、その管理サーバ、支援装置等を提供することである。

本発明の制御システムは、制御装置と、該制御装置のプログラムが作成／編集される支援装置と、管理サーバ装置を有する制御システムであって、下記の構成を有する。
管理サーバ装置は、下記の各手段を有する。

・各制御装置毎に対応付けてプログラムが登録されるプログラム情報記憶手段；
・前記支援装置において任意に作成／編集された任意の制御装置のプログラムの登録依頼があると、前記プログラム情報記憶手段における該任意の制御装置に対応するプログラムとして、該登録依頼されたプログラムを記憶する登録手段；
・該登録手段によって前記プログラム情報記憶手段に登録された、前記登録依頼されたプログラムに対して、所定の登録済情報を付与する登録済情報付与手段：
また、前記支援装置は、前記登録済情報が付与されていないプログラムによって前記任意の制御装置のプログラムの更新を禁止する許可判定手段を有する。

本発明の制御システム、その管理サーバ、支援装置等によれば、制御装置のプログラムを作成させる支援装置と、このプログラムのプロジェクトを管理する管理サーバ装置を有する制御システムに関して、管理サーバ装置側で、制御装置側のプログラムを確実に管理できるようにする。

本例の制御システムの構成図である。 本例の制御システムの機能ブロック図である。 管理サーバにおける登録時の処理フローチャート図である。 管理サーバにおけるプログラム更新確認処理のフローチャート図である。 管理サーバにおけるプロジェクト再発行に係わる処理フローチャート図である。 管理サーバにおけるプログラム更新確認処理（オンライン）のフローチャート図である。 支援装置におけるコンパイル時の処理フローチャート図である。 支援装置におけるダウンロード時の処理フローチャート図である。 従来の制御システムの構成図である。

以下、図面を参照して、本発明の実施の形態について説明する。
図１は、本例の制御システムの構成図である。
本例の制御システムは、各ＰＬＣ（プログラマブルコントローラ）１、支援装置１０、管理サーバ３０等から成る。

尚、支援装置１０−管理サーバ３０間のデータのやりとりは、上記従来と同様に、ネットワークを介して通信するものであってもよいし、可搬型記憶媒体を介して行うものであってもよい。但し、本説明では、基本的に、ネットワークを介して支援装置１０−管理サーバ３０間でデータ送受信する構成を想定して説明するものとする。

尚、ＰＬＣ１は、制御装置の一例であり、この例に限らず、ＤＣＳ（分散制御システム: distributed control system）等であってもよい。
図１の構成では、支援装置１０は、任意のプロジェクト（その機械語オブジェクト）をＰＬＣ１にダウンロードする指示があった場合、少なくとも当該プロジェクトに更新情報ファイル２０が付与されていなければ、ダウンロードを許可しない。また、更新情報ファイル２０が付与されている場合でも、更新情報ファイル２０の内容に基づく所定の条件を満たさない場合には、ダウンロードを許可しないようにしてもよい。

任意のプロジェクトが管理サーバ３０に登録されたときに、管理サーバ３０によって当該プロジェクトに対して上記更新情報ファイル２０が付与される。管理サーバ３０は、例えば、任意の支援装置１０から登録依頼と共に任意のプロジェクトが送られてきた場合には、このプロジェクトを自装置内に登録すると共に、このプロジェクトに更新情報ファイル２０を付与して依頼元の支援装置１０に返信する。

尚、上述したように、従来より、ＰＬＣ用のプログラム（ソースコード、機械語オブジェクト）等を、まとめて、プロジェクトとして管理している。尚、これより、プロジェクトは、実体としては、単にＰＬＣ用のプログラムであると見做しても構わない。

また、支援装置１０において、ユーザが任意のプロジェクトを編集して更新版のプロジェクトが生成されたとき、更新情報ファイル２０が削除される。これは、ユーザが上記更新情報ファイル２０が付与されている任意のプロジェクトに基づいて、そのソースコードに対して所望の編集作業を行って任意の更新版のソースコードを作成すると、この更新版のソースコードをコンパイルして更新版の機械語オブジェクトを生成する。これは、編集作業によって、上記更新版ソースコード、更新版機械語オブジェクト等による新たな（更新版の）プロジェクトが生成されたものと見做してよい。

ここで、上記のように、編集元となる任意のプロジェクトには更新情報ファイル２０が付与されており、これに基づいて生成される上記更新版プロジェクトにもこれが引き継がれる形で更新情報ファイル２０が付与されている状態となっているので、更新情報ファイル２０を削除する。もし、更新情報ファイル２０を削除しないと、更新版プロジェクトは、管理サーバ３０に登録しなくても、ＰＬＣ１にダウンロード可能となるからである。

尚、更新情報ファイル２０を削除するタイミングは、例えば、上記更新版ソースコードが生成されたときではなく、上記更新版機械語オブジェクトが生成されたときとする。ＰＬＣ１にダウンロードするのは機械語オブジェクトであるので、更新版機械語オブジェクト生成前であれば、ダウンロード可能であっても特に問題ないと考えられるからである。但し、これは一例であり、この例に限らない。

上述したようにして、新たな更新版プロジェクトが生成されたときには、当該更新版プロジェクトには更新情報ファイル２０が付与されていない状態となっていることになる。
尚、図示の「編集」（上記編集作業）にはコンパイル処理まで含まれているものとするが、この例に限らない。

更新情報ファイル２０が付与されていない状態のプロジェクト（その機械語オブジェクト）を、コントローラ（ＰＬＣ１）にダウンロードする指示／命令等があっても、支援装置１０は許可しない。

この為、ユーザは、例えば従来と同様に手作業によって、上記生成された更新版プロジェクトを、管理サーバ３０に登録する。管理サーバ３０は、任意のプロジェクトの登録依頼がある毎に、このプロジェクト自体（ソースコードや機械語オブジェクトなど）を、プロジェクト管理情報テーブル４０に登録する。更に、このプロジェクトに関する所定の情報も一緒にプロジェクト管理情報テーブル４０に登録する。そして、上記登録依頼されたプロジェクトに、更新情報ファイル２０を付与する。

これによって、管理サーバ３０によって例えば上記更新版プロジェクトに更新情報ファイル２０が付与されることになるので、今度は、支援装置１０は、更新版プロジェクト（その機械語オブジェクト）をＰＬＣ１にダウンロードすることを許可する。

これによって、管理サーバ３０へのプロジェクト登録自体は、従来と同様にユーザが手作業で行うものであっても、ユーザが登録を忘れた場合にはコントローラへのプログラムダウンロードは許可されない。よって、ユーザが更新版プロジェクトを管理サーバ３０へ登録し忘れることで、例えば「コントローラには更新版プロジェクトが保持されているが、管理サーバ３０側では旧版プロジェクトで管理される」等といった事態は、起こらないようにできる。換言すれば、ユーザによるミス（登録忘れ等）があっても、確実に、ＰＬＣ１で現在記憶・運用されているプログラムが、管理サーバ３０側で保持・管理されている状態とすることができる。

上記図１の制御システムについて、以下、更に詳細に説明する。
上記管理サーバ３０では、例えば施設に導入しているコントローラ（ＰＬＣ１）毎に対応するプロジェクトの管理を行う。特に、自装置に登録されたプロジェクトに対しては更新情報ファイル２０を付与する処理を行う。

支援装置１０は、コントローラのプログラム更新（ダウンロード）が行われる際に、対象となるプロジェクトにおける更新情報ファイル２０の有無やその内容に基づいて、プログラム更新（ダウンロード）の可否を判断する。

また、管理サーバ３０は、コントローラにおけるプログラム更新状況を把握する。本手法では、任意のプロジェクトに関して「管理サーバ３０に登録→更新情報ファイル２０付与→コントローラにダウンロード」という手順になるので、そのままでは管理サーバ３０側では、自己に登録されたプロジェクトが、更新情報ファイル２０付与後に本当にコントローラにダウンロードされているのか（コントローラのプログラム更新されているのか）、分からない。

これより、管理サーバ３０は、コントローラとのオンライン環境が構築できる場合には、例えば後述する図６の処理によって、ネットワークを介してコントローラのプログラムの更新状況を監視することで、プログラム更新されたか否かを判定する。尚、この場合には、支援装置１０が、後述する図８の処理によって、プログラム更新の際に「プロジェクト識別子」をコントローラ内に書込む必要がある。

また、管理サーバ３０は、オンライン環境が構築できない場合には、例えば後述する図４の処理によって、コントローラのプログラムの更新状況を把握する。この処理例では、コントローラのプログラム更新に伴って支援装置１０側でこのプロジェクトの更新情報ファイル２０のステータス２３を「完了」に更新しておく。その後、作業員等が、この更新情報ファイル２０付プロジェクトを可搬型記憶媒体（ＵＳＢメモリ等）に格納して管理サーバ３０に持ち帰って、この可搬型記憶媒体を管理サーバ３０に差し込む。これによって、管理サーバ３０が、可搬型記憶媒体の記憶データを参照しつつ例えば後述する図４の処理を実行することで、コントローラのプログラム更新状況を把握する。図４の処理が行われることで、後述するように、プロジェクト管理情報４０のステータス４５が「完了」に更新されることになる。

以下に、具体的な流れを説明する。
管理サーバ３０側では、導入時などに管理対象となるコントローラとそれを特定するための情報を、プロジェクト管理情報４０の識別子４３に予め設定しておく（本例では、ID1、ID2、…、IDn）。また、ＰＬＣ４１は、単なるシリアル番号（１，２，３・・・）であるので、これも予め設定されている。

次に、支援装置１０において、任意のコントローラのプログラム（プロジェクト）が作成され、コントローラにダウンロードする準備できると、そのプロジェクトを管理サーバ３０に登録させるように依頼する。その際、ダウンロード対象となるコントローラが指定される。管理サーバ３０は、登録依頼されたプロジェクトを、プロジェクト管理情報４０において上記指定されたコントローラに対応するレコードにおけるプロジェクト４２の欄に、上書き登録する。尚、図１の例では、例えば識別子４３＝‘ＩＤ１’のコントローラに関しては、“プロジェクト識別子＝PID1”のプロジェクトが登録された状態を示している。

管理サーバ３０におけるプロジェクト管理情報４０への登録処理では、指定されたコントローラに対応するプロジェクトを格納するだけでなく、プログラム更新に必要な情報の設定を行う。これは、例えば、有効期間４４、プロジェクト識別子４６、ステータス４５等を設定する。

有効期間４４は、登録されたプロジェクトによりコントローラのプログラム更新を行える期間を表し、例えば依頼元の支援装置１０のユーザが任意に指定する（本例では、2014/09/01〜2014/09/30）。

また、管理サーバ３０は、プロジェクト識別用の固有のＩＤを任意に自動生成し、プロジェクトを特定する情報として“プロジェクト識別子４６”に設定する（本例では、PID1）。更に、管理サーバ３０は、プログラム更新の状況を示す“ステータス４５”に、当該登録時には「更新中」を設定する。そして、これらの設定情報を更新情報ファイル２０として登録対象のプロジェクトに付与して、当該更新情報ファイル２０付きプロジェクトを、依頼元の支援装置１０に返信する。

支援装置１０側では、更新情報ファイル２０の有無だけでなく、これらの設定情報も用いて、コントローラへのプログラムのダウンロードの可否（コントローラのプログラム更新の可否）を判定するようにしてもよい。この例に限らないが、少なくとも更新情報ファイル２０が無ければ、ダウンロードは許可しない。

また、管理サーバ３０に登録済のプロジェクトを後から取得することもできる。その場合、指定されたコントローラに対応するプロジェクト４２を、所定の記憶領域にコピーするとともに、“ステータス”４５が更新中であれば、登録時と同様にプロジェクト管理情報４０から更新情報ファイル２０を作成して、上記所定の記憶領域のプロジェクトに付与する。支援装置１０は、上記所定の記憶領域のプロジェクトを取得する。この処理の一例が、後述する図５の処理である。

支援装置１０では、管理サーバ３０に登録したプロジェクト（登録直後、あるいは上記後から取得）は、基本的には、コントローラにダウンロード可能となるが、必ずしもダウンロード許可されるとは限らない。例えば有効期限などの条件も満たさなければ、ダウンロード許可されないという実施例もあってよい。支援装置１０では、更新情報ファイル２０に基づいてダウンロードの許可／不許可を判定して、許可すると判定した場合にはコントローラのプログラム更新（ダウンロード）を行う。支援装置１０は、基本的には、プロジェクトに更新情報ファイル２０が付与されている場合には、管理サーバ３０に登録済みのプロジェクトであると認識して、プログラム更新（ダウンロード）を許可するが、上記の通り、この例に限らない。許可される為には、更に他の条件（有効期限など）も満たさなければならないという実施例が一例としてあってもよい。

ここで、支援装置１０において、上記更新情報ファイル２０が付与されたプロジェクトに基づいて更新版のプロジェクトが作成された場合、そのままでは更新版プロジェクトにも更新情報ファイル２０が付与された状態となる。この為、この更新版プロジェクトは、管理サーバ３０に登録しなくても、コントローラへのダウンロードが許可されてしまう可能性がある。この様な事態を避ける為に、上記プロジェクトの編集の際に（例えばコンパイル実行完了時に）、更新情報ファイル２０を削除するようにする。

図１に示す例では、図示の“Prj01”のプロジェクトを編集して図示の“Prj01’”のプロジェクトが作成されるが、上記処理によって、“Prj01”のプロジェクトに付与されていた更新情報ファイル２０が、引き続き“Prj01’”のプロジェクトにも付与されている状況となることは防止できる。よって、このままの状態では、“Prj01’”のプロジェクトは、コントローラにダウンロードできない。勿論、これは、別プロジェクト（図示の“PrjXX”）についても同様である。

このように、管理サーバ３０に登録され、且つ、変更されていないプロジェクトによってのみ、コントローラのプログラム更新が行えるようにすることができる。
尚、管理サーバ３０におけるコントローラのプログラム更新状況の管理ついては、既に述べたように、オンライン環境においては、コントローラに書込まれる「プロジェクト識別子」を管理サーバ３０から監視することによって、プログラムの更新状況を判別する。尚、プロジェクト識別子は、各プロジェクトを識別するための、ユニークな識別情報である。これは、任意のプロジェクトのプロジェクト識別子と、このプロジェクトの更新版のプロジェクトのプロジェクト識別子とが、異なるようにする。勿論、別のプロジェクトに関しては言うまでもない。

一方、上述したように、オフライン環境においては、管理サーバ３０から持ち出した更新情報ファイル２０付きプロジェクトを、支援装置１０においてコントローラにダウンロードしてプログラム更新完了した後に、管理サーバ３０に持ち帰る。但し、支援装置１０は、プログラム更新完了した場合には、このプロジェクトの更新情報ファイル２０のステータス２３を、「更新中」から「完了」に変更する処理を行っている。これより、管理サーバ３０は、このプロジェクトに付与されている更新情報ファイル２０の“ステータス２３”が「完了」となっているか否かによって、プログラムの更新状況を判別する。

以上により、管理サーバ３０に登録したプロジェクトで確実にコントローラのプログラム更新を行い、且つ、その更新状況を含めて管理することができる。
図２は、上記制御システムの機能ブロック図である。

図示の例では、上記管理サーバ３０は、プログラム情報記憶部５１、登録部５２、登録済情報付与部５３、プログラム更新監視部５４等の各種処理機能部を有する。
尚、管理サーバ３０は、ハードウェア的には一般的なサーバ装置の構成を有するものであってよく、例えば不図示のＣＰＵ、ハードディスク、メモリ等の記憶部、通信機能部等を有している。上記記憶部には、予め所定のアプリケーションプログラムが記憶されている。上記ＣＰＵがこのアプリケーションプログラムを実行することで、上記各種処理機能部５１，５２，５３，５４等が実現される。

支援装置１０は、編集部６１、許可判定部６２等を有する。
尚、支援装置１０も、ハードウェア的には一般的なパソコン等の構成を有するものであってよく、例えば不図示のＣＰＵ、ハードディスク、メモリ等の記憶部、通信機能部等を有している。上記記憶部には、予め所定のアプリケーションプログラムが記憶されている。上記ＣＰＵがこのアプリケーションプログラムを実行することで、上記各種処理機能部６１，６２等が実現される。

上記プログラム情報記憶部５１には、各制御装置（ＰＬＣ１等）毎に対応付けてプログラム（プロジェクト）が登録される。プログラム情報記憶部５１の一例は、上記プロジェクト管理情報テーブル４０等である。尚、上記プログラム情報記憶部５１に登録されるプロジェクトは、ソースコード、機械語オブジェクト等のプログラムであると言える。

登録部５２は、支援装置１０において任意に作成／編集された任意の制御装置のプログラム（プロジェクト）の登録依頼があると、プログラム情報記憶部５１における該任意の制御装置に対応するプログラムとして、該登録依頼されたプログラムを記憶する。

登録済情報付与部５３は、該登録部５２によってプログラム情報記憶部５１に登録された、上記登録依頼されたプログラムに対して、所定の登録済情報を付与する。登録済情報の一例が、図１に示す更新情報ファイル２０である。

上記支援装置１０の許可判定部６２は、上記登録済情報が付与されていないプログラムによって任意の制御装置のプログラムを更新することは、許可しない。これは、一例としては、このプログラムを制御装置にダウンロードすることを許可しないものである。

ダウンロードを許可しないことで、制御装置のプログラム更新が許可されないことになる。換言すれば、ダウンロードを許可しないことで、制御装置のプログラムの更新を禁止することになる。

制御装置のプログラム更新が許可されるようにする為には、上記任意に作成／編集された任意の制御装置のプログラム（プロジェクト）を、管理サーバ３０に登録して、管理サーバ３０によって上記登録済情報を付与してもらう必要がある。つまり、管理サーバ３０に登録済みのプログラムによって、制御装置側の保持プログラムが更新されることになる。つまり、確実に、制御装置側で現在保持・運用しているプログラムが、管理サーバ３０側に登録された状態とすることができる。これは、管理サーバ３０側で、制御装置側のプログラムを確実に管理できるものと言うことができる。

但し、上記登録済情報が付与されていても、プログラムを制御装置にダウンロードすることを許可しない場合もあり得る。
すなわち、許可判定部６２は、上記登録済情報が付与されているプログラムであっても、該登録済情報に基づいて所定の条件を満たすか否かを判定して、該条件を満たさない場合には、該プログラムによって任意の制御装置のプログラムを更新することを許可しない（プログラムの更新を禁止する）。

これは、例えば、上記登録済情報には有効期限が含まれており、許可判定部６２は、現在日時が該有効期限内ではない場合には、所定の条件を満たさないと判定し、以ってプログラムを制御装置にダウンロードすることを許可しない。

また、例えば、管理サーバ３０の上記プログラム更新監視部５４は、上記登録済情報が付与されたプログラムによって上記任意の制御装置のプログラム更新が行われたか否かを確認する。これは、例えば、下記のように、プログラム識別情報を用いて確認する。

すなわち、まず、管理サーバ３０の登録部５２は、上記登録依頼されたプログラムをプログラム情報記憶部５１に記憶する際に該プログラムに対応するユニークなプログラム識別情報を任意に生成して一緒に記憶する。また、登録済情報付与部５３は、該プログラム識別情報を上記登録済情報に含める。

また、支援装置１０は、上記登録済情報付きのプログラムによって制御装置のプログラムを更新完了した場合には、該登録済情報に含まれるプログラム識別情報を該制御装置に記憶させる、不図示のプログラム更新部を有する。

これより、管理サーバ３０の上記プログラム更新監視部５４は、プログラム情報記憶部５１に記憶したプログラム識別情報が、該制御装置に記憶されているプログラム識別情報と一致する場合には、上記登録済情報が付与されたプログラムによって上記任意の制御装置のプログラム更新が行われたと判定する。尚、管理サーバ３０は、上記制御装置に記憶されているプログラム識別情報を、例えばＰＬＣ用のネットワークを介して取得する。

また、例えば、上記登録済情報付与部５３は、上記登録済情報を付与したプログラムを、登録依頼元の支援装置１０に配信する。
また、支援装置１０は、任意の制御装置のプログラムを任意に作成／編集させる上記編集部６１を更に有するものであってもよい。

該編集部６１は、例えば、管理サーバ３０に登録されているプログラムを取得して、該取得したプログラムに基づいて任意の編集をユーザに行わせることで任意の更新版プログラムを作成させ、管理サーバ３０に対して該更新版プログラムの登録依頼を行う。

管理サーバ３０では、例えば、上記登録部５２によって該登録依頼された更新版プログラムを上記プログラム情報記憶部５１に記憶すると共に、上記登録済情報付与部５３によって該更新版プログラムに上記登録済情報を付与する。

以下、管理サーバ側と支援装置側におけるそれぞれの処理について、フローチャート図を参照して説明する。
図３〜図６には、管理サーバ３０側における処理フローチャート図を示す。

まず、管理サーバ３０側の処理について、以下、概略的に説明する。
管理サーバ３０側では、プロジェクト登録の際には、プロジェクト管理情報テーブル４０に必要な情報を設定し、その情報を基に更新情報ファイル２０を作成して登録プロジェクトに付与する処理（図３）を行う。また、プロジェクト管理情報テーブル４０と、指定されたプロジェクト内の更新情報ファイル２０とにより、コントローラのプログラム更新が完了したか否かの判断を行う（図４）。

また、オンライン環境においては、管理しているコントローラの状況を監視し、プログラム更新が完了したか否かの判断を行う（図６）。
以下、まず、図３の処理について説明する。

図３は、管理サーバ３０における登録時の処理フローチャート図である。
図３の処理は、任意のユーザから任意のＰＬＣ１（プログラム更新対象ＰＬＣ）に関する任意のプロジェクトの登録依頼がある毎に、実行される。この依頼は、ユーザによって任意の支援装置１０からネットワークを介して行われるものであってもよいし、ユーザが、上記可搬型記憶媒体を用いたうえで、直接、管理サーバ３０を操作することで行ってもよい。但し、何れの場合でも、管理サーバ３０側には登録依頼されるプロジェクト（ソースコード、機械語オブジェクト等のプログラム一式など）が渡されて、図３の処理が実行されることになる。

図３の処理では、まず、プロジェクト管理情報テーブル４０において、ユーザから指定されたコントローラに対応するレコード（該当レコード）を特定する（ステップＳ１１）。そして、まず、ステップＳ１２の判定処理を実行する。ここで、プロジェクト管理情報テーブル４０のデータ項目について説明する。

プロジェクト管理情報テーブル４０は、図１に示す例では、ＰＬＣ番号４１、プロジェクト４２、識別子４３、有効期間４４、ステータス４５、プロジェクト識別子４６の各データ項目を有する。

ＰＬＣ番号４１は、プロジェクト管理情報テーブル４０において各コントローラを管理する為に用いられるシリアル番号等である。上記コントローラの指定には、例えば、このＰＬＣ番号が用いられるが、この例に限らない。ＰＬＣ番号４１は、初期状態で既に任意に登録されているものとする。

また、識別子４３は、ＰＬＣ番号４１のコントローラを特定できる情報であり、例えば製造番号や、ネットワーク上での識別用ＩＤである例えばＭＡＣアドレス等である。この識別子４３も、上記ＰＬＣ番号４１と同様に、予め全てのＰＬＣ１について登録されているものであってもよい。

プロジェクト４２には、ＰＬＣ番号４１（識別子４３）のＰＬＣ１に現在保持されているはずのプロジェクトが、登録されている。尚、実際には、各ＰＬＣ１には、プロジェクトの全データではなく、その機械語オブジェクトが保持される（少なくともソースコードが保持されない）。一方、プロジェクト４２には、例えば上記ソースコード、機械語オブジェクト等が含まれるフォルダ等が、登録される。尚、初期状態では、プロジェクト４２には何も登録されていない。また、登録更新が行われる毎に、それまでプロジェクト４２に登録されていた旧プロジェクトは、消去される。

また、プロジェクト識別子４６には、プロジェクト４２に登録されているプロジェクトの識別用ＩＤ等が、格納される。尚、上述したように、任意のプロジェクトの更新版のプロジェクトには新たな、プロジェクト識別子が割当てられる。

有効期間４４には、プロジェクト４２に登録されているプロジェクトの有効期間が登録される。有効期間４４は、例えばプログラム更新をスケジューリングするためのものである。つまり、有効期間外である場合、そのプロジェクトによってコントローラのプログラム更新を行うことはできない。

ステータス４５には、コントローラのプロジェクト更新に係わる現状が格納されるものであり、プログラム更新の状況を示すものであり、本例では「更新中」と「完了」の何れか一方が格納される。後述するように、管理サーバ３０側で、プロジェクト４２に登録されているプロジェクトによってコントローラのプログラム更新が行われたことを確認できた場合に、ステータス４５は「完了」となる。詳しくは後述する。

ステップＳ１２では、上記該当レコードの上記ステータス４５が「更新中」であるか否かを判定する。もし、「更新中」であれば（ステップＳ１２，ＹＥＳ）、それは基本的には他ユーザが更新作業中であることを意味しているので、何も行わずに本処理を終了する。

一方、上記該当レコードの上記ステータス４５が「更新中」ではない場合には（ステップＳ１２，ＮＯ）、まず、上記該当レコードの上記ステータス４５を「更新中」に変更する（ステップＳ１３）。

続いて、ユニークなプロジェクト識別子を任意に生成して、これを上記該当レコードの上記プロジェクト識別子４６に格納する（ステップＳ１４）。更に、ユーザに、任意の有効期間を設定させて、これを上記該当レコードの上記有効期間４４に格納する（ステップＳ１５）。

その後、上記該当レコードの識別子４３、有効期間４４、ステータス４５、プロジェクト識別子４６を用いて、上記登録依頼されたプロジェクトに応じた更新情報ファイル２０を生成する（ステップＳ１６）。

尚、上記ステップＳ１４によるプロジェクト識別子は、図３の処理が実行される毎にユニークなものが生成されるので、例えば図１に示す“Prj01”のプロジェクトに対して生成されるプロジェクト識別子と、その更新版である“Prj01’”のプロジェクトに対して生成されるプロジェクト識別子とは、異なることになる。

ここで、更新情報ファイル２０は、例えば図１に示すように、識別子２１、有効期間２２、ステータス２３、プロジェクト識別子２４の各データ項目より成る。上記該当レコードの識別子４３、有効期間４４、ステータス４５、プロジェクト識別子４６を、そのまま、これら識別子２１、有効期間２２、ステータス２３、プロジェクト識別子２４とすることで、更新情報ファイル２０が生成される。

そして、上記登録依頼されたプロジェクトを上記該当レコードのプロジェクト４２の欄に格納すると共に、当該登録依頼されたプロジェクトに上記生成された更新情報ファイル２０を付与して、これをユーザに返す（ステップＳ１７）。例えば一例としては、上記任意の支援装置１０に対して上記ネットワークを介して、更新情報ファイル２０付きの上記登録依頼されたプロジェクトが、返信される。

上述したことから、上記任意の支援装置１０は、プログラム更新対象ＰＬＣに対する上記更新情報ファイル２０付プロジェクト（その機械語オブジェクト）のダウンロードを、基本的には許可することになる。但し、上記の通り、有効期限などの条件を満たさない場合には、許可されない。

この様な支援装置１０におけるダウンロード処理に係わる処理については、図８に示し後に説明するが、それによってＰＬＣ１のプログラム（機械語オブジェクト）の更新に成功した場合、支援装置１０によって、上記更新情報ファイル２０付プロジェクトにおけるステータス２３は、「更新中」から「完了」に変更されている。

その後、支援装置１０は、この更新情報ファイル２０付プロジェクトと共に更新完了通知を管理サーバ３０に通知する。その際、更新対象コントローラが指定される。これを受信した管理サーバ３０は、図４の処理を実行する。但し、この例に限らず、例えばユーザが、この更新情報ファイル２０付プロジェクトを、可搬型記憶媒体（ＵＳＢメモリ等）を介して管理サーバ３０に渡すと、管理サーバ３０が図４の処理を実行するようにしてもよい。

以下、図４の処理について説明する。
図４は、管理サーバ３０におけるプログラム更新確認の為の処理のフローチャート図である。

図４の処理では、まず、上記ステップＳ１１と同様、プロジェクト管理情報テーブル４０において、指定されたコントローラに対応するレコード（該当レコード）を特定する（ステップＳ２１）。

そして、該当レコードのステータス４５が「更新中」であるか否かを判定する（ステップＳ２２）。ステータス４５が「完了」である場合には（ステップＳ２２，ＮＯ）、そのまま本処理を終了する。

ステータス４５が「更新中」であることを確認したら（ステップＳ２２，ＹＥＳ）、上記通知された更新情報ファイル２０付プロジェクトに、更新情報ファイル２０が存在するか否かを判定する（ステップＳ２３）。尚、これは、確認的な意味の処理であり、ユーザは更新情報ファイル２０付プロジェクトを通知したつもりであったが、実際には何等かの理由で更新情報ファイル２０が無いプロジェクトが通知されてくる場合を想定して、この様な場合にはステップＳ２３の判定がＮＯとなり、そのまま本処理を終了する。

処理対象プロジェクトに更新情報ファイル２０が付いている場合には（ステップＳ２３，ＹＥＳ）、この更新情報ファイル２０の識別子２１が、上記該当レコードの識別子４３と一致することを確認する（ステップＳ２４）。もし、識別子が不一致であれば（ステップＳ２４，ＮＯ）、そのまま本処理を終了する。

識別子が一致することを確認したら（ステップＳ２４，ＹＥＳ）、更新情報ファイル２０のステータス２３が「完了」であることを確認し（ステップＳ２５）、「完了」である場合には（ステップＳ２５，ＹＥＳ）上記該当レコードのステータス４５を上記「更新中」から「完了」に変更する（ステップＳ２６）。もし、ステータス２３が「更新中」であれば（ステップＳ２５，ＮＯ）、ステップＳ２６の処理は行わずに、本処理を終了する。

上記の通り、後述する図８の処理によって、ＰＬＣ１のプログラム更新が正常に完了している場合には、ステータス２３は「完了」となっているはずであり、ステップＳ２６の処理が実行されることになる。

そして、本例では、最後に、管理サーバ３０は、支援装置１０における更新情報ファイル２０付プロジェクトから、更新情報ファイル２０を削除する（ステップＳ２７）。これによって、その後、このプロジェクトを編集して更新版プロジェクトを作成する場合、当該更新版プロジェクトも当然、更新情報ファイル２０が無い状態である。よって、この例では、コンパイル時に更新版プロジェクトから更新情報ファイル２０を削除する必要はなくなる。何れにしても、編集によって新たに生成された更新版プロジェクトを、そのままＰＬＣ１にダウンロードしようとしても、許可されないようにしている点では、同様である。

尚、言うまでも無いが、例えば図１に示す別プロジェクトを、コントローラにダウンロードしてプログラム更新しようとしても、当然、許可されない。
支援装置１０は、上記図３の処理によって管理サーバ３０から更新情報ファイル２０付プロジェクトを得るが、後述する図８の処理によってＰＬＣ１のプログラム更新を実現する前に、更新情報ファイル２０付プロジェクトを紛失等する場合が想定される。この様な場合、本例では、支援装置１０は、管理サーバ３０に要求して、再び同じ更新情報ファイル２０付プロジェクトを得ることができる。その際の管理サーバ３０の処理が、図５に示す処理である。

以下、図５の処理について説明する。
図５は、管理サーバ３０のプロジェクト再発行に係わる処理フローチャート図である。
管理サーバ３０は、支援装置１０から任意に指定されたＰＬＣ１の更新情報ファイル２０付プロジェクトの再発行要求があると、まず、上記ステップＳ１１と同様、プロジェクト管理情報テーブル４０において、指定されたコントローラに対応するレコード（該当レコード）を特定する（ステップＳ３１）。

そして、まず、この該当レコードのプロジェクト４２の欄に格納されているプロジェクト（フォルダ）を、所定の記憶領域にコピーする（ステップＳ３２）。
続いて、該当レコードのステータス４５が「更新中」であるか否かを判定し（ステップＳ３３）、「完了」である場合には（ステップＳ３３，ＮＯ）、ステップＳ３４、Ｓ３５の処理を行わずに、本処理を終了する。上記の通り、本処理は、未だコントローラのプログラム更新が行われていない状況を想定しているので、プログラム更新が完了している状況であれば更新情報ファイル２０付プロジェクトの再発行は許可しないようにする。

該当レコードのステータス４５が「更新中」である場合には（ステップＳ３３，ＹＥＳ）、まず、上記ステップＳ１６と同様の処理を行って更新情報ファイル２０を生成する（ステップＳ３４）。そして、生成した更新情報ファイル２０を、上記ステップＳ３２で所定の記憶領域にコピーしたプロジェクトに付与する（ステップＳ３５）。

その後、支援装置１０は、上記所定の記憶領域から、上記更新情報ファイル２０が付与されたプロジェクトを取得する。そして、これを用いて、ＰＬＣ１のプログラム更新を試みることになる。

尚、図５の処理は、更新情報ファイル２０付プロジェクトの再発行の為の処理であるが、上述したように、従来より、支援装置側では、管理サーバから、当該管理サーバに登録されているプロジェクト（特に、現在、コントローラが保持しているはずの機械語オブジェクトに対応するソースコード）を取得して、当該取得したプロジェクトをユーザが任意に編集して更新版プロジェクトが作成される。この様な場合の管理サーバ３０から登録プロジェクトを取得する処理は、図５とは異なるが、これについては上記の通り従来より行われていることであり、ここでは特にフローチャート図等は示さずに以下に簡単に説明するだけとする。

すなわち、管理サーバ３０は、支援装置１０から任意のコントローラのプロジェクトの更新要求があると、プロジェクト管理情報テーブル４０から当該コントローラに対応付けられて登録されているプロジェクトを、支援装置１０に渡す。その際、更新情報ファイル２０は付与しない。従って、支援装置１０側では、渡されたプロジェクトの編集作業をユーザが任意に行って更新版プロジェクトが作成されるが、そのままでは更新版プロジェクトはコントローラにダウンロードできない。これより、コントローラのプログラム更新の為には、図３の処理が行われて更新情報ファイル２０が付与される必要が生じることになる。

また、管理サーバ３０において、コントローラのプログラム更新を認識してステータス４５を「更新中」から「完了」に変更する処理は、上記図４の例に限らず、例えば図６に示す処理であっても構わない。

但し、図６の処理は、管理サーバ３０が、例えばＰＬＣ用のネットワーク等に接続して各ＰＬＣ１と通信可能な構成となっていることが、前提となる。尚、ＰＬＣ用ネットワークは、よく知られているように、複数のＰＬＣ１が接続して相互にデータ送受信する低速ネットワーク等である。

また、後述するように、図８の処理において後述するステップＳ６８の処理は、必須ではないが、図６の処理が行われる場合には必須である。よって、この場合には、コントローラ（ＰＬＣ１）のプログラム更新が完了している場合には、このコントローラには更新版プログラムのプログジェクト識別子が記憶されていることになる。

図６の処理では、管理サーバ３０は、プロジェクト管理情報テーブル４０における任意のレコードを処理対象として（ステップＳ４１）、当該処理対象レコードのステータス４５が、「更新中」であるか否かをチェックする（ステップＳ４２）。もし、ステータス４５が「完了」であれば（ステップＳ４２，ＮＯ）、そのまま本処理を終了する。

ステータス４５が「更新中」であれば（ステップＳ４２，ＹＥＳ）、当該処理対象レコードの識別子４３（ＭＡＣアドレスなど）を用いて処理対象のコントローラにアクセスして、このコントローラが記憶するプログジェクト識別子を読み出す（ステップＳ４３）。上記の通り、このコントローラのプログラム更新済みであるならば、読み出したプログジェクト識別子は、登録されているプロジェクトのプログジェクト識別子と同じであるはずである。これより、ステップＳ４３で読み出したプログジェクト識別子が、処理対象レコードのプログジェクト識別子４６と一致するか否かを確認する（ステップＳ４４）。そして、一致する場合には（ステップＳ４４，ＹＥＳ）、登録されているプロジェクトによってコントローラのプログラムが更新されていると見做して、処理対象レコードのステータス４５を、「更新中」から「完了」に変更する（ステップＳ４５）。

不一致であれば（ステップＳ４４，ＮＯ）、ステップＳ４５の処理は行わずに、本処理を終了する。尚、この場合、ステップＳ４３で読み出したコントローラ側のプログジェクト識別子は、基本的に、旧プロジェクトのプログジェクト識別子であるはずである。これは、未だ、登録されているプロジェクト（更新版プロジェクト）によるコントローラのプログラム更新が成されていない状況であると考えられる為、コントローラには旧バージョンのプログラムが格納されていると考えられるからである。

次に、以下、図７、図８を参照して、支援装置１０の処理について説明する。
図７は、支援装置１０のコンパイル時の処理フローチャート図である。
例えば、上記のように、支援装置１０において、ユーザが、既存のプロジェクトを編集して、その更新版のプロジェクトを作成する場合がある。これは、ユーザは、プロジェクトのソースコードの更新版を作成し、支援装置１０がこのソースコードをコンパイルして機械語オブジェクトに変換することで、更新版のプロジェクトが作成される。その際、既存のプロジェクトに付与されていた更新情報ファイル２０が、そのまま、更新版のプロジェクトに引き継がれるのを防止する為に、更新情報ファイル２０を削除する。この様なコンパイル処理の一例が、図７に示す処理である。

図７の処理では、上記更新版のプロジェクトのソースコードのコンパイルを行う（ステップＳ５１）。そして、コンパイル成功した場合（ステップＳ５２、ＹＥＳ）、上記更新版のプロジェクトに更新情報ファイル２０が存在する場合には（ステップＳ５３，ＹＥＳ）、この更新情報ファイル２０を削除する（ステップＳ５４）。

尚、上記ステップＳ２７の処理が行われる例の場合には、既存のプロジェクトに更新情報ファイル２０が無いことになり、当然、更新版のプロジェクトにも更新情報ファイル２０は無いことになるので、ステップＳ５３に判定はＮＯとなり、そのまま本処理を終了することになる。尚、上記ステップＳ２７の処理が行われる例の場合には、ステップＳ５３，Ｓ５４の処理は、必ずしも必要ないことになる。

また、尚、コンパイル失敗した場合には（ステップＳ５２，ＮＯ）、そのまま本処理を終了する。
図８は、支援装置１０におけるダウンロード時の処理フローチャート図である。

支援装置１０は、上記作成された更新版のプロジェクトに対して、上記図３の処理によって更新情報ファイル２０が付与された後、任意のときに、この更新版プロジェクト（その機械語オブジェクト）を、対象となるＰＬＣ１にダウンロードして、当該ＰＬＣ１のプログラムを更新させる。このような処理の一例を、図８に示す。

図８の処理では、まず、対象のコントローラ（ＰＬＣ１）から、その識別子（ＭＡＣアドレス）を読み出し（ステップＳ６１）、この識別子が、上記更新版プロジェクトに付与されている更新情報ファイル２０の識別子２１と、一致するか否かを判定する（ステップＳ６２）。そして、不一致の場合には（ステップＳ６２，ＮＯ）ステップＳ６６へ移行する。尚、この場合には、当然、プログラム更新が行われないことになるので、ステップＳ６６の判定はＮＯとなり、以って本処理を終了することになる。

基本的には、更新版プロジェクトに更新情報ファイル２０が付与されていない場合に、ステップＳ６２の判定がＮＯとなり、プログラム更新が行われないことになる。これは、つまり、更新版プロジェクトに更新情報ファイル２０が付与されていないと、ダウンロード（ＰＬＣ１のプログラム更新）が許可されないことを意味することになる。

ステップＳ６２では、更に、コントローラの識別情報（図１の例では、ID1）と、対象プロジェクトの更新情報ファイル２０の“識別子２１”（図１の例では、ID1）とが一致することを確認することで、対象コントローラに係わるプロジェクトであることを確認する。これより、例えばユーザがダウンロード対象となるＰＬＣ１の指定を間違えた場合等にも、ステップＳ６２の判定はＮＯとなる。

更新版プロジェクトに更新情報ファイル２０が付与されている場合（更に、その識別子２１が、コントローラの識別子と一致する場合）（ステップＳ６２，ＹＥＳ）、続いて、コントローラから現在日時を読み出して（ステップＳ６３）、現在が更新情報ファイル２０の有効期間２２の期間内であるか否かをチェックする（ステップＳ６４）。有効期間内であれば（ステップＳ６４，ＹＥＳ）、上記更新版プロジェクト（その機械語オブジェクト）をコントローラにダウンロードして、そのプログラム更新を行わせる（ステップＳ６５）。

上記ステップＳ６４によって、現在が有効期間２２の期間内ではない場合には、プログラム更新を許可しない。これにより、プロジェクトの更新タイミングを制御することができる。尚、現在日時は、支援装置１０の時計機能から取得するようにしてもよい。

コントローラ側では、ダウンロードされた機械語オブジェクトによって、自己のプログラム更新を試みる。この処理自体は既存の処理であり、特に説明しない。そして、コントローラは、この処理結果として、プログラム更新の成功／失敗を支援装置１０に通知する。

支援装置１０は、プログラム更新成功した場合には（ステップＳ６６，ＹＥＳ）、更新情報ファイル２０のステータス２３を、「更新中」から「完了」に変更する（ステップＳ６７）。更に、更新情報ファイル２０のプロジェクト識別子２４を、コントローラの所定の記憶領域に書き込む（ステップＳ６８）。尚、上述したように、ステップＳ６８の処理は、必ずしも必要ないものである。

尚、プログラム更新失敗した場合には（ステップＳ６６，ＮＯ）、ステップＳ６７等の処理を行うことなく、本処理を終了する。
上述したように、本手法では、まず、支援装置１０は、更新情報ファイル２０が存在しないプロジェクトは、コントローラへダウンロードすることを許可しないようにしている。支援装置１０は、既存のプロジェクトがユーザによって編集されることで、更新版のプロジェクトが生成される場合に関して、少なくとも当該更新版のプロジェクトがコントローラにダウンロード可能な状態になった時点、すなわちコンパイル処理が実行されて機械語オブジェクトが生成済みである時点には、当該更新版のプロジェクトには更新情報ファイル２０が存在しないようにしている。その為の処理例として、上述した説明では２つの方法を提示しているが、これらの例に限らない。

このままでは、更新版プログラムをコントローラにダウンロード出来ず、以ってコントローラのプログラム更新が行えないことになる。これに対して、本例では、上記更新版のプロジェクトを、管理サーバ３０に登録すると、管理サーバ３０によって上記更新版のプロジェクトに更新情報ファイル２０が付与される。これより、支援装置１０は、この更新版のプロジェクトをコントローラにダウンロードすることを基本的には許可する状態となる。

但し、本例では、更新情報ファイル２０が存在してもダウンロードを許可しない場合がある。すなわち、上記ステップＳ６２やステップＳ６４の判定がＮＯの場合には、更新情報ファイル２０が存在してもダウンロードを許可しない。このように、ダウンロードの際には、更新情報ファイル２０の有無とその内容に基づいて、プログラム更新の可否を判断する。これは、少なくとも更新版プロジェクトが管理サーバ３０に登録されていないならば、プログラム更新は許可されない。よって、コントローラが保持するプログラムと、管理サーバ３０側で管理しているプログラムとが、異なる状況になるようなことはない。

尚、上記更新版のプロジェクトに限らず、図１に示す別プロジェクトであっても、管理サーバ３０に登録されて、以って更新情報ファイル２０が付与された場合には、コントローラへのダウンロードが許可されることになる。

本手法によると、プロジェクトを管理する管理サーバ３０で、施設内の各コントローラが現在保持・運用しているプロジェクトを確実に管理し、管理しているプロジェクトでプログラム更新を確実に行えると共に更新状況も把握可能なため、プロジェクト管理の効率化とユーザによる操作ミスの防止が期待できるという効果を有する。

また、プロジェクト管理情報に有効期限およびステータスの情報を設けることで、施設内全体のコントローラに対するプログラム更新のスケジューリングにより、確実に納期内の更新と管理をサポートし、更に、プロジェクトの紛失などで有効期限が切れた場合の再度、更新手続きをすることにより、プロジェクトの管理を徹底できる効果を有する。

１ ＰＬＣ
１０ 支援装置
２０ 更新情報ファイル
２１ 識別子
２２ 有効期間
２３ ステータス
２４ プロジェクト識別子
３０ 管理サーバ
４０ プロジェクト管理情報テーブル
４１ ＰＬＣ番号
４２ プロジェクト
４３ 識別子
４４ 有効期間
４５ ステータス
４６ プロジェクト識別子
５１ プログラム情報記憶部
５２ 登録部
５３ 登録済情報付与部
５４ プログラム更新監視部
６１ 編集部
６２ 許可判定部

Claims (10)

1. 制御装置と、該制御装置のプログラムが作成／編集される支援装置と、管理サーバ装置を有する制御システムであって、
   前記管理サーバ装置は、
   各制御装置毎に対応付けてプログラムが登録されるプログラム情報記憶手段と、
   前記支援装置において任意に作成／編集された任意の制御装置のプログラムの登録依頼があると、前記プログラム情報記憶手段における該任意の制御装置に対応するプログラムとして、該登録依頼されたプログラムを記憶する登録手段と、
   該登録手段によって前記プログラム情報記憶手段に登録された、前記登録依頼されたプログラムに対して、所定の登録済情報を付与する登録済情報付与手段とを有し、
   前記支援装置は、
   前記登録済情報が付与されていないプログラムによって前記任意の制御装置のプログラムの更新を禁止する許可判定手段を有することを特徴とする制御システム。
2. 前記許可判定手段は、前記登録済情報が付与されているプログラムであっても、該登録済情報に基づいて所定の条件を満たすか否かを判定して、該条件を満たさない場合には、該プログラムによって前記任意の制御装置のプログラムの更新を禁止することを特徴とする請求項１記載の制御システム。
3. 前記登録済情報には有効期限が含まれており、
   前記許可判定手段は、現在日時が該有効期限内ではない場合には、前記所定の条件を満たさないと判定することを特徴とする請求項２記載の制御システム。
4. 前記管理サーバ装置は、
   前記登録済情報が付与されたプログラムによって前記任意の制御装置のプログラム更新が行われたか否かを確認するプログラム更新監視手段を更に有することを特徴とする請求項１〜３の何れかに記載の制御システム。
5. 前記管理サーバ装置は、
   前記登録依頼されたプログラムを前記プログラム情報記憶手段に記憶する際に該プログラムに対応するユニークなプログラム識別情報を任意に生成して一緒に記憶すると共に、該プログラム識別情報を前記登録済情報に含め、
   前記支援装置は、
   前記登録済情報付プログラムによって前記制御装置のプログラムを更新完了した場合には、前記プログラム識別情報を該制御装置に記憶させ、
   前記管理サーバ装置の前記プログラム更新監視手段は、前記プログラム情報記憶手段に記憶したプログラム識別情報が、該制御装置に記憶されているプログラム識別情報と一致する場合には、前記登録済情報が付与されたプログラムによって前記任意の制御装置のプログラム更新が行われたと判定することを特徴とする請求項４記載の制御システム。
6. 前記登録済情報付与手段は、前記登録済情報を付与したプログラムを、前記登録依頼元の支援装置に配信することを特徴とする請求項１〜３の何れかに記載の制御システム。
7. 前記支援装置は、任意の制御装置のプログラムを任意に作成／編集させる編集手段を更に有し、
   該編集手段は、前記管理サーバ装置に登録されているプログラムを取得して、該取得したプログラムに基づいて任意の編集を行わせることで任意の更新版プログラムを作成させ、前記管理サーバに対して該更新版プログラムの前記登録依頼を行い、
   前記管理サーバ装置では、前記登録手段によって該登録依頼された更新版プログラムを前記プログラム情報記憶手段に記憶すると共に、前記登録済情報付与手段によって該更新版プログラムに前記登録済情報を付与することを特徴とする請求項１〜３の何れかに記載の制御システム。
8. 制御装置と、該制御装置のプログラムが作成／編集される支援装置と、管理サーバ装置を有する制御システムにおける該管理サーバ装置であって、
   各制御装置毎に対応付けてプログラムが登録されるプログラム情報記憶手段と、
   前記支援装置において任意に作成／編集された任意の制御装置のプログラムの登録依頼があると、前記プログラム情報記憶手段における該任意の制御装置に対応するプログラムとして、該登録依頼されたプログラムを記憶する登録手段と、
   該登録手段によって前記プログラム情報記憶手段に登録された、前記登録依頼されたプログラムに対して、所定の登録済情報を付与する登録済情報付与手段と、
   を有することを特徴とする制御システムの管理サーバ装置。
9. 制御装置と、該制御装置のプログラムが作成／編集される支援装置と、管理サーバ装置を有する制御システムにおける該支援装置であって、
   任意の制御装置のプログラムを任意に作成／編集させる編集手段と、
   登録済情報が付与されていないプログラムによって前記制御装置のプログラムの更新を禁止する許可判定手段と、
   を有することを特徴とする制御システムの支援装置。
10. 前記編集手段は、前記任意に作成／編集されたプログラムの登録依頼を前記管理サーバ装置に出すことで、該管理サーバ装置から、該登録依頼したプログラムに対して前記登録済情報が付与されて成る登録済情報付プログラムを取得することを特徴とする請求項９記載の制御システムの支援装置。