BRPI0611726A2 - aparelho para realizar um ciclo de operação útil em um artigo fìsico - Google Patents

aparelho para realizar um ciclo de operação útil em um artigo fìsico Download PDF

Info

Publication number
BRPI0611726A2
BRPI0611726A2 BRPI0611726-0A BRPI0611726A BRPI0611726A2 BR PI0611726 A2 BRPI0611726 A2 BR PI0611726A2 BR PI0611726 A BRPI0611726 A BR PI0611726A BR PI0611726 A2 BRPI0611726 A2 BR PI0611726A2
Authority
BR
Brazil
Prior art keywords
network
message
software
node
event
Prior art date
Application number
BRPI0611726-0A
Other languages
English (en)
Inventor
Matthew P Ebrom
Robert J Feldbruegge
Joshua P Carroll
Judith G Kicklighter
Alexandre S Grosse
David J Kmet
Mark E Glotzbach
Richard A Mccoy
Timothy M Knezic
Patrick J Glotzbach
Daniel M Putnam
Andrew D Whipple
Original Assignee
Whirlpool Co
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Family has litigation
First worldwide family litigation filed litigation Critical https://patents.darts-ip.com/?family=37188949&utm_source=google_patent&utm_medium=platform_link&utm_campaign=public_patent_search&patent=BRPI0611726(A2) "Global patent litigation dataset” by Darts-ip is licensed under a Creative Commons Attribution 4.0 International License.
Application filed by Whirlpool Co filed Critical Whirlpool Co
Publication of BRPI0611726A2 publication Critical patent/BRPI0611726A2/pt

Links

Classifications

    • D—TEXTILES; PAPER
    • D06—TREATMENT OF TEXTILES OR THE LIKE; LAUNDERING; FLEXIBLE MATERIALS NOT OTHERWISE PROVIDED FOR
    • D06F—LAUNDERING, DRYING, IRONING, PRESSING OR FOLDING TEXTILE ARTICLES
    • D06F34/00—Details of control systems for washing machines, washer-dryers or laundry dryers
    • D06F34/04—Signal transfer or data transmission arrangements
    • G—PHYSICS
    • G04—HOROLOGY
    • G04G—ELECTRONIC TIME-PIECES
    • G04G7/00—Synchronisation
    • G04G7/02—Synchronisation by radio
    • G—PHYSICS
    • G04—HOROLOGY
    • G04R—RADIO-CONTROLLED TIME-PIECES
    • G04R20/00—Setting the time according to the time information carried or implied by the radio signal
    • G04R20/26—Setting the time according to the time information carried or implied by the radio signal the radio signal being a near-field communication signal
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3466—Performance evaluation by tracing or monitoring
    • G06F11/3495—Performance evaluation by tracing or monitoring for systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2803—Home automation networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2803—Home automation networks
    • H04L12/2807—Exchanging configuration information on appliance services in a home automation network
    • H04L12/2814—Exchanging control software or macros for controlling appliance services in a home automation network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2803—Home automation networks
    • H04L12/2816—Controlling appliance services of a home automation network by calling their functionalities
    • H04L12/2818—Controlling appliance services of a home automation network by calling their functionalities from a device located outside both the home and the home network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2803—Home automation networks
    • H04L12/2816—Controlling appliance services of a home automation network by calling their functionalities
    • H04L12/282—Controlling appliance services of a home automation network by calling their functionalities based on user interaction within the home
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2803—Home automation networks
    • H04L12/2823—Reporting information sensed by appliance or service execution status of appliance services in a home automation network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2803—Home automation networks
    • H04L12/2823—Reporting information sensed by appliance or service execution status of appliance services in a home automation network
    • H04L12/2825—Reporting to a device located outside the home and the home network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2803—Home automation networks
    • H04L12/2823—Reporting information sensed by appliance or service execution status of appliance services in a home automation network
    • H04L12/2827—Reporting to a device within the home network; wherein the reception of the information reported automatically triggers the execution of a home appliance functionality
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2803—Home automation networks
    • H04L12/283—Processing of data at an internetworking point of a home automation network
    • H04L12/2832—Interconnection of the control functionalities between home networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/105—Multiple levels of security
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • H—ELECTRICITY
    • H05—ELECTRIC TECHNIQUES NOT OTHERWISE PROVIDED FOR
    • H05B—ELECTRIC HEATING; ELECTRIC LIGHT SOURCES NOT OTHERWISE PROVIDED FOR; CIRCUIT ARRANGEMENTS FOR ELECTRIC LIGHT SOURCES, IN GENERAL
    • H05B6/00—Heating by electric, magnetic or electromagnetic fields
    • H05B6/64—Heating using microwaves
    • H05B6/66—Circuits
    • H05B6/68—Circuits for monitoring or control
    • H05B6/688—Circuits for monitoring or control for thawing
    • A—HUMAN NECESSITIES
    • A47—FURNITURE; DOMESTIC ARTICLES OR APPLIANCES; COFFEE MILLS; SPICE MILLS; SUCTION CLEANERS IN GENERAL
    • A47L—DOMESTIC WASHING OR CLEANING; SUCTION CLEANERS IN GENERAL
    • A47L15/00—Washing or rinsing machines for crockery or tableware
    • A47L15/0018—Controlling processes, i.e. processes to control the operation of the machine characterised by the purpose or target of the control
    • A47L15/0063—Controlling processes, i.e. processes to control the operation of the machine characterised by the purpose or target of the control using remote monitoring or controlling of the dishwasher operation, e.g. networking systems
    • D—TEXTILES; PAPER
    • D06—TREATMENT OF TEXTILES OR THE LIKE; LAUNDERING; FLEXIBLE MATERIALS NOT OTHERWISE PROVIDED FOR
    • D06F—LAUNDERING, DRYING, IRONING, PRESSING OR FOLDING TEXTILE ARTICLES
    • D06F34/00—Details of control systems for washing machines, washer-dryers or laundry dryers
    • D06F34/28—Arrangements for program selection, e.g. control panels therefor; Arrangements for indicating program parameters, e.g. the selected program or its progress
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2803—Home automation networks
    • H04L12/2807—Exchanging configuration information on appliance services in a home automation network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2803—Home automation networks
    • H04L2012/2847—Home automation networks characterised by the type of home appliance used
    • H04L2012/285—Generic home appliances, e.g. refrigerators
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/26—Special purpose or proprietary protocols or architectures
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02B—CLIMATE CHANGE MITIGATION TECHNOLOGIES RELATED TO BUILDINGS, e.g. HOUSING, HOUSE APPLIANCES OR RELATED END-USER APPLICATIONS
    • Y02B40/00—Technologies aiming at improving the efficiency of home appliances, e.g. induction cooking or efficient technologies for refrigerators, freezers or dish washers
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management

Landscapes

  • Engineering & Computer Science (AREA)
  • Automation & Control Theory (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Strategic Management (AREA)
  • Economics (AREA)
  • Human Resources & Organizations (AREA)
  • Computer Security & Cryptography (AREA)
  • Quality & Reliability (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • Game Theory and Decision Science (AREA)
  • Educational Administration (AREA)
  • Development Economics (AREA)
  • Marketing (AREA)
  • Operations Research (AREA)
  • Human Computer Interaction (AREA)
  • Tourism & Hospitality (AREA)
  • General Business, Economics & Management (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Health & Medical Sciences (AREA)
  • Textile Engineering (AREA)
  • Electromagnetism (AREA)
  • Computer And Data Communications (AREA)
  • Selective Calling Equipment (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Telephonic Communication Services (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Small-Scale Networks (AREA)
  • Cookers (AREA)

Abstract

APARELHO PARA REALIZAR UM CICLO DE OPERAçãO úTIL EM UM ARTIGO FìSICO. A invenção se refere a uma arquitetura de sofi'ware que é implementada e se comunica através de uma rede de comunicação interna em um aparelho, que conecta os vários componentes fisicos do aparelho. A arquitetura de software desempenha múltiplas funções: identificação de cada um dos componentes correspondentes a um nó de rede; identificação das capacidades dos componentes; identificação do estado dos componentes; fornecimento de interfaces de comando bem definidas; e fornecimento de comunicação entre componentes de software internos e externos. Dessa maneira, as funções de SA informam todos os nós na rede da presença, capacidades e estado dos outros nós.

Description

"APARELHO PARA REALIZAR UM CICLO DE OPERAÇÃO ÚTIL EMUM ARTIGO FÍSICO"
REFERÊNCIA A PEDIDO RELACIONADO
O presente pedido reivindica o benefício dePedido de Patente dos Estados Unidos No. 60/595.148, depositadoem 9 de junho de 2005, cuja exposição é incorporada através dereferência.
FUNDAMENTOS DA INVENÇÃO
Campo da Invenção
A invenção se refere a uma arquitetura de software, incluindouma ou mais interfaces de programação de aplicativo que permitemcomunicação com, e gerenciamento de, pelo menos um componente dentro deum aparelho eletrodoméstico.
Descrição da Técnica Relacionada
Aparelhos eletrodomésticos são compreendidos,tipicamente, de um ou mais componentes que causam as operaçõeseletromecânicas, eletrotérmicas e eletroquímicas do aparelho. Porexemplo, um forno pode incluir um componente de gerenciamento deaparelho, tendo um painel de circuito impresso (PCB) com memória,bem como um componente de interface de usuário, tal como um painelde controle ou teclado numérico para um usuário emitir comando para oaparelho de forno. Os modelos básicos de aparelhos, tipicamente, sãodifíceis de desenhar, desenvolver, testar, diagnosticar, controlar edepurar, devido à diversidade de componentes e à diversidade deescolhas de implementação. Essa diversidade é um impedimento àcriação de componentes inter-operáveis, reutilizáveis, de valoradicionado.
Tem se tornado conhecido, em anos recentes, interligar oscomponentes de um aparelho por meio de uma rede de comunicações interna,capaz de enviar e receber mensagens de controle para controlar a interaçãoentre os componentes internos de um aparelho, conforme oposto ao uso deuma pluralidade de circuitos distintos, com cada circuito distinto responsávelpor uma comunicação individual entre componentes relacionados eimplementados por cinta de fios ou outros conectores ou chicotes entre oscomponentes.
Essa rede interna proporciona um grau de universalidade naconexão dos componentes internos ao aparelho, contudo, cada componenteprecisa, tipicamente, ser capacitado com software dentro de seumicroprocessador e do circuito de hardware adjacente, para obter participaçãoem rede. Um exemplo dessa rede interna usada dentro de um aparelhoeletrodoméstico é o protocolo de rede WIDE, criado por Whirlpool, Inc., acessionária deste documento.
SUMÁRIO DA INVENÇÃO
A invenção se refere a uma arquitetura de software que éimplementada e se comunica através de uma rede de comunicação interna emum aparelho, que conecta os vários componentes físicos do aparelho. Aarquitetura de software desempenha múltiplas funções: identificar cada umdos componentes correspondentes a um nó para a rede; identificar ascapacidades ou funções dos componentes identificados para a rede; identificaro estado dos componentes para a rede, proporcionar interfaces de comandobem definidas para cada componente, proporcionar comunicação entrecomponentes de software internos e externos, que não são parte da SA; efornecimento de comunicação entre componentes de software não-SA emdiferentes componentes físicos. Dessa maneira, as funções de SA informam atodos os nós na rede da presente, capacidades e estado dos outros nós epermite que as funções dos nós enviem e recebam mensagens de comandoentre si.
BREVE DESCRIÇÃO DOS DESENHOS
A figura 1 é uma ilustração esquemática mostrando umaparelho eletrodoméstico tendo uma rede de comunicação interna,interconectando uma pluralidade de componentes, em que cada componentetem uma arquitetura de software nele embutida, de acordo com a invenção, oaparelho eletrodoméstico tendo, também, uma conexão de comunicaçãoexterna mostrando vários cartões de interface de rede (NICs)5 estabelecendocomunicação com várias modalidades de clientes externos.
A figura 2 é uma ilustração esquemática da rede decomunicação interna da figura 1, mostrando a arquitetura de software (SA) deacordo com a invenção interposta entre a rede de comunicação interna evários componentes de software internos ao aparelho eletrodoméstico.
A figura 3 é uma ilustração esquemática da rede decomunicação interna da figura 1, mostrando a rede de comunicação internafuncionando como um suporte físico para a SA residente em doiscomponentes (uma Camada Inferior, que representa a camada física de rede enão está diretamente associada com a SA e uma Camada Superior, querepresenta suporte para estrutura de pacotes e é, diretamente, um elemento daSA), com a SA usada pelos componentes para se comunicar através de trocade informação e interagir com outras camadas de operação de saída elétrica,residindo nos componentes, para obter os resultados de acordo com ainformação trocada entre componentes de acordo com a invenção.
A figura 4 é uma ilustração esquemática de uma estrutura depacotes para a rede de comunicação interna do aparelho eletrodoméstico,mostrado na figura 1, tendo uma porção de carga útil, compreendendo umaestrutura de pacotes de aplicação para a arquitetura de software de acordocom a invenção.
A figura 5 é uma ilustração esquemática de comunicação entreuma SA residente em um controlador, SA de controlador, do aparelho e umaSA residente em um componente para criar uma relação de cliente, SA decliente, em relação à SA no controlador, onde diversas variáveis e eventos sãotransmitidos entre a SA de controlador e a SA de cliente.
A figura 5 A é uma ilustração esquemática, similar à figura 5 eilustrando o cliente como um cliente externo em uma localização remota naforma de um centro de suporte de chamadas do consumidor para ilustrar umatroca de dados usada para realizar diagnose remota do aparelho.
A figura 6 é uma ilustração esquemática similar àquelamostrada na figura 5, ilustrando uma técnica de descoberta contida naarquitetura de software da figura 1, de acordo com a invenção.
A figura 7 é uma ilustração esquemática de vários estadosexemplificativos de um ambiente de alteração de software operando,tipicamente, dentro do elemento de Lógica de Controle, conforme mostradona figura 3 dentro de um componente de um aparelho eletrodoméstico, queestá ilustrado como uma lava - louças.
A figura 8 é uma ilustração esquemática mostrando a respostada SA de controlador à várias trocas de informação na forma de comandosemitidos e recebidos por outras instalações de SA para validar ou rejeitaraqueles comandos, com base no estado do aparelho eletrodoméstico, bemcomo no estado interno da SA de controlador.
A figura 9 é uma vista esquemática, ilustrando o uso deligação para ligar múltiplas trocas de dados a fim de formar um comandoúnico e/ou atualização entre SA de cliente e o SA de controlador.
A figura 10 é uma ilustração esquemática mostrando a SA emrelação ao ambiente de software global de um componente, onde o ambientede software compreende várias camadas de operação de software, com aarquitetura de software compreendendo um manipulador de comando, ummanipulador de atualização e uma interface de camada de rede decomunicação interna para interconectar a SA à rede de comunicação internado aparelho eletrodoméstico.
A figura 11 é uma ilustração esquemática mostrando ainvocação do SA de controlador pelo planejador supervisor (MAIN)5residente no controlador principal, que também invoca uma chamada de sub-rotina para expor funções da SA de cliente na rede.
A figura 12 é uma ilustração esquemática mostrando ainterface entre a lógica interna de aplicação de aparelho e a arquitetura desoftware mostrada na figura 11, incluindo uma seção de chamada de volta.
A figura 13 é uma ilustração esquemática de implementaçãode exemplo da arquitetura de software mostrada na figura 11, incluindo umaseção de inicialização de aparelho.
A figura 14 é uma ilustração esquemática de um par deambientes operacionais de software, cada um correspondendo a umcomponente diferente com sua própria SA e conectados pela rede decomunicação interna.
A figura 15 é uma ilustração esquemática de um nó depersistência exposto aos outros componentes dentro do Aparelho de Parrot viarede 14 e estrutura de pacotes de suporte 28 da arquitetura de software 10 dafigura 1, de acordo com a invenção.
A figura 16 é uma ilustração esquemática de um método datécnica anterior, pelo qual, comandos externos são traduzidos emcompressões de tecla para testar a funcionalidade do aparelhoeletrodoméstico.
A figura 17 é uma ilustração esquemática da interação decompressões de tecla iniciadas pelo usuário e comandos de softwarealimentados externamente são passados como argumentos para a SA para aemissão de comandos para um aparelho eletrodoméstico, por exemplo, paratestar a funcionalidade do aparelho eletrodoméstico e/ou mudar o estado damáquina do aparelho eletrodoméstico.
A figura 18 é uma ilustração esquemática mostrando amontagem de um NIC em uma reentrância formada em um lado posterior doaparelho.
A figura 19 é uma ilustração esquemática mostrando amontagem do NIC em um lado frontal do aparelho e um conduto de fiaçãoestendendo-se da localização de montagem do cartão de interface de rede parao lado posterior do aparelho.
A figura 20 é uma ilustração esquemática do aparelhocompreendendo uma barreira de segurança que permite a comunicação de umRF - PCB localizado no aparelho e impede o contato humano com calor e/oueletricidade excessiva.
A figura 21 é uma ilustração esquemática ilustrando o uso deum modo de serviço que obtém dados de diagnóstico do aparelho e carregaros dados de diagnóstico via um computador pessoal através de uma redeexterna.
A figura 21A é uma ilustração esquemática de arquitetura parao módulo de serviço da figura 21.
A figura 22 é uma ilustração esquemática similar à figura 21com o módulo de serviço carregando os dados de diagnósticos via uma linhatelefônica.
A figura 22A é uma ilustração esquemática de arquitetura parao módulo de serviço da figura 22.
A figura 23 é uma ilustração esquemática do aparelho naforma de um refrigerador equipado com um módulo acessório exemplificativona forma de um módulo de estação de tempo, formando um componente comum SA de cliente, permitindo que o módulo de estação de tempo se torneoperacional sem configuração manual.
A figura 24 é uma ilustração esquemática de uma estrutura depacotes de fragmentação para a rede de comunicação interna do aparelhoeletrodoméstico mostrado figura 1, tendo protocolo para manipulação deintegridade de pacote fragmentada, que substitui o protocolo ilustrado nafigura 4, quando uma mensagem deve ser partida em múltiplas mensagens.
A figura 25 ilustra uma seqüência de pacotes, representandouma série de mensagens fragmentadas transmitidas na forma mostrada nafigura 2, que são pela SA de recebimento e reformadas nos conjuntos dedados coerentes originais criados pelo remetente dos pacotes.
A figura 26A é uma ilustração esquemática da localização deinformação de mapa variável em uma localização central, tal como placa dePC de controlador principal, que é, então, comunicada com as placas dosoutros componentes.
A figura 26B é uma ilustração esquemática da localização deinformação de mapa variável no controlador do componente, que é coletadados outros componentes na rede.
A figura 27 é um diagrama de seqüência de UML, mostrandoum cenário de mensagens, onde uma solicitação de evento em duplicata éatribuída a um endereço variável a fim de permitir que ambas as solicitaçõesresidam na rede.
A figura 28 é um diagrama em seqüência de UML de umformato padrão, ilustrando a desativação e a reativação das solicitações deeventos de realização.
A figura 29 é um diagrama em seqüência de UML de umevento reconhecido dentro da SA, onde a SA de controlador aguarda umtempo pré-determinado por uma mensagem de reconhecimento da SA decliente até processamento do evento seguinte.
A figura 30 é um diagrama de estado de UML de um formatopadrão ilustrando os modos de segurança e barreiras de proteçãoproporcionadas pela presente invenção.
A figura 31 é um diagrama em seqüência de UML ilustrandoos métodos de interação entre um cliente que deve negociar com barreira deproteção da figura 30 antes que as mensagens da aplicação possam sercompletamente processadas.
A figura 32 é um diagrama de classes de UML ilustrando asinterfaces públicas padrão que a SA é capaz de implementar.
A figura 33 é um diagrama de classes de UML ilustrando aimplementação preferida da SA.
A figura 34 mostra a organização preferida de arquivos decódigo fonte da AS.
A figura 35 mostra uma compilação de diagramas de estado deUML inter-relacionados, ilustrando 3 estados primários (COMM_IDLE,COMM_EXPECTING_ACK, e COMM_PENDING), cada um dos quais,possivelmente, tendo uma pluralidade de sub-estados.
A figura 36 mostra uma compilação de diagramas de estadosde UML inter-relacionados, ilustrando 4 estados primários (READY,TRANSMIT SNAPSHOT, UPDATESJBLOCKED, ePROCES S_DAQ_EVENTS).
A figura 37 mostra uma compilação de diagramas de estadosde UML inter-relacionados, ilustrando 2 estados primários (MSG_READY eMSGJPROCESS).
A figura 38 é um diagrama de seqüência de UML5 ilustrando aexecução de uma compilação ordenada de mensagens internas entrecomponentes com a finalidade de produzir uma mensagem de rede da redeinterna de SA.
A figura 39 é um diagrama em seqüência de UML, ilustrandoa execução de uma compilação ordenada de mensagens das classes na figura33 do ambiente operacional de software.
A figura 40 é um diagrama de seqüência de UML mostrandouma compilação ordenada de mensagens das classes na figura 33 do ambienteoperacional de software.
A figura 41 é um diagrama de seqüência de UML ilustrado asmensagens requeridas para processar mensagens que entram do barramentoWIDE 14 dos clientes 22/16 que não requerem uma resposta contendo outrosdados significativos que não uma resposta transmitindo o sucesso ou a razãode falha da mensagem que entra (o ACK ou NAK de APIID = 1, Op Code = 1).
A figura 42 é um diagrama em seqüência de UML ilustrandoas mensagens requeridas para processar mensagens que entram de umbarramento de WIDE 14 dos clientes 22/16 que requerem uma pluralidade desucesso ou a razão de falha da mensagem que entra (o ACK ou NAK de APIID=I5OpCode=I).
A figura 43 é um diagrama em seqüência de UML ilustrandoas mensagens requeridas para processar as mensagens que entram dobarramento de WIDE 14 de clientes 22/16 que requerem mensagens deresposta única, contendo dados significativos em adição a uma resposta quetransmite o sucesso ou a razão para falha da mensagem que entra (o ACK ouNAK de APIID = 1, Op Code = 1).
A figura 44 ilustra, esquematicamente, um controle detaxonomia usando um conjunto de dados de taxonomia para controlar aalteração de um ou mais componentes do aparelho sem conhecimento diretodas funções para o componente.
A figura 45 ilustra, esquematicamente, uma interface deusuário povoada por um conjunto de dados de taxonomia, compreendendouma hierarquia de opções e entradas de dados que levarão o usuário aselecionar opções e entradas de dados para gerar um comando bem formado.
A figura 46 ilustra, esquematicamente, as entradas de dadosassociados disponíveis para uma opção de nível superior.
A figura 47 ilustra, esquematicamente, as entradas de dadosassociados disponíveis para uma seleção de opção de sub-nível com entradasde dados associadas.
DESCRIÇÃO DE MODALIDADES DA INVENÇÃO
Uma breve visão geral será útil antes do exame dos múltiplosaspectos da invenção. A invenção se refere a uma arquitetura desoftware^'SA") que é implementada e se comunica através de uma rede decomunicação interna em um aparelho, que conecta os vários componentesfísicos do aparelho.
Alguns dos componentes físicos têm um controladorcorrespondente (controlador principal, um controlador de motor, umainterface de usuário, etc.), que pode ser um simples microprocessadormontado em um painel de circuito impresso. Outros componentes não têmcontrolador. Tipicamente, os componentes que têm controladores (e, sehouver mais de um, são, tipicamente, também capacitados para a rede)cooperam através de mensagens na rede ou outras formas de transmissão dedados para, direta ou indiretamente, através de outros componentes, controlaralteração de todos os componentes e seus dispositivos contidos ou anexadospara implementar uma operação ou ciclo para o aparelho.
A SA pode, mas não tem que, residir em cada um doscomponentes com um controlador. Aqueles componentes com a SA ou umavariante da SA compatível com a SA (compatibilidade determinada pelacapacidade para enviar, receber e processar pacotes) formam um nó na redeque pode se comunicar com os outros nós.
A SA desempenha múltiplas funções: identifica cada um doscomponentes correspondente a um nó para a rede; identifica as capacidadesou funções dos componentes identificados para a rede; identifica o estado doscomponentes para a rede; proporciona interfaces de comando bem definidaspara cada componente; proporciona comunicação entre componentes desoftware internos e externos que não são parte da SA; e proporcionacomunicação entre componentes de software não SA em diferentescomponentes físicos. Dessa maneira, as funções de SA para informar todos osnós na rede da presença, capacidades e estado dos outros nós.
A SA compreende múltiplos módulos, cada um dos quais temfuncionalidades diferentes. Várias combinações dos módulos ou todos osmódulos podem residir em cada um dos componentes. Um módulo tendo afuncionalidade básica ou de núcleo para a invenção reside em todos oscomponentes. Em uma configuração antecipada, todos os módulos residempelo menos no controlador principal, que estabelece o controlador principalpara funcionar como uma SA primária ou do controlador, com os outros nósfuncionando em uma relação de cliente para a SA de controlador. Nessaconfiguração, todos os nós se comunicarão através da SA de controlador.
A SA é suficientemente forte de modo que ela pode permitirconfigurações sem uma SA de controlador ou com múltiplas SA decontrolador. Independente da configuração, qualquer componente com umaSA residente pode funcionar como um cliente com relação aos outroscomponentes.
As comunicações internas podem ser conectadas a um ou maiscomponentes externos diretamente ou através de uma rede externa. Ocomponente externo terá, também um, alguns ou todos os módulos de SAresidentes.
Começando com a figura 1, a parte específica da invenção seráagora descrita. A figura 1 é uma vista esquemática, ilustrando um ambiente deuma arquitetura de software 10 (concretizando os sistemas e métodos aquidescritos e aqueles que serão evidentes para alguém habilitado na técnica), naforma de um aparelho eletrodoméstico 12, tendo uma rede de comunicaçãointerna 14, interconectando uma pluralidade de componentes 16, em que aarquitetura de software 10 reside em pelo menos um componente 16 paraativar o componente 16 e> de preferência, cada componente adicional 16 tenhaarquitetura de software 10 residente, ou uma alternativa capaz de ser inter-operável com ele. O aparelho eletrodoméstico 12 também tem uma conexãode comunicação interna - externa 18, mostrada inter-conectada com váriosdispositivos de interface de rede 20 para comunicação com as váriasmodalidades de um cliente externo 22.
Os clientes externos, tipicamente, compreenderão hardware esoftware de computação e hardware e software de rede, capazes de interagircom a arquitetura de software. Isso pode ser alcançado pela inclusão de todasou de uma porção da arquitetura de software 10 dentro da modalidade docliente externo ou uma alternativa para a arquitetura de software 10, que écapaz de se comunicar e interagir, completa ou parcialmente, com arquiteturade software 10. Um número de componentes alternativos (C dll, Visual BasicDriver, Java Driver, e Active X Driver) capazes de interagir completamentecom a arquitetura de software 10 têm sido implementados.
Em conexão com o texto deste pedido de patente e na análisedos desenhos que acompanham o texto deste pedido, será compreendido que"SA" se refere à "arquitetura de software", conforme descrito pelo numerai dereferência 10 neste pedido.
Ainda, o termo "cliente" é usado para se referir a umcomponente em que toda ou uma parte da SA reside ou que capacita completaou parcialmente a funcionalidade do componente. O componente pode ser umcomponente interno ou externo. Embora o cliente seja usado principalmentepara descrever um componente capacitado pela SA, o cliente também é usadopara descrever um componente que é capacitado por um software alternativo,que é capaz de trocar mensagens com sucesso na rede de comunicação interna14 e se comunicar com a SA. De um modo geral, é usado quando se referindoaos aspectos do software e não aos aspectos do hardware do nó.
Os componentes 16 podem compreender um ou maisdispositivos. Desse modo, o termo "dispositivos", conforme usado no pedido,pode se referir a um componente ou a um dispositivo. Os dispositivos podemser quaisquer componentes eletrônicos, eletrotérmicos e eletromecânicos, queformam, coletivamente, o componente ou que são presos a um componentecom um controlador via circuito elétrico (por exemplo, chicote de fios)quepode lógica e uma parte física que tem memória.
Como aqui descrito, o aparelho 12 pode ser qualquer um deuma variedade bem conhecida de aparelhos que serão bem conhecidos paraalguém habilitado na técnica. Por exemplo, o aparelho 12 pode ser um lava -louças, um secador, um microondas, uma lava - louças, um refrigerador, umacombinação de refrigerador / freezer, um freezer independente, uma gaveta deaquecimento, uma gaveta refrigerada, um forno, uma combinação de cooktope forno, um cooktop e semelhantes. Embora o ambiente descrito da invençãoseja aquele de um aparelho, a invenção tem aplicabilidade a qualquer tipo demáquina tendo componentes em rede.
Como aqui descrito, a rede de comunicação interna 14 podeser qualquer conduto de interconexão bem conhecido, fiação e/ ou chicote defios ou sistema sem fio adequado para interconexão dos vários componentesinternos 16 de um aparelho eletrodoméstico 12. Conforme descrito na seçãoantecedentes deste pedido, a rede WIDE é uma rede de comunicação internaadequada 14 para proporcionar a comunicação interna necessária parasuportar a arquitetura de software 10 de acordo com a invenção. Será evidentepara alguém habilitado na técnica que a arquitetura de software 10 podefuncionar em qualquer rede interna adequada e que o exemplo ilustrativo aquiproporcionado (isto é, a rede WIDE) é simplesmente um exemplo de umarede de comunicação interna 14 adequada.
Como previamente mencionado, o componente 16 é qualquercomponente baseado em processador ou sub-componente de um aparelhoeletrodoméstico 12. Exemplos de componentes 16 adequados pararecebimento e instalação a arquitetura de software 10 de acordo com ainvenção incluem, mas não estão limitados aos mesmos, microprocessadoresde controle de motor, controladores de teclado numérico ativados pormicroprocessador, controladores de interface de usuário de LCD e outroscontroles de dispositivos incluídos, tipicamente, dentro de um aparelhoeletrodoméstico 12.
O conector ou ranhura de interface interno/ externo 18 éadequado para conectar um aplicação de tipos de dispositivos 20, que sãocapazes de comunicação na rede de comunicação interna 14 e pelo menosuma outra rede, tal como RS-232 serial, várias formas de sem fio (Zigbee,Wi-Fi, etc.), USB ou Ethernet cabeada, etc. A funcionalidade do dispositivo20 pode estar limitada, estritamente, ao protocolo e conversão de camadafísica ou pode ser expandida para suportar serviços adicionados de valor emadição a sua função de conexão em ponte de protocolo.
Exemplos de clientes externos 22 aos quais a arquitetura desoftware 10 permite que um aparelho eletrodoméstico 12 seja conectado,incluem, mas não estão limitados aos mesmos, um desenvolvimento decontrole baseado em computador pessoal, uma aplicação para testagem emfábrica, uma aplicação de diagnóstico, uma aplicação para teste de campo euma interface para um ambiente local conectado. Essa conexão ao ambienteexterno, quer adjacente ou remoto do aparelho 12, permite aplicaçõesadicionadas de valor para comunicação com o aparelho 12. Alguns exemplossão:
• Teste de fábrica automatizado
• Aplicações de Gerenciamento de Energia
• Ferramentas de desenvolvimento de engenharia
• Ferramenta para Diagnóstico e Serviço de Aparelho
• Testagem para Verificação Funcional de Fabricação de Controle Eletrônico
• Aplicações do Consumidor ... etc.
A arquitetura de nível de sistema (elementos mecânicos,elétricos e de software participando para alcançar uma finalidade útil doaparelho eletrodoméstico) inclui arquitetura de software 10 e elementos desoftware à parte da arquitetura de software 10. A compilação de elementos desoftware, incluindo, mas não limitado a mesma, a arquitetura de software 10,dentro do microprocessador de um componente da arquitetura do sistema éaqui referida como um ambiente operacional de software 16A. A arquiteturade software 10 é compreendida de três componentes: uma implementação denúcleo, uma definição de protocolo de aplicação, um ou mais interfaces deprograma de aplicação (aqui referidas como "API" ou "APIs" no plural).Implementação de Núcleo
A implementação de núcleo da arquitetura de software 10 éuma compilação de módulos de software (exemplos encontrados na figura 3são SACore, SADiscovery, SADAK, SAPortMemory, SAPollVariable),executando em um micro processador de controle de aparelho. Conformemostrado na figura 11, a implementação de núcleo é executada, depreferência, no laço MAIN do microprocessador de controle de aparelho, oque será evidente para alguém habilitado na técnica. O núcleo proporcionauma camada comum de mensagens de aplicação através da rede decomunicação interna 14 e está baseado em um desenho flexível, permitindo odesenvolvimento de aplicações de conectividade de plataforma cruzada.
Como parte da implementação de núcleo, uma API de núcleo existirá, a qualserá uniformemente implementada em cada aparelho. Além disso, ondeimplementação uniforme não é prática, um mecanismo de descoberta pode serusado, permitindo adaptação pelo cliente à não uniformidade.
Definição de Protocolo de Aplicação
Um protocolo é um procedimento padrão para regulartransmissão de dados entre nós em uma rede. As mensagens são enviadasatravés da rede de comunicação interna em um ou mais pacotes de dados, quesão então montadas para formar uma mensagem comunicada. Há duas áreasaplicáveis de definição em relação à arquitetura de software 10.
1. Definição de Pacote: é o significado pré-definido para cadabyte dentro de uma compilação de bytes que formam o pacote ou bits oufaixas de bits dentro de um daqueles bytes existentes. A figura 4 e a figura 24e sua descrição anexa representam a Definição de Pacotes da arquitetura desoftware 10.
2. Ordem de Mensagens e Regras de Mensagens: a definiçãode um Protocolo é, em geral, expandida além da definição de pacote (1) acimapara incluir regras que governam as coleções ordenadas esperadas demensagens necessárias para realizar certas transações úteis. Exemplos deMensagens Ordenadas com Regras de Mensagens (transações) são mostradosnas figuras 6, 9, 27, 29 e 31.
Interfaces de Programação de Aplicativo
Uma API é um contrato de comunicação e mensagens queespecifica como um nós de rede se comunica com o outro. Isso é realizadopela definição das chamadas de função disponíveis, os argumentos para cadachamada de função, o tipo de dados de cada argumento e, em alguns casos, osvalores válidos de cada argumento.
Em muitos casos, as APIs são específicas para uma aplicaçãoou aparelho 12 e, portanto, não são consideradas como parte da compilação dearquitetura de software 10 de APIs de Núcleo (padrão ajustado de); o núcleoda das 10 permite e expõe múltiplas APFs para o cliente 16, 22 e,possivelmente, 20.
Arquitetura de Nível - Sistema
A arquitetura de software 10 foi projetada para alcançardiversos objetivos através do tempo.
1. Produtividade de negócios dentro das restrições daarquitetura de controle existente.
2. Produtividade de negócios através de capacitação erealização de nova arquitetura de controle.
3. Suporte e melhor capacitação de funções de negócios denúcleo de Inovação, Capacidade de Faturação, Qualidade e Capacidade deServiço.
4. Permissão para novas oportunidades de crescimento atravésda ativação de aparelhos de produção com a arquitetura de software 10, que,com a adição do conector 18, cria o aparelho 'conectável1. Essa abordagemminimiza o risco e o custo da conectividade por meio da externalização docusto de componentes eletrônicos para a rede.
Para realizar o potencial completo desta arquitetura, umconector simples pode estar disponível no aparelho 12, de modo que umcartão de rede pode ser plugado no aparelho. Veja as figuras 1 e 18 a 22 paraexemplos NICs externo adequados 20 conectados ao aparelho 12. Como oaparelho 12 já tem uma rede interna, de baixo custo 14 para sua finalidadeinterna, a fiação adicional para conectar a rede de comunicação interna 14com o MIC externo 20, por meio de uma interface interna / externa 18, émínima e pode ser realizada de maneira conhecida, tal como por um caboserial de três fios, um conector externo e uma ferragem.
A arquitetura de software 10 pode, de preferência, residir emtodos os componentes 16 do sistema de controle de aparelho eletrodoméstico.Contudo, onde custo ou outras restrições são proibitivas, a arquitetura desoftware 10 pode residir em um subconjunto dos componentes 16 dentro dosistema de controle do aparelho eletrodoméstico.
Benefícios exemplificativos dessa arquitetura "conectável"incluem, mas não estão limitados aos mesmos: NICs externos 20 podem seradicionados após a comercialização, reduzindo o custo de base do aparelho12. Os NICs 20 podem ser desenvolvidos suportando múltiplas tecnologias derede, aplicações em NICs 20 podem ser de plataforma cruzada e genéricos,devido à interface padrão apresentada pela arquitetura de software 10, umarede interna de baixo custo (tal como o exemplo de rede WIDE) é usada comouma estrutura de API padrão, e descoberta permite muitos comandosadicionados de valor, a arquitetura de software 10 usa exemplos delimitadospara preservar estado e fazer uso eficiente de largura de banda e a arquiteturade software 10 é projetada para ser configurada em tempo de execução quepermite aos programadores de programas uma arquitetura mais flexível quepode reduzir o tempo para comercialização.
A figura 2 é uma ilustração esquemática da rede decomunicação interna 14 da figura 1, mostrando a arquitetura de software 10interposta entre a rede de comunicação interna 14 e vários componentes desoftware 16B dentro do ambiente operacional do software 16A internos aoscomponentes 16 que constituem o sistema de controle para o aparelhoeletrodoméstico 12. Os componentes 16 na figura 2 representam componentestípicos encontrados em aparelhos 12, tal como um gerenciador de aparelho(placa principal ou placa mãe) e outro componente, tal como controle demotor e uma interface de painel de controle ou teclado numérico, em geral,referida como uma interface de usuário. Os índices "Energy" e "Diage", nafigura 2, são exemplos de funções típicas de não - núcleo, realizadas pelaarquitetura de software, tal como gerenciamento de energia e de potência("Energy") e localização de defeitos ou diagnose ("Diage"). Nãoexplicitamente mostradas na figura 2, estão funções de núcleo (API 1 - 7 e10) realizadas pela arquitetura de software e representadas pelos índices 10.
Além disso, a arquitetura de software 10 pode ser estendida amuitos outros tipos de arquitetura de sistema, onde a troca de dados através decomunicação par - a - par é desejada. Esses incluem sistemas de multi-nósonde múltiplas PCBs, tais como, placas de controle de motor, de controle deaparelho, e sensor inteligente se comunicam dentro do aparelho 12 usandoarquitetura de software 10. O protocolo de descoberta de arquitetura desoftware 10, ilustrado na figura 6 (e descrito aqui mais tarde), pode ser usadopara ativar um componente 16 cuja presença faz com que outros componentes16 adaptem suas funções de controle para criar um novo comportamento oudesempenho ou expor nova capacidade para o consumidor. Arquitetura decomponente da figura 2 (modelo estrutural) junto com o comportamento dedescoberta da figura 6 junto com o esquema de identificação de componentede ID de API, Tipo, Versão (veja ID de API = 3) são uma base para ainvenção concretizada em 10 para capacitar o aparelho com uma novaarquitetura de sistema dinâmica e inteligente.
A figura 3 é uma ilustração esquemática da rede decomunicação interna 14 da figura 1, mostrando componentes típicos decontrole de aparelho 16, trocando mensagens através da rede de comunicaçãointerna 14 do aparelho eletrodoméstico 12 compreendido um protocolo decamada inferior, WIDE sendo um exemplo do mesmo, que leva em conta ascamadas de OSI de PHY LINK e funcionalidade de3 camada de rede parcial eum protocolo de camada superior suportado pela arquitetura de software 10(que leva em conta as camadas de OSI de aplicação, transporte efuncionalidade de camada de rede parcial). O protocolo de camada inferiorfunciona como uma camada física e de ligação entre a camada superiorassociada com a arquitetura de software 10 e os componentes no aparelho.
Dessa maneira, a arquitetura de software 10 usa o protocolo de camadainferior para se comunicar com uma primeira camada de operação de software17 que implementa a lógica de controle do controlador 16 em relação aocliente 22, bem como usando uma segunda camada de software 19 paradesviar a lógica de controle e controlar diretamente os dispositivos associadoscom o controle 16. os dispositivos na figura 3 são os elementos físicos querepresentam a funcionalidade do componente de controle 16. A figura 3ilustra a arquitetura de controle 10 de uma perspectiva de pilha de software /protocolo.
Além disso, a figura 3 proporciona uma ilustração esquemáticade dois modos de operação ativados pela arquitetura de software 10 quecontrolam o acesso e o nível de intervenção entre as mensagens de redeexpostas pela arquitetura de software 10 e a RAM e EE internas e outrasformas de memória não volátil de 16A assim como a Camada de Dispositivode Saída, que é uma camada de operação de software de baixo nível 16Bresidente dentro de 16A e proporcionando controle direto dos dispositivoseletricamente conectados ao componente. A Camada de Dispositivo de Saída16B tendo controle direto dos dispositivos assim faz por ter acesso direto àmemória de endereço de porta de microprocessador, que, por sua vez, mapeiaos pinos físicos do micro processador, que, por sua vez, são conectadosatravés de vários aparelhos eletrônicos aos dispositivos eletromecânicos.
A Camada de Operação de Software 1 da figura 3 representacomponentes de software específicos de aparelho 16B que fazem interfacecom as mensagens de rede recebidas pela arquitetura de software 10 para aLógica de Controle de Aplicação, resultando na lógica de controle deaplicação empreendendo uma ação. Quando o aparelho está em um Estado deDesenvolvimento (chave rotulada A na figura 3), uma Camada de Operaçãode Software 2 adicional (compreendida de API 5 (API de baixo nível) e API7, (API de memória / Porta) e suas implementações e Lógica Alternativa)permitem que as mensagens de rede de API 5 e API 7 mudem o estado damemória física de 16A e os dispositivos. Dessa maneira, os dispositivos e amemória podem ser controlados independentemente do software de aplicação,'que controla, tipicamente, os dispositivos e a memória de acordo com umciclo operacional de Camada de Operação de Software 1. Esse controle diretopermite que cada função dos dispositivos seja controlada independentemente,o que é muito benéfico em processos de desenvolvimento ou diagnóstico.
A Camada de Operação de Software 2 é capacitada paraefetuar mudança de estado por uma mensagem de rede especial exposta pelaarquitetura de software 10 e, também lógica adicional que é personalizadapara os vários estados do aparelho (exemplo mostrado na figura 7). Durante oestado de desenvolvimento, é preferido que, quando o usuário interage com oaparelho da interface de usuário da figura 3, a camada de operação desoftware 1 não receberá as entradas de interface de usuário associadas. Aocontrário, a camada operação de software 2 receberá as entradas da interfacede usuário subseqüentemente, a camada de operação de software 2 podeinteragir com a Lógica Alternativa da figura 3. A Lógica Alternativa pode,por sua vez, fazer chamadas de função na Lógica de Controle de Camada deOperação de Software 1 mudar valores na memória ou mudar o estado dapluralidade de dispositivos anexa. Contudo, durante o estado dedesenvolvimento, a Camada de Operação de Software 1 não é capaz deefetuar o estado da interface de usuário (LEDs, lâmpadas, buzzers, telas detexto e gráficos, etc). O Estado de Desenvolvimento torna a Lógica deControle de Camada de Operação de Software 1 ineficaz a menos queinvocada da Camada de Operação de Software 2. Durante o Estado deDesenvolvimento, a lógica de implementação de API 5 e 7 e a LógicaAlternativa estão em completo controle do aparelho 12 e seus componentesassociados.
O Estado de Desenvolvimento reverte para o Estado Inativo(da figura 7) quando uma mensagem de rede especial é recebida. Além disso,é considerado que pelo menos uma compressão de tecla pré-determinada deuma seqüência de compressões de tecla também pode resultar em umatransição do Estado de Desenvolvimento para Inativo.
A Camada de Operação de Software 1 operaindependentemente da permissão da Camada de Operação 2. A finalidade doestado de desenvolvimento é permitir e ativar ciclos operacionais que nãoforam considerados previamente. A vantagem para essa abordagem é queimplementações e configurações do aparelho, algumas das quais estãoilustradas na figura 1 não requerem novas modificações de software paraqualquer componente 16 do aparelho porque o aparelho tem a capacidadeatravés da arquitetura de software 10 de suportar qualquer implementação ouconfiguração considerada.
Há muitos usos para essa capacidade. Eles incluem, mas nãoestão limitados aos:
1. Capacidade para adicionar novos componentes funcionais aum aparelho ativado com arquitetura de software 10, obtendo novascaracterísticas de comportamento e círculos de operação, sem modificaçãonos componentes funcionais pré-existentes. Exemplos disso são:
a. Adição de controle de vapor a uma lava - louças, secadora,forno e microondas.
b. Adição de energia e outros componentes de gerenciamentode recursos a um aparelho.
c. adição de conexões de ativação de componentes de rede àsredes externas além da rede interna 14.
d. adição de uma leitora de cartões a um aparelho comercial afim de criar um pagamento para usar modelo de uso.
e. adição de um dispositivo de memória que compreendeciclos adicionais de operação disponíveis para seleção e invocação por um nóde cliente ou aplicação ou de um usuário interagindo com uma interface deusuário.
2. Realização de testes diagnósticos, que podem ser realizadospela atuação de cada saída, seqüencialmente, para verificar os resultadosesperados (exemplo: aquecedor ligado - aumento de temperatura observado,válvula de enchimento ligada - observar subida do nível de água, motor detrituração de gelo - observar rotação do aparelho de trituração)
3. Realização de testes de fábrica automatizados.
4. Realização de testagem de desempenho automatizada eexecuções de DOE.5. Realização de testagem de ciclo de vida automatizada.
6. Testagem de unidade de componente 16 e testagem deregressão automatizada.
7. Realização de testagem de ECM automatizada.
8. Realização de outras formas de depuração e testagem adhoc.
9. Ativação de um dispositivo de cliente alternativo (exemplo:PC) para controlar o Aparelho 12, permitindo que o universo de ciclosselecionáveis de operação seja desenvolvido e testado, usando ambientesoperacionais de software alternativos 16A àquele que é requerido,tipicamente, nos componentes de computação embutidos de produção final16, que oferecem ambientes de programação mais produtivos, resultando emum tempo reduzido para comercialização de novos modelos de aparelhos.
A figura 4 é uma ilustração esquemática de uma estrutura depacotes 24 para rede de comunicação interna 14 do aparelho eletrodoméstico12, mostrado na figura 1, tendo uma porção de carga útil 26 compreendendouma estrutura de pacotes de aplicação 28 para a arquitetura de software 10 deacordo com a invenção. A estrutura de pacotes 28 representa uma mensagembem formada que a arquitetura de software 10 pode criar e enviar para outroscomponentes 16 e 22 (tendo uma ocorrência da arquitetura de software 10 ouuma variante da arquitetura de software 10 que foi projetada com a estruturade pacotes 28) para fms de uma troca de dados significativa. A estrutura depacotes 28 ocupa a posição 26 dentro da estrutura de pacotes 24, mas aestrutura de pacotes 28 poderia ocupar uma posição alternativa em umavariante de estrutura de pacotes. 28A representa uma estrutura de pacotesdentro de 28, que é definida de acordo com os valores de API Ib e Op CODEde estrutura de pacote 28.
Em um protocolo de rede, um pacote (algumas vezes chamadouma mensagem) é uma compilação de bytes que são transmitidos emseqüência, representando toda ou parte de uma mensagem completa. Emgeral, é composto de um cabeçalho, que inclui informação de roteamento, umcorpo (também referido como "carga útil") que é dado, e um rodapé quealgumas vezes contém uma soma de verificação (isto é, uma soma de CRC)ou um terminador, tal como indicador de "extremidade" a carga útil é umacompilação de bytes contidos em um pacote. A carga útil é o dado que estásendo transmitido entre as camadas de aplicação dé dois nós 16. A função darede e do protocolo é levar as cargas úteis de um nó para o outro. Algumasvezes, um protocolo é enviado como a carga útil de outro e, dessa maneira, osprotocolos podem ser alinhados ou empilhados.
Variáveis são denominadaslocalizações de memória, que terão valores associados. Uma ou maisvariáveis podem compreender a carga útil. Uma transação é uma série demensagens ou pacotes que representam uma troca de dados completa entreuma pluralidade de nós.
A relação entre um pacote e uma carga útil pode ter umimpacto sobre o uso eficiente de largura de banda disponível. O trade-off a serconsiderado é a quantidade de tempo de excesso necessário para levar ascargas úteis de um nó para o outro no contexto de exigências da camada deaplicação.
A estrutura de pacotes de protocolo 24 como um primeiro bytede cabeçalho que é identificado, por exemplo, como OxED, seguido por umbyte de endereço tendo 4 porções. A primeira porção do byte de endereçoscompreende uma porção de destino (D) de bits O, 1, 2. A segunda porção dobyte de endereço compreende uma porção de difusão B (de bit 3). A terceiraporção do byte de endereço compreende uma porção fonte (S) de bits 4, 5, 6.
A quarta porção do byte de endereço compreende uma porção reservada (R)de bit sete. O byte de endereço é seguido por um byte de identificaçãocompreendido de um comprimento de unidade de dados de serviço (SDU-L)compreendido de bits O - 3 e um identificador de SAP compreendido de bits 4- 7. O identificador de SAP define a estrutura da carga útil 26 encerrada. UmSAP de 4 indica que a SDU 26 encerrada é definida pela estrutura de pacotes28 associada com a arquitetura de software 10. O byte de identificação éseguido por uma unidade de dados de serviço que é referida, em geral, como a"carga útil" da estrutura de pacotes de protocolo 24 e é identificada em geralpela referência 26. A carga útil 26 é seguida por um byte de validação padrão,tal como uma combinação de byte - alto, byte - baixo, ou, em geral, referidapor aqueles habilitados na técnica como CRC16 - CCITT.
A estrutura de pacotes de aplicação 28 é formada da porção decarga útil 26 da estrutura de pacotes de protocolo 24. Está dentro destaestrutura de pacotes 28 que o protocolo de comunicação e a troca de dadospermitida pela arquitetura de software 10 é realizada. O primeiro byte daestrutura de pacote de aplicação 28 contém o identificador (API ID), uminteiro de 1 - 255 da API particular conduzida pelo caso particular daestrutura de pacote de aplicação 28. O segundo byte da estrutura de pacote deaplicação 28 contém um código de operação (aqui abreviado como "op code")como um inteiro de 1 - 31 no bit 0 - 4 seguido por um indicador de comandoou de realimentação (Cmd / Fd) de bit 5, um indicador de fragmentação(Frag) de bit 6 e um indicador pendente de mais mensagens (MMP) no bit 7.
Os bytes 3 - 15 da estrutura de pacotes de aplicação 28 compreendem a cargaútil (isto é, dados de mensagem) do caso particular da estrutura de pacotes deaplicação 28.
Essencialmente, a arquitetura de software 10 usa dois bytes dacarga útil 26 da estrutura de pacotes de rede 24 da rede de comunicaçãointerna 14 para protocolo adicional. O API ID é um identificador único parauma compilação de Op Codes, que são organizados em unidades funcionais.
OxFF (255) e OxOl (1), de preferência, são reservados. Um Op Code é umidentificador único dentro de uma API que define e identifica uma mensagemúnica de comando ou realimentação. Cada API tem um Tipo (2 bytes) eVersão (2 bytes) permitindo que uma grande biblioteca de grupos demensagens identificáveis, funcionalmente relacionados (Op Codes) sejacriada com o tempo.
De preferência, xlF (31) é um valor reservado para Op Code.O indicador Cmd / Fb indica se a mensagem é classificada como um comandoou uma realimentação. Um comando é uma mensagem que solicita que umaação seja empreendida, onde uma realimentação é uma mensagem quesimplesmente contém informação (reconhecimento, data de eventos, etc...).De preferência, o indicador de Cmd / Fb é O para comando e 1 pararealimentações.
O indicador Frag especifica se a mensagem recebida estásendo separada em múltiplas mensagens (fragmentos) pelo remetente porcausa das limitações de tamanho da SDU 26 de protocolo de camada inferior.O primeiro fragmento da mensagem tomará a estrutura da figura 4. Todos osfragmentos subseqüentes da mensagem assumirão a estrutura da figura 24. Oindicador Frag é de preferência ajustado até que a mensagem fragmentadaesteja completa.
O indicador de MMP indica que eventos são enviados comomensagens individuais, mas são delimitados pelo protocolo de modo que ocliente pode agrupar eventos como um snapshot completo para uma varredurado microcontrolador. O indicador de MMP, de preferência, é estabelecido atéque a última mensagem para um snapshot seja enviada. A figura 9 e adiscussão anexa proporcionam mais detalhes sobre mensagens delimitadas.
O indicador de MMP proporciona à arquitetura de software 10a capacidade de expressar o estado de um aparelho 12 como uma função devariáveis de realimentação independentemente significativas ligadas emsnapshots.
Quando o estado interno de um aparelho 12 muda, múltiploseventos podem ser enviados os quais, no total, descrevem o novo estado doaparelho 12. O número de eventos requeridos para descrever uma mudança deestado é específico de estado do aparelho 12. Portanto, delimitadores deprotocolo especiais são usados para permitir que um número específico deimplementação de variáveis de realimentação seja associado com umamudança estado particular de aparelho. Como esses eventos são significativosindependentemente, essa abordagem é preferível pelo fato de que todas aspermutações de agregações de eventos (dados) podem ser criadas através douso de MMP. Isso resulta em uso eficiente do espaço para o nome deidentificação (API ID e Op Code) porque nenhum novo identificador érequerido quando o cliente requer que uma nova combinação de dados sejaenviada. Em resumo, MMP e as suas regras associadas permitem agregaçãode dados dinâmica e virtual, eliminando a necessidade de soluções específicaspara o caso de aplicação especial. Na figura 9 o efeito do indicador de MMP émostrado.
O indicador de MMP também proporciona a capacidade paraque a implementação embutida suprima a condição transitória inválida. Amedida que o estado do aparelho transiciona, é possível que um conjunto devariáveis relacionadas mude3 diversas vezes muito rapidamente. Quando oestado do aparelho é expresso em termo de variáveis de realimentaçãoindependentes enviadas como exemplos separados (mensagens derealimentação) sem o mecanismo de ligação, estados transitórios ambíguos ouinválidos são prováveis de ocorrer. Além disso, se o cliente estiverexecutando lógica de negócios durante o estado transitório inválido, erroslógicos podem resultar em controle incorreto ou ações de exposição deusuário. Com referência à seção, portanto, Integridade de Estado rotulada paraum exemplo de como a coleta de dados assíncronos é uma abordagem inferiorpara dados coletados sincronicamente dentro de cada varredura domicroprocessador e transmitidos dentro do snapshot ativado por MMP. Alémdisso, a aglutinação de mensagens pode ser usada para agrupar invocações decomando independentes de modo que elas possam ser processadas em lote.
O protocolo de aplicação 28 também regula mensagens queentram. Em geral, as redes permitem que processos assíncronos secomuniquem, criando potencial para um nó de rede exceder a capacidade deprocessamento do outro pelo envio de solicitações demais dentro de umacurta janela de tempo. Para impedir excessos de mensagens, um protocolo éusado, de acordo com a invenção, que permite ao remetente esperar por umreconhecimento antes de enviar uma segunda mensagem.
Essa característica permite que a arquitetura de software 10use uma enumeração para esse reconhecimento com base no estado deexecução 8 da das 10. Dessa maneira, informação descrevendo o sucesso oufalha de mensagens é comunicada com menos mensagens. O remetente docomando receberá um reconhecimento enumerado para cada comandoenviado. O mais comum é um ACK positivo, o que significa que o nó estápronto para receber seu comando seguinte. Todas as outras enumerações sãouma forma de falha. A falha é caracterizada pelos 254 valores possíveisrestantes do byte Reconhecimento. Dessa faixa de 254 valores, alguns sãopadronizados e alguns são reservados para códigos de falha específicos deaplicação.
Frag e MMP permitem ao usuário da arquitetura de software10 permitem flexibilidade no planejamento da estratégia de mensagens deaplicação. Se um programador escolhe usar mensagens muito grandes, Fragpode ser usado de modo que mensagens maiores do que a carga útil 28A (istoé, 13 bytes dentro da estrutura de pacotes de aplicação exemplificativa 28aqui mostrada) podem ser enviadas através do envio de dados grandesoriginais estabelecidos como múltiplos conjuntos de dados menores dentro demúltiplos pacotes de estrutura 28.
Pela mesma suposição, se um programador escolhe usarmensagens menores (que são freqüentemente o caso) mas queria agruparaquelas mensagens juntas, MMP pode ser usado. Por exemplo, se 10mensagens de 3 bytes cada uma que precisam ser enviadas como um grupo,de modo que a aplicação de cliente poderia saber que as mensagens estavamrelacionadas com a mesma varredura do micro-controlador, então as 9primeiras mensagens terão MMP estabelecido e a última mensagem do grupoterá MQMP = 0. O seguinte apresenta um sumário de APIs definidas para aarquitetura de software 10 e, então, cada um desses comandos e mensagens derealimentação é descrito em detalhes. A vantagem dessa abordagem é que elapermite ao programador escolher modos dentro da arquitetura de software 10que são apropriados para o estágio corrente de desenvolvimento (isto é, testede unidade, testagem de engenharia, produção, etc). Além disso, a compilaçãode certos modos permite aos programadores usar porções da arquitetura desoftware 10 em cujos casos eram recursos de RAM / ROM que de outro modoseriam proibitivos. As APIs são descritas com seu identificador de interfacede programa e aplicação correntemente selecionado, porém, qualqueridentificador pode ser empregado sem afastamento do escopo desta invenção.
As funções associadas tornadas capazes pela API particular são enumeradasabaixo de cada API. Funções em forma de bala ("·") são mensagensrealimentadas que são enviadas da arquitetura de software 10 para o cliente(tal como o cliente interno 16 ou cliente externo 22) e funções não em formade bala são comandos que são enviados do cliente (16, 22) para a arquiteturade software 10.
Observe uma conversão usada neste pedido. A palavra"estende" se refere à capacidade de uma API de construir a funcionalidade deuma API de nível - base. A palavra estende significa: quando API χ'EXTENDS' API y, então API χ = API χ + API y. Essa notação simplifica atarefa de manutenção de registro e documentação de API. Em outras palavrasAPI χ também inclui aquelas funções específicas em API y. Se a API χ e APIy especificarem, cada uma delas, uma função com o mesmo Op Code, aimplementação de API χ pode tomar precedência.
A tabela a seguir descreve Núcleo API (APIID = 1):
• Reconhecimento de Mensagem_
• Publicar Indicação de Atividade_
• Estabelecer Período de Indicação de Atividade_
• No Período de Indicação de Atividade_
• Ler Memória_
• Publicar Dados de Memória_
• Ler EE_
• Publicar Dados de EE_
• Enviar Evento(s)_
• Publicar Evento_
A tabela a seguir descreve a API de aquisição de dados básica
(Basic DAQ, APIID = 2, Tipo = 1):
• Criar Evento Numérico_
• Criar Evento de Bytes_
» Limpar Evento(s)_
• Publicar Eventos Limpos_
• Reajustar SA_
• Publicar SA Reajustado_
• Ajustar Externo Ligado_
• Publicar Externo Ligado_
• Ajustar Externo Desligado_
• Publicar Externo Desligado_
A tabela a seguir descreve a API de aquisição de dadosestendida
DAQ Estendida, APIID - 2, Tipo 2):
A DAQ estendida é inclusiva de Basic DAQ, em tempo deexecução.
• Obter Dados de Eventos_
• Publicar Dados de Eventos Numéricos_
• Publicar Dados de Bytes de Eventos_
• Criar Evento Numérico Remoto_
• Criar Evento de Bytes Remoto_
• Obter Dados Variáveis Remotos_
• Publicar Dados Variáveis Remotos_
A tabela a seguir descreve a API de Descoberta (API ID = 3)
• Encontrar Nós_
• Publicar Nó_
• Obter APIs• Publicar APIs_
• Obter Info de API_
• Publicar Info de APR_
• Obter Info de Caso_
• Publicar Info de Caso_
A tabela a seguir descreve API de Core Debug (depuração denúcleo) (APIID = 4)
• Publicar Saturação_
• Registrar Mensagem de Saturação_
A tabela a seguir descreve a API de Nível Baixo (API ID = 5)
• Ajustar Estado de Desenvolvimento_
• Publicar Estado_
• TBD (Específico de Aparelho)_
A tabela a seguir descreve a API de Compressão de tecla de núcleo(API ID = 6)
• Pressionar Tecla (índice de teclas)_
• Publicar Compressão de tecla (índice de teclas)_
A tabela a seguir descreve API de Memória de Núcleo/ Porta(API ID = 7)
• Escrever Memória_
• Escrever EE_
A API de Gerenciamento de Energia é APIID = 8. Como asoutras APIs, a API de Energia é feita de uma compilação de Op Codes, cadaum representando uma função útil referente ao gerenciamento de energia etendo uma compilação de bytes associados,, que são os parâmetrosapropriados para obter a função.
A tabela a seguir descreve a API de Variável de Checagem(APIID= 10):
• Ler Variável de Checagem_
• Publicar Variável de Checagem_
A API Núcleo (API ID = 1, aqui) é o menor subconjunto dafuncionalidade da arquitetura de software 10 que pode ser empregado.Contudo, é considerado que outras modalidades em conformidade com aestrutura de pacotes 28 podem ser desenvolvidas. Toma-se providências paradesenhar os dois esquemas de aquisição de dados codificados permanentes,referenciados na figura 5.
Na API Núcleo, um mecanismo de protocolo, enviar Eventosda Figura 5, permite ao cliente (16, 22) solicitar à fonte de eventos para enviartodos ou enviar um conjunto especificado de eventos. Dessa maneira, um tipode checagem é possível dentro da estrutura da arquitetura de eventos, semseparar definições de mensagem ou estruturas e lógica de implementação.
Além disso, esse mecanismo possibilita sólidas condições de inicialização desistema. Por exemplo: se todos os nós de rede enviarem todos os eventossimultaneamente ao iniciar o sistema, operação imprecisa dentro do softwarede um cliente 16 ou 22, onde os componentes de software existentes não serãocapazes de processar, precisamente, a pluralidade de mensagens geradascomo um resultado de uma condição de início, é mais provável.
A API de DAQ (API ID = 2) apresenta uma consulta demecanismo dinâmico para um componente 16 ativado pela arquitetura desoftware 10. Esse aspecto permite ao cliente 16/ 22 configurar um mecanismode software embutido (um arranjo de estruturas cujos elementos sãoinstanceados e armazenados em uma heap de memória dinâmica [vejaDynamicMemoryHeap da figura 33, contendo uma compilação de estruturasNVOEvent]), que associa uma seção de memória de microprocessador comum operador de eventos (descrito em uma tabela abaixo) e argumentos.
Indicadores na memória, valores da memória, operadores de eventos eargumentos de operadores são armazenados no arranjo de estruturas da heapda memória [figura 33 HeapG contendo estruturas NVOEvent]. Conformemostrado na figura 5, o mecanismo de DAQ pode ser configurado de duasmaneiras:
1. Software de aplicativo à parte da arquitetura de software 10,que reside no mesmo microprocessador, pode configurar DAQ 30 como émostrado pela seta na figura 5 do componente de software de DAQ Init().
2. Em segundo lugar, clientes externos podem usar a API deDAQ (aqui descrita) para configurar a DAQ da rede 14.
A razão para cada método de configuração de DAQ é discutidaparágrafos daqui em diante.
Conforme mostrado no Diagrama de Estado de Eventos deDAQ do Processo da figura 36, quando o mecanismo de DAQ é executado,ele itera através de cada estrutura de evento, verificando as localizações dememória associadas contra o operador de eventos e argumentos. Quando ascondições de evento avaliam para um TRUE, memórias temporárias demensagens são construídas dentro da memória interna, refletindo os dadosassociados com a condição de evento. Quando a iteração está completa,mensagens de notificação são geradas e, de preferência, difundidas para arede. Alternativamente, mensagens de notificação podem ser dirigidas a umcomponente específico 16, se memória adicional for alocada para armazenar oidentificador de rede do componente que, inicialmente, solicitou ouconfigurou o evento.
Um programador pode usar diversos operadores de eventos.Exemplos incluem: em mudança, maior do que, menor do que, igual a, bandamorta, máscara de bits, etc. Diversos Op Codes da API de DAQ sãoproporcionados para controlar a heap de memória em tempo de execução,como: limpar Eventos, adicionar Eventos, notificação Externa liga/ desliga,obter Eventos, obter Dados de Eventos, etc.
No total, a arquitetura de software 10 suporta quatro esquemaspara compilação de dados (todos os quais são mostrados na figura 5). Doisdos quatro esquemas descritos resumidamente acima são confiantes na DAQ.Os outros dois esquemas, também descritos resumidamente acima, sãoinseridos no código. Cada esquema pode co-existir dentro da arquitetura desoftware 10. Cada esquema proporciona certas otimizações às custas deoutros recursos.
1. Em um esquema de aquisição de dados configurado pelocliente, eventos dinâmicos são criados. Esse método pode ser usado, se omicroprocessador tiver bastante capacidade de RAM/ROM e é maiscomumente usado quando o cliente é uma aplicação de PC. Usando a API deDAQ, um programador pode re-utilizar o código, requerer menos tempo deengenharia, alavancar um módulo de eventos re-utilizável comprovado, éflexível (por exemplo, pode ser configurado em tempo de execução) e podehaver uma otimização de largura de banda de rede. Contudo, esse métodopode requerer mais RAM/ROM do que os métodos inseridos no código e umcliente embutido poderia não ter acesso aos arquivos de dados necessários notempo de execução.
No esquema de aquisição de dados configurados pelo cliente,o mecanismo de DAQ 30 deve ser proporcionado em uma localização damemória a fim de observar um evento. Com um mapa variável, isso é práticoquando o cliente é uma aplicação de PC, como na figura 26A. Contudo,quando o cliente é, por exemplo, outro painel de controle que implementa aarquitetura de software 10, o acesso a um mapa variável é impraticável. Dessemodo, a presente invenção proporciona funcionalidade para um mapa variávelembutido localizado na memória de um nó implementando na arquitetura desoftware 10. Esse mapa variável liga uma API e um Op Code a um endereçode variável como na figura 26B. Desse modo, a fim de registrar um evento noreferido nó, o cliente precisa apenas conhecer a API e Op Code para aquelavariável, não o endereço de memória específica.
Usando o mapa de variáveis embutido no esquema deaquisição de dados configurado pelo cliente, a situação pode se originar ondeum cliente particular está restrito da criação de um evento porque o para APIe Op Code associado já foi registrado por outro nó. Nessa situação, a presenteinvenção proporciona para aquele nó a capacidade de solicitar informação acerca do mapa de variáveis embutido. Incluído nessa informação está oendereço de memória de variável. Com essa informação, o nó de cliente poderegistrar para um evento da mesma variável, usando o endereço de variável eum par de API e Op Code diferente daquele previamente tentado (veja afigura 27).
2. Uma alternativa à DAQ configurada pelo cliente é a DAQauto-configurada. Nesse caso, a lógica interna usa o mecanismo de DAQ paracriar estruturas de NVOEvent na DynamicMemoryHeap da figura 33. Essepode ser um esquema útil quando os eventos a serem realizados são fixos esão conhecidos no momento do desenho e há recursos suficientes de RAM eROM para reutilizar o mecanismo de diferença (a lógica contida dentro daDAQ 30). Portanto, esse método tem benefícios similares ao esquema deeventos dinâmicos configurados pelo cliente e, além disso, requererá maisRAM/ROM do que os métodos de código inserido (descritos abaixo).
3. Em um módulo de eventos de código inserido, umprogramador pode otimizar largura de banda da rede, otimizar o uso deRAM/ROM e pode se conformar à API de DAQ. Contudo, esse esquemarequer uma solução com código personalizado para gerar os eventos e nãoconta com o software e a lógica da DAQ 30, conforme mostrado na figura 36.
4. Usando o método de checagem de código fixo,proporcionado pela API de Core, um programador pode otimizar o uso deRAM/ROM pela criação de solução de código personalizado. A checagem,em geral desperdiçará largura de banda da rede, mas algumas vezes é usadadevido a sua simplicidade.
A figura 5 ilustra um exemplo de cada tipo de método deaquisição de dados potencial. Uma instalação da arquitetura de software 10pode suportar um, alguns ou todos os 4 métodos. Cada um, dentre a instalação10 e o cliente 16, pode ter uma API de DAQ inicializada. A arquitetura desoftware 10 pode ter uma ou mais variáveis de checagem de código fixo, umou mis eventos de código fixo e/ ou um mecanismo de DAQ 30 comodescrito. Várias variáveis e eventos são transmitidos entre a instalação dearquitetura de software principal e o cliente. Por exemplo, diversas variáveisde checagem de código fixo são permutadas entre a arquitetura de software 10e o cliente 16 entre os métodos ler Variável de Checagem e publicar Variávelde Checagem. Vários eventos de código fixo são permutados entre aarquitetura de software 10 e o cliente 16 pelos métodos enviar Evento epublicar Evento. Um método criar Evento é chamado pelo mecanismo deDAQ Init, que é enviado para o Mecanismo de DAQ 30, que, por sua vez,permuta um evento gerado com o cliente 16 pelos métodos enviar Evento epublicar Evento. O mecanismo de DAQ 30 na arquitetura de software 10também pode criar um evento recebido por meio de um método criar Evento,recebido do cliente 16.
A figura 5A é uma ilustração esquemática mostrandocomunicação entre um aparelho eletrodoméstico 12, tendo a arquitetura desoftware 10 nele instalada de acordo com a invenção e mostrada na figura 1 eum cliente 16 em uma localização remota, tal como um centro de suporte dechamada do consumidor, conforme mostrado na figura 5 A. O aparelho 12 temuma interface 18 com sua rede interna 14 e uma interface de rede 20 quepermite que ele se comunique com o cliente externo 22. A vista esquemáticada figura 5A mostra o centro de serviço do consumidor preparando umaobservação de variável, usando a função criar Evento do Mecanismo de DAQ5 e diagnosticando uma dificuldade com o aparelho eletrodoméstico 12, semnecessidade de enviar um caminhão de serviço para a residência.
A arquitetura de software 10 pode ser personalizada parapermitir as necessidades de diferentes plataformas de implementação. Acomplexidade de tempo e espaço da RAM e da ROM pode ser gerenciada,bem como acesso às localizações de memória e limites de tempo. Todos essesestão localizadas em um arquivo de parâmetros pré-determinado. Serácompreendido que os parâmetros podem ser renomeados, mudados,reimpressos, adicionados ou cancelados, sem afastamento do escopo dapresente invenção.
API de Descoberta (API ID = 3) permite o conceito dearquitetura de "Plug 'n Play". A API de Descoberta implica que um nó de redefísica ou cliente 16 pode conter η funções, cada uma encapsulada por umaAPI conhecida com um unido ID5 Tipo e Versão. Essas APIs são portáteis(significando que elas representam funcionalidade e são independentes domicroprocessador, da linguagem de software e da topologia de rede) e re-utilizáveis em outros componentes onde a funcionalidade existente éaplicável. O protocolo de Discovery (descrito em API 3 da figura 6) permite1 (X- que o cliente aprenda as associações entre os componentes 16 e os grupos defuncionalidade (APIs) que eles contêm.
A figura 6 ilustra uma seqüência típica de API de Descoberta.Não tendo estruturas na memória representando os outros componentesativados da arquitetura de software 10, um cliente 16, 22 transmite umcomando para localizar componentes 16 dentro do aparelho, que são ativadoscom a arquitetura de software (pela emissão de um comando "find Nodes"(encontrar Nós)). Os componentes ativados respondem que, na verdade, elesestão ativados (pela emissão de um comando difundido de "publicar Nós").
Então, o cliente 16 transmite um comando para identificar que as APIs estãolocalizadas em cada nó ativado (pela emissão de um comando "find APIs").Cada nó ativado responde com uma mensagem delimitada, contendo seus IDsde API (através de resposta com uma mensagem de "publicar APIs"). Então, ocliente 16, 22 emite um comando para identificar informação a cerca de cadauma das APIs encontradas em cada nó ativado (pela emissão de um comando"obter Info de API"). Cada nó ativado responde com uma mensagemdelimitada (cuja finalidade e estrutura são descritas na figura 9) contendoinformação a cerca da API nele contida (respondendo com uma mensagem de"publicar Info de API"). Essa mensagem pode incluir tipo, versão e o númerode ocorrências (ou instâncias) de um Id de API particular. Em casos onde onúmero de instâncias de uma API particular dentro de um componente único16 excede um (significando que há múltiplas das mesmas APIs instaladas emum componente 16, como no caso de um forno de múltiplas cavidades quepoderia usar múltiplas APIs de controle de forno), o cliente 16 emite umcomando para obter informação em cada instância de uma API (pela emissãode um comando "obter Info de Instância"). A arquitetura de software 10responde com a informação solicitada (através da mensagem "publicar Info deInstância"). Múltiplas das mesmas instâncias são auto-numeradas com umpseudo-ID de API por meio da arquitetura de software.
Além disso, quando um componente 16, ativado pelaarquitetura de software 10 e tendo residente o sub-componente da arquiteturade software 10, Discovery que é API -Id- APId = 3, inicializa,automaticamente, enviará uma mensagem se anunciando (API Id = 3, OpCode = 2 publishSANodeO).
Também, se o usuário da arquitetura de software assimescolher, a seqüência de Discovery da figura 6 pode ser alterada por meio daomissão de mensagens 1 e 2 (Op Codes 1 & 2, respectivamente). Aabordagem é válida pelo fato de que o cliente pode iniciar a descoberta pelaemissão de uma mensagem Op Code = 3, obter SAAPI(coleta) que resultaráem respostas de todos os componentes ativados pela arquitetura de software10, assim, evitando a necessidade de mensagens 1 e 2 na maioria dos casos.
Também é considerado que uma seqüência de mensagensabreviadas poderia obter os mesmos resultados que a seqüência de descobertaantes mencionada. Em uma seqüência de descoberta abreviada, cada nó emiteuma mensagem após o início, contendo dentro de uma mensagem a totalidadede informação que foi descrita na seqüência de descoberta antes mencionada.
Cada nó que recebe esta mensagem responderá com a mesma informação acerca de si mesmo, dando o nó que iniciou a informação que pode serdescoberta de todos os nós que já estavam iniciados.O mecanismo do protocolo de API de Descoberta permitea um cliente 16 localizar uma entidade lógica em tempo de execução,sem antes compilar programação de tempo. Além disso, essemecanismo permite ao cliente 16 determinar se componentes esperadossão residentes ou estão faltando. A partir desse conhecimento, o clientepode se configurar e/ou apresentar ao usuário a funcionalidade inferidaapropriada.
A API de baixo Nível (APIID = 5) expõe, através da rede 14,capacidade, permitindo ao cliente controlar (atuar) os dispositivos de saídaque são conectados eletricamente aos componentes de contenção 16 eproporcionar acesso de leitura e/ou escrita ao valor numérico que representa oestado corrente e, potencialmente, a história de estado do dispositivo deentrada conectado eletricamente. Exemplo típicos de saída são válvulas, relês,triacs, solenóides, LEDs, lâmpadas, campainhas e assim por diante. Exemplostípicos de entradas são botões de calcar, comutadores, sensores (por exemplo,pressão, temperatura e temperatura em excesso) e assim por diante. Namodalidade preferida, a API de baixo Nível, assim como a API Memória -
Porta estão disponíveis apenas no 'Estado de Desenvolvimento' da figura 3 daarquitetura de software 10 do aparelho 12. O 'Estado de Desenvolvimento' sópode ser introduzido do 'Estado Inativo' do aparelho 12 do diagrama de estadode Aparelho da figura 7. Também, na modalidade preferida, se quaisquerações de interface de usuário são iniciadas através de um teclado numérico,Icd ou outro dispositivo de interface de usuário do aparelho 12, durante'Estado de Desenvolvimento', o aparelho 12 pode reverter para o 'EstadoInativo' da figura 7 e colocar cada saída de volta para seu estado não atuado.
As mensagens para iniciar o 'Estado de Desenvolvimento' podem serencontradas na especificação de definição de mensagem para a API de baixoNível. (Ver API 5, Op Code 2). Essa mensagem de rede é definida parapermitir que o aparelho 12 entre no estado de desenvolvimento. No estado dedesenvolvimento simples, uma API é ativada e exposta a rede 14 que permiteque o cliente 16 controle as saídas eletrônicas do aparelho 12 diretamente. Noestado de desenvolvimento, regras de negócios orientadas para produção,como uma validação, são desviadas, dando ao cliente 16 controle completo dosubsistema eletrônico.
A API de baixo nível pode ser usada para implementaroperação não padrão do aparelho pelo fato de que o aparelho pode seroperado de uma outra maneira que não de acordo com um dos ciclos deoperação pré-determinados, implementados pela camada de operações desoftware de aparelho, que, tipicamente, reside no operador principal. Dessamaneira, a API de baixo Nível pode ser pensada como permitindo ciclosadicionais de operação. Alguns exemplos de ciclos adicionais de operaçãoincluem: um ciclo de demonstração; um ciclo de desenvolvimento; um ciclode detecção de erro; um ciclo de diagnóstico; um ciclo que reduz o tempo depelo menos uma etapa cronometrada de um dos ciclos de operação pré-determinados; um ciclo que desvia pelo menos uma etapa operacional de umdos ciclos de operação pré-determinados; um ciclo que substitui uma etapacronometrada por uma Etapa que responde a um evento de um dos ciclos deoperação pré-determinados; e um ciclo que expõe a API de baixo Nível àrede.
A API de Compressão de tecla (API 6) permite ao cliente 16comprimir teclas virtuais. Isso proporciona um método igual pelo qualexercitar e testar o software, sem atuação mecânica ou humana do tecladonumérico físico.
Uma observação sobre uma convenção. A palavra "estende" serefere à capacidade de uma API construir sobre a funcionalidade-de umaAPI de nível - base. A palavra chave estende-se significa: quandoAPI χ 'EXTENDS' API y, então API χ = API χ + API y. Essanotação simplifica a tarefa de manutenção de registro e documentaçãode API. Em outras palavras API χ também inclui aquelas funçõesespecificadas em API y. Se API χ e API y especificam, cada uma delas, umafunção com o mesmo Op Code, a implementação de API χ pode terprecedência.
Pacotes de aplicação exemplificativos para a porção de cargaútil da estrutura de pacotes para a rede de comunicação interna do aparelhoeletrodoméstico seguem. Os pacotes de aplicação são agrupados de acordocom a API.
API Núcleo (API de Núcleo): APIID = 1 (Tipo 3, Versão 1).
O pacote de aplicação a seguir representa uma mensagem direta daarquitetura de software 10 para um cliente, para publicação dereconhecimento (Publicar Reconhecimento). Esta mensagem é enviada pelaarquitetura de software 10 para o remetente de uma mensagem anterior. Elacontém um valor enumerado, representando os resultados do comandoanterior processado pela arquitetura de software 10. De um modo geral, orecibo do reconhecimento indica que o remetente pode iniciar a mensagemseguinte.
<table>table see original document page 42</column></row><table>
Note que a API e o op code do comando previamente recebido(aquele que está sendo reconhecido) está contido dentro do byte 4 e do 5 dacarga útil. Isso proporciona ao receptor do reconhecimento (o componente 16que enviou o comando original) a certeza quanto a que comando previamentetransmitido está sendo reconhecido. (O comando previamente transmitido,tendo o identificador único de API Id e Op Code). Deve ser notado que, nosdesenhos e nas descrições, o ACK é, em geral, suposto e não continuamenterepetido ou documentado. Valores de enumeração para o código de razão dopacote de aplicativo acima são mostrados na tabela abaixo.
<table>table see original document page 42</column></row><table><table>table see original document page 43</column></row><table>
*0 - 3 são reservados para uso pela arquitetura de software 10
O pacote de aplicação a seguir representa uma mensagem dedifusão da arquitetura de software 10 para um cliente (16 ou 22) para publicarindicação de atividade (Publicar Indicação de Atividade). Essa mensagem éperiodicamente indicada pela arquitetura de software 10. Isso permite que osnós, que tinham sido registrados para eventos, mantenham a confiança nasfontes de eventos. Em outras palavras, a indicação de atividade asseguraintegridade da conexão. Alternativamente, o cliente (16 ou 22) podedeterminar que cada um ou alguns do(s) evento(s) enviado(s) pela arquiteturade software 10 receberão um reconhecimento enviado pelo cliente de voltapara a arquitetura de software 10, antes que a arquitetura de software 10considere a transação associada com a geração e a transmissão do evento estácompleta. Se um evento particular tiver sido criado com o classificador de'reconhecimento' de acordo com a especificação de mensagem de API2, OpCode = 1, 2, 12, ou 13, a arquitetura de software 10 definirá o final datransação associada com a geração e a transmissão do evento como estandocompleta, quando uma mensagem de reconhecimento for recebida de acordocom a mensagem especificada por APIID 1 e Op Code 1.
Publicar Indicação de Atividade não será enviado até após aarquitetura de software 10 receber um comando. Isso pode ser usado paraimpedir uma condição de Traffic Storm durante a iniciação. (Traffic Storm serefere a uma operação errada dentro do software de um cliente 16 ou 22 ondeos componentes dos softwares existentes não serão capazes de processarprecisamente a pluralidade de mensagens geradas como um resultado de umacondição de iniciação). Publicar Indicação de Atividade será suspenso apósuma mensagem de Restaurar SA, que é descrita abaixo com relação a CoreDAQ API e Op Code 8, se recebida, mas retornará após o comandosubseqüente seguinte. Essa é uma mensagem de re-alimentação.
<table>table see original document page 44</column></row><table>
O pacote de aplicação a seguir representa uma mensagemdireta de um cliente para a arquitetura de software 10 para ajustar período deindicação de atividade (SetHeartbeat Period), que está ajustando umafreqüência em que a mensagem de heartbeat é enviada pela arquitetura desoftware 10. Freqüências exemplificativas oscilam de 0 segundos (desligado)a 3600 segundos (1 hora).
<table>table see original document page 45</column></row><table>
O pacote de aplicação a seguir representa uma mensagem dedifusão da arquitetura de software 10 para um cliente para publicação doperíodo de indicação de atividade (Publicar Indicação de Atividade). Essamensagem é uma resposta para Ajustar Período de Indicação de Atividade. Enecessária de modo que, se um segundo cliente mudar o período de indicaçãode atividade, o primeiro cliente será notificado. Clientes que requeremperíodos de indicação de atividade de não mudança usarão a SAQ API parapreparar um evento com um operador de difusão constante, Veja DAQ API Id= 2, Op Code 1, Byte 9 = 4,5 ou 6 (ver mudar tabela de operador).
<table>table see original document page 45</column></row><table>
O pacote de aplicação a seguir representa uma mensagemdireta de um cliente para a arquitetura de software 10 para leitura de memória,particularmente a RAM (Ler Memória). Ela é enviada para a arquitetura desoftware IOe resulta em uma resposta de "Publicar Dados da Memória", queé mostrada abaixo (Op Code 4) e contém valores especificados em Bytes 3 -7 do pacote abaixo.
<table>table see original document page 45</column></row><table>
O pacote de aplicação a seguir representa uma mensagemdireta de um cliente para a arquitetura de software 10 para leitura de memóriaEE (Ler EE). Ela é enviada para a arquitetura de software IOe resulta em umaresposta de "Publicar Dados de EE" (Op Code = 8), que é mostrada abaixo econtém valores especificados em Ler pacotes de EE, Bytes 3-7abaixo.<table>table see original document page 46</column></row><table>
O pacote de aplicação a seguir representa uma mensagemdireta da arquitetura de software 10 para um cliente para publicar dados dememória (Publish Memory Data) e é uma resposta para Ler Memória.
<table>table see original document page 46</column></row><table>
O pacote de aplicação a seguir representa uma mensagemdireta de um cliente para a arquitetura de software para enviar eventos (EnviarEventos). A mensagem instrui a arquitetura de software 10 para enviareventos especificados, independente de critérios de disparo de eventos.
Nota: Id de Evento é usado como sinônimo de Op Code. ID deEvento é um termo mais descritivo para Op Code , quando descrevendo umEvento que é parte de uma API.
Nota: a notação usada abaixo é repetida através do documentoe é descrita aqui apenas. Se o Byte 3 contém o valor reservado OxFF, então aarquitetura de software 10 interpreta Byte 3 para significar todos os Ids deAPI. Caso contrário, o Byte 3 especifica um Id de API particular. Igualmente,se Byte 4 contém OxFF, a arquitetura de software 10 interpreta Byte 4 comosignificando todos os Eventos para a API ou APIs especificadas no Byte 3.Caso contrário, Byte 4 contém um único Id de Evento. Os Bytes de 5 ao Byteη contêm um único ID de Evento.
<table>table see original document page 46</column></row><table>O pacote de aplicação a seguir representa uma mensagem dedifusão da arquitetura de software 10 para um cliente para publicação deeventos (Publicar Eventos) e é uma resposta à mensagem Enviar Eventosacima. De modo alternativo, se o mecanismo de DAQ estiver sendo usado,essa mensagem é enviada quando os critérios de disparo de eventos sãosatisfeitos, Abaixo, API ID e Op Code são notados como 'definido pelocliente'. Isso se refere à atribuição feita de APIID e Op Code pelos comandoscreateEvent (enviados pelo Cliente) de DAQ API (API Id = 2),especificamente nos Bytes 7 e 8 de Op Code 1 & 2 e Bytes 3 e 4 de Op Code12 & 13.
<table>table see original document page 47</column></row><table>
Core DAQ API: APIID = 2 (Tipo 3, Versão 1). O pacote deaplicação a seguir representa uma mensagem direta de um cliente para aarquitetura de software 10 para criar um evento numérico (Criar EventoNumérico). A mensagem, identificada por API Id de 2 e Op Code de 1 ou 2permite ao cliente criar e configurar variáveis de realimentação [estruturas deNYOEvent da figura 33]. Os bytes 7 e 8 são usados para atribuir oidentificador (API Id e Op Code), que será usado para povoar campos namensagem publicar evento (API Id 1), quando as condições de evento são taisque uma mensagem de evento é gerada. Mensagens de eventos gerados são daforma encontrada na descrição precedente da API NÚCLEO, onde o pacotede mensagem é rotulado como 'Publicar Eventos'. Os identificadores APIID eOp Code localizados nos bytes 1 e 2, respectivamente, da mensagem PublicarEventos. Os valores encontrados nesses bytes podem ser atribuídos atravésdas mensagens definidas para DAQ API, Op Codes 1 e 2 abaixo. Os bytes 3 -5 contêm o endereço na memória do ambiente operacional de software queserá avaliado para a condição de evento representada pelo Byte 9, que é umaenumeração de regras de avaliação e Bytes AeB, que são argumentos para asregras de avaliação. O byte 6 especifica o número de bytes contíguos queserão avaliado como um valor numérico único com relação aos Bytes 9, A e B.
<table>table see original document page 48</column></row><table>
Operadores de eventos associados com o Byte 9 do pacote deaplicação acima são discutidos em mais detalhes em seguida a esta seção depacotes de aplicação exemplificativos e são mostrados na tabela que denotaoperadores de evento disponíveis, quando da criação de um evento de basenumérica. Adicionalmente, o byte C corresponde ainda à classificação queresulta em eventos reconhecidos ou não reconhecidos (discutidos mais tarde).Veja a figura 29 para um exemplo da operação de um evento 9 reconhecido.
O pacote de aplicação seguinte representa uma mensagemdireta de um cliente para a arquitetura de software 10 para criar um evento debyte (Criar Evento de Byte). As definições de mensagens, identificadas porAPI Id = 2 e Op Code = 1 ou 2 permitem ao cliente criar e configurarvariáveis de realimentação (eventos). A especificação de mensagem para OpCode 2 é similar em intenção, mas tem detalhes de implementação diferentesque proporcionam utilidade para certos casos de uso da aplicação. API Id 2com Op Code 2 difere em funcionalidade de API 1 Op Code 1, pelo fato deque, dependendo do valor de Byte A, apenas 1 byte dentro da faixaespecificada por Bytes 3 - 5 e Byte 6 ou todos os bytes serão avaliados combase no operador de mudança de Byte 9 e no valor de mudança de Byte B.
Enquanto no caso de Op Code 1, os bytes especificados foram avaliadoscomo um único numérico. No caso de Op Code 2, cada byte ou um únicobyte, de acordo com o valor especificado no Byte A, será avaliadoindependentemente, de acordo com o operador de mudança especificado noByte 9 e o valor de mudança especificado no Byte B.<table>table see original document page 49</column></row><table>
Operadores de eventos associados com o Byte 8 do pacote deaplicação acima são discutidos em detalhes adicionais em seguida a esta seçãode pacotes de aplicação exemplificativos e são mostrados na tabela quedenota operadores de eventos disponíveis quando da criação de um eventobaseado em bytes. Adicionalmente, o byte C corresponde à classificaçãoadicional, resultando em eventos reconhecidos ou não reconhecidos(discutidos mais tarde). Veja a figura 29 para um exemplo da operação de umevento reconhecido.
O pacote de aplicação a seguir representa uma mensagemdireta de um cliente para a arquitetura de software 10 para limpar evento(s)(Limpar Evento(s)). A mensagem Limpar Eventos permite ao cliente limparas definições de eventos previamente criadas com ambos os Op Codes criareventos (1 ou 2, conforme mostrado acima). O cliente pode enviar múltiploscomandos Limpar Evento para a arquitetura de software 10, usando oindicador de MMP, se sincronização for necessária através de múltiploscomandos.
<table>table see original document page 49</column></row><table>
O pacote de aplicação a seguir representa umamensagem de difusão da arquitetura de software 10 para um clientepara a publicação de eventos limpos (Publicar Eventos Limpos) eé uma resposta para Limpar Eventos. A mensagem notifica osclientes da arquitetura de software 10, quando Op Codes ouAPIs são removidos da interface de nós de arquitetura de softwareexistente.<table>table see original document page 50</column></row><table>
O pacote de aplicação a seguir representa uma mensagemdireta de um cliente para a arquitetura de software 10 para reajustar aarquitetura de software 10 (Reajustar SA). O comando Reajustar SA instrui aarquitetura de software 10 para reinicializar, como se ela tivesse já iniciado.
<table>table see original document page 50</column></row><table>
O pacote de aplicação a seguir representa uma mensagem dedifusão da arquitetura de software 10 para notificar que a arquitetura desoftware 10 foi reajustada (Publicar Reajuste de SA) e é uma resposta paraReajustar SA.
<table>table see original document page 50</column></row><table>
O pacote de aplicação a seguir representa uma mensagemdireta de um cliente para a arquitetura de software 10 para ativar a notificaçãoexterna para um evento especificado (Ajustar On Externo). O comando instruia arquitetura de software para notificar externamente clientes do evento. Vejaa figura 28 para um exemplo do uso desse comando.
<table>table see original document page 50</column></row><table>
O pacote de aplicação a seguir representa uma mensagem dedifusão da arquitetura de software 10 para notificar que a notificação externado evento especificado foi ativada (Publicar On Externo) e é uma respostapara Ajustar On Externo. Veja a figura 28 para um exemplo do resultadodesse comando.
<table>table see original document page 50</column></row><table>
O pacote de aplicação a seguir representa uma mensagemdireta de um cliente para a arquitetura de software 10 para desativar anotificação externa para um evento especificado (Ajustar Off Externo). Ocomando instrui a arquitetura de software para não notificar, externamente,clientes do evento.
<table>table see original document page 51</column></row><table>
O pacote de aplicação a seguir representa uma mensagem dedifusão da arquitetura de software 10 para notificar que a notificação externado evento especificado foi desativada (Publicar OFF Externo) e é umaresposta a Ajustar Off Externo.
<table>table see original document page 51</column></row><table>
API de DAQ Núcleo: API ID = 2 (Tipo 4, Versão 1 -Extensões Tipo 3, Versão 1). O pacote de aplicação a seguir representa umamensagem direta de um cliente para a arquitetura de software 10 para obterdados de eventos (Obter Dados de Eventos). Obter Dados de Eventos instrui aarquitetura de software 10 para enviar defmição(ões) de eventosespecificados. A definição é uma imagem de espelho dos dados enviados nasmensagens Criar Op Code de Eventos, que são mostrados acima como OpCodes 1 ou 2 para a Core DAQ API. A arquitetura de software 10 responderácom uma compilação de mensagens de Publicar Dados de Eventos, que sãomostradas abaixo.
<table>table see original document page 51</column></row><table>
O pacote de aplicação a seguir representa uma mensagemdireta da arquitetura de software 10 para um cliente para publicar dados deeventos numéricos (Publicar Dados de Eventos Numéricos) e é uma respostapara Obter Dados de Eventos. Cada definição de evento é relatada em umamensagem de rede interna separada e é governada por regras de snapshotassociadas com o indicador de MMP de 28 da figura 4. A definição de eventocontém a informação especificada a cerca do evento em Criar Evento Numérico.
<table>table see original document page 51</column></row><table>Operadores de eventos associados com o Byte 8 do pacote deaplicação acima são discutidos em mais detalhes em seguida a esta seção depacotes de aplicação exemplificativos e são mostrados na tabela que denotaoperadores de eventos disponíveis, quando da criação de um evento de basenumérica.
O pacote de aplicação a seguir representa uma mensagemdireta da arquitetura de software 10 para um cliente para publicar dados deeventos de bytes (Publicar Dados de Eventos de Bytes) e é resposta paraObter Dados de Eventos. Cada definição de evento é relatada em umamensagem de rede interna separada e será governada pelas regras de snapshotassociadas com o indicador de MMP de 28 da figura 4. A definição de eventocontém a informação especificada a cerca do evento em Criação de Evento de Byte.
<table>table see original document page 52</column></row><table>
Operadores de eventos associados com Byte 8 do pacote deaplicação acima são discutidos em mais detalhes em seguida a esta seção depacotes de aplicação exemplificativos e são mostrados na tabela que denotaoperadores de eventos disponíveis quando da criação de um evento baseadoem byte.
O pacote de aplicação a seguir representa uma mensagemdireta de um cliente para a arquitetura de software 10 para criar um eventonumérico remoto (Criar Evento Numérico Remoto). A mensagem permite aocliente ou outro módulo no sistema embutido para configurar variáveis derealimentação associadas com uma API e um Op Code existentes usando ummapa de variáveis embutidos. Embora o número possa ser 4 bytes, o valor demudança é limitado a 2 bytes. A figura 26B ilustra o mapa variável embutido.A figura 27 define a interação entre 3 nós de rede, onde o Nó A cria, comsucesso, um Evento Numérico Remoto no Nó Β. E onde o Nó C tenta omesmo, mas através da interação com o Nó B, é capaz de realizar o intento dasolicitação, sem duplicação do Identificador (API Id e Op Code). Isso érealizado porque o Nó C é capaz de consultar o Nó B para o endereço namemória do Identificador inicial de modo que um Identificador alternativo(não duplicado) pode ser selecionado. O identificador alternativo é, então,usado para criar o Evento Numérico Remoto pelo envio (veja mensagem 8 nafigura 27) uma nova mensagem para o Nó B com o endereço de memóriaoriginal e o Identificador alternativo.
<table>table see original document page 53</column></row><table>
A figura 26B ilustra o mapa de variáveis embutido. A figura27 define a interação entre 3 nós de rede, onde o Nó A cria, com sucesso, umEvento Numérico Remoto no Nó Β. E onde o Nó C tenta o mesmo, masatravés da interação com o Nó B, é capaz de realizar o intento da solicitaçãosem duplicação do Identificador (API Id e Op Code). Isso é realizado porqueo Nó C é capaz de consultar o Nó B para o endereço na memória doidentificador inicial, de modo que um Identificador alternativo (nãoduplicado) pode ser selecionado. O identificador alternativo é, então, usadopara criar o Evento Numérico Remoto pelo envio (veja mensagem 8 na figura27) de uma nova mensagem para o Nó B com o endereço de memória originale o identificador alternativo.
O pacote de aplicação a seguir representa uma mensagemdireta de um cliente para a arquitetura de software 10 para criar um evento debyte remoto (Criar Evento de Byte Remoto). A mensagem permite ao clienteou outro módulo no sistema embutido configurar variáveis de realimentaçãoassociadas com uma API e Op Code existente, usando um mapa de variáveisembutido.<table>table see original document page 54</column></row><table>
A figura 26B ilustra o mapa de variáveis embutido. A figura27 define a interação entre 3 nós de rede onde Nó A cria, com sucesso, umEvento de Byte Remoto no Nó Β. E onde o Nó C tenta o mesmo, mas atravésda interação com o Nó B, é capaz de realizar o intento da solicitação semduplicação do Identificador (API Id e Op Code). Isso é realizado porque o NóC é capaz de consultar o Nó B para o endereço na memória do identificadorinicial, de modo que um Identificador alternativo (não duplicado) pode serselecionado. O identificador alternativo é, então, usado para criar o Evento deByte Remoto pelo envio (veja mensagem 8 na figura 27) de uma novamensagem para o Nó B com o endereço de memória original e o identificadoralternativo.
O pacote de aplicação a seguir representa uma mensagemdireta de um cliente para a arquitetura de software 10 para obter dadosremotos de variáveis de um mapa de variáveis embutido (Obter DadosRemotos de Variáveis). A mensagem instrui a arquitetura de software parapublicar informação referente aos dados que existem no mapa de variáveisembutido. Veja a figura para um exemplo de uso desse comando.
<table>table see original document page 54</column></row><table>
O pacote de aplicação a seguir representa uma mensagemdirigida da arquitetura de software 10 para um cliente para publicar dados devariáveis remotos (Publicar Dados Remotos de Variáveis) e é uma respostapara Obter Dados Remotos de Variáveis. Ele relata dados do mapa devariáveis embutido, como API, Op Code, tamanho e endereço.
<table>table see original document page 54</column></row><table>API de Descoberta Núcleo: APIID = 3 (Tipo 3, Versão 1).
Fazendo referência à figura 6, o pacote de aplicação a seguir representa umamensagem de difusão de difusão de um cliente para encontrar nós daarquitetura de software 10 (Encontrar Nó(s)). Essa mensagem de difusãopermite a um nó localizar outros nós da arquitetura de software 10.
<table>table see original document page 55</column></row><table> O pacote de aplicação a seguir representa uma mensagem dedifusão (Publicar Nó) da arquitetura de software 10 permitindo-lhe publicarsua presença para outros componentes participantes em 14. Essa mensagem éenviada quando um nó da arquitetura de software 10 inicia ou é reajustado oué enviado como uma resposta para Encontrar Nós. Adicionalmente, essamensagem pode ser enviada quando o nó da arquitetura de software 10através de um processo secundário de Discovery se soma a uma API ouadiciona Op Codes a uma API existente. Publicar Nó não é enviado, quandoum cliente adiciona, dinamicamente, uma API ou Op Code à arquitetura desoftware 10 (via DAQ Op 1, 2, 12, 13). A carga útil da mensagem derealimentação contém uma senha de barreira de proteção, que deve ser usadapelo aspecto de segurança de barreira de proteção da arquitetura de software10 (veja a figura 31 para um exemplo desse aspecto). Isso permite aoremetente da mensagem tornar-se um nó 'confiável' na rede 14.
<table>table see original document page 55</column></row><table>
O pacote de aplicação a seguir representa uma mensagem quepode ser direta ou difundida de um cliente para a arquitetura de software 10para obter API(s) (Get APIs) da arquitetura de software 10. Essa mensagemdireta permite ao cliente descobrir as APIs que são suportadas por um nóespecífico da arquitetura de software 10. O Id de API deve ser único dentro deum aparelho.
<table>table see original document page 55</column></row><table>
O pacote de aplicação a seguir representa uma mensagem dedifusão da arquitetura de software 10 para um cliente para publicação deAPI(s) (Publicar API(s)) da arquitetura de software 10. Essa mensagem é umaresposta para Obter API(s) e é uma mensagem direta que permite ao clientedescobrir as APIs que são suportadas pelo nó de envio da arquitetura desoftware 10.
<table>table see original document page 56</column></row><table>
O pacote de aplicação a seguir representa uma mensagem quepode ser direta ou difundida de um cliente para a arquitetura de software 10para obter informação de API (Obter Info de API). Essa mensagem diretapermite ao cliente descobrir informação de Versão e Tipo a cerca da(s) API(s)especificada(s).
<table>table see original document page 56</column></row><table>
O pacote de aplicação a seguir representa uma mensagemdireta da arquitetura de software 10 para um cliente para publicação deinformação de API (Publicar Info de API) e é uma resposta para Obter Info deAPI. Essa mensagem direta permite ao cliente descobrir informação deVersão e Tipo a cerca das API(s) especificada(s). Há um mensagem por API eas mensagens são delimitadas usando o indicador de MMP da figura 4.
<table>table see original document page 56</column></row><table>
Os bytes 4 e 5 representam um Tipo de API's que pode serusado. Como uma indicação de uma subclassificação específica de uma API.
O valor de Tipo pode ser usado para determinar compatibilidade entre sub-componentes (APIs). Os Bytes 6 e 7 representam uma Versão de API (de umTipo particular). Esse valor pode ser usado para indicar correções de bug oumudanças na funcionalidade. Como com o Tipo, ele permite uma verificaçãode compatibilidade de tempo de execução, que pode informar ao cliente se asversões são compatíveis. Alternativamente, Bytes 4-7 podem ser usados emconjunto com o Byte 3 para formar um identificador de classe de 5 bytes,onde classe se refere a uma definição de classe dentro de uma biblioteca declasses (alguém de competência típica com o estado da técnicacompreenderá). Usando a abordagem alternativa, Byte 3 (API Id) é ummanipulador de objeto em tempo de execução e Bytes 3-7 numericamenteconcatenados forma o id de classe.
As instâncias Numéricas associadas com o Byte 8 significampara o cliente que uma API tem múltiplas instâncias. O cliente podeacompanhar com Obter Info de Instância, que é descrito abaixo, paraencontrar os Ids de Instância que pertencem à API. Descr Char 1 - DescrChar η é um aspecto ótico que pode ser útil para programadores. O textodescritivo pode ser usado para explicar API Id. Por exemplo, 'superior' ou'inferir' poderia ser usado para as duas cavidades de um forno duplo.
O pacote de aplicação a seguir represente uma mensagemdireta de um cliente para a arquitetura de software 10 para obter informaçãode instância (Obter Info de Instância). Essa mensagem direta permite aocliente descobrir os Ids de Instância para as APIs que relatam mais de umaInstância de uma API. A primeira instância de qualquer API usa Id de APIcomo seu Id de Instância. Se há múltiplas Instâncias de um ID de API nomesmo nó endereçável, às instâncias subseqüentes são atribuídos Ids deInstância dinamicamente. Esses Ids atribuídos dinamicamente podem serdescobertos pelo envio da mensagem Obter Info de Instância. O valor do Idde Instância seria usado em lugar do Id de API, quando houver múltiplasinstâncias de uma API em um nó de rede física.
<table>table see original document page 57</column></row><table>
O pacote de aplicação a seguir represente uma mensagem dedifusão da arquitetura de software 10 para um cliente para publicarinformação de instância (Publicar Info de Instância) e é uma resposta paraObter Info de Instância. Essa mensagem direta permite ao cliente descobrir osIds de Instância. A primeira instância de qualquer API usa Id de API comoseu Id de Instância. Se houver múltiplas Instâncias de um Id de API nomesmo nó endereçável, às instâncias subseqüentes serão atribuídos um Id deInstância são comunicados através da mensagem de Publicar Info de API,dinamicamente. Esses Ids atribuídos dinamicamente são comunicados atravésda mensagem de Publicar Info de API descrita acima. Para fins deuniformidade, Publicar Info de API é enviada para a primeira instância (isto é,onde Id de API = Id de Instância). Haverá uma mensagem para Instância deaPI, que é delimitada usando o indicador de MMP. O valor de Id de Instânciaserá usado em lugar de Id de API, quando houver múltiplas instâncias de umaAPI em um nó de rede física.
<table>table see original document page 58</column></row><table>
De preferência, Descr Char 1 - Descr Char η permite aocliente associar um Id de Instância com sua função física. Por exemplo,'superior' ou 'inferior' poderia ser usado para as duas cavidades de um fornoduplo. Contudo, o usuário da arquitetura de software 10 pode usar Descr -Char 1 - Descr Char η para uma finalidade útil.
Core Debug API: API ID = 4 (Tipo 1, Versão 1). O pacotede aplicação a seguir representa uma mensagem de difusão da arquitetura desoftware 10 para um cliente para publicar saturação (Publicar Saturação). Asaturação acontece quando as camadas de suporte da rede interna 14 sãoincapazes de distribuir os dados que a arquitetura de software 10 colocou naPermite que as APIs sejam classificadas como sub-classe ou especializada. Por exemplo, APIID pode sereferir a uma API de máquina de lavar e Tipo pode especificar um modelo de lavadora particularAtiva controle de versão (isto é, correções de bugs ou mudanças na funcionalidade). Ativa uma verificaçãode compatibilidade de tempo de execução, que pode informar ao cliente se as versões são compatíveis.
Permite ao cliente associar Id de Instância com sua função física. Por exemplo, 'superior' ou 'inferior'poderia ser usado para as duas cavidades de um forno duplo.fila de saída de WIDE 14A. A arquitetura de software 10 não tem fila; se aWIDE 14A não pode servir aos dados de saída, então, a arquitetura desoftware 10 envia Publicar Saturação.
<table>table see original document page 59</column></row><table>
O pacote de aplicação representa uma mensagem direta de umcliente para a arquitetura de software 10 para ajuste de um registro parasaturação (Registrar Saturação). O cliente envia essa mensagem para um nóde arquitetura de software, que ativa a mensagem de Saturação. Apenas o nóque ativa saturação pode desativar saturação.
<table>table see original document page 59</column></row><table>
API de Baixo Nível: API ID = 5 (Tipo 1, Versão 1).
O pacote de aplicação a seguir representa uma mensagem dedifusão da arquitetura de software 10 para publicação de estado (PublicarEstado).
Essa mensagem enviada como um resultado de um estadointerno mudado da máquina resultante de progressões de ciclo normais,interações de usuário, Op Code 2 abaixo, ou outras mensagens recebidasatravés da rede 14.
<table>table see original document page 59</column></row><table>
Valores de enumeração de estado de máquina exemplificativossão apresentados na tabela a seguir. De acordo com umamodalidade da invenção, o estado de funcionamento é um poucoambíguo e variáveis de fase adicionais devem ser expostas de modoque a lógica de negócios do cliente pode ser escrita. Em umamodalidade alternativa, o estado de funcionamento é eliminado emfavor de uma máquina de estado definitiva e mais granular onde cadafase de cada estado é documentada, adequadamente. Nestamodalidade, espaço de endereço suficiente existe no byte para enumeraçõesadicionais.
<table>table see original document page 60</column></row><table>
O pacote de aplicação a seguir representa uma mensagemdireta de um cliente para a arquitetura de software 10 para segurar o ambientede operação de software 16 de aparelho eletrodoméstico 12 que governa oestado da figura 7 entre o Estado de Desenvolvimento e Inativo. ObserveEstado de Desenvolvimento não mostrado na figura 7, mas alguém comhabilidade comum na técnica pode considerar um estado de Desenvolvimento,que só pode ser introduzido de Inativo e quando sai volta para Inativo.
<table>table see original document page 60</column></row><table>
API de Compressão de tecla de Núcleo: APIID = 6 (Tipo 1,Versão 1). O pacote de aplicação a seguir representa uma mensagem direta deum cliente para a arquitetura de software 10 para comprimir uma tecla(compressão de tecla). Essa mensagem direta permite ao cliente enviarcompressões de tecla virtuais. Indexes de teclas não são descobríveis devido àtécnicas de codificação usadas no processador embutido; portanto, índices deteclas podem ser extraídos dos arquivos de código fonte, manualmente ouatravés de outros mecanismos automatizados.
<table>table see original document page 60</column></row><table>
O pacote de aplicação a seguir representa uma mensagemdifundida da arquitetura de software 10 para um cliente para publicação decompressão de tecla (Publicar compressão de tecla).
<table>table see original document page 60</column></row><table>Valores de enumeração de índices de compressões de teclasexemplificativos são apresentados na tabela a seguir.
<table>table see original document page 61</column></row><table>
API de Memória/ Porta: ID de API = 7 (Tipo 3, Versão 1).
O pacote de aplicação a seguir representa uma mensagem direta de um clientepara a arquitetura de software 10 para escrita na memória (EscreverMemória). A API de porta de Memória/ Porta é ativada através do Estado deDesenvolvimento da figura 3 e a interação associada é similar à associaçãopreviamente descrita entre Estado de Desenvolvimento da figura 3 e a API deNível Baixo (ID de API = 7).
Essa mensagem direta permite ao cliente escrever em umalocalização de RAM especificada. A escrita na localização de RAMespecificada está limitada a um único pacote. Na modalidade corrente, esseseria o de 13 bytes mostrado em 28A de 28. MMP (de 28) = 1 não é válidopara essa mensagem.
<table>table see original document page 61</column></row><table>
O pacote de aplicação a seguir representa uma mensagemdireta de um cliente para a arquitetura de software 10 para escrever memóriade EE (Escrever EE). A escrita em uma localização de EE especificada estálimitada a um único pacote. Na modalidade corrente, esta será de 13 bytes,mostrada em 28A de 28. MMP (de 28) = 1 não é válido para essa mensagem.
Porta de Memória
<table>table see original document page 61</column></row><table>
API de Variável de Interrogação: API ID = 10 (Tipo 1,Versão 1). Fazendo referência à figura 5, o pacote de aplicação a seguirrepresenta uma mensagem direta de um cliente para a arquitetura de software10 para a leitura de variáveis de interrogação (Ler Variável(eis) deInterrogação). Essa mensagem instrui a arquitetura de software 10 paraenviar uma mensagem de Publicar Variável de Interrogação, que é mostradaabaixo, para variáveis de interrogação apenas. As variáveis de interrogaçãopodem ter código fixo feito por um programador para uma aplicaçãoespecífica e podem ser usadas, se os recursos de RAM/ROM não permitem ouso de DAQ APL.
<table>table see original document page 62</column></row><table>
O pacote de aplicação a seguir representa uma mensagemdireta da arquitetura de software 10 para um cliente para publicar variáveis deinterrogação (Publicar Variável de Interrogação) e é uma resposta para LerVariável(eis) de Interrogação. Há uma mensagem por índice de variáveis deinterrogação, conforme especificado na mensagem de Ler Variável deInterrogação.
<table>table see original document page 62</column></row><table>
Uma nota nos operadores de eventos, discutidos na seção de
DAQ API acima. O Byte 9 da mensagem Criar Evento Numérico e Byte(DAQ API opcodes 1 & 2) e Byte 5 de CreateNumRemoteEvent eCreateByteRemoteEvent (DAQ API op codes 12 & 13) são o operador demudança de eventos, mostrado na NVOEventStructure da figura 33.Operadores são instruções que descreve para a arquitetura de software 10 acondição matemática em que a arquitetura de software 10 gerará umamensagem de evento. A tabela abaixo descreve exemplos de operadores deeventos. Os argumentos para operadores de eventos são dependentes do tipode evento que está sendo criado (baseado em numéricos ou baseado em bytes,que são op codes 1 e 2, respectivamente).
Operadores de eventos são parte da DAQ API, que tem duasvariações: básica (Tipo 1) e estendida (Tipo 2). Observe a quinta coluna natabela, que denota a disponibilidade de cada Operador de Evento para apluralidade de revisões (4) da DAQ API. Note que os Tipos 1 & 2 sãodepreciados e as modalidades preferidas são o Tipo Básico 3 ou o TipoEstendido 4, que é inclusivo de funcionalidade do Tipo 3.
A tabela a seguir denota os operadores de eventos disponíveisquando da criação de um evento baseado em numérico (API BD 2, Op Code 1 e 12):
<table>table see original document page 63</column></row><table>
A tabela a seguir denota os operadores de eventos disponíveisquando da criação de um evento baseado em número (API ID 2, Op Code 1 e 12):
<table>table see original document page 63</column></row><table>O operador de BIND permite ao cliente 16 criar múltiploseventos de memória a partir de um disparo de evento único. Em outraspalavras, uma vez que um ID de Evento tenha sido atribuído, eventossubseqüentes podem ser criados os quais, automaticamente, serão enviados,quando o evento mestre original for disparado.
Quando um evento baseado em bytes (op code = 3) forpreparado com o operador On Change, um valor de 255 no byte 9 instruirá aarquitetura de software 10 a fazer uma detecção de mudança para todos osbytes na faixa especificada pelos argumentos de endereço e de tamanho.
O operador Bit Mask (Máscara de Bits) permite a capacidadede observar transições de bits dentro de um byte. O valor da máscara seráestabelecido de modo que bit = 1 é um 'preocupar-se com' e bit = 0 é 'não sepreocupar com'. Quando estabelecido em 'não se preocupar', uma transição devalor naquela localização de bit resultará em um evento gerado.
A arquitetura de software 10 não proporciona uma soluçãoexplícita para sincronização de tempo, mas proporciona um mecanismo depermissão. A capacidade do cliente remoto 16, 22 criar um evento que éperiodicamente difundido permite ao cliente remoto 16, 22 manter uma horade day clock (relógio eletrônico de 24 horas) que é sincronizada com oaparelho. Uma vez que a arquitetura de software 10 pode não exporexplicitamente uma hora da API de day clock, o cliente 16, 22 pode ter oendereço na memória onde a hora do dia é armazenada.
O núcleo da arquitetura de software 10 tem diversasconsiderações de desenhos que podem ser consideradas e vistas para criarmodalidades alternativas da invenção aqui descrita.
Os itens a seguir podem ser considerados quando dadeterminação de modalidades alternativas da implementação de núcleo daarquitetura de software 10:
• Arquitetura de Mensagem• Estrutura de Carga Útil ou Tamanho de Mensagem
• Verificação de Integridade de Mensagem de Múltiplas Cargas Úteis
• Mensagens de Ciência de Estado
• Versão - Descoberta de API
• Integridade de Conexão
• Controle de Tráfego (Fluxo) e Mensagens Reconhecidas
o Entrada Inválida
o Entrada Válida
o Saída
o Condição de Inicialização
• Integridade de Estado
• Compressões de tecla vs. API Lógica
• Rede de Múltiplos Nós
o Múltiplos Nós
o Múltiplos Clientes
o Múltiplas implementações de API na mesma rede
o Múltiplas implementações de API no mesmo nó de rede
o API(s) usando os mesmos op codes - Namespace
o atribuição de SAP
o descoberta de SAP
Arquitetura de Mensagem
Arquitetura da mensagem é um elemento de desenho primáriocuja a solução tem muitas conseqüências de desenho dependentes. Oprotocolo 28 da rede de comunicação interna 14 proporciona novaspossibilidades para a arquitetura da mensagem acionada por eventos,conforme oposto às redes anteriores. Um elemento a considerar é se os nósinterrogarão um ao outro, caso eles registrem para mensagem de notificação.
A interrogação é uma prática de nós que enviam mensagemperiodicamente para os proprietários de dados solicitando valores atualizados(por exemplo, solicitam dados continuamente a cada 100 ms). Em geral, ainterrogação é mais simples de implementar e usada mais comumente e podemanter integridade conexão verificada com cada solicitação. Com tudo,quando da interrogação, o cliente deve pedir informação continuamente. Alargura de banda de rede é usada até com dados que não estão mudando (alargura de banda é a quantidade de dados que podem ser passados ao longo deum canal de comunicação em dado período de tempo e a diversos fatores queefetuam largura de banda, tais como: número de nós em uma rede, afreqüência de transmissão [taxa de Bauds] e o tempo de excesso de protocolo[CRCs, reconhecimentos, IDs de fonte/destino, etc], o hardware de protocolode transporte e cabeamento regulam o limites de largura de banda, porém, oprotocolo de Aplicação tem a responsabilidade de tornar mais eficiente o usoda largura de banda disponível). As arquiteturas de interrogação não fazemescalas: à medida que os nós aumentam o número de mensagens aumentaexponencialmente. Supondo que aja informação sobre cada nó que todosoutros nós precisam: mensagens = nA2-n. Os dados, tipicamente não estãosincronizados com a memória do controle e latência da mensagem pode sertanto quanto duas vezes a taxa de interrogação.
A criação de eventos é uma pratica de nós em registro com osproprietários dos dados para serem notificados sobre certas condições comnovo valor de dados. O proprietário dos dados é, então, responsável porenviar uma mensagem para os nós de observação, quando os dados satisfazemos critérios especificados originalmente durante o registro (por exemplo,enviar dados apenas quando os dados mudam) em modelo de criação deeventos, o uso da largura de banda é otimizado porque os dados são enviadosapenas quando eles mudam. Esse modelo faz uma boa escala com tráfego demensagens e minimiza a latência. Os dados são sincronizados com o controle.Com tudo uma validação de conexão (indicação de atividade) é necessária.Caso contrário, um cliente pode não saber quando uma fonte de eventos estáfora de linha. Alternativamente, a validação de conexão em modelo de criaçãode eventos pode ser obtida usando-se reconhecimentos que são umamensagem adicional transmitida do observador de eventos de volta para afonte de eventos. Quando a fonte de eventos transmite uma mensagem deevento, a fonte de eventos não considerará que a transação esteja completa atéque uma mensagem de reconhecimento seja recebida. Após um tempo deespera que tenha expirado, a fonte de eventos pode retransmitir o evento. Esseprocesso pode se repetir por um número configurável de tentativas detransmissão de eventos reconhecidas.
Em arquiteturas de criação de eventos, ligação de mensagensda figura 9 e regulada por MMP de 28 pode ser necessária. E um mecanismopara agrupar eventos que foram gerados da mesma 'varredura' do micro-controlador.
Nesse caso, a modalidade preferida é um modelo de criação deeventos uma vez que a criação de eventos tem vantagens relacionadas acima,bem como a simplicidade dos remédios que direcionam as desvantagens dacriação de eventos. A validação de conexão é endereçada pelo uso de um sinalde atividade e/ou eventos reconhecidos. Quando o sinal de atividade é usado,a fonte de eventos enviará um evento periodicamente de modo que todos oscontroladores de eventos daquele nó podem saber que a fonte de eventos estáboa. Igualmente, a implementação do sinal de atividade de modo que suafreqüência seja programável também pode ser usada para notificar a todos osassinantes de eventos que a fonte de eventos é boa. O período de sinal deatividade é configurável na rede. Eventos Reconhecidos que são descritosaqui em detalhes são um método alternativo que pode ser usado além do sinalde atividade ou sinal de atividade programável para assegurar a integridade daconexão. A ligação de mensagem é endereçada com o bit de limite demensagem na carga útil de cada pacote de mensagem 28. Isso permite aoorientador da arquitetura de software 10 coletar mensagens correspondentes àmesma varredura de micro-controlador e apresentar aqueles à camada deaplicação como um todo.
Usando um sub-componente da invenção conhecido comoDAQ 30, a arquitetura de software permite a um cliente 16 registrardinamicamente com componentes de controle de aparelho 16 (ativados com aarquitetura de software 10 e incluindo o sub-componente opcional daarquitetura de software DAQ 30) através da rede de comunicação interna 14para receber notificação quando o valor em uma localização de memóriaespecificada muda em relação ao uma condição especificada. Isso libera ocontrole de aparelho 16 de ter variáveis de realimentação de código fixo epermite que a realimentação em tempo real mude de acordo com a aplicação,sem interrogação do cliente (atualizações baseadas em eventos são difundidasprecisamente, conforme necessário).
Um heap de memória dinâmica da figura 33, isto é, memóriareservada para mensagens de realimentação configuráveis por tempo deexecução, empregada em que tamanho do heap é configurável em tempo decompilação. Foi verificado que cada variável de evento de alimentação requercerca de 10 bytes de RAM. Os eventos registrados na heap (NYOEvent dafigura 33) podem ser adicionados ou restaurados através de comandos da redede comunicação interna 14 emitidos pelo cliente para um componente ativadopela arquitetura de software tendo também instalado o sub-componenteopcional DAQ 30.
Estrutura de carga útil 29 A
Uma estrutura de carga útil de evento é uma carga útil decomposto estático que consiste do agrupamento de múltiplas variáveis (nomomento do desenho) de modo que o cliente pode, com uma transação, enviarum comando completo para, ou receber o estado completo de, umcomponente dentro do aparelho 12. Em caso de um comando, o cliente podenão ter a intenção de mudar cada variável em uma carga útil, por tanto, umaatualização de estado de pré-requisito é requerida para povoar a carga útil decomando como um estado corrente para aquelas variáveis que não sãodestinadas a mudar. Além disso, as variáveis que mudam podem não mapeardiretamente em uma definição de carga útil única, resultando em múltiplasmensagens contendo dados dispersos mudados e não mudados.
Em uma estrutura de carga útil simples, só pode existir umavariável em uma carga útil. Essa tem uma implementação mais simples, maisfácil que podem se aproximar de uma carga útil de composto dinâmico(descrito abaixo). Contudo, a largura de banda não é otimizada por causa deuma relação maior de estouro de mensagens para dados e ligação demensagens necessárias visto que as variáveis são enviadas separadamente.
Em estrutura de carga útil composta dinâmica as cargas úteisnão são definidas estaticamente no momento do desenho, mas são criadasdinamicamente pelo nó de envio. Nesse caso, o comprimento é determinadopelos dados que o remetente deseja enviar e, além disso, deve incluiridentificadores e, possivelmente, delimitadores na carga útil, o que permitiráao analisador de recebimentos não preparar as partes componentes da cargaútil. Para reiterar, o nó de recebimento deve ter um analisador sofisticado obastante para separar as cargas úteis multi-variáveis em suas partescomponentes. Essa estrutura de carga útil utiliza a largura de banda, mas podeaumentar a exigência de ROM devido à sofisticação requerida peloanalisador. Há também algum estouro adicionado ao protocolo de aplicaçãouma vez que a carga útil dinâmica de composto deve envolver comprimentosde op code como parte de mensagens, requer analise adicional pelocomponente de recebimento e pode difícil de compreender e implementar.
É uma modalidade preferida da presente invenção empregaruma estrutura simples de carga útil para o protocolo de aplicação. Acomplexidade de uma carga útil dinâmica de composto pode ter dificuldadesem uma analise de custo-benefício para as mensagens empregadas naarquitetura de software 10. Para maximizar o uso da arquitetura de software105 a complexidade da interface, de preferência, será minimizada. Através deuso de cargas úteis de compostos, por sua natureza complexa, potencialmente,retardarão o uso arquitetura de software 10, especialmente com clientesembutidos. As cargas úteis simples são uma boa aproximação de cargas úteisde compostos dinâmicos mesmo que possa haver estouro de mensagemadicional (isto é, há cinco bytes de estouro para cada mensagem da rede decomunicação interna 14). Há uma adicional de dois bytes de estouro parasuportar o protocolo 28 da arquitetura de software 10. Isso deixa trezes bytespara o protocolo de mensagem 24 da rede de comunicação interna 14 paradados em algumas condições específicas de aplicação. O uso de uma cargaútil estática de composto pode ser inflexível e cheio de desperdícios.
A ligação de mensagem da figura 9 é endereçada com o uso dobit de MMP na carga útil de cada pacote de mensagem. Isso permite que oorientador da arquitetura de software 10 colete as mensagens.Correspondendo à mesma varredura de micro-controlador e apresente aquelaspara a camada de apresentação como um todo.
Comando de Ciência de Estado
Em relação a uma interface de usuário para um aparelho 12, oaparelho 12 atua como uma máquina de estado. A medida que as teclas sãocomprimidas a máquina de estado faz a transição de um estado para o outro.Para cada estado, é conhecido que as teclas são candidatas válidas para ainclusão seguinte.
De um modo geral, quando uma tecla é comprimida que éinvalida, o aparelho 12 produzirá audível para indicar ao usuário que oAparelho estava em um estado impróprio para aquela tecla. O mesmoconceito existe para o cliente externo que deseja enviar comandos válidos,embora esse cliente possa não enviar compressão de tecla.
Em geral, dois tipos de máquinas de estado são desenvolvidospara um controle de aparelho: a máquina de estado de keypress (compressãode teclas) (conforme mencionado acima) em uma máquina de estado deprocesso. Um exemplo de uma máquina de estado de processo típica émostrada na figura 7.
A figura 7 é uma ilustração esquemática ilustrando váriosestados de um aparelho eletro-doméstico 12, tal como uma lavadora mostrada,pelo exemplo na figura 7 e a interação da arquitetura de software 10 atravésde vários estados 32 e um modo de erro de falha 34. Os vários estados 32 dalavadora de exemplo são mostrados na figura como inativa, lavando,centrifugando e pausa. Outros estados para esse aparelho 12 de exemplo, bemcomo estados para aparelhos diferentes 12 são considerados e o exemplomostrado na figura 7 será exemplificativamente apenas.
Os estados da máquina de estado de processo podem serrelatados para o cliente externo 16. Contudo, mediante inspeção, pode servisto que a máquina de estado de processo na figura 7 não endereça eventosde todas as entradas de usuário possíveis (isto é, ajuste de relógio, seleção develocidade de giro, opção de tamanho de carga, etc). Em geral, a lógica nocontrole do aparelho tem uma outra cláusula final que lida com todos osoutros casos que não foram pré-defmidos.
Supondo que é desejável para o cliente 16 compreender asregras que governam as transições de estado do controle de modo que possaevitar o envio de comandos inválido. Levando-se em conta o fato de que ocliente 16 não estará enviando compressões de tecla, o projetista devecompreender que não há documento ou estrutura de dados disponível,permitindo a validação do lado do cliente (isto é, validação antes que asolicitação seja enviada). Eventualmente, isso pode levar às aplicações docliente que têm a probabilidade de enviar um comando que o componente derecebimento não executará devido a sua lógica de validação, que está baseadano estado exemplificativo da figura 7.A solução pode ter um efeito não só sobre o uso da largura debanda, mas também para a força global e a satisfação do usuário final daaplicação. De uma perspectiva da largura de banda, pode ser dito que umamensagem não resultante na ação desejada, mas antes, um código de erro ourecuperação é um desperdício de largura de banda (supondo que poderia serimpedido). De uma perspectiva da satisfação do usuário, aplicações queimpedem o usuário de cometer erros são, em geral, considerados mais"amigas do usuário" do que aquelas que permitem ao usuário cometer erro e,então, usar as caixas de diálogo para explicar o que aconteceu.
Várias modalidades de comandos de estado apropriados foramconsideradas de acordo com a presente invenção.
Com o uso de uma seção de regras codificadas pelo cliente,um subconjunto de informação de estado é usado para desenvolver lógica decaso ou uma emulação do estado do controle com a finalidade de impedirsolicitações inválidas. Esse modelo, tipicamente, não impõe mudança sobre aarquitetura de controle, mas pode ter o cliente e o controle pode, facilmente,ficar fora de sincronização. As regras e o desenvolvimento da lógica podemestar baseados em tentativa e erro (por exemplo, codificar, testar, recodificar).Um desenho de cliente rapidamente evolverá, criando código proceduralpobremente projetado.
Usando um modelo de dados de API baseado em estado dedesenho de tempo, um modelo de dados é desenvolvido de modo que o clientepode interpretá-lo e impedir solicitações inválidas. Em essência, é umacorrelação entre estado e op codes válidos (op codes são identificadores demensagens). A vantagem para isso é que o criador do Op Code ou APItambém é responsável pela publicação da invenção para o criador do cliente(no momento do desenho), permitindo ao projetista emular a máquina deestado no cliente. Essa máquina de estado emulada habilita a aplicação decliente de enviar solicitações inválidas. É necessário que o controle exponhacada estado definido no modelo de dados de API. O modelo de dados demomento de desenho requer que o criador do controle seja responsável pelacomunicação de regras de estado governando o uso de Op Code. O cliente e ocontrole podem sair facilmente de sincronização porque os dados não estãodisponíveis no tempo de execução. Um documento deve ser criado o qualreflete o código como escrito. Esse documento deve ser mantido e publicado.O documento deve ser analisado ou convertido em lógica do lado do cliente eisso não funciona o tempo todo. O estado do aparelho pode mudar apenas àmedida que um comando está sendo enviado, resultando em um comandoinválido.
Usando um modelo de dados de API com base em estado emtempo de execução, essa solução é idêntica à anterior, com a exceção que omodelo de dados não é compartilhado entre criadores no momento dodesenho, mas entre o cliente e o controle no momento da execução. Algumasmensagens adicionais são requeridos para esses dados serem comunicados docontrole. No modelo de dados de tempo de execução, o criador de controlepode ser responsável pela comunicação das regras de estado que governam ouso de Op Code. Um cliente pode descobrir no tempo de execução a definiçãode correlação de Op Code/ Estado. O cliente e o controle estão sempre emsincronização e as atividades do cliente e do criador são otimizadas -nenhuma translação manual para/ de um documento. Código adicional (ROM)(escrito uma vez) requerido para preparar e não preparar a definição decorrelação de Op Code/ Estado. Uma largura de banda de rede requerida paratransmissão de dados e uma latência de partida como um resultado detransmissão de dados. Isso não funciona o tempo todo. O Estado pode mudarà medida que um comando está sendo enviado, resultando em um comandoinválido.
Usando um modelo de enumeração de reconhecimento de pós-comando, as três opções acima têm a meta de impedir o comando de seremitido pelo cliente para controle no estado inválido. Essa solução não tentaessa apropriação. Ao contrário, essa técnica permite à aplicação do clienteenviar qualquer comando em qualquer momento. Se o comando for inválido,um reconhecimento ocorrerá de modo que o cliente pode empreender a açãoapropriada. Esse reconhecimento pode ou não incluir um código de razãoenumerado. Em um modelo de código de razão de pós-comando, não hámudança imposta sobre a arquitetura de controle, mas é mais provável que umcliente envie comandos que serão rejeitados. O criador do cliente devedesenhar uma estratégia para lidar com o reconhecimento da rejeição e aexperiência do usuário final pode não ser tão agradável devido à freqüência demensagens de comando rejeitadas.
Usando um modelo de análise de código fonte e convenção denomeação de tempo de desenho, que é uma combinação dos modelos dedados de desenho e tempo de execução, isso tem o menor impacto sobre aestrutura do código embutido, igualmente, distribui a funcionalidade de tempode execução desejada. E realizado pela criação de um analisador de lado docliente, que pode analisar o código fonte embutido e determinar a variável aser monitorada para cada Op Code externo. As exigências para essa soluçãosão: (1) cada comando externo não diagnóstico (Op Code) terá uma únicavariável booleana associada, que representa o estado de permissão requeridopara a execução; e (2) uma convenção de nomeação é usada de modo que umanalisador pode se associar cada variável de permissão para o Op Codeexterno correspondente. Em um modelo de análise de código fonte, o criadorde controle é responsável pela comunicação de regras de estado quegovernam o uso de Op Code. Um cliente 16 pode descobrir em tempo deexecução a versão adequada pendente de definição de correlação de Op Code/Estado e o cliente e o controle estão sempre em sincronização com a versãoadequada. O documento de referência extra não é necessário, porém, hámudanças não triviais na prática de codificação, na lógica adicional a serexecutada a cada varredura, pequenas RAM e ROM adicionais requeridas eapenas clientes sofisticados são capazes de analisar código fonte.
Usando um modelo de cliente de aprendizagem, essa soluçãonão requer mudança no sistema embutido. Nesse caso, o cliente "aprenderá"após cada comando rejeitado e construirá um mapa de permissão de lado decliente que poderia, com o tempo, obter o comportamento de tempo deexecução desejado. Em um modelo de cliente de aprendizagem, não hámudança imposta sobre a arquitetura de controle, porém, isso supõe que asvariáveis de estado corretas estão sendo avaliadas no momento da rejeição. Senenhuma variável de estado está sendo observada, então, o cliente não podeaprender o que causou a rejeição.
Foi verificado que diversas dessas opções são modalidadespreferidas. Por enquanto, uma modalidade preferida principal é o modelo dedados de API de tempo de execução. Um beneficiário exemplifícativo dessedesenho será a aplicação de controle doméstica. O modelo, porém, requerdesenho embutido adicional. E como o ambiente comercial corrente não criauma exigência para essa modalidade, o reconhecimento pós-comando éadotado até o momento em que o custo - benefício de adoção do modelo dedados de API de tempo de execução (também referenciado como Agente deTaxonomia) se torna favorável.
Um dos desafios da arquitetura de software 10 é proporcionarfuncionalidade sem impactar o esquema de produção do aparelho 12. Aarquitetura de software 10 pode implementar um modelo de solicitaçãoreconhecido. NVORecipeStatus (APIID = 1, Op Code = 1) é uma mensagemde reconhecimento preferida que a arquitetura de software 10 envia após cadamensagem recebida.
Descoberta - Versão de API da Figura 6
Embora o núcleo da arquitetura de software 10 sejaindependente de qualquer API, sua finalidade para a arquitetura de software10 é expor múltiplas APIs. E realístico esperar que as APIs serãocontinuamente adicionadas à arquitetura de software com o tempo. Naantecipação disso, consideração para descoberta e versão de API é feita.
Também é concebível que à medida que as aplicaçõesarquitetura de software 10 crescem, os recursos de microprocessador nãoserão suficientes para suportar todas as APIs e funções da arquitetura desoftware 10, simultaneamente. Com o uso de diretivas do compilador, aarquitetura de software 10 pode ser configurada de modo que as APIsaparecerão e reaparecerão para o mesmo modelo durante a duração damáquina.
A descoberta é uma chave para o sucesso de longo alcance daarquitetura de software 10. Uma finalidade fundamental da arquitetura desoftware 10 é atuar como intermediário entre o cliente 16 e o componente decontrole 16. Dado o cenário descrito abaixo, será necessário que os clientes 16consultem o controle para descobrir o que são as capacidades correntes. Secertas capacidades não estiverem presentes (isto é, decisão de tempo decompilação), é desejável que a aplicação seja capaz de falhar graciosamente ecomunicar ao usuário que o suporte para aplicação não está compiladocorrentemente no software de controle de aparelho.
Pode haver dúzias de implementações de cliente e dúzias deAPIs específicas de plataforma e de plataforma transversal. Diretivas docompilador podem ser desenvolvidas para incluir ou excluir certas funções daarquitetura de software 10. Pode não haver espaço no controle para todas asfunções possíveis da arquitetura de software 10 existirem nomicroprocessador, simultaneamente.
Várias modalidades da invenção aqui descrita referentes aosmétodos de versão e descoberta de APIs são consideradas, sem afastamentodo escopo da presente invenção.
Usando um modelo de descoberta baseado em número demodelo, o cliente é responsável por compreender as capacidades do controle.Isso pode ser feito usando estruturas de dados baseadas em clientes, bases dedados remotas ou veículos de distribuição de código de tempo de execução,como OSGi, que incluem toda a informação relevante sobre um número demodelo particular para um aparelho 12. Em um modelo de descoberta baseadoem número de modelo, não há exigência adicional sobre o controle doaparelho. Contudo, um número de modelo não é, tipicamente, atribuído nocomeço de um ciclo de desenvolvimento de produto, assim, não estádisponível em desenvolvimento de software inicial. Números de modelopodem ser mudados devido aos esquemas de cores, marcação e outros fatoresirrelevantes. APIs diferentes podem ser residentes no mesmo modelo devidoàs diretivas de compilador. Pode ser requerido que o cliente seja responsávelpela aquisição de definição de capacidades ou código equivalente após adescoberta.
Usando um modelo de descoberta baseado em ID de API, adescoberta baseada em API não conta em absoluto com o número de modelo,mas antes define qualquer produto como uma coleção de interfaces bemdefinidas. Essa técnica permite que as mesmas APIs sejam residentes emmúltiplos produtos resultando na mesma reutilização. Em um modelo dedescoberta baseado em ID de API, a referência ao ID de API compensa asdesvantagens de uma abordagem baseada em número de modelo. Essemodelo permite que múltiplos produtos compartilhem algumas diretivas decompilador e as mesmas definições de API e pode promover reutilização desub-função da arquitetura de software 10. Contudo, o cliente pode serresponsável pela aquisição de definição de capacidades ou código equivalenteapós a descoberta, estouro de gerenciamento adicional pode ser requeridopara manter e atribuir APIs únicas e recursos adicionais de ummicroprocessador de controle podem ser requeridos para suportar Op Codesde descoberta (isto é, mensagens adicionais).Usando um modelo de descoberta de capacidades (tambémreferenciado como um Agente de Taxonomia), esse modelo aceita Descobertade API como uma etapa adicional. Além do ID de uma API5 o cliente tambémsolicitará e obterá a definição de dados correspondente àquela da API. Emoutras palavras, o cliente descobrirá cada chamada de função, cada um dosargumentos de chamadas de funções e todos os valores válidos para cadaargumento. No modelo de descoberta de capacidades, nenhuma buscasecundária é requerida para adquirir definição de capacidade. Esse modeloaborda um conceito de UPnP ou tipo Serviço da Web e estabelece a base paraa conversão em interfaces de usuário de tela de LCD que podem ser acionadaspor dados. Contudo, esse conceito pode ser deficiente em custo, quandoaplicado aos teclados mecânicos de margem baixa e atuadores. E, para tirarvantagem· dessa técnica, o cliente 16 deve desenvolver um intérprete para adefinição de capacidades, que pode requerer esforço de modelagem maisintenso pelo criador de sub-função de arquitetura de software 10 esignificativamente mais recursos do microprocessador de controle.
Foi verificado que, no momento em que esta aplicação foipreparada, um modelo de descoberta baseado em ID de API é umamodalidade preferida. Além do ID de API, cada API pode ter um tipo e umaversão, de modo que muitas permutações diferentes de uma API podemexistir através do tempo. Isso pode tornar o protocolo muito mais flexível (porexemplo, pode haver muitos tipos de APIs para um aparelho particular 12, talcomo um secador, bem como uma versão diferente de cada tipo: API deSecador, Tipo de Secador Horizontal, Versão 1).
A descoberta pode ser iniciada em um número de maneiras deacordo com a invenção. Na inicialização. Cada nó ativado com a arquiteturade software 10 difunde uma mensagem na rede de comunicação interna 14,chamada Publicar Nó.
Em segundo lugar, um nó, em qualquer momento, podedifundir uma mensagem na rede de comunicação interna 14, chamadaEncontrar Nós. Essa mensagem resultará em todos os nós respondendo comuma mensagem de Publicar Nó. Essa API é discutida em mais detalhes comrelação à figura 5 e à API de Descoberta.
Como a descoberta é uma chave para a arquitetura de software10, a versão é uma chave para descoberta bem sucedida. O mesmo raciocíniousado para justificar a descoberta de API pode ser aplicado à versão de API.A versão permite ao cliente encontrar mais informação a cerca da API que foidescoberta.
Durante a descoberta da API, a versão e o tipo de API sãorelatados dentro da mesma estrutura de dados que o ID de API. Por exemplo,uma abordagem de choque de número simples pode ser empregada. Ainda,uma estrutura de dados de um ou dois bytes ou η bytes para ID de API e umnúmero de versão são considerados.
Integridade de Conexão
Em arquiteturas de eventos, a integridade de conexão é umproblema; enquanto em arquiteturas de interrogação, a integridade de conexãoé inerente. Em arquitetura de eventos, o cliente 16 pode entrar em registrobem sucedido para prestar atenção à realimentação (tal como para uma leiturade temperatura). Uma vez que o registro esteja completo, o cliente conta como controle para notificação de mudanças na temperatura. Como tal, o clienteinterpretará um problema de rede como uma temperatura constante. Emcontraste, em uma arquitetura de interrogação, o cliente, constantemente,perguntará ao controle para realimentação de temperatura, a resposta ou a suaausência, imediatamente, indicará a integridade da conexão.
Usando um modelo opcional de indicação de atividade pararealizar integridade de conexão, um cliente deve registrar para uma indicaçãode atividade baseada em rede. Usando um modelo automático de indicação deatividade, a arquitetura de software 10 produz uma indicação de atividadeautomaticamente, quando um armazenamento temporário de registro denotificação não é nulo. Indicações de atividades podem ser mensagensdifundidas ou mensagens dirigidas para um nó específico.
Em um modelo opcional de indicação de atividade, se houverum caso quando não ela é necessária, a indicação de atividade pode sereliminada. Em casos onde é necessária, um cliente deve configurar aarquitetura de software 10 para produzir uma indicação de atividade. Em ummodelo automático de indicação de atividade, não há esforço requerido parafuncionalidade desejada - a arquitetura de software 10 é inerentemente forte.
Em uma indicação de atividade difundida, menos mensagens precisam serenviadas, uma indicação de atividade personalizada pode ser realizada atravésde atualizações de eventos com base em tempo e tem implementação maissimples. Contudo, isso pode resultar em manipulação de mensagens de outrosnós de rede que não estão participando na colaboração de arquitetura desoftware 10. Também, nós que não lidam adequadamente com mensagensdifundidas podem interpretar erroneamente mensagens que entram. Em ummodelo de indicação de atividade direcionada, apenas nós permitidosprecisam lidar com o protocolo de aplicação de arquitetura de software 10.Contudo, mais mensagens podem ser enviadas usando um modelo deindicação de atividade direcionada.
Para essa invenção, foi verificado que uma modalidadepreferida é uma indicação de atividade para integridade de conexão e,especificamente, mensagens difundidas podem ser usadas para uma indicaçãode atividade. Clientes que não preferem a taxa de indicação de atividadedifundida podem, ao contrário, usar, alternativamente, uma atualizaçãoperiódica de evento de NVO baseado em tempo. Fazer a indicação deatividade automática pode reduzir a carga sobre o cliente. Com relação àsAPIs contidas na arquitetura de software 10., as funções a seguir sãosuportadas como parte de API Núcleo (Id = 1): Heartbeat Message, SetHeartbeat Period. A indicação de atividade, de preferência, é iniciadaautomaticamente com um período padrão mediante recebimento da primeiramensagem de um cliente 16.
Um método preferível opcional adicional para integridade deconexão pode ser introduzido na arquitetura de software 10. Foi verificadoque à medida que a aplicação da arquitetura de software proliferava, eradeterminado que um método adicional de integridade de conexão eranecessário. O uso do método de indicação de atividade para integridade deconexão é apropriado para muitos cenários de aplicação. Esse método éescolhido porque ele representa uma boa troca entre a utilização de largura debanda e o nível de confiança da fonte de eventos. Contudo, é possível queuma mensagem de evento enviada pela arquitetura de software 10 falhe ao serprocessada pelo assinante de evento pretendido, mesmo quando o assinante deevento não detectou a falta de uma indicação de atividade. Nesse caso, oassinante de evento não pode detectar falha e, portanto não pode empreenderuma ação corretiva. A ação corretiva, no caso da falta detectada de umaindicação de atividade, é que o assinante de evento pode solicitar que a fontede evento reenvie (todos ou um subconjunto de todos) eventos de modo que oassinante de evento tenha a maior parte dos dados correntes. Para endereçaresse modo de falha potencial não detectado, um segundo método deintegridade de conexão é tornado disponível através da arquitetura desoftware 10. O método, conhecido como eventos reconhecidos, permite que aintegridade de cada mensagem de evento seja gerenciada individualmente. Afigura 29 ilustra a funcionalidade do evento reconhecido. Detalhes adicionaisreferentes aos eventos reconhecidos são descritos nas descrições da figura 29.
Controle de Tráfego (Fluxo)
Processos assíncronos configuráveis são poderosos, maspodem falhar quando configurados além de seus limites de processamentofísico e largura de banda. Mecanismos são introduzidos para impedir asaturação em quatro cenários de falha conhecidos: solicitações inválidas deentrada, solicitações válidas de entrada, eventos de mensagem de saída e umacondição de inicialização.
Solicitações Inválidas de Entrada. É provável que o clienteformatará e enviará uma solicitação que não pode ser analisada oucompreendida adequadamente pelo controle ou pode ser inválida, conforme oestado do controle.
Solicitações Válidas de Entrada. Sem consideração, o clientepode pedir ao controle para fazer uma segunda tarefa antes que o controle sejacapaz de processar a primeira.
Em um modelo de armazenamento temporário, um bufferpoderia ser usado, permitindo ao cliente enviar muitas solicitações sempreocupação com a capacidade de controle para servi-las. Nesse modelo, ocliente não tem responsabilidade mesmo que a implementação desse modeloseja mais simples. Contudo, o armazenamento temporário não resolve oproblema do controle do fluxo; apenas retarda ou torna o problema menosprovável ou menos freqüente e o armazenamento temporário requer mais RAM.
Em um modelo de controle de fluxo, mensagens podem serusadas de modo que é requerido que o cliente aguarde até que um controleesteja 'pronto', antes de enviar uma segunda solicitação. Em um modelo decontrole de fluxo, o problema de controle de fluxo é resolvido com firmeza emodos de falha são eliminados. Contudo, um cliente deve implementar umprotocolo de controle de fluxo.
Em um modelo de solicitação reconhecida, um controleproporciona uma resposta positiva ou negativa para cada solicitação decliente. Em um modelo de solicitação reconhecida, esse modelo permite queum cliente 16 desenvolva cenários simples de nova tentativa ou recuperação.Contudo, esse modelo requer mais largura de banda para os reconhecimentose ROM e desenho adicionais são requeridos.
Em um modelo de solicitação reconhecida, as solicitações docliente são não reconhecidas - um cliente deve usar informação de estadopara determinar se o comando teve sucesso. No modelo de solicitaçãoreconhecida, menos largura de banda e ROM são empregados. Contudo, aexperiência do usuário da aplicação pode sofrer, uma aplicação de cliente nãotem indicação, se um comando emitido foi bem sucedido e, portanto, nãopode fazer novas tentativas automáticas e um usuário observará um comandode falta de sucesso e precisará replicar manualmente as ações de comando.
Tem sido determinado que uma modalidade preferida dapresente invenção é um protocolo de controle de fluxo com um modelo decomando reconhecido. Além disso, reconhecimentos podem ser enumeradosde modo que um processo de cliente pode desenvolver cenários derecuperação tão fortes quanto possível. Como a mensagem de reconhecimentopreviamente mencionada nesta invenção proporciona a API e Op Code para ocomando reconhecido, um cliente pode discernir o comando que está sendorespondido. Isso impede a confusão em uma rede de múltiplas placas decontrole, em que múltiplas placas de controle no interior de um aparelhoutilizam todas arquitetura de software 10. Reconhecimentos de comando econtrole de fluxo são técnicas que permitem ao cliente enviar dados tãorapidamente quanto possível, sem saturação do controle. Os benefícios podemser aplicações muito responsivas, sem introdução de latência desnecessária oufalhas de aplicação não esperadas.
Os benefícios do controle de fluxo são obtidos usando publicarReconhecimento, APIID = 1, Op Code 1. Cada comando é reconhecido comuma resposta de publicar Reconhecimento. Um novo comando é permitidoapenas após recebimento de um valor de publicar Reconhecimento deREADY ou UNSUPPORTED. Publicar Reconhecimento tem a máquina deestado para comando de controle de fluxo, conforme mostrado na figura 8.A figura 8 é uma ilustração esquemática mostrando como aarquitetura 10 da figura 1 interage com comandos de entrada de acordo com ainvenção e valida ou rejeita aqueles comandos baseados no estado doaparelho eletrodoméstico. Vários indicadores de estado de controle de fluxosão mostrados na figura 8 com o numerai de referência 36 como, porexemplo, POWERUP, READY, BUSY, REJECTED e UN_SUPPORTEDcom base em vários comandos 38 e respostas emitidas 40.
Eventos de Mensagens de Saída (Realimentações). Durantecada varredura do micro-controlador, DAQ 30 de arquitetura de software 10coleta arranjos de bytes representando os eventos que devem ser enviados nobarramento (veja estado de PROCESS DAQ EVENTS da figura 36). DAQ 30de arquitetura de software 10 é configurável conforme mostrado na figura 5 e,portanto, é possível que o cliente ou clientes possam configurar a arquiteturade software 10 para transmitir mais dados do que é possível para a largura debanda do barramento de comunicação (isto é, durante a configuração).
A fim de impedir isso, um modelo de limite de configuraçãopode ser empregado o qual limitará a capacidade dos clientes 16 paraconfigurar a arquitetura de software 10 para evitar esse problema. Em ummodelo de armazenamento temporário, a arquitetura de software 10 pode serequipada com um armazenamento temporário de transmissão. Em um modelode mensagem de saturação, a arquitetura de software 10 detecta quando hádados demais apresentados para a camada de transporte de modo que os dadospodem não ser enviados para o cliente. Em um modelo que requer re-iniciação, a distribuição de eventos é suspensa e uma mensagem de saturaçãode eventos é enviada e/ ou difundida. Os eventos são resumidos uma vez queuma mensagem de SendEvents (por exemplo, 255 = ALL é recebida. Em ummodelo de não re-iniciação, uma mensagem de saturação é enviada e/ oudifundida e, então, a arquitetura de software 10 continua a criação de eventos.
No modelo de armazenamento temporário de transmissão, ocliente não tem responsabilidade e a implementação de cliente é mais simples.Contudo, o armazenamento temporário não resolve o problema; ele apenasretarda ou torna o problema menos provável ou menos freqüente e requermais RAM.
No modelo de limite de configuração, esse modelo impedirá oproblema de modo que um processo de recuperação não é necessário, éimpossível derivar um limite de configuração e o limite é baseado emtransições de estado da máquina, que são de uma natureza randômica emrelação à arquitetura de software 10.
No modelo de mensagem de saturação, o cliente pode detectarque a arquitetura de software 10 foi incapaz de submeter novos dados à redede comunicação interna 14 em pelo menos uma varredura. Esse cliente éincapaz de determinar se faltavam dados e a mensagem de saturação nãosignifica, necessariamente, que houve falha - apenas a possibilidade de dadosperdidos.
No modelo de re-inicialização, o cliente não temresponsabilidade, porém, o criador do cliente não é forçado a implementarprocesso de recuperação de saturação, o programador de cliente não podeestar ciente de que eventos podem ser abandonados devido à configuraçãoexcessiva da arquitetura de software 10. Esse tipo de falha não é catastróficoe, portanto, aplicações do cliente podem ser esquecidas para a perda de dados.
No modelo de re-iniciação requerido, o programador de clientedeve considerar a falha de saturação e sua implicação para a aplicação, issoimpede dificuldade transitórias para encontrar bugs e os modos de falha sãocatastróficos e/ ou óbvios. Contudo, o cliente deve implementar um processode recuperação de saturação e pode haver latência momentânea durante umprocesso de re-iniciação requerido.
Em um modelo de nada fazer, trabalho desnecessário éevitado, mas uma situação imprevista pode se originar, fazendo com que ocriador do cliente perca tempo localizando dificuldades que podem serdiagnosticadas programaticamente.
Tem sido determinado que uma mensagem de saturação quenão requer que re-iniciação esteja disponível via diretiva de compilador é umamodalidade preferida desta invenção. A mensagem de saturação deve sertransmitida com sucesso antes que outros eventos sejam colocados noarmazenamento temporário de transmissão de camada de transporte. Asfunções de mensagem seguintes são suportadas como parte de API de Debugde arquitetura de software 10 (API Id = 4): obter Saturada e Registro paraMensagem de Saturação.
Conforme mostrado na estrutura de pacote 28 da figura 4,todos os pacotes da arquitetura de software 10 usam um indicador Cmd/Fb,permitindo a possibilidade de conflito de namespace. Desse modo, é possívelsobrepor Op Codes sob a mesma API usando o indicador Cmd/Fb paradiscernimento.
Condição de Inicialização. Se o nó de arquitetura de software10 experimenta uma perda transitória de energia ou micro restauração,poderia ser possível para o cliente ter um snapshot incorreto para as variáveisde módulos de arquitetura de software 10. Para operação forte, a arquiteturade software 10 pode notificar seu cliente que as variáveis previamenteexportadas não podem mais ser consideradas válidas. Quando da consideraçãoda condição transitória, a configuração da arquitetura de software 10 poderia,potencialmente, ser armazenada em memória não volátil, o que permitiria oreinicio automática da comunicação. Em um modelo de mensagem difundida,a arquitetura de software 10 pode enviar uma mensagem de difusão especialnotificando todos os clientes para 'descarregar sua cache' com inicialização. Écompreendido que algumas aplicações de cliente 16 podem não precisarconsiderar seu modo de falha e, portanto, não fará uso da mensagem especial.
Também é conhecido que o ambiente operacional de software da arquiteturade software poderia experimentar uma falha (resultando em uma restauraçãode sua memória interna) e uma recuperação dentro do período de indicação deatividade. Com apenas a indicação de atividade como um meio de detecção,essa recuperação rápida ofuscaria a probabilidade de que a memória de cliente16, contendo cópias de certos valores da memória do ambiente operacional desoftware da arquitetura de software, não mais corresponderia aos valorescorrentes dentro da memória do ambiente operacional de software. Paraendereçar esse cenário de falha, uma mensagem de inicialização pode serincluída na arquitetura de software 10. Essa mensagem é independente daindicação de atividade e indicará para qualquer cliente 16 que quaisquervalores previamente mantidos da memória do ambiente operacional desoftware da arquitetura de software 10 terão mais probabilidade de sereminválidos e que o cliente, através do uso da mensagem sendEvent de Op Code7 de API 1, readquirirá os valores correntes. Também é compreendido que ocliente suspenderá ou modificará qualquer lógica ou cálculos que operamnesses valores de memória em uma maneira apropriada até que os valorescorrentes sejam readquiridos.
Em uma perda de modelo de indicação de atividade, aarquitetura de software 10 pode descontinuar sua indicação de atividade,permitindo ao cliente determinar a ação adequada no modo de falha. Contudo,como descrito acima, perda de modelo de indicação de atividade não cobretodos os cenários de falha. Isso é especialmente verdadeiro quando do uso domodelo automático de reinicio.
Em um modelo automático de reinicio, a arquitetura desoftware 10 pode retomar, automaticamente, a operação normal do últimoestado conhecido após uma re-inicialização ou restauração. No modeloautomático de reinicio, o cliente pode interpretar erroneamente a informaçãorecebida como transições de estado que não ocorreram. Em outras palavras,para um Estado A existente antes de uma Restauração ou Inicialização e umEstado B que é o Estado de inicialização de início; sem indicação adicional deum Estado I representando inicialização ou restauração, o cliente podeinterpretar uma transição do Estado A para o Estado B, como ocorrendo se terpassado através do Estado I.
Em um modelo de reinicialização requerida, um programadorde cliente deve considerar o cenário do parágrafo precedente e sua implicaçãopara a aplicação. Isso pode impedir dificuldade transitória para encontrarbugs, porque a falha é catastrófica e, como tal, facilmente identificada efixada. Contudo, o cliente deve implementar processo de recuperaçãotransitória e pode haver uma latência momentânea durante o processo de re-assinatura/ re-aquisição de dados.
Tem sido determinado que uma perda de modelo de indicaçãode atividade requerendo re-assinatura após uma inicialização/ restauração éuma modalidade preferida da presente invenção. A vantagem de umamensagem especial difundida, indicativa das condições iniciais, também écompreendida para ser uma indicação útil quando os recursos dentro doambiente operacional de software permitem essa característica adicional.
Mesmo que o mecanismo de indicação de atividade possa ser feito paraaproximar a utilidade de um mecanismo de mensagem de inicializaçãofazendo o tempo de espera menor, uma solução preferida incluirá umamensagem de inicialização, quando restrições de recursos do sistemaoperacional de software não são proibitivas. Por essa razão, a arquitetura desoftware 10 suporta como uma característica opcional uma mensagem deinicialização que é API Id = 3, Op Code = 2, publishSANode. A re-assinaturapode ser requerida porque os disparos dinâmicos de eventos são armazenadosna RAM e serão perdidos em uma inicialização.
De preferência, o módulo de arquitetura de software 10 nãoenvia quaisquer mensagens até que tenha detectado um cliente, exceto amensagem de inicialização opcional publishSANode. Um cliente é detectadopelo recebimento de um comando válido. Uma vez que o cliente sejadetectado, um mensagem de indicação de atividade configurável começa adifusão e a arquitetura de software 10, então, está pronta para operaçãonormal. Portanto, se o microprocessador principal para a arquitetura desoftware 10 experimenta uma inicialização/ RESTAURAÇÃO, o cliente seránotificado pela detecção da ausência da mensagem de indicação de atividade(veja API Id = 1, Op Code = 2) e, opcionalmente, detectando a mensagem,publishSANode (veja ID de API = 3 e Op Code = 2).
Integridade de Estado
A DAQ 30 da figura 5 da arquitetura de software 10proporciona diversas vantagens distintas em relação aos sistemas de DAQcomercialmente disponíveis. A arquitetura de software 10 pode exporqualquer variável na memória do microprocessador. Em geral, isso tambémincluirá os sinais de I/O de interesse. DAQs da técnica anterior não podemassim fazer. A arquitetura de software 10 está disponível para máquinas deprodução através de um único plugue de 3 fios, enquanto DAQs ouemuladores da técnica anterior requerem mais fiação ou instalação elétrica.
DAQs da técnica anterior não são práticos no contexto de um teste de campode consumidor. A arquitetura de software 10 pode ser empregada no sistemade produção. A arquitetura de software 10 acoplada com um modem podeproporcionar monitoração remota.
O aspecto mais fundamental, tornando a arquitetura desoftware 10 diferente dos dispositivos da técnica anterior é que ela executacomo uma sub-rotina de bloqueio (SA_ProcessOutgoingEvents da figura 36 eda figura 11) chamada sincronicamente da função mais() domicroprocessador. Isso assegura que o cliente pode ter (dentro dos limites delargura de banda de rede) um snapshot completa de varredura por varredurada memória do microprocessador, exatamente como o agente de execução domicroprocessador varrido. Isso abre muitas possibilidades interessantes,oscilando de emulação de baixo custo e depuração para desenvolvimento dealgoritmo híbrido, usando a arquitetura de software 10 para permitir co-processamento auxiliado por PC com componentes eletrônicos de produção.
Uma comparação de métodos de coleta de dados assíncronos ecoleta de dados síncronos serão agora descritos. Na coleta assíncrona:
1. Consideremos que AeB são variáveis no interior damemória de controle do aparelho.
2. Consideremos que C é uma variável calculada no clientecomo o produto de A e B.
3. Consideremos A = 23 e B = 67.
4. Cliente interroga A: A = 23.
5. A e B mudam. A = 56, B = 77.
6. Cliente interroga Β: B = 77.
7. Cliente calcula C: C = A*B = 23*77 (essa combinação de Ae B nunca ocorreu no microprocessador)
8. Cliente apresenta valor inválido para C para o consumidorou usuário final da aplicação.
A maioria das aplicações funcionarão com coleta de dadosassíncronos. É simples e direto. Contudo, problemas associados com coletaassíncrona são extremamente consumidores de tempo para depurar eidentificar.
Na coleta síncrona, o cliente define ou registra AeB com aarquitetura de software 10. Isso permite que a arquitetura de software 10mantenha valores coordenados de A e B em cada varredura.
1. Cliente registra para AeB.
2. Cliente solicita um enviar tudo.
3. Valores correntes para AeB são enviados pelo controlepara o cliente.
4. A e B mudam. A = 56, B = 77.5. Controle envia evento(s) delimitado(s) contendo A = 56 e B = 77.
6. Cliente não calcula C até que o bit de delimitação oudelimitador final seja alcançado.
7. Cliente calcula C = 56*77.
8. Cliente apresenta valor correto de C.
Com a coleta de dados síncronos, a coleta de dados é forte evirtualmente à prova de bola. Ela permite aplicações que ainda não tinhamsido conceitualizadas e permite depuração em 'tempo real' de software deprodução sem codificação especial nos componentes eletrônicos de produção.Contudo, RAM adicional é requerida no controle para manter snapshots devariável de "preocupação com" o cliente ou lista de propriedade.
Tem sido determinado que a arquitetura de software 10, depreferência, pode suportar e promover a técnica de coleta de dados síncronos.Contudo, interrogação de memória assíncrona está disponível em API Núcleo(APIID = 1).
Com a técnica de coleta de dados síncronos sendo empregada,o conceito de atualizações delimitadas será discutido. Atualizaçõesdelimitadas que são agrupadas juntas como um snapshot do estado doaparelho, tomado durante a mesma varredura de execução de laço principal domicroprocessador principal. O laço principal de controle de aparelho permitiráuma atualização iterativa de variáveis de realimentação que são registradascom a DAQ API (por exemplo, a cada 25 ms). Cada variável registrada émonitorada e apenas aquelas que mudam o valor de acordo com seu operadorde mudança de monitor de memória são difundidas como atualizações para ocliente. Quando as atualizações estão no processo de serem difundidas,nenhuma nova atualização é permitida a fim de preservar o snapshot emtempo. Um snapshot é comunicado ao cliente usando o indicador MMP emByte 2 do cabeçalho da arquitetura de software 10, conforme mostrado noprotocolo de aplicação 28 na figura 4.
Embora MMP de 28, figura 4, seja verdadeiro, maismensagens estão pendentes para o snapshot. Quando MMP é falsa, amensagem corrente é a última mensagem no snapshot. Portanto, se a primeiramensagem de um snapshot for a única mensagem naquele snapshot, MMPserá falsa.
O exemplo na figura 9 ilustra um comando delimitado (Ciclo +Temperatura + MMP) com reconhecimentos, seguidos por duas atualizaçõesdelimitadas consecutivas. Onde a delimitação se refere aos elementos deprotocolo que indicam para o receptor que mais mensagens estão chegando dafonte e que o processamento de dados pela lógica de aplicação do componentede recebimento será retardado até que os indicadores de delimitação doprotocolo dentro da estrutura de pacote 28 (bit de MMP 7) indicam umatransação completa em cujo momento o processamento de dados pela lógicade aplicação é permitido. O comando delimitado é mostrado pelo numerai dereferência 42 e as duas atualizações delimitadas consecutivas são mostradaspelos números de referência 44 e 46, respectivamente. Observe que asatualizações não começam até que a execução de comando delimitada estejacompleta, proporcionando ao cliente a capacidade para filtrar dados derealimentação transitórios. Os comandos delimitados são proporcionados pelomesmo mecanismo, MMP, encontrado em 28, como atualizações delimitadasa fim de proporcionar aplicações de um nível de controle maior.
O exemplo da figura 9 é conceituai. O mecanismo real é MMPencontrado em 28. Contudo para fins ilustrativos, o comando delimitadocomeça com um iniciador de comando inicial de "começar" (MMPestabelecido) e inclui comandos para estabelecer um ciclo de máquina delavar para lavar, um estado de instrução para pronto, uma temperatura da águapara médio, mais uma vez uma instrução para pronto e, finalmente, umindicador de início de ciclo, seguida por um terminador de comando (MMPnão estabelecido). Pode ser notado que, na figura 9, atualizações (tais comoatravés de eventos) são desativadas para impedir atualizações de aconteceremantes de o comando delimitado estar completo. Além disso, um indicador de"comando de processo" é mostrado periodicamente por todo o processamentodo comando delimitado no aparelho 12 para ilustrar as porções do comandoemitido do cliente 16 através da rede de comunicação interna 14 sãoprocessadas.
Nas atualizações delimitadas 44, as atualizações são, mais umavez, ativadas (uma vez que foram desativadas no começo do comandodelimitado $2) para permitir que o aparelho 12 relate seu estado para o cliente16. No exemplo mostrado nas atualizações delimitadas 44, o estado dereconhecimento é mostrado em pronto, o ciclo é relatado como lavagem, oestado é relatado como executando, cesta é relatada como cheia, a bomba érelatada como ligada e a temperatura é relatada como média. Mais uma vez,os indicadores de começar e terminar encerram a atualização delimitada 44.Esses indicadores de começar e terminar podem ser relatados pelo uso doindicador, MMP, na estrutura de pacote de aplicação 28, como discutido nafigura 4 ou outro método que seria evidente para alguém habilitado na técnicade protocolo de rede.
Na atualização delimitada 46 a cesta é relatada como agitada, abomba é relatada como desligada e o motor é relatado como ligado. Mais umavez, indicadores de começando e terminando (MMP) encerram a atualizaçãodelimitada 46.
Estratégia de API (Compressões de tecla vs. API Lógica
Em quase todos os casos, o aparelho 12 é controlado por umteclado integrado, O software embutido lida com as compressões de tecla oueventos de usuário gerados pelo teclado e ação é empreendida. De fato, a(s)função(ões)de manipulação de compressões de tecla é(são) a API para osaparelhos. A consulta a ser considerada nesta seção é se essa API é a melhorabordagem ou se uma segunda API deve ser desenvolvida para um clienteexterno 16, 22.
Em um modelo de compressões de tecla, para usar a API decompressões de tecla, o cliente externo 22 deve criar compressões de teclavirtuais e transmiti-las através da rede. O cliente externo 22 deve serprojetado com o conhecimento do teclado integrado, de modo que essascompressões de tecla podem ser geradas corretamente e isso requer um cartãode interface de rede externa para gerar compressões de tecla. Neste modelo,nenhuma modificação é necessária para programação de teclado subjacente.Contudo, o cliente 22 deve monitorar o estado corrente do teclado, a fim dedeterminar as compressões de tecla necessárias para obter o estado desejado.A API de Cliente deve mudar, se o desenho do teclado mudar em lugar de ascapacidades da máquina. Essa arquitetura rompe as melhores práticas dedesenvolvimento de software pela interposição de uma fileira de apresentaçãoentre uma fileira do meio e a fileira e a fileira de persistência. Haveránecessidade de comandos estendidos para Gerenciamento de Energia, Serviçoe Diag., Testagem, etc, que não está disponíveis na interface básica deteclado.. Deve haver uma maneira de ter uma API lógica, bem comoalavancagem, tanto quanto possível, do código de validação associado com asrotinas de manipulação de compressões de tecla, sem necessidade de duplicarcódigo.
Em um modelo de API lógica, em contraste, a API Lógica édesenvolvida de uma abstração das capacidades das máquinas em lugar dodesenho do teclado. Por exemplo, assar em um forno europeu usandocompressões de tecla poderia requerer que lesse a posição do codificador dodial do ciclo e mudasse programaticamente o codificador para corresponder aum ajuste de Bake (Assar). Se usando uma API lógica, o cliente não precisaenviar somente o Op Code para o Ciclo ajustado com o valor de enumeraçãopara Bake: {0x01, 0x01} (setCycle(Bake). No modelo de API lógica, ocliente 16 não precisa ficar preocupado com o estado do teclado, o desenho doteclado ou rotinas de manipulação de key press. A API permaneceindependente de mudanças no desenho do teclado, permite comandosestendidos e uma prática melhor da indústria.
Tem sido determinado que a arquitetura de software 10 usaráuma API lógica que é integrada com as rotinas de manipulação de key press.A API lógica expõe muitos dos comandos estendidos, os quais permitemvárias aplicações adicionadas de valor. No controle do aparelho, quando umatecla na interface de usuário é comprimida ou um comando externo é emitido,ele é mapeado diretamente em uma chamada de função de API Lógica comoum ponto de entrada comum (por exemplo, quando a tecla WASH (lavar) écomprimida ou um comando de rede WASH externo é emitido, amboschamarão a função SetCycle(WASH) em uma lavadora com a arquitetura desoftware 10 nela instalada. Uma função de API Lógica objetiva descrever umconjunto de funcionalidade de maneira parametrizada de modo que possa serreutilizado. Por exemplo, funções especializadas não lógicas para temperaturapoderiam ser IncrementTemp() ou DecrementTemp(), que não podem serusadas facilmente para ajustar a temp a qualquer valor. Mas uma função deAPI lógica pode ser:
SetTemperature(new Temp ou temp++ ou temp--). Essa últimafunção pode ser usada por ambos, compressões de tecla e comandos externos.
Um manipulador de comandos para a arquitetura de software10 pode compreender um método para o software embutido em resposta aoscomandos lógicos (por exemplo, setCycle(bake) ou compressões de tecla (porexemplo, comprimindo o botão "Bake" em aparelho de forno 12). O métodotranslaciona compressões de tecla de entrada e resulta em uma invocação dafunção apropriada dentro da API lógica.
Uma lógica baseada em estado e de validação tanto quantopossível existe no interior dessa função de API Lógica, de maneira quecomandos externos são tratados do mesmo modo e executam o mesmo códigoque compressões de tecla. Essa API pode ser implementada sem umredesenho importante do sistema de entretenimento de controle de aparelho.Apenas o software do Gerenciador de Interface do Cliente deve serreorganizado e agrupado para chamar funções de API como o ponto deentrada para cada comando de compressões de tecla. Essa não é umaexigência importante da arquitetura de software 10, porém. Ela serve apenaspara minimizar a quantidade de código que deve ser escrita. Se uma coleta defunções de API Lógica não estiver disponível para o agente de comandoexterno, então, a lógica de estado e de validação encontrada dispersa nocontrole de aparelho deve ser duplicada para cada comando externo,resultando em tamanho de código maior e possibilidade aumentada de erro.
Identificação: Emissões de Multi-Nós
A discussão acima sobre Versão e Descoberta de APIestabeleceu um benefício para um mecanismo descobrir as APIs residentesem qualquer nó tendo a arquitetura de software 10 nele instalada. Levado paraa etapa seguinte, há considerações adicionais:
1. Múltiplos Nós
2. Múltiplos Clientes
3. Múltiplos Nós instalados que implementam a mesma API
4. Um único Nó com múltiplas APIs duplicadas
5. Múltiplas APIs usando os mesmos Op Codes
6. Atribuição de SAP
7. Descoberta de Cliente dos Nós suportando o Protocolo dearquitetura de software 10.
Múltiplos Nós. É provável que múltiplos componentes na redeimplementarão a arquitetura de software 10. Portanto, considerações serãofeitas para redes com múltiplos componentes que implementam a arquiteturade software 10.Em um modelo de padrão façade, o padrão façade é usadopara criar acesso simples a uma coleção de objetos. Isso é feito pela criaçãode uma camada de software de interposição entre o cliente e os vários objetosalvo de modo que o cliente tem uma interface simples para um único objeto.
Essa fonte simples é, então, responsável por solicitações diretas para o objetoalvo apropriado. No modelo de padrão façade, esse modelo é mais fácil degerenciar porque a API é definida centralmente. Na maioria das aplicações, afaçade apresenta uma interface mais simples para o cliente. Contudo, essemodelo requer projeto do tempo de compilação para incluir outras APIs denós no nó de façade. RAM/ ROM adicionais podem ser requeridas paras afaçade manipular e enviar solicitações para o nó alvo. E, se dois nós sãoclientes um do outro, então, o padrão de façade criará processamentodesnecessário, visto que o nó de façade primeiro fará solicitação através desua própria façade apenas para enviar aqueles para o nó alvo.
Em um modelo de serviços distribuídos, esse método usaprotocolo de descoberta como o meio para o cliente encontrar os objetos alvo.O cliente é responsável pela interação independente com cada objeto alvo, Emoutras palavras, o cliente descobrirá o(s) nó(s) de arquitetura de software 10 e,então, interrogará cada um quanto a que API(s) são suportadas por cada nó.
No modelo de serviço distribuído, esse modelo escala bem de modo que oscomponentes podem ser plugados juntos em tempo de execução. Contudo,esse modelo pode requerer múltiplos documentos para gerenciar as definiçõesde variáveis de rede (APIs).
Tem sido determinado que a arquitetura de software 10 usará omodelo de serviço distribuído para gerenciar múltiplos nós ativados na rede14. A abordagem de façade pode ser indesejável porque mudanças na API doobjeto alvo requerem mudanças na façade (mudar, compilar, baixar, testar).Enquanto em um ambiente de tempo de compilação único, suportado por boasferramentas de re-fatoração, a façade poderia ser uma boa escolha. Em umambiente distribuído, o modelo de serviço distribuído mais flexível permitirádesenvolvimento mais rápido e configurações flexíveis. Contudo, em algunscasos pode não haver recursos suficientes em cada microprocessador nosistema para suportar a 10. Em outros casos, pode haver protocolo pre-existente e não há desejo de fazer modificações em um painel pré-existente.Nesses casos, façade pode ser uma boa alternativa para o modelo de serviçodistribuído.
Múltiplos Clientes. Conforme mostrado na figura 1, múltiplosnós ou clientes 16 na rede 14 implementarão a arquitetura de software 10.
Portanto, considerações serão feitas para redes com múltiplas ocorrências de10. Uma consideração principal é a do registro e notificação de eventos. Semúltiplos clientes registram com a arquitetura de software 10 para eventos, aarquitetura de software 10 será capaz de gerenciar distribuição de eventos.
Usando um modelo de criação de eventos de mensagensdiretas de ID de nó, a arquitetura de software 10 armazenará o(s) ID(s) deNó(s) de cada solicitador de evento, de modo que, quando aquele evento édisparado, uma mensagem direta será enviada para o(s) Nó(s). Nesse modelo,as mensagens são enviadas apenas para nós que se interessam pelo evento.Contudo, esse modelo requer um byte por mensagem para armazenar o ID deNó e requer mais RAM para criar estruturas adicionais de memória para cadanó solicitante.
Em uma mensagem dirigida de ID de nó criando eventos como Identificador de ID de API, usando essa abordagem, a arquitetura desoftware 10 armazena o(s) ID(s) de nó(s) de cada solicitador de cada evento,de modo que, quando aquele evento é disparado, uma mensagem dirigida éenviada para o(s) nó(s) solicitante(s). Além disso, o ID de API do nó principalé incluído no evento. Esse modelo permite à camada de transporte do clientemelhorar mensagens de roteamento internamente. Contudo, esse modelotambém requer um byte por mensagem para armazenar ID de API e requermais RAM para criar estruturas de memória adicionais para cada nósolicitante.
Em um modelo de criação de eventos de mensagem dedifusão, usando essa abordagem, a arquitetura de software 10 não rastreia oID de nó do solicitador de evento, Quando o evento é disparado, a arquiteturade software 10 envia uma mensagem de difusão. Nesse modelo, aimplementação da arquitetura de software 10 é mais simples e menor, não hánecessidade de gastar um byte por mensagem para armazenar o ID de nó.Contudo, a difusão pode criar processamento de eventos desnecessários poroutros nós.
Uma quarta abordagem híbrida, que é a abordagem preferida,compreende um modelo onde mensagens de difusão são usadas, o que eliminaa necessidade de armazenar Id de Nó. Contudo, o cliente incluirá Id de API eOp Code nas Mensagens de Criação de Eventos da DAQ (Id de API 2, OpCodes 1,2, 12, & 13), de modo que elas são dinamicamente atribuídas(conforme discutido no parágrafo abaixo). Usando essa abordagem, amensagem de evento resultante conterá o Id de API e Op Code atribuídos(conforme mostrado na mensagem publishEvent de Id de API = 1). Nessamensagem (publishEvent), o Id de API e Op Codes de Bytes 1 e 2 de 28 nafigura 4, são aqueles atribuídos pelo cliente 16, usando as Mensagens deCriação de Evento (citadas acima).
Tem sido determinado que a arquitetura de software 10 aquidescrita usará o modelo de mensagens de difusão que inclui o ID de API e OpCode. Isso proporcionará o benefício de roteamento por troca dearmazenamento de ID de API para armazenamento de ID de Nó. Dada adiscussão em SAP abaixo, o risco de mensagens de difusão é muitodiminuído. E embora uma quantidade de processamento seja usada pelos nóspara descartar mensagens não relevantes para eles , é superior às mensagensdirigidas, o que poderia, eventualmente, causar saturação da rede e do códigode arquitetura de software 10. Incluindo o, o ID de API permite que o clienteconfigure o controle com APIs dinâmicas que encorajarão desenhosmodulares, melhores, no futuro.
Usando a Mesma API em Nós Múltiplos. É provável quealgum componente de rede opcional implementará a mesma API que o painelde UI ou Gerenciador de Aparelho (isto é, serviço/ diagnóstico ou energia).
Isso permitirá que o componente de rede opcional 16 se manifeste para umcliente externo 22. Desse modo, a arquitetura de software 10 pode permitirque o cliente 16, 22 interaja com dois nós físicos - cada um implementando amesma API. Essa consideração de desenho está na interseção de diversasoutras e, igualmente, sua resolução é uma combinação de soluções de desenhopré-existentes.
Nós opcionais são possíveis através de participação dinâmica.O cliente será capaz de encontrar que nós suportam o protocolo 28 através deAPI de descoberta (veja a figura 6). Cada nó pode ser interrogado paradescobrir que APIs são suportadas através de descoberta, igualmente. Os OpCodes não são únicos globalmente, mas o id de nó da rede de comunicaçãointerna 14 acoplado com o ID de API e o Op Code são únicos. O ID de API éembutido em cada evento.
Para resumir, o cliente pode primeiro descobrir os nós dearquitetura de software 10 e, então, descobrir as APIs de suporte de cada um.O cliente pode, então, iniciar uma interação com cada API de cada nó. Comocada pacote 24 inclui o ID de nó e o ID de API, ambos, cliente e alvo, serãocapazes de evitar conflitos de namespace e mensagens de roteamento para oespaço de aplicação apropriado.
Múltiplos Casos de APIs no mesmo Nó de Rede. Há 12desenhos de aparelho que se prestam A reutilização de API no mesmomicroprocessador. Exemplos incluirão um forno duplo (isto é, duas câmarasde assar controladas separadamente) ou uma gaveta refrigerada de doiscompartimentos. Em outras palavras, em alguns casos há múltiplas cavidadesque desempenham a mesma função e podem, portanto, ser controladas atravésda mesma API. A abordagem do desenho para esse caso é discutida.
Em um modelo de nome de função única, o programadorcriará um ID de API que tem Op Codes únicos para cada comando ou variávelsem preocupação com a re-utilização da definição. Em outras palavras, OpCode 10 = temperatura de ajuste de forno mais baixa e Op Code 11 =temperatura de ajuste de forno mais alta. Nesse modelo de nomes de funçãoúnica, há menos mensagens durante a descoberta, porém, esse modelo nãopromove desenho modular e reutilização de código.
Em um modelo de ID de API múltiplos, o programador usa amesma definição de Op Code, mas designará um ID de API único para cadacaso da API. Em outras palavras, Id de API de forno superior = 1, ID de APIde forno inferior = 2. Nesse modelo, há menos mensagens durante adescoberta e esse modelo promove desenho modular e reutilização. Contudo,esse modelo resultará no consumo dos IDs de APIs em uma taxa mais rápida.
Em um modelo de ID, a arquitetura de software 10 atribui,dinamicamente, o ID de API a cada caso da API, exceto para o primeiro caso.O primeiro caso da API será identificado por um repositório global de ID deAPI. Para permitir isso, a arquitetura de software 10 especifica IDs de API(por exemplo, 246 - 255) conforme APIs reservadas para atribuição dinâmicapara casos de API. Esse modelo promove desenho modular e reutilização decódigo e no consome IDs de API. Contudo, há mais mensagens durante adescoberta.
A arquitetura de software 10 é um protocolo orientado porobjeto projetado para permitir que objetos descubram e colaborem um com ooutro de maneira segura. Básico para essas exigências são: (1) entidades decolaboração devem ser endereçáveis unicamente de modo que mensagenspodem ser apropriadamente roteadas na rede e (2) entidades de colaboraçãodevem ser identificáveis unicamente, assim, seus contratos de mensagens,regras para interação e preocupações de compatibilidade podem sercompreendidos. Em um ambiente único de tempo de execução, o compiladoré capaz de reforçar o item (2). Em um ambiente de rede ou distribuído,compiladores embutidos, em geral, não endereçam o item (2).
A unicidade de endereçamento de entidade de colaboração(objeto ou API) é governada pela combinação de um ID de nó de 3 bits(encontrado no Campo de Endereço de 24 na figura 4) e uma API ou ID deinstanciamento de 8 bits (encontrado no Byte 1 de 28 na figura 4). Qualquermensagem de rede contendo essas duas partes de informação podem serroteadas corretamente. Isso proporciona 255 entidades (ou objetos) decolaboração únicas para cada nó de rede.
A identificação de entidade é definida por um ID de API de 8bits (por exemplo, um identificador de classe), um ID de Tipo de 2 bytes (istoé, subclasse ou especialização) e um ID de versão de 2 bytes (isto é, ID deTipo significa intenção e ID de Versão significa compatibilidade).
Essa abordagem de duas fileiras reconhece a unicidade deendereçamento separadamente da unicidade de identificação. Essa separaçãoproporciona um uso mais eficiente de largura de banda pela remoção dequatro bytes de informação de identificação de cada pacote. Por sua vez, ocliente deve colocar na cache a informação de identificação e indexá-la pelosonze bits de endereço totais.
Tem sido determinado que o modelo de ID de Instanciamentoé uma modalidade preferida da presente invenção. A API de Descoberta (IDde API = 3) tem suporte para o ID de Instanciamento em mensagens, PublishAPI Info, Get Instance Info e Publish Instance Info. O instanciamento é umconceito muito poderoso, que pode ser exemplificado por seu uso noprotocolo.
Namespace de API - Op Code. Mensagens em uma redeserial, em geral, têm ASCII ou identificador numérico que permitem aoreceptor da mensagem rotear os dados contidos na mensagem para a funçãointerna apropriada. Essa função, então, operará sobre os dados restantes nacarga útil.
Os dados restantes na carga útil são definidos em tempo dedesenho em um documento. Esse documento descreve o significado de cadabit d ou byte na carga útil. Disso, manipuladores internos de mensagens desoftware são desenvolvidos especificamente para cada definição de carga útil.Portanto, há, em geral, um manipulador de mensagem para cada par único deOp Code e Cmd/Fb.
Normalmente, se houver múltiplas definições de carga útilindependentes, que compartilharam o mesmo Op Code sem qualquermecanismo de identificação adicional, será impossível para o receptor rotearaquela mensagem pára o manipulador de mensagens. Contudo, a presenteinvenção proporciona o indicador Cmd/Fb para suportar a sobreposição de OpCodes, usando o indicador para diferenciação. Desse modo, a presenteinvenção proporciona a funcionalidade para sobreposição de um comando esua mensagem de realimentação correspondente, usando o mesmo Op Code
Essa seção discute técnicas que podem ser empregadas paraproporcionar identificação única para as definições de carga útil demensagem.
Em um modelo de Op Code globalmente único, usando essaabordagem, Op Codes devem ser globalmente únicos. Em outras palavras, acada plataforma ou criador de API deve ser alocada uma faixa de Op Code(por exemplo, 350-385), que não deve se sobrepor com a faixa de Op Codede qualquer outro projeto. Esse modelo é ineficiente devido às alocações defaixa que requerem IDs sobressalentes. Ainda, criadores de API não terãocontrole sobre seu esquema de numeração de Op Code e esse modelo requeruma ordem de decisões de magnitude mais coordenadas (transferência deinformação).
Em um modelo de ID de API globalmente único, usando essaabordagem, Op Codes são agrupados em coleções lógicas formando uma API.À API será atribuído um ID globalmente único composto de Id de API, Tipo eVersão, Portanto os Op Codes existentes só precisam ser únicos dentro daAPI. Nesse modelo, não há necessidade de IDs sobressalentes alocados,criadores de API podem começar em Op Code = Ie esse modelo requermenos coordenação de informação para evitar conflitos de namespace.
Tem sido verificado que a presente invenção emprega aestratégia de ID de API globalmente única como uma modalidade preferida.Certos Op Codes fixos, que são parte da API de Núcleo de arquitetura desoftware 10, revertem para o número de partida comum (1) e à API deNúcleo, de preferência, pode ser atribuído um ID de API de (1).
Atribuição de SAP. SAP encontrado em 24 identifica aestrutura da Carga Útil Estendida ou SDU 26. E o mesmo conceito que o deum ID de API, que foi aqui introduzido antes. As vantagens de SAP tambémsão as mesmas, pelo fato de que as mensagens que entram precisam seridentificadas e roteadas para os manipuladores internos corretos (oudescartadas rapidamente). Na rede WIDE 14 de exemplo aqui discutida, hádezesseis SAPs disponíveis. A arquitetura de software 10 adapta os critériospara associação de SAPs. Nesse cenário, o administrador da rede decomunicação interna 14 pode aprovar o protocolo de aplicação da arquiteturade software IOe atribuir à arquitetura de software 10 um SAP oficial. Outrosidentificadores de rede para o protocolo 24 são considerados sem afastamentodo escopo da presente invenção. Por exemplo, à arquitetura de software 10pode ser atribuído um SAP padrão de 1 na rede interna 14.
Um SAP (ou outro identificador de sub-protocolo) permite queo nó da rede de comunicação interna 14 participe na arquitetura de softwareIOe mensagens de não arquitetura 10. O SAP da arquitetura de software 10 seadapta na arquitetura global e adiciona mais escopo à arquitetura de software10. O SAP da rede de comunicação interna 14 é um conceito de som de umaperspectiva técnica e prática. A garantia de um ID específico de rede 14proporciona à arquitetura de software 10 visibilidade global e aceitaçãooficial, o que pode ajudar a proliferar seu uso e impeli-la para um padrãoglobal.
A Descoberta de arquitetura de software 10 - Figura 5. Naseção anterior, foi estabelecido que o ID de API de arquitetura de software 10é análogo ao SAP da rede de comunicação interna 14. Igualmente, nas seçõesanteriores, é estabelecido que é vantajoso para o cliente 16 da arquitetura desoftware para descobrir pela interrogação da(s) API(s), que residem em cadanó físico da arquitetura de software 10.
Uma consulta e/ ou solução similar pode ser apresentada paraa descoberta da arquitetura de software 10. Se uma ferramenta de serviçoquisesse descobrir dinamicamente todas as API(s) de arquitetura de software10, primeiro precisa descobrir os IDs de Nós do(s) nó(s) da rede decomunicação interna 14 que suportavam o protocolo da arquitetura desoftware 10. Isso pode ser realizado por um modelo de mensagem de difusãoque envia um comando de difusão ao qual os nós de arquitetura de software10 responderão. Nesse modelo, a arquitetura de software 10 pode difundiruma nova API, que é adicionada à arquitetura de software 10 ou pode difundira adição de um novo nó(s) de rede 14, que implementa a arquitetura desoftware 10. A API de Descoberta, Figura 6, que servirá como o mecanismopara a descoberta de arquitetura de software 10. Pode haver uma mensagemde descoberta de interrogação e uma mensagem de difusão não solicitadadisponível é discutida na API de Descoberta (ID de API = 3).
Integridade de Mensagem de Múltiplas Cargas Uteis
Frag, bit 6 de Byte 2 no cabeçalho de arquitetura de software10, permite ao protocolo de arquitetura de software 10 enviar cargas úteismaiores do que aquelas do protocolo subjacente (isto é, aquele da rede decomunicação interna 14). Quando Frag é estabelecido, o receptor perceberáque a mensagem corrente será fragmentada em múltiplos pacotes oufragmentos.
No modelo de id de fragmento de mensagem, o primeirofragmento de uma mensagem fragmentada usa a estrutura de pacote padrão,conforme descrito na figura 4. Esse fragmento inicial proporciona a API demensagem, Op Code e indicador Cmd/Fb p. Todos os fragmentossubseqüentes da mensagem, de preferência, suporão a estrutura de mensagemfragmentada descrita na figura 24. Nessa estrutura, o indicador Frag aindaexiste (junto com o indicador MMP) para reforçar os dados. Contudo, o Byte2 agora contém o indicador pendente de mais fragmentos (MMP) no bit 5, idde mensagem (MID) nos bits 3 - 4 e id de fragmento (FID) nos bits 0-2.
O indicador de MFP informa o receptor que pelo menos maisum fragmento da mensagem corrente será esperado. A transição de MFP de 1a 0 informa o receptor de que o pacote corrente é o pacote final da mensagemcorrente. O MID proporciona um identificador de 2 bits para cada mensagem.Desse modo, a cada mensagem fragmentada (grupo de fragmentos) seráatribuído um MID e esse MID, então, incrementará cada mensagemfragmentada subseqüente (grupo de fragmentos). O MID incrementará até 3 e,então, se deslocará de vota para 0. FID proporciona um identificador de 3 bitspara cada fragmento dentro de uma mensagem. Assim, para uma mensagemparticular, o primeiro fragmento será sempre atribuído e FID de 0. Para cadafragmento subseqüente daquela mensagem, o FID será incrementado. O FIDincrementará para 7 e, então, se deslocará de volta para 0.
O protocolo de fragmentação proporcionado pela presenteinvenção permite ao receptor verificar a integridade de uma mensagemfragmentada. Pela monitoração do indicador Frag e MFP, o receptor não podeassegurar paradas errôneas para uma mensagem fragmentada. Através daverificação de que o MID não muda dentro da recepção de uma mensagemfragmentada única, o receptor pode assegurar que duas mensagensfragmentadas separadas não se tornam fundidas (talvez devido a umfragmento perdido). Através da verificação de que os incrementos de correçãode FID por fragmento, o receptor pode assegurar que nenhum fragmento éperdido dentro de uma mensagem (ou recebido fora de ordem). Veja a figura25 para um exemplo do modelo de id de fragmento de mensagem.
Em um modelo de CRC sumário, essa solução faz uso de umconceito de soma de verificação de redundância cíclica (CRC) existente. UmCRC adicional de 2 bytes pode ser anexado à última carga útil de umamensagem de múltiplas carga úteis. A CRC é a representação de CRC detodos os bytes de carga útil concatenados em uma carga útil combinada única.O emissor gera essa CRC. O receptor valida essa CRC de acordo commétodos bem conhecidos. Neste modelo de CRC de sumário, essa soluçãoreutiliza algoritmos de CRC existentes, que são estabelecidos e bemconhecidos, contudo, o algoritmo de CRC é mais complexo do que o contadorde quadros e a CRC pode não ser facilmente portátil para um vendedor deterceiros.
Portanto, tem sido determinado que o modelo de id defragmento de mensagem é uma modalidade preferida para confirmar aintegridade da mensagem de múltiplas cargas úteis η arquitetura de software10 de acordo com a invenção. O modelo de id de fragmento de mensagem émais fácil de implementar por terceiros e é mais fácil de adicionar àarquitetura 10 existente.
Organização de Software
Com relação à arquitetura de software 10, os arquivos deorganização e implementação de códigos serão agora discutidos com relação àfigura 10. A figura 10 é uma ilustração esquemática mostrando a arquiteturade software 10 DA figura 1 de acordo com a invenção em relação ao ambienteoperacional de software 16A de um componente 16 contendo várioscomponentes de software 16B, em que o arquitetura de software 10compreende um manipulador de comando 50, um manipulador de atualização48 e uma interface de camada de rede de comunicação interna 52 parainterconexão da arquitetura de software 10 à camada de operação de softwareda rede de comunicação interna 14A, o que cria e envia dados através da redede comunicação 14 do aparelho eletrodoméstico 12. Também é mostrado umexemplo de como outros componentes de software 16B dentro do ambienteoperacional de software 16A invocarão e interagirão com os componentes daarquitetura de software 10 (50, 52 e 48).
A fim de criar uma implementação mais genérica do ambienteoperacional de software 16A, a dependência entre o Gerenciador de UI (que éum de diversos componentes de software 16B dentro do ambiente operacionalde software 16A) foi eliminada. Nesta implementação, o laço de execuçãoPrincipal 11 do ambiente operacional de software 16A executa a invocaçãoem 50. Acreditava-se previamente que a implementação anteriorproporcionasse desempenho mais preciso e seguro da arquitetura de software10 devido aos detalhes particulares de cronometragem associados com acronometragem de execução associada com UI_Manager 16B.
Para definir o primeiro nível de detalhes para a arquitetura desoftware 10, três componentes principais de software (sub-componentes) sãomostrados: o manipulador de atualizações 48, o manipulador de comandos 50e a interface de camada de rede de comunicação interna 52. O manipulador deatualização 48 interage com o agente de DAQ 30 a fim de identificar ainformação com indicadores para atualizações dentro da operação da DAQ demodo que a interface de camada de rede de comunicação interna 52 podeprocessar a referida informação resultando em interação com a camada deoperação de software 14A de rede de comunicação interna, resultando emuma estrutura de pacote 24 transmitida na rede 14. O manipulador decomando 50 valida e processa comandos de entrada da interface de camada derede de comunicação interna 52, invocando a função de operação de softwareapropriada de acordo com os valores de ID de API de Identificadores e OpCodes de estrutura de pacote 28. A interface de camada de rede decomunicação interna 52 significa desacoplar (tanto quanto praticável) osparticulares da arquitetura de software 10 da camada de operação de softwarede rede de comunicação interna 14A, a rede 14 da figura Iea estrutura depacote 24 da figura 4. A interface de camada de rede de comunicação interna14 52 faz interface com a Camada de Operação de Software 14A da rede decomunicação interna 14, o que cria e envia dados de acordo com a definiçãoda figura 4 através da rede de comunicação 14 do aparelho eletrodoméstico 12.
Os sub-componentes da Camada de Operação de Software 48,50 e 52 da arquitetura de software 10 mostrada na figura 1 trabalham juntospara gerenciar comunicações com outros componentes 16 ou 22, eu tambémtêm a arquitetura de software 10 ou uma alternativa capaz de interagir com aestrutura de pacote 24.
A figura 34 mostra diversos arquivos de implementação, quesão considerados para uso com a presente invenção.
AS_prm.h. A arquitetura de software 10 inclui parâmetrosconfiguráveis e enumerações de comando.
SACore.c/h. Este arquivo para o software de núcleo dearquitetura de software 10 contém o manipulador de atualizações 48 e omanipulador de comando 50, que processa comandos, gerencia realimentaçãode controle de fluxo e toma snapshots de dados do aparelho para atualizaçõesdinâmicas.
SAAppSpecific.c/.h. Este arquivo para o software de núcleode arquitetura de software 10 contém manipuladores de comando específicosde aparelho e implementações de comandos para acionamento de um tipoparticular de aparelho 12 (tal como um arquivo dirigido especificamente paragerenciamento e comunicação com uma máquina de lavar, por exemplo).Qualquer comando que não é genérico para todos os aparelhos 12 éimplementado nessa função. Esses comandos são enumerados em AS_prm.h esão chamados pelo manipulador de comando.
SAWideComm.c/h. Esse arquivo contém a camada deaplicação 52 de rede de comunicação interna 14, que proporciona a interfacepara o protocolo da rede de comunicação interna 14 e controla a delimitaçãode mensagens em snapshots, análise de comandos de entrada e processamentode indicadores de atualização para enviar mensagens de atualização.
SADaq.c/h. Esses arquivos contém toda a funcionalidade parao agente de DAQ 30. Desse modo, toda a funcionalidade referente aomanipulador de atualizações 48 e eventos está contida aqui.
SADiscovery.c/h. Esses arquivos contêm toda afuncionalidade para um nó que implementa a arquitetura de software 10 paradescobrir outros nós (e a funcionalidade correspondente de) outros nós queimplementam a arquitetura de software 10.
A figura 11 ilustra uma interface de exemplo da arquitetura desoftware 10 com um controle de aparelho onde a arquitetura de software 10da figura 1 é invocada três vezes do planejador (MAIN) de acordo com ainvenção. Também é mostrada a invocação de MAIN em WIDE.WideExecQ.WIDE.WideExec() subseqüentemente chama de volta a arquitetura desoftware 10 de acordo com a figura 33, onde o componente da arquitetura desoftware 10, WideCommHamdler5 expõe funções. SA_AcceptData() eSA_BuildData(). Também é mostrada uma invocação de MAIN emSA_WideComm() (também uma função exposta por um componente daarquitetura de software 10) que finalmente resulta na invocação mostrada nafigura 33 na função WIDE.QueueMsg() do componentes WIDE do ambienteoperacional de software 16A.A figura 13 é uma ilustração esquemática da implementaçãode exemplo da arquitetura de software mostrada na figura 11, incluindo umaseção de inicialização de aparelho. A função de inicialização chama SA_Init()de uma rotina de inicialização antes da introdução do laço de execuçãoprincipal mostrado na figura 11.
A tabela em seguida a este parágrafo ilustra um exemplo dedocumentação de como APIs serão gerenciadas, incluindo o mecanismo deDiretivas de Compilador para controlar o emprego da funcionalidade expostaatravés das APIs da arquitetura de software 10.
<table>table see original document page 111</column></row><table>
Na tabela acima, Ids de API na faixa de 241 - 254 podem serusados sem consideração para padrões. Eles são destinados a permitir aprogramados a flexibilidade para usar a arquitetura de software 10 em umaaplicação onde a expectativa de reutilização é mínima. Nesses casos, issoeliminará a necessidade de desenvolver um Id de API e Tipo específicos parauma coleção de mensagens que são esperadas serem 'únicas'. Esses Idstambém podem ser usados para APIs candidatas padrão , que ainda nãoreceberam seu ID. oficial. Adicionalmente, na tabela acima, As estimativas daRAM e da ROM são tomadas usando uma versão 4.3f de CompiladorCósmico HC08 da Motorola com a arquitetura de software 10 configuradapara ter 30 eventos dinâmicos permitidos (isto é, tamanho de heap), 7 APIsdefinidas e um tamanho de comando máximo de 15 bytes.
A figura 14 é uma ilustração esquemática de um roteadorvirtual incorporando a arquitetura de software da figura 1 de acordo com ainvenção, mostrando um mapeamento entre um par de implementações dearquitetura de software. O roteador virtual da figura 14 é um desenho desoftware que encapsula implementações (objetos, veja APIs 1 - 8 em cadalado do roteador da figura 14) da arquitetura de software 10 de modo que acolaboração entre um cliente embutido (lógica de aplicação, algoritmos, laçosfechados, seqüenciadores e máquinas de estado) e componentes embutidos(implementação de API de arquitetura de software 10: objetos comodescongeladores, aquecedores, sensores de temperatura, válvulas, etc.) éuniforme e idêntica, independente de se as entidades colaboram através darede ou compartilham um ambiente de tempo de execução.
A figura 14 mostra seis exemplos únicos de colaboraçãorotulados como tal, ilustrativos de como um par de ambientes operacionais desoftware 16A existentes em componentes de hardware separados 16 econectados por uma rede 14 usará os vários componentes de software 16B doambiente operacional de software 16A para criar acesso transparente entre alógica operacional de 59 e os componentes de software 16B dos ambientesoperacionais de software direito e esquerdo.
Antes da descrição dos exemplos de colaboração, umadescrição da estrutura da figura 14 auxiliará na compreensão dos exemplos decolaboração. Cada ambiente operacional de software 16A contémrepresentações de um subconjunto de componentes operacionais de softwareúteis (16B) contidos, incluindo: a arquitetura de software 10, a interface decamada de rede de comunicação interna 14A, o DAQ 30 e uma camada deabstração de hardware 80.
A camada de abstração de hardware 80 compreende: ummecanismo para encapsular o endereço fixo particular dos circuitos elétricosconectados em que as camadas operacionais de software de 80 operarão; einterfaces de software (28, 28A ou 82) encapsulando ocorrências de 16B naforma de (um dos seguintes): 28 a representação empacotada (uma coleçãoordenada de bytes) de uma mensagem trocada pela arquitetura de software 10,28A a representação empacotada (uma coleção ordenada de bytes) de umamensag3em trocada pela arquitetura de software 10, representando apenas acarga útil de aplicação 28A (os argumentos de dados válidos) esperados pelocomponente operacional de software 84 ou 86, 82 uma representaçãoalternativa de 28 ou 28A, onde a intenção e os valores de dados e açõesresultantes são funcionalmente idênticos, mas não da forma de uma coleçãoordenada de bytes. 82 está na forma de uma função única de software, tendoargumentos representados por variáveis nomeadas individuais cujo valor éderivado de 28A ou representado por uma coleção ordenada de bytesderivados de 28A.
GDMs de aplicação 84 (Global Design Modules) são variantesde 16B conhecidas como módulos de desenho global, que são componentesoperacionais de software padrão tendo sido submetidos a um processo dedesenvolvimento padrão, incluindo exigências funcionais e não funcionais,testagem, documentação e linhas de guia de implementação. Os GDMs deaplicação direcionam cuidados específicos de aparelho, tais comodescongeladores, aquecedores, fechamento de porta. Os GDMs de aplicaçãopodem ser classificados em pelo menos 2 variantes. A variante contém lógicade aplicação específica 59 usada para governar o comportamento e coletarinformação de uma coleção de outros componentes operacionais de software,incluindo uma pluralidade de outros 84(es) e 86(es). A variante 2 contémlógica de aplicação específica à parte de 59, usada para governar ocomportamento e coletar informação de um dispositivo ou sensoreletromecânico específico, tal como um aquecedor, evaporador, motor,válvula, solenóide, relê, pressão ou sensor de temperatura. A variante 2 podeser configurada para direcionar preocupações específica tornadas relevantespela variante de fabricação específica do dispositivo, pela configuraçãoparticular do dispositivo com base no modo de uso determinado pelasexigências de aplicação (isto é, valores de escalonamento) ou por umaconfluência de fatores, que criam preocupações específicas não mencionadasaté agora.
Os GDMs de infra-estrutura 86 direcionam questõesrecorrentes específicas que são independentes da aplicação da arquitetura dosistema da figura 1. Eles podem ser reutilizados através de uma pluralidade deaparelhos, tais como refrigeradores, fogões, máquinas de lavar louças,secadoras, máquinas de lavar roupas, etc; Os GDMs de infra-estrutura podemser classificados em pelo menos duas variantes. A variante 1 é associada comuma consulta particular resultante de uma combinação recorrente decomponentes elétricos ou restrições elétricas. Alguns exemplos são: restriçõesde interface de fabricação, ciclos de trabalho de dispositivos, característicasde carga elétrica, exemplos das quais são limites de corrente de pico decorrente elétrica e estado estacionário ou outra restrição, como os exemplosde modo de conversão de analógico para digital, dos quais são laços decorrente de 4 - 20mA vs. realimentações de tensão analógica de O - 5V. Avariante 2 está associada com aparelho e componentes de softwaresindependentes de aplicação conhecidos como funções de utilidade. . Elesproporcionam lógica usada por outros componentes de 16B, incluindo 59 e80. A variante 2 pode conter ou usar referências à Variante 1 de 86. Exemplosincluem temporizadores, detecção de passagem por zero e outroscomponentes úteis de software, cuja finalidade é mais utilitária do queacionada por exigências de aplicação ou eletromecânicas.
Um roteador virtual embutido 70 proporciona uma camada deencapsulamento pela qual dependências arquitetônicas (o método pelo qualum componente 16B é acessado por ou exposto a outro 16B [exemplos de16B são 30, 84, 86] dentro ou entre pelo menos dois ambientes operacionaisde software conectados por 14) entre a lógica de aplicação 59 (da camadaoperacional de software 16A do componente 16) e os componentescompreendidos pela camada de abstração de hardware 80, DAQ 30, outrocaso de lógica de aplicação 59 ou componente na mesma, ou qualquer outrocomponente útil 16B são minimizados ou eliminados.
Um componente de software 16B, usado por outroscomponentes de software 16B para obter referências a quaisquer outroscomponentes de software 16B, onde 16B obtido pode ser parte de umambiente operacional de software 16A, existente em ou no: mesmocomponente de hardware 16, um componente de hardware diferente 16,conectado por 14, um componente de hardware diferente 22 conectado poruma combinação de segmentos de rede, incluindo 14 ou um componente dehardware diferente 16 de um aparelho diferente 12, conectado por 14, umacombinação de segmentos de rede diferentes entre as duas ocorrências de 12 e14 do primeiro aparelho 12.
O componente de software 72 também proporciona osmecanismos para outros componentes de software residentes dentro domesmo ambiente operacional de software 16A para publicar a identificaçãonecessária e/ ou informação de roteamento na memória de 72 de modo apermitir os usos enumerados antes mencionados de 72. A informação deidentificação e roteamento pode ser associada com os componentes residentesdentro do mesmo ambiente operacional de software ou a informação deidentificação e roteamento pode ser associado com componentes à parte oscomponentes residentes dentro do mesmo ambiente operacional de software,mas são conhecidos por componentes residentes dentro do mesmo ambienteoperacional de software.
As estruturas 74 na memória de 70 são capazes de recebermensagens ou proporcionar funções para invocação de mensagens e sãocapazes de enviar mensagens ou proporcionar funções de chamada de voltapara a distribuição de informação. Essas estruturas tendo uma definição de 28,28A ou 82, correspondente a uma ocorrência de um componente de software,tais como componentes dentro de 80, 59 ou qualquer outro componente útilde software, localizado nas enumerações antes mencionadas de 72 e acapacidade para rotear a informação para aquele componente de software oupara um componente de software intermediário apropriado, tendo a mesma oufinalidade similar de 74.
Olhando agora para os possíveis exemplos de colaboração, éesperado que as estruturas 74 de 70 serão criadas e povoadas com base emconsultas de descoberta contendo solicitações para acesso aos componentesespecíficos de software 16B, que são identificáveis e giráveis, invocaçõesimplicando no referido acesso ou por componentes de software 16B que sãocapazes de invocar em 70, em nome de si mesmos ou de outros componentes16B, resultando na criação e na povoação das estruturas 74.
Colaboração 1: um comando é emitido por componente desoftware 59 do ambiente operacional de software direito 16A e recebido porum componente de software contido na coleção de 74 com um identificadorde API 1 dentro do componente 70 do mesmo ambiente operacional desoftware. Usando a identificação e a informação de roteamento contida dentrode 70, o componente identificado por API 1 transmite a informação recebidaatravés das outras camadas de operação de software locais 40 e 14A efinalmente transmitida através de 14 e recebida por 14A do ambienteoperacional de software 16A esquerdo. A mensagem é, então, manipulada por10 e roteada para o componente apropriado dentro de 74 do ambienteoperacional de software esquerdo. O 74 apropriado do componenteoperacional de software esquerdo, usando informação de identificação eroteamento contida dentro de 70 do mesmo componente operacional desoftware, então, invoca ou envia a mensagem para a implementação local deAPI 1 contida na camada de abstração de hardware de ambientesoperacionais de software esquerdo 80. Desse modo, a lógica de aplicaçãodentro do componente de software 59 do ambiente operacional de softwaredireito invocou uma função implementada no ambiente operacional desoftware do lado esquerdo sem informação nele contida para a realização dareferida invocação. Portanto, o valor do desenho implicado pela figura 14 éque a lógica de aplicação 59 é reutilizável com relação à localização dosoutros componentes de operação de software 16B dentro de uma pluralidadede ambientes operacionais de software 16A conectados por uma rede 14 ouuma pluralidade de segmentos de rede, que podem incluir 14.
Colaboração 2: Neste caso, a iniciação da mensagem é de 59do ambiente operacional de software esquerdo 16A. E ilustrado o caso onde ainvocação final está em um componente de software (neste caso API 2) dentrodo mesmo ambiente operacional de software, usando a mesma metodologiadescrita em maiores detalhes na Colaboração 1. Portanto, na Colaboração 2,uma disposição arquitetônica alternativa entre uma ocorrência de lógica deAplicação 59 para um outro componente útil de software (API2 de Camada deabstração de Hardware 80) é mostrada para não ter efeito sobre aimplementação de ambos. E, além disso, é a finalidade do componente desoftware 70, também sendo capaz de cumprir com as exigências deIdentificação e Interface impostas pela arquitetura de software 10, a fim deproporcionar essa capacidade.
As colaborações de 3 - 6 mostram usos adicionais para oRoteador Virtual Embutido 70. Os mecanismos usados para realizar essasvariantes são os mesmos que aqueles descritos nas Colaborações 1 e 2. Elessão incluídos para ilustrar a utilidade do desenho e os padrões de mensagensadicionais esperados a estarem disponíveis com relação ao DAQ 30. Ouvintesde eventos locais (3) e ouvintes de eventos remotos (4) de Lógica deAplicação 59 são dotados de uma interconexão para uma representação doagente de DAQ 30, proporcionando não só uma conexão ao DAQ noambiente operacional de software 16A local, mas também para o DAQ(s), queresidem em ambientes operacionais remotos. Mensagens de DAQ geradasbaseadas na ocorrência de eventos de DAQ podem ser transmitidaslocalmente (6) e remotamente (5) através de mecanismos disponíveis em 70.
A figura 15 é uma ilustração esquemática de um aparelhoatípico construído usando a arquitetura de 12 e compreendendo um nó depersistência 54, incorporado como um componente compreendendo aarquitetura de software 10 da figura 1, de acordo com a invenção. Enquanto oestado da técnica em sistemas embutidos é proporcionar local de persistênciade dados para PCB, o nó de persistência de acordo com a presente invençãoproporciona um serviço de persistência expostos aos componentes 16 e 22,através dos mecanismos da arquitetura de software 10 e/ ou do roteadorvirtual embutido 70.
Vários exemplos dos conectores e protocolos (RS-232, semfio, WIDE, etc.) são mostrados dentro dos componentes de cada cliente que secomunicam uns com os outros ao longo de uma rede interna em cadacomponente 16, do aparelho e do nó de persistência 54. Em resumo, o nó depersistência 54 é uma entidade lógica, que é descobrível e utilizável por todosos componentes 16 compartilhando uma rede 14, 20 ou uma conexão detempo de execução. Essa entidade proporcionará serviços e mecanismos deprotocolo necessários para ler, escrever e armazenar informação.
Como discutido acima, os aparelhos 12 são máquinasacionadas de "estado" e, tipicamente, têm uma interface de usuário (porexemplo, um teclado) usando que um usuário pode efetuar uma mudança noestado do aparelho 12 (por exemplo, mudar uma lavadora de um estadoinativo para um estado de "lavagem"). Como são desenvolvidas aplicaçõesque requerem comunicação externa com um aparelho 12 (por exemplo,testagem, diagnóstico, controle remoto, etc), há três técnicas possíveis pararealizar essa interface: 1) transformação dos comandos externos emcompressões de tecla (ver a figura 16 e a discussão); (2) uso de softwarepersonalizado para executar comandos de mudança de estado (veja a figura 16e discussão); ou (3) traduzir, simplesmente, compressões de tecla em umaAPI lógica (veja a figura 17 e discussão).
A figura 16 é uma ilustração esquemática de um método datécnica anterior pelo que comandos externos são traduzidos em compressõesde tecla para testagem de funcionalidade de aparelho eletrodoméstico. Nométodo da técnica anterior, um usuário atuará um aparelho 12 através de umaou mais compressões de tecla 56 para mudar o estado do aparelho (referido nafigura 16 como uma "máquina de estado" 12) para afetar a funcionalidade 58do aparelho. A fim de testar a funcionalidade 58 do aparelho, o usuáriopreparará comandos externos 60 e (1) traduzirá os comandos externos 60 emcompressões de tecla 56; ou (2) preparar software personalizado 62, queemularia o aparelho 12 de máquina de estado, para tentar duplicar afuncionalidade 58 do aparelho. Isso pode ser difícil e tendente a erro.
Em um novo método de operação e testagem de um aparelho,a figura 17 é uma ilustração esquemática da interação de compressões de tecla56 iniciadas pelo usuário e comandos de software alimentados externamente60, tipicamente de um cliente, são ambos passados como argumentos para aarquitetura de software 10 da figura 1 de acordo com a invenção, paraemissão de comandos para um aparelho eletrodoméstico 12 para, porexemplo, testar a funcionalidade 58 de aparelho eletrodoméstico e/ ou mudaro estado (isto é, operação real) do aparelho eletrodoméstico 12.
O método discutido com relação à figura 17 é novo, porque,em lugar de traduzir mensagens externas, tratando o aparelho 12 como umsistema fechado, ele expõe a funcionalidade do aparelho 12,independentemente de se a mensagem é recebida como uma key press externaou um comando de software local ou remoto em relação ao aparelho 12. Asmensagens (comandos) são processadas através de uma API da arquitetura desoftware 10 (agora um sistema aberto, conforme oposto ao sistema "fechado"da técnica anterior), enquanto preservando a validação e a realimentação parao usuário.
Correntemente, o software de controle de aparelho não estápreparado para validar e executar comandos externos. Para remediar isso, umaAPI de aparelho é definida que inclui funcionalidade de usuário, bem comocomandos de controle de máquina de nível baixo. Durante operações normais,quando uma chave é passada ou um comando externo é emitido, ele émapeado diretamente para uma chamada de função de API de funcionalidadede usuário como um ponto de entrada comum (por exemplo, uma teclaWASH é comprimida em um [teclado] de interface de usuário ou umcomando WASH externo é emitido chamará uma função setCycle(WASH)imediatamente, independente do estado do aparelho 12). Todocomportamento de validação e baseado em estado existirá no interior dessafunção, de modo que comandos externos são tratados com a mesma finalidadee executarão o mesmo código que as compressões de tecla 56.
Essa API pode ser implementada sem um re-desenho maior dosoftware de controle de aparelho. Apenas um software de interface de usuárioprecisará ser reorganizado para chamar funções de API como o ponto deentrada para qualquer comando, em lugar de apenas reagir às compressões detecla no interior da máquina de estado 12. O uso desse método da figura 17permite a fabricação de um aparelho 12 para testar e diagnosticar a interface,separadamente. Isso poupa tempo e esforço no desenvolvimento, diagnose etestagem de aparelhos. Isso também eliminará a necessidade de dispositivosmecânicos complexos de atuação de teclado, bem como chicotes de atuaçãomecânica que foram usados convencionalmente para testar interfaces deusuários e funcionalidade de aparelho.
Além disso, a API de aparelho 12 contém um comando paraenviar o aparelho em um modo de teste diagnóstico ou de fábrica. Nestemodo, todo código de validação de comportamento e comando com base emestado é desativado para permitir uma API de nível baixo. Comandos de APIneste modo podem acessar e controlar partes de nível baixo do aparelho 12,tal como leitura e escrita em EEPROM, compressão de teclas (56), leitura devalores de sensores, escrita em parâmetros de ciclo, atuação de relês e outrosatuadores, etc.
A interface de API discutida com relação à arquitetura desoftware 10 é um pacote de software orientado em objeto, que é efetivoquando um objeto (funcionalidade de aparelho) tem múltiplos clientes queprecisam interagir com ele (por exemplo, compressões de tecla 56 ecomandos externos 60). Essa é uma nova abordagem porque aparelhos nãocontêm, correntemente, software orientado em objeto e são, em geral,considerados como sendo um sistema fechado e tendo apenas um cliente:teclas de interface de usuário. A presente invenção considera que os aparelhos12 terão muitos clientes através da introdução de um barramento decomunicação interno (isto é, a rede 14) e conectividade externa 20. Essesclientes podem incluir aplicações da web, ferramentas de diagnostico,ferramentas de testagem e sistemas de automação domésticos, entre outros.Os aparelhos 12 com a arquitetura de software de API aquidescritos serão "à prova de futuro" e prontos para muitas aplicações remotasavançadas, que os consumidores podem solicitar. Essas podem incluirgerenciamento de energia, ferramentas aperfeiçoadas de serviços ediagnósticos e controle remoto e monitoração. Além disso, uma vez que a APIé o ponto de entrada em toda a funcionalidade de aparelho, os consumidorespodem se beneficiar da testagem aperfeiçoada de desenvolvimentoautomatizado e testagem de fábrica de aparelhos 12.
A arquitetura de software 10 também considera que o modelode dispositivo virtual pode ter ciência das capacidades correntes dodispositivo físico (o aparelho 12). Por exemplo, se um forno estiver assando,o relógio do aparelho não pode ser modificado. A sincronização decapacidades é uma solução geral para permitir a um modelo virtualreconhecer mudanças nas capacidades de um dispositivo com base em seuestado.
Correntemente, essa finalidade é alcançada através de códigoque é escrito por aparelho 12. A solução contida na arquitetura de software 10substitui código específico de dispositivo com uma solução geral. Essasolução é compreendida de mensagens adicionais que a arquitetura desoftware 10 difundiu, contendo o conjunto corrente de comandos inválidos(API e Op Code). Essa informação é avaliada em tempo de execução, demodo que a interface de usuário será expressa de tal maneira que o usuário sópode modificar aquelas características de dispositivo que são modificáveis, demodo que ao consumidor não é dada a oportunidade de modificar umacaracterística de dispositivo que é correntemente imutável, conforme ditadopelo dispositivo real.
A arquitetura de software 10 é um sistema de produto vetorialde aplicações e ferramentas. Essas aplicações ajudam a aumentar a qualidadee a velocidade de comercialização no processo de desenvolvimento deproduto. Isso é feito pela interação com os dados que estão armazenados namemória, no interior do aparelho 12.
A fim de permanecerem flexíveis, configuráveis e genéricos,as aplicações interagem com o aparelho pela especificação de localizaçõesnuméricas de memória (endereços) que são requeridas. Cada vez que osoftware no aparelho muda, porém, essas localizações na memória podem semover em torno e assumir um significado muito diferente. A fim de resolveresse problema, um padrão e gerador de arquivos de mapas de variáveis foramcriados.
O gerador de arquivos de mapas de variáveis toma os nomesde software (descrições textuais) escritos no código e associa os mesmos como endereço numérico e o tamanho daquele pedaço de dados. Então, sai essainformação em um formato de arquivo padrão. Isso é executado cada vez queo código é mudado e compilado. A informação nesse arquivo padrãoproporciona independência do compilador e de onde os dados estãolocalizados na memória.
O arquivo de mapas de variáveis é, então, lido por qualqueraplicação que deseje interagir com um aparelho 12 baseado em arquitetura desoftware 10. As aplicações são codificadas contra os nomes textuaissignificativos de dados, em lugar dos endereços numéricos de dados, o quesimplifica grandemente o desenvolvimento da aplicação.
O formato de arquivo de mapa de variáveis e o processo deuso são descritos na tabela abaixo.
<table>table see original document page 123</column></row><table>
Um exemplo do método usado no trabalho com o conceito demapa de variáveis inclui as seguintes etapas.
1. Um engenheiro constrói uma aplicação codificada contra osnomes descritivos textuais de dados significativos, localizados no controle doaparelho.
2. O código de controle de aparelho muda, resultando emnovas localizações dos dados de aplicação significativos.
3. Um engenheiro compila o novo código de aparelho, quetambém gera, automaticamente, um arquivo de mapas de variáveis associado.O novo código e o arquivo de mapas de variáveis são empregados juntos.
4. Quando a aplicação é executada contra o novo código, elenão tem que mudar, desde que tenha o arquivo de mapas de variáveisadequados.
5. Se novos dados forem requeridos pela aplicação, eles podemser facilmente identificados ou recuperados do arquivo de mapa de variáveis.
Desse modo, conforme mostrado acima, o engenheiro dedesenvolvimento precisa apenas lembrar a coluna "Nome de Variável", natabela acima e não precisa procurar, constantemente, os valores de endereçoque mudam constantemente nas colunas "Endereço" acima.
Fazendo referência agora à figura 18, o aparelhoeletrodoméstico 12, que é mostrado como um forno para finsexemplificativos, tendo um barramento de comunicação interno 200, pode seracoplado eletricamente a uma rede externa 202 através de um cartão deinterface de rede (NIC) 204 similar ao conector de interface de rede 20, antesmencionado. Um NIC é um dispositivo bem conhecido que conecta umcomputador ou outro cliente a uma rede e qualquer NIC adequado pode serutilizado com o aparelho 12. De acordo com uma modalidade da invenção, oNIC 204 é conectado eletricamente ao barramento de comunicação interno200 e adapta um protocolo de barramento de comunicação interno a umprotocolo de comunicação padrão, tal como TCP/IP e GSM, de modo que oaparelho 12 pode se comunicar com um cliente externo (não mostrado)através da rede externa 202, tal como uma rede de área local (LAN) e/ ou umarede de área estendida (WAN). Desse modo, o cliente externo pode secomunicar com a arquitetura de software 10 associada com várioscomponentes internos do aparelho 12, que residem na rede interna 14. Porexemplo, o aparelho 12 na figura 18 é mostrado como compreendendo umainterface de usuário (UI) 208 e um painel sensor -atuador 210, cada umcompreendendo um painel de circuito impresso (PCB), com a arquitetura desoftware 10 correspondente e o cliente externo pode se comunicar com aarquitetura de software 10 através do NIC 204.
O NIC 204 pode ser montado no barramento de comunicação200, o qual é, de preferência, exposto externamente, do aparelho 12 através dequalquer meio de montagem adequado, como é bem conhecido na técnica derede de computadores. De acordo com um modalidade da invenção, obarramento de comunicação 200 está localizado em uma reentrância 212,definindo uma abertura 214, que está em nível com uma parede, tal como umaparede traseira 216, do aparelho 12, conforme mostrado na figura 18. Quandoo barramento de comunicação 200 está localizado dentro da reentrância 212, obarramento de comunicação 200 e o NIC 204, quando montados nobarramento de comunicação 200, são protegidos de danos que podem ocorrerdurante o transporte do aparelho 12.
O NIC 204 pode ser dotado do aparelho 12 no momento defabricação ou pode ser comprado separadamente do aparelho 12 como umacessório. Desse modo, um consumidor pode escolher comprar o aparelho 12,sem a capacidade de se conectar à rede externa 202 e atualizar o aparelho 12em um momento posterior, para adicionar conectividade, se desejado.
O NIC 204 pode se comunicar com a rede externa 202 atravésde uma conexão cabeada ou sem fio. Por exemplo, o NIC 204 pode secomunicar com a rede externa 202 por intermédio de comunicações deinfravermelho sem fio (IR) ou outro meio sem fio de curto alcance. Nessassituações, o NIC 204 é montado, de preferência, em um lado frontal 218 doaparelho 12 para facilitar uma comunicação forte. De acordo com umamodalidade da invenção, o NIC 204 pode ser montado em uma reentrância220 no lado frontal 218 do aparelho, conforme ilustrado na figurai 9 comrelação a um forno, por exemplo. Quando montado no lado frontal 218 doaparelho, o NIC 204 pode ser conectado a um lado traseiro 222 do aparelhovia fios dispostos em um conduto de fiação 224, que se estende da reentrânciade montagem 220 no lado frontal 218 ao lado traseiro 222 do aparelho 12,onde os fios entram no aparelho 12, onde os fios entram no aparelho 12.
Outro exemplo de comunicação sem fio é a comunicação deradiofreqüência (RF). Por exemplo, o painel de circuito impresso de RP(PCB) 226 e uma antena montada externamente. De modo alternativo, o PCBde RF 226 pode ser montado externamente do aparelho 12, mas essaconfiguração requer uma conexão elétrica entre o PCB de RF 226 ecomponentes eletrônicos de controle de aparelho e um instalador deve abrirum gabinete ou caixa 228 do aparelho 12 durante instalação do PCB de RF226. De acordo com uma modalidade da invenção, o PCB de RF 226 émontado dentro do aparelho 12 e uma barreira de segurança não metálica 230,que é um condutor pobre de calor e eletricidade, é proporcionada como parteda caixa 228. Uma barreira de segurança exemplificativa 230 é uma janelaplástica, tal como uma janela de Plexiglas, integrada com a caixa de aparelho228, conforme mostrado na figura 20 para um aparelho 12 na forma de umforno para fins ilustrativo. A barreira de segurança 230 permite acomunicação de RF com o PCB de RF 226, montado internamente, sem umaantena externa e impede o contato humano com calor ou eletricidadeexcessiva.
Fazendo referência à figura 21, o aparelho 12 pode serconfigurado com hardware para facilitar serviço e diagnóstico do aparelho12. Em uma modalidade, um módulo de serviço 232, adaptado para conectarremovivelmente com um barramento de comunicação padrão no aparelho 12 éconfigurado para registrar dados de diagnóstico, tais como por meio decomunicação com a arquitetura de software 10 na rede interna 14. O módulode serviço pode se conectar prontamente à rede interna 14. A conexão domódulo de serviço 232 ao aparelho 12 é representada pela etapa 1, na figura21. O módulo de serviço 232 é, então, removido do aparelho 12 e conectado aum computador pessoal 234, tal como através de uma porta USB ou outrobarramento de comunicação padrão adequado. A conexão do módulo deserviço 232 ao computador 234 é representada pela etapa 2, na figura 21.Após o módulo de serviço 232 ser conectado ao computador 234, o módulode serviço 232 se conecta à Internet, de preferência, automaticamente ecarrega os dados de diagnóstico para um cliente remoto (não mostrado),conforme indicado pela etapa 3 na figura 21. O cliente remoto processo osdados de diagnóstico para identificar um problema ou falha do aparelho eimpedir, potencialmente, uma chamada de serviço ou, se o problema ou falharequer uma chamada de serviço, otimizar a eficácia e a eficiência da chamadade serviço. Opcionalmente, o módulo de serviço 232 pode baixar scripts detestagem personalizados com base nos dados de diagnóstico para executartestes no aparelho 12, a fim de nova diagnose ou eliminar o problema oufalha. O reconhecimento do módulo de serviço 232 para o aparelho 12executar os scripts de testagem é representado pela etapa 4, na figura 21.
Uma arquitetura exemplificativa para o módulo de serviço 232é ilustrada esquematicamente na figura 2IA. O módulo de serviço 232compreende um par de barramentos de comunicação, tais como barramentosseriais. De acordo com a modalidade ilustrada, o módulo de serviço 232compreende uma USB em uma extremidade para conexão ao computadorpessoal e um barramento RS-232 (EIA-232) 238 em uma extremidade opostapara conexão ao aparelho 12 e, particularmente, à arquitetura de software 10,residente em vários nós da rede interna 14 do aparelho. O módulo de serviço232 ainda compreende a memória 240, tal como uma memória flash, paraarmazenamento dos dados de diagnóstico, dos scripts de testagem, e de outrosdados. A memória flash 240 se comunica com uma lógica de serviço 242, quecontrola a operação do módulo de serviço 232.
A figura 22 ilustra uma arquitetura de hardware alternativapara serviço e diagnóstico do aparelho 12. Essa arquitetura é similar àquelamostrada na figura 21, exceto que o computador pessoal 234 é substituído poruma linha telefônica 244 e o módulo de serviço 232 é adaptado para conexãoà linha telefônica 244. Desse modo, a arquitetura alternativa da figura 22 émais adequada para usuários de aparelhos que não possuem um computadorpessoal ou não têm um computador pessoal conectado à Internet. O processopara a obtenção de dados diagnósticos é o mesmo que aquele descrito acimacom relação à figura 21; contudo, em lugar de conectar o módulo de serviço232 ao computador pessoal 234, o usuário conecta o módulo de serviço 232 auma tomada telefônica padrão 246 e o módulo de serviço 232 se conecta,automaticamente, à Internet através da linha telefônica 244.
Fazendo referência agora à figura 22A, o módulo de serviço232 para uso com o sistema mostrado na figura 22 é similar ao módulo deserviço 232, ilustrado na figura 2IA, exceto que a USB 236 é substituída poruma tomada de linha telefônica 248, tal como uma tomada de RJll paraconexão de um modem250 do módulo de serviço 232232 com a linhatelefônica 244 para estabelecer uma conexão com a Internet.
Os módulos de serviço 232 descritos acima podem ser dotadosdo aparelho 12 no momento da fabricação ou vendidos como um acessóriodurante ou após a venda do aparelho 12. Outros vários tipos de módulos deacessórios podem ser dotados do aparelho 12 ou comprados mais tarde porum consumidor para atualização do aparelho 12. Um módulo de acessórioexemplificativo pode compreender um expositor, conectável, operavelmente,à rede interna 14 e à rede externa 202 e visível para o usuário, quandomontado no aparelho 12. O expositor pode comunicar vários dados para ousuário, incluindo, mas não limitado aos mesmos, dados, tais como estadooperacional, relacionado com o aparelho 12 e obtido através da arquitetura desoftware 10 na rede interna 14, ou informação baixada da Internet através darede externa 202. Um módulo de acessório exemplificativo é um módulo deestação de intempéries 252, que é mostrado na figura 23, conforme montadoem um aparelho 12, na forma de um refrigerador, para fms ilustrativos. Alémde mostrar informação relacionada com as intempéries ou outra informaçãoque possa ser baixada da rede externa 202, o expositor do módulo de estaçãode intempéries 252 também pode incluir uma ou mais almofadas de toque ouuma tela de toque 256, com áreas seletoras 254 para controlar váriasoperações do refrigerador, como para controlar um distribuidor de gelo e umaluz e para acessar ajustes, tais como a temperatura, do refrigerador.
A figura 24 ilustra a estrutura de pacote preferida para umamensagem fragmentada. Essa estrutura de pacto, de preferência, é usada paracomunicação, quando a carga útil da mensagem é maior do que a do protocolosubjacente. Essa estrutura de pacote de fragmentação foi previamente descritana integridade da mensagem de múltiplas cargas úteis concernentesdiscutidas; contudo, um breve resumo pode ser aqui relacionado. Em umamensagem fragmentada, a estrutura de pacote padrão, descrita na figura 4 é,de preferência, usada no primeiro fragmento. Todos os fragmentossubseqüentes , de preferência, usam a estrutura de pacote descrita na figura24. A diferença entre esses protocolos está no Byte 2.
Para a totalidade de uma mensagem fragmentada, o indicadorFrag será estabelecido. O indicador MFP (mais fragmentos pendentes) seráestabelecido até o fragmento final da mensagem fragmentada. O MID (id demensagem) dá a cada mensagem fragmentada (o grupo de fragmentos) ummanipulador ou id, impedindo a fusão de mensagem fragmentada separada.FID (id de fragmento) dá a cada fragmento de uma mensagem fragmentadaum manipulador ou id, permitindo a detecção de um fragmento perdido. Umaexplanação mais profunda pode ser encontrada na discussão sobre aintegridade de mensagem de múltiplas cargas úteis.
A figura 25 proporciona operações de exemplo do protocolode fragmentação discutido dadas na figura 24. A explanação desse protocolopode ser encontrada na seção de integridade de mensagem de múltiplas cargasúteis.
As figuras 26A e 26B representam arquiteturas alternativaspara localização da informação de endereço e de Identificador de modo quemensagens bem formadas podem ser construídas e enviadas para a arquiteturade software da figura 10, resultando na criação de evento dentro de DAQ 30da figura 5. Como previamente mencionado, o agente de DAQ 30 requer umendereço de memória de variável para registro de evento. A figura 26A ilustraum exemplo de uso do esquema de aquisição de dados configurados pelocliente em que o cliente (computador ou outro cliente) retém um mapa dememória corrente, que relaciona um nome de variável a sua localização dememória. Esse endereço de memória, além do Identificador (Id de API e OpCode), é usado para construir uma mensagem bem formada, que é enviadapara DAQ. Como, nesse caso, o software de DAQ realiza a tarefa adicional deaquisição da localização de memória da variável especificada peloIdentificador. Uma vez adquirida, a DAQ usa as mesmas chamadas de funçãoreferenciadas no caso prévio da figura 26A para criar as estruturas de eventosno arranjo de DAQ de estruturas de evento contidas na heap de memória deDAQs.
Informação de mapa de variáveis na figura 26A relacionanomes simbólicos de variáveis aos seus endereços na memória de 16A. Afigura 26B relaciona Identificadores de variáveis (Id de API) aos seusendereços na memória 16. A razão para as arquiteturas alternativas é queessas suportam interações com um ator humano que poderia achardesvantajoso trabalhar em nomes simbólicos (que tendem a ser significativose a se comunicar com a utilidade da variável) e interações com outrasinstancias da arquitetura de software 10 ou algum componente 16 ou 22 oualgum outro componente de software que é capaz de interagir com arquiteturade software 10. Em interações baseadas em software (interações nãohumanas) é vantajoso não usar nomes simbólicos visto que eles requeremmais memória para armazenar, mais largura de banda para transmitir e maisciclos computacionais para processar. Na verdade, identificadores numéricospodem ser substitutos para nomes simbólicos. A arquitetura de software 10usa o ID de API de identificador numérico e Op Codes como substitutosnuméricos para nomes simbólicos. Identificação numérica adicional estádisponível para qualquer ocorrência válida de Id de API. Onde a identificaçãonumérica prévia é suficiente para proporcionar um índice único porcomponente 16 residente na rede 14 e onde a ultima, a informação deidentificação adicional pode ser obtida usando uma consulta secundária,requerendo um componente da identificação numérica prévia, Id de API.
Então, juntos, o Id de API e a identificação numérica adicional (a última),proporcionam identificação única dentro da totalidade de componentes desoftware possíveis, capazes de serem representados dentro da arquitetura desoftware 10.
A figura 27 proporciona um exemplo de uso do esquema deaquisição de dados configurado pelo cliente, usando o mapa de variáveisembutido. Aqui, o Nó A registra um evento no Nó B usando X de APIconhecido publicamente e Op Code Y que liga à variável de evento desejada.
A seguir, o Nó C tenta registrar para o mesmo evento, usando X de API e OpCode Y. Como o par de API e Op Code foram previamente registrados peloNó A, a solicitação do Nó C é rejeitada. Contudo, o Nó C, então, solicitadados do mapa de variáveis remotas (embutidas) com o comando de Dados deVariáveis Remotas obtido. Nó B responde com informação, incluindo oendereço de memória de variável desejado. O Nó C, então, usa esse endereçode memória para registrar um evento, mas esse tempo com um par diferentede API e Op Code.
A figura 27 também pode ser pensada como divulgando doiscenários de mensagens referentes à criação de eventos sugerida na figura 26B.
O primeiro cenário descreve as Mensagens entre os Nós AeB, ambos osquais se comunicam através da rede de comunicação interna 14 e que écompatível com arquitetura de software 10. No primeiro cenário, o Nó B écapaz de agir de acordo com a solicitação do Nó A. O segundo cenáriodescreve as mensagens entre os Nós C e B3 ambos os quais se comunicamatravés da rede de comunicação interna 14 e são compatíveis com arquiteturade software 10. Nesse cenário, o Nó B não pode agir de acordo com asolicitação do Nó C porque o Id de API e Op Code na mensagem 3 já tinhamsido alocados por uma solicitação prévia. Nesse caso, o Nó B respondeapropriadamente, resultando em uma consulta (5) de Nó C, resultando emuma mensagem de rede (6) do Nó B, contendo a informação necessáriapermitindo ao Nó C recriar a mesma estrutura de memória de NVOEvent dafigura 33 com uma ID de API e Op Code únicos para aDynamicMemoryHeap da figura 33 de arquitetura de software 10 do Nó B.
A figura 28 ilustra a funcionalidade de notificação de eventoconfigurável proporcionada pela presente invenção. De preferência, eventossó notificarão clientes externos quando disparados por falha. Contudo, podeser desejado que essa notificação externa tenha "som diminuído" em algunsmomentos sem remover realmente o evento do agente de DAQ 30.Adicionalmente, pode ser desejado que a aplicação interna dentro daarquitetura de software 10 seja notificada, quando um evento ocorre. Dessemodo, a presente invenção proporciona essa funcionalidade. Comopreviamente discutido, notificação externa pode ser alterada usando ocomando Set Externai Event On/Off dentro de API de DAQ. Adicionalmente,a arquitetura de software 10, de preferência, proporciona uma função internapara ligar e desligar a notificação interna. A figura 28 mostra exemplos denotificações de eventos segundo as configurações possíveis.
Dessa maneira, a invenção tem a capacidade de desativar ereativar a realização de NVOEvents da figura 33 na rede de comunicaçãointerna 14. Além disso, a capacidade para desativar e reativar a realização dosNVOEvents da figura33 como mensagens internas enviadas para ocomponente de software 16B dentro do mesmo ambiente operacional desoftware 16A da arquitetura de software 10.
A figura 29 ilustra a funcionalidade de um evento reconhecidodentro da presente invenção. Em um evento reconhecido, a arquitetura desoftware espera um tempo pré-determinado por uma mensagem dereconhecimento do cliente até o processamento do evento seguinte. Se otempo pré-determinado expira, um número pré-determinado de repetidastentativas é executado. De preferência, todos os eventos são supostos seremnão reconhecidos por falha. Desse modo, após enviar um evento para o(s)cliente(s), o agente de DAQ 30 imediatamente processa o evento seguinte.Contudo, algumas aplicações requerem que eventos sejam reconhecidos paraassegurar que a mensagem foi recebida pelo solicitante do evento. Usandoessa técnica, o emissor pode reenviar o evento, se o reconhecimento não forrecebido. O reconhecimento confirma que o solicitante recebeu o evento. Avantagem para a modalidade preferida de fornecimento da opção para eventosreconhecidos é que é o solicitante que determina a necessidade doreconhecimento de acordo com as exigências de aplicação. Portanto, quando osolicitante cria o evento usando os mecanismos proporcionados pelaarquitetura de software 10 dentro da interface para DAQ 30, informação éincluída na mensagem 28A, o que proporciona uma outra classificação doevento como reconhecido ou não reconhecido. Conforme mostrado noexemplo na figura 29, com a ocorrência de um evento reconhecido, aarquitetura de software bloqueia todos os outros eventos, enquanto espera porum reconhecimento do cliente. Se nenhum reconhecimento for recebido, aarquitetura de software 10 re-enviará o evento após uma quantidade de tempoconfigurável. Essa seqüência de tentativas ocorrerá uma quantidade de vezesconfigurável, até que, finalmente, a arquitetura de software pára de tentarenviar o evento e notifica a aplicação através de uma função chamar de voltade falha.
A figura 30 ilustra as características de segurançaproporcionadas dentro da presente invenção. Como a execução de funçõescríticas pelos nós externos é possível através dos protocolos previamentedescritos, a presente invenção proporciona um mecanismo de barreira deproteção para restringir o acesso à execução do comando. Comandos que sãoconsiderados críticos para a segurança podem ser relacionados em uma tabela,de preferência, no arquivo SAVriableMap.h, antes da compilação. Oscomandos podem ser relacionados especificamente (com uma API e OpCode) ou como APIs totais (com uma API específica e um Op Code = OxFF).
Os comandos relacionados nesta tabela são reivindicados estarem atrás dofirewall. Conforme mostrado na figura 30, a invenção proporciona três níveisde acesso de segurança: Acesso Negado, Acesso Concedido e AcessoConcedido Temporário.
De preferência, todos os nós começam com um nível de acessode Acesso Negado por falha. Neste nível de acesso, ao nó é permitido apenasexecutar os comandos na frente do firewall. Desse modo, os comandos atrásdo firewall (ou relacionados na tabela de barreira de proteção) não têmpermissão para serem executados. Com a submissão bem sucedida de umasenha permanente (dentro da carga útil da mensagem de realimentação dePublicar Nó), um nó é promovido ao nível de segurança de AcessoConcedido. Nesse nível de acesso, é permitido ao nó executar todos oscomandos, na frente e atrás do firewall. Para acesso temporário atrás dofirewall, um nó pode submeter com sucesso uma senha de acesso temporário(dentro da carga útil da mensagem de realimentação de Publicar Nó). Nessenível de acesso, é dado ao nó acesso a todos os comandos, na frente e atrás dofirewall, para uma quantidade de tempo confígurável. Após esse tempo terexpirado, o nível de acesso do nó é revertido para seu estado anterior.
Especificamente, a figura 30 considera duas senhas, cada umarepresentando um nível de segurança reconhecido pela lógica do firewall decomando. Uma senha será transmitida por um componente ou cliente quandoa mensagem de API de DAQ, publicar Nó de SA, é difundida (veja bytes 3 e4 ou Op Code 2). Uma das senhas representa acesso permanente a todos oscomandos especiais que são considerados estarem atrás do firewall. Asegunda senha concederá acesso temporário a todos os comandos especiaisque são considerados estarem atrás do firewall. Sem uma senha, os clientesterão acesso a todos os comandos que são considerados estarem na frente dofirewall. O engenheiro responsável pela instalação da arquitetura de software10 em um componente 16 do aparelho eletrodoméstico 12 determinará quecomandos estão na frente e que comandos estão atrás do firewall da figura 30.
A figura 31 ilustra um exemplo de operação da segurança dofirewall proporcionada pela presente invenção e mostrada na figura 30. Porfalha, um nó não tem acesso aos comandos atrás do firewall. Assim, conformemostrado, se um nó sem acesso tenta executar um comando de barreira deproteção, será rejeitado. Após uma submissão incorreta de senha, o comandode barreira de proteção ainda será rejeitado. Apenas após uma submissão desenha bem sucedida é permitido ao nó executar o comando de barreira deproteção.
A figura 32 ilustra as interfaces públicas padrão que aarquitetura de software 10 é capaz de implementar. E mostrada aApplicationSpecificAPI (API Específica de Aplicação), que é ainda povoadacom funcionalidade útil pelo programador de acordo com as necessidades daaplicação. Também é mostrado um exemplo de associações com outroscomponentes de software do ambiente operacional de software com que aarquitetura de software 10 interagirá.
A figura 33 ilustra a implementação preferida da arquitetura desoftware 10. São mostradas as funções internas e as alocações de memórianecessárias para realizar e suportar a funcionalidade implicada pela figura 32.Também são mostradas classes auxiliares (Command Handler, DynamicMemory Heapj Update Handler, NVOEvent, TimeHandler5WIDECommHandler, Message Parser e appSpecificCommandHandler), quemostram o agrupamento funcional das funções internas e alocações dememória necessárias. Também estão mostradas associações entre as classesauxiliares.
A figura 34 mostra a organização preferida de arquivos decódigo fonte da arquitetura de software 10.
A figura 35 mostra uma coleção de diagramas de estado inter-relacionados para três estados primários (COMM_IDLE,COMM_EXPECTING_ACK e COMM_PENDING), com cada estado,possivelmente, tendo uma pluralidade de sub-estados e assim por diante. Afuncionalidade representada aqui está relacionada com as associações decolaboração mostradas na figura 33. Sua invocação também é referenciada nafigura 11 como uma das funções de interface padrão invocadas do laço deexecução de MAIN do sistema operacional de software na arquitetura desoftware 10.
A função MAIN do ambiente operacional de software a6A(mostrado na figura 33 e na figura 11) invoca SA_WideComm() mostrado nadefinição de classe de SA (onde SA e sua funcionalidade agregada é aarquitetura de software 10). O resultado da invocação de função é mostradona figura 35. Conforme mostrado na figura 11, MAIN invocaSA_WideComm() periodicamente dentro da execução de sistemasoperacionais de software.A figura 35 mostra uma 2a interação indireta com MAIN que éo resultado de MAIN invocando na função WIDE WIDE_EXEC(). Essacolaboração é mostrada na figura 11 e na figura 35. Nesse caso, a camada deoperação de software WIDE 14A dentro da invocação da funçãoWIDE_EXEC() chama WIDE.BuildDATA(), que, por sua vez, chamaSA.WideCommHandler.SA._BuildData() dentro de 52. Na figura 35, essainvocação é mostrada dentro do estado COMM_PENDING. Esse curso deexecução ocorre quando, no estado prévio de COMM_IDLE, a lógica dentrodos sub-estados de COMM_IDLE resulta em uma mensagem pendente quechega para a rede 14 de WIDE. Conforme mostrado na figura 33, essatransição de estado é realizada pela invocação da funçãoWIDE.Queue.Message(). Essa invocação resulta na invocação da lógicacontida dentro do estado COMM_PENDING da figura 35.
O estado COMM_EXPECTING_ACK da figura 35 é umresultado de um evento de saída tendo sido criado, inicialmente, com umreconhecimento de denotação de indicador especial requerido. Se o evento(também referido como atualização) que está sendo operado dentro do estadoCOMM_PENDING requer reconhecimento, a transição de estado deCOMM_PENDING será para COMM_EXPECTING_ACK. Nesse caso, oevento será reenviado, pela re-introdução do estado COMM_PENDING, seum tempo tiver expirado sem o recebimento da mensagem deReconhecimento esperada. Esse processo será repetido até que umReconhecimento seja recebido ou até que o parâmetro de repetiçãoconfigurável (MAX_EVENT_RETRY, que é incrementado cada vez que oevento é retransmitido) é excedido.
A figura 36 mostra uma coleção de diagramas de estado deUML inter-relacionados. São mostrados quatro estados primários (READY,TRANSMIT SNAPSHOT, UPDATES_BLOCKED ePROCESS_DAQ_EVENTS). A funcionalidade aqui representada estárelacionada com as associações de colaboração mostradas na figura 33. Suainvocação também é referenciada na figura 11 como uma das funções deinterface padrão invocadas do laço de execução MAIN 11 do ambienteoperacional de software 16A na arquitetura de software 10.
O propósito da funcionalidade representada pela figura 36 éavaliar as estruturas (NVOEvent) 31 da figura 33, determinando se ascondições para a transmissão de evento ocorreram, coletando aquelas eajustando os indicadores apropriados (Updates_Pending & Bounded Update)de modo que, quando as Máquinas de Estado de 35 estão executando,condições de eventos detectadas pela DAQ 30 são realizadas como WIDEPackets 20 no barramento WIDE 14.
A figura 37 mostra dois estados primários (MSG_READY eMSG_PROCESS). A funcionalidade aqui representada está relacionada comas associações de colaboração mostradas na figura 33 onde WIDE chamaSA.WideCommHandler.S.A.AcceptData(). A invocação nessas máquinas deestado também são referenciadas na figura 11 como funções invocadas dolaço de execução MAIN 11 do sistema operacional de software na arquiteturade software 10, onde MAIN chama SA.SA_ProcessIncomingEvents(). Essasmáquinas de estado inter-relacionadas governam a execução de comandos deentrada, respostas para solicitações e a manipulação de eventos.
A figura 38 mostra a execução de uma coleção ordenada demensagens das classes na figura 33 do ambiente operacional de software.Essas mensagens representam o curso de execução para um conjunto comumde lógica referenciado como "Send WIDE Message", nas figuras 39, 40, 41 e42. A invocação de MAIN e WIDE (via WIDE_EXEC() é mostrada na figura 11.
A figura 39 mostra a execução de uma coleção ordenada demensagens das classes na figura 33 do ambiente operacional de software.Essas mensagens representam uma interação dentro de um ambienteoperacional de software 16A contendo a arquitetura de software 10. Ainvocação de MAIN é mostrada na figura 11. O diagrama ilustra asmensagens requeridas para adicionar uma estrutura bem formada de memóriade NVOEvent à DynamicMemoryHeap.
A figura 40 mostra uma coleção ordenada de mensagens dasclasses na figura 33 do ambiente operacional de software. Essas mensagensrepresentam uma interação dentro de um ambiente operacional de software16A contendo a arquitetura de software 10. O diagrama ilustra a execução demensagem da figura 37. E a invocação de MAIN é mostrada na figura 11.0propósito da funcionalidade representada pelo diagrama é avaliar as estruturasde memória de NVOEvent contidas dentro de DynamicMemoryHeap, coletaraquelas e seus valores de dados apropriados cujos critérios de disparo deevento foram satisfeitos e assegurar uma realização de pacotes 24 na rede decomunicação interna 14 para fins de notificação de outros clientes 16/22 dosNVOEvents que satisfizeram critérios de disparo e os valores de dadosassociados.
As figuras 41, 42 e 43 mostram uma coleção ordenada demensagens das classes na figura 33 do ambiente operacional de software parafins de processamento de comandos de entrada (NVOs) da Rede 14. Essasmensagens representam uma interação dentro de um ambiente operacional desoftware contendo a arquitetura de software 10. As invocações de MAIN eWIDE (via WIDE_EXEC()) são mostradas na figura 11. As figuras, descritasindividualmente em parágrafos subseqüentes, representam 3 casos de cursosalternados para execução.
A figura 41 ilustra o serviço de mensagens requerido paraprocessar mensagens de entrada da rede de comunicação interna 14 dosclientes 22/16 que não requerem uma resposta [Command-NoResponse],contendo outros dados significativos que não uma resposta transmitindo osucesso ou a razão para falha da mensagem que entra (o ACK ou NAK de IDde API= 1, Op Code = 1).
A figura 42 ilustra o serviço de mensagens requerido paraprocessar mensagens que entram do barramento WIDE 14 dos clientes 22/16,que requerem uma pluralidade de mensagens de resposta [Command-MultipleResponseRequired], contendo dados significativos em adição a umaresposta que transmite o sucesso ou a razão para falha da mensagem que entra(o ACK ou NAK de ID de API = 1, Op Code = 1).
A figura 43 ilustra o serviço de mensagens requerido paraprocessar mensagens que entram da rede de comunicação interna 14 dosclientes 22/16, que requerem mensagens de respostas simples {Command-SingleResponseRequerid], contendo dados significativos em adição a umaresposta que transmite o sucesso ou a razão para falha da mensagem que entra(o ACK ou NAK de ID de API = 1, Op Code = 1).
Controle de Taxonomia
Uma abordagem típica da técnica anterior para usar um novodispositivo de controle a fim de controlar um aparelho 12 é ter o componentede software do novo dispositivo de controle duplicando a lógica docontrolador de aparelho, de modo que o novo dispositivo de controle nãosolicita, inadvertidamente, ao componente de software do controlador doaparelho para realizar uma operação da qual ele é incapaz. Essa abordagem datécnica anterior ainda requer comunicações entre o aparelho 12 e o novodispositivo de controle com referência ao estado corrente do aparelho 12. Aabordagem da técnica anterior é ineficiente, uma vez que requer a duplicaçãode lógica no novo dispositivo de controle e no controlador de aparelho. Alémdisso, essa abordagem da técnica anterior requer que o novo software sejaescrito a cada vez que o controlador de aparelho é introduzido no novodispositivo de controle.
A finalidade de uma taxonomia de controle é evitar requereressa duplicação de lógica de software (freqüentemente chamada lógica denegócios) entre dois componentes de software inter-atuantes em umdispositivo de controle e um aparelho controlado. Em particular, isso permitea um gerador de comando em um dispositivo de controle controlarprontamente uma porção articulada 50, sem qualquer informação a cerca doaparelho que está sendo controlado, exceto a própria taxonomia de controle.Isso pode permitir a introdução de um dispositivo de controle "genérico" paracontrolar novos aparelhos, adaptando dispositivos de controle a ciclos oufuncionalidades recentemente disponíveis, que foram adicionados a umaparelho e aparelhos de comutação entre modos de operação onde ciclosoperacionais diferentes ou funcionalidades estão disponíveis. Também torna ocontrole dos aparelhos mais fáceis para os usuários uma vez que eles precisamapenas ser presenteados com escolhas que estão correntemente disponíveis doaparelho.
A presente invenção usa um conjunto de dados de taxonomiaestruturada para comunicar, de modo eficiente, ao dispositivo de controleexatamente aquela informação que o dispositivo de controle precisa, a fim degerar um comando bem formado para o aparelho. Como aqui usado, umcomando bem formado é um comando que tem significado e é realizável peloaparelho. A informação transportada pelo conjunto de dados inclui umahierarquia de opções e entradas de dados requeridas para formar o comandobem formado. Na modalidade preferida, também inclui informação semânticaou contextual para comunicar em palavras ou forma icônica as opçõesdisponíveis de modo que um usuário pode compreender as escolhasdisponíveis e introduzir os dados apropriados. Isso é realizado, de preferência,por rótulos dentro do conjunto de dados que estão associados com elementosde identificação arbitrários ou propícios a não usuários. Isso permite que alógica do componente de software que deve interpretar e processar aTaxonomia a ser desacoplada da apresentação da Taxonomia em umainterface de usuário (ex. língua estrangeira, Rótulos, Unidades).Fazendo referência à figura 44, em geral, ilustrando a estruturade controle aperfeiçoada e método da presente invenção, o aparelho sendocontrolado tem um componente de software 2 16B, tendo um controlador deaparelho e gerador de estado. O dispositivo de controle 16, 22 usado paracontrolar o aparelho tem um componente de software 1 16B com um geradorde comando, um construtor de seleção e um intérprete de estado. Odispositivo de controle 16, 22 pode ser uma interface de usuário programável,tal como um pda, uma tabela da web, um telefone celular, um LCD anexadoao aparelho ou um dispositivo de cliente.
A arquitetura de taxonomia, mostrada disposta no controladorde aparelho 16 e lógica, pode, alternativamente, ser disposta em umalocalização remota, tal como em um dispositivo de controle ou na internet. Aarquitetura de taxonomia inclui um gerador de taxonomia, um agente detaxonomia, um tradutor de taxonomia e uma estrutura de taxonomia. Aarquitetura de taxonomia gera um conjunto de dados de taxonomia, definindocapacidades de taxonomia, facilitando: a criação, pelo componente desoftware 1, de comandos bem formados que podem ser transformados peloagente de taxonomia e, opcionalmente, o tradutor de taxonomia em outroscomandos bem formados a serem executados pelo componente de software 2;a criação, pelo componente de software 1, do conteúdo de interface deusuário; e a validação de informação de estado antes de apresentar a interfacede usuário. Cada um desses componentes e suas inter-relações são descritasem maiores detalhes abaixo.
Criação do Conjunto de Dados de Taxonomia
O conjunto de dados de taxonomia é derivado das capacidadesoperacionais do controlador de aparelho 16, estruturado de maneira a permitirque o gerador de comandos no componente de software 1 interprete oconjunto de dados para realizar diversos resultados. Mais particularmente, devez em quando o agente de taxonomia usa a estrutura de taxonomia e ainformação de ciência de estado para gerar um conjunto de dados detaxonomia refletivo do subconjunto do universo de opções para comandos queestarão disponíveis de um aparelho para aqueles que estão correntementedisponíveis do aparelho.
Por exemplo, o conjunto de dados de taxonomia descreve asfunções disponíveis suportadas por um componente de software 16B, cadaargumento de funções e os valores válidos de cada argumento em umaestrutura de dados. Além disso, o conjunto de dados de taxonomia define osvalores válidos de variáveis de realimentação. Uma vez isso em uma estruturade dados, ela pode ser transmitida e retransmitida para clientes 16 ou 22,conforme requerido. Mudanças no conjunto de dados de taxonomia ocorrem àmedida que os ciclos de operação progridem e os comandos disponíveis ou osvalores válidos de seus argumentos mudam. Além disso, comandos adicionaispodem se tornar disponíveis ou podem ser tornar inválidos enquanto o ciclode operação progride de Idle (Inativo) (ver a figura 7).
Mais particularmente, o construtor da seleção registra com oGerenciador de Taxonomia para receber notificações para novos Agentes deTaxonomia. Em resposta, o Gerenciador de Taxonomia passa referências paratodos os Agentes de Taxonomia de volta para o construtor de seleção. Oconstrutor de seleção, então, solicita de cada Agente de Taxonomia umConjunto de Dados de Capacidades de Taxonomia. O Agente de Taxonomiaavalia uma Estrutura de Taxonomia compreendida pela Lógica deControlador de Componente de Software 2 ou, alternativamente, umDocumento para gerar um Conjunto de Dados de Capacidades de Taxonomia.
O construtor da seleção, então, povoa um conjunto de estruturas de pseudocomandos, que são uma hierarquia de opções, apropriadas para um PontoFinal de Aplicação (Exemplos de Pontos Finais de Aplicação são as interfacesde usuários para controle ou serviço ou outras camadas de aplicaçãointermediárias como um controlador de energia ou modo de automaçãodoméstica como férias ou boa noite) e passa aquelas estruturas para o PontoFinal de Aplicação, permitindo que o Ponto Final de Aplicação sejaconfigurado. Alternativamente, o construtor de seleção pode configurardiretamente o ponto final de aplicação.
Comunicação e uso do conjunto de dados
Quando um dispositivo de controle é colocado em rede com oaparelho, o gerenciador de taxonomia estabelece uma relação entre ocomponente de software Iea arquitetura de taxonomia, permitindo aogerador de comandos consultar a existência de conjunto de dados detaxonomia, proporcionando à arquitetura de software 1 acesso a um conjuntode dados de taxonomia e permitindo ao gerador de comando e intérprete deestado assinarem atualizações de conjunto de dados de taxonomia. O Tradutorde Taxonomia é um componente opcional que traduz os conjuntos de dadosde Taxonomia entre os Componentes de softwares 1 e 2, se os Componentesde Software 1 e 2 não forem projetados pra serem inoperáveis com a mesmamodalidade do conjunto de dados de Taxonomia.
O conjunto de dados de taxonomia é comunicado aocontrolador de componente de software 2 e para o construtor de seleção decomponente de software 1. Opcionalmente, o tradutor de taxonomia traduz oconjunto de dados de taxonomia para uma definição esquemática diferente dogerador de comando.
O gerador de comando usa o conjunto de dados de taxonomiapara construir e povoar estruturas de comandos disponíveis para a seleção poruma interface de usuário ou outras aplicações de cliente, compreendendo umconjunto de comandos válidos, seus argumentos válidos e cada um argumentavalores válidos. Mais particularmente, o gerador de comandos usa o conjuntode dados de taxonomia para construir um ou mais comandos bem formados,que podem, então, ser transmitidos para o controlador. Uma vez que oconjunto de dados de taxonomia pode ser reajustado e enviado em diferentesmomentos pelo agente de taxonomia ou o conjunto de dados pode seratualizado por meio de revisões do agente de taxonomia, o Componente deSoftware 1 pode ter um conjunto corrente de estruturas de comando, então,disponível para seleção por uma interface de usuário ou outra aplicação docliente.
Desse modo, em essência, através do uso da arquitetura deTaxonomia, o componente de software 2 ou seu proxy (o agente detaxonomia) comunica ao componente de software 1 um conjunto de regrasque podem ser interpretadas pelo componente de software 1, de modo que ocomponente de software 1 não solicita algo do componente de software 2,componente de software 2 que não pode acomodar e não opera em umavariável de estado que está ajustada para um valor inválido.
Antes de o Ponto Final de Aplicação ser capaz de começar aexecução, ele solicitará ou registrará atualizações de estado com um Intérpretede Estado. Isso permitirá que o Ponto Final de Aplicação a ser povoado comvariáveis de estado válido do Gerador de Estado antes que a lógica sejaexecutada e antes que o componente de interface de usuário seja processado.O Intérprete de Estado processará taxonomicamente conjuntos de dados deestado corretos e validam aqueles conjuntos de dados contra o Conjunto deDados de Capacidades de Taxonomia. O Intérprete de Estado solicita ouregistra atualizações de estado do Gerador de Estado do Componente desoftware 2 através dó Agente de Taxonomia. Com o recebimento de umestado taxonomicamente correto, o Intérprete de Estado proporcionará novosvalores de estado para o ponto final do aplicativo.
O Ponto Final de Aplicação executa, resultando em umprocessamento do estado corrente de componente de software 2 e umprocessamento de estruturas de pseudo comandos selecionáveis. Cada vez queuma seleção é feita da pseudo estrutura de comando, o construtor da seleçãopovoa um conjunto de sub-comandos válidos encontrados no conjunto dedados de Capacidades de Taxonomia apropriado para a seleção para seleçãoadicional pelo ponto final de aplicação. Quando uma seleção completa é feita,uma estrutura contendo todos os pseudo comandos é passada para o geradorde comandos.
O gerador de comandos construirá um comando bem formadotaxonomicamente correto e, opcionalmente, via o Tradutor de Taxonomia,invocará o comando no Controlador de Componente de Software 2 através doAgente de Taxonomia.
Execução
O comando bem formado é distribuído para o controlador doaparelho e executado pelo aparelho.
Tipicamente, o comando resultará em uma mudança de estadopara a memória associada do Componente de Software 2, que disparará umaatualização de estado criado pelo Gerador de Estado e resultando em novosprocessamentos de estado para o ponto final de aplicação . Essa mudança noestado resultará em uma nova Taxonomia de Capacidades ou uma Taxonomiade Capacidades parcial que podem substituir porções da Taxonomia deCapacidades original. A nova Taxonomia de Capacidades resultando em umconjunto de diferente de seleções válidas para controlar os ciclos de operaçãodo Componente de Software 2.
Validação
O intérprete do estado usa o conjunto de dados de taxonomiapara validar as atualizações de estado enviadas pelo Agente de Taxonomia ouTradutor do Gerador de Estado. Além disso, a Estrutura de Taxonomia, que éa fonte do conjunto de dados de Taxonomia, permite ao controlador validarcompletamente os comandos de entrada de acordo com a estrutura, sem lógicaadicional fora do conjunto de dados. Por exemplo, a Estrutura de taxonomiapode ser pensada conceitualmente como uma ou múltiplas árvores de decisão,com cada nível da taxonomia formando um ramo de decisão diferente ouconjunto de ramos de decisão, onde cada uma das opções e/ ou entradas dedados pode formar um nível diferente. Os ciclos de operação de um aparelhorequerem que o usuário selecione as opções e/ ou entradas de dados naformação do comando bem formado. Essas seleções podem ser comparadascom a árvore de decisão para confirmar cada ciclo, atributo de ciclo ou opçãode ciclo é encontrado dentro do ramo apropriado na árvore de decisão paraconfirmar que cada ciclo, atributo de ciclo ou opção de ciclo é encontradodentro da ramificação apropriada na árvore de decisão. Se o ciclo de operaçãoesperado , atributo e opções não são encontrados dentro do comando, então, éuma indicação de que o comando contém um erro. A estrutura de taxonomia,assim, serve para povoar a interface de usuário com opções e entradas dedados disponíveis para um dado estado do aparelho e também serve como alógica para validar o comando resultante.
O conjunto de dados de taxonomia é uma representação dedados da estrutura de taxonomia, que é um objeto ou estrutura de software.Contém todos os comandos, opções e configurações disponíveis para umaparelho no estado corrente e todos valores de estado válidos no estadocorrente. Por exemplo, o aparelho compreende múltiplos componentesinterconectados pela rede interna. Cada um dos componentes pode ter um oumais dispositivos. Cada um dos dispositivos tem uma ou maisfuncionalidades, que tem uma ou mais configurações. Todas asfuncionalidades para todos os dispositivos, necessariamente, não estarãodisponíveis durante cada estado do aparelho. Como tal, o conjunto de dadosde taxonomia compreenderá todas as opções e entradas de dados para todos osdispositivos que estão disponíveis correntemente.
As figuras 45 - 48 ilustram um exemplo do controle deTaxonomia no contexto de uma interface de usuário 16, 22 para umamicroonda que é povoada com um conjunto de dados de taxonomia,indicando as funções disponíveis do aparelho para o estado corrente. Ousuário pode selecionar dos parâmetros do conjunto de dados para formar ocomando bem formado que será emitido para controlara operação do aparelho 12.
A figura 45 ilustra a hierarquia de opções e entradas de dadosdisponíveis. O nível de topo da hierarquia começa com o ciclo 100, que émostrado para ter as opções de COOK, JET DEFROST, BAKED POTATO,STEAM COOK, AUTO REHEAT e DINNER PLATE, conforme exemplosilustrativos. O usuário deve selecionar uma das opções do nível de topo.
Uma vez que o usuário seleciona uma opção do nível de topo,o nível seguinte da hierarquia é exposto ao usuário com base na seleção denível de topo. Na figura 46, o usuário selecionou a opção COOK e a interfacede usuário, então, mostra entradas de dados na forma de TIME 102 e POWERLEVEL 104, disponíveis para aquela opção e necessárias para formar ocomando bem formado.
A figura 47 ilustra a situação onde a seleção de uma opção denível de topo expõe opções em um sub-nível. Na figura 47, JET DEFROST éselecionado, o que expõe o sub-nível de tipos de carne 106. O usuário deveselecionar a opção de carne apropriada ao completar o comando bemformado. As entradas de dados na forma de peso 108 e o nível dedescongelamento 110 são expostos e devem ser selecionados para completar ocomando bem formado.
Uma vez que o usuário tenha selecionado as opções e entradasde dados do conjunto de dados de taxonomia acessado pela interface deusuário, o gerador de comandos formará o comando bem formado e enviará omesmo para o Componente de Software 2 no componente do aparelho paraimplementação. Isso é feito apenas após o comando bem formado ter passadoatravés do processo de validação. O controlador e a lógica do Componente deSoftware 2, então, usa o comando bem formado para controlar a operação dosdispositivos para efetuar o comando bem formado.Um exemplo detalhado da criação do conjunto de dados detaxonomia e do comando bem formado provará ser útil. A criação do conjuntode dados de taxonomia para a microonda da figura 45 que divulga múltiplosciclos de cozimento foi construída pelo construtor de seleção do conjunto dedados de capacidades de taxonomia como é ilustrado em XML5 como segue:
<device id="microwave" Iabel=nMicrowave Oven">
<device id="ovenCavity" label="Microwave Oven">
<char name-'cycle" Iabel=nCycle" default="timedCook">
<setting name="timedCook" IabeH1COOK" />
<char name="turntable" label="Turntable" default="on">
<setting name="on" label="ON" />
<setting name="off label="OFF" />
</char>
<range name="duration" label- 'Duration" default="30" units="seconds"max="6039" min="60" inc="l" />
<range name="power" label="Power Levei" default="100" units="%"max="100" min="50" inc="10" />
</setting>
<setting name="jetdefrost" label="Jet Defrost"/>
<char name =foodType label =nFood Type"/>
<setting name="poultiy" label="POULTRY" />
<setting name="meat" label="MEAT" />
<setting name="fish" Iabel=nFISH" />
</char>
</setting>
etc
</char>
</device>
</device>
Se o usuário da microonda da figura 45 escolher Cozinhar por30 segundos em potência de 90% com o Prato Giratório Ligado, um comandobem formado do esquema Taxônomico será transmitido, opcionalmente, parao Tradutor de Taxonomia e para a Taxonomia. O comando da forma:
<command id=" microwave "><device id="ovenCavity"><sequence>
<step id="21">
<char name="cycle" setting="bake"/><char name="power" setting="90"/><char name="duration" setting="307><char name="turntable" setting="on'7></step></sequence></device></command>O Agente de Taxonomia, então, atravessará a Estrutura deTaxonomia para transformar o comando bem formado do esquemaTaxonômico em um comando bem formado do Controlador de Componentede Software 2 da estrutura de pacote 28. A Estrutura de Taxonomia é umsuper-conjunto do Conjunto de Dados de Capacidades de Taxonomia. Paracada elemento de comando especificável acima (isto é, Ciclo, Potência,Duração e Prato Girável) uma coleção adicional de palavras chave e valoresnecessários para formar a Carga Útil 28A será associada dentro da Estruturade Taxonomia. Essas palavras chave incluirão Id de API, Op Code e índice dePosição na Carga útil 28A, onde índice de Posição poderia ser umdeslocamento de bytes ou um deslocamento de bits.
O Conjunto de Dados de Taxonomia poderia ser construídopara representar diretamente o universo de comandos possíveis das APIs daarquitetura de software 10, proporcionando funcionalidade útil para umengenheiro ou técnico de serviço ou de laboratório.
Embora a invenção tenha sido descrita especificamente emconexão com certas modalidades específicas da mesma, deve sercompreendido que isso é à guisa de ilustração e não de limitação e o escopodas reivindicações anexas será construído tão amplamente quanto a técnicaanterior permitirá.

Claims (211)

1. Sistema caracterizado pelo fato de compreender:uma heap de memória gerado dinamicamente para softwareútil, a heap de memória compreendendo uma pluralidade de estruturas deeventos, cada uma incluindo pelo menos um de cada um dos indicadores namemória, externo à estrutura de eventos, operadores de eventos e argumentos; eum mecanismo de aquisição de dados configurado paraprocurar na heap de memória, avaliar condições de eventos como verdadeirasou falsas, com base em pelo menos um de cada um dos indicadores,operadores e argumentos e gerar uma mensagem de notificação, quando umacondição verdadeira é encontrada.
2. Sistema de acordo com a reivindicação 1, caracterizado pelofato de compreender uma memória associada com a heap de memória e aheap de memória estar alocada na memória associada, em tempo de compilar.
3. Sistema de acordo com a reivindicação 2, caracterizado pelofato de compreender uma arquitetura de software que gera as estrutura deeventos em tempo de execução.
4. Sistema de acordo com a reivindicação 3, caracterizado pelofato da arquitetura de software gerar cada uma das estrutura de eventos comuma única identificação.
5. Sistema de acordo com a reivindicação 3, caracterizado pelofato da arquitetura de software residir em uma rede de comunicação, que estáem comunicação com a memória associada e a arquitetura de software gerarmensagens e enviar as mensagens através da rede de comunicações para amemória associada, a fim de formar as estrutura de eventos.
6. Sistema de acordo com a reivindicação 5, caracterizado pelofato da arquitetura de software compreender uma interface de programa deaplicativo ("API") que gera as mensagens.
7. Sistema de acordo com a reivindicação 6, caracterizado pelofato da rede de comunicações compreender múltiplos nós, com a APIresidindo em pelo menos um dos nós.
8. Sistema de acordo com a reivindicação 7, caracterizado pelofato da rede de comunicações compreender uma rede comunicações internapara um aparelho.
9. Sistema de acordo com a reivindicação 8, caracterizado pelofato do nó compreender um componente do aparelho em que a API reside.
10. Sistema de acordo com a reivindicação 8, caracterizadopelo fato da rede de comunicações compreender um nó externo ao aparelho.
11. Sistema de acordo com a reivindicação 1, caracterizadopelo fato de cada uma das estrutura de eventos ter uma única identificação.
12. Sistema de acordo com a reivindicação 10, caracterizadopelo fato de compreender software de controle configurado para controlar umsistema de dispositivos através de uma série de etapas a fim de realizar umciclo útil de operação, com o software de controle gerando as estrutura deeventos.
13. Sistema de acordo com a reivindicação 12, caracterizadopelo fato da mensagem de notificação alterar a operação do programa decontrole.
14. Sistema de acordo com a reivindicação 1, caracterizadopelo fato de ainda compreender uma rede tendo uma pluralidade de nós, coma heap de memória estando associada com a rede.
15. Sistema de acordo com a reivindicação 14, caracterizadopelo fato da rede compreender uma rede de comunicações interna para umaparelho e efetuar o controle da operação do aparelho.
16. Sistema de acordo com a reivindicação 15, caracterizadopelo fato da rede compreender um nó externo da rede de comunicação internae a mensagem de notificação ser enviada para um nó na rede.
17. Sistema de acordo com a reivindicação 16, caracterizadopelo fato da mensagem de notificação ser invocada em uma função de retornode chamada.
18. Sistema de acordo com a reivindicação 14, caracterizadopelo fato da heap de memória residir em um dos nós e o mecanismo deaquisição de dados residir em outro dos nós.
19. Sistema de acordo com a reivindicação 18, caracterizadopelo fato de pelo menos um dos nós enviar mensagens de configuraçãoatravés da rede para criar uma estrutura de evento na heap de memória.
20. Sistema de acordo com a reivindicação 19, caracterizadopelo fato da mensagem de configuração ativar um nó para enviar umamensagem de reconhecimento mediante o recebimento de uma mensagem denotificação.
21. Sistema de acordo com a reivindicação 1, caracterizadopelo fato do mecanismo de aquisição de dados ser configurado de modo que amensagem de notificação pode ser colocada, seletivamente em um estadodesativado ou um estado ativado.
22. Sistema de acordo com a reivindicação 21, caracterizadopelo fato de, mediante uma mudança no estado da mensagem de notificação,uma mensagem de notificação correspondente ser enviada na rede.
23. Sistema de acordo com a reivindicação 1, caracterizadopelo fato dos operadores de eventos compreenderem pelo menos um de:maior do que, menos do que, igual a, em mudança, banda morta e um mapade bits.
24. Sistema de acordo com a reivindicação 1, caracterizadopelo fato do mecanismo de aquisição de dados ser configurado para gerar umamensagem de notificação em resposta a pelo menos uma das condições deeventos.
25. Sistema de acordo com a reivindicação 24, caracterizadopelo fato do mecanismo de aquisição de dados ser configurado para gerar umamensagem de notificação em resposta às múltiplas condições de eventos.
26. Sistema de acordo com a reivindicação 1, caracterizadopelo fato do mecanismo de aquisição de dados avaliar todas as estruturas deeventos, antes da geração da mensagem de notificação.
27. Sistema de acordo com a reivindicação 1, caracterizadopelo fato de ainda compreender um mecanismo de observação para avaliar asmensagens de notificação geradas pelo mecanismo de aquisição de dados afim de determinar o efeito cumulativo de mais de um evento.
28. Sistema de controle, caracterizado pelo fato decompreender:software de controle configurado para controlar um sistema dedispositivos através de uma série de etapas a fim de realizar um ciclo útil deoperação;uma heap de memória gerada, dinamicamente, pelo softwarede controle, a heap de memória compreendendo uma pluralidade de estruturasde eventos, cada uma incluindo pelo menos um de cada um dos indicadoresna memória externa à estrutura de eventos, operadores de eventos eargumentos associados com um evento; eum mecanismo de aquisição de dados adaptado para procurarna heap de memória, enquanto o software de controle está funcionando econfigurado para avaliar condições de eventos como verdadeiras ou falsas,com base em pelo menos um de cada um dos indicadores, operadores eargumentos e gerar uma mensagem de notificação configurável, quando umacondição verdadeira é encontrada.
29. Sistema de controle de acordo com a reivindicação 28,caracterizado pelo fato de compreender uma memória associada com a heapde memória e o software de controle alocar a heap de memória na memóriaassociada em tempo de compilar do software de controlador.
30. Sistema de controle de acordo com a reivindicação 28,caracterizado pelo fato do software de controle compreender uma interface deprograma de aplicativo ("API") que gera as estruturas de eventos.
31. Sistema de controle de acordo com a reivindicação 30,caracterizado pelo fato de cada uma das estruturas de eventos ter uma únicaidentificação que é atribuída pelo software de controle em tempo de execução.
32. Sistema de acordo com a reivindicação 28, caracterizadopelo fato da operação do software de controle ser alterada em resposta àmensagem de notificação configurável.
33. Sistema de controle de acordo com a reivindicação 32,caracterizado pelo fato de pelo menos uma mensagem de notificação sergerada em resposta às múltiplas condições de eventos.
34. Método para adquirir dados, caracterizado pelo fato decompreender:procurar em uma heap de memória de estruturas de eventostendo parâmetros de condições de pelo menos um dentre indicadores dememória, operadores de eventos e argumentos;identificar condições de eventos que avaliam como verdadeiropor meio da avaliação dos parâmetros de condições para as estruturas deeventos; egeração de uma mensagem de notificação, quando umacondição de verdadeiro é encontrada.
35. Método de acordo com a reivindicação 34, caracterizadopelo fato da heap de memória ser alocada durante compilação.
36. Método de acordo com a reivindicação 34, caracterizadopelo fato da estrutura de eventos ser criada durante um tempo de execução depelo menos uma mensagem de rede.
37. Método de acordo com a reivindicação 34, caracterizadopelo fato da heap de memória ser associada com um programa de controle deum aparelho tendo uma rede interna.
38. Método de acordo com a reivindicação 37, caracterizadopelo fato das estruturas de eventos serem criadas por uma interface deprograma de aplicativo associada com o programa de controle.
39. Método de acordo com a reivindicação 37, caracterizadopelo fato da operação do programa de controle ser alterada em resposta àmensagem de notificação.
40. Método de acordo com a reivindicação 37, caracterizadopelo fato da mensagem de notificação ser enviada através da rede interna paraa rede externa.
41. Método de acordo com a reivindicação 34, caracterizadopelo fato de cada estrutura de eventos ter um único identificador.
42. Método de acordo com a reivindicação 34, caracterizadopelo fato da mensagem de notificação ser enviada através de uma rede tendomúltiplos nós.
43. Método de acordo com a reivindicação 42, caracterizadopelo fato da mensagem de notificação ser enviada através da rede para um dosmúltiplos nós.
44. Método de acordo com a reivindicação 34, caracterizadopelo fato da mensagem de notificação ser invocada em uma função de retornode chamada.
45. Método de acordo com a reivindicação 34, caracterizadopelo fato de, seletivamente, ativar e desativar a geração da mensagem denotificação.
46. Método de acordo com a reivindicação 45, caracterizadopelo fato de enviar uma mensagem de notificação, quando a mensagem denotificação é, seletivamente, ativada e desativada.
47. Método de acordo com a reivindicação 34, caracterizadopelo fato da avaliação dos parâmetros de condições compreender a aplicaçãode um operador de eventos selecionado da lista de: maior do que, menos doque, igual a, em mudança, banda morta e mapa de bits.
48. Método de acordo com a reivindicação 34, caracterizadopelo fato da geração da mensagem de notificação ser feita após a avaliaçãodos parâmetros de condições para múltiplas estruturas de eventos.
49. Método de acordo com a reivindicação 34, caracterizadopelo fato de compreender a avaliação de múltiplas mensagens de notificaçãopara determinar o efeito cumulativo de múltiplas estruturas de eventos.
50. Método para controlar um sistema de dispositivos atravésde uma série de etapas para realizar um ciclo útil de operação, caracterizadopelo fato de compreender as etapas de:execução de um programa de controle para direcionar aoperação dos dispositivos através de uma série de etapas;geração, dinamicamente, durante a execução do programa decontrole, de uma heap de memória, a heap de memória compreendendo umapluralidade de estruturas de eventos, cada uma tendo parâmetros de condiçõescompreendendo pelo menos um de cada um dos indicadores de memóriaexternos para a estrutura de eventos, operadores de eventos e argumentosassociados com um evento;identificação de condições de eventos que avaliam comoverdadeiro, buscando na heap de memória ou estruturas, durante a execuçãodo programa de controle e avaliando os parâmetros de condições para asestruturas de eventos; egeração de uma mensagem de notificação configurável,quando uma condição verdadeira é encontrada.
51. Método de acordo com a reivindicação 50, caracterizadopelo fato de ainda compreender a atribuição a cada estrutura de eventos de umidentificador único, durante a execução do programa de controle.
52. Método de acordo com a reivindicação 50, caracterizadopelo fato de compreender a alteração da operação do programa de controle emresposta à mensagem de notificação.
53. Método de acordo com a reivindicação 50, caracterizadopelo fato de, seletivamente, ativar e desativar a geração da mensagem denotificação.
54. Método de acordo com a reivindicação 50, caracterizadopelo fato de compreender a avaliação de múltiplas mensagens de notificaçãopara determinar o efeito cumulativo de múltiplas estruturas de eventos.
55. Sistema de rede, caracterizado pelo fato de compreender:uma pluralidade de nós interconectados definindo uma rede decomunicações, com pelo menos um dos nós configurados para enviarmensagens através da rede de comunicações e pelo menos um dos nósconfigurado para receber mensagens através da rede de comunicações;pelo menos um identificador de um grupo pré-determinado deidentificadores está associado com cada um dos nós e identifica apenasaquelas funcionalidade que são aplicáveis àquele nó; eem que pelo menos um dos nós transmite o pelo menos umidentificador por uma mensagem enviada através da rede de comunicaçõespara recebimento de pelo menos um dos nós para, assim, publicar asfuncionalidades através da rede de comunicações.
56. Sistema de rede de acordo com a reivindicação 55,caracterizado pelo fato dos nós compreenderem componentes selecionados deuma lista consistindo de um sensor, um distribuidor, luz, filtro, motor,descongelador, aquecedor, evaporador, solenóide, relê, resfriador, controladorde motor, controladores de teclados numéricos e uma interface de usuário.
57. Sistema de rede de acordo com a reivindicação 55,caracterizado pelo fato da rede de comunicações ser configurada para secomunicar com outras redes.
58. Sistema de rede de acordo com a reivindicação 55,caracterizado pelo fato de o grupo pré-determinado de identificadores serconfigurável.
59. Sistema de rede de acordo com a reivindicação 55,caracterizado pelo fato da funcionalidade aplicável a um identificador serconfigurável.
60. Sistema de rede de acordo com a reivindicação 59,caracterizado pelo fato da funcionalidade ser configurável pela atribuição aoidentificador de uma nova função.
61. Sistema de rede de acordo com a reivindicação 59,caracterizado pelo fato da funcionalidade ser configurável dinamicamente.
62. Sistema de rede de acordo com a reivindicação 55,caracterizado pelo fato do identificador indicar um significado em adição auma funcionalidade.
63. Sistema de rede de acordo com a reivindicação 62,caracterizado pelo fato do significado poder ser re-atribuído.
64. Sistema de rede de acordo com a reivindicação 62,caracterizado pelo fato do significado poder variar, dependendo da rede.
65. Sistema de rede de acordo com a reivindicação 62,caracterizado pelo fato do significado do identificador variar entre os nós.
66. Sistema de rede de acordo com a reivindicação 55,caracterizado pelo fato de pelo menos um nó determinar sua própriaidentidade via um arranjo de identificadores publicados na rede.
67. Sistema de rede de acordo com a reivindicação 66,caracterizado pelo fato do arranjo de identificadores ser armazenado em umamemória associada com o pelo menos um nó.
68. Sistema de rede de acordo com a reivindicação 55,caracterizado pelo fato de pelo menos alguns dos identificadores incluíreminformação única a cerca de identificador.
69. Sistema de rede de acordo com a reivindicação 68,caracterizado pelo fato da informação única identificar, unicamente, oidentificador por toda a rede.
70. Sistema de rede de acordo com a reivindicação 68,caracterizado pelo fato da informação única identificar, unicamente, o nó portoda a rede.
71. Sistema de rede de acordo com a reivindicação 68,caracterizado pelo fato da informação única identificar, unicamente, oidentificador por todo o grupo de identificadores.
72. Sistema de rede de acordo com a reivindicação 55,caracterizado pelo fato de ainda compreender múltiplas instâncias de umidentificador no mesmo nó, com cada instância compreendendo informaçãoúnica para identificar unicamente cada instância.
73. Sistema de rede de acordo com a reivindicação 72,caracterizado pelo fato do identificador adicional ser um dentre gerado eatribuído.
74. Sistema de rede de acordo com a reivindicação 55,caracterizado pelo fato de um identificador associado com umafuncionalidade de um nó configurado para receber mensagens ser usado paraendereçar o nó para recebimento de uma mensagem.
75. Sistema de rede de acordo com a reivindicação 55,caracterizado pelo fato da mensagem ser escolhida de uma lista consistindo deum comando para usar uma funcionalidade, uma solicitação para informaçãoreferente a uma funcionalidade, uma resposta a uma mensagem de solicitaçãoe um reconhecimento de recebimento de comando.
76. Sistema de rede de acordo com a reivindicação 75,caracterizado pelo fato da solicitação para informação compreender umamensagem de resposta, solicitando identificadores.
77. Sistema de rede de acordo com a reivindicação 76,caracterizado pelo fato de ainda compreender uma mensagem de resposta emresposta à mensagem de solicitação, reconhecendo a relevância de pelo menosum identificador para pelo menos um nó.
78. Sistema de rede de acordo com a reivindicação 77,caracterizado pelo fato da mensagem de resposta, contendo os identificadoressolicitados incluir o número de instâncias do identificador solicitado.
79. Sistema de rede de acordo com a reivindicação 74,caracterizado pelo fato da solicitação para informação busca pelo menos umde um reconhecimento da relevância de um identificador especificado, umaidentificação de múltiplos identificadores relevantes para pelo menos um nó euma identificação de todos os identificadores relevantes para um nóespecífico.
80. Sistema de rede para um sistema de dispositivos operáveispara realizar, cooperativamente, um ciclo útil de operação, caracterizado pelofato de compreender:uma pluralidade de nós, cada um dos nós estando associadocom pelo menos um dos dispositivos, pelo menos dois dos nós sendoadaptados para enviar mensagens e pelo menos dois dos nós estandoadaptados para receber mensagens;um universo pré-determinado de identificadores; epelo menos um dos identificadores associados com cada umdos nós identificando que funcionalidades são aplicáveis aos dispositivosassociados com aquele nó do universo pré-determinado de identificadores.
81. Sistema de rede de acordo com a reivindicação 80,caracterizado pelo fato da coleção de uma pluralidade de dispositivoscompreender um aparelho.
82. Sistema de rede de acordo com a reivindicação 80,caracterizado pelo fato da coleção de uma pluralidade de dispositivoscompreender uma pluralidade de aparelhos em rede.
83. Método para identificar nós em uma rede tendo umapluralidade de nós, cada um dos nós tendo pelo menos um identificador degrupo pré-determinado de identificadores, com cada identificadoridentificando pelo menos uma funcionalidade aplicável a esse nó,caracterizado pelo fato de compreender:pelo menos um nó enviando através da rede uma mensagemconfigurada para indagar sobre a presença de pelo menos um identificador dogrupo pré-determinado de identificadores; epelo menos um outro nó enviando uma mensagem derealimentação, afirmando a existência do pelo menos um identificador no pelomenos um outro nó.
84. Método de acordo com a reivindicação 83, caracterizadopelo fato de que um nó9 irá ignorar um mensagem indagando pela presençade um identificador inaplicável.
85. Método de acordo com a reivindicação 84, caracterizadopelo fato de um nó ignorar a mensagem pela falha em enviar uma mensagemde realimentação em resposta à mensagem.
86. Método de acordo com a reivindicação 83, caracterizadopelo fato de uma mensagem poder ser difundida para um, alguns ou todos os nós.
87. Método de acordo com a reivindicação 86, caracterizadopelo fato de uma mensagem ser para um nó específico.
88. Método de acordo com a reivindicação 86, caracterizadopelo fato de um nó ignorar mensagens indagando por um identificadorinaplicável, se a mensagem for difundida para mais de um nó.
89. Método de acordo com a reivindicação 83, caracterizadopelo fato da mensagem ser uma consulta de descoberta que solicitainformação e a mensagem de realimentação ser uma mensagem de redecontendo a informação solicitada da consulta de descoberta.
90. Método de acordo com a reivindicação 89, caracterizadopelo fato da mensagem de realimentação ser enviada para um, alguns ou todosos nós.
91. Método de acordo com a reivindicação 90, caracterizadopelo fato da mensagem de realimentação ser dirigida para o nó que enviou aconsulta de descoberta.
92. Método de acordo com a reivindicação 83, caracterizadopelo fato da mensagem de realimentação se referir a pelo menos uma dentreavaliação de integridade de rede, ativação de comportamento de rededinâmica e configuração das interações entre nós.
93. Método de acordo com a reivindicação 83, caracterizadopelo fato de cada identificador representar um grupo de funcionalidadecomum.
94. Método de acordo com a reivindicação 93, caracterizadopelo fato da mensagem poder solicitar informação relacionada com pelomenos uma dentre a funcionalidade de um identificador e informação a cercado identificador.
95. Método de acordo com a reivindicação 94, caracterizadopelo fato do identificador ser implementado por um módulo de softwareresidente no nó e a mensagem solicitar informação referente à funcionalidadedo módulo de software e a identidade do módulo de software .
96. Método de acordo com a reivindicação 83, caracterizadopelo fato do envio da mensagem ser iniciado por um novo nó, difundindo umamensagem ativa de nó.
97. Método de acordo com a reivindicação 83, caracterizadopelo fato de um nó poder enviar uma mensagem indagando qualquer outro nópara pelo menos um dentre: um, alguns ou todos os identificadores funcionaissuportados e informação de identificador único.
98. Método de acordo com a reivindicação 83, caracterizadopelo fato da mensagem de realimentação incluir o número de instâncias daexistência dos identificadores solicitados.
99. Método de acordo com a reivindicação 98, caracterizadopelo fato do nó que está enviando a mensagem poder enviar uma mensagemde acompanhamento em resposta à mensagem de realimentação indagandopor informação de identificação adicional para identificar, unicamente, asinstâncias duplicadas de um identificador em um nó.
100. Método para identificar nós em um aparelho tendo umapluralidade de nós interconectados formando uma rede de comunicações, pelomenos alguns dos nós tendo um componente correspondente, em que oscomponentes são operavelmente acoplados pela rede de comunicações pararealizar, cooperativamente, um ciclo útil de operação, cada um dos nós tendopelo menos um identificador de grupo pré-determinado de identificadores,com cada identificador, identificando pelo menos uma funcionalidadeaplicável ao componente correspondente, caracterizado pelo fato decompreender:pelo menos um nó enviando através da rede um comandoconfigurado para indagar pela presença de pelo menos um identificador dogrupo pré-determinado de identificadores; epelo menos um outro nó enviando uma mensagem derealimentação afirmando a existência do pelo menos um identificador no pelomenos um outro nó.
101. Método de acordo com a reivindicação 100, caracterizadopelo fato de uma mensagem poder ser difundida para um, alguns ou todos os nós.
102. Método de acordo com a reivindicação 100 caracterizadopelo fato de que o comando é uma consulta de descoberta que solicitainformação e a mensagem de realimentação é uma mensagem de rede quecontém a informação pedida da consulta de descoberta.
103. Método de acordo com a reivindicação 100 caracterizadopelo fato de que a mensagem de realimentação relaciona a pelo menos um deavaliar integridade de rede, habilitando comportamento de rede dinâmico, econfigurar as interações entre nós.
104. Método de acordo com a reivindicação 100 caracterizadopelo fato de que o identificador é implementado por um módulo de softwareque reside no componente e o comando solicita informação relativo àfuncionalidade do componente do módulo de software e a identidade domódulo de software.
105. Método de acordo com a reivindicação 100 caracterizadopelo fato de que o enviando do comando é iniciado por um nó novo queradiodifunde um nó mensagem viva.
106. Método de acordo com a reivindicação 100 caracterizadopelo fato de que um nó pode enviar um comando que pede qualquer outro nópelo menos um dentre: um, alguns, ou todos os identificadores funcionaisapoiaram e informação de identificador sem igual.
107. Método de acordo com a reivindicação 100 caracterizadopelo fato de que a mensagem de realimentação inclui o número de exemplosda existência dos identificadores solicitados.
108. Método de acordo com a reivindicação 100 caracterizadopelo fato de que o nó que envia o comando pode enviar um comando deacompanhamento com respeito à mensagem de realimentação que pedeinformação de identificação adicional para identificar os exemplos duplicadosde um identificador exclusivamente a um nó.
109. Sistema para controlar uma pluralidade de dispositivosque têm pelo menos dois modos operacionais e conectado por uma rede decomunicação para formar uma rede de nós de cooperação, caracterizado pelofato de que inclui:uma primeira camada operacional de software configuradapara controlar a operação de pelo menos um dos dispositivos em um primeiromodo operacional com respeito a mensagens enviou na rede, euma segunda camada operacional de software configuradapara controlar a operação de pelo menos um dos dispositivos em um segundomodo operacional com respeito a mensagens enviadas na rede, onde asegunda camada operacional provê um nível diferente de intervenção entre asmensagens e a operação dos dispositivos que a primeira camada operacional.
110. Sistema de acordo com reivindicação 109, caracterizadopelo fato de que as primeira e segunda camadas operacionais de softwarepermitem para níveis diferentes de controle dos dispositivos pelas mensagensprover o nível diferente de intervenção.
111. Sistema de acordo com reivindicação 110, caracterizadopelo fato de que a segunda camada operacional de software permite operaçãode pelo menos um dos dispositivos sob circunstâncias onde a primeira camadaoperacional previne operação daquele dispositivo.
112. Sistema de acordo com reivindicação 111 caracterizadopelo fato de que a primeira camada operacional de software não permitecontrole direto de pelo menos um da pluralidade de dispositivos quando asegunda camada operacional de software permitir controle direto daqueledispositivo.
113. Sistema de acordo com reivindicação 109, caracterizadopelo fato de que a primeira camada operacional de software só permite osdispositivos operarem de modo a executar um ciclo predeterminado deoperação.
114. Sistema de acordo com reivindicação 113, caracterizadopelo fato de que a segunda camada operacional de software permite osdispositivos operarem em pelo menos um ciclo adicional de operação.
115. Sistema de acordo com reivindicação 114, caracterizadopelo fato de que o ciclo adicional de operação é pelo menos um de: um ciclode demonstração; um ciclo de desenvolvimento; um ciclo de detecção deerros; um ciclo diagnóstico; um ciclo que reduz o tempo de pelo menos umaetapa cronometrada de um dos ciclos predeterminados de operação; um cicloque desvia uma etapa operacional de um dos ciclos predeterminados deoperação; um ciclo que substitui uma etapa cronometrada por uma etapa queresponde a um evento de um dos ciclos predeterminados de operação; e umciclo que expõe o API de nível baixo à rede.
116. Sistema de acordo com reivindicação 109, caracterizadopelo fato de que ainda inclui pelo menos um dentre um cliente interno eexterno configurado para gerar a mensagem para mudar o modo operacionalentre os primeiros e segundos modos operacionais.
117. Sistema de acordo com reivindicação 109, caracterizadopelo fato de que pelo menos uma das primeira e segunda camadasoperacionais de software efetuam a operação cooperativa dos dispositivospara realizar umas séries de etapas relacionadas para realizar uma operaçãopredeterminada.
118. Sistema de acordo com reivindicação 117, caracterizadopelo fato de que os dispositivos são selecionados de uma lista que consiste emum sensor, um dispensador, um filtro, um motor, um aquecedor, e umresfriador.
119. Sistema de acordo com reivindicação 117, caracterizadopelo fato de que pelo menos um subconjunto da pluralidade de dispositivos étudo encontrado dentro de um aparelho.
120. Sistema de acordo com reivindicação 117, caracterizadopelo fato de que a pluralidade de dispositivos inclui uma pluralidade deaparelho em rede.
121. Sistema de acordo com reivindicação 109, caracterizadopelo fato de que a rede inclui pelo menos um dentre uma rede interna e umarede externa.
122. Sistema de acordo com reivindicação 121, caracterizadopelo fato de que o segundo modo operacional expõe para a primeira aparelhoa uma rede externa.
123. Sistema de acordo com reivindicação 109, caracterizadopelo fato de que um dos primeiro e segundo modos operacionais incluem ummodo operacional local e o outro dos primeiro e segundo modos operacionaisincluem um modo operacional remoto.
124. Sistema de controle para controlar uma pluralidade dedispositivos conectados por uma rede de comunicação para definir umamáquina operável para executar umas séries de etapas em um ciclo deoperação, caracterizado pelo fato de que inclui:uma interface de usuário configurada para receber entrada deum usuário para a seleção de um ciclo de operação de múltiplos ciclos deoperação;um primeiro elemento de sistema isolado da rede econfigurado para controlar a máquina para implementar o ciclo selecionadode operação para definir um primeiro estado de controle; eum segundo elemento de sistema exposto à rede e configuradopara controlar a máquina através da rede para implementar o cicloselecionado de operação para definir um segundo estado de controle.
125. Sistema de controle de acordo com reivindicação 124,caracterizado pelo fato de que a rede inclui uma rede interna que tem umapluralidade de nós, com pelo menos um nó que tem uma ou mais unidadesfuncionais, e cada unidade de função que representa um grupo defuncionalidade comum.
126. Sistema de controle de acordo com reivindicação 125,caracterizado pelo fato de que pelo menos um dos efeitos de unidadesfuncionais controla de pelo menos uma das entradas e saídas elétricas debaixo nível de pelo menos uma da pluralidade de dispositivos.
127. Sistema de controle de acordo com reivindicação 124,caracterizado pelo fato de que o segundo elemento de sistema inclui que umamáquina de software que reside em pelo menos um dos dispositivos e o qualexpõe uma mensagem de rede enviada através da rede para efetuar o segundoestado de controle.
128. Sistema de controle de acordo com reivindicação 127,caracterizado pelo fato de que a máquina de software expõe comandosencapsulados em uma mensagem de rede, com os comandos usados paraefetuar o segundo estado de controle.
129. Sistema de controle de acordo com reivindicação 124,caracterizado pelo fato de que pelo menos um dentre validação e verificaçõesde segurança é desviado para prover o segundo elemento de sistema comcontrole de funcionalidade de baixo nível para pelo menos alguns dosdispositivos.
130. Sistema de controle de acordo com reivindicação 124,caracterizado pelo fato de que a máquina pode ser removida do segundoestado de controle pelo segundo elemento de sistema respondendo a umamensagem de rede.
131. Método para controlar uma operação de sistema,caracterizado pelo fato de que inclui:gerar um conjunto de dados de taxonomia representativo deum grupo de comandos bem formados;gerar um comando bem formado do grupo de comandos bemformados que usam o conjunto de dados de taxonomia; econtrolar uma operação do sistema em resposta ao comandobem formado gerado.
132. Método de acordo com a reivindicação 131 caracterizadopelo fato de que pelo menos um dentre gerar um conjunto de dados detaxonomia e gerar um comando bem formado é realizado por pelo menos umnó em uma rede associada com o sistema.
133. Método de acordo com a reivindicação 132 caracterizadopelo fato de que o pelo menos um nó é um dentre uma pluralidade de nósinterconectados para formar uma rede interna para uma máquina.
134. Método de acordo com a reivindicação 131 caracterizadopelo fato de que controlar a operação do sistema inclui controlar o sistema deum controlador selecionado de: um controlador em um nó, um controladorexterno à rede interna mas dentro de uma rede do sistema, e um controladorexterno.
135. Método de acordo com a reivindicação 134 caracterizadopelo fato de que ainda inclui a etapa de transmitir o comando bem formado aocontrolador.
136. Método de acordo com a reivindicação 131 caracterizadopelo fato de que o conjunto de dados de taxonomia dita comandosselecionados de comandos que são permissíveis para controlar o sistema ecomandos que são requeridos por controlar o sistema.
137. Método de acordo com a reivindicação 131 caracterizadopelo fato de que o conjunto de dados de taxonomia está definido por umapluralidade de níveis taxonômicos em que pelo menos um nível taxonômicoespecifica pelo menos uma decisão requerida.
138. Método de acordo com a reivindicação 137 caracterizadopelo fato de que a decisão é selecionada de pelo menos um dentre umaseleção ou rejeição de uma opção, entrando um ajuste de valor, e seleção deuma opção de múltiplas opções possíveis.
139. Método de acordo com a reivindicação 138 caracterizadopelo fato de que a opção é selecionada de um grupo de opções disponíveispara um ciclo de operação para o sistema.
140. Método de acordo com a reivindicação 131 caracterizadopelo fato de que a geração do conjunto de dados de taxonomia é realizado porum controlador que controla pelo menos uma porção da operação do sistema.
141. Método de acordo com a reivindicação 140 caracterizadopelo fato de que o controlador gera o conjunto de dados de taxonomiabaseado em pelo menos um dos seguintes fatores: o tipo da operação atual, oestado da operação atual, e quaisquer restrições operacionais da operaçãoatual.
142. Método de acordo com a reivindicação 140 caracterizadopelo fato de que o controlador gera o conjunto de dados de taxonomia comouma função de pelo menos um dentre: restrições de recurso atualmenteaplicáveis, restrição de segurança atualmente aplicável, preferências deusuário, e restrição de tempo.
143. Método de acordo com a reivindicação 131 caracterizadopelo fato de que ainda inclui transmitir o conjunto de dados de taxonomia apelo menos um gerador de comando.
144. Método de acordo com a reivindicação 143 caracterizadopelo fato de que ainda inclui transmitir o conjunto de dados de taxonomia amúltiplos geradores de comando.
145. Método de acordo com a reivindicação 144 caracterizadopelo fato de que a etapa de controlar a operação do sistema inclui controlar osistema de pelo menos um dos múltiplos geradores de comando.
146. Método de acordo com a reivindicação 145 caracterizadopelo fato de que o sistema inclui uma rede interna e ainda em que pelo menosum primeiro gerador de comando está dentro da rede interna e um segundogerador de comando está fora da rede interna.
147. Método de acordo com a reivindicação 143 caracterizadopelo fato de que o pelo menos um gerador de comando é selecionado dentre:uma interface do usuário em um painel de controle, uma interface do usuárioexterna, uma interface do usuário, um sistema de administração de recurso,um sistema de automação doméstico, outros recursos de compartilhamento desistemas, e outros sistemas executando uma operação relacionada.
148. Método de acordo com a reivindicação 143 caracterizadopelo fato de que o gerador de comando envia comandos para operar pelomenos dois sistemas.
149. Método de acordo com a reivindicação 143 caracterizadopelo fato de que o conjunto de dados de taxonomia é enviado como umapluralidade de mensagens para comandar gerador.
150. Método de acordo com a reivindicação 131 caracterizadopelo fato de que ainda inclui a etapa de transmitir o conjunto de dados detaxonomia a um dispositivo de interface do usuário que provê realimentaçãode usuário guiando o usuário para gerar comandos bem formados.
151. Método de acordo com a reivindicação 150 caracterizadopelo fato de que a realimentação de usuário inclui informar um usuário queuma opção não está disponível.
152. Método de acordo com a reivindicação 131 caracterizadopelo fato de que a etapa de gerar um conjunto de dados de taxonomia estárepetida.
153. Método de acordo com a reivindicação 131 caracterizadopelo fato de que ainda inclui a etapa de gerar periodicamente uma mensagemde revisão de taxonomia.
154. Método de acordo com a reivindicação 131 caracterizadopelo fato de que ainda inclui a etapa de verificar um comando bem formado.
155. Método de acordo com a reivindicação 154 caracterizadopelo fato de que a etapa de verificar um comando bem formado é selecionadodentre verificar recibo do comando, verificar que o comando é bem formado,e verificar execução do comando.
156. Método de acordo com a reivindicação 131 caracterizadopelo fato de que a geração do conjunto de dados de taxonomia incluimontagem de uma pluralidade de componentes de comando permissível paraos comandos bem formados.
157. Método de acordo com a reivindicação 156 caracterizadopelo fato de que a geração do comando bem formado inclui montagem doscomponentes de comando em um comando bem formado.
158. Conjunto de dados de taxonomia para permitir umgerador de comando programável para gerar comandos bem formados porcontrolar uma operação, caracterizado pelo fato de que inclui:uma pluralidade de componentes de comando permissíveisdentro de comandos bem formados, euma taxonomia de componentes de comando que esboçamuma estrutura de taxonomia para selecionar componentes de comando paragerar comandos bem formados, a taxonomia especificando para pelo menosum componente de comando, quaisquer componentes de comando adicionaisprecisados para formar o comando bem formado durante a seleção do pelomenos um componente de comando.
159. Conjunto de dados de taxonomia de acordo com areivindicação 158 caracterizado pelo fato de que a estrutura de taxonomiainclui uma pluralidade de níveis taxonômicos em que pelo menos um níveltaxonômico especifica pelo menos uma decisão requerida.
160. Conjunto de dados de taxonomia de acordo com areivindicação 159 caracterizado pelo fato de que a decisão requerida éselecionada dentre: selecionar ou rejeitar uma opção, entrar em um ajuste devalor, e selecionar uma opção dentre múltiplas opções possíveis.
161. Conjunto de dados de taxonomia de acordo com areivindicação 158 caracterizado pelo fato de que o conjunto de dados detaxonomia dita comandos selecionados de comandos que são permissível paracontrolar o sistema e comandos que são requeridos por controlar o sistema.
162. Conjunto de dados de taxonomia de acordo com areivindicação 158 caracterizado pelo fato de que pelo menos um componentede comando reflete informação de estado.
163. Conjunto de dados de taxonomia de acordo com areivindicação 162 caracterizado pelo fato de que a informação de estado éselecionada dentre: informação de estado de sensor, informação de estado deciclo, informação de estado de ambiente, informação de recurso, informaçãode preferência de usuário, informações operacionais históricas, informação derede, informação de modo operacional de controle, e informação de estadooperacional.
164. Sistema de controle para controlar a operação de umsistema útil, caracterizado pelo fato de que inclui:pelo menos um controlador configurado para controlar umaoperação do sistema útil em resposta a um comando bem formado de umgrupo de comandos bem formados;pelo menos uma máquina de taxonomia adaptou para gerar umconjunto de dados de taxonomia que estabelece o grupo de comandos bemformados;pelo menos um gerador de comando adaptou para gerar umcomando bem formado que usa o conjunto de dados de taxonomia; eem que a máquina de taxonomia é configurada para distribuiro conjunto de dados de taxonomia ao gerador de comando, e o gerador decomando é configurado para distribuir o comando bem formado aocontrolador.
165. Sistema de controle de acordo com a reivindicação 164caracterizado pelo fato de que inclui uma pluralidade de controladores, com opelo menos uma máquina de taxonomia configurou para gerar um conjunto dedados de taxonomia que corresponde a cada controlador.
166. Sistema de controle de acordo com a reivindicação 165caracterizado pelo fato de que inclui uma pluralidade de geradores decomando em que cada um dos geradores de comando pode gerar um comandobem formado para qualquer da pluralidade de controladores.
167. Sistema de controle de acordo com a reivindicação 164caracterizado pelo fato de que inclui uma pluralidade de geradores decomando cada um configurado para gerar um comando bem estruturado parao controlador.
168. Sistema de controle de acordo com a reivindicação 164caracterizado pelo fato de que o sistema útil em um aparelho e a operaçãosendo controlada é uma operação do aparelho, em que o aparelho tem umarede interna com uma pluralidade de nós e o controlador é selecionado de umcontrolador em um dos nós, um controlador externo à rede interna, econtrolador externo.
169. Sistema de controle de acordo com a reivindicação 164caracterizado pelo fato de que o conjunto de dados de taxonomia ditacomandos selecionados de comandos que são permissível para controlar osistema e comandos que são requeridos por controlar o sistema.
170. Sistema de controle de acordo com a reivindicação 164caracterizado pelo fato de que o conjunto de dados de taxonomia está definidopor uma pluralidade de níveis taxonômicos em que pelo menos um níveltaxonômico especifica pelo menos uma decisão requerida, em que a decisão éselecionada dentre: uma seleção ou rejeição de uma opção, entrando em umajuste de valor, e selecionando de uma opção dentre múltiplas opçõespossíveis.
171. Sistema de controle de acordo com a reivindicação 164caracterizado pelo fato de que o conjunto de dados de taxonomia é gerado porum controlador como uma função de pelo menos um do tipo da operaçãoatual, o estado da operação atual, e quaisquer restrições operacionais daoperação atual.
172. Sistema de controle de acordo com a reivindicação 164caracterizado pelo fato de que o conjunto de dados de taxonomia é gerado porum controlador como uma função de pelo menos um dentre: restrições derecurso atualmente aplicáveis, restrição de segurança atualmente aplicável,preferências de usuário, e restrição de tempo.
173. Sistema de controle de acordo com a reivindicação 164caracterizado pelo fato de que o gerador de comando é selecionado dentre:uma interface do usuário em um painel de controle, uma interface do usuárioexterna, uma interface do usuário, um sistema de administração de recurso,um sistema de automação de casa, outros recursos de repartição de sistemas, eoutros executando de sistemas uma operação relacionada.
174. Sistema de controle de acordo com a reivindicação 164caracterizado pelo fato de que o gerador de comando é um dispositivo deinterface do usuário programável que provê realimentação de usuário que guiao usuário para gerar comandos bem formados.
175. Sistema de controle de rede caracterizado pelo fato de queinclui:uma camada operacional de software responsiva a umapluralidade de chamadas de função,uma interface do usuário física capaz de diretamente gerar pelomenos algumas das chamadas de função, euma interface do usuário virtual configurada para invocar pelomenos algumas das chamadas de função.
176. Sistema de controle de rede de acordo com areivindicação 175 caracterizado pelo fato de que a interface do usuário virtualé configurada para invocar pelo menos algumas chamadas de função que ainterface do usuário física não pode gerar diretamente.
177. Sistema de controle de rede de acordo com areivindicação 175 caracterizado pelo fato de que ainda inclui uma rede de nósinterconectados, cada um dos nós controlados pela camada operacional desoftware em resposta às chamadas de função para implementar uma operação,em que a interface do usuário virtual é configurada para invocar chamadas defunção para controlar diretamente os nós independentemente da camadaoperacional de software.
178. Sistema de controle de rede de acordo com areivindicação 177 caracterizado pelo fato de que ainda inclui uma máquina desoftware que reside em pelo menos um dos nós para implementar a interfacedo usuário virtual através da rede.
179. Sistema de controle de rede de acordo com areivindicação 178 caracterizado pelo fato de que a máquina de software resideem pelo menos esses nós que podem ser controlados diretamente pelainterface do usuário virtual.
180. Sistema de controle de rede de acordo com areivindicação 179 caracterizado pelo fato de que ainda inclui um nó externopara a rede e configurado para comunicar com a rede de nós interconectados,com a máquina de software que reside no nó externo para a rede.
181. Sistema de controle de rede de acordo com areivindicação 177 caracterizado pelo fato de que a interface do usuário virtualé externa à rede e em comunicação com rede efetuar controle dos nós atravésda rede de um local remoto da rede.
182. Sistema de controle de rede de acordo com areivindicação 177 caracterizado pelo fato de que a interface do usuário virtualé interna à rede.
183. Sistema de controle de rede de acordo com areivindicação 182 caracterizado pelo fato de que a rede define uma rede decomunicação interna para um aparelho.
184. Sistema de controle de rede de acordo com areivindicação 183 caracterizado pelo fato de que a interface do usuário virtualfica situada a um nó diferente que a interface do usuário física.
185. Sistema de controle de rede de acordo com areivindicação 177 caracterizado pelo fato de que cada nó na rede tem uma oumais unidades funcionais cada uma representando um grupo defuncionalidade comum.
186. Sistema de controle de rede de acordo com areivindicação 175 caracterizado pelo fato de que a interface do usuário virtualsurge de uma camada operacional software alternativa.
187. Sistema de controle de rede de acordo com areivindicação 175 caracterizado pelo fato de que o gerador de comandoalternativo é responsivo à descoberta de um evento.
188. Sistema de controle de rede de acordo com areivindicação 187 caracterizado pelo fato de que o evento é selecionado deuma falta, um evento estatal, uma saída de sensor, um evento ativado pelonível operacional de software, e uma mensagem de rede.
189. Sistema de controle de rede de acordo com areivindicação 175 caracterizado pelo fato de que inclui uma rede que tem umapluralidade de dispositivos e pelo menos uma chamada de função é associadacom uma atividade associada com pelo menos um dispositivo.
190. Sistema de controle de rede de acordo com areivindicação 175 caracterizado pelo fato de que chamadas de funçãooriginando da interface do usuário física e chamadas de função originando dainterface do usuário virtual são executadas baseadas em uma prioridadeprescrita.
191. Sistema de controle de rede de acordo com areivindicação 190 caracterizado pelo fato de que a prioridade prescrita éselecionada dentre:pelo menos uma chamada de função que pode desativar pelomenos temporariamente chamadas de função de outra fonte;chamada de função originando da interface do usuário física echamadas de função originando da interface do usuário virtual são executadasem batelada;chamadas de função podem se agrupar tal que um grupologicamente associado de chamadas é completado antes de outra chamada defunção ou grupo logicamente associado de chamadas de função seremexecutados; echamadas de função originando da interface do usuário física echamadas de função originando externamente são executadasconsecutivamente.
192. Sistema de controle de rede de acordo com areivindicação 175 caracterizado pelo fato de que a interface do usuário físicainclui que um dispositivo de rede e processamento de dados auto-suficiente.
193. Sistema de controle de rede de acordo com areivindicação 192 caracterizado pelo fato de que a interface do usuário física éselecionada de um grupo que consiste em um telefone, um computador, umamesa gráfica de rede, um PDA, um microfone, e um teclado virtual.
194. Sistema de controle de rede caracterizado pelo fato de queinclui:uma camada operacional de software responsiva a umapluralidade de chamadas de função,uma interface do usuário física que tem uma pluralidade deações de UI, cada uma das ações de UI que diretamente geram uma daschamadas de função, e pelo menos um dado de geração de ação de UI, euma interface do usuário virtual adaptada para invocar pelomenos algumas das chamadas de função geradas por ações de UI assim comopara invocar pelo menos uma chamada de função que não pode ser gerada poruma ação de UI.
195. Sistema de controle de rede de acordo com areivindicação 194 caracterizado pelo fato de que cada ação de UI tem umachamada de função associada.
196. Sistema de controle de rede de acordo com areivindicação 194 caracterizado pelo fato de que cada chamada de função éassociada com um ou mais ação de UI.
197. Sistema de controle de rede de acordo com areivindicação 194 caracterizado pelo fato de que pelo menos uma ação de UIé associada com uma chamada de função.
198. Sistema de controle de rede de acordo com areivindicação 194 caracterizado pelo fato de que pelo menos uma ação de UIé associada com entrada de dados.
199. Sistema de controle de rede de acordo com areivindicação 194 caracterizado pelo fato de que a interface do usuário físicainclui um teclado numérico que inclui uma pluralidade de teclas.
200. Sistema de controle de rede de acordo com areivindicação 199 caracterizado pelo fato de que cada tecla é associada comuma chamada de função associada.
201. Sistema de controle de rede de acordo com areivindicação 199 caracterizado pelo fato de que pelo menos uma tecla éassociada com pelo menos uma chamada de função associada.
202. Sistema de controle de rede de acordo com areivindicação 199 caracterizado pelo fato de que pelo menos uma tecla éassociada com entrada de dados.
203. Sistema de controle de rede de acordo com areivindicação 194 caracterizado pelo fato de que a interface do usuário virtualé configurada para transmitir uma compressão de tecla virtual que inclui pelomenos uma chamada de função por meio de que a pelo menos umacompressão de tecla virtual instrui um nó de rede receptor para executar umafuncionalidade associada.
204. Sistema de controle de rede de acordo com areivindicação 203 caracterizado pelo fato de que a compressão de tecla virtualhabilita um pelo menos dentre:testar software associado;executar remotamente software;usar de novo software·, e,reprogramar chamadas de função de compressão de tecla.
205. Sistema de controle de rede de acordo com areivindicação 204 caracterizado pelo fato de que pelo menos uma compressãode tecla virtual invoca uma pluralidade de chamadas de função.
206. Sistema de controle de rede de acordo com areivindicação 205 caracterizado pelo fato de que pelo menos uma seqüênciade compressões de teclas virtuais invoca pelo menos uma chamada de função.
207. Sistema de controle de rede de acordo com areivindicação 194 caracterizado pelo fato de que o software tem pelo menosum primeiro e um segundo nível operacional e em que há pelo menos umachamada de função não disponível no primeiro nível operacional que estádisponível no segundo nível operacional.
208. Sistema de controle de rede de acordo com areivindicação 194 caracterizado pelo fato de que a rede inclui um aparelhoque tem uma pluralidade de nós e ainda em que compressões de teclas virtuaisdo teclado numérico são encapsuladas por mensagens de rede enviadas a umnó de rede que apóia a chamada funcional.
209. Sistema de controle de rede de acordo com areivindicação 194 caracterizado pelo fato de que ainda inclui uma rede de nósinterconectados, cada um dos nós controlados pela camada operacional desoftware em resposta às chamadas de função para implementar uma operação,em que a interface do usuário virtual é configurada para invocar chamadas defunção não capazes de serem gerados por uma ação de UI para controlardiretamente os nós independentemente da camada operacional de software.
210. Sistema de controle de rede de acordo com areivindicação 209 caracterizado pelo fato de que ainda inclui uma máquina desoftware que reside em pelo menos um dos nós para implementar a interfacedo usuário virtual através da rede.
211. Sistema de controle de rede de acordo com areivindicação 210 caracterizado pelo fato de que a máquina de software resideem pelo menos esses nós que podem ser controlados diretamente pelainterface do usuário virtual.
BRPI0611726-0A 2005-06-09 2006-06-08 aparelho para realizar um ciclo de operação útil em um artigo fìsico BRPI0611726A2 (pt)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US59514805P 2005-06-09 2005-06-09
US60/595148 2005-06-09
PCT/US2006/022420 WO2006135726A2 (en) 2005-06-09 2006-06-08 Software architecture system and method for communication with, and management of, at least one component within a household appliance

Publications (1)

Publication Number Publication Date
BRPI0611726A2 true BRPI0611726A2 (pt) 2010-11-09

Family

ID=37188949

Family Applications (5)

Application Number Title Priority Date Filing Date
BRPI0622274-9A BRPI0622274A2 (pt) 2005-06-09 2006-06-08 aparelho configurado para executar um ciclo de operação para completar uma operação fìsica em um artigo e rede de aparelho
BRPI0611726-0A BRPI0611726A2 (pt) 2005-06-09 2006-06-08 aparelho para realizar um ciclo de operação útil em um artigo fìsico
BRPI0622273-0A BRPI0622273A2 (pt) 2005-06-09 2006-06-08 sistema de rede compreendendo um processador e pelo menos dois nós
BRPI0621758-3A BRPI0621758A2 (pt) 2005-06-09 2006-06-09 sistema detalhado para gerenciamento do produto
BRPI0611640-0A BRPI0611640A2 (pt) 2005-06-09 2006-06-09 rede de utensÍlios, e, acessàrio para uso junto com um primeiro utensÍlio conectado em rede

Family Applications Before (1)

Application Number Title Priority Date Filing Date
BRPI0622274-9A BRPI0622274A2 (pt) 2005-06-09 2006-06-08 aparelho configurado para executar um ciclo de operação para completar uma operação fìsica em um artigo e rede de aparelho

Family Applications After (3)

Application Number Title Priority Date Filing Date
BRPI0622273-0A BRPI0622273A2 (pt) 2005-06-09 2006-06-08 sistema de rede compreendendo um processador e pelo menos dois nós
BRPI0621758-3A BRPI0621758A2 (pt) 2005-06-09 2006-06-09 sistema detalhado para gerenciamento do produto
BRPI0611640-0A BRPI0611640A2 (pt) 2005-06-09 2006-06-09 rede de utensÍlios, e, acessàrio para uso junto com um primeiro utensÍlio conectado em rede

Country Status (7)

Country Link
US (18) US20100287059A1 (pt)
EP (6) EP2228969B1 (pt)
CN (2) CN101305350A (pt)
BR (5) BRPI0622274A2 (pt)
CA (3) CA2611527A1 (pt)
MX (2) MX2007015681A (pt)
WO (3) WO2006135726A2 (pt)

Families Citing this family (548)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7440842B1 (en) * 2003-05-09 2008-10-21 Dimitri Vorona System for transmitting, processing, receiving, and displaying traffic information
US8825356B2 (en) 2003-05-09 2014-09-02 Dimitri Vorona System for transmitting, processing, receiving, and displaying traffic information
US7623042B2 (en) * 2005-03-14 2009-11-24 Regents Of The University Of California Wireless network control for building lighting system
US9122788B2 (en) 2005-06-09 2015-09-01 Whirlpool Corporation Appliance network for a networked appliance with a network binder accessory
US10333731B2 (en) 2005-06-09 2019-06-25 Whirlpool Corporation Methods and apparatus for communicatively coupling internal components within appliances, and appliances with external components and accessories
US7831321B2 (en) 2005-06-09 2010-11-09 Whirlpool Corporation Appliance and accessory for controlling a cycle of operation
US9103061B2 (en) 2006-06-08 2015-08-11 Whirlpool Corporation Product service system and method
US7813831B2 (en) 2005-06-09 2010-10-12 Whirlpool Corporation Software architecture system and method for operating an appliance in multiple operating modes
US9401822B2 (en) 2005-06-09 2016-07-26 Whirlpool Corporation Software architecture system and method for operating an appliance exposing key press functionality to a network
US8005780B2 (en) 2005-06-09 2011-08-23 Whirlpool Corporation Taxonomy engine and dataset for operating an appliance
US8615332B2 (en) 2005-06-09 2013-12-24 Whirlpool Corporation Smart current attenuator for energy conservation in appliances
US7921429B2 (en) 2005-06-09 2011-04-05 Whirlpool Corporation Data acquisition method with event notification for an appliance
US8816828B2 (en) * 2005-06-09 2014-08-26 Whirlpool Corporation Recipe wand and recipe book for use with a networked appliance
BRPI0622274A2 (pt) 2005-06-09 2011-08-09 Whirlpool Co aparelho configurado para executar um ciclo de operação para completar uma operação fìsica em um artigo e rede de aparelho
US7917914B2 (en) 2005-06-09 2011-03-29 Whirlpool Corporation Event notification system for an appliance
US20070288331A1 (en) 2006-06-08 2007-12-13 Whirlpool Corporation Product demonstration system and method
US8250163B2 (en) 2005-06-09 2012-08-21 Whirlpool Corporation Smart coupling device
US8676656B2 (en) * 2005-06-09 2014-03-18 Whirlpool Corporation Method for product demonstration
US8442042B2 (en) 2005-06-09 2013-05-14 Whirlpool Corporation Appliance and a consumable holder with an embedded virtual router
US20080137670A1 (en) * 2005-06-09 2008-06-12 Whirlpool Corporation Network System with Message Binding for Appliances
US8571942B2 (en) 2005-06-09 2013-10-29 Whirlpool Corporation Method of product demonstration
US8155120B2 (en) 2005-06-09 2012-04-10 Whirlpool Corporation Software architecture system and method for discovering components within an appliance using fuctionality identifiers
US8533253B2 (en) * 2005-06-09 2013-09-10 Whirlpool Corporation Distributed object-oriented appliance control system
US8856036B2 (en) 2005-06-09 2014-10-07 Whirlpool Corporation Method of providing product demonstrations
US9009811B2 (en) 2005-06-09 2015-04-14 Whirlpool Corporation Network system with electronic credentials and authentication for appliances
US8027752B2 (en) 2005-06-09 2011-09-27 Whirlpool Corporation Network for changing resource consumption in an appliance
US9164867B2 (en) 2005-06-09 2015-10-20 Whirlpool Corporation Network for communicating information related to a consumable to an appliance
JP2008547335A (ja) * 2005-07-04 2008-12-25 ヴィーケーアール ホールディング エー／エス コマンド実行処理システムおよび装置
US9418040B2 (en) 2005-07-07 2016-08-16 Sciencelogic, Inc. Dynamically deployable self configuring distributed network management system
US9866697B2 (en) * 2005-08-19 2018-01-09 Nexstep, Inc. Consumer electronic registration, control and support concierge device and method
US8442660B2 (en) 2005-10-28 2013-05-14 Electro Industries/Gauge Tech Intelligent electronic device having audible and visual interface
US7870512B2 (en) * 2005-12-28 2011-01-11 Sap Ag User interface (UI) prototype using UI taxonomy
WO2007098468A1 (en) * 2006-02-21 2007-08-30 University Of Florida Research Foundation Inc. Modular platform enabling heterogeneous devices, sensors and actuators to integrate automatically into heterogeneous networks
KR101176229B1 (ko) * 2006-05-26 2012-08-22 엘지전자 주식회사 세탁실을 관리하는 방법 및 시스템
US7660572B2 (en) * 2006-05-30 2010-02-09 Dell Products L.P. Community networking using networked audio devices
US8682733B2 (en) 2006-06-08 2014-03-25 Whirlpool Corporation System for product demonstration
US9338028B2 (en) * 2006-06-19 2016-05-10 Nokia Technologies Oy Utilizing information of a local network for determining presence state
US20080124065A1 (en) * 2006-11-29 2008-05-29 Ahamefula Chukwu Automatic picture and text alerting camera, with inbuilt smoke and motion detectors
US8353030B2 (en) * 2006-12-13 2013-01-08 Avaya Inc. Maintaining communication between network nodes that are subjected to a packet attack
US8061153B2 (en) 2006-12-28 2011-11-22 Whirlpool Corporation Refrigeration appliance with optional storage module
US8336321B2 (en) 2006-12-28 2012-12-25 Whirlpool Corporation Hybrid multi-evaporator central cooling system for modular kitchen
US8042355B2 (en) 2006-12-28 2011-10-25 Whirlpool Corporation Temporary refrigerator storage modules
US8245524B2 (en) 2006-12-28 2012-08-21 Whirlpool Corporation Thermal cascade system for distributed household refrigeration system
US8161760B2 (en) 2006-12-28 2012-04-24 Whirlpool Corporation Utilities grid for distributed refrigeration system
US8336322B2 (en) 2006-12-28 2012-12-25 Whirlpool Corporation Distributed refrigeration system with optional storage module and controller
US7686127B2 (en) * 2007-01-04 2010-03-30 Whirlpool Corporation Acoustic chamber as part of adapter or appliance
KR101342374B1 (ko) 2007-01-19 2013-12-16 엘지전자 주식회사 세탁기 및 세탁기 서비스 제공 방법
ITRN20070007A1 (it) * 2007-02-08 2007-05-10 Indesit Company Spa Dispositivo portatile di assistenza tecnica di un elettrodomestico
KR100888478B1 (ko) * 2007-03-08 2009-03-12 삼성전자주식회사 액션 처리 방법, 피제어 장치의 제어 방법, 피제어 장치 및제어 포인트
US7707459B2 (en) 2007-03-08 2010-04-27 Whirlpool Corporation Embedded systems debugging
US9106553B2 (en) * 2007-03-26 2015-08-11 Qualcomm Incorporated System and method for sharing resources and interfaces amongst connected computing devices
WO2008147526A1 (en) * 2007-05-23 2008-12-04 The Trustees Of The University Of Pennsylvania Targeted carriers for intracellular drug delivery
US8464212B2 (en) * 2007-07-27 2013-06-11 Canon Kabushiki Kaisha Method, apparatus and storage medium for customizing application
US10540651B1 (en) * 2007-07-31 2020-01-21 Intuit Inc. Technique for restricting access to information
US8798573B2 (en) * 2007-08-22 2014-08-05 Intel-Ge Care Innovations Llc Monitoring activities of daily living using radio frequency emissions
JP5150166B2 (ja) * 2007-08-24 2013-02-20 株式会社東芝 設備機器集合生成支援装置及び方法
US8094034B2 (en) 2007-09-18 2012-01-10 Georgia Tech Research Corporation Detecting actuation of electrical devices using electrical noise over a power line
US20090083000A1 (en) * 2007-09-26 2009-03-26 Modu Ltd. Automated appliance diagnostics and reporting
ITMO20070335A1 (it) * 2007-11-09 2009-05-10 Angelo Grandi Cucine Societa P Apparato per il trattamento di prodotti alimentari dotato di dispositivo di controllo elettronico
US8566431B2 (en) * 2008-01-16 2013-10-22 Razer (Asia-Pacific) Pte. Ltd. Identification device and method for device identification
DE102008009659B4 (de) * 2008-02-18 2019-06-19 Rational Ag Verfahren zur Steuerung von mindestens zwei Gargeräten, Gargerät und System aus mindestens zwei Gargeräten
US8788888B2 (en) * 2008-03-14 2014-07-22 Telefonaktiebolaget L M Ericsson (Publ) Method and apparatus for providing end user notification in a UPnP network
US8419434B2 (en) * 2008-04-15 2013-04-16 International Business Machines Corporation Interactive recipe preparation using interactive cooking device to communicate with kitchen appliances
US8992225B2 (en) 2008-04-15 2015-03-31 International Business Machines Corporation Monitoring recipe preparation using instructive device and generating an alert to provide feedback
US8342847B2 (en) * 2008-04-15 2013-01-01 International Business Machines Corporation Interactive recipe preparation instruction delivery to disabled indiviuals
US8323026B2 (en) * 2008-04-15 2012-12-04 International Business Machines Corporation Interactive recipe preparation using instructive device with integrated actuators to provide tactile feedback
US8419433B2 (en) * 2008-04-15 2013-04-16 International Business Machines Corporation Monitoring recipe preparation using interactive cooking device
US8532273B2 (en) * 2008-04-29 2013-09-10 Lg Electronics Inc. Home appliance and home appliance system
KR101482136B1 (ko) * 2008-04-29 2015-01-14 엘지전자 주식회사 가전기기 및 가전기기 시스템
KR101627219B1 (ko) * 2008-04-29 2016-06-03 엘지전자 주식회사 가전기기 및 가전기기를 포함하는 가전기기시스템
KR101404104B1 (ko) * 2008-04-30 2014-06-10 엘지전자 주식회사 가전기기 진단시스템 및 그 동작방법
US20100040213A1 (en) * 2008-04-30 2010-02-18 Lg Electronics Inc. Home appliance and home appliance system
KR101598238B1 (ko) * 2008-05-05 2016-02-26 노바 콘트롤스 분배 시스템용 조절기
US20100114340A1 (en) 2008-06-02 2010-05-06 Charles Huizenga Automatic provisioning of wireless control systems
US8364325B2 (en) * 2008-06-02 2013-01-29 Adura Technologies, Inc. Intelligence in distributed lighting control devices
US7839017B2 (en) * 2009-03-02 2010-11-23 Adura Technologies, Inc. Systems and methods for remotely controlling an electrical load
US8275471B2 (en) 2009-11-06 2012-09-25 Adura Technologies, Inc. Sensor interface for wireless control
EP3249893A1 (en) 2008-06-03 2017-11-29 Whirlpool Corporation Appliance development toolkit
JP5340027B2 (ja) * 2008-06-05 2013-11-13 キヤノン株式会社 サーバ装置、サーバ装置の制御方法、プログラム及び記録媒体
US9054953B2 (en) * 2008-06-16 2015-06-09 Lg Electronics Inc. Home appliance and home appliance system
US8453126B1 (en) * 2008-07-30 2013-05-28 Dulles Research LLC System and method for converting base SAS runtime macro language scripts to JAVA target language
US20100066554A1 (en) * 2008-09-02 2010-03-18 Lg Electronics Inc. Home appliance system
US8118997B2 (en) * 2008-10-23 2012-02-21 Whirlpool Corporation Smart filter for an appliance
US20100125364A1 (en) * 2008-11-20 2010-05-20 Whirlpool Corporation Configurable consumable holder for an appliance
US8051381B2 (en) * 2008-12-22 2011-11-01 Whirlpool Corporation Appliance with a graphical user interface for configuring an accessory
EP2180390A3 (en) 2008-10-23 2011-01-05 Whirlpool Corporation Consumable information holder with user interface data
SE533007C2 (sv) 2008-10-24 2010-06-08 Ilt Productions Ab Distribuerad datalagring
US9268345B2 (en) 2008-10-27 2016-02-23 Lennox Industries Inc. System and method of use for a user interface dashboard of a heating, ventilation and air conditioning network
US8977794B2 (en) 2008-10-27 2015-03-10 Lennox Industries, Inc. Communication protocol system and method for a distributed-architecture heating, ventilation and air conditioning network
US9261888B2 (en) * 2008-10-27 2016-02-16 Lennox Industries Inc. System and method of use for a user interface dashboard of a heating, ventilation and air conditioning network
US9152155B2 (en) 2008-10-27 2015-10-06 Lennox Industries Inc. Device abstraction system and method for a distributed-architecture heating, ventilation and air conditioning system
US9678486B2 (en) 2008-10-27 2017-06-13 Lennox Industries Inc. Device abstraction system and method for a distributed-architecture heating, ventilation and air conditioning system
US8874815B2 (en) 2008-10-27 2014-10-28 Lennox Industries, Inc. Communication protocol system and method for a distributed architecture heating, ventilation and air conditioning network
US9432208B2 (en) 2008-10-27 2016-08-30 Lennox Industries Inc. Device abstraction system and method for a distributed architecture heating, ventilation and air conditioning system
US9325517B2 (en) 2008-10-27 2016-04-26 Lennox Industries Inc. Device abstraction system and method for a distributed-architecture heating, ventilation and air conditioning system
US9632490B2 (en) 2008-10-27 2017-04-25 Lennox Industries Inc. System and method for zoning a distributed architecture heating, ventilation and air conditioning network
US9651925B2 (en) 2008-10-27 2017-05-16 Lennox Industries Inc. System and method for zoning a distributed-architecture heating, ventilation and air conditioning network
US9377768B2 (en) 2008-10-27 2016-06-28 Lennox Industries Inc. Memory recovery scheme and data structure in a heating, ventilation and air conditioning network
US8994539B2 (en) * 2008-10-27 2015-03-31 Lennox Industries, Inc. Alarm and diagnostics system and method for a distributed-architecture heating, ventilation and air conditioning network
US8892797B2 (en) 2008-10-27 2014-11-18 Lennox Industries Inc. Communication protocol system and method for a distributed-architecture heating, ventilation and air conditioning network
TWI383752B (zh) * 2008-10-28 2013-02-01 Ind Tech Res Inst 結合語音辨識功能之食品製造裝置
US8138933B2 (en) * 2008-11-05 2012-03-20 Crucs Holdings, Llc Systems, methods, and apparatus for automatically disabling appliances in response to a smoke detector
DE102008056412A1 (de) * 2008-11-07 2010-05-12 BSH Bosch und Siemens Hausgeräte GmbH Haushaltsgerät mit einer Luft-Trocknungsvorrichtung und/oder Flüssigkeits-Heizungseinrichtung sowie zugehöriges Verfahren
CA2644885C (en) 2008-11-25 2017-01-03 Electrolux Home Products, Inc. Enterprise wide system and methods for configuring, diagnosing, and updating appliances
US9665838B2 (en) 2008-12-03 2017-05-30 Whirlpool Corporation Messaging architecture and system for electronic management of resources
EP2204707A3 (en) 2008-12-30 2012-03-28 Whirlpool Corporation Method of diagnosing an appliance fault
US20100217803A1 (en) * 2009-01-29 2010-08-26 Ivy Biomedical Systems, Inc. Interface device for communication between a medical device and a computer
US9489776B2 (en) 2009-02-05 2016-11-08 fybr Gen II meter system
US9218000B2 (en) * 2009-04-01 2015-12-22 Honeywell International Inc. System and method for cloud computing
US20100256781A1 (en) * 2009-04-01 2010-10-07 Chen-Yu Sheu Semantic appliance control system
US8204717B2 (en) * 2009-04-01 2012-06-19 Honeywell International Inc. Cloud computing as a basis for equipment health monitoring service
US20100262919A1 (en) * 2009-04-09 2010-10-14 Peter Spezza Method of remotely providing a computer service
US8565079B2 (en) * 2009-04-10 2013-10-22 Lg Electronics Inc. Home appliance and home appliance system
KR101442115B1 (ko) * 2009-04-10 2014-09-18 엘지전자 주식회사 가전기기 및 가전기기 시스템
KR101579481B1 (ko) * 2009-04-10 2015-12-22 엘지전자 주식회사 가전기기 진단시스템 및 그 진단방법
KR20100112948A (ko) * 2009-04-10 2010-10-20 엘지전자 주식회사 가전기기 진단시스템 및 그 진단방법
KR101597523B1 (ko) * 2009-04-10 2016-02-25 엘지전자 주식회사 가전기기 서비스 장치 및 그 제어방법
KR101421685B1 (ko) * 2009-04-10 2014-08-13 엘지전자 주식회사 가전기기 진단시스템 및 그 진단방법
KR101555586B1 (ko) * 2009-04-10 2015-09-24 엘지전자 주식회사 가전기기
KR101563487B1 (ko) 2009-05-11 2015-10-27 엘지전자 주식회사 가전기기를 제어하는 휴대 단말기
KR101556972B1 (ko) * 2009-05-11 2015-10-02 엘지전자 주식회사 세탁기를 제어하는 휴대 단말기 및 그 동작 방법
JP2012532558A (ja) 2009-07-06 2012-12-13 エルジー エレクトロニクス インコーポレイティド 家電機器診断システム及びその運転方法
US20110005258A1 (en) * 2009-07-09 2011-01-13 Mathieu Audet Method and system for managing appliance equipments
US9000949B2 (en) 2009-07-10 2015-04-07 Streetsmart Technology Llc Gen II meter system with multiple processors, multiple detection sensor types, fault tolerance methods, power sharing and multiple user interface methods
US8626344B2 (en) 2009-08-21 2014-01-07 Allure Energy, Inc. Energy management system and method
KR20110010374A (ko) * 2009-07-24 2011-02-01 엘지전자 주식회사 가전기기 진단시스템 및 그 방법
US8996659B2 (en) * 2009-07-24 2015-03-31 Plumchoice, Inc. Systems and methods for providing remote services using a cross-device database
KR101403000B1 (ko) 2009-07-24 2014-06-17 엘지전자 주식회사 가전기기 및 그 신호출력방법
US8380520B2 (en) * 2009-07-30 2013-02-19 Industrial Technology Research Institute Food processor with recognition ability of emotion-related information and emotional signals
KR101482138B1 (ko) * 2009-07-31 2015-01-13 엘지전자 주식회사 가전기기 진단시스템 및 그 진단방법
KR101472402B1 (ko) * 2009-07-31 2014-12-12 엘지전자 주식회사 가전기기 진단시스템 및 그 진단방법
KR101472401B1 (ko) * 2009-07-31 2014-12-12 엘지전자 주식회사 가전기기 진단시스템 및 그 진단방법
KR101553843B1 (ko) * 2009-07-31 2015-09-30 엘지전자 주식회사 가전기기 진단시스템 및 그 진단방법
KR20110013582A (ko) * 2009-07-31 2011-02-10 엘지전자 주식회사 가전기기 진단시스템 및 그 진단방법
KR101482137B1 (ko) * 2009-07-31 2015-01-13 엘지전자 주식회사 가전기기 진단시스템 및 그 진단방법
KR101607891B1 (ko) * 2009-07-31 2016-04-11 엘지전자 주식회사 가전기기 진단시스템 및 그 진단방법
US8547200B2 (en) * 2009-08-05 2013-10-01 Lg Electronics Inc. Home appliance and method for operating the same
US9838255B2 (en) 2009-08-21 2017-12-05 Samsung Electronics Co., Ltd. Mobile demand response energy management system with proximity control
US8498749B2 (en) 2009-08-21 2013-07-30 Allure Energy, Inc. Method for zone based energy management system with scalable map interface
US9209652B2 (en) 2009-08-21 2015-12-08 Allure Energy, Inc. Mobile device with scalable map interface for zone based energy management
DK2476223T3 (da) 2009-09-08 2021-05-31 Abbott Diabetes Care Inc Fremgangsmåder og fremstillede produkter til hosting af en sikkerhedskritisk applikation på en ukontrolleret databehandlingsindretning
CN102575501B (zh) * 2009-09-10 2015-05-20 Bp北美公司 用于在双梯度环境中将井眼流入物循环出来的系统和方法
US8234363B1 (en) 2009-09-18 2012-07-31 Kuo-Hua Kuo Dynamic object management protocol
US8276159B2 (en) * 2009-09-23 2012-09-25 Microsoft Corporation Message communication of sensor and other data
MX2009010902A (es) * 2009-10-08 2011-04-20 Magno Alcantara Talavera Metodos y sistema de control por voz.
DE102009045594A1 (de) * 2009-10-12 2011-04-14 BSH Bosch und Siemens Hausgeräte GmbH Haushaltsgerät, insbesondere Haushalts-Geschirrspülmaschine
KR20110040387A (ko) * 2009-10-14 2011-04-20 이상원 조리 상태 감시 시스템 및 방법
CN102640458B (zh) 2009-11-26 2015-09-30 Lg电子株式会社 用于组件的网络系统
US7937438B1 (en) 2009-12-07 2011-05-03 Amazon Technologies, Inc. Using virtual networking devices to manage external connections
US9203747B1 (en) 2009-12-07 2015-12-01 Amazon Technologies, Inc. Providing virtual networking device functionality for managed computer networks
US9036504B1 (en) 2009-12-07 2015-05-19 Amazon Technologies, Inc. Using virtual networking devices and routing information to associate network addresses with computing nodes
US8995301B1 (en) 2009-12-07 2015-03-31 Amazon Technologies, Inc. Using virtual networking devices to manage routing cost information
US10198935B2 (en) 2009-12-08 2019-02-05 Universal Electronics Inc. System and method for simplified activity based setup of a controlling device
US8526935B2 (en) * 2009-12-15 2013-09-03 General Electric Company Appliance demand response antenna design for improved gain within the home appliance network
US8914133B2 (en) * 2009-12-17 2014-12-16 Lg Electronics Inc. Power management system and method of controlling network system
EP2514142B1 (en) * 2009-12-17 2015-10-14 LG Electronics Inc. Network system and method of controlling network system
US9058037B2 (en) * 2009-12-22 2015-06-16 General Electric Company Return of appliance state after demand response event
US8224971B1 (en) 2009-12-28 2012-07-17 Amazon Technologies, Inc. Using virtual networking devices and routing information to initiate external actions
US7991859B1 (en) * 2009-12-28 2011-08-02 Amazon Technologies, Inc. Using virtual networking devices to connect managed computer networks
US9171293B2 (en) * 2009-12-29 2015-10-27 Telenav, Inc. Location based system with location-enabled messaging and method of operation thereof
KR101748605B1 (ko) 2010-01-15 2017-06-20 엘지전자 주식회사 냉장고 및 냉장고 진단시스템
JP2011152022A (ja) * 2010-01-25 2011-08-04 Sony Corp 電力管理装置、電力管理システム、及び機器制御方法
JP5487994B2 (ja) * 2010-01-25 2014-05-14 ソニー株式会社 電力管理装置、及び表示方法
US20110202194A1 (en) 2010-02-15 2011-08-18 General Electric Company Sub-metering hardware for measuring energy data of an energy consuming device
US8315743B2 (en) * 2010-02-19 2012-11-20 The Boeing Company Network centric power flow control
US8655499B2 (en) * 2010-02-19 2014-02-18 The Boeing Company Controlling virtual power circuits
US9361637B2 (en) * 2010-03-05 2016-06-07 Sears Brands, L.L.C. System and method for providing diagnostic services
US20110224810A1 (en) * 2010-03-12 2011-09-15 Spansion Llc Home and building automation
US20110225327A1 (en) * 2010-03-12 2011-09-15 Spansion Llc Systems and methods for controlling an electronic device
CA2868581C (en) * 2010-03-19 2016-03-29 mr.QR10 GMBH & CO. KG Concept for communicating between different entities using different data portions for different channels
US20110245627A1 (en) * 2010-03-30 2011-10-06 Hong Kong Applied Science And Technology Research Institute Co., Ltd. Electronic health record storage device, system, and method
WO2011131753A1 (en) * 2010-04-21 2011-10-27 Institut Polytechnique De Grenoble System and method for managing services in a living place
US8626921B2 (en) * 2010-04-22 2014-01-07 Cisco Technology, Inc. Device and service management based on layer 2 through layer 7 device attributes
EP2712149B1 (en) 2010-04-23 2019-10-30 Compuverde AB Distributed data storage
KR101510934B1 (ko) * 2010-05-06 2015-04-10 베에스하 보쉬 운트 지멘스 하우스게랫테 게엠베하 가전기기용 장치
EP2386953B1 (en) * 2010-05-14 2018-02-07 Sap Se Systems and methods for generating reusable test components out of remote application programming interface
WO2011162552A2 (ko) * 2010-06-22 2011-12-29 엘지전자 주식회사 네트워크 시스템
US9709981B2 (en) * 2010-06-29 2017-07-18 Orange Managing application failures in a system of domestic appliances
CN103053135A (zh) 2010-07-06 2013-04-17 Lg电子株式会社 诊断家用电器的设备
KR20120006287A (ko) * 2010-07-12 2012-01-18 엘지전자 주식회사 냉장고 및 냉장고 제어방법
US8897899B2 (en) 2010-07-15 2014-11-25 Rain Bird Corporation Method and apparatus for programming a decoder-based irrigation controller
US8599008B2 (en) * 2010-07-26 2013-12-03 General Electric Company Appliance monitoring system and method
ITTO20100647A1 (it) * 2010-07-27 2012-01-28 Global Care S A S Di Maura Milani Metodo, dispositivo e sistema per l'assistenza tecnica post-vendita di utenze elettriche
DE102010039834A1 (de) * 2010-08-26 2012-03-01 BSH Bosch und Siemens Hausgeräte GmbH Haushaltsgerät
GB2484458A (en) * 2010-10-04 2012-04-18 Thorn Security Commissioning detector units of an alarm system by means of a remote infrared based communication tool
US9122744B2 (en) 2010-10-11 2015-09-01 Next It Corporation System and method for providing distributed intelligent assistance
DE102010043659B4 (de) * 2010-11-09 2012-06-21 BSH Bosch und Siemens Hausgeräte GmbH Verfahren zum Betreiben eines Bussystems, Bussystem und Haushaltsgerät mit einem Bussystem
US20120127012A1 (en) * 2010-11-24 2012-05-24 Samsung Electronics Co., Ltd. Determining user intent from position and orientation information
KR101662705B1 (ko) * 2010-12-22 2016-10-05 한국전자통신연구원 그린 홈 전력 관리 시스템에서 소비 전력량 데이터 관리 및 검증 장치 및 그 방법
KR101275582B1 (ko) * 2010-12-31 2013-06-17 엘지전자 주식회사 휴대 단말기의 동작방법
US9612286B2 (en) 2011-02-04 2017-04-04 Bidgely Inc. Systems and methods for improving the accuracy of appliance level disaggregation in non-intrusive appliance load monitoring techniques
US8278779B2 (en) 2011-02-07 2012-10-02 General Electric Company System and method for providing redundant power to a device
US20120239762A1 (en) * 2011-03-14 2012-09-20 Electrolux Home Products, Inc. Remote Communication Systems and Methods for Appliances
US9438678B2 (en) * 2011-03-17 2016-09-06 Sears Brands, L.L.C. Methods and systems for appliance community service management
US9105009B2 (en) 2011-03-21 2015-08-11 Microsoft Technology Licensing, Llc Email-based automated recovery action in a hosted environment
US10504360B2 (en) 2011-04-08 2019-12-10 Ross Gilson Remote control interference avoidance
DE102011017631A1 (de) * 2011-04-27 2012-10-31 BSH Bosch und Siemens Hausgeräte GmbH Hausgerät mit nachträglich abänderbarem, technischem Programm sowie zugehöriges Verfahren und Computerprogrammprodukt
KR101797946B1 (ko) * 2011-05-25 2017-12-12 삼성전자주식회사 가전기기의 자가 진단 시스템 및 그 동작 방법
US8769110B2 (en) * 2011-05-27 2014-07-01 Sony Corporation Transferring RUI from one device to another
US20120316809A1 (en) * 2011-06-08 2012-12-13 Elster Solutions, Llc Virtual option board for use in performing metering operations
US9171314B2 (en) * 2011-06-16 2015-10-27 Microsoft Technology Licensing, Llc Cloud based management of an in-store device experience
US8942835B2 (en) 2011-06-16 2015-01-27 Bsh Home Appliances Corporation System and method of operating household appliances
WO2012174595A1 (en) * 2011-06-21 2012-12-27 Icookit Pty Ltd System for automating cooking steps
JP5158236B2 (ja) * 2011-06-30 2013-03-06 ダイキン工業株式会社 設備機器の制御装置
KR101276861B1 (ko) * 2011-07-27 2013-06-18 엘지전자 주식회사 가전제품 및 이를 포함하여 이루어지는 온라인 시스템
KR101416937B1 (ko) 2011-08-02 2014-08-06 엘지전자 주식회사 가전기기, 가전기기 진단시스템 및 동작방법
ITRN20110053A1 (it) 2011-08-05 2013-02-06 Indesit Co Spa Elettrodomestico e metodo di impostazione in un elettrodomestico di un programma di funzionamento
KR101282386B1 (ko) * 2011-08-18 2013-07-04 정성민 조리 상태 감시 시스템 및 방법
US9954720B2 (en) * 2011-08-18 2018-04-24 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for determining an event instance
KR101252167B1 (ko) 2011-08-18 2013-04-05 엘지전자 주식회사 가전기기 진단장치 및 그 진단방법
US20130214935A1 (en) * 2011-08-22 2013-08-22 Lg Electronics Inc. Information management system for home appliance
WO2013033469A1 (en) 2011-08-30 2013-03-07 Allure Energy, Inc. Resource manager, system, and method for communicating resource management information for smart energy and media resources
US8769138B2 (en) 2011-09-02 2014-07-01 Compuverde Ab Method for data retrieval from a distributed data storage system
US8645978B2 (en) * 2011-09-02 2014-02-04 Compuverde Ab Method for data maintenance
US9626378B2 (en) 2011-09-02 2017-04-18 Compuverde Ab Method for handling requests in a storage system and a storage node for a storage system
US8997124B2 (en) 2011-09-02 2015-03-31 Compuverde Ab Method for updating data in a distributed data storage system
US8650365B2 (en) 2011-09-02 2014-02-11 Compuverde Ab Method and device for maintaining data in a data storage system comprising a plurality of data storage nodes
US9021053B2 (en) 2011-09-02 2015-04-28 Compuverde Ab Method and device for writing data to a data storage system comprising a plurality of data storage nodes
KR20140105712A (ko) * 2011-10-07 2014-09-02 일렉트로룩스 홈 프로덕츠 인코퍼레이티드 용품들을 위한 다중 프로토콜 통신 시스템
US8893077B1 (en) * 2011-10-12 2014-11-18 Google Inc. Service to generate API libraries from a description
US20130092032A1 (en) * 2011-10-18 2013-04-18 Bsh Home Appliances Corporation Intelligent home cooking appliance, associated systems, and/or methods
KR101985337B1 (ko) * 2011-10-26 2019-09-04 삼성전자 주식회사 전자기기 운용에 따른 메시지 전송 방법 및 그를 위한 시스템
US20150194048A1 (en) * 2011-11-14 2015-07-09 Jeremy Haubrich Universal Remote
US8839257B2 (en) 2011-11-22 2014-09-16 Microsoft Corporation Superseding of recovery actions based on aggregation of requests for automated sequencing and cancellation
EP2605178B1 (en) 2011-12-02 2018-10-17 BlackBerry Limited Method and device for secure notification of identity
US9192019B2 (en) 2011-12-07 2015-11-17 Abl Ip Holding Llc System for and method of commissioning lighting devices
MX351575B (es) * 2011-12-20 2017-10-18 Smart Wave Tech Corp Sistemas y metodos para autentificar productos a granel.
US20120109399A1 (en) * 2012-01-01 2012-05-03 Bao Tran Energy resource conservation systems and methods
US8825020B2 (en) * 2012-01-12 2014-09-02 Sensory, Incorporated Information access and device control using mobile phones and audio in the home environment
CN102609331A (zh) * 2012-01-19 2012-07-25 苏州希图视鼎微电子有限公司 Nand闪存的装载代码的文件格式
US9219361B1 (en) * 2012-01-31 2015-12-22 Intellectual Ventures Fund 79 Llc Methods, devices, and mediums associated with power management of electrical devices
US10817848B2 (en) 2012-02-07 2020-10-27 Whirlpool Corporation Appliance monitoring systems
US10013677B2 (en) 2012-02-07 2018-07-03 Whirlpool Corporation Appliance monitoring systems and methods
US8981930B2 (en) 2012-02-07 2015-03-17 Scott Andrew Horstemeyer Appliance monitoring systems and methods
US8918885B2 (en) * 2012-02-09 2014-12-23 International Business Machines Corporation Automatic discovery of system integrity exposures in system code
US20130212668A1 (en) * 2012-02-13 2013-08-15 International Business Machines Corporation Suspension of Processes in Industrial Control System When an Anomaly Occurs
WO2013126738A1 (en) * 2012-02-24 2013-08-29 Meyer Intellectual Properties Ltd. Cookware with heat source under audible feedback control
US8594861B2 (en) * 2012-02-27 2013-11-26 Toyota Motor Engineering & Manufacturing North America, Inc. Systems and methods for communicating with a vehicle user
DE102012101537A1 (de) 2012-02-27 2013-08-29 Miele & Cie. Kg Haushaltsgerät mit einer Kommunikationseinrichtung
US9460303B2 (en) * 2012-03-06 2016-10-04 Microsoft Technology Licensing, Llc Operating large scale systems and cloud services with zero-standing elevated permissions
US20130278384A1 (en) * 2012-04-21 2013-10-24 Irena Jozic McDowell Appliance, device, and system for home energy management
EP2845353A4 (en) * 2012-05-01 2016-01-13 Duke Mfg Co SYSTEM AND METHOD OF CAN BUS BUSINESS DEVICES
US10250638B2 (en) * 2012-05-02 2019-04-02 Elwha Llc Control of transmission to a target device with a cloud-based architecture
EP2663025B1 (de) * 2012-05-10 2016-10-26 Miele & Cie. KG Verfahren zum Betrieb eines Haushaltsgerätenetzwerks und Haushaltsgerät zur Verwendung in einem solchen Netzwerk
US8738664B2 (en) * 2012-05-23 2014-05-27 Lg Chem, Ltd. System and method for generating diagnostic test files associated with a battery pack
KR101942781B1 (ko) 2012-07-03 2019-01-28 엘지전자 주식회사 가전기기 및 가전기기 진단을 위한 신호음 출력방법
KR20140007178A (ko) 2012-07-09 2014-01-17 엘지전자 주식회사 가전기기 및 그 시스템
US20140022917A1 (en) * 2012-07-17 2014-01-23 Procter And Gamble, Inc. Home network of connected consumer devices
US9468162B2 (en) 2012-08-01 2016-10-18 Rain Bird Corporation Irrigation controller wireless network adapter and networked remote service
US8997203B2 (en) * 2012-08-07 2015-03-31 Blackberry Limited Filtering network packets in multiple forwarding information base systems
US9378055B1 (en) 2012-08-22 2016-06-28 Societal Innovations Ipco Limited Configurable platform architecture and method for use thereof
DE102012017386B4 (de) 2012-09-01 2020-10-15 Volkswagen Aktiengesellschaft Verfahren zum Überwachen einer mit einem Kommunikationskanal verbundenen Vorrichtung
US9536049B2 (en) 2012-09-07 2017-01-03 Next It Corporation Conversational virtual healthcare assistant
US9020486B2 (en) * 2012-09-14 2015-04-28 Sheng-Yuan SHIH Real-time management system for mobile electronic devices
US10006462B2 (en) 2012-09-18 2018-06-26 Regal Beloit America, Inc. Systems and method for wirelessly communicating with electric motors
JP6239906B2 (ja) * 2012-09-19 2017-11-29 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカＰａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ アクセス制御方法、アクセス制御システム、通信端末、及び、サーバ
WO2014045175A1 (en) * 2012-09-21 2014-03-27 Koninklijke Philips N.V. Method and apparatus for dynamic address assignment
US20140096270A1 (en) * 2012-09-28 2014-04-03 Richard T. Beckwith Secure data containers and data access control
KR20140050204A (ko) * 2012-10-18 2014-04-29 한국전자통신연구원 홈 에너지 관리 서비스 프로비저닝 방법 및 장치
EP2730159B1 (en) 2012-11-07 2019-03-20 Rain Bird Corporation Irrigation control system
US9451031B2 (en) * 2012-11-28 2016-09-20 Visible Energy, Inc. Cloud-based refrigeration system
US20140156281A1 (en) * 2012-12-03 2014-06-05 Qualcomm Incorporated Voice-controlled configuration of an automation system
US8881249B2 (en) 2012-12-12 2014-11-04 Microsoft Corporation Scalable and automated secret management
WO2014098901A1 (en) * 2012-12-21 2014-06-26 Hewlett-Packard Development Company, L.P. Active component embedded in cable
US20140179222A1 (en) * 2012-12-21 2014-06-26 Vishal Chaudhary Method and system for effective and efficient service support
US10330713B2 (en) 2012-12-21 2019-06-25 Electro Industries/Gauge Tech Intelligent electronic device having a touch sensitive user interface
US9716530B2 (en) 2013-01-07 2017-07-25 Samsung Electronics Co., Ltd. Home automation using near field communication
US8954956B2 (en) * 2013-01-15 2015-02-10 Wigwag, Llc Distributing and executing software code
US9008642B2 (en) 2013-01-17 2015-04-14 General Electric Company Mobile phone to appliance communication via audio sampling
US10094585B2 (en) 2013-01-25 2018-10-09 Honeywell International Inc. Auto test for delta T diagnostics in an HVAC system
US9870716B1 (en) * 2013-01-26 2018-01-16 Ip Holdings, Inc. Smart glasses and smart watches for real time connectivity and health
US9336118B2 (en) 2013-01-28 2016-05-10 Hewlett Packard Enterprise Development Lp Allocating test capacity from cloud systems
WO2014117247A1 (en) * 2013-01-29 2014-08-07 Blackberry Limited Managing application access to certificates and keys
US10085585B2 (en) * 2013-02-21 2018-10-02 Rain Mountain, Llc System and methods of improving the performance, safety and energy efficiency of a cooking appliance
US10386827B2 (en) 2013-03-04 2019-08-20 Fisher-Rosemount Systems, Inc. Distributed industrial performance monitoring and analytics platform
US10649449B2 (en) 2013-03-04 2020-05-12 Fisher-Rosemount Systems, Inc. Distributed industrial performance monitoring and analytics
US9558220B2 (en) 2013-03-04 2017-01-31 Fisher-Rosemount Systems, Inc. Big data in process control systems
US10909137B2 (en) 2014-10-06 2021-02-02 Fisher-Rosemount Systems, Inc. Streaming data for analytics in process control systems
US10282676B2 (en) 2014-10-06 2019-05-07 Fisher-Rosemount Systems, Inc. Automatic signal processing-based learning in a process plant
US10649424B2 (en) 2013-03-04 2020-05-12 Fisher-Rosemount Systems, Inc. Distributed industrial performance monitoring and analytics
US9665088B2 (en) 2014-01-31 2017-05-30 Fisher-Rosemount Systems, Inc. Managing big data in process control systems
US10678225B2 (en) 2013-03-04 2020-06-09 Fisher-Rosemount Systems, Inc. Data analytic services for distributed industrial performance monitoring
US10866952B2 (en) 2013-03-04 2020-12-15 Fisher-Rosemount Systems, Inc. Source-independent queries in distributed industrial system
US10223327B2 (en) 2013-03-14 2019-03-05 Fisher-Rosemount Systems, Inc. Collecting and delivering data to a big data machine in a process control system
CN105009003A (zh) * 2013-03-05 2015-10-28 施耐德电气美国股份有限公司 用于管理工业过程的系统和方法
US10063499B2 (en) 2013-03-07 2018-08-28 Samsung Electronics Co., Ltd. Non-cloud based communication platform for an environment control system
US20150019323A1 (en) * 2013-03-13 2015-01-15 Paul R. Goldberg Secure consumer data and metrics exchange method, apparatus, and system therefor
US20140263410A1 (en) * 2013-03-15 2014-09-18 The Coca-Cola Company Dispensing beverage components for use as ingredients in recipes
US10671028B2 (en) 2013-03-15 2020-06-02 Fisher-Rosemount Systems, Inc. Method and apparatus for managing a work flow in a process plant
EP2973242B1 (en) 2013-03-15 2020-12-23 Fisher-Rosemount Systems, Inc. Modelling and adjustment of process plants
US20140282103A1 (en) * 2013-03-16 2014-09-18 Jerry Alan Crandall Data sharing
US8819127B1 (en) * 2013-04-12 2014-08-26 Fmr Llc Ensemble computing
US10445115B2 (en) * 2013-04-18 2019-10-15 Verint Americas Inc. Virtual assistant focused user interfaces
FI20135421A (fi) * 2013-04-24 2014-10-25 Tellabs Oy Menetelmä sähkölaitteen ohjaamiseksi ja sähkölaite
US9696703B2 (en) 2013-05-18 2017-07-04 Fipak Research And Development Company Method and apparatus for ensuring air quality in a building, including method and apparatus for controlling a working device using a handheld unit having scanning, networking, display and input capability
US9135604B2 (en) * 2013-06-03 2015-09-15 Sap Se Synchronizing real and virtual software development
KR20140147583A (ko) * 2013-06-20 2014-12-30 한국전자통신연구원 산업제어 시스템의 부정 접근을 방지하기 위한 장치 및 그 방법
US9112790B2 (en) 2013-06-25 2015-08-18 Google Inc. Fabric network
JP6359304B2 (ja) * 2013-06-27 2018-07-18 東芝ライフスタイル株式会社 家電機器およびネットワークシステム
KR102085114B1 (ko) * 2013-07-17 2020-03-05 삼성전자주식회사 홈 네트워크 시스템에서 스마트 모듈을 이용한 통신 방법 및 장치
US9431014B2 (en) 2013-07-25 2016-08-30 Haier Us Appliance Solutions, Inc. Intelligent placement of appliance response to voice command
US10440165B2 (en) 2013-07-26 2019-10-08 SkyBell Technologies, Inc. Doorbell communication and electrical systems
EP3025455A1 (en) * 2013-07-26 2016-06-01 Xtera Communications. Inc. Network management system architecture of a telecommunications network
US20170263067A1 (en) 2014-08-27 2017-09-14 SkyBell Technologies, Inc. Smart lock systems and methods
US10672238B2 (en) 2015-06-23 2020-06-02 SkyBell Technologies, Inc. Doorbell communities
US20180343141A1 (en) 2015-09-22 2018-11-29 SkyBell Technologies, Inc. Doorbell communication systems and methods
US10708404B2 (en) 2014-09-01 2020-07-07 Skybell Technologies Ip, Llc Doorbell communication and electrical systems
US11764990B2 (en) 2013-07-26 2023-09-19 Skybell Technologies Ip, Llc Doorbell communications systems and methods
US11651665B2 (en) 2013-07-26 2023-05-16 Skybell Technologies Ip, Llc Doorbell communities
US11889009B2 (en) 2013-07-26 2024-01-30 Skybell Technologies Ip, Llc Doorbell communication and electrical systems
US20170084132A1 (en) * 2013-07-26 2017-03-23 SkyBell Technologies, Inc. Doorbell communication systems and methods
US11909549B2 (en) 2013-07-26 2024-02-20 Skybell Technologies Ip, Llc Doorbell communication systems and methods
US20150046704A1 (en) * 2013-08-06 2015-02-12 Texas Instruments Incorporated Target directed joining algorithm for multi-pan networks
US9366702B2 (en) 2013-08-23 2016-06-14 Green Edge Technologies, Inc. Devices and methods for determining whether an electrical device or component can sustain variations in voltage
WO2015037963A1 (en) * 2013-09-16 2015-03-19 Lg Electronics Inc. Home appliance and mobile terminal
US9756131B2 (en) * 2013-10-01 2017-09-05 Verizon Deutschland Gmbh Label for use in the internet of things
US9736688B2 (en) 2013-10-04 2017-08-15 Sol Mingso Li Systems and methods for programming, controlling and monitoring wireless networks
US11812258B2 (en) 2013-10-04 2023-11-07 Sol Mingso Li Systems and methods for programming, controlling and monitoring wireless networks
US10652735B2 (en) 2013-10-04 2020-05-12 Sol Mingso Li Systems and methods for programming, controlling and monitoring wireless networks
CN104580079A (zh) * 2013-10-16 2015-04-29 宇宙互联有限公司 远程控制系统及方法
RU2016121848A (ru) * 2013-11-04 2017-12-11 Конинклейке Филипс Н.В. Способ уведомления пользователя о задаче аппарата
DE102013223934A1 (de) * 2013-11-22 2015-05-28 BSH Hausgeräte GmbH Haushaltsgerät
US9928672B2 (en) * 2013-12-05 2018-03-27 Wallflower Labs Inc. System and method of monitoring and controlling appliances and powered devices using radio-enabled proximity sensing
US9794989B2 (en) * 2013-12-06 2017-10-17 Panasonic Intellectual Property Corporation Of America Terminal apparatus and control method for assistive cooking
US20150179054A1 (en) * 2013-12-20 2015-06-25 Lennox Industries Inc. Mobile device interface for commercial rtu
EP3092750B1 (en) 2014-01-06 2020-07-15 Samsung Electronics Co., Ltd. System, device, and apparatus for coordinating environments using network devices and remote sensory information
CA2936076C (en) 2014-01-06 2022-07-26 Allure Energy, Inc. System, device, and apparatus for coordinating environments using network devices and remote sensory information
WO2015116326A1 (en) * 2014-01-30 2015-08-06 Exxonmobil Research And Engineering Company Real time optimization of batch processes
CN103820970A (zh) * 2014-02-25 2014-05-28 江苏新安电器有限公司 一种可远程控制的洗衣机
EP3110506B1 (en) * 2014-02-28 2023-11-01 Fipak Research And Development Company Method and apparatus for ensuring air quality in a building, including method and apparatus for controlling a working device using a handheld unit having scanning, networking, display and input capability
DE102014206602A1 (de) * 2014-04-04 2015-10-08 BSH Hausgeräte GmbH Verfahren zum Konfigurieren eines Haushaltsgeräts sowie Haushaltsgerät
US9647888B2 (en) 2014-05-30 2017-05-09 Belkin International Inc. Network addressable appliance interface device
US9660458B2 (en) 2014-05-06 2017-05-23 Google Inc. Electrical load management
DE102014208861A1 (de) * 2014-05-12 2015-11-12 BSH Hausgeräte GmbH Wasserführendes Haushaltsgerät
EP3146428A1 (en) 2014-05-21 2017-03-29 Societal Innovations Ipco Limited System and method for fully configurable real time processing
US10154095B2 (en) 2014-05-21 2018-12-11 N.Io Innovation, Llc System and method for aggregating and acting on signals from one or more remote sources in real time using a configurable platform instance
US9891893B2 (en) 2014-05-21 2018-02-13 N.Io Innovation, Llc System and method for a development environment for building services for a platform instance
DE102014107163A1 (de) * 2014-05-21 2015-11-26 Vorwerk & Co. Interholding Gmbh Elektrisch betriebenes Haushaltsgerät
US10412208B1 (en) * 2014-05-30 2019-09-10 Apple Inc. Notification systems for smart band and methods of operation
US9741244B2 (en) * 2014-05-30 2017-08-22 Qualcomm Incorporated Methods, smart objects, and systems for naming and interacting with smart objects
US9294575B1 (en) 2014-06-04 2016-03-22 Grandios Technologies, Inc. Transmitting appliance-specific content to a user device
US11184589B2 (en) 2014-06-23 2021-11-23 Skybell Technologies Ip, Llc Doorbell communication systems and methods
US20170085843A1 (en) 2015-09-22 2017-03-23 SkyBell Technologies, Inc. Doorbell communication systems and methods
TWI602372B (zh) * 2014-06-25 2017-10-11 易家居聯網科技有限公司 電器設備監控方法與電器設備監控系統
US20160000251A1 (en) * 2014-07-03 2016-01-07 Carla Mosley Stove shut off system
AU2015288164A1 (en) 2014-07-07 2017-02-16 Breville USA, Inc. Systems, articles and methods related to providing customized cooking instruction
US10820750B2 (en) 2014-08-05 2020-11-03 Lynx Grills, Inc. Computer-controlled grills
EP3189608B1 (en) * 2014-09-04 2019-12-11 University Of Washington Detecting user-driven operating states of electronic devices from a single sensing point
DE102014113040A1 (de) 2014-09-10 2016-03-10 Miele & Cie. Kg Verfahren zum Betrieb eines Haushaltsgerätesystems
US10226146B1 (en) 2014-09-21 2019-03-12 Smartstr Inc. Electric cooking system and a cooking method using the same
US10190248B2 (en) * 2014-09-27 2019-01-29 Esporta Wash Systems Inc. System for monitoring restoration quality to a third party certified standard of soft objects being washed remotely
US9942229B2 (en) * 2014-10-03 2018-04-10 Gopro, Inc. Authenticating a limited input device via an authenticated application
US9410712B2 (en) 2014-10-08 2016-08-09 Google Inc. Data management profile for a fabric network
US10447676B2 (en) * 2014-10-10 2019-10-15 Adp, Llc Securing application programming interfaces (APIS) through infrastructure virtualization
US10810222B2 (en) 2014-11-24 2020-10-20 Asana, Inc. Continuously scrollable calendar user interface
EP3029380A1 (en) * 2014-12-03 2016-06-08 Electrolux Appliances Aktiebolag Method for performing a treatment by a domestic appliance and for processing information of said treatment by a mobile computer device
US10114638B2 (en) * 2014-12-15 2018-10-30 Cisco Technology, Inc. Command message generation and execution using a machine code-instruction
US11751712B2 (en) 2014-12-22 2023-09-12 Breville USA, Inc. Food preparation guidance system
CN104539454B (zh) * 2014-12-24 2018-09-04 小米科技有限责任公司 设备管理方法、装置及系统
US10316581B1 (en) 2015-01-12 2019-06-11 Kinestral Technologies, Inc. Building model generation and intelligent light control for smart windows
US20160213187A1 (en) * 2015-01-27 2016-07-28 General Electric Company Method for operating an appliance in a sabbath operating mode
US10009965B2 (en) * 2015-01-28 2018-06-26 Samsung Electronics Co., Ltd. Gas detection apparatus, cooking apparatus, and method of controlling the apparatuses
CN107466219B (zh) 2015-01-30 2020-07-10 布瑞威利美国公司 食物制备控制系统
US9729534B2 (en) * 2015-02-26 2017-08-08 Seagate Technology Llc In situ device authentication and diagnostic repair in a host environment
US10742938B2 (en) 2015-03-07 2020-08-11 Skybell Technologies Ip, Llc Garage door communication systems and methods
US9762585B2 (en) 2015-03-19 2017-09-12 Microsoft Technology Licensing, Llc Tenant lockbox
US10073707B2 (en) 2015-03-23 2018-09-11 n.io Innovations, LLC System and method for configuring a platform instance at runtime
US10503145B2 (en) 2015-03-25 2019-12-10 Honeywell International Inc. System and method for asset fleet monitoring and predictive diagnostics using analytics for large and varied data sources
US11575537B2 (en) 2015-03-27 2023-02-07 Skybell Technologies Ip, Llc Doorbell communication systems and methods
US10605460B2 (en) * 2015-03-30 2020-03-31 Samsung Electronics Co., Ltd. Cooking apparatus
US11381686B2 (en) 2015-04-13 2022-07-05 Skybell Technologies Ip, Llc Power outlet cameras
CN107409278B (zh) * 2015-04-29 2021-03-02 索尔·明索·李 用于对无线网络进行编程、控制和监控的系统和方法
CA2984503A1 (en) 2015-05-01 2016-11-10 Hubbell Incorporated Devices, systems, and methods for controlling electrical loads
US11641452B2 (en) 2015-05-08 2023-05-02 Skybell Technologies Ip, Llc Doorbell communication systems and methods
JP6796912B2 (ja) * 2015-05-26 2020-12-09 株式会社リコー 情報処理装置、情報処理システム、及びプログラム
CN106297057B (zh) * 2015-06-23 2020-12-25 青岛海尔洗衣机有限公司 自助洗衣机的控制方法、终端及系统
US20180047269A1 (en) 2015-06-23 2018-02-15 SkyBell Technologies, Inc. Doorbell communities
KR102315345B1 (ko) * 2015-06-26 2021-10-20 삼성전자주식회사 노드 단말 장치, 디스플레이 장치, 이를 포함하는 주변 기기 관리 시스템 및 그 방법
US10931682B2 (en) 2015-06-30 2021-02-23 Microsoft Technology Licensing, Llc Privileged identity management
CN115462678A (zh) 2015-07-21 2022-12-13 布瑞威利美国公司 食物制备控制系统
US10706702B2 (en) 2015-07-30 2020-07-07 Skybell Technologies Ip, Llc Doorbell package detection systems and methods
US10027866B2 (en) 2015-08-05 2018-07-17 Whirlpool Corporation Refrigerators having internal content cameras, and methods of operating the same
KR102436513B1 (ko) * 2015-08-12 2022-08-26 삼성전자 주식회사 전자 기기의 해상도 조정 방법 및 장치
KR101709469B1 (ko) * 2015-09-11 2017-02-23 엘지전자 주식회사 이동 단말기, 및 홈 어플라이언스
CN106549996A (zh) * 2015-09-22 2017-03-29 青岛海尔滚筒洗衣机有限公司 基于二维码的装置使用方法及洗衣机
JP2019506073A (ja) * 2015-10-08 2019-02-28 テラルクス，インコーポレイティド 追加導入されたデバイスの設定と立ち上げ
US10944591B2 (en) 2015-10-14 2021-03-09 Electrolux Home Products, Inc. Automatically setting a clock of a network-connected apparatus
US10346446B2 (en) * 2015-11-02 2019-07-09 Radiant Geospatial Solutions Llc System and method for aggregating multi-source data and identifying geographic areas for data acquisition
JPWO2017077695A1 (ja) * 2015-11-05 2018-08-23 パナソニックＩｐマネジメント株式会社 加熱調理器
US10346281B2 (en) * 2015-11-12 2019-07-09 Oracle International Corporation Obtaining and analyzing a reduced metric data set
CA3005618A1 (en) 2015-11-16 2017-05-26 ChefSteps, Inc. Data aggregation and personalization for remotely controlled cooking devices
CN106702677B (zh) * 2015-11-17 2019-03-19 泰科电子(上海)有限公司 家电总线控制系统
JP2019503468A (ja) * 2015-11-19 2019-02-07 パーメット・エルエルシー 食品の貯蔵および処理用の統合され区画化されたシステム
US9742581B2 (en) 2015-12-18 2017-08-22 Whirlpool Corporation Appliance network with messaging
KR102416688B1 (ko) * 2016-01-06 2022-07-05 엘지전자 주식회사 식기세척기
ES2684424T3 (es) 2016-02-09 2018-10-02 Vorwerk & Co. Interholding Gmbh Sistema y método para sincronizar los pasos de procesamiento de alimentos de un aparato de cocción multifunción con pasos de procesamiento de alimentos de un dispositivo de cocina a distancia
US10503483B2 (en) 2016-02-12 2019-12-10 Fisher-Rosemount Systems, Inc. Rule builder in a process control network
WO2017142339A1 (en) 2016-02-19 2017-08-24 Samsung Electronics Co., Ltd. Dongle apparatus and method of controlling the same
KR102403117B1 (ko) * 2016-02-22 2022-05-27 삼성전자주식회사 동글 및 그의 제어 방법
US10657199B2 (en) 2016-02-25 2020-05-19 Honeywell International Inc. Calibration technique for rules used with asset monitoring in industrial process control and automation systems
US10776706B2 (en) 2016-02-25 2020-09-15 Honeywell International Inc. Cost-driven system and method for predictive equipment failure detection
US11104502B2 (en) * 2016-03-01 2021-08-31 Jeffrey S. Melcher Multi-function compact appliance and methods for a food or item in a container with a container storage technology
EP3430840B1 (en) * 2016-03-14 2021-08-11 Robert Bosch GmbH Distributed wireless intercom audio routing over ethernet with roaming
KR101776909B1 (ko) * 2016-03-29 2017-09-19 조용진 사물 인터넷 서비스를 제공하기 위한 동글 시스템
KR20170114360A (ko) 2016-04-04 2017-10-16 엘에스산전 주식회사 Ｎ－스크린 기능을 지원하는 원격 관리 시스템
US10257270B2 (en) * 2016-04-26 2019-04-09 International Business Machines Corporation Autonomous decentralized peer-to-peer telemetry
WO2017188909A1 (en) * 2016-04-28 2017-11-02 Gokmen Sabri Haluk Fuzzy logic algorithm based oven temperature control system
EP3449452B1 (en) 2016-04-29 2022-06-29 Nchain Holdings Limited Implementing logic gate functionality using a blockchain
US11032282B2 (en) * 2016-04-29 2021-06-08 Ncr Corporation Interlinking cross platform authorization and processing
US10666654B2 (en) 2016-05-15 2020-05-26 Bank Of America Corporation Linking channel-specific systems with a user authentication hub to provide omni-channel user authentication
US10643212B2 (en) 2016-05-15 2020-05-05 Bank Of America Corporation Linking channel-specific systems with a user authentication hub to provide omni-channel user authentication
US10049088B1 (en) * 2016-05-26 2018-08-14 Kirio Inc. Automated configuration system for complex system requiring exhaustive custom programming
US10853482B2 (en) 2016-06-03 2020-12-01 Honeywell International Inc. Secure approach for providing combined environment for owners/operators and multiple third parties to cooperatively engineer, operate, and maintain an industrial process control and automation system
US11003147B2 (en) 2016-06-12 2021-05-11 Apple Inc. Automatically grouping accessories
US10498552B2 (en) 2016-06-12 2019-12-03 Apple Inc. Presenting accessory state
JP6657025B2 (ja) * 2016-06-17 2020-03-04 シャープ株式会社 操作者推定システム
US10079881B2 (en) 2016-06-30 2018-09-18 International Business Machines Corporation Device self-servicing in an autonomous decentralized peer-to-peer environment
US10572530B2 (en) * 2016-07-03 2020-02-25 Apple Inc. Prefetching accessory data
WO2018013964A1 (en) 2016-07-15 2018-01-18 Rain Bird Corporation Wireless remote irrigation control
US10623509B2 (en) * 2016-07-28 2020-04-14 Accenture Global Solutions Limited Intelligent maintenance and repair of user properties
KR20190000908U (ko) * 2016-08-05 2019-04-15 코닌클리케 필립스 엔.브이. 주방 기구들의 유도성 가열 및 무선 급전을 갖는 요리 시스템
US10310467B2 (en) 2016-08-30 2019-06-04 Honeywell International Inc. Cloud-based control platform with connectivity to remote embedded devices in distributed control system
US9584381B1 (en) 2016-10-10 2017-02-28 Extrahop Networks, Inc. Dynamic snapshot value by turn for continuous packet capture
DE102016221614A1 (de) * 2016-11-04 2018-05-09 BSH Hausgeräte GmbH Verbinden eines Haushaltsgeräts mit einer Fernbedienung
US11190926B2 (en) 2016-11-09 2021-11-30 Ledvance Llc Radio based smart device identification tool for commissioning
DE102016125951A1 (de) * 2016-12-30 2018-07-05 Fresenius Medical Care Deutschland Gmbh Vorrichtung zum Übertragen von Betriebs- und Maschinendaten eines Medizingeräts, Medizingerät sowie Verfahren zum Übertragen von Betriebs- und Maschinendaten eines Medizingeräts
US10087572B2 (en) 2017-02-16 2018-10-02 Whirlpool Corporation Washing machine
CN107018049A (zh) * 2017-03-09 2017-08-04 广东美的制冷设备有限公司 家电设备配网方法、装置和系统
US10476673B2 (en) 2017-03-22 2019-11-12 Extrahop Networks, Inc. Managing session secrets for continuous packet capture systems
GB2560765A (en) * 2017-03-24 2018-09-26 Howden Joinery Ltd Domestic product
CN106970796A (zh) * 2017-03-29 2017-07-21 四川长虹电器股份有限公司 基于状态机的冰箱主控软件设计方法
US10009963B1 (en) 2017-04-17 2018-06-26 Silicon Valley Factory LLC Decoding a custom cooking program
US10120553B1 (en) * 2017-04-17 2018-11-06 Sebastian Thrun User interface and controller for a heating system
US10061285B1 (en) 2017-04-17 2018-08-28 Silicon Valley Factory LLC Encoding a custom cooking program
US10070485B1 (en) 2017-04-17 2018-09-04 Silicon Valley Factory LLC Automatic heating system and method
US10101035B1 (en) 2017-04-17 2018-10-16 Silicon Valley Factory LLC Custom cooking program based on feedback
CN110495140B (zh) * 2017-04-21 2021-09-07 丹佛斯有限公司 用于控制冷却系统的控制系统
US20180324061A1 (en) * 2017-05-03 2018-11-08 Extrahop Networks, Inc. Detecting network flow states for network traffic analysis
CN108931931A (zh) * 2017-05-27 2018-12-04 青岛海尔洗衣机有限公司 洗衣机的信息采集装置、信息采集系统和洗衣机
CN109211078B (zh) * 2017-06-30 2021-07-13 佛山市顺德区美的电热电器制造有限公司 安装故障检测装置和烹饪器具
USD861723S1 (en) * 2017-07-05 2019-10-01 Lg Electronics Inc. Oven display screen with graphical user interface
US10977434B2 (en) 2017-07-11 2021-04-13 Asana, Inc. Database model which provides management of custom fields and methods and apparatus therfor
EP3428541B1 (en) * 2017-07-11 2020-05-06 Electrolux Appliances Aktiebolag Remote control system for controlling a domestic appliance
DE102017212316A1 (de) * 2017-07-19 2019-01-24 BSH Hausgeräte GmbH Haushaltsgeschirrspülmaschine, System mit Haushaltsgeschirrspülmaschine und Server und Verfahren zum Betreiben einer Haushaltsgeschirrspülmaschine
US10606586B2 (en) 2017-08-01 2020-03-31 Accenture Global Solutions Limited Application architecture generation
EP3438774B1 (de) * 2017-08-02 2021-09-29 Siemens Aktiengesellschaft Verfahren zur bereitstellung von funktionen innerhalb eines industriellen automatisierungssystems und automatisierungssystem
CN109407567B (zh) * 2017-08-16 2022-02-11 佛山市顺德区美的电热电器制造有限公司 加热平台的控制方法、控制系统以及烹饪器具
CN111034130A (zh) * 2017-08-25 2020-04-17 祖美股份有限公司 用于识别通信总线上的部件的系统和方法
US10887125B2 (en) * 2017-09-15 2021-01-05 Kohler Co. Bathroom speaker
US10909825B2 (en) 2017-09-18 2021-02-02 Skybell Technologies Ip, Llc Outdoor security systems and methods
US20190223660A1 (en) * 2017-10-20 2019-07-25 Connected Cooking Solutions Private Limited System and method for real time synchronization of set of instructions using iot devices
US9967292B1 (en) 2017-10-25 2018-05-08 Extrahop Networks, Inc. Inline secret sharing
EP3704880A4 (en) 2017-10-30 2021-08-18 Cummins Inc. INTELLIGENT CONNECTOR KIT
US10367650B2 (en) * 2017-11-06 2019-07-30 Cognizant Technology Solutions India Pvt. Ltd. System and method for efficiently developing and testing home automation systems
CN109751630B (zh) * 2017-11-06 2021-06-08 天下父母(北京)科技有限公司 一种超低功耗燃气灶控制方法
US10747968B2 (en) 2017-11-22 2020-08-18 Jeffrey S. Melcher Wireless device and selective user control and management of a wireless device and data
CN108199918B (zh) * 2017-12-28 2021-06-15 Tcl家用电器（合肥）有限公司 一种测试洗衣机的方法及系统
US10791001B2 (en) 2018-01-25 2020-09-29 Haier Us Appliance Solutions, Inc. Diagnostic tools and methods of servicing consumer appliances
US10506019B2 (en) * 2018-01-25 2019-12-10 Haier Us Appliance Solutions, Inc. Methods of servicing one or more consumer appliances
US10389574B1 (en) 2018-02-07 2019-08-20 Extrahop Networks, Inc. Ranking alerts based on network monitoring
US10038611B1 (en) 2018-02-08 2018-07-31 Extrahop Networks, Inc. Personalization of alerts based on network monitoring
US10270794B1 (en) 2018-02-09 2019-04-23 Extrahop Networks, Inc. Detection of denial of service attacks
US10623359B1 (en) 2018-02-28 2020-04-14 Asana, Inc. Systems and methods for generating tasks based on chat sessions between users of a collaboration environment
CN110365719B (zh) * 2018-03-26 2021-10-01 华为技术有限公司 一种数据处理的方法以及相关设备
IT201800004052A1 (it) * 2018-03-28 2019-09-28 Faber Spa Cappa verticale multifunzione perfezionata per aspirazione domestica
US11237550B2 (en) 2018-03-28 2022-02-01 Honeywell International Inc. Ultrasonic flow meter prognostics with near real-time condition based uncertainty analysis
US11138021B1 (en) 2018-04-02 2021-10-05 Asana, Inc. Systems and methods to facilitate task-specific workspaces for a collaboration work management platform
US10613735B1 (en) 2018-04-04 2020-04-07 Asana, Inc. Systems and methods for preloading an amount of content based on user scrolling
DE102018205524A1 (de) * 2018-04-12 2019-10-17 BSH Hausgeräte GmbH Geschirrspülmaschine, Verfahren zum Betreiben einer Geschirrspülmaschine und Computerprogrammprodukt
US10278540B1 (en) * 2018-04-20 2019-05-07 P. Kenneth Huggins Conveyor toaster assembly and method
CN112313924A (zh) * 2018-05-07 2021-02-02 谷歌有限责任公司 提供用于控制各种连接设备的复合图形助理界面
US10785046B1 (en) 2018-06-08 2020-09-22 Asana, Inc. Systems and methods for providing a collaboration work management platform that facilitates differentiation between users in an overarching group and one or more subsets of individual users
DE102018209688A1 (de) 2018-06-15 2019-12-19 BSH Hausgeräte GmbH Wasserführendes Haushaltsgerät, Verfahren zum Betreiben eines wasserführenden Haushaltsgeräts und Computerprogrammprodukt
CN108614462A (zh) * 2018-06-26 2018-10-02 山西清新新能源科技有限公司 一种智能能源处理系统
US11847010B2 (en) * 2018-07-02 2023-12-19 Haier Us Appliance Solutions, Inc. Appliance and methods for operating same in a safety-critical operation
CN109032827A (zh) * 2018-07-03 2018-12-18 郑州云海信息技术有限公司 一种跟踪导致内存溢出异常的测试系统及方法
WO2020031166A1 (en) * 2018-08-07 2020-02-13 Genie Enterprise Ltd. Automated, computer-controlled, cooking system and method
US10411978B1 (en) 2018-08-09 2019-09-10 Extrahop Networks, Inc. Correlating causes and effects associated with network activity
US10594718B1 (en) 2018-08-21 2020-03-17 Extrahop Networks, Inc. Managing incident response operations based on monitored network activity
US11213158B2 (en) 2018-08-29 2022-01-04 Breville USA, Inc. Cooking system
US11234380B2 (en) 2018-09-27 2022-02-01 Rain Bird Corporation Irrigation controller with relays
US10523673B1 (en) * 2018-10-08 2019-12-31 Quest Automated Services, LLC Automation system controller
US10616151B1 (en) 2018-10-17 2020-04-07 Asana, Inc. Systems and methods for generating and presenting graphical user interfaces
US11196863B2 (en) 2018-10-24 2021-12-07 Verint Americas Inc. Method and system for virtual assistant conversations
CN109547302B (zh) * 2018-11-08 2021-11-02 上海优悦信息科技有限公司 一种用于确定用户的关联目标信息的方法和家用电器
US10956845B1 (en) 2018-12-06 2021-03-23 Asana, Inc. Systems and methods for generating prioritization models and predicting workflow prioritizations
DE102018009944A1 (de) * 2018-12-18 2020-06-18 Diehl Ako Stiftung & Co. Kg Elektronisches Haushaltsgerät mit einem Steuerungssystem
US11568366B1 (en) 2018-12-18 2023-01-31 Asana, Inc. Systems and methods for generating status requests for units of work
US11113667B1 (en) 2018-12-18 2021-09-07 Asana, Inc. Systems and methods for providing a dashboard for a collaboration work management platform
US11631010B1 (en) 2019-01-06 2023-04-18 Adaptics Limited System and method for use with connected kitchen appliances
US11782737B2 (en) 2019-01-08 2023-10-10 Asana, Inc. Systems and methods for determining and presenting a graphical user interface including template metrics
US11204683B1 (en) 2019-01-09 2021-12-21 Asana, Inc. Systems and methods for generating and tracking hardcoded communications in a collaboration management platform
DE102019202085A1 (de) * 2019-02-15 2020-08-20 BSH Hausgeräte GmbH Steuern eines Haushaltsgeräts durch eine externe Stelle
US11269804B1 (en) * 2019-02-25 2022-03-08 Amazon Technologies, Inc. Hardware adapter to connect with a distributed network service
CN110069468A (zh) * 2019-03-18 2019-07-30 平安普惠企业管理有限公司 一种获取用户需求的方法及装置、电子设备
JP6962345B2 (ja) * 2019-03-22 2021-11-05 オムロン株式会社 情報処理装置、情報処理方法、および情報処理プログラム
US11722805B1 (en) 2019-04-10 2023-08-08 Alarm.Com Incorporated Electrical appliance power monitoring
US11206308B2 (en) 2019-04-26 2021-12-21 At&T Intellectual Property I, L.P. Facilitating support functionalities through a support appliance device in advanced networks
CN110209060B (zh) * 2019-05-23 2022-03-11 无锡小天鹅电器有限公司 一种控制方法及装置、设备和计算机存储介质
US10965702B2 (en) 2019-05-28 2021-03-30 Extrahop Networks, Inc. Detecting injection attacks using passive network monitoring
FI3994910T3 (fi) * 2019-07-01 2023-06-13 Signify Holding Bv Automaattinen toiminnan uudelleenkäynnistysjärjestelmä langattomille verkkolaitteille
US11165814B2 (en) 2019-07-29 2021-11-02 Extrahop Networks, Inc. Modifying triage information based on network monitoring
US10742530B1 (en) 2019-08-05 2020-08-11 Extrahop Networks, Inc. Correlating network traffic that crosses opaque endpoints
US11388072B2 (en) 2019-08-05 2022-07-12 Extrahop Networks, Inc. Correlating network traffic that crosses opaque endpoints
US11075848B2 (en) * 2019-08-21 2021-07-27 Hewlett Packard Enterprise Development Lp Fast path for acknowledgement frames in wireless networks
JP2022545039A (ja) 2019-08-24 2022-10-24 スカイベル テクノロジーズ アイピー、エルエルシー ドアベル通信システム及び方法
US10742677B1 (en) 2019-09-04 2020-08-11 Extrahop Networks, Inc. Automatic determination of user roles and asset types based on network monitoring
US11016921B2 (en) * 2019-10-24 2021-05-25 Haier Us Appliance Solutions, Inc. Appliances and methods for off-board data storage
US11833517B2 (en) 2019-11-15 2023-12-05 Sundance Spas, Inc. Water testing systems and devices
EP3836043A1 (en) * 2019-12-11 2021-06-16 Carrier Corporation A method and an equipment for configuring a service
US11165823B2 (en) 2019-12-17 2021-11-02 Extrahop Networks, Inc. Automated preemptive polymorphic deception
US11783253B1 (en) 2020-02-11 2023-10-10 Asana, Inc. Systems and methods to effectuate sets of automated actions outside and/or within a collaboration environment based on trigger events occurring outside and/or within the collaboration environment
US11599855B1 (en) * 2020-02-14 2023-03-07 Asana, Inc. Systems and methods to attribute automated actions within a collaboration environment
US11763259B1 (en) 2020-02-20 2023-09-19 Asana, Inc. Systems and methods to generate units of work in a collaboration environment
US11501010B2 (en) 2020-05-20 2022-11-15 Snowflake Inc. Application-provisioning framework for database platforms
US11593354B2 (en) 2020-05-20 2023-02-28 Snowflake Inc. Namespace-based system-user access of database platforms
CN113818198B (zh) * 2020-06-18 2024-01-19 青岛海尔洗衣机有限公司 一种用于洗衣机的衣物处理剂的投放方法及洗衣机
US11900323B1 (en) 2020-06-29 2024-02-13 Asana, Inc. Systems and methods to generate units of work within a collaboration environment based on video dictation
US11455601B1 (en) 2020-06-29 2022-09-27 Asana, Inc. Systems and methods to measure and visualize workload for completing individual units of work
US11449836B1 (en) 2020-07-21 2022-09-20 Asana, Inc. Systems and methods to facilitate user engagement with units of work assigned within a collaboration environment
US11568339B2 (en) 2020-08-18 2023-01-31 Asana, Inc. Systems and methods to characterize units of work based on business objectives
WO2022066910A1 (en) 2020-09-23 2022-03-31 Extrahop Networks, Inc. Monitoring encrypted network traffic
US11463466B2 (en) 2020-09-23 2022-10-04 Extrahop Networks, Inc. Monitoring encrypted network traffic
CN112165413B (zh) * 2020-09-27 2022-08-26 海尔优家智能科技（北京）有限公司 设备状态上报方法及装置、电子装置
US11769115B1 (en) 2020-11-23 2023-09-26 Asana, Inc. Systems and methods to provide measures of user workload when generating units of work based on chat sessions between users of a collaboration environment
US11405435B1 (en) 2020-12-02 2022-08-02 Asana, Inc. Systems and methods to present views of records in chat sessions between users of a collaboration environment
US20220279976A1 (en) * 2021-03-02 2022-09-08 Blendtec, Inc. Blender control system
US11694162B1 (en) 2021-04-01 2023-07-04 Asana, Inc. Systems and methods to recommend templates for project-level graphical user interfaces within a collaboration environment
US11676107B1 (en) 2021-04-14 2023-06-13 Asana, Inc. Systems and methods to facilitate interaction with a collaboration environment based on assignment of project-level roles
US11553045B1 (en) 2021-04-29 2023-01-10 Asana, Inc. Systems and methods to automatically update status of projects within a collaboration environment
US11803814B1 (en) 2021-05-07 2023-10-31 Asana, Inc. Systems and methods to facilitate nesting of portfolios within a collaboration environment
US11792028B1 (en) 2021-05-13 2023-10-17 Asana, Inc. Systems and methods to link meetings with units of work of a collaboration environment
US11809222B1 (en) 2021-05-24 2023-11-07 Asana, Inc. Systems and methods to generate units of work within a collaboration environment based on selection of text
US11349861B1 (en) 2021-06-18 2022-05-31 Extrahop Networks, Inc. Identifying network entities based on beaconing activity
US11801599B2 (en) * 2021-09-01 2023-10-31 Xtend Ai Inc. Method for designing special function robots
US11756000B2 (en) 2021-09-08 2023-09-12 Asana, Inc. Systems and methods to effectuate sets of automated actions within a collaboration environment including embedded third-party content based on trigger events
US11296967B1 (en) 2021-09-23 2022-04-05 Extrahop Networks, Inc. Combining passive network analysis and active probing
US11635884B1 (en) 2021-10-11 2023-04-25 Asana, Inc. Systems and methods to provide personalized graphical user interfaces within a collaboration environment
US11947714B2 (en) 2021-11-09 2024-04-02 Haier Us Appliance Solutions, Inc. System and method for authorizing appliance access
US11811548B2 (en) * 2022-02-02 2023-11-07 Barracuda Networks, Inc. System and method for appliance configuration identification and profile management
US11836681B1 (en) 2022-02-17 2023-12-05 Asana, Inc. Systems and methods to generate records within a collaboration environment
US11843606B2 (en) 2022-03-30 2023-12-12 Extrahop Networks, Inc. Detecting abnormal data access based on data similarity
US11888640B2 (en) * 2022-05-03 2024-01-30 Haier Us Appliance Solutions, Inc. System and method for data transmission for appliance
US11930980B2 (en) * 2022-05-04 2024-03-19 Haier Us Appliance Solutions, Inc. Appliance and method for cleaning context detection
US11811681B1 (en) 2022-07-12 2023-11-07 T-Mobile Usa, Inc. Generating and deploying software architectures using telecommunication resources
DE102022119591B4 (de) * 2022-08-04 2024-03-21 Wittenstein Se Verfahren zur Bereitstellung von Antriebsdaten und Computersystem
US11863601B1 (en) 2022-11-18 2024-01-02 Asana, Inc. Systems and methods to execute branching automation schemes in a collaboration environment
US11902129B1 (en) 2023-03-24 2024-02-13 T-Mobile Usa, Inc. Vendor-agnostic real-time monitoring of telecommunications networks

Family Cites Families (284)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4303990A (en) * 1976-07-01 1981-12-01 Gulf & Western Industries, Inc. Programmable controller using microprocessor
US4345132A (en) * 1978-12-01 1982-08-17 Mitsubishi Denki Kabushiki Kaisha Cooking apparatus
JPS56935A (en) * 1979-06-15 1981-01-08 Matsushita Electric Ind Co Ltd High-frequency heating device
US4425627A (en) * 1981-02-23 1984-01-10 Sperry Corporation Intelligent prompting terminal apparatus
US4447692A (en) * 1981-05-18 1984-05-08 Essex Group, Inc. Control system with interactive display
US4480307A (en) * 1982-01-04 1984-10-30 Intel Corporation Interface for use between a memory and components of a module switching apparatus
JPS58148316A (ja) 1982-02-26 1983-09-03 Sharp Corp 調理装置
US4503535A (en) * 1982-06-30 1985-03-05 Intel Corporation Apparatus for recovery from failures in a multiprocessing system
US4520576A (en) * 1983-09-06 1985-06-04 Whirlpool Corporation Conversational voice command control system for home appliance
US4823283A (en) * 1986-10-14 1989-04-18 Tektronix, Inc. Status driven menu system
US5041967A (en) * 1987-10-13 1991-08-20 Bell Communications Research, Inc. Methods and apparatus for dynamic menu generation in a menu driven computer system
US5124942A (en) * 1988-09-28 1992-06-23 Solatrol, Inc. Machine interface with cyclically displayed hierarchical menus and user selection of menu items by actuation of a single switch
US5187797A (en) * 1988-09-28 1993-02-16 Solatrol, Inc. Machine interface system with hierarchal menus allowing user sequencing and selection of menu items by actuation of three switches
NO303200B1 (no) * 1988-11-04 1998-06-08 Merlin Gerin Bygningsteknisk styringsenhet med totrÕds data- og kraftforsyningslinje
US5113398A (en) * 1989-06-01 1992-05-12 Shackleton System Drives Corporation Self-healing data network and network node controller
US5396635A (en) * 1990-06-01 1995-03-07 Vadem Corporation Power conservation apparatus having multiple power reduction levels dependent upon the activity of the computer system
US5359540A (en) * 1990-07-23 1994-10-25 Hugo Ortiz Computer assisted electric power management
DE4038801A1 (de) 1990-12-05 1992-06-11 Bosch Siemens Hausgeraete Microcomputer-steuerung fuer elektrische haushaltsgeraete o. dgl.
US5317568A (en) * 1991-04-11 1994-05-31 Galileo International Partnership Method and apparatus for managing and facilitating communications in a distributed hetergeneous network
US5295260A (en) * 1991-05-31 1994-03-15 Cray Research Systems, Inc. Memory range monitoring apparatus for a multiprocessor computer system
US5265254A (en) * 1991-08-14 1993-11-23 Hewlett-Packard Company System of debugging software through use of code markers inserted into spaces in the source code during and after compilation
US5450586A (en) * 1991-08-14 1995-09-12 Hewlett-Packard Company System for analyzing and debugging embedded software through dynamic and interactive use of code markers
FR2680592B1 (fr) * 1991-08-23 1994-02-25 Toshiba Kk Systeme de commande a distance.
US7133834B1 (en) * 1992-08-06 2006-11-07 Ferrara Ethereal Llc Product value information interchange server
US5999908A (en) * 1992-08-06 1999-12-07 Abelow; Daniel H. Customer-based product design module
US5890122A (en) * 1993-02-08 1999-03-30 Microsoft Corporation Voice-controlled computer simulateously displaying application menu and list of available commands
US5321229A (en) * 1993-04-05 1994-06-14 Whirlpool Corporation Remote control for a domestic appliance
JP3160825B2 (ja) 1993-04-30 2001-04-25 三菱電機ホーム機器株式会社 加熱調理器
GB9320052D0 (en) * 1993-09-29 1993-11-17 Philips Electronics Uk Ltd Testing and monitoring of programmed devices
IL111154A0 (en) * 1993-10-21 1994-12-29 Martino Ii John A Systems and methods for electronic messaging
US5640542A (en) * 1993-10-29 1997-06-17 Intel Corporation On-chip in-circuit-emulator memory mapping and breakpoint register modules
NO941202L (no) * 1994-03-30 1995-10-02 Oeystein Konsmo Fremgangsmåte til overvåking og generering av meldinger samt utstyr hvor fremgangsmåten anvendes
GB9406477D0 (en) * 1994-03-31 1994-05-25 D2B Systems Co Ltd Interconnection of local communication bus systems
US6151567A (en) * 1994-05-27 2000-11-21 Hamilton Sundstrand Corporation Data communication analysis and simulation tool
KR0129962B1 (ko) * 1994-07-26 1998-04-09 김광호 전자 레인지의 모의 작동방법 및 장치
DE4435931C2 (de) * 1994-10-07 1998-06-04 Convotherm Elektrogeraete Bedienungseinrichtung für ein Gargerät
US5520576A (en) * 1994-11-09 1996-05-28 Pisces Industries, Ltd. Fish filleting machine
US6024867A (en) * 1994-12-28 2000-02-15 Water Safety Corp. Of America Counter top water filter with replaceable electronic display monitor
US5745717A (en) * 1995-06-07 1998-04-28 Vayda; Mark Graphical menu providing simultaneous multiple command selection
US5964893A (en) * 1995-08-30 1999-10-12 Motorola, Inc. Data processing system for performing a trace function and method therefor
US5737516A (en) * 1995-08-30 1998-04-07 Motorola, Inc. Data processing system for performing a debug function and method therefor
JP3846939B2 (ja) * 1995-08-30 2006-11-15 フリースケール セミコンダクター インコーポレイテッド データプロセッサ
US5544311A (en) * 1995-09-11 1996-08-06 Rockwell International Corporation On-chip debug port
US5815297A (en) * 1995-10-25 1998-09-29 General Instrument Corporation Of Delaware Infrared interface and control apparatus for consumer electronics
US6289396B1 (en) * 1995-11-21 2001-09-11 Diamond Multimedia Systems, Inc. Dynamic programmable mode switching device driver architecture
DE19548776A1 (de) * 1995-12-23 1997-06-26 Thomson Brandt Gmbh Verfahren zur Fernbedienung von elektronischen Geräten und Vorrichtung zur Fernbedienung von elektronischen Geräten sowie elektronisches Gerät
EP0827616B1 (en) * 1996-02-08 2002-04-24 Koninklijke Philips Electronics N.V. Initialisation of a wireless security system
DE19615840A1 (de) * 1996-04-20 1997-10-30 Bosch Gmbh Robert Elektrisches Hausgerät
US5875430A (en) * 1996-05-02 1999-02-23 Technology Licensing Corporation Smart commercial kitchen network
US6424991B1 (en) * 1996-07-01 2002-07-23 Sun Microsystems, Inc. Object-oriented system, method and article of manufacture for a client-server communication framework
US6044305A (en) * 1996-10-04 2000-03-28 Fisher Controls International, Inc. Method and apparatus for debugging and tuning a process control network having distributed control functions
US6021429A (en) * 1996-11-18 2000-02-01 Canon Information Systems, Inc. Network device which maintains a list of device addresses
US6009355A (en) * 1997-01-28 1999-12-28 American Calcar Inc. Multimedia information and control system for automobiles
US6243772B1 (en) * 1997-01-31 2001-06-05 Sharewave, Inc. Method and system for coupling a personal computer with an appliance unit via a wireless communication link to provide an output display presentation
WO1998040307A2 (en) * 1997-03-10 1998-09-17 Innovative Medical Services Method and apparatus for dispensing fluids
US6186140B1 (en) * 1997-03-14 2001-02-13 3M Innovative Properties Company Respiratory filter element having a storage device for keeping track of filter usage and a system for use therewith
US6189140B1 (en) * 1997-04-08 2001-02-13 Advanced Micro Devices, Inc. Debug interface including logic generating handshake signals between a processor, an input/output port, and a trace logic
US6094729A (en) * 1997-04-08 2000-07-25 Advanced Micro Devices, Inc. Debug interface including a compact trace record storage
US6154856A (en) * 1997-04-08 2000-11-28 Advanced Micro Devices, Inc. Debug interface including state machines for timing synchronization and communication
US6003065A (en) * 1997-04-24 1999-12-14 Sun Microsystems, Inc. Method and system for distributed processing of applications on host and peripheral devices
US6269412B1 (en) * 1997-05-13 2001-07-31 Micron Technology, Inc. Apparatus for recording information system events
US5888381A (en) * 1997-05-16 1999-03-30 United States Filter Corporation Water filter with pressure actuated flow monitor
AU734528B2 (en) 1997-06-19 2001-06-14 Matsushita Electric Industrial Co., Ltd. Cooking Appliance
EP1257094B8 (en) 1997-06-25 2007-08-08 Samsung Electronics Co., Ltd. Browser based command and control network
DE19746423C2 (de) 1997-10-21 1999-08-19 Bosch Siemens Hausgeraete Elektrisches Haushaltsgerät mit Demonstrations-Mode
US6121898A (en) * 1997-10-28 2000-09-19 Moetteli; John B. Traffic law enforcement system
US6175914B1 (en) * 1997-12-17 2001-01-16 Advanced Micro Devices, Inc. Processor including a combined parallel debug and trace port and a serial port
US6052750A (en) * 1998-01-06 2000-04-18 Sony Corporation Of Japan Home audio/video network for generating default control parameters for devices coupled to the network, and replacing updated control parameters therewith
US6160796A (en) * 1998-01-06 2000-12-12 Sony Corporation Of Japan Method and system for updating device identification and status information after a local bus reset within a home audio/video network
US6704804B1 (en) * 1998-01-26 2004-03-09 International Business Machines Corporation Method and system for communicating information among interactive applications
US6469714B2 (en) * 1998-01-26 2002-10-22 International Business Machines Corporation Infocenter user interface for applets and components
US6266716B1 (en) * 1998-01-26 2001-07-24 International Business Machines Corporation Method and system for controlling data acquisition over an information bus
US6704803B2 (en) * 1998-01-26 2004-03-09 International Business Machines Corporation Method and system for distributing data events over an information bus
US6105122A (en) * 1998-02-06 2000-08-15 Ncr Corporation I/O protocol for highly configurable multi-node processing system
US6148349A (en) * 1998-02-06 2000-11-14 Ncr Corporation Dynamic and consistent naming of fabric attached storage by a file system on a compute node storing information mapping API system I/O calls for data objects with a globally unique identification
US6490726B2 (en) * 1998-03-23 2002-12-03 Icebox, Llc Appliances with the internet access
DE69919619T2 (de) * 1998-03-30 2005-09-08 Sharp K.K. Kochgerät
JP3684832B2 (ja) * 1998-03-31 2005-08-17 セイコーエプソン株式会社 マイクロコンピュータ、電子機器及びデバッグシステム
JP3545256B2 (ja) * 1998-04-17 2004-07-21 松下電器産業株式会社 送信装置及び受信装置
US6426947B1 (en) * 1998-10-21 2002-07-30 Kim K. Banker Apparatus and method for unilateral topology discovery in network management
US6295272B1 (en) * 1998-04-20 2001-09-25 Gadzoox Networks, Inc. Subchannel modulation scheme for carrying management and control data outside the regular data channel
US6847614B2 (en) * 1998-04-20 2005-01-25 Broadcom Corporation Apparatus and method for unilateral topology discovery in network management
US6321331B1 (en) * 1998-04-22 2001-11-20 Transwitch Corporation Real time debugger interface for embedded systems
US6134676A (en) * 1998-04-30 2000-10-17 International Business Machines Corporation Programmable hardware event monitoring method
ATE300834T1 (de) * 1998-05-07 2005-08-15 Samsung Electronics Co Ltd Verfahren und vorrichtung für universellen zugriffsbefehl und kontrollinformation in einem netzwerk
SE9801678L (sv) * 1998-05-13 1999-11-14 Axis Ab Datorchip och datoranordning med förbättrad avlusningsförmåga
US6285966B1 (en) * 1998-06-25 2001-09-04 Fisher Controls International, Inc. Function block apparatus for viewing data in a process control system
US7586398B2 (en) * 1998-07-23 2009-09-08 Universal Electronics, Inc. System and method for setting up a universal remote control
US6233619B1 (en) 1998-07-31 2001-05-15 Unisys Corporation Virtual transport layer interface and messaging subsystem for high-speed communications between heterogeneous computer systems
US6711632B1 (en) * 1998-08-11 2004-03-23 Ncr Corporation Method and apparatus for write-back caching with minimal interrupts
US6121593A (en) 1998-08-19 2000-09-19 Duck Creek Energy, Inc. Home appliances provided with control systems which may be actuated from a remote location
US6359270B1 (en) * 1998-09-04 2002-03-19 Ncr Corporation Communications module mounting for domestic appliance
EP0992904B1 (en) 1998-10-06 2010-06-09 Texas Instruments Inc. Cache coherence during emulation
WO2000022884A1 (en) * 1998-10-09 2000-04-20 Microwave Science, Llc Interpretive language architecture for controlling the attributes of a physical, chemical, or thermodynamic process
JP4142175B2 (ja) * 1998-10-20 2008-08-27 松下電器産業株式会社 グラフィカルユーザインタフェース装置
BR0004006A (pt) * 1999-01-06 2002-01-29 Robert G Harrison Aplicações com modos de operação múltiplos
US6901439B1 (en) * 1999-01-22 2005-05-31 Leviton Manufacturing Co., Inc. Method of adding a device to a network
US7111242B1 (en) * 1999-01-27 2006-09-19 Gateway Inc. Method and apparatus for automatically generating a device user interface
US6559882B1 (en) * 1999-09-02 2003-05-06 Ncr Corporation Domestic appliance
EP1090344B1 (en) * 1999-03-05 2003-12-17 Amulet Technologies, LLC Graphical user interface engine for embedded systems
US6957438B1 (en) * 1999-03-26 2005-10-18 Nortel Networks Limited Network device application programming interface
US6665681B1 (en) * 1999-04-09 2003-12-16 Entrieva, Inc. System and method for generating a taxonomy from a plurality of documents
US6505254B1 (en) * 1999-04-19 2003-01-07 Cisco Technology, Inc. Methods and apparatus for routing requests in a network
JP2006313561A (ja) 1999-04-30 2006-11-16 Renesas Technology Corp データ処理装置
US6567032B1 (en) * 1999-06-30 2003-05-20 International Business Machines Corp. Method of directing communication between addressable targets using a generalized pointing device
US6801507B1 (en) * 1999-07-27 2004-10-05 Samsung Electronics Co., Ltd. Device discovery and configuration in a home network
US6668339B1 (en) * 1999-07-28 2003-12-23 Mitsubishi Denki Kabushiki Kaisha Microprocessor having a debug interruption function
EP1279095A2 (en) * 1999-08-16 2003-01-29 Z-Force Corporation System of reusable software parts and methods of use
US6683065B1 (en) * 1999-08-19 2004-01-27 Host Pharmaceuticals Llc Method of treating body insect infestation
US6337469B1 (en) * 1999-09-10 2002-01-08 Samsung Electronics Co., Ltd. Cooker
US6486453B1 (en) * 1999-09-13 2002-11-26 Maytag Corporation Menu driven control system for a cooking appliance
DE19950433A1 (de) 1999-10-19 2001-04-26 Philips Corp Intellectual Pty Netzwerk mit mehreren Netzknoten zur Medienzugangsprüfung
US7172121B2 (en) * 2000-11-03 2007-02-06 Claricom Limited System and method for applying codes onto packaged products
US6539501B1 (en) * 1999-12-16 2003-03-25 International Business Machines Corporation Method, system, and program for logging statements to monitor execution of a program
US20010032777A1 (en) * 1999-12-30 2001-10-25 Finch Marshall A. Air-gap slide switch
US7526539B1 (en) * 2000-01-04 2009-04-28 Pni Corporation Method and apparatus for a distributed home-automation-control (HAC) window
US6934862B2 (en) 2000-01-07 2005-08-23 Robertshaw Controls Company Appliance retrofit monitoring device with a memory storing an electronic signature
US6453687B2 (en) * 2000-01-07 2002-09-24 Robertshaw Controls Company Refrigeration monitor unit
US7187924B2 (en) * 2000-02-08 2007-03-06 Fitsense Technology, Inc. Intelligent data network with power management capabilities
US20020158910A1 (en) * 2000-02-17 2002-10-31 Sharrow John Anthony Adaptive menu appliance control with user interface options
EP1133188A3 (en) * 2000-02-23 2004-11-24 Sony Corporation Information processing apparatus, network system, recording medium
DE60139172D1 (de) * 2000-03-29 2009-08-20 Lg Electronics Inc System zum ferngemeldeten gesteuerten Wäsche und Verfahren dafür
US20050091576A1 (en) 2003-10-24 2005-04-28 Microsoft Corporation Programming interface for a computer platform
US6681248B1 (en) * 2000-04-12 2004-01-20 Sycamore Networks, Inc. Method for port connectivity discovery in transparent high bandwidth networks
CA2306974A1 (en) * 2000-04-28 2001-10-28 Ibm Canada Limited-Ibm Canada Limitee Management of application programming interface interoperability
US6922685B2 (en) * 2000-05-22 2005-07-26 Mci, Inc. Method and system for managing partitioned data resources
US20030005407A1 (en) 2000-06-23 2003-01-02 Hines Kenneth J. System and method for coordination-centric design of software systems
JP2002027576A (ja) * 2000-07-05 2002-01-25 Toshiba Corp リモートコントローラ及び携帯電話及び電子機器及びその制御方法
KR100342569B1 (ko) 2000-07-13 2002-07-02 윤종용 상호 대화형 세탁기 관리 장치
US20030023435A1 (en) * 2000-07-13 2003-01-30 Josephson Daryl Craig Interfacing apparatus and methods
US7234062B2 (en) * 2000-07-18 2007-06-19 General Electric Company Authentication of remote appliance messages using an embedded cryptographic device
JP3850643B2 (ja) 2000-08-02 2006-11-29 株式会社日立製作所 表示装置を備えた家庭用電気機器
JP2002074086A (ja) 2000-08-29 2002-03-12 Tiger Vacuum Bottle Co Ltd インターネットを用いた家電機器の模擬実演販売方法
ATE380267T1 (de) * 2000-09-04 2007-12-15 Lg Electronics Inc Waschmachine und verfahren zum ändern der systemdaten in dieser maschine
JP2002085885A (ja) 2000-09-11 2002-03-26 Toshiba Corp ランドリーシステム
TW593950B (en) * 2000-09-11 2004-06-21 Toshiba Corp Remote inspection system for refrigerator
US7272643B1 (en) * 2000-09-13 2007-09-18 Fortinet, Inc. System and method for managing and provisioning virtual routers
US6965615B1 (en) * 2000-09-18 2005-11-15 Cisco Technology, Inc. Packet striping across a parallel header processor
US6587739B1 (en) * 2000-09-29 2003-07-01 Sunbeam Products, Inc. Appliance communication and control system and appliances for use in same
WO2002046916A2 (en) * 2000-10-20 2002-06-13 Polexis, Inc. Extensible information system (xis)
US6690979B1 (en) * 2000-10-31 2004-02-10 Maytag Corporation Intelligent appliance network
US7305465B2 (en) * 2000-11-15 2007-12-04 Robert Wing Collecting appliance problem information over network and providing remote technical support to deliver appliance fix information to an end user
DE60021092T2 (de) 2000-11-21 2006-05-18 Siemens Mobile Communications S.P.A. Vorrichtung und Verfahren zur Echtzeitfehlerbeseitigung von Quellprogrammen, insbesondere für DSP
KR100359827B1 (ko) * 2000-11-27 2002-11-07 엘지전자 주식회사 홈 어플라이언스 네트워크 장치 및 방법
US7171475B2 (en) * 2000-12-01 2007-01-30 Microsoft Corporation Peer networking host framework and hosting API
US6742136B2 (en) * 2000-12-05 2004-05-25 Fisher-Rosemount Systems Inc. Redundant devices in a process control system
EP1217475B1 (en) * 2000-12-13 2005-10-26 Lg Electronics Inc. Apparatus and method for remotely controlling household appliances
US6502265B2 (en) * 2000-12-21 2003-01-07 Maytag Corporation Interactive control system for a laundry appliance
KR100439238B1 (ko) 2000-12-23 2004-07-05 엘지전자 주식회사 전송유니트간 송수신 데이터의 릴라이어블 프로토콜운용방법
US7165107B2 (en) * 2001-01-22 2007-01-16 Sun Microsystems, Inc. System and method for dynamic, transparent migration of services
AU2002234258A1 (en) * 2001-01-22 2002-07-30 Sun Microsystems, Inc. Peer-to-peer network computing platform
US20020107716A1 (en) * 2001-02-07 2002-08-08 Kevin Callahan Methods and apparatus for scheduling an in-home appliance repair service
JP2002259657A (ja) * 2001-02-28 2002-09-13 Square Co Ltd 電化製品、ネットワークシステム、ネットワークを用いた電化製品の制御方法およびその方法を達成するプログラム列ならびにコンピュータ可読記憶媒体
JP4149178B2 (ja) * 2001-03-09 2008-09-10 松下電器産業株式会社 リモートメンテナンスシステム
US7219157B2 (en) 2001-03-23 2007-05-15 Lucent Technologies Inc. Application programming interface for network applications
US6948098B2 (en) * 2001-03-30 2005-09-20 Cirrus Logic, Inc. Circuits and methods for debugging an embedded processor and systems using the same
US6577231B2 (en) * 2001-04-03 2003-06-10 Thomson Licensing Sa Clock synchronization over a powerline modem network for multiple devices
KR20020078335A (ko) * 2001-04-09 2002-10-18 삼성전자 주식회사 인터넷 전자레인지 메모리 팩의 데이터 처리방법
DE10117905B4 (de) * 2001-04-10 2014-09-11 BSH Bosch und Siemens Hausgeräte GmbH Haushaltgerät mit einer Anzeigevorrichtung
KR100393580B1 (ko) 2001-05-02 2003-08-02 엘지전자 주식회사 가전기기 네트워크 시스템 및 관리정보전송방법
US7111247B2 (en) * 2001-07-02 2006-09-19 Lg Electronics Inc. Device and method for controlling menu display of microwave oven
CA2453606C (en) * 2001-07-16 2007-01-09 Maytag Corporation Electronic message center for a refrigerator
KR100424297B1 (ko) 2001-07-20 2004-03-24 엘지전자 주식회사 가전기기 제어시스템 및 그 동작방법
US6934592B2 (en) 2001-08-02 2005-08-23 Maytag Corporation Household appliance with advertising display mode
US6813526B1 (en) * 2001-08-13 2004-11-02 William A. Dodd, Jr. Fleet maintenance method
US7039953B2 (en) * 2001-08-30 2006-05-02 International Business Machines Corporation Hierarchical correlation of intrusion detection events
WO2003031876A1 (en) 2001-10-05 2003-04-17 Access Business Group International Llc Interactive cooking appliance
US6622925B2 (en) * 2001-10-05 2003-09-23 Enernet Corporation Apparatus and method for wireless control
KR20030031202A (ko) * 2001-10-12 2003-04-21 주식회사 엘지이아이 컴퓨터를 통한 사용자 인터페이스 방법
WO2003034225A2 (en) 2001-10-12 2003-04-24 Pts Corporation Debugging of processors
US7343407B2 (en) 2001-10-15 2008-03-11 Ricoh Company, Ltd. Method and system of remote monitoring and support of devices, including handling Email messages having message types specified within the Email message
US7200144B2 (en) * 2001-10-18 2007-04-03 Qlogic, Corp. Router and methods using network addresses for virtualization
KR20030035228A (ko) 2001-10-30 2003-05-09 삼성전기주식회사 유무선 통합형 랜카드
US7426572B1 (en) * 2001-10-31 2008-09-16 Juniper Networks, Inc. Network router using embedded and external memory based on packet destination
US20030083770A1 (en) 2001-11-01 2003-05-01 Williamson Charles G. Intelligent breadmaker appliance
US7127633B1 (en) * 2001-11-15 2006-10-24 Xiotech Corporation System and method to failover storage area network targets from one interface to another
US7003688B1 (en) * 2001-11-15 2006-02-21 Xiotech Corporation System and method for a reserved memory area shared by all redundant storage controllers
US7069468B1 (en) * 2001-11-15 2006-06-27 Xiotech Corporation System and method for re-allocating storage area network resources
US6996741B1 (en) * 2001-11-15 2006-02-07 Xiotech Corporation System and method for redundant communication between redundant controllers
US7043663B1 (en) * 2001-11-15 2006-05-09 Xiotech Corporation System and method to monitor and isolate faults in a storage area network
US6883065B1 (en) 2001-11-15 2005-04-19 Xiotech Corporation System and method for a redundant communication channel via storage area network back-end
US6750433B2 (en) * 2001-11-29 2004-06-15 General Electric Company Oven display and user interface
JP2003172578A (ja) * 2001-12-07 2003-06-20 Hitachi Ltd ネットワーク対応家電機器、家電機器点検システム及び家電機器点検サービス
US7069562B2 (en) * 2001-12-12 2006-06-27 Sun Microsystems, Inc. Application programming interface for connecting a platform independent plug-in to a web browser
US6919815B2 (en) * 2002-01-24 2005-07-19 Emerson Electric Co. Appliance control communication methods and apparatus
US20030212654A1 (en) * 2002-01-25 2003-11-13 Harper Jonathan E. Data integration system and method for presenting 360° customer views
US7043718B1 (en) * 2002-02-15 2006-05-09 Lsi Logic Corporation System real-time analysis tool
CN1447239A (zh) * 2002-02-18 2003-10-08 松下电器产业株式会社 轮廓信息取得程序及轮廓信息取得装置
US7516447B2 (en) * 2002-02-22 2009-04-07 Bea Systems, Inc. Methods and apparatus for building, customizing and using software abstractions of external entities
DE10208147A1 (de) 2002-02-26 2003-09-04 Bsh Bosch Siemens Hausgeraete Gebäude-Gateway-Rechneranordnung und Steuerungssystem
KR100420526B1 (ko) 2002-03-15 2004-03-02 엘지전자 주식회사 가전기기 네트워크 시스템 및 그 제어방법
KR100437042B1 (ko) * 2002-03-20 2004-06-23 엘지전자 주식회사 가전기기 네트워크 시스템 및 그 제어방법
US7246144B2 (en) * 2002-03-25 2007-07-17 Data Quality Solutions Method and system for managing a plurality of enterprise business systems
US7428597B2 (en) * 2002-03-28 2008-09-23 Sap Ag Content-based routing system and method
EP1351447A1 (en) * 2002-04-05 2003-10-08 Sony International (Europe) GmbH Management and control of networked audio-video devices
US7149983B1 (en) * 2002-05-08 2006-12-12 Microsoft Corporation User interface and method to facilitate hierarchical specification of queries using an information taxonomy
US7177311B1 (en) * 2002-06-04 2007-02-13 Fortinet, Inc. System and method for routing traffic through a virtual router-based network switch
US7177859B2 (en) * 2002-06-26 2007-02-13 Microsoft Corporation Programming model for subscription services
JP2004040285A (ja) * 2002-07-01 2004-02-05 Matsushita Electric Ind Co Ltd 家庭電化製品の制御装置、制御方法、制御プログラムおよび家庭電化製品
DE10230476A1 (de) * 2002-07-06 2004-01-29 Schott Glas Einrichtung zur Fernabfrage und/oder Fernbeeinflussung von Betriebszuständen eines Gerätes, insbesondere eines elektrischen Haushaltsgerätes
US6907039B2 (en) 2002-07-20 2005-06-14 Redback Networks Inc. Method and apparatus for routing and forwarding between virtual routers within a single network element
US7487509B2 (en) * 2002-08-08 2009-02-03 Sun Microsystems, Inc. System and method for providing multiple embodiments of abstract software modules in peer-to-peer network environments
IL151251A0 (en) 2002-08-14 2003-04-10 Elta Systems Ltd Parallel processing platform with synchronous system halt-resume
US20040098504A1 (en) * 2002-08-27 2004-05-20 Matsushita Electric Industrial Co., Ltd. Routing processing and method in home bus system
US7096383B2 (en) * 2002-08-29 2006-08-22 Cosine Communications, Inc. System and method for virtual router failover in a network routing system
US7263560B2 (en) * 2002-08-30 2007-08-28 Sun Microsystems, Inc. Decentralized peer-to-peer advertisement
JP2004096591A (ja) * 2002-09-03 2004-03-25 Hitachi Ltd 家電機器遠隔制御システム及び家電機器のコントローラ
US7213208B2 (en) * 2002-09-12 2007-05-01 Sap Ag Data container for interaction between a client process and software applications
US6873255B2 (en) * 2002-09-14 2005-03-29 Andrew C. Gallagher Appliance communication system
KR20040025315A (ko) * 2002-09-19 2004-03-24 삼성전자주식회사 무선랜카드 및 그 제어방법
KR20040026816A (ko) * 2002-09-26 2004-04-01 삼성전자주식회사 전자렌지
CN1176536C (zh) 2002-09-29 2004-11-17 联想(北京)有限公司 家庭网络中的家电控制系统和方法
US7904527B2 (en) * 2002-09-30 2011-03-08 Sony Ericsson Mobile Communications Ab System and method for remote servicing of embedded devices
US6993615B2 (en) * 2002-11-15 2006-01-31 Microsoft Corporation Portable computing device-integrated appliance
US7733783B2 (en) * 2002-12-03 2010-06-08 Cedar Point Communications, Inc. Ethernet network availability
US7152180B2 (en) 2002-12-06 2006-12-19 Ntt Docomo, Inc. Configurable reliable messaging system
US20040163126A1 (en) * 2003-01-31 2004-08-19 Qwest Communications International Inc. Methods and apparatus for delivering a computer data stream to a video appliance with a network interface device
US7090141B2 (en) * 2003-03-10 2006-08-15 Lg Electronics Inc. Networking system of refrigerator and method for operating the same
CA2424006A1 (en) * 2003-03-28 2004-09-28 Ibm Canada Limited - Ibm Canada Limitee A technique to generically manage extensible correlation data
US20040260407A1 (en) * 2003-04-08 2004-12-23 William Wimsatt Home automation control architecture
US6933477B2 (en) * 2003-04-10 2005-08-23 Maytag Corporation Menu driven control system for a cooking appliance
US20040219951A1 (en) * 2003-04-29 2004-11-04 Holder Helen A Program controlled apparatus, system and method for remote data messaging and display over an interactive wireless communications network
US7275251B2 (en) * 2003-05-07 2007-09-25 Cisco Technology, Inc. Selective process restart based on API changes
JP2004333079A (ja) 2003-05-12 2004-11-25 Toshiba Corp 家庭電化機器
WO2004102438A2 (en) * 2003-05-16 2004-11-25 Sap Aktiengesellschaft Business process management for a message-based exchange infrastructure
US6988375B2 (en) 2003-06-09 2006-01-24 Whirlpool Corporation System and method for remote appliance monitoring
JP2005026740A (ja) 2003-06-30 2005-01-27 Matsushita Electric Ind Co Ltd 機器制御インタフェース構築方法
US7289988B2 (en) * 2003-07-08 2007-10-30 Hewlett-Packard Development Company, L.P. Method and system for managing events
KR100575311B1 (ko) * 2003-07-16 2006-05-02 엘지전자 주식회사 인터넷 전자레인지 및 그 통신 방법
US20080077780A1 (en) 2003-07-25 2008-03-27 Zingher Arthur R System and Method for Software Debugging
JP2005056207A (ja) * 2003-08-05 2005-03-03 Sanyo Electric Co Ltd ネットワークシステム、宅内機器制御サーバおよび仲介サーバ
DE10340627A1 (de) * 2003-09-03 2005-04-07 Infineon Technologies Ag Steuerbare Hausgeräte-Anordnung und/oder steuerbare Industriegeräte-Anordnung und Steuersystem zum Steuern einer Hausgeräte-Anordnung und/oder Industriegeräte-Anordnung
KR20050034412A (ko) 2003-10-09 2005-04-14 엘지전자 주식회사 가전기기 네트워크 시스템
US7136709B2 (en) * 2003-11-04 2006-11-14 Universal Electronics Inc. Home appliance control system and methods in a networked environment
KR20060133972A (ko) * 2003-11-05 2006-12-27 코닌클리케 필립스 일렉트로닉스 엔.브이. 매체 제공 엔티티에서 제어 포인트에 대한 상이한 허가들
US20050103466A1 (en) * 2003-11-19 2005-05-19 Landry Kenneth D. Refrigerator-oven
FR2863425B1 (fr) * 2003-12-04 2006-02-10 Gemplus Card Int Procede et systeme de configuration automatique d'appareil dans un reseau de communication
US7328045B2 (en) * 2003-12-24 2008-02-05 Robert Bosch Gmbh Secure and intuitive method for wireless network set-up and associated device and system
KR101054185B1 (ko) 2003-12-26 2011-08-03 엘지전자 주식회사 원격 제어 시스템
KR20050068297A (ko) 2003-12-30 2005-07-05 엘지전자 주식회사 원격제어시스템 및 그 제어방법
US7188002B2 (en) * 2004-01-08 2007-03-06 Maple Chase Company Appliance diagnostic display apparatus and network incorporating same
CN1914368A (zh) * 2004-01-29 2007-02-14 松下电器产业株式会社 信息家电系统
US20050172282A1 (en) * 2004-01-30 2005-08-04 Michael Shenfield System and method for publishing and accessing application APIs on a generic terminal
US20050193201A1 (en) * 2004-02-26 2005-09-01 Mahfuzur Rahman Accessing and controlling an electronic device using session initiation protocol
US7117051B2 (en) * 2004-03-15 2006-10-03 Tmio, Llc Appliance communication system and method
US20050212663A1 (en) * 2004-03-23 2005-09-29 Michihiro Matsumoto Equipment installation-place setting system, equipment control apparatus, electrical equipment, equipment installation-place setting method and computer-readable record medium storing equipment installation-place setting program
EP1735672A1 (en) * 2004-04-01 2006-12-27 Delphi Technologies, Inc. Method and protocol for diagnostics of arbitrarily complex networks of devices
EP1589698A1 (en) * 2004-04-19 2005-10-26 Lg Electronics Inc. Home network system and method for operating the same
US7680691B2 (en) * 2004-04-29 2010-03-16 S.C. Johnson & Son, Inc. Inventory management system using RFID
US20060010019A1 (en) * 2004-05-26 2006-01-12 Phillips Scott H Method and system for providing customer service for a household appliance
US20060015299A1 (en) * 2004-06-14 2006-01-19 Mcdermott Scott A Network architecture and protocol for spacecraft systems
WO2006014504A2 (en) 2004-07-07 2006-02-09 Sciencelogic, Llc Self configuring network management system
US20060031155A1 (en) * 2004-08-09 2006-02-09 Tetsuro Motoyama System and method to process an alert from a monitored device based on business context information
US20060036970A1 (en) * 2004-08-16 2006-02-16 Charles Rich System for configuring and controlling home appliances
JP4634456B2 (ja) 2004-09-09 2011-02-16 アバイア インコーポレーテッド ネットワーク・トラフィックのセキュリティのための方法およびシステム
US7183919B2 (en) * 2004-11-05 2007-02-27 Shih-Ho Wang RFID delivery and pickup determination system
US7305278B2 (en) * 2004-11-15 2007-12-04 International Business Machines Corporation Enterprise factory control method and system
US7461154B2 (en) * 2004-11-18 2008-12-02 Cisco Technology, Inc. Communication arrangement between virtual routers of a physical router
US7463592B2 (en) * 2004-12-03 2008-12-09 Microsoft Corporation Protocol for exchanging control data to mitigate interference problems in wireless networking
US20060123807A1 (en) 2004-12-14 2006-06-15 Sullivan C B Apparatus and method for monitoring and displaying power usage
US20060168269A1 (en) * 2004-12-30 2006-07-27 Microsoft Corporation Bus abstraction
KR100678951B1 (ko) * 2005-01-11 2007-02-06 삼성전자주식회사 제어 장치의 해상도에 따라 홈 네트워크 기기에 대한 제품제어 코드를 생성하는 장치 및 방법
JP4733399B2 (ja) 2005-01-28 2011-07-27 株式会社日立製作所 計算機システム、計算機、ストレージ装置及び管理端末
US8347088B2 (en) * 2005-02-01 2013-01-01 Newsilike Media Group, Inc Security systems and methods for use with structured and unstructured data
US20060184892A1 (en) * 2005-02-17 2006-08-17 Morris Robert P Method and system providing for the compact navigation of a tree structure
US8183995B2 (en) 2005-03-08 2012-05-22 Jackson Kit Wang Systems and methods for modifying power usage
US7995569B2 (en) * 2005-04-01 2011-08-09 Nortel Networks Limited Virtual routers for GMPLS networks
US7236099B2 (en) * 2005-04-01 2007-06-26 Maytag Corporation Household appliance with user interface with bi-colored LEDs
US20060270452A1 (en) * 2005-05-27 2006-11-30 Levy Gerzberg Remote storage of pictures and other data through a mobile telephone network
BRPI0622274A2 (pt) * 2005-06-09 2011-08-09 Whirlpool Co aparelho configurado para executar um ciclo de operação para completar uma operação fìsica em um artigo e rede de aparelho
US8442042B2 (en) * 2005-06-09 2013-05-14 Whirlpool Corporation Appliance and a consumable holder with an embedded virtual router
US20070288331A1 (en) * 2006-06-08 2007-12-13 Whirlpool Corporation Product demonstration system and method
US8155120B2 (en) * 2005-06-09 2012-04-10 Whirlpool Corporation Software architecture system and method for discovering components within an appliance using fuctionality identifiers
US9164867B2 (en) * 2005-06-09 2015-10-20 Whirlpool Corporation Network for communicating information related to a consumable to an appliance
US20070162158A1 (en) * 2005-06-09 2007-07-12 Whirlpool Corporation Software architecture system and method for operating an appliance utilizing configurable notification messages
US8005780B2 (en) * 2005-06-09 2011-08-23 Whirlpool Corporation Taxonomy engine and dataset for operating an appliance
US7917914B2 (en) * 2005-06-09 2011-03-29 Whirlpool Corporation Event notification system for an appliance
US20060293788A1 (en) * 2005-06-26 2006-12-28 Pavel Pogodin Robotic floor care appliance with improved remote management
US7739078B2 (en) * 2005-12-01 2010-06-15 Sandisk Corporation System for managing appliances
US7353073B2 (en) * 2005-12-01 2008-04-01 Sandisk Corporation Method for managing appliances
US7894451B2 (en) * 2005-12-30 2011-02-22 Extreme Networks, Inc. Method of providing virtual router functionality
JP2007258817A (ja) 2006-03-20 2007-10-04 Fujitsu Ltd パケット伝送装置
US8682733B2 (en) * 2006-06-08 2014-03-25 Whirlpool Corporation System for product demonstration
US8461959B2 (en) * 2008-10-23 2013-06-11 Whirlpool Corporation Consumable holder with process control apparatus

Also Published As

Publication number Publication date
US20080122648A1 (en) 2008-05-29
US8028302B2 (en) 2011-09-27
BRPI0622273A2 (pt) 2011-08-09
US8849430B2 (en) 2014-09-30
US20080287121A1 (en) 2008-11-20
US20080104212A1 (en) 2008-05-01
US20100287059A1 (en) 2010-11-11
MX2007015681A (es) 2008-02-21
EP2228969A1 (en) 2010-09-15
CN101228741A (zh) 2008-07-23
US20090100153A1 (en) 2009-04-16
BRPI0622274A2 (pt) 2011-08-09
US20090132070A1 (en) 2009-05-21
CA2651012A1 (en) 2006-12-21
US9264252B2 (en) 2016-02-16
US7808368B2 (en) 2010-10-05
EP1889160A2 (en) 2008-02-20
US20080108388A1 (en) 2008-05-08
BRPI0611640A2 (pt) 2009-01-13
CA2611527A1 (en) 2006-12-21
MX2008015676A (es) 2009-02-12
WO2006135758A1 (en) 2006-12-21
US20080105134A1 (en) 2008-05-08
WO2006135726A2 (en) 2006-12-21
CA2611014A1 (en) 2006-12-21
US8786412B2 (en) 2014-07-22
BRPI0621758A2 (pt) 2011-12-20
WO2006135771A3 (en) 2007-11-15
US20080125912A1 (en) 2008-05-29
US20080104208A1 (en) 2008-05-01
EP2228969B1 (en) 2017-04-19
WO2006135771A2 (en) 2006-12-21
EP2244443A1 (en) 2010-10-27
US20090103535A1 (en) 2009-04-23
US8040234B2 (en) 2011-10-18
US20080143490A1 (en) 2008-06-19
EP2247067A1 (en) 2010-11-03
US8345686B2 (en) 2013-01-01
EP1889405A1 (en) 2008-02-20
EP2247067B1 (en) 2016-05-11
US9124444B2 (en) 2015-09-01
WO2006135726A8 (en) 2008-05-02
US7908019B2 (en) 2011-03-15
US20080157936A1 (en) 2008-07-03
US20080140862A1 (en) 2008-06-12
US20080103610A1 (en) 2008-05-01
US8217781B2 (en) 2012-07-10
EP2027544A2 (en) 2009-02-25
US8621049B2 (en) 2013-12-31
US20090100132A1 (en) 2009-04-16
US20080109830A1 (en) 2008-05-08
EP2027544A4 (en) 2010-07-07
CN101305350A (zh) 2008-11-12
US8680983B2 (en) 2014-03-25
US20160134431A1 (en) 2016-05-12

Similar Documents

Publication Publication Date Title
BRPI0611726A2 (pt) aparelho para realizar um ciclo de operação útil em um artigo fìsico
US8155120B2 (en) Software architecture system and method for discovering components within an appliance using fuctionality identifiers
US9401822B2 (en) Software architecture system and method for operating an appliance exposing key press functionality to a network
US7917914B2 (en) Event notification system for an appliance
US7813831B2 (en) Software architecture system and method for operating an appliance in multiple operating modes
US8533253B2 (en) Distributed object-oriented appliance control system
US9009811B2 (en) Network system with electronic credentials and authentication for appliances
US8005780B2 (en) Taxonomy engine and dataset for operating an appliance
US7921429B2 (en) Data acquisition method with event notification for an appliance
US20070162158A1 (en) Software architecture system and method for operating an appliance utilizing configurable notification messages
US20080137670A1 (en) Network System with Message Binding for Appliances
MX2007015625A (en) Software architecture system and method for communication with, and management of, at least one component within a household appliance

Legal Events

Date Code Title Description
B07A Application suspended after technical examination (opinion) [chapter 7.1 patent gazette]
B09B Patent application refused [chapter 9.2 patent gazette]
B09B Patent application refused [chapter 9.2 patent gazette]

Free format text: MANTIDO O INDEFERIMENTO UMA VEZ QUE NAO FOI APRESENTADO RECURSO DENTRO DO PRAZO LEGAL