BR102022002896A2

BR102022002896A2 - Mestre de ota, centro, sistema, método de atualização, meio de armazenamento não transitório, e veículo

Info

Publication number: BR102022002896A2
Application number: BR102022002896-6A
Authority: BR
Inventors: Tomoyasu Ishikawa; Shunsuke TANIMORI
Original assignee: Toyota Jidosha Kabushiki Kaisha
Priority date: 2021-02-18
Filing date: 2022-02-15
Publication date: 2022-08-30
Also published as: KR20220118324A; CN114968316A; JP2022126194A; EP4047477A1; US20220276853A1

Abstract

Um mestre de OTA (30) é configurado para controlar a atualização de software para uma unidade de controle eletrônico (40a; 40b; 40c; 40d) montada em um veículo. O mestre de OTA (30) inclui uma unidade de comunicação (38) configurada para receber, de um centro (10), um pacote de distribuição incluindo dados de atualização para uma unidade de controle eletrônico (40a) na qual uma memória não volátil de primeiro tipo (43a) tendo uma área de armazenamento está montada e dados de atualização para uma unidade de controle eletrônico (40b) na qual uma memória não volátil de segundo tipo (43b) tendo duas áreas de armazenamento está montada.

Description

MESTRE DE OTA, CENTRO, SISTEMA, MÉTODO DE ATUALIZAÇÃO, MEIO DE ARMAZENAMENTO NÃO TRANSITÓRIO, E VEÍCULO

CAMPO DA INVENÇÃO

[001] A presente invenção refere-se a um mestre de OTA, um centro, um sistema, um método de atualização, um meio de armazenamento não transitório e um veículo.

FUNDAMENTOS DA INVENÇÃO

[002] Uma pluralidade de unidades de controle eletrônico usadas para controlar uma operação de um veículo está montada em um veículo. A unidade de controle eletrônico inclui um processador, uma unidade de armazenamento não transitória, como uma memória de acesso aleatório (RAM), e uma memória não volátil que é uma unidade de armazenamento não volátil, como uma memória flash somente para leitura (ROM) Uma função de controle da unidade de controle eletrônico é implementada quando o processador executa o software armazenado na memória não volátil. O software armazenado em cada unidade de controle eletrônico é regravável e, ao atualizar para uma versão mais recente do software, é possível melhorar uma função de cada unidade de controle eletrônico ou adicionar uma nova função de controle veicular.

[003] Como uma tecnologia para atualização de software de uma unidade de controle eletrônico, uma tecnologia over-the-air (OTA) é bem conhecida. Na tecnologia OTA, um dispositivo que se conecta sem fio a um dispositivo de comunicação no veículo conectado a uma rede no veículo a uma rede de comunicação, como a Internet, executa o processamento de atualização de software das atualizações do veículo ou adiciona o software do controle eletrônico unidade baixando o software de um servidor por meio de comunicação sem fio e instalando o software baixado na unidade de controle eletrônico (ver, por exemplo, a Publicação de Pedido de Patente Japonesa Não Examinado No 2004-326689).

[004] Como tipos de memórias não voláteis montadas na unidade de controle letrônico, há uma memória (uma memória de banco único) que tem uma área de armazenamento usada para armazenar dados, como software, e uma memória (uma memória de banco duplo) que tem duas áreas de armazenamento usadas para armazenar dados, como software. As memórias não voláteis podem ser usadas em conformidade com as especificações ou semelhante da unidade de controle eletrônico. Uma unidade de controle eletrônico com a memória de banco duplo montada na mesma pode armazenar duas versões de dados, antigos e novos, nas duas áreas de armazenamento, respectivamente.

SUMÁRIO DA INVENÇÃO

[005] Em uma campanha, que é um evento de atualização de software para veículos, há um caso em que tanto uma unidade de controle eletrônico com uma memória de banco único montada na mesma quanto uma unidade de controle eletrônico com uma memória de banco duplo montada na mesma são unidades de controle eletrônico do qual o software deve ser atualizado. Devido às estruturas das memórias, a unidade de controle eletrônico com a memória de banco único montada na mesma e a unidade de controle eletrônico com a memória de banco duplo montada na mesma têm métodos de recuperação diferentes quando a atualização falha.

[006] Há casos em que é aplicada a um veículo uma campanha na qual a unidade de controle eletrônico tendo a memória de banco único montada na mesma e a unidade de controle eletrônico tendo a memória de banco duplo montada na mesma são misturadas como as unidades de controle eletrônico a serem atualizadas. Neste caso, é desejável executar download e instalação de software apropriados de acordo com as estruturas das memórias montadas na unidade de controle eletrônico a ser atualizada.

[007] A presente invenção provê um mestre de OTA, um centro, um sistema, um método de atualização, um meio de armazenamento não transitório e um veículo que podem executar atualização de software adaptada a uma memória de banco único e uma memória de banco duplo.

[008] Um mestre de OTA, de acordo com um primeiro aspecto da presente invenção, é configurado para controlar a atualização de software para uma unidade de controle eletrônico montada em um veículo. O mestre de OTA inclui uma unidade de comunicação configurada para receber, de um centro, um pacote de distribuição incluindo dados de atualização para a unidade de controle eletrônico na qual uma memória não volátil de primeiro tipo com uma área de armazenamento está montada e dados de atualização para a unidade de controle eletrônico em que uma memória não volátil de segundo tipo com duas áreas de armazenamento está montada.

[009] No primeiro aspecto, o mestre de OTA pode ainda incluir uma unidade de controle configurada para, com base nas informações de tipo que indicam se a memória não volátil montada na unidade de controle eletrônico é do primeiro tipo ou do segundo tipo, transferir os dados de atualização recebidos pela unidade de comunicação para a unidade de controle eletrônico a ser atualizada.

[010] No primeiro aspecto, a unidade de comunicação pode adquirir as informações de tipo do centro.

[011] No primeiro aspecto, o mestre de OTA pode ainda incluir uma unidade de armazenamento configurada para armazenar as informações de tipo.

[012] No primeiro aspecto, a unidade de controle pode transferir os dados de atualização para a unidade de controle eletrônico a ser atualizada com prioridade, com base nas informações de tipo, para os dados de atualização para a unidade de controle eletrônico na qual a memória não volátil de segundo tipo está montada sobre os dados de atualização para a unidade de controle eletrônico na qual a memória não volátil de primeiro tipo está montada.

[013] Um centro, de acordo com um segundo aspecto da presente invenção, é configurado para se comunicar com um mestre de OTA que controla a atualização de software para uma unidade de controle eletrônico montada em um veículo. O centro inclui uma unidade de comunicação configurada para transmitir, para o mestre de OTA, um pacote de distribuição incluindo dados de atualização para a unidade de controle eletrônico na qual uma memória não volátil de primeiro tipo com uma área de armazenamento está montada e a unidade de controle eletrônico na qual um memória não volátil de segundo tipo com duas áreas de armazenamento está montada.

[014] No segundo aspecto, o centro pode incluir ainda uma unidade de armazenamento configurada para armazenar informações de tipo indicando se a memória não volátil montada na unidade de controle eletrônico é do primeiro tipo ou do segundo tipo.

[015] No segundo aspecto, a unidade de comunicação pode transmitir as informações de tipo armazenadas na unidade de armazenamento para o mestre de OTA.

[016] Um sistema, de acordo com um terceiro aspecto da presente invenção, inclui um mestre de OTA configurado para controlar a atualização de software para uma unidade de controle eletrônico montada em um veículo e um centro configurado para se comunicar com o mestre de OTA. O centro inclui uma unidade de comunicação configurada para transmitir, para o mestre de OTA, um pacote de distribuição incluindo dados de atualização para a unidade de controle eletrônico na qual uma memória não volátil de primeiro tipo com uma área de armazenamento está montada e dados de atualização para a unidade de controle eletrônico em que uma memória não volátil de segundo tipo com duas áreas de armazenamento está montada. O mestre de OTA inclui uma unidade de comunicação configurada para receber o pacote de distribuição transmitido pelo centro.

[017] No terceiro aspecto, o mestre de OTA pode incluir uma unidade de controle configurada para transferir os dados de atualização para a unidade de controle eletrônico a ser atualizada com prioridade, com base em informações de tipo indicando se a memória não volátil montada na unidade de controle eletrônico é do primeiro tipo ou do segundo tipo, para os dados de atualização para a unidade de controle eletrônico montada na memória não volátil de segundo tipo sobre os dados de atualização para a unidade de controle eletrônico montada na memória não volátil de primeiro tipo. Os dados de atualização para a unidade de controle eletrônico montada na memória não volátil de segundo tipo e os dados de atualização para a unidade de controle eletrônico montada na memória não volátil de primeiro tipo estão incluídos no pacote de distribuição.

[018] No terceiro aspecto, pelo menos um dentre o centro e o mestre de OTA podem incluir uma unidade de armazenamento configurada para armazenar as informações de tipo.

[019] Um quarto aspecto da presente invenção é um método de atualização executado por um mestre de OTA. O mestre de OTA inclui um processador e uma memória e é configurado para controlar a atualização de software para uma unidade de controle eletrônico montada em um veículo. O método de atualização inclui uma etapa de receber, pelo mestre de OTA, de um centro, um pacote de distribuição incluindo dados de atualização para a unidade de controle eletrônico na qual uma memória não volátil de primeiro tipo com uma área de armazenamento está montada e dados de atualização para o unidade de controle eletrônico na qual uma memória não volátil de segundo tipo com duas áreas de armazenamento está montada e uma etapa de transferência, pelo mestre de OTA, dos dados de atualização para a unidade de controle eletrônico para ser atualizado com prioridade, com base em informações de tipo indicando se a memória não volátil montada na unidade de controle eletrônico é do primeiro tipo ou do segundo tipo, para os dados de atualização para a unidade de controle eletrônico na qual a memória não volátil de segundo tipo está montada sobre os dados de atualização para a unidade de controle eletrônico em que a memória não volátil de primeiro tipo está montada.

[020] Um meio de armazenamento não transitório, de acordo com um quinto aspecto da presente invenção, armazena um comando executável por um processador de um mestre de OTA. O mestre de OTA inclui o processador e uma atualização de software de memória e controles para uma unidade de controle eletrônico montada em um veículo. O comando faz com que o processador execute funções incluindo receber, pelo mestre de OTA, de um centro, um pacote de distribuição incluindo dados de atualização para a unidade de controle eletrônico na qual uma memória não volátil de primeiro tipo com uma área de armazenamento está montada e dados de atualização para a unidade de controle eletrônico na qual uma memória não volátil de segundo tipo com duas áreas de armazenamento está montada e transfere, pelo mestre de OTA, os dados de atualização para a unidade de controle eletrônico a serem atualizados com prioridade, com base em informações de tipo indicando se a memória não volátil montada na unidade de controle eletrônico é do primeiro tipo ou do segundo tipo, para os dados de atualização para a unidade de controle eletrônico na qual a memória não volátil de segundo tipo está montada sobre os dados de atualização para a unidade de controle eletrônico em que a memória não volátil de primeiro tipo está montada.

[021] Um veículo, de acordo com um sexto aspecto da presente invenção, inclui um mestre de OTA configurado para controlar a atualização de software para uma unidade de controle eletrônico montada em um veículo. O mestre de OTA inclui uma unidade de comunicação configurada para receber, de um centro, um pacote de distribuição incluindo dados de atualização para a unidade de controle eletrônico na qual uma memória não volátil de primeiro tipo com uma área de armazenamento está montada e dados de atualização para a unidade de controle eletrônico em que uma memória não volátil de segundo tipo com duas áreas de armazenamento está montada

[022] Com cada aspecto da presente invenção, é possível prover um mestre de OTA, um centro, um sistema, um método de atualização, um meio de armazenamento não transitório e um veículo que pode executar atualização de software adaptada a um único banco memória e uma memória de banco duplo.

BREVE DESCRIÇÃO DOS DESENHOS

[023] Características, vantagens e significado técnico e industrial de modalidades exemplares da invenção serão descritas abaixo com referência aos desenhos anexos, nos quais sinais semelhantes denotam elementos semelhantes, e em que:
a Figura 1 é um diagrama de blocos que ilustra uma configuração geral de um sistema de rede de acordo com uma modalidade;
a Figura 2 é um diagrama de blocos que ilustra uma configuração esquemática de um centro;
a Figura 3 é um diagrama de blocos que ilustra uma configuração esquemática de um mestre de OTA;
a Figura 4A é um diagrama de blocos que ilustra um exemplo de uma configuração esquemática de uma unidade de controle eletrônico;
a Figura 4B é um diagrama de blocos que ilustra outro exemplo da configuração esquemática da unidade de controle eletrônico;
a Figura 5 é um diagrama de blocos funcional do centro;
a Figura 6 é um diagrama de blocos funcional do mestre de OTA;
a Figura 7 é um diagrama que ilustra um exemplo de informações de tipo;
a Figura 8 é um fluxograma dos procedimentos de processamento de download de acordo com um primeiro exemplo específico executado pelo centro e o mestre de OTA;
a Figura 9 é um fluxograma dos procedimentos de processamento de download de acordo com um segundo exemplo específico executado pelo centro e o mestre de OTA;
a Figura 10 é um fluxograma de procedimentos de processamento de instalação de acordo com um terceiro exemplo específico executado pelo mestre de OTA e uma unidade de controle eletrônico alvo;
a Figura 11A é um fluxograma de procedimentos de processamento de instalação de acordo com um quarto exemplo específico executado pelo mestre de OTA e a unidade de controle eletrônico alvo;
a Figura 11B é outro fluxograma dos procedimentos de processamento de instalação de acordo com o quarto exemplo específico executado pelo mestre de OTA e a unidade de controle eletrônico alvo; e
a Figura 12 é um fluxograma de procedimentos de processamento de download/instalação de acordo com um quinto exemplo específico executado pelo centro, o mestre de OTA e a unidade de controle eletrônico alvo.

DESCRIÇÃO DETALHADA DE MODALIDADES

[024] Em um sistema de rede usado para atualizar um programa de uma unidade de controle eletrônico (ECU) da presente invenção, um centro e um mestre de OTA transmitem e recebem um do outro um pacote de distribuição no qual dados de atualização para uma ECU tendo um única memória de banco montada na mesma e dados de atualização para uma ECU tendo uma memória de banco duplo montada na mesma estão misturados. Assim, por exemplo, ao gerar um pacote de distribuição, o centro pode verificar a consistência entre um tipo de memória de uma ECU alvo e os dados de atualização, e priorizar a instalação em uma ECU alvo tendo a memória de banco duplo montada sobre a instalação em uma ECU alvo tendo a memória de banco único montada na mesma. A seguir, as modalidades da presente invenção serão descritas detalhadamente com referência aos desenhos.

Modalidades Configuração

[025] A Figura 1 é um diagrama de blocos que ilustra uma configuração geral de um sistema de rede de acordo com uma modalidade da presente invenção. O sistema de rede ilustrado na Figura 1 é usado para atualizar o software de uma pluralidade de ECUs 40a a 40d montadas em um veículo e inclui um centro 10 fora do veículo e uma rede dentro do veículo 20 construída dentro do veículo.

(1) Centro

[026] O centro 10 pode se comunicar com um mestre de OTA 30 incluído na rede no veículo 20 por meio de uma rede 70, e pode administrar a atualização de software para as ECUs 40a a 40d conectadas ao mestre de OTA 30. O mestre de OTA 30 será descrito abaixo. O centro 10 funciona como um chamado servidor.

[027] A Figura 2 é um diagrama de blocos que ilustra uma configuração esquemática do centro 10 na Figura 1. Conforme ilustrado na Figura 2, o centro 10 inclui uma unidade de processamento central (CPU) 11, um RAM 12, um dispositivo de armazenamento 13, e um dispositivo de comunicação 14. O dispositivo de armazenamento 13 inclui um meio de armazenamento legível e gravável, como uma unidade de disco rígido (HDD) ou uma unidade de estado sólido (SSD), e armazena um programa usado para executar o administração de atualização de software, informações usadas para o administração de atualização de software, dados de atualização para cada ECU e assim por diante. No centro 10, a CPU 11 executa o processamento predeterminado para a atualização do software, executando um programa lido a partir do dispositivo de armazenamento 13 usando a RAM 12 como uma área de trabalho. O dispositivo de comunicação 14 é usado para se comunicar com o mestre de OTA 30 através da rede 70.

(2) Rede no Veículo

[028] A rede no veículo 20 inclui o Mestre de OTA 30, as ECUs 40a a 40d e um módulo de comunicação 50. O Mestre de OTA 30 é conectado ao módulo de comunicação 50 por meio de um barramento 60a, conectado às ECUs 40a, 40b através de um barramento 60b e conectado às ECUs 40c, 40d através de um barramento 60c.

[029] O mestre de OTA 30 pode se comunicar sem fio com o centro 10 através do módulo de comunicação 50. O mestre de OTA 30 tem funções de administração de um estado OTA e execução da atualização de software para uma ECU da qual o software deve ser atualizado (doravante também referido como uma “ECU alvo”) controlando uma sequência de atualização de software e, com base nos dados de atualização adquiridos do centro 10, controla a atualização de software para a ECU alvo entre as ECUs 40a a 40d. O mestre de OTA 30 também pode ser referido como um gateway central (CGW).

[030] As ECUs 40a a 40d são dispositivos usados para controlar uma operação de cada parte do veículo. Na Figura 1, quatro ECUs 40a a 40d estão ilustradas, mas o número de ECUs não é particularmente limitado. Por exemplo, o mestre de OTA 30 pode ser conectado a um dispositivo de exibição (um HMI) usado para executar várias exibições, como uma exibição que representa que há dados de atualização no momento da execução do processamento de atualização de software das ECUs 40a a 40d, uma exibição de uma tela de solicitação de aprovação para solicitar aprovação para a atualização de software de um usuário ou administrador do veículo e uma exibição de um resultado da atualização de software. Como dispositivo de exibição, por exemplo, um sistema de navegação automotivo pode ser usado. Além disso, o número de barramentos que conectam as ECUs ao mestre de OTA 30 também não é particularmente limitado. Por exemplo, o dispositivo de exibição descrito acima pode ser conectado ao Mestre de OTA 30 por meio de um barramento diferente dos barramentos 60a a 60c.

[031] O módulo de comunicação 50 é uma unidade com a função de controlar a comunicação entre o centro 10 e o veículo, e é um dispositivo de comunicação que faz a conexão entre a rede no veículo 20 e o centro 10. O módulo de comunicação 50 pode ser incluído no mestre de OTA 30.

[032] A Figura 3 é um diagrama de blocos que ilustra uma configuração esquemática do mestre de OTA 30 na Figura 1. Conforme ilustrado na Figura 3, o mestre de OTA 30 inclui uma CPU 31, um RAM 32, um ROM 33, um dispositivo de armazenamento 34, e um dispositivo de comunicação 36. A CPU 31, a RAM 32, a ROM 33 e o dispositivo de armazenamento 34 compõem um microcomputador 35. No mestre de OTA 30, a CPU 31 executa processamento predeterminado para a atualização de software executando um programa lido da ROM 33 usando a RAM 32 como área de trabalho. O dispositivo de comunicação 36 é usado para se comunicar com o módulo de comunicação 50 e as ECUs 40a a 40d através dos barramentos 60a a 60c ilustrados na Figura 1.

[033] Cada uma das Figuras 4A e 4B é um diagrama de blocos que ilustra um exemplo de uma configuração esquemática de uma ECU.

[034] A ECU 40a ilustrada na Figura 4A inclui uma CPU 41, uma RAM 42, uma memória não volátil 43a e um dispositivo de comunicação 44. A CPU 41 implementa uma função da ECU 40a executando o programa lido da memória não volátil 43a usando a RAM 42 como área de trabalho. A memória não volátil 43a é uma memória (uma memória de banco único) tendo uma área de armazenamento 45 usada para armazenar software. Doravante, um tipo de memória não volátil 43a configurada para ter uma área de armazenamento 45 é referido como um "primeiro tipo". Na área de armazenamento 45, além do software usado para implementar a função da ECU 40a, informações de versão, dados de parâmetro, um programa de inicialização para inicialização, um programa para atualização de software ou semelhantes podem ser armazenados. O dispositivo de comunicação 44 é usado para se comunicar com o mestre de OTA 30 ou outras ECUs 40b a 40d conectadas à rede no veículo 20.

[035] Semelhante à ECU 40a, a ECU 40b ilustrada na Figura 4B inclui a CPU 41, a RAM 42, uma memória não volátil 43b e o dispositivo de comunicação 44. No entanto, a memória não volátil 43b montada na ECU 40b é uma memória (uma memória de banco duplo) tendo duas áreas de armazenamento 46a, 46b usadas para armazenar programas. Doravante, um tipo de memória não volátil 43b configurada para ter as duas áreas de armazenamento 46a, 46b é referido como um "segundo tipo". Nas áreas de armazenamento 46a, 46b, além do software usado para implementar a função da ECU 40b, informações de versão, dados de parâmetro, um programa de inicialização para inicialização, um programa para atualização de software, ou semelhantes, podem ser armazenados. A CPU 41 da ECU 40b usa qualquer uma das duas áreas de armazenamento 46a, 46b incluídas na memória não volátil 43b como a área de armazenamento (um lado operacional) a ser lido e executa o software armazenado na área de armazenamento a ser lido. Na outra área de armazenamento (um lado não operacional) que não deve ser lido, o software de atualização (um programa de versão atualizada) pode ser instalado (escrito) com base nos dados de atualização em segundo plano enquanto o programa está na área de armazenamento (lado operacional) a ser lido está sendo executado. No processamento de atualização de software, no momento da execução da ativação (tornando o software de atualização eficaz), o software de atualização pode ser ativado ao mudar a área de armazenamento a partir da qual o programa é lido pela CPU 41 da ECU 40b.

[036] Como um exemplo específico, pressupõe-se que o software atual é armazenado na área de armazenamento 46a e o software de atualização é instalado na área de armazenamento 46b. Ao receber uma instrução sobre a ativação do software de atualização do mestre de OTA 30, a CPU 41 da ECU 40b pode alternar a área de armazenamento (o lado operacional) a ser lida da CPU 41 alternando, por exemplo, um endereço de início de leitura da CPU 41 da ECU 40b de um endereço principal da área de armazenamento 46a para um endereço principal da área de armazenamento 46b, e pode executar o software de atualização instalado na área de armazenamento 46b. Na presente invenção, uma configuração referida como uma "memória de suspensão unilateral" em que uma área de armazenamento é pseudodividida em dois lados e um programa pode ser escrito de um lado enquanto o programa armazenado do outro lado está sendo executado, também é classificada no segundo tipo de memória.

[037] A Figura 5 é um diagrama de blocos funcional do centro 10 ilustrado na Figura 2. O centro 10 ilustrado na Figura 5 inclui uma unidade de armazenamento 16, uma unidade de comunicação 17 e uma unidade de controle 18. A função da unidade de armazenamento 16 é implementado pelo dispositivo de armazenamento 13 ilustrado na Figura 2. As funções da unidade de comunicação 17 e da unidade de controle 18 são implementadas quando a CPU 11 ilustrada na Figura 2 executa um programa armazenado no dispositivo de armazenamento 13 usando a RAM 12.

[038] A unidade de armazenamento 16 armazena informações sobre o processamento de atualização de software de uma ou mais ECUs montadas no veículo. Como as informações sobre o processamento de atualização de software, a unidade de armazenamento 16 armazena informações de administração de atualização associadas a informações que indicam software utilizável na ECU para cada informação de identificação de veículo (um ID de veículo) para identificar o veículo e os dados de atualização do software do ECU. Como a informação que indica o software utilizável na ECU, por exemplo, uma combinação das informações da versão mais recente de cada parte de software de uma pluralidade de ECUs é definida.

[039] A unidade de comunicação 17 pode receber um pedido de confirmação de atualização de software do mestre de OTA 30. O pedido de confirmação de atualização é a informação que é transmitida do mestre de OTA 30 para o centro 10 e é para solicitar ao centro 10 para confirmar se há dados de atualização para a ECU quando, por exemplo, uma fonte de alimentação ou uma ignição (IGN) for ligada no veículo. Além disso, a unidade de comunicação 17 pode receber, do mestre de OTA 30, um pedido (um pedido de download) para transmitir o pacote de distribuição. Ao receber o pedido de download para o pacote de distribuição, a unidade de comunicação 17 transmite, para o mestre de OTA 30, o pacote de distribuição incluindo os dados de atualização do software da ECU gerados pela unidade de controle 18 descrita abaixo.

[040] Quando a unidade de comunicação 17 recebe o pedido de confirmação de atualização do mestre de OTA 30, a unidade de controle 18 determina, com base nas informações de administração de atualização armazenadas na unidade de armazenamento 16, se há os dados de atualização do software da ECU montada no veículo especificado pela ID do veículo incluída na solicitação de confirmação de atualização. No caso em que a unidade de controle 18 determina que há os dados de atualização do software da ECU, quando a unidade de controle 18 recebe a solicitação de download para o pacote de distribuição do mestre de OTA 30, a unidade de controle 18 gera o pacote de distribuição incluindo os dados de atualização armazenados na unidade de armazenamento 16.

[041] A unidade de controle 18 pode gerar individualmente um pacote de distribuição incluindo apenas os dados de atualização para a ECU tendo a memória não volátil de primeiro tipo (a memória de banco único) montada na mesma e um pacote de distribuição incluindo apenas os dados de atualização para a ECU tendo a memória não volátil de segundo tipo (a memória de banco duplo) montada na mesma. Alternativamente, a unidade de controle 18 pode gerar o pacote de distribuição incluindo os dados de atualização para a ECU tendo a memória não volátil de primeiro tipo (a memória de banco único) montada na mesma e os dados de atualização para a ECU tendo o segundo tipo não volátil memória (a memória de banco duplo) montada na mesma. Quando as informações de tipo descritas abaixo são armazenadas na unidade de armazenamento 16 com antecedência, a unidade de controle 18 pode gerar intencionalmente o pacote de distribuição no qual uma pluralidade de diferentes tipos de partes de dados de atualização está misturada. Ao gerar tal pacote de distribuição no qual a pluralidade de diferentes tipos de partes de dados de atualização está misturada, (a unidade de comunicação 17 do) centro 10 pode transmitir, para o mestre de OTA 30, o pacote de distribuição incluindo os dados de atualização para a ECU tendo a memória não volátil de primeiro tipo montada na mesma e os dados de atualização para a ECU tendo a memória não volátil de segundo tipo montada na mesma.

[042] A Figura 6 é um diagrama de blocos funcional do Mestre de OTA 30 ilustrado na Figura 2. O mestre de OTA 30 ilustrado na Figura 6 inclui uma unidade de armazenamento 37, uma unidade de comunicação 38 e uma unidade de controle 39. A função do armazenamento a unidade 37 é implementada pelo dispositivo de armazenamento 34 ilustrado na Figura 3. As funções da unidade de comunicação 38 e da unidade de controle 39 são implementadas quando a CPU 31 ilustrada na Figura 3 executa um programa armazenado na ROM 33 usando a RAM 32.

[043] A unidade de armazenamento 37 armazena informações (doravante referidas como "informações de tipo") sobre o tipo de memória não volátil montada em cada uma das ECUs 40a a 40d. A Figura 7 ilustra um exemplo das informações de tipo. Nas informações de tipo ilustradas na Figura 7, uma ECU_ID, que é um número usado para identificar a ECU, está associada ao tipo (o primeiro tipo ou o segundo tipo) da memória não volátil montada na ECU.

[044] As informações de tipo podem ser criadas antecipadamente com base em uma especificação da ECU que compõe a rede no veículo 20 e armazenadas na unidade de armazenamento 37 no momento da fabricação do veículo. Alternativamente, as informações de tipo podem ser adquiridas pela unidade de comunicação 38 descrita abaixo a partir da ECU alvo por comunicação dentro da rede no veículo 20 no momento da execução do processamento de atualização de software. Quando o tipo de memória não volátil é adquirido da ECU alvo cada vez que o processamento de atualização de software é executado, o mestre de OTA 30 pode administrar unitariamente os tipos de memórias não voláteis montadas nas ECUs montadas no veículo e responder apropriadamente mesmo quando o tipo de memória não volátil é alterado devido à substituição da ECU ou semelhante. Alternativamente, as informações de tipo pode ser adquiridas do centro 10 por comunicação através da rede 70. Neste caso, os tipos de memórias não voláteis das ECUs montadas no veículo são administrados antecipadamente pelo centro 10.

[045] Quando, por exemplo, a fonte de alimentação ou o IGN do veículo é ligado, a unidade de comunicação 38 transmite o pedido de confirmação de atualização de software para o centro 10. O pedido de confirmação de atualização inclui um ID de veículo usado para identificar o veículo e versões de software das ECUs 40a a 40d conectadas à rede no veículo 20. A ID do veículo e as versões de software das ECUs 40a a 40d são usadas para determinar se há dados de atualização do software da ECU, comparando-os com a versão de software mais recente mantida pelo centro 10 para cada ID de veículo. Além disso, como uma resposta ao pedido de confirmação de atualização, a unidade de comunicação 38 recebe, do centro 10, uma notificação indicando se há os dados de atualização. Quando há dados de atualização do software da ECU, a unidade de comunicação 38 transmite a solicitação de download do pacote de distribuição para o centro 10 e recebe o pacote de distribuição transmitido do centro 10. Além dos dados de atualização, o pacote de distribuição pode incluir dados de verificação para verificar a autenticidade dos dados de atualização, o número de partes de dados de atualização, ordem de instalação, informações de tipo, diversas partes de informações de controle que são usadas no momento da atualização de software ou semelhantes. Além disso, quando as informações de tipo são adquiridas da ECU alvo no momento da execução do processamento de atualização de software, a unidade de comunicação 38 adquire as informações de tipo comunicando-se com a ECU alvo.

[046] A unidade de controle 39 determina se há dados de atualização do software da ECU com base na resposta do centro 10 ao pedido de confirmação de atualização recebido pela unidade de comunicação 38. Além disso, a unidade de controle 39 verifica a autenticidade do pacote de distribuição recebido do centro 10 pela unidade de comunicação 38 e armazenado na unidade de armazenamento 37. Além disso, a unidade de controle 39 transfere uma ou mais partes dos dados de atualização baixados no pacote de distribuição para a ECU alvo e faz com que a ECU alvo instale o software de atualização com base nos dados de atualização. Após a conclusão da instalação, a unidade de controle 39 dá à ECU alvo uma instrução sobre como tornar o software de atualização instalado eficaz.

[047] Aqui, quando a memória não volátil da ECU é o primeiro tipo (a memória de banco único), o processamento do pedido de aprovação para solicitar a aprovação de um usuário ou administrador do veículo para a atualização do software é executado antes da execução da instalação porque a instalação e a ativação são executadas consecutivamente. Quando a memória não volátil da ECU é do segundo tipo (memória de banco duplo), o processamento do pedido de aprovação para a atualização do software é executado pelo menos após a execução da instalação e antes da execução da ativação. Quando a memória não volátil da ECU é do segundo tipo, o processamento da solicitação de aprovação para a atualização do software pode ser executado antes da execução da instalação ou omitido.

[048] No processamento de solicitação de aprovação, a unidade de controle 39 faz com que um dispositivo de saída emita uma notificação indicando que a aprovação para a atualização de software é necessária ou uma notificação solicitando uma entrada indicando que a atualização de software foi aprovada. Como o dispositivo de saída, um dispositivo de exibição que emite uma notificação por um monitor, um dispositivo de saída de voz que emite uma notificação por voz, ou semelhante, pode ser usado. Por exemplo, no processamento de solicitação de aprovação, quando o dispositivo de exibição é usado como o dispositivo de saída, a unidade de controle 39 pode fazer com que o dispositivo de exibição exiba uma tela de solicitação de aprovação usada para solicitar a aprovação para a atualização de software e fazer com que a unidade de exibição para exibir uma notificação solicitando uma operação de entrada específica, como pressionar um botão de aprovação no caso em que o usuário ou o administrador aprova a solicitação. Alternativamente, no processamento de solicitação de aprovação, a unidade de controle 39 pode fazer com que o dispositivo de exibição exiba texto, um ícone ou semelhante, notificando que há dados de atualização do software da ECU, ou fazer com que o dispositivo de exibição exiba restrições e semelhantes durante a execução do processamento de atualização de software.

[049] A unidade de controle 39 executa o processamento do pedido de aprovação em um tempo de acordo com o tipo de memória da ECU alvo com base na informação do tipo. Então, ao receber a entrada indicando que o pedido foi aprovado do usuário ou do administrador, a unidade de controle 39 executa o processamento de controle da instalação e ativação acima descritas e atualiza o software da ECU alvo.

[050] O processamento de atualização de software é composto por uma fase em que o mestre de OTA 30 baixa os dados de atualização do centro 10 (uma fase de download), uma fase em que o mestre de OTA 30 transfere os dados de atualização baixados para a ECU alvo e instala o software de atualização com base nos dados de atualização na área de armazenamento da ECU alvo (uma fase de instalação) e uma fase na qual a ECU alvo torna o software de atualização instalado eficaz (uma fase de ativação).

[051] O download é um processamento no qual o Mestre de OTA 30 recebe, do centro 10, os dados de atualização para atualização do software da ECU transmitidos no pacote de distribuição e os armazena na unidade de armazenamento 37. Quanto à recepção dos dados de atualização baixando, os dados de atualização para a ECU com a memória não volátil de segundo tipo (a memória de banco duplo) montada na mesma, que tem uma probabilidade relativamente baixa de falha de atualização, podem ser recebidos com prioridade, ou os dados de atualização para o ECU tendo a memória não volátil de primeiro tipo (a memória de banco único) montada na mesma e os dados de atualização para a ECU tendo a memória não volátil de segundo tipo (a memória de banco duplo) montada na mesma podem ser recebidos sem priorizar nenhum deles. A fase de download inclui não apenas a execução do download, mas também o controle de uma série de processos associados ao download, como determinar se o download pode ser executado e verificar os dados de atualização.

[052] Os dados de atualização transmitidos do centro 10 para o mestre de OTA 30 podem incluir qualquer um dos softwares de atualização da ECU, os dados compactados obtidos pela compactação do software de atualização e os dados divididos obtidos pela divisão do software de atualização ou dos dados compactados. Além disso, os dados de atualização podem incluir um número da ECU alvo (ECU_ID) e um número usado para identificar o software da ECU antes da atualização (ECU_Software_ID). Os dados de atualização são baixados como o pacote de distribuição descrito acima, mas o pacote de distribuição inclui os dados de atualização para uma única ECU ou uma pluralidade de ECUs.

[053] A instalação é um processamento em que o mestre de OTA 30 grava o software de atualização (o programa de versão atualizada) na ECU alvo, com base nos dados de atualização baixados do centro 10. A fase de instalação inclui não apenas a execução da instalação, mas também controles de uma série de processos associados à instalação, como determinar se a instalação pode ser executada, transferir os dados de atualização e verificar o software de atualização.

[054] Quando os dados de atualização incluem o próprio software de atualização, na fase de instalação, o mestre de OTA 30 transfere os dados de atualização (o software de atualização) para a ECU alvo. Além disso, quando os dados de atualização incluem os dados compactados do software de atualização, dados de diferença ou dados divididos, o mestre de OTA 30 pode transferir os dados de atualização para a ECU alvo e a ECU alvo pode gerar o software de atualização a partir dos dados de atualização, ou o mestre de OTA 30 pode gerar o software de atualização a partir dos dados de atualização e, em seguida, transferir o software de atualização para a ECU alvo. Aqui, o software de atualização pode ser gerado descompactando os dados compactados e reunindo (integrando) os dados de diferença ou os dados divididos.

[055] O software de atualização pode ser instalado pela ECU alvo com base em um pedido de instalação do mestre de OTA 30. Alternativamente, a ECU alvo que recebeu os dados de atualização pode executar a instalação de forma autônoma sem receber uma instrução explícita do mestre de OTA 30.

[056] A ativação é o processamento no qual a ECU alvo torna (ativa) o software de atualização instalado efetivo. A fase de ativação inclui não apenas a execução da ativação, mas também o controle de uma série de processos associados à ativação, como determinar se a ativação pode ser executada e verificar o resultado da execução.

[057] O software de atualização pode ser ativado pela ECU alvo com base em um pedido de ativação do mestre de OTA 30. Alternativamente, a ECU alvo que recebeu os dados de atualização pode ser ativada de forma autônoma após a conclusão da instalação sem receber uma instrução explícita do mestre de OTA 30.

[058] O processamento de atualização de software pode ser executado continuamente ou em paralelo a cada uma das ECUs.

[059] Além disso, o "processamento de atualização de software" na presente especificação inclui não apenas o processamento para executar continuamente todo o download, instalação e ativação, mas também processamento para executar apenas uma parte do download, instalação e ativação.

Processamento

[060] A seguir, exemplos específicos do processamento de atualização de software executado no sistema de rede de acordo com a presente modalidade serão descritos com referência adicional às Figuras 8, 9, 10, 11A, 11B e 12.

(1) Primeiro Exemplo Específico

[061] A Figura 8 é um fluxograma que descreve os procedimentos de processamento de download de acordo com um primeiro exemplo específico executado pelo centro 10 e o mestre de OTA 30. O primeiro exemplo específico é um exemplo onde o centro 10 administra o tipo de memória não volátil montada em cada uma das ECUs 40a a 40d, ou seja, a unidade de armazenamento 16 armazena a informação do tipo. A unidade de armazenamento 37 do mestre de OTA 30 também pode armazenar as mesmas informações de tipo. O processamento ilustrado na Figura 8 é iniciado quando o centro 10 recebe a solicitação de download para o pacote de distribuição do mestre de OTA 30.

[062] (Etapa S801) O centro 10 gera o pacote de distribuição incluindo os dados de atualização para a ECU alvo da qual o software deve ser atualizado. Neste momento, o centro 10 refere-se às informações de tipo armazenadas na unidade de armazenamento 16 e gera o pacote de distribuição no qual o tipo de memória não volátil montada na ECU alvo é anexado aos dados de atualização como um atributo. Quando o pacote de distribuição é gerado, o processo segue para a etapa S802.

[063] (Etapa S802) O mestre de OTA 30 recebe o pacote de distribuição transmitido do centro 10. Quando o pacote de distribuição é recebido, o processo segue para a etapa S803.

[064] (Etapa S803) O mestre de OTA 30 armazena, na unidade de armazenamento 37, os dados de atualização e o tipo de memória anexado aos dados de atualização como o atributo que está incluído no pacote de distribuição recebido do centro 10. Assim, o processamento do download termina.

[065] Como no primeiro exemplo específico, quando o centro 10 administra as informações de tipo, no momento de gerar o pacote de distribuição, a consistência entre os dados de atualização e a ECU alvo para o tipo de memória pode ser verificada. Por este motivo, é possível evitar uma situação em que não seja encontrada consistência no mestre de OTA 30 após o download. Portanto, é possível evitar uma ocorrência de retransmissão do pacote de distribuição e restringir um aumento na quantidade de comunicação (uma carga de comunicação) entre o centro 10 e o mestre de OTA 30.

(2) Segundo Exemplo Específico

[066] A Figura 9 é um fluxograma que descreve os procedimentos de processamento de download de acordo com um segundo exemplo específico executado pelo centro 10 e o mestre de OTA 30. O segundo exemplo específico é um exemplo onde o mestre de OTA 30 administra o tipo de memória não volátil montada em cada uma das ECUs 40a a 40d, ou seja, a unidade de armazenamento 16 do centro 10 não armazena as informações de tipo. O processamento ilustrado na Figura 9 é iniciado quando o centro 10 recebe a solicitação de download para o pacote de distribuição do mestre de OTA 30.

[067] (Etapa S901) O centro 10 gera o pacote de distribuição incluindo os dados de atualização para a ECU alvo da qual o software deve ser atualizado. Neste momento, o centro 10 não tem que entender se os dados de atualização para a ECU tendo a memória não volátil de primeiro tipo (a memória de banco único) montada na mesma e os dados de atualização para a ECU tendo a memória não volátil do segundo tipo (a memória de banco duplo) montada na mesma estão incluídos no pacote de distribuição. Quando o pacote de distribuição é gerado, o processo segue para a etapa S902.

[068] (Etapa S902) O mestre de OTA 30 recebe o pacote de distribuição transmitido do centro 10. Quando o pacote de distribuição é recebido, o processo segue para a etapa S903.

[069] (Etapa S903) O mestre de OTA 30 armazena, na unidade de armazenamento 37, os dados de atualização incluídos no pacote de distribuição recebido do centro 10. Assim, o processamento de download termina.

[070] No segundo exemplo específico, uma vez que o mestre de OTA 30 administra as informações de tipo, quando o tipo de memória não volátil é alterado devido à substituição da ECU ou semelhante, as informações de tipo administradas pelo mestre de OTA 30 pode ser rapidamente atualizada dentro do veículo (a rede no veículo 20).

(3) Terceiro Exemplo Específico

[071] A Figura 10 é um fluxograma que descreve os procedimentos de processamento de instalação de acordo com um terceiro exemplo específico executado pelo mestre de OTA 30 e a ECU alvo. O terceiro exemplo específico é um exemplo onde o mestre de OTA 30 controla a ordem de instalação dos dados de atualização de acordo com o tipo de memória não volátil montada na ECU alvo. Neste caso, o tipo de memória não volátil montada em cada uma das ECUs 40a a 40d pode ser administrado por qualquer um dentre o centro 10 e o mestre de OTA 30. O processamento ilustrado na Figura 10 é iniciado após o download da atualização dos dados for concluído e quando uma condição predeterminada (a instalação pode ser executada, o software de atualização é verificado e semelhantes) é satisfeita.

[072] (Etapa S1001) O mestre de OTA 30 adquire o tipo (o primeiro tipo/o segundo tipo) da memória não volátil montada na ECU alvo. O tipo de memória pode ser adquirido referindo-se à informação do tipo armazenada na unidade de armazenamento 37 quando o mestre de OTA 30 administra o tipo de memória e referindo-se à informação do tipo de memória que está incluída no pacote de distribuição e transmitida quando o centro 10 administra o tipo de memória. Quando o tipo de memória da ECU alvo é adquirido, o processo segue para a etapa S1002.

[073] (Etapa S1002) O mestre de OTA 30 e a ECU alvo tendo a memória não volátil de segundo tipo (a memória de banco duplo) montada na mesma executam a instalação, que é o processamento para gravar o software de atualização na área de armazenamento com base nos dados de atualização. A instalação é executada continuamente ou em paralelo em cada ECU alvo tendo a memória não volátil do segundo tipo montada na mesma (primeiro processamento). Quando a execução da instalação em cada ECU alvo tendo a memória não volátil de segundo tipo montada na mesma termina, o processo segue para a etapa S1003.

[074] (Etapa S1003) O mestre de OTA 30 e a ECU alvo tendo a memória não volátil de primeiro tipo (a memória de banco único) montada na mesma executam a instalação, que é o processamento para gravar o software de atualização na área de armazenamento com base nos dados de atualização. A instalação é executada continuamente ou em paralelo em cada ECU alvo tendo a memória não volátil do primeiro tipo montada na mesma (segundo processamento). Quando a execução da instalação em cada ECU alvo tendo a memória não volátil do primeiro tipo montada na mesma termina, a instalação em cada ECU alvo é concluída e o processamento da instalação termina.

[075] No terceiro exemplo específico, a instalação é executada priorizando a ECU alvo tendo a memória de banco duplo que não requer um controle de parada durante a atualização montada sobre a ECU alvo tendo a memória de banco único que requer o controle de parada durante a atualização montada na mesma. Por este processamento, o mestre de OTA 30 que pode compreender o status de gravação do software de atualização em tempo real pode gravar o software de atualização na área de armazenamento da ECU alvo tendo a memória de banco duplo montada na mesma primeiro, e no momento em que a gravação está quase concluída, começar a gravar o software de atualização na área de armazenamento da ECU alvo com a memória de banco único montada na mesma. Assim, é possível reduzir a carga de comunicação dentro do veículo (a rede no veículo 20) e encurtar o tempo durante o qual o controle do veículo deve ser interrompido até que a gravação de todo o software de atualização seja concluída.

(4) Quarto Exemplo Específico

[076] As Figuras 11A e 11B são fluxogramas que ilustram os procedimentos de processamento de instalação de acordo com um quarto exemplo específico executado pelo mestre de OTA 30 e a ECU alvo. O processamento da Figura 11A e o processamento da Figura 11B estão ligados por uma ligação X. O quarto exemplo específico é um exemplo em que o mestre de OTA 30 controla a ordem de instalação dos dados de atualização de acordo com o tipo de memória não volátil montada em a ECU alvo ao mesmo tempo em que tenta fazer com que o tipo de memória não volátil montada na ECU alvo seja consistente com o tipo de memória administrado nas informações de tipo. Neste caso, o tipo de memória não volátil montada em cada uma das ECUs 40a a 40d pode ser administrado por qualquer um dentre o centro 10 e o mestre de OTA 30. O processamento ilustrado nas Figuras 11A e 11B é iniciado após o download dos dados de atualização é concluída e quando uma condição predeterminada (a instalação puder ser executada, o software de atualização for verificado e semelhantes) é satisfeita.

[077] (Etapa S1101) O mestre de OTA 30 adquire o tipo (o primeiro tipo/o segundo tipo) da memória não volátil montada na ECU alvo. O tipo de memória pode ser adquirido referindo-se à informação do tipo armazenada na unidade de armazenamento 37 quando o mestre de OTA 30 administra o tipo de memória e referindo-se à informação do tipo de memória que está incluída no pacote de distribuição e transmitida quando o centro 10 administra o tipo de memória. Quando o tipo de memória da ECU alvo é adquirido, o processo segue para a etapa S1102.

[078] (Etapa S1102) O mestre de OTA 30 e a ECU alvo tendo a memória não volátil de segundo tipo (a memória de banco duplo) montada na mesma executam a instalação, que é o processamento para gravar o software de atualização na área de armazenamento com base nos dados de atualização. Neste momento, o mestre de OTA 30 notifica o tipo de memória adquirido na etapa S1101 para a ECU alvo que executou a instalação. Quando a instalação e a notificação do tipo de memória são executadas para a ECU alvo tendo a memória não volátil de segundo tipo montada na mesma, o processo segue para a etapa S1103.

[079] (Etapa S1103) A ECU alvo que executou a instalação determina se o tipo de memória não volátil montada na própria ECU alvo corresponde ao tipo de memória notificado a partir do mestre de OTA 30. Em outras palavras, a ECU alvo que executou a instalação determina se o tipo de memória notificado do mestre de OTA 30 é do segundo tipo. Quando ambos os tipos de memória correspondem entre si (etapa S1103: SIM), o primeiro processamento termina, e quando ambos os tipos de memória não correspondem entre si (etapa S1103: NÃO), o processo segue para a etapa S1104.

[080] (Etapa S1104) A ECU alvo com a memória não volátil de segundo tipo montada na mesma notifica o mestre de OTA 30 que o tipo de memória notificado a partir do mestre de OTA 30 não corresponde ao tipo de memória não volátil montada na própria ECU alvo. Quando o centro 10 administra o tipo de memória não volátil montada em cada uma das ECUs 40a a 40d, a notificação é enviada do mestre de OTA 30 para o centro 10. Quando a incompatibilidade entre os tipos de memória é notificada, o primeiro processamento termina.

[081] O primeiro processamento de acordo com as etapas acima descritas S1102 a S1104 é executado continuamente ou em paralelo a cada ECU alvo tendo a memória não volátil de segundo tipo (a memória de banco duplo) montada na mesma.

[082] (Etapa S1105) O mestre de OTA 30 e a ECU alvo tendo a memória não volátil de primeiro tipo (a memória de banco único) montada na mesma executam a instalação, que é o processamento para gravar o software de atualização na área de armazenamento com base em os dados de atualização. Neste momento, o mestre de OTA 30 notifica o tipo de memória adquirido na etapa S1101 para a ECU alvo que executou a instalação. Quando a instalação e a notificação do tipo de memória são executadas para a ECU alvo tendo a memória não volátil do primeiro tipo montada na mesma, o processo segue para a etapa S1106.

[083] (Etapa S1106) A ECU alvo que executou a instalação determina se o tipo de memória não volátil montada na própria ECU alvo corresponde ao tipo de memória notificado a partir do mestre de OTA 30. Em outras palavras, a ECU alvo que executou a instalação determina se o tipo de memória notificado do mestre de OTA 30 é do primeiro tipo. Quando ambos os tipos de memória correspondem entre si (etapa S1106: SIM), o segundo processamento termina, e quando ambos os tipos de memória não correspondem entre si (etapa S1106: NÃO), o processo segue para a etapa S1107.

[084] (Etapa S1107) A ECU alvo tendo a memória não volátil de primeiro tipo montada na mesma notifica o mestre de OTA 30 que o tipo de memória notificado a partir do mestre de OTA 30 não corresponde ao tipo de memória não volátil montada na própria ECU alvo. Quando o centro 10 administra o tipo de memória não volátil montada em cada uma das ECUs 40a a 40d, a notificação é enviada do mestre de OTA 30 para o centro 10. Quando a incompatibilidade entre os tipos de memória é notificada, o segundo processamento termina.

[085] O segundo processamento de acordo com as etapas acima descritas S1105 a S1107 é executado continuamente ou em paralelo a cada ECU alvo tendo a memória não volátil de primeiro tipo (a memória de banco único) montada na mesma

[086] Quando a execução da instalação em cada ECU alvo tendo a memória não volátil de segundo tipo (o primeiro processamento) é concluída e a execução da instalação em cada ECU alvo tendo a memória não volátil de primeiro tipo (o segundo processamento) for concluído, o processamento de instalação termina.

[087] No quarto exemplo específico, além da execução da instalação com prioridade da ECU alvo tendo a memória de banco duplo que não requer o controle de parada durante a atualização montado nela sobre a ECU alvo tendo a memória de banco único que requer o controle de parada durante a atualização montado nele (o terceiro exemplo específico), a consistência entre o tipo de memória não volátil montada na ECU alvo e o tipo de memória administrado nas informações de tipo é verificada. Por este processamento, quando o tipo de memória nas informações de tipo administradas pelo centro 10 ou o mestre de OTA 30 se desvia de um estado real da ECU alvo, o software de atualização adequado para o estado real pode ser instalado novamente. Além disso, conforme necessário, o tipo de memória nas informações de tipo administradas pelo centro 10 ou o mestre de OTA 30 pode ser reescrito e atualizado.

(5) Quinto Exemplo Específico

[088] A Figura 12 é um fluxograma que descreve os procedimentos de processamento de download e instalação de acordo com um quinto exemplo específico executado pelo centro 10, o mestre de OTA 30 e a ECU alvo. O quinto exemplo específico é um exemplo onde o pacote de distribuição incluindo os dados de atualização para a ECU alvo tendo a memória não volátil de primeiro tipo (a memória de banco único) montada na mesma e a atualização da ECU alvo tendo o segundo tipo não a memória volátil (a memória de banco duplo) montada na mesma é transmitida a partir do centro 10. O tipo de memória não volátil montada em cada uma das ECUs 40a a 40d é administrado pelo centro 10. O processamento ilustrado na Figura 12 é iniciado quando o centro 10 recebe a solicitação de download do pacote de distribuição do mestre de OTA 30.

[089] (Etapa S1201) O centro 10 gera o pacote de distribuição incluindo os dados de atualização para uma ECU tendo uma memória não volátil de primeiro tipo (a memória de banco único) montada na mesma e os dados de atualização para uma ECU tendo a memória não volátil de segundo tipo montada na mesma. Neste momento, o centro 10 refere-se à informação do tipo armazenada na unidade de armazenamento 16 e gera o pacote de distribuição no qual os dados de atualização para o primeiro tipo e os dados de atualização para o segundo tipo são misturados. O tipo de memória pode ser anexado aos dados de atualização como o atributo. Quando o pacote de distribuição é gerado, o processo segue para a etapa S1202.

[090] (Etapa S1202) O mestre de OTA 30 recebe o pacote de distribuição transmitido do centro 10. Quando o pacote de distribuição é recebido, o processo segue para a etapa S1203.

[091] (Etapa S1203) O mestre de OTA 30 armazena, na unidade de armazenamento 37, os dados de atualização incluídos no pacote de distribuição recebido do centro 10 e o tipo de memória nos dados de atualização. Quando os dados de atualização e o tipo de memória nos dados de atualização são armazenados, o processo segue para a etapa S1204.

[092] (Etapa S1204) O mestre de OTA 30 e a ECU alvo executam a instalação, que é o processamento para gravar o software de atualização na área de armazenamento com base nos dados de atualização. Neste momento, a instalação na ECU alvo tendo a memória não volátil de primeiro tipo montada na mesma e a instalação na ECU alvo tendo a memória não volátil de segundo tipo montada na mesma são executadas em paralelo. Quando a execução da instalação em cada ECU alvo é concluída, este processamento termina.

[093] Como no quinto exemplo específico, quando o centro 10 administra as informações de tipo, no momento de gerar o pacote de distribuição, a consistência entre os dados de atualização e a ECU alvo para o tipo de memória pode ser verificada. Por este motivo, é possível evitar uma situação em que não seja encontrada consistência no mestre de OTA 30 após o download. Portanto, é possível evitar uma ocorrência de retransmissão do pacote de distribuição e restringir um aumento na quantidade de comunicação (a carga de comunicação) entre o centro 10 e o mestre de OTA 30. Além disso, uma vez que a instalação na ECU alvo tendo a memória de banco único montada na mesma e a instalação na ECU alvo com a memória de banco duplo montada na mesma podem ser executadas em paralelo, é possível concluir, em um estágio antecipado, o processamento de atualização de software do sistema, incluindo as configurações de ambas as ECU alvo tendo a memória de banco único montada na mesma e a ECU alvo tendo a memória de banco duplo montada na mesma.

Ação e Efeito Vantajoso

[094] Conforme descrito acima, com o sistema de rede de acordo com a modalidade da presente invenção, o centro e o mestre de OTA podem transmitir e receber um do outro o pacote de distribuição, incluindo os dados de atualização para a ECU tendo a memória de banco único (a memória não volátil de primeiro tipo) montada na mesma e os dados de atualização para a ECU tendo a memória de banco duplo (a memória não volátil de segundo tipo) montada na mesma, isto é, o pacote de distribuição em que uma pluralidade de diferentes tipos de partes de dados de atualização são misturados.

[095] Assim, por exemplo, no caso em que o centro administra as informações de tipo sobre o tipo de memória não volátil montada em cada uma das ECUs montadas no veículo, no momento da geração do pacote de distribuição, a consistência entre os dados de atualização e a ECU alvo para o tipo de memória podem ser verificados. Por este motivo, é possível evitar uma situação em que não seja encontrada consistência no mestre de OTA após o download. Portanto, é possível evitar uma ocorrência de retransmissão do pacote de distribuição e limitar um aumento na quantidade de comunicação (a carga de comunicação) entre a central e o mestre de OTA. Além disso, no caso em que o mestre de OTA administra as informações de tipo, quando o tipo de memória não volátil é alterado devido à substituição da ECU ou semelhante, as informações de tipo administradas pelo mestre de OTA podem ser rapidamente atualizadas dentro do veículo (a rede no veículo).

[096] Além disso, uma vez que o mestre de OTA pode receber o pacote de distribuição, incluindo os dados de atualização para a ECU tendo a memória de banco único montada na mesma e os dados de atualização para a ECU tendo a memória de banco duplo montada na mesma, a instalação pode ser executada entre o mestre de OTA e a ECU alvo priorizando a ECU alvo tendo a memória de banco duplo que não requer o controle de parada durante a atualização montada sobre a ECU alvo tendo a memória de banco único que requer o controle de parada durante a atualização montada na mesma.

[097] Assim, o mestre de OTA pode gravar o software de atualização na área de armazenamento da ECU alvo tendo a memória de banco duplo montada na mesma primeiro, e no momento em que a gravação estiver quase concluída, começar a gravar o software de atualização no área de armazenamento da ECU alvo tendo a memória de banco único montada na mesma. Assim, é possível reduzir a carga de comunicação dentro do veículo (a rede no veículo) e encurtar o tempo durante o qual o controle do veículo deve ser interrompido até que a gravação de todo o software de atualização seja concluída.

[098] Alternativamente, o mestre de OTA também pode executar em paralelo a instalação na ECU alvo tendo a memória de banco único montada na mesma e a instalação na ECU alvo tendo a memória de banco duplo montada na mesma. Neste caso, pode-se esperar que o processamento de atualização de software de um sistema incluindo as configurações da ECU alvo tendo a memória de banco único montada na mesma e a ECU alvo tendo a memória de banco duplo montada na mesma seja concluído em um estágio antecipado.

[099] Como acima, uma modalidade da presente invenção foi descrita, mas a presente invenção pode ser considerada não apenas como o mestre de OTA, mas também como um método de atualização executado pelo mestre de OTA, incluindo o processador e a memória, o programa de atualização, um meio de armazenamento não transitório legível por computador que armazena o programa de atualização, o centro comunicante com o mestre de OTA, o sistema incluindo o centro e o mestre de OTA, o veículo incluindo o mestre de OTA ou semelhante.

[0100] É possível empregar a tecnologia da presente invenção em um sistema de rede usado para atualizar um programa de uma ECU.

Claims

Mestre de OTA (30), o mestre de OTA (30) sendo configurado para controlar atualização de software para uma unidade de controle eletrônico (40a, 40b, 40c, 40d) montada em um veículo, o mestre de OTA (30) CARACTERIZADO pelo fato de que compreende: uma unidade de comunicação (38) configurada para receber, de um centro (10), um pacote de distribuição incluindo dados de atualização para a unidade de controle eletrônico (40a) na qual uma memória não volátil de primeiro tipo (43a) tendo uma área de armazenamento está montada e dados de atualização para a unidade de controle eletrônico (40b) na qual uma memória não volátil de segundo tipo (43b) tendo duas áreas de armazenamento está montada.
Mestre de OTA (30), de acordo com a reivindicação 1, CARACTERIZADO pelo fato de que compreende adicionalmente uma unidade de controle (39) configurada para, com base em informações de tipo indicando se a memória não volátil montada na unidade de controle eletrônico (40a, 40b, 40c, 40d) é do primeiro tipo ou do segundo tipo, transferir os dados de atualização recebidos pela unidade de comunicação (38) para a unidade de controle eletrônico (40a, 40b, 40c, 40d) a ser atualizada.
Mestre de OTA (30), de acordo com a reivindicação 2, CARACTERIZADO pelo fato de que a unidade de comunicação (38) é configurada para adquirir as informações de tipo a partir do centro (10).
Mestre de OTA (30), de acordo com a reivindicação 2 ou 3, CARACTERIZADO pelo fato de que compreende ainda uma unidade de armazenamento (37) configurada para armazenar as informações de tipo.
Mestre de OTA (30), de acordo com qualquer uma das reivindicações 2 a 4, CARACTERIZADO pelo fato de que a unidade de controle (39) está configurada para transferir os dados de atualização para a unidade de controle eletrônico (40a, 40b, 40c, 40d) a ser atualizada com prioridade, com base nas informações de tipo, para os dados de atualização para a unidade de controle eletrônico (40b) na qual a memória não volátil de segundo tipo (43b) está montada sobre os dados de atualização para a unidade de controle eletrônico (40a) na qual a memória não volátil de primeiro tipo (43a) está montada.
Centro (10), o centro (10) sendo configurado para se comunicar com um mestre de OTA (30) que controla atualização de software para uma unidade de controle eletrônico (40a, 40b, 40c, 40d) montada em um veículo, o centro (10) CARACTERIZADO pelo fato de que compreende: uma unidade de comunicação (17) configurada para transmitir, para o mestre de OTA (30), um pacote de distribuição incluindo dados de atualização para a unidade de controle eletrônico (40a) na qual uma memória não volátil de primeiro tipo (43a) tendo uma área de armazenamento está montada e a unidade de controle eletrônico (40b) na qual uma memória não volátil de segundo tipo (43b) tendo duas áreas de armazenamento está montada.
Centro (10), de acordo com a reivindicação 6, CARACTERIZADO pelo fato de que compreende ainda uma unidade de armazenamento (16) configurada para armazenar informações de tipo indicando se a memória não volátil montada na unidade de controle eletrônico (40a, 40b, 40c, 40d) é de primeiro tipo ou de segundo tipo.
Centro (10), de acordo com a reivindicação 7, CARACTERIZADO pelo fato de que a unidade de comunicação (17) está configurada para transmitir as informações de tipo armazenadas na unidade de armazenamento (16) para o mestre de OTA (30).
Sistema CARACTERIZADO pelo fato de que compreende: um mestre de OTA (30) configurado para controlar atualização de software para uma unidade de controle eletrônico (40a, 40b, 40c, 40d) montada em um veículo; e um centro (10) configurado para se comunicar com o mestre de OTA (30), em que: o centro (10) inclui uma unidade de comunicação (17) configurada para transmitir, para o mestre de OTA (30), um pacote de distribuição incluindo dados de atualização para a unidade de controle eletrônico (40a) na qual uma memória não volátil de primeiro tipo (43a) tendo uma área de armazenamento está montada e dados de atualização para a unidade de controle eletrônico (40b) na qual uma memória não volátil de segundo tipo (43b) tendo duas áreas de armazenamento está montada; e o mestre de OTA (30) inclui uma unidade de comunicação (38) configurada para receber o pacote de distribuição transmitido pelo centro (10).
Sistema, de acordo com a reivindicação 9, CARACTERIZADO pelo fato de que o mestre de OTA (30) inclui uma unidade de controle (39) configurada para transferir os dados de atualização para a unidade de controle eletrônico (40a, 40b, 40c, 40d) a ser atualizada com prioridade, com base em informações de tipo indicando se a memória não volátil montada na unidade de controle eletrônico (40a, 40b, 40c, 40d) é do primeiro tipo ou do segundo tipo, para os dados de atualização para a unidade de controle eletrônico (40b) montada na memória não volátil de segundo tipo (43b) sobre os dados de atualização para a unidade de controle eletrônico (40a) montada na memória não volátil de primeiro tipo (43a), os dados de atualização para a unidade de controle eletrônico (40b) montada na memória não volátil de segundo tipo (43b) e os dados de atualização para a unidade de controle eletrônico (40a) montada na memória não volátil de primeiro tipo (43a) sendo incluídos no pacote de distribuição.
Sistema, de acordo com a reivindicação 10, CARACTERIZADO pelo fato de que pelo menos um dentre o centro (10) e o mestre de OTA (30) inclui uma unidade de armazenamento (16, 37) configurada para armazenar as informações de tipo.
Método de atualização executado por um mestre de OTA (30), o mestre de OTA (30) incluindo um processador e uma memória e sendo configurado para controlar atualização de software para uma unidade de controle eletrônico (40a, 40b, 40c, 40d) montada em um veículo, o método de atualização CARACTERIZADO pelo fato de que compreende: receber, pelo mestre de OTA (30), de um centro (10), um pacote de distribuição incluindo dados de atualização para a unidade de controle eletrônico (40a) na qual uma memória não volátil de primeiro tipo (43a) tendo uma área de armazenamento está montada e dados de atualização para a unidade de controle eletrônico (40b) na qual uma memória não volátil de segundo tipo (43b) tendo duas áreas de armazenamento está montada; e transferir, pelo mestre de OTA (30), os dados de atualização para a unidade de controle eletrônico (40a, 40b, 40c, 40d) a ser atualizada com prioridade, com base em informações de tipo indicando se a memória não volátil montada na unidade de controle eletrônico (40a, 40b, 40c, 40d) é do primeiro tipo ou do segundo tipo, para os dados de atualização para a unidade de controle eletrônico (40b) na qual a memória não volátil de segundo tipo (43b) está montada sobre os dados de atualização para o unidade de controle eletrônico (40a) na qual a memória não volátil de primeiro tipo (43a) está montada.
Meio de armazenamento não transitório CARACTERIZADO pelo fato de que armazena um comando executável por um processador de um mestre de OTA (30) que inclui o processador e uma memória e controla atualização de software para uma unidade de controle eletrônico (40a, 40b, 40c, 40d) montada em um veículo, o comando fazendo com que o processador execute as seguintes funções: receber, pelo mestre de OTA (30), de um centro (10), um pacote de distribuição incluindo dados de atualização para a unidade de controle eletrônico (40a) na qual uma memória não volátil de primeiro tipo (43a) tendo uma área de armazenamento está montada e dados de atualização para a unidade de controle eletrônico (40b) na qual uma memória não volátil de segundo tipo (43b) tendo duas áreas de armazenamento está montada; e transferir, pelo mestre de OTA (30), os dados de atualização para a unidade de controle eletrônico (40a, 40b, 40c, 40d) a ser atualizada com prioridade, com base em informações de tipo indicando se a memória não volátil montada na unidade de controle eletrônico (40a, 40b, 40c, 40d) é do primeiro tipo ou do segundo tipo, para os dados de atualização para a unidade de controle eletrônico (40b) na qual a memória não volátil de segundo tipo (43b) está montada sobre os dados de atualização para o unidade de controle eletrônico (40a) na qual a memória não volátil de primeiro tipo (43a) está montada.
Veículo CARACTERIZADO pelo fato de que compreende: um mestre de OTA (30) configurado para controlar atualização de software para uma unidade de controle eletrônico (40a, 40b, 40c, 40d) montada em um veículo, em que o mestre de OTA (30) inclui uma unidade de comunicação (38) configurada para receber, a partir de um centro (10), um pacote de distribuição incluindo dados de atualização para a unidade de controle eletrônico (40a) na qual uma memória não volátil de primeiro tipo ( 43a) tendo uma área de armazenamento está montada e dados de atualização para a unidade de controle eletrônico (40b) na qual uma memória não volátil de segundo tipo (43b) tendo duas áreas de armazenamento está montada.