JPWO2018042644A1 - 組込みシステムおよび組込みシステム制御方法 - Google Patents

Abstract

読み込み処理を開始する読込開始手段（２１１）と、読み込み処理ごとに読込ＩＤを割り当て、割り当てられた読込ＩＤの数を示す読込ＩＤ数を更新する読込整合開始手段（２１２）と、通信データを読み込む読込手段（２１３）と、読込手段による読み込みを終了する読込終了手段（２１４）と、読込ＩＤと、書き込み処理中であるか否かを示すデータ書込中フラグと、データ書き込み処理時の読込ＩＤ数を示す書込時ＩＤ数と、を取得し、データ書込中フラグ、読込ＩＤ、書込時読込ＩＤ数と、に基づいて読み込まれたデータの整合性を判定する読込整合終了手段（２１５）と、を備えることで誤作動のない制御を可能とする組込みシステム（１００）を提供する。

Description

この発明は共有メモリを備えた組込みシステム、その制御方法および共有メモリへの読み込み処理時のデータ整合性判定方法に関するものである。

機器に組み込まれて当該機器の機能を実現するための制御を主に行う組込みシステムが広く用いられている。組込みシステムでは、組込みシステムが備える複数の機能（ソフトウェアもしくはハードウェア）が共通のデータ（以下、共有データ）にアクセスする必要がある場合、該当する複数の機能が共有する特定のメモリ領域（以下、共有メモリ領域）に対象のデータを記憶する。例えば組込みシステムの通信デバイスが受信したデータが機器の制御に用いられる場合、通信デバイスを制御するソフトウェア（以下、デバイスドライバ）が共有メモリ領域に受信データを書き込み、機器制御ソフトウェア（以下、アプリケーションソフトウェア）が当該領域のデータを読み込む。この仕組みにより、共有メモリ領域内のデータは常に最新の状態に保たれ、アプリケーションソフトウェアは共有メモリ領域内の受信データを読み込むことで動作することができる。

この仕組みでは、受信データの読み込みタイミングはアプリケーションソフトウェアがデータを必要としたとき、受信データによる共有メモリ領域の書き込みタイミングは外部機器から通信パケットを受信した時となり、それぞれ独立したタイミングとなる。そのため、共有メモリ領域への受信データの書き込み中に当該受信データの読み込みを行うと、アプリケーションソフトウェアが読み込んだデータに不整合が発生する場合がある。

このようにアプリケーションソフトウェアが読み込んだデータに不整合が発生しないように共有データの読み込みと書き込みが同時に発生することを防止し、共有データへのアクセス中には他者が同一のデータにアクセスすることを禁止する排他処理が一般的には行われている。具体的な方法としては、共有メモリ領域アクセス時にロックを獲得することで、データ書き込みとデータ読み込みを排他する方法が一般的に用いられている。この方法を用いると、デバイスドライバが受信データにより共有メモリ領域に書き込む前にロックを獲得し、共有メモリ領域書き込み後にロックを解除するようにする。アプリケーションソフトウェアからは受信データの読み込み前にロックを獲得し、読み込み後にロックを解除するようにする。これにより、先にロックを獲得した方が途中で割り込まれることなく優先的に共有メモリ領域にアクセスできるようになり、更新中の共有データをアプリケーションソフトウェアが使用してしまうことがなくなる。

しかし当該排他方法では、アプリケーションソフトウェアからの受信データ読み込みがデバイスドライバによる受信データ書き込みより先行すると、デバイスドライバにより受信データを共有メモリ領域に書き込む処理が長時間待たされてしまう可能性がある。デバイスドライバは通信デバイスや通信プロトコルで規定された厳しい時間制約のもとに動作しており、前記のようにアプリケーションソフトウェアの処理が完了するまで待たされると、通信が継続できなくなり、誤動作を引き起こす可能性があるという問題点があった。

前記の問題を解決するため、共有メモリ領域への受信データの書き込みが共有メモリ領域からのデータの読み込みの完了を待たされることがなく、かつ、共有メモリ領域から読み込まれたデータに不整合が発生しないデータ読み込み方法が求められている。
このような読み込み方法として、受信データに付与された識別記号を用いることでデータ読み込み時に共有メモリ領域に書き込まれているデータの整合性を判定する方法が提案されている（特許文献１）。この方法では、共有メモリ領域へのデータ書き込み時にデータ先頭と末尾に同一の識別記号を付与して書き込み、読み込み時は、まず対象データの先頭と末尾の識別記号を読み込み、一致あるいは不一致によりデータの整合性を判定する。一致している場合はデータ書き込みが完了しているものとしてデータを読み込み、不一致の場合はデータ書き込み中として書き込み完了まで待機する。

さらに、受信データ名と当該受信データが格納されている場所との対応関係表を持ち、データ書き込み終了後に前記対応関係表を更新することで排他を実現する方法が提案されている（特許文献２）。この方法では、共有メモリ領域への書き込み時には領域内に予め確保した未使用領域に書き込むようにし、書き込み終了後に前記対応関係表を更新し、最新のデータ格納場所へと変更する。これにより、読み込み時に書き込み途中であっても対応関係表が更新されていないため古いデータを読み込むことができ、書き込み完了後は対応関係表が更新されているため新しいデータを読み込むことができる。そのため、書き込みと読み込みの処理を独立に行える。

実開平５−０２０１４６号公報 特開平５−１５８８９２号公報

従来の特許文献１に示す技術では、データごとに付与された識別記号により整合性を判定するため、データ単位の整合性しか判定できず、複数データが組み合わせで意味を持つような場合では整合性が判定できないという問題がある。

ここで、複数データの組み合わせで意味を持つような場合の例としては、例えば、ルームエアコンにおいて、ワイヤレスリモコンから運転モード（冷房、暖房など）を示すデータＡと、設定温度（２８℃など）を示すデータＢを受信し、デバイスドライバが共有メモリ領域内のそれぞれのデータを書き込む場合が考えられる。

この例では、元々共有メモリ領域に書き込まれていたデータが「データＡ＝暖房、データＢ＝２５℃」であり、ワイヤレスリモコンから「データＡ＝冷房、データＢ＝２８℃」を受信したときに、データＡのみ書き込みが完了した状態でアプリケーションソフトウェアが共有メモリ領域から受信データを読み込むと、「データＡ＝冷房、データＢ＝２５℃」を読み込んでしまい、データＡとデータＢ間の整合性が無くなり誤動作を引き起こす。

特許文献１に示す技術においても複数データを纏めて１つのデータとして扱えば整合性を判定できるが、読み込みあるいは書き込みするデータが大容量となり、その一部のみを更新したい場合であっても、データ全体を書き込む必要があるため、処理の非効率化を招くことになる。

また、従来の特許文献２に示す技術においてもデータごとの対応関係を利用するため特許文献１と同様にデータ単位での整合性しか判定できないという問題がある。

本発明は前記のような問題点を解決するためになされたもので、共有メモリからのデータの読み込みにおいて読み込まれる複数のデータの整合性を確認することができる、組込みシステムを実現することを目的とする。

上述した課題を解決し、目的を達成するために、本発明の組込みシステムは、アプリケーション部が実行するデータの読み込み処理を開始する読込開始手段と、読込開始手段にて開始されたそれぞれの読み込み処理に読込ＩＤを割り当て、割り当てられた前記読込ＩＤの数を示す読込ＩＤ数を更新する読込整合開始手段と、データを読み込む読込手段と、読込手段によるデータの読み込みを終了する読込終了手段と、読込ＩＤと、書込み処理中であるか否かを示すデータ書込中フラグと、データ書き込み処理時の読込ＩＤ数を示す書込時ＩＤ数と、を取得し、データ書込中フラグ、読込ＩＤ、書込時ＩＤ数と、に基づいて読み込まれたデータの整合性を判定する読込整合終了手段と、を備えるものである。

また、本発明の組込みシステム制御方法は、データ読み込み処理開始時に読み込み処理を識別するための読込ＩＤを割り当てる読込ＩＤ割り当てステップと、共有メモリからデータを読み込むデータ読み込みステップと、データ読み込みステップの終了時に共有メモリから割り当てられた読込ＩＤの数である読込ＩＤ数と、共有メモリへデータ書き込み処理中であるか否かのフラグであるデータ書込中フラグと、共有メモリへのデータ書き込み処理時の読込ＩＤ数である書込時ＩＤ数とを含む整合性情報を取得する整合性情報取得ステップと、整合性情報取得ステップにて取得したデータ書込中フラグが書き込み中ではなく、かつ、読込ＩＤが書込時ＩＤ数よりも大きい場合にデータ読み込みステップにて読み込まれたデータに整合性が有ると判定する整合性判定ステップと、を有するものである。

また、本発明のデータ整合性判定方法は、共有メモリからのデータ読み込み処理開始時に読込開始処理を識別するために割り当てられる読込ＩＤと、割り当てられた読込ＩＤの数を示す読込ＩＤ数と、共有メモリへのデータ書き込み中である否かを示すデータ書込中フラグと、データ書き込み処理時の読込ＩＤ数を示す書込時ＩＤ数と、に基づいて読み込まれたデータに整合性があるか否かを判定するものである。

さらに、本発明のデータ整合性判定方法は、共有メモリからのデータ読み込み終了時に、共有メモリにデータ書き込み中であるか否かと、当該読み込み処理が何番目に開始された読み込み処理であるかと、共有メモリへのデータ書き込み処理時に実行されていた読み込み処理は何番目に開始された読み込み処理まで含んでいるかと、に基づいて読み込まれたデータに整合性があるか否かを判定するものである。

本発明にかかる組込みシステムは、前記の構成を備えるため、共有メモリから読み込む複数のデータに整合性が有ることを保証でき、読み込んだデータの不整合に起因する誤作動のない制御を可能とする。

本発明の実施の形態１における組込みシステム１００のシステム構成の一例を示す構成図である。 本発明の実施の形態１における組込みシステムのソフトウェア２００のソフトウェア構成の一例を示す構成図である。 本発明の実施の形態１における通信データ管理テーブル１２４内の通信データ管理テーブル構造の一例を示すテーブル構造図である。 本発明の実施の形態１における整合性情報データベース１３４内の整合性情報のデータ構造の一例を示すデータ構造図である。 本発明の実施の形態１におけるデータ読込処理部２１０の処理シーケンスの一例を示すフローチャートである。 本発明の実施の形態１における読込ＩＤ管理テーブル１３２読込ＩＤ管理テーブル構造の一例を示すテーブル構造図。 本発明の実施の形態１におけるデータ書込処理部２４０の処理シーケンスの一例を示すフローチャートである。 本発明の実施の形態１における書込ＩＤ管理テーブル１３３内の書込ＩＤ管理テーブル構造の一例を示すテーブル構造図。 本発明の実施の形態１における整合性有無判定の一例を示す説明図である。 本発明の実施の形態１における整合性有無判定の一例を示す説明図である。 本発明の実施の形態１における整合性有無判定の一例を示す説明図である。 本発明の実施の形態１における整合性有無判定の一例を示す説明図である。 本発明の実施の形態１における整合性有無判定の一例を示す説明図である。 本発明の実施の形態１における整合性有無判定の一例を示す説明図である。 本発明の実施の形態１における整合性有無判定の一例を示す説明図である。 本発明の実施の形態１における整合性有無判定の一例を示す説明図である。 本発明の実施の形態１における整合性有無判定の一例を示す説明図である。 本発明の実施の形態１における整合性有無判定の一例を示す説明図である。 本発明の実施の形態２における組込みシステム３００のシステム構成の一例を示す構成図である。 本発明の実施の形態２における組込みシステムのソフトウェア４００のソフトウェア構成の一例を示す構成図である。 本発明の実施の形態２におけるグループ分類管理テーブル１２５内のグループ分類管理テーブル構造の一例を示すテーブル構造図である。 本発明の実施の形態２における整合性情報データベース１３４内の整合性情報のデータ構造の一例を示すデータ構造図である。 本発明の実施の形態２におけるデータ読込処理部２１０の処理シーケンスの一例を示すフローチャートである。 本発明の実施の形態２におけるデータ書込処理部２４０の処理シーケンスの一例を示すフローチャートである。

以下に、本発明にかかる組込みシステムの実施の形態を図面にもとづいて詳細に説明する。以下で参照する図面においては、同一もしくは相当する部分に同一の符号を付している。なお、この実施の形態によりこの発明が限定されるものではない。

実施の形態１．
図１は本発明の実施の形態１に係る組込みシステム１００のシステム構成の一例を示す構成図であり、図２は本発明の実施の形態１に係る組込みシステムのソフトウェア２００のソフトウェア構成の一例を示す構成図である。

図１において、組込みシステム１００はＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１１０、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）１２０、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）１３０、通信デバイス１４０を備え、ＣＰＵ１１０はＲＯＭ１２０に格納された各コード領域のプログラムを実行し、データ読み込みおよび書き込みを制御する制御部であり、ＲＯＭ１２０とＲＡＭ１３０はデータを記録する共有メモリであり、通信デバイス１４０はＵＡＲＴ（Ｕｎｉｖｅｒｓａｌ Ａｓｙｎｃｈｒｏｎｏｕｓ Ｒｅｃｅｉｖｅｒ Ｔｒａｎｓｍｉｔｔｅｒ）などの外部機器とのデータの送受信を行う通信部である。なお、ＲＯＭ１２０とＲＡＭ１３０の詳細は、後述する。

図２において、ソフトウェア２００はアプリブロック２０１と通信制御部２０２とデバイスドライバ２０３により構成され、ＲＯＭ１２０とＲＡＭ１３０に格納されて、ＣＰＵ１１０上で実行される。
ここで、アプリブロック２０１は、製品あるいはシステムごとに作成されるアプリケーションソフトウェア（アプリケーション部）であり、通信制御部２０２からのデータの読み込み、そして読み込んだデータによる製品あるいはシステム独自の制御を行う。通信制御部２０２は、アプリブロック２０１あるいはデバイスドライバ２０３からの要求に応じてＲＯＭ１２０からのデータの読み込み、あるいはＲＡＭ１３０に対するデータの読み込みと書き込みを行う。デバイスドライバ２０３は、通信デバイス１４０や、通信相手により規定される通信プロトコルで規定された通信処理を行う。なお、アプリブロック２０１、通信制御部２０２およびデバイスドライバ２０３の詳細は、後述する。

通信制御部２０２は、データ読込処理部２１０、通信データ保存部２２０、整合性情報保存部２３０、データ書込処理部２４０より構成される。

データ読込処理部２１０は、読込開始処理２１１、読込整合開始処理２１２、読込処理２１３、読込終了処理２１４、読込整合終了処理２１５により構成され、アプリブロック２０１がデータを読み込む際に実行される。なお、データ読込処理部２１０を構成する各処理は、組込みシステム１００を構成する手段に相当する。読込開始処理２１１は、アプリブロック２０１から呼び出されデータ読み込みの処理を開始する。読込整合開始処理２１２は、読込開始処理２１１から呼び出され、整合性情報保存部２３０を、データ読み込み開始を示す状態に更新する。読込処理２１３は通信データ保存部２２０からアプリブロック２０１から読込要求のあったデータを読み込む。読込終了処理２１４は、読込処理２１３から呼び出されデータ読み込み処理を終了する。読込整合終了処理２１５は、読込終了処理２１４から呼び出され、整合性情報保存部２３０を、データ読み込み終了を示す状態に更新する。なお、読込整合開始処理２１２および読込整合終了処理２１５における整合性情報の更新方法の詳細は後述する。

通信データ保存部２２０は、ＲＯＭ１２０に格納された通信データ管理テーブル１２４とＲＡＭ１３０に格納された通信データデータベース１３１により構成される。通信データ管理テーブル１２４は、通信データデータベース１３１内におけるデータ格納位置の管理テーブルであり、データ読込処理部２１０およびデータ書込処理部２４０の読み込みあるいは書き込み処理において参照される。通信データデータベース１３１は、通信デバイス１４０により受信したデータが保存される領域でデータ書込処理部２４０により更新され、常に最新の状態に保たれる。なお、通信データデータベース１３１は受信データのみでなく、送信データを記憶してもよい。

整合性情報保存部２３０は、ＲＡＭ１３０に格納された読込ＩＤ管理テーブル１３２、書込ＩＤ管理テーブル１３３および整合性情報データベース１３４により構成される。読込ＩＤ管理テーブル１３２は、アプリブロック２０１が実行する通信データデータベース１３１からのデータ読み込み処理ごとに割り当てられ、それぞれの読み込み処理の読み込み対象データと対応付けられる読込ＩＤの管理テーブルである。書込ＩＤ管理テーブル１３３は、デバイスドライバ２０３が実行する通信データデータベース１３１へのデータ書き込み処理ごとに割り当てられ、それぞれの書き込み処理の書き込み対象データと対応付けられる書込ＩＤの管理テーブルである。また、整合性情報データベース１３４はアプリブロック２０１が通信データデータベース１３１から読み込んだデータの整合性を判定するための整合性情報を保存するデータベースである。

データ書込処理部２４０は、通信プロトコルで規定された受信タイミングにおいてデバイスドライバ２０３から呼び出されるもので、書込開始処理２４１、書込整合開始処理２４２、書込処理２４３、書込整合処理２４４、書込終了処理２４５、書込整合終了処理２４６により構成される。なお、データ読込処理部２４０を構成する各処理は、組込みシステム１００を構成する手段に相当する。書込開始処理２４１はデバイスドライバ２０３に呼び出され、通信制御部２０２への受信データ書き込みの処理を開始する。書込整合開始処理２４２は書込開始処理２４１から呼び出され、整合性情報保存部２３０を、データ書き込み開始を示す状態に更新する。書込処理２４３は、デバイスドライバ２０３が外部機器から受信したデータを、通信データ保存部２２０へ書き込む処理である。書込整合処理２４４は、書込処理２４３から呼び出され、整合性情報保存部２３０を、データ書き込みを示す状態に更新する。書込終了処理２４５は、書込整合処理２４４から呼び出され、通信制御部２０２への受信データ書き込み処理を終了する。書込整合終了処理２４６は、書込終了処理２４５から呼び出され、整合性情報保存部２３０を、データ書き込み終了を示す状態に更新する。

ＲＯＭ１２０にはアプリブロック２０１、通信制御部２０２を構成するデータ読み込み処理部２１０とデータ書き込み処理部２４０、デバイスドライバ２０３のそれぞれのブログラムコードであるアプリブロックコード１２１、通信制御部コード１２２、デバイスドライバコード１２３、通信データ保存部を構成する通信データ管理テーブル１２４が格納される。ここで、通信データデータベース１３１内のデータ格納位置は例えばデータアドレスによって管理されており、通信データ管理テーブル１２４内の管理テーブルの構成の一例は、図３に示す受信データ名とデータアドレス、およびデータの大きさを示すデータサイズが対応付けられた管理テーブルとなる。

また、ＲＡＭ１３０には、通信データ保存部を構成する通信データデータベース１３１と整合性情報保存部２３０を構成する読込ＩＤ管理テーブル１３２、書込ＩＤ管理テーブル、整合性情報データベース１３４が格納される。

図４は、整合性情報データベース１３４内の整合性判定のための整合性情報のデータ構造図の一例であり、データ書き込みが開始された回数を保持する書込開始回数、通信データデータベース１３１にデータ書き込み中（書き込みを実行し、書き込み実行可能状態を維持している状態）であるか否かを示すフラグであるデータ書込中フラグ、割り当てられた読込ＩＤの個数を保持する読込ＩＤ数、割り当てられた読込ＩＤのうちデータ読み込み中であるＩＤの数を保持する読込中ＩＤ数、データ書き込みが行われた時点での読込ＩＤの数を保持する書込時ＩＤ数で構成される。

書込開始回数は、書込整合開始処理２４２が実行された時にインクリメント（＋１）され、書込整合終了処理２４６が実行された時にデクリメント（−１）される。初期値は０である。

データ書込中フラグは、書込整合処理２４４が実行された時にＴＲＵＥとなり、書込整合終了処理２４６が実行された時にデクリメントされた書込開始回数が０であった場合にＦＡＬＳＥとなる。初期値はＦＡＬＳＥである。

読込中ＩＤ数は、読込整合開始処理２１２が実行された時にインクリメントされ、読込整合終了処理２１５が実行された時にデクリメントされる。初期値は０である。

読込ＩＤ数は、読込整合開始処理２１２が実行された時にインクリメントされ、読込整合終了処理２１５が実行された時にデクリメントされた読込中ＩＤ数が０であった場合に０となる。初期値は０である。ここで読込ＩＤ数は、読み込み処理が途切れることなく連続して行われた読み込み処理の数をカウントすることができる。
また、読込ＩＤは、読込整合開始処理２１２を実行した時に、インクリメント後の読込ＩＤ数が割り当てられる。
読込ＩＤの割り当て方法についての詳細は後述する。

書込時ＩＤ数は、書込整合処理２４４が実行された時に読込ＩＤ数の値がコピーされ、読込整合開始処理２１５が実行された時に読込ＩＤ数が０となった場合に０となる。初期値は０である。

次に動作について説明する。
まず、図２を用いて概要を説明する。まず、通信データデータベース１３１に対しては、データ読込処理部２１０の動作より、データ書込処理部２４０の動作を優先させることとする。その実現のため、データ読込処理部２１０とデータ書込処理部２４０は独立して動作させ、データ読込処理部２１０の動作によるデータ読み込み中にデータ書込処理部２４０の動作による受信データ書き込みが実行された場合には、データ書込処理部２４０の書き込みは書き込み成功とするが、データ読込処理部２１０の読み込みは読み込んだデータに整合性が無いとして読み込み失敗とする。なお、読み込み失敗時には、データ読込処理部２１０をリトライさせることで、読み込んだ受信データに整合性が有るまで繰り返させるとしてもよい。一定回数リトライしても整合性が有る受信データが得られない場合は、エラー処理としてデータ読込処理部２１０の呼び出しもとに読み込み失敗を通知する。なお、以下では、リトライが実施される場合を例に説明する。

読み込み成功か否かの判定は、読込ＩＤにより行う。読込ＩＤは整合性情報保存部２３０内の読込ＩＤ管理テーブル１３２で管理され、読込整合開始処理２１２を実行した時に割り当てられる。一度割り当てられた読込ＩＤは、読込整合開始処理２１２と対となる読込整合終了処理２１５が実行される時に未割当となるが、処理中の読み込み処理がすべて終了するまで、つまり読込ＩＤ数が０となるまでは再度割り当てられることは無い。整合性情報データベース１３４内の整合性情報は、読込整合開始処理２１２、読込整合終了処理２１５、書込整合開始処理２４２、書込整合処理２４４、書込整合終了処理２４６の実行により逐次更新される。読込終了処理２１４の実行時に当該整合性情報と読み込み処理に割り当てられる読込ＩＤとを参照することで、読み込みの整合性判定を行い読み込みの成否を判定する。

データ読込処理部２１０における処理シーケンスについて、図５を用いて説明する。なお、整合性判定方法の詳細は、後述する。
まず、読み込み開始処理２１１にてリトライ回数を０とする（ステップＳ１０１）。このリトライ回数はデータ読み込みに失敗したら１ずつ加算していき、読み込み前に規定回数まで達したか否かの判定に使用することで、読み込みの最大リトライ回数を決定するために使用する。

次に、リトライ回数が予め決められた回数に達しているか否かを確認する（ステップＳ１０２）。具体的には予め最大リトライ回数としてＮ（Ｎは２以上の自然数）回を設定し、リトライ回数と最大リトライ回数Ｎ回とを比較し、リトライ回数の方が小さい場合は、ステップＳ１０３に移行し、最大リトライ回数Ｎ回がリトライ回数と同じである場合は、必要に応じてデータ読込処理部２１０の呼び出しもとに読込失敗を通知するなどの読み込み失敗時のエラー処理を実施し（ステップＳ１１１）、データ読み込み失敗として終了する。

ステップＳ１０３では、読込整合開始処理２１２にて新しい読込ＩＤを開始された読み込み処理に対して割り当て、整合性情報保存部２３０の読込ＩＤ管理テーブル１３２に登録する。割り当てられた読込ＩＤの管理テーブルの例を図６に示す。具体的には、アプリブロック２０１から読み込み要求された１つ以上の対象データの組みに対して読込ＩＤを割り当て、その値には、読込ＩＤ数をインクリメントした後の値が割り当てられる。
このように読込ＩＤは、読み込み処理に対して割り当てられるため、１つの読み込み処理で読み込まれる複数の対象データを１つの組みとして管理し、読み込みの整合性を判断できる。
なお、ここで読込中ＩＤ数もインクリメントされる。

次に読込処理２１３にて通信データ管理テーブル１２４から読み込み対象データの通信データデータベース１３１内での格納位置を読み出し（ステップＳ１０４）、その位置情報をもとに受信データを読み込む（ステップＳ１０５）。

ステップＳ１０６では、読込終了処理２１４にて同じ読込ＩＤの読み込み対象のデータを全て読み込んだか否かを判定する。読み込み対象データがまだある場合にはステップＳ１０４およびステップＳ１０５に戻りさらに対象データを読み込む。読み込み対象の全てのデータを読み込んだら、ステップＳ１０７に移行する。なお、ここで必要なデータとはアプリブロック２０１から読み込み要求された対象データの組みであり、例えば、図６の読込ＩＤ管理テーブル１３２により判定する。

ステップＳ１０７では、読込整合終了処理２１５にてステップＳ１０３において割り当てられた読込ＩＤで整合性情報データベース１３４の整合性情報を参照して整合性を判定する。次に、読込中ＩＤ数をデクリメントして読み込み中の割り当てられた読込ＩＤの数を１減らし、さらに対応する読込ＩＤの情報を削除することで割り当てられた読込ＩＤを未割当とする（ステップＳ１０８）。なお、ここで、デクリメントされた後の読込中ＩＤ数が０となった時、読込ＩＤ数も０とする。そのため、読み込みが整合性無しと判定された場合も読込中の読み込み処理が他にない場合は、読込ＩＤ数は０となる。

判定処理ステップＳ１０９では、ステップＳ１０７で判定された整合性有無により移行する処理を判定する。ステップＳ１０７で整合性無しと判定された場合は、リトライ回数を１増やして（ステップＳ１１０）、ステップＳ１０２の判定へ戻る。ステップＳ１０７で整合性有りと判定された場合は、読み込み成功として終了する。
なお、データ読込処理部２１０における処理シーケンスを図５にて説明したが、これに限定されるものではない。例えば、ステップＳ１０９において整合性が無しと判定された場合、ステップＳ１０２に戻り再度読み込みを実行しているが、リトライに関わる処理を省略し読み込み失敗としてステップＳ１１１に移行する処理シーケンスとしてもよい。

データ書込処理部２４０における処理シーケンスについて、図７を用いて説明する。
まず、書込開始処理２４１にて書き込み処理を開始し、書込整合開始処理２４２にて書込開始回数をインクリメントすることで、受信データ書き込み開始を整合性情報データベース１３４に記録する（ステップＳ２０１）。これにより書き込みの準備ができたことを管理する。

ステップＳ２０２では、書込整合開始処理２４２にて新しい書込ＩＤを開始された読み込み処理に対して割り当て、整合性情報保存部２３０の書込ＩＤ管理テーブル１３３に登録する。割り当てられた書込ＩＤの管理テーブルの例を図８に示す。具体的には、デバイスドライバ２０３から書き込み要求された１つ以上の対象データの組みに対して書込ＩＤを割り当て、その値には、書込開始回数をインクリメントした後の値が割り当てられる。
このように書込ＩＤは、書き込み処理に対して割り当てられるため、１つの書き込み処理で書き込まれる複数の対象データを１つの組みとして管理することができる。

次に、書込処理２４３にて通信データ管理テーブル１２４から書き込み対象データの通信データデータベース１３１内での格納位置を読み出し（ステップＳ２０３）、その位置情報をもとに受信データを書き込む（ステップＳ２０４）。次に、書込整合処理２４４にて整合性情報データベース１３４内の情報を更新する。具体的には、データ書込中フラグをＴＲＵＥにし、読込ＩＤ数を書込時ＩＤ数にコピーする（ステップＳ２０５）。このことにより割り当て済みの読込ＩＤによるデータ読み込みは読込整合終了処理２１５の実行時に全て整合性無しと判定される。

ステップＳ２０６では、書込終了処理２４５にてデバイスドライバ２０３から要求のあった書き込み対象のデータを全て書き込んだか否かを判定する。書き込み対象データがまだある場合にはステップＳ２０３、ステップＳ２０４およびステップＳ２０４に戻りさらに対象データを書き込む。書き込み対象の全てのデータを書き込んだら、ステップＳ２０７へ移行する。なお、ここで必要なデータとはデバイスドライバ２０３から書き込み要求された対象データの組みであり、例えば、図８の書込ＩＤ管理テーブル１３３により判定する。

ステップＳ２０７では、書込整合終了処理２４６にて書込開始回数をデクリメントすることで、整合性情報データベース１３４に対しステップＳ２０１で記録した受信データ書き込み開始の情報を削除する。次に、書き込み成功としてデータ書き込みを終了する。
なお、データ書込処理部２４０の処理シーケンスにおいて、データ書き込みについて整合性情報に更新するタイミングは図７に示したタイミングに限定されない。例えば、データ書き込みを整合性情報へ反映するステップＳ２０５を受信データの書き込みステップＳ２０４の前に実行してもよい。

整合性情報データベース１３４内の更新方法と、読込ＩＤの割り当て方法と、整合性判定方法の具体例を、図９から図１８を用いて説明する。なお、図面において整合性情報について更新された値を下線にて示している。

ここで、整合性有無の判定は、読込整合性終了処理２１５の実行時にデータ書込中フラグ、および対象データが対応付けてられている読込ＩＤと書込時ＩＤ数との比較により行う。具体的には読込整合性終了処理２１５の実行時のデータ書込中フラグがＦＡＬＳＥ、かつ、読込ＩＤが書込時ＩＤ数より大きい場合に整合性有りと判定し、それ以外の場合、整合性無しとする。

これは整合性判定対象のデータの読み込み終了時にデータが書き込み中（書き込みを実行し、書き込み実行可能状態を維持している状態）ではなく書き込みが終了していることと、整合性判定対象データに対応する読込処理が何番目に開始された読み込み処理であるかを示す読込ＩＤと、最後に実行されたデータ書き込み時に何番目の読込処理が開始されたていたかを示す書込時ＩＤ数により、読込ＩＤが書込時ＩＤ数より大きいことで書き込み時に整合性判定対象のデータの読み込みが開始されていないことを確認することを意味している。なお、ここでデータが書き込み中（書き込みを実行し、書き込み実行可能状態を維持している状態）ではないことを確認するのは、この状態においてはいつ書き込みが行われてもよく、整合性情報の更新状況などによって発生する可能性のある整合性判定の誤りを防ぐためである。

図９は、（Ｂ）−（Ｄ）を組みとする読み込みと、（Ｃ）−（Ｈ）を組みとする読み込みと、（Ｅ）−（Ｆ）−（Ｇ）を組みとする書き込みが行われ、書き込みは（Ｄ）と（Ｈ）の間のタイミングで行われた場合の例である。このとき、（Ｂ）−（Ｄ）間では書き込みが行われていないため（Ｄ）では整合性有りと判定され、（Ｃ）−（Ｈ）間では書き込みが行われているため（Ｈ）で整合性無しと判定されることが期待される。

各データの初期値より読み込みあるいは書き込みが行われていない前提条件は（Ａ）のようになっている。ここで１回目の読込整合開始処理２１２が実行されると前記の規則に従い（Ｂ）のように更新され、読込ＩＤにはインクリメント後の読込ＩＤ数の値、１が割り当てられる。次に２回目の読込整合開始処理２１２が実行されると（Ｃ）のように更新され、読込ＩＤには２が割り当てられる。次に（Ｄ）では、読込整合終了処理２１５が実行され、整合性有無の判定が行われる。まず、読込整合終了処理２１５により内容が更新される前の整合性情報（ここでは（Ｃ）時点の内容）からデータ書込中フラグと書込時ＩＤ数を取得する。ここではデータ書込フラグはＦＡＬＳＥであり、割り当てられている読込ＩＤが１、書込時ＩＤ数が０であり、読込ＩＤの値の方が大きくなっているため整合性有りと判定される。判定後、整合性情報の内容は（Ｄ）となる。次に書き込み処理が行われ、前記の規則に従い、（Ｅ）（Ｆ）（Ｇ）のように更新される。次の（Ｈ）では、（Ｄ）と同様に読込整合終了処理２１５が実行され、整合性有無の判定が行われ、（Ｇ）でのデータ書込中フラグと書込時ＩＤ数が参照される。ここでは、データ書込中フラグがＦＡＬＳＥ、読込ＩＤが２、書込時ＩＤ数が２となり、読込ＩＤと書込時ＩＤ数が等しく整合性有りの条件を満たしていないため、整合性無しと判定される。判定後、整合性情報の内容は（Ｈ）となる。

前記のように（Ｄ）、（Ｈ）の読込終了処理２１４実行時の判定の結果、（Ｂ）−（Ｄ）を組みとする読み込みは整合性有り、（Ｃ）−（Ｈ）を組みとする読み込みは整合性無しと判定され、期待通りの判定結果となる。

読み込み開始から終了の期間が、書き込み開始を含む場合の例を、図１０を用いて説明する。この例では、（Ｂ）−（Ｄ）間で書き込みが開始されているものの、実際に書き込まれるのは（Ｄ）の後であるため、整合性有りと判定されることが期待される。

前記規則に従い整合性情報データベース１３２内の整合性情報を更新すると、（Ｄ）における読み込み終了時の整合性判定時に参照する（Ｃ）の整合性情報は、データ書込中フラグがＦＡＬＳＥ、割り当てられている読込ＩＤが１、書込時ＩＤ数が０となり、読込ＩＤの値の方が大きくなっているため、読み込みは整合性有りと判定される。この結果は期待通りの判定結果である。

読み込み開始から終了の期間が、書き込みを含む場合の例を、図１１を用いて説明する。この例では、読み込み開始から終了の期間で書き込みが実行されているため、整合性無しと判定されることが期待される。

前記規則に従い整合性情報データベース１３２内の整合性情報を更新すると、（Ｅ）における整合性判定時に参照する（Ｄ）の整合性情報は、データ書込中フラグがＴＲＵＥ、割り当てられていた読込ＩＤが１、書込時ＩＤ数が１となり、データ書込中フラグがＦＡＬＳＥではなく、さらに読込ＩＤと書込時ＩＤ数が等しく整合性有りの条件を満たしていないため、整合性無しと判定される。この結果は期待通りの判定結果である。

読み込み開始から終了の期間が、書き込み終了を含む場合の例を、図１２を用いて説明する。この例では、読み込み開始時点で書き込み開始されているものの、読み込み終了までの間に書き込みが行われずに書き込み終了されているため、整合性有りと判定されることが期待される。

前記規則に従い整合性情報データベース１３２内の整合性情報を更新すると、（Ｆ）における整合性判定時に参照する（Ｅ）の整合性情報は、データ書込中フラグがＦＡＬＳＥ、割り当てられている読込ＩＤが１、書込時ＩＤ数が０となり、読込ＩＤの値の方が大きくなっているため、整合性有りと判定される。この結果は期待通りの判定結果である。

読み込み開始から終了の期間が、書き込み開始と書き込みのみを含む場合の例を、図１３を用いて説明する。この例では、（Ｂ）−（Ｅ）間でデータ書き込みがされているため、整合性無しと判定されることが期待される。

前記規則に従い整合性情報データベース１３４内の整合性情報を更新すると、（Ｅ）における整合性判定時に参照する（Ｄ）の整合性情報は、データ書込中フラグがＴＲＵＥ、割り当てられている読込ＩＤが１、書込時ＩＤ数が１となり、データ書込中フラグがＦＡＬＳＥではなく、さらに読込ＩＤと書込時ＩＤ数が等しく整合性有りの条件を満たしていないため、整合性無しと判定される。の結果は期待通りの判定結果である。

読み込み開始から終了の期間が、書き込みと書き込み終了のみを含む場合の例を、図１４を用いて説明する。この例では、（Ｃ）−（Ｄ）間でデータ書き込みがされているため、整合性無しと判定されることが期待される。

前記規則に従って整合性情報データベース１３４内の整合性情報を更新すると、（Ｆ）における整合性判定時に参照する（Ｅ）の整合性情報は、データ書込中フラグがＦＡＬＳＥ、割り当てられている読込ＩＤが１、書込時ＩＤ数が１となり、書込ＩＤと書込時ＩＤ数が等しく整合性有りの条件を満たしていないため、整合性無しと判定される。この結果は期待通りの判定結果である。

書き込み開始から書き込みの期間が、読み込み開始と読み込み終了を含む場合の例を、図１５を用いて説明する。この例では、読み込み開始時点で書き込み開始されているものの、書き込み開始後の初回の書き込み（Ｅ）より前に読み込み終了としているため、整合性有りと判定されることが期待される。

前記規則に従って整合性情報データベース１３４内の整合性情報を更新すると、（Ｄ）における整合性判定時に参照する（Ｃ）の整合性情報は、データ書込中フラグがＦＡＬＳＥ、割り当てられている読込ＩＤが１、書込時ＩＤ数が０となり、読込ＩＤの値が書込時ＩＤ数よりも大きくなっているため、整合性有りと判定される。この結果は期待通りの判定結果である。

書き込みから書き込み終了の期間が、読み込み開始と読み込み終了を含む場合の例を、図１６を用いて説明する。この例では、（Ｂ）−（Ｆ）間の最後の書き込み（Ｃ）より後に読み込みを行っているため整合性有りと判定すべきように思えるが、整合性判定を行う（Ｅ）時点では（Ｃ）が最後の書き込みであるかは不明であるため、整合性無しと判定されることが期待される。

前記規則に従って整合性情報データベース１３４内の整合性情報を更新すると、（Ｅ）における整合性判定時に参照する（Ｄ）の整合性情報は、データ書込中フラグがＴＲＵＥ、割り当てられている読込ＩＤが１、書込時ＩＤ数が０となり、データ書込中フラグがＦＡＬＳＥではなく整合性有りの条件を満たしていないため、整合性無しと判定される。この結果は期待通りの判定結果である。

（Ｂ）−（Ｇ）を組みとする読み込みと、（Ｅ）−（Ｈ）を組みとする読み込みと、（Ｃ）−（Ｄ）−（Ｆ）を組みとする書き込みが行われ、書き込みは（Ｂ）と（Ｅ）の間のタイミングで行われた場合の例を、図１７を用いて説明する。この例では、（Ｂ）−（Ｇ）間での読み込みについては（Ｂ）−（Ｇ）間でデータの書き込みがされているため、整合性無しと判定されることが、（Ｅ）−（Ｈ）間での読み込みについては（Ｅ）−（Ｈ）間では読み込み終了までの間に書き込みが行われずに書き込み終了されているため整合性有りと判定されることが期待される。

前記規則に従って整合性情報データベース１３４内の整合性情報を更新すると、（Ｇ）における整合性判定時に参照する（Ｆ）の整合性情報は、データ書込中フラグがＦＡＬＳＥ、割り当てられている読込ＩＤが１、書込時ＩＤ数が１となり、読込ＩＤが書込時ＩＤと等しく整合性有りの条件を満たしていないため、整合性無しと判定される。さらに（Ｈ）における整合性判定時に参照する（Ｇ）の整合性情報は、データ書込中フラグがＦＡＬＳＥ、割り当てられている読込ＩＤが２、書込時ＩＤ数が１となり、読込ＩＤの値の方が大きくなっているため、整合性有りと判定される。

前記のように（Ｄ）、（Ｈ）の読込終了処理２１４実行時の判定の結果、（Ｂ）−（Ｇ）を組みとする読み込みは整合性無し、（Ｅ）−（Ｈ）を組みとする読み込みは整合性有りと判定され、期待通りの判定結果となる。

読み込み開始から終了の期間に、書き込み開始と書き込み終了を含みさらに書き込みを２回含む場合の例を、図１８を用いて説明する。この例では、（Ｂ）−（Ｇ）間で書き込みがされているため、整合性無しと判定されることが期待される。

前記規則に従って整合性情報データベース１３４内の整合性情報を更新すると、（Ｄ）および（Ｅ）において２回書き込みが行われているため、それぞれにおいてデータ書込中フラグおよび書込時ＩＤ数の更新が行われる。（Ｇ）における整合性判定時に参照する（Ｆ）の整合性情報は、データ書込中フラグがＦＡＬＳＥ、割り当てられている読込ＩＤが１、書込時ＩＤ数が１となり、読込ＩＤが書込時ＩＤ数と等しく整合性有りの条件を満たしていないため、整合性無しと判定される。

以上のように、何れの例においてもアプリブロック２０１から受信データを取得する場合に、その整合性有無を判定することが可能となる。整合性無しの場合には読み込みをリトライし、整合性が有るデータを読み込みことができるまで繰り返すことで、読み込んだデータに整合性があることが保証される。また、アプリブロック２０１からの受信データの読み込み処理よりも、デバイスドライバ２０３からの受信データ書き込みを優先させているため、デバイスドライバ２０３の処理がアプリブロック２０１の処理に待たされることが無くなり、デバイスドライバ２０３の処理が通信デバイスや通信プロトコルが規定している処理のタイミングを保証しやすくなる。
上述の説明では、通信デバイスによって受信されたデータをアプリブロックが読み込む場合について説明したが、この発明はこれに限られるものではない。例えば、種々のセンサによって取得されたデータがメモリに記録されて、アプリブロックが当該データを利用する場合などにも適用することができる。

また、本発明の実施例において整合性有無の判定のために追加した整合性情報データベース１３４は小規模であり、特許文献２に示す技術のように通信データを二重化することもなくメモリ使用効率を悪化させることがない。そのため通信データの二重化を許容できないような小規模なメモリを持つ製品あるいはシステムに適用することも容易である。

以上のように、実施の形態１の組込みシステム１００によれば、１つ以上のデータを対象とした読み込み処理の整合性有無を判定するように構成したので、読み込んだ複数のデータに整合性が有ることを保証でき、誤作動のない制御を可能とするという効果を得ることができる。

実施の形態２．
実施の形態１では、読み込み開始から終了の間に書き込みが実行された場合は全て読み込み失敗と判定し、リトライが必要となる実施例について説明した。実施の形態２では、読み込んだデータの整合性に関係のあるデータが書き込まれた場合にのみ読み込み失敗と判定することにより、より適切な整合性有無の判定が可能な実施例について説明する。

具体的には、通信データデータベース１３１内のデータを、整合性に関係のあるいくつかのグループに分類しておき、アプリブロック２０１が要求する読み込み対象のデータと、デバイスドライバ２０３が要求する書き込み対象のデータが異なるグループに属する場合は、読み込みあるいは書き込みのタイミングが被ったとしても読み込み失敗と判定しないことにより実現する。その結果、読み込みリトライが発生する頻度を低減させることができる。

図１９は本発明の実施の形態２に係る組込みシステム３００のシステム構成の一例を示す構成図であり、図２０は本発明の実施の形態２に係る組込みシステムのソフトウェア４００のソフトウェア構成の一例を示す構成図である。

図１９において、組込みシステム３００の実施の形態１の組込みシステム１００との相違点はＲＯＭ１２０がグループ分類管理テーブル１２５を格納していることであり、それ以外の構成は同じ構成となっている。

また、図２０において、組込みシステムのソフトウェア４００の実施の形態１の組込みシステムのソフトウェア２００との相違点は整合性情報保存部２３０がグループ分類管理テーブル１２５を備えていることであり、それ以外の構成は同じ構成となっている。

グループ分類管理テーブル１２５は、通信データデータベース１３１内のデータを整合性に関係のあるデータに分類したグループの管理テーブルであり、そのデータ構造の一例は図２１のようになる。組込みシステム３００は、データ読込処理部２１０の読込開始処理２１１、データ書込処理部２４０の書込開始処理２４１の実行時にグループ分類管理テーブル１２５を参照することにより、対象とするグループを指定し、以降の処理で整合性情報データベース１３４を参照あるいは更新する時には指定したグループを使用することとする。これにより、読み込みあるいは書き込みのタイミングが被ったとしても、対象とするグループが異なるのであれば、整合性判定に使用する整合性情報のグループが異なるため、読み込み失敗と判定されることはない。

また、図２２は、実施の形態２における整合性情報データベース１３４内の整合性情報のデータ構造の一例であり、それぞれのグループの整合性情報の構成は図４に示す実施の形態１と同様である。なお、図２１、図２２は例として通信データ全体を４グループに分けた場合のものであり、分けるグループ数は自由に選択できるものとする。また、グループの分け方はルームエアコン、テレビなどの対象となる製品あるいはシステムごとに分けてもよいし、空調設定変更処理などの対象となる処理ごとに分けてもよい。
図１９および図２０におけるグループ管理テーブル１２５以外の構成は、実施の形態１の図１および図２の構成と同じであるため詳細な説明は省略する。

実施の形態２のデータ読込処理部２１０における処理シーケンスについて、図２３を用いて説明する。
通信データをグループ分けしていない図５との相違点は、図２２で示した整合性情報から、読み込み対象とするグループを選択する処理（ステップＳ３０１）が増えたことであり、それ以外の処理（ステップＳ３０２からステップＳ３１２）はそれぞれ図５のステップＳ１０１からステップＳ１１１に対応した処理である。但し、整合性情報に関わる処理（ステップＳ３０４、ステップＳ３０８、ステップＳ３０９）においてはステップＳ３０１で選択されたグループの整合性情報を使用することとする。

まず読込開始処理２１１にて読み込み対象とするグループの整合性情報を選択する（ステップＳ３０１）。具体的には、図２１を参照することでアプリブロック２０１から読み込み要求のあったデータの対象グループを指定し、図２２を参照することで対象グループの整合性情報を選択する。ここで選択された整合性情報中の対象グループをこれ以降の処理では参照あるいは更新する。次に、リトライ回数を０とする処理（ステップＳ３０２）、リトライ回数が予め決められた回数に達しているか否かを確認する処理（ステップＳ３０３）、およびステップＳ３０３においてリトライ回数が予め設定された最大リトライ回数Ｎ回に達している場合は読み込み失敗時のエラー処理（ステップＳ３１２）に移行する。これらの処理は図５のステップＳ１０１、Ｓ１０２、Ｓ１１１に相当する処理のため詳細な説明は省略する。

ステップＳ３０３にてリトライ回数が最大リトライ回数Ｎ回に達していない場合は、ステップＳ３０４に移行する。ステップＳ３０４では、読込整合開始処理２１２にて新しい読込ＩＤを、開始された読み込み処理に対して割り当て、整合性情報保存部２３０の読込ＩＤ管理テーブル１３２に登録する。なお、ここで読込中ＩＤ数もインクリメントする。この処理は図５のステップＳ１０３に相当する処理のため詳細な説明は省略する。
ここで読込ＩＤは同じグループに属する読み込み対象データに対して１つのＩＤを割り当てる。もし、複数のグループのデータを同時に読み込む必要がある場合は、グループごとに読込ＩＤが割り当てられ、それぞれ別に管理する。

次に読込処理２１３にて通信データ管理テーブル１２４から読み込み対象データの通信データデータベース１３１内での格納位置を読み出し（ステップＳ３０５）、その位置情報をもとに受信データを読み込む（ステップＳ３０６）。ここで、データ読み込みでは同じグループに属する読み込み対象データのみを読み込むようにする。もし、複数のグループのデータを読み込む必要がある場合には、本処理シーケンスをそれぞれのグループに対して実行する。

ステップＳ３０７では、読込終了処理２１４にて同じグループで同じ読込ＩＤの読み込み対象のデータを全て読み込んだか否かを判定する。この処理は図５のステップＳ１０６に相当する処理のため詳細な説明は省略する。

ステップＳ３０８の整合性有無の判定処理、ステップＳ３０９の読込ＩＤを未割当とする処理はそれぞれ図５のステップＳ１０７、ステップＳ１０８に相当する処理である。そのため処理の詳細な説明は省略する。但し、ここで参照する整合性情報はＳ３０１にて選択したグループの整合性情報である。

判定処理ステップＳ３１０では、ステップＳ３０８で判定された整合性有無により移行する処理を判定する。ステップＳ３１０で整合性無しと判定された場合は、リトライ回数を１増やして（Ｓ３１１）、ステップＳ３０３の判定へ戻る。ステップＳ３１０で整合性有りと判定された場合は、読み込み成功として終了する。
なお、データ読込処理部２１０における処理シーケンスを図２３にて説明したが、これに限定されるものではない。例えば、ステップＳ３１０において整合性が無しと判定された場合、ステップＳ３０３に戻り再度読み込みを実行しているが、リトライにかかわる処理を省略し読み込み失敗としてステップＳ３１２に移行する処理シーケンスとしてもよい。

実施の形態２のデータ書込処理部２４０における処理シーケンスについて、図２４を用いて説明する。
通信データをグループ分けしていない図７との相違点は、図２２で示した整合性情報から、書き込み対象とするグループを選択する処理（ステップＳ４０１）が増えたことであり、それ以外の処理（ステップＳ４０２からステップＳ４０７）はそれぞれ図７のステップＳ２０１からステップＳ２０６に対応した処理である。但し、整合性情報に関わる処理（ステップＳ４０２、ステップＳ４０５、ステップＳ４０７）においてはステップＳ４０１で選択された行の情報を使用することとする。

まず書込開始処理２４１にて書き込み対象とするグループの整合性情報を選択する（ステップＳ４０１）。具体的には、図２１を参照することでデバイスドライバ２０３から書き込み要求のあったデータの対象グループを指定し、図２２を参照することで対象グループの整合性情報を選択する。ここで選択された整合性情報中の対象グループをこれ以降の処理では参照あるいは更新する。

次に、書込整合開始処理２４２にて受信データ書き込み開始を整合性情報データベース１３４の整合性情報に記録する処理（ステップＳ４０２）、新しい書込ＩＤを、開始された書き込み処理に対して割り当て、整合性情報保存部２３０の書込ＩＤ管理テーブル１３３に登録する処理（ステップＳ４０３）、書込処理２４３にて通信データ管理テーブル１２４から書き込み対象データの通信データデータベース１３１内での格納位置を読み出す処理（ステップＳ４０４）、その位置をもとに受信データを書き込む処理(ステップＳ４０５)に移行する。これらの処理は図７のステップＳ２０１、Ｓ２０２、Ｓ２０３、Ｓ２０４に相当する処理であり、詳細な説明は省略する。但し、ここで、書込ＩＤは同じグループに属する書き込み対象データに対して１つのＩＤを割り当てる。もし、複数のグループのデータを同時に読み込む必要がある場合は、グループごとに書込ＩＤが割り当てられ、それぞれ別に管理し、本処理シーケンスをそれぞれのグループに対して実行する。

次に、書込整合処理２４４にて整合性情報データベース１３４内の整合性情報を更新する。（ステップＳ４０６）。この処理は図７のステップＳ２０５に相当する処理であり、詳細な説明は省略する。なお、ここで更新する整合性情報はステップＳ４０１にて選択したグループの整合性情報である。

ステップＳ４０７では、書込終了処理２４５にてデバイスドライバ２０３から要求のあった書き込み対象のデータを全て書き込んだか否かを判定し、ステップＳ４０８では、整合性情報データベース１３４に対しステップＳ４０２で記録した受信データ書き込み開始の情報を削除して、書き込み成功としてデータ書き込みを終了する。これらの処理は図７のステップＳ２０６、ステップＳ２０７に相当する処理のため詳細な説明は省略する。
なお、データ書込処理部２４０の処理シーケンスにおいて、データ書き込みについて整合性情報に更新するタイミングは図２４に示したタイミングに限定されない。例えば、データ書き込みを整合性情報へ反映するステップＳ４０５を受信データの書き込みステップＳ４０４の前に実行してもよい。

以上のように、実施の形態２の組込みシステム１００によれば、通信データデータベース１３１内のデータを整合性の判定に関係のあるグループに分けそれぞれのグループにて１つ以上のデータを対象とした読み込み処理の整合性を判定するように構成したので、アプリブロック２０１からの読み込みとデバイスドライバ２０３からの書き込みのタイミングが被った場合においても、アプリブロック２０１から要求のあった読み込み対象データと、デバイスドライバ２０３から要求のあった書き込み対象の受信データが同じグループに属していない場合は整合性有りと判定するように作用することができ、読込処理を行った複数のデータに整合性が有ることをより適切に判定することができ、誤作動のない制御を可能とするという効果を得ることができる。さらにリトライを繰り返すといった無駄な処理を行う場合を低減させ処理効率を向上するという効果も得ることができる。

１００，３００ 組込みシステム、１１０ ＣＰＵ、１２０ ＲＯＭ 、１２１ アプリブロックコード、１２２ 通信制御部コード、１２３ デバイスドライバコード、１２４ 通信データ管理テーブル、１２５ グループ分類管理テーブル、１３０ ＲＡＭ、１３１ 通信データデータベース、１３２ 読込ＩＤ管理テーブル、１３３ 書込ＩＤ管理テーブル、１３４ 整合性情報データベース、１４０ 通信デバイス、２００，４００ ソフトウェア、２０１ アプリブロック、２０２ 通信制御部、２０３ デバイスドライバ、２１０ データ読込処理部、２１１ 読込開始処理、２１２ 読込整合開始処理、２１３ 読込処理、２１４ 読込終了処理、２１５ 読込整合終了処理、２２０ 通信データ保存部、２３０ 整合性情報保存部、２４０ データ書込処理部、２４１ 書込開始処理、２４２ 書込整合開始処理、２４３ 書込処理、２４４ 書込整合処理、２４５ 書込終了処理、２４６ 書込整合終了処理。

Claims (8)

1. アプリケーション部が実行するデータの読み込み処理を開始する読込開始手段と、
   前記読込開始手段にて開始されたそれぞれの読み込み処理に読込ＩＤを割り当て、割り当てられた前記読込ＩＤの数を示す読込ＩＤ数を更新する読込整合開始手段と、
   前記データを読み込む読込手段と、
   前記読込手段による前記データの読み込みを終了する読込終了手段と、
   前記読込ＩＤと、書き込み処理中であるか否かを示すデータ書込中フラグと、データ書き込み処理時の前記読込ＩＤ数を示す書込時ＩＤ数と、を取得し、前記データ書込中フラグ、前記読込ＩＤ、前記書込時ＩＤ数とに基づいて、読み込まれた前記データの整合性を判定する読込整合終了手段と、
   を備えることを特徴とする組込みシステム。
2. 前記読込ＩＤは数値であり、
   前記読込整合開始手段は、数値を１増加させた前記読込ＩＤを割り当てることを特徴とする請求項１に記載の組込みシステム。
3. 前記読込整合終了手段が、読み込まれたデータに整合性が無いと判定した場合は、データ読み込み処理を再度行うことを特徴とする請求項１あるいは２に記載の組込みシステム。
4. 前記読込ＩＤと前記読込ＩＤ数と前記データ書込中フラグと前記書込時ＩＤ数は、対象とするデータごとに複数のグループに分けられており、
   前記読込整合処理手段は、前記複数のグループごとに整合性を判定することを特徴とする請求項１から３のいずれか１項に記載の組込みシステム。
5. 共有メモリを備えた組込みシステムの共有メモリからのデータ読み込み処理を制御する組込みシステム制御方法において、
   データ読み込み処理開始時に読み込み処理を識別するための読込ＩＤを割り当てる読込ＩＤ割り当てステップと、
   前記共有メモリからデータを読み込むデータ読み込みステップと、
   前記データ読み込みステップの終了時に前記共有メモリから割り当てられた前記読込ＩＤの数である読込ＩＤ数と、前記共有メモリへデータ書き込み処理中であるか否かのフラグであるデータ書込中フラグと、前記共有メモリへのデータ書き込み処理時の前記読込ＩＤ数である書込時ＩＤ数とを含む整合性情報を取得する整合性情報取得ステップと、
   前記整合性情報取得ステップにて取得した前記データ書込中フラグが書き込み中ではなく、かつ、前記読込ＩＤが前記書込時ＩＤ数よりも大きい場合に前記データ読み込みステップにて読み込まれたデータに整合性が有ると判定する整合性判定ステップと、
   を有することを特徴とする組込みシステム制御方法。
6. 共有メモリを備えた組込みシステムにおいて前記共有メモリから読み込まれたデータに整合性があるか否かを判定するデータ整合性判定方法において、
   前記共有メモリからのデータ読み込み処理開始時に読込開始処理を識別するために割り当てられる読込ＩＤと、
   割り当てられた読込ＩＤの数を示す読込ＩＤ数と、
   前記共有メモリへのデータ書き込み中である否かを示すデータ書込中フラグと、
   データ書き込み処理時の前記読込ＩＤ数を示す書込時ＩＤ数と、
   に基づいて前記読み込まれたデータに整合性があるか否かを判定することを特徴とするデータ整合性判定方法。
7. 前記共有メモリへのデータ読み込み処理終了時に、前記データ書込中フラグが書き込み中ではなく、かつ、前記読込ＩＤが書込時ＩＤ数よりも大きい場合に整合性有りと判定する請求項６に記載のデータ整合性判定方法。
8. 共有メモリを備えた組込みシステムにおいて前記共有メモリから読み込まれたデータに整合性があるか否かを判定するデータ整合性判定方法において、
   前記共有メモリからのデータ読み込み処理終了時に、前記共有メモリにデータを書き込み中であるか否かと、当該読み込み処理が何番目に開始された読み込み処理であるかと、前記共有メモリへのデータ書き込み処理時に実行されていた読み込み処理は何番目に開始された読み込み処理まで含んでいるかと、に基づいて前記読み込まれたデータに整合性があるか否かを判定することを特徴とするデータ整合性判定方法。

Images