(57)【要約】      （修正有）【課題】エレベータの緊急状態に行われる、緊急送信と非緊急送信に対して、異なるモジュール構成を適用する際に、処理のためのリソースが小さくても、遅延の少ないデータ処理を可能とする。【解決手段】エレベータからコールセンタへデータを送信する際に、データを第１のモジュールおよび第２のモジュールの少なくとも一つで処理する通信方法である。非緊急状態であったときに開始されたセッションでは、データを第１のモジュールおよび第２のモジュールの両方で処理する非緊急設定を適用する。緊急状態であったときに開始されたセッションでは、データを第１のモジュールを用いずに第２のモジュールで処理する緊急設定を適用する。そして、緊急設定が適用されたセッションにおいては、途中で緊急状態が非緊急状態に遷移した場合でも、当該セッションが終了するまでは緊急設定の適用を継続する。【選択図】図２
2018042173.tif 000002
【特許請求の範囲】
【請求項１】
送信機から受信機へ、データを非緊急データ及び緊急データに区別して送信する通信システムであって、
前記送信機は、
入力部、出力部、記憶装置、セッション管理部、制御ユニット機能ブロック、および、前記データを処理するモジュール、を備え、
前記記憶装置は、
前記データを送信するセッションを特定するセッションパラメータと、当該セッションの生成タイミングを格納するセッション管理テーブルと、
緊急状態と非緊急状態の転換タイミングを格納する緊急フラグテーブルと、
前記非緊急データ及び前記緊急データのそれぞれに対して前記モジュールの適用の態様を定義するモジュールフラグ適用テーブルと、を備え、
前記セッション管理部は、前記セッション管理テーブルの書き込みおよび読み出しを行い、
前記制御ユニット機能ブロックは、前記入力部からデータが入力された場合、当該データに関連するセッションの情報を前記セッション管理部から得るとともに、前記緊急フラグテーブルを読み出し、前記セッションの生成タイミングと前記転換タイミングに基づいて、前記データを非緊急データあるいは緊急データに区別し、前記区別と前記モジュールフラグ適用テーブルの内容に基づいて、前記モジュールをデータに適用し、前記出力部から前記受信機へ送信する、
通信システム。
【請求項２】
前記制御ユニット機能ブロックは、前記データを緊急データに区別した場合には、当該データが緊急データであることを示すフラグを当該データに付加し、前記出力部から前記受信機へ送信する、
請求項１記載の通信システム。
【請求項３】
前記受信機は、
受信側入力部、受信側出力部、受信側記憶装置、コールセンタ通信機能ブロック、および、前記データを処理する受信側モジュール、を備え、
前記受信側記憶装置は、
前記非緊急データ及び前記緊急データのそれぞれに対して前記モジュールの適用の態様を定義する受信側モジュールフラグ適用テーブル、を備え、
前記コールセンタ通信機能ブロックは、前記受信側入力部に前記送信機からのデータが入力された場合、前記フラグを検出し、当該検出の結果に基づいて、前記データが非緊急データであるか緊急データであるかを判別し、前記判別の結果と前記受信側モジュールフラグ適用テーブルの内容に基づいて、前記受信側モジュールをデータに適用する、
請求項２記載の通信システム。
【請求項４】
前記モジュールおよび前記受信側モジュールはそれぞれ複数あり、１つの前記モジュールと１つの前記受信側モジュールが対をなしており、
前記モジュールフラグ適用テーブルおよび前記受信側モジュールフラグ適用テーブルは、
前記非緊急データ及び前記緊急データのそれぞれに対して前記モジュールで処理を行うか否か、および、当該処理の順序を定義する、
請求項３記載の通信システム。
【請求項５】
前記緊急フラグテーブルは、
緊急状態から非緊急状態への転換タイミングと、非緊急状態から緊急状態への転換タイミングを格納し、前記転換タイミングは時間的に昇順に配列されている、
請求項４記載の通信システム。
【請求項６】
前記送信機は、エレベータに付属する制御ユニットからコールセンターに前記非緊急データ及び前記緊急データを送信するものであり、
前記受信機は、前記コールセンターで前記非緊急データ及び前記緊急データを受信するものであり、
前記非緊急状態から前記緊急状態への転換タイミングは、前記エレベータに付属する緊急コールボタンから発信される信号に基づいて設定される、
請求項５記載の通信システム。
【請求項７】
前記緊急状態から前記非緊急状態への転換タイミングは、前記コールセンターから発信される信号に基づいて設定される、
請求項６記載の通信システム。
【請求項８】
前記モジュールはデータの圧縮または伸張を行う変換モジュールを含み、
前記モジュールフラグ適用テーブルおよび前記受信側モジュールフラグ適用テーブルは、前記緊急データに対して前記変換モジュールを適用しないように定義する、
請求項７記載の通信システム。
【請求項９】
前記緊急データは、音声データを含む、
請求項８記載の通信システム。
【請求項１０】
前記フラグはＴＣＰオプションフラグである、
請求項２記載の通信システム。
【請求項１１】
データを非緊急データ及び緊急データに区別して送信する通信装置であって、
入力部、出力部、記憶装置、セッション管理部、制御ユニット機能ブロック、および、前記データを処理するモジュール、を備え、
前記記憶装置は、
前記データを送信するセッションを特定するセッションパラメータと、当該セッションの生成タイミングを格納するセッション管理テーブルと、
緊急状態と非緊急状態の転換タイミングを格納する緊急フラグテーブルと、
前記非緊急データ及び前記緊急データのそれぞれに対して前記モジュールの適用の態様を定義するモジュールフラグ適用テーブルと、を備え、
前記セッション管理部は、前記セッション管理テーブルの書き込みおよび読み出しを行い、
前記制御ユニット機能ブロックは、前記入力部からデータが入力された場合、当該データに関連するセッションの情報を前記セッション管理部から得るとともに、前記緊急フラグテーブルを読み出し、前記セッションの生成タイミングと前記転換タイミングに基づいて、前記データを非緊急データあるいは緊急データに区別し、前記区別と前記モジュールフラグ適用テーブルの内容に基づいて、前記モジュールをデータに適用し、前記出力部から送信する、
通信装置。
【請求項１２】
前記制御ユニット機能ブロックは、前記データを緊急データに区別した場合には、当該データが緊急データであることを示すフラグを当該データに付加する、
請求項１１記載の通信装置。
【請求項１３】
エレベータからコールセンタへデータを送信する際に、前記データを第１のモジュールおよび第２のモジュールの少なくとも一つで処理する通信方法であって、
緊急状態および非緊急状態の２つの状態を設定可能であり、
前記非緊急状態であったときに開始されたセッションでは、前記データを前記第１のモジュールおよび前記第２のモジュールの両方で処理する非緊急設定を適用し、
前記緊急状態であったときに開始されたセッションでは、前記データを前記第１のモジュールを用いずに前記第２のモジュールで処理する緊急設定を適用し、
前記緊急設定が適用されたセッションにおいては、途中で前記緊急状態が前記非緊急状態に遷移した場合でも、当該セッションが終了するまでは前記緊急設定の適用を継続する、通信方法。
【請求項１４】
前記第１のモジュールは、前記データの圧縮を行うモジュールであり、
前記緊急状態であったときに開始されたセッションでは、前記データとして音声データを送信する、
請求項１３記載の通信方法。
【請求項１５】
前記緊急状態は、前記エレベータの緊急コールボタンの操作により開始され、
前記非緊急状態は、前記コールセンタから送信される解除信号により前記緊急状態を解除することにより開始される、
請求項１３記載の通信方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、状況に応じてデータの通信方式を切り替える技術に関する。例えば、エレベータ制御ユニットとコールセンターの間のデータの送信において、エレベータの緊急状態に関するデータ送信に関する。
【背景技術】
【０００２】
遠距離にある複数のエレベータの保守のために、関連するデータがエレベータ側で周期的に収集され、分析及び保守のためにコールセンター等の管理部門に送信される。データとしては、例えば各種センサの検出データ、装置が自発的に生成するデータ、エレベータ利用者が入力する音声その他のデータがある。データは、それぞれのエレベータ内の小型プロセッサ、即ち、制御ユニットにより収集され、ＷＡＮ（ｗｉｄｅ−ａｒｅａ  ｎｅｔｗｏｒｋ）を通じてコールセンターに送信される。
【０００３】
ネットワークには、ＬＴＥ（Ｌｏｎｇ−Ｔｅｒｍ−Ｅｖｏｌｕｔｉｏｎ）のような無線技術が多くの場合に使用され、このようなネットワークリンクは、多くの場合、帯域幅制限され、利用可能な帯域幅は、様々な外部要因に依存し、時間によって変化し得る。
【０００４】
緊急の場合、エレベータの内部の緊急コールボタンは、乗客がコールセンターに緊急コールをすることを可能にする。このコールは通常は双方向（ｔｗｏ−ｗａｙ）の音声コールである。通信リンクの現在利用可能な帯域幅が音声コールのために十分であるか否かを評価するために、帯域幅評価が周期的にまたは緊急コールをする直前に行われる。
【０００５】
運営費用を節減するために、保守データ送信に用いられるのと同一の通信リンクを通じたＶｏＩＰ（Ｖｏｉｃｅ−ｏｖｅｒ−ＩＰ）を用いて、緊急コールが行われる。さらなる運営費用の節減のためには、ネットワークを通じて送信されるデータ量の減少を必要とし、これはＷＡＮを通じた送信前に、データの圧縮を適用することによって実現される。
【０００６】
コールセンターでは、圧縮されたデータを使用する前に解凍しなければならない。圧縮及び解凍は、一つの例であって、運営費用の節減を支援する他の方法、例えば、データ減少のための他の方法が存在し、このような方法は、一般的に“データ変換”と称される。このような変換、例えば圧縮及び解凍は、データに対して行われる所定の計算が必要であり、これにより送信に所定の遅延をもたらす。しかし、緊急コールは、音声の品質に対する要件が非常に高く、送信に対する遅延をできるだけ小さくする必要がある。
【０００７】
通常の送信（非緊急送信）及び緊急送信の要件が衝突する問題に対する解決法のうち一つは、緊急送信に対する専用ＷＡＮの連結を用いることである。他の解決法は、関連のない非緊急送信を禁止することである。
【０００８】
後者の解決法は、特許文献１に記述されている通り、異なる送信の間にネットワーク連結が共有される場合、緊急送信を優先的に処理して、緊急送信が用いることができる使用可能リソースを改善することである。これは、緊急送信と非緊急送信の間の区別を必要とし、緊急送信と非緊急送信を区別するために、例えば、ＴＣＰ／ＩＰ受信先３タプル（ＴＣＰ／ＩＰ  ｄｅｓｔｉｎａｔｉｏｎ  ３−ｔｕｐｌｅ）、即ち、プロトコル、受信先ＩＰアドレス及び受信先ポート番号を示す関連セッション情報が考慮される。また、送信データのコンテンツが分析される。
【先行技術文献】
【特許文献】
【０００９】
【特許文献１】米国特許公開公報  ＵＳ２００６／０１９４，５６６Ａ１
【発明の概要】
【発明が解決しようとする課題】
【００１０】
運営費用の増大を考慮すると、緊急送信用の専用ＷＡＮを用いることは現実的でない。そこで、共有された回線上で緊急送信が用いることができる使用可能リソースを改善するために、緊急送信の間、関連のない非緊急送信を禁止するか、または緊急送信を優先的に処理することが考えられる。
【００１１】
非緊急送信の禁止及び緊急送信の優先処理は、非緊急送信と緊急送信の間の区別を必要とする。これを決定するための方法のうち一つは、例えばＴＣＰ／ＩＰ受信先３タプル、即ち、プロトコル、受信先ＩＰアドレス及び受信先ポート番号を示すセッション情報を検討することである。このアプローチの問題は、例えば、類似したＴＣＰ／ＩＰ受信先３タプルが用いられると、セッション情報にのみ基づいては緊急送信と非緊急送信の間の区別ができない場合があることである。従って、多くの場合、セッション情報評価のほかに、変換データのコンテンツが分析されなければならない。しかし、このようなコンテンツの分析は、通常的にエレベータの制御ユニットに使用された小型プロセッサの能力では困難である。
【００１２】
また、最終的な結果を得る前に、多くの場合、所定量のデータが先に処理されなければならないため、このようなコンテンツの分析自体が、所定の時間的遅延をもたらし、その期間の間は、緊急コール連結の品質に対する高い要求が満足できない。また、データ変換に関する構成の突然または一方的な変化は、このような変化がエレベータ側とコールセンター側の間で認識され、同期化されていないと、例えば圧縮や解凍のエラーを発生させ、データの損失を引き起こす場合がある。
【００１３】
本発明は、例えばエレベータの緊急状態に関して行われる、緊急送信と非緊急送信に対して、異なるモジュール構成を適用する際に、処理のためのリソースが小さくても、遅延の少ないデータ処理を可能とすることを目的とする。
【課題を解決するための手段】
【００１４】
上記課題を解決する本発明の一側面は、送信機から受信機へ、データを非緊急データ及び緊急データに区別して送信する通信システムである。このシステムにおいて、送信機は、入力部、出力部、記憶装置、セッション管理部、制御ユニット機能ブロック、および、データを処理するモジュールを備える。記憶装置は、データを送信するセッションを特定するセッションパラメータとセッションの生成タイミングを格納するセッション管理テーブルと、緊急状態と非緊急状態の転換タイミングを格納する緊急フラグテーブルと、非緊急データ及び緊急データのそれぞれに対してモジュールの適用の態様を定義するモジュールフラグ適用テーブルと、を備える。セッション管理部は、セッション管理テーブルの書き込みおよび読み出しを行い、制御ユニット機能ブロックは、入力部からデータが入力された場合、当該データに関連するセッションの情報をセッション管理部から得るとともに、緊急フラグテーブルを読み出し、セッションの生成タイミングと転換タイミングに基づいて、データを非緊急データあるいは緊急データに区別し、当該区別とモジュールフラグ適用テーブルの内容に基づいて、モジュールをデータに適用し、出力部から受信機へ送信する。
【００１５】
本発明の他の一側面は、データを非緊急データ及び緊急データに区別して送信する通信装置である。この通信装置では、入力部、出力部、記憶装置、セッション管理部、制御ユニット機能ブロック、および、データを処理するモジュール、を備える。記憶装置は、データを送信するセッションを特定するセッションパラメータと当該セッションの生成タイミングを格納するセッション管理テーブルと、緊急状態と非緊急状態の転換タイミングを格納する緊急フラグテーブルと、非緊急データ及び緊急データのそれぞれに対してモジュールの適用の態様を定義するモジュールフラグ適用テーブルと、を備える。セッション管理部は、セッション管理テーブルの書き込みおよび読み出しを行い、制御ユニット機能ブロックは、入力部からデータが入力された場合、当該データに関連するセッションの情報をセッション管理部から得るとともに、緊急フラグテーブルを読み出し、セッションの生成タイミングと前記転換タイミングに基づいて、データを非緊急データあるいは緊急データに区別し、当該区別とモジュールフラグ適用テーブルの内容に基づいて、モジュールをデータに適用し、出力部から送信する。
【００１６】
本発明のさらに他の一側面は、エレベータからコールセンタへデータを送信する際に、データを第１のモジュールおよび第２のモジュールの少なくとも一つで処理する通信方法である。この方法では、緊急状態および非緊急状態の２つの状態を設定可能である。非緊急状態であったときに開始されたセッションでは、データを第１のモジュールおよび第２のモジュールの両方で処理する非緊急設定を適用する。緊急状態であったときに開始されたセッションでは、データを第１のモジュールを用いずに第２のモジュールで処理する緊急設定を適用する。そして、緊急設定が適用されたセッションにおいては、途中で緊急状態が非緊急状態に遷移した場合でも、当該セッションが終了するまでは緊急設定の適用を継続する。
【発明の効果】
【００１７】
本発明は、送信及び変換モジュールの適用に関する緊急／非緊急構成の即座およびリソース軽量の決定を可能にし、間歇的または非同期化された構成変化を回避する。
【図面の簡単な説明】
【００１８】
【図１】本発明のシステム構成の概要を図示する構成要素ブロック図。
【図２】外部緊急装置により受信された緊急状態に関して異なるセッション及びそれらのそれぞれのモジュールの適用を図示する通信シーケンス及び送信及び変換モジュールの適用図。
【図３】異なるイベント、所定のイベントのタイムスタンプの比較及びそれらの異なる結果を図示するタイムチャート。
【図４】エレベータ側及びコールセンター側の関連した装置の構成を図示する構成要素ブロック図。
【図５】本発明の目的を達成するための異なる構成要素の間の相互作用の簡略化した概要を図示する構成要素ブロック及び相互作用図。
【図６】本発明の具現可能な構成のハードウェア構成要素を図示するハードウェア構成図。
【図７】本発明の緊急信号状態の獲得及び関連したデータ構造のアップデートのシーケンス図。
【図８】緊急データ送信の場合、本発明の重要な主機能を図示するシーケンス図。
【図９】非緊急データ送信の場合、本発明の重要な主機能を図示するシーケンス図。
【図１０】エレベータ側で行われる本発明の主機能のプログラムフロー。
【図１１】エレベータ側で本発明の主機能により行われるセッション及び緊急タイムスタンプの比較機能のプログラムフロー。
【図１２】本発明の緊急／非緊急関連状態によるデータ送信及び変換モジュールの適用を図示するプログラムフロー。
【図１３】コールセンター側で行われる本発明の主機能のプログラムフロー。
【図１４】本発明の登録された緊急／非緊急信号に関して関連データ構造をアップデートすることを図示するプログラムフロー。
【図１５】モジュールフラグ適用テーブルを図示するスキーマ（ｓｃｈｅｍａ）。
【図１６】緊急フラグテーブルを図示するスキーマ。
【図１７】セッション管理テーブルの例を図示するスキーマ。
【図１８】緊急状態ネットワークフラグ構造を図示するスキーマ。
【発明を実施するための形態】
【００１９】
実施の形態について、図面を用いて詳細に説明する。ただし、本発明は以下に示す実施の形態の記載内容に限定して解釈されるものではない。本発明の思想ないし趣旨から逸脱しない範囲で、その具体的構成を変更し得ることは当業者であれば容易に理解される。
【００２０】
以下に説明する発明の構成において、同一部分又は同様な機能を有する部分には同一の符号を異なる図面間で共通して用い、重複する説明は省略することがある。
【００２１】
本明細書等における「第１」、「第２」、「第３」などの表記は、構成要素を識別するために付するものであり、必ずしも、数または順序を限定するものではない。また、構成要素の識別のための番号は文脈毎に用いられ、一つの文脈で用いた番号が、他の文脈で必ずしも同一の構成を示すとは限らない。また、ある番号で識別された構成要素が、他の番号で識別された構成要素の機能を兼ねることを妨げるものではない。
【００２２】
図面等において示す各構成の位置、大きさ、形状、範囲などは、発明の理解を容易にするため、実際の位置、大きさ、形状、範囲などを表していない場合がある。このため、本発明は、必ずしも、図面等に開示された位置、大きさ、形状、範囲などに限定されない。
【００２３】
以下で説明する実施例のひとつを簡単に説明する。エレベータ制御ユニットは、外部装置、例えば、エレベータカー内の緊急コールボタンからの緊急信号を受信し、受信後、関連した緊急状態転換及びそれらのそれぞれのタイミングを緊急状態転換テーブルに登録する。送信データが送信準備されている時、例えば一部のデータソースが、データを制御ユニットに提供した後、関連したセッション生成時間が、緊急状態転換テーブルからの最近関連した有効緊急状態のタイムスタンプと比較される。比較結果に関して、一部の構成によって送信データに送信及び変換モジュールが適用され、以前の比較結果を示すネットワークヘッダが付加され、受信コールセンター側は構成された送信及び変換モジュールを類似した方式で適用することができる。
【実施例１】
【００２４】
第１実施例をより詳細に説明するために、図１乃至１８が用いられる。本発明の第１実施例に対する概要を提供するために、それぞれの図面の簡略な説明は次の通りである。
【００２５】
図１は、第１実施例のシステム構成の構成要素例を図示する。本発明の要点の概念を提供するために、図２及び図３が次の通り用いられる。
【００２６】
図２は、それぞれのセッション生成時間の間、それぞれの緊急状態に関して、異なるセッションに対する通信シーケンス及び送信及び変換モジュールの適用を図示する。
【００２７】
図３は、異なるセッションの生成及び緊急信号受信タイミング及びそれらのそれぞれのタイミングの比較の結果であって、異なるモジュール構成の簡略化した概要を図示する。
【００２８】
２つの図面は、登録された緊急信号のタイミングとデータ送信に用いられたセッション生成時間の間の関係が、データが緊急構成を用いて送信されるか、または非緊急構成を用いて送信されるかを決定する方法を説明する。
【００２９】
本発明の異なる構成要素だけでなく、それらの相互作用は、図４及び図５を用いて次の通り説明する。
【００３０】
図４は、送信エレベータ側及び受信コールセンター側における装置の可能性のある構成要素の構成及び主要構成要素の間の関連データ及び制御連結を図示する。
【００３１】
図５は、送信されるデータが到着する時、送信エレベータ側の主要構成要素の間のデータフロー及び構成要素の相互作用の簡略化した概要、及びそれぞれの送信及び変換モジュール構成が選択される方法を図示する。
【００３２】
本発明の第１実施例を具現するために可能性のあるハードウェア構成は、図６を用いて下記の通り説明する。
【００３３】
図６は、本発明の一実施例の可能性のあるハードウェア構成のハードウェア構成図を図示する。
【００３４】
本発明の要点を説明するイベントシーケンスが、図７、８及び９を用いて説明する。図７は、新しい緊急信号状態が獲得される毎に、例えば緊急ボタンが押され、関連信号が受信された時、またはコールセンターからの関連信号で以前の緊急状態がターンオフされる時、適用される関連データ構造のアップデートのシーケンス図を図示する。図８は、送信されるデータに適用されるモジュールの構成が緊急構成である場合、本実施例の一般的な動作を図示するシーケンス図である。図９は、モジュールの構成が非緊急構成である場合、本実施例の一般的な動作を図示する類似したシーケンス図である。
【００３５】
エレベータの制御ユニットに対して行われるメインエレベータ側のプログラムフローは、図１０、１１及び１２を用いて下記に説明し、また、図１２は、後述するコールセンター側で行われるフローである。図１０は、データが所定のデータソースから到着する時、送信側の制御ユニットにより行われ、コールセンターに送信されるエレベータ側の主要機能のプログラムフロー図である。図１１は、現在ペンディング中のデータに、いずれの送信及び変換モジュール構成が適用されるべきかを決定するために、送信に用いる関連セッションがセッション管理部から受信された後、図１０の送信側の制御ユニットのメインプログラムフローによるサブ−フローとして行われる、セッション及び緊急タイムスタンプの比較機能のプログラムフロー図である。図１２は、図１１のプログラムフローにより決定される緊急／非緊急構成に関して送信及び変換モジュールの適用を図示するプログラムフロー図であり、データが送信される時、エレベータ側の制御ユニットのメインプログラムフローによるサブ−フローとして行われ、データが受信された時、センター側通信機能のメインプログラムフローによるサブ−フローとして行われる。
【００３６】
コールセンターで行われるメインコールセンター側のプログラムフローは、図１３を用いて次の通り説明する。また、前述した通り、図１２のプログラムフローは、コールセンター側でも行われる。図１３は、データが受信される時、受信側の通信機能により行われるコールセンター側の主要機能を図示するプログラムフロー図である。
【００３７】
以下の段落で簡略に説明する通り、エレベータ側の制御ユニットが緊急信号を受信している時、図１４のプログラムフローが行われる。
【００３８】
図１４は、緊急信号が受信される時、例えば緊急ボタンが押された後、エレベータ側の制御ユニットにより行われる緊急フラグテーブルアップデートフローを図示するプログラムフロー図である。
【００３９】
本発明の第１実施例のために必要なメインデータ構造は、図１５、１６及び１７を用いて次の通り説明する。図１５のデータ構造は、エレベータ側の制御ユニット及びコールセンターの両方に保存され用いられる一方、図１６及び１７のデータ構造はエレベータ側の制御ユニットにのみ保存され用いられる。図１５は、エレベータ側の制御ユニット及びコールセンター側通信機能により管理される、緊急及び非緊急送信のための送信及び変換モジュール構成を説明するモジュールフラグ適用テーブルを図示するスキーマである。図１６は、エレベータ側の制御ユニットにより管理される緊急信号転換のタイミングを説明する緊急フラグテーブルを図示するスキーマである。図１７は、セッション生成時間のタイムスタンプ及び付加的なセッションパラメータを含み、エレベータ側のセッション管理部により管理される簡略化したセッション管理テーブルを例示する。
【００４０】
エレベータ側の制御ユニットが現在送信の緊急状態を、遠隔コールセンターに通知することを可能にするために、下記に図１８を用いて説明する通り、ネットワークフラグが用いられる。図１８は、緊急状態ネットワークフラグ構造、及び送信エレベータ側から受信コールセンター側に緊急状態を通知することを可能にするネットワークヘッダフラグを図示する簡略化したスキーマである。
【００４１】
今までの簡略な説明から、本発明の一般的な概要が提供された。各図面の詳細な説明は、下記の通りである。
【００４２】
本実施例では計算や制御等の機能は、記憶装置に格納されたプログラムがプロセッサ（ＣＰＵ）によって実行されることで、定められた処理を他のハードウェアと協働して実現する。計算機などが実行するプログラム、その機能、あるいはその機能を実現する手段を、「機能」、「手段」、「部」、「ユニット」、「モジュール」、「ブロック」、「フロー」等と呼ぶ場合がある。また、便宜上、これらを処理の主体として説明することがある。
【００４３】
なお、ソフトウエアで構成した機能と同等の機能は、FPGA（Field Programmable Gate Array）、ASIC（Application Specific Integrated Circuit）などのハードウエアでも実現できる。そのような態様も本願発明の範囲に含まれる。
【００４４】
図１は、実施例のシステム構成（１００）を図示する。エレベータ（１１０）は、ＷＡＮ（１５０）に連結される制御ユニット（１２０）を収容しており、さらに、コールセンター（１３０）も同様にＷＡＮに連結される。エレベータ（１１０）内の制御ユニット（１２０）は、ＷＡＮ（１５０）を通じてコールセンター（１３０）に対してデータを送信及び受信することができる。
【００４５】
図２は、エレベータからコールセンターにデータを送信する際の、複数のセッションの通信シーケンス、及び緊急／非緊急状態の遷移に対応して適用される緊急／非緊急送信及びそれに用いられる変換モジュールを図示する。
【００４６】
緊急状態（２０１）は、左側に緊急状態転換ライン（２１０）で図示される。“ＯＮ”が緊急状態を示し、“ＯＦＦ”は非緊急状態を示す。すなわち、この情報は、緊急状態から非緊急状態への遷移タイミング、および、非緊急状態から緊急状態への遷移タイミングを示している。タイムライン（２２０）上に図示されるように、４つの異なるセッション“セッション＃１”乃至“セッション＃４”はいずれも送信機（２０２）から開始する。図２で送信機（２０２）は、データ送信に対するエレベータ側のエンドポイントであり、また、セッションのオリジンを単純化して示している。反対側のコールセンター側では、同様に受信機（２０８）が単純化したエンドポイントである。
【００４７】
それぞれのセッションのデータは、ＷＡＮ（２０５）を通じて送信される前に、送信側で、第１送信変換モジュール、即ち、モジュール＃１（２０３）、及び第２送信及び変換モジュール、即ち、モジュール＃２（２０４）に対して適用または通過される。受信側では、セッションのデータは逆順にモジュール＃２（２０６）及びモジュール＃１（２０７）に対して適用または通過される。
【００４８】
ライン（２２１）で図示されるように、“セッション＃１”は、緊急状態転換ライン（２１０）で図示されるように、緊急状態が“ＯＦＦ”である間に生成されるため、非緊急送信のためのモジュール構成が適用される。即ち、まず送信側の２２２でモジュール＃１（２０３）、２２３でモジュール＃２（２０４）、及び受信側の２２４でモジュール＃２（２０６）及び２２５でモジュール＃１（２０７）がデータに適用される。同様の方式で、受信機（２０８）からの応答が行われる。即ち、まず受信側２２６でモジュール＃１（２０７）が適用され、その後、２２７でモジュール＃２が適用され、続いて送信側の２２８でモジュール＃２（２０４）、及び２２９でモジュール＃１（２０３）が適用される。
【００４９】
セッション＃２は、非緊急状態で同様に生成される。しかし、セッション＃２の以後、緊急状態転換ライン上の２１１で図示されるように、“ＯＮ”への緊急状態転換が発生する。このような変更された緊急状態の間、セッション＃３が生成され、緊急送信のためのモジュール構成が適用される。即ち、送信側の２４０でモジュール＃１（２０３）は通過されるが、２４１でモジュール＃２（２０４）は適用され、同様に、受信側の２４２でモジュール＃２（２０６）は適用されるが、２４３でモジュール＃１（２０７）は通過される。
【００５０】
セッション＃４が生成される前に、２１２で図示されるように、“ＯＦＦ”への緊急状態転換が発生し、その後、非緊急状態のためのモジュール構成がセッション＃４のデータに適用される。
【００５１】
一方、セッション＃３はタイミング２１２以降も継続しており、送信機２０２と受信機２０８の間でデータがやり取りされている。２１２のタイミングの後、状態転換ライン上の２１３で図示されるように、緊急状態は“ＯＦＦ”となっているが、セッション＃３は緊急“ＯＮ”状態の間に生成されたため、２６０、２６１、２６２及び２６３で図示されるように、緊急送信のための構成が適用される。
【００５２】
同様の方式で、２１４で緊急状態が“ＯＮ”に変更された後、前述したセッション＃４を通じた後続送信は、セッション＃４が緊急状態が“ＯＦＦ”の間に生成されたため、２７０、２７１、２７２及び２７３で図示するように、非緊急送信のためのモジュール構成を用いている。
【００５３】
図２に図示されるシーケンスの特徴は、現在の緊急状態とは関係なく、セッション生成時の緊急状態に基づいて、セッション毎の送信及び変換モジュール構成が定まる点である。これは、送信側及び受信側でモジュールの順序及び適用が同一に保持されることを確保することによって、異なる方式が適用されるデータ送信の安全を確保しながら、緊急送信のために遅延誘発モジュールに対する迅速な無効化（ｄｉｓａｂｌｉｎｇ）を可能にする。
【００５４】
図３は２つの例（３００及び３５０）における、緊急状態転換状態とセッション生成時間のタイミングの比較を図示する。
【００５５】
第１の例（３００）では、まず第１緊急信号（例えば、エレベータカー内の緊急ボタンを押すこと）が、タイムライン（３０５）上に図示されるように、３１１の時間ｔＥで受信される。ある程度の時間後に、３１２で時間ｔ１で新しいセッションが生成される。その後、３１３で時間ｔ２で第１データ送信が発生し、３１４で時間ｔ３で第２データ送信が発生する。
【００５６】
緊急モジュール構成を用いるか、または非緊急モジュール構成を用いるかを決定するために、両方のデータ送信のタイミングｔ２とｔ３で、緊急信号のタイムスタンプｔＥとセッション生成時間のタイムスタンプｔ１が比較され、例示（３００）では、３４０で図示されるように、セッション生成時間ｔ１は緊急信号ｔＥの登録の時間と同一またはそれより遅いため、緊急モジュール構成が適用される。
【００５７】
第２の例（３５０）では、まず３６１で時間ｔ１で新しいセッションが生成される。続いて、３６２で時間ｔ２で第１データ送信が発生する。その後、３６３で時間ｔＥで緊急信号が受信される。続いて、３６４で時間ｔ３で第２データ送信が発生する。
【００５８】
この例において、３９０における比較は、セッション生成時間ｔ１が緊急信号時間ｔＥより早いことを示すため、第１および第２データ送信のために非緊急モジュール構成が適用される。図３に図示されるタイミング比較は、指定されたセッションが終了するまでの間、ペンディング中のデータの送信に、緊急送信及び変換モジュール構成が適用されるべきか、または非緊急送信及び変換モジュール構成が適用されるべきかを決定する、簡単かつ迅速な方法を提供する。一般にセッション生成時間はセッション管理部により管理されているので、登録された緊急状態転換のタイミングの登録及び管理及びデータ送信前の関連したタイミングの比較のための構成を付加すればよい。
【００５９】
図４は、本発明の一実施例の構成要素、及びそれらのそれぞれのデータ及び制御連結を図示する。
【００６０】
上部に図示される送信側には、制御ユニット（１２０）、緊急入力装置（４１０）、及び所定のデータソース（４１１）を収容するエレベータ（１１０）がある。一実施例において、緊急入力装置（４１０）は、エレベータカー内の緊急コールボタンである。制御ユニット（１２０）は、多数の機能ブロック及びデータ構造を含むプロセッサである。一実施例において、制御ユニット（１２０）は汎用プロセッサであり、図４に図示される機能ブロックは、それらの実際の表現の抽象的な概念である。
【００６１】
制御ユニット（１２０）に含まれる機能ブロックは、セッション管理部（４２０）、制御ユニット機能ブロック（４３０）、第１送信及び変換モジュール、即ち、モジュール＃１（４５０）、及び第２送信及び変換モジュール、即ち、モジュール＃２（４６０）であり、本実施例の説明で、送信及び変換モジュールの数は、理解を容易にするために２つに制限されるが、一般的にモジュールの数は制限されない。
【００６２】
一実施例において、モジュール＃１は、帯域幅評価モジュールであり、モジュール＃２は、圧縮／解凍モジュールである。セッション管理部（４２０）は、エレベータの制御ユニット（１２０）と遠隔にあるコールセンター（１３０）の間のエンドツーエンド通信セッションを管理しており、一実施例において、セッション管理部（４２０）は、ＴＣＰ及びＵＤＰセッションを処理している。処理には例えばセッションの生成及び破棄を含む。セッション管理に関する情報は、セッション管理部（４２０）に連結されているセッション管理テーブル（１８００）に保存される。点線で制御のための連結を示す。
【００６３】
制御ユニット機能ブロック（４３０）は、保守データ及び緊急コールデータのエンドツーエンドデータ送信及び、送信及び変換モジュールの送信データへの適用を処理している。
【００６４】
所定のデータソース（４１１）から送信されるデータが発信されており、一実施例において、データソースは、エレベータの利用及び関連構成要素の状態情報を周期的に送信している。送信データフローは、点線（４４１）で図示される。異なる送信及び変換モジュールを通じて送信データフローを制御するために、制御ユニット機能ブロック（４３０）は、制御連結（４４５）でスイッチ（４４０及び４４２）を制御しており、第１スイッチ（４４０）は、送信データがモジュール＃１（４５０）を通じてフローするか否かを制御し、第２スイッチ（４４２）は、送信データがモジュール＃２（４６０）を通じてフローするか否かを制御する。
【００６５】
送信データに、どのモジュールが適用されるべきか決定するために、制御ユニット機能ブロック（４３０）は、一実施例において、セッションの緊急／非緊急状態に関する送信及び変換モジュールの適用構成を含む、モジュールフラグ適用テーブル（１５００ａ）内の情報を用いている。セッションの緊急状態を決定するために、制御ユニット機能ブロック（４３０）は、セッション管理部（４２０）により受信される関連セッション情報、及び緊急フラグテーブル（１６００）を用いている。一実施例において、緊急入力装置（４１０）により受信される緊急信号は、緊急フラグテーブル（１６００）に登録される。必要なモジュールが適用された後、送信データはＷＡＮ（１５０）を通じて下部側に図示される受信側のコールセンター（１３０）に送信される。
【００６６】
コールセンター（１３０）のブロックは、制御ユニット（１２０）と同様に、順次にコールセンター通信機能ブロック（４７０）により制御される２つのスイッチ（４７２及び４７４）により適用が制御される多数の送信及び変換モジュール、即ち、モジュール＃２（４９０）及びモジュール＃１（４８０）を含むプロセッサである。コールセンター通信機能ブロック（４７０）は、エレベータ側の制御ユニット機能ブロック（４３０）と同様に、モジュールフラグ適用テーブル（１５００ｂ）を用いてモジュールの適用構成を適用している。緊急状態を決定するために、コールセンター通信機能ブロック（４７０）は、受信された送信データに含まれたネットワークヘッダ情報を参照している。
【００６７】
図４に図示されるような、構成要素の間の制御及びデータフローによって、エレベータ側では、テーブル内に管理される情報により、緊急／非緊急状態に基づいた送信及び変換モジュールの適用を決定することができる。受信コールセンター側では、ネットワークヘッダ情報を考慮して、緊急／非緊急状態に基づいた送信及び変換モジュールの適用を行うことができる。
【００６８】
図５は、制御ユニット（１２０）の主要構成要素に焦点を合わせ、本発明の一実施例の動作の概要を図示する。一般的なデータフローは下部に図示され、データ（５４０）は、制御ユニット（１２０）により受信され、スイッチ（５５０）の位置によって選択可能な、異なるモジュールによって予め構成された経路のうちの一つを経由して、ＷＡＮ（１５０）に送出される。
【００６９】
この簡略化した概要では、２つの送信及び変換モジュール、即ち、モジュール＃１及びモジュール＃２がこの順に適用されるか、またはモジュール＃２のみ適用される。例えば、前者の構成は非緊急送信のためのものであり、後者は緊急送信のためのものである。
【００７０】
スイッチ（５５０）の設定に関連する情報及び判断を、図５の上部３分の２の構成要素を用いて説明する。まず、後に図１４で説明する、緊急入力装置（４１０）からの信号が緊急フラグテーブルアップデートフローを行う機能ブロック（１４００）により受信されて処理され、結果は緊急フラグテーブル（１６００）に登録される。
【００７１】
データが送信される時（例えば、データ（５４０））、順次にセッション管理テーブル（１８００）に保存された情報を用いるセッション管理部（４２０）から関連セッションが要求される。セッション情報、及び緊急フラグテーブル（１６００）に保存された関連緊急状態情報が機能ブロック（１１００）により処理され、関連セッションの緊急状態を決定する。
【００７２】
後に図１１で説明する、機能ブロック（１１００）は、セッション及び緊急タイムスタンプの比較を行うタイムスタンプ比較機能フローを行っている。関連セッションに対する緊急状態、及びモジュールフラグ適用テーブル（１５００）に含まれたモジュールの適用構成が、機能ブロック（１２００）により処理され、データ（５４０）が、どの経路を経由すべきかを決定するスイッチ（５５０）を設定する。
【００７３】
機能ブロック（１２００）は、後に図１２で説明するように、データに全てのイネーブル通信モジュールを適用するモジュールの適用機能フロー（１２００）を行うことによって、実際の「スイッチ設定」及び送信及び変換モジュールの適用を行っている。
【００７４】
図５に図示される構成要素相互作用の効果は、登録された緊急信号に基づいて制御ユニット機能ブロックにより得られた緊急状態転換情報と、セッション管理部により管理された関連セッション情報のタイミングの比較に基づいて、実際の送信データに緊急もしくは非緊急モジュール構成を適用することである。
【００７５】
図６は、本実施例を具現するために、可能性のあるハードウェア構成要素の構成を図示する。制御ユニット（１２０）は、本実施例に説明した異なる機能を行うことができる類似した構成要素を含み得る。ＣＰＵ（７１５）、記憶装置として主メモリ（７２０）および補助メモリ（７３０）、ＮＩＣ（７４０）及び所定のシリアル入力／出力（Ｉ／Ｏ）（７６０）が所定の通信バス（７１０）を通じて相互連結されている。
【００７６】
構成要素の数は変化し得、例えば、他のＮＩＣがバスに取り付けられる。ＣＰＵ（７１５）は、汎用プロセッサであり得、通信バス（７１０）を通じて連結された他の構成要素にアクセスすることができ、例えば、主メモリ（７２０）に保存されたプログラム命令にアクセスし、所定のプログラムを処理することができる。プログラムは、例えば、本発明の実施例の異なるプログラムフローを具現する所定のマシンコード（ｍａｃｈｉｎｅ  ｃｏｄｅ）である。
【００７７】
一実施例において、プログラム命令は、所定の不揮発性の補助メモリ（７３０）に保存されており、開始時間にＣＰＵにより主メモリ（７２０）内にコピーされ、その後実行される。一実施例において、データソース（４１１）及び緊急入力装置（４１０）は、シリアルＩ／Ｏ（７６０）を通じて連結されており、ＷＡＮは、ＮＩＣ（７４０）を通じて連結されている。
【００７８】
図６に図示される構成は、本実施例を具現するための最小限の構成であり、本実施例の適用を制限せず変更され得る。典型的な一実施例によると、ＣＰＵ（７１５）は、メモリ（７２０または７３０）に保存されたプログラムを実行して実施例の機能を行う。本発明の範囲を制限せず、ＣＰＵ（７１５）の代りに非汎用プロセッサを用いた具現も可能である。
【００７９】
図７は、緊急信号の獲得及び登録のシーケンスを図示する。受信側であるコールセンター（１３０）だけでなく、送信エレベータ側の緊急入力装置（４１０）及び制御ユニット機能ブロック（４３０）が図示される。所定の緊急状態情報、例えば「ボタンを押す」メッセージ（６１０）が緊急入力装置（４１０）により送信され、制御ユニット機能ブロック（４３０）により受信される。その後、制御ユニット機能ブロック（４３０）は、緊急フラグテーブルアップデートフロー（１４００ａ）を行っている。緊急フラグテーブルアップデートフロー（１４００ａ）の処理では、例えば緊急状態転換を緊急フラグテーブル（１６００）（図示しない）内に登録する。これで、緊急“ＯＮ”状態転換を引き起こすイベントの基本的な処理シーケンスが終了する。
【００８０】
図７の下部に、緊急状態が“ＯＦＦ”への転換を引き起こすイベントが同様に図示され、コールセンター（１３０）は「緊急ターンオフ」のメッセージ（６２０）を、その後、緊急フラグテーブルアップデートフロー（１４００ｂ）を行う制御ユニット機能ブロック（４３０）に送信している。緊急フラグテーブルアップデートフロー（１４００ｂ）の処理では、例えば関連した緊急状態転換を上記と同様に登録する。一般的に、非緊急信号（“緊急状況ＯＦＦ”のメッセージ（６２０））の送信者はコールセンター（１３０）であるが、本発明の範囲を制限しない他の信号ソースも可能である。
【００８１】
図７に説明したシーケンスは、制御ユニット機能ブロック（４３０）により所定の信号メッセージ（６１０または６２０）が受信される毎に発生している。図７に図示されるシーケンスは、例えばエレベータカー内の緊急コールボタン等の緊急入力装置から受信される、緊急信号及び関連情報に基づいた緊急状態転換のアップデートを可能とする。
【００８２】
図８は緊急データ送信の場合における、本発明の一実施例のシーケンス図である。図示される構成要素は、送信エレベータ側の制御ユニット機能ブロック（４３０）、セッション管理部（４２０）、第１送信及び変換モジュール、即ち、モジュール＃１（４５０）、及び第２送信及び変換モジュール、即ち、モジュール＃２（４６０）、及び受信コールセンター側の第２送信及び変換モジュール、即ち、モジュール＃２（４９０）、第１送信及び変換モジュール、即ち、モジュール＃１（４８０）、及びコールセンター通信機能ブロック（４７０）である。
【００８３】
まず、データが送信準備されているという所定のメッセージ（８１０）が制御ユニット機能ブロック（４３０）により受信される。続いて、メインフロー（１０００）の動作が、制御ユニット機能ブロック（４３０）により行われる。
【００８４】
メインフロー（１０００）では、まず８１５で「セッション獲得」のメッセージをセッション管理部（４２０）に送信することによって、送信するデータに関連したセッションを要請する。セッション管理部４２０では、所定のセッションルックアップの処理（８１７）を行い、８１９で関連したセッションを制御ユニット機能ブロック（４３０）に返還する。この関連したセッションは、「現在セッション」と称され得る。
【００８５】
セッション要請（８１５）に対する応答（８１９）が制御ユニット機能ブロック（４３０）に送信される際には、セッションルックアップ（８１７）では、新しいセッションがセッション管理部（４２０）によりセットアップされるか、または既存のセッションが検索される。
【００８６】
続いて、制御ユニット機能ブロック（４３０）で、メインフロー（１０００）によりセッション及び緊急タイムスタンプの比較を行うタイムスタンプ比較機能フロー（１１００）が行われる。この比較では、図７のシーケンス図に示されるように、以前に緊急フラグテーブル（１６００）に登録された緊急状態転換のタイムスタンプと、セッション管理部（４２０）から返還されるメッセージ（８１９）を比較することで、関連した現在セッションに対する緊急状態を決定する。メインフロー（１０００）の詳細は後に図１０で、タイムスタンプ比較機能フロー（１１００）詳細は後に図１１で説明する。
【００８７】
この例において、現在セッションに対する緊急状態は“ＯＮ”であり、これは現在セッションに緊急構成が適用されることを意味する。従って、続いて制御ユニット機能ブロック（４３０）のメインフロー（１０００）によりネットワークデータ内の緊急フラグ設定処理（８２０）が行われ、ネットワークデータにＴＣＰオプションを付加し、受信コールセンターに対して適用された緊急状態を通知する。
【００８８】
その後、制御ユニット機能ブロックのメインフロー（１０００）により全てのイネーブル通信モジュールのデータへの適用を行うモジュールの適用機能フロー（１２００ａ）が行われ、送信されるデータに現在セッションの緊急状態に関して全ての必要な送信及び変換モジュールを適用する。この例において、緊急送信であるので、モジュール＃２のみ適用するため、送信データはメッセージ（８３０）でモジュール＃２（４６０）に送信され、モジュール＃２（４６０）で処理された結果はメッセージ（８３２）で返還され、送信データをアップデートする。
【００８９】
最終的に、制御ユニット機能ブロック（４３０）のメインフロー（１０００）は、メッセージ（８３８）の送信データをコールセンター通信機能ブロック（４７０）に送信する。
【００９０】
コールセンター機能ブロックのメインフロー（１３００）は、送信データを受信し、ネットワークデータ内の緊急フラグ獲得機能ブロック（８５０）にネットワークデータ内の関連ＴＣＰオプションに対するチェックを行い、現在セッションの緊急状態を決定する。
【００９１】
この例においては緊急送信であるので、関連ＴＣＰオプションが発見されるため、緊急モジュール構成が適用されなければならない。続いて、全てのイネーブル通信モジュールのデータへの適用を行うモジュールの適用機能フロー（１２００ｂ）が、コールセンター機能ブロックのメインフロー（１３００）により行われ、現在のセッションの緊急状態に関して全ての必要な送信及び機能モジュールを適用する。ここで、緊急送信のための構成は、送信側で適用された構成と同様にモジュール＃２のみ適用するものであるため、受信された送信データは、メッセージ（８６０）内でモジュール＃２（４９０）に送信され、結果はメッセージ（８６２）で返還され、受信された送信データをアップデートする。
【００９２】
これで、主機能処理が終了する。一例において、コールセンター通信機能ブロック（４７０）は、その後、受信された送信データを保存するか、または所定の保守関連分析のために使用することができる。
【００９３】
図９は、非緊急データ送信の場合、本発明の一実施例のシーケンス図である。一般的に、図９に図示される機能シーケンスは、図８に図示されるものと類似しており、一部は現在セッションの緊急／非緊急状態に関連して変更される。本説明は、主に相違点に焦点を合わせる。
【００９４】
送信のために準備された送信データが制御ユニット機能ブロック（４３０）によりメッセージ（９１０）で受信された後、メインフロー（１０００）が行われ、続いて現在セッションがセッション管理部により受信される。後続するセッション及び緊急タイムスタンプの比較を行うタイムスタンプ比較機能フロー（１１００）は、現在セッションに対する緊急状態を“ＯＦＦ”にし、これは、非緊急構成が適用されることを意味する。
【００９５】
この場合、続いて全てのイネーブルになった通信モジュールのデータへの適用を行うモジュールの適用機能フロー（１２００ａ）が行われる。まずメッセージ（９３０）で送信データをモジュール＃１に送信し、モジュール＃１で処理された結果をメッセージ（９３２）で受信し、送信データをアップデートする。アップデートされた送信データをメッセージ（９３４）でモジュール＃２に送信し、モジュール＃２で処理された結果をメッセージ（９３６）で受信し、送信データを再びアップデートする。アップデートされた送信データをメッセージ（９３８）でコールセンター通信機能ブロック（４７０）に送信する。
【００９６】
コールセンター通信機能ブロック（４７０）は、そのメインフロー（１３００）で送信データを受信し、ネットワークデータ内の所定の関連したＴＣＰオプションに対するチェックを行うことによって現在セッションの関連した緊急状態を決定する。図９の例では、このようなオプションが発見されないため、非緊急状態が仮定される。
【００９７】
続いて、全てのイネーブルになった通信モジュールのデータへの適用を行うモジュールの適用機能フロー（１２００ｂ）が行われ、順次に、受信された送信データをまずメッセージ（９６０）内でモジュール＃１に送信し、その結果をメッセージ（９６２）内で受信し、送信データをアップデートして、アップデートされた送信データを再びメッセージ（９６４）内でモジュール＃２に送信し、その結果をメッセージ（９６６）内で受信し、それに応じて送信データをアップデートする。また、受信されてアップデートされた送信データの処理は、図８の説明と同様に発生し得る。
【００９８】
図１０は、送信側エレベータの制御ユニット機能ブロック（４３０）で行われるメインフロー（１０００）のプログラムフローを図示する。
【００９９】
ステップ（１０１５）でデータが送信される場合、送信側の制御ユニット機能ブロック（４３０）によりプログラムフローが開始される。この場合、データは例えば、データソース（４１１）により生成されたデータである。
【０１００】
続いて、ステップ（１０２０）で、送信されるデータのネットワークパラメータを用いて、セッション管理部（４２０）から当該送信に適用可能なセッション（現在セッションと称される）が要求される。ネットワークパラメータには、例えば、保守関連データでは、所定のプロトコル、受信先ＩＰアドレス及びプロトコルポートを設定することができる。
【０１０１】
関連したセッションがまだ存在しない場合は、セッション管理部（４２０）は遠隔コールセンターとのセッションをセットアップ及び設定するために必要な、全てのステップを処理する。ここで、セッションは一実施例において、公知のＵＤＰまたはＴＣＰセッションであり、公知のステップにより確立できる。一実施例において、処理の結果生成されたセッション情報は、図１７のセッション管理テーブル（１８００）の一つのロー（ｒｏｗ）であり得る。
【０１０２】
続いて、現在セッションのタイムスタンプＴ１がステップ（１０３０）で取得される。タイムスタンプＴ１はセッションパラメータを指定してセッション管理テーブル（１８００）を参照することにより、以前に受信されたセッション情報のＴ１カラム（１８１０）内の値として取得することができる。タイムスタンプＴ１によって、現在セッションの生成時間を知ることができる。
【０１０３】
続いて、セッション及び緊急タイムスタンプの比較を行うサブフローである、タイムスタンプ比較機能フロー（１１００）が行われる。タイムスタンプ比較機能フロー（１１００）の結果は、その後のステップ（１０４０）で緊急状態変数（現在セッションの緊急状態であり、“Ｙｅｓ”または“Ｎｏ”である）に記録される。
【０１０４】
次のステップ（１０５０）で、緊急状態変数の値が評価され、その値が“Ｙｅｓ”であれば、送信データに緊急構成が適用されるべきことを意味し、プログラムフローは、ステップ（１０５２）に続き、ここでネットワークデータ内で緊急フラグが設定される。一実施例において、このフラグは、後に図１８の緊急状態ネットワークフラグ構造（１７００）の緊急フラグフィールド（１７３５）で説明するとおりである。
【０１０５】
次のステップで、全てのイネーブルになった通信モジュールのデータへの適用を行うモジュールの適用機能フロー（１２００）がサブフローとして行われ、必要に応じて通信モジュールが送信データをデータ変換することができる。
【０１０６】
続いて、必要に応じてデータ変換された送信データが、ステップ（１０６０）で受信機に送信される。受信機は例えば、コールセンター（１３０）である。最終的に、フローはステップ（１０９０）で終了する。
【０１０７】
ステップ（１０５０）で緊急状態変数が“Ｎｏ”と評価されれば、これは、送信データに非緊急構成が適用されるべきことを意味し、プログラムフローは、ステップ（１０５２）をスキップして、直ちにコーリングされるサブフローであるモジュールの適用機能フロー（１２００）へ続く。
【０１０８】
図１０のプログラムフローによれば、送信されるデータが送信側の制御ユニット機能ブロックにより受信された後、関連したサブフローが順次に行われ、関連した現在セッション情報を受信し、関連した現在セッションに関する緊急状態を判定する。判定した緊急状態に基づいて、送信データに関する送信及び変換モジュールを適用して、また現在セッションの以前に判定された緊急状態を受信機に通知するためにネットワークデータ内のヘッダフラグを準備し、受信側でネットワークヘッダを考慮することだけで緊急状態を判定することができる。
【０１０９】
図１１はセッション及び緊急タイムスタンプの比較を行うタイムスタンプ比較機能フロー（１１００）の詳細を図示する。
【０１１０】
このプログラムフローは、ステップ（１１１５）に図示されるように、セッション管理部から現在セッションが受信された後、メインフロー（１０００）のサブフローとして送信側エレベータの制御ユニット機能ブロック（４３０）により開始される。
【０１１１】
まず、ステップ（１１２０）で現在セッションのタイムスタンプＴ１が決定される。これは、図１０のメインフロー（１０００）のステップ（１０２０）で受信された現在セッション情報のＴ１カラム（１８１０）内の値であり得、現在セッションの生成時間を示す。
【０１１２】
続いて、ステップ（１１３０）で、図１６の緊急フラグテーブル（１６００）の最終エントリーが変数Ｃに記入される。
【０１１３】
続いて、ステップ（１１４０）で、タイムスタンプＴＣは変数ＣのエントリーのカラムＴＥ内のタイムスタンプとして決定される。
【０１１４】
ステップ（１１５０）で、現在セッションのタイムスタンプＴ１と変数ＣのエントリーのタイムスタンプＴＣが比較される。すなわち、Ｔ１がＴＣ以上であるか否かが評価される。評価が肯定であれば、即ち、現在セッション生成時間が変数Ｃに現在含まれている、受信された緊急信号の登録時間と同一の時間またはそれより遅い時間である場合、ステップ（１１５２）で続き、ここで変数Ｃの“緊急フラグ”カラムの値は、制御ユニット機能ブロック（４３０）に返還される。
【０１１５】
“緊急フラグ”カラムの値は変数Ｃに現在含まれている、登録された緊急状態であり、一実施例において、これは緊急フラグテーブル（１６００）内の緊急フラグカラム（１６２０）の緊急フラグであり得、“ＯＮ”または“ＯＦＦ”の値を有し得る。
【０１１６】
これで、プログラムフローは、ステップ（１１９０）で終了する。ステップ（１１５０）における評価が否定であれば、即ち、タイムスタンプＴ１により指定された現在セッション生成時間が変数Ｃに現在含まれた緊急信号の登録時間より早ければ、ステップ（１１５４）で続く。
【０１１７】
ステップ（１１５４）で、変数Ｃのエントリーが緊急フラグテーブル（１６００）の第１エントリーなのか否かが評価される。肯定の場合、緊急フラグテーブル（１６００）にはさらに早い緊急信号が登録されていないので、プログラムフローは、ステップ（１１５２）に続く。
【０１１８】
否定の場合、プログラムフローは、ステップ（１１５８）で続き、ここで緊急フラグテーブル（１６００）の、ひとつ以前のエントリーが変数Ｃに記録される。例えば、ステップ（１１５０）で変数Ｃが緊急フラグテーブル（１６００）の第３エントリーを含む場合には、ステップ（１１５８）で緊急フラグテーブル（１６００）の第２エントリーがＣに記録される。
【０１１９】
続いて、プログラムフローは、ステップ（１１４０）に続き、タイムスタンプＴＣは、ひとつ以前の変数ＣのエントリーのカラムＴＥ内のタイムスタンプとして決定される。
【０１２０】
図１１のタイムスタンプ比較機能フロー（１１００）では、現在セッションに対して緊急フラグテーブル（１６００）内の関連したエントリーの緊急状態を判定する。緊急状態を判定することにより、その後、送信データのコンテンツまたはネットワークデータの所定の統計を考慮せず、送信データにどのモジュール構成が適用されるべきかを決定することができる。
【０１２１】
緊急フラグテーブル（１６００）内の“関連したエントリー”を検出するために、最も大きいタイムスタンプを有するエントリー（すなわち最終エントリー）から、逆順にエントリーを判定していく。現在セッションが発生した時点での“関連したエントリー”の状態を検出するためには、エントリーのタイムスタンプＴＣが、現在セッションのタイムスタンプＴ１よりも小さいか同一になるまで図１１の処理ループを実行すればよい。なお、“現在セッションのタイムスタンプ”は、実質的に現在セッションが生成された時のタイムスタンプである。
【０１２２】
図１２は全てのイネーブルになった通信モジュールのデータへの適用を行うモジュールの適用機能フロー（１２００）を示す。このプログラムフローは、送信側である制御ユニット（１２０）と受信側であるコールセンター（１３０）の双方で実行される。
【０１２３】
ステップ（１２１５）に示されるように、このプログラムフローは、現在セッションの緊急状態が決定された後、データが送信される前に送信側の制御ユニット機能ブロック（４３０）のメインフロー（１０００）により開始される。また、データが受信され、受信されたネットワークデータ内の緊急フラグの存在及び状態が決定された後、受信側コールセンター通信機能ブロック（４７０）のメインフロー（１３００）により開始される。メインフロー（１３００）は、後に図１３を用いて説明する。
【０１２４】
ステップ（１２２０）で、現在の緊急状態が緊急状態変数として獲得される。遂行する構成要素が制御ユニット機能ブロック（４３０）である場合、現在緊急状態はメインフロー（１０００）内のサブフローとしてコーリングされていたタイムスタンプ比較機能フロー（１１００）の結果により決定される。また、遂行する構成要素がコールセンター通信機能ブロック（４７０）である場合、現在緊急状態はコールセンター通信機能ブロックのメインフロー（１３００）のプログラムステップ（１３４４または１３４６）により決定される。
【０１２５】
ステップ（１２３０）で、緊急状態変数の値が評価され、結果が肯定であれば（すなわち結果が緊急状態を示していれば）、プログラムフローは、ステップ（１２３２）で続く。
【０１２６】
ステップ（１２３２）で、適用カラムは、モジュールフラグ適用テーブル（１５００）の“緊急のための構成”に設定される。
【０１２７】
続いて、ステップ（１２４０）で、現在エントリーは、モジュールフラグ適用テーブル（１５００）の第１エントリーに設定される。
【０１２８】
ステップ（１２５０）で、現在エントリーのエントリーの適用カラムのカラム内の値が考慮される。
【０１２９】
ステップ（１２６０）で、ステップ（１２５０）で考慮された値が“適用”なのか否かが評価される。ステップ（１２６０）の評価が肯定（すなわち値が“適用”）であれば、プログラムフローは、ステップ（１２６２）へ続く。
【０１３０】
ステップ（１２６２）で、現在エントリーのモジュールＩＤカラム（１５１０）により参照されたモジュールが送信データに適用され、例えば、モジュールが圧縮モジュールであれば、送信データは、モジュールにより圧縮される。他の例は、帯域幅評価モジュールであり、ここでネットワーク応答を含むネットワークデータが考慮され、考慮されたデータに基づいて帯域幅評価が行われる一方、送信データは変更されない。
【０１３１】
後続するステップ（１２６４）で、現在エントリーがモジュールフラグ適用テーブル（１５００）の最終エントリーなのか否かが評価される。ステップ（１２６４）の評価が肯定であれば、プログラムフローは、ステップ（１２９０）で終了する。
【０１３２】
ステップ（１２６４）の評価が否定であれば、プログラムフローは、ステップ（１２６８）で続き、ここで現在エントリーは、モジュールフラグ適用テーブル（１５００）の次のエントリーに設定される。例えば、現在エントリーがモジュールフラグ適用テーブル（１５００）の第１エントリーであれば、ステップ（１２６８）で現在エントリーは、モジュールフラグ適用テーブル（１５００）の第２エントリーに設定される。続いて、プログラムフローは、ステップ（１２５０）へ続く。
【０１３３】
ステップ（１２６０）における評価が否定であれば、ステップ（１２６２）はスキップされ、プログラムフローは、ステップ（１２６４）で続き、これは現在エントリーにより参照されたモジュールは通過またはスキップされることを意味する。
【０１３４】
ステップ（１２３０）における評価が否定であれば、プログラムフローは、ステップ（１２３４）へ続き、ここで適用カラムは、モジュールフラグ適用テーブル（１５００）の非緊急のための構成カラム（１５２０）に設定される。プログラムフローはその後、ステップ（１２４０）で続く。
【０１３５】
図１２に図示されるプログラムフローの効果は、現在セッションの緊急状態を決定し、それに応じてモジュールフラグ適用テーブル（１５００）に従って、各モジュールの適用状態を設定することである。
【０１３６】
図１３はコールセンター通信機能ブロック（４７０）のメインフロー（１３００）を図示する。このプログラムフローはデータが受信される時、受信側コールセンター通信機能ブロック（４７０）により開始される。
【０１３７】
ステップ（１３２０）でデータが受信される。ステップ（１３３０）で、受信されたネットワークデータについて緊急フラグの取得を試みる。例えば図１８の緊急状態ネットワークフラグ構造（１７００）内に図示される、緊急フラグＴＣＰオプションの存在を検出する。
【０１３８】
ステップ（１３４０）で、緊急フラグの存在が判定される。評価が肯定であれば（すなわち緊急フラグが発見されれば）、プログラムフローは、ステップ（１３４２）で続き、ここでは、発見された緊急フラグが設定されているのか（“ＯＮ”）または設定されていないのか（“ＯＦＦ”）が評価される。
【０１３９】
ステップ（１３４２）で評価が肯定であれば（すなわちデータ内の緊急フラグが“ＯＮ”であれば）、プログラムフローは、ステップ（１３４４）に続き、ここで緊急状態変数は“Ｙｅｓ”に設定される。
【０１４０】
次のステップ（１２００）で、図１２で説明したように、全てのイネーブルになった通信モジュールのデータへの適用を行うモジュールの適用機能フロー（１２００）がサブフローとして行われる。続いて、プログラムはステップ（１３９０）で終了する。
【０１４１】
ステップ（１３４２）における評価が否定であれば（すなわちデータ内の緊急フラグが“ＯＦＦ”であれば）、プログラムフローは、ステップ（１３４６）で続き、ここで緊急状態変数は“Ｎｏ”に設定される。その後、プログラムフローは、ステップ（１２００）に続く。
【０１４２】
ステップ（１３４０）における評価が否定であれば、プログラムフローは、ステップ（１３４６）で続く。
【０１４３】
図１３のプログラムフローの効果は、別途のテーブルまたは他のデータ構造の管理及び評価を回避しながら、ネットワークデータに基づいて受信されたデータに関する関連緊急状態を評価することである。
【０１４４】
図１４は緊急フラグテーブルアップデートフロー（１４００）の機能に対するプログラムフローを図示する。プログラムフローは、所定の緊急信号が受信される時、例えばエレベータカー内の緊急コールボタンが押されるか、例えば、コールセンターにより“緊急ＯＦＦ”信号が受信される時、送信側の制御ユニット機能ブロック（４３０）により開始される。ステップ（１４２０）で、変数Ｅは緊急フラグテーブル（１６００）の最近エントリーの緊急フラグカラム（１６２０）内の値に設定される（即ち、ＴＥカラム（１６１０）で最も大きいタイムスタンプを有するエントリーが選択され、その緊急フラグ値が変数Ｅに記録される）。次のステップ（１４３０）で、受信された緊急信号が変数Ｓに記録され、緊急信号は“緊急”または“普通”（即ち、非緊急）の値を有し得る。次のステップ（１４４０）で、変数Ｓの値が“緊急”なのか否かが評価される。肯定の場合、プログラムフローは、ステップ（１４４２）で続き、ここで変数Ｅの値が“ＯＮ”なのか否か、即ち、緊急フラグテーブル（１６００）内の最近エントリーの緊急状態が“緊急”（この場合、緊急フラグは“ＯＮ”である）なのか、または緊急状態が“非緊急”（この場合、緊急フラグは“ＯＦＦ”である）なのかが評価される。評価が肯定であれば、プログラムフローは、ステップ（１４９０）で終了する。ステップ（１４４２）における評価が否定であれば、プログラムフローは、ステップ（１４４８）で続き、ここで、緊急状態変数は“Ｙｅｓ”に設定される。次のステップ（１４５０）で、現在のタイムスタンプが変数Ｔに記録され、このタイムスタンプは例えば、所定の物理的または論理的クロックにより受信される現在時間である。次のステップ（１４６０）で、緊急フラグテーブル（１６００）に対する新しいエントリーが生成され（ＴＥカラム（１６１０）に対して用いられる変数Ｔ内の値及び緊急フラグカラム（１６２０）に対する変数緊急状態内の値を有する）、新しいエントリーは緊急フラグテーブル（１６００）に添付される。続いて、プログラムフローは、ステップ（１４９０）で続き、プログラムが終了する。ステップ（１４４０）における評価が否定であれば、プログラムフローは、ステップ（１４４４）で続き、ここでは、ステップ（１４４２）の評価と同様に、変数Ｅの値が“ＯＮ”なのか否かが評価される。評価が肯定であれば、ステップ（１４４６）で続き、ここで緊急状態変数は“Ｎｏ”に設定される。プログラムフローは、ステップ（１４５０）で続く。ステップ（１４４４）における評価が否定であれば、ステップ（１４９０）でプログラムを終了する。図１４のプログラムフローの効果は、図１１のメインフロー（１０００）内の迅速な比較のために緊急フラグテーブル（１６００）内に緊急状態転換または変更（“緊急”から“非緊急”に、または逆に）を登録することである。
【０１４５】
図１５は、送信側の制御ユニット機能ブロック（４３０）及び受信側コールセンター通信機能ブロック（４７０）の両方により用いられるモジュールフラグ適用テーブル（１５００）のスキーマを図示する。
【０１４６】
このテーブルは３つのカラム、即ち、モジュールＩＤカラム（１５１０）、非緊急のための構成カラム（１５２０）及び緊急のための構成カラム（１５３０）を含む。モジュールＩＤカラム（１５１０）は、システム構成に存在するそれぞれのモジュールに対する識別子を含む。
【０１４７】
非緊急のための構成カラム（１５２０）及び緊急のための構成カラム（１５３０）は“適用（apply）”または“通過（pass）”の値を含み、カラム（１５１０）のモジュールＩＤにより指定されたモジュールが適用されるべきか（“適用”）、またはそうでないか（“通過”）を説明する。
【０１４８】
図１５に図示される例は、非緊急送信の場合、まずモジュール“１”が適用され、その後、モジュール“２”が適用され、緊急送信の場合、モジュール“２”のみ適用されるモジュール構成を説明する。モジュールフラグ適用テーブル（１５００）は、システムエンジニアまたは管理部により準備され、その後、不揮発性の補助メモリ（７３０）に保存され得、実際の利用のために初期化の際、主メモリ（７２０）にコピーされ得る。このような準備は制御ユニット（１２０）及びコールセンター（１３０）の両方で適用されなければならない。
【０１４９】
通常、制御ユニット（１２０）のモジュールフラグ適用テーブル（１５００ａ）で、あるモジュールが“適用”である場合には、コールセンター（１３０）のモジュールフラグ適用テーブル（１５００ｂ）でも、そのモジュールは“適用”となる。また、制御ユニット（１２０）のモジュールフラグ適用テーブル（１５００ａ）で、あるモジュールが“通過”である場合には、コールセンター（１３０）のモジュールフラグ適用テーブル（１５００ｂ）でも、そのモジュールは“通過”となる。
【０１５０】
また、通常、コールセンター（１３０）内のモジュールＩＤカラム（１５１０）により参照されたモジュールの順序は、制御ユニット（１２０）内のモジュールＩＤカラム（１５１０）により参照されたモジュールの順序と反対になり、コールセンター側におけるモジュールの適用の順序がエレベータ側における場合と反対になる。例えば、エレベータ側でモジュールの順序が“１”それから“２”であれば、通常は、コールセンター側におけるモジュールの順序は“２”それから“１”である。
【０１５１】
図１５のスキーマの効果は、緊急状態に基づいて、どのモジュールがどの順に適用されるべきかの構成を規定することを可能にすることである。
【０１５２】
図１６は、送信側の制御ユニット機能ブロック（４３０）により用いられる緊急フラグテーブル（１６００）のスキーマを図示する。
【０１５３】
このテーブルは、ＴＥカラム（１６１０）及び緊急フラグカラム（１６２０）を含む。ＴＥカラム（１６１０）は、緊急状態転換のタイムスタンプを含み、緊急フラグカラム（１６２０）は、新しい緊急状態が緊急（“ＯＮ”）なのか（“ＯＦＦ”）なのかを含む。
【０１５４】
本実施例では、緊急フラグテーブル（１６００）の、ＴＥカラム（１６１０）内で最小のタイムスタンプを有するエントリーが初期状態である。図１６の例では、第１エントリーが初期状態であり、そのタイムスタンプは“０．０”であり、緊急フラグ値は“ＯＦＦ”である。
【０１５５】
その後、新しく登録された緊急フラグテーブルエントリーは、さらに小さいタイムスタンプを有さず、時間の経過とともにタイムスタンプの値は増加する。従って、ＴＥカラム（１６１０）の値は昇順となる。
【０１５６】
緊急フラグカラム（１６２０）は、例えば、本例の第１エントリーに図示されるように初期状態では“ＯＦＦ”に設定され、その後“ＯＮ”と“ＯＦＦ”の状態を交代に遷移する。
【０１５７】
緊急フラグテーブルの例が図１６に図示され、ＴＥ値に対する第１エントリーは“０．０”であり、緊急フラグ値は“ＯＦＦ”であり、ＴＥ値に対する第２エントリーは“１４６３１０６１９１．５２３５７７５６”であり、緊急フラグは“ＯＮ”に設定され、ＴＥ値に対する第３エントリーは“１４６３１１４３５１．６３４３８７７４”であり、緊急フラグは“ＯＦＦ”に設定され、ＴＥ値に対する第４エントリーは“１４６５８９４４２７．２６８５５１２４”であり、緊急フラグは“ＯＮ”に設定される。
【０１５８】
図１６のスキーマの効果は、緊急状態のタイムスタンプとセッションの生成タイムスタンプを迅速に比較することができるように、緊急状態転換（それらのそれぞれの発生時間を含む）を管理することである。
【０１５９】
図１７は、送信側の制御ユニット（１２０）内のセッション管理部（４２０）により管理されるセッション管理テーブル（１８００）の一例のスキーマを図示する。
【０１６０】
このテーブルはＴ１カラム（１８１０）及びセッションパラメータカラム（１８２０）を含む。Ｔ１カラム（１８１０）は、セッション生成時間のタイムスタンプを含み、セッションパラメータカラム（１８２０）は、セッションの追加的な情報、例えば、プロトコル、ソースＩＰアドレス、ソースプロトコルポート、受信先ＩＰアドレス及び受信先プロトコルポートを説明する５タプルを含む。
【０１６１】
本実施例で、セッション管理テーブル（１８００）内のエントリーは固有であることが保障される。テーブル“スロット”は、再使用されず、例えば、テーブルの第３エントリーにより指定されたセッションが破棄された後、後から新しい異なるセッションが第３エントリーに記録できる。
【０１６２】
図１７に図示されるセッション管理テーブルの例は、時間“１４６５８９０９５５．８２７３７１５７”に生成され、５タプル“ＴＣＰ：１０．０．０．１：３１１４：１０．０．０．２：５０００”により説明する第１セッション、時間“１４６５８９１３８１．４８８７４９５０”に生成され、５タプル“ＴＣＰ：１０．０．０．１：４１２１：１０．０．０．２：５０００”により説明する第２セッション、時間“１４６５８９４４２８．１４７８２３７４”に生成され、５タプル“ＵＤＰ：１０．０．０．１：４１２１４：１０．０．１０．１：５０６０”により説明する第３セッション、及び時間“１４６５８９５０９３．３４８３７９１９”に生成され、５タプル“ＵＤＰ：１０．０．０．１：４１２１４：１０．０．１０．１：５０６０”により説明する第４セッションを含む。
【０１６３】
図１７のスキーマによって、図１１のタイムスタンプ比較機能フロー（１１００）で行われる、ステップ（１１５０）のセッション生成時間と緊急状態転換時間の比較を可能にするように、セッション生成時間のタイムスタンプＴ１を提供することができる。
【０１６４】
図１８は、送信側の制御ユニット（１２０）が、送信側で送信データに適用された緊急状態を受信側コールセンターに通知することを可能にする、緊急状態ネットワークフラグ構造（１７００）を図示する。当該構成により、受信側では、ネットワークデータコンテンツまたは所定の関連データ構造の管理を考慮せず、同一の緊急状態に対して送信側と同様のモジュール構成の適用を可能にする。
【０１６５】
本実施例で、緊急状態ネットワークフラグ構造（１７００）は、ＴＣＰオプションを用いて緊急フラグを送信している。緊急フラグフィールド（１７３５）はフィールド（１７３７）に図示されるようなブール値を有し、例えば、“１”は緊急状態を示す。図１８のデータ構造の効果は、送信側及び受信側の両方で、関連したモジュールの適用のために緊急状態の同期化を可能にすることである。
【０１６６】
本発明は上記した実施形態に限定されるものではなく、様々な変形例が含まれる。例えば、ある実施例の構成の一部を他の実施例の構成に置き換えることが可能であり、また、ある実施例の構成に他の実施例の構成を加えることが可能である。また、各実施例の構成の一部について、他の実施例の構成の追加・削除・置換をすることが可能である。
【符号の説明】
【０１６７】
１２０：エレベータの制御ユニット
１５０：ＷＡＮ
４１０：緊急入力装置
４２０：セッション管理部
４３０：制御ユニット機能ブロック
４５０：送信及び変換モジュール＃１
４６０ａ：送信及び変換モジュール＃２（構成＃１）
４６０ｂ：送信及び変換モジュール＃２（構成＃２）
５４０：データ
５５０：スイッチ（簡略化した）
１１００：タイムスタンプ比較機能フロー
１２００：モジュールの適用機能フロー
１４００：緊急フラグテーブルアップデートフロー
【図１】
2018042173.tif 000003
【図２】
2018042173.tif 000004
【図３】
2018042173.tif 000005
【図４】
2018042173.tif 000006
【図５】
2018042173.tif 000007
【図６】
2018042173.tif 000008
【図７】
2018042173.tif 000009
【図８】
2018042173.tif 000010
【図９】
2018042173.tif 000011
【図１０】
2018042173.tif 000012
【図１１】
2018042173.tif 000013
【図１２】
2018042173.tif 000014
【図１３】
2018042173.tif 000015
【図１４】
2018042173.tif 000016
【図１５】
2018042173.tif 000017
【図１６】
2018042173.tif 000018
【図１７】
2018042173.tif 000019
【図１８】
2018042173.tif 000020