Você está na página 1de 16

PONTOS CRÍTICOS DO PROJETO

1) Banco de dados

Situação atual

São 4 unidades instaladas, o banco de dados é composto de duas tabelas


principais (listagem de pessoas e log de acessos) e tabelas auxiliares. A
listagem de pessoas contém todos os funcionários, terceiros e visitantes que
usam (ou usaram) o sistema e a tabela de log contém os dados de todas as
passagens de cartões registradas. Na tabela abaixo temos um resumo do
tamanho de cada um dos bancos.

Lista Média Média


de Log de Acesso Acesso
pessoa Acessos s Mensai
s (histórico) Diários s
25.000.0 330.00
Limeira/Americana 80.000 00 11.000 0
25.000.0 350.00
Fábrica B 68.000 00 11.667 0
15.000.0 250.00
Mucuri 52.000 00 8.333 0
15.000.0 250.00
Imperatriz 52.000 00 8.333 0

A tabela de pessoas é usada para selecionar qual pessoa tem acesso a qual
leitora, a análise do desempenho atual mostrou um desempenho satisfatório
sendo que o incremento de tempo em relação ao incremento de pessoas se
mostrou uma tendência linear, com um pequeno aumento de delay entre a
implantação e a situação atual, via de regra as consultas nestas tabelas tem
tempo menor que 1 segundo.
Já a tabela de Log tem tido um crescimento bastante grande, já que cada um
dos usuários gera pelo menos 3 acessos ao dia (entrada, restaurante, saída) o
que multiplicado pelo número de pessoas gera um número expressivo de
registros, que tem de ser preservados por ao menos 5 anos. O acesso a esta
tabela é feito basicamente de duas formas, consulta a trajeto de usuários, que
tem uma resposta em torno de 1 segundo e relatórios mensais (hht,
horas/empresa/pedido, etc) que tem resposta um pouco mais lenta, mas bem
satisfatória tendo em vista que são procedimento realizados somente uma vez
por mês.
Situação proposta

A Suzano, pela requisição de cotação, solicita que a base passe a ser


centralizada, para isto teremos de migrar as bases de dados para uma única e
importar os dados das bases Old Fibria, estimando que que a Fibria tenha um
afluxo de pessoas 50% maior (maior número de unidades e colaboradores) e
portando uma geração de dados também 50% (mais pessoas e mais pontos de
acesso), teremos como resultado a tabela abaixo:

Lista Log de Média


de Acessos Acess Média
pesso (histórico os Acesso
as ) Diários Mensais
25.000.0
Limeira/Americana 80.000 00 11.000 330.000
25.000.0
Fábrica B 68.000 00 11.667 350.000
15.000.0
Mucuri 52.000 00 8.333 250.000
15.000.0
Imperatriz 52.000 00 8.333 250.000
226.00 80.000.0 1.180.0
Banco único Kaper 0 00 39.333 00
Unidades Fibria 1.770.0
Inícial 16.000 0 59.000 00
Unidades Fibria 339.00 1.770.0
Consolidado 0 0 59.000 00
565.00 80.000.0 2.950.0
Banco Consolidado 0 00 98.333 00

Log Para
Log de Média Média Relatórios
Lista de Acessos Acessos Acesso Mensais
pessoas (histórico) Diários Mensais (Hot Data) Log 5 anos
25.000.00
Limeira/Americana 80.000 0 11.000 330.000 0 0
25.000.00
Fábrica B 68.000 0 11.667 350.000 0 0
15.000.00
Mucuri 52.000 0 8.333 250.000 0 0
15.000.00
Imperatriz 52.000 0 8.333 250.000 0 0
80.000.00 1.180.00
Banco único Kaper 226.000 0 39.333 0 0 0
1.770.00
Unidades Fibria Inícial 16.000 0 59.000 0 0 0
Unidades Fibria 339.000 0 59.000 1.770.00 0 0
Consolidado 0
80.000.00 2.950.00
Banco Consolidado 565.000 0 98.333 0 11.800.000 177.000.000
Teremos dois problemas, a tabela de pessoas ficará muito grande e
eventualmente poderão haver atrasos e o problema principal será a tabela de
log que deve crescer a taxa de 100.000 linhas por dia, isto significa 3 milhões
de linhas ao mês, logo em menos de um ano a base de dados unificada já seria
muito maior que quaisquer das bases atuais, o que fatalmente implicaria em
lentidão do sistema e eventual inoperância.

Como solução para isto propomos separar as tabelas críticas, a de pessoas


seria separada em parte cadastral (acesso pontual pelas máquinas/sistemas de
cadastro) e a parte de acesso (leitoras, unidades, perfil) que é acessada de
forma contínua pelos bloqueios, sendo que seria dividida em n unidades para
que o sistema tenha uma performance igual ou superior a atual.
Já a tabela de logs teria os dados duplicados, uma tabela global para registros
de deslocamentos/consultas de pessoas e uma tabela menor somente com os
últimos quatro meses para consultas pesadas, desta forma teríamos uma
performance igual ou superior a atual. Esquematicamente:
Quanto ao desempenho esperamos aproximadamente 20000 usuários ao dia,
se considerarmos que 70% trabalha em horário comercial, teríamos
aproximadamente 14000 pessoas saindo numa faixa curta de tempo, se formos
considerar que este período será de aproximadamente 10 minutos, teremos
aproximadamente 1400 acessos por minuto ou 23 por segundo. Como cada
passagem dispara processos internos (controle de jornada, registros, etc)
podemos estimar que no pior caso isto vai gerar 2300 Batch Requests / SEC,
ou seja, será um sistema grande, mas nada exagerado.
2) Transferência de dados entre pontos de acesso e base de dados.

A transferência das passagens é um dos processos mais críticos de todo o


sistema, além de controlarmos quem entra aonde e quando, também temos de
registar isto, para controlar horas trabalhadas de terceiros, tentativas de
entradas indevidas, ponto de funcionários (onde a legislação permite), etc. Para
isto a Kaper criou um sistema de certificação de transmissão (diagrama a
seguir), a informação ao ser gerada é duplicada, e transmitida ao próximo nível
de tal forma que a informação sempre exista em ao menos duas cópias até
atingir a base de dados, neste momento o servidor informa a remota que a
gravação foi feita e existe o descarte da cópia extra. Devido a este mecanismo
é virtualmente impossível a perda de informação no sistema Kaper, a
única possibilidade seria uma falha catastrófica no hardware de coleta e
mesmo assim como a transmissão sempre é imediata a perda se resumiria a
uma passagem.

Do mesmo modo, como a informação é duplicada ao ser coletada, em caso de


interrupção na comunicação, a remota retém os dados e tão logo a
comunicação seja restabelecida, os transmitira de forma automática em
poucos segundos, sem que seja necessária nenhuma intervenção de
operadores, garantindo o funcionamento eficaz da controladora em modo
off-line.

3) Atualização da base de dados da remota

Quantos aos usuários autorizados (lista branca) os sistemas de controle de


acesso se dividem em duas categorias, sistemas estáticos e sistemas
dinâmicos, nos sistemas estáticos temos uma listagem de usuários
autorizados que é alterada poucas vezes, define-se quais usuários são e via
de regra isto não é mais mudado; já nos sistemas dinâmicos a cada momento
a definição de quem pode entrar aonde muda, um bom exemplo disto seria o
controle de jornada, se um colaborador se excedeu nas horas trabalhadas,
temos de ineditamente bloquear sua entrada assim que o mesmo sair da
empresa.
Os sistemas dinâmicos podem ser de duas formas, ou com base distribuída ou
sistema com consulta direta, na base distribuída temos um gerenciamento para
que as mudanças sejam rapidamente transferidas aos pontos de acesso, já no
com consulta direta a cada passagem do usuário é feita uma pesquisa na base
de dados central para verificar se o usuário pode ou não entrar.
As necessidades da Suzano implicam claramente em um sistema de controle
de acesso dinâmico, ou seja, os pontos de acesso vão ter de estar conectados
logicamente a base de dados tal forma a refletir dinamicamente as permissões
de acesso de cada usuário.
Já quanto ao tipo de sistema dinâmico, é claro que pelas distâncias físicas
envolvidas e o número de pessoas controladas não é possível deixar toda a
lógica de liberação para um ente central, isto acarretaria delays altos para
liberação e um risco concreto de paralisarmos todas as unidades do grupo.
Portanto o que a Kaper propõe é um sistema de controle de acesso com
inteligência distribuída, teremos um controlador central que analisara cada
mudança do cadastro e replicará para as remotas de forma automática e
rápida. Basicamente é o sistema que já temos funcionando há mais de 10
anos na Suzano atuando de forma unificada em todas as unidades.
Os diagramas a seguir ilustram a solução proposta e seu modo de
funcionamento, podemos ver que cada um dos processos é analisado, gerando
(ou não) um pequeno frame com as modificações necessárias, estes frames
são depois transferidos para os pontos de acesso. Se por acaso houver uma
falha de comunicação com uma das remotas estas modificações serão
armazenadas até que esta retorne a se comunicar e caso este tempo se
estenda muito então será gerada uma nova base local para que fique
atualizada:
Podemos observar pelos diagramas que se o sistema estiver online ele é
continuamente atualizado, e quando estiver off-line ele vai trabalha com as
informações locais até que a comunicação seja reestabelecida. Todo este
processo é feito de forma automática não sendo necessários comandos ou
intervenções de pessoas, tanto para atualizar sua listagem de pessoas quanto
para descarregar as passagens que porventura houveram durante a
interrupção de comunicação.

4) A remota Kaper

Um dos pontos mais críticos de qualquer sistema de controle de acesso é a


diversidade de equipamentos, cada um dos diversos fabricantes adota uma
estratégia diferente de conectividade e operação, temos equipamentos que são
conectados por conexões (contato seco), outros são acessadas por uma porta
de comunicação serial (RS232 ou RS485), ou por uma porta Wiegand.
Algumas são simplesmente comandadas (abrir, fechar, passar, etc), já outras
tem uma base própria de cartões, atualizada por blocos ou individualmente.
Para se construir um sistema de controle de acesso com esta diversidade de
equipamentos, precisamos de uma diversidade de interfaces. Porém, se a cada
equipamento novo precisássemos atualizar a base de dados central ou até
mesmo as telas de interface com o usuário isto tornaria o sistema, como um
todo, extremamente frágil, já que a todo momento estaríamos sujeitos a bugs
no kernel do sistema de controle de acesso, além, evidentemente, dos custos
envolvidos, já que a cada mudança teríamos uma rotina de testes envolvendo
uma grande parte do sistema.
Para contornar este problema, a Kaper criou sua remota para fazer a conexão
com os diversos hardwares, desta maneira, logicamente, a remota funciona
como uma classe equipamento, fornecendo interface e propriedades padrões
para o sistema de controle de acesso. Portanto se quisermos implantar um
novo equipamento basta implantarmos a mudança na “classe” remota, sem
alterar em nada a base de dados, interfaces com usuários, diminuindo os
custos, facilitando os testes e principalmente aumentando a confiabilidade do
sistema.
Para que isto funcione é necessário um processo para troca de firmware da
remota. Existe uma rotina central que envia a nova versão para a remota e
após com um script é feita a troca e a remota reinicializa já com o novo
software. Desta maneira, é possível se fazer todo este processo a distância,
sem abertura de equipamento e nem troca de chips ou procedimentos
similares. Também existe um módulo no sistema para permitir a configuração
da remota a distância, desta forma, quase toda a manutenção da remota é feita
a distância sem o deslocamento de pessoas.
conceito: remota como classe.

fluxograma troca de firmware.

Esta arquitetura de software permite que o Sistema de Controle de Acesso da


Kaper seja compatível com praticamente todos os equipamentos de todos os
fabricantes, fazendo com a implantação e homologação de novos periféricos
seja simples e rápido.
* a implantação da interface com
novos hardwares/fabricantes depende
do fornecimento de documentação
por parte do fabricante.

Fisicamente a remota Kaper pode ser usada de duas maneiras, remota física,
onde há uma cpu exclusiva para a remota e modo virtual, onde uma ou mais
remotas são hospedas virtualmente em um computador. No modo físico
podemos ter até 8 entradas seriais (RS232 ou RS485 ou Wiegand), 8 portas
lógicas de entradas e 8 portas de saída, desta forma podemos ligar até 8
cancelas ou portas ou duas catracas. Já no modo virtual podemos ter até 4
entradas seriais, 8 portas de entradas e 8 portas de saída por remota, e como
podemos até 4 remotas hospedadas por máquina virtual (em teoria o limite é
bem maior, mas preferimos definir em 4 pelo risco da perda de funcionamento
de muitos equipamentos em caso de falha), nos permite controlar até 16 portas
ou cancelas ou ainda 4 catracas, ou combinação destas capacidades,
esquematicamente teríamos as seguintes opções:
Além dos equipamentos de controle de acesso a remota Kaper permite a
interligação de outros sistemas de segurança, assim podemos conjugar o
acesso a CFTV conjugando câmeras, ou sistema de detecção de incêndio para
liberação automática de rotas de fuga em caso de emergência, outros sistema
de controle de acesso para liberação dupla e até mesmo sistemas industriais,
podendo, por exemplo enviar um sinal ao sistema de ar condicionado indicado
a presença (ou não) de pessoas em uma determinada área.

Você também pode gostar