מדוע חשוב למפתחי חומרה לבצע cusdev באיכות גבוהה

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

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

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

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

בפוסט זה נדבר על בעיה זו וכיצד לפתור אותה.

IoT בפטרוכימיה

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

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

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

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

זהו מקרה מחקר שימושי ראשון של שימוש אפשרי ב-IoT בייצור.

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

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

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

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

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

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

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

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

לגבי תקנים

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

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

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

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

חיישן מערכת בקרה אוטומטית אחת לשימוש תעשייתי עולה כ-2000 דולר.
חיישן LoRaWAN אחד עולה 3-4 אלף רובל.

לפני 10 שנים היו רק מערכות אוטומטיות לבקרת תהליכים, ללא חלופות, LoRaWAN הופיע לפני 5 שנים.

אבל אנחנו לא יכולים פשוט לקחת ולהשתמש בחיישני LoRaWAN בכל הארגונים שלנו

בחירת טכנולוגיה

עם wifi ביתי הכל ברור, עם ציוד משרדי הכל בערך אותו דבר.

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

קחו למשל את ה-HART האלחוטי, שיוצרו על ידי החבר'ה מאמרסון - גם 2,4 גיגה-הרץ, כמעט אותו wifi. שטח כיסוי כזה מנקודה לנקודה הוא 50-70 מטר. כשחושבים על כך ששטח המתקנים שלנו עולה על גודלם של מספר מגרשי כדורגל, זה נהיה עצוב. ותחנת בסיס אחת במקרה זה יכולה לשרת בבטחה עד 100 מכשירים. ועכשיו אנחנו מקימים התקנה חדשה, בשלבים הראשונים יש כבר יותר מ-400 חיישנים.

ואז יש NB-IoT (NarrowBand Internet of Things), שמסופק על ידי מפעילי סלולר. ושוב, לא לשימוש בייצור - ראשית, הוא פשוט יקר (המפעיל גובה תשלום עבור תעבורה), ושנית, הוא יוצר תלות חזקה מדי במפעילי טלקום. אם אתה צריך להתקין חיישנים כאלה בחצרים כגון בונקר, שבו אין תקשורת, ואתה צריך להתקין שם ציוד נוסף, יהיה עליך לפנות למפעיל, תמורת תשלום ועם מועדים בלתי צפויים לביצוע הזמנה לכיסוי. האובייקט עם רשת.

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

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

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

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

מה עוד חסר?

חוסר דיאלוג

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

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

ציוד ה-IT מתאים בהחלט, אבל יש בעיות לתעשייה.

סוללה 3400 mAh. כמובן, זה לא הכי פשוט, כאן זה תיוניל כלוריד, שנותן לו את היכולת לעבוד ב-50 ולא לאבד יכולת. אם נשלח מידע מחישן כזה אחת ל-10 דקות, הוא יגרום לריקון הסוללה תוך שישה חודשים. אין שום דבר רע בפתרון מותאם אישית - הברג את החיישן, הכנס סוללה חדשה עבור 300 רובל כל שישה חודשים.

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

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

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

ולגבי העיקר

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

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

מה לעשות

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

כרגע אנחנו כבר בונים מספר פרויקטים על LoRaWAN באזור הירוק (שם מיגון פיצוץ הוא לא פרמטר חובה עבורנו), אנחנו בוחנים איך זה בכלל, והאם LoRaWAN מתאים לפתרון בעיות על כזה סוּלָם. מאוד אהבנו את זה ברשתות בדיקה קטנות; עכשיו אנחנו בונים רשת עם צפיפות גבוהה של חיישנים, שבה מתוכננים כ-400 חיישנים להתקנה אחת. מבחינת כמות עבור LoRaWAN זה לא הרבה, אבל מבחינת צפיפות הרשת זה כבר קצת הרבה. אז בואו נבדוק את זה.

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

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

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

מקור: www.habr.com