• Nenhum resultado encontrado

Características do software de um laboratório de metrologia

9 Software de gestão de um laboratório de metrologia

9.1 Características do software de um laboratório de metrologia

As calibrações controladas por software e por autómatos surgiram apenas na última década do século passado. Até esse período, a maioria dos cálculos, calibrações e o controlo dos sistemas de calibração foram sendo realizados manualmente, com a recolha de dados feita à mão (com auxílio de calculadoras ou réguas de cálculo) e os registos feitos em papel. Um sistema de calibração

automático poderá ou não fazer o trabalho mais rápido que um técnico, mas é, sem duvida, uma grande mais valia na calibração dos equipamentos. Isto porque é feita pelas máquinas e, em simultâneo, os dados vão sendo produzidos e recolhidos de modo automático para uma base de dados. Deste modo, o técnico que acompanha o processo fica mais liberto, podendo, deste modo, efectuar a calibração de outro equipamento. No que diz respeito à gestão da base de dados de um laboratório de metrologia, esta passa a ser arquivada em formato digital, permitindo, deste modo, a eliminação do papel no laboratório, podendo gerar relatórios e certificados de forma automática, bem como muitas outras funções administrativas.

Um outro campo onde o software de suporte a um laboratório de metrologia pode ajudar é no controlo do processo e agendamento da calibração; através deste será possível produzir-se um cronograma, por exemplo de 30 dias, permitindo que toda a estrutura do laboratório possa saber o que aconteceu, o que está a decorrer ou o que irá acontecer dentro desse período. Com base nessa informação será possível alocar os meios humanos adequados, mas, o mais importante que este sistema permite, mantendo o foco na calibração de equipamentos, é o facto de poder-se programar o ensaio e a calibração de equipamentos similares no mesmo período, ou agendar as calibrações antes de se ter que devolver os padrões usados nestas.

Voltando o foco para a criação e gestão da base de dados gerida pelo software do laboratório, nesta deverá estar armazenado tudo o que aconteceu, onde aconteceu e quem esteve envolvido, tal como, por exemplo: deverá incluir a data em que um determinado equipamento de teste foi calibrado, bem como ter descrito todos os comentários e ou observações feitas pelo técnico de calibração, assim como quem assinou o documento final e o processou. Na base de dados deverão estar todos os custos de reparação, contabilizado o tempo para reparação e calibração, e qualquer informação adicional sobre aprovação ou falha, precisão, cálculo de incerteza de medição, bem como outros dados pertinentes.

Através do software deverá ser possível fazer uma boa gestão dos equipamentos a ensaiar e a calibrar, isto é, não permitindo que um mesmo equipamento calibrado e dado como aprovado num dia, volte ao laboratório no dia seguinte por engano.

A abordagem ao software poderá ser feita de duas formas: 1) Software de controlo e de aquisição de dados;

2) Software para análise e validação automática da calibração e dos cálculos (Bucher, 2012).

Estas duas abordagens, no que diz respeito aos ensaios/calibrações de equipamentos, já estão bastante regulamentadas por várias normas, embora só nos últimos anos se tenha começado a dar algum relevo a esta temática.

Começando pela análise à norma ISO/IEC 17025:2005, a responsável pela especificação dos requisitos gerais para realizar ensaios e/ou calibrações, na sua secção 5.4.7.2 é abordada esta temática de forma clara, onde se pode ler:

• "Sempre que sejam utilizados computadores ou equipamentos automatizados para aquisição, processamento, registo apresentação, armazenamento ou recuperação de dados de ensaio ou de calibração, o laboratório deve garantir que:

a) O software desenvolvido pelo utilizador esteja suficientemente documentado e validado como apto ao uso;

b) Sejam estabelecidos e implementados procedimentos para protecção dos dados; estes procedimentos devem incluir, mas não se limitar à integridade e confidencialidade da introdução e recolha de dados, seu armazenamento, transmissão e processamento; c) Computadores e equipamentos automatizados tenham manutenção, para garantir um

funcionamento adequado, e disponham das condições ambientais e de funcionamento necessárias à preservação da integridade dos dados de ensaio ou de calibração”. No (IPAC, 2010), o “Guia para a aplicação da NP EN ISO/IEC 17025”, considera que, “quando um laboratório recorre a software comercial, a configuração ou as eventuais modificações introduzidas no mesmo, devem ser validadas. A validação do software desenvolvido pelo laboratório para efectuar cálculos pode ser feita, por exemplo, pela descrição das fórmulas e algoritmos usados e uma comparação representativa das respostas dadas pelo computador/sistema automatizado com as expectáveis face à introdução de um conjunto conhecido de dados. O detalhe com que o software desenvolvido pelo laboratório é documentado dependerá, nomeadamente dos conhecimentos dos utilizadores e das implicações do seu uso na qualidade dos resultados.” Olhando para a outra norma também já abordada nesta monografia, a ISO10012, que fornece as orientações para processos de gestão de medição e de confirmação metrológica de equipamento de medição, na sua secção 6.2.2, Software, é dito que ”O software usado nos processos da medição e no cálculo de resultados deve estar documentado, identificado e controlado, tendo em vista assegurar a aptidão para o seu uso contínuo. O software, e qualquer revisão, deve ser testado e/ou validado antes de começar a ser utilizado, aprovado para o uso e arquivado. Os testes devem ser feitos na extensão necessária para garantir a validade dos resultados das medições”.

No fundo, cabe ao laboratório, mais propriamente dito, cabe a quem utiliza, utilizar o software como ferramenta de trabalho, verificar se este está a funcionar de acordo com as especificações que o levaram a adquiri-lo. Isto é, certificar-se de que não há discrepância entre o manual de utilização do equipamento e o mesmo, e se as fórmulas que estão na base do seu funcionamento são precisas e não têm bugs.

Nos Estados Unidos da América (EUA), a National Conference of State Legislatures (NCSL), no seu documento RP-6 – Calibration Control Systems for the Biomedical and Pharmaceutical

Industry, afirma que a implementação de umsoftware num laboratório de metrologia é o caminho

para se poder melhorar o processo de calibração – aumentando a produtividade e a qualidade do laboratório. Com o recurso à utilização de um sistema informatizado/automatizado, estando este validado e que dê garantias de segurança, quer em relação ao algoritmo usado, quer no cálculo dos valores de controlo, quer ainda no controlo dos equipamentos de medida. Este software passa a ser visto como sendo uma parte integrante de um laboratório, cada vez mais importante e indispensável nos sistemas de medição, sendo que o seu desenvolvimento, manutenção e utilização deverão ser geridos e controlados de forma tão rigorosa quanto o hardware do sistema de calibração. No mesmo documento é ainda dito que as mudanças no software devem ser controladas da mesma maneira que os restantes processos documentados.

Para que o processo de validação possa começar, deverão existir alguns recursos, tais como: • Os requisitos devem estar documentados;

• Devem estar definidos os testes de validação dos requisitos,

• A evidência das validações bem-sucedidas deverá ser documentada e mantida.

Poder-se-á dizer que o software e o hardware formam um sistema, isto é, quando o software é usado, parte dos requisitos usados por este fazem parte do sistema global. Os dois já não poderão ser vistos como sendo partes independentes uma da outra.

A validação de um software pressupõe que este passe pelas seguintes fases:

• Planeamento da qualidade – poderá incluir os requisitos do sistema, avaliação de risco, gestão da configuração, um plano de garantia de qualidade do software e outras actividades;

• Definição dos requisitos – definição do que se pretende que o software faça, quer ao nível de controlo (metrológico e automação), quer administrativo;

• Design de software – são os requisitos do utilizador explícitos e implícitos extraídos das especificações dos requisitos e transpostos para os algoritmos do programa;

• Construção (codificação) – a construção aqui refere-se a toda a programação do software. O código deverá estar documentado de modo a que uma terceira pessoa ou a própria, futuramente, possa efectuar a manutenção ou melhorar o código;

• Testes realizados pelo programador – são testes ainda numa fase de pré-conclusão de projecto, visando garantir que todos os requisitos seleccionados na fase inicial do projecto foram atendidos e que todos os requisitos são rastreáveis para os testes que são realizados;

• Teste do utilizador – o utilizador deverá seguir os passos documentados pelo responsável do desenvolvimento do software a partir dos requisitos dos testes documentados que foram desenvolvidos de forma a testar o software;

• Manutenção e alterações a implementar – sempre que seja realizado algum tipo de manutenção e se altera código, ou se implementam novas funcionalidades, o plano de validação deve ser revisto e realizado (Bucher, 2012).

Muitos laboratórios de metrologia já com processos de medição/calibração automatizados e interiorizados pelos seus técnicos acham, possivelmente, que não necessitam de modificar/evoluir os seus procedimentos de calibração. Isto, talvez e em primeiro lugar, devido à sua dimensão e volume de trabalho e, em segundo lugar, porque, com os ajustes/optimização que vão fazendo, de forma voluntária, ao seu sistema, sejam considerados como suficiente. Mas este tipo de intervenção feita ao software dos laboratórios de metrologia, e sem que os responsáveis se apercebam, porque são consideradas alterações simples e pontuais, já é considerado um passo no que respeita ao desenvolvimento e melhoria deste software (de medição/calibração e controlo dos processos). Isto só acontece devido ao facto de certas alterações requererem uma validação mínima e porque os softwares, normalmente, assim o permitirem, isto é, dão ao utilizador a capacidade de modificar os procedimentos de calibração já existentes ou criar novos.

Um dos conjuntos de directrizes mais gerais e acessíveis para validação de software são os Princípios Gerais de Validação de Software referidos no Guia Final para Indústria e equipas da

FDA, produzido pela FDA. Este guia não é aplicável, na totalidade, aos laboratórios de metrologia, porque está mais virado para a orientação dos fabricantes de equipamentos médicos, os quais também desenvolvem software. Este documento foca-se na gestão do ciclo de vida do

software e da gestão de riscos. No entanto, poderá contribuir com os princípios gerais de validação

de software no que diz respeito aos laboratórios.

Em relação aos dispositivos médicos/aplicações de metrologia, as orientações poderão ser traduzidas em:

• Software que faz parte do EI&MT. Isso inclui qualquer firmware interno; • Software que é, ele próprio, o EI&MT;

• Software usado na calibração do volume de trabalho, como procedimento de calibração automatizado;

• Software para implementar o sistema de gestão de qualidade. Isso pode incluir sistemas de automação de calibração e sistemas de gestão de informação de laboratórios.

Na área de desenvolvimento de software, as palavras verificação e validação, juntamente com a de testes, são frequentemente usadas como se fossem sinónimos. A orientação que a FDA dá aponta e define as diferenças:

• A verificação é a evidência objectiva de que, na fase específica do ciclo de vida do

software, o desenvolvimento e todos os requisitos foram atendidos;

• O teste é uma das muitas formas usadas para encontrar as evidências que se querem que sejam objectivas;

• A validação poder-se-á dizer que é a confirmação, por teste e no fornecimento de dados objectivos, de que as especificações de software estão em conformidade com as necessidades dos utilizadores e os usos previstos, e de que os requisitos particulares implementados através do software podem ser cumpridos de forma consistente. A validação depende, entre outras coisas, da verificação e de testes ao longo do período de desenvolvimento do software (Bucher, 2012).