החשיבות של אוטומציית בקרה
על אוטומציית בקרה מדברים במונחים של יעילות וחיסכון, וזה בעצם מוכר אותה בזול. מה שאוטומציה באמת משנה זה את היחסים בין התהליך לאנשים שמפעילים אותו: היא מעבירה את העובדים מביצוע פעולות בקרה חוזרות לפיקוח על מערכת שמבצעת אותן, והיא הופכת את התהליך לנצפה בצורה שהפעלה ידנית לעולם לא מאפשרת.
בדיוק שם נמצא הערך, ובדיוק שם נמצא גם הסיכון. אוטומציה של תהליך שלא מבינים אותו לעומק פשוט מייצרת שגיאות מהר יותר.
עקביות, לא רק מהירות
הרווח הברור ביותר מאוטומציה הוא חזרתיות. לולאת בקרה פועלת בדיוק אותו דבר בשלוש לפנות בוקר בחג ובאמצע יום עבודה רגיל, והיא לא מדלגת על שלב כי מישהו הפריע למפעיל. בתהליכים שבהם איכות התוצר תלויה בתזמון או ברצף מדויק, העקביות הזו שווה יותר מכוח האדם שהיא מחליפה.
טעות אנוש בבקרה ידנית היא כמעט אף פעם לא רשלנות. היא התוצאה הצפויה של בקשה מאנשים לבצע משימות מדויקות ומונוטוניות תחת לחץ זמן, לא פעם בסוף משמרת. אוטומציה מסירה את המשימה במקום להאשים את המפעיל.
נראוּת בזמן אמת משנה החלטות
תהליך ידני חושף בעיות בדיעבד, בדרך כלל כשכבר קרה משהו. תהליך אוטומטי ומנוטר חושף אותן בזמן שהן מתפתחות: מגמה שזזה לכיוון הלא נכון, מגוף שלוקח לו יותר זמן להיפתח מאשר בחודש שעבר, טמפרטורה שנודדת מחוץ לתחום הרגיל שלה בזמן שהיא עדיין בתוך גבולות ההתראה.
הנתונים האלה הם מה שהופך תחזוקה מתגובתית למתוכננת. הערך הוא לא הדשבורד. הערך הוא היכולת להתערב לפני שתקלה הופכת להשבתה.
- חריגות מתגלות כמגמה ולא ככשל
- נתוני ביצועים תומכים בהחלטות תכולה והשקעה עם ראיות
- אפשר לתזמן תחזוקה לפי מצב בפועל ולא לפי לוח שנה או לפי תקלה
- אפשר לשחזר אירועים בדיוק אחרי שקרו
לאן הנתונים הולכים, ומי פועל לפיהם
נראוּת לא שווה כלום אם הנתונים לא נוחתים בשום מקום. רוב פרויקטי האוטומציה מגדירים בקרים ומכשור בקפידה, ואז מתייחסים למאגר הנתונים ההיסטורי כאל מחשבה מאוחרת. וכך מגיעים למתקן עם מכשור מצוין ושלושה שבועות של היסטוריה. תחזוקה לפי מצב צריכה עונות של נתונים, לא שבועות. משאבה שנשחקת לאורך שנה וחצי נראית כמו פעולה תקינה לגמרי בכל חודש בודד.
לחשב את גודל מאגר הנתונים זה חישוב פשוט וכדאי לעשות אותו מוקדם: כמות תגיות, קצב דגימה, תחום מתה ותקופת שמירה. תחום המתה משמעותי יותר ממה שרוב האנשים מניחים. רישום טמפרטורה לפי שינוי במקום לפי מרווח קבוע יכול לחתוך את נפח האחסון בסדר גודל שלם בלי לאבד שום דבר בעל ערך אנליטי. החליטו לכל תגית בנפרד, לא באופן גורף.
- קבעו תקופת שמירה שמאפשרת לראות מחזור שנתי שלם, לא רבעון
- רשמו לפי תחום מתה כשהאות איטי; לפי מרווח זמן כשהתזמון קריטי
- שמרו נתונים גולמיים ברזולוציה מלאה ללולאות קריטיות, וצברו את השאר
- ודאו שגם מי שאינו מהנדס בקרה יכול לשלוף שאילתה מהמאגר
- גבו את המאגר ההיסטורי בנפרד ממערכת הבקרה, כי הם נופלים מסיבות שונות
החצי השני של הבעיה הוא מי פועל לפי מה שהנתונים מראים. מגמה שמזהה מיסב שמתחיל להיכשל לא שווה כלום אם היא לא מגיעה למתכנן תחזוקה שיש לו סמכות לתזמן את העבודה. בפועל זה אומר אינטגרציה בין מערכת הבקרה למערכת ניהול התחזוקה או ל-ERP: סף מצב שמייצר הזמנת עבודה אוטומטית, עם המגמה מצורפת אליה. זו עבודה לא זוהרת ובאופן קבוע היא נחתכת מהתכולה, ואז הניתוח מייצר תובנה שמתה בדשבורד שאף אחד לא פותח.
אם כבר מגדירים אינטגרציה כזו, הגדירו גם מי אחראי על הזמנת העבודה שנוצרת ומה קורה אם אף אחד לא סוגר אותה. הזמנת עבודה אוטומטית שיושבת בלי טיפול חצי שנה גרועה יותר מהיעדר הזמנת עבודה, כי היא מתעדת שהארגון ידע.
כמות הנקודות קובעת את גודל הבקרים וכרטיסי ה-I/O הרבה לפני שהנתונים האלה בכלל קיימים. להערכה ראשונית למבנה, השתמשו במחשבון החינמי שלנו: מחשבון נקודות BMS
איפה פרויקטי אוטומציה נכשלים
הכשלים עקביים מספיק כדי להיות צפויים, וכמעט אף אחד מהם לא קשור לטכנולוגיה.
- אוטומציה של תהליך שלא מבינים, וכך מקבעים את הבעיות הקיימות לתמיד
- ניטור של הרבה יותר נקודות ממה שמישהו אי פעם יסתכל עליהן, מה שמייצר עייפות התראות
- בניית מערכת שרק אדם אחד מבין, ואז אותו אדם עוזב
- דחיית אבטחת הסייבר לשלב מאוחר, על מערכות בקרה שכבר יושבות על הרשת
- ויתור על מסלול ידני חלופי ומתורגל למקרה שהאוטומציה עצמה נופלת
עייפות התראות ראויה לתשומת לב מיוחדת. מערכת שמייצרת מאות התראות חסרות ערך מאמנת את המפעילים להתעלם מכולן, כולל מזו שבאמת חשובה. הגדרה מסודרת של מה מצדיק התראה ומה הוא סתם נתון היא חלק מההנדסה, לא שיפור אופציונלי.
בעיית המסירה שאף אחד לא מתקצב
הסעיף השלישי ברשימה, מערכת שרק אדם אחד מבין, הוא הכשל שגורם לנזק הגדול ביותר. הוא צף שנים אחרי המסירה, כשכבר אף אחד לא זוכר את הפרויקט. הלוגיקה בבקר או ב-PLC היא הצטברות של עשרות החלטות, וכמעט שום דבר מהכוונה שמאחוריהן לא נראה בקוד עצמו. טיימר שהוגדר ל-47 שניות מקודד משהו אמיתי על התהליך. שנתיים אחר כך, כשמהנדס ההרצה כבר לא כאן, אף אחד לא יודע מה.
ההגנה מפני זה היא תיעוד ההרצה, והוא חייב להיות תוצר חוזי בפורמט מוגדר ולא הבטחה. דרשו את קוד המקור בצורה ניתנת לעריכה ולא מהודרת, יחד עם הרישיון שנדרש כדי לפתוח אותו; דרשו תיאור כתוב של כוונת הבקרה לכל לולאה, בשפה פשוטה; דרשו את סט הפרמטרים כפי שנמסר, מיוצא ומתוארך. ודאו את כל אלה לפני התשלום האחרון, כי אחריו כוח המיקוח שלכם נעלם.
- קוד מקור ניתן לעריכה לכל לוגיקת הבקרים, כולל רישיון התוכנה לפתיחה ולשינוי
- תיאור בקרה לכל לולאה או רצף, שמסביר את הכוונה בשפה פשוטה
- רשימת נקודות עבודה ופרמטרים כפי שנמסרו, מיוצאת ומתוארכת
- תרשים רשת, תוכנית כתובות IP וכל סיסמאות ההתקנים, בידי בעל המתקן
- בעלים פנימי בשם מלא ללוגיקה, ואדם שני שהוכשר כגיבוי
- נוהל מתועד לחזרה לתצורה תקינה ידועה
על נקודת הכשל האנושית היחידה כדאי לדבר בגלוי. אם קבלן אחד מחזיק את העותק היחיד של הלוגיקה ואת ההבנה היחידה שלה, הארגון לא באמת בעלים של האוטומציה שלו. הוא שוכר אותה בתנאים שאי אפשר לנהל עליהם משא ומתן. הכשירו אדם שני פנימית, גם אם ישתמש בידע לעיתים רחוקות, ודרשו שכל שינוי אחרי המסירה יתועד באותו סטנדרט כמו ההרצה המקורית. שינויים שנעשו בחיפזון ולא נרשמו הם בדיוק הדרך שבה מערכת מתועדת היטב הופכת לבלתי מתועדת תוך שלוש שנים.
לתחום את התכולה נכון
פרויקטי אוטומציה מוצלחים מתחילים בדרך כלל בקטן. עושים אוטומציה לתהליך אחד שמבינים היטב, מנטרים אותו כמו שצריך, מריצים אותו מספיק זמן כדי לסמוך עליו, ורק אז מתרחבים מבסיס עובד. ניסיון להריץ מתקן שלם בבת אחת מייצר מערכת שהורצה בכל מקום ואף אחד לא סומך עליה.
אוטומציית בקרה היא כבר לא "נחמד שיש" לארגונים שרוצים תוצר עקבי והפעלה מבוססת נתונים. אבל התועלת מגיעה מתיחום ממושמע, מהבנה כנה של התהליך ומתשומת לב לגורם האנושי סביב המערכת. היא לא מגיעה מכמות הטכנולוגיה שהתקינו.