Ola, queridos fans da Internet das Cousas. Neste artigo, gustaríame falar de novo sobre a vivenda e os servizos comunitarios e unha enquisa dos dispositivos de medición.
De cando en vez, o próximo gran xogador de telecomunicacións fala sobre o pronto que entrará neste mercado e esmagará a todos baixo el. Cada vez que escoito historias coma esta, penso: "Rapaces, moita sorte!"
Nin sequera sabes a onde vas.
Para que comprendas a magnitude do problema, contareiche brevemente unha pequena parte da nosa experiencia no desenvolvemento da plataforma Smart City. Esa parte dela que se encarga de despachar.
Idea xeral e primeiras dificultades
Se non falamos de dispositivos de medición individuais, senón dos que están en sotos, salas de caldeiras e empresas, a maioría deles agora están equipados cunha saída telemétrica. Menos veces pulsado, con máis frecuencia - RS-485/232 ou Ethernet. Como regra xeral, os dispositivos de medición máis útiles son os que contan a calor. En primeiro lugar, están dispostos a pagar polo seu envío.
Xa discutín en detalle as características de RS-485 no meu artigo. En resumo, esta é simplemente unha interface de transferencia de datos. Esencialmente, estes son os requisitos para os impulsos eléctricos e as liñas de comunicación. A descrición dos paquetes chega a un nivel superior, no estándar de transmisión de datos, que opera enriba do RS-485. E que tipo de estándar haberá déixalle ao fabricante. Moitas veces Modbus, pero non é necesario. Aínda que sexa Modbus, aínda pode estar algo modificado.
De feito, cada medidor necesita o seu propio script de levantamento, que pode "falar" con el e interrogalo. Isto significa que o sistema de envío é un conxunto de scripts para cada contador individual. A base de datos onde se almacena todo isto. E unha determinada interface de usuario na que pode xerar o informe que precisa.
Parece fácil. O demo, coma sempre, está nos detalles.
Imos comezar coa primeira parte.
Guións
Como escribilos? Ben, obviamente, compre un dispositivo de medición, retoque con el, aprenda a comunicarse con el e integreo nunha plataforma común.
Desafortunadamente, esta solución só cubrirá parte das nosas necesidades. Normalmente, un contador popular ten varias xeracións e o guión para cada xeración pode ser diferente. Ás veces un pouco, ás veces moito. Cando compras algo, obtén a última xeración. O subscritor probablemente teña algo máis antigo. Xa non se vende nas tendas. E o abonado non cambiará a unidade de medición.
De aí o primeiro problema. Escribir tales guións é unha combinación difícil de desenvolvedores de software e enxeñeiros "no terreo". Compramos a última xeración, escribimos algún modelo inicial e despois modificámolo en dispositivos reais. É imposible facelo nun laboratorio, só mentres se traballa con subscritores en directo.
Levounos moito tempo crear tal paquete. O algoritmo agora foi elaborado. Os modelos iniciais foron axustándose e complementando constantemente, dependendo do que atopamos na nosa práctica. Por suposto, o abonado foi avisado se de súpeto o seu contador resultaba un pouco "apagado". Cando aparece un dispositivo deste tipo, conéctase segundo o esquema estándar e o script da enquisa modifícase ao longo do camiño. Durante a integración, o abonado traballa de balde. Infórmanlle que actualmente vive en modo de proba. O proceso de integración en si é algo bastante imprevisible. Ás veces só precisa facer correccións mínimas. Pode haber un proceso complexo que implica ir ao sitio, palear literatura e superar sucesivamente o anciño.
A tarefa non é fácil, pero solucionable. O resultado é un guión de traballo. Canto maior sexa a biblioteca de guións, máis fácil é a vida.
Segundo problema.
Tarxetas de conexión tecnolóxica
Para que comprenda a complexidade deste traballo, vou poñer un exemplo. Tomemos o medidor de calor extremadamente popular VKT-7.
O nome en si non nos di nada. VKT-7 ten varias solucións revestidas de ferro. Que tipo de interface ten dentro?
Hai diferentes opcións. Pode haber un pin nun bloque DB-9 estándar (este é RS-232). Pode ser só un bloque de terminales con contactos RS-485. Quizais incluso unha tarxeta de rede con RJ-45 (neste caso ModBus está empaquetado en Ethernet).
Ou quizais nada de nada. Só un dispositivo de medición. Podes instalar unha saída de interface nel; o fabricante véndese por separado e custa diñeiro. O principal problema é que para instalalo é necesario abrir o contador e romper os selos. É dicir, a organización subministradora de recursos está incluída neste proceso. Infórmase de que se romperán os precintos, fíxase un día e o noso enxeñeiro, en presenza dun representante do recurso, fai as modificacións necesarias, despois de que o contador volve selar.
Dependendo da interface instalada, realízanse máis modificacións. Por exemplo, decidimos conectar o medidor por cable. Esta é a opción máis sinxela, se o noso interruptor está a menos de 100 metros, xogar con LoRa é redundante. É máis fácil conectar un cable á nosa rede, a unha VLAN illada.
Para RS-485/232 necesitas un conversor a Ethernet. Moitos lembrarán inmediatamente MOHA, pero é caro. Para as nosas solucións, seleccionamos unha solución chinesa máis barata.
Se a saída é directamente Ethernet, non é necesario un conversor.
Pregunta. Digamos que instalamos a saída da interface nós mesmos. Podes facilitar a túa vida e instalar Ethernet inmediatamente en todas partes?
Isto non sempre é posible. Temos que ver o deseño do corpo. É posible que non teña o burato necesario para que a interface encaixe correctamente. Permíteme recordarche que o mostrador está no noso soto. Ou na sala de caldeiras. Hai moita humidade alí, o selo non se pode romper. Rematar o corpo cun ficheiro é unha mala idea. É mellor instalar algo que inicialmente non requira grandes modificacións. Moitas veces RS-485 é a única saída.
Ademais. O contador está conectado a enerxía garantida? Se non, entón funciona con batería. Neste modo, está deseñado para a votación manual unha vez ao mes durante tres minutos. Acceder constantemente a VKT-7 esgotará a batería. Isto significa que ten que proporcionar enerxía garantida e instalar un conversor de tensión.
O módulo de potencia é diferente para cada fabricante de medidor. Esta pode ser unha unidade de carril DIN externa ou un conversor incorporado.
Resulta que o noso almacén debe almacenar sempre un conxunto de interfaces e módulos de potencia diferentes para cada contador. A gama alí é impresionante.
Por suposto, todo isto será finalmente pagado polo abonado. Pero non esperará un mes a que chegue o dispositivo axeitado. E precisa unha estimación para a conexión aquí e agora. Así que a reserva tecnolóxica recae sobre os nosos ombreiros.
Todo o que describín convértese nun mapa técnico de conexión claro, para que os enxeñeiros locais non pensen en que tipo de besta atoparon no seguinte soto e que necesitan para que funcione.
O mapa técnico está adxacente á normativa xeral de conexión. Despois de todo, non é suficiente con incluír o contador na nosa rede; aínda necesitamos conectar a mesma VLAN ao porto do switch, necesitamos realizar diagnósticos e facer unha enquisa de proba. Esforzámonos por automatizar todo o proceso na medida do posible para evitar erros e non implicar enxeñeiros innecesarios.
Vale, escribimos mapas técnicos, normativas, automatización. Establecemos a loxística.
Onde máis hai trampas ocultas?
Os datos son lidos e vertidos na base de datos.
Estes números fan que o abonado non teña nin calor nin frío. Necesita un informe. Preferentemente na forma na que estea afeito. Aínda é mellor se é inmediatamente en forma de informe que pode entender, que pode imprimir, asinar e enviar. Isto significa que necesitamos unha interface sinxela e comprensible que amose información sobre o contador e poida xerar automaticamente un informe.
Aquí continúa o noso zoolóxico. O caso é que hai varios formularios de informe. No seu núcleo, reflicten o mesmo (calor consumida), pero de diferentes xeitos.
Algúns abonados informan en valores absolutos (é dicir, na columna de consumo de calor, os valores escríbense a partir da instalación do contador), outros en deltas (é cando escribimos o consumo durante un período de tempo sen referencia a os valores iniciais). De feito, non utilizan estándares uniformes, senón prácticas establecidas. Houbo casos nos que os abonados ven todos os valores que necesitan (cantidade de calor consumida, volume de refrixerante subministrado e descargado, diferenza de temperatura), pero as columnas do informe non están na secuencia correcta.
De aí o seguinte paso: o informe debe ser personalizable. É dicir, o propio subscritor elixe o que vai en que secuencia e que recursos hai no seu documento.
Hai un punto interesante aquí. Todo está ben se o noso contador está instalado correctamente. Pero ocorre que a empresa instaladora, ao instalar o ITP, cometeu un erro e fixou incorrectamente a hora do contador. Atopámonos con dispositivos que pensan que é 2010. No noso sistema, isto parecerá lecturas cero para a data actual e consumo real se seleccionamos 2010. Os deltas son moi útiles aquí. É dicir, dicimos que sucederon moitas cousas nas últimas XNUMX horas.
Parece que, por que tales dificultades? É tan difícil darlle cuerda ao reloxo?
Exactamente con VKT-7 isto levará a un reinicio completo do contador e a eliminación dos arquivos del.
O abonado verase obrigado a demostrar aos axentes de recursos que instalou o ITP non onte, senón hai cinco anos.
E para rematar, a guinda do pastel.
certificado
Temos un contador e un informe. Entre eles está o noso sistema, que xera este informe. Cres nela?
Fago. Pero como podemos demostrar que nada cambia no noso interior, que non distorsionamos o significado. Isto xa é unha cuestión de certificación. O sistema de enquisas debe contar cun certificado que acredite a súa imparcialidade. Todos os grandes sistemas, como LERS, Ya Energetik e outros teñen un certificado similar. Tamén o recibimos, aínda que é caro e leva moito tempo.
Por suposto, sempre podes cortar unha esquina e mercar algo preparado. Pero o desenvolvedor terá que pagar por iso. E o programador pode pedir non só unha taxa de entrada, senón tamén unha taxa de subscrición. É dicir, verémonos obrigados a compartir con el parte da nosa empanada.
Por que é todo?
Este non é o principal problema. Desenvolver o teu propio sistema tamén é moi caro e moito máis difícil. Non obstante, proporciona unha vantaxe importante. Entendemos claramente como funciona. Escalámolo facilmente, podemos modificalo se de súpeto xorde esa necesidade. O abonado recibe un servizo máis completo e, pola nosa parte, un control ao XNUMX% sobre o proceso.
Por iso escollemos o segundo camiño. Investimos nel un ano da vida dos nosos desenvolvedores e enxeñeiros de campo. Pero agora entendemos claramente o funcionamento de toda a cadea.
Mirando cara atrás, entendo que sen os coñecementos adquiridos, simplemente non sería capaz de interpretar correctamente o comportamento anormal dun contador en particular.
Ademais, pódese construír algo máis sobre a base do sistema de despacho. Alarmas por exceso de consumo, informe de accidente. Estamos preparándonos para lanzar unha aplicación móbil en breve.
Fomos aínda máis alá e engadimos á nosa plataforma (non hai outra forma de chamalo) a posibilidade de recibir solicitudes dos veciños, a capacidade de controlar os nosos "intercomunicadores intelixentes", controlar a iluminación pública e varios outros proxectos que non escribín. sobre aínda.
Todo isto é difícil, rompe o cerebro e leva moito tempo. Pero o resultado paga a pena. Os subscritores reciben un produto completo e listo.
Todo operador que planea entrar no sector da vivenda e dos servizos comunitarios tomará definitivamente este camiño. Pasará?
Aquí tes unha pregunta. Nin sequera se trata dos cartos. Como escribín anteriormente, o que se necesita aquí é unha combinación de traballo de campo e desenvolvemento. Non todos os principais xogadores están afeitos a isto. Se os teus desenvolvedores están situados en Moscova e as conexións realízanse en Novosibirsk, o teu tempo para o produto acabado estendese significativamente.
O tempo dirá quen quedará neste mercado e quen dirá: ben, vai ao inferno! Pero unha cousa que sei con certeza é que non poderás vir tomar cota de mercado só con cartos. Este proceso require enfoques non convencionais, bos enxeñeiros, afondar nos reguladores, comunicarse con oficiais de recursos e subscritores, identificar e superar problemas constantemente.
PS Neste artigo centreime deliberadamente na calor e non mencionei a electricidade nin a auga. Tamén describo a conexión por cable. Se temos unha saída de pulso, hai algúns matices, como verificacións obrigatorias despois da instalación. Pode ser que non se poida alcanzar o cable, entón LoRaWAN entra en xogo. É simplemente pouco realista describir toda a nosa plataforma e as etapas do seu desenvolvemento nun artigo.
Fonte: www.habr.com