BRPI0614133A2 - sistema de operaÇço distribuÍdo, dispositivo terminal, mÉtodo para administrar intervenÇÕes em equipamentos de usuÁrio ou rede, e, produto de programa de computador - Google Patents

Abstract

SISTEMA DE OPERAÇçO DISTRIBUÍDO, DISPOSITIVO TERMINAL, MÉTODO PARA ADMINISTRAR INTERVENÇÕES EM EQUIPAMENTOS DE USUÁRIO OU REDE, E, PRODUTO DE PROGRAMA DE COMPUTADOR. Um sistema para gerar sinasi de instrução arranjados em fluxos de trabalho ou regras para executar intervenções em equipamentos, tais como equipamentos de uma rede de comunicação (N), em que os equipamentos podem ser associados a agentes de proxy de Recurso (RP1,...RPn), cada um responsável por administrar um único equipamento. O sistema inclui uma arquitetura distribuída de agentes de proxy de administração de intervenção (PP1,...,PPn) provida com máquinas baseadas em fluxo de trabalho ou baseadas em regras respectivas para gerar sinais a instrução, cada agente estando associado a um dispositivo terminal. Os agentes de proxy de administração de intervenção (PP1,...PPn) podme ser acoplados interativamente (PTP) com os agentes de proxy de Recurso (RP1,...RPn) ou com um recurso administrador associado com o equipamento, por meio de que os sinais de instrução são uma função do estado do equipamento no qual as intervenções são executadas.

Description

"SISTEMA DE OPERAÇÃO DISTRIBUÍDO, DISPOSITIVO TERMINAL, MÉTODO PARA ADMINISTRAR INTERVENÇÕES EM EQUIPAMENTOS DE USUÁRIO OU REDE, Ei PRODUTO DE PROGRAMA DE COMPUTADOR"

Campo da Invenção

A presente invenção relaciona-se a técnicas que habilitam gerar sinais de instrução, e executar intervenções (ou, mais geralmente, operações) baseadas em ditos sinais de instruções em redes distribuídas, tais como nos aparelhos de uma rede de comunicação.

A invenção foi desenvolvida com atenção particular prestada a seu possível uso no contexto de plataformas distribuídas para administração e suporte à operação da mão-de-obra e dos clientes.

Descrição da Técnica Relacionada

Os custos dos processos operacionais, tais como os para prover novos serviços a clientes ou para remover falhas e defeito, representam uma porcentagem importante dos custos que os operadoras de telecomunicações devem enfrentar anualmente. Conseqüentemente, a importância de métodos/sistemas visados a reduzir ditos custos por ferramentas suportando atividades de ambos mão-de-obra de operadora e clientes, que por esse meio podem ser envolvidas diretamente em remover dificuldades relacionadas a equipamentos nas instalações de cliente.

Suporte para a mão-de-obra e para o cliente, que está diretamente envolvido em ações de consertar falhas/defeitos, pode ser provido usando duas ferramentas principais: Sistemas de Administração de Conhecimento (KMs), ou em lugar disso Sistemas de Administração de Conhecimento Operacional (OKMs), e plataformas de administração avançadas, não vistas como entidades separadas, mas como componentes de uma solução integrada e completa.

Por "Administração de Conhecimento (KM)" é significado a atividade que habilita criação, disseminação e uso do conhecimento de uma organização. Entre as várias abordagens para KM, companhias preferem geralmente a local, que focaliza na administração de uma parte do conhecimento e em objetivos específicos (por exemplo, tomada de decisão, solução de problema, etc.)· Administração de Conhecimento Operacional (OKM) é uma abordagem local à administração de conhecimento, focalizada na administração do conhecimento operacional. Este tipo de conhecimento inclui métodos e técnicas (práticas operacionais) necessárias para efetuar um trabalho particular ou uma atividade específica. Usuários típicos de uma OKM são engenheiros de campo de uma companhia e consultores de Centro de Chamada.

Sistemas de KM/OKM representando o nível atual de desenvolvimento destas técnicas são descritos, por exemplo no documento US-A-2004/0044542 e no artigo por G. Valente e A. Rigallo: "Remoter: an Operational Knowledge Management System for Telecommunication Operators", 'Workshop on Knowledge Management and Organizational Memories', 16a Conferência Européia sobre Inteligência Artificial (ECAI), 2004.

As soluções descritas nos documentos anteriores são propostas como ferramentas para suportar atividades de solução de problema como as que podem ser efetuadas pela mão-de-obra de uma operadora de telecomunicações (para lidar com reclamações de cliente ou cumprir pedidos de cliente de novos serviços) ou até mesmo pelo próprio cliente, envolvido diretamente em atividades de auto-atendimento em equipamentos nas suas instalações.

Em particular, o documento US-A-2004/0044542 descreve um método e um sistema para capturar e compartilhar o conhecimento entre o pessoal técnico de uma dada companhia, entre dito pessoal e os usuários e entre os usuários e o pessoal técnico de outras companhias. Dito método e sistema podem ser aplicados a vários domínios, entre os quais também o domínio de serviços de telecomunicações, e provêem um suporte a atividades de solução de problema, usando abordagens de Raciocínio Baseado em Caso e Raciocínio Baseado em Modelo.

No artigo por Valente e Rigallo, ao invés, um sistema de Administração de Conhecimento Operacional (OKMj) chamado 'Remoter', é definido, dito sistema sendo usado em um contexto de telecomunicações para apoiar os técnicos de uma operadora de telecomunicações durante suas atividades diárias. Em particular, 'Remoter' foi usado e testado no contexto dos processos de Provisão e Garantia de serviços de ADSL, nos quais os técnicos devem reagir em um curto tempo e escolher a melhor solução. O propósito do sistema é habilitar os técnicos compartilharem, capturarem e aplicarem seu Conhecimento Operacional para tomar decisões ótimas em tempo real. Dito sistema usa a abordagem de Raciocínio Baseado em Caso Coloquial para suportar solução de problema.

0 documento WO-A-2005/018249 descreve uma arquitetura de sistema baseada em um paradigma de agente e com um alto grau de flexibilidade e capacidade de expansão, para administração distribuída de uma rede de telecomunicações e dos serviços suportados. Os pontos chaves de dita arquitetura são:

- uma plataforma para administração de rede e serviço baseada em agentes distribuídos, associados a máquinas de fluxo de trabalho e máquinas de regras, e organizada em três níveis hierárquicos;

- Máquinas de Processo (máquinas de fluxo de trabalho e máquinas de regras) usadas não só para coordenação dos componentes (dos aplicativos), mas também para implementação flexível de todos os aspectos funcionais e de comportamento da plataforma;

- um inventário de modelo centralizado (Banco de Dados de Modelo - MDB) para a definição, armazenamento mestre (banco de dados mestre) e administração de todas as descrições de processo e modelos de informação de recursos de rede para ser distribuída ao longo da plataforma para uso dentro das Máquinas de Processo;

- uma camada de inventário de rede distribuída que desacopla a rede das funções de administração do OSS e provê um banco de dados alinhado em tempo real com a rede;

- uso de técnicas de mobilidade de código que habilitam uma distribuição conveniente de aplicativos, incluindo os aspectos de equilíbrio de carga e tolerância a falhas.

O artigo de Stephen Corley et al., "Communications Management Process Integration Using Software Agents: A Specification of a Framework for Agent Oriented Workflow Management Systems", EURESCOM PROJECT P815, [On-line] janeiro de 2001, páginas 1-92, XP002343307 Recuperadas da Internet: URL: http://www.eurescom.de/-pub- deliverables/P800-series/P815/Dl/p815dlvol2.pdf, descreve um estrutura para um sistema de administração de fluxo de trabalho orientado para agente. A arquitetura de co-ordenação intra-domínio (isto é, dentro de uma organização empresarial local) inclui um Repositório de Processo Empresarial, um Representante de Domínio, Agentes de Provedor de Recurso, Agentes do Usuário Pessoais e Agentes de Provedor de Fluxo de Trabalho. Os Agentes de Provedor de Fluxo de Trabalho contém máquinas de fluxo de trabalho e são responsáveis por fluxo de trabalho de intra-domínio. O Agente de Usuário Pessoal (PUA) provê uma interface inteligente ao usuário de um Sistema de Administração de Fluxo de Trabalho, e pode ser um PUA GUI ou um PUA inteligente. No caso anterior, quando um usuário pede uma operação de controle de fluxo de trabalho, a GUI remete o pedido ao agente de PUA, e o PUA se comunica com o WPA a fim de proceder ao cumprimento. No caso anterior, o PUA tem capacidades para sentir mudanças em seu ambiente e atuar neles de acordo com um plano que define a fim de alcançar alguns objetivos. Este agente tem capacidades de raciocínio, planejamento e aprendizagem. Ações são implementadas como métodos de objeto de Java.

US 5.826.239 relaciona-se a um sistema e método para administração de recurso distribuído em uma rede de computadores que opera sob controle de sistema de software de administração de fluxo de trabalho para administrar vários recursos para executar um processo de fluxo de trabalho que inclui múltiplas atividades de processo. Um sistema de OpenPM Federal para Administração de Recurso é descrito (veja Figura 12), incluindo um software de sistema de administração de processo de fluxo de trabalho, administradores de computador, dados do recurso, operadores de evento e proxy de recurso.

Objetivo e Sumário da Invenção

Observou-se que os métodos usados nos sistemas descritos nos primeiros dois documentos previamente referenciados (US-A-2004/0044542 e o artigo de Valente e Rigallo) apresentam limites em termos de funções oferecidas, que derivam de três desvantagens.

Em primeiro lugar, eles não provêem uma interação direta com os sistemas/plataformas responsáveis por administração de rede e serviço, que habilitaria uma redução significante nos tempos de execução de atividades de solução de problema explorando as vantagens relacionadas por exemplo à verificação em tempo real da execução correta dos trabalhos pelo pessoal técnico, provisão pró-ativa dos dados de rede precisados, e execução automática de comandos padrão na rede.

Em segundo lugar, eles não representam o conhecimento a ser compartilhado usando ferramentas formais (tais como o fluxos de trabalho) que habilitariam uma redução nos tempos de trabalho dos técnicos por uma descrição não ambígua e prontamente compreensível das atividades a serem efetuadas. Tal representação formal também evitaria qualquer possível dificuldade de interpretação ou qualquer má interpretação, pelos técnicos, das indicações providas, que pode conduzir à execução de atividades que são inúteis ou até mesmo prejudiciais para a rede na qual eles estão operando.

Finalmente, os sistemas em questão não guiam o pessoal técnico de um modo completo, integrado e exaustivo, por todas as etapas a serem seguidas para executar atividades de solução de problema: eles provêem sugestões pontuais de atividades individuais a serem executadas ou de documentos específicos a serem consultados, derivado usando métodos tais como Raciocínio Baseado em Caso Coloquial. Um guia completo habilitaria ambas uma redução nos tempos de trabalho para os técnicos e uma inserção mais rápida de técnicos que são novos ao trabalho.

Como interessa o artigo de Corley et al., e US 5.826.239, o Requerente mostra que estes documentos descrevem soluções para administrar processos empresariais e não para administrar conhecimento operacional. Fluxos de trabalho são portanto usados para representar e executar modelos empresariais e não são dedicados para representar o conhecimento operacional, requerido para efetuar um trabalho particular ou uma atividade específica, e faz disponível para o uso interativo por operadores ou usuários.

Igualmente, no estrutura de sistemas/plataformas para a administração de rede/serviço, soluções avançadas estão disponíveis, que idealizam arquiteturas distribuídas baseadas em agente.

Nesse respeito, a arquitetura descrita em W0-A-2005/018249 acima é extremamente efetiva e eficiente em administração de rede, mas não idealiza qualquer função de KM/OKM para suportar atividades da mão-de- obra de um operador de telecomunicações.

Conseqüentemente, emerge claramente a necessidade para ter soluções inovadoras disponíveis para a administração de atividades operacionais que, superando as desvantagens inerentes esboçadas no antecedente, apresentam algumas características funcionais importantes. Uma primeira destas características é a possibilidade de interação automática e ajudada com os sistemas/plataformas responsáveis pela administração de rede/serviço, o propósito disto sendo habilitar:

- verificação em tempo real, na rede/serviços administrados, da execução correta das sugestões providas, retornando uma realimentação imediata ao usuário do sistema;

- provisão automática, sincronizada com as atividades executadas, dos dados (dados de configuração, dados de medição, etc.) requeridos para proceder com ditas atividades;

- execução automática das etapas, consideradas padrão, da atividade de um engenheiro/operador de campo: por exemplo, configuração de uma placa de rede de acordo com parâmetros predefinidos, para eliminar qualquer possibilidade de erro e reduzir os tempos envolvidos.

Uma segunda característica desejável é que as sugestões providas à mão-de-obra deveriam ser representadas por ferramentas formais (tais como fluxos de trabalho) que têm as vantagens seguintes:

- descrição das atividades a serem executadas a fim de efetuar com êxito uma dada intervenção ou lidar efetivamente com um pedido de cliente, de um modo não ambíguo e prontamente compreensível;

- realce imediato (por exemplo, por meio de contagens apropriadas) das Melhores Práticas; e

- habilitação de uma administração mais simples do conhecimento com respeito às atividades de avanço e atualização possivelmente também por mecanismos automáticos.

Ainda uma característica importante certamente desejável adicional é que o sistema deveria ser capaz de indicar autonomamente e completamente todas as etapas específicas requeridas para efetuar uma dada intervenção (engenheiros de campo) ou para responder a um dado pedido de cliente (consultores de Centro de Chamada): eles provêem sugestões pontuais de atividades individuais a serem executadas ou de documentos específicos a serem consultados, derivados usando métodos tal como Raciocínio Baseado em Caso Coloquial.

Pode ser notado especificamente que as presentes plataformas de administração, embora na vanguarda com respeito a aspectos de administração, não oferecem ferramentas adequadas para apoiar a mão-de- obra, que ainda é confiada com efetuar etapas importantes dos processos Empresariais de uma companhia, e não estão integradas com sistemas de OKM.

E conseqüentemente sentida a necessidade de ter soluções disponíveis capazes de superar estas limitações. Especificamente, é sentida a necessidade de ter disponível uma solução completa para apoiar a mão-de- obra que, a partir de avançadas arquiteturas de administração flexíveis e expansíveis avançadas, introduzirá funções de OKM inovadoras, baseado em uma representação formal das práticas operacionais, e assegurará uma integração entre operação e administração de rede/serviço.

O objetivo da invenção é assim prover uma resposta completamente satisfatória às necessidades anteriores, em particular prover uma técnica eficiente para suportar serviços de intervenção humana em sistemas distribuídos, tal como rede de aparelhos distribuídos em um dado território.

O Requerente achou que o objetivo anterior é alcançado provendo uma arquitetura de administração de operação distribuída, incluindo uma pluralidade de agentes de proxy de administração de intervenção associados a operador respectivo ou dispositivos terminais de usuário, cada agente de proxy de administração de intervenção incluindo uma máquina de processo adequada para processar fluxos de trabalho ou regras definindo as instruções para executar as intervenções, e um sistema para administrar e controlar a operação dos dispositivos terminais incluindo um recurso centralizado adequado para prover os agentes de proxy destes dispositivos com fluxos de trabalho diferentes ou regras dependendo do tipo de intervenção.

De acordo com um aspecto da presente invenção, uma arquitetura distribuída de agentes de proxy de administração de intervenção associados a dispositivos terminais do operador ou usuário respectivo é provida, ditos agentes de proxy de administração de intervenção sendo configurados para interagir com meio administrador (preferivelmente incluindo os agentes de proxy de Recurso) associado com dispositivos adicionais (tais como equipamentos de rede) para gerar sinais de instrução (na forma de fluxos de trabalho ou regras) para executar intervenções nos dispositivos, por meio de que os sinais de instrução são uma função do estado dos dispositivos requerendo a intervenção.

De acordo com outro aspecto da presente invenção, um dispositivo terminal é proposto, que é preferivelmente um dispositivo portátil tal como um telefone celular, um Assistente Digital Pessoal (PDA) ou um laptop, incluindo um agente de proxy de administração de intervenção provido com uma máquina de processo baseada em fluxo de trabalho ou regras e uma Interface Pessoal (PI) para permitir interação com operador ou um usuário, e sendo preferivelmente configurado para descarregar fluxos de trabalho ou regras de um recurso remoto. O agente de proxy também é provido preferivelmente com uma interface para comunicação com um aplicativo de software em outro equipamento, dispositivo ou aparelho a fim de trocar informação com isto durante execução do fluxo de trabalho ou regras.

O Requerente achou que a arquitetura acima e dispositivo terminal podem ser aplicados para executar intervenções em aparelhos de uma rede distribuída, tal como uma rede de telecomunicação ou uma rede de distribuição de potência. A invenção pode porém achar aplicação ampla em todos os cenários em que é pedido para operar (por exemplo para resolver falhas) em aparelhos, equipamentos ou dispositivos de características predefínidas, de um modo sistemático, explorando processos predefinidos de um modo flexível e preferivelmente interativo, e mantendo controle centralizado e administração das operações.

O termo "intervenção" é portanto para ser interpretado amplamente, assim para incluir por exemplo interações entre os dispositivos terminais e dispositivos externos, aparelhos ou equipamentos para diagnose, modificações de hardware/software ou operações de verificação.

A invenção também relaciona-se a um produto de programa de computador correspondente, carregável na memória de pelo menos um computador e incluindo porções de código de software para executar as etapas do método da invenção quando o produto é corrido em um computador. Como usado aqui, referência a um tal produto de programa de computador é compreendida como sendo equivalente à referência a um meio legível por computador contendo instruções para controlar um sistema de computador para o propósito de coordenar a execução do método de acordo com a invenção. Referência a "pelo menos um computador" é pretendida para realçar a possibilidade para a presente invenção ser implementada em um modo distribuído e/ou modular. As reivindicações fazem parte integral da exposição da invenção provida aqui.

Uma concretização particular da solução descrita aqui é um método de sinais de instrução geradores arranjados em fluxos de trabalho para executar intervenções em equipamentos de rede incluídos em uma rede de comunicação em que ditos equipamentos são associados a agentes de proxy de Recurso, cada um responsável por administrar um único equipamento em dita rede, o método incluindo as etapas de:

- prover uma arquitetura distribuída de agentes de proxy de administração de intervenção; e - gerar ditos sinais de instrução por ditos agentes de proxy de administração de intervenção de uma maneira interativa com ditos agentes de proxy de Recurso, por meio de que dito sinais de instrução são uma função do estado do equipamento em rede dita na qual ditas intervenções são executadas.

De acordo com um primeiro aspecto dela, a presente invenção relaciona-se assim a um sistema de operação distribuído, incluindo:

- uma pluralidade de dispositivos terminais, cada dispositivo terminal incluindo um agente de proxy, o agente de proxy incluindo uma máquina de processo baseada em fluxo de trabalho ou baseada em regras para processar fluxos de trabalho ou regras, e uma interface de usuário (preferivelmente uma interface interativa) para representar pelo menos parte de ditos fluxos de trabalho ou regras; e

- pelo menos um recurso administrador remoto configurado para administrar transmissão de ditos fluxos de trabalho ou regras a ditos dispositivos terminais.

Em particular, as máquinas de processo podem ser máquinas baseadas em fluxo de trabalho, máquinas baseadas em regras ou uma combinação das duas. A escolha pode depender do tipo de operações a serem executadas. Por exemplo, funções de suporte relacionadas a uma intervenção de campo de um operador são representadas melhor como um fluxograma, enquanto funções para suportar diagnose em uma base de reclamação, no contexto de um Centro de Chamada, são representadas melhor por um jogo de regras. Porém, sempre que possível e aconselhável, o uso de fluxos de trabalho é preferido como evita a complexidade de lidar com conflitos de regras e administração de regras.

O agente de proxy preferivelmente inclui uma interface de interconexão para troca de informação com um aplicativo de software de um dispositivo adicional durante processamento de ditos fluxos de trabalho ou regras.

Dito aplicativo de software de dito dispositivo adicional preferivelmente inclui uma máquina de processo baseada em fluxo de trabalho ou baseada em regras e em que dita máquina de processo de dito dispositivo terminal é configurada para interagir com a máquina de processo de dito dispositivo adicional por dita interface de interconexão.

Preferivelmente, o sistema também inclui os agentes operacionais configurados para coordenar operações de ditos agentes de proxy.

Além disso, o sistema preferivelmente inclui também um administrador operacional tendo funções de administração e controle de ditos agentes operacionais.

O sistema pode portanto incluir uma arquitetura hierárquica incluindo uma camada inferior formada pelos dispositivos terminais, e uma camada superior incluindo um administrador operacional tendo funções de administração e controle.

A arquitetura hierárquica também pode incluir uma camada intermediária incluindo os agentes operacionais configurados para coordenar operações dos agentes de proxy.

Os agentes operacionais e/ou o administrador operacional pode incluir máquinas de processo baseadas em fluxo de trabalho ou baseadas em regras respectivas.

Os agentes de proxy dos dispositivos terminais podem ser configurados para interagir diretamente entre si em uma relação intertrabalho.

O sistema também pode incluir um repositório de processos definido por fluxos de trabalho ou regras. Além disso, o sistema pode incluir um repositório de modelos de dados.

O sistema também pode incluir os agentes de controle para distribuir os fluxos de trabalho ou regras aos dispositivos terminais. O sistema também pode incluir um banco de dados de desempenho para armazenar dados de desempenho relacionados a processamento do fluxos de trabalho ou regras.

O sistema também pode incluir um registro operacional para armazenar processos executados pelos agentes de proxy.

O sistema pode ser configurado para administrar intervenções em equipamentos de rede. Neste caso, o fluxos de trabalho ou regras são preferivelmente função do estado dos equipamentos de rede nos quais as intervenções são executadas.

De acordo com um segundo aspecto dela, a presente invenção relaciona-se a um dispositivo terminal, incluindo um agente de proxy provido com uma máquina de processo baseada em fluxo de trabalho ou baseada em regras para processar fluxos de trabalho ou regras e uma interface de usuário para permitir interação com um usuário durante processamento de ditos fluxos de trabalho ou regras.

O agente de proxy é preferivelmente configurado para descarregar fluxos de trabalho ou regras de um recurso administrador remoto.

O dispositivo pode ser vantajosamente um dispositivo portátil, para permitir por exemplo intervenções em campo.

O agente de proxy pode incluir uma interface de interconexão para comunicação com um aplicativo de software de um dispositivo adicional para trocar informação com isto.

O aplicativo de software do dispositivo adicional pode incluir uma máquina de processo baseada em fluxo de trabalho ou baseada em regras, a máquina de processo de dito agente de proxy sendo configurada para cooperar com a máquina de processo de dito aplicativo de software.

Dito aplicativo de software pode incluir um agente de proxy. Neste caso, o agente de proxy do dispositivo terminal pode ser configurado para ativar automaticamente uma sessão de comunicação com o agente de proxy de dito dispositivo adicional.

O dispositivo pode ser configurado para descarregar dito agente de proxy de remoto.

A interface do usuário preferivelmente administra uma interface gráfica.

O agente de proxy é preferivelmente configurado para registrar informação durante processamento de ditos fluxos de trabalho ou regras.

O dispositivo pode ser configurado para ativação do agente de proxy por um usuário.

De acordo com um aspecto adicional dela, a presente invenção relaciona-se a um método para administrar intervenções em equipamentos de usuário ou rede, o método incluindo as etapas de:

- prover uma arquitetura distribuída de agentes de proxy de administração de intervenção para administrar intervenções nos equipamentos de rede, ditos agentes de proxy de administração de intervenção estando associados a dispositivos terminais e incluindo máquinas baseadas em fluxo de trabalho ou regras; e

- gerar sinais de instrução para executar uma intervenção em pelo menos um equipamento de usuário ou rede por um de ditos agentes de proxy de administração de intervenção de uma maneira interativa com pelo menos um recurso de administração associado com dito equipamento, por meio de que dito sinais de instrução são uma função do estado de dito equipamento.

O recurso de administração pode incluir agente de proxy de Recurso associado com dito equipamento e incluindo uma máquina de processo baseada em fluxo de trabalho ou baseada em regras.

Cada agente de proxy de administração de intervenção pode ser associado com um único dispositivo terminal e pode incluir uma única máquina baseada em fluxo de trabalho ou regras. O método preferivelmente inclui a etapa de associar com ditos agentes de proxy de administração de intervenção interfaces pessoais para representar pelo menos parte de ditas instruções e para interagir com o fluxo de trabalho executado ou regra.

O método também pode incluir a etapa de arranjar dita arquitetura distribuída em camadas hierárquicas incluindo:

- uma camada de Agentes Operacionais coordenando operação de ditos agentes de proxy de administração de intervenção; e

- uma camada incluindo um Administrador operacional tendo funções de administração e controle e supervisionando a operação de ditos Agentes Operacionais.

Além disso, o método pode incluir a etapa de dividir a ditos Agentes Operacionais a execução distribuída de intervenções através de uma pluralidade de ditos agentes de proxy de administração de intervenção.

Alternativamente, o método pode incluir a etapa de arranjar dita arquitetura distribuída em camadas hierárquicas, em que uma camada inclui um Administrador operacional, tendo funções de administração e controle e coordenando diretamente a operação de ditos agentes de proxy de administração de intervenção.

O método pode incluir a etapa de dividir, para cada um de ditos agentes de proxy de administração de intervenção, a tarefa de suportar um único operador ou cliente, por meio de que execução de ditas intervenções é desacoplada com respeito a ditas funções de administração e controle.

Preferivelmente, o método também inclui a etapa de prover máquinas de processo a ditos agentes de proxy de administração de intervenção.

O método também pode incluir a etapa de prover máquinas de processo a todas as ditas camadas em dita arquitetura distribuída.

Ditas máquinas de processo são preferivelmente baseadas em fluxo de trabalho ou baseadas em regras.

O método preferivelmente inclui a etapa de incluir em ditas camadas componentes adaptados para executar funções respectivas baseado em informação de instrução respectiva provida a eles.

O método também pode incluir a etapa de prover em dita informação de instrução pelo menos um de:

- uma definição de processo, que inclui pelo menos um de um fluxo de trabalho e uma regra; e

- uma definição de modelos de dados.

Preferivelmente, o método inclui a etapa de configurar ditos agentes de proxy de administração de intervenção para interagir diretamente entre si em uma relação intertrabalho, por meio de que pelo menos iam de ditos sinais de instrução é produzido por interação entre agentes de proxy de administração de intervenção.

O método também pode incluir a etapa de configurar ditos agentes de proxy de administração de intervenção para interação de ponto a ponto com ditos agentes de proxy de Recurso.

O método pode incluir a etapa adicional de prover agentes de controle associados a pelo menos uma camada de dita arquitetura distribuída para executar um etapa selecionada do grupo consistindo em:

- distribuir definições de processo para ditas camadas de dita arquitetura distribuída;

- distribuir definições de modelo de dados para ditas camadas de dita arquitetura distribuída; e

- monitorar o estado de ditas camadas de dita arquitetura

distribuída.

O método também pode incluir a etapa de prover um módulo administrador para executar pelo menos uma etapa selecionada do grupo consistindo em: - administrar a distribuição de definições de processo para ditas camadas de dita arquitetura distribuída por ditos agentes de controle;

- administrar a distribuição de definições de modelo de dados para ditas camadas de dita arquitetura distribuída por ditos agentes de controle; e

- monitorar o estado de ditas camadas de dita arquitetura distribuída por ditos agentes de controle.

A invenção presente também relaciona-se a um produto de programa de computador carregável na memória de pelo menos um computador e incluindo porções de código de software para executar o método anterior.

Breve Descrição dos Desenhos Anexos

A invenção será descrita agora, puramente por meio de exemplo, com referência aos desenhos, em que:

Figura 1 é um diagrama de bloco funcional ilustrando uma possível concretização de uma plataforma como descrita aqui;

Figura 2 é outro diagrama de bloco funcional representando administração de operação dentro da plataforma da Figura 1;

Figura 3 é um fluxograma de um primeiro procedimento executado dentro da solução descrita aqui;

Figura 4 é um exemplo de um fluxo de trabalho como gerado pela solução descrita aqui; e

Figuras 5 a 7 são fluxogramas de procedimentos adicionais executados dentro da solução descrita aqui; e

Figura 8 ilustra esquematicamente um dispositivo portátil a ser usado na plataforma das Figuras 1 e 2.

Descrição Detalhada de Concretizações Preferidas da Invenção

A fim de facilitar entendimento correto dos princípios subjacentes à invenção, um glossário é apresentado aqui com explicação de alguns termos/acrônimos usados nesta exposição e nas reivindicações anexas.

WFM (Administração de Mão-de-obra): no contexto de uma operadora de telecomunicações, este é o aplicativo de software/conjuntos de aplicativos de software responsáveis por administrar a mão-de-obra de dita operadora. No contexto específico de interesse, é compreendido como sendo o aplicativo/conjuntos de aplicativos usados para administrar ambas a mão-de- obra móvel (engenheiros de campo) e a mão-de-obra de Centro de Chamada.

Operador: este é um membro do pessoal de companhia fazendo parte da mão-de-obra, compreendido como mão-de-obra móvel (engenheiros de campo), como mão-de-obra especializada (pessoal de retaguarda) e como consultores de Centro de Chamada.

Módulo administrador - MM: este é um aplicativo de software correndo em um hospedeiro que se comunica com os agentes distribuídos para várias atividades de coordenação, tais como distribuição de descrições de fluxo de trabalho, chamada dos agentes distribuídos para invocar uma operação, controles administrativos, etc.; pode incluir uma Interface Gráfica de Usuário (GUI) apropriada e especializada.

Agente: este é um processo autônomo com possível estado persistente e requerendo comunicação (por exemplo, em um modo colaborador e/ou competitivo) com outros agentes a fim de cumprir suas tarefas. Esta comunicação pode ser implementada por troca de mensagem assíncrona e usando linguagens bem conhecidas (por exemplo, a Linguagem de Comunicação de Agente - ACL) com uma semântica bem definida e comumente concordada.

Proxy: este é um componente (agente) por qual é possível controlar ou intervir em outro objeto administrado, por exemplo um equipamento de rede ou uma GUI no contexto de suporte para operação.

Regra: Uma regra é um esquema para construir inferências válidas. Estes esquemas estabelecem relações sintáticas da forma "se <x> então <y> senão <z>" entre um conjunto de fórmulas chamado premissas, formando a parte "se", e uma assertiva chamada uma conclusão, formando a parte "então". A parte "senão" é opcional. Estas relações sintáticas são usadas no processo de inferência, por meio de que novas assertivas verdadeiras são juntadas de outras já conhecidas.

Máquina de Regras (ou Máquina baseada em Regras): este é um sistema para separar regras de processo (logicamente e/ou fisicamente) da lógica de controle e compartilhar-las por armazenamentos de dados, interfaces de usuário e aplicativos. Uma máquina de regras é basicamente um intérprete de declaração de se/então muito sofisticado. Uma máquina de regras é usada para decidir, durante processamento, quais regras aplicar e como estas são para serem executadas.

Fluxo de trabalho: isto pode ser definido como a automatização parcial ou completa de um processo, onde documentos, informação ou tarefas são passadas de um participante para outro, de acordo com um jogo de regras processuais. Um fluxo de trabalho pode ser representado por um fluxograma com uma seqüência de tarefas e dependências temporais e lógicas, entre tarefas incluindo ramais paralelos ou alternativos. Há linguagens ad hoc, tal como XPDL (Linguagem de Descrição de Processo de XML), que habilitam descrição formal dos fluxos de trabalho.

Máquina de Fluxo de trabalho: este é o componente que possui toda a informação relacionada aos procedimentos (fluxos de trabalho), etapas em um procedimento e as regras para cada etapa. A máquina de fluxo de trabalho determina se o processo está pronto para se mover à próxima etapa. Em outras palavras, uma máquina de fluxo de trabalho é um componente para executar fluxos de trabalho.

O diagrama de bloco da Figura 1 representa uma concretização preferida de uma plataforma que inclui uma plataforma para administração distribuída de uma rede de telecomunicações e serviços relacionados, como descrito em W0-A-2005/018249, e uma plataforma para administração de operação distribuída.

A arquitetura ilustrada (que define, em suas camadas mais altas, um Sistema de Suporte de Operações (OSS)) interage com três entidades básicas incluindo outros Sistemas de Suporte de Operações (OSSs), Sistemas de Suporte Empresarial (BSSs), e um sistema de Administração de Mão-de-obra (WFM) (ou possivelmente mais de um WFM). Até onde os aspectos de administração estão envolvidos, os OSSs e os BSSs interagem por um barramento (BARRAMENTO - por exemplo, o barramento TIBCO) com o Aplicativo Mestre, designado por MAl. Este aplicativo administra a distribuição de processos e modelos de dados relacionados, armazenados no Banco de Dados de Modelo (MDB), para os vários Aplicativos de Agente, um dos quais é mostrado e designado por AAl, e Agentes de proxy de Recurso RPl, RPn. Cada Aplicativo de Agente se confia em um ou mais Agentes de proxy de Recurso RP1, RPn que conectam com uma rede de comunicação N por Adaptadores de Protocolo PAs. O Inventário de Rede NI corresponde ao conceito habitual de um componente de inventário de rede e são as coleções de todas as visualizações (imagens) do recurso na rede N; é atualizado periodicamente recuperando informação dos RPs. Detalhes adicionais relativos a esta solução ou arquitetura conhecida podem ser derivados de W0-A-2005/018249.

Como introduzido na Figura 1 e apresentado em maior detalhe na Figura 2, a plataforma de administração de operação inclui um Administrador operacional OM, que se conecta com o barramento e coopera com um Inventário de Perícia EI e um Arquivo de Registro de Operação OL. O Administrador operacional OM supervisiona a operação de Agentes Operacionais OAl, OAk. Cada Agente Operacional se confia em uma ou mais Proxys Pessoais PPl, PPn, que se conectam com uma pluralidade de Equipes Virtuais VTl, VTn por Interfaces Pessoais Pis. Cada VT é composto de, por exemplo, engenheiros de campo, pessoal de retaguarda, consultores de Centro de Chamada, ou clientes.

Os Proxys Pessoais - PP1, PP2s PPn cada um dos quais está equipado com uma Interface Pessoal PI, estão conectados à camada hierárquica superior da arquitetura que inclui tanto um conjunto de Agentes Operacionais OA1, OA2, OAk ou diretamente um Administrador operacional OM. No caso que os OAs estão presentes, estes são, por sua vez, conectados à camada hierárquica superior que inclui o OM. Esta arquitetura em camadas assegura flexibilidade e capacidade de expansão das funções, como descrito no que segue.

Em uma concretização preferida, os PPs estão em comunicação entre si, e são vantajosamente também conectados às Proxys de Recurso RPs (usando a linguagem de ACL), como indicado esquematicamente pela seta de duas cabeças PTP na Figura 1. Isto representa tipicamente uma relação de ponto a ponto entre os Proxys Pessoais e os Proxys de Recurso. Esta relação habilita a possibilidade para a arquitetura aqui descrita de gerar sinais de instrução pelos proxys de administração de intervenção (isto é, os proxys Pessoais) de uma maneira interativa com os Proxys de Recurso, de forma que estes sinais de instrução dependam do estado do equipamento no qual uma intervenção é executada. Pessoas qualificadas no setor apreciarão prontamente que referência à possível presença de η Proxys de Recurso RPl a RPn, η Proxys Pessoais PPl a PPn, e η Equipes Virtuais é completamente puramente indicativa, visto que cada uma destas entidades pode estar concebivelmente presente em qualquer número.

Cada RP é responsável pela criação, manutenção e administração da denominada "imagem" de um equipamento individual (localizado na rede ou nas instalações do cliente). A imagem é uma representação da configuração do equipamento de acordo com um modelo de dados definido. Cada Agente Operacional OA1, OAk coordena um conjunto de Proxys Pessoais; os Agentes Operacionais OAl5 OAk podem interagir entre si, como também com os Proxys Pessoais e o Administrador operacional OM.

Cada agente correndo em hospedeiro (isto é, cada agente para a administração de rede/serviço e cada novo agente tais como Proxys Pessoais, Agentes Operacionais e Administrador operacional) preferivelmente inclui um ou mais Agentes de Controle CÃS, que são os módulos de software responsáveis por controlar e administrar a plataforma. Como foi visto, a plataforma também inclui um conjunto de DBs em suporte das atividades executadas pelos vários componentes. O Banco de dados Operacional ODB é o único ponto (lógico) de definição e armazenamento de todos os aspectos funcionais e os aspectos de administração/suporte de mão-de-obra e clientes, relacionado à plataforma. O ODB é o repositório das descrições de processo (em que uma descrição de processo é tanto um fluxo de trabalho ou uma regra) e das definições de modelo de dados que são usadas pelos componentes da plataforma para administrar a operação (PP, OA e OM).

Um Módulo administrador MM, pelos Agentes de Controle CA, distribui as definições de processo e as definições de modelo de dados aos componentes de administração de operação. Em primeiro lugar, isto habilita as práticas operacionais mais eficientes e efetivas (Melhor Prática) serem feitas disponíveis à mão-de-obra inteira e aos clientes. Além disso, por um espalhamento das definições de modelo de dados, coordenação entre os membros da mão-de-obra é habilitada, assim permitindo identificação simples e rápida de peritos a serem referidos para obter suporte sobre um assunto específico. Associada ao Banco de Dados ODB está uma GUI provida propositalmente que habilitará seu povoamento.

O Banco de Dados de Modelo MDB armazena todas as descrições de processo (fluxos de trabalho e regras) e os modelos dos dados processados (incluindo os modelos do equipamento de rede), que são usados pelos componentes da plataforma para administração de rede/serviço (RPs, AAs e MA como mostrado na Figura 1).

O MDB provê os usuários com um único ponto em que definir e administrar as funções da plataforma com respeito aos aspectos de administração de rede/serviço.

Em uma concretização preferida, a fim de definir os modelos de dados nos bancos de dados ODB e MDB, o modelo de SID (modelo de Dados de Informação Compartilhada, conjunto de documentos do TeleManagementForum GB922 Versão 4.0, agosto de 2004 e Versão 4.5 Avaliação de Membro - dezembro de 2004) é usado.

O Banco de dados de Desempenho PDB é um único ponto (lógico) de armazenamento de todos os dados de desempenho relacionados aos componentes de plataforma e é usado ambos para otimizar o uso de recursos e identificar a Melhor Prática.

Finalmente, também presente na plataforma estão: o Registro Operacional, que é um único ponto (lógico) de armazenamento de todos os registros das atividades executadas pelos operadores e pelos clientes; e o Inventário de Perícia EI, que contém os dados dos perfis de operador e dos perfis de cliente administrados pelos vários PPs.

Em uma concretização preferida, os processos operacionais da plataforma são segmentados em três camadas com funções específicas. Esta escolha é pretendida para cumprir duas necessidades: manter o número de camadas tão baixo quanto possível (assim evitando a complexidade de arquiteturas convencionais), e permitir alocação livre de processos entre uma modalidade distribuída e uma centralizada. Isto implica na presença de uma camada centralizada 1 (que corresponde ao Administrador operacional OM) e uma camada 2 completamente distribuída (que corresponde aos Agentes Operacionais OAl, OAk) mais uma camada de proxy independente 3 (que corresponde aos Proxys Pessoais PPs) que desacopla a operação das funções de administração e controle. Esta segmentação também provê visões de serviço diferentes, por exemplo uma visão de produto para o cliente final na camada 1, uma visão de serviço na camada 2 e uma visão operacional na camada 3. Como será explicado mais tarde, os componentes PP, OAs OM são adaptados para executar funções respectivas baseado em informação de instrução respectiva provida a eles, qual informação inclui definições de processo, tais como fluxos de trabalho ou regras, ou definições de modelos de dados.

Cada Proxy Pessoal PP (no que segue, por razão de brevidade, nós evitaremos repetir cada vez que a seqüência de sufixos 1 a N por exemplo em PPl, PPn, e uma abordagem semelhante também será adotada com referência às outras entidades presentes em uma múltipla forma nos diagramas das Figuras 1 e 2) é responsável por suportar as atividades de um operador específico ou de um cliente específico, em termos ambos de guia nas várias atividades operacionais e de suporte para a cooperação (entre operadores diferentes ou entre operadores e cliente). Em particular, suporte para cooperação é baseado nos perfis de operador e nos perfis de cliente, estes perfis sendo representados no modelo de dados. Processamento dos perfis com os dados reais e atualizados é efetuado pelo Administrador operacional OM com a informação vindo de sistemas de WFM externos, no caso de perfis de operador, ou de Sistemas de Suporte Empresarial, no caso de perfis de cliente, e é comunicado ao Proxy Pessoal.

Em outras palavras, cada Proxy Pessoal desempenha o papel de um agente de proxy de administração de intervenção. Cada Proxy Pessoal (PP) executa processos típicos do nível de PP correspondente usando uma Máquina de Processo PE: estes processos são referidos como sendo processos de camada 3 e podem ser estruturados em subcamadas (por exemplo, para a definição de macro-operações). Os processos na camada de topo de camada 3 constituem os serviços que o PP oferece à camada superior (tipicamente o Agente Operacional, e possivelmente outros aplicativos externos) por invocação de ditos processos. Eles representam as operações que correspondem a uma única atividade executada pelo operador/cliente ao qual o PP está associado. Conseqüentemente, o termo, já previamente introduzido, de agente de proxy de 'administração de intervenção'. Exemplos de serviços (e conseqüentemente de intervenções) providos por um Proxy Pessoal são: executar uma conexão cruzada, instalar e configurar um modem, consertar uma falha de um equipamento (roteador, DSLAM, etc.), etc.; cada um destes pode incluir seqüências de atividades a serem executadas em um ou mais equipamentos. Os processos na camada de fundo de camada 3 usam os serviços oferecidos pelas Interfaces Pessoais Pis.

Os perfis de operador e perfis de cliente administrados por um Proxy Pessoal PP são representados no modelo de dados. Este modelo, definido por meio de uma GUI provida propositalmente, é armazenado no banco de dados ODB e é distribuído pelo Módulo administrador MM, pelos Agentes de Controle CA, aos Proxys Pessoais PPs, que o descarregam e o processam com os valores enviados pelo Administrador operacional OM e adquiridos por sistemas externos (WFM e BSS). Novamente, o processamento é executado de um modo flexível usando uma Máquina de Proxy PE. Desta maneira, mudanças e adições de modelos de dados (tal como atualização do perfil de operador/cliente, introdução de novos tipos de operador, etc.) não requerem qualquer mudança de software apreciável nos componentes da plataforma, alcançando um alto grau de flexibilidade.

Os dados dos perfis de operador e dos perfis de cliente são armazenados no Inventário de Perícia EI, que é atualizado periodicamente pelo OM usando informação adquirida de sistemas externos (sistemas de WFM para perfil de operador e sistemas de suporte empresariais para perfil de cliente). Como dito antes, as mudanças nos dados de perfil também são comunicadas aos Proxys Pessoais PPs interessados.

Os operadores podem conseqüentemente ser agrupados logicamente em Equipes Virtuais VTl, ..., VTn: uma Equipe Virtual inclui um conjunto de operadores que compartilham um dado conhecimento e/ou que trabalha em problemas comuns., As Equipes Virtuais podem, em geral, serem organizadas baseado em uma subdivisão geográfica da mão-de-obra a fim de melhorar a eficiência da solução de problema e otimizar as intervenções de campo.

Os Proxys Pessoais PPs podem interagir diretamente entre si para prover suporte para cooperação entre operadores ou entre operadores e cliente, por exemplo, para consertar uma falha complicada, preferivelmente, os Proxys Pessoais PPs também estão em comunicação com os Proxys de Recurso RPs associados aos recursos de rede diferentes; conseqüentemente, os PPs podem interagir com RPs para emitir comandos, juntar dados de configuração, resultados de medições ou resultados de verificações de execução bem sucedida, no equipamento, de algumas dadas ações pelo operador/cliente, e fazer disponível um acesso remoto para possíveis interfaces de linha de comando. As Interfaces Pessoais PI são ao invés responsáveis por administrar as interações entre os Proxys pessoais e os operadores (membros da mão-de-obra) ou clientes, qualquer que seja o tipo de dispositivo terminal que eles usem para suportar suas atividades de trabalho.

O dispositivo terminal pode ser de tipos diferentes, dependendo do uso particular ao qual está projetado. Figura 8 mostra esquematicamente um dispositivo terminal TD de acordo com a presente invenção, incluindo um Proxy Pessoal PP, que por sua vez inclui uma Máquina de Processo PE baseada em fluxo de trabalho ou baseada em regras. Também representada esquematicamente é a Interface Pessoal PI, composta por vários Widgets WI (componente gráfico com o qual um usuário interage), que permitem interação entre um usuário ou operador e os fluxos de trabalho ou regras executadas pela Máquina de Processo PE.

O fluxo de trabalho ou regra executada pela Máquina de Processo (PE) é responsável por mostrar os Widgets com os dados certos. Deste modo, a interação com o usuário é dirigida completamente pelos fluxos de trabalho ou regras executadas no dispositivo terminal.

O dispositivo terminal também inclui uma interface de intercomunicação IN provida pelo Proxy Pessoal PP para interconexão com um aplicativo de software de um aparelho de rede NA para troca de informação com ele. Preferivelmente, o aplicativo de software é um Proxy de Recurso RP provido co uma Máquina de Processo PE baseada em fluxo de trabalho ou baseada em regras. De acordo com a presente invenção, o dispositivo terminal é um dispositivo portátil, tal como um PDA, um laptop, ou um telefone celular, assim para ser particularmente adequado para intervenções em campo por engenheiros de campo.Alternativamente, o dispositivo terminal pode ser um dispositivo fixo, tal como um computador de mesa, como tipicamente usado pela mão-de-obra de Centro de Chamada.

Cada PI oferece, como serviços para os Proxys Pessoais, administração da GUI para o operador/cliente, incluindo a configuração automática da GUI baseada no tipo de dispositivo disponível.

Cada Agente Operacional OA é responsável por coordenação de um conjunto de PPs e para execução de processos típico de camada 2 usando uma Máquina de Proxy. Estes processos estão relacionados à execução distribuída de intervenções operacionais e podem ser estruturados em subcamadas. Os processos na camada de topo de camada 2 podem ser invocados externamente; assim, estes são os serviços oferecidos pelo Agente Operacional OA ao Administrador operacional OM ou outros sistemas externos. Os processos na camada de fundo da camada 2 usam os serviços (quer dizer, eles invocam processos) oferecidos pelo Proxy Pessoal PP. Um Agente Operacional OA não requer atualização de software para suportar novas práticas operacionais. Isto é devido à flexibilidade dos processos (baseado em fluxo de trabalho ou baseado em regras) que são recebidos do Módulo de Administração MM, pelo CA, descarregados e executados pela camada de OA. Os Agentes Operacionais OAs podem interagir por um Protocolo de Comunidade (um mecanismo intertrabalho baseado na troca de mensagens) para suportar a execução distribuída de atividades operacionais correlatadas entre si, tal como, por exemplo, a criação de um circuito que envolve equipamento localizado em locais geograficamente distribuídos.

O Administrador operacional OM é responsável por coordenação de primeiro nível da execução dos processos típicos de um nível de administração. Os processos de camada 1 podem ser estruturados em subcamadas e são caracterizados para prover funções que requerem interação com entidades externas à plataforma (por exemplo, sistemas de WFM ou Sistemas de Suporte Empresarial) e/ou coordenação entre Agentes Operacionais OAs, que não podem ser alcançados de um modo fácil ou efetivo apenas pelos Agentes Operacionais OAs. A grande flexibilidade da arquitetura também habilita evolução suave; por exemplo, um avanço do protocolo de comunidade pode habilitar migração de um processo de camada .1 para camada 2.

As Máquinas de Processo PE para qualquer camada são pretendidas serem uma máquina de fluxo de trabalho (isto é, um fluxograma), uma máquina de regras ou uma combinação das duas. Por exemplo, funções de suporte relacionadas a uma intervenção de campo de um operador são representadas melhor como um fluxograma enquanto funções para suportar diagnose em uma base de reclamação, no contexto de um Centro de Chamada, são representadas melhor por um conjunto de regras. Sempre que possível e aconselhável, o uso de fluxos de trabalho é preferido como evita a complexidade de lidar com conflitos de regras e administração de regras.

De acordo com a presente invenção, cada Proxy Pessoal PP inclui uma Máquina de Processo. Preferivelmente, também os Agentes Operacionais OA incluem Máquinas de Processo. Mais preferivelmente, também o Administrador operacional OM inclui uma Máquina de Processo. As Máquinas de Processo são portanto preferivelmente usadas por todo componente das camadas hierárquicas da plataforma e, se possível, elas são para serem alocadas no mesmo hospedeiro no qual o próprio componente reside a fim de melhorar os níveis de desempenho: o Administrador operacional OM, os Agentes Operacionais OAs e os Proxys Pessoais PPs apresentam um comportamento que é ambos reativo e pró-ativo, reagindo a eventos, mas também iniciando espontaneamente processos.

Os Agentes de Controle CAs são responsáveis pela distribuição do fluxos de trabalho e dos modelos de dados nos vários agentes da plataforma, para a medição do uso dos recursos e desempenho dos agentes locais (isto é, os que são executados no hospedeiro), e, finalmente, para a otimização local da administração de recurso. As medições são enviadas ao Módulo administrador MM e para outros Agentes de Controle CAs.

A mobilidade entre hospedeiros, administrada pelo Módulo administrador MM ou por um Controle Agente CA dos Agentes Operacionais OAs e dos Proxys Pessoais PPs faz os procedimentos de desenvolvimento, balanceamento de carga e tolerância a falhas mais eficiente e automático. Se agente por qualquer razão "desativar", a solução pode ser clonar ou mover o agente para outro hospedeiro corrente. O Módulo administrador MM, pelo Controle Agente CA, controla periodicamente o estado operacional dos Agentes Operacionais OAs e dos Proxys Pessoais PPs para ditos propósitos. A fim de monitorar desempenho, os componentes da plataforma devem ser capazes de monitorar também execução dos vários processos. No caso do Proxy Pessoal PP, monitoração da execução dos vários processos também é útil em uma perspectiva de identificação de Melhor Prática.

Como já foi dito, a solução descrita aqui é visada para administrar e suportar a operação da mão-de-obra e do cliente. Isto é obtido por um conjunto de serviços feitos disponíveis aos operadores/clientes.

Com referência à estrutura de eTOM (documentos: TeleManagementForum GB921 e GB921D, versão 4.0, de março de 2004 e versão 5.0 em Avaliação de Membro, de abril de 2005), uma primeira concretização da solução descrita na presente invenção provê suporte para operadores e clientes que efetuam atividades se referindo aos agrupamentos de processo de ponta a ponta verticais de Nível 1 seguintes:

- Administração de Vida de Infra-estrutura (área de processo: Estratégia, Infra-estrutura e Produto);

- Suporte e Prontidão de Operações (área de processo: Operações);

- Cumprimento (área de processo: Operações);

- Garantia (área de processo: Operações).

Considerando agora a dimensão horizontal da estrutura de eTOM, os agrupamentos de processo funcionais horizontais de Nível 1 nos quais as atividades de operadores e clientes caem são:

- Desenvolvimento e Administração de Recurso (área de processo: Estratégia, Infra-estrutura e Produto);

- Administração de Relação de Cliente (área de processo: Operações);

- Conserte Administração e Operações (área de processo: Operações); e

- Administração e Operações de Recurso (área de processo: Operações).

Administração e compartilhamento do conhecimento operacional para operadores e clientes podem, em troca, cair na área de processo Administração de Empreendimento e, em particular, ao agrupamento de processo Nível 1 conhecido como Administração de Conhecimento e Pesquisa.

O fluxograma da Figura 3 mostra, por meio de exemplo, um procedimento para suportar engenheiros de campo.

Em primeiro lugar, a plataforma descrita acima guia o operador, confiado com efetuar uma dada atividade, mostrando a ele as atividades pontuais a serem executadas; os modos operacionais com os quais a plataforma oferece dito serviço com referência a engenheiros de campo são apresentados na Figura 3 e descritos em seguida.

Ajusante da seleção pelo engenheiro de campo da intervenção a ser efetuada (etapa 100), o Proxy Pessoal associado a ele exibe (etapa 110) no dispositivo terminal do engenheiro de campo, usando a Interface PI correspondente, sinais de instrução organizados como fluxos de trabalho visados a consertar uma falha ou executar uma Ordem de Trabalho, relacionada, por exemplo, a atividades de Provisão ou Operação (tais como atualizações de banco de dados, etc.). Exibida no dispositivo do engenheiro de campo é uma seleção específica de fluxos de trabalho, que o guia na execução da intervenção de acordo com práticas que são alternativas entre si. Os fluxos de trabalho individuais contêm toda a informação necessária para o engenheiro de campo executar a intervenção específica, incluindo dados específicos possíveis relativos à própria intervenção, tais como os requeridos para identificar o componente de um equipamento no qual operar: por exemplo, se uma etapa de um fluxo de trabalho guiar o engenheiro de campo na atividade de mudar uma placa de um equipamento, dita etapa contém também a indicação que habilita o engenheiro de campo identificar de um modo fácil e único a placa a ser mudada. Cada fluxo de trabalho é apresentado, também indicando a contagem que foi nomeada a ele e que reflete uma avaliação averiguada da efetividade e eficiência do próprio fluxo de trabalho a fim de melhor alcançar o objetivo da intervenção. Dita contagem também determina a ordem de apresentação dos fluxos de trabalho (listados a partir do com a contagem mais alta).

Antes de decidir se selecionar um dos fluxos de trabalho indicados, o engenheiro de campo pode pedir o Proxy Pessoal PP para juntar dados de medição ou prover informação sobre a configuração de equipamento. O pedido requer uma troca de informação entre o Proxy Pessoal PP e o Proxy de Recurso RP, com o pedido do engenheiro de campo remetido do Proxy Pessoal PP para o Proxy de Recurso RP e a resposta correspondente, enviada pelo Proxy de Recurso RP para o Proxy Pessoal PPj apresentada ao engenheiro de campo pela Interface PI (a atividade inteira corresponde à etapa .120).

Além disso, o engenheiro de campo também pode pedir que um ou mais dos fluxos de trabalho propostos deveria ser exibido (etapa 130) assim para ter informação adicional antes de decidir como proceder. O engenheiro de campo pode então decidir (etapa 140) selecionar um ou nenhum dos fluxos de trabalho apresentados; no caso de seleção, há a ativação no PP do fluxo de trabalho escolhido (etapa 150).

Ajusante da ativação de um fluxo de trabalho, um processo de registrar todas as atividades executadas pelo engenheiro de campo é começado (etapa 160). Informação juntada é armazenada no registro operacional OL e então pode ser processada para refinar os fluxos de trabalho existentes ou para o propósito de gerar e validar novos fluxos de trabalho.

Em paralelo à ativação do fluxo de trabalho no Proxy Pessoal PP, há a ativação no Proxy de Recurso RP que administra o equipamento no qual o engenheiro de campo deve operar de um fluxo de trabalho cooperativo que coopera com o no Proxy Pessoal (etapa 170). É o fluxo de trabalho no próprio Proxy Pessoal PP que, como uma primeira etapa, ativa um fluxo de trabalho 'cooperativo' específico no Proxy de Recurso RP. Os dois fluxos de trabalho são executados de um modo independente, exceto para coordenação em alguns pontos nos quais eles podem usar mecanismos de espera mútua para trocar resultados de processamento. Alguns exemplos de permutas de informação são dados no seguinte.

Pode haver então trocas de informação (etapa 180) entre Proxys Pessoais PPs e Proxys de Recurso RPs para enviar, de Proxys de Recurso RPs paro Proxys Pessoais PPs:

- possíveis dados sobre a configuração do equipamento, ou resultados de medições no equipamento, no qual o engenheiro de campo está intervindo, que são requeridos para executar as etapas subseqüentes do fluxo de trabalho. Estes dados são enviados automaticamente, sem qualquer pedido pelo engenheiro de campo, como o Proxy de Recurso RP está sincronizado com as atividades que estão sendo executadas e conhece ambos os tempos envolvidos e o tipo de informação requerida;

- a indicação que as atividades de configuração executadas autonomamente pelo Proxy de Recurso RP em pontos apropriados do fluxo de trabalho foram efetuadas realmente;

- os resultados da verificação, executados autonomamente pelo Proxy de Recurso RP, da execução bem sucedida da intervenção pelo engenheiro de campo (no caso de falha, verificação de seu conserto, no caso de Prover Ordem de Trabalho, verificação da execução correta das atividades de configuração pedidas).

Seguindo na recepção pelo engenheiro de campo pelo Proxy Pessoal PP da indicação, vindo da RP, da conclusão bem sucedida da intervenção (etapa 190), a intervenção é considerada encerrada (etapa 200), e o engenheiro de campo pode selecionar uma intervenção subseqüente.

No caso de onde um engenheiro de campo decide não selecionar qualquer dos fluxos de trabalho propostos a ele, ou senão, se não existir qualquer fluxo de trabalho associado à intervenção a ser executada, o engenheiro de campo pode em qualquer caso pedir, pelo Proxy Pessoal PPj que, por sua vez, se conecta com o Proxy de Recurso RP apropriado, informação, medições ou execução de comandos no equipamento no qual ele deve operar, também provendo um acesso remoto à Interface de Linha de Comunicação (CLI) do equipamento. Isto é feito como suporte para a execução da intervenção (etapa 220) e/ou como verificação da execução correta disso (etapa 230), antes de encerrar a intervenção (etapa 200). Além disso, todas as atividades executadas pelo engenheiro de campo são registradas (etapa 210), e informação juntada é armazenada no Registro Operacional e pode ser processada subseqüentemente para o propósito de gerar e validar novos fluxos de trabalho ou para refinar fluxos de trabalho existentes.

O técnico que escolheu seguir as etapas indicadas por um fluxo de trabalho específico pode interromper a qualquer momento a execução do próprio fluxo de trabalho e proceder sem qualquer demora sendo guiado, interagindo com o equipamento (pela cadeia entre Proxys Pessoais PPs e Proxys de Recurso RPs) para obter informação e/ou efetuar ações no próprio equipamento.

Figura 4 apresenta um exemplo de fluxo de trabalho cooperativo para substituição de uma placa de equipamento. Em particular, Figura 4 em questão apresenta um exemplo de fluxo de trabalho cooperativo visado a guiar os engenheiros de campo em uma atividade de substituição de uma placa em um equipamento.

O engenheiro de campo, a jusante da escolha do fluxo de trabalho a ser ativado de acordo com os critérios previamente descritos, requer a iniciação, pela Interface PI, do fluxo de trabalho selecionado no Proxy Pessoal PP (etapa 1100).

O fluxo de trabalho na ponta de Proxy Pessoal PP começa (etapa 300) e, como primeira ação, começa o fluxo de trabalho cooperativo relacionado no Proxy de Recurso RP (etapa 310). Ao engenheiro de campo é enviada uma mensagem na Interface PI para esperar iniciação do fluxo de trabalho RP (etapa 1110).

O fluxo de trabalho de Proxy Pessoal PP procede com as atividades preliminares à substituição da placa, indicando ao engenheiro de campo as instruções para abrir o equipamento (etapa 320) por descrição na Interface PI das operações manuais a serem executadas (etapa 1120) e as indicações para identificar a placa dentro do equipamento (etapa 330), uma vez mais por exibição na Interface PI (etapa 1130), também pela ajuda de esquemas que facilitam a identificação da placa.

Ao mesmo tempo, o fluxo de trabalho de Proxy de Recurso RP procede com as atividades de administração introdutórias à substituição da placa (etapa 510), tal como, por exemplo, a desativação ou deslocamento de serviços ainda ativos nela ou colocando a placa em um estado não operacional. Quando ditas atividades ocorreram, o fluxo de trabalho de Proxy de Recurso RP notifica o fluxo de trabalho de Proxy Pessoal PP que pode proceder (etapa 520).

O fluxo de trabalho de Proxy Pessoal PP notifica o engenheiro de campo para desconectar a fiação para a placa que está sendo substituída (etapa 340), apresentando informação útil para atividade manual na Interface PI (etapa 1140), enquanto notifica o fluxo de trabalho de Proxy de Recurso RP para proceder com a próxima etapa de supervisão da atividade (etapa 530), tal como, por exemplo, verificação de se as portas físicas envolvidas sinalizam o estado de fiação desconectada. Quando toda a fiação da placa a ser substituída foi desconectada, o fluxo de trabalho de Proxy de Recurso RP notifica o fluxo de trabalho PP (etapa 530).

O fluxo de trabalho de Proxy Pessoal PP procede com a verificação sobre se a placa está pronta para remoção do equipamento (etapa .350), avançando o fluxo de trabalho de Proxy de Recurso RP sobre a atividade de liberação de placa (etapa 540) e indicando ao engenheiro de campo para verificar o sinal de placa liberada (etapa 1150).

Quando o fluxo de trabalho de Proxy de Recurso RP completa as atividades de liberação de placa, como, por exemplo, colocando a placa no estado desligado, notifica o fluxo de trabalho de Proxy Pessoal PP (etapa .540), que procede com a ação de remoção física atual da placa (etapa 360), indicando ao engenheiro de campo as atividades manuais a serem executadas (etapa 1160), tais como alavancas de liberação a serem ativadas e indicações das práticas para remover a placa.

O fluxo de trabalho de Proxy de Recurso RP supervisiona a atividade manual, verificando o estado e sinais vindo do equipamento (etapa .550), tal como, por exemplo, o estado de abertura livre, e notifica o fluxo de trabalho de Proxy Pessoal PP quando a placa não está mais presente.

O fluxo de trabalho de Proxy Pessoal PP, tendo recebido as mensagens de conclusão das atividades ambos do fluxo de trabalho de Proxy Pessoal PP e do engenheiro de campo pela Interface PI, procede com a ação de inserção da placa nova (etapa 370), enviando a informação necessária para a Interface PI (etapa 1170) e notificando o fluxo de trabalho de Proxy de Recurso RP. O anterior supervisiona a inserção da placa nova (etapa 560), por exemplo, verificando se a abertura passou do estado livre para o estado ocupado, até notificação ao fluxo de trabalho de Proxy Pessoal PP da inserção correta da placa nova (etapa 570).

O fluxo de trabalho de Proxy de Recurso RP procede com as verificações e configuração da placa nova (etapa 580), enquanto o fluxo de trabalho de Proxy Pessoal PP espera a conclusão da atividade anterior (etapa .380) e notifica o engenheiro de campo pela Interface PI da verificação em desenvolvimento (etapa 1180).

Ao término da configuração da placa nova, o fluxo de trabalho de Proxy de Recurso RP notifica o fluxo de trabalho de Proxy Pessoal PP (etapa 580) para proceder com a conexão da fiação (etapa 390), por apresentação ao engenheiro de campo na Interface PI das atividades manuais a serem executadas (etapa 1190) com a ajuda de esquemas relativos ao tipo de placa e fiação.

Durante a conexão da fiação, o fluxo de trabalho de Proxy de Recurso RP supervisiona as portas da placa (etapa 590), por exemplo controlando o estado das portas que indica fiação conectada. Só quando toda a fiação envolvida foi reconectada, o fluxo de trabalho de Proxy de Recurso RP notifica o fluxo de trabalho de Proxy Pessoal PP (etapa 590) e procede com a verificação e configuração das portas (etapa 600), tal como, por exemplo, reativação dos serviços ou sua transição da configuração temporária

previamente executada (etapa 510).

O fluxo de trabalho de Proxy Pessoal PP espera a conclusão das configurações das portas da placa nova (etapa 400) e notifica o engenheiro de campo pela Interface PI (etapa 1200) que dita atividade está em desenvolvimento. Uma vez que a configuração das portas esteja completada (etapa 600), o fluxo de trabalho de Proxy de Recurso RP notifica o fluxo de trabalho de Proxy Pessoal PP e termina (etapa 610), enquanto o fluxo de trabalho de Proxy Pessoal PP guia o engenheiro de campo para efetuar o fechamento do gabinete do equipamento (etapa 410) provendo informação apropriada na Interface PI (etapa 1210).

Finalmente, o fluxo de trabalho de Proxy Pessoal PP completa sua execução (etapa 420), notificando o engenheiro de campo que fim dos fluxos de trabalho está sendo esperado (etapa 1220) e esperando por conclusão do fluxo de trabalho de Proxy de Recurso RP. O fluxos de trabalho terminam, sincronizando na última ação do fluxo de trabalho PP (etapa 430), com informação ao engenheiro de campo de intervenção concluída com sucesso (etapa 1230). Figura 5 ilustra, ao invés, um exemplo de procedimento para suportar consultores de Centro de Chamada: a solução descrita aqui na realidade habilita aplicação do serviço de guia também para consultores de Centro de Chamada.

Seguindo no recebimento, pelo consultor de Centro de Chamada, de uma reclamação de cliente (em seguida chamada Relatório de Dificuldade: TR) ou de um pedido para um novo serviço (em seguida chamado Pedido de Cliente: CO) (etapa 1300), o Proxy Pessoal PP associada ao consultor de Centro de Chamada abre uma sessão com o Proxy/Proxys de Recurso RP associadas aos equipamentos de rede de interesse para o pedido de cliente e coleta informação requerida para sua interação com o cliente (no caso de um Relatório de Dificuldade, é verificado se há falhas nos equipamentos envolvidos na oferta de serviço de cliente) (etapa 1310).

Seguindo na coleta dos dados da rede, se o Proxy Pessoal PP não requerer qualquer informação adicional (verificação feita na etapa 1320) e estiver lidando com uma reclamação de cliente (verificação feita na etapa .1330), os dados juntados são processados a fim de efetuar uma primeira diagnose (etapa 1380). Se, ao invés, o Proxy Pessoal PP não requerer informação adicional (verificação feita na etapa 1320) e estiver lidando com um pedido para um novo serviço (verificação feita na etapa 1330), a próxima etapa é a criação de um Pedido de Trabalho (WO) (etapa 1420).

Seguindo na coleta dos dados da rede, se o Proxy Pessoal PP requerer informação adicional (verificação feita na etapa 1320), ela exibe no dispositivo do consultor de Centro de Chamada (etapa 1340), usando a Interface PI correspondente, uma seqüência de perguntas visadas a adquirir detalhes adicionais sobre o TR/CO do cliente. No caso de Relatório de Dificuldade, ditas perguntas também podem ser pedidos ao cliente para executar verificações/ações pontuais, que podem conduzir a resolver o problema que é a causa do Relatório de Dificuldade, por exemplo, pedidos para verificar se toda a fiação de um Equipamento de Instalação de Cliente (CPE) está conectada corretamente e procedendo para corrigir conexão da fiação na qual falhas de conexão são detectadas.

O consultor de Centro de Chamada, interagindo com o cliente, provê o Proxy Pessoal PP com as respostas apropriadas para as perguntas postas a ele (etapa 1350). No caso onde o cliente não é capaz de prover os dados pedidos ou a fim de integrar os dados providos por ele, o consultor de Centro de Chamada pode pedir o Proxy Pessoal PP para juntar dados de medição ou prove-lo com informação de configuração relacionada à porção de rede de interesse para o cliente específico. Isto requer uma troca de informação entre os Proxys Pessoais PPs e os Proxys de Recurso RPs que controlam dita porção de rede, com o pedido do consultor de Centro de Chamada remetido pelo Proxy Pessoal PP para o Proxy de Recurso RP e as respostas correspondentes enviadas pelo Proxy de Recurso RP para o Proxy Pessoal PP e mostrado pelo anterior ao operador pela Interface PI (a atividade inteira corresponde à etapa 1360).

Ao término da seqüência de perguntas ou, no caso de um Relatório de Dificuldade, a jusante da solução do próprio Relatório de Dificuldade baseado em uma verificação/ação do cliente (verificação feita na etapa 1370), a próxima etapa é etapa 1420.

No caso de um Relatório de Dificuldade (verificação feita na etapa 1370) pelo cliente, ao término da etapa de coleta guiada dos dados (do cliente e/ou da rede), o Proxy Pessoal PP, usando um sistema baseado em regras, formula uma primeira hipótese sobre a causa raiz do Relatório de Dificuldade (etapa 13 80).

Se a falha puder ser consertada pelo cliente (verificação feita na etapa 1390), o Proxy Pessoal PP do consultor de Centro de Chamada abre uma sessão com o Proxy Pessoal PP do cliente, pedindo a ele para executar um fluxo de trabalho específico para resolver o Relatório de Dificuldade

(Lv (etapa 1400). O consultor de Centro de Chamada pode então passar para a execução de outras atividades, ao mesmo tempo sendo informado do resultado da execução do fluxo de trabalho pelo cliente.

No recebimento do resultado do fluxo de trabalho (etapa .1410), um Tíquete de Dificuldade (TT) apropriado é criado, que levará em conta o resultado do fluxo de trabalho (se o fluxo de trabalho foi executado com êxito, o TT registrará a solução do Relatório de Dificuldade; caso contrário, conterá informação útil para criar um ou mais Pedidos de Trabalho WR para os engenheiros de campo).

Se a falha não puder ser resolvida pelo cliente (verificação feita na etapa 1390), a próxima etapa é a criação de um Tíquete de Dificuldade (etapa 1420). Seguindo na coleta dos dados no Relatório de Dificuldade/Pedido de Cliente e, no caso de Relatório de Dificuldade, a jusante da diagnose de primeiro-nível e/ou da solução do Relatório de Dificuldade, o Proxy Pessoal PP provê o consultor de Centro de Chamada com todos os dados requeridos para criar um Tíquete de Dificuldade ou um Pedido de Trabalho, que, no caso de um pedido de cliente ainda não satisfeito, produzirá em um ou mais Pedidos de Trabalho WR para os engenheiros de campo (etapa 1420). A jusante da criação do TT/WO, a atividade do consultor de Centro de Chamada termina (etapa 1430).

O fluxograma da Figura 6 se refere, ao invés, a um procedimento para suportar clientes; o suporte para a execução de atividades operacionais descritas aqui também se aplica ao cliente.

Seguindo na detecção, por um cliente, de qualquer mau funcionamento (etapa 700), o próprio cliente ativa em seu dispositivo (tipicamente um PC ou PDA) o Proxy Pessoal PP associada a ele (etapa 710).

O Proxy Pessoal PP abre uma sessão com o Proxy/Proxys de Recurso RP associadas com os equipamentos localizados nas instalações de cliente, a fim de identificar qualquer possível falha em ditos equipamentos (etapa 720). No caso onde nenhuma falha está presente nos equipamentos nas instalações de cliente (verificação feita na etapa 730), o Proxy Pessoal PP exibe no dispositivo do cliente (etapa 740), usando a interface PI correspondente, uma seqüência de perguntas visadas a adquirir detalhes adicionais sobre o mau funcionamento detectado. O cliente provê o Proxy Pessoal PP com as respostas apropriadas para as perguntas postas a ele (etapa .750).

Ao término da seqüência de perguntas, o Proxy Pessoal PP verifica se a causa do mau funcionamento foi identificada e se dita causa pode ser removida pelo cliente (verificação feita na etapa 760) e, nesse caso, ativa um fluxo de trabalho apropriado (etapa 770), que guia o cliente em resolver o problema. O Proxy Pessoal PP também ativa um processo de registro das atividades de cliente (etapa 780): a informação juntada é armazenada no Registro Operacional e pode ser processada subseqüentemente para refinar os fluxos de trabalho existentes ou a fim de gerar e validar novos fluxos de trabalho.

Ao término do fluxo de trabalho, uma verificação é feita, pelo cliente, sobre a remoção do mau funcionamento (etapa 790); se dita verificação tiver um resultado positivo, a atividade do cliente termina (etapa .810). Se, ao invés, a verificação tiver um resultado negativo, o Proxy Pessoal PP notifica o cliente para contatar o Centro de Chamada (etapa 800); a jusante da notificação pelo Proxy Pessoal PP, a atividade do cliente termina (etapa .810). Se a causa do mau funcionamento não foi identificada ou senão, se não puder ser removida pelo cliente (verificação feita na etapa 760), o Proxy Pessoal PP notifica o cliente para contatar o Centro de Chamada (etapa 800).

Seguindo em dita notificação pelo Proxy Pessoal PP, a atividade do cliente termina (etapa 810).

No caso onde há falhas em equipamentos nas instalações de cliente (verificação feita na etapa 730), o Proxy Pessoal PP efetua uma verificação adicional para verificar se ditas falhas podem ser consertadas pelo cliente (verificação feita na etapa 820) e, no caso de um resultado positivo, ativa um fluxo de trabalho apropriado (etapa 770), que guia o cliente em resolver o problema.

Depois de ativação do fluxo de trabalho apropriado, o Proxy Pessoal PP também ativa um processo de registro das atividades de cliente (etapa 780): a informação juntada é armazenada no Registro Operacional e, como já mencionado, pode ser processada a fim de refinar fluxos de trabalho existentes ou gerar e validar novos fluxos de trabalho. Ao término do fluxo de trabalho, uma verificação é feita, pelo cliente, sobre a remoção do mau funcionamento (etapa 790); se dita verificação tiver um resultado positivo, a atividade do cliente termina (etapa 810). Se5 ao invés, a verificação tiver um resultado negativo, o Proxy Pessoal PP notifica o cliente para contatar o Centro de Chamada (etapa 800); a jusante da notificação pelo Proxy Pessoal PP, a atividade do cliente termina (etapa 810).

Os fluxos de trabalho executados no Proxy Pessoal PP do cliente idealizam normalmente que o cliente será informado também de possíveis ações efetuadas automaticamente pelos Proxys de Recurso RPs e que ele pode conceder um consentimento explícito para sua execução.

O fluxograma da Figura 7 ilustra um procedimento para cooperação entre operadores. A plataforma descrita aqui na realidade provê um serviço adicional para suportar o operador, confiado com efetuar uma dada atividade (por exemplo, uma intervenção em campo ou operação de um pedido de cliente), administrando as interações com possíveis outros operadores ou entre um operador e um cliente.

As práticas operacionais adotadas para interação entre operadores são descritas no seguinte.

O Proxy Pessoal PP autonomamente (por exemplo, a jusante de detecção de uma intervenção que foi malsucedida no caso de engenheiros de campo) ou na notificação pelo operador, decide ativar uma sessão para os Proxys Pessoais PPs de outros operadores (etapa 1500).

No caso de ativação automática (verificação feita na etapa 1510), o Proxy Pessoal PP, baseado no conhecimento do tipo de atividade que o operador está executando (deduzida dos dados disponíveis ou derivando de uma indicação explícita do operador) e das macro-habilidades requeridas para efetuá-la, tenta ativar uma sessão usando uma lista ordenada de nomes de operadores a serem contatados, arranjados de acordo com macro-habilidades (etapa 1600).

Se a ativação não for bem sucedida (verificação feita na etapa 1610), o Proxy Pessoal PP verifica com o operador (etapa 1640) se proceder em sua tentativa para ativar uma sessão, ou parar. Se o operador decidir continuar, o Proxy Pessoal PP faz outra tentativa para ativar uma sessão com o próximo nome na lista (etapa 1600) e procede iterativamente até que administre para ativar uma sessão ou até que o operador decida interromper o procedimento. No caso anterior, o Proxy Pessoal PP termina o procedimento de ativação de sessão (etapa 1590).

Se a ativação for bem sucedida (verificação feita na etapa 1610), uma sessão é começada entre operadores, em que o Proxy Pessoal PP faz disponível um conjunto de ferramentas para trabalho cooperativo, tal como fazendo visível para ambos operadores todos os dados sobre a atividade a ser efetuada e sobre as etapas já efetuadas ou para compartilhar possíveis dados de rede que o operador, que pediu o suporte, já tinha adquirido (etapa 1620).

Na notificação do operador, o Proxy Pessoal PP então procede para encerrar a sessão (etapa 1570).

No caso de ativação no pedido pelo operador (verificação feita na etapa 1510), o Proxy Pessoal PP, baseado no conhecimento do tipo de atividade que o operador está efetuando (deduzida dos dados disponíveis ou derivando de uma indicação explícita do operador) e das macro-habilidades requeridas para efetuá-lo, apresenta (etapa 1520) uma lista ordenada de nomes (a ordem é o que o Proxy Pessoal PP seguiria se tivesse que ativar a sessão autonomamente), entre os quais o operador seleciona o desejado (etapa 1530).

A jusante de seleção do nome pelo operador, o Proxy Pessoal PP tenta estabelecer uma sessão para o Proxy Pessoal PP associada a dito nome (etapa 1540). Se a ativação for malsucedida (verificação feita na etapa 1550), o Proxy Pessoal PP verifica com o operador (etapa 1580) se proceder com a tentativa para ativar uma sessão, ou parar. Se o operador decidir continuar, o Proxy Pessoal PP uma vez mais exibe a lista de nomes, apropriadamente atualizada a fim de levar em conta a tentativa/tentativas malsucedidas (etapa 1520) e procede iterativamente até que administre para ativar uma sessão ou até que o operador decida interromper o procedimento. No caso anterior, o Proxy Pessoal PP termina o procedimento de ativação de sessão (etapa 590).

Se a ativação for bem sucedida (verificação feita na etapa 1550), uma sessão entre operadores é começada, na qual o Proxy Pessoal PP faz disponível um conjunto de ferramentas para trabalho cooperativo, do tipo já previamente considerado (etapa 1560). Na notificação do operador, o Proxy Pessoal PP procede então para encerrar a sessão (etapa 1570).

A interação entre cliente e o operador usa mecanismos semelhantes para os referidos acima para interação entre operadores; neste caso, é possível imaginar que a cooperação envolverá normalmente o cliente e um consultor de Centro de Chamada e que será o Proxy Pessoal PP do cliente, no pedido do próprio cliente ou autonomamente, que estabelecerá uma sessão. Também neste caso, o cliente pode decidir interromper a tentativa para estabelecer uma sessão com um operador a qualquer momento. No caso de um pedido de cliente, o Proxy Pessoal PP apresenta o próprio cliente com a lista ordenada de nomes de consultores de Centro de Chamada e permite ao cliente selecionar o consultor a ser contatado.

A fim de oferecer os serviços exemplificados acima, a plataforma descrita mantém um conjunto de dados sobre os operadores, sobre os clientes, e sobre os fluxos de trabalho, e executa uma administração dinâmica dos processos, para adaptar ambos a mudanças operacionais (introdução de novos fluxos de trabalho seguindo na introdução de novos equipamentos, apagamento de fluxos de trabalho se referindo a atividades em equipamentos que não estão mais na rede, etc.), e a mudanças das características e do número de membros da mão-de-obra (introdução de novos operadores, atualização dos dados dos perfis de operador, etc.) e dos clientes (introdução de novos clientes, atualização dos dados dos perfis de cliente, etc.).

Os perfis de operador são definidos baseado em um pequeno número de perfis básicos padrão; ditos perfis especificam as macro- habilidades (por exemplo domínios de rede/serviço nos quais o operador pode efetuar atividades: comutação, transmissão, acesso de ADSL, etc.) dos operadores e, para cada macro-habilidade, o grau correspondente (indica quanto o operador está qualificado em um dado campo). O perfil também realça se o operador é um engenheiro de campo ou um operador de retaguarda, ou um consultor de Centro de Chamada mostra a qual equipe virtual ele pertence, e provê suas credenciais de autenticação. Os dados de ditos perfis são atualizados dinamicamente para levar em conta, por exemplo, novas macro -habilidades ou mudanças em grau; o modelo dos perfis é armazenado no banco de dados ODB. A atualização dinâmica das macro- habilidades é efetuada de um modo oportuno, para habilitar todos os serviços de plataforma (por exemplo, aquele de interação entre operadores) a usar dados atualizados. Com respeito o descarregamento dos dados dos perfis de operador, cada Proxy Pessoal PP mantém só o perfil do operador ao qual está associada (cada Proxy Pessoal PP está associada a um operador específico): os dados de dito perfil são adquiridos pelo OM interagindo com sistemas externos apropriados (sistemas de WFM); a plataforma então idealiza um inventário centralizado (Inventário de Perícia EI), em que os dados dos perfis de todos os operadores (carregado do WFM) estão armazenados. Na iniciação de cada Proxy Pessoal PP, os dados de perfil de operador associados a dito Proxy Pessoal PP são descarregados automaticamente do Inventário de Perícia EI, pelo Administrador operacional OM, sobre o próprio Proxy Pessoal PP. O inventário EI é atualizado periodicamente e, a cada atualização dos dados no próprio inventário, dados são enviados ao Proxy Pessoal PP correspondente.

Os perfis de cliente são definidos na base de um pequeno número de perfis básicos padrão; ditos perfis especificam o serviço/serviços, para o qual o cliente pode efetuar atividades de auto-conserto (por exemplo, serviço de ADSL, serviço de ISDNS, etc.), e as credenciais de autenticação do cliente. Os dados dos perfis são atualizados dinamicamente a fim de levar em conta, por exemplo, novos serviços que foram assinados; o modelo dos perfis é armazenado no banco de dados ODB. A atualização dinâmica dos dados dos perfis de cliente é feita de um modo oportuno a fim de habilitar todos os serviços de plataforma usarem dados atualizados. Com respeito o descarregamento dos dados dos perfis de cliente, cada Proxy Pessoal PP mantém apenas o perfil do cliente ao qual está associado (cada Proxy Pessoal PP está associada a um cliente específico): os dados de dito perfil são adquiridos pelo Administrador OM Operacional interagindo com sistemas externos apropriados (Sistemas de Suporte Empresarial); a plataforma então idealiza um inventário centralizado (Inventário de Perícia EI) em que os dados dos perfis de todos os clientes (carregados dos Sistemas de Suporte Empresarial) são armazenados. Na iniciação de cada Proxy Pessoal PP, os dados do perfil de cliente associados ao dito Proxy Pessoal PP são descarregados automaticamente do inventário EI, pelo Administrador operacional OM, sobre o próprio Proxy Pessoal PP. O inventário EI é atualizado periodicamente, e a cada atualização dos dados no próprio inventário, dados são enviados ao Proxy Pessoal PP correspondente.

Com respeito a fluxos de trabalho em suporte de operação dos engenheiros de campo, o banco de dados ODB mantém, para cada fluxo de trabalho, um conjunto de características como o identificador de fluxo de trabalho (este pode ser um identificador numérico progressivo gerado automaticamente pela plataforma), a versão do fluxo de trabalho, a contagem do fluxo de trabalho, o tipo de intervenção ao qual o fluxo de trabalho se aplica (por exemplo, falha, atividades de Provisão, atividades de operação, etc.), o identificador da intervenção específica a ser executada (por exemplo, no caso de falha, é possível indicar falha de ligação, falha de placa de usuário, etc.), o grau de macro-habilidades requeridas para efetuar a intervenção, se aplicável (por exemplo, engenheiro de campo perito e engenheiro de campo iniciante), etc. Ditas características são providas quando o fluxo de trabalho é criado/modificado; a contagem é atualizada dinamicamente, de acordo com o que é mencionado abaixo. A criação/modificação dos fluxos de trabalho suportando operação, armazenados no banco de dados OBD, e dos fluxos de trabalho cooperativos correspondentes, armazenados no banco de dados MDB, é feita por uma interface gráfica apropriada que habilita edição paralela do dois fluxos de trabalho correlatado a fim de facilitar verificações de congruência sobre o foi processado.

Considerações semelhantes se aplicam com respeito a fluxos de trabalho suportando operação de cliente: o banco de dados ODB mantém, para cada fluxo de trabalho em suporte do cliente, um conjunto de características semelhantes às dos fluxos de trabalho para o engenheiro de campo e também aplicáveis ao caso de cliente.

Para os fluxos de trabalho em suporte dos engenheiros de campo, duas funções de administração são idealizadas. Com respeito o descarregamento de fluxos de trabalho, descarregamento do fluxo de trabalho no Proxy Pessoal PP será efetuado pelo Agente de Controle CA associado a isso. Na iniciação do Proxy Pessoal PP, nenhum fluxo de trabalho é descarregado; os fluxos de trabalho são descarregados sobre o Proxy Pessoal PP só no pedido explícito pelo próprio Proxy Pessoal PP: a jusante da suposição de uma dada atividade por um engenheiro de campo e da seleção por ele de um fluxo de trabalho a ser efetuado ou ser exibido no seu dispositivo, o Proxy Pessoal PP verifica se dito fluxo de trabalho é acessível diretamente na medida em que já está presente na área de memória local e se está atualizado (pelo indicador de versão associado ao fluxos de trabalho). Se o fluxo de trabalho não estiver presente ou não atualizado, pelo Agente de Controle CA, é descarregado do banco de dados ODB; o fluxo de trabalho permanecerá armazenado no Proxy Pessoal PP para qualquer possível uso futuro.

De um modo semelhante, na iniciação do Proxy de Recurso RP nenhum fluxo de trabalho é descarregado; os fluxos de trabalho são descarregados sobre o Proxy de Recurso RP só no pedido explícito pela próprio Proxy de Recurso RP: no momento em que o Proxy de Recurso RP recebe do Proxy Pessoal PP o pedido para ativar um dado fluxo de trabalho em suporte de operação, o Proxy Pessoal PP verifica se isto está diretamente acessível na medida em que já está presente na área de memória local e se está atualizado (pelo indicador de versão associado aos fluxos de trabalho). Se o fluxo de trabalho não estiver presente ou não estiver atualizado, o Proxy de Recurso RP o descarrega do banco de dados MDB; o fluxo de trabalho permanecerá armazenado no Proxy de Recurso RP para possíveis usos futuros.

Um procedimento para administrar dinamicamente a "contagem" dos fluxos de trabalho é então idealizado. A contagem do fluxo de trabalho é baseada ambos nos dados de tempo/custo (ligados às atividades executadas pelo engenheiro de campo e ao custo de materiais usados para executar estas atividades) e as preferências do engenheiro de campo para um dado fluxo de trabalho. A fim de adquirir estes dados, a cada execução de um fluxo de trabalho, um conjunto de parâmetros, ligados à dita execução, é juntado (a coleção dos parâmetros de fluxo de trabalho é executada pelos Proxys Pessoais PPs) e atualizado. Exemplos de tais parâmetros são tempo total de execução do fluxo de trabalho no Proxy Pessoal PP, uso de CPU5 número de operadores que escolheram o fluxo de trabalho, etc. Os dados juntados/atualizados são armazenados no Banco de Dados de Desempenho PDB. Periodicamente (por exemplo, a intervalos de tempo fixos), é necessário analisar e processar ditos parâmetros para obter um novo valor da contagem para cada fluxo de trabalho. A nova contagem dos fluxos de trabalho é então comunicada aos vários Proxys Pessoais PPs.

Funções de administração semelhantes são providas para fluxos de trabalho suportando os clientes: os fluxos de trabalho são descarregados sobre o Proxy Pessoal PP no pedido pela próprio Proxy Pessoal PP, a jusante da identificação da falha/problema a ser operado com ditos fluxos de trabalho ou na recepção do pedido para ativar um fluxo de trabalho específico vindo do Proxy Pessoal PP de um consultor de Centro de Chamada. Em particular, no caso de vários fluxos de trabalho que podem ser usados para guiar o cliente, só o fluxo de trabalho que naquele momento tem a contagem mais alta é descarregado no Proxy Pessoal PP. Também para fluxos de trabalho para o cliente, um mecanismo de administração dinâmica da contagem é provido, calibrado apropriadamente nos parâmetros que podem ser identificados na ponta de cliente.

Como foi visto, a interação entre o Proxy Pessoal PP e o operador ou o cliente é realizada usando uma Interface Pessoal PI apropriada. A Interface PI é criada usando tecnologias que dependem do tipo e potência computacional do dispositivo usado pelo operador/cliente (PC, telefone móvel, palmtop, etc.), tal como por exemplo tecnologias de cliente-servidor baseadas na rede (páginas de HTML, Applet Java, aplicativos de Java independentes) ou tecnologias de agente autônomo. A interface PI é projetada consistentemente com os princípios de utilidade a fim de habilitar o operador/cliente alcançar o objetivo fixado com a melhor efetividade, eficiência e satisfação em todos os contextos específicos de uso. No desenvolvimento da interface PI, muito atenção foi prestada ambos a otimização de código para fazer as interações e atividades, que os Proxys Pessoais PPs têm que executar em cooperação com os Proxys de Recurso RPs, mais efetivas, e aos aspectos de utilidade e de favorecimento de usuário da GUI a fim de melhorar altamente a capacidade do operador/cliente para

efetuar a tarefa nomeada a ele.

No caso de um operador, em um pedido de atividade (intervenção em campo ou Relatório de Dificuldade/Pedido de Cliente), o WFM envia ao Administrador operacional OM o nome do operador escolhido e os detalhes da atividade a ser executada. O Administrador operacional OM remete ditos dados ao Proxy Pessoal PP associada ao operador escolhido, pelo Agente Operacional AO, que coordena dito Proxy Pessoal PP; o Proxy Pessoal PP, por sua vez, notifica na interface PI correspondente que há uma atividade a ser efetuada.

Uma vez que o operador recebeu na sua Interface PI a informação que há uma atividade a ser efetuada, ele procede como segue:

- ele começa, da 'Home Page1 da Interface PI, o procedimento de registro e autenticação; baseado no perfil de operador, seções dedicadas a "funções privilegiadas" podem ou não ser exibidas; os dados de autenticação são verificados contra os armazenados no Inventário de Perícia EI para o operador associado ao dito Proxy Pessoal PP;

- ele exibe os dados na atividade nomeada a ele e executa o procedimento de suposição de dita atividade (por exemplo, intervenção em campo ou Relatório de Problema/Pedido de Cliente); neste momento, o operador pode acessar, pela interface PI, a ambientes gráficos e de navegação como ajuda para operação; as funções providas por estes ambientes estão disponíveis em parte e usadas por todos os tipos de operadores (por exemplo, engenheiros de campo e consultores de Centro de Chamada) e em parte específicas para um certo tipo de operador.

Estas funções habilitam:

- exibição de local do equipamento (por exemplo, dentro de uma estação telefônica) na qual efetuar a intervenção (engenheiros de campo);

- exibição da interface do equipamento e identificação gráfica do componente de hardware (prateleira, placa, porta, dispositivo, etc.) em que é necessário intervir (engenheiros de campo);

- apresentação do fluxo de trabalho (com possível opção anterior de seleção entre fluxos de trabalho diferentes) em um modo interativo, a fim de guiar, passo a passo, a operação do engenheiro (engenheiros de campo);

- apresentação de uma seqüência de perguntas de um modo interativo a fim de adquirir, passo a passo, a informação requerida para detalhar o pedido de um cliente (consultores de Centro de Chamada);

- sugestão de ações que o cliente deveria efetuar a fim de resolver um Relatório de Dificuldade apresentado pelo próprio cliente (consultores de Centro de Chamada);

- apresentação das hipóteses feitas sobre a causa do Relatório de Dificuldade de um cliente (consultores de Centro de Chamada);

- exibição da instalação das conexões entre o Proxy Pessoal PP e Proxy de Recurso RP, e apresentação das "respostas" do Proxy de Recurso RP para as ações de configuração, colocação, medição, prova, etc., efetuadas pelo RP tanto autonomamente ou no pedido do Proxy Pessoal PP (todos os operadores); - acesso remoto, pelo RP5 a uma CLI (Interface de Linha de Comando) no equipamento no qual a intervenção está sendo efetuada (engenheiros de campo);

- exibição da documentação on-line como possível suporte para a atividade (todos os operadores); e

- acesso às funções "tradicionais" de comunicação com outros operadores (os operadores de Equipe Virtual, pessoal de administração, operadores de retaguarda, consultores de Centro de Chamada): chamada de voz, e-mail, conversação, placa branca compartilhada, etc., (todos os operadores).

No caso de um cliente, o próprio cliente, seguindo na iniciação de seu Proxy Pessoal PP, executa o procedimento de registro e autenticação e recebe em eu dispositivo todos os dados (perguntas, fluxos de trabalho de guia, etc.) requeridos para resolver um mau funcionamento detectado por ele.

As funções oferecidas habilitam:

- apresentação do fluxo de trabalho de um modo interativo, a fim de orientar, passo a passo, operacionalidade do cliente;

- apresentação de uma seqüência de perguntas de um modo interativo, a fim de adquirir, passo a passo, a informação requerida para identificar a causa do mau funcionamento detectado pelo cliente;

- apresentação da hipótese sobre a causa raiz de um mau funcionamento;

- exibição da instalação de conexões entre o Proxy Pessoal PP e o Proxy de Recurso RP, e apresentação das "respostas" do Proxy de Recurso RP;

- notificação da necessidade para contatar um operador para resolver o mau funcionamento;

- acesso às funções de comunicação com um operador.

Os componentes suportando operação acima descritos também acham aplicação em contextos de administração baseados em abordagens tecnológicas mais tradicionais (paradigma de cliente-servidor).

Se nós examinamos por exemplo, soluções de administração que adotam uma abordagem hierárquica baseada em tecnologia de cliente- servidor (como, por exemplo, exemplificada por US-A-2004/0196794), as funções para suportar operação (de operadores e clientes) previamente descritas ainda são efetivas e podem ser oferecidas usando uma plataforma que, para a parte operacional, não muda com respeito ao que é apresentado aqui na Figura 2, enquanto, para a parte de administração de rede e serviço, se confia na arquitetura descrita na Figura 2 de US-A-2004/0196794. Em particular, neste caso, se a meta for adotar uma abordagem conservadora que não idealiza modificação do componente de administração (estação de administração de rede de camada inferior) que administra diretamente os dispositivos na rede, o Proxy Pessoal PP se conectaria diretamente com a estação de administração de rede de camada inferior correspondente para efetuar todas as interações da/para a rede (que, na concretização acima descrita, eram executadas pelo Proxy de Recurso RP), usando modalidades de comunicação semelhantes às adotadas entre estações de administração de rede de camada superior e camada inferior. Alternativamente, o Proxy Pessoal PP poderia interagir com a estação de administração de rede de camada superior, que possui a informação topológica sobre a estações de administração rede de camada inferior, assim evitando ter que operar dita informação diretamente. Em qualquer caso, exceto para modificações para o componente de administração, não haveria um fluxo de trabalho cooperativo na estação de administração de rede interessada: isto, porém, de nenhuma maneira arrisca a validade e efetividade da função para suportar operação, na medida em que isto representa só uma possível alternativa à concretização preferida da presente invenção.

Será apreciado que, enquanto o procedimento guiando os engenheiros de campo em efetuar uma dada intervenção, como descrito com relação à Figura 3, se refere à seleção da intervenção a ser efetuada por um engenheiro de campo, as modalidades com as quais dita seleção é feita são várias, e dependem do paradigma operacional adotado e das funções executadas pelo sistema de WFM. Em uma concretização da presente invenção, o engenheiro de campo só se encarrega da intervenção que é apresentada a ele pelo Proxy Pessoal PP na sua Interface PI, e que foi descarregada ao próprio Proxy Pessoal PP pela cadeia de WFM-OM.

Em uma concretização alternativa, o engenheiro de campo seleciona uma atividade das serem efetuadas em um equipamento em um dado local; neste caso, a única indicação recebida pelo engenheiro de campo, pelo Proxy Pessoal PP que, por sua vez, a recebeu da cadeia de WFM-OM, é a relacionada ao local ao qual ele tem que ir (o WFM só administra as rodadas periódicas dos engenheiros de campo entre os vários locais, sem indicar a eles o que eles têm que fazer).

O procedimento previamente descrito com relação à Figura 3 indica que fluxos de trabalho apropriados são propostos ao engenheiro de campo. Isto é feito por interação entre o Proxy Pessoal PP e o Administrador operacional OM. Quando uma intervenção é selecionada por um engenheiro de campo, o Proxy Pessoal PP pede para o Administrador operacional OM a lista de todos os fluxos de trabalho para suportar dita intervenção. O Administrador operacional OM cria dinamicamente esta lista, baseado em informação de fluxo de trabalho disponível no banco de dados ODB, e a envia ao Proxy Pessoal PP que a apresenta ao engenheiro de campo.

Em uma primeira possível concretização da presente invenção, dada uma intervenção específica, todos os engenheiros de campo são então apresentados com os mesmos fluxos de trabalho, independente do seu grau de habilidade particular.

Em uma concretização alternativa, dada uma intervenção específica, os fluxos de trabalho apresentados a um engenheiro de campo dependem do seu próprio grau de habilidade. Se o engenheiro de campo for um perito, ele é apresentado com fluxos de trabalho de nível mais alto; caso contrário, os fluxos de trabalho propostos são mais detalhados ou em qualquer caso permitem acessar documentos e normas técnicas úteis para o engenheiro de campo. No primeiro caso, a seleção pelo Administrador operacional OM dos fluxos de trabalho a serem postos na lista é , portanto, feita considerando só o tipo de intervenção a ser efetuada, enquanto, no segundo caso, também o perfil do engenheiro de campo é levado em conta e em particular o seu grau de habilidade com referência à habilidade requerida para efetuar a intervenção em questão.

Novamente, em uma concretização alternativa da presente invenção, a ativação do fluxo de trabalho no Proxy Pessoal PP não envolve ativação de um fluxo de trabalho cooperativo no Proxy de Recurso RP: o fluxo de trabalho no Proxy Pessoal PP só ativa de um modo interativo fluxos de trabalho específicos no Proxy de Recurso RP a fim de juntar alguns determinados dados/medições, para pedir execução de dadas atividades no equipamento, ou fazer disponível um acesso remoto a possíveis interfaces de linha de comando. Os fluxos de trabalho executam o que é pedido e retornam o resultado ao Proxy Pessoal PP. Neste caso, o Proxy de Recurso RP não sabe o que o operador, guiado pelo Proxy Pessoal PP, está fazendo. Isto requer que, como última etapa, o fluxo de trabalho no Proxy Pessoal PP deveria pedir para o Proxy de Recurso RP verificar o resultado da intervenção efetuada pelo engenheiro de campo, antes de considerar dita intervenção efetuada com êxito.

Como foi visto, o procedimento para suportar um consultor de Centro de Chamada permite ativar, sempre que necessário, um fluxo de trabalho no Proxy Pessoal PP do cliente. Isto requer o Proxy Pessoal PP estar ativa. Ativação do Proxy Pessoal PP pode ocorrer automaticamente, com um pedido para ativação do Proxy Pessoal PP do operador ou senão em modo manual, com ativação do Proxy Pessoal PP pelo cliente. Neste caso anterior, o próprio Proxy Pessoal PP já pode estar no dispositivo de cliente e deve apenas ser ativada, ou senão o cliente pode descarregá-la de um local provido propositalmente. Em uma concretização alternativa, dito procedimento não idealiza ativação de um fluxo de trabalho no Proxy Pessoal PP do cliente: o consultor de Centro de Chamada só interage com o cliente por meio de um paradigma de pergunta-resposta, no máximo lhe pedindo para efetuar algumas ações particulares.

Também o procedimento para suportar o cliente idealiza uma concretização alternativa na qual, uma vez o Proxy Pessoal PP detectou a necessidade para contatar um consultor de Centro de Chamada para resolver o mau funcionamento informado pelo cliente, em vez de sugerir ao cliente para contatar o Centro de Chamada, ativa diretamente uma sessão com o Proxy Pessoal PP de um consultor de Centro de Chamada.

Com respeito à cooperação entre operadores, pode ser notado novamente o que é descrito na seqüência. O procedimento descrito com referência à Figura 7 idealiza preparar uma lista ordenada de nomes de operadores a serem contatados, usada pelo PP para abrir uma sessão entre operadores ou então apresentada ao operador: dita lista é criada de um modo dinâmico. No momento em que o Proxy Pessoal PP deveria abrir um sessão cooperativa, pede para o Administrador operacional OM criar a lista dos operadores a serem contatados, provendo-o com as indicações requeridas (por exemplo, indicação da atividade executada pelo operador e da habilidade requerida para dita atividade); o Administrador operacional OM examina o Inventário de Perícia EI e, baseado na informação obtida, prepara a lista requerida (entrando com operadores da mesma Equipe Virtual ou até mesmo de outras Equipes). A lista é ordenada de acordo com as habilidades dos operadores e, no caso de equipes diferentes, de acordo com as Equipes (primeiro os operadores da mesma Equipe Virtual são entrados, de acordo com o grau decrescente de habilidade, então os operadores de outras Equipes, uma vez mais em grau decrescente de habilidade). Finalmente, o Administrador operacional OM envia a lista criada ao Proxy Pessoal PP.

Em uma concretização alternativa à previamente apresentada, o Proxy Pessoal PP pode abrir sessões entre operador e dois ou mais outros operadores, que podem interagir entre si por várias ferramentas, incluindo ferramentas para suportar trabalho cooperativo.

Também no caso de cooperação entre cliente e operador, as mesmas modalidades são aplicadas de criação dinâmica, pelo Administrador operacional OM, da lista de operadores a serem contatados, usada pelo Proxy Pessoal PP para abrir uma sessão entre cliente e operador, ou senão apresentada ao cliente.

Levando em conta agora a administração dos perfis de operador no Proxy Pessoal PP em uma concretização alternativa à apresentada acima, cada PP mantém, além do perfil do operador ao qual está associado, também os dados de outros perfis de operador (isto é feito por razão de desempenho: deste modo, tempo para acessar dados de outros operadores a serem contatados diminui). Em particular, uma primeira alternativa idealiza que dito dados deveriam se referir a todos os operadores na mesma Equipe Virtual como aquela do operador ao qual o Proxy Pessoal PP está associada. Uma segunda alternativa também é possível, de acordo com a qual os dados sobre os perfis de operador armazenados no Proxy Pessoal PP se referem a um subconjunto dos operadores na Equipe Virtual de interesse e em particular consideram os operadores equipados, a um grau alto, com as macro- habilidades requeridas à Equipe: para cada macro-habilidade, um ou mais perfis são selecionados; estes perfis são os perfis de operadores que são peritos com respeito a uma macro-habilidade específica (isto é, cuja habilidade é a mais alta entre as de uma dada Equipe Virtual). Os modos que ditos dados são descarregados pela primeira vez e são atualizados subseqüentemente não mudam com respeito ao que foi descrito para o perfil do operador associado ao Proxy Pessoal PP; neste caso, porém, nos dados remetidos ao Proxy Pessoal PPj também há a indicação de quais se referem ao perfil do operador associado ao próprio Proxy Pessoal PP.

Administração dos perfis de operador em uma concretização adicional é completamente dinâmica, no senso que o Proxy Pessoal PP não está associado a priori a qualquer operador específico: a associação com um dado operador é feita quando o operador se autentica. Neste caso, seguindo na autenticação pelo operador, o Proxy PP remete ao Administrador operacional OM os dados de autenticação providos pelo operador e lhe pede para descarregar os dados de perfil relativos a dito operador. O Administrador operacional OM5 depois de verificação anterior da perfeição das credenciais providas, descarrega sobre o PP os dados do perfil em questão. Também neste caso, é possível idealizar uma concretização alternativa na qual o Administrador operacional OM envia ao Proxy Pessoal PP não só os dados do perfil do operador ao qual está associado, mas também os dados de outros perfis de operador, com as mesmas opções vistas acima (dados se referindo a todos os operadores da Equipe Virtual do operador, ou a um subconjunto dos operadores da Equipe Virtual).

Com respeito ao procedimento de administração dos fluxos de trabalho para suportar operadores, com respeito ao que foi mencionado previamente, é possível idealizar concretizações alternativas das modalidades a serem adotadas para descarregar os fluxos de trabalho.

Uma primeira concretização idealiza que na iniciação do Proxy Pessoal PP todos os fluxos de trabalho para guiar o operador são descarregados nela.

De acordo com uma segunda concretização, ao invés, na iniciação do Proxy Pessoal PP ou depois de autenticação do operador (de acordo com se o Proxy Pessoal PP está associado a um operador de um modo estático ou dinâmico), todos os fluxos de trabalho para guiar o operador são descarregados nela com a exclusão de possível fluxos de trabalho aplicáveis só a Equipes Virtuais específicas. É possível definir fluxos de trabalho que só se aplicam a Equipes Virtuais específicas, baseado nas características dos equipamentos administrados por estas equipe e/ou baseado nas habilidades particulares dos membros da equipe.

Finalmente, de acordo com uma terceira concretização, na iniciação do Proxy Pessoal PP ou a jusante da autenticação de operador, só os fluxos de trabalho que são consistentes com as habilidades do operador ao qual a PP está associada são descarregados nela.

Na base de possíveis concretizações alternativas adotadas, também as funções da Interface PI podem mudar: em particular, se a única indicação recebida pelo engenheiro de campo na Interface PI for a relativa ao local para o qual ele deve ir, a Interface PI apresentará ao engenheiro de campo o conjunto das intervenções a serem feitas em um dado local (consistentemente com o perfil do engenheiro de campo), e será o próprio engenheiro de campo que selecionará a intervenção a ser efetuada e se encarregar disto.

Conseqüentemente, sem prejuízo para os princípios subjacentes à invenção, os detalhes e as concretizações pode variar, até mesmo apreciavelmente, com respeito ao que foi descrito aqui puramente por meio de exemplo, sem partir da extensão da invenção como definida pelas reivindicações anexas.

Claims (47)

1. Sistema de operação distribuído, caracterizado pelo fato de incluir: - uma pluralidade de dispositivos terminais (TD), cada dispositivo terminal incluindo um agente de proxy (PP), o agente de proxy incluindo uma máquina de processo baseada em fluxo de trabalho ou baseada em regras (PE) para processar fluxos de trabalho ou regras, e uma interface de usuário (PI) para representar pelo menos parte de ditos fluxos de trabalho ou regras; e - pelo menos um recurso administrador remoto (MM) configurado para administrar transmissão de ditos fluxos de trabalho ou regras para ditos dispositivos terminais.

2. Sistema de acordo com reivindicação 1, caracterizado pelo fato de que o dito agente de proxy inclui uma interface de interconexão para trocar informação com um aplicativo de software (RP) de um dispositivo adicional (NA) durante processamento de ditos fluxos de trabalho ou regras.

3. Sistema de acordo com reivindicação 2, caracterizado pelo fato de que o dito aplicativo de software de dito dispositivo adicional inclui uma máquina de processo baseada em fluxo de trabalho ou baseada em regras (PE) e em que dita máquina de processo de dito dispositivo terminal é configurada para interagir com a máquina de processo de dito dispositivo adicional por dita interface de interconexão.

4. Sistema de acordo com reivindicação 1, caracterizado pelo fato de que a dita interface de usuário é uma interface interativa.

5. Sistema de acordo com reivindicação 1, caracterizado pelo fato de incluir agentes operacionais (OA) configurados para coordenar operações de ditos agentes de proxy.

6. Sistema de acordo com reivindicação 5, caracterizado pelo fato de incluir um administrador operacional (OM) tendo funções de administração e controle de ditos agentes operacionais.

7. Sistema de acordo com reivindicação 1, caracterizado pelo fato de incluir uma arquitetura hierárquica incluindo uma camada inferior formada por ditos dispositivos terminais, e uma camada superior incluindo um administrador operacional (OM) tendo funções de administração e controle.

8. Sistema de acordo com reivindicação 7, caracterizado pelo fato de que a dita arquitetura hierárquica inclui uma camada intermediária incluindo agentes operacionais (OA), ditos agentes operacionais sendo configurados para coordenar operações de ditos agentes de proxy.

9. Sistema de acordo com reivindicação 5 ou 8, caracterizado pelo fato de que os ditos agentes operacionais incluem máquinas de processo baseadas em fluxo de trabalho ou baseadas em regras respectivas (PE).

10. Sistema de acordo com reivindicação 6 ou 7, caracterizado pelo fato de que o dito administrador operacional inclui uma máquina de processo baseada em fluxo de trabalho ou baseada em regras (PE).

11. Sistema de acordo com reivindicação 1, caracterizado pelo fato de que os ditos agentes de proxy de ditos dispositivos terminais são configurados para interagir diretamente entre si em uma relação intertrabalho.

12. Sistema de acordo com reivindicação 1, caracterizado pelo fato de incluir um repositório de processos definidos por fluxos de trabalho ou regras (ODB).

13. Sistema de acordo com reivindicação 1, caracterizado pelo fato de incluir um repositório de modelos de dados (ODB).

14. Sistema de acordo com reivindicação 1, caracterizado pelo fato de incluir agentes de controle (CA) para distribuir ditos fluxos de trabalho ou regras para ditos dispositivos terminais.

15. Sistema de acordo com reivindicação 1, caracterizado pelo fato de incluir um banco de dados de desempenho (PDB) para armazenar dados de desempenho relacionados a dito processamento de ditos fluxos de trabalho ou regras.

16.Sistema de acordo com reivindicação 1, caracterizado pelo fato de incluir um registro operacional (OL) para armazenar processos executados por ditos agentes de proxy.

17.Sistema de acordo com quaisquer das reivindicações precedentes, caracterizado pelo fato de que é configurado para administrar intervenções em equipamentos de rede.

18.Sistema de acordo com reivindicação 17, caracterizado pelo fato de que os ditos fluxos de trabalho ou regras são função do estado dos equipamentos de rede na qual ditas intervenções são executadas.

19.Dispositivo terminal, caracterizado pelo fato de compreender um agente de proxy (PP) provido com uma máquina de processo baseada em fluxo de trabalho ou baseada em regras para processar fluxos de trabalho ou regras e uma interface de usuário (PI) para permitir interação com um usuário durante processamento de ditos fluxos de trabalho ou regras.

20.Dispositivo de acordo com reivindicação 19, caracterizado pelo fato de que o agente de proxy é configurado por descarregar fluxos de trabalho ou regras de um recurso administrador remoto (MM).

21. Dispositivo de acordo com reivindicação 19 ou 20, caracterizado pelo fato de que é um dispositivo portátil.

22.Dispositivo de acordo com reivindicação 19, caracterizado pelo fato de que o agente de proxy inclui uma interface de interconexão (IN) para comunicação com um aplicativo de software de um dispositivo adicional a fim de trocar informação com isto.

23.Dispositivo de acordo com reivindicação 22, caracterizado pelo fato de que o dito aplicativo de software de dito dispositivo adicional inclui uma máquina de processo baseada em fluxo de trabalho ou baseada em regras (PE), dita máquina de processo de dito agente de proxy sendo configurada para cooperar com a máquina de processo de dito aplicativo de software.

24. Dispositivo de acordo com reivindicação 22 ou 23, caracterizado pelo fato de que dito aplicativo de software inclui um agente de proxy (RP).

25. Dispositivo de acordo com reivindicação 24, caracterizado pelo fato de que o dito agente de proxy do dispositivo terminal é configurado para ativar automaticamente uma sessão de comunicação com dito agente de proxy de dito dispositivo adicional.

26. Dispositivo de acordo com reivindicação 19, caracterizado pelo fato de que é configurado para descarregar dito agente de proxy de remoto.

27. Dispositivo de acordo com reivindicação 19, caracterizado pelo fato de que a dita interface de usuário administra uma interface gráfica (GUI).

28. Dispositivo de acordo com reivindicação 19, caracterizado pelo fato de que o dito agente de proxy é configurado para registrar informação durante processamento de ditos fluxos de trabalho ou regras.

29. Dispositivo de acordo com reivindicação 19, caracterizado pelo fato de que é configurado para ativação do agente de proxy por um usuário.

30. Método para administrar intervenções em equipamentos de usuário ou rede, caracterizado pelo fato de incluir as etapas de: - prover uma arquitetura distribuída de agentes de proxy de administração de intervenção (PP) para administrar intervenções nos equipamentos de rede, ditos agentes de proxy de administração de intervenção estando associados a dispositivos terminais e incluindo máquinas baseadas em fluxo de trabalho ou regras; e - gerar sinais de instrução para executar uma intervenção em pelo menos um equipamento de usuário ou rede por um de ditos agentes de proxy de administração de intervenção de uma maneira interativa (PTP) com pelo menos um recurso de administração associado com dito equipamento, por meio de que ditos sinais de instrução são uma função do estado de dito equipamento.

31. Método de acordo com reivindicação 30, caracterizado pelo fato de que o dito recurso de administração inclui um agente de proxy de Recurso (RP) associado com dito equipamento e incluindo uma máquina de processo baseada em fluxo de trabalho ou baseada em regras.

32. Método de acordo com reivindicação 30 ou 31, caracterizado pelo fato de que cada um de ditos agentes de proxy de administração de intervenção está associado com um único dispositivo terminal e inclui uma única máquina baseada em fluxo de trabalho ou regras.

33. Método de acordo com reivindicação 30, caracterizado pelo fato de que inclui a etapa de associar com ditos agentes de proxy de administração de intervenção (PP) interfaces pessoais (PI) para representar pelo menos parte de ditas instruções e para interagir com o fluxo de trabalho executado ou regra.

34. Método de acordo com reivindicação 30, caracterizado pelo fato de que inclui a etapa de arranjar dita arquitetura distribuída em camadas hierárquicas incluindo: - uma camada de Agentes Operacionais (OA) coordenando operação de ditos agentes de proxy de administração de intervenção (PP); e - uma camada incluindo um Administrador operacional (OM) tendo funções de administração e controle e supervisionando a operação de ditos Agentes Operacionais (OA).

35. Método de acordo com reivindicação 34, caracterizado pelo fato de que inclui a etapa de dividir a ditos Agentes Operacionais (OA) a execução distribuída de intervenções através de uma pluralidade de ditos agentes de proxy de administração de intervenção (PP)-

36. Método de acordo com reivindicação 30, caracterizado pelo fato de que inclui a etapa de arranjar dita arquitetura distribuída em camadas hierárquicas, em que uma camada inclui um Administrador operacional (OM) tendo funções de administração e controle e coordenando diretamente a operação de ditos agentes de proxy de administração de intervenção (PP).

37. Método de acordo com reivindicação 34 ou 36, caracterizado pelo fato de que inclui a etapa de dividir, para cada um de ditos agentes de proxy de administração de intervenção (PP), a tarefa de suportar um único operador ou cliente, por meio de que execução de ditas intervenções é desacoplada com respeito a ditas funções de administração e controle.

38. Método de acordo com reivindicação 30, caracterizado pelo fato de que inclui a etapa de prover máquinas de processo (PE) a ditos agentes de proxy de administração de intervenção (PP).

39. Método de acordo com reivindicação 34 ou 36, caracterizado pelo fato de que inclui a etapa de prover máquinas de processo (PE) para todas as ditas camadas em dita arquitetura distribuída.

40. Método de acordo com reivindicação 38 ou 39, caracterizado pelo fato de que ditas máquinas de processo (PE) são baseadas em fluxo de trabalho ou baseadas em regras.

41. Método de acordo com reivindicação 34 ou 36, caracterizado pelo fato de que inclui a etapa de incluir em ditas camadas, componentes (PP, OAj OM) adaptados para executar funções respectivas baseadas em informação de instrução respectiva provida a eles.

42. Método de acordo com reivindicação 41, caracterizado pelo fato de que inclui a etapa de prover em dita informação de instrução pelo menos uma de: - uma definição de processo, que inclui pelo menos um de um fluxo de trabalho e uma regra; e - uma definição de modelos de dados.

43. Método de acordo com reivindicação 30, caracterizado pelo fato de que inclui a etapa de configurar ditos agentes de proxy de administração de intervenção (PP) para interagir diretamente entre si em uma relação intertrabalho, por meio de que pelo menos um de ditos sinais de instrução é produzido por interação entre agentes de proxy de administração de intervenção (PP).

44. Método de acordo com reivindicação 30, caracterizado pelo fato de que inclui a etapa de configurar ditos agentes de proxy de administração de intervenção (PP) para interação de ponto a ponto (PTP) com ditos agentes de proxy de Recurso (RP).

45. Método de acordo com reivindicação 34 ou 36, caracterizado pelo fato de que inclui a etapa de prover os agentes de controle (CA) associados a pelo menos uma camada de dita arquitetura distribuída para executar pelo menos uma etapa selecionada do grupo consistindo em: - distribuir definições de processo para ditas camadas de dita arquitetura distribuída; - distribuir definições de modelo de dados para ditas camadas de dita arquitetura distribuída; e - monitorar o estado de ditas camadas de dita arquitetura distribuída.

46. Método de acordo com reivindicação 45, caracterizado pelo fato de que inclui a etapa de prover um módulo administrador (MM) para executar pelo menos uma etapa selecionada do grupo consistindo em: - administrar a distribuição de definições de processo para ditas camadas de dita arquitetura distribuída por ditos agentes de controle (CA); - administrar a distribuição de definições de modelo de dados para ditas camadas de dita arquitetura distribuída por ditos agentes de controle (CA); e - monitorar o estado de ditas camadas de dita arquitetura distribuída por ditos agentes de controle (CA).

47. Produto de programa de computador, caracterizado pelo fato de ser carregável na memória de pelo menos um computador e incluindo porções de código de software para executar o método como definido em quaisquer das reivindicações 30 a 46.