BRPI0622274A2 - aparelho configurado para executar um ciclo de operação para completar uma operação fìsica em um artigo e rede de aparelho - Google Patents

aparelho configurado para executar um ciclo de operação para completar uma operação fìsica em um artigo e rede de aparelho Download PDF

Info

Publication number
BRPI0622274A2
BRPI0622274A2 BRPI0622274-9A BRPI0622274A BRPI0622274A2 BR PI0622274 A2 BRPI0622274 A2 BR PI0622274A2 BR PI0622274 A BRPI0622274 A BR PI0622274A BR PI0622274 A2 BRPI0622274 A2 BR PI0622274A2
Authority
BR
Brazil
Prior art keywords
api
software
message
software architecture
network
Prior art date
Application number
BRPI0622274-9A
Other languages
English (en)
Inventor
Matthew P Ebrom
Mark E Glotzbach
Patrick J Glotzbach
Richard A Mccoy
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=BRPI0622274(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 BRPI0622274A2 publication Critical patent/BRPI0622274A2/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

Abstract

Patente de Invenção: APARELHO CONFIGURADO PARA EXECUTAR UM CICLO DE OPERAçãO PARA COMPLETAR UMA OPERAçãO FìSICA EM UM ARTIGO E REDE DE APARELHO. A invenção se refere a uma arquitetura de software 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

Relatório Descritivo da Patente de Invenção para "APARELHOCONFIGURADO PARA EXECUTAR UM CICLO DE OPERAÇÃO PARACOMPLETAR UMA OPERAÇÃO FÍSICA EM UM ARTIGO E REDE DEAPARELHO".
Dividido do PI0611726-0, depositado em 08/06/2006.REFERÊNCIA A PEDIDO RELACIONADO
O presente pedido reivindica o benefício de Pedido de Patentedos Estados Unidos No. 60/595.148, depositado em 9 de junho de 2005,cuja exposição é incorporada através de referê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 permitem comuni-cação com, e gerenciamento de, pelo menos um componente dentro de umaparelho eletrodoméstico.
Descrição da Técnica Relacionada
Aparelhos eletrodomésticos são compreendidos, tipicamente, deum ou mais componentes que causam as operações eletromecânicas, ele-trotérmicas e eletroquímicas do aparelho. Por exemplo, um forno pode incluirum componente de gerenciamento de aparelho, tendo um painel de circuitoimpresso (PCB) com memória, bem como um componente de interface deusuário, tal como um painel de controle ou teclado numérico para um usuárioemitir comando para o aparelho de forno. Os modelos básicos de aparelhos,tipicamente, são difíceis de desenhar, desenvolver, testar, diagnosticar, con-trolar e depurar, devido à diversidade de componentes e à diversidade deescolhas de implementação. Essa diversidade é um impedimento à criaçãode componentes inter-operáveis, reutilizáveis, de valor adicionado.
Tem se tornado conhecido, em anos recentes, interligar os com-ponentes 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 e imple-mentados por cinta de fios ou outros conectores ou chicotes entre os com-ponentes. Essa rede interna proporciona um grau de universalidade na co-nexão dos componentes internos ao aparelho, contudo, cada componenteprecisa, tipicamente, ser capacitado com software dentro de seu micropro-cessador e do circuito de hardware adjacente, para obter participação emrede. Um exemplo dessa rede interna usada dentro de um aparelho eletro-doméstico é o protocolo de rede WIDE, criado por Whirlpool, Inc., a cessio-nária deste documento.
SUMÁRIO DA INVENÇÃO
A invenção se refere a uma arquitetura de software que é im-plementada e se comunica através de uma rede de comunicação interna emum aparelho, que conecta os vários componentes físicos do aparelho. A ar-quitetura de software desempenha múltiplas funções: identificar cada um doscomponentes correspondentes a um nó para a rede; identificar as capacida-des ou funções dos componentes identificados para a rede; identificar o es-tado 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 informama todos 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 um aparelhoeletrodoméstico tendo uma rede de comunicação interna, interconectandouma pluralidade de componentes, em que cada componente tem uma arqui-tetura de software nele embutida, de acordo com a invenção, o aparelho ele-trodoméstico tendo, também, uma conexão de comunicação externa mos-trando vários cartões de interface de rede (NICs), estabelecendo comunica-ção com várias modalidades de clientes externos.A figura 2 é uma ilustração esquemática da rede de comunica-ção interna da figura 1, mostrando a arquitetura de software (SA) de acordocom a invenção interposta entre a rede de comunicação interna e várioscomponentes de software internos ao aparelho eletrodoméstico.
A figura 3 é uma ilustração esquemática da rede de comunica-ção interna da figura 1, mostrando a rede de comunicação interna funcio-nando como um suporte físico para a SA residente em dois componentes(uma Camada Inferior, que representa a camada física de rede e não estádiretamente associada com a SA e uma Camada Superior, que representasuporte para estrutura de pacotes e é, diretamente, um elemento da SA),com a SA usada pelos componentes para se comunicar através de troca deinformação e interagir com outras camadas de operação de saída elétrica,residindo nos componentes, para obter os resultados de acordo com a in-formaçã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 eventossão transmitidos entre a SA de controlador e a SA de cliente.
A figura 5A é 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 ilustraruma troca de dados usada para realizar diagnose remota do aparelho.
A figura 6 é uma ilustração esquemática similar àquela mostradana figura 5, ilustrando uma técnica de descoberta contida na arquitetura desoftware da figura 1, de acordo com a invenção.
A figura 7 é uma ilustração esquemática de vários estados e-xemplificativos de um ambiente de alteração de software operando, tipica-mente, dentro do elemento de Lógica de Controle, conforme mostrado nafigura 3 dentro de um componente de um aparelho eletrodoméstico, que está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 de ligaçãopara ligar múltiplas trocas de dados a fim de formar um comando único e/ouatualizaçã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 ambien-te de 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 de comuni-cação interna para interconectar a SA à rede de comunicação interna do a-parelho eletrodoméstico.
A figura 11 é uma ilustração esquemática mostrando a invoca-ção do SA de controlador pelo planejador supervisor (MAIN), residente nocontrolador principal, que também invoca uma chamada de sub-rotina paraexpor funções da SA de cliente na rede.
A figura 12 é uma ilustração esquemática mostrando a interfaceentre a lógica interna de aplicação de aparelho e a arquitetura de softwaremostrada na figura 11, incluindo uma seção de chamada de volta.
A figura 13 é uma ilustração esquemática de implementação deexemplo 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 de ambien-tes operacionais de software, cada um correspondendo a um componentediferente com sua própria SA e conectados pela rede de comunicação inter-na.
A figura 15 é uma ilustração esquemática de um nó de persis-tência exposto aos outros componentes dentro do Aparelho de Parrot viarede 14 e estrutura de pacotes de suporte 28 da arquitetura de software 10da figura 1, de acordo com a invenção.
A figura 16 é uma ilustração esquemática de um método da téc-nica anterior, pelo qual, comandos externos são traduzidos em compressõesde tecla para testar a funcionalidade do aparelho eletrodoméstico.
A figura 17 é uma ilustração esquemática da interação de com-pressões de tecla iniciadas pelo usuário e comandos de software alimenta-dos externamente são passados como argumentos para a SA para a emis-são de comandos para um aparelho eletrodoméstico, por exemplo, para tes-tar 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 a monta-gem de um NIC em uma reentrância formada em um lado posterior do apa-relho.
A figura 19 é uma ilustração esquemática mostrando a monta-gem do NIC em um lado frontal do aparelho e um conduto de fiação esten-dendo-se da localização de montagem do cartão de interface de rede para olado posterior do aparelho.
A figura 20 é uma ilustração esquemática do aparelho compre-endendo uma barreira de segurança que permite a comunicação de um RF -PCB localizado no aparelho e impede o contato humano com calor e/ou ele-tricidade excessiva.
A figura 21 é uma ilustração esquemática ilustrando o uso de ummodo de serviço que obtém dados de diagnóstico do aparelho e carregar osdados de diagnóstico via um computador pessoa! através de uma rede ex-terna.
A figura 21A é uma ilustração esquemática de arquitetura para omódulo de serviço da figura 21.
A figura 22 é uma ilustração esquemática similar à figura 21 como módulo de serviço carregando os dados de diagnósticos via uma linha tele-fônica.
A figura 22A é uma ilustração esquemática de arquitetura para omódulo de serviço da figura 22.
A figura 23 é uma ilustração esquemática do aparelho na formade um refrigerador equipado com um módulo acessório exemplificativo naforma 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 de in-tegridade de pacote fragmentada, que substitui o protocolo ilustrado na figu-ra 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, mostrando umcenário de mensagens, onde uma solicitação de evento em duplicata é atri-buí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 um formatopadrão, ilustrando a desativação e a reativação das solicitações de eventosde realização.A figura 29 é um diagrama em seqüência de UML de um eventoreconhecido dentro da SA, onde a SA de controlador aguarda um tempo pre-determinado por uma mensagem de reconhecimento da SA de cliente 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ção propor-cionadas pela presente invenção.
A figura 31 é um diagrama em seqüência de UML ilustrando osmé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 as in-terfaces públicas padrão que a SA é capaz de implementar.
A figura 33 é um diagrama de classes de UML ilustrando a im-plementação preferida da SA.
A figura 34 mostra a organização preferida de arquivos de códi-go fonte da AS.
A figura 35 mostra uma compilação de diagramas de estado deUML inter-relacionados, ilustrando 3 estados primários (COMMJDLE,COMM_EXPECTING_ACK, e COMMPENDING), cada um dos quais, pos-sivelmente, tendo uma pluralidade de sub-estados.
A figura 36 mostra uma compilação de diagramas de estados deUML inter-relacionados, ilustrando 4 estados primários (READY, TRANSMITSNAPSHOT, UPDATES_BLOCKED, e PROCESS_DAQ_EVENTS).
A figura 37 mostra uma compilação de diagramas de estados deUML inter-relacionados, ilustrando 2 estados primários (MSG_READY eMSG_PROCESS).
A figura 38 é um diagrama de seqüência de UML1 ilustrando aexecução de uma compilação ordenada de mensagens internas entre com-ponentes com a finalidade de produzir uma mensagem de rede da rede in-terna de SA.
A figura 39 é um diagrama em seqüência de UML1 ilustrando aexecuçã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 ambi-ente operacional de software.
A figura 41 é um diagrama de seqüência de UML ilustrado asmensagens requeridas para processar mensagens que entram do barramen-to WIDE 14 dos clientes 22/16 que não requerem uma resposta contendooutros dados significativos que não uma resposta transmitindo o sucesso oua razão de falha da mensagem que entra (o ACK ou NAK de APIID = 1, OpCode = 1).
A figura 42 é um diagrama em seqüência de UML ilustrando asmensagens requeridas para processar mensagens que entram de um bar-ramento de WJDE 14 dos clientes 22/16 que requerem uma pluralidade derespostas contendo dados significativos além de uma resposta que transmiteo sucesso ou a razão de falha da mensagem que entra (o ACK ou NAK deAPI ID = 1, Op Code = 1).
A figura 43 é um diagrama em seqüência de UML ilustrando asmensagens requeridas para processar as mensagens que entram do barra- mento de WIDE 14 de clientes 22/16 que requerem mensagens de respostaúnica, contendo dados significativos em adição a uma resposta que transmi-te o sucesso ou a razão para falha da mensagem que entra (o ACK ou NAKde API ID = 1, Op Code = 1).
A figura 44 ilustra, esquematicamente, um controle de taxonomiausando um conjunto de dados de taxonomia para controlar a alteração deum ou mais componentes do aparelho sem conhecimento direto das funçõespara o componente.
A figura 45 ilustra, esquematicamente, uma interface de usuáriopovoada por um conjunto de dados de taxonomia, compreendendo uma hie-rarquia de opções e entradas de dados que levarão o usuário a selecionaropçõ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 entra-das de 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 de softwa-re("SA") que é implementada e se comunica através de uma rede de comu-nicação interna em um aparelho, que conecta os vários componentes físicosdo aparelho.
Alguns dos componentes físicos têm um controlador correspon-dente (controlador principal, um controlador de motor, uma interface de usu-ário, etc.), que pode ser um simples microprocessador montado em um pai-nel de circuito impresso. Outros componentes não têm controlador. Tipica-mente, os componentes que têm controladores (e, se houver mais de um,são, tipicamente, também capacitados para a rede) cooperam através demensagens na rede ou outras formas de transmissão de dados para, diretaou indiretamente, através de outros componentes, controlar alteração detodos os componentes e seus dispositivos contidos ou anexados para im-plementar uma operação ou ciclo para o aparelho.
A SA pode, mas não tem que, residir em cada um dos compo-nentes com um controlador. Aqueles componentes com a SA ou uma varian-te da SA compatível com a SA (compatibilidade determinada pela capacida-de para enviar, receber e processar pacotes) formam um nó na rede quepode 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 estadodos componentes para a rede; proporciona interfaces de comando bem defi-nidas para cada componente; proporciona comunicação entre componentesde software internos e externos que não são parte da SA; e proporciona co-municação entre componentes de software não SA em diferentes compo-nentes físicos. Dessa maneira, as funções de SA para informar todos os nósna 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 permitir con-figurações sem uma SA de controlador ou com múltiplas SA de controlador.Independente da configuração, qualquer componente com uma SA residentepode funcionar como um cliente com relação aos outros componentes.
As comunicações internas podem ser conectadas a um ou maiscomponentes externos diretamente ou através de uma rede externa. O com-ponente externo terá, também um, alguns ou todos os módulos de SA resi-dentes.
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 ambientede uma arquitetura de software 10 (concretizando os sistemas e métodosaqui descritos e aqueles que serão evidentes para alguém habilitado na téc-nica), na forma de um aparelho eletrodoméstico 12, tendo uma rede de co-municação interna 14, interconectando uma pluralidade de componentes 16,em que a arquitetura de software 10 reside em pelo menos um componente16 para ativar o componente 16 e, de preferência, cada componente adicio-nal 16 tenha arquitetura de software 10 residente, ou uma alternativa capazde ser inter-operável com ele. O aparelho eletrodoméstico 12 também temuma conexão de comunicação interna - externa 18, mostrada inter-conectada com vários dispositivos de interface de rede 20 para comunicaçãocom as várias modalidades de um cliente externo 22.Os clientes externos, tipicamente, compreenderão hardware esoftware de computação e hardware e software de rede, capazes de intera-gir com a arquitetura de software. Isso pode ser alcançado pela inclusão detodas ou de uma porção da arquitetura de software 10 dentro da modalidadedo cliente externo ou uma alternativa para a arquitetura de software 10, queé capaz de se comunicar e interagir, completa ou parcialmente, com arquite-tura de software 10. Um número de componentes alternativos (C dll, VisualBasic Driver, Java Driver, e Active X Driver) capazes de interagir completa-mente com 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á compreendidoque "SA" se refere à "arquitetura de SoZifwaren, conforme descrito pelo nume-rai de referência 10 neste pedido.
Ainda, o termo "cliente" é usado para se referir a um componen-te em que toda ou uma parte da SA reside ou que capacita completa ou par-cialmente 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 é u-sado para descrever um componente que é capacitado por um software al-ternativo, que é capaz de trocar mensagens com sucesso na rede de comu-nicação interna 14 e se comunicar com a SA. De um modo geral, é usadoquando se referindo aos aspectos do software e não aos aspectos do hard-ware do nó.
Os componentes 16 podem compreender um ou mais dispositi-vos. Desse modo, o termo "dispositivos", conforme usado no pedido, podese referir a um componente ou a um dispositivo. Os dispositivos podem serquaisquer 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 de umavariedade bem conhecida de aparelhos que serão bem conhecidos para al-gué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,uma combinação de refrigerador / freezer, um freezer independente, umagaveta de aquecimento, uma gaveta refrigerada, um forno, uma combinaçãode cooktop e forno, um cooktop e semelhantes. Embora o ambiente descritoda invenção seja aquele de um aparelho, a invenção tem aplicabilidade aqualquer tipo de máquina tendo componentes em rede.
Como aqui descrito, a rede de comunicação interna 14 pode serqualquer conduto de interconexão bem conhecido, fiação e/ ou chicote defios ou sistema sem fio adequado para interconexão dos vários componen-tes internos 16 de um aparelho eletrodoméstico 12. Conforme descrito naseção antecedentes deste pedido, a rede WIDE é uma rede de comunicaçãointerna adequada 14 para proporcionar a comunicação interna necessáriapara suportar a arquitetura de software 10 de acordo com a invenção. Seráevidente para alguém habilitado na técnica que a arquitetura de software 10pode funcionar em qualquer rede interna adequada e que o exemplo ilustra-tivo aqui proporcionado (isto é, a rede WIDE) é simplesmente um exemplode uma rede 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 para recebi-mento e instalação a arquitetura de software 10 de acordo com a invençãoincluem, mas não estão limitados aos mesmos, microprocessadores de con-trole de motor, controladores de teclado numérico ativados por microproces-sador, controladores de interface de usuário de LCD e outros controles dedispositivos incluídos, tipicamente, dentro de um aparelho eletrodoméstico12.
O conector ou ranhura de interface interno/ externo 18 é ade-quado para conectar um aplicação de tipos de dispositivos 20, que são ca-pazes 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-Fi1 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 de con-trole 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ções adi-cionadas de valor para comunicação com o aparelho 12. Alguns exemplossão:
<table>table see original document page 14</column></row><table>
A arquitetura de nível de sistema (elementos mecânicos, elétri-cos e de software participando para alcançar uma finalidade útil do aparelhoeletrodoméstico) inclui arquitetura de software 10 e elementos de software àparte da arquitetura de software 10. A compilação de elementos de software,incluindo, mas não limitado a mesma, a arquitetura de software 10, dentro domicroprocessador de um componente da arquitetura do sistema é aqui refe-rida como um ambiente operacional de software 16A. A arquitetura de soft-ware 10 é compreendida de três componentes: uma implementação de nú-cleo, uma definição de protocolo de aplicação, um ou mais interfaces deprograma de aplicação (aqui referidas como "AP!" ou "APIs" no plural).
Implementação de Núcleo
A implementação de núcleo da arquitetura de software 10 é umacompilação de módulos de software (exemplos encontrados na figura 3 sãoSACore1 SADiscovery, SADAK, SAPortMemory, SAPollVariable), executan-do em um micro processador de controle de aparelho. Conforme mostradona figura 11, a implementação de núcleo é executada, de preferência, nolaço MAIN do microprocessador de controle de aparelho, o que será eviden-te para alguém habilitado na técnica. O núcleo proporciona uma camadacomum de mensagens de aplicação através da rede de comunicação interna14 e está baseado em um desenho flexível, permitindo o desenvolvimentode aplicações de conectividade de plataforma cruzada. Como parte da im-plementação de núcleo, uma API de núcleo existirá, a qual será uniforme-mente implementada em cada aparelho. Além disso, onde implementaçãouniforme não é prática, um mecanismo de descoberta pode ser usado, per-mitindo adaptação pelo cliente à não uniformidade.Definição de Protocolo de Aplicação
Um protocolo é um procedimento padrão para regular transmis-são de dados entre nós em uma rede. As mensagens são enviadas atravésda rede de comunicação interna em um ou mais pacotes de dados, que sãoentã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 figura24 e sua descrição anexa representam a Definição de Pacotes da arquitetu-ra de software 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) a-cima para 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 mos-trados nas figuras 6, 9, 27, 29 e 31.
Interfaces de Programação de Aplicativo
Uma API é um contrato de comunicação e mensagens que es-pecifica como um nós de rede se comunica com o outro. Isso é realizadopela definição das chamadas de função disponíveis, os argumentos paracada chamada de função, o tipo de dados de cada argumento e, em algunscasos, os valores 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çãode arquitetura de software 10 de APIs de Núcleo (padrão ajustado de); o nú-cleo da das 10 permite e expõe múltiplas API's para o cliente 16, 22 e, pos-sivelmente, 20.
Arquitetura de Nível - Sistema
A arquitetura de software 10 foi projetada para alcançar diversosobjetivos através do tempo.
1. Produtividade de negócios dentro das restrições da arquitetu-ra de controle existente.
2. Produtividade de negócios através de capacitação e realiza-ção de nova arquitetura de controle.
3. Suporte e melhor capacitação de funções de negócios de nú-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ável'. Essa abor-dagem minimiza o risco e o custo da conectividade por meio da externaliza-ção do custo de componentes eletrônicos para a rede.
Para realizar o potencial completo desta arquitetura, um conec-tor simples pode estar disponível no aparelho 12, de modo que um cartão derede pode ser plugado no aparelho. Veja as figuras 1 e 18 a 22 para exem-plos NICs externo adequados 20 conectados ao aparelho 12. Como o apare-lho 12 já tem uma rede interna, de baixo custo 14 para sua finalidade inter-na, a fiação adicional para conectar a rede de comunicação interna 14 com oMIC externo 20, por meio de uma interface interna / externa 18, é mínima epode ser realizada de maneira conhecida, tal como por um cabo serial detrê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ésti-co. 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" inclu-em, mas não estão limitados aos mesmos: NICs externos 20 podem ser adi-cionados após a comercialização, reduzindo o custo de base do aparelho 12.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 co-mo uma 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 arquite-tura de software 10 é projetada para ser configurada em tempo de execuçãoque permite aos programadores de programas uma arquitetura mais flexívelque pode reduzir o tempo para comercialização.
A figura 2 é uma ilustração esquemática da rede de comunica-ção interna 14 da figura 1, mostrando a arquitetura de software 10 interpostaentre a rede de comunicação interna 14 e vários componentes de software16B dentro do ambiente operacional do software 16A internos aos compo-nentes 16 que constituem o sistema de controle para o aparelho eletrodo-méstico 12. Os componentes 16 na figura 2 representam componentes típi-cos encontrados em aparelhos 12, tal como um gerenciador de aparelho(placa principal ou placa mãe) e outro componente, tal como controle de mo-tor e uma interface de painel de controle ou teclado numérico, em geral, refe-rida como uma interface de usuário. Os índices "Energy" e "Diage", na figura2, são exemplos de funções típicas de não - núcleo, realizadas pela arquite-tura de software, tal como gerenciamento de energia e de potência (Έ-nergy") e localização de defeitos ou diagnose ("Diage"). Não explicitamentemostradas na figura 2, estão funções de núcleo (API 1 - 7 e 10) realizadaspela 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ésde comunicação par - a - par é desejada. Esses incluem sistemas de multi-nós onde múltiplas PCBs, tais como, placas de controle de motor, de contro-le de aparelho, e sensor inteligente se comunicam dentro do aparelho 12usando arquitetura de software 10. O protocolo de descoberta de arquiteturade software 10, ilustrado na figura 6 (e descrito aqui mais tarde), pode serusado para ativar um componente 16 cuja presença faz com que outroscomponentes 16 adaptem suas funções de controle para criar um novocomportamento ou desempenho ou expor nova capacidade para o consumi-dor. Arquitetura de componente da figura 2 (modelo estrutural) junto com ocomportamento de descoberta da figura 6 junto com o esquema de identifi-cação de componente de ID de API1 Tipo, Versão (veja ID de API = 3) sãouma base para a invenção concretizada em 10 para capacitar o aparelhocom uma nova arquitetura de sistema dinâmica e inteligente.
A figura 3 é uma ilustração esquemática da rede de comunica-ção interna 14 da figura 1, mostrando componentes típicos de controle deaparelho 16, trocando mensagens através da rede de comunicação interna14 do aparelho eletrodoméstico 12 compreendido um protocolo de camadainferior, WIDE sendo um exemplo do mesmo, que leva em conta as cama-das de OSI de PHY LINK e funcionalidade de3 camada de rede parcial e umprotocolo de camada superior suportado pela arquitetura de software 10(que leva em conta as camadas de OSI de aplicação, transporte e funciona-lidade de camada de rede parcial). O protocolo de camada inferior funcionacomo uma camada física e de ligação entre a camada superior associadacom a arquitetura de software 10 e os componentes no aparelho. Dessa ma-neira, a arquitetura de software 10 usa o protocolo de camada inferior parase comunicar com uma primeira camada de operação de software 17 queimplementa a lógica de controle do controlador 16 em relação ao cliente 22,bem como usando uma segunda camada de software 19 para desviar a lógi-ca de controle e controlar diretamente os dispositivos associados com o con-trole 16. os dispositivos na figura 3 são os elementos físicos que represen-tam a funcionalidade do componente de controle 16. A figura 3 ilustra a ar-quitetura de controle 10 de uma perspectiva de pilha de software f 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í-da 16B tendo controle direto dos dispositivos assim faz por ter acesso diretoà memória de endereço de porta de microprocessador, que, por sua vez,mapeia os pinos físicos do micro processador, que, por sua vez, são conec- tados através de vários aparelhos eletrônicos aos dispositivos eletromecâni-cos.
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 de aplica-çã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 comum ciclo operacional de Camada de Operação de Software 1. Esse controledireto permite que cada função dos dispositivos seja controlada independen-temente, o que é muito benéfico em processos de desenvolvimento ou diag-nóstico.A Camada de Operação de Software 2 é capacitada para efetuarmudança de estado por uma mensagem de rede especial exposta pela ar-quitetura de software 10 e, também lógica adicional que é personalizada pa-ra os vários estados do aparelho (exemplo mostrado na figura 7). Durante oestado de desenvolvimento, é preferido que, quando o usuário interage como aparelho 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 interfa-ce de usuário subseqüentemente, a camada de operação de software 2 po-de interagir 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 Camadade Operação de Software 1 mudar valores na memória ou mudar o estadoda pluralidade de dispositivos anexa. Contudo, durante o estado de desen-volvimento, a Camada de Operação de Software 1 não é capaz de efetuar oestado da interface de usuário (LEDs, lâmpadas, buzzers, telas de texto egráficos, etc). O Estado de Desenvolvimento torna a Lógica de Controle deCamada de Operação de Software 1 ineficaz a menos que invocada da Ca-mada de Operação de Software 2. Durante o Estado de Desenvolvimento, alógica de implementação de API 5 e 7 e a Lógica Alternativa estão em com-pleto controle do aparelho 12 e seus componentes associados.
O Estado de Desenvolvimento reverte para o Estado Inativo (dafigura 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 opera independentemen-te da permissão da Camada de Operação 2. A finalidade do estado de de-senvolvimento é permitir e ativar ciclos operacionais que não foram conside-rados previamente. A vantagem para essa abordagem é que implementa-ções e configurações do aparelho, algumas das quais estão ilustradas nafigura 1 não requerem novas modificações de software para qualquer com-ponente 16 do aparelho porque o aparelho tem a capacidade através da ar-quitetura de software 10 de suportar qualquer implementação ou configura-çã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 novas caracte-rísticas de comportamento e círculos de operação, sem modificação noscomponentes 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 compreende ciclosadicionais de operação disponíveis para seleção e invocação por um nó decliente ou aplicação ou de um usuário interagindo com uma interface de u-suá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 observa-do, válvula de enchimento ligada - observar subida do nível de água, motorde trituraçã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 e exe-cuções de DOE.
5. Realização de testagem de ciclo de vida automatizada.
6. Testagem de unidade de componente 16 e testagem de re-gressã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 ciclos sele-cionáveis de operação seja desenvolvido e testado, usando ambientes ope-racionais de software alternativos 16A àquele que é requerido, tipicamente,nos componentes de computação embutidos de produção final 16, que ofe-recem ambientes de programação mais produtivos, resultando em um temporeduzido 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ésti-co 12, mostrado na figura 1, tendo uma porção de carga útil 26 compreen-dendo uma estrutura de pacotes de aplicação 28 para a arquitetura de soft-ware 10 de acordo com a invenção. A estrutura de pacotes 28 representauma mensagem bem formada que a arquitetura de software 10 pode criar eenviar para outros componentes 16 e 22 (tendo uma ocorrência da arquitetu-ra de software 10 ou uma variante da arquitetura de software 10 que foi pro-jetada com a estrutura de pacotes 28) para fins de uma troca de dados signi-ficativa. A estrutura de pacotes 28 ocupa a posição 26 dentro da estrutura depacotes 24, mas a estrutura de pacotes 28 poderia ocupar uma posição al-ternativa em uma variante de estrutura de pacotes. 28A representa uma es-trutura de pacotes dentro de 28, que é definida de acordo com os valores deAPI Ib e Op CODE de estrutura de pacote 28.
Em um protocolo de rede, um pacote (algumas vezes chamadouma mensagem) é uma compilação de bytes que são transmitidos em se-qüência, representando toda ou parte de uma mensagem completa. Em ge-ral, é composto de um cabeçalho, que inclui informação de roteamento, umcorpo (também referido como "carga útil") que é dado, e um rodapé que al-gumas 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 de dois nós 16. A funçãoda rede e do protocolo é levar as cargas úteis de um nó para o outro. Algu-mas vezes, um protocolo é enviado como a carga útil de outro e, dessa ma-neira, os protocolos podem ser alinhados ou empilhados. Variáveis são de-nominadas localizações de memória, que terão valores associados. Uma oumais variáveis podem compreender a carga útil. Uma transação é uma sériede mensagens ou pacotes que representam uma troca de dados completaentre uma pluralidade de nós.
A relação entre um pacote e uma carga útil pode ter um impactosobre o uso eficiente de largura de banda disponível. O trade-off a ser consi-derado é a quantidade de tempo de excesso necessário para levar as cargasúteis de um nó para o outro no contexto de exigências da camada de aplica-çã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 0, 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 0 - 3 e um identificador de SAP compreendido de bits4 - 7. O identificador de SAP define a estrutura da carga útil 26 encerrada.Um SAP de 4 indica que a SDU 26 encerrada é definida pela estrutura depacotes 28 associada com a arquitetura de software 10. O byte de identifica-ção é seguido por uma unidade de dados de serviço que é referida, em ge-ral, como a "carga útil" da estrutura de pacotes de protocolo 24 e é identifi-cada em geral pela referência 26. A carga útil 26 é seguida por um byte devalidação padrão, tal como uma combinação de byte - alto, byte - baixo, ou,em geral, referida por 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 desta es-trutura de pacotes 28 que o protocolo de comunicação e a troca de dadospermitida pela arquitetura de software 10 é realizada. O primeiro byte da es-trutura de pacote de aplicação 28 contém o identificador (API ID), um inteirode 1 - 255 da API particular conduzida pelo caso particular da estrutura depacote de aplicação 28. O segundo byte da estrutura de pacote de aplicação28 contém um código de operação (aqui abreviado como "op code") comoum inteiro de 1 - 31 no bit 0 - 4 seguido por um indicador de comando ou derealimentação (Cmd / Fd) de bit 5, um indicador de fragmentação (Frag) debit 6 e um indicador pendente de mais mensagens (MMP) no bit 7. Os bytes3 - 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 funcio-nais. OxFF (255) e 0x01 (1), de preferência, são reservados. Um Op Code éum identificador único dentro de uma API que define e identifica uma men-sagem única de comando ou realimentação. Cada API tem um Tipo (2 bytes)e Versão (2 bytes) permitindo que uma grande biblioteca de grupos de men-sagens identificáveis, funcionalmente relacionados (Op Codes) seja criadacom o tempo.
De preferência, x1F (31) é um valor reservado para Op Code. Oindicador 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 é 0 para comando e 1 para reali-mentações.
O indicador Frag especifica se a mensagem recebida está sendoseparada em múltiplas mensagens (fragmentos) pelo remetente por causadas limitações de tamanho da SDU 26 de protocolo de camada inferior. Oprimeiro fragmento da mensagem tomará a estrutura da figura 4. Todos osfragmentos subseqüentes da mensagem assumirão a estrutura da figura 24.O indicador Frag é de preferência ajustado até que a mensagem fragmenta-da esteja 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 varre-dura do microcontrolador. O indicador de MMP, de preferência, é estabeleci-do até que a última mensagem para um snapshot seja enviada. A figura 9 ea discussão anexa proporcionam mais detalhes sobre mensagens delimita-das.
O indicador de MMP proporciona à arquitetura de software 10 acapacidade 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çade estado é 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 uma mu-danç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ésdo uso de MMP. Isso resulta em uso eficiente do espaço para o nome deidentificação (API ID e Op Code) porque nenhum novo identificador é reque-rido quando o cliente requer que uma nova combinação de dados seja envi-ada. Em resumo, MMP e as suas regras associadas permitem agregação dedados 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 realímentação in-dependentes enviadas como exemplos separados (mensagens de realímen-tação) sem o mecanismo de ligação, estados transitórios ambíguos ou invá-lidos são prováveis de ocorrer. Além disso, se o cliente estiver executandológica de negócios durante o estado transitório inválido, erros lógicos podemresultar em controle incorreto ou ações de exposição de usuário. Com refe-rência á seção, portanto, Integridade de Estado rotulada para um exemplode como a coleta de dados assíncronos é uma abordagem inferior para da-dos coletados sincronicamente dentro de cada varredura do microprocessa-dor e transmitidos dentro do snapshot ativado por MMP. Além disso, a aglu-tinação de mensagens pode ser usada para agrupar invocações de coman-do independentes de modo que elas possam ser processadas em lote.
O protocolo de aplicação 28 também regula mensagens que en-tram. Em geral, as redes permitem que processos assíncronos se comuni-quem, criando potencial para um nó de rede exceder a capacidade de pro-cessamento do outro pelo envio de solicitações demais dentro de uma curtajanela de tempo. Para impedir excessos de mensagens, um protocolo é usa-do, 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 10 useuma enumeração para esse reconhecimento com base no estado de execu-ção 8 da das 10. Dessa maneira, informação descrevendo o sucesso ou fa-lha de mensagens é comunicada com menos mensagens. O remetente docomando receberá um reconhecimento enumerado para cada comando en-viado. O mais comum é um ACK positivo, o que significa que o nó está pron-to para receber seu comando seguinte. Todas as outras enumerações sãouma forma de falha. A falha é caracterizada pelos 254 valores possíveis res-tantes do byte Reconhecimento. Dessa faixa de 254 valores, alguns são pa-dronizados e alguns são reservados para códigos de falha específicos deaplicação.
Frag e MMP permitem ao usuário da arquitetura de software 10permitem flexibilidade no planejamento da estratégia de mensagens de apli-caçã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 exemplificativa28 aqui mostrada) podem ser enviadas através do envio de dados grandesoriginais estabelecidos como múltiplos conjuntos de dados menores dentrode múltiplos pacotes de estrutura 28.
Pela mesma suposição, se um programador escolhe usar men-sagens menores (que são freqüentemente o caso) mas queria agrupar aque-las mensagens juntas, MMP pode ser usado. Por exemplo, se 10 mensa-gens de 3 bytes cada uma que precisam ser enviadas como um grupo, demodo que a aplicação de cliente poderia saber que as mensagens estavamrelacionadas com a mesma varredura do micro-controlador, então as 9 pri-meiras mensagens terão MMP estabelecido e a última mensagem do grupoterá MMP = 0. O seguinte apresenta um sumário de APIs definidas para aarquitetura de software 10 e, então, cada um desses comandos e mensa-gens de realimentação é descrito em detalhes. A vantagem dessa aborda-gem é que ela permite ao programador escolher modos dentro da arquiteturade software 10 que são apropriados para o estágio corrente de desenvolvi-mento (isto é, teste de unidade, testagem de engenharia, produção, etc).Além disso, a compilação de certos modos permite aos programadores usarporções da arquitetura de software 10 em cujos casos eram recursos deRAM / ROM que de outro modo seriam proibitivos. As APIs são descritascom seu identificador de interface de programa e aplicação correntementeselecionado, porém, qualquer identificador pode ser empregado sem afas-tamento do escopo desta invenção. As funções associadas tornadas capa-zes pela API particular são enumeradas abaixo de cada API. Funções emforma de bala (V) são mensagens realimentadas que são enviadas da ar-quitetura de software 10 para o cliente (tal como o cliente interno 16 ou clien-te externo 22) e funções não em forma de bala são comandos que são envi-ados do cliente (16, 22) para a arquitetura de software 10.
Observe uma conversão usada neste pedido. A palavra "esten-de" se refere à capacidade de uma API de construir a funcionalidade de umaAPI de nível - base. A palavra estende significa: quando API χ 'EXTENDS'API y, então API χ = API χ + API y. Essa notação simplifica a tarefa de ma-nutenção de registro e documentação de API. Em outras palavras API χtambém inclui aquelas funções específicas em API y. Se a API χ e API y es-pecificarem, cada uma delas, uma função com o mesmo Op Code, a imple-mentação de API χ pode tomar precedência.
A tabela a seguir descreve Núcleo API (API ID = 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, API ID = 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 DesligadoA tabela a seguir descreve a API de aquisição de dados estendi-da
DAQ Estendida, API ID = 2, Tipo 2):
A DAQ estendida é inclusiva de Basic DAQ, em tempo de exe-cução.
<table>table see original document page 29</column></row><table>
A tabela a seguir descreve a API de Descoberta (APIID = 3)
<table>table see original document page 29</column></row><table>
A tabela a seguir descreve API de Core Debug (depuração denúcleo) (API ID = 4)
<table>table see original document page 29</column></row><table>
A tabela a seguir descreve a API de Nível Baixo (API ID = 5)
<table>table see original document page 29</column></row><table>
A tabela a seguir descreve a API de Compressão de tecla denúcleo (API ID = 6)<table>table see original document page 30</column></row><table>
A tabela a seguir descreve API de Memória de Núcleo/ Porta
(API ID = 7)
<table>table see original document page 30</column></row><table>
A API de Gerenciamento de Energia é API ID = 8. Como as ou-tras 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âmetros apro-priados para obter a função.
A tabela a seguir descreve a API de Variável de Checagem (APIID = 10):
<table>table see original document page 30</column></row><table>
A API Núcleo (API ID = 1, aqui) é o menor subconjunto da fun-cionalidade da arquitetura de software 10 que pode ser empregado. Contu-do, é considerado que outras modalidades em conformidade com a estruturade pacotes 28 podem ser desenvolvidas. Toma-se providências para dese-nhar os dois esquemas de aquisição de dados codificados permanentes,referenciados na figura 5.
Na API Núcleo, um mecanismo de protocolo, enviar Eventos daFigura 5, permite ao cliente (16, 22) solicitar à fonte de eventos para enviartodos ou enviar um conjunto especificado de eventos. Dessa maneira, umtipo de checagem é possível dentro da estrutura da arquitetura de eventos,sem separar 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 de sistema. Por exemplo: se todos os nós de rede enviarem todos oseventos simultaneamente ao iniciar o sistema, operação imprecisa dentro dosoftware de um cliente 16 ou 22, onde os componentes de software existen-tes não serão capazes de processar, precisamente, a pluralidade de mensa-gens geradas como um resultado de uma condição de início, é mais prová-vel.
A API de DAQ (APl ID = 2) apresenta uma consulta de meca-nismo dinâmico para um componente 16 ativado pela arquitetura de software10. Esse aspecto permite ao cliente 16/ 22 configurar um mecanismo desoftware embutido (um arranjo de estruturas cujos elementos são instancea-dos e armazenados em uma heap de memória dinâmica [veja DynamicMe-moryHeap da figura 33, contendo uma compilação de estruturas NVOE-vent]), que associa uma seção de memória de microprocessador com um operador de eventos (descrito em uma tabela abaixo) e argumentos. Indica-dores na memória, valores da memória, operadores de eventos e argumen-tos de operadores são armazenados no arranjo de estruturas da heap damemória [figura 33 Heap contendo estruturas NVOEvent]. Conforme mos-trado na figura 5, o mecanismo de DAQ pode ser configurado de duas ma- neiras:
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 lnit().
2. Em segundo lugar, clientes externos podem usar a API de DAQ (aqui descrita) para configurar a DAQ da rede 14.
A razão para cada método de configuração de DAQ é discutida 3parágrafos daqui em diante.
Conforme mostrado no Diagrama de Estado de Eventos de DAQdo 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. Quandoas condiçõ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 armazenaro identificador de rede do componente que, inicialmente, solicitou ou configu-rou o evento.
Um programador pode usar diversos operadores de eventos.Exemplos incluem: em mudança, maior do que, menor do que, igual a, ban-da morta, máscara de bits, etc. Diversos Op Codes da API de DAQ são pro-porcionados para controlar a heap de memória em tempo de execução, co-mo: limpar Eventos, adicionar Eventos, notificação Externa liga/ desliga, ob-ter 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 naDAQ. Os outros dois esquemas, também descritos resumidamente acima,são inseridos no código. Cada esquema pode co-existir dentro da arquiteturade software 10. Cada esquema proporciona certas otimizações às custas deoutros recursos.
1. Em um esquema de aquisição de dados configurado pelo cli-ente, eventos dinâmicos são criados. Esse método pode ser usado, se o mi-croprocessador tiver bastante capacidade de RAM/ROM e é mais comumen-te usado quando o cliente é uma aplicação de PC. Usando a API de DAQ,um programador pode re-utilizar o código, requerer menos tempo de enge-nharia, alavancar um módulo de eventos re-utilizável comprovado, é flexível(por exemplo, pode ser configurado em tempo de execução) e pode haveruma otimização de largura de banda de rede. Contudo, esse método poderequerer mais RAM/ROM do que os métodos inseridos no código e um clien-te 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, omecanismo de DAQ 30 deve ser proporcionado em uma localização da me-mó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.Desse modo, a presente invenção proporciona funcionalidade para um mapavariável embutido localizado na memória de um nó implementando na arqui-tetura de software 10. Esse mapa variável liga uma API e um Op Code a umendereço de variável como na figura 26B. Desse modo, a fim de registrar umevento no referido nó, o cliente precisa apenas conhecer a API e Op Codepara aquela variável, não o endereço de memória específica.
Usando o mapa de variáveis embutido no esquema de aquisiçãode dados configurado pelo cliente, a situação pode se originar onde um cli-ente particular está restrito da criação de um evento porque o para API e OpCode 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á o en-dereç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ávele um par de API e Op Code diferente daquele previamente tentado (veja afigura 27).
2. Uma alternativa à DAQ configurada pelo cliente é a DAQ auto-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 RAMe ROM 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, um programa-dor pode otimizar largura de banda da rede, otimizar o uso de RAM/ROM epode se conformar à API de DAQ. Contudo, esse esquema requer uma so-lução com código personalizado para gerar os eventos e não conta com osoftware e a lógica da DAQ 30, conforme mostrado na figura 36.
4. Usando o método de checagem de código fixo, proporcionadopela API de Core, um programador pode otimizar o uso de RAM/ROM pelacriação de solução de código personalizado. A checagem, em geral desper-diçará largura de banda da rede, mas algumas vezes é usada devido a suasimplicidade.
A figura 5 ilustra um exemplo de cada tipo de método de aquisi-ção de dados potencial. Uma instalação da arquitetura de software 10 podesuportar um, alguns ou todos os 4 métodos. Cada um, dentre a instalação 10e o cliente 16, pode ter uma API de DAQ inicializada. A arquitetura de soft-ware 10 pode ter uma ou mais variáveis de checagem de código fixo, um oumis eventos de código fixo e/ ou um mecanismo de DAQ 30 como descrito.Várias variáveis e eventos são transmitidos entre a instalação de arquiteturade software principal e o cliente. Por exemplo, diversas variáveis de checa-gem de código fixo são permutadas entre a arquitetura de software 10 e ocliente 16 entre os métodos ler Variável de Checagem e publicar Variável deChecagem. Vários eventos de código fixo são permutados entre a arquitetu-ra de software 10 e o cliente 16 pelos métodos enviar Evento e publicar E-vento. Um método criar Evento é chamado pelo mecanismo de DAQ Init1 queé enviado para o Mecanismo de DAQ 30, que, por sua vez, permuta um e-vento gerado com o cliente 16 pelos métodos enviar Evento e publicar Even-to. O mecanismo de DAQ 30 na arquitetura de software 10 também podecriar um evento recebido por meio de um método criar Evento, recebido docliente 16.
A figura 5A é uma ilustração esquemática mostrando comunica-ção entre um aparelho eletrodoméstico 12, tendo a arquitetura de software10 nele instalada de acordo com a invenção e mostrada na figura 1 e umcliente 16 em uma localização remota, tal como um centro de suporte dechamada do consumidor, conforme mostrado na figura 5A. O aparelho 12tem uma interface 18 com sua rede interna 14 e uma interface de rede 20que permite que ele se comunique com o cliente externo 22. A vista esque-mática da figura 5A mostra o centro de serviço do consumidor preparandouma observação de variável, usando a função criar Evento do Mecanismo deDAQ 5 e diagnosticando uma dificuldade com o aparelho eletrodoméstico12, sem necessidade de enviar um caminhão de serviço para a residência.A arquitetura de software 10 pode ser personalizada para permi-tir as necessidades de diferentes plataformas de implementação. A comple-xidade de tempo e espaço da RAM e da ROM pode ser gerenciada, bemcomo 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, reim-pressos, adicionados ou cancelados, sem afastamento do escopo da pre-sente invenção.
API de Descoberta (APIID = 3) permite o conceito de arquiteturade "Plug 'n Play". A API de Descoberta implica que um nó de rede física oucliente 16 pode conter η funções, cada uma encapsulada por uma API co-nhecida com um unido ID, Tipo e Versão. Essas APIs são portáteis (signifi-cando que elas representam funcionalidade e são independentes do micro-processador, 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) permite que ocliente 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 APl de Descoberta.Não tendo estruturas na memória representando os outros componentesativados da arquitetura de software 10, um cliente 16, 22 transmite um co-mando 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,eles estão ativados (pela emissão de um comando difundido de "publicarNós"). Então, o cliente 16 transmite um comando para identificar que as A-Pls estão localizadas em cada nó ativado (pela emissão de um comando"find APls"). Cada nó ativado responde com uma mensagem delimitada,contendo seus IDs de API (através de resposta com uma mensagem de"publicar APls"). Então, o cliente 16, 22 emite um comando para identificarinformação a cerca de cada uma das APIs encontradas em cada nó ativado(pela emissão de um comando "obter Info de API"). Cada nó ativado respon-de com uma mensagem delimitada (cuja finalidade e estrutura são descritasna figura 9) contendo informação a cerca da API nele contida (respondendocom uma mensagem de "publicar Info de ΑΡΓ). Essa mensagem pode incluirtipo, versão e o número de ocorrências (ou instâncias) de um Id de API par-ticular. Em casos onde o número de instâncias de uma API particular dentrode um componente único 16 excede um (significando que há múltiplas dasmesmas APIs instaladas em um componente 16, como no caso de um fornode múltiplas cavidades que poderia usar múltiplas APIs de controle de for-no), o cliente 16 emite um comando para obter informação em cada instân-cia de uma API (pela emissão de um comando "obter Info de Instância"). Aarquitetura de software 10 responde com a informação solicitada (através damensagem "publicar Info de Instância"). Múltiplas das mesmas instânciassão auto-numeradas com um pseudo-ID de API por meio da arquitetura desoftware.
Além disso, quando um componente 16, ativado pela arquiteturade software 10 e tendo residente o sub-componente da arquitetura de soft-ware 10, Discovery que é API -Id- APId = 3, inicializa, automaticamente,enviará uma mensagem se anunciando (API Id = 3, Op Code = 2 publish-SANodeO).
Também, se o usuário da arquitetura de software assim esco-lher, 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). A aborda-gem é válida pelo fato de que o cliente pode iniciar a descoberta pela emis-são de uma mensagem Op Code = 3, obter SAAPI(coleta) que resultará emrespostas de todos os componentes ativados pela arquitetura de software10, assim, evitando a necessidade de mensagens 1 e 2 na maioria dos ca-sos.
Também é considerado que uma seqüência de mensagens a-breviadas poderia obter os mesmos resultados que a seqüência de desco-berta antes mencionada. Em uma seqüência de descoberta abreviada, cadanó emite uma mensagem após o início, contendo dentro de uma mensagema totalidade de informação que foi descrita na seqüência de descoberta an-tes mencionada. Cada nó que recebe esta mensagem responderá com amesma informação a cerca de si mesmo, dando o nó que iniciou a informa-ção que pode ser descoberta de todos os nós que já estavam iniciados.
O mecanismo do protocolo de API de Descoberta permite a 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 inferida a- propriada.
A API de baixo Nível (API ID = 5) expõe, através da rede 14, ca-pacidade, permitindo ao cliente controlar (atuar) os dispositivos de saída quesão conectados eletricamente aos componentes de contenção 16 e propor-cionar acesso de leitura e/ou escrita ao valor numérico que representa o es- tado corrente e, potencialmente, a história de estado do dispositivo de entra-da 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. Exem-plos típicos de entradas são botões de calcar, comutadores, sensores (porexemplo, pressão, temperatura e temperatura em excesso) e assim por dian- te. Na modalidade preferida, a API de baixo Nível, assim como a API Memó-ria - Porta estão disponíveis apenas no 'Estado de Desenvolvimento' da fi-gura 3 da arquitetura de software 10 do aparelho 12. O 'Estado de Desen-volvimento' só pode ser introduzido do 'Estado Inativo' do aparelho 12 dodiagrama de estado de Aparelho da figura 7. Também, na modalidade prefe- rida, se quaisquer ações de interface de usuário são iniciadas através de umteclado numérico, Icd ou outro dispositivo de interface de usuário do apare-lho 12, durante 'Estado de Desenvolvimento', o aparelho 12 pode reverterpara o 'Estado Inativo' da figura 7 e colocar cada saída de volta para seuestado não atuado. As mensagens para iniciar o 'Estado de Desenvolvimen-to' podem ser encontradas na especificação de definição de mensagem paraa API de baixo Nível. (Ver API 5, Op Code 2). Essa mensagem de rede édefinida para permitir que o aparelho 12 entre no estado de desenvolvimen-to. No estado de desenvolvimento simples, uma API é ativada e exposta arede 14 que permite que o cliente 16 controle as saídas eletrônicas do apa-relho 12 diretamente. No estado de desenvolvimento, regras de negóciosorientadas para produção, como uma validação, são desviadas, dando aocliente 16 controle completo do subsistema eletrônico.
A API de baixo nível pode ser usada para implementar operaçãonão padrão do aparelho pelo fato de que o aparelho pode ser operado deuma outra maneira que não de acordo com um dos ciclos de operação pre-determinados, implementados pela camada de operações de software deaparelho, que, tipicamente, reside no operador principal. Dessa maneira, aAPI de baixo Nível pode ser pensada como permitindo ciclos adicionais deoperação. Alguns exemplos de ciclos adicionais de operação incluem: umciclo de demonstração; um ciclo de desenvolvimento; um ciclo de detecçãode erro; um ciclo de diagnóstico; um ciclo que reduz o tempo de pelo menosuma etapa cronometrada de um dos ciclos de operação pré-determinados;um ciclo que desvia pelo menos uma etapa operacional de um dos ciclos deoperação pré-determinados; um ciclo que substitui uma etapa cronometradapor uma Etapa que responde a um evento de um dos ciclos de operaçãopré-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 qual exerci-tar e testar o software, sem atuação mecânica ou humana do teclado numé-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ções especifica-das em API y. Se API χ e API y especificam, cada uma delas, uma funçãocom o mesmo Op Code, a implementação de API χ pode ter precedê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): API ID = 1 (Tipo 3, Versão 1). Opacote de aplicação a seguir representa uma mensagem direta daarquitetura de software 10 para um cliente, para publicação de reconheci-mento (Publicar Reconhecimento). Esta mensagem é enviada pela arquitetu-ra de software 10 para o remetente de uma mensagem anterior. Ela contémum valor enumerado, representando os resultados do comando anterior pro-cessado pela arquitetura de software 10. De um modo geral, o recibo do re-conhecimento indica que o remetente pode iniciar a mensagem seguinte
<table>table see original document page 39</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 componente16 que enviou o comando original) a certeza quanto a que comando previa-mente transmitido está sendo reconhecido. (O comando previamente trans-mitido, tendo o identificador único de API Id e Op Code). Deve ser notadoque, nos desenhos e nas descrições, o ACK é, em geral, suposto e não con-tinuamente repetido ou documentado. Valores de enumeração para o código de razão do pacote de aplicativo acima são mostrados na tabela abaixo.
<table>table see original document page 39</column></row><table><table>table see original document page 40</column></row><table><table>table see original document page 41</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 publi-car indicação de atividade (Publicar Indicação de Atividade). Essa mensa-gem é periodicamente indicada pela arquitetura de software 10. Isso permiteque os nós, que tinham sido registrados para eventos, mantenham a confi-ança nas fontes de eventos. Em outras palavras, a indicação de atividadeassegura integridade da conexão. Alternativamente, o cliente (16 ou 22) po-de determinar que cada um ou alguns do(s) evento(s) enviado(s) pela arqui-tetura de software 10 receberão um reconhecimento enviado pelo cliente devolta para a arquitetura de software 10, antes que a arquitetura de software10 considere a transação associada com a geração e a transmissão do e-vento está completa. Se um evento particular tiver sido criado com o classifi-cador de 'reconhecimento' de acordo com a especificação de mensagem deAPI2, Op Code = 1,2, 12, ou 13, a arquitetura de software 10 definirá o finalda transação associada com a geração e a transmissão do evento como es-tando completa, quando uma mensagem de reconhecimento for recebida deacordo com a mensagem especificada por APIID 1 e Op Code 1.
Publicar Indicação de Atividade não será enviado até após a ar-quitetura 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 22onde os componentes dos softwares existentes não serão capazes de pro-cessar precisamente a pluralidade de mensagens geradas como um resulta-do de uma condição de iniciação). Publicar Indicação de Atividade será sus-penso após uma mensagem de Restaurar SA, que é descrita abaixo comrelação a Core DAQ API e Op Code 8, se recebida, mas retomará após ocomando subseqüente seguinte. Essa é uma mensagem de re-alimentação.
<table>table see original document page 42</column></row><table>
O pacote de aplicação a seguir representa uma mensagem dire-ta de um cliente para a arquitetura de software 10 para ajustar período deindicação de atividade (SetHeartbeat Period), que está ajustando uma fre-qüência em que a mensagem de heartbeat é enviada pela arquitetura desoftware 10. Freqüências exemplificativas oscilam de 0 segundos (desliga-do) a 3600 segundos (1 hora).
<table>table see original document page 42</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.É necessária de modo que, se um segundo cliente mudar o período de indi-cação de 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 APIId = 2, Op Code 1, Byte 9 = 4,5 ou 6 (ver mudar tabela de operador).<table>table see original document page 43</column></row><table>
O pacote de aplicação a seguir representa uma mensagem dire-ta 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 10 e 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 43</column></row><table>
O pacote de aplicação a seguir representa uma mensagem dire- ta de um cliente para a arquitetura de software 10 para leitura de memória EE (Ler EE). Ela é enviada para a arquitetura de software 10 e resulta em uma resposta de "Publicar Dados de EE" (Op Code = 8), que é mostrada abaixo e contém valores especificados em Ler pacotes de EE1 Bytes 3-7 abaixo.
<table>table see original document page 43</column></row><table>
O pacote de aplicação a seguir representa uma mensagem dire-ta da arquitetura de software 10 para um cliente para publicar dados de me-mória (Publish Memory Data) e é uma resposta para Ler Memória.
<table>table see original document page 43</column></row><table>
O pacote de aplicação a seguir representa uma mensagem dire-ta da arquitetura de software 10 para um cliente para publicar dados de me-mória de EE (Publicar Dados de EE) e é uma resposta para Ler EE.
<table>table see original document page 44</column></row><table>
O pacote de aplicação a seguir representa uma mensagem dire-ta de um cliente para a arquitetura de software para enviar eventos (EnviarEventos). A mensagem instrui a arquitetura de software 10 para enviar even-tos 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 OxFFl entãoa arquitetura 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 OxFF1 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 Byten contêm um único ID de Evento.
<table>table see original document page 44</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 pelo clien-te'. Isso se refere à atribuição feita de API ID e Op Code pelos comandoscreateEvent (enviados pelo Cliente) de DAQ API (API Id = 2), especificamen-te nos Bytes 7 e 8 de Op Code 1 & 2 e Bytes 3 e 4 de Op Code 12 & 13.
<table>table see original document page 45</column></row><table>
Core DAQ API: API ID = 2 (Tipo 3. Versão 1).
O pacote de aplicação a seguir representa uma mensagem dire-ta de um cliente para a arquitetura de software 10 para criar um evento nu-mérico (Criar Evento Numérico). A mensagem, identificada por API Id de 2 eOp Code de 1 ou 2 permite ao cliente criar e configurar variáveis de reali-mentação [estruturas de NVOEvent da figura 33], Os bytes 7 e 8 são usadospara atribuir o identificador (API Id e Op Code), que será usado para povoarcampos na mensagem publicar evento (API Id 1), quando as condições deevento são tais que uma mensagem de evento é gerada. Mensagens de e-ventos gerados são da forma encontrada na descrição precedente da APINÚCLEO, onde o pacote de mensagem é rotulado como 'Publicar Eventos'.Os identificadores API ID e Op Code localizados nos bytes 1 e 2, respecti-vamente, da mensagem Publicar Eventos. Os valores encontrados nessesbytes podem ser atribuídos através das mensagens definidas para DAQ API1Op Codes 1 e 2 abaixo. Os bytes 3-5 contêm o endereço na memória doambiente operacional de software que será avaliado para a condição de e-vento representada pelo Byte 9, que é uma enumeração de regras de avali-ação e Bytes AeB1 que são argumentos para as regras de avaliação. O by-te 6 especifica o número de bytes contíguos que serão avaliado como umvalor numérico único com relação aos Bytes 9, A e B.
<table>table see original document page 45</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çãode pacotes de aplicação exemplificativos e são mostrados na tabela que de-nota operadores de evento disponíveis, quando da criação de um evento de base numérica. Adicionalmente, o byte C corresponde ainda à classificaçãoque resulta em eventos reconhecidos ou não reconhecidos (discutidos maistarde). Veja a figura 29 para um exemplo da operação de um evento 9 reco-nhecido.
O pacote de aplicação seguinte representa uma mensagem dire- ta 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 configurar variá-veis de realimentação (eventos). A especificação de mensagem para OpCode 2 é similar em intenção, mas tem detalhes de implementação diferen- tes que proporcionam utilidade para certos casos de uso da aplicação. APIId 2 com Op Code 2 difere em funcionalidade de API 1 Op Code 1, pelo fatode que, dependendo do valor de Byte A, apenas 1 byte dentro da faixa es-pecificada 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á avaliado indepen-dentemente, de acordo com o operador de mudança especificado no Byte 9e o valor de mudança especificado no Byte B.
<table>table see original document page 46</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 estaseção de pacotes de aplicação exemplificativos e são mostrados na tabelaque denota operadores de eventos disponíveis quando da criação de umevento baseado em bytes. Adicionalmente, o byte C corresponde à classifi-cação adicional, resultando em eventos reconhecidos ou não reconhecidos(discutidos mais tarde). Veja a figura 29 para um exemplo da operação deum evento reconhecido.
O pacote de aplicação a seguir representa uma mensagem dire-ta 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 o indi-cador de MMP, se sincronização for necessária através de múltiplos coman-dos.
<table>table see original document page 47</column></row><table>
O pacote de aplicação a seguir representa uma mensagem dedifusão da arquitetura de software 10 para um cliente para a publicação deeventos limpos (Publicar Eventos Limpos) e é uma resposta para LimparEventos. A mensagem notifica os clientes da arquitetura de software 10,quando Op Codes ou APIs são removidos da interface de nós de arquiteturade software existente.
<table>table see original document page 47</column></row><table>
O pacote de aplicação a seguir representa uma mensagem dire-ta de um cliente para a arquitetura de software 10 para reajustar a arquitetu-ra de software 10 (Reajustar SA). O comando Reajustar SA instrui a arquite-tura de software 10 para reinicializar, como se ela tivesse já iniciado.
<table>table see original document page 48</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 para
Reajustar SA.
<table>table see original document page 48</column></row><table>
O pacote de aplicação a seguir representa uma mensagem dire-ta de um cliente para a arquitetura de software 10 para ativar a notificaçãoexterna para um evento especificado (Ajustar On Externo). O comando ins-trui a arquitetura de software para notificar externamente clientes do evento.Veja a figura 28 para um exemplo do uso desse comando.
<table>table see original document page 48</column></row><table>
O pacote de aplicação a seguir representa uma mensagem de difusão da arquitetura de software 10 para notificar que a notificação externa do evento especificado foi ativada (Publicar On Externo) e é uma resposta para Ajustar On Externo. Veja a figura 28 para um exemplo do resultado desse comando.
<table>table see original document page 48</column></row><table>
O pacote de aplicação a seguir representa uma mensagem dire-ta de um cliente para a arquitetura de software 10 para desativar a notifica-ção externa para um evento especificado (Ajustar Off Externo). O comandoinstrui a arquitetura de software para não notificar, externamente, clientes do48
evento.
<table>table see original document page 49</column></row><table>
O pacote de aplicação a seguir representa uma mensagem de difusão da arquitetura de software 10 para notificar que a notificação externa do evento especificado foi desativada (Publicar OFF Externo) e é uma res- posta a Ajustar Off Externo. <table>table see original document page 49</column></row><table>
API de DAQ Núcleo: API ID = 2 (Tipo 4, Versão 1 - Extensões Tipo 3, Ver-são 1).
O pacote de aplicação a seguir representa uma mensagem dire-ta de um cliente para a arquitetura de software 10 para obter dados de even-tos (Obter Dados de Eventos). Obter Dados de Eventos instrui a arquiteturade software 10 para enviar definição(ões) de eventos especificados. A defi-nição é uma imagem de espelho dos dados enviados nas mensagens CriarOp Code de Eventos, que são mostrados acima como Op Codes 1 ou 2 paraa Core DAQ API. A arquitetura de software 10 responderá com uma compi-lação de mensagens de Publicar Dados de Eventos, que são mostradas a-baixo.
<table>table see original document page 49</column></row><table>
O pacote de aplicação a seguir representa uma mensagem dire-ta da arquitetura de software 10 para um cliente para publicar dados de e-ventos 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 even-to contém a informação especificada a cerca do evento em Criar EventoNumérico.
<table>table see original document page 50</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çãode pacotes de aplicação exemplificativos e são mostrados na tabela que de-nota operadores de eventos disponíveis, quando da criação de um evento debase numérica.
O pacote de aplicação a seguir representa uma mensagem dire-ta da arquitetura de software 10 para um cliente para publicar dados de e-ventos de bytes (Publicar Dados de Eventos de Bytes) e é resposta paraObter Dados de Eventos. Cada definição de evento é relatada em uma men-sagem 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 even-to contém a informação especificada a cerca do evento em Criação de Even-to de Byte.
<table>table see original document page 50</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çãode pacotes de aplicação exemplificativos e são mostrados na tabela que de-nota operadores de eventos disponíveis quando da criação de um eventobaseado em byte.O pacote de aplicação a seguir representa uma mensagem dire-ta de um cliente para a arquitetura de software 10 para criar um evento nu-mé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 usandoum mapa de variáveis embutidos. Embora o número possa ser 4 bytes, ovalor de mudança é limitado a 2 bytes. A figura 26B ilustra o mapa variávelembutido. A figura 27 define a interação entre 3 nós de rede, onde o Nó Acria, com sucesso, um Evento Numérico Remoto no Nó Β. E onde o Nó Ctenta o mesmo, mas através da interação com o Nó B, é capaz de realizar ointento da solicitaçã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çona memó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 8na figura 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 51</column></row><table>
A figura 26B ilustra o mapa de variáveis embutido. A figura 27define 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, mas a-travé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 do identifi-cador inicial, de modo que um Identificador alternativo (não duplicado) podeser selecionado. O identificador alternativo é, então, usado para criar o E-vento Numérico Remoto pelo envio (veja mensagem 8 na figura 27) de umanova mensagem para o Nó B com o endereço de memória original e o identi-ficador alternativo.
O pacote de aplicação a seguir representa uma mensagem dire-ta 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á-veis embutido.
<table>table see original document page 52</column></row><table>
A figura 26B ilustra o mapa de variáveis embutido. A figura 27define a interação entre 3 nós de rede onde Nó A cria, com sucesso, um E-vento 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 Eventode Byte 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 identifica-dor alternativo.
O pacote de aplicação a seguir representa uma mensagem dire-ta de um cliente para a arquitetura de software 10 para obter dados remotosde variáveis de um mapa de variáveis embutido (Obter Dados Remotos deVariáveis). A mensagem instrui a arquitetura de software para publicar in-formação referente aos dados que existem no mapa de variáveis embutido.Veja a figura para um exemplo de uso desse comando.<table>table see original document page 53</column></row><table>
O pacote de aplicação a seguir representa uma mensagem diri-
gida 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 de vari-áveis embutido, como API, Op Code, tamanho e endereço.
<table>table see original document page 53</column></row><table>
API de Descoberta Núcleo: API ID = 3 (Tipo 3, Versão 1).
Fazendo referência à figura 6, o pacote de aplicação a seguirrepresenta uma mensagem de difusão de difusão de um cliente para encon-trar nós da arquitetura de software 10 (Encontrar Nó(s)). Essa mensagem dedifusão permite a um nó localizar outros nós da arquitetura de software 10.
<table>table see original document page 53</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 mensa-gem é enviada quando um nó da arquitetura de software 10 inicia ou é rea-justado ou é enviado como uma resposta para Encontrar Nós. Adicionalmen-te, essa mensagem pode ser enviada quando o nó da arquitetura de softwa-re 10 através de um processo secundário de Discovery se soma a uma APiou adiciona Op Codes a uma API existente. Publicar Nó não é enviado,quando um cliente adiciona, dinamicamente, uma API ou Op Code à arquite-tura de software 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 u-sada pelo aspecto de segurança de barreira de proteção da arquitetura desoftware 10 (veja a figura 31 para um exemplo desse aspecto). Isso permiteao remetente da mensagem tornar-se um nó 'confiável' na rede 14.
<table>table see original document page 54</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 dentrode um aparelho.
<table>table see original document page 54</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 éuma resposta para Obter API(s) e é uma mensagem direta que permite aocliente descobrir as APIs que são suportadas pelo nó de envio da arquiteturade software 10.
<table>table see original document page 54</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) A- Pl(s) especificada(s).
<table>table see original document page 54</column></row><table>
O pacote de aplicação a seguir representa uma mensagem dire-ta da arquitetura de software 10 para um cliente para publicação de informa-ção de API (Publicar Info de API) e é uma resposta para Obter Info de APLEssa mensagem direta permite ao cliente descobrir informação de Versão eTipo a cerca das API(s) especificada(s). Há um mensagem por API e asmensagens são delimitadas usando o indicador de MMP da figura 4.
<table>table see original document page 55</column></row><table>
Os bytes 4 e 5 representam um Tipo de API's que pode ser usa-do. Como uma indicação de uma subclassificação específica de uma API. Ovalor de Tipo pode ser usado para determinar compatibilidade entre sub-componentes (APIs). Os Bytes 6 e 7 representam uma Versão de API (deum Tipo particular). Esse valor pode ser usado para indicar correções de bugou mudanças na funcionalidade. Como com o Tipot ele permite uma verifica-ção de compatibilidade de tempo de execução, que pode informar ao clientese as versões são compatíveis. Alternativamente, Bytes 4-7 podem serusados em conjunto com o Byte 3 para formar um identificador de classe de5 bytes, onde classe se refere a uma definição de classe dentro de uma bi-blioteca de classes (alguém de competência típica com o estado da técnicacompreenderá). Usando a abordagem alternativa, Byte 3 (API Id) é um ma-nipulador 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 pode acom-panhar com Obter Info de Instância, que é descrito abaixo, para encontrar osIds de Instância que pertencem à API. Descr Char 1 - Descr Char n é umaspecto ótico que pode ser útil para programadores. O texto descritivo podeser usado para explicar API Id. Por exemplo, 'superior' ou 'inferir' poderia serusado para as duas cavidades de um forno duplo.
O pacote de aplicação a seguir represente uma mensagem dire-ta de um cliente para a arquitetura de software 10 para obter informação deinstância (Obter Info de Instância). Essa mensagem direta permite ao clientedescobrir os Ids de Instância para as APIs que relatam mais de uma Instân-cia de uma API. A primeira instância de qualquer API usa Id de API comoseu Id de Instância. Se há múltiplas Instâncias de um ID de API no mesmonó endereçável, às instâncias subseqüentes são atribuídos Ids de Instânciadinamicamente. Esses Ids atribuídos dinamicamente podem ser descobertospelo envio da mensagem Obter Info de Instância. O valor do Id de Instânciaseria usado em lugar do Id de API1 quando houver múltiplas instâncias deuma API em um nó de rede física.
<table>table see original document page 56</column></row><table>
O pacote de aplicação a seguir represente uma mensagem dedifusão da arquitetura de software 10 para um cliente para publicar informa-ção de instância (Publicar Info de Instância) e é uma resposta para ObterInfo de Instância. Essa mensagem direta permite ao cliente descobrir os Idsde Instância. A primeira instância de qualquer API usa Id de API como seu Idde Instância. Se houver múltiplas Instâncias de um Id de API no mesmo nóendereçável, às instâncias subseqüentes serão atribuídos um Id de Instânciasão comunicados através da mensagem de Publicar Info de API, dinamica-mente. Esses Ids atribuídos dinamicamente são comunicados através damensagem de Publicar Info de API descrita acima. Para fins de uniformida-de, Publicar Info de API é enviada para a primeira instância (isto é, onde Idde API = Id de Instância). Haverá uma mensagem para Instância de aPI, queé delimitada usando o indicador de MMP. O valor de Id de Instância seráusado em lugar de Id de API1 quando houver múltiplas instâncias de umaAPI em um nó de rede física.<table>table see original document page 57</column></row><table>
De preferência, Descr Char 1 - Descr Char 1 permite ao clienteassociar um Id de Instância com sua função física. Por exemplo, 'superior1 ouinferior' poderia ser usado para as duas cavidades de um forno duplo. Con-tudo, o usuário da arquitetura de software 10 pode usar Descr - Char 1 -Descr Char η para uma finalidade útil.
Core Debuq API: API ID = 4 (Tipo 1. Versão 1).
O pacote de aplicação a seguir representa uma mensagem dedifusão da arquitetura de software 10 para um cliente para publicar satura-ção (Publicar Saturação). A saturação acontece quando as camadas de su-porte da rede interna 14 são incapazes de distribuir os dados que a arquite-tura de software 10 colocou na fila de saída de WIDE 14A. A arquitetura desoftware 10 não tem fila; se a WIDE 14A não pode servir aos dados de saí-da, então, a arquitetura de software 10 envia Publicar Saturação.
<table>table see original document page 57</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 para sa-turação (Registrar Saturação). O cliente envia essa mensagem para um nóde arquitetura de software, que ativa a mensagem de Saturação. Apenas onó que ativa saturação pode desativar saturação.
Permite que as APls sejam classificadas como sub-classe ou especializada. Por exemplo, API IDpode se referir a uma API de máquina de lavar e Tipo pode especificar um modelo de lavadora parti-cular
2 Aliva controle de versão (isto é, correções de bugs ou mudanças na funcionalidade). Ativa unia veri-ficação de compatibilidade de tempo de execução, que pode informar ao cliente se as versões sãocompatíveis.
3 Pemiite 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 fomo duplo.<table>table see original document page 58</column></row><table>
API de Baixo Nível: API ID = 5 (Tído 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 estado in-terno mudado da máquina resultante de progressões de ciclo normais, inte-rações de usuário, Op Code 2 abaixo, ou outras mensagens recebidas atra-vés da rede 14.
<table>table see original document page 58</column></row><table>
Valores de enumeração de estado de máquina exemplificativossão apresentados na tabela a seguir. De acordo com uma modalidade dainvenção, o estado de funcionamento é um pouco ambíguo e variáveis defase adicionais devem ser expostas de modo que a lógica de negócios docliente pode ser escrita. Em uma modalidade alternativa, o estado de funcio-namento é eliminado em favor de uma máquina de estado definitiva e maisgranular onde cada fase de cada estado é documentada, adequadamente.Nesta modalidade, espaço de endereço suficiente existe no byte para enu-merações adicionais.
<table>table see original document page 58</column></row><table>
O pacote de aplicação a seguir representa uma mensagem dire-ta 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 com ha-bilidade 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 59</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 dire-ta de um 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 devi-do à técnicas de codificação usadas no processador embutido; portanto, ín-dices de teclas podem ser extraídos dos arquivos de código fonte, manual-mente ou através de outros mecanismos automatizados.
<table>table see original document page 59</column></row><table>
O pacote de aplicação a seguir representa uma mensagem di-fundida 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 59</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 59</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 dire-ta de um cliente para a arquitetura de software 10 para escrita na memória(Escrever Memória). A API de porta de Memória/ Porta é ativada através do Estado de Desenvolvimento da figura 3 e a interação associada é similar àassociação previamente descrita entre Estado de Desenvolvimento da figura3 e a API de Nível Baixo (ID de API = 7).
Essa mensagem direta permite ao cliente escrever em uma loca-lização de RAM especificada. A escrita na localização de RAM especificadaestá limitada a um único pacote. Na modalidade corrente, esse seria o de 13bytes mostrado em 28A de 28. MMP (de 28) = 1 não é válido para essamensagem.
<table>table see original document page 60</column></row><table>
O pacote de aplicação a seguir representa uma mensagem dire-ta de um cliente para a arquitetura de software 10 para escrever memória deEE (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 mensa-gem.
Porta de Memória
<table>table see original document page 60</column></row><table>
API de Variável de Interrogação: API ID = 10 (Tipo I1 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 soft-ware 10 para a leitura de variáveis de interrogação (Ler Variável(eis) de In-terrogação). Essa mensagem instrui a arquitetura de software 10 para enviaruma mensagem de Publicar Variável de Interrogação, que é mostrada abai-xo, para variáveis de interrogação apenas. As variáveis de interrogação po-dem ter código fixo feito por um programador para uma aplicação específicae podem ser usadas, se os recursos de RAM/ROM não permitem o uso deDAQ APL.
<table>table see original document page 61</column></row><table>
O pacote de aplicaçao a seguir representa uma mensagem dire-ta 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 de Inter-rogação.
<table>table see original document page 61</column></row><table>
Uma nota nos operadores de eventos, discutidos na seção deDAQ API acima. O Byte 9 da mensagem Criar Evento Numérico e Byte(DAQ API opcodes 1 & 2) e Byte 5 de CreateNumRemoteEvent e CreateBy-teRemoteEvent (DAQ API op codes 12 & 13) são o operador de mudança deeventos, mostrado na NVOEventStructure da figura 33. Operadores são ins-truções que descreve para a arquitetura de software 10 a condição matemá-tica em que a arquitetura de software 10 gerará uma mensagem de evento.A tabela abaixo descreve exemplos de operadores de eventos. Os argumen-tos para operadores de eventos são dependentes do tipo de evento que estásendo criado (baseado em numéricos ou baseado em bytes, que são op co-des 1 e 2, respectivamente).
Operadores de eventos são parte da DAQ API1 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ão depre-ciados e as modalidades preferidas são o Tipo Básico 3 ou o Tipo Estendido4, 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 ID 2, Op Code1 e 12):
<table>table see original document page 62</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 1e 12):
<table>table see original document page 62</column></row><table><table>table see original document page 63</column></row><table>
O operador de BIND permite ao cliente 16 criar múltiplos eventosde memória a partir de um disparo de evento único. Em outras palavras,uma vez que um ID de Evento tenha sido atribuído, eventos subseqüentespodem ser criados os quais, automaticamente, serão enviados, quando oevento mestre original for disparado.
Quando um evento baseado em bytes (op code = 3) for prepara-do com o operador On Change, um valor de 255 no byte 9 instruirá a arquite-tura de software 10 a fazer uma detecção de mudança para todos os bytesna faixa especificada pelos argumentos de endereço e de tamanho.
O operador Bit Mask (Máscara de Bits) permite a capacidade deobservar transições de bits dentro de um byte. O valor da máscara será es-tabelecido 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çãode valor naquela localização de bit resultará em um evento gerado.
A arquitetura de software 10 não proporciona uma solução explí-cita para sincronização de tempo, mas proporciona um mecanismo de per-missão. A capacidade do cliente remoto 16, 22 criar um evento que é perio-dicamente difundido permite ao cliente remoto 16, 22 manter uma hora deday clock (relógio eletrônico de 24 horas) que é sincronizada com o apare-Iho. Uma vez que a arquitetura de software 10 pode não expor explicitamen-te uma hora da API de day clock, o cliente 16, 22 pode ter o endereço namemória onde a hora do dia é armazenada.
O núcleo da arquitetura de software 10 tem diversas considera-ções de desenhos que podem ser consideradas e vistas para criar modali-dades alternativas da invenção aqui descrita.
Os itens a seguir podem ser considerados quando da determi-nação de modalidades alternativas da implementação de núcleo da arquite-tura 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 ReconhecidasO 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ósO 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 MensagemArquitetura da mensagem é um elemento de desenho primáriocuja a solução tem muitas conseqüências de desenho dependentes. O pro-tocolo 28 da rede de comunicação interna 14 proporciona novas possibilida-des para a arquitetura da mensagem acionada por eventos, conforme opostoàs redes anteriores. Um elemento a considerar é se os nós interrogarão umao outro, caso eles registrem para mensagem de notificação.
A interrogação é uma prática de nós que enviam mensagem pe-riodicamente 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 po-de manter 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 Ion-go de um canal de comunicação em dado período de tempo e a diversosfatores que efetuam largura de banda, tais como: número de nós em umarede, a freqüência de transmissão [taxa de Bauds] e o tempo de excesso deprotocolo [CRCs1 reconhecimentos, IDs de fonte/destino, etc], o hardware deprotocolo de transporte e cabeamento regulam o limites de largura de banda,porém, o protocolo de Aplicação tem a responsabilidade de tornar mais efici-ente o uso da largura de banda disponível). As arquiteturas de interrogaçãonão fazem escalas: à medida que os nós aumentam o número de mensa-gens aumenta exponencialmente. Supondo que aja informação sobre cadanó que todos outros nós precisam: mensagens = ηΛ2-η. Os dados, tipica-mente não estão sincronizados com a memória do controle e latência damensagem pode ser tanto 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 por en-viar uma mensagem para os nós de observação, quando os dados satisfa-zem os 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 envia-dos apenas quando eles mudam. Esse modelo faz uma boa escala com trá-fego de mensagens e minimiza a latência. Os dados são sincronizados como 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 deeventos está fora de linha. Alternativamente, a validação de conexão emmodelo de criação de eventos pode ser obtida usando-se reconhecimentosque são uma mensagem adicional transmitida do observador de eventos devolta para a fonte de eventos. Quando a fonte de eventos transmite umamensagem de evento, a fonte de eventos não considerará que a transaçãoesteja completa até que uma mensagem de reconhecimento seja recebida.Após um tempo de espera que tenha expirado, a fonte de eventos pode re-transmitir o evento. Esse processo pode se repetir por um número configurá-vel de tentativas de transmissã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. É um mecanis-mo para 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 aci-ma, bem como a simplicidade dos remédios que direcionam as desvanta-gens da criação de eventos. A validação de conexão é endereçada pelo usode um sinal de atividade e/ou eventos reconhecidos. Quando o sinal de ati-vidade é usado, a fonte de eventos enviará um evento periodicamente demodo que todos os controladores de eventos daquele nó podem saber que afonte de eventos está boa. Igualmente, a implementação do sinal de ativida-de de modo que sua freqüência seja programável também pode ser usadapara notificar a todos os assinantes de eventos que a fonte de eventos é bo-a. O período de sinal de atividade é configurável na rede. Eventos Reconhe-cidos que são descritos aqui em detalhes são um método alternativo quepode ser usado além do sinal de atividade ou sinal de atividade programávelpara assegurar a integridade da conexão. A ligação de mensagem é endere-çada com o bit de limite de mensagem na carga útil de cada pacote de men-sagem 28. Isso permite ao orientador da arquitetura de software 10 coletarmensagens correspondentes à mesma varredura de micro-controlador e a-presentar aqueles à camada de aplicação como um todo.
Usando um sub-componente da invenção conhecido como DAQ30, a arquitetura de software permite a um cliente 16 registrar dinamicamen-te com componentes de controle de aparelho 16 (ativados com a arquiteturade software 10 e incluindo o sub-componente opcional da arquitetura desoftware DAQ 30) através da rede de comunicação interna 14 para recebernotificação quando o valor em uma localização de memória especificadamuda em relação ao uma condição especificada. Isso libera o controle deaparelho 16 de ter variáveis de realimentação de código fixo e permite que arealimentação em tempo real mude de acordo com a aplicação, sem interro-gação do cliente (atualizações baseadas em eventos são difundidas preci-samente, conforme necessário).
Um heap de memória dinâmica da figura 33, isto é, memória re-servada para mensagens de realimentação configuráveis por tempo de exe-cução, empregada em que tamanho do heap é configurável em tempo decompilação. Foi verificado que cada variável de evento de alimentação re-quer cerca de 10 bytes de RAM. Os eventos registrados na heap (NVOEventda figura 33) podem ser adicionados ou restaurados através de comandosda rede de comunicação interna 14 emitidos pelo cliente para um componen-te ativado pela arquitetura de software tendo também instalado o sub-componente opcional DAQ 30.Estrutura de carga útil 29 A
Uma estrutura de carga útil de evento é uma carga útil de com-posto estático que consiste do agrupamento de múltiplas variáveis (no mo-mento do desenho) de modo que o cliente pode, com uma transação, enviarum comando completo para, ou receber o estado completo de, um compo-nente dentro do aparelho 12. Em caso de um comando, o cliente pode nãoter a intenção de mudar cada variável em uma carga útil, por tanto, uma atu-alizaçã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ão des-tinadas 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 uma va-riá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 (des-crito abaixo). Contudo, a largura de banda não é otimizada por causa deuma relação maior de estouro de mensagens para dados e ligação de men-sagens 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 incluir identi-ficadores e, possivelmente, delimitadores na carga útil, o que permitirá aoanalisador 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 partes com-ponentes. Essa estrutura de carga útil utiliza a largura de banda, mas podeaumentar a exigência de ROM devido à sofisticação requerida pelo analisa-dor. Há também algum estouro adicionado ao protocolo de aplicação umavez que a carga útil dinâmica de composto deve envolver comprimentos deop code como parte de mensagens, requer analise adicional pelo componen-te 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. A comple-xidade de uma carga útil dinâmica de composto pode ter dificuldades emuma analise de custo-benefício para as mensagens empregadas na arquite-tura de software 10. Para maximizar o uso da arquitetura de software 10, acomplexidade da interface, de preferência, será minimizada. Através de usode 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úteis de compostos dinâmicos mesmo que possa haver estouro de mensa-gem adicional (isto é, há cinco bytes de estouro para cada mensagem darede de comunicação interna 14). Há uma adicional de dois bytes de estouropara suportar o protocolo 28 da arquitetura de software 10. Isso deixa trezesbytes para o protocolo de mensagem 24 da rede de comunicação interna 14para dados em algumas condições específicas de aplicação. O uso de umacarga ú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. Correspon-dendo à mesma varredura de micro-controlador e apresente aquelas para acamada 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 ou-tro. Para cada estado, é conhecido que as teclas são candidatas válidas pa-ra a inclusão seguinte.
De um modo geral, quando uma tecla é comprimida que é invali-da, o aparelho 12 produzirá audível para indicar ao usuário que o Aparelhoestava em um estado impróprio para aquela tecla. O mesmo conceito existepara o cliente externo que deseja enviar comandos válidos, embora essecliente 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 (compres-são de 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ários esta-dos 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 32da lavadora de exemplo são mostrados na figura como inativa, lavando, cen-trifugando 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 ser rela-tados para o cliente externo 16. Contudo, mediante inspeção, pode ser vistoque a máquina de estado de processo na figura 7 não endereça eventos detodas 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 os ou-tros casos que não foram pré-definidos.
Supondo que é desejável para o cliente 16 compreender as re-gras 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 deve com-preender que não há documento ou estrutura de dados disponível, permitin-do a validação do lado do cliente (isto é, validação antes que a solicitaçãoseja enviada). Eventualmente, isso pode levar às aplicações do cliente quetêm a probabilidade de enviar um comando que o componente de recebi-mento não executará devido a sua lógica de validação, que está baseada noestado 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 erroou recuperação é um desperdício de largura de banda (supondo que poderiaser impedido). De uma perspectiva da satisfação do usuário, aplicações queimpedem o usuário de cometer erros são, em geral, considerados mais "a-migas 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, umsubconjunto 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 sobrea arquitetura de controle, mas pode ter o cliente e o controle pode, facilmen-te, ficar fora de sincronização. As regras e o desenvolvimento da lógica po-dem estar baseados em tentativa e erro (por exemplo, codificar, testar, reco-dificar). Um desenho de cliente rapidamente evolverá, criando código proce-durai pobremente projetado.
Usando um modelo de dados de API baseado em estado de de-senho de tempo, um modelo de dados é desenvolvido de modo que o clientepode interpretá-lo e impedir solicitações inválidas. Em essência, é uma cor-relaçã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 API tam-bém é responsável pela publicação da invenção para o criador do cliente (nomomento do desenho), permitindo ao projetista emular a máquina de estadono cliente. Essa máquina de estado emulada habilita a aplicação de clientede enviar solicitações inválidas. É necessário que o controle exponha cadaestado definido no modelo de dados de API. O modelo de dados de momen-to de desenho requer que o criador do controle seja responsável pela comu-nicaçã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 publica-do. O documento deve ser analisado ou convertido em lógica do lado do cli-ente e isso não funciona o tempo todo. O estado do aparelho pode mudarapenas à medida que um comando está sendo enviado, resultando em umcomando invá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 do dese-nho, mas entre o cliente e o controle no momento da execução. Algumasmensagens adicionais são requeridos para esses dados serem comunicadosdo controle. No modelo de dados de tempo de execução, o criador de con-trole pode ser responsável pela comunicação das regras de estado que go-vernam o uso de Op Code. Um cliente pode descobrir no tempo de execu-ção a definição de correlação de Op Code/ Estado. O cliente e o controleestão sempre em sincronização e as atividades do cliente e do criador sãootimizadas - nenhuma translação manual para/ de um documento. Códigoadicional (ROM) (escrito uma vez) requerido para preparar e não preparar adefinição de correlação de Op Code/ Estado. Uma largura de banda de rederequerida para transmissão de dados e uma latência de partida como umresultado de transmissão de dados. Isso não funciona o tempo todo. O Esta-do pode mudar à medida que um comando está sendo enviado, resultandoem um comando invá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-ção apropriada. Esse reconhecimento pode ou não incluir um código de ra-zão enumerado. Em um modelo de código de razão de pós-comando, nãohá mudança imposta sobre a arquitetura de controle, mas é mais provávelque um cliente envie comandos que serão rejeitados. O criador do clientedeve desenhar uma estratégia para lidar com o reconhecimento da rejeiçãoe a experiência do usuário final pode não ser tão agradável devido à fre-qüência de mensagens 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 tem-po de execução desejada. É realizado pela criação de um analisador de ladodo cliente, que pode analisar o código fonte embutido e determinar a variávela ser monitorada para cada Op Code externo. As exigências para essa solu-ção são: (1) cada comando externo não diagnóstico (Op Code) terá uma cí-nica variável booleana associada, que representa o estado de permissãorequerido para a execução; e (2) uma convenção de nomeação é usada demodo que um analisador pode se associar cada variável de permissão parao Op Code externo correspondente. Em um modelo de análise de códigofonte, o criador de controle é responsável pela comunicação de regras deestado que governam o uso de Op Code. Um cliente 16 pode descobrir emtempo de execução a versão adequada pendente de definição de correlaçãode Op Code/ Estado e o cliente e o controle estão sempre em sincronizaçãocom a versão adequada. 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 adicio-nal a ser executada a cada varredura, pequenas RAM e ROM adicionais re-queridas e apenas clientes sofisticados são capazes de analisar código fon-te.
Usando um modelo de cliente de aprendizagem, essa soluçãonão requer mudança no sistema embutido. Nesse caso, o cliente "aprende-rá" após cada comando rejeitado e construirá um mapa de permissão delado de cliente que poderia, com o tempo, obter o comportamento de tempode execuçã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.Se nenhuma variável de estado está sendo observada, então, o cliente nãopode aprender o que causou a rejeição.
Foi verificado que diversas dessas opções são modalidades pre-feridas. Por enquanto, uma modalidade preferida principal é o modelo dedados de API de tempo de execução. Um beneficiário exemplificativo 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. A ar-quitetura de software 10 pode implementar um modelo de solicitação reco-nhecido. NVORecipeStatus (API ID = 1, Op Code = 1) é uma mensagem dereconhecimento preferida que a arquitetura de software 10 envia após cadamensagem recebida.
Descoberta - Versão de APl da Figura 6
Embora o núcleo da arquitetura de software 10 seja independen-te de qualquer API, sua finalidade para a arquitetura de software 10 é expormúltiplas APIs. É realístico esperar que as APIs serão continuamente adicio-nadas à arquitetura de software com o tempo. Na antecipação disso, consi-deração para descoberta e versão de API é feita.
Também é concebível que à medida que as aplicações arquite-tura de software 10 crescem, os recursos de microprocessador não serãosuficientes para suportar todas as APIs e funções da arquitetura de software10, simultaneamente. Com o uso de diretivas do compilador, a arquitetura desoftware 10 pode ser configurada de modo que as APIs aparecerão e reapa-recerão para o mesmo modelo durante a duração da má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 clientes16 consultem o controle para descobrir o que são as capacidades correntes.Se certas capacidades não estiverem presentes (isto é, decisão de tempo decompilação), é desejável que a aplicação seja capaz de falhar graciosamen-te e comunicar 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çõesda arquitetura de software 10. Pode não haver espaço no controle para to-das as funções possíveis da arquitetura de software 10 existirem no micro-processador, simultaneamente.
Várias modalidades da invenção aqui descrita referentes aosmétodos de versão e descoberta de APIs são consideradas, sem afastamen-to do escopo da presente invenção.
Usando um modelo de descoberta baseado em número de mo-delo, o cliente é responsável por compreender as capacidades do controle.Isso pode ser feito usando estruturas de dados baseadas em clientes, basesde dados remotas ou veículos de distribuição de código de tempo de execu-ção, como OSGi1 que incluem toda a informação relevante sobre um númerode modelo particular para um aparelho 12. Em um modelo de descobertabaseado em número de modelo, não há exigência adicional sobre o controledo aparelho. Contudo, um número de modelo não é, tipicamente, atribuído1no começo de um ciclo de desenvolvimento de produto, assim, não está dis-ponível em desenvolvimento de software inicial. Números de modelo podemser mudados devido aos esquemas de cores, marcação e outros fatores irre-levantes. APIs diferentes podem ser residentes no mesmo modelo devido àsdiretivas 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 API1 adescoberta baseada em API não conta em absoluto com o número de mode-lo, 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 API1 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 ser res-ponsá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 um microproces-sador de controle podem ser requeridos para suportar Op Codes de desco-berta (isto é, mensagens adicionais).
Usando um modelo de descoberta de capacidades (também re-ferenciado como um Agente de Taxonomia), esse modelo aceita Descobertade API como uma etapa adicional. Além do ID de uma API1 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 busca se-cundária é requerida para adquirir definição de capacidade. Esse modeloaborda um conceito de UPnP ou tipo Serviço da Web e estabelece a basepara a conversão em interfaces de usuário de tela de LCD que podem seracionadas por dados. Contudo, esse conceito pode ser deficiente em custo,quando aplicado aos teclados mecânicos de margem baixa e atuadores. E,para tirar vantagem dessa técnica, o cliente 16 deve desenvolver um intér-prete para a definição de capacidades, que pode requerer esforço de mode-lagem mais intenso pelo criador de sub-função de arquitetura de software 10e significativamente mais recursos do microprocessador de controle.
Foi verificado que, no momento em que esta aplicação foi prepa-rada, um modelo de descoberta baseado em ID de API é uma modalidadepreferida. Além do ID de API, cada API pode ter um tipo e uma versão, demodo que muitas permutações diferentes de uma API podem existir atravésdo tempo. Isso pode tornar o protocolo muito mais flexível (por exemplo, po-de haver muitos tipos de APIs para um aparelho particular 12, tal como umsecador, bem como uma versão diferente de cada tipo: API de Secador, Tipode 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, pode difundiruma mensagem na rede de comunicação interna 14, chamada EncontrarNós. Essa mensagem resultará em todos os nós respondendo com umamensagem de Publicar Nó. Essa API é discutida em mais detalhes com rela- çã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í-nio usado para justificar a descoberta de API pode ser aplicado à versão deAPI. A versão permite ao cliente encontrar mais informação a cerca da API que foi descoberta.
Durante a descoberta da API, a versão e o tipo de API são rela-tados 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 um número de versão são considerados.
Integridade de Conexão
Em arquiteturas de eventos, a integridade de conexão é um pro-blema; enquanto em arquiteturas de interrogação, a integridade de conexãoé inerente. Em arquitetura de eventos, o cliente 16 pode entrar em registro bem sucedido para prestar atenção à realimentação (tal como para uma lei-tura de temperatura). Uma vez que o registro esteja completo, o cliente con-ta com o controle para notificação de mudanças na temperatura. Como tal, ocliente interpretará um problema de rede como uma temperatura constante.Em contraste, em uma arquitetura de interrogação, o cliente, constantemen- te, perguntará ao controle para realimentação de temperatura, a resposta oua sua ausência, imediatamente, indicará a integridade da conexão.
Usando um modelo opcional de indicação de atividade para rea-lizar integridade de conexão, um cliente deve registrar para uma indicaçãode atividade baseada em rede. Usando um modelo automático de indicaçãode atividade, a arquitetura de software 10 produz uma indicação de atividadeautomaticamente, quando um armazenamento temporário de registro de no-tificação não é nulo. Indicações de atividades podem ser mensagens difun-didas ou mensagens dirigidas para um nó específico.
Em um modelo opcional de indicação de atividade, se houver umcaso quando não ela é necessária, a indicação de atividade pode ser elimi-nada. Em casos onde é necessária, um cliente deve configurar a arquiteturade software 10 para produzir uma indicação de atividade. Em um modeloautomático de indicação de atividade, não há esforço requerido para funcio-nalidade desejada - a arquitetura de software 10 é inerentemente forte. Emuma indicação de atividade difundida, menos mensagens precisam ser envi-adas, uma indicação de atividade personalizada pode ser realizada através de atualizações de eventos com base em tempo e tem implementação maissimples. Contudo, isso pode resultar em manipulação de mensagens de ou-tros nós de rede que não estão participando na colaboração de arquiteturade software 10. Também, nós que não lidam adequadamente com mensa-gens difundidas podem interpretar erroneamente mensagens que entram. Em um modelo de indicação de atividade direcionada, apenas nós permiti-dos precisam lidar com o protocolo de aplicação de arquitetura de software10. Contudo, mais mensagens podem ser enviadas usando um modelo deindicação de atividade direcionada.
Para essa invenção, foi verificado que uma modalidade preferida é uma indicação de atividade para integridade de conexão e, especificamen-te, mensagens difundidas podem ser usadas para uma indicação de ativida-de. Clientes que não preferem a taxa de indicação de atividade difundidapodem, ao contrário, usar, alternativamente, uma atualização periódica deevento de NVO baseado em tempo. Fazer a indicação de atividade automá- tica pode reduzir a carga sobre o cliente. Com relação às APIs contidas naarquitetura de software 10., as funções a seguir são suportadas como partede API Núcleo (Id = 1): Heartbeat Message, Set Heartbeat Period. A indica-ção de atividade, de preferência, é iniciada automaticamente com um perío-do padrão mediante recebimento da primeira mensagem de um cliente 16.
Um método preferível opcional adicional para integridade de co-nexão pode ser introduzido na arquitetura de software 10. Foi verificado queà medida que a aplicação da arquitetura de software proliferava, era deter-minado que um método adicional de integridade de conexão era necessário.O uso do método de indicação de atividade para integridade de conexão éapropriado para muitos cenários de aplicação. Esse método é escolhido por-que ele representa uma boa troca entre a utilização de largura de banda e onível de confiança da fonte de eventos. Contudo, é possível que uma men-sagem de evento enviada pela arquitetura de software 10 falhe ao ser pro-cessada pelo assinante de evento pretendido, mesmo quando o assinantede evento 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 empreen-der uma 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 fon-te de evento reenvie (todos ou um subconjunto de todos) eventos de modoque o assinante de evento tenha a maior parte dos dados correntes. Paraendereçar esse modo de falha potencial não detectado, um segundo métodode integridade de conexão é tornado disponível através da arquitetura desoftware 10. O método, conhecido como eventos reconhecidos, permite quea integridade de cada mensagem de evento seja gerenciada individualmen-te. A figura 29 ilustra a funcionalidade do evento reconhecido. Detalhes adi-cionais referentes aos eventos reconhecidos são descritos nas descriçõesda figura 29.
Controle de Tráfego (Fluxo)
Processos assíncronos configuráveis são poderosos, mas po-dem falhar quando configurados além de seus limites de processamento físi-co e largura de banda. Mecanismos são introduzidos para impedir a satura-ção em quatro cenários de falha conhecidos: solicitações inválidas de entra-da, 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 cliente formatará e enviará uma solicitação quenão pode ser analisada ou compreendida adequadamente pelo controle oupode ser inválida, conforme o estado do controle.Solicitações Válidas de Entrada.Sem consideração, o cliente pode pedir ao controle para fazeruma segunda tarefa antes que o controle seja capaz de processar a primei-ra.
Em um modelo de armazenamento temporário, um buffer pode-ria ser usado, permitindo ao cliente enviar muitas solicitações sem preocu-pação com a capacidade de controle para servi-las. Nesse modelo, o clientenão tem responsabilidade mesmo que a implementação desse modelo sejamais simples. Contudo, o armazenamento temporário não resolve o proble-ma do controle do fluxo; apenas retarda ou torna o problema menos provávelou menos freqüente e o armazenamento temporário requer mais RAM.
Em um modelo de controle de fluxo, mensagens podem ser usa-das de modo que é requerido que o cliente aguarde até que um controle es-teja '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 controle propor-ciona uma resposta positiva ou negativa para cada solicitação de cliente. Emum modelo de solicitação reconhecida, esse modelo permite que um cliente16 desenvolva cenários simples de nova tentativa ou recuperação. Contudo,esse modelo requer mais largura de banda para os reconhecimentos e ROMe 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ção reco-nhecida, menos largura de banda e ROM são empregados. Contudo, a ex-periê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 coman-do de falta de sucesso e precisará replicar manualmente as ações de co-mando.
Tem sido determinado que uma modalidade preferida da presen-te invenção é um protocolo de controle de fluxo com um modelo de comandoreconhecido. Além disso, reconhecimentos podem ser enumerados de modoque um processo de cliente pode desenvolver cenários de recuperação tãofortes quanto possível. Como a mensagem de reconhecimento previamentemencionada nesta invenção proporciona a API e Op Code para o comandoreconhecido, um cliente pode discernir o comando que está sendo respondi-do. Isso impede a confusão em uma rede de múltiplas placas de controle,em que múltiplas placas de controle no interior de um aparelho utilizam to-das arquitetura de software 10. Reconhecimentos de comando e controle defluxo são técnicas que permitem ao cliente enviar dados tão rapidamentequanto possível, sem saturação do controle. Os benefícios podem ser apli-cações muito responsivas, sem introdução de latência desnecessária ou fa-lhas de aplicação não esperadas.
Os benefícios do controle de fluxo são obtidos usando publicarReconhecimento, API ID = 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 de RE-ADY ou UNSUPPORTED. Publicar Reconhecimento tem a máquina de es-tado para comando de controle de fluxo, conforme mostrado na figura 8.
A figura 8 é uma ilustração esquemática mostrando como a ar-quitetura 10 da figura 1 interage com comandos de entrada de acordo com ainvenção e valida ou rejeita aqueles comandos baseados no estado do apa-relho eletrodoméstico. Vários indicadores de estado de controle de fluxo sãomostrados na figura 8 com o numerai de referência 36 como, por exemplo,POWER_UP READY, BUSY, REJECTED e UN_SUPPORTED com baseem vários comandos 38 e respostas emitidas 40.Eventos de Mensagens de Saída (Realimentações).
Durante cada varredura do micro-controlador, DAQ 30 de arqui-tetura de software 10 coleta arranjos de bytes representando os eventos quedevem ser enviados no barramento (veja estado de PROCESS DAQ E-VENTS da figura 36). DAQ 30 de arquitetura de software 10 é configurávelconforme mostrado na figura 5 e, portanto, é possível que o cliente ou clien-tes possam configurar a arquitetura de software 10 para transmitir mais da-dos do que é possível para a largura de banda do barramento de comunica-ção (isto é, durante a configuração).
A fim de impedir isso, um modelo de limite de configuração podeser empregado o qual limitará a capacidade dos clientes 16 para configurar aarquitetura de software 10 para evitar esse problema. Em um modelo de ar-mazenamento temporário, a arquitetura de software 10 pode ser equipadacom um armazenamento temporário de transmissão. Em um modelo demensagem de saturação, a arquitetura de software 10 detecta quando hádados demais apresentados para a camada de transporte de modo que osdados podem 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-ção de eventos é enviada e/ ou difundida. Os eventos são resumidos umavez que uma mensagem de SendEvents (por exemplo, 255 = ALL é recebi-da. Em um modelo de não re-iniciação, uma mensagem de saturação é en-viada e/ ou difundida 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 sim-ples. Contudo, o armazenamento temporário não resolve o problema; eleapenas retarda ou torna o problema menos provável ou menos freqüente erequer mais 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 em transi-ções de estado da máquina, que são de uma natureza randômica em rela-çã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 à re-de de 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 da-dos perdidos.
No modelo de re-inicialização, o cliente não tem responsabilida-de, porém, o criador do cliente não é forçado a implementar processo derecuperação de saturação, o programador de cliente não pode estar cientede que eventos podem ser abandonados devido à configuração excessivada arquitetura de software 10. Esse tipo de falha não é catastrófico e, portan-to, 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 duranteum processo 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 o criador docliente perca tempo localizando dificuldades que podem ser diagnosticadasprogramaticamente.
Tem sido determinado que uma mensagem de saturação quenão requer que re-iniciação esteja disponível via diretiva de compilador éuma modalidade preferida desta invenção. A mensagem de saturação deveser transmitida 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 De-bug de arquitetura de software 10 (API Id = 4): obter Saturada e Registropara Mensagem de Saturação.
Conforme mostrado na estrutura de pacote 28 da figura 4, todosos pacotes da arquitetura de software 10 usam um indicador Cmd/Fb, permi-tindo a possibilidade de conflito de namespace. Desse modo, é possível so-brepor Op Codes sob a mesma API usando o indicador Cmd/Fb para discer-nimento.
Condição de Inicialização.
Se o nó de arquitetura de software 10 experimenta uma perdatransitória de energia ou micro restauração, poderia ser possível para o cli-ente ter um snapshot incorreto para as variáveis de módulos de arquiteturade software 10. Para operação forte, a arquitetura de software 10 pode noti-ficar seu cliente que as variáveis previamente exportadas não podem maisser consideradas válidas. Quando da consideração da condição transitória, aconfiguração da arquitetura de software 10 poderia, potencialmente, ser ar-mazenada em memória não volátil, o que permitiria o reinicio automática dacomunicação. Em um modelo de mensagem difundida, a arquitetura desoftware 10 pode enviar uma mensagem de difusão especial notificando to-dos os clientes para 'descarregar sua cache' com inicialização. É compreen-dido que algumas aplicações de cliente 16 podem não precisar considerarseu modo de falha e, portanto, não fará uso da mensagem especial. Tam-bém é conhecido que o ambiente operacional de software da arquitetura desoftware poderia experimentar uma falha (resultando em uma restauraçãode sua memória interna) e uma recuperação dentro do período de indicaçãode atividade. 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óriade cliente 16, contendo cópias de certos valores da memória do ambienteoperacional de software da arquitetura de software, não mais corresponderiaaos valores correntes dentro da memória do ambiente operacional de soft-ware. Para endereçar esse cenário de falha, uma mensagem de inicializaçãopode ser incluída na arquitetura de software 10. Essa mensagem é indepen-dente da indicação de atividade e indicará para qualquer cliente 16 quequaisquer valores previamente mantidos da memória do ambiente operado-nal de software da arquitetura de software 10 terão mais probabilidade deserem inválidos e que o cliente, através do uso da mensagem sendEvent deOp Code 7 de API 1, readquirirá os valores correntes. Também é compreen-dido que o cliente suspenderá ou modificará qualquer lógica ou cálculos queoperam nesses valores de memória em uma maneira apropriada até que osvalores correntes sejam readquiridos.
Em uma perda de modelo de indicação de atividade, a arquitetu-ra de software 10 pode descontinuar sua indicação de atividade, permitindoao cliente determinar a ação adequada no modo de falha. Contudo, comodescrito acima, perda de modelo de indicação de atividade não cobre todosos cenários de falha. Isso é especialmente verdadeiro quando do uso domodelo automático de reinicio.
Em um modelo automático de reinicio, a arquitetura de softwarepode retomar, automaticamente, a operação normal do último estado co-nhecido após uma re-inicialização ou restauração. No modelo automático dereinicio, o cliente pode interpretar erroneamente a informação recebida comotransições de estado que não ocorreram. Em outras palavras, para um Esta-do A existente antes de uma Restauração ou Inicialização e um Estado Bque é o Estado de inicialização de início; sem indicação adicional de um Es-tado I representando inicialização ou restauração, o cliente pode interpretaruma transição do Estado A para o Estado B, como ocorrendo se ter passadoatravés do Estado I.
Em um modelo de reinicialização requerida, um programador decliente 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 e fixa-da. Contudo, o cliente deve implementar processo de recuperação transitóriae 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 uma men-sagem especial difundida, indicativa das condições iniciais, também é com-preendida para ser uma indicação útil quando os recursos dentro do ambien-te operacional de software permitem essa característica adicional. Mesmoque o mecanismo de indicação de atividade possa ser feito para aproximar autilidade de um mecanismo de mensagem de inicialização fazendo o tempode espera menor, uma solução preferida incluirá uma mensagem de iniciali-zação, quando restrições de recursos do sistema operacional de softwarenão são proibitivas. Por essa razão, a arquitetura de software 10 suportacomo uma característica opcional uma mensagem de inicialização que é APIId = 3, Op Code = 2, publishSANode. A re-assinatura pode ser requeridaporque os disparos dinâmicos de eventos são armazenados na RAM e serãoperdidos em uma inicialização.
De preferência, o módulo de arquitetura de software 10 não en-via 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 seja detec-tado, um mensagem de indicação de atividade configurável começa a difu-são e a arquitetura de software 10, então, está pronta para operação normal.Portanto, se o microprocessador principal para a arquitetura de software 10experimenta uma inicialização/ RESTAURAÇÃO, o cliente será notificadopela detecção da ausência da mensagem de indicação de atividade (vejaAPI Id = 1, Op Code = 2) e, opcionalmente, detectando a mensagem, publi-shSANode (veja ID de API = 3 e Op Code = 2).
Integridade de Estado
A DAQ 30 da figura 5 da arquitetura de software 10 proporcionadiversas vantagens distintas em relação aos sistemas de DAQ comercial-mente disponíveis. A arquitetura de software 10 pode expor qualquer variá-vel na memória do microprocessador. Em geral, isso também incluirá os si-nais de l/O de interesse. DAQs da técnica anterior não podem assim fazer. Aarquitetura de software 10 está disponível para máquinas de produção atra-vés de um único plugue de 3 fios, enquanto DAQs ou emuladores da técnicaanterior requerem mais fiação ou instalação elétrica. DAQs da técnica ante-rior não são práticos no contexto de um teste de campo de consumidor. Aarquitetura de software 10 pode ser empregada no sistema de produção. Aarquitetura de software 10 acoplada com um modem pode proporcionar mo-nitoração remota.
O aspecto mais fundamental, tornando a arquitetura de software10 diferente dos dispositivos da técnica anterior é que ela executa como umasub-rotina de bloqueio (SA_ProcessOutgoingEvents da figura 36 e da figura11) chamada sincronicamente da função mais() do microprocessador. Issoassegura que o cliente pode ter (dentro dos limites de largura de banda derede) um snapshot completa de varredura por varredura da memória do mi-croprocessador, exatamente como o agente de execução do microprocessa-dor varrido. Isso abre muitas possibilidades interessantes, oscilando de emu-lação de baixo custo e depuração para desenvolvimento de algoritmo híbri-do, usando a arquitetura de software 10 para permitir co-processamento au-xiliado 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 da memóriade controle do aparelho.
2. Consideremos que C é uma variável calculada no cliente co-mo 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 A eB nunca ocorreu no microprocessador)
8. Cliente apresenta valor inválido para C para o consumidor ouusuário final da aplicação.
A maioria das aplicações funcionarão com coleta de dados as-síncronos. É simples e direto. Contudo, problemas associados com coletaassíncrona são extremamente consumidores de tempo para depurar e identi-ficar.
Na coleta síncrona, o cliente define ou registra AeB com a ar-quitetura de software 10. Isso permite que a arquitetura de software 10 man-tenha valores coordenados de A e B em cada varredura.
1. Cliente registra para A e B.2. Cliente solicita um enviar tudo.3. Valores correntes para AeB são enviados pelo controle parao 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 ou delimita-dor 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 snapshotsde variável de "preocupação com" o cliente ou lista de propriedade.
Tem sido determinado que a arquitetura de software 10, de pre-ferê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 (API ID = 1).
Com a técnica de coleta de dados síncronos sendo empregada,o conceito de atualizações delimitadas será discutido. Atualizações delimita-das que são agrupadas juntas como um snapshot do estado do aparelho,tomado durante a mesma varredura de execução de laço principal do micro-processador principal. O laço principal de controle de aparelho permitirá umaatualização iterativa de variáveis de realimentação que são registradas coma DAQ API (por exemplo, a cada 25 ms). Cada variável registrada é monito-rada e apenas aquelas que mudam o valor de acordo com seu operador demudanç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, ne-nhuma nova atualização é permitida a fim de preservar o snapshot em tem-po. Um snapshot é comunicado ao cliente usando o indicador MMP em Byte2 do cabeçalho da arquitetura de software 10, conforme mostrado no proto-colo de aplicação 28 na figura 4.
Embora MMP de 28, figura 4, seja verdadeiro, mais mensagensestão pendentes para o snapshot. Quando MMP é falsa, a mensagem cor-rente é a última mensagem no snapshot. Portanto, se a primeira mensagemde um snapshot for a única mensagem naquele snapshot, MMP será 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 chegandoda fonte e que o processamento de dados pela lógica de aplicação do com-ponente de recebimento será retardado até que os indicadores de delimita-ção do protocolo dentro da estrutura de pacote 28 (bit de MMP 7) indicamuma transação completa em cujo momento o processamento de dados pelalógica de aplicação é permitido. O comando delimitado é mostrado pelo nu-merai de referência 42 e as duas atualizações delimitadas consecutivas sãomostradas pelos números de referência 44 e 46, respectivamente. Observeque as atualizações não começam até que a execução de comando delimi-tada esteja completa, proporcionando ao cliente a capacidade para filtrardados de realimentação transitórios. Os comandos delimitados são propor-cionados pelo mesmo mecanismo, MMP1 encontrado em 28, como atualiza-ções delimitadas a fim de proporcionar aplicações de um nível de controlemaior.
O exemplo da figura 9 é conceituai. O mecanismo real é MMPencontrado em 28. Contudo para fins ilustrativos, o comando delimitado co-meça com um iniciador de comando inicial de "começar" (MMP estabelecido)e inclui comandos para estabelecer um ciclo de máquina de lavar para lavar,um estado de instrução para pronto, uma temperatura da água para médio,mais uma vez uma instrução para pronto e, finalmente, um indicador de iní-cio de ciclo, seguida por um terminador de comando (MMP não estabeleci-do). Pode ser notado que, na figura 9, atualizações (tais como através deeventos) são desativadas para impedir atualizações de acontecerem antesde o comando delimitado estar completo. Além disso, um indicador de "co-mando 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ão pro-cessadas.
Nas atualizações delimitadas 44, as atualizações são, mais umavez, ativadas (uma vez que foram desativadas no começo do comando deli- mitado $2) para permitir que o aparelho 12 relate seu estado para o cliente16. No exemplo mostrado nas atualizações delimitadas 44, o estado de re-conhecimento é 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, MMP1 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écni-ca de protocolo de rede.
Na atualização delimitada 46 a cesta é relatada como agitada, abomba é relatada como desligada e o motor é relatado como ligado. Maisuma vez, indicadores de começando e terminando (MMP) encerram a atuali-zação delimitada 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 paraos aparelhos. A consulta a ser considerada nesta seção é se essa API é a melhor abordagem ou se uma segunda API deve ser desenvolvida para umcliente externo 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 ser proje- tado com o conhecimento do teclado integrado, de modo que essas com-pressões de tecla podem ser geradas corretamente e isso requer um cartãode interface de rede externa para gerar compressões de tecla. Neste mode-lo, nenhuma modificação é necessária para programação de teclado subja-cente. Contudo, o cliente 22 deve monitorar o estado corrente do teclado, afim de determinar as compressões de tecla necessárias para obter o estadodesejado. A API de Cliente deve mudar, se o desenho do teclado mudar emlugar de as capacidades da máquina. Essa arquitetura rompe as melhorespráticas de desenvolvimento de software pela interposição de uma fileira deapresentação entre uma fileira do meio e a fileira e a fileira de persistência.Haverá necessidade de comandos estendidos para Gerenciamento de Ener-gia, Serviço e Diag., Testagem, etc, que não está disponíveis na interfacebásica de teclado.. Deve haver uma maneira de ter uma API lógica, bemcomo alavancagem, tanto quanto possível, do código de validação associa-do com as rotinas de manipulação de compressões de tecla, sem necessi-dade de duplicar código.
Em um modelo de API lógica, em contraste, a API Lógica é de-senvolvida de uma abstração das capacidades das máquinas em lugar dodesenho do teclado. Por exemplo, assar em um forno europeu usando com-pressões de tecla poderia requerer que lesse a posição do codificador dodial do ciclo e mudasse programaticamente o codificador para correspondera um ajuste de Bake (Assar). Se usando uma API lógica, o cliente não preci-sa enviar somente o Op Code para o Ciclo ajustado com o valor de enume-ração para Bake: {0x01, 0x01} (setCycle(Bake). No modelo de APl lógica, ocliente 16 não precisa ficar preocupado com o estado do teclado, o desenhodo teclado ou rotinas de manipulação de key press. A API permanece inde-pendente de mudanças no desenho do teclado, permite comandos estendi-dos 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 keypress. A API lógica expõe muitos dos comandos estendidos, os quais permi-tem várias aplicações adicionadas de valor No controle do aparelho, quandouma tecla na interface de usuário é comprimida ou um comando externo éemitido, ele é mapeado diretamente em uma chamada de função de API Ló-gica como um ponto de entrada comum (por exemplo, quando a tecla WASH(lavar) é comprimida ou um comando de rede WASH externo é emitido, am-bos chamarão a função SetCycIe(WASH) em uma lavadora com a arquitetu-ra de software 10 nela instalada. Uma função de API Lógica objetiva descre-ver um conjunto de funcionalidade de maneira parametrizada de modo quepossa ser reutilizado. Por exemplo, funções especializadas não lógicas paratemperatura poderiam ser IncrementTempO ou DecrementTempO, que nãopodem ser usadas facilmente para ajustar a temp a qualquer valor. Mas umafunção de API 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 software 10pode compreender um método para o software embutido em resposta aoscomandos lógicos (por exemplo, setCycle(bake) ou compressões de tecla(por exemplo, comprimindo o botão "Bake" em aparelho de forno 12). O mé-todo translaciona compressões de tecla de entrada e resulta em uma invo-cação da funçã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 que co-mandos externos são tratados do mesmo modo e executam o mesmo códigoque compressões de tecla. Essa API pode ser implementada sem um rede-senho importante do sistema de entretenimento de controle de aparelho.Apenas o software do Gerenciador de Interface do Cliente deve ser reorga-nizado e agrupado para chamar funções de API como o ponto de entradapara cada comando de compressões de tecla. Essa não é uma exigênciaimportante da arquitetura de software 10, porém. Ela sen/e apenas para mi-nimizar a quantidade de código que deve ser escrita. Se uma coleta de fun-ções de API Lógica não estiver disponível para o agente de comando exter-no, então, a lógica de estado e de validação encontrada dispersa no controlede aparelho deve ser duplicada para cada comando externo, resultando emtamanho de código maior e possibilidade aumentada de erro.
Identificação: Emissões de Multi-NósA discussão acima sobre Versão e Descoberta de API estabele-ceu um beneficio para um mecanismo descobrir as APIs residentes emqualquer nó tendo a arquitetura de software 10 nele instalada. Levado para aetapa 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 rede implementarão aarquitetura de software 10. Portanto, considerações serão feitas para redescom múltiplos componentes que implementam a arquitetura de software 10.
Em um modelo de padrão façade, o padrão façade é usado paracriar acesso simples a uma coleção de objetos. Isso é feito pela criação deuma 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 ob-jeto alvo apropriado. No modelo de padrão façade, esse modelo é mais fácilde gerenciar porque a API é definida centralmente. Na maioria das aplica-ções, a façade apresenta uma interface mais simples para o cliente. Contu-do, esse modelo requer projeto do tempo de compilação para incluir outrasAPIs de nós no nó de façade. RAM/ ROM adicionais podem ser requeridasparas a façade manipular e enviar solicitações para o nó alvo. E, se dois nóssão clientes 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 usa proto-colo de descoberta como o meio para o cliente encontrar os objetos alvo. Ocliente é responsável pela interação independente com cada objeto alvo, Emoutras palavras, o cliente descobrirá o(s) nó(s) de arquitetura de software 10e, então, interrogará cada um quanto a que API(s) são suportadas por cadanó. No modelo de serviço distribuído, esse modelo escala bem de modo queos componentes podem ser plugados juntos em tempo de execução. Contu-do, esse modelo pode requerer múltiplos documentos para gerenciar as de-finições de 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 APIdo objeto alvo requerem mudanças na façade (mudar, compilar, baixar, tes-tar). Enquanto em um ambiente de tempo de compilação único, suportadopor boas ferramentas de re-fatoração, a façade poderia ser uma boa esco-lha. Em um ambiente distribuído, o modelo de serviço distribuído mais flexí-vel permitirá desenvolvimento mais rápido e configurações flexíveis. Contu-do, em alguns casos pode não haver recursos suficientes em cada micro-processador no sistema para suportar a 10. Em outros casos, pode haverprotocolo pré-existente e não há desejo de fazer modificações em um painelpré-existente. Nesses casos, façade pode ser uma boa alternativa para omodelo de serviço distribuído.
Múltiplos Clientes.
Conforme mostrado na figura 1, múltiplos nós ou clientes 16 narede 14 implementarão a arquitetura de software 10. Portanto, considera-ções serão feitas para redes com múltiplas ocorrências de 10. Uma conside-ração principal é a do registro e notificação de eventos. Se múltiplos clientesregistram com a arquitetura de software 10 para eventos, a arquitetura desoftware 10 será capaz de gerenciar distribuição de eventos.
Usando um modelo de criação de eventos de mensagens diretasde ID de nó, a arquitetura de software 10 armazenará o(s) ID(s) de Nó(s) decada solicitador de evento, de modo que, quando aquele evento é disparado,uma mensagem direta será enviada para o(s) Nó(s). Nesse modelo, as men-sagens são enviadas apenas para nós que se interessam pelo evento. Con-tudo, esse modelo requer um byte por mensagem para armazenar o ID deNó e requer mais RAM para criar estruturas adicionais de memória para ca-da nó solicitante.
Em uma mensagem dirigida de ID de nó criando eventos com oIdentificador de ID de API, usando essa abordagem, a arquitetura de softwa-re 10 armazena o(s) ID(s) de nó(s) de cada solicitador de cada evento, demodo 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 clien-te melhorar 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ó solici-tante.
Em um modelo de criação de eventos de mensagem de difusão,usando essa abordagem, a arquitetura de software 10 não rastreia o ID denó do solicitador de evento, Quando o evento é disparado, a arquitetura desoftware 10 envia uma mensagem de difusão. Nesse modelo, a implementa-ção da arquitetura de software 10 é mais simples e menor, não há necessi-dade de gastar um byte por mensagem para armazenar o ID de nó. Contu-do, a difusão pode criar processamento de eventos desnecessários por ou-tros nós.
Uma quarta abordagem híbrida, que é a abordagem preferida,compreende um modelo onde mensagens de difusão são usadas, o que eli-mina a necessidade de armazenar Id de Nó. Contudo, o cliente incluirá Id deAPI e Op Code nas Mensagens de Criação de Eventos da DAQ (Id de API 2,Op Codes 1,2, 12, & 13), de modo que elas são dinamicamente atribuídas(conforme discutido no parágrafo abaixo). Usando essa abordagem, a men-sagem de evento resultante conterá o Id de API e Op Code atribuídos (con-forme mostrado na mensagem publishEvent de Id de API = 1). Nessa men-sagem (publishEvent), o Id de API e Op Codes de Bytes 1 e 2 de 28 na figu-ra 4, são aqueles atribuídos pelo cliente 16, usando as Mensagens de Cria-çã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 eOp Code. Isso proporcionará o benefício de roteamento por troca de arma-zenamento de ID de API para armazenamento de ID de Nó. Dada a discus-são em SAP abaixo, o risco de mensagens de difusão é muito diminuído. Eembora uma quantidade de processamento seja usada pelos nós para des-cartar mensagens não relevantes para eles , é superior às mensagens dirigi-das, o que poderia, eventualmente, causar saturação da rede e do código dearquitetura de software 10. Incluindo o, o ID de API permite que o clienteconfigure o controle com APIs dinâmicas que encorajarão desenhos modula-res, melhores, no futuro.
Usando a Mesma API em Nós Múltiplos.
É provável que algum componente de rede opcional implementa-rá a mesma API que o painel de Ul ou Gerenciador de Aparelho (isto é, ser-viço/ diagnóstico ou energia). Isso permitirá que o componente de rede op-cional 16 se manifeste para um cliente externo 22. Desse modo, a arquitetu-ra de software 10 pode permitir que o cliente 16, 22 interaja com dois nósfísicos - cada um implementando a mesma API. Essa consideração de de-senho está na interseção de diversas outras e, igualmente, sua resolução éuma combinação de soluções de desenho pré-existentes.
Nós opcionais são possíveis através de participação dinâmica. Ocliente 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 para des-cobrir 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 de arqui-tetura de software 10 e, então, descobrir as APIs de suporte de cada um. Ocliente pode, então, iniciar uma interação com cada API de cada nó. Comocada pacote 24 incluí o ID de nó e o ID de API, ambos, cliente e alvo, serãocapazes de evitar conflitos de namespace e mensagens de roteamento parao espaço de aplicação apropriado.
Múltiplos Casos de APIs no mesmo Nó de Rede.
Há 12 desenhos de aparelho que se prestam À reutilização deAPI no mesmo microprocessador. Exemplos incluirão um forno duplo (isto é,duas câmaras de assar controladas separadamente) ou uma gaveta refrige-rada de dois compartimentos. Em outras palavras, em alguns casos há múl-tiplas cavidades que desempenham a mesma função e podem, portanto, sercontroladas através da mesma API. A abordagem do desenho para essecaso é discutida.
Em um modelo de nome de função única, o programador criaráum ID de API que tem Op Codes únicos para cada comando ou variável sempreocupação com a re-utilização da definição. Em outras palavras, Op Code10 = temperatura de ajuste de forno mais baixa e Op Code 11 = temperaturade ajuste de forno mais alta. Nesse modelo de nomes de função única, hámenos mensagens durante a descoberta, porém, esse modelo não promovedesenho 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 a desco-berta e esse modelo promove desenho modular e reutilização. Contudo, es-se modelo resultará no consumo dos IDs de APIs em uma taxa mais rápida.
Em um modelo de ID1 a arquitetura de software 10 atribui, dina-micamente, o ID de API a cada caso da API, exceto para o primeiro caso. Oprimeiro caso da API será identificado por um repositório global de ID de A-PI. Para permitir isso, a arquitetura de software 10 especifica IDs de API (porexemplo, 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 por objetoprojetado para permitir que objetos descubram e colaborem um com o outrode maneira segura. Básico para essas exigências são: (1) entidades de co-laboração devem ser endereçáveis unicamente de modo que mensagenspodem ser apropriadamente roteadas na rede e (2) entidades de colabora-ção devem ser identificáveis unicamente, assim, seus contratos de mensa-gens, regras para interação e preocupações de compatibilidade podem sercompreendidos. Em um ambiente único de tempo de execução, o compila-dor é 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 (ob-jeto ou API) é governada pela combinação de um ID de nó de 3 bits (encon-trado no Campo de Endereço de 24 na figura 4) e uma API ou ID de instan-ciamento de 8 bits (encontrado no Byte 1 de 28 na figura 4). Qualquer men-sagem de rede contendo essas duas partes de informação podem ser rotea-das corretamente. Isso proporciona 255 entidades (ou objetos) de colabora-ção únicas para cada nó de rede.
A identificação de entidade é definida por um ID de API de 8 bits(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 de en-dereç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 pe-los onze 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, Publi-sh API Info1 Get Instance Info e Publish Instance lnfo. O instanciamento éum conceito muito poderoso, que pode ser exemplificado por seu uso noprotocolo.
Namespace de API - Op Code.Mensagens em uma rede serial, em geral, têm ASCI! ou identifi-cador numérico que permitem ao receptor da mensagem rotear os dadoscontidos na mensagem para a função interna apropriada. Essa função, en-tão, operará sobre os dados restantes na carga útil.
Os dados restantes na carga útil são definidos em tempo de de-senho em um documento. Esse documento descreve o significado de cadabit e/ 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 de Op Code e Cmd/Fb.
Normalmente, se houver múltiplas definições de carga útil inde-pendentes, que compartilharam o mesmo Op Code sem qualquer mecanis-mo de identificação adicional, será impossível para o receptor rotear aquelamensagem pára o manipulador de mensagens. Contudo, a presente inven-ção proporciona o indicador Cmd/Fb para suportar a sobreposição de OpCodes, usando o indicador para diferenciação. Desse modo, a presente in-venção proporciona a funcionalidade para sobreposição de um comando esua mensagem de realimentação correspondente, usando o mesmo Op Co-de
Essa seção discute técnicas que podem ser empregadas paraproporcionar identificação única para as definições de carga útil de mensa-gem.
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 Co-de de qualquer outro projeto. Esse modelo é ineficiente devido às alocaçõesde faixa que requerem IDs sobressalentes. Ainda, criadores de API não te-rão controle sobre seu esquema de numeração de Op Code e esse modelorequer uma ordem de decisões de magnitude mais coordenadas (transferên-cia de informação).
Em um modelo de ID de API globalmente único, usando essaabordagem, Op Codes são agrupados em coleções lógicas formando umaAPI. À APl será atribuído um ID globalmente único composto de Id de API,Tipo e Versão, Portanto os Op Codes existentes só precisam ser únicos den-tro da API. Nesse modelo, não há necessidade de IDs sobressalentes alo-cados, criadores de API podem começar em Op Code = 1 e esse modelorequer menos coordenação de informação para evitar conflitos de namespa-ce.
Tem sido verificado que a presente invenção emprega a estraté-gia de ID de API globalmente única como uma modalidade preferida. CertosOp Codes fixos, que são parte da API de Núcleo de arquitetura de software10, revertem para o número de partida comum (1) e à API de Núcleo, de pre-ferência, pode ser atribuído um ID de API de (1).Atribuição de SAP.
SAP encontrado em 24 identifica a estrutura da Carga Útil Es-tendida ou SDU 26. É o mesmo conceito que o de um ID de API, que foi aquiintroduzido antes. As vantagens de SAP também são as mesmas, pelo fatode que as mensagens que entram precisam ser identificadas e rateadas pa-ra os manipuladores internos corretos (ou descartadas rapidamente). Narede WIDE 14 de exemplo aqui discutida, há dezesseis SAPs disponíveis. Aarquitetura de software 10 adapta os critérios para associação de SAPs.Nesse cenário, o administrador da rede de comunicação interna 14 podeaprovar o protocolo de aplicação da arquitetura de software 10 e atribuir áarquitetura de software 10 um SAP oficial. Outros identificadores de redepara o protocolo 24 são considerados sem afastamento do escopo da pre-sente invenção. Por exemplo, à arquitetura de software 10 pode ser atribuídoum SAP padrão de 1 na rede interna 14.
Um SAP (ou outro identificador de sub-protocolo) permite que onó da rede de comunicação interna 14 participe na arquitetura de software10 e mensagens de não arquitetura 10. O SAP da arquitetura de software 10se adapta na arquitetura global e adiciona mais escopo à arquitetura desoftware 10. O SAP da rede de comunicação interna 14 é um conceito desom de uma perspectiva técnica e prática. A garantia de um ID especifico derede 14 proporciona à arquitetura de software 10 visibilidade global e aceita-ção oficial, o que pode ajudar a proliferar seu uso e impeli-la para um padrãoglobal.
A Descoberta de arquitetura de software 10 - Figura 5.
Na seção anterior, foi estabelecido que o ID de API de arquitetu-ra de software 10 é análogo ao SAP da rede de comunicação interna 14.Igualmente, nas seções anteriores, é estabelecido que é vantajoso para ocliente 16 da arquitetura de software para descobrir pela interrogação da(s)API(s), que residem em cada nó físico da arquitetura de software 10.
Uma consulta e/ ou solução similar pode ser apresentada para adescoberta da arquitetura de software 10. Se uma ferramenta de serviçoquisesse descobrir dinamicamente todas as API(s) de arquitetura de softwa-re 10, primeiro precisa descobrir os IDs de Nós do(s) nó(s) da rede de co-municação interna 14 que suportavam o protocolo da arquitetura de software10. Isso pode ser realizado por um modelo de mensagem de difusão queenvia um comando de difusão ao qual os nós de arquitetura de software 10responderão. Nesse modelo, a arquitetura de software 10 pode difundir umanova API, que é adicionada à arquitetura de software 10 ou pode difundir aadição de um novo nó(s) de rede 14, que implementa a arquitetura de soft-ware 10. A API de Descoberta, Figura 6, que servirá como o mecanismo pa-ra 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 Úteis
Frag, bit 6 de Byte 2 no cabeçalho de arquitetura de software 10,permite ao protocolo de arquitetura de software 10 enviar cargas úteis maio-res do que aquelas do protocolo subjacente (isto é, aquele da rede de co-municação interna 14). Quando Frag é estabelecido, o receptor perceberáque a mensagem corrente será fragmentada em múltiplos pacotes ou frag-mentos.
No modelo de id de fragmento de mensagem, o primeiro frag-mento 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 fragmentos subse-qü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 mais umfragmento da mensagem corrente será esperado. A transição de MFP de 1 aO informa o receptor de que o pacote corrente é o pacote final da mensagemcorrente. O MID proporciona um identificador de 2 bits para cada mensa-gem. 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é 3e, então, se deslocará de vota para 0. FID proporciona um identificador de 3bits para cada fragmento dentro de uma mensagem. Assim, para uma men-sagem particular, o primeiro fragmento será sempre atribuído e FID de 0.Para cada fragmento subseqüente daquela mensagem, o FID será incre-mentado. O FJD incrementará para 7 e, então, se deslocará de volta para 0.
O protocolo de fragmentação proporcionado pela presente in-venção permite ao receptor verificar a integridade de uma mensagem frag-mentada. Pela monitoração do indicador Frag e MFP1 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 mensagens frag-mentadas separadas não se tornam fundidas (talvez devido a um fragmentoperdido). Através da verificação de que os incrementos de correção de FIDpor fragmento, o receptor pode assegurar que nenhum fragmento é perdidodentro de uma mensagem (ou recebido fora de ordem). Veja a figura 25 paraum 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 uma men-sagem de múltiplas carga úteis. A CRC é a representação de CRC de todosos bytes de carga útil concatenados em uma carga útil combinada única. Oemissor gera essa CRC. O receptor valida essa CRC de acordo com méto-dos bem conhecidos. Neste modelo de CRC de sumário, essa solução reuti-liza algoritmos de CRC existentes, que são estabelecidos e bem conhecidos,contudo, o algoritmo de CRC é mais complexo do que o contador de qua-dros e a CRC pode não ser facilmente portátil para um vendedor de tercei-ros.
Portanto, tem sido determinado que o modelo de id de fragmentode mensagem é uma modalidade preferida para confirmar a integridade damensagem de múltiplas cargas úteis η arquitetura de software 10 de acordocom a invenção. O modelo de id de fragmento de mensagem é mais fácil deimplementar por terceiros e é mais fácil de adicionar à arquitetura 10 existen-te.
Organização de Software
Com relação à arquitetura de software 10, os arquivos de orga-nizaçã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 ambi-ente operacional de software 16A de um componente 16 contendo várioscomponentes de software 16B, em que o arquitetura de software 10 com-preende um manipulador de comando 50, um manipulador de atualização 48e uma interface de camada de rede de comunicação interna 52 para interco-nexão da arquitetura de software 10 à camada de operação de software darede 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 é mostradoum exemplo de como outros componentes de software 16B dentro do ambi-ente operacional de software 16A invocarão e interagirão com os componen-tes da arquitetura 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 Ul (queé um de diversos componentes de software 16B dentro do ambiente opera-cional de software 16A) foi eliminada. Nesta implementação, o laço de exe-cução Principal 11 do ambiente operacional de software 16A executa a invo-cação em 50. Acreditava-se previamente que a implementação anterior pro-porcionasse 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ão mostrados: o manipulador de atualizações 48, o manipulador de coman-dos 50 e a interface de camada de rede de comunicação interna 52. O ma-nipulador de atualização 48 interage com o agente de DAQ 30 a fim de iden-tificar a informação com indicadores para atualizações dentro da operaçãoda DAQ de modo que a interface de camada de rede de comunicação inter-na 52 pode processar a referida informação resultando em interação com acamada de operação de software 14A de rede de comunicação interna, re-sultando em uma estrutura de pacote 24 transmitida na rede 14. O manipu-lador de comando 50 valida e processa comandos de entrada da interfacede camada de rede de comunicação interna 52, invocando a função de ope-ração de software apropriada de acordo com os valores de ID de API de I-dentificadores e Op Codes de estrutura de pacote 28. A interface de camadade rede de comunicação interna 52 significa desacoplar (tanto quanto prati-cável) os particulares da arquitetura de software 10 da camada de operaçãode software de rede de comunicação interna 14A, a rede 14 da figura 1 e aestrutura de pacote 24 da figura 4. A interface de camada de rede de comu-nicação interna 14 52 faz interface com a Camada de Operação de Software14A da rede de comunicação interna 14, o que cria e envia dados de acordocom a definição da figura 4 através da rede de comunicação 14 do aparelhoeletrodomé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 tam-bém têm a arquitetura de software 10 ou uma alternativa capaz de interagircom a estrutura de pacote 24.
A figura 34 mostra diversos arquivos de implementação, que sãoconsiderados para uso com a presente invenção.
AS prm.h.
A arquitetura de software 10 inclui parâmetros configuráveis eenumerações de comando.SACore.c/h-
Este arquivo para o software de núcleo de arquitetura de softwa-re 10 contém o manipulador de atualizações 48 e o manipulador de coman-do 50, que processa comandos, gerencia realimentação de controle de fluxoe toma snapshots de dados do aparelho para atualizações dinâmicas.SAAppSpecific.c/.h.
Este arquivo para o software de núcleo de arquitetura de softwa-re 10 contém manipuladores de comando específicos de aparelho e imple-mentações de comandos para acionamento de um tipo particular de apare-lho 12 (tal como um arquivo dirigido especificamente para gerenciamento ecomunicação com uma máquina de lavar, por exemplo). Qualquer comandoque não é genérico para todos os aparelhos 12 é implementado nessa fun-ção. Esses comandos são enumerados em AS_prm.h e são chamados pelomanipulador de comando.SAWideComm.c/h.
Esse arquivo contém a camada de aplicação 52 de rede de co-municação interna 14, que proporciona a interface para o protocolo da redede comunicação interna 14 e controla a delimitação de mensagens emsnapshots, análise de comandos de entrada e processamento de indicado-res de atualização para enviar mensagens de atualização.SADaq.c/h.
Esses arquivos contém toda a funcionalidade para o agente deDAQ 30. Desse modo, toda a funcionalidade referente ao manipulador deatualizações 48 e eventos está contida aqui.SADiscovery.c/h.Esses arquivos contêm toda a funcionalidade para um nó queimplementa a arquitetura de software 10 para descobrir outros nós (e a fun-cionalidade correspondente de) outros nós que implementam a arquiteturade 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 a in-venção. Também é mostrada a invocação de MAIN em WIDE.WideExecQ.WIDE.WideExecQ subseqüentemente chama de volta a arquitetura de soft-ware 10 de acordo com a figura 33, onde o componente da arquitetura desoftware 10, WideCommHamdIer1 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 da ar-quitetura de software 10) que finalmente resulta na invocação mostrada nafigura 33 na função WIDE.QueueMsgO do componentes WIDE do ambienteoperacional de software 16A.
A figura 13 é uma ilustração esquemática da implementação deexemplo da arquitetura de software mostrada na figura 11, incluindo umaseção de inicialização de aparelho. A função de inicialização chamaSA_lnit() de uma rotina de inicialização antes da introdução do laço de exe-cução principal mostrado na figura 11.
A tabela em seguida a este parágrafo ilustra um exemplo de do-cumentação de como APIs serão gerenciadas, incluindo o mecanismo deDiretivas de Compilador para controlar o emprego da funcionalidade exposta através das APIs da arquitetura de software 10.<table>table see original document page 107</column></row><table><table>table see original document page 108</column></row><table>
Na tabela acima, Ids de API ria 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íficospara uma coleção de mensagens que são esperadas serem 'Unicas'. EssesIds també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 Compilador Cós-mico HC08 da Motorola com a arquitetura de software 10 configurada parater 30 eventos dinâmicos permitidos (isto é, tamanho de heap), 7 APIs defi-nidas e um tamanho de comando máximo de 15 bytes.
A figura 14 é uma ilustração esquemática de um roteador virtualincorporando a arquitetura de software da figura 1 de acordo com a inven-ção, mostrando um mapeamento entre um par de implementações de arqui-tetura de software. O roteador virtual da figura 14 é um desenho de softwareque encapsula implementações (objetos, veja APIs 1 - 8 em cada lado doroteador da figura 14) da arquitetura de software 10 de modo que a colabo-ração entre um cliente embutido (lógica de aplicação, algoritmos, laços fe-chados, seqüenciadores e máquinas de estado) e componentes embutidos(implementação de API de arquitetura de software 10: objetos como descon-geladores, aquecedores, sensores de temperatura, válvulas, etc.) é uniformee idêntica, independente de se as entidades colaboram através da rede oucompartilham um ambiente de tempo de execução.
A figura 14 mostra seis exemplos únicos de colaboração rotula-dos como tal, ilustrativos de como um par de ambientes operacionais desoftware 16A existentes em componentes de hardware separados 16 e co-nectados por uma rede 14 usará os vários componentes de software 16B doambiente operacional de software 16A para criar acesso transparente entrea lógica operacional de 59 e os componentes de software 16B dos ambien-tes operacionais de software direito e esquerdo.
Antes da descrição dos exemplos de colaboração, uma descri-ção da estrutura da figura 14 auxiliará na compreensão dos exemplos decolaboração. Cada ambiente operacional de software 16A contém represen-tações de um subconjunto de componentes operacionais de software úteis(16B) contidos, incluindo: a arquitetura de software 10, a interface de cama- da de rede de comunicação interna 14A, o DAQ 30 e uma camada de abs-tração de hardware 80.
A camada de abstração de hardware 80 compreende: um meca-nismo para encapsular o endereço fixo particular dos circuitos elétricos co-nectados em que as camadas operacionais de software de 80 operarão; e interfaces 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 software10, 28A a representação empacotada (uma coleção ordenada de bytes) deuma mensag3em trocada pela arquitetura de software 10, representando apenas a carga útil de aplicação 28A (os argumentos de dados válidos) es-perados pelo componente operacional de software 84 ou 86, 82 uma repre-sentação alternativa de 28 ou 28A, onde a intenção e os valores de dados eações resultantes são funcionalmente idênticos, mas não da forma de umacoleção ordenada de bytes. 82 está na forma de uma função única de soft-ware, tendo argumentos representados por variáveis nomeadas individuaiscujo valor é derivado de 28A ou representado por uma coleção ordenada debytes derivados de 28A.
GDMs de aplicação 84 (Global Design Modules) são variantesde 16B conhecidas como módulos de desenho global, que são componentes operacionais 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 como descon-geladores, aquecedores, fechamento de porta. Os GDMs de aplicação po-dem 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 softwa-re, 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 o compor-tamento e coletar informação de um dispositivo ou sensor eletromecânicoespecífico, tal como um aquecedor, evaporador, motor, válvula, solenóide,relê, pressão ou sensor de temperatura. A variante 2 pode ser configuradapara direcionar preocupações específica tornadas relevantes pela variantede fabricação específica do dispositivo, pela configuração particular do dis-positivo com base no modo de uso determinado pelas exigências de aplica-ção (isto é, valores de escalonamento) ou por uma confluência de fatores,que criam preocupações específicas não mencionadas até agora.
Os GDMs de infra-estrutura 86 direcionam questões recorrentesespecíficas que são independentes da aplicação da arquitetura do sistemada figura 1. Eles podem ser reutilizados através de uma pluralidade de apa-relhos, tais como refrigeradores, fogões, máquinas de lavar louças, secado-ras, máquinas de lavar roupas, etc; Os GDMs de infra-estrutura podem serclassificados em pelo menos duas variantes. A variante 1 é associada comuma consulta particular resultante de uma combinação recorrente de com-ponentes 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 de cor-rente elétrica e estado estacionário ou outra restrição, como os exemplos demodo de conversão de analógico para digital, dos quais são laços de corren-te de 4 - 20mA vs. realimentações de tensão analógica de O - 5V. A variante2 está associada com aparelho e componentes de softwares independentesde aplicação conhecidos como funções de utilidade. . Eles proporcionamlógica usada por outros componentes de 16B, incluindo 59 e 80. A variante 2pode conter ou usar referências à Variante 1 de 86. Exemplos incluem tem-porizadores, detecção de passagem por zero e outros componentes úteis desoftware, cuja finalidade é mais utilitária do que acionada por exigências deaplicaçã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 componentes compre-endidos pela camada de abstração de hardware 80, DAQ 30, outro caso delógica de aplicação 59 ou componente na mesma, ou qualquer outro compo-nente útil 16B são minimizados ou eliminados.
Um componente de software 16B, usado por outros componen-tes de software 16B para obter referências a quaisquer outros componentesde software 16B, onde 16B obtido pode ser parte de um ambiente operacio-nal de software 16A, existente em ou no: mesmo componente de hardware16, um componente de hardware diferente 16, conectado por 14, um com-ponente de hardware diferente 22 conectado por uma combinação de seg-mentos de rede, incluindo 14 ou um componente de hardware diferente 16de um aparelho diferente 12, conectado por 14, uma combinação de seg-mentos de rede diferentes entre as duas ocorrências de 12 e 14 do primeiroaparelho 12.
O componente de software 72 também proporciona os meca-nismos para outros componentes de software residentes dentro do mesmoambiente operacional de software 16A para publicar a identificação necessá-ria e/ ou informação de roteamento na memória de 72 de modo a permitir osusos enumerados antes mencionados de 72. A informação de identificação eroteamento pode ser associada com os componentes residentes dentro domesmo ambiente operacional de software ou a informação de identificação eroteamento pode ser associado com componentes à parte os componentesresidentes dentro do mesmo ambiente operacional de software, mas sãoconhecidos por componentes residentes dentro do mesmo ambiente opera-cional 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 de28, 28A ou 82, correspondente a uma ocorrência de um componente desoftware, tais como componentes dentro de 80, 59 ou qualquer outro com-ponente útil de software, localizado nas enumerações antes mencionadas de72 e a capacidade para rotear a informação para aquele componente desoftware ou para um componente de software intermediário apropriado, ten-do a mesma ou finalidade 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 baseem consultas de descoberta contendo solicitações para acesso aos compo-nentes específicos de software 16B, que são identificáveis e giráveis, invo-cações implicando no referido acesso ou por componentes de software 16Bque são capazes de invocar em 70, em nome de si mesmos ou de outroscomponentes 16B, resultando na criação e na povoação das estruturas 74.
Colaboração 1: um comando é emitido por componente de soft-ware 59 do ambiente operacional de software direito 16A e recebido por umcomponente de software contido na coleção de 74 com um identificador deAPI 1 dentro do componente 70 do mesmo ambiente operacional de softwa-re. Usando a identificação e a informação de roteamento contida dentro de70, o componente identificado por API 1 transmite a informação recebidaatravés das outras camadas de operação de software locais 40 e 14A e fi-nalmente transmitida através de 14 e recebida por 14A do ambiente opera-cional de software 16A esquerdo. A mensagem é, então, manipulada por 10e roteada para o componente apropriado dentro de 74 do ambiente opera-cional de software esquerdo. O 74 apropriado do componente operacionalde software esquerdo, usando informação de identificação e roteamentocontida dentro de 70 do mesmo componente operacional de software, então,invoca ou envia a mensagem para a implementação local de API 1 contidana camada de abstração de hardware de ambientes operacionais de softwa-re esquerdo 80. Desse modo, a lógica de aplicação dentro do componentede software 59 do ambiente operacional de software direito invocou umafunção implementada no ambiente operacional de software do lado esquerdosem informação nele contida para a realização da referida invocação. Por-tanto, o valor do desenho implicado pela figura 14 é que a lógica de aplica-ção 59 é reutilizável com relação à localização dos outros componentes deoperação de software 16B dentro de uma pluralidade de ambientes opera-cionais de software 16A conectados por uma rede 14 ou uma pluralidade desegmentos de rede, que podem incluir 14.
Colaboração 2: Neste caso, a iniciação da mensagem é de 59do ambiente operacional de software esquerdo 16A. É ilustrado o caso ondea invocação final está em um componente de software (neste caso API 2)dentro do mesmo ambiente operacional de software, usando a mesma me-todologia descrita em maiores detalhes na Colaboração 1. Portanto, na Co-laboração 2, uma disposição arquitetônica alternativa entre uma ocorrênciade lógica de Aplicação 59 para um outro componente útil de software (API2de Camada de abstração de Hardware 80) é mostrada para não ter efeitosobre a implementação de ambos. E, além disso, é a finalidade do compo-nente de software 70, também sendo capaz de cumprir com as exigênciasde Identificação e Interface impostas pela arquitetura de software 10, a fimde proporcionar essa capacidade.
As colaborações de 3 - 6 mostram usos adicionais para o Rote-ador Virtual Embutido 70. Os mecanismos usados para realizar essas vari-antes 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 mensa-gens adicionais esperados a estarem disponíveis com relação ao DAQ 30.Ouvintes de eventos locais (3) e ouvintes de eventos remotos (4) de Lógicade Aplicação 59 são dotados de uma interconexão para uma representaçãodo agente de DAQ 30, proporcionando não só uma conexão ao DAQ no am-biente 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 transmitidas local-mente (6) e remotamente (5) através de mecanismos disponíveis em 70.
A figura 15 é uma ilustração esquemática de um aparelho atípicoconstruído usando a arquitetura de 12 e compreendendo um nó de persis-tência 54, incorporado como um componente compreendendo a arquiteturade software 10 da figura 1, de acordo com a invenção. Enquanto o estado datécnica em sistemas embutidos é proporcionar local de persistência de da-dos para PCB, o nó de persistência de acordo com a presente invenção pro-porciona 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, sem fio,WIDE, etc.) são mostrados dentro dos componentes de cada cliente que secomunicam uns com os outros ao longo de uma rede interna em cada com-ponente 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 to-dos os componentes 16 compartilhando uma rede 14, 20 ou uma conexãode tempo de execução. Essa entidade proporcionará serviços e mecanismosde protocolo necessários para ler, escrever e armazenar informação.
Como discutido acima, os aparelhos 12 são máquinas acionadasde "estado" e, tipicamente, têm uma interface de usuário (por exemplo, umteclado) usando que um usuário pode efetuar uma mudança no estado doaparelho 12 (por exemplo, mudar uma lavadora de um estado inativo paraum estado de "lavagem"). Como são desenvolvidas aplicações que reque-rem comunicação externa com um aparelho 12 (por exemplo, testagem, di-agnóstico, controle remoto, etc), há três técnicas possíveis para realizar essainterface: 1) transformação dos comandos externos em compressões de te-cla (ver a figura 16 e a discussão); (2) uso de software personalizado paraexecutar comandos de mudança de estado (veja a figura 16 e discussão); ou(3) traduzir, simplesmente, compressões de tecla em uma API lógica (veja afigura 17 e discussão).
A figura 16 é uma ilustração esquemática de um método da téc-nica 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 deuma ou mais compressões de tecla 56 para mudar o estado do aparelho (re-ferido na figura 16 como uma "máquina de estado" 12) para afetar a funcio-nalidade 58 do aparelho. A fim de testar a funcionalidade 58 do aparelho, ousuário preparará comandos externos 60 e (1) traduzirá os comandos exter-nos 60 em compressões de tecla 56; ou (2) preparar software personalizado62, que emularia 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, afigura 17 é uma ilustração esquemática da interação de compressões detecla 56 iniciadas pelo usuário e comandos de software alimentados exter-namente 60, tipicamente de um cliente, são ambos passados como argu-mentos para a arquitetura de software 10 da figura 1 de acordo com a inven-ção, para emissão de comandos para um aparelho eletrodoméstico 12 para,por exemplo, testar a funcionalidade 58 de aparelho eletrodoméstico e/ oumudar o estado (isto é, operação real) do aparelho eletrodoméstico 12.
O método discutido com relação à figura 17 é novo, porque, emlugar de traduzir mensagens externas, tratando o aparelho 12 como um sis-tema fechado, ele expõe a funcionalidade do aparelho 12, independente-mente de se a mensagem é recebida como uma key press externa ou umcomando de software local ou remoto em relação ao aparelho 12. As men-sagens (comandos) são processadas através de uma API da arquitetura desoftware 10 (agora um sistema aberto, conforme oposto ao sistema "fecha-do" da técnica anterior), enquanto preservando a validação e a realimenta-ção para o usuário.
Correntemente, o software de controle de aparelho não estápreparado para validar e executar comandos externos. Para remediar isso,uma API de aparelho é definida que inclui funcionalidade de usuário, bemcomo comandos de controle de máquina de nível baixo. Durante operaçõesnormais, quando uma chave é passada ou um comando externo é emitido,ele é mapeado diretamente para uma chamada de função de API de funcio-nalidade de usuário como um ponto de entrada comum (por exemplo, umatecla WASH é 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). Todo comporta-mento de validação e baseado em estado existirá no interior dessa função,de modo que comandos externos são tratados com a mesma finalidade eexecutarã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á-rio precisará ser reorganizado para chamar funções de API como o ponto deentrada para qualquer comando, em Iugarde apenas reagir às compressõesde tecia no interior da máquina de estado 12. O uso desse método da figura17 permite a fabricação de um aparelho 12 para testar e diagnosticar a inter-face, separadamente. Isso poupa tempo e esforço no desenvolvimento, di-agnose e testagem de aparelhos. Isso também eliminará a necessidade dedispositivos mecânicos complexos de atuação de teclado, bem como chico-tes de atuação mecânica que foram usados convencionalmente para testarinterfaces de usuários e funcionalidade de aparelho. Além disso, a API de aparelho 12 contém um comando para en-viar o aparelho em um modo de teste diagnóstico ou de fábrica. Neste modo,todo código de validação de comportamento e comando com base em esta-do é 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 ou-tros atuadores, etc.
A interface de API discutida com relação à arquitetura de softwa-re 10 é um pacote de software orientado em objeto, que é efetivo quando umobjeto (funcionalidade de aparelho) tem múltiplos clientes que precisam inte-ragir com ele (por exemplo, compressões de tecla 56 e comandos externos60). Essa é uma nova abordagem porque aparelhos não contêm, corrente-mente, software orientado em objeto e são, em geral, considerados comosendo um sistema fechado e tendo apenas um cliente: teclas de interface deusuário. A presente invenção considera que os aparelhos 12 terão muitosclientes através da introdução de um barramento de comunicação interno(isto é, a rede 14) e conectividade externa 20. Esses clientes podem incluiraplicações da web, ferramentas de diagnostico, ferramentas de testagem esistemas de automação domésticos, entre outros.
Os aparelhos 12 com a arquitetura de software de API aqui des-critos serão "à prova de futuro" e prontos para muitas aplicações remotasavançadas, que os consumidores podem solicitar. Essas podem incluir ge-renciamento de energia, ferramentas aperfeiçoadas de serviços e diagnósti-cos e controle remoto e monitoração. Além disso, uma vez que a API é oponto de entrada em toda a funcionalidade de aparelho, os consumidorespodem se beneficiar da testagem aperfeiçoada de desenvolvimento automa-tizado e testagem de fábrica de aparelhos 12.
A arquitetura de software 10 também considera que o modelo dedispositivo virtual pode ter ciência das capacidades correntes do dispositivofísico (o aparelho 12). Por exemplo, se um forno estiver assando, o relógiodo aparelho não pode ser modificado. A sincronização de capacidades éuma solução geral para permitir a um modelo virtual reconhecer mudançasnas capacidades de um dispositivo com base em seu estado.
Correntemente, essa finalidade é alcançada através de códigoque é escrito por aparelho 12. A solução contida na arquitetura de software10 substitui 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áriosó pode modificar aquelas características de dispositivo que são modificá-veis, de modo que ao consumidor não é dada a oportunidade de modificaruma característica de dispositivo que é correntemente imutável, conformeditado pelo dispositivo real.A arquitetura de software 10 é um sistema de produto vetorial deaplicações e ferramentas. Essas aplicações ajudam a aumentar a qualidadee a velocidade de comercialização no processo de desenvolvimento de pro-duto. 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, asaplicaçõ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 podemse mover em torno e assumir um significado muito diferente. A fim de resol-ver esse problema, um padrão e gerador de arquivos de mapas de variáveisforam criados.
O gerador de arquivos de mapas de variáveis toma os nomes desoftware (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 es-sa informação em um formato de arquivo padrão. Isso é executado cada vezque o código é mudado e compilado. A informação nesse arquivo padrãoproporciona independência do compilador e de onde os dados estão locali-zados na memória.
O arquivo de mapas de variáveis é, então, lido por qualquer apli-cação que deseje interagir com um aparelho 12 baseado em arquitetura desoftware 10. As aplicações são codificadas contra os nomes textuais signifi-cativos de dados, em lugar dos endereços numéricos de dados, o que sim-plifica grandemente o desenvolvimento da aplicação.
O formato de arquivo de mapa de variáveis e o processo de usosão descritos na tabela abaixo.
<table>table see original document page 118</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 em novaslocalizações dos dados de aplicação significativos.
3. Um engenheiro compila o novo código de aparelho, que tam-bé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áveis ade-quados.
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 de de-senvolvimento precisa apenas lembrar a coluna "Nome de Variável", na ta-bela 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 aparelho eletrodomésti-co 12, que é mostrado como um forno para fins exemplificativos, tendo umbarramento de comunicação interno 200, pode ser acoplado eletricamente auma rede externa 202 através de um cartão de interface de rede (NIC) 204similar ao conector de interface de rede 20, antes mencionado. Um NIC éum dispositivo bem conhecido que conecta um computador ou outro clientea uma rede e qualquer NIC adequado pode ser utilizado com o aparelho 12.
De acordo com uma modalidade da invenção, o NIC 204 é conectado eletri-camente ao barramento de comunicação interno 200 e adapta um protocolode barramento de comunicação interno a um protocolo de comunicação pa-drão, tal como TCP/IP e GSM, de modo que o aparelho 12 pode se comuni-car com um cliente externo (não mostrado) através da rede externa 202, talcomo uma rede de área local (LAN) e/ ou uma rede de área estendida(WAN). Desse modo, o cliente externo pode se comunicar com a arquiteturade software 10 associada com vários componentes internos do aparelho 12,que residem na rede interna 14. Por exemplo, o aparelho 12 na figura 18 émostrado como compreendendo uma interface de usuário (UI) 208 e um pai-nel sensor -atuador 210, cada um compreendendo um painel de circuito im-presso (PCB), com a arquitetura de software 10 correspondente e o clienteexterno pode se comunicar com a arquitetura de software 10 através do NIC204.
O NIC 204 pode ser montado no barramento de comunicação200, o qual é, de preferência, exposto externamente, do aparelho 12 atravésde qualquer meio de montagem adequado, como é bem conhecido na técni-ca de rede 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 comouma parede traseira 216, do aparelho 12, conforme mostrado na figura 18.Quando o barramento de comunicação 200 está localizado dentro da reen-trância 212, o barramento de comunicação 200 e o NIC 204, quando monta-dos no barramento de comunicação 200, são protegidos de danos que po-dem ocorrer durante o transporte do aparelho 12.
O NIC 204 pode ser dotado do aparelho 12 no momento de fa-bricação ou pode ser comprado separadamente do aparelho 12 como umacessório. Desse modo, um consumidor pode escolher comprar o aparelho12, sem a capacidade de se conectar à rede externa 202 e atualizar o apare-lho 12 em 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 se co-municar com a rede externa 202 por intermédio de comunicações de infra-vermelho sem fio (IR) ou outro meio sem fio de curto alcance. Nessas situa-ções, o NIC 204 é montado, de preferência, em um lado frontal 218 do apa-relho 12 para facilitar uma comunicação forte. De acordo com uma modali-dade da invenção, o NIC 204 pode ser montado em uma reentrância 220 nolado frontal 218 do aparelho, conforme ilustrado na figurai 9 com relação aum forno, por exemplo. Quando montado no lado frontal 218 do aparelho, oNIC 204 pode ser conectado a um lado traseiro 222 do aparelho via fios dis-postos em um conduto de fiação 224, que se estende da reentrância demontagem 220 no lado frontal 218 ao lado traseiro 222 do aparelho 12, ondeos fios entram no aparelho 12, onde os fios entram no aparelho 12.
Outro exemplo de comunicação sem fio é a comunicação de ra-diofreqüência (RF). Por exemplo, o painel de circuito impresso de RF (PCB)226 e uma antena montada externamente. De modo alternativo, o PCB deRF 226 pode ser montado externamente do aparelho 12, mas essa configu-ração requer uma conexão elétrica entre o PCB de RF 226 e componenteseletrônicos de controle de aparelho e um instalador deve abrir um gabineteou caixa 228 do aparelho 12 durante instalação do PCB de RF 226. De a-cordo com uma modalidade da invenção, o PCB de RF 226 é montado den-tro do aparelho 12 e uma barreira de segurança não metálica 230, que é umcondutor pobre de calor e eletricidade, é proporcionada como parte da caixa228. Uma barreira de segurança exemplíficativa 230 é uma janela plástica,tal como uma janela de Plexiglas, integrada com a caixa de aparelho 228,conforme mostrado na figura 20 para um aparelho 12 na forma de um fornopara fins ilustrativo. A barreira de segurança 230 permite a comunicação deRF com o PCB de RF 226, montado internamente, sem uma antena externae impede o contato humano com calor ou eletricidade excessiva.
Fazendo referência à figura 21, o aparelho 12 pode ser configu-rado com hardware para facilitar serviço e diagnóstico do aparelho 12. Emuma modalidade, um módulo de serviço 232, adaptado para conectar remo-vivelmente com um barramento de comunicação padrão no aparelho 12 éconfigurado para registrar dados de diagnóstico, tais como por meio de co-municaçã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 conectadoa um 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 e car-rega os dados de diagnóstico para um cliente remoto (não mostrado), con-forme indicado pela etapa 3 na figura 21. O cliente remoto processo os da-dos de diagnóstico para identificar um problema ou falha do aparelho e im-pedir, 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 chama-da de serviço. Opcionalmente, o módulo de serviço 232 pode baixar scriptsde testagem personalizados com base nos dados de diagnóstico para exe-cutar testes no aparelho 12, a fim de nova diagnose ou eliminar o problemaou falha. 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 21 A. O módulo de serviço 232 com-preende 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 opos-ta para conexão ao aparelho 12 e, particularmente, à arquitetura de software10, residente em vários nós da rede interna 14 do aparelho. O módulo deserviço 232 ainda compreende a memória 240, tal como uma memória flash,para armazenamento dos dados de diagnóstico, dos scripts de testagem, ede outros dados. A memória flash 240 se comunica com uma lógica de ser-viço 242, que controla a operação do módulo de serviço 232.
A figura 22 ilustra uma arquitetura de hardware alternativa paraserviço e diagnóstico do aparelho 12. Essa arquitetura é similar àquela mos-trada 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 cone-xã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 compu-tador pessoal ou não têm um computador pessoal conectado à Internet. Oprocesso para a obtenção de dados diagnósticos é o mesmo que aqueledescrito acima com relação à figura 21; contudo, em lugar de conectar omódulo de serviço 232 ao computador pessoal 234, o usuário conecta o mó-dulo de serviço 232 a uma tomada telefônica padrão 246 e o módulo de ser-viço 232 se conecta, automaticamente, à Internet através da linha telefônica244.
Fazendo referência agora à figura 22A, o módulo de serviço 232para uso com o sistema mostrado na figura 22 é similar ao módulo de servi-ço 232, ilustrado na figura 21 A, exceto que a USB 236 é substituída por umatomada de linha telefônica 248, tal como uma tomada de RJ11 para conexãode um modem250 do módulo de serviço 232232 com a linha telefônica 244para 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, quando mon-tado no aparelho 12. O expositor pode comunicar vários dados para o usuá-rio, incluindo, mas não limitado aos mesmos, dados, tais como estado ope-racional, 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 fins 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-ção de intempéries 252 também pode incluir uma ou mais almofadas de to-que ou uma tela de toque 256, com áreas seletoras 254 para controlar váriasoperações do refrigerador, como para controlar um distribuidor de gelo euma luz 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, é usadapara comunicação, quando a carga útil da mensagem é maior do que a doprotocolo subjacente. Essa estrutura de pacote de fragmentação foi previa-mente descrita na integridade da mensagem de múltiplas cargas úteis con-cernentes discutidas; contudo, um breve resumo pode ser aqui relacionado.
Em uma mensagem fragmentada, a estrutura de pacote padrão, descrita nafigura 4 é, de preferência, usada no primeiro fragmento. Todos os fragmen-tos subseqüentes , de preferência, usam a estrutura de pacote descrita nafigura 24. 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 a inte-gridade de mensagem de múltiplas cargas úteis.
A figura 25 proporciona operações de exemplo do protocolo defragmentação discutido dadas na figura 24. A explanação desse protocolopode ser encontrada na seção de integridade de mensagem de múltiplascargas úteis.
As figuras 26A e 26B representam arquiteturas alternativas paralocalização da informação de endereço e de Identificador de modo que men-sagens 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 ilus-tra um exemplo de uso do esquema de aquisição de dados configuradospelo cliente em que o cliente (computador ou outro cliente) retém um mapade memória corrente, que relaciona um nome de variável a sua localizaçãode memória. Esse endereço de memória, além do Identificador (Id de API eOp Code), é usado para construir uma mensagem bem formada, que é envi-ada para DAQ. Como, nesse caso, o software de DAQ realiza a tarefa adi-cional de aquisição da localização de memória da variável especificada peloIdentificador. Uma vez adquirida, a DAQ usa as mesmas chamadas de fun-ção referenciadas no caso prévio da figura 26A para criar as estruturas deeventos no arranjo de DAQ de estruturas de evento contidas na heap dememória de DAQs.
Informação de mapa de variáveis na figura 26A relaciona nomessimbólicos de variáveis aos seus endereços na memória de 16A. A figura26B relaciona Identificadores de variáveis (Id de API) aos seus endereços namemória 16. A razão para as arquiteturas alternativas é que essas suportaminterações com um ator humano que poderia achar desvantajoso trabalharem nomes simbólicos (que tendem a ser significativos e a se comunicar coma utilidade da variável) e interações com outras instancias da arquitetura desoftware 10 ou algum componente 16 ou 22 ou algum outro componente desoftware que é capaz de interagir com arquitetura de software 10. Em intera-ções baseadas em software (interações não humanas) é vantajoso não usarnomes simbólicos visto que eles requerem mais memória para armazenar,mais largura de banda para transmitir e mais ciclos computacionais paraprocessar. Na verdade, identificadores numéricos podem ser substitutos pa-ra nomes simbólicos. A arquitetura de software 10 usa o ID de API de identi-ficador numérico e Op Codes como substitutos numéricos para nomes sim-bólicos. Identificação numérica adicional está disponível para qualquer ocor-rência válida de Id de API. Onde a identificação numérica prévia é suficientepara proporcionar um índice único por componente 16 residente na rede 14e onde a ultima, a informação de identificação adicional pode ser obtida u-sando 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çãonumérica adicional (a última), proporcionam identificação única dentro datotalidade de componentes de software possíveis, capazes de serem repre-sentados dentro da arquitetura de software 10.A figura 27 proporciona um exemplo de uso do esquema de a-quisição de dados configurado pelo cliente, usando o mapa de variáveis em-butido. Aqui, o Nó A registra um evento no Nó B usando X de API conhecidopublicamente 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 Op Code Y.Como o par de API e Op Code foram previamente registrados pelo Nó A, asolicitação do Nó C é rejeitada. Contudo, o Nó C, então, solicita dados domapa de variáveis remotas (embutidas) com o comando de Dados de Variá-veis Remotas obtido. Nó B responde com informação, incluindo o endereçode memória de variável desejado. O Nó C, então, usa esse endereço dememória para registrar um evento, mas esse tempo com um par diferente deAPI e Op Code.
A figura 27 também pode ser pensada como divulgando doiscenários de mensagens referentes à criação de eventos sugerida na figura26B. O primeiro cenário descreve as Mensagens entre os Nós A e B1 ambosos quais 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ário des-creve as mensagens entre os Nós C e B1 ambos os quais se comunicamatravés da rede de comunicação interna 14 e são compatíveis com arquitetu-ra de 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 responde a-propriadamente, 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 a DynamicMemoryHe-ap da figura 33 de arquitetura de software 10 do Nó B.
A figura 28 ilustra a funcionalidade de notificação de evento con-figurável proporcionada pela presente invenção. De preferência, eventos sónotificarão clientes externos quando disparados por falha. Contudo, pode serdesejado que essa notificação externa tenha "som diminuído" em algunsmomentos sem remover realmente o evento do agente de DAQ 30. Adicio-nalmente, pode ser desejado que a aplicação interna dentro da arquiteturade software 10 seja notificada, quando um evento ocorre. Desse modo, apresente invenção proporciona essa funcionalidade. Como previamente dis-cutido, notificação externa pode ser alterada usando o comando Set ExternaiEvent On/Off dentro de API de DAQ. Adicionalmente, a arquitetura de soft-ware 10, de preferência, proporciona uma função interna para ligar e desligara notificação interna. A figura 28 mostra exemplos de notificações de even-tos segundo as configurações possíveis.
Dessa maneira, a invenção tem a capacidade de desativar e rea-tivar a realização de NVOEvents da figura 33 na rede de comunicação inter-na 14. Além disso, a capacidade para desativar e reativar a realização dosNVOEvents da figura33 como mensagens internas enviadas para o compo-nente de software 16B dentro do mesmo ambiente operacional de software16A 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 de reco-nhecimento do cliente até o processamento do evento seguinte. Se o tempopré-determinado expira, um número pré-determinado de repetidas tentativasé executado. De preferência, todos os eventos são supostos serem não re-conhecidos por falha. Desse modo, após enviar um evento para o(s) clien-te(s), o agente de DAQ 30 imediatamente processa o evento seguinte. Con-tudo, 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 even-tos reconhecidos é que é o solicitante que determina a necessidade do re-conhecimento de acordo com as exigências de aplicação. Portanto, quandoo solicitante cria o evento usando os mecanismos proporcionados pela arqui-tetura de software 10 dentro da interface para DAQ 30, informação é incluídana mensagem 28A, o que proporciona uma outra classificação do eventocomo reconhecido ou não reconhecido. Conforme mostrado no exemplo nafigura 29, com a ocorrência de um evento reconhecido, a arquitetura desoftware bloqueia todos os outros eventos, enquanto espera por um reco-nhecimento do cliente. Se nenhum reconhecimento for recebido, a arquitetu-ra de software 10 re-enviará o evento após uma quantidade de tempo confi-gurá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 vol-ta de falha.
A figura 30 ilustra as características de segurança proporciona-das dentro da presente invenção. Como a execução de funções críticas pe-los nós externos é possível através dos protocolos previamente descritos, apresente invenção proporciona um mecanismo de barreira de proteção pararestringir o acesso à execução do comando. Comandos que são considera-dos críticos para a segurança podem ser relacionados em uma tabela, depreferência, no arquivo SAVriabIeMap.h, antes da compilação. Os comandospodem ser relacionados especificamente (com uma API e Op Code) ou co-mo APIs totais (com uma API específica e um Op Code — OxFF). Os coman-dos relacionados nesta tabela são reivindicados estarem atrás do firewafl.Conforme mostrado na figura 30, a invenção proporciona três níveis de a-cesso de segurança: Acesso Negado, Acesso Concedido e Acesso Conce-dido 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 ape-nas executar os comandos na frente do firewall. Desse modo, os comandosatrás do 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 Acesso Concedi-do. Nesse nível de acesso, é permitido ao nó executar todos os comandos,na frente e atrás do firewall. Para acesso temporário atrás do firewall, um nópode submeter com sucesso uma senha de acesso temporário (dentro dacarga útil da mensagem de realimentação de Publicar Nó). Nesse nível deacesso, é dado ao nó acesso a todos os comandos, na frente e atrás do fi-rewall, para uma quantidade de tempo configurá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 quan-do a mensagem de API de DAQ, publicar Nó de SA, é difundida (veja bytes3 e 4 ou Op Code 2). Uma das senhas representa acesso permanente a to-dos os comandos especiais que são considerados estarem atrás do firewall.A segunda senha concederá acesso temporário a todos os comandos espe-ciais que são considerados estarem atrás do firewall. Sem uma senha, osclientes terão acesso a todos os comandos que são considerados estaremna frente do firewall. O engenheiro responsável pela instalação da arquitetu-ra de software 10 em um componente 16 do aparelho eletrodoméstico 12determinará que comandos estão na frente e que comandos estão atrás dofirewall 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, con-forme mostrado, se um nó sem acesso tenta executar um comando de bar-reira de proteção, será rejeitado. Após uma submissão incorreta de senha, ocomando de barreira de proteção ainda será rejeitado. Apenas após umasubmissão de senha bem sucedida é permitido ao nó executar o comandode barreira de proteção.
A figura 32 ilustra as interfaces públicas padrão que a arquiteturade software 10 é capaz de implementar. É mostrada a ApplicationSpecificA-Pl (API Específica de Aplicação), que é ainda povoada com funcionalidadeútil pelo programador de acordo com as necessidades da aplicação. Tam-bém é mostrado um exemplo de associações com outros componentes desoftware do ambiente operacional de software com que a arquitetura desoftware 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 figura32. Também são mostradas classes auxiliares (Command Handlert DynamicMemory Heap, Update Handler1 NVOEvent, TimeHandIer, WIDECommHan-dler, Message Parser e appSpecificCommandHandler), que mostram o a-grupamento funcional das funções internas e alocações de memória neces-sárias. Também estão mostradas associações entre as classes auxiliares.
A figura 34 mostra a organização preferida de arquivos de códi-go 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 (COMMJDLE,COMM_EXPECTING_ACK e COMM_PENDING), com cada estado, possi-velmente, tendo uma pluralidade de sub-estados e assim por diante. A fun-cionalidade representada aqui está relacionada com as associações de co-laboraçã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 (mos-trado na figura 33 e na figura 11) invoca SA_WideComm() mostrado na defi-nição de classe de SA (onde SA e sua funcionalidade agregada é a arquite-tura de software 10). O resultado da invocação de função é mostrado na fi-gura 35. Conforme mostrado na figura 11, MAIN invoca SA_WideComm()periodicamente dentro da execução de sistemas operacionais de software.
A figura 35 mostra uma 2a interação indireta com MAIN que é oresultado de MAIN invocando na função WIDE WIDE_EXEC(). Essa colabo-ração é mostrada na figura 11 e na figura 35. Nesse caso, a camada de ope-ração de software WIDE 14A dentro da invocação da função WIDE_EXEC()chama WIDE.BuildDATAQ, 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, essa tran-sição de estado é realizada pela invocação da função WI-DE. Queue.Message(). Essa invocação resulta na invocação da lógica conti-da dentro do estado COMM_PENDING da figura 35.
O estado COMM_EXPECTING_ACK da figura 35 é um resultadode um evento de saída tendo sido criado, inicialmente, com um reconheci-mento de denotação de indicador especial requerido. Se o evento (tambémreferido como atualização) que está sendo operado dentro do estadoCOMM_PENDlNG requer reconhecimento, a transição de estado deCOMM_PENDING será para COMM_EXPECTING_ACK. Nesse caso, o e-vento será reenviado, pela re-introdução do estado COMM_PENDING, seum tempo tiver expirado sem o recebimento da mensagem de Reconheci-mento esperada. Esse processo será repetido até que um Reconhecimentoseja recebido ou até que o parâmetro de repetição configurável(MAX_EVENT_RETRY, que é incrementado cada vez que o evento é re-transmitido) é excedido.
A figura 36 mostra uma coleção de diagramas de estado de UMLinter-relacionados. São mostrados quatro estados primários (READY,TRANSMIT SNAPSHOT, UPDATES_BLOCKED e PRO-CESS_DAQ_EVENTS). A funcionalidade aqui representada está relacionadacom as associações de colaboração mostradas na figura 33. Sua invocaçãotambém é referenciada na figura 11 como uma das funções de interface pa-drão invocadas do laço de execução MAIN 11 do ambiente operacional desoftware 16A na arquitetura de software 10.
O propósito da funcionalidade representada pela figura 36 é ava-liar as estruturas (NVOEvent) 31 da figura 33, determinando se as condiçõespara a transmissão de evento ocorreram, coletando aquelas e ajustando osindicadores apropriados (Updates_Pending & Bounded Update) de modoque, quando as Máquinas de Estado de 35 estão executando, condições deeventos detectadas pela DAQ 30 são realizadas como WIDE Packets 20 nobarramento 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 arquitetu-ra de software 10, onde MAIN chama SA.SA_ProcesslncomingEvents(). Es-sas máquinas de estado inter-relacionadas governam a execução de co-mandos de entrada, respostas para solicitações e a manipulação de even-tos.
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 co-mum de lógica referenciado como "Send WIDE Message", nas figuras 39,40, 41 e 42. A invocação de MAIN e WIDE (via WIDE_EXEC() é mostradana 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 ambiente ope-racional de software 16A contendo a arquitetura de software 10. A invocaçãode MAIN é mostrada na figura 11. O diagrama ilustra as mensagens requeri-das para adicionar uma estrutura bem formada de memória de NVOEvent àDynamicMemoryHeap.
A figura 40 mostra uma coleção ordenada de mensagens dasclasses na figura 33 do ambiente operacional de software. Essas mensa-gens representam uma interação dentro de um ambiente operacional desoftware 16A contendo a arquitetura de software 10. O diagrama ilustra aexecução de mensagem da figura 37. E a invocação de MAIN é mostrada nafigura 11.0 propósito da funcionalidade representada pelo diagrama é avali-ar as estruturas de memória de NVOEvent contidas dentro de DynamicMe-moryHeap, coletar aquelas e seus valores de dados apropriados cujos crité-rios de disparo de evento foram satisfeitos e assegurar uma realização depacotes 24 na rede de comunicação interna 14 para fins de notificação deoutros clientes 16/22 dos NVOEvents que satisfizeram critérios de disparo eos valores de dados associados.
As figuras 41, 42 e 43 mostram uma coleção ordenada de men-sagens 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 operacionalde software contendo a arquitetura de software 10. As invocações de MAINe WIDE (via WIDE_EXEC()) são mostradas na figura 11. As figuras, descri-tas individualmente em parágrafos subseqüentes, representam 3 casos decursos alternados para execução.
A figura 41 ilustra o serviço de mensagens requerido para pro-cessar mensagens de entrada da rede de comunicação interna 14 dos clien-tes 22/16 que não requerem uma resposta [Command-NoResponse], con-tendo outros dados significativos que não uma resposta transmitindo o su-cesso 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 para pro-cessar mensagens que entram do barramento WIDE 14 dos clientes 22/16,que requerem uma pluralidade de mensagens de resposta [Command-MultipIeResponseRequired], contendo dados significativos em adição a umaresposta que transmite o sucesso ou a razão para falha da mensagem queentra (o ACK ou NAK de ID de API = 1, Op Code = 1).
A figura 43 ilustra o serviço de mensagens requerido para pro-cessar mensagens que entram da rede de comunicação interna 14 dos clien-tes 22/16, que requerem mensagens de respostas simples {Command-SingIeResponseRequerid], contendo dados significativos em adição a umaresposta que transmite o sucesso ou a razão para falha da mensagem queentra (o ACK ou NAK de ID de API = 1, Op Code = 1).
Controle de TaxonomiaUma 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 do controla-dor de aparelho, de modo que o novo dispositivo de controle não solicita,inadvertidamente, ao componente de software do controlador do aparelhopara realizar uma operação da qual ele é incapaz. Essa abordagem da téc-nica anterior ainda requer comunicações entre o aparelho 12 e o novo dis-positivo de controle com referência ao estado corrente do aparelho 12. Aabordagem da técnica anterior é ineficiente, uma vez que requer a duplica-ção de lógica no novo dispositivo de controle e no controlador de aparelho.Além disso, essa abordagem da técnica anterior requer que o novo softwareseja escrito a cada vez que o controlador de aparelho é introduzido no novodispositivo de controle.
A finalidade de uma taxonomia de controle é evitar requerer es-sa duplicação de lógica de software (freqüentemente chamada lógica de ne-gócios) entre dois componentes de software inter-atuantes em um dispositi-vo de controle e um aparelho controlado. Em particular, isso permite a umgerador de comando em um dispositivo de controle controlar prontamenteuma porção articulada 50, sem qualquer informação a cerca do aparelho queestá sendo controlado, exceto a própria taxonomia de controle. Isso podepermitir a introdução de um dispositivo de controle "genérico" para controlarnovos aparelhos, adaptando dispositivos de controle a ciclos ou funcionali-dades recentemente disponíveis, que foram adicionados a um aparelho eaparelhos de comutação entre modos de operação onde ciclos operacionaisdiferentes ou funcionalidades estão disponíveis. Também torna o controledos aparelhos mais fáceis para os usuários uma vez que eles precisam ape-nas 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 fimde gerar um comando bem formado para o aparelho. Como aqui usado, umcomando bem formado é um comando que tem significado e é realizávelpelo aparelho. A informação transportada pelo conjunto de dados inclui umahierarquia de opções e entradas de dados requeridas para formar o coman-do bem formado. Na modalidade preferida, também inclui informação se-mântica ou contextual para comunicar em palavras ou forma icônica as op-ções disponíveis de modo que um usuário pode compreender as escolhasdisponíveis e introduzir os dados apropriados. Isso é realizado, de preferên-cia, por rótulos dentro do conjunto de dados que estão associados com ele-mentos de identificação arbitrários ou propícios a não usuários. Isso permiteque a lógica do componente de software que deve interpretar e processar aTaxonomia a ser desacoplada da apresentação da Taxonomia em uma inter-face 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. O disposi-tivo de controle 16, 22 pode ser uma interface de usuário programável, talcomo um pda, uma tabela da web, um telefone celular, um LCD anexado aoaparelho ou um dispositivo de cliente.
A arquitetura de taxonomia, mostrada disposta no controlador deaparelho 16 e lógica, pode, alternativamente, ser disposta em uma localiza-ção remota, tal como em um dispositivo de controle ou na internet. A arquite-tura de taxonomia inclui um gerador de taxonomia, um agente de taxonomia,um tradutor de taxonomia e uma estrutura de taxonomia. A arquitetura detaxonomia gera um conjunto de dados de taxonomia, definindo capacidadesde taxonomia, facilitando: a criação, pelo componente de software 1, de co-mandos bem formados que podem ser transformados pelo agente de taxo-nomia e, opcionalmente, o tradutor de taxonomia em outros comandos bemformados a serem executados pelo componente de software 2; a criação,pelo componente de software 1, do conteúdo de interface de usuário; e avalidação de informação de estado antes de apresentar a interface de usuá-rio. Cada um desses componentes e suas inter-relações são descritas emmaiores 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 permi-tir que o gerador de comandos no componente de software 1 interprete oconjunto de dados para realizar diversos resultados. Mais particularmente,de vez 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 de taxo-nomia 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 uma es-trutura 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 estru-tura de dados, ela pode ser transmitida e retransmitida para clientes 16 ou22, conforme requerido. Mudanças no conjunto de dados de taxonomia ocor-rem á medida que os ciclos de operação progridem e os comandos disponí-veis ou os valores válidos de seus argumentos mudam. Além disso, coman-dos adicionais podem se tornar disponíveis ou podem ser tornar inválidosenquanto o ciclo de operação progride de Idle (Inativo) (ver a figura 7).
Mais particularmente, o construtor da seleção registra com o Ge-renciador de Taxonomia para receber notificações para novos Agentes deTaxonomia. Em resposta, o Gerenciador de Taxonomia passa referênciaspara todos os Agentes de Taxonomia de volta para o construtor de seleção.O construtor 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 de Controla-dor de Componente de Software 2 ou, alternativamente, um Documento paragerar um Conjunto de Dados de Capacidades de Taxonomia. O construtorda seleção, então, povoa um conjunto de estruturas de pseudo comandos,que são uma hierarquia de opções, apropriadas para um Ponto Final de A-plicação (Exemplos de Pontos Finais de Aplicação são as interfaces de usu-ários para controle ou serviço ou outras camadas de aplicação intermediá-rias como um controlador de energia ou modo de automação doméstica co-mo férias ou boa noite) e passa aquelas estruturas para o Ponto Final deAplicação, permitindo que o Ponto Final de Aplicação seja configurado. Al-ternativamente, o construtor de seleção pode configurar diretamente o pontofinal 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 o com-ponente de software 1 e a arquitetura de taxonomia, permitindo ao geradorde comandos consultar a existência de conjunto de dados de taxonomia,proporcionando à arquitetura de software 1 acesso a um conjunto de dadosde taxonomia e permitindo ao gerador de comando e intérprete de estadoassinarem atualizações de conjunto de dados de taxonomia. O Tradutor deTaxonomia é um componente opcional que traduz os conjuntos de dados deTaxonomia 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 mes-ma modalidade do conjunto de dados de Taxonomia.
O conjunto de dados de taxonomia é comunicado ao controladorde componente de software 2 e para o construtor de seleção de componentede software 1. Opcionalmente, o tradutor de taxonomia traduz o conjunto dedados de taxonomia para uma definição esquemática diferente do geradorde comando.
O gerador de comando usa o conjunto de dados de taxonomiapara construir e povoar estruturas de comandos disponíveis para a seleçãopor uma interface de usuário ou outras aplicações de cliente, compreenden-do um conjunto de comandos válidos, seus argumentos válidos e cada umargumenta valores válidos. Mais particularmente, o gerador de comandosusa o conjunto de dados de taxonomia para construir um ou mais comandosbem formados, que podem, então, ser transmitidos para o controlador Umavez que o conjunto de dados de taxonomia pode ser reajustado e enviadoem diferentes momentos pelo agente de taxonomia ou o conjunto de dadospode ser atualizado por meio de revisões do agente de taxonomia, o Com-ponente de Software 1 pode ter um conjunto corrente de estruturas de co-mando, então, disponível para seleção por uma interface de usuário ou outraaplicação do cliente.
Desse modo, em essência, através do uso da arquitetura de Ta-xonomia, o componente de software 2 ou seu proxy (o agente de taxonomia)comunica ao componente de software 1 um conjunto de regras que podemser interpretadas pelo componente de software 1, de modo que o componen-te de software 1 não solicita algo do componente de software 2, componentede software 2 que não pode acomodar e não opera em uma variável de es-tado 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ér-prete de Estado. Isso permitirá que o Ponto Final de Aplicação a ser povoa-do com variáveis de estado válido do Gerador de Estado antes que a lógicaseja executada e antes que o componente de interface de usuário seja pro-cessado. O Intérprete de Estado processará taxonomicamente conjuntos dedados de estado corretos e validam aqueles conjuntos de dados contra oConjunto de Dados de Capacidades de Taxonomia. O Intérprete de Estadosolicita ou registra atualizações de estado do Gerador de Estado do Compo-nente de software 2 através do Agente de Taxonomia. Com o recebimentode um estado taxonomicamente correto, o Intérprete de Estado proporciona-rá novos valores de estado para o ponto finai do aplicativo.
O Ponto Final de Aplicação executa, resultando em um proces-samento do estado corrente de componente de software 2 e um processa-mento de estruturas de pseudo comandos selecionáveis. Cada vez que umaseleçã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-ção adicional pelo ponto final de aplicação. Quando uma seleção completa éfeita, uma estrutura contendo todos os pseudo comandos é passada para ogerador de 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ésdo Agente de Taxonomia.
Execução
O comando bem formado é distribuído para o controlador do a-parelho 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áuma atualização de estado criado pelo Gerador de Estado e resultando emnovos processamentos de estado para o ponto final de aplicação . Essa mu-dança no estado resultará em uma nova Taxonomia de Capacidades ou umaTaxonomia de Capacidades parcial que podem substituir porções da Taxo-nomia de Capacidades original. A nova Taxonomia de Capacidades resul-tando em um conjunto de diferente de seleções válidas para controlar osciclos de operação do 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 Taxonomiaou Tradutor do Gerador de Estado. Além disso, a Estrutura de Taxonomia,que é a fonte do conjunto de dados de Taxonomia, permite ao controladorvalidar completamente os comandos de entrada de acordo com a estrutura,sem lógica adicional fora do conjunto de dados. Por exemplo, a Estrutura detaxonomia pode ser pensada conceitualmente como uma ou múltiplas árvo-res de decisão, com cada nível da taxonomia formando um ramo de decisãodiferente ou conjunto de ramos de decisão, onde cada uma das opções e/ ouentradas de dados pode formar um nível diferente. Os ciclos de operação deum aparelho requerem que o usuário selecione as opções e/ ou entradas dedados na formação do comando bem formado. Essas seleções podem sercomparadas com a árvore de decisão para confirmar cada ciclo, atributo deciclo ou opção de ciclo é encontrado dentro do ramo apropriado na árvore dedecisão para confirmar que cada ciclo, atributo de ciclo ou opção de ciclo éencontrado dentro da ramificação apropriada na árvore de decisão. Se o ci-clo de operação esperado , atributo e opções não são encontrados dentro docomando, então, é uma indicação de que o comando contém um erro. A es-trutura de taxonomia, assim, serve para povoar a interface de usuário comopções e entradas de dados disponíveis para um dado estado do aparelho etambém serve como a lógica para validar o comando resultante.
O conjunto de dados de taxonomia é uma representação de da-dos 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 componentes inter-conectados pela rede interna. Cada um dos componentes pode ter um oumais dispositivos. Cada um dos dispositivos tem uma ou mais funcionalida-des, que tem uma ou mais configurações. Todas as funcionalidades paratodos os dispositivos, necessariamente, não estarão disponíveis durante ca-da estado do aparelho. Como tal, o conjunto de dados de taxonomia com-preenderá todas as opções e entradas de dados para todos os dispositivosque estão disponíveis correntemente.
As figuras 45 - 48 ilustram um exemplo do controle de Taxono-mia no contexto de uma interface de usuário 16, 22 para uma microonda queé povoada com um conjunto de dados de taxonomia, indicando as funçõesdisponíveis do aparelho para o estado corrente. O usuário pode selecionardos parâmetros do conjunto de dados para formar o comando bem formadoque 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 exemplos ilus-trativos. 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, oní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 interfa-ce de usuário, então, mostra entradas de dados na forma de TIME 102 ePOWER LEVEL 104, disponíveis para aquela opção e necessárias para for-mar o comando 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 bem for-mado. As entradas de dados na forma de peso 108 e o nível de desconge-Iamento 110 são expostos e devem ser selecionados para completar o co-mando 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áo mesmo para o Componente de Software 2 no componente do aparelhopara implementação. Isso é feito apenas após o comando bem formado terpassado através do processo de validação. O controlador e a lógica doComponente de Software 2, então, usa o comando bem formado para con-trolar a operação dos dispositivos para efetuar o comando bem formado.
Um exemplo detalhado da criação do conjunto de dados de ta-xonomia 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 XML, como segue:<device id="microwave" IabeI=nMicrowave Oven"><device id="ovenCavity" IabeI=ltMicrowave Oven"><char name="cycle" IabeI=nCycIe" default="timedCook"><setting name="timedCook" IabeH1COOK" /><char name="tumtable" label="Turntable" default="on"><setting name="on" label="ON" />
<setting name="off label="OFF" />
</char>
<range name="duration" label- Ouration" default="30"units="seconds"
max="6039" min=n60" inc="1"/>
<range name="power" label=nPower Level" default="100"units="%"
max="100" min="50n inc="10" />
</setting>
<setting name="jetdefrost" label="Jet Defrost"/>
<char name =foodType label -'Food Type/>
<setting Pame="poultiy" label="POULTRY" />
<setting name="meat" label="MEAT" />
<setting name="fish" label="FISH"/>
</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 coman-do bem formado do esquema Taxônomico será transmitido, opcionalmente,para o Tradutor de Taxonomia e para a Taxonomia. O comando da forma:
<command id=" microwave ">
<device id="ovenCavity">
<sequence>
<step id="21"><char name=Mcycle" setting="bake7><char name-'power" setting="907><char name=nduration" setting="307><char name="turntable" setting="on"/></step></sequence></device></command>
O Agente de Taxonomia, então, atravessará a Estrutura de Ta-xonomia para transformar o comando bem formado do esquema Taxonômi-co em um comando bem formado do Controlador de Componente de Soft-ware 2 da estrutura de pacote 28. A Estrutura de Taxonomia é um super-conjunto do Conjunto de Dados de Capacidades de Taxonomia. Para cadaelemento de comando especificável acima (isto é, Ciclo, Potência, Duração ePrato Girável) uma coleção adicional de palavras chave e valores necessá-rios para formar a Carga Útil 28A será associada dentro da Estrutura de Ta-xonomia. Essas palavras chave incluirão Id de API1 Op Code e índice de Po-sição na Carga útil 28A, onde índice de Posição poderia ser um deslocamen-to de bytes ou um deslocamento de bits.
O Conjunto de Dados de Taxonomia poderia ser construído pararepresentar diretamente o universo de comandos possíveis das APIs da ar-quitetura de software 10, proporcionando funcionalidade útil para um enge-nheiro ou técnico de serviço ou de laboratório.
Embora a invenção tenha sido descrita especificamente em co-nexão com certas modalidades específicas da mesma, deve ser compreen-dido que isso é à guisa de ilustração e não de limitação e o escopo das rei-vindicações anexas será construído tão amplamente quanto a técnica ante-rior permitirá.

Claims (12)

1. Aparelho (12) configurado para executar um ciclo de operaçãopara completar uma operação física em um artigo, caracterizado por:- pelo menos um componente (16), capaz de ser interligado emrede e capaz de ser operável por um comando de rede enviado de um se-gundo componente (16);- o referido pelo menos um componente (16) compreendendouma arquitetura de software (10) compreendendo pelo menos um elementode software e configurado para gerar uma pluralidade de mensagens emuma rede e configurado para permitir a transmissão de pelo menos uma dapluralidade de mensagens na rede;- onde a arquitetura de software (10) fornece um firewall (figura-30) para restringir a execução de comandos pelo referido pelo menos umcomponente (16) recebidos por mensagem do segundo componente (16) narede.
2. Aparelho de acordo com a reivindicação 1, caracterizado pelofato de que o segundo componente (22) deve comunicar uma senha parapermitir a execução de comandos subseqüentes por parte do referido pelomenos um componente.
3. Aparelho de acordo com a reivindicação 2, caracterizado pelofato de que o firewall compreende uma tabela de comandos que o referidopelo menos um componente (16) pode executar sem uma senha.
4. Aparelho de acordo com a reivindicação 1, caracterizado pelofato de que o firewall provê três níveis de acesso pelo referido segundocomponente: negado, concedido, e temporariamente concedido.
5. Aparelho de acordo com a reivindicação 4, caracterizado pelofato de que ao segundo componente (22) será permitido o acesso pleno atodos os comandos a partir da publicação e da aceitação de uma senhapermanente.
6. Aparelho de acordo com a reivindicação 4, caracterizado pelofato de que ao segundo componente (22) será permitido o acesso pleno atodos os comandos por um período limitado após a publicação e a aceitaçãode uma senha temporária.
7. Aparelho de acordo com a reivindicação 1, caracterizado pelofato de que o segundo componente (22) pode obter acesso a um comandorestrito pela publicação de uma senha em uma mensagem pela rede.
8. Rede de aparelho que compreende um aparelho (12) configu-rado para executar um ciclo de operação para completar uma operação físi-ca em um artigo, o aparelho caracterizado por:- pelo menos um componente (16) interligado em uma rede a umacessório (204, 232, 252) e capaz de ser operável por um comando de redeenviado a partir do acessório (204, 232, 252);- o referido pelo menos um componente (16) compreendendouma arquitetura de software (10) compreendendo pelo menos um elementode software e configurado para gerar uma pluralidade de mensagens na re-de e configurado para permitir a transmissão de pelo menos uma da plurali-dade de mensagens na rede;- onde a arquitetura de software (10) provê um firewall para res-tringir a execução de comandos pelo referido pelo menos um componente(16) recebidos por mensagem do acessório (204, 232, 252) na rede.
9. Rede de aparelho de acordo com a reivindicação 8, caracteri-zada pelo fato de que o firewall é composto por uma tabela de comandosque o acessório (204, 232, 252) pode acessar sem uma senha.
10. Rede de aparelho de acordo com a reivindicação 8, caracte-rizada pelo fato de que o firewall oferece três níveis de acesso pelo acessó-rio (204, 232, 252): negado, concedido, e temporariamente concedido.
11. Rede de aparelho de acordo com a reivindicação 10, carac-terizada pelo fato de que ao acessório (204, 232, 252) será permitido o a-cesso pleno a todos os comandos após a publicação e aceitação de umasenha permanente.
12. Rede de aparelho de acordo com a reivindicação 10, carac-terizada pelo fato de que ao acessório (204, 232, 252) será permitido o a-cesso pleno a todos os comandos por um tempo limitado a partir da publica-ção e aceitação de uma senha temporária.
BRPI0622274-9A 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 BRPI0622274A2 (pt)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US59514805P 2005-06-09 2005-06-09

Publications (1)

Publication Number Publication Date
BRPI0622274A2 true BRPI0622274A2 (pt) 2011-08-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
BRPI0622273-0A BRPI0622273A2 (pt) 2005-06-09 2006-06-08 sistema de rede compreendendo um processador e pelo menos dois nós
BRPI0611726-0A BRPI0611726A2 (pt) 2005-06-09 2006-06-08 aparelho para realizar um ciclo de operação útil em um artigo fìsico
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 After (4)

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
BRPI0611726-0A BRPI0611726A2 (pt) 2005-06-09 2006-06-08 aparelho para realizar um ciclo de operação útil em um artigo fìsico
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) EP2247067B1 (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
US7917914B2 (en) 2005-06-09 2011-03-29 Whirlpool Corporation Event notification system for an appliance
US8615332B2 (en) 2005-06-09 2013-12-24 Whirlpool Corporation Smart current attenuator for energy conservation in appliances
US9103061B2 (en) 2006-06-08 2015-08-11 Whirlpool Corporation Product service system and method
US8533253B2 (en) 2005-06-09 2013-09-10 Whirlpool Corporation Distributed object-oriented appliance control system
US20070288331A1 (en) 2006-06-08 2007-12-13 Whirlpool Corporation Product demonstration system and method
US20080137670A1 (en) * 2005-06-09 2008-06-12 Whirlpool Corporation Network System with Message Binding for Appliances
US8005780B2 (en) 2005-06-09 2011-08-23 Whirlpool Corporation Taxonomy engine and dataset for operating an appliance
US8155120B2 (en) 2005-06-09 2012-04-10 Whirlpool Corporation Software architecture system and method for discovering components within an appliance using fuctionality identifiers
US9009811B2 (en) 2005-06-09 2015-04-14 Whirlpool Corporation Network system with electronic credentials and authentication for appliances
US9164867B2 (en) * 2005-06-09 2015-10-20 Whirlpool Corporation Network for communicating information related to a consumable to an appliance
US8856036B2 (en) 2005-06-09 2014-10-07 Whirlpool Corporation Method of providing product demonstrations
US7921429B2 (en) 2005-06-09 2011-04-05 Whirlpool Corporation Data acquisition method with event notification for an appliance
US9122788B2 (en) * 2005-06-09 2015-09-01 Whirlpool Corporation Appliance network for a networked appliance with a network binder accessory
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
EP2247067B1 (en) 2005-06-09 2016-05-11 Whirlpool Corporation Appliance with embedded virtual router
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
US8676656B2 (en) * 2005-06-09 2014-03-18 Whirlpool Corporation Method for product demonstration
US8816828B2 (en) * 2005-06-09 2014-08-26 Whirlpool Corporation Recipe wand and recipe book for use with a networked appliance
US8442042B2 (en) 2005-06-09 2013-05-14 Whirlpool Corporation Appliance and a consumable holder with an embedded virtual router
US7831321B2 (en) * 2005-06-09 2010-11-09 Whirlpool Corporation Appliance and accessory for controlling a cycle of operation
US7813831B2 (en) 2005-06-09 2010-10-12 Whirlpool Corporation Software architecture system and method for operating an appliance in multiple operating modes
US8250163B2 (en) * 2005-06-09 2012-08-21 Whirlpool Corporation Smart coupling device
US8571942B2 (en) 2005-06-09 2013-10-29 Whirlpool Corporation Method of product demonstration
US8027752B2 (en) 2005-06-09 2011-09-27 Whirlpool Corporation Network for changing resource consumption in an appliance
DE602005021555D1 (de) * 2005-07-04 2010-07-08 Vkr Holding As System und verfahren zur befehlsausführungs-handhabung
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
US8042355B2 (en) 2006-12-28 2011-10-25 Whirlpool Corporation Temporary refrigerator storage modules
US8061153B2 (en) 2006-12-28 2011-11-22 Whirlpool Corporation Refrigeration appliance with optional storage module
US8161760B2 (en) 2006-12-28 2012-04-24 Whirlpool Corporation Utilities grid for distributed refrigeration system
US8245524B2 (en) 2006-12-28 2012-08-21 Whirlpool Corporation Thermal cascade system for distributed household refrigeration system
US8336322B2 (en) 2006-12-28 2012-12-25 Whirlpool Corporation Distributed refrigeration system with optional storage module and controller
US8336321B2 (en) 2006-12-28 2012-12-25 Whirlpool Corporation Hybrid multi-evaporator central cooling system for modular kitchen
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
US7707459B2 (en) 2007-03-08 2010-04-27 Whirlpool Corporation Embedded systems debugging
KR100888478B1 (ko) * 2007-03-08 2009-03-12 삼성전자주식회사 액션 처리 방법, 피제어 장치의 제어 방법, 피제어 장치 및제어 포인트
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
US20090083060A1 (en) * 2007-09-26 2009-03-26 Modu Ltd. Automated computer electronics device 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
US8419433B2 (en) * 2008-04-15 2013-04-16 International Business Machines Corporation Monitoring recipe preparation using interactive cooking device
US8342847B2 (en) * 2008-04-15 2013-01-01 International Business Machines Corporation Interactive recipe preparation instruction delivery to disabled indiviuals
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
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
US8532273B2 (en) * 2008-04-29 2013-09-10 Lg Electronics Inc. Home appliance and home appliance system
EP2277280A4 (en) * 2008-04-29 2011-11-16 Lg Electronics Inc HOUSEHOLD APPLIANCE AND SYSTEM FOR HOUSEHOLD APPLIANCE
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 노바 콘트롤스 분배 시스템용 조절기
US8275471B2 (en) 2009-11-06 2012-09-25 Adura Technologies, Inc. Sensor interface for wireless control
US20100114340A1 (en) 2008-06-02 2010-05-06 Charles Huizenga Automatic provisioning of wireless control systems
US7839017B2 (en) * 2009-03-02 2010-11-23 Adura Technologies, Inc. Systems and methods for remotely controlling an electrical load
US8364325B2 (en) 2008-06-02 2013-01-29 Adura Technologies, Inc. Intelligence in distributed lighting control devices
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
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
US8118997B2 (en) * 2008-10-23 2012-02-21 Whirlpool Corporation Smart filter for an appliance
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
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
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
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
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
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
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
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
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
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
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
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
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
WO2010088218A1 (en) * 2009-01-29 2010-08-05 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
US8601465B2 (en) 2009-09-08 2013-12-03 Abbott Diabetes Care Inc. Methods and articles of manufacture for hosting a safety critical application on an uncontrolled data processing device
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
KR20100112948A (ko) * 2009-04-10 2010-10-20 엘지전자 주식회사 가전기기 진단시스템 및 그 진단방법
KR101442115B1 (ko) * 2009-04-10 2014-09-18 엘지전자 주식회사 가전기기 및 가전기기 시스템
KR101421685B1 (ko) * 2009-04-10 2014-08-13 엘지전자 주식회사 가전기기 진단시스템 및 그 진단방법
KR101555586B1 (ko) * 2009-04-10 2015-09-24 엘지전자 주식회사 가전기기
KR101579481B1 (ko) * 2009-04-10 2015-12-22 엘지전자 주식회사 가전기기 진단시스템 및 그 진단방법
US8565079B2 (en) * 2009-04-10 2013-10-22 Lg Electronics Inc. Home appliance and home appliance system
KR101597523B1 (ko) * 2009-04-10 2016-02-25 엘지전자 주식회사 가전기기 서비스 장치 및 그 제어방법
KR101563487B1 (ko) 2009-05-11 2015-10-27 엘지전자 주식회사 가전기기를 제어하는 휴대 단말기
KR101556972B1 (ko) * 2009-05-11 2015-10-02 엘지전자 주식회사 세탁기를 제어하는 휴대 단말기 및 그 동작 방법
CN102474420B (zh) 2009-07-06 2014-12-17 Lg电子株式会社 家电诊断系统及其操作方法
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
US8855830B2 (en) 2009-08-21 2014-10-07 Allure Energy, Inc. Energy management system and method
US20110029658A1 (en) * 2009-07-24 2011-02-03 Theodore Werth System and methods for providing a multi-device, multi-service platform via a client agent
KR20110010374A (ko) 2009-07-24 2011-02-01 엘지전자 주식회사 가전기기 진단시스템 및 그 방법
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
KR101482137B1 (ko) * 2009-07-31 2015-01-13 엘지전자 주식회사 가전기기 진단시스템 및 그 진단방법
KR20110013582A (ko) * 2009-07-31 2011-02-10 엘지전자 주식회사 가전기기 진단시스템 및 그 진단방법
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 엘지전자 주식회사 가전기기 진단시스템 및 그 진단방법
KR101607891B1 (ko) * 2009-07-31 2016-04-11 엘지전자 주식회사 가전기기 진단시스템 및 그 진단방법
EP2462719B1 (en) * 2009-08-05 2020-09-30 LG Electronics Inc. Home appliance and method for operating the same
US9209652B2 (en) 2009-08-21 2015-12-08 Allure Energy, Inc. Mobile device with scalable map interface for zone based energy management
US8498749B2 (en) 2009-08-21 2013-07-30 Allure Energy, Inc. Method for zone based energy management system with scalable map interface
US9838255B2 (en) 2009-08-21 2017-12-05 Samsung Electronics Co., Ltd. Mobile demand response energy management system with proximity control
MX2012002832A (es) * 2009-09-10 2012-04-19 Bp Corp North America Inc Sistemas y metodos para circular hacia afuera un caudal de perforacion de pozo en ambiente de gradiente dual.
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 이상원 조리 상태 감시 시스템 및 방법
AU2010322810B8 (en) 2009-11-26 2015-02-26 Lg Electronics Inc. Network system for a component
US8995301B1 (en) 2009-12-07 2015-03-31 Amazon Technologies, Inc. Using virtual networking devices to manage routing cost information
US7937438B1 (en) 2009-12-07 2011-05-03 Amazon Technologies, Inc. Using virtual networking devices to manage external connections
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
US9203747B1 (en) 2009-12-07 2015-12-01 Amazon Technologies, Inc. Providing virtual networking device functionality for managed computer networks
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
WO2011074800A2 (en) * 2009-12-17 2011-06-23 Lg Electronics Inc. Network system and method of controlling network system
WO2011074799A2 (en) * 2009-12-17 2011-06-23 Lg Electronics Inc. Method of controlling network system
US9058037B2 (en) * 2009-12-22 2015-06-16 General Electric Company Return of appliance state after demand response event
US7991859B1 (en) * 2009-12-28 2011-08-02 Amazon Technologies, Inc. Using virtual networking devices to connect managed computer networks
US8224971B1 (en) 2009-12-28 2012-07-17 Amazon Technologies, Inc. Using virtual networking devices and routing information to initiate external actions
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
US20110225327A1 (en) * 2010-03-12 2011-09-15 Spansion Llc Systems and methods for controlling an electronic device
US20110224810A1 (en) * 2010-03-12 2011-09-15 Spansion Llc Home and building automation
WO2011113874A2 (en) * 2010-03-19 2011-09-22 Martin Palzer 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
US9213325B2 (en) * 2010-04-21 2015-12-15 Institut Polytechnique De Grenoble System and method for managing services in a living place
US8650311B2 (en) * 2010-04-22 2014-02-11 Cisco Technology, Inc. Client device configured to connect with a home network
EP2712149B1 (en) 2010-04-23 2019-10-30 Compuverde AB Distributed data storage
WO2011138149A1 (de) * 2010-05-06 2011-11-10 BSH Bosch und Siemens Hausgeräte GmbH Haushaltsgerätevorrichtung
EP2386953B1 (en) * 2010-05-14 2018-02-07 Sap Se Systems and methods for generating reusable test components out of remote application programming interface
US9696773B2 (en) 2010-06-22 2017-07-04 Lg Electronics Inc. Consumption unit for effectively managing energy sources
WO2012001267A1 (fr) * 2010-06-29 2012-01-05 France Telecom Gestion de panne applicative dans un systeme d'equipements domestiques
US10325269B2 (en) 2010-07-06 2019-06-18 Lg Electronics Inc. Home appliance diagnosis system and diagnosis method for same
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 정성민 조리 상태 감시 시스템 및 방법
WO2013023837A2 (en) * 2011-08-18 2013-02-21 Telefonaktiebolaget L M Ericsson (Publ) A method and apparatus for determining an event instance
KR101252167B1 (ko) 2011-08-18 2013-04-05 엘지전자 주식회사 가전기기 진단장치 및 그 진단방법
EP2562967B1 (en) * 2011-08-22 2015-01-14 LG Electronics Inc. Information management system for home appliance
MX342956B (es) 2011-08-30 2016-10-19 Allure Energy Inc Administrador de recursos, sistema y método para comunicar información de administración de recursos para recursos inteligentes de energía y medios.
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
US8645978B2 (en) 2011-09-02 2014-02-04 Compuverde Ab Method for data maintenance
US8769138B2 (en) 2011-09-02 2014-07-01 Compuverde Ab Method for data retrieval from a distributed data storage system
US8997124B2 (en) 2011-09-02 2015-03-31 Compuverde Ab Method for updating data in a distributed data storage system
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
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
WO2013052798A1 (en) * 2011-10-07 2013-04-11 Electrolux Home Products, Inc. Multiple protocol communication system for appliances
US8510762B1 (en) * 2011-10-12 2013-08-13 Google Inc. Generate custom client library samples based on a machine readable API 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
US8981930B2 (en) 2012-02-07 2015-03-17 Scott Andrew Horstemeyer Appliance monitoring systems and methods
US10013677B2 (en) 2012-02-07 2018-07-03 Whirlpool Corporation 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
KR20150005952A (ko) 2012-05-01 2015-01-15 듀크 매뉴팩쳐링 코. Can 버스 상업용 기기 시스템 및 방법
US20130298199A1 (en) * 2012-05-02 2013-11-07 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 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカＰａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ アクセス制御方法、アクセス制御システム、通信端末、及び、サーバ
CN104641620B (zh) * 2012-09-21 2018-06-05 飞利浦灯具控股公司 用于动态地址分配的方法和装置
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 한국전자통신연구원 홈 에너지 관리 서비스 프로비저닝 방법 및 장치
ES2734348T3 (es) 2012-11-07 2019-12-05 Rain Bird Corp Sistema de control de riego
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
US10330713B2 (en) 2012-12-21 2019-06-25 Electro Industries/Gauge Tech Intelligent electronic device having a touch sensitive user interface
CN104854598B (zh) * 2012-12-21 2018-02-13 惠普发展公司，有限责任合伙企业 嵌入在线缆中的有源组件
US20140179222A1 (en) * 2012-12-21 2014-06-26 Vishal Chaudhary Method and system for effective and efficient service support
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
US10282676B2 (en) 2014-10-06 2019-05-07 Fisher-Rosemount Systems, Inc. Automatic signal processing-based learning in a process plant
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
US10649449B2 (en) 2013-03-04 2020-05-12 Fisher-Rosemount Systems, Inc. Distributed industrial performance monitoring and analytics
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
US10909137B2 (en) 2014-10-06 2021-02-02 Fisher-Rosemount Systems, Inc. Streaming data for analytics in process control systems
US10386827B2 (en) 2013-03-04 2019-08-20 Fisher-Rosemount Systems, Inc. Distributed industrial performance monitoring and analytics platform
US9665088B2 (en) 2014-01-31 2017-05-30 Fisher-Rosemount Systems, Inc. Managing big data in process control systems
US9558220B2 (en) 2013-03-04 2017-01-31 Fisher-Rosemount Systems, Inc. Big data in process control systems
US10649424B2 (en) 2013-03-04 2020-05-12 Fisher-Rosemount Systems, Inc. Distributed industrial performance monitoring and analytics
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
US20140263411A1 (en) * 2013-03-15 2014-09-18 The Coca-Cola Company Dispensing Ingredients for Use in Recipes
US11573672B2 (en) 2013-03-15 2023-02-07 Fisher-Rosemount Systems, Inc. Method for initiating or resuming a mobile control session in a process plant
CN107885494B (zh) 2013-03-15 2021-09-10 费希尔-罗斯蒙特系统公司 用于分析过程控制数据的方法和计算机系统
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
US11889009B2 (en) 2013-07-26 2024-01-30 Skybell Technologies Ip, Llc Doorbell communication and electrical systems
US10708404B2 (en) 2014-09-01 2020-07-07 Skybell Technologies Ip, Llc Doorbell communication and electrical systems
US11651665B2 (en) 2013-07-26 2023-05-16 Skybell Technologies Ip, Llc Doorbell communities
US11764990B2 (en) 2013-07-26 2023-09-19 Skybell Technologies Ip, Llc Doorbell communications systems and methods
US20170084132A1 (en) * 2013-07-26 2017-03-23 SkyBell Technologies, Inc. Doorbell communication systems and methods
US20170263067A1 (en) 2014-08-27 2017-09-14 SkyBell Technologies, Inc. Smart lock systems and methods
US11909549B2 (en) 2013-07-26 2024-02-20 Skybell Technologies Ip, Llc Doorbell communication systems and methods
US10672238B2 (en) 2015-06-23 2020-06-02 SkyBell Technologies, Inc. Doorbell communities
US10440165B2 (en) 2013-07-26 2019-10-08 SkyBell Technologies, Inc. Doorbell communication and electrical systems
US20180343141A1 (en) 2015-09-22 2018-11-29 SkyBell Technologies, Inc. Doorbell communication systems and methods
US20150033294A1 (en) * 2013-07-26 2015-01-29 Xtera Communications, Inc. Network management system architecture of a telecommunications network
US20150046703A1 (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
US10015021B2 (en) * 2013-09-16 2018-07-03 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
US10652735B2 (en) 2013-10-04 2020-05-12 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
US9736688B2 (en) 2013-10-04 2017-08-15 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
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
US10129383B2 (en) 2014-01-06 2018-11-13 Samsung Electronics Co., Ltd. Home management system and method
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
CN106796514A (zh) 2014-05-21 2017-05-31 社会创新Ipco有限公司 用于完全可配置的实时处理的系统和方法
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
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
DE102014107163A1 (de) * 2014-05-21 2015-11-26 Vorwerk & Co. Interholding Gmbh Elektrisch betriebenes Haushaltsgerät
US9741244B2 (en) 2014-05-30 2017-08-22 Qualcomm Incorporated Methods, smart objects, and systems for naming and interacting with smart objects
US10412208B1 (en) * 2014-05-30 2019-09-10 Apple Inc. Notification systems for smart band and methods of operation
US9294575B1 (en) 2014-06-04 2016-03-22 Grandios Technologies, Inc. Transmitting appliance-specific content to a user device
US20170085843A1 (en) 2015-09-22 2017-03-23 SkyBell Technologies, Inc. Doorbell communication systems and methods
US11184589B2 (en) 2014-06-23 2021-11-23 Skybell Technologies Ip, Llc 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
KR102422417B1 (ko) 2014-07-07 2022-07-18 브레빌 유에스에이 인코포레이티드 맞춤식 요리 지도 제공 시스템, 물품, 및 방법
US10820750B2 (en) 2014-08-05 2020-11-03 Lynx Grills, Inc. Computer-controlled grills
WO2016037095A1 (en) * 2014-09-04 2016-03-10 Sidhant Gupta 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
US9553843B1 (en) 2014-10-08 2017-01-24 Google Inc. Service directory 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
CN107249403B (zh) 2014-12-22 2021-03-30 布瑞威利美国公司 食物制备指导系统
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
EP3289503B1 (en) * 2015-04-29 2019-12-18 Li, Sol Mingso Methods for programming, controlling and monitoring wireless networks
MX2017013964A (es) 2015-05-01 2018-01-18 Hubbell Inc Dispositivos, sistemas y metodos para controlar cargas electricas.
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
CA2993176A1 (en) 2015-07-21 2017-01-26 ChefSteps, Inc. Food preparation control system
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 青岛海尔滚筒洗衣机有限公司 基于二维码的装置使用方法及洗衣机
EP3360014A4 (en) * 2015-10-08 2019-04-24 Ledvance LLC MANAGEMENT AND COMMISSIONING OF MODERNIZED DEVICES
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
CN108351109B (zh) * 2015-11-05 2019-11-22 松下知识产权经营株式会社 加热烹调器
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 엘지전자 주식회사 식기세척기
EP3206095B1 (en) 2016-02-09 2018-06-27 Vorwerk & Co. Interholding GmbH System and method for synchronizing food processing steps of a multi-function cooking apparatus with food processing steps of a remote kitchen appliance
US10503483B2 (en) 2016-02-12 2019-12-10 Fisher-Rosemount Systems, Inc. Rule builder in a process control network
CN108604215B (zh) 2016-02-19 2022-04-05 三星电子株式会社 软件保护器装置和控制该软件保护器装置的方法
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
US11032282B2 (en) * 2016-04-29 2021-06-08 Ncr Corporation Interlinking cross platform authorization and processing
WO2017187396A1 (en) 2016-04-29 2017-11-02 nChain Holdings Limited Implementing logic gate functionality using a blockchain
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
US10498552B2 (en) 2016-06-12 2019-12-03 Apple Inc. Presenting accessory state
US11003147B2 (en) 2016-06-12 2021-05-11 Apple Inc. Automatically grouping accessories
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
US10609878B2 (en) 2016-07-15 2020-04-07 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 四川长虹电器股份有限公司 基于状态机的冰箱主控软件设计方法
US10061285B1 (en) 2017-04-17 2018-08-28 Silicon Valley Factory LLC Encoding a custom cooking program
US10101035B1 (en) 2017-04-17 2018-10-16 Silicon Valley Factory LLC Custom cooking program based on feedback
US10009963B1 (en) 2017-04-17 2018-06-26 Silicon Valley Factory LLC Decoding a custom cooking program
US10070485B1 (en) 2017-04-17 2018-09-04 Silicon Valley Factory LLC Automatic heating system and method
US10120553B1 (en) * 2017-04-17 2018-11-06 Sebastian Thrun User interface and controller for a heating system
RU2720585C1 (ru) * 2017-04-21 2020-05-12 Данфосс А/С Система управления для управления охлаждающей системой
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 佛山市顺德区美的电热电器制造有限公司 加热平台的控制方法、控制系统以及烹饪器具
TW201921891A (zh) * 2017-08-25 2019-06-01 美商促美股份有限公司 確認在通訊匯流排上之元件之系統及方法
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
WO2019077591A1 (en) * 2017-10-20 2019-04-25 Connected Cooking Solutions Private Limited SYSTEM AND METHOD FOR REAL-TIME SYNCHRONIZATION OF A SET OF INSTRUCTIONS USING IDO 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
CN109751630B (zh) * 2017-11-06 2021-06-08 天下父母(北京)科技有限公司 一种超低功耗燃气灶控制方法
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
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 华为技术有限公司 一种数据处理的方法以及相关设备
US11237550B2 (en) 2018-03-28 2022-02-01 Honeywell International Inc. Ultrasonic flow meter prognostics with near real-time condition based uncertainty analysis
IT201800004052A1 (it) * 2018-03-28 2019-09-28 Faber Spa Cappa verticale multifunzione perfezionata per aspirazione domestica
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
EP3783867A1 (en) 2018-05-07 2021-02-24 Google LLC Providing composite graphical assistant interfaces for controlling various connected devices
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 郑州云海信息技术有限公司 一种跟踪导致内存溢出异常的测试系统及方法
CA3108675A1 (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
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
DE102018009944A1 (de) * 2018-12-18 2020-06-18 Diehl Ako Stiftung & Co. Kg Elektronisches Haushaltsgerät mit einem Steuerungssystem
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
US11388072B2 (en) 2019-08-05 2022-07-12 Extrahop Networks, Inc. Correlating network traffic that crosses opaque endpoints
US10742530B1 (en) 2019-08-05 2020-08-11 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
WO2021041354A1 (en) 2019-08-24 2021-03-04 Skybell Technologies Ip, Llc Doorbell communication systems and methods
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
US11593354B2 (en) 2020-05-20 2023-02-28 Snowflake Inc. Namespace-based system-user access of database platforms
US11501010B2 (en) 2020-05-20 2022-11-15 Snowflake Inc. Application-provisioning framework for 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
EP4218212A1 (en) 2020-09-23 2023-08-02 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
WO2022187044A1 (en) * 2021-03-02 2022-09-09 Blendtec, Inc. Cross-reference to related applications
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
WO2023031847A1 (en) * 2021-09-01 2023-03-09 X-Tend Robotics Ltd. 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
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
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
FI100139B (fi) 1988-11-04 1997-09-30 Schneider Electric Sa Rakennuksen teknisten toimintojen valvontalaitteisto
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.
US5999908A (en) * 1992-08-06 1999-12-07 Abelow; Daniel H. Customer-based product design module
US7133834B1 (en) * 1992-08-06 2006-11-07 Ferrara Ethereal Llc Product value information interchange server
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
DE69616917T2 (de) * 1995-08-30 2002-06-06 Motorola Inc Datenprozessor mit eingebauter Emulationsschaltung
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
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
JP3973689B2 (ja) * 1996-02-08 2007-09-12 コーニンクレッカ フィリップス エレクトロニクス エヌ ヴィ セキュリティシステム
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
US6154856A (en) * 1997-04-08 2000-11-28 Advanced Micro Devices, Inc. Debug interface including state machines for timing synchronization and communication
US6094729A (en) * 1997-04-08 2000-07-25 Advanced Micro Devices, Inc. Debug interface including a compact trace record storage
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
WO1998058210A1 (en) 1997-06-19 1998-12-23 Matsushita Electric Industrial Co., Ltd. Cooking device
KR100340253B1 (ko) 1997-06-25 2002-06-12 윤종용 브라우저 기반의 개선된 홈 네트웍 명령 및 제어
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
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
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
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
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
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
EP0948240B1 (en) 1998-03-30 2004-08-25 Sharp Kabushiki Kaisha Cooking apparatus
JP3684832B2 (ja) * 1998-03-31 2005-08-17 セイコーエプソン株式会社 マイクロコンピュータ、電子機器及びデバッグシステム
JP3545256B2 (ja) * 1998-04-17 2004-07-21 松下電器産業株式会社 送信装置及び受信装置
US6847614B2 (en) * 1998-04-20 2005-01-25 Broadcom Corporation 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
US6426947B1 (en) * 1998-10-21 2002-07-30 Kim K. Banker 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
CA2331705C (en) * 1998-05-07 2007-08-07 Samsung Electronics Co., Ltd. Method and apparatus for user and device command and control in a network
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
US6480753B1 (en) * 1998-09-04 2002-11-12 Ncr Corporation Communications, particularly in the domestic environment
EP0992904B1 (en) 1998-10-06 2010-06-09 Texas Instruments Inc. Cache coherence during emulation
AU6421399A (en) * 1998-10-09 2000-05-01 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 松下電器産業株式会社 グラフィカルユーザインタフェース装置
AU2960100A (en) * 1999-01-06 2000-07-24 Robert G. Harrison Appliances with multiple modes of operation
CA2325494A1 (en) * 1999-01-22 2000-07-27 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
DE60007252T2 (de) 1999-03-05 2004-09-16 Amulet Technologies, LLC, Campbell Graphischer benutzerschnittstellentreiber für eingebettete systeme
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
WO2001046804A1 (en) * 1999-08-16 2001-06-28 Z-Force Corporation System of reusable software parts for implementing concurrency and hardware access, 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
AU2295101A (en) * 1999-12-30 2001-07-16 C-Smart Llc Method and apparatus for providing distributed control of a home automation system
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 インターネットを用いた家電機器の模擬実演販売方法
ES2298200T3 (es) * 2000-09-04 2008-05-16 Lg Electronics Inc. Lavadora y procedimiento para modificar los datos del sistema de la misma.
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
EP1209567B1 (en) 2000-11-21 2005-06-29 Siemens Mobile Communications S.p.A. Method and system for real time debugging a source program, particularly for 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
WO2002057917A2 (en) * 2001-01-22 2002-07-25 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
US6715302B2 (en) 2001-07-16 2004-04-06 Maytag Corporation Menu-based control system for refrigerator that predicts order and replace dates for filters
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
US7069468B1 (en) * 2001-11-15 2006-06-27 Xiotech Corporation System and method for re-allocating storage area network resources
US7127633B1 (en) * 2001-11-15 2006-10-24 Xiotech Corporation System and method to failover storage area network targets from one interface to another
US6996741B1 (en) * 2001-11-15 2006-02-07 Xiotech Corporation System and method for redundant communication between redundant controllers
US7003688B1 (en) * 2001-11-15 2006-02-21 Xiotech Corporation System and method for a reserved memory area shared by all redundant storage controllers
US6883065B1 (en) 2001-11-15 2005-04-19 Xiotech Corporation System and method for a redundant communication channel via storage area network back-end
US7043663B1 (en) * 2001-11-15 2006-05-09 Xiotech Corporation System and method to monitor and isolate faults in a storage area network
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
AU2003304166A1 (en) 2002-01-25 2005-01-21 Seurat Company Data integration system and method for presenting 3600 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 家庭電化機器
EP1625499A2 (en) * 2003-05-16 2006-02-15 Sap Ag 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
JPWO2005073450A1 (ja) * 2004-01-29 2007-07-26 松下電器産業株式会社 情報家電システム
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
US9077611B2 (en) * 2004-07-07 2015-07-07 Sciencelogic, Inc. 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
EP1790131B1 (en) * 2004-09-09 2012-12-05 Avaya Inc. Methods of and systems for network traffic security
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
GB2439490B (en) 2005-03-08 2008-12-17 Radio Usa Inc E Systems and methods for modifying power usage
US7236099B2 (en) * 2005-04-01 2007-06-26 Maytag Corporation Household appliance with user interface with bi-colored LEDs
US7995569B2 (en) * 2005-04-01 2011-08-09 Nortel Networks Limited Virtual routers for GMPLS networks
US20060270452A1 (en) * 2005-05-27 2006-11-30 Levy Gerzberg Remote storage of pictures and other data through a mobile telephone network
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
US8005780B2 (en) 2005-06-09 2011-08-23 Whirlpool Corporation Taxonomy engine and dataset for operating 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
US9164867B2 (en) * 2005-06-09 2015-10-20 Whirlpool Corporation Network for communicating information related to a consumable to an appliance
US8155120B2 (en) * 2005-06-09 2012-04-10 Whirlpool Corporation Software architecture system and method for discovering components within an appliance using fuctionality identifiers
EP2247067B1 (en) * 2005-06-09 2016-05-11 Whirlpool Corporation Appliance with embedded virtual router
US8442042B2 (en) * 2005-06-09 2013-05-14 Whirlpool Corporation Appliance and a consumable holder with an embedded virtual router
US20060293788A1 (en) * 2005-06-26 2006-12-28 Pavel Pogodin Robotic floor care appliance with improved remote management
US7353073B2 (en) * 2005-12-01 2008-04-01 Sandisk Corporation Method for managing appliances
US7739078B2 (en) * 2005-12-01 2010-06-15 Sandisk Corporation System 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
US8217781B2 (en) 2012-07-10
WO2006135726A2 (en) 2006-12-21
US20080143490A1 (en) 2008-06-19
MX2008015676A (es) 2009-02-12
BRPI0622273A2 (pt) 2011-08-09
US20090100132A1 (en) 2009-04-16
CA2611527A1 (en) 2006-12-21
US8849430B2 (en) 2014-09-30
US8680983B2 (en) 2014-03-25
CA2611014A1 (en) 2006-12-21
WO2006135771A3 (en) 2007-11-15
US8621049B2 (en) 2013-12-31
EP1889160A2 (en) 2008-02-20
MX2007015681A (es) 2008-02-21
US20080105134A1 (en) 2008-05-08
BRPI0611726A2 (pt) 2010-11-09
WO2006135771A2 (en) 2006-12-21
WO2006135758A1 (en) 2006-12-21
US20080103610A1 (en) 2008-05-01
US8786412B2 (en) 2014-07-22
CN101228741A (zh) 2008-07-23
US9264252B2 (en) 2016-02-16
US20080104208A1 (en) 2008-05-01
BRPI0611640A2 (pt) 2009-01-13
US20080108388A1 (en) 2008-05-08
US20100287059A1 (en) 2010-11-11
US20160134431A1 (en) 2016-05-12
US20080104212A1 (en) 2008-05-01
US8345686B2 (en) 2013-01-01
US7908019B2 (en) 2011-03-15
CA2651012A1 (en) 2006-12-21
US20090132070A1 (en) 2009-05-21
EP2228969A1 (en) 2010-09-15
EP1889405A1 (en) 2008-02-20
US20080157936A1 (en) 2008-07-03
US8028302B2 (en) 2011-09-27
EP2244443A1 (en) 2010-10-27
US7808368B2 (en) 2010-10-05
US20080109830A1 (en) 2008-05-08
BRPI0621758A2 (pt) 2011-12-20
US9124444B2 (en) 2015-09-01
WO2006135726A8 (en) 2008-05-02
EP2027544A2 (en) 2009-02-25
EP2247067A1 (en) 2010-11-03
US20080125912A1 (en) 2008-05-29
EP2027544A4 (en) 2010-07-07
US20080122648A1 (en) 2008-05-29
US20090103535A1 (en) 2009-04-23
EP2228969B1 (en) 2017-04-19
US20090100153A1 (en) 2009-04-16
US20080287121A1 (en) 2008-11-20
US8040234B2 (en) 2011-10-18
CN101305350A (zh) 2008-11-12
US20080140862A1 (en) 2008-06-12
EP2247067B1 (en) 2016-05-11

Similar Documents

Publication Publication Date Title
BRPI0622274A2 (pt) aparelho configurado para executar um ciclo de operação para completar uma operação fìsica em um artigo e rede de aparelho
US8155120B2 (en) Software architecture system and method for discovering components within an appliance using fuctionality identifiers
US7813831B2 (en) Software architecture system and method for operating an appliance in multiple operating modes
US7917914B2 (en) Event notification system for an appliance
US9401822B2 (en) Software architecture system and method for operating an appliance exposing key press functionality to a network
US8533253B2 (en) Distributed object-oriented appliance control system
US8005780B2 (en) Taxonomy engine and dataset for operating an appliance
US9009811B2 (en) Network system with electronic credentials and authentication for appliances
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
B03A Publication of a patent application or of a certificate of addition of invention [chapter 3.1 patent gazette]
B07A Application suspended after technical examination (opinion) [chapter 7.1 patent gazette]
B08F Application dismissed because of non-payment of annual fees [chapter 8.6 patent gazette]
B08K Patent lapsed as no evidence of payment of the annual fee has been furnished to inpi [chapter 8.11 patent gazette]

Free format text: REFERENTE AO DESPACHO 8.6 PUBLICADO NA RPI 2467 DE 17/04/2018.