פיתוח מערכת בינה מלאכותית לאופטימיזציה של צריכת אנרגיה בייצור

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

תחומי פיתוח AI

שאלות נפוצות

העבודות האחרונות

  • פיתוח אפליקציית ווב עבור FEEDME
    פיתוח אפליקציית ווב עבור FEEDME
    1365
  • פיתוח חנות מקוונת לחברת FURNORO
    פיתוח חנות מקוונת לחברת FURNORO
    1330
  • עיצוב לוגו לחברת B2B Advance
    עיצוב לוגו לחברת B2B Advance
    776
  • פיתוח אפליקציית ווב עבור Enviok
    פיתוח אפליקציית ווב עבור Enviok
    1077
  • פיתוח לוגו חברת AIDER
    פיתוח לוגו חברת AIDER
    1022
  • פיתוח CRM עבור Chasseurs
    פיתוח CRM עבור Chasseurs
    1113

אופטימיזציה של צריכת אנרגיה: היכן הייצור מאבד אנרגיה לשווא

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

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

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

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

מה משתנה באתר: שיאי עומס וצריכה לטון תוצר

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

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

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

מצבי הפעולה של המערכת: ממליץ, אוטומטי, לולאה סגורה

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

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

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

מגבלות האוטומציה בשלב ההתחלה

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

כיצד אנחנו מטמיעים את המערכת: מאודיט הצריכה ועד מסירה לעבודה

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

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

  2. הערכת איכות נתוני המדידה. אנחנו מאחדים ארכיוני מונים ויומנים ידניים, מחפשים חסרים, אי-סנכרון של חותמות זמן ורשומות כפולות. משחזרים סדרה רציפה על פני מחזור ייצור מלא — בלי עונתיות ומצבי משמרות אי אפשר לאמן את המודל.

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

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

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

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

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

מה נשאר באתר: מודלים, תרשימי מדידה, נהלים

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

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

דוגמת הטמעה: כיצד שיאי העומס הפסיקו לקבוע את הצריכה

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

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

לאחר מכן — כללי החלקה: חימום מדורג של יחידות עתירות אנרגיה, פיזור הפעלות של קווים על פני חלון של 40-60 דקות, מאגר חוצץ לאוויר דחוס ולקור, ותחזית שיא לחצי שעה קדימה עם המלצה איזו מכונה להזיז.

האופטימיזציה של צריכת האנרגיה התבצעה לא לפי ממוצע חודשי, אלא לפי הפרופיל היומי; את הדיווח התאמנו לדרישות ISO 50001.

מדדים לפני ואחרי: הספק השיא של הכניסה נמוך ב-19%, הצריכה הסגולית ליחידת תוצר — ב-11%, והפיזור בין המשמרות הצטמצם מ-±14% ל-±5%. הפעלות של הגנות עומס יתר על הכניסות — אחת לרבעון במקום חמש-שבע בחודש.

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

אופטימיזציה של צריכת אנרגיה לפי לוח זמנים או לפי תחזית עומס?

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

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

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

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

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

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

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

התלבטויות לפני ההפעלה: מדידה, נתונים ואחריות להחלטות

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

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

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

מה עושים אם המדידה חלקית או שהקריאות סותרות זו את זו?

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

האם יהיה צורך לבנות מחדש את הדיספוטינג הקיים?

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

מי אחראי להמלצות ולטעויות של המודל?

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

מה כלול בתמיכה לאחר ההפעלה?

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

נדבר על המשימה: ממה מתחילים באתר שלכם

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

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

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

תארו את המשימה — נחזור עם הערכה ותוכנית להרצת פיילוט.