clase ara::diag::SovdServiceValidation

La clase ara::diag::SovdServiceValidation sirve para la comprobación específica de la aplicación de derechos de acceso y condiciones previas en solicitudes de servicio SOVD entrantes ([SWS_DM_01822]). Tras la instanciación del puerto y la activación explícita mediante Offer(), Diagnostic Management llama al método de validación asíncrono Validate() para cada recurso solicitado ([SWS_DM_01827]). Si la validación devuelve un valor de error incluso para un solo subrecurso, el sistema cancela de inmediato todo el procesamiento y rechaza la solicitud del cliente. Mientras que la instanciación es segura para subprocesos, métodos como Offer() y StopOffer() deben ser sincronizados por quien realiza la llamada.

más ›

Contexto

La clase ara::diag::SovdServiceValidation sirve en la Adaptive Platform para proporcionar comprobaciones específicas del fabricante y del proveedor para Service-Oriented Vehicle Diagnostics (SOVD) dentro de una aplicación de diagnóstico ([SWS_DM_01822]). Mientras que Diagnostic Management (DM) evalúa las condiciones previas estandarizadas y las condiciones ambientales en el marco del protocolo SOVD antes de la ejecución del método ([SWS_DM_01468]), esta interfaz traslada las lógicas de validación personalizadas directamente a la aplicación adaptativa.

En la validación del servicio participan tres partes centrales:

• Cliente SOVD: inicia solicitudes de diagnóstico a través de métodos HTTP hacia el sistema del vehículo.
• Diagnostic Management (DM): recibe solicitudes SOVD, comprueba condiciones de nivel superior y delega la validación a los mapeos de puertos configurados ([SWS_DM_01467], SWS Diagnostics §7.3.3.2.3 «SOVD – Validation of Environmental Conditions»).
• Manejador de validación: implementa la especialización específica de la aplicación de SovdServiceValidation y decide sobre la admisibilidad de la operación solicitada ([SWS_DM_01822], [SWS_DM_01827]).

Diagrama de contexto: componentes y relaciones de interfaz en la validación de servicios SOVD. Fuentes: [SWS_DM_01822], [SWS_DM_01823], SWS Diagnostics §7.3.3.2.3 «SOVD – Validation of Environmental Conditions»

Ciclo de vida

La instanciación de un manejador de validación se realiza a través del constructor de SovdServiceValidation, que se vincula mediante un ara::core::InstanceSpecifier a un PortPrototype modelado en el manifiesto ([SWS_DM_01823]). En este caso, el puerto debe estar tipificado mediante un DiagnosticSovdServiceValidationInterface ([SWS_DM_01823]). A través del parámetro ConcurrencyType, la aplicación define de forma vinculante si su implementación está diseñada para llamadas concurrentes (kConcurrent) o si debe atenderse de forma no concurrente (kNotConcurrent) ([SWS_DM_01823]).

Tras una construcción exitosa, la instancia se encuentra en estado inicializado. El reenvío de solicitudes por parte del DM debe activarse explícitamente mediante la llamada a Offer() ([SWS_DM_01825]). Si el reenvío debe interrumpirse o finalizarse, la aplicación lo desactiva mediante StopOffer() ([SWS_DM_01826]). El destructor virtual ~SovdServiceValidation() finaliza limpiamente el ciclo de vida del manejador ([SWS_DM_01824]). Mientras que el propio constructor está especificado como seguro para subprocesos, Offer(), StopOffer() y el destructor no son seguros para subprocesos y no deben llamarse de forma concurrente ([SWS_DM_01823], [SWS_DM_01824], [SWS_DM_01825], [SWS_DM_01826]).

Ruta de uso

El flujo típico de la validación se divide en las siguientes fases:

1. Inicialización y registro: la aplicación instancia la clase especializada y habilita el servicio mediante Offer() para el DM ([SWS_DM_01823], [SWS_DM_01825]). Interpretación: esto se realiza típicamente al iniciar la funcionalidad de diagnóstico de la aplicación. Pregunta (abierta)
2. Procesamiento de solicitudes: si llega un mensaje SOVD al Diagnostic Server, este llama al método Validate para cada mapeo de puertos configurado en DiagnosticServiceValidationConfiguration en el orden establecido (SWS Diagnostics §7.3.3.2.3 «SOVD – Validation of Environmental Conditions»).
3. Comprobación de recursos: si la llamada afecta a una colección de recursos (Resource Collection), el DM llama a Validate varias veces: exactamente una vez para la colección misma y, a continuación, una vez para cada recurso contenido en la colección ([SWS_DM_01827]). La ruta del recurso que se está comprobando actualmente se pasa en cada caso en ara::diag::MetaInfo (SWS Diagnostics §7.3.3.2.3 «SOVD – Validation of Environmental Conditions»).
4. Resultado asíncrono: el método devuelve un ara::core::Future<void> ([SWS_DM_01827]). Si la comprobación es exitosa, el future se resuelve sin valor de error y el DM continúa el procesamiento de la solicitud (SWS Diagnostics §7.3.3.2.3 «SOVD – Validation of Environmental Conditions»).
5. Desactivación del servicio: antes de la terminación o en caso de cambios de configuración, la aplicación llama a StopOffer() ([SWS_DM_01826]).

Diagrama de secuencia: flujo de una comprobación de solicitud SOVD a través de Validate con iteración de recursos y tratamiento de errores. Fuentes: [SWS_DM_01827], SWS Diagnostics §7.3.3.2.3 «SOVD – Validation of Environmental Conditions»

Escenarios de error

Los errores pueden producirse en diferentes fases de la inicialización y la ejecución:

• Infracciones de construcción: si el InstanceSpecifier no se puede resolver en el modelo o no hace referencia a un PortPrototype, se notifica una InstanceSpecifierMappingIntegrityViolation ([SWS_DM_01823]). Se produce una PortInterfaceMappingViolation si el puerto no se corresponde con la interfaz DiagnosticSovdServiceValidationInterface ([SWS_DM_01823]). Si falta el mapeo de procesos, se produce ProcessMappingViolation, y si se utiliza el mismo identificador varias veces, se produce una InstanceSpecifierAlreadyInUseViolation ([SWS_DM_01823]).
• Errores de registro en Offer: si el servicio ya se ha ofrecido activamente, Offer() devuelve el error DiagOfferErrc::kAlreadyOffered ([SWS_DM_01825]). Si la configuración difiere del modelado DEXT, se produce el error DiagOfferErrc::kConfigurationMismatch ([SWS_DM_01825]).
• Errores de validación técnica: el método Validate notifica inadmisibilidades a través de códigos de error de DiagSovdErrc ([SWS_DM_01827]). Entre ellos se incluyen DiagSovdErrc::kInsufficientAccessRights en caso de permisos insuficientes del cliente, DiagSovdErrc::kPreconditionNotFulfilled si no se cumplen las condiciones previas, DiagSovdErrc::kTemporarilyNotAvailable en caso de no disponibilidad temporal (p. ej., validación de token en línea ausente) o DiagSovdErrc::kSovdServerMisconfigured en caso de configuración errónea ([SWS_DM_01827]).
• Interrupción inmediata en caso de errores en subrecursos: si la validación falla incluso para un solo recurso contenido de una colección de recursos, el DM cancela de inmediato el procesamiento de la solicitud completa y devuelve directamente un mensaje de error al cliente (SWS Diagnostics §7.3.3.2.3 «SOVD – Validation of Environmental Conditions»).