الهندسة المعمارية عالية المستوى (HLA) مقابل المحاكاة التفاعلية الموزعة (DIS)

Question

هل هناك نظرة عامة على مستوى رفيع المستوى HLA عكس ديس أطراف المحاكاة؟ هل يمكن لأحد استضافة الآخر والعكس بالعكس؟

Answer 1

أنا حاليًا (على الرغم من ذلك لمدة أسبوع آخر أو نحو ذلك) في صناعة المحاكاة - أعتذر مقدمًا عن أي أخطاء ، سأقوم بتصحيحها إذا كنت أتذكر معلومات غير صحيحة.

ديس

• يحدد المعيار تخطيط البيانات على السلك ، أي أن حزم/بيانات PDUs يتم وضعها تمامًا كما هو محدد في مواصفات DIS

• يعتمد على أفضل شبكات الجهد (أي بروتوكول UDP ، البث)

• يتعين على الكيانات أن تصلب على فترات زمنية معينة (افتراضي: 5 ثوان) لإخطار الجميع بأنها لا تزال جزءًا من التمرين

• لا يوجد خادم مركزي يدير التطبيقات المختلفة المرتبطة بالتمرين

• يمكن أن تنضم طلبات المحاكاة إلى المحاكاة في أي وقت ، مغادرة في أي وقت

HLA

• يستخدم مدير مركزي ، يسمى RTI (البنية التحتية لوقت التشغيل) ، والذي يتلقى بيانات من مختلف التطبيقات ويرسلها إلى تطبيقات أخرى في المحاكاة (في سياق HLA ، وتسمى هذه الاتحادات ومجموعة من الاتحاد هي اتحاد)

• يجب على جميع الاتحادات الانضمام وترك المحاكاة من خلال المرور عبر RTI

• على عكس DIS ، لا تحدد مواصفات HLA تخطيط حزم البيانات ، ولكنها بدلاً من ذلك تحدد مجموعة من وظائف API التي تستخدمها التطبيقات. RTI هو ما ينفذ واجهة برمجة التطبيقات.

• ينشر HLA Federates البيانات وفقًا لنموذج FOM (كائن الاتحاد) الذي يحدد ما تمثله البيانات في المحاكاة. يتيح ذلك للأشخاص إنشاء FOMs جديدة تحدد أنواع الكائنات والتفاعل الجديدة ، على عكس DIS ، حيث تمر إضافة أنواع جديدة من البيانات PDUs عبر لجنة (SISO). على سبيل المثال ، تستخدم معظم عمليات المحاكاة التي تعمل تحت HLA برنامج RPR FOM ، والذي يعكس إلى حد كبير الكيانات والتفاعلات القياسية DIS.

• يضيف HLA ميزات إضافية لا تدعمها DIS ، مثل إدارة توزيع البيانات (DDM) ، حيث يقوم Federates بإخطار RTI بأنهم مهتمون فقط بأنواع معينة من البيانات.

• يدعم خدمات الاشتراك ، حيث يقوم Federates بإخطار RTI بأنهم مهتمون فقط بتلقي بيانات أو تفاعل معينة (أي التطبيق يريد فقط بيانات حول السفن)

• يدعم ميزة نقل الملكية ، حيث يتم إعطاء الكائنات الخاضعة لسيطرة FERENT لاتحاد آخر لإدارتها.

هل يمكن لـ DIS مضيف HLA والعكس بالعكس؟

بسبب هذه الاختلافات الأساسية ، يجب أن يكون من الواضح أن DIS و HLA لا يمكن أن تستضيف بعضهما البعض.

ومع ذلك ، فإن هذا ما يعنيه هذا حقًا هو أنه بالنسبة لمحاكاة DIS للتفاعل مع عمليات المحاكاة في HLA هو أنك تحتاج إلى نوع من وسيط الشبكات الذي يعمل كمحول بين البروتوكولات. أمثلة على هؤلاء الوسطاء ماك VR-Exchange أو بوابة GMU.

لمزيد من القراءة:

• http://www.mak.com/products/standards.php
• http://www.siaa.asn.au/get/2395379411.pdf
• http://dss.ll.mit.edu/dss.web/96.14.103.rti.introduction.html

Answer 2

هنا بعض التاريخ المعروف المؤجر فيما يتعلق HLA.

يعتمد تصميم HLA فعليًا على شيء يسمى بروتوكول محاكاة المستوى الإجمالي (ALSP) الذي تم تقوده في أوائل التسعينيات من قبل أهل Miter نفسها التي طورت HLA. تم تصميم ALSP لربط المحاكاة البناءة على نطاق واسع تستخدم لتدريب ما بعد قيادة الفيلق/القسم. تضمنت متطلبات قابلية التشغيل المتداخلة ALSP أعدادًا أكبر من الكائنات ، والوقت المحافظ ، وتبادل أحداث المحاكاة. لم نتمكن من تحمل تكاليف تحديثات الكيان البث بشكل دوري لأن ذلك قد يسبب مشاكل في قابلية التوسع.

في سنواتي الأخيرة من مشاركتي ، وصلنا إلى ما يصل إلى مليون كائن ساحة المعركة لكل واحد من تمرين Ulchi Focus Lens. الفرق الأساسي بين HLA و DIS هو أن HLA مصمم للتعامل مع الإخلاص البناء والمتغير ، والمحاكاة المدارة في الوقت المحافظ ، بينما ولدت DIS من بيئة محاكاة متصلة بالشبكة وتركز على أجهزة المحاكاة على مستوى المنصة القريبة من الوقت.

يمكن أن تساعد HLA في جعل هاتين الفئتين من المحاكاة متداخلة إلى حد ما ، ولكن سيكون دائمًا محدودًا بسبب الاختلافات الكامنة في أنواع المحاكاة التي يتم ربطها.

على سبيل المثال ، إذا تعثرت اتحاد المحاكاة المحافظة التي تديرها الوقت مع الحسابات ، فإن إدارة وقت HLA ستؤدي إلى توقف الاتحاد عن المضي قدمًا إلى الأمام حتى يتحرك أبطأ المحاكاة للأمام. ديس لا يدعم هذا. بالنسبة إلى منصة Discarive ، يبدو أن جميع الكيانات التي تديرها الوقت تتحرك في حركة بطيئة أو تتوقف تمامًا ويبدو أنها تتحرك بشكل أسرع من الوقت الفعلي حيث يحاول الاتحاد اللحاق بالوقت الفعلي.

Answer 3

لا يوجد شيء في مواصفات HLA التي تقول إن RTI يجب أن يكون مركزيًا ، على الرغم من أن جميع RTIs تقريبًا.

Answer 4

يحدد معيار HLA 1516 API فقط بين المحاكاة و RTI. ليس بين RTIs. البروتوكول المستخدم لتبادل البيانات بين RTIs هو الملكية. لذلك فإن RTIs فقط من نفس البائع أو وكالة حكومية قادرة على التفاعل. عيب كبير. إذا كنت تستخدم RTI مختلفًا ، فستحتاج إلى "جسر" للترجمة بين بروتوكولات الملكية. هذا يمكن أن يكون مكلفا.

Answer 5

شيء واحد يجب وضعه في الاعتبار إذا كنت تخطط لسد DIS و HLA هو أنك ستخسر إخلاص المحاكاة على كلا الجانبين اعتمادًا على كيفية تنظيم FOM الخاص بك. dis to rpr foM واضح ومباشر ولكن هناك foms أخرى قد لا تخطط بشكل جيد على الإطلاق إلى dis. في بعض المواقف ، قد تكون غير قادر على ترجمة حقل PDU إلى سمة كائن HLA أو معلمة التفاعل (أو العكس). سيتعين عليك استخدام أفضل حكمك فيما يتعلق بأنواع القيم الافتراضية التي يجب استخدامها في هذه الحالات. في أوقات أخرى ، قد يتم تنظيم التسلسل الهرمي لكائن HLA FOM بشكل مختلف تمامًا عن dis. في هذه الحالة ، قد تتطلب الترجمة الجمع بين البيانات من PDUs متعددة لتشكيل رسالة HLA واحدة. هذا يعني أنه سيتعين عليك كتابة التعليمات البرمجية في الجسر للحفاظ على شكل من أشكال حالة الرسالة.

أيضًا ، في وقت التشغيل ، ستحصل على سمات HLA الخاصة بك. بعد اكتشاف الكائن ، سيتعين عليك الانتظار لترجمة مثيل كائن حتى تتلقى سمات كافية لإلغاء PDU بشكل صحيح.

مسألة أخرى هي أن HLA يمكن أن توفر خدمات إدارة الوقت. سيكون لديك الكثير من مشاكل التزامن للتعامل معها إذا حاولت دمج تطبيق DIS في اتحاد HLA باستخدام إدارة الوقت.

إذا كان لديك ميزانية شراء ، فستكون نصيحتي هي الذهاب مع Mak VR-Exchange.