Modelação do Fluxo de Informação no Processo de Construção

Aplicação ao Licenciamento Automático de Projectos

João Pedro da Silva Poças Martins

Dissertação apresentada à Faculdade de Engenharia da Universidade do Porto para a obtenção do grau de Doutor em Engenharia Civil

Porto

2009

À Diana, à Beatriz e à Benedita

Agradecimentos

Ao meu orientador, Professor Vitor Abrantes, por todo o seu apoio desde o momento de escolha deste tema. A sua visão multidisciplinar da construção foi uma importante inspiração no desenvolvimento desta tese.

À Secção de Construções Civis, na pessoa do seu director, Professor Vasco Freitas, por garantir todas as condições necessárias à realização deste trabalho.

Ao meu Pai, Joaquim Poças Martins, pelas frequentes discussões e sugestões. O seu conhecimento acerca do sector da água foi fundamental em muitos momentos.

À Engenheira Cristina Moura das Águas do Porto pelas suas explicações acerca do processo de licenciamento de projectos de sistemas de distribuição predial de águas.

Ao Engenheiro Lars Christensen pelas suas sugestões oportunas na fase inicial deste trabalho.

Ao meu amigo Eric Many pela tradução do resumo da tese para francês.

Aos meus amigos, Catarina Tuna, João Luís Lima, Pedro Vieira e Ricardo Poças pelas conversas acerca dos sistemas de informação para a construção e suas aplicações.

Aos meus pais e ao meu irmão Ivo pelo permanente incentivo. Acompanharam-me sempre de perto durante a realização deste trabalho.

À minha mulher, Diana, pelo seu apoio, pela sua confiança, mas também pelas inúmeras sugestões que ajudaram a moldar esta tese.

Finalmente, aos meus avós, pelo seu exemplo de vida.

Resumo

A construção civil é um sector ineficiente quando comparada com outras actividades produtivas. Uma parte significativa do desperdício nesta área decorre de uma inadequada gestão da informação. Ao contrário do que sucede em outras actividades produtivas, a construção civil carece da definição de formatos de representação padrão para os seus produtos que permitam que a comunicação entre os intervenientes nos seus processos decorra de forma eficiente e, em alguns casos, automática.

Ao longo das últimas décadas, têm sido propostos diversos modelos de informação que permitem a representação completa ou parcial de produtos da construção. Ainda assim, a sua adopção por parte da comunidade de utilizadores é francamente diminuta. Admite-se que os intervenientes no processo construtivo não reconheçam, neste momento, vantagens concretas nos modelos de informação que justifiquem a sua adopção e as alterações nos processos de trabalho que lhe são inerentes. Considera-se, pois, que os modelos que se têm imposto como formatos padrão ad-hoc devem ser complementados por modelos parciais, de âmbito restrito, dedicados a solucionar problemas específicos que são colocados aos intervenientes no processo construtivo.

No presente trabalho apresenta-se um modelo de informação elaborado com o fim de permitir a verificação automática da conformidade regulamentar de projectos de sistemas prediais de distribuição de água, de acordo com o principal regulamento nacional em vigor. Apresenta-se ainda um conjunto de algoritmos que permitem a realização automática das verificações referidas. Crê-se que a utilização de métodos de avaliação automática de projectos resultará não só em evidentes vantagens decorrentes da simplificação administrativa inerente, mas constituirá ainda um factor de motivação para a adopção de modelos de informação por parte dos intervenientes, em particular daqueles que operam nas primeiras fases do processo construtivo.

Foram desenvolvidas aplicações informáticas que permitem a elaboração de projectos de sistemas prediais de distribuição de água de acordo com o formato do modelo proposto, bem como a geração automática de peças escritas e desenhadas de projecto.

Propõe-se ainda um conjunto de medidas de fiabilidade de abastecimento de água que, ao contrário dos indicadores existentes, permitem retratar o problema referido na óptica do cliente.

Abstract

The construction industry is inefficient when compared to other productive activities. Inadequate information management is a major source of waste in this area of the economy. Unlike other productive activities, the construction industry is yet to develop standard formats for the representation of its products, which would allow its participants to communicate efficiently and, in some cases, automatically.

Several different information models that represent building products partially or as a whole have been developed over the last decades. Their adoption by the community of users has been, however, scarce. It is believed that the participants in the construction process are yet to recognize the advantages presented by information models that would warrant their adoption and the changes in the workflow that they require. The models that have become ad-hoc standard formats should, therefore, be supported by narrow scoped aspect models, built to solve specific construction-related problems.

The present thesis proposes an information model developed to allow the automatic code checking of domestic water systems for compliance with the main national regulations. A set of algorithms that perform the code checks are also presented. Automated code checking should not only provide advantages due to simplified work processes, but it should also motivate users to adopt building information models, especially in the early stages of the construction process.

A software application has been developed to assist the design of domestic water systems according to the proposed information model. This application can generate drawings and other construction documents automatically.

Finally, two different water supply reliability indexes are proposed which, unlike existing indexes, measure the network’s performance from the customer’s point of view.

Résumé

Comparée à d’autres activités productives, la construction civile est un secteur inefficient. Une  partie significative des pertes dans ce domaine est due à une gestion inadéquate de l’information. Contrairement à ce qui se passe dans d’autres activités productives, la construction civile manque de formats de représentation patron pour ses produits, formats qui permettent que la communication entre les intervenants, au cours du processus, ait lieu de manière efficiente et, dans certains cas, automatique.

Au cours des dernières décennies, différents modèles d’information permettant la représentation complète ou partielle des produits de la construction ont été proposés. Malgré tout, leur adoption de la part de la communauté des utilisateurs est minime.  On admettra que les intervenants du processus constructif ne reconnaissent pas, aujourd’hui, les avantages concrets des modèles d’information justifiant leur adoption et les altérations inhérentes au processus de travail. On peut considérer en effet que les modèles qui se sont imposés comme formats patron ad hoc doivent être complétés par des modèles partiels, dans un cadre restreint, dont le but est de résoudre les problèmes spécifiques rencontrés par les intervenants au cours du processus constructif.

Dans le travail proposé ici, on présentera un modèle d’information élaboré pour permettre la vérification automatique de la conformité réglementaire des projets de système de distribution d’eau dans les immeubles, conformément au principal règlement national en vigueur. On présentera aussi un ensemble de chiffres permettant la réalisation automatique de ces vérifications. Nous pensons que l’utilisation de méthodes d’évaluation automatique de projets représentera non seulement d’évidents avantages résultant de la simplification administrative inhérente, mais elle constituera aussi un facteur de motivation pour l’adoption de modèles d’information chez les intervenants, en particulier chez ceux qui opèrent au cours des premières phases du processus constructif.

Des applications informatiques ont été développées. Elles permettent l’élaboration de projets de systèmes de distribution d’eau dans les immeubles selon le format de modèle proposé ainsi que la création automatique de pièces écrites et dessinées du projet.

On proposera aussi un ensemble de mesures de fiabilité de ravitaillement d’eau qui, contrairement aux indicateurs existant aujourd’hui, permettent d’ébaucher le problème défini du point de vue du client.

Índice Geral

ÍNDICE DE FIGURAS

ÍNDICE DE TABELAS

1                             INTRODUÇÃO

1.1         CONSTRUÇÃO CIVIL: UM SECTOR INEFICIENTE?

1.2         TECNOLOGIAS DE INFORMAÇÃO NA CONSTRUÇÃO: SITUAÇÃO ACTUAL

1.2.1           Adopção e adaptação de tecnologias da informação

1.2.2           BIM: um novo paradigma na construção

1.2.3           BIM: dificuldades em satisfazer exigências de utilizadores

1.3         LICENCIAMENTO AUTOMÁTICO DE PROJECTOS

1.4         ÂMBITO E OBJECTIVOS

1.4.1           Âmbito

1.4.2           Objectivos

1.5         ESTRUTURA DA TESE

2                             ESTADO DA ARTE

2.1         INFORMAÇÃO: CONCEITO

2.1.1           Modelo DIKW

2.1.2           Dados

2.1.3           Informação

2.1.4           Conhecimento

2.1.5           Sabedoria

2.1.6           Síntese

2.2         GESTÃO DA INFORMAÇÃO NA CONSTRUÇÃO

2.2.1           Especificidade do sector da construção

2.2.2           Ineficiência na gestão da informação: alguns sintomas

2.2.3           Das origens do CAD aos primeiros modelos paramétricos

2.3         SISTEMAS E MODELOS DE INFORMAÇÃO

2.3.1           Aspectos gerais

2.3.2           Tecnologias, sistemas e modelos de informação. Definições adoptadas.

2.3.3           Modelos de informação “completos” e “parciais”

2.3.4           Compatibilização de formatos

2.3.5           Vectores de desenvolvimento: ERP, BIM e aplicações à medida

2.4         FLUXO DE INFORMAÇÃO NO PROCESSO CONSTRUTIVO

2.4.1           Introdução

2.4.2           Processo construtivo

2.4.3           Implementação e dinamização de um sistema de informação baseado num BIM

2.4.4           Características desejáveis num modelo de informação

2.5         LICENCIAMENTO DE PROJECTOS

2.5.1           O papel do termo de responsabilidade

2.5.2           A importância do processo de licenciamento no contexto da gestão da informação

2.5.3           Licenciamento automático de projectos: Iniciativas em curso

2.5.4           Licenciamento de projectos de sistemas prediais de águas e esgotos

2.5.5           Análise regulamentar

2.6         CONCLUSÕES DA REVISÃO DO ESTADO DA ARTE

2.6.1           Má gestão da construção: Um infeliz equilíbrio

2.6.2           Caminhos possíveis para alterar o equilíbrio

2.6.3           O papel dos modelos de informação para a construção

2.6.4           O papel do processo de licenciamento automático de projectos

3                             REQUISITOS A CUMPRIR PELOS PROJECTOS DE SISTEMAS DE DISTRIBUIÇÃO PREDIAL DE ÁGUA

3.1         INTRODUÇÃO

3.2         SEGURANÇA DE PESSOAS E BENS

3.3         RESPEITO PELO AMBIENTE

3.4         FIABILIDADE DO SISTEMA PÚBLICO

3.4.1           Conceito

3.4.2           Critérios de avaliação

3.4.3           Fiabilidade: Custos

3.4.4           Aplicabilidade dos modelos de avaliação da fiabilidade de um sistema

3.4.5           Modelo probabilístico

3.4.6           POCINDEX

3.4.7           Conclusões

3.5         EFICÁCIA

3.6         EFICIÊNCIA E ECONOMIA: CUSTOS DE CONSTRUÇÃO

3.7         CONCLUSÕES

4                             LICENCIAMENTO AUTOMÁTICO DE PROJECTOS DE SISTEMAS DE DISTRIBUIÇÃO PREDIAL DE ÁGUA

4.1         INTRODUÇÃO

4.2         DESCRIÇÃO GERAL DA APLICAÇÃO LICA

4.3         MODELO DE DADOS

4.3.1           Aspectos gerais

4.3.2           Constituição da rede

4.3.3           Parâmetros de cálculo

4.4         DESCRIÇÃO DO ALGORITMO

4.4.1           Verificações prévias

4.4.2           Cálculo hidráulico

4.4.3           Verificações regulamentares

4.5         APLICAÇÕES EXTERNAS

4.5.1           Integração com base de dados

4.5.2           Aplicação com interface gráfica desenvolvida: LiCAD

4.6         APRESENTAÇÃO DO PROJECTO À ENTIDADE LICENCIADORA

4.7         AVALIAÇÃO DO MODELO DESENVOLVIDO

4.7.1           Introdução

4.7.2           Exemplo de aplicação

4.7.3           Alteração de fluxo de trabalho. Ameaças e oportunidades.

5                             CONCLUSÕES

5.1         RESULTADOS DO TRABALHO DESENVOLVIDO

5.2         DESENVOLVIMENTO FUTURO

ANEXO A.      ANÁLISE REGULAMENTAR DR Nº 23/95

ANEXO B.      LICA: ESTRUTURA DA BASE DE DADOS

ANEXO C.      LICAXML

BIBLIOGRAFIA

Índice de figuras

Fig. 1 – Objectivos do trabalho: Relação com o esquema DIKW apresentado na Fig. 3

Fig. 2 (a a d) - Esquemas DIKW (Steyn 2001), (Bellinger et al. 2004), (Clark 2004), (Sharma 2005) (traduções)

Fig. 3 – Esquema DIKW proposto

Fig. 4 – Indicador de adopção de tecnologias da informação e comunicação. Comparação com outros sectores da indústria (e-Business W@atch 2005) (traduzido)

Fig. 5 - Indicador de adopção de tecnologias da informação e comunicação. Comparação com outros sectores da indústria (e-Business W@atch 2006) (traduzido)

Fig. 6 – Dispersão da indústria da construção nacional (INE 2003)

Fig. 7 – Tipos de sistemas de informação. Adaptado a partir de (Laudon, Laudon 2002).

Fig. 8 – Arquitectura cliente-servidor

Fig. 9 - Vantagens decorrentes da antecipação de decisões de projecto. Curva de MacLeamy (CURT 2004)

Fig. 10 - Processo construtivo: Perda de valor entre fases. Adaptado a partir de (Bernstein 2005).

Fig. 11 – Interacção entre sistemas ERP das organizações e BIM. Adaptado a partir de (Stevens 2006)

Fig. 12 – Modelo IFC (IAI 2006). Os elementos representados a verde correspondem à parte do modelo que obteve certificação ISO em 2002.

Fig. 13 – Quota de mercado dos principais servidores (Netcraft 2009)

Fig. 14 – PXS: (a) Consulta de dados de uma tarefa, (b) diagrama de Gantt, (c) alerta de atrasos e (d) actualização de dados de progresso

Fig. 15 – CPS: (a) Importação de ficheiros gerados no Microsoft Project e (b) geração de curvas de progresso

Fig. 16 – Processo construtivo: esquema simplificado (Poças Martins 2006)

Fig. 17 – Produção de informação e sua formalização ao longo das fases de projecto

Fig. 18 – Desagregação de elementos do projecto a distribuir por subempreiteiros (Poças Martins 2006)

Fig. 19 – “Fluxograma de um processo de abastecimento” (EPAL 2006)

Fig. 20 – Relação de projectos de águas e esgotos com o projecto geral de arquitectura

Fig. 21 – Probabilidade de ocorrência de falha com magnitude especificada (exemplo)

Fig. 22 – Relação entre custos de construção, operação e manutenção e magnitude de falha

Fig. 23 – Fiabilidade do abastecimento na perspectiva do cliente

Fig. 24 – Algoritmo de quatro etapas: (a) Determinação de todos os percursos que unem os pontos início e fim, (b) Eliminação de percursos inviáveis do ponto de vista do seu funcionamento hidráulico, (c) Avaliação da fiabilidade de cada percurso individual, (d) Avaliação da fiabilidade da combinação de percursos (Poças Martins, Poças Martins 2007)

Fig. 25 - Representação esquemática de um algoritmo para a definição de todos os caminhos possíveis entre dois pontos de um grafo (Função Trails).

Fig. 26 - Subrotina “Novo Nível” correspondente a algoritmo representado na Fig. 25

Fig. 27 – Grafo completo com 4 nós e árvore correspondente aos percursos possíveis entre A e B

Fig. 28 – Rede simples composta por 4 troços A a D

Fig. 29 – Aplicação ProbIn: Obtenção de dados e cálculo de indicador de fiabilidade da rede (Poças Martins, Poças Martins 2008)

Fig. 30 – Árvore de Steiner: (1) Dados, (2) Rede correspondente aos pontos P1 a P4.

Fig. 31 – Árvore de Steiner vs. Condicionantes de projecto

Fig. 32 – Configuração correspondente à maior diferença entre comprimentos das redes de Steiner (a vermelho) e EMST (a azul)

Fig. 33 – Mínima árvore euclidiana correspondente aos dados representados na Fig. 30 (uma das duas soluções possíveis)

Fig. 34 – Mínima árvore euclidiana vs. Condicionantes

Fig. 35 – Grafo completo (K[n]) correspondente a conjuntos de n vértices, para n=16 (Trudeau 1993)

Fig. 36 – Se uma aresta não está numa triangulação de Delaunay então a aresta não está na árvore euclidiana mínima correspondente

Fig. 37 – Triangulação de Delaunay e Algoritmo de Prim. Exemplo simples: (1) Dados, (2) Triangulação de Delaunay, (3) Dimensões, (4 a 8) Algoritmo de Prim: Sequência de operações, (9) Resultado: Rede mais curta

Fig. 38 – Algoritmo proposto: Representação esquemática. Algoritmo de Prim destacado (linha a traço interrompido).

Fig. 39 – Definição da rede mais curta. Representação esquemática das etapas principais do algoritmo proposto

Fig. 40 – Representação esquemática geral da aplicação LicA

Fig. 41 – Nós com diferentes funções: (A) mudança de diâmetro, (B) modificação da geometria da rede, (C) consumos associados a nós

Fig. 42 – Um dispositivo de utilização (lavatório): dois nós com consumos associados

Fig. 43 – Não é suficiente verificar se os troços são paralelos: é necessário medir distâncias entre as condutas.

Fig. 44 – Distância entre duas rectas (Sunday 2001)

Fig. 45 – Condutas a par

Fig. 46 – Relação entre LiCAD e LicA

Fig. 47 - Imagens da aplicação LiCAD: Ecrã de definição e consulta das características dos componentes da rede

Fig. 48 – Imagens da aplicação LiCAD: Ecrã de análise hidráulica

Fig. 49 - Imagens da aplicação LiCAD: Ecrã de verificação regulamentar

Fig. 50 – Representação parcial de um modelo usando (a) projecção central e (b) projecção cilíndrica

Fig. 51 – Texto dinâmico: Verificação da conformidade regulamentar de um dispositivo de utilização

Fig. 52 – Relatório de verificação de conformidade regulamentar (imagem parcial)

Fig. 53 – Relatório de cálculo (imagem parcial)

Fig. 54 – Utilização de XML para a submissão de projectos

Fig. 55 – Planta do Piso 0

Fig. 56 – Planta do Piso 1

Fig. 57 – Esquema “isométrico”

Fig. 58 – Esquema isométrico gerado pela aplicação LiCAD

Fig. 59 – Resultado da verificação regulamentar efectuada. Nota: as não conformidades detectadas foram destacadas posteriormente sobre as imagens geradas pelo LiCAD.

Fig. 60 – Verificação regulamentar: Perspectiva (imagem parcial)

Fig. 61 – Medições efectuadas de forma automática

Fig. 62 – Cálculo hidráulico (imagem parcial)

Índice de tabelas

Tabela 1 – Custos de projecto relativamente a custos de produção (Eastman 1999).

Tabela 2 – Modelos completos e parciais (síntese)

Tabela 3 – Projectos de sistemas de distribuição predial de água: Características que favorecem a adopção de processos de licenciamento automático

Tabela 4 – Factores que influenciam a deterioração estrutural de condutas para o abastecimento de água (Røstum 2000) (traduzido)

Tabela 5 – Requisitos aplicáveis aos projectos de redes de distribuição predial de água: Conclusões

Tabela 6 – Utilização simultânea de fluxómetros: Valores regulamentares aos quais se acrescenta a primeira linha da tabela (Paixão 1999)

Tabela 7 – Coeficiente M[0]

Tabela 8 – Parâmetros geométricos a utilizar na produção de peças desenhadas

Tabela 9 – Título III: Sistemas de distribuição predial de água

Tabela 10 – Título V: Sistemas de drenagem predial de águas residuais

Tabela 11 – Tabelas usadas pelo LicA e respectivas descrições

Tabela 12 – Campos da base de dados por tabela, seus tipos de dados e respectivas descrições

Tabela 13 – Tipos de redes: Tabela SubNetworks_Type_Desc

Tabela 14 – Dispositivos de utilização e acessórios de rede: Tabela Devices_Type_Desc

Tabela 15 – Tipos de ligação de rede: Tabela Link_Type_Desc

Tabela 16 – Materiais para canalizações: Tabela Materials_Desc

Tabela 17 – Tipos de válvulas: Tabela Valves_Type_Desc

Tabela 18 – Tipos de espaços: Tabela Spaces_Type_Desc

Tabela 19 – Propriedades gerais: Tabela General_Properties

Tabela 20 – Utilização de coeficiente de simultaneidade: Tabela URC

Tabela 21 – Tipos de mensagens de sistema: Tabela Calc_Report_Res_Desc

Tabela 22 – Avisos: Tabela Warning_Level_ID

1     Introdução

1.1    Construção Civil: um sector ineficiente?

Durante séculos, a construção civil foi a actividade industrial com um maior consumo de recursos humanos e materiais. Para além de todo o peso que o sector ainda representa na economia, a construção civil desempenhou, até meados do século XIX, um papel no desenvolvimento tecnológico que desde então tem perdido para outras actividades industriais.

Estudos nacionais e internacionais revelam que a produtividade das empresas do sector da construção é consideravelmente mais baixa do que a do resto da economia. Uma análise da evolução ao longo das últimas quatro décadas revela mesmo que, apesar de todo o progresso tecnológico verificado, a produtividade na construção, medida da forma usual, tem sofrido um ligeiro decréscimo enquanto a produtividade do resto da economia mais do que duplicou.

As tecnologias de informação têm permitido o desenvolvimento de novos métodos de trabalho em todos os sectores da economia, incluindo a construção civil. Existe uma enorme variedade de aplicações específicas para o sector da construção, desenvolvidas praticamente desde que existem computadores com output gráfico. Algumas destas aplicações ter-se-ão tornado standard, podendo ser encontradas na maioria dos gabinetes de projecto ou escritórios de obra. Estas observações parecem indicar que o problema da gestão da informação na construção está já resolvido e que as manifestações evidentes de uma gestão da informação ineficaz se devem apenas a atrasos pontuais na disseminação da tecnologia de informação existente.

Na realidade, estudos recentes indicam que a indústria da construção é uma das menos eficientes na adopção das tecnologias da informação. Com efeito, as expressões “informatização” e “gestão da informação” não são sinónimas e é frequente encontrar-se empresas bem servidas em termos de hardware, com software actualizado e pessoal dedicado em exclusivo à manutenção do sistema informático mas que não realizam uma gestão eficaz da informação.

Uma avaliação efectuada aos métodos de trabalho no sector da construção civil permite afirmar que esta revela ineficiências significativas relacionadas com a transição entre as sucessivas fases do processo construtivo. Os problemas de interoperabilidade[1] entre sistemas de informação ao longo do processo construtivo espelham a sua estrutura fragmentada e acarretam custos elevados para todos os participantes. Estas ineficiências assumem várias formas, entre as quais o desperdício de tempo e a acumulação de erros devidos à introdução repetida de dados por processos manuais, a dificuldade em comunicar com outros intervenientes e a dificuldade em reutilizar a informação produzida em projectos anteriores.

Estes aspectos tornam útil a comparação da indústria da construção com outras actividades com um desempenho mais favorável nas áreas indicadas.

A indústria automóvel, em particular, tem gerado soluções que têm vindo a ser avaliadas e implementadas noutros sectores da economia. Entre as mais recentes tendências de gestão nascidas no sector automóvel ou que foram adoptadas desde logo nesta indústria, estão a filosofia lean e o PLM (Product Lifecycle Management).

A especificidade da indústria da construção tem impossibilitado a importação directa de soluções e atrasado a adaptação de métodos bem aceites noutros sectores.

1.2    Tecnologias de informação na construção: Situação actual

1.2.1       Adopção e adaptação de tecnologias da informação

Muitas empresas industriais de áreas diversas, com alguma afinidade com o sector da construção adoptaram, há mais de duas décadas, sistemas fiáveis de gestão da informação do tipo ERP (Enterprise Resource Planning). Hoje em dia, as aplicações ERP estão implementadas, com sucesso, na generalidade das empresas de construção com alguma dimensão.

Os BIM (Building Information Model), a aplicação da filosofia PLM ao sector da construção, começam a conhecer as suas primeiras aplicações práticas.

Ainda assim, os problemas referidos subsistem de tal forma que uma habitação custa hoje mais do que em 1964, a preços constantes. É certo que os produtos da construção são hoje mais sofisticados do que há 40 anos atrás mas, em muitos outros sectores, foi possível, através de um incremento significativo na produtividade, aumentar a qualidade dos produtos, diminuindo simultaneamente os seus preços.

1.2.2       BIM: um novo paradigma na construção

Na opinião de muitos autores, os BIM são uma tecnologia revolucionária, capaz de alterar radicalmente as práticas de trabalho actuais pelos seguintes motivos:

a.       Constituem formatos padrão para a representação de informação;

b.      Permitem uma redução do esforço necessário para a representação de informação;

c.       Obrigam à antecipação das decisões de projecto;

d.      Favorecem a interoperabilidade entre sistemas de informação.

Tem-se observado uma forte actividade das empresas de software no sentido de produzir aplicações comerciais, total ou parcialmente, com os formatos padrão de representação. No caso dos produtos da construção, esse formato é o IFC (Industry Foundation Classes) ou alguma das suas variantes.

Esta evolução é significativa e transcende largamente a simples criação de mais uma ferramenta informática para o sector: os BIM representam um novo paradigma na construção.

1.2.3       BIM: dificuldades em satisfazer exigências de utilizadores

Apesar do enorme potencial reconhecido nos BIM, observa-se que a sua adopção por parte da comunidade de potenciais utilizadores é muito diminuta. Estudos realizados em diferentes países revelam que apenas uma minoria dos técnicos do sector experimentaram já ferramentas BIM e que, entre estes, a larga maioria os utiliza apenas como ferramenta de desenho, tirando partido das suas funções de representação em 3 dimensões.

Assim, importa reflectir acerca da capacidade dos BIM para dar resposta aos problemas concretos da construção de hoje, isto é, com os regulamentos, as organizações e as práticas de trabalho actuais.

Na última década, uma parte significativa do esforço de investigação e desenvolvimento na área dos BIM tem incidido na produção de uma linguagem comum para a construção. Este tem sido um esforço que segue uma abordagem tipicamente top-down: uma parte da comunidade identifica ineficiências nas práticas de trabalho do seu sector de actividade e prescreve soluções, tecnicamente complexas, que o sector nunca exigiu.

Considera-se, pois, que a abordagem seguida actualmente deve ser complementada com um esforço bottom-up que, partindo das exigências da comunidade técnica actual, proponha soluções que resultem em vantagens de curto prazo, reconhecidas pelos intervenientes no processo construtivo.

Uma abordagem deste tipo permitirá, por um lado, alargar significativamente a base constituída pela comunidade de utilizadores dos BIM, ao tornar mais gradual a evolução dos métodos de trabalho. Por outro lado, permitirá identificar potenciais lacunas nos formatos de representação existentes, que os tornam menos aptos para representar algumas características relevantes dos produtos da construção.

Os BIM são uma tecnologia aplicável a todo o processo construtivo, mas o seu potencial só poderá ser plenamente aproveitado se forem adoptados desde as fases iniciais deste processo. Assim, e embora alguns estudos apontem a fase de utilização como aquela em que poderão ser recolhidos os maiores benefícios, a longo prazo, da adopção dos BIM, considera-se que as entidades que têm a capacidade de dinamizar todo o processo de mudança são os donos de obra e os projectistas. Admite-se que é a estes utilizadores que importa evidenciar as vantagens reais da aplicação das novas tecnologias.

1.3    Licenciamento automático de projectos

No presente trabalho, parte-se deste princípio para se propor um sistema de licenciamento automático de projectos. O processo de licenciamento tem características que o tornam uma significativa oportunidade para a introdução dos BIM no processo construtivo com evidentes vantagens imediatas para os intervenientes que voluntariamente os adoptem.

O licenciamento automático de projectos é o objectivo de um conjunto de iniciativas a nível internacional, sendo indicado por um dos autores mais influentes na área dos BIM como uma meta que deverá ser atingida cerca do ano 2020.

O desenvolvimento de um sistema de verificação automática da conformidade regulamentar de projectos depende da realização de duas tarefas principais:

a.       Elaboração de um formato de representação compatível com os regulamentos em vigor;

b.      Desenvolvimento de algoritmos que realizem a verificação das disposições regulamentares susceptíveis de verificação objectiva, isto é, daquelas às quais corresponde uma interpretação única.

Como complemento destas tarefas de base, é necessário produzir ferramentas informáticas que permitam a elaboração e a avaliação de projectos de acordo com as especificações propostas.

1.4    Âmbito e objectivos

1.4.1       Âmbito

Este é um trabalho na área dos sistemas de informação para a construção.

A tecnologia actual permite que sejam aplicadas aos produtos da construção tecnologias de informação com características anteriormente disponíveis apenas para outro tipo de indústrias.

A avaliação efectuada às características das tecnologias disponíveis e à forma como foram desenvolvidas permite retirar as seguintes conclusões:

a.       Os modelos de informação para a construção serão ferramentas fundamentais na abordagem a algumas das manifestações de desperdício verificado na fase de projecto, nomeadamente as que se prendem com questões de interoperabilidade.

b.      É fundamental incentivar a comunidade técnica a adoptar novas tecnologias, em particular na fase de projecto, apresentando vantagens concretas a quem as utilize.

1.4.2       Objectivos

Pretende-se criar uma aplicação concreta de um modelo de informação na construção cujas vantagens sejam reconhecidas pelos intervenientes nas primeiras fases do processo construtivo, em particular pelos donos de obra e pelos projectistas. Identificou-se o processo de licenciamento como uma oportunidade para intervir neste sentido.

O processo de licenciamento realizar-se-á por verificação automática da conformidade regulamentar do projecto, tendo em conta as disposições em vigor.

Será desenvolvido um modelo para a representação de sistemas de distribuição predial de água que corresponda às exigências de informação colocadas por um processo de licenciamento com as características referidas.

Serão desenvolvidas medidas quantitativas para a avaliação de redes hidráulicas, quando essas medidas não existirem ou forem consideradas inadequadas, em particular para avaliar requisitos de fiabilidade e de economia.

Serão desenvolvidos algoritmos que permitam efectuar, de forma automática, a verificação da conformidade regulamentar das disposições de projecto.

Serão desenvolvidas ferramentas que permitam criar modelos de informação para o fim descrito e para os avaliar do ponto de vista hidráulico e regulamentar.

Será especificado um formato padrão para a troca de informação entre intervenientes, aplicável às redes de distribuição predial de água e compatível com as ferramentas desenvolvidas.

Não se pretende que o modelo desenvolvido constitua uma representação genérica de produtos da construção. Existem já iniciativas em curso destinadas a este fim. Para além disso, a dimensão de um modelo dessa natureza tornaria claramente inviável o seu desenvolvimento num trabalho deste tipo.

Representa-se na Fig. 1 uma relação entre o âmbito do trabalho e os seus objectivos. Esta figura foi produzida a partir do esquema DIKW (Data – Information – Knowledge – Wisdom) proposto neste trabalho (ver Fig. 3).

Fig. 1 – Objectivos do trabalho: Relação com o esquema DIKW apresentado na Fig. 3

1.5    Estrutura da tese

A dissertação está dividida em cinco  capítulos, incluindo o presente capítulo introdutório onde se faz um enquadramento geral da tese e são referidos os objectivos a atingir.

No segundo capítulo apresenta-se o estudo do estado da arte na área das tecnologias da informação na construção, com ênfase nos aspectos relacionados com os formatos padrão para a representação de produtos da construção e com o licenciamento automático de projectos.

No terceiro capítulo são avaliados os requisitos a cumprir pelos projectos de sistemas de distribuição predial de água. A maior parte destes aspectos são convenientemente tratados nos regulamentos em vigor. Para alguns requisitos, porém, em particular os relacionados com a fiabilidade do abastecimento de água, devem ser desenvolvidos novos métodos de avaliação, pelo que estes tópicos serão desenvolvidos em maior detalhe, ainda que as consequências da sua aplicação apenas em parte sejam aplicáveis para efeitos do licenciamento de obras privadas.

No quarto capítulo apresenta-se o formato proposto para a representação de sistemas de distribuição predial de água para efeitos de licenciamento automático de projectos. Remete-se para anexo a descrição detalhada do formato desenvolvido. Apresenta-se a aplicação LicA, que efectua a verificação de conformidade regulamentar de acordo com o Decreto Regulamentar nº 23/95. Apresenta-se ainda a aplicação LiCAD que pode ser usada para produzir modelos de acordo com o formato proposto bem como peças escritas e desenhadas de projecto. Finalmente, efectua-se uma avaliação do modelo proposto, incluindo uma aplicação das ferramentas desenvolvidas.

No quinto capítulo são apresentadas as conclusões do trabalho realizado.

2     Estado da arte

2.1    Informação: Conceito

2.1.1       Modelo DIKW

É importante procurar definir à partida o termo “informação”. Encontra-se na bibliografia um conjunto de definições, nem sempre coincidentes para esta expressão no âmbito das tecnologias de informação.

Uma forma corrente de ilustrar o significado da expressão “informação” é dada por um esquema do tipo “Dados – Informação – Conhecimento – Sabedoria” (DIKW – Data – Information – Knowledge – Wisdom na bibliografia de origem anglo-saxónica).

Informação; Conhecimento: “os coelhos comem erva… a erva nasce do solo… a chuva cai das nuvens… os lobos comem coelhos… etc. etc.”; Sabedoria: “Se eu matar todos os lobos, os coelhos vão comer a erva toda e o solo vai ser levado pela chuva!”

Fig. 2 (a a d) - Esquemas DIKW (Steyn 2001), (Bellinger et al. 2004), (Clark 2004), (Sharma 2005) (traduções)

Os esquemas apresentados na Fig. 2 revelam que a distinção entre cada uma das expressões não é entendida de forma consensual. A informação, por exemplo, pode ser vista como um subconjunto de dados ou, de outra forma, como um conjunto de regras que relacionam dados. Um autor considera que, “numa organização, os dados passam a ser considerados informação quando, sendo um subconjunto dos dados, acrescentam valor nas tomadas de decisão da organização” (Pereira 2005). O mesmo autor classifica como dados, documentos como “projectos” ou “descrições de produto”[2].

Na verdade, a distinção entre os conceitos apresentados neste ponto continua a ser debatida desde meados da década de 70, continuando ainda a ser um tema relevante no campo da filosofia (Pulsifer 2008). O tema é igualmente interessante no campo das tecnologias da informação. Com efeito, esta disciplina interessa-se, não tanto pela produção de informação ou de conhecimento, mas antes pela sua gestão, em particular pela forma como estas são transmitidas e partilhadas no interior das organizações.

Dada a incoerência detectada nas definições encontradas, e de forma a abreviar uma discussão em larga medida semântica, optou-se por apresentar o significado dos termos “dados”, “informação”, “conhecimento” e “sabedoria” adoptados neste trabalho.

2.1.2       Dados

No presente trabalho, considera-se que os “dados” são os elementos de base da estrutura DIKW. Os dados são desprovidos de contexto, isto é, não estão relacionados com outros elementos da estrutura DIKW. Um conjunto de nomes ou de números de telefone são exemplos de dados. A utilidade dos dados é limitada até serem inseridos num contexto, formando “informação”.

2.1.3       Informação

Se, na sequência do exemplo apresentado no ponto anterior, os nomes forem associados aos números de telefone respectivos e relacionados com um qualquer projecto formando uma “lista de contactos” das pessoas envolvidas no projecto, os elementos disponíveis constituem informação com utilidade evidente. Serão classificados como “informação” a generalidade dos elementos elaborados e partilhados pelos intervenientes do processo construtivo, incluindo correspondência, actas de reuniões, documentos de projecto, registos de progresso, características de materiais e componentes, etc.

Remete-se uma análise mais profunda acerca da natureza da informação no sector da construção e da forma como esta é gerida para os pontos 2.2, 2.3 e 2.4.

2.1.4       Conhecimento

A análise de informação recolhida em projectos anteriores pode resultar na identificação de padrões que permitam o estabelecimento de regras que poderão ser aplicadas em projectos similares no futuro. Ainda na sequência do exemplo usado nos pontos 2.1.2 e 2.1.3, uma lista dos elementos envolvidos em projectos anteriores associada a um conjunto de indicadores de desempenho medidos em cada um dos projectos podem permitir a avaliação das vantagens decorrentes da selecção de uma equipa de projecto com determinada composição. Os sistemas de suporte à decisão, por exemplo, fazem uso de métodos estatísticos para pesquisar a informação registada de forma a encontrar padrões que permitam estabelecer correlações entre variáveis de um problema. Nesta óptica, a gestão da informação e a gestão do conhecimento são conceitos afins.

Um conceito interessante, na óptica do presente trabalho, é a distinção entre conhecimento tácito e conhecimento explícito definidos por Polanyi (Polanyi 1962). Este filósofo classifica como tácito o conhecimento resultante do pensamento individual. Este tipo de conhecimento está directamente relacionado com a inteligência. O conhecimento explícito resulta do conhecimento tácito, embora nem todo o conhecimento tácito produzido por um indivíduo seja explicitado. O conhecimento explícito é escrito, falado, observado e formalizado de modo a poder ser consumido por outros.

Na indústria da construção, a componente tácita está presente nos actos criativos, na concepção de projectos, por exemplo, enquanto a componente explícita está presente na representação, isto é, na produção de peças de projecto (Pulsifer 2008). O conhecimento tácito é privado e pessoal. O conhecimento explícito é público e colectivo. Esta distinção entre processos criativos e processos de representação estará presente ao longo deste trabalho, permitindo identificar as áreas em que as tecnologias de informação podem ser mais úteis à gestão do conhecimento: a formalização do conhecimento tácito e a sua transmissão no interior das organizações.

Embora se estime que, no sector da construção, o conhecimento explícito seja responsável por mais de 80% do volume de negócios das empresas de projecto, as vantagens competitivas das empresas residem habitualmente no conhecimento tácito que produzem (Pulsifer 2008).

O conceito de conhecimento explícito proposto por Polanyi aproxima-se claramente da definição apresentada para informação neste trabalho. Assim, e salvo indicação em contrário, as referências a conhecimento apresentadas no presente documento correspondem ao conhecimento tácito de Polanyi.

2.1.5       Sabedoria

A sabedoria resulta da experiência acumulada em actividades anteriores, podendo surgir a partir da compreensão de princípios correspondentes a actividades distintas. Embora a descrição adoptada para sabedoria aponte para uma faculdade exclusivamente humana, encontra-se na bibliografia algumas referências ao conceito de “gestão da sabedoria” (Wisdom Management). Este conceito está longe de ser consensual entre autores, resultando frequentemente de uma definição de sabedoria distinta daquela que é a mais geralmente aceite. Considera-se, pois, que a “gestão da sabedoria” está claramente além das capacidades dos sistemas actualmente concebíveis e, por conseguinte, fora do âmbito do trabalho apresentado.

2.1.6       Síntese

A distinção entre os elementos da estrutura DIKW não é simplesmente uma questão de semântica. Com efeito, a definição de um modelo simplificado para esta estrutura permite concretizar o âmbito de um trabalho na área da gestão da informação.

A Fig. 3 representa o modelo DIKW segundo o ponto de vista do autor deste trabalho. Inclui não só a hierarquia entre elementos mas também as transições entre eles. Procura-se ainda fazer uma separação entre o domínio tangível – os documentos, a comunicação verbal, etc. – e o domínio intangível – o pensamento, a imaginação.

Fig. 3 – Esquema DIKW proposto

A generalidade dos componentes do diagrama representa um acréscimo de valor para os indivíduos e para as organizações. Os dados, a informação, o conhecimento e a sabedoria têm um valor intrínseco evidente. A transição entre estes estados (em qualquer sentido) representa um esforço que possui igualmente valor: o processo de aprendizagem de um indivíduo resulta num ganho de valor pessoal e para a organização onde se insere. Por outro lado, o volume de negócios das empresas resulta da aplicação do capital intelectual acumulado, isto é, na concretização daquilo que se sabe.

A única excepção à regra estabelecida de associar um valor positivo a cada uma das transições refere-se à transformação de informação em dados como resultado de uma perda de contexto. A desorganização produz este efeito ao permitir que esforços anteriores sejam desperdiçados. Esta transição pode resultar de desarrumação, de esquecimento ou de extravio, por exemplo. As organizações recaem frequentemente neste tipo de desperdício ao não documentarem devidamente as suas actividades.

As empresas ineficientes no domínio da gestão da informação são especialmente sensíveis à perda de capital humano, sejam elas temporárias – ausências de colaboradores por motivo de doença ou férias, por exemplo – sejam elas permanentes. É evidente que a ausência de colaboradores representa sempre uma perda para as empresas – os seus talentos fazem parte do capital humano das organizações. Um dos objectivos da disciplina da Gestão da Informação deve passar por evitar que as pessoas sejam os repositórios exclusivos de informação e de conhecimento das organizações.

O presente documento é um trabalho na área da gestão de informação no sector da construção. Assim, são abordados os temas relacionados com a organização de dados e com a criação de mecanismos que facilitem a transição entre os estados de informação e de conhecimento, separando as actividades criativas dos processos de representação.

2.2    Gestão da informação na construção

2.2.1       Especificidade do sector da construção

2.2.1.1      Aspectos gerais

A constatação de que existem sectores da indústria em que há muito se empregam sistemas de informação eficientes, frequentemente aceites como standard nas áreas respectivas, conduz de uma forma quase inevitável à sugestão da sua aplicação à construção civil.

Compara-se, no presente subcapítulo, a indústria da construção com outras actividades industriais, tendo em conta as características que influenciam o desenvolvimento de boas práticas na área da gestão da informação. Naturalmente, a adopção e o desenvolvimento destas boas práticas não eliminam o risco de ocorrência de deficiências originadas na fase de projecto. As indústrias automóvel (Bates et al. 2007), (Lee 1998), aeronáutica (Leveson 2000) e aeroespacial (Rogers 1986) registam casos documentados de deficiências associadas a falhas de projecto, algumas das quais com consequências trágicas. Ainda assim, estas indústrias desenvolveram práticas de trabalho que resultaram numa transição entre as fases de projecto e de produção que não têm sido emulados na indústria da construção civil.

Interessa estudar as características do sector da construção que dificultam a importação das soluções que se têm revelado úteis em outras áreas.

2.2.1.2      Um sector “low-tech”?

A construção foi, até meados do século XIX, a actividade industrial com maior consumo de recursos humanos e materiais (Eastman 1999). Embora outras actividades industriais tenham tido um papel relevante no progresso científico das sociedades – nomeadamente a construção naval, entre outras – pode-se afirmar que durante este período, a construção foi um sector “de ponta” em termos de tecnologia.

Esta supremacia foi rapidamente invertida durante o último século. A indústria automóvel, por exemplo, tem vindo a produzir um impacto significativo na sociedade, que se estende para lá dos aspectos tecnológicos e económicos que lhe são inerentes. Com efeito, muitos dos princípios de gestão adoptados nas mais diversas actividades económicas tiveram origem na indústria automóvel – desde o Fordismo, ao Total Quality Management, passando pela filosofia Lean.

Assim, a supremacia tecnológica verificada no sector da construção foi suprimida de forma que hoje, o custo de desenvolvimento de produtos nas indústrias automóvel, aeroespacial ou electrónica excedem largamente o custo de projecto de qualquer edifício (tanto em termos relativos como em termos absolutos – ver Tabela 1).

O sector da construção tem-se distinguido das outras actividades industriais também na questão da produtividade. A produtividade é medida usualmente pelo quociente entre o Valor Acrescentado Bruto (ou o Valor Bruto da Produção) e o número de trabalhadores (ou o número de horas de trabalho). Embora esta abordagem não seja isenta de críticas, nomeadamente devido à dificuldade de quantificar a mão de obra na construção, esta forma de medir a produtividade é usada nos trabalhos consultados que comparam o desempenho da construção com o de outras indústrias (Teicholz 2004), (Baganha et al. 2002). De acordo com o último trabalho referido, a produtividade da construção nacional é 30% inferior à produtividade total no país. Conclui-se ainda que a produtividade no sector da construção civil e obras públicas tem registado oscilações não muito significativas ao longo dos últimos anos. De acordo com Teicholz, com base em valores registados nos EUA nos últimos 40 anos, a produtividade no sector da construção tem sofrido igualmente pequenas variações, sendo actualmente cerca de 10% inferior ao valor de referência (de 1964). Em igual período, a produtividade dos restantes sectores da indústria mais do que duplicou. As desvantagens metodológicas referidas, inerentes à adopção de medidas de produtividade do tipo usado nos trabalhos citados são, de alguma forma, mitigadas pela consideração de uma longa série de dados que permite não só comparar indústrias diferentes, mas também avaliar as oscilações de produtividade verificadas em cada sector individual.

Perante esta realidade, não se pode deixar de constatar que a indústria da construção é, em termos relativos e usando uma expressão anglo-saxónica, low-tech.

Fig. 4 – Indicador de adopção de tecnologias da informação e comunicação. Comparação com outros sectores da indústria (e-Business W@atch 2005) (traduzido)

Resultados brutos

Resultados ponderados pelo número de trabalhadores (empresas maiores têm um peso superior)

Fig. 5 - Indicador de adopção de tecnologias da informação e comunicação. Comparação com outros sectores da indústria (e-Business W@atch 2006) (traduzido)

As Fig. 4 e Fig. 5 procuram ilustrar diferenças registadas no uso de tecnologias da informação em dez sectores da indústria (e-Business W@atch 2005), (e-Business W@atch 2006). Os critérios A a D, usados para medir a difusão de tecnologias da informação podem ser descritos, de forma muito sucinta, da seguinte forma (e-Business W@atch 2004):

A.    Conectividade da empresa (caracteriza ligações dos computadores da empresa a redes internas e à Internet);

B.     Automação dos processos de negócio internos (mede a utilização de intranets, de sistemas ERP, de sistemas de controlo de produtividade e impacto percebido da utilização de aplicações e-business nos processos internos da empresa);

C.     Procurement e integração da cadeia de fornecedores (mede o número de empresas que efectuam compras na Internet, que integram os seus sistemas de informação com os dos seus fornecedores, que com eles trocam documentos electrónicos que não e-mails e que empregam sistemas de gestão da cadeia de fornecimento);

D.    Marketing e vendas (mede o número de empresas que recorrem a sistemas CRM – Customer Relationship Management –, as vendas efectuadas na Internet, a segurança das transacções online e a forma como os funcionários interagem com os sites das empresas).

No estudo de 2005 são comparadas empresas com menos de 50 trabalhadores em sete países da União Europeia (República Checa, Alemanha, Espanha, França, Itália, Polónia e Reino Unido). No estudo de 2006, o mais recente à data de publicação deste trabalho, são acrescentados três outros países (Dinamarca, Hungria e Finlândia) e são consideradas empresas de dimensões superiores pelo que os resultados não são estritamente comparáveis. Os resultados apresentados permitem retirar as seguintes conclusões:

a.       O sector da construção apresenta uma muito reduzida difusão de tecnologias da informação em comparação com outros sectores industriais, classificando-se em último lugar entre os sectores avaliados no estudo de 2005. Esta conclusão seria relativamente previsível dado que o peso das pequenas empresas no sector da construção é muito elevado (ver também Fig. 6). O desempenho relativo das empresas do sector da construção nos estudos referidos é justificado da seguinte forma:

i.            A dimensão das empresas (em qualquer sector) é um factor determinante para justificar o seu desempenho de acordo com o indicador de adopção de tecnologias da informação e comunicação: empresas maiores registam invariavelmente classificações superiores àquelas das empresas menores do mesmo sector de actividade.

ii.            A natureza não-standard do serviço prestado pelas empresas do sector da construção dificulta a adopção de soluções padrão na área das tecnologias da informação.

b.      O mau desempenho da indústria da construção neste índice mantém-se, mesmo comparando empresas de dimensões similares.

2.2.1.3      Características do produto

Em geral, a função “produção” desenvolvida na indústria transformadora pode ser encarada, de forma simplificada, como um processo dividido em três fases distintas (Grieves 2006):

a.       O fabrico do primeiro exemplar (o protótipo);

b.      A optimização dos procedimentos relacionados com a produção;

c.       A produção propriamente dita.

Na realidade, estas fases não costumam ser claramente delimitadas. Com efeito, o “protótipo”, em geral, não é uma versão final do produto a desenvolver. A optimização dos procedimentos pode não ser atingida de forma imediatamente perceptível pelo que, por vezes, só uma análise retrospectiva do historial de produção permite a definição de um momento a partir do qual o ritmo de produção e a qualidade do produto se mantêm relativamente estáveis, o que dificulta a diferenciação das duas últimas fases referidas.

O produto da construção apresenta quase invariavelmente as características de um protótipo: raramente faz parte de uma série de produtos idênticos. A fase de “execução” do processo construtivo (ver 2.4.2) não passa, pois, da primeira das três fases aqui referidas. Apresenta-se em seguida uma descrição sucinta desta primeira fase, no âmbito de um processo de produção típico da indústria transformadora:

O fabrico do primeiro produto é a primeira fase do processo de produção. Dado que se encontra na fronteira entre a “engenharia” [nota: a designação equivalente, no contexto da construção, será “projecto”] e a produção, não é claro onde termina a “engenharia” e começa a produção. Nesta intersecção, o fabrico do primeiro produto representa uma importante potencial fonte de desperdício de tempo, de energia e de material enquanto se procura conciliar o produto “conforme o projecto” (as-designed) com o produto “conforme o produzido” (as-built). Para além disto […] poderá haver um significativo esforço na partilha ad-hoc de informação entre a “engenharia” e a produção. (Grieves 2006)

Embora este texto tenha sido citado a partir de um documento que foca sobretudo a indústria transformadora, parece evidente que seria igualmente adequado para descrever as dificuldades de coordenação habitualmente verificadas em projectos de construção. Admite-se, pois, que uma parte significativa das características que são frequentemente apontadas como específicas da indústria da construção seja, afinal, partilhada por outros sectores da indústria, pelo menos durante uma parte do processo de fabrico.

O que sucede depois do fabrico do protótipo ajuda a explicar a maior eficiência geralmente apontada aos procedimentos correspondentes à etapa de produção na indústria transformadora quando comparada com a indústria da construção: na construção, a “curva de aprendizagem” é sucessivamente interrompida após a execução de cada novo produto. Isto significa que o sector da construção acaba por viver permanentemente nas primeiras etapas da curva de aprendizagem, caracterizadas pela ineficiência, isto é, pelo “desperdício de tempo, de energia e de material”.

2.2.1.4      Tecnologias de fabrico

A construção civil é caracterizada por uma enorme variedade de sistemas e de componentes disponíveis nas fases de projecto e seguintes. Novos materiais de construção são lançados no mercado a um ritmo acelerado por um grande número de fornecedores distintos, de dimensões variáveis. Muitos dos componentes que chegam ao mercado têm propriedades, em rigor, desconhecidas ou insuficientemente documentadas. Assim, num produto de construção, a qualquer exigência de desempenho poderão ser associados um número significativo de soluções alternativas.

Esta dificuldade em estabelecer um conjunto finito de pares correspondentes exigência-solução que seja suficientemente abrangente e detalhado para caracterizar a generalidade dos fluxos de trabalho que constituem a actividade de projecto ilustram, de alguma forma, a dificuldade associada ao desenvolvimento de modelos de informação detalhados para a construção. Em síntese, a variedade dificulta a padronização.

A actividade de projecto consiste, em larga medida, à preconização de soluções construtivas que correspondam às exigências identificadas. Assim, as exigências de desempenho podem ser encaradas como inputs e as soluções construtivas como outputs de um processo que consiste na produção de uma representação de um produto de construção. Segundo a teoria de sistemas, um processo é uma forma determinística de ligar inputs a outputs (Grieves 2006). De acordo com esta definição, as actividades de projecto não podem, regra geral, ser classificadas como processos. Assim, contrariamente ao que a terminologia corrente parece indicar, na actividade de projecto quase não existem processos de trabalho. Isto explica a dificuldade em obter-se outputs consistentes a partir de um conjunto comum de inputs.

Na realidade, as actividades não se podem resumir a uma categoria única – processos – mas, ao invés, podem ser classificadas de formas distintas em função do grau de definição dos seus inputs, dos seus outputs e das ligações entre ambos.

Num extremo do espectro correspondente a esta classificação estão os processos. Os processos exigem inputs bem identificados para que, de uma forma determinística, se obtenham outputs específicos e consistentes. Um processo pode ser inteiramente programado, no sentido informático do termo.

No extremo oposto do espectro está a arte. Não é possível identificar todos os inputs necessários à actividade, nem a forma como esses inputs serão usados. Da variedade de outputs possíveis, são seleccionados os que são considerados aceitáveis por quem os produz. Estas actividades encerram um elevado grau de incerteza e são frequentemente ineficientes. Não é, pois, de estranhar que as organizações procurem aproximar as suas actividades aos processos.

As actividades realizadas na construção podem ser classificadas, regra geral, como práticas. Nas práticas, os inputs e os outputs estão razoavelmente bem definidos, embora a ligação entre ambos não o seja. Os processos desenvolvem-se em ambientes bem controlados, o que não sucede com as práticas.

A forma como um desenhador representa um produto de construção é uma prática, assim como o é a interpretação desse desenho. Em ambos os casos, factores como a experiência dos intervenientes ou a sua formação académica têm uma influência importante no resultado das actividades.

Dada a maior consistência nos resultados dos processos e a sua maior eficiência, não é de estranhar que as organizações procurem transformar as suas práticas, aproximando-as daqueles. A representação simplificada de actividades sob a forma de fluxogramas ilustra este esforço.

De acordo com o que foi referido anteriormente, na indústria da construção a variabilidade de outputs possíveis para cada situação é um dos factores que dificultam a parametrização das actividades. Assim, algumas tarefas, principalmente as que se situam na fase de projecto do processo construtivo, aproximam-se claramente mais de uma arte do que de um processo.

É claro que não é desejável que a indústria da construção se transforme num conjunto de processos. Os processos não produzem resultados originais nem exclusivos. O mercado exige uma gama infinita de potenciais outputs da indústria da construção e estes simplesmente não podem ser obtidos com recurso a actividades classificadas como processos, mesmo que tecnicamente estas possam produzir resultados satisfatórios. Assim, a construção continuará a ser constituída por práticas e por artes, com as vantagens e os inconvenientes que lhes estão associadas. A questão que importa considerar, e que está presente ao longo de todo o presente trabalho, é: até que ponto é possível definir melhor os fluxos de trabalho, pelo menos nas tarefas menos criativas das fases de projecto e de execução. No que toca à execução, isto passa por adoptar, sempre que possível, soluções estandardizadas. Nas tarefas de projecto importa igualmente transformar algumas práticas, em particular as rotineiras, em processos, transformando formas de comunicação informais em formais (ver 2.3.2.2).

Retoma-se aqui a discussão relacionada com a gestão do conhecimento (2.1.4). A automatização de processos e a definição de formatos de representação padrão são mecanismos apropriados para servirem de suporte a actividades baseadas em conhecimento explícito – tarefas que têm como fim a materialização de conceitos: elaboração de peças de projecto, de orçamentos, etc. As actividades criativas (baseadas em conhecimento tácito) tendem a beneficiar mais de tecnologias que facilitem a comunicação, frequentemente informal, entre intervenientes (Pulsifer 2008). Estas actividades são menos aptas para serem transformadas em processos, tal como estes foram definidos no presente capítulo.

O problema associado à falta de definição nas tarefas que constituem o processo construtivo tende a ser menor nos casos em que são utilizadas, de forma intensiva, soluções estandardizadas. A indústria metalomecânica, por exemplo, utiliza já há algum tempo tecnologias de informação com uma aceitação significativa no sector. O projecto CIMsteel, que culminou no desenvolvimento de um modelo de informação para produtos de construção (estruturas metálicas), precedeu as iniciativas STEP ou IFC (ver 2.3.5.3.6 e 2.3.5.3.7)

2.2.1.5      Recursos gastos em projecto

O custo do projecto na construção civil é muito reduzido comparado com outras indústrias. Apresenta-se na Tabela 1 um conjunto de relações entre o custo de produção e o respectivo custo de projecto para produtos de diferentes áreas industriais.

Os produtos de consumo de massas – electrónica, automóveis, etc. – têm, como seria de esperar, um custo de produção reduzido quando comparado com o custo necessário para o seu desenvolvimento. Esta característica não é exclusiva deste tipo de produtos, sendo igualmente observada na indústria aeroespacial e na indústria aeronáutica.

No caso dos produtos de consumo de massas, a dimensão do mercado permite suportar os custos de investigação e desenvolvimento e, nos casos apontados, os clientes reconhecem valor na investigação.

No caso da indústria aeroespacial, o mercado é obviamente menor, mas o número de empresas do sector também o é. Neste sector, a investigação e o desenvolvimento têm um valor reconhecido pelos clientes, não só pelas características que acrescentam aos produtos, mas também um valor intrínseco – os clientes compram investigação.

Tabela 1 – Custos de projecto relativamente a custos de produção (Eastman 1999).

Exemplo

Custo/Un

Design

Relação

Microprocessador

€ * 10 2

€ * 10 8

1 / 1 Milhão

Electrónica de consumo

€ * 10 2

€ * 10 6

1 / Milhares

Construção

€ * 10 6

€ * 10 5

1 / 0.1

Os resultados resumidos na Tabela 1 sugerem que a indústria da construção é uma indústria com uma relação com o projecto distinto da das indústrias indicadas. Com efeito, o valor indicado na coluna Design da tabela tem um significado e um conteúdo diferente para a construção relativamente às indústrias indicadas. Para as indústrias referidas, Design inclui não só o projecto do produto (incluindo todas as fases necessárias ao seu desenvolvimento) mas também a investigação levada a cabo para lhe acrescentar novas características – isto é, investigação e desenvolvimento. Na construção, a generalidade das empresas do sector não promovem a investigação e desenvolvimento, pelo menos da forma como ela é entendida na indústria electrónica ou automóvel, por exemplo. Assim, para a indústria da construção, design corresponde, em geral, apenas ao desenvolvimento do projecto – original, como é próprio do projecto de um protótipo, mas não necessariamente inovador. É evidente que recursos escassos não favorecem o desenvolvimento de soluções optimizadas e tem sido sugerido que perante relações de custos do tipo apresentado, seria de esperar um grau de padronização dos produtos de construção claramente superior ao verificado (Eastman 1999).

As soluções estandardizadas podem alterar a relação entre custos indicada na Tabela 1, actualmente penalizadora para a indústria da construção. Por natureza, as soluções estandardizadas são aplicadas em diversas obras distintas, pelo que os custos inerentes à sua concepção são divididos por um grande número de produtos. Assim, torna-se possível tirar partido de uma vantagem de escala normalmente associada aos produtos de consumo de massas: aumentando o número de unidades idênticas produzidas, é possível aumentar os recursos dedicados ao desenvolvimento sem aumentar o custo unitário do produto.

2.2.1.6      Dispersão da indústria

O sector da construção civil é dominado, em Portugal, por um grande número de pequenas empresas (cerca de 98% com menos de 19 trabalhadores) que são responsáveis por cerca de metade do volume de negócios total do sector (ver Fig. 6).

Fig. 6 – Dispersão da indústria da construção nacional (INE 2003)

Os dados da Comissão Europeia apontam para uma situação semelhante a nível europeu, em que cerca de 96% das empresas contam com menos de 20 trabalhadores (e-Business W@atch 2005).

O reduzido capital da maioria dos intervenientes não é favorável ao desenvolvimento de esforços no sentido de alterar procedimentos habituais. Com efeito, constata-se que no sector da construção as PME estão mal preparadas para a utilização de tecnologias da informação (Ng et al. 2001), (Dainty et al. 2006). Por outro lado, o grande número de empresas no mercado dificulta o estabelecimento de formas de comunicação padrão.

Na construção nacional, a única fase do processo construtivo em que esta pulverização de intervenientes é alterada de forma significativa é a da promoção. Nesta fase, o volume de trabalho correspondente às obras públicas é de tal forma significativo e a natureza dos trabalhos a elas associados é de tal forma específica que a estrutura orgânica das empresas de construção inclui frequentemente departamentos dedicados a este tipo de obras. Esta singularidade no processo construtivo pode ser encarada como uma oportunidade para produzir alterações na forma de representar produtos na construção. Com efeito, o promotor pode impor formatos de representação padrão que deverão ser respeitados pelos seus fornecedores.

2.2.1.7      Interface projecto-execução

Os tipos de contrato tradicionais não favorecem a análise global do processo construtivo por parte dos participantes. É corrente que, por exemplo, as questões relacionadas com a produção sejam analisadas pela primeira vez após a conclusão do projecto, depois do lançamento do concurso de empreitada. Esta realidade contrasta com a prática seguida noutros sectores, nomeadamente no sector automóvel, em que as técnicas de gestão de projectos seguidas (Womack, Jones 2003) impõem a inclusão de técnicos ligados à produção nas equipas de projecto de forma a condicionar a concepção do produto com base em questões ligadas à produção.

As formas de contratação tradicionais na construção separam claramente as fases de projecto e de execução. Nas obras públicas, por exemplo, a forma de contrato padrão conduz a uma situação em que o projectista não só é uma entidade completamente independente relativamente ao empreiteiro, mas ainda tem de elaborar todo o projecto antes de conhecer quem o executará. Evidentemente, nestas circunstâncias não é possível adaptar o projecto às características do empreiteiro, o que, por vezes, seria desejável. O construtor pode, mediante a aprovação do dono da obra, propor soluções variantes para os projectos, mas os melhores exemplos de optimização da transição da informação entre as fases de projecto e de construção surgem nas obras em que os trabalhos correspondentes a ambas as fases referidas são adjudicados à mesma entidade.

Com efeito, considera-se que o sector da construção é caracterizado por uma perda de valor entre as sucessivas fases do processo construtivo, como resultado de uma deficiente coordenação entre os intervenientes que protagonizam cada uma delas (ver também Fig. 10).

Para além da inclusão de técnicos ligados à produção nas equipas de projecto, a transição entre as fases de projecto e produção na indústria automóvel apresenta uma outra característica que a distingue da indústria da construção: o projecto é congelado durante um longo período de tempo até ao início da fase de produção. A este período chama-se, nas publicações em língua inglesa, design freeze. A generalidade dos construtores de automóveis congela os projectos durante um período de dois a três anos. Num artigo publicado em 2005, revelava-se que o construtor automóvel com uma transição entre projecto e produção mais rápida tinha como objectivo fases de design freeze com uma duração de doze meses apenas (Ohnsman 2005).

Durante esta fase intermédia é preparada a fase produção: são definidas os locais onde as novas entidades serão produzidas e os recursos necessários à tarefa. As actividades de procurement são provavelmente as mais importantes durante esta fase.

Na construção, exceptuando num pequeno número de obras de características especiais, não há qualquer equivalente à noção de design freeze. Os desenhos e as especificações técnicas chegam continuamente ao estaleiro de obra, durante a fase de execução. Esta prática reduz a importância relativa das actividades ligadas à gestão da construção. Na construção, os potenciais ganhos associados à selecção de um sistema de aquecimento, por exemplo, são claramente superiores àqueles que podem ser atingidos por uma escolha criteriosa de fornecedores, de instaladores, de condições de entrega, etc. Assim, a oportunidade para modificar os custos do empreendimento vão sendo reduzidas à medida que o processo construtivo avança (ver também Fig. 9).

Naturalmente, os ganhos associados à gestão da produção são tanto maiores quanto maior for o número de unidades semelhantes produzidas. Assim, tal como sucede com as tarefas de projecto, também a gestão na construção tende a ser mais cuidada nos casos em que o grau de padronização das soluções é maior – isto é, em termos relativos, mais recursos são dedicados à gestão da produção quando o grau de repetição é maior.

Assim, a indústria automóvel beneficia de uma longa fase de congelamento de projectos uma vez que os ganhos cumulativos associados a uma gestão da produção mais cuidada excedem as perdas que correspondem a um lançamento mais tardio de produtos no mercado. Na construção, os prazos exigidos pelos clientes não permitem esta paragem prolongada e, dado o pequeno número de unidades semelhantes a produzir – regra geral, apenas uma – os ganhos cumulativos associados a uma fase de procurement que constitua uma verdadeira transição entre as fases de projecto e de execução são menos evidentes do que os observados noutras indústrias.

2.2.1.8      Relações entre elementos da cadeia de valor

Os intervenientes sucedem-se em cada fase do processo construtivo e em cada nova obra, o que resulta numa significativa dificuldade ao estabelecimento de relações de longo prazo entre empresas do sector.

As formas de contrato tradicionais separam a fase de projecto da de construção, o que resulta numa das divisões mais sensíveis, ao longo do processo construtivo, no que toca à gestão da informação.

Em termos comparativos, empresas do sector automóvel, por exemplo, tendem a realizar uma parte significativa das tarefas necessárias ao desenvolvimento dos seus produtos e a estabelecer parcerias com um número mais limitado de fornecedores. Estas parcerias são de tal forma estáveis que frequentemente se mantêm mesmo após a abertura de novas instalações da construtora noutros países.

Assim, os grandes construtores da indústria automóvel assumem claramente um papel dominante ao longo de toda a cadeia de valor.

Este tipo de relações, que não encontra paralelo na construção, é claramente benéfico para o estabelecimento de formas de comunicação padrão.

2.2.1.9      Prazo de validade de produto

Um modelo de informação deve incluir dados que permitam, por um lado, definir as exigências fundamentais que se colocam ao respectivo produto e, por outro enunciar as características dos componentes que satisfazem essas exigências. A satisfação destes requisitos é dificultada pela longevidade dos produtos de construção. Com efeito, um edifício, por exemplo, pode conhecer diferentes tipos de utilização ao longo do seu período de vida útil. Desejavelmente, um projecto deve permitir este tipo de alterações e, se possível, deve prevê-las. Infelizmente, as exigências do utilizador são, em larga medida, desconhecidas nas primeiras fases do processo construtivo.

2.2.2       Ineficiência na gestão da informação: alguns sintomas

2.2.2.1      Sintomas

A gestão da informação na construção é frequentemente criticada por ser considerada relativamente ineficiente e por usar ferramentas por vezes pouco sofisticadas em comparação com o que sucede com outras áreas industriais. Importa analisar esta observação, procurando identificar sintomas de gestão da informação não optimizada, deixando para um capítulo posterior a discussão das possíveis soluções para este aparente atraso do sector da construção.

Foram encontradas na bibliografia estimativas que indicam que os custos devidos ao desperdício resultante da divisão de processos e de falhas na comunicação entre intervenientes são, tipicamente, de cerca de 30% (Latham 1994), sendo este valor citado com alguma frequência (Sjøgren 2006), (Stevens 2006). Esta estimativa carece de alguma fundamentação e não há indicação da sua validade para diferentes países (resulta de uma avaliação da indústria da construção do Reino Unido), pelo que dificilmente poderá ser considerado adequado para a construção nacional.

Uma outra fonte (McGraw Hill Construction 2007) sugere que 3.1% dos custos na fase de projecto são desperdiçados como resultado da falta de interoperabilidade entre intervenientes. Este valor resulta de um inquérito efectuado nos EUA entre intervenientes correspondentes às diversas fases do processo construtivo – projectistas (engenheiros e arquitectos), empreiteiros e donos de obra. Naturalmente, indica a percepção dos respondentes relativamente à questão em apreço, não uma medida objectiva da dimensão do problema.

Um estudo levado a cabo pelo NIST (National Institute of Standards and Technology) acerca dos custos da falta de interoperabilidade de sistemas no sector da construção sugere que nos EUA este valor foi de cerca de 15.8 mil milhões de dólares em 2002, sendo mais de dois terços deste valor suportados pelos utilizadores (Gallaher 2004). Este valor é algo especulativo: resulta da identificação de um conjunto de ineficiências geradas ao longo do processo construtivo e da quantificação do desperdício correspondente. A caracterização das práticas de trabalho das organizações e das respectivas ineficiências foi efectuada com base num conjunto de inquéritos efectuados. Assim, embora haja um significativo grau de subjectividade nos resultados do estudo, a descrição de cenários aos quais corresponde uma gestão da informação optimizada e a avaliação do impacto de cada tipo de ineficiência permitem identificar áreas de intervenção prioritárias na área dos sistemas de informação para a construção.

As medidas referidas anteriormente comparam a situação actual no sector com situações hipotéticas concebidas pelos autores dos respectivos estudos. Não será, pois, de estranhar a disparidade entre os resultados sugeridos pelos diferentes autores.

Não foi encontrada na bibliografia nenhuma medida de ineficiência da gestão da informação, baseada em casos de estudo, que pudesse ser aplicada de forma sistemática ao sector da construção de modo a quantificar o desperdício resultante de sistemas de informação desadequados. Uma medida deste tipo seria, certamente, difícil de construir pelos seguintes motivos:

a.       Dificilmente se pode quantificar os impactos no custo de um erro cometido no processo de construtivo, já que estes têm frequentemente consequências que se prolongam para além da tarefa à qual o erro diz respeito. A selecção de um sistema de impermeabilização desadequado pode resultar em custos acrescidos de construção ou em patologias às quais podem ser associados custos. A incorrecta execução de um elemento estrutural pode provocar deficiências na construção que se tornarão aparentes anos após a sua conclusão ou pode resultar em alterações ao projecto de forma a adaptar a construção aos erros cometidos.

b.      Raramente se podem imputar os erros a uma causa única ou mesmo a uma causa principal. Tradicionalmente, por razões de responsabilidade civil, procura-se apontar o interveniente responsável por uma qualquer deficiência detectada. Existem estudos que dividem os custos dos erros na construção pelos agentes que lhes dão origem (donos de obra, projectistas, empreiteiros, etc.) ou por especialidades (estruturas, impermeabilizações, instalações, etc.). Não se conhece estudos que analisem os erros originados nas áreas de interface entre intervenientes ou entre especialidades, isto é, erros de comunicação que seriam susceptíveis de serem minorados caso tivessem sido usados sistemas de informação adequados. Um estudo deste tipo seria útil como visão crítica do processo de construção na sua totalidade, mais do que uma visão crítica das suas fases isoladas. Seria também um indicador importante para a determinação de prioridades de desenvolvimento para os sistemas de informação.

Aparentemente, esta dificuldade existente em associar benefícios a custos relacionados com investimentos em tecnologias de informação não é exclusiva do sector da construção (Davenport, Marchand 2000). Assim, qualquer avaliação do impacto resultante da adopção de sistemas de informação no sector da construção deve incidir sobre aspectos qualitativos, isto é, sobre sintomas associados à boa ou má gestão da informação.

De acordo com o referido neste ponto, reconhecendo-se a dificuldade em quantificar as perdas decorrentes de falhas na comunicação, interessa detectar sintomas de má gestão da informação que sejam facilmente reconhecíveis. Importa analisar eventuais problemas associados às seguintes tarefas, comuns a todos os intervenientes no processo construtivo:

a.       Recolha/registo de dados;

b.      Tratamento de dados;

c.       Divulgação/Comunicação de resultados;

d.      Validação de resultados;

e.       Implementação.

Apresenta-se em seguida alguns exemplos de sintomas de erros cometidos nas tarefas apontadas acima:

a.       Dados introduzidos manual e repetidamente: Estudos estimam que a mesma informação é introduzida, em média, sete vezes em diferentes sistemas durante o processo construtivo antes da fase de utilização e manutenção (Sjøgren 2005);

b.      Dados apresentam erros/omissões/duplicações;

c.       Intervenientes trabalham com conjuntos de dados de versões diferentes;

d.      Alterações a documentos (especialmente de projecto) são demoradas, obrigam à actualização manual de desenhos e de cálculos efectuados;

e.       Comunicação demorada entre intervenientes.

Muitos dos sintomas apontados são frequentemente encontrados nas diversas fases do processo construtivo.

Os problemas associados a deficiente gestão documental, em particular, os problemas relacionados com a partilha de informação, podem ser mitigados com ferramentas informáticas simples, acessíveis mesmo à generalidade das pequenas empresas do sector.

No decorrer do presente trabalho serão tratados com maior detalhe alguns dos sintomas de má gestão da informação, procurando-se apontar soluções no âmbito das tecnologias da informação. Serão apontadas áreas prioritárias tendo em conta as características dos produtos de construção e das organizações que participam no acto de construir.

2.2.2.2      Evolução na gestão da informação

Na sequência da distinção já apontada entre gestão da informação e informatização, interessa ponderar se a informática tem melhorado significativamente a gestão da informação ou se o progresso se tem verificado essencialmente ao nível da velocidade de processamento de dados em algumas tarefas. A grande quantidade de sistemas de informação já desenvolvidos parece tornar óbvia a resposta a esta questão. Existem, de facto, muitos exemplos de utilização proveitosa de recursos informáticos para organização e partilha de informação (ERP, correspondência, contabilidade, etc.), mas a análise de casos práticos permite concluir que estes exemplos são pontuais, isto é, que a sua utilização se concentra numa fracção das empresas ligadas ao sector e que não existe no sector uma abordagem sistemática à gestão de informação.

A conclusão aparente é que os avanços na gestão de informação ficam claramente aquém dos verificados no processamento de dados.

2.2.3       Das origens do CAD aos primeiros modelos paramétricos

Apresenta-se, no presente subcapítulo, uma breve perspectiva histórica acerca do tema dos modelos de informação na construção, partindo das primeiras aplicações com interface gráfico e terminando nos primeiros modelos de informação paramétricos. Esta perspectiva será retomada em 2.3.5.3.6, onde se descreve a evolução de alguns modelos de informação para a construção (BIM) considerados mais relevantes no contexto actual.

Os computadores são usados na engenharia desde meados da década de 50, para o cálculo automático de funções matemáticas. Seguiram-se as primeiras aplicações de apoio ao procurement e à facturação (Eastman 1999).

Surgiram depois as primeiras aplicações geométricas simples, cujos resultados eram produzidos por periféricos – plotters. A utilidade prática desta tecnologia era limitada pela ausência de monitores com capacidades gráficas que servissem de interface com o utilizador.

O primeiro sistema de desenho assistido por computador – incluindo software e hardware – foi desenvolvido por Ivan Sutherland, no âmbito da sua tese de doutoramento (Sutherland 1963). As primeiras aplicações práticas desta tecnologia só surgiram a partir da década de 70, quando a produção em massa de monitores de CRT permitiu a disseminação da tecnologia CAD. Os primeiros anos de vida da tecnologia CAD, a partir de 1970, foram caracterizados por uma dispersão de formatos de representação distintos que eram desenvolvidos e copiados por entidades diferentes. Alguns formatos sobreviveram a esta primeira fase, outros desapareceram (ver 2.3.4).

As indústrias automóvel e aeronáutica foram as primeiras a tirar partido da tecnologia CAD enquanto uma entidade distinta da simples automatização dos processos de desenho. As aplicações CAD permitiam a representação de superfícies curvas, o que não acontece, de forma satisfatória, nos desenhos bidimensionais. Outras indústrias impulsionaram o desenvolvimento de algumas das características que são encontradas nas aplicações CAD actuais, nomeadamente a indústria electrónica, que passou a utilizar computadores para automatizar alguns processos de projecto e de fabrico de componentes e a indústria de software, cujas aplicações SIG – Sistemas de Informação Geográfica – estabelecem a ligação entre bases de dados de grandes dimensões e a sua representação geométrica sob a forma de superfícies. A indústria de construção continua a depender, ao longo de todo o seu processo produtivo, de representações bidimensionais, pelo que não faz uso de todas as vantagens oferecidas pelas aplicações CAD.

Os avanços tecnológicos das décadas de 80 e 90 permitiram a consolidação e a expansão do mercado de aplicações CAD. Os formatos de representação actuais permitem a modelação paramétrica de sólidos, condição necessária para a elaboração de um modelo de informação que contenha informação geométrica acerca dos produtos de construção.

Os primeiros modelos de informação para a construção surgiram na década de 70. Inicialmente funcionavam como formatos de representação padrão de produtos da construção (alguns com âmbito muito específico) mas alguns destes modelos evoluíram até se tornaram sistemas CAD comerciais. Entre estas iniciativas contam-se quatro projectos britânicos: OXSYS CAD, CEDA, HARNESS e Scottish Special Housing Authority Housing System e três Norte Americanos: o modelo da Techcrete, o ARCH-MODEL e o CAEADS. As características destes projectos são apresentadas com algum detalhe por Eastman (Eastman 1999). Estes modelos não interagiam, em geral, com as aplicações usualmente utilizadas no sector da construção e tinham dificuldade em coordenar os esforços dos diversos projectistas de especialidades, pelo que a sua aceitação pela comunidade técnica foi limitada e os formatos de representação nunca chegaram a ser adoptados como padrão.

2.3    Sistemas e modelos de informação

2.3.1       Aspectos gerais

Pretende-se, no presente subcapítulo, apresentar um conjunto de conceitos considerados essenciais ao desenvolvimento de um modelo de informação para a construção, com as características detalhadas adiante:

a.       Serão definidas as expressões “tecnologias”, “sistemas” e “modelos” de informação.

b.      Serão distinguidos os modelos de informação para a construção completos dos modelos parciais, indicando-se as vantagens e desvantagens de cada um destes tipos de modelos.

c.       Será abordada a questão da compatibilização de diferentes formatos de representação usados na construção, isto é, a questão da interoperabilidade.

d.      Serão apresentados os sistemas ERP e BIM como vectores de desenvolvimento da gestão da informação na construção, sendo ainda abordado o papel actual das aplicações informáticas desenvolvidas no interior das organizações.

2.3.2       Tecnologias, sistemas e modelos de informação. Definições adoptadas.

2.3.2.1      Tecnologias de informação

A expressão “tecnologia de informação” remete para aspectos funcionais relacionados com a organização, o armazenamento e a comunicação de dados.

Como exemplos de assuntos da área das tecnologias de informação, contam-se (Pereira 2005):

A escolha dos diversos tipos de hardware, das formas de comunicação de dados entre os diversos computadores, das linguagens e produtos de desenvolvimento de aplicações, da optimização da organização física dos dados em bases de dados, da configuração dos sistemas operativos e dos sistemas gestores de bases de dados (SGBD).

2.3.2.2      Sistemas de informação

2.3.2.2.1            Conceito

Encontra-se, na bibliografia consultada, a seguinte definição, bastante abrangente, do conceito de “sistema de informação”: “Um sistema de informação representa todas as componentes dinâmicas da organização que incluem, entre outros, o hardware, o software, as regras e metodologias de desenvolvimento, as pessoas e a estrutura da organização que permitem a recolha e a agregação de dados, a sua análise e apresentação de forma a tornar mais eficientes os processos administrativos e mais eficaz o processo de tomada de decisão” (Pereira 2005).

De uma forma simples, pode afirmar-se que os sistemas de informação se apoiam na tecnologia de informação para atingir os seus fins (Correa 2004).

A área dos sistemas de informação, ao contrário do que sucede com as tecnologias de informação, é um domínio da gestão de organizações e trata de analisar a aplicabilidade das tecnologias a um negócio específico.

Numa analogia que, curiosamente, se relaciona com a construção, compara-se a composição de um sistema de informação com a de um edifício, procurando-se distinguir sistemas e tecnologias de informação (Laudon, Laudon 2006). Da mesma forma que um edifício é composto por um conjunto de materiais, usando para o efeito diferentes equipamentos mas também conhecimento sob a forma de arquitectura, engenharia, etc., também os sistemas de informação não se esgotam nos computadores e nas aplicações que lhes servem de base. Estes não são capazes, por si só, de produzir informação. Só é possível conhecer um sistema de informação na medida em que se conhecem os problemas que este se destina a resolver, a sua arquitectura, os elementos que o compõem e os processos que conduziram à sua definição.

Embora os sistemas de informação não estejam necessariamente dependentes de recursos informáticos, o presente trabalho centra-se no estudo dos Sistemas de Informação Baseados em Computadores (frequentemente designados pelo acrónimo SIBC, ou CBIS, resultante da sua designação na língua inglesa).

2.3.2.2.2            Classificação de sistemas de informação

Os sistemas de informação admitem uma diversidade de classificações, baseadas em critérios funcionais ou com base no tipo de informação gerida.

Uma primeira classificação prende-se com a estrutura dos dados e dos procedimentos a tratar. Segundo esta classificação, os sistemas dividem-se em formais e informais.

Um exemplo de um sistema informal é uma “rede de rumores” de escritório (Laudon, Laudon 2006). Um sistema deste tipo baseia-se num conjunto de regras não enunciadas, não existindo uma definição de informação, nem da forma como esta será armazenada e processada. Os sistemas de informação informais são frequentemente associados à gestão de informação não estruturada, especialmente se esta se processar de forma não rotineira. Nos casos em que a mesma informação não estruturada deva ser produzida, processada e comunicada de uma forma rotineira, deve analisar-se a possibilidade de incluir as funções correspondentes num sistema de informação formal. Uma tecnologia de informação correntemente usada para gerir informação informal e não rotineira é o correio electrónico (Pereira 2005).

Os sistemas formais, pelo contrário, são estruturados, isto é, operam em conformidade com um conjunto de regras fixas. Este tipo de sistemas pode ser manual ou baseado em computadores.

Este primeiro conceito de sistema formal remete, desde logo, para um dos principais obstáculos à implementação de um sistema de informação na construção (ver também 2.2.1): a enorme variedade de componentes e de processos alternativos admissíveis num projecto de construção dificulta o estabelecimento de uma estrutura formal que enquadre todos os elementos relevantes para a sua completa definição. Perante esta dificuldade, pode antever-se um conjunto de questões essenciais à definição de um sistema de informação para a construção:

a.       Que informação é possível (e viável) incluir num sistema de informação formal para a construção?

b.      Até que ponto se considera viável a criação de um sistema de informação formal para o sector que inclua os aspectos relativos à especificação de componentes e processos (ou, seguindo a terminologia mais usual na construção, de materiais e trabalhos)?

c.       Qual o papel actualmente desempenhado e qual o que deverá ser desempenhado no futuro pelos sistemas de informação informais na construção? Dever-se-á procurar limitar o seu âmbito a trocas de informação específicas (por exemplo, submissão de projectos para licenciamento ou comunicação entre os elementos de uma equipa de projecto)?

d.      É possível definir um sistema que combine as características de um sistema formal e de um sistema informal, de forma flexível em função das características do projecto de construção a que corresponde?

Importa ainda distinguir claramente os sistemas de informação internos de cada organização/interveniente (ou agrupamentos de organizações/intervenientes) e um possível sistema de informação “externo”, que respeita a um projecto de construção individual. Os primeiros são ferramentas de gestão própria da organização e contêm, entre outros, dados confidenciais que a organização prefere não partilhar com o exterior, frequentemente por questões relacionadas com eventuais responsabilidades decorrentes da sua actividade. Os segundos funcionam como repositórios de informação, onde todos os intervenientes ligados a um projecto de construção, condicionados por permissões atribuídas pelo administrador do sistema, podem contribuir com informação e consultar a informação introduzida pelos demais participantes no processo. Embora seja frequente que o mesmo sistema de informação reúna características correspondentes a ambos os tipos de sistema referidos, permitindo o acesso limitado a intervenientes exteriores à respectiva organização em função de um conjunto de permissões atribuídas, no sector da construção tende a verificar-se uma separação entre sistemas ou subsistemas vocacionados para a gestão da empresa (vendas, marketing, produção, contabilidade, recursos humanos) e sistemas ou subsistemas cujas funções primordiais estão associadas à comunicação com o exterior, isto é, à partilha de informação.

Apresenta-se na Fig. 7 uma classificação dos sistemas de informação em função do nível de decisão associado e à área funcional a que interessam. Esta classificação será usada para enquadrar os tipos de sistemas de informação considerados mais relevantes para o sector da construção.

Fig. 7 – Tipos de sistemas de informação. Adaptado a partir de (Laudon, Laudon 2002).

Entre as várias áreas funcionais representadas na Fig. 7, interessa focar a área da produção como correspondendo a um dos tipos de sistemas que irá previsivelmente assistir a uma maior evolução e disseminação num futuro próximo, no contexto da construção civil. Os sistemas de produção apoiam actividades relacionadas com o planeamento, desenvolvimento e manutenção de produtos e de instalações produtivas (Laudon, Laudon 2006). Estes sistemas admitem diferentes níveis de acesso, desde o nível operacional, ao qual correspondem por exemplo informações relacionadas com a verificação da progressão registada nos trabalhos, passando pelos níveis de gestão intermédia onde os sistemas podem analisar a produtividade e os custos associados à produção, até ao nível estratégico onde podem ser analisados os objectivos a longo prazo da empresa, incluindo a selecção de áreas geográficas onde apostar em termos de produção ou a escolha dos tipos de trabalho onde a empresa prevê conseguir maiores vantagens.

2.3.2.2.3            Product Lifecycle Management

Um tipo de sistema que tem assumido uma importância crescente na indústria automóvel ou aeroespacial, por exemplo, são os sistemas de gestão do ciclo de vida de produto (também designados por sistemas PLM – Product Lifecycle Management).

Os sistemas PLM baseiam-se num repositório de dados que organiza toda a informação necessária ao desenvolvimento de um qualquer produto (Laudon, Laudon 2006). Os dados podem incluir informação acerca dos fornecedores de materiais e componentes ou a especificação das suas características e são frequentemente ligados a um sistema CAD, isto é, a um modelo geométrico do produto. Os BIM, abordados adiante no presente capítulo, enquadram-se neste tipo de sistemas.

2.3.2.2.4            Adopção de sistemas de informação na construção

Tem-se assistido, nos últimos anos, a um esforço considerável das empresas ligadas à construção em implementar sistemas de informação adequados às suas características. Já depois do ano 2000, eram conhecidas empresas de grande dimensão à escala nacional que recorriam à mesma tecnologia de informação existente há décadas ou que não usavam, na prática, sistemas de informação propriamente ditos. Assim, a construção nacional, em termos da utilização de sistemas de informação, revelava ainda recentemente características próprias da primeira fase de desenvolvimento deste tipo de tecnologias. Esta fase é conhecida por “era do processamento de dados” (Pereira 2005) e caracteriza-se por uma utilização de computadores na automatização dos processos de trabalho que utilizam informação. Na era do processamento de dados, os computadores são utilizados para diminuir os custos de mão de obra e o tempo de realização das actividades, não para fornecer informação útil para as actividades de gestão. Alguns sintomas das práticas próprias deste período são ainda visíveis na generalidade das empresas do sector. É frequente, por exemplo, que as actividades de gestão recorram exclusivamente a mapas resumo produzidos recorrentemente, de forma manual, para satisfazerem a sua necessidade de informação.

A situação actual é significativamente distinta daquela que se verificava há cerca de uma década atrás, em grande parte devido à súbita disseminação de sistemas ERP. Ainda assim, a realidade das grandes empresas de construção dificilmente pode ser classificada como representativa da realidade da construção civil nacional. Embora não se pretenda estudar em pormenor este tipo de sistemas, estes não devem ser dissociados dos sistemas de informação correspondentes a projectos de construção individuais, nomeadamente aos que se baseiam nos BIM.

Na construção, onde a organização hierárquica das empresas é em geral uma organização por projectos, a cada obra individual corresponde frequentemente um sistema de informação com um grau de independência bastante elevado relativamente ao sistema de informação geral da empresa. Assim, os sistemas de informação correspondentes a projectos de construção individuais incluirão componentes relacionados com a representação dos produtos de construção (por exemplo, CAD ou eventualmente BIM), para além de componentes dedicados à gestão (por exemplo, ERP).

Esta ligação entre os modelos de informação para a construção e os sistemas ERP justifica a abordagem específica que lhes será realizada em capítulos futuros. Com efeito, é desejável que os sistemas sejam compatíveis, permitindo a troca de informação de uma forma, tanto quanto o possível, automática.

2.3.2.2.5            Papel dos sistemas de informação formais na construção

A definição apresentada em 2.3.2.2.1 para sistema de informação é suficientemente abrangente para que seja possível admitir que todas as actividades produtivas são enquadradas por um sistema de informação de qualquer natureza. É evidente que nem todos os sistemas empregados serão baseados em computadores, nem serão formais, tal como foram definidos estes tipos de sistemas no presente trabalho.

Frequentemente, os dados são produzidos, processados e comunicados de uma forma informal. Os sistemas informais são essenciais para o funcionamento das organizações (Laudon, Laudon 2006), conferindo-lhes a flexibilidade necessária à resolução de problemas imprevistos ou não rotineiros. Com efeito, este tipo de sistemas pode ser adaptável a qualquer tipo de problema (embora, frequentemente, se constate que esta abordagem será pouco viável), recorrendo à criatividade das pessoas e à sua facilidade em comunicarem directamente. Os sistemas informais podem pois, em algumas situações, ser encarados como uma solução alternativa à rigidez dos sistemas formais, apresentando um conjunto importante de vantagens relativamente a estes.

Em contrapartida, os sistemas formais tendem a resultar em soluções mais eficientes para problemas de carácter rotineiro, isto é, tarefas que assentam sobre procedimentos fixos, com conjuntos de dados de características conhecidas. Para além disso, resultam na criação de um repositório de dados estruturados, o que se pode tornar útil, por exemplo, no caso de se pretender reutilizar os dados usando outras aplicações.

Tendo em conta o referido no presente capítulo, a questão não será se o sector da construção deve usar sistemas de informação e, em caso afirmativo, em que tarefas. O sector da construção usa (usou sempre) sistemas de informação, naturalmente que nem sempre formais. Será portanto mais importante questionar qual o papel a desempenhar pelos sistemas informação formais na construção, sabendo que muitas tarefas deverão continuar a ser realizadas sem o apoio deste tipo de sistemas.

2.3.2.3      Modelos de informação

2.3.2.3.1            Conceito

Um conceito inerente à gestão de informação, em particular no contexto da construção civil é o de abstracção. Pode-se definir uma abstracção como uma visão de uma realidade onde se suprime um conjunto de informações que sejam consideradas desnecessárias para o fim a que se destina. Sob este ponto de vista, um modelo de informação é uma abstracção sobre o produto que se pretende representar.

Surgem frequentemente referências a modelos paramétricos aplicados às mais diversas actividades. Considera-se que o adjectivo é apenas útil para distinguir os modelos que são importantes para este trabalho dos modelos puramente conceptuais, que não contêm informação quantitativa acerca dos aspectos que pretendem descrever. Assim, os modelos referidos neste trabalho são de facto modelos paramétricos.

As peças escritas e desenhadas do projecto, o planeamento dos trabalhos, o cronograma financeiro e outros documentos relacionados com a obra não são mais do que “vistas” sobre o modelo. Frequentemente, as aplicações informáticas baseadas em modelos de informação para a construção usam estas vistas como interfaces para o modelo, isto é, permitem alterar as características do modelo a partir das suas vistas.

Uma vez que os modelos incluem aspectos que não se esgotam na sua geometria, é usual designá-los de modelos a n dimensões, ou modelos nD. Para além das 3 dimensões do espaço euclidiano, é frequente que os modelos incluam outras “dimensões”, entre as quais o tempo – o que permite, por exemplo, representar o progresso de uma obra ao longo das suas sucessivas fases – o custo, etc.

Tendo em conta a definição adoptada para o conceito de “modelo de informação”, o termo “de informação” é, de alguma forma, redundante, pelo que alguns autores se referem simplesmente a “modelos para a construção” (building models).

2.3.2.3.2            Correspondência com o “mundo real”: Modelos semânticos

Os dados têm uma correspondência com a realidade que pode ser estabelecida por meio de uma semântica, no sentido usualmente dado a esta palavra na bibliografia da área das tecnologias da informação (Woods 1975). Neste contexto, uma semântica é uma estrutura lógica que liga a representação de um objecto numa base de dados e o respectivo objecto no mundo real (Sheth 1995).

Dependendo da abordagem seguida na representação dos dados, a semântica pode ser tornada explícita através da definição de uma ontologia (ver 2.3.2.3.3) ou pode permanecer implícita (Delcambre et al. 2006). A primeira estratégia é típica de uma abordagem do tipo estruturalista ao desenvolvimento de formatos de representação (ver 2.3.3). Nas abordagens do tipo minimalista, algumas regras de representação serão implícitas, o que conduz a modelos mais ligeiros mas menos completos. As vantagens e desvantagens destes tipos de abordagem serão analisadas, em maior detalhe, em 2.3.3.

2.3.2.3.3            Ontologias

As ontologias são métodos de representação do conhecimento, tendo sido desenvolvidas no campo da Inteligência Artificial para facilitar a partilha e a reutilização de conhecimento (Malucelli 2006). Uma ontologia pode ser encarada como uma especificação explícita de uma abstracção (Gruber 1993). Por outras palavras, uma ontologia define a forma como se produz um modelo simplificado da realidade. Por norma, esse modelo assume a forma de uma estrutura hierárquica definida por classes de objectos e por ligações – às quais correspondem regras – entre estas classes. Uma ontologia deve obrigatoriamente ser consistente mas, por definição, não é necessariamente completa relativamente à realidade (Gruber 1993).

O desenvolvimento de modelos de informação para a construção, detalhados e completos, recorre a este tipo de representação para descrever um edifício, incluindo os seus componentes, as relações entre eles e os processos que conduzem à sua materialização.

Actualmente existem diversas linguagens que permitem o desenvolvimento de ontologias usando ferramentas informáticas, isto é, a explicitação de conhecimento. Actualmente, a linguagem padrão para o desenvolvimento de ontologias para a construção é a OWL (Ontology Web Language) desenvolvida pelo W3C (Lee et al. 2008). Para além das ontologias desenvolvidas com recurso à OWL, encontram-se na bibliografia exemplos de iniciativas baseadas na linguagem UML (Unified Modeling Language) (Gonçalves et al. 2007), (Santos 2002).

Uma ontologia aplicada à construção permite, por exemplo, descrever um compartimento como um espaço delimitado por paredes e associar um conjunto de restrições a esse compartimento (área mínima, número mínimo de compartimentos deste tipo incluídos num edifício, etc.).

Este tema será retomado em 2.3.3, onde serão avaliadas algumas vantagens e desvantagens inerentes à aplicação de ontologias em representações de conhecimento no sector da construção.

2.3.3       Modelos de informação “completos” e “parciais”

2.3.3.1      Aspectos gerais

Os conceitos de modelos “completos” e modelos “parciais” são fundamentais para a definição de uma solução para a representação de produtos de construção que possa ser aplicada a actividades concretas realizadas pelos intervenientes do processo construtivo. De acordo com o que se apresenta no presente subcapítulo, os modelos de informação completos e parciais têm objectivos e campos de aplicação distintos, embora possam (e devam) ser compatíveis. Apresenta-se, em 2.3.3.3, uma tabela onde se resume os aspectos mais relevantes abordados ao longo do ponto 2.3.3.

As designações “completo” e “parcial” encerram, de alguma forma, uma contradição. Com efeito, todos os modelos são derivados da realidade por supressão de detalhes considerados menos relevantes, ou de modelação mais difícil. Por outras palavras, um modelo não é mais do que uma abstracção da realidade.

Assim, todos os modelos são “parciais” no sentido em que são uma visão simplificada da realidade. Com efeito, é esta simplificação que torna os modelos de informação úteis, permitindo que sejam usados para retratar e para prever o comportamento do único modelo verdadeiramente completo: a realidade.

Importa, pois, procurar definir qual o nível de pormenorização adequado para o modelo, tendo em conta as práticas correntes seguidas pelos diversos intervenientes no processo construtivo. A definição da estrutura de um modelo e do seu nível de pormenorização é uma tarefa que encerra um elevado grau de subjectividade. Com efeito, de acordo com (Turk 2001), não é possível afirmar que um modelo é correcto ou incorrecto, salvo no que diz respeito à sua coerência interna. Ainda assim é possível avaliar a sua capacidade para satisfazer um determinado conjunto de requisitos definidos por um utilizador ou por uma comunidade de utilizadores. É esta natureza subjectiva dos modelos que os torna, na opinião de alguns autores, interpretações da realidade ao invés de representações da realidade.

Nos últimos anos têm sido desenvolvidos esforços no sentido de construir um modelo completo a ponto de definir características físicas e outras propriedades de cada elemento de construção. As iniciativas mais promissoras resultam, directa ou indirectamente, do trabalho iniciado com o programa ISO-STEP. Este projecto visa desenvolver um modelo para produtos (incluindo produtos de construção) independente de qualquer aplicação informática (ver 2.3.5.3.7).

O grau de pormenorização deste tipo de modelos permite-lhes incluir informações que transcendem as características dos seus componentes. Com efeito, para além da definição de um conjunto de propriedades para cada componente individual ou família de componentes, é possível estabelecer relações entre os vários componentes a colocar em obra. Estas relações serão mantidas, mesmo em caso de se proceder a alterações no projecto. As relações definidas no modelo podem ser simplesmente geométricas, por exemplo, uma parede interior poderá ser definida entre duas paredes vizinhas que lhe são perpendiculares, mas podem assumir a forma de restrições à implementação de determinada solução construtiva.

Isto significa que, para além de informação, é possível incorporar conhecimento num modelo desta natureza. É também possível transferir esta informação entre diversas aplicações, por exemplo, CAD, análise estrutural, térmica ou acústica, aplicações ERP, etc. Por outro lado, importa considerar algumas desvantagens significativas inerentes à adopção de um modelo completo:

a.       Dificuldade em actualizar modelo:

Mesmo que a base de dados de materiais e componentes do modelo fosse abrangente (o que suporia um volume de trabalho verdadeiramente prodigioso), o aparecimento de novos materiais implicaria um processo de actualização constante e uma disponibilização, por parte dos fornecedores ou outros agentes, de toda a informação considerada relevante para as aplicações a utilizar. Toda a informação teria de ser validada antes de ser incluída no modelo. A prescrição de materiais e componentes que não estejam completamente definidos na base de dados poderia inviabilizar a utilização de um modelo para análise, por exemplo.

b.      Introdução de alterações significativas nos processos de trabalho, especialmente ao nível da fase de projecto:

Por um lado, parece evidente que este tipo de abordagem reduziria o trabalho relacionado com a introdução de dados e que facilitaria a alteração de dados de projecto. Permitiria, por exemplo, actualizar o modelo estrutural de um edifício directamente a partir de uma alteração na posição de um pilar definido no seu modelo geométrico (isto é, o projecto de estabilidade estaria ligado ao projecto de arquitectura).

Por outro lado, considera-se que uma ferramenta desta natureza poderá tender a condicionar a adopção de soluções construtivas, dificultando a implementação de soluções que não sejam devidamente suportadas pelo modelo[3]. A adopção de soluções “mistas”, em que algumas peças seriam definidas no modelo e outras seriam especificadas e desenhadas segundo os processos usuais parece pouco viável, uma vez que este tipo de abordagem corromperia a integridade do modelo. Uma solução alternativa passaria pela possibilidade de criar novos componentes e regras ou pela possibilidade de alterar as definições existentes, isto é, por permitir editar o modelo padrão. Esta solução permitiria manter a integridade do modelo (embora crie o risco de corrupção através da introdução de dados inadequados, não validados), mas levaria a uma inevitável disseminação de modelos incompletos, com informações não validadas. Para além disto, obrigaria os utilizadores a dominar um conjunto de operações complexas para a definição de novos elementos de construção. Actualmente esses modelos são criados em linguagens de programação específicas (EXPRESS, NIAM, etc.) e é pouco crível que a comunidade de projectistas adopte este tipo de procedimento. Esta previsível dificuldade em produzir alterações no modelo predefinido ou em aceitar soluções “mistas” pode resultar numa situação de “tudo-ou-nada” em que apenas os componentes definidos no modelo podem integrar o projecto a definir.

c.       Pode ser vontade de qualquer interveniente manter sigilo sobre alguns dados, quer por os considerar confidenciais (rendimentos de mão de obra, por exemplo), quer por desejar prevenir a utilização dos seus elementos de análise para fins imprevistos.

Alguns autores sugerem simplesmente que a introdução de toda a informação relacionada com um edifício num formato digital é dispendiosa, ineficiente e desnecessária (Johnson et al. 1999).

Outras críticas aos modelos completos apontam a lentidão do seu desenvolvimento e a elevada complexidade associada à sua implementação (Behrman 2002). As dificuldades apontadas são inerentes à imposição de um formato padrão por parte de um conjunto limitado de organizações – implementação top-down.

2.3.3.2      Avaliação de diferentes tipos de abordagem ao desenvolvimento de formatos padrão

O desenvolvimento de formatos padrão para as tecnologias de informação apresenta já uma história longa. A World Wide Web, por exemplo, foi construída sobre um conjunto muito bem sucedido de formatos, incluindo a linguagem HTML – Hypertext Markup Language – e o formato XML – Extended Markup Language.

As abordagens seguidas durante o desenvolvimento destes formatos podem ser divididas em duas categorias distintas (Behrman 2002):

a.       Abordagens minimalistas: As abordagens do tipo minimalista valorizam formatos padrão simples e a sua rápida aceitação por parte da comunidade de utilizadores. É uma abordagem do tipo bottom-up que começa com um conjunto limitado de regras de representação. O desenvolvimento do formato é iterativo e empírico – o formato vai sendo ampliado à medida que é bem sucedido na resolução de problemas concretos. Alguns exemplos que resultam de abordagens ao desenvolvimento do tipo minimalista são as linguagens HTML, SQL e C e o protocolo TCP/IP.

b.      Abordagens estruturalistas: As abordagens do tipo estruturalista valorizam formatos padrão completos e detalhados. É uma abordagem do tipo top-down que começa com um modelo de nível elevado e que prossegue depois para níveis mais baixos, onde o detalhe é maior. Frequentemente, o processo de desenvolvimento é muito lento e a tarefa tende a afigurar-se colossal. As aplicações práticas deste tipo de tecnologias tendem a não surgir até que o modelo atinja um nível de desenvolvimento suficientemente detalhado, pelo que a sua aceitação por parte da comunidade de utilizadores é, regra geral, demorada. Entre as iniciativas que seguem abordagens deste tipo conta-se o Standard for the Exchange of Product Model Data (STEP).

Considera-se que as abordagens de desenvolvimento que seguem exclusivamente a via estruturalista são menos aptas a solucionar os problemas concretos que se colocam à indústria da construção. A dimensão do problema, as características da indústria e a prática tradicional (já avaliados nos capítulos anteriores) são obstáculos relevantes à imposição de um formato padrão abrangente seguindo um desenvolvimento do tipo top-down.

Com efeito, afigura-se provável que, mesmo modelos que mereceram a aceitação geral da comunidade académica, não gozam da mesma popularidade junto da comunidade técnica. Os modelos “completos” são extremamente interessantes na óptica da comunidade académica, não só pela clara atractividade associada ao conceito da possibilidade de representar, de forma completa, um produto de construção em todas as suas fases, mas também porque abre um novo e vasto campo de investigação na área da gestão da informação. Por outro lado, importa reflectir acerca da reduzida aceitação que este tipo de modelos goza ainda junto da comunidade técnica. É importante admitir que a comunidade técnica não reconhece actualmente valor – no sentido económico da expressão – nas potencialidades oferecidas por estes modelos a ponto de justificar uma adesão significativa às novas práticas que lhes estão associadas. Mesmo nos ainda raros casos em que os técnicos utilizam modelos completos e lhes reconhecem valor, referem-se frequentemente apenas a aspectos limitados dos modelos, por exemplo a aspectos geométricos usados na detecção de incompatibilidades entre projectos de especialidades distintas (ver casos descritos em 2.3.5.3.4). Um estudo consultado (McGraw Hill Construction 2007) revela que 80% dos engenheiros que utilizam BIM, usam esta tecnologia para produzir imagens tridimensionais dos produtos de construção (renders), 50% usam BIM para detectar incompatibilidades (geométricas) de projecto e que apenas 46% o usam para efectuar análises estruturais, por exemplo. Com efeito, os BIM continuam a não cobrir todos os domínios na área do projecto, nem todas as fases do projecto (Weise et al. 2008).

Em síntese, importa considerar a hipótese de que os modelos “completos” não têm dado resposta satisfatória aos problemas concretos colocados pelos técnicos hoje.

Considera-se que pode ser preferível uma solução alternativa que permita incorporar alterações relativamente pequenas aos procedimentos de trabalho actuais de forma a assegurar uma transformação gradual nos processos de trabalho. Esta visão não colide de forma alguma com o objectivo de criar um modelo completo, apenas se considera improvável que tal modelo possa ser adoptado pela comunidade técnica a curto ou a médio prazo e que não se deve esperar uma alteração brusca nos procedimentos habitualmente seguidos na construção. Admite-se que uma solução que permita a utilização de ferramentas informáticas habitualmente empregues nas diferentes fases do processo construtivo e que relacione a informação gerida por cada uma destas aplicações possui vantagens significativas sobre uma solução do tipo “tudo-ou-nada”. Uma solução deste tipo não exclui a possibilidade de usar modelos completos como repositórios de informação, tornando-os importantes para assegurar a interoperabilidade entre diferentes utilizadores e entre diferentes aplicações.

Um modelo que resulta de uma abordagem minimalista apresenta vantagens claras para a comunidade técnica dado que visa, em primeiro lugar, dar resposta aos seus problemas concretos. Durante a fase de desenvolvimento, podem coexistir diversos modelos concorrentes para um mesmo fim que, eventualmente, poderão ser selectivamente agregados num modelo de espectro mais alargado. Estes modelos podem ser desenvolvidos de modo independente – não existe uma obrigatoriedade na adesão a outro tipo de formatos padrão, nem uma necessidade absoluta de desenvolver vários modelos de modo coordenado. No caso da construção, seria possível (e previsível) assistir-se a um rápido surgimento de modelos para as áreas em que o seu desenvolvimento e a sua implementação seriam mais vantajosas e mais fáceis, nomeadamente nas actividades com uma componente de pré-fabricação mais acentuada. Dado que o objectivo principal de cada participante no processo de desenvolvimento será a resolução dos seus problemas específicos (ou os problemas do sector onde se insere) o processo poderia nunca vir a culminar num modelo completo. Ainda assim, é possível conseguir uma representação global de um produto de construção através de uma federação de modelos parciais em alternativa a um único modelo completo (Turk 2001).

Encontrou-se, na bibliografia consultada, uma conclusão acerca da abordagem mais vantajosa a seguir na produção de formatos padrão. O autor, embora alerte para a necessidade de avaliar cada caso separadamente, sintetiza da seguinte forma as conclusões reunidas após a análise de um conjunto significativo de esforços de desenvolvimento de formatos padrão em áreas distintas:

[…] Formatos padrão bem sucedidos começam pequenos e crescem com um consenso em torno de um núcleo central. […] A [conclusão acerca da abordagem ao desenvolvimento] que emerge da comunidade de especialistas em standards reflecte as seguintes lições: reunir um conjunto restrito de fornecedores, redigir uma especificação curta e simples que cubra os aspectos importantes, omitir os aspectos não fundamentais, prever eventuais expansões ou contracções da especificação, identificar oportunidades para a testar no mundo real e lançá-la tão cedo quanto for possível. (Libicki 1995)

2.3.3.3      Modelos completos e modelos parciais: Tabela resumo

Segue-se uma tabela que resume o conteúdo do presente subcapítulo:

Tabela 2 – Modelos completos e parciais (síntese)

Modelo Completo

Modelo Parcial

Objectivo

Pretende vir a constituir um formato padrão

Visa dar resposta a um ou mais problemas específicos

Dimensão

Modelo detalhado e completo

Modelo constituído por um conjunto limitado de regras de representação, pelo menos na fase inicial

Interoperabilidade

Âmbito alargado do modelo permite que seja usado para a partilha de informação entre sistemas com diferentes finalidades

Interoperabilidade pode ser garantida por uma federação de modelos, não por um modelo único

Abordagem ao desenvolvimento

Abordagem estruturalista do tipo  top-down

Abordagem minimalista do tipo  bottom-up

Intervenientes no processo de desenvolvimento

Equipa restrita centraliza desenvolvimento

Disseminação de equipas de desenvolvimento

Envolvimento da comunidade de utilizadores

Aplicações práticas do modelo só são possíveis depois de este ter atingido um grau de desenvolvimento significativo. Comunidade de utilizadores tem um impacto reduzido no desenvolvimento.

Modelo avança por processo iterativo. Validação empírica do modelo por parte de comunidade de utilizadores condiciona desenvolvimento de sucessivas versões.

Adopção

Demorada

Adopção ou extinção rápidas

Exemplos

ISO-STEP, IFC

TCP/IP, HTML, XML, SQL, C

2.3.4       Compatibilização de formatos

Naturalmente, a compatibilização de dados codificados por aplicações comerciais distintas é uma questão que importa analisar. A generalidade das aplicações informáticas utiliza preferencialmente dados escritos em formatos que lhes são específicos (designados habitualmente por proprietary formats), mas tem-se assistido a um esforço no sentido de passarem a aceitar também formatos alternativos cuja estrutura é de conhecimento público.

Em oposição aos formatos suportados de forma exclusiva por uma determinada aplicação estão os exchange formats (usando a designação anglo-saxónica habitual), que permitem que um mesmo ficheiro possa ser lido por diferentes aplicações.

Actualmente, um número crescente de aplicações comerciais permite a implementação de funções definidas pelo utilizador que podem ser usadas, por exemplo, para a troca de dados com aplicações externas.

No sector da construção, um exemplo que ilustra a distinção entre estes dois tipos de formatos e as consequências da adopção de um ou de outro como padrão é o dos formatos usados pelas aplicações de CAD. Actualmente, os formatos padrão ad-hoc para a representação gráfica de produtos da construção são o DWG e o DXF, ambos desenvolvidos pela Autodesk. Existem outros formatos padrão, como o IGES que é certificado pelo ANSI, mas são claramente menos utilizados. Com efeito, o formato IGES foi integrado no programa STEP, tendo o seu desenvolvimento abrandado de tal forma que a sua última versão data de 1999 (IGES 1999) (a última versão oficial foi apresentada em 1996).

De entre os formatos referidos, o DWG foi o primeiro a ser desenvolvido. É considerado o formato de representação mais utilizado na área do desenho assistido por computador e é propriedade da Autodesk. Os detalhes acerca da estrutura deste tipo de ficheiros só recentemente têm vindo a ser tornados públicos o que, para além das questões relacionadas com os direitos de autor, impedem a sua utilização por parte de outras empresas de software. Para promover a partilha de informação com outras aplicações foi desenvolvido o formato DXF, que não é completamente compatível com o formato DWG.

A existência de um formato padrão proprietário restringe a possibilidade da participação da comunidade de utilizadores no seu desenvolvimento. Para além disso, tende a reflectir-se na adopção generalizada de um conjunto limitado de aplicações comerciais padrão em função da atribuição ou não de licenças de utilização do formato a outras empresas de software.

2.3.5       Vectores de desenvolvimento: ERP, BIM e aplicações à medida

2.3.5.1      Aspectos gerais

Perante o crescente número de iniciativas de desenvolvimento de sistemas de informação para a construção, partindo da comunidade académica, das empresas do sector ou de empresas de software, importa efectuar aqui uma análise preliminar sucinta dos vectores de desenvolvimento previsíveis, bem como uma apreciação crítica de algumas opções possíveis. Esta análise será ampliada nos capítulos seguintes.

Os vectores de desenvolvimento escolhidos correspondem a tecnologias distintas, embora eventualmente complementares, admitindo-se que virão a constituir a base da generalidade dos sistemas de informação para a construção no futuro previsível. Considera-se que, nas suas áreas específicas, os sistemas ERP e BIM serão as tecnologias chave no sector da construção. Ainda assim, e especialmente nesta fase em que estes sistemas começam a ser disseminados e adaptados às necessidades das organizações, é provável que as “aplicações à medida”, que podem ser desenvolvidas no interior das organizações, venham a ter um papel significativo como complemento dos sistemas referidos.

Admite-se que os sistemas ERP, pela sua versatilidade e pela sua disseminação actual, continuem a constituir as ferramentas de base para a gestão de recursos e procedimentos das empresas. Poderão ainda ser úteis para a gestão da comunicação interna das empresas e para a comunicação entre as empresas e o exterior (parceiros e clientes).

Os modelos de informação para a construção (BIM) baseados em especificações padrão (IFC ou outra) serão usados para a representação de produtos de construção e farão a ligação entre as suas representações específicas tradicionais (por exemplo arquitectura, estruturas, infraestruturas, gestão da construção, etc.). Admite-se que as actuais ferramentas informáticas tenderão a evoluir de forma a permitirem a importação/exportação de dados de e para estes formatos padrão.

As aplicações à medida poderão vir a ser o elemento que permitirá que cada organização preserve algumas das suas eventuais vantagens competitivas (baseadas em conhecimento e em procedimentos particularmente eficientes), evitando que os procedimentos padrão associados à adopção dos novos sistemas nivelem em absoluto os métodos de trabalho de empresas de um mesmo sector. Para além disso, é possível que algumas empresas de pequena ou média dimensão possam vir a recorrer a este tipo de aplicações como uma alternativa mais barata para implementar apenas algumas das funcionalidades oferecidas por sistemas comerciais, de forma a obter sistemas adequados aos seus procedimentos actuais.

Refere-se, contudo, que as “aplicações à medida” não são vistas, de forma alguma como tecnologias alternativas aos sistemas ERP e BIM, mas antes como um complemento destes sistemas mais poderosos, permitindo combinar as suas potencialidades, adicionar-lhes funções ou adaptá-los às características de cada organização. Em sentido figurado, não se fala aqui em três vectores de desenvolvimento que funcionam em paralelo, preferindo-se ver o desenvolvimento baseado em dois vectores principais e num vector complementar.

2.3.5.2      Enterprise Resource Planning (ERP)

2.3.5.2.1            Aspectos gerais

Os sistemas ERP (Enterprise Resource Planning) estão actualmente muito divulgados entre as empresas de construção não sendo, contudo, concebidos originalmente para este sector da indústria. Na verdade, embora os primeiros sistemas ERP tenham surgido há mais de quarenta anos, muitas das empresas de construção nacionais de maiores dimensões ainda não usavam, já depois do ano 2000, sistemas deste tipo.

Este tipo de sistemas pode apresentar significativas variações, quer ao nível da forma, quer ao nível funcional, pelo que se torna de algum modo difícil definir de forma sucinta o que é e o que faz um sistema ERP. Em termos gerais, este tipo de software procura integrar todos os dados e todos os processos de uma organização num sistema único. O sistema pode ser composto por diversas aplicações distintas, instaladas em computadores diferentes mas é frequente que todos acedam a uma base de dados única. A base de dados torna-se assim o componente que une todo o sistema. Embora um sistema que se limite a interligar de alguma forma duas ou mais aplicações distintas de forma a relacionar os respectivos dados possa ser considerado um sistema ERP, o termo é mais frequentemente aplicado para denominar aplicações mais abrangentes.

Os sistemas ERP têm vindo a evoluir desde as suas primeiras aplicações, durante os anos 60, até à actualidade. Os primeiros sistemas, desenvolvidos em linguagens de programação generalistas como o Cobol, o Algol ou o Fortran, ocupavam-se de dados operacionais (ver Fig. 7), por exemplo no controlo de inventários ou no processamento de folhas de vencimento dos trabalhadores (Correa 2004). Este tipo de dados é usado na tomada de decisões operacionais, correspondentes a um nível inferior na hierarquia de uma organização. São úteis para o funcionamento rotineiro da empresa embora não sejam usados directamente na tomada de decisões estratégicas, de nível superior. Em termos de hardware, estes primeiros sistemas estavam instalados em grandes computadores centrais (mainframe).

Actualmente, o desenvolvimento dos sistemas ERP tornou-os ferramentas úteis para a gestão de topo das organizações. É a estes sistemas mais recentes, que integram todos os processos de negócio da empresa, não só os que estão directamente relacionados com a produção, que se aplica habitualmente a designação ERP.

Estes sistemas funcionam com base na tecnologia cliente/servidor (ver Fig. 8) e apresentam frequentemente interfaces web. Esta característica dos mais recentes sistemas ERP torna-os especialmente interessantes para a indústria da construção onde os centros administrativos e de decisão (as sedes das empresas) estão habitualmente distantes dos centros de produção e infraestruturas de apoio (as obras, os armazéns, as empresas de pré-fabricação, etc.).

Os sistemas ERP são habitualmente adquiridos como um pacote, eventualmente adaptável às características de cada organização por meio de um conjunto de módulos opcionais específicos para o sector em que esta opera ou, em alguns casos, desenvolvidos especificamente para a empresa.

Em alternativa, é possível desenvolver de raiz um sistema simplificado que se ajuste aos requisitos determinados pela organização.

Fig. 8 – Arquitectura cliente-servidor

2.3.5.2.2            Sistemas ERP: Vantagens e oportunidades

A implementação de sistemas ERP apresenta um conjunto de vantagens potenciais mas também alguns desafios que podem comprometer o seu sucesso. Entre as vantagens contam-se as seguintes (Laudon, Laudon 2002):

a.       Estrutura e organização da empresa

Os sistemas ERP podem contribuir, por um lado, para o desenvolvimento de uma estrutura da empresa até então impossível (por exemplo, reduzindo ou eliminando a influência da distância física de um sector da empresa relativamente à sede no que diz respeito à transmissão de informação). Por outro lado, contribuem para uma uniformização de processos seguidos na empresa: uma organização pode trabalhar da mesma forma, em qualquer local. As barreiras definidas pela estrutura funcional da organização tornam-se menos rígidas em consequência da transferência livre de informação.

b.      Processos de gestão baseados em conhecimento

A disponibilidade imediata de dados provenientes de diferentes sectores da organização melhoram os processos de reporte e de tomada de decisão.

c.       Plataforma tecnológica unificada

Um sistema ERP deve ambicionar a integração de todos os processos relacionados com a produção e transmissão de informação, criando um único repositório de informação para o efeito. Os dados usados em toda a organização serão definidos de forma padrão.

d.      Operações mais eficientes e processos de negócio orientados pelo cliente

A organização de um sistema ERP facilita a partilha de informação com o cliente e permite que este apresente pedidos ao sistema. Uma empresa industrial, por exemplo, pode ligar o sistema de encomendas com o sistema de informação para o sector de produção de forma a produzir apenas em função das encomendas efectivamente recebidas, minimizando o volume do inventário. Este tipo de vantagens tem sido associado frequentemente a empresas industriais em geral, mas é igualmente aplicável ao sector da construção, em particular na fase de projecto ou nas tarefas relacionadas com o aprovisionamento.

2.3.5.2.3            Sistemas ERP: Desvantagens e ameaças

Por outro lado, o investimento necessário à implementação de um sistema deste tipo e as profundas alterações a impor aos procedimentos da organização são frequentemente obstáculos que se opõem à introdução dos sistemas ERP. Entre os principais desafios que se apresentam às organizações que decidem adoptar sistemas ERP contam-se os seguintes (Laudon, Laudon 2002):

a.       Implementação difícil

Os sistemas ERP introduzem mudanças dramáticas no funcionamento das empresas. Os procedimentos, a estrutura e a cultura da organização sofrem alterações significativas e simultâneas, exigindo-se ainda que o funcionamento da empresa não seja interrompido. A adaptação da empresa ao novo sistema pode demorar anos e, durante este período, a inevitável resistência à mudança pode inviabilizar as alterações pretendidas ou reduzir o seu âmbito.

b.      Custos iniciais elevados com benefícios a prazo

O custo inicial associado a estes sistemas é elevado e a sua visibilidade é grande. Os benefícios, por outro lado, surgem a prazo e a sua quantificação é, na fase de implementação, difícil se não impossível. Refere-se ainda que, para além dos custos iniciais, a organização que implementa um sistema ERP deve considerar um conjunto de custos “ocultos” que incluem custos associados a quebras de produtividade, custos de formação, etc. (ver 2.3.5.2.5)

c.       Pouca flexibilidade

Os sistemas ERP são normalmente complexos e a sua instalação e manutenção é difícil, estando a cargo de um conjunto de pessoas treinadas para o efeito. Por outro lado, a integração de dados de diversos sectores da empresa tende a resultar na criação de um repositório de informação de alguma forma rígido, dificultando a introdução de alterações na estrutura de dados inicial. Normalmente, os fornecedores prestam serviços que permitem adequar o pacote ERP standard às características da empresa mas, ainda assim, pode afirmar-se que esta flexibilidade potencial corresponde a custos acrescidos.

d.      Desperdício de vantagens decorrentes de processos estabelecidos

Os sistemas ERP comerciais podem não se adaptar aos processos seguidos na empresa, o que se pode traduzir num desperdício nos casos em que esses processos encerram vantagens competitivas para as empresas que os seguem.

2.3.5.2.4            Redes industriais

Um conceito directamente relacionado com o dos sistemas ERP é o de rede industrial (industrial network na bibliografia em língua inglesa). Uma rede industrial é uma extensão do conceito de ERP e resulta na interligação, por meio de um sistema informático, de um conjunto de empresas. As empresas podem trocar informações acerca de inventários, encomendas, etc. As redes industriais dividem-se em horizontais (caso agrupem empresas do mesmo sector, incluindo empresas concorrentes), ou verticais (se relacionarem empresas incluídas numa única cadeia de fornecimento). As redes industriais verticais são as mais comuns e são usadas frequentemente para coordenar fornecimentos (Laudon, Laudon 2002).

2.3.5.2.5            Custos ERP

Os custos de aquisição, implementação e manutenção dos sistemas ERP são elevados e incluem custos com maior ou menor visibilidade, associados a diferentes opções de instalação.

Para além dos custos de aquisição de uma licença de utilização para o software ou de “aluguer” do serviço correspondente, há que considerar custos periódicos de manutenção (incluindo actualizações do software, serviço de apoio técnico e acesso a documentos técnicos) e formação profissional.

Os custos de aquisição do software podem variar significativamente, desde algumas centenas de milhar até alguns milhões de euros (Koch 2006) em função da marca, das funcionalidades oferecidas (as aplicações são habitualmente distribuídas sob a forma de um conjunto de módulos, alguns dos quais opcionais) e do número de utilizadores abrangidos pela licença. Os custos referidos são, em larga medida, confirmados por outras publicações consultadas (Enterprise Ireland 2002).

Refere-se que existem ainda, embora com um peso no mercado de construção desconhecido, soluções ERP livres, sem custos de aquisição. Em alguns casos, as organizações que desenvolvem este software vendem módulos adicionais a instalar sobre o produto base ou prestam serviços de consultadoria, de implementação ou de manutenção do sistema.

A aquisição da licença de utilização é vista como o “topo de um iceberg” (Enterprise Ireland 2002), sendo necessário considerar os referidos custos anuais de manutenção que variam, tipicamente, entre os 17.5% e os 22% para além de um conjunto significativo de custos menos visíveis. Uma regra empírica sugere que o custo total de um sistema ERP, incluindo os chamados custos ocultos, será de cerca de seis vezes o valor da licença de utilização (Koch 2006).

2.3.5.3      Building Information Model (BIM)

2.3.5.3.1            Aspectos gerais

O acrónimo BIM (Building Information Model ou Building Information Modeling) surge frequentemente associado a algumas das mais recentes aplicações desenvolvidas para a indústria da construção. Será usado, no presente trabalho a designação BIM no lugar da sua tradução para português MIC (Modelo de Informação para a Construção), dada a sua actual disseminação, tanto em publicações científicas como em aplicações comerciais.

Considera-se que os BIM são uma tecnologia que poderá vir a desempenhar um papel central na indústria da construção nos próximos anos. Dada a relevância desta tecnologia para o trabalho elaborado, decidiu-se dar um maior destaque a este tema relativamente aos abordados em 2.3.5.2 e em 2.3.5.4.

Serão apresentados, de forma sucinta, os modelos mais próximos de constituírem um standard para a indústria da construção e o percurso percorrido desde os primeiros modelos de informação até aos BIM actuais (ver 2.3.5.3.6 e 2.3.5.3.7).

Serão ainda discutidos alguns aspectos tecnológicos que servem de base à estrutura dos BIM.

2.3.5.3.2            BIM: Apresentação

A designação BIM é, por vezes, erradamente atribuída a representações tridimensionais de produtos de construção. Este equívoco deve-se, provavelmente, ao aspecto gráfico das aplicações que recorrem a este tipo de tecnologia. Em alguns casos, esta nova geração de aplicações é incorrectamente entendida como uma nova versão dos produtos CAD mais utilizados. Na verdade, um BIM é justamente aquilo que a tradução directa sugere: um modelo de informação para a construção, que pode ter um grau de simplificação maior ou menor. Em rigor, pode nem conter informação acerca da geometria dos produtos de construção ou, pelo contrário, a esse tipo de informação pode acrescentar, por exemplo, dados de planeamento ou características físicas dos materiais que compõem os produtos. Pode afirmar-se então que um BIM pode ser mais ou menos completo em função da natureza, da variedade e do volume da informação que o constitui. A percepção mais geral para um BIM, contudo, será a de um modelo tridimensional com informação complementar associada a cada componente do produto de construção. Usualmente, a cada componente correspondem, no mínimo, a especificação da sua função (por exemplo, parede, pilar, isolamento, etc.) e a sua identificação (por exemplo, P1, V3, etc.). Esta é a abordagem seguida pelas aplicações comerciais mais usuais.

As mais modernas versões dos modelos de informação para a construção incluem não só os elementos de construção mas também informação acerca das relações entre elementos, alguns dos quais abstractos. Um espaço, por exemplo, pode estar limitado por quatro paredes. As paredes, por sua vez, são limitadas superior e inferiormente por lajes e lateralmente por duas outras paredes. Qualquer alteração na posição de uma das paredes resultará na alteração de propriedades dos elementos com ela relacionados, por exemplo, a área do espaço adjacente ou o comprimento das paredes que a limitam. Alguns modelos, por exemplo o IFC – Industry Foundation Classes (ver 2.3.5.3.7), permitem a associação não só de atributos físicos mas também de informação sobre planeamento dos trabalhos, indicações acerca da aprovação ou não de cada trabalho, etc. (IAI 2006).

Actualmente, estão disponíveis no mercado diversos produtos que recorrem a esta tecnologia. Muitas das aplicações permitem ainda o relacionamento dos componentes (definidos pela sua geometria e pela sua função) com uma base de dados de componentes num formato que a torna acessível a partir de aplicações externas (exchange format). Esta realidade potencia a utilidade de um modelo de informação para a construção: é possível associar interfaces poderosas e aplicações padrão a bases de dados acessíveis a qualquer entidade. Desta forma, os modelos de informação poderão ser editados, usando ferramentas simples, por qualquer entidade ligada ao sector da construção, condição necessária ao desenvolvimento de um modelo abrangente e actualizado.

Como se refere em 2.3.5.3.6.3 e 2.3.5.3.7, desde meados da década de 70, diferentes países têm promovido esforços a nível nacional ou têm participado activamente em iniciativas internacionais no sentido de estabelecer um modelo de informação para edifícios que abranja todas as fases do processo construtivo. Não se conhecem iniciativas nacionais equivalentes em fase de estudo, claramente não em fase de implementação. Desconhece-se ainda a posição das principais organizações da construção nacional acerca dos BIM. Considera-se que o desenvolvimento de um formato padrão de representação de produtos da construção é um passo indispensável à evolução do sector e que, caso não se procure estabelecer algumas bases de trabalho, o país acabará por importar essa tecnologia numa fase de evolução mais adiantada, limitando a possibilidade de introduzir alterações no sentido de a adaptar às práticas nacionais.

O desenvolvimento de um modelo de informação completo para a construção será, apesar do considerável volume de trabalho já realizado, um esforço de desenvolvimento contínuo, de médio a longo prazo. As metas que um modelo deste tipo se propõe atingir são ambiciosas pelo que se corre o risco de não produzir resultados significativos no imediato (Eastman et al. 2008): não basta que o modelo exista, terá de corresponder às exigências reais da comunidade técnica. Assim, poderá ser desejável tirar partido da heterogeneidade do sector da construção no sentido de definir áreas de actuação prioritárias. Com efeito, o universo dos intervenientes no processo construtivo é extremamente vasto, sendo que o nível de envolvimento de cada participante é distinto (quanto ao âmbito, à natureza, ao espaço e ao tempo). Considera-se que é importante destacar algumas destas fases no sentido de produzir rapidamente resultados que possam ser reconhecidos por um conjunto de agentes. Este subconjunto da comunidade técnica tratará de propagar a mudança a outros intervenientes com ela directamente relacionados, seguindo um processo bottom-up. Isto só será possível se se procurar adaptar as novas ferramentas às práticas correntes. Considera-se, pois, que se deve começar por adaptar as ferramentas às práticas em vez de impor o oposto.

É importante adoptar uma perspectiva acerca dos sistemas de informação que não se limite a enunciar as hipotéticas vantagens económicas decorrentes da adopção de novas tecnologias mas que procure descrever o impacto que elas produzem no interior das organizações. Com efeito, o impacto das novas tecnologias não se restringe a uma redução da mão de obra e do tempo necessários à realização das actividades. As organizações podem adoptar ou rejeitar uma nova tecnologia por razões que transcendem os potenciais ganhos imediatos de produtividade ou de qualidade que esta possa anunciar. Práticas de trabalho instituídas, hábitos pessoais ou perspectivas individuais de carreira são apenas alguns dos factores que podem influenciar o sucesso de uma nova tecnologia implementada numa organização. Assim, para além da teoria económica, importa aplicar à investigação dos sistemas e tecnologias da informação uma abordagem baseada na teoria comportamental, que permita considerar aspectos sociais, culturais e políticos associados à adopção destas tecnologias (Pereira 2005). Esta abordagem permite apontar, por exemplo, razões que explicam o insucesso de tecnologias baseadas em pressupostos técnicos sãos – processos aparentemente eficientes – quando aplicadas a organizações reais. Não se pretende efectuar, no presente trabalho, uma análise às teorias económicas e comportamentais aplicadas aos sistemas de informação, remetendo-se esta descrição para (Laudon, Laudon 2006) e (Pereira 2005).

2.3.5.3.3            BIM: Vantagens e oportunidades

2.3.5.3.3.1     Benefícios esperados: Aspectos gerais

Os BIM surgem como uma tecnologia de tal forma promissora que se pode afirmar que quaisquer esforços no sentido de melhorar gestão de informação devem ser enquadrados num modelo de informação. De outra forma, as iniciativas terão um carácter algo avulso e um tempo de validade limitado pelo inevitável aparecimento de tecnologias de âmbito mais alargado, actualmente em desenvolvimento.

Entre as potenciais vantagens identificadas para a indústria da construção, associadas à adopção deste tipo de tecnologia, contam-se as seguintes (El-Desouki, Hosny 2005):

a.       Pesquisa e obtenção eficientes de documentos específicos;

b.      Propagação de alterações rápida e directa;

c.       Automatização de fluxos de trabalho;

d.      Compilação da informação relevante;

e.       Integração de processos de produção e de gestão documental que resultam numa economia de esforços ao nível administrativo;

f.       Simplificação da recolha de informação produzida em projectos anteriores ou proveniente de fontes de informação externas;

g.      Criação de condições favoráveis para a realização simultânea do trabalho de diversos projectistas, resultando em prazos mais curtos para o desenvolvimento de projectos;

h.      Eliminação da introdução repetida de dados, evitando-se os erros associados;

i.        Redução de esforços redundantes relacionados com a repetição de tarefas de projecto e com as verificações das especificações elaboradas;

j.        Aumento de produtividade devido a uma partilha de informação mais rápida e isenta de ruído;

k.      Simplificação da introdução de modificações em projectos;

l.        Melhoria da cooperação interdisciplinar.

As vantagens e oportunidades associadas à adopção de BIM são apresentadas em maior detalhe e são justificadas nos pontos seguintes.

2.3.5.3.3.2     Alteração nas práticas de trabalho

A adopção de modelos de informação produzirá alterações significativas nas práticas de trabalho tradicionais. Uma previsível mudança, da qual se pode esperar vantagens relevantes, é a antecipação de decisões de projecto exigida pela utilização dos BIM desde as primeiras fases do processo construtivo. A antecipação de decisões de projecto apresenta vantagens significativas relativamente às práticas usuais. Com efeito, os custos de alterações produzidas nos projectos de construção são tanto maiores quanto mais adiantada a fase do processo construtivo em que forem efectuadas. A Fig. 9 representa o impacto da antecipação de decisões de projecto na construção. O significado das quatro curvas representadas na figura é o seguinte:

1.      Possibilidade de produzir impacto nos custos e aspectos funcionais do projecto;

2.      Custo de alterações produzidas no projecto;

3.      Processo tradicional;

4.      Processo alternativo.

No eixo das abcissas, as letras A a G representam as sucessivas fases do processo construtivo:

A.    Promoção (pre-design, no original);

B.     Estudo prévio (schematic design);

C.     Projecto (design development);

D.    Projecto de execução (construction documentation);

E.     Procurement;

F.      Gestão da construção;

G.    Operação.

Fig. 9 - Vantagens decorrentes da antecipação de decisões de projecto. Curva de MacLeamy (CURT 2004)

Note-se que, apesar das vantagens funcionais decorrentes da antecipação de decisões de projecto, a prática corrente não favorece esta alteração. Com efeito, o fraccionamento de pagamentos habitualmente praticado nos contratos de projecto não corresponde ao maior esforço a realizar nas fases iniciais do projecto (ver, a este respeito as Instruções para o Cálculo dos Honorários Referentes aos Projectos de Obras Públicas). Os empreendimentos iniciados são frequentemente abandonados antes da conclusão do projecto de execução, pelo que o acréscimo do esforço na fase inicial do projecto poderá não ser traduzido numa efectiva compensação pelo volume de trabalho realizado (ver a este respeito o ponto 4 do Art.º 12º das ICHRPOP). Assim, a introdução deste tipo de tecnologia deve ser acompanhada por uma alteração nos procedimentos de contratação de projectos sob pena de se estar a transferir para o projectista um risco acrescido associado à não conclusão de um projecto por decisão do Dono da Obra.

2.3.5.3.3.3     Benefícios iniciais

Admite-se que os primeiros benefícios de uma eventual adopção de modelos de informação para a construção serão sentidos pelas empresas responsáveis pela elaboração de projectos, sob a forma de uma mais fácil compatibilização dos diversos projectos e de uma redução do volume de trabalho correspondente à introdução repetida de dados. A generalidade das peças desenhadas será produzida de forma automática, tal como as medições e serão actualizadas sempre que forem introduzidas alterações no projecto. É possível pesquisar incompatibilidades entre os diversos projectos de especialidade automaticamente e efectuar verificações da sua conformidade com os regulamentos aplicáveis. Admite-se que a antecipação de decisões de projecto, característica fundamental dos BIM relativamente às tecnologias tradicionais, aliada à verificação automática do projecto e à disponibilidade dos dados introduzidos para serem usados por aplicações informáticas a jusante, são factores que permitem antecipar um acréscimo da qualidade global dos projectos de construção como resultado da utilização destes modelos de informação. As vantagens iniciais serão sentidas pois, previsivelmente, na fase de projecto.

2.3.5.3.3.4     Previsíveis benefícios futuros

Embora se preveja que as primeiras entidades a sentirem as vantagens oferecidas pelos BIM sejam os projectistas, espera-se que se façam sentir efeitos benéficos de segunda ordem devidos à alteração dos processos de trabalho resultantes da introdução de uma nova entidade abstracta no processo construtivo: o repositório de informação. Com efeito, a existência de uma base de dados partilhada pelos diversos intervenientes, contendo a generalidade das informações produzidas durante o processo construtivo, alterará radicalmente a forma como é feita actualmente a gestão de informação. Para além das vantagens que foram apontadas anteriormente, relativas à fase de projecto, considera-se que os BIM podem produzir um impacto significativo ao longo de todo o processo construtivo:

a.       A partilha de informação deverá deixar de se fazer sob a forma de “pacotes fechados”, consubstanciados em documentos formais, passando a ocorrer, na generalidade dos casos, sob a forma de um acesso directo de cada interveniente a um modelo centralizado. Os benefícios directos desta alteração ultrapassam aqueles que resultam directamente da centralização da informação, nomeadamente a facilidade em assegurar que todos os intervenientes tenham acesso imediato à última versão de qualquer documento associado ao empreendimento. A alteração é mais profunda, assistindo-se a uma mudança de paradigma: abandona-se o procedimento habitual que consiste numa necessidade de que uma tarefa de projecto esteja concluída antes de se iniciar a tarefa seguinte, passando-se a uma forma distinta de trabalhar – as tarefas de projecto devem ser desenvolvidas em simultâneo, admitindo-se que há vantagens em que assim seja, não só em termos de eficiência (a sobreposição temporal de tarefas em alternativa ao seu encadeamento usando relações fim-início resulta, previsivelmente, numa redução no prazo total), mas também em termos da qualidade do projecto (criam-se condições para um verdadeiro trabalho de equipa entre projectistas, em que a colaboração de cada elemento passa a ter influência imediata nos trabalhos produzidos pelos outros).

b.      A disponibilidade de informação (não só de dados) num formato acessível a todos os intervenientes permitirá a automatização de grande parte das tarefas de gestão da informação a realizar por cada um deles. Serão de esperar benefícios, por exemplo, nas tarefas relacionadas com o aprovisionamento, com a contratação de serviços e com o planeamento dos trabalhos (incluindo o acompanhamento do progresso dos trabalhos) como resultado da integração dos modelos de informação com os sistemas ERP das empresas. Existem já soluções comerciais que permitem esta integração. Conforme foi referido anteriormente, também as tarefas de licenciamento das construções podem ser aligeiradas, fazendo-se uma verificação automática do cumprimento de regulamentos aplicáveis.

c.       A adopção deste tipo de tecnologia por parte de um conjunto significativo de intervenientes com peso no sector da construção poderá resultar numa pressão sobre as entidades com o fim de criar mecanismos que facilitem a automatização de processos. Para além do licenciamento de projectos, considera-se que os próprios regulamentos e documentos técnicos podem sofrer alterações no sentido de “suavizar” o percurso da informação ao longo do processo construtivo (ver Fig. 10). Neste contexto, destaca-se as vantagens que decorreriam (e que outros países experimentam já) da disponibilidade de especificações técnicas padrão.

Fig. 10 - Processo construtivo: Perda de valor entre fases. Adaptado a partir de (Bernstein 2005).

2.3.5.3.4            Exemplos de sucesso e de insucesso

2.3.5.3.4.1     Exemplos de sucesso

Embora os BIM sejam uma tecnologia relativamente recente em comparação com as tecnologias usualmente empregues em projectos de construção civil, já é possível apontar para alguns exemplos como casos de sucessos, situações em que as perspectivas para a introdução dos BIM são optimistas e, por outro lado, enumerar algumas experiências mal sucedidas de aplicação desta tecnologia.

A lista de grandes projectos que foram desenvolvidos de raiz usando BIM é já vasta e inclui edifícios emblemáticos, de grande dimensão como o Terminal 5 de Heathrow (Rebbeck 2006), a nova Estação Ferroviária de Munique, o Aeroporto de Berlim (Juli, Liebich 2006) e as Piscinas Olímpicas em Beijing (“o Cubo”) (ARUP 2004). Uma compilação relativamente extensa e detalhada de casos de estudo acerca da aplicação dos BIM a projectos reais pode ser consultada em (Eastman et al. 2008). A dimensão destes empreendimentos torna-os interessantes e demonstra as potencialidades desta tecnologia, mas o seu carácter excepcional não permite tomá-los como exemplo de aplicabilidade generalizada dos BIM ao sector da construção. Alguns autores questionam mesmo a possibilidade de se poder obter todos os benefícios potenciais dos BIM em projectos de grande dimensão, dadas as limitações técnicas actuais (Cook 2004).

Existe ainda um conjunto de projectos de menor dimensão em que os BIM foram usados, em maior ou menor grau. A análise destes casos será, porventura, mais interessante para avaliar a viabilidade desta tecnologia nos cenários mais correntes que se colocam aos profissionais do sector da construção. Ainda assim, muitos deles podem ser encarados como “casos piloto” em que a análise das potencialidades das novas tecnologias foi um dos objectivos do empreendimento. Naturalmente, perante este tipo de cenário, não se pode fazer uma aferição definitiva das vantagens decorrentes da utilização dos BIM, admitindo-se que as experiências podem implicar uma escolha de fornecedores e prestadores de serviço diferente do habitual ou a produção de documentos de projecto em formato tradicional, para além da representação BIM, para permitir a sua leitura por parte de todos os intervenientes (pelo menos perante as entidades licenciadoras).

Considera-se ainda que, para além de aferir a utilidade dos BIM na construção, importa avaliar que tipo de BIM se revela mais apto para solucionar os problemas de cada tipo de interveniente e para cada tipo de obra. Como se referiu no presente trabalho, coexistem actualmente especificações de âmbitos consideravelmente distintos pelo que dificilmente os resultados observados para um tipo de modelo poderão ser estendidos a outros tipos.

2.3.5.3.4.2     Avaliação da representatividade de casos de estudo documentados

Admite-se que os factores atrás referidos, que dificultam a generalização dos resultados das experiências documentadas de utilização dos BIM, se possam colocar a todos os projectos concretizados até ao momento em que se lançou mão desta tecnologia. Com efeito, pode afirmar-se que um exemplo representativo deveria incluir um conjunto de condições difíceis de reunir em simultâneo no imediato:

a.       Introdução dos BIM deve ocorrer nas fases iniciais do projecto

O modelo de informação não deve ser uma representação adicional do edifício a construir, entre um volume considerável de peças desenhadas e escritas nos seus formatos tradicionais. Deve ser desenvolvido desde o início de forma que a generalidade dos documentos de projecto possa ser gerada automaticamente a partir do modelo para posterior divulgação ou, de preferência, que este seja suficiente para as actividades de projecto, de gestão e de construção seguintes. Em síntese, um BIM só poderá realizar em pleno as suas potencialidades se for um verdadeiro repositório de informação.

b.      Apreciação de entidades licenciadoras deve incidir sobre BIM

A primeira entrega formal de um projecto de construção é geralmente a que se destina a licenciamento por parte das entidades competentes. A entrega inclui um conjunto de elementos obrigatórios, sob a forma de peças escritas e desenhadas, que implicam a sua exportação a partir de um BIM ou a sua elaboração de raiz usando tecnologias tradicionais. Esta passagem resulta invariavelmente num desperdício de informação, codificada no modelo e que não pode ser completamente transferida para o papel, para além de um gasto desnecessário de tempo e um risco de introdução de erros resultantes do registo repetido de dados pelos diversos intervenientes. Existe actualmente tecnologia que permite que a apreciação de alguns aspectos do modelo seja, em larga medida, automática e imediata (ver referência ao sistema CORENET em 2.3.5.3.5).

c.       Modelo deve ser usado como principal repositório de informação na fase de execução

Este objectivo é, obviamente, muito ambicioso. Conforme se referiu em 2.2.1, a construção civil nacional é caracterizada por uma proliferação de microempresas de construção que realizam um volume significativo dos trabalhos. A adopção dos BIM resultaria, no imediato, em duas consequências previsíveis: circulação de informação em formatos distintos, numa primeira fase, e selecção de subempreiteiros de acordo com a sua possibilidade de lidar com os elementos de projecto em qualquer formato, numa fase posterior. Não se prevê que as microempresas percam de alguma forma a sua utilidade para as grandes empresas de construção como resultado da introdução das novas tecnologias. Com efeito, a preparação de trabalhos actualmente realizada pelos empreiteiros gerais limita, em larga medida, o âmbito das funções técnicas dos subempreiteiros menores e não há razões para suspeitar que a introdução dos BIM iria alterar essa forma de trabalhar de forma significativa, pelo menos no imediato. Admite-se, contudo, que o domínio das novas tecnologias pode originar uma mais clara divisão entre empresas, em função das respectivas competências técnicas. Admite-se ainda que o desenvolvimento deste tipo de competências possa resultar numa maior estabilização das relações comerciais das empresas do sector da construção, reforçando a tendência de criação de cadeias de valor formadas por empresas que trabalham habitualmente em conjunto.

d.      Modelo deve interagir com sistemas de informação das organizações intervenientes

Na generalidade dos casos, um modelo não será desenvolvido por uma entidade única, resultando antes do esforço continuado dos vários participantes no processo construtivo. Cada uma das organizações intervenientes terá, eventualmente, um sistema de informação próprio, havendo vantagens óbvias em conseguir integrar a informação disponível no modelo com estes sistemas, designadamente com os sistemas ERP (ver Fig. 11).

e.       Intervenientes que operam durante a fase de utilização devem herdar o modelo de informação

O modelo de informação desenvolvido durante o processo construtivo pode ser usado pelo dono da obra, ainda antes da conclusão dos trabalhos, para apoiar a gestão operacional do edifício.

Fig. 11 – Interacção entre sistemas ERP das organizações e BIM. Adaptado a partir de (Stevens 2006)

As eventuais vantagens decorrentes do uso dos BIM serão, pois, cumulativas, admitindo-se que os diversos participantes possam beneficiar (ainda que indirectamente) da sua introdução e do seu alargamento a todas as fases do processo construtivo, de acordo com o referido em 2.3.5.3.3.

Assim, considera-se que o pleno aproveitamento das vantagens decorrentes da utilização dos BIM depende da sua implementação, desde a fase inicial do processo construtivo, por imposição do dono da obra.

2.3.5.3.4.3     Exemplos de insucesso

Na bibliografia consultada encontra-se um grande número de exemplos de sucesso na utilização de BIM. De acordo com os argumentos apresentados, nem todos os casos documentados devem ser entendidos como representativos, dado que frequentemente não retratam casos “típicos” da construção nem representam implementações “completas” de BIM tal como foram definidas neste subcapítulo. São normalmente destacadas as vantagens técnicas atribuídas aos BIM ao invés de eventuais ganhos de eficiência resultantes da sua aplicação.

A literatura é claramente menos abundante em exemplos de insucesso na utilização dos BIM. Ainda assim, é possível encontrar alguns casos em que empresas que , tendo testado esta tecnologia, não deram sequência à experiência, regressando aos processos mais tradicionais. Num exemplo apresentado publicamente (Pimentel 2006), foi retratada uma experiência de utilização de BIM por parte de um grande empreiteiro nacional, não se tendo concluído que ofereceriam vantagens decisivas relativamente aos procedimentos habituais no contexto actual da construção em Portugal. Relativamente a este exemplo, deve-se destacar que a implementação dos BIM terá sido feita apenas na fase de execução, pelo empreiteiro, pelo que se considera que o resultado não permite apontar esta tecnologia como inadequada para a construção nacional, mas reforça a afirmação apresentada no presente subcapítulo segundo a qual os BIM devem ser introduzidos nas fases iniciais do processo construtivo, em particular durante a fase de projecto. Realça-se ainda que o modelo adoptado terá sido um modelo completo, suportado por uma aplicação comercial reconhecida. Esta aplicação foi adoptada a título experimental a fim de averiguar as suas potencialidades, não com o fim de resolver qualquer problema concreto identificado pela empresa.

Averiguações sucessivas relativamente a este caso documentado de insucesso na adopção de tecnologias BIM revelaram que a empresa em causa decidiu prosseguir com os testes em novas obras, com resultados mais animadores. Actualmente, as ferramentas geométricas disponíveis permitem detectar incompatibilidades de projecto, o que é uma mais-valia reconhecida pela empresa.

2.3.5.3.5            Factores que favorecem mudança

Importa fazer uma reflexão no sentido de procurar identificar os factores que conduzem aos exemplos de sucesso apontados, em particular aqueles que se podem considerar como estruturais. Estes factores poderão dividir-se em locais (específicos de cada país) e globais (de carácter tecnológico).

Alguns dos factores que terão, por hipótese, favorecido a introdução dos BIM em países como a Noruega ou a Singapura não poderão ser reproduzidos em Portugal.

A Singapura, por exemplo, é uma cidade-estado de 648 km^2, com uma extensão máxima de 22 km de Norte a Sul e de 50 km de Este a Oeste. É um dos países de maior densidade populacional com cerca de 4600 habitantes por quilómetro quadrado, o que conduz a uma tipologia construtiva bastante uniforme, dominando a construção em altura. Este país é considerado um dos mais avançados ao nível das redes de telecomunicações. Para tal contribuem a sua pequena dimensão geográfica, uma economia em expansão e o empenho governamental no desenvolvimento de uma rede de telecomunicações de excelência (Minges et al. 2001). A estas condições junta-se a visão do Ministério do Desenvolvimento Nacional da Singapura que, desde 1995, desenvolve o sistema CORENET (COnstruction and Real Estate NETwork), considerado uma iniciativa significativa no campo das tecnologias de informação (Khemlani 2005). O governo tem colocado forte empenho nesta iniciativa, obrigando os distribuidores de software BIM a desenvolver cursos de formação para os compradores destes sistemas, pagando inclusivamente a quem os frequentar (Wix 2006).

A Noruega, um dos países que actualmente lidera o desenvolvimento de soluções BIM, procurou a experiência de Singapura como referência. As características geográficas e demográficas do país são muito distintas das de Singapura, apresentando uma densidade populacional de apenas 12.1 habitantes por quilómetro quadrado e uma área total de aproximadamente 385155 km^2. A população total é de aproximadamente 4.6 milhões de pessoas (curiosamente um valor semelhante ao encontrado na Singapura). O país tem uma experiência considerável no domínio das tecnologias da informação. A Noruega tem ainda uma forte tradição no âmbito da prefabricação, favorecida por um custo elevado da mão-de-obra e por um clima agreste que dificultam a aplicação de algumas tecnologias de construção habituais em Portugal, como a betonagem de elementos estruturais in-situ. O país dispõe ainda de um conjunto de regras de construção padrão, incluindo regras de medição e especificações técnicas, que podem ser incorporadas nos modelos de informação actuais. O governo norueguês empenhou-se na implementação de sistemas de informação para a construção em finais de 2000, ano em que teve início o projecto ByggSøk (Rooth 2004).

Entre os factores tecnológicos, deve destacar-se o desenvolvimento de estruturas de informação padrão para a construção, que tem vindo a ser desenvolvida, entre outros pela IAI - International Agency for Interoperability – e que permite que os produtos da construção sejam codificados sob a forma de um modelo de informação. Este tema será retomado e aprofundado no ponto 2.3.5.3.7.

Embora os BIM possam existir independentemente das aplicações que os utilizem, a sua disseminação depende da disponibilidade de ferramentas informáticas que permitam a fácil materialização das decisões dos intervenientes. Actualmente, há no mercado uma variedade de ferramentas que se baseiam em BIM, desenvolvidas por empresas com tradição nos domínios do CAD, o que indicia uma mudança de paradigma, pelo menos na área do projecto. Os modelos de informação que servem de base às aplicações comerciais mais populares são, por norma, parcialmente compatíveis com as especificações IFC (ver 2.3.5.3.7). Estas ferramentas têm procurado estender a aplicação dos BIM a todas as especialidades do projecto e, num âmbito mais alargado, a todas as fases do processo construtivo, interagindo com os sistemas de informação existentes como os ERP.

O desenvolvimento de novos modelos de informação beneficiou ainda de alguns factores conjunturais, dificilmente repetíveis. Como se constatará em 2.3.5.3.6 e 2.3.5.3.7, a maior parte dos modelos de informação desenvolvidos para a construção tiveram origem europeia. Esta concentração regional de esforços na área dos BIM poderá ser explicada, em parte, pelo processo europeu de integração que levou à revisão de uma parte significativa dos códigos da construção.

2.3.5.3.6            Breve perspectiva histórica

2.3.5.3.6.1     Apresentação

Conforme se referiu em 2.2.3, os primeiros modelos de informação para a construção datam da década de 70.

São apresentados, neste ponto, algumas iniciativas mais recentes. Os modelos considerados mais relevantes na actualidade - o ISO-STEP e principalmente o IFC - serão abordados nos pontos seguintes.

2.3.5.3.6.2     Modelos parciais

Os modelos apresentados neste ponto são úteis em domínios específicos do sector da construção. Não têm como fim representar toda a gama de produtos da construção, nem um conjunto particularmente diversificado de propriedades dos produtos abrangidos. Serão apresentados, de forma sucinta, três modelos parciais distintos: o CIMsteel, o COMBINE e o Building Elements Using Explicit Shape Representation.

CIMsteel

O projecto CIMsteel teve como objectivo a melhoria da eficiência e eficácia das actividades relacionadas com a construção em aço na Europa. Embora não tenha sido identificado como o objectivo central do projecto, este culminou com a criação de um modelo de representação de estruturas metálicas – as especificações CIS (CIMsteel Integration Standards) (Watson 1997). O projecto foi iniciado em 1987, sob o financiamento do projecto EUREKA. O CIMsteel foi desenvolvido por 42 associações de 8 países europeus, tendo sido concluído em 1998 (CIMsteel 1998). As especificações CIS foram desenvolvidas usando a linguagem EXPRESS de modo a prever uma futura compatibilização do modelo com o STEP. Depois da conclusão do projecto CIMsteel, o desenvolvimento das especificações CIS foi continuado pela Universidade de Leeds. A participação de organizações distintas no projecto, incluindo universidades, organizações profissionais, empresas de software, gabinetes de projecto e construtores garantiu que as especificações se adequassem às aplicações reais da indústria, pelo que o modelo conheceu uma aceitação significativa. Naturalmente, as características específicas dos produtos de construção abordados pelo projecto (ver 2.2.1) tornam-nos especialmente aptos para uma representação sob a forma de um modelo de informação.

COMBINE

Tal como o CIMsteel, também o projecto COMBINE foi financiado pela União Europeia, desta feita no âmbito do programa JOULE cujo objectivo era o uso racional de energia. Este projecto teve início em 1990 e foi concluído em 1995. O modelo foi criado de forma a ser compatível com o STEP e com um conjunto de ferramentas informáticas utilizadas para o projecto de infraestruturas de AVAC. Assim, e embora o projecto tenha resultado num modelo de informação de grande dimensão (Augenbroe 1994), foi uma iniciativa que visou em primeiro lugar a interoperabilidade de sistemas, integrando o modelo ISO-STEP com aplicações standard.

Building Elements Using Explicit Shape Representation (Parte 225)

O modelo Building Elements Using Explicit Shape Representation é parte integrante do projecto ISO-STEP (é identificado como a Parte 225 deste projecto), dependendo deste modelo para o armazenamento e organização de informação. Foi a primeira parte do modelo STEP a ser aprovada para o sector da construção (Eastman 1999)[4]. O objectivo deste modelo é a partilha de informação geométrica acerca de produtos da construção entre aplicações CAD. Embora o modelo identifique elementos de construção individuais, não lhes associa propriedades relacionadas com função ou com desempenho. Assim, a Parte 225 é um modelo interessante dado que é um primeiro exemplo da aplicabilidade de um modelo completo para a construção, ainda que esta aplicabilidade se reduza a um domínio muito específico.

Os dois primeiros exemplos apontados remetem para um conjunto de limitações dos modelos completos já referida em 2.3.3. Com efeito, o modelo ISO-STEP usado como base das especificações CIS e COMBINE desde cedo se revelou insuficiente tendo em conta as exigências práticas da comunidade técnica, pelo que estes modelos divergiram significativamente do modelo de referência, tanto ao nível do âmbito como ao nível da arquitectura dos modelos. Por outro lado, a simples existência destas iniciativas, em paralelo com o ISO-STEP, revela que o desenvolvimento deste era demasiado lento para satisfazer as necessidades do sector. Com efeito, os projectos CIS e COMBINE foram desenvolvidos e concluídos antes da Parte 225, cujo âmbito era significativamente mais restrito.

2.3.5.3.6.3     Modelos completos

RATAS

O modelo RATAS é uma iniciativa do comité RATAS criado pelo Centro de Investigação Técnica da Finlândia (VTT). As actividades deste comité tiveram início em 1985, sendo a primeira versão do modelo lançada em 1987. A questão principal em torno da qual o comité centrou a sua actividade foi enunciada pelo responsável pelo projecto (Björk 1995) da seguinte forma:

Como devemos estruturar a informação digital que descreve um edifício de forma a tornar tão simples quanto for possível a partilha de informação entre as aplicações informáticas da construção que produzem ou que utilizam estes dados?

O modelo segue uma abordagem de desenvolvimento estruturalista, típica dos modelos completos, como se constata a partir das duas primeiras das cinco características exigidas aos modelos de informação para a construção enunciadas por Björk (Björk 1995):

a.       Capacidade de modelar todo o tipo de informação[5];

b.      Capacidade de responder às necessidades de informação de todas as fases e disciplinas;

c.       Não redundância de estruturas de informação;

d.      Possibilidade de suportar diferentes formatos de apresentação, isto é, interoperabilidade com outros sistemas;

e.       Independência das restrições colocadas por aplicações informáticas.

Como se constata, muitos dos princípios que orientam as iniciativas mais recentes, nomeadamente o IFC, foram apontados neste trabalho.

Building Construction Core Model (Parte 106)

O Building Construction Core Model (BCCM) é uma actividade do projecto STEP, identificado como Parte 106. O seu desenvolvimento foi iniciado em 1994, tendo sido enunciadas, nesse mesmo ano, as características fundamentais do modelo a desenvolver (ISO 1994). O modelo nunca foi concluído, pelo que não são conhecidas aplicações práticas do BCCM. Ainda assim, alguns dos conceitos abordados no seu desenvolvimento, tornam o BCCM um influente precursor de iniciativas que se lhe seguiram. A estrutura do modelo inclui produtos, processos, recursos e controlos, constituindo estes últimos, restrições que se colocam aos outros elementos da estrutura do BCCM. Estes elementos podem ser aplicados a todas as fases do processo construtivo, desde a promoção à utilização, pelo que o âmbito do modelo é considerado como muito alargado (Eastman 1999). Uma característica particularmente interessante desta iniciativa é o seu desenvolvimento por camadas em torno de um núcleo central de especificações. As camadas em torno deste núcleo correspondem a aplicações mais concretas do modelo, isto é a modelos parciais (aspect models na bibliografia em língua inglesa) que podem ser desenvolvidos por grupos distintos. Este procedimento de desenvolvimento pode ser visto como uma variante da abordagem estruturalista descrita em 2.3.3 que visa o aligeiramento do processo de criação do modelo. Naturalmente, o desenvolvimento de um modelo por camadas só é viável após a estabilização das especificações que constituem o seu núcleo o que, frequentemente, se revela impossível sem uma suficiente clarificação do âmbito dos correspondentes modelos parciais. Esta interdependência entre os dois extremos da estrutura do modelo foi sentida, por exemplo, no desenvolvimento do IFC.

2.3.5.3.7            Situação actual

2.3.5.3.7.1     ISO-STEP

O desenvolvimento das especificações STEP (Standard for the Exchange of Product model data) teve origem no final do ano de 1983, por iniciática da International Standards Organization (ISO).

As especificações STEP não se resumem à indústria da construção. Pelo contrário, pretendem ser representações de produtos (em geral), pelo que o âmbito desta iniciativa é extremamente vasto. Assim, e tal como foi referido em 2.3.3, as especificações STEP são vistas como um exemplo claro de um formato cujo desenvolvimento segue uma abordagem estruturalista.

Actualmente, o projecto ISO-STEP, pelo menos no que toca à sua aplicação à indústria da construção, é visto como uma iniciativa em larga medida mal sucedida. O seu desenvolvimento tem-se revelado lento, tendo mesmo dado origem a um projecto alternativo – o IFC – com o fim de conseguir resultados com maior brevidade.

Ainda assim, a proximidade entre as iniciativas ISO-STEP e IFC, que se traduz desde logo nos seus objectivos para a área da construção e nas suas abordagens ao desenvolvimento, passando pelas suas semelhanças ao nível da utilização de tecnologias de informação, justifica a referência ao modelo, embora já tenha perdido há muito o estatuto de potencial formato padrão para a indústria da construção.

2.3.5.3.7.2     IFC

O modelo IFC tem uma origem próxima da iniciativa ISO-STEP. Ao contrário deste, é dedicado exclusivamente à indústria da construção. Este modelo tem sido desenvolvido pela IAI – International Agency for Interoperability – fundada em 1995, e a sua primeira versão data de 1997. Uma parte significativa do modelo IFC foi baseado no STEP e a mesma linguagem (EXPRESS) é utilizada na definição de ambos os modelos.

Ao contrário do modelo STEP, o IFC não é desenvolvido com o fim de constituir uma norma de representação, mas antes para ser aplicado directamente na indústria da construção (Choo 2003).

Em 2002, uma parte significativa do modelo obteve certificação ISO (ver Fig. 12).

Desde o aparecimento do XML, a IAI tem adaptado o IFC a este formato de representação de dados. Dado que os formatos XML e EXPRESS não são completamente compatíveis, a transição deve respeitar regras de transformação específicas. Desde 2001 está disponível o modelo ifcXML que, embora tenha sido obtido a partir do formato EXPRESS original, não contém toda a informação existente neste (Behrman 2002).

O desenvolvimento do formato IFC tem vindo a seguir uma abordagem marcadamente estruturalista, sendo o seu principal objectivo inicial declarado (IAI - International Alliance for Interoperability 2001):

[…] o desenvolvimento de um modelo conceptual detalhado para edifícios comerciais […]

A estrutura do modelo IFC não se presta a um desenvolvimento descentralizado, envolvendo um conjunto alargado de entidades. O modelo respeita uma hierarquia típica em modelos organizados por objectos segundo a qual as classes de níveis inferiores herdam as propriedades das classes de nível superior na hierarquia. Assim, qualquer alteração nas classes de nível superior modifica a estrutura das classes de níveis inferiores. Uma abordagem ao desenvolvimento deste tipo tende a concentrar o esforço de desenvolvimento do formato num grupo reduzido de indivíduos, dificultando ainda a elaboração de aplicações externas que acedam a modelos de informação que respeitem as suas especificações. A descrição do processo de desenvolvimento do formato IFC pode ser consultado em (Wix, See 1999).

Na realidade, o modelo é criado e mantido por um conjunto limitado de pessoas: o Model Support Group (MSG). Em 2002, o MSG era constituído por apenas seis pessoas que trabalhavam a tempo parcial no desenvolvimento do IFC (Behrman 2002).

Fig. 12 – Modelo IFC (IAI 2006). Os elementos representados a verde correspondem à parte do modelo que obteve certificação ISO em 2002.

Conforme se referiu neste trabalho, a abordagem de desenvolvimento do tipo estruturalista que foi seguida na elaboração das especificações IFC dificultou a sua implementação por parte das organizações responsáveis pelo desenvolvimento de outras aplicações, em particular de aplicações comerciais. As especificações, desenvolvidas no interior de um grupo restrito, lançadas antes de se tornarem um standard ad-hoc, e cuja implementação consiste numa tarefa complexa e demorada, foram responsáveis por alguma relutância por parte das empresas produtoras de software para o sector da construção em adoptar o novo formato IFC. Com o fim de facilitar este processo de adopção, foi criado em 1999 o projecto Building Lifecycle Interoperable Software (BLIS). O projecto BLIS tem permitido a implementação do IFC seguindo alguns dos princípios minimalistas (Behrman 2002) referidos neste trabalho.

O projecto BLIS tem explorado aplicações concretas do modelo IFC, por exemplo, a produção de medições e orçamentos a partir do projecto geral de arquitectura. Este projecto tem permitido a identificação de falhas no modelo IFC, relevantes para a sua aplicação em situações concretas e tem promovido a resolução destes problemas. É importante realçar que as lacunas existentes no modelo IFC o tornam insuficientemente abrangente para satisfazer muitas das exigências colocadas por empresas de software para a construção.

Encontra-se na bibliografia consultada (Yurchyshyna et al. 2007) uma avaliação do modelo IFC para efeitos da sua utilização na verificação de conformidade regulamentar de projectos na construção. Segundo este estudo, o modelo IFC não permite a verificação automática relativamente à maior parte das normas francesas analisadas devido a uma de duas razões:

a.       O modelo não contém informação suficiente, o que pode suceder quando a norma se refere a objectos ou respectivas propriedades não incluídas no modelo;

b.      Inexistência de uma interpretação padrão para a disposição regulamentar, isto é, existência de ambiguidades nas normas.

2.3.5.3.7.3     Modelos associados a aplicações comerciais

Para além destas iniciativas internacionais de acesso livre (non-propriety), existe um conjunto de aplicações que recorrem a modelos que lhes são exclusivos (propriety). Entre as aplicações mais utilizadas contam-se o ArchiCAD (Graphisoft) e o Autodesk Revit. Existem ainda outras aplicações que resultam da evolução de aplicações de desenho assistido por computador, nomeadamente o Bentley Architecture e o Autodesk Architectural Desktop. Estas aplicações são consideradas híbridas (Khemlani 2004) dado que acrescentam informação relativa à construção a um modelo geométrico tradicional.

Embora as aplicações utilizem modelos próprios, algumas delas (em particular o ArchiCAD), são em larga medida (mas não totalmente) compatíveis com o modelo IFC, o que reforça o seu papel de potencial repositório de informação para aplicações externas. O IFC contém algumas entidades que não estão incluídas no modelo das aplicações referidas e vice-versa, isto é, nenhum dos modelos é um subconjunto de outro modelo, o que exclui a possibilidade de compatibilidade total entre modelos de informação.

Considera-se que o desenvolvimento de ferramentas para a construção baseadas em modelos de informação deve ser levado a cabo tendo em conta as especificações de acesso livre. A dependência de modelos associados a aplicações comerciais levanta um conjunto de inconvenientes significativos (Kiviniemi 2005):

a.       A estrutura de um modelo associado a uma aplicação comercial pode ser alterada sem aviso prévio;

b.      Para cada aplicação comercial será necessário desenvolver uma ligação específica;

c.       A documentação da estrutura interna de um modelo deste tipo pode não estar publicamente disponível.

2.3.5.4      Aplicações “à medida”

2.3.5.4.1            Aspectos gerais

Este tipo de solução não pode, obviamente, ser classificada como uma categoria particular de sistemas de informação, mas é incluída na lista de “Vectores de desenvolvimento” pelas vantagens que oferece. Com efeito, os produtos desta categoria partilham poucas características para além das seguintes:

a.       Aptidão para automatizar os processos de trabalho das empresas, evitando os inconvenientes próprios de algumas aplicações comerciais correntes, que tendem a homogeneizar práticas, eliminando potenciais vantagens competitivas que as empresas possam deter.

b.      Possibilidade de serem desenvolvidas, com relativamente poucos recursos, no interior das organizações onde serão aplicadas.

As aplicações “à medida” são aquelas que são desenvolvidas ou adaptadas usando os recursos da organização, em particular o seu hardware, software e técnicos informáticos. Admite-se, pois, que sejam a forma mais simples de preservar os processos que possam conferir a uma organização algum tipo de vantagem competitiva, dado que são desenvolvidas atendendo às características específicas da empresa, permitindo ainda automatizar, total ou parcialmente, algumas das tarefas a realizar. Nessa medida, as aplicações desenvolvidas no interior da organização surgem como uma solução evolutiva relativamente às práticas correntes, não como uma revolução nos métodos de trabalho, ao contrário do que sucede com as tecnologias ERP ou BIM.

Este tipo de solução tem-se tornado cada vez mais interessante à medida que o acesso aos recursos referidos se tem tornado mais fácil e barato. Com efeito, é hoje possível desenvolver aplicações cliente-servidor baseadas na Internet usando hardware simples, software barato ou até gratuito e recursos humanos limitados.

A possibilidade oferecida por um número crescente de aplicações informáticas de automatizar as suas funções, isto é, de permitir o acesso às suas funções internas a partir de aplicações externas, facilita a conversão de procedimentos pretendida. É assim possível manter as operações a realizar nas aplicações comerciais habitualmente usadas mas automatizar a entrada de dados ou a divulgação de resultados produzidos, por exemplo.

2.3.5.4.2            Arquitectura three-tier

Os sistemas de informação baseados na Internet, considerados ajustados às necessidades do sector da construção (como acontece, por exemplo, com os sistemas ERP), podem ser enquadrados frequentemente na arquitectura three-tier (três camadas) ou multi-tier. Este tipo de arquitectura é caracterizado, muito sucintamente, pela introdução de uma camada adicional (ou mais, no caso da arquitectura multi-tier) entre as camadas “cliente” e “servidor”.

A primeira camada, o cliente, é essencialmente, uma camada de interface, podendo assumir algumas funções de processamento. Um cliente responsável por uma parte significativa do processamento é designado frequentemente por “gordo”, por oposição aos clientes mais “magros” que têm poucas funções para além das de interface (isto é, entrada e saída de dados). No limite, um sistema que dependa de clientes muito “gordos” não se distinguirá significativamente de uma arquitectura two-tier. Por norma, e em consequência das condicionantes decorrentes da utilização de redes Internet, os clientes neste tipo de redes (usualmente os browsers) são “magros”, passando a quase totalidade das funções de processamento para as outras camadas do sistema de informação.

A camada oposta à camada cliente tem funções de gestão da base de dados. É aqui que são armazenados os dados e é esta camada que deve assegurar a sua consistência.

A camada intermédia, que distingue funcionalmente a arquitectura three-tier da clássica organização two-tier, típica dos sistemas constituídos por um mainframe e por terminais, é uma camada de gestão de processos. É aqui que residem as aplicações que respondem aos pedidos dos utilizadores, processam os dados requisitados à base de dados e os enviam de volta para o cliente.

Note-se que, embora a arquitectura apresentada se baseie em três sistemas em grande medida independentes, não se desenvolve necessariamente em três máquinas distintas. Em muitos casos, em particular quando se prevê uma utilização simultânea de um grande número de utilizadores, ou quando o trabalho de processamento exigido se considera significativo, as camadas de gestão de processos e de bases de dados são separadas em máquinas diferentes. Perante as exigências previsíveis na maior dos sistemas de informação para a construção, incluindo mesmo os sistemas criados para apoiar a gestão de muitos dos grandes empreendimentos actuais, não se considera necessária esta separação do sistema, admitindo-se organizações mais simples. Naturalmente, o recurso a redes Internet resulta, em qualquer caso, numa separação física do cliente relativamente às restantes camadas do sistema.

2.3.5.4.3            Recursos necessários ao desenvolvimento

2.3.5.4.3.1     Aspectos gerais

Conforme foi já referido neste capítulo, os recursos necessários ao desenvolvimento ou adaptação e à manutenção de muitas aplicações “à medida” são francamente reduzidos e acessíveis a muitas das organizações do sector da construção, incluindo algumas de pequena dimensão. Uma análise muito breve dos recursos mínimos necessários para este fim confirma esta afirmação. Sublinha-se que os recursos indicados em seguida correspondem a uma configuração mínima, destinada a suportar aplicações simples, podendo revelar-se insuficiente para sistemas mais complexos do tipo ERP, por exemplo.

Refere-se finalmente que os custos indicados nos pontos seguintes – correspondentes a hardware, software e recursos humanos – dizem respeito apenas ao desenvolvimento e manutenção das soluções. Tal como sucede com os sistemas ERP, é possível que às aplicações desenvolvidas no interior das organizações correspondam custos “escondidos” (ver 2.3.5.2.5) incluindo custos de formação e possíveis quebras de produtividade após a adopção das soluções desenvolvidas.

2.3.5.4.3.2     Hardware

Qualquer computador pessoal actual pode ser usado, hoje em dia, como servidor de Internet, repositório de dados, servidor de e-mail e de aplicações web em simultâneo desde que não lhe sejam impostas exigências muito significativas, quer ao nível do número de utilizadores em simultâneo, quer ao nível das aplicações eventualmente instaladas.

2.3.5.4.3.3     Software

O software necessário é actualmente bastante estável, existindo para todas as utilizações previsíveis, diversas alternativas disponíveis, incluindo alternativas de custo reduzido ou mesmo gratuitas.

No cliente instala-se apenas, na maior parte dos casos, um vulgar browser web que, como se sabe, é instalado em conjunto com os sistemas operativos mais usuais ou pode ser obtido gratuitamente na Internet. Eventualmente poderá ser necessário acrescentar ao browser pequenos programas adicionais (plugins) para aceder a alguns tipos de conteúdo.

À camada intermédia (de gestão de processos) correspondem usualmente, para além das aplicações propriamente ditas, o programa servidor e, indirectamente, as ferramentas necessárias ao desenvolvimento das aplicações a disponibilizar.

O programa servidor (muitas vezes chamado apenas de servidor) mais utilizado no mundo (ver Fig. 13), o Apache (Apache Software Foundation), pode ser obtido gratuitamente a partir da Internet.

A alternativa mais popular ao Apache – o Internet Information Services (IIS) da Microsoft – tem sido incluída em sucessivas versões do sistema operativo Windows desde 1996. Existem ainda alternativas gratuitas, que podem ser instaladas em computadores com sistemas operativos Windows que não incluam o IIS(UltiDev LLC 2006).

Fig. 13 – Quota de mercado dos principais servidores (Netcraft 2009)

Um servidor web pode suportar conteúdo estático e dinâmico. Muito do conteúdo dinâmico é desenvolvido usando tecnologias como o PHP ou o ASP.NET. Estas tecnologias correspondem frequentemente a servidores específicos. Assim, aplicações desenvolvidas em ASP.NET, por exemplo, são associadas a servidores ISS. Existem actualmente diversas ferramentas destinadas ao desenvolvimento de aplicações PHP ou ASP.NET, tanto comerciais como gratuitas.

O componente essencial da camada de gestão de base de dados é, evidentemente, o sistema gestor de base de dados (SGBD). Para além dos dados e da respectiva estrutura, o SGBD inclui um conjunto de outros componentes que permitem a sua organização, armazenamento e acesso. À imagem dos outros constituintes de um sistema de informação apresentados, também no caso do SGBD é possível encontrar diversas alternativas no mercado, com diferentes tipos de licenças, incluindo as gratuitas.

2.3.5.4.3.4     Recursos humanos

No que toca aos recursos humanos, a tecnologia tem evoluído de forma que um conhecimento de um número limitado de linguagens de programação permite actualmente a realização de tarefas tão distintas como a automatização de programas comerciais (de desenho, de apoio ao planeamento, folhas de cálculo, etc.), a criação de páginas dinâmicas para a Internet, o acesso a bases de dados, para além da criação de aplicações mais simples. Esta evolução permite expandir as competências da generalidade dos programadores para áreas que anteriormente exigiriam conhecimentos mais especializados.

Admite-se, pois, que o desenvolvimento de aplicações usando os recursos próprios das empresas seja uma solução ao alcance de um número significativo de organizações dado que o investimento a realizar é, em geral, modesto.

2.3.5.4.4            Aplicações desenvolvidas: CPS e PXS

Apresenta-se, a título de exemplo, imagens de duas aplicações desenvolvidas pelo autor que se enquadram no tipo de programas descritos no presente subcapítulo.

As aplicações CPS e PXS, embora tenham sido desenvolvidas especificamente para apoiar a gestão de tarefas relacionadas com a construção, podem ser usadas para a gestão de projectos de qualquer tipo. Ambas as aplicações funcionam com interface Web e permitem que diversos utilizadores trabalhem em simultâneo sobre um único modelo de dados centralizado.

As aplicações partilham algum código e as suas interfaces têm uma apresentação semelhante, mas o seu funcionamento difere significativamente: em síntese, o CPS permite a importação/exportação de ficheiros do Microsoft Project enquanto o PXS tem um funcionamento autónomo daquele programa. Ambas as aplicações permitem realizar o planeamento de tarefas usando o método CPM – Critical Path Method – e produzem relatórios e curvas de progresso, diagramas de Gantt, etc.

Fig. 14 – PXS: (a) Consulta de dados de uma tarefa, (b) diagrama de Gantt, (c) alerta de atrasos e (d) actualização de dados de progresso

Fig. 15 – CPS: (a) Importação de ficheiros gerados no Microsoft Project e (b) geração de curvas de progresso

2.4    Fluxo de Informação no Processo Construtivo

2.4.1       Introdução

No presente capítulo procede-se a uma descrição das necessidades, em termos de informação, dos participantes no processo construtivo. Essa descrição conduz, de forma directa, a uma enumeração de requisitos considerados desejáveis num modelo de informação para a construção.

Durante o processo construtivo é produzida uma quantidade significativa de informação, mesmo no caso de empreendimentos relativamente simples. Alguma desta informação acaba por ser formalizada, resultando na elaboração de peças de projecto, de contratos, de actas de reuniões, de correspondência entre os intervenientes ou de documentos internos das organizações envolvidas. Uma parte significativa da informação produzida não chega, contudo, a ser formalizada e reside apenas na mente de alguns dos intervenientes, sendo eventualmente transmitida de forma oral a outros participantes no processo construtivo. Os conceitos de informação formal e informal foram apresentados em 2.3.2.2.5, tendo-se afirmado que ambos coexistem em qualquer projecto de construção.

Nesta secção importa afirmar, em primeiro lugar, que o estudo da informação formal assume particular importância neste trabalho. É a este tipo de informação que se considera possível aplicar um conjunto de tecnologias, em particular as apresentadas em 2.3.5. Mesmo a informação informal pode, em alguns casos, ser incorporada em sistemas de informação formais (Pereira 2005).

Em segundo lugar importa levantar um conjunto de questões importantes para a definição de um modelo de informação que corresponda às necessidades dos intervenientes no processo construtivo: Que informação está contida nos documentos produzidos durante o processo construtivo? Até que ponto se pode considerar que as peças de projecto são compostas integralmente por informação formal?

Um projecto de construção resulta, como se sabe, da codificação das ideias dos elementos da equipa projectista sob a forma de peças escritas e desenhadas. O facto de ser um processo muito estabilizado, com resultados comprovados, pode ocultar algumas fragilidades que lhe são inerentes:

a.       O projecto é invariavelmente uma representação incompleta por diversas razões. A mais evidente reside nos quase inevitáveis erros e omissões acidentais que o desvirtuam. Para além das omissões acidentais, há um conjunto de “omissões deliberadas” a considerar: por um lado, as especificações técnicas dos projectos remetem, por sistema, para um conjunto de “regras da boa arte” inespecíficas. Por outro lado, a compreensão das peças desenhadas de projecto pressupõe frequentemente algum entendimento que transcende as regras do desenho técnico. No fundo, estas “omissões deliberadas” nas peças escritas e desenhadas têm por base um entendimento entre os intervenientes, apoiado em experiências anteriores que constituem de facto as referidas “regras da boa arte”. Conforme foi referido neste trabalho, esta deficiência é significativamente mais grave na ausência de uma base normativa que sustente estas “regras”.

b.      Estas representações são pouco úteis para o desenvolvimento de conhecimento. Não permitem, por exemplo, fazer uma análise das características de um conjunto de edifícios (isto é, da sua tipologia construtiva) no sentido de determinar, de forma automática, regras de projecto a partir de experiências anteriores bem sucedidas. Actualmente, o conhecimento resultante de experiências anteriores é condensado e publicado em livros de referência, podendo-se esperar que no futuro este papel possa caber a aplicações informáticas (Eastman 1999). Refira-se, a título de exemplo, que a generalidade das câmaras municipais nacionais não dispõe ainda de meios tecnológicos que lhes permita realizar as mais simples análises estatísticas à informação contida nos documentos de projecto que lhe são apresentados para licenciamento. Apenas as autarquias que dispõem de sistemas de informação geográfica (SIG) estendidos a todo o seu território urbano podem obter em tempo real informações como áreas médias de fogos em diferentes zonas da cidade e, ainda assim, esta informação só se torna acessível depois de lida pelos técnicos e introduzida manualmente no sistema.

A primeira das desvantagens enunciadas é inerente ao acto de representar ideias (ver a este respeito o conceito de abstracção apresentado em 2.3.2.3). Todas as representações são, necessária mas também desejavelmente, incompletas. O conjunto de propriedades de um produto é infinito (Eastman 1999) e o custo da expansão de um modelo, de forma a que passe a incluir um número maior de propriedades, é elevado, reflectindo-se na sua dimensão, na sua complexidade e em tempos de processamento maiores. É evidente que a representação de um edifício deve resultar de um compromisso entre os benefícios e os custos inerentes a modelos mais ou menos complexos.

A segunda desvantagem pode ser contornada de forma definitiva pelo recurso aos sistemas de informação baseados em computadores (SIBC).

Pretende-se assim, no presente subcapítulo:

a.       Discutir a questão colocada anteriormente: Que informação está contida nos documentos produzidos durante o processo construtivo? Esta reflexão será útil na definição de requisitos de um sistema de informação para a construção (a desenvolver em 2.4.2).

b.      Discutir a possibilidade de migrar a informação produzida dos sistemas actuais (não necessariamente baseados em computadores, nem sequer formais) para SIBC.

c.       Discutir a possibilidade de fomentar a adopção destes sistemas, procurando que as suas vantagens sejam perceptíveis para os participantes no processo construtivo (a desenvolver em 2.4.3).

2.4.2       Processo construtivo

2.4.2.1      Introdução

Processo construtivo é a designação dada ao conjunto de actividades necessárias ao planeamento e à construção de uma obra e à sua utilização. De acordo com os argumentos apresentados em 2.2.1, esta designação é, desde logo, imprecisa. Com efeito, a inconsistência dos resultados obtidos e a variabilidade das abordagens seguidas perante cada uma das tarefas a realizar não são características de um processo. Desta forma, considera-se que o “processo construtivo” é, na realidade, uma sequência de práticas. Ainda assim, no decorrer do trabalho será adoptada a designação corrente.

O processo construtivo engloba toda a vida útil da obra e inclui a sua manutenção e demolição. Encontra-se, na bibliografia consultada, diversas visões alternativas do processo construtivo, esquematizado habitualmente como uma sucessão linear de fases que decorrem entre pontos singulares (ou transições). As diferentes visões do processo construtivo não são de forma alguma contraditórias, mas tendem a valorizar algumas das fases que o compõem, isto é, a individualizar ou não qualquer uma das tarefas. Uma versão popular deste esquema é a proposta de Gielingh (Gielingh 1988). Para apoiar a discussão que se segue, adoptou-se um esquema alternativo, apresentando algumas simplificações relativamente ao modelo referido, de forma a dar relevo às fases consideradas mais decisivas da obra e aos respectivos protagonistas.

Fig. 16 – Processo construtivo: esquema simplificado (Poças Martins 2006)

Ao longo de todo o presente trabalho, argumenta-se a favor da melhor definição das tarefas que constituem o processo construtivo e dos seus respectivos inputs e outputs. Por outras palavras, pretende-se aproximar as práticas seguidas na indústria da construção a processos.

Importa, pois, definir a forma como se deve processar a produção e a partilha de informação que, para além de ser registada por aplicações diferentes, deve ser útil em fases distintas do processo construtivo. Uma análise breve aos procedimentos habitualmente seguidos no sector da construção permite afirmar que, em cada fase do processo e para cada interveniente, o nível de análise varia de forma significativa.

2.4.2.2      Promoção

Durante esta fase importa considerar o produto de construção como um todo, definindo as suas características fundamentais e os objectivos que se propõe realizar. Considera-se que, nesta fase, um sistema de informação deverá permitir antecipar custos, prazos e eventuais restrições que se colocam à pretensão do promotor de modo a que seja possível analisar a sua viabilidade. Por um lado, o modelo deverá poder aceder a uma base de dados que contenha dados de síntese relativamente a empreendimentos anteriores (isto é, um historial), por outro deverá incluir um conjunto de normas relevantes (isto é, um módulo de legislação, eventualmente ligado a sistemas de informação geográfica). É ainda desejável que exista uma base de dados que contenha informações relativas a potenciais fornecedores e prestadores de serviço para as fases posteriores do processo construtivo de forma a apoiar a sua selecção (apoio a procurement). Deve ser preparado um sistema de gestão documental para organizar e para divulgar todo o tipo de informação a produzir durante o processo construtivo (não apenas durante a fase de promoção): correspondência, actas de reuniões, elementos de projecto, autos de medição, etc.

2.4.2.3      Projecto

2.4.2.3.1            Aspectos gerais

O projecto é uma actividade que consiste na definição de soluções construtivas que satisfaçam as pretensões inicialmente definidas, com um grau de detalhe sucessivamente crescente à medida que o projecto é desenvolvido. Nesta fase procede-se à concepção da geometria do empreendimento, à especificação dos elementos que o compõem e à análise do seu comportamento. Alguma da informação usada ou produzida nesta fase não é, regra geral, divulgada aos restantes intervenientes, por exemplo, alguns elementos de cálculo estrutural.

Deverá ser possível interligar a informação produzida por cada interveniente nesta fase, dado que as modificações operadas numa especialidade de projecto tendem a ser relevantes na definição das restantes especialidades. Idealmente, a representação gráfica dos elementos de construção deverá ser tridimensional, o que facilita a compatibilização dos diversos projectos. Aceita-se, porém, prescindir, quer da representação a três dimensões, quer de alguma interligação entre peças desenhadas e escritas do projecto numa solução de nível de compromisso baixo, onde as alterações efectuadas às práticas correntes serão menos significativas.

Durante a fase de projecto, a informação produzida é organizada em níveis de detalhe distintos:

a.       A um nível “elementar”, define-se cada componente individual, especifica-se a sua forma e a sua localização. É esta informação que compõe as peças desenhadas do projecto.

b.      A um nível mais geral, associam-se características físicas a cada grupo de componentes e definem-se regras para orientar a sua implementação em obra. Esta informação pode ser utilizada em projectos diferentes e é agrupada de modo a formar as especificações técnicas do projecto.

c.       A um nível “operacional”, os elementos de construção são associados a artigos formando o mapa de trabalhos e quantidades. É a estes artigos que serão associados custos e prazos nas fases posteriores.

Esta informação será, eventualmente, sujeita a análise na fase de revisão de projecto e será enviada para as entidades responsáveis pelo licenciamento do empreendimento. Os documentos a enviar para apreciação pelas entidades licenciadoras são produzidos a partir da informação desenvolvida pelos intervenientes até então: não constituem uma compilação de toda a informação produzida mas apenas um subconjunto desta informação, destinado a satisfazer os requisitos exigidos. Estes documentos resultam, pois, não só da organização de toda a informação mas também da supressão de alguma dessa informação.

2.4.2.3.2            Licenciamento

A fase de licenciamento representa um marco significativo no desenvolvimento do projecto, dado que corresponde a uma entrega formal de documentos, frequentemente a primeira entrega efectuada para o exterior do grupo formado pelas partes envolvidas nas primeiras fases do processo construtivo (ver Fig. 17).

Fig. 17 – Produção de informação e sua formalização ao longo das fases de projecto

Até à fase de licenciamento, a generalidade dos documentos é trocada entre projectistas e dono da obra, com eventual colaboração de elementos que actuem em representação deste último. Uma parte significativa da informação, até à fase de licenciamento, será ainda de carácter bastante informal, não estando ainda representada sob a forma de documentos de projecto. Naturalmente, existe também troca de informação com outros intervenientes, inclusivamente com entidades municipais, por exemplo aquando da apresentação de Pedidos de Informação Prévia. Nestes casos, porém, a informação apresentada por qualquer uma das partes é limitada, estando longe de constituir uma representação de um edifício, ainda que parcial. Pode afirmar-se, pois, que até à fase de licenciamento, as trocas de informação que, de alguma forma, constituam uma representação do edifício, ocorrem entre a equipa projectista e o dono da obra e correspondem às fases de projecto habitualmente consideradas. Embora estas fases de projecto estejam definidas, de uma forma genérica, na lei (Rodrigues 2003), constata-se que a interpretação dos intervenientes sobre o que é, por exemplo, um estudo prévio, admite variações significativas, sendo frequente fazer-se referência a estudos prévios “mais ou menos desenvolvidos” ou mesmo dispensar-se por completo a elaboração de um estudo prévio. Admite-se que esta variedade de procedimentos poderá ser menor nos casos em que exista uma relação mais duradoura entre os intervenientes no processo, em particular entre o dono da obra, projectistas e empreiteiro. Este tipo de relações favorece o desenvolvimento de procedimentos e de formas de comunicação padrão, tal como se referiu em 2.2.1.

Na fase de licenciamento, pelo contrário, a existência de procedimentos e de regras de representação formais reduzem a variabilidade dos conteúdos e respectivos formatos apresentados. Para além disso, o licenciamento é, ao contrário da generalidade das fases de projecto, uma etapa de cumprimento obrigatório.

2.4.2.3.3            Projecto de execução

Na generalidade dos casos, ocorre ainda uma segunda entrega significativa de documentos ao exterior, correspondente ao projecto de execução. Esta versão do projecto serve de base a eventuais consultas ou concursos de empreitada a efectuar, sendo depois o documento de referência para a elaboração de orçamentos, de planeamento da construção e para a execução propriamente dita. Naturalmente, esta versão de projecto deve ser elaborada segundo um conjunto de regras de codificação que permitam a sua compreensão por um universo mais vasto de intervenientes, tornando dispensável a consulta de informações adicionais, formais ou informais.

Em síntese, o projecto é um procedimento durante o qual se produz informação e em que esta é formalizada. Uma singularidade comum a todos os projectos de construção ocorre na fase de licenciamento, onde se formaliza um subconjunto da informação produzida, tornando-a conforme com as exigências das entidades licenciadoras.

Refere-se finalmente que há duas questões que merecem especial atenção no que concerne à gestão da informação produzida na fase de projecto:

a.       Divulgação:

Todos os intervenientes devem ter acesso, em tempo real, à última versão de cada documento e devem ser avisados em caso de alterações;

b.      Trabalho em equipa:

O trabalho é realizado, tradicionalmente, por intervenientes que pertencem a organizações diferentes, em lugares distintos. O trabalho de cada projectista pode influir no trabalho dos restantes. É habitual haver troca de elementos de projecto incompletos para permitir a realização simultânea de várias tarefas de projecto. Este aspecto da gestão de informação é particularmente relevante dado que as aplicações habitualmente usadas não prevêem que um modelo possa ser um repositório de informações que possam ser editadas de forma individual – isto é, que uma alteração ao modelo não obrigue à sua substituição integral por um modelo novo (uma operação habitualmente designada por batch transaction na bibliografia em língua inglesa). Considera-se que é importante analisar a possibilidade de introduzir dispositivos de controlo de alterações de modelos gerados por algumas aplicações comerciais de modo a permitir o trabalho simultâneo de múltiplos intervenientes.

2.4.2.4      Construção

Esta fase parte dos elementos preparados nas fases anteriores, acrescentando-lhe informação relacionada com custos e prazos durante o processo de concurso, formando o orçamento comercial e o planeamento de obra. Esta informação é relacionada com a decomposição do trabalho em artigos do mapa de trabalhos e quantidades. A preparação técnica de uma obra obriga à sua desagregação em recursos (mão de obra, materiais, equipamentos e subempreitadas). Cada um destes recursos constitui uma categoria à qual pode ser associada informação adicional, nomeadamente listas de fornecedores, um historial de custos e prazos de execução, etc. A informação recolhida na fase de preparação inicial da obra deve ser compilada para produzir documentos que, regra geral, não são partilhados com outros intervenientes: o orçamento de produção e uma revisão do planeamento. Durante a construção, há um conjunto de actividades, quer relacionadas com a produção, quer com a sua fiscalização que requerem a actualização da informação produzida até então e a produção de novos documentos. São desenvolvidos e actualizados continuamente os planos de qualidade e de saúde e segurança, incluindo o registo de eventuais não conformidades detectadas pela fiscalização. São preparados e conferidos periodicamente os autos de medição que, por sua vez, dão origem à facturação de trabalhos realizados. Esta informação é habitualmente relacionada com o mapa de trabalhos e quantidades. A preparação técnica da obra é realizada de forma contínua e obriga à análise dos elementos de projecto e sua decomposição formando novas peças para uso interno (shop drawings). O progresso de construção é registado periodicamente e enviado para o Dono de Obra. Durante o processo de construção, é habitual que o empreiteiro decida subcontratar alguns dos trabalhos a realizar, pelo que se torna necessário fornecer alguns elementos de projecto aos subempreiteiros contactados para o efeito. No final dos trabalhos, o empreiteiro deve actualizar os elementos que recebeu do projectista de modo a compatibilizá-los com os trabalhos efectivamente realizados, produzindo as telas finais.

Fig. 18 – Desagregação de elementos do projecto a distribuir por subempreiteiros (Poças Martins 2006)

2.4.2.5      Utilização e Manutenção

É importante que os intervenientes envolvidos na fase de utilização e manutenção tenham acesso à informação que resulta das fases anteriores. Esta necessidade faz-se sentir frequentemente durante o período de garantia da construção, por razões óbvias, mas prolonga-se até à fase de demolição (inclusive). No caso de edifícios de serviços ou industriais, por exemplo, é usual usar-se programas de apoio à gestão de edifícios para analisar o uso dos espaços disponíveis, para controlar o funcionamento de equipamentos eléctricos e mecânicos (por exemplo, elevadores ou equipamentos de ar condicionado) ou para apoio à decisão na fase de manutenção.

Desde 2004, “não pode ser celebrada a escritura pública que envolva a aquisição da propriedade de prédio ou fracção destinada à habitação sem que o notário se certifique da existência da ficha técnica da habitação e de que a mesma é entregue ao comprador” (Decreto-Lei n.º 68/2004, de 25 de Março). Em edifícios de habitação, alguns promotores fornecem aos seus clientes um “Manual da Habitação”, onde são descritos alguns cuidados relativos à sua utilização e manutenção.

Em resumo, a informação considerada relevante durante esta fase inclui dados relativos à geometria do edifício (representada nas telas finais) e ao comportamento dos seus componentes.

2.4.2.6      Demolição

As fases descritas anteriormente decorrem entre os nós do esquema apresentado na Fig. 16 e têm a designação do nó que as precede. Pelo contrário, a fase de demolição é representada por um nó único. Considera-se, pois, que ao nível do planeamento, é encarada mais como um marco do que como uma actividade – representa o fim do processo.

Embora esta seja uma fase tradicionalmente negligenciada em comparação com as restantes, questões relacionadas com a reutilização dos produtos de construção fazem com que a informação produzida nas fases anteriores seja crucial nesta etapa, em particular a que diz respeito aos materiais utilizados. Assim, questões relacionadas com a sustentabilidade da construção têm vindo a exigir a disponibilidade de informação acerca da natureza dos materiais aplicados nos produtos da construção. Esta transição da informação acumulada ao longo da existência dos produtos é característica da filosofia PLM, na qual os BIM podem ser enquadrados.

Os BIM possuem esse tipo de informação, podendo ser-lhe associada informação acerca dos cuidados a ter no tratamento de resíduos, etc.

Ainda assim, e embora haja potencial para a criação de ferramentas úteis para a fase de demolição, a prática tem revelado um interesse superior nas fases anteriores do processo construtivo.

2.4.3       Implementação e dinamização de um sistema de informação baseado num BIM

2.4.3.1      Responsabilidade pela adopção e manutenção de um BIM

Importa reflectir acerca da responsabilidade da implementação de um sistema de gestão de informação associado a um qualquer projecto de construção e da sua dinamização.

Quem deve procurar promover uma alteração aos procedimentos habituais? Como fazê-lo? Admitindo que uma tecnologia considerada como viável para o efeito, isto é, um conjunto de sistemas cuja robustez tenha sido comprovada pela prática, esteja disponível para os diversos intervenientes, como deve ser feita a gestão da informação ao longo da duração do projecto? Quem deve dinamizar o processo?

São consideradas aqui duas repostas distintas para o conjunto de questões colocadas. Ambas apontam para soluções que visam desencadear, directa e indirectamente alterações nos procedimentos habituais.

Numa primeira solução, aponta-se a possibilidade de adoptar uma abordagem de algum modo dirigista, impondo directamente uma forma de trabalhar aos intervenientes de um processo construtivo. Esta abordagem é concebível para empreendimentos que admitem um actor principal na cadeia de valor (value chain master na bibliografia em língua inglesa), o que pode suceder, de alguma forma, nas grandes obras públicas, por exemplo. As parcerias público-privadas na construção podem ser encaradas como caso extremo, no contexto da indústria da construção, em que o consórcio assume a tarefa de value chain master. É possível que este actor principal imponha a utilização de tecnologias BIM, ERP ou de qualquer outra natureza aos restantes intervenientes em função da sua posição dominante na cadeia de valor.

Sugere-se ainda uma solução alternativa, adequada a obras de qualquer dimensão, públicas ou privadas. Esta solução é tornada possível pelas tecnologias BIM, embora o seu uso não seja imposto: estas são sugeridas aos intervenientes em função das vantagens que possam representar.

2.4.3.2      Dono de obra impõe sistema de informação directamente

As necessidades dos intervenientes, no que diz respeito à informação, são variáveis ao longo do processo construtivo. A intervenção de cada participante é, em geral, concentrada numa fase do processo, sendo relativamente limitada nas fases restantes. Um sistema de informação associado a um projecto de construção específico deve ser dinamizado por um agente que tenha responsabilidades em todo o processo construtivo, em particular nas fases de promoção, projecto, construção, até à entrega definitiva da obra.

Em segundo lugar, importa que o responsável pela gestão de um sistema de informação desta natureza, esteja interessado na divulgação da informação produzida durante o processo construtivo pelos vários intervenientes. Conforme foi referido anteriormente, muita da informação produzida pode ter implicações futuras ao nível da responsabilidade civil dos seus autores, o que resulta em alguma tendência para limitar a divulgação dessa informação.

Finalmente, considera-se que um sistema de informação adequado deve basear-se num modelo de informação sólido, que se constitua como padrão. Tem-se assistido a esforços no sentido de desenvolver um modelo com essas características mas, claramente, a tarefa afigura-se ambiciosa e inacessível à generalidade dos intervenientes em projectos de construção nacionais. Neste momento, a gestão de um sistema de informação exige ainda um esforço ao nível da investigação e do desenvolvimento só ao alcance de um conjunto muito limitado de intervenientes.

Os argumentos apresentados pretendem apontar no sentido de evidenciar a responsabilidade do Dono de Obra na gestão de um sistema de informação. Num momento inicial, os Donos de Obra públicos têm uma responsabilidade acrescida no sentido em que, por um lado, dispõem dos meios necessários ao esforço de investigação e desenvolvimento exigido para construir um modelo de informação para a construção ou para adaptar um modelo eventualmente existente. Por outro lado, sendo os maiores dos Donos de Obra, serão os únicos com capacidade para impor alterações às práticas correntes.

2.4.3.3      Sistema de informação resulta de processo de licenciamento

Embora a generalidade dos projectos de construção não admitam um actor principal da natureza descrita no ponto anterior, todos têm em comum uma fase em que a informação produzida deve ser formalizada e apresentada, sob a forma de peças escritas e desenhadas: o licenciamento.

Conforme o referido no capítulo 2.3.5.3, o uso de tecnologia BIM permite automatizar um conjunto de tarefas necessárias ao licenciamento de projectos.

Naturalmente, isto conduz a processos de licenciamento mais expeditos para projectos apresentados num formato adequado. A determinação do formato para licenciamento automático de projectos será da responsabilidade das entidades licenciadoras. As alternativas tradicionais continuarão a estar disponíveis pelo que esta solução não é imposta a qualquer dos intervenientes.

As vantagens desta solução são óbvias:

a.       O Dono da Obra vê reduzido o prazo de licenciamento, para além de dispor das vantagens, já referidas, associadas à tecnologia BIM.

b.      O projectista pode retirar toda a vantagem de uma tecnologia de projecto mais avançada, sem ter a necessidade de produzir todos os documentos habitualmente apresentados para licenciamento.

c.       As entidades licenciadoras passam a dispor de um processo de licenciamento expedito, o que resulta numa economia significativa ao nível dos recursos humanos necessários. O processo automático não é, necessariamente, definitivo (nem tal será forçosamente desejável). Todas as verificações automáticas podem ser alteradas manualmente, permitindo que as entidades preservem algum poder discricionário que lhes permita, por exemplo, ser condescendentes relativamente ao cumprimento de determinados requisitos considerados menos críticos, ou cujo cumprimento poderá ser conseguido através da adopção de disposições em momento posterior. Pode, também, ser importante que as entidades licenciadoras se reservem ao direito de não aprovar projectos, mesmo que estes sejam considerados aptos pelo sistema de verificação automática.

2.4.4       Características desejáveis num modelo de informação

Como conclusão do presente subcapítulo, enuncia-se em seguida um conjunto das características desejáveis consideradas mais relevantes num modelo de informação para a construção:

a.       Deve ser evolutivo para acompanhar todas as fases do processo construtivo descritas sucintamente acima;

b.      Deve permitir a geração automática de alguns dos documentos referidos;

c.       Deve funcionar como repositório central de informação, embora não esteja necessariamente localizado num computador único;

d.      Deve aceitar que vários intervenientes realizem trabalho simultâneo, evitando potenciais conflitos que possam decorrer deste tipo de utilização;

e.       Deve poder ser implementado com diferentes graus de compromisso, que estarão associados a uma maior ou menor necessidade de proceder a alterações aos procedimentos habituais na construção.

2.5    Licenciamento de projectos

2.5.1       O papel do termo de responsabilidade

O licenciamento é o processo pelo qual as autoridades competentes analisam os documentos fornecidos pelo requerente, tendo em conta os regulamentos, normas e leis aplicáveis, podendo conduzir à aprovação de um projecto de construção e consequente atribuição de uma licença de construção.

Embora as autoridades tenham frequentemente acesso a informação que lhes permitiria rever as decisões tomadas pelos projectistas – nomeadamente critérios e cálculos de dimensionamento nos diversos projectos de especialidade – não é habitual que o façam. Usualmente, é verificado apenas um conjunto limitado de disposições cujo cumprimento pode ser aferido sem o recurso a cálculos elaborados, confiando-se na capacidade dos técnicos responsáveis para garantirem que o projecto cumpre integralmente as regras aplicáveis.

O documento pelo qual o técnico assume a responsabilidade pelo cumprimento das regras em vigor para um determinado projecto é o termo de responsabilidade. Este papel do termo de responsabilidade, de garantia pela conformidade regulamentar e legal do projecto a apreciar, confere-lhe um estatuto de peça chave do processo de licenciamento. Um técnico que preste falsas declarações no âmbito de um termo de responsabilidade incorre em responsabilidades cíveis, criminais e disciplinares.

Dada a relevância do termo de responsabilidade no processo de licenciamento, importa analisar o significado real deste documento na óptica das entidades licenciadoras e dos projectistas.

Na óptica da entidade licenciadora, um termo de responsabilidade é um documento que deve garantir o cumprimento de normas e regulamentos que, tomando por verdadeiras as declarações que contém, permitiria reduzir o processo de licenciamento a uma sequência de procedimentos administrativos.

Os documentos técnicos apresentados pelo projectista permitiriam, tal como se referiu anteriormente, verificar a sua conformidade – ou seja, tornariam possível aferir a validade das declarações efectuadas no âmbito do termo de responsabilidade, tornando-o redundante – mas esta revisão do projecto seria muito exigente em termos de recursos técnicos. Assim, para a entidade licenciadora, o termo de responsabilidade representa, em última análise, uma economia no esforço de análise do projecto sujeito a apreciação e um mecanismo que permite evitar a transferência da responsabilidade do projectista para si mesma.

Na óptica do dono da obra, o termo de responsabilidade constitui, simultaneamente uma garantia de boa concepção e um veículo de transferência dos riscos correspondentes a problemas decorrentes de erros de projecto.

Tendo em conta os ambiciosos objectivos que um curto texto se propõe a atingir, importa reflectir acerca da validade técnica do termo de responsabilidade no contexto actual. Os textos que se seguem são excertos dos termos de responsabilidade dos autores de projectos de redes de distribuição predial de água e de drenagem de águas residuais de algumas das principais empresas do sector. Note-se que, nos textos apresentados, os projectos a que dizem respeito são designados por projectos de “abastecimento” ou de “redes de abastecimento” de água. Na presente dissertação, optou-se por designar estes projectos por “projectos de sistemas de distribuição predial de água”, em harmonia com a nomenclatura adoptada no Regulamento Geral dos Sistemas Públicos e Prediais de Distribuição de Água e de Drenagem de Águas Residuais. Considera-se que esta designação é a mais adequada uma vez que se pode definir um sistema de distribuição como o conjunto constituído pelas canalizações e órgãos prediais, incluindo o ramal de ligação (Paixão 1999). Por sua vez, o conceito de abastecimento é mais abrangente que o de distribuição, englobando órgãos do sistema a montante dos reservatórios de distribuição (Silva Afonso 1997).

(identificação completa do técnico responsável pelo projecto) declara, para efeitos do disposto no n.º 1 do artigo 10º do Decreto-lei n.º 555/99, de 16 de Dezembro, na redacção que lhe foi conferida pela Lei n.º 60/2007 de 4 de Setembro, que o projecto das redes prediais de abastecimento de água e de drenagem de águas residuais domésticas, de que é autor, relativa à obra localizada em (localização) pertencente a (identificação do dono da obra) observa as normas legais e regulamentares aplicáveis, designadamente o Regulamento dos Sistemas Públicos e Prediais de Distribuição de Água e de Drenagem de Águas Residuais Domésticas em vigor e o Regulamento Geral dos Sistemas Públicos e Prediais de Distribuição de Água e de Drenagem de Águas Residuais.

Texto 1 – Excerto do “Termo de responsabilidade do autor do projecto” de redes prediais (Águas do Porto 2008)

(identificação completa do técnico responsável pelo projecto) declara, para efeitos do disposto no nº. 1do Decreto-Lei n. 445/91, de 20 de Novembro, com as alterações introduzidas pelo Decreto-Lei nº. 250/94, de 15 de Outubro, que o projecto de execução das obras de abastecimento de água e de drenagem e tratamento de águas residuais de que é autor, relativo à obra de construção de um prédio localizado em (localização), cujo licenciamento foi requerido por (identificação do dono da obra), observa as normas técnicas gerais específicas de construção, bem como as disposições regulamentares aplicáveis.

Texto 2 – Excerto do termo de responsabilidade do autor do projecto de abastecimento de água e de águas residuais constante do Regulamento dos Sistemas Públicos e Prediais de Abastecimento de Água e de Águas Residuais do Município de Vila Nova de Gaia, (Águas de Gaia 2000)

Os textos apresentados são, obviamente, genéricos. Uma crítica frequentemente apontada aos termos de responsabilidade é a de que os projectistas se limitam a alterar a morada e a identificação do dono de obra em cada novo projecto, não sendo motivados pelo texto a reflectir acerca de eventuais erros que possam ter cometido na sua elaboração.

Sabendo-se que os meios e os prazos destinados à fase de projecto se revelam frequentemente escassos, a preparação de documentos como o termo de responsabilidade tende a ser encarada como uma tarefa administrativa adicional a efectuar, pelo que a sua validade enquanto garantia de cumprimento das normas e dos regulamentos aplicáveis é, no mínimo, discutível.

A prática comum de subcontratação de tarefas de projecto ou de disseminação do trabalho a efectuar por equipas alargadas de projectistas contribui também para algum enfraquecimento da validade da declaração efectuada no âmbito do termo de responsabilidade. Em rigor, o seu signatário desconhece, com alguma frequência, se as normas e os regulamentos aplicáveis foram, de facto, observados em todas as especificações de projecto preparadas.

Com efeito, tendo em conta as condições em que o termo de responsabilidade é redigido, parece lícito admitir que a declaração funciona mais como uma validação dos procedimentos seguidos pelas entidades responsáveis pela autoria do projecto do que a garantia de conformidade que se pretende que constitua. Considera-se assim que o termo de responsabilidade funciona frequentemente como uma declaração do seu signatário que confirma que o projecto foi preparado com base em meios que permitem adivinhar o cumprimento de normas e regulamentos (isto é, técnicos competentes, programas adequados, etc.), não como uma garantia aplicável a um projecto específico.

Como nota final, refere-se que o cumprimento das normas aplicáveis não é necessariamente uma garantia da qualidade do projecto. Alguns procedimentos de cálculo usados na análise de determinados produtos da construção não estão devidamente enquadrados nas normas nacionais aplicáveis. Assim, é possível que um projecto dimensionado a partir de uma avaliação tecnicamente acertada seja considerado não conforme com os regulamentos em vigor. No caso das redes de distribuição predial de água, por exemplo, os caudais de cálculo são obtidos tendo em conta os coeficientes de simultaneidade previstos no regulamento, o que resulta numa descontinuidade dos caudais de cálculo nos nós das redes. Esta abordagem é adequada para a generalidade das redes ramificadas, mas é claramente inapta para o cálculo de redes que contêm malhas. Neste tipo de redes, alterações ligeiras nos caudais instantâneos verificados nos dispositivos de utilização podem provocar mudanças significativas no funcionamento da rede, incluindo a inversão do sentido do escoamento ou a ocorrência de variações relativas substanciais do caudal em determinados troços. Desta forma, uma análise efectuada com base nas disposições regulamentares aplicáveis pode conduzir a um incorrecto dimensionamento da rede.

2.5.2       A importância do processo de licenciamento no contexto da gestão da informação

Foram abordadas, em 2.4.3.3, algumas razões que justificam a opção tomada de focar especificamente o processo de licenciamento entre todas as actividades que constituem o processo construtivo.

Com efeito, admite-se que uma introdução de métodos de verificação expedita de projectos, desde que entregues voluntariamente num dado formato, poderá ser uma medida cujas vantagens de segunda ordem ultrapassam os previsíveis ganhos de eficiência no processo de licenciamento.

Realce-se que não se encara o processo de licenciamento como uma questão avulsa. O licenciamento não deve ser visto como um processo isolado, nem um fim em si mesmo. É possível que funcione como um catalisador que facilite a introdução de novos métodos de trabalho e de novas formas de representação num sector frequentemente criticado pela sua aversão à mudança.

De acordo com o referido em 2.2.1, a indústria da construção é constituída por um grande número de empresas, quase todas de muito pequena dimensão, que não estabelecem, em geral, ligações de trabalho duradouras entre si. Esta característica torna mais difícil a adopção de formatos de representação padrão no sector da construção quando comparado com o sector automóvel, por exemplo, onde se identifica com alguma facilidade um número limitado de intervenientes com a capacidade de influenciar os métodos de trabalho ao longo da cadeia de valor onde se inserem. Os intervenientes que dominam uma cadeia de valor podem assumir a definição geral do sistema de informação, incluindo os dados de entrada e os resultados a retirar do sistema. No caso da construção essa figura só existe de facto nos projectos em que uma entidade é responsável por várias das fases do processo construtivo, isto é, em projectos do tipo concepção-construção ou concepção-construção-exploração. Dada a ausência efectiva e persistente de um value-chain master (ver 2.4.3.1) no sector da construção, admite-se que o seu papel tutelar no âmbito da definição de formatos de representação padrão pode ser ocupado pela figura do processo de licenciamento: a entidade licenciadora define um formato que pretende estabelecer como padrão.

Os participantes no processo construtivo seriam motivados para a produção de conteúdos num formato compatível com o utilizado no processo de licenciamento, logo à formalização da informação gerada.

Note-se que, conforme se descreveu neste trabalho, já estão disponíveis modelos de informação que permitem representar satisfatoriamente a generalidade dos produtos de construção. Alguns destes modelos estão implementados em ferramentas comerciais populares disponíveis para o uso dos projectistas. Admitindo que a utilização destes modelos seria benéfica para a indústria e constatando a fraca receptividade que têm recebido junto dos participantes no processo construtivo (McGraw Hill Construction 2007), (Weise et al. 2008), é-se obrigado a questionar a real maior valia representada por estas formas de representação e a forma como a comunidade se apercebe dessas supostas vantagens. O facto dos modelos de informação para a construção serem ainda uma tecnologia recente, que carece de uma variedade de aplicações informáticas, algumas das quais ainda por desenvolver, para desencadear todas as suas potencialidades, impede uma avaliação fiável dos seus benefícios. A receptividade deste tipo de tecnologias noutras indústrias permite adivinhar alguns benefícios possíveis para a construção, mas não constitui por si só uma prova de que a tecnologia produzirá um impacto positivo no sector. Alguns resultados apresentados indiciam ganhos de produtividade em algumas tarefas como resultado directo da utilização dos BIM, mas acredita-se que os maiores benefícios decorrerão de uma implementação desta tecnologia ao longo de todo o processo construtivo, conforme foi referido em 2.3.5.3. Não é ainda possível pois, aferir a utilidade dos BIM com base em resultados anteriores. Considera-se que, apesar das aparentes vantagens oferecidas por esta tecnologia, é importante apresentar aos intervenientes benefícios evidentes e imediatos como resultado da utilização de formas de representação padrão. Neste contexto, um sistema de licenciamento automático de projectos seria um importante argumento a favor da utilização dos BIM.

Como conclusão refere-se assim que o processo de licenciamento é importante no contexto da gestão da informação por duas ordens de razões:

a.       Em primeiro lugar porque, fixando uma forma de representação padrão e forçando a explicitação de um conjunto de requisitos de projecto, funciona como catalisador para uma mudança nos métodos de trabalho;

b.      Em segundo lugar, porque oferece aos intervenientes vantagens evidentes, condição essencial para uma rápida disseminação dos modelos de informação na construção.

2.5.3       Licenciamento automático de projectos: Iniciativas em curso

A automatização do processo de licenciamento, com base em representações em formato padrão dos produtos de construção, é vista como um objectivo a ser atingido pelo sector da construção a partir do ano 2020 (Eastman et al. 2008).

A nível internacional, existem actualmente algumas iniciativas neste âmbito das quais se destacam os projectos CORENET (referido em 2.3.5.3.5) na Singapura e SMARTCodes centrado nos EUA.

O projecto SMARTCodes foi criado em Novembro de 2006 pela associação Norte Americana ICC – International Code Council – com o objectivo de estabelecer definições básicas para processos automatizados de verificação de conformidade regulamentar nos EUA (ICC 2006). A ICC é uma associação fundada em 1994, que se dedica à segurança em edifícios e à segurança contra incêndios e que elabora os respectivos regulamentos usados em edifícios residenciais e comerciais na maior parte das cidades, condados e estados dos EUA (ICC 2008).

De acordo com a informação recolhida (ICC 2006), não existe nenhuma aplicação dos métodos de verificação automática a funcionar em situações reais. O projecto estará numa fase inicial de desenvolvimento. Ainda de acordo com o ICC, nesta fase estão a ser desenvolvidas formas de verificação para disposições regulamentares que sejam consideradas de análise simples. Só no futuro serão abordadas as disposições regulamentares cuja verificação careça de algum cálculo, a realizar por aplicações externas. O objectivo final será a verificação automática de todos os regulamentos aplicáveis à construção a partir de um modelo BIM submetido pelo projectista.

O projecto SMARTCodes depende do modelo IFC como input e como meio de interagir com aplicações externas de cálculo.

2.5.4       Licenciamento de projectos de sistemas prediais de águas e esgotos

É possível identificar 4 tarefas principais que constituem um processo de licenciamento:

a.       Organização documental;

b.      Apreciação técnica de projectos;

c.       Fiscalização de obras;

d.      Comunicação com requerente e com outras entidades.

Estas tarefas não se processam, necessariamente de forma consecutiva (isto é, não são tarefas “monolíticas” com um encadeamento do tipo fim-início). A ocorrência de mais de uma tarefa em simultâneo é frequente o que, apesar de resultar em algumas vantagens evidentes relacionadas com a mobilização simultânea de um número significativo de técnicos, é um procedimento responsável por alguma desorganização do ponto de vista processual. Com efeito, as entidades em que a separação destas tarefas não é clara, apresentam alguma dificuldade em reconhecer um processo como formalmente completo (uma vez que o processo circula, fragmentado, no interior da organização), o que por sua vez resulta num obstáculo à implementação de processos de gestão e, eventualmente, em extravio de documentos.

O licenciamento de projectos de redes prediais de abastecimento de água oferece algumas vantagens relativamente a outros projectos de especialidade, que o torna um processo particularmente apto para ser automatizado. Apresenta-se, na Tabela 3, um conjunto de características que justificam a importância atribuída ao licenciamento de projectos de redes de distribuição predial de água enquanto catalisador do processo de adopção de modelos de informação para a construção.

Tabela 3 – Projectos de sistemas de distribuição predial de água: Características que favorecem a adopção de processos de licenciamento automático

Característica

Observação

Complexidade da rede

As redes são formadas por um conjunto relativamente limitado de componentes. Esta característica é partilhada, por exemplo, com as estruturas metálicas, conforme se referiu em 2.2.1.

Os regulamentos aplicáveis dividem os componentes de rede num conjunto restrito de categorias.

Geometria da rede

A geometria das redes é simples e pode ser representada, de forma simplificada, por um conjunto de nós e de ligações, isto é, por um grafo.

Esta simplicidade contrasta, por exemplo, com a potencial variedade de formas e de ligações entre componentes de uma estrutura em betão armado.

Cálculo hidráulico

O cálculo de sistemas de distribuição predial de água é um processo relativamente pouco complexo, baseando-se num conjunto limitado de regras aptas para a aplicação de métodos computacionais.

Relação com projecto geral de arquitectura (ver também 2.5.5.2)

As interdependências dos projectos de sistemas de distribuição predial de água e do projecto geral de arquitectura são simples de estabelecer. Embora seja importante relacionar, por exemplo, os dispositivos de utilização com a divisão onde estes se encontram, essa ligação pode ser efectuada de uma forma nominativa (por exemplo, aparelho A – divisão D).

Um projecto de comportamento térmico de um edifício, por exemplo, tem uma ligação mais difícil de efectuar com o projecto de arquitectura: requer a medição de áreas de elementos da envolvente exterior, de volumes de divisões, etc.

Processo de licenciamento

O processo de licenciamento decorre habitualmente num local único, com a participação de um conjunto limitado de intervenientes (a excepção são as redes de incêndios).

Pode-se apontar, porém, uma desvantagem a considerar na automatização de processos de licenciamento de projectos de redes de distribuição predial de água: a coexistência de um grande número de regulamentos de âmbito local. Considera-se que a viabilidade da implementação de um sistema de licenciamento automático de projectos pode ser afectada pela existência de excepções ao regulamento nacional. A definição de um modelo de informação que abranja todas as disposições regulamentares existentes em todos os regulamentos locais seria uma tarefa complexa, morosa e fundamentalmente pouco útil. Seria claramente mais vantajoso adoptar um regulamento único a nível nacional.

A Fig. 19 ilustra o processo de aprovação de um projecto de abastecimento de águas segundo o Manual de Redes da EPAL (EPAL 2006).

Fig. 19 – “Fluxograma de um processo de abastecimento” (EPAL 2006)

2.5.5       Análise regulamentar

2.5.5.1      Aspectos gerais

Uma vez que se pretende construir um modelo parcial dedicado ao processo de licenciamento de projectos de sistemas de distribuição predial de água, importa analisar em primeiro lugar as disposições regulamentares a verificar e o processo actualmente seguido pelas entidades licenciadoras durante a apreciação de projectos.

Apresenta-se no Anexo A uma tabela que resume a análise efectuada ao DR nº 23/95 – Títulos III (Sistemas de distribuição predial de água) e V (Sistemas de drenagem predial de águas residuais).

A avaliação efectuada resulta num conjunto de orientações – apresentadas em 2.5.5.4 – para o desenvolvimento de um modelo de representação e de um sistema de verificação automática de projectos.

2.5.5.2      Relação dos projectos de sistemas de distribuição predial de água com restantes projectos

No caso dos edifícios, os projectos de sistemas de distribuição predial de água estarão sempre subordinados a um projecto geral, normalmente a um projecto geral de arquitectura. Assim, as verificações de conformidade regulamentar, a efectuar aquando do processo de licenciamento, terão como base não só as especificações elaboradas pelo projectista da especialidade em causa mas também as elaboradas pelos restantes autores de projectos, em particular pelo autor do projecto geral.

Esta reflexão é particularmente relevante no contexto do licenciamento automático de projectos. A apreciação simultânea de elementos provenientes de diferentes projectos exige um modelo de informação extremamente complexo (um “modelo completo”, conforme foi designado neste trabalho). Em contrapartida, verifica-se que estas questões multidisciplinares são, regra geral, de fácil verificação por métodos manuais, frequentemente por observação directa.

Apresenta-se, a título de exemplo, o Artigo 107º do Regulamento Geral dos Sistemas Públicos e Prediais de Distribuição de Água e de Drenagem de Águas Residuais:

Artigo 107º -  Localização dos contadores

1 – Nos edifícios confinantes com a via ou espaços públicos, os contadores devem localizar-se no seu interior, na zona de entra ou em zonas comuns, consoante se trate de um ou de vários consumidores.

2 – Nos edifícios com logradouros privados, os contadores devem localizar-se:

a.       No logradouro junto à zona de entrada contígua com a via pública, no caso de um só consumidor;

b.       No interior do edifício em zonas comuns ou no logradouro junto à entrada contígua com a via pública, no caso de vários consumidores.

Texto 3 – Artigo 107º do Regulamento Geral dos Sistemas Públicos e Prediais de Distribuição de Água e de Drenagem de Águas Residuais – Relação entre o projecto de sistema de distribuição predial de água e projecto geral de arquitectura

Os artigos 96º e 250º, apresentados em seguida, relacionam também o projecto de águas e esgotos com outros projectos de especialidades.

Artigo 96º - Instalação

(…)

5 – As canalizações não devem ficar:

a.       Sob elementos de fundação;

b.      Embutidas em elementos estruturais;

c.       Embutidas em pavimentos, excepto quando flexíveis e embainhadas;

d.      Em locais de difícil acesso;

e.        Em espaços pertencentes a chaminés e a sistemas de ventilação.

Texto 4 – Artigo 96º do Regulamento Geral dos Sistemas Públicos e Prediais de Distribuição de Água e de Drenagem de Águas Residuais – Relação entre o projecto de sistema de distribuição predial de água e outros projectos de especialidades

Artigo 250º - Câmara de ramal de ligação

1 – É obrigatória a construção de câmaras implantadas na extremidade de jusante de sistemas prediais, estabelecendo a ligação destes aos respectivos ramais de ligação, localizadas preferencialmente fora da edificação, em logradouros quando existam, junto à via pública e em zonas de fácil acesso.

2 – Quando as câmaras de ramal de ligação não possam ser instaladas no exterior das edificações, por implicações com outras infra-estruturas, as mesmas devem ser instaladas dentro das edificações, em zonas de fácil acesso e em zonas comuns nos edifícios de vários fogos.

(…)

Texto 5 - Artigo 250º do Regulamento Geral dos Sistemas Públicos e Prediais de Distribuição de Água e de Drenagem de Águas Residuais – Relação entre projecto de águas e esgotos e projecto geral de arquitectura

Pretende-se, com os exemplos apresentados, evidenciar os seguintes aspectos:

a.       A consideração de interfaces entre projectos diferentes aumenta consideravelmente a complexidade dos modelos necessários à tarefa de verificação automática.

b.      Algumas verificações, complexas sob o ponto de vista computacional, são triviais para os humanos. A identificação de elementos construtivos e a sua associação com as respectivas funções, por exemplo, revela-se frequentemente uma tarefa extremamente exigente para um programa informático embora seja uma actividade intuitiva e expedita para a generalidade das pessoas.

c.       Algumas disposições regulamentares conferem alguma discricionariedade a que verifica a sua conformidade regulamentar uma vez que são baseadas em parâmetros qualitativos (por exemplo, alínea d) do ponto 5 do artigo 96º).

Retoma-se pois, a discussão iniciada em 2.3.3 acerca das vantagens e desvantagens dos “modelos completos” sobre os “modelos parciais”. É importante definir o grau de complexidade pretendido para um modelo de informação a ser usado para o licenciamento automático de projectos. É possível definir um conjunto de soluções alternativas para o efeito:

a.       Um modelo completo que contenha informações relativas a todos os projectos, isto é, uma imagem detalhada do edifício a construir;

b.      Um modelo parcial (ou uma parte de um modelo completo) que contenha toda a informação necessária à realização da tarefa por meios exclusivamente automáticos;

c.       Um modelo parcial (ou uma parte de um modelo completo) que contenha apenas a informação necessária à realização de uma parte das verificações por meios automáticos, admitindo que as verificações restantes serão efectuadas por meios manuais.

Considera-se que a primeira opção é, no curto prazo, inverosímil, quer por razões técnicas quer, sobretudo, por razões culturais: não é concebível que a generalidade dos intervenientes adopte integralmente a tecnologia BIM no imediato.

A segunda opção, embora atraente do ponto de vista conceptual (reduz-se o processo de licenciamento a um procedimento inteiramente automático), requer igualmente o desenvolvimento de um modelo complexo, o que exige um esforço considerável por parte de todos os intervenientes para obter resultados adicionais modestos. De acordo com o referido neste capítulo, algumas verificações possíveis de efectuar instantaneamente por meios manuais exigem a introdução de um volume de informação muito significativo e o desenvolvimento de aplicações informáticas consideravelmente mais complexas para serem realizadas de forma automática.

A terceira opção combina as vantagens relativas dos meios manuais e automáticos de forma a obter uma solução que, por um lado, seja de adopção verosímil no curto prazo e que, por outro, funcione como um incentivo à utilização de novas tecnologias da informação na indústria da construção.

Note-se que os modelos parciais e os modelos completos não são entendidos como soluções mutuamente exclusivas. As vantagens e desvantagens de cada um deles são suficientemente relevantes para justificar o uso simultâneo de ambos. Por outro lado, não se argumenta a favor do desenvolvimento simultâneo de projectos com base em dois modelos distintos o que, de acordo com o que se referiu neste trabalho, representaria um desperdício resultante da realização de tarefas redundantes pelo projectista. Considera-se útil que a informação contida num modelo parcial possa ser convertida para um formato que possa ser usado na constituição de um modelo completo e vice-versa.

O esquema apresentado na Fig. 20 ilustra, de uma forma muito simplificada, a interacção entre as especificações correspondentes ao projecto geral de arquitectura e as dos projectos de águas e de esgotos. Note-se que as especificações correspondentes às redes de águas e de esgotos são aqui encaradas como entidades separadas. Embora as especificações sejam associadas, uma vez que são regidas pelo mesmo regulamento, as verificações a efectuar são diferentes para cada uma das redes e constata-se que as interacções entre ambas as redes são pontuais.

De acordo com o referido neste capítulo, a consideração de cada domínio adicional (ou seja, de cada novo projecto), acrescenta uma complexidade significativa ao modelo de informação requerido para o licenciamento automático. A avaliação detalhada dos regulamentos aplicáveis aos projectos de águas e esgotos e da informação necessária à sua verificação sugere que, para além da informação correspondente (em exclusivo) aos domínios “águas” e “esgotos”, seja considerada a informação comum a ambos os domínios – isto é, considera-se desejável que os modelos de representação de redes de esgotos e de distribuição de água tenham uma parte comum – mas que algumas questões relacionadas com o projecto de arquitectura sejam remetidas para uma verificação manual.

Assim, considera-se que os caudais de cálculo a considerar para as redes de distribuição e de saneamento devem ser obtidos a partir de uma referência comum (o que, de uma forma implícita, corresponde a associar os modelos de cada uma das redes ao nível dos seus acessórios).

Considera-se também que as verificações correspondentes aos artigos 96º, 107º e 250º, por exemplo, devem ser efectuadas por processos manuais ou que, em alternativa, se confie nas declarações prestadas pelo projectista num termo de responsabilidade aumentado, onde o projectista explicite o cumprimento de determinadas disposições regulamentares (ver 2.5.5.4).

Fig. 20 – Relação de projectos de águas e esgotos com o projecto geral de arquitectura

2.5.5.3      Disposições regulamentares de verificação automática simples e complexa

De acordo com o projecto SMARTCodes referido em 2.5.3, é possível identificar disposições regulamentares cuja verificação automática é simples – em geral aquelas cuja verificação pode ser efectuada sem recurso a cálculo – e outras de verificação complexa – que exigem o apoio de aplicações de cálculo externas.

Foram referidos, no ponto anterior, alguns factores que simplificam a verificação automática de algumas disposições regulamentares relativamente a outras. Concluiu-se que os aspectos construtivos cuja validação regulamentar depende da sobreposição de informação habitualmente presente em projectos de especialidade distintos são complexos de aferir por meios automáticos, embora sejam, por norma, simples de observar por meios manuais.

Concluiu-se ainda que algumas disposições conferem alguma discricionariedade a quem verifica a sua conformidade regulamentar, ao não estabelecer parâmetros quantitativos para o seu cumprimento.

Admite-se que é possível estabelecer modelos de informação aptos para efectuar qualquer tipo de verificação de forma automática, embora possam ser considerados inadequados por uma de duas razões antagónicas:

a.       Modelos demasiado complexos: Como se afirmou neste trabalho, a complexidade dos modelos de informação não incentivam a sua adopção por parte da comunidade técnica. Um dos sintomas apontados para a gestão ineficiente de informação consiste comunicação demorada entre intervenientes. Considera-se que a implementação de procedimentos que obriguem à introdução de um volume de dados consideravelmente superior àquele que é exigido pelas práticas correntes tenderá a corrigir um problema – neste caso, um problema da entidade responsável pelo licenciamento – ao mesmo tempo que cria outro – ao projectista. Não se considera razoável que, para garantir a verificação inteiramente automática de uma disposição regulamentar simples – por exemplo, o artigo 107º que define as localizações autorizadas para um contador – se obrigue o projectista a definir a geometria do logradouro, a posição da entrada, etc. Recorda-se que um objectivo deste trabalho é identificar formas de incentivar a adopção de novas tecnologias na fase de projecto o que seria manifestamente contrariado por um procedimento com estas características.

b.      Modelos demasiado simples: É possível efectuar a verificação de conformidade de um projecto exclusivamente com base nas declarações do projectista: exigindo-lhe que confirme explicitamente a conformidade com cada um das disposições regulamentares. Uma abordagem deste tipo aproxima-se claramente da abordagem tradicional, baseada no termo de responsabilidade do projectista. Tem algum interesse no sentido da desmaterialização de processos e na clarificação de responsabilidades, mas para além destes objectivos, o seu impacto seria relativamente diminuto.

Assim, considera-se que há vantagem em manter algumas verificações manuais (que devem ser devidamente identificadas como tal) ao mesmo tempo que se deve automatizar a verificação das disposições mais aptas para esse fim.

2.5.5.4      Conclusões da análise regulamentar

Apresenta-se neste ponto um conjunto de conclusões da análise regulamentar efectuada. Estas conclusões são relevantes para a definição do tipo de modelo a elaborar pelo que a discussão será retomada no capítulo 4.4.3, onde serão definidas as formas de verificação a aplicar a cada um dos artigos.

Os artigos do Regulamento Geral dos Sistemas Públicos e Prediais de Distribuição de Água e de Drenagem de Águas Residuais correspondentes às redes prediais de águas e esgotos foram analisados com o propósito de avaliar a sua aptidão para serem verificados de forma automática ou manual. Apresenta-se no Anexo A uma tabela onde se resume as avaliações efectuadas.

Em síntese, considera-se que a generalidade dos artigos pode ser sujeita a uma verificação automática, contudo, num conjunto limitado de casos, as dificuldades associadas à adopção deste tipo de processo podem superar os potenciais benefícios que possam daí resultar.

Se um projecto for avaliado com recurso a processos manuais, constata-se que a conformidade regulamentar relativa a alguns artigos – relacionados com a segurança de bens, por exemplo (ver 3.2) – pode ser aferida através de uma rápida leitura das peças desenhadas. Esta simplicidade contrasta significativamente com a maior dificuldade em avaliar o funcionamento hidráulico da rede e em validar o dimensionamento dos componentes da rede, efectuado pelo projectista.

Se a análise for efectuada de forma automática, constata-se que, regra geral, os aspectos relacionados com o funcionamento hidráulico da rede, frequentemente associados a um modelo numérico que terá de ser construído e validado, são mais aptos para uma verificação automática do que os aspectos relacionados com a concepção geral do edifício, que só poderão ser convenientemente avaliados com base num modelo de informação mais complexo.

Os modelos de informação que podem ser utilizados para o fim da verificação automática da conformidade regulamentar de projectos podem ser mais ou menos complexos em função do volume de informação que se pretende que seja introduzido pelo projectista e da quantidade e da natureza das verificações a efectuar.

Os modelos mais simples não contêm informação geométrica acerca do edifício que representam. Estes modelos simples deverão assumir a forma de uma checklist cujo preenchimento, por parte do projectista, dará resposta directa às questões regulamentares consideradas pertinentes pela entidade responsável pelo licenciamento. Admite-se mesmo que um documento deste tipo poderá ser visto como uma versão detalhada do termo de responsabilidade, em que o projectista deve discriminar as opções tomadas perante o regulamento aplicável.

A adopção de um modelo de informação baseado numa checklist permitiria, por um lado, clarificar as opções tomadas pelo projectista, em particular as verificações regulamentares que efectuou e, por outro lado, contornar algumas dificuldades inerentes à introdução de modelos de informação mais completos no processo construtivo.

Desta forma, seria possível dividir os aspectos que serão obrigatoriamente alvos de análise durante o processo de licenciamento em 4 grupos, de acordo com a forma como essa análise poderá ser efectuada:

a.       Aspectos cuja verificação é considerada simples do ponto de vista manual, mas complexa do ponto de vista computacional (por exemplo, Artigo 107º do Dec. Reg. nº 23/95);

b.      Aspectos cuja verificação é considerada complexa ou trabalhosa do ponto de vista manual, mas relativamente simples do ponto de vista computacional (por exemplo, Artigo 94º do Dec. Reg. nº 23/95 – Dimensionamento hidráulico);

c.       Aspectos cuja verificação é considerada simples, tanto do ponto de vista manual como do ponto de vista computacional (por exemplo, localização da obra ou identificação de dono da obra nos termos do regime jurídico do licenciamento de obras particulares);

d.      Aspectos cuja verificação encerra alguma subjectividade, admitindo múltiplas interpretações independentemente do processo de análise escolhido (por exemplo, alínea d) do número 5 do Artigo 96º do Dec. Reg. nº 23/95).

Esta reflexão conduz a um conjunto de orientações para a definição de um sistema de verificação automático com diferentes níveis de compromisso, de acordo com a maior ou menor vontade de introduzir alterações significativas nas tecnologias de informação adoptadas, em particular nas fases do processo construtivo que antecedem a execução da obra:

a.       Todos os aspectos que podem ser alvo de verificação por parte da entidade responsável pelo licenciamento podem ser incluídos num sistema de informação formal.

b.      Quase todos estes aspectos podem ser verificados de forma automática. A única excepção são as disposições regulamentares cuja apreciação não pode ser efectuada de forma objectiva, uma vez que não estão associadas a parâmetros quantitativos. Em rigor, esta dificuldade coloca-se igualmente aos avaliadores humanos, não sendo exclusiva dos métodos de avaliação automática.

c.       O sistema de informação poderá ser constituído por um componente baseado nas informações prestadas pelo projectista (sob a forma de uma declaração, que pode assumir a forma de uma checklist) e por um modelo de informação baseado nas componentes individuais do edifício (por exemplo, na matéria em apreço, uma base de dados contendo informação acerca das características dos componentes da rede e da forma como estas estão ligadas entre si). Embora ambos os componentes possam ser classificados por si só ou em conjunto como um BIM, importa distingui-los em função da natureza da informação que contêm, da forma como essa informação é apresentada e do uso que pode ser dado a dessa informação.

d.      As vantagens e desvantagens associadas a modelos de informação mais ou menos completos (já discutidas em maior detalhe neste trabalho) aconselham a adopção de modelos mistos, com componentes que se aproximam daquilo que a maior parte dos profissionais reconheceriam como um BIM e outras mais próximas de um termo de responsabilidade de um projectista.

e.       Num modelo de informação mais simplificado, deve ser privilegiada a componente “checklist”. No limite, todos os aspectos regulamentares considerados relevantes deverão ser discriminados na checklist. O projectista deverá apresentar, sob a forma de uma declaração, as verificações que realizou, que conduziram ao dimensionamento hidráulico efectuado (nomeadamente, velocidades e pressões máximas na rede).

f.       Num modelo completo, devem ser usados os formatos padrão (IFC ou outro) que permitem a extracção de toda a informação necessária à verificação regulamentar automática.

g.      Num modelo “híbrido”, devem ser tidas em conta as considerações efectuadas neste capítulo acerca da maior ou menor simplicidade com que determinadas verificações podem ser efectuadas por processos manuais ou automáticos. Deve ser avaliada a possibilidade de integrar toda a informação necessária para a verificação manual de um projecto num modelo mais detalhado, dando-se prioridade aos aspectos cuja verificação automática seja considerada simples. As questões relacionadas com o dimensionamento hidráulico poderiam ser vistas neste contexto como prioritárias. De uma forma genérica, pode afirmar-se que as questões que envolvem uma modelação numérica da rede devem ser verificadas por computadores; as questões que podem ser verificadas por uma simples observação do projecto por parte de um técnico devem ser consideradas não prioritárias sob o ponto de vista da sua possível inclusão num sistema automático.

A simplicidade inerente a um conjunto significativo de verificações regulamentares por métodos manuais desaconselha a sua validação por processos automáticos, salvo se forem adoptados formatos padrão para todas as especialidades de projecto (que podem ser produzidos usando ferramentas comerciais disponíveis). Apenas desta forma se poderá admitir que as vantagens decorrentes de uma verificação automática justificam o maior esforço exigido aos projectistas na formalização das disposições de projecto.

2.6    Conclusões da revisão do estado da arte

2.6.1       Má gestão da construção: Um infeliz equilíbrio

A gestão da informação nas actividades na área da construção é claramente ineficiente quando comparada com aquela que é realizada em outras actividades industriais.

Erros de projecto, lacunas nos documentos de trabalho, coexistência de diversas versões do mesmo documento que circulam entre os intervenientes do processo construtivo, existência de aplicações que trabalham com formatos incompatíveis e que conduzem a processos demorados e propensos a erros, métodos de trabalho que requerem a introdução repetida dos mesmos dados em mais de uma aplicação informática são exemplos de má gestão da informação.

Para além das características específicas da actividade, dos seus intervenientes, dos seus produtos e das suas práticas tradicionais, o funcionamento do mercado de projectos ajuda a explicar um ciclo que resulta em algumas das ineficiências descritas.

O custo dos projectos de construção é extremamente reduzido quando comparado com o de outras actividades industriais. Ao mesmo tempo, os donos de obra continuam a preferir projectos exclusivos, não optando por soluções pré-fabricadas. Os reduzidos custos de projecto obrigam as empresas de projecto na área da construção a um ciclo de trabalho muito distinto daquele que caracteriza outras indústrias. Esta gestão pode comprometer a qualidade global do projecto e, simultaneamente, desincentiva o investimento em investigação e desenvolvimento.

Assim, a indústria da construção tem vivido numa espécie de infeliz equilíbrio – usando a expressão típica da Teoria dos Jogos – que, apesar de reiteradas avaliações que a colocam entre as actividades com um mais baixo nível de utilização de novas tecnologias, impede o desenvolvimento e a implementação de soluções que alterem os processos de trabalho.

Por definição, numa situação de equilíbrio nenhum interveniente pode melhorar a sua situação actuando de forma isolada.

Se um projectista optar por praticar preços significativamente acima do preço de mercado, mesmo incrementando a qualidade do produto, deixa de ser competitivo.

Se o dono de obra optar por pagar mais do que o normal, é provável que o projectista tenda a não alterar significativamente a qualidade do produto: o acréscimo do preço repercutir-se-á provavelmente num aumento da margem do projectista, não tanto num acréscimo de qualidade proporcional – porquê fazer muito melhor do que a concorrência? Para além disso, dada a dimensão do mercado da construção, a mudança de atitude de um número restrito de clientes – a não ser que sejam clientes particularmente representativos como é o caso do Estado em Portugal – dificilmente produzirá alterações neste estado de equilíbrio.

Infelizmente, numa situação de equilíbrio, não se pode afirmar que ocorre o máximo benefício acumulado para os intervenientes.

2.6.2       Caminhos possíveis para alterar o equilíbrio

Considera-se que as soluções mais racionais (e mais favoráveis) à alteração da situação actual devem seguir uma combinação de duas soluções:

a.       Padronização de produto: Criar condições para que soluções estandardizadas (em particular as pré-fabricadas) sejam mais apetecíveis por parte dos clientes. Esta tarefa não se tem afigurado simples. Com efeito, as soluções pré-fabricadas existem há décadas, com um potencial muito superior ao que a sua quota de mercado parece sugerir.

b.      Padronização de actividades de projecto: Criar condições para que os custos de projecto se mantenham ou se reduzam, mas que a qualidade aumente. Importa para tal procurar transformar as práticas seguidas na fase de projecto em processos. É esta a solução que é explorada ao longo deste trabalho.

Conforme se refere neste trabalho, considera-se que a tecnologia disponível permite actuar neste sentido.

2.6.3       O papel dos modelos de informação para a construção

Os modelos de informação para a construção são suportes para um conjunto de aplicações informáticas. Permitem a interoperabilidade entre sistemas e a automatização de processos. Espera-se que a este acréscimo de eficiência correspondam reduções de prazos e minimização de erros cometidos ao longo do processo.

Nos últimos 10 anos, o surgimento de modelos de informação como o IFC motivam algum optimismo quanto à possibilidade de alteração dos processos de trabalho tradicionais.

Não se afigura provável que a utilização destas novas tecnologias no sector da construção conheça um crescimento incremental. As vantagens da utilização destas ferramentas só são realmente significativas se a indústria reconhecer nelas virtudes suficientemente evidentes para justificar uma adopção em massa, súbita. A abordagem estruturalista seguida no desenvolvimento do IFC não favorece a adesão rápida da comunidade de utilizadores.

Admite-se que o desenvolvimento de formatos que procurem responder de forma directa aos problemas específicos de diversos subsectores da área da construção pode ser um mecanismo de mudança importante.

Esta abordagem minimalista ao desenvolvimento de formatos de representação não colide de forma alguma com o objectivo de criar um modelo detalhado e completo para a construção. Pelo contrário, pretende-se que estes modelos de âmbito mais restrito façam a ponte entre os utilizadores e o modelo completo. Pretende-se que, por um lado, os modelos minimalistas sejam capazes de resolver os problemas específicos dos utilizadores e que, por outro, forneçam indicações importantes para o desenvolvimento futuro de modelos completos.

Compete às organizações com capacidade para criar essas condições ao nível do sector da construção, actuar em conformidade.

2.6.4       O papel do processo de licenciamento automático de projectos

Considera-se que é importante criar aplicações práticas para os modelos de informação para a construção que ofereçam vantagens evidentes para quem os adopte.

Considera-se ainda que se deve procurar influenciar, em primeiro lugar, os intervenientes nas primeiras fases do processo construtivo, nomeadamente os donos de obra e os projectistas. Esta ênfase nas primeiras fases do processo construtivo deve-se a dois motivos principais:

a.       A sua maior importância relativa no que toca a influenciar o custo final dos empreendimentos;

b.      A importância, para os intervenientes nas fases seguintes do processo, em particular nas fases construção e de manutenção, de herdar os modelos criados nas primeiras fases do processo construtivo. Uma parte significativa da informação necessária nas últimas fases do processo construtivo é produzida e organizada nas primeiras fases. É importante evitar as perdas de valor associadas a uma deficiente transição de informação entre os intervenientes em cada uma das fases do processo.

O licenciamento de projectos de construção corresponde a uma entrega formal de documentos. Regra geral, corresponde à primeira representação formal da obra que deve ser apresentada com carácter obrigatório. Segundo a prática tradicional, há nesta fase uma interrupção do processo criativo, ocorrendo então a representação da informação produzida – a prática tradicional separa a criação de informação da sua representação. Considera-se, pois, que há toda a conveniência em aproveitar esta singularidade no processo construtivo para que, em alternativa à representação seguindo os formatos tradicionais (peças escritas e desenhadas) o projectista promova a representação em formatos que incluam conhecimento (modelos paramétricos).

Assim, admite-se que a concessão de benefícios – por exemplo, licenciamento mais expedito – aos intervenientes que adoptem formatos de representação padrão – nomeadamente, modelos parciais – pode ser um incentivo importante à alteração de práticas de trabalho.

Uma vez que um projecto se divide em diversas especialidades, a cada especialidade corresponderia potencialmente um modelo parcial para efeitos de licenciamento. A transição deste conjunto de modelos parciais para um modelo completo, caso fosse desejado por algum dos intervenientes, seria claramente mais suave.

Dado que o licenciamento de projectos se baseia em regulamentos nacionais (ou locais), é importante definir modelos de informação que correspondam às exigências de cada país ou, em alternativa, definir critérios de licenciamento aplicáveis, por exemplo, a nível comunitário.

3     Requisitos a cumprir pelos projectos de sistemas de distribuição predial de água

3.1    Introdução

O licenciamento de projectos não é, evidentemente, um fim em si mesmo. É um meio que visa estabelecer níveis de desempenho mínimos perante um conjunto de exigências consideradas comuns ao tipo de projectos a avaliar.

Importa, pois, identificar um conjunto de requisitos a impor aos projectos de sistemas de distribuição predial de água. Decidiu-se dividir estes requisitos nas seguintes categorias:

a.       Segurança de pessoas e bens;

b.      Respeito pelo ambiente;

c.       Fiabilidade do sistema público;

d.      Eficácia;

e.       Eficiência e economia.

A satisfação destes requisitos deverá ser o objectivo primordial de um sistema de avaliação de projectos.

Nem todos os requisitos deverão ser alvo de apreciação durante o processo de licenciamento. Ainda assim, considera-se que a metodologia proposta não se deve limitar à verificação das disposições regulamentares, mas deve estender-se a outros parâmetros que permitam a avaliação da qualidade do projecto. Esta extensão aos objectivos fundamentais do trabalho foi efectuada no sentido de alcançar os seguintes resultados:

a.       Desenvolver uma metodologia que não se restrinja a um regulamento específico. Em Portugal, os regulamentos de instalações prediais de águas e saneamento admitem, como se sabe, variações locais, pelo que importa alargar o âmbito da metodologia proposta sob pena de se limitar a sua aplicabilidade a uma escala local.

b.      Alargar o campo de aplicação das ferramentas desenvolvidas. Com efeito, pretende-se que esta metodologia seja útil, não só para efeitos de licenciamento, mas também para a avaliação da qualidade de projectos a efectuar pelos seus autores e pelos seus clientes. Pretende-se, pois, que a utilização do método proposto resulte, de facto, num estímulo à qualidade dos projectos da especialidade.

Como se irá expor nos pontos seguintes, considera-se que a maior parte destes aspectos são convenientemente tratados nos regulamentos em vigor. Nestes casos, devem ser desenvolvidos formatos de representação e processos automáticos de conformidade compatíveis com os regulamentos existentes. Crê-se, porém, que para alguns requisitos, em particular os relacionados com a fiabilidade e a eficiência, devem ser desenvolvidos novos métodos de avaliação pelo que estes tópicos serão desenvolvidos em maior detalhe, ainda que as consequências da sua aplicação apenas em parte sejam aplicáveis para efeitos do licenciamento de obras privadas.

No que toca à fiabilidade do sistema público, considera-se que é importante desenvolver novos indicadores que permitam a avaliação deste parâmetro na óptica do cliente. Admite-se mesmo que este é um assunto que deve ser tido em conta, tanto ao nível da atribuição de licenças de construção, como ao nível do planeamento urbano.

3.2    Segurança de pessoas e bens

De acordo com as consultas efectuadas a entidades responsáveis pelo licenciamento de projectos de redes prediais de águas e esgotos, as questões relacionadas com a segurança de pessoas e bens são particularmente relevantes na fase de apreciação do projecto.

A aptidão para a aplicação de métodos automáticos de verificação de conformidade regulamentar de um conjunto de aspectos relacionados com a segurança de pessoas e bens justifica a sua inclusão na lista de aspectos de verificação obrigatória no âmbito do processe de licenciamento.

A segurança de pessoas está associada essencialmente à qualidade da água na rede. Uma vez que se está a avaliar o projecto de um sistema predial, não de um sistema público, a qualidade da água depende dos seguintes aspectos:

a.       Escolha de materiais adequados para tubagens e acessórios da rede;

b.      Correcta aplicação de disposições construtivas, por exemplo, no que toca à construção de depósitos de água.

A segurança de bens está relacionada com a possibilidade de ocorrência de roturas na rede. Os factores mais relevantes para a avaliação deste problema são os seguintes:

a.       Adopção de materiais adequados;

b.      Introdução de mecanismos que evitem a ocorrência de sobrepressões em caso de avaria na rede pública, nomeadamente válvulas redutoras de pressão à entrada da rede e sempre que se considere provável a ocorrência de pressões elevadas (constituem uma forma económica de reduzir o risco de roturas por sobrepressão).

Considera-se que todas estas situações estão devidamente salvaguardadas pelas disposições regulamentares em vigor. Assim, não se afigura necessário definir medidas complementares que permitam quantificar os riscos de rotura ou de contaminação das redes prediais.

3.3    Respeito pelo ambiente

As implicações dos projectos de sistemas prediais de distribuição água no ambiente são limitadas.

As eventuais contaminações dos efluentes como resultado da aplicação, na rede de distribuição, de materiais com características inadequadas são evitadas, como se referiu em 3.2, pelo respeito pelas disposições regulamentares.

Um impacto adicional, resultante de um consumo excessivo de água, só pode ser indirectamente associado a disposições de projecto – é, em primeiro lugar, uma questão relacionada com a utilização da rede. Com efeito, até um cliente com uma rede predial muito simples pode ser responsável por consumos elevados. Ainda assim, é possível verificar a instalação de dispositivos de utilização que permitam reduzir o consumo de água (Silva Afonso 2001).

A estrutura dos tarifários praticados pelas empresas responsáveis pela gestão das redes públicas desincentiva o consumo excessivo ao penalizar os escalões de consumo mais elevados. Embora esta solução possa produzir algumas situações de injustiça relativa, considera-se que é uma forma adequada de abordar esta questão.

Como será referido em 3.4.7, um consumo elevado de água pode também ter um impacto negativo considerável no funcionamento da rede pública.

3.4    Fiabilidade do sistema público

3.4.1       Conceito

Algumas opções tomadas pelos projectistas de redes prediais de águas ou saneamento podem afectar o bom funcionamento do sistema público. É, pois, natural que a entidade responsável pela manutenção do sistema público estabeleça um conjunto de verificações a efectuar no sentido de evitar a introdução de impactos nefastos ao bom funcionamento da rede. No limite, admite-se que a entidade licenciadora estabeleça um grau de fiabilidade mínimo a respeitar para cada novo cliente, podendo este ser responsável pelo desenvolvimento de condições que visem a melhoria da fiabilidade do serviço, em particular nos casos em que esta possa ser considerada insuficiente. Considera-se, pois, que o incremento da fiabilidade de um sistema público deverá ser uma responsabilidade partilhada pela entidade responsável pelo sistema e pelos seus clientes.

A fiabilidade de um sistema público de abastecimento de água pode ser definida pelo grau de confiança segundo o qual se pode garantir que os seus clientes são abastecidos em condições aceitáveis. Estas condições aceitáveis podem ser definidas a partir de parâmetros relacionados com a qualidade da água, pressões limite (máxima e mínima), etc. (Harberg 1997).

3.4.2       Critérios de avaliação

3.4.2.1      Critérios gerais

Não existe um indicador padrão para a fiabilidade de uma rede pública, embora possam ser considerados diferentes tipos de critérios para a medir (Harberg 1997):

a.       Volume de reserva

Mede a capacidade de conjuntos de componentes do sistema relativamente ao uso previsto. É frequente ter em conta, por exemplo, o volume total dos reservatórios ou a capacidade das estações de tratamento do sistema, comparando-os com consumos máximos diários. Um estudo de fiabilidade baseado apenas em volumes de reserva pode revelar-se insuficiente dado que estes indicadores não têm em consideração a ocorrência de falhas no serviço (em particular as suas frequência e duração) ou eventuais heterogeneidades locais que caracterizam a rede. Ainda assim, a pouca informação necessária ao cálculo dos volumes de reserva torna-os indicadores interessantes para uma avaliação rápida (ainda que algo optimista) da fiabilidade de um sistema.

b.      Redundância

Avalia a existência de elementos que assegurem o funcionamento de outros componentes da rede na eventualidade da ocorrência de uma falha nestes. A existência de elementos redundantes numa rede é um aspecto crucial para a minimização dos riscos associados a falhas, em particular a falhas de longa duração, embora não tenha, em geral, um impacto significativo na redução da probabilidade de falhas no abastecimento de curta duração. Com efeito, as falhas de curta duração estão frequentemente associadas a roturas de condutas ou a outras avarias cujo tempo de reparação não é, em regra, superior a algumas horas num sistema bem gerido. Perante falhas imprevisíveis de tão curta duração, a entidade responsável pela gestão do sistema só será motivada para proceder a alterações ao esquema habitual de abastecimento se, por exemplo:

i.            A falha afectar um grande número de clientes;

ii.            As alterações a produzir no sistema (nomeadamente a abertura e fecho de válvulas ao longo da rede ou a montagem de meios provisórios que visem o restabelecimento de condições de serviço aceitáveis) sejam muito simples;

iii.            O contrato de concessão previr multas por incumprimento (por exemplo, multas por cada dia em que se registar uma interrupção de abastecimento de duração superior a 6 horas).

c.       Probabilidade de ocorrência de abastecimento insuficiente

O abastecimento pode ser limitado devido à ocorrência de períodos de seca ou cheias, por infra-estruturas com uma capacidade insuficiente para garantir o serviço ou pela falha de componentes da rede. Em alguns casos, a ocorrência de falhas pode ser previsível, permitindo que a entidade responsável pela gestão do sistema e os seus clientes se adaptem a restrições específicas no consumo. Nas regiões em que se verifica habitualmente uma variação significativa e sazonal de população, os clientes podem esperar falhas no serviço, nomeadamente pressão insuficiente, a determinadas horas do dia. O carácter repetitivo destas falhas poderá motivar os clientes para a alteração dos seus padrões de consumo e a entidade responsável pelo sistema de abastecimento a prever alterações na infra-estrutura existente. A frequência, a magnitude e a duração da falha no abastecimento são aspectos relevantes, podendo produzir resultados que variam entre o imperceptível ou o incómodo tolerável para o cliente até situações em que o risco de dano severo para a actividade económica ou para a saúde pública passa a ser considerável.

As curvas que relacionam a probabilidade de ocorrência de uma falha com a sua magnitude são uma forma comum de representar a fiabilidade de um sistema, tendo em conta a probabilidade de ocorrência de abastecimento insuficiente (que pode ser medida como função de diferentes parâmetros, incluindo duração e natureza da falha) (ver Fig. 21).

Fig. 21 – Probabilidade de ocorrência de falha com magnitude especificada (exemplo)

d.      Probabilidade de ocorrência de interrupção de abastecimento

Embora se possa considerar uma interrupção como um exemplo extremo de abastecimento insuficiente, estes dois graus de falha de abastecimento são frequentemente analisados separadamente. Com efeito, não só as causas das falhas mais relevantes são distintas, mas também as consequências dos dois tipos de falha tendem também a ser significativamente diferentes. Embora as interrupções de abastecimento possam ser de curta duração, motivadas por falhas nos componentes do sistema, por cortes de electricidade, etc. (isto é causas idênticas às que foram apontadas para a ocorrência de abastecimento insuficiente), as interrupções de longa duração não são, regra geral, previsíveis e as suas consequências podem revelar-se dramáticas. As interrupções de longa duração podem surgir como resultado de catástrofes naturais (sismos, cheias particularmente severas, etc.) ou podem ser consequência de actividades humanas (focos de poluição, guerras, terrorismo, etc.). A extrema raridade deste tipo de eventos torna difícil uma análise probabilística de falha de abastecimento uma vez que, em geral, não há disponibilidade de dados relativos a ocorrências anteriores. Na ausência de dados, as únicas alternativas viáveis são:

i.            Admitir como cenário pessimista uma interrupção com uma duração máxima tolerável (tendo em conta riscos de saúde pública e de danos severos para a actividade económica), estimando ainda uma frequência máxima para o evento;

ii.            Usar formas de análise simplificadas, nomeadamente volumes de reserva e avaliação da redundância do sistema.

3.4.2.2      Percepção do cliente

A percepção do cliente é uma outra forma de avaliar, ainda que de forma qualitativa, a fiabilidade do sistema de abastecimento. Tipicamente, a opinião dos clientes é recolhida sob a forma de um inquérito e é depois sujeita a tratamento estatístico. Entre outras questões, os clientes são interrogados acerca da frequência das interrupções e da sua duração. Constata-se, porém, que este processo tende a ser pouco informativo. Os clientes não são, em geral, capazes de identificar eventos específicos ao longo do tempo pelo que tendem a não ter uma opinião concreta acerca da fiabilidade do sistema. Para além disso, constata-se que assuntos não directamente relacionados com o tema da fiabilidade tendem a ter um impacto significativo nas opiniões dos clientes inquiridos. Se o inquérito for realizado após um aumento das tarifas, por exemplo, a opinião dos clientes acerca da fiabilidade do sistema é significativamente afectada, revelando resultados negativos. As tentativas de correlacionar o resultado de inquéritos com outras medidas de fiabilidade de um sistema têm-se revelado, portanto, infrutíferas (Roberts, Davis 2003).

Um estudo efectuado pela empresa Norte Americana Memphis Light, Gas and Water (Roberts, Davis 2003), relacionado com as queixas apresentadas pelos seus clientes da rede eléctrica revela que um número reduzido de clientes reclama após uma interrupção isolada (em especial se esta ocorrer numa altura particularmente inconveniente) mas que as queixas aumentam com o aumento de frequência das interrupções. Constata-se, por exemplo, que a ocorrência de três interrupções de serviço num intervalo de seis meses resulta num número de reclamações duas vezes superior ao registado para o mesmo número de interrupções ao longo de um ano. O estudo conclui que a redução do número de clientes que sofrem mais de três interrupções ao longo de um ano terá um impacto favorável significativo na apreciação global da fiabilidade do sistema. Constata-se ainda que diferentes tipos de clientes tendem a revelar diferentes graus de sensibilidade relativamente a interrupções de serviço. Pessoas idosas e pessoas que trabalham em casa são, em geral, mais sensíveis a estas interrupções. Os habitantes de zonas rurais são tipicamente menos sensíveis às interrupções do que a população urbana. Não foram encontrados estudos similares aplicados a redes de distribuição de água.

3.4.2.3      Clientes afectados por interrupções múltiplas

O Instituto de Engenheiros Electrotécnicos e Electrónicos Norte Americano - Institute of Electrical and Electronic Engineers (IEEE) – instituiu em 1998 um índice que mede o número de clientes afectados por mais do que um determinado número de interrupções de serviço anuais. O índice faz parte da especificação IEEE 1366 de 2001. Esse índice, designado por Customers Experiencing Multiple Interruptions (CEMI), permite avaliar a fiabilidade do sistema na óptica de todo o espectro de clientes que serve em vez de os agrupar sob a forma de médias aritméticas. O número de clientes afectados por mais de cinco interrupções no intervalo de um ano, por exemplo, é quantificado no índice CEMI_5 (Warren 2002), também representado por CEMI-5. Naturalmente, o índice é função do número total de clientes da rede:

Em que,

-        CN(kn) representa o número total de clientes afectados por mais de n interrupções;

-        NTrepresenta o número total de clientes da rede;

-        k representa o número total de interrupções sofridas pelo cliente individual durante o período de análise.

Nas redes eléctricas, é usual dividir-se as interrupções em momentâneas e sustentadas conforme a sua duração for igual ou inferior a 59 segundos ou igual ou superior a 1 minuto, respectivamente. As interrupções de serviço aqui mencionadas referem-se a interrupções sustentadas. Considera-se que só estas são relevantes enquanto referência para redes de abastecimento de água.

Vários estados dos EUA avaliam actualmente a utilização deste índice, não só como medida de fiabilidade, mas também como critério de aplicação de multas a pagar pelo concessionário aos clientes afectados por um desempenho insuficiente do sistema de abastecimento (Warren 2002), (Matavalam 2004).

Crê-se que a aplicação de um índice similar às redes de abastecimento de água produzirá resultados úteis na medida em que se sabe que a distribuição de avarias ao longo de toda uma rede tende a ser muito heterogénea.

3.4.2.4      Outros indicadores aplicados a redes eléctricas

O índice CEMI não é ainda de utilização generalizada. Os índices de fiabilidade de redes eléctricas do IEEE mais comuns são os SAIFI (System Average Interruption Frequency Index), SAIDI (System Average Interruption Duration Index), CAIDI (Customer Average Interruption Duration Index) e ASAI (Average Service Availability Index) (Mansoor et al. 2004). Admite-se que estes indicadores possam servir de base a novas formas de contratos de fornecimento de electricidade baseados no desempenho. Segue-se uma breve descrição destes indicadores:

a.       SAIFI (System Average Interruption Frequency Index)

Em que,

-        Ni representa o número de clientes afectados pela interrupção de serviço i;

-        NTrepresenta o número total de clientes da rede.

O SAIFI representa, pois, o número de interrupções sofridas pelo cliente médio durante o período de análise (Sanabria 2005). Como é evidente, o conceito de cliente médio tende a ocultar as heterogeneidades características de qualquer rede logo, embora seja útil para retratar de uma forma genérica o desempenho de uma rede como um todo, o índice constitui uma informação de utilidade limitada para o decisor uma vez que não identifica locais de intervenção prioritários.

b.      SAIDI (System Average Interruption Duration Index)

Em que,

-        ri representa a duração da interrupção i;

-        As restantes variáveis têm o mesmo significado apresentado para o indicador SAIFI.

O indicador SAIDI representa a duração total das interrupções sofridas pelo cliente médio durante o período de análise. O índice apresenta claras semelhanças com o SAIFI, pelo que lhe são também aplicáveis as observações efectuadas para aquele indicador.

c.       CAIDI (Customer Average Interruption Duration Index)

O CAIDI representa o tempo aparente de reparação por cliente afectado (Sanabria 2005). Também este indicador não fornece informação acerca das heterogeneidades da rede, no que diz respeito à sua fiabilidade.

d.      ASAI (Average Service Availability Index)

Em que,

-        NHDS é o número de horas em que o serviço está disponível;

-        NHT é o número de horas total no intervalo de tempo considerado. Dado que este intervalo corresponde, usualmente, a um ano, adopta-se o valor de 8760 horas num ano regular e de 8784 horas num ano bissexto (Matavalam 2004).

Este indicador é frequente calculado de acordo com a seguinte expressão, mais compatível com os dados usados no cálculo dos restantes indicadores de fiabilidade apresentados:

O ASAI representa a fracção de tempo em que o cliente tem acesso ao serviço.

Constata-se que o exemplo das redes eléctricas é relevante na medida em que na sua gestão é empregado um conjunto de indicadores de fiabilidade comuns, bem definidos e sustentados por anos de utilização em redes distintas. Naturalmente, os requisitos de fiabilidade que se colocam às redes de abastecimento de água são distintos daqueles que se colocam às redes eléctricas, nomeadamente no que diz respeito a indicadores de qualidade. Com efeito, a água fornecida deve respeitar determinados critérios de qualidade (por exemplo pressões limite, características microbiológicas, aspecto, odor, sabor, etc.) que obviamente não têm correspondência com os requisitos colocados à electricidade, cujos principais indicadores de fiabilidade dizem respeito a interrupções de serviço e suas duração e frequência. Ainda assim, se se encarar a prestação de um serviço de abastecimento de água de qualidade insuficiente (de acordo com qualquer um dos parâmetros utilizados para aferir esta qualidade) como uma interrupção de um serviço em condições aceitáveis, os indicadores de fiabilidade referidos, usados para a rede eléctrica, serão susceptíveis de adopção para avaliar a fiabilidade de redes de abastecimento de água.

3.4.2.5      Indicadores do IWA

A International Water Association sugere uma lista de 158 indicadores de desempenho aplicáveis aos sistemas de abastecimento de água (Alegre 2000), (Duarte et al. 2004). Um conjunto destes indicadores é relevante sob o ponto de vista da análise de fiabilidade do sistema, permitindo medir a frequência e a duração das interrupções de serviço. As expressões indicadas no texto que se segue, bem com a designação das respectivas variáveis são citadas directamente da fonte.

a.       QS12 – Continuidade do abastecimento [%]

Em que,

-        H1 é a duração do período de referência [dia];

-        H2 é o tempo de pressurização do sistema [horas].

O indicador mede a quantidade de horas do ano em que o sistema está em pressão relativamente à duração, em horas, do período de referência. O indicador Q12 apresenta semelhanças com o indicador ASAI referido anteriormente, mas não é ponderado pelo número de clientes afectados pela interrupção de serviço. Segundo a bibliografia consultada, este indicador é relevante para sistemas com abastecimento intermitente, o que exclui a generalidade dos sistemas de abastecimento de água urbanos.

b.      QS13 – Interrupções de fornecimento [%]

Em que,

-        D35 representa as interrupções do fornecimento de água [habitante x hora];

-        F1 é a população abastecida [habitante];

-        H1 é a duração do período de referência [dia].

O cálculo deste indicador é efectuado de forma semelhante ao do ASAI apresentado anteriormente. Com efeito, pode ser visto como o seu complementar: o ASAI mede a continuidade do abastecimento enquanto o QS13 mede interrupções de serviço. É aplicável a sistemas de distribuição urbanos (sistemas com uma densidade de ramais superior a 20 por km de rede).

Segundo a bibliografia consultada, para muitas entidades gestoras, não há informação disponível para o cálculo deste indicador nem será possível recolhê-la num futuro próximo (Duarte et al. 2004) pelo que se propõe, em alternativa, o indicador QS14 para sistemas urbanos ou QS15 para sistemas rurais e sistemas de produção e adução. Com efeito, admite-se que a generalidade das entidades gestoras não tem registos operacionais que incluam informação acerca da duração das interrupções da rede e do número de clientes afectados por cada interrupção.

c.       QS14 – Interrupções por ramal [nº/1000 ramais/ano]

Em que,

-        C24 é o número de ramais na rede [nº];

-        D36 representa o número de interrupções do serviço [nº];

-        H1 é a duração do período de referência [dia].

Este indicador não exige a disponibilidade de uma base de dados operacional que contenha informação detalhada acerca das interrupções de serviço e suas durações. É suficiente que, para além da informação acerca do número de clientes da rede, se conheça o número de interrupções de serviço ao longo do período de referência. Este indicador, sendo útil para o estabelecimento de comparações externas (benchmarking), omite informação relevante para a tomada de decisões, nomeadamente a quantificação do impacto das interrupções e a sua distribuição ao longo da rede.

O indicador apresenta semelhanças com o SAIFI, embora este exija a contabilização do número de clientes afectados por cada interrupção.

d.      QS15 – Interrupções por ponto de entrega [nº/ponto de entrega/ano]

-        E9 representa o número de contadores de clientes distribuidores;

-        As restantes variáveis têm o significado já apresentado para o indicador anterior.

Este indicador é semelhante ao QS14, sendo indicado para sistemas de distribuição rurais e sistemas de produção e adução.

Os indicadores QS16 e QS17 são também indicadores de fiabilidade que medem restrições ao uso de água em alternativa a interrupções de serviço.

Constata-se que os indicadores do IWA apresentam claras semelhanças com alguns índices do IEEE, sendo que os primeiros foram definidos tendo em conta a limitação de dados disponíveis por parte da generalidade das entidades gestoras de sistemas de abastecimento de água. Com efeito, estes indicadores, embora permitam o estabelecimento de comparações externas entre empresas responsáveis pelo abastecimento de água, não permitem mais do que estabelecer uma medida da “fiabilidade média” do sistema. Como já se referiu, considera-se que, na óptica do gestor, um índice deverá fornecer informação que permita estabelecer áreas prioritárias de intervenção. Não deverão ser toleradas, por exemplo, situações em que o sistema apresenta uma “fiabilidade média” elevada apesar de se constatar a existência de zonas onde se registam interrupções de serviço regulares. Deverão ser adoptados indicadores que revelem a existência destas heterogeneidades para além dos indicadores que agrupam os clientes numa medida única. Conforme se referiu neste capítulo, a adopção de índices deste tipo é limitada pelas actuais dificuldades em recolher dados suficientes para os calcular. O indicador QS13 do IWA, por exemplo, exige a determinação do parâmetro D35 – interrupções do abastecimento de água [hab. x hora] – o que se tem revelado inviável. Actualmente, a generalidade das entidades gestoras não dispõe de dados operacionais com um grau de detalhe suficiente para descrever detalhadamente o desempenho das suas redes, tendo em conta as suas heterogeneidades.

Conclui-se assim que qualquer proposta de um índice que exija dados que ultrapassem a contabilização do número de interrupções anuais, para além de dados operacionais básicos como o número de clientes da rede, deve ser acompanhada por uma sugestão de recolha destes dados. Só desta forma poderá ser aferida a viabilidade de tais indicadores.

3.4.2.6      Perfil de fiabilidade

Embora os diagramas do tipo indicado na Fig. 21 sejam formas elegantes de ilustrar a fiabilidade de um sistema de abastecimento, representando-a sob a forma de uma curva contínua, na realidade, estas curvas resultam da análise de um número finito de cenários, correspondentes a falhas de diferentes tipos. Assim, os diagramas poderiam assumir o aspecto de um histograma. De acordo com o referido nos pontos anteriores, a prática aconselha que haja alguma separação entre, pelo menos, as análises de fiabilidade para eventos recorrentes e para eventos extremos. Com efeito, é concebível que, por exemplo, ocorram os seguintes cenários distintos:

a.       A entidade responsável pela gestão de um sistema de abastecimento recente poderá mostrar-se particularmente atenta a questões relacionadas com a detecção de roturas e a sua rápida reparação embora saiba que o abastecimento depende de uma captação ou de uma estação de tratamento únicas. Numa situação deste tipo, os clientes sofrerão, provavelmente, poucas interrupções de serviço durante um ano e estas serão de curta duração, mas estarão mais vulneráveis a interrupções de muito longa duração que, embora muito improváveis, poderão ter consequências dramáticas.

b.      Um antigo sistema de abastecimento que terá crescido lentamente ao longo de décadas, acrescentando novas captações à medida que se expandia, poderá sofrer roturas frequentes como resultado de uma manutenção insuficiente dos componentes da rede e de uma gestão pouco cuidada de operações. Este sistema registará, provavelmente, um maior número de interrupções de serviço contudo, em consequência das captações redundantes que contém (e admitindo que estas apresentam alguma dispersão geográfica), poderá garantir aos seus clientes uma maior segurança de abastecimento perante eventos extremos.

Os exemplos indicados pretendem ilustrar não só a possibilidade de um mesmo sistema apresentar níveis de fiabilidade diversos perante eventos recorrentes ou eventos extremos, mas também a distinção entre a natureza dos eventos que correspondem a magnitudes de falha diferentes. Se os eventos recorrentes podem ser encarados como relativamente previsíveis em função do volume de dados que é possível recolher acerca do funcionamento de um sistema de abastecimento, tornando o recurso a uma análise probabilística do funcionamento da rede particularmente apetecível, já os eventos extremos são difíceis de antecipar.

3.4.3       Fiabilidade: Custos

As considerações efectuadas acerca das causas das falhas de um sistema de abastecimento e as correspondentes magnitudes, permitem antecipar uma relação entre custos de construção, operação e manutenção e correspondentes magnitudes de falha a evitar do tipo ilustrado na Fig. 22.

Fig. 22 – Relação entre custos de construção, operação e manutenção e magnitude de falha

A Fig. 22 divide os custos em três grupos principais:

a.       C1, que corresponde ao custo de investimento mínimo, sem despesas relacionadas com o aumento de fiabilidade do sistema de abastecimento. Este custo inclui o custo de construção do sistema sem componentes redundantes (nomeadamente, captações alternativas, estações de tratamento alternativas, malhas na rede de distribuição, etc.) e com uma manutenção mínima.

b.      C2, que inclui os custos relacionados com a mitigação de riscos associados a eventos extremos. Dados os efeitos catastróficos e a extrema improbabilidade de ocorrência destes eventos, considera-se que é prudente garantir a redundância de todos os componentes do sistema de abastecimento, em particular de captações e estações de tratamento. Uma forma eficiente de assegurar esta redundância consiste na interligação de sistemas de abastecimento vizinhos. Estes investimentos são considerados prioritários para o bom funcionamento da rede, tendo em conta os riscos e os custos associados.

c.       C3, composto pelos custos relacionados com a mitigação de riscos associados a eventos recorrentes. Os custos incluem a construção de malhas na rede de distribuição, a instalação de geradores nas estações elevatórias, o reforço de verbas a afectar às operações de reparação da rede, tornando-as mais céleres (por exemplo, garantindo a existência de piquetes de reparação permanentes), etc. Naturalmente, é impossível garantir uma fiabilidade de 100% para a rede, pelo que a curva correspondente a estes custos apresenta uma assímptota vertical .

3.4.4       Aplicabilidade dos modelos de avaliação da fiabilidade de um sistema

A avaliação da fiabilidade de um sistema é efectuada através da aplicação de uma combinação dos critérios de avaliação referidos em 3.4.2. A avaliação probabilística da fiabilidade é a forma mais racional de abordar o problema, contudo, é substancialmente mais exigente sob o ponto de vista da informação necessária ao cálculo de estimativas. Com efeito, os dados necessários podem revelar-se insuficientes ou inexistentes pelo que a avaliação probabilística deve ser complementada por outros critérios, isto é, pela consideração de volumes de reserva e da existência de componentes redundantes no sistema.

A quantidade de parâmetros que influem na avaliação da fiabilidade de um sistema de abastecimento é de tal forma significativa que importa proceder a um conjunto de simplificações que tornem viável a resolução do problema.

Encontra-se na bibliografia uma discussão da viabilidade da introdução destas simplificações (Harberg 1997), apresentando-se aqui uma síntese das conclusões daquele estudo:

a.       Interrupções de curta duração (eventos recorrentes): Nestes cenários, devem ser consideradas apenas causas recorrentes, por exemplo cortes de energia, roturas e falhas de componentes da rede (a extrema improbabilidade de ocorrência de eventos que causem uma interrupção prolongada do abastecimento de água permite a análise isolada da rede sob o efeito de causas recorrentes para a avaliação da fiabilidade da rede em situações normais de funcionamento). A ocorrência de consumos anormalmente elevados, causados por fogos ou por tempo muito seco ou quente deve ser considerada como um evento recorrente.

b.      Interrupções de longa duração (eventos extremos): Nestes cenários, devem ser consideradas apenas causas extremas, incluindo catástrofes naturais, guerras, terrorismo, etc. (as interrupções de curta duração são consideradas toleráveis perante estes cenários).

c.       Redundância: Os sistemas que apresentem componentes redundantes, em particular os que apresentam uma rede de distribuição que contenha malhas, reduzem significativamente o impacto das causas extremas referidas.

d.      Distribuição: Os critérios de dimensionamento habitualmente empregues são considerados adequados para as redes de distribuição. O autor do estudo referido considera que a análise de redes de distribuição emalhadas dispensa uma avaliação adicional com base em critérios probabilísticos.

Em síntese, o autor do estudo referido advoga que a avaliação da fiabilidade de um sistema com base em critérios probabilísticos deve resumir-se às duas situações seguintes:

a.       Interrupções de curta duração provocadas por falhas no sistema de adução (eventos recorrentes);

b.      Interrupções de longa duração provocadas por falhas no sistema de adução (eventos extremos).

3.4.5       Modelo probabilístico

3.4.5.1      Apresentação

Foi construído um modelo probabilístico com o fim de indicar, para cada cliente, um nível de fiabilidade como função das características do sistema público (incluindo rede de distribuição, rede de adução, tratamento e captação) e da rede predial.

Salienta-se que o modelo procura avaliar a fiabilidade do abastecimento na óptica do cliente individual, levando em conta as características de todos os componentes da rede pública que garantem o abastecimento, mas também as de componentes da rede predial do cliente. Esta análise de fiabilidade levada a cabo a partir da perspectiva do cliente distingue a abordagem proposta de outros indicadores estudados, nomeadamente o Índice de Segurança de Abastecimento (Security of Supply Index - SSI) proposto pelo Office of Water Services (OFWAT 2003). Este índice procura avaliar a fiabilidade do sistema de abastecimento visto como um todo, tendo em conta a proporção de clientes considerados vulneráveis perante situações de abastecimento insuficiente, levando em conta a incerteza relacionada com a evolução dos padrões de consumo locais ao longo do tempo. O índice não tem em conta as características dos componentes individuais da rede, sendo calculado, para cada “zona da rede”[6], como uma função do volume de água disponível para o uso, o consumo previsto (usualmente o consumo médio diário de um ano seco) e a reserva de capacidade planeada para cada zona do sistema de abastecimento.

O SSI da OFWAT não avalia a fiabilidade do sistema tendo em conta o grau de redundância dos seus componentes. Isto significa que um sistema de abastecimento que dependa de uma captação única, capaz de fornecer um volume de água muito superior ao que será necessário segundo as previsões da entidade responsável pela gestão da rede, obterá uma classificação elevada enquanto um sistema que disponha de duas origens, embora com capacidade total um pouco inferior, deverá ser pior classificado. De acordo com o referido anteriormente, um sistema que dependa do bom funcionamento de componentes individuais tenderá a ser menos fiável, neste caso, face a eventos extremos em particular. Este exemplo pretende ilustrar a afirmação apresentada em 3.4.1 segundo a qual uma análise de fiabilidade baseada apenas em volumes de reserva se pode revelar insuficiente.

Finalmente, o SSI da OFWAT, ao limitar o seu âmbito de análise a “zonas da rede” (esta é a unidade de análise de menor dimensão), tende a minimizar a importância de vulnerabilidades geograficamente limitadas mas persistentes na rede. Embora os eventuais défices de capacidade da rede face às necessidades previsíveis quantificadas pela entidade responsável pela sua gestão sejam majoradas no cálculo do índice, a existência de “sub-zonas” com capacidade excessiva anulará o impacto das deficiências verificadas na rede. Assim, a existência de um número reduzido de clientes sujeitos a interrupções de abastecimento frequentes ou particularmente vulnerável a interrupções de abastecimento de longa duração, não afectará significativamente o desempenho da rede traduzido por este índice. Naturalmente, não se pode considerar aceitável que subsistam na rede clientes sujeitos a interrupções de serviço regulares e frequentes, pelo que se torna necessário desenvolver medidas que permitam identificar os pontos críticos da rede e que a penalizem, quanto à avaliação da sua fiabilidade. A divulgação pública destes índices de fiabilidade detalhados, bem como a adopção de medidas que permitam que um cliente sujeito a um serviço deficiente seja compensado, sob a forma de multas pagas pela entidade responsável pelo sistema de abastecimento, poderão funcionar como mecanismos poderosos para incentivar ao investimento no incremento da fiabilidade das redes.

Fig. 23 – Fiabilidade do abastecimento na perspectiva do cliente

Pretende-se avaliar o impacto de decisões de projecto (no âmbito do projecto de rede de abastecimento de águas) no funcionamento do sistema público, por um lado e na fiabilidade do abastecimento na óptica do cliente, por outro. Naturalmente, se forem identificadas disposições de projecto que resultem num acréscimo de fiabilidade considerável e/ou que tenham um impacto positivo no funcionamento do sistema público e que, simultaneamente, apresentem custos considerados aceitáveis para o cliente, a entidade gestora do sistema poderá incentivar a sua implementação ou mesmo torná-las necessárias para a obtenção de licença de construção.

O modelo probabilístico desenvolvido inclui um conjunto de simplificações introduzidas com o fim de viabilizar a sua utilização de uma forma sistemática para uma grande quantidade de clientes.

Procura-se descrever nos pontos seguintes as simplificações introduzidas no modelo, justificando-se a sua validade.

3.4.5.2      Rede de distribuição

Importa avaliar a probabilidade de ocorrência de uma interrupção de serviço causada por uma avaria na rede de distribuição e o impacto associado a este evento na óptica do cliente.

Entre as avarias na rede de distribuição, a mais importante é claramente a ocorrência de roturas nas condutas. Este é o único tipo de avaria considerado explicitamente na bibliografia consultada (Harberg 1997). O modelo deve considerar os mecanismos de falha mais relevantes para as condutas, a frequência com que as avarias ocorrem (em função das características das condutas) e o tempo de reparação esperado para cada caso estudado.

Representa-se na Tabela 4 um conjunto de factores responsáveis por falhas em condutas de abastecimento de água (Røstum 2000). As variáveis identificadas são agrupadas em quatro categorias: estruturais ou físicas, externas ou ambientais, internas ou hidráulicas e dados de manutenção. O autor deste estudo atribui importâncias distintas a cada uma das variáveis, admitindo mesmo que a relação entre algumas das variáveis e a probabilidade de ocorrência de roturas é complexa. A idade das condutas, por exemplo, será um indicador desadequado para prever a ocorrência de roturas. Considera-se, contudo, que mesmo após a redução do número de variáveis a um conjunto menor classificadas como “causas com um maior impacto na ocorrência de roturas em condutas”, a quantidade e a natureza das variáveis inviabiliza um estudo do tipo pretendido. Com efeito, uma parte significativa das variáveis identificadas pelo autor citado (por exemplo corrosão, condições do solo, comprimentos de troços individuais de condutas, etc.) não é, em geral, conhecida a não ser por acesso directo à conduta. A consideração deste tipo de variáveis poderá ser interessante para avaliar a viabilidade de substituir uma conduta acessível antes da ocorrência de uma rotura, por exemplo. Frequentemente, muitas das outras variáveis são igualmente desconhecidas devido a registos insuficientes (dados de manutenção, por exemplo).

Tabela 4 – Factores que influenciam a deterioração estrutural de condutas para o abastecimento de água (Røstum 2000) (traduzido)

Variáveis estruturais

Variáveis externas/ambientais

Variáveis internas

Dados de manutenção

Localização da conduta

Tipo de solo

Velocidade média de escoamento

Data de falha

Diâmetro

Carga

Pressão

Data de reparação

Comprimento

Nível freático

Qualidade da água

Localização da falha

Ano de construção

Fluxo de corrente directa

Choque hidráulico

Tipo de falha

Material da conduta

Taxa de fugas

Corrosão interior

Historial de falhas

Tipo de junta

Presença de outras infraestruturas

Revestimento interior

Utilização de sal para descongelar estradas

Revestimento exterior

Temperatura

Classe de pressão

Corrosão exterior

Espessura da parede da conduta

Profundidade da conduta

Condições do assentamento

As conclusões de outros estudos (Boxall 2007), (O’Day 1986) apontam para um número mais reduzido de variáveis, mais consentâneas com o objectivo deste estudo.

Apresenta-se em seguida um conjunto de conclusões da pesquisa bibliográfica efectuada consideradas mais relevantes para a definição do modelo de análise a desenvolver:

a.       Todos os autores atrás referidos concordam que a idade de uma conduta é um mau indicador de falha. Esta conclusão é partilhada com estudos recentes, considerando condutas em diferentes tipos de materiais (Hurley 2007).

b.      Concordam ainda que a taxa de roturas aumenta exponencialmente à medida que o diâmetro das condutas decresce como resultado de um decréscimo da resistência das condutas de menor secção.

c.       Concordam ainda que as condutas em ferro fundido cinzento apresentam um número de roturas superior ao verificado em condutas de outros materiais. O ferro fundido dúctil, pelo contrário, é o material ao qual corresponte a menor taxa de roturas (Hurley 2007).

d.      Apenas um dos estudos consultados (Boxall 2007) não detecta qualquer relação relevante entre dados geotécnicos e a taxa de roturas.

e.       A fiabilidade de uma conduta pode ser fortemente influenciada pela qualidade da mão-de-obra empregue na sua montagem, em particular no caso das condutas em plástico (Hurley 2007). Este factor pode ser responsável por algumas irregularidades detectadas nos resultados observados.

A análise bibliográfica realizada e a avaliação das características particulares da análise à rede que se pretende efectuar sugerem que as seguintes variáveis sejam consideradas e relacionadas com a taxa de roturas:

a.       Diâmetros das condutas;

b.      Comprimento total das condutas;

c.       Material das condutas.

Os efeitos dos outros factores atrás referidos, que influenciam a ocorrência de roturas, não deverão ser individualizados dada a dificuldade em produzir informação coerente a partir dos dados recolhidos.

Os estudos referidos neste sub capítulo, entre outros, contêm dados suficientes para preparar uma primeira estimativa da probabilidade de ocorrência de roturas em condutas com diferentes características, por ano e por quilómetro de comprimento. Ainda assim, de acordo com o referido anteriormente, constata-se que a fiabilidade de uma conduta pode ser fortemente influenciada pela qualidade da mão-de-obra empregue na sua montagem. A importância desta variável dificulta a importação directa, por parte das empresas responsáveis pela gestão dos sistemas de abastecimento, de dados recolhidos no exterior.

Considera-se, portanto, que os dados disponibilizados por estas e por outras publicações sejam usados apenas para a construção de uma primeira estimativa, devendo ser dada preferência à informação recolhida por cada empresa. A qualidade da mão-de-obra nos trabalhos de uma mesma empresa pode ser comparada mais facilmente, não só em função da quantidade de dados que lhe é possível recolher, mas também devido à possibilidade de adoptar critérios homogéneos de aceitação de trabalhos. Por outro lado, cada empresa depende de um número relativamente limitado de fornecedores, o que reduz a variação esperada para a qualidade da mão-de-obra.

Devem ser também considerados as durações previstas para os trabalhos de reparação das condutas (ver 3.4.6.3.5).

3.4.5.3      Outros componentes da rede

Para além das condutas da rede de distribuição, outros componentes podem ter impacto na fiabilidade da rede pública, nomeadamente:

a.       Captações;

b.      Tratamento;

c.       Reservatórios;

d.      Bombas;

e.       Válvulas.

A escassez de informação encontrada na bibliografia a respeito da fiabilidade destes componentes aconselha a que, a curto prazo, o desenvolvimento de perfis de fiabilidade para cada um deles se realize a nível local.

Admite-se que esta escassez de informação condicione o desenvolvimento de modelos de fiabilidade probabilísticos, pelo menos no imediato.

3.4.5.4      Modelação

3.4.5.4.1            Descrição geral

Pretende-se modelar o funcionamento da rede de uma forma simplificada, de modo a que seja viável a verificação sucessiva da fiabilidade do abastecimento a um grande número de clientes. No limite, deverá ser possível verificar a fiabilidade para todos os clientes individuais de um sistema.

Este objectivo torna pouco interessante a utilização de métodos de simulação do tipo Monte Carlo, por exemplo. Este tipo de métodos é particularmente interessante para a análise de redes de abastecimento complexas, com uma quantidade considerável de elementos redundantes (nomeadamente malhas, múltiplas captações e/ou estações de tratamento alternativas) e/ou sujeitas à acção de um grande número de variáveis (incluindo padrões de consumo variáveis, caudais de combate a incêndio originados em diversos pontos da rede, etc.). O esforço de processamento exigido por um modelo deste tipo seria considerável e o número de iterações necessárias a uma adequada caracterização dos eventos extremos, cujo intervalo de recorrência é normalmente muito elevado (eventualmente superior à centena de anos, em alguns casos), seria significativo.

O método adoptado contorna estas dificuldades estudando de forma isolada todos os percursos hidráulicos possíveis entre as captações definidas e o nó correspondente ao cliente cuja fiabilidade de abastecimento se pretende avaliar. Os percursos são depois combinados de forma a avaliar a fiabilidade da porção do sistema que une os pontos extremos considerados.

Em síntese, o algoritmo a aplicar à avaliação da fiabilidade num dado cenário é composto pelas quatro etapas ilustradas na Fig. 24.

O algoritmo deve ser aplicado a cenários distintos, correspondentes a diferentes magnitudes de falha, de forma a obter um perfil de fiabilidade, de acordo com o descrito neste capítulo.

Fig. 24 – Algoritmo de quatro etapas: (a) Determinação de todos os percursos que unem os pontos início e fim, (b) Eliminação de percursos inviáveis do ponto de vista do seu funcionamento hidráulico, (c) Avaliação da fiabilidade de cada percurso individual, (d) Avaliação da fiabilidade da combinação de percursos (Poças Martins, Poças Martins 2007)

3.4.5.4.2            Determinação de todos os percursos que unem os pontos início e fim

A listagem de todos os caminhos possíveis entre dois pontos de uma rede é efectuada com recurso a um algoritmo que se crê ser original, representado nas Fig. 25 e Fig. 26. O algoritmo é do tipo BFS (acrónimo da designação anglo-saxónica Breadth-First Search (Black 2007)). Neste tipo de algoritmo de pesquisa, os percursos possíveis entre dois nós distintos são identificados seguindo um processo iterativo. São verificados todos os nós vizinhos do ponto de partida (frequentemente apelidado de source, recorrendo à designação habitual na bibliografia em língua inglesa), depois todos os vizinhos destes e assim sucessivamente até ser encontrado o ponto de chegada (ou sink).

No algoritmo desenvolvido, a pesquisa continua para além do primeiro percurso encontrado entre os pontos de partida e chegada, parando apenas quando todos os percursos com origem no ponto de partida tenham sido esgotados, isto é, quando tenham atingido o ponto de chegada dado ou quando se verifique que o percurso não conduz ao ponto pretendido.

Note-se que no algoritmo proposto, a rede é encarada como um simples grafo. São ignorados os aspectos que influenciam o seu funcionamento hidráulico, nomeadamente cotas de pontos ou perdas de carga ao longo de condutas. Esses aspectos serão considerados adiante.

Fig. 25 - Representação esquemática de um algoritmo para a definição de todos os caminhos possíveis entre dois pontos de um grafo (Função Trails).

Por cada novo nível adicionado à rede gerada pelo algoritmo representado na Fig. 25, é efectuado um conjunto de verificações de acordo com o esquema apresentado na Fig. 26.

Fig. 26 - Subrotina “Novo Nível” correspondente a algoritmo representado na Fig. 25

Sublinhe-se que a rotina representada pode tornar-se muito exigente em termos de processamento no caso de redes com muitas malhas. No limite, a rede pode corresponder a um grafo completo (ver Fig. 35). Neste caso, todos os pares de pontos da rede estariam ligados por uma conduta, num total de na condutas:

O número total de percursos possíveis entre dois pontos distintos da rede, np, será dado pela seguinte expressão:

Neste caso, a eficiência do algoritmo será de . Este valor é muito elevado, dificultando a aplicação do algoritmo para grafos completos, mesmo com um número relativamente reduzido de pontos. Note-se, contudo, que este é um valor extremo, apresentando as redes reais um número de malhas muito reduzido em comparação com um grafo completo.

A expressão , válida para grafos completos, pode ser justificada da forma seguinte:

Pretende-se contabilizar o número de percursos existentes entre dois nós A (partida) e B (chegada) da rede dada. Como a pesquisa é efectuada usando um algoritmo do tipo Breadth-First Search, a rede será percorrida a partir da análise sucessiva de todos os nós vizinhos de um nó dado, começando por A. O conjunto de percursos possíveis pode ser representado sob a forma de uma árvore. Num dado percurso, nenhum nó pode ser visitado mais de uma vez. Um percurso é considerado completo se terminar no nó B. Verifica-se assim as seguintes condições:

a.       Em cada novo nível i da árvore, são representados ci percursos completos e di percursos incompletos.

b.      O número de percursos incompletos abertos em cada novo nível i é função do número n de pontos do grafo e de i.

c.       Cada ponto novo representado na árvore, correspondente a um percurso incompleto, produz um percurso completo no nível seguinte, isto é:

Nesta expressão, d_0=1 e c_0=0.

Assim o número total de percursos possíveis entre dois pontos distintos da rede, np, pode ser calculado da seguinte forma:

Apresenta-se na Fig. 27, a título de exemplo, um grafo completo correspondente a um conjunto de quatro nós designados por A, B, C e D. Pretende-se estudar todos os percursos entre A e B.

Fig. 27 – Grafo completo com 4 nós e árvore correspondente aos percursos possíveis entre A e B

Refere-se que a aplicação do algoritmo proposto a redes reais (nomeadamente à rede de distribuição da cidade do Porto), conduz a tempos de cálculo na ordem dos poucos segundos (dependendo, naturalmente, dos nós início e fim escolhidos) pelo que se considera que o algoritmo é adequado à dimensão dos problemas reais admissíveis.

3.4.5.4.3            Eliminação de percursos inviáveis do ponto de vista do seu funcionamento hidráulico

A verificação do funcionamento hidráulico de um percurso pode ser efectuada de duas formas distintas:

a.       Validação simplificada: O percurso é dividido em troços nos nós que correspondem a reservatórios. O percurso é considerado válido se todos os seus troços o forem. Cada troço é considerado válido se ocorrer pelo menos uma das seguintes condições:

i.            As cotas de todos os pontos do troço são inferiores à cota piezométrica do seu ponto inicial;

ii.            O troço contém uma bomba.

Este tipo de validação pode ser efectuado directamente sobre a base de dados gerada pela aplicação desenvolvida, o que permite um cálculo mais expedito. Naturalmente, não se trata de uma verificação exaustiva da validade do percurso, podendo erradamente ser considerado válido um percurso que, por exemplo, apresente alguma das seguintes características:

i.            Contenha uma válvula de retorno que impeça o percurso da água no sentido pretendido;

ii.            Contenha uma bomba com uma altura de elevação insuficiente;

iii.            Seja capaz de fornecer algum caudal, embora inferior ao exigido (frequentemente assume-se o caudal médio diário correspondente ao dia de maior consumo). Isto não corresponde necessariamente a um percurso não válido, mas apenas a uma restrição imposta ao consumo.

b.      Validação com recurso a um programa externo de cálculo hidráulico: O algoritmo proposto permite exportar os dados relativos a um percurso individual sob a forma de um ficheiro de texto que pode ser lido pelo EPANET. Este processo, embora permita atender a uma maior variedade de condicionantes do que o referido no método referido no ponto anterior, apresenta alguns inconvenientes que importa considerar:

i.            Exige um esforço de processamento considerável pelo que se pode tornar inviável na análise de redes de grande dimensão.

ii.            Alguns percursos podem ser erradamente considerados como inválidos em virtude de eventuais regras definidas no EPANET que podem não ser aplicáveis numa análise a um percurso individual (por exemplo, sentido de escoamento predeterminado). Este inconveniente pode ser contornado se forem simplesmente ignoradas todas as regras impostas ao modelo, mas este procedimento poderá igualmente produzir consequências indesejadas.

iii.            A consideração de um percurso isolado numa rede tende a ignorar consumos associados a nós não pertencentes ao percurso, o que conduz a uma subavaliação dos caudais escoados. Esta subavaliação pode ter consequências indesejadas na análise uma vez que o percurso pode não ser capaz de fornecer o caudal total que seria considerado caso fossem contabilizados os consumos correspondentes a nós exteriores ao percurso, isto é, podem ser ignoradas situações de limitações de consumos.

Considera-se preferível, na generalidade dos casos, o primeiro método de análise, embora se admita que pode conduzir a avaliações ligeiramente optimistas. O recurso a um programa de cálculo externo deve ser limitado a redes simples, onde o impacto dos inconvenientes descritos se torna menos significativo.

3.4.5.4.4            Avaliação da fiabilidade de percursos

A avaliação de cada percurso individual é efectuada tendo em conta a fiabilidade de cada um dos seus componentes (aplicando a expressão ). A fiabilidade dos componentes da rede deverá ser estimada de acordo com o referido nos pontos anteriores.

A avaliação da fiabilidade da combinação de percursos deve ser efectuada da forma descrita em seguida:

Uma vez decomposto em percursos individuais entre os pontos extremos considerados, pode afirmar-se que o sistema é bem sucedido se algum destes percursos o for. Assim, basta calcular a fiabilidade de cada percurso, sabendo que fiabilidade do sistema será igual à da união dos seus n percursos:

Onde Rs representa a fiabilidade do sistema e P(Pi) a probabilidade de sucesso do percurso i.

Como os percursos são sucessões de componentes colocados em série, a probabilidade de sucesso do percurso i, P(Pi), é dada pela probabilidade conjunta de sucesso dos seus m componentes (C_1, …,Cm):

Esta forma de avaliar a fiabilidade de sistemas complexos é designada de método path-tracing.

Fig. 28 – Rede simples composta por 4 troços A a D

A rede representada na Fig. 28 admite dois percursos possíveis entre os pontos Início e Fim. Note-se que apenas são considerados os percursos que não contêm ciclos (no sentido usualmente atribuído a esta expressão na teoria dos grafos), isto é, aqueles em que nenhum dos pontos seja visitado mais de uma vez durante o percurso. Os dois percursos serão compostos pelos troços ABD (P_1) e ACD (P_2), respectivamente. A fiabilidade do sistema será dada pela seguinte expressão:

Onde,

A fiabilidade do sistema representado na Fig. 28 será calculada pela expressão :

RA a RD são as fiabilidades dos componentes A a D do sistema s.

A expressão , para além de indicar a fiabilidade do sistema entre os pontos extremos definidos, permite conhecer os componentes críticos do sistema, isto é, aqueles que fazem parte de todos os percursos entre os pontos extremos. Neste caso, os componentes A e D são críticos uma vez que os termos RA e RD fazem parte de todas as parcelas da expressão. Ao indicar os componentes críticos do sistema, este método permite avaliar o seu grau de redundância que, de acordo com o referido em 3.4.1, é também um critério de avaliação da fiabilidade do sistema.

3.4.5.4.5            Obtenção de um perfil de fiabilidade

O perfil de fiabilidade resulta da aplicação sucessiva do modelo perante cenários distintos, correspondentes a diferentes magnitudes de falha. Devem ser considerados, no mínimo, dois cenários correspondentes a eventos rotineiros e a eventos extremos, embora seja possível avaliar cenários adicionais.

A cada cenário corresponde um conjunto de assumpções simplificadoras, de acordo com o descrito neste ponto. Refere-se ainda que os limites de cada cenário, definidos de acordo com tempos de interrupção concretos, foram estabelecidos tendo em conta uma avaliação subjectiva do impacto destas interrupções na actividade da povoação afectada. Admite-se, pois, que estes limites sejam sujeitos a uma análise crítica, embora se considere que a caracterização dos cenários correspondentes, bem como das suas causas típicas e simplificações assumidas para efeitos de modelação, permanecerão válidas perante pequenas alterações dos valores limite.

a.       Magnitude: 0

Caracterização: Limitação ou interrupção de serviço de duração muito pequena.

Causas típicas:

i.            Rotura de condutas pertencentes à rede de distribuição

ii.            Cortes eléctricos que interrompem o funcionamento de estações elevatórias

iii.            etc.

Simplificações:

i.            Apenas são consideradas as falhas rotineiras.

ii.            Admite-se que todas as falhas rotineiras podem ser resolvidas num prazo inferior de 6 horas, quer pela acção de equipas de trabalho da entidade responsável pela gestão do sistema de abastecimento (por exemplo, pela existência de piquetes para a reparação de avarias, 24 horas por dia), quer pela existência de meios redundantes (por exemplo, geradores junto a estações elevatórias), quer pela existência e mobilização de planos de emergência (isto é, manobras que permitem modificar o funcionamento da rede).

Estas simplificações permitem ignorar as potenciais falhas a montante do reservatório que serve o cliente (ou dos reservatórios que o servem) cuja fiabilidade de serviço se pretende avaliar, atribuindo-se a todos esses componentes uma fiabilidade de 100% neste cenário.

Admite-se, pois, que o volume de reserva mínimo num reservatório é suficiente para abastecer os respectivos clientes durante o tempo suficiente para levar a cabo as operações referidas anteriormente, permitindo o rápido restabelecimento do abastecimento ao reservatório em caso de avaria.

Observações:

i.            A fiabilidade de uma rede perante falhas de magnitude 0 será fortemente afectada pelo respectivo registo de roturas e pelo tempo estimado para a reparação de avarias.

ii.            As simplificações assumidas neste cenário permitem afirmar que um cliente abastecido a partir de um reservatório predial de dimensão normal (suficiente para garantir o abastecimento durante algumas horas) será imune a falhas de magnitude 0, isto é, apresentará uma fiabilidade de aproximadamente 100% face a avarias rotineiras.

b.      Magnitude: N-1

Caracterização: Interrupção de abastecimento de longa duração (superior a 1 semana).

Causas típicas:

Destruição de partes significativas da rede devido a:

i.            Terrorismo;

ii.            Guerras;

iii.            Catástrofes naturais (secas prolongadas, cheias, sismos, incêndios, etc.);

iv.            Poluição extrema (em particular, poluição nuclear).

A natureza das causas exige a descontaminação das origens de água ou mesmo a construção ou reconstrução de uma parte substancial da rede. As interrupções daí decorrentes são consideradas demasiado extensas para manter a actividade da povoação afectada, mesmo com o apoio de abastecimentos de emergência. Uma ocorrência desta magnitude aconteceu, por exemplo, após o furacão Katrina (Copeland 2005).

Simplificações:

i.            A duração da interrupção do abastecimento é de uma ordem de grandeza manifestamente superior ao tempo previsto para a resolução de eventuais avarias rotineiras (devidas a roturas, cortes eléctricos, etc.) que, de qualquer forma, teriam sempre um impacto reduzido perante as consequências dramáticas do evento responsável pela interrupção de longa duração.

Estas simplificações permitem limitar a análise efectuada a eventos extremos, ignorando os eventos rotineiros referidos.

Esta análise será necessariamente limitada pela indisponibilidade de dados (por exemplo, “Qual é a probabilidade de ocorrência de uma guerra que afecte as infraestruturas urbanas nacionais?”; “Qual é a probabilidade de ocorrência de um desastre nuclear que inviabilize uma captação por um período extenso?”). Com efeito, a escassez de dados que permitam quantificar a probabilidade de ocorrência de eventos extremos, associada a um desconhecimento do respectivo modelo de distribuição (não há dados suficientes para sugerir a adopção de uma distribuição normal, por exemplo), aconselham a uma abordagem distinta daquela que foi aplicada aos eventos rotineiros. A tomada de decisões num ambiente caracterizado pela incerteza, em particular quando se considera possível a ocorrência de eventos de elevada magnitude, deve ser levada a cabo focando preferencialmente as consequências dos eventos (que podem ser determinadas) em detrimento das respectivas probabilidades de ocorrência (que em geral não podem ser estimadas de forma satisfatória) (Taleb 2007).

Neste cenário, a aplicação de critérios de fiabilidade relacionados com a redundância, não com a probabilidade de ocorrência, são da maior importância dada a dificuldade em quantificar o risco associado a eventos extremos. Com efeito, admite-se que uma regra de projecto como a que se segue será a consequência previsível de uma eventual análise do risco associado a interrupções de abastecimento de longa duração que envolvam, naturalmente, a quantificação de perdas materiais e riscos de saúde pública (incluindo a perda de vidas humanas):

Todos os sistemas de abastecimento com mais de n clientes devem dispor de pelo menos duas captações suficientemente distantes para poderem ser consideradas independentes relativamente a riscos que podem comprometer o seu bom funcionamento.

Esta conclusão é suportada, em larga medida, por estudos que avaliam o custo de construção de infraestruturas que permitem interligar redes vizinhas de modo a partilharem componentes decisivos para a segurança dos sistemas face a eventos extremos.

c.       Magnitude: N

Caracterização: Interrupção de serviço de muito longa duração devido à completa destruição do sistema de abastecimento.

Observações: A probabilidade de ocorrência deste cenário, mesmo perante as catástrofes referidas como potencialmente responsáveis por falhas de magnitude N-1, é aproximadamente nula. Assim, exceptuando o caso de redes extremamente simples compostas por um número muito reduzido de componentes, pode afirmar-se que os perfis de fiabilidade traçados de acordo com o modelo proposto terminam sempre no eixo das ordenadas (N,0).

3.4.5.4.6            Implementação

O algoritmo descrito foi implementado numa aplicação informática desenvolvida no âmbito do presente trabalho. A aplicação, designada de ProbIn, divide-se em dois componentes:

a.       Um componente desenvolvido em Visual Basic, que importa os dados acerca da configuração da rede a avaliar a partir de um ficheiro INP do EPANET;

b.      Um componente desenvolvido em SQL Server que efectua os cálculos descritos anteriormente. Os dados que permitem a definição das funções de fiabilidade dos componentes individuais da rede devem ser introduzidos nesta parte da aplicação.

A aplicação ProbIn não dispõe de uma interface gráfica, pelo que os comandos de análise da rede devem ser introduzidos sob a forma de texto.

A aplicação produz dois tipos de resultado (ver Fig. 29):

a.       A fiabilidade da rede, definida por uma probabilidade de ocorrência de uma falha durante o período de análise;

b.      Uma lista de componentes críticos da rede correspondentes a um par de nós início-fim definidos pelo utilizador. Qualquer falha num destes componentes resulta numa interrupção de serviço no nó fim devida à ausência de componentes redundantes.

Fig. 29 – Aplicação ProbIn: Obtenção de dados e cálculo de indicador de fiabilidade da rede (Poças Martins, Poças Martins 2008)

3.4.6       POCINDEX

3.4.6.1      Apresentação

O POCINDEX é um modelo que procura avaliar a fiabilidade de um sistema de abastecimento, com recurso aos dados que se considera possível obter de imediato num sistema que mantenha um registo contínuo de operações efectuadas e de avarias detectadas na rede.

Ao contrário do que o nome pode sugerir, não se trata de uma medida simples de fiabilidade (um valor numérico qualitativo), mas antes de um conjunto de parâmetros que caracterizam a rede e o seu desempenho. Assim, um índice deste tipo será um índice compósito constituído por informação quantitativa acerca da rede. Por outro lado, tendo em conta a importância de avaliar a fiabilidade de uma rede de diferentes pontos de vista (do cliente, da empresa responsável pela gestão do sistema, etc.), foram desenvolvidos índices de natureza diversa contendo a informação considerada relevante para cada um dos intervenientes correspondentes.

A avaliação do sistema de abastecimento, tendo em conta a sua redundância a capacidade dos seus componentes, é efectuada, de forma automática, usando o algoritmo descrito em 3.4.5, mas não será avaliada a probabilidade de sucesso associada. Assim, o modelo não será baseado em critérios probabilísticos, mas antes em critérios de redundância e de capacidade do sistema. A possibilidade de associar diferentes níveis de redundância e de capacidade a cada uma das zonas do sistema ou mesmo a cada cliente individual distingue esta abordagem das medidas actualmente utilizadas a nível internacional (por exemplo, o já referido SSI da OFWAT).

3.4.6.2      Descrição geral do modelo

O POCINDEX divide-se em dois índices:

a.       O primeiro, designado de Customer POCINDEX, mede a fiabilidade do sistema na óptica do cliente individual. Deve ser calculado para cada cliente do sistema e só avalia a porção de rede envolvida no abastecimento a esse cliente.

b.      O segundo, o System POCINDEX, avalia a fiabilidade da rede como um todo. Este índice, para além de medidas de volume de reserva para todo o sistema, inclui parâmetros que procuram identificar a existência de zonas de menor fiabilidade na rede. Estas zonas correspondem a troços de rede onde o grau de redundância é reduzido porque não estão incluídos num anel, porque não são podem ser servidos por mais de uma captação, porque o volume de reserva correspondente é considerado insuficiente ou ainda porque registaram um número apreciável de interrupções de serviço durante o período de análise. Este modelo pode ainda ser aplicado a áreas individuais da rede de modo a avaliar o seu peso na fiabilidade global do sistema.

Note-se que, ao contrário do indicador probabilístico proposto, o POCINDEX baseia-se, por um lado em dados recolhidos directamente e de forma automática no cadastro da rede (nomeadamente a inclusão ou não de um cliente numa malha da rede, por exemplo) e em dados operacionais (como o número de clientes afectados por mais de n interrupções durante o período de análise semelhante ao indicador CEMIn do IEEE apresentado anteriormente). Refere-se que este parâmetro não procura justificar as interrupções observadas. Ao invés, agrupa os incidentes, capturando de forma indistinta interrupções devidas a deficiências materiais, a operações de manutenção na rede, a falhas na origem, etc.

3.4.6.3      Obtenção de dados: Interrupções de serviço

3.4.6.3.1            Soluções alternativas

O cálculo do POCINDEX exige a obtenção de dados relacionados com o número de interrupções de serviço por cada cliente, actualmente indisponíveis para generalidade dos sistemas de abastecimento. É fundamental que se garanta ainda que os dados sejam fiáveis e auditáveis.

Discute-se no texto que se segue um conjunto de soluções alternativas para a obtenção dos dados necessários ao cálculo do indicador proposto. Essas soluções são ordenadas, de forma crescente, de acordo com as dificuldades previstas para a sua implementação, isto é, da solução menos ambiciosa (mas mais apta para ser adoptada no curto prazo por qualquer entidade gestora) à mais ambiciosa (mas de aplicação menos verosímil no imediato).

3.4.6.3.2            Fichas de interrupção

Considera-se que esta opção permite a recolha dos dados necessários ao cálculo do POCINDEX a curto prazo, na generalidade dos sistemas de abastecimento. Sugere-se que, para cada interrupção registada, seja preenchida uma ficha que permita conhecer a duração do corte de abastecimento e o número de clientes afectados. O número de clientes afectados resultará de uma simples estimativa a efectuar no local. Admite-se que esta prática pode comprometer a fiabilidade dos resultados recolhidos e a sua auditabilidade. Ainda assim, a simplicidade do método e a utilidade da informação recolhida para a gestão interna da empresa, tornam-no interessante, em especial para empresas cujos sistemas de informação não estejam ainda suficientemente maduros.

É suficiente determinar o perímetro afectado ou os arruamentos onde se regista a interrupção para se conhecer, ainda que de forma aproximada, o número de interrupções sofridas num dado período por cada cliente e a sua magnitude medida em habitante x hora ou em hora/habitante.

3.4.6.3.3            Algoritmos de corte

Esta designação foi adoptada, por simplicidade, para um procedimento que combina a informação contida numa ou mais bases de dados – cadastro de clientes e levantamento de componentes da rede e suas características – com um modelo hidráulico que permita efectuar não só o cálculo de pressões e velocidades na rede como a sua evolução perante a adopção de manobras a realizar no sistema em caso de rotura. Deve ser possível prever e simular a abertura e fecho de válvulas que isolem o troço de rede afectado pela rotura ou a entrada em funcionamento de uma estação elevatória que permita restabelecer o abastecimento numa determinada zona, por exemplo.

Os algoritmos de corte, dadas as coordenadas da rotura responsável pela interrupção, determinam de forma automática as manobras de fecho de troços de rede a efectuar e os clientes afectados. Note-se que estas roturas podem ser reais ou virtuais, servindo estas últimas para simular interrupções devidas a outras causas (avarias de componentes de rede, por exemplo). As coordenadas poderão ser cartesianas ou podem representar a respectiva distância relativamente a um dado nó da rede, acompanhada por uma referência à conduta onde ocorreu a rotura. A adopção desta solução exige, para além da determinação de regras que definam as manobras a efectuar em caso de rotura, de um levantamento cadastral rigoroso e de um Sistema de Informação Geográfica detalhado. Deve ser possível identificar cada cliente individual e cada componente da rede (condutas, válvulas, estações elevatórias, etc.), incluindo as respectivas características relevantes. Assim, dada a posição da rotura e o cadastro da rede, o algoritmo determinará quais os clientes afectados pela rotura e pelas manobras a efectuar na rede.

Embora se reconheça que a generalidade das entidades gestoras não dispõem actualmente de toda a informação necessária à implementação deste procedimento, considera-se que é importante que desenvolvam esforços no sentido de a conseguirem. Com efeito, um levantamento cadastral detalhado é fundamental, não só para a avaliação da fiabilidade da rede, mas para a generalidade das medidas de gestão da rede, desde a aquisição de componentes à gestão da manutenção, ao cálculo hidráulico da rede, à gestão de perdas, etc.

3.4.6.3.4            Instalação generalizada de equipamentos

Esta é uma solução menos verosímil no curto prazo, embora seja tecnicamente viável com os meios actualmente disponíveis. Requer a instalação de equipamentos do tipo AMR (Automatic Meter Reading, na bibliografia em língua inglesa) em todos os ramais – acoplados aos contadores, a montante destes – que permitam a medição de pressões na rede e a transmissão de dados, em tempo real.

3.4.6.3.5            Estimativa da duração de interrupções

A duração de uma interrupção causada por uma rotura pode ser introduzida directamente por um utilizador de um sistema deste tipo ou pode ser estimada a partir dos dados operacionais da empresa (contidos no seu sistema ERP, por exemplo). Essa estimativa poderá ser calculada a partir de expressões como a seguinte:

Em que,

-        Di é a duração da interrupção [horas];

-        Heq é o tempo que a equipa responsável pela reparação da rotura permanece afecta a este trabalho [horas]. Esta informação deve ser recolhida, de preferência de forma automática, a partir dos dados operacionais da empresa;

-        a é um parâmetro adimensional que afecta Heq de forma a considerar apenas o tempo que demora a restabelecer o abastecimento de água, não eventuais trabalhos complementares de repavimentação, por exemplo. Assim, o parâmetro deve assumir valores menores ou iguais a um;

-        Ta é o tempo contado desde que ocorre a rotura até o momento em que a equipa de reparação é mobilizada [horas]. Considera-se que este valor deve ser recolhido, de preferência de forma automática, no registo de trabalhos de reparação já realizados (poderá ser assumido um valor médio para este tempo) e pode servir como indicador de desempenho da empresa no que concerne ao seu tempo de mobilização perante situações de rotura.

Nenhum dos indicadores elementares que compõem o POCINDEX é função da duração das interrupções registadas, pelo que a expressão não é utilizada no cálculo do indicador compósito. Admite-se, porém, que o valor de Di pode ser útil na definição de medidas complementares de eficiência do sistema de abastecimento, nomeadamente o QS13 descrito em 3.4.2.5.

3.4.6.4      Excesso de capacidade do sistema de abastecimento

Conforme se referiu em 3.4.1, o excesso de capacidade de um sistema de abastecimento é medido usualmente como função do volume de reserva de um número limitado de componentes considerados críticos na rede em alta – nomeadamente reservatórios, estações elevatórias, etc.

Constata-se, porém, que frequentemente as condições de serviço são limitadas, não pelos componentes da rede em alta, mas pelos da rede de distribuição. Assim, na óptica do cliente, um determinado caudal instantâneo de consumo pode ser condicionado por uma conduta da rede de distribuição de dimensão insuficiente, por exemplo. Inversamente, o funcionamento de uma rede de distribuição pode ser afectado negativamente pela introdução de um cliente com um consumo de água elevado.

Considera-se que é importante que, no processo de licenciamento de sistemas de distribuição predial água, seja considerado o impacto criado na rede pública por cada novo cliente. A adopção de um sistema de representação do tipo proposto no presente trabalho permite que esse impacto seja avaliado de forma automática a partir do somatório dos caudais instantâneos correspondentes aos dispositivos de utilização previstos nos projectos (QT) (ver 4.3).

O valor de QT deve ser relacionado com o caudal máximo que pode ser fornecido ao cliente, admitindo uma pressão reduzida na rede pública, independentemente das características da sua rede predial (QD). QD é calculado, de forma simplificada, a partir da expressão , usualmente aplicada a escoamentos por orifícios. Assim, QD é função da pressão na rede e do diâmetro do ramal de abastecimento:

Assume-se um valor típico de 0,6 para o coeficiente de vazão, C. A altura h deve ser substituída pela altura piezométrica, , imediatamente a montante do ramal de abastecimento. Dado que QD é calculado para uma pressão reduzida na rede, considera-se que, na ausência de outro valor indicado pela entidade responsável pela gestão da rede pública, a altura piezométrica deverá assumir um valor correspondente à pressão mínima recomendada pelo DR nº 23/95 – ou seja, de aproximadamente 15 mca.

A relação entre QT e QD (indicada na expressão ) pode ser encarada de duas formas distintas:

a.       Um indicador da fiabilidade do abastecimento na óptica do cliente (isto é, do “factor de segurança” aplicável ao abastecimento em condições desfavoráveis);

b.      Uma medida do possível impacto produzido por um cliente individual na rede pública.

Valores elevados de RQ são normalmente associados a empreendimentos industriais ou imobiliários de grande dimensão, relativamente ao meio onde estão inseridos. Valores superiores à unidade são claramente indesejáveis.

3.4.6.5      Descrição detalhada do índice

Como se referiu, o POCINDEX é um índice composto por dois indicadores distintos, um que mede a fiabilidade do sistema sob o ponto de vista do cliente (Customer POCINDEX) e outro que mede a fiabilidade geral da rede, atendendo a eventuais heterogeneidades existentes (System POCINDEX).

a.       Customer POCINDEX

O indicador de fiabilidade do sistema sob o ponto de vista do cliente individual é definido pela seguinte expressão, a calcular para cada cliente individual da rede:

O significado das vaiáveis que compõe esta expressão é o seguinte:

-        NI – Número de interrupções de serviço a que o cliente foi sujeito durante o período de análise – o ano anterior;

-        ST – Armazenamento disponível para o cliente, medido em dias, assumindo um consumo diário médio ao longo da rede;

-        RQ – Relação entre caudal máximo de consumo e caudal disponibilizado pela rede pública em condições desfavoráveis, de acordo com o descrito em 3.4.6.4;

-        Rmalha – Valor binário – a configuração da rede de distribuição permite o abastecimento ao cliente por mais de um caminho distinto?

-        Rcaptação – Valor binário – o cliente pode ser abastecido a partir de mais de duas ou mais captações distintas?

-        Radução – Valor binário – o abastecimento ao cliente pode ser efectuado a partir de duas ou mais condutas adutoras distintas?

Todas as variáveis devem poder ser obtidas de forma automática a partir da base de dados da entidade gestora. Os valores binários referidos podem ser calculados a partir do algoritmo do tipo breath-first search descrito anteriormente, usado para o cálculo do ProbIn.

b.      System POCINDEX

O indicador de fiabilidade do sistema é calculado pela seguinte expressão:

O significado das variáveis apresentadas é o seguinte:

-        %1I, %2I, %2I – Número relativo de clientes (expresso sob a forma de percentagem) sujeitos a uma, a duas e a mais de duas interrupções de serviço respectivamente, durante o período de análise anterior, respectivamente;

-        %1S, %1R, %2ST – Número relativo de clientes (expresso sob a forma de percentagem) servidos por uma captação única, por uma conduta adutora única e com menos de dois dias de armazenamento respectivamente, calculado com base em consumos médios diários;

-        %XD, %XW, %XM – Excesso de capacidade do sistema relativamente aos consumos médios diário, semanal ou mensal (medido pela relação entre o volume de armazenamento total e os consumos médios referidos).

Tal como se referiu para o indicador de fiabilidade sob o ponto de vista do cliente, as variáveis devem poder ser obtidas de forma automática a partir dos dados operacionais recolhidos pela entidade gestora.

3.4.7       Conclusões

Este ponto divergiu do tema central do trabalho, os sistemas de informação associados à construção. Este tópico foi desenvolvido uma vez que se considera que a fiabilidade do sistema público deve ser uma preocupação central das entidades responsáveis pela sua gestão mas que não é avaliada de uma forma consistente por indicadores existentes. Em particular, a fiabilidade da rede na óptica do cliente é um assunto que deve ser tido em conta, tanto ao nível da atribuição de licenças de construção, como ao nível do planeamento urbano.

Este assunto não poderia ser abordado, de forma relevante, sem o desenvolvimento de indicadores de fiabilidade da rede, ainda que as consequências da sua aplicação apenas em parte sejam aplicáveis para efeitos do licenciamento de obras privadas.

Optou-se assim por realizar aqui uma reflexão acerca do conceito de fiabilidade de uma rede, das diferentes formas admissíveis para a medir e das ilações que devem ser extraídas pelos diferentes intervenientes no processo construtivo face aos riscos que se colocam ao abastecimento de água.

Foram desenvolvidas duas metodologias para a avaliação da fiabilidade de uma rede, permitindo ambas a extracção de informação relevante na óptica do cliente: uma metodologia probabilística e um índice baseado em critérios de redundância e de capacidade de reserva.

Considera-se que uma avaliação probabilística da fiabilidade será a forma mais racional de medir a vulnerabilidade de cada componente da rede (e da rede no seu conjunto) face a diferentes cenários de falha. Este método permite ainda a introdução de parâmetros não quantificados neste estudo, em particular de parâmetros que permitem medir a fiabilidade de alguns dos componentes individuais da rede. Admite-se, contudo, que a aplicabilidade deste método pode ser comprometida pela indisponibilidade de dados necessários à quantificação de riscos e até pelas contradições detectadas entre muitos dos dados propostos por autores de proveniências distintas ou que realizaram estudos baseados em diferentes pressupostos. De qualquer forma, a definição e a implementação do algoritmo probabilístico que avalia a fiabilidade da rede estão concluídas, considerando-se que a recolha sistemática de dados operacionais é essencial para que possa ser aplicado de forma satisfatória a redes reais, com características próprias. Actualmente, uma entidade que pretenda utilizar indicadores probabilísticos (não só o indicador proposto) deve adoptar uma de duas soluções alternativas:

a.       Utilizar dados “locais” (recolhidos a partir dos dados operacionais da empresa), geralmente insuficientes sob o ponto de vista da avaliação de eventos extremos.

b.      Utilizar dados “globais” (resultantes de estudos efectuados a nível regional, nacional ou internacional), seriamente afectados pelas inconsistências detectadas nos vários estudos internacionais consultados, principalmente no que toca às variáveis relevantes para a avaliação de eventos rotineiros.

Nenhuma destas soluções conduz, por si só, a avaliações fiáveis dadas as fragilidades detectadas nos dados de base a utilizar. Considera-se, porém, que uma análise baseada em dados “locais” para a avaliação de eventos rotineiros e dados “globais” para eventos extremos poderá ser uma forma adequada de contornar as debilidades inerentes a cada um dos tipos de dados referidos.

O POCINDEX, baseado em critérios de redundância e de capacidade de reserva, pode ser aplicado a redes que mantenham um registo razoável de dados operacionais, não exigindo a avaliação de fiabilidade de componentes individuais. A sua aplicação automática depende, conforme foi referido anteriormente, de uma parte significativa do algoritmo desenvolvido para a avaliação probabilística da fiabilidade de sistemas de abastecimento, em particular para a identificação de percursos de abastecimento possíveis e dos seus componentes. Crê-se que a possibilidade de aplicação imediata deste índice, bem como a possibilidade de realizar análises comparativas de desempenho entre sistemas ou entre regiões de um mesmo sistema o tornam útil neste contexto.

O cálculo de indicadores de fiabilidade úteis na óptica do gestor – com a capacidade de revelar as debilidades do sistema que poderiam ser mascaradas pela adopção exclusiva de indicadores de “fiabilidade média” – exige a recolha de dados actualmente indisponíveis para a generalidade das redes. Estes dados podem ser obtidos por estimativa, por cálculo automático ou, sob um ponto de vista mais ambicioso, directamente a partir de equipamento instalado em cada ramal de abastecimento.

A entidade responsável pela gestão de um sistema de abastecimento deve avaliar continuamente a fiabilidade da sua rede e deve realizar esforços no sentido de garantir que os seus clientes contribuam, dentro de limites razoáveis, para o incremento da segurança do seu abastecimento.

Os indicadores de fiabilidade devem ser calculados por um processo fiável e auditável. Assim, o cálculo automático dos indicadores é essencial, não só por questões de eficiência, mas também para garantir que os resultados obtidos possam ser sujeitos à verificação de entidades externas. Desta forma, tornar-se-ia possível incentivar o investimento na fiabilidade de redes públicas de abastecimento de água através da introdução de multas, a pagar pela entidade gestora, perante situações em que a fiabilidade do abastecimento aos clientes seja considerada insuficiente.

No que toca ao contributo dos donos de obra particulares para a fiabilidade do sistema de abastecimento, considera-se que a construção de reservatórios prediais resulta num significativo acréscimo na segurança relativamente a falhas rotineiras, originando ainda vantagens funcionais decorrentes da regularização dos picos de consumo diários. Este acréscimo de fiabilidade resulta, naturalmente, numa combinação de dois benefícios:

a.       Por um lado, os clientes estarão menos vulneráveis a interrupções de abastecimento de curta duração;

b.      Por outro, tornando estas interrupções toleráveis, admite-se que será possível reduzir parte dos custos associados à disponibilidade permanente de serviços de reparação na rede.

Refere-se ainda que a utilização generalizada de reservatórios prediais tende a mitigar os impactos criados, em particular em zonas residenciais, por consumos de ponta elevados em períodos de tempo limitados.

Note-se, contudo, que a utilização de reservatórios prediais para fins alimentares – isto é, para a generalidade das redes prediais – é actualmente limitada pelos regulamentos em vigor – Ponto nº 2 do artigo 108º do DR nº 23/95 – sendo encarada como uma solução de recurso a empregar nos casos em que o fornecimento por parte do sistema público é considerado insuficiente em termos de pressões e caudais disponíveis. Refere-se, contudo, que o Regulamento permite que a entidade gestora defina os casos em que o armazenamento de água é autorizado.

3.5    Eficácia

Uma rede eficaz é aquela que garante o abastecimento em boas condições, sempre. É necessariamente uma rede robusta.

Os requisitos fundamentais a respeitar prendem-se com o bom funcionamento hidráulico da rede: respeito por pressões limite e velocidades de escoamento de referência. Na generalidade dos casos, ao fornecerem indicações para o cálculo hidráulico da rede, os regulamentos em vigor conduzem a redes eficazes, devidamente dimensionadas e construídas com materiais adequados.

É possível apontar, contudo, um aspecto regulamentar que pode resultar numa avaliação incorrecta do funcionamento da rede: a abordagem determinística à obtenção de coeficientes de simultaneidade. Em síntese, o DR nº 23/95 apresenta, sob a forma de curva, uma relação entre o caudal acumulado num qualquer nó da rede e o respectivo caudal de cálculo. O caudal de cálculo é minorado relativamente ao caudal acumulado, admitindo-se que os consumos da rede não decorrem em simultâneo.

Esta abordagem pode conduzir a dois tipos de problemas distintos:

a.       Problemas no cálculo de redes emalhadas: Considera-se que as disposições regulamentares são adequadas ao cálculo de redes prediais ramificadas, não emalhadas, pelas razões indicadas em 2.5.1.

b.      Problemas no cálculo de redes com consumos simultâneos: Os coeficientes regulamentares podem não ser adequados para todas as situações. Frequentemente, a ocorrência simultânea de consumos deve ser prevista pelo projectista – por exemplo, no caso de balneários de recintos desportivos – resultando em tubagens com diâmetros superiores aos que seriam encontrados caso fossem adoptados caudais reduzidos. O DR nº 23/95 não prevê esta situação de forma explícita, nem fornece indicações acerca do caudal de cálculo a adoptar neste tipo de casos. Encontrou-se, na bibliografia consultada (Silva Afonso 2001), alternativas ao processo de cálculo indicado no Regulamento Geral.

Assim, uma rede calculada de forma a garantir o consumo simultâneo de diversos dispositivos de utilização (isto é, uma rede em que os caudais de cálculo não são obtidos através da aplicação dos coeficientes de simultaneidade regulamentares) pode ser considerada não conforme perante o DR nº 23/95. Com efeito, uma verificação subsequente à luz dos regulamentos aplicáveis (considerando os coeficientes de simultaneidade previstos) pode indicar velocidades reduzidas nas tubagens, violando o disposto no Artigo 94º: às tubagens dimensionadas para valores iguais ou próximos do caudal acumulado corresponderão velocidades reduzidas perante o caudal de cálculo regulamentar respectivo.

De acordo com a descrição apresentada em 4, o modelo de dados proposto permite ao projectista optar entre o coeficiente de simultaneidade regulamentar ou outro (por exemplo, por um coeficiente de simultaneidade igual à unidade, ou seja, considerando o caudal de cálculo igual ao caudal acumulado no nó). O sistema de verificação automática elaborado pode tomar em consideração esta indicação do projectista aquando da avaliação da conformidade do projecto.

3.6    Eficiência e economia: Custos de construção

Os requisitos de eficiência e economia, não sendo de cumprimento obrigatório para garantir uma satisfação dos requisitos básicos de funcionamento, têm influência nos custos da solução escolhida, incluindo os seus custos iniciais e de funcionamento.

O custo de construção da rede inclui todos os custos directos de mão-de-obra, materiais e equipamentos necessários à sua execução e os correspondentes custos indirectos.

Uma razão pela qual importa à entidade licenciadora a estimativa do custo de construção das redes prediais prende-se com a definição de custos para o processo de licenciamento, a imputar ao dono da obra. Segundo foi possível constatar, o dono da obra deve declarar os custos de construção previsíveis, sendo estes valores verificados posteriormente por comparação com valores de referência que podem ser retirados do historial de declarações correspondentes a obras similares e/ou dos índices de custos publicados pela Comissão de Índices e Fórmulas de Empreitadas (CIFE) do InCI. O custo a imputar ao dono da obra será então uma percentagem do custo de construção estimado. Embora este processo seja considerado aceitável para o fim a que se destina, admite-se que pode ser melhorado usando modelos de informação do tipo proposto para obter as quantidades de trabalho a realizar e os respectivos custos.

Apesar do interesse da entidade licenciadora, é aos donos de obra que importa, em primeiro lugar estimar e validar os custos de construção. Para além do método referido no parágrafo anterior, adequado para a detecção de eventuais desvios de custo relativamente ao previsto, importa ainda explicar os desvios detectados e propor alternativas de projecto no sentido de reduzir os custos estimados.

Uma verificação importante a efectuar neste sentido prende-se com a avaliação do traçado definido para as redes. De uma forma geral, importa definir um traçado tão curto quanto o possível para a rede, respeitando naturalmente as restrições impostas pelo projecto geral e pelas restantes especialidades e garantindo o bom funcionamento da rede em termos de pressões e velocidades de escoamento.

Propõe-se uma verificação geométrica do traçado da rede, medindo o seu comprimento total e comparando-a com uma solução de referência. A solução de referência é obtida de forma automática a partir de um conjunto de pontos de passagem obrigatória, de acordo com a descrição efectuada em 3.6.1.1.

Refere-se ainda que este estudo é válido para a generalidade das redes prediais ramificadas. As redes do tipo pex, pelo contrário, têm uma configuração distinta da tradicional, caracterizada pela convergência de todas as condutas das redes de água fria e quente num ponto para cada rede. Neste tipo de rede, não se opta por um traçado optimizado no que toca ao seu comprimento total, sendo a sua configuração geométrica mais fortemente condicionada pela arquitectura do edifício (em particular pela definição dos seus compartimentos).

É evidente que as variáveis envolvidas na estimativa do custo total de uma rede excedem aquelas que se relacionam com a determinação do traçado mais curto. Os materiais escolhidos para os acessórios da rede (em particular para aqueles que são instalados à vista como as torneiras, por exemplo) podem ter um peso muito significativo nos custos. Embora se considere viável estimar esses custos em função do tipo de construção previsto, optou-se por reduzir o estudo à comparação da rede projectada com a rede mais curta uma vez que esta definição de projecto é talvez aquela cujo problema de optimização se revela mais interessante. A selecção dos materiais a empregar pode ser encarada como sendo efectuada, a montante da definição do traçado da rede, em função das características específicas da obra consideradas pelo projectista da especialidade.

3.6.1.1      A rede mais curta

3.6.1.1.1            Visão global do problema

A definição da rede mais curta que passa por um conjunto de pontos dados é um problema geométrico que se coloca ao traçado de redes hidráulicas, eléctricas, viárias, etc. O problema admite um conjunto de variantes eventualmente não aplicáveis ao problema em apreço, incluindo a rede mais barata ou a rede que minimiza os tempos de percurso.

As redes hidráulicas, de acordo com o DR nº 23/95, são compostas por troços horizontais e verticais. Por norma, uma rede pode ser encarada, de forma simplificada, por conjuntos de condutas horizontais correspondentes aos pisos, ligados pontualmente por troços verticais. Nestas condições, a rede mais curta será a que apresenta um conjunto de condutas horizontais com a menor dimensão.

O problema pode ser resolvido como um problema de árvore mínima de Steiner, enunciado da seguinte forma:

Dado um conjunto N de pontos pertencentes a um plano, a árvore mínima de Steiner é a rede que liga os pontos de N com o menor comprimento medido por uma dada função distância.

Importa fazer um conjunto de comentários à definição apresentada:

a.       A “função distância” pode ser a correspondente à distância euclidiana ou outra. Torna-se assim possível calcular a rede mais barata ou a rede que minimiza os tempos de percurso seguindo a mesma metodologia.

b.      A árvore de Steiner pode incluir pontos não pertencentes a N, designados de “pontos de Steiner”. Estes pontos são adicionados ao conjunto de pontos dados de forma a reduzir o comprimento da rede. Representa-se na Fig. 30, a título de exemplo, a árvore de Steiner correspondente aos pontos P1 a P4 representados. Os pontos S1 e S2 são pontos de Steiner, adicionados aos pontos dados.

c.       A inclusão destes pontos adicionais torna o problema de Steiner NP-completo (Brazil 2001).

Fig. 30 – Árvore de Steiner: (1) Dados, (2) Rede correspondente aos pontos P1 a P4.

Note-se que os pontos são adicionados com um objectivo exclusivo: reduzir o comprimento da rede. Os pontos adicionais podem, contudo, resultar em consequências indesejáveis:

a.       Maior tempo de processamento/dificuldade em generalizar processo de resolução

De acordo com o referido anteriormente, o problema de Steiner é NP-completo, o que na prática, significa que o problema não pode ser resolvido em tempo polinomial (Buescu 2003), tornando-o exigente sob o ponto de vista computacional. O problema não se afigura, contudo, particularmente grave na generalidade dos casos relacionados com projectos de instalações hidráulicas, caracterizados por um conjunto N de pontos dados contendo poucos elementos (na ordem das dezenas, ou poucas centenas de elementos, no máximo). Encontra-se na bibliografia exemplos de problemas geométricos resolvidos com alguns milhares de pontos dados (Warme 1998) pelo que se considera que este obstáculo está longe de inviabilizar a resolução do problema relativo aos sistemas hidráulicos concebíveis, apesar de dificultar a generalização do modo de resolução de forma a permitir a análise de conjuntos de pontos com um número arbitrário de elementos.

b.      Possibilidade de geração de redes inviáveis devido à colocação inadequada de pontos de Steiner

A definição de um traçado adequado para uma rede hidráulica não se resume, naturalmente, à definição da menor rede que contém todos os pontos a percorrer. A rede deve respeitar as condicionantes impostas pelo projecto geral e pelo conjunto dos projectos de especialidade. Representa-se na Fig. 31 um exemplo baseado na rede simples já apresentada anteriormente, onde se ilustra uma possível incompatibilidade com o projecto de arquitectura (implantação do edifício representado de forma esquemática pela linha azul). Este problema tornar-se-ia ainda mais sério se fosse considerada a organização interna do edifício, incluindo a definição das divisões e dos respectivos revestimentos. Estas condicionantes podem inviabilizar estas redes de traçado relativamente imprevisível e representam um obstáculo sério à resolução automática do problema. Uma solução possível passa pela definição manual de um conjunto adicional de pontos que evitem os conflitos identificados. Esta solução produz dois problemas adicionais:

i.      Cada novo ponto introduzido em N produz efeitos no traçado da rede que podem ser difíceis de prever. Pontos de Steiner que podem ser considerados aceitáveis numa dada configuração, podem deixar de existir ou migrar para posições inconvenientes devido à alteração dos dados do problema.

ii.      A introdução manual de pontos não é, por norma, criteriosa pelo que pode resultar numa rede subóptima no que concerne ao seu comprimento total.

c.       Custos adicionais devidos à introdução de novos nós na rede

Embora se admita, por simplificação, que a rede mais curta será a mais barata, a verdade é que todos os novos nós criados na rede implicam custos adicionais correspondentes ao corte de tubagens (e consequentes desperdícios) e à montagem de acessórios.

Fig. 31 – Árvore de Steiner vs. Condicionantes de projecto

3.6.1.1.2            Método aproximado

Os obstáculos apontados ao traçado automático de redes de acordo com o problema de Steiner justificam a adopção de um método alternativo que evite a definição automática de pontos de Steiner. O resultado obtido não será, em princípio, a rede mais curta, mas apenas uma aproximação desta configuração. A rede produzida poderá apresentar conflitos com os restantes projectos, tal como acontecia com as árvores de Steiner, mas a introdução de novos pontos produz resultados mais previsíveis, facilitando uma eventual automatização do processo de correcção da rede. Nos exemplos ilustrados na Fig. 33 e na Fig. 34., o conflito detectado foi corrigido através da introdução de um quinto ponto, P5, que altera a configuração da rede de uma forma previsível.

Esta visão alternativa do problema corresponde ao designado problema da “árvore geradora de custo mínimo”. Neste caso, como o “custo” corresponde à distância entre vértices, pode usar-se a designação alternativa “mínima árvore euclidiana” (versão simplificada da designação anglo-saxónica, euclidean minimum spanning tree, ou EMST). Esta rede não inclui vértices não pertencentes ao conjunto N de pontos dados, o que simplifica o processo de resolução.

Uma questão relevante prende-se com a determinação do grau de aproximação entre as soluções obtidas a partir de ambos os métodos (árvore de Steiner e mínima árvore euclidiana). Conjecturou-se (Gilbert, Pollak 1968) que a relação entre comprimentos totais seria, no máximo, de cerca de 13%, de acordo com a seguinte expressão:

Nesta expressão LS é o comprimento total da árvore de Steiner e LM o comprimento total da mínima árvore euclidiana.

Esta conjectura foi validada mais de 20 anos depois (Du, Hwang 1990). Embora este seja um limite extremo, verifica-se que a diferença real é, em geral, significativamente menor (Dippon, Train 2000). Ilustra-se na Fig. 32 uma configuração que resulta numa diferença máxima entre comprimentos dos dois tipos de rede analisadas. A mesma diferença ocorrerá em conjuntos de pontos em que a configuração apresentada na Fig. 32 se repita de forma modular.

Fig. 32 – Configuração correspondente à maior diferença entre comprimentos das redes de Steiner (a vermelho) e EMST (a azul)

Fig. 33 – Mínima árvore euclidiana correspondente aos dados representados na Fig. 30 (uma das duas soluções possíveis)

Fig. 34 – Mínima árvore euclidiana vs. Condicionantes

Este problema pode ser resolvido usando algoritmos do tipo greedy (por vezes apelidados de vorazes, gulosos ou avarentos na bibliografia em língua portuguesa), tornando-o particularmente apto para ser resolvido por métodos computacionais. Os algoritmos deste tipo procuram atingir um óptimo global para uma função a partir de uma sequência de óptimos locais. Frequentemente, não é atingido um óptimo global, mas apenas uma aproximação. Em alguns casos, contudo, um algoritmo greedy pode mesmo conduzir à pior solução possível (Gutin et al. 2001), (Gutin et al. 2004). Ainda assim, os bons resultados obtidos em problemas do tipo árvore euclidiana mínima, bem como a sua simplicidade conceptual, justificam a adopção deste tipo de algoritmo para a determinação da rede hidráulica mais curta. No caso em estudo, o traçado mais curto seria construído de forma iterativa pelo conjunto de troços admissíveis mais curtos apresentados em cada iteração.

Note-se que este método pressupõe a definição prévia de um conjunto de troços admissíveis, sendo que a rede a definir será um subconjunto deste. A forma mais evidente de gerar este conjunto, garantindo que contem todos os pontos da rede a definir, será construir o grafo completo correspondente ao conjunto N de pontos, isto é, estabelecer todas as combinações de pontos, dois a dois. O número total de arestas, na, do grafo, e, correspondente a um conjunto de n pontos será, dado pela expressão .

Fig. 35 – Grafo completo (Kn) correspondente a conjuntos de n vértices, para n=16 (Trudeau 1993)

Naturalmente, a eficiência global do algoritmo será tanto maior quanto menor o conjunto de troços admissíveis definido nesta fase inicial, por um lado porque a simples geração do conjunto é uma tarefa que exige algum esforço de processamento, por outro porque o volume de verificações a efectuar durante o processo será significativamente reduzido.

Importa, pois, limitar o número de arestas a considerar numa primeira fase do algoritmo. Essa redução será efectuada com base na seguinte propriedade:

Se uma aresta pertence à árvore euclidiana mínima correspondente a um conjunto N de pontos, então pertence à triangulação de Delaunay correspondente ao mesmo conjunto.

Uma triangulação 2D diz-se de Delaunay se respeitar a seguinte condição (Poças Martins 2004):

Qualquer elemento triangular da malha pode ser inscrito numa circunferência que não contém, no seu interior, nenhum ponto para além dos vértices do elemento.

A proposição que sustenta a propriedade enunciada para as EMST pode ser provada através do seu contrapositivo: se a aresta não pertence à triangulação de Delaunay correspondente ao conjunto N de pontos, então não pertence à mínima árvore euclidiana correspondente ao mesmo conjunto.

A prova partirá da seguinte propriedade de uma triangulação de Delaunay, que resulta da condição definidora citada anteriormente:

Dados dois pontos P e Q pertencentes a um conjunto N de pontos, se existir uma circunferência que contenha ambos os pontos e que não contenha quaisquer outros pontos de N, então a aresta PQ pertence à triangulação de Delaunay correspondente a N.

Assim, se se tomar uma circunferência de diâmetro PQ, esta aresta só não pertencerá à triangulação de Delaunay se existir um ponto R no interior da circunferência Fig. 36. Naturalmente, se R for um ponto interior da circunferência,  e . Nestas condições, a árvore euclidiana mínima, isto é, o conjunto de arestas de menor comprimento total que incluem todos os pontos de N, nunca irá incluir PQ. Prova-se assim que:

a.       Se uma aresta não está numa triangulação de Delaunay então a aresta não está na árvore euclidiana mínima correspondente, logo:

b.      Todas as arestas pertencentes a uma árvore euclidiana mínima pertencem também à triangulação de Delaunay correspondente, ou ainda de outra forma:

O conjunto das arestas da árvore euclidiana mínima forma um subconjunto das arestas da triangulação de Delaunay correspondente.

Fig. 36 – Se uma aresta não está numa triangulação de Delaunay então a aresta não está na árvore euclidiana mínima correspondente

O número de arestas numa triangulação de Delaunay pode ser calculado a partir das seguintes expressões:

E pela fórmula de Euler:

Nestas expressões, t representa o número de elementos triangulares, e o número de arestas, n o número de vértices e k representa o número de arestas no contorno que, para um polígono fechado, é igual ao número de pontos sobre o contorno, com  (Poças Martins 2004).

O número e de arestas de uma triangulação de Delaunay correspondente a um conjunto N com n pontos é dado pela expressão seguinte:

Um grafo completo será composto por na arestas:

Sublinha-se que o número de arestas correspondentes um grafo completo é função de n^2, enquanto o número de arestas da triangulação de Delaunay respectiva é função de n. Esta redução pode não produzir benefícios perceptíveis, em termos de tempo de processamento, para redes extremamente simples – como são a generalidade das redes de distribuição prediais – mas torna-se muito significativa em redes mais complexas, como por exemplo redes municipais de abastecimento de águas ou de saneamento.

3.6.1.1.3            Definição da rede: Algoritmos de Prim e de Kruskal

Tendo sido definidos os troços iniciais admissíveis, isto é, um conjunto de arestas que contém todas as arestas pertencentes à árvore euclidiana mínima, procede-se à selecção dos troços que constituem a rede mais curta. Essa selecção pode ser efectuada com recurso aos algoritmos de Prim (Prim 1957) ou de Kruskal (Kruskal 1956), entre outros.

Neste trabalho, optou-se por implementar o algoritmo de Prim (também designado de algoritmo Dijsktra-Jarnk-Prim por ter sido descoberto e redescoberto de forma independente pelos três autores) por se ter considerado que resulta num código mais compacto. Ainda assim, dada a popularidade relativamente equivalente dos dois métodos, optou-se por fazer uma curta referência complementar ao algoritmo de Kruskal. De acordo com o referido anteriormente, ambos os algoritmos são do tipo greedy.

O algoritmo de Prim pode ser descrito sucintamente da seguinte forma (ver também Fig. 38):

a.       Dados:

i.            Vector N contendo os n pontos a considerar.

ii.            Matriz A contendo as arestas admissíveis (quer tenham ou não sido limitadas com recurso à triangulação de Delaunay) definidas pelos seus pontos extremos nas primeiras colunas e os respectivos comprimentos na coluna seguinte.

b.      Procedimento:

i.            Seleccionar um ponto P pertencente ao vector N a partir do qual se pretende gerar uma aresta. Na primeira iteração, este ponto é seleccionado de forma arbitrária. Nas iterações seguintes será escolhido o ponto já visitado pelo algoritmo que dará origem à aresta válida mais curta definida na matriz A (a aresta será válida se não unir dois pontos já visitados pelo algoritmo). O ponto P deve ser adicionado a Pv, vector que contém todos os pontos já visitados pelo algoritmo, excepto se P já pertencer a Pv.

ii.            Escolher a aresta definida na matriz A, que contém P, de menor comprimento e que não contenha mais nenhum outro ponto pertencente a Pv. Isto significa que não serão escolhidas arestas em que ambos os pontos extremos já tiverem sido visitados pelo algoritmo. O segundo ponto extremo da aresta será Q, que será também adicionado a Pv. PQ será adicionada a R, vector que contém todas as arestas conhecidas da rede a definir.

iii.            Caso nv, o número de pontos de Pv for igual a n, isto é, se todos os pontos de N já tiverem sido visitados, a definição da rede está concluída, podendo ser lida a partir do vector R. Caso contrário, regressar ao primeiro passo.

A sequência de operações descrita nos parágrafos anteriores é ilustrada na Fig. 37. No exemplo apresentado, depois de gerada a triangulação de Delaunay correspondente ao conjunto de pontos dados, é aplicado o algoritmo de Prim.

O algoritmo proposto é representado, sob a forma de um fluxograma, na Fig. 38.

Fig. 37 – Triangulação de Delaunay e Algoritmo de Prim. Exemplo simples: (1) Dados, (2) Triangulação de Delaunay, (3) Dimensões, (4 a 8) Algoritmo de Prim: Sequência de operações, (9) Resultado: Rede mais curta

Fig. 38 – Algoritmo proposto: Representação esquemática. Algoritmo de Prim destacado (linha a traço interrompido).

O algoritmo de Kruskal apresenta algumas semelhanças com o de Prim. Segundo o algoritmo de Kruskal, as arestas não são obrigatoriamente escolhidas a partir de um ponto já visitado, sendo sempre escolhida e exportada para R a aresta válida mais curta. Neste caso, uma aresta será válida se, simultaneamente, não tiver sido já definida e se não der origem a um ciclo de pontos em que o mesmo ponto apareça mais de uma vez. No exemplo anterior, a aresta AB não poderia ser definida sob pena de dar origem ao ciclo A → C → B → A, dado que as arestas AC e CB, mais curtas, já teriam sido adicionadas anteriormente à rede mais curta.

3.6.1.1.4            Eficiência do método proposto

O método proposto divide-se essencialmente em duas fases (ver Fig. 39):

a.       Limitação do número de arestas a considerar com recurso à triangulação de Delaunay

A eficiência dos algoritmos mais rápidos para a geração de triangulações de Delaunay, nomeadamente o algoritmo de Fortune (Fortune 1987), (Jin et al. 2006), pode ser medida por O(nlogn).

b.      Definição da rede com recurso ao algoritmo de Prim

O tempo de processamento correspondente a este algoritmo, depois da limitação do número de arestas é de O(nlogn) (na realidade, a eficiência do algoritmo é de O(elogn) (Pettie, Ramachandran 2001), onde e é o número de arestas do grafo embora, no caso de triangulações de Delaunay, e e n possam ser relacionados pela expressão pelo que o valor O(nlogn) permanece válido). Caso o número de arestas não seja limitado pelo processo descrito, a eficiência neste passo será reduzida para O(n^2).

Assim, a eficiência global do método será igualmente de O(nlogn).

Refere-se novamente que este estudo de eficiência do algoritmo só se torna realmente relevante para redes complexas, como são algumas redes públicas de grande dimensão.

Fig. 39 – Definição da rede mais curta. Representação esquemática das etapas principais do algoritmo proposto

3.7    Conclusões

Os requisitos aplicáveis aos projectos de redes prediais foram divididos em 5 categorias. Segue-se uma síntese dos aspectos mais relevantes relacionados com cada tipo de requisito identificado (coluna assinalada com um a):

Tabela 5 – Requisitos aplicáveis aos projectos de redes de distribuição predial de água: Conclusões

a)

Observações

Segurança de pessoas e bens

·         A segurança de pessoas está associada essencialmente à qualidade da água na rede. Os aspectos mais relevantes para o cumprimento deste requisito prendem-se com a escolha de materiais adequados para os seus componentes e a regulamentação da implementação de reservatórios prediais.

·         A segurança de bens está relacionada com a possibilidade de ocorrência de roturas na rede. Os factores mais relevantes para a avaliação deste problema são a adopção de materiais adequados e a introdução de mecanismos que evitem a ocorrência de sobrepressões em caso de avaria na rede pública.

·         Considera-se que todas estas situações estão devidamente salvaguardadas pelas disposições regulamentares em vigor.

·         Os aspectos relacionados com este requisito são susceptíveis de verificação automática.

Respeito pelo ambiente

·         As implicações dos projectos de redes prediais de água no ambiente são limitadas.

·         A escolha de materiais adequados é essencial para evitar a contaminação da água.

·         Os problemas associados a consumos elevados de água são abordados através da adopção de tarifários divididos em escalões de consumo.

·         A verificação automática da rede, no que toca aos materiais que a compõem, pode ser efectuada usando o modelo proposto.

Fiabilidade do sistema público

·         Medidas existentes não representam a fiabilidade na óptica do cliente. Foram propostas medidas alternativas com esta finalidade, incluindo a definição de algoritmos de cálculo e o desenvolvimento de aplicações informáticas para a análise de redes públicas.

·         No DR nº 23/95, as questões relacionadas com a fiabilidade são abordadas por disposições que visam garantir a durabilidade dos elementos da rede, não a redundância de componentes.

·         Os reservatórios prediais são uma forma económica de incrementar a fiabilidade do abastecimento. Actualmente, na ausência de especificações no DR nº 23/95, as entidades gestoras são responsáveis pela definição dos aspectos construtivos, do dimensionamento e da localização dos reservatórios. Considera-se que a implementação destas instalações deveria ser devidamente regulamentada de modo a garantir os requisitos de segurança referidos anteriormente.

·         Os aspectos relacionados com a fiabilidade – tanto aqueles que estão previstos no regulamento como aqueles que foram identificados neste trabalho – são susceptíveis de cálculo e de verificação automática.

Eficácia

·         Os aspectos relacionados com a eficácia da rede dividem-se em duas categorias principais: aqueles que se referem à robustez da rede e os que dizem respeito ao seu bom funcionamento hidráulico.

·         No cálculo de redes prediais, não é assumida a continuidade de caudais ao longo dos nós da rede. Os caudais são minorados através do uso de coeficientes de simultaneidade definidos no DR nº 23/95.

·         O uso de coeficientes de simultaneidade resulta em problemas no cálculo de redes emalhadas e no cálculo/verificação de redes onde se prevê o funcionamento simultâneo de diversos dispositivos de utilização. Considera-se que o uso de coeficientes de simultaneidade, previsto no regulamento, deveria ser revisto de modo a que estes se adaptem às diversas situações reais. Estes coeficientes não deveriam ser calculados exclusivamente em função do caudal acumulado em cada nó.

·         O cálculo hidráulico da rede pode ser efectuado de forma automática, de acordo com as disposições regulamentares, desde que a rede seja definida num formato padrão. O uso ou não de coeficientes de simultaneidade no cálculo da rede deve ser decidido pelo projectista. A verificação do cálculo hidráulico, em sede de processo de licenciamento, deve respeitar esta decisão.

Eficiência e economia

·         Os aspectos relacionados com este requisito não são verificados, de uma forma directa, durante o processo de licenciamento. Não são alvo de disposições regulamentares específicas.

·         As entidades gestoras das redes públicas estimam os custos de construção das redes prediais com o fim de definirem as custas do processo de licenciamento. Esta estimativa é efectuada com base nas declarações dos projectistas e nos índices CIFE do InCI.

·         Actualmente, os custos das redes dependem, cada vez mais, dos custos dos dispositivos de utilização – difíceis de estimar com base num projecto de licenciamento – e das eventuais instalações complementares. Ainda assim, é possível identificar um aspecto que pode permitir aferir do grau de optimização do projecto: o traçado da rede.

·         Usando o algoritmo proposto é possível identificar a rede mais curta que contém um conjunto de pontos e compará-la com a rede definida pelo projectista. Este algoritmo pode ser usado para definir um traçado preliminar de forma automática.

·         A utilização de um formato de representação padrão para redes de distribuição predial de água e o recurso a uma lista de preços unitários estimados para cada tipo de componente permitem realizar, de forma automática, uma estimativa fundamentada dos custos de construção.

4     Licenciamento automático de projectos de sistemas de distribuição predial de água

4.1    Introdução

Foram apresentados no capítulo 2 os princípios que devem orientar a definição da estrutura de um modelo de informação para a construção e foram sugeridas formas de incentivar a comunidade de utilizadores a adoptarem o novo modelo, nomeadamente a verificação automática da conformidade regulamentar de projectos de sistemas de distribuição predial de água.

No capítulo 3 foram referidos alguns requisitos a cumprir pelos sistemas de distribuição predial de água, alguns dos quais com suporte no Decreto Regulamentar nº 23/95 e susceptíveis de verificação com recurso a meios informáticos.

Apresenta-se, no presente capítulo, a concretização dos aspectos acima referidos, nomeadamente:

a.       Proposta de um formato padrão para a representação de sistemas de distribuição predial de água que possa ser aplicado ao licenciamento automático de projectos;

b.      Desenvolvimento de metodologias de verificação regulamentar, baseadas nas disposições em vigor;

c.       Desenvolvimento de aplicações informáticas que interajam com os modelos elaborados.

Foram apresentadas, em 2.3.3, duas abordagens distintas ao processo de desenvolvimento de modelos de informação. A cada uma delas correspondem modelos com características distintas, em particular no que toca ao seu grau de detalhe e ao seu âmbito de aplicação. O modelo apresentado no presente trabalho foi desenvolvido através de uma abordagem minimalista, embora se considere que, idealmente, deva coexistir com modelos construídos segundo uma via estruturalista com o fim de garantir a interoperabilidade entre modelos.

Argumenta-se neste trabalho a favor do desenvolvimento de aplicações que evidenciem as vantagens da utilização de tecnologias da informação na construção. É fundamental que estas vantagens sejam tais que o cliente do produto da construção lhes reconheça valor. Só assim se considera que haverá incentivos para a adopção destas tecnologias da informação, inicialmente na fase de projecto, depois nas fases seguintes. Como se referiu anteriormente, a alternativa a esta abordagem passa pela introdução de regulamentos que tornem obrigatória a utilização de determinadas formas de representação de produtos da construção o que, claramente, não conduz às vantagens que acompanham a adesão voluntária às tecnologias de informação referidas.

Com efeito, o maior obstáculo à disseminação de tecnologia BIM será provavelmente a sua aceitação pelos intervenientes no processo de construção (em função da necessidade de ajustar processos de trabalho) e não qualquer outra questão de índole tecnológica (Carroll 2008).

Neste contexto foi desenvolvida uma aplicação designada de LicA (Licenciamento Automático) que efectua, de forma automática, a verificação da conformidade regulamentar de projectos de sistemas de distribuição predial de água de acordo com o Decreto Regulamentar nº 23/95.

A verificação automática da conformidade regulamentar é actualmente vista como um objectivo ambicioso para o sector da construção. Na bibliografia consultada, aponta-se mesmo que este objectivo só deverá ser atingido em 2020 (Eastman et al. 2008), apesar da existência de algumas iniciativas com este fim (ver 2.3.5.3.5).

Os projectos devem ser submetidos num formato próprio (descrito em detalhe neste capítulo e no Anexo C) produzido por ferramentas informáticas do tipo apresentado neste trabalho.

4.2    Descrição geral da aplicação LicA

A aplicação LicA efectua a verificação da conformidade regulamentar de um projecto definido num conjunto de tabelas de uma base de dados em formato SQL (Structured Query Language). Os resultados são também reunidos num conjunto de tabelas de forma a poderem ser apresentadas ao utilizador sob a forma de relatórios ou informação gráfica.

Fig. 40 – Representação esquemática geral da aplicação LicA

A aplicação LicA foi deliberadamente separada das aplicações que constituirão a interface com o utilizador por um conjunto de razões:

a.       Separação de tecnologias de programação

A linguagem T-SQL (Transact Structured Query Language) mantém-se relativamente estável desde o seu lançamento, apesar de assistir a actualizações periódicas. A compatibilidade das novas versões com as versões anteriores permite adivinhar uma vida útil extensa às aplicações desenvolvidas nesta linguagem quando comparada com a de aplicações que recorrem a outras linguagens de programação. As bases de dados têm, em geral, uma vida útil superior ao das aplicações externas que a elas acedem. A definição de um conjunto de funções principais, escritas em T-SQL permite a sua reutilização em aplicações futuras distintas, incluindo aplicações com interface web. Permite ainda que as funções do LicA sejam usadas tanto em aplicações de verificação da conformidade regulamentar de projectos (o objectivo principal da aplicação desenvolvida) como em programas de apoio ao projecto.

b.      Incerteza de formatos de ficheiros de dados

Actualmente, não existe um formato de representação padrão para produtos de construção. As entidades licenciadoras definem algumas regras de representação (para peças escritas e peças desenhadas) e algumas empresas de projecto e de construção desenvolvem normas próprias para o efeito, mas estas estão longe de constituir um modelo de informação tal como este conceito é definido neste trabalho. Como se referiu, o IFC tem assumido o papel de um formato padrão ad-hoc, mas a sua utilização por parte dos intervenientes no processo construtivo é ainda marginal. O seu estatuto actual não está associado à sua popularidade junto da comunidade técnica, mas antes à ausência de formatos de representação concorrentes, abertos e bem documentados. Com efeito, o sucesso deste formato, no que toca à sua adopção generalizada, está longe de estar garantido. Assim, importa prever a introdução de dados em formatos distintos. Esta abordagem é seguida também noutros trabalhos relacionados com modelos de informação para a construção estudados (Kiviniemi 2005). Na realidade, neste trabalho isto é conseguido através da definição de um formato de dados intermédio e de um conjunto de ferramentas que sejam capazes de gerar ficheiros de dados com ele compatíveis – directamente ou com recurso a outras aplicações específicas. Considera-se que são particularmente interessantes os inputs efectuados a partir de ficheiros compatíveis com o formato IFC e os que são efectuados directamente pelo utilizador usando uma interface gráfica (eventualmente baseada na web).

c.       Diferentes formatos de output

Uma ferramenta deste tipo deve ser capaz de produzir resultados úteis para diferentes tipos de utilizadores, desde projectistas que pretendam elaborar um projecto ou testar a conformidade regulamentar de um projecto antes de o submeter, até os técnicos das empresas responsáveis pelo abastecimento de água que pretendam analisar dados relativos aos projectos existentes (por exemplo, averiguar a existência de reservatórios prediais numa determinada área para medir a fiabilidade do abastecimento), até os técnicos das entidades licenciadoras que pretendam preparar um relatório da avaliação regulamentar de um projecto. A aplicação desenvolvida gera um ficheiro de resultados que pode ser lida por aplicações a jusante de forma a produzir diferentes tipos de output, conforme a utilização pretendida.

4.3    Modelo de dados

4.3.1       Aspectos gerais

O presente subcapítulo contém uma descrição do modelo de dados utilizado pelo programa LicA. O modelo de dados foi definindo especificamente para a aplicação em questão. Ainda assim, é compatível com outros formatos de representação, desde que seja usado um conversor apropriado.

A definição do modelo de dados resultou de uma procura de equilibrar duas exigências, em larga medida antagónicas: Por um lado, o modelo deve ser suficientemente completo para que descreva as propriedades mais relevantes do produto de construção e para que permita a realização de um conjunto significativo de verificações. Por outro, deve ser suficientemente simples para que a sua utilização, por parte dos projectistas, não implique um esforço de introdução de dados excessivo. Como regra geral, considerou-se que o modelo deve permitir efectuar de forma automática todas as verificações que não possam verosimilmente ser realizadas por processos manuais e que são dispensáveis as verificações automáticas de disposições que podem ser conferidas de forma expedita através de uma simples observação (ver discussão e exemplos em 2.5.5) quando a aquela implica a introdução de um volume significativo de dados.

Apresenta-se no Anexo B a estrutura da base de dados LicA.

Nos pontos que se seguem será descrita, de forma sucinta, a estrutura da base de dados que inclui a representação dos sistemas de distribuição e dos seus componentes, um conjunto de parâmetros relacionados com o regulamento a aplicar e os algoritmos de verificação da conformidade regulamentar de projectos.

De uma forma geral, as designações das tabelas da base de dados foram atribuídas de acordo com algumas regras principais:

a.       As tabelas cujo nome termina em _Res contêm os resultados da análise efectuada pelo programa.

b.      As tabelas terminadas em _Desc contêm campos de texto que podem ser usadas para output.

c.       As tabelas terminadas em _ID contêm listas de valores admissíveis para serem usados em campos de tabelas com elas relacionadas, sendo importantes para garantir a integridade da base de dados.

Os campos das tabelas da base de dados devem ser preenchidos de acordo com as regras indicadas nos pontos seguintes. Sublinha-se que as regras indicadas podem ser alteradas facilmente (isto é, podem ser acrescentados novos tipos de válvulas ou de espaços, por exemplo), pelo que estas podem ser encaradas como um conjunto base de instruções de preenchimento que correspondem ao DR nº 23/95.

Serão apresentadas apenas as regras consideradas mais relevantes, encontrando-se uma descrição mais detalhada da base de dados e do seu funcionamento em anexo.

4.3.2       Constituição da rede

4.3.2.1      Definição geral da rede

A rede é formada por nós e por ligações. As ligações podem ser canalizações, bombas ou válvulas e assumem obrigatoriamente uma destas funções. Os nós podem ter ou não consumos associados e podem assumir a função de reservatórios prediais. Os nós não assumem obrigatoriamente funções específicas, podendo ser definidos para, por exemplo, modificarem a geometria da rede (ver Fig. 41).

Fig. 41 – Nós com diferentes funções: (A) mudança de diâmetro, (B) modificação da geometria da rede, (C) consumos associados a nós

No LicA, os consumos são associados directamente a nós, não a dispositivos de utilização. Assim, o consumo de um dispositivo de utilização é o somatório dos consumos dos nós a ele associados. Isto permite que, por exemplo, um dispositivo de utilização (ou acessório de rede) tenha um consumo nulo ou que, pelo contrário, tenha múltiplos consumos associados.

N1

N2

Fig. 42 – Um dispositivo de utilização (lavatório): dois nós com consumos associados

4.3.2.2      Tipos de redes

As redes dividem-se em redes de água fria e de água quente. O programa não aceita actualmente redes de outro tipo (por exemplo redes para uso não alimentar, etc.).

Apresenta-se na Tabela 13 (SubNetworks_Type_Desc) do Anexo B os tipos de redes disponíveis no modelo de dados e as respectivas designações.

4.3.2.3      Nós de rede. Dispositivos de utilização e acessórios de rede.

No LicA, os nós podem não ter função específica ou podem corresponder a dispositivos ou acessórios de rede. Como se referiu anteriormente, as classes Nó e Dispositivo não são equivalentes. Um dispositivo pode conter vários nós aos quais estão associadas as suas propriedades hidráulicas relevantes para efeitos de cálculo: caudal e pressão. A ligação entre as tabelas de nós (Nodes) e de dispositivos (Devices) é efectuada através de uma tabela de consumos.

Para além das funções referidas, um nó pode ainda representar um reservatório predial. Neste caso, as suas propriedades serão descritas na tabela Tanks.

Dos elementos referidos, apenas os dispositivos de utilização e os acessórios de rede são subdivididos em categorias pelo que só estes serão detalhados neste subcapítulo.

A Tabela 14 (Devices_Type_Desc) do Anexo B contém a lista de dispositivos de utilização e acessórios de rede incluídos nesta versão do LicA.

4.3.2.4      Ligações de rede

4.3.2.4.1            Tipos de ligação de rede

Esta versão do LicA contém três tipos de ligações conforme se indicada na Tabela 15 (Link_Type_Desc) do Anexo B.

As tubagens são classificadas de acordo com a sua posição relativamente ao edifício (interior ou exterior), com o seu isolamento térmico (existente ou inexistente) e com o seu material, conforme se refere no ponto seguinte.

As válvulas, por sua vez, podem ser divididas de acordo com o indicado em 4.3.2.4.3.

A classe das bombas não contém subdivisões, pelo que estas não serão descritas neste ponto.

4.3.2.4.2            Tubagens

As tubagens da rede são enumeradas na tabela Pipes. Os materiais para canalizações, cujas características estão incluídas na base de dados, são os indicados na Tabela 16 (Materials_Desc) do Anexo B.

4.3.2.4.3            Válvulas

Os tipos de válvula incluídos nesta versão do programa são aqueles que são referidos no Regulamento Geral dos Sistemas Públicos e Prediais de Distribuição de Água e de Drenagem de Águas Residuais. As designações adoptadas pela aplicação desenvolvida estão indicadas na Tabela 17 (Tabela Valves_Type_Desc) Anexo B.

A lista de válvulas da rede compõe a tabela Valves cuja estrutura se apresenta em anexo.

4.3.2.5      Tipos de espaços

Os espaços são definidos no projecto geral de arquitectura. O estabelecimento de relações entre os componentes da rede e a respectiva localização, definida pelo espaço onde se encontra, é importante para a verificação regulamentar do modelo. O LicA aceita actualmente os tipos de espaços referidos na Tabela 18 (Spaces_Type_Desc) do Anexo B.

4.3.2.6      Modelação de componentes: Pormenores

A estrutura da base de dados foi definida tendo em conta as especificações do Regulamento Geral dos Sistemas Públicos e Prediais de Distribuição de Água e de Drenagem de águas Residuais, em particular as que constam do seu Título III. Naturalmente, existe uma enorme variedade de componentes disponíveis para serem usados nos sistemas de distribuição predial de água. Nem todos esses componentes são descritos ou mesmo mencionados nos regulamentos em vigor. Ainda assim, à imagem do que se processa com outras aplicações usadas para o cálculo de redes hidráulicas, é possível efectuar a modelação do comportamento hidráulico de alguns componentes da rede não incluídos nas tabelas predefinidas através de uma associação de elementos definidos na base de dados.

A título de exemplo, refere-se que é possível modelar o comportamento de depósitos de água com alimentação acima da superfície livre ou de equipamentos produtores de água quente da forma indicada em seguida:

a.       Modelação de depósitos com alimentação acima da superfície livre

Por defeito, considera-se que a alimentação de um depósito é efectuada abaixo da superfície livre. Caso se pretenda simular um abastecimento acima da superfície, é necessário colocar uma válvula de segurança imediatamente a montante do depósito. O parâmetro de funcionamento da válvula referida deve ser de 0 mca, isto é, a pressão imediatamente à entrada do depósito deve ser nula.

b.      Modelação de equipamentos produtores de água quente

O comportamento hidráulico de um equipamento produtor de água quente deve ser modelado usando um conjunto de nós e de ligações, em função do tipo de funcionamento que se pretenda simular. Tipicamente, um esquentador será representado por dois nós, correspondentes à entrada de água fria e à saída de água quente, e por uma ligação entre ambos. Caso se pretenda, é possível acrescentar válvulas, bombas ou depósitos, por exemplo, entre os nós referidos, em função das características do equipamento.

4.3.3       Parâmetros de cálculo

4.3.3.1      Propriedades gerais

A Tabela 19 (General_Properties) do Anexo B inclui constantes a utilizar nas verificações a efectuar pelo programa. Alguns dos valores indicados referem-se a valores regulamentares (por exemplo, pressão de serviço mínima de acordo com o art. 87º do DR 23/95), outros a constantes válidas para um projecto individual (por exemplo, pressão mínima na rede pública), outros ainda a regras de cálculo que podem ser alteradas pelo utilizador.

4.3.3.2      Utilização de coeficiente de simultaneidade regulamentar

Os caudais de cálculo resultam da aplicação de coeficiente de simultaneidade aos caudais acumulados em cada ponto da rede. Nem sempre são aplicados coeficientes de cálculo a consumos individuais, ou porque o regulamento assim o determina, ou porque o projectista decide, em função do tipo de uso previsto, admitir que um conjunto de dispositivos de utilização possa funcionar em simultâneo com frequência.

O programa permite associar a cada consumo uma indicação de utilização ou não de coeficiente de simultaneidade (ver Tabela 20 do Anexo B).

4.3.3.3      Mensagens de sistema

O programa produz um conjunto de mensagens de sistema indicando o resultado das verificações efectuadas (ver Tabela 21 do Anexo B). Nem todas as verificações regulamentares efectuadas correspondem a mensagens de sistema.

4.3.3.4      Avisos

Após efectuar as verificações indicadas pelo utilizador, o programa associa um conjunto de avisos às mensagens de sistema (ver Tabela 22 do Anexo B).

Estes avisos podem, por exemplo, ser associados a um código de cores para transmitir as mensagens de sistema de uma forma mais intuitiva. Esta é a abordagem seguida na aplicação LiCAD apresentada em 4.5.2.

4.4    Descrição do algoritmo

4.4.1       Verificações prévias

Antes de efectuar qualquer cálculo hidráulico, procede-se a um conjunto de verificações prévias, de modo a garantir que os dados preenchem os requisitos necessários, a saber:

a.       Todos os nós devem pertencer a pelo menos uma ligação;

b.      Todas as ligações devem ter uma (e só uma) função prevista na base de dados (ver 4.3.2.4);

c.       Não existe mais de uma ligação entre qualquer par de nós;

d.      Nenhum nó é ligado a si próprio;

e.       O número de nós da rede é superior ao número de ligações existentes em uma unidade, isto é, , onde nn representa o número de nós na rede e nl é o número de ligações.

As verificações referidas requerem um esforço computacional muito reduzido.

Posteriormente, são realizadas duas verificações adicionais, importantes para garantir o bom funcionamento do algoritmo (ver também 4.4.2.2):

a.       Não existem malhas na rede;

b.      Todos os nós estão interligados.

Estas verificações são claramente mais exigentes sob o ponto de vista computacional, pelo que são realizadas juntamente com a determinação do percurso hidráulico na rede, conforme se descreve em 4.4.2.1.

4.4.2       Cálculo hidráulico

4.4.2.1      Determinação de percurso hidráulico na rede

A rede é tratada como um grafo que não contém malhas (esta condição é verificada no decorrer deste algoritmo). É definido um ponto de entrada na rede a partir do qual se verificam todos os caminhos possíveis até que todos os nós tenham sido visitados. Para cada novo nó são calculadas as propriedades hidráulicas relevantes (pressão no nó e caudal e velocidade na ligação a montante). A rede é analisada dos seus nós extremos (aqueles que não estão ligados a outros nós a jusante) para o nó de montante.

O algoritmo de cálculo é, pois um algoritmo do tipo Breadth First Search (ver descrição em 3.4.5.4) (Black 2007) onde, para além da típica avaliação de percursos de um grafo se procede a cálculos hidráulicos intermédios.

O resultado desta pesquisa é a tabela MonJus_Res que contém uma lista de todas as ligações da rede, ordenadas de montante para jusante. Esta lista é útil em várias das verificações que serão efectuadas pelo LicA.

4.4.2.2      Verificações complementares

Caso o algoritmo do tipo Breadth First Search referido em 4.4.2.1 revele que existe algum nó com menos de um nó a montante, para além do nó inicial da rede, existem nós desligados no grafo, pelo que o processo de cálculo é interrompido e é emitido um aviso para o utilizador.

Se algum dos nós tiver mais do que um nó a montante, a rede contém malhas. Neste caso, pelas razões apontadas em 2.5.1, o cálculo da rede será igualmente interrompido, sendo emitido um aviso para o utilizador.

Estas verificações são fundamentais para garantir o bom funcionamento do processo de cálculo hidráulico da rede. Não são realizadas previamente uma vez que o seu custo, em termos de esforço de processamento adicional, é praticamente nulo depois de determinado o percurso hidráulico na rede.

4.4.2.3      Propriedades hidráulicas

As propriedades fundamentais que são calculadas neste algoritmo são caudais e pressões nos nós. São ainda registados os comprimentos de cada ligação (calculados a partir das coordenadas dos seus pontos extremos) e são contados separadamente os consumos a montante de cada nó aos quais se aplicam e aos quais não se aplicam o coeficiente de simultaneidade de caudais respectivamente.

Os caudais armazenados na tabela de resultados dividem-se nas seguintes categorias:

a.       Caudal acumulado resultante de consumos a jusante do nó ao qual será aplicado o coeficiente de simultaneidade regulamentar;

b.      Caudal acumulado resultante de consumos a jusante do nó ao qual não será aplicado o coeficiente de simultaneidade regulamentar. Os fluxómetros são dispositivos de utilização cujo caudal não deve ser afectado deste coeficiente, mas é possível estender esta propriedade a outros consumos que não ser pretenda reduzir (por exemplo, para prever o funcionamento de chuveiros colectivos). Em contrapartida, o regulamento prevê a utilização simultânea de um número limitado de fluxómetros sempre que exista mais de um instalado na rede:

Tabela 6 – Utilização simultânea de fluxómetros: Valores regulamentares aos quais se acrescenta a primeira linha da tabela (Paixão 1999)

Número de fluxómetros instalados

Em utilização simultânea

1 e 2

1

3 a 10

2

11 a 20

3

21 a 50

4

Acima de 50

5

Estes caudais são acumulados em campos separados de modo a permitir a correcta aplicação do coeficiente de simultaneidade apropriado. Os consumos individuais são destinados a um campo ou outro em função do valor do campo correspondente na tabela URC (ver 4.3.3.2).

A relação entre caudais acumulados e caudais de cálculo é definida, no DR nº 23/95, de forma gráfica. Assim, a sua utilização para efeitos de cálculo automático requer que seja efectuada uma aproximação numérica à curva de caudais de cálculo regulamentar. A seguinte expressão (Silva Afonso 2001), válida para a generalidade dos casos práticos concebíveis, permite converter caudais acumulados (Qa) em caudais de cálculo (Qcs):

Embora a bibliografia consultada indique que expressão é válida para valores de Qa entre 0.6 e 60 l/s, constata-se que a aproximação à curva regulamentar é satisfatória para valores inferiores a 0.6 l/s. Assim, adoptou-se esta expressão para valores de Qa superiores a aproximadamente 0.28 l/s. Para caudais inferiores a este valor, a aplicação da expressão conduziria a caudais de cálculo superiores aos caudais acumulados. Assim, optou-se por não aplicar coeficientes de simultaneidade a caudais acumulados inferiores a 0.28 l/s.

Na aplicação desenvolvida, os caudais de cálculo [m^3/s] são obtidos a partir da seguinte expressão:

Nesta expressão, o valor de Qcs é obtido da seguinte forma:

Na expressão , Q_0 representa o caudal acumulado correspondente a fluxómetros e Q_1 o caudal acumulado correspondente a outros dispositivos de utilização [m^3/s]. O coeficiente M_0 destina-se a reduzir o número de fluxómetros em funcionamento simultâneo e obtém-se a partir da seguinte tabela:

Tabela 7 – Coeficiente M_0

Número de fluxómetros instalados

M_0

1 e 2

1

3 a 10

2/ C 0

11 a 20

3/ C 0

21 a 50

4/ C 0

Acima de 50

5/ C 0

Nesta tabela, C_0 representa o número de fluxómetros existentes na rede a jusante do nó considerado.

As pressões na rede são calculadas para os valores extremos mínimo e máximo do seguinte modo:

a.       Pressões mínimas: Calculadas de jusante para montante, isto é, calculadas em função das pressões mínimas indicadas para cada nó onde se registam consumos na tabela Flow. Admite-se que os reservatórios prediais estão cheios até à cota mínima indicada na tabela Tanks. São adicionadas as perdas de carga registadas em cada ligação até à entrada na rede.

b.      Pressões máximas: Calculadas de montante para jusante, isto é, calculadas em função da pressão máxima indicada pela entidade responsável pela rede pública de abastecimento de água. Este valor é registado na tabela General_Properties. Admite-se que os reservatórios prediais estão cheios até à cota máxima indicada na tabela Tanks. São subtraídas as perdas de carga registadas em cada ligação até aos dispositivos de utilização.

c.       As perdas de carga são calculadas a partir da fórmula de Darcy-Weisbach:

, onde L representa o comprimento da canalização, D o seu diâmetro (ambos medidos em m) e U representa a velocidade média do escoamento na secção considerada. O coeficiente de atrito f pode ser calculado através da equação implícita de Colebrook-White, mas são frequentemente usadas equações explícitas cujos resultados são semelhantes ao daquela expressão. No LicA é utilizado o método de Serghides (Serghides 1984). Este método é aplicável para qualquer número de Reynolds, apresentando um erro máximo de 0.0031% relativamente à equação explícita de Colebrook-White, sendo provavelmente a mais precisa das equações explícitas usadas para a determinação do coeficiente de atrito f (Lester 2003), (Verma 2008).

Segundo o método usado, o coeficiente de atrito é dado pela seguinte expressão:

Os valores de A, B e C são obtidos da seguinte forma:

Nesta expressão, e representa a rugosidade do tubo [m], D o seu diâmetro [m] e Re o número de Reynolds.

Os resultados dos cálculos efectuados são armazenados nas tabelas temporárias Node_Res e Link_Res, cuja estrutura está indicada na Tabela 12 do Anexo B.

4.4.3       Verificações regulamentares

O LicA efectua, de forma automática, um conjunto de verificações de conformidade com disposições regulamentares, segundo o Decreto Regulamentar 23/95. O regulamento divide-se em artigos cuja verificação automática se considerou viável, artigos que indicam definições e regras gerais de dimensionamento que são incorporadas nos modelos de cálculo do LicA e artigos cuja verificação automática se considerou inviável. Apresenta-se, em anexo, uma tabela resumo contendo a classificação dos artigos do regulamento de acordo com as categorias referidas.

Todas as verificações são efectuadas após a avaliação preliminar dos dados (ver 4.4.1) e o cálculo hidráulico da rede (ver 4.4.2). Os resultados armazenados nas tabelas temporárias Node_Res, Link_Res e MonJus_Res simplificam de forma significativa algumas das tarefas seguintes.

4.4.3.1      Artigo 87º, Decreto Regulamentar 23/95

Artigo 87º - Concepção de novos sistemas (…)

2 - As pressões de serviço nos dispositivos devem situar-se entre 50 kPa e 600 kPa, sendo recomendável, por razões de conforto e durabilidade dos materiais, que se mantenham entre 150 kPa e 300 kPa.

Texto 6 – Artigo 87º, Decreto Regulamentar 23/95

O conteúdo da tabela Node_Res torna esta verificação uma simples comparação entre valores máximos e mínimos das pressões calculadas (convertidas para as unidades indicadas) e os valores extremos previstos no regulamento.

Caso forem detectados nós com pressões que se encontrem fora do intervalo [50 kPa, 600 kPa], é emitido um aviso de nível 5 – Reprovado – se as pressões estiverem fora do intervalo [150 kPa, 300 kPa], é gerado um aviso de nível 3 - Apreciação negativa: Verificação manual recomendada.

4.4.3.2      Artigo 90º, Decreto Regulamentar 23/95

Artigo 90º - Caudais instantâneos (…)

2 – Os valores mínimos dos caudais instantâneos a considerar nos dispositivos de utilização mais correntes são indicados no anexo IV.

Texto 7 – Artigo 90º, Decreto Regulamentar 23/95

A verificação da conformidade com este artigo é efectuada por comparação entre os valores correspondentes a cada um dos tipos de dispositivos de utilização contidos nas tabelas Device_Type e Flow.

Caso sejam detectados dispositivos de utilização cujos caudais instantâneos de projecto sejam inferiores aos indicados no Regulamento, será emitido um aviso de nível 5 – Reprovado – caso contrário será gerado um aviso de nível 0 – Aprovado.

4.4.3.3      Artigos 91º e 93º, Decreto Regulamentar 23/95

Artigo 91º - Coeficientes de simultaneidade (…)

4 – No anexo V é apresentada uma curva que, tendo em conta os coeficientes de simultaneidade, fornece os caudais de cálculo para um nível de conforto médio em função dos caudais acumulados, e pode ser utilizada para os casos correntes de habitação sem fluxómetros.

5 – No caso de instalação de fluxómetros, ao caudal de cálculo obtido de acordo com os números anteriores deve ainda adicionar-se o caudal de cálculo dos fluxómetros, a determinar de acordo com o indicado no anexo V.

Texto 8 – Artigo 91º, Decreto Regulamentar 23/95

A tabela Device_Type, na sua coluna URC, contém a indicação acerca da imposição regulamentar de afectar ou não o caudal instantâneo correspondente a cada tipo de dispositivo de utilização de um coeficiente de simultaneidade (de acordo com o número 4 do Artigo 91º).

A tabela Flow contém a informação fornecida pelo projectista acerca da utilização ou não de coeficientes de simultaneidade para cada dispositivo de utilização no cálculo hidráulico efectuado.

De acordo com o Regulamento, o caudal correspondente a fluxómetros deverá ser acumulado à parte dos caudais correspondentes a outros dispositivos de utilização (ver 4.4.2).

Caso se detecte que a tabela Flow contém registos de consumos aos quais o projectista associou uma indicação relativamente à utilização de coeficientes de simultaneidade contrária à indicada no Regulamento, será emitido um aviso de nível 4 – Reprovado com reservas, caso contrário o aviso criado será de nível 0 – Aprovado.

4.4.3.4      Artigo 92º, Decreto Regulamentar 23/95

Artigo 92º - Pressões na rede pública

Para efeitos de cálculos da rede predial devem ser fornecidos pela entidade gestora os valores das pressões máxima e mínima na rede pública no ponto de inserção naquela.

Texto 9 – Artigo 92º, Decreto Regulamentar 23/95

As pressões mínima e máxima na rede pública são armazenadas na tabela General_Properties.

Após a realização do cálculo hidráulico, são verificadas as pressões na rede, sendo estas comparadas com os valores fornecidos pela entidade gestora. Verifica-se se a pressão mínima indicada é suficiente para abastecer os dispositivos de utilização tendo em conta as pressões mínimas registadas na tabela Flow.

Note-se que a verificação de ocorrência de pressões excessivas é efectuada ao abrigo do Artigo 87º (ver 4.4.3.1).

Serão emitidos avisos de nível 5 – Reprovado – se forem detectados dispositivos para os quais a pressão mínima é insuficiente.

4.4.3.5      Artigo 94º, Decreto Regulamentar 23/95

Artigo 94º - Dimensionamento hidráulico

1 - O dimensionamento hidráulico da rede predial de água fria e quente é efectuado de acordo com os seguintes elementos:

a)      Caudais de cálculo;

b)      Velocidades, que devem situar-se entre 0,5 m/s e 2,0 m/s;

c)      Rugosidade do material.

2 - Nos ramais de alimentação de fluxómetros para bacias de retrete devem ter-se em atenção as pressões mínimas de serviço a cujos valores correspondem os seguintes diâmetros mínimos:

Pressão (kPa)

Diâmetro (milímetros)

200

25

80

32

50

40

Texto 10 – Artigo 94º, Decreto Regulamentar 23/95

O ponto 1 do presente artigo contém remete para uma verificação e para dias regras de cálculo. A verificação da sua alínea b) é efectuada directamente a partir dos resultados armazenados na tabela Link_Res. Se forem encontradas ligações onde se registam velocidades de escoamento fora do intervalo especificado no DR 23/95, serão emitidos avisos de nível 5 – Reprovado.

O Ponto 2 associa valores de pressões mínimas a diâmetros de canalizações que abastecem nós com uma finalidade específica. A tabela Node_Res contém valores de pressões mínimas em cada nó. Os nós são associados a consumos através da tabela Flow e estes são associados aos dispositivos de utilização através da tabela Devices, o que permite conhecer as pressões mínimas calculadas para cada bacia de retrete com fluxómetro. A tabela MonJus_Res indica a ligação que abastece cada nó, e esta informação é associada aos dados da tabela Pipes para conhecer o diâmetro da conduta correspondente ao nó a analisar. Depois de realizadas estas associações de tabelas, a verificação de conformidade regulamentar resulta directa.

Caso sejam detectadas inconformidades com o disposto neste ponto, serão emitidos avisos de nível 5 – Reprovado.

4.4.3.6      Artigo 95º, Decreto Regulamentar 23/95

Artigo 95º - Traçado

1 – O traçado das canalizações prediais de água deve ser constituído por troços rectos, horizontais e verticais, ligados entre si por acessórios apropriados, devendo os primeiros possuir ligeira inclinação para favorecer a circulação do ar considerando-se recomendável 0,5% como valor orientativo.

2 – A exigência de alguns acessórios pode ser dispensável caso se utilizem canalizações flexíveis.

3 – As canalizações de água quente devem ser colocadas, sempre que possível, paralelamente às de água fria e nunca abaixo destas.

4 – A distância mínima entre canalizações de água fria e de água quente é de 0,05 m.

Texto 11 – Artigo 95º, Decreto Regulamentar 23/95

O Ponto 1 do Artigo 95º impõe características geométricas específicas à rede. Ao impor troços rectos para o traçado das canalizações prediais de água, favorece a adopção de expressões vectoriais para a realização de operações geométricas de forma analítica.

Dado que uma rede predial pode incluir uma componente exterior ao edifício, a aplicação literal desta disposição regulamentar resulta na proibição da adopção de traçados de rede que acompanhem a morfologia do terreno, salvo nos casos em que este seja aproximadamente horizontal. Note-se que as condutas pertencentes às redes de distribuição pública de água não estão sujeitas a este tipo de restrições. Admite-se, pois, que isto constitua um lapso na redacção do regulamento pelo que se optou por dispensar desta verificação as condutas situadas no exterior dos edifícios. A informação contida no campo IsInside da tabela Pipes da base de dados permite identificar as condutas situadas no exterior.

A horizontalidade de um troço pode ser aferida através da relação entre o comprimento da projecção horizontal do segmento de recta correspondente e o comprimento do segmento referido. Procede-se de forma idêntica para avaliar a verticalidade do troço, mutatis mutandis. Admitindo que o segmento de recta é definido pelos pontos P e Q e que , onde os vectores  e  contêm as coordenadas cartesianas dos pontos correspondentes, as componentes vertical e horizontal do vector  são  e : ; . O comprimento do troço é dado por . Assim, as condições a verificar são as seguintes:

isto é, o troço é horizontal.

Para se avaliar se o troço é vertical, devem ser verificadas as seguintes condições:

Para avaliar a conformidade com o especificado no Ponto 1 do Artigo 95º deve ser cumprida uma das duas condições indicadas nas expressões e .

Os valores de tolh e de tolv devem ser especificados na tabela General_Properties. O primeiro corresponde à “ligeira inclinação” recomendada para os troços horizontais indicada no Regulamento Geral, o segundo a um factor de tolerância para eventuais erros resultantes de arredondamentos efectuados nas operações geométricas. Por defeito, os valores de tolv e de tolh são de 0.001 e de 0.005, respectivamente. A variável tolh assume o valor indicado (0.5%, de acordo com o regulamento) uma vez que, para ângulos pequenos, .

Se se detectar que a rede não cumpre as especificações regulamentares neste ponto, serão emitidos avisos de nível 5 – Reprovado.

O Ponto 2 do Artigo 95º não conduz a nenhuma verificação concreta.

O Ponto 3 conduz à realização das duas verificações seguintes:

a.       Deve haver paralelismo entre condutas de água quente e fria;

b.      Condutas de água quente não devem ser colocadas abaixo das condutas de água fria.

Serão novamente empregues expressões vectoriais para verificar as condições enunciadas.

Dados dois segmentos de recta (que representam duas canalizações), definem-se dois vectores de comprimento não nulo,  e , a partir das cotas dos seus pontos extremos. Os segmentos de recta são paralelos se se verificar a seguinte condição:

Mais uma vez, tendo em conta a possibilidade de ocorrerem pequenos erros nos cálculos em função dos arredondamentos efectuados ou introdução incorrecta de dados devida à utilização de ferramentas com interface gráfico, substitui-se a expressão acima pela seguinte:

Na expressão , tolp é uma constante definida na tabela General_Properties que, por defeito, assume o valor de 0.01.

Naturalmente, não basta verificar se duas canalizações são paralelas para se considerar que cumprem o estipulado neste artigo. Dois segmentos podem ser paralelos mas podem encontrar-se a uma distância considerável um do outro. É também possível que as rectas que contêm os segmentos paralelos estejam próximas uma da outra, mas que a distância medida entre os pontos mais próximos do segmento seja considerável. A Fig. 43 ilustra estes dois problemas. A conduta de água quente Q1.2 é paralela a todas as condutas de água fria representadas na vertical na figura, a saber, F1.1, F1.2, F1.3 e F2. Uma análise manual do problema levaria, contudo, a concluir correctamente que apenas o par de canalizações Q1.2 e F1.3 satisfazem as disposições impostas pelo ponto 3 do Artigo 95º (no que toca ao seu paralelismo).

Fig. 43 – Não é suficiente verificar se os troços são paralelos: é necessário medir distâncias entre as condutas.

Para procurar solucionar os problemas descritos, optou-se por proceder do seguinte modo, que tem produzido resultados satisfatórios nos testes efectuados:

a.       Para cada troço de canalização da rede de água quente, determinar quais os troços da rede de água fria que lhe são paralelos. Constrói-se assim uma lista de pares de canalizações que podem satisfazer a condição imposta.

b.      Adicionar à lista definida no ponto anterior um campo adicional onde se mede a distância entre as rectas que contêm os segmentos de recta correspondentes a cada troço. A determinação da distância entre as rectas referidas é efectuada segundo um processo que, simultaneamente, permitirá aferir se as rectas estão “demasiado longe” uma da outra para que possam satisfazer a disposição regulamentar e se as canalizações se desenvolvem a par. Este processo será descrito adiante.

c.       Eliminar os pares considerados não satisfatórios de acordo com o referido no ponto anterior.

A Fig. 44 ilustra a forma utilizada para medir a distância entre duas rectas: através da determinação da norma do vector , sobre a perpendicular comum às rectas.

Fig. 44 – Distância entre duas rectas (Sunday 2001)

O vector  é perpendicular aos vectores  e . Assim,

De acordo com a Fig. 44:

Substituindo o valor de  de acordo com a equação nas equações e , obtém-se um sistema de equações lineares em sc e tc cuja solução é (Poças Martins 2004):

Em que .

Quando , as rectas são paralelas. Nesta situação que, como se referiu, é particularmente relevante para o caso em apreço, há uma infinidade de perpendiculares comuns às duas rectas: Por qualquer ponto de qualquer uma das rectas é possível passar uma recta que seja perpendicular à outra, e que a intersecte. Sublinha-se que  é o ponto da recta com a direcção de  que está contido na perpendicular comum sobre a qual será medida a distância entre as rectas. Uma vez que, como se referiu,  pode ser qualquer, habitualmente faz-se , de onde resulta  (Sunday 2001). Neste caso, pretende-se verificar se as duas canalizações seguem a par. Assim, optou-se por fazer para obter . Se , as canalizações seguem a par uma vez que a perpendicular comum às duas rectas que passa pelo ponto médio do primeiro segmento intersecta o segundo. Caso contrário, verifica-se, de forma semelhante à indicada anteriormente, o valor de  para , admitindo-se que as canalizações seguem a par se . A Fig. 45 ilustra a razão pela qual é importante fazer esta segunda verificação no caso de . A perpendicular comum aos segmentos que passa por MQ, ponto médio do segmento correspondente à conduta de água quente (sc=0.5) não intersecta o segmento correspondente à conduta de água fria . Se a verificação efectuada for a inversa (partindo de MF, ponto médio do segmento correspondente à conduta de água fria), a intersecção dá-se para , pelo que se pode concluir que as condutas Q1.2 e F1.3 seguem a par.

Fig. 45 – Condutas a par

Assim, considera-se que os requisitos regulamentares são cumpridos se  e  ou  (calculados de acordo com as indicações dadas nos parágrafos anteriores) e se a distância entre as condutas não for considerada demasiado grande. A distância limite para a qual se aceita que os requisitos são cumpridos é registada na tabela General_Properties. Por defeito, esta distância é de 0.20 m.

Esta distância é dada por  que, por sua vez, pode ser representada pela seguinte expressão (Poças Martins 2004):

O significado de todas as variáveis que compõe a expressão indicada foi já descrito no presente subcapítulo.

Refere-se finalmente que se optou por dispensar esta verificação em duas situações distintas:

a.       Em condutas de pequena dimensão desta verificação, uma vez que a sua geometria é frequentemente determinada pelas características de dispositivos de utilização ou de algum elemento construtivo. A dimensão mínima das condutas para as quais será efectuada a verificação descrita é, por defeito, de 0.50 m, estando este valor definido na tabela General_Properties. Naturalmente, esta opção pode ser desactivada alterando o valor da dimensão mínima referida para 0.00 m.

b.      Em condutas consideradas suficientemente distantes de todas as outras. Por defeito, a distância a partir da qual se considera uma conduta individual dispensada desta verificação é de d = 0.50 m . Em rigor, são dispensadas de verificação todas condutas que, após a aplicação do algoritmo descrito acima, medindo a sua distância relativamente a todas as outras condutas, não conduzam a um único resultado com as seguintes características:

-        d 0.50 m

Nota: Este valor está definido na tabela General_Properties

-

-

Nota: nesta verificação, as distâncias às condutas da rede de água fria são medidas relativamente a todas as condutas da rede de água quente e as condutas da rede de água quente são medidas relativamente a todas as condutas da rede de água fria.

Ainda no Ponto 3 do Artigo 95º, indica-se que as canalizações de água quente nunca devem ser colocadas abaixo das condutas de água fria. Após a determinação de  (pertencente à conduta de água quente) e de  (pertencente à conduta de água fria), basta verificar a seguinte condição:

Em caso afirmativo, conclui-se que a conduta de água quente não passa por baixo da conduta de água fria, admitindo-se que verifica a imposição regulamentar. Esta verificação só é efectuada para condutas que não se encontrem a uma distância considerada excessiva uma da outra. A distância máxima para efectuar esta verificação é, por defeito, de 0.20 m, valor registado na tabela General_Properties.

Caso seja verificada a conformidade deste ponto, será emitido um aviso de nível 1 – Aprovado com reservas. Caso se constate que existem incumprimentos relativamente ao disposto no Regulamento, será emitido um aviso de nível 3 – Apreciação negativa: Verificação manual recomendada.

O Ponto 4 do Artigo 95º é de verificação imediata depois dos cálculos efectuados para a verificação dos pontos anteriores. Aos incumprimentos regulamentares detectados serão associados avisos de nível 4 – Reprovado com reservas.

4.4.3.7      Artigo 97º, Decreto Regulamentar 23/95

O Artigo 97º prevê um conjunto de disposições construtivas que têm como fim a prevenção contra a corrosão nas condutas metálicas da rede. Considera-se que a generalidade das disposições enunciadas neste artigo não é susceptível de ser adequadamente aferida por processos automáticos devido ao seguinte conjunto de razões:

a.       A generalidade das disposições regulamentares referidas neste artigo admite excepções (por exemplo, “as canalizações enterradas [devem] ser executadas, preferencialmente, com materiais não corrosíveis” ou “as canalizações metálicas [devem] ser colocadas, sempre que possível, não embutidas ou revestidas com materiais não agressivos”);

b.      As verificações a efectuar recaem sobre propriedades de componentes que são frequentemente omitidos em projectos de licenciamento (por exemplo, “o assentamento de canalizações não embutidas [deve] fazer-se com suportes de material inerte, do mesmo material, ou de material, de nobreza próxima inferior”);

c.       As verificações resultam numa aferição da compatibilidade entre projectos de especialidades distintas (por exemplo, “o assentamento de canalizações metálicas de redes distintas [deve] fazer-se sem pontos de contactos entre si ou com quaisquer elementos metálicos da construção”). A utilização de um modelo de informação “completo” permitiria contornar esta dificuldade através da utilização de algoritmos de verificação de conflitos entre projectos distintos, mas apenas à custa de um significativo acréscimo de esforço na introdução de dados e da utilização obrigatória deste tipo de modelos em todos os projectos de especialidades.

Em face das limitações expostas e da natureza das disposições construtivas referidas neste artigo, opta-se por efectuar uma verificação simples que alerta para a possibilidade de existirem especificações de projecto que possam gerar não conformidades com as alíneas a) e b) do nº 1 deste artigo. Assim, considera-se que é possível que existam não conformidades caso exista mais de um tipo de material distinto nas canalizações. Esta verificação é efectuada directamente a partir da informação contida na coluna Material_ID da tabela Pipes.

Reconhecendo-se que a verificação deste regulamento é incompleta, os avisos gerados são de nível 2 – Apreciação positiva: verificação manual recomendada – para projectos cujas canalizações são todas executadas com o mesmo material ou de nível 3 – Apreciação negativa: verificação manual recomendada – em caso contrário.

4.4.3.8      Artigo 98º, Decreto Regulamentar 23/95

Artigo 98º - Isolamento da rede de água quente

1 – As canalizações de água quente devem ser isoladas com produtos adequados (…).

Texto 12 – Artigo 98º, Decreto Regulamentar 23/95

O artigo 98º recomenda o isolamento térmico de canalizações de água quente. Embora sejam identificadas algumas exigências que devem ser respeitadas pelos materiais a usar para este fim, estes não são identificados no regulamento de forma a poderem ser avaliados em função da sua designação. Assim, optou-se por efectuar uma verificação directa da existência de isolamento térmico das canalizações de água quente a partir da sua propriedade IsThermIns que consta da tabela Pipes.

Caso sejam identificadas canalizações de água quente não isoladas termicamente, serão emitidos avisos de grau 5 – Reprovado – caso contrário, os avisos emitidos serão de grau 0 – Aprovado.

4.4.3.9      Artigo 99º, Decreto Regulamentar 23/95

Artigo 99º - Natureza dos materiais

1 – As tubagens e acessórios que constituem as redes interiores podem, entre outros, ser de cobre, aço inoxidável, aço galvanizado ou PVC rígido, este último no caso de canalizações de água fria não afectas a sistemas de combate a incêndios.

2 – Nas redes exteriores de água fria, as tubagens e acessórios podem ser de ferro fundido, fibrocimento, polietileno ou PVC rígido.

Texto 13 – Artigo 99º, Decreto Regulamentar 23/95

Este artigo elenca um conjunto de materiais autorizados para as tubagens e acessórios das redes interiores e exteriores. O regulamento não exclui a possibilidade de serem usados outros materiais.

A verificação é efectuada por comparação entre os valores previstos nas colunas Material_ID e IsInside da tabela Pipes e nas colunas ID e IsInside da tabela Allowed_Materials.

As canalizações executadas em materiais previstos neste artigo, para os fins especificados no regulamento, originam avisos de nível 0 – Aprovado. As restantes resultam em avisos de nível 3 – Apreciação negativa: verificação manual recomendada.

4.4.3.10   Artigo 102º, Decreto Regulamentar 23/95

Artigo 102º - Instalação de válvulas

É obrigatória a instalação de válvulas:

a.       De seccionamento à entrada dos ramais de introdução individuais, dos ramais de distribuição das instalações sanitárias e das cozinhas e a montante de autoclismos, de fluxómetros, de equipamentos de lavagem de roupa e de louça, do equipamento de produção de água quente, de purgadores de água e ainda imediatamente a montante e a jusante de contadores;

b.      De retenção a montante de aparelhos produtores-acumuladores de água quente e no início de qualquer rede não destinada a fins alimentares e sanitários;

c.       De segurança na alimentação de aparelhos produtores-acumuladores de água quente;

d.       Redutoras de pressão nos ramais de introdução sempre que a pressão seja superior a 600 kPa e ou as necessidades específicas do equipamento o exijam.

Texto 14 – Artigo 102º, Decreto Regulamentar 23/95

A verificação da instalação de válvulas a montante dos aparelhos é efectuada segundo um algoritmo do tipo Depth-First Search (Black 2008) a partir dos nós correspondentes aos aparelhos a analisar. Segundo este tipo de algoritmo, o grafo é pesquisado percorrendo sucessivamente cada um dos seus níveis antes de pesquisar os nós do mesmo nível do grafo (o oposto do que sucede nos algoritmos do tipo Breadth-First Search).

Neste caso, a pesquisa inicia-se no nó correspondente ao aparelho a avaliar, mas não se estende até ao último nível do grafo. A pesquisa por uma eventual válvula termina quando for encontrado um dos seguintes elementos:

a.       Um nó onde se encontrem três ou mais tubagens;

b.      Um depósito;

c.       Um outro dispositivo de utilização;

d.      Uma bomba.

A realização das verificações prévias referidas em 4.4.1 e o cálculo da rede efectuado em seguida, traduzido na determinação da tabela MonJus_Res simplificam significativamente esta pesquisa, bastando para o efeito seguir as ligações pela ordem indicada nesta tabela.

A tabela Valves contém a informação acerca do tipo de cada válvula e dos seus parâmetros de funcionamento hidráulico.

A pesquisa de válvulas a montante das instalações sanitárias e cozinhas é efectuada da seguinte forma:

a.       Identifica-se os nós correspondentes a dispositivos de utilização pertencentes a cada um destes espaços, dividindo-os por tipo de rede (de água fria e de água quente);

b.      Utilizando um algoritmo do tipo Depth-First Search, regista-se, para cada um dos nós identificados no ponto anterior, o percurso seguido pela água desde o ponto de entrada na rede;

c.       Para cada uma das redes, intersecta-se os conjuntos de nós definidos na etapa anterior de forma a obter o percurso no grafo comum ao abastecimento de todos os nós;

d.      Identifica-se o nó que se encontra mais a jusante do percurso determinado no ponto anterior e o primeiro elemento a montante desse nó que seja de um dos seguintes tipos:

i.            Um nó onde se encontrem três ou mais tubagens;

ii.            Um depósito;

iii.            Um dispositivo de utilização que não contenha o nó a partir do qual se iniciou a pesquisa;

iv.            Uma bomba.

e.       Verifica-se se, entre os elementos identificados no ponto anterior se encontra uma válvula de seccionamento, de acordo com a disposição regulamentar cujo cumprimento se está a verificar.

Caso não sejam encontradas as válvulas previstas no Artigo 102º do regulamento, serão emitidos avisos de nível 5 – Reprovado.

4.4.3.11   Artigo 106º, Decreto Regulamentar 23/95

O número um deste artigo é susceptível de verificação automática. Cada consumidor individual deverá dispor de um contador, colocado isoladamente ou em bateria. A estrutura da tabela Spaces, em particular a sua coluna Fraction_ID permite dividir a rede em fracções, pelo que resta verificar se para cada fracção existe um e só um contador. A estrutura da tabela Devices, depois de associada à tabela Spaces, permite que esta contagem seja efectuada directamente.

Caso exista um único contador por fracção, será gerado um aviso de nível 0 – Aprovado – caso contrário, será emitido um aviso de nível 5 – Reprovado.

4.4.3.12   Artigo 108º, Decreto Regulamentar 23/95

De acordo com o referido em 3.4, embora se constate que a instalação de reservatórios prediais resulta em significativas vantagens relacionadas com a fiabilidade do abastecimento de água, o presente artigo não o permite, excepto “em casos devidamente autorizados pela entidade gestora, nomeadamente quando as características do fornecimento por parte do sistema público não ofereçam as garantias necessárias ao bom funcionamento do sistema predial, em termos de caudal e pressão”.

Assim, um sistema de verificação automática de projectos deverá limitar-se a gerar um aviso caso o projecto contenha alguma instalação complementar deste tipo. No LicA, esse aviso será de nível 3 – Apreciação negativa: Verificação manual recomendada. Caso contrário, o aviso será de nível 0 – Aprovado.

Dado que todos os eventuais reservatórios estão descritos na tabela Tanks, a sua contagem é simples.

4.5    Aplicações externas

4.5.1       Integração com base de dados

A estrutura da base de dados LicA, descrita nos pontos anteriores e no Anexo B, contém não só o modelo paramétrico da rede cujo projecto se pretende submeter a uma verificação regulamentar mas também um conjunto de subrotinas que permitem efectuar essa verificação. Assim, de um ponto de vista funcional, a base de dados pode ser usada por si só. É funcionalmente independente de qualquer outra aplicação externa embora possa aceitar inputs provenientes de outros programas e lhes permita o acesso à informação que contém. Em síntese:

a.       A base de dados funciona como repositório de informação, contém mecanismos que asseguram a integridade dos dados e inclui todas as rotinas que permitem a sua alteração – não só a alteração do modelo paramétrico mas também a geração de tabelas de resultados de cálculos efectuados. Tanto os dados, como os resultados, como as referidas rotinas só podem ser acedidas através de aplicações exteriores (nomeadamente sistemas de gestão de bases de dados) e assumem a forma de tabelas e de comandos SQL.

b.      As aplicações externas constituem uma interface para a informação e para as rotinas que compõem a base de dados. A base de dados só pode ser alterada usando as rotinas nela contidas para a edição do modelo paramétrico da rede ou para a realização de cálculos. A informação geométrica contida na base de dados permite o desenvolvimento de aplicações com interfaces gráficas elaboradas.

Como foi referido em 2.3.5.4.2, este tipo de arquitectura de sistema apresenta diversas vantagens, entre as quais a de permitir o desenvolvimento de aplicações cliente ligeiras, com permissões para aceder à informação contida na base de dados, mantendo nesta toda a lógica de negócio. Qualquer alteração no processo de verificação regulamentar de um projecto, por exemplo, pode ser efectuada directamente na base de dados sem necessidade de modificar o funcionamento das aplicações cliente.

Assim, e em resumo, neste projecto as aplicações cliente assumem um papel importante, permitindo o acesso dos utilizadores ao modelo, mas não essenciais no que toca à organização conceptual do modelo de informação.

4.5.2       Aplicação com interface gráfica desenvolvida: LiCAD

4.5.2.1      Apresentação

Foi desenvolvida, de raiz, uma interface gráfica para a base de dados LicA.

Esta aplicação acede directamente à base de dados usando uma ligação ODBC (Open Data Base Connectivity) e permite ao utilizador correr as rotinas de cálculo e de verificação regulamentar nela contidas.

O programa permite aceder, de forma gráfica, a funções de criação e edição de modelos, de cálculo hidráulico, de verificação regulamentar e de geração de documentos de trabalho.

Entre os documentos gerados pela aplicação contam-se peças escritas e desenhadas, nomeadamente:

a.       Plantas e cortes;

b.      Esquemas isométricos da rede;

c.       Relatórios de cálculo hidráulico (caudais de cálculo e pressões na rede, bem como indicação de velocidades registadas);

d.      Medições;

e.       Relatório de verificação regulamentar (incluindo tabela resumo e representação gráfica dos resultados das verificações efectuadas).

Na sequência do diagrama apresentado na Fig. 40, ilustra-se na Fig. 46 as funções executadas pela aplicação LiCAD e a relação desta com a base de dados LicA.

Fig. 46 – Relação entre LiCAD e LicA

4.5.2.2      Desenvolvimento

O LiCAD foi desenvolvido em Visual Basic 2008 usando objectos ADO.NET para aceder à base de dados. As interfaces gráficas são elaboradas usando a tecnologia WPF – Windows Presentation Foundation.

Relativamente à tecnologia anteriormente existente para o desenvolvimento de interfaces gráficas para os sistemas operativos Windows – Windows Forms – a tecnologia WPF disponibiliza um conjunto de ferramentas mais poderosas (MacDonald 2008). A tecnologia WPF está baseada na tecnologia DirectX, uma interface de programação de aplicações muito utilizada em aplicações exigentes do ponto de vista gráfico uma vez que é suportada pela generalidade das placas gráficas actuais. Assim, torna-se possível utilizar efeitos gráficos sofisticados sem a sobrecarga de recursos do sistema que ocorreriam se fosse utilizada a tecnologia Windows Forms.

O LiCAD tira partido das vantagens oferecidas pela tecnologia WPF, não só na representação tridimensional de componentes da rede (ligações e nós) mas também na manipulação dos modelos gráficos representados – realização de operações de rotação, translação e ampliação.

Embora ofereça um conjunto significativo de vantagens relativamente a tecnologias concorrentes, a WPF apresenta também uma desvantagem importante: é uma tecnologia muito jovem, com uma biblioteca de objectos tridimensionais desenvolvidos ainda reduzida e com uma oferta limitada de representações de sólidos. Com efeito, na ausência de funções internas para representar sólidos elementares (inclusivamente esferas ou cilindros) torna-se necessário recorrer a bibliotecas de funções externas desenvolvidas para a definição destes elementos geométricos – designados frequentemente de formas primitivas (Petzold 2007). Foi este o processo seguido no desenvolvimento da aplicação LiCAD.

A rede é representada por um conjunto de nós e de ligações aos quais são associadas as respectivas propriedades, de acordo com a descrição efectuada em 4.3. Tira-se partido das vantagens oferecidas pela plataforma WPF na representação gráfica destas propriedades. As funções de representação 3D disponibilizadas permitem a associação de diferentes tipos de materiais, com cores e texturas distintas, aos elementos desenhados. Na óptica dos utilizadores da aplicação desenvolvida, e dado que é utilizado um tipo de material único para a representação gráfica de todos os componentes da rede, isto permite estabelecer um código de cores para cada uma das propriedades associadas a representar.

No que toca à produção de peças desenhadas, a tecnologia WPF, permite a representação gráfica de objectos definidos no programa – isto é, separa conceptualmente o objecto da sua representação gráfica – segundo sistemas de projecção distintos. A representação é efectuada tendo em conta a posição definida para o observador e o sistema de projecção a utilizar. A interface gráfica disponibilizada ao utilizador da aplicação LiCAD recorre à projecção central ou cónica para representar a rede para as funções gerais de criação e edição, bem como para a consulta das suas propriedades físicas e dos resultados de cálculo obtidos. Para a representação em planta ou em axonometria, faz-se uso de um sistema de projecção cilíndrico ou ortogonal (Borges 1986). Em ambos os casos, o aspecto da rede depende ainda do tipo de iluminação definida. Embora seja possível utilizar luz solar ou luz de vela (Borges 2003) para a iluminação da rede, nesta aplicação faz-se uso à primeira, por defeito.

Todos os restantes componentes da interface gráfica – incluindo os comandos, as tabelas e os campos de texto – são também representados usando a plataforma WPF. Uma vez que esta é uma tecnologia extremamente recente, alguns destes componentes (por exemplo os componentes associados à representação de dados) estão disponíveis ao público apenas em versões experimentais.

4.5.2.3      Interface

Segue-se uma breve descrição da interface e das funções mais importantes realizadas pela aplicação desenvolvida.

A interface principal divide-se nos seguintes quatro espaços distintos (ver Fig. 47):

a.       Definir modelo

Onde o utilizador pode definir e consultar as propriedades dos elementos que compõem a rede de distribuição predial de água. O código de cores permite distinguir a rede de água quente da rede de água fria. É ainda possível definir a posição do observador e o sistema de projecção a utilizar de modo a obter perspectivas realistas da rede ou, em alternativa, plantas e axonometrias.

b.      Análise hidráulica

Permite correr a rotina, incluída na base de dados LicA, de cálculo hidráulico da rede. Os resultados são apresentados segundo um código de cores. Os parâmetros que podem ser consultados são o caudal de cálculo, a velocidade e o comprimento de cada ligação e as pressões máxima e mínima e o caudal de cálculo em cada nó.

c.       Verificação regulamentar

Permite correr a rotina de verificação regulamentar da base de dados LicA. Representa-se, de acordo com um código de cores, o resultado das verificações efectuadas relativamente a cada um dos componentes da rede. Por defeito, é apresentado o resultado mais desfavorável tendo em conta a classificação descrita em 4.3.3.4.

d.      Documentos

Produz um conjunto de documentos a partir de pesquisas realizadas sobre a base de dados LicA. Por defeito, é possível obter três tipos de documentos diferentes: medições, relatórios de cálculo hidráulico e relatórios de verificação de conformidade regulamentar.

Fig. 47 - Imagens da aplicação LiCAD: Ecrã de definição e consulta das características dos componentes da rede

Fig. 48 – Imagens da aplicação LiCAD: Ecrã de análise hidráulica

Fig. 49 - Imagens da aplicação LiCAD: Ecrã de verificação regulamentar

4.5.2.4      Outputs da aplicação LiCAD

4.5.2.4.1            Apresentação

Apresenta-se, neste ponto, um conjunto de resultados produzidos pela aplicação desenvolvida. Os resultados dividem-se em representações gráficas – bidimensionais e tridimensionais – e representações escritas – tabelas e relatórios.

Sublinha-se o facto de que, dado que a aplicação não faz mais do que realizar pesquisas sobre um modelo paramétrico, os resultados podem ser considerados como simples vistas sobre o modelo. Isto é válido tanto para as peças desenhadas como para as peças escritas produzidas.

As representações apresentadas nos pontos seguintes resultam de um exemplo simples criado para o efeito, não de um projecto real.

4.5.2.4.2            Representações gráficas

As representações gráficas produzidas podem ser divididas em “imagens estáticas” que correspondem às tradicionais peças desenhadas de projecto – plantas, cortes e axonometrias – e imagens dinâmicas correspondentes à interface da área de trabalho (Fig. 47). Os modelos gerados podem ser representados com recurso quer à projecção central, quer à projecção cilíndrica. Considera-se que a projecção central, por conduzir a imagens mais realistas, é mais adequada para a construção e para a consulta do modelo e dos resultados representados de forma gráfica. A projecção cilíndrica deve ser utilizada na produção de plantas, cortes, esquemas isométricos, etc.

Fig. 50 – Representação parcial de um modelo usando (a) projecção central e (b) projecção cilíndrica

Em ambos os casos é possível definir os parâmetros geométricos que conduzem à representação, quer de forma aproximada (usando o rato do computador), quer de forma rigorosa, especificando a posição do observador, a orientação da câmara virtual, a direcção das linhas a representar na vertical, etc. Representa-se, na Tabela 8, um conjunto de parâmetros a utilizar para a representação de peças desenhadas de projecto com recurso à projecção cilíndrica.

Tabela 8 – Parâmetros geométricos a utilizar na produção de peças desenhadas

Tipo de representação

Projectantes (vector)

Vertical (vector)

Planta

Cortes e Alçados

(x e y definidos de modo a que o vector seja perpendicular aos planos que contêm os elementos a representar em verdadeira grandeza)

Esquema isométrico

Embora esta função não esteja incluída na presente versão da aplicação, considera-se que, para a produção de algumas peças desenhadas de projecto, pode haver vantagens em exportar, em formato DXF, as projecções ortogonais correspondentes às várias vistas sobre o modelo para a aplicação gráfica usada para representar os desenhos de arquitectura. A generalidade das aplicações gráficas utilizadas para este efeito pode ser acedida por programas externos pelo que a sobreposição da representação gráfica da rede aos desenhos de arquitectura é uma tarefa relativamente simples de programar. Em alternativa, a aplicação LiCAD poderá ser expandida de modo a importar os desenhos de arquitectura.

Embora a aplicação desenvolvida permita elaborar representações rigorosas do modelo desenvolvido, considera-se que não é uma ferramenta indicada para a preparação das tradicionais peças desenhadas de projecto. Com efeito, constata-se que as peças desenhadas não são representações rigorosas de um produto de construção dado que incluem simplificações (omissões de pormenores), distorções (de modo a permitir a representação de elementos que não seriam visíveis caso fossem desenhados de forma rigorosa) e outras modificações. Assim, uma vez que os modelos paramétricos não assumem actualmente o papel de formatos de representação padrão, a intervenção humana na elaboração e na interpretação de desenhos que não constituem representações rigorosas dos produtos a construir continua a ser essencial.

4.5.2.4.3            Representações escritas

4.5.2.4.3.1     Relatórios e textos dinâmicos

Tal como sucede com as representações gráficas, também as representações escritas podem ser divididas em “relatórios” que resultam de pesquisas realizadas sobre a base de dados e que resumem os dados relativos aos vários elementos da rede e “textos dinâmicos” que são apresentados quando o utilizador selecciona algum dos componentes individuais da rede.

No parágrafo anterior, colocou-se a palavra relatórios entre aspas para indicar que se remete aqui para relatórios de bases de dados – database reports na designação anglo-saxónica corrente (Powell 2006), (Laudon, Laudon 2002) – e não a outro tipo de relatórios escritos.

Foram designados por textos dinâmicos aqueles que são apresentados sobre comandos interactivos da interface. Têm como função, não só a apresentação das propriedades dos componentes da rede, mas também permitir a alteração do modelo, acedendo-se para tal às funções existentes na base de dados.

Fig. 51 – Texto dinâmico: Verificação da conformidade regulamentar de um dispositivo de utilização

Como se referiu, os relatórios disponibilizados pela aplicação, por defeito, são as medições e os relatórios de verificação de conformidade regulamentar.

Dado que há um número significativo de pesquisas potencialmente relevantes que podem ser efectuadas sobre a base de dados, a aplicação foi desenvolvida de modo a permitir a fácil inclusão de novas pesquisas, às quais corresponderão novos documentos.

4.5.2.4.3.2     Relatórios de verificação de conformidade regulamentar

Estes relatórios são simples listagens dos resultados da avaliação realizada pela rotina de verificação regulamentar incluída na base de dados LicA. A aplicação LiCAD permite organizar esta informação por componente da rede, por artigo do Regulamento ou por gravidade da não conformidade, por exemplo.

Fig. 52 – Relatório de verificação de conformidade regulamentar (imagem parcial)

4.5.2.4.3.3     Medições

Na construção civil, o acto de medir consiste na determinação analítica e ordenada dos diferentes tipos de trabalhos cujas medidas devem ser obtidas a partir dos desenhos e das condições técnicas de projectos ou de trabalhos executados em obra (Pacheco 1997). Na ausência de normas oficiais nacionais em vigor, o documento técnico que serve usualmente de referência à realização de medições (Fonseca 1998) não é de aplicação obrigatória. A informação armazenada na base de dados desenvolvida permite a geração automática de um mapa de medições que cumpre a generalidade das regras definidas na publicação referida, de acordo com as observações seguintes:

a.       As quantidades de canalização são avaliadas a partir das dimensões dos troços de tubagem indicados pelo utilizador, incluindo os acessórios dos tubos, conforme a publicação de referência. A medição é realizada em [m].

b.      As tubagens são agrupadas por tipo de material e por diâmetro. Não é possível especificar, de forma automática, as seguintes características das tubagens, previstas na publicação de referência:

i.            Tipo de ligação dos tubos;

ii.            Condições de execução (isto é, canalizações enterradas ou em elevação).

c.       Os dispositivos de utilização e os acessórios da rede são medidos à unidade [Un], conforme a publicação de referência, sendo associados em função da sua classificação de acordo com o ponto 4.3.2.3.

d.      As bombas e os reservatórios prediais são apresentados individualmente.

e.       As válvulas são agrupadas de acordo com o referido em 4.3.2.4.3. A publicação de referência é omissa a este respeito.

As medições são uma peça escrita de projecto pelo que as vantagens inerentes à sua elaboração por processos automáticos são evidentes. Ainda assim, importa referir um conjunto de razões menos óbvias que tornam a preparação automática desta peça escrita interessante:

a.       As medições podem ser organizadas por artigos, constituindo assim um mapa de trabalhos e quantidades. Aos artigos do mapa de trabalhos e quantidades podem ser associados a preços unitários, obtendo-se assim um orçamento. O orçamento é uma peça escrita importante, não só no contexto da relação comercial entre dono da obra e empreiteiro, mas também no âmbito da avaliação de custos da obra, a efectuar por parte da entidade responsável pelo licenciamento: num processo de licenciamento, o custo para o requerente é calculado em função do custo previsto para a obra. Como se referiu anteriormente, esse custo é avaliado de duas formas independentes: pela declaração do dono da obra (que tem vantagens óbvias na sua subavaliação), que faz parte do processo de licenciamento preparado pelo projectista, e pela avaliação da entidade licenciadora, que calcula o custo a partir de custos estimados por unidade de área útil do edifício. A geração automática de um mapa de medições, associado a um conjunto de custos unitários torna a estimativa de custos reais da rede mais expedita e mais precisa.

b.      Existe um conjunto de aplicações informáticas que produzem, de forma automática, especificações técnicas a partir de um conjunto de artigos de um mapa de trabalhos e quantidades, pelo que a geração deste documento se torna importante por motivos de interoperabilidade. De entre as aplicações que produzem especificações técnicas, destaca-se:

i.            A e-SPECS (http://www.e-specs.com/), por contar com uma biblioteca de especificações vasta e com forte aceitação entre a comunidade técnica norte americana, conferida por anos de desenvolvimento permanente e por interagir directamente com modelos de informação na construção elaborados segundo as especificações IFC. Estas especificações são baseadas em documentos técnicos norte-americanos, pelo que a sua aplicabilidade aos projectos nacionais se torna limitada.

ii.             A nível nacional, o programa PRONIC (Sousa, Moreira, Manso et al. 2007), (Sousa, Moreira, Mêda et al. 2007), por ser baseado nas normas técnicas aplicáveis em Portugal, e por permitir uma composição extremamente flexível do texto das especificações técnicas, em função das características do trabalho a descrever. A base de dados do PRONIC é muito recente o que, por um lado confere actualidade aos seus conteúdos, mas que, por outro, não permite aferir o seu grau de aceitação junto da comunidade técnica nacional.

Esta ligação do mapa de medições a aplicações externas não foi ainda desenvolvida, à data de publicação deste trabalho, mas a estrutura de dados adoptada permite afirmar que será uma tarefa de programação relativamente simples de efectuar, ainda que possa implicar a introdução de informação adicional por parte do utilizador.

4.5.2.4.3.4     Relatório de Cálculo

É possível gerar uma tabela resumo dos cálculos efectuados contendo informação acerca dos caudais, velocidades e pressões ao longo da rede (ver Fig. 53).

Fig. 53 – Relatório de cálculo (imagem parcial)

4.6    Apresentação do projecto à entidade licenciadora

O projectista pode desenvolver o modelo de informação usando aplicações externas (como o LiCAD) o que lhe permite realizar verificações de conformidade localmente (no seu próprio ambiente de trabalho). Embora seja possível partilhar a base de dados resultante, realizando uma cópia de segurança da informação que contém e enviando esta cópia por correio electrónico (ou por outro meio), não se considera que este seja o processo ideal.

Há cerca de uma década que o formato padrão para a partilha de dados na Web é o XML (Libicki et al. 2000). Actualmente, os SGBD (Sistemas Gestores de Bases de Dados – ver 2.3.5.4.3.3) mais populares, como o SQL Server, permitem a importação e exportação de dados no formato XML. Existem ainda diversas aplicações independentes que permitem a partilha de dados entre ambos os formatos. Assim, e uma vez que a base de dados LicA foi desenvolvida em SQL Server, a obtenção de um schema XML (isto é, uma descrição da estrutura de um ficheiro XML) correspondente ao subconjunto de dados contidos na base de dados que corresponde à informação de projecto é uma tarefa relativamente simples.

Considera-se, pois, que a submissão de processos de construção representados com recurso ao modelo proposto deve ser efectuada usando ficheiros em formato XML.

Apresenta-se, no Anexo C, o formato de dados proposto para a apresentação do projecto à entidade licenciadora.

Fig. 54 – Utilização de XML para a submissão de projectos

4.7    Avaliação do modelo desenvolvido

4.7.1       Introdução

Apresenta-se no presente capítulo uma discussão acerca de alguns aspectos considerados relevantes no modelo descrito no capítulo anterior:

a.       Exemplo de aplicação;

b.      Alterações no fluxo de trabalho: Discussão acerca de potenciais vantagens e desvantagens associadas à utilização do modelo.

4.7.2       Exemplo de aplicação

Apresenta-se, no presente subcapítulo, uma aplicação das ferramentas desenvolvidas a um projecto real.

O projecto, já licenciado, diz respeito a uma habitação unifamiliar a construir num concelho do norte do país. A moradia desenvolve-se em 2 pisos – Piso 0 e Piso 1, possuindo cobertura plana. Existem 3 instalações sanitárias e uma cozinha no piso 1 e uma lavandaria no piso 0. A alimentação de água ao edifício será efectuada a partir da rede pública existente.

O contador localiza-se junto ao portão de entrada, como se evidencia nas peças desenhadas apresentadas. A entrada de água, a partir da rede pública, faz-se ao nível do Piso 0.

As condutas situadas no exterior são executadas em polietileno. As da rede interior são em aço inoxidável, sendo a rede de água quente isolada termicamente.

Fig. 55 – Planta do Piso 0

Fig. 56 – Planta do Piso 1

Fig. 57 – Esquema “isométrico”

Fig. 58 – Esquema isométrico gerado pela aplicação LiCAD

O resultado da aplicação do algoritmo de verificação regulamentar ao projecto apresentado pode ser observado na Fig. 59. São detectados erros correspondentes à falta de válvulas a montante de máquinas de lavar louça e roupa, do aparelho produtor-acumulador de água quente e do contador. Detectou-se ainda a ausência de uma válvula de seccionamento a jusante do contador. Todos os erros detectados dizem respeito ao Artigo 102º do DR 23/95.

Fig. 59 – Resultado da verificação regulamentar efectuada. Nota: as não conformidades detectadas foram destacadas posteriormente sobre as imagens geradas pelo LiCAD.

O Projecto foi corrigido, de acordo com as indicações do programa, tendo sido inseridas as válvulas em falta de acordo com as disposições regulamentares. Conforme se pode constatar na Fig. 60, os únicos elementos do modelo relativamente aos quais é emitida uma apreciação negativa – um aviso de nível 3 – são agora os dispositivos de utilização. Nos nós assinalados, a pressão máxima excede o valor recomendado no Artigo 87º do DR 23/95 de 300 kPa. Segundo o cálculo efectuado, as pressões de serviço nos dispositivos de utilização variam entre os 370 kPa e os 410 kPa ao longo da rede, ainda assim claramente aquém do valor máximo permitido de 600 kPa. Considera-se, pois, que o projecto cumpre o disposto no nº DR 23/95.

Fig. 60 – Verificação regulamentar: Perspectiva (imagem parcial)

Fig. 61 – Medições efectuadas de forma automática

Fig. 62 – Cálculo hidráulico (imagem parcial)

4.7.3       Alteração de fluxo de trabalho. Ameaças e oportunidades.

4.7.3.1      Introdução

Conforme se referiu em 2.3.5.3, a adopção de modelos de informação para construção por parte dos projectistas requer alterações significativas relativamente às práticas tradicionais no sector. Embora se considere que estas alterações produzirão, em geral, vantagens para os intervenientes que adoptem estas tecnologias, admite-se que a mudança não é isenta de riscos nem de inconvenientes.

De acordo com o referido no presente subcapítulo, considera-se que algumas das ameaças mais significativos apresentadas pelos modelos são colocadas igualmente por muitas outras aplicações comerciais actualmente disponíveis para a indústria da construção – as “soluções completas para projecto”.

São apresentadas em seguida algumas vantagens associadas à adopção do modelo proposto.

Não se pretende repetir aqui a referência às vantagens e inconvenientes genéricas dos BIM (ver 2.3.5.3) embora estas sejam aplicáveis ao modelo desenvolvido. Serão abordados aspectos específicos do modelo LicA, relacionados com as suas características enquanto modelo de representação e com as suas funções de cálculo.

4.7.3.2      Ameaças

4.7.3.2.1            Automatização da elaboração de projectos

Desde a introdução de métodos automáticos na construção, em particular na elaboração de projectos, têm vindo a ser discutidos alguns potenciais inconvenientes que lhes estarão associados. É evidente que algumas das exigências, quer funcionais, quer estéticas, colocadas aos edifícios de hoje não podem ser abordadas, de forma viável, sem a utilização de ferramentas de cálculo automático. As “soluções completas para projecto”, que realizam funções de cálculo e de representação de forma automática merecem, contudo, uma análise específica.

Assim, embora não seja um assunto particularmente recente, a discussão acerca das ameaças associadas à utilização de aplicações informáticas na construção tem ganho uma relevância cada vez maior à medida que as potencialidades destas têm aumentado. Esta maior relevância é justificada, em larga medida, por alguma perda de controlo dos técnicos relativamente às aplicações informáticas, à medida que estas últimas passam a realizar tarefas que anteriormente eram da responsabilidade dos primeiros. Antes da introdução de métodos automáticos, os projectos de engenharia resultavam de tarefas de cálculo e de representação realizadas de forma manual. Os primeiros processos a serem automatizados foram os processos de cálculo, seguindo-se os de dimensionamento. Limitações no hardware e software deixaram para último a automatização dos processos de representação que, actualmente, já estão integrados em muitas das aplicações comerciais de projecto.

Em síntese, projectos que outrora eram concebidos e representados de acordo com regras específicas adoptadas por cada técnico individual podem ser, actualmente, elaborados usando regras padrão sobre as quais os técnicos têm cada vez menos controlo.

Esta diminuição do controlo dos técnicos sobre algumas das tarefas que antes lhes competiam, por um lado, e o aumento de eficiência associado à utilização de métodos automáticos, por outro, justificam a existência de dois pontos de vista antagónicos que coexistem entre a comunidade técnica:

a.       Por um lado existe a tendência para considerar que os métodos automáticos podem ser nocivos para a qualidade do projecto. Este argumento poderá ser suportado por três razões principais:

i.            Os métodos automáticos conduzem à perda de controlo sobre o processo de cálculo: As aplicações informáticas funcionam frequentemente como “caixas negras”, cujos inputs e outputs são conhecidos, mas cujo funcionamento não é completamente aparente para o utilizador. A ocorrência, já documentada, de discrepâncias entre resultados obtidos por processos manuais e por processos automáticos agrava a desconfiança com que as “soluções completas para projecto” são encaradas por uma parte significativa da comunidade técnica.

ii.            Estes métodos tendem a criar condições para a ocorrência e para a persistência de erros: Uma introdução errada de dados, aliada à menor intervenção técnica (humana), permitem que um erro persista nos cálculos sem ser notado. Admite-se que este problema possa ser agravado pelo motivo indicado no ponto seguinte.

iii.            As “soluções completas para projecto” permitem o acesso à actividade a técnicos menos habilitados e/ou experientes: Estas aplicações criaram um segmento de mercado caracterizado por custos baixos mas também por uma menor garantia de qualidade. Embora a existência de técnicos que exercem funções de projecto sem as devidas habilitações não seja uma realidade recente, o surgimento de soluções completas para projecto” permite, em simultâneo, intensificar e mascarar o problema.

b.      Inversamente, é possível argumentar que os erros humanos associados às práticas tradicionais, nomeadamente a entrada repetida de dados, erros de cálculo e a dificuldade em proceder a alterações no modelo de cálculo são potencialmente mais graves do que aqueles criados pela má utilização de aplicações informáticas.

Embora se admita que ambos os pontos de vista se sustentam em argumentos válidos, considera-se que o elemento chave desta discussão é humano: Em larga medida, não representam apenas duas visões opostas acerca das vantagens e inconvenientes dos métodos automáticos, mas antes uma opinião única acerca da atitude do técnico perante o acto de projectar. Com efeito, constata-se que é possível produzir projectos “cuidados” e “descuidados”, tanto por processos manuais como por processos automáticos pelo que as aplicações informáticas não são o factor fundamental na elaboração de projectos de boa qualidade. Considera-se, pois, que esta discussão se desenvolve em torno de questões técnicas, mas também deontológicas.

As aplicações informáticas oferecem, contudo, uma vantagem significativa relativamente aos processos manuais: os seus resultados são mais fáceis de auditar e por isso os processos que lhes estão subjacentes são mais susceptíveis de serem aperfeiçoados no futuro.

O modelo de representação desenvolvido neste trabalho pode ser usado independentemente do processo de cálculo escolhido pelo projectista. Embora tenham sido desenvolvidos algoritmos de cálculo automático, admite-se que um projecto possa ser desenvolvido por qualquer método, sendo depois a sua representação efectuada de acordo com as regras especificadas. Naturalmente, esta opção anula algumas das vantagens inerentes à utilização de modelos de informação na construção, embora continue a permitir uma partilha de informação mais eficiente relativamente àquela que resulta da adopção, quer de meios manuais, quer de “soluções completas para projecto”. De acordo com o referido ao longo deste trabalho, um BIM contém mais informação do que as peças de projecto tradicionais, pelo que a sua adopção como forma de representação tem um valor que não se esgota na automatização de processos de cálculo.

4.7.3.3      Oportunidades

4.7.3.3.1            Vantagens de curto prazo

São referidas, neste ponto, apenas as potenciais vantagens que poderão ser obtidas a curto prazo pela adopção do modelo proposto. Conforme se referiu em 2.3.5.3, considera-se que a introdução de modelos de informação na construção resultará em vantagens significativas de segunda ordem relacionadas com a automatização de processos de trabalho ao longo do processo construtivo. Naturalmente, estas vantagens só poderão ser atingidas se os BIM forem aplicados a todas as fases do processo construtivo de modo a assegurar a interoperabilidade entre os sistemas usados por todos os intervenientes. Nestas condições, considerou-se que os ganhos totais seriam superiores ao somatório dos ganhos das partes.

4.7.3.3.2            Vantagens para os donos de obra

4.7.3.3.2.1     Prazos de apreciação mais curtos e transparentes

O principal objectivo do presente trabalho é o de desenvolver uma solução que motive os donos de obra e os projectistas a adoptar modelos de informação. Para tal, mais do que enunciar as vantagens técnicas desta forma de representação, é importante oferecer vantagens concretas aos intervenientes que adoptem os BIM. Estas vantagens deverão ser atingidas independentemente da atitude dos intervenientes perante os modelos de informação nas restantes fases do processo construtivo. Assim, considera-se que os modelos parciais, com aplicações específicas, podem desempenhar um papel importante na mudança de processos de trabalho na construção.

O modelo proposto é aplicável ao desenvolvimento de projectos de distribuição predial de água e ao seu licenciamento de acordo com os regulamentos nacionais em vigor. Permite ao dono de obra prever o resultado do processo de licenciamento antes de submeter o projecto à apreciação da entidade licenciadora uma vez que tem acesso ao mesmo sistema de verificação de conformidade regulamentar usado por esta. Para além disso, a automatização de processos conduz a prazos de licenciamento significativamente mais curtos.

4.7.3.3.3            Vantagens para os projectistas

4.7.3.3.3.1     Simplificação da introdução de alterações ao projecto

A introdução de alterações ao projecto – resultantes de modificações efectuadas no projecto geral ou de opções técnicas do projectista de especialidade – é simplificada relativamente ao que sucede com métodos tradicionais. Todas as peças de projecto e todos os cálculos efectuados são actualizados de forma automática.

4.7.3.3.3.2     Validação prévia de especificações de projecto

O projectista, ao recorrer ao mesmo sistema de verificação colocado à disposição da entidade licenciadora, pode efectuar, de modo instantâneo, um controlo da qualidade do projecto elaborado. Este procedimento permite a detecção atempada de eventuais erros cometidos na elaboração do projecto de licenciamento.

4.7.3.3.3.3     Geração automática de peças escritas e desenhadas

Plantas, cortes e perspectivas podem ser produzidas de forma automática a partir do modelo proposto. A ferramenta LiCAD desenvolvida produz estes elementos, bem como mapas de medições. É possível automatizar a geração de peças desenhadas em formato DWG ou DXF, usando uma aplicação externa que aceda à base de dados. O desenvolvimento de uma ferramenta deste tipo ou a adaptação de uma aplicação com funções similares (Poças Martins 2004) permitirá a sobreposição dos desenhos correspondentes às diversas especialidades.

Actualmente, não são geradas especificações técnicas pela aplicação LiCAD, mas considera-se que esta funcionalidade pode ser conseguida, ligando o modelo proposto a ferramentas existentes, conforme se referiu em 4.5.2.4.3.

4.7.3.3.4            Vantagens para as entidades licenciadoras

4.7.3.3.4.1     Processos de licenciamento melhor definidos

A adopção de métodos automáticos de licenciamento transforma as práticas actuais em processos, através da melhor definição das actividades a realizar (ver 2.2.1). Os processos são mais transparentes do que as práticas uma vez que todas as tarefas a realizar são detalhadas e, eventualmente, tornadas públicas.

4.7.3.3.4.2     Processos de licenciamento mais exigentes

O processo de licenciamento torna-se mais exigente uma vez que passa a contemplar verificações explícitas que actualmente são confiadas ao autor do projecto, sob a forma de um termo de responsabilidade generalista (ver 2.5.1). O modelo de representação proposto e o sistema de verificação desenvolvido permitem a avaliação, entre outros, de aspectos relacionados com o funcionamento hidráulico da rede.

De acordo com o referido neste trabalho, a obtenção de uma estimativa de custos dos trabalhos de construção do sistema predial é importante para a entidade licenciadora. Com efeito, os custos do processo de licenciamento, a pagar pelo dono de obra, são função desta estimativa. O recurso às medições, efectuadas de forma automática, permite efectuar uma avaliação mais precisa do custo da rede quando comparada com os métodos usados actualmente (recurso aos índices de custos do InCI e/ou declaração do dono de obra).

4.7.3.3.4.3     Economia de recursos

Como consequência da simplificação de procedimentos e da redução de prazos, a automatização do processo de licenciamento conduz a uma significativa redução nos recursos necessários para o efeito, em particular no que se refere aos recursos humanos.

5     Conclusões

5.1    Resultados do trabalho desenvolvido

A avaliação efectuada no presente trabalho permitiu identificar sintomas de deficiente gestão da informação na indústria da construção. Foi ainda possível indicar causas para a prestação negativa da indústria da construção na área da gestão da informação quando comparada com outras actividades económicas.

Uma parte significativa do desperdício neste sector decorre de fluxos de informação disfuncionais entre os intervenientes do processo construtivo.

Os modelos de informação foram apontados como tecnologias que podem contribuir para a resolução de algumas das deficiências identificadas e dos problemas que delas decorrem.

Apesar da existência de iniciativas a nível internacional que visam o desenvolvimento de modelos completos e detalhados para a construção, considera-se que estes devem ser complementados com modelos parciais, criados para resolver problemas específicos dos utilizadores e que possam ser ligados aos modelos de carácter holístico com o objectivo de fomentar a interoperabilidade entre sistemas e a comunicação entre intervenientes.

O licenciamento de projectos de construção civil foi identificado como uma oportunidade para introduzir os modelos de informação no processo construtivo. Na presente tese, foi seleccionado como exemplo de demonstração da viabilidade prática de uma nova metodologia de licenciamento automático que contribui para simplificar e objectivar uma componente importante do complexo processo de decisão que culmina com a construção da obra.

Foi desenvolvido, de raiz, um modelo original para representar projectos de sistemas de distribuição predial de água. Este modelo foi criado para um fim específico: o de permitir a comunicação com a entidade licenciadora e o licenciamento automático de projectos. O modelo foi desenvolvido usando a linguagem XML – Extended Markup Language –, um formato padrão para a representação de dados, pelo que pode ser acedido por aplicações externas criadas para o efeito. Esta característica permite que o modelo funcione como um repositório central de informação, evitando a disseminação de diferentes versões incompatíveis de um mesmo projecto. Embora a estrutura do modelo proposto tenha sido definida tendo em conta as disposições regulamentares em vigor, considera-se que é suficientemente flexível para incorporar eventuais alterações devidas a evoluções nos regulamentos aplicáveis.

Foi desenvolvido, também de raiz, um conjunto de rotinas que realizam a verificação da conformidade do projecto – representado de acordo com as especificações requeridas pelo modelo – com o principal regulamento em vigor. Estas rotinas foram incluídas na base de dados que contém também o modelo de informação proposto, podendo ser utilizadas por aplicações externas.

Foi desenvolvida uma aplicação original com interface gráfica compatível com o modelo de licenciamento elaborado, que permite o desenvolvimento de projectos de sistemas de distribuição predial de água, o seu cálculo hidráulico e a sua verificação regulamentar. Esta aplicação permite ainda a elaboração de representações gráficas rigorosas dos sistemas prediais. A coerência relativa das representações gráficas e das peças escritas produzidas pela aplicação é garantida pelo facto de serem geradas e actualizadas automaticamente a partir de um modelo de informação único.

Os elementos referidos nos parágrafos anteriores – o modelo parcial, as rotinas de verificação de conformidade regulamentar e a aplicação com interface gráfica – foram aplicados com sucesso a um projecto real de um sistema de distribuição predial de água de uma moradia.

Foi identificado um conjunto de exigências impostas aos sistemas de distribuição predial de água e foram elaboradas formas de aferir o comportamento das soluções preconizadas pelos projectistas no que concerne a estes requisitos, em particular no que toca à fiabilidade das redes públicas e à economia.

Verificou-se que as medidas de fiabilidade de abastecimento de água existentes apresentam inconvenientes importantes que, por um lado, não permitem que sejam usadas para medir a fiabilidade na óptica do cliente e, por outro, ao não estabelecerem uma distinção entre falhas de abastecimento rotineiras e catastróficas, não apontam prioridades de intervenção às entidades responsáveis pela gestão das redes. Assim, foram desenvolvidas duas formas alternativas de medir a fiabilidade do abastecimento:

a.       Uma medida probabilística que depende de um algoritmo que mede a probabilidade de falha numa rede potencialmente emalhada, que inclui diferentes tipos de componentes;

b.      Um índice compósito de fiabilidade baseado em critérios de redundância e de capacidade de reserva da rede.

Foi avaliada a possibilidade de implementação destes índices a curto prazo, tendo sido concluído que ambos os indicadores podem ser calculados com base nas informações que a generalidade das entidades responsáveis pela gestão das redes públicas de abastecimento possui actualmente ou que pode obter num prazo reduzido.

Foram desenvolvidos algoritmos que permitem o cálculo da rede mais curta que contém um conjunto de nós específicos. Esta medida pode ser usada para avaliar os traçados definidos pelos projectistas, comparando-os com “traçados óptimos” sob o ponto de vista do comprimento total da rede.

Em síntese, o trabalho realizado permite retirar as seguintes conclusões:

-        Os modelos “completos” que se têm imposto como formatos padrão ad-hoc devem ser complementados por modelos parciais, de âmbito mais restrito, dedicados a solucionar problemas específicos que são colocados aos intervenientes no processo construtivo.

-        O licenciamento de projectos é uma fase comum a todos os projectos de construção. Actualmente, esta tarefa é efectuada com base em regulamentos cuja interpretação permite algum grau de subjectividade e os prazos de apreciação são frequentemente dilatados. Crê-se que o desenvolvimento de métodos de avaliação automática de projectos de construção, para além de vantagens directas, decorrentes da simplificação administrativa resultante da sua aplicação, constitua também um factor de motivação para a adopção de modelos de informação por parte dos intervenientes, em particular daqueles que operam nas primeiras fases do processo construtivo.

-        Entre as vantagens directas referidas no ponto anterior, contam-se as seguintes:

-        Maior transparência do processo, dado que as verificações efectuadas pela entidade responsável pelo licenciamento podem ser replicadas pelos autores de projecto para confirmarem a sua conformidade;

-        Maior objectividade e rigor na avaliação devido à uniformidade dos processos de verificação de conformidade regulamentar adoptados;

-        Possibilidade de verificar o cumprimento de disposições regulamentares que exigem o cálculo hidráulico do sistema de distribuição. Actualmente, o termo de responsabilidade do autor do projecto tende a substituir essa verificação explícita;

-        Prazos de licenciamento mais curtos e redução do volume de recursos dispendidos para a verificação dos elementos de projecto.

-        As principais vantagens resultantes da adopção de modelos de informação para a construção só deverão ser obtidas após a sua disseminação pelos vários agentes que intervêm ao longo de todas as fases do processo construtivo. Assim, importa desenvolver aplicações concretas de modelos de informação – sejam eles completos ou parciais – que confiram benefícios evidentes e imediatos aos intervenientes que os adoptem nas diversas fases da construção.

-        Considera-se que é desejável que as primeiras aplicações concretas dos modelos de informação para a construção garantam uma transição tão gradual quanto for possível dos procedimentos de trabalho correntes. Este aspecto produz consequências no licenciamento automático de projectos. A aplicação de métodos automáticos na verificação de algumas disposições regulamentares, em particular daquelas que exigem informação acerca do projecto de arquitectura ou de outros projectos de especialidades, pode revelar-se pouco interessante na medida em que o volume de informação a introduzir pelo projectista aumenta consideravelmente para produzir vantagens relativamente pouco significativas. Assim, numa primeira fase, considera-se aceitável a coexistência de verificações realizadas de forma manual e de forma automática num mesmo processo de avaliação de conformidade regulamentar. O processo de licenciamento só deverá ser completamente automatizado a partir do momento em que a utilização de modelos de informação que representem um produto de construção de forma completa seja uma prática comum no sector.

-        Embora o licenciamento automático de projectos seja por vezes encarado pela comunidade dedicada à investigação na área dos modelos de informação como um objectivo que não deverá ser concretizado até 2020 (Eastman et al. 2008), demonstra-se que, em algumas áreas, é possível alcançar essa meta a curto prazo.

5.2    Desenvolvimento futuro

O trabalho desenvolvido permite identificar um conjunto de oportunidades de investigação e de desenvolvimento futuro.

-        Importa em primeiro lugar apontar para uma estratégia de desenvolvimento de formatos de representação para a construção a nível nacional ou, porventura, a nível comunitário. É importante decidir-se entre duas alternativas principais:

-        Desenvolver modelos próprios, mantendo as normas e os regulamentos nacionais quando estes existam;

-        Adoptar modelos internacionais, adaptando os regulamentos actualmente aplicáveis.

-        O presente trabalho partilha as conclusões de outros estudos internacionais na área do licenciamento automático de projectos segundo os quais os regulamentos aplicáveis aos edifícios não estão isentos de disposições que admitem interpretações ambíguas. Caso o licenciamento automático de projectos seja encarado como um objectivo a atingir pelas entidades envolvidas no processo construtivo, é importante que estas ambiguidades sejam identificadas e eliminadas dos regulamentos e processos de licenciamento.

-        No que toca aos projectos de sistemas de distribuição predial de água, importa concretizar a ligação do modelo desenvolvido ao formato IFC – Industry Foundation Classes.

-        Importa igualmente alargar o estudo desenvolvido a outros projectos de especialidade. Os projectos de águas residuais, em particular, foram alvo de uma avaliação regulamentar no decorrer deste trabalho, considerando-se aptos para o desenvolvimento de especificações que permitam a sua sujeição a processos de licenciamento automático.

Anexo A.                    Análise regulamentar DR nº 23/95

Apresenta-se, nas tabelas seguintes, uma análise sucinta às disposições regulamentares aplicáveis a sistemas de distribuição predial de água e a sistemas de drenagem predial de águas residuais.

Para cada artigo dos títulos III e V do DR nº 23/95 (Ministério das Obras Públicas 1995) foi indicada uma apreciação à possibilidade de aplicar diferentes métodos de verificação de conformidade regulamentar:

a.       Manual, de forma expedita, por simples observação dos elementos de projecto;

b.      Automático com base numa checklist, isto é, numa lista de declarações do autor do projecto;

c.       Automático com base num modelo de informação;

d.      Observação directa em obra durante acções de fiscalização.

Para cada artigo e para cada método, de verificação, foi indicado se a verificação pode ser efectuada (s), se, podendo ser efectuada, é considerada pouco viável (p) ou se não pode ser efectuada (n). As classificações foram atribuídas de forma a orientar o desenvolvimento de modelos de informação para o licenciamento automático de projectos, não devendo ser encaradas como medidas rigorosas da aplicabilidade dos diferentes tipos de métodos.

Tabela 9 – Título III: Sistemas de distribuição predial de água

Capítulo

Secção

Artigo

Parág.

Alínea

Manual

Automático

Obs. obra

Observações

Obs. directa

Checklist

Modelo

Regras Gerais

82

s

s

s

Modelo deve conter informação acerca de função de cada componente incluindo, para este efeito, identificação de eventuais origens

83

NA

NA

NA

Aplicável apenas à entidade gestora do serviço de distribuição pública

84

NA

NA

NA

s

Conformidade só pode ser verificada no local – fiscalização de obra

85

1

s

s

s

Modelo deve verificar se existe algum componente comum entre redes de distribuição e de drenagem - nós de cada rede serão obrigatoriamente identificados de forma distinta

2

NA

NA

NA

s

Soluções correntes não oferecem este tipo de risco. Boa instalação deverá ser verificada no local

86

1

p

p

p

É possível verificar em que troços da rede é usada água não potável (as redes serão separadas, de acordo com Art. 82º). Riscos de saúde pública devem ser avaliados por entidade competente.

2

s

Semelhante a Art. 84º

Concepção Geral

87

1

NA

NA

NA

Regras genéricas para concepção de sistemas. Devem ser atendidas por projectistas e podem ser incorporadas no seu modelo de cálculo.

2

p

s

s

Método manual permite uma verificação expedita de funções (estimando perdas de carga de forma "intuitiva"). Checklist funciona como declaração de cumprimento. Modelo permite cálculo de pressões em cada nó.

88

NA

NA

NA

Regra administrativa impõe a verificação da capacidade da rede existente perante alterações efectuadas. Às redes resultantes aplicam-se as observações efectuadas para o Art. 87º Par. 2

89

1

s

s

s

Modelo deve conter lista de dispositivos e de localizações possíveis

2

s

s

s

Um modelo de informação pode tornar dispensável a apresentação de peças desenhadas tradicionais

90

1

s

s

s

Verificar lista de caudais instantâneos (consumos instantâneos por nó).

2

s

s

s

Idem

91

1

NA

NA

NA

Parágrafo enquadrador de parágrafos seguintes

2

NA

NA

NA

Definição

3

NA

NA

NA

Obtenção de coeficientes de simultaneidade

4

n

s

s

Obtenção do valor do caudal de cálculo em cada troço é uma tarefa cuja realização por processos manuais é morosa (a observação directa está fora de hipótese). É necessário recalcular as condições de funcionamento da rede, o que só se torna viável (para efeitos de licenciamento) se forem usados meios automáticos.

5

n

s

s

Idem (regras específicas para redes que incluem fluxómetros)

92

s

s

s

Embora a regra seja directamente aplicável à entidade gestora, as pressões na rede à entrada do contador são dados de base de qualquer projecto e são invariavelmente explicitadas pelos projectistas.

Rede predial de água fria e água quente

93

n

s

s

Ver comentários aos parágrafos 4 e 5 do Art. 91º

94

1

a

n

s

s

Verificação implica cálculo hidráulico da rede, o que está fora do âmbito da observação directa.

b

n

s

s

c

n

s

s

2

p

s

s

Observação directa permite a confirmação do respeito pelos diâmetros mínimos regulamentares, não a verificação das pressões de serviço

95

1

s

s

s

s

Modelo deve conter informação geométrica. Admite-se que, por simplicidade de procedimentos, se deve evitar efectuar a verificação da inclinação imposta aos troços horizontais. Esta verificação poderá, caso seja considerada relevante, ser efectuada em obra

2

NA

NA

NA

Regra genérica, não concretiza acessórios dispensáveis.

3

s

s

s

s

Paralelismo de condutas é facilmente verificável, quer por processos manuais, quer por processos automáticos. Cota relativa das condutas de redes de águas frias e quentes normalmente é omitida nas peças desenhadas de projecto e pode ser verificada em obra.

4

s

s

s

s

Ver comentários ao parágrafo 3 deste artigo

96

1

s

s

n

Apenas modelos completos permitem a conveniente definição de elementos construtivos referidos neste parágrafo. A sua inclusão num modelo mais simples, embora possível, dificulta o processo de introdução de dados por parte do projectista pelo que se considera que a verificação automática deste parágrafo carece da adopção de sistemas BIM.

2

n

s

n

s

Verificação só pode ser efectuada em obra

3

n

s

n

p

Idem

4

s

s

n

Ver comentários ao parágrafo 1 deste artigo

5

todas

s

s

n

Ver comentários ao parágrafo 1 deste artigo

97

1

a

s

s

s

Modelo inclui características de tubagens

b

s

s

s

Idem

c

n

s

n

s

A não ser que todos os acessórios estejam especificados no projecto e que seja possível, a partrir da análise do projecto de instalações hidráulicas, garantir que nenhum elemento metálico não pertencente à rede de distribuição de água esteja em contacto com as condutas, a única forma de verificar o cumprimento deste ponto será a fiscalização da obra

d

n

s

n

s

Idem

e

n

s

n

s

Idem

f

n

s

n

s

Idem

g

n

s

n

s

Idem

h

s

s

s

Modelo deve incluir informação acerca da susceptibilidade de um material em ser corroído

2

n

s

n

Embora esta regra só possa ser verificada após a entrada em funcionamento da rede, o projectista pode explicitar as condições de funcionamento previstas para a rede.

3

n

s

p

Idem; Modelo pode dispôr de características dos materiais relevantes para prever o seu comportamento acima da temperatura indicada no regulamento

98

1

s

s

s

A cada conduta deve corresponder uma propriedade "isolamento - material", permitindo a verificação da vulnerabilidade do material

2

s

s

s

Constitui uma excepção à alínea anterior - não verificar derivações que tenham um comprimento inferior a x (não especificado no regulamento)

3

n

s

n

s

Pode ser verificado in situ por observação directa ou projectista pode assumir que considerou riscos associados a infiltrações e choques mecânicos

99

1

s

s

s

Alínea apenas exclui a aplicação de tubagens em PVC rígido em redes afectas a sistemas de combate a incêndios. A verificação automática desta alínea obriga modelo a caracterizar uso de cada troço de rede.

2

s

s

s

De acordo com comentário anterior, troços da rede devem ser caracterizados em função do uso, mas também em função da sua localização (interior/exterior)

Elementos acessórios da rede

100

NA

NA

NA

Definição (torneiras)

101

NA

NA

NA

Definição (válvulas, tipos de válvulas)

102

a

s

s

s

Importante definir posição de válvulas de seccionamento/retenção/segurança/redutoras de pressão e tipo de aparelhos a jusante destas válvulas

b

s

s

s

Idem

c

s

s

s

Idem

d

s

s

s

Idem

103

s

s

s

Obriga à especificação do material que constitui as válvulas

104

NA

NA

NA

Não exclui de forma explícita nenhum material.

105

1

NA

NA

NA

Aplica-se à entidade gestora

2

NA

NA

NA

Parâmetros que determinam a definição do contador

106

1

s

s

s

Cada consumidor integrado numa rede predial deverá dispôr de um contador isolado ou integrado numa bateria de contadores

2

NA

NA

NA

Não exclui nenhum tipo de configuração para baterias de contadores

3

NA

NA

NA

Aplica-se à entidade gestora

4

NA

NA

NA

Exemplo de bateria de contadores

107

1

s

s

n

Localização de contador só pode ser determinada, de forma automática, se forem usados BIM que permitam a identificação automática de cada divisão

2

s

s

n

Semelhante ao indicado no ponto anterior, mas BIM deve permitir identificar limites de logradouro

108

1

NA

NA

NA

Definição (finalidade de reservatório predial)

2

NA

NA

NA

Aplicável apenas à entidade gestora do serviço de distribuição pública

3

NA

NA

NA

Aplicável apenas à entidade gestora do serviço de distribuição pública

109

1

NA

NA

NA

Definição (instalações elevatórias)

2

NA

NA

NA

Definição (instalações sobrepressoras)

110

NA

NA

NA

s

Condições necessárias para a realização da verificação in situ da rede

111

1

NA

NA

NA

s

Realização do ensaio de estanquidade

2

NA

NA

NA

s

idem

112

NA

NA

NA

s

Lavagem de redes depois da realização do ensaio de estanquidade

113

NA

NA

NA

s

Verificação in situ do funcionamento hidráulico do sistema

Tabela 10 – Título V: Sistemas de drenagem predial de águas residuais

Capítulo

Secção

Artigo

Parág.

Alínea

Manual

Automático

Obs. obra

Observações

Obs. directa

Checklist

Modelo

Regras gerais

198

1

s

s

s

Modelo deve distinguir redes de drenagem de águas residuais e pluviais

2

NA

NA

NA

Águas residuais industriais podem ser descarregadas em rede de águas residuais domésticas ou pluviais após tratamento adequado

199

1

s

s

s

Natureza de águas que podem ser descarregadas nas redes de águas residuais domésticas - modelo deve identificar tipo de efluente lançado em cada nó da rede

2

s

s

s

Idem, águas pluviais

200

n

s

n

Apenas se considera viável que o projectista apresente uma declaração indicando que não aceitáveis descargas do tipo referido no art. 117º na rede

201

NA

NA

NA

Aplicável apenas à entidade gestora do serviço de distribuição pública

202

NA

NA

NA

s

Apenas pode ser constatado em obra, embora projectista deva especificar em conformidade

Concepção dos sistemas

203

1

s

s

s

Deve ser verificada existência de ventilação primária - tubos de queda devem ser prolongados até cobertura ou condutas de ventilação devem ser inseridas nos extremos montante dos colectores prediais

2

NA

NA

NA

Definição ventilação secundária

3

n

s

n

Obriga à análise complementar de outros projectos de especialidade

204

NA

NA

NA

Regra administrativa impõe a verificação da capacidade da rede existente perante alterações efectuadas.

205

1

s

s

s

Pontos da rede de cota superior ao arruamento devem descarregar para colector público por gravidade: verificar se cotas da rede são sucessivamente decrescentes e se não existem bombas  nestes troços.

2

s

s

s

Pontos da rede de cota inferior ao do arruamento devem ser descarregar na rede pública com o auxílio de bombas: verificar existência

3

n

n

n

Disposições construtivas não estão especificadas no artigo - avaliação ao critério de entidade licenciadora

4

s

s

s

Ver art. 85º

206

1

s

s

s

Identificar natureza do ponto de descarga - colector ou valeta

2

s

s

s

Ver art. 205º - 2

207

NA

NA

NA

Quando não existe rede pública, aplicam-se as regras até à câmara do ramal de ligação

Elementos de base para dimensionamento

208

1

NA

NA

NA

Não se trata de uma verificação

2

NA

NA

NA

Idem

209

1

NA

NA

NA

Obtenção de coeficientes de simultaneidade

2

NA

NA

NA

Idem

210

1

p

s

s

Obtenção de dados de precipitação - verificação pode ser efectuada de forma automática

2

p

s

s

Idem

211

p

s

s

Coeficiente de escoamento pode ser verificado pelo programa

Canalizações

Ramais de descarga

212

1

NA

NA

NA

Definição de ramal de descarga (águas residuais)

2

NA

NA

NA

Idem (águas pluviais)

213

1

NA

NA

NA

Regra de cálculo (águas residuais)

2

NA

NA

NA

Idem (águas pluviais)

214

1

a

NA

NA

NA

Regra de cálculo

b

s

s

s

Limites pata inclinação de ramais de descarga (águas residuais)

c

NA

NA

NA

Regra de cálculo

d

NA

NA

NA

Regra de cálculo

2

p

s

s

Verificação - Secção máxima do escoamento num ramal de descarga individual em função da distância do respectivo sifão à seccção ventilada a que está ligado

3

p

s

s

Idem

4

p

s

s

Verificar se nos ramais de descarga não individuais o escoamento é efectuado a meia secção

5

a

NA

NA

NA

Regra de cálculo

b

s

s

s

Limites pata inclinação de ramais de descarga (águas pluviais)

c

NA

NA

NA

Regra de cálculo

6

NA

NA

NA

Escoamento de águas pluviais pode efectuar-se a secção cheia (não constitui uma verificação, mas antes um princípio de cálculo)

215

1

s

s

s

Diâmetros mínimos (águas residuais)

2

s

s

s

Diâmetros mínimos (águas pluviais)

216

s

s

s

Verificar se diâmetros nunca crescem para jusante

217

1

s

s

s

Definição de ramal de descarga a partir de pontos extremos permite admitir que troços serão rectilíneos. Modelo deve sugerir que sejam colocadas caixas de reunião na intersecção dos troços ou, em alternativa, impor a instalação de curvas de concordância (menos recomendado!).

2

s

s

s

Implica a possibilidade de definir a rede em 3D (na prática, será suficiente estabelecer a correspondência de dois pontos na mesma vertical (por exemplo, a definição de dois tubos de queda)

3

s

s

s

Semelhante a art. 217º - 1 - permitir ligações por meio de forquilhas para tubos de águas de sabão

4

s

s

s

Manter ramais de descarga de bacias de retretes separados dos de águas de sabão

5

s

s

s

Desenvolve, de alguma forma, ponto anterior: ramais de descarga de águas de sabão ou de urinóis podem ser ligadas ramais de descarga de bacias de retrete se primeiras disposerem de ventilação secundária. Modelo deve poder caracterizar tipo de ventilação em cada troço da rede.

6

s

s

s

A ligação entre ramais de descarga de urinóis e de águas de sabão só pode ser efectuada por intermédio de caixas de reunião

218

1

a

p

s

s

A possibilidade de verificação deste artigo depende da incorporação do conceito de forquilha no modelo. A ser introduzido este conceito, deve ser verificada a existência de ligações do tipo conduta - forquilha - conduta (ver Nota 3).

b

p

s

s

Idem

2

p

s

s

É possível verificar artigo se, entre as propriedades da forquilha, se contar o ângulo de inserção

219

1

n

s

n

s

Deve ser verificado em obra. Note-se que o ponto é relativamente pouco relevante para efeitos de verificação uma vez que não exclui nenhuma solução "de bom senso" (naturalmente, ramais não devem ser separados de paredes/pavimentos/tectos...).

2

n

s

n

Obriga à verificação simultânea de projectos de redes de águas e esgotos e de estabilidade, recusando eventuais intersecções não previstas de elementos especificados em cada um dos projectos.

Ramais de ventilação

220

NA

NA

NA

Finalidade

221

s

s

s

Diâmetro mínimo de ramal de ventilação: 2/3*Diâmetro de ramal de descarga correspondente

222

1

s

s

s

Exige a definição tridimensional da rede de ventilação (semelhante ao indicado para o art. 217º - 2)

2

s

s

s

Inclinação mínima de um troço de ramal de ventilação: 2%

3

s

s

s

Distância entre sifão e ligação ao ramal de descarga do ramal de ventilação (valores limite)

4

s

s

s

Ventilação secundária para baterias de bacias de retrete

223

n

s

n

s

Ver art. 219º

224

s

s

s

Sugere materiais aceitáveis, mas não exclui explicitamente nenhum

Algerozes e Caleiras

225

NA

NA

NA

Finalidade

226

p

s

s

Ver comentários a artigos 210º e 211º

227

a

NA

NA

NA

Ver artigo anterior

b

NA

NA

NA

Princípios de cálculo

c

NA

NA

NA

Idem

d

n

s

s

Altura de lâmina líquida pode ser verificada pelo programa

228

s

s

s

Sugere materiais aceitáveis, mas não exclui explicitamente nenhum

Tubos de Queda

229

1

NA

NA

NA

Finalidade

2

NA

NA

NA

Definição

230

1

NA

NA

NA

Princípios de cálculo

2

n

s

s

Valores de cálculo a empregar podem ser obtidos de forma automática

231

1

a

NA

NA

NA

Princípios de cálculo

b

n

s

s

Ocupação máxima de tubos de queda pode ser verificada por cálculo automático

2

s

s

s

Modelo inclui características de tubagens

3

p

s

s

Tubos de queda com mais de 35m e caudal superior a 700 l/min - instalar coluna de ventilação

4

a

NA

NA

NA

Princípios de cálculo

b

s

s

s

Modelo deve fornecer informação geométrica suficiente

5

NA

NA

NA

Exemplo

232

s

s

s

Diâmetro mínimo de tubo de queda: 50mm ou maior ramal de descarga a ele ligado

233

1

s

s

s

É possível verificar se os tubos formam um alinhamento vertical (ou aceitar alguma tolerância neste aspecto, tal como o artigo o faz - ver ponto seguinte)

2

s

s

s

idem - tolerância referida no comentário anterior é de 10 diâmetros

3

NA

NA

NA

Embora se trate de um princípio de cálculo, remete para um conjunto de novas regras a aplicar nos troços de fraca pendente. Estas regras podem ser incluídas na aplicação)

4

s

s

s

É possível efectuar esta verificação caso as características geométricas da tubagem sejam devidamente especificadas

5

a

s

s

p

Verificação de características referidas implica o cruzamento de dados com outros projectos, nomeadamente o projecto geral de arquitectura. Esta tarefa é mais apta para ser realizada de forma manual.

b

s

s

p

idem

c

s

s

p

idem

d

n

s

n

s

A verificar em obra, em eventuais pormenores construtivos ou nas peças escritas de projecto

6

NA

NA

NA

Exemplo

234

1

n

s

n

s

Não exclui nenhuma solução alternativa às sugeridas; Mais fácil de verificar em obra

2

n

s

n

s

idem

235

1

a

s

s

s

Obriga à definição de uma distância limite entre boca de limpeza e curva de concordância

b

s

s

s

Obriga à definição de uma distância limite entre boca de limpeza e ponto de inserção de ramais de descarga no tubo de queda

c

s

s

p

Obriga modelo a reconhecer quando muda de piso. Uma (possível) forma de contornar este problema passa pela definição automática de um piso em cada plano (aproximadamente) horizontal definida pelos ramais de descarga.

d

s

s

s

Obriga à definição de uma distância limite entre boca de limpeza e parte inferior do tubo de queda. Só é aplicável nas situações em que não é possível instalar uma câmara de inspecção.

2

s

s

s

Diâmetro de boca de limpeza = Diâmetro do tubo de queda. Definir distância máxima de abertura entre boca de limpeza e tubo de queda.

3

p

s

p

s

Princípio geral, mais fácil de constatar em obra ou após consulta de projecto completo.

236

1

s

s

s

Modelo deve reconhecer ligações por meio de forquilhas e câmaras de inspecção

2

s

s

s

Verificar se distância entre troço vertical do tubo de queda e o colector predial é superior a 10x o diâmetro do tubo de queda. Em caso afirmativo, garantir ventilação secundária, instalar câmara de visita ou ainda garantir ventilação primária do troço.

3

a

s

s

s

Tubos de queda devem terminar (na sua extremidade inferior) em colectores prediais através de forquilhas ou câmaras de inspecção com curvas de concordância entre os troços

b

s

s

s

Em valetas de arruamentos.

237

1

NA

NA

NA

Não exclui, de forma explícita, nenhum material

2

NA

NA

NA

Não exclui, de forma explícita, nenhum material

Colunas de Ventilação

238

1

NA

NA

NA

Definições

2

NA

NA

NA

idem

239

p

s

s

Correspondência entre diâmetro dos tubos de queda e das respectivas colunas de ventilação é fácil de realizar de forma automática. Também pode ser efectuada de forma manual, mas o processo poderá ser moroso no caso de projectos de grande dimensão.

240

s

s

s

Deve ser avaliada a variação da secção da coluna ao longo da sua extensão. Não deverá haver redução de secção no sentido ascendente.

241

1

s

s

s

Possível de verificar, embora permita alguma variabilidade em termos de traçados admissíveis…

2

a

s

s

s

Definir tolerância para estas dimensões

b

s/p

s

s

Em representações 2D (plantas) nem sempre as cotas das extremidades dos tubos de queda são devidamente representadas.

c

s

s

s

Exige a definição tridimensional da rede de ventilação (semelhante ao indicado para o art. 217º - 2) mas também da sua interligação com a rede de saneamento, o que exige um modelo relativamente complexo.

d

s

s

s

De aplicação mais simples que pontos anteriores

242

p

p

p

s

Mais fácil de constatar em obra. De qualquer forma, o artigo não exclui explicitamente nenhuma solução alternativa à preconizada.

243

NA

NA

NA

Não exclui, de forma explícita, nenhum material

Colectores Prediais

244

NA

NA

NA

Definições

245

1

n

s

s

Regras de cálculo. Obtenção do valor do caudal de cálculo em cada troço é uma tarefa cuja realização por processos manuais é morosa (a observação directa está fora de hipótese). É necessário recalcular as condições de funcionamento da rede, o que só se torna viável (para efeitos de licenciamento) se forem usados meios automáticos.

2

n

s

s

Idem

246

1

a

p

s

s

Validação da relação diâmetro-caudal

b

s

s

s

Inclinações limite para colectores prediais

c

n

s

s

Rugosidade pode ser considerada nas expressões de cálculo.

2

p

s

s

Validação da relação secção de escoamento-caudal

247

s

s

s

Diâmetro mínimo de canalizações

248

s

s

s

Verificar se diâmetros nunca decrescem para jusante

249

1

s

s

s

Troços devem ser definidos por pontos a montante e jusante

2

s

s

s

Limites de troços devem ser marcados (em termos de modelo) por câmaras de inspecção.

3

p

s

p

Caso os colectores estejam à vista, o que nem sempre é fácil de constatar nas peças de projecto, as câmaras de inspecção podem ser substituídas por outros dispositivos.

4

s

s

s

Distância máxima entre bocas de limpeza.

250

1

s

s

s

Na extremidade jusante do sistema predial deve existir uma câmara de ramal de ligação. A conformidade da sua localização com as disposições regulamentares pode não ser fácil de efectuar num modelo simplificado.

2

s

s

n

Ver comentário anterior.

3

NA

NA

NA

Conceito

4

p

s

p

s

Identificação de eventuais obstáculos à ventilação não é, em princípio, possível em projecto

5

n

s

n

Excepção admitida para sistemas públicos em algumas condições de funcionamento… Admite-se que, para efeitos de licenciamento, este ponto seja pouco relevante.

251

s

s

s

Em princípio, as válvulas de retenção são proibidas, embora se atribua alguma discricionariedade ao licenciador neste ponto.

252

1

NA

NA

NA

Não exclui, de forma explícita, nenhum material

2

NA

NA

NA

Não exclui, de forma explícita, nenhum material

Acessórios

253

1

NA

NA

NA

Definição

2

s

s

s

Todos os aparelhos sanitários devem ter um sifão associado. Essa associação pode ser colectiva, isto é, vários aparelhos podem partilhar um sifão.

3

s

s

s

Ralos de recolha de águas pluviais ligados a sistemas unitários, em princípio deverão estar munidos de sifões excepto se licenciador não considerar que o local não é "de permanência de pessoas"

254

1

s

s

s

Diâmetros mínimos de sifões

2

s

s

s

Fecho hídrico limite. Nota: tal como o parágrafo anterior, nem sempre é possível verificar a conformidade regulamentar do fecho hídrico nos projectos correntes

255

1

NA

NA

NA

s

Regra (de elementar bom senso!) difícil de verificar em projecto.

2

s

s

s

Distância mínima entre aparelho sanitário e sifão

3

s

s

s

Sifões colectivos são aceitáveis em aparelhos produtores de águas de sabão.

4

s

s

s

Duplo sifonamento é proibido.

5

s

s

s

Sifões individuais obrigatórios em instalações em bateria.

256

NA

NA

NA

Não exclui, de forma explícita, nenhum material

257

NA

NA

NA

Definições

258

1

n

s

s

Áreas úteis relativas de ralos de águas residuais domésticas vs. Respectivos ramais de descarga

2

n

s

s

Idem para tubos de queda de águas pluviais

259

1

s

s

s

Ralos obrigatórios em todos os aparelhos excepto bacias de retrete.

2

p

s

s

Características de ralos em locais de acumulação de areias

3

p

s

s

Idem para ralos de lava-louças

260

NA

NA

NA

Não exclui, de forma explícita, nenhum material

261

1

NA

NA

NA

Definições e disposições construtivas tipo.

2

s

s

s

Dimensões de câmara de inspecção

3

s

s

s

Dimensões de câmara de inspecção

Instalaões complementares

262

1

NA

NA

NA

Disposições genéricas relacionadas com a localização de instalações elevatórias

2

NA

NA

NA

Características de instalações elevatórias. Considera-se que a sua verificação regulamentar é pouco relevante para efeitos de licenciamento.

263

1

NA

NA

NA

Definições (Câmaras retentoras)

2

NA

NA

NA

Idem

3

NA

NA

NA

Idem

264

NA

NA

NA

Aspectos gerais relacionados com dimensionamento de câmaras retentoras

265

1

s

s

s

Câmaras retentoras não devem ser ligadas a bacias de retretes e urinóis

2

s

s

p

Localização de câmara retentora. Difícil de realizar de forma automática num modelo simplificado, embora possível!

266

1

NA

s

NA

Aspectos gerais relacionados com características de câmaras retentoras. Difícil de comprovar directamente em projecto, mas possível de ser apreciado a partir de declaração de projectista.

2

p

s

n

s

Aspectos construtivos de câmaras retentoras. Mais fácil de constatar em obra. Modelo simplificado não captura este nível de detalhe.

3

s

s

s

Câmaras retentoras devem dispor de ventilação e de sifão a jusante (caso os aparelhos que serve não o tenham).

Aparelhos sanitários

267

NA

NA

NA

Todos as bacias de retrete, urinóis, etc. devem dispor de autoclismos ou fluxómetros. Num modelo, este tipo de disposições poderá ser remetido para considerações genéricas (ver Nota2).

Ensaios

268 a 270

NA

NA

NA

Obrigatoriedade de realização de ensaios e sua descrição

Anexo B.                    LicA: Estrutura da base de dados

Segue-se uma descrição sucinta da estrutura da base de dados LicA.

Uma descrição detalhada do formato a usar na representação de dados pode ser consultada no Anexo C.

Tabela 11 – Tabelas usadas pelo LicA e respectivas descrições

Tabela

Descrição

Allowed_Materials

Calc_Report_Res

Resultados das verificações automáticas efectuadas

Calc_Report_Res_AppliesTo_Desc

Tipo de elemento da rede ao qual corresponde a mensagem de sistema

Calc_Report_Res_AppliesTo_ID

Calc_Report_Res_Desc

Contém texto correspondente a cada tipo de mensagem

Calc_Report_Res_ID

Devices

Contém identificação dos diversos acessórios da rede

Devices_Type

Devices_Type_Desc

Designação de cada tipo de acessório

Devices_Type_ID

Flow

Consumos em cada nó da rede e indicação da necessidade de os afectar dos coeficientes de redução regulamentares

Fractions_ID

General_Properties

Contém uma variedade de constantes necessárias à verificação da conformidade da rede

General_Properties_Desc

Descrição dos parâmetros de texto indicados em General_Properties

Languages

Línguas utilizadas nos campos de texto do LicA

link_res

Link_Type_Desc

Descrição do tipo de ligação (link) da rede

Links

Ligações da rede

Materials_Desc

Descrição do tipo de material da canalização

Materials_ID

MonJus_Res

Indicação do nó de montante e de jusante da ligação

Node_Res

Resultados, ao nível dos nós da rede, do cálculo hidráulico efectuado

Nodes

Nós da rede e suas coordenadas cartesianas

Pipe_Roughness

Rugosidade de condutas de diferentes materiais - Darcy-Weisbach. É possível definir uma gama de rugosidades indicando um valor máximo e um valor mínimo para este parâmetro

Pipe_Roughness_Desc

Descrição dos materiais constituintes das tubagens da rede

Pipes

Tubagens da rede

Pumps

Bombas da rede e suas alturas de elevação

Spaces

Identifica cada espaço individual e indica o seu tipo

Spaces_Type_Desc

Descrição dos espaços definidos no projecto de arquitectura

Spaces_Type_ID

Identificação dos tipos de espaço admissíveis

SubNetworks

Divide rede em subredes que podem ser de diferentes tipos (ex: água quente/fria)

SubNetworks_Type_Desc

Descrição das redes existentes

SubNetworks_Type_ID

Identificação dos tipos de rede admissíveis

Tanks

Reservatórios prediais

URC

Utilizar coeficiente de redução?

URC_ID

Valves

Válvulas da rede

Valves_Type_Desc

Tipo de válvulas de rede

Valves_Type_ID

Identificação dos tipos de válvula admissíveis

Warning_Level

Associa avisos a mensagens geradas pelo programa

Warning_Level_Desc

Níveis dos avisos gerados pelo programa

Warning_Level_ID

Identificação dos tipos de aviso admissíveis

Tabela 12 – Campos da base de dados por tabela, seus tipos de dados e respectivas descrições

Tabela

Campo

Datatype

Descrição

Allowed_Materials

ID

Int

Allowed_Materials

IsInside

Bit

Calc_Report_Res

ID

Int

Identificação do elemento ao qual se refere a mensagem gerada - combina com dados de Calc_Report_Res_Desc. Ex: 55 (falta de pressão no nó 55)

Calc_Report_Res

MSG_ID

Int

Ligação a tabela Calc_Report_Res_ID

Calc_Report_Res

MSG_TXT

NVarChar (500)

Campo actualmente não utilizado

Calc_Report_Res_AppliesTo_Desc

ID

Int

Calc_Report_Res_AppliesTo_Desc

Lang_ID

Int

Calc_Report_Res_AppliesTo_Desc

Description

NChar (100)

Calc_Report_Res_AppliesTo_ID

ID

Int

Calc_Report_Res_Desc

MSG_ID

Int

Ligação a tabela Calc_Report_Res_ID

Calc_Report_Res_Desc

MSG_TXT

NVarCharMax

Texto a incluir no relatório a produzir

Calc_Report_Res_Desc

LANG_ID

Int

Identificação da língua em que está escrita a mensagem

Calc_Report_Res_ID

ID

Int

Identificação

Calc_Report_Res_ID

ArtID

NChar (20)

Calc_Report_Res_ID

AppliesTo

Int

Devices

ID

Int

Identificação

Devices

Device_Type_ID

Int

Ligação a tabela Devices_Type_ID

Devices

Space_ID

Int

Ligação a tabela Spaces

Devices_Type

ID

Int

Devices_Type

Min_Reg_Flow

Decimal (19,9)

Devices_Type

URC

Bit

Devices_Type_Desc

ID

Int

Ligação a tabela Devices_Type_ID

Devices_Type_Desc

Description

NVarCharMax

Descrição do acessório de rede

Devices_Type_Desc

LANG_ID

Int

Ligação a tabela Languages

Devices_Type_ID

ID

Int

Identificação

Flow

ID

Int

Flow

Node_ID

Int

Ligação a tabela Nodes

Flow

Flow

Decimal (19,9)

Caudal [m3/s]

Flow

Use_Reduction_Coef

Bit

Ligação a tabela URC_ID

Flow

Device_ID

Int

Ligação a tabela Devices

Flow

Hmin

Decimal (19,9)

Pressão mínima necessária para o funcionamento do equipamento [m]

Fractions_ID

ID

Int

General_Properties

ID

Int

Identificação

General_Properties

VAL

Decimal (19,9)

Constante a utilizar para o parâmetro

General_Properties_Desc

ID

Int

Ligação a tabela General_Properties

General_Properties_Desc

Description

Char (500)

Descrição do parâmetro (texto)

General_Properties_Desc

LANG_ID

Int

Ligação a tabela Languages

Languages

LANG_ID

Int

Identificação

Languages

Language

NVarChar (50)

Nome da língua (texto)

link_res

ID

Int

Identificação

link_res

Qc

Decimal (19,9)

Caudal de cálculo [m^3/s]

link_res

Q0

Decimal (19,9)

Caudal de cálculo não sujeito a aplicação de coeficiente de simultaneidade [m^3/s]

link_res

Q1

Decimal (19,9)

Caudal de cálculo sujeito a aplicação de coeficiente de simultaneidade [m^3/s]

link_res

V

Decimal (19,9)

Velocidade correspondente ao caudal de cálculo Qc [m/s]

link_res

L

Decimal (19,9)

Comprimento da canalização [m]

Link_Type_Desc

ID

Int

Identificação do tipo de ligação

Link_Type_Desc

Link_Type

NVarChar (50)

Descrição do tipo de ligação

Link_Type_Desc

LANG_ID

Int

Ligação a tabela Languages

Links

ID

Int

Identificação

Links

P1

Int

Ligação a tabela Nodes

Links

P2

Int

Ligação a tabela Nodes

Materials_Desc

ID

Int

Materials_Desc

Description

NChar (100)

Materials_Desc

LANG_ID

Int

Materials_ID

ID

Int

Materials_ID

Roughness_ID

Int

MonJus_Res

Lid

Int

Ligação a tabela Links

MonJus_Res

ID

Int

Ligação a tabela Nodes

MonJus_Res

ID_Prev

Int

Ligação a tabela Nodes

Node_Res

ID

Int

Identificação

Node_Res

Hmin

Decimal (19,9)

Pressão mínima no nó [m]

Node_Res

Hmax

Decimal (19,9)

Pressão máxima no nó [m]

Node_Res

Q0

Decimal (19,9)

Caudal acumulado de fluxómetros a jusante do nó [m^3/s]

Node_Res

C0

Int

Número de fluxómetros a jusante

Node_Res

Q1

Decimal (19,9)

Caudal acumulado de dispositivos de utilização, excepto fluxómetros, a jusante [m^3/s] (em rigor, é contado o caudal acumulado correspondente aos nós com consumos não nulos a jusante do nó)

Node_Res

C1

Int

Número de dispositivos de utilização, excepto fluxómetros, a jusante (em rigor, é contado o número de nós com consumos não nulos a jusante do nó)

Nodes

ID

Int

Identificação

Nodes

X

Decimal (19,9)

Coordenada cartesiana X

Nodes

Y

Decimal (19,9)

Coordenada cartesiana Y

Nodes

Z

Decimal (19,9)

Coordenada cartesiana Z

Pipe_Roughness

ID

Int

Identificação

Pipe_Roughness

e_min

Decimal (19,9)

rugosidade mínima [m]

Pipe_Roughness

e_max

Decimal (19,9)

rugosidade máxima [m]

Pipe_Roughness_Desc

ID

Int

Ligação a tabela Pipe_Roughness

Pipe_Roughness_Desc

Description

NVarCharMax

Nome do material

Pipe_Roughness_Desc

LANG_ID

Int

Ligação a tabela Languages

Pipes

ID

Int

Ligação a tabela Links

Pipes

Material_ID

Int

Ligação a tabela Pipe_Roughness

Pipes

Diameter

Decimal (19,9)

Diâmetro da tubagem [m]

Pipes

IsThermIns

Bit

Pipes

IsInside

Bit

Pumps

ID

Int

Ligação a tabela Links

Pumps

H

Decimal (19,9)

Altura de elevação [m]

Spaces

ID

Int

Identificação

Spaces

Space_Type_ID

Int

Ligação a tabela Spaces_Type_ID

Spaces

Fraction_ID

Int

Spaces_Type_Desc

ID

Int

Ligação a tabela Spaces_Type_ID

Spaces_Type_Desc

Description

NVarCharMax

Descrição do espaço

Spaces_Type_Desc

LANG_ID

Int

Ligação a tabela Languages

Spaces_Type_ID

ID

Int

Identificação

SubNetworks

Link_ID

Int

Ligação a tabela SubNetworks

SubNetworks

Network_ID

Int

Identificação da subrede

SubNetworks

Network_Type_ID

Int

Ligação a tabela SubNetworks_Type_ID

SubNetworks_Type_Desc

Network_Type_ID

Int

Ligação a tabela SubNetworks_Type_ID

SubNetworks_Type_Desc

Description

NVarCharMax

Descrição do tipo de rede

SubNetworks_Type_Desc

LANG_ID

Int

Ligação a tabela Languages

SubNetworks_Type_ID

ID

Int

Identificação

Tanks

ID

Int

Ligação a tabela Nodes

Tanks

Min_Level

Decimal (19,9)

Cota mínima do reservatório [m]

Tanks

Max_Level

Decimal (19,9)

Cota máxima do reservatório [m]

URC

Use_Reduction_Coef

Bit

Ligação a tabela URC_ID

URC

Description

Char (10)

Descrição do campo anterior (Sim/Não + texto complementar, se necessário)

URC

LANG_ID

Int

Identificação da língua utilizada para o campo anterior

URC_ID

ID

Bit

Identificação

Valves

ID

Int

Ligação a tabela Links

Valves

Type

Int

Ligação a tabela Valves_Type_ID

Valves

Setting

Decimal (19,9)

Parâmetro de funcionamento da válvula

Valves_Type_Desc

Valve_Type_ID

Int

Ligação a tabela Valves_Type_ID

Valves_Type_Desc

Description

NVarCharMax

Descrição do tipo de válvula

Valves_Type_Desc

LANG_ID

Int

Ligação a tabela Languages

Valves_Type_ID

ID

Int

Identificação

Warning_Level

MSG_ID

Int

Identificação

Warning_Level

WARNING_LEVEL

Int

Nível do aviso - liga à tabela Warning_Level_Desc e pode ser usado para, por exeplo, estabelecer um código de côres para as mensagens

Warning_Level_Desc

ID

Int

Ligação a tabela Warning_Level_ID

Warning_Level_Desc

Description

NVarChar (100)

Descrição do nível do aviso

Warning_Level_Desc

LANG_ID

Int

Ligação a tabela Languages

Warning_Level_ID

ID

Int

Identificação

Nota: o campo Datatype refere-se ao formato de dados usado para o valor de cada um dos campos da tabela SQL (Groff, Weinberg 2002).

Tabela 13 – Tipos de redes: Tabela SubNetworks_Type_Desc

ID

Descrição

0

Água Fria

1

Água Quente

Tabela 14 – Dispositivos de utilização e acessórios de rede: Tabela Devices_Type_Desc

ID

Descrição

0

Generico

1

Lavatório individual

2

Lavatório colectivo (por bica)

3

Bidé

4

Banheira

5

Chuveiro individual

6

Pia de despejo com torneira de D15 mm

7

Autoclismo de bacia de retrete

8

Mictório com torneira individual

9

Pia lava-louça

10

Bebedouro

11

Máquina de lavar louça

12

Máquina ou tanque de lavar roupa

13

Bacia de retrete com fluxómetro

14

Mictório com fluxómetro

15

Boca de rega ou de lavagem de D15mm

16

Boca de rega ou de lavagem de D20mm

17

Máquinas industriais e outros aparelhos não especificados

100

Contador

101

Equipamento de produção-acumulação de água quente

102

Purgador  de água

Tabela 15 – Tipos de ligação de rede: Tabela Link_Type_Desc

ID

Descrição

0

Tubagem

1

Válvula

2

Bomba

Tabela 16 – Materiais para canalizações: Tabela Materials_Desc

ID

Descrição

0

Genérico

1

Cobre

2

Aço inoxidável

3

Aço galvanizado

4

PVC rígido

5

Ferro fundido

6

Fibrocimento

7

Polietileno

Tabela 17 – Tipos de válvulas: Tabela Valves_Type_Desc

ID

Descrição

0

Válvula de seccionamento

1

Válvula de retenção

2

Válvula de segurança

3

Válvula redutora de pressão

4

Válvula de regulação

Tabela 18 – Tipos de espaços: Tabela Spaces_Type_Desc

ID

Descrição

0

Espaço Genérico

1

Sala de Estar

2

Sala de Jantar

3

Quarto

4

Quarto de Banho

5

Cozinha

6

Circulações

7

Garagem

100

Exterior

Tabela 19 – Propriedades gerais: Tabela General_Properties

ID

Descrição

0

Pressão mínima na rede pública [kPa]

1

Pressão máxima na rede pública [kPa]

2

Velocidade mínima na rede [m/s], de acordo com Art. 94º.1.b

3

Velocidade máxima na rede [m/s], de acordo com Art. 94º.1.b

4

Pressão de serviço mínima [kPa] de acordo com Art. 87º.2

5

Pressão de serviço máxima [kPa] de acordo com Art. 87º.2

6

Pressão de serviço mínima recomendada [kPa] de acordo com Art. 87º.2

7

Pressão de serviço máxima recomendada [kPa] de acordo com Art. 87º.2

50

Distância mínima entre condutas de água quente e fria [m]

100

Ângulo de conduta com vertical  - tolerância

101

Ângulo de conduta com horizontal  - valor orientativo

102

Factor de tolerância para o paralelismo de vectores u e v - sqrt(uXv.uXv)

103

Distância máxima entre condutas para que estas sejam consideradas no âmbito do Artº 95.3 [m]

104

Comprimento mínimo para análise do Artº 95 [m]

Tabela 20 – Utilização de coeficiente de simultaneidade: Tabela URC

ID

Descrição

Falso

Não usar coeficiente de simultaneidade

Verdadeiro

Usar coeficiente de simultaneidade

Tabela 21 – Tipos de mensagens de sistema: Tabela Calc_Report_Res_Desc

ID

Descrição

100

Pressão mínima requerida por dispositivos a jusante do nó acima de valor permitido pela válvula

150

Velocidade não regulamentar (Art. 94º.1.b)

151

Pressão insuficiente disponível no fluxómetro da bacia de retrete, tendo em atenção a dimensão do respectivo ramal de ligação (Art. 94º.2)

152

Pressão de serviço insuficiente no dispositivo (Art. 87º.2)

153

Pressão de serviço excessiva no dispositivo (Art. 87º.2)

154

Pressão de serviço inferior à recomendada no dispositivo (Art. 87º.2)

155

Pressão de serviço superior à recomendada no dispositivo (Art. 87º.2)

156

Dispositivo sem válvula de seccionamento a montante (Art. 102º.a)

157

Aparelho produtor-acumulador de água quente sem válvula de retenção a montante (Art. 102º.b)

158

Aparelho produtor-acumulador de água quente sem válvula de segurança a montante (Art. 102º.c)

159

Contador sem válvula de seccionamento a jusante (Art. 102º.a)

200

Há paralelismo entre canalizações de água quente e fria (aparentemente) ou dimensão da canalização insuficiente para efectuar a verificação (Artº 95.3)

201

Não há paralelismo entre canalizações de água quente e fria (aparentemente) (Art. 95º.3)

202

Canalizações de águas quentes e frias a uma distância inferior à permitida (Art. 95º.4)

203

Canalização de água quente situada abaixo de canalização de água fria próxima (Art. 95º.3)

204

Traçado de canalização não é horizontal ou vertical (Art. 95º.1)

205

Cozinha ou quarto de banho sem válvula de seccionamento a montante (Art. 102º.a)

Tabela 22 – Avisos: Tabela Warning_Level_ID

ID

Descrição

0

Aprovado

1

Aprovado com reservas

2

Apreciação positiva: Verificação manual recomendada

3

Apreciação negativa: Verificação manual recomendada

4

Reprovado com reservas

5

Reprovado

Anexo C.                    LicAXML

Elements

Allowed_Materials

Calc_Report_Res

Calc_Report_Res_AppliesTo_Desc

Calc_Report_Res_AppliesTo_ID

Calc_Report_Res_Desc

Calc_Report_Res_ID

Devices

Devices_Type

Devices_Type_Desc

Devices_Type_ID

Flow

Fractions_ID

General_Properties

General_Properties_Desc

Languages

Link_Type_Desc

Links

Materials_Desc

Materials_ID

Nodes

Pipe_Roughness

Pipe_Roughness_Desc

Pipes

Pumps

Spaces

Spaces_Type_Desc

Spaces_Type_ID

SubNetworks

SubNetworks_Type_Desc

SubNetworks_Type_ID

Tanks

URC

URC_ID

Valves

Valves_Type_Desc

Valves_Type_ID

Warning_Level

Warning_Level_Desc

Warning_Level_ID

element Allowed_Materials

diagram

properties

content

complex

children

ID IsInside

source

xs:element name="Allowed_Materials"
xs:complexType
xs:sequence
xs:element name="ID"
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element
xs:element name="IsInside" nillable="true" minOccurs="0"
xs:simpleType
xs:restriction base="xs:boolean"/
/xs:simpleType
/xs:element
/xs:sequence
/xs:complexType
/xs:element

element Allowed_Materials/ID

diagram

type

restriction of xs:int

properties

isRef

0

content

simple

facets

minInclusive

-2147483648

maxInclusive

2147483647

source

xs:element name="ID"
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element

element Allowed_Materials/IsInside

diagram

type

restriction of xs:boolean

properties

isRef

0

minOcc

0

maxOcc

1

content

simple

nillable

true

source

xs:element name="IsInside" nillable="true" minOccurs="0"
xs:simpleType
xs:restriction base="xs:boolean"/
/xs:simpleType
/xs:element

element Calc_Report_Res

diagram

properties

content

complex

children

ID MSG_ID MSG_TXT

used by

element

Calc_Report_Res_ID

annotation

documentation

Campo actualmente não utilizado

source

xs:element name="Calc_Report_Res"
xs:annotation
xs:documentationCampo actualmente não utilizado/xs:documentation
/xs:annotation
xs:complexType
xs:sequence
xs:element name="ID" nillable="true" minOccurs="0"
xs:annotation
xs:documentationIdentificação do elemento ao qual se refere a mensagem gerada - combina com dados de Calc_Report_Res_Desc. Ex: 55 (falta de pressão no nó 55)/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element
xs:element name="MSG_ID" nillable="true" minOccurs="0"
xs:annotation
xs:documentationLigação a tabela Calc_Report_Res_ID/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element
xs:element name="MSG_TXT" nillable="true" minOccurs="0"
xs:annotation
xs:documentationCampo actualmente não utilizado/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:string"
xs:maxLength value="500"/
/xs:restriction
/xs:simpleType
/xs:element
/xs:sequence
/xs:complexType
/xs:element

element Calc_Report_Res/ID

diagram

type

restriction of xs:int

properties

isRef

0

minOcc

0

maxOcc

1

content

simple

nillable

true

facets

minInclusive

-2147483648

maxInclusive

2147483647

annotation

documentation

Identificação do elemento ao qual se refere a mensagem gerada - combina com dados de Calc_Report_Res_Desc. Ex: 55 (falta de pressão no nó 55)

source

xs:element name="ID" nillable="true" minOccurs="0"
xs:annotation
xs:documentationIdentificação do elemento ao qual se refere a mensagem gerada - combina com dados de Calc_Report_Res_Desc. Ex: 55 (falta de pressão no nó 55)/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element

element Calc_Report_Res/MSG_ID

diagram

type

restriction of xs:int

properties

isRef

0

minOcc

0

maxOcc

1

content

simple

nillable

true

facets

minInclusive

-2147483648

maxInclusive

2147483647

annotation

documentation

Ligação a tabela Calc_Report_Res_ID

source

xs:element name="MSG_ID" nillable="true" minOccurs="0"
xs:annotation
xs:documentationLigação a tabela Calc_Report_Res_ID/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element

element Calc_Report_Res/MSG_TXT

diagram

type

restriction of xs:string

properties

isRef

0

minOcc

0

maxOcc

1

content

simple

nillable

true

facets

maxLength

500

annotation

documentation

Campo actualmente não utilizado

source

xs:element name="MSG_TXT" nillable="true" minOccurs="0"
xs:annotation
xs:documentationCampo actualmente não utilizado/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:string"
xs:maxLength value="500"/
/xs:restriction
/xs:simpleType
/xs:element

element Calc_Report_Res_AppliesTo_Desc

diagram

properties

content

complex

children

ID Lang_ID Description

used by

elements

Calc_Report_Res_AppliesTo_ID Languages

source

xs:element name="Calc_Report_Res_AppliesTo_Desc"
xs:complexType
xs:sequence
xs:element name="ID" nillable="true" minOccurs="0"
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element
xs:element name="Lang_ID" nillable="true" minOccurs="0"
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element
xs:element name="Description" nillable="true" minOccurs="0"
xs:simpleType
xs:restriction base="xs:string"
xs:maxLength value="100"/
/xs:restriction
/xs:simpleType
/xs:element
/xs:sequence
/xs:complexType
/xs:element

element Calc_Report_Res_AppliesTo_Desc/ID

diagram

type

restriction of xs:int

properties

isRef

0

minOcc

0

maxOcc

1

content

simple

nillable

true

facets

minInclusive

-2147483648

maxInclusive

2147483647

source

xs:element name="ID" nillable="true" minOccurs="0"
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element

element Calc_Report_Res_AppliesTo_Desc/Lang_ID

diagram

type

restriction of xs:int

properties

isRef

0

minOcc

0

maxOcc

1

content

simple

nillable

true

facets

minInclusive

-2147483648

maxInclusive

2147483647

source

xs:element name="Lang_ID" nillable="true" minOccurs="0"
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element

element Calc_Report_Res_AppliesTo_Desc/Description

diagram

type

restriction of xs:string

properties

isRef

0

minOcc

0

maxOcc

1

content

simple

nillable

true

facets

maxLength

100

source

xs:element name="Description" nillable="true" minOccurs="0"
xs:simpleType
xs:restriction base="xs:string"
xs:maxLength value="100"/
/xs:restriction
/xs:simpleType
/xs:element

element Calc_Report_Res_AppliesTo_ID

diagram

properties

content

complex

children

ID Calc_Report_Res_ID Calc_Report_Res_AppliesTo_Desc

identity constraints

Name

Refer

Selector

Field(s)

key

Calc_Report_Res_AppliesTo_ID_PrimaryKey_1

.

ID

keyref

Calc_Report_Res_ID_ForeignKey_1

Calc_Report_Res_AppliesTo_ID_PrimaryKey_1

Calc_Report_Res_ID

AppliesTo

keyref

Calc_Report_Res_AppliesTo_Desc_ForeignKey_1

Calc_Report_Res_AppliesTo_ID_PrimaryKey_1

Calc_Report_Res_AppliesTo_Desc

ID

source

xs:element name="Calc_Report_Res_AppliesTo_ID"
xs:complexType
xs:sequence
xs:element name="ID"
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element
xs:element ref="Calc_Report_Res_ID" minOccurs="0" maxOccurs="unbounded"/
xs:element ref="Calc_Report_Res_AppliesTo_Desc" minOccurs="0" maxOccurs="unbounded"/
/xs:sequence
/xs:complexType
xs:key name="Calc_Report_Res_AppliesTo_ID_PrimaryKey_1"
xs:selector xpath="."/
xs:field xpath="ID"/
/xs:key
xs:keyref name="Calc_Report_Res_ID_ForeignKey_1" refer="Calc_Report_Res_AppliesTo_ID_PrimaryKey_1"
xs:selector xpath="Calc_Report_Res_ID"/
xs:field xpath="AppliesTo"/
/xs:keyref
xs:keyref name="Calc_Report_Res_AppliesTo_Desc_ForeignKey_1" refer="Calc_Report_Res_AppliesTo_ID_PrimaryKey_1"
xs:selector xpath="Calc_Report_Res_AppliesTo_Desc"/
xs:field xpath="ID"/
/xs:keyref
/xs:element

element Calc_Report_Res_AppliesTo_ID/ID

diagram

type

restriction of xs:int

properties

isRef

0

content

simple

facets

minInclusive

-2147483648

maxInclusive

2147483647

source

xs:element name="ID"
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element

element Calc_Report_Res_Desc

diagram

properties

content

complex

children

MSG_ID MSG_TXT LANG_ID

used by

element

Calc_Report_Res_ID

identity constraints

Name

Refer

Selector

Field(s)

unique

Calc_Report_Res_Desc_UniqueKey_1

.

MSG_ID

LANG_ID

annotation

documentation

Identificação da língua em que está escrita a mensagem

source

xs:element name="Calc_Report_Res_Desc"
xs:annotation
xs:documentationIdentificação da língua em que está escrita a mensagem/xs:documentation
/xs:annotation
xs:complexType
xs:sequence
xs:element name="MSG_ID" nillable="true" minOccurs="0"
xs:annotation
xs:documentationLigação a tabela Calc_Report_Res_ID/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element
xs:element name="MSG_TXT" nillable="true" minOccurs="0"
xs:annotation
xs:documentationTexto a incluir no relatório a produzir/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:string"
xs:maxLength value="1073741823"/
/xs:restriction
/xs:simpleType
/xs:element
xs:element name="LANG_ID" nillable="true" minOccurs="0"
xs:annotation
xs:documentationIdentificação da língua em que está escrita a mensagem/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element
/xs:sequence
/xs:complexType
xs:unique name="Calc_Report_Res_Desc_UniqueKey_1"
xs:selector xpath="."/
xs:field xpath="MSG_ID"/
xs:field xpath="LANG_ID"/
/xs:unique
/xs:element

element Calc_Report_Res_Desc/MSG_ID

diagram

type

restriction of xs:int

properties

isRef

0

minOcc

0

maxOcc

1

content

simple

nillable

true

facets

minInclusive

-2147483648

maxInclusive

2147483647

annotation

documentation

Ligação a tabela Calc_Report_Res_ID

source

xs:element name="MSG_ID" nillable="true" minOccurs="0"
xs:annotation
xs:documentationLigação a tabela Calc_Report_Res_ID/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element

element Calc_Report_Res_Desc/MSG_TXT

diagram

type

restriction of xs:string

properties

isRef

0

minOcc

0

maxOcc

1

content

simple

nillable

true

facets

maxLength

1073741823

annotation

documentation

Texto a incluir no relatório a produzir

source

xs:element name="MSG_TXT" nillable="true" minOccurs="0"
xs:annotation
xs:documentationTexto a incluir no relatório a produzir/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:string"
xs:maxLength value="1073741823"/
/xs:restriction
/xs:simpleType
/xs:element

element Calc_Report_Res_Desc/LANG_ID

diagram

type

restriction of xs:int

properties

isRef

0

minOcc

0

maxOcc

1

content

simple

nillable

true

facets

minInclusive

-2147483648

maxInclusive

2147483647

annotation

documentation

Identificação da língua em que está escrita a mensagem

source

xs:element name="LANG_ID" nillable="true" minOccurs="0"
xs:annotation
xs:documentationIdentificação da língua em que está escrita a mensagem/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element

element Calc_Report_Res_ID

diagram

properties

content

complex

children

ID ArtID AppliesTo Calc_Report_Res Calc_Report_Res_Desc

used by

element

Calc_Report_Res_AppliesTo_ID

identity constraints

Name

Refer

Selector

Field(s)

key

Calc_Report_Res_ID_PrimaryKey_1

.

ID

keyref

Calc_Report_Res_ForeignKey_1

Calc_Report_Res_ID_PrimaryKey_1

Calc_Report_Res

MSG_ID

keyref

Calc_Report_Res_Desc_ForeignKey_1

Calc_Report_Res_ID_PrimaryKey_1

Calc_Report_Res_Desc

MSG_ID

annotation

documentation

Identificação

source

xs:element name="Calc_Report_Res_ID"
xs:annotation
xs:documentationIdentificação/xs:documentation
/xs:annotation
xs:complexType
xs:sequence
xs:element name="ID"
xs:annotation
xs:documentationIdentificação/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element
xs:element name="ArtID" nillable="true" minOccurs="0"
xs:simpleType
xs:restriction base="xs:string"
xs:maxLength value="20"/
/xs:restriction
/xs:simpleType
/xs:element
xs:element name="AppliesTo" nillable="true" minOccurs="0"
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element
xs:element ref="Calc_Report_Res" minOccurs="0" maxOccurs="unbounded"/
xs:element ref="Calc_Report_Res_Desc" minOccurs="0" maxOccurs="unbounded"/
/xs:sequence
/xs:complexType
xs:key name="Calc_Report_Res_ID_PrimaryKey_1"
xs:selector xpath="."/
xs:field xpath="ID"/
/xs:key
xs:keyref name="Calc_Report_Res_ForeignKey_1" refer="Calc_Report_Res_ID_PrimaryKey_1"
xs:selector xpath="Calc_Report_Res"/
xs:field xpath="MSG_ID"/
/xs:keyref
xs:keyref name="Calc_Report_Res_Desc_ForeignKey_1" refer="Calc_Report_Res_ID_PrimaryKey_1"
xs:selector xpath="Calc_Report_Res_Desc"/
xs:field xpath="MSG_ID"/
/xs:keyref
/xs:element

element Calc_Report_Res_ID/ID

diagram

type

restriction of xs:int

properties

isRef

0

content

simple

facets

minInclusive

-2147483648

maxInclusive

2147483647

annotation

documentation

Identificação

source

xs:element name="ID"
xs:annotation
xs:documentationIdentificação/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element

element Calc_Report_Res_ID/ArtID

diagram

type

restriction of xs:string

properties

isRef

0

minOcc

0

maxOcc

1

content

simple

nillable

true

facets

maxLength

20

source

xs:element name="ArtID" nillable="true" minOccurs="0"
xs:simpleType
xs:restriction base="xs:string"
xs:maxLength value="20"/
/xs:restriction
/xs:simpleType
/xs:element

element Calc_Report_Res_ID/AppliesTo

diagram

type

restriction of xs:int

properties

isRef

0

minOcc

0

maxOcc

1

content

simple

nillable

true

facets

minInclusive

-2147483648

maxInclusive

2147483647

source

xs:element name="AppliesTo" nillable="true" minOccurs="0"
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element

element Devices

diagram

properties

content

complex

children

ID Device_Type_ID Space_ID Flow

used by

elements

Devices_Type_ID Spaces

identity constraints

Name

Refer

Selector

Field(s)

key

Devices_PrimaryKey_1

.

ID

keyref

Flow_ForeignKey_1

Devices_PrimaryKey_1

Flow

Device_ID

annotation

documentation

Ligação a tabela Spaces

source

xs:element name="Devices"
xs:annotation
xs:documentationLigação a tabela Spaces/xs:documentation
/xs:annotation
xs:complexType
xs:sequence
xs:element name="ID"
xs:annotation
xs:documentationIdentificação/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element
xs:element name="Device_Type_ID"
xs:annotation
xs:documentationLigação a tabela Devices_Type_ID/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element
xs:element name="Space_ID" nillable="true" minOccurs="0"
xs:annotation
xs:documentationLigação a tabela Spaces/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element
xs:element ref="Flow" minOccurs="0" maxOccurs="unbounded"/
/xs:sequence
/xs:complexType
xs:key name="Devices_PrimaryKey_1"
xs:selector xpath="."/
xs:field xpath="ID"/
/xs:key
xs:keyref name="Flow_ForeignKey_1" refer="Devices_PrimaryKey_1"
xs:selector xpath="Flow"/
xs:field xpath="Device_ID"/
/xs:keyref
/xs:element

element Devices/ID

diagram

type

restriction of xs:int

properties

isRef

0

content

simple

facets

minInclusive

-2147483648

maxInclusive

2147483647

annotation

documentation

Identificação

source

xs:element name="ID"
xs:annotation
xs:documentationIdentificação/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element

element Devices/Device_Type_ID

diagram

type

restriction of xs:int

properties

isRef

0

content

simple

facets

minInclusive

-2147483648

maxInclusive

2147483647

annotation

documentation

Ligação a tabela Devices_Type_ID

source

xs:element name="Device_Type_ID"
xs:annotation
xs:documentationLigação a tabela Devices_Type_ID/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element

element Devices/Space_ID

diagram

type

restriction of xs:int

properties

isRef

0

minOcc

0

maxOcc

1

content

simple

nillable

true

facets

minInclusive

-2147483648

maxInclusive

2147483647

annotation

documentation

Ligação a tabela Spaces

source

xs:element name="Space_ID" nillable="true" minOccurs="0"
xs:annotation
xs:documentationLigação a tabela Spaces/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element

element Devices_Type

diagram

properties

content

complex

children

ID Min_Reg_Flow URC

used by

element

Devices_Type_ID

identity constraints

Name

Refer

Selector

Field(s)

key

Devices_Type_PrimaryKey_1

.

ID

source

xs:element name="Devices_Type"
xs:complexType
xs:sequence
xs:element name="ID"
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element
xs:element name="Min_Reg_Flow" default="0"
xs:simpleType
xs:restriction base="xs:decimal"
xs:totalDigits value="19"/
xs:fractionDigits value="9"/
xs:minExclusive value="-10000000000"/
xs:maxExclusive value="10000000000"/
/xs:restriction
/xs:simpleType
/xs:element
xs:element name="URC" default="1"
xs:simpleType
xs:restriction base="xs:boolean"/
/xs:simpleType
/xs:element
/xs:sequence
/xs:complexType
xs:key name="Devices_Type_PrimaryKey_1"
xs:selector xpath="."/
xs:field xpath="ID"/
/xs:key
/xs:element

element Devices_Type/ID

diagram

type

restriction of xs:int

properties

isRef

0

content

simple

facets

minInclusive

-2147483648

maxInclusive

2147483647

source

xs:element name="ID"
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element

element Devices_Type/Min_Reg_Flow

diagram

type

restriction of xs:decimal

properties

isRef

0

content

simple

default

0

facets

minExclusive

-10000000000

maxExclusive

10000000000

totalDigits

19

fractionDigits

9

source

xs:element name="Min_Reg_Flow" default="0"
xs:simpleType
xs:restriction base="xs:decimal"
xs:totalDigits value="19"/
xs:fractionDigits value="9"/
xs:minExclusive value="-10000000000"/
xs:maxExclusive value="10000000000"/
/xs:restriction
/xs:simpleType
/xs:element

element Devices_Type/URC

diagram

type

restriction of xs:boolean

properties

isRef

0

content

simple

default

1

used by

element

URC_ID

source

xs:element name="URC" default="1"
xs:simpleType
xs:restriction base="xs:boolean"/
/xs:simpleType
/xs:element

element Devices_Type_Desc

diagram

properties

content

complex

children

ID Description LANG_ID

used by

elements

Devices_Type_ID Languages

identity constraints

Name

Refer

Selector

Field(s)

unique

Devices_Type_Desc_UniqueKey_1

.

ID

LANG_ID

annotation

documentation

Ligação a tabela Languages

source

xs:element name="Devices_Type_Desc"
xs:annotation
xs:documentationLigação a tabela Languages/xs:documentation
/xs:annotation
xs:complexType
xs:sequence
xs:element name="ID" nillable="true" minOccurs="0"
xs:annotation
xs:documentationLigação a tabela Devices_Type_ID/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element
xs:element name="Description" nillable="true" minOccurs="0"
xs:annotation
xs:documentationDescrição do acessório de rede/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:string"
xs:maxLength value="1073741823"/
/xs:restriction
/xs:simpleType
/xs:element
xs:element name="LANG_ID" nillable="true" minOccurs="0"
xs:annotation
xs:documentationLigação a tabela Languages/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element
/xs:sequence
/xs:complexType
xs:unique name="Devices_Type_Desc_UniqueKey_1"
xs:selector xpath="."/
xs:field xpath="ID"/
xs:field xpath="LANG_ID"/
/xs:unique
/xs:element

element Devices_Type_Desc/ID

diagram

type

restriction of xs:int

properties

isRef

0

minOcc

0

maxOcc

1

content

simple

nillable

true

facets

minInclusive

-2147483648

maxInclusive

2147483647

annotation

documentation

Ligação a tabela Devices_Type_ID

source

xs:element name="ID" nillable="true" minOccurs="0"
xs:annotation
xs:documentationLigação a tabela Devices_Type_ID/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element

element Devices_Type_Desc/Description

diagram

type

restriction of xs:string

properties

isRef

0

minOcc

0

maxOcc

1

content

simple

nillable

true

facets

maxLength

1073741823

annotation

documentation

Descrição do acessório de rede

source

xs:element name="Description" nillable="true" minOccurs="0"
xs:annotation
xs:documentationDescrição do acessório de rede/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:string"
xs:maxLength value="1073741823"/
/xs:restriction
/xs:simpleType
/xs:element

element Devices_Type_Desc/LANG_ID

diagram

type

restriction of xs:int

properties

isRef

0

minOcc

0

maxOcc

1

content

simple

nillable

true

facets

minInclusive

-2147483648

maxInclusive

2147483647

annotation

documentation

Ligação a tabela Languages

source

xs:element name="LANG_ID" nillable="true" minOccurs="0"
xs:annotation
xs:documentationLigação a tabela Languages/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element

element Devices_Type_ID

diagram

properties

content

complex

children

ID Devices Devices_Type Devices_Type_Desc

identity constraints

Name

Refer

Selector

Field(s)

key

Devices_Type_ID_PrimaryKey_1

.

ID

keyref

Devices_ForeignKey_1

Devices_Type_ID_PrimaryKey_1

Devices

Device_Type_ID

keyref

Devices_Type_ForeignKey_1

Devices_Type_ID_PrimaryKey_1

Devices_Type

ID

keyref

Devices_Type_Desc_ForeignKey_2

Devices_Type_ID_PrimaryKey_1

Devices_Type_Desc

ID

annotation

documentation

Identificação

source

xs:element name="Devices_Type_ID"
xs:annotation
xs:documentationIdentificação/xs:documentation
/xs:annotation
xs:complexType
xs:sequence
xs:element name="ID"
xs:annotation
xs:documentationIdentificação/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element
xs:element ref="Devices" minOccurs="0" maxOccurs="unbounded"/
xs:element ref="Devices_Type" minOccurs="0" maxOccurs="unbounded"/
xs:element ref="Devices_Type_Desc" minOccurs="0" maxOccurs="unbounded"/
/xs:sequence
/xs:complexType
xs:key name="Devices_Type_ID_PrimaryKey_1"
xs:selector xpath="."/
xs:field xpath="ID"/
/xs:key
xs:keyref name="Devices_ForeignKey_1" refer="Devices_Type_ID_PrimaryKey_1"
xs:selector xpath="Devices"/
xs:field xpath="Device_Type_ID"/
/xs:keyref
xs:keyref name="Devices_Type_ForeignKey_1" refer="Devices_Type_ID_PrimaryKey_1"
xs:selector xpath="Devices_Type"/
xs:field xpath="ID"/
/xs:keyref
xs:keyref name="Devices_Type_Desc_ForeignKey_2" refer="Devices_Type_ID_PrimaryKey_1"
xs:selector xpath="Devices_Type_Desc"/
xs:field xpath="ID"/
/xs:keyref
/xs:element

element Devices_Type_ID/ID

diagram

type

restriction of xs:int

properties

isRef

0

content

simple

facets

minInclusive

-2147483648

maxInclusive

2147483647

annotation

documentation

Identificação

source

xs:element name="ID"
xs:annotation
xs:documentationIdentificação/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element

element Flow

diagram

properties

content

complex

children

ID Node_ID Flow Use_Reduction_Coef Device_ID Hmin

used by

elements

Devices Nodes URC_ID

identity constraints

Name

Refer

Selector

Field(s)

key

Flow_PrimaryKey_1

.

ID

annotation

documentation

Pressão mínima necessária para o funcionamento do equipamento [m]

source

xs:element name="Flow"
xs:annotation
xs:documentationPressão mínima necessária para o funcionamento do equipamento [m]/xs:documentation
/xs:annotation
xs:complexType
xs:sequence
xs:element name="ID"
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element
xs:element name="Node_ID"
xs:annotation
xs:documentationLigação a tabela Nodes/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element
xs:element name="Flow" nillable="true" minOccurs="0"
xs:annotation
xs:documentationCaudal [m3/s]/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:decimal"
xs:totalDigits value="19"/
xs:fractionDigits value="9"/
xs:minExclusive value="-10000000000"/
xs:maxExclusive value="10000000000"/
/xs:restriction
/xs:simpleType
/xs:element
xs:element name="Use_Reduction_Coef"
xs:annotation
xs:documentationLigação a tabela URC_ID/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:boolean"/
/xs:simpleType
/xs:element
xs:element name="Device_ID" default="0"
xs:annotation
xs:documentationLigação a tabela Devices/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element
xs:element name="Hmin" nillable="true" minOccurs="0"
xs:annotation
xs:documentationPressão mínima necessária para o funcionamento do equipamento [m]/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:decimal"
xs:totalDigits value="19"/
xs:fractionDigits value="9"/
xs:minExclusive value="-10000000000"/
xs:maxExclusive value="10000000000"/
/xs:restriction
/xs:simpleType
/xs:element
/xs:sequence
/xs:complexType
xs:key name="Flow_PrimaryKey_1"
xs:selector xpath="."/
xs:field xpath="ID"/
/xs:key
/xs:element

element Flow/ID

diagram

type

restriction of xs:int

properties

isRef

0

content

simple

facets

minInclusive

-2147483648

maxInclusive

2147483647

source

xs:element name="ID"
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element

element Flow/Node_ID

diagram

type

restriction of xs:int

properties

isRef

0

content

simple

facets

minInclusive

-2147483648

maxInclusive

2147483647

annotation

documentation

Ligação a tabela Nodes

source

xs:element name="Node_ID"
xs:annotation
xs:documentationLigação a tabela Nodes/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element

element Flow/Flow

diagram

type

restriction of xs:decimal

properties

isRef

0

minOcc

0

maxOcc

1

content

simple

nillable

true

used by

elements

Devices Nodes URC_ID

facets

minExclusive

-10000000000

maxExclusive

10000000000

totalDigits

19

fractionDigits

9

annotation

documentation

Caudal [m3/s]

source

xs:element name="Flow" nillable="true" minOccurs="0"
xs:annotation
xs:documentationCaudal [m3/s]/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:decimal"
xs:totalDigits value="19"/
xs:fractionDigits value="9"/
xs:minExclusive value="-10000000000"/
xs:maxExclusive value="10000000000"/
/xs:restriction
/xs:simpleType
/xs:element

element Flow/Use_Reduction_Coef

diagram

type

restriction of xs:boolean

properties

isRef

0

content

simple

annotation

documentation

Ligação a tabela URC_ID

source

xs:element name="Use_Reduction_Coef"
xs:annotation
xs:documentationLigação a tabela URC_ID/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:boolean"/
/xs:simpleType
/xs:element

element Flow/Device_ID

diagram

type

restriction of xs:int

properties

isRef

0

content

simple

default

0

facets

minInclusive

-2147483648

maxInclusive

2147483647

annotation

documentation

Ligação a tabela Devices

source

xs:element name="Device_ID" default="0"
xs:annotation
xs:documentationLigação a tabela Devices/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element

element Flow/Hmin

diagram

type

restriction of xs:decimal

properties

isRef

0

minOcc

0

maxOcc

1

content

simple

nillable

true

facets

minExclusive

-10000000000

maxExclusive

10000000000

totalDigits

19

fractionDigits

9

annotation

documentation

Pressão mínima necessária para o funcionamento do equipamento [m]

source

xs:element name="Hmin" nillable="true" minOccurs="0"
xs:annotation
xs:documentationPressão mínima necessária para o funcionamento do equipamento [m]/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:decimal"
xs:totalDigits value="19"/
xs:fractionDigits value="9"/
xs:minExclusive value="-10000000000"/
xs:maxExclusive value="10000000000"/
/xs:restriction
/xs:simpleType
/xs:element

element Fractions_ID

diagram

properties

content

complex

children

ID

identity constraints

Name

Refer

Selector

Field(s)

key

Fractions_ID_PrimaryKey_1

.

ID

source

xs:element name="Fractions_ID"
xs:complexType
xs:sequence
xs:element name="ID"
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element
/xs:sequence
/xs:complexType
xs:key name="Fractions_ID_PrimaryKey_1"
xs:selector xpath="."/
xs:field xpath="ID"/
/xs:key
/xs:element

element Fractions_ID/ID

diagram

type

restriction of xs:int

properties

isRef

0

content

simple

facets

minInclusive

-2147483648

maxInclusive

2147483647

source

xs:element name="ID"
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element

element General_Properties

diagram

properties

content

complex

children

ID VAL General_Properties_Desc

identity constraints

Name

Refer

Selector

Field(s)

key

General_Properties_PrimaryKey_1

.

ID

keyref

General_Properties_Desc_ForeignKey_1

General_Properties_PrimaryKey_1

General_Properties_Desc

ID

annotation

documentation

Constante a utilizar para o parâmetro

source

xs:element name="General_Properties"
xs:annotation
xs:documentationConstante a utilizar para o parâmetro/xs:documentation
/xs:annotation
xs:complexType
xs:sequence
xs:element name="ID"
xs:annotation
xs:documentationIdentificação/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element
xs:element name="VAL" nillable="true" minOccurs="0"
xs:annotation
xs:documentationConstante a utilizar para o parâmetro/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:decimal"
xs:totalDigits value="19"/
xs:fractionDigits value="9"/
xs:minExclusive value="-10000000000"/
xs:maxExclusive value="10000000000"/
/xs:restriction
/xs:simpleType
/xs:element
xs:element ref="General_Properties_Desc" minOccurs="0" maxOccurs="unbounded"/
/xs:sequence
/xs:complexType
xs:key name="General_Properties_PrimaryKey_1"
xs:selector xpath="."/
xs:field xpath="ID"/
/xs:key
xs:keyref name="General_Properties_Desc_ForeignKey_1" refer="General_Properties_PrimaryKey_1"
xs:selector xpath="General_Properties_Desc"/
xs:field xpath="ID"/
/xs:keyref
/xs:element

element General_Properties/ID

diagram

type

restriction of xs:int

properties

isRef

0

content

simple

facets

minInclusive

-2147483648

maxInclusive

2147483647

annotation

documentation

Identificação

source

xs:element name="ID"
xs:annotation
xs:documentationIdentificação/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element

element General_Properties/VAL

diagram

type

restriction of xs:decimal

properties

isRef

0

minOcc

0

maxOcc

1

content

simple

nillable

true

facets

minExclusive

-10000000000

maxExclusive

10000000000

totalDigits

19

fractionDigits

9

annotation

documentation

Constante a utilizar para o parâmetro

source

xs:element name="VAL" nillable="true" minOccurs="0"
xs:annotation
xs:documentationConstante a utilizar para o parâmetro/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:decimal"
xs:totalDigits value="19"/
xs:fractionDigits value="9"/
xs:minExclusive value="-10000000000"/
xs:maxExclusive value="10000000000"/
/xs:restriction
/xs:simpleType
/xs:element

element General_Properties_Desc

diagram

properties

content

complex

children

ID Description LANG_ID

used by

elements

General_Properties Languages

identity constraints

Name

Refer

Selector

Field(s)

unique

General_Properties_Desc_UniqueKey_1

.

ID

LANG_ID

annotation

documentation

Ligação a tabela Languages

source

xs:element name="General_Properties_Desc"
xs:annotation
xs:documentationLigação a tabela Languages/xs:documentation
/xs:annotation
xs:complexType
xs:sequence
xs:element name="ID" nillable="true" minOccurs="0"
xs:annotation
xs:documentationLigação a tabela General_Properties/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element
xs:element name="Description" nillable="true" minOccurs="0"
xs:annotation
xs:documentationDescrição do parâmetro (texto)/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:string"
xs:maxLength value="500"/
/xs:restriction
/xs:simpleType
/xs:element
xs:element name="LANG_ID" nillable="true" minOccurs="0"
xs:annotation
xs:documentationLigação a tabela Languages/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element
/xs:sequence
/xs:complexType
xs:unique name="General_Properties_Desc_UniqueKey_1"
xs:selector xpath="."/
xs:field xpath="ID"/
xs:field xpath="LANG_ID"/
/xs:unique
/xs:element

element General_Properties_Desc/ID

diagram

type

restriction of xs:int

properties

isRef

0

minOcc

0

maxOcc

1

content

simple

nillable

true

facets

minInclusive

-2147483648

maxInclusive

2147483647

annotation

documentation

Ligação a tabela General_Properties

source

xs:element name="ID" nillable="true" minOccurs="0"
xs:annotation
xs:documentationLigação a tabela General_Properties/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element

element General_Properties_Desc/Description

diagram

type

restriction of xs:string

properties

isRef

0

minOcc

0

maxOcc

1

content

simple

nillable

true

facets

maxLength

500

annotation

documentation

Descrição do parâmetro (texto)

source

xs:element name="Description" nillable="true" minOccurs="0"
xs:annotation
xs:documentationDescrição do parâmetro (texto)/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:string"
xs:maxLength value="500"/
/xs:restriction
/xs:simpleType
/xs:element

element General_Properties_Desc/LANG_ID

diagram

type

restriction of xs:int

properties

isRef

0

minOcc

0

maxOcc

1

content

simple

nillable

true

facets

minInclusive

-2147483648

maxInclusive

2147483647

annotation

documentation

Ligação a tabela Languages

source

xs:element name="LANG_ID" nillable="true" minOccurs="0"
xs:annotation
xs:documentationLigação a tabela Languages/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element

element Languages

diagram

properties

content

complex

children

LANG_ID Language Calc_Report_Res_AppliesTo_Desc Devices_Type_Desc General_Properties_Desc Link_Type_Desc Materials_Desc Pipe_Roughness_Desc Spaces_Type_Desc SubNetworks_Type_Desc Valves_Type_Desc Warning_Level_Desc

identity constraints

Name

Refer

Selector

Field(s)

key

Languages_PrimaryKey_1

.

LANG_ID

keyref

Calc_Report_Res_AppliesTo_Desc_ForeignKey_2

Languages_PrimaryKey_1

Calc_Report_Res_AppliesTo_Desc

Lang_ID

keyref

Devices_Type_Desc_ForeignKey_1

Languages_PrimaryKey_1

Devices_Type_Desc

LANG_ID

keyref

General_Properties_Desc_ForeignKey_2

Languages_PrimaryKey_1

General_Properties_Desc

LANG_ID

keyref

Link_Type_Desc_ForeignKey_1

Languages_PrimaryKey_1

Link_Type_Desc

LANG_ID

keyref

Materials_Desc_ForeignKey_1

Languages_PrimaryKey_1

Materials_Desc

LANG_ID

keyref

Pipe_Roughness_Desc_ForeignKey_1

Languages_PrimaryKey_1

Pipe_Roughness_Desc

LANG_ID

keyref

Spaces_Type_Desc_ForeignKey_1

Languages_PrimaryKey_1

Spaces_Type_Desc

LANG_ID

keyref

SubNetworks_Type_Desc_ForeignKey_1

Languages_PrimaryKey_1

SubNetworks_Type_Desc

LANG_ID

keyref

Valves_Type_Desc_ForeignKey_1

Languages_PrimaryKey_1

Valves_Type_Desc

LANG_ID

keyref

Warning_Level_Desc_ForeignKey_1

Languages_PrimaryKey_1

Warning_Level_Desc

LANG_ID

annotation

documentation

Nome da língua (texto)

source

xs:element name="Languages"
xs:annotation
xs:documentationNome da língua (texto)/xs:documentation
/xs:annotation
xs:complexType
xs:sequence
xs:element name="LANG_ID"
xs:annotation
xs:documentationIdentificação/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element
xs:element name="Language" nillable="true" minOccurs="0"
xs:annotation
xs:documentationNome da língua (texto)/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:string"
xs:maxLength value="50"/
/xs:restriction
/xs:simpleType
/xs:element
xs:element ref="Calc_Report_Res_AppliesTo_Desc" minOccurs="0" maxOccurs="unbounded"/
xs:element ref="Devices_Type_Desc" minOccurs="0" maxOccurs="unbounded"/
xs:element ref="General_Properties_Desc" minOccurs="0" maxOccurs="unbounded"/
xs:element ref="Link_Type_Desc" minOccurs="0" maxOccurs="unbounded"/
xs:element ref="Materials_Desc" minOccurs="0" maxOccurs="unbounded"/
xs:element ref="Pipe_Roughness_Desc" minOccurs="0" maxOccurs="unbounded"/
xs:element ref="Spaces_Type_Desc" minOccurs="0" maxOccurs="unbounded"/
xs:element ref="SubNetworks_Type_Desc" minOccurs="0" maxOccurs="unbounded"/
xs:element ref="Valves_Type_Desc" minOccurs="0" maxOccurs="unbounded"/
xs:element ref="Warning_Level_Desc" minOccurs="0" maxOccurs="unbounded"/
/xs:sequence
/xs:complexType
xs:key name="Languages_PrimaryKey_1"
xs:selector xpath="."/
xs:field xpath="LANG_ID"/
/xs:key
xs:keyref name="Calc_Report_Res_AppliesTo_Desc_ForeignKey_2" refer="Languages_PrimaryKey_1"
xs:selector xpath="Calc_Report_Res_AppliesTo_Desc"/
xs:field xpath="Lang_ID"/
/xs:keyref
xs:keyref name="Devices_Type_Desc_ForeignKey_1" refer="Languages_PrimaryKey_1"
xs:selector xpath="Devices_Type_Desc"/
xs:field xpath="LANG_ID"/
/xs:keyref
xs:keyref name="General_Properties_Desc_ForeignKey_2" refer="Languages_PrimaryKey_1"
xs:selector xpath="General_Properties_Desc"/
xs:field xpath="LANG_ID"/
/xs:keyref
xs:keyref name="Link_Type_Desc_ForeignKey_1" refer="Languages_PrimaryKey_1"
xs:selector xpath="Link_Type_Desc"/
xs:field xpath="LANG_ID"/
/xs:keyref
xs:keyref name="Materials_Desc_ForeignKey_1" refer="Languages_PrimaryKey_1"
xs:selector xpath="Materials_Desc"/
xs:field xpath="LANG_ID"/
/xs:keyref
xs:keyref name="Pipe_Roughness_Desc_ForeignKey_1" refer="Languages_PrimaryKey_1"
xs:selector xpath="Pipe_Roughness_Desc"/
xs:field xpath="LANG_ID"/
/xs:keyref
xs:keyref name="Spaces_Type_Desc_ForeignKey_1" refer="Languages_PrimaryKey_1"
xs:selector xpath="Spaces_Type_Desc"/
xs:field xpath="LANG_ID"/
/xs:keyref
xs:keyref name="SubNetworks_Type_Desc_ForeignKey_1" refer="Languages_PrimaryKey_1"
xs:selector xpath="SubNetworks_Type_Desc"/
xs:field xpath="LANG_ID"/
/xs:keyref
xs:keyref name="Valves_Type_Desc_ForeignKey_1" refer="Languages_PrimaryKey_1"
xs:selector xpath="Valves_Type_Desc"/
xs:field xpath="LANG_ID"/
/xs:keyref
xs:keyref name="Warning_Level_Desc_ForeignKey_1" refer="Languages_PrimaryKey_1"
xs:selector xpath="Warning_Level_Desc"/
xs:field xpath="LANG_ID"/
/xs:keyref
/xs:element

element Languages/LANG_ID

diagram

type

restriction of xs:int

properties

isRef

0

content

simple

facets

minInclusive

-2147483648

maxInclusive

2147483647

annotation

documentation

Identificação

source

xs:element name="LANG_ID"
xs:annotation
xs:documentationIdentificação/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element

element Languages/Language

diagram

type

restriction of xs:string

properties

isRef

0

minOcc

0

maxOcc

1

content

simple

nillable

true

facets

maxLength

50

annotation

documentation

Nome da língua (texto)

source

xs:element name="Language" nillable="true" minOccurs="0"
xs:annotation
xs:documentationNome da língua (texto)/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:string"
xs:maxLength value="50"/
/xs:restriction
/xs:simpleType
/xs:element

element Link_Type_Desc

diagram

properties

content

complex

children

ID Link_Type LANG_ID

used by

element

Languages

identity constraints

Name

Refer

Selector

Field(s)

unique

Link_Type_Desc_UniqueKey_1

.

ID

LANG_ID

annotation

documentation

Ligação a tabela Languages

source

xs:element name="Link_Type_Desc"
xs:annotation
xs:documentationLigação a tabela Languages/xs:documentation
/xs:annotation
xs:complexType
xs:sequence
xs:element name="ID" nillable="true" minOccurs="0"
xs:annotation
xs:documentationIdentificação do tipo de ligação/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element
xs:element name="Link_Type" nillable="true" minOccurs="0"
xs:annotation
xs:documentationDescrição do tipo de ligação/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:string"
xs:maxLength value="50"/
/xs:restriction
/xs:simpleType
/xs:element
xs:element name="LANG_ID" nillable="true" minOccurs="0"
xs:annotation
xs:documentationLigação a tabela Languages/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element
/xs:sequence
/xs:complexType
xs:unique name="Link_Type_Desc_UniqueKey_1"
xs:selector xpath="."/
xs:field xpath="ID"/
xs:field xpath="LANG_ID"/
/xs:unique
/xs:element

element Link_Type_Desc/ID

diagram

type

restriction of xs:int

properties

isRef

0

minOcc

0

maxOcc

1

content

simple

nillable

true

facets

minInclusive

-2147483648

maxInclusive

2147483647

annotation

documentation

Identificação do tipo de ligação

source

xs:element name="ID" nillable="true" minOccurs="0"
xs:annotation
xs:documentationIdentificação do tipo de ligação/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element

element Link_Type_Desc/Link_Type

diagram

type

restriction of xs:string

properties

isRef

0

minOcc

0

maxOcc

1

content

simple

nillable

true

facets

maxLength

50

annotation

documentation

Descrição do tipo de ligação

source

xs:element name="Link_Type" nillable="true" minOccurs="0"
xs:annotation
xs:documentationDescrição do tipo de ligação/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:string"
xs:maxLength value="50"/
/xs:restriction
/xs:simpleType
/xs:element

element Link_Type_Desc/LANG_ID

diagram

type

restriction of xs:int

properties

isRef

0

minOcc

0

maxOcc

1

content

simple

nillable

true

facets

minInclusive

-2147483648

maxInclusive

2147483647

annotation

documentation

Ligação a tabela Languages

source

xs:element name="LANG_ID" nillable="true" minOccurs="0"
xs:annotation
xs:documentationLigação a tabela Languages/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element

element Links

diagram

properties

content

complex

children

ID P1 P2 Pipes Pumps SubNetworks Valves

used by

element

Nodes

identity constraints

Name

Refer

Selector

Field(s)

key

Links_PrimaryKey_1

.

ID

keyref

Pipes_ForeignKey_1

Links_PrimaryKey_1

Pipes

ID

keyref

Pumps_ForeignKey_1

Links_PrimaryKey_1

Pumps

ID

keyref

SubNetworks_ForeignKey_1

Links_PrimaryKey_1

SubNetworks

Link_ID

keyref

Valves_ForeignKey_1

Links_PrimaryKey_1

Valves

ID

annotation

documentation

Ligação a tabela Nodes

source

xs:element name="Links"
xs:annotation
xs:documentationLigação a tabela Nodes/xs:documentation
/xs:annotation
xs:complexType
xs:sequence
xs:element name="ID"
xs:annotation
xs:documentationIdentificação/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element
xs:element name="P1" nillable="true" minOccurs="0"
xs:annotation
xs:documentationLigação a tabela Nodes/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element
xs:element name="P2" nillable="true" minOccurs="0"
xs:annotation
xs:documentationLigação a tabela Nodes/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element
xs:element ref="Pipes" minOccurs="0" maxOccurs="unbounded"/
xs:element ref="Pumps" minOccurs="0" maxOccurs="unbounded"/
xs:element ref="SubNetworks" minOccurs="0" maxOccurs="unbounded"/
xs:element ref="Valves" minOccurs="0" maxOccurs="unbounded"/
/xs:sequence
/xs:complexType
xs:key name="Links_PrimaryKey_1"
xs:selector xpath="."/
xs:field xpath="ID"/
/xs:key
xs:keyref name="Pipes_ForeignKey_1" refer="Links_PrimaryKey_1"
xs:selector xpath="Pipes"/
xs:field xpath="ID"/
/xs:keyref
xs:keyref name="Pumps_ForeignKey_1" refer="Links_PrimaryKey_1"
xs:selector xpath="Pumps"/
xs:field xpath="ID"/
/xs:keyref
xs:keyref name="SubNetworks_ForeignKey_1" refer="Links_PrimaryKey_1"
xs:selector xpath="SubNetworks"/
xs:field xpath="Link_ID"/
/xs:keyref
xs:keyref name="Valves_ForeignKey_1" refer="Links_PrimaryKey_1"
xs:selector xpath="Valves"/
xs:field xpath="ID"/
/xs:keyref
/xs:element

element Links/ID

diagram

type

restriction of xs:int

properties

isRef

0

content

simple

facets

minInclusive

-2147483648

maxInclusive

2147483647

annotation

documentation

Identificação

source

xs:element name="ID"
xs:annotation
xs:documentationIdentificação/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element

element Links/P1

diagram

type

restriction of xs:int

properties

isRef

0

minOcc

0

maxOcc

1

content

simple

nillable

true

facets

minInclusive

-2147483648

maxInclusive

2147483647

annotation

documentation

Ligação a tabela Nodes

source

xs:element name="P1" nillable="true" minOccurs="0"
xs:annotation
xs:documentationLigação a tabela Nodes/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element

element Links/P2

diagram

type

restriction of xs:int

properties

isRef

0

minOcc

0

maxOcc

1

content

simple

nillable

true

facets

minInclusive

-2147483648

maxInclusive

2147483647

annotation

documentation

Ligação a tabela Nodes

source

xs:element name="P2" nillable="true" minOccurs="0"
xs:annotation
xs:documentationLigação a tabela Nodes/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element

element Materials_Desc

diagram

properties

content

complex

children

ID Description LANG_ID

used by

element

Languages

identity constraints

Name

Refer

Selector

Field(s)

key

Materials_Desc_PrimaryKey_1

.

ID

source

xs:element name="Materials_Desc"
xs:complexType
xs:sequence
xs:element name="ID"
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element
xs:element name="Description" nillable="true" minOccurs="0"
xs:simpleType
xs:restriction base="xs:string"
xs:maxLength value="100"/
/xs:restriction
/xs:simpleType
/xs:element
xs:element name="LANG_ID" nillable="true" minOccurs="0"
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element
/xs:sequence
/xs:complexType
xs:key name="Materials_Desc_PrimaryKey_1"
xs:selector xpath="."/
xs:field xpath="ID"/
/xs:key
/xs:element

element Materials_Desc/ID

diagram

type

restriction of xs:int

properties

isRef

0

content

simple

facets

minInclusive

-2147483648

maxInclusive

2147483647

source

xs:element name="ID"
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element

element Materials_Desc/Description

diagram

type

restriction of xs:string

properties

isRef

0

minOcc

0

maxOcc

1

content

simple

nillable

true

facets

maxLength

100

source

xs:element name="Description" nillable="true" minOccurs="0"
xs:simpleType
xs:restriction base="xs:string"
xs:maxLength value="100"/
/xs:restriction
/xs:simpleType
/xs:element

element Materials_Desc/LANG_ID

diagram

type

restriction of xs:int

properties

isRef

0

minOcc

0

maxOcc

1

content

simple

nillable

true

facets

minInclusive

-2147483648

maxInclusive

2147483647

source

xs:element name="LANG_ID" nillable="true" minOccurs="0"
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element

element Materials_ID

diagram

properties

content

complex

children

ID Roughness_ID

used by

element

Pipe_Roughness

identity constraints

Name

Refer

Selector

Field(s)

key

Materials_ID_PrimaryKey_1

.

ID

source

xs:element name="Materials_ID"
xs:complexType
xs:sequence
xs:element name="ID"
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element
xs:element name="Roughness_ID" nillable="true" minOccurs="0"
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element
/xs:sequence
/xs:complexType
xs:key name="Materials_ID_PrimaryKey_1"
xs:selector xpath="."/
xs:field xpath="ID"/
/xs:key
/xs:element

element Materials_ID/ID

diagram

type

restriction of xs:int

properties

isRef

0

content

simple

facets

minInclusive

-2147483648

maxInclusive

2147483647

source

xs:element name="ID"
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element

element Materials_ID/Roughness_ID

diagram

type

restriction of xs:int

properties

isRef

0

minOcc

0

maxOcc

1

content

simple

nillable

true

facets

minInclusive

-2147483648

maxInclusive

2147483647

source

xs:element name="Roughness_ID" nillable="true" minOccurs="0"
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element

element Nodes

diagram

properties

content

complex

children

ID X Y Z Flow Links Tanks

identity constraints

Name

Refer

Selector

Field(s)

key

Nodes_PrimaryKey_1

.

ID

keyref

Flow_ForeignKey_2

Nodes_PrimaryKey_1

Flow

Node_ID

keyref

Links_ForeignKey_1

Nodes_PrimaryKey_1

Links

P1

keyref

Links_ForeignKey_2

Nodes_PrimaryKey_1

Links

P2

keyref

Tanks_ForeignKey_1

Nodes_PrimaryKey_1

Tanks

ID

annotation

documentation

Coordenada cartesiana Z

source

xs:element name="Nodes"
xs:annotation
xs:documentationCoordenada cartesiana Z/xs:documentation
/xs:annotation
xs:complexType
xs:sequence
xs:element name="ID"
xs:annotation
xs:documentationIdentificação/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element
xs:element name="X" nillable="true" minOccurs="0"
xs:annotation
xs:documentationCoordenada cartesiana X/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:decimal"
xs:totalDigits value="19"/
xs:fractionDigits value="9"/
xs:minExclusive value="-10000000000"/
xs:maxExclusive value="10000000000"/
/xs:restriction
/xs:simpleType
/xs:element
xs:element name="Y" nillable="true" minOccurs="0"
xs:annotation
xs:documentationCoordenada cartesiana Y/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:decimal"
xs:totalDigits value="19"/
xs:fractionDigits value="9"/
xs:minExclusive value="-10000000000"/
xs:maxExclusive value="10000000000"/
/xs:restriction
/xs:simpleType
/xs:element
xs:element name="Z" nillable="true" minOccurs="0"
xs:annotation
xs:documentationCoordenada cartesiana Z/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:decimal"
xs:totalDigits value="19"/
xs:fractionDigits value="9"/
xs:minExclusive value="-10000000000"/
xs:maxExclusive value="10000000000"/
/xs:restriction
/xs:simpleType
/xs:element
xs:element ref="Flow" minOccurs="0" maxOccurs="unbounded"/
xs:element ref="Links" minOccurs="0" maxOccurs="unbounded"/
xs:element ref="Tanks" minOccurs="0" maxOccurs="unbounded"/
/xs:sequence
/xs:complexType
xs:key name="Nodes_PrimaryKey_1"
xs:selector xpath="."/
xs:field xpath="ID"/
/xs:key
xs:keyref name="Flow_ForeignKey_2" refer="Nodes_PrimaryKey_1"
xs:selector xpath="Flow"/
xs:field xpath="Node_ID"/
/xs:keyref
xs:keyref name="Links_ForeignKey_1" refer="Nodes_PrimaryKey_1"
xs:selector xpath="Links"/
xs:field xpath="P1"/
/xs:keyref
xs:keyref name="Links_ForeignKey_2" refer="Nodes_PrimaryKey_1"
xs:selector xpath="Links"/
xs:field xpath="P2"/
/xs:keyref
xs:keyref name="Tanks_ForeignKey_1" refer="Nodes_PrimaryKey_1"
xs:selector xpath="Tanks"/
xs:field xpath="ID"/
/xs:keyref
/xs:element

element Nodes/ID

diagram

type

restriction of xs:int

properties

isRef

0

content

simple

facets

minInclusive

-2147483648

maxInclusive

2147483647

annotation

documentation

Identificação

source

xs:element name="ID"
xs:annotation
xs:documentationIdentificação/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element

element Nodes/X

diagram

type

restriction of xs:decimal

properties

isRef

0

minOcc

0

maxOcc

1

content

simple

nillable

true

facets

minExclusive

-10000000000

maxExclusive

10000000000

totalDigits

19

fractionDigits

9

annotation

documentation

Coordenada cartesiana X

source

xs:element name="X" nillable="true" minOccurs="0"
xs:annotation
xs:documentationCoordenada cartesiana X/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:decimal"
xs:totalDigits value="19"/
xs:fractionDigits value="9"/
xs:minExclusive value="-10000000000"/
xs:maxExclusive value="10000000000"/
/xs:restriction
/xs:simpleType
/xs:element

element Nodes/Y

diagram

type

restriction of xs:decimal

properties

isRef

0

minOcc

0

maxOcc

1

content

simple

nillable

true

facets

minExclusive

-10000000000

maxExclusive

10000000000

totalDigits

19

fractionDigits

9

annotation

documentation

Coordenada cartesiana Y

source

xs:element name="Y" nillable="true" minOccurs="0"
xs:annotation
xs:documentationCoordenada cartesiana Y/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:decimal"
xs:totalDigits value="19"/
xs:fractionDigits value="9"/
xs:minExclusive value="-10000000000"/
xs:maxExclusive value="10000000000"/
/xs:restriction
/xs:simpleType
/xs:element

element Nodes/Z

diagram

type

restriction of xs:decimal

properties

isRef

0

minOcc

0

maxOcc

1

content

simple

nillable

true

facets

minExclusive

-10000000000

maxExclusive

10000000000

totalDigits

19

fractionDigits

9

annotation

documentation

Coordenada cartesiana Z

source

xs:element name="Z" nillable="true" minOccurs="0"
xs:annotation
xs:documentationCoordenada cartesiana Z/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:decimal"
xs:totalDigits value="19"/
xs:fractionDigits value="9"/
xs:minExclusive value="-10000000000"/
xs:maxExclusive value="10000000000"/
/xs:restriction
/xs:simpleType
/xs:element

element Pipe_Roughness

diagram

properties

content

complex

children

ID e_min e_max Materials_ID Pipe_Roughness_Desc Pipes

identity constraints

Name

Refer

Selector

Field(s)

key

Pipe_Roughness_PrimaryKey_1

.

ID

keyref

Materials_ID_ForeignKey_1

Pipe_Roughness_PrimaryKey_1

Materials_ID

Roughness_ID

keyref

Pipe_Roughness_Desc_ForeignKey_2

Pipe_Roughness_PrimaryKey_1

Pipe_Roughness_Desc

ID

keyref

Pipes_ForeignKey_2

Pipe_Roughness_PrimaryKey_1

Pipes

Material_ID

annotation

documentation

rugosidade máxima [m]

source

xs:element name="Pipe_Roughness"
xs:annotation
xs:documentationrugosidade máxima [m]/xs:documentation
/xs:annotation
xs:complexType
xs:sequence
xs:element name="ID"
xs:annotation
xs:documentationIdentificação/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element
xs:element name="e_min" nillable="true" minOccurs="0"
xs:annotation
xs:documentationrugosidade mínima [m]/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:decimal"
xs:totalDigits value="19"/
xs:fractionDigits value="9"/
xs:minExclusive value="-10000000000"/
xs:maxExclusive value="10000000000"/
/xs:restriction
/xs:simpleType
/xs:element
xs:element name="e_max" nillable="true" minOccurs="0"
xs:annotation
xs:documentationrugosidade máxima [m]/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:decimal"
xs:totalDigits value="19"/
xs:fractionDigits value="9"/
xs:minExclusive value="-10000000000"/
xs:maxExclusive value="10000000000"/
/xs:restriction
/xs:simpleType
/xs:element
xs:element ref="Materials_ID" minOccurs="0" maxOccurs="unbounded"/
xs:element ref="Pipe_Roughness_Desc" minOccurs="0" maxOccurs="unbounded"/
xs:element ref="Pipes" minOccurs="0" maxOccurs="unbounded"/
/xs:sequence
/xs:complexType
xs:key name="Pipe_Roughness_PrimaryKey_1"
xs:selector xpath="."/
xs:field xpath="ID"/
/xs:key
xs:keyref name="Materials_ID_ForeignKey_1" refer="Pipe_Roughness_PrimaryKey_1"
xs:selector xpath="Materials_ID"/
xs:field xpath="Roughness_ID"/
/xs:keyref
xs:keyref name="Pipe_Roughness_Desc_ForeignKey_2" refer="Pipe_Roughness_PrimaryKey_1"
xs:selector xpath="Pipe_Roughness_Desc"/
xs:field xpath="ID"/
/xs:keyref
xs:keyref name="Pipes_ForeignKey_2" refer="Pipe_Roughness_PrimaryKey_1"
xs:selector xpath="Pipes"/
xs:field xpath="Material_ID"/
/xs:keyref
/xs:element

element Pipe_Roughness/ID

diagram

type

restriction of xs:int

properties

isRef

0

content

simple

facets

minInclusive

-2147483648

maxInclusive

2147483647

annotation

documentation

Identificação

source

xs:element name="ID"
xs:annotation
xs:documentationIdentificação/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element

element Pipe_Roughness/e_min

diagram

type

restriction of xs:decimal

properties

isRef

0

minOcc

0

maxOcc

1

content

simple

nillable

true

facets

minExclusive

-10000000000

maxExclusive

10000000000

totalDigits

19

fractionDigits

9

annotation

documentation

rugosidade mínima [m]

source

xs:element name="e_min" nillable="true" minOccurs="0"
xs:annotation
xs:documentationrugosidade mínima [m]/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:decimal"
xs:totalDigits value="19"/
xs:fractionDigits value="9"/
xs:minExclusive value="-10000000000"/
xs:maxExclusive value="10000000000"/
/xs:restriction
/xs:simpleType
/xs:element

element Pipe_Roughness/e_max

diagram

type

restriction of xs:decimal

properties

isRef

0

minOcc

0

maxOcc

1

content

simple

nillable

true

facets

minExclusive

-10000000000

maxExclusive

10000000000

totalDigits

19

fractionDigits

9

annotation

documentation

rugosidade máxima [m]

source

xs:element name="e_max" nillable="true" minOccurs="0"
xs:annotation
xs:documentationrugosidade máxima [m]/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:decimal"
xs:totalDigits value="19"/
xs:fractionDigits value="9"/
xs:minExclusive value="-10000000000"/
xs:maxExclusive value="10000000000"/
/xs:restriction
/xs:simpleType
/xs:element

element Pipe_Roughness_Desc

diagram

properties

content

complex

children

ID Description LANG_ID

used by

elements

Languages Pipe_Roughness

identity constraints

Name

Refer

Selector

Field(s)

unique

Pipe_Roughness_Desc_UniqueKey_1

.

ID

LANG_ID

annotation

documentation

Ligação a tabela Languages

source

xs:element name="Pipe_Roughness_Desc"
xs:annotation
xs:documentationLigação a tabela Languages/xs:documentation
/xs:annotation
xs:complexType
xs:sequence
xs:element name="ID" nillable="true" minOccurs="0"
xs:annotation
xs:documentationLigação a tabela Pipe_Roughness/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element
xs:element name="Description" nillable="true" minOccurs="0"
xs:annotation
xs:documentationNome do material/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:string"
xs:maxLength value="1073741823"/
/xs:restriction
/xs:simpleType
/xs:element
xs:element name="LANG_ID" nillable="true" minOccurs="0"
xs:annotation
xs:documentationLigação a tabela Languages/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element
/xs:sequence
/xs:complexType
xs:unique name="Pipe_Roughness_Desc_UniqueKey_1"
xs:selector xpath="."/
xs:field xpath="ID"/
xs:field xpath="LANG_ID"/
/xs:unique
/xs:element

element Pipe_Roughness_Desc/ID

diagram

type

restriction of xs:int

properties

isRef

0

minOcc

0

maxOcc

1

content

simple

nillable

true

facets

minInclusive

-2147483648

maxInclusive

2147483647

annotation

documentation

Ligação a tabela Pipe_Roughness

source

xs:element name="ID" nillable="true" minOccurs="0"
xs:annotation
xs:documentationLigação a tabela Pipe_Roughness/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element

element Pipe_Roughness_Desc/Description

diagram

type

restriction of xs:string

properties

isRef

0

minOcc

0

maxOcc

1

content

simple

nillable

true

facets

maxLength

1073741823

annotation

documentation

Nome do material

source

xs:element name="Description" nillable="true" minOccurs="0"
xs:annotation
xs:documentationNome do material/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:string"
xs:maxLength value="1073741823"/
/xs:restriction
/xs:simpleType
/xs:element

element Pipe_Roughness_Desc/LANG_ID

diagram

type

restriction of xs:int

properties

isRef

0

minOcc

0

maxOcc

1

content

simple

nillable

true

facets

minInclusive

-2147483648

maxInclusive

2147483647

annotation

documentation

Ligação a tabela Languages

source

xs:element name="LANG_ID" nillable="true" minOccurs="0"
xs:annotation
xs:documentationLigação a tabela Languages/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element

element Pipes

diagram

properties

content

complex

children

ID Material_ID Diameter IsThermIns IsInside

used by

elements

Links Pipe_Roughness

identity constraints

Name

Refer

Selector

Field(s)

key

Pipes_PrimaryKey_1

.

ID

annotation

documentation

Diâmetro da tubagem [m]

source

xs:element name="Pipes"
xs:annotation
xs:documentationDiâmetro da tubagem [m]/xs:documentation
/xs:annotation
xs:complexType
xs:sequence
xs:element name="ID"
xs:annotation
xs:documentationLigação a tabela Links/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element
xs:element name="Material_ID" nillable="true" minOccurs="0"
xs:annotation
xs:documentationLigação a tabela Pipe_Roughness/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element
xs:element name="Diameter" nillable="true" minOccurs="0"
xs:annotation
xs:documentationDiâmetro da tubagem [m]/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:decimal"
xs:totalDigits value="19"/
xs:fractionDigits value="9"/
xs:minExclusive value="-10000000000"/
xs:maxExclusive value="10000000000"/
/xs:restriction
/xs:simpleType
/xs:element
xs:element name="IsThermIns" nillable="true" minOccurs="0"
xs:simpleType
xs:restriction base="xs:boolean"/
/xs:simpleType
/xs:element
xs:element name="IsInside" nillable="true" minOccurs="0"
xs:simpleType
xs:restriction base="xs:boolean"/
/xs:simpleType
/xs:element
/xs:sequence
/xs:complexType
xs:key name="Pipes_PrimaryKey_1"
xs:selector xpath="."/
xs:field xpath="ID"/
/xs:key
/xs:element

element Pipes/ID

diagram

type

restriction of xs:int

properties

isRef

0

content

simple

facets

minInclusive

-2147483648

maxInclusive

2147483647

annotation

documentation

Ligação a tabela Links

source

xs:element name="ID"
xs:annotation
xs:documentationLigação a tabela Links/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element

element Pipes/Material_ID

diagram

type

restriction of xs:int

properties

isRef

0

minOcc

0

maxOcc

1

content

simple

nillable

true

facets

minInclusive

-2147483648

maxInclusive

2147483647

annotation

documentation

Ligação a tabela Pipe_Roughness

source

xs:element name="Material_ID" nillable="true" minOccurs="0"
xs:annotation
xs:documentationLigação a tabela Pipe_Roughness/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element

element Pipes/Diameter

diagram

type

restriction of xs:decimal

properties

isRef

0

minOcc

0

maxOcc

1

content

simple

nillable

true

facets

minExclusive

-10000000000

maxExclusive

10000000000

totalDigits

19

fractionDigits

9

annotation

documentation

Diâmetro da tubagem [m]

source

xs:element name="Diameter" nillable="true" minOccurs="0"
xs:annotation
xs:documentationDiâmetro da tubagem [m]/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:decimal"
xs:totalDigits value="19"/
xs:fractionDigits value="9"/
xs:minExclusive value="-10000000000"/
xs:maxExclusive value="10000000000"/
/xs:restriction
/xs:simpleType
/xs:element

element Pipes/IsThermIns

diagram

type

restriction of xs:boolean

properties

isRef

0

minOcc

0

maxOcc

1

content

simple

nillable

true

source

xs:element name="IsThermIns" nillable="true" minOccurs="0"
xs:simpleType
xs:restriction base="xs:boolean"/
/xs:simpleType
/xs:element

element Pipes/IsInside

diagram

type

restriction of xs:boolean

properties

isRef

0

minOcc

0

maxOcc

1

content

simple

nillable

true

source

xs:element name="IsInside" nillable="true" minOccurs="0"
xs:simpleType
xs:restriction base="xs:boolean"/
/xs:simpleType
/xs:element

element Pumps

diagram

properties

content

complex

children

ID H

used by

element

Links

identity constraints

Name

Refer

Selector

Field(s)

key

Pumps_PrimaryKey_1

.

ID

annotation

documentation

Altura de elevação [m]

source

xs:element name="Pumps"
xs:annotation
xs:documentationAltura de elevação [m]/xs:documentation
/xs:annotation
xs:complexType
xs:sequence
xs:element name="ID"
xs:annotation
xs:documentationLigação a tabela Links/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element
xs:element name="H" nillable="true" minOccurs="0"
xs:annotation
xs:documentationAltura de elevação [m]/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:decimal"
xs:totalDigits value="19"/
xs:fractionDigits value="9"/
xs:minExclusive value="-10000000000"/
xs:maxExclusive value="10000000000"/
/xs:restriction
/xs:simpleType
/xs:element
/xs:sequence
/xs:complexType
xs:key name="Pumps_PrimaryKey_1"
xs:selector xpath="."/
xs:field xpath="ID"/
/xs:key
/xs:element

element Pumps/ID

diagram

type

restriction of xs:int

properties

isRef

0

content

simple

facets

minInclusive

-2147483648

maxInclusive

2147483647

annotation

documentation

Ligação a tabela Links

source

xs:element name="ID"
xs:annotation
xs:documentationLigação a tabela Links/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element

element Pumps/H

diagram

type

restriction of xs:decimal

properties

isRef

0

minOcc

0

maxOcc

1

content

simple

nillable

true

facets

minExclusive

-10000000000

maxExclusive

10000000000

totalDigits

19

fractionDigits

9

annotation

documentation

Altura de elevação [m]

source

xs:element name="H" nillable="true" minOccurs="0"
xs:annotation
xs:documentationAltura de elevação [m]/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:decimal"
xs:totalDigits value="19"/
xs:fractionDigits value="9"/
xs:minExclusive value="-10000000000"/
xs:maxExclusive value="10000000000"/
/xs:restriction
/xs:simpleType
/xs:element

element Spaces

diagram

properties

content

complex

children

ID Space_Type_ID Fraction_ID Devices

used by

element

Spaces_Type_ID

identity constraints

Name

Refer

Selector

Field(s)

key

Spaces_PrimaryKey_1

.

ID

keyref

Devices_ForeignKey_2

Spaces_PrimaryKey_1

Devices

Space_ID

annotation

documentation

Ligação a tabela Spaces_Type_ID

source

xs:element name="Spaces"
xs:annotation
xs:documentationLigação a tabela Spaces_Type_ID/xs:documentation
/xs:annotation
xs:complexType
xs:sequence
xs:element name="ID"
xs:annotation
xs:documentationIdentificação/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element
xs:element name="Space_Type_ID" nillable="true" minOccurs="0"
xs:annotation
xs:documentationLigação a tabela Spaces_Type_ID/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element
xs:element name="Fraction_ID" nillable="true" minOccurs="0"
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element
xs:element ref="Devices" minOccurs="0" maxOccurs="unbounded"/
/xs:sequence
/xs:complexType
xs:key name="Spaces_PrimaryKey_1"
xs:selector xpath="."/
xs:field xpath="ID"/
/xs:key
xs:keyref name="Devices_ForeignKey_2" refer="Spaces_PrimaryKey_1"
xs:selector xpath="Devices"/
xs:field xpath="Space_ID"/
/xs:keyref
/xs:element

element Spaces/ID

diagram

type

restriction of xs:int

properties

isRef

0

content

simple

facets

minInclusive

-2147483648

maxInclusive

2147483647

annotation

documentation

Identificação

source

xs:element name="ID"
xs:annotation
xs:documentationIdentificação/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element

element Spaces/Space_Type_ID

diagram

type

restriction of xs:int

properties

isRef

0

minOcc

0

maxOcc

1

content

simple

nillable

true

facets

minInclusive

-2147483648

maxInclusive

2147483647

annotation

documentation

Ligação a tabela Spaces_Type_ID

source

xs:element name="Space_Type_ID" nillable="true" minOccurs="0"
xs:annotation
xs:documentationLigação a tabela Spaces_Type_ID/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element

element Spaces/Fraction_ID

diagram

type

restriction of xs:int

properties

isRef

0

minOcc

0

maxOcc

1

content

simple

nillable

true

facets

minInclusive

-2147483648

maxInclusive

2147483647

source

xs:element name="Fraction_ID" nillable="true" minOccurs="0"
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element

element Spaces_Type_Desc

diagram

properties

content

complex

children

ID Description LANG_ID

used by

elements

Languages Spaces_Type_ID

identity constraints

Name

Refer

Selector

Field(s)

unique

Spaces_Type_Desc_UniqueKey_1

.

ID

LANG_ID

annotation

documentation

Ligação a tabela Languages

source

xs:element name="Spaces_Type_Desc"
xs:annotation
xs:documentationLigação a tabela Languages/xs:documentation
/xs:annotation
xs:complexType
xs:sequence
xs:element name="ID" nillable="true" minOccurs="0"
xs:annotation
xs:documentationLigação a tabela Spaces_Type_ID/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element
xs:element name="Description" nillable="true" minOccurs="0"
xs:annotation
xs:documentationDescrição do espaço/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:string"
xs:maxLength value="1073741823"/
/xs:restriction
/xs:simpleType
/xs:element
xs:element name="LANG_ID" nillable="true" minOccurs="0"
xs:annotation
xs:documentationLigação a tabela Languages/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element
/xs:sequence
/xs:complexType
xs:unique name="Spaces_Type_Desc_UniqueKey_1"
xs:selector xpath="."/
xs:field xpath="ID"/
xs:field xpath="LANG_ID"/
/xs:unique
/xs:element

element Spaces_Type_Desc/ID

diagram

type

restriction of xs:int

properties

isRef

0

minOcc

0

maxOcc

1

content

simple

nillable

true

facets

minInclusive

-2147483648

maxInclusive

2147483647

annotation

documentation

Ligação a tabela Spaces_Type_ID

source

xs:element name="ID" nillable="true" minOccurs="0"
xs:annotation
xs:documentationLigação a tabela Spaces_Type_ID/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element

element Spaces_Type_Desc/Description

diagram

type

restriction of xs:string

properties

isRef

0

minOcc

0

maxOcc

1

content

simple

nillable

true

facets

maxLength

1073741823

annotation

documentation

Descrição do espaço

source

xs:element name="Description" nillable="true" minOccurs="0"
xs:annotation
xs:documentationDescrição do espaço/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:string"
xs:maxLength value="1073741823"/
/xs:restriction
/xs:simpleType
/xs:element

element Spaces_Type_Desc/LANG_ID

diagram

type

restriction of xs:int

properties

isRef

0

minOcc

0

maxOcc

1

content

simple

nillable

true

facets

minInclusive

-2147483648

maxInclusive

2147483647

annotation

documentation

Ligação a tabela Languages

source

xs:element name="LANG_ID" nillable="true" minOccurs="0"
xs:annotation
xs:documentationLigação a tabela Languages/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element

element Spaces_Type_ID

diagram

properties

content

complex

children

ID Spaces Spaces_Type_Desc

identity constraints

Name

Refer

Selector

Field(s)

key

Spaces_Type_ID_PrimaryKey_1

.

ID

keyref

Spaces_ForeignKey_1

Spaces_Type_ID_PrimaryKey_1

Spaces

Space_Type_ID

keyref

Spaces_Type_Desc_ForeignKey_2

Spaces_Type_ID_PrimaryKey_1

Spaces_Type_Desc

ID

annotation

documentation

Identificação

source

xs:element name="Spaces_Type_ID"
xs:annotation
xs:documentationIdentificação/xs:documentation
/xs:annotation
xs:complexType
xs:sequence
xs:element name="ID"
xs:annotation
xs:documentationIdentificação/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element
xs:element ref="Spaces" minOccurs="0" maxOccurs="unbounded"/
xs:element ref="Spaces_Type_Desc" minOccurs="0" maxOccurs="unbounded"/
/xs:sequence
/xs:complexType
xs:key name="Spaces_Type_ID_PrimaryKey_1"
xs:selector xpath="."/
xs:field xpath="ID"/
/xs:key
xs:keyref name="Spaces_ForeignKey_1" refer="Spaces_Type_ID_PrimaryKey_1"
xs:selector xpath="Spaces"/
xs:field xpath="Space_Type_ID"/
/xs:keyref
xs:keyref name="Spaces_Type_Desc_ForeignKey_2" refer="Spaces_Type_ID_PrimaryKey_1"
xs:selector xpath="Spaces_Type_Desc"/
xs:field xpath="ID"/
/xs:keyref
/xs:element

element Spaces_Type_ID/ID

diagram

type

restriction of xs:int

properties

isRef

0

content

simple

facets

minInclusive

-2147483648

maxInclusive

2147483647

annotation

documentation

Identificação

source

xs:element name="ID"
xs:annotation
xs:documentationIdentificação/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element

element SubNetworks

diagram

properties

content

complex

children

Link_ID Network_ID Network_Type_ID

used by

elements

Links SubNetworks_Type_ID

identity constraints

Name

Refer

Selector

Field(s)

key

SubNetworks_PrimaryKey_1

.

Link_ID

unique

SubNetworks_UniqueKey_1

.

Link_ID

annotation

documentation

Ligação a tabela SubNetworks_Type_ID

source

xs:element name="SubNetworks"
xs:annotation
xs:documentationLigação a tabela SubNetworks_Type_ID/xs:documentation
/xs:annotation
xs:complexType
xs:sequence
xs:element name="Link_ID"
xs:annotation
xs:documentationLigação a tabela SubNetworks/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element
xs:element name="Network_ID" nillable="true" minOccurs="0"
xs:annotation
xs:documentationIdentificação da subrede/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element
xs:element name="Network_Type_ID" nillable="true" minOccurs="0"
xs:annotation
xs:documentationLigação a tabela SubNetworks_Type_ID/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element
/xs:sequence
/xs:complexType
xs:key name="SubNetworks_PrimaryKey_1"
xs:selector xpath="."/
xs:field xpath="Link_ID"/
/xs:key
xs:unique name="SubNetworks_UniqueKey_1"
xs:selector xpath="."/
xs:field xpath="Link_ID"/
/xs:unique
/xs:element

element SubNetworks/Link_ID

diagram

type

restriction of xs:int

properties

isRef

0

content

simple

facets

minInclusive

-2147483648

maxInclusive

2147483647

annotation

documentation

Ligação a tabela SubNetworks

source

xs:element name="Link_ID"
xs:annotation
xs:documentationLigação a tabela SubNetworks/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element

element SubNetworks/Network_ID

diagram

type

restriction of xs:int

properties

isRef

0

minOcc

0

maxOcc

1

content

simple

nillable

true

facets

minInclusive

-2147483648

maxInclusive

2147483647

annotation

documentation

Identificação da subrede

source

xs:element name="Network_ID" nillable="true" minOccurs="0"
xs:annotation
xs:documentationIdentificação da subrede/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element

element SubNetworks/Network_Type_ID

diagram

type

restriction of xs:int

properties

isRef

0

minOcc

0

maxOcc

1

content

simple

nillable

true

facets

minInclusive

-2147483648

maxInclusive

2147483647

annotation

documentation

Ligação a tabela SubNetworks_Type_ID

source

xs:element name="Network_Type_ID" nillable="true" minOccurs="0"
xs:annotation
xs:documentationLigação a tabela SubNetworks_Type_ID/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element

element SubNetworks_Type_Desc

diagram

properties

content

complex

children

Network_Type_ID Description LANG_ID

used by

elements

Languages SubNetworks_Type_ID

identity constraints

Name

Refer

Selector

Field(s)

unique

SubNetworks_Type_Desc_UniqueKey_1

.

Network_Type_ID

LANG_ID

annotation

documentation

Ligação a tabela Languages

source

xs:element name="SubNetworks_Type_Desc"
xs:annotation
xs:documentationLigação a tabela Languages/xs:documentation
/xs:annotation
xs:complexType
xs:sequence
xs:element name="Network_Type_ID" nillable="true" minOccurs="0"
xs:annotation
xs:documentationLigação a tabela SubNetworks_Type_ID/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element
xs:element name="Description" nillable="true" minOccurs="0"
xs:annotation
xs:documentationDescrição do tipo de rede/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:string"
xs:maxLength value="1073741823"/
/xs:restriction
/xs:simpleType
/xs:element
xs:element name="LANG_ID" nillable="true" minOccurs="0"
xs:annotation
xs:documentationLigação a tabela Languages/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element
/xs:sequence
/xs:complexType
xs:unique name="SubNetworks_Type_Desc_UniqueKey_1"
xs:selector xpath="."/
xs:field xpath="Network_Type_ID"/
xs:field xpath="LANG_ID"/
/xs:unique
/xs:element

element SubNetworks_Type_Desc/Network_Type_ID

diagram

type

restriction of xs:int

properties

isRef

0

minOcc

0

maxOcc

1

content

simple

nillable

true

facets

minInclusive

-2147483648

maxInclusive

2147483647

annotation

documentation

Ligação a tabela SubNetworks_Type_ID

source

xs:element name="Network_Type_ID" nillable="true" minOccurs="0"
xs:annotation
xs:documentationLigação a tabela SubNetworks_Type_ID/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element

element SubNetworks_Type_Desc/Description

diagram

type

restriction of xs:string

properties

isRef

0

minOcc

0

maxOcc

1

content

simple

nillable

true

facets

maxLength

1073741823

annotation

documentation

Descrição do tipo de rede

source

xs:element name="Description" nillable="true" minOccurs="0"
xs:annotation
xs:documentationDescrição do tipo de rede/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:string"
xs:maxLength value="1073741823"/
/xs:restriction
/xs:simpleType
/xs:element

element SubNetworks_Type_Desc/LANG_ID

diagram

type

restriction of xs:int

properties

isRef

0

minOcc

0

maxOcc

1

content

simple

nillable

true

facets

minInclusive

-2147483648

maxInclusive

2147483647

annotation

documentation

Ligação a tabela Languages

source

xs:element name="LANG_ID" nillable="true" minOccurs="0"
xs:annotation
xs:documentationLigação a tabela Languages/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element

element SubNetworks_Type_ID

diagram

properties

content

complex

children

ID SubNetworks SubNetworks_Type_Desc

identity constraints

Name

Refer

Selector

Field(s)

key

SubNetworks_Type_ID_PrimaryKey_1

.

ID

keyref

SubNetworks_ForeignKey_2

SubNetworks_Type_ID_PrimaryKey_1

SubNetworks

Network_Type_ID

keyref

SubNetworks_Type_Desc_ForeignKey_2

SubNetworks_Type_ID_PrimaryKey_1

SubNetworks_Type_Desc

Network_Type_ID

annotation

documentation

Identificação

source

xs:element name="SubNetworks_Type_ID"
xs:annotation
xs:documentationIdentificação/xs:documentation
/xs:annotation
xs:complexType
xs:sequence
xs:element name="ID"
xs:annotation
xs:documentationIdentificação/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element
xs:element ref="SubNetworks" minOccurs="0" maxOccurs="unbounded"/
xs:element ref="SubNetworks_Type_Desc" minOccurs="0" maxOccurs="unbounded"/
/xs:sequence
/xs:complexType
xs:key name="SubNetworks_Type_ID_PrimaryKey_1"
xs:selector xpath="."/
xs:field xpath="ID"/
/xs:key
xs:keyref name="SubNetworks_ForeignKey_2" refer="SubNetworks_Type_ID_PrimaryKey_1"
xs:selector xpath="SubNetworks"/
xs:field xpath="Network_Type_ID"/
/xs:keyref
xs:keyref name="SubNetworks_Type_Desc_ForeignKey_2" refer="SubNetworks_Type_ID_PrimaryKey_1"
xs:selector xpath="SubNetworks_Type_Desc"/
xs:field xpath="Network_Type_ID"/
/xs:keyref
/xs:element

element SubNetworks_Type_ID/ID

diagram

type

restriction of xs:int

properties

isRef

0

content

simple

facets

minInclusive

-2147483648

maxInclusive

2147483647

annotation

documentation

Identificação

source

xs:element name="ID"
xs:annotation
xs:documentationIdentificação/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element

element Tanks

diagram

properties

content

complex

children

ID Min_Level Max_Level

used by

element

Nodes

identity constraints

Name

Refer

Selector

Field(s)

key

Tanks_PrimaryKey_1

.

ID

annotation

documentation

Cota máxima do reservatório [m]

source

xs:element name="Tanks"
xs:annotation
xs:documentationCota máxima do reservatório [m]/xs:documentation
/xs:annotation
xs:complexType
xs:sequence
xs:element name="ID"
xs:annotation
xs:documentationLigação a tabela Nodes/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element
xs:element name="Min_Level" nillable="true" minOccurs="0"
xs:annotation
xs:documentationCota mínima do reservatório [m]/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:decimal"
xs:totalDigits value="19"/
xs:fractionDigits value="9"/
xs:minExclusive value="-10000000000"/
xs:maxExclusive value="10000000000"/
/xs:restriction
/xs:simpleType
/xs:element
xs:element name="Max_Level" nillable="true" minOccurs="0"
xs:annotation
xs:documentationCota máxima do reservatório [m]/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:decimal"
xs:totalDigits value="19"/
xs:fractionDigits value="9"/
xs:minExclusive value="-10000000000"/
xs:maxExclusive value="10000000000"/
/xs:restriction
/xs:simpleType
/xs:element
/xs:sequence
/xs:complexType
xs:key name="Tanks_PrimaryKey_1"
xs:selector xpath="."/
xs:field xpath="ID"/
/xs:key
/xs:element

element Tanks/ID

diagram

type

restriction of xs:int

properties

isRef

0

content

simple

facets

minInclusive

-2147483648

maxInclusive

2147483647

annotation

documentation

Ligação a tabela Nodes

source

xs:element name="ID"
xs:annotation
xs:documentationLigação a tabela Nodes/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element

element Tanks/Min_Level

diagram

type

restriction of xs:decimal

properties

isRef

0

minOcc

0

maxOcc

1

content

simple

nillable

true

facets

minExclusive

-10000000000

maxExclusive

10000000000

totalDigits

19

fractionDigits

9

annotation

documentation

Cota mínima do reservatório [m]

source

xs:element name="Min_Level" nillable="true" minOccurs="0"
xs:annotation
xs:documentationCota mínima do reservatório [m]/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:decimal"
xs:totalDigits value="19"/
xs:fractionDigits value="9"/
xs:minExclusive value="-10000000000"/
xs:maxExclusive value="10000000000"/
/xs:restriction
/xs:simpleType
/xs:element

element Tanks/Max_Level

diagram

type

restriction of xs:decimal

properties

isRef

0

minOcc

0

maxOcc

1

content

simple

nillable

true

facets

minExclusive

-10000000000

maxExclusive

10000000000

totalDigits

19

fractionDigits

9

annotation

documentation

Cota máxima do reservatório [m]

source

xs:element name="Max_Level" nillable="true" minOccurs="0"
xs:annotation
xs:documentationCota máxima do reservatório [m]/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:decimal"
xs:totalDigits value="19"/
xs:fractionDigits value="9"/
xs:minExclusive value="-10000000000"/
xs:maxExclusive value="10000000000"/
/xs:restriction
/xs:simpleType
/xs:element

element URC

diagram

properties

content

complex

children

Use_Reduction_Coef Description LANG_ID

used by

element

URC_ID

identity constraints

Name

Refer

Selector

Field(s)

unique

IX_URC

.

Use_Reduction_Coef

LANG_ID

annotation

documentation

Identificação da língua utilizada para o campo anterior

source

xs:element name="URC"
xs:annotation
xs:documentationIdentificação da língua utilizada para o campo anterior/xs:documentation
/xs:annotation
xs:complexType
xs:sequence
xs:element name="Use_Reduction_Coef" nillable="true" minOccurs="0"
xs:annotation
xs:documentationLigação a tabela URC_ID/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:boolean"/
/xs:simpleType
/xs:element
xs:element name="Description" nillable="true" minOccurs="0"
xs:annotation
xs:documentationDescrição do campo anterior (Sim/Não + texto complementar, se necessário)/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:string"
xs:maxLength value="10"/
/xs:restriction
/xs:simpleType
/xs:element
xs:element name="LANG_ID" nillable="true" minOccurs="0"
xs:annotation
xs:documentationIdentificação da língua utilizada para o campo anterior/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element
/xs:sequence
/xs:complexType
xs:unique name="IX_URC"
xs:selector xpath="."/
xs:field xpath="Use_Reduction_Coef"/
xs:field xpath="LANG_ID"/
/xs:unique
/xs:element

element URC/Use_Reduction_Coef

diagram

type

restriction of xs:boolean

properties

isRef

0

minOcc

0

maxOcc

1

content

simple

nillable

true

annotation

documentation

Ligação a tabela URC_ID

source

xs:element name="Use_Reduction_Coef" nillable="true" minOccurs="0"
xs:annotation
xs:documentationLigação a tabela URC_ID/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:boolean"/
/xs:simpleType
/xs:element

element URC/Description

diagram

type

restriction of xs:string

properties

isRef

0

minOcc

0

maxOcc

1

content

simple

nillable

true

facets

maxLength

10

annotation

documentation

Descrição do campo anterior (Sim/Não + texto complementar, se necessário)

source

xs:element name="Description" nillable="true" minOccurs="0"
xs:annotation
xs:documentationDescrição do campo anterior (Sim/Não + texto complementar, se necessário)/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:string"
xs:maxLength value="10"/
/xs:restriction
/xs:simpleType
/xs:element

element URC/LANG_ID

diagram

type

restriction of xs:int

properties

isRef

0

minOcc

0

maxOcc

1

content

simple

nillable

true

facets

minInclusive

-2147483648

maxInclusive

2147483647

annotation

documentation

Identificação da língua utilizada para o campo anterior

source

xs:element name="LANG_ID" nillable="true" minOccurs="0"
xs:annotation
xs:documentationIdentificação da língua utilizada para o campo anterior/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element

element URC_ID

diagram

properties

content

complex

children

ID Flow URC

identity constraints

Name

Refer

Selector

Field(s)

key

URC_ID_PrimaryKey_1

.

ID

keyref

Flow_ForeignKey_3

URC_ID_PrimaryKey_1

Flow

Use_Reduction_Coef

keyref

URC_ForeignKey_1

URC_ID_PrimaryKey_1

URC

Use_Reduction_Coef

annotation

documentation

Identificação

source

xs:element name="URC_ID"
xs:annotation
xs:documentationIdentificação/xs:documentation
/xs:annotation
xs:complexType
xs:sequence
xs:element name="ID"
xs:annotation
xs:documentationIdentificação/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:boolean"/
/xs:simpleType
/xs:element
xs:element ref="Flow" minOccurs="0" maxOccurs="unbounded"/
xs:element ref="URC" minOccurs="0" maxOccurs="unbounded"/
/xs:sequence
/xs:complexType
xs:key name="URC_ID_PrimaryKey_1"
xs:selector xpath="."/
xs:field xpath="ID"/
/xs:key
xs:keyref name="Flow_ForeignKey_3" refer="URC_ID_PrimaryKey_1"
xs:selector xpath="Flow"/
xs:field xpath="Use_Reduction_Coef"/
/xs:keyref
xs:keyref name="URC_ForeignKey_1" refer="URC_ID_PrimaryKey_1"
xs:selector xpath="URC"/
xs:field xpath="Use_Reduction_Coef"/
/xs:keyref
/xs:element

element URC_ID/ID

diagram

type

restriction of xs:boolean

properties

isRef

0

content

simple

annotation

documentation

Identificação

source

xs:element name="ID"
xs:annotation
xs:documentationIdentificação/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:boolean"/
/xs:simpleType
/xs:element

element Valves

diagram

properties

content

complex

children

ID Type Setting

used by

elements

Links Valves_Type_ID

identity constraints

Name

Refer

Selector

Field(s)

key

Valves_PrimaryKey_1

.

ID

annotation

documentation

Parâmetro de funcionamento da válvula

source

xs:element name="Valves"
xs:annotation
xs:documentationParâmetro de funcionamento da válvula/xs:documentation
/xs:annotation
xs:complexType
xs:sequence
xs:element name="ID"
xs:annotation
xs:documentationLigação a tabela Links/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element
xs:element name="Type" nillable="true" minOccurs="0"
xs:annotation
xs:documentationLigação a tabela Valves_Type_ID/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element
xs:element name="Setting" nillable="true" minOccurs="0"
xs:annotation
xs:documentationParâmetro de funcionamento da válvula/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:decimal"
xs:totalDigits value="19"/
xs:fractionDigits value="9"/
xs:minExclusive value="-10000000000"/
xs:maxExclusive value="10000000000"/
/xs:restriction
/xs:simpleType
/xs:element
/xs:sequence
/xs:complexType
xs:key name="Valves_PrimaryKey_1"
xs:selector xpath="."/
xs:field xpath="ID"/
/xs:key
/xs:element

element Valves/ID

diagram

type

restriction of xs:int

properties

isRef

0

content

simple

facets

minInclusive

-2147483648

maxInclusive

2147483647

annotation

documentation

Ligação a tabela Links

source

xs:element name="ID"
xs:annotation
xs:documentationLigação a tabela Links/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element

element Valves/Type

diagram

type

restriction of xs:int

properties

isRef

0

minOcc

0

maxOcc

1

content

simple

nillable

true

facets

minInclusive

-2147483648

maxInclusive

2147483647

annotation

documentation

Ligação a tabela Valves_Type_ID

source

xs:element name="Type" nillable="true" minOccurs="0"
xs:annotation
xs:documentationLigação a tabela Valves_Type_ID/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element

element Valves/Setting

diagram

type

restriction of xs:decimal

properties

isRef

0

minOcc

0

maxOcc

1

content

simple

nillable

true

facets

minExclusive

-10000000000

maxExclusive

10000000000

totalDigits

19

fractionDigits

9

annotation

documentation

Parâmetro de funcionamento da válvula

source

xs:element name="Setting" nillable="true" minOccurs="0"
xs:annotation
xs:documentationParâmetro de funcionamento da válvula/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:decimal"
xs:totalDigits value="19"/
xs:fractionDigits value="9"/
xs:minExclusive value="-10000000000"/
xs:maxExclusive value="10000000000"/
/xs:restriction
/xs:simpleType
/xs:element

element Valves_Type_Desc

diagram

properties

content

complex

children

Valve_Type_ID Description LANG_ID

used by

elements

Languages Valves_Type_ID

identity constraints

Name

Refer

Selector

Field(s)

unique

Valves_Type_Desc_UniqueKey_1

.

Valve_Type_ID

LANG_ID

annotation

documentation

Ligação a tabela Languages

source

xs:element name="Valves_Type_Desc"
xs:annotation
xs:documentationLigação a tabela Languages/xs:documentation
/xs:annotation
xs:complexType
xs:sequence
xs:element name="Valve_Type_ID" nillable="true" minOccurs="0"
xs:annotation
xs:documentationLigação a tabela Valves_Type_ID/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element
xs:element name="Description" nillable="true" minOccurs="0"
xs:annotation
xs:documentationDescrição do tipo de válvula/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:string"
xs:maxLength value="1073741823"/
/xs:restriction
/xs:simpleType
/xs:element
xs:element name="LANG_ID" nillable="true" minOccurs="0"
xs:annotation
xs:documentationLigação a tabela Languages/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element
/xs:sequence
/xs:complexType
xs:unique name="Valves_Type_Desc_UniqueKey_1"
xs:selector xpath="."/
xs:field xpath="Valve_Type_ID"/
xs:field xpath="LANG_ID"/
/xs:unique
/xs:element

element Valves_Type_Desc/Valve_Type_ID

diagram

type

restriction of xs:int

properties

isRef

0

minOcc

0

maxOcc

1

content

simple

nillable

true

facets

minInclusive

-2147483648

maxInclusive

2147483647

annotation

documentation

Ligação a tabela Valves_Type_ID

source

xs:element name="Valve_Type_ID" nillable="true" minOccurs="0"
xs:annotation
xs:documentationLigação a tabela Valves_Type_ID/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element

element Valves_Type_Desc/Description

diagram

type

restriction of xs:string

properties

isRef

0

minOcc

0

maxOcc

1

content

simple

nillable

true

facets

maxLength

1073741823

annotation

documentation

Descrição do tipo de válvula

source

xs:element name="Description" nillable="true" minOccurs="0"
xs:annotation
xs:documentationDescrição do tipo de válvula/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:string"
xs:maxLength value="1073741823"/
/xs:restriction
/xs:simpleType
/xs:element

element Valves_Type_Desc/LANG_ID

diagram

type

restriction of xs:int

properties

isRef

0

minOcc

0

maxOcc

1

content

simple

nillable

true

facets

minInclusive

-2147483648

maxInclusive

2147483647

annotation

documentation

Ligação a tabela Languages

source

xs:element name="LANG_ID" nillable="true" minOccurs="0"
xs:annotation
xs:documentationLigação a tabela Languages/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element

element Valves_Type_ID

diagram

properties

content

complex

children

ID Valves Valves_Type_Desc

identity constraints

Name

Refer

Selector

Field(s)

key

Valves_Type_ID_PrimaryKey_1

.

ID

keyref

Valves_ForeignKey_2

Valves_Type_ID_PrimaryKey_1

Valves

Type

keyref

Valves_Type_Desc_ForeignKey_2

Valves_Type_ID_PrimaryKey_1

Valves_Type_Desc

Valve_Type_ID

annotation

documentation

Identificação

source

xs:element name="Valves_Type_ID"
xs:annotation
xs:documentationIdentificação/xs:documentation
/xs:annotation
xs:complexType
xs:sequence
xs:element name="ID"
xs:annotation
xs:documentationIdentificação/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element
xs:element ref="Valves" minOccurs="0" maxOccurs="unbounded"/
xs:element ref="Valves_Type_Desc" minOccurs="0" maxOccurs="unbounded"/
/xs:sequence
/xs:complexType
xs:key name="Valves_Type_ID_PrimaryKey_1"
xs:selector xpath="."/
xs:field xpath="ID"/
/xs:key
xs:keyref name="Valves_ForeignKey_2" refer="Valves_Type_ID_PrimaryKey_1"
xs:selector xpath="Valves"/
xs:field xpath="Type"/
/xs:keyref
xs:keyref name="Valves_Type_Desc_ForeignKey_2" refer="Valves_Type_ID_PrimaryKey_1"
xs:selector xpath="Valves_Type_Desc"/
xs:field xpath="Valve_Type_ID"/
/xs:keyref
/xs:element

element Valves_Type_ID/ID

diagram

type

restriction of xs:int

properties

isRef

0

content

simple

facets

minInclusive

-2147483648

maxInclusive

2147483647

annotation

documentation

Identificação

source

xs:element name="ID"
xs:annotation
xs:documentationIdentificação/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element

element Warning_Level

diagram

properties

content

complex

children

MSG_ID WARNING_LEVEL

identity constraints

Name

Refer

Selector

Field(s)

key

Warning_Level_PrimaryKey_1

.

MSG_ID

annotation

documentation

Nível do aviso - liga à tabela Warning_Level_Desc e pode ser usado para, por exeplo, estabelecer um código de côres para as mensagens

source

xs:element name="Warning_Level"
xs:annotation
xs:documentationNível do aviso - liga à tabela Warning_Level_Desc e pode ser usado para, por exeplo, estabelecer um código de côres para as mensagens/xs:documentation
/xs:annotation
xs:complexType
xs:sequence
xs:element name="MSG_ID"
xs:annotation
xs:documentationIdentificação/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element
xs:element name="WARNING_LEVEL" nillable="true" minOccurs="0"
xs:annotation
xs:documentationNível do aviso - liga à tabela Warning_Level_Desc e pode ser usado para, por exeplo, estabelecer um código de côres para as mensagens/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element
/xs:sequence
/xs:complexType
xs:key name="Warning_Level_PrimaryKey_1"
xs:selector xpath="."/
xs:field xpath="MSG_ID"/
/xs:key
/xs:element

element Warning_Level/MSG_ID

diagram

type

restriction of xs:int

properties

isRef

0

content

simple

facets

minInclusive

-2147483648

maxInclusive

2147483647

annotation

documentation

Identificação

source

xs:element name="MSG_ID"
xs:annotation
xs:documentationIdentificação/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element

element Warning_Level/WARNING_LEVEL

diagram

type

restriction of xs:int

properties

isRef

0

minOcc

0

maxOcc

1

content

simple

nillable

true

facets

minInclusive

-2147483648

maxInclusive

2147483647

annotation

documentation

Nível do aviso - liga à tabela Warning_Level_Desc e pode ser usado para, por exeplo, estabelecer um código de côres para as mensagens

source

xs:element name="WARNING_LEVEL" nillable="true" minOccurs="0"
xs:annotation
xs:documentationNível do aviso - liga à tabela Warning_Level_Desc e pode ser usado para, por exeplo, estabelecer um código de côres para as mensagens/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element

element Warning_Level_Desc

diagram

properties

content

complex

children

ID Description LANG_ID

used by

elements

Languages Warning_Level_ID

identity constraints

Name

Refer

Selector

Field(s)

unique

Warning_Level_Desc_UniqueKey_1

.

ID

LANG_ID

annotation

documentation

Ligação a tabela Languages

source

xs:element name="Warning_Level_Desc"
xs:annotation
xs:documentationLigação a tabela Languages/xs:documentation
/xs:annotation
xs:complexType
xs:sequence
xs:element name="ID" nillable="true" minOccurs="0"
xs:annotation
xs:documentationLigação a tabela Warning_Level_ID/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element
xs:element name="Description" nillable="true" minOccurs="0"
xs:annotation
xs:documentationDescrição do nível do aviso/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:string"
xs:maxLength value="100"/
/xs:restriction
/xs:simpleType
/xs:element
xs:element name="LANG_ID" nillable="true" minOccurs="0"
xs:annotation
xs:documentationLigação a tabela Languages/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element
/xs:sequence
/xs:complexType
xs:unique name="Warning_Level_Desc_UniqueKey_1"
xs:selector xpath="."/
xs:field xpath="ID"/
xs:field xpath="LANG_ID"/
/xs:unique
/xs:element

element Warning_Level_Desc/ID

diagram

type

restriction of xs:int

properties

isRef

0

minOcc

0

maxOcc

1

content

simple

nillable

true

facets

minInclusive

-2147483648

maxInclusive

2147483647

annotation

documentation

Ligação a tabela Warning_Level_ID

source

xs:element name="ID" nillable="true" minOccurs="0"
xs:annotation
xs:documentationLigação a tabela Warning_Level_ID/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element

element Warning_Level_Desc/Description

diagram

type

restriction of xs:string

properties

isRef

0

minOcc

0

maxOcc

1

content

simple

nillable

true

facets

maxLength

100

annotation

documentation

Descrição do nível do aviso

source

xs:element name="Description" nillable="true" minOccurs="0"
xs:annotation
xs:documentationDescrição do nível do aviso/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:string"
xs:maxLength value="100"/
/xs:restriction
/xs:simpleType
/xs:element

element Warning_Level_Desc/LANG_ID

diagram

type

restriction of xs:int

properties

isRef

0

minOcc

0

maxOcc

1

content

simple

nillable

true

facets

minInclusive

-2147483648

maxInclusive

2147483647

annotation

documentation

Ligação a tabela Languages

source

xs:element name="LANG_ID" nillable="true" minOccurs="0"
xs:annotation
xs:documentationLigação a tabela Languages/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element

element Warning_Level_ID

diagram

properties

content

complex

children

ID Warning_Level_Desc

identity constraints

Name

Refer

Selector

Field(s)

key

Warning_Level_ID_PrimaryKey_1

.

ID

keyref

Warning_Level_Desc_ForeignKey_2

Warning_Level_ID_PrimaryKey_1

Warning_Level_Desc

ID

annotation

documentation

Identificação

source

xs:element name="Warning_Level_ID"
xs:annotation
xs:documentationIdentificação/xs:documentation
/xs:annotation
xs:complexType
xs:sequence
xs:element name="ID"
xs:annotation
xs:documentationIdentificação/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element
xs:element ref="Warning_Level_Desc" minOccurs="0" maxOccurs="unbounded"/
/xs:sequence
/xs:complexType
xs:key name="Warning_Level_ID_PrimaryKey_1"
xs:selector xpath="."/
xs:field xpath="ID"/
/xs:key
xs:keyref name="Warning_Level_Desc_ForeignKey_2" refer="Warning_Level_ID_PrimaryKey_1"
xs:selector xpath="Warning_Level_Desc"/
xs:field xpath="ID"/
/xs:keyref
/xs:element

element Warning_Level_ID/ID

diagram

type

restriction of xs:int

properties

isRef

0

content

simple

facets

minInclusive

-2147483648

maxInclusive

2147483647

annotation

documentation

Identificação

source

xs:element name="ID"
xs:annotation
xs:documentationIdentificação/xs:documentation
/xs:annotation
xs:simpleType
xs:restriction base="xs:int"
xs:minInclusive value="-2147483648"/
xs:maxInclusive value="2147483647"/
/xs:restriction
/xs:simpleType
/xs:element

Bibliografia

Águas de Gaia, EM. 2000. Regulamento dos Sistemas Públicos e Prediais de Abastecimento de Água e de Águas Residuais do Município de Vila Nova de Gaia.

Águas do Porto, EM. 2008. Termo de responsabilidade do autor do projecto de redes prediais de abastecimento de água e de drenagem de águas residuais domésticas e águas pluviais  [acedido a 23 de Março 2009]. Disponível em http://www.aguasdoporto.pt/publico/downloads/int_termo_resp_autor_projecto.zip.

Alegre, Helena. 2000. Performance indicators for water supply services, Manual of best practice series. London: IWA.

Apache Software Foundation. The Apache Software Foundation Homepage  [acedido a 26 de Março 2009]. Disponível em http://www.apache.org/.

ARUP. 2004. Creating a "Water Cube", www.bentley.com  [acedido a 30 de Outubro 2008]. Disponível em http://www.bentley.com/pt-BR/Corporate/Publications/Case+Studies/Buildings/Creating+a+Water+Cube.htm.

Augenbroe, Godfried. 1994. An Overview of the COMBINE project  [acedido a 14 de Janeiro 2009]. Disponível em ftp://erg.ucd.ie/public/pdfiles/combine_papers/paper1.pdf.

Baganha, Maria Ioannis, José Carlos Marques e Pedro Góis. 2002. O Sector da Construção Civil e Obras Públicas em Portugal: 1990-2000. Oficina do CES (173):1-35.

Bates, Hilary, Nick Oliver, Matthias Holweg e Michael Lewis. 2007. Motor vehicle recalls: trends, patterns and emerging issues. Omega, International Journal of Management Science 35 (2):202-210.

Behrman, William. 2002. Best Practices for the Development and Use of XML Data Interchange Standards. CIFE Technical report TR131. Stanford University.

Bellinger, G, D Castro e A Mills. 2004. Data, Information, Knowledge, and Wisdom  [acedido a 21 de Março 2009]. Disponível em http://www.systems-thinking.org/dikw/dikw.htm.

Bernstein, Phil. 2005. Integrated Practice: It’s Not Just About the Technology. AIArchitect (Outubro 2005), http://www.ddscad.com/Integrated_Practice_Bernistein.pdf.

Björk, Bo-Christer. 1995. Requirements and information structures for building products data models. Tese de Doutoramento, VTT Building Technology, Espoo, Finlândia.

Black, Paul E. 2007. Breadth-first search - Dictionary of Algorithms and Data Structures. U.S. National Institute of Standards and Technology, 23 de Abril [acedido a 8 de Setembro 2008]. Disponível em http://www.nist.gov/dads/HTML/breadthfirst.html.

———. 2008. Depth-first search - Dictionary of Algorithms and Data Structures. U.S. National Institute of Standards and Technology, 8 de Janeiro [acedido a 8 de Setembro 2008]. Disponível em http://www.nist.gov/dads/HTML/depthfirst.html.

Borges, José Manuel Leitão. 1986. Projecção central e axonometria: Utilização do computador no desenho de perspectivas. Provas de aptidão pedagógica e capacidade científica, Faculdade de Engenharia, Universidade do Porto, Porto.

———. 2003. Método Cotado - Sombras. Porto: Faculdade de Engenharia da Universidade do Porto.

Boxall, J. B., O'Hagan, A., Pooladsaz, S., Saul, A. J., Unwin, D. M. 2007. Estimation of burst rates in water distribution mains. Water Management 160 (2):73-82.

Brazil, Marcus. 2001. Steiner Minimum Trees in Uniform Orientation Metrics. In Steiner Trees in Industry, edited by Xiuzhen Cheng and Ding-Zhu Du: Springer.

Buescu, Jorge. 2003. Da falsificação de Euros aos Pequenos Mundos - Novas Crónicas das Fronteiras da Ciência. 2 ed, Ciência Aberta. Lisboa: Gradiva.

Carroll, Stewart. 2008. BIM: When Will It Enter “The Ours” Zone? AECbytes (40), http://www.aecbytes.com/viewpoint/2008/issue_40.html.

Choo, Seung Yeon. 2003. Study on Computer-Aided Design Support of Traditional Architectural Theories. Tese de Doutoramento, Faculdade de Arquitectura, Universidade Técnica de Munique, Munique.

CIMsteel. 1998. CIMsteel Project Homepage  [acedido a 31 de Outubro 2008]. Disponível em http://www.engineering.leeds.ac.uk/civil/research/cae/past/cimsteel/cimsteel.htm.

Clark, Donald. 2004. Understanding  [acedido a 11 de Abril 2006]. Disponível em http://www.nwlink.com/~donclark/performance/understanding.html.

Cook, Chris. 2004. Scaling the Building Information Mountain. CAD User AEC Magazine, Março/Abril 2004.

Copeland, Claudia. 2005. Hurricane-Damaged Drinking Water and Wastewater Facilities: Impacts, Needs, and Response. Washington D.C., EUA: Congressional Research Service, Library of Congress

Correa, Patricio Ramirez. 2004. Rol y contribución de los sistemas de planificación de los recursos de la empresa (ERP). Tese de Doutoramento, Departamento de Administración de Empresas Y Comercialización e Investigaciones de Mercados (Marketing), Universidad de Sevilla, Sevilha.

CURT. 2004. Collaboration, Integrated Information, and the Project Lifecycle in Building Design, Construction and Operation (WP-1202): The Construction Users Roundtable.

Dainty, Andrew, David Moore e Michael Murray. 2006. Communication in construction - Theory and practice. Vol. 1. Nova Iorque: Taylor Francis.

Davenport, Thomas H. e Donald A. Marchand. 2000. Mastering information management. London ; New York: Financial Times/Prentice Hall.

Delcambre, Lois, Vijay Khatri, Yair Wand, Barbara Williams, Carson Woo e Mark Zozulia. 2006. Eliciting Data Semantics Via Top-Down and Bottom-Up Approaches: Challenges and Opportunities Artigo apresentado em: Conceptual Modeling - ER 2006, 25th International Conference on Conceptual Modeling, 6 a 9 de Novembro de 2006, Tucson, Arizona, EUA.

Dippon, Christian M. e Kenneth E. Train. 2000. The cost of the local telecommunication network: a comparison of minimum spanning trees and the HAI model. Telecommunications Policy 24 (3):253-262.

Du, D.-Z. e F.K. Hwang. 1990. An approach for proving lower bounds: solution of Gilbert-Pollakapos;sconjecture on Steiner ratio. Artigo apresentado em: 31st Annual Symposium on Foundations of Computer Science, 1990, St. Louis, MO, USA.

Duarte, Patrícia, Helena Alegre e Jaime Melo Baptista. 2004. Indicadores de desempenho para serviços de abastecimento de água. IRAR, LNEC ed, Guias Técnicos. Lisboa.

e-Business W@atch. 2004. Electronic Business in the Textile, Clothing and Footwear Industries - The quantitative picture: Diffusion of ICT and e-business in 2003/04.

———. 2005. ICT and Electronic Business in the Construction Industry: Key issues, case studies, conclusions. Bona/Bruxelas: The European e-Business Market Watch - Direcção Geral da Empresa e Indústria, Comissão Europeia.

———. 2006. ICT and e-Business in the Construction Construction Industry: ICT adoption and e-business activity in 2006. Copenhaga/Bruxelas: The European e-Business Market Watch - Direcção Geral da Empresa e Indústria, Comissão Europeia.

Eastman, Charles M. 1999. Building Product Models: Computer Environments, Supporting Design and Construction: CRC.

Eastman, Charles M., Paul Teicholz, Rafael Sacks e Kathleen Liston. 2008. BIM handbook : a guide to building information modeling for owners, managers, designers, engineers, and contractors. Hoboken, N.J.: Wiley.

El-Desouki, Maha e Abdel Hady Hosny. 2005. A Framework Model for Workflow Automation in Construction Industry Artigo apresentado em: International Workshop on Innovations in Materials and Design of Civil Infrastructure, 28 - 29 de Dezembro, Cairo, Egipto.

Enterprise Ireland. 2002. Competitive Advantage Through IT and eBusiness; a Handbook for Irish Managers. Dublin.

EPAL. 2006. Manual de Redes Prediais (Versão 2/2006) [acedido a 01 de Abril 2008]. Disponível em: http://www.epal.pt/Epal/Modelo13.aspx?src=ManRedesPrediasarea=287sub=1525menu=1525.

Fonseca, M. Santos. 1998. Curso sobre regras de medição na construção. 2 ed. Lisboa: Laboratório Nacional de Engenharia Civil.

Fortune, Steven. 1987. A sweepline algorithm for Voronoi diagrams. Algorithmica 2 (1):153-174.

Gallaher, M. P.; O'Connor, A. C.; Dettbarn, J. L., Jr.; Gilday, L. T. . 2004. Cost Analysis of Inadequate Interoperability in the U.S. Capital Facilities Industry. Gaithersburg, Maryland, EUA: National Institute of Standards and Technology, U.S. Department of Commerce Technology Administration.

Gielingh, Wim. 1988. General AEC Reference Model (GARM), an aid for the integration of applications specific data models. Artigo apresentado em: CIB Conference on The Conceptual Modeling of Buildings, Outubro 1988, Lund, Suécia.

Gilbert, E.N. e H.O. Pollak. 1968. Steiner minimal trees. SIAM Journal on Applied Mathematics 16:1-29.

Gonçalves, Rodrigo Franco, Rita Cristina Ferreira, Eduardo Toledo Santos e Marcelo Schneck de Paula Pessôa. 2007. Um modelo em UML para a Representação Sistêmica de Projectos AEC. Artigo apresentado em: TIC 2007 - III Encontro de Tecnologia de Informação e Comunicação na Construção Civil, 11 e 12 de Julho de 2007, Porto Alegre.

Grieves, Michael. 2006. Product Lifecycle Management. Nova Iorque: McGraw-Hill.

Groff, James R. e Paul N. Weinberg. 2002. SQL: the complete reference. New York, NY: McGraw-Hill Professional.

Gruber, Thomas R. 1993. Toward Principles for the Design of Ontologies Used for Knowledge Sharing International Journal Human-Computer Studies (43):907-928.

———. 1993. A Translation Approach to Portable Ontology Specifications. Knowledge Acquisition 5 (2):199-220.

Gutin, Gregory, Jørgen Bang-Jensen e Anders Yeo. 2004. When the greedy algorithm fails. Discrete Optimization 1 (2):121-127.

Gutin, Gregory, Anders Yeo e Alexey Zverovich. 2001. Traveling Salesman Should not be Greedy: Domination Analysis of Greedy-Type Heuristics for the TSP. BRICS Report Series:1-7.

Harberg, Robert J. 1997. Planning and managing reliable urban water systems. Denver: American Water Works Association.

Hurley, Roger. 2007. Exclusive Result Findings Comparing The Reliability Of Plastic Vs. Metal Pipe Materials. In Global Water Leakage Summit - Adopting The Most Effective Strategy for Water Efficiency and Leakage Management. Londres.

IAI - International Alliance for Interoperability. 2001. The Federal Initiative: Commitment to Information Interoperability in the AEC + FM + BPF + OM Industries. Draft Discussion Paper.

IAI. 2006. IFC2x Edition 3 Final Documentation  [acedido a 12/09/2006 2006]. Disponível em http://www.iai-international.org/Model/R2x3_final/index.htm.

ICC. 2006. SMARTCodes homepage, http://www.iccsafe.org/SMARTcodes/index.html  [acedido a 17 de Outubro 2008]. Disponível em http://www.iccsafe.org/SMARTcodes/index.html.

———. 2008. International Code Council - Factsheet  [acedido a 17 de Outubro 2008]. Disponível em http://www.iccsafe.org/news/pdf/factssheet.pdf.

IGES. 1999. The Initial Graphics Exchange Specification (IGES) Version 5.x: IGES.

INE. 2003. Anuário Estatístico de Portugal Lisboa.

ISO. 1982. ISO/TC97/SC5/WG3: Concepts and Terminology for the Conceptual Schema and Information.

———. 1994. Building Construction Core Model, Project Proposal, TC184/SC4/WG3 document N341.

Jacoski, Claudio Alcides e Roberto Lamberts. 2002. A interoperabilidade como factor de integração de projetos na construção civil. In II Workshop Nacional: Gestão do processo de projeto na construção de edifícios. Porto Alegre: Pontifícia Universidade Católica do Rio Grande do Sul.

Jin, Li, Donguk Kim, Lisen Mu, Deok-Soo Kim e Shi-Min Hu. 2006. A sweepline algorithm for Euclidean Voronoi diagram of circles. Computer-Aided Design 38 (3):260-272.

Johnson, Robert, Mark Clayton e Yunsik Song. 1999. A Research Agenda For The AEC Community in 2000 and Beyond. Artigo apresentado em: Berkeley-Stanford CEM Workshop: Defining a Research Agenda for AEC Process/Product Development in 2000 and Beyond, 26 a 28 de Agosto, Stanford University.

Juli, Rudolf e Thomas Liebich. 2006. Experiences with BIM. Establishing the use of Building Information Models and the role of IFC integration. Artigo apresentado em: Building Information Model - International Workshop, 28 e 29 Setembro de 2006, Lisboa.

Khemlani, Lachmi. 2004. The IFC Building Model: A Look Under the Hood. AECbytes (3), http://www.aecbytes.com/feature/2004/IFCmodel.html.

———. 2005. CORENET e-PlanCheck: Singapore's Automated Code Checking System. AECbytes (23), http://www.aecbytes.com/buildingthefuture/2005/CORENETePlanCheck.html.

Kiviniemi, Arto. 2005. Requirements Management Interface to Building Product Models, Center for Integrated Facility Engineering, Stanford University, Stanford.

Koch, Christopher. 2006. The ABCs of ERP. CIO Magazine.

Kruskal, Joseph B., Jr. 1956. On the Shortest Spanning Subtree of a Graph and the Traveling Salesman Problem Proceedings of the American Mathematical Society 7 (1):48-50.

Latham, Michael. 1994. Constructing the team : final report : joint review of procurement and contractual arrangements in the United Kingdom construction industry. London: HMSO.

Laudon, Jane P. e Kenneth C. Laudon. 2002. ActiveBook Essentials of MIS. Upper Saddle River, NJ: Prentice Hall.

Laudon, Kenneth C e Jane P Laudon. 2006. Management information systems managing the digital firm. 9 ed. Upper Saddle River, NJ: Pearson Prentice Hall.

Laudon, Kenneth C e Jane Price Laudon. 2002. Management information systems activebook, version 1.0. 5 ed. Upper Saddle River, NJ: Prentice Hall.

Lee, Joo-Sung, Kyung-Min Min, Yoon-Sun Lee e Ju-Hyung Kim. 2008. Building Ontology to Implement the BIM (Building Information Modelling) Focused on Pre-Design Stage Artigo apresentado em: ISARC 2008: The 25th International Symposium on Automation and Robotics in Construction, 26-29 de Junho de 2008, Vilnius, Lituânia.

Lee, Matthew T. 1998. The Ford Pinto Case and the Development of Auto Safety Regulations, 1893-1978. Business and Economic History 27 (2):390-401.

Lester, Thomas G. 2003. Solving for Friction Factor. ASHRAE JOURNAL 45 (7):41-44.

Leveson, Nancy G. 2000. System Safety in Computer-Controlled Automotive Systems. Artigo apresentado em: SAE Congress, 6 a 9 Março 2000, Detroit, EUA.

Libicki, Martin C. 1995. Standards: The Rough Road to the Common Byte. In Standards Policy for Information Infrastructure, edited by Brian Kahin and Janet Abbate: MIT Press.

Libicki, Martin, James Schneider, David R. Frelinger e Anna Slomovic. 2000. Scaffolding the New Web. Santa Monica, Califórnia: RAND.

MacDonald, Matthew. 2008. Pro WPF with VB 2008: Windows Presentation Foundation with .NET 3.5: Apress.

Malucelli, Andreia. 2006. Ontology-based services for agents interoperability. Tese de Doutoramento, Faculdade de Engenharia, Universidade do Porto, Porto.

Mansoor, Arshad, Mark McGranaghan e Karen Forsten. 2004. Quantifying Reliability and Service Quality. Transmission Distribution World.

Matavalam, Roop Kishore R. 2004. Power Distribuition Reliability as a Function of Weather Tese de Mestrado, University of Florida.

McGraw Hill Construction. 2007. Interoperability in the Construction Industry SmartMarket Report. McGraw Hill [acedido a 16 de Outubro 2008]. Disponível em http://construction.ecnext.com/mcgraw_hill/includes/SMRI.pdf.

Minges, Michael, Magda Ismail e Larry Press. 2001. The e-City: Singapore Internet Case Study. Genebra, Suiça: International Telecomunication Union.

Ministério das Obras Públicas, Transportes e Comunicações. 1995. Decreto Regulamentar nº 23/95 de 23 de Agosto - Regulamento Geral dos Sistemas Públicos e Prediais de Distribuição de Água e de Drenagem de Águas Residuais: Imprensa Nacional.

Netcraft. 2009. Web Server Survey  [acedido a 18-02-2009 2009]. Disponível em http://news.netcraft.com/archives/web_server_survey.html.

Ng, S. Thomas, Swee Eng Chen, Denny McGeorge, Ka-Chi Lam e Simon Evans. 2001. Current state of IT usage by Australian subcontractors. Construction Innovation: Information, Process, Management 1 (1):3-13.

O’Day, D.K., Weiss, R., Chiavari, S., Blair, D. 1986. Water Main Evaluation for Rehabilitation/Replacement. Denver, Colorado: American Water Works Association Research Foundation.

OFWAT. 2003. Security of supply, leakage and the efficient use of water. 2002–2003 report: Office of Water Services.

Ohnsman, Alan. 2005. Toyota Trimming Auto-Development Time to 12 Months (Update1). Bloomberg.com, 13 de Outubro de 2008 [acedido a. Disponível em http://www.bloomberg.com/apps/news?pid=10000101sid=aou5D442lIVgrefer=japan.

Pacheco, Fernando da Costa. 1997. Dicionário Técnico de Construção Civil. Mafra: Sindicato Nacional dos Engenheiros Técnicos.

Paixão, Mário de Assis. 1999. Águas e Esgotos em Urbanizações e Instalações Prediais. 2 ed. Amadora: Edições Orion.

Pereira, Manuel João. 2005. Sistemas de Informação: uma abordagem sistémica: Universidade Católica Editora.

Pettie, Seth e Vijaya Ramachandran. 2001. An Optimal Minimum Spanning Tree Algorithm. Journal of the ACM (JACM) 49 (1):16-34.

Petzold, Charles. 2007. 3D Programming for Windows: Three-Dimensional Graphics Programming for the Windows Presentation Foundation Redmond: Microsoft Press.

Pimentel, Eduardo. 2006. Melhores Práticas da Gestão da Construção em Portugal. Artigo apresentado em: Building Information Model - International Workshop, 28 e 29 de Setembro, Lisboa.

Poças Martins, João. 2004. Métodos Computacionais na Geometria. Provas de Aptidão Pedagógica e Capacidade Científica, Faculdade de Engenharia, Universidade do Porto, Porto.

———. 2006. Sistemas de Informação na Construção: Semana da Tecnologia e da Gestão, IPB.

Poças Martins, João e Joaquim Poças Martins. 2008. Indicadores de fiabilidade de redes de abastecimento de água. Artigo apresentado em: GESCON 2008, 11 e 12 de Dezembro, Porto.

Poças Martins, Joaquim e João Poças Martins. 2007. Reliability of Water Supply Systems. Artigo apresentado em: CERUP - International Conference Risk Management In Production Activities, 10 de Outubro, Porto.

Polanyi, Michael. 1962. Personal Knowledge: Towards a Post-critical Philosophy: Routledge.

Powell, Gavin. 2006. Beginning Database Design. Indianapolis, Indiana: Wiley.

Prim, Robert C. 1957. Shortest connection networks and some generalizations. Bell System Technical Journal 36:1389–1401.

Pulsifer, Doris. 2008. A Case for Knowledge Management in the A/E Industry. AECbytes (41), http://www.aecbytes.com/viewpoint/2008/issue_41.html.

Rebbeck, Peter. 2006. The New Information Management Model in Construction. Artigo apresentado em: Building Information Model - International Workshop, 28 e 29 de Setembro, Lisboa.

Roberts, Don e Xavier Davis. 2003. Customer-Oriented Reliability. In Transmission Distribution World: Prism Business Media.

Rodrigues, José Alves. 2003. Instruções para o Cálculo Dos Honorários Referentes Aos Projectos de Obras Públicas - Ministério das Obras Públicas, Transportes e Comunicações: Rei dos Livros.

Rogers, W. P. 1986. Report of the PRESIDENTIAL COMMISSION on the Space Shuttle Challenger Accident: U.S. Government Printing Office.

Rooth, Øivind. 2004. ByggSøk - Norwegian system for eGovernment In the field of Zoning, Building and Construction. Singapura.

Røstum, Jon. 2000. Statistical modelling of pipe failures in water networks. Tese de Doutoramento, Faculty of Civil Engineering, Norwegian University of Science and Technology, Trondheim.

Sanabria, Doeg Rodríguez. 2005. Comparative Framework for Service Reliability in Electric Distribution Systems. Tese de Mestrado, University of Puerto Rico.

Santos, Inácio Fernando de Carvalho Almeida. 2002. Modelización de edificios de viviendas para la verificación automática de requisitos formales asociados a las normas generales de construcción: Un desarrollo basado en los estándares IFC y UML. Tese de Doutoramento, Universidad de Sevilla, Sevilha.

Serghides, T. K. 1984. Estimate friction factor accurately. Chemical engineering 91 (5):63-64.

Sharma, Nikhil. 2005. The Origin of the “Data Information Knowledge Wisdom” Hierarchy  [acedido a 21 de Março 2009]. Disponível em http://www-personal.si.umich.edu/~nsharma/dikw_origin.htm.

Sheth, A. 1995. Data semantics: What, where and how? Artigo apresentado em: 6th IFIP Working Conference on Data Semantics (DS-6), 30 de Maio - 2 de Junho de 1995, Stone Mountain, Atlanta, Georgia, EUA.

Silva Afonso, Armando Baptista. 1997. O novo regulamento português de águas e esgotos anotado e comentado. Coimbra: Casa do Castelo.

———. 2001. Contributos para o dimensionamento de redes de águas em edifícios especiais Aplicação de modelos matemáticos. Tese de Doutoramento, Faculdade de Engenharia, Universidade do Porto, Porto.

Sjøgren, Jøns. 2005. Governmental and Industry experience in Norway. Madrid, 23-24 Fevereiro 2005.

———. 2006. Norwegian builders in the driver’s seat. EXPRESSway (9):2.

Sousa, Hipólito de, Joaquim Moreira, Armando Manso, João Viegas e Luís Guardão. 2007. A Importância do ProNIC® para a Gestão da Informação na Construção Portuguesa. Artigo apresentado em: Congresso Construção 2007 - 3.º Congresso Nacional, 17 a 19 de Dezembro, Coimbra, Portugal

Sousa, Hipólito de, Joaquim Moreira, Pedro Mêda e Paulo de Carvalho. 2007. A Estrutura Organizativa da Informação Técnica do ProNIC®  para Execução de Trabalhos de Construção. Artigo apresentado em: Congresso Construção 2007 - 3.º Congresso Nacional, 17 a 19 de Dezembro, Coimbra, Portugal.

Stevens, Jeff. 2006. BIM: The Contractors' Perspective. Artigo apresentado em: Building Information Model - International Workshop, 28 e 29 de Outubro, Lisboa.

Steyn, Jacques. 2001. Data, Information, Knowledge and Wisdom  [acedido a 4 de Abril 2006]. Disponível em http://www.knowsystems.com/km/definition.html.

Sunday, Dan. 2001. Geometry Algorithms  [acedido a 12 de Julho 2008]. Disponível em http://www.geometryalgorithms.com/.

Sutherland, Ivan. 1963. Sketchpad, A Man-Machine Graphical Communication System. Tese de Doutoramento, Cambridge, Massachusetts Institute of Technology, Massachusetts.

Taleb, Nassim Nicholas. 2007. The Black Swan. Londres: Penguin Books.

Teicholz, Paul. 2004. Labor Productivity Declines in the Construction Industry: Causes and Remedies. AECbytes (4), http://www.aecbytes.com/viewpoint/2004/issue_4.html.

Trudeau, Richard J. 1993. Introduction to Graph Theory, Dover Books on Advanced Mathematics: Courier Dover Publications.

Turk, Ziga. 2001. Phenomenological  foundations  of  conceptual product  modelling  in  architecture,  engineering  and  construction. International Journal of AI in Engineering (15):83-92.

UltiDev LLC. 2006. UltiDev Cassini Web Server for ASP.NET Applications  [acedido a 27 de Setembro 2006]. Disponível em http://www.ultidev.com/products/Cassini/index.htm.

Verma, Mahendra P. 2008. MOODYCHART: An ActiveX component to calculate frictional factor for fluid flow in pipelines. Artigo apresentado em: Thirty-Third Workshop on Geothermal Reservoir Engineering, Stanford University, Stanford, California.

Warme, David Michael. 1998. Spanning Trees in Hypergraphs with Applications to Steiner Trees. Tese de Doutoramento, Faculty of the School of Engineering and Applied Science, University of Virginia.

Warren, C.A. 2002. Overview of 1366-2001 the Full Use Guide on Electric Power Distribution Reliability Indices. Artigo apresentado em: Power Engineering Society Summer Meeting, 2002 IEEE, 25 de Julho 2002.

Watson, Alastair. 1997. Deploying the CIMsteel Integration Standards. Artigo apresentado em: 3rd European Conference on Product Data Technology, Abril 1997, Sophia Antipolis, França.

Weise, M., T. Liebich e J. Wix. 2008. Integrating use case definitions for IFC developments. InPro, http://www.inpro-project.eu/media/Integrating_UseCase_def.pdf.

Wix, Jefferey. 2006. Building-codes checking - Singapure's CORENET e-Submission. Artigo apresentado em: Building Information Model - International Workshop, 28 e 29 de Outubro, Lisboa.

Wix, Jefferey e R. See. 1999. IFC Specification Development Guide: International Alliance for Interoperability.

Womack, James P. e Daniel T. Jones. 2003. Lean Thinking. Londres: Simon Schuster.

Woods, W. A. 1975. What’s in a link: Foundations for semantic networks. In: Representation and understanding: Studies in cognitive science. In Representation and understanding: Studies in cognitive science, edited by Daniel Gureasko Bobrow and Allan Collins. Nova Iorque: Academic Press.

Yurchyshyna, Anastasiya, Catherine Zuker, Nhan Le-Than, Celson Lima e Alain Zarli. 2007. Towards an ontology-based approach for conformance checking modelling in construction. Artigo apresentado em: 24th W78 Conference, 26 a 29 de Junho de 2007, Maribor, Eslovénia.

[1] Interoperabilidade significa a capacidade de dois ou mais sistemas de informação comunicarem entre si. Quando aplicada a sistemas de informação relacionados com actividades industriais, pode definir-se como a capacidade para comunicar dados ao longo de diferentes actividades produtivas (Jacoski, Lamberts 2002).

[2] Admite-se que estes elementos possam passar a constituir informação caso “acrescentem valor nas tomadas de decisão”.

[3] O impacto da utilização de modelos paramétricos nos processos criativos é discutido em maior detalhe em (Turk 2001).

[4] Em rigor, não deverá ser considerado como um modelo parcial autónomo, mas antes como um subconjunto de um modelo completo.

[5] Esta exigência é comparável com o objectivo do programa ISO-STEP de “representar todos os aspectos estáticos e dinâmicos […] do universo de discurso” (ISO 1982)

[6] Tradução directa da terminologia usada na documentação de apresentação do Índice.

Table of Contents

Índice de figuras. xv

Índice de tabelas. xxi

1                             Introdução.. 1

1.1         Construção Civil: um sector ineficiente?. 1

1.2         Tecnologias de informação na construção: Situação actual   3

1.2.1           Adopção e adaptação de tecnologias da informação. 3

1.2.2           BIM: um novo paradigma na construção. 3

1.2.3           BIM: dificuldades em satisfazer exigências de utilizadores. 4

1.3         Licenciamento automático de projectos. 5

1.4         Âmbito e objectivos. 5

1.4.1           Âmbito. 5

1.4.2           Objectivos. 6

1.5         Estrutura da tese.. 7

2                             Estado da arte.. 9

2.1         Informação: Conceito.. 9

2.1.1           Modelo DIKW.. 9

2.1.2           Dados. 10

2.1.3           Informação. 10

2.1.4           Conhecimento. 11

2.1.5           Sabedoria. 12

2.1.6           Síntese. 12

2.2         Gestão da informação na construção.. 14

2.2.1           Especificidade do sector da construção. 14

2.2.2           Ineficiência na gestão da informação: alguns sintomas. 27

2.2.3           Das origens do CAD aos primeiros modelos paramétricos. 31

2.3         Sistemas e modelos de informação.. 33

2.3.1           Aspectos gerais. 33

2.3.2           Tecnologias, sistemas e modelos de informação. Definições adoptadas. 34

2.3.3           Modelos de informação “completos” e “parciais”. 42

2.3.4           Compatibilização de formatos. 50

2.3.5           Vectores de desenvolvimento: ERP, BIM e aplicações à medida. 51

2.4         Fluxo de Informação no Processo Construtivo.. 87

2.4.1           Introdução. 87

2.4.2           Processo construtivo. 90

2.4.3           Implementação e dinamização de um sistema de informação baseado num BIM   98

2.4.4           Características desejáveis num modelo de informação. 101

2.5         Licenciamento de projectos. 101

2.5.1           O papel do termo de responsabilidade. 101

2.5.2           A importância do processo de licenciamento no contexto da gestão da informação  105

2.5.3           Licenciamento automático de projectos: Iniciativas em curso. 107

2.5.4           Licenciamento de projectos de sistemas prediais de águas e esgotos. 108

2.5.5           Análise regulamentar. 111

2.6         Conclusões da revisão do estado da arte.. 121

2.6.1           Má gestão da construção: Um infeliz equilíbrio. 121

2.6.2           Caminhos possíveis para alterar o equilíbrio. 123

2.6.3           O papel dos modelos de informação para a construção. 123

2.6.4           O papel do processo de licenciamento automático de projectos. 124

3                             Requisitos a cumprir pelos projectos de sistemas de distribuição predi

3.1         Introdução.. 127

3.2         Segurança de pessoas e bens. 128