módulo ara::ucm — Update and Configuration Management

O cluster funcional Update and Configuration Management controla a instalação transacional, verificação e ativação de pacotes de software em uma máquina Adaptive (AUTOSAR_AP_EXP_SWArchitecture p. 138). A interface de serviço PackageManagement implementa para isso uma pipeline trifásica de transmissão de dados, processamento de pacotes e comutação subsequente via Activate ([SWS_UCM_00352]). Em caso de erros ocorridos ou dependências ausentes, mecanismos padronizados como Rollback e RevertProcessedSwPackages garantem a restauração segura do estado anterior do sistema ([SWS_UCM_00350], [SWS_UCM_00353]).

mais ›

O Update and Configuration Management (UCM) é um Functional Cluster baseado em daemon da AUTOSAR Adaptive Platform que disponibiliza a interface orientada a serviços PackageManagement via ara::com ([SWS_UCM_00361], AUTOSAR_AP_EXP_SWArchitecture p. 138). O UCM atua como órgão executor local para clientes OTA, aplicações de diagnóstico ou o Vehicle Update and Configuration Management (V-UCM) em todo o veículo e, em configurações multi-ECU, é endereçado por meio de um identificador de instância exclusivo em todo o veículo mediante GetId ([SWS_UCM_00343], TPS_ManifestSpecification p. 631).

O fluxo de atualização ocorre em três fases: transmissão de dados, processamento e ativação (AUTOSAR_AP_SWS_UpdateAndConfigurationManagement p. 136). Os pacotes de software podem ser transmitidos por streaming bloco a bloco a qualquer momento via TransferStart, TransferData e TransferExit ou registrados via RegisterSoftwarePackage como um caminho de URI existente ([SWS_UCM_00344], [SWS_UCM_00345], [SWS_UCM_00346]). Transferências que não sejam mais necessárias podem ser removidas com DeleteTransfer ([SWS_UCM_00348]).

Diagrama de sequência: transmissão de um pacote de software via streaming bloco a bloco ou registro direto de URI. Fontes: [SWS_UCM_00344], [SWS_UCM_00345], [SWS_UCM_00346], [SWS_UCM_00347], AUTOSAR_AP_SWS_UpdateAndConfigurationManagement p. 136, AUTOSAR_AP_SWS_UpdateAndConfigurationManagement p. 137.

O processamento é disparado com ProcessSwPackage, momento em que o UCM verifica manifestos e assinaturas de pacotes, descompacta os clusters de destino e indica o progresso no campo de status CurrentStatus, bem como via GetProgress ([SWS_UCM_00349], [SWS_UCM_00360], [SWS_UCM_00361]). Após a preparação bem-sucedida, Activate comuta para os novos clusters em coordenação com o State Management e o Execution Management, após o que Finish limpa os dados de origem temporários ([SWS_UCM_00352], [SWS_UCM_00354], AUTOSAR_AP_EXP_PlatformDesign p. 77).

Diagrama de sequência: ativação, transição de estado da plataforma e limpeza dos pacotes de software. Fontes: [SWS_UCM_00352], [SWS_UCM_00354], AUTOSAR_AP_EXP_PlatformDesign p. 77.

Processamentos com falha levam ao estado kProcessingFailed, enquanto campanhas incompletas antes da ativação são revertidas transacionalmente para o estado inicial com RevertProcessedSwPackages e, após comutação com falha, com Rollback ([SWS_UCM_00350], [SWS_UCM_00353], AUTOSAR_AP_SWS_UpdateAndConfigurationManagement p. 38). Para inspeção de status e auditoria, servem GetSwClusterInfo, GetSwClusterChangeInfo e GetHistory ([SWS_UCM_00355], [SWS_UCM_00356], [SWS_UCM_00357]).

mais ›

Papel e limites funcionais do sistema no ecossistema da plataforma

O cluster funcional Update and Configuration Management (UCM) constitui o componente central da AUTOSAR Adaptive Platform para a atualização, instalação e desinstalação seguras e transacionais de software de aplicação e de plataforma no nível da máquina (AUTOSAR_AP_EXP_SWArchitecture p. 138). Tecnicamente, o UCM é implementado como um serviço de segundo plano (daemon-based) em todo o sistema e disponibiliza sua funcionalidade principal por meio da interface de serviço primária ara::com PackageManagement ([SWS_UCM_00361], AUTOSAR_AP_SWS_UpdateAndConfigurationManagement p. 90). Entre as entidades consumidoras incluem-se clientes over-the-air internos do veículo (clientes OTA), testadores de diagnóstico via Diagnostic Management, bem como coordenadores de nível superior, como o Vehicle Update and Configuration Management (V-UCM) (AUTOSAR_AP_SWS_UpdateAndConfigurationManagement p. 17).

Dentro de uma arquitetura veicular multicamadas, o UCM atua como órgão executor local (UCM Subordinate), enquanto o V-UCM central do veículo orquestra campanhas baseadas em software abrangendo múltiplas ECUs (SWS_VehicleUpdateAndConfigurationManagement p. 16, AUTOSAR_AP_SWS_VehicleUpdateAndConfigurationManagement p. 12). Para permitir que o orquestrador central enderece múltiplas instâncias distribuídas do UCM em diferentes máquinas, cada instância disponibiliza seu identificador exclusivo por meio do método GetId ([SWS_UCM_00343]). Esse identificador deve ser configurado de forma exclusiva e específica da máquina em todo o veículo, de acordo com as especificações do manifesto (TPS_ManifestSpecification p. 631).

Diagrama de contexto: integração funcional do daemon do UCM na Adaptive Platform e interação com clientes e clusters de plataforma. Fontes: AUTOSAR_AP_EXP_SWArchitecture p. 138, AUTOSAR_AP_SWS_UpdateAndConfigurationManagement p. 17, SWS_VehicleUpdateAndConfigurationManagement p. 16.

Disponibilização e transmissão de pacotes de software

O ciclo de vida de uma atualização de software divide-se convencionalmente nas três macrofases de transmissão de dados (Data Transmission), processamento de pacotes (Processing) e ativação (Activation) (AUTOSAR_AP_SWS_UpdateAndConfigurationManagement p. 136). Uma característica arquitetural essencial do UCM é o desacoplamento da transmissão de dados em relação aos estados internos de processamento e gerenciamento de pacotes: pacotes de software podem ser transferidos para a máquina a qualquer momento durante a operação contínua (SWS_UpdateAndConfigurationManagement p. 38).

Para a disponibilização de pacotes de software, a interface PackageManagement define dois mecanismos complementares:

• Streaming bloco a bloco: o cliente inicia a transferência chamando TransferStart com a especificação do tamanho total em bytes e recebe um TransferIdType exclusivo, bem como o tamanho máximo permitido de bloco ([SWS_UCM_00345]). Em seguida, os fragmentos de dados são transferidos sequencialmente com TransferData e contador progressivo de blocos ([SWS_UCM_00346], AUTOSAR_AP_SWS_UpdateAndConfigurationManagement p. 136). A conclusão formal é constituída pela chamada de método TransferExit ([SWS_UCM_00347]).
• Registro baseado em URI: caso o pacote já tenha sido disponibilizado fora do UCM (p. ex., por meio de um gerenciador de download em segundo plano ou armazenamento prévio no sistema de arquivos local), o cliente pode registrar o pacote via RegisterSoftwarePackage informando um caminho padronizado de URI ([SWS_UCM_00344], AUTOSAR_AP_SWS_UpdateAndConfigurationManagement p. 137).

Em ambos os casos, o UCM atribui ao pacote um TransferId exclusivo, por meio do qual todas as ações subsequentes são referenciadas. Pacotes transferidos, mas ainda não processados, podem ser explicitamente removidos do armazenamento temporário com DeleteTransfer em caso de cancelamento ou limpeza de armazenamento ([SWS_UCM_00348]).

Diagrama de sequência: transmissão de um pacote de software via streaming bloco a bloco ou registro direto de URI. Fontes: [SWS_UCM_00344], [SWS_UCM_00345], [SWS_UCM_00346], [SWS_UCM_00347], AUTOSAR_AP_SWS_UpdateAndConfigurationManagement p. 136, AUTOSAR_AP_SWS_UpdateAndConfigurationManagement p. 137.

Processamento e verificação no UCM local

Após a transferência ou o registro bem-sucedido, o cliente inicia o processamento do pacote por meio do método ProcessSwPackage ([SWS_UCM_00349]). O processamento compreende a extração dos clusters de software, a leitura dos manifestos, verificações de integridade e autenticidade, bem como a validação estática de dependências de clusters (EXP_SWArchitecture p. 185). Um único pacote de software pode encapsular executáveis de Adaptive Applications, atualizações de sistema operacional ou de firmware, bem como dados de configuração e calibração (SWS_UpdateAndConfigurationManagement p. 27).

A chamada de ProcessSwPackage coloca o field de serviço CurrentStatus no estado kProcessing ([SWS_UCM_00361], AUTOSAR_AP_SWS_UpdateAndConfigurationManagement p. 123). Os clientes podem assinar o field ou monitorar o progresso atual por meio do método de consulta GetProgress ([SWS_UCM_00360]). Além disso, GetSwPackages permite a consulta de todos os pacotes de software conhecidos atualmente no UCM e de seus status de processamento ([SWS_UCM_00359]). Etapas de processamento demoradas em andamento podem ser interrompidas conforme a necessidade com Suspend e continuadas em um momento posterior por meio de Resume ([SWS_UCM_00397], [SWS_UCM_00398]). Se o processamento for cancelado, o procedimento pode ser interrompido de forma controlada com Cancel ([SWS_UCM_00351]).

Diagrama de sequência: processamento de pacotes com transição de status e monitoramento de progresso. Fontes: [SWS_UCM_00349], [SWS_UCM_00360], [SWS_UCM_00361], AUTOSAR_AP_SWS_UpdateAndConfigurationManagement p. 123.

Workflow de ativação e mudança de estado da plataforma

Se todos os pacotes previstos para uma campanha tiverem sido processados com sucesso, o cliente inicia a entrada em operação dos novos clusters de software com a chamada síncrona de Activate ([SWS_UCM_00352]). O pré-requisito para isso é que o UCM se encontre em um estado de repouso consistente e que não haja tarefas ativas de processamento ou cancelamento em execução (EXP_SWArchitecture p. 185). O UCM coordena a etapa de ativação estreitamente com o State Management (SM) e o Execution Management (EM): os processos em execução da versão antiga são encerrados de forma ordenada, as estruturas de dados de persistência são migradas e as novas instâncias de aplicação são iniciadas (AUTOSAR_AP_EXP_PlatformDesign p. 77).

O metamodelo de manifesto da Adaptive Platform suporta etapas de ativação em múltiplos estágios (SoftwarePackageStep), permitindo desacoplar de forma flexível a ordem de processamento dos pacotes da preparação e do momento real de comutação (activationSwitch=True) (AUTOSAR_TPS_ManifestSpecification p. 642). Após a comutação e verificação bem-sucedidas das novas versões de software, o cliente conclui a campanha com Finish ([SWS_UCM_00354]). Essa chamada executa uma limpeza definitiva, apaga os pacotes de origem do armazenamento temporário e transfere os clusters de software para o estado permanente (EXP_SWArchitecture p. 138).

Diagrama de sequência: ativação, transição de estado da plataforma e limpeza dos pacotes de software. Fontes: [SWS_UCM_00352], [SWS_UCM_00354], AUTOSAR_AP_EXP_PlatformDesign p. 77.

Ciclo de vida de clusters, APIs de consulta e histórico de auditoria

Os Software Clusters (SwCluster) possuem um ciclo de vida bem definido: após o processamento bem-sucedido via ProcessSwPackage, um cluster recém-adicionado passa para o estado kAdded, enquanto um cluster atualizado assume o estado kUpdating (SWS_UpdateAndConfigurationManagement p. 24). Somente com a chamada final de Finish após a ativação é que esses clusters passam para o estado produtivo estável kPresent (SWS_UpdateAndConfigurationManagement p. 24). Para os pacotes de software propriamente ditos, existem máquinas de estados desacopladas: a TransferState (estados kTransferring, kTransferred) e a ProcessingState (estados kReady, kProcessing, kProcessed, kProcessingFailed) permitem também cenários de streaming puros sem armazenamento intermediário prévio de todo o pacote (AUTOSAR_AP_SWS_UpdateAndConfigurationManagement p. 38).

Em tempo de execução, o UCM disponibiliza interfaces de informação abrangentes para inspeção do sistema:

• GetSwClusterInfo fornece uma lista de todos os Software Clusters atualmente ativos no estado kPresent juntamente com os identificadores de versão ([SWS_UCM_00357]).
• GetSwClusterChangeInfo relata todas as alterações pendentes (clusters a serem adicionados, atualizados ou removidos) antes da ativação final ([SWS_UCM_00356]).
• GetSwClusterManifestInfo permite a consulta direcionada de detalhes de manifesto de um determinado Software Cluster instalado ([SWS_UCM_00358]).
• GetHistory possibilita a leitura de uma trilha de auditoria cronológica de todas as ações do UCM dentro de um intervalo de tempo definido para rastreabilidade contínua na gestão de frotas ([SWS_UCM_00355], AUTOSAR_AP_SWS_UpdateAndConfigurationManagement p. 86).

Diagrama de estados: Máquinas de estados desacopladas para transferência de dados e processamento de um pacote de software. Fontes: AUTOSAR_AP_SWS_UpdateAndConfigurationManagement p. 38, AUTOSAR_SWS_UpdateAndConfigManagement p. 20.

Diagrama de estados: Ciclo de vida de um Software Cluster desde a preparação até a ativação final. Fontes: SWS_UpdateAndConfigurationManagement p. 24, AUTOSAR_AP_SWS_UpdateAndConfigurationManagement p. 87.

Comportamento em caso de erro e proteção transacional

Para garantir a segurança funcional e a estabilidade do sistema da ECU sob todas as condições operacionais, o UCM impõe verificações estritas de consistência e oferece mecanismos de fallback para cada fase do processo de atualização. Se a validação ou a instalação falhar durante o processamento do pacote, o pacote afetado passa para o estado kProcessingFailed (AUTOSAR_AP_SWS_UpdateAndConfigurationManagement p. 38). Caso pacotes já processados devam ser descartados antes da ativação, RevertProcessedSwPackages reverte coletivamente todas as alterações temporárias de arquivos e de configuração ([SWS_UCM_00350]).

Se for detectado um erro durante a etapa de ativação – por exemplo, devido a dependências não solucionáveis (kDependencyMissing), falhas de alocação de memória (kPersistencyAllocationFailed) ou erros na sessão de atualização com o State Management ([SWS_UCM_00352]) –, o UCM cancela a ativação. Em tal caso de erro, o método Rollback restaura toda a plataforma exatamente para o estado anterior ao início do processamento do pacote ([SWS_UCM_00353]). Interpretação: supõe-se que, para isso, o UCM recorra a estruturas de armazenamento redundantes, como partições A/B ou snapshots do sistema de arquivos, a fim de recolocar em operação as versões antigas inalteradas sem perda de dados (AUTOSAR_AP_EXP_SWArchitecture p. 138). Pergunta Q-8d85be7343a9aace (aberta)

No nível de interface, chamadas inadmissíveis (por exemplo, tentativas de ativação na ausência de pacotes ou chamadas paralelas durante operações ativas) são rejeitadas de forma determinística por meio do código de erro kOperationNotPermitted ([SWS_UCM_00347], [SWS_UCM_00352]). Interpretação: supõe-se que o UCM bloqueie rigorosamente quaisquer chamadas de modificação concorrentes durante processos de ativação ou rollback em andamento, a fim de evitar race conditions na comutação de partição (EXP_SWArchitecture p. 185). Pergunta Q-60859031e6230a65 (aberta) O UCM confirma identificadores de sessão inválidos ou desconhecidos com o erro de aplicação kTransferIdInvalid ([SWS_UCM_00348], [SWS_UCM_00351]).

Evidências mais detalhadas

A arquitetura do UCM e sua integração orientada a serviços estão formalmente estabelecidas nas seguintes especificações principais:

• PackageManagement Interface de serviço e protocolo de transferência: [SWS_UCM_00345], [SWS_UCM_00346], [SWS_UCM_00347], AUTOSAR_AP_SWS_UpdateAndConfigurationManagement p. 85.
• Processamento, transições de estado e tratamento de erros: [SWS_UCM_00349], [SWS_UCM_00350], [SWS_UCM_00352], [SWS_UCM_00353], AUTOSAR_AP_SWS_UpdateAndConfigurationManagement p. 38.
• Inspeção de status, modelo de dados do Software Cluster e histórico: [SWS_UCM_00355], [SWS_UCM_00356], [SWS_UCM_00357], AUTOSAR_AP_SWS_UpdateAndConfigurationManagement p. 86, AUTOSAR_AP_SWS_UpdateAndConfigurationManagement p. 87.
• Coordenação multi-ECU e interação com o Vehicle UCM: [SWS_UCM_00343], SWS_VehicleUpdateAndConfigurationManagement p. 16, TPS_ManifestSpecification p. 631.