IBMS · Âmbito
Âmbito do IBMS — uma matriz de subsistemas, não uma lista de desejos
Um método prático para definir o âmbito do IBMS: uma matriz de subsistemas, profundidade de integração realista, exclusões e critérios de aceitação.
Resposta rápida
O âmbito do IBMS define-se através de uma matriz de subsistemas: para cada sistema, indique se é apenas monitorizado, controlado, incluído em interbloqueios entre sistemas ou apenas objeto de reporte. Os sistemas de segurança de pessoas e de segurança patrimonial permanecem habitualmente sob o seu próprio controlo, com o IBMS a supervisionar estados e eventos em vez de emitir comandos.
O âmbito é uma matriz, não uma lista
Uma lista de subsistemas indica o que está ligado. Uma matriz indica o que cada ligação pode fazer. Utilize linhas para os sistemas e colunas para monitorização, controlo, tratamento de alarmes, interbloqueio entre sistemas e reporte. Acrescente colunas para o responsável pela interface e para o teste de aceitação. A matriz revela lacunas antes de estas se tornarem trabalhos adicionais: um sistema marcado para controlo mas sem interface de escrita, ou um interbloqueio que depende de um ponto que ninguém fornece. Dá também ao operador uma imagem realista do que a plataforma fará e não fará. Uma matriz sem coluna de responsável é um diagrama de intenções. Mantenha a coluna do teste de aceitação visível nas revisões de projeto; transforma uma promessa num entregável.
Profundidade realista por subsistema
O AVAC suporta normalmente monitorização e controlo completos. A iluminação pode suportar cenas e horários, mas nem todos os grupos de luminárias justificam controlo individual. Os contadores de energia são apenas monitorizados, com a profundidade de reporte definida pelo contador e pelo gateway. O controlo de acesso pode partilhar eventos e permissões, enquanto o sistema de acesso mantém a sua própria lógica de decisão. O sistema de incêndio é apenas monitorizado quanto a estado e eventos; os comandos permanecem no sistema de incêndio. Elevadores, estacionamento e quartos de hotel variam muito. A profundidade correta é a que o operador utilizará efetivamente, não a máxima que o protocolo permite. O controlo dos quartos de hotel pode incluir cenas e limites de energia, enquanto o PMS do hotel mantém o seu próprio fluxo de trabalho. Cada decisão de profundidade deve ser justificada por um cenário operacional, não por uma lista de capacidades do protocolo.
O que deixar de fora
Exclua tudo o que não possa ser suportado após a entrega. Isso inclui controladores obsoletos sem interface documentada, portais de fornecedores que exigem uma conta pessoal e sistemas cuja única via de integração contorna os seus limites de segurança. Os comandos de segurança de pessoas devem permanecer no próprio sistema de segurança. Evite integrar um subsistema apenas para apresentar um valor num painel de controlo; a interface, o gateway e o esforço de manutenção sobreviverão à novidade. Uma lista de exclusões clara protege o projeto tanto como uma lista de inclusões clara. Cada exclusão precisa de uma razão e de uma consequência, para que o cliente a possa aceitar com conhecimento de causa. Se um subsistema não tiver uma interface estável, um processo manual documentado é frequentemente a resposta honesta.
Redigir a declaração de âmbito
Transforme a matriz numa declaração de âmbito com quatro partes: inclusões, exclusões, responsabilidades de interface e testes de aceitação. Indique o protocolo, o responsável pelo gateway, a base de contagem de pontos e a propriedade dos dados. Declare o que acontece quando uma interface está indisponível. Defina o teste que comprova cada linha e exija o resultado no dossiê de entrega. Reveja a declaração em cada fase de projeto, porque o âmbito cresce silenciosamente com as questões levantadas em obra. O documento deve ser suficientemente curto para ser lido numa reunião e suficientemente específico para ser orçamentado. Utilize os mesmos termos dos documentos de concurso, para que o âmbito possa ser comparado linha a linha. Quando uma questão alterar o âmbito, registe a alteração e o seu custo antes de prosseguir.
Profundidade típica de integração IBMS por subsistema
7 rows| Subsistema | Profundidade típica | Fronteira |
|---|---|---|
| HVAC | Monitorização e controlo | As sequências permanecem nos controladores DDC |
| Iluminação | Cenas, horários e estado | A iluminação de emergência permanece no seu próprio sistema |
| Medição de energia | Monitorização e reporte | Exatidão do contador e responsabilidade pelo gateway |
| Controlo de acesso | Eventos e permissões | As decisões de acesso permanecem no sistema de acesso |
| CCTV | Eventos e fluxos selecionados | Regras de privacidade e retenção |
| Alarme de incêndio | Apenas estado e eventos | Os comandos permanecem no sistema de incêndio |
| Elevadores e estacionamento | Estado, alarmes e disponibilidade | Interface do fornecedor e limites de segurança |
Imagens do projeto
3 images
Perguntas frequentes
01O IBMS deve controlar o sistema de incêndio?
Não. O sistema de incêndio e os restantes sistemas de segurança de pessoas mantêm o seu próprio controlo dedicado. O IBMS pode monitorizar estados e eventos e apresentá-los juntamente com os outros alarmes.
02Quantos subsistemas deve integrar um IBMS?
Não existe um número-alvo. Integre os sistemas que suportam uma decisão que o operador toma efetivamente; deixe os restantes de fora até surgir um caso de uso real.
03Podemos acrescentar um subsistema mais tarde?
Sim, se o modelo de dados, a nomenclatura e a rede tiverem sido concebidos para isso. Adaptar posteriormente um subsistema não documentado é muito mais difícil do que acrescentar um com uma interface estável.
04Quem é responsável pelo gateway?
Deve haver uma única parte responsável. A declaração de âmbito deve indicar quem fornece, configura, testa e mantém o gateway, incluindo atualizações de firmware e unidades sobressalentes.
05O que prova que o âmbito está completo?
Uma matriz assinada, com um resultado de teste de aceitação para cada linha, e uma lista de exclusões acordada com o cliente e o operador.
Próximo passo
Traga-nos o edifício.
Diga-nos o tipo de edifício, os sistemas abrangidos e o resultado pretendido. Indicaremos o caminho mais curto para um sistema funcional.