Objeto e Descritivo Geral

1. Objeto e Descritivo Geral 1.1. Fornecimento de sistema informatizado para Central de Monitoramento de atividades e eventos diversos, compreendendo os seguintes componentes: Sistema de Central de Monitoramento; Sistema de Integração de Telefonia; Sistema de Análise de Conteúdo de Vídeo; Ambiente de Desenvolvimento, Homologação e Treinamento; Serviços de Consultoria; Serviços de Treinamento e Transferência de Tecnologia; Serviços de Suporte e Manutenção. 1.2. O Sistema de Central Monitoramento deverá dar suporte operacional e estratégico ao monitoramento de ocorrências imprevistas ou planejadas até a sua conclusão, por meio de workflows associados a procedimentos de resposta; de análise estratégica de dados associados; e pela gestão de ativos e de pessoal, possibilitando: 1.2.1. Visualização e Monitoramento de ocorrências; 1.2.2. Cadastro e Monitoramento dos Procedimentos de Resposta; 1.2.3. Geração de Alertas, Mensagens; 1.2.4. Intercâmbio de informações; 1.2.5. Integração com sensores, câmeras de vídeo e outras fontes de dados; 1.2.6. Monitoramento e endereçamento de mídias sociais; 1.2.7. Gestão de ativos e pessoal. 1.3. Deve suportar qualquer número de estações de operação cliente, limitado apenas pelo hardware e pela largura de banda de comunicação. 1.4. Deve ser multi tenant, possibilitando o trabalho em conjunto de múltiplos órgãos e permitindo hierarquização de centrais rodando sistema idêntico ou integração com sistemas similares. Permitindo ainda a implantação dos seguintes ambientes operacionais, localizados fisicamente nos limites geográficos do Município de São Paulo: 1.4.1. Desenvolvimento; 1.4.2. Homologação; 1.4.3. Produção I; 1.4.4. Produção II (contingência, em load balance e failover); 1.4.5. Treinamento. 1.5. O Sistema de Central de Monitoramento subdivide-se em: 1.5.1. Módulo de Ocorrências 1.5.2. Módulo de Procedimentos Operacionais de Resposta; 1.5.3. Módulo de Atendimento e Despacho; 1.5.4. Módulo de Georeferenciamento; 1.5.5. Módulo de Visualização; 1.5.6. Módulo de Alarmes e Avisos; 1.5.7. Módulo de Estatísticas e Relatórios; 1.5.8. Módulo de Framework Web; 1.5.9. Módulo de Integração de Sistemas e Sensores; 1.5.10. Módulo de Mídias; 1.5.11. Módulo de Controle de Acesso; 1.5.12. Módulo de Vídeo Monitoramento; 1.5.13. Módulo de Auditoria e Logs; 1.5.14. Módulo de Backup e Versionamento

1.6. Os sistemas que constituem o objeto devem ser capazes de trabalhar de forma redundante, em alta disponibilidade e em arquitetura tolerante a falhas. 1.6.1. Em particular, deve ser possível a operação simultânea em modos load balance e fail over com outro sistema idêntico de Central de Monitoramento, permitindo a troca de uma central por outra em caso de falha de uma das centrais. 1.7. Os sistemas e módulos devem ser escaláveis na horizontal (adição de novos servidores e infraestrutura de hardware) e na vertical (aumento da capacidade de processamento) para atender a uma demanda crescente. 1.8. Os sistemas devem ser instalados de forma a serem acessados em ambiente centralizado web, nos servidores IIS ou Apache. 1.9. Todas as interfaces homem-máquina devem ser disponibilizadas na Língua Portuguesa. 1.10. Os módulos devem possuir padrão homogêneo de interface gráfica em todos os seus constituintes acessados via web. 1.11. O Sistema de Central de Monitoramento deve apresentar uma interface customizável ao usuário, baseado num mapa geográfico do município, sobre os quais são visualizados os eventos de interesse em tempo próximo ao real. 1.12. Cada sistema individual funciona como entidade autônoma e independente, mas operando em conjunto integrado com os demais sistemas e módulos que compõem a Central Integrada de Monitoramento. 1.13. Os sistemas devem ser compatíveis com servidores padrão x86 de 64bits, devendo ser capazes de rodar em ambientes: 1.13.1. Microsoft Windows Server ou RedHat Linux Enterprise Server ou ou CentOS em suas versões correntes. 1.13.2. Para armazenamento das informações referentes aos sistemas, deve ser possível o uso de pelo menos um dos seguintes Sistemas Gerenciadores de Banco de Dados, em suas versões mais correntes: 1.13.2.1. SQL Server 1.13.2.2. DB2 1.13.2.3. PostgreSQL 1.13.2.4. MySQL 1.14. O desenvolvimento de sistemas, módulos, interfaces e software customizado, necessários à entrega do objeto contratado, será feito, preferencialmente nos ambientes de programação HTML5, JEE,.NET e PHP, com scripting em shell sh ou csh, Perl, VBS e BAT (prompt de comando do Windows). Stored Procedures serão escritas conforme a linguagem SQL utilizada pelo software de banco de dados. 1.14.1. O desenvolvimento em outras linguagens de programação só será permitido mediante autorização prévia da CONTRATANTE. 1.15. O sistema deve ser capaz de utilizar banco de dados relacional padrão SQL para armazenamento de dados, com suporte a objetos espaciais e geográficos e funções GIS utilizando tais tipos de dados. 1.15.1. O acesso às bases de dados será provido pela CONTRATANTE. 1.15.2. Acesso indireto a bases externas será permitido a partir do Módulo de Integração de Sistemas e Sensores.

1.16. A CONTRATADA se obriga a entregar toda a documentação pertinente ao cumprimento dos entregáveis que são alvo desta contratação, incluindo o projeto detalhado da solução; manuais de instalação, configuração e testes integrados; documentação de apoio pertinente ao desenvolvimento; atas de reunião; cronogramas; relatórios técnicos e outros documentos que se fizerem necessários ou que forem solicitados. 1.17. As licenças fornecidas para a utilização do sistema devem ser definitivas, com garantia de atualização durante o período de contratação, com cessão de código-fonte, podendo a CONTRATANTE efetuar, a seu critério, múltiplas instalações e efetuar alterações no mesmo, a seu critério e julgamento. 1.17.1. A cessão de código-fonte será válida apenas nos casos de scripts (SQL, shell, web ou similares), onde não forem utilizados código-objeto compilado e executado diretamente (isto é, sem interpretadores). 1.17.2. Caso sejam utilizadas bibliotecas externas ou de terceiros, a CONTRATADA se obriga a fornecer até 15 (quinze) licenças necessárias para a compilação, com a quantidade definida a critério da CONTRATANTE. 1.18. Gerenciamento do Sistema de Central de Monitoramento 1.18.1. Os sistemas e módulos devem possuir gerenciamento centralizado com interface web, permitindo a sua configuração e parametrização por um operador a partir de um browser padrão web. 1.18.1.1. Os browsers suportados pelo sistema são o Microsoft Internet Explorer, o Mozilla Firefox, o Google Chrome e o Chromium, em ambientes Microsoft Windows, RedHat Linux Enterprise Server, SUSE Linux, Debian Linux, Ubuntu e CentOS em suas versões correntes. 1.18.1.2. Os sistemas devem possuir capacidade para monitorar o desempenho, a utilização de memória, CPU e uso de rede em tempo próximo ao real. 1.18.1.3. Os sistemas devem armazenar os dados relevantes à sua operação e possuir a capacidade de emitir relatórios de uso de CPU, memória, rede, tempos de resposta e disponibilidades totais e individuais de cada módulo. 1.18.2. Gerenciamento de falhas 1.18.3. Os sistemas informatizados devem possuir mecanismo de avaliação remota do seu estado e do consumo de memória e CPU via mensagens e alertas do tipo syslog e SNMP. 1.18.4. Também deve ser possível, via Módulo de Alarmes e Avisos, o envio de e- mails e mensagens SMS mediante configuração prévia, dependendo das características da falha e da sua criticidade. 1.18.4.1. O envio de SMS se dará via webservice de responsabilidade da CONTRATANTE. 2. Módulo de Ocorrências 2.1. Efetua o cadastro de eventos e ocorrências, possibilitando o cadastro de eventos esporádicos, agendados, habilitando as suas operações e procedimentos operacionais de resposta associados.

2.2. O Módulo de Ocorrências deverá permitir a criação de registros de eventos a serem gerenciados pela Central de Monitoramento, com informações mínimas que o identifiquem, tais como descrição, localização, tipo e gravidade do evento, fonte da informação do evento, situação, responsável por sua resposta, data e hora do evento e outras informações pertinentes. 2.2.1. Estes eventos poderão ser criados automaticamente ou de forma préagendada, através de integrações entre sistemas ou manualmente por um operador. 2.2.2. Deve possuir inventário de ocorrências integrado, que possibilite o cadastro de eventos programados, com início e término de eventos, riscos relacionados, workflow com ações necessárias (via Módulo de Procedimentos Operacionais de Resposta) e cadastro de recursos associados. O módulo deve permitir, no mínimo, a inserção dos seguintes atributos: 2.2.2.1.Identificador da ocorrência (descritivo alfanumérico); 2.2.2.2.Nome da ocorrência; 2.2.2.3.Descritivo; 2.2.2.4.Data e hora de início; 2.2.2.5.Data e hora prevista para término; 2.2.2.6.Local da ocorrência; 2.2.2.7.Permitir a inclusão e visualização de arquivos associados de imagens e vídeos. 2.3. Deve permitir a classificação de ocorrências a um ou mais tipos (ou classes) previamente cadastrados. 2.4. Deve permitir atribuir valores de prioridade e importância às ocorrências de forma automática ou manual, através de informações contidas nestes registros no momento da criação/atualização. 2.5. Deve registrar informações sobre temporização das ocorrências em cada status disponível no sistema, alimentando o Módulo de Alarmes e Avisos. 2.5.1. Permitir a criação manual de eventos, via formulário específico e customizável apresentado na tela do operador. 2.5.1.1.Deve ser possível atribuir uma localização geográfica a uma evento das seguintes formas: 2.5.1.1.1. Localização através de clique de mouse no mapa apresentado na tela do Módulo de Visualização; 2.5.1.1.2. Entrada direta de latitude e longitude; 2.5.1.1.3. Endereço completo (logradouro e número); 2.5.1.1.4. Entrada direta de ponto de interesse, via cadastro prévio de tais pontos; 2.5.1.1.5. Cruzamento de logradouros; 2.5.1.1.6. Com uma distância pré-definida a partir de um ponto de interesse (por exemplo: Marginal Tietê, a 500m da Ponte Casa Verde, sentido Ayrton Senna). 2.5.1.2.Para cada ocorrência, deve ser possível atribuir um raio de interesse, na forma de um buffer circular de raio definido pelo usuário em torno da latitude/longitude fornecida pelo próprio usuário ou calculada pelo sistema. 2.5.1.3. 2.5.2. Permitir criação sem intervenção humana de eventos, acionada via Módulo de Integração de Sistemas e Sensores por outros componentes da solução ou

sistemas externos que enviam dados do evento via serviços tais como web services ou fila de mensagens. 2.6. Permitir atualização de dados associados do evento, bem como encerramento do mesmo, gerando registro auditável de tais atualizações.. 2.7. Permitir ao operador e demais módulos correlacionar dois eventos com base na localização (distância entre eventos menor que valor parametrizado) e na data e hora dos eventos (diferença de data e hora menor que valor parametrizado). 2.8. Exibir lista de eventos em andamento (não encerrados) em painel de controle para visualização do usuário; 2.9. Exibir eventos em andamento (não encerrados) no mapa parte do componente Módulo de Georeferenciamento e exibido na tela do usuário via Módulo de Visualização. 2.10. Permitir escalada de evento para incidente após análise manual feita pelo usuário e permitir informar razão da escalada para incidente. 2.11. Deve permitir que cada ocorrência ou unidade possua status e atributos no sistema, que serão definidos por informações cadastrais e localização no mapa combinadas com registros realizados durante a vigência da ocorrência. 2.12. Deve permitir que cada ocorrência ou unidade possua um segundo nível de status, manual ou automático, que indique a situação diferenciada desta ocorrência. 2.13. Deve permitir que cada ocorrência possua um terceiro nível de status, distinguindo fases de contatos internos e/ou externos. 2.14. Cada status alertará, via Módulo de Alarmes e Avisos, com prioridade ou não, um ou mais usuários, identificados no Módulo de Controle de Acesso, sobre a ação efetuada ou a necessidade de alguma nova ação: pendente, acionar, acionada, reiterar, reiterada, cancelar, cancelada, consultar, consultada, guinchado, ignorado, arquivar. Esta ação deverá prever o cadastro de informações sobre o contato realizado. 2.15. Todas as informações inseridas manualmente deverão permitir que o usuário realize a leitura no tempo que precisar, antes do primeiro salvamento. Após a primeira gravação, todos os dados e alterações serão armazenados. 2.16. Deve possuir a capacidade de trabalhar de modo integrado a uma base de dados cartográfica, via Módulo de Georeferenciamento; 2.17. Deve permitir o cadastro de limites de área para cada serviço, possibilitando o uso de alarmes a unidades que se encontrarem fora destes limites ( cerca eletrônica ). 2.18. Deve permitir, a usuários específicos, o registro de ocorrências com datas retroativas para uso em pós-contingências (dados históricos). 2.19. Um ícone representativo da ocorrência deverá ser exibido no mapa via Módulo de Visualização. 3. Módulo de Procedimentos Operacionais de Resposta 3.1. O Módulo de Procedimentos Operacionais de Resposta a incidentes deverá permitir a execução e acompanhamento de procedimentos pré-definidos de gestão e respostas a eventos que foram escalados para incidente no Módulo de Ocorrências, através de um fluxo de trabalho com as atividades de resposta descritas no procedimento pré-definido no cadastramento do Procedimento Operacional de Resposta Associado.

3.1.1. Estes procedimentos de resposta a incidentes poderão ser criadas automaticamente, isto é, sem intervenção manual, através de integrações via Módulo de Integração de Sistemas e Sensores ou manualmente e gerenciadas através de um painel de controle visual, por meio do Módulo de Visualização. 3.2. O Módulo de Procedimentos Operacionais de Resposta deverá permitir que o fluxo de trabalho de resposta a um incidente seja executado por meio de acionamento pelo usuário; uma vez acionado, o fluxo de trabalho deverá gerar de forma automática todas as atividades do fluxo de resposta descrito no procedimento operacional de resposta pré-definido. 3.3. O Módulo de Procedimentos Operacionais de Resposta devepermitir a criação manual de atividades de resposta pelo usuário, com dados mínimos tais como descrição, data e hora, data e hora previstas para término e responsável. 3.3.1. A atividade criada manualmente será direcionada para um outro usuário ou instituição responsável por sua execução. 3.4. O Módulo de Procedimentos Operacionais de Resposta deverá executar a atividade de forma automática permitindo estabelecer critérios tais como condições para execução da atividade, nível de escalada para usuário responsável e agendamento e programação da atividade entre outros atributos, desde que previamente configurado. 3.5. O Módulo de Procedimentos Operacionais de Resposta deverá integrar-se ao Módulo de Alarmes e Avisos para permitir envio de notificação de forma automática. 3.6. O Módulo de Procedimentos Operacionais de Resposta deve permitir visualizar a situação, o andamento e o status de cada atividade. 3.7. O Módulo de Procedimentos Operacionais de Resposta deve permitir atualizar os dados de uma atividade de resposta bem como encerrar uma atividade de resposta pelo usuário responsável pela execução da atividade 3.8. O Módulo de Procedimentos Operacionais de Resposta deve permitir a definição precisa de pessoas de contato e processo de escalação. 3.9. O Módulo de Procedimentos Operacionais de Resposta deve possuir a funcionalidade de registro do status de resolução do alerta e de evidenciar os alertas pendentes de resolução, via Módulo de Alarmes e Avisos; 3.10. Deve possuir funcionalidade que permita a criação de workflows de forma gráfica em ambiente web, controlado pelo Módulo de Visualização. 3.11. O cadastro de Procedimentos de Resposta deverá permitir a construção de Procedimentos Operacionais Padrão monitoráveis, a serem construídos como workflows com a inserção de: 3.11.1. Procedimentos Padrão de Operação, com a descrição das atividades; 3.11.2. Datas de fim e inicio das atividades; 3.11.3. Status das atividades; 3.11.4. Descrição de recursos a serem empregados nas atividades ; 3.11.5. Procedimentos Padrão de Operação; 3.11.6. Status do recurso, nível de serviço (ex. operante, reparo); 3.11.7. Contato responsável pelo recurso, via Módulo de Controle de Acesso; 3.11.8. Atributos do recurso;

3.11.9. Emails, números de telefones e informações de contatos que notifiquem o progresso das atividades do workflow, a não execução de atividades ou a necessidade de entrada manual de dados, via Módulo de Alarmes e Avisos. 3.12. A base de dados gerada pelo controle dos processos deverá estar disponível para consultas que permitam avaliações da performance das ações empreendidas, via Módulo de Estatísticas e Relatórios. 3.13. As atividades deverão estar disponíveis para acesso remoto através da web, de maneira que os atores possam visualizar e interagir com suas respectivas atividades. 3.14. Deverá ser possível iniciar as atividades / workflows tendo como base um evento criado de forma manual através da interface ou via integração com um sistema externo, via Módulo de Integração de Sistemas e Sensores. 3.15. Deverá contar com inventário básico de ativos, devendo integrar-se ao Módulo de Controle de Ativos para um controle mais amplo e extenso. 3.16. O sistema deve contar com sistema gerenciador do fluxo de trabalho, considerando a possibilidade de cadastro e gestão dos processos necessários para o atendimento e acompanhamento de ocorrências. 3.17. Deve possibilitar aos usuários planejadores definir e associar formulários múltiplos específicos com cada tipo de incidente e procedimentos. 3.18. Deve possuir mecanismo para associar arquivos anexos e associá-los com tipos de incidente e procedimentos. 4. Módulo de Atendimento e Despacho 4.1. O sistema deverá possuir funcionalidades de atendimento às instituições, registro, despacho e acompanhamento de ocorrências, considerando as funcionalidades requisitadas para operações de monitoramento. 4.2. Deverá permitir a classificação das ocorrências atendidas de acordo com os níveis de criticidade definidos pelo operador ou de forma automática, permitindo ainda o registro e o acompanhamento das ocorrências em andamento. 4.3. Deve prover o gerenciamento de chamadas de emergência, tanto no atendimento da solicitação quanto no despacho de recursos. 4.4. Deve permitir o registro, despacho e acompanhamento de ocorrências através das interfaces de atendimento e despacho. 4.5. Deve permitir a priorização dos atendimentos relacionados a cada tipo de ocorrência. 4.6. Deve permitir definição do formato de um identificador alfanumérico que será automaticamente designada aos registros de ocorrências. 4.7. Deve permitir calcular e registrar o tempo estimado de chegada de uma unidade de campo até a ocorrência, gerando alertas via Módulo de Alarmes e Avisos. 4.8. Deve permitir que as ocorrências sejam cadastradas com um código identificador alfanumérico, possibilitando a correlação entre o identificador da ocorrência e sua localidade de origem. 4.8.1. O número de caracteres e o formato do identificador deverá ser customizável. 4.9. Deve permitir trabalhar com os seguintes dados de ocorrências: 4.9.1. Data da geração

4.9.2. Hora da geração; 4.9.3. Localização (endereço, bairro, cidade, estado, complemento); 4.9.4. Tipo da ocorrência; 4.9.5. Pessoas envolvidas (autor, vítima, testemunhas); 4.9.6. Existência de vítimas com necessidades de atendimento médico (quantidade e breve descrição da gravidade das vítimas); 4.9.7. Identificação de veículos envolvidos (modelo, cor, placa, características específicas); 4.9.8. Status da ocorrência (em andamento, finalizada, encerrada no local, etc); 4.9.9. Origem do chamado (Canal ou meio utilizado para identificação da ocorrência); 4.9.10. Responsável pela ocorrência, incluindo nome, posto/graduação/cargo e organização a que pertence; 4.9.11. Responsável pelo registro da ocorrência no sistema (nome, posto/graduação ou cargo, instituição a que pertence); 4.9.12. Data do registro; 4.9.13. Horário do registro; 4.9.14. Histórico; 4.9.15. Providências adotadas, incluindo recursos despachados. 4.10. Deve possibilitar o envio simultâneo, via Modulo de Alertas, a todas as instituições envolvidas, quando da necessidade de múltiplo emprego de recursos. 4.11. Deve permitir o despacho das ocorrências ao órgão responsável pelo atendimento, possibilitando o cumprimento das rotinas que exercidas atualmente, receberá as anotações realizadas pelo atendimento, avaliará a necessidade de envio de meios e acionará os meios adequados e necessários para o local da ocorrência. 4.12. Deve permitir a visualização e acompanhamento das ocorrências em andamento. O sistema deverá permitir o acompanhamento das ocorrências em andamento por meio de diferentes formas de priorização considerando, minimamente, sua criticidade, cronologia, região geográfica, organizações atuantes e tipo. As ações decorrentes das tomadas de decisão também deverão ser registradas e visualizadas. 4.13. Permitir ao usuário marcar ocorrências como sendo correlacionadas ou diretamente associadas entre si. 4.14. Possuir mecanismos para permitir a identificação de registro de ocorrências em duplicidade. 4.15. Possuir mecanismos que possibilitem a classificação manual e automática das ocorrências conforme critérios e condições pré-definidas, de maneira a definir quantitativamente a urgência e os impactos estimados. 4.16. Permitir a exibição automática de alertas com informações sobre criticidade das ocorrências, data, horário e localização nos televisores LCD 16:9 e monitores de vídeo 16:10 utilizados pela equipe de operações da Central de Monitoramento, via Módulo de Visualização. 4.17. Possuir interface de monitoração que permita ao operador a realização de filtros minimamente por status, criticidade, tipo de ocorrência, órgão e pessoa responsável, data e horário da ocorrência, localização e informações sobre veículos e pessoas envolvidos. 4.18. Permitir a consulta de informações sobre ocorrências finalizadas.

4.19. Permitir a atualização manual das ocorrências por parte de equipes de campo 4.20. Permitir o direcionamento manual de ações para as diferentes organizações externas. Estas ações podem estar relacionadas a atividades de monitoramento remoto, avaliação ou tratamento in loco e encerramento das ocorrências. 4.21. Permitir o direcionamento automático de ações, de acordo com critérios prédefinidos para ocorrências com características específicas. Estas ações podem estar relacionadas ao direcionamento de chamadas telefônicas (via Sistema de Telefonia) e o envio de mensagens eletrônicas para dispositivos móveis ou embarcados (via Módulo de Alarmes e Avisos). 4.22. Deve se integrar ao Módulo de Estatísticas e Relatórios para inserir automaticamente as ocorrências finalizadas nas bases de conhecimento da Central de Monitoramento. 4.23. Permitir a seleção e direcionamento de ações de ocorrências por meio da localização no mapa disponível via Módulo de Georeferenciamento e mostrado no Módulo de Visualização e de ferramentas de georeferenciamento. 4.24. Deve possibilitar o retorno das ligações das chamadas de ocorrências, via integração com Sistema de Telefonia, através da interface gráfica. 4.25. Deve permitir o direcionamento automático de ocorrências correlacionadas, de acordo com requisitos pré-definidos. 5. Módulo de Georeferenciamento 5.1. Módulo de Georreferenciamento deverá prover serviços de apresentação, e publicaçãopublicação e apresentação de mapas e pontos de interesse, bem como prover funções relacionadas à manipulação e edição de dados espaciais. 5.2. Poderá se conectar a um map server disponível publicamente, ou a um sistema de informações geográficas, conhecido como SIG (Sistema de Informação Geográfica) no padrão de dados (Formato de armazenamento) e sistemas (Software) existentes e em uso na CONTRATANTE. 5.3. Deverá ser disponibilizado o sistema de mapas com servidor de dados geográficos interoperável, que possibilite, através de serviços web, o intercâmbio e a transmissão de dados geográficos entre o sistema, seus módulos internos e ambientes externos, mediante serviços providos pelo Módulo de Integração de Sistemas e Sensores. 5.4. Visando facilitar a interoperabilidade, toda implementação será desenvolvida baseada em especificações e padrões definidos pelo Open Geospatial Consortium (OGC) incluindo, mas não se limitando, aos padrões de comunicação e manutenção de dados geográficos WMS (Web Map Service Interface Standard ) e WFS (Web Feature Service Interface Standard). 5.5. A solução deverá ser de alto desempenho e disponibilidade para acesso a um banco de dados espacial com o objetivo de atender as necessidades vigentes em Sistema de Informação Geográfica (SIG). A licença do SIG deverá permitir a instalação para configuração de servidores em balanço (Farm) para possibilitar alto desempenho e escalabilidade. 5.6. Deverá acomodar as seguintes feições gráficas básicas: 5.6.1. Segmento de Logradouro; 5.6.2. Numeração do Imóvel (Indicação de Face de Lote Ponto de Mercado);

5.6.3. Bairros; 5.6.4. Acidente Geográfico; 5.6.5. Área Urbana (Mancha Urbana); 5.6.6. Localidade; 5.6.7. Edificação de Destaque; 5.6.8. Ponto Notável; 5.6.9. Ferrovia; 5.6.10. Hidrografia. 5.7. O serviço de apresentação e publicação de mapas da solução apresentada preferencialmente deve ser compatível com SIGSIG os padrões e formatos adotados pela CONTRATANTE.O módulo deve permitir a conexão com um serviço público de fornecimento de mapas e imagens ortorretificadas (Provenientes de satélite ou ortofotos),, e com a base de SIG de propriedade da CONTRATANTE. 5.8. O módulo deve permitir a construção de mapa global para ver onde as ocorrências estão localizadas e para controlar quais categorias de ocorrências são mostradas. 5.8.1. Deve fornecer uma representação visual dos eventos em um mapa que permita a identificação de padrões do local, conflitos e outros problemas com informações provenientes de outros módulos e sistemas. 5.9. Deverá possuir duas interfaces interativas: 5.9.1. Mapa: Um mapa da região geográfica fornecendo informações sobre o local do evento. 5.9.2. Filtro: Um formulário de entrada que permita selecionar quais categorias de ocorrências serão mostradas no mapa. 5.10. O mapa deverá mostrar todos os eventos que são relevantes, usando os valores de latitude e longitude especificados no registro de eventos para mostrar a localização do evento no formulário na forma de um ícone ou imagem determinada pelo usuário operador. 5.11. O mapa deverá ser atualizado conforme novas ocorrências são inseridas no sistema, sujeitas a quaisquer filtros configurados para limitar as categorias mostradas. Deverá ser possível exibir uma descrição do evento clicando no marcador do evento no mapa. As categorias de evento exibidas no mapa poderão ser alteradas com base na seleção de formulário de filtro. 5.12. Deverá ser possível focar na categoria do evento que se deseja analisar, utilizando o filtro para ocultar as categorias de evento que não sejam necessárias. 5.13. O mapa deverá responder para qualquer nova seleção de categoria enviada a partir do formulário de filtro. Quando uma solicitação for enviada, a janela do mapa deverá ser atualizada e apenas os locais de eventos da categoria selecionada serão plotados no mapa e visualizados na tela do usuário por intermédio do Módulo de Visualização. 5.14. Deverá ser possível focar nos eventos individuais que se deseja analisar marcando caixas de seleção de eventos. Esses eventos serão, então, destacados no mapa.

5.15. O mapa deverá representar o local de um evento com um dos seguintes tipos de marcador: 5.15.1. Ícone: Identifica a localização de um evento no mapa com um ícone exclusivo para cada categoria. 5.15.2. Polígono: Uma estrutura de tópicos no mapa da área associada a um evento. 5.16. O ícone e o nome da categoria deverão estar inclusos nos detalhes sobre a ocorrência. 5.17. A plataforma integrada de Georreferenciamento deverá permitir ao Módulo de Visualização as funcionalidades de interface de exploração de mapas: aproximar (Zoom in), afastar (Zoom out) e centralizar no espaço disponível, janela (Zoom window); arrastar, deslocar e rotacionar o mapa; uso de unidades de medidas configuráveis; cálculo de distância lineares entre dois ou mais pontos com apresentação da distância acumulada; cálculo de áreas entre três ou mais pontos; mudança de unidade da escala do mapa; bússola; lente de aumento; apresentação de coordenadas fornecidas de acordo com a localização do cursor do mouse; símbolos que diferenciem eventos e recursos / entidades representadas no mapa; capacidade de fazer anotações no mapa incluindo pontos, retas, polígonos e suas respectivas legendas. 5.18. A solução deve ter funções que permitam o cálculo de rotas e permitir a configuração de itinerários entre um ponto de origem e um ponto de destino, entre um ponto de origem e vários pontos de destino, entre um ponto de origem e um destino e vários pontos de passagem intermediários (Caixeiro viajante). 5.19. A solução deve ter funções que permitam o cálculo de rotas com opção de menor caminho, melhor caminho e caminho mais rápido. 5.20. A empresa contratada deverá executar serviços para adaptar a base de dados oficial da CONTRATANTE para permitir a execução de operações de roteamente e levantar as informações e cadastrar todas as informações necessárias para o perfeito funcionamento do sistema, incluindo mão de direção, conversões permitidas e proibidas, velocidade permitida, entre outras características para executar este tipo de operação. 5.21. A solução deve disponibilizar funções de geocoding e geocoding reverso. As ocorrências serão cadastradas sempre com um endereço válido (Nome do logradouro e numeração exata ou aproximada) e o sistema deverá georreferenciar este endereço (Por métodos de geocodificação ou Address Match) e o sistema deverá transformar este endereço em uma coordenada que será armazenada no formato longitude e latitude ou coordenadas planas (E,N). Tratamento em relação a análise fonética deverão ser considerados, para a localização de endereços digitados parcialmente ou grafia semelhante ao real, assim como uma forma de correção e adição de nomenclatura oficial e popular, diferenciação de logradouros homônimos entre outros recursos de identificação e padronização automática de endereços. 5.22. Deve permitir a administração e gerenciamento de pontos de interesse organizados por categorias. 5.23. Deve suportar múltiplos provedores SIG 2D e 3D (relevo de terreno, superfície e modelos 3D de edificações, se disponíveis) simultaneamente. 5.24. Deve suportar camadas múltiplas de mapas. 5.25. Deve suportar navegar entre os múltiplos níveis de visualização.

5.26. Deve suportar o recurso de apresentar automaticamente as visualizações de mapas ou localizações mais relevantes para o incidente. 5.27. Deve prover recurso para adicionar, via operador ou pelo provimento de webservice, via Módulo de Integração um ponto notável ou de interesses, como sensor ou múltiplos sensores ou grupo de sensores ao SIG, através do posicionamento do cursor do mouse em cima do mapa, ou pela entrada direta de coordenadas geodésicas. 5.28. Deve prover recurso para customizar ícones de sensores. Os ícones representando sensores devem refletir visualmente o estado de cada sensor ou grupo de sensores. 5.29. Deve prover recurso para rastrear o movimento de tecnologias baseadas em localização, se tecnologicamente viável, (ex.: GPS, RFID, etc.), apresentando visualmente o trajeto histórico de movimento. 5.30. Deve prover recurso para customizar a visibilidade de um mapa do SIG por nível de zoom. 5.31. Deve ser integrável aos demais módulos e sistemas, de forma a possibiltar o disparo, via Módulo de Integração, de ações e tarefas, ou ainda o consumo de webservices. 5.32. Deve suportar o recurso de adicionar marcadores visuais ao SIG. Os marcadores, imagem/ícone devem ser personalizáveis. Os marcadores devem ter recursos de ativar automaticamente ações variadas. 5.33. Deve possuir recurso para definir restrições de autorização para a administração do SIG como adicionar visualização, ícones, layers, etc. 5.34. Deve servir como centralizador de manipulação de informações georeferenciadas entre todos os módulos e sistemas. 6. Módulo de Visualização 6.1. Deve ser compatível com o trabalho em desktops com duas telas, de modo a possibilitar a melhor visualização e organização dos recursos disponíveis no sistema. 6.2. Permitir que o usuário organize na sua tela as diversas janelas de trabalho, pré-definidas no sistema, de acordo com seu uso e preferência, tanto na estação de trabalho, como em tablet e smartphones. 6.3. O Módulo de Visualização deve permitir a inclusão manual e a captura automática de informações que viabilizam a localização geográfica das ocorrências, possibilitando a visualização destas informações na tela bem como dos arquivos de gravação referentes a estas, possibilitando a geração de um mapa especifico e a localização fácil das ocorrências. 6.4. O módulo, ao receber as informações relevantes de outros sistemas (por exemplo, o Módulo de Ocorrências), ilustrará a ocorrência em um mapa global permanentemente atualizado em tempo próximo ao real, de acordo com uma legenda técnica padronizada, devendo ser descrita por código e nível de risco. 6.5. Por meio de filtros predeterminados, o sistema deverá permitir ao operador visualizar as câmeras de vídeo disponíveis na região, via Módulo de Integração de Sistemas e Sensores, recursos disponíveis, viaturas mais próximas de um incidente, hospitais, rotas para deslocamento (estabelecimento e gerenciamento), entre outros. O sistema deverá permitir que o operador selecione a câmera mais próxima e acione-a de forma a obter a imagem do evento no momento em que ele se desenvolve.

6.6. O sistema integrador deve permitir a interação com o Módulo de Georeferenciamento, de tal forma que qualquer elemento gráfico referente a um item de interesse (tal como uma ocorrência, viatura, alerta ou dispositivo de monitoramento) possa ser manipulado diretamente a partir do seu ícone indicativo no mapa, através de um menu de contexto. 6.7. Deverá ser apresentável no mapa a posição dos elementos móveis conhecidos, dentre eles, mas não restritos a: recursos de segurança e relacionados, como viaturas policiais, bases móveis, viaturas dos bombeiros, ambulâncias, helicópteros, terminais embarcados, pontos de interesse, entre outros recursos com disponibilidade de informações de posicionamento. 6.7.1. O posicionamento geográfico poderá será obtido, por exemplo, a partir do Módulo de Integração de Sistemas e Sensores. 6.8. A solução também deverá ser capaz de trabalhar com monitores operando em resoluções de 16:9 ou 16:10, permitindo que qualquer tela de acompanhamento de ocorrências, relatórios, indicadores ou informações do Sistema da Central de Monitoramento possam ser disponibilizadas para visualização em aparelhos de TV tela plana ou monitores de vídeo. 6.9. Deve oferecer os recursos de pan e zoom do mapa global onde as ocorrências e pontos de interesse são visualizados. 6.10. Deve se integrar ao Módulo de Alarmes e Avisos para a visualização de alertas por meio de ícones e talas de alto contraste e janelas modais. 6.11. A solução deve permitir a interação das operações dos diversos sistemas e módulos integrados, permitindo ao operador a análise de informações geradas pelos vários sistemas de forma única através de uma interface homem-máquina padronizada e consistente. 6.12. Deverá permitir a visualização a partir de terminais móveis, tais como smartphones, tablets e PDAs. 6.12.1. Os sistemas suporados para handhelds serão o ios e o Android, em suas versões mais correntes. 6.12.2. Os navegadores suportados serão, nesta ordem de preferência: 6.12.2.1. Aqueles fornecidos em conjunto com o sistema operacional (Safari, Android Broser) ; 6.12.2.2. Google Chrome, como forma de padronização entre plataformas. 6.13. Permitir que os vários usuários do sistema controlem os conteúdos disponíveis para visualização e operem os layouts nos diversos painéis de visualização. 6.14. Deve ser possível a criação automática de layouts e presets de câmeras e aplicativos, as operações de controle de janelas, o posicionamento e redimensionamento dos conteúdos, o controle das entradas físicas de vídeo dos displays e o controle remoto de estações conectadas ao sistema. 6.14.1. O acesso à ferramenta e os níveis de acesso às funcionalidades serão os definidos pelo administrador/supervisor na ferramenta de gerenciamento, via Módulo de Controle de Acesso. 6.15. Uma vez desencadeada uma situação de evento, deverá automaticamente exibir o plano de ação pré-programada e deve atualizar automaticamente e dinamicamente o plano de resposta baseado em novas informações ou entradas pelo operador. 6.16. Deve prover ao operador, a qualquer hora, permissões apropriadas para ver a lista de todos os eventos e situações correntes com os detalhes associados,

incluindo ações tomadas e pendentes; operador responsável; imagens de vídeo relevantes, e plano de ações em andamento. 6.17. Deve pertmitir que usuários do tipo coordenadores possam replicar em sua estação de trabalho a mesma tela visualizada por qualquer operador/usuário sob sua coordenação. 6.18. Deve prover recurso para o usuário assumir a responsabilidade (coordenação) pelo incidente após recebimento. 6.19. Deve prover recurso de criar um relatório com data/hora de todos os procedimentos adotados no gerenciamento do incidente. 6.20. Deve fazer atualização dinâmica das prioridades operacionais de cada usuário e suportar divisão balanceada de incidentes de acordo com a evolução da situação. 6.21. Deve prover recurso de fazer atualização das propriedades do incidente, realocar incidentes e adicionar tarefas agendadas automaticamente de acordo com a demanda. 6.22. Deve prover recurso para escalar os incidentes que não foram gerenciados dentro do tempo previsto. 6.23. Deve prover uma tela dedicada para gerenciamento de incidentes. 6.24. Deve permitir visualizar os incidentes relevantes por cada usuário responsável. 6.25. Deve integrar-se ao Módulo de Controle de Acesso, de forma a possuir recurso para filtrar quais incidentes podem ser vistos por quais operadores. 6.26. Deve prover um relatório integrado de incidentes que contém visualização de todos os incidentes e que podem automaticamente classificar novos incidentes de acordo com a severidade pré-definida e sequência de criação. 6.27. Deve prover recurso para alocar categoria (ou tipo de incidente) para os incidentes, tanto automaticamente ou sob demanda e agrupar incidentes dentro do log de incidentes por região, por responsável ou por categoria. 6.28. Deve permitir administradores definir a categoria padrão para quick launch por operador como emergência médica, crime, acidente, etc. 6.29. Deve prover log de incidentes que possibilita acesso fácil a mapas e imagens de vídeo relevantes, anexas e formulários por cada incidente. 6.30. Deve prover recurso para visualizar e editar formulários relacionados a incidentes e tarefas. O formulário com todas as atualizações deve ser salvo e acessível a qualquer hora. 6.31. Deve prover recurso para localizar incidentes que compartilham características similares. Cada incidente similar com horário de criação, horário de fechamento, sensores relacionados, criador e procedimentos adotados devem ser visualizados. 6.32. Deve possuir recurso para visualizar as tarefas relevantes por cada incidente. 6.33. Deve possuir recurso para visualizar as tarefas relevantes por cada operador. 6.34. Deve prover recurso para adicionar, alocar e realocar tarefas em tempo real para um usuário ou grupo de usuários. 6.35. Deve prover recurso para adicionar anexos no momento da criação da tarefa. 6.36. Deve prover recurso para adicionar comentários a incidentes, tanto no formulário pré-definido como no formato texto livre. 6.37. Deve prover recurso para disparar automaticamente as ações quando a tarefa é classificada como cancelada, falhada, realocada, etc.

6.38. Deve prover recurso para ocultar incidentes fechados dentro do log de incidentes ativos ainda procurar por incidentes fechados de acordo com a propriedade do filtro. 6.39. Deve prover recurso para criar incidentes pré-arquivados, para propósito de relatório do incidente, e não aparecer no log de incidentes ativos. 6.40. Deve suportar recurso para procurar por incidentes ativos. 6.41. Deve mostrar popup de notificações quando o incidente é criado e escalado. 6.41.1. A cor do popup de notificações deve refletir a severidade do incidente. 6.42. Deve suportar recurso para filtrar o conteúdo do relatório de incidente e gerar relatórios de acordo com a demanda ou automaticamente para qualquer incidente a qualquer hora, no formato selecionado pelo operador. 6.43. Deve permitir aos usuários enviar pacotes de relatórios contendo informações como formulários, vídeo clipe, snapshots, emails relacionados, etc. 6.44. Deve requerer um comentário, sobre o encerramento do incidente, o qual deve ser gravado e ser recuperável para análise posterior. 7. Módulo de Alarmes e Avisos 7.1. Deve permitir o envio de mensagens de texto através de email, mensagens por popups e, torpedos SMS de forma automatizada e deve estar nativamente integrado aos demais módulos da Central de Monitoramento. 7.1.1. Deve permitir a geração, localmente, no terminal do usuário, de alarmes audíveis. 7.1.2. O webservice para envio de SMS será provido pela CONTRATANTE. 7.1.3. Deve ser capaz de endereçar mensagens destinadas a serviços de monitoramento SNMP e syslog. 7.1.4. Deve ainda permitir integração ao Sistema de Integração de Telefonia para o disparo de torpedos de voz. 7.2. Permitir a comunicação (chat) entre os usuários com mensagens préformatadas ou livres, com visualização de histórico pelos usuários envolvidos e pela supervisão. 7.3. O módulo deve ser baseado e integrado à interface web coordenada pelo Módulo de Visualização. 7.4. Deverá dispor de interface de administração web. 7.5. Deve permitir a configuração do acesso de usuários e regras pelos administradores da ferramenta, via Módulo de Controle de Acesso. 7.6. A solução deverá possuir funcionalidade de mensagens instantâneas (chat) permita aos operadores do sistema a troca de informações em tempo real. 7.6.1. As mensagens instantâneas deverão poder ser acionadas de forma manual ou de forma automática acionada por agente externo, via Módulo de Integração de Sistemas e Sensores. 7.6.2. A solução deverá exibir dados de presença do usuário (ex. ativo, inativo). 7.6.3. A solução deverá permitir a troca de mensagens criptografadas utilizando padrões de segurança de mercado (ex. HTTPS). 7.6.4. Deve ainda possibilitar a assinatura de mensagens e avisos utilizando certificados digitais padrão ICP-Brasil.

7.6.5. Deve permitir o disparo de alarmes em sistemas informatizados remotos, via Módulo de Integração de Sistemas e Sensores. 8. Módulo de Relatórios Operacionais 8.1. O módulo de Estatísticas e Relatórios deve se comunicar a uma base de dados, permitindo o armazenamento e compartilhamento de todos os elementos e informações trafegadas e tratadas na Central de Monitoramento, por meio de uma plataforma web comum a todos os usuários. 8.2. Este módulo deve ser integrado a todos os demais módulos, permitindo o acesso tabular às informações armazenadas, ajudando a compor análises estatísticas e extração de relatórios com base nas hierarquias de vínculos, correlações e dependências entre entidades e atributos de análise. 8.3. Deve possibilitar identificação e análise de vínculos entre bases, entre registros disponíveis e a partir de inserção de palavras-chave de busca. 8.4. Deve permitir a identificação e análise de relacionamento entre entidades, considerando quantidade de relacionamentos, repetições, conexões diretas e indiretas entre entidades e atributos. 8.5. O sistema deverá fornecer relatórios consolidados e personalizados considerando, minimamente, períodos de tempo, classificações de criticidade, regiões geográficas, tipo, bem como índices/indicadores (estatísticas) de eficiência, na resolução das ocorrências, dentre outros. 8.6. De posse dos dados extraídos, o sistema deve possibilitar a aplicação de regras para a conversão, cálculos, correlações e análises de dados. 8.7. O sistema deverá possuir um gerador de estatísticas e relatórios de interesse, a fim de ressaltar os principais índices. 8.8. O sistema também deve prover métodos para que sistemas, sem intervenção manual, sejam capazes de acessar informações na forma de relatórios. 8.9. As integrações e relatórios não devem afetar o desempenho do sistema e das interfaces utilizadas na operação. 8.10. O módulo deverá permitir a criação/modificação de indicadores de performance e modelos de monitoramento, e deve conter pelo menos as seguintes funcionalidades: 8.11. Possibilidade de uso de cores nos indicadores de desempenho. 8.12. Os indicadores de desempenho devem ser capazes de agregar informações sobre recursos distintos de forma aninhada (status de veículos, que compreende status de caminhões, ambulâncias) e de forma individual (status de caminhões). 8.13. A visualização de tais indicadores de desempenho deve ser separada por níveis de acesso, de maneira que determinados indicadores só possam ser visualizados se devidamente autorizados, via integração com o Módulo de Controle de Acesso. 8.14. Ser nativamente integrado aos demais módulos, permitindo, por exemplo, o envio de alertas se um indicador atingir um valor crítico. 8.15. Permitir a criação de novos indicadores a serem monitorados. 8.16. Permitir o cálculo dos valores dos indicadores com base em medições ou através de expressões baseadas nos indicadores existentes. 8.17. Deverá permitir a riação de relatórios com com diferentes tipos de gráficos (coluna, pizza, barra, etc.)

8.18. Possuir interface para confecção de consultas e construção de análises e, neste contexto, possuir linguagem de interação e desenvolvimento scripts para manipulação, automação e análise de informações. 8.19. O sistema deve processar informações, aplicar regras predefinidas para conversão de dados (ex: inteiro para float ou data para string), realizar cálculos, e permitir ao usuário identificação de tendências para possibilitar a análise e o direcionamento de ações para tratamento preventivo de possíveis eventos. 8.20. Permitir a criação de regras de cálculos e análises que envolvam dados oriundos de fontes distintas, desde que obedeçam às regras de perfis de acesso aos dados integrados. 8.21. Realizar cálculos estatísticos e que incluam operações de máximo, mínimo, porcentagem, média e soma, em relação a quaisquer dimensões de dados, em qualquer métrica. 8.22. Possuir biblioteca de funções (lógica, conversão, financeiras, matemáticas, analíticas, estatísticas, cadeias de caracteres e outras) para serem utilizadas durante o processamento de regras pré-definidas ou em consultas e relatórios. 8.22.1. Deverá se integrar ao Módulo de Georeferenciamento para permitir a utilização de funções e a manipulação de dados geográficos. 8.23. Possibilitar o agendamento de execução e processamentos de dados. 8.24. Possuir base de informações padronizada e centralizada para armazenamento dos dados processados. 8.25. Disponibilizar os resultados de processamentos já executados de forma que permitam a realização de consultas sem a necessidade da execução de novos processamentos. 8.26. Deverá apresentar relatórios de falhas ocorridas com os respectivos logs de erro. 8.27. Deverá apresentar também um relatório com os erros de integração com os demais sistemas, com interface de fácil compreensão, onde seja possível identificar a falha ocorrida, a ocorrência e unidade operacional relacionada à falha e o conteúdo da informação que estava sendo integrada. 8.28. Deverá propiciar a geração dos seguintes tipos de relatórios a serem utilizados para o planejamento estratégico: 8.28.1. Estatísticas de Tipos de Ocorrência por região (ou Área de Atendimento); 8.28.2. Estatísticas de Ocorrências através do preenchimento gráfico das regiões dos bairros ou das áreas de atendimento com cores diferenciando a quantidade de Ocorrências. 8.29. Visualização das ocorrências no mapa georeferenciado, iluminando;. 8.30. Mapa termal georeferenciado indicando regiões com concentração de ocorrências. 8.31. Deverá permitir e incorporar a preparação de relatórios gerenciais alfanuméricos que permitam avaliar o desempenho de todas as atividades sob a alçada da Central de Monitoramento, tais como: 8.31.1. Tipos de Ocorrências por dia da semana e horário da ocorrência; 8.31.2. Tipo e Quantidade de Ocorrências atendidas por Grupo de Despacho; 8.31.3. Relatório de Ocorrências: Número de Registro da Ocorrência, Tipo da Ocorrência, Localidade, Área de Atendimento, Grupo de Despacho

designado, Unidades envolvidas no atendimento, data e horário do empenho da unidade, data e horário da chegada ao local de cada uma das unidades, data e horário do término da atividade ou ocorrência e nome dos agentes presentes nas unidades; 8.31.4. Relatório do Controle de Tempo das Ocorrências: tipo e quantidade de ocorrências, tempo médio de atendimento e tempo máximo de atendimento. 8.32. Toda informação deverá permitir ser exportada para diferentes formatos tais como: Adobe portable document format (PDF), Rich-text format (RTF), Microsoft Excel (XLS), comma separated values (CSV), Hypertext Markup Language (html), PlainText. 9. Módulo de Framework Web 9.1. Deve possuir framework básico baseado em HTML5, sendo capaz de aceitar a execução de código baseado em.net ou JEE, via Módulo de Integração de Sistemas e Sensores. 9.2. Deve estar integrado ao Módulo de Visualização, para permitir a customização e ampliação das funcionalidades visuais do sistema. 9.3. Deve permitir nativamente o acesso de dados via web services de acordo com padrões existentes de troca de mensagens como SOAP em protocolo HTTP e HTTPS. 9.4. Deve ser integrado ao Módulo de Visualização, possibilitando o controle das informações e variáveis a serem exibidas ao usuário, permitindo a extensão das funcionalidades deste. 10. Módulo de Integração de Sistemas e Sensores 10.1. Permitir o envio de mensagens de dados a usuários de equipamentos integrados, logados ou não, com textos pré-formatados, livres ou com base em uma ocorrência selecionada, mantendo o histórico de textos e datas em que as mensagens foram enviadas. 10.2. O sistema deve permitir a criação de canais para troca mensagens entre órgãos, clientes e parceiros devidamente autorizados. 10.3. O sistema integrador deve dar suporte às operações da Central de Monitoramento, permitindo a troca de informações e inteligência, seguindo o fluxo definido nos Procedimentos de Resposta, devendo também dar suporte à geração dos relatórios e informes do ritmo diário e promover a interoperabilidade entre diferentes organizações a partir de uma estrutura flexível e rápida de disseminação de informações. 10.4. Permitir o desenvolvimento de conectores de software para integração com sistemas legados ou de organizações externas nas linguagens JEE ou.net, perfeitamente integradas aos demais módulos e, em especial ao Módulo de Framework Web. 10.5. Deve permitir a integração do Sistema de Central de Monitoramento com sistemas, interfaces e bases de dados externas, tais como: 10.5.1. Sistemas de georeferenciamento e map servers; 10.5.2. Bases de conhecimento nacionais e regionais; 10.5.3. Arquivos texto; 10.5.4. Arquivos XML; 10.5.5. Arquivos de imagens (JPG, TIFF/GeoTIFF, BMP, PNG); 10.5.6. Arquivos de áudio (.wav,.wma,.au);

10.5.7. Arquivos ESRI shape, KML, Google Earth, DWG, DGN, DXF e ESRI grid; 10.5.8. Acesso a Web Map Service, Web Feature Service, Geography Markup Language; 10.5.9. Bancos de dados relacionais Oracle, SQL Server, Sybase, DB2, PostgreSQL e MySQL; 10.5.10. Sistemas de dataware house; 10.5.11. Sistemas de BI; 10.5.12. Soluções de ETL; 10.5.13. Web services (POST/GET/REST/SOAP) em protocolos HTTP e HTTPS; 10.5.14. Planilhas eletrônicas (.xls,.xlsx,.ods) e documentos (.doc,.docx,.odf,.pdf); 10.5.15. Sistema gerenciador de eventos;. 10.5.16. Bases de dados SQL acessíveis via OLEDB e ODBC; 10.5.17. Filas de mensagens; 10.5.18. Sockets IP com suporte a TLS/SSL; 10.5.19. Servidores FTP e SFTP; 10.6. As integrações acima podem ser feitas sob demanda, mediante o uso do banco de horas de consultoria, conforme descrito no item 19. 10.7. Deve permitir capacidade de paralelismo e multiprocessamento, permitindo a execução simultânea de fragmentos de código executável. 10.8. Deve permitir a captura automática e pré-agendada de informações em sistemas externos. 10.9. O Módulo de Integração de Sistemas e Sensores deve possibilitar à Central de Monitoramento a utilização de informações disponibilizadas, bem como permitir o seu armazenamento para posterior análise, evitando registros duplicados. 10.10. Possibilitar o versionamento de extrações e tratamento de dados, permitindo a criação de históricos e a extração de relatórios via Módulo de Estatísticas e Relatórios. 10.11. A solução deve permitir a interação das operações dos diversos sistemas integrados, desta forma, permitindo ao operador a análise de informações geradas pelos diversos sistemas de forma única. 10.12. Deve permitir integração com os Módulos de Georeferenciamento e demais módulos, permitindo, por exemplo, a visualização pelo usuário ou operador de câmeras de vídeo associadas a uma ocorrência. 10.13. Deve permitir a inclusão manual e a captura automática de informações que viabilizam a identificação e a localização geográfica das ocorrências, possibilitando a visualização destas informações pelo Módulo de Visualização. 11. Módulo de Mídias 11.1. A solução deve possibilitar acesso para análise automática de fontes de informações como sites pessoais, de instituições, de organizações, de redes sociais, no mínimo para Twitter, Facebook, Youtube, Orkut, Google (Blogs, Notícias e Alertas), Google+, Yahoo! Respostas, Reclame Aqui!, Blogs (WordPress), feeds RSS e possibilitar a identificação de informações em jornais eletrônicos, sítios de notícia e blogs. 11.1.1. A solução deve ser capaz de utilizar bibliotecas externas e específicas para extração das informações na Internet, devendo, no entanto, prover uma

camada de abstração às chamadas de funções e métodos, de forma a permitir a troca destas bibliotecas com um mínimo de esforço de programação. 11.1.2. Se utilizados, o fornecimento de bibliotecas e gateways externos serão de responsabilidade da CONTRATADA. 11.2. A solução deve, minimamente, suportar Web 2.0, anonimidade, normalização de datas e utilização de proxies. 11.3. A CONTRATADA deve prover a programação inicial dos sistemas de coleta, que deve ser configurável pelos usuários. 11.4. A solução deve garantir o armazenamento do histórico dos termos e citações monitorados automaticamente pelo sistema, por meio da manutenção de um banco de dados interno, integrado ao Módulo de Estatísticas e Relatórios. 11.5. Serão monitorados, minimamente, os idiomas, português, inglês e espanhol. 11.6. A solução deve possibilitar a consulta de informações capturadas de forma manual ou automática por filtros, considerando no mínimo: Assunto, Público, Mídia, Data da publicação e Palavra-chave. 11.7. A solução deve gerar relatórios com os dados coletados no monitoramento a qualquer tempo. 11.8. Os relatórios da Solução deverão trazer como resultados as informações minimamente identificadas pelas categorias de filtro existentes. 11.9. Possibilitar na geração dos relatórios a especificação de período-base e o assunto relativos aos eventos, problemas e situações ocorridas. 11.10. A solução deve utilizar metodologia de indexação de matérias, que permita através de uma análise quantitativa e qualitativa, identificar os principais focos abordados pela mídia. 11.11. Obter, dinamicamente, os assuntos e conteúdos e análises através do uso de palavras chave (tags). 11.12. Possibilitar o envio de informações em tempo real, via Módulo de Alarmes e Avisos, para públicos pré-selecionados, ou através de página web 11.12.1. No caso de envio para página web, este poderá ser efetuado via serviços FTP, webservices ou similares, através do uso do Módulo de Integração de Sistemas e Sensores. 11.13. Em caso de falha na comunicação com algum dos provedores de informações, a Solução de Monitoramento de Mídias deverá ser capaz de retomar automaticamente a apresentação das informações quando elas estiverem novamente disponíveis. 11.14. A solução deve disponibilizar respostas automáticas nas diferentes mídias e redes sociais, para agir de forma rápida mediante postagens e demais tipos informações identificadas. Tal recurso deve ser configurável. 11.15. A solução deve também permitir o recurso de postagem em múltiplas mídias sociais, como o twitter e o Facebook. 11.16. A solução deve gerar relatórios com gráficos que permitam uma rápida avaliação do volume de informações monitoradas, mídias identificadas, assuntos, entre outros. 11.17. A solução deve disponibilizar o recurso de exportação de dados em diversos formatos, como por exemplo: CSV, XLS,TXT, HTML, PDF, XML. 11.18. Deve existir um recurso para controle de conteúdo monitorado para inclusão, alteração ou exclusão de assuntos, temas, palavras-chave, mídias, informações monitoradas, entre outros. A inclusão ou a alteração de palavras-chave e termos de clipping deve ser funcionalidade disponível, e as

alterações realizadas devem ser refletidas em tempo real nos mecanismos de monitoração automática. 11.19. A solução deverá oferecer telas customizáveis, indicando de qual rede social, site ou serviço de blog está sendo extraída a mensagem, possibilitando identificar, se tecnicamente viável, o usuário que está publicando a mensagem (post), de modo que caso o usuário não seja identificado, a solução deve permitir o cadastramento do novo usuário a partir da mesma tela de agente. 11.20. A solução deve estar pronta para extrair dados de mídias sociais, provendo abrangência no acesso à informação online, extraindo fontes de dados como: 11.20.1. Twitter, Facebook e Linkedin a partir de suas APIs nativas; 11.20.2. Dados de outras redes sociais a partir de chamadas REST ou web services que podem ser configurados diretamente na aplicação; 11.20.3. Dados de páginas web, como, por exemplo, o site Reclame Aqui, por meio da leitura da estrutura HTTP para localização e extração dos dados que são relevantes. 11.20.4. A extração de dados de mídias sociais pode ser feita de duas formas: 11.20.4.1. Através da configuração de usuário e senha de uma conta associada à CONTRATANTE; 11.20.4.2. Através do uso de gateways ou similares para acesso às últimas mensagens do site ou serviço, identificando aquelas de interesse da CONTRATANTE, através de configuração ou parametrização de algoritmo de análise de semântica. 11.21. A solução deve ainda suportar a definição das palavras-chave: as ferramentas ou serviços devem possibilitar o cadastro de palavras a serem monitoradas para captação das menções feitas por usuários Em um exemplo, pode-se monitorar pelas publicações que envolvam termos como PM, Bombeiro, SAMU, etc. O objetivo é dar foco e captar postagens que possibilitem uma relação ou que sejam úteis para o envio de avisos, via Módulos de Alertas ou mesmo a criação automática de eventos via Módulo de Ocorrências. 11.22. A solução deve prover componentes que desenvolvam a interpretação dos textos a partir da sintaxe das frases, fazendo a segmentação das informações extraídas, eliminando informações que não sejam do interesse da organização/instituição, segmentando sobre qual produto ou serviço que a informação diz respeito, identificando se é uma reclamação ou um elogio entre outras análises. A flexibilidade da solução deverá permitir que ela se adeque rapidamente a gírias e modismos que surgem online buscando interpretar corretamente o que é dito sobre a organização. 12. Módulo de Controle de Acesso 12.1. O Módulo de Controle de Acesso é o responsável pelo cadastro de perfis de usuários e clientes e suas credenciais de acesso ao Sistema da Central de Monitoramento. 12.2. O módulo deverá prover serviços de controle de acesso ao sistema, possibilitando a criação de diferentes perfis de usuário e de acesso, controlando quais informações e as funcionalidades que cada usuário poderá visualizar ou alterar. 12.3. Deve permitir integração com bases de usuários definidas armazenadas com acesso provido pelos seguintes protocolos, componentes de software ou serviços:

12.3.1. LDAP 12.3.2. Active Directory 12.3.3. Bases em SQL(em suas últimas versões correntes): 12.3.3.1. Oracle 12.3.4. IBM DB2 12.3.5. Microsoft SQL Server 12.3.6. Sybase 12.3.7. PostgreSQL 12.3.8. MySQL. 12.3.9. As senhas de acesso serão armazenadas em bases SQL, Active Directory ou em ambiente LDAP na forma de hashs criptográficos sempre que forem tecnologicamente possíveis. 12.3.10. A base de dados de autenticação deve ser multi tenant, habilitando múltiplos órgãos com jurisdições próprias sobre seus usuários e perfis de acesso. 12.4. O sistema deve prover uma configuração padrão de regras e direitos para uma série de tipos de usuários variando desde o administrador do sistema até usuários básicos. 12.5. O sistema deve prover um mecanismo de criar novos tipos de usuários e atribuir direitos específicos e autoridades para os usuários novos criados. 12.6. O sistema deve prover um mecanismo para alterar os direitos associados aos tipos de usuários. 12.7. O sistema deve prover um mecanismo para associar usuários específicos do sistema com ou mais tipos de usuários. 12.8. Permitir definição de perfis de usuários com diferentes níveis de acesso ao sistema: visualizador (apenas leitura), atendentes, despachadores, supervisores e pessoal distribuído em campo com equipamentos móveis. 12.9. Permitir o registro da unidade no sistema, através do login do usuário, com as características associadas. 12.10. Permitir listar e localizar usuários a partir de seu registro, nome completo ou área de atualização, com indicação se está logado ou não, assim como as informações sobre o equipamento remoto utilizado para acesso (ex: desktop, ou mobile). 12.11. Deve permitir que administradores e supervisores especifiquem que informações e ocorrências serão acessíveis e visualizadas pelos usuários pertencentes às suas áreas de responsabilidade. 12.12. Deve permitir funcionalidades de bloqueio de acesso, expiração de senhas e controle da sua complexidade, na forma de quantidade mínima de caracteres que não sejam letras e números, quantidade mínima de letras maiúsculas e minúsculas, e quantidade mínima de numerais que devem estar presentes na senha de acesso. 12.13. Deve ser capaz de permitir a autenticação de usuários com base em certificados digitais padrão ICP Brasil. 12.13.1. Os certificados serão fornecidos pela CONTRATANTE. 12.13.2. Deve ser capaz de assinar digitalmente as entradas de dados e as tomadas de decisão. 12.14. Deve permitir o cadastro de clientes, usuários e parceiros como pontos de contato para o envio de mensagens via módulos e sistemas de integração. 12.15. O sistema deve permitir integração com terceiros via Módulo de Integração de Sistemas e Sensores.

13. Módulo de Auditoria e Logs 13.1. O Módulo de Auditoria e Logs será o repositório principal das informações sobre acessos ao sistema, a delegação de responsabilidades e os dados de desempenho e de operações de todo o conjunto. 13.2. Deve ser construído de forma a proteger os dados inseridos de qualquer modificação. 13.3. Deve permitir a geração de relatórios básicos e a pesquisa por palavraschave e por usuários e sistemas, tanto na forma de remetentes como de destinatários. 13.4. O acesso será definido pelo administrador, e, para tal, será integrado ao Modulo de Controle de Acesso. 14. Módulo de Backup e Versionamento 14.1. Deve ser fornecido componente de software que permita o completo backup e restore de todas as informações pertinentes ao funcionamento e ao histórico de operações da Central de Monitoramento. 14.1.1. O backup das configurações do sistema (incluindo os dados referentes ao controle de acesso) deve poder ser executado em filesystem (local ou remoto) ou ainda utilizando o banco de dados SQL associado à solução. 14.1.1.1. No caso de backup remoto via filesystem, deve ser possível realizar backups e restores via protocolos CIFS e NFS. 14.2. A solução deve permitir visualizar o histórico de backup, permitindo ao operador efetuar o restore para o estado que o sistema se encontrava em determinada data e hora. 14.3. A ferramenta de backup deve permitir realizar backups em modo incremental e total,. 14.4. O backup deve incluir todas as ocorrências e todos os arquivos anexos, tais como mensagens, imagens e vídeos. 14.5. Deve permitir o backup parcial de apenas determinadas informações e de determinados módulos e sistemas. 14.6. Deve permitir o agendamento de backups e a restauração de dados de forma automática 14.7. A solução deve armazenar todos os parâmetros de configuração do sistema, atrelado a um controle de versionamento, de forma que seja possível a restauração do software, dos dados e das configurações a um estado anterior, previamente definido pelo usuário. 15. Módulo de Vídeo Monitoramento 15.1. Solução de sistema de vídeo segurança multiusuário e multi-site, devendo suportar integrações com sistemas de gravação e visualização de câmeras IP, codificadores de vídeo IP, desde que suportado pelo fabricante dos equipamentos, via SDK ou funcionalidade específica para tal. 15.1.1. A integração deverá ser feita diretamente às câmeras de vídeo ou ainda indiretamente, através de equipamentos tipo DVR ou NVR (já existentes) compatível com o fabricante das câmeras de vídeo. 15.2. Deve suportar a integração com sistemas externos de detecção de movimento. 15.3. Deve possuir gerenciamento centralizado em ambiente web, via integração com Módulo de Visualização.

15.4. Deve permitir a visualização ao vivo de câmeras e reprodução com clientes utilizando plataforma móbile (smartphones, tablets, PDAs) e desktops. 15.5. Deve permitir ao usuário a adição de câmeras, a configuração de vídeo e gravação, ajuste de detecção de movimento e configuração do usuário. 15.6. Deve permitir a exibição de Janelas/Layouts: Trabalha com exibições contendo até 10x10 câmeras (com otimização para sistemas com vídeo 4:3, 16:9 e 16:10), Hot spot, Matriz, sequencial, imagens estáticas e ativas, mapas HTML, distribuídos em todos os monitores do computador. 15.7. Deve possobilitar o controle PTZ manual, presets e macros, bem como o patrulhamento em patterns e o controle de limpadores. 15.8. Deve permitir o controle remoto de câmeras por meio de joystick e mesa acoplada ao computador, bem como teclado e mouse. 15.9. Deve prover interface entre as câmeras remotas e o Módulo de Alarmes e Avisos. 15.10. Deve ter suporte a recursos de áudio bidirecional. 15.11. Deve ser integrável a câmeras de vídeo com múltiplos live streams MPEG4 e H.264 e arquivos de vídeo padrão MPEG4. 15.11.1. Deve permitir ao Módulo de Visualização a reprodução de vídeo localmente com até 16 fontes de vídeo em sincronismo. 15.11.2. Linha de tempo de atividade com recurso de lupa. 15.11.3. Provas podem ser geradas com relatório impresso, imagem em JPEG, filme AVI ou no formato de banco de dados nativo. 15.11.4. Exportação de gravações de áudio em formato WAV ou AVI. 15.11.5. Exportação de vídeo digital com zoom para visualizar área de interesse, e para minimizar o tamanho do arquivo exportado. 15.11.6. Exportação de "CD de Evidência" contendo dados nativos e o visualizador. 15.11.7. Opção de criptografia e senha de proteção para as gravações e os arquivos exportados. 15.11.8. Capacidade de adicionar comentários às provas exportadas, também criptografadas. 15.11.9. Opção para enviar provas de vídeo por e-mail. 15.12. Deve estar integrado ao Módulo de Controle de Acesso para autenticação de usuários e acesso às informações e controle das câmeras. 15.13. Deve ser capaz de solicitar a visualização ao vivo em uma taxa de quadros diferentes e em resolução mais baixa que as configurações de gravação. 15.14. Deve possibilitar aplicar configurações individuais ou em grupo para as câmeras (presets, PTZ, algoritmos e taxas de compressão, bem como zonas de detecção). 15.15. Deve ser capaz de trabalhar com equipamentos capazes de detecção de movimento embutida, em tempo real, com sensibilidade completamente ajustáveis e com zonas de exclusão. 15.16. Deve permitir configuração para ativar a gravação com velocidade de frames superior quando é detectado movimento ou quando surge um evento, notificando o alerta por e-mail ou SMS, via integração com Módulo de Alarmes e Avisos. 15.17. Deve ser capaz visualizar imagens de vídeo provenientes de DVRs e /ou NVRs sem a necessidade de encoders ou decoders adicionais.

15.18. Deve possibilitar recurso de selecionar uma localização no mapa e automaticamente trazer fonte de vídeos de câmeras que tenham visibilidade do ponto selecionado. 15.19. Deve prover uma indicação visual refletindo o estado da câmera, se ativa, inativa, não operacional. 15.20. Deve possibilitar recurso de selecionar uma localização no mapa e automaticamente trazer fonte de vídeos de câmeras que tenham visibilidade do ponto selecionado. 15.21. Deve possuir recurso de visão panorâmica do ambiente abrindo todas as câmeras ao redor de uma câmera numa única ação do operador. 15.22. Deve suportar o recurso de salvar e exportar clipes de vídeo de imagens ao vivo ou gravados para distribuição e análise pós- eventos. 15.23. Deve possuir recurso de perseguição de vídeo, onde o operador pode facilmente seguir objetos ou pessoas suspeitas movendo em tempo real, abrindo câmeras adjacentes assim que o objeto ou pessoa sair da visão de uma câmera. 16. Sistema de Análise de Conteúdo de Vídeo 16.1. O Sistema de Análise de Conteúdo de Vídeo deve receber as imagens das câmeras e deverá fazer as tarefas de análise avançada e correlação melhorando a eficiência do vídeo monitoramento com alarmes em tempo real. 16.2. Estas tarefas devem incluir funções como identificação e indexação de imagens, cores, objetos (pessoas, veículos, por exemplo) e velocidade. 16.3. A solução deverá realizar indexação de conteúdo de vídeo destinada a permitir alertas em tempo real, bem como pesquisas mais rápidas e eficientes de vídeo. A arquitetura deve ser aberta e deverá oferecer suporte a correlação de dados provenientes de múltiplas fontes. 16.4. Não deve interferir na gravação de Vídeos pela Rede (Network Vídeo Recorder), permitindo que sejam gravados os vídeos que passaram pela análise de conteúdo. 16.5. Os dados de vídeo deverão ser indexados e poder ser utilizados para várias aplicações. 16.6. Os dados de vídeo devem realizar detecção de danos, identificação de pessoas e ajudar a lidar com requisitos de conformidade regulatória. 16.7. Deve ser capaz de pesquisar por data / hora, consultas ou alertas. 16.8. Deve permitir consultas baseadas em cor, porcentagem da cor, tamanho objeto, tipo de objeto (carro ou pessoas), velocidade do objeto. 16.9. Permitir consultas compostas (por exemplo, todos os carros brancos no centro da cidade desde 2 de janeiro). 16.10. Os padrões deverão ser abertos, permitindo a integração com outros sistemas de TI, sensores e algoritmos e permitindo suportar o uso dos mesmos dados por vários aplicativos. 16.11. Deverá ser controlado via web com as características abaixo: 16.11.1. Visualização de vídeo ao vivo ou reprodução de gravações para 1 a 16 câmeras simultaneamente do mesmo ou diferentes servidores. 16.11.2. Navegação de vídeo avançadas, incluindo reprodução lenta/rápida, salto a data/hora e pesquisa de movimento no vídeo. 16.11.3. Exibições individuais podem ser definidas pelo usuário em vários layouts: exibição ou reprodução de imagens da câmera de vários servidores simultaneamente na mesma vista.

16.11.4. Vistas compartilhadas podem ser geridas centralmente, através do servidor com permissão de administrador, identificado por integração ao Módulo de Controle de Acesso. 16.11.5. Deve integrar-se ao Módulo de Visualização e ao Módulo de Georeferenciamento para o display de mapas para navegação rápida entre câmeras. 16.11.6. Visão geral das seqüências com movimento detectado e janela de visualização. 16.11.7. Visão geral de eventos / alertas. 16.11.8. Controle de câmeras PTZ remotamente, usando também posições prédeterminadas. 16.11.9. Controle remoto de PTZ por clique de mouse em ponto. 16.12. Deve monitorar sinais de vídeo digital em tempo quase real, observar os padrões de comportamento, conteúdo e atividade na cena, desenvolver modelos internos e memórias da cena dos comportamentos que ocorrem dentro dela, com as seguintes características: 16.12.1. O sistema deve refinar continuamente o seu entendimento da cena de vídeo e aperfeiçoar a precisão e a eficiência da detecção, rastreamento, classificação e reconhecimento de comportamento anormal; 16.12.2. O sistema deve aprender padrões de comportamento dos objetos observados dentro da cena; 16.12.3. O sistema deve prover usuários com um mecanismo para definir comportamentos específicos na cena que nunca ou sempre devem ser alertados; 16.13. Os comportamentos aprendidos pelo sistema na cena não devem ser baseados em regras definidas por humanos ou expectativas de comportamentos na cena. 16.14. O sistema deve decidir por ele mesmo como melhor classificar objetos observados na cena. 16.15. O sistema deve otimizar estas classificações do objeto conforme o campo particular de cada câmera usando o critério interno de seu sistema. 16.16. O sistema deve ajustar sua abordagem para classificação sem necessidade de treinamento ou intervenção manual humana. 16.17. O sistema deve manter conjuntos independentes de memórias de classificação e comportamento para cada campo de visão especifica de cada câmera. 16.18. O sistema deve automaticamente reconhecer mudanças no campo de visão e (sem intervenção humana) chavear para o conjunto apropriado de memórias para este campo de visão em particular. 16.19. O sistema deve ser capaz de alertar atividade ou movimento não usual na cena. 16.20. O sistema deve ser capaz de alertar interação não usual entre dois ou mais objetos na cena. 16.21. O sistema deve ser capaz de alertar um trajeto não usual tomado pelo objeto na cena. 16.22. O sistema deve gerenciar mudança no campo de visão para a câmera automaticamente e independentemente, e deve reconhecer quando a cena foi mudada sem intervenção ou reprogramação humana. 16.23. O sistema deve decompor a cena observada separando elementos da cena do primeiro plano (ativos) e do segundo plano (inativos)

16.24. O sistema deve prover uma interface permitindo usuários especificar o nível e tipo de alerta relevante para a visão da câmera escolhida. 16.25. O sistema deve incluir ferramenta forense para proporcionar meios de investigar vídeos gravados recuperando relatórios de incidentes passados. 17. Sistema de Integração de Telefonia 17.1. Deve ser fornecido sistema de integração computador-telefonia, para origem e recebimento de chamados. 17.2. Atender uma chamada telefônica de emergência utilizando diretamente o posto de operador, sem a necessidade de um aparelho telefônico acima da mesa. 17.3. Registrar os dados da chamada telefônica, criando uma ocorrência. 17.4. Permitir que o despachante acione a comunicação via sistema de telefonia existente, diretamente pelo sistema, sem a utilização de nenhum equipamento terminal ou rádio adicional, apenas utilizando o posto de operador. 17.5. Efetue todo o acompanhamento da ocorrência, registrando todas as informações relevantes, com os respectivos logs e gravações das comunicações com as informações de data, hora, e ação executada. 17.6. Permitir que o operador escolha a forma de comunicação com os terminais telefônicos em campo, podendo ser, no mínimo, através de head-sets, microfones de mesa e pedaleira tipo PTT. 17.7. Deve permitir a construção de sistema de atendimento com reconhecimento automático de voz de forma a sintetizar as chamadas permitindo que o cidadão controle o diálogo direcionando para o órgão competente sem perder a qualidade do atendimento. 17.8. Permite geração de relatórios de todas as interações, inclusive em tempo real. 17.9. Gravação integrada com funcionalidade de pesquisa de gravações com suporte a atributos de negócio. 17.10. Suporte aberto via CTI a PABX. 17.11. Capacidade de equalizar a distribuição de chamadas entre os atendentes de um ou mais grupos de atendimento de forma automática, conforme a disponibilidade dos atendentes. 17.12. Possuir sistema de anunciadores e/ou mensagens de fila de espera. 17.13. Permitir a inclusão de mensagem de espera aos cidadãos, informando que todos os atendentes estão ocupados no momento e suas ligações ficarão temporariamente em espera. 17.14. Permitir a realização de escuta passiva e ativa. 17.15. Permitir o bloqueio de ligações recebidas de telefonia móvel, celular e telefonia móvel digital para os números DDG e/ou convencional. Os critérios para bloqueio serão apresentados conforme necessidade da CONTRATANTE. 17.16. Deve prover sistema de gravação digital de mensagens, registrar todas as comunicações entre o público e os atendentes, entre estes e os despachadores, em condições de serem recuperadas. 17.17. Disponibilizar relatórios on-line, com dados do momento (em tempo real), bem como do histórico dos chamados e de cada grupo/skill de atendimento, contendo no mínimo:

17.17.1. Permitir a exibição do status de cada atendente (pausa, indisponível, entre outros disponíveis) e seus motivos (em treinamento, lanche, entre outros disponíveis), bem como a possibilidade de exportar em arquivo o histórico do status dos atendentes; 17.17.2. Quantidade de Posições de Atendimento necessárias nos dias úteis, feriados, sábados e domingos, por turno de serviço, podendo ser ajustado a qualquer instante do período de balizamento. 17.18. Quanto aos requisitos mínimos de níveis de serviço comuns entre o atendimento telefônico de primeiro nível básico por acionamento e por Posição de Atendimento: deverá alcançar a meta para cada indicador de nível mínimo de serviço, conforme apresentado a seguir: 17.18.1. TME (Tempo Médio de Espera): Tempo Médio que um cidadão aguarda na fila de espera antes da ligação ser atendida; 17.18.2. ILA (Índice de Ligações Abandonadas): Percentual de ligações desligadas pelo cidadão antes de ser atendido. Ligações desligadas pelo cidadão durante a mensagem de anúncio da URA (ou similar), é considerada como desistência; 17.18.3. IDS (Índice de disponibilidade do Serviço): Percentual de disponibilidade mensal, POR SERVIÇO, contemplando toda infraestrutura da SPE para o atendimento telefônico 24 (vinte e quatro) horas dia / 07 (sete) dias por semana; 17.18.4. TMD (Tempo máximo para despacho): Tempo Máximo para Despacho de Incidentes; 17.18.5. IQA (Índice de Qualidade do Atendimento): Índice de avaliação da qualidade do atendimento baseado nas gravações, escutas passiva e na descrição do acionamento. Os critérios de avaliação são: 17.18.5.1. Cumprimento do script; 17.18.5.2. Cordialidade no atendimento; 17.18.5.3. Cada atendimento avaliado será considerado como: EM CONFORMIDADE, de acordo com regras parametrizáveis pela CONTRATANTE. Por exemplo, se os dois (02) critérios forem atendidos adequadamente, ou como: EM NÃO CONFORMIDADE, caso um ou mais critérios não sejam atendidos. 17.18.6. SFA (Percentual de Satisfação do Atendimento): Índice de avaliação do usuário quanto a satisfação do atendimento prestado nos atendimentos resolvidos em primeiro nível. Este indicador é aferido com base na resposta do cidadão a-o final do atendimento; 17.18.7. GR (Gravações realizadas): Percentual de gravação dos atendimentos telefônico. 17.19. O Sistema deve possuir recurso de comunicação capaz de enviar e-mail, realizar ligações via sistema de telefonia VOIP SIP e enviar torpedos SMS e de voz. 17.19.1. A integração será realizada por sistemas disponibilizados pela CONTRATANTE, sob demanda e via banco de horas de consultoria, conforme descrito no item 19. 17.20. Deve possuir recurso de rastreamento de mensagens que podem ser filtrados por parâmetros como data/hora de criação, remetente, usuário ou status da mensagem. 17.21. Deve suportar conexão telefone a telefone automaticamente ou por demanda baseado em protocolo SIP.

17.22. Deve fornecer lista de números de telefone eletrônico com recurso de busca, via integração ao Módulo de Controle de Acesso. 17.23. Deve suportar protocolo SIP, permitindo usuário fazer chamada externa SIP do discador de telefone ou iniciar uma chamada SIP para um usuário diretamente do mapa. 17.24. Deve possuir recurso integrado de intercomunicador. 18. Sistema de Controle de Ativos e de Pessoal 18.1. O sistema deve ter módulo integrado de gestão de ativos para inventário a fim de rastrear a localização, bem como monitorar os ativos de uma organização. 18.2. Deve possuir funcionalidade para gestão mínima de pessoal e equipes cujo acionamento seja necessário como resposta a algum evento. 18.3. Deve possuir as seguintes funcionalidades básicas par a ativos: 18.3.1. Administração de todos os tipos de ativos; 18.3.2. Controle de número de série; 18.3.3. Informação se o ativo está disponível para uso imediato ou não; 18.3.4. Processo do tipo workflow para a disponibilidade de ativos; 18.3.5. Controle de alteração de registros de ativos; 18.3.6. Controle de ações corretivas e gestão de problemas; 18.3.7. Administração de incidentes; 18.3.8. Calibrações e manutenções corretivas e preventivas; 18.3.9. Controle de entrada e saída; 18.3.10. Controle do uso de insumos e descartáveis relacionados ao ativo; 18.3.11. Registro de responsáveis pela guarda, manutenção, gerência e administração do ativo; 18.4. Deve possuir as seguintes funcionalidades para a gestão de pessoal: 18.4.1. Entrada e saída; 18.4.2. Gestão de disponibilidade (férias, descanso, afastamentos, via regras definidas); 18.4.3. Construção de organogramas; 18.4.4. Skills, aptidões, conhecimentos e funções. 18.5. Deve permitir definição e manutenção de características das unidades (equipe, viatura, tipo, equipamentos embarcados, etc.). 18.6. Deve permitir a criação de unidades sem equipamentos associados; 18.7. Possibilitar classificação dinâmica de unidades, de acordo com os itens atribuídos, que definirão, inclusive, o formato de apresentação em mapas; 18.8. Permitir que os tipos de ocorrências estejam disponíveis através de cadastro prévio através do Módulo de Ocorrências e do Módulo de Procedimentos Operacionais de Resposta. 18.9. A solução deve possuir uma interface administrativa que possibilite realizar uma carga inicial de todo o inventário de ativos e pessoal, fornecido pelas organizações, a serem gerenciados pelo integrador, bem como elementos georeferenciados estáticos. 18.10. A solução deverá permitir a criação de interfaces, via Módulo de Visualização, para disponibilizar o acesso desses dados aos outros sistemas integrantes Central de Monitoramento.

18.11. Além da posição geográfica também deverão ser fornecidas informações complementares desses elementos, por exemplo: identificação, situação atual (exemplo: disponível, em atendimento, inativo), entre outras. 18.12. As informações de elementos georeferenciados recebidas deverão ser enviadas para o sistema para acesso aos demais módulos integrados. 18.13. A solução permitirá a gestão de recursos, com o devido cadastramento de ativos (recursos) e possibilidade de cadastramento e acompanhamento de pessoal alocado aos eventos; 18.14. Deve ser integrado ao Módulo de Alarmes e Avisos para que seja possível o acompanhamento de eventos selecionados e visualização de agendas. 18.15. Deve ser possível a visualização da agenda do período (dia, semana, mês) contendo os eventos cadastrados e os respectivos impactos na região onde serão realizados os eventos, através do Modulo de Georeferenciamento; 18.15.1. Permitirá a análise de conflitos de agenda entre os eventos assim como de participantes alocados em mais de um evento; 18.15.2. Deverá controlar a geração de escalas de trabalho, permitindo a geração automática das escalas baseadas em critérios especificados sendo que as escalas geradas deverão poder ser editadas manualmente e modificadas a qualquer tempo até a data de início da escala. 18.16. A solução disponibilizará, para extração, relatórios gerenciais e analíticos que contenham os dados de um determinado evento ou comparativos de um ou mais eventos, incluindo gráficos 18.17. Deve ser multi tenant, habilitando o uso multi-site e em múltipla hierarquia; 19. Serviços de Consultoria (Banco de Horas) 19.1. Os serviços serão prestados pela empresa vencedora, contados a partir da assinatura do contrato, compostos de: 19.1.1. Serviços de confecção do projeto de implantação, modelagem, desenvolvimento, instalação e implantação da solução que deverão ser executados em até 10 (dez) meses, compreendendo: 19.1.1.1. Confecção do Projeto de Implantação 19.1.1.2. Coordenação e suporte a estruturação física e lógica dos ambientes da Central de Monitoramento 19.1.1.3. Modelagem dos processos de negócio 19.1.1.4. Modelagem de banco de dados Modelagem de banco de dados Geográficos e carga de dados 19.1.1.5. Configuração de hardware e software da solução 19.1.1.6. Instalação e configuração do software 19.1.1.7. Testes e validação das integrações 19.1.1.8. Controle de qualidade dos dados 19.1.2. Go Live (data formal de início de utilização da solução de software implantada em ambiente de produção de TI e de operação da CONTRATANTE) 19.1.2.1. A CONTRATADA deverá prover odo o suporte e informações para a execução das atividades técnicas necessárias à implantação da solução completa em ambiente de produção e de suas integrações com outros sistemas e para verificação do perfeito funcionamento de todos os módulos no ambiente de operação da CONTRATANTE.

19.1.3. Serviço de Operação Assistida, executado por 2 meses, após a implantação da solução em ambiente de produção (Go Live), no ambiente da CONTRATANTE. 19.1.3.1. A CONTRATADA deverá elaborar um roteiro completo com os procedimentos para atender a sustentabilidade do ambiente de Produção. 19.1.3.2. Este roteiro deverá ser executado em caso de falha de um servidor ou defeito de software (por exemplo: roteiro para ativação do ambiente de homologação em substituição ao da Produção, dentro das condições de desempenho desse ambiente). 19.2. Os serviços serão contratados mediante a emissão de cronograma contendo a estimativa de esforço a ser dispendido pela CONTRATADA. 19.3. Uma vez aprovado cronograma, a CONTRATANTE emitirá as ordens de serviços que se fizerem pertinentes. 20. Serviços de Treinamento e Transferência de Tecnologia 20.1. A implantação da solução inclui as atividades de transferência de conhecimento e disponibilização de documentação técnica e operacional acerca das soluções, acessórios e procedimentos. 20.2. Disponibilização de transferência de conhecimento presencial relacionado à operação cotidiana, ao suporte básico, à administração e à configuração das soluções. Sendo necessária composição de transferência de conhecimento específica para, no mínimo, 4 (quatro) grupos de até 30 (trinta) alunos, conforme especificado: 20.2.1. Grupo Gestão, composto por colaboradores de administração e coordenação da Central de Monitoramento, com pelo menos 4 (quatro) horas*aula, contemplando: 20.2.1.1. Funcionalidades gerais de operação. 20.2.1.2. Visão geral de gestão de eventos e riscos. 20.2.1.3. Operação básica (informações de cadastros, ações e agenda, entre outros) 20.2.1.4. Cadastro de novos eventos, recursos, planos de ação, rotas, riscos, pessoas; 20.2.1.5. Utilização de recursos de Workflow; 20.2.1.6. Integração com sistemas de georeferenciamento; 20.2.1.7. Extração de relatórios gerenciais e analíticos; 20.2.2. Grupo operacional, composto por colaboradores de operação cotidiana da solução, de pelo menos 16 (dezesseis) horas*aula, contemplando: 20.2.2.1. Operação básica (informações de cadastros, ações e agenda, entre outros) 20.2.2.2. Cadastro de novos eventos, recursos, planos de ação, rotas, riscos, pessoas; 20.2.2.3. Utilização de recursos de Workflow; 20.2.3. Grupo técnico e de manutenção, composto por colaboradores técnicos das áreas de operações de TI e infraestrutura, com pelo menos 8 (oito) horas*aula, contemplando: 20.2.3.1. Instalação e configuração do sistema e as ferramentas fornecidas. 20.2.3.2. Incluir e remover usuários e grupos. 20.2.3.3. Realizar tarefas de manutenção de suporte de primeiro nível 20.2.3.4. Utilização de funcionalidades de georeferenciamento 20.2.3.5. Detecção e correção de problemas 20.2.3.6. Tuning

20.2.4. Grupo de desenvolvimento, composto por colaboradores técnicos da área de desenvolvimento de software e componentes integráveis à solução, contemplando um mínimo de 40 (quarenta) horas*aula, com os seguintes tópicos: 20.2.4.1. Introdução ao framework; 20.2.4.2. Modelo de dados; 20.2.4.3. Extensão de funcionalidades do framework de integração; 20.3. Deve ser previsto o fornecimento de documentação em Português Brasileiro da solução e dos treinamentos, contemplando: 20.4. Manuais impressos e procedimentos de usuários; 20.5. Descritivo de funcionalidades, 20.6. Detalhamento de operações de sistema e indicativo de simbologias utilizadas; 20.7. Desenhos dos componentes de hardware, software e redes de comunicação. 20.8. Documentos com a descrição dos processos internos da solução e estruturas de dados relevantes; 20.9. Documentação das configurações contidas no pacote de software. 20.10. Documentação de especificações funcionais e desenvolvimentos adicionais. 20.11. Recursos de treinamento como e-learnings, tutoriais e guias passo a passo; 20.12. Documentação de servidores, banco de dados, versões de produtos, componentes lógicos e componentes de software; 20.13. Manuais e procedimentos de suporte; 20.14. Manuais e procedimentos técnicos e operacionais, em Português Brasileiro 20.15. ou em inglês, disponíveis em arquivos eletrônicos, contendo, pelo menos, informações sobre procedimentos técnicos necessários, catálogo de mensagens de sistema comuns e ações corretivas necessárias, catálogos de funcionalidades, dicionário de dados, descritivo de interfaces, diagramas de conexões, características técnicas e requerimentos legais. 21. Garantia, Suporte e Manutenção 21.1. O objeto deste Termo de Referência também contempla o suporte técnico e a manutenção das soluções e sistemas fornecidos 21.2. Por todo o período de contrato, e até 12 meses após o fim do período de operação assistida, a CONTRATADA deve prover suporte técnico especializado, garantindo alta disponibilidade e desempenho das plataformas tecnológicas em operação. 21.3. Deve atender prontamente correções e alertas derivados da ferramenta de monitoração do ambiente tecnológico. 21.4. Deve proceder a atualização da base de conhecimento de suporte: acompanhar a revisão e atualização dos procedimentos operacionais (documentos), pesquisando novas soluções, analisando criticamente os processos e propondo melhorias, solicitar procedimento aos fornecedores. 21.5. Deve interagir com fornecedores e parceiros para resolução, tratativa e acompanhamento das soluções de incidentes e problemas. 21.6. A CONTRATADA é obrigada a reparar, corrigir, remover, reconstruir ou substituir, às suas expensas, no total ou em parte, o objeto do contrato em que se verificarem vícios, defeitos ou incorreções resultantes da execução ou de materiais empregados.

21.7. A garantia inclui todas as ações de manutenção corretiva, com vistas a garantir o total funcionamento da solução, a saber: 21.7.1. Defeitos de software; 21.7.2. Assistência na determinação de problemas; 21.7.3. Questões específicas de uso e instalação de curta duração para funções documentadas; 21.7.4. Perguntas sobre compatibilidade de produtos e componentes de software; 21.7.5. Auxílio na interpretação de publicações oficiais da solução; 21.7.6. Pesquisas nos bancos de dados de problemas/soluções da solução. 21.8. Durante o período de garantia, a CONTRATADA deverá atender todo e qualquer chamado, relacionado ao funcionamento da solução, que venha a receber da CONTRATANTE, e resolver o problema no menor prazo possível, a contar da abertura do chamado técnico, 21.9. O início do atendimento não poderá ultrapassar o prazo de 02 (duas) horas, contado a partir da abertura do chamado pela CONTRATANTE. 21.10. Uma vez que a solução do problema tenha sido enviada pela 21.11. CONTRATADA e testada pela CONTRATANTE, estando esta e a CONTRATADA em conformidade com o encerramento do chamado, os especialistas da CONTRATADA finalizam o atendimento. 21.12. Caso o INEA não possa testar a solução no curto prazo, a CONTRATADA deverá colocar o chamado em stand-by deixando-o disponível para reabertura por um período de até 30 (trinta) dias em caso de dúvida futura. 21.13. A garantia deverá ser prestada, observando as seguintes condições: 21.13.1. Fornecimento e substituição de componentes que apresentarem defeitos, identificados dentro das condições normais de operação ou que necessitarem reposição em virtude da evolução de outros componentes da solução; 21.13.2. Os chamados de acionamento da garantia deverão ser abertos por meio de central de abertura de chamados, a partir de número 0800 ou número local do Município de São Paulo, com atendimento telefônico, de segunda a sexta-feira, em horário comercial (das 09:00hs às 18:00hs), exceto feriados, para qualquer tipo de dúvida ou problema, atendimento telefônico, vinte e quatro horas por dia, sete dias por semana, para problemas críticos considerados de Severidade 1 ou 2; 21.13.3. O momento da abertura do chamado deverá ser fornecido para a CONTRATANTE um número único de identificação do chamado; 21.13.4. Os dados dos chamados, bem como das providências tomadas, devem ser armazenados em sistema da CONTRATADA para controle de chamados. Esse sistema deverá estar disponível ao acesso da CONTRATANTE e ter capacidade de apresentar número do chamado, data e hora de abertura, nome da pessoa que abriu e do técnico alocado, descrição dos problemas, bem como dados das atividades executadas, data e hora de fechamento do chamado e solução aplicada; 21.13.5. Iniciar o atendimento telefônico em até 2 (duas) horas, após a comunicação do problema pela CONTRATANTE, que classificará os problemas reportados de acordo com seu grau de severidade, segundo a seguinte classificação: 21.13.5.1. Para os casos de severidade 1, se o suporte de nível 1 não conseguir resolver o problema até três horas após a abertura do chamado, o chamado deverá ser escalado e poderá chegar até a equipe de laboratório responsável pelo produto.

21.13.6. Para os casos de severidade 2, se o suporte não conseguir resolver o problema em até 6 (seis) horas após a abertura do chamado, este deverá ser escalado e poderá chegar até a equipe de laboratório responsável pelo produto. 21.14. A critério da CONTRATANTE, um chamado poderá ser escalado para nível de severidade diferente do originalmente aberto e será considerado o nível de serviço do novo nível, a partir do momento da escalação. 21.15. Com exceção de parada programada e acordada previamente com a CONTRATANTE, de no máximo 12 (doze) horas, nenhuma manutenção deverá acarretar indisponibilidade da solução. 21.16. Os chamados somente poderão ser fechados após autorização do gestor do contrato. 21.17. Mensalmente, quando houver acionamento da garantia, a CONTRATADA deverá encaminhar à CONTRATANTE relatório com todos os chamados de manutenção abertos e fechados, contendo os detalhes de abertura e fechamento do chamado e da solução aplicada. 21.18. A prestação dos serviços relacionados a suporte e manutenção durante o período de garantia e respectivas condições de atendimento informadas neste documento deve ser de responsabilidade da CONTRATADA. 22. Quantitativos, volumes e níveis de serviço (SLA) 22.1. Os dados aqui apresentados devem ser considerados como quantitativos iniciais mínimos para instalação. 22.2. As licenças de software não devem possuir restrições para número de usuários nem em número de servidores (ou de processadores). Ambiente Número.de usuários Número de usuários simultâneos Número de ocorrências por dia Desenvolvimento 100 10 500 97% Homologação 50 5 100 97% Produção I 1000 100 35.000 99% Produção II 1000 100 35.000 99% (redundância) Treinamento 20 20 200 97% SLA mínimo do ambiente Módulo Ocorrências Procedimentos Operacionais de Resposta Atendimento e Despacho Georreferenciamento Alarmes e Avisos Estatísticas e Relatórios Framework web Integração de Sistemas e Sensores Mídias Valor

Controle de Acesso Vídeo Monitoramento Auditoria e Logs Backup e versionamento TOTAL Sistema Sistema Controle de Ativos e Pessoal Sistema de Análise de Conteúdo de Vídeo Sistema de Telefonia Serviços de Consultoria (banco de horas) Unidade de medida Quantidade Valor Unitário Valor Total - 1 Streams de vídeo 300 Links E1 10 Horas de trabalho 8000 (oito mil) Treinamento Turmas de 20 alunos Transferência de Turmas de 5 Tecnologia alunos Operação Mês Assistida Garantia, suporte e manutenção 5 (cinco) 2 (dois) 3 (três) Mês 36 (trinta e seis) 23. Projeto e primeira implantação 23.1. A primeira implantação corresponde à instalação do objeto contratado e a realização de integrações com sistemas pré-existentes, de posse ou de responsabilidade da CONTRATANTE, ou ainda de seus parceiros. 23.1.1. A primeira implantação deverá ser realizada em prazo não superior a 90 (noventa) dias após a assinatura do contrato. 23.1.2. Os sistemas pré-existentes a serem integrados à Central de Monitoramento e os requisitos da primeira implantação serão definidos em comum acordo com a CONTRATANTE, de forma que os prazos sejam exeqüíveis. 23.1.3. A primeira implantação será realizada em ambiente disponibilizado pela CONTRATANTE, na forma de: 23.1.3.1. Servidores físicos ou virtuais do tipo compatível com arquitetura 80x86; 23.1.3.2. Sistema operacional: Microsoft Windows Server, RedHat Linux ou CentOS; 23.1.3.3. Bases de dados: SQL Server, Oracle, DB2, PostgreSQL ou MySQL;

23.1.3.3.1. As bases de dados serão disponibilizadas em duas formas: acesso a uma instalação corporativa, ou instalações em hardware dedicado (a depender dos critérios técnicos de capacidade e disponibilidade); 23.1.3.4. Área de armazenamento (storage). 23.1.3.4.1. O armazenamento será oferecido na forma de SAN via interfaces HBA Fibre Channel em servidores dedicados ou NAS, nos protocolos CIFS e NFS. 23.2. A CONTRATADA será responsável pela elaboração de Projeto de Implantação, contemplando: 23.2.1. Cronograma geral e prazos para execução; 23.2.2. Cronograma detalhado (WBS) com indicação dos responsáveis pelas atividades e respectivos prazos; 23.2.3. Requisitos de hardware, software básico (sistemas operacionais, servidores web e banco de dados) e de comunicação; 23.2.4. Formalização dos prazos máximos para a entrega dos equipamentos, dos serviços de banco de dados (por meio de servidores dedicados ou pelo acesso a servidores corporativos) e das áreas de armazenamento; 23.2.5. Carga inicial do sistema e operações de transferência de dados ou de ETL que se fizerem necessárias; 23.3. As atividades referentes à elaboração do planejamento da primeira implantação fazem parte do escopo de contratação, incluindo: 23.3.1. Participação de reuniões; 23.3.2. Gestão de atividades; 23.3.3. Gestão de pessoas; 23.3.4. Desenvolvimento; 23.3.5. Administração de sistemas; 23.3.6. Instalação de software 23.3.7. Análise de requisitos; 23.4. A confecção do planejamento e a execução das atividades dele originadas será sujeita à utilização do Banco de Horas contratado, podendo incluir aqui as seguintes atividades: 23.4.1. Desenvolvimento; 23.4.2. Customização; 23.4.3. Instalação de software; 23.4.4. Sizing; 23.4.5. Otimização e tuning; 23.4.6. Carga e processamento de dados (ETL); 23.4.7. Gestão de projetos e de pessoas; 24. Papéis e Responsabilidades 24.1. No decorrer da execução deste contrato, cabe à CONTRATADA: 24.1.1. A elaboração e execução do Projeto de Implantação, contemplando: 24.1.1.1. A elaboração de cronograma de implantação e work breakdown structure (WBS); 24.1.1.2. A elaboração de descritivo completo da arquitetura mínima necessária ao Sistema, composta de hardware e software básico, para os ambientes de

desenvolvimento, homologação, produção I, produção II (contingência) e treinamento; 24.1.1.3. A elaboração da documentação referente ao desenvolvimento, tais como casos de uso; diagrama de classes; diagrama de chamadas; padrões de nomenclatura de variáveis, funções, métodos e classes; 24.1.2. O Projeto de Implantação e a sua execução devem levar em consideração fatores tais como: 24.1.2.1. A oferta ou a capacidade disponível de equipamentos, sistemas e serviços no tempo de execução do Projeto; 24.1.2.2. O tempo para a aquisição de insumos que não estejam prontamente disponíveis; 24.1.2.3. A minimização de custos de aquisição (tais como o software e hardware) e de manutenção (por exemplo, energia e ar condicionado), visando uma solução que apresente melhor economicidade; 24.1.2.4. O completo atendimento dos requisitos, dos níveis de serviço e da volumetria mensurada ou definida; 24.1.3. A elaboração da documentação de instalação e uso do Sistema; 24.1.4. A carga inicial do Sistema da Central de Monitoramento 24.1.5. O fornecimento de assistência e consultaria para a implantação do Sistema; 24.1.6. O treinamento inicial de usuários e replicadores; 24.1.7. Assegurar a completa transferência de tecnologia utilizada no Sistema; 24.1.8. A cessão de direitos para a CONTRATANTE sobre o sofware desenvolvido, permitindo a manutenção do mesmo por esta última; 24.2. A CONTRATANTE será responsável por: 24.2.1. Disponibilização da infraestrutura física, lógica e hardware 24.2.1.1. Cabeamento físico, switches, roteadores, links e conectividade; 24.2.1.2. Disponibilização e administração de servidores padrão x86, sua instalação física e hospedagem; 24.2.1.3. Storage SAN, via HBA do tipo Fibre Channel; 24.2.1.4. Storage NAS, nos protocolos CIFS e NFS; 24.2.1.5. Ambiente de datacenter com infraestrutura de energia elétrica, refrigeração (condicionamento de ar), segurança física, lógica e controle de acesso; 24.2.1.6. Gestão da configuração e capacidade. 24.2.2. Software básico, composto por: 24.2.2.1. Sistema Operacional: Microsoft Windows Server, Linux (RHES ou CentOS); 24.2.2.2. Servidores web: IIS em ambiente Windows e Apache em ambiente Linux; 24.2.2.3. Bancos de Dados (SQL Server, Oracle, DB2, PostgreSQL, e MySQL) 24.2.3. Tarefas associadas ao Projeto de Implantação: 24.2.4. Consulta aos parceiros e clientes para o mapeamento das informações referentes à criação do Projeto de Implantação; 24.2.5. Definição das integrações iniciais necessárias;

24.2.6. Disponibilizar os ambientes de desenvolvimento e homologação, segundo a arquitetura aprovada definida no Projeto de Implantação e aprovada pela própria CONTRATANTE. 24.2.7. Aprovação final do Projeto de Implantação; 25. Cronograma de Entrega 25.1. Deve ser seguido o seguinte cronograma-macro, com início na data de assinatura do contrato. 25.1.1. Alterações podem ser feitas, se aprovadas pela CONTRATANTE. Atividade Sizing Projeto Piloto (Chuvas de Verão) Implantação Projeto Piloto Treinamento Implantação Central Prazo (a partir da assinatura do contrato) 15 dias 90 dias 120 dias 180 dias

ANEXO A PROJETO PILOTO

PREFEITURA DO MUNICIPIO DE SÃO PAULO SECRETARIA DE COORDENAÇÃO DAS SUBPREFEITURAS Coordenadoria Municipal de Defesa Civil -COMDEC PLANO CHUVAS DE VERÃO PRINCIPIOS, FLUXOS E PROCEDIMENTOS 1ª VERSÃO. 1. Introdução No período do verão a ocorrência de eventos pluviométricos ganham maior freqüência e são agravados, entre outros aspectos, pelas mudanças climáticas e pelo próprio processo de estruturação das grandes cidades. Este quadro, somado a ocorrência destes eventos, aumenta consideravelmente a vulnerabilidade da Cidade de São Paulo aos riscos ambientais relacionados às chuvas, como os escorregamentos e os alagamentos/enchentes, acarretando, muitas vezes, em decorrência de extremos climáticos, transtornos a população. Neste sentido, torna-se necessária a adoção de uma política pública que priorize a implantação de um gerenciamento permanente baseado em dois eixos de ação: prevenção e preparação. Como resposta a esta necessidade, a Prefeitura do Município de São Paulo está estabelecendo um plano preventivo para o gerenciamento de riscos associados ao período crítico de pluviosidade na cidade denominado Plano Preventivo Chuvas de Verão. Este plano, que tem com objetivo principal a redução ou a minimização dos efeitos e consequências destes riscos sobre a população, é pautado pela integração de todos os órgãos de administração pública; otimização de recursos; definição de procedimentos, atribuições e responsabilidades; fluxos de comunicação e informação pública, além de envolver a população na operação do Plano, especialmente os moradores de áreas de risco de escorregamentos e enchentes. A Prefeitura entende que a implantação deste plano, que está dentro das diretrizes na nova Política Nacional de Proteção e Defesa Civil (Lei Federal nº

1.2608/2012) irá fortalecer a cultura permanente do gerenciamento destes riscos que é essencial para que a população tenha melhores condições para enfrentar o período de chuvas deste próximo verão. A ação integrada, no entanto, deve ser somada aos investimentos na infraestrutura da cidade, através de obras de drenagem, canalização, serviços de conservação e limpeza e outras intervenções não-estruturais (reflorestamento, ampliação de áreas permeáveis, remoção de moradias em planícies de inundação, etc). 2 Órgãos envolvidos O Plano Chuvas de Verão procura envolver todos os órgãos da administração municipal. Todavia alguns órgãos possuem uma ação mais direta com funções e procedimentos definidos, onde relacionamos: 2.1 Órgãos da Administração Municipal 1. Secretária Municipal de Coordenação das Subprefeituras SMSP através da Coordenadoria Municipal de Defesa Civil e o Centro de Controle Integrado CCOI, que possuem centrais de comunicação que serão unificadas, e as Coordenadorias Distritais de Defesa Civil CODDECs., organizadas por subprefeituras e que possuem como canal de comunicação as salas de estratégias ou salas de rádio; 2. Secretária Municipal de Segurança Urbana SMSU através da Guarda Civil Metropolitana que possui uma central de comunicação CETEL central 153; 3. Secretária Municipal de Infraestrutura Urbana e Obras SIURB através do Centro de Gerenciamento de Emergências CGE., que é responsável pelo monitoramento e disseminação de informações relativas a situação meteorológica da cidade. 4. Secretária Municipal de Transportes SMT através da Companhia de Engenharia de Tráfego que possui uma central de informações

5. Secretária Municipal de Assistência e Desenvolvimento Social SMADS através da CAPPE que é uma central de atendimento a emergências; 6. Secretária Municipal da Saúde SMS, através do CIEVS ( Centro de Informações Estratégicas em Vigilância em Saúde); do Serviço Médico de Urgência SAMU CENTRAL 192; Centro de Controle de Zoonoses - CCZ.; 7. Secretária Executivo de Comunicação - SECOM; 2.2. Órgãos da Administração Estadual 2.2.1 Ação Direta a ocorrências 1. Corpo de Bombeiros Central 193 ação direta no atendimento a emergências/ busca e salvamento 2. AES Eletropaulo também possui uma central e tem interface nas ocorrências relacionadas a queda de arvores; 2.2.2 Ação suplementar e eventual a ocorrências 1. Companhia de Saneamento Básico no Estado de São Paulo SABESP atua em ocorrências que envolvam a rede de distribuição, com destaque para adutoras; 2. Companhia de Gás de São Paulo - COMGÁS - atua em ocorrências que envolvam a rede de distribuição, com destaque para a rede de distribuição de gás natural; 3. Petrobrás Transportes S.A TRANSPETRO - atua em ocorrências que envolvam a rede de distribuição, com destaque para os dutos de distribuição de combustíveis (gasolina diesel, GNV); 4. Companhia do Metropolitano de São Paulo fluxo de informações sobre a situação meteorológica e estado de criticidade na cidade para balizamento de eventuais ações que envolvam o transporte;

3. Companhia de Trêns Metropolitanos CPTM - fluxo de informações sobre a situação meteorológica e estado de criticidade na cidade para balizamento de eventuais ações que envolvam o transporte; 4. Empresa Metropolitana de Transportes Urbanos EMTU - fluxo de informações sobre a situação meteorológica e estado de criticidade na cidade para balizamento de eventuais ações que envolvam o transporte; 5. SOCICAM Terminais Rodoviários do Tietê, Jabaquara e Barra Funda - fluxo de informações sobre a situação meteorológica e estado de criticidade na cidade para balizamento de eventuais ações que envolvam o transporte; 6. Agência de Transporte no Estado de São Paulo ARTESP - fluxo de informações sobre a situação meteorológica e estado de criticidade na cidade para balizamento de eventuais ações das concessionárias de rodovias (Via Oeste; Ecovias; Autoban etc) com relação a situação de circulação e ingresso de veículos via rodoviária na cidade de São Paulo; 3. CRITÉRIOS TECNICOS PARA DEFLAGRAÇÃO DOS ESTADOS DE CRITICIDADE DO PLANO O CGE tem como responsabilidade a previsão do tempo, monitoramento das condições meteorológicas e pluviométricas e a indicação dos estados de criticidade para escorregamentos, alagamentos e enchentes. Os estados de criticidade, estarão vinculados á gravidade do risco, seguindo critérios técnicos, previamente estabelecidos e estarão balizando todo o andamento do plano. A partir daí todos os órgãos participantes do plano adotarão os procedimentos correspondentes as suas funções e responsabilidades e que estão apresentados nos conteúdos dos respectivos grupos temáticos. Os estados de criticidade do PLANO PREVENTIVO CHUVAS DE VERÃO e os procedimentos correspondentes a serem adotados serão determinados pelo índice pluviométrico, pela previsão meteorológica e pelos indicadores de

campo e serão decretados por Subprefeitura no caso de enchentes e escorregamentos e, também, por Gerência de Engenharia de Trafego GET/CET no caso de enchentes. A partir daí o CGE analisa e indica os estados de criticidade para os cenários relacionados a escorregamentos, enchentes e alagamentos, sendo que em algumas situações será emitido um pré-aviso de tempo severo. Este pré-aviso tem como objetivo fornecer aos órgãos participantes do plano, dentro da antecedência possível e das condições significativas de chuva, informações sobre a situação da cidade. OBSERVAÇÃO ATENÇÃO ALERTA ALAGAMENTOS Todo o período de vigência do Plano. Chuva com potencial de alagamento. Alagamentos generalizados intransitáveis e continuidade das chuvas. ALERTA MÁXIMO Alagamentos generalizados intransitáveis, associados a extravasamento de rios e córregos, dimensão do evento supera a capacidade de atendimento do município gerando forte impacto nos sistemas de trânsito e transporte, necessitando do apoio de instituições federais e/ou estaduais. OBSERVAÇÃO ATENÇÃO ALERTA ALERTA MÁXIMO INUNDAÇÕES Todo o período de vigência do Plano. Chuva com potencial de transbordamento dos córregos ou rios e previsão de continuidade das chuvas nas cabeceiras. Transbordamento dos córregos e rios e continuidade das chuvas nas cabeceiras. Transbordamentos de rios e córregos generalizados e a dimensão do evento supera a capacidade de atendimento do município, necessitando do apoio de instituições federais e/ou estaduais. OBSERVAÇÃO ATENÇÃO ALERTA ALERTA MÁXIMO ESCORREGAMENTOS Todo o período de vigência do Plano. Chuva acumulada de 50mm em 72 horas e previsão de continuidade das chuvas e necessidade de remoções. Escorregamentos generalizados com previsão de chuvas moderadas e fortes, necessidade de remoções. Dimensão do evento supera a capacidade de atendimento do município, necessitando do apoio de instituições federais e/ou estaduais.

3.1 FLUXOS PARA DECRETAÇÃO DOS ESTADOS DE CRITICIDADE A indicação dos estados de criticidade relativos aos alagamentos, enchentes e escorregamentos ficará sob a responsabilidade do CGE, sendo que a decretação dos estados de criticidade respeitarão os seguintes prodedimentos: 3.1.1 ALAGAMENTOS A decretação dos estados de criticidade relativos a alagamentos de vias, por questões de agilidade e de informações de campo fornecidas pelos agentes da Companhia de Engenharia de Tráfego CET, ficará sob a responsabilidade do Centro de Gerenciamento de Emergências CGE que informará a Central de Operações da Companhia de Engenharia de Tráfego CET e os demais órgãos participantes do plano; 3.1.2. ESCORREGAMENTOS E ENCHENTES A decretação dos estados de criticidade relativos a escorregamentos e enchentes, a partir da indicação do Centro de Gerenciamento de Emergências CGE ficará sob a responsabilidade da Coordenadoria Municipal de Defesa Civil COMDEC através do seu Centro de Comunicações CECOM 199 que deverá informar as respectivas Coordenadorias Distritais de Defesa Civil CODDECs das Subprefeituras e os demais órgãos participantes do presente plano de acordo com as diretrizes e fluxos pré-estabelecidos. 4. FLUXOS DE ATENDIMENTO DE OCORRÊNCIAS POR PARTE DAS COORDENADORIAS DISTRITAIS DE DEFESA CIVIL - CODDECs Nas Coordenadorias Distritais de Defesa Civil CODDECs, organizadas por subprefeituras, os fluxos de atendimento as respectivas ocorrências deverão ser adequados as respectivas realidades, ressaltando que as ocorrências também poderão ter sua entrada através das salas de rádio instaladas em cada subprefeitura:

4.1 ENCHENTES A partir da entrada de uma ocorrência relacionada a enchentes o CECOM 199 entra em contato com as respectivas subprefeituras (CODDECS) através das salas de rádio ou de situação, dependendo da organização local e informa todos os dados relativos a ocorrência para atendimento por parte do respectivo CODDECs.. 4.2 ESCORREGAMENTOS. A partir da entrada de uma ocorrência relacionada a escorregamento o CECOM 199 entra em contato com as respectivas subprefeituras (CODDECS) através das salas de rádio ou de situação, dependendo da organização local e informa todos os dados relativos a ocorrência para atendimento por parte do respectivo CODDECs..

4.3 QUEDAS DE ÁRVORES A partir da entrada de uma ocorrência relacionada à queda de arvores o CECOM 199 entra em contato com as respectivas subprefeituras (CODDECS) através das salas de rádio ou de situação, dependendo da organização local e informa todos os dados relativos a ocorrência para atendimento por parte do respectivo CODDECs..