The OCAP Monitor Application

The Monitor Application is a special unbound application which is designed to help manage execution of OCAP applications on an OCAP receiver.

According to the OCAP specification, the MSO is responsible for the development, maintenance and delivery of the Monitor Application. The features included in the Monitor should be directly a function of the MSO's requirements. The OCAP specification does not require that the Monitor Application is deployed, however there are considerable commercial reasons why it should be.

The OCAP specification defines a set of privileged APIs which can be used by Monitors. Consequently, Monitor Applications will need to be authenticated and provided with the appropropriate Permission Request File. UniSoft OCAP SFG can fulfil this role.

Whilst it is up to the MSO to define the exact role of the Monitor, the OCAP specification gives a good indication of what features may be included in the Monitor. These include:

1. Filter User Input events (key press on the remote). Values may be changed prior to sending to an application. This will allow the MSO to present a consistent 'feel' to the user for each application.
2. Register unbound applications in the applications database. All application lifecycle management should be controlled.
3. Application Filtering. Establish a "black and white" list, which the system uses to determine whether to accept or reject broadcasted applications on the OCAP receiver. The filter can be based on organization ID, application priority or other factors specified.
4. Validation of Application Permissions. For those applications which have successfully passed through the application filter, the Monitor Application determines if the application has been granted the correct permissions to run. This will allow the MSO to control which applications will run on the OCAP receiver and is vital for commercial reasons. A request for permissions to access specific resources is defined in a signed Permissison Request File which needs to be broadcast with the OCAP application.
5. Resource Contention. Upon resource contention, the Monitor Application will be called and it will decide which application gets the resource. Typical resources include memory and the display. Resource contention deadlocks will also be managed.
6. System Reboot. The Monitor Application can request a system reboot and be alerted upon a system reboot to provide a graceful recovery to the viewer following a reboot.
7. Copy Protection bits and output resolution of the video can be changed.
8. Catch system errors. Interception of error messages, warnings and other notifications.
9. Emergency Alert System (EAS) handling and display.
10. Manage display of Closed-Captioning within an application.
11. Upgrades of the Monitor Application. When there is a new version of the XAIT file, the Monitor will be responsible to upgrade itself. This is important when a new OCAP receiver has be installed, when a receiver has been moved to a different network and when a new version of the Monitor has been made available.