Re: Re.: ARLA/CLUSTER: SIRESP: Não à possibilidade de multar a empresa que detém o sistema de comunicações de segurança, o contrato permitia que houvesse uma indisponibilidade de 69.456 horas..
João Costa > CT1FBF
ct1fbf gmail.com
Quarta-Feira, 10 de Abril de 2019 - 20:12:39 WEST
Eu acho que estás a ser muito optimista, Pedro.
Eu aposto na inversa, uma hora em 10 torres corresponde a uma sô hora no
contrato.
Um contrato "leonino" (os sportingistas não são para aqui chamados)
deveria em bom rigor poder ser repudiado. Por mais voltas que se possa dar
ao texto ), a unica solução razoavel é a nacionalização.
João Costa (CT1FBF)
A qua, 10/04/2019, 19:20, Pedro Ribeiro <ct7abp gmail.com> escreveu:
> Deduzo que as horas sejam a soma da indisponibilidade em vários pontos
> (torres??) da infraestrutura.
>
> Se 10 torres estiverem simultaneamente inativas durante 1h contarão 10h na
> contabilização (ou algo do género ...)
>
> 73!
> On 2019/04/10 14:03, Jorge Santos wrote:
>
> Não entendo o raio deste relatório. Se as horas que o SIRESP pode falhar
> são 69.456, que se a calculadora não está errada dá 2894 dias, e se um ano
> não bissexto tem 365 quer dizer que temos um sistema de segurança nacional
> que pode estar parado quase *8 anos*, boa...
> Ou as 69.456 horas de downtime são para dividir pelo tempo de contrato??
> nesse caso o contrato é de quantos anos, será que é de 8?.
> Com base nas informações procurei pelo contrato SIRESP disponÃvel em:
> http://www.utap.pt/Contratos/seguranca/SIRESP.pdf e depois de o "lamber"
> todo concluà que precisava dos anexos,
> http://www.utap.pt/PPP%20Seguranca/SIRESP/Contrato%20em%20vigor/Anexos/Siresp_contrato_anexos.htm,
> são 47, estranhamento o
> Anexo 29
>
> Procedimento de aferição das deduções por Falhas de Disponibilidade e por
> Falhas de Desempenho(1)
> que define as responsabilidades é um dos não possÃveis de visualização
> suponho que por ter lá aquele (1) (hehehehe).
> Com toda a transparência, existem coisas que não podem ser
> transparentes..., mas não me lixem *69.456* H de downtime.
>
>
> Ai mãezinha.....
>
> On Wed, 10 Apr 2019 at 12:44, ct1hix <ct1hix sapo.pt> wrote:
>
>> Politiquices!!!! :(
>>
>> 73 de Gomes op: CT1HIX
>> https://ct1hix.net/
>>
>>
>> -------- Mensagem original --------
>> Assunto: ARLA/CLUSTER: SIRESP: Não à possibilidade de multar a empresa
>> que detém o sistema de comunicações de segurança, o contrato permitia que
>> houvesse uma indisponibilidade de 69.456 horas..
>> De: "João Costa > CT1FBF"
>> Para: Cluster-ARLA
>> CC:
>>
>>
>> Autor: Rui Pedro Antunes in Observador
>>
>> O ministro da Administração Interna, Eduardo Cabrita, prometeu e
>> minutos depois o documento estava no portal do Governo: mais um
>> relatório sobre as falhas da rede SIRESP em 2017, ano em que os
>> incêndios florestais provocaram a morte de 115 pessoas. O relatório de
>> onze páginas deixa claro que — ao contrário do que chegou a sugerir o
>> ministro no Parlamento a 4 de abril de 2018 — “não existe qualquer
>> margem†para aplicar sanções à empresa que gere a rede SIRESP pelas
>> falhas durante os incêndios de 2017.
>>
>> O ministro tinha dito em abril de 2018 que “o levantamento que foi
>> feito aponta para 9.000 horas de indisponibilidade da rede SIRESP em
>> 2017, e daà tiremos sem demagogias as responsabilidades necessáriasâ€.
>> Depois disso, o ministério chegou a garantir ao Público que ia aplicar
>> multas. No entanto, meses depois foi noticiado que não havia condições
>> para multar a empresa. O relatório-sÃntese divulgado esta terça-feira
>> — que o ministro pediu à secretaria-geral do Ministério da
>> Administração Interna (SGMAI) — conclui que “não existe qualquer
>> margem para a entidade gestora (SGAI) aplicar penalidades à entidade
>> operadora (SIRESP), SA) relativamente ao ano de 2017 com base no
>> critério contratual de disponibilidade da redeâ€.
>>
>> As falhas existiram mas o contrato está feito de uma forma bastante
>> favorável para a empresa. Assim, diz a mesma conclusão, o SIRESP
>> esteve disponÃvel em 2017 “dentro dos intervalos contratualmente
>> permitidos“. O relatório tem os valores referidos pelo ministro no
>> Parlamento, mas também tem os valores que a SIRESP estava autorizada a
>> falhar, que são bastante superiores.
>>
>> Segundo o relatório, a rede SIRESP falhou durante 8.960 horas (o
>> número dado pelo ministro no Parlamento) e que corresponde a 6.779
>> horas de indisponibilidade global e 2.189 horas de indisponibilidade
>> operacional. Mas este total de 8.960 horas de indisponibilidade não é
>> um problema para a empresa, já que o contrato permitia que houvesse
>> uma indisponibilidade de 69.456 horas.
>>
>> Ainda assim, na disponibilidade operacional (onde estão as falhas de
>> mais gravidade — de NÃvel 1) a indisponibilidade verificada ficou
>> muito mais perto do limite: 2189 horas de indisponibilidade verificada
>> para 5298 horas de indisponibilidade permitida (41,31%).
>>
>> A avaliação do contrato é feita de forma quantitativa, não
>> qualitativa. Aquelas nove mil horas podem ter sido altamente
>> prejudiciais para o sistema de Proteção Civil, mas o que conta para
>> efeitos de contrato é o número de horas por ano que a rede pode
>> falhar. Estas falhas podem ocorrer em diferentes dias e zonas do paÃs
>> e são acumulativas.
>>
>> Na introdução deste relatório é explicado que, na base do estudo,
>> estiveram dados cedidos pela própria SIRESP, SA, após terem sido
>> cruzados com a aplicação TeMIP pela SGAI, uma aplicação que, segundo a
>> SGMAI, “é inviolável e armazena todos os eventos que poderão impactar
>> a disponibilidade da rede SIRESP“. É neste último ponto que estará
>> garantida a independência da análise.
>>
>> O relatório explica que o cálculo da “disponibilidade operacional e
>> global†é de “elevada complexidade†e que, por isso, foram tidos em
>> conta “todos os perÃodos de indisponibilidade dos elementos que em
>> 2017 registaram avaria ou indisponibilidade, sem aplicar nenhuma das
>> deduções contratualmente previstas.â€
>>
>>
>> ______________________________________________________________
>> Esta mensagem é da exclusiva responsabilidade
>> do seu autor e não representa nem vincula a posição
>> da ARLA - Associação de Radioamadores do Litoral Alentejano
>> _______________________________________________
>> CLUSTER mailing list
>> CLUSTER radio-amador.net
>> http://radio-amador.net/cgi-bin/mailman/listinfo/cluster
>>
>> ______________________________________________________________
>> Esta mensagem é da exclusiva responsabilidade
>> do seu autor e não representa nem vincula a posição
>> da ARLA - Associação de Radioamadores do Litoral Alentejano
>> _______________________________________________
>> CLUSTER mailing list
>> CLUSTER radio-amador.net
>> http://radio-amador.net/cgi-bin/mailman/listinfo/cluster
>>
>
>
> --
>
> 73's
> ***********************************
> CT1JIB / *Jorge Santos*
> ***********************************
>
> ______________________________________________________________
> Esta mensagem é da exclusiva responsabilidade
> do seu autor e não representa nem vincula a posição
> da ARLA - Associação de Radioamadores do Litoral Alentejano
> _______________________________________________
> CLUSTER mailing listCLUSTER radio-amador.nethttp://radio-amador.net/cgi-bin/mailman/listinfo/cluster
>
> --
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Callsign: CT7ABP
> QRA: Pedro Ribeiro
> GRID Locator: IM58mr
> QTH: São Francisco, Alcochete, Portugal
> NET: http://www.qrz.com/db/CT7ABP
> CT7ABP is also home station of CR7AJI Diogo
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>
> ______________________________________________________________
> Esta mensagem é da exclusiva responsabilidade
> do seu autor e não representa nem vincula a posição
> da ARLA - Associação de Radioamadores do Litoral Alentejano
> _______________________________________________
> CLUSTER mailing list
> CLUSTER radio-amador.net
> http://radio-amador.net/cgi-bin/mailman/listinfo/cluster
>
-------------- próxima parte ----------
Um anexo em HTML foi limpo...
URL: http://radio-amador.net/pipermail/cluster/attachments/20190410/d00aaf13/attachment.htm
Mais informações acerca da lista CLUSTER