SOFTWARE ANATOMY

Home networking services in the HAVi architecture are modeled as objects. An object is a self-contained entity that consists of both data and procedures to manipulate this data. Each object has a unique name and identifier. HAVi objects are commonly called software elements because they are accessible to programmers through a well-defined interface. All objects make themselves known to other objects via a system-wide naming service known as a registry. The registry is a distributed database that stores information about the HAVi objects. Objects often use the registry to find other objects on the network. All objects communicate with each other using a message-passing model. The intercommunication between HAVi objects commences with the assignment of software element identifiers (SEIDs). All SEIDs are unique; however, they may change as a result of a reconfiguration of the devices on the network. Objects use this identification number in conjunction with a general-purpose messaging mechanism to request services from other objects. The messaging mechanism consists of a suite of network and transport layer protocols that provide HAVi software elements with communication facilities. The actual implementation of this messaging system differs from vendor to vendor; however, the format of these messages and the protocols used for their delivery remains common across all HAVi-based home networks. To improve our understanding of the HAVi software architecture, let's examine the software elements of a typical FAV device (see Figure 11.1).

1394 Communication Media Manager (CMM)

The CMM is a network-dependent entity that is embedded in all FAV and IAV devices connected to the HAVi network. It interfaces with the underlying communication media to provide services to other HAVi components or application programs residing on the same device as the CMM. Each physical communication medium has its own CMM to serve the above purpose. This section concentrates only on the CMM for the 1394 bus. Two types of services are provided by CMM. One is to provide a transport mechanism to send requests to and receive indications from remote in-home appliances. The other is to abstract the network activities and present information to the HAVi system. The 1394 bus is a dynamically configurable network. When devices are plugged into or removed from the network, a "bus reset" occurs. After each bus reset, a device may have a completely different physical ID than it had before. If a HAVi component or an application has been communicating with a device in the network, it may want to continue the communication after a bus reset, though the device may have a different physical ID. The Global Unique ID (GUID) is used by CMM and other HAVi entities to uniquely identify a device regardless of frequent bus resets.

A GUID is a 64-bit number that is composed of 24 bits of IEEE 1394 vendor ID and 40 bits of chip ID. While a device's physical ID may change constantly, its GUID is permanent.

One of the advanced features the 1394 bus provides to the HAVi system is its support for dynamic device actions such as hot plugging and unplugging. To fully support this up to the user level, HAVi system components or applications need to be aware of these network changes. CMM works with the Event Manager (discussed below) to detect and announce such dynamic changes in network configuration. Since any topology change within the 1394 bus will cause a bus reset to occur, the CMM can detect topology changes and post an event to the Event Manager about these changes along with associated information. The Event Manager will then distribute a related event (called a network reset) to all interested HAVi entities or applications.

Messaging System

The messaging system provides HAVi software elements with communication facilities. It is independent of the network and transport layers. A messaging system is embedded in all FAV and IAV devices. The messaging system of a device is in charge of allocating identifiers (SEIDs) for the software elements of that device. These identifiers are first used by the software elements to register. They are then used by the software elements to communicate with each other within the home network.

Registry

The registry is a system service whose purpose is to manage a directory of software elements available within the home network. It provides an API to register and search for software elements. The registry service is present on all IAVs and FAVs. Within one device, any local software element can describe itself through the registry. If a software element wants to be contacted, it must register with the registry. The registry maintains, for each registered object, its identifier (SEID) and its attributes. The registry also provides a query interface that software elements can use to search for a target software element according to a set of criteria.

Event Manager

The event manager provides an event delivery service. An event normally happens when either a software element or the home-network itself changes state. For instance, the connection or disconnection of a digital appliance implies a change of state of the network and is likely (but not necessarily) to trigger an appropriate event. The delivery of an event is done either locally within a single device or globally to all devices in the network. To support this service, the event manager functions as an agent to help ensure the event posted by a software element will reach all software elements that care about the event. If a software element wishes to be notified when a particular event is posted, it must register such intention with its local event manager. Each event manager maintains an internal table containing the list of events registered by software elements. When a software element posts an event, it does so via a service provided by the event manager. The event manager checks its internal table and notifies those software elements that have registered this event. Software elements that do not register the event will not receive a notification. If the event was posted globally, the local event manager also relays the event to all remote event managers in the network. Each remote event manager performs the same lookup and notifies the registered local software elements. An event manager notifies software elements by using the HAVi messaging system; in particular, it sends a notification message to the software element that is to be notified. An event has an optional buffer that can be used to pass information related to the event. For instance, consider an input device with multiple buttons, a button-pressed event could be generated when the user presses a button. The software element that is notified of this event may also be interested in knowing which button was pressed. The event poster can optionally put additional information in a buffer and let the event manager pass this information to other software elements. A software element would get the optional information as part of the notification process and it is the software element's task to interpret the information. The event manager process is also present on all IAVs and FAVs connected to the HAVi-based home network.

Stream Manager

When a home network is up and running, HAVi uses different types of streams to transfer data between appliances. To manage the continuous flow of multimedia streams across a network, HAVi employs a software element called a stream manager. The main responsibility of a stream manager is to allocate network resources (such as network bandwidth and channel numbers) to home networking streams. The stream manager provides an easy-to-use API for configuring end-to-end isochronous connections. The streaming of content across a HAVi home network is based on the IEC 61883 plug control model. Under this model, any appliance on a home network that is capable of transmitting or receiving isochronous data implements virtual plugs for its inputs and outputs. A plug is best described as a software object that represents hardware I/O ports contained within a home networking device. A connection is made between an output plug on one appliance and one or more input plugs on other in-house appliances. Plug control registers (PCR) on each appliance specify the isochronous channel, device-specific I/O port numbers, and other parameters necessary for managing virtual connections across the bus. The stream manager is responsible for managing the plug control model. It should be noted that the stream manager can also support plugs associated with purely software elements. This enables an application to build a graph of connections, from source to sink, which pass through hardware and software processes—or filters. In this way, an A/V stream can be manipulated by various filters before eventually being consumed. An example might be a MPEG stream that is sourced from a VHS player, transcoded to digital video format, passed through a software filter that acts as a simple edit suite, and recorded (or consumed) in digital format on a hard drive that is connected to the home network. The following points summarize the features of the stream manager software element:

• The stream manager provides services only to applications that are running on the same appliance as the stream manager itself.

• A stream manager is required on FAV appliances. Implementation on a IAV appliance is required only if applications on the IAV need stream manager services.

• The stream manager is capable of constructing a map of all connections within the home network established by HAVi applications. The stream manager is also capable of reporting on usage of 1394 isochronous bandwidth by non-HAVi applications.

• Every stream of multimedia data that is managed by the stream manager has an associated stream type. This parameter identifies the representation of data, bandwidth allocation, and other attributes of the actual stream. A stream type identifier is formed from a 24-bit IEEE 1394 vendor ID and a 16-bit type number.

• After a home network reset, the stream manager invokes a set of procedures for restoring connections on your network.

• The stream manager establishes and maintains connections (internal and external). An internal connection transfers data within an in-home appliance. An external connection, on the other hand, transfers data between appliances and may involve the 1394 network or other forms of physical cabling.

Device Control and Functional Component Modules

In a HAVi network, a DCM (Device Control Module) exists for each appliance known in that network. The DCM provides home networking applications with an interface to the physical appliance. A DCM is a HAVi object in the sense that its details are stored in the registry and can communicate with other HAVi objects via the HAVi messaging system. Associated with a DCM are zero or more FCMs (Functional Component Modules). FCMs are software elements that represent the different functional components contained within a networked device. The number of FCMs within a DCM is flexible and may vary over time. HAVi applications do not communicate with a functional component directly but only through the FCM. HAVi has defined the following FCMs: tuner, VCR, clock, camera, A/V disc, amplifier, display, A/V display, modem, web proxy, and converter. The HAVi specification has also defined a number of interfaces for FCMs to help programmers develop home networking applications. FCMs and DCMs are identified to applications through a number called a HAVi unique identifier (HUID). Each DCM and FCM stores its HUID in the registry.

A DCM can be asked for the list of FCMs it currently contains. This flexibility allows a DCM to represent the functionality of an external device as FCMs. (An external device is one connected via an external plug to the device represented by the DCM itself.) External devices will normally contain a configuration parameter that describes itself to the HAVi DCM. For instance, it's an MP3 player manufactured by Sony and its model number is xxxxxx.

A DCM and its FCMs are obtained from the DCM code unit for the device. A DCM code unit is a piece of programming code that is related to a particular HAVi appliance. DCM code units can be written in Java bytecode or native code. The DCM management system is responsible for installing and uninstalling DCM code units.

For different types of HAVi devices, DCM play a different role:

• An IAV device may host one DCM representing itself and may host one or more DCMs representing LAVs (or BAVs operating in LAV mode).

• An FAV device may host one DCM representing itself and may host one or more DCMs representing LAV devices and/or BAV devices.

• A LAV device does not have any notion of DCMs. When attached to a HAVi network where one or more FAV or IAV devices know how to handle the LAV, one of them has to provide the DCM code unit to make the LAV available to other HAVi components.

• A BAV device does not host any DCMs, but provides a DCM code unit in Java bytecode. When attached to a HAVi network with one or more FAVs, one of them uploads and installs the DCM code unit to make the BAV device available to other HAVi components. Installation of the DCM code unit results in the installation of the DCM and all FCMs related to the device.

• When a BAV device is attached to a HAVi network with no FAV devices but with an IAV device that knows how to handle that BAV, an IAV device can provide a DCM code unit itself to make the BAV device available to other HAVi components.

Besides an API for controlling the in-home appliance, a DCM may also contain a device-specific application called a "havlet." Through this application, a manufacturer can provide consumers with a way to control any special feature of the electronic device in a way that is decided by the manufacturer. Because developing DCMs and FCMs requires knowledge of the underlying hardware and firmware architecture of the in-home device, they are normally developed by the device makers themselves.

Resource Manager

Within a HAVi environment, the management of resources is split between the stream manager and the resource manager. As described earlier, the stream manager handles the management of connections and bandwidth requirements. The resource manager deals with the reservation and release of hardware resources on your network. The hardware resources of in-home appliances can be reserved by an application for exclusive use, but can also be shared by more than one application. The resource manager is responsible for "scheduled actions." It allows applications to identify actions that are to take place at some specific time (such as a VCR recording) and then triggers these actions at the appropriate times. There is a resource manager on each FAV and IAV device that hosts or can host at least one DCM. All resource managers cooperate on a HAVi-based network to ensure that resource deadlocks are prevented.

In-Home Software Applications

In general, a HAVi application is one that creates software elements that use other software elements to provide specific services. A HAVi application may be developed in native code and embedded (resident) on an FAV or IAV. The applications that are run across an in-home network are conceptually similar to DCMs. They typically have proprietary functionality and can be created by third-party application developers. These applications use the APIs defined by HAVi, and supported by the HAVi software elements and HAVi DCM/FCMs to interact with and control home network devices.

HAVi in-home applications can be upgraded using two different techniques:

Havlets

In addition to the above software elements specified by the HAVi architecture, devices on an in-home network may also contain a number of havlets that are specific to a home-networking environment. A havlet is typically a proprietary application that offers a user interface for controlling appliances. For the actual control of the appliance, the havlet makes use of a DCM. A havlet is an object in the sense that it is registered in the registry and can communicate with other HAVi objects via the messaging system described earlier. Havlets only run on FAV-enabled appliances.

HAVi User Interfaces

The primary goal of the HAVi user interface for home networks is to provide the user with a comfortable operating environment. The HAVi Architecture allows users to control appliances through familiar means, such as via the front panel or via the buttons of a remote controller. In addition, the HAVi architecture allows manufacturers to specify graphical user interfaces (GUIs) which can be rendered on a range of displays varying from text-only to high-level graphical displays. The GUI need not appear on the device itself, it may be displayed on another device and the display device may potentially be from another manufacturer. To support this powerful feature, the HAVi architecture provides two mechanisms—the first, the Level 1 UI, is intended for IAVs and is called Data Driven Interaction (DDI); the second, the Level 2 UI, consists of APIs that are based on the Java programming language. DDI is essentially the encoding of user interface elements. The DDI elements can be loaded and displayed by a DDI controller. This controller is used by the home network to generate messages in response to user input—for example, the pressing of a key on a remote control.