JP2019516167A - リアルタイムデータフロープログラミング言語のためのツールおよび方法 - Google Patents

Abstract

パターン駆動型リアルタイムデータ解析において用いることができるリアクティブデータフロープログラムは、データフロープログラミング言語を用いて表現することができる。シンタックスおよびセマンティクスにおける正当性の検証、論理的正当性の検証、デバッグ、ソースコードから安全でポータブルなフォーマット（たとえばパッケージングされたコード）への変換、ソースコード（またはパッケージングされたコード）からプラットフォーム固有コードへの変換、バッチモード解釈、インタラクティブ解釈、データフロー環境のシミュレーションおよびビジュアライゼーション、遠隔実行、モニタリング、またはこれらの任意の組合せのための、１つ以上のツールが、データフロープログラミング言語に対して提供される。これらのツールにより、開発、デバッグ、およびデータフローグラフデバイスのデプロイの方法が実現される。

Description

説明
関連出願との相互参照
この特許出願は、２０１６年３月２３日に出願された米国特許出願第６２／３１２，１０６号、第６２／３１２，１８７号、第６２／３１２，２２３号、および第６２／３１２，２５５号の利益を主張し、それらは、本願で引用されたすべての他の引例とともに、引用により援用される。

発明の背景
この発明は、コンピューティングの分野に関し、より具体的には、特に産業機械によって生成された大量のデータを取扱うためにエッジコンピューティングにおいて用いられる、データフロープログラムプログラミング言語のためのツールを備えた開発環境に関する。

従来の企業ソフトウェアアプリケーションホスティングは、規模の経済性およびシステム効率を活用するために、データセンターまたは「クラウド」インフラストラクチャに依拠してきた。しかしながら、これらのデータセンターは、企業がそのビジネス活動のほとんどを行なう物理的活動地点（たとえば工場、倉庫、小売店など）から任意に離れている場合がある。産業用インターネット・オブ・シングス（industrial Internet of things ：ＩＩｏＴ）とは、非常に高頻度でイベントを追跡するセンサを用いた物理的活動の計測に依拠するデバイスまたは使用事例の集合を指す。

多くのセクターにおける産業用機械が、製造、石油およびガス、採鉱、運輸、電力および水、再生可能エネルギー、ヘルスケア、小売、スマートビルディング、スマートシティ、および接続された車両を含むこのインターネット・オブ・シングス（ＩｏＴ）の下に入る。クラウドコンピューティングの成功にもかかわらず、多くの欠点が存在する。そのデータのすべてをクラウドストレージへ送信することは実用的ではない。なぜなら、接続性が常にそこにあるとは限らず、帯域幅が十分ではなく、レイテンシにおける変動が高すぎ、または、帯域幅が存在していたとしても、それは法外なコストがかかるためである。接続性、帯域幅、およびコストが問題ではなかったとしても、リアルタイムの意思決定および予測保守はなく、それは機械への著しい損傷をもたらし得る。

したがって、特に産業機械によって生成された大量のデータを取扱うためにエッジコンピューティングにおいて使用される、データフロープログラムプログラミング言語のためのツールを備えた、改良された開発環境が必要とされている。

発明の簡単な概要
パターン駆動型リアルタイムデータ解析において用いることができるリアクティブデータフロープログラムは、データフロープログラミング言語を用いて表現することができる。シンタックスおよびセマンティクスの正当性の検証、論理的正当性の検証、デバッグ、ソースコードから安全でポータブルなフォーマット（たとえばパッケージングされたコード）への変換、ソースコード（またはパッケージングされたコード）からプラットフォーム固有コードへの変換、バッチモード解釈、インタラクティブ解釈、データフロー環境のシミュレーションおよびビジュアライゼーション、遠隔実行、モニタリング、またはこれらの任意の組合せのための、１つ以上のツールが、データフロープログラミング言語に対して提供される。これらのツールにより、開発、デバッグ、およびデータフローグラフデバイスのデプロイの方法が実現される。

具体的な実現例において、データフロープログラムプログラミング言語のためのツールは、エッジコンピューティングシステムにおいて用いられる。方法は、エッジでのインテリジェンスを可能にする。特徴は、以下を含む。ゲートウェイデバイスまたは組込まれたシステム上でホストされるソフトウェア層においてセンサデータによってトリガすること。ソフトウェア層はローカルエリアネットワークに接続される。サービス、アプリケーション、およびデータ処理エンジンのリポジトリが、ソフトウェア層によってアクセス可能にされる。ソフトウェア層によって利用可能にされた式言語を通して、センサデータを特定条件の発生の意味論的記述と整合させること。式を連続的に実行することによってパターンイベントを自動的に発見すること。アプリケーションおよび解析式をつなぐために、ソフトウェア層によって管理されるネットワーク全体のゲートウェイデバイスおよび組込まれたシステムを越えて、サービスおよびアプリケーションをインテリジェントに構成すること。リソース利用可能性に基づいてアプリケーションおよび解析のレイアウトを最適化すること。ソフトウェア層の健全性を監視すること。未加工のセンサデータまたは式の結果を、ローカル時系列データベースまたはクラウドストレージに格納すること。サービスおよびコンポーネントは、どのゲートウェイ環境でも円滑な動作を保証するために、コンテナ化され得る。

エッジインテリジェンスは、インターネット・オブ・シングス（ＩｏＴ）データのソースでイネーブルにされる。システムは、リアルタイムのエッジ解析およびアプリケーションのために、ＩｏＴデバイスセンサデータへの強化（enrich）されたアクセス（ストリームモードまたはバッチモード、または双方）を提供する。システムは、低メモリフットプリント機械で動作する高性能解析エンジンを通して解析関数および解析式を実行するための高効率で表現的なコンピュータ言語を含む。システムは、さらなる機械学習のために収集データをクラウドへ発行することを可能にする。システムは、エッジアプリを開発するためのソフトウェア開発キットを含む。クラウドベースの管理コンソールが、エッジデプロイメント、構成、アプリケーション、および解析式の管理を可能にする。

エッジインフラストラクチャおよびプラットフォームの特定の一実現化例は、フォグホーン・システムズ・インコーポレイテッド（FogHorn Systems, Inc）（フォグホーン）による。フォグホーンのウェブサイト、www.foghorn-systems.com、出版物（白書、ユーザガイド、指導書、ビデオなどを含む）、ならびに、フォグホーンの技術および製品についての他の出版物が、引用により援用される。

フォグホーンは、産業用および商業用インターネット・オブ・シングス（ＩｏＴ）データのためのエッジインテリジェンスを可能にするためのプラットフォームを提供する。何百億もの産業用および商業用ＩｏＴデバイスによって生成されるデータの量は、インターネット全体を圧倒するのに十分莫大になるであろう。フォグホーンのプラットフォームはＩｏＴデータを、それがまさしく生じるところ、すなわちネットワークのエッジで処理し、解析し、それに応答する。フォグホーンの「インテリジェントエッジ」ソフトウェアプラットホームは、前例がないレベルの自動化、業務効率、コスト削減などを可能にする。

産業用インターネット・オブ・シングス（ＩＩｏＴ）は、センサ、機械類、およびコンピュータといった、相互接続された産業用および商業用デバイスからなる。ＩＩｏＴの目標は、分散された企業全体にわたって、より優れたデバイス制御、データ管理、機械自動化、および業務効率を可能にすることである。会社は、システム全体の管理および最適化のためにクラウドコンピューティングを活用しながら、リアルタイムの解析および自動化応答を使用してグリーンフィールドＩＩｏＴ機会を捕らえるためにエッジでフォグコンピューティングを適用することができる。フォグホーンのエッジコンピューティングプラットフォームはまた、追加のコンピューティングリソースを追加することが実行できない場合に、既存のプログラマブルロジックコントローラ（programmable logic controller：ＰＬＣ）（たとえば、ブラウンフィールド機会）において動作するように設計される。ブラウンフィールドとは、確立されたシステムを勘案しながら情報技術（information technology：ＩＴ）問題領域を解決するための新しいシステムの実現を指す。新しいソフトウェアアーキテクチャは、既存のおよび動作中のソフトウェアを考慮する。

エッジインテリジェンスプラットフォームとは、ＩＩｏＴデバイスが存在するエッジのより近くまでデータ処理および解析を拡張する、フォグコンピューティング概念に基づいたソフトウェアベースのソリューションである。遠くの集中型クラウドへすべてのデータを送信する代わりに、エッジデバイスとの近接性を維持することは、待ち時間を最小化し、最大性能、より速い応答時間、ならびにより効果的な保守および業務戦略を可能にする。それはまた、全体的な帯域幅要件と、広範に分散されたネットワークを管理するコストとを著しく減少させる。

エッジでのＩＩｏＴ操作に焦点を合わせることは、全体的な帯域幅要件を減少させ、時間依存の条件への即時の自動化応答を可能にする。産業界は何十億もの新しいＩＩｏＴデバイスを追加しており、これらのデバイスは集団で、毎日多くのペタバイトのデータを生成する。このデータのすべてをクラウドに送信することは、法外なコストがかかるだけでなく、より大きいセキュリティリスクも生み出す。エッジで動作することは、はるかにより速い応答時間、リスクの減少、および全体的コストの低下を保証する。

２０１５年８月２７日に出願された米国特許出願第６２／２１０，９８１号、および２０１６年８月２９日に出願された米国特許出願第１５／２５０，７２０号は、ここに引用により援用され、エッジコンピューティング環境およびプラットフォームを記載する。２０１７年３月２３日に出願された米国特許出願第１５／４６７，３０６号は、ここに引用により援用され、リアルタイムデータフロープログラミングのための効率的な状態機械を記載する。２０１７年３月２３日に出願された米国特許出願第１５／４６７，３１３号は、ここに引用により援用され、リアルタイムデータフロープログラミングにおけるパターン駆動型反応の構成を記載する。

ある実装例において、データフロープログラミング言語のための開発環境により、少なくとも１つのマッチャー（matcher）・ステートマシンを指定することができる。このステートマシンは、受信した入力ストリームにおけるパターンマッチングを実行して出力データを生成することができる。この開発環境は複数のツールを含み、これら複数のツールは、潜在的なデータストリームを識別すること、上記ストリームにおけるデータのパターンに対応するリアクティブ関数とパラメータとのセットを識別すること、宣言されたパターンにマッチするデータを変換するための処理関数とパラメータとのセットを識別すること、または、データフローのパターンの比較対象である時限イベントのセットを識別すること、またはこれらの任意の組合せを、実行するためのツールである。

別の実装例において、データフロープログラミング開発プラットフォームのためのシステムは、コンピュータの画面に表示されるグラフィカルユーザインターフェイスを備える。宣言画面において、ユーザは宣言データタイプを指定することができる。宣言データタイプを表すブロックが上記画面に表示されて、ユーザが上記ブロックを上記画面上の所望の位置にドラッグ・アンド・ドロップできるようにする。リアクション画面において、ユーザは、宣言データタイプのブロックを、データフロープログラムのグラフィカル表現に相互接続することができる。計算ブロック画面において、ユーザは、計算ブロックによって実行される演算を見て指定することができる。コード閲覧画面において、ユーザは、開発プラットフォームによって自動的に生成されたコンピュータコード表現を見て編集することにより、データフロープログラムを実現することができる。ユーザは、開発プラットフォームインターフェイスに対し、ユーザが指定したデータフロープログラムのデータフロープログラムパッケージ表現をコンパイルするよう要求することができる。

もう１つの実装例において、データフロープログラムを開発する方法は、グラフィカルユーザインターフェイスを用いてデータフロープログラムのグラフィカル表現を指定することを含む。ユーザは、ブロックを用いて表された作成タイプ、変換タイプ、および抽出タイプを選択してコンピュータ画面上のさまざまな位置に移動させることができる。ユーザは、相互接続リンクを介してブロックを相互接続することができる。ユーザは、各ブロックの詳細を指定することができる。開発プラットフォームは、ユーザがグラフィカルに指定したデータフロープログラムに対応するコンピュータソースコードを自動的に生成する。ユーザは、テキストまたはエディタインターフェイスにおいて自動的に生成されたコンピュータソースコードを見て編集することができる。ユーザは、ターゲットハードウェアプラットフォーム上で実行可能なデータフロープログラムのためのコンピュータパッケージコードを生成するようプラットフォームに指示することができる。

本発明の他の目的、特徴、および利点は、以下の詳細な説明および添付図面を考慮すれば明らかになるであろう。図面では、図全体を通し、同じ参照記号は同じ特徴を表わす。

クライアント−サーバシステムおよびネットワークのブロック図である。 クライアントまたはサーバのより詳細な図である。 コンピュータシステムのシステムブロック図である。 センサストリームとクラウドとの間にあるエッジコンピューティングプラットフォームのブロック図である。 エッジ解析を含むエッジコンピューティングプラットフォームのより詳細なブロック図である。 エッジインフラストラクチャとクラウドインフラストラクチャとの間の動作フローを示す図である。 決定性有限オートマトン（ＤＦＡ）に変換された拡張非決定性有限オートマトン（ＮＦＡ）および状態縮小機械（state-reduced machine）を示す。 トークンアルファの受信で状態ＡからＢへの遷移を示す。 別途の状態遷移、状態Ｘを経た、状態Ａから状態Ｂへの遷移を示す。 構文解析によって形成された抽象構文木の例を示す。 離接のための部分グラフを示す。 合接のための部分グラフを示す。 構造を有する閉包（closure）を示す。 論理的正当性の検証およびテストの画面を示す。 コマンドデバッガの画面を示す。 ロードディレクティブの画面を示す。 ステータス・マニフェストディレクティブの画面を示す。 現在開いていないバルブの画面を示す。 デッドラインディレクティブの画面を示す。 開こうとするバルブの画面を示す。 ｇｏディレクティブの画面を示す。 データフローの状態および形状を示す。 データフローの状態および形状を示す。 データフロープログラミング用のビジュアライゼーションスタジオ開発環境のパターン駆動型フロー・リアクティブ概念のブロック図を示す。 上記開発環境の宣言ページの画面を示す。 ビジュアライゼーションスタジオのリアクションページの画面を示す。 ユーザがブロックを画面上の位置にドラッグ・アンド・ドロップしてデータフロープログラムを構成する宣言ページの別の画面を示す。 リアクションページにおいてデータフロープログラムを指定する画面を示す。 ユーザが修正できる計算ブロックの詳細または内部の画面を示す。 計算ブロックの詳細の画面を注釈とともに示す。 開発プラットフォームによって自動的に生成されたコンピュータソースコードとともにコードパネルを示す画面を示す。

図１は、本発明の一実施形態を取入れる分散型コンピュータネットワーク１００の簡略ブロック図である。コンピュータネットワーク１００は、複数の通信リンク１２８を介して通信ネットワーク１２４に結合された、複数のクライアントシステム１１３、１１６、および１１９と、サーバシステム１２２とを含む。通信ネットワーク１２４は、分散型ネットワーク１００のさまざまなコンポーネントが互いに通信して情報を交換することを可能にするためのメカニズムを提供する。

通信ネットワーク１２４はそれ自体、多くの相互接続されたコンピュータシステムおよび通信リンクで構成されてもよい。通信リンク１２８は、配線リンク、光リンク、衛星または他の無線通信リンク、波動伝搬リンク、もしくは、情報の通信のための他のメカニズムであってもよい。通信リンク１２８は、ＤＳＬ、ケーブル、イーサネット（登録商標）または他の配線リンク、受動または能動光リンク、３Ｇ、３．５Ｇ、４Ｇおよび他のモビリティ、衛星または他の無線通信リンク、波動伝搬リンク、もしくは、情報の通信のための任意の他のメカニズムであってもよい。

図１に示すさまざまなシステム間の通信を容易にするために、さまざまな通信プロトコルが使用されてもよい。これらの通信プロトコルは、ＶＬＡＮ、ＭＰＬＳ、ＴＣＰ／ＩＰ、トンネリング、ＨＴＴＰプロトコル、無線アプリケーションプロトコル（wireless application protocol：ＷＡＰ）、ベンダー固有プロトコル、カスタマイズされたプロトコルなどを含んでいてもよい。一実施形態では、通信ネットワーク１２４はインターネットであり、他の実施形態では、通信ネットワーク１２４は、ローカルエリアネットワーク（local area network：ＬＡＮ）、ワイドエリアネットワーク（wide area network：ＷＡＮ）、無線ネットワーク、イントラネット、私的ネットワーク、公的ネットワーク、スイッチドネットワーク、およびこれらの組合せなどを含む、任意の好適な通信ネットワークであってもよい。

図１の分散型コンピュータネットワーク１００は、本発明を取入れる実施形態の単なる例示であり、請求項に記載されるようなこの発明の範囲を限定しない。当業者であれば、他の変形、変更、および代替物を認識するであろう。たとえば、２つ以上のサーバシステム１２２が通信ネットワーク１２４に接続されてもよい。別の例として、複数のクライアントシステム１１３、１１６、および１１９は、アクセスプロバイダ（図示せず）を介して、または何らかの他のサーバシステムを介して、通信ネットワーク１２４に結合されてもよい。

クライアントシステム１１３、１１６、および１１９は典型的には、情報を提供するサーバシステムから情報を要求する。この理由により、サーバシステムは典型的には、クライアントシステムよりも多いコンピューティングおよびストレージ容量を有する。しかしながら、特定のコンピュータシステムは、そのコンピュータシステムが情報を要求しているか、または提供しているかに依存して、クライアントまたはサーバとして、双方として機能してもよい。加えて、この発明の局面はクライアント−サーバ環境を使用して説明されてきたが、この発明はスタンドアロンコンピュータシステムにおいても具現化され得ることが明らかであるはずである。

サーバ１２２は、クライアントシステム１１３、１１６、および１１９から情報要求を受信し、要求を満たすために必要とされる処理を行ない、要求に対応する結果を要求元クライアントシステムへ送り返す役割を担う。要求を満たすために必要とされる処理は、サーバシステム１２２によって行なわれてもよく、またはそれに代えて、通信ネットワーク１２４に接続された他のサーバに委任されてもよい。

クライアントシステム１１３、１１６、および１１９は、ユーザが、サーバシステム１２２によって格納された情報にアクセスし、情報をクエリすることを可能にする。特定の一実施形態では、クライアントシステムは、デスクトップアプリケーション、もしくはモバイルスマートフォンまたはタブレットアプリケーションなどのスタンドアロンアプリケーションとして動作可能である。別の実施形態では、クライアントシステム上で実行される「ウェブブラウザ」アプリケーションが、ユーザが、サーバシステム１２２によって格納された情報を選択し、情報にアクセスし、情報を検索し、またはクエリすることを可能にする。ウェブブラウザの例は、マイクロソフト社（Microsoft Corporation）によって提供されるインターネットエクスプローラ（Internet Explorer）ブラウザプログラム、モジラ（Mozilla）によって提供されるファイアーフォックス（Firefox（登録商標）)ブラウザ、グーグル（Google（登録商標））によって提供されるクローム（Chrome）ブラウザ、アップル（Apple）によって提供されるサファリ（Safari）ブラウザなどを含む。

クライアント−サーバ環境では、いくつかのリソース（たとえばファイル、音楽、ビデオ、またはデータ）はクライアントで格納され、一方、他のリソースは、サーバなどネットワークにおけるどこか他のところに格納されるかまたはそこから配信され、ネットワーク（たとえばインターネット）を介してアクセス可能である。したがって、ユーザのデータは、ネットワークまたは「クラウド」に格納され得る。たとえば、ユーザは、クラウド（たとえばサーバ）上にリモートに格納されている、クライアントデバイス上の文書に対して作業することができる。クライアントデバイス上のデータは、クラウドと同期され得る。

図２は、本発明の例示的なクライアントまたはサーバシステムを示す。一実施形態では、ユーザは、図２に示すようなコンピュータワークステーションシステムを通して、システムとインターフェイス接続する。図２は、モニタ２０３と、スクリーン２０５と、筐体２０７（システムユニット、キャビネット、またはケースとも呼ばれてもよい）と、キーボードまたは他の人間入力デバイス２０９と、マウスまたは他のポインティングデバイス２１１とを含む、コンピュータシステム２０１を示す。マウス２１１は、マウスボタン２１３などの１つ以上のボタンを有していてもよい。

本発明は、特定のフォームファクタ（たとえば、デスクトップコンピュータのフォームファクタ）のどのコンピューティングデバイスにも限定されず、さまざまなフォームファクタのあらゆるタイプのコンピューティングデバイスを含み得る、ということが理解されるべきである。ユーザは、スマートフォン、パーソナルコンピュータ、ラップトップ、電子タブレットデバイス、全地球測位システム（global positioning system：ＧＰＳ）受信機、ポータブルメディアプレイヤー、携帯情報端末（personal digital assistant：ＰＤＡ）、他のネットワークアクセスデバイス、および、データを送受信できる他の処理デバイスを含む、任意のコンピューティングデバイスとインターフェイス接続することができる。

たとえば、特定の一実現化例では、クライアントデバイスは、アップルｉＰｈｏｎｅ（登録商標）（たとえば、アップルｉＰｈｏｎｅ６）、アップルｉＰａｄ（登録商標）（たとえば、アップルｉＰａｄ、またはアップルｉＰａｄ ｍｉｎｉ）、アップルｉＰｏｄ（登録商標）（たとえば、アップルｉＰｏｄ Ｔｏｕｃｈ）、サムスン（Samsung）ギャラクシー（Galaxy）製品（たとえば、ギャラクシーＳシリーズ製品、またはギャラクシーノート（Galaxy Note）シリーズ製品）、グーグル（登録商標）ネクサス（Nexus）デバイス（たとえば、グーグルネクサス６、グーグルネクサス７、またはグーグルネクサス９）、およびマイクロソフトデバイス（たとえば、マイクロソフトサーフェス（Surface）タブレット）といった、スマートフォンまたはタブレットデバイスであり得る。典型的には、スマートフォンは、電話部分（および関連付けられた無線機）とコンピュータ部分とを含み、それらはタッチスクリーンディスプレイを介してアクセス可能である。

電話部分のデータ（たとえば、連絡先および電話番号）と、コンピュータ部分のデータ（たとえば、ブラウザを含むアプリケーションプログラム、画像、ゲーム、ビデオ、および音楽）とを格納するための不揮発性メモリがある。スマートフォンは典型的には、写真およびビデオを撮るためのカメラ（たとえば、前向きのカメラまたは後部カメラ、もしくは両方）を含む。たとえば、スマートフォンまたはタブレットは、１つ以上の他のデバイスにストリーミングされ得るライブビデオを撮るために使用され得る。

筐体２０７は、プロセッサ、メモリ、大容量ストレージデバイス２１７などといった、よく知られたコンピュータコンポーネント（それらのうちのいくつかは図示されず）を収容する。大容量ストレージデバイス２１７は、大容量ディスクドライブ、フロッピー（登録商標）ディスク、磁気ディスク、光ディスク、光磁気ディスク、固定ディスク、ハードディスク、ＣＤ−ＲＯＭ、書込可能ＣＤ、ＤＶＤ、書込可能ＤＶＤ（たとえば、ＤＶＤ−Ｒ、ＤＶＤ＋Ｒ、ＤＶＤ−ＲＷ、ＤＶＤ＋ＲＷ、ＨＤ−ＤＶＤ、またはブルーレイ（登録商標）ディスク）、フラッシュおよび他の不揮発性ソリッドステートストレージ（たとえば、ＵＳＢフラッシュドライブまたはソリッドステートドライブ（solid state drive：ＳＳＤ））、バッテリによってバックアップされた揮発性メモリ、テープストレージ、リーダー、および他の同様の媒体、ならびにこれらの組合せを含んでいてもよい。

この発明の、コンピュータにより実現される、またはコンピュータにより実行可能なバージョン、もしくはコンピュータプログラム製品が、コンピュータ読取可能媒体を使用して具現化され、コンピュータ読取可能媒体上に格納され、またはコンピュータ読取可能媒体に関連付けられてもよい。コンピュータ読取可能媒体は、命令を実行のために１つ以上のプロセッサに提供することに関与する任意の媒体を含んでいてもよい。そのような媒体は、不揮発性媒体、揮発性媒体、および伝送媒体を含むものの、それらに限定されない多くの形を取ってもよい。不揮発性媒体は、たとえば、フラッシュメモリ、もしくは、光学ディスクまたは磁気ディスクを含む。揮発性媒体は、キャッシュメモリまたはＲＡＭなどのスタティックメモリまたはダイナミックメモリを含む。伝送媒体は、同軸ケーブル、銅線、光ファイバー線、およびバスに配置されたワイヤを含む。伝送媒体はまた、無線波および赤外線データ通信中に生成されるような電磁波、無線周波、音響波、または光波の形を取り得る。

たとえば、本発明のソフトウェアの、機械により実行可能なバイナリバージョンが、ＲＡＭまたはキャッシュメモリ内に、もしくは大容量ストレージデバイス２１７上に格納されてもよく、または存在してもよい。本発明のソフトウェアのソースコードも、大容量ストレージデバイス２１７（たとえば、ハードディスク、磁気ディスク、テープ、またはＣＤ−ＲＯＭ）上に格納されてもよく、または存在してもよい。さらに別の例として、この発明のコードは、ワイヤ、無線波を介して、または、インターネットなどのネットワークを通して伝送されてもよい。

図３は、本発明のソフトウェアを実行するために使用されるコンピュータシステム２０１のシステムブロック図を示す。図２と同様に、コンピュータシステム２０１は、モニタ２０３と、キーボード２０９と、大容量ストレージデバイス２１７とを含む。コンピュータシステム５０１はさらに、中央プロセッサ３０２、システムメモリ３０４、入力／出力（Ｉ／Ｏ）コントローラ３０６、ディスプレイアダプタ３０８、シリアルまたはユニバーサルシリアルバス（universal serial bus：ＵＳＢ）ポート３１２、ネットワークインターフェイス３１８、およびスピーカ３２０といったサブシステムを含む。この発明はまた、追加の、またはより少ないサブシステムを有するコンピュータシステムで使用されてもよい。たとえば、あるコンピュータシステムは２つ以上のプロセッサ３０２を含んでいてもよく（すなわち、マルチプロセッサシステム）、または、あるシステムはキャッシュメモリを含んでいてもよい。

３２２などの矢印は、コンピュータシステム２０１のシステムバスアーキテクチャを表わす。しかしながら、これらの矢印は、サブシステム同士をリンクするよう機能する任意の相互接続スキームの例示である。たとえば、スピーカ３２０は、ポートを通して他のサブシステムに接続されてもよく、または、中央プロセッサ３０２への内部直接接続を有していてもよい。プロセッサは、複数のプロセッサまたはマルチコアプロセッサを含んでいてもよく、それは、情報の並列処理を許可してもよい。図２に示すコンピュータシステム２０１は、本発明での使用にとって好適なコンピュータシステムの単なる一例である。本発明での使用にとって好適なサブシステムの他の構成は、当業者には容易に明らかになるであろう。

コンピュータソフトウェア製品は、Ｃ、Ｃ＋＋、Ｃ＃、パスカル（Pascal）、フォートラン（Fortran）、パール（Perl）、（マスワークス（MathWorks）、www.mathworks.comからの）マトラボ（Matlab）、ＳＡＳ、ＳＰＳＳ、ＪａｖａＳｃｒｉｐｔ（登録商標）、ＡＪＡＸ、Ｊａｖａ（登録商標）、パイソン（Python）、アーラン（Erlang）、およびルビー・オン・レイルズ（Ruby on Rails）といった、さまざまな好適なプログラミング言語のうちのいずれで書かれてもよい。コンピュータソフトウェア製品は、データ入力モジュールおよびデータ表示モジュールを有する独立したアプリケーションであってもよい。これに代えて、コンピュータソフトウェア製品は、分散オブジェクトとしてインスタンス化され得るクラスであってもよい。コンピュータソフトウェア製品はまた、（オラクル社（Oracle Corporation）からの）Ｊａｖａ Ｂｅａｎｓ、またはエンタープライズＪａｖａ Ｂｅａｎｓ（オラクル社からのＥＪＢ）といったコンポーネントソフトウェアであってもよい。

システム用のオペレーティングシステムは、マイクロソフトウィンドウズ（登録商標）ファミリーのシステム（たとえば、ウィンドウズ（登録商標）９５、９８、Ｍｅ、ウィンドウズＮＴ、ウィンドウズ２０００、ウィンドウズＸＰ、ウィンドウズＸＰ ｘ６４エディション、ウィンドウズビスタ（Vista）、ウィンドウズ７、ウィンドウズ８、ウィンドウズ１０、ウィンドウズＣＥ、ウィンドウズモバイル、ウィンドウズＲＴ）、シンビアン（Symbian）ＯＳ、タイゼン（Tizen）、リナックス（登録商標）、ＨＰ−ＵＸ、ＵＮＩＸ（登録商標）、サン（Sun）ＯＳ、ソラリス（Solaris）、Ｍａｃ ＯＳ Ｘ、アップルｉＯＳ、アンドロイド（登録商標）、アルファ（Alpha）ＯＳ、ＡＩＸ、ＩＲＩＸ３２、またはＩＲＩＸ６４のうちの１つであってもよい。他のオペレーティングシステムが使用されてもよい。マイクロソフトウィンドウズは、マイクロソフト社の商標である。

また、コンピュータはネットワークに接続されてもよく、このネットワークを使用して他のコンピュータにインターフェイス接続されてもよい。ネットワークは、とりわけ、イントラネット、またはインターネットであってもよい。ネットワークは、有線ネットワーク（たとえば、銅を使用）、電話網、パケットネットワーク、光学ネットワーク（たとえば、光ファイバーを使用）、または無線ネットワーク、もしくはこれらの任意の組合せであってもよい。たとえば、データおよび他の情報は、Ｗｉ−Ｆｉ（数例を挙げると、ＩＥＥＥ規格８０２．１１、８０２．１１ａ、８０２．１１ｂ、８０２．１１ｅ、８０２．１１ｇ、８０２．１１ｉ、８０２．１１ｎ、８０２．１１ａｃ、および８０２．１１ａｄ）、近距離無線通信（near field communication：ＮＦＣ）、無線自動識別（radio-frequency identification：ＲＦＩＤ）、モバイルまたはセルラー無線（たとえば、２Ｇ、３Ｇ、４Ｇ、３ＧＰＰ ＬＴＥ、ＷｉＭＡＸ、ＬＴＥ、ＬＴＥアドバンスト、フラッシュＯＦＤＭ、ＨＩＰＥＲＭＡＮ、アイバースト（iBurst）、ＥＤＧＥエボリューション、ＵＭＴＳ、ＵＭＴＳ−ＴＤＤ、１ｘＲＤＤ、およびＥＶ−ＤＯ）といったプロトコルを使用した無線ネットワークを使用して、コンピュータとこの発明のシステムのコンポーネント（またはステップ）との間で渡されてもよい。たとえば、あるコンピュータからの信号が、コンポーネントまたは他のコンピュータへ、少なくとも部分的に無線で転送されてもよい。

ウェブブラウザがコンピュータワークステーションシステム上で実行される一実施形態では、ユーザは、インターネットなどのネットワークを通して、ワールド・ワイド・ウェブ（World Wide Web：ＷＷＷ）上のシステムにアクセスする。ウェブブラウザは、ＨＴＭＬ、ＸＭＬ、テキスト、ＰＤＦ、およびポストスクリプトを含むさまざまなフォーマットのウェブページまたは他のコンテンツをダウンロードするために使用されており、システムの他の部分へ情報をアップロードするために使用されてもよい。ウェブブラウザは、ウェブ上のリソースを識別するためにユニフォーム・リソース・アイデンティファイヤ（uniform resource identifier：ＵＲＬ）を使用してもよく、ウェブ上のファイルを転送する際にハイパーテキスト転送プロトコル（ＨＴＴＰ）を使用してもよい。

他の実現化例では、ユーザは、ネイティブアプリケーションおよび非ネイティブアプリケーションのいずれかまたは双方を通して、システムにアクセスする。ネイティブアプリケーションは、特定のコンピューティングシステム上にローカルにインストールされ、そのコンピューティングシステムのオペレーティングシステムまたは１つ以上のハードウェアデバイス、もしくはこれらの組合せに固有である。これらのアプリケーション（「アプリ」と呼ばれる場合もある）は、直接インターネットアップグレードパッチングメカニズムを介して、またはアプリケーションストア（たとえば、アップルｉＴｕｎｅｓおよびＡｐｐ ｓｔｏｒｅ、グーグルプレイ（Google Play）ストア、ウィンドウズフォン（Windows Phone）ストア、およびブラックベリー（登録商標）Ａｐｐ Ｗｏｒｌｄストア）を通して、（たとえば周期的に）アップデートされ得る。

システムは、プラットフォームから独立した非ネイティブアプリケーションで動作可能である。たとえば、クライアントは、１つ以上のサーバから、当該サーバとのネットワーク接続を使用して、ウェブアプリケーションを通してシステムにアクセスし、当該ウェブアプリケーションをウェブブラウザにロードすることができる。たとえば、ウェブアプリケーションは、ウェブブラウザによって、アプリケーションサーバからインターネットを通してダウンロードされ得る。非ネイティブアプリケーションも、ディスクなどの他のソースから得られ得る。

図４は、典型的にはセンサ４０９とクラウド４１２との間にあるエッジゲートウェイまたは同等物上で動作するエッジコンピューティングプラットフォーム４０６のブロック図を示す。エッジコンピューティングプラットフォームは、産業用機械および他の産業用インターネット・オブ・シングスを管理し最適化するために重要であるエッジインテリジェンスを導き出すことを可能にする。エッジゲートウェイのコンポーネントは、取込み４２１と、強化４２５と、複合イベント処理（complex event processing：ＣＥＰ）エンジン４２９と、適用４３２と、式言語を通した解析４３５と、移送４３８とを含む。クラウドは、エッジプロビジョニングおよびオーケストレーション４４３と、クラウドおよびエッジ解析ならびにアプリポータビリティ４４６とを含み得る。

上述のように、エッジコンピューティングプラットフォームの特定の一実現化例は、フォグホーンからのものである。フォグホーンは、「エッジインテリジェンス」という急速に台頭してきているドメインにおけるリーダーである。制御システムおよび物理センサのより近くで高性能処理、解析、および異種アプリケーションをホストすることにより、フォグホーンの画期的なソリューションは、閉ループデバイス最適化のためのエッジインテリジェンスを可能にする。これは、製造、石油およびガス、電力および水、運輸、採鉱、再生可能エネルギー、スマートシティなどにおける法人顧客のために、ビッグデータおよび現場でのリアルタイム処理をもたらす。フォグホーンの技術は、世界の有力な産業用インターネットイノベータ、ならびに、クラウドコンピューティング、高性能エッジゲートウェイ、およびＩｏＴシステムインテグレーションにおける主要事業者によって採用されている。

フォグホーンは、ストリームモードおよびバッチモード双方でのエッジアプリのための強化されたＩｏＴデバイスおよびセンサデータアクセス；解析関数を実行するための非常に効率的で表現的なＤＳＬ；低フットプリント機械上で動作可能である強力な小型解析エンジン；さらなる機械学習のために収集されたデータをクラウドへ送信するための発行機能；エッジアプリを開発するためのＳＤＫ（多言語）；構成のエッジデプロイメント、アプリ、および解析式を管理するための管理コンソールを提供する。

フォグホーンは、産業用機械からのセンサデータのリアルタイムの現場ストリーム処理を可能にする、効率的で非常にスケーラブルなエッジ解析プラットフォームを提供する。フォグホーンのソフトウェアスタックは、エッジおよびクラウド上で動作するサービスの組合せである。

「エッジ」ソリューションは、未処理のデータをオフライン解析のためにクラウド環境へ発行するオプションを用いて、ローカルストレージリポジトリへのセンサデータの取込みをサポートしてもよい。しかしながら、多くの産業環境および産業デバイスはインターネット接続性がなく、このデータを使用できなくしている。しかし、インターネット接続性があったとしても、生成されるデータの純然たる量は、利用可能な帯域幅を容易に上回るであろう。または、あまりに法外なコストがかかるためにクラウドに送信できないであろう。加えて、データがクラウドにアップロードされ、データセンターで処理され、結果がエッジに送り返される時までに、行動を取るには遅すぎるかもしれない。

フォグホーンのソリューションは、解析エンジンとしても公知である超小型の複合イベント処理（ＣＥＰ）エンジンと、多くの着信センサストリームのデータに関する規則を表現する強力で表現的なドメイン固有言語（domain specific language：ＤＳＬ）とを提供することによって、この問題に対処する。これらの表現からの出力は次に、高くつく機械故障またはダウンタイムを防止するために、ならびに、リアルタイムの産業活動およびプロセスの効率および安全性を高めるために、直ちに使用され得る。

フォグホーンのプラットフォームは、低フットプリント環境および高スループットまたはゲートウェイ環境で動作する能力；着信ストリーミングセンサデータに作用できる非常にスケーラブルで高性能のＣＥＰエンジン；強化されたデータアクセスを用いた異種アプリの開発およびエッジへのデプロイメント；クラウドおよびエッジを越えるアプリケーションモビリティ；進んだ機械学習（machine learning：ＭＬ）およびクラウドとエッジとの間のモデル転送を含む。独創的に、フォグホーンは、主な産業用データ取込みプロトコル（たとえば、ＯＰＣ−ＵＡ、モドバス（Modbus）、ＭＱＴＴ、ＤＤＳなど）、および他のデータ転送プロトコルをサポートする。加えて、ユーザは、カスタムプロトコルアダプタを、フォグホーンのデータ取込み層へ容易にプラグインすることができる。

フォグホーンのエッジサービスは、ＩＩｏＴデバイスが存在するネットワークのエッジで動作する。エッジソフトウェアスタックは、センサおよび産業用デバイスからのデータを高速データバス上へ取込み、次にユーザ定義の解析式をストリーミングデータに対して実行して、洞察を得てデバイスを最適化する役割を担う。これらの解析式は、フォグホーンの非常にスケーラブルで小フットプリントの複合イベント処理（ＣＥＰ）エンジンによって実行される。

フォグホーンのエッジサービスはまた、時間ベースのセンサデータクエリについてのローカル時系列データベースと、ストリームモードおよびバッチモード双方でデータを消費できるアプリケーションを開発するための多言語ＳＤＫとを含む。オプションで、このデータはまた、顧客が選んだクラウド格納先へ発行され得る。

フォグホーンのプラットフォームはまた、エッジをリモートに構成し管理するためにクラウド環境または構内環境で動作するサービスを含む。フォグホーンのクラウドサービスは、解析式を開発およびデプロイメントし、ドッカー（Docker）（www.docker.com）として公知であるアプリケーションを使用してアプリケーションをエッジへデプロイメントし、顧客のアイデンティティアクセス管理および持続性ソリューションとのサービスの統合を管理するための管理ＵＩを含む。プラットフォームはまた、クラウドで開発された機械学習モデルを、エッジで実行され得るセンサ式へ変換することもできるであろう。

例として、あるアプリケーションは、キャビテーションイベントによるポンプへの高くつく損傷を防止するために、リアルタイムデータ監視および解析、予測保守スケジューリング、ならびに自動化された流れの方向転換を適用する。別の例は、発電を最大化し、機器の寿命を延ばし、正確なエネルギー予測のために履歴解析を適用するためにフォグホーンエッジインテリジェンスソフトウェアを使用した、風力エネルギー管理システムである。

図５は、エッジコンピューティングプラットフォームのより詳細なブロック図を示す。このプラットフォームは、データ取込み５１２、データ処理５１５、およびデータ発行５１８という３つの論理層または区分を有する。データ取込みコンポーネントは、データを生成するセンサまたはデバイス５２３に接続されるエージェント５２０を含む。エージェントは、それぞれのプロトコルサーバからの１つ以上のプロトコルを介して、センサからデータを集め、または取込む。エージェントは、とりわけ、ＭＱＴＴ、ＯＰＣ ＵＡ、モドバス、およびＤＤＳといったプロトコル用のクライアントまたはブローカーであり得る。センサによって提供または出力されるデータは典型的には、バイナリデータストリームである。センサからエージェントへのこのデータの伝送または配信は、プッシュ法またはプル法によるものであり得る。

プッシュは、所与のトランザクションに対する要求が送信側（たとえばセンサ）によって開始される通信のスタイルを記述する。プル（またはゲット）は、情報の伝送に対する要求が受信側（たとえばエージェント）によって開始される通信のスタイルを記述する。別の通信手法は、受信側またはエージェントが、センサが送信するべきデータを持っているか周期的に問合せるかまたはチェックする、ポーリングである。

ＭＱＴＴ（以前はＭＱテレメトリトランスポート（Telemetry Transport））とは、ＴＣＰ／ＩＰプロトコルに加えて使用するための、ＩＳＯ規格の発行−サブスクライブベースの「軽量」メッセージ通信プロトコルである。代替的なプロトコルは、アドバンストメッセージキューイングプロトコル、ＩＥＴＦ制約アプリケーションプロトコル、ＸＭＰＰ、およびウェブアプリケーションメッセージングプロトコル（Web Application Messaging Protocol：ＷＡＭＰ）を含む。

ＯＰＣ統一アーキテクチャ（OPC Unified Architecture：ＯＰＣ ＵＡ）とは、ＯＰＣ協議会（OPC Foundation）によって開発された、相互運用性のための産業用Ｍ２Ｍ通信プロトコルである。それは、オープンプラットフォーム通信（Open Platform Communications：ＯＰＣ）の後継版である。

モドバスとは、元々１９７９年にモディコン（Modicon）（現在のシュナイダーエレクトリック（Schneider Electric））によってそのプログラマブルロジックコントローラ（ＰＬＣ）とともに使用するために発行された、シリアル通信プロトコルである。単純かつ頑強であるため、それはそれ以降、すべての意図および目的のために標準通信プロトコルとなった。それは現在、産業用電子デバイスを接続する、一般に利用可能な手段である。

データ処理５１５はデータバス５３２を含み、それは、データ取込み層のエージェント５２０に接続される。データバスは、すべての接続されたコンポーネント間のデータおよび制御メッセージ双方のための中央バックボーンである。コンポーネントは、データバスを通って流れるデータおよび制御メッセージをサブスクライブする。解析エンジン５３５は、１つのそのような重要なコンポーネントである。解析エンジンは、式言語５３８で開発された解析式に基づいて、センサデータの解析を行なう。データバスに接続する他のコンポーネントは、構成サービス５４１と、メトリックサービス５４４と、エッジマネージャ５４７とを含む。データバスはまた、未加工のバイナリデータを消費可能なデータフォーマット（ＪＳＯＮなど）へ復号するとともに、必要で有用な追加のメタデータで装飾することによって、センサからの着信データを強化する「デコーダサービス」を含む。また、強化は、データ復号、メタデータ装飾、データ正規化などを含み得るが、それらに限定されない。

ＪＳＯＮ（ＪａｖａＳｃｒｉｐｔオブジェクト表記法とも呼ばれる）とは、属性値ペアからなるデータオブジェクトを伝送するために人間が読めるテキストを使用する、オープンスタンダードフォーマットである。ＪＳＯＮは、非同期ブラウザまたはサーバ通信（ＡＪＡＪ）または双方のために使用される共通データフォーマットである。ＪＳＯＮの代替例はＸＭＬであり、それはＡＪＡＸによって使用される。

エッジマネージャはクラウド４１２に、特にクラウドマネージャ５５２に接続する。クラウドマネージャは、同様にクラウドにある、顧客アイデンティティおよびアクセス管理（identity and access management：ＩＡＭ）用プロキシ５５５とユーザインターフェイスコンソール５５８とに接続される。また、クラウドを介してアクセス可能なアプリ５６１もある。アイデンティティおよびアクセス管理とは、正しい個人が正しい時間に正しい理由で正しいリソースにアクセスすることを可能にする、セキュリティおよびビジネス規律である。

データ処理５１５内では、ソフトウェア開発キット（software development kit：ＳＤＫ）５６４コンポーネントもデータバスに接続し、それは、エッジゲートウェイ上にデプロイメントされ得る、機能するアプリケーション５６７の作成を可能にする。ソフトウェア開発キットはまた、データを取出すためにローカル時系列データベースに接続する。アプリケーションは、ドッカーなどのコンテナ技術を使用することなどによってコンテナ化され得る。

ドッカーコンテナは、１つのソフトウェアを完全なファイルシステムで包み、ファイルシステムは、コード、ランタイム、システムツール、およびシステムライブラリといった、それが動作するために必要なものすべてを含み、サーバにインストールされ得るものを何でも含む。これは、ソフトウェアが、それが動作している環境にかかわらず、常に同じように動作することを保証する。

データ発行５１８は、クラウド内の格納位置５７３に接続されるデータパブリッシャ５７０を含む。また、ソフトウェア開発キット５６４のアプリケーション５６７は、時系列データベース５７６内のデータにアクセスできる。時系列データベース（time-series database：ＴＳＤＢ）とは、時系列データ、時間によって索引付けされた数の配列（たとえば、日付−時刻、または日付−時間範囲）を取扱うために最適化されたソフトウェアシステムである。時系列データベースは典型的には、新しい情報がデータベースに追加されると最も古い情報が除去される、回転または循環バッファまたはキューである。データパブリッシャ５７０もデータバスに接続し、ローカル時系列データベースに、またはクラウドストレージに格納される必要があるデータをサブスクライブする。

図６は、エッジインフラストラクチャ６０２とクラウドインフラストラクチャとの間の動作フローを示す。いくつかの特定のエッジインフラストラクチャは上に説明された。センサ６０６からデータが集められる。これらのセンサは、産業用デバイス、小売デバイス、ヘルスケアデバイス、または医療デバイス、もしくは、電力または通信用途、もしくは、これらの任意の組合せのためのものであり得る。

エッジインフラストラクチャはソフトウェアプラットホーム６０９を含み、それは、データ処理６１２と、ローカル時系列データベース６１５と、クラウドシンク６１８と、解析複合イベント処理エンジン（ＣＥＰ）６２１と、解析リアルタイムストリーミングドメイン固有言語（ＤＳＬ）６２４（たとえば、フォグホーンによるＶｅｌ言語）と、リアルタイムアグリゲーションおよびアクセス６２７とを有する。プラットフォームは、以下により詳細に説明される仮想センサ６３０を含み得る。仮想センサは、強化されたリアルタイムデータアクセスを提供する。

プラットフォームは、ソフトウェア開発キットまたはＳＤＫを使用して開発され得る、アプリまたはアプリケーション１、２および３などの１つ以上のアプリケーション６３３を介してアクセス可能である。アプリは（たとえば、複数の異なる言語で開発された）異種であってもよく、複合イベント処理エンジン６２１を活用するとともに、機械学習を行なうことができる。アプリは、アプリストア６３７を使用して配布可能であり、アプリストア６３７は、エッジプラットフォーム開発者またはエッジプラットフォームの顧客（パートナーと呼ばれてもよい）によって提供されてもよい。アプリストアを通して、ユーザは、アプリをダウンロードし、他人と共有することができる。アプリは、機械学習、遠隔監視、予測保守、または動作インテリジェンス、またはこれらの任意の組合せを含む、解析および適用６３９を行なうことができる。

アプリについては、エッジとクラウドとの間に動的アプリモビリティがある。たとえば、フォグホーンのソフトウェア開発キットを使用して開発されたアプリケーションは、エッジ上に、またはクラウド内にデプロイメント可能であり、それにより、エッジとクラウドとの間にアプリモビリティを達成する。アプリは、エッジの一部として、またはクラウドの一部として使用され得る。一実現化例では、この特徴はアプリがコンテナ化されることによって可能になり、そのため、アプリは、それらが実行されるプラットフォームから独立して動作可能である。同じことが解析式についても言える。

クラウドまたは私的データセンター６４４でのデータの監視または格納を含む、統合運営および管理６４０を可能にするデータアプリがある。

物理センサは電子変換器であり、それは、その環境のいくつかの特性をアナログまたはデジタル測定値として測定する。アナログ測定値は典型的には、アナログ／デジタル変換器を使用してデジタル量に変換される。センサデータは、必要ベースで測定（ポーリング）されるか、または、一定速度のストリームとして利用可能である。典型的なセンサ仕様は、範囲、精度、解像度、ずれ、安定性、および他の属性である。多くの測定システムおよびアプリケーションは、処理、移送、または格納のためにセンサデータを直接利用し、または通信する。

システムは、解析式言語を使用して作成されたソフトウェアベースのセンサである、仮想センサとも呼ばれる「プログラマブルソフトウェア定義センサ」を有する。一実現化例では、解析式言語は、フォグホーンの解析式言語である。この式言語はＶｅｌとして公知である。Ｖｅｌ言語は、実行の待ち時間が少ない制約された低フットプリント環境においてリアルタイムストリーミング解析をサポートするために効率的に実現される。たとえば、システムの待ち時間は約１０ミリ秒以下であり得る。

一実現化例では、プログラマブルソフトウェア定義センサは、「センサ式言語」（sensor expression language）またはＳＸＬと呼ばれる宣言型アプリケーションプログラムインターフェイス（ＡＰＩ）を用いて作成される。ＳＸＬ言語の特定の一実現化例は、フォグホーンからのＶｅｌである。Ｖｅｌセンサは、この構成を通して作成されたＶｅｌセンサであり、物理センサおよびＶｅｌセンサを含む複数のソースによって生成されたデータを処理することから導き出された測定値を提供する。本願では、ＶｅｌおよびＳＸＬは交換可能に使用される。

Ｖｅｌセンサは、これら３つのソースのうちのいずれか１つまたはそれらの組合せから導き出され得る。

１．単一のセンサデータ。
１．１．単一の物理センサから導き出される仮想センサまたはＶｅｌセンサは、任意の組合せの動的較正、信号処理、数式、データ圧縮またはデータ解析を使用して、着信センサデータを変換し得る。

２．複数の物理センサデータ。
２．１．複数の異種物理センサから（上述の方法を使用して）変換として導き出された仮想センサまたはＶｅｌセンサ。

３．Ｖｅｌセンサ装置の実現にとって利用可能にされた、物理センサデータと仮想センサデータとの組合せ。

Ｖｅｌセンサはドメイン固有であり、特定のアプリケーションを念頭に置いて作成される。Ｖｅｌプログラミングインターフェイスの特定の一実現化例は、アプリケーションが、変換（たとえば数式）およびアグリゲーションを通してデータ解析を定義することを可能にする。Ｖｅｌは、典型的にはプログラミング言語に基づいた１組の数学演算子を含む。Ｖｅｌセンサは、Ｖｅｌ構成またはプログラムを実行することによって、ランタイムにデータに作用する。

Ｖｅｌセンサの作成：Ｖｅｌセンサは、データをリアルタイムで利用可能にするためのソフトウェア装置として設計される。これは、アプリケーションによって必要とされるレートでＶｅｌセンサデータを生成するために、Ｖｅｌで開発されたアプリケーションが、組込まれたコンピュートハードウェアに対してリアルタイムで実行されることを必要とする。これを達成するために、システムは高効率の実行エンジンを含む。

Ｖｅｌセンサの利点は、以下を含む。
１．プログラム可能性：Ｖｅｌは、Ｖｅｌセンサをプログラマブルにして、データを合成し、データ品質、頻度および情報についての特定のアプリケーション要件に整合させる。Ｖｅｌセンサは、物理センサおよび他の（たとえば、前から存在する）Ｖｅｌセンサから供給されたデータにプラグインするための無線ソフトウェアアップグレードとして広く分散され得る。このため、アプリケーション開発者は、物理インフラストラクチャのレイアウトから独立したビジネスロジックの効率的実行の助けとなるデジタルインフラストラクチャを作成することができる。

２．保守性または透明性：Ｖｅｌセンサは、アプリケーションと物理センサとの間にデジタル抽象化層を作成し、それは、物理センサへのアップグレードおよびサービスによる物理インフラストラクチャの変化から開発者を隔離する。

３．効率：Ｖｅｌセンサは、物理センサからの未加工データをそれらに含まれる情報の正確な表現へ変換することによって、情報管理における効率を生み出す。この効率は、アプリケーションにおける下流での計算、ネットワーキング、および格納のようなＩＴリソースの効率的な利用につながる。

４．リアルタイムデータ：Ｖｅｌセンサは、実在または物理センサデータストリームから計算されるリアルタイムセンサデータを提供する。これは、データを最小の時間遅延でアプリケーションにとって利用可能にする。

実現化例：システムは、Ｖｅｌインターフェイスに基づいて、Ｖｅｌセンサのスケーラブルでリアルタイムの実現化例を設計した。Ｖｅｌは、Ｊａｖａ言語によってサポートされる演算子を含み、物理センサおよびそれらのプロトコルと良好に統合される。

システムは、実行される物理センサのデータに対する演算を正確に表現するための新規の方法をもたらす。この宣言型の式は、デジタル抽象化の定義を、物理センサに対する実現から隔てる。

さまざまな型のデータのストリームのセットと、それらのストリームにおけるデータの特定のパターンに反応しそれら特定のパターンを処理することを意図した関数のセットとが与えられると、本発明は、データがストリームで到着するとこれらの関数が適切かつ効率的に呼び出され得るようにこれらの関数を記述および変換する技術である。

この種の問題を解決する必要性は、すべての形式のデータフロープログラミングで共通して発生する。これは、エンタープライズデータセンター内およびエンタープライズデータセンター間のデータフローなどの非常に大規模なアーキテクチャ、ならびに埋込まれたデバイスにおけるイベントのフローなどの非常に小規模なアーキテクチャに適用可能である。

本発明は、データフロープログラミングのすべての領域に適用可能であるが、一致を検出でき、ハンドラ関数を適用できる速度が最も重要であり、実行に費やすストレージおよび計算リソースが限られている場合に最適である。

実施例。所与の整数のストリームから、１つ以上の非零値に１つ以上の零が続くものをマッチングしたい。このパターンがマッチすると、非零値の和を計算し、その結果を別のストリームに書き込みたい。

この問題のパターンマッチング部分を正規表現の表記法で書き、和の計算を別途算術式として書くことができる。それが起こると、エッジコンピューティングにおいてデータフローアプリケーションで使用するために設計されたＶｅｌプログラミング言語を使用することにより、変換全体を統一された表記法で書くことができる。

この技術は、上記の関数のパラメータ化を状態機械に変換するであろう。次に、それは、一致をその状態機械に基づいて決定性有限オートマトンとして実現し、結果の一致を合計式に供給するであろう。このフローを図７に示す。これは、状態０ ７０５、状態１ ７１０、「リストａから」ブロック７１５、および「和（ａ）をプッシュする」ブロック７２０である。

この問題は、各ハンドラ関数ごとにマッチング関数を生成することで解決できる。マッチング関数は、ストリームからデータのウィンドウを入力として受け入れ、一致の場合は真を返し、不一致の場合は偽を返す。データがウィンドウを通って流れると、一致が見つかるまで、マッチング関数を繰り返し適用する必要がある。一致が見つかると、ハンドラ関数が適用される。

この解決策は、ハンドラ関数がデータベースクエリに対して使用されるのと同様の方法で指定されるため、生ずる。ＳＱＬのようなＷＨＥＲＥ節は、一致のための条件を記述するブール式を与え、マッチング関数はこの式の直接的コンパイルである。

別々のマッチング関数は、新たなデータがストリームバッファに流入するときに個別に評価されなければならない。一致は各関数ごとに独立して判断される。

状態機械を使用して一致を実行する方が、複数の任意のブール式を繰り返し適用するよりも、効率的である。

本発明は、関数のパラメータを宣言するパターン記述言語から状態機械を導出する。導出された状態機械は、データストリーム内において、一致を、従来のブール式マッチング関数よりも、より効率的に検出する。

導出された状態機械はまた、データストリームにおいて検出された一致のためにハンドラ関数のセットを実装してもよい。複数のマッチング関数および対応するハンドラ関数を組み合わせて、どのハンドラ関数に対しても効率的に一致を認識する単一の状態機械に縮小してもよい。

導出された状態機械はまた、状態機械によって認識されるシーケンスを変更することなく、追加のノードを介する自由（イプシロン）遷移を含むように拡張されてもよい。

このような追加のノードを介して遷移することにより、データ上でさまざまなアクションをトリガしてもよい。たとえば、決定性有限オートマトン（ＤＦＡ）またはスタックマシンのシフトバッファにおけるデータの、保持領域への収集をトリガすることができる。これらのデータは、後で関数適用に対する引数の基礎を形成してもよい。

この出願ではＤＦＡという用語を使用しているが、これらのオートマトンまたはユニットはスタックマシンと称されてもよい。厳密に言えば、決定性有限オートマトンは、空間における有限の性能を意味する。しかしながら、この特許のオートマトンは、必ずしも有限であるとは限らず、非有限であり得るが、依然として単純であり得る。したがって、この特許に記載されているＤＦＡは、非有限であってもよい。

このような追加のノードを介して遷移することにより、以前のノードで取込まれたデータを関数適用引数として使用して、ハンドラ関数の呼び出しをトリガすることもできる。

正規表現および値式の局面を組み合わせたスクリプトからの変換により、パターンのマッチングおよび値の計算を効率的に行い得る拡張された状態機械またはＤＦＡが生まれる。

結果として生じる組み合わされたマッチングまたは計算アルゴリズムは、パターンマッチングおよび値計算の別個の編成よりも効率的である。

語彙ソースからＤＦＡまたは状態機械を構築する方法は、非決定性有限オートマトン（ＮＦＡ）で始まり、次いでそれを最小のＤＦＡに縮小する。ＤＦＡの目的は、一連の入力データ内でパターンを認識することである。この議論のため、状態機械を通って流れるデータをトークンと呼び、ＤＦＡによって認識される特定のパターンをトークンの言語と呼ぶ。

図８のＮＦＡの部分を考える。この部分は偶然ＤＦＡでもあるが、この例では重要ではない。それは、トークンアルファの受信で、状態Ａ８０５から状態Ｂ８１０に遷移する。

図９に示すように、イプシロン遷移９２０を有する追加のノードを追加することによって、このＮＦＡを拡張することができる。イプシロンエッジは、入力の状態にかかわらず、いつでも‐あたかも自由に‐辿られることができる。

１つ以上のイプシロンエッジが存在すると、状態機械は非決定性になるが、しかし、イプシロンエッジはアルゴリズムによって除去されてもよく、ＮＦＡはこの手段によって同等のＤＦＡに縮小され、表駆動法によって効率的に実施されることができる。したがって、効率的な実装の戦略を依然として維持しながら、これらの別途のイプシロン遷移を導入することができる。

図９の状態機械は、トークンアルファ９２５の受信で状態Ａ９０５から状態Ｘ９１５に遷移し、それから随意に状態Ｘから状態Ｂ９１０に進むことができる。アルファの刺激は、図８におけるより単純な機械と同様に、依然として状態Ａから状態Ｂへの遷移をもたらす結果となり、この遷移を達成するために追加の入力は必要ない。したがって、図９のＮＦＡは、図８と同じ言語を変換することが分かる。そうするためには、単に、状態Ｘを通る別途の状態遷移が必要である。

別途の状態は、副作用のパフォーマンスをそれに関連付けるために役立つ。これらの副作用が状態機械の定義も状態機械を流れるデータも変更しない限り、追加のノードは言語の認識に影響を与えないが、副作用は追加作業を行い得る。

データフロー反応実現例では、追加作業には、データに対する任意の数の有用なアクション、またはそのデータを使用することを含めることができる。例示的な一実現例では、作業は以下を含む。

１．ノードを流れるデータを検査し、それのコピーを外部コレクタに発する。
２．データがノードを通過する際にデータに変換を適用し、変換されたデータを一時バッファに収集する。または、
３．収集したデータを一時バッファから追加の変換にフラッシュし、その結果を別のＤＦＡまたはスタックマシンにプッシュする。

例として、ソースフラグメントを考える：

フラグメントは、２つの項からなるパターンを記述する。（１）ａと呼ばれる第１項。非零値の１回以上の繰り返しとマッチする。（２）名前が与えられていない第２項。１つ以上の零の繰り返しとマッチする。

これを反応の基礎として使用したいと考える。呼び入れられたソースから値を読み、入力の中でフラグメントのパターンを認識すると、フラグメントの右辺を評価し、呼び出された宛先に結果をプッシュすることで、反応する。

たとえば、値[101, 202, 303, 0, 0]からなる場合、最初の３つの値をａに、最後の２つの値を匿名の第２項にバインドすることで、パターンをマッチングするであろう。次に、ａにバインドされた値[101, 202, 303]のリストに合計関数を適用することによって、右辺を評価し、６０６を返すであろう。次いで６０６をプッシュアウトするであろう。

本発明によるこの例のような関数パターンの変換は、コンピュータ実行の変換プログラムを介して実施することができる。プログラムは、２つの異なる形式の変換：関数指向部分“sum(a)”を、計算を実行するであろう実行可能文のブロックに変換すること、およびパターン指向部分“a:{!= 0} .. {>0}, :0 .. {>0}”を、パターンを認識し、引数を取込み、関数を呼び出すであろうＤＦＡまたはスタックマシンに変換すること、を実行しなくてはならないだろう。前者をタスク関数変換と呼び、後者をタスクパターン変換と呼ぼう。

関数変換は、コンパイラおよびインタープリタの書込みを専門とするコンピュータプログラマーによってよく理解されている。パターン変換、関数変換とパターン変換とのフィッティング、ならびにその後のパターン認識および関数ディスパッチの自動化は、本発明の主題である。

関数変換は、ソーステキストを受け入れ、テキストをトークンに分割し、その後、文法によって導かれて、ソーステキストの構文的内容を記述する抽象構文木（ＡＳＴ）の葉を形成するようにトークンを配置することからなる。次に、抽象構文木は、ソースによって記述される関数を評価するために必要な命令のブロックを最終的に生成する一連のアルゴリズムによって走査される。

パターン変換は、上述の構文解析によって形成された抽象構文木から始まる。抽象構文木には、パターン宣言のルートを形成する１つ以上のノードが含まれる。たとえば、上記の我々のパターンは、図１０の左下に示すように、２つの子を有する単一のルートノードで構成され、各子はパターンの１つの項を記述するかもしれない。図１０において、反応ルートノード１００５、パターンルートノード１０１０、和(a)ノード１０１５、ノード１０２０、および<no name>（名前無し）ノード１０が存在する。

マッチングする例およびそれをマッチングする繰り返しを認識するように指定するパターン項ノードが、正規表現における項と同じ情報を担持することを認識する。さらに、子ノードのシーケンスは、まとめて順に、正規表現の項の線形連言（linear conjunction）と同じ情報を特定する。正規表現または正規表現の項の線形連言は、ＮＦＡへの変換項とすることができる。我々は、本発明において同じアルゴリズムが使用され得、パターン項は正規表現の項の代わりとなることを発見した。

基本的なＮＦＡがそのように形成されたら、それに、別途の、副作用誘導状態を、アクションがパターン項によって必要とされる位置において注入し、受容状態の後、反応の関数を呼び出すことができる。

この例を続けると、項ａは、それにマッチする値のリストを収集し、最終的にそれらを引数として反応の関数に渡し得ることを必要とする。したがって、図９に示す変換を項ａの結果であるＮＦＡ状態に適用し、新たな状態を使用して、マッチングする項を収集する作業を行なう。次いで、変換を、再び、今度はＮＦＡの受容状態に適用し、収集された値を使用して反応の関数を呼び出し、結果を反応のコンシューマにプッシュし、収集バッファをクリアする。この強化されたＮＦＡがＤＦＡに変換され、状態が縮小された後、図７に示すマシンが残る。

ステップは、状態機械エンジンを駆動するよう状態アクション表を用いるためのアルゴリズムのように、ＮＦＡをＤＦＡに変換し、ＤＦＡを状態縮小し、ＤＦＡを状態アクション表として表現するために使用される。

本発明の技術によって生成されたＮＦＡは、変換されて表に表現されることができる。ただし、結果の表には、各状態を通過するときに実行される副作用ラムダからなる別途の列が含まれる。このような状態アクションラムダ表を使用する自動化エンジンは、他の技術とは異なり、遷移するたびに追加のラムダを実行する。

データフローコンピューティング環境で使用するためのリアクティブ関数を記述し変換する方法であって、（ｉ）リアクティブ関数を識別することと、（ｉｉ）関数への入力を提供するパラメータのパターンを識別することと、（ｉｉｉ）関数に渡された引数に基づいて評価されるべき式を識別することと、（ｉｖ）パラメータのパターンを、パターンにマッチする入力のシーケンスを認識することができる状態機械に変換することと、（ｖ）状態機械を、入力データを収集および変換してそれを関数に対する引数として使用する準備をする作業を行なう追加の状態で拡張することと、（ｖｉ）状態機械を、単純なソフトウェアまたはハードウェアによる自動化が可能な状態アクション効果表に縮小することとを備える。

関数のセット、および引数として値のシーケンスを与えられると、本発明は、引数がマッチする関数に実行をディスパッチするか、または引数がいずれの関数ともマッチしないと判断する、方法である。この方法は、値式、型式、および正規表現を組み合わせることによって、それが、型システムで表現可能な値のシーケンスを曖昧さなしにマッチングできるという点において新規である。

この種の問題を解決する必要があるのは、トランスレータ、インタープリタ、コンパイラの開発においてであり、多相的ディスパッチの概念と密接に関係している。シーケンスの任意の接頭辞を構成する要素が単一のオブジェクト（タプル）を構成すると考えるならば、正しい関数にディスパッチするタスクは、タプルのクラスのメソッドの多相的ディスパッチと等価であると考えることができる。

本発明は、この種の多相的ディスパッチが必要とされるあらゆる状況に適用可能である。これには、プログラムの外部から発生したデータのストリームに応答する必要があるイベント駆動型またはリアクティブ型プログラムのすべての態様が含まれる。本発明は、エッジもしくはフォグコンピューティング環境またはネットワーク接続環境で頻繁に発生するような、複数のデータストリームのリアルタイム処理に関する適用例において特に有用である。

正規表現は、通常、特定のパターンに適合する文字列を検出するために使用される。最も密接に関連する多くの正規表現言語、およびそれらに基づいた効率的なマッチングエンジンを実装する多くのツールがある。これらは、一般に、文字のシーケンスのマッチングに限定される。

文字列以外のドメインで動作する他のパターンベースの表記法がある。ＸＭＬ文書においてパターンを記述するＸＰＡＴＨがその一例である。これらの表記法は、通常、正規表現よりも完全性が低く、パワフルではないことが多く、特定のドメインに合わせて調整されている。

いくつかのプログラミング言語は、型ベースのパターンマッチングシステムを用いてランタイム多相的ディスパッチを実行する。関数の複数のオーバーロードが定義され、それらの各々は異なるパターンの型および値をとり、引数の型および値を関数パラメータのパターンと照合することによって、ディスパッチが実行時に解決される。Haskellはそのようなプログラミング言語の１つである。

言語仕様言語は、文脈自由文法を一連の生成規則として記述する。これらの規則は言語の構文を構成する。コンパイラコンパイラは、これらの規則を、言語のインスタンスを認識できる表駆動型決定性有限状態機械に変換する。Bisonは、そのような言語仕様言語およびそれの関連するコンパイラコンパイラの例である。

正規表現などの文法駆動型パターンマッチングシステムは、決定性有限オートマトン（ＤＦＡ）や状態機械などの単純な機械として表現できるため、効率的実行の利点があるが、それらには、完全な型システムの幅広いモデリング機能はない。Haskellで使用されているような型駆動型パターンマッチングシステムは、はるかにより豊富なモデリング機能を備えているが、合理的に効率的な実装を優先して表現できるものをしばしば犠牲にし、それでも依然として、ＤＦＡに基づく高速マッチングシステムほど効率的ではない。

本発明は、型に基づくマッチングシステムを扱い、それは、その型の中で表現可能なすべての状態と照合することができながら、依然として状態機械として効率的に実施され得る。型と状態との一般化されたパターンは、パターンのインスタンスを効率的に認識する表駆動型状態機械に変換される。

これらのパターンに基づいて関数パラメータを定義することにより、関数はまさにどのような恣意的なデータパターンともマッチングし、マッチングにおいて、マッチングするデータ要素間からその引数をバインドすることができる。メンバー関数の状態機械をマージし、その結果を最小の状態数に縮小することによって、関数の合併（union）のためのマッチングパターンを記述する状態機械が形成される。オーバーロード間の曖昧さ回避、または全体的な不一致の検出は、シーケンス内で可能な限り早く起こり、関数適用の解決をスピードアップする。また、シーケンス内でできるだけ遅くまで一致を遅らせて、可能な限り多くの入力を受け入れる関数の「貪欲」バージョンを生成することもできる。

あるメソッドは、値式、型式、および正規表現を組み合わせて、それが、型システムで表現可能な任意の値のシーケンスと曖昧さなくマッチングし得るようにする。このメソッドは関数適用を解決し、最小限の判断数で正しいオーバーロードにディスパッチする。このメソッドにより、オーバーロードされた関数適用は、文脈自由文法と同じ作業を実行し、文法的な下位構成要素を帰納的に認識して変換関数をそれに適用することによって特定の言語を認識することができる。

このメソッドは、複数の異なる型を含む型システムに関連して適用可能であり、たとえば、（１）整数、実数、および文字列などの基本的な単相型の集合（set）。（２）多相型の集合およびそれらのコンストラクタ、特に、我々が間もなく論ずるある特定のプロパティを持つ多相集合型。（３）sum型。（４）レコードの形式のproduct型。（５）パターンの形式のproduct型。タプルの、それのフィールドの繰り返しを含むことへの一般化である。（６）ラムダ型。パターン型を任意の型にマッピングする。（７）ラムダのリストからなる多ラムダ型。

集合は、１つ以上の要素の範囲からなる多相型である。集合型は、それが含む要素の型上においてパラメータ化され、たとえば、整数の集合は文字列の集合とは異なる型である。集合型は、その内容の制限によってさらに特徴づけられる。特に、集合型は、有限もしくは無限であるよう、またはその左辺もしくは右辺において閉じられているかもしくは開いているよう、またはこれらの任意の組合せであるように、制約されてもよい。以下の整数の集合の例を考えてみよう。

[>= 1]と[> 0]との間に区別はなく、なぜならば、要素は整数型であり、整数は相異なって可算であるからである。要素が、仮に、実数や文字列のように、非可算型である場合、明示的な包含または特定の端点の包含が必要となる。たとえば、集合[>= “cat”]は、文字列“cat”、および辞書編集上“cat”の後に分類するすべての文字列で構成されている。

集合のインスタンスを型として使用してもよい。そのような型のインスタンスは、集合の要素でなければならない。たとえば、型として使用される集合[> 0]は、正の整数だけを値として許可するであろう。実際、すべての型をこのように考えることができる。たとえば、単相の整数型は、すべての整数の集合からなる集合型と考えることができる。

我々のsum型は、他の型の単純な合併（union）である。たとえば、型int（整数）または型string（文字列）は、その２つの構成要素型の和である。sum型の構成要素型のいずれかの何れのインスタンスも、sum型のインスタンスである。これにより、たとえば、各々が整数または文字列のいずれかである値のリストである型リスト（intまたはstring）を記述することができる。unionのunionは平坦（flatten）になり、型式（intもしくはstring）または（intもしくはreal（実数））はintまたはrealまたはstringに等しくなる。unionにおける型の順序は重要ではないが、正規性のため、すべてのunion型をここにおいてそれらの構成要素がアルファベット順であるように提示する。

我々のレコード型は名前付きフィールドを使用し、各フィールドを型に関連付ける。たとえば、{birthday: date; first_name: string; last_name: string}（{誕生日: 日付; 名: 文字列; 姓: 文字列}）レコード型は常に有限数のフィールドを有し、各フィールドは型内において一意の名前を有する。フィールドの順序は重要ではない。{x: int; y: int}は{y: int; x: int}と同じであるが、unionに対してしたように、我々はレコード型を、それらの構成要素がアルファベット順にある状態で提示する。

レコードの型はそれ自体がレコードであることに注意されたい。値{x: 3; y: 4}は型{x: int; y: int}を有する。

我々のパターン型は、型のシーケンスとして定義されている点で、タプルに似ている；しかしながら、タプルは暗示的にその要素の各々が正確に１回現れると仮定しているが、パターンはそれの各要素が繰り返しを有することを許す。この繰り返しは整数の集合として与えられる。たとえば、パターン<a: int # [1 .. 3]; b: string # [1 .. 3]>は１つから３つの整数の後に１つから３つの文字列が続くものとマッチする。

ラムダのパラメータとして使用すると、パターンのフィールドはラムダの評価内でバインドされる引数を生じさせる。たとえば、前の段落で与えられたパターンをマッチングした後、範囲に２つのローカル識別子ａおよびｂを有するであろう。Ａの値は１つから３つの整数のリストになり、ｂの値は１つから３つの文字列のリストになるであろう。

パターンについて１つ以上のフィールドが名前を持たないことも有効である。名前のないフィールドはマッチングされるが、それに対するどのような値も引数としてバインドされない。たとえば、<a: int # [ 1 .. 3 ]; string # [ 1 .. 3] >をマッチングした場合、前のように１つから３つの整数の後に１つから３つの文字列が続くものをマッチングさせ、整数をａというリストとしてバインドするが、文字列はバインドしないであろう。

パターンは無限長であってもよい。たとえば、パターン<a: int # [ 1 .. ]>は１つ以上の整数と上限なしでマッチする。これは有効である。ただし、無限入力ストリームを処理するために使用する場合、無限のパターンを、値の収集をいつ停止すべきか示す時間間隔などの他のトリガとペアにする必要がある。

一般に、パターンは、それがマッチするデータを消費するが、しかしながら、そのデータの部分集合のみを消費することも、またはまったく消費しないことが可能である。パターンには、ピークポイントと呼ばれるアットマークが含まれてもよく、それを越えて、パターンはデータとマッチし、引数をバインドするが、入力ストリームからは消費しない。たとえば、パターン<a: int; b: int; peek; c: int> は３つの整数とマッチし、３つのローカル識別子をバインドするが、入力から２つの整数しか消費しない。

フィールドのないレコードまたはフィールドのないパターンを有することは有効である。これらの２つのケースは、両方ともproduct型を意味するため、互いに有意に区別できない。語彙的には、この概念をボイドというキーワードで指定する。ボイドは一意の値である。それ自身の型でもある。合併で使用される場合、ボイドはintまたはvoidなど、任意選択的な型の表記をもたらし、存在する場合にはintである値を意味するが、まったく存在しないかもしれない。

我々の目的のために、型マッチングは構造的であり、名目上のものではない。型には名前はなく、記述だけがある。同じ記述を有する２つの型は同じ型である。記述が別の型の記述の部分集合である型は、その型の一般化である。たとえば、型{x: int; y: int}および{x: int; y: int; z: int}を考える。２つのフィールド-xおよびy-を有する型は、３つのフィールド-x, yおよびz-を有する型の部分集合であるため、前者は後者の一般化と見なすことができる。これはパターンにも当てはまる。別のものの接頭辞であるパターンもその一般化である。

我々のラムダ型は、入力パターンを出力型にマッピングする。たとえば、<int # [1 .. 3]> → intは、１つから３つの整数をとり、ある整数を返す、ある関数の型である。我々の多ラムダ型は、ラムダ型のリストで構成されている。ラムダの順序はここでは重要である。多ラムダ適用を解決する際、それの構成要素ラムダのうちマッチする最初のラムダにディスパッチすることになる。

このように定義されると、多ラムダをディスパッチするのに必要なパターンマッチングは、決定性有限オートマトン（ＤＦＡ）に縮小され得る。どのようにするかを示すために、比較のための基礎として状態機械の構築方法を使用し、必要に応じてそれを拡張する。ある記述は、まず、非決定性有限オートマトン（ＮＦＡ）を構築すること、および次いでそれをＤＦＡに縮小することを含むが；しかしながら、実際には、これは一般に単一のステップで行なうことができる。

前述したように、この出願ではＤＦＡという用語を使用しているが、これらのオートマトンまたはユニットはスタックマシンと称されてもよい。厳密に言えば、決定性有限オートマトンは、空間における有限の性能を暗示する。しかしながら、この特許のオートマトンは、必ずしも有限であるとは限らず、非有限であり得るが、依然として単純であり得る。したがって、この特許に記載されているＤＦＡは、非有限であってもよい。

第１に、多ラムダの構成要素-個々のラムダパターン-は、離接の要素として考えなければならない。正規表現を変換する場合、構文a|b (a OR B)は離接であり、一致ａ１１０５または一致ｂ１１１０である。我々の例では、a AND bは各々ラムダパターンである。図１１に従って離接のための部分グラフを作成する。

我々は個々のパターンのフィールドをまず合接により表わす。正規表現の変換では、構文ａｂ１２１０は合接であり、一致ａ１２０５の後にｂ１２１５が続く。我々の例では、a AND bはパターンの各フィールドである。図１２に従って、合接のための部分グラフを作成する。

フィールドの反復係数は、従来はa+またはa*またはa{n:m}と書かれた正規表現の閉包と同じである。ここでも、図１３のような構造でこれらの閉包を表現できる。この場合、反復集合の値に基づいて、部分グラフにおけるなんらかの変化が必要になる。たとえば、ノードｉ１３０５からノードｊ１３１０への順方向イプシロン１３１５は、集合が零を含む場合にのみ含まれる。これらの変化は大部分明白であり、ここで説明したのと同じ基本的な考え方に沿って継続する。

中間のＮＦＡが完結した後、それをＤＦＡに縮小し、次いでそのＤＦＡを最小のＤＦＡに達するまで状態縮小する。次に、ＤＦＡを、状態機械の自動化に使用される通常の種類のソフトウェアまたはハードウェアによる自動化に適した状態−アクション表として表現する。この表の受容状態は、多ラムダへのエントリポイントをマーキングし、中間状態は引数をバインドするために使用されるデータの集まりを提供する。

ＤＦＡがそのように自動化され、入力ストリームが提供されると、それは、ストリームからの入力の接頭辞にマッチし、正しいオーバーロードにディスパッチしてそれらを処理し、計算結果を生成する。このプロセスが繰り返されることが許されている場合、結果は、入力ストリームからの一致ごとに１つの、生じた結果のシーケンスである。これは、データストリーム内で検出されたさまざまな型の引数の対応するパターンによってトリガされる多相型関数によって、入力データストリームの効率的なリアルタイム処理を提供する。

値と型識別子との混合を含む複数の種類の関数引数を含むデータストリームに応答して多相型関数の実行をディスパッチする方法であって、（ｉ）実行されるべき多相型関数を識別することを備え、当該多相型関数は、異なる種類の引数のパターンに各々が関連付けられる複数のオーバーロードを有し、前記方法はさらに、（ｉｉ）各オーバーロードについて、オーバーロードの引数パターンをマッチングすることによって、入力ストリームからバインドされる引数値の集合にわたって評価される出力式を識別することと、（ｉｉｉ）各オーバーロードの引数パターンを、入力ストリームにおけるパターンについて一致を効率的に認識するＤＦＡに変換することと、（ｉｖ）個々のオーバーロードのＤＦＡを、全体として多相型関数のための単一のＤＦＡに結合することとを備え、結果として得られる結合されたＤＦＡは、個々のＤＦＡによってマッチングされるであろう任意のパターンをマッチングし、マッチングする入力を処理すべきオーバーロードを選択することができ、前記方法はさらに、（ｖ）結合されたＤＦＡにデータストリームを適用し、ＤＦＡは、次いで、必要に応じてストリームからデータを検査もしくは消費またはその両方を行なって、一致または無一致を判定し、一致の場合には、入力引数値を適切にバインドし、評価されるべき適切な出力式を選択することと、（ｖｉ）出力式の評価をディスパッチし、結果を返すこととを備える。

リアクティブ関数によって生成される異なる型のデータのストリームのセットが与えられると、本発明は、それらのストリームを、それらの出力が、統合された型の単一のストリームに効率的に構成され得るように、表現する技術である。

この種の問題を解決する必要性は、すべての形式のデータフロープログラミングで共通して発生する。これは、エンタープライズデータセンター内およびエンタープライズデータセンター間のデータフローなどの非常に大規模なアーキテクチャ、ならびに埋込まれたデバイスにおけるイベントのフローなどの非常に小規模なアーキテクチャに適用可能である。

本発明は、データフロープログラミングのすべての領域に適用可能であるが、一致を検出でき、ハンドラ関数を適用できる速度が最も重要であり、実行に費やすストレージおよび計算リソースが限られている場合に最適である。

実施例。ｎ個の別個の入力ストリームのセットからなる流入Ai:0<k<nを考える。各ストリームは、型Tiの要素のキューで構成される。各ストリームは、型Ti→Uiのリアクティブ関数fiによって消費および変換されており、型Uiの要素のキューから各々がなる流出のｎ個のストリームBiが存在する。すべてのストリームBiを、Σ Tk→Σ Ukのマージ関数mを用いて、単一のストリームCにマージしたい。

３つのストリームの間で発生するこのようなマージの例をＶｅｌ言語で書いて以下に示す。

ストリームCは、B0、B1およびB2からの値から構成され、それらが生成されるときにインターリーブされる。Bストリームの内容を実現することにポイントがないことに注意されたく、なぜならばそれらはCストリームを構成するためだけに使用されるためである。それらは匿名の一時的な部分式として同じく簡単に表現できるであろう。

本発明は、各変換関数fiを決定性有限オートマトン（ＤＦＡ）に変換し、マージ関数mをこれらのＤＦＡの合併として単一の最小ＤＦＡに変換することを記載する。その結果、中間流Biの内容を実現する必要なく流入Aiを流出Cにマージする最大効率的な手段が得られる。

この技術は、繰り返し適用され、後続の中間流の層を単一のリアクティブ関数に融合させることができる。これは、Ｖｅｌの場合のように、宣言型データフロー言語のインフィックスまたは演算子で表されるマージの概念と整合している。

この問題はブルートフォースによって解決できる。すなわち、マージ関数が中間流の唯一のコンシューマであっても、中間流を実現し、それらを消費することによって達成される。

また、マージ関数では、それの流入および流出が、すべて、同じ型のものであるか、そうでなければ、型のないシステムの場合においては未分類のものであることを必要とすることもよくある。これは、それらの型システムにunion型（sum型とも呼ばれる）がないためである。データフローシステムにおける真のマージの存在は、union型の使用を要求する。

一部のデータフローシステムでは、真のマージを欠き、代わりに複数入力単一出力リアクティブ変換を実施する。これらはそれら自体有用な構成体であるが、真のマージ関数ほど単純でも一般的でもなく、完全に最適化することはできない。

マッチング関数をＤＦＡとして表現することは、ブール型の任意の式として表現するよりも効率的である。各自の駆動流入を伴う複数のマッチング関数のＤＦＡは、単一の流出を伴うマージ関数を表す単一の効率的なＤＦＡを形成するために統合される。ＤＦＡのマージは、できるだけ早くまたはできるだけ遅く結果がマッチングするように行なわれ、結果として２つの異なる潜在的に望ましい挙動が生じる。複数の反応を１つのＤＦＡに構成することにより、最小の機械、つまり、最小数の判断を用いてすべての一致を実行するアルゴリズムが得られる。最小の機械は、小規模なプラットフォーム用の複数の反応の最も好適な実現例である。最小の機械は、マッチング式の複数の別々の評価よりもアルゴリズム上の利点を有するため、他のすべてが等しい場合、より効率的に実行される。

変換ＤＦＡのセットを単一のＤＦＡにマージするには、正規表現で代替（alternation）を考えるように変換ＤＦＡを考慮する必要がある。正規表現を変換する場合、構文a|bは代替であり：一致a OR 一致bである。我々の例では、a AND bは各々変換関数からのＤＦＡである。図１１に従ってそれらの代替のための部分グラフを作成する。

中間の非決定性有限オートマトン（ＮＦＡ）が完結した後、それをＤＦＡに縮小し、次いでそのＤＦＡを最小のＤＦＡに達するまで状態縮小する。次に、ＤＦＡを、状態機械の自動化に使用される通常の種類のソフトウェアまたはハードウェアによる自動化に適した状態−アクション表として表現する。この表の受容状態は、マージされたデータ要素が出力ストリームに放出される点をマーキングする。

ＤＦＡがそのように自動化され、入力ストリームのセットが提供される場合、ＤＦＡは、各入力を、その入力に関連付けられた元の変換関数に従って変換し、すべての結果を１つの出力上でともにインターリーブして与える。

入力データの複数の独立したストリームを出力データの単一のストリームにマージする方法は、（ｉ）複数の潜在的な入力データストリームを識別することと、（ｉｉ）入力ストリームごとに１つ、各入力ストリームにおけるデータ上で実行され、その結果が一緒になるようマージされる、複数の変換関数を識別することと、（ｉｉｉ）入力データ要素を、複数のストリームから同時に受け取り、データ要素を単一の出力ストリームにインターリーブするマージ関数を識別することと、（ｉｖ）各変換関数を、変換を効率的に実行するＤＦＡに変換することと、（ｖ）変換ＤＦＡを、変換を効率的に実行し、その結果を単一のストリームにインターリーブする単一の結合されたＤＦＡにマージすることと、（ｖｉ）結合されたＤＦＡにデータストリームを適用し、ＤＦＡは次いで変換およびマージの作業を実行することと、（ｖｉｉ）マージされた出力を使用のために宛先にディスパッチすることとを備える。

本発明は、Ｖｅｌプログラミング言語でソフトウェアを開発するためのツールおよび関連する方法である。Ｖｅｌは、データフロープログラムの表現に役立つプログラミング言語である。正しいデータフロープログラミングには多くの課題がある。いくつかはすべての形式のコンピュータプログラミングに共通する課題であり、他のいくつかはデータフローパラダイムに特有の課題である。

このツールは、以下を含む、Ｖｅｌプログラミングの多くの分野に対応している：（１）構文的および意味的な正しさをチェックする。（２）論理的な正しさをチェックする。（３）デバッグ支援。（４）ソースコードを安全かつポータブルな形式（つまり、パッケージ化されたコード）に変換する。（５）さまざまなコンピューティングプラットフォーム、特に小規模なプラットフォームに適した、ネイティブで最適なバイナリ形式へのソースコードまたはパッケージ化されたコードの変換。（６）パッケージ化されたコードの記述およびその署名の確認。（７）パッケージ化されたコードのバッチモード解釈。（８）Ｖｅｌソースのインタラクティブな解釈。（９）パッケージ化されたコードまたはネイティブコードを実行するデータフロー環境のシミュレーション。（１０）ライブデータフロー環境におけるバイナリコードの遠隔実行、監視、および制御。

これらは、Ｖｅｌ言語でソフトウェアを開発している誰もが達成する必要があるタスクである。本発明は、Ｖｅｌプログラミングに熟練した者が、正確で有用なソフトウェアを作成することを可能にするために、これらの分野すべてにおいて十分なサポートを提供する。

構文上および意味上の正しさをチェックすることは、多くの形態の自動ソフトウェア変換に共通するタスクである。論理的な正しさをチェックするためのツールは、通常、変換ツール自体には組込まれていない。これらの種類のツールは別々に存在するのが一般的であり、それらがテストしているコードの不完全な洞察をしばしば伴う。

デバッグはソフトウェア開発の共通タスクであるが、ほとんどのデバッグツールは命令型プログラミングに重点を置いている。関数型およびリアクティブプログラミングのデバッグは、命令型デバッグとはまったく異なる課題を提示するため、それほど一般的に対応されない。特に、これらの言語では、「フライト中の」計算を検査するのは困難であり得、なぜならば、それらの値はデバッガ（およびデバッガプログラマー）が覗き得るアドレスを有さないことが多いからである。

複数のネイティブプラットフォームアーキテクチャを対象とする能力は、Ｃなどのシステム言語のコンパイラにはまれではないが、スクリプトレベルの言語では一般的に見られるパワーではない。スクリプト言語は、コンパイルされないか、またはそれらのホストのために部分的にコンパイルされるかまたはジャストインタイムでコンパイルされる（ジットされる(jitted)）傾向があるが、クロスコンパイル（１つのアーキテクチャで実行されるが、別のアーキテクチャに対してコードを生成するコンパイラ）はまれである。小規模なプラットフォーム上で実行するためにスクリプトレベルの言語を具体的にコンパイルすることは非常に珍しいことである。

対話型シェルは、スクリプト言語の共通の機能である。たとえば、Pythonはシェルを実装している。実際の、またはシミュレートされたデータフロー環境に接続されるシェルは、あまり一般的ではない。

コンパイルされたコードの遠隔実行は、一部のオペレーティングシステムの機能であり、オープンソースおよび商用の両方のいくつかのサードパーティツールからも利用可能である。これらは、具体的に小規模なプラットフォームを対象としない傾向があるが、小規模なプラットフォーム用の遠隔実行ツールの例が存在する。これらはデータフロープログラミングに特有のものではなく、遠隔で実行されるべきプログラムを開発するのに使用されるツールに組込まれていない。

Ｖｅｌコードを開発するための単一の統合されたツールは、Ｖｅｌ言語で作業するソフトウェア開発者にとって有用で便利である。このツールは主にＶｅｌ言語を変換するコンパイラであるが、Ｖｅｌプログラミングに関連する他のいくつかの関数のセットも提供する。ツールで論理的な正しさのテストを構文的および意味的な正しさのテストとともに実行すると、開発者はより効率的になり、コードの正確性を高めることができる。論理テストでは、コンパイラによるコードの洞察の恩恵があり、診断メッセージはより完全なものになり得る。対話型シェルにより、開発者はコードをテストして即座の応答を得ることができる。これは開発やデバッグに便利である。シェルはまた、プログラマーがデータフロー環境を視認できるようにする。

小規模なプラットフォームでの使用に適したスタンドアロンのバイナリ実行可能コードを生成することは、さまざまな小型デバイスで複雑な計算を実行することにしばしば依存する、物のインターネット使用事例を可能にする。シミュレートされたデータフロー環境を提供することで、開発者はコードにおけるバグを解消し、論理的な正しさに対するテストと連携して、パッケージが正しく動作していることを実証できる。コンパイルされたパッケージを遠隔で実行する場合、特に遠隔プラットフォームが小さい場合、プログラマーは、自分のプログラム上で迅速に、プログラムをそれのターゲットハードウェア上で１つのコマンドでコンパイルしテストすることを、たとえターゲットプラットフォームが、自分がその上で開発しているものでなくても、反復できる。

言語をそれの語彙的表現からこの中間の記号的表現に変換（フェーズ１コンパイル）し、次いでこの中間表現を計算ハードウェアによって実行され得る形式に変換（フェーズ２コンパイル）するプロセス。

Ｖｅｌフェーズ１変換ツールは、コンパイラに共通する一般的な戦略に従い、具体的には次のとおりである。（１）入力文字列を解析してそれをトークンのシーケンスに分解する。（２）トークンのシーケンスを解析して構文木を形成する。（３）構文木内の記号宣言を識別する。（４）構文木内の記号参照の特定および解決。（５）共通の部分式の削除や定数の折り畳みなどの初期の最適化。（６）型チェック。（７）最適化および記号成熟の追加フェーズ。（８）記号の最終決定および中間表現の放出。

Ｖｅｌフェーズ１トランスレータの際立った特徴の１つは、それが、決定性有限オートマトンまたはＤＦＡを用いて、関数適用に必要なパターンマッチングを実行し、反応をトリガすることである。フェーズ１変換ツールは以下を含む。（１）入力言語を構文木に変換する構文解析器。（２）解析中の言語がＤＳＬまたはマクロ解析器の態様で解析器によって修正され得るように、変換中のプログラムが自己参照を行なうことを可能にする語彙バインドコンポーネント。（３）バインドされた構文木を、データフロー、パターン、反応、関数式、タイマー、および入出力パラメータ化を表す記号に変換する意味解析アルゴリズム。（４）式木を、多かれ少なかれマイクロプロセッサＡＬＵ命令への直接変換に適したスタックに変換する式トランスレータ。（５）反応のパターンおよび式を潜在的に非最小のＤＦＡの中間収集物に変換するためのＤＦＡジェネレータ。（６）ＤＦＡの中間収集物から統合された最小のＤＦＡを作成するためのＤＦＡ結合および縮小アルゴリズム。

フェーズ１変換ツールの出力は以下を含む：（１）変換に関与する各ストリームの論理的アイデンティティ。各々が複数のストリームの中で一意的な参照であり得るようにする。（２）各ストリームにおけるデータにおけるフローの記述。各々、内方向（反応に向かう、すなわち外部ソースへのサブスクリプション）、外方向（反応から離れる、つまり外部の宛先へのパブリケーション）、内方向および外方向の両方（パブリケーション／サブスクリプションのペア）、または内部（他の反応における中間ステップとしてのみ使用されるため、パブリケーションまたはサブスクリプションとして表面化されない）である。（３）各ストリームにおいて流れるデータの型の記述。ストリームに注入またはストリームから抽出されるデータが型の正しさを静的にチェックされるように、都度有限項で記述される。（４）ＤＦＡの状態および遷移を記述する表のセット。（５）反応の間に実行されるべき計算を記述する式スタックのセット。（６）ストリーム入力をＤＦＡ入力にマッピングする表。（７）時限イベント（timed event）をＤＦＡ入力にマッピングする表。（８）ＤＦＡ出力をアクションのペアにマッピングする表。各ペアは、式スタックへの参照およびストリーム出力から構成され、ＤＦＡの出力が所与の式で変換され、次いで所与のストリームにプッシュされることを示す。

Ｖｅｌインタープリタおよびデータフローシミュレータはフェーズ１変換の出力を直接使用する。インタープリタはコードの実行においてハードウェアプラットフォームをエミュレートし、データフローシミュレータはストリーミングデータ環境をエミュレートし、Ｖｅｌストリームに入力を提供し、Ｖｅｌストリームから出力を収集する。これらの２つのタスクを命令解釈およびデータフローエミュレーションと呼ぼう。

命令解釈は、コンパイラおよびインタープリタの作成を専門とするコンピュータプログラマーがよく理解するタスクのカテゴリである。タスクには、実行時変数の状態を格納できる実行コンテキストを構築し、プログラムの命令を一度に１つずつ実行し、実行コンテキストからデータにアクセスし、必要に応じてそれを更新することが含まれる。

Ｖｅｌの場合、実行コンテキストには、変換の過程でデータのストリームを保持するキューのセット、およびＤＦＡで記述された変換を実行する表駆動型の状態機械エンジンも含まれている必要がある。キューは、データの流通チャネルを記述する、Ｖｅｌソースにおける宣言のため、発生する。これらのうちのいくつかは、Ｖｅｌプログラムの外部入力または出力であり、他のいくつかは入力と出力との間の中間状態を記述する純粋な内部チャネルである。

データフローエミュレーションは、ファイルやソケットなどのデータのために外部ソースおよびシンクへのアクセスを提供することと、これらの外部システムと解釈されているＶｅｌプログラムとの間でデータを交換するために必要なプログラミングとからなる。これには、外部ソースからデータを読み出してそれらデータをプログラムの入力を表すキューにプッシュする注入関数と、プログラム出力を表すキューからデータをポップしてそれらデータを外部シンクに書き込む抽出関数とが含まれる。

本発明によるＶｅｌの解釈が正規とは異なるところでは、ＤＦＡが関与するようになる態様である。状態機械エンジンは、キューからデータを読み取り、それらデータを使用してそれらのＤＦＡの状態を前進させる。ＤＦＡ表には、ＤＦＡがそれらの状態を通過するときに実行される副作用の列が含まれる。これらの副作用は、命令解釈を呼び出して計算を実行し、その結果は他のキューにプッシュされ、これが他のＤＦＡをトリガする。

このようにして、本発明による解釈中のＶｅｌプログラムは、最初に、高速かつ小規模な状態機械のセットによって表され、必要なときに一般的な命令解釈にドロップバックするだけである。これにより、命令解釈だけですべて処理される場合よりも、プログラムの実行効率が向上する。

Ｖｅｌフェーズ２変換ツールは、大部分、Ｖｅｌ言語に固有ではなく、実行対象のプラットフォームに固有である。フェーズ２トランスレータのＶｅｌ言語関連コンポーネントは次のとおりである。（１）フェーズ１によって生成された中間表現の初期取入れ。（２）反応性システムを生成するフェーズ２コード生成の全体的編成。（３）データフォーマットの外部エンコードおよびデコード、またはリアルタイムクロックの内部調整を実行するもののような、ランタイムサポートコンポーネントのライブラリの提供。

マルチソース・マルチ宛先データフロー環境におけるデータストリームのリアルタイム処理のためにプログラムを作成するためのツールは、以下を含む。（１）複数の潜在的なデータストリームを識別すること。（２）このストリームにおけるデータのパターンに対応するリアクティブ関数およびパラメータのセットを識別すること。（３）宣言されたパターンにマッチするデータを変換するための処理関数およびパラメータのセットを識別すること。（４）データが収集または破棄される時間の間隔や、データが収集または破棄される前後の特定の時点など、データフローのパターンが比較される時限イベントのセットを識別すること。（５）識別されたストリーム、反応、関数、および時限イベントを記述するデータフロープログラムを作成すること。（６）このプログラムを、Ｖｅｌプログラム文を対応するＤＦＡに変換するためのＤＦＡジェネレータを組込んだフェーズ１変換ツールと、プラットフォーム上での実行のために変換されたＶｅｌ文に対応するプラットフォーム固有のハードウェア命令を生成するためのフェーズ２変換ツールとを備える２フェーズ変換ツールに、入力として与えること。（７）変換ツールの各フェーズの出力を受け取ること。

フェーズ１変換ツールの出力は、以下を含むインタープリタコンポーネントによって使用されてもよい：（１）コードの実行においてハードウェアプラットフォームをエミュレートする命令インタープリタ。（２）ストリーミングデータ環境をエミュレートし、Ｖｅｌストリームに入力を提供し、Ｖｅｌストリームから出力を収集するデータフローシミュレータ。

フェーズ１変換ツールの出力は、以下を含むフェーズ２変換ツールへの入力として使用することができる：（１）命令を、中間表現から、ターゲットハードウェアプラットフォームによる実行に適した形式に変換するハードウェア命令ジェネレータ。（２）データフロー環境におけるリアクティブプログラムとしての使用に適した形式で出力が生成されるよう指示するプログラム編成モジュール。（３）実行に必要なランタイムサポートコンポーネントのライブラリ。フェーズ２変換ツールの出力は、対象とされるハードウェアプラットフォーム上での使用に適した実行可能なプログラムである。

Ｖｅｌコードを開発するための単一の統合ツールは、ＶｅＬ言語で作業を行なうソフトウェア開発者にとって、有用かつ便利である。このツールはホストプラットフォーム上で実行され、ホストプラットフォームは、リナックス（登録商標）オペレーティングシステムを実行するＩｎｔｅｌ（登録商標）ｘ８６アーキテクチャマイクロコンピュータのような標準コンピュータとオペレーティングシステムとで構成される。このツールは他のツールとのやり取りが可能であり、ウェブブラウザまたは統合開発環境（integrated development environment：ＩＤＥ）のようなプラットフォームを簡単にする。プラットフォームがネットワークインターフェイスデバイスを有する場合、このツールは遠隔ホストリソースにアクセスすることも可能である。ホストがインターネットへのアクセスを許可する場合、このツールはインターネットベースのリソースにアクセスすることも可能である。

このツールは、主としてコンパイラであり、Ｖｅｌ言語を変換するが、Ｖｅｌプログラミングに関連する関数の他のいくつかのセットも提供する。それは以下を含む。（１）論理的正当性をテストすることにより、Ｖｅｌプログラムの正しい動作を検証、実証、およびドキュメント化するドライバ。（２）Ｖｅｌプログラム開発において高速のやり取りを容易にし、Ｖｅｌプログラムの動作の実証を支援する、言語解釈のためのインタラクティブシェル。（３）Ｖｅｌプログラムにおける不具合の調査および修正を容易にするインタラクティブプログラムデバッガ。

Ｖｅｌインタラクションシェルおよびデバッガ。デバッグはソフトウェア開発活動においては一般的であり多数のツールが存在するが、これらのツールでは、命令的で段階的な方式でデバッグすることしかできない。依然として、論理フローの意味およびセマンティクスの負担は、このツールを使用する人間が負う。命令型のシェルはさまざまなプログラミング言語にも一般的であるが、この発明の技術は、極めて独特なセマンティックレベルデバッグ機能を提供することによって、多大な改良をもたらす。これにより、Ｖｅｌプログラマーは、ビジネスロジックまたはセマンティックベースのデバッグにまたはこれら両方のみに集中し易くなり、問題解決プロセスを大幅に促進する。

実行中のＶｅｌプログラムのライブデバッグおよび検査またはモニタリング：このツールはまた、ライブ実行中のＶｅｌプログラムのデバッグ／モニタリングが可能であるという概念を改善する。典型的に、実行中のプロセスまたはプログラムまたはこれら両方をモニタリングまたは検査するためには、特別の計器または外部ツールが必要である。産業用ＩｏＴ環境という文脈において、この問題は、所望の結果に対して何十万ものセンサデータポイントの検査が必要な状態において、著しく悪化する。その結果、データフローの管理およびデバッグに関連する問題は、ほとんど手に負えない規模になってしまう。本ツールは、この問題を、データフローのセマンティクスおよびその瞬間に何が起こっているかをインフライトで素早くフェッチするためにいかなるときも外部からクエリすることができる、デフォルト内部自己検査データフローレジームを公開することによって解決する。簡単に述べると、プログラムが予想通りに働かないまたは予想通りにデータを生成しないときは、プログラムに対してクエリし、機能しなかった原因を尋ねれば、それが答えを教えてくれるであろう。リアルタイムストリーミングデータ解析の場合、これは著しい改善である。なぜなら、データに対して多くのプログラムデバッグをインフライトで瞬時に実行する必要があるからである。

例。このセクションでは、実行中のツールの単純な具体例を提供する。先ず、ある具体的なユースケースとそのためのＶｅｌプログラムから始める。次に、このツールを用いて上記機能を実証する。バルブに対するセンサ入力ストリーム（input stream）について考える。このバルブは、条件の変更に伴って開閉する。バルブが開いたときのセンサの表示は「true」であり、バルブが閉じたときのセンサの表示は「false」である。

input_streamは、その中に２つのフィールドがある記録である。

目的は、バルブがいつ開いたかを正確に検出し「true」をoutput_streamに送ることである。よって、センサの表示については、falseの後にtrueを検出したことになる。これに関連する重要なパターンマッチングストリーム処理の特徴は、ＴＦＲ（１）を用い、スライディングウィンドウパターンを介して閉から開への移行を検出することである。

入力ストリームデータから来たサンプルＪＳＯＮフォーマットのリアルデータは次の通りである。

Ｖｅｌプログラム

論理的正当性を検証しテストする。図１４は、論理的正当性を検証しテストする画面を示す。これは、論理的検証（意味の流れ）とともにプログラムの正当性を実証するための小さな具体例であるが、これを、極めて複雑なデータフロー問題に外挿することができる。その場合、シンタックスの間違いを検出し論理的（セマンティクスの）間違いも検出するツールの能力は非常に有用である。

インタラクティブシェルおよびライブデバッグ。Ｖｅｌ開発ツールは、端末で実行されるインタラクティブデバッガを提供する。このツールは、Ｖｅｌスクリプトの開発中に、予想通りに動作していることを確認する、または、何が問題なのかを解明するのに役立つ。

デバッガへの出入り。Ｖｅｌをコンパイルするツールと同じツールが、そのデバッガとしても機能する。図１５はコマンドデバッガを示す。コマンドは「debug」である。これにより、端末のインタラクティブセッションに入る。「vel>」プロンプトを見ることになるので、いつＶｅｌデバッガに入ったかがわかる。デバッガから出るときは、ｃｔｒｌ＋ｄまたはｑｕｉｔを押せばよい。

ローディング。パッケージに対する作業を行なうには、その前にそれをロードしなければならない。ＬＯＡＤディレクティブは、スクリプトをファイルから読出し、変換し、パッケージとしてデバッガで保持して実行の準備をする。

図１６はロードディレクティブの一例を示す。これは、「test.vel」スクリプトをロードし、これに論理名「valve_test」を割り当てる。以下、このパッケージに言及するときはこの名称「valve_test」を使用する。しかしながらこのパッケージはまだ開始されていない。開始されていないパッケージは、入力に対して反応することは出来ず、何の出力も生成しない。パッケージは好きなだけロードすることができる。ライブエッジノードの場合と全く同様に、これらは実行中に並列で実行されトピックに関して相互にやり取りする。

図１７はステータス・マニフェストディレクティブを示す。どのパッケージにＳＴＡＴＵＳディレクティブがロードされるかがわかる。また、ＭＡＮＩＦＥＳＴディレクティブを有する各パッケージのストリームを見ることができる。

スタートアップ。ＳＴＡＲＴＵＰディレクティブを用いてすべてのパッケージの実行を開始する。個々のパッケージをその名称を指定することによってスタートアップすることもできるが、すべてを一度に開始することが実用的であることが多い。スタートアップアクションを有するパッケージは、開始するとすぐにそれらを実行する。一旦開始すると、パッケージは入来するデータに応じ、そのストリーム定義に従って結果を生成することができる。開始したパッケージのバインディングは、それを停止またはアンロードすることなく変更できる。

データ注入（injection）。ＩＮＪＥＣＴディレクティブにより、データを外部ソースにバインドすることなく、ストリームに直接注入できる。これにより、他のインフラストラクチャまたはツールセットアップによってデータ実験をポンプする必要は回避される。たとえば、この例において、バルブの状態は現在開いた状態ではないことを先ずポンプすると説明してきた。そこで、プログラムに対し、バルブは現在開いていない（not_open）と意図的に知らせる。

図１８は、現在開いていないバルブを示す。注入されている値は、引用されたストリングとしてではなく、Ｖｅｌスクリプトで与えられ、いかなる形態のトランスコードも受けない。Ｖｅｌ値を直接構成しこれをストリームに入れる。注入後、値の挙動は通常通りになる。反応およびそれに基づくその他の計算は、値をブローカーから受けた場合と全く同じように進行する。直接的な注入は、パッケージを通していくつかの値を実行することを試みたいだけの場合には便利である。パッケージに注入するには、パッケージを開始しなければならない。

デッドライン（deadline）。このツールの重要な特徴のうちの１つは次の通りである。デバッガにおける時間は人為的である。時間は、流れると述べた場合にしか流れない。そうすると、パッケージを前に進めてそれがどのように働くかを知ることができる。デバッガが開始する時間を「start」と呼ぶ。デバッガの現在の時間は「now」である。その他すべての時間はこれらに対して相対的に与えられる。絶対的な時間は存在しない。各パッケージは、次に行動しようとするとき、未来の時間が念頭にある。これがパッケージのデッドラインである。各パッケージのデッドラインは、ＤＥＡＤＬＩＮＥディレクティブで知ることができる。

図１９はデッドラインディレクティブを示す。「never」というデッドラインは、デッドラインが存在しないを意味する。この場合、「valve_test」パッケージは、パッケージが完全にリアクティブであり（すなわち自身のタイマーに基づいてアクションを起こさない）現在ペンディングの入力はないのでもう一度実行するか否かに興味がない、という、デッドラインの意味を持たない。このユースケースは、valve_statusが、trueに続くfalseであるか否かを判断することであることを思い出して頂きたい。最後の「next」ラインは、すべてのパッケージのうちで最も早いデッドラインを示している。この場合、ロードされたパッケージは１つしかないので、次のデッドラインは、「never」である「valve_test」のデッドラインと同一である。「now」というデッドラインを有するパッケージは、即実行する準備ができている。ペンティング入力を有するパッケージは、これらの入力の処理を希望するのであれば、常に準備ができている「now」である。パッケージが、実行中のタイマーを有する場合、タイマーに基づくデッドラインを有し得る。このようなデッドラインは、「now + 25(ms)」のようなものであろう。

図２０は開こうとするバルブを示す。ここで、このプログラムのロジックを実行するために、valve_statusにtrueを注入して、バルブを開こうとする。ここでtrueの注入は、trueウィンドウがマッチする前にfalseにデータがマッチすることを待っているパターンを示す。パターンマッチは、リアクションの発生条件を満たすことを意味する。このことは、想定したロジックが正しい場合、valve_opened上に出力が見えるはずであることを意味する。これは、生のセンサデータからの論理イベントの最も正確な検出である。

図２１はＧＯディレクティブを示す。ｇｏさせる。ＧＯディレクティブは、デバッガを、最も早いデッドラインまで前進させる。デバッガは、ｇｏを用いることにより、「valve_test」パッケージがそのペンディング入力に今反応できるようにしている。入力は既に待機していたので、時間の経過は不要であった。このパターンは実際マッチングしていたので、今その出力がある。

自動デバッグ。予め設定された一連のディレクティブを通してデバッガを実行することが好都合な場合が多い。これを容易にするために、デバッガはＤＯディレクティブ：vel> do 「stored_directives.vdbg」を与える。

これは、「stored_directives.vdbg」ファイルに格納されているディレクティブを読出して１度に１つずつ順番に実行する。これは、あたかもこれらをデバッガ内にタイプしたかのようであるがすべてタイプしてはいないというのと同じである。

デバッガ内へのライブデータの捕捉をリプレイ。デバッグにおいて、ライブシナリオは、既存のデータソースから「ライブ」データを捕捉してＶｅｌデバッガ内にリプレイするのに好都合であることが多い。このようにして、ビデオエディタのような実行およびデータのセマンティックなデバッグをインフライトで制御することができる。時間という概念を外部から注入することにより、システムのどの部分も検査し易くなる。

プロダクションにおいて既に実行しているＶｅｌプログラムのライブ検査。これは、プロダクションにおいて実行中のＶｅｌプログラムのライブ状態の抽出を支援するツールの一部である。先になしたポイントに戻って、ツールは、問題を、データフローのセマンティクスおよびその瞬間に何が起こっているかをインフライトで素早くフェッチするためにいかなるときも外部からクエリすることができる、デフォルト内部自己検査データフローレジームを公開することによって、解決する。

使用例

これは、データフローの状態および形状の両方をダンプする。次に、これの出力を、フローを見る価値を視覚的に詳細に示すビジュアライゼーションスタジオ（以下で説明）において、連続的にプロットすることができる。図２２Ａ〜図２２Ｂはデータフローの状態および形状を示す。図２２Ａにおいて、ライン２２０５は、図面に示されている画面の部分で見えているものよりも長い。ライン２２０５の残りの部分は、図２２Ｂにおいてライン２２０７として示されている。

Ｖｅｌプログラミングに関連する関数のその他のセットは以下を含む。（４）プラットフォームから独立した暗号的に安全なプログラムパッケージャ（packager）。これは、Ｖｅｌプログラムを、不明瞭な実行可能なプラットフォーム独立形態（パッケージ）に変換できるようにする。これは、プログラム定義と、プログラムの起源に関する情報（プログラムのバージョン、作者の名前およびコンタクト情報、プログラムに使用する目的のライセンス、関連する法律上の注意点、ならびにその他のそのようなメタ情報等）とを含み、それとともに、そのコンテンツを検証するための、パッケージの暗号ダイジェストおよびデジタル署名を含み、それにより、他人による使用のために開発されたＶｅｌプログラム（場合によってはその複数のバージョン）をリリースするプロセスを容易にし標準化する一方で、プログラムの起源および内部インテグリティを検証するための確実な手段を提供する。

５．暗号的に安全なプログラムパッケージインポート機構。これは、他人によって開発されたＶｅｌプログラム（場合によってはその複数のバージョン）をインポートするプロセスを容易にし標準化する一方で、プログラムの起源および内部インテグリティを検証するための確実な手段を提供する。

６．暗号的に安全なプログラムパッケージ検査機構。これにより、開発されたパッケージの、作者、バージョン、およびその他メタ情報を含む内容、プログラム定義、ならびに内部ヘルプおよびドキュメント化を、確実に検査し、パッケージの暗号的安全性を検証し、パッケージに関する情報を、外部自動化および直接人的計算にとって有用で都合のよい形態（ＪＳＯＮおよびＨＴＭＬ等）にすることができる。

７．パッケージインタープリタ。これにより、パッケージ化されたＶｅｌプログラムを、ホストプラットフォーム上で、ホストのネイティブなアーキテクチャに完全にコンパイルすることなく、実行することができる。これは、実行プログラムに対してさまざまなサポート機能を与える。これらの機能は、特定の標準およびプロトコルに従ってストリーミングデータチャネルのサブスクライブまたはパブリッシュを行なう機能、特定の標準およびプロトコルに従ってデータをエンコードまたはデコードする機能、特定の標準およびプロトコルに従ってデータを圧縮または解凍する機能、ならびに、特定の標準およびプロトコルに従ってデータを暗号化または解読する機能等の機能である。

８．クロスプラットフォーム実行可能コードジェネレータ。これにより、Ｖｅｌプログラムまたはパッケージまたはこれら両方を、ホストプラットフォームを含むさまざまなプラットフォーム上でネイティブに実行できるコンパクトで効率的な形態に変換する。また、これは、プログラムの有用な動作を実行するのに必要または好都合であろう、再使用可能な（ライブラリ）実行可能コードのさまざまな実行可能コンポーネントを含む。これらのコンポーネントは、特定の標準およびプロトコルに従ってストリームデータチャネルのサブスクライブまたはパブリッシュを行なうことを可能にするコンポーネント、特定の標準およびプロトコルに従ってデータをエンコードまたはデコードすることを可能にするコンポーネント、特定の標準およびプロトコルに従ってデータを圧縮または解凍することを可能にするコンポーネント、ならびに、特定の標準およびプロトコルに従ってデータを暗号化または解読することを可能にするコンポーネント等のコンポーネントである。

９．遠隔デプロイおよびメンテナンス機構。これにより、開発されたＶｅｌプログラムを、安全で検証可能なやり方で遠隔ホストに送信してインストールすることができ、このようにしてインストールしたプログラムを、新たなバージョンが利用できるようになったときにアップグレードすることができ、このようにしてインストールしたプログラムを、不要になったときに遠隔ホストから削除することができ、このようにしてインストールしたプログラムの遠隔ホスト上での実行を開始することができ、このような遠隔ホスト上で実行しているプログラムの、正当性、パフォーマンス、および通常の動作の進行をモニタリングすることができ、このような遠隔ホスト上で実行しているプログラムの実行を停止することができる。

１０．データフローシミュレーションスタジオ。これにより、ストリーミングデータチャネルのサブスクライブおよびパブリッシュ機能を含むＶｅｌプログラムを開発、検証、および実証する実際的なデータフロー環境を提供し、ストリームのライブコンテンツを記録し、シミュレートしたストリームを作成し、記録またはシミュレートしたストリームのコンテンツを編集し、記録またはシミュレートしたストリームを再生し、記録またはシミュレートしたストリームの再生を一時停止または停止し、記録またはシミュレートしたストリームの再生全体またはその一部の巻戻し、繰り返し、またはその両方を行なう。

１１．プログラムビジュアライゼーションスタジオ。これにより、Ｖｅｌプログラムを表示するもしくはリバイズするもしくはその両方を行なうことができる、またはグラフィカルに作成することができる。Ｖｅｌプログラムコンポーネントはノードとしてグラフィックに表され、コンポーネント間のデータリンクはエッジとしてグラフィカルに表される。それによって、ユーザがＶｅｌプログラムのアクションをより直感的かつ十分に理解することを支援する。

１２．データフロービジュアライゼーションスタジオ。これは、プログラムビジュアライゼーションスタジオ、データフロー環境スタジオ、および関連するアクセス可能なライブデータストリームと協力して、Ｖｅｌプログラムを通して流れるストリーミングデータの動画化されたグラフィカルディスプレイを可能にする。これによって、ユーザは、どのようにデータがプログラムコンポーネントに入り、プログラムコンポーネントによって変換され、プログラムコンポーネントから出るのかを見ることができ、データが流れた結果としてのプログラムの内部状態の変化を見ることができ、プログラムの正当性、パフォーマンス、および通常の動作の進行をモニタリングすることができ、間違った動作の検出、診断、および修正を補助することができる。

プログラムまたはデータフロービジュアライゼーションおよびシミュレーションスタジオ。プログラムまたはデータフロービジュアライゼーションおよびシミュレーションツールは、本特許に関して先に述べたさまざまなサービスのバックエンドにおいてＶｅｌツールを使用するウェブベースのツールである。

図２３は、ビジュアライゼーションスタジオのパターン駆動型フロー・リアクティブ概念のブロック図である。ビジュアライゼーションスタジオは、データフロープログラミング言語のための開発環境である。具体的な実装例において、この開発環境は、Ｖｅｌデータフロープログラミング言語のための環境であり、「Visual Vel Maker」として知られている。データフロープログラミング言語には、入力、リアクション、および出力という３つの総合的コンポーネントがある。これらは、Ｖｅｌのパターン駆動型フロー・リアクティブ概念に基づいて設計される。

図２４は、ビジュアライゼーションスタジオの宣言ページの画面を示す。データフロー開発環境は、静的に存在するものをユーザが宣言できる宣言（declarations）ページ２４０５を有する。ユーザは、リアクション（reactions）ボタン２４０９を選択することにより、下記のリアクションページに変更することができる。

宣言ページ上において、宣言のいくつかの例は、ストリーム定義（たとえばセンサを表す）、パターン（たとえば宣言パターンまたはマッチングするパターン、ＴＦＲ（１）を指定）、タイマー、ユーザ定義関数、複合データタイプなどである。各定義のタイプに対し、ツールバーにアイコンおよびボタンがある。それらは、ストリーム２４２２、定数２４２６、ユーザ定義タイプ２４３０、タイマー２４３４、ユーザ定義関数２４３８、およびパターン２４４２である。

ユーザは、コンパイル（compile）ボタン２４５１を選択して用いることにより、プログラムを、開発環境の外部で実行できるポータブルパッケージ表現にコンパイルすることができる。ユーザは、エクスポート（export）ボタン２４５３を用いることにより、プログラムを別のフォーマットにエクスポートすることができる。ユーザは、コードパネルボタン２４５６を用いることにより、プログラムのコードパネルビューを開くことができる。コードパネルには、プログラムのテキストビューがある。コードパネルは、テキストエディタの編集機能を有するので、ユーザはコードを編集できる。これは、直接コーディングしたい上級ユーザには便利であろう。

図２５は、ビジュアライゼーションスタジオのリアクション（reactions）ページ２５０４の画面を示す。リアクションページにおいて、ユーザは、データフロープログラムの解析目的のランタイムビューを有するであろう。ユーザは、計算ブロック（変換器と呼ぶことができる）を追加することができる（add compute blocks）。このページは、入力ストリーム、ローカルストリーム、および出力ストリームといった、入力（インジェクタ（injector）と呼ぶことができる）および出力（エクストラクタ（extractor）と呼ぶことができる）を示すこともできる。

図２６は、ビジュアライゼーションスタジオの宣言ページの別の画面を示す。この画面は、所望のデータフロープログラムを構築するために、ユーザが如何にしてドラッグ・アンド・ドロップを用いて宣言を画面上の異なる位置に移動させることができるかを、表している。この画面は、定数２６１１、ユーザ定義タイプ２６１３、ストリーム２６１６および２６１８（２つのカラムで示される）、タイマー２４２２、ユーザ定義関数２４２５、ならびにパターン２６２７のためのブロックを示す。

図２７は、ビジュアライゼーションスタジオのリアクションページの画面、および、ユーザが如何にしてデータフロープログラムを指定できるかを示す。入力（たとえばインジェクタ）、計算ブロック（たとえばトランスデューサ）、および出力（たとえばエクストラクタ）がある。ユーザは、宣言（宣言ページ上に定められたブロック）、相互接続、計算ブロック（たとえばＴＦＲ（１）仕様等のマッチャープログラム）、および出力を指定することによって、データフロープログラムを指定する。

一例として、図面に示される特定のプログラムにおいて、いくつかのストリーム２７０８（ソフトウェアまたはハードウェアセンサデバイスであってもよい）が入力として使用される。ユーザは、いくつかの計算ブロック２７１７への入力の相互接続２７１３（たとえばライン接続で示されるブロック）を指定する。計算ブロックの出力は、相互接続２７２３（ユーザが指定したもの）を介していくつかのストリームブロック２７２８（たとえば中間トランスデューサ）に接続される。ストリームブロックは、相互接続２７３４を介して出力２７３７（たとえばエクストラクタ）に接続される。

この例は、如何にしてシステム内のいくつかのコンポーネントまたはブロックを、トランスデューサおよびエクストラクタとして使用されるストリームブロック等のさまざまな目的のために使用できるかを示している。さらに、ユーザが画面上のブロックをクリックすれば、別のウィンドウまたは画面がポップアップし、これがブロックの内部を示すであろう。たとえば、計算ブロックをクリックすると、計算ブロックの内部が画面上に示されるであろう。

図２８は、計算ブロックの詳細または内部を示す画面を示す。この画面を用いることにより、計算ブロックの仕様または内容を、閲覧、指定、または修正することができる。データ選択部２８０２、条件部２８０４、およびデータアクション部２８０５がある。関係する入力ストリームの各データ値に対し、画面上で指定されたことが、計算ブロック内で生じる。

図２９は、注釈が追加された計算ブロックの画面を示す。左から右に向かって、計算ブロックは、データを、入力、計算、条件、計算、および出力により、変換する。このモデルは、データフローのパターンマッチング、変換、条件付き評価などを、視覚的に実現する。この環境はユーザにとって直感的である。

示されている例では、入口圧力（inlet pressure）２９１５および出口圧力（outlet pressure）２９１９がある。これらのストリームは、入口および出口の圧力値を提供する。これらの値は差分（diff）ブロック２９２４に与えられ、このブロックが差分演算を実行する。よって、差分ブロックの出力は、入口圧力値と出口圧力値との差である。この差分出力はローカル圧力（local pressure）ストリーム出力２９２８に接続される。計算ブロックをトランスデューサとして用いることにより、２つのセンサ入力に基づいた視覚センサストリーミングローカル圧力を提供することができる。

図３０は、コードパネルを示す画面を示す。ユーザが計算ブロックの詳細をグラフィカルに指定した後に、開発環境は、計算ブロックのためのコンピュータコードを生成することができる。ユーザは、コードパネル３００５を開くことにより、反応画面に重ねられたポップアップウィンドウにおいて計算ブロックプログラムのためのコードのテキストビューを見ることができる。

このコードパネルにおいて、ユーザは、コードを閲覧することができ、希望に応じてコードを編集することができる。上級ユーザは、グラフィカルインターフェイスの代わりにまたはそれと組み合わせて、コーディングにより、計算ブロックのいくつかの部分を指定することを好む場合がある。

ある実装例において、開発環境はウェブベースである。この場合、ソフトウェアはウェブブラウザ内で実行される。別の実装例において、開発環境は、ウェブブラウザが不要な、オペレーティングシステム内で実行されるデスクトップソフトウェアである。

ツールに、論理的正当性のテストを、シンタックスおよびセマンティクスの正当性のテストとともに実行させることは、開発者をより効率的にするのに役立ち、コードがより正しくなることを促進する。論理テストは、コードに関するコンパイラの見識を利用するので、診断メッセージはより完全なものになる。

インタラクティブシェルおよびデバッグにより、開発者がコードをテストし即時レスポンスを得てコードディレクタを検査しその正当性を確認するまたはそのエラーを診断できるようにすることが、容易になる。これらは、プログラム開発中の極めて重要な活動である。

パッケージ化されたＶｅｌプログラム（パッケージと呼ぶこともできる）の生成、検査、解釈、および共有は、一般的に、コードの再使用の実施を容易にすることにより、プログラム開発を強力に支援する。パッケージは一旦開発されてテストされると、さらなる開発にとって信頼できる構成要素となる。また、パッケージは、ソフトウェア開発者が、各ユーザの固有のプラットフォームについて心配することなく、そのＶｅｌベースの製品をユーザに対して販売する共通の形態になる。このようなパッケージに対するユーザの信頼およびこのようなパッケージを活用するユーザの能力は増大する。なぜなら、ユーザは、元の作者から支援を受けなくても、自由にパッケージを検査しそのインテグリティを検証するからである。

さまざまなプラットフォーム上での使用に適したスタンドアロンバイナリ実行可能コードを、特にプラットフォーム上で生成することにより、モノのインターネット（Internet-of-Things）（ＩｏＴ）ユースケースが可能になる。これは、多様な小型デバイス上での複雑な計算に依拠することが多い。既存のパッケージを新たなハードウェア上においてクロスコンパイルにより再使用することによって、異種のフレキシブルなＩｏＴ環境が可能になる。

遠隔デプロイおよびモニタリング機構もＩｏＴユースケースにとって極めて重要である。一旦開発されると、パッケージは、遠方にある遠隔ホストの異種の一団に対して簡単にデプロイすることができ、一方では、特にそのためにクロスコンパイルされているので各ホスト上で最適に実行される。一団のパッケージ全体においてデプロイされたもののアクティビティを、中心点からモニタリングおよび制御することによって、動作を簡素化することができる。

コンパイルされたパッケージの遠隔実行は、特に遠隔プラットフォームが小さすぎて好都合な開発環境を提供出来ない場合に、プログラマーがそのプログラム上で素早く反復し、このプログラムをそのターゲットハードウェア上で１つのコマンドでコンパイルおよびテストし、一方で、このプログラマーが選択したプラットフォーム上における開発の利便性を保つことができる。

シミュレートされたデータフロー環境を提供することは、開発者らが彼らのコード内にあるバグを解決することを支援し、論理的正当性のテストと協力して、パッケージが正しく機能していることを実証する。また、データフローシミュレーションは、教育環境において、販売実演の支援や、ライブデータが利用できないまたは望ましくない他の状況にも役立つ。

同様に、プログラムおよびデータフローのビジュアライゼーションは、ソフトウェア開発のプロセスを強力に支援する。プログラマーは、プログラムおよびデータフロー環境に対して直感的に作業することができ、テキストベースの環境単独で一般的に可能なものに比べてより素早くコンポーネント間でナビゲートすることができ、作業の対象となっているアクティブなプログラムコンポーネントおよびデータをその場で検査し修正することができる。

Ｖｅｌフェーズ１変換器の顕著な特徴の１つは、これが、ＴＦＲ（１）アルゴリズムを用いて効率的なステートマシン（「マッチャー」）を構築することにより、リアクションをトリガして属性計算機能を適用するのに必要なパターンマッチングを実行することである。固有のパターンマッチング技術は、時間前進最右（time forward right-most）（１）パターンマッチングまたはＴＦＲ（１）と呼ばれる。

フェーズ１変換ツールは以下を含む。（１）入力言語を構文木に変換する構文解析器。（２）解析中の言語がドメイン固有言語（ＤＳＬ）解析器またはマクロ解析器の態様で解析器によって修正され得るように、変換中のプログラムが自己参照を行なうことを可能にする語彙バインドコンポーネント。（３）バインドされた構文木を、データフロー、パターン、反応、関数式、タイマー、および入出力パラメータ化を表す記号に変換する意味解析アルゴリズム。（４）式木を、多かれ少なかれマイクロプロセッサＡＬＵ命令への直接変換に適したスタックに変換する式トランスレータ。（５）反応のパターンおよび式を潜在的に次善のマッチャーの中間収集物に変換するためのマッチャージェネレータ。（６）マッチャーの中間収集物から統合された最小のマッチャーを作成するためのマッチャー結合および最適化アルゴリズム。

フェーズ１変換ツールの出力は以下を含む：（１）変換に関与する各ストリームの論理的アイデンティティ。各々が複数のストリームの中で一意的な参照であり得るようにする。（２）各ストリームにおけるデータにおけるフローの記述。各々、内方向（反応に向かう、すなわち外部ソースへのサブスクリプション）、外方向（反応から離れる、つまり外部の宛先へのパブリケーション）、内方向および外方向の両方（パブリケーション／サブスクリプションのペア）、または内部（他の反応における中間ステップとしてのみ使用されるため、パブリケーションまたはサブスクリプションとして表面化されない）である。（３）各ストリームにおいて流れるデータの型の記述。ストリームに注入またはストリームから抽出されるデータが型の正しさを静的にチェックされるように、都度有限項で記述される。（４）マッチャーの状態および遷移を記述する表のセット。（５）反応の間に実行されるべき計算を記述する式スタックのセット。（６）ストリーム入力をマッチャー入力にマッピングする表。（７）時限イベント（timed event）をマッチャー入力にマッピングする表。（８）マッチャー出力をアクションのペアにマッピングする表。各ペアは、式スタックへの参照およびストリーム出力から構成され、マッチャーの出力が所与の式で変換され、次いで所与のストリームにプッシュされることを示す。

Ｖｅｌインタープリタおよびデータフローシミュレータはフェーズ１変換の出力を直接使用する。インタープリタはコードの実行においてハードウェアプラットフォームをエミュレートし、データフローシミュレータはストリーミングデータ環境をエミュレートし、Ｖｅｌストリームに入力を提供し、Ｖｅｌストリームから出力を収集する。これらの２つのタスクを命令解釈およびデータフローエミュレーションと呼ぼう。

命令解釈は、コンパイラおよびインタープリタの作成を専門とするコンピュータプログラマーがよく理解するタスクのカテゴリである。タスクには、実行時変数の状態を格納できる実行コンテキストを構築し、プログラムの命令を一度に１つずつ実行し、実行コンテキストからデータにアクセスし、必要に応じてそれを更新することが含まれる。

Ｖｅｌの場合、実行コンテキストには、変換の過程でデータのストリームを保持するキューのセット、およびマッチャーで記述された変換を実行する表駆動型の状態機械エンジンも含まれている必要がある。キューは、データの流通チャネルを記述する、Ｖｅｌソースにおける宣言のため、発生する。これらのうちのいくつかは、Ｖｅｌプログラムの外部入力または出力であり、他のいくつかは入力と出力との間の中間状態を記述する純粋な内部チャネルである。

データフローエミュレーションは、ファイルやソケットなどのデータのために外部ソースおよびシンクへのアクセスを提供することと、これらの外部システムと解釈されているＶｅｌプログラムとの間でデータを交換するために必要なプログラミングとからなる。これには、外部ソースからデータを読み出してそれらデータをプログラムの入力を表すキューにプッシュする注入関数と、プログラム出力を表すキューからデータをポップしてそれらデータを外部シンクに書き込む抽出関数とが含まれる。

本発明によるＶｅｌの解釈が正規とは異なるところでは、マッチャーが関与するようになる態様である。マッチャー駆動エンジンは、キューからデータを読み取り、それらデータを使用してそれらのマッチャーの状態を前進させる。マッチャー表には、マッチャーがそれらの状態を通過するときに実行される副作用の列が含まれる。これらの副作用は、命令解釈を呼び出して計算を実行し、その結果は他のキューにプッシュされ、これが他のマッチャーをトリガする。

このようにして、本発明による解釈中のＶｅｌプログラムは、最初に、高速かつ小規模な状態機械のセットによって表され、必要なときに一般的な命令解釈にドロップバックするだけである。これにより、命令解釈だけですべて処理される場合よりも、プログラムの実行効率が向上する。

Ｖｅｌフェーズ２変換ツールは、大部分、Ｖｅｌ言語に固有ではなく、実行対象のプラットフォームに固有である。フェーズ２トランスレータのＶｅｌ言語関連コンポーネントは次のとおりである。（１）フェーズ１によって生成された中間表現の初期取入れ。（２）反応性システムを生成するフェーズ２コード生成の全体的編成。（３）データフォーマットの外部エンコードおよびデコード、またはリアルタイムクロックの内部調整を実行するもののような、ランタイムサポートコンポーネントのライブラリの提供。

Ｖｅｌフェーズ２変換器の顕著な特徴は、これが、トライステートフローグラフとしてリアクティブシステムを実現することである。マルチソース・マルチ宛先データフロー環境におけるデータストリームのリアルタイム処理のためにプログラムを作成するためのツールは、以下を含む。（１）複数の潜在的なデータストリームを識別すること。（２）このストリームにおけるデータのパターンに対応するリアクティブ関数およびパラメータのセットを識別すること。（３）宣言されたパターンにマッチするデータを変換するための処理関数およびパラメータのセットを識別すること。（４）データが収集または破棄される時間の間隔や、データが収集または破棄される前後の特定の時点など、データフローのパターンが比較される時限イベントのセットを識別すること。（５）識別されたストリーム、反応、関数、および時限イベントを記述するデータフロープログラムを作成すること。（６）このプログラムを、Ｖｅｌプログラム文を対応するマッチャーに変換するためのマッチャージェネレータを組込んだフェーズ１変換ツールと、プラットフォーム上での実行のために変換されたＶｅｌ文に対応するプラットフォーム固有のハードウェア命令を生成するためのフェーズ２変換ツールとを備える２フェーズ変換ツールに、入力として与えること。（７）変換ツールの各フェーズの出力を受け取ること。

フェーズ１変換ツールの出力は、以下を含むインタープリタコンポーネントによって使用されてもよい：（１）コードの実行においてハードウェアプラットフォームをエミュレートする命令インタープリタ。（２）ストリーミングデータ環境をエミュレートし、Ｖｅｌストリームに入力を提供し、Ｖｅｌストリームから出力を収集するデータフローシミュレータ。

フェーズ１変換ツールの出力は、以下を含むフェーズ２変換ツールへの入力として使用することができる：（１）命令を、中間表現から、ターゲットハードウェアプラットフォームによる実行に適した形式に変換するハードウェア命令ジェネレータ。（２）データフロー環境におけるリアクティブプログラムとしての使用に適した形式で出力が生成されるよう指示するプログラム編成モジュール。（３）実行に必要なランタイムサポートコンポーネントのライブラリ。ある実装例において、フェーズ２変換ツールの出力は、対象とされるハードウェアプラットフォーム上での使用に適した実行可能なプログラムである。

ある実装例において、データフロープログラミング言語のための開発環境により、少なくとも１つのマッチャー・ステートマシンを指定することができる。このステートマシンは、受信した入力ストリームにおけるパターンマッチングを実行して出力データを生成することができる。この開発環境はツールを含み、これらのツールは、潜在的なデータストリームを識別すること、上記ストリームにおけるデータのパターンに対応するリアクティブ関数とパラメータとのセットを識別すること、宣言されたパターンにマッチするデータを変換するための処理関数とパラメータとのセットを識別すること、および、データが収集もしくは破棄される時間の間隔またはデータが収集もしくは破棄される時間の前もしくは後の特定の時点等の、データフローのパターンの比較対象である時限イベントのセットを識別すること、のうちの少なくとも１つを実行する。ある実装例において、データフロープログラミング言語は、FogHornのＶｅｌである。

さらに、上記ツールは、上記識別したストリーム、リアクション、関数、および時限イベントを記述するデータフロープログラムを、表明された意図に基づいて作成すること、プログラムステートメントを、対応するマッチャー、データフロートポロジ、関数、および関連するシンボリックコンポーネントに変換するためのマッチャージェネレータが組込まれた第１フェーズ変換ツールと、プラットフォーム上で実行される、上記変換されたステートメントに対応する最適化されたプラットフォーム固有ハードウェア命令を生成するための第２フェーズ変換ツールとを含む２フェーズ変換ツールに、上記プログラムを入力として与えること、および、上記変換ツールの各フェーズの出力を受信すること、のうちの少なくとも１つを実行し得る。

上記開発環境は、ユーザが１つ以上の計算ブロックを追加できるようにするグラフィカルユーザインターフェイスを有し、各計算ブロックはステートマシンを実現する。上記グラフィカルユーザインターフェイスは、ユーザが、追加した１つ以上の計算ブロックに接続する入力ブロックを選択できるようにする。上記グラフィカルユーザインターフェイスは、ユーザが、出力ブロック（たとえばエクストラクタ）に、または、他の変換器（たとえばストリームブロックもしくは計算ブロック）に接続する追加した１つ以上の計算ブロックからの出力を選択できるようにする。

上記開発環境は、上記第１フェーズ変換ツールの出力を使用するインタープリタコンポーネントを含む。コードの実行においてハードウェアプラットフォームをエミュレートする命令インタープリタはある。ストリーミングデータ環境をエミュレートし、ステートマシンストリームに入力を与えステートマシンストリームからの出力を収集する、データフローシミュレータがある。計算およびデータをインフライトで検査し計算を前後に駆動するプログラム実行フローコントローラがある。

上記開発環境はライブ検査コンポーネントを含む。ある検査方法は、特定のハードウェアプログラム上のライブ実行中プログラムをインストルメント化しそれにアタッチし、データフローグラフの形状に関する見識を提供する。ある検査方法は、アタッチ後に実行されて、実行中プログラムのデータフロー計算の状態を抽出し、計算に関する高精度の直接的な見識を、考慮するデータとともに提供する。

上記開発環境は、ビジュアライゼーションおよびデータフローシミュレーショングラフィカルベースコンポーネントを含む。プログラムをグラフィカルに書くまたは表示するまたは修正することができるようにするグラフィカルベースインターフェイス（またはウェブベースインターフェイス、または組合せ）がある。これは、ユーザがストリーミングデータ解析のためのより直感的なメンタルモデルを得て上記プログラムのアクションを十分に理解することを支援する。実際のデータの流れをアニメーションおよびリンクを介して視覚的にシミュレートすることにより、書かれたグラフィカルプログラムをテスト駆動する、データフローシミュレーションがある。シミュレーションコンポーネントは、注入された時間の概念を外部制御しデータフローおよび計算において流動性が前後するようにする。

インタープリタコンポーネントは、上記第１フェーズ変換ツールの出力を使用する。命令インタープリタは、コードの実行においてハードウェアプラットフォームをエミュレートする。データフローシミュレータは、ストリーミングデータ環境をエミュレートし、ステートマシンストリームに入力を与えステートマシンストリームからの出力を収集する。プログラム実行フローコントローラは、計算およびデータをインフライトで検査し計算を前後に駆動する。

上記第１フェーズ変換ツールは、デバッグ環境における複数のパブリッシャから複数のサブスクライバへのシミュレートされたメッセージのやり取りを容易にする、（一般的にメッセージブローカーと呼ばれる）シミュレートされたパブリッシャ−サブスクライバ型マルチプレクサを含む。

上記開発環境はライブ検査コンポーネントを含む。ある検査方法は、特定のハードウェアプログラム上のライブ実行中プログラムをインストルメント化しそれにアタッチし、データフローグラフの形状に関する見識を提供する。ある検査方法は、アタッチ後に実行されて、実行中プログラムのデータフロー計算の状態を抽出する。この検査方法はまた、計算に関する高精度の直接的な見識を、考慮するデータとともに提供する。

上記第１フェーズ変換ツールの出力は、上記第２フェーズ変換ツールへの入力として使用することができる。上記変換ツールは、命令を、中間表現から、ターゲットハードウェアプラットフォームによる実行に適した形式に変換するハードウェア命令ジェネレータと、データフロー環境におけるリアクティブプログラムとしての使用に適した形式で出力が生成されるよう指示するプログラム編成モジュールと、上記ターゲットハードウェアプラットフォーム上で実行できるようにするランタイムサポートコンポーネントのライブラリとを含み得る。ある実装例において、第２フェーズ変化ツールの出力は、ターゲットハードウェアプラットフォーム上での使用に適した実行可能なプログラムである。

ある実装例において、データフロープログラミング開発プラットフォームのためのシステムは、コンピュータの画面に表示されるグラフィカルユーザインターフェイスを含む。上記開発プラットフォームのグラフィカルユーザインターフェイスの宣言画面を用いて、ユーザは、ストリームと定数と関数とパターンとを含む宣言データタイプを指定することができる。ストリーム内で識別すべきパターンを指定するためにパターン定義が使用される。上記宣言データタイプを表すブロックが上記画面に表示されて、ユーザが上記ブロックを上記画面上の所望の位置にドラッグ・アンド・ドロップできるようにする。

上記開発プラットフォームのグラフィカルユーザインターフェイスのリアクション画面を用いて、ユーザは、上記宣言データタイプのブロックを、データフロープログラムのグラフィカル表現に相互接続することができる。上記リアクション画面において、ユーザは異なるブロック間の相互接続（ワイヤまたはラインとして見えている）を指定して変更することができる。

上記開発プラットフォームのグラフィカルユーザインターフェイスの計算ブロック画面を用いて、ユーザは、計算ブロックによって実行される演算を見て指定することができる。ユーザは、上記計算ブロックへの入力および上記入力に対する計算、ならびに上記計算ブロックの出力を指定することができる。上記開発プラットフォームのグラフィカルユーザインターフェイスのコード閲覧画面を用いて、ユーザは、上記計算ブロック画面においてグラフィカルに表された演算のコンピュータコード表現を見て編集することができる。上記コンピュータコードは上記開発プラットフォームによって自動的に生成される
上記開発プラットフォームのインターフェイスに対するコンパイルコマンド（たとえばグラフィカルボタン）を用いて、ユーザは、上記開発プラットフォームのインターフェイスを用いて指定した上記データフロープログラムのデータフロープログラムパッケージ表現をコンパイルするよう、上記開発プラットフォームのインターフェイスに指示することができる。ストリームタイプブロックを、入力データを取込んでデータを出力する、データの作成部兼変換部として使用することができる。

さらに、上記開発プラットフォームのコンポーネントは、コードの実行においてハードウェアプラットフォームをエミュレートする命令インタープリタと、ストリーミングデータ環境をエミュレートし、ステートマシンストリームに入力を与え上記ステートマシンストリームからの出力を収集するデータフローシミュレータと、計算およびデータをインフライトで検査し計算を前後に駆動するプログラム実行フローコントローラと、デバッグ環境における複数のパブリッシャから複数のサブスクライバへのシミュレートされたメッセージのやり取りを容易にする、シミュレートされたパブリッシャ−サブスクライバ型マルチプレクサとを含む。

ある実装例において、データフロープログラムを開発する方法は、グラフィカルユーザインターフェイスを用いて、データフロープログラムのグラフィカル表現を指定することを含み、上記プログラムは、作成タイプと、変換タイプと、抽出タイプとを含む。上記グラフィカルユーザインターフェイスを通して、ユーザは、ブロックを用いて表された上記作成タイプ、上記変換タイプ、および上記抽出タイプを選択してコンピュータ画面上のさまざまな位置に移動させることができる。上記グラフィカルユーザインターフェイスを用いて、上記作成タイプ、上記変換タイプ、および上記抽出タイプを表すブロックを上記ユーザが相互接続リンクを介して相互接続できるようにする。上記グラフィカルユーザインターフェイスを通して上記ブロック各々の詳細を上記ユーザが指定できるようにする。ユーザは変換タイプブロックに対して動作を指定することができる。ユーザが上記グラフィカルユーザインターフェイスを用いて指定した上記データフロープログラムに対応するコンピュータソースコードを自動的に生成する。テキストインターフェイスにおいて自動的に生成された上記コンピュータソースコードをユーザが見て編集できるようにする。ユーザが上記グラフィカルユーザインターフェイスを用いて指定した上記データフロープログラムを実現したものであるターゲットハードウェアプラットフォーム上で実行可能なコードのコンピュータパッケージの生成を、ユーザが指定できるようにする。

変換ブロックにおける上記動作はパターンマッチング動作である。上記コンピュータソースコードを自動的に生成することは、上記動作をステートマシンを用いて実現し、上記ステートマシンは、バックトラッキングすることなく、作成部の入力ストリームのデータを処理する技術を反映する。別の実装例において、上記コンピュータソースコードを自動的に生成することは、上記動作をステートマシンを用いて実現し、上記ステートマシンが反映する技術は、作成部の入力からのストリームデータを一度だけ処理し、前に読み出したデータを後で再び読み出すためにバッファに保持しない。作成は、ハードウェアセンサの仮想表現であってもよい。

本発明のこの記載は、例示および説明のために提示されたものである。それは、網羅的であることを意図するものでもなく、本発明を記載された正確な形態に限定することも意図されておらず、上記教示に照らして多くの修正および変形が可能である。実施形態は、本発明の原理およびその実際の適用を最もよく説明するために選択され、記載された。この記載により、当業者は、本発明を、さまざまな実施形態において、および特定の用途に適したさまざまな修正を加えて、最も有効に活用し実施することが可能になる。本発明の範囲は、特許請求の範囲によって規定される。

Claims (20)

1. 方法であって、
   少なくとも１つのマッチャー・ステートマシンを指定できるようにする、データフロープログラミング言語のための開発環境を提供することを含み、前記マッチャー・ステートマシンは、受信した入力ストリームにおけるパターンマッチングを実行して出力データを生成することができ、前記開発環境は複数のツールを含み、前記複数のツールは、
   複数の潜在的なデータストリームを識別すること、
   前記ストリームにおけるデータのパターンに対応するリアクティブ関数とパラメータとのセットを識別すること、
   宣言されたパターンにマッチするデータを変換するための処理関数とパラメータとのセットを識別すること、
   データが収集もしくは破棄される時間の間隔またはデータが収集もしくは破棄される時間の前もしくは後の特定の時点等の、データフローのパターンの比較対象である時限イベントのセットを識別すること、
   前記識別したストリーム、リアクション、関数、および時限イベントを記述するデータフロープログラムを、表明された意図に基づいて作成すること、
   プログラムステートメントを、対応するマッチャー、データフロートポロジ、関数、および関連するシンボリックコンポーネントに変換するためのマッチャージェネレータが組込まれた第１フェーズ変換ツールと、プラットフォーム上で実行される、前記変換されたステートメントに対応する最適化されたプラットフォーム固有ハードウェア命令を生成するための第２フェーズ変換ツールとを含む２フェーズ変換ツールに、前記プログラムを入力として与えること、および、
   前記変換ツールの各フェーズの出力を受信すること、
   のうちの少なくとも１つを実行する、方法。
2. 前記開発環境は、ユーザが１つ以上の計算ブロックを追加できるようにするグラフィカルユーザインターフェイスを有し、各計算ブロックはステートマシンを含む、請求項１に記載の方法。
3. 前記グラフィカルユーザインターフェイスは、ユーザが、追加した１つ以上の計算ブロックに接続する入力ブロックを選択できるようにする、請求項２に記載の方法。
4. 前記グラフィカルユーザインターフェイスは、ユーザが、出力ブロックに接続する追加した１つ以上の計算ブロックからの出力を選択できるようにする、請求項３に記載の方法。
5. 前記開発環境は、前記第１フェーズ変換ツールの出力を使用するインタープリタコンポーネントを含み、前記インタープリタコンポーネントは、
   コードの実行においてハードウェアプラットフォームをエミュレートする命令インタープリタと、
   ストリーミングデータ環境をエミュレートし、ステートマシンストリームに入力を与えステートマシンストリームからの出力を収集する、データフローシミュレータと、
   計算およびデータをインフライトで検査し計算を前後に駆動するプログラム実行フローコントローラとを含む、請求項１に記載の方法。
6. 前記開発環境はライブ検査コンポーネントを含み、前記ライブ検査コンポーネントは、
   特定のハードウェアプログラム上のライブ実行中プログラムをインストルメント化しそれにアタッチし、データフローグラフの形状に関する見識を提供する、検査方法と、
   アタッチ後に実行されて、実行中プログラムのデータフロー計算の状態を抽出し、計算に関する高精度の直接的な見識を、考慮するデータとともに提供する、検査方法とを含む、請求項１に記載の方法。
7. 前記開発環境は、ビジュアライゼーションおよびデータフローシミュレーショングラフィカルベースコンポーネントを含み、当該コンポーネントは、
   プログラムをグラフィカルに書くまたは表示するまたは修正することができるようにすることによって、ユーザがストリーミングデータ解析のためのより直感的なメンタルモデルを得て前記プログラムのアクションを十分に理解することを支援する、グラフィカルベースインターフェイスと、
   注入された時間の概念を外部制御しデータフローおよび計算において流動性が前後するようにして、実際のデータの流れをアニメーションおよびリンクを介して視覚的にシミュレートすることにより、書かれたグラフィカルプログラムをテスト駆動する、データフローシミュレーションとを含む、請求項１に記載の方法。
8. 前記開発環境は、前記第１フェーズ変換ツールの出力を使用するインタープリタコンポーネントを含み、前記インタープリタコンポーネントは、
   コードの実行においてハードウェアプラットフォームをエミュレートする命令インタープリタと、
   ストリーミングデータ環境をエミュレートし、ステートマシンストリームに入力を与えステートマシンストリームからの出力を収集する、データフローシミュレータと、
   計算およびデータをインフライトで検査し計算を前後に駆動するプログラム実行フローコントローラとを含む、請求項７に記載の方法。
9. 前記第１フェーズ変換ツールは、デバッグ環境における複数のパブリッシャから複数のサブスクライバへのシミュレートされたメッセージのやり取りを容易にする、一般的にメッセージブローカーと呼ばれる、シミュレートされたパブリッシャ−サブスクライバ型マルチプレクサを含む、請求項８に記載の方法。
10. 前記開発環境はライブ検査コンポーネントを含み、前記ライブ検査コンポーネントは、
    特定のハードウェアプログラム上のライブ実行中プログラムをインストルメント化しそれにアタッチし、データフローグラフの形状に関する見識を提供する、検査方法と、
    アタッチ後に実行されて、実行中プログラムのデータフロー計算の状態を抽出し、計算に関する高精度の直接的な見識を、考慮するデータとともに提供する、検査方法とを含む、請求項８に記載の方法。
11. 前記第１フェーズ変換ツールの出力は、前記第２フェーズ変換ツールへの入力として使用することができ、前記変換ツールは、
    命令を、中間表現から、ターゲットハードウェアプラットフォームによる実行に適した形式に変換するハードウェア命令ジェネレータと、
    データフロー環境におけるリアクティブプログラムとしての使用に適した形式で出力が生成されるよう指示するプログラム編成モジュールと、
    前記ターゲットハードウェアプラットフォーム上で実行できるようにするランタイムサポートコンポーネントのライブラリとを含む、請求項１に記載の方法。
12. 第２フェーズ変換ツールの出力は、前記ターゲットハードウェアプラットフォーム上での使用に適した実行可能なプログラムである、請求項１１に記載の方法。
13. データフロープログラミング開発プラットフォームのためのシステムであって、
    コンピュータの画面に表示されるグラフィカルユーザインターフェイスと、
    前記開発プラットフォームの前記グラフィカルユーザインターフェイスの宣言画面とを備え、前記宣言画面において、ユーザは、ストリームと定数と関数とパターンとを含む宣言データタイプを指定することができ、ストリーム内で識別すべきパターンを指定するためにパターン定義が使用され、前記宣言データタイプを表すブロックが前記画面に表示されて、ユーザが前記ブロックを前記画面上の所望の位置にドラッグ・アンド・ドロップできるようにし、
    前記開発プラットフォームの前記グラフィカルユーザインターフェイスのリアクション画面を備え、前記リアクション画面において、ユーザは、前記宣言データタイプのブロックを、データフロープログラムのグラフィカル表現に相互接続することができ、前記リアクション画面において、ユーザは異なるブロック間の相互接続を指定して変更することができ、
    前記開発プラットフォームの前記グラフィカルユーザインターフェイスの計算ブロック画面を備え、前記計算ブロック画面において、ユーザは、計算ブロックによって実行される演算を見て指定することができ、前記ユーザは、前記計算ブロックへの入力および前記入力に対する計算、ならびに前記計算ブロックの出力を指定することができ、
    前記開発プラットフォームの前記グラフィカルユーザインターフェイスのコード閲覧画面を備え、前記コード閲覧画面において、ユーザは、前記計算ブロック画面においてグラフィカルに表された演算のコンピュータコード表現を見て編集することができ、前記コンピュータコードは前記開発プラットフォームによって自動的に生成される、システム。
14. 前記開発プラットフォームのインターフェイスに対するコンパイルコマンドを備え、ユーザは、コンパイルコマンドを用いて、ユーザが前記開発プラットフォームのインターフェイスを用いて指定した前記データフロープログラムのデータフロープログラムパッケージ表現をコンパイルするよう、前記開発プラットフォームのインターフェイスに指示する、請求項１３に記載のシステム。
15. ストリームタイプブロックを、入力データを取込んでデータを出力する、データの作成部兼変換部として使用することができる、請求項１３に記載のシステム。
16. コードの実行においてハードウェアプラットフォームをエミュレートする命令インタープリタと、
    ストリーミングデータ環境をエミュレートし、ステートマシンストリームに入力を与え前記ステートマシンストリームからの出力を収集するデータフローシミュレータと、
    計算およびデータをインフライトで検査し計算を前後に駆動するプログラム実行フローコントローラと、
    デバッグ環境における複数のパブリッシャから複数のサブスクライバへのシミュレートされたメッセージのやり取りを容易にする、シミュレートされたパブリッシャ−サブスクライバ型マルチプレクサとを備える、請求項１３に記載のシステム。
17. データフロープログラムを開発する方法であって、
    グラフィカルユーザインターフェイスを用いて、データフロープログラムのグラフィカル表現を指定することを含み、前記プログラムは、作成タイプと、変換タイプと、抽出タイプとを含み、前記グラフィカルユーザインターフェイスを通して、ユーザは、ブロックを用いて表された前記作成タイプ、前記変換タイプ、および前記抽出タイプを選択してコンピュータ画面上のさまざまな位置に移動させることができ、
    前記グラフィカルユーザインターフェイスを用いて、前記作成タイプ、前記変換タイプ、および前記抽出タイプを表すブロックを前記ユーザが相互接続リンクを介して相互接続できるようにすることと、
    前記グラフィカルユーザインターフェイスを通して前記ブロック各々の詳細を前記ユーザが指定できるようにすることとを含み、ユーザは変換タイプブロックに対して動作を指定することができ、
    ユーザが前記グラフィカルユーザインターフェイスを用いて指定した前記データフロープログラムに対応するコンピュータソースコードを自動的に生成することと、
    テキストインターフェイスにおいて自動的に生成された前記コンピュータソースコードをユーザが見て編集できるようにすることと、
    ユーザが前記グラフィカルユーザインターフェイスを用いて指定した前記データフロープログラムを実現したものであるターゲットハードウェアプラットフォーム上で実行可能なコードのコンピュータパッケージの生成を、ユーザが指定できるようにすることとを含む、方法。
18. 変換ブロックにおける前記動作はパターンマッチング動作であり、前記コンピュータソースコードを自動的に生成することは、前記動作をステートマシンを用いて実現し、前記ステートマシンは、バックトラッキングすることなく、作成部の入力ストリームのデータを処理する技術を反映する、請求項１７に記載の方法。
19. 変換ブロックにおける前記動作はパターンマッチング動作であり、前記コンピュータソースコードを自動的に生成することは、前記動作をステートマシンを用いて実現し、前記ステートマシンが反映する技術は、作成部の入力からのストリームデータを一度だけ処理し、前に読み出したデータを後で再び読み出すためにバッファに保持しない、請求項１７に記載の方法。
20. セマンティックレベルのデバック機能をユーザに提供することを含む、請求項１７に記載の方法。