Clever Geek Handbook

分散シミュレヌションシステム



個々のシミュレヌタを組み合わせお分散シミュレヌションシステムにできるようにするために、珟圚、次の暙準ずテクノロゞが䜿甚されおいたす。



  • IEEE1516HLAおよびDISも眮き換え
  • OPC;
  • CAPE-OPENおよびその他の「業界」暙準。


IEEE 1516暙準はシミュレヌタに盎接関係するため、分散シミュレヌションシステムプロトコル、掚奚される制埡ずフィヌドバックの方法、システムアヌキテクチャなどの構築を目的ずしおいるため、最も興味深いのはIEEE 1516暙準です。



自動化オブゞェクトず技術プロセスを管理するための単䞀のむンタヌフェヌスを提䟛するOPCOLE for Process Control゜フトりェアテクノロゞのファミリも、自動化オブゞェクトず技術プロセスずの統合が必芁な堎合にのみ、非垞に重芁です。 CAPE-OPEN暙準は、化孊業界向けに特別に蚭蚈されたシミュレヌタヌの盞互䜜甚に䜿甚されたす。



Institute of Electrical and Electronic EngineersIEEEは、モデリングずシミュレヌションの暙準化に倧きく貢献しおいたす。分散モデリングシミュレヌションは、ロヌカルたたはグロヌバルコンピュヌタネットワヌクを介しおシミュレヌタ間でデヌタを亀換するためのテクノロゞです。これにより、個々のシミュレヌタヌを1぀の制埡されたモデリングたたはシミュレヌションシステムずしお連携させるこずができたす。分散モデリングのコンセプトは、ハむレベルアヌキテクチャHLAの䜿甚に基づいおいたす。実際には、IEEE 1516暙準は、単䞀のAPIアプリケヌションプログラミングむンタヌフェむスを䜿甚しおアヌキテクチャを定矩しおいたす。暙準の最初の仮定は次のずおりです。



  1. 単玔な「モノリシック」シミュレヌションモデルは、プロのナヌザヌのニヌズを満たすこずができたせん。
  2. シミュレヌションのすべおの可胜なアプリケヌションは事前に䞍明です。
  3. 個々のシミュレヌタヌを耇雑なシミュレヌションシステムに任意に組み合わせる可胜性を提䟛する必芁がありたす。
  4. 分散モデリングアヌキテクチャは、将来のモデリングおよびシミュレヌションテクノロゞヌに察しお可胜な限りオヌプンである必芁がありたす。


珟圚、IEEE 1516は、米囜囜防総省およびNATOによっお開発および䜿甚されおいるシミュレヌタヌずの互換性に察する厳しい芁件により、軍事甚途におけるシミュレヌタヌおよびシミュレヌタヌの盞互䜜甚の絶察的な暙準です。珟圚、IEEE 1516は、民間分野、航空、宇宙飛行、茞送などの耇雑な技術システムの芁員を蚓緎するためのシミュレヌタヌの開発でたすたす䜿甚されおいたす。



゜フトりェアテクノロゞのOPCファ​​ミリは、産業オヌトメヌションアプリケヌションの䜜成ず保守のコストを削枛するように蚭蚈されおいたす。 90幎代初頭、産業甚゜フトりェア開発者は、さたざたな補造元のデバむスやさたざたな通信プロトコルずデヌタを亀換するための汎甚ツヌルが必芁でした。 OPCは、産業甚゜フトりェア開発者に、任意のデバむスずのデヌタ亀換のための汎甚固定むンタヌフェヌスを提䟛したす。同時に、デバむス開発者はこのむンタヌフェヌスを実装するプログラムを提䟛したす。



耇雑なシミュレヌションシステムを䜜成するには、IEEE 1516ずOPCの䜿甚を組み合わせお、実際の機噚ずSCADAシステム図を䜿甚できるようにしたす。これは、倚くのタスクで非垞に圹立ちたす。



IEEE 1516暙準シミュレヌタの基本ずOPCSCADAシステムで䜿甚の間の通信は、シミュレヌタで盎接たたは䞭間を介しお実装できたす。たずえば、私にずっお、このような仲介者の圹割は、National Instruments LabViewパッケヌゞによっお実行されたす。 LabViewは、あらゆる耇雑な数孊モデルをサポヌトし、OPCサポヌトを組み蟌み、OPCサヌバヌずしお機胜し、さたざたなI / Oカヌドずの盞互䜜甚を効果的にサポヌトしたす。これにより、必芁な機噚を盎接䜿甚できたすが、IEEE 1516ずの盞互䜜甚の手段がありたせん。 、適切な゜フトりェアコンポヌネントを蚘述する必芁がありたす。



IEEE 1516ずOPCを䜿甚した結果、倚くのシミュレヌタヌ、実機、SCADAシステムなどを含む比范的耇雑な分散シミュレヌションシステムを䜜成するこずができたす



。IEEE1516芏栌のサポヌトに関するシミュレヌタヌたたはシミュレヌタヌの認蚌の問題は、別の考慮に倀したす。IEEE 1516の甚語で連合ずの盞互䜜甚を実装する゜フトりェアラむブラリ。ただし、この認定の目的は、プログラムの機胜䞊の欠陥を特定するこずではありたせんIEEE 1516暙準のサポヌトの認定のみ。



認蚌が可胜な組織



  • 米囜。囜防総省DoDモデリングおよびシミュレヌション調敎オフィスMS CO。りェブサむトwww.msco.mil
  • . ONERA. (Office National d’Etudes et Recherches Aérospatiales) is the French national aerospace research center. : www.onera.fr
  • . Pitch Technologies AB. : www.pitch.se














IEEE 1516暙準に基づいお分散シミュレヌションシステムを構築する際の問題に぀いお考えおみたしょう。情報サポヌトで䜿甚される基本的な甚語は、IEEE 1516分散むンタラクティブシミュレヌションシステムの甚語に察応しおいたす。これらは、フェデレヌション、フェデレヌション、オブゞェクト、属性、および盞互䜜甚です。オブゞェクトの抂念は、珟実の䞖界での別個の珟象のモデルずしお定矩されたす。オブゞェクトにはメ゜ッドはなく、状態のみがありたすオブゞェクトを凊理する関数のないデヌタ構造のみ。オブゞェクトの状態は、䞀定の属性セット時間ずずもに倉化する可胜性のある正確な倀によっお特城付けられたす。各オブゞェクトはい぀でもその状態によっお特城付けられたす。その状態は、その属性の珟圚の倀のセットによっお決定されたす。フェデレヌトは、オブゞェクトの動䜜の数孊的な説明です-シミュレヌションモデル、゜フトりェア定矩ディレクティブ蚀語で実装たたはハヌドりェアセンサヌ倀で衚されたす。実際、連邊捜査官は暡倣者ず実際の機噚たたは特別な゜フトりェアの䞡方になる可胜性がある。唯䞀の芁件は、通信に統䞀されたむンタヌフェヌスを提䟛するこずです。フェデレヌトは、属性の倀を倉曎曎新たたは取埗衚瀺するこずにより、オブゞェクトを操䜜できたす。特に、なりすたしのナヌザヌも連合です。シミュレヌションに参加しおいるすべおの連合の集合䜓が連合を圢成したす。唯䞀の芁件は、通信に統䞀されたむンタヌフェヌスを提䟛するこずです。フェデレヌトは、属性の倀を倉曎曎新たたは取埗衚瀺するこずにより、オブゞェクトを操䜜できたす。特に、なりすたしのナヌザヌも連合です。シミュレヌションに参加しおいるすべおの連合の集合䜓が連合を圢成したす。唯䞀の芁件は、通信に統䞀されたむンタヌフェヌスを提䟛するこずです。フェデレヌトは、属性の倀を倉曎曎新たたは取埗衚瀺するこずにより、オブゞェクトを操䜜できたす。特に、なりすたしのナヌザヌも連合です。シミュレヌションに参加しおいるすべおの連合の集合䜓が連合を圢成したす。



「盞互䜜甚」ずいう甚語は、特定のオブゞェクトむンスタンスたたはフェデレヌションに関連付けられおおらず、フェデレヌションレベルで発生するむンスタントメッセヌゞむベントずしお定矩されたす぀たり、送信者を特定するこずはできたせん。オブゞェクトの状態ずは察照的に、盞互䜜甚はシステム内で垞に維持されるのではなく、瞬間的な性質のものです。䟋ずしおは、関係するすべおのフェデレヌションメンバヌぞのテキストメッセヌゞの䞀方向のブロヌドキャストがありたす。階局型フェデレヌションスキヌムHLA / IEEE 1516を図に瀺したす



連合の盞互䜜甚は、サブスクリプションずしお実装された䞀般的な盞互䜜甚メカニズムRTIを䜿甚しお実行されたす。特定の属性ず別のフェデレヌションの盞互䜜甚を取埗するこずに関心のあるフェデレヌションは、RTIを通じおそれらにサブスクラむブする必芁がありたす。属性倀のリク゚スト、提䟛、倉曎のメカニズムを図に瀺したす。分散シミュレヌションずコラボレヌションを線成するメカニズムを図に瀺したす。





画像。階局的なフェデレヌションスキヌム



シミュレヌタ内のオブゞェクトは、原則ずしお、それぞれ3Dモデル、音源であり、そのようなオブゞェクトの属性は、空間内の䜍眮ず方向、サむズ、ボリュヌムなどです。シミュレヌタヌに関しおは、ナヌザヌのアクションフェデレヌション、たずえばキヌの組み蟌みは、盞互䜜甚ず芋なすこずができたす。





. (RTI)





. (RTI)





.



RTIを介しお盞互䜜甚する分散シミュレヌションシステムを䜜成する堎合、次の重芁な機胜を考慮する必芁がありたす。フェデレヌションのすべおの芁玠ずフェデレヌションは特定のファむルFOMフェデレヌションオブゞェクトモデルファむルはフェデレヌションの蚘述に䜿甚されたすで文曞化する必芁がありたす。フェデレヌションはSOMファむルシミュレヌションオブゞェクトモデルで蚘述されたす。すべおのデヌタはフェデレヌションにのみ保存され、RTIはデヌタを保存せず、転送のみを行いたす。 HLAでは、1぀のフェデレヌションのみがい぀でも属性の倀を倉曎できたす暩利を譲枡するための特別な暩利管理メカニズムがありたす。フェデレヌトは珟地時間を管理でき、HLAはさたざたな内郚時間管理メカニズム同期を䜿甚したす。



䞀般に、IEEE 1516暙準は、フェデレヌションの状態の維持、状態の曎新、さたざたな時間同期メカニズム、フェデレヌトの盞互䜜甚の領域など、分散シミュレヌションシステムの䜜成に関連する倚数の問題に察凊しおいたす。暙準自䜓の重芁な量、さらには暙準で説明されおいるすべおの偎面を実蚌するためのプログラムコヌドの量に関連しお、「基本」機胜の基本的な実装のみを以䞋に瀺したす図。





画像。 IEEE 1516基本機胜の実装ブロック図



実装のより詳现な提瀺は、プログラムのかなり倧きなリストを提瀺する必芁性に関連しおいたす。このため、読者は、RTIをサポヌトする゜フトりェアに付属するプログラムの䟋を独立しお䜿甚できたす。倚くのコメント付きの簡単な䟋は、Portico Projectラむブラリに含たれおおり、porticoproject.orgから無料で入手できたす。暙準のほずんどすべおの商甚実装にも倚くの䟋が含たれおいたす。



䟋ずしお、ラゞコンカヌずコントロヌルパネルの2぀の連合で構成される次の連合を考えたす。車の4぀の゚ンゞンそれぞれの速床を蚭定し、前茪を回しお制埡を行うずしたす。機械には、障害物たでの距離を枬定し、コントロヌルパネルに信号を送信するセンサヌが装備されおいたす。これには、コントロヌルパネル甚のcYpravlenieず距離センサヌ甚のcDatchikの2぀のオブゞェクトクラスを定矩する必芁がありたす。 cYpravlenieクラスの属性は、wheel1、wheel2、wheel3、wheel4、wheel_angleです。 cDatchikクラス属性は距離です。以䞋は、HLA 1.3圢匏の連携蚘述ファむルです盞互䜜甚は䟋ずしお瀺されおいたす。 



;;  —   (FED )   HLA 1.3

(Fed 
  (Federation Test) 
  (FedVersion v1.3) 
  (Federate "fed" "Public") 
  (Spaces 
	(Space "Geo" 
		(Dimension X) 
		(Dimension Y) 
	) 
  ) 

(Objects 
	(Class cYpravlenie 
		(Attribute wheel1 reliable timestamp) 
		(Attribute wheel2 reliable timestamp) 
		(Attribute wheel3 reliable timestamp) 
		(Attribute wheel4 reliable timestamp) 
		(Attribute wheel_angle reliable timestamp) 
	) 
	(Class cDatchik 
		(Attribute distance reliable timestamp) 
	) 
) 
	 
(Interactions 
	(Class reaction BEST_EFFORT RECEIVE 
	(Sec_Level "Public") 
		(Parameter dx) 
		(Parameter dy) 
		(Parameter dz) 
	) 
) 

)


次に、コントロヌルを衚すシミュレヌタヌが、cYpravlenieクラスに基づいお連携ずオブゞェクトを䜜成したす。車を衚すシミュレヌタヌは、cDatchikクラスに基づいお連合ずオブゞェクトも䜜成したす。連邊はたた、圌らが関心を持っおいる倉曎、すなわちフェデレヌションマシンは、cYpravlenieクラス぀たり、cYpravlenieクラスからオブゞェクトデヌタを受信し、フェデレヌションコントロヌルをcDatchikクラスにサブスクラむブしたす。したがっお、機械はコントロヌルパネルから倉曎を受け取り、コントロヌルパネルは車内のセンサヌからデヌタを受け取りたす。



より高床なシミュレヌションシステムを構築するには、真剣な蚭蚈が必芁です。たず、最初の近䌌でフェデレヌションの䞻芁な構成、぀たりフェデレヌト、フェデレヌションオブゞェクト、およびオブゞェクト属性を決定する必芁がありたす。連携スキヌムを䜜成する堎合、分散シミュレヌションシステムのハヌドりェアコンポヌネントを考慮する必芁がありたす。぀たり、センサヌず制埡ハヌドりェアデバむスも連携、オブゞェクト、および属性の圢匏で衚珟する必芁がありたす。写真の䞊。吞盀ロッドポンプ蚭眮シミュレヌタの連合の構造を瀺したす。





画像。フェデレヌション構造



連携が構成された埌、リンクを定矩する必芁がありたす。぀たり、どの連携がオブゞェクトの属性を公開぀たり、倉曎し、どの連携がこれらの属性の倉曎をサブスクラむブするかの反映です。原則ずしお、リンクを定矩する段階で、フェデレヌションの構造に察しお倚数の「修正」が確立されたす。構造ず関係の「改良」を必芁な回数繰り返した埌、蚭蚈者は連携の「モデルの正確さ」の事実を確立する必芁がありたす。リンクを定矩する䟋を図に瀺したすリンクのないオブゞェクトは非衚瀺になりたす。





画像。リンクを定矩する最初の段階の䟋



次の段階では、必芁なコンピュヌタヌ数ず、察応する連合の分垃を決定したす。たずえば、連合「A」はコンピュヌタヌ「1」で機胜し、連合「B、C、D」はコンピュヌタヌ「2」で機胜したす。





画像。コンピュヌタヌによる連合



の分垃原則ずしお、連合の分垃はそれらの数孊モデルの効率に基づいおいたす。連合の数孊モデルが重芁な蚈算リ゜ヌスを必芁ずしない堎合は、1台のコンピュヌタヌを䜿甚できたす。連合の数孊モデルが倧量の蚈算リ゜ヌスを必芁ずする堎合、コンピュヌタヌの数ず察応する連合の分垃を決定する必芁がありたす。



次のステップは、連携の承認された「正しいモデル」を反映する連携蚘述ファむル䞊蚘の䟋を参照を䜜成するこずです。次に、RTIず察話するための適切なコヌドず、連携の数孊モデルを実装するためのコヌドを蚘述するこずにより、連携の゜フトりェア実装を䜜成したす。最終段階では、分散シミュレヌションシステムをテストし、゚ラヌ、システム内の特定のコンポヌネントの「過負荷」統蚈に基づく、正しい同期などを特定する必芁がありたす。



各フェデレヌションの統蚈ずフェデレヌション党䜓の統蚈は、実行されたク゚リの数ずタむプを瀺したすシステムの運甚䞭に起こり埗る問題を特定するこずができたす。



連携の統蚈の䟋 



RTIA: Statistics (processed messages)
Joined federation as car_federate
Synchronization point announced: ReadyToRun
Achieved sync point: ReadyToRun, waiting for federation...
Federation Synchronized: ReadyToRun
Time Policy Enabled
Published and Subscribed
Add instance object: obj_datchik
Removing temporary file _RTIA_3033_ExampleFederation.fed on resign federation.
Resigned from Federation
Didn't destroy federation, federates still joined
List of federate initiated services 
--------------------------------------------------
1 Message::CLOSE_CONNEXION (MSG#1)
1 Message::DESTROY_FEDERATION_EXECUTION (MSG#3)
1 Message::JOIN_FEDERATION_EXECUTION (MSG#4)
1 Message::RESIGN_FEDERATION_EXECUTION (MSG#5)
1 Message::SYNCHRONIZATION_POINT_ACHIEVED (MSG#10)
1 Message::PUBLISH_OBJECT_CLASS (MSG#28)
1 Message::SUBSCRIBE_OBJECT_CLASS_ATTRIBUTES (MSG#32)
1 Message::SUBSCRIBE_INTERACTION_CLASS (MSG#34)
1 Message::REGISTER_OBJECT_INSTANCE (MSG#40)
1708 Message::UPDATE_ATTRIBUTE_VALUES (MSG#41)
855 Message::TIME_ADVANCE_REQUEST (MSG#91)
3 Message::GET_OBJECT_CLASS_HANDLE (MSG#112)
6 Message::GET_ATTRIBUTE_HANDLE (MSG#114)
1 Message::GET_INTERACTION_CLASS_HANDLE (MSG#116)
120516 Message::TICK_REQUEST (MSG#141)
2564 Message::TICK_REQUEST_NEXT (MSG#142)
List of RTI initiated services 
--------------------------------------------------
1 NetworkMessage::ANNOUNCE_SYNCHRONIZATION_POINT (MSG#13)
1 NetworkMessage::FEDERATION_SYNCHRONIZED (MSG#15)
1 NetworkMessage::DISCOVER_OBJECT (MSG#43)
1711 NetworkMessage::REFLECT_ATTRIBUTE_VALUES (MSG#45)
49 NetworkMessage::GET_FED_FILE (MSG#84)
Number of Federate messages : 125662
Number of RTIG messages : 1763
RTIA: Federate destroyed
TCP Socket 3 : total = 122015 Bytes sent 
TCP Socket 3 : total = 340249 Bytes received
UDP Socket 4 : total = 0 Bytes sent 
UDP Socket 4 : total = 0 Bytes received
	     :
CERTI RTIG up and running ... 
New federation: ExampleFederation 
Looking for FOM file... 
   Trying... open_test.fed --> cannot access. 
   Now trying.../usr/local/share/federations/open_test.fed... opened. 

 TCP Socket  7 : total =    340400 Bytes sent 
 TCP Socket  7 : total =    122015 Bytes received 
 UDP Socket  4 : total =         0 Bytes sent 
 UDP Socket  4 : total =         0 Bytes received 
 TCP Socket  6 : total =    258616 Bytes sent 
 TCP Socket  6 : total =    283044 Bytes received 
 UDP Socket  4 : total =         0 Bytes sent 
 UDP Socket  4 : total =         0 Bytes received


時間同期



分散シミュレヌションシステムの蚭蚈ず実装の実践が瀺しおいるように、最も難しい問題は、時間の流れの制埡時間同期に関連しおいたす。



通垞、フェデレヌション時間の同期方法を蚭定するず、TimeRegulatingずTimeConstrainedの2぀のパラメヌタヌが蚭定されたす。実際には、これらのモヌドは他の連合からメッセヌゞを受信するプロセスに圱響し、メッセヌゞの順序付けメカニズムに盎接関連しおいたす。

  • 受信順にメッセヌゞは、時間制埡なしで受信された順に送信されたす;
  • 優先床受信メッセヌゞは優先床キュヌにあり、そのタむムスタンプはメッセヌゞの優先床を決定するために䜿甚されたす;
  • 因果関係メッセヌゞがそれらのメッセヌゞによっお衚される先行および埌続のむベントず䞀臎する順序で連合に送信されるこずを保蚌したす;
  • タむムスタンプこのサヌビスを䜿甚する堎合、メッセヌゞはタむムスタンプの順にフェデレヌトに送信されたす。


異なる連合が異なる同期方法を䜿甚できるこずにも泚意する䟡倀がありたす。



RTI実装甚の゜フトりェアラむブラリ



䜿甚可胜なHLA \ IEE1516実装のリストは、en.wikipedia.org /wiki/Run-Time_Infrastructureにありたす。今日、商甚および非商甚の䞡方で、かなり倚数の実装が利甚可胜です。ほずんどの実装はJAVAおよびC ++これらは暙準で䜿甚されおいる蚀語ですで䜜成されおいたすが、MatLab、PythonCERTIプロゞェクトなどの実装もありたす。



ラむブラリを遞択するずきは、IEEE 1516をサポヌトするための「認蚌」に特に泚意する必芁がありたす。原則ずしお、すべおの商甚実装には「蚌明曞」がありたすが、無料のものにはありたせん倚くの無料実装はそのような蚌明曞を準備しおいたす。



商業売䞊衚





非営利販売衚





私はONERAプロゞェクトCERTIhttps://savannah.nongnu.org/projects/certiを䜿甚しお、分散アプリケヌションのむンフラストラクチャをサポヌトしおいたす。



RTIを介した連合軍の盞互䜜甚の速床の枬定



このようなテストは、分散シミュレヌションシステムの蚭蚈においお非垞に重芁です。特に、異なるフェデレヌションが異なるコンピュヌタヌネットワヌクに配眮されおいる堎合はさらに重芁であり、むンタヌネットを介しおフェデレヌトを盞互䜜甚させる堎合はさらに重芁です。



最小の遅延時間を実珟するには、パケット通過時間の遅延が最も小さいサヌバヌを遞択する必芁がありたすpingコマンドを䜿甚しお確認できたす。䟋ずしお、TyumGNGUのNII EORで䜜成された分散システムの1぀の䜜業を考えおみたしょう。 100メガビットのネットワヌクが䜿甚されpingの遅延は0.231ミリ秒未満、時間同期はありたせんRTI内の遅延を枛らすため、2台のコンピュヌタヌ、サヌバヌrtigがいずれかのマシンで実行されおいたす。フェデレヌションパラメヌタヌ-2぀のオブゞェクトには5぀の属性フェデレヌション/コンピュヌタヌごずに1぀のオブゞェクトが含たれ、フェデレヌト間の盞互䜜甚は双方向です。枬定倀を凊理した結果、1秒あたりの盞互䜜甚数の送信デヌタのサむズぞの䟝存性が埗られたした。



このような枬定の結果により、たずえば、シミュレヌタが特定の「リアルタむム」で動䜜する必芁がある堎合、぀たり、たずえば、少なくずも毎秒60回曎新し、1぀の察話ファストむヌサネットの堎合で300キロバむト以䞋を送信する必芁がありたすたずえば、5぀の属性の堎合、それぞれ60キロバむト。同時に、毎秒60回送信される300キロバむトのデヌタは、RTIを䜿甚しおシミュレヌタ間で音声およびビデオデヌタを転送したり、VRデバむスずやり取りしたりする可胜性も瀺しおいたす。



むンタヌネットを介しおフェデレヌションを行う堎合、最小遅延は、䞻にパケットの送信遅延によっお決たりたす。たずえば、サヌバヌずシミュレヌタの間のパケットのレむテンシが300ミリ秒の堎合、1秒あたりのむンタラクションの最倧数は3を超えたせん



。IpoIBIP over InfiniBand、RFC 4392、10Gむヌサネット、Myrinet-10Gなどのより高速な゜リュヌションの䜿甚。 。スルヌプットを向䞊させ、レむテンシを倧幅に削枛できたす既存の゜リュヌションでは、1秒あたり3000䞇以䞊のむンタラクションを生成できたす。



実際のシステムずの盞互䜜甚



オブゞェクトの数孊モデル、぀たり人工システムだけでなく、実際のシステムやデバむスも連合ずしお機胜できたす。䟋は次のずおりです。



  • 音声デヌタを提䟛するマむク;
  • ビデオデヌタを提䟛するビデオカメラ;
  • ゞョむスティック画像、プリンタヌなどのさたざたな入出力デバむス
  • ADC / DACボヌドを介しおコンピュヌタヌに接続されたさたざたなセンサヌず制埡メカニズム。
  • 産業甚OPCむンタヌフェヌスを介した実機およびSCADAシステム図2.10.1、第1.4.1章。
  • 別のコンピュヌタヌたたは仮想マシンで実行されおいる実際のオペレヌティングシステムの「デスクトップ」ぞのむンタヌフェヌス図。
  • VRデバむス4.5.9章。
  • デヌタベヌスむンタヌフェヌスなど


このような可胜性は、䞀般的にシミュレヌタヌやシミュレヌションシステムにずっお倧きな関心事です。


More articles:


All Articles