Benefits of HAVi - EHOME: 電子家庭雛型之設計與實作(3/3]─子計畫二:嵌入式 JAVA 及 JINI 系統之設計與實作

Chapter 1 Introduction

1.4 HAVi

1.4.2 Benefits of HAVi

A HAVi compliant appliance can offer some advantages [13].

Brand independence: Devices from different manufactures can communicate with each other in a HAVi network. For example, a Panasonic VCR can work with a Sony amplifier and be controlled by a Mitsubishi TV as long as all these devices are HAVi compliant.

Interoperability: Functions on a device within a HAVi network can be controlled from another device within the network. For example, search for an available VCR to record a TV program, with commands being given via the menu selection of another TV display.

Legacy appliances support: HAVi supports legacy appliances, including non-IEEE1394 devices and non-HAVi devices. This plays an important role since the transition to networked devices is gradual and there could be multiple standards in a home network.

Plug and Play: A HAVi-compliant appliance can configure itself and integrate itself into a HAVi network without user intervention. This can greatly simplify installation and setup.

Upgradeable: HAVi devices may have only basic function, and new functionality can be automatically downloaded via the Internet. For instance, a HAVi Panasonic VCR can install the necessary application on a Sony TV in order to make two appliances interoperable.

Services in the HAVi are modeled as objects called software elements, accessible through their APIs (application programming interface). A software element is a basic unit in HAVi software framework. The design and implementation of software elements greatly affect the performance of home networking. Although the HAVi specification is available, there is little explanation about software element design.

The purpose of this project is to examine all issues that developers may encounter and to provide their solutions. The report may serve as a guide for consumer electronics manufacturers and application developers to design and implement software elements in HAVi.

1.5 Structure of Report

The report is divided into five chapters. Chapter One gives an introduction about home networking. The second chapter describes background about HAVi, and the third chapter describes the software element architecture. The fourth chapter explains our implementation. Chapter Five concludes the report.

Chapter 2 Home Audio/Video Interoperability

The HAVi Architecture specifies a set of Application Programming Interfaces (APIs) allowing consumer electronics manufacturers and third parties to develop applications for the home network. The primary goal of the HAVi Architecture is to assure that products from different vendors can interoperate, that is, can cooperate to perform application tasks.

Figure 2-1: An example of a HAVi home network

Kitchen

Internet IEEE 1394

Fridge TV DVD DVCR

STB camcorder

printer 1394

1394 1394

Broadband

Living Room

Typically, there will be several clusters of devices in the home, with one per floor or one per room. A HAVi home network is viewed as a distributed computing platform, and devices communicate in a peer-to-peer fashion, with no single master control device. An example of a HAVi home network is shown below:

2.1 Device Classification

HAVi classifies consumer electronics (CE) devices into four categories: Full AV devices (FAV), Intermediate AV devices (IAV), Base AV devices (BAV), and Legacy AV devices (LAV). HAVi-compliant devices are those in the first three categories.

LAV is either a non-IEEE1394 device, or an IEEE 1394 device not supporting HAVi.

Usually FAV and IAV are controllers; BAV and LAV are controlled devices. A controller is a device that acts as a host for a controlled device. A controller is said to host a driver--Device Control Module (DCM) in terms of HAVi--for the controlled device. The control interface is exposed via the API of this DCM. This API is the only access point for applications to control the device. For instance, an intelligent television in the living room might be the controller for a VCR. An application in the TV could control the VCR via its DCM in the TV.

2.1.1 Full AV Devices

A Full AV device contains a complete set of HAVi software elements (see Figure 2-2).

This device class generally has greater computing power and more resources; thus, it can support a complex software environment. The primary distinguishing feature of an FAV is the presence of a runtime environment for Java bytecode. This allows an FAV to upload bytecode from other devices and so provide enhanced capabilities for their control. Likely FAV devices would be Set Top Boxes, televisions, residential gateways, and home PCs.

2.1.2 Intermediate AV Devices

An Intermediate AV device is generally lower in cost and has fewer resources than a FAV device. The main difference from FAVs is that IAVs have no Java runtime environment, so IAVs cannot control arbitrary devices within the home network.

Television PC

DVD

Nevertheless, an IAV still can control particular devices if it has native-code DCMs for them. Possible IAV devices are DVD players and VCRs.

2.1.3 Base AV Devices

BAV devices support IEEE 1394 but they cannot act as controllers in a HAVi home network. They can be controlled by an FAV or IAV device by providing uploadable Java bytecode (DCM) in their ROM. They do not host any software element of the HAVi Architecture. A FAV or IAV device and a BAV device communicate by the IEEE 1394 command protocol used by the BAV device. Likely BAV devices are audio players and camcorders.

Here is a possible scenario. A DVD player (BAV) contains Java bytecode that constructs a user interface for the device and allows external control of the device.

When the DVD player connects to a television (FAV), the TV obtains the user interface and control code from the DVD player. An icon representing the device may then appear on the TV screen, and the device could be controlled via the TV.

2.1.4 Legacy AV Devices

LAV devices do not aware of the HAVi Architecture. The difference from BAVs is that LAVs may not support IEEE 1394 and do not provide uploadable control code.

Hence, LAVs can work in a HAVi network only if an FAV or IAV recognize them and use proprietary protocols for their control. An FAV or IAV device and a LAV communicate by the legacy command protocol used by the LAV.

For example, a Sony VCD player, which does not support HAVi, connects with a Sony TV (FAV). If the TV recognizes the VCD player and has the DCM for it, users can control the VCD player via TV.

2.2 Software Element

As its name implies, a software element is the most basic unit in HAVi software architecture. In terms of object-oriented concept, a software element is a HAVi object.

camcorder

Software elements provide services, which are accessible through the API. The diagram below is a possible arrangement of software elements on an FAV device.

Figure 2-2: HAVi architecture diagram (FAV)

Here is the list of software elements in the HAVi Architecture and the services they provide.

1394 Communication Media Manager (CMM) – allows other software elements to perform asynchronous and isochronous communication over IEEE 1394.

Messaging System – responsible for passing messages between software elements.

Registry – serves as a directory service, allows any software element to locate another software element in the home network

Event Manager – serves as an event delivery service. An event is the change in state of a software element or of the home network.

Stream Manager – responsible for managing real-time transfer of AV and other media.

CMM 1394

HAVi Java API

Application Application

Messaging System

DCM

Vendor Specific Platform

Havlet Havlet Havlet

Platform Specific API

DCM DCM

Re gistr y Event Mgr S tream Mgr Resource Mgr DCM Mgr

Resource Manager – facilitates sharing of resources and scheduling of actions.

Device Control Module (DCM) – a software element used to control a device.

DCM Manager – responsible for installing and removing DCMs on FAV and IAV devices.

Havlet – a HAVi Java application, offers interaction with uses via user interface

“System software element” or “system component” is defined as a software element providing basic system services. System software elements include CMM, Messaging System, Event Manager, Registry, DCM Manager, Stream Manager, and Resource Manager. Non-system software elements include Application, Havlet, and DCM.

The following table summarizes required and optional software elements for the four device classes.

Table 2-1: Software elements presented on various device classes

D [D] D D

D: required [D]: optional

2.2.1 Software Element Identifier

Each software element has a software element identifier (SEID), which is an 80-bit value for identification and guaranteed to be unique. SEID are allocated by Messaging System when a software element initiates. The Messaging System of a device allocates SEIDs only for the software elements of that device. Software elements use SEIDs to be registered on the home network, and to communicate (via HAVi messages) with each other. For example, a software element wants to send HAVi messages to another software element. The SEID of the destination SE has to be specified when invoking the Messaging System API.

2.3 Messaging System

2.3.1 Description

HAVi network is message-based. All software elements communicate using messages via Messaging System, which is independent of the network and transport layers. This message passing mechanism abstracts from the details of physical location, that is, there is no distinction between a software element on the same device and one on a remote device. A Messaging System has mainly two jobs: forwards the messages from local software elements to other MS and dispatches the incoming messages from other MS to local software elements. A Messaging System is embedded in all FAV and IAV devices, but not in BAV or LAV devices. Thus, FAV (or IAV) devices communicate by HAVi messages via their Messaging System; FAV or IAV devices control BAV or LAV devices by proprietary protocols (not HAVi messages).

Figure 2-3: Communication among HAVi devices

IEEE 1394

To receive messages, a software element has to indicate callback function to the Messaging System. After Messaging System gets incoming messages, it will notify the destination software element via its callback function. The request will be handled in the callback function and corresponding actions will be executed. Callback function also called listener.

Here we define “callback thread”. When a Messaging System receives a message, the callback functions of the software element will be invoked. The thread that executes the callback function of the software element is called “callback thread”.

2.3.2 Message Transfer Modes

Messaging System provides two modes to send a message: simple and reliable mode.

In this report, only reliable mode is discussed. In reliable mode, messages are sent synchronously or asynchronously.

The asynchronous mode is described through the following example. Suppose that there are two devices. Software element A and Messaging System 1 are on the same device, and software element B and MS 2 are on the other device. When A sends a message to B, the MS 1 sends the message to the MS 2. The MS 2 then tries to invoke the callback function of B. If the callback function successfully returns without errors, MS 2 sends an acknowledgment to MS 1. When MS 1 receives the acknowledgement, the Messaging System API invoked by A will return. The acknowledgement timeout is 30 seconds. That is, a caller software element always blocks until either the acknowledgement returns or a 30 seconds timeout occurs.

Figure 2-4: An example of asynchronous message transfer

Software Messaging Messaging Software

Element A System 1 System 2 Element B

msgSendRequest(B) Invocation

msg_reliable(B)

Callback(req) Invocation

Callback(req) Return msg_reliable_ack(A)

msgSendRequest(B) Return: OK

Software Messaging Messaging Software

Element A System 1 System 2 Element B

msgSendRequest(B) Invocation

msg_reliable(B)

Callback(req) Invocation

Callback(req) Return reliable ack lost

msgSendRequest(B) Return: timeout

Software Messaging Messaging Software

Element A System 1 System 2 Element B

msgSendRequestSync(B) Invocation

msg_reliable(B)

Callback(req) Invocation

Callback(req) Return msg_reliable_ack(A)

msgSendResponse(A, simple) Invocation msg_simple(A)

msgSendRequestSync(B) Return: ok

Figure 2-5: Messaging failing due to time expiration

Note that when a callback function successfully returns, it indicates the destination software element starts to process the request rather than finishes. When the response returns, all callback function installed by the caller will be invoked. Then, the caller uses the transactionId, an identifier is given while sending the message, to match the corresponding incoming responses in the callback function.

In synchronous mode, a caller blocks until the response is received (not the acknowledgment). A timeout parameter of the API indicates the maximum time that the caller will be blocked. As shown in the following figure, when the caller receives the acknowledgement, the caller keeps waiting until the response returns or a timeout occurs. Note that the timeout here is the parameter given in the API rather than the 30-second acknowledgement timeout in asynchronous mode.

Figure 2-6: An example of synchronous message transfer

2.4 Registry

Registry serves as a software element directory, providing services for software elements to search other software elements in the network. Software elements that want to be contacted have to register with Registry. Registry maintains the SEID and the attributes for each registered software element.

Table 2-2: Services provided by Registry

API Description RegisterElement Add a software element in the Registry

UnregisterElement Remove a software element in the Registry RetrieveAttributes Read the attributes of the given software element GetElement Get software elements that satisfy the query parameter MultipleGetElement Get software elements that satisfy the query parameter

2.5 Java and HAVi

HAVi specifies a Java programming environment for applications and DCMs. The use of Java assures that applications and DCMs will run on any FAV device, the only device class that offers runtime environment for Java bytecode. This is an important feature because it allows third parties can also develop HAVi applications. Besides, it assures HAVi is compatible with future home appliances because applications and DCMs are upgradeable.

It is also possible to write HAVi applications in other languages, such as C or C++.

They are native applications, which execute on a device-specific platform and therefore execute only on a particular HAVi device. Native applications can only be written and supplied by the vendor of the HAVi device or by someone who has specific knowledge of its platform. But anyone can write HAVi Java applications for FAVs, not just the manufacturer of FAVs.

A portable HAVi application can run on any FAV device from any manufacture, but it must be written in Java and confine itself to HAVi Java APIs, the set of Java class packages specified by HAVi.

2.5.1 The HAVi Java APIs

Software elements offer their services to other software elements via APIs. HAVi specifies APIs in IDL (Interface Definition Language) [14]. IDL is programming-language independent; it indicates the input and output parameters of interfaces, but not their implementation. HAVi provides a Java binding of IDL form APIs. Example 2-1 shows the IDL form of the

^GetElement

service of a Registry software element and the Java representation is shown in Example 2-2.

Example 2-1: IDL form of an API

Status Registry::GetElement(in SimpleQuery query,

out sequence<SEID> seidList)

Example 2-2: Java binding for the API

package org.havi.system;

public class RegistryClient extends HaviClient {

void getElement(IntHolder transactionId, SimpleQuery query);

void getElementSync(int timeout, SimpleQuery query, SEIDSeqHolder seidList);

}

In the IDL form, the service has a

SimpleQuery

input parameter and a SEID array output parameter. In the Java representation,

RegistryClient

is a Java class whose methods correspond to the services of Registry software elements. Note that each service is mapped to two Java methods: asynchronous version and synchronous version. Asynchronous one has the same name, and the synchronous one has the name suffixed with

^“Sync”

. Synchronous service methods have a timeout parameter. An exception will be thrown if the Messaging System does not receive a response before the specified timeout.

The set of packages defined by HAVi for developing in Java is called the HAVi Java APIs [15]. A portable HAVi application can only use the packages appearing in the HAVi Java APIs.

The HAVi Java APIs consists of the following packages:

org.havi.constants

In addition, the following packages can be used in a portable HAVi application:

objects to send HAVi messages to other software elements and use service of system components. In concept, a HAVi application is a software element; In Java implementation, a HAVi application owns a

SoftwareElement

object. A HAVi Java application example is shown in Example 2-5.

As for system software elements, their design is implementation dependent. They may implement in Java and use the

SoftwareElement

class the way as an application

does, or they may implement in any way as long as they provide the services conforming to the HAVi specification.

The following is the definition for the

SoftwareElement

class.

Example 2-3: The SoftwareElement class

public class SoftwareElement {

public SoftwareElement(HaviListener hl);

public SoftwareElement();

public final void close();

public final boolean msgIsTrusted(SEID seid);

public final SEID msgGetSystemSeid(SEID seid, int softwareElementType);

public final void msgWatchOn(SEID destSeid);

public final void msgWatchOff(SEID destSeid);

public final void msgSendSimple(byte protocol, SEID[] destSeidList,

HaviByteArrayOutputStream buffer);

public final void msgSendReliable(byte protocol,

SEID destSeid,

HaviByteArrayOutputStream buffer);

public final void msgSendRequest(SEID destSeid,

OperationCode opCode,

HaviByteArrayOutputStream buffer,

IntHolder transactionId);

public final void msgSendResponse(SEID destSeid,

OperationCode opCode,

int transferMode,

Status returnCode,

HaviByteArrayOutputStream buffer,

int transactionId);

public final void msgSendRequestSync(SEID destSeid,

OperationCode opCode,

int timeout,

HaviByteArrayOutputStream bufferIn,

HaviByteArrayInputStream bufferOut,

StatusHolder returnCode);

19 public final SEID getSeid();

public final void addHaviListener(HaviListener hl);

as:

20 public abstract class HaviListner {

public abstract boolean receiveMsg(

Boolean haveReplied, byte protocolType, SEID sourceId, SEID destId, Status state,

HaviByteArrayInputStream payload);

}

receiveMsg()

returns true only if it receives an request that it can handle. The

haveReplied

parameter shows whether any other listener has replied to the incoming message. The

protocolType

parameter indicates whether the message uses the HAVi RMI (Remote Method Invocation) protocol or some private (application-specific) protocol. The state parameter shows error condition.

^sourceId

indicates the SEID of the sender and

^destId

indicates the SEID of the receiver.

payload

is the message payload from which request parameters can be retrieved.

2.5.4 The HaviClient Class

The

^HaviClient

class is extended by all classes that allow an application to access the services of system components. For instance,

RegistryClient

extends

HaviClient

and provides access to Registry services (see Example 2-4). The first parameter in the constructor

RegistryClient()

is a

SoftwareElement

object that will be a client of Registry services; this is typically a software element created by an application. The second parameter identifies the GUID of the device.

In most cases, software elements use the system components in the same device rather than remote ones. ‘

RegistryLocalClient

’, the local client class of the Registry, provides the service of the local Registry running on the same device with the client

Example 2-4: The HaviClient class and the RegistryClient class

public abstract class HaviClient {

HaviClient(SoftwareElement se, SEID destSeid);

}

public class RegistryClient extends HaviClient {

RegistryClient(SoftwareElement se, GUID destGUID);

// other Registry APIs

void getElement(IntHolder transactionId, SimpleQuery query);

...

}

public class RegistryLocalClient extends RegistryClient { RegistryLocalClient(SoftwareElement se);

}

2.5.5 An Example

In Example 2-5, a software element will be created to represent this application, which offers a “Hello World” Service.

In line 16, a software element is initiated in the constructor and ”

this

”, a HaviListener, is passed as a parameter. In lines 31,

receiveMsg()

handles incoming messages to the software element. The HAVi message payload contains three fields:

In line 16, a software element is initiated in the constructor and ”

this

”, a HaviListener, is passed as a parameter. In lines 31,

receiveMsg()

handles incoming messages to the software element. The HAVi message payload contains three fields:

在文檔中 EHOME: 電子家庭雛型之設計與實作(3/3]─子計畫二:嵌入式 JAVA 及 JINI 系統之設計與實作 (頁 14-0)