Diagnóstico

A plataforma SDV oferece um conjunto de APIs para serem usadas entre o Diagnostics Manager fornecido pelo OEM e os pacotes de serviços SDV, além de utilitários e recursos gerais da plataforma para oferecer suporte aos casos de uso de diagnóstico do OEM. Os diagnósticos são essenciais para os esforços de SDV, serviços automotivos e tecnologias que oferecemos aos OEMs porque a pilha de diagnóstico é um componente essencial de qualquer sistema operacional automotivo.

Os OEMs implantam instâncias do Diagnostics Manager (geralmente uma por ECU ou uma por VM) para processar solicitações de clientes de diagnóstico comunicando-se com os pacotes de serviços SDV no sistema. Para isso, o SDV oferece um conjunto de APIs de diagnóstico padrão, utilitários e suporte geral da plataforma para casos de uso de diagnóstico de OEM. Nosso objetivo é:

  • Permitir que os OEMs implementem o Diagnostics Manager de acordo com o padrão UDS.
  • Permite que o Diagnostics Manager delegue solicitações de teste a pacotes de serviços do SDV.
  • Permite que pacotes de serviços SDV exponham dados de diagnóstico de maneira independente do veículo.

Para isso, o SDV fornece um conjunto de APIs para padronizar as interações entre pacotes de serviços do SDV (potencialmente fornecidos por terceiros) e a implementação da pilha de diagnóstico do OEM.

Pilha de diagnóstico

Figura 1. Stack de diagnóstico.

Os pacotes de serviços SDV podem expor dados e entidades de diagnóstico, implementar funcionalidades de diagnóstico e informar sobre falhas ao Gerenciador de diagnóstico.

Ao fornecer uma API de diagnóstico padrão em toda a SDV, simplificamos a implementação de pacotes de serviços da SDV, evitando a necessidade de reimplementar diagnósticos para execução em diferentes veículos de diferentes OEMs.

API Diagnostics Services

A API SDV Diagnostics define os seguintes serviços, que correspondem a serviços específicos de UDS (ISO 14229-1):

  • service AuthenticationService: 0x29 (autenticação). Ele oferece um mecanismo para o cliente provar sua identidade e acessar dados ou serviços restritos.
  • service DataItemService: 0x22 (ReadDataByIdentifier) e 0x2E (WriteDataByIdentifier). Ela permite ler e gravar elementos de dados identificados por DIDs.
  • service EcuResetService: 0x11 (ECUReset). Ele permite que o testador solicite uma redefinição da ECU.
  • service FileTransferService: 0x34 (RequestDownload), 0x35 (RequestUpload), 0x36 (TransferData), 0x37 (RequestTransferExit) e 0x38 (RequestFileTransfer). Ele lida com o início e o processamento de downloads e uploads de arquivos.
  • service IoControlService: 0x2F (InputOutputControlByIdentifier). Ele permite que testadores externos controlem entradas e saídas do sistema para fins de teste.
  • service RoutineControlService: 0x31 (RoutineControl). Ele permite que o testador inicie, pare e solicite resultados de rotinas (funções) específicas implementadas pelos serviços do SDV.
  • service SecurityAccessService: 0x27 (SecurityAccess). Ele gerencia a troca de sementes e chaves necessária para desbloquear níveis específicos de segurança.

A API SDV Diagnostics também define service FaultListenerService e message Event com base no Diagnostic Event Manager (Gerenciador de eventos de diagnóstico) da AUTOSAR (AUTOSAR_SWS_DiagnosticEventManager), que permite que os aplicativos informem eventos de diagnóstico e falhas.

Além disso, service DiagnosticsManagerService define um serviço de plataforma SDV que permite que outros serviços consultem os parâmetros atuais de conexão de diagnóstico (endereço de origem, endereço de destino) e o tipo de sessão.

Guia para desenvolvedores sobre pacotes de serviços

Como desenvolvedor de pacotes de serviços, diagnostics_declaration e os seguintes servidores podem ser definidos no arquivo .vsidl correspondente:

service_bundle {
    name: "<BUNDLE-NAME>"
    ...
    server {
        service: "com.sdv.google.diagnostics.data_item.DataItemService"
    }
    server {
        service: "com.sdv.google.diagnostics.routine_control.RoutineControlService"
    }
    server {
        service: "com.sdv.google.diagnostics.io_control.IoControlService"
    }
    server {
        service: "com.sdv.google.diagnostics.fault.FaultListenerService"
    }
    ...
    diagnostics_declaration {
        data_item {
            ...
        }

        routine {
            ...
        }

        event {
            ...
        }

        io_control {
            ...
        }
    }
    ...
}

A mensagem DiagnosticsDeclaration é definida como:

package sdv.diagnostics.v1;

message DiagnosticsDeclaration {
  // Diagnostics data item declaration.
  //
  // See com.sdv.google.diagnostics.data_item.DataItemService service.
  message DataItem {
    // Required. Id of the data item.
    string id = 1;

    // Required. Fully qualified name of the message that defines a structure of
    // the data item.
    string message_name = 2;

    // Flag that indicates whether the data item is writable by the Diagnostics
    // Manager.
    //
    // Effectively, this indicates whether the call to DataItemService::Write,
    // is supported for this data item id.
    bool is_writable = 3;
  }

  // Declaration of diagnostics data for input/output control.
  //
  // See com.sdv.google.diagnostics.io_control.IoControl service.
  message InputOutputControlData {
    // Id of the input/output control data.
    string id = 1;

    // Fully qualified name of the message that defines a structure of the data.
    string message_name = 2;
  }

  // Declaration of diagnostics routine.
  //
  // See com.sdv.google.diagnostics.routine_control.RoutineControl.
  message Routine {
    // Information about routine control method.
    message Method {
      // Fully qualified name of the request message.
      string request = 1;

      // Fully qualified name of the response message.
      string response = 2;
    }

    // Id of the routine.
    string id = 1;

    // Information about routine start method.
    //
    // See com.sdv.google.diagnostics.routine_control.RoutineControl::Start.
    Method start = 2;

    // Information about routine stop method.
    //
    // See com.sdv.google.diagnostics.routine_control.RoutineControl::Stop.
    Method stop = 3;

    // Information about routine result method.
    //
    // See
    // com.sdv.google.diagnostics.routine_control.RoutineControl::RequestResult.
    Method result = 4;
  }

  // Declaration of diagnostics event and corresponding fault listener.
  //
  // See com.sdv.google.diagnostics.event.Event.
  // See com.sdv.google.diagnostics.fault.FaultListener.
  message Event {
    // Id of the event.
    string id = 1;

    // Fully qualified message name of the event's extended data message.
    string extended_data_message_name = 2;

    // Fault status changes which service wants to be notified of.
    //
    // See com.sdv.google.diagnostics.fault.FaultListener.StatusMask.
    uint32 fault_listener_mask = 3;

    // User-defined service unit name of a corresponding event publisher.
    string service_unit_name = 4;
  }

  // Diagnostic data items exposed by the service bundle.
  repeated DataItem data_item = 1;

  // Diagnostic data exposed for input/output control by the service bundle.
  repeated InputOutputControlData io_control = 2;

  // Diagnostic routines exposed by the service bundle.
  repeated Routine routine = 3;

  // Diagnostic events sent by the service bundle.
  repeated Event event = 4;
}

Se o bloco acima (service_bundle que contém diagnostics_declaration) estiver definido nos catálogos, vsidl_rc_generator vai gerar os destinos prebuilt_etc para cada pacote de serviços que declarar os servidores acima e diagnostics_declaration:

prebuilt_etc {
    name: "<APEX-NAME>.<BUNDLE-NAME>-diag-config.binpb",
    filename: "DiagService-diag-config.binpb",
    sub_dir: "vsidl_provider",
    src: ":generate_vsidl_files_single_bundle_<APEX-NAME>.<BUNDLE-NAME>{diagnostics-config.binpb}",
    installable: false,
}

Essas metas PRECISAM ser adicionadas ao prebuilts do bloco de definição do apex correspondente, conforme indicado pelo bloco de comentários autogerado acima do bloco prebuilt_etc {}:

apex {
    name: "<APEX-NAME>",
    ...
    prebuilts: [
        ...
        "<APEX-NAME>.<BUNDLE-NAME>-diag-config.binpb",
        ...
    ],
    ...
}

Também é necessário adicionar esses destinos no campo diagnostics_config_path da entrada sdv_service_bundle_metadata do pacote no arquivo sdv_service_bundles_manifest.textproto correspondente. Além disso, especifique políticas de autorização para ativar a comunicação RPC entre o pacote de serviços e o serviço do gerenciador de diagnóstico:

sdv_service_bundle_metadata {
  name: "<BUNDLE-NAME>"
  ...
  diagnostics_config_path: "etc/vsidl_provider/<BUNDLE-NAME>-diag-config.binpb"
  authorization_policy_path: "etc/authz/permissions.textproto"
  ...
}

As permissões no arquivo permissions.textproto precisam definir as funções do cliente ou do servidor. Por exemplo, se o pacote de serviços implementar um item de dados de diagnóstico:

server {
    service: "com.sdv.google.diagnostics.data_item.DataItemService"
    allow_all_channels: true
}

Guia para desenvolvedores da plataforma

Como desenvolvedores de plataforma, os OEMs PRECISAM implementar um destino rust_binary do agente do Diagnostics Manager:

rust_binary {
    name: "<DIAGNOSTICS-AGENT-BINARY-EXECUTABLE-NAME>",
    ...
    product_specific: true,
    ...
}

Além disso, nos arquivos de build, a seguinte variável precisa ser definida/substituída: SDV_DIAGNOSTICS_AGENT_MODULE := <DIAGNOSTICS-AGENT-BINARY-EXECUTABLE-NAME>

Para facilitar, a biblioteca libsdv_uds_serde_v1 pode ser usada para tradução de Proto ↔ UDS, e a VSIDL Provider Library para reflexão.

O arquivo do agente de diagnóstico .vsidl precisa ter o seguinte conteúdo:

package: "com.sdv.oem.diagnostics"

service_bundle {
    name: "DiagnosticsAgent"

    server {
        service: "com.sdv.google.diagnostics.DiagnosticsManagerService"
    }

    client {
        service: "com.sdv.google.diagnostics.data_item.DataItemService"
    }

    client {
        service: "com.sdv.google.diagnostics.routine_control.RoutineControlService"
    }

    client {
        service: "com.sdv.google.diagnostics.io_control.IoControlService"
    }

    client {
        service: "com.sdv.google.diagnostics.fault.FaultListenerService"
    }

    client {
        service: "com.sdv.google.diagnostics.ecu_reset.EcuResetService"
    }

    client {
        service: "com.sdv.google.diagnostics.security_access.SecurityAccessService"
    }

    client {
        service: "com.sdv.google.diagnostics.authentication.AuthenticationService"
    }

    client {
        service: "com.sdv.google.diagnostics.file_transfer.FileTransferService"
    }
}

Como o agente do Diagnostics Manager é um executável binário, o sdv_service_bundle_metadata do pacote é definido como uma declaração somente de configuração:

sdv_service_bundle_metadata {
    # This name must match the agent's Bundle Name
    name: "DiagnosticsAgent"
    version_number: 1
    version_name: "1"

    # Reference the manifest itself to mark this as a config-only declaration.
    native_library_path: "etc/sdv_service_bundles_manifest.textproto"

    authorization_policy_path: "etc/authz/permissions.textproto"
}

A política de autorização do agente de diagnóstico precisa definir as permissões dos serviços com que ele interage. Por exemplo, se ele chamar o serviço de transferência de arquivos:

client {
    service: "com.sdv.google.diagnostics.file_transfer.FileTransferService"
    allow_all_channels: true
}