یادداشت های ارائه دهنده اینترنت اشیا. مشکلات نقشه برداری کنتورهای مسکن و خدمات عمومی

با سلام خدمت طرفداران عزیز اینترنت اشیا. در این مقاله دوباره می خواهم در مورد مسکن و خدمات عمومی و بررسی دستگاه های اندازه گیری صحبت کنم.

هر از گاهی بازیکن بزرگ بعدی مخابرات از اینکه چقدر زود وارد این بازار خواهد شد و همه را زیر پا می گذارد صحبت می کند. هر بار که چنین داستان هایی را می شنوم، فکر می کنم: "بچه ها، موفق باشید!"
شما حتی نمی دانید کجا می روید.

برای اینکه مقیاس مشکل را درک کنید، بخش کوچکی از تجربه خود را در توسعه پلتفرم شهر هوشمند به طور خلاصه به شما می گویم. قسمتی از آن که وظیفه اعزام را بر عهده دارد.

یادداشت های ارائه دهنده اینترنت اشیا. مشکلات نقشه برداری کنتورهای مسکن و خدمات عمومی

ایده کلی و اولین مشکلات

اگر ما در مورد دستگاه های اندازه گیری فردی صحبت نمی کنیم، بلکه آنهایی که در زیرزمین ها، اتاق های دیگ بخار و شرکت ها هستند، در این صورت اکثر آنها اکنون به خروجی تله متری مجهز هستند. کمتر پالس می شود، اغلب - RS-485/232 یا اترنت. به عنوان یک قاعده، مفیدترین دستگاه های اندازه گیری آنهایی هستند که گرما را شمارش می کنند. آنها در وهله اول حاضرند هزینه اعزام خود را بپردازند.
من قبلاً در مقاله خود به طور مفصل درباره ویژگی های RS-485 صحبت کرده ام. به طور خلاصه، این به سادگی یک رابط انتقال داده است. اساساً اینها الزامات تکانه های الکتریکی و خطوط ارتباطی هستند. شرح بسته‌ها در سطح بالاتری قرار دارد، در استاندارد انتقال داده، که در بالای RS-485 عمل می‌کند. و اینکه چه نوع استانداردی وجود خواهد داشت به سازنده واگذار می شود. اغلب Modbus، اما مورد نیاز نیست. حتی اگر Modbus باشد، باز هم ممکن است تا حدودی اصلاح شود.

در واقع، هر متر به اسکریپت بررسی خاص خود نیاز دارد که می تواند با آن "صحبت" کند و آن را بازجویی کند. این بدان معنی است که سیستم اعزام مجموعه ای از اسکریپت ها برای هر شمارنده جداگانه است. پایگاه داده ای که همه اینها در آن ذخیره می شود. و یک رابط کاربری مشخص که در آن بتواند گزارش مورد نیاز خود را تولید کند.

یادداشت های ارائه دهنده اینترنت اشیا. مشکلات نقشه برداری کنتورهای مسکن و خدمات عمومی

آسان به نظر می رسد. شیطان، مثل همیشه، در جزئیات است.

بیایید با قسمت اول شروع کنیم.

اسکریپت ها

چگونه آنها را بنویسیم؟ خب، بدیهی است که یک دستگاه اندازه گیری بخرید، آن را سرهم کنید، یاد بگیرید که با آن ارتباط برقرار کنید و آن را در یک پلت فرم مشترک ادغام کنید.

متاسفانه این راه حل تنها بخشی از نیازهای ما را پوشش خواهد داد. به طور معمول، یک شمارنده محبوب چندین نسل دارد و اسکریپت برای هر نسل ممکن است متفاوت باشد. گاهی کم، گاهی زیاد. وقتی چیزی می‌خرید، آخرین نسل را دریافت می‌کنید. مشترک به احتمال زیاد چیزی قدیمی تر خواهد داشت. دیگر در فروشگاه ها فروخته نمی شود. و مشترک واحد اندازه گیری را تغییر نمی دهد.

از این رو اولین مشکل. نوشتن چنین اسکریپت هایی ترکیبی سخت از توسعه دهندگان نرم افزار و مهندسان «روی زمین» است. ما آخرین نسل را خریدیم، چند الگوی اولیه نوشتیم و سپس آن را در دستگاه های واقعی اصلاح کردیم. انجام این کار در آزمایشگاه، فقط در حین کار با مشترکین زنده غیرممکن است.

برای ایجاد چنین بسته نرم افزاری زمان زیادی از ما گرفت. اکنون الگوریتم کار شده است. قالب های اولیه به طور مداوم تنظیم و تکمیل می شدند، بسته به آنچه در تمرین خود با آن مواجه می شدیم. البته، اگر ناگهان کنتور او کمی "خاموش" شد، به مشترک هشدار داده شد. هنگامی که چنین دستگاهی ظاهر می شود، طبق طرح استاندارد متصل می شود و اسکریپت نظرسنجی در طول مسیر اصلاح می شود. در طول ادغام، مشترک به صورت رایگان کار می کند. به او اطلاع داده می شود که در حال حاضر در حالت آزمایشی به سر می برد. فرآیند ادغام خود یک چیز نسبتاً غیرقابل پیش بینی است. گاهی اوقات فقط باید حداقل اصلاحات را انجام دهید. می‌تواند فرآیند پیچیده‌ای شامل بازدید از سایت، بیل‌کردن ادبیات و غلبه بر چنگک‌ها باشد.

کار آسانی نیست، اما قابل حل است. نتیجه یک اسکریپت کار است. هرچه کتابخانه اسکریپت ها بزرگتر باشد، زندگی راحت تر است.

مشکل دوم

کارت های اتصال تکنولوژیکی

برای اینکه متوجه پیچیدگی این کار شوید، مثالی می زنم. بیایید گرمای سنج بسیار محبوب VKT-7 را در نظر بگیریم.

خود نام چیزی به ما نمی گوید. VKT-7 دارای چندین راه حل با روکش آهن است. چه نوع رابطی در داخل آن وجود دارد؟

یادداشت های ارائه دهنده اینترنت اشیا. مشکلات نقشه برداری کنتورهای مسکن و خدمات عمومی

گزینه های مختلفی وجود دارد. ممکن است یک پین در یک بلوک استاندارد DB-9 وجود داشته باشد (این RS-232 است). این فقط می تواند یک بلوک ترمینال با مخاطبین RS-485 باشد. شاید حتی یک کارت شبکه با RJ-45 (در این مورد ModBus در اترنت بسته بندی شده است).

یا شاید اصلاً هیچی. فقط یک دستگاه اندازه گیری خالی شما می توانید یک خروجی رابط را در آن نصب کنید؛ به طور جداگانه توسط سازنده فروخته می شود و هزینه دارد. مشکل اصلی این است که برای نصب آن باید متر را باز کنید و مهر و موم ها را بشکنید. یعنی سازمان تامین کننده منابع در این فرآیند قرار می گیرد. به او اعلام می شود که مهر و موم ها شکسته می شود، یک روز تعیین شده است و مهندس ما با حضور نماینده منبع، اصلاحات لازم را انجام می دهد و پس از آن دوباره کنتور آب بندی می شود.

بسته به رابط نصب شده، تغییرات بیشتری انجام می شود. به عنوان مثال، ما تصمیم گرفتیم که کنتور را از طریق سیم وصل کنیم. این ساده ترین گزینه است، اگر سوئیچ ما در فاصله 100 متری قرار داشته باشد، در این صورت دست زدن به LoRa اضافی است. اتصال یک کابل به شبکه ما، به یک VLAN ایزوله آسان تر است.

برای RS-485/232 به یک مبدل به اترنت نیاز دارید. بسیاری بلافاصله MOHA را به یاد می آورند، اما گران است. برای راه حل های خود، ما یک راه حل ارزان تر چینی را انتخاب کردیم.

اگر خروجی مستقیماً اترنت باشد، نیازی به مبدل نیست.

سوال فرض کنید خروجی رابط را خودمان نصب می کنیم. آیا می توانید زندگی خود را آسان تر کنید و بلافاصله اترنت را در همه جا نصب کنید؟

این همیشه ممکن نیست. باید به طراحی بدنه نگاه کنیم. ممکن است سوراخ لازم برای قرار گرفتن مناسب رابط را نداشته باشد. به شما یادآوری کنم که پیشخوان در زیرزمین ما است. یا در دیگ بخار. آنجا رطوبت بالایی دارد، مهر و موم شکسته نمی شود. تکمیل بدنه با یک فایل ایده بدی است. بهتر است چیزی را نصب کنید که در ابتدا نیاز به تغییرات اساسی نداشته باشد. اغلب RS-485 تنها راه خروج است.

به علاوه. آیا کنتور به برق تضمینی متصل است؟ اگر نه، با باتری کار می کند. در این حالت برای نظرسنجی دستی هر ماه یک بار به مدت سه دقیقه طراحی شده است. دسترسی مداوم به VKT-7 باتری آن را تخلیه می کند. این به این معنی است که شما باید برق تضمینی ارائه دهید و یک مبدل ولتاژ نصب کنید.

ماژول قدرت برای هر سازنده کنتور متفاوت است. این می تواند یک واحد ریلی خارجی DIN یا یک مبدل داخلی باشد.

به نظر می رسد که انبار ما همیشه باید مجموعه ای از رابط های مختلف و ماژول های قدرت را برای هر متر ذخیره کند. محدوده آنجا چشمگیر است.

البته تمام این هزینه ها در نهایت بر عهده مشترک خواهد بود. اما او یک ماه منتظر نمی ماند تا دستگاه مناسب برسد. و او نیاز به تخمینی برای اتصال اینجا و اکنون دارد. بنابراین ذخیره فناوری بر دوش ما می افتد.

همه چیزهایی که توضیح دادم به یک نقشه ارتباط فنی واضح تبدیل می شود، به طوری که مهندسان محلی فکر نمی کنند که در زیرزمین بعدی با چه جانوری روبرو شده اند و برای کار کردن به چه چیزهایی نیاز دارند.

نقشه فنی در مجاورت مقررات عمومی برای اتصال می باشد. از این گذشته، گنجاندن متر در شبکه ما کافی نیست؛ ما هنوز باید همان VLAN را به پورت سوئیچ متصل کنیم، باید عیب یابی را انجام دهیم و یک نظرسنجی آزمایشی انجام دهیم. ما تلاش می کنیم تا حد امکان کل فرآیند را خودکار کنیم تا از اشتباهات جلوگیری کنیم و مهندسان غیر ضروری را درگیر نکنیم.

خوب، نقشه های فنی، مقررات، اتوماسیون نوشتیم. ما تدارکات را ایجاد کرده ایم.

کجای دیگر دام های پنهان وجود دارد؟

داده ها خوانده می شوند و در پایگاه داده ریخته می شوند.

این اعداد مشترک را نه گرم و نه سرد می کند. او نیاز به گزارش دارد. ترجیحاً به شکلی که او عادت کرده است. حتی بهتر است که فوراً در قالب گزارشی باشد که بتواند آن را بفهمد و بتواند آن را چاپ کند، امضا کند و ارسال کند. این بدان معنی است که ما به یک رابط ساده و قابل درک نیاز داریم که اطلاعات را روی متر نمایش دهد و بتواند به طور خودکار گزارش تولید کند.

اینجا باغ وحش ما ادامه دارد. واقعیت این است که چندین فرم گزارش وجود دارد. در هسته خود، آنها همان چیزی را منعکس می کنند (گرمای مصرف شده)، اما به روش های مختلف.

برخی از مشترکین در مقادیر مطلق گزارش می دهند (یعنی در ستون مصرف گرما، مقادیر با شروع نصب کنتور نوشته می شوند)، برخی دیگر در دلتا (این زمانی است که مصرف را در یک دوره زمانی بدون اشاره به آن می نویسیم. مقادیر اولیه). در واقع آنها از استانداردهای یکسان استفاده نمی کنند، بلکه از شیوه های ثابت شده استفاده می کنند. مواردی وجود داشته است که مشترکین تمام مقادیر مورد نیاز خود را می بینند (مقدار گرمای مصرفی، حجم مایع خنک کننده عرضه شده و تخلیه شده، اختلاف دما)، اما ستون های گزارش به ترتیب صحیح نیستند.
از این رو مرحله بعدی - گزارش باید قابل تنظیم باشد. یعنی مشترک خودش انتخاب می کند که چه مواردی به چه ترتیبی باشد و چه منابعی در سندش باشد.

در اینجا یک نکته جالب وجود دارد. اگر متر ما به درستی نصب شود همه چیز خوب است. اما اتفاق می افتد که شرکت نصب در هنگام نصب ITP اشتباه کرده و زمان کنتور را به اشتباه تنظیم کرده است. ما با دستگاه هایی مواجه شده ایم که فکر می کنند سال 2010 است. در سیستم ما، اگر 2010 را انتخاب کنیم، این رقم برای تاریخ فعلی صفر و مصرف واقعی خواهد بود. دلتاها در اینجا بسیار مفید هستند. یعنی می گوییم در XNUMX ساعت گذشته خیلی اتفاق افتاده است.

به نظر می رسد، چرا چنین مشکلاتی وجود دارد؟ آیا پیچاندن ساعت انقدر سخت است؟

دقیقاً با VKT-7 این منجر به تنظیم مجدد کامل شمارنده و حذف بایگانی ها از آن می شود.
مشترک مجبور خواهد شد به افسران منابع ثابت کند که ITP را نه دیروز بلکه پنج سال پیش نصب کرده است.

و در نهایت، بستنی روی کیک.

گواهی

یک متر و یک گزارش داریم. بین آنها سیستم ما قرار دارد که این گزارش را تولید می کند. آیا او را باور می کنید؟

انجام میدهم. اما چگونه می توانیم ثابت کنیم که هیچ چیز در درون ما تغییر نمی کند، ما معنا را تحریف نمی کنیم. این در حال حاضر یک موضوع صدور گواهینامه است. سیستم نظرسنجی باید گواهینامه ای داشته باشد که بی طرفی آن را تایید کند. تمام سیستم های بزرگ مانند LERS، Ya Energetik و سایرین دارای گواهی مشابه هستند. ما هم دریافت کردیم، هرچند گران است و زمان زیادی می برد.

البته همیشه می توانید گوشه ای را کوتاه کنید و چیزی آماده بخرید. اما توسعه دهنده باید برای این هزینه پرداخت کند. و توسعه دهنده ممکن است نه تنها هزینه ورودی، بلکه هزینه اشتراک را نیز بخواهد. یعنی مجبور می شویم بخشی از پای خود را با او تقسیم کنیم.

چرا این همه؟

این مشکل اصلی نیست. توسعه سیستم شخصی شما نیز بسیار پرهزینه و بسیار دشوارتر است. با این حال، یک مزیت مهم را فراهم می کند. ما به وضوح درک می کنیم که چگونه کار می کند. ما به راحتی آن را مقیاس می کنیم، اگر چنین نیازی ناگهانی ایجاد شد، می توانیم آن را اصلاح کنیم. مشترک خدمات کامل تری دریافت می کند و از طرف ما کنترل XNUMX% بر روند.

به همین دلیل راه دوم را انتخاب کردیم. ما یک سال از عمر توسعه دهندگان و مهندسان میدان خود را در آن سرمایه گذاری کردیم. اما اکنون ما به وضوح عملکرد کل زنجیره را درک می کنیم.

با نگاهی به گذشته، می فهمم که بدون دانش به دست آمده، نمی توانستم رفتار غیرعادی یک شمارنده خاص را به درستی تفسیر کنم.

علاوه بر این، چیز دیگری را می توان بر اساس سیستم اعزام ساخت. آلارم مصرف مازاد گزارش تصادف. ما در حال آماده شدن برای انتشار یک اپلیکیشن موبایل به زودی هستیم.

ما حتی فراتر رفتیم و به پلتفرم خود (راه دیگری برای نامیدن آن وجود ندارد) توانایی دریافت درخواست‌های ساکنان، توانایی کنترل "اینترکام هوشمند"، کنترل روشنایی خیابان و چندین پروژه دیگر را اضافه کردیم که من ننوشته‌ام. در مورد هنوز

یادداشت های ارائه دهنده اینترنت اشیا. مشکلات نقشه برداری کنتورهای مسکن و خدمات عمومی

همه اینها سخت، مغز شکن و وقت گیر است. اما نتیجه ارزشش را دارد. مشترکین یک محصول آماده و جامع دریافت می کنند.

هر اپراتوری که قصد ورود به بخش مسکن و خدمات عمومی را داشته باشد، قطعا این مسیر را طی خواهد کرد. آیا می گذرد؟
اینجا یک سوال است. حتی بحث پول هم نیست همانطور که در بالا نوشتم، آنچه در اینجا لازم است ترکیبی از کار میدانی و توسعه است. همه بازیگران اصلی به این کار عادت ندارند. اگر توسعه دهندگان شما در مسکو هستند و اتصالات در نووسیبیرسک انجام می شود، زمان شما برای محصول نهایی به طور قابل توجهی افزایش می یابد.

زمان نشان خواهد داد که چه کسی در این بازار بماند و چه کسی بگوید - خوب، برو به جهنم! اما یک چیزی که من با اطمینان می دانم این است که شما نمی توانید بیایید و سهم بازار را تنها با پول بدست آورید. این فرآیند مستلزم رویکردهای غیر متعارف، مهندسان خوب، بررسی رگولاتورها، ارتباط با افسران منابع و مشترکین، شناسایی و غلبه بر مشکلات دائمی است.

PS در این مقاله من عمداً روی گرما تمرکز کرده ام و به برق یا آب اشاره نکرده ام. اتصال کابل را هم توضیح می دهم. اگر خروجی پالس داشته باشیم، نکات ظریفی وجود دارد، مانند بررسی های اجباری پس از نصب. ممکن است به سیم دسترسی نداشته باشد، سپس LoRaWAN وارد بازی می شود. توصیف کل پلتفرم ما و مراحل توسعه آن در یک مقاله به سادگی غیر واقعی است.

منبع: www.habr.com

اضافه کردن نظر