Sistema de Pesagem LT8RFID

NegociávelAtualização em11/26

Modelo

Natureza do fabricante: Produtores

Categoria do produto

Local de origem

Consulta Online

Visão geral

LT8RFID sistema de pesagem de identificação de rádio-frequência sem fio (sistema de pesagem RFID) é uma tecnologia rápida, em tempo real e precisa de coleta e processamento de informações de pesagem, identificação única e eficaz de objetos físicos através de sinais de rádio-frequência, que pode ser amplamente utilizado em produção, varejo, logística, transporte, saúde, defesa, pecuária, mineração e outras indústrias.

Detalhes do produto

Sistema de Pesagem LT8RFID

A tecnologia de identificação de radiofrequência sem fio (sistema de pesagem RFID) é uma tecnologia rápida, em tempo real e precisa de coleta e processamento de informações de pesagem, identificação única e eficaz de objetos físicos através de sinais de radiofrequência, que pode ser amplamente usada em vários setores como produção, varejo, logística, transporte, saúde, defesa, pecuária e mineração. O sistema básico de pesagem RFID é geralmente composto por três partes: etiquetas, leitores e software de suporte à aplicação. O middleware é um componente importante do software de suporte de aplicativos e é uma ponte entre dispositivos de pesagem de hardware, como etiquetas, leitores e aplicativos empresariais, como planejamento de recursos empresariais (ERP), gerenciamento de relacionamento com o cliente (CRM), etc. A principal tarefa do middleware é filtrar, agregar, calcular e agrupar os dados relacionados com as etiquetas do leitor, reduzir a grande quantidade de dados brutos transmitidos do leitor para o aplicativo empresarial e gerar dados de eventos com interpretação semantica adicionada. Pode-se dizer que o middleware é o "centro nervoso" do sistema de pesagem RFID. Para o design do middleware do sistema de pesagem RFID, há muitas questões a serem consideradas, como: como implementar muitas propriedades de qualidade do software, como implementar o isolamento do middleware do dispositivo de pesagem de hardware, como lidar com a relação com a função de gerenciamento de dispositivos, como implementar o processamento de dados de alto desempenho e muito mais.
1, estrutura de estrutura de rede do sistema de pesagem RFID, dados de etiqueta são relatados ao sistema de aplicação através do processamento de agrupamento, filtragem e outros middleware; O sistema de aplicativos é responsável pelo armazenamento persistente de dados de eventos e pelo gerenciamento de informações de negócios ligadas a etiquetas. A plataforma de serviço público compartilhado de sistemas de pesagem RFID oferece serviços públicos como o serviço de nome de objeto de nó raiz (ONS), gerenciamento de autenticação de aplicativos empresariais, descoberta de informações de etiquetas e gerenciamento de códigos de autorização empresariais. Entre eles, o nó raiz ONS, juntamente com o ONS interno de todos os sistemas de pesagem RFID de nível empresarial, forma uma árvore ONS, e qualquer etiqueta pode encontrar o endereço da base de informações da etiqueta correspondente à etiqueta na árvore ONS, o que permite mais acesso aos detalhes da etiqueta correspondente.
Função do middleware e princípio de implementação Em suma, a função do middleware é aceitar a solicitação do sistema de aplicativos, iniciar comandos operacionais para um ou mais leitores especificados, como contagem de etiquetas, gravação de dados de identificação de etiquetas, leitura e escrita de áreas de dados de usuários de etiquetas, bloqueio de dados de etiquetas, matança de etiquetas, etc., e receber, processar e relatar dados de resultados para o sistema de aplicativos em segundo plano. Entre eles, a lista de etiquetas é a função mais básica e mais amplamente utilizada.
2.1 Descrição geral da função de inventário de etiquetas, o fluxo de trabalho do inventário de etiquetas pode ser descrito de forma simples como: o sistema de aplicação define as necessidades de dados de etiquetas na forma de regras, as regras são apresentadas pelo sistema de aplicação ao middleware e mantidas pelo middleware. As regras definem quais dados de inventário de leitores são necessários, as condições de início e fim do ciclo de relatório de dados de rótulo (ciclo de eventos), como os dados de rótulo são filtrados, como os dados de rótulo são agrupados, se os dados de relatório são dados de inventário originais, dados de rótulo adicionados ou dados de rótulo reduzidos, quais dados originais os dados de rótulo contêm, etc. O sistema de aplicação especifica uma regra que oferece ao middleware uma reserva para os dados da etiqueta. O middleware inicia o ciclo de eventos e emite o comando de contagem de etiquetas ao leitor, de acordo com a reserva de dados de etiquetas do sistema de aplicação. O leitor envia para o middleware os dados listados em um determinado período de tempo (ciclo de leitura). O ciclo de leitura pode ser determinado por negociação privada entre o middleware e o leitor. O middleware recebe os dados enviados pelo leitor. O middleware filtra, agrupa, acumula, etc., os dados recebidos de acordo com a definição da regra e, no final do ciclo de eventos, gera relatórios de resultados de dados de acordo com a regra e envia-os ao reservante da regra. O processo de filtragem elimina dados duplicados e dados que não interessam ao sistema de aplicação, reduzindo significativamente a quantidade de dados transferidos entre os componentes.
É necessário explicar o conceito de leitor lógico. O middleware abstrai a fonte de eventos em um conceito lógico - um leitor lógico, que pode conter vários leitores físicos ou até mesmo ser refinado em múltiplas antenas que contêm vários leitores físicos. A divisão de leitores lógicos pode ser determinada de acordo com a implementação real do sistema, por exemplo, um armazém com duas saídas distribuído quatro leitores, os quatro leitores podem ser configurados como um leitor lógico, como necessário. Os sistemas de aplicativos podem emitir comandos de inventário com base nesse leitor lógico quando precisarem de dados de etiqueta exportados pelo armazém, com o nome do leitor lógico como parâmetro para a chamada de uma API parcial.
2.2 Princípios de Implementação do Invento de Etiquetas Como mencionado anteriormente, as regras são um elemento-chave de toda a funcionalidade do middleware. As regras são equivalentes a um pedido emitido pelo sistema de aplicação para o middleware e definem os requisitos para o tempo (ciclo de eventos) e as especificações (como filtrar, agrupar, estilo de relatório, etc.) dos produtos (dados de etiqueta), com referência parcial ao conteúdo relacionado com o EPCglobal. As regras e relatórios têm seu próprio modelo de informação que caracteriza a informação que eles carregam, enquanto as regras têm seu próprio modelo de máquina de estado. Ao aceitar reservas de longo prazo e únicas do sistema de aplicativos, essas operações de reserva provocam mudanças de status nas regras, como a transição do estado "não solicitado" para o estado "solicitado". As regras são definidas pelo sistema de aplicação através da API.
(1) Modelo de Informação de Regra O modelo de informação de regra é descrito usando a Linguagem de Modelagem Unificada (UML), como mostrado na Figura 3. Figura 3 Em um contexto orientado a objetos, uma regra pode ser caracterizada como uma classe (ECSpec). A descrição do modelo de informação mostra que uma classe de regra está associada a várias outras classes, ou possui as seguintes propriedades: uma lista de leitores lógicos (readers), definições de limites de ciclo de eventos (boundaries), definições de um ou mais relatórios (reportSpecs) e marcas para incluir a própria regra no relatório (includeSpecInReports).
(2) Modelo de Informação de Relatório É semelhante ao modelo de informação de regra, onde as classes de relatório de grupo de eventos (ECReports) possuem os seguintes atributos: nome da regra (specName), data, duração do ciclo de eventos (totalMilliseconds), condição de fim do ciclo de eventos (terminaonCondition), instância de classe de definição de regra (spec), lista de instâncias de uma ou mais classes de relatório (reports). A classe de relatório (ECReport) contém informações específicas sobre os dados da etiqueta.
(3) Solicitações de regras definidas, dados de reserva, etc. feitas pelo sistema de aplicação da API de inventário de etiquetas são concluídas chamando a API fornecida pelo middleware. O processo de chamada de API pode ser implementado usando tecnologias específicas relacionadas, como Java RMI, SOAP, e as APIs mais importantes estão na Tabela 1. Tabela 1: Interface do aplicativo de inventário de etiquetas. onde a operação poll é equivalente a uma operação subscribe que chama a operação unsubscribe após receber dados de um ciclo de eventos; A operação immediate é equivalente à operação define, depois de definir a regra, chamando a operação poll e, em seguida, chamando a operação undefine.
(4) Modelo de máquina de estado de regra Regras podem existir em três estados, a partir da sua definição: não solicitado, solicitado e ativo. Quando a regra foi criada e ainda não foi reservada por nenhum cliente (ou seja, o sistema de aplicativos), a regra está no estado Unrequested; A primeira ação de reserva da regra faz com que a regra salte para o estado Requested; Quando as condições do início do ciclo de eventos são cumpridas, a regra entra no estado Ativo; Quando as condições do fim do ciclo de eventos são cumpridas, se a regra tiver um reservador, é transferido para o estado Requested ou, caso contrário, para o estado Unrequested.
O sistema de middleware como um sistema de software (ou componente), além da realização de certas funções e requisitos de desempenho, compreensível, escalável, modificável (ou refigurável), inserível, reutilizável e outros atributos de qualidade serão apresentados como requisitos de design de software. Durante quase uma década, o pensamento orientado a objetos ocupa quase toda a área de design de software, tornando-se o método de análise e design mais popular. Nos últimos anos, a pesquisa sobre padrões de design também se aperfeiçoou, tornando-se quase uma "linguagem de programação mais avançada" (em comparação com linguagens de programação avançadas como Java e C ++). Pensamento orientado a objetos, padrões de design são para implementar o software compreensível, escalável, modificável, inserível, reutilizável e outros objetivos, este artigo também aplicará o pensamento orientado a objetos, linguagem de padrões de referência, para fazer uma exploração preliminar da arquitetura de software do middleware, os exemplos abaixo, como envolvendo a linguagem de programação avançada, estão usando a linguagem Java.
3.1 Os nós no processo de processamento de embalagem e isolamento dividem os nós no processo de negócios do middleware em diferentes módulos para obter as vantagens de embalagem, alta agregação e baixa acoplamento, veja Figura 5. Figura 5: Divisão de módulos de sistema de middleware. Entre eles, o módulo de upload de relatórios é responsável por implementar diferentes tipos de métodos de upload de relatórios, como HTTP, JMS, etc. Módulo de interface API, responsável por isolar o sistema de aplicativos e o módulo de processamento lógico de negócios do núcleo do middleware, fornecendo uma interface API de middleware para o sistema de aplicativos; Módulo de processamento lógico do negócio central do middleware, responsável pelo negócio central do middleware, incluindo filtragem de recepção de dados, agrupamento de dados, geração de relatórios, salto de estado do objeto de regra, etc.; Módulo de comunicação do leitor, responsável pela comunicação entre o sistema de middleware e o leitor.
3.2 Modo de fachada, modo de fábrica para exposição externa à interface API Para evitar o acoplamento excessivo do sistema de aplicações de fundo, ou seja, o cliente do middleware, o uso do modo de fachada (Facade) para alcançar um isolamento claro dentro e fora do sistema. O processo de processamento pode ser visto no diagrama de sequência mostrado na Figura 6. O cliente simplesmente se conecta com a classe Facade e, se a interface Facade for definida claramente o suficiente, o cliente não sabe nada sobre a implementação interna do middleware, o que reflete a encapsulabilidade orientada a objetos.
3.5 Modo de observador para processar a mensagem de relatório A mensagem de relatório do leitor é convertida em objeto de mensagem, e a recepção e distribuição do objeto de mensagem podem ser realizadas pelo modo clássico de observador.

Produto semelhante Recomendar