نظام بسيط للذهاب المحاكاة

مقدمة

المحاكاة هي طريقة لإجراء التجارب ، يتم استبدال النظام الحقيقي المدروس بنموذج. في مثل هذا النموذج ، يمكنك أن تفقد المواقف الفردية والكثير منها. يمكن أن تساعد الإحصاءات التي تم جمعها في استخلاص استنتاجات حول العمليات في النظام ، وكذلك مسارات تحسين المخطط التفصيلي.

غالبًا ما يتم اعتبار نمذجة المحاكاة كنوع من الاختبارات التجريبية ، ولكنها في الوقت نفسه أقل تكلفة ، فهي تتيح لك تغيير المعلمات بسرعة ومراقبة النظام المحاكى في الديناميات.

بالفعل حوالي نصف قرن في نمذجة المحاكاة ، تم استخدام نماذج الكمبيوتر. تم إنشاء الكثير من البرامج والأطر المختلفة لتطويرها ، من بينها ، في رأيي ، أكثرها تطوراً هي أدوات وضع نماذج لقوائم الانتظار (QS). أحد أكثر البرامج المعروفة والبسيطة لمحاكاة نظام QS - GPSS World (نظام محاكاة الأغراض العامة - نظام نمذجة للأغراض العامة) ، يمكن العثور على مزيد من التفاصيل في [1] ، [2] .

كان مفهوم هذا البرنامج هو أساس إطار المحاكاة على الذهاب.

محاكاة في GPSS

نموذج في GPSS هو سلسلة من الكتل (الأوامر) التي تصف الكائنات المحاكية التي تتحرك فيها المعاملات. عندما تدخل معاملة ما إلى الكتلة ، يتم إنشاء أحداث تؤدي إما إلى تغيير في حالة الكائن المسمى أو إلى تغيير في حالة / معلمات المعاملة.

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

تحتوي الكائنات في GPSS على مجموعة من السمات العددية القياسية (NAV) والسمات المنطقية القياسية (ALS). على سبيل المثال ، بالنسبة لقائمة الانتظار ، يكون أحد NAV هو الطول الحالي ، وسيكون مثال ALS لبعض المعدات مجانيًا (TRUE) أو مشغولًا (FALSE).
في بعض إصدارات GPSS ، يوجد تصور لعملية النمذجة ، لكنه غالبًا ما يكون غائبًا. بناءً على نتائج المحاكاة ، يتم إنشاء تقرير في GPSS ، يشير إلى NAV و ALS لجميع الكائنات.

الذهاب التنفيذ

التنفيذ في Go هو تطوير مجموعة من الكائنات المشابهة لوظيفة كتل GPSS. تم إنشاء أول خط أنابيب - الكائن الذي يتم تنفيذ المحاكاة فيه.

بناءً على map تحتوي على قائمة بالمكونات لوصف النظام المحاكاة. نظرًا لأن المعاملات يجب أن تمر خلال المحاكاة بسلسلة من الكتل بترتيب صارم ، وفي طريقة إضافة مكونات Append ، تم تنفيذ إجراء الإضافة مع الإشارة المتزامنة لوجهات المعاملات منها. يتم استخدام اسم المكون كمفتاح map ، لذلك يجب أن يكون لكل مكون اسم فريد.

بعد إضافة جميع المكونات ، يمكنك بدء المحاكاة باستخدام طريقة Start . بداخله ، يتم تنفيذ تجاوز دوري لجميع المكونات لفترة محاكاة معينة. في نهاية المحاكاة ، يمكنك طباعة تقرير يحتوي على NAV و ALS.

العنصر المهم الثاني هو المكونات الفعلية لوصف المحاكاة. تم تنفيذ ما يلي: المولد - يولد المعاملات ، Advance - يخلق تأخيرات في مسار المعاملة ، قائمة الانتظار - قوائم انتظار المعاملات ، التسهيلات - جهاز يتم التقاطه حصريًا بواسطة المعاملة لفترة ، ثقب - "ثقب" تفشل فيه المعاملات في نهاية المسار. بالطبع ، هذه المجموعة لا تكفي لإنشاء نماذج محاكاة معقدة ، ولكنها كافية لحل الحل ومقارنة بنتائج GPSS. جميع المكونات تنفذ واجهة IBaseObj ، والتي تغطي الحد الأدنى من الوظائف المطلوبة.

يحتوي كل مكون على قائمة انتظار معاملة. مباشرة باعتبارها قائمة انتظار ، يتم استخدامها فقط في قائمة الانتظار ، للمكونات الأخرى هو مجرد مستودع. يتم تنفيذ قائمة الانتظار على أساس map . في عملية النمذجة ، تمر المكونات بدورها وتحقق من جاهزية المعاملة (تحقيق شرط معين) لنقلها إلى المكون التالي. يتم تنفيذ النقل من خلال طريقة AppendTransact للمكون التالي. في حالة نجاح النقل ، تتم إزالة المعاملة من قائمة الانتظار ، على التوالي ، يأخذها المكون التالي بدوره. نظرًا لتعريف عدة مستلمين لكل مكون ، فإذا لم يكن من الممكن إرسال معاملة إلى مستلم واحد ، فإننا نحاول إرساله إلى آخر.

لإنشاء متغيرات عشوائية عند تحديد وقت ظهور المعاملة وإنشاء تأخير ، يتم استخدام وظائف PRNG في Go.

حيث أنه عند القيام بالنمذجة ، في الوقت نفسه ، يمكن أن يكون هناك العديد من المعاملات التي تتحرك بين المكونات المختلفة ، نشأت الفكرة لاستخدام goroutines داخل المكونات. يقوم خط الأنابيب ، الذي يمر عبر المكونات ، ببدء HandleTransacts معالج HandleTransacts لكل منهما ، حيث يتم إنشاء goroutine. بعد الانتهاء من جميع goroutines ، يتم زيادة عداد وقت النموذج ويتم استدعاء HandleTransacts .

الكائن الرئيسي الأخير هو المعاملة نفسها. لديه معرف ، وقت الولادة والموت ، والمالك (في العنصر الذي هو عليه الآن) ، وعدد من المعلمات لحساب SCA و SCHL.

في التين. 1 هو مخطط هيكلي لتفاعل الكائنات الرئيسية للإطار أثناء النمذجة.


التين. 1. المخطط الهيكلي المعمم للتفاعل بين الأشياء الرئيسية في المحاكاة

مثال المحاكاة

لنفترض أنك تحتاج إلى محاكاة عمل مصفف شعر. هذا مثال شهير من GPSS. يذهب الزائرون بشكل عشوائي ، بتردد 18 ± 6 دقائق ، وعددهم غير معروف مقدمًا. لدينا مصفف شعر واحد ، فهو يقضي 16 ± 4 دقائق على قصة شعر. لذلك ، كم من الناس سوف يقطع ليوم عمل؟ كم من الناس سوف تكون في الخط؟ ما هو متوسط ​​الوقت الذي يستغرقه قص الشعر وكم من الوقت ينتظره الناس في الطابور؟ الكثير من الأسئلة ومحاكاة بسيطة. الرسم البياني كتلة في الشكل. 2.


التين. 2. المخطط الهيكلي لنمذجة مصفف شعر

سيكون رمز بناء النموذج كما يلي.

 barbershop := NewPipeline("Barbershop", true) //   clients := NewGenerator("Clients", 18, 6, 0, 0, nil) //   chairs := NewQueue("Chairs") //  master := NewFacility("Master", 16, 4) //  hole := NewHole("Out") //  barbershop.Append(clients, chairs) //       barbershop.Append(chairs, master) //      barbershop.Append(master, hole) //     barbershop.Append(hole) //        barbershop.Start(480) //    <-barbershop.Done //   barbershop.PrintReport() 

خدم 25 عميلاً ، وكان 26 في وقت الانتهاء من المحاكاة لا يزال في كرسي السيد. لم تكن قائمة الانتظار أكثر من شخص واحد ، 11 شخصًا لم ينتظروا (صفر تمريرة) وذهبوا على الفور للحلاقة. في المتوسط ​​، قضى الناس 2.58 دقيقة في قائمة الانتظار ، وأولئك الذين كانوا ينتظرون (وليس تمريرة صفرية) ، 4.47 دقيقة. 89.17 ٪ من وقته ، تصفيف الشعر ، القص بشكل مكثف.

بالطبع ، إذا أجريت محاكاة أخرى ، فستتغير النتائج. ولكن خلال سلسلة من عمليات المحاكاة ، سيكون المستوى الكلي لتحميل المعالج وعدد العملاء الذين يتم تقديمهم مرئيًا. محاكاة مماثلة في GPSS تعطي نتائج مماثلة.

مثال آخر يوجد مكتب به 10 موظفين ومرحاض واحد. يرغب الأشخاص في الذهاب إلى المرحاض كل 90 ± 60 دقيقة ، والذهاب إلى المرحاض لمدة 5 ± 3 دقائق ، والاستحمام لمدة 15 ± 10 دقائق ، والعودة إلى المكتب لمدة 5 ± 3 دقائق. سنجري المحاكاة لمدة 9 ساعات (8 ساعات عمل + ساعة غداء واحدة) ، في شكل. 3 هو المخطط الهيكلي.


التين. 3. المخطط الهيكلي لنموذج العمالة المرحاض: على اليسار مع مرحاض واحد ، على اليمين مع اثنين

على اليسار نموذج مع مرحاض واحد ، على اليمين مع اثنين. ما يلي هو رمز النموذج.

 waterclosetsim := NewPipeline("Water Closet Simulation", false) office := NewGenerator("Office", 0, 0, 0, 10, nil) wantToToilet:= NewAdvance("Wanted to use the toilet", 90, 60) pathToWC := NewAdvance("Path to WC", 5, 3) queue := NewQueue("Queue to the WC") pathFromWC := NewAdvance("Path from WC", 5, 3) wc := NewFacility("WC", 15, 10) pathToOffice:= NewAdvance("Path from WC", 5, 3) waterclosetsim.Append(office, wantToToilet) waterclosetsim.Append(wantToToilet, pathToWC) waterclosetsim.Append(pathToWC, queue) waterclosetsim.Append(queue, wc) waterclosetsim.Append(wc, pathFromWC) waterclosetsim.Append(pathFromWC, wantToToilet) waterclosetsim.Start(540) <-waterclosetsim.Done waterclosetsim.PrintReport() 

كان هناك ما يصل إلى 4 أشخاص في الطابور ، 8 مرات دخل الشخص على الفور إلى المرحاض ، خلال يوم العمل ، تم استخدام المرحاض بنسبة 87.04٪. الأكثر أهمية ، في رأيي ، هو أن الناس ينتظرون حوالي نصف ساعة (31 دقيقة) في الطابور للحمام. ربما يكون هذا بسبب حقيقة وجود مرحاض واحد فقط ، وربما يرجع ذلك إلى حقيقة أن الناس يجلسون فيه لمدة 14.69 دقيقة في المتوسط.

بعد إضافة مرحاض آخر ، رأيت أن قائمة الانتظار تم تخفيضها إلى 3 أشخاص ، 29 مرة دخل فيها الحمام على الفور. ولكن الأهم من ذلك ، انخفض التوقع ما يقرب من ثلاث مرات.

استنتاج

الإطار الذي تم إنشاؤه على الركبة بسيط للغاية ولا يزال محدودا. تخطط لزيادة وظائفها إلى مستوى GPSS. القيمة العملية للإطار هي القدرة على تجميع نموذج محاكاة بسرعة وسهولة والحصول على النتائج.

تم نشر الكود على جيثب .