ניטור ציוד ייצור: איך זה הולך ברוסיה?

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

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

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

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

למה אנחנו לא יכולים בלי ניטור מרחוק?

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

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

ובכן, מכשירים עדיין כותבים יומנים, נכון? מה הבעיה?

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

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

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

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

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

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

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

נישת שוק

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

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

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

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

ויש גרפים מהציוד:

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

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

תקציר

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

בואו ניתן כמה דוגמאות למה שזה נותן בפועל.

1. הנה יצרן עולמי של ציוד קירור תעשייתי המשמש בעיקר ברשתות השיווק. 10% מהכנסות החברה מגיעות ממתן שירותים לשירות מוצריה. יש צורך להוזיל את עלות השירותים ובאופן כללי לתת הזדמנות להגדיל את ההיצע באופן רגיל, כי אם נמכור יותר, מערכת השירות הקיימת לא תתמודד. התחברנו ישירות לפלטפורמה של מרכז שירות יחיד, שינינו כמה מודולים לצרכי הלקוח הספציפי הזה, וקיבלנו הפחתה של 35% בהוצאות הנסיעה בשל העובדה שגישה למידע שירות מאפשרת לזהות את הסיבות של כשל ללא צורך במהנדס שירות לביקור. ניתוח נתונים על פני תקופות זמן ארוכות - חיזוי המצב הטכני ובמידת הצורך בצע במהירות תחזוקה מבוססת מצב. כבונוס, מהירות התגובה לבקשות גדלה: יש פחות נסיעות בשטח, ומהנדסים מסוגלים לעשות דברים מהר יותר.
2. חברת הנדסת מכונות, יצרנית כלי רכב חשמליים המשמשים בערים רבות של הפדרציה הרוסית וחבר העמים. כמו כולם, הם רוצים להוזיל עלויות ובמקביל לחזות את המצב הטכני של ציי הטרוליבוסים והחשמליות בעיר כדי להודיע ​​לצוות הטכני במועד. חיברנו ויצרנו אלגוריתמים לאיסוף והעברת נתונים טכניים ממלאי מתגלגל למרכז מצב בודד (האלגוריתמים מובנים ישירות במערכת בקרת הכוננים ועובדים עם נתוני CAN bus). גישה מרחוק לנתוני מצב טכני, כולל גישה בזמן אמת לפרמטרים משתנים (מהירות, מתח, העברת אנרגיה משוחזרת וכו') במצב "אוסצילוסקופ", נתנה גישה לעדכוני קושחה מרחוק. התוצאה היא הפחתה של 50% בעלויות הנסיעה: גישה ישירה למידע השירות מאפשרת לזהות את הסיבות לכשל ללא צורך במהנדס שירות לביקור, וניתוח הנתונים על פני מרווחי זמן ארוכים מאפשר לחזות את מצב טכני ובמידת הצורך לבצע במהירות תחזוקה "מבוססת מצב", כולל ניתוח אובייקטיבי של מצבי חירום. יישום חוזי מחזור חיים מורחבים בהתאמה מלאה לדרישות הלקוח ובזמן. עמידה בדרישות המפרט הטכני של המפעיל, כמו גם מתן הזדמנויות חדשות במונחים של ניטור מאפייני השירות לצרכן (איכות מיזוג האוויר, האצה/בלימה וכו').
3. הדוגמה השלישית היא עירייה. אנחנו צריכים לחסוך בחשמל ולשפר את בטיחות האזרחים. חיברנו פלטפורמה אחת לניטור, ניהול ואיסוף נתונים על תאורת רחוב מחוברת, ניהול מרחוק של כל תשתית התאורה הציבורית ושירות מלוח בקרה אחד, מתן פתרונות למשימות הבאות. מאפיינים: עמעום או כיבוי אורות מרחוק, בנפרד או בקבוצות, הודעה אוטומטית לשירותי העיר על תקלות בנקודות תאורה לתכנון תחזוקה יעיל יותר, אספקת נתוני צריכת אנרגיה בזמן אמת, מתן כלים אנליטיים רבי עוצמה לניטור ושיפור תאורת הרחוב. מערכת המבוססת על Big Data, מספקת נתונים על תעבורה, מצב אוויר, אינטגרציה עם תת-מערכות אחרות של Smart City. תוצאות - הפחתת צריכת אנרגיה לתאורת רחוב עד 80%, הגברת הבטיחות לתושבים באמצעות שימוש באלגוריתמים חכמים של בקרת תאורה (אדם שהולך ברחוב - מדליק לו את האור, אדם במעבר חצייה - מדליק יותר תאורה כך שניתן לראותו מרחוק), מתן שירותים נוספים לעיר (טעינת רכבים חשמליים, מתן תוכן פרסומי, מעקב וידאו וכו').

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

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

מקור: www.habr.com