Integração de estacionamento
Integração de Gestão de Estacionamento
Integração de gestão de estacionamento para edifícios: ocupação, estado das barreiras, orientação e ligações entre sistemas, sem fornecer barreiras nem equipamento de estacionamento.
Âmbito: integração, não equipamento de estacionamento
A gestão de estacionamento, neste contexto, significa ligar um sistema de estacionamento existente ou de terceiros à plataforma do edifício. Não fornecemos barreiras, máquinas de bilhetes, terminais de pagamento, câmaras ANPR nem sensores de lugares. O fornecedor do sistema de estacionamento continua responsável pelo seu equipamento, pelas transações e pela garantia. O nosso papel é trazer a ocupação, o estado das barreiras, os eventos de entrada e saída e as falhas de equipamento para a visão operacional do edifício e, em seguida, ligá-los à iluminação, à ventilação, ao controlo de acesso e ao reporte. Essa fronteira mantém as responsabilidades claras e permite ao cliente manter o sistema de estacionamento que já adquiriu. Quando se especifica um novo sistema, podemos definir os requisitos de interface. A lista de interfaces é acordada antes de o fornecedor de estacionamento e a equipa do edifício iniciarem os trabalhos. Uma lista de interfaces escrita é também a proteção mais clara contra uma reclamação tardia de que a integração estava incluída no pacote de outra entidade. Essa clareza é o que torna suportável uma futura mudança de fornecedor de estacionamento, e deve refletir-se nos desenhos, na lista de pontos e no contrato de manutenção.
- Integramos sistemas de estacionamento existentes ou de terceiros
- Barreiras, máquinas de bilhetes e câmaras continuam com o fornecedor de estacionamento
- Os requisitos de interface podem ser definidos antes da aquisição
- Fronteiras de responsabilidade escritas no âmbito
Dados e interfaces
Os sistemas de estacionamento expõem dados de formas diferentes. As instalações mais antigas disponibilizam contactos livres de tensão para abertura da barreira, sinal de cheio ou alarme. Os sistemas mais recentes oferecem uma API de software, uma exportação de base de dados ou um gateway Modbus ou BACnet. A integração deve começar por uma lista de dados: o que é necessário, com que frequência e quem é responsável por cada ponto. As contagens de ocupação, as contagens por nível, os eventos de entrada e saída, o estado do pagamento e os códigos de falha são habituais. A sincronização horária é mais importante do que parece: um evento de entrada desfasado dois minutos do CCTV torna a análise de incidentes mais difícil. Cada ponto precisa de um nome, uma unidade, um indicador de qualidade e uma origem documentada. A lista de dados deve distinguir o estado em tempo real dos registos históricos, porque os dois chegam normalmente por vias diferentes, com latências diferentes e regras de retenção diferentes. Quando um fornecedor não documenta a sua interface, a negociação pertence ao período anterior ao contrato, não ao período posterior à primeira falha.
- Lista de dados acordada antes do início dos trabalhos de interface
- API, exportação de base de dados, Modbus, BACnet ou contactos livres de tensão
- Sincronização horária com o CCTV e os registos de acesso
- Cada ponto tem nome, unidade, indicador de qualidade e origem
Contagem de ocupação e orientação
Quando as contagens são fiáveis, a plataforma pode alimentar a orientação: sinais de lugares disponíveis, indicadores de nível, ecrãs de zona e vistas na aplicação. A lógica de orientação deve incluir histerese, para que um sinal não oscile entre cheio e disponível no limiar, e uma alternativa de recurso quando as contagens ficam desatualizadas. O estado dos lugares de VE pode ser apresentado quando os pontos de carregamento o comunicam. A utilização histórica sustenta decisões sobre atribuição, política de preços e acesso fora de horas. A plataforma pode comparar padrões de dias úteis e de fim de semana, identificar zonas persistentemente cheias e mostrar quanto tempo os veículos permanecem. São informações operacionais, não um substituto do sistema de receitas do operador de estacionamento. Um ecrã de orientação que promete um lugar que não consegue verificar é pior do que nenhum ecrã, porque os condutores deixam de confiar no sistema ao segundo erro de percurso. As contagens desatualizadas devem ser substituídas por uma mensagem neutra, não pelo último número conhecido. As contagens devem ser calibradas contra um levantamento manual no primeiro dia de funcionamento e novamente após quaisquer trabalhos nos sensores.
- Sinais de lugares disponíveis e indicadores de nível
- Histerese para evitar oscilação nos limiares
- Estado dos lugares de VE quando os pontos de carregamento o comunicam
- Tendências de utilização por zona e faixa horária
Iluminação, ventilação e controlo de CO
Os eventos de estacionamento tornam-se úteis quando se ligam ao resto do edifício. A entrada de um veículo num nível subterrâneo pode desencadear a cena de iluminação e o estágio de ventilação dessa zona. Uma falha de barreira pode gerar um alarme de instalações e indicar ao operador a câmara mais próxima. Um evento de saída pode libertar o registo de acesso associado. A ventilação deve seguir os dados de CO e de ocupação em vez de um temporizador fixo, com velocidades de ventilador escalonadas e um período de purga definido. O controlo escalonado típico utiliza limiares de CO na ordem dos 20 a 30 ppm para o primeiro estágio e um nível de alarme mais elevado acima de 50 ppm, mas os valores reais devem decorrer do projeto de ventilação do parque e dos requisitos locais. O controlo de incêndio e de fumo permanece no sistema de incêndio; a integração do estacionamento não deve atrasar nem sobrepor-se a uma sequência de segurança de vida.
- Eventos de entrada acionam a iluminação e a ventilação da zona
- Falhas de barreira encaminhadas para instalações e CCTV
- CO e ocupação comandam os estágios de ventilação
- O controlo de incêndio e de fumo fica fora da sequência do BAS
Fronteiras de acesso, carregamento de VE e pagamento
O acesso e o pagamento são fronteiras que têm de ser traçadas cedo. O sistema de estacionamento é responsável pelos bilhetes, tarifas, validações e pagamento; a plataforma do edifício pode receber estados e eventos para correlação, mas não deve tornar-se o sistema de transações. Quando a mesma credencial abre a porta do átrio e uma barreira de estacionamento, o sistema de controlo de acesso e o sistema de estacionamento precisam de uma relação definida, incluindo o que acontece quando um deles está offline. O carregamento de VE acrescenta uma segunda relação comercial: o operador dos pontos de carregamento é responsável pelas sessões e pela faturação, enquanto a plataforma do edifício pode limitar a procura do local ou deslocar o carregamento para os períodos de geração. Cada fronteira deve identificar o sistema de referência, o sentido dos dados e o comportamento de recurso. A ambiguidade nestas fronteiras é normalmente descoberta por um condutor na barreira, que é o local menos conveniente para a resolver.
- O sistema de estacionamento continua a ser o sistema de transações
- Relação de credenciais definida entre acesso e estacionamento
- Sessões de VE e faturação continuam com o operador dos pontos de carregamento
- Sistema de referência e recurso identificados para cada fronteira
Reporte e operação
Os relatórios de estacionamento devem responder a questões operacionais: quão cheia ficou cada zona, quando, durante quanto tempo e com que frequência a orientação estava errada? A plataforma pode registar tendências de ocupação, contagens de entrada e saída, falhas de barreira e indisponibilidade de equipamento. Pode reconciliar as contagens com os totais de transações do operador de estacionamento quando a interface o permite, mas a reconciliação é uma verificação, não um sistema de faturação. Os alarmes devem ser agrupados por equipamento e localização, com uma via clara para o fornecedor de estacionamento no caso de falhas fora do âmbito da integração. Uma revisão mensal da utilização e das falhas é normalmente mais valiosa do que um painel em tempo real que ninguém observa. A revisão deve também testar a lógica de orientação face às chegadas reais, porque uma contagem exata à meia-noite pode ainda estar errada no pico da manhã. As tendências devem ser conservadas tempo suficiente para comparar estações, e não apenas semanas.
- Tendências de ocupação e permanência por zona
- Falhas de barreira e indisponibilidade de equipamento registadas
- Reconciliação apenas quando a interface o permite
- Falhas fora do âmbito encaminhadas para o fornecedor de estacionamento
Entrega, testes e fronteiras com fornecedores
A entrega começa com um levantamento de interfaces e um plano de testes. Cada ponto é comprovado contra o sistema de estacionamento, incluindo valores normais, desconexão, reinício e dados desatualizados. Os sinais de orientação são verificados no limiar, não apenas a meio da gama. A ligação à ventilação é testada com sinais de CO simulados e com o modo de incêndio, porque essas duas condições não podem entrar em conflito. A entrega inclui a lista de dados, o mapa de pontos, a documentação da API ou dos registos, o encaminhamento de alarmes e os contactos de escalonamento de ambos os fornecedores. Vale a pena agendar um teste conjunto com o fornecedor de estacionamento, uma vez que a maioria dos problemas de integração são problemas de responsabilidade e não de protocolo. O contrato de suporte deve indicar quem responde em primeiro lugar quando falha uma barreira, um contador ou um gateway, e o que faz a equipa do edifício enquanto o fornecedor está a caminho.
- Levantamento de interfaces e plano de testes conjuntos acordados
- Todos os pontos comprovados, incluindo desconexão e dados desatualizados
- Ventilação testada com CO e com o modo de incêndio
- Contactos de escalonamento e primeira resposta identificados
Funções de integração de estacionamento e verificações de falha
14 rows| Função | Sistema de origem | Interface típica | Função da plataforma | Falha a verificar |
|---|---|---|---|---|
| Ocupação de lugares e de zonas | Sensores ou contadores de estacionamento | API, Modbus, contacto seco | Tendência, orientação e reporte | Deriva do contador após um reinício |
| Estado da barreira | Controlador da barreira | Contacto seco ou API | Monitorizar e gerar alarmes de falha | Estado preso em aberto ou fechado |
| Eventos de entrada e saída | Sistema de estacionamento | API ou exportação de base de dados | Referência cruzada com CCTV e acessos | Hora do evento desfasada do vídeo |
| Estado do pagamento e dos bilhetes | Sistema de estacionamento | API | Apenas estado; sem transações | Pressuposto de que a plataforma processa pagamentos |
| Sinais de disponibilidade | Controlador dos sinais | API ou relé | Executar a lógica de orientação | Oscilação do sinal no limiar |
| Estado dos lugares de VE | Sistema de pontos de carregamento | API ou Modbus | Apresentar disponibilidade | Lugar ocupado comunicado como livre |
| Falhas de equipamento | Sistema do fornecedor de estacionamento | API ou contacto seco | Encaminhar alarmes para o fornecedor responsável | Alarme sem responsável |
| Eventos ANPR | Sistema de estacionamento | API | Apenas correlação e registo | Dados de matrícula conservados sem regra |
| Ligação à iluminação | BAS | E/S locais ou barramento de campo | Cenas de zona à entrada e à saída | Luzes acesas após a última saída |
| Ligação à ventilação e ao CO | Sensores de CO e BAS | E/S locais ou Modbus | Ventiladores escalonados e purga | Estágio bloqueado ou purga desativada |
| Correlação de acessos | Sistema de controlo de acesso | API ou exportação de eventos | Ligar eventos de veículo e de credencial | Credencial válida após a falha da barreira |
| Reporte de utilização | Todas as origens de estacionamento | Modelo de dados da plataforma | Tendência por zona e faixa horária | Relatório baseado em contagens desatualizadas |
| Sincronização horária | Sistema de estacionamento e BAS | Hora de rede ou protocolo | Reconstrução coerente de eventos | Deriva do relógio após uma atualização do fornecedor |
| Escalonamento para o fornecedor | Ambos os fornecedores | Contrato de suporte | Encaminhar falhas para a equipa correta | Ambas as partes recusam a chamada |
Imagens do projeto
3 images
Perguntas frequentes
01Fornecem barreiras ou máquinas de bilhetes?
Não. Integramos e monitorizamos. As barreiras, máquinas de bilhetes, terminais de pagamento e câmaras ANPR são fornecidos e apoiados pelo especialista em estacionamento, o que mantém a responsabilidade pelo equipamento e a garantia numa única parte. Isso também significa que o cliente pode mudar de fornecedor de estacionamento mais tarde sem substituir a plataforma do edifício, desde que a interface continue disponível.
02Podem integrar o nosso sistema de estacionamento existente?
Depende da interface que expõe. Os sistemas com API, exportação de base de dados, Modbus ou contactos secos são normalmente viáveis. Comece por um levantamento de interfaces e uma lista de dados antes de assumir o âmbito. Os sistemas mais antigos podem necessitar de um gateway ou de uma pequena interface de hardware, e esse custo deve ser conhecido antes de a proposta ser fixada.
03A plataforma pode processar pagamentos?
Não. O pagamento e as transações permanecem no sistema de estacionamento ou no seu prestador de pagamentos. A plataforma lê apenas o estado para monitorização e reconciliação. Manter as transações fora da plataforma do edifício reduz também o âmbito de segurança e de auditoria, o que é uma vantagem e não uma limitação.
04O estacionamento pode comandar a iluminação e a ventilação?
Sim. A entrada de veículos, a ocupação da zona ou a concentração de CO podem desencadear cenas de iluminação e estágios de ventilação. A lógica deve ser acordada com o projeto elétrico e com os requisitos de ventilação do parque. O modo de incêndio prevalece sobre qualquer sequência normal, e os dois devem ser testados em conjunto e não separadamente.
05A aplicação pode mostrar lugares livres?
Sim, quando o sistema de estacionamento fornece contagens de zona fiáveis. A orientação precisa de histerese e de um recurso definido quando as contagens ficam desatualizadas, para que o ecrã não prometa um lugar que não consegue verificar. Uma mensagem neutra é melhor do que um número errado apresentado com confiança, e o operador deve poder ver quando a contagem foi atualizada pela última vez.
06O ANPR está incluído?
Não fornecemos câmaras. Quando o sistema de estacionamento expõe eventos de reconhecimento através de uma API, a plataforma pode recebê-los para correlação de entradas e saídas e conservação de registos. As regras de retenção, acesso e privacidade dos dados de matrícula pertencem ao operador de estacionamento e à política de dados do edifício, não apenas à integração.
07Vários locais podem ser geridos em conjunto?
Sim. Cada local mantém o seu sistema de estacionamento e o seu controlo local, enquanto a plataforma proporciona monitorização central, reporte e encaminhamento de alarmes. O modelo de dados deve ser consistente entre locais desde o início. O reporte central só é útil se o mesmo ponto significar o mesmo em todos os locais, pelo que as regras de nomenclatura e de contagem pertencem à primeira fase.
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.