Trazemos à sua atenção um artigo de Vladislav Zaitsev ( vvzvlad ), um convidado do nosso blog. Vladislav há muito tempo se dedica ao tópico “casas inteligentes” e, resumindo sua experiência, ele oferece os seguintes princípios básicos para o design de tais sistemas.Hoje, quero falar com você sobre casas inteligentes em particular e dispositivos de IoT em geral. Mas este não será um artigo comum: não haverá glândulas, links para fabricantes, partes de código e repositórios no github. Hoje discutiremos algo de nível superior - os
princípios pelos quais os sistemas "inteligentes" são organizados.
Ao continuar a ler o artigo, você concorda que está satisfeito com o seguinte aviso.
Na verdade, exoneração de responsabilidade- Todos esses pontos dizem respeito apenas aos sistemas de IoT dos consumidores (leia-se “casas inteligentes”). Aqueles que uma pessoa pode comprar na loja e instalar sem o envolvimento de instaladores / integradores especializados.
- Alguns desses princípios não são aplicáveis a sistemas industriais (existem requisitos e princípios próprios), bem como a sistemas em que existem operadores separados do usuário (por exemplo, uma casa inteligente que é instalada e mantida por pessoas especialmente treinadas).
Além disso, alguns dos princípios não são aplicáveis a sistemas de brinquedo por nerd, sistemas caseiros e de código aberto que não possuem um único proprietário de produto. - E, claro, tudo o que está escrito abaixo é apenas minha opinião, com base em meus muitos anos de experiência. Você tem o direito de discordar dele.
Uma casa inteligente é um sistema que assume parte das preocupações diárias de uma pessoa. A partir daqui segue o primeiro e mais básico princípio:
1. Uma casa inteligente deve facilitar e facilitar a vida.
Uma casa inteligente é um sistema para a vida, não um brinquedo para geeks. Qualquer sistema que seja mais difícil de usar
1 do que os comutadores convencionais não é uma casa inteligente.
Qualquer novo produto deve ser testado quanto à conformidade com este princípio. Se isso não facilitar a vida e você não entender como facilitar, ela não pertence a uma casa inteligente. Você pode tentar imaginá-lo como um sistema de aprendizado.
O segundo princípio mais importante diz respeito à maneira como o usuário interage com o sistema:
2. Uma boa experiência do usuário é mais importante que a funcionalidade.
O Worthless é uma ferramenta interessante que não pode ser usada normalmente. Dispositivos convenientes e confiáveis com funcionalidade limitada têm mais probabilidade de obter sucesso do que produtos sofisticados para "todas as ocasiões".
2.1 Interfaces convenientes são melhores que personalização.
Não entende como salvar várias funções e uma interface simples? Você empurra todas as funções em uma fila na esperança de que o usuário descubra o que ele precisa? Saia da profissão!
Não entende como combinar conveniência e várias configurações? Doe as configurações. Qualquer funcionalidade será mais interessante do que um comutador normal, mas a complexidade excessiva forçará facilmente o usuário a retornar ao comutador.
O mesmo se aplica à qualidade do trabalho. Um botão que simplesmente acende a luz é melhor do que um controle deslizante de ajuste de brilho, que às vezes falha:
2.2 A qualidade das funções implementadas é mais importante que a sua quantidade.
Um pouco confiável, mas a funcionalidade comprovada é melhor do que muita coisa, mas funciona de alguma forma.
Um dos mecanismos fixados na psique humana pela evolução é uma reação mais ativa a estímulos negativos. Fatores negativos são mais importantes que positivos: pular a abordagem de um predador perigoso é muito pior do que não perceber e não comer uma fruta deliciosa em uma árvore. Se o seu sistema não tem nenhuma função, não é assustador, é apenas a ausência de um incentivo positivo. Mas a função existente, mas funciona mal, é um incentivo negativo: é lembrada com mais facilidade e por mais tempo.
2.3 A implementação do sistema não deve reduzir a velocidade normal do trabalho.
Atrasos são inaceitáveis, pois degradam a experiência do usuário. Este também é um incentivo negativo. Se uma pessoa não notar um atraso
2 entre o clique de um comutador convencional e a inclusão da luz, ela não deve notá-lo no seu sistema.
O ferro moderno trabalha a uma velocidade muito alta. Não há problema em atingir frequências de dezenas de megahertz em microcontroladores e pelo menos dezenas de kilobits por segundo, mesmo no ar. Se você não conseguir criar um sistema nessas condições, o usuário não sentirá nenhum atraso em sua operação, saia da profissão!
2.4 O sistema não deve quebrar os hábitos já formados do usuário.
Seu sistema é apenas um pequeno pedaço da vida humana. O tempo de vida de uma pessoa excede a vida do sistema, na melhor das hipóteses, algumas vezes e, na pior das hipóteses, em uma ordem de magnitude. Seu sistema sairá como vai e a vida humana continuará. E nesta vida, uma pessoa formou hábitos em relação ao brilho preferido da luz, à localização dos interruptores, como é conveniente para ele acender a luz e controlar o clima em casa.
Você não pode mudar com força esses hábitos. É possível oferecer. Forçar - é impossível.
Você não pode dizer ao usuário "agora acenderá a luz do telefone - é elegante, moderno, jovem". Isso é uma violação deste princípio e de vários outros.
Então o que fazer?
2.5 O sistema deve trazer uma nova experiência e não tentar substituir a antiga.
Se você acha que sua maneira de gerenciar sistemas em casa é melhor que a antiga, ofereça-a ao usuário. Se for realmente mais conveniente, ele escolherá um novo (sim, métodos diferentes se adequam a pessoas diferentes). Tudo o que você pode (e deve) fazer é lhe dar uma escolha.
Um lugar importante em uma casa inteligente é ocupado pela lógica do trabalho. O que determina por quais regras essa casa inteligente funcionará. E o seguinte princípio importante é exatamente isso:
3. O usuário não pode estar limitado na lógica acessível a ele.
Se o usuário quiser ligar a chaleira
3 quando a temperatura subir na sala, dê a ele a oportunidade de fazer isso. Uma situação deve ser excluída quando não houver limitações físicas ou de software para executar uma determinada ação, mas ela não estiver disponível, porque o desenvolvedor pensou "ninguém nunca precisará disso".
3.1 Tão simples quanto possível: a lógica de escrita não deve exigir conhecimentos especiais sobre o dispositivo do sistema
Se você possui dispositivos de versões diferentes com protocolos diferentes, verifique se o usuário sabe sobre isso apenas nos casos realmente necessários, quando você não pode ficar sem ele. Se você pode salvar o usuário de obter conhecimentos especiais, ainda que ao custo do tempo dos desenvolvedores, faça-o. O desenvolvedor passará dois dias e mil usuários por hora. Quarenta e oito horas versus mil? A resposta é óbvia.
Como você dorme, John é um programador serial?
3.2 Dispositivos com as mesmas funções devem ser controlados igualmente.
O usuário não precisa saber que a válvula de água é controlada por alguns comandos e a torneira por outros. Se os dois controlam a água no tubo, devem ter a mesma interface do usuário: “águas abertas” e “águas próximas”.
Todos vivemos no mundo físico. O corpo humano e o cérebro são formados para interagir com objetos físicos. Daí o princípio:
4. Os dispositivos de controle físico são melhores que os virtuais.
Qualquer um, mesmo os melhores aplicativos do telefone com botões de controle virtual perdem para o comutador físico usual no lugar certo.
Outra coisa é que o switch deve estar localizado no
lugar certo . Daí outra regra importante:
5. O rádio é melhor que os fios.
Os sistemas com fio são confiáveis, mas apenas a comunicação via rádio permite instalar um novo comutador ou relé para a lâmpada sem precisar repará-la novamente. E transfira, se você está entediado com o lugar anterior. Mas este princípio tem suas exceções:
5.1 Rádio ruim é pior que fios.
Um bom rádio é aquele que permite que você não pense a que distância do controlador central os dispositivos devem ser colocados. Um bom rádio são os protocolos de
rede mesh : ZigBee, Z-Wave, 6LoWPAN e assim por diante.
Todas as outras opções são ruins de rádio. Wi-fi é um rádio ruim. Protocolos caseiros de empresas individuais (eles são conhecidos pelo self-made sob o nome "433 MHz", embora possam estar em outras frequências e muito diferentes entre si) - rádio ruim.
O Wi-Fi é ruim porque é impossível criar dispositivos "adormecidos" completos e é difícil fazer a configuração automática, além de problemas de compatibilidade com outros dispositivos Wi-Fi em casa. Protocolos simples feitos em casa são ruins porque geralmente não contêm controle de entrega, criptografia ou especificações disponíveis. Nenhum deles possui roteamento de malha, o que geralmente resulta em problemas como "mas não consigo colocar um interruptor naquele canto - muito longe do transmissor".
É impossível criar um sistema com confiabilidade absoluta e sem a necessidade de manutenção. Os dispositivos quebram, surtos de energia ocorrem na rede, a água escorre do apartamento dos vizinhos, as pilhas acabam, rachaduras plásticas, a criança derrama sopa na lâmpada e assim por diante. Mas:
6. Reparo, atualização, manutenção e diagnóstico devem ser simples.
Tudo é claro no B2B: existe um usuário, um desenvolvedor e um operador - uma pessoa ou organização que sabe como o sistema funciona e pode trabalhar com ele em nível profissional. Ninguém requer um conhecimento de contador de programação sob 1C, esta é uma pessoa especial. E ninguém exige que uma pessoa que aluga um escritório entenda como a ventilação funciona nele - seu trabalho é dizer: "É abafado em nosso escritório".
Uma decisão competente para comprar um sistema baseia-se no cálculo do custo total de propriedade, que é a soma do preço do sistema e o custo de sua operação.
Nos sistemas que uma pessoa usa em casa, tudo é mais complicado. Lá, o operador e o usuário são a mesma pessoa e, além disso, muitas vezes não possuem o conhecimento necessário sobre o sistema. Infelizmente, essas são as limitações do mercado consumidor. Daí os seguintes princípios:
6.1 O dispositivo deve funcionar ou não funcionar. Não há terceiro.
A probabilidade de trabalho, trabalho parcial e trabalho incorreto não são permitidos. Você não deve permitir situações nas quais o dispositivo funcione sempre ou não uma vez em cada dez. Se você acha que seu dispositivo está com defeito, desligue-o completamente - por segurança e para manter uma experiência positiva do usuário. A substituição do dispositivo é desagradável, mas é melhor forçar o usuário a substituí-lo do que formar uma opinião "funciona uma vez" sobre o sistema. O sistema deve estar em um estado estritamente definido: se quebrar, não funcionará, se não quebrar, funcionará.
Se você estiver firmemente convencido de que a degradação da funcionalidade é aceitável, você ainda deve avisar o usuário com uma mensagem clara: “Foi detectada uma falha no segundo canal dimmer. É necessário substituir o redutor. Continuar a usar o primeiro canal dimmer? Sim / não
6.2 Substituir um dispositivo quebrado deve ser fácil.
O sistema deve ser modular. Se o usuário quebrar o sensor, ele só precisará substituí-lo. Você não pode exigir a troca do relé com o painel de controle, porque, você vê, ele está anexado a ele na fase de produção.
Você nem pode dizer "apenas nosso especialista pode instalar um novo sensor", porque obviamente, com o desenvolvimento do seu sistema, não haverá especialistas suficientes para milhões de usuários possíveis, o que significa que os problemas começarão em algum momento. Obviamente, o usuário não reparará o dispositivo, mas no caso de uma falha, ele poderá substituí-lo.
6.3 Limpar mensagens.
Se algo der errado, o usuário deve saber e saber exatamente o que deu errado.
É impossível dizer ao usuário “Erro nº 45”, o que implica que apenas o funcionário do suporte técnico entenderá esta mensagem. Ele precisa dizer: “O dispositivo não está respondendo. Tente reiniciá-lo, ligue novamente ou entre em contato com o serviço. Erro nº 45. "
É impossível detectar que o dispositivo não está respondendo (se você tiver a oportunidade de fazer isso) e não informar o usuário sobre isso. Não é muito agradável receber uma mensagem sobre problemas, mas é muito mais desagradável entender que o dispositivo não está funcionando há uma semana, no momento em que você precisava urgentemente.
6.4 Falta de informações desnecessárias nas mensagens.
Mas, ao mesmo tempo, você não precisa despejar despejos de depuração e logs de várias linhas no usuário. As informações são necessárias ao usuário, como no parágrafo anterior, porque incluem informações sobre o que exatamente deu errado ou não são necessárias se essas informações adicionais não estiverem claras, porque não são endereçadas a ele.
Não é necessário mostrar ao usuário cem mensagens do mesmo tipo: “a conexão com o dispositivo foi perdida”, “a comunicação com o dispositivo foi restaurada”. Decida finalmente: esse é um problema crítico e você precisa denunciá-lo da maneira correta - “Comunicação instável com o dispositivo” ou, como ele acabou sendo restaurado, não é uma informação importante e não é necessário mostrá-lo
4 .
6.5 A manutenção não requer conhecimentos e equipamentos especiais.
Dê ao usuário a oportunidade de atualizar o firmware - deixe que ele seja atualizado simplesmente pressionando alguns botões. E isso será feito através da interface padrão (USB / BT / Wi-Fi), ou não mencione na documentação do usuário sobre a atualização do firmware usando o programador SPI em geral.
Você não pode exigir que o usuário calcule máscaras de bits para uma configuração de dispositivo se essa configuração for necessária no uso normal.
6.6 O sistema não deve exigir manutenção contínua.
Se uma vez por mês um link voa na unidade executiva e o usuário precisa subir no lustre e amarrá-lo novamente, esse é um sistema ruim. Se o interruptor precisar trocar as baterias a cada dois meses - esse é um sistema ruim. Até o período médio de manutenção de seis meses para cada dispositivo é ruim: para vinte dispositivos em casa, o usuário precisará executar algumas ações em média a cada nove dias.
6.7 O sistema deve ter a capacidade de atualizar ou expandir.
O custo da expansão do sistema deve crescer linearmente. Um novo bloco deve custar o custo de um novo bloco.
Não deve haver uma situação em que você precise comprar um novo controlador para adicionar um novo sensor, porque o antigo não suporta mais de seis sensores
5 .
Não deve haver uma situação em que um novo firmware do sensor possa funcionar apenas com uma nova versão da unidade de controle.
Tais restrições têm um efeito positivo nos lucros, forçando os usuários a comprar novos dispositivos, mas este é o caminho para o inferno - perdendo a confiança do usuário devido a esses truques, você perderá muito mais do que poderia ganhar.
7. Auto-suficiência: redes externas são uma opção, não uma necessidade.
Um sistema no qual as equipes passam apenas por um servidor externo é um sistema ruim. Você pode se gabar de interfaces convenientes, aplicativos modernos e redes neurais legais o quanto quiser, mas não importa se o usuário, juntamente com a queda da Internet, perdeu a capacidade de acender a luz no banheiro. Desenvolvedor, você realmente acha que esse sistema é bom?
Mas, falando sério, eu realmente não entendo por que esse item não é uma questão de disciplina. Ao vincular o sistema a um servidor externo, você cria um ponto de falha com a confiabilidade de um servidor comum, mas ao mesmo tempo para todos os seus usuários. Serviços externos são legais, eles permitem expandir a funcionalidade, mas não devem ser a única opção para gerenciamento operacional. Um canal de controle adicional, armazenamento de backup, análise de dados - quantos você desejar.
8. Centralização: a falta de um hub central limita a lógica disponível.
No entanto, não se apresse para o outro extremo - tente tornar o sistema descentralizado e, portanto, absolutamente confiável.
Um sistema descentralizado é quando o interruptor diz "acender" a lâmpada e o sensor de temperatura liga o aquecedor quando a temperatura cai. Um sistema distribuído perde centralizado simplesmente porque esse sistema existe apenas dentro da estrutura do paradigma mais simples de interação do dispositivo - “o dispositivo controla outro dispositivo”. À medida que a complexidade do sistema aumenta, esse sistema levanta mais perguntas do que respostas. Se houver vários sensores de temperatura, o aquecedor deve aceitar comandos de todos? Ou ele próprio deveria interrogar os sensores? E se você precisar tomar uma decisão sobre inclusão com base na tendência, onde armazenar os dados do arquivo? Em cada aquecedor? Não é ousado? Em todo dispositivo? E direcionar tráfego com cada solicitação? E onde armazenar e como mudar a lógica? E se a lógica incluir elementos externos? E como armazenar lógica em dispositivos "estúpidos"? E como atualizá-lo?
Todos esses problemas desaparecem se você se reconciliar e reconhecer a necessidade de um hub central como um ponto de interação entre os dados e os locais de armazenamento para a lógica do usuário. Deixe todos os dispositivos serem "estúpidos", capazes de enviar dados e receber comandos, e a tarefa de armazenar dados de arquivo morto, processar esses dados, tomar decisões e interagir com serviços externos cairá sobre o controlador central.
A descentralização, a propósito, pode ser preservada, embora parcialmente: nada impede que você envie um comando diretamente, pois existe um modo à prova de falhas, na ausência de uma resposta do hub. Não haverá lógica, mas será possível acender a luz.
9. O sistema não deve executar ações potencialmente perigosas sem confirmação ou notificação ao usuário.
Enquanto não vivermos em um mundo onde o programador é responsável pelos danos causados por seu programa (bem escrito neste tópico
aqui ), haverá muitos erros nos programas. Eles estarão no software de uma casa inteligente. A única possibilidade em que esses erros não levarão a consequências desastrosas é a limitação das ações independentes do sistema. Ações potencialmente perigosas devem ser realizadas pelo menos com o conhecimento do usuário e, de preferência, com sua confirmação. Você pode acender a luz automaticamente: um bug no programa fará o usuário acordar à noite ou receber uma fatura por cem rublos extras no final do mês. Desagradável, mas dificilmente perigoso. Por exemplo, é impossível ligar a água automaticamente, se não houver mecanismos garantidos para desligá-la durante uma inundação. Mas desligue a água - você pode, porque essa não é uma ação perigosa.
Este princípio não afirma que é imperativo proibir o controle automático de todos os aquecedores, caldeiras, fogões, chaleiras e similares. Em vez disso, é sobre o fato de que, se você já está fabricando um dispositivo potencialmente perigoso com controle de software, verifique se o perigo não atinge o nível do usuário: a chaleira controlada deve ter circuitos "de ferro" que o desligam quando o superaquecimento; o banho, que é preenchido por si só, deve ter sensores de inundação; o ferro deve poder desligar, mas ligue-o novamente somente quando você pressionar o botão "ferro" e assim por diante.
10. O sistema deve poder se autocontrolar e diagnosticar.
Um verdadeiro desenvolvedor de sistemas inteligentes deve ser um pouco paranóico. Você não pode confiar na Internet, ela pode desaparecer. Você não pode confiar no código, pode haver erros nele. Talvez pelo menos o hardware possa ser confiável? Não. Você não pode confiar no seu hardware. O relé pode grudar, triativamente aberto espontaneamente, os fusíveis explodem. Por fim, o usuário pode conectar a chaleira de quilowatt a uma tomada de 100 watts. Precisa de sensores de tensão, corrente, temperatura. A temperatura está fora da faixa? Desligue tudo, envie um aviso. A corrente foi além - desligue-a. Eles desligaram o relé, mas ainda há tensão na saída? Observe. Ligado, mas não há voltagem? Observe!
11. O sistema deve poder ser controlado manualmente.
E mesmo com todas essas coisas paranóicas, ainda haverá uma situação em que as verificações falharam e algo quebrou. Ligue a sala, roteador, hub central. E o usuário quer acender a luz no banheiro. Qual é a conclusão?Sempre deve haver um botão que possa ser usado para fazer "pôr do sol manualmente". Que pode ligar ou desligar a luz IMEDIATAMENTE. Como eles trarão um novo hub amanhã, você poderá comprar um interruptor um pouco mais tarde e deseja desligar a luz da sala naquela noite para dormir em paz.12. Desenvolvedores e hackers são tão importantes quanto os usuários comuns.
Usuários comuns farão de você um caixa e hackers 6 - crie novos recursos. O fabricante não pode e não deve desenvolver todos os cenários para o uso do sistema, pois obviamente não possui conhecimento em todas as áreas e não pode avaliar o efeito do desenvolvimento dessas áreas. É possível que sua tomada controlada se torne insanamente conveniente para controlar o termostato do luar ainda, porque existe um controlador PID na biblioteca de soluções e agora todos os lombadores compram seus sistemas a granel. Um exemplo é um tanto artificial, mas a mensagem principal é que, à custa de alguns esforços, vale a pena criar um ambiente confortável para os hackers, porque eles adicionam uma força motriz ao seu sistema.13. Abertura: o sistema deve ter uma API para integração com outros sistemas.
Você não pode atender a todas as necessidades de seus clientes com seus dispositivos. Sempre haverá dispositivos que você não possui, mas outros fabricantes possuem. Ou você tem, mas outros fabricantes são melhores. Ou você será o fabricante cuja única unidade é a melhor. É necessária uma API aberta e bem documentada para conectar seu sistema a outras pessoas. Se você não possui uma API, está negando aos usuários a capacidade de construir sistemas heterogêneos. Mesmo as empresas, os mais fervorosos defensores de hardware e software proprietários, não podem pagar por isso.14. Documentação: a documentação é parte tão importante do sistema quanto código e hardware.
Qualquer hardware legal que você tenha e qualquer software legal que você escreva, não importará se o usuário não entender como iniciar o sistema e como trabalhar com ele. Uma boa documentação é aquela ao trabalhar com o qual o usuário nem sequer pensa em entrar em contato com o suporte ou avaliar negativamente as capacidades mentais do desenvolvedor. Escrever essa documentação é quase impossível, mas devemos nos esforçar para isso.E, finalmente, o último princípio (mas longe do último em termos de importância):15. Auto-suficiência e auto-sustentabilidade: o sistema deve continuar funcionando, mesmo que a empresa pare de funcionar
Uma pessoa vive de 70 a 90 anos, o sistema em sua casa é de 5 a 10 anos (na melhor das hipóteses), e as empresas geralmente são menores. Você não deve criar um sistema, a capacidade de trabalhar com a qual você arrasta consigo até o túmulo. Tenha pena dos usuários. Projete o sistema para que seja possível trabalhar com ele, mesmo que a empresa e os desenvolvedores tenham caído no esquecimento há muito tempo.A ligação de um novo dispositivo ocorre com o recebimento de um token do servidor do desenvolvedor? Faça o botão "Ignorar token de recebimento". Quando você liga o sistema pela primeira vez, você precisa atualizar o firmware a partir do site? Verifique se o firmware padrão está inundado quando o site não está disponível. E assim por diante
Neste artigo, tentei descrever toda a experiência de usar, trabalhar e projetar esses sistemas, compactados em 15 princípios básicos. Alguns deles podem parecer absurdos, outros podem ser controversos (e isso é normal) e outros podem ser banais (e isso também é normal).Mas se você pensar em pelo menos um deles, significa que o artigo não foi escrito em vão.Notas de rodapé e comentários
1. Quando digo "uso", não quero dizer o processo de configuração, mas o processo de interação normal com o sistema.2. Observe que não estou dizendo "o atraso deve ser o mesmo", mas "o usuário não deve perceber". A prática mostra que uma pessoa não percebe um atraso de até cerca de 300 ms.3. Talvez ele tenha crescido na Ásia Central e acredita que o melhor remédio para o calor é o chá verde quente.4. Obviamente, quando digo "não há necessidade de mostrar informações", isso significa que você não deve enviar uma mensagem ao usuário todas as vezes. Ele deve ser mostrado a pedido do usuário - clicando nos botões "show logs" ou "show debugging information". Os usuários não devem ser considerados idiotas, mas seu tempo deve ser respeitado.5. Obviamente, é impossível projetar um sistema que suporte um número infinito de dispositivos. Sempre haverá restrições, mas a tarefa do desenvolvedor é garantir que ele não atue em 99% dos casos. Um limite de seis sensores é inaceitável. Cento e duzentos dispositivos em uma rede é um número suficiente para a maioria dos usuários de residências inteligentes.6. Estou falando de hackers no significado original da palavra, de acordo com a RFC1983 , e não como hackers.