שירותים וקוד מדור קודם הצמוד ל-SCADA: שיקולים מיוחדים עבור צוותי מודרניזציה

גבול ה-IT/OT בארגון שירות אינו קו נקי על דיאגרמת רשת. זוהי קרום חדיר שדרכו נתונים זורמים בשני הכיוונים, תוכניות COBOL המייצרות קבצי תצורה של נקודות הגדרה הנצרכים על ידי בקרים מבוקרים (PLC), תוכניות RPG קוראות נתוני היסטוריית SCADA לצורך חיוב ודיווח רגולטורי, גשרי C מדור קודם שמתרגמים פלטי מחשב מרכזי לפורמטים שמערכות בקרה מבוזרות מבינות, זרמי משימות JCL שמתזמנים ומסדרים חילופי נתונים על פני הגבול בתזמון שתהליכים תפעוליים תלויים בו. התוכנה שמנהלת זרימה זו אינה טהורה של IT וגם לא טהורה של OT. זוהי רקמת החיבור שגורמת לתשתיות לתפקד, וזוהי קטגוריית הקוד שצוותי המודרניזציה הכי פחות מוכנים לנתח כאשר תוכנית טרנספורמציה מתחילה.

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

מה המשמעות של "SCADA-Ajacent" בפועל

המונח "צמוד ל-SCADA" מתאר תוכנה בצד ה-IT שמתממשקת עם מערכות טכנולוגיה תפעוליות, לא עם תוכנת ה-SCADA עצמה, לא עם קושחת ה-PLC, לא עם קוד ה-RTU המוטמע, אלא עם שכבת היישומים העסקיים שמזינה נתונים ומקבלת נתונים מהמערכות הללו. קטגוריה זו גדולה, אינה מנותחת מספיק, ושונה באמת משאר תיק היישומים הארגוניים.

בסביבת שירות טיפוסית, קוד צמוד ל-SCADA כולל:

תוכניות חישוב קצב ונקודות ייעוד. תוכניות COBOL ו-PL/I המחשבות נקודות ייעוד עומס, יעדי מתח, ספי לחץ ומגבלות תפעול המסופקות למערכות SCADA כקבצי תצורה או הזנות נתונים ישירות. תוכניות אלו מקודדות דרישות תאימות רגולטוריות, מפרטים הנדסיים ומגבלות בטיחות פיזיות. חישוב שגוי אינו מייצר מספר שגוי בדוח, הוא מייצר נקודת ייעוד תפעולית שגויה שעל פיה מערכת בקרה פועלת.

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

תוכניות גשר פרוטוקולים. תוכניות C מותאמות אישית המתרגמות בין פורמטי פלט של מחשב מרכזי לבין ממשקים מבוססי קבצים או מבוססי רשת שצורכות מערכות DCS (מערכת בקרה מבוזרת) ו-SCADA. גשרים אלה מיישמים פרוטוקולים ספציפיים, Modbus, DNP3, IEC 61850, פורמטים של ספקים קנייניים, ויש להם הנחות קידוד קשיחות לגבי מבנה הודעות, סדר בתים ותזמון שאינן קיימות בשום מקום בתיעוד.

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

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

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

מדוע ניתוח מודרניזציה סטנדרטי נכשל כאן

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

השלכות פיזיות של שגיאות נתונים

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

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

תלויות תזמון שניתוח סטטי אינו יכול לדמות

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

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

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

זיהוי פונקציות בטיחות

IEC 61511 (בטיחות פונקציונלית עבור מגזרי תעשיית התהליך) ו-IEC 61508 (בטיחות פונקציונלית עבור מערכות בטיחות חשמליות/אלקטרוניות/ניתנות לתכנות) מגדירים דרישות הסמכה לתוכנה המבצעת פונקציות בטיחות. קוד שאושר תחת תקנים אלה אינו רק קוד מדור קודם שניתן לעבד אותו מחדש לצורך תחזוקה. ההסמכה היא עבור ארטיפקטים של קוד ספציפיים, הגרסה הספציפית של הקובץ הבינארי הספציפי שגוף ההסמכה העריך. שינוי הקוד, אפילו כדי לתקן בעיית איכות שלא תהיה ראויה לציון ביישום עסקי, מבטל את ההסמכה ודורש הסמכה מחדש לפני שניתן יהיה לפרוס את הקוד שהשתנה בפונקציית בטיחות.

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

צימוד חומרה ופרוטוקולים

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

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

גבול ה-IT/OT: היכן נמצא הקוד

מודל פרדו (ISA-99 / IEC 62443) מגדיר את הארכיטקטורה הקונספטואלית של רשתות מערכות בקרה תעשייתיות בחמש רמות, החל מתהליכים פיזיים ברמה 0 ועד למערכות עסקיות ארגוניות ברמה 4. קוד מדור קודם הצמוד ל-SCADA בסביבות שירות בדרך כלל נמצא ברמות 3 ו-4, אזורי פעולות הייצור ורשת הארגון, אך זרימת הנתונים שלו חוצה את הרמה 2 (שכבת הפיקוח של SCADA) בשני הכיוונים.

גבול ה-IT/OT בין רמות 3 ו-2 הוא המקום שבו הסיכון הביטחוני והתפעולי הוא הגבוה ביותר. גורמים מדינתיים מתמקמים מראש בתוך רשתות OT חודשים לפני ההפעלה, בעוד שקבוצות כופר פורסות כיום מטענים תואמי ICS המתוכננים לנעול HMI ולעצור את הייצור. נקודת הכניסה הנפוצה ביותר אינה תוכנת SCADA המוטמעת, אלא שכבת הגבול של IT/OT, שבה קוד בצד ה-IT ומערכות בצד ה-OT מחליפות נתונים באמצעות ממשקים שתוכננו לאמינות תפעולית ולא לאבטחה עוינת.

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

תבניות קוד ספציפיות לתוכניות צמודות ל-SCADA

קוד חישוב יחידת הנדסה

חישובי יחידת הנדסה (EU) ממירים ערכי גלם של חיישן, בדרך כלל ספירות שלמות מממירי אנלוגי-לדיגיטלי, למדידות פיזיקליות עם יחידות, טווחים ודיוק ספציפיים. לולאת זרם של 4-20mA ממשדר לחץ מייצרת ספירה גולמית; חישוב ה-EU ממיר אותה ל-PSI או לבר עם כיול איפוס וטווח נכון.

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

קובול

       CALCULATE-PRESSURE-EU.
      *  RAW-COUNT ranges 0-4095 (12-bit ADC)
      *  SENSOR-ZERO-OFFSET = 819  (4mA = 20% of 4095)
      *  SENSOR-SPAN       = 3276  (16mA span = 80% of 4095)  
      *  RANGE-LOW-PSI     = 0
      *  RANGE-HIGH-PSI    = 500
           COMPUTE EU-PRESSURE-PSI =
               (RAW-COUNT - SENSOR-ZERO-OFFSET) /
               SENSOR-SPAN *
               (RANGE-HIGH-PSI - RANGE-LOW-PSI)
               + RANGE-LOW-PSI
           IF EU-PRESSURE-PSI < RANGE-LOW-PSI OR
              EU-PRESSURE-PSI > RANGE-HIGH-PSI
               MOVE 'RANGE-VIOLATION' TO ALARM-STATUS
               PERFORM GENERATE-ALARM
           END-IF.

הקבועים בחישוב זה, SENSOR-ZERO-OFFSET, SENSOR-SPAN, RANGE-LOW-PSI, RANGE-HIGH-PSI, תואמות למפרטי המכשיר הפיזי. אם הם מקודדים בקפידה (כפי שקורה לעתים קרובות בקוד מדור קודם), שינוי במכשיר הפיזי דורש שינוי קוד. אם הם שגויים (עקב כיול מחדש של המכשיר, החלפה או שגיאת תצורה מקורית), ערך ה-EU שגוי באופן שיטתי עבור כל רשומה שהתוכנית יצרה אי פעם. ניתוח סטטי יכול למצוא היכן קבועים אלה מוגדרים; רק אימות תפעולי יכול לאשר האם הם נכונים עבור תצורת המכשיר הנוכחית.

יצירת אזעקות ולוגיקת סיווג

קוד ליצירת אזעקות הוא בין הקודים הרגישים ביותר לתקנות הקשורים ל-SCADA בסביבות שירות. תקני NERC CIP (הגנה על תשתיות קריטיות) עבור שירותים חשמליים, דרישות NRC עבור מתקנים גרעיניים ודרישות דיווח של ה-EPA עבור שירותים במים ובשפכים, כולם מציינים אילו אירועים חייבים ליצור אזעקות, איזה מידע האזעקות חייבות להכיל, ובתוך אילו מסגרות זמן יש לדווח עליהן.

קובול

       CLASSIFY-ALARM.
           EVALUATE TRUE
               WHEN EU-PRESSURE-PSI > HIGH-HIGH-LIMIT
                   MOVE 'HH'   TO ALARM-PRIORITY
                   MOVE 'NERC' TO REPORTING-FLAG
                   PERFORM GENERATE-NERC-EVENT
               WHEN EU-PRESSURE-PSI > HIGH-LIMIT
                   MOVE 'HI'   TO ALARM-PRIORITY
                   MOVE 'LOG'  TO REPORTING-FLAG
               WHEN EU-PRESSURE-PSI < LOW-LIMIT
                   MOVE 'LO'   TO ALARM-PRIORITY
                   MOVE 'LOG'  TO REPORTING-FLAG
               WHEN EU-PRESSURE-PSI < LOW-LOW-LIMIT
                   MOVE 'LL'   TO ALARM-PRIORITY
                   MOVE 'NERC' TO REPORTING-FLAG
                   PERFORM GENERATE-NERC-EVENT
           END-EVALUATE.

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

יישומי גשר פרוטוקולים

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

c

/* Legacy Modbus RTU bridge -- written for Modicon 984 PLCs, circa 1998 */
/* NOTE: 984 series uses 1-based register addressing, not 0-based */
/* Function code 03 only -- 984 does not support FC 04 */
/* Max 60 registers per request -- 984 firmware limitation */

#define MODBUS_FC03_READ_HOLDING  0x03
#define MAX_REGS_PER_REQUEST      60    /* 984 firmware limit, not Modbus spec */
#define REGISTER_OFFSET           1     /* 984 uses 1-based addressing */

int read_holding_registers(int start_reg, int count, uint16_t *buffer) {
    /* Compensate for 984 1-based addressing */
    uint16_t adjusted_start = (uint16_t)(start_reg + REGISTER_OFFSET);
    
    if (count > MAX_REGS_PER_REQUEST) {
        /* 984 will return error if count exceeds 60 */
        /* Split into multiple requests silently */
        return read_registers_chunked(adjusted_start, count, buffer);
    }
    /* ... */
}

לקוד זה יש ארבע הנחות מוטמעות לגבי מודל PLC ספציפי שאינן חלק ממפרט Modbus: כתובות אוגרים מבוססות 1, קוד פונקציה 03 בלבד, מקסימום של 60 אוגרים, והתנהגות חלוקת נקבים (chucking) עבור בקשות גדולות יותר. אף אחת מהן אינה מופיעה בתיעוד Modbus. אלו הן התנהגויות ספציפיות לספק של Modicon 984, שתועדו במדריך חומרה משנת 1998 שעשוי להיות אינו זמין עוד. אם גשר זה עובר מודרניזציה מבלי להבין הנחות אלו, או אם ה-PLC מוחלף במודל חדש יותר המשתמש בכתובות סטנדרטיות מבוססות 0, כל קריאת אוגרים מחזירה את הערך השגוי בהיסט כתובת אוגר אחד בדיוק.

ניתוח טרום-מודרניזציה: מה יש לייצר

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

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

מפת חציית גבולות IT/OT. כל זרימת נתונים שחוצה את גבול ה-IT/OT חייבת להיות מתועדת: איזו תוכנה מייצרת את הנתונים, באיזה פורמט, באיזה לוח זמנים; איזו מערכת OT צורכת אותם; ומה ההשלכות אם הנתונים שגויים, מתעכבים או חסרים. מפה זו היא פרופיל הסיכון התפעולי עבור השכבה הסמוכה ל-SCADA.

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

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

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

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

גישות המודרניזציה שעובדות ואלו שלא

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

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

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

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

איך SMART TS XL תומך בניתוח קוד מדור קודם של SCADA

SMART TS XL"S ניתוח קוד סטטי חל על צד ה-IT של הגבול הסמוך ל-SCADA, תוכניות COBOL, JCL, RPG, PL/I ו-C הפועלות על מחשבים מרכזיים ומערכות בינוניות ומייצרות, טרנספורמציות או צורכות נתונים שחוצים לסביבות OT. עבור קוד זה, ניתוח מבני מייצר את מלאי הפונקציות התפעוליות ואת רישום הפרמטרים המקודד קשיח הנדרשים על ידי ניתוח טרום-מודרניזציה.

מיפוי תלות היישומים בונה את מפת חציית הגבולות של IT/OT: כל תוכנית שכותבת לממשק קובץ הנצרך על ידי מערכת SCADA, כל שלב במשימת JCL שמייצר נתונים בעלי משמעות תזמון תפעולי, כל תוכנית במסלול נתוני ההיסטוריון ממקור OT לצרכן ה-IT. כאשר תוכנית COBOL לחיוב של חברת שירות קוראת נתוני היסטוריון דרך גשר C ביניים, מפת התלות מייצגת הן את התלות בין COBOL ל-C והן את התלות בין C להיסטוריון כשרשרת מחוברת, מה שהופך את חציית הגבולות המלאה של IT/OT לגלויה ולא ניתנת לגילוי רק באמצעות אירוע תפעולי.

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

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

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

לתכנון צוותים מודרניזציה מורשת של מערכות שירות, SMART TS XL מספק ניתוח מבני בצד ה-IT, אשר מציב את צוות המודרניזציה לעבודה יעילה לצד מהנדסי בקרה בצד ה-OT שמבינים את ההקשר התפעולי. גבול ה-IT/OT אינו נחצה בבטחה על ידי צוותי IT בלבד או על ידי צוותי OT בלבד, הוא נחצה בבטחה כאשר לשני הצדדים יש ידע מבני מדויק על מה שמכילים המערכות שלהם.

מדוע קוד זה דורש סוג שונה של תשומת לב

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

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