São Paulo Region Chapter

1 Introdução

Os objetivos da Web das Coisas (Web of Things, WoT) são melhorar a interoperabilidade e a usabilidade da Internet das Coisas (IoT). Mediante a colaboração que envolve muitos interessados, ao longo de vários anos, foram identificados diversos componentes que ajudam a enfrentar esses desafios.

Esta especificação é focalizada no escopo da padronização W3C WoT, que pode ser dividida em tais componentes, bem como na arquitetura abstrata que define como eles estão relacionados. Os componentes são definidos e descritos detalhadamente em especificações separadas. No entanto, além de definir a arquitetura abstrata, sua terminologia e seu quadro conceitual, essa especificação também serve de introdução aos componentes WoT e explica sua interação.

• A Web das Coisas (WoT) Thing Description [WOT-THING-DESCRIPTION] normalmente fornece um formato de dados legível por máquina para descrever os metadados e as interfaces de rede das Coisas. Baseia-se nos conceitos fundamentais introduzidos neste documento, tais como affordances de interação.
• Web das Coisas (WoT) Modelos de Ligação [WOT-BINDING-TEMPLATES] fornece diretrizes de informação sobre como definir interfaces de rede nas Coisas para protocolos particulares e ecossistemas de IoT, que são denominados Conexão de Protocolos (Protocol Bindings). O documento também fornece exemplos para uma série de ecossistemas e normas de IoT existentes.
• A API de Script da Web das Coisas (WoT) [WOT-SCRIPTING-API], que é opcional, permite a implementação da lógica de aplicativo de uma Coisa usando uma API JavaScript comum semelhante às APIs do navegador Web. Isso simplifica o desenvolvimento de aplicações IoT e permite a portabilidade entre fornecedores e dispositivos.
• O Web das Coisas (WoT) Diretrizes de Segurança e Privacidade (Security and Privacy Guidelines) [WOT-SECURITY] representa um componente transversal. Este documento informativo fornece diretrizes para a implementação e configuração segura das Coisas, bem como discute questões que devem ser consideradas em quaisquer sistemas que implementem o W3C WoT. No entanto deve-se enfatizar que a segurança e a privacidade só podem ser plenamente avaliadas no contexto de um conjunto completo de mecanismos concretos para uma implementação específica, que a arquitetura abstrata WoT não especifica totalmente. E isso é especialmente verdadeiro quando a arquitetura WoT é usada de modo descritivo para sistemas preexistentes, pois o W3C WoT não pode restringir o comportamento de tais sistemas, ele só pode descrevê-los. Neste documento também se discute sobre os riscos de privacidade e segurança e sua mitigação em alto nível na seção §12. Considerações de Segurança e Privacidade.

Esta especificação abrange, ainda, aspectos arquitetônicos não normativos e condições de implantação de sistemas WoT. As orientações são descritas no contexto de cenários de exemplos de implantação, embora não se defina normalmente implementações concretas e específicas.

Esta especificação cobre as especificações [LG1] W3C WoT e define os conceitos básicos como terminologia e a arquitetura abstrata subjacente da Web das Coisas W3C. Em resumo, o objetivo desta especificação é fornecer:

• um conjunto de domínios de aplicação no § 4. Domínios de Aplicação (Verticais) que foram considerados para identificar casos de uso para a Arquitetura W3C WoT;
• um conjunto de requisitos para implementações WoT no § 7. Requisitos;
• uma definição da arquitetura abstrata no § 8. Arquitetura Abstrata do Sistema WoT;
• um panorama do conjunto de componentes de WoT e sua interação no § 9. Componentes de WoT;
• uma orientação informativa sobre como mapear a arquitetura abstrata para possíveis implementações concretas no § 10. Arquitetura Serviente Abstrata;
• exemplos informativos de possíveis cenários de implantação no § 11. Exemplos de Aplicações de WoT;
• e uma discussão, em alto nível, de considerações de segurança e privacidade para tornar ciente ao implementar um sistema baseado na arquitetura W3C WoT no § 12. Considerações de Segurança e Privacidade.

Numa futura revisão deste documento serão abordados requisitos adicionais, casos de utilização, características conceituais e novos módulos.

2 Conformidade

Assim como as seções marcadas como não normativas, todas as diretrizes de autoria, diagramas, exemplos e notas, nesta especificação, são não normativas; todo o resto é normativo.

As palavras-chave PODE, DEVE, e DEVERIA, neste documento, devem ser interpretadas conforme descrito no BCP 14[RFC2119] [RFC8174] quando, e somente quando, aparecem em letras maiúsculas, como escritas aqui.

3 Terminologia

Esta seção não é normativa.

Esta especificação usa os seguintes termos, conforme definidos aqui. O prefixo WoT é usado para evitar ambiguidades para termos que são (re)definidos especificamente para conceitos de Web das Coisas.

Ação – Um Affordance de Interação que permite invocar uma função da Coisa, que manipula o estado (por exemplo, ativar ou desativar uma lâmpada) ou desencadeia um processo na Coisa (por exemplo, diminuir a intensidade de uma lâmpada ao longo do tempo).

Modelos de Ligação – Uma coleção reutilizável de modelos para a comunicação com diferentes plataformas IoT. Os modelos fornecem informações para mapear os Affordances de Interação para mensagens específicas da plataforma a partir da Descrição da Coisa WOT, bem como notas de implementação para as pilhas de protocolo necessárias ou drivers de comunicação dedicados.

Coisa Consumida – Uma abstração de software que representa uma Coisa remota usada pela aplicação local. A abstração pode ser criada por um WoT de tempo de execução nativo, ou instanciada como um objeto através da API de Script WoT.

Consumir uma Coisa – Para analisar e processar um documento TD e, a partir dele, criar uma abstração de software de Coisa Consumida como interface para a aplicação no ambiente de tempo de execução local.

Consumidor – Uma entidade capaz de processar Descrições de Coisas WoT (incluindo seu formato de representação baseado em JSON) e interagir com Coisas (ou seja, consumir Coisas).

Esquema de Dados – Um esquema de dados descreve o modelo de informação e a estrutura de carga útil relacionada e itens de dados correspondentes que são passados entre Coisas e Consumidores durante as interações.

Gêmeo Digital – Um gêmeo digital é uma representação virtual de um dispositivo ou de um grupo de dispositivos que reside em uma nuvem ou em um nó de borda. Ele pode ser usado para representar dispositivos do mundo real que podem não estar on-line constantemente ou para executar simulações de novas aplicações e serviços, antes de serem implantados nos dispositivos reais.

Vocabulário Específico do Domínio – Vocabulário de Dados Ligados que pode ser usado na descrição da Coisa WOT, mas não é definido pelo W3C WoT.

Dispositivo de Ponta – Um dispositivo que fornece um ponto de entrada nas redes de base da empresa ou do prestador de serviços. Exemplos incluem gateways, roteadores, comutadores, multiplexadores e uma variedade de outros dispositivos de acesso.

Evento – Um Affordance de Interação que descreve uma fonte de eventos, que leva dados de eventos para os Consumidores de forma assíncrona (por exemplo, alertas de superaquecimento).

Coisa Exposta – Uma abstração de software que representa uma Coisa hospedada localmente e que pode ser acessada através da rede por Consumidores remotos. A abstração pode ser criada por um WoT de tempo de execução nativo ou instanciada como um objeto pela API de Script WoT.

Expor uma Coisa – Para criar uma abstração de software de Coisa Exposta no ambiente local de tempo de execução visando gerenciar o estado de uma Coisa e fazer interface com a implementação de comportamento.

Controle de Hipermídia – A serialização de um Protocolo de Ligação em hipermídia, ou seja, um link Web [RFC8288] para navegação ou um formulário Web para realizar outras operações. Os formulários podem ser vistos como modelos de pedido fornecidos pela Coisa a serem preenchidos e enviados pelo Consumidor.

Affordance de Interação– Metadados de uma Coisa que exibe e descreve as possíveis escolhas para os Consumidores, sugerindo como os Consumidores podem interagir com a Coisa. Existem muitos tipos de affordances potenciais, mas o W3C WoT define três tipos de Affordances de Interação: Propriedades, Ações e Eventos. Um quarto Affordance de Interação é a navegação, que já está disponível na Web através de links.

Modelo de Interação – Uma abstração intermediária que formaliza e estreita o mapeamento da intenção da aplicação para operações de protocolo concreto. No W3C WoT, o conjunto definido de Affordances de Interação constitui o Modelo de Interação.

Intermediário – Uma entidade entre Consumidores e Coisas que podem servir de proxy, aumentar, ou compor Coisas e republicar uma Descrição de Coisa WoT que aponta para a Interface WoT no Intermediário, em vez da Coisa original. Para os Consumidores, um Intermediário pode ser indistinguível de uma Coisa, seguindo a restrição do Sistema em Camadas do REST (Representation State Transfer).

Plataforma IoT – Um ecossistema específico de IoT, como OCF, oneM2M, ou Coisas do Projeto Mozilla com suas próprias especificações para APIs direcionadas a aplicações, modelo de dados, protocolos ou configurações de protocolo.

Metadados – Dados que fornecem uma descrição das características abstratas de uma entidade. Por exemplo, uma Descrição de uma Coisa é Metadado para uma Coisa.

Informações de Identificação Pessoal (IIP) – Quaisquer informações que possam ser utilizadas para identificar a pessoa física a quem essas informações se refiram, ou que estejam ou possam estar direta ou indiretamente ligadas a uma pessoa física. Usa-se a mesma definição que [ISO-IEC-29100].

Privacidade – Liberdade de intrusão na vida ou nos assuntos privados de um indivíduo quando essa intrusão resultar de obtenção e utilização indevidas ou ilegais de dados sobre esse indivíduo. Usa-se a mesma definição que [ISO-IEC-2382]. Ver também Informações de Identificação Pessoal e Segurança, bem como outras definições conexas em [ISO-IEC-29100].

Dados Privados de Segurança – Dados Privados de Segurança é o componente de Configuração de Segurança de uma Coisa que é mantido em segredo e não é compartilhado com outros dispositivos ou usuários. Um exemplo seria o de chaves privadas em um sistema PKI. O ideal seria ter esses dados armazenados em uma memória separada e inacessível à aplicação, sendo esses dados usados só a partir de operações abstratas, como a assinatura, que não revelam a informação secreta até mesmo para a aplicação que a utiliza.

Propriedade – Um Affordance de Interação que expõe o estado da Coisa. Este estado pode então ser recuperado (lido) e atualizado opcionalmente (escrita). As Coisas também podem optar por tornar Propriedades observáveis, ativando o novo estado após uma mudança.

Ligação de Protocolo – O mapeamento a partir de um Affordance de Interação para mensagens concretas de um protocolo específico, assim, informando os Consumidores como ativar o Affordance de Interação. O W3C WoT serializa as Ligações de Protocolo como controles de hipermídia.

Metadados de Segurança Pública – Metadados de Segurança Pública são componentes da configuração de segurança de uma Coisa que descrevem os mecanismos de segurança e direitos de acesso necessários para acessar uma Coisa. Eles não incluem nenhuma informação secreta ou dados concretos (incluindo chaves públicas) e não fornecem, por si só, acesso à Coisa. Em vez disso, descrevem os mecanismos pelos quais o acesso pode ser obtido por usuários autorizados, incluindo como eles devem autenticar-se.

Segurança – Preservação da confidencialidade, integridade e disponibilidade da informação. Propriedades como autenticidade, responsabilidade, não repúdio e confiabilidade, também, podem estar envolvidas. Esta definição é adaptada a partir da definição de Segurança da Informação em [ISO-IEC-27000], que, ainda, inclui definições adicionais de cada uma das propriedades mais específicas mencionadas. Consulte este documento para outras definições relacionadas. Além disso, observa-se que é desejável que estas propriedades sejam mantidas tanto em funcionamento normal como quando o sistema está sujeito a ataque.

Configuração da Segurança – A combinação de metadados de Segurança Pública, dados de segurança privada e qualquer outra informação de configuração (como chaves públicas) é necessária para configurar operacionalmente os mecanismos de segurança de uma Coisa.

Serviente – Uma pilha de software que implementa os componentes WoT. Um serviente pode hospedar e expor Coisas e/ou hospedar Consumidores que consomem Coisas. Os servientes podem suportar múltiplas Ligações de Protocolo para permitir a interação com diferentes plataformas IoT.

Subprotocolo – Um mecanismo de extensão a um protocolo de transferência que deve ser conhecido para interagir com sucesso. Um exemplo é uma sondagem longa para HTTP.

TD – Abreviatura de Descrição da Coisa WoT.

Vocabulário TD – Um vocabulário controlado de dados interligados pelo W3C WoT para marcar os metadados de Things no WoT Thing Description, incluindo metadados de comunicação de Modelos de Ligação WoT.

Coisa ou Coisa Web – A abstração de uma entidade física ou virtual cujos metadados e interfaces são descritos por uma Descrição de Coisa WoT, enquanto uma entidade virtual é a composição de uma ou mais Coisas.

Diretório de Coisas – Um serviço de diretório para TDs que fornece uma interface Web para registrar TDs (semelhante a [CoRE-RD]) e pesquisá-los (por exemplo, usando consultas SPARQL ou a interface de pesquisa do CoRE RD [CoRE-RD]).

Modelo de Coisa – Um Modelo de Coisa é uma descrição para uma classe de Coisas que tem os mesmos recursos. Ele descreve Propriedades, Ações e Eventos e metadados comuns que são compartilhados para um grupo inteiro de Coisas. Comparado a uma Descrição de uma Coisa, um Modelo de Coisa não contém informações suficientes para identificar ou interagir com uma instância de Coisa.

Protocolo de Transferência – O protocolo de camada de aplicação subjacente, padronizado, sem requisitos específicos de aplicação ou restrições sobre opções ou mecanismos de subprotocolo. Exemplos são HTTP, CoAP ou MQTT.

Coisa Virtual – A instância de uma Coisa que representa uma Coisa [LG1] que está localizada em outro componente do sistema.

Interface WoT – A interface de rede de uma Coisa que é descrita por uma descrição de Coisa WoT.

Tempo de Execução WoT – Um sistema de tempo de execução que mantém um ambiente de execução para aplicações e é capaz de expor e/ou consumir Coisas, processar Descrições de Coisas WoT para manter Configurações de Segurança e fazer interface com implementações de Ligações de Protocolo. Um Tempo de Execução WoT pode ter uma API personalizada ou usar a API opcional de Script WoT.

API de Script WoT – A interface de programação voltada para aplicações fornecida por um Serviente a fim de facilitar a implementação de comportamento ou aplicações, executando em um Tempo de Execução WoT. É comparável às APIs do navegador Web. A API de Scrip WoT é um componente opcional para W3C WoT.

Serviente WoT – Sinônimo de Serviente.

Descrição WoT da Coisa ou Descrição da Coisa – Dados estruturados que descrevem uma Coisa. Uma descrição de Coisa WoT inclui metadados gerais, metadados específicos de domínio, Affordance de Interação (que incluem as Ligações de Protocolo suportadas) e links para Coisas relacionadas. O formato WoT de Descrição da Coisa é o componente central do W3C WoT.

NOTA DO EDITOR – A FAZER: É preciso adicionar definições para descoberta, modelos de coisas, perfis, ciclo de vida.

4. Domínios de Aplicação (Verticais)

Esta seção não é normativa.

Esta seção apresenta os domínios de aplicação e os casos de uso visados pelo W3C WoT e que são usados para derivar a arquitetura abstrata discutida no § 9. Componentes WoT.

A arquitetura da Web das Coisas não coloca quaisquer limitações em casos de uso e domínios de aplicação. Vários domínios de aplicação foram considerados para coletar padrões comuns que têm de ser satisfeitos pela arquitetura abstrata.

As seções seguintes não são exaustivas. Em vez disso, servem como ilustrações, em que as coisas conectadas podem proporcionar benefícios adicionais ou permitir novos cenários.

NOTA DO EDITOR: CASOS DE USO

Nota: Os casos de uso estão sendo coletados e organizados no repositório https://github.com/w3c/wot-usecases. Um documento de caso de Utilização pormenorizado está sendo preparado, que deverá ser publicado como uma Nota W3C [WOT-USE-CASES]. Um esboço está disponível em: https://w3c.github.io/wot-usecases/.

4.1 Consumidor

No espaço do consumidor há múltiplos ativos que se beneficiam ao estar conectados. Luzes e ar-condicionado podem ser desligados de acordo com a ocupação do quarto. Cortinas podem ser fechadas automaticamente com base em condições meteorológicas e presença. O consumo de energia e de outros recursos pode ser otimizado com base em padrões de uso e previsões.

Os casos de uso do consumidor nesta seção incluem casos de uso de Casa Inteligente.

Na Figura 1, há o exemplo de uma Casa Inteligente. Neste caso, gateways são conectados a dispositivos de borda, tais como sensores, câmeras e eletrodomésticos através de protocolos de comunicação locais correspondentes, como KNX, ECHONET, ZigBee, DECT ULE e Wi-SUN. Vários gateways podem existir em uma casa, enquanto cada gatewaypode suportar múltiplos protocolos locais.

Os gateways podem ser conectados à nuvem através da internet, enquanto alguns aparelhos podem ser conectados diretamente à nuvem. Os serviços que rodam na nuvem coletam dados de dispositivos de borda e analisam os dados, depois, fornecem valor para os usuários a partir dos dispositivos de borda e outros dispositivos UX.

A Casa Inteligente oferece benefícios aos consumidores, como acesso e controle remotos, controle de voz e automação doméstica. A Casa Inteligente também permite aos fabricantes de dispositivos monitorarem e darem manutenção a dispositivos remotamente. A Casa Inteligente pode realizar serviços de valor agregado, como gerenciamento de energia e vigilância de segurança.

4.2 Industrial
Os casos de uso industrial nesta seção são aplicáveis a diferentes produtos da indústria.
Devido à natureza das sobreposições nos cenários de aplicação, os diferentes produtos verticais têm casos de uso semelhantes.

4.2.1 Exemplo: Fábrica Inteligente

A Figura 2 representa o exemplo de Fábrica Inteligente. Neste caso, controladores ao nível de campo, células e linhas automatizam diferentes equipamentos de fábrica com base em protocolos de comunicação industrial como PROFINET, Modbus, OPC UA TSN, EtherCAT ou CAN. Um dispositivo de borda industrial coleta dados selecionados de vários controladores e disponibiliza-os a um serviço de backend de nuvem, por exemplo, para monitoramento remoto através de um painel de instrumentos ou analisa-os para manutenção preventiva.

As fábricas inteligentes exigem um acompanhamento avançado dos equipamentos de fabricação conectados, bem como dos produtos fabricados. Eles se beneficiam de previsões de falhas de máquinas e descobertas precoces de anomalias para evitar dispendiosos esforços de tempo de inatividade e manutenção.

Além disso, o monitoramento do equipamento de produção conectado e do ambiente na instalação de produção para a presença de gases tóxicos, ruído excessivo ou calor aumenta a segurança dos trabalhadores e reduz os riscos de incidentes ou acidentes.

Monitoramento em tempo real e cálculos de KPI (Indicador-chave de Desempenho) de equipamentos de produção ajudam a detectar problemas de produtividade e a otimizar a cadeia de suprimentos.

4.3 Transportes e Logística

O monitoramento de veículos, custos de combustível, necessidades de manutenção e tarefas ajuda a otimizar a plena utilização da frota de veículos.

As remessas podem ser rastreadas para serem encaminhadas visando garantir a qualidade e o estado consistente das mercadorias transportadas. Isto é bastante útil para garantir a integridade da cadeia fria de armazéns a caminhões refrigerados para entrega.

O controle centralizado e a gestão dos estoques nos armazéns e estaleiros podem evitar situações de falta ou excesso de estoque.

4.4 Serviços

Leitura automatizada de contadores residenciais e C&I (Comerciais e Industriais) e faturamento oferecem informações contínuas sobre o consumo de recursos e potenciais gargalos.

O monitoramento da condição e da produção de equipamentos distribuídos de geração de energia renovável permite a otimização dos recursos energéticos distribuídos.

O monitoramento e controle remoto de equipamentos de distribuição ajudam a automatizar o processo de distribuição.

O acompanhamento contínuo da infraestrutura de geração e distribuição está melhorando a segurança da equipe de serviço em campo.

4.5 Petróleo e Gás

O monitoramento das plataformas offshore, a detecção de vazamentos e a previsão de oleodutos, bem como o monitoramento e controle dos níveis nos tanques e reservatórios, contribuem para melhorar a segurança industrial da mão de obra e do meio ambiente.

O cálculo automatizado de um estoque distribuído em vários tanques de armazenamento e ductos de entrega/caminhões permite melhor planejamento e otimização de recursos.

4.6 Seguros

Acompanhamento Proativo de Ativos de elevado valor, tais como estruturas conectadas, veículos de frota, etc., reduz o risco de danos graves e custos elevados graças a previsões e detecção precoce de incidentes.

Seguro baseado no uso pode ser oferecido com acompanhamento de uso e apólices de seguro personalizadas.

Monitoramento meteorológico preditivo e redirecionamento de veículos da frota para garagens cobertas pode limitar a perda devido a danos por granizo e devido à queda de árvores.

4.7 Engenharia e Construção

O controle da segurança industrial reduz os riscos para a segurança. O monitoramento dos ativos no local de construção pode prevenir danos e perdas.

4.8 Agricultura

O monitoramento da condição do solo e a criação de planos otimizados para regar, fertilizar e monitorar as condições de produção otimizam a qualidade e o resultado da produção agrícola.

4.9 Cuidados de Saúde

A coleta de dados e a análise dos dados de ensaios clínicos ajudam a obter informações sobre novas áreas.

O monitoramento remoto de pacientes reduz o risco de situações críticas não detectadas em idosos e pacientes após a internação.

4.10 Monitoramento Ambiental

O monitoramento ambiental, comumente, depende de um lote de sensores distribuídos que enviam suas medições para gateways comuns, dispositivos de borda e serviços de nuvem.

O monitoramento da poluição atmosférica, da poluição da água e de outros fatores de risco ambiental, tais como poeiras finas, ozônio, compostos orgânicos voláteis, radioatividade, temperatura, umidade para detectar condições ambientais críticas, pode prevenir danos irreparáveis para a saúde ou para o meio ambiente.

4.11 Cidades Inteligentes

O monitoramento do estado material de pontes, barragens, diques, canais, quanto à deterioração e às vibrações, permite trabalhos de reparo e manutenção e evita danos significativos. O monitoramento de rodovias e a sinalização adequada garantem um fluxo de tráfego otimizado.

O Estacionamento Inteligente está otimizando e rastreando o uso e a disponibilidade de vagas de estacionamento e automatiza faturamentos/reservas.

Controle inteligente de luzes de rua com base na detecção de presença, previsões meteorológicas, etc., reduz custos.

Os recipientes de lixo podem ser monitorados para otimizar a gestão de resíduos e a rota de coleta de lixo.

4.12 Edifícios Inteligentes

O monitoramento do uso de energia em todo o edifício ajuda a otimizar o consumo de recursos e reduzir o desperdício.

Monitoramento de equipamentos em edifícios, tais como ventilação, elevadores, etc., e a solução precoce de problemas melhoram a satisfação dos ocupantes.

4.13 Automóvel Conectado

O monitoramento do estado de operação, previsão de necessidades de serviço, otimiza as necessidades de manutenção e custos. A segurança dos condutores é reforçada com a notificação de um sistema de alerta rápido para as condições críticas de circulação rodoviária.

4.13.1 Exemplo de Automóvel Conectado

A Figura 3 ilustra um exemplo de automóvel conectado. Neste caso, um gateway conecta-se aos componentes do automóvel por CAN e ao sistema de navegação do carro através de uma interface proprietária. Os serviços que funcionam na nuvem coletam dados levados a partir de componentes do carro e analisam os dados de múltiplos veículos para determinar os padrões de tráfego. O gateway também pode consumir serviços de nuvem, neste caso, para obter dados de tráfego e mostrá-los ao motorista através do sistema de navegação do automóvel.

Esta seção não é normativa.

Esta seção introduz padrões de implantação comuns que ilustram como dispositivos/coisas interagem com controladores, outros dispositivos, agentes e servidores. Nesta seção, usa-se o termo função cliente (client role) como iniciador de um protocolo de transporte, e o termo função servidor (server role) como um componente passivo de um protocolo de transporte. Isso não implica prescrição de uma função específica sobre qualquer componente do sistema. Um dispositivo pode estar em uma função cliente e servidor simultaneamente.

Um exemplo dessa dupla função é um sensor, que se registra com um serviço de nuvem e envia regularmente leituras de sensores para a nuvem. Nas mensagens de resposta, a nuvem pode ajustar a taxa de transmissão das mensagens do sensor ou selecionar atributos específicos do sensor, que devem ser transmitidos em mensagens futuras. Uma vez que o sensor se registra com a nuvem e inicia conexões, ela está na função “cliente”. No entanto, uma vez que também reage a pedidos, que são transmitidos em mensagens de resposta, também, cumpre função de “servidor”.

As seções seguintes descrevem as funções, as tarefas e os padrões de casos de uso com complexidade crescente. Elas não são exaustivas, sendo apresentadas visando motivar para a arquitetura WoT e componentes que são definidos em seções posteriores desta especificação.

5.1 Controladores de Dispositivos

O primeiro caso de uso é um dispositivo local gerenciado por um controlador remoto operado pelo usuário, como descrito na Figura 4. Um controlador remoto pode acessar um aparelho eletrônico através da rede doméstica local diretamente. Neste caso, o controlador remoto pode ser implementado por um navegador ou aplicação nativa.

Neste padrão, pelo menos um dispositivo como o aparelho eletrônico tem a função de servidor que pode aceitar uma solicitação dos outros dispositivos e responde a eles e, às vezes, inicia uma ação mecânica. O outro dispositivo como o controlador remoto tem a função de cliente que pode enviar uma mensagem com um pedido, como ler um valor do sensor ou ligar o dispositivo. Além disso, para emitir uma notificação de estado ou evento atual de um dispositivo, o dispositivo pode ter uma função de cliente que pode enviar uma mensagem para outro dispositivo, que tem funções de servidor.

5.2 Coisa a Coisa

A Figura 5 exemplifica uma interação direta Coisa a Coisa. O cenário é o seguinte: um sensor detecta uma mudança da condição da sala, por exemplo, a temperatura que excede a um limiar e emite uma mensagem de controle como “ligar” para o aparelho eletrônico. A unidade de sensores pode emitir algumas mensagens de ativação para outros dispositivos.Neste caso, quando dois dispositivos que têm função de servidor estão conectados, pelo menos um dispositivo deve ter também a função de cliente, que emite uma mensagem para o outro para acionar ou notificar.

5.3 Acesso Remoto

Este caso de uso contém um controlador remoto móvel (por exemplo, em um smartphone), como se observa na Figura 6. O controlador remoto pode alternar entre diferentes conexões de rede e protocolos, por exemplo, entre uma rede móvel e uma rede doméstica, que está usando protocolos como Wi-Fi e bluetooth. Quando o controlador está na rede doméstica é um dispositivo confiável e não é necessário nenhum controle adicional de segurança ou acesso. Enquanto estiver fora da rede confiável, devem ser aplicados mecanismos adicionais de controle de acesso e segurança para garantir uma relação confiável. Note-se que neste cenário a conectividade de rede pode alterar devido à mudança entre diferentes pontos de acesso à rede ou estações de base celulares.

Neste padrão, o controlador remoto e o aparelho eletrônico têm função cliente e servidor como no cenário relacionado, na Figura 4.

5.4 Gateways de Casas Inteligentes

A Figura 7 representa um caso de uso de um Gateway de Casa Inteligente. O gateway é colocado entre uma rede doméstica e a Internet. Ele gerencia eletrodomésticos dentro da casa e pode receber comandos de um controlador remoto através da Internet, por exemplo, de um smartphone, como no caso de uso anterior. É também uma representação virtual de um dispositivo. O Gateway de Casa Inteligente tipicamente oferece proxy e funcionalidade de firewall.

Neste padrão, o gateway de casa inteligente tem função tanto de cliente quanto de servidor. Quando o controlador remoto aciona o aparelho eletrônico, ele pode conectar-se ao aparelho eletrônico com a função de cliente e, ao controlador remoto, com a função de servidor. Quando o aparelho eletrônico emite uma mensagem para o controlador remoto, o gateway atua com funções de servidor para o aparelho elétrico e, com funções de cliente, para o controlador remoto.

5.5 Dispositivos de Bordas

NOTA DO EDITOR: A FAZER: Esta seção será expandida para capturar atividades recentes.

Um Dispositivo de Borda ou Gateway de Borda é semelhante a um Gateway de Casa Inteligente. Aqui se utiliza o termo para indicar tarefas adicionais que são realizadas pelo gateway de borda. Enquanto o gateway doméstico, conforme a Figura 8, basicamente apenas liga a rede pública e a rede confiável, o dispositivo de borda tem recursos de computação locais e, normalmente, liga diferentes protocolos. Dispositivos de borda são comumente usados em soluções industriais, para as quais podem fornecer pré-processamento, filtragem e agregação de dados fornecidos por dispositivos e sensores conectados.

5.6 Gêmeos Digitais

Um gêmeo digital é uma representação virtual de um dispositivo ou um grupo de dispositivos que reside em uma nuvem ou dispositivo de borda. Ele pode ser usado para representar dispositivos do mundo real que podem não estar on-lineconstantemente, ou para executar simulações de novas aplicações e serviços, antes de ser implantado nos dispositivos reais.

Os gêmeos digitais podem representar único dispositivo ou podem agregar múltiplos dispositivos em uma representação virtual dos dispositivos combinados.

Gêmeos digitais podem ser concretizados de diferentes maneiras, dependendo se um dispositivo já está conectado à nuvem ou se ele está conectado a um gateway que está, por sua vez, conectado à nuvem.

5.6.1 Dispositivos Prontos para Nuvens

Na Figura 11, expõe-se um exemplo no qual os aparelhos eletrônicos estão ligados diretamente à nuvem. A nuvem espelha os eletrodomésticos e, atuando como um gêmeo digital, pode receber comandos de controladores remotos (por exemplo, um smartphone). Controladores autorizados podem ser localizados em qualquer lugar, pois o gêmeo digital é globalmente acessível.

5.6.2 Dispositivos Legados

Na Figura 12, consta um exemplo em que os eletrodomésticos legados não podem conectar-se diretamente à nuvem. Aqui, um gateway é necessário para transmitir a conexão. O gateway funciona como:

• integrador de uma variedade de protocolos de comunicação legado, tanto de ponto de vista físico como lógico;
• firewall para a Internet;
• filtro de privacidade que substitui imagem real e/ou fala, e registra os dados localmente;
• agente local no caso de a conexão à rede ser interrompida;
• serviços de emergência, rodando localmente, quando ocorrem alarmes de incêndio e eventos semelhantes.

A nuvem espelha o gateway com todos os aparelhos conectados e atua como um gêmeo digital que os gerencia na nuvem, junto com o gateway. Além disso, a nuvem pode receber comandos de controladores remotos (por exemplo, um smartphone), que podem ser localizados em qualquer lugar.

5.7 Multi-nuvem

Implantações típicas de IoT consistem em múltiplos (milhares) dispositivos. Sem um mecanismo padronizado, a gestão de atualizações de firmware para nuvens específicas requer muito esforço e dificulta a adoção de IoT em maior escala.

A principal vantagem de um mecanismo padronizado para descrever dispositivos e tipos de dispositivos é a capacidade de implantação de dispositivos para diferentes ambientes de nuvem, sem a necessidade de fazer a personalização, no dispositivo, ao nível de software/firmware ‒ por exemplo, a instalação de código específico de nuvem para um dispositivo. Isso implica que a solução é flexível o suficiente para descrever os dispositivos de uma forma que permita o embarque e o uso de dispositivos em múltiplos ambientes de nuvem de IoT.

Isso impulsiona a adoção de dispositivos de Web das Coisas, visto que permite o fácil uso de novos dispositivos em uma implantação existente, bem como a migração de dispositivos existentes de uma nuvem para a outra.

5.8 Colaboração entre Domínios

Na Figura 13, observa-se o exemplo de uma colaboração entre domínios. Neste caso, cada sistema envolve outros sistemas em outros domínios, como Fábrica Inteligente com Cidade Inteligente, Cidade Inteligente com Casa Inteligente. Esse tipo de sistema é chamado de ecossistema “Simbiótico”, como se verifica em [IEC-FOTF]. Existem dois modelos de colaboração: colaboração direta e colaboração indireta. No modelo de colaboração direta, os sistemas trocam informações diretamente entre si, de uma forma ponto a ponto. Na colaboração indireta, os sistemas trocam informações por meio de alguma plataforma de colaboração. A fim de manter e continuar esta colaboração, cada sistema fornece os metadados de seus recursos e interfaces e adapta-se aos outros.

6. Integração de Sistema

A seção anterior descreve vários padrões de arquitetura. Nesses padrões, algumas entidades funcionais como os dispositivos, incluindo os dispositivos legados, controladores, gateways e servidores de nuvem, estão localizadas em pontos físicos, tais como dentro de edifícios, fora de edifícios e em data centers. A Figura 14 é um panorama que mostra as combinações e os caminhos de comunicação dessas entidades.

Em uma camada de protocolo de transporte, cada entidade arbitrariamente seleciona uma função adequada para as comunicações. Por exemplo, um dispositivo pode atuar como um servidor quando o dispositivo fornece um serviço para um número indefinido de aplicações. Por sua vez, se um dispositivo tiver conectividade de rede limitada ou intermitente, ele pode atuar como cliente e enviar mensagens ativamente para uma aplicação quando a rede estiver disponível. Independentemente disso, na camada de aplicação, uma aplicação vê que um dispositivo fornece interfaces abstratas para interagir, e a aplicação pode interagir com o dispositivo usando suas interfaces abstratas.

7. Requisitos

Esta seção é normativa.

NOTA DO EDITOR: USAR CASOS E REQUISITOS

Nota:Os requisitos WoT estão sendo coletados e organizados no repositório https://github.com/w3c/wot-architecture. Os requisitos são, por sua vez, derivados de Casos de Uso WoT [WOT-USE-CASES].

7.1 Requisitos Funcionais

Esta seção define as propriedades necessárias a uma arquitetura abstrata de Web das Coisas (WoT).

NOTA DO EDITOR – A FAZER: Novos requisitos de novos casos de uso devem ser adicionados aqui. Aicionar um link para a seção de requisitos no repositório github.

7.1.1 Princípios Comuns

• A arquitetura WoT deverá permitir o interfuncionamento mútuo de diferentes ecossistemas utilizando tecnologia Web.
• A arquitetura WoT deve ser baseada na arquitetura Web usando APIs RESTful.
• A arquitetura WoT deve permitir a utilização de múltiplos formatos de carga que são comumente usados na Web.
• A arquitetura WoT deve permitir diferentes arquiteturas de dispositivos e não deve forçar um cliente ou servidor à implementação de componentes do sistema.
• Flexibilidade

Há grande variedade de configurações de dispositivos físicos para implementações WoT. A arquitetura abstrata WoT deve ser capaz de ser mapeada e de cobrir todas as variações.

• Compatibilidade: Já existem muitas soluções de IoT e atividades de padronização de IoT em diversos campos de negócios. A WoT deve fornecer uma ponte entre essas soluções de IoT existentes e em desenvolvimento e tecnologia Web baseada em conceitos de WoT. A WoT deve ser compatível com as soluções de IoT existentes e com as normas atuais.

• Escalabilidade: A WoT deve ser capaz de escalar para soluções IoT que incorporam milhares a milhões de dispositivos. Esses dispositivos podem oferecer recursos análogos, mesmo que sejam criados por diferentes fabricantes.

• Interoperabilidade; A WoT deve assegurar a interoperabilidade entre os fabricantes de dispositivos e de nuvem. Deve ser possível pegar um dispositivo WoT habilitado e conectá-lo com um serviço de nuvem de diferentes fabricantes imediatamente.

7.1.2 Funcionalidades das Coisas

• A arquitetura WoT deve permitir que as coisas tenham funcionalidades como:
  • leitura da informação do estado da coisa;
  • atualizar a informação do estado da coisa que pode causar a ativação;
  • inscrever, receber e cancelar notificações de alterações da informação de estado da coisa;
  • invocar funções com parâmetros de entrada e de saída que causariam uma determinada ativação ou cálculo;
  • inscrever, receber e cancelar notificações de eventos que são mais gerais do que apenas relatórios de transições de estado.

7.1.3 Busca e Descoberta

• A arquitetura WoT deve permitir que os clientes saibam os atributos, as funcionalidades e os seus pontos de acesso antes de acessar a coisa em si.
• A arquitetura WoT deve permitir que os clientes procurem coisas por seus atributos e funcionalidades.
• A arquitetura WoT deve permitir a busca semântica de coisas que forneçam funcionalidades necessárias baseadas em um vocabulário unificado, independentemente do nome das funcionalidades.

7.1.4 Mecanismo de Descrição

• A arquitetura WoT deve suportar um mecanismo de descrição comum que permita descrever coisas e suas funções.
• Tais descrições não devem ser apenas legíveis por humanos, mas também legíveis por máquina.
• Essas descrições devem permitir uma anotação semântica da sua estrutura e conteúdo descrito.
• Essas descrições devem poder ser trocadas utilizando múltiplos formatos que são comumente utilizados na web.

7.1.5 Descrição dos Atributos

• A arquitetura WoT deve permitir descrever atributos das coisas como:
  • nome;
  • explicação;
  • versão de especificação, formato e descrição em si;
  • ligações a outras coisas relacionadas e informação sobre metadados.
• Tais descrições devem suportar a internacionalização.

7.1.6 Descrição das Funcionalidades

• A arquitetura WoT deve permitir descrever as funcionalidades da coisa como descrito em § 7.1.2 Funcionalidades da Coisa

7.1.7 Rede

• A arquitetura WoT deve suportar múltiplos protocolos Web que são comumente usados.
• Tais protocolos incluem:
  • protocolos comumente utilizados na internet; e
  • protocolos comumente utilizados na rede local.
• A arquitetura WoT deve permitir o uso de múltiplos protocolos Web para acessar a mesma funcionalidade.
• A arquitetura WoT deve permitir a utilização de uma combinação de múltiplos protocolos para as funcionalidades da mesma coisa (por exemplo, HTTP e WebSocket).

7.1.8 Implantação

• A arquitetura WoT deve suportar uma grande variedade de capacidades de coisas, tais como dispositivos de borda com restrições de recursos e coisas virtuais na nuvem, com base no mesmo modelo.
• A arquitetura WoT deve suportar múltiplos níveis de hierarquia de coisas com entidades intermediárias, como gatewayse proxies.
• A arquitetura WoT deve suportar o acesso às coisas na rede local a partir do exterior da rede local (a internet ou outra rede local), considerando a tradução de endereço de rede.

7.1.9 Aplicação

• A arquitetura WoT deve permitir a descrição de aplicações para uma grande variedade de coisas, como dispositivo de borda, gateway, nuvem e dispositivo UI/UX, usando tecnologia padrão Web baseada no mesmo modelo.

7.1.10 Adoção Legado

• A arquitetura WoT deve permitir mapear os protocolos antigos de IP e não IP para protocolos Web, suportando várias topologias, em que tais protocolos legados são terminados e traduzidos.
• A arquitetura WoT deve permitir a utilização transparente dos protocolos IP existentes sem tradução, que seguem arquitetura RESTful.
• A arquitetura WoT não deve impor funções de cliente ou servidor em dispositivos e serviços. Um dispositivo IoT pode ser um cliente ou um servidor, ou ambos, dependendo da arquitetura do sistema; da mesma forma para os serviços de borda e nuvem.

7.2 Requisitos Técnicos

§ 5. Topologias de Sistema (Horizontais) define a arquitetura abstrata da Web das coisas, mostrando várias topologias de sistema. Esta seção descreve os requisitos técnicos derivados da arquitetura abstrata.

NOTA DO EDITOR: A FAZER: Novos requisitos de novos casos de uso devem ser adicionados aqui.

7.2.1 Componentes na Web das Coisas e a Arquitetura da Web das Coisas

Os casos de uso ajudam a identificar componentes básicos, tais como dispositivos e aplicações que acessam e controlam esses dispositivos, proxies (ou seja, gateways e dispositivos de borda) que estão localizados entre dispositivos. Um componente adicional útil em alguns casos de uso é o diretório, que auxilia na descoberta.

Esses componentes estão conectados à internet ou a redes de campo em escritórios, fábricas ou outras instalações. Note que todos os componentes envolvidos podem ser conectados a única rede em alguns casos. No entanto, em geral, componentes podem ser implantados em várias redes.

7.2.2 Dispositivos

O acesso aos dispositivos é feito mediante uma descrição das suas funções e interfaces. Essa descrição é chamada Descrição de Coisa (Thing Description, TD). Uma Descrição de Coisa inclui um metadado geral sobre o dispositivo, modelos de informação representando funções, descrição do protocolo de transporte para operar em modelos de informação e informações de segurança.

Os metadados gerais contêm identificadores de dispositivos (URI), informações do dispositivo, tais como número de série, data de produção, localização e outras informações legíveis por humanos.

Os modelos de informação definem os atributos do dispositivo e representam a configuração interna do dispositivo, a funcionalidade de controle e a funcionalidade de notificação. Os dispositivos que desempenham a mesma funcionalidade têm o mesmo modelo de informação, independentemente dos protocolos de transporte utilizados.

Visto que muitos sistemas baseados na arquitetura da Web das Coisas estão cruzando domínios do sistema, vocabulários e metadados (por exemplo, ontologias) usados em modelos de informação devem ser comumente compreendidos pelas partes envolvidas. Além dos transportes REST, os transportes PubSub também são suportados.

Informações de segurança incluem descrições sobre autenticação, autorização e comunicações seguras. Os dispositivos devem colocar TDs, dentro deles ou em locais externos aos dispositivos, e tornar TDs acessíveis para que outros componentes possam encontrá-los e acessá-los.

7.2.3 Aplicações

As aplicações devem ser capazes de gerar e utilizar interfaces de rede e de programa baseadas em metadados (descrições).

As aplicações devem estar aptas a obter essas descrições através da rede, portanto, precisam ser capazes de realizar operações de pesquisa e adquirir as descrições necessárias a partir da rede.

7.2.4 Gêmeos Digitais

Gêmeos Digitais precisam gerar interfaces de programa internamente baseadas em metadados (descrições) e representar dispositivos virtuais usando essas interfaces de programa. Um gêmeo deve produzir uma descrição para o dispositivo virtual e torná-lo disponível externamente.

Os identificadores de dispositivos virtuais precisam ser atribuídos de novo, portanto, são diferentes dos dispositivos originais. Isso garante que os dispositivos virtuais e os dispositivos originais sejam claramente reconhecidos como entidades separadas. Os mecanismos de transporte e segurança e as configurações dos dispositivos virtuais podem ser diferentes dos dispositivos originais, se necessário. Dispositivos virtuais são necessários para ter descrições fornecidas diretamente pelo gêmeo ou para tê-los disponíveis em locais externos. Em ambos os casos, precisa-se tornar as descrições disponíveis para que outros componentes possam encontrar e usar os dispositivos associados a eles.

7.2.5 Descoberta

Para que os TDs de dispositivos e dispositivos virtuais estejam acessíveis a partir de dispositivos, aplicações e gêmeos, deve haver uma maneira comum de compartilhar TDs. Os diretórios podem atender a este requisito fornecendo funcionalidades para permitir que os dispositivos e os próprios gêmeos, automaticamente, ou os usuários registrem manualmente as descrições.

As descrições dos dispositivos e dispositivos virtuais devem ser pesquisáveis por entidades externas. Os diretórios devem ser capazes de processar as operações de busca com chaves de busca, tais como palavras-chave da descrição geral na descrição do dispositivo, ou modelos de informação.

7.2.6 Segurança

As informações de segurança relacionadas com dispositivos e dispositivos virtuais devem ser mencionadas nas descrições dos dispositivos. Isto inclui informações para autenticação/autorização e encriptação de carga.

A arquitetura WoT deve suportar múltiplos mecanismos de segurança comumente usados na Web, como Basic, Digest, Bearer e OAuth2.0.

7.2.7 Acessibilidade

A Web das Coisas visa principalmente à comunicação máquina-a-máquina. Os humanos envolvidos são geralmente desenvolvedores que integram as Coisas em aplicações. Os utilizadores finais serão confrontados com os front-ends das aplicações ou com as interfaces físicas fornecidas pelos próprios dispositivos. Ambos estão fora do âmbito das especificações W3C WoT. Dado o foco em IoT em vez de usuários, a acessibilidade não é um requisito direto e, portanto, não é abordada nesta especificação.

Há, no entanto, um aspecto interessante sobre acessibilidade: o cumprimento dos requisitos supradescritos permite que as máquinas compreendam a API de dispositivos voltados para a rede. Isso pode ser utilizado por ferramentas de acessibilidade para fornecer interfaces de usuário de diferentes modalidades, removendo assim barreiras ao uso de dispositivos físicos e aplicações relacionadas com a IoT.