מפחיתים את צריכת האנרגיה של הבניין ב-30% עם ניהול מבוסס בינה מלאכותית

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

תחומי פיתוח AI

שאלות נפוצות

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

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

AI בניין חכם: כשהאוטומציה עובדת לשווא

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

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

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

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

שליטה חזויה באקלים: אפקט מדיד

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

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

הפחתת צריכת האנרגיה בלי לאבד נוחות

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

באתרים עם מדידה רציפה הצריכה לחימום ולקירור ירדה ב-27–34% בעונה, וסטיות הטמפרטורה הצטמצמו מ-±2.5 °C ל-±0.8 °C.

פחות תקלות ציוד ופחות יציאות שלא מתוכננות

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

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

דרכי הטמעה: ענן, מודול מקומי, היברידי

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

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

כיצד לבחור מצב: קריטריונים ומגבלות

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

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

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

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

  1. ביקורת מערכות הנדסיות. הרכב הציוד, מצבי העבודה בפועל, נקודות איסוף הנתונים, איכות מערכת הניטור והבקרה הקיימת. בפלט — מפת עומסים ורשימת מעגלים עם פוטנציאל שליטה.
  2. תכנית אינטגרציה. אנחנו קובעים מהיכן לוקחים נתונים וכיצד מחזירים פעולות שליטה: חיישנים חדשים, בקרים קיימים, שערים (gateways). את גבולות האחריות מתאמים עם מחלקת התפעול.
  3. כוונון מעגלי השליטה. ערכי יעד, סדרי עדיפויות ומגבלות — לפי טמפרטורה, לחות ולוח הזמנים של התפוסה. לכל החלטה של האוטומציה נשאר הסבר מובן למהנדס.
  4. פיילוט על מעגל אחד. המודל לומד מנתונים אמיתיים של האתר, ולא מהנחות ממוצעות.
  5. בדיקת השערות. משווים את הצריכה לפני ואחרי בתקופות ובתנאי מזג אוויר ברי-השוואה, ומנטרלים את עונתיות. אם השיפור לא אומת — מתקנים את הלוגיקה ולא מרחיבים את השטח.
  6. הכפלה. מעבירים את הכללים המגובשים לשאר המעגלים, עם תיקון לאינרציה שלהם ולהשפעה ההדדית ביניהם.
  7. מסירה לתפעול. מאמנים את המחלקה, מוסרים תיעוד, ומשאירים את השליטה הידנית זמינה בכל רגע.

מה עושים בשלב הפיילוט על מעגל אחד

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

מה מוסרים ללקוח: קונפיגורציות ותקנות תפעול

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

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

תיעוד ותקנות תפעול

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

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

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

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

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

תחילה אספנו היסטוריה: טלמטריה מהבקרים ונתוני האוטומציה הקיימת של הבניין לעונה שלמה. שכבת האנליטיקה נפרסה מעל המערכת הפועלת Schneider Electric EcoStruxure Building Operation — בלי להחליף ציוד ובלי לעצור את התפעול.

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

בעונת החימום הצריכה ירדה ב-31%, ההספק בשיא — ב-18%, יציאות החירום — מ-9 ל-2 בחודש, והתגובה לסטייה — מכמה שעות ל-15 דקות. ההשקעה החזירה את עצמה תוך 14 חודשים בזכות הפחתת הצריכה.

היכן האפקט היה גבוה מהציפיות

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

במה שליטה חזויה נבדלת מלוח זמנים

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

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

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

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

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

מגבלות: היכן שליטת AI לא תחליף מהנדס

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

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

מה עושים אם הנתונים ההיסטוריים מועטים או חלקיים?

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

כיצד המערכת מתנהגת בעת אובדן תקשורת או כשל חיישן?

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

מי אחראי להחלטות והאם אפשר לחזור לשליטה ידנית?

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

עד כמה הפתרון תואם לאוטומציה הקיימת של הבניין?

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

נדון במשימה ונחזור עם הערכה ותכנית

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

שלחו את מה שיש — אפילו סט חלקי נותן תמונה מעשית:

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

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