JP2022516001A - 通信を形式的に監視するためのシステム - Google Patents

通信を形式的に監視するためのシステム Download PDF

Info

Publication number
JP2022516001A
JP2022516001A JP2021535802A JP2021535802A JP2022516001A JP 2022516001 A JP2022516001 A JP 2022516001A JP 2021535802 A JP2021535802 A JP 2021535802A JP 2021535802 A JP2021535802 A JP 2021535802A JP 2022516001 A JP2022516001 A JP 2022516001A
Authority
JP
Japan
Prior art keywords
actor
function
communication
data
interface
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2021535802A
Other languages
English (en)
Other versions
JPWO2020128363A5 (ja
JP7490656B2 (ja
Inventor
ポール・デュブリュレ
Original Assignee
コミッサリア ア レネルジー アトミーク エ オ ゼネルジ ザルタナテイヴ
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by コミッサリア ア レネルジー アトミーク エ オ ゼネルジ ザルタナテイヴ filed Critical コミッサリア ア レネルジー アトミーク エ オ ゼネルジ ザルタナテイヴ
Publication of JP2022516001A publication Critical patent/JP2022516001A/ja
Publication of JPWO2020128363A5 publication Critical patent/JPWO2020128363A5/ja
Application granted granted Critical
Publication of JP7490656B2 publication Critical patent/JP7490656B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/03—Protocol definition or specification 
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60R—VEHICLES, VEHICLE FITTINGS, OR VEHICLE PARTS, NOT OTHERWISE PROVIDED FOR
    • B60R16/00—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for
    • B60R16/02—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for electric constitutive elements
    • B60R16/023—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for electric constitutive elements for transmission of signals between vehicle parts or subsystems
    • B60R16/0231—Circuits relating to the driving or the functioning of the vehicle
    • B60R16/0232—Circuits relating to the driving or the functioning of the vehicle for measuring vehicle parameters and indicating critical, abnormal or dangerous conditions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/448—Execution paradigms, e.g. implementations of programming paradigms
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/14—Network analysis or design
    • H04L41/145—Network analysis or design involving simulating, designing, planning or modelling of a network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5003—Managing SLA; Interaction between SLA and QoS
    • H04L41/5009—Determining service level performance parameters or violations of service level contracts, e.g. violations of agreed response time or mean time between failures [MTBF]

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Automation & Control Theory (AREA)
  • Mechanical Engineering (AREA)
  • Computer Security & Cryptography (AREA)
  • Debugging And Monitoring (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Stored Programmes (AREA)
  • Selective Calling Equipment (AREA)
  • Computer And Data Communications (AREA)
  • Devices For Executing Special Programs (AREA)

Abstract

本発明は、プラットフォームの特定のアプリケーションのセットの通信を形式的に監視するためのシステムであって、特定のアプリケーションの前記セットをモデル化する参加者のグループの挙動を記述するデータストリームの形式モデル(13)、および前記参加者によってモデル化されたアプリケーションを実装するソフトウェア実装を記述する通信仕様(15)であって、前記ソフトウェア実装が、あらかじめ決定された通信機能を呼び出すように構成された、通信仕様(15)を取得するように構成された取得モジュール(9)と、前記通信機能を呼び出すためのシーケンスが、前記参加者のグループの予期される挙動に準拠していることを検証するように構成された監視モジュール(11)とを備える、システムに関する。

Description

本発明は、具体的なアプリケーションのセットの通信を形式的に監視するためのシステムに関し、より詳細には、サービス指向アーキテクチャにおける、具体的なアプリケーションのセットの通信を形式的に監視するためのシステムに関する。
本発明は、具体的なアプリケーションが、相互にデータを交換するためにあらかじめ定義されたインターフェース機能を使用するシステムに適用される。特に、本発明は、いくつかのタスクの予期される挙動の順守が重要であると見なされる、すなわち、順守がない場合、非常に否定的な結果が生じる可能性があるようなシステムに適用される。一般的に言えば、本発明は、異なるレベルの重要度のタスクが共存するシステムに適用され、いくつかのタスクは、予期される挙動に厳密に準拠する必要があると見なされ、他のタスクは、挙動における逸脱が一時的に許容され、または、さらに他のタスクは、挙動の保証がない。これらは混合臨界システムとして知られている。
自律走行車用の最近のリアルタイム搭載システムは、そのようなシステムの例である。車両用の新しい搭載アーキテクチャは分散されており、異種であり、それらをプログラムするために使用されるパラダイムはサービス指向である。重要なタスクの予期される挙動から逸脱すると、非常に危険な誤動作が発生する可能性がある。一方、快適性や運転経験に関連するいくつかのタスクは、実際には挙動に制約がないため、混合臨界システムである。
したがって、そのようなシステムの形式的な仕様を作成できるツールを有し、指定されたシステムの実装の適合性の形式的な検証が行われることが重要である。
しかしながら、すべての制約を考慮したそのようなシステムの仕様は、非常に複雑な技術的問題である。次いで、指定されたシステムの実装にリソースを割り当て、これらのリソースが、仕様に同意したとおりに実装が機能するのに十分であることを検証する作業が行われる。
再構成可能なリアルタイムデータフローシステムを指定するための形式モデルベースのアルゴリズムがある。そのような方法の1つは、たとえば文書[1]に記載されている。この方法により、実装に必要なリソースと、アクタ間のインターロックがないことを検証することが可能になる。しかしながら、実行中に、指定されたシステムの実装の挙動とその仕様との適合性を検証することはできない。
もう1つの問題は、形式的方法論における指定されたシステムの実装である。これには、各アクタによってモデル化された具体的なアプリケーションを実装するソフトウェアを開発し、形式的に指定された通信を実行するためにこのソフトウェアにおいて通信インターフェースを使用することが含まれる。この実装は、これらの通信が形式的な仕様に準拠するように、インターフェース間の通信用に実装されたソフトウェア要素を構成することを必要とする。
この種のシステム、特にサービス指向システム用のソフトウェアを記述するための多くの言語およびプログラミングインターフェースがある。しかしながら、それらのプログラミングインターフェースはすべて同様の概念、すなわち、サーバによるデータの公開と1つもしくは複数のクライアントによるそのデータのサブスクリプション、または必要な処理の実行を担当するサーバへの1つもしくは複数のクライアントによる要求の放出に基づいている。クライアントとサーバとの間の接続は、システムの存続期間中に変更される可能性があり、システムの適切な動作を保証するために時間の制約が課される場合がある。
文書[2、3]は、データフローアクタを実装するソフトウェアを記述するための言語と、指定されたシステムの挙動を実行するようにコードを生成する関連コンパイラについて説明している。
しかしながら、このソフトウェアは、形式的な仕様のすべての制約を表現できないため、考慮されるコンテキストに制限されており、ほとんどの場合、対象となるソフトウェアアーキテクチャは混合臨界システムに適合していない。さらに、様々なソフトウェアプロデューサがアクタ仕様を実装する開発モデルの範囲では、それらを同じインテグレータに提供するために、インテグレータが特定の言語の使用を強制することは非常に困難である。
したがって、本発明の目的は、特に異種分散プラットフォーム上で任意の言語で記述されたソフトウェア実装の統合を可能にすることによって、前述の欠点を克服するアプリケーションのセットの通信を形式的に監視するためのシステムを提供することである。
本発明は、プラットフォームの具体的なアプリケーションのセットの通信を形式的に監視するためのシステムであって、
- 一方向通信チャネルを通じて、定量化可能な情報を相互に交換するアクタのセットを備えるデータストリームの形式モデルであって、前記形式モデルが、具体的なアプリケーションの前記セットをモデル化するアクタの前記セットの挙動を記述する、形式モデル、および、前記アクタによってモデル化されたアプリケーションを実装するソフトウェア実装を記述する通信仕様であって、前記ソフトウェア実装が、前記プラットフォームのプログラミングインターフェースに関連するあらかじめ決定された通信機能を呼び出すように構成された、通信仕様を取得するように構成された取得モジュールと、
- 前記通信機能への呼出しのシーケンスが、アクタの前記セットの予期される挙動に従っていることを検証するように構成された監視モジュールと
を備える、システムに関する。
したがって、監視モジュールは、考えられるすべての予期される挙動(および、考えられる多くのシナリオの中のあらかじめ決定されたシナリオだけでなく)を認識し、異常な動作が検出された場合に修正措置を適用することができる。さらに、このシステムは、アクタを実装するソフトウェアを修正する必要なしに、形式モデルにおいて指定されたものに従った通信挙動を示す異種分散プラットフォーム上で任意の言語で記述されたソフトウェア実装の統合を可能にする。ソフトウェア実装は、動作環境においてオンラインで搭載することができる。
本発明の好ましい実施形態によれば、監視モジュールは、アクタに対応するソフトウェア実装ごとにオートマトンを構築するように構成され、各オートマトンは、ある状態から別の状態への移行が、ソフトウェア実装から前記通信機能のうちの1つへの呼出しによってトリガされる状態のセットを備え、前記オートマトンは、ソフトウェア実装の前記通信機能への有効な呼出しシーケンスを追跡するために、形式モデルによって予期される挙動に基づいている。
有利なことに、各オートマトンは、ソフトウェア実装の初期化に関連付けられる第1の部分と、ソフトウェア実装の動作に関連付けられる第2の部分とを備え、前記第1の部分の最終状態から前記第2の部分の初期状態への移行は、同期信号がソフトウェア実装によって受信されたときにトリガされ、プラットフォーム上での具体的なアプリケーションの実行を示す。
有利なことに、監視モジュールは、通信機能呼出しをキャプチャするように構成されたソフトウェア要素を生成することと、具体的なアプリケーションの実行時に行われる呼出しのシーケンスがオートマトンによって定義されたシーケンスに対応することを確認することとを行うように構成される。
有利なことに、ソフトウェア要素は、通信機能ごとの拡張機能、入力データ期日管理機能、および現在のアクティベーション管理機能を備えている。
有利なことに、通信仕様はサービス指向実装の仕様である。
有利なことに、通信機能はサービス指向であり、サービス提供機能、インターフェース公開機能、公開インターフェースサブスクリプション機能、放出機能、受信機能、要求機能、およびインターフェース処理機能を備える。
有利なことに、形式モデルは、前記アクタの実装に必要な構成データのセットを備えるため、搭載システムの予期される挙動を記述することができる。
有利なことに、構成データは、アクタごとに、予算、初期遅延、初期期限、入力期限、デフォルトの入力ポリシ、永続的/一時的インジケータ、および厳密な/緩和されたインジケータデータを含む。
有利なことに、通信仕様は、ソフトウェア実装と形式モデルのアクタとの間のリンクを含む。
本発明はまた、前述の特性のいずれかに従って監視システムを使用して設計されたリアルタイムの搭載機器を対象とし、前記搭載機器は、その環境に固有の測定値を受信し、機能的動作を作動させる結果をもたらすように構成されている。
有利なことに、前記機器は、陸上、鉄道、航空宇宙、または海軍タイプの自律型または非自律型の車両である。
本発明はまた、プラットフォームの具体的なアプリケーションのセットの通信を形式的に監視するための方法であって、
- 一方向通信チャネルを通じて、定量化可能な情報を相互に交換するアクタのセットを備えるデータストリームの形式モデルであって、前記形式モデルが、具体的なアプリケーションの前記セットをモデル化するアクタのセットの挙動を記述する、形式モデル、および、前記アクタによってモデル化されたアプリケーションを実装するソフトウェア実装を記述する通信仕様であって、前記ソフトウェア実装が、前記プラットフォームのプログラミングインターフェースに関連するあらかじめ決定された通信機能を呼び出すように構成された、通信仕様を取得するステップと、
- 前記通信機能への呼出しのシーケンスが、アクタの前記セットの予期される挙動に従っていることを検証するステップと
を含む方法を対象とする。
本発明によるデバイスおよび方法のさらなる特徴および利点は、以下の添付の図面を参照して、決して限定するものではなく目的を示すために、以下に与える説明を読むとより明確になる。
本発明の一実施形態による、プラットフォームの具体的なアプリケーションのセットの通信を形式的に監視するためのシステムを概略的に示す図である。 本発明の一実施形態による、グラフによって定義される形式モデルの例を概略的に示す図である。 本発明の一実施形態による、形式モデルのアクタと通信仕様のサービス指向インターフェースの記述との間の対応を概略的に示す図である。 本発明の一実施形態による、形式モデルのアクタと通信仕様のサービス指向インターフェースの記述との間の対応を概略的に示す図である。 本発明の一実施形態による、形式モデルのアクタと通信仕様のサービス指向インターフェースの記述との間の対応を概略的に示す図である。 本発明の一実施形態による、オートマトンの構築を概略的に示す図である。 本発明の一実施形態による、オートマトンの構築を概略的に示す図である。
本発明の原理は、形式的な仕様に従ってデータ交換を観察するために、形式的方法論において指定されたコンポーネントを実装する計算タスク間のデータ交換を監視することである。
図1は、本発明の一実施形態による、プラットフォームの具体的なアプリケーションのセットの通信を形式的に監視するためのシステムを概略的に示している。
形式的な監視システム1は、マイクロプロセッサ5およびメモリ7を備える計算機またはコンピュータ3などの情報処理機械を備えるハードウェア手段によって実装される。マイクロプロセッサ5は、コンピュータのメモリ7に記憶され、アプリケーションのセットの通信を形式的に監視するためのシステムを実装するように設計された、プログラムコード命令を備える1つまたは複数のコンピュータプログラムを実行するように構成される。
監視システムは、プラットフォームの具体的なアプリケーションのセットの通信の形式的な監視を実行することを目的としている。本発明によれば、監視システムは、取得モジュール9および監視モジュール11を備える。
取得モジュールは、具体的なアプリケーションのセットをモデル化するアクタのセットの挙動を記述するデータストリームの形式モデル13を取得するように構成される。さらに、取得モジュール9は、アクタによってモデル化されたアプリケーションを実装するソフトウェア実装を記述する通信仕様15を取得するように構成される。ソフトウェア実装は、あらかじめ決定された通信機能を呼び出すように構成される。
監視モジュール11は、通信機能への呼出しのシーケンスが、アクタのセットの予期される挙動に従っていることを検証するように構成される。
データストリームの形式モデル13は、一方向通信チャネルを通じて、定量化可能な情報を相互に交換する独立したアクタを備える。アクタは、ソフトウェアエンティティ(たとえば、アプリケーション)および/またはハードウェアエンティティ(たとえば、センサ、カメラ、プローブ、マイクロプロセッサなど)である可能性がある。各アクタは、静的に指定された量のデータを消費するために、その量のデータを各アクタの入力チャネルで受信するまで待機することと、そのデータの処理を実行することと(または、実行しないことと)、その出力チャネルで静的に指定された量のデータを新しいアクタに生成することとを行うように構成され、それぞれがこの挙動を無期限に繰り返す。消費/処理/放出処理は、一般にアクティベーションと呼ばれる。
各アクティベーションはあらかじめ定義された再構成に従って行われ、特定の再構成に対して、アクティベーションは消費/処理/生成(いわゆる実行)する、または何もしない(いわゆるパス)のいずれかであり、構成を変更する選択は予測できない。
各アクタは、可能な周波数制約(または、同等に期間制約)を使用して、あらかじめ定義された時間内の再構成(リアルタイムと呼ばれる)ウィンドウに従ってアクティブ化する。
さらに、通信仕様15は、アプリケーション、それらが提供するサービス、それらが使用するサービス、チャネル上を通過するデータのタイプ、異なるアプリケーション間の相互作用に関する情報、プラットフォームのアプリケーションと形式モデルのアクタとの間のリンクまたは対応に関する情報などを含む。
監視モジュール11は、形式的方法論(すなわち、形式モデル13)からの構成および通信仕様15のアプリケーションの記述を入力として受け取り、アクタの実装によって実行される通信を観察し、場合によっては形式的な仕様からの逸脱を修正することを担当する監視ソフトウェア層を自動的に生成するコード生成ツールである。
したがって、本発明による監視システム11は、任意の既存の言語で記述されたアクタの実装を、異種分散プラットフォーム上に自動的に統合する手段を提供する。
対象となるアーキテクチャがインターネット、自動車、航空、気象学などの多くの分野において使用されていることを考えると、この監視システムの潜在的なアプリケーションは数多くある。
特に、本発明は、搭載システムまたはデバイス用の異種分散プラットフォームに適用され、予期される挙動への準拠は、そのようなシステムで提供される機器の安全性および適切な機能にとって非常に重要であると考えられる。
自律走行車用の最近のリアルタイム搭載システムは、そのようなシステムの例であり、エンティティは、具体的なアプリケーションが相互にデータを交換できるようにする一般的なインターフェースを提供し、各アプリケーションは独立しており、分散アーキテクチャのコンピュータで実行される。アプリケーション間の接続は、車両の現在の動作モード、および/またはサービスの可用性に応じて再構成することができる。
以下では、本発明は、アクタのセットからなる形式モデルによってモデル化されたシステムを参照することによって、およびモデルによって予期される挙動の記述を与えることによって、詳細に説明される。
実際、図2は、本発明の例示的な実施形態による、グラフによって定義される形式モデルの例を概略的に示している。
この例によれば、形式モデル13は、30Hzにおいてセンサによって供給されるデータを取得する「取得」アクタと、10Hzにおいてアクチュエータにコマンドを送信する「コマンド」アクタとを備える。コマンドは、可能なすべての再構成におけるデータの前処理を実行する「前処理」アクタ、および、ある再構成では、前処理されたデータの高速で低解像度の処理を実行する「高速処理」アクタ、および、もう1つの再構成では、低速で高解像度の処理を実行する「高品質処理」アクタで構成される再構成可能な処理チェーンの結果に従って決定される。現在の再構成の選択は、利用可能な場合に高解像度処理を使用することが好ましい「モード」アクタによって行われる。
グラフは、周波数制約、異なる再構成モード、および初期消費に使用可能な初期データを使用してデータストリームをモデル化する。円a1～a5は、データの処理を実行する、いわゆる一般的なアクタを表している。したがって、これらの一般的なアクタa1～a5は、データを消費することと、データを変換するために計算を実行することと、結果を生成することとを行うように適合されている。三角形a6およびa7は、周波数制約のあるデータを生成および消費する「クロック」a6または「期限」a7と呼ばれるアクタを表す。正方形a8は、シグナリングの再構成を担当する「モード」アクタa8を表す。有向アークc1～c10は単方向チャネルであり、それぞれが2つのアクタ間のデータストリームと、チャネル上で生成または消費されるデータの量を与える関連付けられる数値を示す。
この例によれば、モデル化されたシステムは、5つの一般的なアクタa1～a5(取得a1、前処理a2、高速処理a3、高品質処理a4、およびコマンドa5)、2つの一時的なアクタa6およびa7(クロックおよび期限)、ならびに1つのモードアクタa8で構成される。「取得」アクタa1は、クロックアクタa6によって提供されたデータを30Hzにおいて取得する。コマンドアクタa5は、10Hzにおいて期限アクチュエータアクタa7にコマンドを送信する。コマンドは、すべての可能な再構成において取得アクタa1によって生成されたデータの前処理を実行する別の一般的な「前処理」アクタa2で構成される再構成可能な処理チェーンの結果に従って決定される。第1の構成(λ1によって示されるモード)では、「高速処理」アクタa3(高速アクタ)は、前処理アクタa2によって前処理されたデータの高速および低解像度の処理を実行する。第2の再構成(λ2によって示されるモード)では、「高品質処理」アクタa4(低速アクタ)が低速であるが高解像度の処理を実行する。したがって、第1の構成λ1のデータ処理パスは、取得アクタa1を前処理アクタa2、高速処理アクタa3、次いで最後に制御アクタa5に接続するパスである。第2の構成λ2は、取得アクタa1を前処理アクタa2、低速処理アクタa4、次いで最後に制御アクタa5に接続するパスによって定義される。したがって、構成はあるアクタから別のアクタに伝播するため、これらの再構成モードでの集中同期は必要ない。各アクタは、動作する必要のある構成モードを近隣に通信する。現在の構成の選択は、可能な場合は高解像度処理を使用することが好ましいモードアクタa8によって行われる。
この例によれば、高速処理アクタa3は、アクティブ化されるたびに、その入力チャネルc3(チャネルc3では「1」によって表される)でデータの一部を消費し、その出力チャネルc4(チャネルc4では「1」によって表される)でデータの一部を生成する。同じことが、その入力チャネルc5においてデータの一部を消費し、その出力チャネルc6においてデータの一部を生成する低速処理アクタa4にも当てはまる。制御アクタa5は、その第1の入力チャネルc4またはその第2の入力チャネルc4(構成モードによって異なる)においてデータの一部を消費し、アクティブ化されるたびにその出力チャネルc2においてデータの一部を生成する。前処理アクタa2は、アクティブ化されるたびに、その第1の入力チャネルc1においてデータの一部を消費し、その第2の入力チャネルc9においてデータの一部を消費し、その第1の出力チャネルc3またはその第2の出力チャネルc5(構成モードによって異なる)においてデータの一部を生成する。
一方、取得アクタa1は、その入力チャネルc2(入力チャネルc2において値「1/3」によって表される)において有理数のデータを消費し、その出力チャネルc1(出力チャネルc1において値「1/3」によって表される)において有理数のデータを生成する。これは、取得アクタa1が3回のアクティベーションごとにデータの一部を消費または生成することを意味する。図2における例は、初期状態において、チャネルc2(制御アクタa5と取得アクタa1の間)で使用可能なトークンT1(すなわち、データの一部)があることを示している。次に、取得アクタa1は、このチャネルc2でこの既存のデータの一部を消費し、その出力チャネルc1(すなわち、取得アクタa1を前処理アクタa2に接続するチャネルc1)でデータの一部を生成する。したがって、取得アクタa1は、データの一部を消費し、データの一部を生成した。しかしながら、次の2つのアクティベーションにおいて、ゼロデータを消費し、ゼロデータを生成する。言い換えれば、取得アクタa1は、3回のアクティベーションごとにデータの一部を消費し、データの一部を生成する。これにより、データを失うことなく、異なる周波数において動作する2つのアクタ間でデータを同期することが可能になる。実際、この例によれば、取得はコマンドごとに3回表示されるため、データを失うことなく、30Hzにおいて動作する取得アクタa1と10Hzにおいて動作するコマンドアクタa5との間でデータを転送することができる。
以下では、形式モデル13を定義する要素を、図2における例を参照して要約する。この形式によれば、データストリームの仕様は、以下の要素F1～F9で構成される。
F1:データを処理する一般的なアクタa1～a5のセット、ならびにデータを処理する、および/または構成モードを選択するモードアクタa6およびa7のセットが定義される。
F2:アクタを相互に接続するチャネルのセットc1～c10が定義され、各アクタは少なくとも1つの入力または出力チャネルに関連付けられている。
F3:その入力チャネルまたは出力チャネルごとに各アクタによって生成または消費されるデータの数が定義され、チャネルがこれらの数のうちの1つだけを有理数にすることができるという利点がある。これらの数値は、アクタを接続するアークc1～c10の値によって表される。
F4:空でないモードのセットのモードアクタa8ごとに、モードアクタa8は、そのアクティベーションごとにこれらのモードの1つだけを動的に選択することを担当する(これらのモードはλ1およびλ2と表記される)。現在の構成の選択は、単一のa8モードアクタによって有利に行われ、この現在の構成は、あるアクタから別のアクタに分散された方法で伝播される。
F5:一般的なアクタa1～a5ごとに、それを実行するモードのセット、およびそれが通過する他のすべてのモードの暗黙のセットが定義される。一般的なアクタが実行するモードのセットは、システム全体に共通の公称モード、またはモードアクタによって選択されたモードのサブセットのいずれかである点に留意されたい。図2の例では、前処理アクタa2がモードλ1およびλ2において実行され、高速処理アクタa3がモードλ1において実行され、低速処理アクタa4がモードλ2において実行される限り、前処理a2、高速処理a3、および低速処理a4アクタを除くすべてのアクタが公称モードで実行される。
F6:異なるモードが与えられると、フィードバックチャネルの暗黙のセットは、同じモードアクタによって選択されたモードのうちの少なくとも1つにおいてそれぞれ実行される2つの一般的なアクタを接続するチャネルのセットとして定義され、したがって、モードアクタから始まり、そのチャネルの生成アクタで終わり、消費アクタを通過する非反復パスがある。
F7:最大周波数制約は、一部の一般的なまたはモードアクタに対して定義されている。それらを表現する1つの可能な方法は、周波数が関連付けられているいわゆるクロックアクタa6によるものである。図2の例において、取得アクタa1の最大周波数制約は30Hzであり、周波数30Hzのクロックアクタa6、それらを接続するアークc7、および関連付けられるデータ量によって表される。
F8:最小周波数制約は、一部の一般的なまたはモードアクタに対して定義されている。それらを表現する1つの可能な方法は、頻度を関連付ける、いわゆる期限アクタa7を使用することである。図2の例において、制御アクタa2の最小周波数制約は10Hzであり、周波数10Hzの期限アクタa7、それらを接続するアークc8、および関連付けられるデータ量によって表される。同じアクタが最小および最大周波数において動作するように制約される可能性がある点に留意されたい。その場合、それは正確な周波数制約である。言い換えれば、周波数制約は、最大(1秒あたりの回数以下)、最小(1秒あたりの回数以上)、または正確(1秒あたりの正確な回数)のいずれかである。
F9:システムの初期状態は、チャネルごとに、有理数、およびこの有理数を最も近い整数に切り捨てたものに等しい長さのモードのシーケンスで構成され、その初期モードの一般的なアクタごとに構成される。図2の例において、すべてのアクタの初期モードとして公称モードがあり、小さな円T1およびT2でマーク付けされたチャネルの初期状態は値「1」である。もちろん、初期状態は、任意の有理数(たとえば2/5、4/3など)によって表すことができ、これは、本発明の1つの有利な実施形態によれば、生成および消費率が合理的であるという事実に起因する。
以下のTable 1(表1)は、例として、図2の形式モデル13の実装に必要な構成データを示している。
Figure 2022516001000002
第1の行は、取得a1、前処理a2、高速処理a3、高品質処理a4、およびコマンドa5アクタの、5つの一般的なアクタを表している。
第2の行、第3の行、第4の行、第5の行は、それぞれ予算、初期遅延、初期期限、および入力期限のミリ秒単位の値を示している。第6の行、第7の行、および第8の行は、デフォルトの入力ポリシ、永続的/一時的インジケータ、および厳密な/緩和されたインジケータを示している。
値は通常、プラットフォームインテグレータによって課され、ここでは例としてのみ示されている。予算は、異なるタスクを実行するために各アクタに割り当てられる期間をミリ秒単位で指定する。初期遅延および初期期限は、異なるサンプルのルーティングと処理を考慮に入れるために、サンプルの通信および生成に必要な時間を示している。初期遅延がゼロの場合は、強制的なレイテンシの制約がなく、準備が整うとすぐにアクタが開始することを意味する。入力期限は、アクタの実装によって消費されるデータの到着期限を指定するため、アクタは、作業を開始する前に目的のデータを待機する待機時間を割り当てることができる。
この例におけるデフォルトの入力ポリシは、2種類のポリシを参照している。入力データがない場合、「無視」ポリシは置換データを生成せず、「以前の」ポリシは最後に受信した入力をコピーする。あるいは、同じデフォルト値を体系的に生成する第3の「デフォルト」ポリシを設定することもできる。
別の入力構成データの一部は、生成の欠如が障害として指定されているかどうかに関連している可能性がある。図2の例において、キャリブレーション要求が必須ではないため、コマンドアクタから取得アクタへの出力がないことだけが障害とは見なされない。
さらに、以下の説明において、サービス指向アーキテクチャにおける形式的な通信監視システムについてより具体的に説明する。言い換えれば、通信仕様15はサービス指向実装の仕様であり、通信機能はサービス指向機能である。
例として、サービス指向アーキテクチャは、AcquisitionService、PreprocessService、およびProcessServiceの3つのサービスで構成されていると見なされる。各サービスは、次のインターフェースを提供する。
- AcquisitionServiceは、センササンプルを生成するAcquisitionService::Samplesインターフェースを公開し、キャリブレーション要求を処理するためのAcquisitionService::Calibrateインターフェースを提供する。
- PreprocessServiceは、前処理されたサンプルを生成するインターフェースを公開し、再構成を実装するために、このインターフェースはPreprocessService::Samples1およびPreprocessService::Samples2インターフェースに複製され、これは現在の再構成に従って使用される。
- ProcessServiceは、処理されたサンプルを生成するProcessService::Samplesインターフェースを公開する。
各サービスの実装は、一意の識別子によって識別される。AcquisitionServiceの実装Acq1、PreprocessServiceの実装Pre1、およびProcessServiceの2つの実装Proc1とProc2がある。クライアントのみの実装Com1もある。これらの実装とモデル内のアクタとの間のリンクを次のTable 2(表2)に示す。
Figure 2022516001000003
モデルの5つのアクタを実装するソフトウェアは、異なるソフトウェアプロバイダによって作成することができる。このソフトウェアは、サービス指向の通信を確立するために通信機能を呼び出す。
例として、文書[4、5]に記載されている適応型自動車プラットフォームAutoSARのプログラミングインターフェースに関連する通信機能を以下に説明する。これらの通信機能は、サービス提供機能(OfferService)、インターフェース公開機能(PublishInterface)、公開インターフェースサブスクリプション機能(SubscribeInterface)、放出機能(Emit)、受信機能(Receive)、要求機能(Request)、およびインターフェース処理機能(Process)を含む。
OfferService関数(サービス識別子)を使用すると、呼出し元のソフトウェアを識別子に関連付けられる実装として識別することができる。
PublishInterface(インターフェース識別子)関数を使用すると、呼出し元のソフトウェアは、他のソフトウェアの識別子に関連付けられるインターフェースにアクセスすることができる。
SubscribeInterface(サービス識別子、インターフェース識別子)関数を使用すると、呼出し元のソフトウェアは、インターフェース識別子に関連付けられるインターフェースを通じて、サービス識別子に関連付けられるソフトウェアによって放出されたデータを受信することができる。
Emit(インターフェース識別子、データの一部)関数を使用すると、呼出し元のソフトウェアは、インターフェース識別子に関連付けられるインターフェースを通じて、提供されたデータの一部を放出することができ、これは、データストリームの形式モデル13においてトークンを生成することに相当する。
Receive関数(サービス識別子、インターフェース識別子)を使用すると、呼出し元のソフトウェアは、Receiveへの最後の呼出し以降に識別子に関連付けられるインターフェースを通じて送信されたデータを検索することができ、これは、データストリームの形式モデル13において参照されたデータと同じ数のトークンの消費に相当する。
Request(サービス識別子、インターフェース識別子、パラメータ)関数を使用すると、呼出し元のソフトウェアは、所与のパラメータを処理するために、インターフェース識別子に関連付けられる処理要求をサービス識別子に関連付けられるソフトウェアに送信し、要求が処理されると可能な結果を取り出すことができ、これは、データストリームの形式モデル13におけるトークンの生成に相当し、結果の抽出はトークンの消費に相当する。
Process(インターフェース識別子)関数を使用すると、呼出し元のソフトウェアは、識別されたインターフェースにおいて受信した要求のパラメータを取り出し、必要な処理を実行し、最終的には要求を送信したソフトウェアに結果を放出することができ、要求を取り出すことは、データストリームの形式モデル13においてトークンを消費することに相当し、結果を放出することは、トークンを生成することに相当する。
図3A～図3Cは、本発明の一実施形態による、形式モデルのアクタと通信仕様のサービス指向インターフェースの記述との間の対応を概略的に示している。
より具体的には、図3Aは、形式モデル13のグラフトポロジと、サービスを提供することと、インターフェースを公開することと、公開されたインターフェースにサブスクライブすることとを行うためのサービス指向インターフェースとの間の対応を示している。説明のために、この例では、取得a1と前処理a2の2つのアクタのみが考慮されている。取得a1アクタの挙動を実行するソフトウェアAcq1は、取得サービスに対応するPublishinterface(Samples)インターフェースを公開する。より具体的には、ソフトウェアAcq1はOfferService関数を呼び出し、次いでPublishInterface関数を呼び出して、データが公開される接続ポートを作成する。次いで、前処理アクタa2を実装するソフトウェアPre1は、生成されたサンプルを消費するためにソフトウェアAcq1のインターフェースにサブスクライブするために、SubscribeInterface関数を呼び出す。したがって、図3Aは、これらの異なる要素間の接続を行い、関数の呼出しが行われるときにデータストリームグラフを再描画することを可能にする。図3Aは、通信が実際に図2の形式モデル13のグラフに対応することを検証するための初期化フェーズに関する点に留意されたい。グラフが構築されると、図3Bによって説明されている第2の動作フェーズが開始される。
実際、図3Bは、形式モデル13のグラフのチャネルにおける生成/消費と、サービス指向インターフェースにおけるデータの放出/受信との間の対応を示している。ソフトウェアAcq1は、そのインターフェースにおいて定期的にEmit関数を呼び出し、このインターフェースにおいて具体的なデータの一部を提供する。前処理アクタを実装するソフトウェアPre1は、このデータの一部を消費するためにReceive関数を呼び出す。
図3Cは、形式モデル13のグラフのチャネルにおける生成/消費と、サービス指向インターフェースにおける要求の送信および処理との間の対応を示している。より具体的には、コマンドアクタを実装するソフトウェアCom1は、パラメータおよび要求識別子を使用して要求を送信し、これは、図2の形式モデルのグラフにおけるトークンの生成に対応する。一方、取得アクタのソフトウェアAcq1は、そのインターフェースにおいて要求を処理するためにProcess関数を呼び出す。
図3A～図3Cの例におけるアクタの実装の予期される挙動は次のとおりである。
- Acq1:上記の構成では、図2における形式モデル13の例は、取得アクタが3つの連続したアクティベーションを有し、第1のアクティベーションが0ミリ秒から20ミリ秒の間に行われる必要があり、その出力チャネルにおいてトークンを生成し、その入力チャネルにおいてトークンを消費する必要があると決定する。次の2つのアクティベーションは通信しない。したがって、実装の予期される挙動は、AcquisitionService::SamplesインターフェースにおいてEmit関数を1回呼び出し、AcquisitionService::Calibrateインターフェースの要求を0ミリ秒から20ミリ秒の間に処理するためにProcess関数を呼び出すことである。この挙動は、100ミリ秒から120ミリ秒、200ミリ秒から220ミリ秒などの間で繰り返される必要がある。
- Pre1:上記の構成では、図2における形式モデル13の例は、前処理アクタが0ミリ秒から50ミリ秒の間に行われる必要があるアクティベーションを有し、その入力チャネルにおいてトークンを消費し、出力チャネルのうちの1つにおいてデータを含むトークンと、他のチャネルにおいてデータを含まないトークンとを生成する必要があると決定する。可能な再構成を考慮に入れるために、この実装は、実装Proc2がOfferService関数を呼び出したかどうかを検証する。したがって、実装の予期される挙動は、データの一部を検索するためにAcq1のSamplesインターフェースにおいてReceive関数を呼び出すことと、Samples1インターフェースにおいて、またはSamples2インターフェースにおいて、0ミリ秒から50ミリ秒の間にSend関数を1回呼び出すこととを行うことである。この挙動は、100ミリ秒から150ミリ秒、200ミリ秒から250ミリ秒などの間で繰り返される必要がある。
- Proc1:上記の構成では、図2における形式モデル13の例は、高速処理アクタがその入力チャネルにおいてトークンを消費し、その出力チャネルにおいてトークンを生成する必要があるアクティベーションを有し、このトークンは、データを含むか、データを含まないと決定する。したがって、この実装の予期される挙動は、1つまたは0のデータの一部を検索するためにPre1のSamples1インターフェースにおいてReceive関数を呼び出し、そのSamplesインターフェースにおいて、データが実際に受信された場合にのみ、Emit関数を1回呼び出すことであり、これは0ミリ秒から90ミリ秒の間である。この挙動は、100ミリ秒から190ミリ秒、200ミリ秒から290ミリ秒などの間で繰り返される必要がある。
- Proc2:予期される挙動は、Receiveのインターフェースが、Pre1のSamples2インターフェースであることを除いて、Proc1と同じである。
- Com1:上記の構成では、図2における形式モデル13の例は、コマンドアクタは、その一方の入力チャネルにデータを含むトークンと、もう一方の入力チャネルにデータを含まないトークンを消費し、その出力チャネルにおいてトークンを生成する必要があるアクティベーションを有すると決定する。したがって、この実装の予期される挙動は、Proc1およびProc2のSamplesインターフェースにおいてReceive関数を呼び出して、どちらかのデータの一部を検索し、任意で、Calibrateインターフェースの要求関数を0ミリ秒から110ミリ秒の間に1回呼び出すことである。この挙動は、100ミリ秒から210ミリ秒、200ミリ秒から310ミリ秒などの間で繰り返される必要がある。
アクタの記述が定義されると、監視モジュール11は、この記述を入力として受け取り、サービス指向通信機能への呼出しシーケンスが、アクタの予期される挙動に従っていることを検証する。
監視モジュール11は、たとえば、オートマトン、ツリー、リスト、ネストされた条件を備えたコード選択、文法を備えた正規表現などを使用して、異なる技法に従って実装することができる点に留意されたい。
しかしながら、以下の説明では、オートマトンに基づくコード生成技法を例として考える。したがって、監視モジュール11は、実装の予期される挙動を記述するオートマトンを構築し、移行は上記の通信機能のうちの1つへの呼出しに対応する。
より具体的には、監視モジュール11は、アクタに対応するソフトウェア実装ごとにオートマトンを構築するように構成され、各オートマトンは、ある状態から別の状態への移行が、ソフトウェア実装から通信機能のうちの1つへの呼出しによってトリガされる状態のセットを備える。オートマトンは、ソフトウェア実装の通信機能への有効な呼出しシーケンスを追跡するために、形式モデルによって予期される挙動に依存する。
そのようなオートマトンの構築の例は、2つの部分に分割されたオートマトンの構築であり、1つはソフトウェア実装の初期化に対応し、もう1つは初期化された後の動作に対応し、プラットフォームの同期開始後にのみ許可される移行によって接続される。
実際、図4Aおよび図4Bは、本発明の一実施形態によるオートマトンの第1の部分および第2の部分の構築を概略的に示している。
より具体的には、図4Aは、オートマトンの第1の部分の構築を示している。この構築は、初期状態から始まり、次の場合にトリガされるいくつかの中間状態および移行を通じて最終状態に到達する。
- 実装が、この実装に関連付けられるサービス識別子を使用してOfferService関数を呼び出す。
- 実装が、OfferServiceへの呼出しが現在の状態にしたサービスのインターフェースに対応するインターフェース識別子を使用してPublishInterface関数を呼び出す。
- 実装が、そのサービス識別子に関連付けられるソフトウェアへの予期される接続に対応するインターフェースおよびサービス識別子を使用してSubscribeInterface関数を呼び出す。
より具体的には、図4Aにおける例は、図2の例における前処理アクタa2の実装Pre1に対して生成された初期化オートマトンを表している。初期化フェーズにおいて、実装は初期状態EI0(黒丸によって表される)にある。オートマトンは任意の関数を呼び出すことができるが、OfferService関数を呼び出すまで、前処理アクタの実装Pre1として認識されない。前処理アクタの実装Pre1として識別されると、Samples1またはSamples2インターフェースのいずれかをEI1状態に公開することができる。Samples1インターフェースを公開することから始めた場合、Samples2インターフェース(状態EI2)を公開する。一方、Samples2インターフェースを公開することから開始した場合、Samples1インターフェース(状態EI3)を公開する。これらのインターフェースを公開すると、インターフェースAcq1(状態EI4)にサブスクライブでき、最後に、状態EI5において、終了したと見なされる。
この場合、オートマトンの第1の部分の最終状態から第2の部分の初期状態への移行は、プラットフォーム上での具体的なアプリケーションの実行を示す同期信号(すなわち、システムの起動を示す)が実装によって受信されたときに可能である。
さらに、図4Bにおける例によれば、オートマトンの第2の部分の構築は、第2の部分の初期状態から始まり、以下の場合にトリガされるいくつかの中間状態および移行を通じてこの状態に戻る。
- 実装が、以前に公開されたインターフェース識別子を使用してEmit関数を呼び出し、すでに放出されたデータの量は、そのインターフェースで予期される量を超えない。
- 実装が、以前にサブスクライブされたインターフェース識別子を使用してReceive関数を呼び出し、すでに受信されたデータの量は、そのインターフェースで予期される量を超えない。
- 実装が、モデルにおける出力チャネルに対応するサービスおよびインターフェース識別子を使用してRequest関数を呼び出し、すでに送信された要求の数は、このインターフェースで予期される量を超えない。
- 実装が、モデルにおける入力チャネルに対応するインターフェース識別子を使用してProcess関数を呼び出し、すでに処理された要求の数は、このインターフェースで予期される量を超えない。
- 現在のアクティベーションの期限が過ぎた。
より具体的には、図4Bにおける例は、前処理アクタの実装Pre1に対して生成された動作オートマトンを表している。
初期動作状態EF0(黒丸によって表される)では、オートマトンはReceive関数を呼び出すことができ、サンプルを受信しない限り、初期状態EF0に戻る。
Receive関数を呼び出してサンプルを受信すると、オートマトンは状態EF1に移行する。状態EF1において、オートマトンは、初期状態EF0に戻る前に、Samples1インターフェースにおいてサンプルを送信するか、Samples2インターフェースにおいてサンプルを放出する。しかしながら、状態EF1において期限違反が検出された場合、オートマトンはその初期状態EF0に直接戻る。
一方、Receiveで開始する代わりに、オートマトンがEmit関数を呼び出すことによって開始する場合、オートマトンは状態EF2に移行する。状態EF2において、オートマトンは、その初期状態EF0に戻る前に、Samples1インターフェースにおいてサンプルを放出するか、Samples2インターフェースにおいてサンプルを放出する。さらに、サンプルを受信しない限り、状態EF2に戻る。以前と同様に、状態EF2において期限違反が検出された場合、オートマトンはその初期状態EF0に直接戻る。
したがって、実装Pre1用に作成された動作オートマトンは、その前処理アクタの挙動に対応する有効な通信機能のシーケンスを記述する。
このオートマトンが構築されると、監視モジュールは、通信機能呼出しをキャプチャするように構成されたソフトウェア要素を生成し、具体的なアプリケーションの実行時に行われる呼出しのシーケンスがオートマトンによって定義されたシーケンスに対応することを確認する。
ソフトウェア要素は、次のソフトウェア要素を含む。
- 上記の各通信機能の各々の拡張機能。ソフトウェア呼出しが行われるたびに、その呼出しに対応する現在の状態からの発信移行があるかどうかを決定するために、各拡張機能がオートマトンに照会する。そのような移行がある場合、拡張機能は元の関数を呼び出す。そのような移行がない場合、拡張機能は、必要に応じて障害を登録し、許可されている場合は障害処理の直後に戻る。特定のケースは、アクセスされたデータの数が事前に知られていないReceive関数に関連している。この関数の拡張バージョンでは、最大で指定された量のデータをアプリケーションで使用できるようになり、任意の追加のデータは、使用可能になったときに次のアクティベーションを待つためにバッファリングされる。したがって、1回のアクティベーションでReceiveへの複数の呼出しが可能であるが、検索されるデータの数が指定された数を超えることはない。
- 入力データの期限を管理するための機能。初期状態を通過するたびに、次のアクティベーションの入力データを受信する期限が計算され、その日に呼び出されるように関数がプログラムされる。この方法で関数が呼び出されると、必要に応じて障害が記録され、障害処理ポリシが実装される。たとえば、実装Pre1の場合、最後に受信したサンプルの値は、受信したかのように使用可能になる。
- 現在のアクティベーションの期限を管理するための機能。初期状態を通過するたびに、次のアクティベーションの期限が計算され、その日に呼び出されるように関数がプログラムされる。この方法で関数が呼び出されると、新しいアクティベーションを開始するためにオートマトンの現在の状態を更新し、許可されている場合は障害管理の直後に戻る。
監視モジュールは、プラットフォームのすべての実装の初期化フェーズから動作フェーズへの移行を許可することを担当するソフトウェアも生成するように構成されている。監視モジュールが同期された起動を許可しない限り、アクタ実装ソフトウェアは動作フェーズに入ることができない。このコードは、たとえば、ソフトウェアのサブセットが動作する準備ができるのを待つか、期限を管理することができる。このコードは、サービス指向ソフトウェアプラットフォームにおいて一般的に利用可能な、ソフトウェア間の時刻同期のための既存の技術に依存している。
したがって、本発明は、標準関数を呼び出す標準プログラミングインターフェースから、プログラミングインターフェースソフトウェアを修正することなく、呼出しが正しい順序で、予期される挙動に従って行われることを確実にすることを可能にする。これにより、独自の方法論を使用しながら、標準ソフトウェアサプライヤからインテグレータを提供できるようになる。
本発明は、すべてのデータストリームシステムに適用可能である。第1のアプリケーションは、リアルタイムの重要な分散システムに関連する。特に、機器とその環境に固有の測定値を受信し、その機器が適切に動作するように動作を作動させる結果をもたらすように構成された、機器のリアルタイム搭載システムである。機器は、陸上、鉄道、航空宇宙、または海軍タイプの自律型または非自律型の車両であり得る。
特に、車両データストリームシステムの範囲内で、本発明によれば、異なる周波数および異なる構成で動作するセンサおよびプロセッサを有することが有利である。さらに、ドライバーがいる車の場合、特定の速度からの歩行者の検出が興味深い例と見なすことができる。したがって、歩行者検出処理が特定の速度から、または特定の範囲の速度にわたって行われるように、異なる再構成モードを使用して、マイクロプロセッサがこの範囲外の実行リソースを不必要に消費しないようにすることができる。
第2のアプリケーションは、リアルタイムの重要度を実現するFPGAシステムに関連している。FPGAシステムは、処理装置をトリガするクロックによってタイミングが調整されるデータストリームであり、データのルーティングを動的に変更することができる。
第3のアプリケーションは、特定のスループット制約に従って、および再構成可能な処理に従って、オブジェクトの工業的製造のために構成された工業的処理のシステムに関する。実際、工業的製造方法は、技術的な理由からフローの制約があるデータストリームと見なすことができる。
(参考文献)
1 監視システム
3 計算機またはコンピュータ
5 マイクロプロセッサ
7 メモリ
9 取得モジュール
11 監視モジュール
13 形式モデル
15 通信仕様

Claims (13)

  1. プラットフォームの具体的なアプリケーションのセットの通信を形式的に監視するためのシステムであって、
    - 一方向通信チャネルを通じて、定量化可能な情報を相互に交換するアクタのセットを備えるデータストリームの形式モデルであって、前記形式モデルが、具体的なアプリケーションの前記セットをモデル化するアクタの前記セットの挙動を記述する、形式モデル、および、前記アクタによってモデル化された前記アプリケーションを実装するソフトウェア実装を記述する通信仕様であって、前記ソフトウェア実装が、前記プラットフォームのプログラミングインターフェースに関連するあらかじめ決定された通信機能を呼び出すように構成された、通信仕様を取得するように構成された取得モジュールと、
    - 前記通信機能への呼出しのシーケンスが、アクタの前記セットの予期される挙動に従っていることを検証するように構成された監視モジュール(11)と
    を備えることを特徴とする、システム。
  2. 前記監視モジュール(11)が、アクタに対応するソフトウェア実装ごとにオートマトンを構築するように構成され、各オートマトンが、ある状態から別の状態への移行が、前記ソフトウェア実装から前記通信機能のうちの1つへの呼出しによってトリガされる状態のセットを備え、前記オートマトンが、前記通信機能への有効な呼出しシーケンスを追跡するために、前記形式モデルによって予期される挙動に依存していることを特徴とする、請求項1に記載のシステム。
  3. 各オートマトンが、前記ソフトウェア実装の初期化に関連付けられる第1の部分と、前記ソフトウェア実装の動作に関連付けられる第2の部分とを備え、前記第1の部分の最終状態から前記第2の部分の初期状態への前記移行が、同期信号が前記ソフトウェア実装によって受信されたときにトリガされ、具体的なアプリケーションの実行を示すことを特徴とする、請求項2に記載のシステム。
  4. 前記監視モジュール(11)が、通信機能への呼出しをキャプチャするように構成されたソフトウェア要素を生成することと、具体的なアプリケーションの実行時に行われる呼出しの前記シーケンスが前記オートマトンによって定義された前記シーケンスに対応することを確認することとを行うように構成されることを特徴とする、請求項2または3に記載のシステム。
  5. 前記ソフトウェア要素が、前記通信機能ごとの拡張機能、入力データ期限管理機能、および現在のアクティベーション管理機能を備えることを特徴とする、請求項4に記載のシステム。
  6. 前記通信仕様が、サービス指向実装の仕様であることを特徴とする、請求項1から5のいずれか一項に記載のシステム。
  7. 前記通信機能が、サービス指向であり、サービス提供機能、インターフェース公開機能、公開インターフェースサブスクリプション機能、放出機能、受信機能、要求機能、およびインターフェース上の処理機能を備えることを特徴とする、請求項1から6のいずれか一項に記載のシステム。
  8. 前記形式モデルが、前記アクタの前記実装に必要な構成データのセットを備えることを特徴とする、請求項1から7のいずれか一項に記載のシステム。
  9. 前記構成データが、前記アクタごとに、予算、初期遅延、初期期限、入力期限、デフォルトの入力ポリシ、永続的/一時的インジケータ、および厳密な/緩和されたインジケータデータを備えることを特徴とする、請求項8に記載のシステム。
  10. 前記通信仕様が、ソフトウェア実装と前記形式モデルにおけるアクタとの間のリンクを備えることを特徴とする、請求項1から9のいずれか一項に記載のシステム。
  11. 請求項1から10のいずれか一項に記載の監視システムを使用して設計されたリアルタイムの搭載機器であって、前記搭載機器が、その環境に固有の測定値を受信し、機能的動作を作動させる結果をもたらすように構成されることを特徴とする、リアルタイムの搭載機器。
  12. 前記機器が、陸上、鉄道、航空宇宙、または海軍タイプの自律型または非自律型の車両であることを特徴とする、請求項11に記載の機器。
  13. 具体的なアプリケーションのセットの通信を形式的に監視するための方法であって、
    - 一方向通信チャネルを通じて、定量化可能な情報を相互に交換するアクタのセットを備えるデータストリームの形式モデルであって、前記形式モデルが、具体的なアプリケーションの前記セットをモデル化するアクタのセットの挙動を記述する、形式モデル、および、前記アクタによってモデル化された前記アプリケーションを実装するソフトウェア実装を記述する通信仕様であって、前記ソフトウェア実装が、前記プラットフォームの前記プログラミングインターフェースに関連するあらかじめ決定された通信機能を呼び出すように構成された、通信仕様を取得するステップと、
    - 前記通信機能への呼出しのシーケンスが、アクタの前記セットの予期される挙動に従っていることを検証するステップと
    を含むことを特徴とする、方法。
JP2021535802A 2018-12-20 2019-12-19 通信を形式的に監視するためのシステム Active JP7490656B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
FR1873585A FR3091106B1 (fr) 2018-12-20 2018-12-20 Système de supervision formelle de communications
FR1873585 2018-12-20
PCT/FR2019/053201 WO2020128363A1 (fr) 2018-12-20 2019-12-19 Système de supervision formelle de communications

Publications (3)

Publication Number Publication Date
JP2022516001A true JP2022516001A (ja) 2022-02-24
JPWO2020128363A5 JPWO2020128363A5 (ja) 2024-04-02
JP7490656B2 JP7490656B2 (ja) 2024-05-27

Family

ID=66867261

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2021535802A Active JP7490656B2 (ja) 2018-12-20 2019-12-19 通信を形式的に監視するためのシステム

Country Status (5)

Country Link
US (1) US20220250560A1 (ja)
EP (1) EP3881515B1 (ja)
JP (1) JP7490656B2 (ja)
FR (1) FR3091106B1 (ja)
WO (1) WO2020128363A1 (ja)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2023060524A1 (zh) * 2021-10-15 2023-04-20 华为技术有限公司 车载应用的参数标定方法、装置和车辆

Family Cites Families (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8161081B2 (en) * 2001-03-16 2012-04-17 Michael Philip Kaufman System and method for generating automatic user interface for arbitrarily complex or large databases
US7739240B2 (en) * 2002-12-09 2010-06-15 Hewlett-Packard Development Company, L.P. Replication and replica management in a wide area file system
US7900194B1 (en) * 2004-03-25 2011-03-01 Verizon Corporate Services Group Inc. Kernel-based intrusion detection using bloom filters
US8015235B1 (en) * 2006-01-03 2011-09-06 Emc Corporation Group services
DE602007006476D1 (de) * 2007-08-17 2010-06-24 Aitment Gmbh X Spielgleichgewichtswerkzeug
JP5107131B2 (ja) * 2008-04-28 2012-12-26 株式会社東芝 テストケース生成装置およびその生成方法、ならびにテストケース生成のためのプログラム
JP5298967B2 (ja) * 2009-03-06 2013-09-25 富士通株式会社 検証支援プログラム、情報処理装置および検証支援方法
JP5524244B2 (ja) 2010-02-02 2014-06-18 株式会社日立製作所 仕様モデル検査方法および仕様モデル検査装置
US8839197B2 (en) 2010-10-11 2014-09-16 International Business Machines Corporation Automated analysis of composite applications
US8984490B1 (en) * 2010-10-26 2015-03-17 Interactive TKO, Inc. Modeling and testing of interactions between components of a software system
US9335977B2 (en) * 2011-07-28 2016-05-10 National Instruments Corporation Optimization of a data flow program based on access pattern information
US8856291B2 (en) * 2012-02-14 2014-10-07 Amazon Technologies, Inc. Providing configurable workflow capabilities
US9684524B1 (en) * 2013-12-20 2017-06-20 Amazon Technologies, Inc. Service-oriented system optimization using trace data
US9852294B1 (en) * 2014-06-24 2017-12-26 Symantec Corporation Systems and methods for detecting suspicious applications based on how entry-point functions are triggered
WO2016151710A1 (ja) 2015-03-20 2016-09-29 株式会社日立製作所 仕様構成装置および方法
US10346140B2 (en) * 2015-08-05 2019-07-09 General Electric Company System and method for model based technology and process for safety-critical software development
US10579753B2 (en) * 2016-05-24 2020-03-03 Ab Initio Technology Llc Executable logic for processing keyed data in networks
US20210248514A1 (en) * 2018-05-06 2021-08-12 Strong Force TX Portfolio 2018, LLC Artificial intelligence selection and configuration
US20200372315A1 (en) * 2019-05-22 2020-11-26 GM Global Technology Operations LLC System and method for carrying out a vehicle action based on a sensor tag state
US11880271B2 (en) * 2020-03-27 2024-01-23 VMware LLC Automated methods and systems that facilitate root cause analysis of distributed-application operational problems and failures
US11379198B1 (en) * 2020-12-14 2022-07-05 Sap Se Call graph enhancement using stitching algorithm

Also Published As

Publication number Publication date
US20220250560A1 (en) 2022-08-11
WO2020128363A1 (fr) 2020-06-25
FR3091106A1 (fr) 2020-06-26
FR3091106B1 (fr) 2021-02-12
EP3881515B1 (fr) 2023-08-16
JP7490656B2 (ja) 2024-05-27
EP3881515A1 (fr) 2021-09-22

Similar Documents

Publication Publication Date Title
US11093227B1 (en) Computer-automated software release and deployment architecture
US11157253B1 (en) Computer-automated software release and deployment architecture
Hellmund et al. Robot operating system: A modular software framework for automated driving
US9172589B2 (en) Method for configuring a distributed avionics control system
US11294711B2 (en) Wait a duration timer action and flow engine for building automated flows within a cloud based development platform
US11966731B2 (en) Method for real-time updating of process software
US11263404B2 (en) Conversational AI platform using declarative graph model
RU2605918C2 (ru) Способ предоставления функций в промышленной системе автоматизации и промышленная система автоматизации
FR2964224A1 (fr) Procede et dispositif de deploiement et d'aide au deploiement de composants formant un systeme temps reel embarque
Chardet et al. Toward safe and efficient reconfiguration with concerto
JP2022516001A (ja) 通信を形式的に監視するためのシステム
Paunicka et al. A CORBA-based middleware solution for UAVs
CN113268332B (zh) 持续集成方法及装置
CN115220698A (zh) 一种实时数据智能检测方法、装置及计算机设备
Ferry et al. Models@ runtime for continuous design and deployment
Santos et al. An IEC 61499 replication for distributed control applications
Otto Enabling Reproducibility in ROS 2 by Ensuring Sequence Deterministic Callback Execution
KR102600294B1 (ko) 차량용 플랫폼을 위한 arinc 기반 운영체제 헬스 모니터링 설정 코드 자동 생성 장치 및 방법
Buit PC104 stack mechatronic control platform
US9342382B2 (en) Program processing method, program processing apparatus, and computer program
Webel et al. Developing reliable systems with SDL design patterns and design components
WO2023147017A1 (en) Component management system and method
CN115033251A (zh) 软件部署方法、装置、电子设备和存储介质
JP6674039B2 (ja) ストリームデータの分散処理方法、ストリームデータの分散処理システム及び記憶媒体
Gamarra et al. Grant agreement no. 780785 Project acronym OFERA (micro-ROS) Project full title Open Framework for Embedded Robot Applications Deliverable number D3. 4 Deliverable name Micro-ROS middleware interface

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20221219

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20231130

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20240321

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20240422

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20240515

R150 Certificate of patent or registration of utility model

Ref document number: 7490656

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150