(57)【要約】    【課題】  デバッグが容易で、試作機の破壊を防止でき、二次バグが発生し難く、プログラムの流用性が良好で、しかも、プログラムのセキュリティが高く、且つプログラムの視認性を向上できるプログラムの作成方法及びそのプログラムを提供する。    【解決手段】  機器の動作を記述する機器動作制御部分と、プログラムの流れを制御するプログラムフロー制御部分とを分離して記述した。【選択図】      図１
2005174245.tif 000002
【特許請求の範囲】
【請求項１】
機器を制御する制御装置により実行されるプログラムを作成するプログラム作成方法であって、
前記プログラムは、前記機器の動作を記述する機器動作制御部分と、前記プログラムの流れを制御するプログラムフロー制御部分とを分離して記述したことを特徴とするプログラム作成方法。
【請求項２】
前記機器動作制御部分は、テーブル形式で記述し、前記プログラムフロー制御部分は、前記機器動作制御部分を記述したテーブルに対する演算子として前記機器動作制御部分と切り分けて記述したことを特徴とする請求項１に記載のプログラム作成方法。
【請求項３】
前記機器動作制御部分を記述したテーブルは複数存在し、前記複数のテーブル間には、無関係を含む複数の形態の関係を備え、且つ前記複数のテーブル間に備えられた複数の形態の関係に対応したプログラム作成フロー制御工程を備え、前記複数のテーブル間に備えられた複数の形態の関係によって前記適切なプログラム作成フロー制御工程を対応させることを特徴とする請求項１に記載のプログラム作成方法。
【請求項４】
前記複数のテーブルの属性と前記複数のテーブル間に備えられた複数の形態の関係とを所定の方式によって記述し、前記所定の方式を入力として、プログラム作成フロー制御用プログラムコードと前記機器動作制御部分用のテーブルとを生成することを特徴とする請求項３に記載のプログラム作成方法。
【請求項５】
前記所定の方式とは、図式であることを特徴とする請求項４に記載のプログラム作成方法。
【請求項６】
前記制御装置は、コンピュータであることを特徴とする請求項１に記載のプログラム作成方法。
【請求項７】
機器を制御する制御装置により実行されるプログラムであって、
前記機器の動作を記述する機器動作制御部分と、前記プログラムの流れを制御するプログラムフロー制御部分とを分離して記述したことを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、機器を制御するマイクロコンピュータ等の制御装置により実行されるプログラムを作成するプログラム作成方法及びそのプログラムに関する。
【背景技術】
【０００２】
従来、機器に組み込まれ且つマイクロコンピュータ等の制御装置によって実行されるプログラムを用いることが知られている（例えば、特許文献１参照）。
【０００３】
斯かるプログラムにおいては、機器制御アプリケーション（機器動作制御部分）と、プログラム自体の制御コード（プログラムフロー制御部分）とが混在しているために、それぞれを独立して開発することができず、また、不具合が発生しても、機械部（メカ）を動かす必要があるので、問題点の切り分けが難しかった。
【０００４】
また、変更を行う場合でも、アプリケーションの制御を変更するためには、プログラムの制御の変更を伴うため、二次バグ等が発生し易かった。
【０００５】
図８は、従来のプログラム組み込み型機器の構成を示すブロック図であり、同図において、８００はプログラム組み込み型機器で、制御基板８０１と制御対象機器８０２とを有している。
【０００６】
制御基板８０１は、制御対象機器８０２を制御するものである。制御基板８０１は、マイクロプロセッサ（ＣＰＵ：中央処理装置）８０１１、ＲＯＭ（リードオンリーメモリ）８０１２、ＲＡＭ（ランダムアクセスメモリ）８０１３、Ｉ／Ｏ８０１４、バス８０１５を有している。ＣＰＵ８０１１は、プログラム組み込み型機器８００全体の制御を司るものである。ＲＯＭ８０１２は、プログラムを格納するものである。ＲＡＭ８０１３は、ワークエリア等に使用するものである。Ｉ／Ｏ８０１４は、制御対象機器８０２とのインタフェースを行うものである。バス８０１５は、ＣＰＵ８０１１、ＲＯＭ８０１２、ＲＡＭ８０１３及びＩ／Ｏ８０１４を、相互に接続するものである。
【０００７】
制御対象機器８０２は、モータ８０２１，８０２３，８０２５，センサ８０２２，８０２４，８０２６、クラッチ８０２７、ソレノイド８０２８、メカ(機械部)８０２９，８０３０，８０３１，８０３２，８０３３を有している。メカ８０２９〜８０３３は、相互に作用するように構成されている。そして、メカ８０２９〜８０３３を、モータ８０２１，８０２３，８０２５、クラッチ８０２７、ソレノイド８０２８等で駆動し、センサ８０２２，８０２４，８０２６でメカ８０２９〜８０３３の状態を検知できるようになっている。また、Ｉ／Ｏ８０１４を通じてＣＰＵ８０１１でＲＯＭ８０１２内のプログラムに従って、プログラム組み込み型機器８００全体の動作を制御する。
【０００８】
次に、従来のプログラムの機器動作制御部分とプログラムフロー制御部分について、図９及び図１０を用いて説明する。
【０００９】
図９及び図１０は、従来のプログラムにおいて、機器動作制御部分とプログラムフロー制御部分とが混在していることを説明するための図である。
【００１０】
図９は、機器の動作を規定する機能部（機器動作制御部分）の動作の流れを示すフローチャートで、機器制御アプリケーションである。ここで、機器の例としては、ページプリンタを想定している。
【００１１】
図９において、先ず、ステップＳ９０１で、機器の給紙部における用紙供給カセットから未印刷の用紙をピックアップする。また、エラーが有れば本処理動作を終了し、エラーが無ければ次のステップＳ９０２へ進む。
【００１２】
ステップＳ９０２では、前記ステップＳ９０１においてピックアップした用紙を、機器の紙搬送部により印刷ステージまで搬送する。また、エラーが有れば本処理動作を終了し、エラーが無ければ次のステップＳ９０３へ進む。
【００１３】
ステップＳ９０３では、前記ステップＳ９０２において印刷ステージまで搬送した用紙を印刷ステージに搭載する。また、エラーが有れば本処理動作を終了し、エラーが無ければ次のステップＳ９０４へ進む。
【００１４】
ステップＳ９０４では、前記ステップＳ９０３において印刷ステージに搭載した用紙に印刷する。また、エラーが有れば本処理動作を終了し、エラーが無ければ次のステップＳ９０５へ進む。
【００１５】
ステップＳ９０５では、前記ステップＳ９０４において印刷した用紙を印刷済み用紙トレイに搬送した後、本処理動作を終了する。また、エラーが有れば本処理動作を終了する。
【００１６】
図１０は、プログラムフロー制御部分の動作の流れを示すフローチャートで、図９における機器動作制御部分の動作の流れを示すフローチャートをプログラムのフローチャートにしたものである。
【００１７】
図１０において、プログラムの動作を開始すると、まず、ステップＳ１００１で、機器の給紙部における用紙供給カセットから未印刷の用紙をピックアップする。
【００１８】
次に、ステップＳ１００２へ進んで、エラーの有無を判断する。そして、エラーが有る場合は本処理動作を終了し、エラーが無い場合は次のステップＳ１００３へ進む。
【００１９】
ステップＳ１００３では、前記ステップＳ１００１においてピックアップした用紙を、機器の紙搬送部により印刷ステージまで搬送し、その後、次のステップＳ１００４へ進む。
【００２０】
ステップＳ１００４では、エラーの有無を判断する。そして、エラーが有る場合は本処理動作を終了し、エラーが無い場合は次のステップＳ１００５へ進む。
【００２１】
ステップＳ１００５では、前記ステップＳ１００３において搬送した用紙を印刷ステージに搭載し、その後、ステップ１００６へ進む。
【００２２】
ステップＳ１００６では、エラーの有無を判断する。そして、エラーが有る場合は本処理動作を終了し、エラーが無い場合は次のステップＳ１００７へ進む。
【００２３】
ステップＳ１００７では、前記ステップＳ１００５において印刷ステージに搭載した用紙に印刷し、その後、次のステップＳ１００８へ進む。
【００２４】
ステップＳ１００８では、エラーの有無を判断する。そして、エラーが有る場合は本処理動作を終了し、エラーが無い場合は次のステップＳ１００９へ進む。
【００２５】
ステップＳ１００９では、前記ステップＳ１００７において印刷した用紙を印刷済み用紙トレイに搬送した後、次のステップＳ１０１０へ進む。
【００２６】
ステップＳ１０１０では、エラーの有無を判断する。そして、エラーが有る場合は、本処理動作を終了し、エラーが無い場合も、本処理動作を終了する。
【００２７】
図９に示すように、機器の動作を記述する時点では、プログラムの流れを制御するようなフローチャートの要素は必要としていないが、図１０に示すように、プログラムのフローチャートを記述する時点では、機能フローチャートで複文の形になっていたところは２つの要素に分離し、機器制御動作の実行と、その結果の判定によるプログラムフローの制御とに分かれている。図１０に示すように、プログラムのフローチャートでは、プログラム構成要素として、分岐判定が必要になっている。
【特許文献１】特開平１１−２４９８８５号公報
【発明の開示】
【発明が解決しようとする課題】
【００２８】
上述したように、従来のプログラムにおいては、機器動作制御部分とプログラムフロー制御部分とが混在していたために、流用性に乏しいという問題点があった。
【００２９】
即ち、あるプログラムを流用する際に、機器動作制御部分は同じであるが、プログラムフロー制御部分が異なるといった場合、そのまま流用することができず、流用性に乏しかった。
【００３０】
図１１及び図１２は、機器動作制御部分は同じであるが、プログラムフロー制御部分が異なる場合のフローチャートである。
【００３１】
図１１は、図９においてエラーが発生しない場合の機能フローチャートであり、図１１におけるステップＳ１１０１〜Ｓ１１０５は、「エラーがあれば終了する」という項目が無い点以外は、図９におけるステップＳ９０１〜Ｓ９０５と同じである。
【００３２】
実際のプリンタでは、エラーが発生しないのはメカニカルなものを対象として制御している以上有り得ないことであるが、エラー処理は、正常処理に比べてプログラムサイズが極めて大きいのが一般的である。そのため、開発初期段階においては、メカニカルの動作を早期に確認するため、正常処理だけのプログラミングが多く行われる。
【００３３】
図１２は、図１１の機能フローチャートからプログラムのフローチャートを起したものである。図１０と違って、エラー処理判定のための分岐要素が無い。即ち、図１２におけるステップＳ１２０１〜Ｓ１２０５は、図１０におけるステップＳ１００１，Ｓ１００３，Ｓ１００５，Ｓ１００７，Ｓ１００９と同じである。
【００３４】
図９及び図１０は、プリンタの紙を搬送して印刷するということに関しては同じであるが、図１０と図１２との違いから明らかなように、これをプログラムコードにする場合には、修正が必要である。つまり、そのまま流用することができない。
【００３５】
上記とは逆に、機器動作制御部分は異なるがプログラムフロー制御部分は同じと言った場合も、そのまま流用することができなかった。
【００３６】
図１３及び図１４は、プログラムフロー制御部分が図９及び図１０と同じ場合の一例を示すフローチャートである。
【００３７】
図１３は、機器の動作を規定する機能フローチャートで、機器制御アプリケーションである。ここで、機器の例としては、光カードのリーダーライターを想定している。
【００３８】
図１３において、まず、ステップＳ１３０１で、光カードを外部から挿入した場合にリーダーライター内にローディングする。また、エラーが有れば本処理動作を終了する。
【００３９】
次に、ステップＳ１３０２へ進んで、前記ステップ１３０１においてローディングした光カードを、光カード読取書き込み用のＸＹステージまで、光カード搬送部により搬送する。また、エラーが有れば本処理動作を終了する。
【００４０】
次に、ステップＳ１３０３へ進んで、前記ステップＳ１３０２において搬送した光カードをＸＹステージに搭載する。また、エラーが有れば本処理動作を終了する。
【００４１】
次に、ステップＳ１３０４へ進んで、前記ステップＳ１３０３においてＸＹステージに搭載した光カードからデータを読み取る。また、エラーが有れば本処理動作を終了する。
【００４２】
次に、ステップＳ１３０５へ進んで、前記ステップＳ１３０４においてデータを読み取った光カードを光カード排出口に搬送した後、本処理動作を終了する。また、エラーが有れば本処理動作を終了する。
【００４３】
図１４は、プログラムのフローチャートで、図１３の機能フローチャートをプログラムのフローチャートにしたものである。
【００４４】
図１４において、プログラムの動作を開始すると、まず、ステップＳ１４０１で、光カードを外部から挿入した場合にリーダーライター内にローディングする。
【００４５】
次に、ステップＳ１４０２へ進んで、エラーが有るか否かを判断する。そして、エラーが有る場合は本処理動作を終了し、エラーが無い場合は、次のステップＳ１４０３へ進む。
【００４６】
ステップＳ１４０３では、前記ステップＳ１４０１においてローディングした光カードを光カード読取書き込み用のＸＹステージまで、光カード搬送部により搬送した後、次のステップＳ１４０４へ進む。
【００４７】
ステップＳ１４０４では、エラーが有るか否かを判断する。そして、エラーが有る場合は本処理動作を終了し、エラーが無い場合は、次のステップＳ１４０５へ進む。
【００４８】
ステップＳ１４０５では、前記ステップＳ１４０３において搬送した光カードをＸＹステージに搭載する。
【００４９】
次に、ステップＳ１４０６へ進んで、エラーが有るか否かを判断する。そして、エラーが有る場合は本処理動作を終了し、エラーが無い場合は、次のステップＳ１４０７へ進む。
【００５０】
ステップＳ１４０７では、前記ステップＳ１４０５においてＸＹステージに搭載した光カードからデータを読み取る。
【００５１】
次に、ステップＳ１４０８へ進んで、エラーが有るか否かを判断する。そして、エラーが有る場合は本処理動作を終了し、エラーが無い場合は、次のステップＳ１４０９へ進む。
【００５２】
ステップＳ１４０９では、前記ステップＳ１４０７においてデータを読み取った光カードを光カード排出口に搬送する。
【００５３】
次に、ステップＳ１４１０へ進んで、エラーが有るか否かを判断する。そして、エラーが有る場合は本処理動作を終了し、エラーが無い場合も本処理動作を終了する。
【００５４】
以上説明したように、図１３のプログラムのフローチャートは、図１０のプログラムのフローチャートと同じ形をしているが、図１３の機器動作の内容が図９の機器動作の内容と異なっているため、プログラムのコードを流用することができなかった。
【００５５】
これまで述べた例は、フローチャートが異なっている例であったが、フローチャートは全く同じでも、プログラミング言語で実装する際に、使用する言語によって当然のことながらソースコードの記述は異なってくる。アセンブラで記述したソースコードはＣ言語コンパイラでは使えないし、Ｃ言語で記述したソースコードはアセンブラには使えない。また、Ｃ言語の場合は、方言はあるが、各コンパイラに共通に対応可能なソースコードを記述することも可能である。
【００５６】
それに対して、アセンブラを使用して実装する場合には、プラットフォームとなるＣＰＵ（中央処理装置）によって機械語が異なり、その機械語に対応するアセンブラ言語の差異に基づくＣＰＵ依存性が発生してしまう。
【００５７】
従って、アセンブラを使用する場合には、異なる命令体系を持つＣＰＵ毎にソースコードを記述する必要があり、流用性に乏しい。
【００５８】
通常、組み込み型機器制御用プログラムの開発においては、ホストコンピュータ上でプログラミング（プログラム作成）を行い、出来上がったソースコードをクロスコンパイラやクロスアセンブラやリンカ等を用いてオブジェクトコードを作成し、このオブジェクトコードをターゲットシステム（実機）のプログラムメモリにダウンロードして動作させ、デバッグを行う。
【００５９】
これは、組み込み型機器の持つハードウェアリソースが、プログラム開発を行うには不適当なものだからで、ＣＰＵパワー、ＲＯＭ（リードオンリーメモリ）／ＲＡＭ（ランダムアクセスメモリ）等のメモリ容量及び周辺デバイス等は、コストダウン、小型化等の要求により、最小限に抑えるのが一般的である。
【００６０】
そこで、前述したように、ホストコンピュータを用いたクロス開発環境での開発が一般的に行われている。
【００６１】
これに対して、ホストコンピュータ上で動作するプログラムは、コンピュータの持つリソースが潤沢であるため、セルフ開発環境での開発が一般的である。
【００６２】
ホストコンピュータといえども、その能力に比して、開発負荷の重いプログラムを開発する場合には、更に能力の高いコンピュータ上でソフト開発を行うこともある。
【００６３】
ところで、組み込み型機器制御用プログラムにおいては、クロス開発特有の困難が生じる。
【００６４】
即ち、ターゲットシステムを潤沢に用意することからして困難が生じる。
【００６５】
開発対象となる機器に採用される技術は常に進化しており、それに伴って開発費も増加の一途である。量産に移行すれば、量産効果が見込めるため、１台当たりの製造価格は下がるのであるが、新規開発時には、試作機１台当たりの製造価格は非常に高いものとなる。
【００６６】
従って、数量を揃えることが難しい。
【００６７】
また、ソフトウェアの設計後、プログラミングを行い、出来上がったプログラムをテストするに当たって、いきなり実機上でプログラムをテストするのは、高価で数少ない試作機の破壊に繋がり易い。
【００６８】
そこで、実機上で動作させる前に、何らかの手段を用いて充分な事前テストを行った後に、実機上で本来目的とするアプリケーションの機能的なテストを行いたいところであるが、その何らかの手段として、ホストコンピュータ搭載のシミュレータ上でプログラムを動かすのでは、センサやアクチュエータの信号入出力タイミングを発生させるのが難しい。
【００６９】
逆に、実機上ではスタティックなテストは出来ても、ダイナミックな動作テストは、メカニズム部分の破壊に繋がるおそれがあり、いきなりやるわけにはいかない等という問題があった。
【００７０】
そこで、このような問題点をいくらかでも解消できる手段が要望されている。
【００７１】
その１つの手段として、ホストコンピュータ上のシミュレータでテストできる部分と、実機上でテストする方が好ましい部分とを分離し、それぞれの部分を、ホストコンピュータ上と実機上とでテストすることにより、プログラムをテストする場合のリスクを緩和することができる。
【００７２】
なお、近年では、３次元ＣＡＤ(computer aided design：コンピュータ援用設計)システムが普及しつつあり、ホストコンピュータ上に仮想メカニカルシステムを構築して、これを実際のメカニカルの代わりに用いて、テストするプログラムによって仮想メカニカルシステムを制御してテストする方法も行われつつあるが、これもシステムが高価で動作速度も遅いため、実用に供しているとは言い難い。
【００７３】
また、シミュレータでは充分なテストが出来ないために、プログラム制御上のバグを潰しきれず、アプリケーションのデバッグを行うと共に、プログラム制御のデバッグ（コーディング上のデバッグ）をも行う事態に陥り易く、高価で数少ない試作機の占有時間が増え、ソフトウェア以外の電気、メカニカル、光学、等の他分野の検討時間を圧迫するという問題点があった。
【００７４】
また、従来行われているプログラム作成方法では、プログラムのコードを解析・改竄されることへの保護が弱かった。
【００７５】
通常、プログラムはプログラムＲＯＭ内に格納される。
【００７６】
これは、シングルチップマイコンシステムでもマルチチップマイコンシステムでも同様である。
【００７７】
シングルチップマイコンの場合は、プログラムＲＯＭがＣＰＵと同一チップ内に構成されており、プログラムＲＯＭへのアクセス手段として、ＣＰＵバスが外部に開放されていなければ、プログラムＲＯＭの読み出し、解析は比較的困難であるが、ＣＰＵバスが外部に開放されていて外部からプログラムＲＯＭの読み出しが可能な場合は、容易にプログラムを読み出せる。
【００７８】
マルチチップマイコンの場合は、プログラムの読み出しは更に容易で、プログラムＲＯＭをプリント基板から取り外し、ＲＯＭライターを使用して簡単に読み出せる。
【００７９】
こういった読み出しを防ぐような機構も提案されているが、一般的ではない。
【００８０】
一旦プログラムＲＯＭ内のデータ読み出しに成功すれば、後は、逆アセンブルや逆コンパイル等を行うことにより、リバースエンジニアリングし易く、セキュリティ上問題があった。
【００８１】
これは、元々のプログラムが逆アセンブルや逆コンパイルを行い易い形式でＲＯＭに格納されているからである。スタティックに逆アセンブルや逆コンパイルを行い難い形式で、プログラムをＲＯＭに格納することで、セキュリティ上の問題点は軽減される。
【００８２】
また、従来行われているプログラム作成方法では、プログラムの制御とアプリケーションの制御とが混在しており、これが見た目にも両者が混ざってしまい、それぞれについて、どちらかを抜き出して見ることが困難であった。
【００８３】
このことにより、プログラムの見易さを損ない、プログラムの作成やデバッグ、メインテナンス等を困難にしていた。
【００８４】
そこで、本発明は、デバッグが容易で、試作機の破壊を防止でき、二次バグが発生し難く、プログラムの流用性が良好で、しかも、プログラムのセキュリティが高く、且つプログラムの視認性を向上できるプログラムの作成方法及びそのプログラムを提供することを目的とする。
【課題を解決するための手段】
【００８５】
上記目的を達成するために、本発明のプログラム作成方法は、機器を制御する制御装置により実行されるプログラムを作成するプログラム作成方法であって、前記プログラムは、前記機器の動作を記述する機器動作制御部分と、前記プログラムの流れを制御するプログラムフロー制御部分とを分離して記述したことを特徴とする。
【発明の効果】
【００８６】
本発明によれば、デバッグが容易で、試作機の破壊を防ぐことができ、しかも二次バグ等が発生し難く、プログラムの流用性が良好で、プログラムのセキュリティが高まり、更に、プログラムの視認性が良い。
【発明を実施するための最良の形態】
【００８７】
本発明のプログラム作成方法の実施形態について、図面を参照しながら説明する。
【００８８】
［第１の実施形態］
本発明の要旨は、機器を制御する制御装置のプログラムを、前記機器の動作を記述する機器動作制御部分と、プログラムの流れを制御するプログラムフロー制御部分とを明確に分離して記述することである。
【００８９】
また、本発明の要旨は、前記機器動作制御部分はテーブル形式で記述し、前記プログラムフロー制御部分は機器動作制御部分を記述したテーブルに対する演算子として前記機器動作制御部分と切り分けて記述することである。
【００９０】
つまり、実装技術やプラットフォームに依存しないモデルを作成し、それを特定の実装技術やプラットフォームにマッピングすることで、システム開発をアプリケーションと実装技術とに切り離して行うことである。
【００９１】
本実施形態のプログラムは、従来技術と同様、制御対象機器内のＲＯＭ（リードオンリメモリ）に格納され、機器内のＣＰＵ（中央制御装置）によって読み出されて実行されるものとする。
【００９２】
一部のオブジェクト指向手法では、ＲＤＢ（リレーショナルデータベース）を基本としてオブジェクト（またはクラス）とオブジェクト（またはクラス）間の関係を記述して、プログラムのソースコードを自動生成するものがある。
【００９３】
データベースは、テーブルとテーブルとの間の関係を表したものであることから、本手法との類似性を連想し易いが、本手法とオブジェクト指向手法との違いは、クラスの標準的な記述方法に見られるように、クラス名・クラスのデータメンバー・クラスの振る舞いが一体となっており、データと振る舞いとが１つのパッケージとして存在するが、本手法では、データと振る舞いとは一体となっておらず、テーブルとテーブルとの間の関係から、別々に作成或いは生成されるものである。
【００９４】
＜順次（シーケンス）条件分岐（選択）反復（リピート）のみで記述可能＞
プログラムを記述する制御構造は、以下の４つに分類することができる。
(1) 逐次実行・・・・・上から下に順番に実行していく通常の実行手順
(2) 条件分岐・・・・・条件を評価し、その結果によって指定した実行文に分岐
(3) ループ制御・・・・条件を評価し、その結果によってループを実行するか否かを判断
(4) 無条件分岐・・・・指定した実行文へ無条件に分岐
ＢｏｈｍとＪａｃｏｐｉｎｉの理論では、どんな論理のプログラムでも順次（Ｓｅｑｕｅｎｃｅ）とＩＦ  ＴＨＥＮ  ＥＬＳＥ(条件分岐)とＤＯ  ＷＨＩＬＥ(ループ制御)の制御構造だけを用いて書けるということを証明している。
【００９５】
（C.Bohm and G. Jacopini,”Flow Diagrams,Turing Machines,and Languages with Only Two Formation Rules,”Communications of the ACM,9(5),1966,366-371）
図１は、ＮＳチャートで表す基本的な３つの構造単位である。
【００９６】
図１（ａ）は順次（Ｓｅｑｕｅｎｃｅ）、図１（ｂ）は選択（Ｉｆ−ｔｈｅｎ−ｅｌｓｅ）、図１（ｃ）は繰返し（Ｄｏ−ｗｈｉｌｅ）、図１（ｄ）は繰返し（Ｄｏ−ｕｎｔｉｌ）である。
【００９７】
図２は、単純にファイルを読み込んで明細印刷する場合の例をフローチャートで示した図、図３は、ＮＳチャートで示した図である。
【００９８】
図２において、プログラム動作が開始すると、先ず、ステップＳ２０１で、ファイルをオープンする。次に、ステップＳ２０２で、ファイルをリードする。次に、ステップＳ２０３で、ＤＯＷＨＩＬＥレコードが有るか否かを判断する。ＤＯＷＨＩＬＥレコードが有る場合は、ステップＳ２０６へ進み、ファイルをクローズした後、本処理動作を終了し、また、ＤＯＷＨＩＬＥレコードが無い場合は、ステップＳ２０４へ進む。ステップＳ２０４では、明細を印刷し、次のステップＳ２０５で、ファイルをリードした後、前記ステップＳ２０３へ戻る。
【００９９】
図３において、ステップＳ３０１ではファイルをオープンし、次のステップＳ３０２ではファイルをリードし、次のステップ３０３ではＤＯＷＨＩＬＥレコードが有ると判断する。次のステップＳ３０４では明細を印刷し、次のステップＳ３０５ではファイルをリードし、次のステップＳ３０６ではファイルをクローズする。
【０１００】
従来は、図２に示すようなフローチャートで記述した場合でも、図３に示すようなＮＳチャートで記述した場合でも、プログラミング言語で実装する場合には、機器動作制御部分とプログラムフロー制御部分とがソースコード中で混在化してしまうのが常であった。
【０１０１】
そこで、本実施の形態では、上述のように機器動作制御部分とプログラムフロー制御部分とを切り離して記述するために、基本的な３つの構造単位のみを階層化して用いることにより実現する。
【０１０２】
図４は、図９の機能フローチャートをテーブル形式で記述した図である。同図において、ステップＳ４０１では、用紙をピックアップする。次のステップＳ４０２では、用紙を印刷ステージまで搬送する。次のステップＳ４０３では、用紙を印刷ステージに搭載する、次のステップＳ４０４では、印刷ステージ上の用紙に印刷する。次のステップＳ４０５では、用紙を印刷済み用紙トレイに搬送する。
【０１０３】
図４のように、機能フリーチャートをテーブル形式で記述するのは書式が単純であるためであり、ドキュメントとして記述するのもプログラムのソースコードとして記述するのも労力的には大差ない。
【０１０４】
図５は、図１０のプログラムフローチャートを書き換えたもので、これは、図４に示すテーブル形式で記述された機能フローチャートを、図１０のフローチャートと等価な動作が行われるようにしたものである。
【０１０５】
図５において、まず、ステップＳ５０１で、テーブルの先頭アドレスを取得し、そのアドレスをテーブルポインタに格納する。次に、ステップＳ５０２で、テーブルポインタがポイントするサブルーチンのアドレスを取得し、そのアドレスをサブルーチンポインタに格納する。次に、ステップＳ５０３で、テーブルポインタを増分して、テーブルの次のアドレスに更新する。次に、ステップＳ５０４で、テーブルが終了か否かを判断する。そして、テーブルが終了であると判断された場合は、ステップＳ５０７へ進んで、テーブルポインタに格納されているアドレスをステック内のプログラムカウンタ退避領域に格納した後、本処理動作を終了する。
【０１０６】
一方、前記ステップＳ５０４において、テーブルが終了でないと判断された場合は、ステップＳ５０５へ進んで、サブルーチンポインタに格納されているアドレスから始まるプログラムを実行する。次に、ステップＳ５０６で、エラーが有るか否かを判断する。そして、エラーが有ると判断された場合は、前記ステップＳ５０７へ進み、また、エラーが無いと判断された場合は、前記ステップＳ５０２へ戻る。
【０１０７】
記述の労力で比較すると、アセンブラ記述よりもフローチャート記述の方が多くの手間がかかる。従って、作業負荷を減らすためには、フローチャート記述が必要な部分をなるべく少なくしたいという要求が発生する。
【０１０８】
図４のテーブルと図１０のフローチャートとで実行される動作は、基本的な３つの構造単位のうち、順次（Ｓｅｑｕｅｎｃｅ）である。
【０１０９】
図６は、メモリイメージを示す図であり、図４の機能フローチャートをテーブル形式で表したものをメモリ上に実装した場合のイメージを示している。
【０１１０】
図６において、アドレス６０１には、機能６０１を実行するプログラムが、アドレス６０２には、機能６０２を実行するプログラムが、アドレス６０３には、機能６０３を実行するプログラムが、アドレス６０４には、機能６０４を実行するプログラムが、アドレス６０５には、機能６０５を実行するプログラムが、それぞれ格納される。
【０１１１】
テーブル形式で機器の制御プログラムを記述しきれるのかという点について疑問視される場合があるが、その点について説明する。
【０１１２】
汎用の各種ＣＰＵには豊富な命令が用意されているが、各命令が平均して使用されているかというと決してそうではなく、命令の使用頻度には大きな偏りが見られる。このことを利用して、使用頻度の高い命令は短いバイト数で表現したり、短いバイト数のコードを別名で割り当てたりすることが行われている（ＴＲＯＮｃｈｉｐ等）。
【０１１３】
組込みリアルタイム制御用途において、使用される命令はＭＯＶ等の転送命令がほとんどで、中には８０％に及ぶ場合もあるといわれている。
【０１１４】
プログラミングを行う上で、ＣＰＵの命令を使用する必要性としては、以下の種類がある。
(1) メモリアクセス（メモリマップトＩ／Ｏの場合）
(2) レジスタアクセス
(3) Ｉ／Ｏ空間がメモリ空間と別空間の場合はＩ／Ｏアクセスもある。
(4) 制御構造記述部
(5) 数値計算部
(6) ＣＰＵ特権命令
特に、組込みリアルタイム制御用途では、数値計算プログラムが用いられることは比較的少ない。
【０１１５】
何故ならば、厳しいリアルタイム性が要求される場合、計算結果が求められる都度、計算を行っていたのでは間に合わない場合が多く、また、計算プログラムによってＣＰＵパワーを占有される結果、全体のパフォーマンスが低下して、更にリアルタイム性の要求に応える事が難しくなるからである。
【０１１６】
従って、計算が必要になる場合には、予め、ホストコンピュータ上で計算しておいて、その計算結果をテーブル形式にして格納し、動作時には、そのテーブルを参照して、計算結果だけを求めるということが良く行われる。
【０１１７】
一例として、ステッピングモータをマイクロコンピュータで動作させる場合がある。
【０１１８】
ステッピングモータを動作させる場合に、まず、所望のパルスを与えて、これを相励磁分配器で各相に分配し、これを電力増幅してステッピングモータ各相の励磁巻線に通電して動作させる。このパルスの周期は、一定速で動作させる場合には不変であるが、加減速制御を行う場合には所望の速度／加速度カーブを描くように増減させる必要がある。
【０１１９】
ところが、パルスの周期をその都度計算していたのでは、高速になった場合には間に合わない。例えば、タイマ割り込みを使用してステッピングモータに与えるパルス幅を生成する場合、２０Ｋｐｐｓの速度では、割り込み間隔が５０μｓｅｃとなり、５０μｓｅｃ以内でパルス幅生成に関わる処理を全て終える必要がある。また、この間に他の仕事を行わせる必要のある場合は、更に使える時間は短くなる。
【０１２０】
仮令間に合ったとしても、ＣＰＵパワーを占有することになり、他のプラグラムが動作する余地がなくなってしまう。
【０１２１】
そこで、周期を予め計算しておいて、周期テーブルとしてメモリに格納することが行われる。例えば、組込みリアルタイム制御用途で使われるＣＰＵの場合、メモリ容量（メモリフットプリント）は少ないのが通常である。また、ＲＯＭ（リードオンリーメモリ）容量＞ＲＡＭ（ランダムアクセスメモリ）容量であることが多い。
【０１２２】
従って、ターゲットＣＰＵで計算して、その計算結果をＲＡＭに格納する方法もあるが、開発ツールとしてのホストコンピュータ上で計算して、その計算結果をＣ言語等の高級言語やアセンブラのテーブルに変換して、クロスコンパイルまたはクロスアセンブルして、ターゲットＣＰＵのバイナリ−コードに変換してＲＯＭに格納する方が、少ないＲＡＭ容量を圧迫しないという利点があるので、良く行われる。
【０１２３】
以上説明したように、組み込み制御用途の場合、テーブルのみでアプリケーションを記述できる可能性が大である。
【０１２４】
前記(1)〜(5)等の部分はテーブル記述に適さない。
【０１２５】
次に、基本的な３つの構造単位をアセンブラ言語で実装した場合の例を示す。
【０１２６】
（株）日立製作所のシングルチップマイクロコンピュータＨ８／３３０において、アセンブラ言語でプログラムを記述した例を示す。
【０１２７】
（Ｈ８／３３０，ＨＤ６４７３３０８，ＨＤ６４３３０８  ハードウェアマニュアル  （株）日立製作所）
アセンブラ言語のサブルーチンとして順次制御を実装した場合について例示する。
【０１２８】
以下は、アプリケーションをテーブル形式で記述した例である。
【０１２９】
ｓｅｑｕｅｎｃｅｒは、順次制御を行う制御構造演算子で、サブルーチンとして実装されている。
【０１３０】
jsr      @sequencer        ;順次制御を行うサブルーチンへのジャンプ
.data.w  check_sensor_no1,error_code;センサ１入力プログラムのエントリアドレス、エラーコード
.data.w  check_sensor_no2,error_code;センサ２入力プログラムのエントリアドレス、エラーコード
.data.w  check_sensor_no3,error_code;センサ３入力プログラムのエントリアドレス、エラーコード
.data.w  clutch_on,e_ok    ;クラッチオンプログラムのエントリアドレス、エラーコード
.data.w  start_motor_no1,e_ok       ;モータ１スタートプログラムのエントリアドレス、エラーコード
.data.w  start_motor_no2,e_ok       ;モータ２スタートプログラムのエントリアドレス、エラーコード
.data.w  start_motor_no3,e_ok       ;モータ３スタートプログラムのエントリアドレス、エラーコード
.data.w  wait_event_no1,e_timeout   ;イベント１ウェイトプログラムのエントリアドレス、エラーコード
.data.w  terminate_sequencer        ;順次制御の終了コード
rts      ;プログラムカウンタをテーブルの次のアドレスに更新する。
【０１３１】
なお、上記の記述において、エラーコード付与方法、サブルーチンまたは関数の引数に影響を与えずにエラーコードをサブルーチンまたは関数を呼び出す側で付与することが可能となり、呼び出し箇所でユニークなエラーコードを割り当てることが可能となっている。
【０１３２】
これにより、同一機能（サブルーチン／関数）を実行した場合でも、エラーが発生した場合には異なるエラーコードを得ることが可能となり、エラーコードによる障害発生箇所の特定が容易になっている。
【０１３３】
上記の順次制御を行うサブルーチンの内容の例を以下に示す
Sequencer
mov.w        @sp,r6   ;テーブル先頭のアドレスをr6
に格納する
seq_continue
mov.w    @r6+,r0  ;r6に格納されたアドレスに格納されているアドレスをr0に格納する
;r6をインクリメントしてテーブルの次のアドレスに更新する
mov.w    terminate_sequencer,r1
cmp.w    r1,r0
beq      seq_end  ;終了条件
jsr      @r0      ;r0に格納されているアドレスから始まるサブルーチンを実行する
beq      seq_continue      ;エラーチェック：ゼロフラグが真ならseq_continueへジャンプする
bne      seq_end  ;エラーチェック：ゼロフラグが偽ならseq_endへジャンプする
seq_end
mov.w    r6,@sp   ;スタック内のプログラムカウンタの値を更新する
rts      ;プログラムカウンタをテーブルの次のアドレスに更新する
アセンブラ言語のサブルーチンとして分岐制御を実装した場合
jsr      @selector;分岐制御を行うサブルーチンへのジャンプ
.data.w  sensor_input      ;条件  センサ入力のサブルーチンのエントリアドレス
.data.w  clutch_on;真の場合に実行するサブルーチンのエントリアドレス
.data.w  clutch_off        ;偽の場合に実行するサブルーチンのエントリアドレス
rts
selector
mov.w    @sp,r6   ;テーブルの先頭アドレスを取得する
mov.w    @r6+,r0  ;サブルーチンsensor_inputのアドレスを取得する
mov.w    @r6+,r1  ;サブルーチンclutch_onのアドレスを取得する
mov.w    @r6+,r2  ;サブルーチンclutch_offのアドレスを取得する
mov.w    r6,@sp   ;スタック内のプログラムカウンタの値を更新する
jsr      @r0      ;サブルーチンsensor_inputを実行する
beq      case_beq ;ゼロフラグが真ならcase_beqへジャンプする
bne      case_bne ;ゼロフラグが偽ならcase_bneへジャンプする
case_beq
jsr      @r1      ;サブルーチンclutch_onを実行する
rts      ;プログラムカウンタをテーブルの次のアドレスに更新する
case_bne
jsr      @r2      ;サブルーチンclutch_offを実行する
rts      ;プログラムカウンタをテーブルの次のアドレスに更新する
アセンブラ言語のサブルーチンとして繰返し制御を実装した場合
jsr      @repeater;繰返し制御を行うサブルーチンへのジャンプ
.data.w  sensor_input      ;条件  センサー入力のサブルーチンのエントリアドレス
.data.w  count_up ;真の場合に実行するサブルーチンのエントリアドレス
rts
repeater
mov.w    @sp,r6   ;テーブルの先頭アドレスを取得する
mov.w    @r6+,r0  ;サブルーチンsensor_inputのアドレスを取得する
mov.w    @r6+,r1  ;サブルーチンcount_upのアドレスを取得する
loop
jsr      @r0      ;サブルーチンsensor_inputを実行する
beq      case_beq ;ゼロフラグが真ならcase_beqへジャンプする
bne      case_bne ;ゼロフラグが偽ならcase_bneへジャンプする
case_beq
jsr      @r1      ;サブルーチンcount_upを実行する
bra      loop     ;loopへ無条件ジャンプする
case_bne
mov.w    r6,@sp   ;スタック内のプログラムカウンタの値を更新する
rts      ;プログラムカウンタをテーブルの次のアドレスに更新する。
【０１３４】
上記の選択制御のテーブルとテーブルの演算子をアセンブラ言語で記述した部分をＣ言語で記述した例を以下に示す。
【０１３５】
Ｃ言語の場合はテーブル名を必要とするので、この場合はselect_tableとしている。テーブルに対する演算子を関数として実装し、引数としてテーブルのアドレスを指定している。アセンブラでの記述とＣ言語での記述に規則的な対応関係を取れるため、相互の変換は簡単である。テーブルを記述することに関しては、Ｃ言語よりもアセンブラの方が簡単明瞭である。
int     selector(select_table);
/*テンプレート定義*/
struct  table
{
void     (*function)()     ;
};
extern  void     sensor_input(void) ;
extern  void     clutch_on (void) ;
extern  void     clutch_off (void) ;
struct  table
select_table []=
{
{     sensor_input      }, //条件  センサ入力のサブルーチンのエントリアドレス
{     clutch_on}, //真の場合に実行するサブルーチンのエントリアドレス
{     clutch_off        }, //偽の場合に実行するサブルーチンのエントリアドレス
};
以上説明したように、テーブル形式でアプリケーションを記述表現できることを示したが、プログラムが細分化されたテーブルの集合となってしまうため、全体像を把握するのが困難になってくる。
【０１３６】
そこで、テーブルの属性とテーブル間の関係を図式的に記述表現して全体像を把握する場合の例を説明する。
【０１３７】
図７は、テーブルの属性とテーブル間の関係を図式的に表現した場合の図であり、テーブルの属性としては、順次、選択、繰返し(DoWhile/DoUntil)を用いており、テーブル間の関係を矢印で示している。
【０１３８】
このような図７を用いることで、細分化された複数のテーブルの関連を視覚的に明瞭に把握することが可能となる。
【０１３９】
更に、テーブルの属性とテーブル間の関係を、マイクロプロセッサの多段間接アドレシングモードに見られるように、多段階の関係にすることも、図式的に表現することも可能である。
【０１４０】
また、図式的に表現されたものから、プログラムのソースコードを自動生成することも可能である。
【０１４１】
本発明によれば、アプリケーションと制御構造を分離して、アプリケーションをテーブル形式で記述することにより、機器組込み制御プログラムにおいて機器制御アプリケーション（機器動作制御部分）とプログラム自体の制御コード（プログラムフロー制御部分）のコードとが独立しており、それぞれを独立開発可能で、不具合が発生した場合に、問題点の切り分けが容易となり、デバッグが容易となった。
【０１４２】
また、独立にテスト可能であるため、試作機の数量や占有時間による制限が軽減され、試作機の破壊を防ぐことができる。
【０１４３】
また、変更を行う場合でも、アプリケーションの制御の変更と、プログラムの制御の変更とを、それぞれ独立して変更できるため、二次バグ等が発生し難くなった。
【０１４４】
また、あるプログラムを流用する際に、機器動作制御部分は同じであるがプログラムフロー制御部分が異なるといった場合、そのまま流用することが可能となった。
【０１４５】
また、上記とは逆に、機器動作制御部分は異なるがプログラムフロー制御部分は同じという場合も、そのまま流用することが可能となった。
【０１４６】
また、異なる言語間での流用性も改善された。
【０１４７】
また、アプリケーションがテーブルで記述されているため、リバースエンジニアリングが難しく、プログラムのセキュリティが高まった。
【０１４８】
更に、テーブル形式で記述することにより、プログラムの視認性が良くなった。
【０１４９】
［その他の実施形態］
以上が本発明の実施形態の説明であるが、本発明は、これら実施形態に限られるものではなく、特許請求の範囲で示した機能、または実施形態の構成が持つ機能を達成できる構成であれば、どのようなものであっても適用可能である。
【図面の簡単な説明】
【０１５０】
【図１】本発明の第１の実施形態に係るプログラム作成方法を説明するための図で、プログラムをＮＳチャートで表す基本的な３つの構造単位を示す図である。
【図２】本発明の第１の実施形態に係るプログラム作成方法を説明するための図で、プログラムをフローチャートで示す図である。
【図３】本発明の第１の実施形態に係るプログラム作成方法を説明するための図で、プログラムをＮＳチャートで示す図である。
【図４】本発明の第１の実施形態に係るプログラム作成方法を説明するための図で、機能フローチャートをテーブル形式で記述した状態を示す図である。
【図５】本発明の第１の実施形態に係るプログラム作成方法を説明するための図で、プログラムフローチャートを書き換えた図である。
【図６】本発明の第１の実施形態に係るプログラム作成方法を説明するための図で、機能フローチャートをテーブル形式で表したものをメモリ上に実装した場合のイメージを示す図である。
【図７】本発明の第１の実施形態に係るプログラム作成方法を説明するための図で、テーブルの属性とテーブル間の関係とを図式的に表した図である。
【図８】一般的な組み込み型機器の構成を示すブロック図である。
【図９】従来のプログラム作成方法により作成されたプログラムの機器動作制御部分とプログラムフロー制御部分とが混在する状態を説明するための図である。
【図１０】図９の機能フローチャートをプログラムのフローチャートにした状態を示す図である。
【図１１】図９と機器動作制御部分はおなじであるが、プログラムフロー制御部分が異なる場合の説明図である。
【図１２】図９においてエラーが発生しない場合の機能フローチャートである。
【図１３】機器の動作を規定する機能フローチャートで、機器アプリケーションである。
【図１４】図１３の機能フローチャートをプログラムのフローチャートにした状態を示す図である。
【符号の説明】
【０１５１】
６０１      アドレス
６０２      アドレス
６０３      アドレス
【図１】
2005174245.tif 000003
【図２】
2005174245.tif 000004
【図３】
2005174245.tif 000005
【図４】
2005174245.tif 000006
【図５】
2005174245.tif 000007
【図６】
2005174245.tif 000008
【図７】
2005174245.tif 000009
【図８】
2005174245.tif 000010
【図９】
2005174245.tif 000011
【図１０】
2005174245.tif 000012
【図１１】
2005174245.tif 000013
【図１２】
2005174245.tif 000014
【図１３】
2005174245.tif 000015
【図１４】
2005174245.tif 000016