BR112019025269A2 - microprocessador incluindo um modelo corporativo - Google Patents

Abstract

Uma unidade computacional de placa única (100) para executar um código de software modelado em uma forma que incorpore dados e instruções de software em um único modelo, a unidade computacional de placa única caracterizada por: uma unidade de processamento central (101) configurada para processar dados de acordo com um modelo com pelo menos uma camada de abstração (210), o referido modelo incluindo nós (215) associados com o contexto (217), cada nó (215) sendo conectado a pelo menos outro nó em uma mesma camada de abstração, onde os nós representam o status e o estado dos processos; uma memória de núcleo não volátil (102) para armazenar e limitar o acesso à unidade de processamento central (101), o referido núcleo (102) contendo instruções para interpretar pelo menos um modelo de camada de abstração (210) e instruções para sincronizar pelo menos um modelo de camada de abstração (210) com uma versão do modelo armazenado em um dispositivo remoto; uma unidade de criptografia e descriptografia (109) para criptografar e descriptografar dados trocados entre a unidade computacional de placa única (100) e o dispositivo remoto; e uma unidade de controle de energia (116) configurada para informar a unidade de processamento central (101) sobre o status da energia. A presente solução inovadora introduz dois projetos de unidades de hardware/software. O primeiro é um modelo computacional simples com base no entendimento e executando um Modelo de Sobreposição de Domínio, e oferecendo a infraestrutura apropriada na forma de um dispositivo computacional de placa única ou um dispositivo computacional de chip único. O segundo introduz uma grade computacional que é uma grade de unidades individuais projetada para Modelos de Sobreposição de Domínio distribuídos, proporcionando a segurança e o desempenho apropriados. Com o advento da IdC e de ecossistemas na esfera cibernética, o desenvolvimento e implementação independentes são inevitáveis..

Description

MICROPROCESSADOR INCLUINDO UM MODELO CORPORATIVO CAMPO DA INVENÇÃO

[001]. O software é utilizado para gerenciar a interação humana com unidades de processamento computadorizadas.

[002]. O software aparece na interface humana / computador na forma de uma interface do usuário e alto nível de linguagens de programação. O software permite que um computador se comunique com as pessoas utilizando diferentes dispositivos externos como um mouse, teclado ou sistema de reconhecimento por vídeo. Talvez principalmente, o software traduz linguagens de processamento do nível humano para a linguagem da máquina. Por exemplo, o software permite a tradução de uma linguagem no nível do desenvolvedor, como Visual Basic, C#, Python, Java ou SQL, para uma linguagem intermediária e, então, para uma linguagem de máquina. A natureza onipresente dos computadores e seu software tornou as interações com os humanos imensamente variadas. Como resultado, os computadores genéricos comumente utilizados apresentam facilidades de interação humana que excedem muito as facilidades necessárias para um aplicativo de negócio específico.

[003]. As facilidades complexas necessariamente integradas em computadores genéricos para permitir que aqueles computadores interajam com um amplo arranjo de diversas interações de software e humanas combinadas com um grande volume de informações corporativas a serem processadas e uma infinidade de facilidades de software tornam aplicativos específicos, como um todo, intensivos em termos de recursos que reduzem as velocidades de processamento. Por exemplo, a base de dados de Linguagem/Programa, SQL/Sequel, requer um serviço para executar e tratar da recuperação e armazenamento na maioria dos softwares corporativos. Existem diversas subetapas necessária para recuperação. Este programa, e programas equivalentes, requer programação intensiva.

[004]. O software requer atualizações e aprimoramentos frequentes para incorporar melhorias e remover erros de processamento (bugs). O processo de atualização ou, principalmente, o aprimoramento do software é muito intenso em termos de trabalho e de tempo. De forma que o gasto com desenvolvimento de software seja frequentemente considerado como consistindo amplamente de 50% de elicitação das exigências, projeto e implementação e 50% de teste. Existem poucas outras indústrias, se houver, onde o teste é uma parte significativa do desenvolvimento. O processo de atualização é prejudicial para o desenvolvimento e para o uso mais amplo do software e é mais agudo em novos paradigmas de uso de software como na Internet das Coisas (IdC) e resposta a emergência.

[005]. A IdC é um dos desenvolvimentos mais significativos de softwares da atualidade. Ela consiste em componentes de software e hardware que não são necessariamente controlados ou produzidos por um investidor. Por este motivo, a IdC é criticamente dependente da interoperabilidade dos componentes da IdC que são desenvolvidos e produzidos independentemente. Isto significa que os componentes da IdC devem interoperar com outros componentes da IdC durante o uso final, sem terem sido anteriormente previstos como um sistema. É um problema generalizado que os componentes da IdC ocasionalmente carecerão de interoperabilidade como resultado de não serem desenvolvidos em conjunto. A resolução da incompatibilidade dos componentes da IdC é realizada por meio de uma atualização. A atualização através de um modelo é uma parte essencial do desenvolvimento do software revelado aqui.

[006]. Semelhante a uma atualização de software é modificar ou melhorar a funcionalidade do software a tempo para obter um benefício, como durante a resposta a uma emergência. O uso emergente de software e dispositivos portáteis para uso intenso em operações complexas que exigem coordenação, com a resposta a uma emergência, é outra área onde é necessário que a modificação do software seja mais eficiente. A resposta a uma emergência utilizando múltiplos dispositivos computacionais portáteis é intensiva em termos de tempo e diversa em exigências de forma que uma capacidade de modificar o software durante a emergência em andamento pode aumentar grandemente a probabilidade de uma resolução bem-sucedida de uma situação de emergência. Considere quantas exceções para antecipar as exigências podem surgir na implementação de um sistema de resposta a emergência. Diversos casos de uso não previstos podem se tornar aparentes durante o curso de uma emergência real. Por exemplo, uma necessidade de identificar pessoas que são ameaças ocultas, ao invés de uma evacuação ou confinamento, durante um ataque terrorista, pode exigir uma modificação rápida do software durante a emergência. O desenvolvimento de software revelado neste documento proporciona a rastreabilidade exclusiva das mudanças de forma que a divisão do processo de atualização pode ser realizada com base na qual os nós do modelo, incluindo quais usuários, e quais contextos se baseiam na via de propagação das mudanças. A chave para isto é a rastreabilidade com base na modelagem das vias de propagação.

[007]. Uma modelagem semelhante das vias de propagação pode ser utilizada com a parametrização do tempo de execução do software ao invés de uma atualização.

[008]. Uma causa que retarda a atualização de um software é uma falta de rastreabilidade e a capacidade de evolução do software como resultado de uma falta de um modelo rastreável para descrever processos e status de negócios. Além disso, novamente devido à falta de rastreabilidade, a modificação do software para resolver bugs de último minuto do software identificados durante o teste antes que a nova funcionalidade do sistema esteja pronta para ser aplicada, se adiciona significativamente ao tempo e esforço necessários para a atualização. Aplicar instruções atualizadas compiladas em um aplicativo existente utilizando métodos convencionais é grande em volume novamente devido à falta de rastreabilidade, de forma que atualizações parciais não podem ser utilizadas como base para serem livres de defeitos.

[009]. Além disso, o software é exposto a interjeições ilícitas durante o uso comumente referido como ameaças à cibersegurança. O problema da cibersegurança é um resultado do uso de camadas de software comum e convencional para armazenamento e recuperação de dados de forma que agentes ilícitos possam se infiltrar em uma grande maioria de sistemas com os mesmos métodos.

[0010]. Adicionalmente, o desempenho do software convencional que não implementa camadas de software específicas para uso de forma a evitar grandes componentes de software genéricos, afeta significativamente o desempenho e a cibersegurança. O uso de software específico para uso melhora o desempenho e a cibersegurança significativamente. Conforme revelado abaixo, o uso de um ou mais modelos de negócios reduz significativamente a necessidade de software redundante.

[0011]. A Patente dos Estados Unidos No 8,571,910 e a Publicação do Pedido de Patente dos Estados Unidos No 2014/0330616 Al, ambos intitulados, “Sistema e Método para Identificar Informações Relevantes para um Negócio”, e ambos de D. Lyras, revelam um sistema e um método para encontrar e recuperar informações relevantes para uma empresa que sejam relevantes para os problemas da empresa, para as oportunidades e eventos inesperados ou interessantes da empresa.

[0012]. Um componente do sistema e o método revelado na patente US 8,571,910 e na patente US 2014/0330616 Al é uma “Sobreposição”, definida como um auxílio de software para encontrar informações dentro de uma empresa. Um aspecto da Sobreposição é sua função como uma máquina de relevância, ao contrário de uma máquina de busca. A Sobreposição recupera somente informações relevantes para um determinado problema ou oportunidade da empresa. O software de Sobreposição localiza casos semelhantes a problemas e oportunidades atuais localizando etapas de processo semelhantes e proximidade semelhante a um objetivo. Para alcançá-los, a Sobreposição utiliza um modelo corporativo que é exclusivamente rastreável e age como uma combinação de dados e lógica executores que contorna a necessidade de camadas genéricas e volumosas de software.

[0013]. Um glossário de termos associados com a Sobreposição inclui:

[0014]. Contexto Extraído: Um contexto que pode ser extraído no sentido de que ele pode se aplicar a mais de um domínio. O contexto extraído é utilizado para definir diferentes camadas de abstração incorporando um ou mais contextos correspondentes em um nível de abstração inferior. Correspondente significa que mais de um nível inferior de contextos de abstração são conectados a nós associados correspondentes de um nível de abstração maior.

[0015]. Cluster de Nós Extraídos: Um cluster de nós que reflete a semântica e a lógica de causa e efeito de mais de um cluster de nós específicos do domínio.

[0016]. Objeto Extraído: Um objeto que pode ser extraído no sentido de que ele pode se aplicar a mais de um domínio como uma delineação de contexto de um nó.

[0017]. Ator: Um participante humano em um processo do mundo real muito embora os processos do mundo real possam não ser totalmente distintos dos processos emulados pelo sistema.

[0018]. Atributos: Características de conceitos com os nós mencionados nesta revelação, também chamados de status de nós. Cada nó respectivo possui um único valor de atributo em um determinado tempo, muito embora o valor do atributo mudará como resultado da propagação de dados.

[0019]. Entidade de Negócio: Um termo do desenvolvimento de software de computador utilizado para descrever um conceito no mundo real que é emulado no software e tendo mais de um atributo descrevendo suas características. Qualquer coisa física, como um ambiente, lugar, componentes físicos e pessoas, é um contexto e não um atributo ou um nó.

[0020]. Objeto de Negócio: Semelhante a uma entidade, trata-se de um termo utilizado na indústria de software para descrever um conceito no mundo real que é emulado no software.

[0021]. Casos/discussões/descrições/experiências: Estes são casos de experiências que podem descrever toda ou parte da causa, efeito, risco e solução. Eles podem incluir explicações e modelos generalizados para descrever como as coisas se comportam nos processos onde são designados.

[0022]. Causa: Uma ocorrência ou ocorrência potencial considerada por causar um efeito.

[0023]. Circunstância: Uma ampla atividade subjacente, um ambiente complexo, faixa de tempo ou semelhante. Na Sobreposição, a circunstância é semelhante ao estado e parâmetros de estado, mas não é um termo comumente utilizado na engenharia de software. Ela difere do estado pelo fato de que o estado também descreve a instância da situação do nó ou sistema de nós ao passo que a circunstância descreve mais do que uma instância. A circunstância também é utilizada neste texto em seu sentido de idioma inglês geral quando não estiver descrevendo as vias de propagação do nó e conceitos de modelo de Sobreposição semelhantes.

[0024]. Estrutura cognitiva: Uma estrutura que indexa informações de forma que enquadre princípios cognitivos conhecidos.

[0025]. Condição: Um estado de estar (conforme definido no idioma inglês) e sentir o equipamento e ajudar o processo (conforme definido em inteligência artificial (IA)).

[0026]. Contexto: Um ambiente, circunstância ou identificação importante no domínio dentro do qual um processo ocorre. Isto pode ser descrito pelo modelo de domínio de Sobreposição e processado pelo computador definindo nós, ambiente básico ou informações circunstanciais como parte de seu estado. O contexto frequentemente delineia vias de propagação pertencentes a processos semelhantes, mas delineados, por exemplo, um cheque de pagamento está no contexto do tripulante apropriado onde o contexto do pessoal definir a propagação do cheque de pagamento para o tripulante correto. A maioria dos conceitos baseados na não atividade na Sobreposição é descrita como contexto. Os nós da Sobreposição podem não ser nada, mas atividades; portanto, o aspecto de uma atividade que ocorre nas circunstâncias de um conceito de não atividade como um lugar, é descrito na Sobreposição por um contexto que define adicionalmente um nó.

[0027]. Conversão, Conversão Lógica ou Lógica de Conversão: A lógica costumeiramente encontrada em sistemas de software que converte um valor de status em outro. Na Sobreposição, esta é a lógica que existe para propagar valores de um nó para outro e para validar a conversão de valor de um nó para outro.

[0028]. Diagnóstico: Encontrar a causa de problemas e explicar eventos interessantes ou causas de oportunidade.

[0029]. Domínio: Uma indústria, um departamento de uma empresa, um negócio ou parte dele que seja diferente de outras semelhantes por sua variedade específica de atividades, ou qualquer estrutura de negócio onde as etapas do processo e a terminologia sejam específicas e os praticantes as entendam. Modelos de Sobreposição em diferentes domínios raramente afetam uns ao outros. O domínio difere do contexto em que o contexto é mais granular praticamente sem ênfase sobre as atividades e mais ênfase sobre um ambiente inanimado que afeta as atividades.

[0030]. Efeito: Uma ocorrência ou ocorrência potencial que se considera que afeta um processo, um objetivo do plano ou um objetivo condicional.

[0031]. Problemas Endêmicos/Oportunidades/Nós: Problemas, oportunidades ou ocorrências inexplicadas/potenciais/ocasionais, em vários níveis de abstração que são consideradas por profissionais altamente experientes como sendo repetitivas em uma variedade de processos relacionados. Problemas endêmicos/oportunidades estão associados com os objetivos uma vez que os problemas e oportunidades não podem ser definidos sem primeiro definir os objetivos.

[0032]. Empresa: Qualquer organização ou coleção de organizações que realiza atividades para um ou mais propósitos conhecidos; geralmente caracterizada pela previsibilidade dos objetivos a qualquer momento, previsibilidade de planos e processo para atingir estes objetivos, e atores com valores substancialmente conhecidos, habilidades, conhecimento, informação, resistência e emoção com relação aos objetivos.

[0033]. Atividade Empresarial: Atividades reconhecidas pelos profissionais em cada domínio ou em mais de um domínio.

[0034]. Estrutura da Atividade Empresarial: Uma estrutura de critérios de relevância relacionados que são reconhecidos pelos profissionais na maioria dos domínios.

[0035]. Evento/evento inesperado/evento interessante: Um evento é uma ocorrência que para um profissional altamente experimente é considerado razoavelmente importante para a empresa e seus objetivos.

[0036]. Explicações: Explicações de problemas ou oportunidades de eventos inesperados.

[0037]. Processo Externo: Os processos externos ocorrem fora da empresa da qual alguns processos da empresa dependem: por exemplo, projeto, construção, ou educação, e atividades de preparo que podem fazer parte de qualquer etapa do processo; processos que ocorrem no ambiente que não são projetados para atender a objetivos conhecidos, mas que afetam os processos e objetivos da empresa, por exemplo, o comportamento humano discricionário; ou processo não diretamente relacionados ao comportamento humano, como fenômenos ambientais.

[0038]. Objetivos: Os objetivos são nós, mas devido à sua natureza abstrata, eles frequentemente não apresentam subnós diretamente designados a eles. Eles são frequentemente afetados pelos nós de mais de um cluster do processo em um sistema descrevendo na Sobreposição que os objetivos podem ter muitas fontes de contribuição.

[0039]. Objetivos ou Objetivos Condicionais: Os objetivos e objetivos condicionais para os quais um processo da empresa foi desenvolvido.

[0040]. Proximidade do Objetivo: O efeito proporcional de nós subordinados sobre os nós dependentes quando os nós estão conectados por causa e efeito em um cluster de nós. Geralmente, a proximidade do objetivo é a proporção de causa e efeito de processos subordinados ou causais sobre processos dependentes ou afetados.

[0041]. Profissionais Altamente Experientes: Pessoas que têm participado e são responsáveis por um processo para o qual elas são consideradas altamente experientes pela maior parte de suas carreiras e estão cientes do processo particular e de suas principais características, e também estão cientes dos processos dependentes e subordinados ao processo para o qual elas são consideradas altamente experientes.

[0042]. Processo Inanimado: Um processo que não envolve a intervenção humana (como um processo químico) e, portanto, pode não ter objetivos que não sejam os objetivos do processo dentro do qual ele foi desenvolvido para fazer parte por humanos. Por exemplo, a corrosão é um processo inanimado que é previsível e bem conhecido, mas, no entanto, não seria considerado um processo baseado no objetivo.

[0043]. Modelo de Camada de Abstração: A Sobreposição pode ser descrita como modelo de atividades empresariais em um ou mais níveis de abstração. As camadas de abstração podem ser: A) clusters de nós com muitos nós semanticamente idênticos delineados por vias de propagação paralelas em diferentes contextos que não convergem entre as camadas em diferentes contextos e podem convergir entre camadas em diferentes contextos no mesmo nó que é a jusante na propagação; B) As camadas de abstração também podem ser semanticamente semelhantes, mas, não nós geralmente idênticos em clusters em propagação paralela que não convergem e onde nós em diferentes níveis de abstração correspondem uns aos outros por semelhança de semântica e lógica; e combinações de (A) e (B).

[0044]. Modelo de Lógica ou Abstração Lógica: Um incremento de lógica reutilizável colocada entre os nós no modelo de Sobreposição. A ênfase sobre a abstração de lógica mais a abstração de semântica do nó auxilia consideravelmente no desenvolvimento de modelos de Sobreposição que podem ser comparados quanto à semelhança que possui muitos benefícios.

[0045]. Micronúcleo: Uma quantidade de software próxima do mínimo que pode oferecer os mecanismos necessários para implementar um sistema operacional. Estes mecanismos geralmente incluem espaço de endereço de baixo nível, gestão de segmentos e comunicação interprocesso (CIP). Uma aplicação exemplar de um micronúcleo é revelada na Patente dos Estados Unidos No 9,282,079, “Servidor de Gateway de Micronúcleo” por Meier et al. A patente 9,282,079 revela um servidor de gateway que apresenta um primeiro subitem que recebe dados de uma rede insegura, como a Internet, e um segundo subsistema que transmite os dados para uma rede segura. Um controlador de CIP e um micronúcleo estão dispostos entre o primeiro e o segundo subsistemas. Todas as comunicações passam através de uma memória controlada pela combinação de controlador de CIP / micronúcleo. O código dentro do micronúcleo determina quais dados são seguros para passar pelo segundo subsistema. O uso de um micronúcleo é significativo para a operação de IdC, sistemas de resposta à emergência, sistemas compactos de alto desempenho, IdC, e muitos outros usos importantes.

[0046]. Valor de Status do Nó: O valor associado com um nó que muda na medida em que o sistema recebe dados frescos. O valor de status do nó muda frequentemente e está associado com a mudança de dados em um sistema. O registro da hora acompanha o valor de status do nó, mas é considerado um parâmetro de estado em engenharia de software. Muitos parâmetros de estado acompanham o valor de status do nó de cada nó, do qual o contexto é o mais importante para propósitos de modelagem.

[0047]. Processos Animados Não Baseados no Objetivo: Processos que as pessoas experimentam, mas que não são claramente baseados no objetivo, como apreciar um determinado tipo de música ou ligação com uma determinada cor. Uma palavra comum para isto é discricionário.

[0048]. Memória não volátil: Memória do computador que pode ser sustentada sem energia.

[0049]. Objeto: Um objeto no domínio que é uma parte importante de um processo que delineia um ambiente no qual o processo ocorre e é representado como um contexto identificando adicionalmente um nó, na Sobreposição. Isto pode ser descrito pelo modelo de domínio da Sobreposição e processado pelo computador pelos nós correspondentes com informações sobre seu estado. Um objeto pode ser ferramentas de diferentes tipos com diferentes tipos de materiais envolvidos em um processo que pode afetar a via de propagação do processo.

[0050]. Oportunidades/Sucessos: Na presente revelação, oportunidades e sucessos são considerados nós dentro de processos ou podem ser nós que representam objetivos onde profissionais altamente experientes esperam razoavelmente oportunidades e/ou sucessos.

[0051]. Organizar: Ser uma abstração de, para generalizar, para um grupo ou modelo.

[0052]. Ossificado: Uma propriedade de uma entidade dentro do modelo de atividade da empresa que varia, mas é considerada constante, porque os profissionais esperam que a propriedade seja bastante constante e previsível.

[0053]. Modelo de Sobreposição: um ou mais clusters de nós que explicam as relações entre os elementos em um sistema e são capazes de ilustrar o estado do valor de status ou propagação da circunstância graficamente ou em uma representação rastreável. Uma representação gráfica ou representação fácil de rastrear dos trabalhos de um sistema onde os componentes destes nós da revelação estão relacionados uns com os outros e todos os outros elementos relacionados aos nós estão relacionados uns com os outros através dos nós.

[0054]. Plano: Um processo menos bem definido onde as etapas dos processos são ordenadas de forma a se encaixar nas circunstâncias atuais. A hierarquia de planos do objetivo é frequentemente diferente dos processos subjacentes que eles incorporam.

[0055]. Profissionais: Pessoas com experiência média no empreendimento.

[0056]. Padrão Previsível: Cluster de nós de software ou hardware ou módulo de software que utiliza dados e lógica para identificar padrões em nós não Sobreposição e principalmente dados externos e os introduz na Sobreposição, como no texto em repositórios externos e dados em modelos de dados externos. É utilizado pelo modelo de Sobreposição para trocar dados e texto com sistemas externos. Pode conter lógica de Inteligência Empresarial (IE), reconhecimento de padrão ou lógica semelhante.

[0057]. Os principais meios para compreender mais sobre o problema ou oportunidade. Os métodos pelos quais a relevância mais apropriada sobre um problema ou oportunidade é determinada.

[0058]. Problemas/Falhas: Problemas e falhas são nós dentro de processos ou podem ser nós que representam objetivos onde profissionais altamente experientes razoavelmente esperam problemas e/ou falhas ou fenômenos inexplicados ou fenômenos de causa e efeito inexplicados. Problemas e falhas, oportunidades e sucessos, pontos de tensão, objetivos são todos nós considerados.

[0059]. Processo: Um conjunto de atividades que atendem um conjunto de objetivos e objetivos condicionais. Estes podem variar de processos ossificados, para processos estabelecidos, a processos recém-estabelecidos, a planos que são processos ainda a serem colocados em prática.

[0060]. Nós do Processo: Partes de processos onde profissionais altamente experientes esperam resultados notáveis e informações como problemas e oportunidades.

[0061]. Poder de Processamento: O poder de processamento de um componente de hardware de um processador em termos da velocidade na qual o processador pode processar unidades do trabalho de processamento.

[0062]. Propagação: A mudança nos valores do nó que se desenvolve ao longo de uma série de nós conectados por terem valores de nó conectados por lógica que é configurada para transferir novos valores ao longo da via de propagação e execução. O contexto diferente para um mesmo nó delineia diferentes vias de propagação.

[0063]. Critérios de Relevância: Maneiras de expressar relevância que ajuda a construir o modelo ou a estrutura da atividade corporativa. Os critérios de relevância são determinados principalmente pelo nó e seu estado incluindo o contexto e os links lógicos entre os nós mais as ligações de semelhança entre os nós em diferentes camadas de abstração. Os critérios de relevância também podem incluir aspectos da estrutura cognitiva que é designada para os nós como funções, usuários, fluxos de trabalho, atores ou outros conceitos que ajudam os profissionais a determinar a relevância. Os critérios de relevância também podem ser apresentados por clusters de nós configurados de maneira específica.

[0064]. Risco: Um efeito potencial. Ele pode ser positivo quando corresponde a uma oportunidade ou negativo quando corresponde a um problema.

[0065]. Função: Investidor do processo que está sendo emulado no sistema. Isto geralmente significa que a função é um investidor da emulação computadorizada do processo e não é necessariamente um ator no processo do mundo real correspondente. As funções estão relacionadas a quais emulações do processo um usuário do sistema é capaz de ver e está autorizado a acessar.

[0066]. Causa Raiz: Uma ocorrência ou ocorrência potencial considerada como sendo o motivo pelo qual uma causa ocorreu.

[0067]. Roteiro: Um processo que é realizado conscientemente ou subconscientemente porque foi ossificado.

[0068]. Modelo de Estado: Um modelo de dados coletados em um sistema.

[0069]. Parâmetros de Estado: Circunstâncias que envolvem um nó, incluindo o contexto e o tempo de mudança do novo valor do status. Parâmetros de estado que acompanham nós e cada nó tem seus próprios parâmetros de estado. O principal parâmetro de estado é o contexto, mas podem existir outros parâmetros de estado. Em termos de engenharia de software, os parâmetros são qualquer coisa que define como a mudança em um sistema ou seus compostos é definida dentro do sistema. Exemplos de parâmetros de Estado e status de um nó seriam: Nó; “transferir pagamento mensal para tripulante” Contexto “tripulante”, ator Contexto; “MoneyGram“, status; data de pagamento “12-5-2017”, Registro de data/Hora do Status “12-5-2017”,

Função 1) oficial de folha de pagamento, Função 2); Tripulante.

[0070]. Em um exemplo semelhante; Nó; “transferir pagamento mensal para tripulante” Contexto “todos os tripulantes”, status do nó; “Em risco de não ser pago no prazo”, Registro de data/Hora do Status “1-1 2018”, função 1): Oficial de folha de pagamento, função 2); gerente de frota.

[0071]. Pode haver muitos contextos por nó e este é o principal parâmetro de estado, mas não o único parâmetro que define as circunstâncias. O status é acompanhado por um registro de data/hora. Todas as representações circunstanciais além do valor de status do nó atual podem ser consideradas um estado. O valor do status também pode representar o estado em circunstâncias específicas.

[0072]. Nós Sobrepostos e Nós Subjacentes Correspondentes: Nós sobrepostos são um tipo de nó que é acompanhado por um nó subjacente. Nós sobrepostos são nós que ocorrem nas circunstâncias de outros nós (nós subjacentes). Tanto os nós sobrepostos quanto os subjacentes são atividades e não ambientes. A diferença entre estes nós e outros nós de atividade que são específicos do contexto, é que o nó subjacente é uma atividade e tem mais de uma via de propagação para outros nós que na maioria das vezes não estão no mesmo cluster de nós que o nó sobreposto. No caso de um contexto de um nó não sobreposto, o contexto propriamente dito não é uma atividade e é uma delineação de um nó que é específico para um ambiente. As delineações de contexto dos nós também não se ligam logicamente a outras delineações de contexto de outros nós a menos que os nós para os quais elas são designadas estejam logicamente ligados.

[0073]. Um exemplo de um nó sobreposto é a disputa legal sobreposta a um nó subjacente que pode ser um processo do negócio sobre o qual a disputa legal pertence. Do mesmo modo um processo de precificação ou pagamento pode ser sobre um processo de negócio subjacente como um reparo. A propagação do processo sobreposto não está diretamente relacionada à propagação do processo subjacente, mas é delineada pelo processo subjacente e segue uma via de propagação diferente daquela do mesmo processo sobreposto com outros nós subjacentes. Por exemplo, o mesmo processo sobreposto de precificação ou pagamento que pode ser sobre um processo de transporte e não um processo de reparo e seguiria um processo de propagação diferente para propósitos de precificação ou pagamento para transporte do que para o processo de reparo.

[0074]. Rastreabilidade: A capacidade de visualizar os valores em transformação de nós ao longo das vias de execução da lógica entre os nós de uma série.

[0075]. Atualização: Uma capacidade de mudar e implementar mudanças de nós e/ou suas posições em clusters de nós e links com outros nós e/ou mudança da lógica que conecta nós e/ou mudança do estado dos nós mudando, dessa forma, o comportamento legível por máquina do sistema. A atualização de software convencional normalmente envolve a mudança de relações da entidade e/ou a mudança de atributos de entidades e/ou a mudança da lógica de conversão.

[0076]. Memória volátil: Memória do computador que precisa de energia para ser sustentada.

DESCRIÇÃO RESUMIDA DA INVENÇÃO

[0077]. Revela-se aqui um sistema e método para incorporar dados e códigos de pelo menos um modelo de camada de abstração, em um chip semicondutor (microprocessador). Incorporar o código no chip melhora o desempenho significativamente, talvez 1000 vezes, em comparação com quando o software de armazenamento utiliza uma linguagem genérica de armazenamento e recuperação, como SQL, e quando há um código de processamento do domínio separado em um servidor separado. Incorporar o código no chip melhora tanto o desempenho quanto a segurança em relação ao processamento distribuído do servidor convencional.

[0078]. As vantagens de pelo menos um modelo de camada de abstração, incorporado no chip inclui um tempo muito reduzido para preparar a lógica do novo software e novos dados em comparação com entradas de múltiplos atributos convencionais e código separado.

DESCRIÇÃO DAS FIGURAS

[0079]. A Figura 1 ilustra a operação do código de software convencional conforme conhecido a partir da técnica anterior.

[0080]. A Figura 2 ilustra a operação do código do software utilizando pelo menos um modelo de camada de abstração.

[0081]. A Figura 3a ilustra o uso de camadas de abstração para determinar a similaridade dos nós em uma primeira configuração de pelo menos um modelo de camada de abstração.

[0082]. A Figura 3b ilustra uma extensão de pelo menos um modelo de camada de abstração da Figura 3a para aplicativos externos.

[0083]. A Figura 3c ilustra uma operação de translação de dados.

[0084]. A Figura 4 ilustra graficamente uma ligação de causa e efeito entre os nós corporativos de uma empresa conforme modelados na Sobreposição.

[0085]. A Figura 5 ilustra graficamente diferentes comprimentos de vias de causa e efeito que levam ao mesmo objetivo.

[0086]. A Figura 6 representa graficamente um diagrama de estado que ilustra nós corporativos em um de dois estados de status possíveis a) status em risco ou b) status fora de risco.

[0087]. A Figura 7 é um diagrama de blocos exemplar de uma unidade computacional de modelo de sobreposição de domínio.

[0088]. A Figura 8 é um diagrama de blocos de uma grade de uma unidade computacional de modelo de domínio.

[0089]. A Figura 9 é um diagrama de blocos ilustrando o sistema incluindo uma unidade de processamento central e uma pluralidade de unidades parciais dependentes, cada uma com uma função ou investidor designado.

[0090]. A Figura 10 é um diagrama de blocos que ilustra como um modelo de domínio pode ser transferido de uma unidade parcial para outra unidade parcial.

[0091]. A Figura 11 é um diagrama de blocos que ilustra a acomodação do sistema para uma ocorrência inesperada de introdução ou remoção de novos nós durante o tempo de execução.

DESCRIÇÃO DETALHADA DA INVENÇÃO

[0092]. Na medida em que os sistemas corporativos utilizados em pequenos dispositivos computacionais portáteis, como smartphones e tablets, evoluem, haverá uma necessidade de trabalhar off-line e, às vezes, em condições árduas onde a comunicação com uma unidade computacional de coordenação central não é contínua. Isto requer que os pequenos dispositivos computacionais portáteis operem com capacidade de software considerável em um estado off-line. Isto, por sua vez requer que estes dispositivos computacionais tenham um aplicativo de software corporativo dividido para atender aos usuários e dispositivos. Isto, por sua vez, requer a divisão do modelo de dados porque os pequenos dispositivos computacionais não serão capazes de armazenar ou processar uma cópia do modelo de dados corporativo completo. A divisão de um sistema corporativo para atender às circunstâncias atuais em transformação requer um modelo corporativo exclusivo que possa ser dividido em uma grande variedade de maneira que podem não ter sido previstas na época do projeto.

[0093]. Revela-se aqui o seguinte: (1): Métodos para tornar os processadores e o armazenamento mais específicos do aplicativo empresarial aumentando a eficiência de processamento e reduzindo a vulnerabilidade aos ciberataques; (2): Resolver a incompatibilidade do software entre os componentes da IdC e o software componentizado possibilitando a rastreabilidade da lógica dentro e entre os sistemas de diferente origem de projeto e pela abstração da semântica e lógica entre sistemas díspares que precisam expor seus trabalhos lógicos para propósito de interoperabilidade, propósitos de conformidade, propósitos de coordenação, etc. Isto ajuda a controlar o vasto problema potencial de compatibilidade de software quando os sistemas não têm um investidor abrangente; e (3): Rápida modificação do software para se adaptar a mudanças imprevistas de uma situação de emergência em andamento. Esta é uma solução para a incompatibilidade da IdC ou de outros componentes de software desenvolvidos independentemente e resolve o problema do software que precisa de modificação enquanto está em uso. Também oferece redundância em circunstâncias onde o hardware utilizado em emergências está sujeito a atrito. “Rápido” é convencionalmente referido como sendo um período de tempo para que o sistema seja restabelecido ou atualizado durante uma emergência.

[0094]. Um modelo de dados corporativos é dividido em um estágio tardio de projeto e implementação. Os componentes do modelo de dados são aplicados a diferentes unidades de processamento autônomo e armazenamento. Esta divisão do modelo de dados permite que estas unidades de processamento autônomo e armazenamento trabalhem independentemente quando estiverem off-line, bem como em colaboração com um modelo corporativo autônomo quando estiverem on-line. A capacidade de dividir o modelo de dados para atender á situação, por sua vez, oferece o benefício de permitir ocasionalmente que sistemas off-line sejam adaptados às funções e às situações previstas.

[0095]. O advento de métodos eficientes em termos de custo para a fabricação de placas de computador utilizando uma unidade de processamento central (CPU), memória, dispositivos dedicados (como WiFi, sensores de proximidade,

acelerômetros etc.) cria novas oportunidades para o desenvolvimento de combinações de hardware / software compactas de alto desempenho e seguras. O desenvolvimento de tal unidade computacional requer um processo de desenvolvimento de novo software.

[0096]. A Sobreposição oferece vantagens exclusivas para a independência de unidades de processamento, a interoperabilidade de unidades de processamento independentes e a atualização de software no advento de IdC e Ecossistemas na esfera cibernética, a recuperação de sistemas corporativos quando uma ou mais unidades de processamento tiverem sido consideradas inoperantes e a reorganização de instalações computacionais quando os investidores mudam. A este respeito, um modelo baseado na Sobreposição pode ser utilizado para denotar as dependências, exigências ou limitações entre diferentes configurações de dispositivos de IdC. Qualquer violação destas dependências, exigências ou limitações constituiria uma ameaça ou uma quebra da interoperabilidade. Por exemplo, o modelo de Sobreposição pode denotar que o dispositivo de IdC A requer entrada ASCII e é dependente da entrada de dispositivos de IdC B e C. Aqui uma violação observada no tempo de execução entre formatos de dados de saída/entrada do dispositivo de IdC B ou C para o dispositivo de IdC A constituiria violações de interoperabilidade. Isto se torna possível porque a modelagem da Sobreposição permite a separação de questões por meio de uma coleção de clusters de nós e seus respectivos estados conectados pela lógica. Neste exemplo, este cluster de nós estaria denotando o que cada dispositivo de IdC faz ou requer para si como uma unidade independente.

[0097]. A fim de entender a operação e os benefícios do modelo de Sobreposição proposto, nós consideramos brevemente a operação de um código de software convencional. A Figura 1 ilustra a operação do código de software convencional conforme conhecido a partir da técnica anterior. Uma parte do código de software 42, escrita em qualquer linguagem de software, tipicamente armazena, modifica e recupera dados utilizando tabelas 44 em um Sistema de Gestão de Base de Dados Relacional (RDBMS) como SQL. Em configurações exemplares alternativas, outros sistemas de gestão de base de dados (por exemplo, noSQL) e outras estruturas de dados podem ser utilizadas para tratamento de dados. As tabelas 44 podem conter dados relativos, por exemplo, a pessoas (tblPersonsToBuilding), funções (tblRoles), eventos (tblEvents), etc. Cada tabela possui um valor de identidade associado como

PersonID, RoleId no exemplo acima. O valor da identidade atua como uma “chave” para identificar e combinar dados entre as tabelas e permitir, por exemplo, localizar informações, ações e eventos relacionados a uma determinada pessoa. Para alcançar esta funcionalidade, a mesma chave pode ser utilizada em mais de uma tabela da base de dados.

[0098]. O código de software 42 pode, assim, utilizar consultas do SQL para recuperar os registros de dados do RDBMS 44. Estes dados também são mantidos em uma ou mais tabelas 46 de resultados de consultas e são, então, manipuladas por algoritmos que implementam a lógica do negócio (isto é, o código do software) dependendo do processo desejado (isto é, ação do usuário).

[0099]. A abordagem acima é rotineiramente utilizada em software moderno para alcançar as seguintes tarefas: - Recuperar as informações necessárias; - Ler dados sobre as informações recuperadas; - Designar dados para variáveis algorítmicas; - Executar a parte de validação do código correspondente para o caso de interesse de uso particular; e - Consultar um procedimento armazenado reutilizável (isto é, o código do software) para executar um evento 48 (isto é, uma Ação do Usuário, por exemplo, “Trancar a Porta”) associado com um resultado 50 (isto é, Status do Evento, por exemplo, “Status da Porta”).

[00100]. Um problema com a estrutura e operação do software da técnica anterior (isto é, um código de software não modelado) é que tal código não consegue identificar o contexto de atributos uma vez que é impossível conectar o texto aos pontos de dados selecionados. Isto é mais bem compreendido ao considerar uma parte de uma tabela de eventos exemplar 52 que armazena um evento utilizando seu ”Id” 54 e seu estado “Status” 56. Nenhuma outra informação que pode ser utilizada para identificar o contexto do evento ou seus atributos é armazenada ou associada com o evento.

[00101]. Este modelo de codificação da técnica anterior pode unir dois atributos em um estágio de propagação, mas não consegue conectar mais de um estágio de propagação porque o código é estruturado em pelo menos duas partes, uma parte de recuperação de dados e uma parte de propagação. Nenhuma parte contém metadados que possam permitir a distinção do estado de um evento (ou nó) e, assim, a relevância do nó e a associação com outros eventos (ou nós). Além disso, e mais importante, nenhum modelo de dados nem o mecanismo de recuperação de dados oferece informações suficientes sobre o estado de cada evento (ou nó) para permitir que as vias de propagação sejam reconhecidas pelo sistema na forma de um modelo de causa e efeito.

[00102]. Esta característica dos métodos de codificação do software predominante, como aquele ilustrado na Figura 1, limita a funcionalidade do código em cenários modernos de uso empresarial e crítico onde a versatilidade é necessária a fim de suprir as situações em constante mutação, arquitetura do sistema, parâmetros, etc. Estes ambientes e condição variáveis requerem o uso de um software que possa ser ajustado, reconfigurado e atualizado a tempo para obter o benefício enquanto ainda está em execução em sistemas complexos que também estão em reconfiguração contínua (isto é, enquanto estiver em operação).

[00103]. Para superar as limitações do modelo de software da Figura 1, o presente modelo de Sobreposição é apresentado. A Figura 2 ilustra a operação do código de software utilizando o modelo de Sobreposição 60. O modelo de Sobreposição 60 utiliza a noção de nós 62 que representam problemas/falhas e oportunidades/sucessos dentro dos processos em um ambiente corporativo (ou outro). Os nós são conectados uns aos outros em um cluster de nós 64. Cada nó 62 recupera seu valor de um arquivo e não requer uma consulta de recuperação em um sistema de base de dados, cuja consulta precisaria ser executada no tempo de execução.

[00104]. Na Sobreposição, todas as informações fazem parte do modelo, portanto cada nó recupera sua própria informação através dos valores de status. Diferente da técnica anterior, não há necessidade de executar consultas em um modelo de dados externo, portanto a lógica codificada legível por computador incorporada no modelo de Sobreposição carece de qualquer aspecto de recuperação em um modelo de dados externo e evita a descontinuidade na lógica legível por computador para acomodar a recuperação. A técnica anterior não pode ser um modelo porque o processo de recuperação e a lógica são adjacentes à lógica de conversão e, assim, é muito difícil rastrear uma conversão e seus dados até diretamente após a conversão e seus dados. Isto é, o código não pode ser um modelo contínuo porque é interrompido pelas consultas de recuperação que, por sua vez, não são representações precisas do status e do estado dos nós que estão sendo processados pelo código e, portanto, não podem ligar um estágio de propagação ao próximo para formar um modelo.

[00105]. A fim de garantir a unificação e a integridade dos dados, a Sobreposição utiliza a locação dos nós e seu estado, e a lógica entre os nós para definir inequivocamente a relevância entre os nós.

[00106]. A localização dos nós adjacentes à lógica legível por computador e conectados a outros nós assim como nas Figuras 3a, 3b e 3c permite um modelo corporativo expresso utilizando nós de Sobreposição e que seus critérios sejam utilizados para comparação com outros modelos de dados como modelos de dados de entidade-relacionamento e modelos semelhantes e para verificar a semântica e a relevância de dados em tais modelos comparando nós idênticos na sobreposição com os nós do modelo de relação com a entidade. Isto, por sua vez, pode ajudar a destacar informações duplicadas nestes modelos de dados de entidade-relacionamento e ajudam a descrever o fluxo das conversões lógicas na lógica codificada. Existem diversos benefícios para esta expressão de modos de dados convencionais e código em termos de Sobreposição, alguns dos quais são discutidos em outro local deste documento.

[00107]. A localização do valor armazenado no mecanismo de armazenamento ou cache é determinada exclusivamente pelo modelo de sobreposição através do nó e dos links que indicam a relevância de um nó e seu estado (contexto) para outro nó e seu contexto.

[00108]. Em uma configuração, cada nó obtém seu valor para passar para o mecanismo de tempo de execução de um mecanismo de armazenamento não volátil ou de um cache de memória volátil. Em um aspecto, estes links e estados podem ser armazenados em um arquivo contendo todos os nós do modelo de Sobreposição. Em outro aspecto, existe um arquivo de armazenamento para pelo menos um nó, onde cada um destes arquivos está conectado por uma via do nó correspondente. Portanto, o sistema e seus usuários podem selecionar nós para processamento no tempo de execução, por exemplo, através da ID do nó que pode recuperar valores diretamente e inequivocamente.

[00109]. O uso dos nós 62 e dos clusters de nós 64 é suficiente para o modelo de Sobreposição 60 para descrever qualquer ambiente corporativo (ou outro). Cada link de nó 66 contém o código do software que muda o valor do nó afetado (isto é, o nó-alvo) sem a necessidade de incluir qualquer lógica de recuperação de local (isto é,

evitando o acesso às tabelas da base de dados) agilizando, dessa forma, a operação e facilitando a reorganização do modelo. Os links de nós apresentam uma direção específica de propagação de dados/estado como a ligação do nó 66.

[00110]. O modelo de Sobreposição 60 descreve o estado de um evento utilizando o contexto relacionado ao evento como uma parte maior. Por meio de exemplo, podemos considerar qual “construção”, qual “função", qual “pessoa”, etc., acompanham cada nó 62. Além disso, cada nó 62 possui um valor de status. Como resultado, o status do nó e o estado do nó são visíveis no modelo de Sobreposição 60 e acompanhados pelo código adjacente nos links 66 entre os nós 62. Esta característica do modelo de Sobreposição 60 permite a rastreabilidade dos nós 62, dos estados do nó, e das relações de causa e efeitos subjacentes entre os nós e, portanto, da relevância dos nós com relação um ao outro. Esta característica, por sua vez, permite a acomodação de reorganizações, adições e exclusões de nós, que refletem mudanças na vida real, como mudanças relacionadas ao negócio sem perder a rastreabilidade humana ou da máquina com relação às mudanças.

[00111]. A Sobreposição e sua relação com as linguagens de programação em geral; O modelo de Sobreposição representa valores de status para cada nó, estado para cada nó por meio de contexto para delinear as vias de propagação com base no contexto, e lógica para converter um valor de status de nó em um valor de status de nó afetado. O nó afetado sendo compatível no contexto e outros parâmetros de estado. Como cada nó na Sobreposição apresenta parâmetros de estado descritos dentro do modelo e cada nó possui parâmetros de estado, os valores de status e a lógica de conversão são os componentes restantes que precisam ser convertidos em uma linguagem compreensível pelo sistema operacional. O aspecto do estado é tratado pelo modelo propriamente dito e não precisa ser convertido em uma linguagem compreensível pelo sistema operacional.

[00112]. Portanto, por exemplo, ao executar em um ambiente Linux ou semelhante, os valores de status e lógica apresentados na Sobreposição são convertidos para o Linux ou código semelhante. O mesmo pode acontecer com outras linguagens e ambientes de programação, como o Microsoft.net, ou qualquer outra linguagem de programação de nível superior ou inferior.

[00113]. Em outros exemplos, a Sobreposição não é utilizada para processar, mas somente para converter de um modelo para qualquer linguagem de programação. Isto pode ser útil, por exemplo, para converter um modelo de Sobreposição que tenha muitos recursos de rastreabilidade e abstração descritos em outras partes desta revelação, em um sistema ou ambiente que não consiga processar o modelo de sobreposição propriamente dito, mas que consiga processar somente o código específico. Os contratos inteligentes, por exemplo, são uma forma de desenvolvimento de software que frequentemente dita a linguagem na qual o software é executado. Por exemplo, a Solidity é uma linguagem utilizada no ambiente do contrato inteligente Etherium que, por sua vez, está associada com o Blockchain. Portanto, em uma configuração, o método de modelagem de Sobreposição pode ser utilizado para construir software para diversos ambientes, por exemplo, para dispositivos de IdC onde a sobreposição entrega rastreabilidade e muitas vantagens relacionadas enquanto que as transações de contrato inteligente associadas relacionadas aos dispositivos de IdC podem ser executadas no Etherium, convertendo o modelo de Sobreposição em código Solidity.

[00114]. Neste caso, informações como parâmetros de estado, parâmetros de instanciação e o modelo de dados também precisam ser passadas para o sistema operacional subjacente porque o modelo de Sobreposição não é utilizado para processar o modelo de Sobreposição, mas todo o modelo é convertido para uma linguagem apropriada como a Solidity. O processo de conversão é o processo de engenharia baseada no modelo e a Sobreposição pode ser utilizada para modelar e converter para uma das linguagens de software mencionadas acima para processamento. Isto permite a modelagem de software na Sobreposição que é, então, convertida em uma linguagem como Solidity de forma que os modelos de Sobreposição podem ser convertidos em domínio ou outros ambientes de linguagem específicos de desenvolvimento.

[00115]. Em outro exemplo, o desenvolvimento da lógica na Sobreposição são modelos e abstrações da lógica. A lógica da Sobreposição pode ser desenvolvida em modelos de lógica abstraída. Os modelos ajudam os desenvolvedores de Sobreposição a desenvolverem muito mais rápido e com menos esforço e erros. Eles também ajudam na abstração de camadas da Sobreposição permitindo a comparação de lógica entre os nós em diferentes camadas de abstração comprando os modelos. A combinação de abstração de nós e modelos de lógica, por sua vez, ajuda de muitas maneiras mencionadas em algum lugar desta especificação, principalmente em desenhar semelhanças através de camadas abstraídas e no monitoramento de sistemas díspares e sua funcionalidade quanto à conformidade com as necessidades e com os regulamentos. Um aspecto especial de lógica modelada é a proximidade do objetivo, mas tem havido muita lógica modelada utilizada regularmente no desenvolvimento de software muito embora isto tenha incluído consultas ao modelo de dados da relação e outros aspectos de codificação convencional não utilizados na Sobreposição para evitar rastreabilidade opaca.

[00116]. O modelo de Sobreposição pode ser utilizado como um modelo conceitual e também para executar dados em tempo real. A capacidade do modelo de Sobreposição de executar dados em tempo real foi descrita aqui. A importância de modelos conceituais capaz de executar dados em tempo real também é descrita aqui. Um trabalho publicado, Implementando o Modelo Conceitual Executável (ECM), do Dr. Reinhold Thurner, Rebweg 21, CH8700 Küsnacht, Suíça, explica as mudanças e descreve um método alternativo.

ABSTRAÇÃO NO MODELO DE SOBREPOSIÇÃO

[00117]. A Sobreposição pode ser descrita como um modelo de atividades empresariais em um ou mais níveis de abstração. As camadas de abstração podem ser: A) clusters de nós com muitos nós semanticamente idênticos delineados por vias de propagação paralelas em diferentes contextos que não convergem entre a propagação paralela delineada pelo contexto dentro daquele cluster e podem convergir em algum nó que seja a jusante na propagação; B) As camadas de abstração também podem ser nós semanticamente semelhantes nos clusters em propagação paralela que não convergem entre as camadas e onde os nós em diferentes níveis de abstração correspondem uns aos outros por semelhança. Também pode haver Combinações de A) e (B em uma Sobreposição. As Figuras 3a e 3b ilustram o uso de camadas de abstração para determinar a semelhança dos nós no modelo de Sobreposição. Por meio de exemplo, nós consideramos o cenário de um modelo corporativo que representa operações corporativas, processos corporativos, seu status e estado, bem como oportunidades, riscos, etc. Olhando para uma configuração exemplar de todo o modelo de Sobreposição 200, nós vemos que ele está dividido em diversas camadas de abstração, cada camada conduzindo várias quantidades de detalhes. No mais elevado nível de abstração 210, encontramos um cluster de nós de abstração, tal cluster representa operações de alta consequência para o negócio, como operações relativas a uma grande variedade de negócios verticais, incluindo construção, fabricação e transporte marítimo. Cada nó, como o nó 215, representa um problema/falha ou oportunidade/sucesso (por exemplo, dano colateral de alta consequência) e está associado com um contexto 217 (por exemplo, múltiplos negócios verticais). Neste nível de abstração, um objetivo geral está descrito (por exemplo, gestão de processo de alta consequência) e poucos detalhes do processo estão incluídos.

[00118]. Mudando para o segundo nível de abstração 220, um cluster mais detalhado de nós é definido apresentando objetivos mais detalhados (por exemplo, carga/descarga de qualquer navio-tanque). O cluster 220 é dividido nos subclusters 221, 222, 223. O nó 225 no cluster 222 está associado com um contexto 227 (por exemplo, todos os tipos de navios-tanques) (semelhantemente para todos os outros nós do segundo nível de abstração 220) e está diretamente ligado ao nó 215 do cluster de nós do nível mais elevado (maior neste caso) 210 (ligação 1-1 entre os nós).

[00119]. O cluster 222 contém mais objetivos e contextos nível sênior para o qual podemos designar detalhes 221, 223 como resultado de estar em um nível de abstração inferior, dessa forma, mais domínio especificamente definido em comparação com empresas multiverticais.

[00120]. Em uma configuração exemplar alternativa, os nós de um nível de abstração mais elevado podem ser diretamente ligados com mais de um nó em um nível de abstração inferior (ligação de 1-para-N). Este pode ser o caso em qualquer nível de abstração.

[00121]. Avançando para menos abstração na terceira camada 230 (que é dividida nos subclusters 231, 232, 233), um cluster de nós mais detalhado é definido apresentando objetivos/processos mais detalhados (por exemplo, descarregar navio- tanque classe A). O nó 238 no cluster 232 está associado com o contexto 239 (por exemplo, navio-tanque classe A) e está diretamente ligado com o nó 225 do cluster de nós de nível mais elevado 223 (segunda camada de abstração). Este nível de abstração 230 pode conter mais detalhes em comparação com o nível de abstração maior 220. Na presente ilustração, este nível maior de detalhes não é mostrado por simplicidade e facilidade de visualização.

[00122]. Uma camada abaixo está a quarta camada de abstração 240, que é a camada que contém o modelo subjacente de um primeiro aplicativo que realiza uma primeira tarefa (por exemplo, descarregar o navio-tanque classe A específico com um primeiro software de aplicativo). O modelo do primeiro aplicativo no cluster 240 pode ser dividido nos subclusters 241, 242, 243, 244. O nó 245 no cluster 241 está associado com um contexto 247 (por exemplo, navio-tanque classe A tipo X1) e está diretamente ligado com o nó 235 do cluster de nós de nível mais elevado (terceira camada de abstração) 232 para transmitir dados para o cluster de nível mais elevado

235. O cluster 241 contém mais detalhes em comparação com o cluster 231, onde o cluster 231 pertence a um nível de abstração mais elevado. O nó 255 no cluster 241 está associado com o contexto 257 (por exemplo, navio-tanque classe A tipo X2) e está diretamente ligado com o nó 235 do cluster de nós de nível mais elevado (terceira camada de abstração) 231 para receber dados do cluster de nível mais elevado 230.

[00123]. Outros nós 248, 249, 250 na quarta camada de abstração 240 estão conectados a um módulo padrão preditivo 258 que contém o código do software que associa os nós 248, 249, 250 com atributos na tabela de data 259 do aplicativo externo 1 (Figura 3b). O módulo de padrão preditivo 258 também extrai o contexto das colunas apropriadas da tabela de dados 259 e o transfere para os rótulos de contexto correspondente dos nós 248, 249, 250, respectivamente. Em configurações exemplares alternativas, o módulo de padrão preditivo 258 troca informações (por exemplo, texto e/ou outros dados) com sistemas externos e também pode conter lógica de inteligência empresarial para identificar os padrões (por exemplo, em dados textuais).

[00124]. A tabela de dados 259 do aplicativo externo 1 é criada pelo aplicativo externo 1 290, tal aplicativo 1 contém, em uma configuração exemplar, um ou mais dispositivos clientes 291 (por exemplo, desktop ou dispositivo computacional portátil ou dispositivo de IdC, incluindo smartphones) em comunicação com um servidor do aplicativo 292, tal servidor do aplicativo 292 também está em comunicação com um servidor da base de dados 293.

[00125]. A quarta camada de abstração também pode conter o modelo subjacente de aplicativos adicionais, como aquele de um segundo aplicativo que realiza uma segunda tarefa (por exemplo, descarregar um navio-tanque classe A específico com um segundo software de aplicativo), no cluster 260. O cluster 260 também pode ser dividido nos subclusters 261, 262, 263, 264.

[00126]. O nó 265 no cluster 261 está associado com um contexto 267 (por exemplo, navio-tanque classe A tipo Y1) e está diretamente ligado com o nó 235 do cluster de nós de nível mais elevado (terceira camada de abstração) 230 para transmitir dados para o cluster de nível mais elevado 230. O cluster 264 contém mais detalhes em comparação com o cluster 230, onde o cluster 230 pertence a um nível de abstração mais elevado. O nó 275 no cluster 262 está associado com o contexto 277 (por exemplo, navio-tanque classe A tipo Y2) e está diretamente ligado com o nó 235 do cluster de nós de nível mais elevado (terceira camada de abstração) 230 para receber dados do cluster de nível mais elevado 230.

[00127]. Outros nós 268, 269, 270, 271 na quarta camada de abstração 241 estão conectados a um módulo de padrão preditivo 278, tal módulo contém um código de software que associa os nós 268, 269, 270, 271 com atributos na tabela de dados 279 do aplicativo externo 2. O módulo de padrão preditivo 278 também extrai o contexto das colunas apropriadas da tabela de dados 279 e o passa para os rótulos de contexto correspondentes dos nós 268, 269, 270, 271, respectivamente.

[00128]. Em configurações exemplares alternativas, o módulo de padrão preditivo 278 troca informações (por exemplo, texto e/ou outros dados) com sistemas externos e também pode conter lógica de inteligência empresarial para identificar os padrões (por exemplo, em dados textuais).

[00129]. A tabela de dados 279 do aplicativo externo 2 é criada pelo aplicativo externo 2 295, tal aplicativo 2 contém, em uma configuração exemplar, um ou mais dispositivos clientes 296 (por exemplo, desktop ou dispositivo computacional portátil ou dispositivo de IdC, incluindo smartphones) em comunicação com um servidor do aplicativo 297, tal servidor do aplicativo 297 também está em comunicação com um servidor da base de dados 298.

[00130]. O propósito de conectar os nós 245, 255 da quarta camada de abstração 240 e os nós 265, 275 do cluster 260 com o nó 235 da terceira camada de abstração 230 é integrar os atributos armazenados nas tabelas 259, 279 através de uma operação de translação de dados. Conforme explicado, isto é facilitado pelos módulos de padrão preditivos 258, 278.

[00131]. Na configuração exemplar da Figura 3a-b, um nó de um nível de abstração superior pode ser ligado diretamente com um nó em um nível de abstração inferior (ligação 1-to-l) onde a localização dos dois nós está associada por meio de semelhança nos clusters de nós correspondentes. Em outras palavras, se considerarmos que o nível de abstração inferior é essencialmente semelhante em termos semânticos e semelhante na lógica de causa e efeito com um nível de abstração superior, mas enriquecido com nós de detalhes adicionais, os nós no nível de abstração superior e os nós na parte correspondente do nível de abstração inferior são diretamente conectados por semelhança como distintos da causa e efeito. Isto não é ilustrado, exceto para poucas conexões de similaridade entre as camadas de abstração nas Figuras 3a-b para propósitos de simplicidade.

[00132]. A Figura 3c ilustra uma operação de translação de dados. O modelo de integração 386 pode ser visualizado conectando-se o modelo 382 do aplicativo 1 (associado com o contexto 383 e contendo dados “X”) e o modelo 384 do aplicativo 2 (associado com o contexto 385 e contendo dados “Y”) para formar o modelo de integração combinado 386 (associado com o contexto 387 e contendo dados “X e Y”).

[00133]. A revelação que acompanha a Figura 3a-3c explica como, dividindo o modelo de Sobreposição em diversos níve3is de abstração e detalhes e utilizando a rastreabilidade do modelo combinando dados e lógica no mesmo modelo, uma pessoa pode rastrear aplicativos subjacentes quanto a funcionalidades comuns. É possível integrar todas estas noções em um modelo explícito que também descreve a funcionalidade subjacente. A funcionalidade subjacente pode ser abstraída porque uma pessoa pode rastrear a semântica e o estado exato de cada atributo nas camadas abaixo (isto é, as camadas de detalhes maiores) e aplicar a lógica na camada abstraída que segue a lógica das camadas abaixo. Este é um benefício do modelo de Sobreposição uma vez que isto não pode ser feito com modelos conceituais convencionais e nem com software não modelado convencional, porque na programação e nos modelos convencionais, o estado não é definido para cada atributo e a lógica não está simplesmente definindo a relevância legível por máquina (como no modelo de Sobreposição). Ao contrário, a lógica na técnica anterior inclui a recuperação de muitos atributos que não resolvem identificar adequadamente nós fontes em um modelo contínuo. A lógica da técnica anterior também inclui o estado modelo implícito, mas não explicitamente. A lógica convencional também inclui a lógica da conversão que não pode ser prontamente abstraída para propósitos de modelagem porque ela não envolve qualquer semântica do atributo.

[00134]. Existem diversos motivos relacionados além de abstrair a lógica, como porque na técnica anterior a modelagem da Entidade-Relacionamento e a lógica separada não podem ser abstraídas no sentido descrito aqui. Um motivo é que na técnica anterior, o modelo de dados não define individualmente ou diferencia atributos e seu estado das entidades das quais elas se originam (que têm muitos atributos). Portanto, os atributos não têm identificação e estado autônomos seja no modelo de dados ou no código. Portanto, na técnica anterior, os atributos não podem ser conectados pela lógica para formar um modelo de causa e efeito para que aqueles clusters de nós em várias camadas de abstração possam ser modelados. As entidades ou objetos podem ser abstraídos para versões mais generalizadas, mas entidades ou objetos generalizados não constituem modelos como na Sobreposição onde os nós são conectados por causa e efeito. Portanto, comparar diretamente as entidades e objetos uns aos outros em vários níveis de abstração pode apenas gerar um resultado sim ou sem combinação. Não pode haver uma comparação de similaridade porque não há modelo de atividade/processo/objetivo envolvido em uma entidade ou objeto individualmente. A comparação quanto à similaridade requer lógica para relacionar atributos à lógica a fim de definir como os atributos servem aos processos e objetivos. Outra forma de dizer isto é que a similaridade requer esquemas de dados e código incorporado de forma que a funcionalidade possa ser comparada quanto ao que ela realmente faz para chegar a qualquer conclusão sobre similaridade. Veja, também, as discussões em outro lugar nesta especificação com relação à importância da abstração para a similaridade e a importância de comparações de similaridade quando vários investidores requerem critérios de conformidade tangíveis com relação aos recursos e capacidades para satisfazer as expectativas dos sistemas que eles não controlam mas nos quais se baseiam de alguma maneira.

[00135]. Os vários modelos de Sobreposição nos níveis de abstração discutidos acima e nas Figuras 3a, 3b, e 3c, podem representar qualquer aplicativo de software e não estão limitados a operações com alta consequência e navios-tanques. As abstrações também podem servir muitos propósitos incluindo, mas não se limitando a mostrar a similaridade entre os sistemas subjacentes 1 a N em cada camada de abstração abaixo, mostrando pontos de integração entre sistemas conforme ilustrado nas Figuras 3b e 3c, proporcionando meios para monitorar, regular, padronizar a atividade de sistemas subjacentes 1 a N e muitos propósitos relacionados.

[00136]. Além disso, a semântica do modelo de Sobreposição pode ser abstraída e comparada quanto ao que o modelo realmente faz e isto pode ser entre domínios. Isto é possível em virtude do modelo de Sobreposição que inclui o cluster de nós, a proximidade do objetivo entre os nós, outra lógica entre os nós, designações de ator e investidores aos nós, contexto/estado designado aos nós, unidades de quantidade designada aos nós e outros critérios mencionados aqui.

[00137]. Existem diferentes maneiras de propagar valores entre os nós. Como um método exemplar, a Figura 4 ilustra graficamente uma ligação de causa e efeito entre os nós corporativos de uma empresa conforme modelados na Sobreposição. A Sobreposição opera em um ciclo de raciocínio contínuo. No tempo de execução, quando um novo elemento de informação é inserido no sistema, seja de um sensor, um usuário ou outro sistema, um nó-fonte 10 conectado a este elemento aplica lógica de validação e lógica de mudança de estado e, então, atualiza seu estado e status de risco (ativação) adequadamente. Links de saída 12 do nó-fonte 10 são utilizados para propagar informações e o status do nó-fonte (que pode ser, por exemplo, em risco ou seu valor mudou a propagação desencadeadora) para outros nós no modelo que são conectados através destas ligações de saída. Uma vez que um link de saída 12 é ativada, sua lógica de propagação de valor 14 é aplicada a fim de enviar informações para um nó-alvo 16. Este mesmo ciclo é repetido quando o nó-alvo 16 obtém valores de suas ligações de entrada 18. Muito embora a propagação possa ter início quando um nó-fonte 10 é ativado (fica em risco) e suas ligações de saída 12 são desencadeadas, somente os nós do contexto apropriado são mostrados para o usuário que está em risco. Isto permite que o usuário durante uma sessão de consulta veja somente os nós que pertencem ao contexto correto.

[00138]. O ciclo de raciocínio para um determinado nó é representado na lista a seguir de etapas e se aplica a cada nó: Etapa 1: Informações (nó de dados) ou um evento interno/externo é apresentado como uma entrada para um nó corporativo através de um link de entrada. Etapa 2: O nó mediante o recebimento de dados através de seu link de entrada: a) Desencadeia suas facilidades de registro; b) Desencadeia sua lógica de validade e se sua lógica de validação permitir, prossegue para a etapa 2.c.; c) Desencadeia sua lógica de mudança de estado, avalia seus níveis de risco e seu estado (por exemplo, de fora de risco para em risco ou vice-versa) e a Etapa

2.d tem início. Um nó fica em risco ou alternativamente sai da condição de risco ou atinge um valor estável imutável, quando sua lógica de mudança de estado, mediante o recebimento de entrada através de um link de entrada e em conformidade com sua lógica de validação, assim ditar.

Por exemplo, o nó-alvo N1 pode ter três links de entrada de causa-efeito com os nós fontes N2, N3 e N4. Assuma que N1 está atualmente em risco ou que apresenta um determinado valor de status.

Um link de entrada pode apresentar valores de um nó-fonte N2 indicando que o nó N2 acabou de sair do risco ou possui um valor que não induz propagação, enquanto que os outros dois nós fontes N3 e N4 ainda estão em risco ou têm valores que induzem propagação através da lógica de causa e efeito decorrente de cada nó N2, N3. A lógica de validação de N1 e a lógica de mudança de estado podem determinar que N1 seja mantido com status em risco ou status aguardando mudança, se, por exemplo, a validação de N1 e a lógica de mudança de estado exigirem que todos os nós N2, N3 e N4 não estejam em risco ou não exigindo mudança de status para que N1 não esteja em risco ou não exija mudança de status.

Os nós com maior proximidade com o objetivo de alto nível da empresa são avaliados primeiro em casos onde os recursos de processamento são escassos, por exemplo, em uma emergência; d) Se o contexto do nó estiver em conformidade com a função do usuário e/ou o nó estiver no contexto no qual a sessão de consulta atual ocorrer, então, o nó é mostrado ao usuário com estando em risco.

Se nenhuma informação sobre o contexto estiver disponível para um nó, ele obtém as informações de contexto faltantes ao longo da via de raciocínio exercida até então.

Por exemplo, considere que 10 navios com diferentes nomes como contextos possam se propagar para 10 outros nós com o contexto dos navios correspondentes até que eles alcancem todos os nós dos navios que não tenham contexto de navios e agreguem os status para cada propagação de navio individual.

O processo prossegue para a Etapa 2.e; e) Nós de interface do usuário (IU) são notificados e, com base no nível de alerta do nó corporativo, o dispositivo/display de IU do lado do cliente reorganiza a informação classificada de acordo com o nível de alerta do nó exibido.

Nós de IU podem ser notificados imediatamente ou depois de um grupo pré-definido de nós corporativos ter sido notificado (isto é, visitado pelo processo); e f) Os links de saída são desencadeados e sua lógica de propagação de valor executa e os escores de proximidade do objetivo são calculados ou outros valores são calculados com base nas unidades dos status dos nós e na lógica de propagação.

Se não houver links de saída, o processo termina. Se houver links de saída, o processo prossegue para a Etapa 3. Etapa 3: Uma vez que um link de saída é ativado e sua lógica de propagação de valor é computada, as informações e valores computados são, então, alimentados no nó-alvo do link e a Etapa 2 é realizada.

[00139]. Os modelos preferivelmente convergem. Isto é, os ciclos devem ser evitados. No entanto, podem ocorrer ciclos em modelos incompletos como resultado de loops de feedback incompletos, ou incorporação incompleta do modelo. Os ciclos podem apresentar oscilações infinitas nos estados e pode fazer com que o processo continue para sempre. A fim de evitar oscilações infinitas, o sistema registra o estado global de seu modelo (o estado e o contexto de cada nó), e se o estado global atual do sistema/modelo for o mesmo de um estado que foi alcançado anteriormente (oscilação) o processo de raciocínio termina. Loops de feedback podem ser evitados quando o modelo for suficientemente definido por meio de quebra do nó de forma que o feedback para um nó causal é diminuído depois de cada repetição.

[00140]. Muito embora a propagação de valores seja exclusivamente alcançada por nós de domínio/negócio e seus parâmetros de estado e a propagação de valor por meio de lógica entre os nós, a semântica do modelo de Sobreposição é tal que a proximidade do objetivo como um tipo de critério de relevância, pode ser um fator importante na Sobreposição para computar a “potência” de propagação de valores através de um link quando necessário. Por exemplo, se um valor for realizado através de links ao longo de uma via, a “potência” ou a “importância” deste valor é alta quando, como uma função das etapas e lógica da via, o processo alcançou um nó importante de alto nível. Portanto, os nós que estão mais próximos de um objetivo podem ser de maior importância do que outros nós. Muito embora estes conceitos possam ser aplicados, a semântica do modelo permite estes conceitos de comprimento da via e proximidade do objetivo. Esta é uma forma importante de priorizar a propagação do modelo em momentos onde o processador que processa os recursos é inferior ao exigido de forma que processos importantes sejam processados primeiro.

[00141]. Em um exemplo de processamento de Proximidade do Objetivo, a Proximidade (G, N) de um nó corporativo N com relação a um nó corporativo do objetivo G, é uma propriedade do nó corporativo N, e se refere à proximidade em termos de um comprimento da via de causa-efeito do raciocínio do nó N para o nó G, e/ou a potência da relação de causa-efeito do nó N para o nó G (isto é, quanto o nó corporativo N contribui para aumentar ou diminuir o nível de risco do nó G). Por exemplo, uma das vias do nó N para o nó G apresenta um comprimento de 10 (isto é, ele possui 10 ligações de N para G), mas, até agora, 6 links ao longo da via foram ativados (por exemplo, do nó N ao nó N6). Observe que a proximidade do objetivo do nó N6 até um nó do objetivo G pode ser determinada pelo comprimento da via remanescente (isto é, 4 no exemplo acima), ou como uma função das potências (isto é, pesos) dos pesos ao longo da via remanescente de N6 até G. Um exemplo desta função pode ser a média dos pesos ao longo da via. Por exemplo, a potência do nó N6 pode ser (w6,7 + w7,8 + w8,9 + W9,G) / 4, onde w6,7 é o peso da ligação do nó N6 ao nó N7. Outro exemplo desta função pode ser a Proximidade do Objetivo (N, G) = máx. sobre todos os P j ( i=1..k wi,m)/k2 onde Pj é uma via que leva de N a G, k é o comprimento desta via Pj, e wi,m é o peso da ligação do nó Ni ao nó Nm na via Pj. Outras funções que levam em consideração todos os pesos ao longo da via de raciocínio (por exemplo, os pesos das ligações que já foram percorridas e os pesos das ligações remanescentes na direção do nó do objetivo G.

[00142]. O comprimento de uma via de raciocínio de um nó corporativo N até um nó do objetivo G, é definido como o comprimento da via (em termos de teoria de gráfico) que é formado pelas ligações de causa-efeito do nó corporativo N até o nó do objetivo G. Um nó corporativo N pode ter diferentes vias de causa-efeito até o nó do objetivo N. Conforme mostra a Figura 2, cada uma destas vias tem seu próprio comprimento, de forma que uma pessoa pode definir a via mais longa ou as vias mais curtas. Em qualquer caso, cada comprimento de via é determinado pelas ligações que foram ativadas até o momento do nó N em direção ao nó do objetivo G. Por exemplo, uma das vias do nó N para o nó G apresenta um comprimento de 10 (isto é, ele possui 10 ligações de N para G), mas, até agora, 6 links ao longo da via foram ativados (por exemplo, do nó N ao nó N6). A este respeito, a proximidade do objetivo ao longo desta via é 4, o comprimento da via percorrida até o momento é 6, e esta via de raciocínio atual de N até G é 10. Observe que a proximidade do objetivo de um nó (por exemplo, N6) até um nó de objetivo G é determinada pelo comprimento da via remanescente (isto é, 4 no exemplo acima), ou como um função das potências (isto é, pesos) dos pesos ao longo da via remanescente de N6 até G. Um exemplo desta função pode ser a média dos pesos ao longo da via. Por exemplo, a potência do nó N6 pode ser (w6,7 + w7,8 + w8,9 + w9,G) / 4, onde w6,7 é o peso da ligação do nó N6 ao nó N7. Outro exemplo desta função pode ser a Proximidade do Objetivo (N, G) = máx. sobre todos os P j ( i=1..k wi,m)/k2 onde Pj é uma via que leva de N a G, k é o comprimento desta via Pj, e wi,m é o peso da ligação do nó Ni ao nó Nm na via Pj.

[00143]. O processo de raciocínio ao longo de todos os nós pode ser observado em dois diferentes modos, o modo descendente e o modo ascendente.

[00144]. No modo descendente, o usuário ou um terceiro sistema seleciona um ou mais objetivos a serem atendidos um contexto no qual os objetivos devem esperar. No modo descendente de raciocínio, o processo de raciocínio tenta verificar todos os nós que contribuem para a satisfação dos objetivos selecionados.

[00145]. No modo ascendente, o usuário ou um sistema terceiro apresenta o contexto e todos os dados que estão disponíveis e todos os nós de Sobreposição relevantes (conectados) são ativados. Consequentemente, os nós ativados (isto é, os nós que mudam o estado), podem ativar outros nós através das ligações de causa- efeito. O processo continua em um loop ativando todos os nós que podem ser ativados, e o processo termina (isto é, converge) quando todos os nós e todos os links que podem ter sido ativados no modelo foram ativados, e/ou um estado global que foi observado antes é alcançado. O estado global é definido como a coleta de todos os estados de todos os nós alcançáveis, nesta seção, no modelo.

[00146]. Os algoritmos que seguem são exemplares e apresentados para ilustração. Reconhece-se que eles podem ser reavaliados, avaliados ou alterados para se enquadrar nos objetivos de implementação pelos desenvolvedores do sistema.

RACIOCÍNIO DESCENDENTE

[00147]. A Figura 5 ilustra graficamente diferentes comprimentos de vias de causa e efeito que levam ao mesmo objetivo. O processo de raciocínio global descendente para cada objetivo G e contexto CTX é descrito pelas seguintes fases e etapas: FASE A. INICIALIZAR O OBJETIVO E O CONTEXTO

1. Deixe G ser o objetivo superior identificado pelo usuário ou por um processo automatizado com base em casos passados ou classificações de risco passadas, oportunidades e ameaças. Deixe o contexto da sessão ser denotado pelo CTX. FASE B. IDENTIFIQUE AS VIAS QUE LEVAM AO OBJETIVO

2. Deixe L = [L1, L2, ...Li] ser a lista de listas (vias), onde cada via é composta de nós de modelo do processo que levam, através de ligações de causa e efeito, ao nó do objetivo G (como as vias L1, L2, e L3 representadas na Figura 5.

3. Deixe cada lista Lj em L, ser composta de nós de modelo do processo de forma que Lj = [G, Aj1, Aj2, Aj3, ...Ajn] (observe que o tamanho de cada lista Lj pode diferir dependendo do comprimento da via que leva ao nó do objetivo G. FASE C. CRIE A LISTA DE TRABALHO

4. Crie uma lista de trabalho WL = [A11, A12..., A21,...A2n, ... Ai1, Ain] (isto é, uma lista composta de todos os elementos das listas Lj em L, isto é, todos os nós em todas as vias). Observe que pode haver nós duplicados na lista de trabalho WL porque estes nós aparecem em diferentes vias. FASE D. PROCESSE A LISTA DE TRABALHO

5. Muito embora a WL tenha elementos e o usuário não tenha terminado a sessão FAZER mais TERMINAR

5.1 Classifique a lista WL de acordo com o risco, o nível, a prioridade, a gravidade, a experiência passada ou, o contexto em ordem decrescente. O nó com o escore mais alto aparece como o primeiro elemento da lista WL. Vamos chamar este nó de Ck. Observe que este nó aparece em uma via na direção de G. FASE E. INTERAÇÃO COM O USUÁRIO DE ACORDO COM A DINÂMICA E COM O

CONTEXTO

5.2 Estabeleça como Uk o nó no modelo de interface de usuário que corresponde ao nó do modelo de processo Ck, e Ck está no contexto CTX

5.3 Se Uk tiver que obter dados do usuário, então:

5.3.1 Crie um formulário para ser enviado para o dispositivo do cliente de forma que o usuário possa inserir dados Dk1, Dk2, Dk3 etc. A lógica para a criação de formulários é incorporada em cada nó Uk, e no dispositivo do cliente.

5.3.2 Caso o nó Ck seja um cluster de nós no modelo do processo, expanda os nós de forma que o usuário possa fornecer os dados necessários apropriadamente para cada nó no cluster através dos nós do modelo de interface do usuário correspondente Ukx. Se o nó Ck for um padrão sequencial, então, para cada nó no padrão sequencial, visite o nó e execute-o. A execução de um nó no padrão sequencial significa que o código do nó executa, ou o usuário realiza uma ação conforme orientado pelo nó e sua lógica de renderização, ou os dados são lidos ou escritos de/para uma fonte/dissipador de dados ou sistema externo de terceiro. As ações de um nó em um padrão sequencial podem ser Síncronas ou Assíncronas. Síncronas significa que toda a execução do sistema para até que esta ação seja realizada. Assíncronas significa que a ação prossegue independentemente e informa o sistema que ela já foi concluída e fornece qualquer dado ao sistema.

5.4 Se Uk for obter dados de um sensor, então, invoque o software que lê dados Dk1, Dk2, Dk3 etc. a partir do sensor apropriado. FASE F. DESIGNAÇÃO DE VALORES PARA NÓS DO MODELO CORPORATIVO

5.5 Alimente os dados Dk1, Dk2, Dk3 etc. em um nó de dados INk e propague os valores para o nó do modelo corporativo Ck. A este respeito, o nó Ck obteve, agora, seus novos valores. FASE G. COMPUTAÇÃO DE ESTADO NOVO E NÍVEL DE RISCO PARA O NÓ

5.6 Avalie o novo estado S, o nível de risco R, e os resultados de saída F para cada link de saída do nó Ck. FASE H. O OBJETIVO FOI ALCANÇADO

5.7 Se Ck for o nó de objetivo G superior, então notifique o usuário com resultados (isto é, valores de risco do nó G) e Termine. FASE I. PROPAGAÇÃO DE VALORES PARA OUTROS NÓS

5.8 Propague os valores, o estado, o contexto, as funções:

5.8.1 Identifique todos os nós Nk1, Nk2, ..., Nkx que estejam diretamente ligados ao nó Ck através de links de causa-efeito de entrada e apareçam em uma via na direção G, isto é, os nós Nk1, Nk2, Nkx, que aparecem como elementos em uma lista L1, L2, …, Li.

5.8.2 Para cada nó Nk1, Nk2, ...Nkx

5.8.2.1 Propague valores utilizando a lógica de propagação de valor de cada uma das ligações do nó Ck com os nós Nk1, Nk2, ...Nkx

5.8.2.2 Avalie novos valores para Nk1, Nk2, ...Nkx utilizando a validação e a lógica de mudança de estado incorporada em cada nó Nk1, Nk2, ...Nkx

5.8.3 Remova o nó Ck da lista WL.

5.8.4 Vá para a Etapa 5.10. FASE J. NENHUMA PROPAGAÇÃO NECESSÁRIA

5.9 Se por algum motivo o nó Ck não garantir a propagação de seus valores e estado para outro conectado com seus nós (isto é, a sequência de propagação é cortada), remova o nó Ck da lista WL. FASE K. OTIMIZAÇÕES

5.10 O sistema pode remover, para propósitos de otimização, outros nós da lista

WL que ficaram sem relevância ou apresentam escore baixo. FASE L. ETAPA DE ITERAÇÃO

5.11 Vá para a Etapa 5.

[00148]. Observe que G pode ser um objetivo superior artificial que faz com que um conjunto de nós do objetivo convirja para, ou seja um nó do objetivo de uma lista de nós de objetivo LG. O processo acima terá início para cada nó do objetivo Gi; na lista LG. Uma questão a ser considerada no projeto final de qualquer algoritmo de raciocínio é como lidar com ciclos no modelo, a fim de evitar propagações em loop infinito, ou oscilações (o estado global do modelo - o estado coletivo de todos os nós - oscila de um estado global para outro). O método primário serve para dividir nós subordinados na parte subordinada do ciclo para garantir que os loops sejam alimentados de volta nos nós parciais subordinados ou intermediários e suas ligações lógicas e, dessa forma, são reduzidos.

RACIOCÍNIO ASCENDENTE

[00149]. Do mesmo modo, o processo de raciocínio global ascendente para inserir dados D = {d1, d2, ...dn} e o contexto CTX é descrito pelas fases e etapas a seguir: FASE A. INICIALIZAR LISTA DE TRABALHO

1. Deixe a lista de trabalho WL ser WL = [N1, N2, ..., Nk], onde N1, N2, ..., Nk são os nós corporativos imediatamente afetados pelos dados em D. FASE B. SELECIONE O NÓ E OBTENHA DADOS

2. Muito embora a WL tenha elementos e o usuário não tenha terminado a sessão FAZER mais TERMINAR

2.1 Classifique a lista WL de acordo com o nível de efeito ou nível de risco. Outros critérios mensuráveis como prioridade, gravidade, experiência passada podem ser considerados através de lógica adicional. O contexto tem uma função na combinação do contexto dos nós N com os dados em D para obter a combinação lógica do contexto quando da propagação. O contexto pode ser um critério prioritário em determinadas situações. O nó com o escore mais alto aparece como o primeiro elemento da lista WL. Valos chamar este nó de Ck.

2.2 Estabeleça como Uk o nó no modelo de interface de usuário que corresponde ao nó do modelo de processo Ck, e Ck está no contexto CTX

2.3 Se Uk tiver que obter dados do usuário, então:

2.3.1 Crie um formulário para ser enviado para o dispositivo do cliente de forma que o usuário possa entrar dados Dk1, Dk2, Dk3 etc. A lógica para a criação de formulários é incorporada em cada nó Uk, e no dispositivo do cliente.

2.3.2 Caso o nó Ck seja um cluster de nós no modelo do processo, expanda os nós de forma que o usuário possa fornecer os dados necessários apropriadamente para cada nó no cluster através dos nós do modelo de interface do usuário correspondente Ukx. Se o nó Ck for um padrão sequencial, então, para cada nó no padrão sequencial, visite o nó e execute-o. A execução de um nó em um padrão sequencial significa que o código do nó executa, ou o usuário realiza uma ação conforme orientado pelo nó e sua lógica de renderização, ou os dados são lidos ou escritos de/para uma fonte/dissipador de dados ou sistema externo de terceiro. As ações de um nó em um padrão sequencial podem ser Síncronas ou Assíncronas. Síncronas significa que toda a execução do sistema para até que esta ação seja realizada. Assíncronas significa que a ação prossegue independentemente e informa o sistema que ela já foi concluída e fornece qualquer dado ao sistema.

2.4 Se Uk for obter dados de um sensor, então, invoque o software que lê dados Dk1, Dk2, Dk3 etc. a partir do sensor apropriado. FASE C. DESIGNAÇÃO DE VALORES PARA NÓS CORPORATIVOS

2.5 Alimente os dados Dk1, Dk2, Dk3 etc. em um nó de dados INk e propague os valores para o nó do modelo corporativo Ck. A este respeito, o nó Ck obteve, agora, seus novos valores. FASE D. COMPUTAÇÃO DE ESTADO NOVO E NÍVEL DE RISCO PARA O NÓ

2.6 Avalie o novo estado S, o nível de risco ou impacto R, e os resultados de saída F em cada link de saída do nó Ck aplicando a lógica de propagação de valor de cada link de saída. FASE E. PROPAGAÇÃO DE VALORES PARA OUTROS NÓS

2.7 Propague os valores, o estado, os contextos, as funções:

2.7.1 Identifique todos os nós Nk1, Nk2, ...Nkx que estão diretamente ligados ao nó Ck através de ligações de causa-efeito de entrada.

2.7.2 Para cada nó Nk1, Nk2, ...Nkx

2.7.2.1 Propague valores utilizando a lógica de propagação de valor de cada uma das ligações do nó Ck com os nós Nk1, Nk2, ...Nkx.

2.7.2.2 Avalie novos valores para Nk1, Nk2, ...Nkx utilizando a validação e a lógica de mudança de estado incorporada em cada nó Nk1, Nk2, ...Nkx

2.7.3 Remova o nó Ck da lista WL.

2.7.4 Adicione nós Nk1, Nk2, …Nkx na WL excluindo quaisquer destes nós que tenham estado anteriormente na WL (isto serve para evitar iterações / oscilações infinitas).

2.7.5 Vá para a Etapa 2.9. FASE F. NENHUMA PROPAGAÇÃO NECESSÁRIA

2.8 Se por algum motivo o nó Ck não garantir a propagação de valores para outros nós (isto é, a sequência de propagação é cortada), remova o nó Ck da lista WL. FASE G. OTIMIZAÇÕES

2.9 O sistema pode remover, para propósitos de otimização, outros nós da lista WL que ficou sem relevância ou apresenta escore baixo. FASE H. ETAPA DE ITERAÇÃO

2.10 Vá para a Etapa 2.

[00150]. Os nós corporativos podem estar em um de dois estados de status possíveis a) status em risco ou b) status fora de risco. No entanto, o risco ou a ausência de risco é um aspecto da mudança de status e não deve ser considerado apenas o sentido de um perigo. Em risco ou fora de risco podem, respectivamente, significar estar para fazer uma mudança no próximo em nós afetados pela propagação ou não estar para fazer uma mudança nos nós afetados. Ou, o status em risco pode significar que um processo precisa da atenção do investidor enquanto que fora de risco pode significar que o processo tem pouca necessidade de atenção pelo usuário. O diagrama de estado que descreve isto está representado na Figura 6. A Figura 6 representa que um nó pode estar em estado de status EM RISCO (S-01) ou estado de status FORA DE RISCO (S-02). Se um nó estiver no estado EM RISCO e ao receber dados de entrada (idata 1) e estar no estado atual (cstate 1), sua função de lógica de mudança de estado (SCL) pode transferir o nó através da transição T-01 do estado de status EM RISCO para um novo estado de status FORA DE RISCO. O argumento semelhante serve para as outras transições. Observa-se que o nó que está no estado de status FORA DE RISCO, pode receber dados de entrada (por exemplo, idata4) em um estado atual (por exemplo, cstate4) e permanecer no mesmo estado de status (veja a transição T-04).

[00151]. Uma vez que um nó muda seu estado de risco, então, ele propaga seus valores de atributo para seus nós vizinhos Ni através de suas ligações de causa- efeito de saída. Isto pode causar, através da lógica de propagação de valor de seus links de saída e da lógica de validação de seus nós vizinhos-alvo, o nó vizinho Ni para consequentemente mudar seu próprio estado de status. Esta mudança de status pode se propagar, então, através do gráfico do modelo.

[00152]. Deve-se observar que os exemplos acima se referem a nós em risco. Eles podem, na maioria dos casos, se referir, também, aos nós afetados sem um elemento de risco como, por exemplo, uma propagação que afeta o próximo nó como em uma transação na qual o nó afetado está, por exemplo, em uma máquina automática de vendas para liberar um confeito depois que o pagamento é recebido, ou em um processo de concurso para aprovar um fornecedor para o próximo estágio de processamento depois que diversos algoritmos de comparação de preço forem satisfeitos.

[00153]. A Sobreposição também difere da técnica anterior no sentido de que o mecanismo de tempo de execução está programado para executar conversões sem executar consultas sobre a localização e recuperação de dados associadas com modelos de dados relacionais como na técnica anterior. Se consultas de recuperação de dados forem utilizadas, a rastreabilidade do modelo de domínio pode ser perdida, portanto, as consultas sobre a localização e recuperação de dados são evitadas no modelo de domínio de Sobreposição. Portanto, diferente da técnica anterior, o tempo de execução da Sobreposição não executará consultas no modelo de dados relacionais em combinação com algoritmos de conversão. No entanto, para quaisquer cálculos de múltiplos estágios no domínio, cada algoritmo de conversão do modelo de domínio da Sobreposição deve ser capaz de se referir àqueles nós e seus status e seus parâmetros de estado que estão ligados ao algoritmo de conversão. Mas esta referência aos nós só deve se referir aos nós imediatamente subordinados, caso contrário, a rastreabilidade pode ser perdida.

[00154]. Em uma configuração do modelo de propagação de Sobreposição, o contexto é designado a cada nó para representar o que na técnica anterior é um aspecto definidor do estado, como um atributo importante de um objeto de negócio que liga diversos objetos do negócio e possui seu próprio atributo ainda em outro objeto do negócio. Os atributos que na técnica anterior estão associados com o contexto como atributos de entidade de um identificador-chave, podem, na Sobreposição também se tornar nós e são conectados pelas ligações lógicas legíveis por computador onde são ativos na propagação dentro do modelo de propagação de sobreposição de nós interconectados.

Por exemplo, se um tripulante for um contexto para uma atividade da tripulação como receber um cheque de pagamento, um “nó receber cheque de pagamento” recebe a designação do contexto de um determinado tripulante.

No entanto, se o tamanho do sapato do triplante for necessário para o vestuário de emergência, e se houver um nó denotando “combinação do tamanho do sapato dos tripulantes com o vestuário de emergência disponível” então, o nó que denota “tamanho de sapato” se torna uma parte ativa do modelo que propaga adequadamente para reafirmar ao sistema da empresa que existe uma combinação.

Este “tamanho de sapato” fica conectado à “combinação do tamanho do sapato do tripulante com o vestuário de emergência disponível” através de uma ligação de causa e efeito enquanto se atribui a ambos os nós o contexto do tripulante em particular.

Na técnica anterior, o contexto do tripulante teria atributos e o tamanho do sapato poderia ser um deles.

No entanto, os sistemas da técnica anterior não acomodam o código adjacente aos atributos como “Tamanho do Sapato” ligando este ao nó “combinação do tamanho do sapato do tripulante com o vestuário de emergência disponível”. Portanto, o atributo pode ser perdido no esquema de dados convencional se não foi incorporado como um atributo nos objetos do negócio do tripulante onde o tripulante é um atributo-chave ou contexto.

O agrupamento de atributos dentro do objeto do negócio como tripulantes torna a compatibilidade entre os sistemas que são desenvolvidos separadamente mais difícil pelos motivos relacionados a seguir.

Os atributos não são semanticamente claros, a menos que sejam adjacentes às ligações lógicas que representam como eles são utilizados em um cluster de nós e, portanto, não podem ser facilmente abstraídos e comparados quanto à semelhança.

Também, os atributos estão em um grupo como um objeto de negócio que não possui relação lógica legível por computador entre os atributos no objeto do negócio e não se pode atribuir similaridade legível por computador a isto.

Portanto, o objeto do negócio ou as entidades da técnica anterior são idênticos ou diferentes de forma indefinida para o computador.

Na Sobreposição, as ligações lógicas e atributos autônomos como o tamanho do sapato são conectados por uma lógica legível por computador aos nós que elas afetam e, portanto, a semântica e a localização destes atributos como o tamanho do sapato no modelo de dados são inequívocos.

Sistemas de IdC que precisam interoperar se beneficiarão significativamente de serem descritos em termos de Sobreposição, incluindo os estados dos nós e as ligações adjacentes.

[00155]. Em uma configuração, o contexto de Sobreposição é designado a um nó como uma diferenciação legível por humanos de outros contextos para um nó no mesmo nome. Portanto, o contexto é uma propriedade legível por humanos do nó. Para a máquina, o contexto define nós adicionais com os mesmos nomes identificados separadamente. Para as interfaces do usuário na Sobreposição, o contexto é uma forma de apresentar muitos nós em diferentes contextos sem repetir o nome do nó. No armazenamento, cada nó com um contexto diferente independente se o rótulo dos nós é o mesmo, é armazenado independentemente de forma que cada valor de status armazenado não é confundido com valores de status de nós com o mesmo nome e diferente contexto.

[00156]. A identificação do contexto em um sentido de domínio de empresa na Sobreposição é alcançada pelos clusters de identificação dentro do modelo do domínio que pode ser associado com contextos; isto é, contextos como rótulos para diferenciar nós com mesmo nome com diferentes contextos. Estes clusters de identificação podem conter lógica e ponderação para servir para emular como a identificação é realmente atingida no domínio. Por exemplo, identificar pessoas como tripulantes de um navio pode ser um uso simples de seu primeiro e último nome quando o aplicativo de software que precisa desta identificação só programa o uso de unidades de recreação a bordo. No entanto, se uma lista de tripulantes for utilizada para identificar tripulantes para se apresentarem às autoridades de imigração em terra, nós precisamos do nome completo, do nome do meio, do sobrenome, nós precisamos dos números dos passaportes, do número da cédula de marítimo, da data de nascimento, do posto à bordo, números de licença, etc. Em um exemplo adicional, identificar tripulantes a serem designados a processos críticos como atores pode exigir mais identificação, incluindo atributos relacionados como habilidades, experiência e mais detalhes da licença. Portanto, as combinações de identificação dependem de como elas serão utilizadas e isto envolve lógica e, portanto, é colocado na grade do domínio.

[00157]. A Sobreposição permite que cada status de nó seja associado com o estado do nó, incluindo contexto específico ou designação para uma função. Isto, combinado com a lógica adjacente, significa que os atributos do modelo obtém semântica específica auxiliada pela causa e efeito. Isto é assim porque o nó e a lógica que o acompanha são muito mais bem somaticamente definidos sem a necessidade de esforço massivo para padronizar a semântica.

[00158]. Em outra configuração, a Sobreposição permite a abstração de funcionalidade específica na funcionalidade abstraída. Por exemplo, um trabalho de reparo para um navio possui datas em que o navio e seus componentes estão disponíveis para serem reparados. Os recursos que estão disponíveis também precisarão ser agendados. Também há trabalhos que são pré-requisitos para outros trabalhos, trabalhos que estão em conflito quando acontecem concorrentemente, recursos que são ocupados em outros trabalhos, etc. Um sistema de sobreposição pode representar o processo de agendamento dos recursos e dos trabalhos. No entanto, um cluster de Sobreposição abstraído também pode ser construído, isto é, abstraído em comparação com o cluster de domínio. Isto acontece abstraindo-se o processo de agendamento e abstraindo-se as interações e durações de recursos abstraídos e a demanda abstraída para os recursos. O uso de uma abstração torna possível determinar como um processo de agendamento de nível de domínio se compara ou atende as exigências mais gerais para priorização do agendamento.

[00159]. Por exemplo, no agendamento de recursos do processador do computador em sistemas sensíveis ao recurso, as prioridades de agendamento abstraídas podem ser configuradas pela proximidade do objetivo dos processos que estão sendo priorizados em comparação com outros processos que afetam os objetivos de alto nível do sistema, e o processamento do domínio e recursos do trabalho podem ser mapeados para a abstração para expor a priorização em um nível de supervisão que pode ser regulado.

[00160]. Por exemplo, ao agendar recursos de processamento do computador em um sistema de IdC crítico utilizado, por exemplo, em um sistema de aviônica, um sistema de gestão de recursos de processamento computadorizado específico do fornecedor em um sistema de aviônica pode ser combinado com uma abstração que é utilizada para regular tal sistema para determinar a conformidade com os regulamentos. Isto pode proporcionar sistemas de supervisão facilmente escaláveis para garantir a conformidade com a priorização de recursos entre um sistema interoperacional. Em geral, uma camada abstraída de um modelo de domínio de Sobreposição pode servir para expressar a conformidade do software subjacente com os objetivos e limitações de mais de um investidor. Esta capacidade é relevante para sistemas interoperacionais que não têm um único investidor abrangente para garantir a interoperabilidade.

[00161]. O uso da proximidade do objetivo no domínio ou na abstração pode alinhar as exigências de priorização de qualquer tipo com a causa e efeito incorporados dos modelos de Sobreposição expondo, desta forma, a priorização de sistemas díspares e comparando com as exigências do investidor.

[00162]. A Sobreposição permite a propagação transparente de mudanças no modelo de empresa ou multiempresas para propósitos de atualização. A Sobreposição também permite a divisão do modelo de dados em modelos menores em cada placa e chip. O modelo empresarial de Sobreposição une e relaciona componentes independentes díspares utilizando suas vias de propagação transparente intrínsecas. Sem este recurso, a interoperabilidade dos componentes de IdC e de pequenos dispositivos computadorizados colaboradores é impedida. Além da representação explícita de valores de propagação de um componente de um sistema interoperacional para outro, também existe a capacidade de utilizar modelos de Sobreposição abstraídos para oferecer as abstrações da funcionalidade subjacente de forma a expor inter-relações, limitações, capacidades, redundâncias e outras capacidades de forma que os componentes de sistemas díspares possam expor suas capacidades a mais de uma parte interessada.

[00163]. Em comparação com o software convencional, por ter uma capacidade muito maior de rastrear mudanças no sistema e seu efeito na propagação, a Sobreposição torna o teste e a verificação mais rápidos e mais transparentes, torna as atualizações menores em termos de volume e o processo de desenvolvimento de atualizações muito mais curto. Isto pode ser alcançado pela identificação de componentes dependentes e pela compilação consequente e priorização dos casos de teste a serem considerados durante o processo de teste e verificação. Portanto, em domínios como os principais aplicativos de resposta à emergência como um refém ou ataque terrorista em uma cidade, onde as atualizações podem comprovar ser necessárias durante a emergência, uma vez que nenhuma emergência é igual à outra, é possível realizar a atualização utilizando a Sobreposição distribuindo atualizações muito leves apenas dos clusters de nós que tenham sido modificados. Alternativamente, ela permite que as atualizações sejam realizadas distribuindo fisicamente novos modelos ultraleves acima das unidades de micronúcleos de propósito especial (placa ou chip).

[00164]. Com os métodos convencionais, uma atualização durante uma emergência exigiria um projeto de programação massivo para cobrir o trabalho de atualização e teste a tempo e, também, um grande volume de material atualizado a ser passado através de meios convencionais, por exemplo, por célula ou internet, para pequenos dispositivos computadorizados no campo.

[00165]. Uma vantagem, em uma resposta à emergência, do uso de modelos ultraleves (para placa ou chip) combinados com modelos de Sobreposição de domínio, ao invés do processamento de software convencional e do hardware associado é que o desempenho, a proteção e a segurança são melhor por ordem de magnitude. Proteção se refere à capacidade de um usuário malevolente de manipular o sistema arbitrariamente, ou de adquirir informações confidenciais. No caso de uma resposta à emergência, segurança se refere a uma capacidade do sistema de se ajustar dinâmica e efetivamente a condições imprevistas.

[00166]. Em uma resposta à emergência, isto significa que pequenos dispositivos podem gerenciar modelos de empreendimento maiores sem exigir que uma unidade de servidor central seja uma grande instalação que talvez não seja adequada para a localização imprevisível da emergência. Também, a ausência de um servidor convencional reduz a vulnerabilidade a violações de segurança evitando o uso de linguagens de software e configurações de armazenamento com as quais os hackers estão familiarizados e com mais capacidade de atacar.

[00167]. Um recurso necessário que permite que a atualização de entregáveis seja pequena em termos de volume é a natureza do modelo de dados do modelo de Sobreposição de Domínio que combina os dados e a lógica de execução. O resultado disto é que um modelo de empreendimento significativo pode ter um modelo de dados dividido em unidades designadas para cada placa e chip. É possível ter replicação de partes do modelo de Sobreposição em diferentes placas e chips ou ter modelagem adicional por meio de modelo de sobreposição para aspectos específicos de funcionalidade de recuperação em cada placa e chip. Estas disposições de projeto e métodos semelhantes servem para evitar situações onde partes do modelo não estão sempre disponíveis devido à falta de conectividade ou falha de um processo para propagar dados entre as unidade ou falha de uma unidade de processamento de hardware. Isto não é possível com um software convencional onde o modelo de dados é um e não pode ser dividido depois do projeto inicial. Isto é possível na sobreposição porque qualquer unidade que perca sua capacidade de funcionar pode ser detectada pelas outras unidades que podem ser pré-configuradas para funcionar na sua ausência.

Caso seja uma unidade de coordenação central que perca sua capacidade de funcionar, ela pode ser substituída por um cluster de nós idênticos em uma unidade de substituição. As demais unidades funcionais podem ter lógica suficiente através dos nós e ligações para permitir o estado global provisório e compensar, bem como se adaptar a uma nova unidade. Isto porque cada unidade possui propagação rastreável específica para outras unidades e, portanto, a natureza da propagação é clara, bem como as consequências de sua interrupção. É uma questão de adicionar nós e lógica em cada unidade a qualquer momento do ciclo de vida do sistema para oferecer compensação por interrupções funcionais de outras unidades. Isto é possível em sistemas convencionais somente se for feita a partição no estágio inicial do projeto porque o esquema de dados em sistemas convencionais não define a propagação e o código não é estruturado e também não representa a propagação de forma rastreável. Sem esta rastreabilidade, é muito difícil construir métodos de recuperação do sistema, exceto no projeto original do sistema.

[00168]. A Figura 7 é um diagrama de blocos exemplar de uma unidade computacional com modelo de sobreposição de domínio. As características desta unidade computacional são: 100: Unidade Computacional com Modelo de Domínio. É um computador de placa única que se comunica com o mundo externo na Linguagem do Modelo. Apreciar- se-á que o dispositivo 100 seja somente um exemplo de um dispositivo portátil 100. É um dispositivo multifuncional que pode ter mais ou menos componentes do que se mostra na Figura 7. O dispositivo 100 pode ser combinado em uma grade de dois ou mais (conforme mostra a Figura 8), definindo um cluster homogêneo. Em um aspecto, a Unidade Computacional com Modelo de domínio é fabricada em um único chip. 101: Unidade de Processamento Central (CPU). É um dispositivo para múltiplos propósitos, programável, que aceita dados como entrada, processa-os de acordo com as instruções armazenadas nos módulos de memória 102, 106 e 108, criptografa- os/descriptografa-os utilizando módulo 109 e apresenta os resultados como saída armazenada no módulo 108, encaminha-os para outras unidades 198 (Figura 8) ou lê os dados do módulo 113 e libera os dados para os mesmos dispositivos. 102: Memória de Núcleo Não Volátil. Fica escondida para qualquer acesso externo e comunidades somente com a CPU 101. Seu propósito é armazenar os módulos 103, 104 e 105 que constituem a Memória do Núcleo.

103: L0 – Sistema Operacional (SO). Contém o SO responsável pela inicialização do sistema, sistema de arquivos, segurança, e ambiente diferente para diferentes componentes da CPU 101. 104: L1 – Núcleo do Modelo.

Contém instruções que oferecem a capacidade da unidade 100 de entender o Modelo.

Pode ser atualizado somente pelo gerente do sistema.

Novos núcleos são apresentados em binários criptografados e somente o uso do módulo 109 descriptografará e atualizará o núcleo do modelo 104. A fundamentação é para oferecer um núcleo altamente seguro que é quase impossível de ser hackeado remotamente.

Os micronúcleos são atualizados por usuários autorizados utilizando o Projeto de Sobreposição / Plataforma de Desenvolvimento.

O pacote de atualização / aprimoramento é criptografado em uma base da organização e descriptografado em uma unidade local.

No mínimo, o micronúcleo contém a implementação de nós, ligações e o modelo de propagação nas instruções da CPU.

O modelo designará aquelas implementações a fim de executar qualquer modelo de domínio. 105: L2 – Modelo de Comunicação.

Para a unidade do cliente, este módulo contém as instruções na linguagem do Modelo do Domínio, para sincronização com a parte do lado do servidor do modelo. 106: Memória de Trabalho Não Volátil.

Este módulo de memória contém o(s) Modelo(s) do Domínio.

A unidade suporta mais de um Modelo e pode executá-los em paralelo. 107: L3 – Modelo(s) de Domínio.

Modelo ou Modelos de Domínio que podem ser executados em paralelo.

Estes módulos são fornecidos para a Unidade 100 através de download pela internet ou memória flash em um arquivo criptografado.

A unidade 100 os descriptografará e atualizará.

O Projeto de Sobreposição / Plataforma de Desenvolvimento oferece uma capacidade para os Especialistas em Domínio de definir os nós que mudarão (atualização / aprimoramento) e quando. 108: Memória de Acesso Aleatório (RAM). Memória principal da unidade, volátil.

Suporta módulos comerciais (oferece o conector do módulo de memória dupla em linha com contorno pequeno (SODIMM)), até 8 GB em uma configuração exemplar.

Em configurações exemplares alternativas pode-se utilizar capacidades maiores ou menores. 109: Unidade de Criptografia/Descriptografia.

Unidade responsável por criptografar e descriptografar dados trocados com o mundo externo, ou os arquivos fornecidos para os módulos de atualização 103, 104, 105 e 107. Quando o sistema recebe um pacote / mensagem, ele utiliza a parte de descriptografia da unidade para descriptografá-lo. Quando o sistema envia um novo pacote / mensagem, ele utilizará a parte de criptografia da unidade para criptografá-lo(a). Depois da criptografia, a unidade envia a mensagem. 110: Barramento do Sistema Interno A. Barramento do sistema de alta velocidade utilizado pela CPU 101 para enviar e receber dados para os módulos 103 -

108. Somente a CPU e os módulos 103 - 108 têm acesso a este barramento. 111: Barramento do Sistema Interno B. Barramento de alta velocidade utilizado pela CPU 101 para se comunicar com os módulos do mundo externo 112, 113, 114 e

115. 112: Conector da Unidade de Suporte da Grade. Conector que será utilizado para adicionar mais unidades, se necessário. 113: Unidade de Entrada/Saída. Conector que disponibiliza portas analógicas e digitais. 114: Conector de Expansão. Conector utilizado para adicionar unidades de expansão comercial ou unidades desenvolvidas pelo empreendimento. 115: Conector de Alimentação. Conector USB utilizado para carregar as baterias da unidade ou para fornecer energia apropriada. 116: Unidade de Gestão de Energia: Unidade responsável por realizar a interface entre a fonte de alimentação 115, a bateria e a CPU 101 do sistema. A CPU é informada sobre o status da carga e os níveis da bateria através desta unidade. Além disso, ela pode implementar políticas de gestão de energia específicas de acordo com a energia disponível do sistema. Através destas políticas, ela pode agir como um mecanismo de segurança em casos de capacidade inaceitavelmente baixa da bateria, garantindo que o sistema desligará de maneira consistente e segura.

[00169]. A Figura 8 é um diagrama de blocos de uma grade da unidade computacional com modelo de domínio. As características desta unidade computacional com modelo de domínio incluem:

200. Grade de Unidades Computacionais com Modelo de Domínio. Grade de unidades do lado do servidor que funciona como um computador independente ou conectada a outros computadores. É um computador com grade de placa única que se comunica com o mundo externo na Linguagem do Modelo. O modelo de comunicação é um Modelo de Sobreposição. Existe um Cluster de Nós de Comunicação de Sobreposição que define e executa comunicações na grade descrita. É um dispositivo multifuncional que pode ter mais ou menos componentes do que mostrado na figura. O dispositivo 200 pode ser combinado em uma grade de 2, 4 ou 8 unidades, definindo um cluster homogêneo. Aqui, os módulos da CPU contêm um componente mais poderoso, ainda um baixo consumo de energia (especialmente desenvolvido para dispositivos móveis). Em um aspecto, a Grade das Unidades Computacionais com Modelo de Domínio é fabricada em um único sistema de chip.

201. Unidades Computacionais com Modelo de Domínio. Semelhante à unidade 100 da Figura 7. Uma diferença é que o módulo 105 agora é mais avançado para suportar clusters de modelo distribuídos.

202. Barramento Interno. Serve a conexão de todos os módulos 201.

203. Conector para computadores externos. O conector permite que a unidade 200 se comunique com computadores externos em alta velocidade. Também, a unidade oferece a capacidade de se comunicar com unidades semelhantes sem fio.

204. Conector de Alimentação. Conector USB utilizado para carregar as baterias da unidade ou para fornecer energia apropriada.

[00170]. Em uma configuração, o desenho do produto inclui uma placa de computador composta de componentes descritos aqui que estão amplamente disponíveis e pode ser desenvolvido como uma primeira versão de tal computador. Protótipos são desenvolvidos utilizando componentes discretos. Depois de estabilizar o micronúcleo, estes componentes são todos montados em um único chip (com a cooperação de fabricantes de chips) e vendidos como chip em uma placa de circuito impresso tendo apenas o chip e alguns conectores.

[00171]. Em uma segunda configuração, uma placa de expansão com este layout pode ser desenvolvida e instalada em uma placa de computador, ou colocada em uma máquina independente que será conectada aos computadores do servidor utilizando uma linha de interconexão de alta velocidade (incluindo, mas não se limitando a uma óptica). Esta não terá necessariamente um servidor da web ou serviços de registro e monitoramento, ou bases de dados, etc. Eles existirão como acontece agora em computadores principais. Na prática, este novo computador terá apenas o software do servidor instalado e fornecerá seu conteúdo como um serviço para o computador principal.

[00172]. A capacidade de adicionar unidades de expansão que contém os computadores de placa única descritos aqui ou rede de computadores com placa única interconectados e microprocessadores para propósito específico, ajuda a evitar complexidades na atualização, atualizando somente uma parte do micronúcleo e partes específicas do modelo de Sobreposição de domínio. Ela também permite o desenvolvimento de dispositivos móveis independentes de nova geração que são muito fáceis de atualizar utilizando um telefone celular ou internet, e permite a capacidade de ligar o dispositivo a um ambiente de trabalho e compartilhar informações e recursos.

[00173]. A unidade principal é a “Unidade Computacional do Modelo de Sobreposição de Domínio”. Esta é uma unidade computadorizada de baixo consumo de energia que é programada como um Modelo de Sobreposição de domínio e não utiliza uma linguagem de programação genérica como C, C++, C#, Python, etc. Ela utiliza o modelo de sobreposição para oferecer um programa de execução organizando o status dos parâmetros de estado do nó, organizando a localização da lógica de conversão e, também, a organização/localização do armazenamento dos dados. Linguagens de nível inferior podem ser utilizadas para lógica de conversão e comandos para o processador.

[00174]. Ela pode ser utilizada para construir modelos corporativos projetados centralmente ou modelos corporativos que consistem de componentes pré- construídos de projetistas díspares. Ela também pode ser utilizada para construir dispositivos de clientes como, mas não limitados a robôs, drones, dispositivos médicos, IdC, etc. Os Smartphones também podem ser incluídos e podem ser conectados a um modelo de domínio do servidor continuamente ou intermitentemente. Uma característica desta unidade é sua segurança, desempenho e a sincronização de dados e estado do sistema com um modelo de domínio do servidor, quando tiver acesso a um servidor. Ela possui um conector que oferece uma capacidade de conectar placas de expansão com, por exemplo, mas não se limitando a Wi-Fi, sensores biomédicos, câmeras, teclados, telas sensíveis ao toque, displays sensíveis ao toque, etc. Uma empresa pode conectar placas de expansão comercialmente disponíveis ou desenvolver suas próprias placas.

[00175]. Para reiterar, ambos os projetos exemplares são programados utilizando Modelos de Sobreposição de Domínio, possuem componentes de baixo consumo de energia, oferecem alta segurança e desempenho intermediário a elevado

(dependendo do componente 101) e permitem tanto a independência quanto a interoperabilidade das unidades de processamento.

[00176]. A Sobreposição oferece uma nova abordagem para a indústria de desenvolvimento de software. Seus principais objetivos são reduzir a complexidade de raciocínio do software, armazenamento, recuperação, propagação e rastreabilidade adotando uma estrutura de modelo mais próxima daquela pela qual os processos são realizados com menos ênfase nas entidades para representar os processos. Também, para permitir a abstração e comparação da funcionalidade.

[00177]. O ecossistema da Sobreposição contém ferramentas e um modelo de plataforma que diminui o tempo do projeto até a implementação da produção, mas, acima de tudo, permite a rastreabilidade resultando em manutenção e evolução muito mais fáceis e processamento muito mais eficiente.

EXEMPLO

[00178]. Como uma aplicação exemplar, uma única unidade computacional (hardware) que é baseada no entendimento e executando um Modelo de Sobreposição de domínio e oferecendo a infraestrutura apropriada. A unidade de hardware introduz uma grade computacional que é uma grade de unidades individuais desenvolvidas para Modelos de Sobreposição de Domínio distribuídos, proporcionando segurança e desempenho apropriados. A Unidade Computacional de Modelo de Sobreposição é uma unidade segura, de alto desempenho, independente.

[00179]. A grade de Unidades Computacionais de Sobreposição é preferida para o processamento componentizado do modelo de satélite uma vez que oferece processamento distribuído que consegue se recuperar de falhas muito mais facilmente. O modelo distribuído também é favorável para o projeto descentralizado e atualização para executar o projeto do software e a implementação que não pode esperar por uma parte interessada central, como uma empresa ou diversas empresas, para controlar e sincronizar o desenvolvimento e a implementação pelo uso de rastreabilidade de Sobreposição, flexibilidade de armazenamento de dados e outras características do projeto de Sobreposição.

[00180]. A unidade básica do hardware é a “Unidade Computacional do Modelo de Sobreposição de Domínio”. Trata-se de uma unidade computacional de baixo consumo de energia que é programada como um Modelo de Sobreposição de Domínio e não utiliza, convencionalmente, uma linguagem de programação genérica como C, C++,

C#, Python, etc. Ela pode utilizar algumas delas ou outras linguagens, mas não utiliza as linguagens convencionalmente. Ela utiliza o modelo de Sobreposição para oferecer um programa de execução e, também, a organização e armazenamento de status e estados de nós. Linguagens de nível inferior podem ser utilizadas para lógica de conversão e comandos para o processador.

[00181]. Unidades de hardware individuais serão utilizadas para compor uma coleção de unidades de hardware instaladas no satélite. As unidades de hardware podem ser genéricas no projeto. Uma característica desta unidade de hardware é sua segurança, desempenho e a capacidade de ser sincronizada em dados e estado do sistema geral com um modelo de domínio do servidor, quando tiver acesso a ele. Ela possui um conector que oferece a capacidade de conectar placas de expansão, por exemplo (mas não se limitando a), sensores, câmeras, etc.

[00182]. O projeto, programado utilizando Modelos de Sobreposição de Domínio, possui componentes de baixo consumo de energia, oferece alta segurança e desempenho intermediário a elevado e permite tanto a independência quanto a interoperabilidade das unidades de processamento. Ter as grades acima com mais de uma unidade computacional adiciona redundância.

[00183]. A Unidade Computacional do Modelo de Sobreposição de Domínio possui quatro módulos, colocados como uma pilha (em sequência): • Modelo de Sobreposição de Domínio de Satélite; • Modelo de Sobreposição de Plataforma; • Núcleo de Sobreposição; e • Sistema Operacional

[00184]. As duas primeiras camadas podem estar sujeitas a atualização frequente das equipes que têm a responsabilidade de criar e manter o modelo de satélite. As duas últimas camadas são atualizadas apenas por um gestor de sistemas e raramente mudam.

[00185]. A Sobreposição tem a capacidade de enviar mensagens de uma unidade para outra utilizando o menor pacote de: • Cluster de nós atualizado do modelo de domínio; • Código-fonte do cluster de nós atualizado; ou • Código compilado do cluster de nós atualizado.

[00186]. Cada pacote é comprimido e criptografado. O destinatário do pacote é a unidade de satélite, ela descriptografa e descomprime o pacote. Toda unidade computacional pode ter um módulo específico para compressão/descompressão e criptografia/descriptografia. Se o destinatário for uma estação local ou um dispositivo móvel terminal, a unidade apenas passa por aqueles que utilizam canais de transmissão ou de comunicação ponto a ponto.

[00187]. Os modelos podem ser fragmentados em modelos menores que podem se comunicar descontinuamente. Todo componente de um modelo de domínio tem suas próprias informações independentes e passa as mudanças apropriadas (não todas) para o componente preciso do modelo que continuará o processo. Portanto, somente pacotes pequenos são passados. Caso os pacotes precisem ser muito grandes ou se houver pressa para que eles sejam transferidos para uma unidade que não esteja localmente acessível, o sistema pode utilizar a internet, disco ou qualquer mídia suportada para transferi-los.

[00188]. Em uma configuração ilustrada na Figura 9, o sistema inclui uma unidade de processamento central 101 e diversas unidades parciais dependentes (satélite) 120, 122, 124, 126, 128, 130 designadas para funções ou partes interessadas do modelo do processo em cada unidade dependente de satélite. As unidades parciais podem se comunicar umas com as outras e com a unidade de processamento central através de uma rede sem fio.

[00189]. Cada unidade dependente de satélite inclui uma unidade computacional do modelo de domínio (100 na Figura 7) e um ou mais modelos de domínio 107. Para propósitos ilustrativos, os diferentes modelos de domínio foram designados com uma letra entre A e K. Este modelo do empreendimento é dividido entre a unidade de processamento central 101 e as unidades de satélite dependentes 120 – 130 de forma a permitir que as unidades de satélite trabalhem independentemente quando desconectadas, mas sem a coordenação permitida pela unidade de processamento central 101. Se a comunicação for perdida entre a unidade de processamento central 101 e as unidades de satélite dependentes 120 – 130, as unidades de satélite dependentes 120 - 130 ainda podem ser úteis para a função correspondente ou parte interessada, uma vez que elas conterão o suficiente do modelo do empreendimento para oferecer informações úteis. A capacidade de dividir o modelo de empreendimento permite que as unidades dependentes/satélite sejam úteis quando a comunicação é perdida. De outra forma as unidades dependentes/satélites terão funcionalidade muito limitada.

[00190]. A divisão do modelo em uma unidade de processamento central 101 e diversas unidades de satélite dependentes 120 – 130, com cada unidade instalada em um dispositivo portátil pode ser feita no início de um evento de emergência. Portanto, a repartição do modelo em diferentes dispositivos pode ser adaptada às habilidades das partes interessadas à mão em uma emergência e a repartição feita de acordo com uma designação de nós e clusters de nós para uma função ou parte interessada. As unidades dependentes que são capazes de operar independentemente quanto à funcionalidade restrita são adaptadas às habilidades e, portanto, à função ou participação do pessoal disponível.

[00191]. Um aspecto é que o modelo pode ser dividido em diferentes unidades menores da forma que o pessoal disponível na emergência ditar de forma que a funcionalidade restrita quando off-line é adaptada à função ou parte interessada.

[00192]. Com referência à Figura 10, se uma unidade for danificada, modelos de domínio naquela unidade podem ser redistribuídos para unidades remanescentes não danificadas. Por exemplo, se a unidade 120 (da Figura 9) for danificada, o modelo de domínio A pode ser redistribuído para a unidade 126 e o Modelo de Domínio B para a mesma unidade ou para uma unidade diferente. O mesmo modelo de empreendimento pode ser distribuído em diversos chips de placa de forma que quando um chip de placa for danificado, o modelo de empreendimento pode ser redistribuído através de um aprimoramento dos chips de placa remanescentes.

[00193]. Com referência novamente à Figura 9, em outra configuração, o sistema pode ter um modelo de empreendimento à disposição 132 centralmente em uma unidade portátil 130 enquanto as unidades remanescentes 120 - 128 acessam a unidade de processamento central 101 através da web e executam um processamento mínimo ou nenhum processamento quando off-line. Se a unidade de processamento central 101 ficar inutilizável, então, o modelo de empreendimento disponível 132 pode ser ativado no dispositivo portátil 130 ou, se não houver modelo central de empreendimento disponível pré-existente, um modelo de processamento pode ser instalado em outra unidade através de um aprimoramento. Isto permite que o modelo de processamento central seja móvel entre as unidades de hardware de forma a superar o problema de falha da unidade de processamento central.

[00194]. Todo componente de um modelo de domínio de múltiplas placas tem suas próprias informações independentes e passa as mudanças apropriadas (não todas) para o componente preciso do modelo que continuará o processo.

[00195]. Com referência à Figura 11, a resposta à emergência envolve riscos não previstos, causas não previstas, ações corretivas não previstas, suporte detalhado não previsto para os usuários, etc. Para acomodar isto, o modelo do empreendimento permite que a unidade de processamento central (101 na Figura 9) introduza ou remova novos nós do modelo de empreendimento 128 em uma unidade 126 em tempo para utilizar a mudança durante o evento atual. Ela também permite que os nós do modelo de empreendimento mude sua entrada de um ponto de referência existente para outros pontos de referência também em tempo para utilizar a mudança durante o evento atual. A abstração permite que o modelo de empreendimento encontre dados alternativos quando os dados que o sistema configurou para monitorar for insuficiente para as necessidades. Por exemplo, uma necessidade pode ser processar a identificação do pessoal em um formato diferente do previsto. Em outro exemplo, a necessidade de processar modelos eletrônicos especiais de um edifício pode ser possível e relevante se se tornarem disponíveis em uma emergência. Eles seriam acessados pelo mesmo, por exemplo, nós de rota de fuga, mas fariam referência a diferentes dados topográficos. Por exemplo, em caso de emergência em um aeroporto poderia haver uma exigência de um processo de compra que não tenha sido previsto como a introdução de um subcontratado externo para utilizar maquinário especial para limpar resíduos obstrutores, que não tenha sido liberado por segurança. Isto poderia ser semelhante a uma compra de emergência de qualquer fonte externa de pessoal durante uma emergência. O sistema não seria capaz de apresentar os procedimentos corretos e as estimativas do tempo para resposta se não pudesse estabelecer semelhanças entre todos os processos que precisassem de pessoal e equipamento externo levando em consideração diferenças contextuais como qualquer parte do aeroporto o novo pessoal e equipamento precisará acessar. Isto pode se aplicar a qualquer coisa dos primeiros socorros até a priorização em decisões difíceis.

[00196]. Com relação à interconexão de unidades de software (SW) e hardware (HW):

[00197]. O projeto da unidade de HW está diretamente acoplada ao modelo de Sobreposição. Uma unidade de HW que seja estável para atender às exigências de tempo de execução e às limitações de uma condição de emergência deve ser capaz de incorporar todos os módulos de HW necessários a fim de realizar sua carga de trabalho dinâmica a tempo, de acordo com o que o modelo de Sobreposição ditar. Consequentemente, o exemplo apresentado de uma unidade de HW é adaptado às necessidades do modelo de Sobreposição, desde que uma unidade de HW pronta para uso, já disponível, não consiga garantir que as exigências de tempo de execução serão satisfeitas.

[00198]. A unidade computacional do modelo de Sobreposição completa introduz uma nova combinação de HW-SW, que conjuntamente avança os paradigmas de gestão de recursos existentes de sistemas de processamento relevantes que incorporem o estado da técnica. O modelo de Sobreposição oferece uma forma concisa de mapear processos e interações do mundo físico e externo em informações semântica e logicamente interpretáveis por um sistema computadorizado. Desta forma, a lógica de gestão de recursos de tempo de execução de uma unidade computacional de Sobreposição pode tomar decisões com base no estado real dos arredores do sistema físico ou externo, ao invés apenas de situações de modelo pré-codificadas. Por exemplo, no caso de uma emergência, ela pode priorizar a execução de rotinas de propagação de status do nó que sejam de alta prioridade para o incidente, mesmo que seja um sem precedentes. A alta prioridade sendo baseada impulsionada pelo modelo de Sobreposição de proximidade do objetivo do nó inicial em uma propagação até os objetivos de alto nível. Em um caso normal de desenvolvimento de aplicativo da técnica anterior, este evento e as ações relevantes seriam previstas e desenvolvidas pelo projetista do aplicativo no momento do projeto e não se adapta à situação existente utilizando a proximidade do objetivo dos nós que estão para ser processados, o que é diferente em cada instância temporal do estado geral dos modelos de empreendimento.

[00199]. Por meio de exemplo, para uma série de nós de baixa prioridade em uma propagação, o mecanismo de tempo de execução está para executar a série de baixa prioridade de valor e as propagações do estado dos nós iniciais até os nós finais. O software do modelo de Sobreposição comparará dinamicamente a série de nós de baixa prioridade quanto à sua importância comparativa com outros processos na situação atual utilizando a proximidade do objetivo ou meios semelhantes. Então, o software sinalizará o hardware de processamento para executar em uma velocidade inferior à máxima de forma a preservar a energia/eletricidade ou adiar o processamento do tempo de execução de tal trabalho de processamento sem (praticamente) afetar a operação normal. Em outro exemplo, uma reconfiguração importante do nó (empregando a atualização de todo o modelo de Sobreposição ou grande parte dele) deve ser levada em consideração pelo software e considerada como uma operação “pesada" que necessita de toda a potência de processamento disponível. Por este motivo, o software pode sinalizar o hardware a operar em velocidade total e adiar outro processamento menos importante.

[00200]. Em outro exemplo, a proximidade do objetivo de um incremento de propagação do nó pode ser comparado com outros no esquema de trabalhos de processamento a serem executados através de um programa de tempo de execução e processador. Desta forma, o processador pode ser alimentado com trabalhos que tenham alta prioridade para a situação do empreendimento existente e adiar outros de baixa prioridade conforme medido pela proximidade do objetivo. Isto pode auxiliar na gestão do desempenho do processador quando o seu desempenho for limitado. Da mesma forma, a proximidade do objetivo pode ser utilizada na gestão da energia/eletricidade quando esta for limitada. Deve ficar aparente para um leitor com habilidade comum na técnica relacionada que outras combinações e decisões são possíveis, como também levando em consideração a potência da bateria disponível de um dispositivo de processamento portátil, a urgência e/importância de uma operação/evento, etc.

[00201]. As descrições da configuração exemplar acima são simplificadas e não incluem elementos de hardware e software que são utilizados nas configurações, mas não fazem parte da solução inovadora atual, não são necessárias para o entendimento das configurações, e são óbvias para qualquer usuário com habilidade comum na técnica relacionada. Além disso, variações da técnica descrita, da arquitetura do sistema e da arquitetura do software são possíveis onde, por exemplo, etapas da técnica e elementos de hardware e software podem ser reorganizados, omitidos ou novos podem ser adicionados.

[00202]. Várias configurações da invenção são descritas acima na Descrição Detalhada. Muito embora estas descrições descrevam diretamente as configurações acima, entende-se que aqueles com habilidade na técnica podem conceber modificações e/ou variações (como adição, exclusão ou reordenação de etapas do processo, e módulos de software e hardware) nas configurações específicas mostradas e descritas aqui. Estas modificações ou variações que se enquadram no âmbito desta descrição se destinam a ser incluídas nela também. A menos que especificamente observado, é a intenção do inventor que as palavras e frases na especificação e nas reivindicações recebam os significados comuns e habituais para aqueles com habilidade comum na(s) técnica(s) aplicável(is).

[00203]. A descrição mencionada acima tem o propósito de ilustração e descrição. Ela não pretende ser exaustiva ou limitar a invenção para a forma precisa revelada e muitas modificações e variações são possíveis à luz da revelação acima. As configurações foram escolhidas e descritas para permitir que outras pessoas com habilidade na técnica utilizem melhor a invenção em várias configurações e com várias modificações conforme adequado para o uso particular contemplado. Portanto, pretende-se que a invenção não seja limitada às configurações particulares reveladas para realizar esta invenção, mas que a invenção inclua todas as configurações que se enquadrem no escopo das reivindicações anexas.

[00204]. Aqueles com habilidade na técnica entenderiam que os sinais podem ser representados utilizando quaisquer de uma variedade de técnicas diferentes. Por exemplo, dados, software, instruções, sinais que podem ser referenciados ao longo da descrição acima podem ser representados por tensões, correntes, ondas eletromagnéticas, campos ou partículas magnéticas, luz ou quaisquer de suas combinações.

[00205]. Aqueles com habilidade apreciariam ainda que os vários blocos ilustrativos de circuitos de radiofrequência ou analógicos descritos em conexão com a presente revelação podem ser implementados em uma variedade de diferentes topologias de circuito, em um ou mais circuitos integrados, separado ou em combinação com circuitos lógicos e sistemas realizando as mesmas funções descritas na presente revelação.

[00206]. Aqueles com habilidade também apreciariam, ainda, que vários blocos lógicos ilustrativos, módulos, circuitos e etapas algorítmicas descritas em conexão com a presente revelação podem ser implementados como hardware eletrônico, software de computador, ou suas combinações. Para ilustrar claramente esta intercambialidade de hardware e software, vários componentes ilustrativos, blocos, módulos, circuitos e etapas foram descritos acima geralmente em termos de sua funcionalidade. Se tal funcionalidade for implementada como hardware ou software depende da aplicação particular e limitações do projeto impostas no sistema em geral. Artesãos com habilidade podem implementar a funcionalidade descrita de várias maneiras para cada aplicação particular, mas tais decisões de implementação não devem ser interpretadas como causadoras de um desvio do escopo da presente revelação.

[00207]. Os vários blocos lógicos ilustrativos, módulos e circuitos descritos em conexão com a presente revelação podem ser implementados ou realizados com um processador para propósito geral, um processador de sinal digital (DSP), um circuito integrado específico para a aplicação (ASIC), um arranjo de portas programáveis em campo (FPGA) ou outro dispositivo lógico programável, porta discreta ou lógica de transistor, componentes de hardware discretos, ou qualquer combinação deles desenvolvida para realizar as funções descritas aqui. Um processador de propósito geral pode ser um microprocessador, mas na alternativa, o processador pode ser qualquer processador convencional, controlador, microcontrolador ou máquina de estado. Um processador também pode ser implementado como uma combinação de dispositivos computacionais, por exemplo, uma combinação de um DSP e um microprocessador, diversos microprocessadores, um ou mais microprocessadores em conjunto com um núcleo de DSP, ou qualquer outra configuração.

[00208]. Em uma ou mais configurações exemplares, as funções descritas podem ser implementadas no hardware, software, firmware, ou em quaisquer de suas combinações. Se implementadas no software, as funções podem ser armazenadas ou transmitidas como uma ou mais instruções ou código em uma mídia legível por computador. Uma mídia legível por computador inclui tanto a mídia de armazenamento em computador e mídia de comunicação incluindo qualquer mídia que facilite a transferência de um programa de computador de um local para outro. Uma mídia de armazenamento pode ser qualquer mídia disponível que pode ser acessada por um computador. A título de exemplo, e sem limitação, tal mídia legível por computador podem compreender RAM, ROM, EEPROM, CD ROM ou outro armazenamento em disco óptico, armazenamento em disco magnético ou outros dispositivos de armazenamento magnético, ou qualquer outro meio que possa ser utilizado para carregar ou armazenar o código de programa desejado na forma de instruções ou estruturas de dados e que pode ser acessado por um computador ou qualquer outro dispositivo ou aparelho que opere como um computador. Também, qualquer conexão é adequadamente denominada como um meio legível por computador. Por exemplo, se o software for transmitido de um website, servidor, ou de outra fonte remota utilizando um cabo coaxial, cabo óptico de fibra, par trançado, linha digital de assinante (DSL), ou tecnologias sem fio como infravermelho, rádio, e microondas, então, cabo axial, cabo de fibra óptica, par trançado, DSL ou tecnologias sem fio como infravermelho, rádio e microondas estão incluídas na definição de mídia. Disk (disco) e disc (disco), conforme utilizado aqui, inclui disco compacto (CD), disco a laser, disco óptico, disco digital versátil (DVD), disquete e disco de Blu-ray onde os disks geralmente reproduzem dados magneticamente, enquanto os discs reproduzem dados opticamente com lasers. Combinações dos elementos acima também devem ser incluídas dentro do escopo de mídia legível por computador.

[00209]. Um meio de armazenamento exemplar está acoplado ao processador de forma que o processador pode ler informações e escrever informações no meio de armazenamento. Alternativamente, o meio de armazenamento pode ser integrante do processador. O processador e o meio de armazenamento podem residir em um ASIC. O ASIC pode residir em um terminal do usuário. Alternativamente, o processador e o meio de armazenamento podem residir como componentes discretos em um terminal do usuário.

[00210]. A descrição anterior das configurações exemplares reveladas é apresentada para permitir que qualquer pessoa com habilidade na técnica faça ou utilize a presente invenção. Várias modificações nestas configurações exemplares serão prontamente aparentes para aqueles com habilidade na técnica, e os princípios genéricos definidos aqui podem ser aplicados a outras configurações sem fugir do espírito ou escopo da invenção. Dessa forma, a presente invenção não se destina a ser limitada às configurações mostradas aqui, mas pode-se conferir o mais amplo escopo consistente com os princípios e novas características reveladas aqui.

Claims (61)

REIVINDICAÇÕES

1. UNIDADE COMPUTACIONAL DE MÓDULO DE DOMÍNIO caracterizada por um computador de placa simples; uma unidade de processamento central (CPU) (101) em comunicação tanto com um primeiro barramento (110) quanto com um segundo barramento (111), onde toda comunicação entre o primeiro barramento (110) e o segundo barramento (111) seja através da CPU (101); o primeiro barramento (110) em comunicação com diversos módulos internos, os referidos módulos internos incluindo: uma memória de núcleo não volátil (102); uma memória de trabalho não volátil (106); uma memória de acesso aleatório (108); e uma unidade de criptografia / descriptografia (109); e o segundo barramento (111) em comunicação com uma unidade de entrada / saída (I/O) (113) efetivo para se comunicar com dispositivos externos ao computador de placa simples.

2. UNIDADE COMPUTACIONAL DE MÓDULO DE DOMÍNIO de acordo com a reivindicação 1 caracterizada de tal forma que onde a memória de trabalho não volátil (106) inclua um ou mais modelos de domínio (107), cada modelo de domínio (107) incluindo diversos nós (10, 16) ligados juntos por uma ou mais vias, todas convergindo em um ou mais objetivos onde os objetivos de cada modelo de domínio (107) são diferentes.

3. UNIDADE COMPUTACIONAL DE MÓDULO DE DOMÍNIO de acordo com a reivindicação 2 caracterizada de forma que as ligações (12, 18) entre os nós (10, 16) contenham lógica de causa e efeito (14).

4. UNIDADE COMPUTACIONAL DE MÓDULO DE DOMÍNIO de acordo com a reivindicação 3 caracterizada de forma que a memória de núcleo não volátil (102) inclua um micronúcleo (104) e um sistema operacional (103) efetivo para se comunicar (10)5 e instruir um modelo de domínio (107).

5. UNIDADE COMPUTACIONAL DE MÓDULO DE DOMÍNIO de acordo com a reivindicação 4 caracterizada de forma que a unidade de I/O (113) se comunique com um servidor externo.

6. UNIDADE COMPUTACIONAL DE MÓDULO DE DOMÍNIO de acordo com a reivindicação 5 caracterizada de forma que o servidor externo seja eficiente para enviar instruções de aprimoramento / atualização para o núcleo do modelo (104) e para pelo menos um modelo de domínio (107).

7. UNIDADE COMPUTACIONAL DE MÓDULO DE DOMÍNIO de acordo com a reivindicação 6 caracterizada de forma que as instruções de aprimoramento / atualização sejam recebidas em formato criptografado e direcionado para a unidade criptografia / descriptografia (109) para descriptografia.

8. UNIDADE COMPUTACIONAL DE MÓDULO DE DOMÍNIO de acordo com a reivindicação 5 caracterizada de forma que a memória de acesso aleatório (108) seja eficiente para suportar um ou mais módulos de domínio (107) caso a comunicação com dispositivos externos para o computador de placa única seja perdida.

9. SISTEMA CONTENDO UM MODELO DE UM EMPREENDIMENTO caracterizado por: diversas unidades computacionais de domínio (201), cada uma tendo um computador de placa simples (100), uma unidade de processamento central (CPU) (101) em comunicação tanto com um primeiro barramento (110) quanto com um segundo barramento (111), onde toda comunicação entre o primeiro barramento e o segundo barramento seja através da CPU (110), o primeiro barramento (110) em comunicação com diversos módulos internos, os referidos módulos internos incluindo: (a) uma memória de núcleo não volátil (102), (b) uma memória de trabalho não volátil (106), (c) uma memória de acesso aleatório (108) e (d) uma unidade de criptografia / descriptografia (109), e o segundo barramento (111) em comunicação com uma unidade de entrada / saída (I/O) (113) eficiente para se comunicar com dispositivos externos ao computador de placa única; e um terceiro barramento (202) permitindo que as diversas unidades computacionais de domínio (201) se comuniquem umas com as outras. (10).

SISTEMA de acordo com a reivindicação 9 caracterizado de forma que o modelo do empreendimento (198) seja dividido em diversos modelos de domínio que são distribuídos entre as diversas unidades computacionais de domínio (201).

11. SISTEMA de acordo com a reivindicação (10) caracterizado de forma que cada um dos referidos modelos de domínio inclua diversos nós (A1 - A6) ligados juntos por uma ou mais vias, todas convergindo em um ou mais objetivos G.

12. SISTEMA de acordo com a reivindicação 11 caracterizado de forma que o terceiro barramento (202) se comunique (203) com um servidor externo.

13. SISTEMA de acordo com a reivindicação 12 caracterizado de forma que o servidor externo envie instruções criptografadas para uma ou mais das unidades computacionais de domínio (201) e aquelas instruções sejam descriptografadas naquela unidade de criptografia / descriptografia (109) da unidade computacional de domínio. (14).

SISTEMA de acordo com a reivindicação 13 caracterizado de forma que a memória de acesso aleatório (108) de cada unidade computacional de domínio (201) seja eficiente para suportar um ou mais módulos de domínio (107) na unidade computacional de domínio (201) caso a comunicação (203) com o servidor ou com outras unidades computacionais de domínio (201) seja perdida.

15. SISTEMA de acordo com a reivindicação 13 caracterizado de forma que cada computador de placa única (100) esteja contido dentro de um dispositivo diferente.

16. SISTEMA de acordo com a reivindicação 15 caracterizado de forma que os diferentes dispositivos sejam selecionados do grupo que consiste de smartphones, tablets e dispositivos computacionais semelhantes.

17. SISTEMA de acordo com a reivindicação 16 caracterizado de forma que, em caso de emergência, o servidor envie instruções para atualizar a função das unidades computacionais de domínio selecionadas (201) e coordene a função de cada dispositivo.

18. SISTEMA de acordo com a reivindicação 15 caracterizado de forma que o mesmo modelo de domínio (107) esteja localizado em diferentes unidades computacionais de modelo de domínio (100) para oferecer redundância.

19. SISTEMA de acordo com a reivindicação 15 caracterizado de forma que o terceiro barramento (202) seja uma rede de comunicação sem fio.

20. UNIDADE COMPUTACIONAL DE PLACA SIMPLES para executar o código do software modelado em uma forma incorporando dados e instruções de software em um único modelo, a unidade computacional de placa simples caracterizada por: uma unidade de processamento central (101) configurada para processar dados de acordo com pelo menos um modelo de camada de abstração (210), o referido modelo incluindo nós (215) associados com o contexto (217), cada nó (215) sendo conectado a pelo menos outro nó em uma mesma camada de abstração, onde os nós representam o status e o estado dos processos;

uma memória de núcleo não volátil (102) para armazenar e limitar o acesso à unidade de processamento central (101), o referido núcleo (102) apresentando instruções para interpretar pelo menos um modelo de camada de abstração (210) e instruções para sincronizar pelo menos um modelo de camada de abstração (210) com uma versão do modelo armazenada em um dispositivo remoto; uma unidade de criptografia e descriptografia (109) para criptografar e descriptografar dados trocados entre a unidade computacional de placa única (100) e o dispositivo remoto; e uma unidade de gestão de energia (116) configurada para informar a unidade de processamento central (101) do status de energia.

21. UNIDADE COMPUTACIONAL DE PLACA ÚNICA de acordo com a reivindicação 20 caracterizada de forma que a unidade de gestão de energia (116) implemente dinamicamente prioridades de gestão de energia, de forma que estas prioridades sejam um mecanismo de segurança para preservar a capacidade da bateria ou, em casos de capacidade de bateria abaixo de um limite, garantir que a unidade computacional desligará de forma consistente e segura, e onde as prioridades de gestão de energia sejam implementadas de acordo com pelo menos: uma energia disponível remanescente da unidade computacional; uma quantidade de potência de processamento e trabalho necessário para uma operação ou série de operações; e uma prioridade corporativa de operações de processamento pelo processador (101).

22. UNIDADE COMPUTACIONAL DE PLACA ÚNICA de acordo com a reivindicação 21 caracterizada de forma que uma unidade de gestão de desempenho de processamento dinâmico gerencie a priorização do sistema de tempo de execução dinamicamente para oferecer excelente desempenho de processamento do sistema, onde uma unidade de gestão de desempenho de processamento dinâmico mantenha o desempenho de processamento do sistema especialmente em emergências ou uso de alto risco do empreendimento de acordo com pelo menos: uma potência de processamento disponível do processador (101); uma quantidade de potência de processamento e trabalho necessário para uma operação ou série de operações; e uma prioridade corporativa de operações de processamento pelo processador

(101).

23. UNIDADE COMPUTACIONAL DE PLACA ÚNICA de acordo com a reivindicação 22 caracterizada de forma que a prioridade corporativa de operações seja determinada pela proximidade do objetivo G de cada cluster de processamento prospectivo (220, 230) para objetivos baseados na situação do empreendimento existente.

24. UNIDADE COMPUTACIONAL DE PLACA ÚNICA de acordo com a reivindicação 22 caracterizada de forma que a prioridade corporativa de operações seja determinada por uma capacidade de processamento esperada que será dispendida em um cluster de nós prospectivo (220, 230) para ser processada.

25. UNIDADE COMPUTACIONAL DE PLACA ÚNICA de acordo com a reivindicação 21 caracterizada de forma que o modelo único daquela unidade computacional de placa única (100) forme um componente de um modelo corporativo formado pela interconexão da grade de unidades computacionais de placa única interconectadas, o referido modelo corporativo sendo configurado como pelo menos um modelo de camada de abstração (210).

26. UNIDADE COMPUTACIONAL DE PLACA ÚNICA de acordo com a reivindicação 22 caracterizada de forma que a memória de núcleo não volátil (102) inclua implementações de nós (10, 16), ligações (12, 18) e modelos de propagação (14) nas instruções da unidade de processamento central (101) e onde pelo menos um modelo de camada de abstração (210) seja configurado para chamar estas implementações para executar o modelo corporativo.

27. UNIDADE COMPUTACIONAL DE PLACA ÚNICA de acordo com a reivindicação 26 caracterizada de forma que a memória de núcleo não volátil armazene (102) diversos sistemas operacionais com cada sistema operacional associado com uma unidade de processamento central (101) diferente.

28. UNIDADE COMPUTACIONAL DE PLACA ÚNICA de acordo com a reivindicação 26 caracterizada de forma que a memória de trabalho não volátil (106) armazene diversos modelos parciais de abstração de múltiplas camadas (210) e os diversos modelos parciais sejam capazes de serem executados em paralelo.

29. UNIDADE COMPUTACIONAL DE PLACA ÚNICA de acordo com a reivindicação 25 caracterizada de forma que a unidade de processamento central (100) selecione a sequência de nós (225) em uma camada (220) de pelo menos um modelo de camada de abstração (210) para ser executado primeiro com base em um esquema de priorização.

30. UNIDADE COMPUTACIONAL DE PLACA ÚNICA de acordo com a reivindicação 26 caracterizada de forma que a priorização do processamento dinâmico seja baseado em pelo menos: uma potência de processamento disponível do processador (101); uma quantidade de potência de processamento e trabalho necessário para uma operação ou série de operações; e uma prioridade corporativa de operações de processamento pelo processador (101).

31. UNIDADE COMPUTACIONAL DE PLACA ÚNICA de acordo com a reivindicação 30 caracterizada de forma que uma prioridade corporativa de operações de processamento seja determinada pela proximidade do objetivo de cada cluster de processamento prospectivo (A1 - A6) para os objetivos G baseados na situação do empreendimento existente.

32. UNIDADE COMPUTACIONAL DE PLACA ÚNICA de acordo com a reivindicação 30 caracterizada de forma que uma prioridade corporativa de operações de processamento seja determinada por uma capacidade de processamento esperada que será dispendida em um cluster de nós (A1 - A6) prospectivo para ser processada.

33. GRADE DE UNIDADES COMPUTACIONAIS configurada para executar o código do software modelado em uma forma incorporando dados e instruções de software em um único modelo, a grade (198) de unidades computacionais (201) caracterizada por diversas unidades computacionais, onde cada unidade computacional seja caracterizada por: uma unidade de processamento central (101) para processar dados de acordo com pelo menos um modelo de camada de abstração (210), o referido modelo de camada de abstração (210) apresentando nós (215) com parâmetros de status e estado, onde cada nó (215) seja conectado a pelo menos um nó adicional na mesma camada de abstração (210), os nós (215) configurados para propagar para objetivos G de alto nível com parâmetros de status e estado na mesma camada de abstração (210), nós (215) na mesma camada de abstração associados com nós (225), (238) com parâmetros de status e estado do processo em um nível de abstração (220, 230) inferior ou associados com nós (215) definidos pelo contexto em um nível de abstração maior (210); uma memória de núcleo não volátil (102) para armazenar e limitar o acesso somente à unidade de processamento central (101), instruções configuradas para interpretar pelo menos um modelo de camada de abstração (210), e instruções configuradas para sincronizar pelo menos um modelo de camada de abstração (210) com um modelo corporativo armazenado em um dispositivo remoto; uma memória de trabalho não volátil (106) para armazenar pelo menos um modelo de camada de abstração (210); uma memória de acesso aleatório (108) para armazenar dados e instruções no tempo de execução; uma unidade de criptografia e descriptografia (109) para criptografar e descriptografar dados trocados com unidades computacionais externas; uma unidade de entrada-saída (113) para trocar dados com unidades computacionais externas; e uma unidade de gestão de energia (116) para gerenciar a energia e para informar a unidade de processamento central (101) do status de energia.

34. GRADE DE UNIDADES COMPUTACIONAIS de acordo com a reivindicação 33 caracterizada de forma que o núcleo (104) armazenado na memória de núcleo não volátil (102) inclua implementações de nós (10, 16), ligações (12, 18), modelos de propagação (14) e instruções da unidade de processamento central (101), onde pelo menos um modelo de camada de abstração (210) chame estas implementações para executar o modelo.

35. GRADE DE UNIDADES COMPUTACIONAIS de acordo com a reivindicação 34 caracterizada de forma que a memória de núcleo não volátil (102) armazene diversos sistemas operacionais (103), cada sistema operacional (103) associado com uma unidade de processamento central (101) diferente.

36. GRADE DE UNIDADES COMPUTACIONAIS de acordo com a reivindicação 34 caracterizada de forma que a memória de trabalho não volátil (106) armazene diversos modelos parciais de pelo menos uma camada de abstração (210) e onde os diversos modelos parciais sejam executados em paralelo.

37. MÉTODO PARA PROPORCIONAR A RASTREABILIDADE DE PROPAGAÇÃO em um modelo armazenado em uma ou múltiplas bases de dados, caracterizado por: oferecer uma pluralidade de primeiros nós (10), cada um dos referidos nós (10)

apresentando um atributo respectivo e um respectivo estado de parâmetro; e oferecer uma pluralidade de primeiras ligações (12, 18) interconectando a referida pluralidade de primeiros nós (10) em uma fonte para o relacionamento-alvo para formar um primeiro cluster de nós, cada uma das referidas primeiras ligações (12, 18) contendo o código do software (14) efetivo para mudar o respectivo atributo de um nó-alvo 16.

38. MÉTODO de acordo com a reivindicação 37 caracterizado de forma que a pluralidade de primeiros nós (10) recupere respectivo atributo inicial de um local designado pelo nó (10) e seu estado diretamente sem quaisquer outras instruções de localização para recuperar os referidos atributos iniciais.

39. MÉTODO de acordo com a reivindicação 37 caracterizado de forma que as ligações (12, 18) sejam unidirecionais e tanto o atributo do primeiro nó (10) quanto os parâmetros de estado do primeiro nó (10) façam parte do modelo proporcionando, dessa forma, rastreabilidade de propagação, e sejam configurados para serem exibidos na interface de um usuário.

40. MÉTODO de acordo com a reivindicação 39 caracterizado de forma que os primeiros nós (10) tenham uma mudança em seu atributo ou os parâmetros de estado sejam exibidos de forma diferente que os nós de propagação (10) e as ligações (12, 18) exibidas na interface do usuário.

41. MÉTODO de acordo com a reivindicação 38 caracterizado de forma que selecionar um dos primeiros nós (A1, A2, A3, A4) define uma primeira via para um objetivo G.

42. MÉTODO de acordo com a reivindicação 41 caracterizado de forma que selecionar um dos primeiros nós (A1, A5) define uma segunda via para um objetivo G.

43. MÉTODO de acordo com a reivindicação 42 caracterizado de forma que a proximidade do objetivo de um cluster de nós (A1, A2, A3, A4) iniciar a partir de um primeiro nó A4 dependa de um número de estágios de propagação para o objetivo G e um efeito comparativo de propagação do referido nó (A1, A2, A3, A4) para outros nós (A1, A5) propagando para o mesmo objetivo G.

44. MÉTODO de acordo com a reivindicação 43 caracterizado de forma que as primeiras ligações (12, 18) contenham o código de software (14) de causa e efeito.

45. MÉTODO de acordo com a reivindicação 43 caracterizado de forma a fornecer uma pluralidade de segundos nós (A1, A5) que interconectados por uma pluralidade de segundas ligações para formar um segundo cluster de nós onde o segundo cluster de nós está interconectado com o primeiro cluster de nós por pelo menos uma terceira ligação.

46. PRODUTO DE PROGRAMA COMPUTADORIZADO NÃO TEMPORÁRIO que faça com que uma unidade computacional execute o código de software modelado em uma forma incorporando dados e instruções de software em um único modelo, o produto de programa computadorizado não temporário caracterizado por ser configurado para: fazer com que uma unidade de processamento central (101) processe dados de acordo com pelo menos um modelo de camada de abstração (200), o modelo inclui os nós (215) associados com o contexto (217), onde cada nó (215) é conectado a pelo menos um nó adicional na mesma camada de abstração (200) ou a outras camadas de abstração (220, 230), os nós (215) representam o status e o estado do processo, e os nós (215) são utilizados para associar objetivos de nível elevado com diversos níveis de status e estado do processo, e onde pelo menos um modelo de camada de abstração (200) é dividido em pelo menos um primeiro modelo parcial (198) armazenado em uma primeira unidade computacional e um segundo modelo parcial (198) armazenado em uma segunda unidade computacional ou servidor; fazer com que uma memória de núcleo não volátil (102) dê acesso à unidade de processamento central (101) do conteúdo do núcleo (104), onde o conteúdo do núcleo (104) inclui um sistema operacional (103), instruções para interpretar o modelo de abstração de múltiplas camadas, e instruções para sincronizar o modelo de abstração de múltiplas camadas com uma versão do modelo armazenada em um servidor ou em uma unidade computacional terceira; fazer com que uma memória de trabalho não volátil (106) armazene o modelo de abstração de múltiplas camadas (200); fazer com que uma memória de acesso aleatório (108) armazene dados e instruções no tempo de execução; fazer com que uma unidade de criptografia e descriptografia (109) criptografe e descriptografe dados trocados (203) com unidades computacionais externas; fazer com que uma unidade de entrada-saída (113) troque dados com unidades computacionais externas; e fazer com que uma unidade de gestão de energia (116) gerencie a energia e informe a unidade de processamento central (101) do status de energia.

47. PRODUTO DO PROGRAMA COMPUTADORIZADO NÃO TRANSITÓRIO de acordo com a reivindicação 46 caracterizado de forma que a memória de núcleo não volátil (102) inclua implementações de nós (10, 16), ligações (12, 18), e modelos de propagação (14) as instruções da unidade de processamento central (101), e onde pelo menos um modelo de camada de abstração (200) chame estas implementações para executar o modelo (198).

48. PRODUTO DO PROGRAMA COMPUTADORIZADO NÃO TRANSITÓRIO de acordo com a reivindicação 46 caracterizado de forma que a memória de núcleo não volátil (102) armazene diversos sistemas operacionais (103) e cada sistema operacional (103) esteja associado com uma unidade de processamento central (101) diferente.

49. PRODUTO DO PROGRAMA COMPUTADORIZADO NÃO TRANSITÓRIO de acordo com a reivindicação 46 caracterizado de forma que a memória de trabalho não volátil (106) armazene diversos modelos parciais de pelo menos uma camada de abstração (200) e diversos modelos parciais sejam executados em paralelo.

50. PRODUTO DO PROGRAMA COMPUTADORIZADO NÃO TRANSITÓRIO de acordo com a reivindicação 46 caracterizado de forma que a unidade de gestão de energia (116) implemente dinamicamente prioridades de gestão de energia que funcionem como um mecanismo de segurança para preservar a capacidade da bateria ou, em casos de capacidade de bateria abaixo de um limite garantir que a unidade computacional desligará de forma consistente e segura, e onde as prioridades de gestão de energia sejam implementadas de acordo com pelo menos: uma energia disponível remanescente da unidade computacional; uma quantidade de potência de processamento e trabalho necessário para uma operação ou série de operações; e uma prioridade corporativa de operações de processamento pelo processador (101).

51. PRODUTO DO PROGRAMA COMPUTADORIZADO NÃO TRANSITÓRIO de acordo com a reivindicação 46 caracterizado de forma que uma unidade de gestão de desempenho de processamento dinâmico gerencie a priorização do sistema de tempo de execução dinamicamente para oferecer excelente desempenho de processamento do sistema, a unidade de gestão de desempenho de processamento dinâmico mantenha o desempenho de processamento do sistema especialmente em emergências ou uso de alto risco do empreendimento priorizando pelo menos: uma potência de processamento disponível do processador (101); uma quantidade de potência de processamento e trabalho necessário para uma operação ou série de operações; e uma prioridade corporativa de operações de processamento pelo processador (101).

52. PRODUTO DO PROGRAMA COMPUTADORIZADO NÃO TRANSITÓRIO de acordo com a reivindicação 50 caracterizado de forma que uma prioridade corporativa de operações de processamento pelo processador (101) seja determinada pela proximidade do objetivo de cada cluster de processamento prospectivo (A1, A2, A3, A4) para os objetivos G baseados na situação do empreendimento existente.

53. PRODUTO DO PROGRAMA COMPUTADORIZADO NÃO TRANSITÓRIO de acordo com a reivindicação 51 caracterizado de forma que a prioridade corporativa de operações de processamento pelo processador (101) seja determinada pela capacidade de processamento esperada que será dispendida no cluster de nós prospectivo (A1, A2, A3, A4) a serem processados.

54. SISTEMA DE NÍVEL DE ABSTRAÇÃO caracterizado por: uma pluralidade de primeiros nós (238), cada primeiro nó (238) tendo um respectivo atributo e um respectivo estado, e uma pluralidade de primeiras ligações interconectando a referida pluralidade de primeiros nós (238) em uma fonte ao relacionamento-alvo para formar um primeiro cluster de nós, cada uma das referidas primeiras ligações contendo o código do software efetivo para mudar o respectivo atributo de um nó-alvo; uma pluralidade de segundos nós (250), cada um dos referidos segundos nós (250) tendo uma respectivo atributo e um respectivo estado, e uma pluralidade de segundas ligações interconectando a referida pluralidade de segundos nós em uma fonte ao relacionamento-alvo para formar um segundo cluster de nós, cada uma das segundas ligações contendo código de software efetivo para mudar o respectivo atributo de um nó-alvo; e uma ou mais terceiras ligações interconectando o primeiro cluster de nós (238) e o segundo cluster de nós (250) seja em um relacionamento-alvo fonte ou uma associação direta de relacionamento semelhante onde o primeiro cluster de nós (238)

esteja em um nível abstração superior (230) quando comparado com o segundo cluster de nós (250).

55. SISTEMA DE MÚLTIPLOS NÍVEIS de acordo com a reivindicação 54 caracterizado de forma que os clusters de nós (238, 250) sejam orientado pelo objetivo e orientados e executáveis pelo processo.

56. SISTEMA DE MÚLTIPLOS NÍVEIS de acordo com a reivindicação 55 caracterizado de forma que pelo menos um nó do segundo cluster de nós seja interconectado a um primeiro módulo de padrão preditivo (258) que associe aquele nó (250) com um primeiro aplicativo externo.

57. SISTEMA DE MÚLTIPLOS NÍVEIS de acordo com a reivindicação 56 caracterizado de forma que o primeiro aplicativo externo (258) esteja localizado em um dispositivo selecionado do grupo que consiste de um dispositivo computacional desktop, um dispositivo computacional portátil, um dispositivo de Internet das Coisas e um smartphone.

58. SISTEMA DE MÚLTIPLOS NÍVEIS de acordo com a reivindicação 56 caracterizado de forma que um terceiro cluster de nós (260) seja orientado pelo processo e no mesmo nível de abstração do segundo cluster de nós (250).

59. SISTEMA DE MÚLTIPLOS NÍVEIS de acordo com a reivindicação 58 caracterizado de forma que pelo menos um nó (265) do terceiro cluster de nós (260) seja interconectado a um segundo módulo de padrão preditivo (278) que associe aquele nó (265) com um segundo aplicativo externo.

60. SISTEMA DE MÚLTIPLOS NÍVEIS de acordo com a reivindicação 59 caracterizado de forma que o segundo aplicativo externo (278) esteja localizado em um dispositivo selecionado do grupo que consiste de um dispositivo computacional desktop, um dispositivo computacional portátil, um dispositivo de Internet das Coisas e um smartphone.

61. SISTEMA DE MÚLTIPLOS NÍVEIS de acordo com a reivindicação 50 caracterizado de forma que clusters de nós (230) adicionais seja dispostos entre o nível de abstração do primeiro cluster de nós (225) e o nível de abstração do segundo (250) e do terceiro cluster de nós (260) e tenha um nível de abstração intermediário.