conversão de protocolo / normalização: BizTalk, alternativas?

Question

Temos uma necessidade de tomar dezenas de diferentes protocolos de sistemas, tais como sistemas de segurança, alarmes de incêndio, sistemas de câmera etc .. e integrá-los em um único protocolo comum.

Gostaria que este seja um servidor de mensagens que muitos sistemas poderiam subscrever e ou comunicar através de.

• polling e não-polling "drivers" (conversores de protocolo)
• alça RS232 / RS485 / tcp
• programáveis ??"drivers" em uma linguagem gerenciada como Java ou C #
• capacidade de motor de regras

BizTalk encaixar isso?

Existem alternativas de código aberto?

Existe uma maneira Java / Java EE para fazer isso?

Em uma extremidade do sistema seria um sistema SCADA, no outro é é uma espécie de / servidor de mensagens middleware.

Qualquer pensamento sobre a melhor maneira de proceder seria apreciada. Eu sei que haverá uma quantidade considerável de programando envolvido no lado do motorista, no entanto, tentado como eu sou, a construção de todo o sistema a partir do zero não seria apropriada.

Answer 1

Se você não se importa que trabalha na plataforma Java há um switcher protocolo leve e implementação do Patterns Enterprise Integration em um projeto open source chamado Apache Camel .

Camel já pode falar a maioria dos protocolos comuns e tecnologias como arquivos , email , JMS , < a href = "http://activemq.apache.org/camel/xmpp.html" rel = "nofollow noreferrer"> XMPP e assim por diante de modo que não haveria real necessidade de codificação para essas coisas.

Para adicionar novos protocolos personalizados a rota mais simples é construir em cima do MINA componente que se encarrega de toda a rede, manuseamento soquete, rosqueamento e assim por diante (por exemplo NIO contra BIO et ai).

Então você acabou de estendê-lo para adicionar seu próprio codec protocolo (como marechal / mensagens desempacotar no soquete com possivelmente usando enquadramento etc).

O componente HL7 é um exemplo de fazer isso. Mais detalhes sobre como escrever codecs MINA aqui .

Então uma vez que você tem a sua componente de camelo (vamos chamá-lo foo), você poderia, então, construir uma ponte de qualquer protocolo para qualquer outro protocolo usando URIs simples de implementar qualquer um dos Patterns Enterprise Integration como Content Based Router , lista de destinatários , Roteamento etc

por exemplo. em código Java

// route all messages from foo
// to a single queue on JMS
from("foo://somehost:1234").
  to("jms:MyQueue");

// route all messages from foo component
// to a queue using a header
from("foo://somehost:1234").
  recipientList().
    simple("activemq:MyPrefix.${headers.cheese}");

Answer 2

Gostaria de evitar BizTalk para SCADA e RS232 / RS485, porque estes geralmente requerem tempo real soluções (ou, pelo menos, baixa latência). BizTalk está optimizado em alta throughtput, mas tem a desvantagem de ter alta latência por padrão.

Você pode ajustar BizTalk para baixa latência, mas neste momento você vai achar que você ignorar quase tudo BizTalk foi construído com e provavelmente iria ficar no caminho, em vez de ajudá-lo.

Answer 3

www.livedata.com

É um pouco caro, mas é um motor baseado em Python que pode ter um protocolo e cuspir para fora um outro, já é configurado para vários protocolos SCADA tais como ICCP, Modbus, OPC, e DNP fora da caixa. Então você pode falar o que quiser a jusante.

• John

Answer 4

OpenSCADA . O site é no momento um pouco de confusão, mas o software está ativamente em uso e em desenvolvimento ativo. Um objetivo explícito é criar um comum, independente de tecnologia, interface para casos de uso SCADA (embora no momento a direção é mais ou menos orientado para java [mas nós experimentar também com ikvm para criar uma versão .NET]).

Então, você poderia usar OpenSCADA para se comunicar com todos os dispositivos de "hardware" e, em seguida, criar uma ponte para o resto do seu middleware, ou criar uma ponte OpenSCADA como um plugin no seu middleware. Nós já temos para os motoristas exemplo que se conectam a leitores de cartões ligados através de um servidor de série para a LAN.