C. Variation in system design parameters

Depending on the system design and product requirements, an implementation is permitted to collapse a chain of transitions for a component, where this does not remove information that is required by the update client, or compromise other system requirements. This can result in some states and transitions being eliminated from the state model for that component’s firmware store.

An implementation is also permitted to provide either volatile or persistent behavior for the WRITING, CANDIDATE, FAILED, and UPDATED states. See also Volatile states. Volatile states cause additional transitions to occur at reboot.

Table 7 lists a sample of the possible variations that are illustrated in this appendix, as well as the complete state model provided in Programming model.

Table 7 Variations of the state model

Reboot required	Trial required	Staging type a	Description
Yes	Yes	Non-volatile	See complete model
Yes	Yes	Volatile	See complete model with volatile staging
Yes	No	Non-volatile	See no-trial model
Yes	No	Volatile	See no-trial model with volatile staging
No	Yes	Non-volatile	See no-reboot model
No	Yes	Volatile	See no-reboot model with volatile staging
No	No	Non-volatile	See basic state model
No	No	Volatile	See basic state model with volatile staging

1. If the staging type is volatile, then CANDIDATE, WRITING, FAILED, and UPDATED states are volatile.

   If the staging type is non-volatile, then CANDIDATE state is non-volatile, and it is implementation defined whether WRITING, FAILED, and UPDATED states are volatile.

C.1. Component with non-volatile staging

A component that does not have volatile staging will maintain the CANDIDATE component state across a reboot, and can optionally maintain the WRITING, FAILED, and UPDATED component states across a reboot.

• Additional reboot transitions for states with optional volatility are indicated with ‘†’ and ‘‡’ marks on the state, and described in the figure legend.

See Component with volatile staging for example state models for a component that has volatile staging.

C.1.1. Component that requires a reboot, but no trial

If a component does not require testing before committing the update, the the TRIAL and REJECTED states are not used.

• The reboot that installs the firmware will transition the component to UPDATED on success, or FAILED on failure, unless the target state is volatile, in which case the reboot will transition the component to READY.

• The accept operation is never used.

• The reject operation is only used to abandon an update that has been STAGED.

The simplified flow is shown in Figure 9.

Figure 9 State model for a component that does not require a trial

C.1.2. Component that requires a trial, but no reboot

If a component does not require a reboot to complete installation, the STAGED and REJECTED states are not used.

• The install operation will complete the installation immediately, transitioning to TRIAL if successful.

• The reject operation from TRIAL state does not require a reboot to complete. A reject operation from TRIAL states transitions directly to FAILED.

The simplified flow is shown in Figure 10:

Figure 10 State model for a component that does not require a reboot

Implementation note

There is no ability for the update service to automatically reject a TRIAL, because a reboot does not affect this component’s installation.

C.1.3. Component that requires neither a reboot, nor a trial

If a component does not require a reboot to complete installation, and does not require testing before committing the update, then the STAGED, TRIAL, and REJECTED states are not used.

• The install operation will complete the installation immediately, transitioning to UPDATED if successful.

• The accept and reject operations are not used.

The simplified flow is shown in Figure 11:

Figure 11 State model for a component that does not require a reboot or trial

C.2. Component with volatile staging

A component that has volatile staging does not maintain the WRITING, CANDIDATE, FAILED, and UPDATED component states across a reboot.

In each case the state model is very similar to the associated state model for a component with non-volatile staging, except that a reboot now affects almost all states:

• WRITING, CANDIDATE, and FAILED states will always revert to READY, discarding any image that had been prepared or rejected.

• UPDATED state is progressed to READY.

• Existing reboot transitions from STAGED, TRIAL, and REJECTED, that go to FAILED in the non-volatile-staging model, are reverted to READY.

• The existing reboot transition from STAGED to UPDATED for a successful installation in the ‘no trial’ model, transitions to READY.

The modified flows are shown in the following figures:

• Modified reboot transitions are shown explicitly in the diagrams.

• New reboot transitions are indicated with ‘*’, ‘†’, and ‘‡’ marks on the state, and described in the diagram legend.

Figure 12 Full state model for a component with volatile staging

Figure 13 State model for a component with volatile staging that does not require a trial

Figure 14 State model for a component with volatile staging that does not require a reboot

Figure 15 State model for a component with volatile staging that does not require a reboot or trial