المحاكاة الافتراضية للتشغيل: آلية العمل ومتى تحقق عائدها

Disclosure: M365.FM host Mirko Peters works at iFAKT GmbH. This page describes the company factually; paid partnerships and links are labelled as advertising.

By Mirko Peters · 2026-11-11

تختبر المحاكاة الافتراضية للتشغيل برنامج التحكم على نموذج افتراضي قبل بدء التشغيل. تعرّف على آلية عملها، وما تقوله الأدلة، ومتى تحقق عائدها لأحد المصانع.

Automatically translated with AI from the original post. Read the English original

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

النقاط الرئيسية

• تربط المحاكاة الافتراضية للتشغيل برنامج التحكم الفعلي، مثل برنامج PLC، بنموذج محاكٍ للآلة، فتُختبر المنطق والإشارات والتسلسلات قبل تشغيل المعدات.
• يحتاج النموذج إلى الهندسة والحركة معًا، إضافةً إلى الواجهة الكهربائية مع المتحكم، وتعتمد قيمته على مدى تطابقه مع السلوك الحقيقي.
• توفير الوقت المُبلَّغ عنه كبير، لكنه مستمد من تجارب صغيرة ومن صفحات الموردين، لذا خطّط برقم متحفظ ولا تعامله على أنه مضمون.
• تحقق المحاكاة الافتراضية عائدها عندما يكون يوم التأخير في بدء التشغيل مكلفًا، أو عندما يكون منطق التحكم معقدًا، أو عندما يمكن إعادة استخدام النموذج في التدريب والتعديلات اللاحقة.
• تجيب عن سؤال يختلف عن سؤال محاكاة الإنتاج: هل يعمل التحكم بصورة صحيحة، لا كم يمكن للنظام أن ينتج.

المحاكاة الافتراضية للتشغيل: ماهيتها وآلية عملها

في التشغيل التقليدي، يلتقي برنامج التحكم بالآلة لأول مرة في الموقع. وعندها تكلّف الأخطاء في المنطق والإشارات والتسلسلات وقتًا ثمينًا على أرض المصنع، حيث تكون كل ساعة تأخير مكلفة. أما المحاكاة الافتراضية للتشغيل فتنقل هذا اللقاء الأول إلى المكتب، إلى بيئة افتراضية يستطيع فيها النموذج محاكاة المستشعرات والمحركات والأجزاء. وهذا يعني بالنسبة إلى مشروع الأتمتة معالجة الأعطال في مرحلة مبكرة، حين يكون الإصلاح زهيد التكلفة. وقد وصف Matthias Schamp وزملاؤه من جامعة غنت ومنظمة Flanders Make، في ورقة بحثية نُشرت في Procedia Manufacturing عام 2019، هذه المحاكاة بأنها إعادة إنتاج سلوك الأجهزة في بيئة برمجية، من أجل التحقق من منطق التحكم قبل التنفيذ الفعلي. وتحتاج المكونات الافتراضية إلى نموذج ميكانيكي يتضمن الهندسة والحركة، وإلى نموذج كهربائي يغطي التفاعل مع PLC.

عمليًا، تسير الخطوات على النحو الآتي:

1. بناء النموذج للآلة أو للمصنع: الأجزاء المتحركة، والمستشعرات، والمشغّلات.
2. تسمية الإشارات في النموذج بالأسماء نفسها الموجودة في برنامج التحكم، بحيث يرى المتحكم النموذج كما يرى المعدات الحقيقية.
3. ربط برنامج التحكم بالنموذج. يعمل برنامج PLC الفعلي، ويتفاعل النموذج معه.
4. اختبار التسلسلات والأعطال. شغّل الدورات الاعتيادية، ثم فعّل أعطالًا مثل غياب جزء، أو تعطل مستشعر، أو انحشار، وهي أعطال يكون اختبارها على المعدات الحقيقية محفوفًا بالمخاطر أو بطيئًا.
5. إصلاح الأخطاء على المكتب، ونقل البرنامج المُصحَّح إلى الموقع.

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

ثلاثة مستويات للاختبار: النموذج والبرمجيات والعتاد في الحلقة

يمكن إجراء الاختبار على مستويات مختلفة، بحسب مرحلة المشروع. تصف صفحة المورّد realvirtual، وهي برمجية للتشغيل الافتراضي، ثلاث حلقات:

• النموذج في الحلقة يربط نماذج السلوك، مثلاً من أداة محاكاة، بنموذج الآلة. وهو مناسب للمحركات والعمليات قبل وجود أي شيفرة PLC.
• البرمجيات في الحلقة تُشغّل وحدة التحكم كبرمجية على حاسوب شخصي، فلا يحتاج الاختبار كله إلى توصيلات أو عتاد. وهو مناسب للاختبارات المبكرة، ويتوسع بسهولة.
• العتاد في الحلقة يربط PLC حقيقياً بالنموذج عبر الشبكة. وهو أقرب إلى النظام النهائي، ويتحقق من سلوك العتاد الفعلي وتوقيته.

تصف مدونة Siemens، وهي مورّد أيضاً، الوضعين نفسيهما للبرمجيات والعتاد في الحلقة في أداة محاكاة المصانع لديها. والفرق بين simulation وemulation مهم هنا ويستحق معالجة منفصلة. أما بالنسبة لمدير المصنع، فالنقطة العملية هي: ابدأ بالبرمجيات، وأضف العتاد الحقيقي عندما يصل المشروع إلى المرحلة التي يصبح فيها التوقيت والواجهات مهمين.

ما تقوله الأدلة عن توفير الوقت

الوفورات المُعلَنة كبيرة، لكن جودة الأدلة متفاوتة، لذا ينبغي قراءة الأرقام بحذر.

• تستشهد ورقة Schamp بتجربة سابقة صغيرة النطاق أبلغت عن انخفاض بنسبة 73% في وقت التشغيل الفعلي، وتحسّن بنسبة 31% في المتطلبات المُنجزة قبل التشغيل الفعلي باستخدام نهج النموذج الرقمي. ويشير المؤلفون إلى أن مقارنة الأساليب صعبة، لأن التشغيل لا يمكن أن يحدث إلا مرة واحدة.
• تذكر صفحة realvirtual أن وقت التشغيل في الموقع يمكن أن يكون أقصر بنسبة تصل إلى 75%، وأن نسبة وظائف التحكم التي عملت من المحاولة الأولى ارتفعت من 37% إلى 84%، مستشهدةً بدراسة ميدانية من Technical University of Munich. كما تذكر أن نسبة 75% ليست نتيجة مضمونة لكل مشروع. وهذا مصدر من المورّد يستشهد بطرف ثالث.
• تدّعي مدونة Siemens أيضاً وفورات كبيرة، لكنها تقدم أرقاماً قليلة يمكن التحقق منها.

إذن الاتجاه متسق، أما الحجم فغير مؤكد. للتخطيط، استخدم افتراضاً متحفظاً، مثل ربع وقت الموقع، وتحقق منه مقابل مشروعك الأول.

مصطلح ذو صلة هو التوأم الرقمي (digital twin): تمثيل رقمي مُحدَّث لمورد مادي، يُحافَظ على تحديثه من خلال الملاحظات الواردة. وفي مشاريع Industry 4.0 يُناقَش التوأم ونموذج التشغيل الافتراضي غالباً معاً، لكنهما ليسا الشيء نفسه. فالنموذج المبني للتشغيل الافتراضي غالباً ما يكون نموذج اختبار لمرة واحدة، مثلاً لخط تجميع واحد. وإذا حافظت عليه محدَّثاً، يمكن أن يتطور إلى توأم، ثم يُستخدم في التدريب وفي اختبار التغييرات اللاحقة. وإعادة الاستخدام هذه من أهم الطرق التي يعود بها الاستثمار بالعائد.

مثال: متى يصبح الأمر مجدياً؟

هذا حساب توضيحي وليس حالة مقاسة. يحتاج خط جديد إلى 30 يوماً من التشغيل في الموقع. بناء النموذج الافتراضي يكلّف 25 يوم هندسة بسعر 800 لليوم، أي 20,000، إضافةً إلى 15,000 للبرمجيات والتراخيص، فيكون المجموع 35,000. وكل يوم تأخير عند التشغيل يكلّف 8,000، وذلك من طاقم الموقع والهامش المفقود.

لنفترض أن الفريق يخطط بتحفظ ويتوقع توفير 25% من وقت الموقع، أي 7.5 يوم.

• التوفير: 7.5 × 8,000 = 60,000.
• التكلفة: 35,000.
• صافي المكسب: نحو 25,000.

نقطة التعادل هي 35,000 ÷ 8,000 = 4.4 يوم، وهي نحو 15% من الـ 30 يوماً. إذا كان الوقت الموفَّر أقل من ذلك، فإن النموذج لن يغطي تكلفته على هذا الخط وحده.

الآن نغيّر افتراضاً واحداً. إذا كلّف يوم التأخير 3,000 فقط، فإن الأيام السبعة والنصف نفسها تساوي 22,500، وهو أقل من 35,000. لا يحقق المشروع عائداً من الخط الأول، إلا إذا أُعيد استخدام النموذج. وإذا خدم النموذج نفسه أيضاً تدريب المشغّلين، وتغييرين لاحقين كان كل منهما سيستغرق يومين من الاختبار بتكلفة 3,000، فإن إعادة الاستخدام تضيف 12,000. يصبح إجمالي المنفعة حينها نحو 34,500، أي قريباً من نقطة التعادل.

الفكرة هي أن القرار يعتمد على ثلاثة أرقام: تكلفة يوم التأخير، ونسبة الأيام التي تتوقع توفيرها، وإعادة استخدام النموذج. قارنها قبل بدء المشروع.

اختبارات التحكم واختبارات المخرجات: نوعان من المحاكاة

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

تسأل محاكاة نظام الإنتاج عما إذا كان المصنع سيحقق المخرجات المطلوبة. فـiFAKT's Polaris Simulator، على سبيل المثال، وحدة ضمن iFAKT Polaris تختبر نظام الإنتاج افتراضياً، كسيناريوهات السعة والتوظيف والمخازن المؤقتة، وتكشف الاختناقات قبل إجراء أي تغييرات. هذا سؤال عن التدفق والسعة، وليس اختباراً لشيفرة PLC، ولا يحل أحدهما محل الآخر. قد يملك الخط برنامج تحكم مختبراً جيداً ويظل تصميمه ضعيفاً، والعكس صحيح أيضاً. يجيب الاختباران عن سؤالين مختلفين، لذلك ينبغي أن يُجريا في مرحلتين مختلفتين من المشروع.

كيفية بدء مشروع الأتمتة في خمس خطوات

هذا التسلسل أداة تخطيط من إعدادنا، وليس معياراً قياسياً.

1. اختر مشروعاً ذا تكلفة تأخير عالية أو منطق تحكم معقّد وجديد. فالآلة البسيطة التي بنيتها مراراً مرشح ضعيف لتكون الحالة الأولى.
2. حدّد الأسئلة. ما التسلسلات والأقفال المتبادلة وحالات الأعطال التي يجب اختبارها؟ فالنطاق يحدد جهد بناء النموذج.
3. اتفق على مستوى التفصيل. ينبغي أن يكون النموذج بسيطاً بقدر ما تسمح به الأسئلة. النموذج شديد التفصيل يستهلك وقتاً، والنموذج شديد العمومية يفوّت الأخطاء.
4. حدّد مستوى الاختبار. ابدأ بالبرمجيات في الحلقة (Software in the Loop). وأضف العتاد عندما يكون التوقيت أو الواجهات مهمة.
5. اختبر ووثّق واحتفظ بالنموذج. سجّل الأخطاء المكتشفة، ونقل البرنامج المصحَّح إلى الموقع، وعيّن مالكاً للنموذج بعد ذلك.

الأخطاء الشائعة

• البدء متأخراً. إذا كانت شيفرة التحكم قد اكتملت وسُلّمت، فلن يبقى الكثير لاختباره.
• مستوى تفصيل خاطئ. النموذج العام أكثر من اللازم يفوّت الأخطاء، والنموذج المفصّل أكثر من اللازم يؤخر المشروع.
• إشارات غير متطابقة. إذا اختلفت أسماء الإشارات في النموذج عن الإشارات الفعلية، فأنت تختبر برنامجاً مختلفاً.
• اعتبار الاختبار الناجح دليلاً قاطعاً. النموذج ليس الآلة نفسها. خصّص وقتاً للفحص في الموقع.
• الاعتماد على النسبة المئوية الواردة في العناوين. حتى المورّد نفسه يقرّ بأن رقمه غير مضمون في كل مشروع.
• عدم وجود مالك بعد انتهاء المشروع. النموذج الذي لا يصونه أحد يصبح قديماً بعد أول تغيير.

كيف يمكن للبرمجيات أن تساعد

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

الخطوة التالية

اكتب قائمة بأهم ثلاثة مشاريع استثمارية قادمة لديك، وقدّر تكلفة يوم التأخير في بدء التشغيل لكل منها، وقارنها بتكلفة النموذج. ثم اختر المشروع الذي تملك فيه التشغيل الافتراضي أعلى فرصة لتحقيق العائد، ليكون هو التجربة الرائدة.