特許 7350192 マルチコアシステムオンチップ処理アーキテクチャーにおいてデータを処理する方法、マルチコアシステムオンチップデバイス及び記憶媒体

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2023-09-14

(45)【発行日】2023-09-25

(54)【発明の名称】マルチコアシステムオンチップ処理アーキテクチャーにおいてデータを処理する方法、マルチコアシステムオンチップデバイス及び記憶媒体

(51)【国際特許分類】

   G06F 13/10 20060101AFI20230915BHJP

   G06F 15/78 20060101ALI20230915BHJP

   G06F 9/48 20060101ALI20230915BHJP

【ＦＩ】

G06F13/10 330B

G06F15/78 530

G06F9/48 300F

【請求項の数】 15

(21)【出願番号】P 2022555257

(86)(22)【出願日】2020-11-17

(65)【公表番号】

(43)【公表日】2023-01-25

(86)【国際出願番号】 JP2020044130

(87)【国際公開番号】W WO2021171719

(87)【国際公開日】2021-09-02

【審査請求日】2022-05-12

(31)【優先権主張番号】20305196.6

(32)【優先日】2020-02-27

(33)【優先権主張国・地域又は機関】EP

(73)【特許権者】

【識別番号】503163527

【氏名又は名称】ミツビシ・エレクトリック・アールアンドディー・センター・ヨーロッパ・ビーヴィ

【氏名又は名称原語表記】ＭＩＴＳＵＢＩＳＨＩ ＥＬＥＣＴＲＩＣ Ｒ＆Ｄ ＣＥＮＴＲＥ ＥＵＲＯＰＥ Ｂ．Ｖ．

【住所又は居所原語表記】Ｃａｐｒｏｎｉｌａａｎ ４６， １１１９ ＮＳ Ｓｃｈｉｐｈｏｌ Ｒｉｊｋ， Ｔｈｅ Ｎｅｔｈｅｒｌａｎｄｓ

(74)【代理人】

【識別番号】100110423

【弁理士】

【氏名又は名称】曾我 道治

(74)【代理人】

【識別番号】100111648

【弁理士】

【氏名又は名称】梶並 順

(74)【代理人】

【識別番号】100122437

【弁理士】

【氏名又は名称】大宅 一宏

(74)【代理人】

【識別番号】100147566

【弁理士】

【氏名又は名称】上田 俊一

(74)【代理人】

【識別番号】100161171

【弁理士】

【氏名又は名称】吉田 潤一郎

(72)【発明者】

【氏名】ロレ、ロマン

【審査官】田中 啓介

(56)【参考文献】

【文献】特表２００７－５００３８１（ＪＰ，Ａ）

【文献】国際公開第２０１９／０２６１３９（ＷＯ，Ａ１）

【文献】特開２０１２－００３７４７（ＪＰ，Ａ）

【文献】米国特許出願公開第２００９／００８３５１６（ＵＳ，Ａ１）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｆ１３／００－１３／１４

Ｇ０６Ｆ１５／１６－１５／１７７、１５／７８

Ｇ０６Ｆ９／４５５－９／５４

(57)【特許請求の範囲】

【請求項1】

マルチコアシステムオンチップ（ＳＯＣ）処理アーキテクチャーにおいてデータを処理する方法であって、
前記ＳＯＣの媒体アクセスコントローラー（ＭＡＣ）からリアルタイムオペレーティングシステム（ＲＴＯＳ）のネットワークインターフェースコントローラー（ＮＩＣ）において入力フレームを受信することであって、前記ＲＴＯＳは前記ＳＯＣの第１のコアにおいて実装されることと、
前記入力フレームを前記ＲＴＯＳの前記ＮＩＣから前記ＲＴＯＳのフレームプロセッサに送信することと、
少なくとも、ＲＴＯＳタスクに関係付けられた第１のクラスと、非ＲＴＯＳタスクに関係付けられた第２のクラスとを含む分類に従って、前記フレームプロセッサにおいて前記入力フレームを構文解析及び分類することと、
前記第１のクラスに分類された入力フレームを、前記フレームプロセッサから、前記ＲＴＯＳのシーケンサーによって実行される１つ以上のタスクに送信することと、
前記第２のクラスに分類された入力フレームを、前記フレームプロセッサから、前記ＳＯＣの第２のコアにおいて実装される第２のオペレーティングシステム（ＯＳ）のネットワークデバイスドライバーに送信することであって、前記第２のＯＳは、カーネル空間とユーザー空間とを備えることと、
前記第１のコアにおいて、前記ＲＴＯＳの前記シーケンサーによって実行される前記１つ以上のタスクに送信される前記入力フレームを処理すると共に、前記第２のコアにおいて、前記第２のＯＳの前記ネットワークデバイスドライバーに送信される前記入力フレームを処理することと、
ＲＴＯＳタスクに関係付けられた出力フレームを、前記ＲＴＯＳの前記シーケンサーによって実行される前記１つ以上のタスクから、前記フレームプロセッサに送信することと、
非ＲＴＯＳタスクに関係付けられた出力フレームを、前記第２のＯＳの前記ネットワークデバイスドライバーから前記フレームプロセッサに送信することと、
前記フレームプロセッサにおいて前記出力フレームを分類及びスケジューリングすることと、
前記スケジューリングされた出力フレームを、前記フレームプロセッサから前記ＮＩＣに送信すると共に、前記スケジューリングされた出力フレームを前記ＮＩＣから前記ＭＡＣに送信することと、
を含む、方法。

【請求項2】

前記ＲＴＯＳは、前記ＳＯＣの追加のコアにおいて実装される、請求項１に記載の方法。

【請求項3】

他のＲＴＯＳタスクに関係付けられた１つ以上の他のクラスを含む分類に従って、前記フレームプロセッサにおいて前記入力フレームを構文解析及び分類することと、
前記１つ以上の他のクラスに分類された入力フレームを、前記フレームプロセッサから、１つ以上の専用の他のＲＴＯＳの１つ以上の専用の他のシーケンサーによって実行される１つ以上のタスクに送信することであって、前記１つ以上の専用の他のＲＴＯＳは、前記ＳＯＣの１つ以上の専用コアにおいて実装されることと、
を更に含む、請求項１又は２に記載の方法。

【請求項4】

前記第２のＯＳは、前記ＳＯＣの追加のコアにおいて実装される、請求項１～３のいずれか１項に記載の方法。

【請求項5】

非ＲＴＯＳタスクに関係付けられた１つ以上の更なるクラスを含む分類に従って、前記フレームプロセッサにおいて前記入力フレームを構文解析及び分類することと、
前記１つ以上の更なるクラスに分類された入力フレームを、前記フレームプロセッサから、前記ＳＯＣの１つ以上の専用の更なるコア上で実装される１つ以上の専用の更なるＯＳの１つ以上の専用の更なるネットワークデバイスドライバーに送信することであって、前記１つ以上の専用の更なるＯＳは、専用の更なるカーネル空間及び専用の更なるユーザー空間を含むことと、
を更に含む、請求項１～４のいずれか１項に記載の方法。

【請求項6】

前記第２のＯＳの前記ネットワークデバイスドライバーにおいて、前記ＲＴＯＳの前記フレームプロセッサから排他的に送信された入力フレームを受信することを更に含む、請求項１～５のいずれか１項に記載の方法。

【請求項7】

前記第２のＯＳの前記ネットワークデバイスドライバーによって、出力フレームを、前記ＲＴＯＳの前記フレームプロセッサに排他的に送信することを更に含む、請求項１～６のいずれか１項に記載の方法。

【請求項8】

前記ＲＴＯＳによって、及び前記第２のＯＳのカーネルによって、フレームデータを記憶するバッファーを共有することを更に含む、請求項１～７のいずれか１項に記載の方法。

【請求項9】

前記第２のＯＳからＲＴＯＳバッファーへのアクセスを防ぐことを更に含む、請求項１～７のいずれか１項に記載の方法。

【請求項10】

前記入力フレームを分類することは、
前記フレームプロセッサによって、分類規則に従って、ストリームクラス識別子を前記入力フレームにアタッチすることと、
前記入力フレーム及び前記アタッチされたストリームクラス識別子を、前記フレームプロセッサのキュー識別モジュールに渡すことと、
を更に含む、請求項１～９のいずれか１項に記載の方法。

【請求項11】

前記フレームプロセッサは、動的に定義された分類規則を適用している、請求項１～１０のいずれか１項に記載の方法。

【請求項12】

前記第２のＯＳのカーネル及び前記ＲＴＯＳのアプリケーションの一方又は双方が、前記分類規則を動的に定義することに寄与している、請求項１１に記載の方法。

【請求項13】

前記フレームプロセッサにおいて前記出力フレームを分類及びスケジューリングすることは、
前記フレームプロセッサによって、分類規則に従って、ストリームクラス識別子を前記出力フレームにアタッチすることと、
前記スケジューリングされた出力フレームのフレーム送信について、前記出力フレームの前記アタッチされたストリームクラスの時間及び優先度の双方に依拠して、スケジューリング規則を前記出力フレームに適用することと、
を含む、請求項１～１２のいずれか１項に記載の方法。

【請求項14】

処理コアとメモリとを備えるマルチコアシステムオンチップ（ＳＯＣ）デバイスであって、前記処理コアは、請求項１～１３のいずれか１項に記載のように動作するように構成される、マルチコアシステムオンチップ（ＳＯＣ）デバイス。

【請求項15】

マルチコアシステムオンチップ（ＳＯＣ）デバイスの処理コアによって実行されると、該処理コアに請求項１～１３のいずれか１項に記載の方法を実行させる命令を含むコンピューター可読記憶媒体。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、コンピューティングアーキテクチャーの分野、特にマルチコアシステムオンチップアーキテクチャーの分野に関する。

【背景技術】

【0002】

マルチコアシステムオンチップアーキテクチャーは、特定のシステムオンチップにおいていくつかのオペレーティングシステムを実行することを可能にし、各オペレーティングシステムは１つ以上のコアを用いて動作することができる。そのようなマルチコアシステムは、同種とすることができ、複数の同一コアを含むことができるか、又は異なるコアタイプを含み、異種とすることができる。そのようなマルチコアシステムは、コンピューティングアーキテクチャーに関して柔軟性を提供する。

【発明の概要】

【0003】

本発明は、添付の独立請求項によって定義される。本明細書において開示される概念の更なる特徴及び利点は、以下に続く説明において記載される。

【0004】

本開示は、マルチコアシステムオンチップ（ＳＯＣ）処理アーキテクチャーにおいてデータを処理する方法であって、
ＳＯＣの媒体アクセスコントローラー（ＭＡＣ）からリアルタイムオペレーティングシステム（ＲＴＯＳ）のネットワークインターフェースコントローラー（ＮＩＣ）において入力フレームを受信することであって、ＲＴＯＳはＳＯＣの第１のコアにおいて実装されることと、
入力フレームをＲＴＯＳのＮＩＣからＲＴＯＳのフレームプロセッサに送信することと、
少なくとも、ＲＴＯＳタスクに関係付けられた第１のクラスと、非ＲＴＯＳタスクに関係付けられた第２のクラスとを含む分類に従って、フレームプロセッサにおいて入力フレームを構文解析及び分類することと、
第１のクラスに分類された入力フレームを、フレームプロセッサから、ＲＴＯＳのシーケンサーによって実行される１つ以上のタスクに送信することと、
第２のクラスに分類された入力フレームを、フレームプロセッサから、ＳＯＣの第２のコアにおいて実装される第２のオペレーティングシステム（ＯＳ）のネットワークデバイスドライバーに送信することであって、第２のＯＳは、カーネル空間とユーザー空間とを備えることと、
第１のコアにおいて、ＲＴＯＳのシーケンサーによって実行されるタスクに送信される入力フレームを処理すると共に、第２のコアにおいて、第２のＯＳのネットワークデバイスドライバーに送信される入力フレームを処理することと、
ＲＴＯＳタスクに関係付けられた出力フレームを、ＲＴＯＳのシーケンサーによって実行されるタスクから、フレームプロセッサに送信することと、非ＲＴＯＳタスクに関係付けられた出力フレームを、第２のＯＳのネットワークデバイスドライバーからフレームプロセッサに送信することと、
フレームプロセッサにおいて出力フレームを分類及びスケジューリングすることと、
スケジューリングされた出力フレームを、フレームプロセッサからＮＩＣに送信すると共に、ＮＩＣからＭＡＣに送信することと、
を含む、方法を記載する。

【0005】

そのようなアーキテクチャーは、同じマルチコアＳＯＣにおいて、ＲＴＯＳを用いて、例えばタイムセンシティブネットワーキング（ＴＳＮ）規格に準拠したプロセス等のタイムセンシティブなプロセスを実行し、第２のＯＳにおいて、他のよりタイムセンシティブでないプロセスを実行することを可能にする。これは、入力フレーム及び出力フレームのハンドリングが、ＲＴＯＳのＮＩＣ及びフレームプロセッサ等のＲＴＯＳのコンポーネントを通じて集中型で行われることを確実にすることによって達成される。本開示において、ＴＳＮは、ＩＥＥＥ８０２．１ワーキンググループの一部であるタイムセンシティブネットワーキングタスクグループによって指定された規格のセットである。

【0006】

選択的には、ＲＴＯＳは、ＳＯＣの追加の第１のコアにおいて実装される。これにより、入力フレーム及び出力フレームの中央制御されたハンドリングを解除することなく、ＲＴＯＳのための増大した処理能力を得ることを可能にすることができる。

【0007】

選択的には、方法は、
他のＲＴＯＳタスクに関係付けられた１つ以上の他のクラスを含む分類に従って、フレームプロセッサにおいて入力フレームを構文解析及び分類することと、
１つ以上の他のクラスに分類された入力フレームを、フレームプロセッサから、１つ以上の専用の他のＲＴＯＳの１つ以上の専用の他のシーケンサーによって実行される１つ以上のタスクに送信することであって、１つ以上の専用の他のＲＴＯＳは、ＳＯＣの１つ以上の専用コアにおいて実装されることと、
を更に含む。

【0008】

そのような場合、ＲＴＯＳタスクの分類の粒度を上げることにより、いくつかのＲＴＯＳにわたるそのようなタスクの処理を並列化することを可能にすることができ、各ＲＴＯＳは少なくとも１つの専用処理コアから利益を得る。

【0009】

選択的には、第２のＯＳは、ＳＯＣの追加の第２のコアにおいて実装される。そのような構成は、第２のＯＳの処理帯域幅を増大することを可能にすることができる。

【0010】

選択的には、方法は、
非ＲＴＯＳタスクに関係付けられた１つ以上の更なるクラスを含む分類に従って、フレームプロセッサにおいて入力フレームを構文解析及び分類することと、
１つ以上の更なるクラスに分類された入力フレームを、フレームプロセッサから、ＳＯＣの１つ以上の専用の更なるコア上で実装されている１つ以上の専用の更なるＯＳの１つ以上の専用の更なるネットワークデバイスドライバーに送信することであって、１つ以上の専用の更なるＯＳは、専用の更なるカーネル空間及び専用の更なるユーザー空間を含むことと、
を更に含む。

【0011】

そのような場合、非ＲＴＯＳタスクの分類の粒度を上げることにより、いくつかのＯＳにわたるそのようなタスクの処理を並列化することを可能にすることができ、各ＯＳは少なくとも１つの専用処理コアから利益を得る。

【0012】

選択的には、方法は、第２のＯＳのネットワークデバイスドライバーにおいて、ＲＴＯＳのフレームプロセッサから排他的に送信された入力フレームを受信することを更に含む。これにより、入力フレームの制御がＲＴＯＳのフレームプロセッサによって集中化されることを確実にすることができる。

【0013】

選択的には、方法は、第２のＯＳのネットワークデバイスドライバーによって、出力フレームを、ＲＴＯＳのフレームプロセッサに排他的に送信することを更に含む。これにより、出力フレームの制御がＲＴＯＳのフレームプロセッサによって集中化されることを確実にすることができる。

【0014】

選択的には、方法は、ＲＴＯＳによって、及び第２のＯＳのカーネルによって、フレームデータを記憶するバッファーを共有することを更に含む。共通リソースのそのような共有により、アーキテクチャーがより効率的になる。

【0015】

選択的には、方法は、第２のＯＳからＲＴＯＳバッファーへのアクセスを防ぐことを更に含む。これにより、ＲＴＯＳを通じて実行されるネットワークタスクのセキュリティの強化を可能にすることができる。

【0016】

選択的には、方法は、
フレームプロセッサによって、分類規則に従って、ストリームクラス識別子を入力フレームにアタッチすることと、
入力フレーム及びアタッチされたストリームクラス識別子を、フレームプロセッサのキュー識別モジュールに渡すことと、
を更に含む。

【0017】

そのようなストリームクラス識別子は、例えば、入力フレームをＲＴＯＳ又は第２のＯＳによる更なる処理のためにポストすることができるキューを決定することを可能にすることができる。

【0018】

選択的には、方法は、フレームプロセッサが動的に定義された分類規則を適用していることを更に含む。これにより、分類を異なる状況に適合させることを可能にすることができ、特に、入力フレームの処理及び出力フレームの生成を担当するＲＴＯＳ又は第２のＯＳにおけるアプリケーションの展開を可能にする。より詳細には、第２のＯＳのカーネル及びＲＴＯＳのアプリケーションの一方又は双方が、分類規則を動的に定義することに寄与している。これにより、フィードバックメカニズムを用いて分類規則を適合させることを可能にすることができ、そのようなフィードバックは、第２のＯＳのカーネル及びＲＴＯＳのアプリケーションのうちの一方又は双方から生じる。

【0019】

選択的には、方法は、
フレームプロセッサによって、分類規則に従って、ストリームクラス識別子を出力フレームにアタッチすることと、
スケジューリングされた出力フレームのフレーム送信について、出力フレームのアタッチされたストリームクラスの時間及び優先度の双方に依拠して、スケジューリング規則を出力フレームに適用することと、
を更に含む。

【0020】

これによって、フレームプロセッサによって、例えばＴＳＮ規格制約に準拠するために、いずれの出力フレームが他のフレームの前に処置されるべきかを制御することを可能にすることができる。

【0021】

本開示は、処理コアとメモリとを備えるマルチコアシステムオンチップ（ＳＯＣ）デバイスであって、処理コアは、本開示による方法のうちの任意のものに従って動作するように構成される、マルチコアシステムオンチップ（ＳＯＣ）デバイスも説明する。そのようなマルチコアＳＯＣデバイスは、汎用ＯＳ及びＲＴＯＳの双方をハンドリングすることを可能にすることができる。

【0022】

本開示は、マルチコアシステムオンチップ（ＳＯＣ）デバイスの処理コアによって実行されると、該処理コアに本開示による方法のうちの任意のものを実行させる命令を含むコンピューター可読記憶媒体も記載する。

【図面の簡単な説明】

【0023】

【図1】本開示による例示的な方法を示す図である。

【図2】本開示による別の例示的な方法を示す図である。

【図3】本開示による別の例示的な方法を示す図である。

【図4】本開示による例示的なＳＯＣを示す図である。

【図5】本開示による別の例示的なＳＯＣを示す図である。

【図6】本開示による例示的なフレームプロセッサを示す図である。

【図7】本開示による例示的なフレームプロセッサを示す図である。

【図8】本開示による別の例示的なＳＯＣを示す図である。

【図9】本開示による別の例示的なＳＯＣを示す図である。

【発明を実施するための形態】

【0024】

より効率的なコンピューティングシステムを提供するために、半導体製造者は、様々な電子コンポーネントを同じパッケージ上にパッケージングする（「ＳｏＣ」又は「ＳＯＣ」とも呼ばれる）傾向にある。この手法は、複数のパッケージの代わりに単一の半導体パッケージが提供されるため、物理的空間を節減することができ、より良好な性能を提供することができ、より低いコストで、より低い電力を消費することができる。複数のパッケージは、コンポーネント間の通信を可能にするために物理的オフチップワイヤを介して別個に給電及び／又は結合され、ひいては更なる物理的空間を必要とする。本開示は、マルチコアＳＯＣ処理アーキテクチャーにおけるデータの処理に適用される。そのようなＳＯＣは、複数の中央処理ユニット（ＣＰＵ）又はコアと、メモリとを備える。様々な場合に、ＳＯＣデバイスは、任意の特定の市場セグメントを特別に対象としていない任意のチップ設計を含むことができる。ＳＯＣは、単純なＳＯＣ、コンパニオンチップ又は複雑なＳＯＣとすることができる。

【0025】

マルチコアＳＯＣは、いくつかの例において、いくつかの実行コアを備えてもよく、実行コアのそれぞれが、いくつかのプロセッサとしてプログラム命令を読み出し、実行する。コアは、キャッシュを共有する場合もしない場合もあり、いくつかの例では、メッセージの受け渡し又は共有メモリコア間通信方法を実施することができる。いくつかの場合、各コアが専用Ｌ１キャッシュを有する。いくつかの場合、様々なコアが同じＬ２キャッシュを共有する。いくつかの例において、同種マルチコアＳＯＣは、同一のコアのみを含む。いくつかの例において、異種マルチコアＳＯＣは、同一でないコアを含む。

【0026】

いくつかの場合、特定の割り込みコントローラー（例えば、ＡＲＭプロセッサにおいて、グローバル割り込みコントローラーと呼ばれる）が、マルチコアＳＯＣのコア間の割り込みルーティング、及びプロセッサ間割り込みを提供する。

【0027】

いくつかの場合、ＲＡＭ（ランダムアクセスメモリ）及びデバイス周辺機器（例えばＵＡＲＴ（汎用非同期受信機－送信機）又はネットワークインターフェース）を、異なるＣＰＵ又はコア間で共有することができる。いくつかの場合、いくつかのコアが同じ周辺リソースに同時にアクセスしているとき、何らかのメモリ又はデバイスのボトルネックが生じる場合がある。

【0028】

例えば図１に表されるように、本開示は、マルチコアＳＯＣ処理アーキテクチャーにおいてデータを処理する方法１００に適用され、この方法は、例えば、ブロック１０１におけるように、ＳＯＣの媒体アクセスコントローラー（ＭＡＣ）からリアルタイムオペレーティングシステム（ＴＲＯＳ）のネットワークインターフェースコントローラー（ＮＩＣ）において入力フレームを受信することを含み、ＲＴＯＳはＳＯＣの第１のコアにおいて実装される。

【0029】

ＲＴＯＳは、データが受信される際にデータのリアルタイム処理を提供するように意図されたオペレーティングシステムである。ＲＴＯＳの例は、数ある中でも、ＦＲＥＥＲＴＯＳ（商標）、ＲＴＥＭＳ（商標）を含む。ＲＴＯＳの特性は、タスクをスケジューリング及び完了する際の一貫性レベルである。本明細書において用いられるとき、タスクは、ＲＴＯＳ上で実行されているアプリケーション、又は割り込みサービスルーチン（ＩＳＲ）等によって呼び出すことができるオペレーティングシステム動作とすることができる。その実行時間は、タスクの単一実行のための時間である。いくつかの場合、タスクは、タスクが完了しなくてはならない関連する期限を有する。期限に遅れることは、タスクの実行がタスクの期限前に完了しない場合のシナリオである。代替的に、又は加えて、期限は、タスクの或る特定の数の起動期間を含む。電力ステアリングシステム（ＥＰＳ）において用いられているもの等のハードＲＴＯＳでは、タスクタイミング及びタスク期限が重要な役割を果たす。本開示によれば、ＲＴＯＳは、ＳＯＣの第１のコアにおいて実装される。いくつかの場合、ＳＯＣの第１のコアにおいて他のＯＳは実装されず、第１のコアにおいて実装される唯一のＯＳがＲＴＯＳである。

【0030】

ＲＴＯＳは、リアルタイムシステムに関するタスクの処理に特に適することができる。リアルタイムシステムは、インタラクティブなリアルタイムプロセスのセットとみなすことができ、各リアルタイムプロセスは、期限前を意味する有限時間内に、外部イベントに応答して何らかの反応を生成する。

【0031】

システムは、以下のカテゴリのうちの１つにおいて分類することができる。
－非リアルタイム。非リアルタイムシステムは、期限が関与しないシステムである。ＲＴＯＳは、本開示によれば非リアルタイムシステムではない。
－ソフトリアルタイム。ソフトリアルタイムシステムは、期限を満たさないことが望ましくない影響を有する場合があるが、システムによって許容され得る、例えば性能劣化につながるシステムである。換言すれば、ソフトリアルタイムシステムは、平均的な事例において期限を満たすことができる。Ｌｉｎｕｘ（登録商標）ＯＳカーネルは、例えば、ＦＩＦＯ（先入れ先出し）又はラウンドロビンプロセススケジューリングを実施することに起因して、このカテゴリに関するものとして分類することができる。ＲＴＯＳは、本開示によればソフトリアルタイムシステムではない。
－ファームリアルタイム。まれに期限に遅れることが許容可能であるが、システムサービス品質が劣化する場合がある。システムは、タスクの失敗の間隔が適切に空いている限り、タスクの失敗を切り抜けることができる。ファームＲＴ（リアルタイム）システムは、例えば、ハードリアルタイムに近づくように改善されたソフトＲＴシステムである。大抵の場合、システムによって保証される厳密な期限は存在しない。ＰＲＥＥＭＰＴ＿ＲＴパッチを有するＬｉｎｕｘ（登録商標）カーネル、又はＸｅｎｏｍａｉがこのカテゴリの一部である。ＲＴＯＳは、本開示によればファームリアルタイムシステムではない。
－ハードリアルタイム。ハードリアルタイムシステムは、期限を満たさないことが重大な影響を有し得るシステムである。ＦｒｅｅＲＴＯＳ又はＲＴＥＭＳ等のリアルタイムＯＳ（ＲＴＯＳ）がこのカテゴリの一部である。いくつかの場合、Ｌｉｎｕｘ（登録商標）等のＯＳと異なり、これらは比較的少ないサービスを提供し、そのような少ないサービスは、いくつかの場合、タスク／プロセスのスケジューリング及び割り込みに関係している。ＲＴＯＳは、ハードリアルタイムシステムとすることができる。
－絶対リアルタイム。絶対リアルタイムシステムは、外部イベントに対する応答時間が固定され、同じままである（数ｎｓ又はナノ秒以内）システムである。ＦＰＧＡ（フィールドプログラマブルゲートアレイ）又はＣＰＬＤ（複雑なプログラマブル論理デバイス）等のいくつかのプログラム可能なハードウェアベースのシステムがこのカテゴリにある。ＲＴＯＳは、絶対リアルタイムシステムではない。

【0032】

いくつかの場合、ＲＴＯＳは、割り込みプロセスの慎重な実施によって適切な性能を達成することができる。いくつかの場合、ＲＴＯＳは、ＣＰＵ速度に依拠して、及びＨＷ（ハードウェア）割り込みを生成する周辺デバイスの複雑度に依拠して、数ｐｓの最大レイテンシを達成することができる。いくつかの場合、ＲＴＯＳは、一般的に静的に定義し、ＲＴＯＳにバインドすることができるタスクの制限されたセットをサポートする。いくつかの場合、ＲＴＯＳは、ファイルシステム又はメモリマネージャー等のサービスを提供しない場合がある。いくつかの場合、ＲＴＯＳによってサポートされるアプリケーションの複雑度は限定される。いくつかの場合、ＲＴＯＳアプリケーションを開発、試験及び／又は維持するのに必要な時間及びコストは、カーネル空間及びユーザー空間を含むＯＳ等の汎用ＯＳを用いてアプリケーションを維持するよりも高い。

【0033】

媒体アクセスコントローラー（ＭＡＣ）は、物理的伝送媒体へのアクセスを制御する機能を提供する。ＭＡＣ機能のうちのいくつかは、プロセッサ上で実行されるソフトウェアにおいて実装される。いくつかの場合、ユーザーデータプレーン、特に、ＰＨＹイーサネット（イーサネット物理層コンポーネント）との間の送受信に関するＭＡＣ機能は、ハードウェアにおいて実装される。ＭＡＣは、個別ロジック、メモリ、マイクロプロセッサ及び／又はそれらの組み合わせとして基板上で実装される。ＭＡＣは、暗号化／復号化、パケットのセグメンテーション／リアセンブリ、チャネルアクセス（例えば、アービトレーションを含む）、及びアドレスフィルタリングの機能を実行するようにアレンジされる。いくつかの例において、ＭＡＣは、イーサネットＭＡＣのための１０ＢＡＳＥ－Ｔ／１００ＢＡＳＥ－ＴＸ８０２．３等のＩＥＥＥ規格に準拠するイーサネット媒体アクセスコントローラー（ＥＭＡＣ）周辺機器を含み、１０／１００Ｍｂｐｓデータ伝送レートをサポートする。いくつかの場合、ＥＭＡＣはＩＥＥＥ８０２．１Ｑ ＶＬＡＮタグ検出をサポートすることができる。いくつかの場合、ＥＭＡＣは、精密なネットワーク制御されたクロック同期又はギガビット速度のためにＩＥＥＥ１５８８－２００８をサポートすることができる。いくつかの場合、ＥＭＡＣは、ＩＥＥＥ８０２．１ｑｂｖ（時間認識スケジューラー）、又は時間ベースの送出（すなわち、所与の時点にフレームを送信する能力）等のいくつかのＩＥＥＥ ＴＳＮ拡張をサポートする。

【0034】

ネットワークインターフェースコントローラー（ＮＩＣ）ブロックは、メッセージの受信及び送信のために用いられるＭＡＣキューの管理を担当する。ＮＩＣブロックは、入力メッセージ及び出力メッセージをバッファリングし、高レベルのインターフェースを提供する。加えて、ＮＩＣは、ローカルコンピューティングリソースメッセージ統計を収集することができる。これは、送信、受信及びブロックされたメッセージの数を追跡することを伴うことができる。ＮＩＣの役割は、ＲＴＯＳに通信リソースの統一ビューを提供することとすることができる。例えば、ＮＩＣにおいて収集されるメッセージ統計をＮＩＣによって処理し、ＲＴＯＳが実装されるＳＯＣの第１のコアに通信することができる。いくつかの例において、ＮＩＣは、ＲＴＯＳの分散部分とみなすことができる。

【0035】

いくつかの場合、本開示による方法は、イーサネットＴＳＮ要件のコンテキストで適用することができる。ＴＳＮは、標準イーサネットにおける決定性メッセージング（deterministic messaging）を提供するための、ＩＥＥＥ８０２．１が定義した標準技術に対応する。（ＲＴＯＳタスクに関係するもの等の）リアルタイム（ＲＴ）フレームのオンタイム送達の提供は、ＩＥＥＥ８０２．１Ｑｂｖ規格に従うことができる。ＩＥＥＥ８０２．１Ｑｂｖは、（非ＲＴＯＳタスクに関係するもの等の）非ＲＴイーサネットフレームが、（ＲＴＯＳタスクに関係付けられた）ＲＴフレームの周りで、ベストエフォートベースで送信されることを可能にしながら、スケジュールに沿って或る特定のＴＳＮイーサネットフレームを送信することに関する。全てのネットワークノードが同期されている場合、ＩＥＥＥ８０２．１Ｑｂｖは、（ＲＴＯＳタスクに関係する）重大な通信を、非常に迅速に、かつ送達時のジッターを非常に低くして送達することができる。ＩＥＥＥ８０２．１グループによって定義される異なるＴＳＮ規格は、以下の３つのコンポーネントカテゴリにグループ化することができる。
－時刻同期：ＴＳＮネットワークにおける時刻は、１つのマスターソースから全てのネットワークノードに配信することができる。いくつかの場合、これは、イーサネットフレームを利用して時刻同期情報を配信する、ＩＥＥＥ１５８８高精度時刻同期プロトコル規格を用いて行われる。
－スケジューリング及びトラフィックシェーピング：スケジューリング及びトラフィックシェーピングは、同じネットワークにおける、異なる優先度を有する異なるトラフィッククラスの共存を可能にする。ＴＳＮは、ソフトリアルタイム要件及びハードリアルタイム要件を用いた適時の送達を確実にするメカニズムを追加することによって、イーサネット通信を向上させることができる。
－通信経路、経路予約及びフォールトトレランスメカニズムの選択。

【0036】

いくつかの場合、異なる優先度についてスケジューリングコンポーネントに焦点を当てることによって、ユーザーは、様々なアクセス制御及びスケジューリングメカニズムから、イーサネットフレームが処理される方法を選択することができる。それによって、（ＩＥＥＥ８０２．ＩＱ規格によって定義された厳密な優先度スケジューラー等の）既存の方法、又はＩＥＥＥ８０２．１Ｑｂｖ規格によって定義された時間認識トラフィックスケジューラー等の何らかの新たな処理方法に、何らかの優先度を割り当てることができる。この時間認識スケジューラーは、イーサネットネットワークにおける通信を固定長の複数の繰り返し時間サイクルに区分するように設計される。これらのサイクル内で、イーサネット優先度のうちの１つ又は複数に割り当てることができる異なる複数のタイムスライスを構成することができる。このメカニズムを用いることで、厳しいリアルタイム制約を有するトラフィッククラス（ＲＴＯＳタスク等）のためのイーサネット伝送媒体に排他的使用を与えることが可能になる。この排他的アクセスは、イーサネットスイッチ伝送バッファーにおけるバッファリング効果をなくし、時間が重要なトラフィック（ＲＴＯＳタスクに関係するもの等）を、非決定性割り込みなしで送信することができる。タイムスライスは、仮想通信チャネルとみなすことができ、時間が重要な通信（ＲＴＯＳタスクに関係する）を、重要でないバックグラウンドトラフィック（非ＲＴＯＳタスクに関係する）から区分することを可能にすることができる。

【0037】

本開示によれば、ＭＡＣ及びＮＩＣはＳＯＣにおいて実装される。ＭＡＣ及びＮＩＣは、処理されるデジタルデータを含む入力フレームを処理しており、入力フレームは、ＳＯＣの外部のコンポーネントから入力される。本明細書に記載のように、入力フレームのＳＯＣにおけるルーティングは、ＳＯＣのＭＡＣからＳＯＣのＮＩＣに進む。いくつかの例において、入力フレームは、ＳＯＣの外部のコンポーネントからＳＯＣのＭＡＣに直接入力される。ＳＯＣの外部のコンポーネントはバスとすることができる。いくつかの例において、入力フレームは、ＭＡＣからＮＩＣに直接ルーティングされる。

【0038】

例えば図１に表されているような本開示によれば、入力フレームは、例えばブロック１０２におけるように、ＲＴＯＳのＮＩＣからＲＴＯＳのフレームプロセッサに送信される。ＲＴＯＳのフレームプロセッサまでの入力フレームのルーティングにより、入力フレームの処理に対するＲＴＯＳ制御が可能になる。このように進めることにより、時間が重要な処置を要する入力フレームが実際にＲＴＯＳに到達することが確実になる。いくつかの例において、ＳＯＣに入力される全てのフレームが、ＳＯＣのＭＡＣへ、ＳＯＣのＮＩＣへ、そしてＲＴＯＳのフレームプロセッサへこの順序で送信される。第２のＯＳによる処理に関係付けることができる入力フレームも、本開示によれば、ＲＴＯＳのフレームプロセッサにルーティングされる。そのようなプロセスは、ＲＴＯＳによるタイムセンシティブなタスクの処理を危険にさらすことなく第２のＯＳ等の汎用ＯＳによるタスクのハンドリングを可能にする。

【0039】

例えば図１に表されているような本開示によれば、入力フレームは、例えばブロック１０３におけるように、少なくとも、ＲＴＯＳタスクに関係付けられた第１のクラスと、非ＲＴＯＳタスクに関係付けられた第２のクラスとを含む分類に従って、フレームプロセッサにおける構文解析及び分類にサブミットされる。いくつかの場合、構文解析は、入力フレームにおいて提供されたデータの構造表現を提供することを含む。少なくとも、ＲＴＯＳタスクに関係付けられた第１のクラスと、非ＲＴＯＳタスクに関係付けられた第２のクラスとを含む分類による入力フレームの分類は、タイムセンシティブ性に応じて少なくとも２つの異なるカテゴリにおいて入力フレームを区分することが可能になる。いくつかの場合、２つのクラスは、ＲＴＯＳによる更なる処置のための特にタイムセンシティブなタスクと、第２のＯＳによる処置のためのあまりタイムセンシティブでないタスクとの間で入力フレームを区分するのに十分とすることができる。いくつかの例では、分類の粒度を高めるために、追加のクラスを提供することができる。

【0040】

例えば図１に表されているような本開示によれば、第１のクラスに分類された入力フレームは、例えばブロック１０４におけるように、フレームプロセッサから、ＲＴＯＳのシーケンサーによって実行される１つ以上のタスクに送信される。ＲＴＯＳのシーケンサーによって実行されるそのような１つ以上のタスクはＲＴＯＳタスクである。シーケンサーは、ＲＴＯＳが実装されているプロセッサを１つのマイクロ命令から別のマイクロ命令に制御するか又は進めさせることができ、これによって、シーケンスによって決定された順序で第１のクラスに分類された入力フレームを処理することになる。そのような処理は、そのような入力フレームに関係するタスクのタイムセンシティブ性が守られることを確実にすることができる。３つ以上のクラスを用いるいくつかの例において、いくつかの他のクラスに分類された入力フレームは、ＲＴＯＳのシーケンサーによって実行される１つ以上のタスクに送信することができる。第２のクラスに分類された入力フレームは、タイムセンシティブでないタスクについてＲＴＯＳの処理能力を用いることを回避するために、ＲＴＯＳのシーケンサーによって実行される１つ以上のタスクに送信されるべきでない。したがって、第２のクラスに分類されたそのような入力フレームは、第２のＯＳによってハンドリングされる。

【0041】

例えば図１に表されているような本開示によれば、第２のクラスに分類された入力フレームは、例えばブロック１０５におけるように、フレームプロセッサから、ＳＯＣの第２のコアにおいて実装される第２のオペレーティングシステム（ＯＳ）のネットワークデバイスドライバーに送信され、第２のＯＳは、カーネル空間とユーザー空間とを備える。第２のＯＳは、いくつかの例において、コンピューティングタスクの一般使用に適したＯＳであり、すなわち、ＲＴＯＳ等のタイムセンシティブなタスクをハンドリングするために予約されたＯＳではない。これが、第２のＯＳがカーネル空間及びユーザー空間を含む理由である。第２のＯＳは、特に自身のユーザー空間において、多岐にわたるアプリケーションを実施することができる。第２のＯＳは、例えばＲＴＯＳのフレームプロセッサと第２のＯＳをインターフェースさせることを可能にするネットワークデバイスドライバーを備える。ＲＴＯＳのフレームプロセッサは、実際に、特にタイムセンシティブなときのＲＴＯＳによる処理のために、又は他の形での第２のＯＳによる処理のために、入力フレームを方向付ける選択的フィルタとみなすことができる。いくつかの例において、ＲＴＯＳは、タイムセンシティブなタスクの処理に専用であり、ＲＴＯＳはユーザー空間を含まない。いくつかの例において、ＲＴＯＳは、ＲＴＯＳカーネル空間においてアプリケーションを実行し、それによって、ＲＴＯＳ上で実行されるアプリケーションにＲＴＯＳの制御の増大をもたらし、ＲＴＯＳ上で実行する際の割り込みを低減するか又は更には防ぐ。これは、ユーザー空間を含み、それによって第２のＯＳのカーネル空間上で制御することができる割り込みに対する、第２のＯＳのユーザー空間上で実行されるアプリケーションの制御を制限する第２のＯＳと異なる。第２のＯＳは、ＳＯＣ上で実装され、したがって、ＲＴＯＳと同じＳＯＣ上で実装されるが、第２のＯＳはＳＯＣの第２のコアにおいて実装され、したがって、ＲＴＯＳが実装される第１のコアと異なるコアにある。これにより、第２のＯＳに利用可能な処理と、ＲＴＯＳに利用可能な処理との優先権の衝突が回避される。ＳＯＣのコアは、同じタイプであってもよく、異なるタイプであってもよい。

【0042】

例えば図１に表されているような本開示によれば、例えばブロック１０６におけるように、第１のコアにおいて、ＲＴＯＳのシーケンサーによって実行される１つ以上のタスクに送信される入力フレームが処理され、第２のコアにおいて、第２のＯＳのネットワークデバイスドライバーに送信される入力フレームが処理される。いくつかの例では、ＲＴＯＳ及び第２のＯＳは、異なるコアにおいて並列に機能する。ＲＴＯＳは、自身のＮＩＣ及びフレームプロセッサを通じて、ＲＴＯＳと第２のＯＳとの間の入力フレーム及び関連タスクのディスパッチ又は割り当てを制御するが、ＲＴＯＳ及び第２のＯＳは、本開示による分類によって割り当てられると自身のタスクを独立してハンドリングする。この独立した処理は、そうでない場合にタイムセンシティブなタスクに影響を与えるか、又はあまりタイムセンシティブでないタスクに過度の遅延を引き起こす衝突を回避する。

【0043】

例えば図１に表されているような本開示によれば、ＲＴＯＳタスクに関係する出力フレームは、例えばブロック１０７におけるように、ＲＴＯＳのシーケンサーによって実行される１つ以上のタスクからフレームプロセッサに送信される。そのような出力フレームは、ＲＴＯＳが実装されている第１のコア等のコアに対するＲＴＯＳによるタスクの処理の結果として生じるデジタルデータを含む。いくつかの場合、出力フレームは、特定の入力フレームによる処理に対応するか又はこの処理によってトリガーされる場合があるが、これは必ずしも当てはまらない。本開示によれば、フレームプロセッサはＲＴＯＳのフレームプロセッサである。これは、本開示によるＲＴＯＳによるフレームフローの制御と一致する。

【0044】

例えば図１に表されているような本開示によれば、非ＲＴＯＳタスクによって生成される出力フレームは、例えばブロック１０８におけるように、第２のＯＳのネットワークデバイスドライバーからフレームプロセッサに送信される。そのような出力フレームは、第２のＯＳが実装される第２のコア等のコアに対する第２のＯＳによるタスクの処理の結果として生じるデジタルデータを含む。ここでもまた、いくつかの場合、出力フレームは、特定の入力フレームによる処理に対応するか又はこの処理によってトリガーされる場合があるが、これは必ずしも当てはまらない。ここでもまた、本開示によれば、フレームプロセッサはＲＴＯＳのフレームプロセッサである。これは、出力フレームが第２のＯＳから生じる場合であっても、本開示によるＲＴＯＳによるフレームフローの制御と一致する。

【0045】

例えば図１に表されているような本開示によれば、出力フレームは、例えばブロック１０９におけるように、フレームプロセッサにおいて分類及びスケジューリングされる。これは、出力フレームレベルにおけるＲＴＯＳのフレームプロセッサの集中化の役割を実施する。実際に、いくつかの例において、ＲＴＯＳ及び第２のＯＳの双方から生じる全ての出力フレームを含む全ての出力フレームがＲＴＯＳの同じフレームプロセッサにルーティングされる。これは、特定のタイムセンシティブなタスクが相応して分類及びスケジューリングされ、これにより過剰な遅延を回避することを確実にする。

【0046】

例えば図１に表されているような本開示によれば、スケジューリングされた出力フレームは、例えばブロック１１０におけるように、フレームプロセッサからＮＩＣに、及びＮＩＣからＭＡＣに送信される。これにより、ＲＴＯＳ及び第２のＯＳタスクの双方のＳＯＣに対する処理が完了し、そのようなタスクの処理は、入力及び出力の双方においてＲＴＯＳフレームプロセッサによって集中制御される。

【0047】

いくつかの場合、ＲＴＯＳは、ＳＯＣの追加の第１のコアにおいて実装される。これは、例えば、処理ブロック１０６の加速を可能にすることができる。いくつかの例では、ＲＴＯＳのフレームプロセッサは、ＲＴＯＳが実装される第１のコアのうちの単一のコアによって制御される。第２のＯＳは、ＲＴＯＳが実装される第１のコアにおいて実装されない場合がある。任意の追加の第１のコアは、第１のコアと同じであってもよいし、第１のコア又は他の追加の第１のコアと異なっていてもよい。

【0048】

例えば図２に表されているもの等のいくつかの場合、本開示による方法２００は、図１に記載のブロック１０１～１０２、並びに、例えばブロック２０３におけるように、他のＲＴＯＳタスクに関係する１つ以上の他のクラスを含む分類に従ってフレームプロセッサにおいて入力フレームを構文解析及び分類することを含む。そのような１つ以上の他のクラスを導入することにより、分類に追加の粒度をもたらすことが可能になる。この例において、方法は、１つ以上の他のクラスに分類された入力フレームを、フレームプロセッサから、１つ以上の専用の他のＲＴＯＳの１つ以上の専用の他のシーケンサーによって実行される１つ以上のタスクに送信することであって、１つ以上の専用の他のＲＴＯＳは、ＳＯＣの１つ以上の専用コアにおいて実装されることを更に含む。これにより、１つ以上の他のクラスによって提供される追加の粒度を利用して、同じＳＯＣにおいて実装される異なるＲＴＯＳに対しＲＴＯＳ関連タスクの処理を並列化することができる。この例において、いくつかのＲＴＯＳは、ＳＯＣにおいてＲＴＯＳタスクを処理する位置にあることができるが、フレームの集中型のハンドリングを維持するために、単一のＲＴＯＳが本開示によるフレームプロセッサに関係付けられる。この例において、例えばブロック２０４に示すように、第１のクラス及び１つ以上の他のクラスに分類された入力フレームは、ＳＯＣの様々なＲＴＯＳのシーケンサーによって実行される１つ以上の専用タスクに送信される。この特定の例において、第２のクラスは、非ＲＴＯＳタスクにリンク付けされたままであり、ブロック１０５におけるように、そのような非ＲＴＯＳタスクは、第２のＯＳのネットワークデバイスドライバーに送信される。この場合、ブロック２０６によって示されるように、一方で、非ＲＴＯＳタスクについて第２のＯＳにおいて、他方で、それぞれ第１のクラス及び１つの又は他のクラスに対応する様々なＲＴＯＳにおいて、処理が行われる。この例では、ＳＯＣの各ＲＴＯＳは、割り当てられた対応するクラスを有するが、他の場合、ＲＴＯＳに対応するそのようなクラスが、特にタイムセンシティブなものとして分類されたＲＴＯＳタスクに対応する限り、特定のＲＴＯＳが異なる複数のクラスをハンドリングしてもよく、異なる複数のＲＴＯＳが単一のクラスをハンドリングしてもよい。方法２００の以下のステップは、ステップ１０７～１１０に類似しており、ＳＯＣの全てのＲＴＯＳ及び第２のＯＳが、本開示によるフレームの集中型の処置を維持するために、自身の対応する出力フレームを、特定のＲＴＯＳに割り当てられた同じフレームプロセッサに返送する。

【0049】

いくつかの例において、第２のＯＳは、ＳＯＣの追加の第２のコアにおいて実装される。これにより、第２のＯＳのための追加の処理能力から利益を得ることが可能になる。しかしながら、第２のＯＳのこの実装は、ＲＴＯＳのフレームプロセッサによるフレームの集中型ハンドリングに対し直接の影響を有しない。換言すれば、異なる第２のコアに対する第２のＯＳについてハンドリングされるタスクは、同じフレームプロセッサから生じる入力フレームに関係し、同じフレームプロセッサに送信される出力フレームに関係する。この例において、第２のＯＳが実装される第２のコアは、ＲＴＯＳを実装するために用いられない。換言すれば、ＳＯＣに存在するいずれのコアもＲＴＯＳ及び第２のＯＳの双方を実装することができない。

【0050】

例えば図３に表されているもの等のいくつかの場合、本開示による方法３００は、図１又は図２に記載のブロック１０１及び１０２、並びに、例えばブロック３０３におけるように、非ＲＴＯＳタスクに関係する１つ以上の他のクラスを含む分類に従ってフレームプロセッサにおいて入力フレームを構文解析及び分類することを含む。そのような１つ以上の他のクラスを導入することにより、分類に追加の粒度をもたらすことが可能になる。この例において、方法は、１つ以上の更なるクラスに分類された入力フレームを、フレームプロセッサから、ＳＯＣの１つ以上の専用の更なるコア上で実装される１つ以上の専用の更なるＯＳの１つ以上の専用の他の更なるネットワークデバイスドライバーに送信することであって、１つ以上の専用の更なるＯＳは、専用の更なるカーネル空間及び専用の更なるユーザー空間を含むことを更に含む。これにより、１つ以上の他のクラスによって提供される追加の粒度を利用して、同じＳＯＣにおいて実装される異なるＯＳに対しＯＳ関連タスクの処理を並列化することができる。そのような更なるＯＳは、それぞれ、カーネル空間及びユーザー空間の双方を含み、本開示による第２のＯＳの機能に類似した機能を可能にする。この例において、第２のＯＳに加えたそのような１つ以上の更なるＯＳは、ＳＯＣにおける非ＲＴＯＳタスクを処理する位置にあることができる。この例において、第２のクラス及び１つ以上の他のクラスに分類された入力フレームは、例えばブロック３０５に示すように、ＳＯＣの様々なＯＳの専用ネットワークデバイスドライバーに送信される。この特定の例において、第１のクラスは、ＲＴＯＳタスクにリンク付けされたままであり、ブロック１０４におけるように、そのようなＲＴＯＳタスクは、ＲＴＯＳのシーケンサーによって実行される１つ以上のタスクに送信される。この場合、ブロック３０６によって示されるように、一方で、それぞれ第２のクラス及び１つの又は他のクラスに対応する非ＲＴＯＳタスクについて第２のＯＳ及び１つ以上の更なるＯＳにおいて、他方で第１のクラスに対応するタスクについてＲＴＯＳにおいて、処理が行われる。この例では、ＳＯＣの各ＯＳは、割り当てられた対応するクラスを有するが、他の場合、ＯＳに対応するそのようなクラスが、特にタイムセンシティブなものとして分類されていないＯＳタスクに対応する限り、特定のＯＳが異なる複数のクラスをハンドリングしてもよく、異なる複数のＯＳが単一のクラスをハンドリングしてもよい。方法３００の以下のステップは、ステップ１０７～１１０に類似しており、ＳＯＣの全てのＯＳ（第２のＯＳを含む）及びＲＴＯＳが、本開示によるフレームの集中型の処置を維持するために、自身の対応する出力フレームを、特定のＲＴＯＳに割り当てられた同じフレームプロセッサに返送する。

【0051】

図示されていないが、図２及び図３に示す構造を組み合わせた例を検討することができる。そのような例は、それぞれがカーネル空間及びユーザー空間を含むいくつかのＯＳのみでなく、いくつかのＲＴＯＳも含むＳＯＣに適用することができ、各ＲＴＯＳ、並びにカーネル空間及びユーザー空間を含む各ＯＳは、ＳＯＣの少なくとも１つの専用コアを割り当てられる。そのような構造において、本開示によれば、関連タスクのタイムセンシティブ性に応じて入力フレーム及び出力フレームの分類について多数のクラスを検討することができるが、そのような分類は、ＳＯＣの単一のＲＴＯＳに含まれる単一のフレームプロセッサの制御下に留まる。

【0052】

いくつかの例において、本開示による方法は、第２のＯＳのネットワークデバイスドライバーにおいて、ＲＴＯＳのフレームプロセッサから排他的に送信された入力フレームを受信することを更に含む。これは、例えば、本明細書に記載の方法１００、２００、３００、及び本明細書に記載の特徴を組み合わせた方法のうちの任意のものに適用することができる。入力フレームのルーティングに対するそのような制約により、そのようなルーティングがＲＴＯＳのフレームプロセッサの制御下に留まることが確実になり、それによって、タイムセンシティブなタスクをＯＣのＲＴＯＳによる処理のために適切に処置し、適時に送信することができることを確実にするのに役立つ。

【0053】

いくつかの例において、本開示による方法は、第２のＯＳのネットワークデバイスドライバーによって、出力フレームを、ＲＴＯＳのフレームプロセッサに排他的に送信することを更に含む。これは、例えば、本明細書に記載の方法１００、２００、３００、及び本明細書に記載の特徴を組み合わせた方法のうちの任意のものに適用することができる。出力フレームのルーティングに対するそのような制約により、そのようなルーティングがＲＴＯＳのフレームプロセッサの制御下に留まることが確実になり、それによって、タイムセンシティブなタスクを適切に処置し、本開示によるＳＯＣのＲＴＯＳによる処理後、ＳＯＣの外部のコンポーネントに対して適時に送信することができることを確実にするのに役立つ。

【0054】

いくつかの例において、本開示による方法は、ＲＴＯＳによって、及び第２のＯＳのカーネルによって、フレームデータを記憶するバッファーを共有することを更に含む。これは、例えば、本明細書に記載の方法１００、２００、３００、及び本明細書に記載の特徴を組み合わせた方法のうちの任意のものに適用することができる。第２のＯＳ及びＲＴＯＳが同じＳＯＣに含まれることを考慮すると、フレームデータを記憶するバッファーのそのような共有は、結果として特に効率的なものとなることができる。フレームデータを記憶するそのようなバッファーは、実際に同じＳＯＣに含めることもできる。そのような共有は、本開示によるＳＯＣに含まれる１つ以上の更なるＯＳ及び／又は１つ以上の更なるＲＴＯＳにも適用することができる。

【0055】

いくつかの例において、本開示による方法は、第２のＯＳからフレームデータを記憶するＲＴＯＳバッファーへのアクセスを防ぐことを更に含む。これは、例えば、本明細書に記載の方法１００、２００、３００、及び本明細書に記載の特徴を組み合わせた方法のうちの任意のものに適用することができる。第２のＯＳからＲＴＯＳバッファーへのアクセスを阻止することは、例えば、ＲＴＯＳタスクの所望のセキュリティレベルを確保することに寄与することができる。そのような選択的なアクセス制御は、本開示によるＳＯＣに含まれる１つ以上の更なるＯＳ及び／又は１つ以上の更なるＲＴＯＳにも適用することができ、各ＯＳ若しくは各ＲＴＯＳ、又はＯＳのグループ若しくはＲＴＯＳのグループが、特定のバッファーに対し排他的アクセスを有することができる。

【0056】

いくつかの例において、本開示による方法は、フレームプロセッサによって、分類規則に従って、ストリームクラス識別子を入力フレームにアタッチすることと、入力フレーム及びアタッチされたストリームクラス識別子を、フレームプロセッサのキュー識別モジュールに渡すこととを更に含む。これは、例えば、ＲＴＯＳ、第２のＯＳ、又は更なるＲＴＯＳ若しくはＯＳに対応するＯＳの異なる複数のコアによる処理の前にキューの形成を編成することを可能にすることができる。そのようなアタッチ及び受け渡しは、例えば、示される方法１００、２００及び３００のブロック１０３、２０３又は３０３に含めることができる。

【0057】

本開示による方法のいくつかの例において、フレームプロセッサは、動的に定義された分類規則を適用している。そのような規則のそのような動的な定義は、例えば、ＲＴＯＳからのフィードバックメカニズム、第２のＯＳからのフィードバックメカニズム、ＳＯＣのコンポーネントからのフィードバックメカニズム、又はＳＯＣの外部のコンポーネントからのフィードバックメカニズムのうちの１つ以上を用いて行うことができる。そのような動的に定義された分類規則は、例えば、全体的な柔軟性を得るために優先度を調整することができる。いくつかの例では、分類規則を動的に定義することは、クラス数を変更することを含む。いくつかの例では、分類規則を動的に定義することは、クラス数を低減することを含む。いくつかの例では、分類規則を動的に定義することは、クラス数を増加させることを含む。いくつかの例では、第２のＯＳのカーネル及びＲＴＯＳのアプリケーションの一方又は双方が、分類規則を動的に定義することに寄与している。例えば、第２のＯＳ上で実行されているアプリケーションが、特定のトランスポートプロトコル及び何らかのサービス品質（ＱｏＳ）要件を用いてデータを送受信する必要がある場合、十分なＱｏＳを確実にする優先度を有するこのトランスポートプロトコルに新たなクラスを割り当てることができる。そのような動的に定義された分類規則は、例えば方法１００、２００及び３００を含む、本明細書に記載の方法のうちの任意のものに適用することができる。

【0058】

本開示による方法のいくつかの例において、フレームプロセッサにおいて出力フレームを分類及びスケジューリングすることは、フレームプロセッサによって、分類規則に従って、ストリームクラス識別子を出力フレームにアタッチすることと、スケジューリングされた出力フレームのフレーム送信について、出力フレームのアタッチされたストリームクラスの時間及び優先度の双方に依拠して、スケジューリング規則を出力フレームに適用することとを含む。これは、例えば、ＲＴＯＳ、第２のＯＳ、又は更なるＲＴＯＳ若しくはＯＳに対応するＯＳの異なる複数のコアによる処理の後にキューの形成を編成することを可能にすることができる。そのようなアタッチ及び適用は、例えば、示される方法１００、２００及び３００のブロック１０９に含めることができる。

【0059】

図４は、処理コア４０１及び４０２と、メモリ４０３と備える例示的なマルチコアシステムオンチップ（ＳＯＣ）デバイス４００を示し、処理コア４０１及び４０２は、本明細書に記載の方法のうちの任意のものに従って動作するように構成される。一例において、処理コア４０１は、ＲＴＯＳを実装するＳＯＣ４００の第１のコアである。この例において、処理コア４０２は、カーネル空間４１４及びユーザー空間４１６を含む第２のＯＳを実装している、ＳＯＣ４００の第２のコアである。この例において、ＳＯＣは、ＳＯＣの外部のコンポーネント（図示せず）から第１のコア４０１において実装されるＲＴＯＳのＮＩＣ４１３に入力フレームを送信するＭＡＣ４０４を備える。入力フレームは、本開示の方法に従って、ＮＩＣ４１３から第１のコア４０１上で実装されるＲＴＯＳのフレームプロセッサ４１５にルーティングされる。本開示の方法によれば、フレームプロセッサ４１５は、本開示の方法に従って、入力フレームを、第１のコア４０１によって実装されるＲＴＯＳのシーケンサー４１７によって実行される１つ以上のタスク、又は第２のコア４０２上で実装される第２のＯＳのネットワークデバイスドライバー４１８に送信する。

【0060】

図４は、４００等のマルチコアＳＯＣデバイスの４０１及び４０２等の処理コアによって実行されると、処理コア４０１及び４０２に本明細書に記載の方法のうちの任意の１つを実行させる命令を含む、メモリ４０３等のコンピューター記憶媒体も示す。プロセッサ又は処理コア４０１及び４０２は、プロセッサ又は処理コア上で実行されているＯＳ又はＲＴＯＳによって管理される計算のための電子回路を含むことができる。

【0061】

本開示によるコンピューター可読記憶装置は、実行可能な命令を記憶する任意の電子、磁気、光又は他の物理的記憶デバイスであり得る。コンピューター可読記憶装置は、例えば、ランダムアクセスメモリ（ＲＡＭ）、電気的消去可能プログラマブルリードオンリーメモリ（ＥＥＰＲＯＭ）、記憶ドライブ、及び光ディスク等であり得る。本明細書によって説明されるように、コンピューター可読記憶装置は、本明細書によって説明される方法による実行可能命令で符号化され得る。

【0062】

記憶装置又はメモリは、本明細書によって説明されるような実行可能命令を記憶する任意の電子、磁気、光又は他の物理的記憶デバイスを含み得る。

【0063】

本開示によるいくつかの例において、単一のＳＯＣにおける、サービス及びアプリケーションと、異種ネットワークＱｏＳ（サービス品質）要件、セキュリティ制約及び実施複雑度との組み合わせが対処される。いくつかの場合、単一のＳＯＣにおいて、いくつかのアプリケーションは、強力なリアルタイム制約を有する場合があり、例えば、ネットワークイベントが生じるとき（例えば、メッセージの受信）、数ｐｓを超えるレイテンシをサポートすることができないことを意味する。この種のアプリケーションは、この場合、非常に低いレイテンシを得るように、ＲＴＯＳを介して実施される。ＳＯＣは、リアルタイム要件を有しないか又はソフトリアルタイム要件を有する他のアプリケーションもサポートすることができる。これらの他の非ＲＴＯＳアプリケーションは、頻繁な更新を伴う場合があり、ソフトウェアプラグインによって拡張される場合があり、複数のユーザー機能を含む。そのようなアプリケーションは、ＲＴＯＳではなく、カーネル空間及びユーザー空間を有するという点で汎用である、いわゆる汎用ＯＳにおいて実施することができる。そのような汎用ＯＳは、本開示による第２のＯＳの一例である。

【0064】

いくつかのアプリケーション要件は、汎用ＯＳ（Ｌｉｎｕｘ（登録商標）又はＶｘＷｏｒｋｓ等）又はＲＴＯＳのいずれかの排他的使用によって満たされない場合がある。そのようなアプリケーションは、実際に、ＲＴＯＳによるハンドリングのためのタイムセンシティブな態様と、ＲＴＯＳ単独でのハンドリングに適していない、複雑なよりタイムセンシティブでない態様（例えば、ユーザー空間を必要とする）との両方を含む。例は、制御ネットワークレイテンシアプリケーション、セキュリティアプリケーション、複数プロトコルスタックアプリケーション、又は異種能力（例えば、ＴＳＮ機能を含む）とのＨＷイーサネットインターフェースの統合／抽出を含む。

【0065】

本開示の方法を用いることができる環境の例は、プログラマブル論理コントローラーからのコマンドを受信するスレーブとして動作する産業通信デバイスである。そのようなデバイスは、デイジーチェーントポロジにおいてイーサネット通信ネットワークを通じてＰＬＣに接続することができる。そのようなデバイスは、以下のサービス及びアプリケーションを、括弧内に示されるＲＴ（リアルタイム）要件と統合することができる。
－周期的通信及び強力なＱｏＳの制約（レイテンシ、ジッター）を有する産業ネットワークプロトコル通信スタック（例えば、ＰｕｂＳｕｂ ＴＳＮ）［ハードＲＴ］、
－産業処理制御［ハードＲＴ］、
－Ｌ２イーサネット切り替え［ハードＲＴ］、
－ネットワーク管理プロトコル（例えばＴＳＮ管理）及びアプリケーション（例えば、構成／管理のためのウェブサーバー）［非ＲＴ］、
－産業ネットワーク管理プロトコル（例えば、ＯＰＣ－ＵＡクライアント／サーバー、ＯＰＣ－ＵＡは、オープンプラットフォーム通信統一アーキテクチャーを意味する）［非ＲＴ］、及び、
－第三者エッジコンピューティングプロセス［ソフトＲＴ、非ＲＴ］。

【0066】

いくつかの場合、本開示による方法は、単一のマルチコア処理ユニットを有する汎用ハードウェアプラットフォーム上で異種ネットワークＱｏＳ及びセキュリティ要件を有する重大なアプリケーションを実施することを可能にする。いくつかの場合、本方法は、アプリケーションのための各実行環境の利点を組み合わせることによって、汎用オペレーティングシステム（Ｌｉｎｕｘ（登録商標）又はＶｘＷｏｒｋｓ等）を、第２のＯＳ及びＲＴＯＳとして同時使用することに依拠する。第２のＯＳ及びＲＴＯＳのそれぞれがコアの所定のセットに対し実行される。いくつかの場合、第２のＯＳ及びＲＴＯＳは同じメモリ空間を共有する。いくつかの場合、第２のＯＳ及びＲＴＯＳは、ＳＯＣのＭＡＣ及びＲＴＯＳのＮＩＣ等の同じネットワークインターフェースを共有する。統合されたネットワーク周辺デバイスのそのような共有は、より高速な性能及び／又は増大したセキュリティを提供することができる。いくつかの場合、ＲＴＯＳは、例えば、汎用ＯＳネットワークドライバーにおいて行われる、ＨＷネットワークインターフェースの管理に関係するＳＷ（ソフトウェア）ブロック（ネットワークインターフェースコントローラー）を実施する。

【0067】

いくつかの場合、入力フレームの受信時に、そうでない場合そのような特徴（例えば、Ｒｘ－Ｐｒｏｃサブブロック）をサポートしないＨＷネットワークインターフェースについてフレーム構文解析及び分類が実施される。異なるリアルタイム制約を有するネットワークアプリケーションをサポートするのに必要なイーサネットフレーム処理の優先度を導入することができる。

【0068】

いくつかの場合、出力フレームを送信するとき、複数の送出キューをサポートするフレーム分類器が提供される。フレーム分類器は、例えば標準的なＨＷネットワークインターフェースを有する、ＩＥＥＥ８０２．１Ｑｂｖにおいて定義されているもの等の優先度又は時間認識スケジューラーのＳＷ実施を可能にすることができるフレーム送出スケジューラーと結合することができる。そのようなフレーム分類器及びスケジューラーは、Ｔｘ－Ｐｒｏｃサブブロックに含めることができる。

【0069】

いくつかの場合、第２のＯＳアプリケーションが、ＲＴＯＳによって管理されるネットワークインターフェースを用いることを可能にすることができる汎用ＯＳネットワークドライバーが提供される。このドライバーは、ＲＴＯＳ Ｒｘ－Ｐｒｏｃサブブロックから何らかのイーサネットフレームを受信し、イーサネットフレームをＴｘ－Ｐｒｏｃに送信することが可能である場合がある。以下の例示的な方式の双方が、ＲＴＯＳ及び汎用ＯＳのネットワークインターフェース共有に対処することができる。
－汎用ＯＳ（又は第２のＯＳ）サービス及びアプリケーションのための高速伝送を可能にするＲＴＯＳ管理メモリへの直接アクセスを可能にする１つの方式、及び、
－ＲＴＯＳ上で実行されている重大なネットワークタスクのためのセキュリティを強化する、汎用ＯＳ（又は第２のＯＳ）によるＲＴＯＳメモリアクセスにデータコピー及び制約を適用する１つの方式。

【0070】

本発明によるマルチコアＳＯＣデバイスの一例が図５に表されている。この例において、汎用ＯＳ（本開示において第２のＯＳとも呼ばれる）及び１つ以上のＲＴＯＳが同じネットワークインターフェースを共有する。この例では、汎用ＯＳ及びＲＴＯＳに専用のＣＰＵコアの再区分が静的に定義される。コア＃０へのリンクとして表されているが、汎用ＯＳは、ＳＭＰ（対称マルチプロセッシング）を用いて、２つ以上のＣＰＵコアに対し異なるカーネル及びアプリケーションプロセスを動的にスケジューリングすることができる。別個のＲＴＯＳを複数の専用コア（図５のコア＃１を含む）上で展開し、ＲＴＯＳに専用の１つ以上のコア上でアタッチ及び実行されるタスクのリストを実行することができる。代替的に、ＲＴＯＳに専用のコアのセット上で単一のＲＴＯＳが展開されてもよい。そのような場合、例えばＦｒｅｅＲＴＯＳ等の選択されたＲＴＯＳがＳＭＰモードをサポートすることができる。この場合、ＲＴＯＳ及び第２のＯＳ又は汎用ＯＳの双方が同じメモリ空間を共有し、それによって、ＲＴＯＳタスク及び汎用ＯＳカーネル又は第２のＯＳカーネルが、キュー、フレームメタデータ、及びフレームデータバッファーのコンテンツにアクセスすることができる。この例において、汎用ＯＳ又は第２のＯＳにおいて実行されているネットワークメモリマネージャーは、この共有メモリ空間の管理、特に、受信されるフレーム又は送信されるフレーム、すなわち入力フレームを記憶するための空いているデータバッファーの提供を担当する。

【0071】

第１の場合として、いくつかのメモリエリアを汎用ＯＳとＲＴＯＳとの間で共有することができ、それによって、ＲＴＯＳにおいてＮＩＣによって操作されるフレームデータバッファーのコンテンツに、ＯＳネットワークデバイスドライバーによってアクセスすることができる。そのような場合、汎用ＯＳにおいて実行されるアプリケーションのより良好な性能を提供するデータコピーは必要とされない。第２の場合として、フレームデータバッファーは、特に、機密情報を保有する場合があるＲＴＯＳによって管理される非暗号化プロトコルについて、セキュリティを強化するためにプライベートメモリエリアに記憶することができる。その場合、汎用ＯＳに対し意図され、それに応じてフレームプロセッサにおいて分類されるデータフレーム（入力フレーム）を受信するとき、追加のコピーステップが必要とされる場合がある。

【0072】

図５に示す例において、ＨＷネットワークインターフェース（ＭＡＣインターフェース）はＲＴＯＳによって制御される。ＲＴＯＳに割り当てられるコアの数が２以上であるとき、単一のＲＴＯＳコアは、単一のＮＩＣとしてネットワークインターフェースを制御するように指定することができる。この場合、各ＮＩＣは、例えばイーサネットブロックの受信／送信に用いられるＨＷキューの管理を担当する受信処理（入力フレームを処理するためのＮＩＣ－Ｒｘ）ブロック及び送信処理（出力フレームを処理するためのＮＩＣ－Ｔｘ）ブロックを含む。そのような処理は、受信（入力）フレーム又は送信（出力）フレームに関連するメタデータを含むいくつかのバッファー記述子（ＢＤ）を操作することを含むことができる。

【0073】

図５に示す例において、Ｒｘ処理ブロック（Ｒｘ－Ｐｒｏｃ、本開示によるフレームプロセッサの一部）は、受信したイーサネットフレーム又は入力フレームの解析を担当するネットワークプロトコルパーサー（ＴＣＰ／ＩＰ／産業プロトコル等のイーサネット／高次レイヤ）を含む。構文解析結果に基づいて、各フレームが分類され、所与のキュー内に置かれる。Ｒｘ－Ｐｒｏｃ構成サブブロックを用いて、構文解析規則、及び分類プロセス後に受信入力フレームを記憶するのに用いられるキューを動的に定義／調整することができる。キューは、ＲＴＯＳ上で実行されているタスク、又は汎用ＯＳ若しくは第２のＯＳに対し実行されているアプリケーション若しくはプロトコルスタックに専用とすることができる。いくつかの場合、キューは、任意のデータコピーを回避して、フレームに関係するメタデータのみを含むことができる。いくつかの特定のＲＴＯＳタスクによって処理されるトラフィックのためにいくつかの専用キューを用いることにより、サポートされるアプリケーション及びサービスについて異なる処理優先度を管理することが可能になる。このため、ＲＴＯＳシーケンサーは、より高い優先度を有するタスクが、より低い優先度を有するタスクよりも前に受信フレーム（入力フレーム）を処理することを確実にする。これは、単一のキューが用いられる場合には当てはまらない。

【0074】

図５に示す例において、ＲＴＯＳタスク専用のキューは、次に、対応するＲＴＯＳタスクによって、到来するネットワークデータフレームを索出するようにポーリングされる。この方式において、異なるＲＴＯＳアプリケーションタスクが単一のトランスポートプロトコルを共有することができるように、ＴＣＰ／ＩＰスタック又は任意の他のプロトコルスタックを挿入することができる。汎用ＯＳ又は第２のＯＳのアプリケーション又はプロトコルスタック（すなわち、非ＲＴＯＳタスクに関係する）に対し意図されたトラフィックに専用のキューは、汎用ＯＳ又は第２のＯＳのネットワークデバイスドライバーによってポーリングされる。次に、データフレームは、汎用（本開示によれば第２の）ＯＳネットワークデバイスＡＰＩ（アプリケーションプログラミングインターフェース）を遵守して、例えば汎用ＯＳネットワークバッファー（Ｌｉｎｕｘ（登録商標）においてソケットバッファー又はＳＫＢと称される）にカプセル化される。

【0075】

図５に示す例において、送信処理（Ｔｘ－Ｐｒｏｃ）ブロック（本開示によるフレームプロセッサに含まれる）は、出力フレームとしての送信を待機する、ＲＴＯＳアプリケーション又は汎用ＯＳ若しくは第２のＯＳのネットワークデバイスドライバーによって送信された保留中のフレームに関係するメタデータを記憶する送信キューのセットを含む。例えばＴＳＮ拡張を用いるとき、異なるスケジューリング戦略を用いてネットワークフレーム優先度を決定することができる。例えば、ＩＥＥＥ８０２．１Ｑｂｖ規格のいくつかの実装は、８個のそれぞれの送信キューを用いた８つのトラフィッククラス（ＴＣ）間の分類に基づくことができる。本開示による方法のいくつかの場合、複数のキューが複数のクラスに対応する。他の実施態様は、ストリームごとに専用キューを割り当てる制約を有するストリーム分類（ストリームは、宛先アドレス及びＶＬＡＮ（仮想ローカルエリアネットワーク）ＩＤ（識別子）の関連付けとすることができる）に依拠することができる。分類器サブブロック（本開示によるフレームプロセッサに含まれる）は、この場合、送信フレーム又は出力フレームを送出又は送信前に記憶することができるキューの選択を担当する。このタスクを実行するために、分類器は、ＶＬＡＮ優先度、ストリーム識別子等のようなフレームに関するいくつかのメタデータを用いることができる。例えば、分類器がトラフィッククラスをサポートする場合、分類器は、ＶＬＡＮ ＰＣＰ（優先度コードポイント）及びマッピングを用いて、いずれのトラフィッククラスが所与のＰＣＰに関連付けられるかを選択することができる。ＲＴＯＳシーケンサーは、採用されたスケジューリング戦略を遵守するために出力フレームの送出の制御を担当する。例えば、ＩＥＥＥ８０２．１Ｑｂｖ規格によって定義される時間認識スケジューラーが有効にされる場合、出力フレームは特定のタイムウィンドウにおいて送出される。これは、スケジューラーが特定の時点にフレームを送信することが可能であるべきことを意味する。ＲＴＯＳの使用に起因して、多数のアプリケーションに十分であり得るＰＴＰ（精密時間プロトコル）クロックに基づくタイマー、及び精緻なキュー管理を組み合わせることによって、かなりの精度（＜１ｐｓ）を達成することが可能である。分類及びマッピング規則、並びにスケジューリングパラメーターは、Ｔｘ構成サブモジュールを通じて動的に定義することができる。

【0076】

図５に示す例において、ＨＷネットワークインターフェースに関係する割り込みは、大域割り込み制御モジュール（例えば、ＡＲＭアーキテクチャーにおいてＧＩＣと称される）によって管理される。このモジュールは、ネットワーク割り込みが、ネットワークインターフェースコントローラーを実行しているＲＴＯＳコアにルーティングされるようにプログラミングすることができる。

【0077】

図５に示す例において、ＲＴＯＳタスクは、動的に作成することができ、ＲＴＯＳシーケンサーによって、優先度によりスケジューリングすることができる。ＲＴＯＳタスクは、ＲＴＯＳ－ＲＸブロックにおいて定義されたキューをポーリングすることによって、データフレーム又は入力フレームを受信することができる。ＲＴＯＳタスクは、データフレーム又は出力フレームを、ＲＴＯＳ－ＴＸブロックに送信することによってそれらを送信することもできる。タスク処理は、データフレーム（入力フレーム）の受信によって、又は内部タイマーによってトリガーすることができる。

【0078】

図５に示す例において、ＰＴＰプロトコルを用いてローカルクロックをネットワーククロックに同期させる。ＰＴＰ時間制御プロトコルは、非常に良好な精度（＜１００ｎｓ）を達成するためにハードウェアフレームタイムスタンプ処理に基づくため、いくつかのリアルタイム機能を必要としない。フレームが受信（入力フレーム）又は送信（出力フレーム）されるとき、ＭＡＣは、フレームメタデータに受信／送信時間を追加する。いくつかの例では、ＩＥＥＥ１５８８機能をサポートするＭＡＣは、ＰＴＰクロックによってトリガーされたＨＷタイマーも提供する。この場合、ＰＴＰ制御アプリケーション（ＰＴＰタイムクロックを調整するのに用いられる）は汎用ＯＳ又は第２のＯＳ上で実行されている（例えば、プロトコル、サーボ制御アルゴリズム及びポータビリティの観点における柔軟性に起因する）が、ＰＴＰタイムスタンプ処理は、受信／送信時間を取得し、これらを、キューメカニズムを通じて汎用ＯＳに報告するために、ＲＴＯＳによってサポートすることができる。この例において、ＲＴＯＳ側でＰＴＰタイマー制御も実施される。

【0079】

図６は、本開示によるフレームプロセッサの一部分の例を示す。この例において、ＲＴＯＳフレームプロセッサのＲｘ－Ｐｒｏｃブロックは、ＮＩＣによって受信された入力フレームの処理を担当し、この入力フレームを、ＲＴＯＳタスク（例えば、重大なネットワークタスク）、又は汎用ＯＳ若しくは第２のＯＳのカーネルネットワークデバイスドライバーによってポーリングされたＲＸキューのうちの１つにポストする。

【0080】

図６におけるＮＩＣは、入力フレームデータと、フレームサイズと、入力フレームが受信されたインターフェースのインデックス（又は識別子）を含むバッファーへの参照を提供する。

【0081】

図６において、入力フレームは、フレームプロセッサのパーサーサブブロックによって、例えばＲｘ－Ｐｒｏｃ構成空間（オフセット位置及びサイズを有するフィールドのリスト等）において定義されたプロトコル及び符号化タイプを用いて構文解析される。解析されたプロトコルがＴＣＰ／ＩＰプロトコルを介してトランスポートされるとき、ＶＬＡＮ ＩＤ、ＩＰアドレス、ＴＣＰ（伝送制御プロトコル）又はＵＤＰ（ユーザーデータグラムプロトコル）ポート等の関連パラメーターが抽出される。フレームデータ及び関連パラメーターは、フレームプロセッサのフレーム分類サブブロックに渡される。Ｒｘ－Ｐｒｏｃ構成空間において定義された分類規則を適用することによって、パラメーターを用いて入力フレームを分類する。この動作の結果として、ストリームクラス識別子が入力フレームにアタッチされる。フレーム及びストリームクラスＩｄは、フレームプロセッサのキュー識別サブブロックに渡される。ストリームクラス識別子を用いて、入力フレームが１つのＲＴＯＳタスク又は汎用ＯＳ若しくは第２のＯＳのカーネルネットワークデバイスドライバーによる更なる処理のためにポストされるキューが決定される。

【0082】

図７は、例えば、例示的なフレームプロセッサを形成するように図６に示す部分と結合することができる、本開示によるフレームプロセッサの一部分の例を示す。図７において、ＲＴＯＳフレームプロセッサのＴｘ－Ｐｒｏｃブロックは、ＲＴＯＳネットワークアプリケーションタスク又は汎用ＯＳ若しくはソースＯＳのカーネルネットワークデバイスドライバーによって送信された出力フレームの処理を担当し、ＲＴＯＳのＮＩＣのうちの１つに適時に出力フレームを送るか又は送信する。フレームプロセッサは、フレーム分類器を備え、サポートされる各ＮＩＣのフレームスケジューラーも備える。

【0083】

図７において、分類器は、汎用ＯＳ若しくは第２のＯＳのカーネル又はＲＴＯＳタスクによってポストされた出力フレームを、ＶＬＡＮタグ又はフレームサイズ等の関連パラメーターと共に受信する。次に、フレームプロセッサは、データフレームから、例えばプロトコル定義を用いてＭＡＣアドレス等の出力フレーム分類に関連する何らかの追加情報を抽出する。次に、フレームプロセッサのフレーム分類サブブロックは、Ｔｘ－Ｐｒｏｃ構成空間において定義された分類規則からストリームクラスＩｄを決定することが可能である。

【0084】

図７において、ストリームクラスＩｄに基づいて、Ｔｘ－Ｐｒｏｃ構成空間において定義されたキューマッピング定義から、スケジューラーキューインデックスが決定される。例えば、ＴＳＮ ＩＥＥＥ８０２．１Ｑｂｖ時間認識トラフィックスケジューラーが４つのトラフィッククラス（ＴＣ）と共に用いられる場合、トラフィッククラスごとに１つずつ、４つのスケジューラーキューが定義される。本開示のいくつかの例によれば、キューの数は、スケジューラーのトラフィッククラスの数に等しい。

【0085】

図７において、スケジューラー構成は、ＮＩＣごとの使用されるスケジューラーのタイプ、及び関連構成パラメーターを含む。この例において、構成パラメーターは、所与のＴＣを有する各出力フレームを送出又は送信することができる期間を定義する開／閉ゲートのリストを含む。この例において、スケジューラーの役割は、定義されたスケジューリング規則を適用し、ＮＩＣに送信される次の出力フレームを選択することである。スケジューリング規則が優先度のみでなく時間に依拠するとき（ＴＳＮ ＩＥＥＥ８０２．１Ｑｂｖ時間認識トラフィックスケジューラー等）、スケジューラーは、高い優先度を有するＲＴＯＳタスクとして実施することができる。次に、出力フレームは、ＰＴＰクロックに基づいて厳密な所与の時点にＮＩＣに渡すことができる。

【0086】

いくつかの場合、セキュリティは、マルチコアＳＯＣのために適切なメモリ管理によってハンドリングすることができる。いくつかの場合、汎用ＯＳ又は第２のＯＳは、ＳＫＢと称されるいくつかのバッファー記述子を操作して、データフレーム及びいくつかの関係メタデータ（パケット長）を操作することができる。ＳＫＢは、「ネットワークメモリマネージャー」と呼ばれるモジュールを介して汎用ＯＳ又は第２のＯＳのカーネルによって割り当て／解除することができる。本開示による例示的な方法は、汎用ＯＳ若しくは第２のＯＳのネットワークデバイスドライバーからの直接フレームバッファーアクセス、又は間接的フレームバッファーアクセスをサポートすることができる。

【0087】

本開示による例示的な方法によってサポートすることができる直接バッファーアクセスの例が図８に示される。

【0088】

図８において、直接バッファーアクセスは、フレームデータを記憶するために用いられるバッファーが汎用ＯＳ又は第２のＯＳとＲＴＯＳとの間で共有されるという意味で行われる。利点は、汎用ＯＳとＲＴＯＳ領域との間でデータコピーがないことによる、より高速なデータ処理である。ＲＴＯＳネットワークインターフェースコントローラーは、図８に示すように、ＳＫＢ（又はカプセル化された入力フレーム）を操作することができる。例えば図８に示すように、ＲＴＯＳフレームプロセッサの内部キューは、ＳＫＢへの参照を記憶し、ＳＫＢの割り当て／解除を行うために汎用（又は第２の）ＯＳメモリマネージャープリミティブを呼び出すことができる。これらのＳＫＢは、ＲＴＯＳと汎用（又は第２の）ＯＳネットワークドライバーとの間で直接交換することができる。受信時に、ＳＫＢ割り当ては、ＭＡＣによって埋められた入力フレームをハンドリングするＮＩＣ－Ｒｘサブブロックによって第２のＯＳメモリマネージャーに要求することができ、次に、（フレームプロセッサによる構文解析／分類後に）第２のＯＳカーネルネットワークスタックに渡すことができ、汎用ＯＳ又は第２のＯＳによって処理することができる。次に、ＳＫＢは、第２のＯＳのカーネルネットワークプロトコルスタックによって、カプセル化された出力フレームとして解除することができる。出力フレームの送信時、第２のＯＳカーネルネットワークプロトコルスタックは、ＳＫＢを割り当て、これらをＲＴＯＳフレームプロセッサに送信する。ＳＫＢ解除は、イーサネットフレームがネットワークインターフェースによって効率的に送信されると、ＮＩＣ－Ｔｘサブブロックによって第２のＯＳメモリマネージャーに要求される。そのような例示的な方法の潜在的制約は、ＲＴＯＳ及びサポートされるアプリケーションによって用いられるフレームデータバッファーにメモリアクセスを制約することの難易度に関係付けることができる。これは、これらのアプリケーションが暗号化をサポートしないときに関連することができる。別の潜在的な制約は、いくつかの場合、ＲＴ要件に準拠しない場合があるＲＴＯＳにおいて、動的ＳＫＢ割り当て／解除手順の呼び出しを引き起こすことであり得る。

【0089】

本開示による例示的な方法によってサポートすることができる間接的バッファーアクセスの例が図９に示される。

【0090】

間接的なバッファーアクセス方式の図９に示す例において、ＲＴＯＳフレームプロセッサは、ＲＴＯＳタスクによって排他的に達成可能なネットワークバッファー（ＮｅｔＢｕｆ）を扱う。この例において、ＲＴＯＳ ＮｅｔＢｕｆマネージャーを用いてＮｅｔＢｕｆを管理し（割り当て及び解除動作等）、入力及び出力フレームのＳＫＢカプセル化／脱カプセル化動作を行って、フレーム（例えばイーサネットフレーム）を汎用（又は第２の）ＯＳネットワークドライバーと交換する。図９に示すように、そのような動作中、フレームデータは、ＳＫＢ脱カプセル化／カプセル化ブロックによってＮｅｔＢｕｆとＳＫＢとの間でコピーされる。

【0091】

図９の例における入力フレームの処理は、入力フレームの受信時にＮＩＣ－Ｒｘによって割り当てられ、ＨＷ ＭＡＣによって埋められたＮｅｔＢｕｆを含む。そのような入力フレームは、この例において、構文解析及び分類動作を行うＲｘ－Ｐｒｏｃによって処理され、キューを介してＯＳネットワークドライバーに渡される。キューは、ＮｅｔＢｕｆ及び関係メタデータ（例えば、パケット長等）への参照を記憶する。ＳＫＢは、「ＳＫＢカプセル化」サブブロックによって割り当てられ、データはＮｅｔＢｕｆからＳＫＢにコピーされ、ＮｅｔＢｕｆが解除される。この例において、送信時、ＮｅｔＢｕｆは、汎用ＯＳカーネルネットワークプロトコルスタックによって送信される任意のフレームについて、ＳＫＢ脱カプセル化によって割り当てられる。データはＳＫＢからＮｅｔＢｕｆにコピーされ、ＮｅｔＢｕｆは、出力フレームとしてＲＴＯＳフレームプロセッサ（Ｔｘ－Ｐｒｏｃ）に渡され、関係ＳＫＢが解除される。ＮｅｔＢｕｆは、ＭＡＣによって送信されると、出力フレームとしてＮＩＣ－Ｔｘサブブロックによって解除される。

【0092】

図９に示す方式の利点は、ＲＴＯＳメモリがプライベートであり、例えばＡＲＭ ＴｒｕｓｔＺｏｎｅ等のＨＷセキュリティメカニズムによって保護することができることである。これにより、汎用（第２の）ＯＳ側からネットワークバッファーにアクセスすることが阻止される。別の利点は、ＮｅｔＢｕｆ割り当て／解除に用いられるルーチンを、ＲＴ実装のために最適化することができることである。可能な実施は、セットアップ時に行われた静的バッファーの割り当てと、バッファーの割り当てのためにキューから取り出され、バッファーが解除されるときにキューに入れられる空きバッファーリストとに依拠することを含む。そのような方式は、汎用（第２の）ＯＳによって受信された入力／送信された出力フレームごとにフレームデータコピー動作を追加する。この方式は、例えば、セキュリティが関心事であるとき、特に、ＲＴＯＳアプリケーションによって用いられる通信プロトコルがセキュア化されていないとき（すなわち、暗号化なし、認証なし）に利用することができる。この方式は、汎用（第２の）ＯＳ上で実行されているアプリケーションが、帯域幅の観点で低減した性能要件を有するか又は性能要件を有しないときにも選択することができる。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】