Um sistema de planeamento e controlo da descarga e carga de navios porta-contentores

A necessidade

Um navio porta-contentores que chega a Ashdod transporta centenas e por vezes milhares de contentores. Uns são descarregados em Ashdod, outros seguem a bordo para outro porto, e no espaço libertado são carregados contentores de exportação. O planeamento é feito fora do porto: o planeador da companhia de navegação envia um ficheiro BAPLIE com a posição de cada contentor, cada agente envia um manifesto e o porto envia listas dos contentores cheios e vazios para exportação. Estas fontes nem sempre coincidem, e alguém tem de as conciliar antes de o trabalho a bordo começar.

A bordo trabalham os conferentes (tallymen) do Daniel Group. Contam, registam e verificam cada movimento: que contentor foi descarregado e de que posição, se ficou danificado, se foi movimentado e quanto tempo duraram os atrasos. Esse registo é a base para reportar aos agentes, esclarecer diferenças e faturar.

O setor tem sistemas de planeamento de estiva e computadores de carga, como o MACS3 e o StowMan da Navis, que calculam a estabilidade e a posição dos contentores, e sistemas de gestão de terminal dos operadores portuários. O sistema do Daniel Group responde a outra necessidade: foi construído para a empresa que supervisiona o trabalho, o regista e reporta sobre ele. Por isso concentra-se em conciliar as fontes de dados, controlar a execução do plano e manter um registo sólido perante agente, porto e navio.

Como o sistema está construído

• Aplicação de gestão para Windows: no escritório abre-se a escala, recebem-se ficheiros, corrigem-se dados, constrói-se o plano, acompanha-se o trabalho e produzem-se relatórios.
• Aplicação Android para tablet: os conferentes reportam cada movimento a partir do navio, com ou sem ligação à rede.
• Camada de serviços API: as duas aplicações usam-na para trabalhar com uma única base de dados SQL Server. A comunicação é protegida e cada dispositivo é identificado e autorizado.

A vida de uma escala

1. Abrir a escala e escolher o navio, verificando que os números de viagem de importação e exportação são únicos.
2. Preparar o plano de descarga a partir do ficheiro EDI do planeador, do ficheiro de Restows e dos manifestos dos agentes.
3. Preparar o plano de carga a partir do planeador, das listas do porto, do manifesto de reefers e dos dados de mercadorias perigosas, até um pré-plano enviado ao oficial do navio para aprovação.
4. Reportar o trabalho a bordo através dos tablets, também enquanto o plano ainda está a ser preparado.
5. Produzir relatórios intermédios e finais, e enviar ficheiros aos agentes e ao porto.
6. Fechar a escala e passá-la para o histórico, de onde pode ser recuperada a qualquer momento.

O sistema impõe a ordem entre ficheiros: não permite processar a exportação antes da importação, nem carregar um ficheiro do porto ou um manifesto antes do ficheiro EDI da mesma direção.

Receção e validação de ficheiros

O sistema identifica a versão da norma do ficheiro BAPLIE (SMDG 1.5, 2.0 ou 2.2) e a forma como o peso é registado, e verifica cada contentor antes de entrar no plano. Um contentor com erro vai para uma tabela de erros e aguarda tratamento:

• Peso fora do intervalo do tipo de contentor, ou código EDI ou porto que não existem nas tabelas.
• Contentor que aparece duas vezes, posição que não existe no navio, ou vários contentores na mesma posição.
• Número de contentor que não cumpre a norma ISO 6346, incluindo o dígito de controlo.
• Contentor de 40 pés numa posição que não o comporta, ou em que uma das metades já está ocupada.

Quando chega um ficheiro corrigido, o sistema atualiza apenas o que mudou. Quando se apaga um ficheiro, recupera cada contentor do ficheiro anterior em que apareceu, de modo que apagar uma correção repõe o estado anterior. Erros recorrentes, como um código de porto fora da norma, são tratados por conversões que correm antes do carregamento.

O plano do navio

A página do plano mostra o navio por bay, row e tier, em corte de dois porões ou com o navio inteiro. Cada posição mostra o contentor, os portos, o agente e o peso, e os contentores especiais estão assinalados: movimentações (shifting), mercadorias perigosas, high cube, reefers e cargas fora de gabarito que bloqueiam posições vizinhas. O utilizador escolhe um atributo principal, como o porto de descarga, e o sistema colore o navio inteiro por ele.

O plano alerta quando uma coluna ultrapassa o peso permitido, quando há demasiados high cube abaixo do convés e quando um contentor que devia ter sido descarregado continua a bordo. No modo de fecho da exportação compara, para cada combinação de tamanho, tipo, destino e classe de perigo, o plano com o que o porto pretende carregar, para que as diferenças sejam corrigidas antes de o navio partir.

O tablet a bordo

O conferente escreve apenas os sete algarismos do número do contentor, e o sistema completa o prefixo e a posição. Um contentor que não é encontrado é verificado segundo a norma e pode ainda assim ser reportado, porque o que aconteceu a bordo tem de ficar registado mesmo quando não coincide com o plano. No mesmo ecrã reportam-se movimentações, danos por lado do contentor com fotos da câmara, equipamento especial e entrega direta, e registam-se atrasos, gôndolas e a abertura e fecho das tampas de porão.

O tablet guarda todos os dados da escala numa base de dados local. Quando a rede cai, o trabalho continua, e quando a ligação volta tudo o que foi registado é enviado para o servidor. O sistema nunca assume que um dado foi guardado: espera pela confirmação do servidor.

Relatórios e envios

O sistema produz relatórios de trabalho antes de o trabalho começar, relatórios intermédios como o relatório de conferência por turno e o relatório diário, e relatórios finais: listas de descarga e de carga, short/over com motivos, danos, movimentações, resumos por agente e um TDR. O ecrã de EDI produz ficheiros na versão 2.2 com o peso VGM exigido pela Convenção SOLAS, e o ecrã de agentes produz o pacote de relatórios definido para cada agente com um clique.

Como o sistema foi especificado

O sistema substituiu o sistema anterior do cliente. Os requisitos foram escritos a partir da análise desse sistema, dos ficheiros reais que chegam dos planeadores, dos agentes e do porto, dos relatórios que o cliente produzia e de sessões de trabalho. O documento de requisitos é uma árvore de 6 epics, 32 features e cerca de 180 user stories, com mais de 500 referências cruzadas, de modo que cada ecrã foi construído e testado contra uma única definição dos dados e das regras. É assim que trabalhamos: a especificação conduz cada etapa.