O problema da interoperabilidade na indústria da E&C

Quando se fala em interoperabilidade na indústria da E&C, utilizando os meios digitais, pensamos logo em ‘troca de arquivos’. Mas será que interoperabilidade diz respeito somente aos formatos digitais da informação?

Interoperável

Segundo a Wikipédia, Interoperabilidade é a capacidade de um sistema (informatizado ou não) de se comunicar de forma transparente (ou o mais próximo disso) com outro sistema (semelhante ou não). Quando dizemos que um modelo é interoperável, estamos dizendo que ele possui informações que podem ser acessadas por outros sistemas que não o de sua autoria, ou elaborado num formato proprietário.

A não ser que todo o workflow da informação fique restrito ao conjunto de aplicações que trabalhe com o mesmo formato proprietário. Neste caso, é preciso garantir que todo o fluxo de informação caminhe por atores de um mesmo domínio, seja uma empresa, um elemento da cadeia produtiva, ou que este formato tenha sido adotado pelo mercado de forma universal.

Neste momento, escrevo este artigo no Microsoft Word, e o mais importante, mantenho ele neste formato, mesmo sabendo que vou precisar estar com a minha assinatura em dia para acessar esta informação. Não vejo tanto problema, afinal, Windows é o sistema operacional mais popular do planeta, e por conta disso, mesmo os outros sistemas se preocupam em manter uma certa compatibilidade com ele, o que garante que eu posso migrar para outro sistema operacional sem perder meus preciosos artigos. Mas será que isso se aplica a uma indústria tão fragmentada como a da E&C? Será que uma organização pode confiar todos os seus dados a um formato proprietário, na promessa de que este formato estará sempre disponível e acessível, não só por conta das assinaturas, mas também pela compatibilidade entre as diferentes versões lançadas periodicamente, e muitas até que não trazem diferença significativa alguma?

API

A utilização de API (Application Programming Interface), um conjunto de rotinas e padrões que permite a interface entre aplicações, é uma forma de garantir interoperabilidade de informações. Mas mesmo neste processo, a padronização aberta e universal é importante.  Quando falamos no uso de API na comunicação de sistemas diferentes e independentes, o protocolo de transmissão de dados costuma ser padronizado, e o formato também, isto garante que qualquer desenvolver, seja ele empresa ou um profissional prestando um serviço, pode consumir informações de forma padronizada se devidamente autorizado.  Existem diferentes formas de consumir informações através de API.

Sistemas costumam usar o que chamamos de API REST para conceder informações entre aplicações utilizando uma arquitetura específica (REST), geralmente através do protocolo http ou https, muito utilizado nas conexões via internet.

Existem várias destas API públicas, onde qualquer aplicação pode consumir informação como clima, mapas, dados governamentais públicos, etc. Um sistema pode criar uma API REST para permitir que outros sistemas possam consumir informação, através de um protocolo de autorização, e assim garantir interoperabilidade entre aplicações. Outra forma de interoperabilidade são as API programáveis. Um desenvolvedor cria uma biblioteca em uma linguagem específica para garantir o acesso a dados no seu formato proprietário de forma algorítmica.

Isso permite que outros desenvolvedores criem complementos, conhecidos como plugins ou add-ons. Assim, um desenvolvedor de uma aplicação específica pode criar um complemento que exporte as informações do modelo para um formato proprietário específico desta outra aplicação e manter, assim, a interoperabilidade entre duas aplicações. O grande problema deste processo é garantir a comunicação apenas entre estas duas aplicações, sem utilizar um padrão aberto e universal.

É como um acordo entre duas partes somente.  Imagine se o código Morse, amplamente utilizado para comunicação como um sistema de representação de letras através de sinal codificado, tivesse um padrão diferente para cada país que o utilizasse. Teríamos mais de uma centena de padrões sendo utilizados através do mesmo equipamento e forma de comunicação. Por que então não utilizar um padrão aberto e universal?

Semântica dos dados

Para que dados produzam informação eles precisam ter significado dentro de um contexto específico. Imagine uma ‘porta’. Esta ‘porta’ pode ter muitos significados dependendo do contexto.

Ela pode representar um simples componente dentro de um contexto de materiais, um serviço de fornecimento e instalação dentro do contexto de medição em obra e também um elemento construtivo com função de permitir a passagem entre ambientes diferentes ou que impeça a propagação de fogo no caso de um incêndio no contexto funcional.

A interoperabilidade não se restringe a apenas uma troca de arquivos, mas à uma troca de dados que produzam informação em diferentes contextos de forma a não perder o seu significado A importância de ter um padrão de interoperabilidade, não preocupado somente com o formato do arquivo, mas com a semântica dos dados, levou a indústria a criar um padrão aberto e internacional, padronizado pela ISO.

IFC

IFC (Industry Foundation Classes) é um padrão que visa descrever dados e elementos de um empreendimento da indústria da E&C em todo o seu ciclo de vida. É baseado em um método de modelagem de dados orientado a objetos. Isto significa que elementos do mundo real são descritos digitalmente como objetos com atributos, e não só os objetos, mas os relacionamentos entre eles, de forma a preservar seus significados, para toda a cadeia produtiva da indústria, durante todo o ciclo de vida. Isto significa que a porta vai ser modelada neste arquivo e seus dados devem produzir informação para todos os diferentes contextos, desde a concepção, passando pela construção até a gestão de sua manutenção.

Fonte: BIMCommunity

O fato da indústria da construção civil ser tão fragmentada, obriga os diferentes participantes de diferentes fases utilizarem diferentes aplicações. Aplicações de análise estrutural, modelagem de projeto, gestão de obra, orçamento, gestão de ativos, etc. Todos compartilhando os mesmos dados e de forma integrada. Parece impossível que todos estes atores utilizem a mesma aplicação com o mesmo formato proprietário. E mesmo que utilizem, será seguro manter todas estas informações num formato proprietário? Existe uma visão errada de que o padrão IFC possui falhas e não atende aos usuários. Na verdade, o padrão é bem maduro, tem muito o que melhorar, mas atende muito todos os requisitos de todo o ciclo de vida de uma construção.

O que acontece é que são raros os softwares que exportam e convertem a informação de forma padronizada conforme o esquema. Existe um lugar correto para cada elemento, uma classe para cada objeto, e o que se vê é que a aplicações, ou não permitem a configuração adequada, ou simplesmente bagunçam os dados dentro do formato e não seguem o padrão adequadamente.

Interoperabilidade por padrão aberto

O Brasil ainda caminha lentamente na adoção do BIM, mas lembrando que BIM diz respeito à tecnologia, processos e políticas, acreditar que conseguiremos alcançar níveis altos de maturidade com formatos proprietários, se comunicando apenas através de API, é um pouco utópico. A adoção de um padrão aberto e certificado se torna importante desde os primeiros níveis de maturidade na adoção do BIM, como a única forma de garantir que mais de 200 aplicações certificadas possam consumir a informação de forma correta, sem perda de dados, transparente, e com qualidade.

Comunicação entre aplicações vs comunicação por padrão aberto ( Fonte: Bloor & Owen 1995:18; Gielingh 2008:755) Aprender sobre o padrão IFC garante, não só um bom entendimento de como se deve trocar informação entre aplicações, como também entender a fundo, e na prática, o porquê dos dados estarem distribuídos de uma certa forma, levando em conta como serão utilizados e por quem.  

Autor: Carlos Dias,