Virtual Commissioning: איך זה עובד ומתי זה משתלם

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

Virtual commissioning בודק תוכנת בקרה על מודל וירטואלי לפני ההפעלה. ראו איך זה עובד, מה הראיות אומרות ומתי זה משתלם למפעל.

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

Virtual commissioning פירושו בדיקה של תוכנת הבקרה האמיתית של מכונה או מפעל מול מודל וירטואלי, לפני שהציוד נבנה או פועל. זה משתלם כאשר יום עיכוב בהפעלה עולה הרבה כסף או כאשר לוגיקת הבקרה מורכבת, ואינו משתלם בכל פרויקט. מדריך זה מיועד למנהלי מפעלים שצריכים להחליט אם לבקש אותו. תלמדו איך זה עובד, את שלוש רמות הבדיקה, מה הראיות אומרות על חיסכון בזמן, דוגמה לנקודת איזון עם מספרים, והטעויות שכדאי להימנע מהן.

עיקרי הדברים

• Virtual commissioning מחבר את תוכנת הבקרה האמיתית, כמו תוכנית PLC, למודל מדומה של המכונה, כך שהלוגיקה, האותות וסדרי הפעולות נבדקים לפני שהציוד פועל.
• המודל צריך לכלול גם גיאומטריה וקינמטיקה וגם את הממשק החשמלי אל הבקר, והערך שלו תלוי במידת ההתאמה להתנהגות האמיתית.
• החיסכון בזמן המדווח גדול, אך הוא מגיע מניסויים קטנים ומדפי ספקים, ולכן כדאי לתכנן לפי נתון שמרני ולא להניח שהוא מובטח.
• זה משתלם כאשר יום עיכוב בהפעלה עולה הרבה כסף, כאשר לוגיקת הבקרה מורכבת, או כאשר אפשר לעשות שימוש חוזר במודל להדרכה ולשינויים עתידיים.
• הוא עונה על שאלה אחרת מסימולציית ייצור: האם הבקרה עובדת, ולא כמה המערכת יכולה לספק.

Virtual commissioning: מהו ואיך הוא עובד

בהפעלה מסורתית, תוכנת הבקרה נפגשת עם המכונה לראשונה באתר. שגיאות בלוגיקה, באותות ובסדרי הפעולות עולות אז זמן רב על רצפת המפעל, שבה כל שעת עיכוב יקרה. Virtual commissioning מעביר את המפגש הראשון הזה לשולחן העבודה, לסביבה וירטואלית שבה המודל יכול לדמות חיישנים, מנועים וחלקים. בפרויקט אוטומציה, המשמעות היא איתור תקלות בשלב מוקדם, כאשר התיקון זול. במאמר של Matthias Schamp ועמיתיו מאוניברסיטת גנט ו-Flanders Make, שפורסם ב-Procedia Manufacturing בשנת 2019, מתואר התהליך כשכפול התנהגות של חומרה בסביבת תוכנה, כדי לאמת את לוגיקת הבקרה לפני ההטמעה בפועל. הרכיבים הווירטואליים זקוקים למודל מכני, הכולל גיאומטריה וקינמטיקה, ולמודל חשמלי שמכסה את האינטראקציה עם ה-PLC.

בפועל, השלבים נראים כך:

1. בנו את המודל של המכונה או המפעל: החלקים הנעים, החיישנים וההינעים.
2. תנו שמות לאותות במודל זהים לאלה שבתוכנית הבקרה, כך שהבקר יראה את המודל כפי שהיה רואה את הציוד האמיתי.
3. חברו את תוכנת הבקרה למודל. תוכנית ה-PLC האמיתית פועלת, והמודל מגיב.
4. בדקו רצפים ותקלות. הריצו מחזורים רגילים, ולאחר מכן הפעילו תקלות כמו חלק חסר, כשל בחיישן או תקיעה, שבדיקתן על ציוד אמיתי מסוכנת או איטית.
5. תקנו את השגיאות על שולחן העבודה, והעבירו את התוכנית המתוקנת לאתר.

איכות התוצאה תלויה במידת ההתאמה בין המודל להתנהגות בפועל. מאמר Schamp קובע שמודל דיגיטלי צריך להתנהג כמו מערכת הייצור האמיתית, ומונה כאתגרים פתוחים את מאמץ המידול ואת התלות בידע מומחה.

שלוש רמות בדיקה: מודל, תוכנה וחומרה בלולאה

אפשר לבצע את הבדיקה ברמות שונות, בהתאם לשלב הפרויקט. דף היצרן של realvirtual, שמוכרת תוכנה להפעלה וירטואלית, מתאר שלוש לולאות:

• Model-in-the-loop מחבר מודלים התנהגותיים, למשל מכלי סימולציה, למודל המכונה. הוא מתאים לכוננים ולתהליכים לפני שקיים קוד PLC כלשהו.
• Software-in-the-loop מריץ את הבקר כתוכנה על מחשב אישי, ולכן הבדיקה כולה אינה דורשת כבלים או חומרה. הוא מתאים לבדיקות מוקדמות וניתן להרחבה בקלות.
• Hardware-in-the-loop מחבר PLC אמיתי למודל דרך רשת. הוא קרוב יותר למערכת הסופית, ובודק את ההתנהגות והתזמון של החומרה האמיתית.

פוסט בבלוג של Siemens, ספק נוסף, מתאר את אותם שני מצבים של software-in-the-loop ו-hardware-in-the-loop עבור כלי הסימולציה של קווי הייצור שלה. ההבדל בין סימולציה לאמולציה, שחשוב כאן, ראוי לטיפול נפרד. מנקודת מבטו של מנהל מפעל, הנקודה המעשית היא זו: להתחיל עם תוכנה, ולהוסיף חומרה אמיתית כשהפרויקט מגיע לשלב שבו התזמון והממשקים הופכים לחשובים.

מה אומרות הראיות על חיסכון בזמן

החיסכון המדווח גדול, אבל איכות הראיות משתנה, ולכן יש לקרוא את המספרים בזהירות.

• מאמר Schamp מצטט ניסוי קודם בקנה מידה קטן, שדיווח על הפחתה של 73 אחוז בזמן ההפעלה האמיתי, ועל שיפור של 31 אחוז בדרישות שהתקיימו לפני ההפעלה האמיתית, בגישה של מודל דיגיטלי. המחברים מציינים שהשוואה בין גישות קשה, מכיוון שהפעלה כזו יכולה להתרחש רק פעם אחת.
• דף realvirtual טוען שזמן ההפעלה באתר יכול להיות קצר בעד 75 אחוז, ושחלקן של פונקציות הבקרה שעבדו בניסיון הראשון עלה מ-37 ל-84 אחוז. הדף מסתמך על מחקר שטח של האוניברסיטה הטכנית של מינכן. הוא גם מציין ש-75 האחוז אינו תוצאה מובטחת בכל פרויקט. מדובר במקור של ספק שמצטט צד שלישי.
• פוסט הבלוג של Siemens גם הוא טוען לחיסכון גדול, אך הוא מציג מעט מספרים שניתן לבדוק.

לכן הכיוון עקבי, והגודל אינו ודאי. לצורך תכנון, יש להשתמש בהנחה שמרנית, למשל רבע מזמן ההפעלה באתר, ולבדוק אותה מול הפרויקט הראשון שלכם.

מונח קשור הוא תאום דיגיטלי: ייצוג דיגיטלי מתוחזק של משאב פיזי, שמתעדכן על בסיס תצפיות. בפרויקטים של 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, אז 7.5 הימים שווים 22,500, שזה פחות מ-35,000. הפרויקט לא מחזיר את עצמו כבר בשורה הראשונה, אלא אם המודל ממוחזר. אם אותו מודל משמש גם לאימון מפעילים ולשני שינויים מאוחרים יותר שכל אחד מהם היה עולה יומיים של בדיקות בעלות 3,000, השימוש החוזר מוסיף 12,000. התועלת הכוללת היא אז בערך 34,500, כלומר קרובה לנקודת האיזון.

הנקודה היא שההחלטה תלויה בשלושה מספרים: העלות של יום עיכוב, החלק מהימים שאתם מצפים לחסוך, והשימוש החוזר במודל. השוו ביניהם לפני תחילת הפרויקט.

בדיקות בקרה ובדיקות תפוקה: שני סוגים של סימולציה

לעיתים מבלבלים בין commissioning וירטואלי לבין סימולציה של ייצור, משום ששניהם משתמשים במודל. הם עונים על שאלות שונות. ההבחנה המקובלת היא זו: סימולציה בוחנת איך מערכת מתנהגת ומה היא יכולה לספק, ואילו כאן המוקד הוא בדיקה שהבקרה פועלת נכון.

סימולציה של מערכת ייצור שואלת אם קו הייצור ייתן את התפוקה. iFAKT's Polaris Simulator, לדוגמה, הוא מודול של iFAKT Polaris שבודק את מערכת הייצור באופן וירטואלי, למשל תרחישים של קיבולת, כוח אדם ומאגרי ביניים, וחושף צווארי בקבוק לפני שמבצעים שינויים. מדובר בשאלה על זרימה וקיבולת. זו אינה בדיקה של קוד PLC, והשניים אינם מחליפים זה את זה. קו יכול לכלול תוכנית בקרה שנבדקה היטב ועדיין להיות תכנון גרוע, או להפך. שתי הבדיקות עונות על שאלות שונות, ולכן הן שייכות לנקודות שונות בפרויקט.

כיצד להתחיל פרויקט אוטומציה בחמישה שלבים

רצף זה הוא כלי תכנון שפיתחנו בעצמנו, ואינו תקן.

1. בחרו פרויקט עם עלות גבוהה של עיכוב או עם לוגיקת בקרה מורכבת וחדשה. מכונה פשוטה שבניתם כבר פעמים רבות אינה מקרה ראשון טוב.
2. הגדירו את השאלות. אילו רצפים, נעילות ותרחישי תקלה חייבים להיבדק? ההיקף קובע את מאמץ המודל.
3. סכמו על רמת הפירוט. המודל צריך להיות פשוט ככל שהשאלות מאפשרות. מודל מפורט מדי גוזל זמן. מודל גס מדי מפספס שגיאות.
4. בחרו את רמת הבדיקה. התחילו עם software in the loop. הוסיפו חומרה כאשר תזמון או ממשקים הם קריטיים.
5. בדקו, תעדו ושמרו על המודל. רשמו את השגיאות שנמצאו, העבירו את התוכנית המתוקנת לאתר, והגדירו לאחר מכן בעלים למודל.

טעויות נפוצות

• התחלה מאוחרת מדי. אם קוד הבקרה הסתיים ונשלח, נותר מעט מאוד מה לבדוק.
• רמת פירוט שגויה. מודל גס מדי מפספס שגיאות, ומודל מפורט מדי מעכב את הפרויקט.
• סיגנלים שאינם תואמים. אם שמות המשתנים במודל שונים מהשמות האמיתיים, אתם בודקים תוכנית אחרת.
• להתייחס לבדיקה שעברה כהוכחה. המודל אינו המכונה. תכננו זמן לבדיקה באתר.
• להסתמך על האחוז הבולט בכותרת. גם היצרן מודה שהנתון שלו אינו מובטח בכל פרויקט.
• אין בעלים אחרי הפרויקט. מודל שאיש אינו מתחזק מתיישן כבר אחרי השינוי הראשון.

כיצד תוכנה יכולה לעזור

תוכנות סימולציה לעבודה מסוג זה נעות בין חבילות סימולציה לתעשייה ובין תוספים למנועי משחקים, ורבות מהן מתחברות לפלטפורמות PLC נפוצות. בדקו את הממשקים אל בקר ה-PLC שלכם, את המאמץ הנדרש לבנות ולקרוא לסיגנלים, ואם ניתן לעשות שימוש חוזר במודל בהמשך. כלי הוא שימושי רק כמו המודל שבונים בעזרתו, ובניית המודל היא החלק הגדול יותר בעלות.

הצעד הבא

רשמו את שלושת פרויקטי ההשקעה הבאים שלכם, העריכו את עלות יום עיכוב בהקמה עבור כל אחד, והשוו אותה לעלות המודל. בחרו כפיילוט את הפרויקט שבו ל-commissioning הווירטואלי יש את הסיכוי הגבוה ביותר להחזיר את ההשקעה.