(57)【要約】【課題】組み込み機器の制御ソフトウェアに対して、新規または変更要求、不具合修正が発生した場合において、機器の制御を司る実際のソースコードをコーディングすることなく、インターロック処理やアラーム発報などのハードウェア制御を実現し、コーディングミスによる不具合発生を防止する。また、仕様書の記述内容と実際のソースコード処理が不一致によって招かれる混乱状態を防止し、機器の的確な仕様を把握できるようにする。【解決手段】機器本体の作動条件およびそれに対応する作動アクションが一覧表形式で記述された装置管理台帳ファイルを更新し、装置管理台帳ファイルを装置本体の制御用ソフトウェアで認識可能なパラメータファイルに変換し、制御用ソフトウェアを読み込んで動作してパラメータファイルに基づいて作動条件を満たすときに作動アクションを行うことを特徴とする。【選択図】図９
2011018142.tif 000002
【特許請求の範囲】
【請求項１】
機器本体の作動条件およびそれに対応する作動アクションが一覧表形式で記述された装置管理台帳ファイル、該機器本体の制御用ソフトウェア、および、該装置管理台帳ファイルを該制御用ソフトウェアで認識可能なパラメータファイルに変換するための変換プログラムを記憶する記憶装置と、
該制御用ソフトウェアを読み込んで動作して、該変換プログラムを読み込んで該装置管理台帳ファイルを該パラメータファイルに変換すると共に、該パラメータファイルに基づいて該作動条件を満たすときに該作動アクションを該機器本体に行わせる中央処理装置と、
該記憶装置に記憶された該装置管理台帳ファイルの更新手段と、を備えることを特徴とする組み込み機器。
【請求項２】
前記装置管理台帳ファイルには、前記作動アクションとして、アラーム発報処理が記述されていることを特徴とする請求項１に記載の組み込み機器。
【請求項３】
前記装置管理台帳ファイルには、前記作動アクションとして、インターロック処理が記述されていることを特徴とする請求項１に記載の組み込み機器。
【請求項４】
機器本体の作動条件およびそれに対応する作動アクションが一覧表形式で記述された装置管理台帳ファイルを新規作成または更新して機器本体の記憶装置に記憶し、中央処理装置が該装置管理台帳ファイルを該装置本体の制御用ソフトウェアで認識可能なパラメータファイルに変換し、該制御用ソフトウェアを読み込んだ該中央処理装置が該パラメータファイルに基づいて該機器本体を作動させることを特徴とする組み込み機器の制御用ソフトウェア更新方法。
【発明の詳細な説明】
【技術分野】
【０００１】
ハードウェア動作があらかじめ内蔵されたソフトウェアによって制御される組み込み機器、および、そのソフトウェア更新方法に関する。
【背景技術】
【０００２】
近年、組み込み機器の多様化、高機能化に伴い、そこに組み込まれるソフトウェア（以下、単にソフトともいう）の重要性が増している。例として、ディジタルテレビの場合のハードウェア（ただし，電気、電子回路のみ対象）とソフトウェアの開発比重の変遷を図1に示す。2005年前後には，開発工数の約半分がソフトウェア開発に占められている（非特許文献１）。また、カーナビ、ディジタルテレビ、携帯電話に関して、経過年数に対する搭載ソフトウェア総容量（バイト）を示したものが図２である。今やディジタル製品を中心とした精密情報機器、家電、産業機器などの主要技術要素は、組込みソフトウェアと言っても過言ではない（非特許文献２）。
【先行技術文献】
【非特許文献】
【０００３】
【非特許文献１】日経エレクトロニクス、株式会社日経ＢＰ、1998年3月23日号(No.712)
【非特許文献２】日経エレクトロニクス、株式会社日経ＢＰ、2000年9月11月号(No776)
【発明の概要】
【発明が解決しようとする課題】
【０００４】
組込みソフトウェアが肥大化する要因は、開発者個人のスキル、開発手法、組織など様々であり、一概には特定できない。一例として、類似した仕様に対して、同じようなソースコード、関数などの増加による肥大化が挙げられる。当然、開発者がソースコードを書けば、バグ（不具合）を作りこむ可能性が発生し、大きな問題に発展しかねない。特に、大規模組み込みソフトウェア開発でその傾向が強い。よって、類似した処理は、一定の品質が確認できたならば、それを確実に流用することが望ましい。
【０００５】
ところで、一つの品目に対して多機種の製品を有する場合、それらの仕様の把握が難しい、または混乱する場合がある。製品によっては、様々な部位を有し、その都度、各種機器のマニュアル、仕様書などを比較することによって仕様を把握しなければならない。また、一元管理する場合でも、記載内容に信頼性がなければならない。つまり、実際のソースコードに書かれている処理と管理されている記載内容が一致しなければならない。基本的には、このような台帳は、人手によって管理されると想定され、以降で述べるように、ソフトウェア開発現場では様々な状況が考えられるため、漏れ、誤記などの発生が十分に考えられ得る。そのような事態が発生した場合、開発者はその仕様書をもとに設計、開発を行っているため、不具合（バグ）をつくりかねない。また、使用者は仕様書に機器の正しい動作が記載されていることを念頭に操作しているため、大いに混乱し、扱う機器によっては最悪、人命に関わる事態に発展しかねない。
【０００６】
ところで、現状のソフトウェア開発現場にて行われている一般的な業務フローについて考えてみる。正常時の概略フローを図３に示す。使用者から新規・変更要求、バグ修正の要求（ステップ１と呼称）があり、開発者は、その内容に関する仕様書（要求仕様書、機能仕様書、設計仕様書、試験仕様書など）の作成、修正を行い（ステップ２と呼称）、設計、コーディング（プログラミング）作業、試験（ステップ３と呼称）を行う。つまり、望ましい業務フローは、ステップ１からステップ２を経てステップ３の作業に移ることである。
【０００７】
また、使用者から調査や問い合わせが発生した場合、正常時の概略フローを図４に示す。開発者は問われた動作仕様について仕様書の確認（ステップ４）を行い、仕様書における記載内容を得る（ステップ５）。一方、ソースコード（プログラム）の確認（ステップ６）を行い、ソースコードにおける処理内容を得る（ステップ７）。通常であれば、ステップ５の結果とステップ７の結果が等しくなければならない。使用者は仕様書に機器の正しい動作が記載されていることを念頭に操作し、開発者はその仕様書とソースコードの内容が一致しているとして、設計、開発を行っているからである。
【０００８】
ところが、急なトラブルなどが発生した場合、主に時間的な要因により図３のようなフローを遵守することが難しいことが多い。このような異常時の一例の概略フローを図５に示す。使用者から新規・変更要求、バグ修正の要求（前述したステップ１）を受けて、仕様書の作成、修正（ステップ２）と設計、コーディング、プログラミング、試験（ステップ３）が同時に行われるケースである。
【０００９】
他に異常時の一例の概略フローを図６に示す。使用者から新規・変更要求、バグ修正の要求（ステップ１）を受けて、まず、設計、コーディング、プログラミング、試験（ステップ３）に着手し、その後、仕様書の作成、修正（ステップ２）に戻るケースである。
【００１０】
このような異常時が発生すると、仕様書の記載漏れ、記載間違いといった事態を誘発し、仕様書とソースコードの不一致を招く。結果、使用者から調査や問い合わせが発生した場合、図７のような異常時の概略フローを招く。開発者は問われた動作仕様について仕様書の確認（ステップ４）を行い、仕様書における記載内容を得る（ステップ５）。一方、ソースコード（プログラム）の確認（ステップ６）を行い、ソースコードにおける処理内容を得る（ステップ７）。正常であれば、ステップ５の結果とステップ７の結果が等しい。しかし、異常時の場合、ステップ５の結果とステップ７の結果が等しくない事態が発生する。使用者は仕様書どおりに機器が動作しないことに不安や不満を覚え、開発者も正しい動作を把握するのに時間がかかり、余計な開発工数がかさむことになる。
【００１１】
本発明は、組み込み機器の制御ソフトウェアに対して、新規または変更要求、不具合修正が発生した場合において、類似した仕様に対して、実際のソースコードを追加することなく、装置制御台帳への追加、修正することによって仕様を実現できる組み込み機器、およびそのソフトウェア更新方法を提供することを目的とする。結果、必要以上のソースコードの肥大化が防止でき、装置制御台帳がそのまま仕様書になるため、ソースコードと仕様書との不一致が防止できる。
【課題を解決するための手段】
【００１２】
前記の目的を達成するためになされた、特許請求の範囲の請求項１に記載された組み込み機器は、
機器本体の作動条件およびそれに対応する作動アクションが一覧表形式で記述された装置管理台帳ファイル、該機器本体の制御用ソフトウェア、および、該装置管理台帳ファイルを該制御用ソフトウェアで認識可能なパラメータファイルに変換するための変換プログラムを記憶する記憶装置と、
該制御用ソフトウェアを読み込んで動作して、該変換プログラムを読み込んで該装置管理台帳ファイルを該パラメータファイルに変換すると共に、該パラメータファイルに基づいて該作動条件を満たすときに該作動アクションを該機器本体に行わせる中央処理装置と、
該記憶装置に記憶された該装置管理台帳ファイルの更新手段と、を備えることを特徴とする。
【００１３】
請求項２に記載の組み込み機器は、請求項１に記載されたもので、前記装置管理台帳ファイルには、前記作動アクションとして、アラーム発報処理が記述されていることを特徴とする。
【００１４】
請求項３に記載の組み込み機器は、請求項１に記載されたもので、前記装置管理台帳ファイルには、前記作動アクションとして、インターロック処理が記述されていることを特徴とする。
【００１５】
請求項４に記載の組み込み機器の制御用ソフトウェア更新方法は、機器本体の作動条件およびそれに対応する作動アクションが一覧表形式で記述された装置管理台帳ファイルを新規作成または更新して機器本体の記憶装置に記憶し、中央処理装置が該装置管理台帳ファイルを該装置本体の制御用ソフトウェアで認識可能なパラメータファイルに変換し、該制御用ソフトウェアを読み込んだ該中央処理装置が該パラメータファイルに基づいて該機器本体を作動させることを特徴とする。
【発明の効果】
【００１６】
組み込み機器の制御ソフトウェアに対して、新規または変更要求、不具合修正が発生した場合において、機器の制御を司る実際のソースコードをコーディングすることなく、装置管理台帳ファイルに記述することで、インターロック処理やアラーム発報などのハードウェア制御を実現できる。結果、開発者がソースコードを追加、修正、削除をしないため、不具合の誘発を発生しにくい。そして、この方法に従い追加した処理に関しては、仕様書の記述内容と実際のソースコード処理が一致するため、制御機器の使用者が、実際の動作と仕様書の記述の不一致による混乱状態に陥ることを防止できる。
【図面の簡単な説明】
【００１７】
【図１】組み込み機器（ディジタルTV）におけるソフトウェア開発の重要性を示す図である。
【図２】代表的な組み込み機器のソフトウェアサイズの発展を示す図である。
【図３】従来のソフトウェア開発において好ましい形態を示すフロー図である。
【図４】従来のソフトウェア開発における調査、問い合わせのフローにおいて正常の場合を示す図である。
【図５】従来のソフトウェア開発において好ましくない形態を示すフロー図である。
【図６】従来のソフトウェア開発において好ましくない形態を示すフロー図である。
【図７】従来のソフトウェア開発における調査、問い合わせのフローにおいて好ましくない場合を示すフロー図である。
【図８】発明方式によるソフトウェア開発のフローを示す図である。
【図９】発明方式の処理詳細を示す図である。
【図１０】発明方式を説明するための制御ソフトウェア内部構成を示す図である。
【図１１】発明方式における装置管理台帳を示す図である。
【図１２】発明方式においてアラーム定義ファイル（ソースファイル）を示す図である。
【図１３】発明方式においてアラーム定義ファイル（コンパイル結果）を示す図である。
【図１４】本発明を適用する組み込み機器のハードウェア構成を示す図である。
【発明を実施するための形態】
【００１８】
以下、本発明の実施の形態について説明する。
【００１９】
発明したソフトウェア開発の概略フローを図８に示す。組み込み機器の制御ソフトウェアに対して、新規または変更要求、不具合が発生した場合、アラーム発報やインターロック処理など、既に、装置管理台帳に存在する処理の場合、装置管理台帳に対してのみ追加、修正を行う（ステップ８）。装置管理台帳については後述する。
【００２０】
アラーム発報とは、装置が異常状態になった場合、装置画面にそのメッセージが出力されることであり、作業者に装置の異常状態を知らせる手段である。
【００２１】
インターロックとは、制御機器が異常状態を検知した場合、人体の負傷やシステムの損傷を防止するための処理である。制御機器の場合、各種のセンサとコントローラの制御によりシステムの状態を監視し、システム全体、または一部の機能を停止させる働きがある。以下に、主なインターロックの3種類を示す。第一に、人体の負傷を防止するためのインターロックがある。主に、制御機器本体のカバーやドアなどに取り付けられたセンサで、カバーやドアが開けられたときに、コントローラの制御により駆動部の動作、ガスの供給などを停止させる処理である。第二に、システムの損傷を防止するためのインターロックがある。各駆動部に取り付けられたセンサやモータドライバにより、駆動部の動作状態を確認し、可動部位の衝突を防止させる処理である。第三に、制御機器の処理を正常に実行するためのインターロックである。制御機器に設定、指定された値と、取り付けられた各種のセンサにより、圧力、温度、電力などを監視する。制御機器内で定められている適正条件から外れたとき、制御機器の処理を停止させる。
【００２２】
また、この装置管理台帳はそのまま仕様書として使用できる（ステップ９）。使用者はその仕様書の記述を参照して、在るべき機器の動作を確認する（ステップ１０）。一方、装置管理台帳をもとに制御機器に組み込まれた操作が実行されることにより、パラメータファイルを生成する（ステップ１１）。さらに、このパラメータファイルの情報が、制御機器が電源投時、制御ソフト領域に展開される。結果、従来のソースコード処理となる（ステップ１２）。
【００２３】
上記で述べたパラメータファイルの生成、制御ソフト領域への展開を含めて、発明手法の処理過程の詳細を図９に示す。組み込み機器の制御ソフトウェアに対して、新規または変更要求、不具合が発生した場合（ステップA）、アラーム発報やインターロック処理など、既に、装置管理台帳に存在するかどうかを設計者等が判断する（ステップB）。装置管理台帳に存在する処理の場合、装置管理台帳に対してのみ追加、修正を行う（ステップD）。ここで、装置管理台帳に対する追加、修正作業とは、単には装置管理台帳のある升目にフラグ（１か0）を追加、修正することに相当する。装置管理台帳に存在しない処理の場合、要求されている仕様が汎用的な処理または定型化が望まれる処理の場合、その処理のソースコードを追加する（ステップC）。追加後、装置管理台帳に存在する処理の場合、装置管理台帳に対して追加、修正を行う（ステップD）。
【００２４】
装置管理台帳は、一般的な表計算ソフトで作成されており、あらかじめ作成され機器内に組み込まれたマクロファイル（CSV形式で保存する機能を有するマクロファイル）を実行することにより、それは表計算ソフトで作成された装置管理台帳はCSVファイル（カンマ区切りのテキストファイル）に変換される（ステップE）。変換されたCSVファイルは、機器内のコンパイラによって、パラメータファイルに変換され（ステップF）、それは、パラメータとして制御機器ソフト内部のグローバルエリアに展開される（ステップG）。制御機器が電源投入され、制御ソフトウェアの起動に伴い、それらのパラメータ群は、テーブル（制御ソフトウェアのプログラミング言語としてC言語を採用する場合、構造体配列に該当する）に変換される（ステップH）。なお、マクロファイルおよびコンパイラが本発明における変換プログラムに相当する。
【００２５】
以降、使用者が制御機器を使用している最中に、異常事態が発生した場合、制御ソフトウェア内のリアルタイムOS（Operating System）の機能によって、数百ミリ秒で定期的に動作するアラーム監視タスクが、このテーブル情報を参照して、アラーム発報やインターロック処理などを実現する（ステップI）。
【００２６】
以下、本発明の実施の形態についてさらに説明する。本発明の手法は、特に組み込み機器の種類を問わないが、説明の都合上、半導体やフラットパネルなどの基板を処理加工する部位を有する制御機器を想定する。一般的に、それは、組み込み機器の中でも大規模な部類であり、高精度なリアルタイムOSが搭載され、大規模な制御ソフトウェアで構成されるため、ここで示した形態は広範な組み込み機器に適用可能と考えられる。
【００２７】
まず、本発明を適用する組み込み機器のハードウェア構成の一例について、図14を参照しつつ説明する。
【００２８】
同図に示すように、組み込み機器１０は、中央処理装置（CPU:Central Processing
Unit）１１、ハードディスクで構成される記憶装置１２、作業用メモリとして使用されるRAM（Random Access Memory）１３、キーボードで構成される入力装置１４、モニターディスプレイで構成される表示装置１５、USB（Universal Serial Bus）メモリやフレキシブルディスクなどの外部記録媒体にデータを読み書き可能な補助記憶装置１６、ガスセンサ２１、圧力センサ２２、温度センサ２３、電力センサ２４で構成されている。また、組み込み機器１０は、ホストコンピュータに接続されている。中央処理装置１１には、記憶装置１２およびRAM１３が読み書き可能に接続されている。また、中央処理装置１１には、入力装置１４および表示装置１５が接続されて、数値や文字等を入力可能であると共に、画像や数値、文字等を表示可能に構成されている。さらに、中央処理装置１１には、センサ２１〜２４が接続されて、各センサの検出値が入力される。
【００２９】
記憶装置１２には、表計算ソフト、組み込み機器１０のハードウェア動作を制御する制御ソフトウェア、表計算ソフトを用いて作成した組み込み機器１０の作動条件およびそれに対応する作動アクションが一覧表形式で記述された装置管理台帳ファイル、該装置管理台帳ファイルを該制御用ソフトウェアで認識可能なパラメータファイルに変換するための変換プログラム（コンパイラ）、および、パラメータファイルが記憶されている。制御ソフトウェアには、リアルタイムOSが含まれている。
【００３０】
中央処理装置１１は、制御用ソフトウェアを読み込んで動作して、変換プログラムを読み込んで装置管理台帳ファイルをパラメータファイルに変換すると共に、パラメータファイルに基づいて作動条件を満たすときに作動アクションを機器本体に行わせる。なお、中央処理装置１１は、装置管理台帳ファイルをパラメータファイルに一度変換を行えば記憶装置１２に記憶されるので、装置管理台帳ファイルに変更のない限りパラメータファイルへの変換は行わなくてもよい。
【００３１】
また、中央処理装置１１は、入力装置１４をオペレータに操作されることで、表計算ソフトを起動して、装置管理台帳ファイルを開き、一覧表形式の表（ワークシートとも呼ばれる）を表示装置１５に表示する。オペレータは、この表示された表を見ながら入力装置１４を操作して、表に文字や数値を追加、削除などして記憶装置１２に保存することで装置管理台帳ファイルの内容を更新することができる。なお、装置管理台帳ファイルがない場合には、表に文字等を追加して保存することで新規作成することもできる。なお、本発明における装置管理台帳ファイルの更新手段とは、この例では、中央処理装置１１、入力装置１４および表示装置１５がこれに相当する。
【００３２】
なお、装置管理台帳ファイルを、図外のパーソナルコンピュータを用いて、新規に作成したり、一度作成したものを修正したりして、外部記録媒体に記録して、この外部記録媒体を補助記憶装置１６に差し込むなどして、装置管理台帳ファイルを記憶装置１２に記憶させることもできる。この場合、補助記憶装置１６が、本発明における装置管理台帳ファイルの更新手段に相当する。
【００３３】
次に、説明する制御ソフトウェア内部のタスク構成について図10を用いて説明する。勿論、この構成は説明するための例であり、本発明を実施するにはこの限りではない。
【００３４】
通常、作業者が画面から行う指示を受け取り、制御ソフトに指示する働きをするのがマンマシンタスクである。最も作業者に近い上位のタスクとして位置付けられる。制御機器がオンラインでホストコンピュータによって接続されている場合、ホストからの指示を受け取り、制御ソフトに指示する働きをするのがホスト通信タスクである。
【００３５】
マンマシンタスクとホスト通信タスクと他のタスクとのやり取りを行うタスクとして、中継タスクがある。それは、マンマシンタスク、ホスト通信タスクからの指示をイベントとして受け取り、各デバイスやアラーム関連のタスクにそのイベント送信を送信する。または、下位のデバイスタスクからのイベントを受け取り、それをマンマシンタスクまたはホスト通信タスクに送信する。
【００３６】
アラーム発生やインターロック処理を担うアラーム処理タスク群として、アラーム検知タスク、アラーム判定タスク、アラームハンドラタスクが存在する。アラーム検知タスクは、リアルタイムOS規定の間隔で、常時アラーム状態を監視するタスクである。アラーム判定タスクは、アラーム検知タスクからのエラー発生イベントを基に、どのアラームアクションを発行すべきかチェックするタスクである。アラームハンドラは、指定されたアラームコードに応じて、アラーム監視を検索し、エラー状態が発生しているか解除されているのかチェックするタスクである。
【００３７】
制御機器には各デバイスが搭載されている。ここではデバイスとして、ガス、圧力、温度、電力を例とする。このデバイスを制御するデバイスタスクとして、ガスタスク、圧力タスク、温度タスク、電力タスクがある。各々、ガス系統の制御、圧力制御、温度制御、電力制御を行うタスクである。
【００３８】
上記で述べた制御ソフトウェア構成を前提に、本発明手法がどのように実現されるか具体的に説明する。制御機器内に図11に示す装置管理台帳が存在する。同図に示されるように装置管理台帳は一覧表形式で記述されている。装置管理台帳は、アラームコード、検出周期、検出タイプ、ローカルID、検出論理、チェック関数ID、アラーム消去タイミング、アクション列で構成される。アラームコードは、発生するエラーをシンボルで指定したものである。検出周期は、制御ソフトがエラー状態を検出する周期であり、LOW_TYPEを指定すれば、1000ms周期で監視し、HIGH_TYPEを指定すれば、100ms周期で監視する。この検出周期は採用するリアルタイムOSの能力によって異なる。検出タイプとしては、DI_TYPEとCHECK_TYPEが指定できる。DI_TYPEは、ローカルIDで指定されるDI（Digtal
In;ディジタル入力）値の値で制御を行うタイプである。CHECK_TYPEは、制御ソフトのグローバルデータ領域に格納されている変数の値によって、チェック関数番号で指定される処理を行うタイプである。このグローバルデータ領域に格納されている変数は、デバイスタスクなどの制御ソフトが制御機器の状態に従い更新を行う。検出論理として、ACT_LOWを指定すれば、DI値がOFF（0）のとき、アラーム発報ならびにインターロック処理を行う。逆に、ACT_HIGHを指定すれば、ローカルIDで指定されるDI値がON（1）のとき、アラーム発報ならびにインターロック処理を行う。ここで、DI値はセンサやコントローラなどのハードウェアが外界を通じて取得される。アラーム消去タイミングとしては、OFF、NON_AUT、OPE_CONが指定できる。OFFを指定すれば、状況が普及すれば自動消去し、NON_AUTを指定すれば、自動消去せず、該当するデバイスの初期化が正常終了すれば消去し、OPE_CONを指定すれば、作業者の確認、指示によって消去するタイプである。アクションは、検出周期、検出タイプ、検出論理の情報に基づき、行われる処理であり、本発明における作動アクションに相当する。また、検出周期、検出タイプ、ローカルID、検出論理、チェック関数ID、アラーム消去タイミングが、本発明における作動条件に相当する。
【００３９】
例として、アラームコードERR_5で指定される行について説明する。この処理は、DI値の検知タイプであり、100ms周期でDI_CHMB_OPの値を監視し、OFF（0）になれば、アクションで指定されている処理B、処理Cに該当するインターロック処理を行い、アラームコードERR_5で指定されるアラーム発報を行うことになる。発生したアラームは、自動消去されず、該当するデバイスの初期化が正常終了すれば消去される。
【００４０】
他の例として、アラームコードERR_7で指定される行について説明する。この処理は、CHECK_TYPE検知タイプであり、1000ms周期で、チェック関数番号101で指定される処理にもとづき、グローバルデータ領域に格納されている変数の値を監視し、ON（1）になれば、アクションで指定されているプロセスガス停止、処理Aに該当するインターロック処理を行い、アラームコードERR_7で指定されるアラーム発報を行うことになる。発生したアラームは、状況が普及すれば自動消去される。
【００４１】
上記で説明したように、発明手法に従えば、既存のアラーム発報、インターロック処理を実現したければ、アクション列で指定されている各処理に１を立てるだけで実現可能となる。逆に、アクション列で指定されている処理を解除したければ、１を削除すればよい。また、新規のアラーム発報、インターロック処理を実現したければ、既存のそれらに従い、該当する処理を追加するだけで既存の仕組みが流用できる。このように、あらかじめ用意した装置管理台帳のアクション列の値を操作することによって、実際のソースコードに追加、修正、削除をすることなく、アラーム発報、インターロック処理を実現できることが本発明手法の最大の特徴である。
【００４２】
結果、新たな要求が発生しても、開発者がソースコードを追加、修正、削除をしないため、不具合の誘発を発生しにくい。そして、この方法に従い追加した処理に関しては、仕様書の記述内容と実際のソースコード処理が一致するため、それらの不一致による混乱状態を防止でき、瞬時に正確な仕様が確認できる。
【００４３】
しかし、装置管理台帳に追加する処理（上記で述べたアクション）は、文字通り管理上の観点から、汎用的な処理または定型化が望まれる処理に限定すべきである。特殊な機器、特定の条件下の動作は、従来どおり、ソースコードを書くべきである。
【００４４】
図11でみたように、装置管理台帳は表計算ソフトで作成される。これに対してあらかじめ作成され機器内に組み込まれたマクロファイルを実行することにより、一例として図12に示すCSVファイルに変換される。これをアラーム定義テーブル（ソースファイル）と称す。この形式は、C言語における構造体を表し、ErrCodeはエラーコードを示し、DetectCycleは検出周期を示し、DetectTypeは検出タイプを示し、LocalIDはローカルIDを示し、DetectLogicは検出論理を示し、ChkFuncIdはチェック関数IDを示し、Actは検知処理を示し、Dataはスペアを示し、AlmMsg[40]は文字数40のアラームメッセージを示す。
【００４５】
アラーム定義テーブル（ソースファイル）は、機器内の付属コンパイラによって、一例として図13に示すパラメータファイルに変換される。これをアラーム定義テーブル（コンパイル結果）と称す。
【００４６】
このアラーム定義テーブル（コンパイル結果）は、パラメータとして制御機器ソフト内部のグローバルエリア（メモリ）領域上に展開される。制御機器が電源投入され、制御ソフトウェアの起動に伴い、それらの値は、（制御ソフトウェアのプログラミング言語としてC言語を採用する場合、）構造体のメンバとして参照される。
【００４７】
前述したアラーム検知タスクが、装置管理台帳において指定された検出周期（LOW_TYPEを指定すれば、1000ms周期、HIGH_TYPEを指定すれば、100ms周期）でこのグローバルエリア（メモリ）領域に展開されたアラーム定義テーブル情報を監視する。例えば、DI検出タイプの場合、このアラーム検知タスクがDI検出論理の変化（1から0、0から1）を検知したら、アラーム判定タスクにその旨を示すイベントを送信する。
【００４８】
アラーム検知タスクからのイベントを受け取ったアラーム判定タスクは、装置管理台帳に記載されたどのアクションを発行すべきかチェックする。チェックした結果、あるデバイスに対して、インターロック処理を依頼したい場合、該当するデバイスタスクにその旨イベント通知する。デバイスタスクで処理が実行された後、正常終了したのか異常終了だったのか等その旨の終了イベントを中継タスクに送信する。中継タスクは、その情報を画面に表示したい場合、マンマシンタスクにイベント送信し、ホストコンピュータに通知したい場合は、ホスト通信タスクに送信する。
【００４９】
また、アラーム検知タスク同様、アラームハンドラは、装置管理台帳において指定された検出周期（LOW_TYPEを指定すれば、1000ms周期、HIGH_TYPEを指定すれば、100ms周期）でグローバルエリア（メモリ）領域に展開されたアラーム定義テーブル情報を監視する。エラー状態が解除されていれば、装置管理台帳において指定されたアラーム消去タイミングに従い、アラーム消去を行う。アラームハンドラはアラーム検知タスクの中に含めても構わないが、処理の相違を明確にするため、分割している。
【００５０】
以上、開発者が入力した装置管理台帳からアラーム定義テーブル（ソースファイル）を作成し、さらにアラーム定義テーブル（コンパイル結果）が生成され、それがパラメータとして制御機器ソフト内部のグローバルエリア（メモリ）領域上に展開され、アラーム処理タスク群とデバイスタスク群によって、アラーム発報処理ならびにインターロック処理が実現できることを示した。
【符号の説明】
【００５１】
１０は組み込み機器、１１は中央処理装置、１２は記憶装置、１３はＲＡＭ、１４は入力装置、１５は表示装置、１６は補助記憶装置、２１はガスセンサ、２２は圧力センサ、２３は温度センサ、２４は電力センサである。
【図１】
2011018142.tif 000003
【図２】
2011018142.tif 000004
【図３】
2011018142.tif 000005
【図４】
2011018142.tif 000006
【図５】
2011018142.tif 000007
【図６】
2011018142.tif 000008
【図７】
2011018142.tif 000009
【図８】
2011018142.tif 000010
【図９】
2011018142.tif 000011
【図１０】
2011018142.tif 000012
【図１１】
2011018142.tif 000013
【図１２】
2011018142.tif 000014
【図１３】
2011018142.tif 000015
【図１４】
2011018142.tif 000016