Uma taxonomia para o IIoT

Reis jogam xadrez em bancos de vidro fino. Alguém se lembra disso?

Para a maioria, isso provavelmente é um jargão. Mas não para mim. Este mnemônico me ajuda a lembrar a taxonomia da vida:Reino, Filo, Classe, Ordem, Família, Gênero, Espécie.

A amplitude, profundidade e variedade da vida na Terra são impressionantes. Uma taxonomia divide logicamente os tipos de sistemas por suas características. A Ciência da Biologia seria impossível sem uma boa taxonomia. Ele permite que os cientistas classifiquem plantas e animais em tipos lógicos, identifiquem pontos em comum e construam regras para compreender classes inteiras de sistemas vivos.

A amplitude, a profundidade e a variedade da Internet das Coisas Industrial (IIoT) também são impressionantes. A Ciência de Sistemas IIoT precisa de uma taxonomia organizada de tipos de aplicativos de forma semelhante. Só então podemos prosseguir com a discussão de arquiteturas e tecnologias apropriadas para implementar sistemas.

O primeiro problema é escolher as divisões de nível superior. No Reino Animal, você pode rotular a maioria dos animais como animais "terrestres, marítimos ou aéreos". No entanto, essas descrições ambientais não ajudam muito na compreensão do animal. A “arquitetura” de uma baleia não é muito parecida com um polvo, mas é muito parecida com um urso. Para ser compreendido, os animais devem ser divididos por suas características e arquitetura.

Também não é útil dividir os aplicativos por seus setores, como "médico, transporte e energia". Embora esses ambientes sejam importantes, as arquiteturas e tecnologias aplicáveis ​​simplesmente não se dividem entre as linhas da indústria. Mais uma vez, precisamos de uma compreensão mais profunda das características que definem os principais desafios, e esses desafios determinarão a arquitetura.

Eu percebo que esta é uma afirmação poderosa, até mesmo chocante. Isso implica, por exemplo, que os padrões, protocolos e arquiteturas sob medida em cada indústria não são maneiras úteis de projetar as arquiteturas futuras de sistemas IIoT . No entanto, é um fato claro dos sistemas em campo. Como na transformação que se tornou a Internet corporativa, as tecnologias genéricas substituirão as abordagens de propósito especial. Para aumentar nossa compreensão e cumprir a promessa da IIoT, devemos abandonar nosso antigo pensamento específico do setor.

Então, o que podemos usar para divisões? Quais características definidoras podemos usar para separar os mamíferos dos répteis dos insetos da IIoT?

Existem milhares e milhares de requisitos, funcionais e não funcionais, que podem ser usados. Como nos animais, precisamos encontrar aqueles poucos requisitos que dividem o espaço em categorias principais e úteis.

A tarefa é simplificada pela realização de que o objetivo é dividir o espaço para que possamos determinar a arquitetura do sistema . Assim, bons critérios de divisão são a) inequívocos eb) impactantes na arquitetura. Isso pode parecer fácil, mas na verdade não é nada trivial. A única maneira de fazer isso é por meio da experiência. Estamos no início de nossa busca. No entanto, um progresso significativo está ao nosso alcance.

Com base na vasta experiência da RTI com quase 1000 aplicativos IIoT do mundo real, sugiro algumas das primeiras divisões abaixo. Para ser o mais preciso possível, também escolhi “métricas” para cada divisão. As linhas, é claro, não são tão rígidas. Mas os números exigem clareza, e isso é crítico; sem parâmetros numéricos (bastões métricos?), o significado é freqüentemente perdido.

Proposta de taxonomia IIoT

Confiabilidade [Métrica:Disponibilidade contínua deve ser melhor que “99,999%”]

Não podemos ficar satisfeitos com o chavão "altamente confiável". Quase tudo “precisa” disso. Para ser significativo, devemos ser mais específicos sobre as demandas arquitetônicas para alcançar essa confiabilidade. Isso requer uma compreensão de quão rapidamente uma falha causa problemas e quão graves são esses problemas.

Descobrimos que a maneira mais simples e útil de categorizar a confiabilidade é perguntar:"Quais são as consequências de uma falha inesperada por 5 minutos por ano?" (Escolhemos 5 min / ano aqui apenas porque essa é a especificação de ouro “5-9s” para servidores de classe empresarial. Muitos sistemas industriais não podem tolerar nem mesmo alguns milissegundos de tempo de inatividade inesperado.)

Esta é uma característica importante porque tem um grande impacto na arquitetura do sistema. Um sistema que não pode falhar, mesmo por um curto período de tempo, deve suportar computação redundante, sensores, rede e muito mais. Quando a confiabilidade é realmente crítica, ela rapidamente se torna um - ou talvez o - principal motivador da arquitetura.

Tempo real [Métrica:Resposta <100ms]

Existem milhares de maneiras de caracterizar “tempo real”. Todos os sistemas devem ser “rápidos”. Mas para ser útil, devemos entender especificamente quais requisitos de velocidade impulsionam a arquitetura.

Uma arquitetura que pode satisfazer um usuário humano que não quer esperar mais de 8 segundos por um site nunca irá satisfazer um controle industrial que deve responder em 2ms. Descobrimos que o “joelho na curva” que tem grande impacto no design ocorre quando a velocidade de resposta é medida em algumas dezenas de milissegundos (ms) ou mesmo microssegundos (µs). Escolheremos 100ms simplesmente porque se trata do jitter potencial (latência máxima) imposto por um servidor ou corretor no caminho de dados. Sistemas que respondem muito mais rápido do que isso geralmente devem ser ponto a ponto, e isso é um grande impacto arquitetônico.

Escala do conjunto de dados [métrica:tamanho do conjunto de dados> 10.000 itens]

Novamente, existem milhares de dimensões a serem escaladas, incluindo número de “nós”, número de aplicativos, número de itens de dados e muito mais. Não podemos dividir o espaço por todos esses parâmetros. Na prática, eles estão relacionados. Por exemplo, um sistema com muitos itens de dados provavelmente possui muitos nós.

Apesar do amplo espaço, descobrimos que duas questões simples se correlacionam com os requisitos arquitetônicos. O primeiro é o “tamanho do conjunto de dados” e o joelho na curva é de cerca de 10k itens. Quando os sistemas ficam tão grandes, não é mais prático enviar todas as atualizações de dados para todos os receptores possíveis. Portanto, o gerenciamento dos próprios dados se torna uma necessidade arquitetônica chave. Esses sistemas precisam de um design “centrado em dados” que modele explicitamente os dados, permitindo, assim, filtragem e entrega seletivas.

Escala de equipe ou aplicativo [Métrica:número de equipes ou aplicativos interagindo> 10]

O segundo parâmetro de escala que escolhemos é o número de equipes ou aplicativos desenvolvidos de forma independente no “projeto”, com um ponto de interrupção em torno de 10. Quando muitos grupos independentes de desenvolvedores criam aplicativos que devem interagir, o controle da interface de dados domina o desafio da interoperabilidade. Novamente, isso geralmente indica a necessidade de um design centrado em dados que modele e gerencie explicitamente essas interfaces.

Desafio de descoberta de dados do dispositivo [métrica:> 20 tipos de dispositivos com conjuntos de dados multivariável]

Alguns sistemas IIoT podem (ou mesmo devem) ser configurados e entendidos antes do tempo de execução. Isso não significa que todas as fontes e coletores de dados sejam conhecidos, mas apenas que essa configuração é relativamente estática.

No entanto, quando os sistemas IIoT integram racks e racks de máquinas ou dispositivos, eles geralmente devem ser configurados e entendidos durante a operação. Por exemplo, uma IHM de controlador de planta pode precisar descobrir as características do dispositivo de um dispositivo ou rack instalado para que o usuário possa escolher os dados a serem monitorados. A escolha de “20” dispositivos diferentes é arbitrária. O ponto:quando existem muitas configurações diferentes para os dispositivos em um rack, essa “introspecção” torna-se uma necessidade arquitetônica importante para evitar a ginástica manual. A maioria dos sistemas com essa característica tem mais de 20 tipos de dispositivos.

Foco de distribuição [métrica:espalhar> 10]

Definimos “fan out” como o número de destinatários de dados que devem ser informados na alteração de um único item de dados. Isso impacta a arquitetura porque muitos protocolos funcionam por meio de conexões 1:1 únicas. A maior parte do mundo corporativo funciona dessa maneira, geralmente com TCP, um protocolo de sessão 1:1. Os exemplos incluem conectar um navegador a um servidor da web, um aplicativo de telefone a um back-end ou um banco a uma operadora de cartão de crédito.

No entanto, os sistemas IIoT geralmente precisam distribuir informações para muitos outros destinos. Se um único item de dados deve ir para vários destinos, a arquitetura deve oferecer suporte a várias atualizações eficientes. Quando o fan-out excede 10 ou mais, torna-se impraticável fazer essa ramificação gerenciando um conjunto de conexões 1:1.

Foco de coleta [métrica:fluxo de dados unilateral com ventilador em> 100]

Os sistemas que são essencialmente restritos ao problema de coleta não compartilham dados significativos entre os dispositivos. Em vez disso, eles transmitem informações copiosas para serem armazenadas ou analisadas em servidores de nível superior ou na nuvem.

Isso tem um grande impacto arquitetônico. Os sistem

[1] [2] 下一页