הערות מספק IoT. המלכודות של מדידת מדיור ושירותים קהילתיים

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

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

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

רעיון כללי וקשיים ראשונים

אם אנחנו לא מדברים על מכשירי מדידה בודדים, אלא כאלה שנמצאים במרתפים, חדרי דוודים וארגונים, אז רובם מצוידים כעת בפלט טלמטרי. לעתים קרובות פחות דופק, לעתים קרובות יותר - RS-485/232 או Ethernet. ככלל, מכשירי המדידה השימושיים ביותר הם אלה שסופרים חום. הם מוכנים לשלם עבור השיגור שלהם מלכתחילה.
כבר דנתי בפירוט בתכונות של RS-485 במאמר שלי. בקיצור, זה פשוט ממשק העברת נתונים. בעיקרו של דבר, אלו הן הדרישות לדחפים חשמליים וקווי תקשורת. תיאור החבילות מגיע ברמה גבוהה יותר, בתקן העברת נתונים, הפועל על גבי RS-485. ואיזה תקן יהיה נשאר ליצרן. לעתים קרובות Modbus, אבל לא חובה. גם אם זה Modbus, זה עדיין עשוי להיות שונה במקצת.

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

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

נתחיל מהחלק הראשון.

סקריפטים

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

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

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

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

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

בעיה שניה.

כרטיסי חיבור טכנולוגיים

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

השם עצמו לא אומר לנו כלום. ל-VKT-7 יש מספר פתרונות מצופים ברזל. איזה סוג של ממשק יש לו בפנים?

ישנן אפשרויות שונות. יכול להיות שיש סיכה בבלוק DB-9 סטנדרטי (זהו RS-232). זה יכול להיות רק בלוק מסוף עם אנשי קשר RS-485. אולי אפילו כרטיס רשת עם RJ-45 (במקרה זה ModBus ארוז לתוך Ethernet).

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

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

עבור RS-485/232 אתה צריך ממיר ל-Ethernet. רבים יזכרו מיד את MOHA, אבל זה יקר. עבור הפתרונות שלנו, בחרנו בפתרון סיני זול יותר.

אם הפלט הוא ישירות Ethernet, אין צורך בממיר.

שְׁאֵלָה. נניח שאנו מתקינים את פלט הממשק בעצמנו. האם אתה יכול להקל על חייך ולהתקין מיד את אתרנט בכל מקום?

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

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

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

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

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

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

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

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

איפה עוד יש מלכודות נסתרות?

הנתונים נקראים ויוצקים למסד הנתונים.

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

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

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

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

נראה, מדוע קשיים כאלה? כל כך קשה לגלגל את השעון שלך?

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

ולבסוף, הדובדבן שבקצפת.

הסמכה

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

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

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

למה הכל?

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

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

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

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

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

כל זה קשה, שובר מוח וגוזל זמן. אבל התוצאה שווה את זה. המנויים מקבלים מוצר מוכן ומקיף.

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

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

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

מקור: www.habr.com