BR102022000011A2 - Ota mestre, método de controle de atualização, meio de armazenamento não transitório, e veículo - Google Patents

Ota mestre, método de controle de atualização, meio de armazenamento não transitório, e veículo Download PDF

Info

Publication number
BR102022000011A2
BR102022000011A2 BR102022000011-5A BR102022000011A BR102022000011A2 BR 102022000011 A2 BR102022000011 A2 BR 102022000011A2 BR 102022000011 A BR102022000011 A BR 102022000011A BR 102022000011 A2 BR102022000011 A2 BR 102022000011A2
Authority
BR
Brazil
Prior art keywords
control unit
electronic control
software
update
target electronic
Prior art date
Application number
BR102022000011-5A
Other languages
English (en)
Inventor
Tomoyasu Ishikawa
Shunsuke TANIMORI
Original Assignee
Toyota Jidosha Kabushiki Kaisha
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
Application filed by Toyota Jidosha Kabushiki Kaisha filed Critical Toyota Jidosha Kabushiki Kaisha
Publication of BR102022000011A2 publication Critical patent/BR102022000011A2/pt

Links

Images

Classifications

    • 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/34—Network arrangements or protocols for supporting network services or applications involving the movement of software or configuration parameters 
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/65—Updates
    • G06F8/654—Updates using techniques specially adapted for alterable solid state memories, e.g. for EEPROM or flash memories
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60R—VEHICLES, VEHICLE FITTINGS, OR VEHICLE PARTS, NOT OTHERWISE PROVIDED FOR
    • B60R16/00—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for
    • B60R16/02—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for electric constitutive elements
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1415—Saving, restoring, recovering or retrying at system level
    • G06F11/1433—Saving, restoring, recovering or retrying at system level during software upgrading
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1415—Saving, restoring, recovering or retrying at system level
    • G06F11/1438—Restarting or rejuvenating
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1471—Saving, restoring, recovering or retrying involving logging of persistent data for recovery
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/61—Installation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/65—Updates
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/65—Updates
    • G06F8/658—Incremental updates; Differential updates
    • 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/44—Arrangements for executing specific programs
    • G06F9/448—Execution paradigms, e.g. implementations of programming paradigms
    • G06F9/4482—Procedural
    • 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
    • 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
    • H04L67/125—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks involving control of end-device applications over a network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30—Services specially adapted for particular environments, situations or purposes
    • H04W4/40—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P]
    • H04W4/44—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P] for communication between vehicles and infrastructures, e.g. vehicle-to-cloud [V2C] or vehicle-to-home [V2H]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30—Services specially adapted for particular environments, situations or purposes
    • H04W4/40—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P]
    • H04W4/48—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P] for in-vehicle communication
    • 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

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Quality & Reliability (AREA)
  • Medical Informatics (AREA)
  • General Health & Medical Sciences (AREA)
  • Computing Systems (AREA)
  • Health & Medical Sciences (AREA)
  • Mechanical Engineering (AREA)
  • Stored Programmes (AREA)
  • Human Computer Interaction (AREA)

Abstract

Um OTA mestre inclui: uma unidade receptora (22) configurada para receber dados de atualização para software em uma unidade de controle eletrônico alvo (13a, 13b, 13c, 13d) de um centro; uma unidade de armazenamento (23) configurada para armazenar os dados de atualização; e uma unidade de controle (24) configurada para: controlar um processo de atualização de software para a unidade de controle eletrônico alvo (13a, 13b, 13c, 13d) com base nos dados de atualização; fazer com que a unidade de armazenamento (23) retenha os dados de atualização até que o processo da atualização de software para a unidade de controle eletrônico alvo (13a, 13b, 13c, 13d) seja concluído com sucesso; e deletar os dados de atualização da unidade de armazenamento (23) após o processo de atualização de software para a unidade de controle eletrônico alvo (13a, 13b, 13c, 13d) ser concluído com sucesso.

Description

OTA MESTRE, MÉTODO DE CONTROLE DE ATUALIZAÇÃO, MEIO DE ARMAZENAMENTO NÃO TRANSITÓRIO, E VEÍCULO FUNDAMENTOS DA INVENÇÃO 1. Campo da Invenção
[001] A presente divulgação refere-se a um over-the-air (OTA) mestre, um método de controle de atualização, um meio de armazenamento não transitório, e um veículo.
2. Descrição da Técnica Relacionada
[002] Um veículo é equipado com uma pluralidade de unidades de controle eletrônico (ECUs) que controlam a operação de um veículo. Cada ECU inclui um processador, uma unidade de armazenamento temporário, como uma memória de acesso aleatório (RAM), e uma unidade de armazenamento não volátil, como uma memória flash somente leitura (ROM). O processador de cada ECU implementa funções de controle dessa ECU executando o software armazenado na unidade de armazenamento não volátil. O software armazenado em cada ECU é regravável e é possível melhorar as funções de cada ECU ou adicionar uma nova função de controle do veículo a cada ECU atualizando o software para uma versão mais recente.
[003] Uma técnica over-the-air (OTA) é um exemplo de uma técnica de atualização de software em uma ECU. Na técnica OTA, um programa na ECU é atualizado ou um programa é adicionado à ECU conectando sem fio um dispositivo de comunicação no veículo conectado a uma rede no veículo a uma rede de comunicação, como a Internet, fazendo download do software de um servidor por meio de comunicação sem fio e instalação do software baixado (consulte, por exemplo, a Publicação do Pedido de Patente Japonesa não Examinada n° 2004-326689 (JP 2004326689 A)).
[004] Existem dois tipos de unidades de armazenamento não voláteis que são montadas na ECU: memórias (memórias de banco único) com uma área de armazenamento de dados para armazenar dados, como um programa e memórias (memórias de banco duplo) com duas áreas de armazenamento de dados para armazenar dados, como um programa. Qualquer um desses dois tipos de memória é usado dependendo das especificações da ECU, etc..
SUMÁRIO DA INVENÇÃO
[005] Quando uma atualização de software em uma ECU a ser atualizada falha, é desejável ser capaz de repetir e concluir rapidamente a atualização de software. No entanto, uma atualização de software pode levar muito tempo quando, por exemplo, o ambiente de comunicação fica ruim durante a nova tentativa de atualização de software. Especialmente para uma ECU com memória de banco único, se um processo de atualização de software falhar no meio, a ECU não pode ser operada. Isso causa transtornos quando há uma emergência para usar um veículo. Consequentemente, há espaço para melhorias.
[006] A presente divulgação fornece um OTA mestre, um método de controle de atualização, um meio de armazenamento não transitório, e um veículo que pode melhorar as atualizações de software em uma unidade de controle eletrônico.
[007] Um OTA mestre de acordo com um primeiro aspecto da presente divulgação inclui: uma unidade receptora configurada para receber dados de atualização para software em uma unidade de controle eletrônico alvo de um centro; uma unidade de armazenamento configurada para armazenar os dados de atualização; e uma unidade de controle configurada para: controlar um processo de atualização de software para a unidade de controle eletrônico alvo com base nos dados de atualização; fazer com que a unidade de armazenamento retenha os dados de atualização até que o processo de atualização de software para a unidade de controle eletrônico alvo seja concluído com sucesso; e deletar os dados de atualização da unidade de armazenamento após o processo de atualização de software para a unidade de controle eletrônico alvo ser concluído com sucesso.
[008] Um método de controle de atualização de software de acordo com um segundo aspecto da presente divulgação é realizado por um computador incluindo um processador, uma memória, e um dispositivo de armazenamento. O método de controle de atualização de software inclui: receber dados de atualização para software em uma unidade de controle eletrônico alvo de um centro; armazenar os dados de atualização no dispositivo de armazenamento; controlar um processo de atualização de software para a unidade de controle eletrônico alvo com base nos dados de atualização; reter os dados de atualização até que o processo de atualização de software para a unidade de controle eletrônico alvo seja concluído com sucesso; e deletar os dados de atualização do dispositivo de armazenamento após o processo de atualização de software para a unidade de controle eletrônico alvo ser concluído com sucesso.
[009] Um meio de armazenamento não transitório de acordo com um terceiro aspecto da presente divulgação armazena um programa de controle de atualização de software que é executável por um computador incluindo um processador, uma memória, e um dispositivo de armazenamento e que faz com que o computador realize funções incluindo: receber dados de atualização para software em uma unidade de controle eletrônico alvo de um centro; armazenar os dados de atualização no dispositivo de armazenamento; controlar um processo de atualização de software para a unidade de controle eletrônico alvo com base nos dados de atualização; reter os dados de atualização até que o processo de atualização de software para a unidade de controle eletrônico alvo seja concluído com sucesso; e deletar os dados de atualização do dispositivo de armazenamento após o processo de atualização de software para a unidade de controle eletrônico alvo ser concluído com sucesso.
[010] Um veículo de acordo com um quarto aspecto da presente invenção pode incluir o OTA mestre de acordo com o primeiro aspecto.
[011] A presente divulgação pode fornecer um OTA mestre, um método de controle de atualização, um meio de armazenamento não transitório, e um veículo que pode melhorar as atualizações de software em uma unidade de controle eletrônico.
BREVE DESCRIÇÃO DOS DESENHOS
[012] Características, vantagens e significado técnico e industrial de modalidades exemplificativas da invenção serão descritas abaixo com referência aos desenhos anexos, nos quais sinais semelhantes denotam elementos semelhantes, e em que:
[013] A Figura 1 é um diagrama de bloco mostrando uma configuração geral de um sistema de rede de acordo com uma modalidade;
[014] A Figura 2 é um funcional diagrama de bloco de um OTA mestre de acordo com a modalidade; e
[015] A Figura 3 é um fluxograma de um processo de controle de atualização de software que é realizado pelo OTA mestre de acordo com a modalidade.
DESCRIÇÃO DETALHADA DAS MODALIDADES
[016] A Figura 1 é um diagrama de bloco mostrando uma configuração geral de um sistema de rede de acordo com uma modalidade.
[017] Um sistema de rede mostrado na Figura 1 é um sistema para atualizar software em unidades de controle eletrônico 13a a 13d montadas em um veículo, e inclui um servidor 1 (centro) e uma rede no veículo 2 que é montada no veículo.
[018] O servidor 1 pode se comunicar com um OTA mestre 11 montado no veículo por meio de uma rede 5, e gerencia atualizações de software nas unidades de controle eletrônico 13a a 13d montadas no veículo.
[019] O servidor 1 inclui uma unidade de processamento central (CPU), uma RAM, um dispositivo de armazenamento tendo um meio de armazenamento legível e gravável como disco rígido e unidade de estado sólido (SSD), e um dispositivo de comunicação para se comunicar com o OTA mestre 11 por meio da rede 5. O dispositivo de armazenamento armazena um programa para gerenciar atualizações de software, informações a serem usadas para o gerenciamento de atualização de software, e dados de atualização para as unidades de controle eletrônico. No servidor 1, a CPU controla a transmissão dos dados de atualização para o OTA mestre 11 executando o programa lido do dispositivo de armazenamento usando a RAM como uma área de trabalho.
[020] A rede no veículo 2 inclui o OTA mestre 11, um módulo de comunicação 12, as unidades de controle eletrônico (ECUs) 13a a 13d, e um dispositivo de exibição 14. O OTA mestre 11 é conectado ao módulo de comunicação 12 por meio de um barramento 15a, é conectado às unidades de controle eletrônico 13a, 13b por meio de um barramento 15b, é conectado às unidades de controle eletrônico 13c, 13d por meio de um barramento 15c, e é conectado ao dispositivo de exibição 14 por meio de um barramento 15d. O módulo de comunicação 12 é um dispositivo de comunicação que conecta a rede no veículo 2 e o servidor 1.
[021] O OTA mestre 11 inclui um microcomputador e um dispositivo de comunicação. O microcomputador inclui uma CPU, uma RAM, uma ROM, e um dispositivo de armazenamento. No OTA mestre 11, a CPU do microcomputador realiza um processo de controle que será descrito mais tarde executando um programa lido do ROM ou o dispositivo de armazenamento usando a RAM como uma área de trabalho. O dispositivo de comunicação é um dispositivo que se comunica com o módulo de comunicação 12, as unidades de controle eletrônico 13a a 13d, e o dispositivo de exibição 14 por meio dos barramentos 15a a 15d mostrados na Figura 1. O OTA mestre 11 pode se comunicar sem fio com o servidor 1 por meio do módulo de comunicação 12. O OTA mestre 11 controla uma atualização de software na unidade de controle eletrônico do qual software é um alvo da atualização de software (a unidade de controle eletrônico a ser atualizada, unidade de controle eletrônico alvo) fora das unidades de controle eletrônico 13a a 13d, com base nos dados de atualização adquiridos do servidor 1. O OTA mestre 11 é algumas vezes denominado como o dispositivo mestre ou o gateway central.
[022] As unidades de controle eletrônico 13a a 13d controlam dispositivos como atuadores e sensores montados no veículo. O dispositivo de exibição 14 (interface homem-máquina (HMI)) é usado para exibir várias indicações como uma indicação de que há dados de atualização, uma tela de solicitação de aceitação que solicita a um usuário ou a um administrator para aceitar uma atualização de software, um resultado de atualização, etc. durante um processo de atualização de software para as unidades de controle eletrônico 13a a 13d. Um exemplo típico do dispositivo de exibição 14 é um dispositivo de exibição para um sistema de navegação de carro. Entretanto, o dispositivo de exibição 14 não é particularmente limitado desde que possa exibir as informações necessárias para um processo de atualização do programa. Embora as quatro unidades de controle eletrônico 13a a 13d sejam ilustradas na Figura 1, o número de unidades de controle eletrônico não é particularmente limitado. Além do dispositivo de exibição 14, uma unidade de controle eletrônico pode ainda ser conectado ao barramento 15d mostrado na Figura 1.
[023] Cada uma das unidades de controle eletrônico 13a a 13d inclui uma CPU, uma RAM, uma memória não volátil (armazenamento), e um dispositivo de comunicação. A CPU de cada unidade de controle eletrônico 13a a 13d implementa funções dessa unidade de controle eletrônico executando software (programa) lido da memória não volátil usando a RAM como uma área de trabalho. Existem dois tipos de unidades de controle eletrônico: aquelas tendo uma área de armazenamento de dados para armazenar software e aquelas tendo duas áreas de armazenamento de dados para armazenar software. Na área de armazenamento de dados (banco) da unidade de controle eletrônico, informações de versão, dados de parâmetro, um programa boot para inicializar, um programa para atualizações de software, etc. são algumas vezes armazenados além do software para implementar as funções da unidade de controle eletrônico. Nas unidades de controle eletrônico tendo uma área de armazenamento de dados (um banco, memórias de banco único), a instalação de dados de atualização na área de armazenamento de dados afeta o software na unidade de controle eletrônico. Por outro lado, nas unidades de controle eletrônico tendo duas áreas de armazenamento de dados (dois bancos, memórias de banco duplo), uma das duas áreas de armazenamento de dados é usada como uma área de armazenamento a ser lida (banco ativo), e software armazenado na área de armazenamento a ser lida é executado. Dados de atualização podem ser gravados em segundo plano na outra área de armazenamento que não devem ser lidos (banco inativo, banco de gravação) durante a execução de um programa armazenado na área de armazenamento a ser lido (banco ativo). Durante a ativação no processo de atualização de software, a versão atualizada do software pode ser ativada trocando a área de armazenamento a partir da qual a CPU lê o programa.
[024] Na presente divulgação, as unidades de controle eletrônico tendo duas áreas de armazenamento de dados incluem: uma unidade de controle eletrônico tendo uma memória com uma configuração chamada “memória suspensa em um banco” em que uma área de armazenamento de dados da memória não volátil é dividida em dois bancos de forma pseudo e, durante a execução de um programa armazenado em um banco dos dois bancos, um programa pode ser gravado no outro dos dois bancos; e uma unidade de controle eletrônico que tem uma expansão de memória não volátil tendo uma área de armazenamento de dados de um banco além de uma memória não volátil tendo uma área de armazenamento de dados de um banco e em que essas duas memórias não voláteis podem ser usadas como um banco ativo e um banco inativo.
[025] O processo de atualização de software é composto de uma fase de fazer download dos dados de atualização do servidor 1, uma fase de transferir os dados de atualização baixados para a unidade de controle eletrônico a ser atualizada e instalar os dados de atualização na área de armazenamento da unidade de controle eletrônico a ser atualizada, e uma fase de ativação de ativação da versão atualizada do software instalada na unidade de controle eletrônico a ser atualizada.
[026] Fazer download é um processo de receber os dados de atualização para atualizar o software na unidade de controle eletrônico do servidor 1 e armazenar os dados de atualização recebidos. A fase de fazer download inclui o controle de uma série de processos relacionados para fazer download, como determinação se o download pode ser realizado e verificação dos dados de atualização, além de recebimento dos dados de atualização. Instalação é um processo de gravar uma versão atualizada do programa (software de atualização) na área de armazenamento da unidade de controle eletrônico a ser atualizada, com base nos dados de atualização baixados. A fase de instalação inclui o controle de uma série de processos relacionados à instalação, como determinação se a instalação pode ser executada, a transferência dos dados de atualização e a verificação da versão atualizada do programa, além da execução da instalação. A ativação é um processo de ativação da versão atualizada instalada do programa. A fase de ativação inclui o controle de uma série de processos relacionados à ativação, como a determinação se a ativação pode ser executada e a verificação do resultado da ativação, além da execução da ativação.
[027] Os dados de atualização que são enviados do servidor 1 para o OTA mestre 11 podem incluir qualquer um de software de atualização para a unidade de controle eletrônico, dados compactados do software de atualização, e dados divididos do software de atualização ou os dados compactados. Os dados de atualização podem incluir um identificador que identifica a unidade de controle eletrônico a ser atualizada (ID de ECU) e um identificador que identifica o software antes da atualização (ECU software ID). Os dados de atualização são baixados como um pacote de distribuição. O pacote de distribuição contém os dados de atualização para uma ou mais unidades de controle eletrônico.
[028] Quando os dados de atualização incluem o próprio software de atualização, o OTA mestre 11 transfere os dados de atualização (software de atualização) para a unidade de controle eletrônico a ser atualizada durante a fase de instalação. Quando os dados de atualização incluem dados compactados, dados de diferença, ou dados divididos do software de atualização, o OTA mestre 11 pode transferir os dados de atualização para a unidade de controle eletrônico a ser atualizada e a unidade de controle eletrônico a ser atualizada pode gerar o software de atualização a partir dos dados de atualização. Alternativamente, o OTA mestre 11 pode gerar o software de atualização a partir dos dados de atualização e, em seguida, transferir o software de atualização gerado para a unidade de controle eletrônico a ser atualizada. O software de atualização pode ser gerado descompactando os dados compactados ou reunindo os dados de diferença ou os dados divididos.
[029] A unidade de controle eletrônico a ser atualizada pode instalar o software de atualização com base em uma solicitação de instalação do OTA mestre 11. Alternativamente, a unidade de controle eletrônico a ser atualizada que recebeu os dados de atualização pode autonomamente instalar o software de atualização sem receber uma instrução explícita do OTA mestre 11.
[030] A unidade de controle eletrônico a ser atualizada pode ativar o software de atualização com base em uma solicitação de ativação do OTA mestre 11. Alternativamente, a unidade de controle eletrônico a ser atualizada que recebeu os dados de atualização pode autonomamente ativar o software de atualização sem receber uma instrução explícita do OTA mestre 11.
[031] O processo de atualização de software pode ser realizado sucessivamente ou em paralelo para cada uma das unidades de controle eletrônico.
[032] O “processo de atualização do programa” no presente relatório descritivo inclui não apenas um processo no qual todo o download, instalação e ativação são realizados sucessivamente, mas também um processo no qual apenas uma parte do download, instalação e ativação é realizada..
[033] A Figura 2 é um diagrama de bloco funcional do OTA mestre de acordo com a modalidade.
[034] O OTA mestre 11 inclui uma unidade de transmissão 21, uma unidade receptora 22, uma unidade de armazenamento 23, e uma unidade de controle 24.
[035] Por exemplo, a unidade de transmissão 21 envia uma solicitação de confirmação de atualização para o servidor 1 quando a fonte de alimentação ou ignição do veículo está ligada. A solicitação de confirmação de atualização é uma solicitação para confirmar se há dados de atualização para o software. A solicitação de confirmação de atualização inclui uma identificação do veículo (ID) (número de identificação do veículo (VIN)) que identifica o veículo e a versão do software nas unidades de controle eletrônico 13a a 13d conectadas à rede no veículo 2. O veículo ID e a versão do software nas unidades de controle eletrônico 13a a 13d são usados para determinar se há dados de atualização para o software nas unidades de controle eletrônico 13a a 13d por comparação com a versão mais recente do software retido no servidor 1 para cada ID de veículo ou cada modelo de veículo identificado pelo ID de veículo. Quando é determinado com base em uma resposta à solicitação de confirmação de atualização de que há dados de atualização para o software em qualquer uma das unidades de controle eletrônico 13a a 13d, a unidade de transmissão 21 envia uma solicitação de download de dados de atualização para o servidor 1.
[036] A unidade receptora 22 recebe o resultado de confirmação indicando se há dados de atualização do servidor 1 como resposta à solicitação de confirmação de atualização. Após a unidade de transmissão 21 enviar a solicitação de download de dados de atualização para o servidor 1, a unidade receptora 22 recebe dados de atualização para o software na unidade de controle eletrônico do qual software é um alvo da atualização de software (unidade de controle eletrônico a ser atualizada, unidade de controle eletrônico alvo) do servidor 1. Os dados de atualização são enviados do servidor 1 como um pacote de distribuição. O pacote de distribuição pode incluir, além dos dados de atualização, dados de verificação para verificar a autenticidade dos dados de atualização, o número de partes dos dados de atualização, a ordem de instalação dos dados de atualização, vários tipos de informações de controle a serem usadas durante a atualização de software, etc. A unidade receptora 22 armazena o pacote de distribuição recebido na unidade de armazenamento 23.
[037] A unidade de armazenamento 23 armazena o pacote de distribuição recebido pela unidade receptora 22. A unidade de armazenamento 23 pode ser usada para armazenar, além dos dados de atualização (pacote de distribuição), dados relacionados às outras funções de controle que são realizada pela técnica de OTA, durante a atualização de software pelo OTA mestre 11.
[038] A unidade de controle 24 determina se há dados de atualização para o software na unidade de controle eletrônico, com base no resultado de confirmação recebido pela unidade receptora 22 do servidor 1 em resposta à solicitação de confirmação de atualização. Quando a unidade receptora 22 recebe o pacote de distribuição contendo os dados de atualização do servidor 1, a unidade de controle 24 verifica a autenticidade do pacote de distribuição recebido. Verificação da autenticidade aqui significa verificar a integridade e exatidão de dados. A autenticidade pode ser verificada usando, por exemplo, um ID de veículo (VIN) e uma assinatura digital. A unidade de controle 24 controla o processo de atualização de software para a unidade de controle eletrônico alvo. O processo de atualização de software que é realizado pela unidade de controle 24 será descrito em detalhes abaixo.
[039] A Figura 3 é um fluxograma da processo de controle de atualização de software que é realizado pelo OTA mestre de acordo com a modalidade. Por exemplo, o processo de controle mostrado na Figura 3 é realizado quando a fonte de alimentação ou ignição do veículo está ligada.
[040] Na etapa S11, a unidade de transmissão 21 envia uma solicitação para confirmar se há dados de atualização para o software na unidade de controle eletrônico para o servidor 1. A solicitação de confirmação de dados de atualização inclui uma combinação do ID de veículo e a versão do software na unidade de controle eletrônico. O processo, então, prossegue para a etapa S12.
[041] Na etapa S12, a unidade receptora 22 recebe o resultado de confirmação para a solicitação de confirmação de dados de atualização do servidor 1. O processo, então, prossegue para a etapa S13.
[042] Na etapa S13, a unidade de controle 24 determina se há dados de atualização para o software em qualquer uma das unidades de controle eletrônico 13a a 13d, com base no resultado de confirmação recebido na etapa S12. Quando YES na etapa S13, o processo prossegue para a etapa S14. De outro modo, o processo termina.
[043] Na etapa S14, os dados de atualização são baixados. Mais especificamente, a unidade de transmissão 21 envia uma solicitação para fazer download de um pacote de distribuição para o servidor 1, e a unidade receptora 22 recebe o pacote de distribuição enviados em resposta à solicitação de download. A unidade receptora 22 armazena o pacote de distribuição recebido na unidade de armazenamento 23. A unidade de controle 24 verifica a autenticidade dos dados de atualização contidos no pacote de distribuição recebido. Na etapa S14, a unidade de controle 24 pode determinar antes do download se o download pode ser realizado. Na etapa S14, após o download ser concluído, a unidade de transmissão 21 pode enviar uma notificação de que o download foi concluído para o servidor 1. O processo, então, prossegue para a etapa S15.
[044] Na etapa S15, a unidade de controle 24 realiza um processo de instalação e um processo de ativação para a unidade de controle eletrônico alvo. Mais especificamente, a unidade de controle 24 transfere os dados de atualização contidos no pacote de distribuição para a unidade de controle eletrônico alvo e instrui a unidade de controle eletrônico alvo para instalar os dados de atualização. A unidade de controle eletrônico alvo grava os dados de atualização recebidos do OTA mestre 11 para a área de armazenamento de dados. A unidade de controle 24 então instrui a unidade de controle eletrônico alvo para ativar a versão atualizada do software. A unidade de controle eletrônico alvo é reiniciada quando uma operação específica como desligar da fonte de alimentação ou ignição é realizado, e executa o software atualizado. O processo, então, prossegue para a etapa S16.
[045] Quando a unidade de controle eletrônico alvo inclui uma memória de banco único, o software na unidade de controle eletrônico alvo é afetado assim que os dados de atualização são instalados na área de armazenamento de dados. Portanto, o processo de instalação e o processo de ativação podem ser executados sucessivamente. Neste caso, quando a unidade de controle eletrônico alvo tem uma área de armazenamento de dados, um processo de solicitação de aceitação tanto para a instalação quanto para a ativação pode ser realizado antes da execução da instalação, e um processo de solicitação de aceitação antes da execução da ativação pode ser omitido.
[046] A unidade de controle 24 pode realizar um processo para determinar se a instalação pode ser executada e um processo de solicitação de aceitação para a instalação antes da execução da instalação. Por exemplo, como o processo de solicitação de aceitação para a instalação, a unidade de controle 24 faz com que o dispositivo de exibição 14 exiba uma indicação que uma atualização de software na unidade de controle eletrônico é iniciada, uma solicitação para o usuário para aceitar a atualização de software, e se necessário, o tempo necessário para instalar os dados de atualização e restrições e cuidados durante a instalação, e recebe uma entrada de operação realizada pelo usuário usando meios de entrada, como painel de toque ou botão de operação. A unidade de controle 24 então determina se uma entrada de operação aceitando a atualização de software (instalação) foi realizada. Por exemplo, se a entrada de operação aceitando a instalação foi realizada pode ser determinado com base em se um botão como “aceitar” ou “iniciar atualização” exibido no dispositivo de exibição 14 foi pressionado. Quando o usuário não deseja aceitar o início da atualização do software (instalação) imediatamente, mas deseja iniciar a atualização do software (instalação) mais tarde, essa intenção pode ser recebida quando um botão como “mais tarde” é pressionado.
[047] Da mesma forma, a unidade de controle 24 pode realizar um processo para determinar se a ativação pode ser executada e um processo de solicitação de aceitação para a ativação antes da execução da ativação. Por exemplo, como o processo de solicitação de aceitação para a ativação, a unidade de controle 24 faz com que o dispositivo de exibição 14 exiba uma indicação que a atualização de software na unidade de controle eletrônico está pronta para ser realizada e que o programa será atualizado quando uma operação específica como desligar da fonte de alimentação ou ignição é realizada, e se necessário, o tempo necessário para a ativação e restrições e cuidados durante a ativação, e recebe uma entrada de operação realizado pelo usuário usando os meios de entrada como painel de toque ou botão de operação. A unidade de controle 24 então determina se uma entrada de operação aceitando a atualização de software (ativação) foi realizada. Por exemplo, se a entrada de operação aceitando a ativação foi realizada pode ser determinado com base em se um botão como “aceitar” ou “atualizar” exibido no dispositivo de exibição 14 foi pressionado. Quando o usuário não deseja aceitar a atualização do software (ativação) imediatamente, mas deseja executá-la posteriormente, essa intenção pode ser recebida quando um botão como “mais tarde” é pressionado.
[048] Na etapa S16, a unidade de controle 24 determina se o processo de atualização de software para a unidade de controle eletrônico alvo foi concluído com sucesso. A unidade de controle 24 faz a determinação da etapa S16 com base em uma notificação da unidade de controle eletrônico alvo. Por exemplo, a unidade de controle 24 determina que o processo de atualização de software para a unidade de controle eletrônico alvo foi concluído com sucesso quando a unidade de controle 24 adquire da unidade de controle eletrônico alvo uma notificação que o software atualizado foi ativado com sucesso e informações de identificação do software ativado na unidade de controle eletrônico alvo e confirma com base nas informações adquiridas que o software na unidade de controle eletrônico alvo foi atualizado com software apropriado. Quando YES na etapa S16, o processo prossegue para a etapa S17. De outro modo, o processo prossegue para a etapa S18.
[049] Na etapa S17, a unidade de controle 24 deleta os dados de atualização armazenados na unidade de armazenamento 23. A unidade de controle 24 pode sequencialmente deletar os dados de atualização para cada unidade de controle eletrônico alvo ou pode deletar todo o pacote de distribuição quando o processo de atualização de software é concluído com sucesso em todas as unidades de controle eletrônico alvo. Portanto, o processo termina.
[050] Na etapa S18, a unidade de controle 24 repete o processo de instalação e o processo de ativação para qualquer unidade de controle eletrônico alvo para o qual o processo de atualização de software não foi concluído com sucesso. Quando o processo de atualização de software para a unidade de controle eletrônico alvo não é concluído com sucesso, a unidade de controle 24 não deleta os dados de atualização para o software na unidade de controle eletrônico alvo mas faz com que a unidade de armazenamento 23 retenha os dados de atualização para o software na unidade de controle eletrônico alvo. Isso permite que a unidade de controle 24 repita prontamente o processo de atualização de software com base nos dados de atualização retidos na unidade de armazenamento 23 sem fazer download novamente dos dados de atualização para o software na unidade de controle eletrônico alvo do servidor 1.
[051] Na etapa S18, como na etapa S15, a unidade de controle 24 transfere os dados de atualização contidos no pacote de distribuição para a unidade de controle eletrônico alvo e instrui a unidade de controle eletrônico alvo para instalar os dados de atualização. A unidade de controle eletrônico alvo grava os dados de atualização recebido do OTA mestre 11 para a área de armazenamento de dados. A unidade de controle 24 então instrui a unidade de controle eletrônico alvo para ativar a versão atualizada do software. A unidade de controle eletrônico alvo é reiniciada quando uma operação específica como desligar da fonte de alimentação ou ignição é realizada, e executa o software atualizado. O processo, então, prossegue para a etapa S19.
[052] Na etapa S19, a unidade de controle 24 determina se o processo de atualização de software para a unidade de controle eletrônico alvo foi concluído com sucesso. Como na etapa S16, a unidade de controle 24 adquire da unidade de controle eletrônico alvo uma notificação que o software atualizado foi ativado com sucesso e informações de identificação do software ativado na unidade de controle eletrônico alvo. A unidade de controle 24 determina que o processo de atualização de software para a unidade de controle eletrônico alvo foi concluído com sucesso quando a unidade de controle 24 confirma com base nas informações adquiridas que o software na unidade de controle eletrônico alvo foi atualizado com software apropriado. Quando YES na etapa S19, o processo prossegue para a etapa S17. De outro modo, o processo prossegue para a etapa S20.
[053] Na etapa S20, a unidade de controle 24 realiza tratamento de erro. Como o tratamento de erro, a unidade de controle 24 pode realizar, por exemplo, um dos seguintes processos: um processo de reversão de software para a unidade de controle eletrônico alvo, notificando que a atualização do software na unidade de controle eletrônico falhou, e dando uma notificação encorajando o usuário a consertá-lo em uma concessionária ou oficina. Depois disso, o processo termina.
[054] No exemplo mostrado na Figura 3, tratamento de erro é realizado (S20) quando o processo de instalação e o processo de ativação são repetidos uma vez (S18) e a atualização de software não é concluída com sucesso (NO em S19). Etapas S18 e S19 podem ser repetidas um pluralidade de tempos.
[055] Como descrito acima, o OTA mestre 11 de acordo com a presente modalidade retém os dados de atualização na unidade de armazenamento 23 até que o processo de atualização de software para a unidade de controle eletrônico alvo seja concluído com sucesso. O OTA mestre 11 deleta os dados de atualização da unidade de armazenamento 23 após o processo de atualização de software para a unidade de controle eletrônico alvo ser concluído com sucesso. Consequentemente, os dados de atualização retidos na unidade de armazenamento 23 podem ser reutilizados quando o processo de atualização de software para a unidade de controle eletrônico alvo não é concluído com sucesso.
[056] Na presente modalidade, quando o processo de atualização de software para a unidade de controle eletrônico alvo não é concluído com sucesso, a unidade de controle 24 repete o processo de atualização de software com base nos dados de atualização retidos na unidade de armazenamento 23. Com este controle, a unidade de controle eletrônico alvo pode ser prontamente atualizada, independentemente da condição de comunicação.
[057] Embora a memória na unidade de controle eletrônico alvo possa ser uma memória de banco único ou uma memória de banco duplo, o OTA mestre 11 de acordo com a presente modalidade é particularmente eficaz quando a unidade de controle eletrônico alvo inclui uma memória de banco único. Quando a memória na unidade de controle eletrônico alvo é uma memória de banco duplo em que, durante a execução de um programa armazenado em um banco de dois bancos, um programa pode ser gravado no outro dos dois bancos, a unidade de controle eletrônico pode ser operada usando o software antes da atualização, mesmo se uma atualização do software falhar. Por outro lado, quando a memória na unidade de controle eletrônico alvo inclui uma memória de banco único, o software antes da atualização é regravado pela instalação da versão atualizada do software. Portanto, a unidade de controle eletrônico não pode ser operada usando o software antes da atualização se o processo de atualização do software falhar. Ou seja, é preferível que, quando uma atualização de software na unidade de controle eletrônico alvo incluindo uma memória de banco único, falhar, o processo de atualização de software possa ser repetido o mais rápido possível. Quando uma atualização de software na unidade de controle eletrônico alvo falha, o OTA mestre 11 de acordo com a presente modalidade pode repetir o processo de atualização de software no menor tempo possível usando os dados de atualização retidos na unidade de armazenamento 23. O OTA mestre 11 de acordo com a presente modalidade pode, assim, restaurar rapidamente a falha.
[058] Como descrito acima, quando uma atualização de software na unidade de controle eletrônico tendo uma memória de banco duplo falha, a unidade de controle eletrônico pode continuar a ser operada usando o software antes da atualização. Portanto, quando a unidade de controle eletrônico alvo tem uma memória de banco duplo, a unidade de controle 24 pode deletar os dados de atualização da unidade de armazenamento 23 após a transferência dos dados de atualização para a unidade de controle eletrônico alvo ser concluída no processo de instalação. A unidade de controle 24 faz com que a unidade de armazenamento 23 retenha os dados de atualização para a unidade de controle eletrônico alvo incluindo uma memória de banco único até que o processo de atualização de software seja concluído com sucesso. Por outro lado, ao deletar os dados de atualização para o software na unidade de controle eletrônico alvo com a memória de banco duplo que pode ser operado com o software antes da atualização, mesmo após o processo de atualização do software ser iniciado, a capacidade de armazenamento da unidade de armazenamento 23 do OTA mestre 11 é garantido e a influência em outros processos de controle é reduzida.
Outras Modificações
[059] As funções do OTA mestre 11 ilustradas na modalidade acima podem ser implementadas como um método de controle de atualização de software que é realizado por um computador no veículo incluindo um processador (CPU), uma memória, e um dispositivo de armazenamento, como um programa de controle de atualização de software que faz com que o computador no veículo realize as funções, ou como um meio de armazenamento não transitório legível por computador, armazenando o programa de controle de atualização de software. As funções do OTA mestre 11 ilustradas na modalidade acima também podem ser implementadas como um microcomputador equipado com um método de controle de atualização de software ou um microcomputador tendo um programa de controle de atualização instalado em um dispositivo de armazenamento.
[060] No exemplo descrito na modalidade acima, o OTA mestre 11 na rede no veículo controla as atualizações do programa em todas as unidades de controle eletrônico 13a a 13d. Entretanto, em vez de fornecer o OTA mestre 11, uma das unidades de controle eletrônico 13a a 13d pode ter a função de controle de atualização mostrada na Figura 3 e pode controlar atualizações de software nas outras unidades de controle eletrônico. Em vez de fornecer o OTA mestre 11, um dispositivo externo que pode ser conectado à rede no veículo 2 por fio pode ter a função de controle de atualização mostrada na Figura 3, e o processo de atualização do programa para as unidades de controle eletrônico 13a a 13d pode ser realizado usando este dispositivo externo.
[061] A técnica divulgada pode ser usada em um sistema de rede para atualizar um programa para uma unidade de controle eletrônico.

Claims (9)

  1. Over-the-air (OTA) mestre (11), CARACTERIZADO pelo fato de que compreende:
    uma unidade receptora (22) configurada para receber dados de atualização para software em uma unidade de controle eletrônico alvo (13a, 13b, 13c, 13d) de um centro;
    uma unidade de armazenamento (23) configurada para armazenar os dados de atualização; e
    uma unidade de controle (24) configurada para:
    controlar um processo de atualização de software para a unidade de controle eletrônico alvo (13a, 13b, 13c, 13d) com base nos dados de atualização;
    fazer com que a unidade de armazenamento (23) retenha os dados de atualização até que o processo de atualização de software para a unidade de controle eletrônico alvo (13a, 13b, 13c, 13d) seja concluído com sucesso; e
    deletar os dados de atualização da unidade de armazenamento (23) após o processo de atualização de software para a unidade de controle eletrônico alvo (13a, 13b, 13c, 13d) ser concluído com sucesso.
  2. OTA mestre (11), de acordo com a reivindicação 1, CARACTERIZADO pelo fato de que a unidade de controle (24) está configurada para repetir a atualização de software para a unidade de controle eletrônico alvo (13a, 13b, 13c, 13d) com base nos dados de atualização retidos na unidade de armazenamento (23) quando o processo de atualização de software para a unidade de controle eletrônico alvo (13a, 13b, 13c, 13d) não é concluído com sucesso.
  3. OTA mestre (11), de acordo com a reivindicação 1 ou 2, CARACTERIZADO pelo fato de que a unidade de controle eletrônico alvo (13a, 13b, 13c, 13d) inclui uma memória de banco único.
  4. OTA mestre (11), de acordo com a reivindicação 1, CARACTERIZADO pelo fato de que a unidade de controle (24) é configurada para, após a transferência dos dados de atualização para a unidade de controle eletrônico alvo (13a, 13b, 13c, 13d) no processo de atualização de software:
    fazer com que a unidade de armazenamento (23) retenha os dados de atualização para a unidade de controle eletrônico alvo (13a, 13b, 13c, 13d) incluindo uma memória de banco único; e
    deletar os dados de atualização para a unidade de controle eletrônico alvo (13a, 13b, 13c, 13d) incluindo uma memória de banco duplo da unidade de armazenamento (23).
  5. OTA mestre (11), de acordo com qualquer uma das reivindicações 1 a 4, CARACTERIZADO pelo fato de que a unidade de controle eletrônico alvo é montada em um veículo e uma unidade de controle eletrônico do qual software é um alvo da atualização de software.
  6. OTA mestre (11), de acordo com a reivindicação 4, CARACTERIZADO pelo fato de que a unidade de controle eletrônico alvo (13a, 13b, 13c, 13d) incluindo a memória de banco duplo está configurada para ser operável, mesmo após o processo de atualização de software ser iniciado, com o software antes do processo de atualização de software ser iniciado.
  7. Método de controle de atualização de software que é realizado por um computador incluindo um processador, uma memória, e um dispositivo de armazenamento, o método de controle de atualização de software CARACTERIZADO pelo fato de que compreende:
    receber dados de atualização para software em uma unidade de controle eletrônico alvo (13a, 13b, 13c, 13d) de um centro;
    armazenar os dados de atualização no dispositivo de armazenamento;
    controlar um processo de atualização de software para a unidade de controle eletrônico alvo (13a, 13b, 13c, 13d) com base nos dados de atualização;
    reter os dados de atualização até que o processo de atualização de software para a unidade de controle eletrônico alvo (13a, 13b, 13c, 13d) seja concluído com sucesso; e
    deletar os dados de atualização do dispositivo de armazenamento após o processo de atualização de software para a unidade de controle eletrônico alvo (13a, 13b, 13c, 13d) ser concluído com sucesso.
  8. Meio de armazenamento não transitório que armazena um programa de controle de atualização de software que é executável por um computador incluindo um processador, uma memória, e um dispositivo de armazenamento e que faz com que o computador realize funções, CARACTERIZADO pelo fato de que compreende:
    receber dados de atualização para software em uma unidade de controle eletrônico alvo (13a, 13b, 13c, 13d) de um centro;
    armazenar os dados de atualização no dispositivo de armazenamento;
    controlar um processo de atualização de software para a unidade de controle eletrônico alvo (13a, 13b, 13c, 13d) com base nos dados de atualização;
    reter os dados de atualização até que o processo de atualização de software para a unidade de controle eletrônico alvo (13a, 13b, 13c, 13d) seja concluído com sucesso; e
    deletar os dados de atualização do dispositivo de armazenamento após o processo de atualização de software para a unidade de controle eletrônico alvo (13a, 13b, 13c, 13d) ser concluído com sucesso.
  9. Veículo, CARACTERIZADO pelo fato de que compreende o OTA mestre (11), conforme definido em qualquer uma das reivindicações 1 a 6.
BR102022000011-5A 2021-02-02 2022-01-03 Ota mestre, método de controle de atualização, meio de armazenamento não transitório, e veículo BR102022000011A2 (pt)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2021015293A JP7452452B2 (ja) 2021-02-02 2021-02-02 Ｏｔａマスタ、ソフトウェアの更新制御方法及び更新制御プログラム、ｏｔａマスタを備える車両
JP2021-015293 2021-02-02

Publications (1)

Publication Number Publication Date
BR102022000011A2 true BR102022000011A2 (pt) 2022-08-16

Family

ID=78820142

Family Applications (1)

Application Number Title Priority Date Filing Date
BR102022000011-5A BR102022000011A2 (pt) 2021-02-02 2022-01-03 Ota mestre, método de controle de atualização, meio de armazenamento não transitório, e veículo

Country Status (6)

Country Link
US (1) US20220244946A1 (pt)
EP (1) EP4036712A1 (pt)
JP (1) JP7452452B2 (pt)
KR (2) KR102669611B1 (pt)
CN (1) CN114844874A (pt)
BR (1) BR102022000011A2 (pt)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11886860B2 (en) * 2021-09-27 2024-01-30 Red Hat, Inc. Distribution of digital content to vehicles

Family Cites Families (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6532152B1 (en) * 1998-11-16 2003-03-11 Intermec Ip Corp. Ruggedized hand held computer
JP2004326689A (ja) 2003-04-28 2004-11-18 Nissan Motor Co Ltd 車載機器のソフトウェア書き換え方法、テレマティクスシステムおよびテレマティクス装置
US8472920B2 (en) * 2009-01-22 2013-06-25 Belair Networks Inc. System and method for providing wireless networks as a service
US9015837B1 (en) * 2011-09-29 2015-04-21 Google Inc. Systems and methods for verifying an update to data of an electronic device
US10127036B2 (en) * 2015-06-15 2018-11-13 Lear Corporation Method for OTA updating vehicle electronic control unit
US10114634B2 (en) * 2016-01-22 2018-10-30 2236008 Ontario Inc. Updating a controller unit in a vehicle
US12001825B2 (en) * 2016-02-19 2024-06-04 Ford Global Technologies, Llc Method and apparatus for vehicle software update installation
JP6696468B2 (ja) * 2016-08-30 2020-05-20 株式会社オートネットワーク技術研究所 車載更新装置及び車載更新システム
JP6682019B2 (ja) * 2017-01-25 2020-04-15 日立オートモティブシステムズ株式会社 プログラム更新システムおよびプログラム書込装置
KR102249599B1 (ko) * 2017-03-21 2021-05-07 현대자동차 주식회사 차량 모듈의 소프트웨어 업데이트 정보 제공 서버 및 방법
DE102017218872A1 (de) 2017-10-23 2019-04-25 Robert Bosch Gmbh Verfahren und Vorrichtung zum Aktualisieren von Software eines Kfz-Steuergerätes
US10642602B2 (en) 2017-12-12 2020-05-05 Nxp Usa, Inc. NVM architecture with OTA support
US10834206B2 (en) * 2018-02-27 2020-11-10 Excelfore Corporation Broker-based bus protocol and multi-client architecture
JP7115429B2 (ja) * 2018-08-10 2022-08-09 株式会社デンソー 車両用マスタ装置、ロールバックの実行制御方法及びロールバックの実行制御プログラム
JP6832374B2 (ja) 2019-02-22 2021-02-24 本田技研工業株式会社 ソフトウェア更新装置、車両及びソフトウェア更新方法
JP7111030B2 (ja) * 2019-03-04 2022-08-02 株式会社オートネットワーク技術研究所 車載更新装置、更新処理プログラム及び、プログラムの更新方法
JP6780724B2 (ja) 2019-03-18 2020-11-04 株式会社オートネットワーク技術研究所 車載更新装置、更新処理プログラム及び、プログラムの更新方法
JP7177755B2 (ja) * 2019-07-24 2022-11-24 株式会社日立製作所 サーバ、ソフトウェア更新システム、およびソフトウェア更新装置
JP7395962B2 (ja) * 2019-10-31 2023-12-12 株式会社リコー 情報処理装置、更新制御方法、更新制御プログラム、及び情報処理システム
KR20210151498A (ko) * 2020-06-05 2021-12-14 현대자동차주식회사 차량 업데이트 시스템 및 방법

Also Published As

Publication number Publication date
KR20240078424A (ko) 2024-06-03
JP2022118631A (ja) 2022-08-15
CN114844874A (zh) 2022-08-02
US20220244946A1 (en) 2022-08-04
KR20220111648A (ko) 2022-08-09
JP7452452B2 (ja) 2024-03-19
KR102669611B1 (ko) 2024-05-28
EP4036712A1 (en) 2022-08-03

Similar Documents

Publication Publication Date Title
US11436002B2 (en) Systems and methods for failsafe firmware upgrades
BR102022000011A2 (pt) Ota mestre, método de controle de atualização, meio de armazenamento não transitório, e veículo
CN109375953B (zh) 一种操作系统启动方法及装置
JP2018160207A (ja) 車載制御装置、及び、プログラム更新ソフトウェア
JP2012093961A (ja) 制御装置及び方法、並びにプログラム書込システム
JP7230768B2 (ja) 電子制御装置、セッション確立プログラム及び制御プログラム
US20220391192A1 (en) Ota master, center, system, method, non-transitory storage medium, and vehicle
JP7484791B2 (ja) Ｏｔａマスタ、更新制御方法、及び更新制御プログラム
US11995429B2 (en) Software update device, update control method, non-transitory storage medium, and server
JP6935694B2 (ja) 電子制御装置
JP2019160133A (ja) 情報処理装置、情報処理システムおよび方法
US20220391193A1 (en) Ota master, system, method, non-transitory storage medium, and vehicle
BR102022007514A2 (pt) Centro, ota mestre, sistema, método de distribuição, meio de armazenamento não transitório, e veículo
BR102022002896A2 (pt) Mestre de ota, centro, sistema, método de atualização, meio de armazenamento não transitório, e veículo
US11954480B2 (en) Center, OTA master, system, method, non-transitory storage medium, and vehicle
US20220405080A1 (en) Ota master, system, method, non-transitory storage medium, and vehicle
JP7512908B2 (ja) センタ、管理方法および管理プログラム
JP7355061B2 (ja) センタ、ｏｔａマスタ、システム、配信方法、配信プログラム、及び車両
JP7418494B2 (ja) 更新管理システムおよび更新管理方法
US20230032451A1 (en) Center, method, and non-transitory storage medium
US20220342653A1 (en) Ota master, center, system, update method, non-transitory storage medium, and vehicle
US20230252153A1 (en) Electronic control device and updating method for control software
US20240211257A1 (en) Cache to Receive Firmware Generated Data During Firmware Update
US20230143921A1 (en) Electronic control system, storage medium storing data structure of software package, and storage medium storing computer program
CN117369847A (zh) 升级固件的方法、电子设备和存储介质

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]