BR112016009081B1

BR112016009081B1 - Tecnologia de segurança da comunicação serial de elevador

Info

Publication number: BR112016009081B1
Application number: BR112016009081-0A
Authority: BR
Inventors: Christopher Taylor; Charlie Thurmond; Fabio Speggiorin
Original assignee: Thyssenkrupp Elevator Ag
Priority date: 2013-10-25
Filing date: 2014-10-23
Publication date: 2022-10-18
Also published as: US9452909B2; CN105764825B; BR112016009081A2; US20150114764A1; EP3060507A1; WO2015059565A1; EP3060507B1; CN105764825A; ES2908606T3; CA2926769A1

Abstract

TECNOLOGIA DE SEGURANÇA DA COMUNICAÇÃO SERIAL DE ELEVADOR. Informação de segurança para uma instalação de elevador pode ser transmitida através de uma conexão serial que usa módulos de serialização e deserialização. Estes módulos de serialização e deserialização podem incluir componentes redundantes, tais como processadores e interfaces, e podem estar configurados para verificar várias entradas e saídas de dados para identificar corrupção de dados, falhas de componentes ou inconsistências em dados.

Description

[001] CAMPO

[002] A tecnologia apresentada pertence à transmissão de informação de segurança em uma instalação de elevador.

[003] ANTECEDENTES

[004] A capacidade para operar em segurança é crítica para qualquer instalação de elevador. Como resultado, as modernas instalações de elevador são concebidas para permitirem a recolha de uma quantidade substancial de informação relacionada com os carros que contêm, e para usar essa informação de modo a assegurar que os carros do elevador operem de modo seguro. Apesar de esta recolha e utilização de informação de segurança ser benéfica na manutenção da segurança dos carros de elevador, tem também desvantagens. Por exemplo, quando a informação de segurança é recolhida e processada em diferentes componentes, essa informação tem estado historicamente a comunicar a partir do(s) componente(s) de recolha para o(s) componente(s) de processamento com fios discretos para cada peça de informação recolhida. Isto geralmente resulta na utilização de 10-15 fios discretos para a comunicação de informação de segurança, que aumenta o custo da instalação de elevador, tanto em termos do custo do material dos fios como do custo do trabalho para instalá- los.

[005] RESUMO

[006] A tecnologia aqui apresentada pode ser usada para implementar um sistema de comunicação de informação de segurança que inclui um dispositivo de entrada e um dispositivo de saída. Em um sistema de comunicação desse tipo, o dispositivo de entrada inclui um módulo de comunicação e uma primeira série de microcontroladores, enquanto o dispositivo de saída inclui várias interfaces periféricas seriais e uma segunda série de microcontroladores. Quando estão presentes, uma primeira série de microcontroladores de um dispositivo de entrada pode incluir microcontroladores que estão, cada um, configurados para periodicamente receberem vários itens de dados de segurança para um carro de elevador, criar um primeiro pacote de dados e enviar o primeiro pacote de dados para o módulo de comunicação. O módulo de comunicação, por sua vez, pode ser configurado para transmitir o primeiro pacote de dados ao dispositivo de saída em um formato serial. Uma segunda série de microcontroladores em um dispositivo de saída também pode incluir microcontroladores que estão, cada um, configurados para realizar um conjunto de tarefas. Por exemplo, um conjunto de tarefas que os microcontroladores da segunda série de microcontroladores podiam estar configurados para realizar podia incluir receber o primeiro pacote de dados, procurar erros no primeiro pacote de dados, criar um segundo pacote de dados e enviar o segundo pacote de dados para um controlador do elevador através das várias interfaces periféricas seriais.

[007] Em um sistema tal como o acima descrito, o dispositivo de entrada pode estar configurado para verificar os dados de segurança de entre os microcontroladores da primeira série de microcontroladores que o dispositivo de entrada inclui. Adicionalmente, em um sistema desses, um primeiro pacote de dados criado pelos microcontroladores que o dispositivo de entrada inclui podia englobar os vários itens de dados de segurança para o carro de elevador e um código para erros detectado pelo dispositivo de entrada. O segundo pacote de dados criado pelos microcontroladores que o dispositivo de entrada inclui podia englobar os vários itens dos dados de segurança para o carro de elevador, sendo o código para erros detectado pelo primeiro dispositivo de entrada, e um código de erros detectado pelo dispositivo de saída.

[008] Note-se que são também possíveis outras abordagens para implementar a tecnologia do inventor, incluindo em máquinas inovadoras, métodos ou artigos de fabrico ou em sistemas que podem não corresponder ao sistema exemplificativo descrito acima, e essas abordagens ficarão imediatamente claras às pessoas leigas na matéria à luz da apresentação daqui em diante apresentada. Correspondentemente, este resumo deve ser entendido como exemplo apenas de como a tecnologia do inventor pode ser implementada, e não deve ser tratado limitativo da proteção deste documento ou qualquer documento relacionado.

[009] BREVE DESCRIÇÃO DOS DESENHOS

[010] Os desenhos e a descrição detalhada que e segue destinam-se meramente a fins ilustrativos e não pretendem limitar o âmbito da invenção conforme contemplado pelos inventores.

[011] A Figura 1 apresenta uma vista de nível alta de um sistema que pode ser usado para recolher informação de segurança do elevador e transmiti-la através de uma conexão serial.

[012] A Figura 2 ilustra um conjunto exemplificativo de componentes que pode ser usado para implementar um módulo de serialização, tal como é apresentado na Figura 1.

[013] A Figura 3 ilustra um formato exemplificativo que pode ser usado para a transmissão de dados entre o módulo de serialização e o módulo de deserialização em um sistema, tal como se pode ver na Figura 1.

[014] A Figura 4 ilustra um conjunto exemplificativo de componentes que pode ser usado para implementar um módulo de deserialização, tal como é apresentado na Figura 1.

[015] A Figura 5 ilustra um formato exemplificativo que pode ser usado para pacotes de dados comunicados entre um módulo de deserialização e um controlador.

[016] DESCRIÇÃO DETALHADA

[017] Os inventores conceberam tecnologia inovadora que, para efeitos de ilustração, é aqui apresentada conforme aplicada no contexto de comunicar informação de segurança em uma instalação de elevador usando uma conexão serial. Enquanto as aplicações apresentadas da tecnologia do inventor satisfazem uma necessidade há muito sentida mas ainda não satisfeita na arte de comunicar informação de segurança em uma instalação de elevador, entende-se que a tecnologia do inventor não está limitada a ser implementada nos modos exatos que são aqui apresentados, e que há outras implementações que ficarão imediatamente claras aos - e podiam ser implementadas sem a indevida experiência - profissionais na matéria à luz desta apresentação. Correspondentemente, os exemplos adiante apresentados devem ser entendidos como meramente ilustrativos e não devem ser tratados como sendo limitativos.

[018] Agora relativamente às figuras, a Figura 1 apresenta uma vista de nível alta de um sistema que pode ser usado para recolher informação de segurança do elevador e transmiti-la através de uma conexão serial. No sistema da Figura 1, a informação de segurança é recolhida a partir de interruptores [101][102][116] que representam as portas do elevador, interruptores de paragem, interruptores de inspeção e vários outros interruptores baseados na segurança. Por exemplo, um conjunto típico de interruptores podia ser contato porta carro dianteiro (CDCF), contato porta carro traseiro (CDCR), Limite final (FTSD), Interruptor engrenagem de segurança (SAFGR), Interruptor paragem dentro do carro (CST), Interruptor transferência inspeção topo do carro (INCTM), Inspeção topo do carro para cima (INCTU), Inspeção topo do carro para baixo (INCTD), Permitir inspeção topo do carro (INCTE), Interruptor permitir poço do elevador (INHAM), e 7 outros interruptores ligados em série a 1 entrada (SAFCAR) incluindo Interruptor de saída de emergência, Interruptor de extração cadeia como, Interruptor paragem estação pendente, Bloqueio movimento carro, Interruptor paragem topo do carro, Interruptor de paragem topo do carro traseiro e Interruptor de paragem bombeiros. São também possíveis outros interruptores ou combinações de interruptores, e os interruptores especificamente utilizados podem variar de instalação para instalação (p. ex., baseado nos códigos de segurança locais). De igual modo, em alguns casos, a tecnologia do inventor pode ser configurada para ler informação de um grande número de interruptores que estão realmente presentes, podendo o(s) interruptor(es) ausentes ser substituídos por conector(es) com fios.

[019] Um sistema como o tal apresentado na Figura 1 pode também recolher informação de segurança a partir de outros tipos de dispositivos, tal como um ou mais sensores [117] usados para detectar a posição, velocidade e/ou velocidade de um carro de elevador. Esta recolha pode ser conseguida através da utilização de um módulo de serialização [118], que pode estar configurado para ler a informação de segurança a partir dos interruptores [101][102][116] e/ou vários sensores [117], e para enviá-la de forma serial através de um cabo de manobra [119] para um módulo de deserialização [120]. O módulo de deserialização [120] podia estar configurado para, assim que tiver recebido a informação de segurança, deserializar a informação e comunicá-la a um controlador do elevador [121]. Claro que é possível recolher outros tipos de informação de segurança e enviar também ao módulo de deserialização [120]. Por exemplo, em alguns modelos que seguem o diagrama da Figura 1, os sensores externos [117], tal como são apresentados nessa Figura podiam ser sensores de posição absolutos que podiam ser estar configurados para detectar falhas como parte do seu cálculo da posição e velocidade. Nesses modelos, qualquer falha detectada por um sensor externo [117] podia ser enviada para o módulo de serialização [118], a partir do qual podia ser comunicada a, e manuseada por um controlador [121] através do módulo de deserialização [120] de modo idêntico ao descrito aqui para outros tipos de erros.

[020] Preferencialmente, o módulo de serialização [118] será configurado para enviar a informação de segurança através de transmissões que ocorrem a cada 5 ms através de um único cabo de par trançado com um comprimento máximo de 1500 metros, usando um código de não retorno a zero. No entanto, entende-se que podem ser também utilizadas variações dessa abordagem preferida, tal como o uso de outras frequências de transmissão, outros tipos de suportes físicos para o cabo de manobra [119] (p. ex., fios de transmissão redundantes) ou outros tipos de esquemas de codificação (p. ex., códigos Hamming, códigos de retorno a zero, etc.) que são do conhecimento das pessoas leigas na matéria para implementar um sistema apresentado na Figura 1.

[021] Preferencialmente, em um sistema conforme apresentado na Figura 1, o módulo de serialização [118] e o módulo de deserialização [120] serão ambos implementados como duas placas de fichas PCB separadas. Essa placa de fichas PCB pode ficar inserida em caixas, mas note-se que quando o módulo de serialização [118] e/ou o módulo de deserialização [120] são implementados como uma placa de fichas PCB, não é necessário que essa placa fique inserida em uma caixa para ser usada em um sistema, tal como é apresentado na Figura 1.

[022] Olhando agora para a Figura 2, esta ilustra um conjunto exemplificativo de componentes que pode ser usado para implementar um módulo de serialização [118], tal como é apresentado na Figura 1. Para ilustrar como esses componentes podiam interagir entre si e operar em um módulo de serialização [118], os componentes da Figura 2 são descritos no contexto da execução de quatro funções principais: fazer a leitura de interruptores relacionados com a segurança [101][102][116], ler informação a partir de um sensor externo [117], criando um pacote de dados para transmissão ao módulo de deserialização [120] e transmitido a informação de segurança ao módulo de deserialização [120]. Note-se que, apesar de o material incluído nesta descrição representar uma abordagem privilegiada para implementar um módulo de serialização [118], são também possíveis outras abordagens para implementar um módulo de serialização [118], tal como abordagens, nas quais o módulo lê uma informação diferente, lê a informação a partir de diferentes dispositivos ou números de dispositivos, ou usa diferentes componentes e/ou níveis de redundância, e que ficarão imediatamente claras às pessoas leigas na matéria à luz desta apresentação. Correspondentemente, a Figura 2 e a apresentação correspondente a essa figura devem ser entendidas como meramente ilustrativas e não devem ser tratadas como sendo limitativas.

[023] Relativamente agora ao modo como os componentes apresentados na Figura 2 podiam ser usados para realizar as funções acima descritas, as funções da leitura dos interruptores relacionados com a segurança [101][102][116] e a leitura da informação a partir do sensor externo [117] podem ser executadas usando dois microcontroladores [201][202] e duas interfaces de rede (apresentadas como interfaces CAN [204][205]). Estes microcontroladores [201][202] estariam preferencialmente configurados (p. ex., através de software apropriadamente programado ou firmware) para comparar os sinais de leitura nos terminais de entrada de interruptores [203] (apresentados como 16 terminais de entrada na Figura 2, apesar de serem também possíveis diferentes números (p. ex., mais terminais em um módulo de serialização [118] que pretendem recolher entrada a partir de mais do que 16 interruptores). De igual modo, os microcontroladores [201][202] estariam também preferencialmente configurados, cada um, para receber e verificar informação dos sensores externos múltiplos [117] através das correspondentes interfaces CAN [204][205]. Estas comparações e verificações podem ser usadas para detectar corrupção de dados, curto-circuitos ou falhas por não variação do estado lógico, aumentando assim a segurança geral do sistema.

[024] Esta mesma abordagem para aumentar a segurança através do processamento redundante pode ser também usada na criação de pacotes de dados com a informação de segurança para transmissão ao módulo de deserialização [120]. Em particular, em um modelo privilegiado, cada microcontrolador [201][202] vai independentemente criar o pacote de dados. Isto permite a integridade de microcontroladores [201][202] por verificar através da comparação dos pacotes de dados independentemente criados. Por exemplo, é possível que um dos microcontroladores [201] possa operar como um microcontrolador master [que transmitiria um pacote de dados ao módulo de comunicação [206], enquanto o outro microcontrolador [202] podia operar como um microcontrolador slave que não transmitiria um pacote de dados, mas em vez disso iria monitorizar o módulo de comunicação [206] para pacotes de dados transmitidos pelo microcontrolador master [201]. Nesse tipo de implementação, quando um microcontrolador slave detecta uma transmissão de um microcontrolador master, vai comparar o pacote de dados nessa comunicação com o seu próprio pacote de dados independentemente criado e desativar a transmissão recebida ao módulo de comunicação, se os pacotes forem inconsistentes. Claro que são também possíveis outras abordagens para garantir a consistência dos pacotes de dados, tal como usar um componente de comparação separado do módulo de serialização [118] (não apresentado na Figura 1), ou através do uso de microcontroladores no módulo de deserialização [120], e que ficam imediatamente claras às, e podiam ser implementadas sem a experiência indevida pelas pessoas leigas na matéria a luz desta apresentação.

[025] A tecnologia apresentada não apenas melhora a segurança, ao permitir que os pacotes de dados sejam criados de forma independente e verificados quanto à consistência, como também a informação em um pacote de dados pode suportar uma maior fiabilidade e, por conseguinte segurança, para o sistema. Por exemplo, os microcontroladores [201][202] e/ou um módulo de comunicação separado [206] pode estar configurado para criar o pacote de dados para incluir, adicionalmente à informação de segurança recolhida pelos sensores ou interruptores, códigos de falhas ou informação sobre o estado determinados pelo próprio módulo de serialização [118]. Por exemplo, em alguns modelos, podem ser configurados microprocessadores [201][202] em um módulo de serialização para detectar e criar códigos de erros para erros internos, tais como falhas de componentes ou falhas par comunicar com sensores externos [107]. De igual modo, esses microprocessadores [201][202] podiam ser configurados para detectar erros na operação de um sensor externo [107], tal como verificando, por exemplo, o número de sequência, a expetativa de tempo ou CRC de um quadro usado em comunicar dados a partir de um sensor externo [107], para verificar que esses dados são válidos. De igual modo, em implementações que um canal dual, podiam ser configurados sensores de posição absolutos, tais como um sensor externo [107], um microprocessador [201][202] a partir de um módulo de serialização, para verificar a informação desses canais (p. ex., ao comparar as posições dos dois canais e, se não corresponderem a um desvio fixo esperado da posição, registam um erro de comunicação). Vários tipos de dados administrativos podiam ser adicionados a um pacote de dados, tal como um contador de sequências e um valor de verificação/soma de verificação cíclico de redundância sobre todo o suporte de dados, que podia potencialmente ser usado pelo módulo de deserialização [120] para encontrar dados corruptos.

[026] É ilustrado na Figura 3 um formato exemplificativo que podia ser usado para um pacote de dados para ser transmitido entre o módulo de serialização [118] (referido por S3I) e o módulo de deserialização [120] (referido por S3O). Em um pacote de dados que segue o formato da Figura 3, o primeiro byte do pacote [301] inclui o contador de sequências adicionado pelos microcontroladores [201][202]. Os próximos dez bytes do pacote [302] vai incluir informação da posição e da velocidade recuperada a partir dos sensores externos (referidos na Figura 3 como dados a partir do APS, um acrónimo para Sensor de Posição Absoluto). Os seguintes dois bytes do pacote [303] incluem informação do estado dos interruptores relacionados com segurança, com os valores dos bits individuais (p. ex., zero ou um) indicando o estado dos interruptores individuais. Os dois bytes depois disso [304] incluem informação sobre o estado do módulo de serialização [118]. Esta informação sobre o estado pode incluir informação, tal como o fabricante dos sensores externos, se os sensores externos estão adequadamente alinhados ou têm de ser alinhados por alguma razão (p. ex., leitura demasiado perto, leitura demasiado longe, leitura demasiado à esquerda, leitura demasiado à direita), e se o carro de elevador associado ao módulo de serialização está ok, se é recomendado para o serviço, se está a operar em um estado de aviso (p. ex., que deve ir até ao piso pretendido do que terminar a operação), e se está (ou deve ser) parado. O próximo campo de um byte no pacote [305] incluiria códigos que fornecem informação de erros. Estes códigos de erro podem indicar tipos de erro, tais como que existe um erro na posição ou velocidade encontrada por um sensor externo, que um erro interno foi detectado no módulo de serialização, que existe uma falha em um interruptor, que existem erros de alinhamento, falhas de comunicação ou erros internos em um sensor ou outros tipos de informação de erro. Por fim, os dois últimos bytes [306] de um pacote enviado que usa o formato da Figura 3 inclui um valor de verificação de redundância cíclico que, conforme descrito anteriormente, pode ser usado para identificar dados corruptos no pacote.

[027] Preferencialmente, quando é recebido um pacote que contém códigos de erro que indica que foi detectado um erro, o elevador associado ao módulo de serialização [118] que enviou o pacote com os códigos de erro será imediatamente parado para que o problema associado aos códigos de erro possa ser tratado e o elevador possa retomar a operação segura. De igual modo, quando se espera receber um pacote que não chega (p. ex., quando se espera que os pacotes sejam enviados a cada cinco milésimos de segundos, e o pacote não chega em uma certa janela de chegada centrada à volta do seu tempo esperado), então o elevador associado ao módulo de serialização [118] cujo pacote não foi recebido será preferencialmente parado para que o problema que causou a perda de comunicação possa ser identificado e tratado, permitindo assim que o elevador retome a operação segura.

[028] Olhando agora para a Figura 4, esta ilustra um conjunto exemplificativo de componentes que pode ser usado para implementar um módulo de deserialização [120], tal como é apresentado na Figura 1. Tal como na discussão da Figura 2, a discussão da Figura 4 foca-se em três funções principais que esses componentes podiam realizar - ler pacotes de dados recebidos do módulo de serialização [118], criar novos pacotes de dados para transmissão ao controlador [121], e na realidade transmitir os novos pacotes de dados ao controlador [121] - para ilustrar como esses componentes podiam operar e interagir entre si. Tal como foi o caso com a discussão correspondente à Figura 2, a seguinte discussão dos componentes apresentada na Figura 4 deve ser entendida meramente de forma ilustrativa, e não deve ser tratada implicando limitações à proteção acordada por este documento ou qualquer documento relacionado.

[029] Relativamente à forma como os componentes apresentados na Figura 4 podiam ser usados para executar as funções acima descritas, os componentes conforme apresentados na Figura 4 serão preferencialmente implementados de um modo que usa a redundância de componentes e processamento de dados para aumentar a fiabilidade e segurança. Correspondentemente, tal como foi o caso com o módulo de serialização exemplificativo [118] apresentado na Figura 2, o módulo de deserialização exemplificativo [120] apresentado na Figura 4 inclui microcontroladores paralelos [401][402]. Estes microcontroladores [401][402] podem ser configurados para recuperar os pacotes de dados enviados pelo módulo de serialização [118] e verificar esses pacotes quanto à consistência entre eles, assim como, quanto à corrupção interna de dados (p. ex., usando números de sequência e valores de verificação de redundância cíclica, conforme descrito anteriormente). Os microcontroladores [401][402] também podem ser configurados para, assim que os pacotes de dados forem recuperados e verificados, usar a informação a partir desses pacotes de dados para criar novos pacotes de dados que serão enviados para o controlador do elevador [121].

[030] Tal como com o módulo de serialização [118] conforme discutido no contexto da Figura 2, um módulo de deserialização [120] conforme descrito discutido no contexto da Figura 4 podia ser implementado de várias maneiras, incluindo a utilização de um design master/slave similar ao discutido no contexto da Figura 2. Por exemplo, em um módulo de deserialização [120] que usa um design master/slave desses, um microprocessador master [401] receberia pacotes de módulo de serialização [118] e criaria um novo pacote de dados que podia ser transmitido ao controlador do elevador [121]. O microprocessador slave [402] iria receber o mesmo pacote de dados do módulo de serialização [118] e criar independentemente um novo pacote de dados. O microprocessador slave [402] monitorizaria transmissões do microprocessador master [401] e compararia os dois novos pacotes de dados independentemente criados. Se o microprocessador slave [402] detectasse quaisquer inconsistências ao longo dos dois novos pacotes de dados independentemente criados, impediria o controlador do elevador [121] de receber o novo pacote de dados enviado pelo microprocessador master [401].

[031] É apresentado na Figura 5 um formato exemplificativo que podia ser usado para novos pacotes de dados criados por um módulo de deserialização [120]. Como se pode ver nas inscrições nessa figura, a maior parte dos dados do novo pacote de dados é, na realidade, retirada diretamente dos pacotes de dados recebidos do módulo de serialização [118]. No entanto, um novo pacote de dados que segue o formato da Figura 5 vai diferir do pacote de dados recebido a partir do módulo de serialização [118] pelo fato de esse primeiro [501] e último [502] dos novos pacotes incluírem novos valores de verificação do contador de sequências e de redundância cíclica determinados pelo módulo de deserialização [120], em vez de simplesmente repetirem os valores do pacote de dados original. De igual modo, o segundo byte [503] de um novo pacote de dados que segue o formato da Figura 5 vão incluir novos códigos de erro, códigos de erro esses que podiam indicar informação, tal como se existia um erro de comunicação na (ou perda de) comunicação entre os módulos de serialização e deserialização e se existe um erro na tentativa de comunicar dados a partir do módulo de deserialização para o controlador (ou algum outro tipo de erro interno no módulo de deserialização). Tal como foi o caso com o manuseamento de erros conforme discutido no contexto da Figura 3, no caso de a informação do código de erro em um novo pacote de dados indicar que foi detectado um erro ou no caso de não ser recebida uma comunicação esperada a partir do módulo de deserialização, o elevador ou elevadores cuja informação seria tratada por esse módulo de deserialização seria(m) preferencialmente parado(s), de modo a que a questão subjacente ao erro ou perda de comunicação pudesse ser resolvida e a operação segura do elevador ou elevadores pudesse ser retomada.

[032] Tal como com os pacotes de dados transmitidos a partir do módulo de serialização [118], estes novos pacotes de dados serão preferencialmente criados independentemente e verificados uns em relação aos outros. Assim que tiverem sido verificados, os pacotes de dados serão comunicados ao controlador do elevador [121] através de um conjunto (apresentado como um conjunto de três interfaces na Figura 4, apesar de poderem ser usados outros números de interfaces) de interfaces redundantes seriais para paralelas (SPI) [403]. Tal como com os terminais de entrada de interruptor [203] da Figura 2, estas interfaces redundantes SPI [403] serão preferencialmente verificadas umas em relação às outras (p. ex., através de um componente de comparação separado [não ilustrado, por um ou vários dos microcontroladores [401][402] do módulo de deserialização [120], e/ou pelo controlador [121]) para identificar se alguma das interfaces [403] está corrupta.

[033] A inclusão de exemplos particulares, detalhes, explicações e características na apresentação anterior não deve ser tratada como se implicasse que este documento ou qualquer documento relacionado com este documento não incluísse dentro do seu âmbito variações da apresentação anterior, como ficará de imediato evidente a, e podia ser implementado sem a experiência indevida por uma pessoa leiga na matéria à luz da apresentação explícita aqui anunciada. Por exemplo, na apresentação anterior, a Figura 2 ilustrou o módulo de serialização exemplificativo [118] como tendo 16 terminais de entrada de interruptores [203], e as Figuras 3 e 5 ilustraram formatos de pacotes de dados exemplificativos como tendo dois bytes (16 bits) de espaço reservado para guardar informação sobre o estado dos interruptores relacionados com segurança. Enquanto esta configuração representa uma abordagem privilegiada para implementar a tecnologia do inventor, note-se que podem ser usados outros números de terminais de entrada de interruptores [203] (ou mesmo sem terminais de entrada de interruptores, no caso de toda a informação de segurança ser recolhida a partir de outros tipos de sensores, tais como sensores de posição absolutos) em sistemas que implementam a tecnologia apresentada, e que, no caso de alterações nos números de terminais de entrada de interruptores, seriam também feitas correspondentes alterações no número de bits usado para representar o estado dos interruptores. Podiam ser feitas alterações idênticas nos números de outros componentes (p. ex., podiam ser implementados módulos de serialização e/ou deserialização para usar mais do que microcontroladores redundantes), em outros aspectos da organização de dados (p. ex., os dados podem ser comunicados usando uma ordem de bits diferente da apresentada nas Figuras 3 e 5) ou em outros aspectos da operação do sistema (p. ex., a comunicação dos dados podia realizar-se com uma frequência diferente da frequência de 5 ms identificada na apresentação acima). Correspondentemente, a apresentação adiante apresentada deve ser entendida como meramente ilustrativa e não deve ser tratada como sendo limitativa.

[034] À luz do que foi dito, a proteção para a tecnologia do inventor acordada por este documento ou qualquer documento relacionado não deve ser limitada ao material explicitamente aqui definido. Em vez disso, a proteção acordada por este documento, ou qualquer documento relacionado, deve ser entendida como sendo definida pelas reivindicações nesse documento, quando os termos nessas reivindicações que são apresentadas no título “Definições Explícitas” são entendidos de acordo com as definições explícitas e os restantes termos são entendidos na sua interpretação mais geral e razoável, tal como é apresentado um dicionário geral. No caso de a interpretação que seria dada às reivindicações com base neste documento ser menos abrangente do que interpretação que seria dada com base nas “Definições Explícitas” e a interpretação mais geral e razoável fornecida por um dicionário geral, prevalece a interpretação fornecida pelas “Definições Explícitas” e interpretação mais geral e razoável fornecida por um dicionário geral, e a utilização inconsistente de termos na especificação deste ou outro documento relacionado não tem efeito.

[035] Definições Explícitas

[036] Quando é usada na reivindicação uma afirmação de que alguma coisa se “baseia em” alguma outra coisa, isso deve ser entendido no sentido de que alguma coisa é determinada pelo menos em parte pela coisa que é indicada como sendo “baseada em”. Quando alguma coisa é completamente determinada por uma coisa, será descrita como sendo “baseada EXCLUSIVAMENTE em” a coisa.

[037] Quando usado nas reivindicações, “cardinalidade” deve ser entendido como referindo-se ao número de elementos em um conjunto.

[038] Quando usado nas reivindicações, “instruções exequíveis em computador” deve ser entendido como referindo-se a dados que podem ser usados para especificar operações físicas ou lógicas que podem ser executadas por um computador.

[039] Quando usado nas reivindicações, “suporte de leitura informática” deve ser entendido como referindo-se a qualquer objeto, substância ou combinação de objetos ou substâncias, capazes de guardar dados ou instruções em uma forma na qual podem ser recuperados e/ou processados por um dispositivo. Um suporte de leitura informática não deve ser limitado a qualquer tipo ou organização particular, e deve ser entendido para incluir sistemas distribuídos e descentralizados, apesar de estarem fisicamente ou logicamente dispostos, assim como, objetos de armazenamento de sistemas que se encontram em um espaço físico e/ou lógico definido e/ou circunscrito. Memória de computadores, tais como discos duros, memória de leitura apenas, memória de acesso aleatório, elementos de memória de estado sólido, discos óticos e registadores é um exemplo de um “suporte de leitura informática”.

[040] Quando usado nas reivindicações, “configurado” deve ser entendido em como a coisa “configurada” está adaptada, concebida ou modificada para um propósito específico. Um exemplo de “configurar” no contexto de computadores é fornecer um computador com dados específicos (que podem incluir instruções) que podem ser usados na realização dos atos específicos para os quais o computador está a ser “configurado”. Por exemplo, instalar o Microsoft WORD em um computador “configura” o computador para funcionar como um processador de word, o que faz usando as instruções do Microsoft WORD combinadas com outras entradas, tais como um sistema operativo e vários periféricos (p. x., um teclado, monitor, etc.).

[041] Quando usado nas reivindicações, o termo “objeto de dados” deve ser entendido como referindo-se a uma entidade identificável e distinta expressa em uma forma (p. ex., dados guardados em um suporte de leitura informática) que pode ser manipulada por um computador.

[042] Quando usado nas reivindicações, “base de dados” deve ser entendida como uma coleção de dados guardados em um suporte de leitura informática de modo a que os dados possam ser recuperados por um computador. O termo “base de dados” pode ser também usado para referir-se ao próprio suporte de leitura informática (p. ex., um objeto físico que guarda os dados).

[043] Quando usado nas reivindicações, um “elemento” de um “conjunto” (definido infra) deve ser entendido como referindo-se a uma das coisas no “conjunto”.

[044] Quando usado nas reivindicações, “meios para ler, criar um pacote de dados a deserializador com base no, e transmitindo informação que inclui pelo menos uma parte do pacote de dados serializador” deve ser entendido como sendo um elemento definido em forma de meios + função conforme permitido por 35 U.S.C. § 102(f), em que a correspondente estrutura descrita na especificação é um módulo de deserialização [120] conforme ilustrado nas Figuras 1 e 4 e descrito no texto correspondente.

[045] Quando usado nas reivindicações, “meios para ler, criar um pacote de dados a serializador com base em, e transmitindo em série informação que inclui, dados de segurança para um carro de elevador” deve ser entendido como sendo um elemento definido em forma de meios + função conforme permitido por 35 U.S.C. § 112(f), em que a correspondente estrutura descrita na especificação é um módulo de serialização [118] conforme ilustrado nas Figuras 1 e 2 e descrito no texto correspondente.

[046] Quando usado nas reivindicações, “remoto” deve ser entendido como referindo-se à relação entre entidades que estão fisicamente distantes umas das outras, tal como entre entidades que comunicam através da rede.

[047] Quando usado nas reivindicações, o termo “conjunto” deve ser entendido como referindo-se a um número, grupo ou combinação de zero ou mais coisas de idêntica natureza, concepção ou função.

[048] Quando usado nas reivindicações, o termo “guardar” usado no contexto de uma memória ou suporte de leitura informática deve ser entendido para designar que a coisa “guardada” é refletida em uma ou mais propriedades físicas (p. ex., momento magnético, potencial elétrico, refletividade ótica, etc.) da coisa que está a “guardar” por um período de tempo, apesar de breve.

Claims

1. Método para permitir que dados de segurança em relação a uma instalação de elevador sejam comunicados com o uso de um canal de comunicação em série, sendo que o método compreende um conjunto de etapas de transmissão e recepção que compreendem: a. em um módulo de serialização (118): i. receber uma pluralidade de itens de dados de segurança para um carro de elevador; ii. construir um pacote de dados de serializador que compreende a pluralidade de itens de dados de segurança para o carro de elevador; e iii. enviar o pacote de dados de serializador que compreende a pluralidade de itens de dados de segurança para o carro de elevador ao módulo de desserialização (120); b. no módulo de desserialização (120): i. receber o pacote de dados de serializador que compreende a pluralidade de itens de dados de segurança para o carro de elevador; ii. construir um pacote de dados de desserializador que compreende a pluralidade de itens de dados de segurança para o carro de elevador; e iii. enviar o pacote de dados de desserializador que compreende a pluralidade de itens de dados de segurança a um controlador (121); sendo que o método é caracterizado por compreender adicionalmente: c. no controlador (121), determinar, com base nas informações do módulo de desserialização (120), se o carro de elevador deve ser impedido de operar devido a um problema de segurança; em que o módulo de desserialização (120) compreende vários microcontroladores; em que o recebimento do pacote de dados de serializador que compreende a pluralidade de itens de dados de segurança para o carro de elevador compreende receber o pacote de dados de serializador independentemente em dois ou mais microcontroladores dentre os vários microcontroladores do módulo de desserialização (120); em que a construção do pacote de dados de desserializador que compreende a pluralidade de itens de dados de segurança do carro de elevador compreende construir o pacote de dados de desserializador independentemente em dois ou mais microcontroladores dentre os vários microcontroladores do módulo de desserialização (120); em que o conjunto de etapas de transmissão e recepção compreende adicionalmente comparar o pacote de dados de desserializador conforme construído por outro dentre os vários microcontroladores do módulo de desserialização (120) ao pacote de dados de desserializador conforme construído por outro dentre os vários microcontroladores do módulo de desserialização (120).

2. Método, de acordo com a reivindicação 1, caracterizado por; a. o módulo de serialização (118) compreender vários microcontroladores; b. o recebimento da pluralidade de itens de dados de segurança para o carro de elevador no módulo de serialização (118) compreender receber a pluralidade de itens de dados de segurança para o carro de elevador independentemente em dois ou mais microcontroladores dentre os vários microcontroladores do módulo de serialização (118); c. a construção do pacote de dados de serializador que compreende a pluralidade de itens de dados relacionados à segurança para o carro de elevador compreender construir o pacote de dados de serializador independentemente em dois ou mais microcontroladores dentre os vários microcontroladores do módulo de serialização (118); d. o conjunto de etapas de transmissão e recepção compreender adicionalmente: 1. a verificação da pluralidade de itens de dados de segurança recebidos no módulo de serialização (118) realizando-se ações compreender comparar dados da pluralidade de itens de dados de segurança, conforme recebidos em um dentre a pluralidade de microcontroladores do módulo de serialização (118), a dados da pluralidade de itens de dados de segurança recebidos em outro dentre a pluralidade de microcontroladores do módulo de serialização (118); ii a verificação dos pacotes de dados de serializador construídos independentemente realizando-se ações compreender comparar o pacote de dados de serializador conforme construído por outro dentre os vários microcontroladores do módulo de serialização (118) ao pacote de dados de serializador conforme construído por outro dentre os vários microcontroladores do módulo de serialização (118).

3. Método, de acordo com a reivindicação 2, caracterizado por: a. o envio do pacote de dados de desserializador ao controlador (121) compreender comunicar o pacote de dados de desserializador ao controlador (121) independentemente através de uma pluralidade de interfaces periféricas em série compreendidas pelo módulo de desserialização (120); b. o envio do pacote de dados de serializador ao módulo de desserialização (120) compreender enviar o pacote de dados de serializador em forma serial por um cabo com o uso de um código sem retorno a zero; e c. o conjunto de etapas de transmissão e recepção compreender determinar se qualquer uma das interfaces periféricas em série do módulo de desserialização (120) está corrompida verificando-se as interfaces periféricas em série do módulo de desserialização (120) uma em relação à outra.

4. Método, de acordo com a reivindicação 1, caracterizado por: a. o pacote de dados de serializador compreender os dados de segurança para o carro de elevador envolvidos por dados complementares adicionados pelo módulo de serialização (118), em que os dados complementares adicionados pelo módulo de serialização (118) compreendem: i. um contador de sequência para o pacote de dados de serializador; ii. um valor de verificação de corrupção para o pacote de dados de serializador; iii. informações de situação; e iv. informações de erro; b. o pacote de dados de desserializador compreender: i. os dados de segurança para o carro de elevador; ii. as informações de situação do pacote de dados de serializador; iii. as informações de erro do pacote de dados de serializador; iv. informações de erro adicionais; v. um contador de sequência para o pacote de dados de desserializador; e vi. um valor de verificação de corrupção para o pacote de dados de desserializador.

5. Método, de acordo com a reivindicação 4, caracterizado por: a. os dados de segurança para o carro de elevador compreenderem: i. informações de situação ligado/desligado para uma pluralidade de comutadores; ii. velocidade do carro de elevador; e iii. posição para o carro de elevador; b. o valor de verificação de corrupção ser: i. um valor de verificação redundância cíclica calculado para o pacote de dados; ou ii. um valor de soma de verificação calculado para o pacote de dados; c. as informações de situação compreenderem: i. dados de alinhamento para sensores de velocidade e posição para o carro de elevador; e ii. se o carro de elevador é recomendado para serviço ou está em um estado de alerta; d. as informações de erro compreenderem um ou mais códigos que indicam tipos de erro que compreendem: i. erros internos no módulo de serialização (118); ii. falhas em um ou mais comutadores da pluralidade de comutadores; e iii. erros em sensores usados para detectar velocidade e posição do carro de elevador; e. as informações de erro adicionais compreenderem um ou mais códigos que indicam tipos de erro que compreendem: i. erros em comunicação entre o módulo de serialização (118) e o módulo de desserialização (120); e ii. erros internos no módulo de desserialização (120).

6. Método, de acordo com a reivindicação 4, caracterizado por a determinação, com base em informações do módulo de desserialização (120), da possibilidade de que o carro de elevador deva ser impedido de operar devido a um problema de segurança compreender realizar uma ou mais ações do conjunto que consiste em: a. determinar se um erro é indicado pelas informações de erro do pacote de dados de serializador ou pelas informações de erro adicionais; b. determinar se um erro é indicado pelas informações de erro adicionais; c. determinar, com base no contador de sequência para o pacote de dados de desserializador, se o pacote de dados foi perdido, inserido, repetido ou está fora da sequência; d. determinar, com base no tempo decorrido desde a recepção do pacote de dados, se um pacote de dados foi perdido; e e. determinar se os dados comunicados do módulo de desserialização (120) ao controlador (121) foram corrompidos.

7. Método, de acordo com a reivindicação 1, sendo que o método é caracterizado por compreender realizar várias vezes o conjunto de etapas de transmissão e recepção a cada 5 ms.

8. Sistema para permitir que dados de segurança em relação a uma instalação de elevador sejam comunicados com o uso de um canal de comunicação em série, sendo que o sistema compreende: a. um módulo de serialização (118) configurado para realizar um conjunto de etapas de serialização que compreendem: i. receber uma pluralidade de itens de dados de segurança para um carro de elevador; ii. construir um pacote de dados de serializador que compreende a pluralidade de itens de dados de segurança para o carro de elevador; e iii. enviar o pacote de dados de serializador que compreende a pluralidade de itens de dados de segurança para o carro de elevador ao módulo de desserialização (120); b. o módulo de desserialização (120), sendo que o módulo de desserialização (120) é configurado para realizar um conjunto de etapas de desserialização que compreendem: i. receber o pacote de dados de serializador que compreende a pluralidade de itens de dados de segurança para o carro de elevador; ii. construir um pacote de dados de desserializador que compreende a pluralidade de itens de dados de segurança para o carro de elevador; e iii. enviar o pacote de dados de desserializador que compreende a pluralidade de itens de dados de segurança a um controlador (121); em que o sistema é caracterizado por compreender: c. o controlador (121) configurado para determinar, com base em informações do módulo de desserialização (120), se o carro de elevador deve ser impedido de operar devido a um problema de segurança; em que o módulo de desserialização (120) compreende vários microcontroladores e, na realização do conjunto de etapas de desserialização, é configurado para: i. receber o pacote de dados de serializador independentemente em dois ou mais microcontroladores dentre os vários microcontroladores do módulo de desserialização (120); ii. construir o pacote de dados de desserializador que compreende a pluralidade de itens de dados de segurança para o carro de elevador independentemente em múltiplos microcontroladores dentre a pluralidade de microcontroladores do módulo de desserialização (120); em que o sistema é configurado para realizar ações que compreendem comparar o pacote de dados de desserializador conforme construído por um dentre os vários microcontroladores do módulo de desserialização (120) ao pacote de dados de desserializador conforme construído por outro dentre os vários microcontroladores do módulo de desserialização (120).

9. Sistema, de acordo com a reivindicação 8, caracterizado por; a. o módulo de serialização (118) compreender vários microcontroladores e, na realização do conjunto de etapas de serialização, ser configurado para: i. receber a pluralidade de itens de dados de segurança para o carro de elevador independentemente em dois ou mais microcontroladores dentre os vários microcontroladores do módulo de serialização (118); ii. verificar a pluralidade recebida de itens de dados relacionados à segurança realizando-se ações que compreendem comparar dados da pluralidade de itens de dados relacionados à segurança, conforme recebidos em um dentre os microcontroladores dentre os vários microcontroladores do módulo de serialização (118), a dados da pluralidade de itens de dados relacionados à segurança recebidos em um microcontrolador diferente dentre os vários microcontroladores do módulo de serialização (118); e iii. construir o pacote de dados de serializador independentemente em múltiplos microcontroladores dentre a pluralidade de microcontroladores do módulo de serialização (118); e b. o sistema ser configurado para realizar ações que compreendem: 1. a verificação da pluralidade de itens de dados de segurança recebidos no módulo de serialização (118) realizando-se ações compreender comparar dados da pluralidade de itens de dados de segurança, conforme recebidos em um dentre a pluralidade de microcontroladores do módulo de serialização (118), a dados da pluralidade de itens de dados de segurança recebidos em outro dentre a pluralidade de microcontroladores do módulo de serialização (118); ii a verificação dos pacotes de dados de serializador construídos independentemente realizando-se ações compreender comparar o pacote de dados de serializador conforme construído por outro dentre os vários microcontroladores do módulo de serialização (118) ao pacote de dados de serializador conforme construído por outro dentre os vários microcontroladores do módulo de serialização (118).

10. Sistema, de acordo com a reivindicação 9, caracterizado por: a. o módulo de desserialização (120) compreender uma pluralidade de interfaces periféricas em série, e o envio do pacote de dados de desserializador ao controlador (121) compreende comunicar o pacote de dados de desserializador ao controlador (121) independentemente através da pluralidade de interfaces periféricas em série do módulo de desserialização (120); b. o envio do pacote de dados de serializador ao módulo de desserialização (120) compreender enviar o pacote de dados de serializador em forma serial por um cabo com o uso de um código sem retorno a zero; e c. o sistema ser configurado adicionalmente para determinar se qualquer uma das interfaces periféricas em série do módulo de desserialização (120) está corrompida verificando-se as interfaces periféricas em série do módulo de desserialização (120) uma em relação à outra.

11. Sistema, de acordo com a reivindicação 8, caracterizado por: a. o pacote de dados de serializador compreender os dados de segurança para o carro de elevador envolvidos por dados complementares adicionados pelo módulo de serialização (118), em que os dados complementares adicionados pelo módulo de serialização (118) compreendem: i. um contador de sequência para o pacote de dados de serializador; ii. um valor de verificação de corrupção para o pacote de dados de serializador; iii. informações de situação; e iv. informações de erro; b. o pacote de dados de desserializador compreender: i. os dados de segurança para o carro de elevador; ii. as informações de situação do pacote de dados de serializador; iii. as informações de erro do pacote de dados de serializador; iv. informações de erro adicionais; v. um contador de sequência para o pacote de dados de desserializador; e vi. um valor de verificação de corrupção para o pacote de dados de desserializador.

12. Sistema, de acordo com a reivindicação 11, caracterizado por: a. os dados de segurança para o carro de elevador compreenderem: i. informações de situação ligado/desligado para uma pluralidade de comutadores; ii. velocidade do carro de elevador; e iii. posição para o carro de elevador; b. o valor de verificação de corrupção ser: i. um valor de verificação redundância cíclica calculado para o pacote de dados; ou ii. um valor de soma de verificação calculado para o pacote de dados; c. as informações de situação compreenderem: i. dados de alinhamento para sensores de velocidade e posição para o carro de elevador; e ii. se o carro de elevador é recomendado para serviço ou está em um estado de alerta; d. as informações de erro compreenderem um ou mais códigos que indicam tipos de erro que compreendem: i. erros internos no módulo de serialização (118); ii. falhas em um ou mais comutadores da pluralidade de comutadores; e iii. erros em sensores usados para detectar velocidade e posição do carro de elevador; e. as informações de erro adicionais compreenderem um ou mais códigos que indicam tipos de erro que compreendem: i. erros em comunicação entre o módulo de serialização (118) e o módulo de desserialização (120); e ii. erros internos no módulo de desserialização (120).

13. Sistema, de acordo com a reivindicação 11, caracterizado por a determinação, com base em informações do módulo de desserialização (120), da possibilidade de que o carro de elevador deva ser impedido de operar devido a um problema de segurança compreender realizar uma ou mais ações do conjunto que consiste em: a. determinar se um erro é indicado pelas informações de erro do pacote de dados de serializador ou pelas informações de erro adicionais; b. determinar se um erro é indicado pelas informações de erro adicionais; c. determinar, com base no contador de sequência para o pacote de dados de desserializador, se o pacote de dados foi perdido, inserido, repetido ou está fora da sequência; d. determinar, com base no tempo decorrido desde a recepção do pacote de dados, se um pacote de dados foi perdido; e e. determinar se os dados comunicados do módulo de desserialização (120) ao controlador (121) foram corrompidos.

14. Sistema, de acordo com a reivindicação 8, sendo que o sistema é caracterizado por ser configurado para: a. realizar o conjunto de etapas de serialização; b. realizar o conjunto de etapas de desserialização; c. determinar, com base nas informações do módulo de desserialização (120), se o carro de elevador deve ser impedido de operar devido a um problema de segurança; em que o sistema é configurado para repetir as etapas a, b e c a cada 5 ms.

15. Máquina que compreende: a. meios para ler, construir um pacote de dados de serializador com base em dados relacionados à segurança para um carro de elevador e transmitir serialmente informações os compreendem; b. um módulo de desserialização (120) para ler, construir um pacote de dados de desserializador com base no pacote de dados de serializador e transmitir informações que compreendem pelo menos uma porção do pacote de dados de serializador; em que a máquina é caracterizada por compreender: c. um controlador (121), em que o controlador (121) está: i. conectado de maneira comunicativa ao módulo de desserialização (120) para ler, construir o pacote de dados de desserializador com base no pacote de dados de serializador e transmitir informações que compreendem pelo menos uma porção do pacote de dados de serializador; e ii. configurado para determinar se o carro de elevador deve ser impedido de operar devido a um problema de segurança; em que o módulo de desserialização (120) compreende vários microcontroladores para receber o pacote de dados de serializador independentemente em dois ou mais microcontroladores dentre os vários microcontroladores do módulo de desserialização (120); construir o pacote de dados de desserializador independentemente em dois ou mais microcontroladores dentre os vários microcontroladores do módulo de desserialização (120); e comparar o pacote de dados de desserializador conforme construído por um dentre os vários microcontroladores do módulo de desserialização (120) com o pacote de dados de desserializador, conforme construído por outro dentre os vários microcontroladores do módulo de desserialização (120).

16. Máquina, de acordo com a reivindicação 15, sendo que: a. a máquina é caracterizada por compreender adicionalmente um cabo que conecta: i. os meios para ler, construir o pacote de dados de serializador com base em dados relacionados à segurança para o carro de elevador e transmitir serialmente informações que os compreendem; com ii. o módulo de desserialização (120) para ler, construir o pacote de dados de desserializador com base no pacote de dados de serializador e transmitir informações que compreendem pelo menos a porção do pacote de dados de serializador; e b. a transmissão de informações que compreendem dados relacionados à segurança para o carro de elevador compreender transmitir o pacote de dados de serializador por um cabo com o uso de um código sem retorno a zero.