BR112018006334B1 - Método e sistema para monitorar status de dispositivos de campo e unidade de terminal remoto para uso em planta de processo - Google Patents

Abstract

MONITORAMENTO DE DISPOSITIVOS DE CAMPO VIA UMA REDE DE COMUNICAÇÃO. Um sistema para monitorar dispositivos de campo que operam em plantas de processo inclui uma unidade de terminal remoto (RTU) acoplada a vários dispositivos de campo, cada um configurado para executar uma função respectiva em uma planta de processo e um host disposto remotamente a partir da RTU e acoplado à RTU através de uma rede de comunicação. A RTU inclui (i) um primeiro módulo de interface configurado para se comunicar de acordo com um protocolo de automação industrial digital, através do qual a RTU recebe dados indicativos dos respectivos status dos dispositivos de campo, (ii) uma memória para armazenar os dados recebidos, e (iii) um segundo módulo de interface configurado para se comunicar com hosts remotos através de uma rede de comunicação. O host é configurado para (i) solicitar os status dos dispositivos de campo e (ii) receber, a partir da RTU, indicações do status com base nos dados armazenados na memória da RTU.

Description

CAMPO DA TECNOLOGIA

[0001] A presente invenção se refere, em geral, a sistemas de planta de processo e, mais particularmente, monitoramento da saúde de dispositivos de campo através de uma rede de comunicação usando dispositivos intermediários configurados para coletar informações de status do dispositivo e outros dados dos dispositivos de campo.

INFORMAÇÕES DE FUNDAMENTO

[0002] A descrição de fundo aqui fornecida aqui é para a finalidade de apresentar geralmente o contexto da divulgação. O trabalho dos inventores presentemente designados, na medida em que ele é descrito nesta seção de fundamentos, bem como aspectos da descrição que não podem de outro modo ser qualificados como técnica anterior no momento do depósito, não são expressamente nem implicitamente admitidos como técnica anterior contra a presente divulgação.

[0003] Os sistemas de controle de processos distribuídos, como os usados em indústrias químicas, de petróleo ou de outros processos, geralmente incluem um ou mais controladores de processo acoplados de forma comunicativa a um ou mais dispositivos de campo por meio de barramentos analógicos/digitais ou analógicos/digitais combinados ou através de uma ligação de comunicação sem fio ou rede. Os dispositivos de campo, que podem ser, por exemplo, válvulas, posicionadores de válvulas, interruptores e transmissores (por exemplo, temperatura, pressão, nível e sensores de taxa de fluxo) estão localizados dentro do ambiente do processo e geralmente realizam funções de controle físico ou de processo, como abertura ou fechamento de válvulas, medição de parâmetros do processo, etc. para controlar um ou mais processos que se executam dentro da indústria ou sistema de processo. Os dispositivos de campo inteligentes, como os dispositivos de campo em conformidade com o bem conhecido protocolo Fieldbus, também podem realizar cálculos de controle, funções alarmantes e outras funções de controle comumente implementadas dentro do controlador. Os controladores de processo, que também estão tipicamente localizados dentro do ambiente da planta, recebem sinais indicativos de medições de processo feitas por sensores e/ou dispositivos de campo e/ou outras informações pertencentes aos dispositivos de campo e executam um aplicativo de controlador que executa, por exemplo, diferentes módulos de controle que tomam decisões de controle de processo, geram sinais de controle com base nas informações recebidas e coordenam com os módulos ou blocos de controle que estão sendo executados nos dispositivos de campo, como os dispositivos de campo HART®, Wireless HART®, e FOUNDATION® Fieldbus. Os módulos de controle no controlador enviam os sinais de controle através das linhas de comunicação ou ligações aos dispositivos de campo para assim controlar a operação de pelo menos uma parte da indústria ou sistema de processo.

[0004] As informações dos dispositivos de campo e do controlador normalmente são disponibilizadas através de uma rodovia de dados para um ou mais outros dispositivos de hardware, tais como estações de trabalho do operador, computadores pessoais ou dispositivos informáticos, historiadores de dados, geradores de relatórios, bancos de dados centralizados ou outros dispositivos informáticos administrativos centralizados que normalmente são colocados em salas de controle ou outros locais longe do ambiente mais severo da indústria. Cada um desses dispositivos de hardware tipicamente é centralizado em toda a planta de processo ou em uma porção da planta de processo. Esses dispositivos de hardware executam aplicativos que podem, por exemplo, permitir que um operador execute funções no que diz respeito ao controle de um processo e/ou operação da planta de processo, como alterar as configurações da rotina de controle de processo, modificar a operação dos módulos de controle dentro do controladores ou os dispositivos de campo, visualizar o status atual do processo, visualizar alarmes gerados por dispositivos de campo e controladores, simular a operação do processo com o objetivo de capacitar o pessoal ou testar o software de controle de processo, mantendo e atualizando um banco de dados de configuração, etc. . A rodovia de dados utilizada pelos dispositivos de hardware, controladores e dispositivos de campo pode incluir um caminho de comunicação com fio, um caminho de comunicação sem fio ou uma combinação de caminhos de comunicação com fio e sem fio.

[0005] Um sistema de controle de processo distribuído pode incluir uma ou mais unidades de terminal remoto (RTUs), que podem ser implementadas como computadores de fluxo acoplados a dispositivos de campo. Uma RTU pode incluir, por exemplo, um ou mais módulos de I/O para conectar-se a dispositivos de campo com dispositivos de campo Highway Addressable Remote Transducer (HART) com fio e um ou mais módulos de I/O para conexão ao dispositivo de campo HART sem fio. De forma mais geral, uma RTU pode suportar qualquer protocolo de automação industrial adequado, incluindo protocolos de automação industrial digital adequados como HART, Fieldbus ou Profibus.

[0006] Uma RTU pode operar em uma rede de controle de supervisão e aquisição de dados (SCADA). A rede SCADA pode ser uma rede ou sistema de supervisão central ou distribuído que conecta um ou vários hosts executando aplicativos de software para monitorar processos, equipamentos, variáveis, etc. com dispositivos especiais que operam um sistema de controle de processo (ou, em geral, um sistema de controle industrial). Por exemplo, um host que implementa um sistema de gerenciamento de ativos (AMS) pode se comunicar com uma ou mais RTUs para coletar informações sobre dispositivos de campo conectados às RTUs para construir uma hierarquia de dispositivos de campo e fornecer uma descrição da hierarquia para um operador via interface de usuário da AMS. O host também pode implementar, ou ser acoplado de forma comunicativa, a um módulo que suporte um protocolo de automação industrial para comandos de tunelamento através de uma RTU para um dispositivo de campo. Por exemplo, o host pode incluir um módulo de servidor HART.

[0007] Para avaliar a saúde de um dispositivo de campo, o host envia uma mensagem através da rede SCADA e da RTU para o dispositivo de campo, recebe a resposta ou detecta um tempo limite e fornece uma indicação apropriada para o operador através da interface do usuário. Em outras palavras, a abordagem disponível hoje é baseada em acessar diretamente um dispositivo de campo de um host remoto através de uma rede de comunicação. A coleta de informações dessa maneira pode levar vários segundos por cada dispositivo de campo, com operadores com um atraso particularmente longo quando um dispositivo de campo não está se comunicando e o host detecta um evento de tempo limite. Além disso, essa abordagem gera uma grande quantidade de tráfego na rede, às vezes interferindo em outras comunicações, como a coleta de dados de telemetria SCADA.

SUMÁRIO

[0008] Uma unidade de terminal remoto (RTU) é acoplada de forma comunicativa a um host remoto e dispositivos de campo que executam as respectivas funções em uma planta de processo. A RTU coleta informações indicativas do status dos dispositivos de campo, como alertas e armazena (ou "oculta") esta informação em sua memória local. A RTU fornece essas informações ao host remoto mediante solicitação através de uma rede SCADA, que pode incluir ligações de comunicação com e sem fio. O host remoto pode coletar as informações da RTU de acordo com uma programação configurável por um operador. Desta forma, o número de mensagens que se deslocam entre o host remoto e um dispositivo de campo individual é significativamente reduzido e as informações de status para vários dispositivos de campo podem ser fornecidas rápida e eficientemente a um operador através da interface do usuário do host remoto. Além disso, o host pode fornecer informações de status para dispositivos de campo para um software de terceiros de acordo com o padrão OPC Alarms and Events, por exemplo.

[0009] Uma modalidade dessas técnicas é um método para monitorar o status de dispositivos de campo que operam em uma planta de processo. O método inclui (i) receber, em uma RTU acoplada a um dispositivo de campo, dados indicativos de um status do dispositivo de campo, (ii) armazenar a informação recebida em uma memória da RTU, (iii) receber, na RTU de um host remoto através de uma rede de comunicação, uma solicitação para o status do dispositivo de campo e (iv) fornecer, a partir da RTU para o host remoto em resposta à solicitação uma indicação do status do dispositivo de campo com base nos dados armazenados na memória da RTU.

[0010] Outra incorporação dessas técnicas é um sistema para monitorar dispositivos de campo que operam em plantas de processo. O sistema inclui uma unidade de terminal remoto (RTU) acoplada a vários dispositivos de campo, cada um configurado para executar uma função respectiva em uma planta de processo e um host disposto remotamente a partir da RTU e acoplado à RTU através de uma rede de comunicação. A RTU inclui (i) um primeiro módulo de interface configurado para se comunicar de acordo com um protocolo de automação industrial digital, através do qual a RTU recebe dados indicativos dos respectivos status dos dispositivos de campo, (ii) uma memória para armazenar os dados recebidos, e (iii) um segundo módulo de interface configurado para se comunicar com hosts remotos através de uma rede de comunicação. O host é configurado para (i) solicitar os status dos dispositivos de campo e (ii) receber, a partir da RTU, indicações do status com base nos dados armazenados na memória da RTU.

[0011] Ainda outra modalidade dessas técnicas é uma RTU para uso em uma planta de processo. A RTU compreende um primeiro módulo de interface configurado para trocar dados com dispositivos de campo de acordo com um protocolo de automação industrial digital, uma memória para armazenar dados indicativos dos respectivos status dos dispositivos de campo, um segundo módulo de interface configurado para se comunicar com um host remoto através de uma rede de comunicação e um módulo de processamento configurado para fornecer, através do segundo módulo de interface, indicações dos respectivos status dos dispositivos de campo com base nos dados armazenados na memória.

BREVE DESCRIÇÃO DOS DESENHOS

[0012] A Fig. 1 é um diagrama de blocos de uma parte de um exemplo de planta de processo ou sistema de controle de processo no qual uma RTU armazena dados de status para dispositivos de campo e fornece dados em cache, ou informações baseadas nos dados em cache, para um host remoto, de acordo com uma implementação das técnicas desta divulgação.

[0013] A Fig. 2 é um diagrama de blocos de um exemplo de host remoto que pode operar no sistema da Fig. 1, e um exemplo de gerenciador de dispositivo acoplado de forma comunicativa ao host remoto.

[0014] A Fig. 3 é um diagrama de fluxo de um método de exemplo para recuperar informações de status para dispositivos de campo de acordo com uma programação configurável, que pode ser implementada no exemplo de host da Fig. 1 ou Fig. 2.

[0015] A Fig. 4 é um diagrama de fluxo de um método de exemplo para gerenciar o status do dispositivo usando uma memória local, que pode ser implementada na RTU da Fig. 1.

DESCRIÇÃO DETALHADA

[0016] A Fig. 1 é um diagrama de blocos de um sistema de exemplo 10 em que uma RTU 12 recolhe dados de status dos dispositivos de campo 20 e fornece indicações dos status correspondentes para um host remoto 14. Os dispositivos de campo 20 podem incluir dispositivos HART com fio HA 20A - 20E e/ou dispositivos HART sem fio 22A - 22D. Os dispositivos de campo com fio 20A-20E podem se comunicar através de ligações com fio 24A - 24C. Os dispositivos HART sem fio 22A-22D operam em uma rede de malha sem fio 26 através de múltiplos ligações de comunicação entre pares de dispositivos. Os dispositivos de campo 20 podem ser qualquer tipo de dispositivos, tais válvulas, posicionadores de válvulas, interruptores, sensores (por exemplo, temperatura, pressão, vibração, taxa de fluxo ou sensores de pH), bombas, ventiladores, etc. Os dispositivos de campo 20 executam funções de controle, monitoramento e/ou físicas dentro de um processo ou circuitos de controle de processo, como abertura ou fechamento de válvulas ou medições de parâmetros de processo, por exemplo. Além dos dispositivos de campo 20, a RTU 12 pode ser acoplada a outras unidades remotas, como adaptadores ou gateways para outras redes, por exemplo.

[0017] A RTU 12 pode ser acoplada ao controle remoto 14 através de uma rede SCADA, que pode incluir ligações com e sem fio, como uma ligação 13. Em um exemplo de implementação, a rede SCADA inclui uma grande rede principal de dados à qual vários hosts, incluindo o host 14, são acoplados. Esses hosts podem incluir estações de trabalho do operador, bancos de dados, historiadores de dados, etc.

[0018] A RTU 12 pode incluir uma unidade de processamento 30, que pode incluir um ou vários processadores de uso geral adequados, microprocessadores ou processadores incorporados. A RTU também inclui uma memória 32, que pode incluir quaisquer componentes de armazenamento persistentes e/ou não persistentes adequados legíveis pelo processador 30, um cartão HART com fio 34 e um cartão HART de cartão sem fio 36. Cada um dos cartões 34 e 36 pode ser configurado para transmitir e receber mensagens que estejam de acordo com o protocolo de comunicação HART. A RTU 12 pode acessar os dispositivos de campo com fio 20A-20E através do cartão 34 e dispositivos de campo sem fio 22A-22D através do cartão 36 e, em pelo menos algumas das modalidades, um ponto de acesso sem fio 40.

[0019] Por simplicidade, a Fig. 1 ilustra apenas uma máquina de host, uma RTU e dispositivos de campo acoplados à RTU através de um cartão com fio e uma placa sem fio. Em geral, no entanto, o sistema 10 pode incluir dispositivos adicionais, ligações de comunicação e redes de comunicação. Por exemplo, o sistema 10 em algumas implementações pode incluir pontos de acesso, gateways para outras plantas de processo (por exemplo, através de uma rede de intranet ou de ampla área corporativa), gateways para sistemas externos (por exemplo, para a Internet), dispositivos de interface de máquina humana (HMI), servidores, sistemas de dados (por exemplo, incluindo bancos de dados de processos, historiadores, etc.), controladores, cartões de entrada/saída (I/O) que operam em controladores, roteadores, redes de comunicação com fio adicionais, redes de comunicação sem fio adicionais, etc.

[0020] A memória 32 pode armazenar instruções de software e/ou firmware, executáveis no processador 30, que implementam um módulo de relatório hierárquico HART 50. Em operação, o módulo 50 formata e transmite comandos HART aos dispositivos de campo 20, recebe respostas aos comandos HART dos dispositivos de campo 20, transmite comandos de passagem entre o host 14 e os dispositivos de campo 20 e solicitações de serviços para dados recebidos do anfitrião 14. Mais especificamente, o módulo 50 pode armazenar informação de status de cache para os dispositivos de campo 20 na memória 32 e, após uma solicitação do host 14, formatar uma mensagem de acordo com um formato desejado para transportar informações de status do dispositivo com base nos dados em cache ou simplesmente encaminhar os dados em cache para o host 14. A operação de exemplo do módulo 50 é discutida com mais detalhes com referência à Fig. 4. Observa-se novamente que os dispositivos HART e os comandos HART são apenas um exemplo de um padrão para a comunicação de informações de controle do processo com as quais as técnicas desta divulgação podem ser usadas.

[0021] O módulo 50 pode armazenar a informação sobre os dispositivos de campo 20 no cache de status de dispositivo HART 52, que pode ser qualquer porção adequada da memória 32. O cache 52 pode ser implementado como uma ou várias tabelas de um banco de dados relacional ou usando qualquer outra estrutura de dados adequada. Em um exemplo de implementação, o cache 52 armazena, para cada um dos dispositivos de campo 20, uma gravação respectiva 60 que indica o status do dispositivo de campo correspondente como uma máscara de bit de status do dispositivo HART, por exemplo. Mais geralmente, o registro 60 pode armazenar dados de status em qualquer formato adequado. Para maior clareza, os bits de uma máscara de bit de status do dispositivo HART são ilustrados e discutidos brevemente na Tabela 1 abaixo. Como um versado comum na técnica reconheceria, a máscara de bits em cada linha especifica como o bit correspondente é extraído (por exemplo, o valor 0x84 mascarado com 0x01 extrai o bit menos significativo, que é zero e o mesmo valor encoberto com 0x02 extrai o segundo bit menos significativo, que é um), e a definição especifica o significado do bit extraído quando o bit é definido. Tabela 1

[0022] Além de coletar dados de status do dispositivo em resposta a um comando do host 14, o módulo 50 ou outro componente que opera na RTU 12 pode manter o cache 52 atualizado com as informações atuais dos dispositivos 20. Em geral, a RTU 12 pode receber atualizações de status iniciadas pelos dispositivos de campo 20 ou pesquisar periodicamente os dispositivos de campo 20 para informações atualizadas, por exemplo.

[0023] O host 14 pode ser implementado de forma semelhante a um cliente/servidor SCADA, ou simplesmente "host" 100 ilustrado na Fig. 2. Agora, referindo-se à Fig. 2, o servidor 100 em geral é um componente de servidor e banco de dados que permite a arquitetura de cliente/servidor, integrando-se a certos clientes SCADA. O servidor 100 também suporta integração com um serviço AMS e suporta integração com componentes de terceiros.

[0024] O servidor 100 pode incluir um componente de interface de dados remoto (RDI) 102 para se comunicar com uma ou várias RTUs através de uma ligação de comunicação 110, que pode ser uma parte de uma rede SCADA. Por exemplo, referindo-se à Fig. 1, a ligação 110 pode corresponder à ligação 13, e o servidor 100 pode acessar a RTU 12 através do RDI 102. A RDI 102 pode ser configurada para coletar periodicamente dados das RTUs de acordo com uma determinada programação, como uma taxa de pesquisa predefinida. Em algumas implementações, o servidor 100 inclui várias instâncias da RDI 102, um para cada tipo de protocolo RTU. Um exemplo de operação da RDI 102 é ainda discutido abaixo com referência à Fig. 3.

[0025] A RDI 102 pode ser acoplada de forma comunicativa a um controlador de comunicação 104 que suporta comunicações de camada inferior através da ligação 110 e a um banco de dados de dispositivo e sistema 106 pode armazenar hierarquia de dispositivo, último status relatado para cada dispositivo de campo, etc. A RDI 102 pode armazenar dados de status recém-recebidos, incluindo alarmes, eventos, etc. no banco de dados do sistema 106, para serem acessados por outros componentes do servidor 100 conforme discutido abaixo. Além disso, em alguns casos, a RDI 102 pode receber dados HART "brutos" de uma RTU, gerar um novo alarme ou evento de acordo com o formato desejado e armazenar o alarme ou evento recentemente formatado no banco de dados 106.

[0026] O servidor 100 também pode implementar um gateway AMS de automação remota 120. Por exemplo, o gateway 120 pode ser parte de um produto RAS (Remote Automation Solutions) oferecido pela Emerson™ Process Management. O gateway 120 pode incluir um servidor XML 122 e um servidor HART/IP 124. O gateway 120 pode ser acoplado de forma comunicativa ao dispositivo e à base de dados do sistema 106. Em operação, o servidor XML 122 pode se comunicar com outro módulo, como um gerenciador de dispositivos AMS 200, via XML em camadas em TCP. O servidor HART/IP 124 pode comunicar dados HART ao gerenciador de dispositivos AMS 200 através de uma ligação TCP/IP.

[0027] Além disso, o servidor 100 pode incluir um Servidor de Alarmes e Eventos OPC 130. O Servidor de Alarmes e Eventos OPC 130 pode fornecer alarmes e eventos para um componente de cliente de Alarmes e Eventos OPC 204 que opera no gerenciador de dispositivos AMS 200 por meio de ligações de Alarmes e Eventos OPC 160. Em outras palavras, o servidor 130 pode fornecer dados de alarmes e eventos armazenados no banco de dados 106 para outros serviços e até mesmo componentes de terceiros usando um padrão industrial amplamente compartilhado.

[0028] O gerenciador de dispositivos AMS 200 pode incluir uma interface de sistema de host de automação de gerenciador/remoto de dispositivo inteligente (HSI), além do cliente OPC A&E 204. Usando os componentes 202 e 205, o gerenciador de dispositivos AMS 200 pode fornecer informações adicionais sobre ativos através de interfaces de usuário apropriadas.

[0029] Note-se que o gerenciador de dispositivos AMS 200 não precisa enviar, receber e processar mensagens para e de dispositivos de campo. Por exemplo, o gerenciador de dispositivos AMS 200 não precisa trocar dados HART com dispositivos de campo: em vez disso, o gerenciador de dispositivos AMS 200 pode acessar informações de status do dispositivo a partir do banco de dados 106, que por sua vez é preenchido usando dados em cache em uma RTU. Desta forma, o número total de mensagens transmitidas através da rede SCADA 13 (ver Fig. 1) é significativamente reduzido.

[0030] Os componentes 102, 104, 106, 120 e 130 podem ser implementados como conjuntos de instruções guardados em uma memória legível por computador e executados por um ou mais processadores. Para evitar desordem, o(s) processador(es) e a memória não são ilustrados separadamente na Fig. 2. A memória do servidor 100 pode ser qualquer meio de armazenamento adequado legível por um ou mais processadores e pode incluir componentes persistentes e/ou não persistentes. O gerenciador de dispositivos AMS 200 pode ser implementado de forma semelhante. Dependendo da implementação, o servidor 100 e o gerenciador de dispositivos AMS 200 podem ser implementados em um único host de computador físico ou hosts separados.

[0031] A Fig. 3 ilustra um diagrama de fluxo de um método de exemplo 300 para recuperar informações de status para dispositivos de campo de acordo com uma programação configurável. O método 300 pode ser implementado no host remoto 14 ou na RDI 102 do servidor 100, por exemplo. Em geral, o método 300 pode ser implementado em qualquer host adequado ou um grupo de hosts. No entanto, para facilitar a ilustração, este método é discutido abaixo com referência à RDI 102.

[0032] O método 300 começa no bloco 302, onde a RDI 102 solicita o status do dispositivo pesquisando a RTU apropriada de acordo com um determinado cronograma. Por exemplo, a RDI 102 pode implementar um temporizador periódico e iniciar uma pesquisa em cada evento de expiração. Conforme indicado acima, o operador pode especificar o cronograma de pesquisa desejado de acordo com suas necessidades e preferências. Além disso, além de configurar o cronograma de votação, o operador pode indicar à RDI 102 qual(ais) RTU(s) deve ser consultada quando o servidor 100 pode acessar várias RTUs, bem como quais dispositivos HART acoplados a uma RTU devem ser consultados. Assim, se uma determinada RTU é acoplada a dois sensores de fluxo e dois sensores de temperatura, o operador pode configurar a RDI 102 para especificar que os sensores de fluxo devem ser consultados a cada 10 segundos, enquanto os sensores de temperatura devem ser consultados a cada 30 segundos. Desta forma, o sistema desta divulgação pode reduzir ainda mais o número de mensagens desnecessárias transmitidas dentro da rede SCADA.

[0033] Assim, a solicitação transmitida no bloco 302 pode pertencer a todos os dispositivos de campo disponíveis na RTU, um grupo específico de dispositivos de campo ou um dispositivo de campo individual especificado, dependendo da implementação.

[0034] No bloco 304, os dados de status solicitados para os dispositivos de campo solicitados são recebidos. Note-se que, a menos que a própria RTU esteja offline, a RDI 102 não encontrará um atraso significativo devido a dispositivos de campo respondendo lentamente ou não. Em particular, a RTU pode determinar se os dispositivos de campo estão respondendo e o que os dispositivos de campo estão relatando, antes de receber a solicitação da RDI 102. Assim, a RDI 102 pode receber a resposta no bloco 304 prontamente, mesmo quando a solicitação pertence a vários dispositivos de campo.

[0035] De acordo com um exemplo de implementação, a RTU contatada no bloco 302 responde com uma máscara de bits para cada dispositivo de campo ao qual a solicitação pertence. Se a máscara de bits não estiver definida, ou seja, se cada bit da máscara de bits for zero, nenhuma informação estava disponível para o dispositivo de campo no cache da RTU. Consequentemente, no bloco 306, a RDI 102 verifica se a máscara de bits está configurada. Se a máscara de bits estiver definida, o fluxo passa para o bloco 308. Caso contrário, o fluxo retorna ao bloco 302 (pelo menos para este dispositivo de campo).

[0036] No bloco 308, a RDI 102 verifica se o bit indicativo da disponibilidade de dados adicionais para o dispositivo de campo está configurado. Referindo-se à Tabela 1 acima, a RDI 102 pode aplicar a máscara 0x10. Se não houver mais dados de status disponíveis para o dispositivo de campo, o fluxo passa para o bloco 314. Caso contrário, o fluxo prossegue para o bloco 310.

[0037] No bloco 310, a RDI 102 recupera as informações adicionais formatando um comando HART apropriado e encapsulando o comando HART para o dispositivo de campo através da RTU. No bloco 312, as informações adicionais são recebidas da RTU.

[0038] Em seguida, no bloco 314, uma descrição de alarme ou evento é formatada usando os dados recebidos no bloco 304 e, quando aplicável, os dados recebidos no bloco 312. Conforme indicado acima, o servidor 100 pode fornecer o alarme ou evento ao operador através de uma interface de usuário apropriada e também disponibilizar o alerta ou o evento gerado para outros serviços, componentes de software de terceiros, etc. O fluxo retorna então ao bloco 302, onde a RDI 102 inicia uma nova pesquisa de acordo com o cronograma.

[0039] Agora, referindo-se à Fig. 4, um método de exemplo 400 para gerenciar o status do dispositivo usando uma memória local pode ser implementado na RTU 12 da Fig. 1, ou qualquer outra RTU adequada. Por conveniência, o método 400 é discutido abaixo com referência à RTU 12.

[0040] O método começa no bloco 402, onde o RTU lê o status do dispositivo de campo. Para este fim, a RTU pode transmitir um comando HART para o dispositivo de campo, cuja resposta inclui uma máscara de bits discutida acima com referência à Fig. 1. Em outras palavras, a RTU 12 pode pesquisar o dispositivo de campo para obter dados de status atuais.

[0041] A RTU 12 pode então armazenar em cache os dados de status recebidos em uma memória local, um bloco 404. Em seguida, no bloco 406, a RTU 12 pode receber uma solicitação das informações de status de um host remoto através de uma rede SCADA. Em resposta, a RTU 12 pode fornecer os dados em cache no bloco 408. Dependendo da implementação, a RTU 12 pode fornecer dados em cache de acordo com o formato no qual o status foi recebido do dispositivo de campo. Em outra implementação, a RTU 12 pode gerar uma mensagem de acordo com um formato diferente, com base nos dados em cache.

[0042] Em alguns cenários, a RTU 12 também recebe um comando em túnel, como o comando HART 48, endereçado ao dispositivo de campo (bloco 408), quando o status armazenado em cache na memória da RTU e relatado ao host remoto indica que informações adicionais está disponível. A RTU 12 avança o comando em túnel, recebe uma resposta (bloco 410) e encaminha a resposta para o comando em túnel para o host remoto através da rede SCADA (bloco 412).

OBSERVAÇÕES GERAIS

[0043] Do que precede, será entendido que as técnicas desta divulgação reduzem o número de mensagens transmitidas através de uma rede SCADA para monitorar informações de status de dispositivos de campo coletando dados de status do dispositivo. Nos exemplos específicos discutidos acima, a RTU armazena informações de status para dispositivos de campo e torna desnecessário em determinadas situações para que o host remoto e os dispositivos de campo troquem diretamente comandos/mensagens HART. Além disso, embora os exemplos acima pertençam principalmente aos dispositivos HART e ao protocolo HART, técnicas semelhantes podem ser usadas com outros protocolos de automação industrial nos quais a informação do status do dispositivo é relatada de maneira similar.

[0044] A menos que exista especificamente o contrário, as discussões que utilizam palavras como "processamento", "computação", "cálculo", "determinação", "identificação", "apresentação", "exibição" ou similares podem se referir a ações ou processos de uma máquina (por exemplo, um computador) que manipula ou transforma dados representados como quantidades físicas (por exemplo, eletrônicas, magnéticas ou ópticas) dentro de uma ou mais memórias (por exemplo, memória volátil, memória não volátil ou uma combinação destes), registradores, ou outros componentes da máquina que recebem, armazenam, transmitem ou exibem informações.

[0045] Quando implementado em software, qualquer das aplicações, serviços, motores, rotinas e módulos aqui descritos podem ser armazenados em qualquer memória legível por computador, tangível e não transitória, como em um disco magnético, disco laser, dispositivo de memória de status sólido, dispositivo de armazenamento de memória molecular, um disco óptico ou outro meio de armazenamento, em uma RAM ou ROM de um computador ou processador, etc. Embora os sistemas de exemplo aqui descritos sejam divulgados como incluindo, entre outros componentes, software e/ou firmware executados em hardware, deve notar-se que tais sistemas são meramente ilustrativos e não devem ser considerados limitativos. Por exemplo, é contemplado que qualquer um ou todos esses componentes de hardware, software e firmware possam ser incorporados exclusivamente em hardware, exclusivamente em software ou em qualquer combinação de hardware e software. Consequentemente, os versados na técnica apreciarão facilmente que os exemplos fornecidos não são o único meio de implementar tais sistemas.

[0046] Assim, embora a presente invenção tenha sido descrita com referência a exemplos específicos, que se destinam a ser apenas ilustrativos e não limitativos da invenção, será evidente para os versados na técnica que mudanças, adições ou deleções podem ser feitas às modalidades descritas sem se afastar do espírito e do escopo da invenção.

Claims (17)

1. Método para monitorar o status de dispositivos de campo que operam em uma planta de processo, o método caracterizado pelo fato de que compreende: receber, em uma unidade de terminal remoto (RTU) acoplada a um dispositivo de campo, dados indicativos de um status do dispositivo de campo; armazenar a informação recebida em uma memória da RTU; receber, na RTU de um host remoto através de uma rede de comunicação, uma solicitação para o status do dispositivo de campo; e fornecer, a partir da RTU para o host remoto em resposta à solicitação, uma indicação do status do dispositivo de campo com base nos dados armazenados na memória da RTU, incluindo fornecer uma máscara de bit para o host remoto; verificar, no host remoto, um status da máscara de bits para determinar se informações adicionais estão disponíveis e solicitar, a partir do host remoto através da RTU, informações adicionais do dispositivo de campo.

2. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que a solicitação é uma de uma pluralidade de solicitações recebidas na RTU do host remoto através da rede de comunicação, o método compreendendo ainda transmitir a pluralidade de solicitações de acordo com uma programação configurável por um operador no host remoto.

3. Método, de acordo com a reivindicação 1 ou 2, caracterizado pelo fato de que a solicitação da informação adicional inclui encapsular uma solicitação para o dispositivo de campo através da RTU.

4. Método, de acordo com qualquer uma das reivindicações 1 a 3, caracterizado pelo fato de que compreende ainda proporcionar, a partir do host remoto, a indicação do status do dispositivo de campo para um sistema de terceiros usando um padrão não proprietário.

5. Método, de acordo com qualquer uma das reivindicações 1 a 4, caracterizado pelo fato de que compreende ainda armazenar, no host remoto, a indicação do status do dispositivo de campo em um banco de dados acessível por uma pluralidade de serviços.

6. Método, de acordo com qualquer uma das reivindicações 1 a 5, caracterizado pelo fato de que a unidade de terminal remoto comunica com o dispositivo de campo através de um protocolo de automação industrial digital.

7. Método, de acordo com qualquer uma das reivindicações 1 a 6, caracterizado pelo fato de que o protocolo de automação industrial digital é HART.

8. Método, de acordo com qualquer uma das reivindicações 1 a 7, caracterizado pelo fato de que a rede de comunicação é uma rede de controle de supervisão e aquisição de dados (SCADA).

9. Sistema para monitorar o status de dispositivos de campo que operam em plantas de processo, o sistema caracterizado pelo fato de que compreende: uma unidade de terminal remoto (RTU) acoplada a uma pluralidade de dispositivos de campo, cada um configurado para executar uma função respectiva em uma planta de processo, em que a RTU inclui: um primeiro módulo de interface configurado para se comunicar de acordo com um protocolo de automação industrial digital, através do qual a RTU recebe dados indicativos dos respectivos status dos dispositivos de campo, uma memória para armazenar os dados recebidos, e um segundo módulo de interface configurado para se comunicar com hosts remotos através de uma rede de comunicação; o sistema compreendendo ainda: um host disposto remotamente da RTU e acoplado à RTU através de uma rede de comunicação, em que o host está configurado para (i) solicitar os status dos dispositivos de campo, e (ii) receber, a partir da RTU, as indicações dos status com base nos dados armazenados na memória da RTU, (iii) verificar um status da máscara de bits para determinar se informações adicionais estão disponíveis no dispositivo de campo correspondente, e (iv) solicitar, através da RTU, informações adicionais do dispositivo de campo.

10. Sistema, de acordo com a reivindicação 9, caracterizado pelo fato de que compreende ainda um banco de dados para armazenar alarmes e eventos relacionados ao dispositivo de campo, em que o host é ainda configurado para (i) gerar alarmes ou eventos com base nas indicações recebidas e (ii) armazenar os alarmes gerados ou eventos no banco de dados.

11. Sistema, de acordo com a reivindicação 9 ou 10, caracterizado pelo fato de que o host está configurado para solicitar os status dos dispositivos de campo de acordo com uma programação configurável por um operador do host.

12. Sistema, de acordo com qualquer uma das reivindicações 9 a 11, caracterizado pelo fato de que a unidade de terminal remoto comunica com o dispositivo de campo através de um protocolo de automação industrial digital.

13. Sistema, de acordo com qualquer uma das reivindicações 9 a 12, caracterizado pelo fato de que a rede de comunicação é uma rede de controle de supervisão e aquisição de dados (SCADA).

14. Sistema, de acordo com qualquer uma das reivindicações 9 a 13, caracterizado pelo fato de que a RTU pesquisa periodicamente os dispositivos de campo para obter os status.

15. Unidade de terminal remoto (RTU) para uso em uma planta de processo, a RTU caracterizada pelo fato de que compreende: um primeiro módulo de interface configurado para trocar dados com dispositivos de campo de acordo com um protocolo de automação industrial digital; uma memória para armazenar dados indicativos dos respectivos status dos dispositivos de campo, os dados incluindo máscaras de bit relatadas pelos dispositivos de campo; um segundo módulo de interface configurado para se comunicar com um host remoto através de uma rede de comunicação; e um módulo de processamento configurado para fornecer, através do segundo módulo de interface, indicações dos respectivos status dos dispositivos de campo com base nos dados armazenados na memória em respostas a comandos do host remoto, em que um status para um dos dispositivos de campo indica que informação adicional está disponível no dispositivo de campo correspondente, um comando em túnel do host remoto endereçado para o um dos dispositivos de campo, e um comando de túnel do um dos dispositivos de campo para o host remoto.

16. RTU, de acordo com a reivindicação 15, caracterizada pelo fato de que o módulo de processamento está configurado para fornecer as indicações dos respectivos status em resposta a comandos do host remoto.

17. RTU, de acordo com a reivindicação 15 ou 16, caracterizada pelo fato de que a rede de comunicação é uma rede de controle de supervisão e aquisição de dados (SCADA).