Due to the nature of OCAP, the high-level software architecture is much more complex than in an MHP receiver. Before we can really understand how to use OCAP to its full potential, we need to know some more about the software architecture of an OCAP receiver.  Without this overall knowledge of the architecture, some parts of the OCAP standard don’t make much sense – hopefully, but the end of this chapter some things will be a little clearer.

Most of this complexity is introduced because of the nature of the cable TV business in the US. Network operators traditionally have much more control over some elements of the receiver that are the responsibility of the receiver manufacturer in other markets. In particular, OCAP allows the network operator to have a far bigger say in what applications get started and when (going far beyond the application signaling that is in the transport stream) and in how the receiver responds in certain conditions such as resource conflicts. Some of the functions in an OCAP receiver are only available after a network operator has downloaded their own software into the receiver.

MHP receivers don’t have these issues, since the navigator is much more tightly coupled with the firmware. In an OCAP receiver, the navigator functionality and even some of the functionality provided by the MHP middleware is contained in a separate application that must be downloaded from the network operator. We will examine this in more detail later.

The basic OCAP software stack is shown in the diagram below:

A diagram of the OCAP software stack.

One of the most important components of the software stack is the Execution Engine. This contains more or less all of the important parts of the midleware, including a Java virtual machine for running OCAP applications, modules for parsing service information, resource and application management and the various other things that have to be done in order to let the viewer watch TV and run OCAP applications.

The execution engine itself is split into a number of separate subsystems. As we’ve already mentioned, the Java VM is one of these, but that is not shown on the diagram above. The other modules are described in a little more detail below. It’s important to remember that these modules are a logical separation of the important functions, and they don’t include all of the functionality that makes up an PCAP receiver. Some of the APIs that are covered by the OCAP specification don’t fit into any of these modules.

The Executive Module is that part of the firmware that boots the receiver and starts the monitor application. It’s also responsible for controlling the receiver if there is no monitor application, or if the receiver isn’t connected to a cable network. The Executive Module monitors the XAIT and launches the monitor application that’s signaled with the highest priority. In the event that no monitor application is signaled, the Executive Module will launch any unbound applications that are signaled as being auto-start.

In addition to monitoring the XAIT signaling, it monitors the state of the monitor application by registering as a listener for XletStateChangedEvents. If the monitor application is destroyed for any reason (such as the monitor application has upgraded itself and wants to restart), the Executive Module launches a new copy of the monitor application that’s being signaled.

The monitor application is, in effect, just another OCAP application that happens to have been granted special powers by the network operator. It communicates with the Executive Module via the standardized OCAP APIs, and the Executive Module monitors its state using those same APIs. Once it’s been loaded, the monitor application takes over responsibility for monitoring all application signaling and for launching any application, be they service-bound or unbound. It also takes responsibility for upgrading any applications that are stored in the receiver’s persistent memory, which may include the monitor application itself. Basically, the monitor application is in complete control of the system once it loads. In theory, there is no access to the Executive Module using the OCAP APIs. In practice, though, some of the standard OCAP APIs may actually use functionality from the Executive Module, or at least the OCAP APIs and Executive Module will rely on common functionality provided by other parts of
the middleware.

There is far more to the monitor application than we’ve covered here, and the relationship between it and the Executive Module has a few more details than we’ve seen so far. We will address some of these issues in other sections.

As you can see from the diagram above, there are a number of other modules in the execution engine that we have not yet discussed. The System Information Module parses and monitors in-band and out-of-band service information. This information can then be access by applications, using the JavaTV Service Information API or other APIs. In some cases, the System Information Module will also pass on information to other modules in the middleware. For instance, any Emergency Alert System messages will be passed on to the Emergency Alert System Module, which we’ll look at later in a bit more detail.

Any in-band service information that’s broadcast in the clear is made available to applications via the JavaTV service information API. Similarly, if the receiver has a POD inserted, out-of band service information is also processed and (if that service information is compliant with the ANSI/SCTE 65 specification, or is contained in the XAIT). It is also made available to applications through the appropriate API. This may be the service information API, or the application listing and launching API in the case of XAIT information. XAIT information is also forwarded to the Executive Module.

The Closed Captioning Module is responsible for handling closed caption subtitles. This feature needs to work even if a monitor application is not running, and the Closed Captioning Module parses any closed caption signals in the current stream and handles them as necessary. In the case where the receiver has video outputs that support NTSC closed caption signals, the closed caption data is added to the VBI on the output. In this cases where the outputs don’t support NTSC closed caption signals, the closed caption data is decoded and overlaid on the video output by the receiver itself.

The Content Advisory Module is the module that supports the V-Chip functionality that’s required by the US government. This module decodes any V-Chip signals that are contained in the incoming VBI data and forwards those signals to any other modules in the receiver that need to access it. This module only handles analog content rating systems – any parental rating information that’s carried in the digital signals is handled elsewhere in the system.

The Download Module allows the network operator to upgrade the firmware of the receiver in the field. This is a common feature in set-top boxes, and it allows the network operator to fix bugs or add features to receivers that are already deployed. In OCAP receivers, this module should comply with the OCAP Common Download Specification.

The OCAP middleware provides hooks that allow the monitor application to use this module for downloading new versions of the firmware.

The Copy Protection Module supports the receiver’s copy protection systems. This can either be an analog system such as Macrovision, or a digital system on those receivers which support digital outputs. OCAP applications can control the copy protection systems using the org.ocap.hardware.CopyControl class and the persistent storage API, and can also reduce the resolution on analog outputs for high-definition signals. This module is also used by those OCAP receivers that support Personal Video Recorder (PVR) functions.

The most important function of an OCAP receiver is to allow the user to watch TV – that’s why they bought it (or subscribed to the service, or whatever) in the first place. The Watch TV Module provides the user with the basic channel zapping functionality that you would expect. At its simplest this can be channel up/down, or it can be something more complex. Like some of the other modules in the system, a downloaded application can (under the right circumstances) take over the functionality of this module. This allows the network operator to provide more sophisticated features such as integration with an EPG or premium services. Later in this tutorial, we will see how applications can take over some of the functions of system modules – modules that allow this are called assumable modules (because another application can assume their task).

Another assumable module is the Emergency Alert System Module. As we’ve already seen, the Emergency Alert System is a system required by the US government that enables the network operator to force the receiver to display messages during local or national emergencies.

This module parses any Emergency Alert System messages that are received by the System Information Module and handles them in the appropriate way. This may involve displaying a message, playing a sound or tuning to a new service.

Finally, we have the POD Resources Module. This processes messages from the POD hardware relating to the man-machine interface, application information or specific applications. Like some of the other modules that we’ve seen so far, this is also an assumable module. Unlike the other modules, however, this functionality is actually shared as three sub-modules (called resources) which have different rules about how their functionality can be taken over.

The MMI resource can only be replaced by one application at a time, because only one application should be in control of displaying MMI messages from the CA system in order to avoid confusion. The application information resource and specific application resource can have several applications registered as replacements.

The monitor application in more detail

As we’ve already seen, the monitor application plays an important part in an OCAP receiver, acting as a cross between a navigator, a part of the middleware and the network operator’s representative in the receiver. 
Why is this a separate application? Why not move this functionality in to the middleware?

Partly, it allows the network operator to enforce common behaviour across receivers. In an MHP system, two different receivers on the same network may behave differently when resolving a resource conflict between two applications. In an OCAP system, they will probably behave the same, but they may both behave differently when they’re plugged into a different network. This allows the network operator to make the user experience as close to identical as possible, no matter who built the receiver. 
If all boxes on a network are running the same monitor application, you know that the behaviour will be identical in those areas that the monitor application has responsibility.

There is another part to this, of course. Controlling the monitor application also gives the network operator more control over the receivers, and takes some of the control away from the receiver manufacturer. From the point of view of the network operators, this makes some sense in that it allows them to give their brand more exposure to the customer and provide another way to help them sell premium services.

So, now that we’ve heard a little about the monitor application, what does it actually do?

Resource arbitration. In MHP, two receivers on the same network may resolve a resource conflict in different ways. Two OCAP receivers that share a network will resolve the conflict in the same way, but a receiver on one network may resolve the conflict in a different way to the same receiver on another network. This has advantages and disadvantages, but it does mean that the user sees more consistent behaviour from receivers on the same network.

Application registration. The monitor application is responsible for registering unbound applications with the receiver’s application database. This allows other applications to control unbound applications should they wish to do so (and should the monitor application allow them).

Application validation. Before any application can be started, it must be validated by the monitor application. This enables the network operator to keep tight control over what applications get started and when. We will talk about the process of validating applications later in this tutorial.

Error handling. The monitor application will handle any errors that get propagated to it from the OCAP middleware, underlying OS or even other OCAP applications. This provides a general mechanism for handling certain types of general errors, such as out of memory errors, where the network operator can decide to implement a standard way of handling them. Why is this useful? Well, having the same error behaviour on every receiver on a network can reduce support costs (since there’s only one set of error messages for tech support staff to decipher) and make sure that users get consistent behaviour even when there’s a problem.

Software upgrades. The monitor application has the ability to store applications in the flash memory of the set top boxes, and to upgrade these stored applications. Typically this will get used by the network operator to make sure that any unbound applications provided by the network operator are up-to-date and will load quickly. Since the monitor application is itself an unbound application, it can upgrade itself in the same way. Upgrading the rest of the receiver’s firmware isn’t quite so easy, however – this still depends on other methods.

User input event handling. Before any other application has access to user input events, they will pass through the monitor application. During this process, the monitor application can choose to modify them or even block them completely. This allows applications to receive a common set of user input events for all keys on the remote control, even those not standardized by OCAP. The monitor application can choose how keys are mapped across remote control units, and even whether certain keys have any effect at all.

System reboots. Should the receiver need to reboot for any reason, the monitor application can request this. Similarly, it can choose to register for notification when other parts of the system cause a reboot.

Managing copy-protection hardware. The monitor application can use the org.ocap.hardware.CopyControl class to enable or disable analog copy protection schemes such as Macrovision. Using the same interface, it can also enable or disable down-conversion of high-definition services to standard definition.

As you can see from this list, OCAP monitor applications can do an awful lot of things that an MHP navigator can’t. In some cases, there are good practical reasons for this, but in other cases it’s driven purely by the existing business models of the cable operators. Whether or not this is a good thing is debatable, and some electronics retailers in the US have tried to get the monitor application removed from OCAP (or at least, get a lot of its power removed), but that hasn’t happened yet.

OCAP is not really aimed at a horizontal market in the same way that MHP is, and sometimes it shows. This is one of the places where it shows most clearly. It’s a way of introducing some elements of a horizontal market (by letting the consumers buy the receiver and allowing receivers to be moved from one network to another) while still retaining a large element of vertical market philosophy (since the network operator has more-or-less full control over any receiver plugged into their network).

Software architecture – differences from MHP

• Many of the functions in OCAP receivers are controlled by the monitor application. This is a special application provided by the network operator that combines some of the features of a navigator with some functionality normally implemented in MHP middleware

• This gives the network operator much more control over an OCAP receiver than over a comparable MHP receiver
• OCAP allows applications to be stored in persistent memory

• OCAP adds support for native applications. These must have an OCAP-compatible wrapper written in Java

• All applications in an OCAP receiver, including native applications, resident applications and the monitor application are OCAP applications

• The OCAP execution engine (effectively, the middleware stack) contains functionality in several well-defined modules.

• The monitor application may register an OCAP application (possibly itself) to take over the functionality of some of these modules