JP2013143072A

JP2013143072A - 起動装置及びネットワークシステム

Info

Publication number: JP2013143072A
Application number: JP2012003799A
Authority: JP
Inventors: Tatsuya Maruyama; 龍也丸山; Tsutomu Yamada; 山田　　勉; Hiromichi Endo; 浩通遠藤
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 2012-01-12
Filing date: 2012-01-12
Publication date: 2013-07-22
Anticipated expiration: 2032-01-12
Also published as: JP5762986B2

Abstract

【課題】定期的な保守を容易にし、かつ、開発を容易とするネットワークシステムを提供する。
【解決手段】第１の起動イメージを有する中央管理装置と接続され、停止状態からの立ち上げを行うための起動装置において、起動装置は第２の起動イメージを保有しており、停止状態からの立ち上げを行う時に中央管理装置との間で通信が確立しているときは中央管理装置が有する第１の起動イメージを入手して起動し、停止状態からの立ち上げを行う時に中央管理装置との間で通信が確立してないときは、自己が保有している第２の起動イメージで起動することを特徴とする。
【選択図】図３

Description

本発明は、複数の計算機が結合されて稼動するときに停止状態から立ち上げるための起動装置及びネットワークシステムに係り、特に計算機における各種の更新を簡便、正確、迅速に行なうことに関する。

近年では、多くの計算機がネットワークに結合されて稼動するネットワークシステムに組み込まれている。係る構成は、一般の家庭用、事務用計算機ばかりでなく、産業用などにも広く採用されている。これらの計算機の中には、稼働率確保のために停止することが許されず、停止したとしても極力短時間での復旧が望まれる場合がある。

例えば産業システムにおける製造装置に使用される計算機およびネットワークシステムでは、その付加価値を高めるために稼働率を向上させることが求められている。稼働率を低下させる原因はさまざまであるが、その一つとして、計算機などに対する定期保守によるシステムの停止が挙げられる。

例えば、新機能を搭載したアプリケーションへの交換、セキュリティパッチの適用、オペレーティングシステム（以下、ＯＳとする）のバージョンアップ等の理由により、製造装置は定期的に停止され、ソフトウェアの更新処理がなされる。産業システムにおける製造装置に使用される計算機は、専用計算機により構成される場合もあるが、多くの場合には汎用計算機を使用することが多いので、上記のようなソフトウェアの更新処理が避けられない状態にある。

このことはシステム全体から見れば、製造装置を停止し、ソフトウェアの更新を実施し、システムを再起動する間、その製造装置は付加価値を生み出すことができず、デッドタイムとみなされる。特に、対象とする製造装置が複雑化、大規模化すれば、それだけ定期保守を実施する計算機台数が増加し、システムの稼働率は低下する。

これらの課題に関して特許文献１では、半導体製造装置を例に、サーバ上に予めバージョンアップ時の新規パラメータ等を登録しておき、バージョンアップ後にサーバから、対象の半導体製造装置（露光装置等）にパラメータを転送、設定することで、更新処理を容易にする発明が開示されている。

また、定期保守を容易にする対策方法としてネットワークブート方式が挙げられる。ネットワークブート方式では、計算機はネットワーク経由でＯＳやファイルシステム、アプリケーションといった起動時に必要なファイル（以下、起動イメージとする）を取得して起動する。

一般的に、ネットワークブート方式を実現するためにはＰＸＥ（プレブート実行環境：ＰｒｅｂｏｏｔｅＸｅｃｕｔｉｏｎＥｎｖｉｒｏｎｍｅｎｔ）規格に準拠したサーバと、ＰＸＥ規格に対応したＮＩＣ（ネットワークカード：ＮｅｔｗｏｒｋＩｎｔｅｒｆａｃｅＣａｒｄ）の両方が必要である。

ＰＸＥ規格対応サーバ（以下、ブートサーバとする）は、ＰＸＥクライアントにＩＰアドレスを割り当てるためのＤＨＣＰ（動的ホスト構成プロトコル：ＤｙｎａｍｉｃＨｏｓｔＣｏｎｆｉｇｕｒａｔｉｏｎＰｒｏｔｏｃｏｌ）サーバとＰＸＥクライアントに起動イメージを転送するためのＴＦＴＰ（ＴｒｉｖｉａｌＦｉｌｅＴｒａｎｓｆｅｒＰｒｏｔｏｃｏｌ）サーバを稼働させる必要がある。

ＰＸＥクライアントは、はじめにブートサーバにアクセスし、ＤＨＣＰによってＩＰアドレスを取得する。次に、ＰＸＥクライアントはブートサーバにアクセスし、ＴＦＴＰによって起動イメージを取得する。起動イメージの取得後、制御を起動イメージに制御を移し、起動する。

ネットワークブートの利点は、特に、複数のクライアントを管理する場合に現れる。すなわち、起動イメージをＰＸＥサーバ単体で管理できるため、クライアントごとにセキュリティパッチの適用、オペレーティングシステム（以下、ＯＳとする）のバージョンアップ等をする必要がないことである。

この効果により、管理コストを大幅に低減することができる。

特開２０００−１８８２５２号公報

しかしながら、ネットワークブート方式の導入は管理を集中して、定期保守を迅速に、かつ、容易にすることで稼働率を向上させる一方、開発時にかえって開発工数が増加するという課題がある。

特許文献１に示す方法は、開発完了時に、サブシステムのパラメータを中央管理装置に登録しなければならない。対象とする制御装置が大規模で、個別のサブシステムごとにパラメータが異なる場合は、サブシステムの数だけ中央管理装置にパラメータを登録しなければならない。これは例えば、サブシステム個々の開発物（アプリケーション、デバイスドライバ等）をサブシステムの数だけ、中央管理装置に登録しなければならないことを意味する。

また、ネットワークブート方式の課題は、サブシステムの開発時に中央管理装置（ブートサーバ）を必要とすることである。これにより、サブシステムの開発者、あるいは開発チームは中央管理装置の操作方法に精通していなければならず、要求する技術水準が高まる。場合によっては、中央管理装置の開発者を必要とする。

また、中央管理装置とは異なる別々の開発者、開発チームがサブシステムを開発する場合、個別に中央管理装置が必要となる。多数のサブシステムの開発が並行する場合は、中央管理装置をサブシステムの数だけ必要とする。中央管理装置の数が不足する場合は、複数のサブシステムを並行して開発することができず、開発工程が遅延する。

以上のことから本発明においては、定期的な保守を容易にし、かつ、開発を容易とする起動装置及びネットワークシステムを提供することを目的とする。

本発明は、上記課題を解決するために、第１の起動イメージを有する中央管理装置と接続され、停止状態からの立ち上げを行うための起動装置において、起動装置は第２の起動イメージを保有しており、停止状態からの立ち上げを行う時に中央管理装置との間で通信が確立しているときは中央管理装置が有する第１の起動イメージを入手して起動し、停止状態からの立ち上げを行う時に中央管理装置との間で通信が確立してないときは、自己が保有している第２の起動イメージで起動することを特徴とする。

また、起動装置と中央管理装置との間が、第１のネットワークで接続され、通信することを特徴とする。

また、起動装置は、第２のネットワークを介して制御対象に接続され通信することを特徴とする。

また、起動装置は、第２のネットワークを介して制御対象に接続され通信するとともに、中央管理装置内に仮想的に構成されていることを特徴とする。

本発明は、上記課題を解決するために、第１の起動イメージを有する中央管理装置と接続されて通信を行い、停止状態からの立ち上げを行うための起動装置において、起動装置は、第２の起動イメージと、中央管理装置から第１の起動イメージを取得して起動するブートプログラムと、中央管理装置との通信が確立しているかどうかを検出する上位接続検知部とを備え、停止状態からの立ち上げ時に上位接続検知部の検知結果をもとに、第２の起動イメージによる起動、またはブートプログラムにより入手した第１の起動イメージによる起動のうち、いずれかを実行することを特徴とする。

また起動装置は、中央管理装置へ第１の起動イメージを送信するアップロードプログラムを備え、停止状態からの立ち上げ時に上位接続検知部の検知結果をもとに、第２の起動イメージによる起動、ブートプログラムにより入手した第１の起動イメージによる起動、アップロードプログラムにより第２の起動イメージを中央管理装置へ送信する処理のうち、少なくとも一つを実行することを特徴とする。

また中央管理装置との通信が確立していない場合は、第２の起動イメージによって起動し、中央管理装置との通信が確立している場合は、中央管理装置の有する第１の起動イメージを取得して起動し、中央管理装置との通信が確立していない場合の起動動作時の次の起動時に、中央管理装置との通信が確立している場合は、第２の起動イメージを中央管理装置へ送信することを特徴とする。

また中央管理装置から中央管理装置の有する第１の起動イメージを取得して起動することに失敗した場合に、起動装置の第２の起動イメージを用いて起動することを特徴とする。

また起動装置は、第２の起動イメージが更新されたかどうかを判定する起動イメージ更新検知部を備え、起動イメージ更新検知部の検知結果をもとに、アップロードプログラムにより第２の起動イメージ中央管理装置へ送信する処理を実行することを特徴とする。

また起動イメージ更新検知部は、ファイルの属性に基づいて、第２の起動イメージが更新されたかを判定することを特徴とする。

また起動イメージ更新検知部は、所定命令が実行されたかどうかに基づいて、第２の起動イメージが更新されたかを判定することを特徴とする。

また起動装置は、第２の起動イメージのバージョンと、中央管理装置の第１の起動イメージのバージョンの新旧を比較する起動イメージバージョン比較部を備え、起動イメージバージョン比較部の検知結果をもとに、第２の起動イメージによる起動、ブートプログラムにより中央管理装置から入手した第１の起動イメージによる起動のうち、いずれかを実行することを特徴とする。

また起動装置は、起動イメージバージョン比較部の検知結果をもとに、第２の起動イメージによる起動、ブートプログラムにより中央管理装置から入手した第１の起動イメージによる起動、アップロードプログラムにより第２の起動イメージを中央管理装置へ送信する処理のうち、少なくとも一つを実行することを特徴とする。

また起動装置と中央管理装置との間が第１のネットワークで接続され、通信することを特徴とする。

また起動装置は、第２のネットワークを介して制御対象に接続され通信することを特徴とする。

また起動装置は、第２のネットワークを介して制御対象に接続され通信するとともに、中央管理装置内に仮想的に構成されていることを特徴とする。

本発明は、上記課題を解決するために、第１の起動イメージを有する中央管理装置と停止状態からの立ち上げを行うための起動装置が接続され、起動装置は第２のネットワークを介して制御対象に接続され通信するネットワークシステムにおいて、起動装置は第２の起動イメージを保有しており、停止状態からの立ち上げを行う時に中央管理装置との間で通信が確立しているときは中央管理装置が有する第１の起動イメージを入手して起動し、停止状態からの立ち上げを行う時に中央管理装置との間で通信が確立してないときは、自己が保有している第２の起動イメージで起動することを特徴とする。

また起動装置と中央管理装置との間が、第１のネットワークで接続され、通信することを特徴とする。

また起動装置は、中央管理装置内に仮想的に構成されていることを特徴とする。

定期的な保守を容易にし、かつ、開発を容易とする情報処理装置を提供することができる。

本発明を適用した起動装置を用いて構成するシステム例を示す図。本発明を適用した起動装置のハードウェア構成の一実施形態を示す図。本発明を適用した起動装置の起動処理プログラムの構成を示す図。図３の起動プログラム１３０を示した図。起動プログラムのうち、初期状態プログラムを示した図。起動プログラムのうち、初期状態プログラムの代案例を示した図。起動プログラムのうち、開発状態プログラムを示した図。起動プログラムのうち、開発状態プログラムの代案例を示した図。起動プログラムのうち、開発状態プログラムの他の代案例を示した図。起動プログラムのうち、開発状態プログラムの他の代案例を示した図。起動プログラムのうち、開発完了状態プログラムを示した図。起動プログラムのうち、開発完了状態プログラムの代案例を示した図。起動プログラムのうち、稼動状態プログラムを示した図。起動プログラムのうち、稼動状態プログラムの代案例を示した図。起動プログラムのうち、稼動状態プログラムの他の代案例を示した図。起動プログラムのうち、稼動状態プログラムの他の代案例を示した図。ネットワークブートプログラムを示した図。ネットワークブートプログラムの代案例を示した図。ネットワークアップロードプログラムを示す図。状態記憶部の管理する状態遷移を示す図。実施例２における起動装置の起動処理プログラム構成を示す図。実施例２における起動プログラムを示した図。実施例２における起動プログラムの代案例を示した図。起動イメージ更新検知部の結果を、開発状態プログラムに反映させた図。起動イメージ更新検知部における起動イメージ更新判定方法を示した図。実施例３における起動装置の起動処理プログラム構成を示す図。実施例３における起動プログラムを示した図。バージョン番号を連番で設定する方法を示す図。実施例３におけるシステム構成例を示す図。実施例３のときの中央管理装置のハードウェア構成を示す図。中央管理装置のＣＰＵ上で動作するソフトウェア構成を示す図。中央管理装置のＣＰＵ上で動作する他のソフトウェア構成を示す図。経路制御部を備えた起動装置のハードウェア構成を示す図。上位、下位接続通信部を直接接続するカットスルーモードを示す図。上位、下位接続通信部がバス接続する通常モードを示す図。経路制御部を備えた起動装置で構成するシステム例を示す図。複数の起動装置で構成するシステム例を示す図。

以下、本発明の実施形態にかかるネットワークシステムについて図面を用いて説明する。

図１は、本発明を適用した起動装置１２１を用いて構成するシステム例である。この図において、中央管理装置１２０は、ネットワーク１２２を介して起動装置１２１と接続し、通信する。中央管理装置１２０と起動装置１２１の通信内容としては、中央管理装置１２０から起動装置１２１に対する動作指示や各種の設定が例示され、また、起動装置１２１の動作結果や状態を中央管理装置１２０が取得することが例示される。

計算機で構成された起動装置１２１は、計算機で構成された中央管理装置１２０の動作指示をもとに、ネットワーク１２３を通じて制御対象１２４を制御する。制御対象１２４として、各種のセンサや、各種のアクチュエータが例示される。図１では、一つの中央管理装置１２０と複数の起動装置１２１が接続している。またネットワークは、上位ネットワーク１２２と下位ネットワーク１２３を有する例を示している。

上位のネットワーク１２２として、図１ではＩＥＥＥ８０２．３を想定する。なお、図１中にはネットワークスイッチを図示しているが、ネットワーク１２２によってトポロジやネットワークの構成要素は異なる。

下位の制御用ネットワーク１２３として、図１ではＩＥＥＥ８０２．３を想定する。制御対象１２４を制御することから、制御用ネットワーク１２３は、各種制御用通信、ＩＥＣ６１１５８で定義される産業用Ｅｔｈｅｒｎｅｔ（登録商標）の適用が望ましい。なお、複数の起動装置１２１に接続する制御用ネットワーク１２３は、同じ番号を割り当てているが、異なる通信規格であってもよい。

図２は、本発明を適用した起動装置１２１のハードウェア構成の一実施形態である。ＣＰＵ１０１は、不揮発性記憶媒体１０９からプログラムをメモリ１０８に転送して実行する。実行処理プログラムとしては、オペレーティングシステム（以下、ＯＳと称す）やＯＳ上で動作するアプリケーションプログラムが例示される。

上位接続通信部１０２は、ＣＰＵ１０１上で動作するプログラムから通信要求を受け取り、ネットワーク１２２と通信する。上位接続通信部１０２の実装例としては、ＦＰＧＡ（Ｆｉｅｌｄ−ＰｒｏｇｒａｍｍａｂｌｅＧａｔｅＡｒｒａｙ）、ＣＰＬＤ（ＣｏｍｐｌｅｘＰｒｏｇｒａｍｍａｂｌｅＬｏｇｉｃＤｅｖｉｃｅ）、ＡＳＩＣ（ＡｐｐｌｉｃａｔｉｏｎＳｐｅｃｉｆｉｃＩｎｔｅｇｒａｔｅｄＣｉｒｃｕｉｔ）、ゲートアレイ、ＩＥＥＥ８０２．３のＭＡＣ（ＭｅｄｉａＡｃｃｅｓｓＣｏｎｔｒｏｌ）層の処理ＩＣ、ＰＨＹ（Ｐｈｙｓｉｃａｌ）層の処理ＩＣ、ＭＡＣ、ＰＨＹの一体型ＩＣが例示される。なお、通信機能の一部がＣＰＵ１０１に含まれていてもよい。

下位接続通信部１０３は、制御用ネットワーク１２３との通信機能を実装した送受信機ＩＣである。下位接続通信部１０３の実装例としては、ＦＰＧＡ、ＣＰＬＤ、ＡＳＩＣ、ゲートアレイ、ＩＥＥＥ８０２．３のＭＡＣ層の処理ＩＣ、ＰＨＹ層の処理ＩＣ、ＭＡＣ、ＰＨＹの一体型ＩＣが例示される。なお、通信機能の一部がＣＰＵ１０１に含まれていてもよい。

なお、接続するネットワークが、ネットワーク１２２か制御用ネットワーク１２３かの違いによって、上位接続通信部１０２と下位接続通信部１０３を区別しているが、これは便宜上の呼称であって、同一の通信規格であってもよい。

メモリ１０８は、ＣＰＵ１０１が動作するための一時的な記憶領域であり、不揮発性記憶媒体１０９から転送したＯＳ、アプリケーションプログラム等が格納される。

不揮発性記憶媒体１０９は、情報の記憶媒体で、ＯＳ、アプリケーション、デバイスドライバ等の起動イメージや、ＣＰＵ１０１を動作させるためのプログラムの保存、プログラムの実行結果の保存に利用される。不揮発性記憶媒体１０９として、ハードディスクドライブ（ＨＤＤ）やソリッドステートドライブ（ＳＳＤ）、フラッシュメモリが例示される。また、取り外しが容易な外部記憶媒体として、フロッピーディスク（登録商標：ＦＤ）、ＣＤ、ＤＶＤ、ブルーレイ（登録商標）、ＵＳＢメモリ、コンパクトフラッシュ（登録商標）等の利用が例示される。

バス１１０は、ＣＰＵ１０１、メモリ１０８、不揮発性記憶媒体１０９、上位接続通信部１０２、下位接続通信部１０３をそれぞれ接続する。バス１１０としては、ＰＣＩバス、ＩＳＡバス、ＰＣＩＥｘｐｒｅｓｓバス、システムバス、メモリバス等が例示される。

本発明を適用した起動装置１２１の起動処理に関連するプログラムの構成を図３に示す。各プログラムの詳細な処理内容は後述する。ここでははじめに各処理の概要を示すに留める。

起動プログラム１３０は、起動装置１２１の起動時（電源オン時、あるいはＣＰＵ１０１のハードリセット時等）に、最初に起動するプログラムである。起動プログラム１３０の実体は、ＣＰＵ１０１のハードウェアリセット時のアドレスに配置されるＩＰＬ（ＩｎｉｔｉａｌＰｒｏｇｒａｍＬｏａｄｅｒ）や汎用ＰＣ（ＰｅｒｓｏｎａｌＣｏｍｐｕｔｅｒ）のＢＩＯＳ（ＢａｓｉｃＩｎｐｕｔ／ＯｕｔｐｕｔＳｙｓｔｅｍ）等が例示される。

ネットワークブートプログラム１３１は、ネットワークブート処理を実行する。ネットワークブートプログラム１３１は、ＩＰＬ、ＢＩＯＳ等に含まれる場合もあれば、上位接続通信部１０２をネットワークカードＮＩＣとする構成では、ＮＩＣ上の不揮発性記憶媒体に含む場合もある。

ネットワークアップロードプログラム１３２は、起動イメージ１３４を所定のサーバにアップロードする。ネットワークアップロードプログラム１３２は、ＩＰＬやＢＩＯＳとして構成してもよいし、起動イメージ１３４に含まれるＯＳの起動処理として構成してもよい。例えば、Ｌｉｎｕｘ（登録商標）では、所定の起動処理を起動スクリプトとして設定、動作させることができる。

状態記憶部１３３は、起動プログラム１３０の状態遷移における現在の状態を記憶する。状態記憶部１３３は、電源を切った場合でも、記憶内容を保持しておく必要がある。そのため、他の起動処理に関連するプログラムと同様に不揮発性記憶媒体上に構成する必要がある。従って、図２の不揮発性記憶媒体１０９を用いてもよいし、ＥＥＰＲＯＭ（ＥｌｅｃｔｒｉｃａｌｌｙＥｒａｓａｂｌｅＰｒｏｇｒａｍｍａｂｌｅＲｅａｄ−ＯｎｌｙＭｅｍｏｒｙ）等のデバイスを用いてもよい。

起動イメージ１３４は、ＯＳやアプリケーションプログラムなど、起動処理完了後に定常的に動作するソフトウェアプログラムである。

上位接続通信検知部１３５は、起動装置１２１が上位ネットワーク１２２と通信が確立しているかを検知する。検知方法は、ＩＥＥＥ８０２．３で規定されるＭＤＩ（ＭａｎａｇｅｍｅｎｔＤａｔａＩｎｔｅｒｆａｃｅ）におけるＰＨＹＩＣの状態レジスタのリンクステータスを用いる方法や、ＰＨＹＩＣで一般的に用いられるＬＥＤ点灯用の出力信号を用いる方法が例示される。

次に、起動処理に関する各プログラムの動作について説明する。起動プログラム１３０を図４に示す。

前述のとおり、起動プログラム１３０は、起動装置１２１の電源を入れた後、最初に起動するプログラムである。はじめに図３の状態記憶部１３３に保持している状態を取得する（処理ステップＳ００１）。次に、取得した状態に応じて、動作を変える（処理ステップＳ００２）。次に初期状態の動作（処理ステップＳ００３）、開発状態の動作（処理ステップＳ００４）、開発完了状態の動作（処理ステップＳ００５）、稼働状態の動作（処理ステップＳ００６）について実行する。これらの詳細は後述する。各動作を実行後、メモリ１０８に展開されたＯＳ等の起動イメージの起動アドレスから動作を開始し、ＯＳ等のプログラムを起動する（処理ステップＳ００７）。

これらの処理によれば、まず状態記憶部１３３に保持している状態として、初期状態、開発状態、開発完了状態、稼働状態に区分して記憶されている。現在の状態がこのどこに当るかによって、次に実行すべき処理（処理ステップＳ００３乃至Ｓ００６）を決定して逐次実行する。なお、これらの個々の処理完了後には、状態記憶部１３３に保持している状態を他の段階に変更しておくことで、これらの処理を遂行し、状態の遷移を行う。

まず、起動プログラム（図３の１３０）のうち、初期状態の動作（図４の処理ステップＳ００３）について以下詳細に説明する。この場合には、図５と図６のいずれかの手法を採用できる。

はじめに図５の手法について説明する。ここではまず、図３の上位接続通信検知部１３５による検知結果を取得する。処理ステップＳ０１０では、この検知結果を基にして、上位接続通信が確立しているかを判断する。

上位通信が確立している場合、処理ステップＳ０１１において図３のネットワークブートプログラム１３１に制御を移して、処理ステップＳ０１２ではネットワークブートプログラム１３１の終了を待機する。ネットワークブート処理の終了時点では、中央管理装置１２０が有する起動イメージが起動装置１２１に取り込まれ、起動装置１２１は起動している。従って、ネットワークブート処理の終了を確認して処理ステップＳ０１３では図３の状態記憶部１３３の状態を稼働状態とする。

処理ステップＳ０１０にて、上位接続通信が確立していないとされた場合、処理ステップＳ０１４では図３の起動イメージ１３４を図２のメモリ１０８の所定領域に展開し、ＣＰＵ１０１での演算に供する。この場合起動装置１２１は、予め自己内部に保有する起動イメージを使用して起動処理を実行することになる。次に処理ステップＳ０１５では、図３の状態記憶部１３３の状態を起動処理の次段階である開発状態とする。

初期状態の動作（図４の処理ステップＳ００３）の詳細処理の代案例を図６に示す。図５との違いは、点線で囲んだ部分である。処理ステップＳ０１２の後に、ネットワークブートプログラム１３１によるネットワーク経由の起動イメージのダウンロードが成功したかどうかを処理ステップＳ０１６で判定する。これが失敗した場合、処理ステップＳ０１７において起動イメージ１３４をメモリ１０８の所定領域に展開する。これによりこの起動装置１２１は、予め自己内部に保有する起動イメージを使用して起動処理を実行する。なお、処理ステップＳ０１７の後に、状態を稼働状態としているが、状態を設定せずにそのまま終了してもよい。この場合、状態記憶部１３３の状態は初期状態のままである。

次に、起動プログラム（図３の１３０）のうち、開発状態の動作（図４の処理ステップＳ００４）について以下詳細に説明する。この場合には、図７、図８、図９、図１０のいずれかの手法を採用できる。

まず、図７での処理について説明する。ここでははじめに、図３の上位接続通信検知部１３５による上位接続通信が確立しているかの検知結果を処理ステップＳ０２０で取得し、この結果を判断する。

上位通信が確立している場合、処理ステップＳ０２１では図３のネットワークアップロードプログラム１３２に制御を移し、処理ステップＳ０２２においてネットワークアップロードプログラム１３２の終了を待機する。これらの処理によって、図３のネットワークアップロードプログラム１３２が作動して、開発物である起動イメージ１３４を自動で中央管理装置１２０に転送することができる。この起動イメージは、起動装置１２１内で作成され、ここに保有されていたものである。

その後、ネットワークブートプログラム１３１に制御を移し（処理ステップＳ０２３）、処理ステップＳ０２４でネットワークブートプログラム１３１の終了を待機する。これにより起動装置１２１は、中央管理装置１２０から起動イメージを得る。このときの起動イメージは、先に送付した開発物である起動イメージ１３４であり、これにより起動装置１２１と中央管理装置１２０に保有する起動イメージの同期が図られる。その終了後に、図３の状態記憶部１３３の状態を開発完了状態に設定する（処理ステップＳ０２５）。

処理ステップＳ０２０において上位接続通信が確立していなければ、処理ステップＳ０２６において図３の起動イメージ１３４を図２のメモリ１０８の所定領域に展開する。この起動イメージは起動装置１２１内に保有されていたものである。

開発状態の動作（処理ステップＳ００４）の詳細の別の例を図８に示す。図８における図７との違いは、点線で囲んだ部分である。処理ステップＳ０２２の後にネットワークアップロードプログラム１３２による起動イメージのアップロードが成功したかどうかを判定し（処理ステップＳ０２７）、アップロードが失敗した場合は、起動イメージ１３４をメモリ１０８の所定領域に展開する（処理ステップＳ０２６）。この起動イメージは起動装置１２１内に保有されていたものである。

開発状態の動作（処理ステップＳ００４）の詳細の別の例を図９に示す。図９における図７との違いは、点線で囲んだ部分である。処理ステップＳ０２５の後にネットワークブートプログラム１３１によるネットワーク経由の起動イメージの取得が成功したかどうかを判定（処理ステップＳ０２８）する。これが失敗した場合は、起動イメージ１３４をメモリ１０８の所定領域に展開する（処理ステップＳ０２６）。この起動イメージは起動装置１２１内に保有されていたものである。

開発状態の動作（処理ステップＳ００４）の詳細の別の例を図１０に示す。図１０は、図８、図９を組み合わせた動作となる。

次に、起動プログラム（図３の１３０）のうち、開発完了状態の動作（図４の処理ステップＳ００５）について以下詳細に説明する。この場合には、図１１と図１２のいずれかの手法を採用できる。

まず、図１１での処理について説明する。ここでははじめに、図３の上位接続通信検知部１３５による上位接続通信が確立しているかの検知結果を取得し、これを確認する（処理ステップＳ０３０）。

上位接続通信が確立している場合、図３のネットワークブートプログラム１３１に制御を移し（処理ステップＳ０３１）、ネットワークブートプログラム１３１の終了を待機する（処理ステップＳ０３２）。ネットワークブート処理の終了により、図３の状態記憶部１３３の状態を稼働状態に設定する（処理ステップＳ０３３）。

処理ステップＳ０３０にて、上位接続通信が確立していなければ、図３の起動イメージ１３４を図２のメモリ１０８の所定領域に展開する（処理ステップＳ０３４）。そして、図３の状態記憶部１３３の状態を開発状態に設定する（処理ステップＳ０３５）。

開発完了状態の動作（処理ステップＳ００５）の詳細の別の例を図１２に示す。図１２における図１１との違いは、点線で囲んだ部分である。処理ステップＳ０３３の後にネットワークブートプログラム１３１によるネットワーク経由の起動イメージのダウンロードが成功したかどうかを判定し（処理ステップＳ０３６）、これが失敗した場合は起動イメージ１３４をメモリの所定領域に展開する（処理ステップＳ０３７）。

次に、起動プログラム（図３の１３０）のうち、稼動状態の動作（図４の処理ステップＳ００６）について以下詳細に説明する。この場合には、図１３から図１６のいずれかの手法を採用できる。

まず、図１３での処理について説明する。ここでははじめに、図３の上位接続通信検知部１３５による上位接続通信が確立しているかの検知結果を取得し確認する（処理ステップＳ０４０）。上位接続通信が確立している場合、図３のネットワークブートプログラム１３１に制御を移す（処理ステップＳ０４１）。そして、ネットワークブートプログラム１３１の終了を待機する（処理ステップＳ０４２）。

処理ステップＳ０４０にて、上位接続通信が確立していなければ、図３の起動イメージ１３４を図２のメモリ１０８の所定領域に展開する（処理ステップＳ０４３）。そして、状態記憶部１３３の状態を稼働状態に設定する（処理ステップＳ０４４）。

稼働状態の動作（処理ステップＳ００５）の詳細の別の例を図１４に示す。図１４における図１３との違いは、点線で囲んだ部分である。処理ステップＳ０４２の後にネットワークブートプログラム１３１によるネットワーク経由の起動イメージの取得が成功したかどうかを判定し（処理ステップＳ０４５）、これが失敗した場合は起動イメージ１３４をメモリの所定領域に展開する（処理ステップＳ０４６）。

稼働状態の動作（処理ステップＳ００５）の詳細の別の例を図１５に示す。図１５における図１３との違いは、点線で囲んだ部分である。処理ステップＳ０４２の後に、ネットワークブートプログラム１３１によるネットワーク経由で取得した起動イメージで、起動イメージ１３４を上書きする（処理ステップＳ０４７）。

稼働状態の動作（処理ステップＳ００５）の詳細の別の例を図１６に示す。図１６は、図１４、図１５を組み合わせた動作を示す。

図３の起動プログラムに関連する処理には、ネットワークブートプログラム１３１、またはネットワークアップロードプログラム１３２の処理の成功、失敗の判定処理を行う部分がある。これらは例えば、図５、６、７、８、９、１０、１１、１２、１４、１６の手順中において必要となる。

この判定処理の具体的な処理手法事例としては、ＴＦＴＰに従い、エラーコードを示すパケットを受信した場合に失敗と判定する方法や、所定期間応答がない場合等の通信が成立しなかった場合に失敗と判定する方法が挙げられる。一方で、ＴＦＴＰに従い、所定サイズのデータ転送が完了して確認応答（ＡＣＫ）コードを示すパケットを受信した場合に成功と判定する方法が挙げられる。

また図３の起動プログラムに関連する処理には、ネットワークアップデート、ネットワークブートの成功、失敗という判定結果を外部に通知する部分がある。これらは例えば、図５、６、７、８、９、１０、１１、１２、１４、１６の手順中において必要となる。

この具体的な実現手段としては、ＬＥＤ、ＬＣＤ、ディスプレイ、アラーム音等の手段を用いて外部に通知する方法が例示される。あるいは、状態記憶部１３３に判定結果を記憶し、起動後のソフトウェア上から判定結果を取得できるようにする構成や、予め設定したメールアドレスに電子メールで通知してもよい。

また、図３の起動プログラムに関連する処理には、失敗に対するリトライ処理を行う部分がある。これらは例えば、図５、６、７、８、９、１０、１１、１２、１４、１６の手順中において必要となる。

この処理に関し、ネットワークブートプログラム１３１、あるいはネットワークアップロードプログラム１３２の処理結果が失敗と判定した場合に、再度、ネットワークブートプログラム１３１、ネットワークアップロードプログラム１３２に制御を移し、再試行してもよい。このとき、所定回数、試行が失敗だった場合に、従来の失敗と判定した後の処理を実行することが例示される。

また、図３の起動プログラムに関連する処理には、失敗した場合のプロンプトに関する部分がある。これらは例えば、図５、６、７、８、９、１０、１１、１２、１４、１６の手順中において必要となる。

この処理に関し、ネットワークブートプログラム１３１、あるいはネットワークアップロードプログラム１３２の処理結果が失敗と判定した場合に、所定のタイムアウト期間をもうけ、その所定期間内に入力装置による入力があれば、その後の処理を継続し、入力がなければ、起動せずに終了してもよい。タイムアウト期間は固定値でもよいし、ソフトウェア上から設定可能としてもよい。この場合、起動プログラムは、ＣＰＬＤ、ＦＰＧＡ等のユーザ論理ＩＣ上に実装し、入力装置の入力を取得できる構成が例示される。入力装置として、起動装置１２１上にプッシュスイッチ、トグルスイッチ、ＤＩＰ（ＤｕａｌＩｎ−ｌｉｎｅＰａｃｋａｇｅ）スイッチ等の各種スイッチを設けることやキーボードが例示される。

また、起動プログラムから他のプログラムへの制御の移し方についても考慮すべきである。このための具体的手法として、一般的なＣＰＵに定義されているジャンプ命令やコール命令、リターン命令を用いる方法が例示される。

ジャンプ命令は所定アドレスに制御を移す命令であり、引数に起動処理に関連するプログラムの先頭アドレスを指定すればよい。コール命令は、指定の関数へ制御を移す命令である。コール先の関数のアドレスは、コンパイラ等によって解釈される。起動処理に関連するプログラムが終了した場合は、ジャンプ命令やリターン命令を使用し、起動プログラム１３０に戻る方法を例示する。ジャンプ命令の場合は、戻り先のアドレスを指定する。リターン命令は、コール命令実行時にスタックに設定されたアドレスに制御を移す。

以上が、図３の起動プログラム１３０の説明である。ここまで多様なプログラム処理について説明をしてきたが、ここでは、起動装置１２１の電源投入後の状態が如何なるものであれ、同じ対応を実施している。

つまり中央管理装置１２０と起動装置１２１の関係において、起動装置１２１の電源投入後に中央管理装置１２０との通信が確立しているのであれば起動装置１２１は中央管理装置１２０から起動イメージを入手して起動する。通信が確立していないのであれば起動装置１２１は自己が保有する起動イメージで起動する。

続いて、図３のネットワークブートプログラム１３１の動作について具体的に説明する。ネットワークブートプログラム１３１を図１７に示している。

ここで、ネットワークブートプログラム１３１は、プレブート実行環境規格ＰＸＥにしたがってネットワークブートすることが一般的である。この場合はじめに、図３のネットワークブートプログラム１３１は、処理ステップＳ０５０においてＩＰアドレスを所定のサーバから取得する。この時、ＩＰアドレスを取得するために、動的ホスト構成プロトコルＤＨＣＰを用いるのが一般的である。

そして処理ステップＳ０５１で、起動イメージを提供するブートサーバの情報を取得する。ここで取得するブートサーバの情報としては、ブートサーバの接続情報、起動イメージのファイル名等である。

処理ステップＳ０５２では、これらの情報をもとにネットワークブートプログラム１３１は、ブートサーバから起動イメージを取得する。起動イメージを取得する通信プロトコルとしてＴＦＴＰが例示される。

処理ステップＳ０５３では、起動イメージを取得した後、図２のメモリ１０８に展開する。

なお、ＩＰアドレスを割り当てるサーバとブートサーバを別として説明しているが、同じサーバとして構成してもよい。図１の構成では、中央管理装置１２０は、ＤＨＣＰサーバ、ブートサーバとして構成している。

なお、図１７の実施に当り、更に以下のような変更、改変、代案を採用可能である。処理ステップＳ０５０において、起動装置１２１のＩＰアドレスを静的に決定している場合は、処理ステップＳ０５０の手順を省略してもよい。

処理ステップＳ０５１において、中央管理装置１２０のＩＰアドレス、起動イメージのファイル名等を静的に決定し、ブートサーバの情報を取得する必要がない場合は、処理ステップＳ０５１の手順を省略してもよい。

起動イメージの取得をメモリ１０８への展開を処理ステップＳ０５２、処理ステップＳ０５３と段階を分けて説明したが、所定ブロックサイズにわけて処理ステップＳ０５２、処理ステップＳ０５３を繰り返し実行してもよい。つまり、所定ブロックサイズをネットワークで経由した後に、メモリ１０８へと展開し、再度、所定ブロックサイズをネットワークで取得する。起動イメージ全体を取得するまで、これらの処理を繰り返し実行する。

図１５、１６に示す手順の処理ステップＳ０４７において、起動イメージ１３４を上記処理ステップＳ０５２で取得した起動イメージで上書きしているが、この処理も同様に、ブロックサイズ毎に起動イメージ１３４を上書きしてもよい。

次に、ネットワークブートプログラム１３１を用いて中央管理装置１２０から取得した起動イメージにより、起動装置内ＯＳを起動する処理を図１８に示す。図１８には、図１７の処理ステップＳ０５３の後に、処理ステップＳ０５４が追加されている。処理ステップＳ０５４では、メモリ１０８に展開されたＯＳ等の起動イメージの起動アドレスから動作を開始し、ＯＳ等のプログラムを起動する。

図１７、図１８の処理の具体的な実行に際して、さらに以下の点を考慮し、或いは工夫するのがよい。

図１７、図１８の処理では、以後起動プログラム１３０に動作が戻らない。このため、起動プログラム１３０の動作において、ネットワークブートプログラム１３１の動作前に状態記憶部１３３の状態を更新する方法が例示される。

また、図６、９、１０、１２、１４、１６の処理において、ネットワークブートプログラム１３１の成功、失敗を判定するため、ネットワークブートプログラム１３１の処理結果を所定の位置に記憶する。処理結果の記憶先として、状態記憶部１３３でもよい。

記憶する結果は、ネットワークブートプログラム１３１の処理が成功したか失敗したかを示す真理値の他に、失敗した処理とその失敗要因も含めて記憶するのがよい。

失敗した処理の例としては、ＩＰアドレスの取得処理、起動イメージの取得処理、起動イメージの所定ブロック処理等が挙げられる。失敗要因としては、タイムアウトを含む通信の失敗、通信プロトコルに依存した失敗要因、起動イメージが存在しない、起動イメージの容量が不適切（過剰に大きい、過剰に小さい等）、不正な起動イメージファイル名であるといった起動イメージの取得に関する要因や、メモリ１０８の容量不足といった原因が例示される。

また、起動プログラム１３０が必要とする情報は、成功か失敗かのみであるが、他の情報をもとに対応処理を変更することができる。例えば、失敗した処理が起動イメージの取得である場合は、再度ネットワークブートプログラム１３１を実行して、ＩＰアドレスの取得処理を省略してもよい。

さらに、起動イメージによるＯＳの起動後に失敗要因を取得して、対策を取ることができる。例えば、起動イメージの容量が大きい場合は、メモリ１０８の容量を大きくする対策や、中央管理装置１２０の起動イメージを縮小する対策が例示される。

なお、これらの処理結果は、ソフトウェアから消去できるように構成してもよいし、起動プログラム１３０の実行時の最初（図４の処理ステップＳ００１の前）に消去してもよい。

次に、図３のネットワークアップロードプログラム１３２を図１９に示す。ここでははじめに、ネットワークブートプログラム１３１と同様にＩＰアドレスを取得する（処理ステップＳ０６０）。

次にブートサーバ（中央管理装置１２０）の情報を取得する（処理ステップＳ０６１）。ここでは、図１７の処理ステップＳ０５２と同様にＰＸＥ仕様の枠組みで取得する方法が例示される。これはシステムの運用方法として、ブートサーバと中央管理装置１２０を同じとし、図１７の処理ステップＳ０５２と同様に、プレブート実行環境規格ＰＸＥ仕様の枠組みで取得することを前提とする。あるいは、中央管理装置１２０のＩＰアドレスを静的に決定し、利用する方法が例示される。

最後に、起動装置１２１自身が保有する起動イメージ１３４を中央管理装置１２０に送信する（処理ステップＳ０６２）。

なお、図８、１０において、ネットワークアップロードプログラム１３２の成功、失敗を判定するため、ネットワークアップロードプログラム１３２の処理結果を所定の位置に記憶する。処理結果の記憶先として、状態記憶部１３３でもよい。

記憶する結果は、ネットワークアップロードプログラム１３２の処理が成功したか失敗したかを示す真理値の他に、失敗した処理とその失敗要因が例示される。

また、起動プログラム１３０が必要とする情報は、成功か失敗かのみであるが、他の情報をもとに対応処理を変更することができる。例えば、失敗した処理が起動イメージの取得である場合は、再度ネットワークアップロードプログラム１３２を実行して、ＩＰアドレスの取得処理を省略してもよい。

さらに、起動イメージによるＯＳの起動後に失敗要因を取得して、対策を取ることができる。例えば、起動イメージの容量が大きい場合は、メモリ１０８の容量を大きくする対策や、中央管理装置１２０の起動イメージを縮小する対策が例示される。なお、これらの処理結果は、ソフトウェアから消去できるように構成してもよいし、起動プログラム１３０の実行時の最初（図４の処理ステップＳ００１の前）に消去してもよい。

なお、図１９において、中央管理装置１２０が複数の起動装置１２１と接続し、かつ、起動装置１２１毎に起動イメージを区別して管理する場合は、起動イメージの更新場所を起動装置１２１毎に管理する必要がある。具体的には、起動装置１２１のＩＰアドレス毎に起動イメージの更新場所を区別する。処理ステップＳ０６１において、プレブート実行環境規格ＰＸＥ仕様に基づいて、ブートサーバ（中央管理装置１２０）の情報を提供する場合は、ファイル名を起動装置１２１ごとに変更する方法が例示される。このとき、起動装置１２１は、中央管理装置１２０から提示されたファイル名で起動イメージを中央管理装置１２０に送信する。

次に図３の状態記憶部１３３について説明する。状態記憶部１３３は、起動プログラム１３０の動作を制御する状態を記憶する。状態には、初期状態、開発状態、開発完了状態、稼働状態がある。

またこれらの状態は、状態遷移する。状態記憶部１３３の管理する状態遷移を図２０に示す。

図２０に示す状態遷移の動作は、図５、６、７、８、９、１０、１１、１２、１３、１４、１５、１６で説明したとおりである。このため、遷移についての詳細説明を割愛するが、参考までに遷移を決定している処理ステップを記述している。なお、開発状態から開発完了状態に遷移する条件（処理ステップＳ０２５）において、「起動イメージの更新が成功」は、図８、１０で説明した動作の場合に有効である。

なお状態の表現方式は、４ビットで、各ビットを状態に割り当て、排他的に１にする方式が例示される。例えば、ビット０を初期状態、ビット１を開発状態、ビット２を開発完了状態、ビット３を稼働状態と定義する。一例として、００１０（２進数）は開発状態を表す。あるいは、所定の値を各状態に割り当てる方式が例示される。例えば、０を初期状態、１を開発状態、２を開発完了状態、３を稼働状態と定義する。

また状態記憶部１３３を不揮発性記憶媒体、あるいは外部記憶媒体で構成する場合に、図２０の状態遷移による設定ではなく、ソフトウェア等から、明示的に所定の値を設定できるように構成してもよい。

以上詳細に説明した本発明により、ネットワークで接続された製造装置の保守、開発、稼働における課題への効果を説明する。効果の説明に当り、本発明を適用した起動装置を利用して、通常の稼働時では、図１に示す構成で運用するという前提で述べる。

この場合、起動装置１２１はネットワークブートによる起動が可能となる。そこで、アプリケーションの交換、セキュリティパッチの適用、オペレーティングシステムのバージョンアップ等の定期保守は、中央管理装置１２０内の起動イメージを更新するだけでよい。そのため、個別の起動装置１２１内の起動イメージを更新する必要がない。したがって、定期保守が容易になる利点がある。

一方で、起動装置１２１側で個別にサブシステムを開発する場合は、上位接続通信を検知しないことで開発状態となり、起動装置１２１内の起動イメージを利用し、起動装置１２１単独で起動する。したがって、中央管理装置１２０を必要としない。

また、開発完了時には、図１の構成となるため、起動装置１２１と中央管理装置１２０間の通信接続の確立を確認し、開発成果物であるアプリケーションやデバイスドライバを含む起動イメージが自動的に起動装置１２１から中央管理装置１２０に送信される。したがって、開発時の工数を低減することができ、開発コストを削減することができる。

これらの起動時の動作の切り替えを上位通信の接続に基づいて、起動プログラム１３０が自動で切り替えるため、本発明を容易に適用することができる。

次に、所定アドレス、所定命令による開発完了の判定を行う第２の実施例について説明する。ここでは、実施例１と比較して、上位接続ではなく、起動装置１２１の動作に基づいて開発完了を判定する構成である。実施例に使用する符号は、特に断りのない限り、実施例１で説明した機能や要素等と同一であることを意味する。

本発明を適用した起動装置１２１を用いて構成するシステム例は図１と同様である。また、起動装置１２１のハードウェア構成は図２と同様である。

本発明を適用した起動装置１２１の起動処理に関連するプログラム構成を図２１に示す。図３と比較した場合に、新たに追加された起動イメージ更新検知部１５０は、起動イメージが更新されたかどうかを検知する。検知方法は後述する。

最初に、起動プログラム１３０を図２２に示し、ここでの動作について説明する。

ここでは、はじめに起動イメージ更新検知部１５０による検知結果を取得する（処理ステップＳ０７０）。そして、起動イメージ１３４が更新されたかどうかを判定する（処理ステップＳ０７１）。

起動イメージ１３４が更新されている場合、ネットワークアップロードプログラム１３２に制御を移す（処理ステップＳ０７２）。そして、ネットワークアップロードプログラム１３２の終了を待機する（処理ステップＳ０７３）。これにより、起動装置１２１自身が保有する、更新された起動イメージ１３４を中央管理装置１２０に送信する。

その後、更新された起動イメージ１３４をメモリ１０８の所定領域に展開し（処理ステップＳ０７４）、メモリ１０８に展開されたＯＳ等の起動イメージの起動アドレスから動作を開始し、ＯＳ等のプログラムを起動する（処理ステップＳ０７５）。

処理ステップＳ０７１において、起動イメージ１３４が更新されていなければ、ネットワークブートプログラム１３１に制御を移す（処理ステップＳ０７６）。そして、ネットワークブートプログラム１３１の終了を待機する（処理ステップＳ０７７）。その後は、処理ステップＳ０７５の手順を取る。これにより中央管理装置１２０からの起動イメージにより起動する。

起動プログラム１３０の別の例を図２３に示す。図２２の場合には、更新された起動イメージを起動装置１２１から中央管理装置１２０に送り、起動装置１２１自身は保有する起動イメージで起動した。図２３では、更新された起動イメージを起動装置１２１から中央管理装置１２０に送り（処理ステップＳ０７２,Ｓ０７３）、起動装置１２１自身は、その後に中央管理装置１２０から送られた（処理ステップＳ０７６,Ｓ０７７）起動イメージで起動することにしている。そのうえで、図２３の場合には、処理ステップＳ０７１の更新がされていないという条件のときにネットワークブートプログラム１３１に制御を移し、実行するようにしている。

なお、図２２、図２３は、上位接続通信検知部１３５を利用しない場合の動作である。上位接続通信検知部１３５と組み合わせて利用する場合、図２０に示す状態遷移に基づいて起動プログラム１３０は動作する。このとき、起動イメージ更新検知部１５０の検知結果を、開発状態における動作に反映させる。

この場合の処理の一例を図２４に示す。図２４は、開発状態におけるプログラムを示す図７の処理を一部改変している。図２４において、点線で示す処理ステップＳ０８０,Ｓ０８１が追加部分であり、これにより図７の処理に起動イメージ更新検知部１５０の検知結果を反映している。

具体的には、処理ステップＳ０２０の後に、起動イメージ更新検知部１５０の検知結果を取得する（処理ステップＳ０８０）。そして、起動イメージ１３４が更新されたかを判定する（処理ステップＳ０８１）。起動イメージ１３４が更新されていない場合は、処理ステップＳ０２１、処理ステップＳ０２２の処理を省略する。

このようにして、ネットワークアップロードプログラム１３２に制御を移す前に起動イメージ更新検知部１５０の検知結果を取得して、起動イメージ１３４が更新された場合にネットワークアップロードプログラム１３２に制御を移す。起動イメージ１３４が更新されていない場合は、起動イメージ１３４をアップロードする必要がないため、ネットワークアップロードプログラム１３２の処理を省略する。

次に、起動イメージ更新検知部１５０の検知方法について説明する。検知方法は、複数考えられ、起動時に起動イメージ更新検知部１５０が能動的に検知する方法や、ＯＳ起動後の稼働時に検知する方法、所定命令の実行の有無によって判定する方法が例示される。以下、具体的に説明する。

例えば、起動イメージ更新検知部１５０が、ファイルシステムの所定のファイルの情報をもとに起動イメージが更新されたかどうかを判定する方法を図２５に例示する。

ここでは予め、判定対象のファイルは設定済みであるとする。判定対象のファイルの設定方法は、起動イメージ更新検知部１５０がソフトウェアによって設定可能であり、判定対象のファイルパス、あるいはファイルシステムに依存する識別情報によって指定する方法が例示される。

図２５は、起動プログラム１３０から検知結果の取得要求があった際に起動するものとする。はじめに、記憶している更新日時情報が存在するかを判定する（処理ステップＳ０９０）。

記憶している更新日時情報が存在すれば、判定対象のファイルの更新日時情報を取得する（処理ステップＳ０９１）。そして、取得した更新日時情報が、記憶している更新日時情報より新しいかを判定する（処理ステップＳ０９２）。

取得した更新日時情報が、記憶している更新日時情報より新しければ、起動イメージ１３４は更新されたと判定する（処理ステップＳ０９３）。続いて、記憶している更新日時情報を、取得した更新日時情報に更新する（処理ステップＳ０９４）。処理ステップＳ０９０で、更新日時情報を記憶していない場合も、処理ステップＳ０９３、処理ステップＳ０９４の手順をとる。

処理ステップＳ０９２で、取得した更新日時情報が、記憶している更新日時情報より新しくない場合は、起動イメージ１３４は更新されていないと判定する（処理ステップＳ０９５）。

ここで使用する更新日時情報は、ファイルシステムに依存し、起動イメージが更新されているかどうかを判定可能な分解能が必要である。更新日時情報として、西暦、月、日、時間、分、秒の組み合わせが例示される。

なお、図２５は、ファイルの更新日時情報をもとに起動イメージ１３４が更新されたかを判定したが、更新日時ではなく、ファイルサイズやファイル名等のファイルに関する属性をもとに判定してもよい。例えば、起動イメージ更新検知部１５０はファイルサイズを記憶しておき、図２５の処理ステップＳ０９２に相当する処理では、取得したファイルサイズが、記憶しているファイルサイズと異なる場合に起動イメージ１３４が更新されと判定する方法が例示される。

また、図２５は起動時に実行する方法であるが、ＯＳ起動後の定期実行処理として構成してもよい。ただし、この場合、図２５の処理ステップＳ０９４の記憶情報は、起動処理時に更新する必要がある。そうしなければ、起動イメージ１３４が更新されたと判定された次回の定期処理で起動イメージ１３４に変化がない場合、起動イメージ１３４が更新されていないと誤判定する可能性があるためである。

この他に、明示的に起動イメージ１３４が更新されたことを起動イメージ更新検知部１５０に設定する専用のプログラムを開発し、利用する方法が例示される。起動イメージ更新検知部１５０の記憶部分を不揮発性記憶媒体１０９上に構成し、ＯＳ起動後に、専用プログラムを用いて、起動イメージ更新検知部１５０に、起動イメージ１３４が更新されたことを示す所定値を設定する。設定された値を消去するタイミングは、起動時に起動プログラム１３０から取得要求があった際が考えられる。

なお、設定する方法は、専用プログラムの他に、プロセッサの専用命令で構成する方法や、ＦＰＧＡ、ＣＰＬＤで制御レジスタを設け、ソフトウェアから所定値を書き込まれた場合に起動イメージ更新検知部１５０が起動イメージ１３４が更新されたと判定する方法が例示される。

また、起動イメージ１３４が更新されたことを検知する別の方法として、ＣＰＵ１０１、あるいはＣＰＵ１０１上で動作するソフトウェアの動作を監視し、所定の条件に合致した場合に起動イメージ１３４が更新されたと判定する方法が挙げられる。ＣＰＵ１０１の動作例としては、ストア命令やＣＰＵ１０１からみて、外部の記憶媒体（不揮発性記憶媒体１０９等）に対する書込み命令や、アクセス先のアドレスと組み合わせて条件とすることが例示される。

ＣＰＵ１０１の動作を取得する方法としては、バウンダリスキャンテストやＪＴＡＧ（ＪｏｉｎｔＴｅｓｔＡｃｔｉｏｎＧｒｏｕｐ）を用いる方法が例示される。ＣＰＵ１０１ではなく、ＦＰＧＡやＣＰＬＤ内部にプロセッサコアを実装し、特定条件の命令が実行されたかどうかを判定する論理を構成してもよい。

これらの条件の一致をもって、起動イメージ更新検知部１５０を構成する不揮発性記憶媒体１０９上に起動イメージ１３４が更新されたことを示す所定値を記憶する。あるいは、ファイルシステム、ＯＳカーネル、デバッグツールで所定の動作（所定のファイル操作等）を実行した場合に起動イメージ１３４が更新されたと判定して、不揮発性記憶媒体１０９上に記憶する方法が例示される。

これは、ＯＳカーネル、ファイルシステム等のソースコードを変更して実現してもよいし、ＯＳカーネル、ファイルシステム、デバッグツール等のソフトウェアがフックを用意していれば、それを用いて構成してもよい。フックは、特定の動作時にユーザが所定の独自処理を追加できる仕組みである。

以上の実施例２により、実施例１と比較して、起動イメージ更新検知部１５０を有することにより、より適切に起動イメージが更新されたかを判定することができる。実施例１の効果に加え、開発完了時に単に上位接続の有無だけでなく、起動イメージ１３４が更新されたかどうかを判定することで、起動イメージ１３４が更新されていない場合はアップロードを実行しない。こうすることで無駄な通信を避けることができ、ネットワーク帯域を効率的に利用することができる。

次に、起動イメージのバージョン比較を行うことについて説明する。

第３の実施例は、実施例１、実施例２と比較して、起動装置１２１と中央管理装置１２０の起動イメージのバージョン番号を比較することで、ネットワークブート、ネットワークアップデートの実行を制御する構成である。実施例に使用する符号は、特に断りのない限り、実施例１、実施例２で説明した機能や要素等と同一であることを意味する。

本発明を適用した起動装置１２１の起動処理に関連するプログラム構成を図２６に示す。第１の実施例の起動処理に関連するプログラム構成を示す図３に起動イメージバージョン比較部１６０を追加した構成になっている。

起動イメージバージョン比較部１６０は、中央管理装置１２０と通信し、起動装置１２１が保有する起動イメージ１３４と、中央管理装置１２０の起動イメージのバージョンを比較する。

実施例３の場合の起動プログラム１３０を図２７に示す。

はじめに、起動イメージバージョン比較部１６０による比較結果を取得する（処理ステップＳ１００）。そして、中央管理装置１２０の起動イメージのバージョン番号（Ａとする）と起動装置１２１自身が保有する起動イメージ１３４のバージョン番号（Ｂとする）の比較結果に応じて動作を変更する（処理ステップＳ１０１）。但し、ここでは、バージョン番号が大きな数字の方が、起動イメージも新しいものとする。

ＡがＢより大きい場合は、中央管理装置１２０の起動イメージ１３４の方が新しいため、起動装置１２１の起動イメージ１３４を中央管理装置１２０にアップロードする必要はない。中央管理装置１２０の起動イメージ１３４で起動装置１２１が起動すればよい。つまりネットワークブート処理を行えばよい。このため、ネットワークブートプログラム１３１に制御を移す（処理ステップＳ１０２）。そして、ネットワークブートプログラム１３１の終了を待機する（処理ステップＳ１０３）。

なお、処理ステップＳ１０３の後に、ネットワークブートプログラム１３１によるネットワーク経由で取得した起動イメージで、起動イメージ１３４を上書きしてもよい。

処理ステップＳ１０１において、ＢがＡより大きい場合は起動装置１２１の起動イメージ１３４の方が新しいため、中央管理装置１２０にアップロードする必要がある。したがって、ネットワークアップロードプログラム１３２に制御を移す（処理ステップＳ１０４）。そして、ネットワークアップロードプログラム１３２の終了を待機する（処理ステップＳ１０５）。

その後、起動イメージ１３４をメモリ１０８の所定領域に展開し（処理ステップＳ１０６）、メモリ１０８に展開されたＯＳ等の起動イメージの起動アドレスから動作を開始し、ＯＳ等のプログラムを起動する（処理ステップＳ１０７）。

処理ステップＳ１０１において、ＡとＢが等しい場合は、起動装置１２１の起動イメージ１３４で起動装置１２１が起動すればよい。具体的には、処理ステップＳ１０５、処理ステップＳ１０６の手順を取る。なお、ＡとＢが等しい場合は、ネットワークブートプログラム１３１によって起動してもよい。その場合は、処理ステップＳ１０６ではなく、処理ステップＳ１０２に遷移する。

なお、起動イメージバージョン比較部１６０は、上位接続通信検知部１３５や図２１の起動イメージ更新検知部１５０と組み合わせて用いてもよい。例えば、ネットワークアップロードプログラム１３２に制御を移す前に起動イメージバージョン比較部１６０の比較結果を取得する。

この結果、起動イメージ１３４のバージョンが中央管理装置１２０の起動イメージのバージョンよりも大きい場合に、ネットワークアップロードプログラム１３２に制御を移す。

起動イメージ１３４のバージョンが中央管理装置１２０の起動イメージのバージョンよりも大きくない場合は、起動イメージ１３４をアップロードする必要がないため、ネットワークアップロードプログラム１３２の処理を省略する。

加えて、ネットワークブートプログラム１３１に制御を移す前に、起動イメージバージョン比較部１６０の比較結果を取得して、中央管理装置１２０の起動イメージのバージョンが起動イメージ１３４のバージョンよりも大きい場合に、ネットワークブートプログラム１３１に制御を移す。

中央管理装置１２０の起動イメージのバージョンが起動イメージ１３４のバージョンよりも新しくない場合は、ネットワークブートプログラム１３１の処理を省略する。なお、中央管理装置１２０の起動イメージのバージョンと、起動イメージ１３４のバージョンが等しい場合は、起動イメージ１３４を用いて起動してもよい。

次に、バージョン番号の定義方法について説明する。

バージョン番号の定義方法の一つは、起動イメージの作成、更新日時の情報をバージョン番号とすることである。時間の分解能は、起動イメージの新旧を比較できる程度として、例えば、年、月、日、時、分、秒を用いるものとする。なお、中央管理装置１２０と起動装置１２１間でバージョン番号を比較可能とするために、中央管理装置１２０、起動装置１２１間で時刻を同期している必要がある。時刻同期の方法としては、ＮＴＰ（ＮｅｔｗｏｋＴｉｍｅＰｒｏｔｏｃｏｌ）、全地球測位システムＧＰＳ、ＩＥＥＥ１５８８等の方法が例示される。

あるいは、起動イメージが作成、更新されるたびに、連番でバージョン番号を定義する方法が例示される。この場合、中央管理装置１２０と起動装置１２１間でバージョン番号が連番となるように、相互に通信する方法が挙げられる。

図２８に、バージョン番号を連番で設定する方法を示す。図２８は、中央管理装置１２０、起動装置１２１それぞれで実行する方法である。

はじめに、通信相手の起動イメージのバージョンを取得する（処理ステップＳ１１０）。次に、取得した通信相手の起動イメージのバージョンが、自身の有する起動イメージのバージョンより新しいかどうかを判定する（処理ステップＳ１１１）。

取得した通信相手のバージョンが、自身のバージョンより新しい場合は、新しく設定する起動イメージのバージョンを、取得したバージョンに１を加えた値とする（処理ステップＳ１１２）。なお、自身でバージョンを設定していない場合は、取得した通信相手のバージョンの方が新しいものとする。

処理ステップＳ１１１で、取得した通信相手のバージョンが、自身のバージョンより新しくない場合は、自身のバージョンが設定されているかを判定する（処理ステップＳ１１３）。自身のバージョンが設定されている場合は、新しく設定するバージョンを、自身のバージョンに１を加えた値とする（処理ステップＳ１１４）。

処理ステップＳ１１３で、自身のバージョンが設定されていない場合は、新しく設定するバージョンとして１を設定する（処理ステップＳ１１５）。

なお、図２８で、バージョンを更新する場合は１を加えているが、所定値でもよい。また、図２８の方法は、起動装置１２１と中央管理装置１２０間で排他的に実行しなければならない。これは、起動装置１２１と央管理装置１２０の起動イメージの更新を同時に実行しない運用としてもよいし、ネットワーク上で同期をとる仕組みを用いてもよい。

図２８は、中央管理装置１２０と起動装置１２１各々でバージョンを決定しているが、中央管理装置１２０で統一的に決定してもよい。これは、起動装置１２１でバージョンが必要となった際に中央管理装置１２０に要求し、中央管理装置１２０が新しいバージョン番号を発行する方法である。この方法では、全起動装置１２１の要求を中央管理装置１２０で管理するため、中央管理装置１２０、起動装置１２１のバージョン番号が重複しないように割り当てることができる。

バージョン番号の所在について説明する。割り当てたバージョン番号は、起動イメージ中の所定位置に埋め込む方法や、所定ファイル中に記憶する方法が例示される。バージョン番号を有するファイル名は起動イメージと関連付けた名称にすることが例示される。一例としては、起動イメージのファイル名の拡張子を”．ｖｅｒｓｉｏｎ”等にすることが例示される。あるいは、起動イメージの情報をキー、バージョン番号を値とするデータベースとして構成してもよい。

また、バージョン管理システムと連携して、バージョンの取得、大小を比較してもよい。起動イメージの作成、更新時にバージョン管理システムを登録することで、固有の識別子を起動イメージに割り当てることができる。識別子自体を用いて新旧を比較できる場合もあれば、識別子と日時情報を対応づけて比較してもよい。

この時に、起動イメージバージョン比較部１６０は、バージョン管理システム対応のソフトウェアの機能を有するものとする。なお、ＯＳ起動後の起動スクリプトとして、起動イメージバージョン比較部１６０を構成し、処理後にシステムを再起動してもよい。

また、バージョン管理システムにおけるタグやブランチと関連付けて、バージョンを比較してもよい。タグとは、バージョン管理における特定のバージョンに対する名称であり、ブランチとは、主流の開発履歴から分岐した開発の履歴である。例えば、タグのみをバージョン比較の対象とすることや、同じブランチ上でのみバージョンを比較する方法が例示される。

以上説明した実施例３により、実施例１、実施例２と比較して、起動イメージバージョン比較部１６０をそなえることにより、中央管理装置１２０と起動装置１２１間での起動イメージの新旧関係を、より適切に判定することができる。

実施例１、２の効果に加え、中央管理装置１２０の起動イメージが更新されたかどうかを判定することで、ネットワークブートが必要かどうかを判定することができる。

また、起動イメージ１３４が最新で、ネットワークブートが不要な場合は、実行しない。これにより、無駄な通信を避けることができ、また、中央管理装置１２０への通信の集中を防止することができ、システム全体で高速な起動が可能となる。

次に起動装置の仮想化を実現する実施例４について説明する。実施例４は、実施例１、実施例２、実施例３と比較して、複数の起動装置１２１を１つの中央管理装置１２０に仮想化して集約した構成である。実施例に使用する符号は、特に断りのない限り、実施例１、実施例２、実施例３で説明した機能や要素等と同一であることを意味する。

実施例４の発明を適用したシステム例を図２９に示す。ここでは、中央管理装置１７０は、図１のシステム構成と比較して、ネットワーク１２２がなくなり、制御対象１２４で構成される制御用ネットワーク１２３を制御する起動装置の機能を複数仮想化して搭載する。

このときの中央管理装置１７０のハードウェア構成を図３０に示す。

通信部１８０は、制御用ネットワーク１２３との通信機能を実装した送受信機ＩＣである。通信部１８０の実装例としては、ＦＰＧＡ（Ｆｉｅｌｄ−ＰｒｏｇｒａｍｍａｂｌｅＧａｔｅＡｒｒａｙ）、ＣＰＬＤ（ＣｏｍｐｌｅｘＰｒｏｇｒａｍｍａｂｌｅＬｏｇｉｃＤｅｖｉｃｅ）、ＡＳＩＣ（ＡｐｐｌｉｃａｔｉｏｎＳｐｅｃｉｆｉｃＩｎｔｅｇｒａｔｅｄＣｉｒｃｕｉｔ）、ゲートアレイ、ＩＥＥＥ８０２．３のＭＡＣ（ＭｅｄｉａＡｃｃｅｓｓＣｏｎｔｒｏｌ）層の処理ＩＣ、ＰＨＹ（Ｐｈｙｓｉｃａｌ）層の処理ＩＣ、ＭＡＣ、ＰＨＹの一体型ＩＣが例示される。なお、通信機能の一部がＣＰＵ１０１に含まれていてもよい。

また、制御用ネットワーク１２３ごとに通信部１８０を図示しているが、複数の制御用ネットワーク１２３と通信できるように通信部１８０を構成してもよい。

中央管理装置１７０は、複数の制御用ネットワーク１２３を制御するため、複数の通信部１８０を有する。通信部１８０の搭載数は、必要な制御用ネットワーク１２３の数である。

この場合に、中央管理装置１７０のＣＰＵ１０１上で動作するソフトウェア構成を図３１、または図３２に示す。これらの図において、１９３は仮想化された起動装置である。１９０は、仮想化起動装置１９３を管理する仮想化管理ソフトウェアである。さらに図３２において２００はホストＯＳであり、２０１はアプリケーションである。

このうち、仮想化起動装置１９３は、起動装置１２１における制御機能をソフトウェアで実現して中央管理装置１７０内に位置づけた仮想マシンである。仮想化起動装置１９３内では、例えば、ゲストＯＳ１９１、アプリケーション１９２が動作している。また、仮想化通信部１９４は、仮想化起動装置１９３内における仮想的な通信部である。

なお、ゲストＯＳ１９１は、仮想マシン上で動作するＯＳであり、通常のホストＯＳと同様の場合もあり、仮想マシン用に最適化されている場合もある。また、アプリケーション１９２は、制御用ネットワーク１２３の制御対象１２４を制御、管理するアプリケーションである。

これに対し、仮想化管理ソフトウェア１９０は、仮想マシンを動作、管理するためのソフトウェアである。生成する仮想化起動装置１９３の数は、集約する起動装置１２１の数である。

仮想化管理ソフトウェア１９０内の仮想ネットワーク管理部１９５は、仮想化起動装置１９３間の通信や、仮想マシンから仮想マシン以外との入出力を管理する。例えば、仮想化起動装置１９３から、中央管理装置１７０外部の制御対象１２４へパケットを送信する際に、仮想化通信部１９４から送信されたパケットを通信部１８０から送信する機能を担う。

また、仮想ネットワーク管理部１９５は、所定の仮想化起動装置１９３の仮想化通信部１９４と所定の通信部１８０を対応づける。これは、特定の制御用ネットワーク１２３を制御する仮想化起動装置１９３を特定するためである。

仮想化管理ソフトウェア１９０内のブートサーバ１９６は、動的ホスト構成プロトコルＤＨＣＰ、ＴＦＴＰ（ＴｒｉｖｉａｌＦｉｌｅＴｒａｎｓｆｅｒＰｒｏｔｏｃｏｌ）を含むブートサーバとしての機能、異なる起動装置毎の起動イメージの管理機能を有する。なお、この機能は仮想化管理ソフトウェア１９０内ではなく、図３２のアプリケーション２０１で実現してもよいし、あるいは中央管理装置１２０を仮想マシン（仮想化中央管理装置）として構成して実現してもよい。

図３２において、ホストＯＳ２００は、通常のＯＳである。また、アプリケーション２０１は、ホストＯＳ２００上で動作するアプリケーションであり、仮想化管理ソフトウェア１９０の設定、状態取得機能を含む。

なお、仮想化起動装置１９３内のソフトウェア構成はゲストＯＳ１９１を含むが、起動装置１２１のソフトウェア構成を模擬するため、ＯＳを含まない構成でもよい。

このように構成することで、制御用ネットワーク１２３と起動装置１２１を用いて、サブシステムを開発する。サブシステムの開発後は、起動装置１２１を中央管理装置１７０に接続することで、開発物となる起動イメージ１３４を中央管理装置１７０にアップロードする。通常稼働時は、起動装置１２１を取り外して、制御用ネットワーク１２３と接続してシステムを構成する。

次に経路制御部のある構成について説明する。起動装置１２１の別の構成として、図３３に示すハードウェア構成が例示される。この構成を図３０と比較すると、経路制御部２１０が設けられている点で相違する。

図３３に示すハードウェア構成を有する起動装置１２１の場合は、後述するカットスルーモードにより、起動装置１２１を中央管理装置１７０に接続していてもよい。この場合のシステム構成を図３６に示す。図３６の構成では、図２９の構成において、起動装置１２１を中央管理装置１７０に接続している点で相違する。

図３３の経路制御部２１０は、上位接続通信部１０２、下位接続通信部１０３、バス１１０間の経路を制御する。経路制御部２１０の実装例としては、ＦＰＧＡ（Ｆｉｅｌｄ−ＰｒｏｇｒａｍｍａｂｌｅＧａｔｅＡｒｒａｙ）、ＣＰＬＤ（ＣｏｍｐｌｅｘＰｒｏｇｒａｍｍａｂｌｅＬｏｇｉｃＤｅｖｉｃｅ）、ＡＳＩＣ（ＡｐｐｌｉｃａｔｉｏｎＳｐｅｃｉｆｉｃＩｎｔｅｇｒａｔｅｄＣｉｒｃｕｉｔ）、ゲートアレイ等が例示される。なお、ＣＰＵ１０１に含まれていてもよい。

図３３の経路制御部２１０の経路構成を図３４、図３５に示す。図３４は、上位接続通信部１０２、下位接続通信部１０３を直接接続するカットスルーモードであり、図３５は、上位接続通信部１０２、下位接続通信部１０３それぞれがバス１１０と接続する通常モードである。

図３５のバスプロトコル変換部２２０は、上位接続通信部１０２、下位接続通信部１０３それぞれとのバスプロトコルと、バス１１０のバスプロトコルを変換し、相互に通信可能とする機能部である。

なお、図３４のカットスルーモードでの通信遅延を最小化するために、上位接続通信部１０２、下位接続通信部１０３はそれぞれＰＨＹＩＣとして構成することが望ましい。

図３４のパケット解析部２２１は、パケットフォーマットが所定のフォーマット条件に一致するかを判定する。条件の一例としては、所定の位置に所定値のデータを含むこと等が例示される。

モードの切り替えは、バス１１０経由で設定してもよいし、通信経路上を流れるパケットの内容をパケット解析部が解析して、所定条件に一致した場合に設定してもよい。

図３４のカットスルーモードは、単にパケットを通過させるための接続状態であり、通常稼働時に中央管理装置１７０の仮想化起動装置１９３によって制御用ネットワーク１２３を制御する場合を想定している。これは、起動装置１２１で単にパケットを転送する場合でも、パケット処理遅延がシステム性能に影響を与えることを防止するためである。

図３５の通常モードは、起動装置１２１が制御用ネットワーク１２３を制御する場合や起動装置１２１上の起動イメージ１３４を中央管理装置１７０にアップロードする場面での利用を想定している。

なお、開発完了時の通常モードにおいて、アップロードが完了するまで、下位接続通信部１０３の通信機能を無効化してもよい。具体的には、図７の処理ステップＳ０２２の後、図８の処理ステップＳ０２３の前、図９の処理ステップＳ０２２の後、図１０の処理ステップＳ０２３の前に、下位接続通信部１０３の通信機能を無効化する。

このようにすれば、アップロードが完了して、仮想化起動装置１９３が動作する前に、誤ったパケットが下位接続通信部１０３に接続する制御対象１２４へと通信されるのを防止することができる。

なお、下位接続通信部１０３の通信機能は、仮想化起動装置１９３が所定フォーマットのパケットを送信し、経路制御部２１０がこれを認識することで、再有効化することが例示される。

次に、モード切り替えのタイミングについて説明する。モード切り替えとして、図２０の状態遷移に連動して切り替える方法が例示される。初期状態、開発状態では通常モードとし、開発完了状態、稼働状態でカットスルーモードとする。

あるいは、起動装置１２１が起動イメージ１３４をアップロード後、自動的にカットスルーモードに切り替わってもよい。

あるいは、仮想化起動装置１９３が起動後に起動装置１２１に対して、カットスルーモードに切り替わるように要求を送信してもよい。仮想化起動装置１９３の起動イメージ１３４の起動スクリプトに、経路制御部２１０のモードを切り替えるプログラムを含めて構成する方法が例示される。また、起動装置１２１は、そのような要求を受信する通信プログラムが必要である。

あるいは、起動装置１２１として、ＩＥＣ６１７８４のパート２で定義されるＥｔｈｅｒＣＡＴ（登録商標）として、カットスルーモードを構成してもよい。ＥｔｈｅｒＣＡＴスレーブとして構成する場合は、所定のアドレス空間に起動イメージ、起動イメージに関する情報（サイズ等）を配置する。こうすることで、中央管理装置１７０から起動イメージを取得可能である。

あるいは、図３７のように、複数の起動装置１２１を連結してもよい。システム構成時は、いずれの起動装置１２１においても通常モードで下位接続通信部１０３を無効化することにより、各起動装置１２１中央管理装置１２０の起動イメージ１３４を順番に取得することができる。

この順番を中央管理装置１７０の仮想化起動装置１９３の構成に利用してもよい。例えば、順番に対応する仮想化起動装置１９３の起動イメージとしてもよいし、一つの起動イメージ中のアプリケーションの識別子としてもよい。

以上説明した実施例により、他の実施例と比較し、仮想化管理ソフトウェア１９０を有する中央管理装置１７０と組み合わせることにより、制御用ネットワーク１２３を制御する複数の起動装置を一つの中央管理装置１７０に集約することができる。これにより、他の実施例の効果に加え、システム全体を構築するコストを低減することができる。

１０１：ＣＰＵ
１０：上位接続通信部
１０３：下位接続通信部
１０８：メモリ
１０９：不揮発性記憶媒体
１１０：バス
１２０、１７０：中央管理装置
１２１：起動装置
１２２：ネットワーク
１２３：制御用ネットワーク
１２４：制御対象
１３０：起動プログラム
１３１：ネットワークブートプログラム
１３２：ネットワークアップロードプログラム
１３３：状態記憶部
１３４：起動イメージ
１３５：上位接続通信検知部
１５０：起動イメージ更新検知部
１６０：起動イメージバージョン比較部
１８０：通信部
１９０：仮想化管理ソフトウェア
１９１：ゲストＯＳ
１９２、２０１：アプリケーション
１９３：仮想化起動装置
１９４：仮想化通信部
１９５：仮想ネットワーク管理部
１９６：ブートサーバ
２００：ホストＯＳ
２１０：経路制御部
２２０：バスプロトコル変換部
２２１：パケット解析部

Claims

第１の起動イメージを有する中央管理装置と接続され、停止状態からの立ち上げを行うための起動装置において、
起動装置は第２の起動イメージを保有しており、停止状態からの立ち上げを行う時に前記中央管理装置との間で通信が確立しているときは前記中央管理装置が有する前記第１の起動イメージを入手して起動し、停止状態からの立ち上げを行う時に前記中央管理装置との間で通信が確立してないときは、自己が保有している前記第２の起動イメージで起動することを特徴とする起動装置。
請求項１に記載の起動装置において、
起動装置と前記中央管理装置との間が、第１のネットワークで接続され、通信することを特徴とする起動装置。
請求項１または請求項２に記載の起動装置において、
起動装置は、第２のネットワークを介して制御対象に接続され通信することを特徴とする起動装置。
請求項１に記載の起動装置において、
起動装置は、第２のネットワークを介して制御対象に接続され通信するとともに、前記中央管理装置内に仮想的に構成されていることを特徴とする起動装置。
第１の起動イメージを有する中央管理装置と接続されて通信を行い、停止状態からの立ち上げを行うための起動装置において、
起動装置は、第２の起動イメージと、前記中央管理装置から前記第１の起動イメージを取得して起動するブートプログラムと、前記中央管理装置との前記通信が確立しているかどうかを検出する上位接続検知部とを備え、停止状態からの立ち上げ時に前記上位接続検知部の検知結果をもとに、前記第２の起動イメージによる起動、または前記ブートプログラムにより入手した第１の起動イメージによる起動のうち、いずれかを実行することを特徴とする起動装置。
請求項５記載の起動装置において、
起動装置は、前記中央管理装置へ前記第１の起動イメージを送信するアップロードプログラムを備え、停止状態からの立ち上げ時に前記上位接続検知部の検知結果をもとに、前記第２の起動イメージによる起動、前記ブートプログラムにより入手した第１の起動イメージによる起動、前記アップロードプログラムにより前記第２の起動イメージを前記中央管理装置へ送信する処理のうち、少なくとも一つを実行することを特徴とする起動装置。
請求項６記載の起動装置において、
前記中央管理装置との通信が確立していない場合は、前記第２の起動イメージによって起動し、前記中央管理装置との通信が確立している場合は、前記中央管理装置の有する前記第１の起動イメージを取得して起動し、前記中央管理装置との通信が確立していない場合の起動動作時の次の起動時に、前記中央管理装置との通信が確立している場合は、前記第２の起動イメージを前記中央管理装置へ送信することを特徴とする起動装置。
請求項７に記載の起動装置において、
前記中央管理装置から前記中央管理装置の有する前記第１の起動イメージを取得して起動することに失敗した場合に、前記起動装置の前記第２の起動イメージを用いて起動することを特徴とする起動装置。
請求項５乃至請求項８のいずれかに記載の起動装置において、
起動装置は、前記第２の起動イメージが更新されたかどうかを判定する起動イメージ更新検知部を備え、前記起動イメージ更新検知部の検知結果をもとに、前記アップロードプログラムにより前記第２の起動イメージを前記中央管理装置へ送信する処理を実行することを特徴とする起動装置。
請求項９に記載の起動装置において、
前記起動イメージ更新検知部は、ファイルの属性に基づいて、前記第２の起動イメージが更新されたかを判定することを特徴とする起動装置。
請求項９または請求項１０に記載の起動装置において、
前記起動イメージ更新検知部は、所定命令が実行されたかどうかに基づいて、前記第２の起動イメージが更新されたかを判定することを特徴とする起動装置。
請求項５から請求項１１のいずれかに記載の起動装置において、
起動装置は、前記第２の起動イメージのバージョンと、前記中央管理装置の前記第１の起動イメージのバージョンの新旧を比較する起動イメージバージョン比較部を備え、前記起動イメージバージョン比較部の検知結果をもとに、前記第２の起動イメージによる起動、前記ブートプログラムにより前記中央管理装置から入手した前記第１の起動イメージによる起動のうち、いずれかを実行することを特徴とする起動装置。
請求項１２に記載の起動装置において、
起動装置は、前記起動イメージバージョン比較部の検知結果をもとに、前記第２の起動イメージによる起動、前記ブートプログラムにより前記中央管理装置から入手した前記第１の起動イメージによる起動、前記アップロードプログラムにより前記第２の起動イメージを前記中央管理装置へ送信する処理のうち、少なくとも一つを実行することを特徴とする起動装置。
請求項５から請求項１３のいずれかに記載の起動装置において、
起動装置と前記中央管理装置との間が第１のネットワークで接続され、通信することを特徴とする起動装置。
請求項５から請求項１４のいずれかに記載の起動装置において、
起動装置は、第２のネットワークを介して制御対象に接続され通信することを特徴とする起動装置。
請求項５から請求項１３のいずれかに記載の起動装置において、
起動装置は、第２のネットワークを介して制御対象に接続され通信するとともに、前記中央管理装置内に仮想的に構成されていることを特徴とする起動装置。
第１の起動イメージを有する中央管理装置と停止状態からの立ち上げを行うための起動装置が接続され、起動装置は第２のネットワークを介して制御対象に接続され通信するネットワークシステムにおいて、
前記起動装置は第２の起動イメージを保有しており、停止状態からの立ち上げを行う時に前記中央管理装置との間で通信が確立しているときは前記中央管理装置が有する前記第１の起動イメージを入手して起動し、停止状態からの立ち上げを行う時に前記中央管理装置との間で通信が確立してないときは、自己が保有している前記第２の起動イメージで起動することを特徴とするネットワークシステム。
請求項１７に記載のネットワークシステムにおいて、
前記起動装置と前記中央管理装置との間が、第１のネットワークで接続され、通信することを特徴とするネットワークシステム。
請求項１７または請求項１８に記載のネットワークシステムにおいて、
前記起動装置は、前記中央管理装置内に仮想的に構成されていることを特徴とするネットワークシステム。