A Função dos Modelos Semânticos nas Operações Industriais Mais Inteligentes

Desenvolvedores e arquitetos de soluções têm muitas opções de arquitetura à disposição. Os arquitetos podem aproveitar os padrões arquiteturais baseados no design orientado a dados, a serviços, a mensagens e outros. Naturalmente, esses padrões não são mutuamente exclusivos e frequentemente usamos os componentes em conjunto no design de soluções. Neste artigo, abordamos as arquiteturas de modelo semântico e descrevemos a abordagem do modelo semântico e como ele se ajusta ao contexto de outros padrões de arquitetura. Destacamos o valor dos modelos semânticos como um componente principal no design de soluções e mostramos como o IBM Integrated Information Core permite a criação de soluções integradas ao modelo.

Tim Hanis, Chief Architect, IBM Integrated Information Core, IBM

Author photoTim Hanis é o arquiteto chefe do produto IBM Integrated Information Core. Ele trabalha no desenvolvimento de produto de software na organização Industry Solutions no Research Triangle Park, NC. Ele liderou vários projetos de desenvolvimento com grupos de software da IBM e com desenvolvimento e implementação de solução do cliente. Tim tem ampla experiência em auxiliar clientes na resolução de problemas de negócios com os produtos IBM.


nível de autor Contribuidor do
        developerWorks

Dave Noller, Senior Architect, Industrial Sector Solutions, IBM

Photo of Dave NollerDave Noller tem 27 anos de experiência em desenvolvimento de software para aplicativos de fabricação e integração empresarial. Durante sua carreira, ele trabalhou em sistemas de fabricação na IBM e também com clientes nos segmentos farmacêutico, automotivo, químico e petrolífero. Ele arquitetou, projetou e implementou o Manufacturing Execution Systems (MES) para IBM, um middleware voltado para a integração de aplicativo empresarial. Atualmente, Dave está trabalhando como arquiteto chefe de soluções para a Industrial Sector Frameworks na IBM. Ele é membro da APICS, onde é certificado com CPIM e do MESA Technical Committee e Senior Certified IT Architect na IBM. Dave é formado em engenharia matemática e sistemas de computação pela Universidade Central da Flórida e possui mestrado em ciências de engenharia industrial pela Universidade Purdue.



31/Ago/2012

Introdução

Normalmente, descrevemos três elementos críticos na discussão sobre as soluções mais inteligentes do planeta. Os três "i", como às vezes são conhecidos, são "instrumentado", "inteligente" e "interconectado". Suportam a ideia de que há uma grande quantidade de dados no mundo, que podemos coletar e usar para gerar inteligência e, a partir disso, podemos ajudar a impulsionar uma otimização envolvendo tarefas de negócios críticas. O importante nessa abordagem é a análise e compreensão dos dados provenientes de muitas fontes em uma ampla variedade de formatos e contextos.

As soluções devem ser projetadas para manipular esses tipos de dados heterogêneos, como dados estruturados e não estruturados, dados de sensor (valor atual e histórico), imagens, áudio e vídeo. Além de não se ajustar bem às estruturas padrão de persistência relacional, eles também são difíceis de contextualizar.

Considere um aplicativo de tráfego municipal mais inteligente. Sensores de semáforo, sensores de velocidade do departamento de transporte e câmeras de vídeo fornecem dados de tráfego em tempo real. Dados adicionais que são críticos para uma previsão precisa do fluxo de tráfego podem vir de diversas fontes, como relatórios meteorológicos, relatórios de acidentes, interrupções no trânsito, eventos de calendário (como feriados), tendências sazonais (como o trânsito para o litoral), eventos especiais (como desfiles, festivais ou grandes eventos esportivos), eventos de envio de emergência e fatos jornalísticos significativos. Precisamos entender todos esses dados no contexto e o relacionamento entre os eventos.

Além disso, precisamos de uma compreensão comum dos eventos que podemos consultar dessas várias fontes. Por exemplo, termos básicos como veículo podem se tornar ambíguos entre provedores de fontes de dados se considerarmos distinções como carros, caminhonetes, carretas, ônibus ou motocicletas. Algumas características, como eixos ou ocupantes, podem assumir distinções importantes. E, obviamente, os dados relevantes que precisamos reunir mudam continuamente.

A modelagem semântica pode ajudar a definir os dados e os relacionamentos entre essas entidades. Um modelo de informação fornece a capacidade de abstrair tipos diferentes de dados e fornece uma compreensão de como os elementos dos dados se relacionam. Um modelo semântico é um tipo de modelo de informação que suporta a modelagem de entidades e seus relacionamentos. O conjunto total de entidades do nosso modelo semântico constitui a taxonomia de classes que usamos no modelo para representar o mundo real. Juntas, essas ideias são representadas por uma ontologia - o vocabulário do modelo semântico que fornece a base sobre a qual se formam as consultas definidas pelo usuário. O modelo suporta a representação de entidades e seus relacionamentos e pode suportar as restrições desses relacionamentos e entidades.Isso fornece a composição semântica do modelo de informações.

No nosso exemplo, um modelo semântico poderia ajudar a entender relações como as dos sensores de semáforo com as intersecções que eles monitoram, qualquer sensor de semáforo com outros sensores na mesma estrada ou a relação das estradas sobre as quais temos dados de sensor específicos com outras estradas que as cruzam e, coletivamente, como alimentadores para as principais rodovias. O modelo também pode gerar informações parecidas sobre linhas de ônibus ou de metrô. Pode descrever os tipos de serviço disponíveis com os locais atendidos. As relações entre as estações e endereços e linhas de serviço e rotas de carro forneceriam a base para entender as implicações sobre o tráfego rodoviário de perturbações específicas no serviço de transporte coletivo.

Outra complicação é a possibilidade de que um único aplicativo precise interagir com vários modelos de domínio (ou ontologias de domínio). Um método de conseguir isso é unir ontologias existentes em uma nova ontologia. Não é necessário mesclar todas as informações de cada ontologia original, pois talvez não seja possível atender a essa integração logicamente. Além disso, a nova ontologia pode apresentar novos termos e relações que servem para vincular os itens correspondentes a partir das ontologias de origem. Mais adiante neste artigo, veremos como os modelos semânticos se encaixam em um exemplo.

A compreensão fornecida por meio dos modelos semânticos é fundamental para poder conduzir apropriadamente os insights corretos a partir da instrumentação monitorada que, em última análise, pode levar a processos de negócio — ou, nesse caso, serviços municipais — otimizados. Consequentemente, os modelos semânticos podem aumentar muito a utilidade das informações obtidas por meio das soluções de integração de operações.


Rumo à integração de operações baseada no modelo

Figura 1. Evolução da integração dos sistemas de operações
Evolução da integração dos sistemas de operações

Com o passar dos anos, várias abordagens de arquitetura foram definidas para a integração de sistemas e para a representação das informações e processos. Isso incluía abordagens orientadas a dados, mensagens, serviços e informações. Queremos explorar as diferenças e relações entre essas abordagens, qual é o lugar dos modelos semânticos do ponto de vista da arquitetura e o valor que eles fornecem como componente chave da arquitetura de integração de operações. Na próxima seção, veremos como as abordagens arquitetônicas evoluíram e posicionaremos a integração de modelos semânticos em relação a essas várias abordagens.

Propriedade centralizada dos dados

O aplicativo centralizado é proprietário dos dados

Nesse caso, um aplicativo centralizado é proprietário dos dados e outros aplicativos fazem chamadas diretas para obter informações ou solicitar que o aplicativo chamado realize alguma ação. Historicamente, isso envolvia a chamada direta de outro aplicativo por meio de interfaces de programa de aplicativo (APIs) ou chamadas de função remota (RFCs) contidas em uma biblioteca cliente à qual o aplicativo de chamada estaria vinculado. O aplicativo de chamada, nesse caso, é responsável por entender a semântica do aplicativo chamado e por todas as transformações de dados. Embora seja rápida — do ponto de vista do desempenho — essa abordagem mostrou-se cara em termos de manutenção (além de frágil, já que a falha em um aplicativo tem um efeito propagador em todos os aplicativos diretamente conectados entre si).

Um exemplo desse tipo de compartilhamento de informação seria um aplicativo cliente que chama diretamente uma Business Interface de Programação de Aplicativos (BAPI) de Service Advertising Protocol (SAP) por meio de uma chamada de função remota.

Arquitetura centrada nos dados

Uma alternativa ao aplicativo centralizado como proprietário dos dados é a arquitetura centrada nos dados — que pode ser considerada um passo à frente em relação à abordagem de conectividade direta, já que os aplicativos não se conectam diretamente entre si para trocar informações. A arquitetura centrada em dados tem base na definição de dados de negócios relevantes em torno dos quais os sistemas são integrados e os aplicativos são desenvolvidos. Em termos simples, as arquiteturas centradas em dados estabelecem um modelo de dados comum para um armazenamento de dados centralizado, e os aplicativos cliente interoperam por meio desse armazenamento de dados centralizado.

Novamente, o aplicativo de Planejamento de Recursos Empresariais (ERP) do SAP é um exemplo precoce dessa abordagem. Qualquer pessoa que tenha trabalhado com representações anteriores do SAP percebeu que ele era (ou pelo menos parecia) basicamente um conjunto de aplicativos desenvolvidos para interagir em torno de um modelo de dados central. Embora o SAP suportasse outras abordagens à integração para aplicativos externos, o SAP em si tinha adotado uma abordagem centrada nos dados para a comunicação intra-aplicativos.

Essa abordagem à integração, apesar de ser inerentemente simples, ainda tem como resultado um sistema fortemente acoplado no qual todos os componentes do sistema são afetados por mudanças no modelo de dados (e têm um ponto único de falha no armazenamento de dados compartilhado).

Propriedade distribuída dos dados

Arquiteturas baseadas em sistemas de mensagens

Uma arquitetura orientada a sistema de mensagens normalmente se baseia em dois componentes complementares:

  • Um modelo de interação que define padrões como comandos, solicitação/resposta ou pub/sub
  • Um modelo de dados do conteúdo a ser trocado

Ambos poderiam aproveitar os padrões do segmento do mercado. O Serviço de Mensagens Java™ (JMS), por exemplo, que faz parte da especificação Java EE, define uma API que pode ser usada para a normatização do modelo de interação para aplicativos. Entretanto, o JMS não diz nada sobre o conteúdo das informações a serem trocadas entre os aplicativos.

A arquitetura orientada a mensagens destina-se a trocar informações (documentos), em que não há uma semântica implícita sobre o que deve ser feito com os documentos recebidos. O que essa definição significa? Significa que a arquitetura orientada a mensagens se destina ao compartilhamento de informações em larga escala. Os registros de cotações da bolsa são um exemplo disso. Uma empresa de serviços financeiros terá um backbone de arquitetura orientada a mensagens (por exemplo, TIBCO, MQ ou MSMQ) para distribuir mudanças nos valores de ações em qualquer aplicativo no qual esteja interessado. Ele não determina o que a pessoa irá fazer depois de saber que a ação sofreu uma mudança - somente informa que ela ocorreu. De acordo com essa definição, a arquitetura orientada a mensagens é usada principalmente para a sincronização de dados e notificação de eventos. Consequentemente, com frequência ela se baseia em pub/sub.

Também podemos basear o modelo de dados para trocar informações sobre padrões do segmento de mercado. Os exemplos incluem EDI (electronic data interchange), B2MML (implementação XML do padrão ISA-95) e BatchML (implementação XML do padrão ISA-88). Observe que o modelo de dados usado aqui também pode ser usado para o modelo de dados que discutimos anteriormente na seção "Arquitetura centrada nos dados".

Outro exemplo de modelo de dados é o Open Applications Group Integration Specification (OAGIS). Ele define Documento de Objeto de Negócios (BODs) para informações como Itens, Listas de materiais, Pedidos de produção e mais. Cada um desses BODs tem uma área de aplicativo (cabeçalho) e uma área de dados. Ambas as seções de um BOD são formadas por campos e estruturas de dados com base em um vocabulário padronizado (fundamentado parcialmente nos Componentes principais de UN/CEFACT e publicado como parte do padrão OAGIS). Os BODS podem ser estendidos (de uma forma padronizada) pelos usuários e representados (para troca de dados) como documentos XML (parecido com BATCHML e B2MML). Dessa forma, o próprio padrão OAGIS pode servir como o modelo de informações para a troca de dados (e pode ser usado como o conteúdo para um modelo de interação com base em JMS) como mostra a Figura 2. Em outras palavras, pode-se usar o padrão OAGIS para fornecer os nomes nas ontologias, conforme descrito posteriormente neste artigo. (O padrão implica as relações, mas não as define explicitamente.)

Figura 2. Cenário do OAGIS "da produção para a manufatura"
Cenário do OAGIS

Arquitetura orientada aos dados

Rajiv Joshi, no artigo "Data-Oriented Architecture: Loosely Coupling Systems into Systems of Systems" (consulte Recursos), argumenta que a arquitetura orientada a dados é a melhor maneira de integrar sistemas em tempo real. Ele descreve o barramento de dados como um componente importante da arquitetura para suportar essa abordagem. O barramento de dados é um complemento para o barramento de serviço corporativo (ESB), que é um componente base de uma arquitetura orientada ao serviço.

O Grupo de Gerenciamento de Objetos (OMG) publicou uma especificação que descreve uma abordagem para a realização de uma arquitetura orientada aos dados chamada Padrão de Distribuição de Dados (consulte Recursos). A especificação define APIs para a troca em tempo real em um modelo pub/sub independente de plataforma.

A especificação OLE for Process Control (OPC) é voltada para a mesma questão — ou seja, fornecer um meio neutro em relação ao fornecedor e ao dispositivo de obter dados em tempo real sobre o status da produção e os ativos associados — e tem muito mais aceitação no segmento de mercado.

Enterprise application integration (EAI) (troca de dados com broker)

A abordagem arquitetônica do EAI se baseia nas abordagens orientadas a mensagens para lidar com o problema dos aplicativos que precisam conter muito conhecimento sobre questões como as seguintes:

  • Aplicativos que precisam de comunicação para solicitações/informações específicas
  • Protocolo para interagir com outro aplicativo
  • Requisitos de transformação de dados para interagir com outro aplicativo

O EAI apresenta uma infraestrutura adicional de integração para separar esses interesses dos aplicativos participantes, como um message broker (por exemplo, WebSphere Message Broker ou Microsoft® BizTalk) que podem manipular roteamento de mensagem, transformação e gerenciamento de transações em nome dos aplicativos que estão sendo integrados. Normalmente, isso é combinado com o uso de padrões do sistema de mensagens (por exemplo, OAGIS) para apresentar uma forma canônica para a integração, tratando das questões identificadas anteriormente.

Arquitetura Orientada a Serviços

Os serviços fornecem uma abordagem padronizada para interoperação entre aplicativos ou componentes de aplicativo. Os serviços e aplicativos podem ser implementados em sistemas diferentes e executar em plataformas diferentes (J2EE, Windows®, Linux). O serviço deve ser uma camada de abstração, semelhante ao CORBA IDL no passado, que permite aos aplicativos interagir de forma independente da plataforma, sem necessidade de conhecer a implementação ou até mesmo o local do provedor de serviços. Os principais elementos que uma arquitetura orientada a serviços (SOA) frequentemente inclui são:

  • Provedor de serviços – um componente da arquitetura que presta serviços para os consumidores
  • Consumidor do serviço – um componente (cliente) que está consumindo serviços
  • Barramento de serviço corporativo – o barramento de integração por meio do qual os serviços são invocados e as informações que fluem entre os componentes são mediadas
  • Registro de serviço – fornece um registro e serviço de consulta para os serviços que existem dentro de um sistema baseado em SOA. Pode incluir serviços de consulta de livros e de chamada.
  • Coreografia de processos – um elemento importante da SOA é que os processos de negócios compostos, fluxos de serviços, podem ser coreografados de forma gerenciada em vários aplicativos.

A SOA é diferente da arquitetura centrada nos dados e da arquitetura orientada a mensagens porque não há um foco no fluxo das informações entre os serviços, nem um modelo predefinido. Em vez disso, a meta da SOA é fornecer uma abordagem de arquitetura para a criação de aplicativos compostos, que são formados por um conjunto de processos de negócios compostos envolvendo os aplicativos que estão sendo integrados.

Na SOA, o consumidor interage com um provedor com um propósito bem definido (por exemplo, processar um pedido). As informações são muito específicas para a tarefa e não mudam com frequência. As mudanças nas informações muitas vezes exigem novas versões de provedores de serviços para suportar novos consumidores com novos tipos de informações.

Arquitetura orientada às informações

As abordagens arquitetônicas anteriores podem se complementar e o seu uso em conjunto pode fazer sentido. A arquitetura orientada às informações estende a SOA para incluir uma visualização canônica (e acesso) das informações no sistema que está sendo integrado ao serviço como base para a inteligência de negócios e analítica para dar suporte à otimização de processos e melhoria da tomada de decisões. Esse tipo de arquitetura oferece a base para compor processos de negócios que, em conjunto, criam aplicativos compostos em torno de um modelo de informações. Esse modelo define a forma canônica para a troca de dados – em outras palavras, define o lado canônico das mediações de dados.

A arquitetura orientada às informações normalmente inclui o gerenciamento de dados mestres (MDM) e ferramentas de inteligência de negócios como complemento para a SOA. Robin Bloor, em uma postagem no blog Data Integration (consulte Recursos), indica que uma arquitetura orientada às informações também pode incluir um mapa de dados semânticos, que pode ajudar a contextualizar as informações que estão sendo acessadas no MDM e os aplicativos integrados. Essa ideia é condizente com a premissa básica deste artigo — embora as abordagens arquitetônicas descritas anteriormente tenham sido úteis em muitas implementações, falta a elas, graus variados, o "contexto" das informações que estão sendo utilizadas. A SOA, combinada com mensagens baseadas em padrões (por exemplo, OAGIS, B2MML e BATCHML), fornece a capacidade de criar e integrar processos compostos e aplicativos para serviços como gerenciamento de pedidos ou rastreamento da produção. Entretanto, mesmo assim não há contexto sobrejacente para as informações que podem ser solicitadas por aplicativos clientes.

A arquitetura orientada às informações pode fornecer esse contexto por meio de um modelo sobrejacente do mundo real que fornece um contexto para as solicitações de informações. Dessa forma, solicitações, serviços associados, definições de dados, e outros, podem ser associados a um objeto no modelo que definirá o seu significado e dará o seu contexto. Por exemplo, pode-se criar um modelo para uma empresa com base em padrões do mercado, como ISA-95 e ISA-88, que pode ser usado para definir a hierarquia corporativa de uma plataforma de perfuração de petróleo. Esse modelo, no nível mais baixo da hierarquia, pode conter instâncias de equipamento, como bombas ou motores, que podem ser associadas às solicitações de informações e ações. Em seguida, essa associação fornece o contexto para suportar consultas como "localize as ordens de serviço disponíveis para essa bomba", "informe a temperatura atual desse motor" ou "calcule o valor médio do pH neste tanque na última semana".

É possível obter todas essas informações, de uma forma ou de outra, com qualquer uma das arquiteturas descritas anteriormente. A abordagem centrada no modelo apresenta o contexto na discussão de uma forma que seja significativa para a empresa, simplificando a tarefa de acessar as informações e associar ações significativas a eventos relacionados aos objetos modelados, que no exemplo são equipamentos de perfuração de petróleo.

Arquitetura acionada pelo modelo

Estamos tratando do uso de modelos semânticos para suportar a integração de sistemas de operações e, possivelmente, a criação de aplicativos compostos/integrados por meio de SOA, middleware e um modelo de informações comum. Isso pode parecer semelhante ao que se conhece como arquitetura acionada pelo modelo, mas na verdade é muito diferente. A arquitetura acionada pelo modelo — explicada detalhadamente no trabalho excelente de Alan Brown, "An introduction to Model Driven Architecture" — tem a ver com uso de modelos no contexto do design de aplicativos para impulsionar o desenvolvimento do aplicativo, incluindo talvez a geração do próprio código do aplicativo (consulte Recursos). Aqui, por outro lado, trata-se do uso de modelos, em conjunto com a SOA e o middleware adequado, para fornecer o contexto e uma visualização comum (bem como um método de acesso) para as informações disponíveis na empresa.


Por que usar os modelos semânticos?

O que, exatamente, são os modelos semânticos e como eles ajudam nesse tipo de integração de sistemas de operações? Primeiro, para esclarecer, vamos comparar os modelos na Linguagem de Modelagem Unificada (UML) versus a OWL. A UML é uma linguagem de modelagem usada na engenharia de software para projetar artefatos, de modo geral, em torno de sistemas orientados a objetos. Quando falamos de integração de sistemas operacionais baseada na arquitetura orientada às informações, nesse contexto, estamos nos referindo ao aproveitamento de modelos semânticos como o núcleo funcional de um aplicativo para fornecer um modelo navegável de dados e relações associadas que representam o conhecimento na nossa área pretendida.

Os modelos semânticos permitem que os usuários façam perguntas sobre o que está acontecendo em um sistema modelado de forma mais natural. Por exemplo, uma empresa de produção de petróleo pode ser constituída por cinco regiões geográficas, cada uma delas contendo de três a cinco plataformas de perfuração, e cada plataforma é monitorada por vários sistemas de controle, cada um com um propósito diferente. Um desses sistemas de controle pode monitorar a temperatura do petróleo extraído, enquanto outro pode monitorar a vibração em uma bomba. Um modelo semântico permitirá que o usuário faça uma pergunta como, "Qual é a temperatura do petróleo que está sendo extraído na Plataforma 3?", sem precisar entender detalhes como qual sistema de controle específico monitora essas informações ou qual sensor físico está reportando a temperatura do petróleo nessa plataforma.

Portanto, os modelos semânticos podem ser usados para relacionar o mundo físico — da forma que ele é conhecido pelos engenheiros de sistemas de controle deste exemplo — ao mundo real, da forma que ele é conhecido pelos líderes de linha de negócios e tomadores de decisões. No mundo físico, um ponto de controle — como uma válvula ou sensor de temperatura — é conhecido por seu identificador em um sistema de controle específico, possivelmente por meio de um nome de tag como 14-WW13. Pode ser um dos milhares de identificadores em um determinado sistema de controle e pode haver muitos sistemas de controle parecidos na empresa. Para complicar ainda mais o problema de referenciamento e agregação de informações, é possível gerenciar outros pontos de dados de interesse por meio de bancos de dados, arquivos, aplicativos ou serviços de componente, e cada um tendo seu próprio método de interface e convenção de nomenclatura para acesso dos dados.

Dessa forma, um valor importante do modelo semântico é o oferecimento de acesso às informações no contexto do mundo real, de uma maneira consistente. Em uma implementação do modelo semântico, essas informações são identificadas usando "triplos" na forma "sujeito-predicado-objeto"; por exemplo:

  • Tank1 <tem o sensor de temperatura> 7
  • Tanque 1 <faz parte da> Plataforma 4
  • Plataforma 4 <faz parte da> Região 1

Esses triplos em conjunto formam a ontologia para a Região 1 e podem ser armazenados em um servidor de modelo, conforme descreveremos com mais detalhes mais adiante neste artigo. Em seguida, essas informações podem ser transferidas facilmente por meio da linguagem de consulta de modelo para responder perguntas como "qual é a temperatura do tanque 1 na plataforma 4" com muito mais facilidade do que responderia sem um modelo semântico que relaciona as informações de engenharia ao mundo real.

Outra vantagem dos modelos semânticos para esse tipo de aplicativo é a manutenção. Considere a Figura 3.

Figura 3. Abordagens estruturais ao modelo de informações
Abordagens estruturais ao modelo de informações

O modelo de mundo real descrito aqui pode ser implementado com qualquer um dos tipos de modelos mostrados na Figura 3. No modelo relacional, as relações entre as entidades são estabelecidas por meio de chaves explícitas (primária, estrangeira) e, no caso das relações de muitos com muitos, entidades associativas. A alteração dos relacionamentos nesse caso é difícil, pois exige mudanças na própria estrutura do modelo base, o que pode ser difícil para um banco de dados preenchido. A consulta desse tipo de dado com base em um modelo relacional também pode ser difícil, porque pode resultar em cláusulas where bastante complicadas ou em junções de tabela significativas.

Os modelos hierárquicos têm limitações semelhantes quando se trata de atualizações no mundo real e não são muito flexíveis quando se trata de transferir o modelo "horizontalmente".

O modelo gráfico, que é a forma de implementação dos modelos semânticos, facilita muito a consulta e manutenção do modelo depois que ele é implementado. Por exemplo, se houver necessidade de representar uma nova relação que não tinha sido prevista durante o design. Com uma representação de armazenamento triplo, a manutenção dessa representação adicional fica fácil. Basta incluir um novo triplo no armazenamento de dados. O ponto crítico é que as relações fazem parte dos dados, e não da estrutura do banco de dados.

Da mesma forma, é possível transferir o modelo de várias perspectivas diferentes para responder às perguntas que não foram pensadas no momento do design. Ao contrário, outros tipos de design de banco de dados podem exigir mudanças estruturais para responder a novas perguntas que surgem após a implementação inicial.

Os modelos de semântica (com base em gráficos) nos permitem fazer inferências com facilidade, de uma maneira não linear. Por exemplo, considere um serviço online para compra de livros ou de música. Um aplicativo como esse deve ser muito bom para fazer sugestões de compras adicionais com base em seus padrões de compra. Isso é muito comum para sites de varejo eletrônico, que fornecem recomendações como "Já que você gostou desse filme, talvez goste também de..." ou "Como você gostou dessa música, provavelmente também gostará da próxima...".

Uma maneira de conseguir isso é usar um modelo semântico e adicionar relações como as seguintes:

Enya <é parecido com> Celtic Women

Também é possível estabelecer, na ontologia, que tanto a Enya quanto o grupo Celtic Women fazem parte do gênero musical chamado "New Age". Essas relações, depois de estabelecidas no modelo, simplificam a oferta desses tipos de sugestões, quando necessário.

Agora veremos os detalhes dos modelos semânticos e um exemplo de abordagem de implementação do servidor de modelo.


Modelos semânticos

Conforme definido pelo World Wide Web Consortium (W3C), a Web semântica "fornece uma estrutura comum que permite o compartilhamento e a reutilização de dados entre limites de aplicativo, empresas e comunidade." Apesar da web geralmente se resumir à habilidade de compartilhar documentos, a web semântica fornece a estrutura para que os computadores possam compartilhar, interrogar com maior prontidão e entender os dados. A Web semântica suporta a noção de formatos comuns para dados que podem ser apresentados por diversas fontes. Ela também fornece a estrutura para entender os relacionamentos de dados. Isso suporta a interrogação de dados baseados na web que dependem do significado semântico ao invés de depender de links e referências explícitas (ou implícitas).

A arquitetura da Web semântica, conforme definida por Tim Berners-Lee, é uma estrutura com camadas e uma base em XML para definições de namespace e de esquema para suportar uma sintaxe comum. A próxima camada acima da base XML suporta um Resource Definition Framework (RDF) e esquema RDF. RDF é uma estrutura para representação gráfica de recursos. Embora ela tenha sido criada para representar as informações sobre os recursos da web, podemos usar para diversos outros tipos de dados, conforme discutiremos posteriormente. A definição principal de um elemento RDF tem base em triplos na forma sujeito-predicado-objeto. O formato legível por máquinas para RDF é XML (RDF/XML).

Um modelo RDF define essencialmente um gráfico, conforme descrito pelos triplos. Um esquema RDF (também conhecido como Linguagem de descrição do vocabulário RDF) proporciona um conhecimento adicional ao RDF, como os termos que podem ser usados, restrições que se aplicam e quais relacionamentos adicionais existem. É possível criar um esquema RDF para descrever a taxonomia das classes (ao contrário de apenas recursos no RDF) e relacionamentos formalizados entre os recursos (tipo e subclasse) para definir ontologias simples. É possível criar ontologias mais complexas usando o Web Ontology Language (OWL). O vocabulário de ontologia é a próxima camada da arquitetura da Web semântica.

Como mencionamos anteriormente, a ontologia fornece uma compreensão dos conceitos (termos e relações) dentro de uma área por meio de um vocabulário definido e uma taxonomia de modelo. Dentro da área de um segmento de mercado específico, podemos usar uma ontologia para suportar vários aplicativos. Além disso, a ontologia pode suportar termos aplicáveis de forma geral e relações que podem envolver diversas áreas. As ontologias definem as entidades e relacionamentos para representar o conhecimento que desejamos compartilhar entre setores, domínios e aplicativos, de maneira apropriada. Para facilitar isso, as ontologias suportam a herança. Portanto, é possível capturar um conhecimento mais generalizado (conhecido como ontologias superiores) que pode ser refinado para suportar um domínio específico (ontologias de domínio). Como discutiremos posteriormente neste artigo, o IBM Integrated Information Core Reference Semantic Model fornece um exemplo de uma ontologia superior.

A compreensão semântica dos dados depende de um vocabulário comum que define termos e relacionamentos. O esquema RDF fornece uma estrutura para um vocabulário que suporta tipos e subtipos e a habilidade de definir tipos de dados. É possível criar ontologias mais detalhadas usando OWL, que depende de esquemas RDF, mas fornece termos de linguagem adicionais em seu próprio namespace. O OWL é definido por meio de espécies ou perfis. O fornecimento de perfis que restringem o uso de termos pode simplificar as implementações, incluindo os mecanismos de inferência que você pode usar. Discutiremos a inferência e os mecanismos de inferência (raciocinadores) posteriormente neste artigo. É possível usar o OWL Lite para taxonomias e restrições simples, o OWL DL para expressividade total e o OWL Full no caso de não haver restrições de expressividade.

O Simple Protocol and RDF Query Language (SPARQL) é uma linguagem parecida com SQL para consulta de RDF (incluindo esquema RDF ou OWL). Usamos SPARQL para consultar padrões gráficos RDF e retornar resultados de subgráficos selecionados. (Consulte Recursos.) É possível usar o SPARQL para consultar ontologias e dados de modelo instanciados.

Em seguida, explicamos a função do servidor de modelo como um "host" de tempo de execução para o modelo semântico.


Servidores de modelo

O servidor de modelo (ou gerenciador de modelo) fornece a estrutura de tempo de execução na qual o modelo será implementado. Um servidor de modelo precisa suportar vários serviços funcionais para persistir e gerenciar o modelo (ontologia) e os dados de instância do modelo. Também precisa fornecer as ferramentas e interfaces de aplicativo para modelar e instanciar as consultas de dados e atualizações. Vamos analisar esse recurso mais detalhadamente por meio de projetos de software livre como Jena, Joseki, Sesame e Pellet como exemplos.

Os servidores de modelo podem suportar várias camadas de persistência diferentes que incluem bancos de dados e arquivo (normalmente no formato RDF/XML, embora N3 e Turtle sejam outras duas notações populares). Ainda que você possa usar bancos de dados relacionais para suportar a persistência de dados RDF, a consulta de dados RDF (dados com base em gráficos) armazenados em um RDB normalmente é ineficiente, e é possível perder a capacidade de alterar o modelo de dados sem alterar o esquema do banco de dados. Um armazenamento triplo é um banco de dados com uma finalidade especial, projetado especificamente para armazenamento e consulta de dados RDF. A estrutura de dados é otimizada para dados armazenados em uma estrutura tripla que corresponde à forma sujeito-predicado-objeto do RDF. Jena e Sesame fornecem armazenamentos triplos.

Quando pensamos sobre servidores de modelo nesse nível, não há ainda qualquer requisito para compreender a estrutura dos dados persistidos. No entanto, como há a consideração da função de modelo de servidor adicional, a compreensão dos dados se torna relevante. Jena e Sesame fornecem bons exemplos.

Primeiro, devemos observar que Jena fornece uma estrutura Java para desenvolvimento de aplicativos em Web semântica ao invés de fornecer um servidor de modelo completo. Especificamente, Joseki, um subprojeto de código aberto de Jena, fornece capacidade de servidor por meio de uma interface HTTP para os dados RDF e uma interface para consulta e atualização de SPARQL. Além disso, Jena fornece uma interface de programação para os dados RDF e um mecanismo de inferência. Com essa capacidade adicional, Jena não precisa entender a ontologia de RDF. Raciocinar ou inferir significa ser capaz de obter fatos que a ontologia não expressa diretamente.

O Jena fornece um mecanismo de inferência para suportar o raciocínio em RDF, RDFS e OWL, mas algumas instâncias são incompletas. O Jena fornece uma interface conectável de modo que outros mecanismos de inferência possam ser integrados. Por exemplo, o Pellet é um raciocinador Java de software livre que suporta totalmente o OWL DL, que pode ser conectado ao Jena. Com esse tipo de extensibilidade, Jena suporta linguagens como RDFS e OWL e suporta a inferência de dados de instância e descrições de classe.

Assim como Jena, o Sesame fornece uma estrutura Java que suporta persistência, uma API de interface e inferência. No entanto, o recurso de inferência no Sesame suporta RDF e RDFS, mas não OWL. Para um conjunto de dados RDF ou RDFS, é possível consultar o Sesame e encontrar as informações implícitas. Como tudo que pode ser inferido também pode ser afirmado, uma abordagem para suportar a inferência é adicionar explicitamente as informações implícitas ao repositório quando os dados são criados inicialmente. Essa é a abordagem do Sesame.

Em seguida, abordaremos o modelo semântico fornecido com o produto Integrated Information Core, que estabelece vários padrões de segmento de mercado para criar um metamodelo que fornece definições de recurso integradas à estrutura de operações empresariais. Esse modelo, na forma de uma ontologia e manifestado em um RDF, será implementado em um servidor de modelo fornecido com o Integrated Information Core que suporta alguns dos recursos descritos aqui.


Modelos de semântica e IBM Integrated Information Core

A finalidade do IBM Integrated Information Core é fornecer uma estrutura que simplifica a criação de aplicativos centrados em um modelo de semântica do mundo real e que suporta a integração de dados operacionais em tempo real e aplicativos empresariais relacionados. O principal componente da arquitetura Integrated Information Core que suporta essa meta é o modelo semântico que, com base nos padrões do segmento de mercado (centrado em grande parte no ISA-95 e no ISA-88), suporta a definição de um modelo corporativo até os ativos e as medições associadas.

O modelo de informações incluído com o Integrated Information Core é o Modelo semântico de referência. Ele atende a nossa definição de modelos semânticos, pois fornece uma abstração do mundo real da empresa e dos ativos em um modelo gráfico. Por meio dele, os aplicativos podem acessar as informações de sistemas discrepantes com vários métodos de acesso. O modelo de informações no Integrated Information Core contém entidades nomeadas com base em padrões de mercado (que atualmente incluem principalmente ISA-95, ISA-88 e ISO15926) e relacionamentos definidos por esses padrões ou implícitos pela combinação dos padrões em um modelo homogêneo. O Modelo semântico de referência pode ser consultado por meio de serviços ou (com base na implementação) de uma interface SPARQL.

Outro componente importante da arquitetura Integrated Information Core é a camada de adaptadores cientes do modelo, que suporta a integração de diversos tipos de terminal (aplicativos acessíveis por OPC, bancos de dados e serviços da web), e mapas das informações que fluem entre esses terminais e elementos do modelo.

Há duas visualizações do modelo semântico Integrated Information Core:

  1. Modelo de referência(a ontologia)

    Essa visualização define as classes que existem no modelo e as relações entre elas, mas não corresponde a qualquer empresa ou ativo específico.

  2. Modelo instanciado

    Essa visualização inclui instâncias das classes que têm uma referência direta de mapeamento para entidades do mundo real. Elas são preenchidas com um conjunto de propriedades (por exemplo, s/n, local, temperatura) e com relacionamentos com outras entidades instanciadas no modelo.

Considere o exemplo a seguir (baseado em um projeto para um fabricante de tinta) como um exemplo de uso do modelo baseado em padrões de mercado no Integrated Information Core para modelar o mundo real.

Como exemplo de uso do modelo baseado nos padrões de mercado no Integrated Information Core para modelar o mundo real, considere o exemplo a seguir, com base em um projeto para um fabricante de tinta.

Primeiro, como mostra a Figura 4, as classes de ISA-95, Enterprise, Site, Area e Production Unit (encontradas como classes de referência no modelo RSM) são instanciadas. Essas classes, juntamente com a classe Equipment, são usadas para definir um modelo físico que começa no nível corporativo e vai até o nível de equipamentos específicos.

Figura 4. Hierarquias corporativas baseadas em padrões de mercado
Hierarquias corporativas baseadas em padrões de mercado

(Veja uma versão ampliada da Figura 4..)

Normalmente, é no nível dos equipamentos de trabalho que as classes de medição podem ser conectadas e mapeadas para os adaptadores de dados de terminais e origens de dados específicas.

Após a instanciação e mapeamento do modelo até as extremidades por meio da camada do adaptador, é possível usá-lo de várias maneiras para conseguir os benefícios empresariais descritos anteriormente:

  • Aplicativos na empresa de fabricação de tinta que precisam obter informações sobre um ativo, como um tanque, podem ir até um único local, ou seja, o servidor do modelo que hospeda o modelo instanciado, para acessar essas informações. Isso pode incluir informações em tempo real sobre o tanque (por exemplo, temperatura), informações históricas (como a temperatura média da semana) ou tipos mais complexos de informação (por exemplo, ordens de serviço abertas para esse tanque, ou tanques do mesmo tipo).
  • As consultas feitas pelos aplicativos para obter informações operacionais sobre o tanque podem ser feitas usando um método de interface consistente (por exemplo, SPARQL), independentemente da verdadeira fonte das informações, como sistemas SCADA, banco de dados operacional ou um aplicativo (por exemplo, IBM Maximo ou SAP).
  • A representação do tanque e da hierarquia empresarial em torno do tanque é consistente e é baseada nos padrões de mercado. Essa forma canônica permanece intacta, independentemente do formato subjacente usado nos sistemas de terminais.
  • As informações sobre o tanque podem ser facilmente estendidas para apresentar novas informações consideradas úteis no futuro. Por exemplo, um novo requisito para relacionar às falhas de equipamento em um sistema de gerenciamento de ativo externo pode ser facilmente vinculado ao equipamento no modelo, de modo que as informações sobre a falha possam ser consultadas por meio do mesmo contexto de modelo. O modelo também fornece uma tela, baseada no contexto do mundo real, para simplificar a configuração de aspectos do controle de produção, como cálculo de KPIs (principais indicadores de desempenho), definição das ações necessárias para eventos operacionais e geração de alertas para problemas detectados. Agora, esse tipo de informação pode ser associado a um objeto no modelo e pode ser considerado confidencial para o contexto no modelo.
  • Da mesma forma, as relações no modelo semântico facilitam muito para os aplicativos buscarem essas informações no modelo de forma lateral, para responder perguntas que não foram previstas na criação inicial do modelo. Por exemplo, é possível que a nossa empresa de tintas contenha tipos de motores semelhantes que podem ter a mesma função, mas são de fornecedores diferentes. Por meio de relações no modelo, como "Motor tipo A <é equivalente ao> Motor tipo B", podemos produzir com facilidade um relatório mostrando características de desempenho de todos os motores semelhantes que estão sendo usados no momento na produção (em vários locais, se for necessário), de modo que possamos tomar decisões mais adequadas com relação ao fornecedor no futuro. Também podemos concluir que, ao fazer isso, precisamos de uma ação de manutenção para substituir um tipo de modo, uma vez que outro tipo está funcionando muito melhor. Observe nesse exemplo que as relações que mostram equivalência não precisam estar no modelo originalmente implementado e implantado — podem ser incluídas posteriormente com base em novos conhecimentos.

Resumindo, o Integrated Information Core estende o recurso de integração de aplicativos com base em um modelo semântico.

  • Modelo de entidade de negócios

    Modele as entidades de negócios (por exemplo, tanques, bombas) e suas relações de forma que seja possível suportar consultas de dados, que podem estar contidas em vários sistemas diferentes, em um contexto do mundo real. Esse é um conceito eficiente e nos permite estabelecer a inteligência entre as entidades (e sistemas subjacentes) para suportar analítica e otimizações voltadas para aspectos como previsão de falhas, detecção de comportamento anormal e detecção e prevenção de problemas de qualidade do produto.

  • Estabeleça o namespace global

    Estabeleça uma definição comum de nomenclatura e um método de acesso a informações, de modo que um aplicativo possa referenciar entidades como ativos que podem ser nomeados e identificados de forma diferente por vários subsistemas corporativos para que o aplicativo não conheça os detalhes desses subsistemas (por exemplo, SCADA/DCSl Systems, OPC Servers, SAP ou Maximo).

  • Defina a forma canônica

    Defina uma forma canônica para referenciar as informações associadas às entidades de negócios na empresa. Por exemplo, um tanque sendo usado para misturar tinta pode ter informações sobre a temperatura que podem ser obtidas de servidores OPC de nível inferior, ou ordens de serviço que podem ser obtidas do SAP ou do Maximo. Conforme mencionado anteriormente, é possível usar padrões de mercado para fornecer significados para essa forma canônica, que tem a vantagem de desenvolver definições e vocabulários aceitos para entidades comuns, como equipamento, locais, pessoal e muito mais.

  • Forneça uma interface de aplicativo corporativo

    Forneça uma interface global para os aplicativos consultarem e atualizarem as entidades de negócio e seus dados associados, de modo que o aplicativo não precise saber qual subsistema detém a propriedade de qualquer entidade específica ou dados associados (por exemplo, servidores OPC, SAP ou IBM Maximo). O aplicativo será fornecido com uma visualização empresarial completa dos dados, com base no modelo do mundo real que corresponde às informações. Isso simplifica muito a adição de novos sistemas subjacentes, pois as especificidades disso ficam ocultas por trás do modelo.


Conclusão

Neste artigo, analisamos o valor dos modelos semânticos no desenvolvimento de soluções. Discutimos essa arquitetura no contexto de várias arquiteturas de soluções amplamente usadas e conhecidas, centradas em dados, mensagens e serviços. Descrevemos os modelos semânticos em termos gerais e discutimos como o IBM Integrated Information Core agrega o valor de proporcionar uma base fundamentada no modelo semântico para o desenvolvimento de soluções que geram insights de negócio e eficiências.

Conforme o descrito neste artigo, os modelos semânticos desempenham um papel fundamental nas arquiteturas de soluções em evolução que suportam o objetivo de negócios de obter uma visualização mais completa daquilo que "está acontecendo" dentro das operações e, em seguida, derivar insights de negócios a partir dessa visualização. Modelos semânticos baseados em padrões de mercado dão esse passo a frente, particularmente quando os fornecedores de aplicativos adotam esses padrões (algo que, como sempre, acontecerá mais rapidamente sob a pressão da comunidade de usuários).

Recursos

Aprender

Obter produtos e tecnologias

Discutir

Comentários

developerWorks: Conecte-se

Los campos obligatorios están marcados con un asterisco (*).


Precisa de um ID IBM?
Esqueceu seu ID IBM?


Esqueceu sua senha?
Alterar sua senha

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


A primeira vez que você entrar no developerWorks, um perfil é criado para você. Informações no seu perfil (seu nome, país / região, e nome da empresa) é apresentado ao público e vai acompanhar qualquer conteúdo que você postar, a menos que você opte por esconder o nome da empresa. Você pode atualizar sua conta IBM a qualquer momento.

Todas as informações enviadas são seguras.

Elija su nombre para mostrar



Ao se conectar ao developerWorks pela primeira vez, é criado um perfil para você e é necessário selecionar um nome de exibição. O nome de exibição acompanhará o conteúdo que você postar no developerWorks.

Escolha um nome de exibição de 3 - 31 caracteres. Seu nome de exibição deve ser exclusivo na comunidade do developerWorks e não deve ser o seu endereço de email por motivo de privacidade.

Los campos obligatorios están marcados con un asterisco (*).

(Escolha um nome de exibição de 3 - 31 caracteres.)

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


Todas as informações enviadas são seguras.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=Segmentos de mercado
ArticleID=767118
ArticleTitle=A Função dos Modelos Semânticos nas Operações Industriais Mais Inteligentes
publish-date=08312012