The primary module that is responsible for discovering and managing updating images on various devices. On initialization or at some configured times, the Device Update manager will scan the update sub-filesystem of the rootfs for new images and announce the found images on the IARM bus. This can be extended to communicating with a server to identify updates on an update server that can be pulled down and announced. The Device Update Manager will also be able to aggregate data about devices that are downloaded and downloaded sessions that are executed. It will be able to gate when downloads go to devices and when they are loaded on devices. And it will be able to officiate between multiple Device Update Proxy's requesting downloads over low bandwidth or highly utilized mediums.

Device Update Proxy

Each class of devices will have a single Device Update Proxy responsible for managing updates to its child devices. A Device Update Proxy can represent multiple devices as long as they are in the same class. An example of this is remote controls. The Device Update Proxy will be responsible for listening for announcements and accepting updates for specific devices that are ready for an update. It is assumed the Device Update Proxy will know the version of devices it manages and can either contact them to notify them of the update or receive polls from them asking about an update. The Device Update Proxy is responsible for understanding the physical transport connecting devices  to the STB and whether downloads to those devices must be serialized or can be parallelized (and how many can be parallelized). The Device Update Manager can also restrict parallelized downloads across the same or different transports. The Device Update Proxy is responsible for accepting download and load events, informing on the status of these events and negotiating the download with the device over the device specific protocol.

Update Master 

The system can be figured with a config file to allow the Device Update Manager to fully manage device update activities or to have a third entity, called the Update Master, to initiate either/or downloads and loads. An example of an Update Master would be a UI which would query the user if they wanted to load and/or download the code. In a typical usage, the UI would gate on the download, then perform an immediate download followed by an automatic load or would perform a background download followed by a gated load.

Standard Call/Event sequences

Background Download and Load during Non-usage Time (middle of night)

#define IARM_BUS_DEVICE_UPDATE_MASTER_DOWNLOAD_ENABLED 0
#define IARM_BUS_DEVICE_UPDATE_MASTER_LOAD_ENABLED 0

1. Device Update Manager performs check and finds new device image in update sub-filesystem in the rootfs.
2. Device Update Manager sends an ANNOUNCE event with details of the new image
3. The Device Update Proxy receives the Announce, decides a device it manages needs it and calls AcceptUpdate to register its intent with the Device Update Manager and get an updateSessionID.
4. When the Device Update Proxy negotiates with its managed device that a download is ready and confirms the device is ready and able to receive the download, it sends the READY_TO_DOWNLOAD event with all of the relevant information about the download it is taking.
5. The Device Update Manager sends a DOWNLOAD_INITIATE event to begin the download with backgroundDownload set to true.
6. The Device Update Proxy sends DOWNLOAD_STATUS events back for 0, the requested percent increments, and finally 100.
7. If, say, its 8 PM, the Device Update Manager sends a LOAD_INITIATE event with a timeToLoad of 25200 and a timeAfterInactive of 300 seconds which will put the download happening at 3 AM and after 5 minute of inactivity (just in case the user is still using it.
8. At 3:05 AM (presumably and approximately), the device begins the load causing the Device Update Proxy to send a LOAD_STATUS of BEGIN. The device does what it needs to do to load the new image, notifying the Device Update Proxy when done, which then sends ao LOAD_STATUS of END. This will complete the session.

User confirmed Immediate Download and Load

#define IARM_BUS_DEVICE_UPDATE_MASTER_DOWNLOAD_ENABLED 1
#define IARM_BUS_DEVICE_UPDATE_MASTER_LOAD_ENABLED 0

1. Device Update Manager performs check and finds new device image in update sub-filesystem in the rootfs.
2. Device Update Manager sends an ANNOUNCE event with details of the new image
3. The Device Update Proxy receives the Announce, decides a device it manages needs it and calls AcceptUpdate to register its intent with the Device Update Manager and get an updateSessionID.
4. When the Device Update Proxy negotiates with its managed device that a download is ready and confirms the device is ready and able to receive the download, it sends the READY_TO_DOWNLOAD event with all of the relevant information about the download it is taking.
5. A UI agent would be listening for this event and would pop up a window asking the user if he wants to download X update for Y device. 
6. The user would click yes and the UI agent would send a DOWNLOAD_INITIATE event to begin the download with backgroundDownload set to false with increments as desired to update status bar on the screen.
7. The Device Update Proxy sends DOWNLOAD_STATUS events back for 0, the requested percent increments, and finally 100. The UI agent would receive these events and update the status bar on the screen appropriately (also accounting there will be a load at the end).
8. When the Device Update Manager sees the 100% DOWNLOAD_STATUS, it would send a LOAD_INITIATE event with a timeToLoad of 0 and a timeAfterInactive of 0 causing the load to Immediately happen
9. The device immediately begins the load causing the Device Update Proxy to send a LOAD_STATUS of BEGIN. The device does what it needs to do to load the new image, notifying the Device Update Proxy when done, which then sends a LOAD_STATUS of END. This will complete the session.