estructura <DataElement-Namespace>::<DataElementInterface>::<DataElement>ReadOutput

La estructura <DataElement>ReadOutput sirve en el módulo de diagnóstico adaptativo como contenedor de transporte para encapsular todos los argumentos de salida de una operación de lectura de un elemento de datos. Ante una solicitud de lectura entrante, el proveedor del servicio la instancia, la rellena con los valores determinados y la devuelve al llamador. Las instancias poseen semántica de valor pura sin gestión de estado propia y presumiblemente se destruyen inmediatamente tras su evaluación. Pregunta (abierta) Cualquier posible error durante la consulta se gestiona, como interpretación, a través de los mecanismos de retorno de la función de plataforma de nivel superior y no a través de la propia estructura.

más ›

Contexto

La estructura <DataElement>ReadOutput forma parte de la definición de interfaz del módulo de diagnóstico (diag) dentro de AUTOSAR Adaptive Platform en el release R25-11. Su función principal consiste en agrupar, a modo de estructura envoltorio (wrapper), los argumentos de salida (out arguments) de una operación de lectura (ReadOutput) para un elemento de datos de diagnóstico determinado dentro del <DataElementInterface> correspondiente. En la arquitectura de AUTOSAR Adaptive, los componentes de software funcionales se comunican con el gestor de diagnóstico de la plataforma a través de interfaces de servicio claramente definidas. <DataElement>ReadOutput actúa aquí como mero contenedor de transferencia de datos que agrupa los datos útiles de una consulta de lectura. Presumiblemente, la estructura de datos sirve como tipo de retorno de una operación de lectura asíncrona (como Read()) dentro de la interfaz de diagnóstico <DataElementInterface> para proporcionar parámetros de salida de forma agrupada. Pregunta Q-e3c1110153021b2a (abierta) Gracias a esta encapsulación se crea una interfaz tipificada y homogénea que prescinde de pasos de punteros o parámetros de salida separados.

Ciclo de vida

En cuanto al ciclo de vida, la estructura <DataElement>ReadOutput presenta las propiedades de un tipo de valor elemental. No posee una identidad duradera ni atraviesa estados internos complejos. La creación se realiza dinámicamente o en la pila mediante aquel componente que implementa el acceso de lectura al elemento de datos y recopila los datos de salida. Es de esperar que las instancias de la estructura se pasen típicamente por valor o mediante semántica de movimiento (move), y que el componente de diagnóstico llamador o el framework de la plataforma las consuma y destruya tras finalizar la operación de lectura. Pregunta Q-f7af8c361e9352b0 (abierta) La transferencia de propiedad se produce directamente al receptor del resultado de lectura. En cuanto la rutina de procesamiento ha leído los datos necesarios, la estructura se libera automáticamente al salir del ámbito de validez. Respecto a la concurrencia, <DataElement>ReadOutput no ofrece sincronización interna. Dado que en el flujo de llamadas regular las instancias se transfieren exclusivamente al llamador respectivo, no está previsto un uso compartido entre distintos hilos en el funcionamiento estándar.

Ruta de uso

La ruta de uso típica abarca desde el disparo de una solicitud de lectura hasta el procesamiento de los parámetros de salida suministrados. Una secuencia típica se desarrolla de la siguiente manera:

• Solicitud: un cliente de diagnóstico o el framework adaptativo solicita la lectura de un elemento de datos a través del método de la interfaz <DataElementInterface>.
• Instanciación y rellenado: el componente de software proveedor determina los datos de diagnóstico actuales, crea una instancia de <DataElement>ReadOutput y asigna a sus campos de datos los valores registrados.
• Retorno: la estructura rellenada se transmite como resultado de la operación al framework solicitante.
• Consumo: el framework o el componente llamador accede a los argumentos de salida contenidos, formatea la respuesta de diagnóstico y finaliza el procesamiento de la consulta.

Tras una transferencia y extracción correctas de los campos de datos, la instancia pierde su validez y se descarta sin más pasos de interacción.

Escenarios de error

Interpretación: es previsible que el fallo de una operación de lectura no se represente a través de la propia estructura, sino a través del mecanismo envolvente de resultados o errores de la plataforma (por ejemplo, ara::core::Result o ara::core::Future). Pregunta Q-7d16241843f2d5e6 (abierta) Como estructura de datos pura, <DataElement>ReadOutput no declara métodos, precondiciones ni códigos de error propios. En caso de que falle el acceso de lectura a un elemento de datos —por ejemplo, debido a permisos insuficientes, estados de sistema no válidos o problemas de comunicación con los sensores subyacentes—, la interfaz implementadora señala este error a través del canal de errores de nivel superior de la plataforma. En tal caso de error no se proporciona ninguna instancia válida de <DataElement>ReadOutput para su evaluación, evitando así interpretaciones erróneas de datos útiles incompletos en el lado del llamador.