Orientativo BMS

EcoStruxure for Healthcare
HOSPITAL UNIMED BELÉM
Descritivo orientativo do
Sistema unificado de
infraestrutura hospitalar
EcoStruxure for Healthcare – Unimed Belém
Objetivo
O objetivo deste documento é fornecer dados e estabelecer

parâmetros para a análise de viabilidade operacional e
orçamentária de um sistema que monitore e controle todo o
Ecossistema da Infraestrutura do hospital UNIMED BELÉM.
Este documento foi produzido em conjunto com a coordenação

de engenharia e manutenção do HUB.
pg. 1
As Fases
A implementação deste projeto será realizada em três fases.
A primeira, contemplada neste documento, reunirá em um único

software de Building & Energy Management System (BEMS) os
seguintes subsistemas:
Ar Condicionado, Monitoramento Elétrico, Gestão de Água Potável,
Monitoramento de Geladeiras e Detecção de Incêndio.
A segunda, acrescentará ao sistema:

Monitoramento de Gases, Monitoramento de Ruído, RTLS,
Integração com o sistema de hotelaria e o de manutenção do
Hospital.
A terceira e última fase, reunirá todos os dados coletados em

softwares “na nuvem” com a intenção de utilizar Machine
Learning e Inteligência Artificial para coordenar o uso da
infraestrutura em favor do business da instituição.
Nesta última fase, o EcoStruxure passa para a camada de
analíticos com suporte para a gestão sustentável dos recursos
através do Resource Advisor. Além de poder contar com as
vantagens do Building Advisor e Power Advisor.
Ferramentas capazes de extrair o máximo de insights possíveis
para melhorar a operação, eficiência e manutenção constantes
dos equipamentos instalados.
pg. 2
Índice
Índice 3
EcoStruxure for Healthcare 4
1. Sistema supervisório 4
a. Software 4
O Hospital já conta com os seguintes softwares: Erro! Indicador não definido.
 EcoStruxure Building Operator Erro! Indicador não definido.
 EcoStruxure Power Monitoring Expert Erro! Indicador não definido.
Não sendo necessária nova aquisição! Este documento se refere a integração destes sistemas e a
união dos outros BMS implementados em um único guarda-chuva. Erro! Indicador não definido.
PLANTA BAIXA – Para localização espacial 4
EQUIPAMENTOS: 4
ÁREA CLÍNICA: 6
GESTÃO DE FACILITIES: 7
b. Servidor 8
c. Sala de operação 8
2. Ar Condicionado 9
Centrais de água gelada 9
a. Chillers 9
3. Fancoils e similares 11
a. Fancoils 11
b. Fancoletes 12
c. Splits, K7 ou aparelhos de janela com controle remoto 12
d. VRFs 12
4. Caldeiras 13
a. Aquecimento 13
5. UPS 14
6. Geradores 15
7. IT Médico 16
8. Medição de Energia 17
9. Gestão de Água 22
10. Interface com sistema de incêndio 24
11. Monitoramento de Gases 24
1. Abreviações 26
2. Comunicações e protocolos 26
3. Controladoras 26
pg. 3
1. Sistema supervisório
a. Software
Tem como propósito oferecer uma visão operacional e gerencial da infraestrutura
hospitalar dividindo-se em áreas de atuação contendo:
PLANTA BAIXA – Para localização espacial
EQUIPAMENTOS:
Esta divisão do software deve oferecer dados técnicos dos equipamentos, contendo as
informações necessárias para a manutenção e operação reduzindo os riscos de interrupção.
 HVAC (Chillers, Fancoils, Fancoletes, K7, VRF, Splits, Caldeiras)

 Elétrica (MT, BT, Geradores, UPS, IT Médico, Iluminação)
 Gestão de água potável
 Monitoramento de gases
pg. 4
 Interface com painéis de incêndio
pg. 5
ÁREA CLÍNICA:
Esta área é reservada a gestão da área clínica onde o BEMS, integrado ao sistema de
gerenciamento de pacientes, poderá prover em um único ambiente dados de infraestrutura e
gerenciais dos usos das áreas de atendimento hospitalar.
Informações como:
 Taxas de ocupação e utilização

 Ociosidade
 Tempo de espera
 Número de camas disponível
 Quarto Disponível, em limpeza ou ocupado
 Número de Salas Cirúrgicas Disponíveis
 Tempo médio de: Cirurgia, Internação, Limpeza
 Localização de equipamentos (RTLS)
 Controle da automação dos quartos
 Índice de satisfação dos pacientes
pg. 6
GESTÃO DE FACILITIES:
Esta área é reservada a gestão de facilities e se destina a apresentar de maneira clara os
números de consumos dos diversos subsistemas e blocos do hospital.
 Consumos anuais e mensais de Energia, Água, Gases Médicos etc.

 Subdivisão consumo de energia (i.e. 30% Critica, 27% Equip, 10% Life Safety)
 Rateio de energia, agua e gases
pg. 7
b. Servidor
Considerar o provimento de um servidor com capacidade para abrigar as máquinas virtuais
do EcoStruxure Building, Power, IT e de Base de Dados.
As informações mínimas dos softwares se encontram em seus respectivos datasheets.
c. Sala de operação
Considerar o provimento de uma sala para a operação contendo 2 monitores de 40” que
ficarão justapostos lado a lado e outros 2 de 22” sobre as mesas.
 Em um dos Monitores de 40” mostrar o diagrama unifilar de elétrica

 No outro monitor de 40” os principais indicadores Mecânicos (Chillers,
Caldeiras, Gases Médicos e Fornecimento de água
 Em um dos monitores de 22” fica a operação e navegação do dia-a-dia
 Enquanto que no último, se apresentará a lista de alarmes
pg. 8
2. Ar Condicionado
A variedade de equipamentos de ar condicionado em hospitais nos obriga a separar esta
categoria em grupos. Entretanto as regras para o controle prevalecem as mesmas que serão
definidas a seguir:
 Por se tratar de um hospital o controle deve ser executado de maneira criteriosa

seguindo os parâmetros de recomendação da ASHRAE para a manutenção dos filtros e
componentes dos equipamentos.
 O ajuste de PID deverá se dar durante a partida em teste do sistema de forma
individual levando-se em consideração cada ambiente controlado. Este ajuste deve
priorizar o conforto dos pacientes em áreas médicas e buscar eficiência energética nas
demais áreas.
 A elaboração do programa de controle deverá partir sempre do conceito da
manutenção dos componentes do equipamento informando dados que auxiliem a sua
preservação máxima. Itens como tempo de funcionamento, períodos de trocas,
temporizadores para a próxima manutenção e alertas de mau funcionamento são
obrigatórios.
 Filtros são absolutamente necessários em fancoils de hospitais e são capazes de por a
perder todo o trabalho de recuperação dos pacientes. Portanto a gestão de alarmes
destes filtros deve ser tratada de maneira detalhada e seguindo as normas JCI e
equivalentes.
Centrais de água gelada
a. Chillers
Estes se dividem entre novos e velhos modelos.
Para modelos mais novos com interface de comunicação, seja ela BACnet, LonWorks ou
Modbus, a orientação é buscar os pontos que oferecerem maior relevância para a
manutenção e gestão destes equipamentos. Entretanto, para tornar padrão a forma de
mensurar a eficiência de Chillers, de diferentes marcas e idades em hospitais espalhados
por todo o complexo, utilizaremos sensores e medidores externos que trarão um resultado
alinhado e padronizado.
Sendo assim, mesmo que haja placas de comunicação nos Chillers, para cada equipamento
considerar um conjunto de controles e sensores para produzir um BTU Meter individual:
1 – Sensor de temperatura de entrada
1 – Sensor de temperatura de saída
1 – Sensor de vazão
1 – Válvula de bloqueio
1 – Medidor de energia
1 – Hidrômetro para água
pg. 9
Em posse destas informações será possível avaliar o desempenho individual de cada

equipamento seguindo a seguinte formula para calcular a carga térmica de cada Chiller:
Para realizar este cálculo, precisamos ter em mãos algumas informações:
 O fluxo de volume de água no evaporador (Sensor de Vazão)

 Temperatura de entrada e saída da água gelada (Sensores de temperatura)
Precisamos pesquisar as propriedades da água para as seguintes condições:
 A densidade da água na temperatura média (temp de entrada + temp de saída) / 2

 A Capacidade Calorífica Específica da água gelada à temperatura média
(temp de entrada + temp de saída) / 2
Com estas informações podemos calcular a capacidade de refrigeração de um Chiller.

Utilizando o exemplo de um sistema que possui fluxo da água refrigerada para o
evaporador de 0,0995 m³/s
Temperatura de entrada de 12ºC –> transformando para kelvin temos
(12 + 273,15 = 285,15 K)
Temperatura de saída de 6ºC –> transformando para kelvin temos
(6 + 273,15 = 279,15 K)
Obs. Adicionamos 273,15K ao Celsius para convertê-lo em unidades de Kelvin.
A capacidade específica de calor (Cp) é medida em unidades de kJ por kg por Kelvin.

Temperatura média é de 9ºC
( (12ºC + 6ºC) / 2)
Com isto procuramos as propriedades da água a essa temperatura para encontrar a
densidade de 999,78 kg/m³ e uma capacidade específica de calor de 4,19kJ / kg / K.
Usando a equação de energia de Q = ṁ x Cp x ΔT podemos calcular a capacidade de
refrigeração.
Q = (999,78 kg/m³ x 0,0995 m³/s) x 4,19 kJ / kg / K x ((285,15 K) – (279,15 K))
Isso nos dá uma resposta final de Q = 2.501kW de resfriamento.
2500kW / 3,517 = 711 TR
Uma vez descoberta a capacidade de cada Chiller o hospital poderá descobrir quais
equipamentos precisam mais ou menos de investimentos em manutenção.
pg. 10
3. Fancoils e similares
a. Fancoils
Estes também são de diversos tipos e idades nos vários edifícios e blocos. Sendo assim
separaremos em categorias
Novos:
Considerar, sempre onde for aplicável o conceito de Room Controllers (SE8000 series por
exemplo) que encerram em um só produto a capacidade de controlar o ar condicionado,
ler a temperatura ambiente, permitir o ajuste de temperatura por display local e se
comunicar via BACnet MS/TP.
Onde não for possível em função da quantidade de pontos, utilizar controladores BACnet
IP.
Existentes:
Para os fancoils que já possuem automação, será necessário trazê-los para o BEMS
utilizando-se de gerenciadoras e/ou gateways que falem com diversas marcas e
protocolos. Estes, porém, deverão ser padronizados com os mesmos formatos de alarmes
e conceitos com a intenção de que o resultado final seja de operação simples igualitária.
A intenção é facilitar o treinamento de novos funcionários reduzindo o tempo de
aprendizado.
pg. 11
b. Fancoletes
Considerar o conceito de Room Controllers que encerram em um só produto a capacidade
de controlar o ar condicionado, ler a temperatura ambiente, permitir o ajuste de
temperatura por display local e se comunicar via BACnet MS/TP.
Para cada grupo de até 45 fancoletes, considerar um gerenciador BACnet IP.
Estes Room Controllers farão a interação com o sistema de gerenciamento de hóspedes e
poderão mostrar mensagens personalizadas de boas-vindas, assim como mudar o setpoint
para modo de economia quando a janela do quarto for aberta.
c. Splits, K7 ou aparelhos de janela com controle remoto
Os Splits, K7 ou aparelhos de janela que possuam controle remoto poderão ser controlados
por um emulador de IR instalado nas salas onde estes equipamentos atendem.
Estes emuladores deverão possuir comunicação webservices e assim serem conectados ao
sistema de BMS através de conexão IP.
d. VRFs
Caso exista refrigeração executada por VRFs oferecer formas de comunicação

preferencialmente BACnet.
pg. 12
4. Caldeiras
a. Aquecimento
O fornecimento de água quente para o hospital ocorre normalmente através do uso de
caldeiras e estas devem funcionar ininterruptamente. O sistema de BEMS tem que garantir
este fornecimento monitorando:
 Temperatura de saída das caldeiras (Individual)
 Estado das bombas (Ligado/Desligado e Falha)
 Consumo de energia (Usando medidores de energia)
 Consumo de água (Hidrômetro pulsado ligado ao medidor de energia)
 Fluxograma (Distribuição da tubulação)
 Agenda de Manutenção
Exemplo de Tela
pg. 13
5. UPS
A maior parte do parque de UPS instalados possui comunicação ou modbus ou SNMP.

Estes equipamentos deverão ser monitorados através de ferramenta específica para UPS
oferecendo dados que auxiliem na prevenção de falhas e ofereçam informações precisas
sobre as condições de baterias e momentos adequados para a substituição destas.
Poderão ser integrados no EcoStruxure Power ou EcoStruxure DCE.
pg. 14
6. Geradores
Em caso de falta de energia, são os UPS que mantêm o hospital funcionando e é desnecessário
dizer o quanto o sistema de BEMS deve oferecer recursos para que a manutenção possa
antecipar falhas e resolve-las o mais breve possível.
Os geradores deverão ser monitorados pelo EcoStruxure Power e seus respectivos módulos de
testes de funcionamento.
pg. 15
7. IT Médico
Para a integração com o sistema de IT Médico (sistema de aterramento) será realizado através
do protocolo Modbus TCP dos equipamentos já instalados.
As informações poderão ser replicadas para as IHM das Salas Cirúrgicas.
A Tabela Modbus com os registros, deverá ser fornecido pelos fabricantes do equipamento.
O sistema EcoStruxure recebe as informações e aciona as equipes de manutenção para a rápida
correção da falha.
pg. 16
8. Medição de Energia
1. Mais do que simplesmente buscar dados dos displays de medidores, o sistema de

BEMS deve ser uma ferramenta de diagnóstico da saúde elétrica do hospital.
Deve possuir um diagrama unifilar
Trazer dados recomendados pelo fabricante:
pg. 17
Gerenciamento de Energia:
• Tendência de consumo mensal
• Tendência de consumo semanal
• Ranking de consumidores de energia
• Comparação entre consumidores, podendo incluir diferentes unid de medida
• Relatório de custo de energia
• Relatório de comparação entre períodos (ex: Corrente x mês anterior).
• Relatório de consumo de energia por turno de trabalho.
• Relatório por período de horas dentro do dia.
• Relatório de consumo de energia
• Perfil de carga. Representação gráfica do nível de carga dentro de um período.
Conhecendo os horários de maior carga nos transformadores, o usuário pode planejar

a utilização dos equipamentos para evitar sobrecargas ou picos de demanda.
Rateio e alocação de custos:
• Permitir criar grupos de consumidores e realizar o “faturamento” de cada um

deles baseado num total de consumo.
Relatórios gerais:
 Exportação de dados padrão. Permitir exportar dados para arquivos Excel.

 Exportação de dados estendida. Permitir exportar dados detalhados para
arquivos Excel.
 Eventos do sistema. Apresentar uma lista com o instante, o nome e a
prioridade de cada evento registrado para um dado período.
 Relatório de configuração do sistema.
 Relatório tabular. Permitir montar uma tabela com registros de qualquer
grandeza elétrica, de qualquer um dos medidores do sistema.
pg. 18
Qualidade de Energia:
• EN50160. Relatório apresentando uma análise da qualidade de energia com

base no padrão europeu EN50160. Neste relatório eventos como afundamento de
tensão, elevação de tensão, desequilíbrio de fases, harmônicas, frequência e
interrupções são avaliados dentro dos critérios estabelecidos pela EN50160.
• IEEE519. Utiliza o padrão IEEE519 para avaliar o comportamento de

harmônicas no sistema.
• IEC61000-4-30. Utiliza a norma IEC61000-4-30 para avaliar a qualidade de

energia do sistema. Esta norma avalia o perfil de tensão, harmônica total, desequilíbrio
de carga, oscilação de tensão e estabilidade de frequência do sistema.
• Relatório de qualidade de energia. Analisa os registros de variação de tensão

no sistema e gera a curva CBEMA resultante.
pg. 19
Tendência de consumo:
• Cinco relatórios que permitem analisar os dados de diversas formas,

comparando diversas grandezas, de qualquer medidor e dentro de qualquer período.
Performance de equipamento:
• Acompanhamento da vida útil de disjuntores (se integrados a disjuntores

Schneider).
• Executar teste no sistema de energia de emergência (geradores) e emite
relatório com o resultado do teste.
• Perfil de carga do sistema de transferência
Performance de geradores:
• Atividade dos geradores.

• Estado das baterias dos geradores.
• Acompanhamento da vida útil de disjuntores.
• Avaliação da capacidade dos geradores.
• Curva de carga dos geradores.
2. Dashboards.
Os Dashboards (painéis) são um meio de visualizar dados instantâneos e históricos de

forma organizada, através de objetos chamados “gadgets”.
O sistema conta com objetos para composição de gráficos de barras verticais e

horizontais, gráficos pizza, período vs período e tendências. Através do objeto Web
Viewer pode-se abrir uma página web dentro do dashboard.
pg. 20
4. Medidores virtuais.
O sistema permite criar “medidores virtuais”, compostos pela soma de medidores

reais, para compor medições completas dos centros de custos existentes.
5. Módulo notificador de eventos (Event Notification Module).
Permite enviar email aos responsáveis pelos consumos das áreas com seu respectivo
relatório de consumo. Também permite informar a ocorrência de eventos pré-
definidos.
6. Integração com dispositivos de terceiros.
Caso os controladores dos geradores possuam protocolo modbus, esses podem ser
integrados ao sistema. Desta forma parâmetros do sistema gerador, como
temperatura do óleo e outros, podem ser exibidos na tela e até mesmo registrados em
histórico.
Pode-se, por exemplo, criar uma tela exibindo a temperatura dos transformadores.
Neste caso os relés 49T devem possuir comunicação modbus e estar integrados ao
sistema.
Uma vez integrados no sistema, alarmes referentes a esses dispositivos podem ser
implementados no sistema. Por exemplo, alta temperatura no transformador.
Essa integração auxilia na manutenção preventiva e corretiva dos equipamentos.
pg. 21
9. Gestão de Água
Em todo o complexo do HUB há muitos reservatórios de água potável, totalizando uma

capacidade de mais milhares de litros.
Sem água o hospital para. Portanto o sistema de BEMS deve oferecer todos os detalhes
necessários para impedir a interrupção de fornecimento.
O sistema de gerenciamento de água deverá informar e armazenar as seguintes variáveis:
 Nível das caixas (78%)

 Volume (15.325 litros)
 Autonomia (Baseado no consumo médio, restam 4 dias e 3 horas de fornecimento)
 Gráfico de consumo (Diário e Mensal)
 Bombas (Estado, Tempo de funcionamento, Consumo)
 Fluxograma (Mapa de tubulações)
 Mapa da Localização – (Como chegar a esta caixa d’água? Quais chaves eu preciso?)
 Agenda de limpeza – (Quando foi realizada a última limpeza? Quando será a Próxima?)
E os alarmes deverão ser o mais detalhado possível conforme instruções abaixo:
Exemplo:
Reservatório com nível crítico, verifique:
- Mostrar câmera na região dos reservatórios
- Verificar o fornecimento de água da SABESP
- Verificar a válvula V2 no Barrilete na Cobertura
- Verificar a solenoide de contenção de inundação
- Verificar estado das bombas
- Chamar Alberto no tel: 2222-23459
- Notificar Eng° Clinica – Pedro no tel. 2345-34567
- Fornecedor de água mais próximo: PCOMAGUA 3456-90878
Como a quantidade de reservatórios total é considerável, os dividimos em dois tipos:
Pequenos e Grandes. Onde foram considerados reservatórios Pequenos aqueles com
capacidade inferior a 5000 litros e Grandes os com capacidade superior a esta quantia.
Pequenos
Estes reservatórios de menor capacidade terão apenas supervisionadas as seguintes variáveis:
Nível (Chave de Nível), Consumo (Hidrômetro) e Sensor de tampa aberta
Grandes
Os grandes reservatórios terão supervisionadas as seguintes variáveis:
 Nível (Sensor Ultrassônico, sem contato com a água)

 Sensor de vazão de água
 Detecção de Líquidos
 Monitoramento de bombas e seu consumo (12 Bombas)
pg. 22
pg. 23
10. Interface com sistema de incêndio
Todo o complexo conta com uma considerável quantidade de painéis de marcas distintas e este
fato dificulta ou até invalida a correta integração entre os sistemas.
O EcoXpert contratado dever descobrir se os fabricantes possuem gateways para a integração.
Feita a integração, deverá ser realizado um workshop entre todas as áreas envolvidas para
determinar as medidas necessárias para equipamento em situação de incêndio.
Não ocorrendo esta definição por parte do hospital o integrador deverá considerar no mínimo
que os fancoils deverão se desligar, acender todas as luzes e liberar as travas de acesso.
11. Monitoramento de Gases
O fornecimento de gases ocorre em um único local e contará com um controlador IP para

coletar informações disponíveis por contato seco.
pg. 24

HOSPITAL UNIMED BELÉM
Premissas para a contratação

de Integrador EcoXpert
pg. 25
1.1 Padronização
1. Abreviações
 ASHRAE: American Society Heating, Refrigeration, Air Conditioning Engineers
 AHU: Air Handling Unit
 BACnet: Building Automation Controls Network
 BMS: Building Management System
 DDC: Direct Digital Control
 EIA: Electronic Industries Alliance
 GUI: Graphical User Interface
 HVAC: Heating, Ventilation, and Air Conditioning
 IEEE: Institute Electrical Electronic Engineers
 MER: Mechanical Equipment Room
 PID: Proportional, Integral, Derivative
 VAV: Variable Air Volume Box
2. Comunicações e protocolos
 CSMA/CD: Carrier Sense Multiple Access/Collision Detect
 DDE: Dynamic Data Exchange
 FTT: Free Topology Transceivers
 HTTP: Hyper Text Transfer Protocol
 IIOP: Internet Inter-ORB Protocol
 LAN: Local Area Network
 LON: Echelon Communication – Local Operating Network
 MS/TP: Master Slave Token Passing
 ODBC: Open Database Connectivity
 SNVT: Standard Network Variables Types
 SQL: Structured Query Language
 UDP: User Datagram Protocol
 XML: eXtensible Markup Language
3. Controladoras
 AAC: Advanced Application Controller
 ASC: Application Specific Controller.
 CAC: Custom Application Controller.
 DCU: Distributed Control Unit
 LCM: Local Control Module
 NSC: Network Server Controller
 PPC: Programmable Process Controller
 SDCU: Standalone Digital Control Units
 SLC: Supervisory Logic Controller
 UEC: Unitary Equipment Controller
 VAVDDC: Variable Air Volume Direct Digital Controller
pg. 26
1.2 Qualificação dos proponentes e pré-qualificação
A. Todos os proponentes devem ser EcoXperts certificados da Schneider Electric.

1. O Integrador de sistemas de Automação Predial deve ter disponível os serviços
necessários num raio de 150 Km da área de construção do projeto, com técnicos
e engenheiros treinados e certificados pelo fabricante para configuração,
programação dos serviços necessários para o sistema de automação. Os técnicos
da contratada deverá ser plenamente capaz de proporcionar instruções e serviço
de manutenção de emergência de rotina em todos os componentes do sistema.
2. Qualquer integrador de sistemas, não listado como pré-qualificado, deverá
apresentar credenciais detalhadas na apresentação da pré-proposta para revisão
do engenheiro duas semanas antes da data de licitação. Na falta dos
comprovantes mencionados, o integrador será desqualificado como proponente
do projeto. Documentos devem atestar que o integrador cumpre todos os
requisitos de especificação e conhecimento técnico dos engenheiros, de modo a
ser aprovado como instalador qualificado à licitação.
B. Qualquer integrador ou fabricante interessado em participar deste projeto deverá fazer uma
apresentação técnica ao consultor deste projeto. Todas as informações devem ser
submetidas 2 semanas antes da concorrência, para que o engenheiro consultor tenha tempo
suficiente para analisar a proposta enviada.
C. Para a apresentação de uma pré-licitação as informações seguintes serão necessárias:
1. Um perfil do fabricante e da instalação e manutenção/organização local.
2. Descrição de como o sistema atende e atinge todos os critérios especificados em
termos de configuração, operação e controle.
3. Arquitetura do Sistema com diagrama mostrando todos os componentes
principais (controladores digitais, roteadores, hubs, etc.) que serão necessários
para este projeto.
4. Procedimento para o comissionamento e o tempo necessário para o startup e
comissionamento de cada um dos sistemas para este projeto.
5. Abordagem do integrador para o planejamento e gerenciamento de projetos.
6. Catálogos de produtos para todos os componentes, painéis e todos os acessórios
apresentados de acordo com as seções de especificações apropriadas aqui
contidas.
7. Exemplos de telas gráficas reais de outros projetos semelhantes.
8. Número e tipos de painéis de controle necessários para a instalação.
9. Número e tipos de pontos do sistema proposto.
10. Lista de peças de reposição recomendadas para os componentes com a lista de
preços.
11. Lista de dois sistemas semelhantes instalados e comissionados anteriormente
pelo integrador, com uma lista dos membros da equipe de projeto e as
informações de contato.
12. Amostras de ofertas de serviços e uma lista de contratos de serviços similares
atuais com informações de contato.
13. Currículos da equipe de gestão e de todos os funcionários que estarão envolvidos
com a concepção do projeto, comissionamento, gerenciamento de projetos e
após o serviço de instalação. Currículos devem incluir cópias de certificações do
fabricante para a linha de produtos proposto.
pg. 27
14. Um checklist de toda a especificação do sistema com a conformidade dos

equipamentos e softwares do fabricante em relação aos requerimentos
especificados. Caso a exigência não pode ser cumprida, indicar as razões /
limitações e a alternativa proposta.
15. Uma entrevista pode ser realizada e o licitante será convidado a fazer uma
apresentação formal sobre o sistema proposto e, possivelmente, fornecer uma
visita em um dos projetos semelhantes antes de uma decisão final.
pg. 28
1.3 Escopo de trabalho
A. A Contratada deverá fornecer e instalar o EcoStruxure de forma completa, incluindo todo o

hardware necessário e todos os softwares aplicativos necessários para executar as seqüências
de operação de controle, como previsto na presente especificação. Todos os componentes
do sistema - estações de trabalho, servidores de aplicações, controladores, controladores
unitários, etc devem comunicar usando o protocolo BACnet (Padrão ASHRAE 135-2007 ou EIA
padrão 709.1) e o protocolo Modbus.
B. Exceto quando indicado, o sistema de controle será constituído por todos os controladores
de rede Ethernet necessárias, Unidades de Controle Digital, estações de trabalho, software,
sensores, transdutores, relés, válvulas, dampers, controladores de dampers, painéis de
controle e outros acessórios, juntamente com um sistema completo de elétrica interligado
para compor a especificação e fornecer um sistema completo e operacional. Salvo disposição
em contrário, fornecer aos atuadores de equipamentos, tais como dampers, se o fabricante
do equipamento não fornece estes. Coordenar os requisitos com os vários fornecedores.
C. A empresa a ser contratada deve analisar e estudar todos os desenhos de HVAC e de toda a
especificação a fim de se familiarizar com o equipamento e operação do sistema e para
verificar as quantidades e tipos de dampers, atuadores, alarmes, etc a serem fornecidos.
D. Todo o trabalho realizado descrito nesta secção deve cumprir todas as leis e órgãos de
governo. Se os desenhos e / ou especificações estão em conflito com os códigos de governo,
a contratada, com a orientação do engenheiro, deve apresentar uma proposta com as
modificações apropriadas para o projeto para atender restrições de código. Se esta
especificação e os desenhos associados exceder as exigências do código de governo, a
especificação permanecerá.
pg. 29
1.4 Descrição do software
A. De acordo com o escopo do trabalho, o sistema também deve fornecer uma interface gráfica
(baseada na web) para o operador que permite o acesso instantâneo a qualquer sistema
através de um navegador padrão. A contratada deve fornecer estações baseadas em PC para
programação, estações de trabalho de operador e microcomputador para controladores com
design modular que fornece capacidade de processamento distribuído, permitindo a
expansão futura de pontos de entrada/saída e funções de processamento/controle.
Para este projeto, o sistema é composto pelos seguintes componentes:
1. Estações de Trabalho para Administração e Programação: A contratada deverá
fornecer estações de trabalho de administração e programação do sistema. Estas
estações de trabalho devem executar o software padrão desenvolvido e testado
pelo fabricante dos controladores servidores e controladores autônomos.
Nenhum software de terceiros será aceitável na estação de trabalho. Postos de
trabalho devem estar de acordo com o perfil de dispositivo BACnet Operator
Workstation (B-OWS).
2. Estações de Trabalho do Operador Web (Webstation): O integrador de sistemas
deverá fornecer licenças para conexão com a web para o sistema de automação
predial. Usuários terão acesso a todos os pontos do sistema e gráficos, deve ser
capaz de receber e reconhecer os alarmes, e deve ser capaz de controlar pontos
de ajuste e outros parâmetros. Todo o trabalho de engenharia, tais como
tendências, relatórios, gráficos, etc, que são realizados na estação de trabalho
deve estar disponível para visualização através da interface do navegador (web
browser), sem alterações adicionais. A interface baseada na web deve estar de
acordo com o perfil do dispositivo BACnet Operator Workstation (B-OWS). Não
haverá necessidade de qualquer hardware baseado em computador adicional
para suportar a interface de usuário baseada na web.
3. Gerenciador (Servidor) de Rede Ethernet: A contratada deverá fornecer
gerenciadores de rede Ethernet. Esses controladores serão ligados diretamente
na estação de trabalho pela rede Ethernet (mínimo de 100 Mbps), e fornecer
comunicação com módulos de entrada/saída. Gerenciadores de rede devem
estar de acordo com o perfil do dispositivo BACnet Building Controller (B-BC).
Controladores de rede que utilizam comunicação serial RS232 ou ARCNET para
se comunicar com as estações de trabalho não serão aceitos.
Os gerenciadores de rede devem ser testados e certificados por um laboratório
certificado BACnet (BTL).
4. Unidades de Controle Digital Standalone (SDCUs): Fornecer a quantidade e os
tipos de SDCUs para atender aos requisitos do projeto para controle de
equipamentos. Cada SDCU funcionará completamente autônoma, contendo
todas as entradas/saídas e programas de controle internamente. Cada SDCU
BACnet deve estar de acordo com o perfil Bacnet Advanced Application
Controller (B-AAC). BACnet SDCUs deverão ser testados e certificados pelo
Laboratório de Ensaios BACnet (BTL).
B. A Rede Local (LAN) deve ser uma rede Ethernet com velocidade de 10 ou 100 Mpbs para
suportar os protocolos BACnet, Modbus, Java, XML, HTTP, CORBA IIOP, com a máxima
flexibilidade, para a integração de dados do edifício com os sistemas de informação da
empresa, fornecendo suporte para os múltiplos gerenciadores (servidor) de rede, estações
de trabalho do usuário e sistema de computador local.
pg. 30
C. A rede Ethernet (IEEE 802.3) LAN deve utilizar Carrier Sense Multiple/Access/Collision Detect
(CSMA/CD), Address Resolution Protocol (ARP) e User Datagram Protocol (UDP) operando em
10 ou 100 Mbps.
D. O sistema deve permitir uma arquitetura aberta que utiliza EIA padrão 709.1, protocolo
LonTalk™ e/ou funcionalidade BACnet (ANSI / ASHRAE™ Padrão 135-2007) para assegurar a
interoperabilidade entre todos os componentes do sistema. O suporte nativo para o
protocolo LonTalk™ e o protocolo BACnet (ANSI / ASHRAE™ Padrão 135-2007) são
necessários para assegurar que o projeto é totalmente suportado pelos protocolos abertos
de HVAC para reduzir futuras manutenções do empreendimento, atualizações e custos de
expansão.
E. O sistema deve permitir uma arquitetura que utiliza um protocolo MS/TP selecionável de 9,6-
76,8 KBaud, assim como a funcionalidade do protocolo BACnet (ANSI / ASHRAE ™ Padrão 135-
2008), de comunicação comum entre todos os controladores, para assegurar a
interoperabilidade entre todos os componentes do sistema. As SDCUs devem ser capaz de se
comunicar como um dispositivo MS/TP ou como um dispositivo BACnet IP, se comunicando a
10/100 Mbps em uma rede TCP/IP. O protocolo BACnet (ANSI / ASHRAE ™ Padrão 135-2008)
é necessário para garantir que o projeto é totalmente suportado pelos protocolos abertos de
HVAC, levando a reduzir futuras manutenções do empreendimento, atualizações e custos de
expansão.
F. As ferramentas de software necessárias para gerenciamento de rede do protocolo LonTalk™
e o protocolo BACnet (ANSI / ASHRAE ™ Padrão 135-2008) devem ser fornecidas com o
sistema. Os desenhos são apenas esquemáticos. Equipamentos e mão-de-obra não
especificamente aqui referidos ou no planejamento e que são obrigados a cumprir uma
funcionalidade, deverão ser fornecidos sem custo adicional para o proprietário. Requisito
mínimo de BACnet é Nível 4; com a capacidade de suportar funcionalidades de leitura e
escrita de dados. A ligação física de dispositivos BACnet será via Ethernet IP ou MS/TP. A
ligação física dos dispositivos LonWorks será via Ethernet IP ou FTT-10A.
G. O sistema deverá suportar protocolos Modbus TCP e RTU nativamente, sem a necessidade de
uso de gateways.
H. O barramento de campo deverá suportar o uso de comunicação wireless.
I. Sistema completo de controle de temperatura para ser DDC com sensores eletrônicos e
atuação eletrônica/elétrica da Quarto Equipamentos Mecânicos (MER) válvulas e dampers e
acionamento eletrônico das válvulas de equipamentos terminais e atuadores como aqui
especificado. O BMS é destinado a conectar diretamente dispositivos em todo o edifício,
independentemente do tipo de subsistema, ou seja, inversores de freqüência, sistemas de
iluminação de baixa tensão, disjuntores elétricos, medição de energia e cartão de acesso
devem facilmente coexistir no mesmo canal de rede.
1. O sistema fornecido deve incorporar a capacidade de acessar todos os dados
utilizando HTML5 habilitados sem a necessidade de programas proprietários de
interface de operação e configuração. Não serão aceitos sistemas que dependam
de atualização do JAVA para navegação.
2. Todo o banco de dados deve residir em um servidor para ser acessado de
qualquer dispositivo da rede.
3. Uma topologia hierárquica é necessária para garantir razoáveis tempos de
resposta do sistema e para gerenciar o fluxo e compartilhamento de dados sem
prejudicar a rede Intranet, interna do cliente.
pg. 31
J. Todo o trabalho descrito nesta seção deverá ser instalado, cabeado, testado e calibrado por
técnicos certificados e qualificados para este trabalho para comprovação de funcionamento
pelo fabricante. O integrador de sistema deverá ter um mínimo de 3 anos de experiência em
instalações com o fabricante e deve fornecer a documentação da licitação e pacote de
apresentação verificando longevidade do relacionamento com o fabricante, quando
solicitado. Supervisão, hardware e software de engenharia, calibração e verificação geral do
sistema deve ser feita por engenheiros da equipe técnica do integrador contratado, não
sendo permitida subcontratação.
K. Fornecer o comissionamento, configuração e ferramenta de diagnóstico (CCDT), software e
interfaces para fazer upload/download de Controladores de Contagem de Pontos (AAC),
Controladores Equipamento Unitário (UEC) e Controladores de VAV (VAVDDC),
monitoramento de todos os objetos BACnet, monitoramento de substituições de todos os
pontos de entrada/saída física do controlador e edição de horários residentes.
L. O sistema deve ter a capacidade de prover um Sistema de Gerenciamento de Energia (PEMS)
com o objetivo de monitorar uma infraestrutura completa de distribuição elétrica, da cabine
de entrada até os pontos de distribuição de baixa tensão. Este deverá ser projetado para
monitorar e gerenciar o consumo de energia em todo empreendimento, desde de uma
pequena instalação até uma rede de instalações, para melhorar a disponibilidade e
confiabilidade da energia e medir e gerenciar a eficiência energética. Deverá ser uma oferta
de produto padrão, sem a necessidade de programação personalizada. O sistema deverá
fornecer uma experiência de usuário integrada para o gerenciamento dos sistemas mecânicos
(HVAC e iluminação) e monitoramento da distribuição elétrica (transformadores, disjuntores,
relés, switches, capacitores, UPS, etc).
PART 2 - Produtos
2.1 Arquitetura do sistema
A. Gerais
1. O sistema de automação predial (BAS) consistirá de Servidor de Rede /
Controladores (NSCs), uma família de Unidades Controle Digital Standalone
(SDCUs), Estações de Trabalho de Administração e Programação (APWs), e
estações de trabalho do operador com base na Web (WOWs). O BAS deve
fornecer controle, detecção de alarme, programação horária, elaboração de
relatórios e gerenciamento de informações para toda a instalação, e uma rede
WAN (Wide Area Network), se aplicável.
2. Um nível Enterprise BAS consiste em um Servidor Principal (Enterprise Server),
que permite que vários NSCs (incluindo todos os gráficos, alarmes, horários,
tendências, programação e configuração) estejam acessíveis a partir de uma
única estação de trabalho ao mesmo tempo para as operações e tarefas de
engenharia.
3. O nível Enterprise BAS deverá permitir o uso de até 250 servidores/NSCs ou
abaixo disso.
4. Para a capacidade de geração de relatórios e a capacidade robusta de visualizar
listas e gráficos de tendência na estação de trabalho, um Servidor de Relatórios
(Reports Server) deverá ser instalado em um computador com Microsoft
Windows. O servidor de relatórios pode ser instalado no mesmo computador
que o Enterprise Server.
5. O sistema deve ser projetado com uma rede Ethernet de 10/100bT, usando
protocolos BACnet/IP, LonWorks IP, e/ou Modbus TCP.
pg. 32
6. Modbus RTU/ASCII (e J-bus), Modbus TCP, BACnet MS/TP, BACnet IP, LonTalk
FTT-10A , e WebServices devem ser nativos nos NSCs. Não deve haver a
necessidade de prover vários NSCs para suportar todos os protocolos de rede,
nem deve haver a necessidade de fornecer software adicional para permitir que
todos os três protocolos sejam nativos. A sub-rede de SDCUs, usando o BACnet
MS/TP, LonTalk FTT-10A, e / ou Modbus RTU, deverá conectar os controladores
locais com os gerenciadores/servidores de nível Ethernet IP.
B. Nível TCP/IP
1. A camada TCP/IP conecta todos os edifícios em uma única rede WAN isolada por
firewall. Devem ser utilizados endereços IP fixo para ligações entre o WAN e cada
dispositivo que se conecta à WAN.
C. Nível de rede de campo com as Unidades de Controle Digital Standalone (SDCUs)
1. A camada de campo deverá suportar todos os seguintes tipos de SDCUs:
a. Requisitos SDCU BACnet: O sistema poderá ser constituído por uma ou mais
redes de campo BACnet MS/TP gerenciados pelo controlador de servidor de
rede. Velocidade mínima de 76.8kbps. Essa camada consiste em uma rede
RS485, suportando até 50 Unidades de Controle Digital Standalone (SDCUs)
para operação de HVAC e equipamentos de iluminação. Estes dispositivos
devem estar em conformidade com a norma BACnet 135-2007.
b. Requisitos SDCU Modbus: O sistema poderá ser constituído por uma ou mais
redes de campo Modbus RTU (RS-485 ou RS-232), gerenciados pelo
controlador de servidor de rede. Essa rede de campo será composta por até
62 SDCUs para operação de HVAC, medição de potência e equipamentos de
iluminação. No caso de Modbus TCP, a rede de campo poderá ser composta
por até 100 SDCUs para operação de HVAC, medição de potência e
equipamentos de iluminação.
D. Segmentação BAS LAN
1. O BAS deve ser capaz de ser segmentado, por meio de software, em várias redes
locais (LANs) distribuídas em uma rede de área ampla (WAN). As estações de
trabalho podem gerenciar uma única LAN (ou prédio) e/ou o sistema inteiro com
todas as partes da LAN mantidas como única com banco de dados atual.
E. Suporte de rede padrão
1. Todos os NSC, Estações de Trabalho e Servidores devem ser capazes de se
conectar diretamente na rede Ethernet TCP/IP LAN/WAN, sem a necessidade de
gateways. Além disso, os NSCs, Estações de Trabalho e Servidores devem ser
capazes de se conectar a dispositivos padrões, disponíveis comercialmente, para
infraestrutura Ethernet, como roteadores, switches e hubs. Com este projeto, o
proprietário pode utilizar o investimento de uma rede existente ou nova, além
de cabeamento estruturado. Isso também permite a opção de manutenção da
LAN / WAN ser executada pelo proprietário do Departamento de Sistemas de
Informação, como todos os dispositivos que utilizam componentes TCP/IP
padrão.
F. Expansão do sistema
1. O sistema BAS deve ser escalável e expansível em todos os níveis do sistema
usando a mesma interface de software, e o mesmo nível de TCP/IP e
controladores de rede de campo. Plataformas que necessitam de substituição de
software da estação de trabalho ou de controladores de campo a fim de expandir
o sistema não serão aceitáveis.
2. Operação em Web deve ser suportada diretamente pelos NSCs, sem a
necessidade de software adicional.
pg. 33
3. O sistema deve ser capaz de usar programação gráfica (blocos) e/ou linhas de
linguagem de programação para os controladores de servidor de rede.
G. Suporte para sistemas de protocolos abertos
1. Todos os gerenciadores/servidores de rede devem suportar os protocolos
BACnet IP, BACnet MS/TP, KNX, LonWorks FTT-10, Modbus TCP, Modbus RTU
(RS-485 e RS-232) e Modbus ASCII nativamente.
2.2 Requisitos da estação de trabalho
A. Geral
1. A operação do sistema BAS será constituída por uma ou mais estações de
trabalho para configuração e programação completa, e uma ou mais estações
para operação baseada na web. Para este projeto, fornecer no mínimo acesso a
10 usuários simultâneos na Estação de Trabalho e/ou 2 usuários simultâneos
para acesso ao Servidor Principal.
2. O software de programação deve permitir a qualquer usuário, com permissão
adequada, criar e/ou modificar qualquer configuração nos
gerenciadores/servidores e/ou base de dados do Servidor Principal.
3. Todas as estações de trabalho devem ser computadores que operam sob o
sistema operacional Microsoft Windows. O software de aplicação deve ser capaz
de se comunicar com todos os Gerenciadores / Servidores de Rede e apresentar
gráficos coloridos e de alta resolução, alarmes e gráficos de tendência. Deve ser
configurável para todas as funções de coleta e apresentação de dados.
4. Utilização de no mínimo uma estação de trabalho na rede Ethernet. Nesta
configuração cliente / servidor, quaisquer alterações ou adições feitas a partir de
uma estação de trabalho irá aparecer automaticamente em todas as outras
estações de trabalho, uma vez que as alterações são realizadas para a base de
dados do Gerenciador / Servidor. Sistemas com uma base de dados central não
serão aceitáveis.
B. Requisitos do Servidor Principal e da Estação de Trabalho

1. O Servidor Principal deve atender os seguintes requisitos:
a. Processador
a) Mínimo: 2.0 GHz
b) Recomendado: 2.6 GHz ou superior
b. Memória
a) Mínimo: 4GB
b) Recomendado: 4GB ou superior
c. Sistema Operacional
a) Microsoft Windows 7 Pro 32-bit (Professional, Enterprise ou
Ultimate)
b) Microsoft Windows 7 Pro 64-bit (Professional, Enterprise ou
Ultimate)
c) Microsoft Windows 8.1 32-bit (Pro, Pro N, Enterprise ou
Enterprise N)
d) Microsoft Windows 8.1 64-bit (Pro, Pro N, Enterprise ou
Enterprise N)
e) Microsoft Windows Server 2008 R2 64-bit (Standard, Enterprise,
Datacenter, Web ou Itanium)
pg. 34
f) Microsoft Windows Server 2012 64-bit (Standard, Datacenter,

Essentials ou Foundation)
g) Microsoft Windows Server 2012 R2 64-bit (Standard, Datacenter,
d. 10/100MBPS Ethernet NIC
e. 250 GB hard disk
f. Software adicional necessário
a) Microsoft .Net 4.5
g. Licenças para todos os softwares
2. As Estações de Trabalho devem atender os seguintes requisitos:
a. Processador
a) Mínimo: 1.0 GHz
b. Memória
a) Mínimo: 2GB
c. Sistema Operacional
a) Microsoft Windows 7 32-bit (Professional, Enterprise ou
Ultimate)
b) Microsoft Windows 7 64-bit (Professional, Enterprise ou
Ultimate)
c) Microsoft Windows 8.1 32-bit (Pro, Pro N, Enterprise ou
Enterprise N)
d) Microsoft Windows 8.1 64-bit (Pro, Pro N, Enterprise ou
Enterprise N)
e) Microsoft Windows Server 2008 R2 64-bit (Standard, Enterprise,
Datacenter, Web ou Itanium)
f) Microsoft Windows Server 2012 64-bit (Standard, Datacenter,
g) Microsoft Windows Server 2012 R2 64-bit (Standard, Datacenter,
d. Porta serial, paralela, USB
e. 10/100MBPS Ethernet NIC
f. 20 GB hard disk
g. DVD drive
h. Alta resolução (mínimo 1280 x 1024), 17” flat monitor
i. Mouse óptico e teclado com função completa
j. Placa de áudio e caixas acústicas
k. Software adicional necessário
a) Microsoft .Net 4.5
l. Licensas para todos os softwares
C. Webstation
1. Qualquer usuário na rede pode acessar o sistema, usando os seguintes
softwares:
a. Internet Explorer 11
b. Mozilla Firefox
c. Google Chrome
pg. 35
D. Software da Estação de Trabalho de Administração e Programação

1. A arquitetura do sistema deve ser cliente-servidor, em que a Estação de Trabalho
deve funcionar como o cliente, enquanto os Gerenciadores/Servidores devem
funcionar como os servidores. O cliente é responsável pela apresentação de
dados e validação de entradas enquanto o servidor é responsável pela coleta e
envio de dados.
2. As funções da Estação de Trabalho devem incluir o monitoramento e a
programação de todos os Dispositivos de Campo (DDC). O monitoramento inclui
alarmes, elaboração de relatórios, telas gráficas, armazenamento de dados de
longo prazo, coleta automática de dados e ações de controle do operador como
cronograma e ajustes de valor nominal (setpoint).
3. A programação de Controladores de Campo (SDCU) deve ser capaz de ser feita
off-line ou on-line, a partir de qualquer Estação de Trabalho. Todas as
informações estarão disponíveis em telas gráficas ou em textos armazenados no
Gerenciador/Servidor (NSC). Telas gráficas deve conter efeitos de animação para
melhorar a apresentação dos dados, para alertar os operadores de problemas e
para facilitar a localização de informações em todo os Dispositivos de Campo
(DDC) do sistema. Todas as funções de operador devem ser selecionáveis através
de um mouse.
E. Interface de usuário:
1. O software da Estação de Trabalho BAS deve permitir a criação de uma interface
customizada e vinculada ao usuário que fazer logon em qualquer Estação de
Trabalho. Adicionalmente, deve ser possível a criação de espaços de trabalho
personalizados que podem ser atribuídos a grupos de usuários. Esta interface
deve suportar a criação de "hot-spots" que o usuário pode atribuir para ver /
editar qualquer objeto no sistema ou executar qualquer edição de objeto e
ferramenta de configuração contidas no software. Além disso, esta interface
deve ser habilitada a ser configurada para se tornar um "Desktop PC" de usuário
- com todos os links que o usuário precisa para executar outras aplicações. Em
conjunto com as capacidades de segurança de usuário do Windows, este recurso
irá permitir a administração das contas da estação de trabalho, que não só
limitarão as capacidades do usuário dentro do software BAS, mas também
restrições em ações no PC e na rede LAN/WAN. Isso pode ser usado para
garantir, por exemplo, que o usuário de uma estação de trabalho de
monitoramento de alarme não seja capaz de silenciar um alarme ativo no
visualizador e/ou não seja capaz de carregar um software no PC.
2. O sistema deve ser capaz de alterar automaticamente as unidades de medidas
(imperiais e métricas) apresentadas com base na localização da Estação de
Trabalho / Webstations.
3. O software principal e as Webstations devem obrigatoriamente ser em
Português, entretanto as Estações de Trabalho/Webstations devem ser
configuráveis para exibição em vários idiomas, incluindo inglês e espanhol. Os
vários idiomas não podem exigir software adicional na Estação de Trabalho e
deve ser selecionável dentro da referida Estação de Trabalho.
4. Webstations devem ter capacidade de redirecionamento automático para uma
conexão HTTPS, assegurando comunicações mais seguras.
5. Interfaces personalizadas estendidas da Estação de Trabalho às Webstations
para garantir experiências de usuário consistentes entre as interfaces de usuário.
pg. 36
6. Servidores e clientes devem ter a capacidade de ser localizados em diferentes

fusos horários, sincronizados através de servidor NTP.
F. Segurança de usuário
1. O software deve ser projetado de modo que cada usuário possa ter um nome
de usuário e senha exclusivos. Esta combinação nome de usuário / senha deve
ser combinado a um conjunto de recursos dentro do software, criado e editável
apenas por um administrador do sistema. Os conjuntos de capacidades devem
variar de visualização somente, reconhecer alarmes, ativar / desativar e alterar
os valores, programa e administrar. O sistema deve permitir que as
capacidades acima para ser aplicada de forma independente para cada classe
de objeto no sistema. O sistema deve permitir um mínimo de 256 usuários para
ser configurado por estação de trabalho. Além disso, o software deve permitir a
capacidade de adicionar / remover usuários baseados em Microsoft Domínios
de Segurança do Windows que permitem que o departamento de TI do cliente
para ajudar no acesso do usuário.
G.Configuração de interface
1. O software de estação de trabalho deve usar uma interface de estilo familiar do
Windows Explorer para o operador ou programador para ver e / ou editar
qualquer objeto (controlador, ponto, alarme, relatório, programação, etc), em
todo o sistema. Além disso, esta interface deve apresentar um "mapa da rede"
de todos os controladores e seus pontos associados, programas, gráficos,
alarmes e relatórios em uma forma fácil de entender a estrutura. Todos os
nomes de objetos devem ser alfanuméricos e usar a convenção do Windows
para nomes longos.
2. A interface de configuração deve também incluir suporte para o usuário definir
tipos de objetos. Estes tipos de objetos devem ser usados como blocos de
construção para a criação do banco de dados BAS. Devem ser criados forma os
tipos de objetos de base dentro do sistema de entrada, de saída, variáveis de
cadeia, setpoints, etc, algoritmos de alarmes, objetos de notificação de alarme,
relatórios, displays gráficos, cronogramas e programas. Grupos de usuários
definem os tipos de objeto que deve ser capaz de ser configurado como um
agregado predefinido de subsistemas e sistemas. A interface de configuração
deve apoiar copiar / colar e exportação / importação parte do banco de dados
para eficiência adicional. O sistema deve também manter um vínculo com
todos os objetos "filhos" criados. Se um usuário deseja fazer uma mudança
para um objeto pai, o software deve perguntar ao usuário se ele quer atualizar
todos os objetos filho com a mudança.
H. Displays gráficos
1. O sistema deve permitir a criação de usuário, cor telas gráficas para a
visualização de sistemas mecânicos e elétricos, ou esquemas de construção.
Estes gráficos devem conter informações do ponto do banco de dados,
incluindo todos os atributos associados com o ponto (unidades de engenharia,
etc.) Além disso os operadores devem ser capazes de comandar equipamentos
ou alterar setpoints de um gráfico com o uso do mouse.
2. Requisitos do subsistema gráfico a cores incluem:
a. É obrigatório que os gráficos sejam produzidos usando a tecnologia
Scalable Vector Graphics (SVG) para que não exista degradação da
imagem nos muitos tamanhos de telas disponíveis. As telas não devem
perder a resolução seja esta vista em um SmartPhone, Tablet ou em um
Video Wall. Além disso, o usuário deve ter a capacidade de importar. Gif,.
pg. 37
Png,. Bmp,. Jpeg,. Tif, e CAD, arquivos de imagem como o fundo de telas e
de camadas deve ser possível.
b. Deve ser possível para o usuário usar o JavaScript para personalizar o
comportamento de cada gráfico.
c. O editor deve usar tecnologia Scalable Vector Graphics (SVG).
d. Uma biblioteca de objetos animados, tais como dumpers, ventiladores,
bombas, botões, medidores, gráficos que podem ser “descarregados” em
um gráfico através do uso de uma configuração de software "wizard".
Esses objetos devem permitir que os operadores interagem com as telas
gráficas de uma forma que imita seus equivalentes mecânicos
encontrados no campo.
e. Usando o mouse, os operadores devem ser capazes de ajustar setpoints,
iniciar ou parar o equipamento, modificar os parâmetros de malha PID, ou
alterar os horários.
f. Mudanças de estado ou condição de alarme devem ser capazes de ser
destacado por objetos que mudam o local da tela, tamanho, cor, texto,
piscar ou mudar de uma tela para outra.
g. Capacidade de ligação de telas gráficas através de objetos definidos pelo
usuário, testes de alarme, ou o resultado de uma expressão matemática.
Os operadores devem ser capazes de mudar de um gráfico para outro,
selecionando um objeto com um mouse - sem a necessidade de menus.
h. Deve ser possível criar e salvar componentes gráficos e código JavaScript
em bibliotecas personalizadas reutilizáveis e transferíveis.
i. Os gráficos devem redimensionar com base em qualquer monitor ou
visualizar o dispositivo que está sendo usado.
j. Ser capaz de criar gráficos em camadas diferentes e podem ser movidos e
repetidos.
k. Ser capaz de criar gráficos em diferentes janelas que podem ser movidos e
/ ou referenciados. Por exemplo, a criação do menu gráfico dentro de um
painel e referenciá-lo em todas as páginas de gráficos, portanto, não
permitindo, assim, reconstruir um único local para as atualizações que são
empurrados a todas as páginas que fazem referência a ele.
3. Além disso, a parte de Editor de Gráficos da Engenharia de Software deve
fornecer os seguintes recursos:
a. Criar e salvar páginas.
b. Agrupar e desagrupar símbolos.
c. Modificar um símbolo existente.
d. Modificar uma página gráfica existente.
e. Girar e espelhar um símbolo.
f. Colocar um símbolo em uma página.
g. Colocar dados dinâmicos analógicos em formato decimal em uma página.
h. Colocar dados dinâmicos binários utilizando descritores do estado em uma
página.
i. Criar movimento através do uso de animação. Gif ou JavaScript.
j. Colocar indicação do modo de teste em uma página.
k. Colocar indicação modo manual em uma página.
l. Colocar links usando um símbolo fixo ou solto em uma página.
m. Links para outros gráficos.
n. Links para sites.
o. Links para notas.
pg. 38
p. Links para os horários.

q. Links para qualquer arquivo.Exe na estação de trabalho do operador.
r. Links para arquivos. Doc.
s. Atribuir uma cor de fundo.
t. Atribuir uma cor de primeiro plano.
u. Colocar indicadores de alarme em uma página.
v. Alterar símbolo / texto / valor de cor em função de uma variável
analógica.
w. Alterar uma cor símbolo / texto / valor em função de um estado binário.
x. Alterar símbolo / texto / valor em função de um estado binário.
I. Monitoramento automático
1. O software deve permitir a coleta automática de dados e relatórios a partir de
qualquer controlador ou NSC. A frequência de coleta de dados deve ser
configuráveis pelo usuário.
J. Gerenciamento de alarmes
1. O software deve ser capaz de aceitar alarmes diretamente do NSC ou
controladores, ou a geração de alarmes com base na avaliação dos dados de
controladores e comparando a limites ou equações condicionais configurados
através do software. Qualquer alarme (independentemente da sua origem)
será integrado no sistema global de gerenciamento de alarme e vai aparecer
em todos os relatórios de alarme padrão, estar disponível para reconhecimento
do operador, e tem a opção para a exibição de gráficos ou relatórios.
2. Recursos de gerenciamento de alarme deve incluir:
a. Um mínimo de 1000 níveis de notificação de alarme. Cada nível de
notificação irá estabelecer um conjunto único de parâmetros para o
controle de exibição de alarme, distribuição, reconhecimento, teclado
anunciação e manutenção de registros.
b. Registro automático na base de dados da mensagem de alarme, nome do
ponto, valor de ponto, dispositivo de origem, data e hora do alarme, nome
de usuário e tempo de reconhecimento, nome de usuário e tempo de
silêncio do alarme (reconhecimento suave)
c. Tocar um som audível no início de alarme ou voltar ao normal.
d. O envio de uma página de e-mail para ninguém especificamente referido a
ocorrência de um alarme. A capacidade de utilizar e-mail paginação de
alarmes deve ser uma característica padrão do software integrado com
interface do aplicativo de correio do sistema operacional (MAPI). Não há
interfaces de software especiais serão necessários e nenhum software de
cliente de e-mail deve estar em execução para que o e-mail a ser
distribuído.
e. Alarmes devem ser capazes de ser encaminhado para um usuário em
horários especificados pelo tipo de usuário e datas. Por exemplo, um
alarme de alta temperatura crítica pode ser configurado para ser
encaminhado para uma estação de trabalho para a manutenção durante o
horário normal de trabalho (durante o horário comercial nos dias de
semana) e para uma estação de trabalho central em todas as outras vezes.
f. Visualizador de alarme ativo deverá ser incluído e poderá ser personalizado
para cada tipo de usuário para ocultar ou exibir os atributos de alarme.
g. O visualizador de alarme ativo pode ser configurado de tal forma que um
operador deve digitar texto em uma entrada de alarme e / ou escolher a
pg. 39
partir de uma lista drop-down de ações do usuário para determinados

alarmes.
h. O visualizador de alarme ativo pode ser configurado de tal forma que um
operador deve digitar texto em uma entrada de alarme e / ou escolher a
partir de uma lista drop-down de causas para determinados alarmes. Isso
garante prestação de contas para a resposta a alarmes críticos.
i. O visualizador de alarme ativo pode ser configurado de tal forma que um
operador deve confirmar que toda a etapa de uma lista de verificação
tenha sido realizada antes de reconhecer o alarme.
j. O operador deve ter a capacidade de atribuir um alarme para outro usuário
do sistema.
K. Geração de relatórios
1. O servidor de relatórios deve ser capaz de processar grandes quantidades de
dados e produzir relatórios significativos para facilitar a análise e otimização de
cada instalação.
2. Os relatórios devem ser capazes de gerar e visualizar a partir da estação de
trabalho do operador e / ou Webstation, e / ou diretamente de um relatórios
de única interface web.
3. Uma biblioteca de relatórios predefinidos, automaticamente gerados solicitam
entrada dos usuários antes da geração dos mesmos, deverão estar disponíveis.
As propriedades e configurações feitas a estes relatórios devem ser possível
salvar como relatórios do painel, para que as configurações salvas possam ser
utilizadas no futuro.
4. Deve ser possível criar relatórios através de ferramentas padrão, como o
Microsoft Report Builder 2.0 ou Visual Studio, quando utilizado para relatórios
personalizados.
5. Os relatórios adicionais ou conjuntos de relatórios devem ser baixado,
transferível e importável
6. Todos os relatórios deverão ser capazes de serem configurados para ser
executado automaticamente ou ser gerado por demanda.
7. Cada relatório deve ser capaz de ser automaticamente enviado para um
destinatário, Excel e / ou Adobe PDF. Microsoft Word.
8. Os relatórios podem ser de qualquer comprimento e contêm todos os atributos
de ponto a partir de qualquer controlador da rede.
9. Funcionalidade de gerenciamento de imagem deve ser possível para permitir
que os administradores do sistema possam carregar facilmente novos logotipos
ou imagens para o sistema.
10. Deve ser possível executar outros programas executáveis sempre que um
relatório é iniciado.
11. A Geração de Relatórios pode ser ligada ao sistema de gerenciamento de
alarme, de modo que qualquer um dos relatórios configurados pode ser
exibidos em resposta a uma condição de alarme.
12. Relatórios fornecidos devem incluir no mínimo:
a. Atividades por Report Server
b. Atividades por relatório do usuário
c. Alarme Valor por categoria de relatório
d. Alarme Valor por Tipo de relatório
e. Alarmes por Server Relatório
f. Relatório de alarme atual
g. Relatório de alarme com maior prioridade
pg. 40
h. Erros do sistema por Report Server

i. Top Relatório de Actividades
j. Top Alarmes Relatório
k. Erros do sistema Top Assinalar
l. Tendência Log Relatório de Comparação
m. Usuário Logins Relatório
n. Usuários e Grupos Relatórios
13. Relatório de energia deve incluir no mínimo:
a. Relatório de Monitoramento de Energia Calendário x Consumo: fornecerá
um relatório interativo que mostra o consumo de energia em um ou vários
dias selecionados.
b. Relatório de Consumo de Monitoramento de Energia Breakdown: deve
fornecer um relatório sobre o consumo de energia discriminadas utilizando
sub-medição.
c. Relatório de Consumo de Monitoramento de Energia: Quer mostrar o
consumo de energia com um valor de destino especificado.
14. Requisitos de hardware Reports Server
a. Processador
a) Minimo: 2.0 GHz
b. Memória
a) Minimo: 6 GB
c. Hard Disk: 500 GB
15. Requisitos de Software Reports Server
a. Sistema operacional: Microsoft Windows Server 2008 R2 (64-bit)
b. SQL Versions:
a) Microsoft SQL Server 2008 R2 Express with Advanced Services (64-
bit)
b) Microsoft SQL Server 2008 R2 Standard (64-bit)
L. Agendamento
1. A partir da estação de trabalho ou webstation, deve ser possível configurar e
baixar programações para qualquer um dos controladores da rede.
2. Tempo de horários durante o dia deve ser em estilo calendário e visualiza em
ambos uma visão gráfica e tabular.
3. Horários deverão ser programáveis para um mínimo de um ano de
antecedência.
4. Para alterar a programação para um determinado dia, um usuário deve
simplesmente selecionar o dia e fazer as modificações desejadas.
5. Além disso, a partir das webstations do operador, cada cronograma aparecerá
na tela visível como todo o ano, mês, semana e dia. Um simples clique do
mouse deve permitir a alternância entre pontos de vista. Deve também ser
possível para se deslocar de um mês para o outro e visualizar ou alterar
qualquer dos tempos de programação.
6. Horários serão atribuídos aos controladores específicos e armazenados em sua
memória RAM local. Quaisquer alterações feitas na estação de trabalho serão
atualizadas automaticamente com o cronograma correspondente no
controlador.
pg. 41
7. Deve ser possível atribuir um cronograma tal que horários locais são
atualizados com base em mudanças na liderança.
8. Deve ser possível atribuir uma lista (s) de dias de eventos de exceção, datas,
intervalos de datas com uma programação.
9. Será possível ter visualizações combinadas mostrando o calendário e todas as
isenções priorizados em uma tela.
10. Deve acomodar um mínimo de 16 níveis de prioridade.
11. Os valores devem ser capazes de ser controlada diretamente a partir de uma
programação, sem a necessidade de um programa lógico especial.
M. Programador de meio ambiente
1. Programação no NSC deverá ser em formato de bloco gráfico ou formato de
programação de linha ou ambos.
2. O ambiente do programador vai incluir acesso a um super conjunto da mesma
linguagem de programação suportadas no SDCUs .
3. Dispositivos NSC apoiará tanto linguagem de programação script, bem como a
linguagem de programação do bloco de função gráfica . Para ambas as línguas,
o programador será capaz de configurar o software de aplicação para o
desenvolvimento de programas personalizados e escrever programas de
controle globais.
4. Deve ser possível salvar programas personalizados como bibliotecas para
reutilização em todo o sistema. Uma ferramenta assistente devem estar
disponíveis para os programas de carregamento de um arquivo de biblioteca no
editor do programa.
5. Deve ser possível para ver ao vivo de programação gráfica e em tempo real a
partir da estação de trabalho.
6. O sistema deve ser capaz de criar "modelos de ligação" que permite ao usuário
ligar vários pontos para vários objetos de uma só vez.
7. Termos-chave devem aparecer quando se digita (IntelliType) .
8. As candidaturas devem ser capazes de se atribuir diferentes prioridades e
tempos de ciclo para uma execução priorizada de função diferente.
9. O sistema deve ser capaz de criar objetos que permitem objetos comuns, tais
como medidores de energia, unidades de CSC, etc, para ser integrado no
sistema com ações simples de importação, sem a necessidade de programação
ou configuração complicada de setups.
N. Salvamento / Recarga
1. O software de estação de trabalho deve ter um aplicativo para salvar e
restaurar NSC e arquivos de memória do controlador de campo.
2. Para o NSC, esta aplicação não deve ser limitada a salvar e recarregar um
controlador ao todo - também deve ser capaz de salvar / recarregar objetos
individuais no controlador. Isso permite que a depuração off-line de programas
de controle, por exemplo, e depois apenas recarrega as informações
modificadas.
pg. 42
O. Auditoria
1. O software de estação de trabalho deve registrar automaticamente e marcar o
horário para cada operação que um usuário executa em uma estação de
trabalho, do início e término de sessão de uma estação de trabalho para alterar
um valor de ponto, a modificação de um programa, ativar / desativar um
objeto, vendo um display gráfico, a execução de um relatório, modificação de
um cronograma, etc
2. Deve ser possível visualizar um histórico de alarmes, as ações do usuário e
comandos para qualquer objeto do sistema individualmente ou pelo menos os
últimos 5.000 registros de todos os eventos para todo o sistema de estação de
trabalho.
3. Deve ser possível salvar visualizações personalizadas filtradas de informações
de eventos que podem ser visualizados e configuráveis em Workstation.
P. Falhas tolerantes no Enterprise Server Operation (Top level NSC)
1. Uma falha de um único componente do sistema não deve fazer com que todo o
sistema falhe. Todos os usuários do sistema devem ser informados de qualquer
falha de um componente detectável através de um evento de alarme. Os
usuários do sistema não devem ser desconectados, como resultado de uma
falha do sistema ou transição.
Q. Software operador baseado em Web
1. Gerais:
a. Operação do dia-a-dia do sistema deve ser acessível através de uma
interface de navegador web padrão, permitindo que técnicos e
operadores possam ver qualquer parte do sistema de qualquer lugar na
rede.
b. O sistema deve ser capaz de ser acessado no site através de um ambiente
móvel dispositivo com, no mínimo, acesso a substituir e visualização dos
valores do sistema.
2. Displays Gráficos:
a. As interfaces baseadas em browser devem compartilhar as mesmas telas
gráficas das estações de trabalho de administração e programação,
apresentando dados dinâmicos em layouts de site, planos de chão, e
equipamentos gráficos. Os gráficos do navegador devem suportar
comandos para alterar setpoints, ativar / desativar o equipamento e
iniciar / parar o equipamento.
b. Através da interface do navegador, os operadores devem ser capazes de
navegar através de todo o sistema, e alterar o valor ou o estado de
qualquer ponto em qualquer controlador. As alterações entram em vigor
imediatamente para o controlador, com um registro da mudança
armazenado no banco de dados do sistema.
3. Gerenciamento de alarmes
a. Sistemas que requerem software adicional para ser instalado em um PC
para ver o webstation, não serão considerados.
b. Através da interface do navegador, um visualizador de alarme online
idêntico ao visualizador de alarme da Administração e estação de trabalho
de programação deve ser apresentado, se a senha do usuário permitir. Os
usuários devem ser capazes de receber alarmes, silenciar alarmes e
reconhecer alarmes através de um browser. Se desejar, o texto específico
do operador deve ser capaz de ser adicionado ao registro de alarme antes
pg. 43
de reconhecimento, anexo devem ser visíveis, e listas de verificação de

alarme devem estar disponíveis.
R. Grupos e horários
1. Através da interface do navegador, os operadores devem ser capazes de ver os
grupos pré-definidos de pontos, com os seus valores atualizados
automaticamente.
2. Através da interface do navegador, os operadores devem ser capazes de mudar
horários - mudança de iniciar e parar, adicionar novos tempos com uma
programação e modificar calendários.
S. Conta de usuários e auditoria
1. As mesmas contas de usuários devem ser utilizadas para a interface do
navegador e para as estações de trabalho do operador. Os operadores não
devem ser obrigados a memorizar várias senhas.
2. Todos os comandos e atividade do usuário através da interface do navegador
devem ser registrados no log de atividades do sistema, que pode ser mais tarde
pesquisado e recuperado por usuário, data ou ambos.
T. Web Services
1. O sistema instalado será capaz de utilizar os serviços da Internet para
"consumir" a informação na rede Server / Controllers (NCCC) com outros produtos e
sistemas. Incapacidade de realizar serviços web dentro dos NSC será inaceitável.
a. Deve ser capaz de "consumir" os dados no sistema via SOAP e
webservices em REST.
b. Deve ser capaz de "servir" e "consumir" dados de outros
sistemas, como:
a) EcoStruxure Power Monitoring Expert
b) Sistema de iluminação KNX
2.3 Controladores de servidor de rede (NSCs)
A. Controladores de Roteador de rede deve combinar as duas funções de roteamento da rede,

funções de controle e funções de servidores em uma única unidade.
B. O BACnet NSC deve ser classificado como um dispositivo BACnet "nativo”, que suporte o
perfil de controle de redes BACnet Server (B- AC). Controladores que suportam um perfil
menor, como B-SA não são aceitáveis. NSC deverão ser testados e certificados pelo
Laboratório de Ensaios BACnet (BTL), como controladores de servidor BACnet rede (B- AC).
C. O controlador de servidor de rede deve fornecer a interface entre a LAN ou WAN e os
dispositivos de controle de campo, e fornecem funções de controle de supervisão globais ao
longo dos dispositivos de controle conectados aos NRS.
D. Devem também ser responsável por monitorar e controlar os seus próprios equipamentos
de climatização, como uma AHU ou caldeira.
E. Devem também conter gráficos, tendências, gráficos de tendências, visualização de alarme,
e outros objetos de apresentação semelhantes que podem ser servidos para as estações de
trabalho ou interfaces baseadas na web. Um número suficiente de NSC deve ser fornecido
para atender plenamente os requisitos desta especificação e lista de pontos.
F. Deve ser capaz de executar programas de controle de aplicativos para fornecer:
1. Funções de calendário
2. Agendamento
3. Trending
4. Monitoramento de alarme e roteamento
pg. 44
5. A sincronização de tempo por meio de um site na Internet, incluindo a

sincronização automática
6. Integração nativa de LonWorks dados do controlador e os dados do
controlador Modbus ou dados de controlador BACnet e dados do controlador
Modbus
7. Funções de gerenciamento de rede para todos os dispositivos baseados
LonWorks
G. Especificação do hardware
1. Memória:
a. O sistema operacional do controlador, programas, aplicativos, e todas as
outras partes do banco de dados de configuração, devem ser armazenados
em não-volátil, memória FLASH. Servidores / Controladores devem conter
memória suficiente para o aplicativo atual, além de registro histórico
necessário, além de um mínimo de 20% de memória livre adicional.
2. Cada NRC deve fornecer o seguinte hardware on-board para a comunicação:
a. Uma porta Ethernet 10/100BT para comunicação com estações de
trabalho, outros CRN e para a Internet
b. Duas portas RS-485 para comunicação com bus BACnet MSTP ou Modbus
(software configurável)
c. Uma porta TP / FT para a comunicação com dispositivos LonWorks.
d. Uma porta USB
e. Duas portas USB host
3. O NSC deve ter medidas não maiores do que 100W x 125H x 75D mm (3.94W x
4.92H x 2.95D in).
H. Expansão modular:
1. O sistema deve empregar um projeto de E / S modular para permitir a
expansão. Capacidade de entrada e saída deve ser fornecido através de
módulos plug-ins de vários tipos. Deve ser possível combinar módulos de E / S,
como desejado para atender aos requisitos de I / O para aplicações de controle
individuais.
2. Deve ser capaz de (hot-swap) os módulos de E / S preservando o sistema on-
line sem qualquer intervenção no software; endereçamento e configuração
serão automáticos
I. Manipulação das saídas:
1. Todas as saídas digitais devem, eventualmente, incluir três posições
interruptores manuais de substituição para permitir a seleção do ON, OFF ou
estado de saída AUTO. Estes switches devem ser construídos dentro da unidade
e fornecer feedback para o controlador de modo que a posição da chave de
correção pode ser obtida através de software. Além disso, cada saída analógica
deve ser equipada com um potenciômetro de substituição para permitir o
ajuste manual do sinal de saída analógico sobre a sua gama completa, quando
o interruptor de acionamento manual de 3 posições é colocado na posição ON.
J. Entradas Temperatura Universal
1. Todas as entradas universais diretamente ligadas ao NSC viam expansão
modular devem ser capazes de usar os seguintes termistores para uso no
sistema sem quaisquer conversores externos necessários.
1) 10 kohm Type I
2) 10 kohm Type II
3) 10 kohm Type III
4) 10 kohm Type IV
pg. 45
5) Linearized 10 kohm Type V

6) Linearized 10 kohm
7) 1.8 kohm
8) 1 kohm
9) 20 kohm
10) 2.2 kohm
2. Além do acima, o sistema deve ser capaz de utilizar os sensores abaixo RTD, no
entanto, não é necessário que todas as entradas universais forem compatíveis
com eles.
1) PT100
2) PT1000
3) Ni1000
K. Estado local, Indicador de Lâmpadas:
1. O NSC deve incluir no mínimo indicação LED de status da CPU, estado Ethernet
LAN, e status de barramento de campo. Para cada entrada ou saída, fornecer
LED indicação do valor do ponto (On / Off). A indicação LED deve apoiar
configuração de software para definir se a iluminação do diodo emissor de luz
corresponde a ON ou OFF ou se a cor quando iluminado é vermelho ou verde.
L. Real Time Clock (RTC):
1. Cada NSC incluirá, um relógio de tempo real alimentado por bateria, com
precisão de 10 segundos por dia. A RTC deve fornecer o seguinte: hora do dia,
dia, mês, ano e dia da semana. Cada NSC permitirá o seu próprio fuso horário
UTC. Quando o fuso horário é definido, o NSC também irá armazenar os
momentos apropriados para o horário de verão.
M. Fonte de alimentação:
1. A fonte de alimentação de 24 VCC para os NSC deverá fornecer 30 watts de
potência disponível para o NSC e módulos de IO associados. O sistema deverá
suportar o uso de mais de uma fonte de alimentação, se forem necessários
módulos com muito consumo.
2. A fonte de alimentação, NSC, e módulos I / O deve conectar a energia e
comunicação através da base terminal separado permitindo a facilidade de
reposição e nenhuma fiação separada ou solta.
N. Reinício automático após falha de energia:
1. Após a restauração da energia, depois de uma queda de energia, o NSC deve
automaticamente e sem intervenção humana atualizar todas as funções
monitoradas, retomar a operação com base no atual, sincronizar tempo e
status, e implementar estratégias de arranque especiais, conforme exigido.
O.Bateria de backup:
1. O NSC incluirá uma bateria on-board para fazer backup de memória RAM do
controlador. A bateria deve fornecer backup acumulado de todas as funções de
memória RAM e relógio por pelo menos 30 dias. No caso de uma falha de
energia, o NSC deve primeiro tentar reiniciar a partir da memória RAM. Se a
memória é corrompida ou inutilizável, o NSC deverá reiniciar-se a partir de seu
programa aplicativo armazenado em sua memória FLASH.
P. Especificações de software
1. O sistema operacional do controlador, programas, aplicativos, e todas as outras
partes do banco de dados de configuração, tais como gráficos, tendências,
alarmes, visualizações, etc, devem ser armazenados em não-volátil, memória
FLASH. Não haverá restrições quanto ao tipo de programas, aplicativos no
sistema. Cada NSC devem ser capazes de processamento paralelo, a execução
pg. 46
de todos os programas de controle simultaneamente. Qualquer programa pode

afetar o funcionamento de qualquer outro programa. Cada programa terá o
acesso completo de todas as instalações de I / O do processador. Esta execução
da função de controle não deve ser interrompida devido a comunicação normal
do usuário, incluindo o interrogatório, a entrada do programa, saída do
programa para armazenamento, etc
2. Cada NSC deverá ter uma capacidade disponível de 4 GB de memória. Isso deve
representar 2 GB para aplicação e dados históricos e 2 GB dedicado para
armazenamento de backup.
Q.Linguagem de programação de usuário:
1. O software de aplicação deve ser programável pelo usuário. Isto inclui todas as
estratégias, seqüências de operação, algoritmos de controle, parâmetros e
valores nominais. O programa fonte deve ser um texto baseado em roteiro
estruturado ou bloco de função gráfica baseada e totalmente programável pelo
usuário. A linguagem deve ser estruturada de forma a permitir a configuração
de programas de controle, horários, alarmes, relatórios, telecomunicações,
monitores locais, cálculos matemáticos e histórias. Os usuários devem ser
capazes de colocar comentários em qualquer lugar no corpo de programas em
bloco ou de script ou função.
2. Controladores de servidor de rede que usam um método programa "enlatado"
não serão aceitos.
R. Software de controle:
1. O NSC deve ter a capacidade de executar os seguintes algoritmos de controle
pré-testadas:
a. Controle Proporcional, Integral mais Derivativo (PID)
b. Dois Controle de Posição
c. Filtro digital
d. Ratio Calculator
e. Equipamentos de Proteção Ciclismo
S. Funções matemáticas:
1. Cada controlador deve ser capaz de executar funções matemáticas básicas (+, -,
*, /), quadrados, raízes quadradas, exponenciais, logaritmos, declarações de
lógica booleana, ou combinações de ambos. Os controladores devem ser
capazes de executar instruções complexas lógicas, incluindo operadores, tais
como >, <, = e, ou, ou exclusivo, etc Estes devem ser capazes de ser usado nas
mesmas equações com os operadores matemáticos até cinco parênteses.
T. NSC devem ter a capacidade de realizar qualquer um ou todos os seguintes procedimentos
de gestão de energia:
1. Agendamento de Horário do Dia
2. Calendário Baseado Agendamento
3. Programação de férias
4. Substituições Agenda temporárias
5. Iniciar Optimal
6. Optimal Parar
7. Controle noturno
8. Entalpia alternância (economizador)
9. Limitador de Demanda
10. Temperatura Compensada
11. Rastreamento CFM
12. Aquecimento / resfriamento intertravamento
pg. 47
13. Quente/Fria Redefinir

14. Redefinir Água Quente
15. Condensador Repor água
16. Seqüenciamento de chiller
U. Histórico de Log:
1. Cada controlador NSC devem ser capazes de LOCALMENTE registrar qualquer
entrada, saída, valor calculado ou outra variável de sistema, quer em intervalos
de tempo definidos pelo usuário que variam de 1 segundo para 1.440 minutos ,
ou com base em uma mudança de valor configurável de usuário. Um mínimo de
1.000 registros, com um mínimo de 100.000 registros armazenados. Cada
registro pode gravar tanto o instantâneo, média, valor mínimo ou máximo do
ponto. Os dados registrados serão baixados para um nível superior NSC
arquivamento de longo prazo com base em intervalos de tempo definidos pelo
usuário, ou de comando manual.
2. Para tendência estendida registrando um mínimo de 1500, as tendências
devem ser capazes de no mínimo de 600 mil registros.
3. Gestão de uma substituição do medidor de energia para garantir a exatidão dos
dados de registro do medidor deve ser possível no NSC .
4. Cada ponto de entrada e saída de hardware, hospedado dentro do NSC e
módulos I / O em anexo, deve ter tendências automaticamente, sem a
necessidade de criação manual, e cada um desses registros devem registrar
valores com base em uma mudança de valor e armazenar pelo menos 500
amostras de tendência antes de substituir a amostra mais antiga com novos
dados.
5. A apresentação dos dados registrados será construído nas capacidades de
servidor do NSC a apresentação pode ser em tempo pré-determinados em
formatos de lista ou em formato de gráfico com as cores da caneta totalmente
configurável, pesos, escalas e períodos de tempo.
V. Gerenciamento de alarme:
1. Para cada ponto do sistema, alarmes podem ser criados com base nos limites
de alta / baixa ou em relação a outros valores de pontos. Todos os alarmes
serão testados a cada varredura do NSC e podem resultar na exibição de uma
ou mais mensagens de alarme ou de relatórios.
2. Não há limite para o número de alarmes, que podem ser criados por qualquer
ponto
3. Os alarmes podem ser configurados para ser geradas com base em um estado
de sistema único ou múltiplo condições do sistema.
4. Alarmes serão gerados com base em uma avaliação das condições de alarme e
pode ser apresentado ao usuário em uma ordem totalmente configurável, por
prioridade, pelo tempo, por categoria, etc. Essas exibições de alarmes
configuráveis serão apresentadas a um usuário após o login no sistema,
independentemente de o login é feito em uma estação de trabalho ou um
Webstation.
5. O sistema de gerenciamento de alarme deve apoiar a capacidade de criar e
selecionar causa e a ação a serem associados a um evento de alarme. As listas
de verificação serão também possíveis, a fim de apresentar a um operador de
um modo sugerido de solução de problemas. Ao reconhecer um alarme, deve
ser possível atribuí-la a um usuário do sistema de tal forma que o usuário é
notificado da cessão e é feito o responsável pela resolução de alarme.
pg. 48
6. Alarmes devem ser capazes de ser encaminhado para qualquer estação de

trabalho BACnet que está de acordo com o perfil do dispositivo B - OWS e
utiliza o protocolo BACnet / IP.
W. Servidor de web incorporado
1. Cada NSC deve ter a capacidade de servir as páginas da web que contenham a
mesma informação que está disponível a partir de estação de trabalho. O
desenvolvimento das telas para realizar não devem exigir que qualquer
trabalho de engenharia adicional sobre que o necessário para mostrá-los no
próprio WorkStation.
2.4 BACnet controlador de campo e BACnet SDCUs
A. Rede
1. Rede IP: Todos os dispositivos que se conectam à WAN devem ser capazes de
operar a 10 megabits por segundo ou 100 megabits por segundo.
2. IP para Field Bus dispositivo roteador
a. Um controlador de servidor de rede deve ser usada para fornecer essa
funcionalidade.
b. Estes dispositivos devem ser configurável localmente com cabo
crossover IP e configurável através da rede IP.
c. A configuração de roteamento deve ser apenas os pacotes de dados a
partir dos dispositivos de barramento de campo que precisam viajar
sobre o nível de IP da arquitetura.
B. Fiação e terminação dos controladores de campo
1. A arquitetura dos componentes deverá usar um conceito de bus ou em cadeia,
sem t-shirt, canhotos (stubs), ou topologia livre.
2. Cada barramento de campo deve ter um resistor de terminação em ambas as
extremidades de cada segmento.
3. O barramento de campo deve apoiar o uso de comunicações sem fio.
C. Repetidores
1. Os repetidores são necessários para conectar dois segmentos.
2. Os repetidores devem ser instalados em um gabinete.
D. Dispositivos de campo
1. Requerimentos gerais
a. Os dispositivos devem ter uma luz indicando que eles estão
alimentados.
b. Os dispositivos devem ser alimentados localmente. Os dispositivos de
conexão de alimentação (energia é fornecida a partir de uma fonte
central através do cabo de bus de campo) não são aceitáveis.
c. Os programas de aplicação devem ser armazenados de uma maneira
que a perda de energia não resulta em uma perda do programa de
aplicação ou ajustes de parâmetros de configuração. (Backup de bateria,
memória flash, etc)
E. Controlador do servidor de rede (NSCs)
a. Se NSC tem incorporado I / O, todos os requisitos para a I / O, que são
descritos em Controladores Avançados de Aplicação é aplicável.
b. Apóia a exportação de dados para NSC de outros fornecedores que
suportam o compartilhamento de dados, leia serviço propriedade.
pg. 49
c. Apóia a exportação de dados usando Change of Valor ( COV) iniciação à

NSC de outros fornecedores que suportam a assinatura de dados,
usando o conceito de COV .
d. Apóia a exportação de dados para qualquer BACnet OWS que suporta o
compartilhamento de dados, serviço de propriedade ler.
e. Apóia a exportação de dados usando Change of Valor ( COV) iniciação a
qualquer OWS BACnet que suporta a assinatura de dados utilizando o
conceito COV .
f. Prestará apoio log tendência para todos os dispositivos no barramento
de campo. Eles devem fornecer memória suficiente para armazenar até
300 amostras para cada variável pela seqüência de controle.
g. Devem apoiar a exportação de dados de registro de tendência para
qualquer OWS BACnet que suporta o serviço BACnet alcance de leitura
de tendências.
h. Prestará apoio calendário para todos os dispositivos no barramento de
campo.
i. Apóia a edição de entradas programar o tempo de qualquer OWS
BACnet que suporta o serviço BACnet para a escrita de parâmetros de
agendamento tempo.
j. Deve fornecer iniciação mensagem de alarme para todos os alarmes
condições de qualquer um dos dispositivos de barramento de campo.
k. Emitirá mensagens de alarme para qualquer OWS BACnet que suporta o
serviço BACnet para receber mensagens de alarme e está configurado
para ser um destinatário da notificação.
l. Apóia o reconhecimento do alarme de qualquer OWS BACnet que
suporta o serviço BACnet para a execução de reconhecimento de
alarme / evento.
m. Apóia o controle da propriedade de serviço e atribuição de valor ou
estado para analógico e objetos binários de qualquer OWS BACnet que
suporte escrito para o de bens de serviços e propriedade valor do
analógico e objetos binários.
n. Apóia a recepção e resposta aos comandos de sincronização de tempo a
partir de qualquer dispositivo que suporte o serviço BACnet para iniciar
comandos de sincronização de tempo.
o. Apoiará a "Quem é?" E "Eu sou". Serviço BACnet.
p. Apoiará a "" Quem tem? "E" eu tenho". Serviço BACnet.
q. Apóia Backup e Restauração comandos de qualquer OWS BACnet que
suporta o início de comandos de backup e restauração.
r. Devem ser certificadas BTL.
F. Controladores de aplicação avançada (B-AAC)
1. As principais características de um B-AAC são:
a. Eles têm entrada física e circuitos de saída para a conexão de
dispositivos analógicos de entrada, dispositivos de entrada binários,
dispositivos de saída de pulso analógico e dispositivos de saída binários.
O número e tipo de dispositivos de entrada e de saída suportados irão
variar dependendo do modelo.
b. Eles podem ou não fornecer suporte para dispositivos de entrada e
saída adicionais para além do número de circuitos que são fornecidos na
placa de circuito básico. Suporte para I / O adicional será prestada por
pg. 50
placas de circuitos adicionais que se conectam fisicamente com o

controlador básico.
c. Se os horários locais estão integrados, o B- AAC apóia a edição de
entradas de programação de tempo de qualquer OWS BACnet que
suporta o serviço BACnet para a escrita de parâmetros de agendamento
tempo.
d. Se o registro de tendência local é incorporado, o B- AAC apóia a
exportação de dados de registro de tendência para qualquer OWS
BACnet que suporta o serviço BACnet alcance de leitura de tendências.
e. Se iniciação mensagem de alarme local é incorporada, o B- AAC deve:
1) Entregar mensagens de alarme para qualquer OWS BACnet que
suporta o serviço BACnet para receber mensagens de alarme e
está configurado para ser um destinatário fora a mensagem de
alarme.
2) Reconhecimento do alarme e apoio de qualquer BACnet OWS que
suporta o serviço BACnet para a execução de alarme /
reconhecimento evento.
f. Apoia a leitura de dados analógicos e binários de qualquer BACnet OWS
ou controlador que suporta o serviço BACnet para a leitura de dados.
g. Apoia o controle da propriedade de serviço e atribuição de valor ou
estado para objetos analógicos e binários de qualquer BACnet OWS que
oferece suporte à escrita para o de bens de serviços e propriedade valor
do analógico e objetos binários.
h. Apoia a recepção e resposta aos comandos de sincronização de tempo a
partir de um controlador BACnet.
i. Apoiará a "Quem é" e "Eu sou". Serviços BACnet.
j. Apoiará a "quem tem" e "eu tenho." Serviços BACnet.
2. Circuitos de entrada analógica
a. A resolução do chip A / D não deve ser maior do que 0,01 Volts por
incremento. Para um conversor A / D, que tem uma gama de medição
de 0 a 10 VDC e é de 10 bits, a resolução é de 10/1024 ou 0,00976 Volts
por incremento.
b. Para sensores não-fluxo, a lógica de controle deve fornecer apoio para a
utilização de uma calibração de deslocamento de modo a que o valor
medido em bruto é adicionado a (+ / -) desvio para criar um valor de
calibração para ser utilizada pela lógica de controle e relatar a estação
de trabalho do operador (OWS).
c. Para sensores de fluxo, a lógica de controle deve fornecer suporte para
o uso de um ganho ajustável e um ajustável compensar tal que um
conceito calibração de dois pontos pode ser executado (ambos um valor
baixo e um valor de alto são ajustados para combinar valores
determinados por um instrumento de calibração).
d. Para os sensores não-lineares, como termistores e sensores de fluxo do
B-AAC deve fornecer suporte de software para a linearização do sinal de
entrada.
3. Circuitos de entrada binária
a. Sensores de contato seco devem ligar ao controlador com dois fios.
b. Uma fonte de alimentação externa no circuito do sensor não será
exigida.
4. Circuito de entrada pulsada
pg. 51
a. Sensores de entrada de pulso devem ligar ao controlador com dois fios.

b. Uma fonte de alimentação externa no circuito do sensor não será
exigida.
c. O circuito de entrada de pulso deve ser capaz de processar até 20 pulsos
por segundo.
5. Circuito de entrada analógica (True Analog)
a. Os comandos lógicos devem ser processados por um digital para
analógico (D / A). O sinal de controle de 0% a 100% deve ser escalável
para o intervalo de saída completo que deve ser 0 a 10 VCC, de 4 a 20
mA ou 0 a 20 mA ou para intervalos dentro da faixa de saída total
(Exemplo: 0 a 100% cria 3-6 VDC, onde o intervalo de saída total é de 0 a
10 VDC).
b. A resolução do D / A chip não deverá ser superior a 0,04 Volts por
incremento ou 0,08 miliamperes por incremento.
6. Circuito de saída binária
a. Polo único ou único relés com dupla saída com suporte para até 230
VAC e uma corrente máxima de 2 amps.
b. Tensão de abastecimento ou triacs alimentação externa com suporte
para até 30 VAC e 0,5 ampères e 24VAC
7. Execução de programa
a. Malhas de controle de processos devem operar em paralelo e não em
sequência.
b. A taxa de amostragem para uma malha de controle de processo deve
ser ajustável e apoia uma taxa de amostragem mínima de 1 segundo.
c. A taxa de amostragem para variáveis de processo deve ser ajustável e
apoia uma taxa de amostragem mínima de 1 segundo.
d. A taxa de amostragem para atualizações algoritmo deve ser ajustável e
apoia uma taxa de amostragem mínima de 1 segundo.
e. O pedido deve ter a capacidade de determinar se um ciclo de energia
para o controlador ocorreu e o programador aplicação deve ser capaz
de utilizar a indicação de um ciclo de energia para modificar a sequência
de controle imediatamente após um ciclo de energia.
8. Interface local
a. O controlador deve suportar a conexão de um dispositivo de interface
portátil, como um computador portátil ou dispositivo de mão. A
capacidade de executar quaisquer outros além da visualização de dados
essas tarefas devem ser protegidas por senha. Através desta interface
local, o operador deve ser capaz de:
1) Ajustar os parâmetros de aplicação.
2) Executar o controle manual de pontos de entrada e saída.
3) Ver dados dinâmica.
G.Aplicação de dispositivos específicos
1. Dispositivos específicos de aplicação devem ter função de aplicativos
configuráveis para correção.
2. Se o aplicativo pode ser alterado por instrumento programável, o dispositivo é
um controlador de aplicação avançada e não um dispositivo específico do
aplicativo.
3. Dispositivos específicos de aplicação devem ser certificados BTL.
pg. 52

Orientativo BMS

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Orientativo BMS

Enviado por

Direitos autorais:

Formatos disponíveis

EcoStruxure for Healthcare

HOSPITAL UNIMED BELÉM

O objetivo deste documento é fornecer dados e estabelecer

Este documento foi produzido em conjunto com a coordenação

A implementação deste projeto será realizada em três fases.

A primeira, contemplada neste documento, reunirá em um único

A segunda, acrescentará ao sistema:

A terceira e última fase, reunirá todos os dados coletados em

EcoStruxure for Healthcare

PLANTA BAIXA – Para localização espacial

 HVAC (Chillers, Fancoils, Fancoletes, K7, VRF, Splits, Caldeiras)

 Interface com painéis de incêndio

 Taxas de ocupação e utilização

 Consumos anuais e mensais de Energia, Água, Gases Médicos etc.

 Em um dos Monitores de 40” mostrar o diagrama unifilar de elétrica

 Por se tratar de um hospital o controle deve ser executado de maneira criteriosa

Centrais de água gelada

Em posse destas informações será possível avaliar o desempenho individual de cada

Para realizar este cálculo, precisamos ter em mãos algumas informações:

 O fluxo de volume de água no evaporador (Sensor de Vazão)

 A densidade da água na temperatura média (temp de entrada + temp de saída) / 2

Com estas informações podemos calcular a capacidade de refrigeração de um Chiller.

A capacidade específica de calor (Cp) é medida em unidades de kJ por kg por Kelvin.

c. Splits, K7 ou aparelhos de janela com controle remoto

Caso exista refrigeração executada por VRFs oferecer formas de comunicação

A maior parte do parque de UPS instalados possui comunicação ou modbus ou SNMP.

1. Mais do que simplesmente buscar dados dos displays de medidores, o sistema de

Deve possuir um diagrama unifilar

Trazer dados recomendados pelo fabricante:

Conhecendo os horários de maior carga nos transformadores, o usuário pode planejar

Rateio e alocação de custos:

• Permitir criar grupos de consumidores e realizar o “faturamento” de cada um

 Exportação de dados padrão. Permitir exportar dados para arquivos Excel.

• EN50160. Relatório apresentando uma análise da qualidade de energia com

• IEEE519. Utiliza o padrão IEEE519 para avaliar o comportamento de

• IEC61000-4-30. Utiliza a norma IEC61000-4-30 para avaliar a qualidade de

• Relatório de qualidade de energia. Analisa os registros de variação de tensão

• Cinco relatórios que permitem analisar os dados de diversas formas,

• Acompanhamento da vida útil de disjuntores (se integrados a disjuntores

• Atividade dos geradores.

Os Dashboards (painéis) são um meio de visualizar dados instantâneos e históricos de

O sistema conta com objetos para composição de gráficos de barras verticais e

O sistema permite criar “medidores virtuais”, compostos pela soma de medidores

5. Módulo notificador de eventos (Event Notification Module).

6. Integração com dispositivos de terceiros.

Essa integração auxilia na manutenção preventiva e corretiva dos equipamentos.

Em todo o complexo do HUB há muitos reservatórios de água potável, totalizando uma

 Nível das caixas (78%)

 Nível (Sensor Ultrassônico, sem contato com a água)

10. Interface com sistema de incêndio

11. Monitoramento de Gases

O fornecimento de gases ocorre em um único local e contará com um controlador IP para

EcoStruxure for Healthcare

Premissas para a contratação

1.2 Qualificação dos proponentes e pré-qualificação

A. Todos os proponentes devem ser EcoXperts certificados da Schneider Electric.

14. Um checklist de toda a especificação do sistema com a conformidade dos

1.3 Escopo de trabalho

A. A Contratada deverá fornecer e instalar o EcoStruxure de forma completa, incluindo todo o

1.4 Descrição do software

2.1 Arquitetura do sistema

2.2 Requisitos da estação de trabalho

B. Requisitos do Servidor Principal e da Estação de Trabalho