Le presentamos un artículo de Vladislav Zaitsev ( vvzvlad ), un invitado invitado de nuestro blog. Vladislav ha estado involucrado durante mucho tiempo en el tema de "hogares inteligentes" y, resumiendo su experiencia, ofrece los siguientes principios básicos para el diseño de tales sistemas.Hoy quiero hablar con usted sobre hogares inteligentes en particular y dispositivos IoT en general. Pero este no será un artículo ordinario: no habrá glándulas, enlaces a fabricantes, piezas de código y repositorios en el github. Hoy discutiremos algo de nivel superior: los
principios por los cuales se organizan los sistemas "inteligentes".
Al continuar leyendo el artículo, acepta que está satisfecho con el siguiente descargo de responsabilidad.
Descargo de responsabilidad en sí mismo- Todos estos puntos se refieren solo a los sistemas de IoT del consumidor (léase "hogares inteligentes"). Aquellos que una persona puede comprar en la tienda e instalar sin la participación de instaladores / integradores especializados.
- Algunos de estos principios no son aplicables a los sistemas industriales (existen sus propios requisitos y principios), así como a los sistemas donde hay operadores separados del usuario (por ejemplo, un hogar inteligente que es instalado y mantenido por personas especialmente capacitadas).
Además, algunos de los principios no son aplicables a los sistemas de juguete para geek, los sistemas caseros y de código abierto que no tienen un único propietario del producto. - Y, por supuesto, todo lo escrito a continuación es únicamente mi opinión basada en mis muchos años de experiencia. Tienes derecho a estar en desacuerdo con él.
Una casa inteligente es un sistema que se hace cargo de parte de las preocupaciones diarias de una persona. A partir de aquí se sigue el primer y más básico principio:
1. Una casa inteligente debería hacer la vida más y más fácil.
Una casa inteligente es un sistema para la vida, no un juguete para geeks. Cualquier sistema que sea más difícil de usar
1 que los conmutadores convencionales no es un hogar inteligente.
Cualquier producto nuevo debe ser probado para cumplir con este principio. Si no facilita la vida y no comprende cómo hacerlo, no pertenece a un hogar inteligente. Puedes intentar imaginarlo como un sistema de aprendizaje.
El segundo principio más importante se refiere a cómo interactúa el usuario con el sistema:
2. Una buena experiencia de usuario es más importante que la funcionalidad.
Sin valor es una herramienta genial que no se puede usar normalmente. Los dispositivos convenientes y confiables con funcionalidad limitada tienen más probabilidades de tener éxito que los productos complejos para "todas las ocasiones".
2.1. Las interfaces convenientes son mejores que la personalización.
¿No entiendo cómo guardar un montón de funciones y una interfaz simple? ¿Empujas todas las funciones seguidas con la esperanza de que el usuario descubra lo que necesita? ¡Sal de la profesión!
¿No entiendes cómo combinar la conveniencia y un montón de configuraciones? Done las configuraciones. Cualquier funcionalidad será más fría que un conmutador normal, pero una complejidad excesiva obligará fácilmente al usuario a volver al conmutador.
Lo mismo se aplica a la calidad del trabajo. Un botón que simplemente enciende la luz es mejor que un control deslizante de ajuste de brillo, que a veces falla:
2.2. La calidad de las funciones implementadas es más importante que su cantidad.
Una funcionalidad un poco confiable pero probada es mejor que mucho, pero funciona de alguna manera.
Uno de los mecanismos fijados en la psique humana por la evolución es una reacción más activa a los estímulos negativos. Los factores negativos son más importantes que los positivos: perder el enfoque de un depredador peligroso es mucho peor que no darse cuenta y no comer una fruta deliciosa en un árbol. Si su sistema no tiene ninguna función, no da miedo, es solo la ausencia de un incentivo positivo. Pero la función existente, pero funciona mal, es un incentivo negativo: se recuerda más fácilmente y se recuerda por más tiempo.
2.3. La implementación del sistema no debería reducir la velocidad habitual de trabajo.
Los retrasos son inaceptables ya que degradan la experiencia del usuario. Esto también es un incentivo negativo. Si una persona no nota un retraso
2 entre el clic de un interruptor convencional y la inclusión de la luz, no debería notarlo en su sistema.
El hierro moderno funciona a una velocidad muy alta. No hay problema para alcanzar frecuencias de decenas de megahercios en microcontroladores y al menos decenas de kilobits por segundo, incluso por aire. Si no puede crear un sistema en estas condiciones, el usuario no siente ningún retraso en su funcionamiento, ¡salga de la profesión!
2.4. El sistema no debe romper los hábitos ya formados del usuario.
Su sistema es solo una pequeña parte de la vida humana. El tiempo de vida de una persona excede la vida del sistema en el mejor de los casos un par de veces, y en el peor en un orden de magnitud. Su sistema se irá como lo hará, y la vida humana continuará. Y en esta vida, una persona ha formado hábitos con respecto al brillo preferido de la luz, la ubicación de los interruptores, cómo le conviene encender la luz y controlar el clima en el hogar.
No puedes cambiar a la fuerza estos hábitos. Es posible ofrecer. Para forzar, es imposible.
No puede decirle al usuario "ahora encenderá la luz del teléfono: es elegante, moderno y juvenil". Esto es una violación de este principio y varios otros.
Entonces que hacer?
2.5. El sistema debería traer una nueva experiencia, y no tratar de reemplazar la anterior.
Si cree que su forma de administrar los sistemas en el hogar es mejor que la anterior, ofrézcala al usuario. Si es realmente más conveniente, elegirá uno nuevo (sí, diferentes métodos se adaptan a diferentes personas). Todo lo que puedes (y debes) hacer es darle una opción.
Un lugar importante en una casa inteligente está ocupado por la lógica del trabajo. Lo que determina por qué reglas funcionará esta casa inteligente. Y el siguiente principio importante es solo sobre eso:
3. El usuario no puede estar limitado en la lógica accesible para él.
Si el usuario desea encender el hervidor
3 cuando la temperatura aumenta en la habitación, dele la oportunidad de hacerlo. Se debe excluir una situación cuando no hay restricciones físicas o de software para realizar una determinada acción, pero no está disponible, porque el desarrollador pensó que "nadie la necesitará".
3.1. Lo más simple posible: escribir lógica no debería requerir un conocimiento especial sobre el dispositivo del sistema
Si tiene dispositivos de diferentes versiones con diferentes protocolos, asegúrese de que el usuario lo sepa solo en casos realmente necesarios, cuando no pueda prescindir de él. Si puede evitar que el usuario obtenga conocimientos especiales, aunque a costa del tiempo de los desarrolladores, hágalo. El desarrollador pasará dos días y mil usuarios por hora. Cuarenta y ocho horas versus mil? La respuesta es obvia.
¿Cómo duermes, John es un programador en serie?
3.2. Los dispositivos con las mismas funciones deben controlarse por igual.
El usuario no tiene que saber que la válvula de agua está controlada por algunos comandos y el grifo por otros. Si ambos controlan el agua en la tubería, ambos deben tener la misma interfaz de usuario: "abrir agua" y "cerrar agua".
Todos vivimos en el mundo físico. El cuerpo humano y el cerebro están formados para interactuar con objetos físicos. De ahí el principio:
4. Los dispositivos de control físico son mejores que los virtuales.
Cualquiera, incluso las mejores aplicaciones en el teléfono con botones de control virtual pierden el interruptor físico habitual en el lugar correcto.
Otra cosa es que el interruptor debe estar ubicado en el
lugar correcto . De ahí otra regla importante:
5. La radio es mejor que los cables.
Los sistemas con cable son confiables, pero solo la comunicación por radio le permite instalar un nuevo interruptor o relé para la lámpara sin tener que repararla nuevamente. Y transfiérete, si estás aburrido del lugar anterior. Pero este principio tiene sus excepciones:
5.1. La mala radio es peor que los cables.
Una buena radio es aquella que le permite no pensar en qué tan lejos del controlador central deben colocarse los dispositivos. Una buena radio son los protocolos de
red de malla : ZigBee, Z-Wave, 6LoWPAN, etc.
Todas las demás opciones son malas radios. El wifi es una mala radio. Protocolos caseros de empresas individuales (se conocen por el hecho propio bajo el nombre de "433 MHz", aunque pueden estar en otras frecuencias y pueden ser muy diferentes entre sí) - radio defectuosa.
El Wi-Fi es malo porque es imposible hacer dispositivos "durmientes" completos en su base, y es difícil hacer una configuración automática, así como problemas de compatibilidad con otros dispositivos Wi-Fi en la casa. Los protocolos caseros simples son malos porque a menudo no contienen control de entrega, cifrado o especificaciones disponibles. Ninguno de los dos tiene una ruta de malla, que a menudo genera problemas como "pero no puedo poner un interruptor en esa esquina, demasiado lejos del transmisor".
Es imposible hacer un sistema con absoluta fiabilidad y sin necesidad de mantenimiento. Los dispositivos se rompen, se producen sobretensiones en la red, se vierte agua del apartamento de los vecinos, las baterías se agotan, las grietas de plástico, el niño vierte sopa sobre la lámpara, etc. Pero:
6. La reparación, actualización, mantenimiento y diagnóstico deben ser simples.
Todo está claro en B2B: hay un usuario, hay un desarrollador y hay un operador, una persona u organización que sabe cómo funciona el sistema y puede trabajar con él a nivel profesional. Nadie requiere un conocimiento contable de programación bajo 1C, esta es una persona especial. Y nadie requiere que una persona que alquila una oficina entienda cómo funciona la ventilación en ella; su trabajo es decir: "Está cargada en nuestra oficina".
Una decisión competente para comprar un sistema se basa en el cálculo del costo total de propiedad, que es la suma del precio del sistema y el costo de su operación.
En los sistemas que una persona usa en casa, todo es más complicado. Allí, el operador y el usuario son la misma persona y, además, a menudo no tienen los conocimientos necesarios sobre el sistema. Lamentablemente, estas son las limitaciones del mercado de consumo. De ahí los siguientes principios:
6.1. El dispositivo debería funcionar o no funcionar. No hay un tercero.
La probabilidad de trabajo, trabajo parcial y trabajo incorrecto no están permitidos. No debe permitir situaciones en las que su dispositivo funciona cada dos veces o no funciona una vez de cada diez. Si cree que su dispositivo no funciona correctamente, debe apagarlo por completo, por seguridad y para mantener una experiencia positiva del usuario. Reemplazar el dispositivo es desagradable, pero es mejor obligar al usuario a reemplazarlo que formarse una opinión "funciona una vez" sobre el sistema. El sistema debe estar en un estado estrictamente definido: si se descompone, entonces no funciona, si no se descompone, entonces funciona.
Si está firmemente convencido de que la degradación de la funcionalidad es aceptable, aún debe advertir al usuario con un mensaje claro: “Se ha detectado una falla en el segundo canal del atenuador. Es necesario reemplazar el atenuador. ¿Continuar usando el primer canal dimmer? Sí / no
6.2. Reemplazar un dispositivo roto debería ser fácil.
El sistema debe ser modular. Si el usuario rompe el sensor, solo debería reemplazar el sensor. No puede exigir cambiar el relé con el panel de control porque, como puede ver, está conectado a él en la etapa de producción.
Ni siquiera puede decir "solo nuestro especialista puede instalar un nuevo sensor", porque, obviamente, con el desarrollo de su sistema, no habrá suficientes especialistas para millones de posibles usuarios, lo que significa que los problemas comenzarán en algún momento. Por supuesto, el usuario no reparará el dispositivo él mismo, pero en caso de avería, debería poder reemplazarlos.
6.3. Mensajes claros
Si algo salió mal, el usuario debe saberlo y saber exactamente qué salió mal.
Es imposible decirle al usuario "Error # 45", lo que implica que solo el empleado de soporte técnico entenderá este mensaje. Necesita decir: “El dispositivo no responde. Intente reiniciarlo, vuelva a vincular o póngase en contacto con el servicio. Error # 45. "
Es imposible detectar que el dispositivo no responde (si tiene la oportunidad de hacerlo) y no decirle al usuario al respecto. No es muy agradable recibir un mensaje sobre problemas, pero es mucho más desagradable comprender que el dispositivo no ha estado funcionando durante una semana, en el mismo momento en que lo necesitaba con urgencia.
6.4. Falta de información innecesaria en los mensajes.
Pero al mismo tiempo, no es necesario volcar los volcados de depuración y los registros de varias líneas en el usuario. El usuario necesita información, como en el párrafo anterior, porque incluye información sobre qué salió mal exactamente, o no es necesaria si esta información adicional no es clara, porque no está dirigida a él.
No es necesario mostrar al usuario cien mensajes del mismo tipo: "se ha perdido la conexión con el dispositivo", "se ha restablecido la comunicación con el dispositivo". Decida finalmente: o bien este es un problema crítico, y debe informarlo de la manera correcta: “Comunicación inestable con el dispositivo” o, dado que resultó ser restaurado, esta no es información importante, y no necesita mostrarla
4 .
6.5. El mantenimiento no requiere conocimientos y equipos especiales.
Brinde al usuario la oportunidad de actualizar el firmware: deje que se actualice simplemente presionando un par de botones. Y esto se hará a través de la interfaz estándar (USB / BT / Wi-Fi), o no mencione en la documentación del usuario sobre la actualización del firmware utilizando el programador SPI en general.
No puede exigir al usuario que calcule máscaras de bits para una configuración de dispositivo si esta configuración se requiere en uso normal.
6.6. El sistema no debería requerir mantenimiento continuo.
Si una vez al mes un enlace vuela a la unidad ejecutiva, y el usuario necesita subir al candelabro y volver a atarlo, este es un mal sistema. Si el interruptor necesita cambiar las baterías una vez cada dos meses, este es un mal sistema. Incluso el período de mantenimiento promedio de seis meses para cada dispositivo es malo: para veinte dispositivos en la casa, el usuario tendrá que tomar algunas acciones en promedio cada nueve días.
6.7. El sistema debe tener la capacidad de actualizarse o expandirse.
El costo de expandir el sistema debería crecer linealmente. Un nuevo bloque debería costar el costo de un nuevo bloque.
No debería haber una situación en la que necesite comprar un nuevo controlador para agregar un nuevo sensor, ya que el antiguo no admite más de seis sensores
5 .
No debería haber una situación en la que un nuevo firmware del sensor solo pueda funcionar con una nueva versión de la unidad de control.
Dichas restricciones tienen un efecto positivo en las ganancias, obligando a los usuarios a comprar nuevos dispositivos, pero este es el camino al infierno: al perder la confianza del usuario debido a tales trucos, perderá mucho más de lo que podría ganar.
7. Autosuficiencia: las redes externas son una opción, no una necesidad.
Un sistema en el que los equipos solo pasan por un servidor externo es un sistema defectuoso. Puede presumir de interfaces convenientes, aplicaciones modernas y redes neuronales geniales tanto como desee, pero no importa si el usuario, junto con la caída de Internet, ha perdido la capacidad de encender la luz en el inodoro. Desarrollador, ¿realmente crees que un sistema así es bueno?
Pero en serio, no entiendo por qué este artículo no es algo natural. Al vincular el sistema a un servidor externo, crea un punto de falla con la confiabilidad de un servidor normal, pero al mismo tiempo para todos sus usuarios. Los servicios externos son geniales, le permiten ampliar la funcionalidad, pero no deberían ser la única opción para la gestión operativa. Un canal de control adicional, almacenamiento de respaldo, análisis de datos, tantos como desee.
8. Centralización: la falta de un centro central limita la lógica disponible.
Sin embargo, no se apresure al otro extremo: trate de hacer que el sistema esté descentralizado y, por lo tanto, sea absolutamente confiable.
Un sistema descentralizado es cuando el interruptor dice "encienda" la bombilla y el sensor de temperatura enciende el calentador cuando la temperatura baja. Un sistema distribuido pierde centralizado simplemente porque dicho sistema existe bien solo dentro del marco del paradigma de interacción de dispositivo más simple: "el dispositivo controla a otro dispositivo". A medida que aumenta la complejidad del sistema, dicho sistema plantea más preguntas que respuestas. Si hay varios sensores de temperatura, ¿debería el calentador aceptar los comandos de todos? ¿O debería él mismo interrogar a los sensores? Y si necesita tomar una decisión sobre la inclusión en función de la tendencia, ¿dónde almacenar los datos del archivo? En cada calentador? ¿No es audaz? En cada dispositivo? ¿Y generar tráfico con cada solicitud? ¿Y dónde almacenar y cómo cambiar la lógica? ¿Y si la lógica incluye elementos externos? ¿Y cómo almacenar la lógica en dispositivos "estúpidos"? ¿Y cómo actualizarlo?
Todos estos problemas desaparecen si se reconcilia y reconoce la necesidad de un concentrador central como punto de interacción entre los datos y las ubicaciones de almacenamiento para la lógica del usuario. Deje que todos los dispositivos sean "estúpidos", capaces de enviar datos y recibir comandos, y la tarea de almacenar datos de archivo, procesar estos datos, tomar decisiones e interactuar con servicios externos recaerá en el controlador central.
La descentralización, por cierto, se puede preservar, aunque sea parcialmente: nada le impide enviar un comando directamente, ya que hay un modo a prueba de fallas, en ausencia de una respuesta del concentrador. No habrá lógica, pero será posible encender la luz.
9. El sistema no debe realizar acciones potencialmente peligrosas sin confirmación o notificación al usuario.
Mientras no vivamos en un mundo donde el programador sea responsable del daño causado por su programa (bien escrito sobre este tema
aquí ), habrá muchos errores en los programas. Estarán en el software de una casa inteligente. La única posibilidad de que estos errores no conduzcan a consecuencias desastrosas es la limitación de las acciones independientes del sistema. Las acciones potencialmente peligrosas deben realizarse al menos con el conocimiento del usuario, y preferiblemente con su confirmación. Puede encender la luz automáticamente: un error en el programa hará que el usuario se despierte por la noche o reciba una factura por cien rublos adicionales al final del mes. Desagradable, pero apenas peligroso. Por ejemplo, es imposible abrir el agua automáticamente si no hay mecanismos garantizados para apagarlo durante una inundación. Pero cierre el agua, puede hacerlo, porque esta no es una acción peligrosa.
Este principio no establece que es imperativo prohibir el control automático de todos los calentadores, calderas, estufas, calderas y similares. Más bien, se trata del hecho de que si ya está haciendo un dispositivo potencialmente peligroso con control de programa, asegúrese de que su peligro no llegue al nivel del usuario: el hervidor controlado debe tener circuitos "de hierro" que lo apaguen cuando se sobrecaliente; el baño, que se llena solo, debe tener sensores de inundación; la plancha debería poder apagarse, pero volver a encenderla solo cuando presione el botón "plancha", y así sucesivamente.
10. El sistema debería ser capaz de autocontrol y autodiagnóstico.
Un verdadero desarrollador de sistemas inteligentes debería ser un poco paranoico. No puedes confiar en Internet, puede desaparecer. No puede confiar en el código, puede haber errores en él. ¿Quizás al menos se puede confiar en el hardware? No No puedes confiar en tu hardware. El relé puede pegarse, los triacs se abren espontáneamente, los fusibles se apagan. Finalmente, el usuario puede enchufar el hervidor de kilovatios en un tomacorriente de 100 vatios. Necesita sensores de voltaje, corriente, temperatura. ¿Está la temperatura fuera de rango? Apague todo, envíe una advertencia. La corriente ha ido más allá: apáguela. Apagaron el relé, pero ¿hay voltaje en la salida? Aviso. Encendido, pero no hay voltaje? Aviso!
11. El sistema debe poder controlarse manualmente.
E incluso con todas estas cosas paranoicas, todavía habrá una situación en la que los controles fallaron y algo se rompió.
Interruptor en la sala, enrutador, concentrador central. Y el usuario quiere encender la luz del inodoro. ¿Cuál es la conclusión?Siempre debe haber un botón que se pueda utilizar para hacer que "la puesta de sol sea el sol manualmente". Que puede encender o apagar la luz INMEDIATAMENTE. Debido a que traerán un nuevo centro mañana, puede comprar un interruptor un poco más tarde y desea apagar la luz de la habitación esa noche para dormir tranquilo.12. Los desarrolladores y hackers son tan importantes como los usuarios comunes.
Los usuarios comunes lo convertirán en cajero y piratas informáticos 6 - presenta nuevas características. El fabricante no puede y no debe desarrollar todos los escenarios para usar el sistema, ya que obviamente no tiene conocimiento en todas las áreas y no puede evaluar el efecto del desarrollo de dichas áreas. Es posible que su toma de corriente controlada resulte increíblemente conveniente para controlar el termostato de la luz de la luna todavía, porque hay un regulador PID en la biblioteca de soluciones, y ahora todas las gafas de luna compran sus sistemas en masa. Un ejemplo es un tanto artificial, pero el mensaje principal es que, a costa de algunos esfuerzos, vale la pena crear un entorno cómodo para los piratas informáticos, ya que agregan una fuerza impulsora a su sistema.13. Apertura: el sistema debe tener una API para la integración con otros sistemas.
No puede cubrir todas las necesidades de sus clientes con sus dispositivos. Siempre habrá dispositivos que no tenga, pero otros fabricantes sí. O lo tienes, pero otros fabricantes son mejores. O serás el fabricante cuya unidad individual es la mejor. Se requiere una API abierta y bien documentada para conectar su sistema a otros. Si no tiene una API, está negando a los usuarios la capacidad de construir sistemas heterogéneos. Incluso las empresas, los partidarios más fervientes de hardware y software patentado, no pueden permitirse esto.14. Documentación: la documentación es una parte tan importante del sistema como el código y el hardware.
Independientemente del hardware que tenga y del software que escriba, no importará si el usuario no descubre cómo iniciar su sistema y cómo trabajar con él. Una buena documentación es aquella cuando se trabaja con la cual el usuario ni siquiera piensa en ponerse en contacto con el soporte o evaluar negativamente las capacidades mentales del desarrollador. Escribir tal documentación es casi imposible, pero debemos esforzarnos por esto.Y finalmente, el último principio (pero lejos del último en términos de importancia):15. Autosuficiencia y autosostenibilidad: el sistema debe seguir funcionando, incluso si la empresa deja de funcionar
Una persona vive entre 70 y 90 años, el sistema en su hogar es de 5 a 10 años (en el mejor de los casos), y las empresas suelen ser más pequeñas. No debe hacer un sistema, la capacidad de trabajar con el que arrastra con usted a la tumba. Lástima los usuarios. Diseñe el sistema para que sea posible trabajar con él, incluso si la compañía y los desarrolladores se han hundido en el olvido hace mucho tiempo.¿El enlace de un nuevo dispositivo ocurre con la recepción de un token del servidor del desarrollador? Haga el botón "Omitir token de recepción". Cuando enciende el sistema por primera vez, ¿necesita actualizar el firmware desde el sitio? Asegúrese de que el firmware predeterminado esté inundado cuando el sitio no esté disponible. Y así sucesivamente.
En este artículo intenté describir toda la experiencia de usar, trabajar y diseñar tales sistemas, comprimidos en 15 principios básicos. Algunos de ellos pueden parecer exagerados, algunos pueden ser controvertidos (y esto es normal), y algunos pueden ser triviales (y esto también es normal).Pero si piensa en al menos uno de ellos, significa que el artículo fue escrito no en vano.Notas al pie y comentarios
1. Cuando digo "usar", no me refiero al proceso de configuración, sino al proceso de interacción normal con el sistema.2. Tenga en cuenta que no estoy diciendo "la demora debería ser la misma", sino "el usuario no debería darse cuenta". La práctica muestra que una persona no nota un retraso de hasta unos 300 ms.3. Quizás creció en Asia Central y cree que el mejor remedio para el calor es el té verde caliente.4. Por supuesto, cuando digo "no es necesario mostrar información", esto significa que no debe enviar un mensaje al usuario al respecto cada vez. Debería mostrarse a petición del usuario haciendo clic en los botones "mostrar registros" o "mostrar información de depuración". Los usuarios no deben considerarse idiotas, pero su tiempo debe ser respetado.5. Por supuesto, es imposible diseñar un sistema que admita un número infinito de dispositivos. Siempre habrá restricciones, pero la tarea del desarrollador es garantizar que no desempeñen un papel en el 99% de los casos. Un límite de seis sensores es inaceptable. Ciento doscientos dispositivos en una red es un número suficiente para la mayoría de los usuarios de hogares inteligentes.6. Estoy hablando de hackers en el significado original de la palabra, de acuerdo con RFC1983 , y no como hackers.