interfaz de servicio UpdateRequest

El método de servicio PrepareRollback de la interfaz de servicio UpdateRequest es invocado por Update and Configuration Management para preparar la reversión de modificaciones para los grupos de funciones de un clúster de software transferidos en el parámetro functionGroupList [SWS_SM_91105]. La llamada se realiza sin semántica Fire-and-Forget, de modo que State Management comunica el resultado de la preparación al llamador [SWS_SM_91105].

Para la llamada y el tratamiento de errores rigen condiciones fijas:

• Contexto de sesión: la llamada solo está permitida dentro de una sesión de actualización activa. Si se realiza fuera de una sesión activa, State Management rechaza la operación con el error kOperationRejected [SWS_SM_00213].
• Errores de aplicación: además de kOperationRejected en caso de un estado interno no válido, el método puede devolver kOperationFailed si la preparación falla [SWS_SM_91105].

En el modelo de estados, la invocación del método tiene repercusiones directas sobre las máquinas de estados involucradas:

• Las máquinas de estados que gestionan uno de los grupos de funciones transferidos son marcadas por el proceso controlador como ImpactedByUpdate [SWS_SM_00654].
• Si se marca una máquina de estados de tipo Agent, este estado pasa transitivamente también al Controller de nivel superior [SWS_SM_00655].
• Para las máquinas de estados identificadas como ImpactedByUpdate, los errores de ejecución notificados (ExecutionErrorEvent::executionError) no se tratan mediante una recuperación, sino que se ignoran y únicamente se registran [SWS_SM_00664].

usar

El método de servicio PrepareUpdate es llamado por Update and Configuration Management (UCM) para solicitar a State Management la preparación de la actualización de un conjunto de grupos de funciones [SWS_SM_00206], [SWS_SM_91103]. Se proporciona a través de la interfaz de servicio UpdateRequest y recibe como parámetro de entrada la lista functionGroupList de tipo FunctionGroupListType, la cual especifica los grupos de funciones que se van a actualizar dentro del clúster de software [SWS_SM_91103]. Dado que Fire & Forget está desactivado, la llamada posee una semántica de respuesta síncrona con confirmación al llamador [SWS_SM_91103].

Condiciones de orden y concurrencia

Una llamada solo es admisible dentro de una sesión de actualización iniciada previamente con éxito mediante RequestUpdateSession [SWS_SM_91103]. Durante la llamada, el proceso de control marca todas las máquinas de estados que gestionan uno de los grupos de funciones transmitidos como ImpactedByUpdate [SWS_SM_00654]. Si esto afecta a una máquina de estados de tipo Agent, la máquina de estados Controller de nivel superior también se marca automáticamente como ImpactedByUpdate [SWS_SM_00655]. Mientras exista este estado, las transiciones de estado externas se bloquean: cada llamada a RequestTransition se responde con kUpdateInProgress [SWS_SM_00649]. Además, las solicitudes de recuperación en caso de errores de ejecución (ExecutionErrorEvent::executionError) se ignoran y únicamente se registran [SWS_SM_00664].

Manejo de errores

Para el método se han definido dos errores de aplicación específicos [SWS_SM_91103]:

• kOperationRejected: Se devuelve si la llamada se produce fuera de una sesión de actualización activa [SWS_SM_00213] o si el estado interno de State Management rechaza la operación [SWS_SM_91103].
• kOperationFailed: Indica que la preparación solicitada de los grupos de funciones ha fallado [SWS_SM_91103].

Interpretación: El método debería retornar solo tras la iniciación o conclusión de los cambios de estado internos de los grupos de funciones, ya que en la interfaz no se define ningún mecanismo de confirmación asíncrono independiente. Pregunta Q-9994d886fd5504d8 (abierta)

El método de servicio RequestUpdateSession de la interfaz UpdateRequest se invoca sin parámetros (Fire & Forget: false) y sirve a Update and Configuration Management como punto de entrada para iniciar una actualización de software [SWS_SM_91102]. Mediante la llamada se inicia la transición a una sesión de actualización activa, que perdura hasta la finalización de la actualización [SWS_SM_00210] [SWS_SM_00213].

Por máquina solo puede haber tipificado como máximo un puerto con la interfaz UpdateRequest [SWS_SM_CONSTR_00020], el cual solo puede ser proporcionado por un proceso que controle una StateMachine de tipo Controller [SWS_SM_00629]. Para garantizar la coherencia de la plataforma, en cada instante solo puede estar activa una única sesión de actualización [SWS_SM_00210]. Además, State Management persiste el estado de la sesión para que este pueda leerse tras reiniciar la máquina [SWS_SM_00204].

La aceptación exitosa de la sesión es una condición de orden estricta: los métodos posteriores como PrepareUpdate [SWS_SM_91103], ResetMachine [SWS_SM_91100] o StopUpdateSession [SWS_SM_91101] requieren que RequestUpdateSession se haya invocado previamente con éxito [SWS_SM_00213].

En caso de error se definen dos errores específicos de la aplicación [SWS_SM_91102]: si se invoca el método durante una sesión que ya está en curso, devuelve kNotAllowedMultipleUpdateSessions [SWS_SM_00209]. Si la verificación (por ejemplo a través de la interfaz UpdateAllowed) determina que la máquina no permite actualmente una actualización, la solicitud se rechaza con el error kOperationRejected [SWS_SM_00630].

El método de servicio ResetMachine en la interfaz de servicio UpdateRequest es invocado por Update and Configuration Management (UCM) para solicitar un reinicio de la máquina durante una sesión de actualización en curso [SWS_SM_91100]. El método no posee parámetros de transferencia y está declarado con semántica fire-and-forget [SWS_SM_91100].

Antes de llevar a cabo el reinicio, toda la información interna de la máquina debe guardarse de forma persistente [SWS_SM_91100]. Para ello, State Management asegura los datos de la sesión de actualización activa con el fin de que UCM pueda continuar de forma consistente el proceso de actualización tras el rearranque de la máquina [SWS_SM_00204]. Al invocar el método, el proceso de control transfiere la StateMachine de tipo Controller al estado Restart [SWS_SM_00658]. Una vez efectuado el reinicio de la máquina, el Controller pasa al estado ContinueUpdate para la reanudación de la actualización SWS StateManagement §7.2 «ResetMachine notification».

Para la sincronización y el seguimiento de la ejecución, State Management proporciona el campo ResetMachineNotifier [SWS_SM_00211] [SWS_SM_91106], cuyo valor inicial es kIdle [SWS_SM_00212]. Dado que ResetMachine está diseñado como una llamada de tipo fire-and-forget, es de suponer que UCM supervise el resultado del reinicio primordialmente de forma asíncrona a través de este notificador (interpretación). Pregunta Q-732913d75d024929 (abierta)

Si previamente no se estableció con éxito una sesión de actualización mediante RequestUpdateSession, la llamada se rechaza y devuelve el error kOperationRejected [SWS_SM_91100]. En caso de una llamada fuera de una sesión de actualización, el proceso establece además el valor del campo ResetMachineNotifier en kRejected [SWS_SM_00661].

El campo de servicio ResetMachineNotifier de tipo UpdateStatusType [SWS_SM_91027] pertenece a la interfaz de servicio UpdateRequest y sirve para permitir a Update and Configuration Management (UCM) el seguimiento del estado del método ResetMachine durante su ejecución y después de ella [SWS_SM_00211] [SWS_SM_91106]. El campo proporciona un getter así como un notificador, pero no posee ningún setter [SWS_SM_91106]. Es de esperar que UCM se suscriba típicamente al notificador para recibir cambios de estado tras el reinicio de la Machine de forma asíncrona y sin sondeo (polling). Pregunta Q-122f44b23cd76238 (abierta)

El ciclo de vida del campo comprende los siguientes estados y transiciones de estado:

• Valor inicial: El valor predeterminado del campo es kIdle [SWS_SM_00212].
• Rechazo fuera de una sesión: Si se produce una llamada a ResetMachine fuera de una sesión de actualización activa, el proceso controlador modelado establece el valor del campo en kRejected [SWS_SM_00661].
• Reinicio y continuación: Dentro de una sesión de actualización, ResetMachine conduce a una transición al estado Restart [SWS_SM_00658]. Tras el arranque de la Machine, State Management y UCM se sincronizan de nuevo. Al completarse con éxito la transición a ContinueUpdate, el campo se establece en kSuccessful [SWS_SM_00662].
• Caso de error: Si falla la ejecución de la transición a ContinueUpdate, el valor del campo cambia a kFailed [SWS_SM_00663].

Si se finaliza la sesión de actualización mediante StopUpdateSession, la State Machine cambia al estado AfterUpdate [SWS_SM_00646] y State Management restablece el campo ResetMachineNotifier de nuevo a su valor predeterminado kIdle [SWS_SM_00660].

El método de servicio StopUpdateSession de la interfaz de servicio UpdateRequest ([SWS_SM_91101]) es llamado por Update and Configuration Management tan pronto como la actualización ha finalizado y la Machine se encuentra en un estado estable. La llamada se realiza sin parámetros y posee una semántica de solicitud-respuesta síncrona o asíncrona (Fire & Forget es false).

Condiciones de llamada y tratamiento de errores

La ejecución requiere una sesión de actualización iniciada previamente con éxito. Si la llamada a StopUpdateSession se produce fuera de una sesión de actualización activa, la solicitud se rechaza y devuelve el error kOperationRejected ([SWS_SM_00213], [SWS_SM_91101]).

Comportamiento del sistema y transiciones de estado

La llamada finaliza la sesión de actualización en curso (AUTOSAR_AP_SWS_StateManagement p. 90). En State Management, esto desencadena varias acciones coordinadas:

• El proceso modelado que controla la StateMachine de tipo Controller la transfiere al estado AfterUpdate ([SWS_SM_00646]).
• El campo ResetMachineNotifier se restablece de nuevo a su valor por defecto ([SWS_SM_00660]).
• Para instancias de StateMachine de tipo Controller se cancela el bloqueo de RequestTransition; las llamadas subsiguientes ya no responden con kUpdateInProgress ([SWS_SM_00647]).
• La marca ImpactedByUpdate se elimina de las instancias de StateMachine afectadas ([SWS_SM_00656]), con lo que se vuelven a habilitar los cambios de estado regulares y las Recovery Actions.

Uso y contexto de llamada

El método de servicio VerifyUpdate es invocado por Update and Configuration Management (UCM) a través de la interfaz de servicio UpdateRequest para encargar a State Management la verificación de grupos de funciones actualizados [SWS_SM_00207]. Como parámetro se transfiere functionGroupList (tipo FunctionGroupListType), el cual contiene la lista de los grupos de funciones que se deben comprobar en el SoftwareCluster correspondiente [SWS_SM_91104]. Dado que el método no está definido como Fire-and-Forget (Fire & Forget: false), el llamador espera una respuesta síncrona o disponible tras la finalización [SWS_SM_91104].

Secuencia y tratamiento de errores

La llamada está sujeta a estrictas condiciones de estado: solo está permitida dentro de una sesión de actualización activa y presupone que State Management haya autorizado la actualización y que la fase PrepareUpdate haya concluido previamente con éxito [SWS_SM_91104].

• kOperationRejected: se devuelve si la llamada se realiza fuera de una sesión de actualización activa [SWS_SM_00213] o si el estado interno de State Management o de las máquinas de estados involucradas rechaza la verificación (por ejemplo, si PrepareUpdate no tuvo éxito) [SWS_SM_91104].
• kOperationFailed: indica que la operación de verificación solicitada ha fallado [SWS_SM_91104].

Interacción y concurrencia

Durante el procesamiento, el proceso modelado controlador de una StateMachine de tipo Controller marca cada máquina de estados como ImpactedByUpdate cuyos grupos de funciones gestionados estén listados en functionGroupList [SWS_SM_00654]. Si esto afecta a una StateMachine de tipo Agent, el Controller asociado también se marca indirectamente como ImpactedByUpdate [SWS_SM_00655]. Mientras este estado esté activo, los errores de ejecución notificados (ExecutionErrorEvent::executionError) por Platform Health Management o Execution Management se ignoran y únicamente se registran [SWS_SM_00664]. Presumiblemente, las máquinas de estados afectadas se sitúan durante este paso en el estado VerifyUpdate, que forma parte de los cinco estados obligatorios de toda StateMachine AUTOSAR_AP_SWS_StateManagement §7.7.1 «StateMachine introduction». Pregunta Q-cd5deaf13acfc2f5 (abierta)