havi doc edited
TRANSCRIPT
-
8/2/2019 Havi Doc Edited
1/17
HAVi
Dept of E.C.E. B.I.T.Institute of Technology 1
HAVi: Home Audio Video Interoperability
Abstract:
Eight major consumer electronics manufacturers have come up with anopen standard
enabling home entertainment devices to communicate intelligently with each other. The
HAVi (Home Audio Video Interoperability) standard promises to bring true platform
independent interoperability to consumer devices using high bandwidth IEEE 1394
(FireWire) as the connecting medium. This paper studies the HAVi standard and what it has
to offer to consumers.
1 INTRODUCTION
An average household nowadays contains many very complicated devices. Many of them are
home entertainment devices related to handling different audio or video data. These devices
are computers in essence, but just more specialized in their features than a home PC. Home
networking has become very popular nowadays since a normal household might contain
several PCs that need to use shared resources like printers or file shares. Home audio and
video devices like VCR, TV, amplifier, tuner, DVD, CD player and set-top-box form a
similar interconnected network (see Figure 1). Why couldnt these miniature computers also
make use of each others features and even control each other to make everything easier for
the consumer? Major consumer electronics, software, semiconductor and computer
manufacturers think that this should be possible and have decided to make it happen. The
manufactures, namely Grundig, Hitachi, Panasonic, Philips, Sharp, Sony, Thomson and
Toshiba along with now over 30 other participants, have formed a non-profit organizationcalled HAVi (Home Audio Video Interoperability) for promoting the development of
interoperable consumer products. The goal of HAVi organization is to provide a standard
open architecture for intelligent audio and video devices to interoperate with each other
regardless of manufacturer, operating system, CPU or programming language used for
implementation (HAVi, Inc., 2001a).
-
8/2/2019 Havi Doc Edited
2/17
HAVi
Dept of E.C.E. B.I.T.Institute of Technology 2
The first beta version of the HAVi standard version 1.0 was published in December 1998
while the final 1.0 version was released in December 1999. The current version of the
specification is 1.1 (HAVi, Inc., 2001b) and it was published in May 15th 2001.
This paper presents the basic architecture and promises the HAVi standard offers. Various
problems and questions still to be answered will also be discussed. Although HAVi is still to
come into living rooms as a de facto standard, a brief look at the future of HAVi will be
made.
The paper is mainly based on the information offered by HAVi organization (HAVi, Inc.,
2001a) and naturally the HAVi specification version 1.1 itself (HAVi, Inc., 2001b). Another
main source of the paper is a HAVi introduction by Rodger Lea, Simon Gibbs, Alec Dara-
Abrams and Edward Eytchison (Lea et al., 2000).
2 PROMISES OF HAVI
The idea of an open standard sounds very promising, but how can a normal consumer benefit
from it? How can it make lives easier and what kind of things, not possible before, can be
achieved by using it?
The simplest example might be time synchronization between different devices. TV set might
get the correct time from the broadcast stream and the other devices can query the TV and set
their own clocks according to it. Setting the VCR to record a program is a familiar
situationusers usually have problems with. With HAVi enabled devices this task can be made
very easy. User can select the program (s)he wishes to record with the Electronic Program
Guide (EPG) residing on a digital TV set (or set-top-box). The task can be as simple as just
browsing the program information, selecting the desired program and pressing one button to
activate recording. The TV then locates an available recorder (e.g., a VCR or a recording
DVD device) and commands it to record the program supplying it with the time, length and
channel parameters taken from the EPG. Thus, the user doesnt need to program or touch the
recording device in any way.
One of the more advanced scenarios might be automatic directing of an oncoming
videophone call to the TV screen or part of it and muting all other sounds. Similarly, if a
-
8/2/2019 Havi Doc Edited
3/17
HAVi
Dept of E.C.E. B.I.T.Institute of Technology 3
camera placed outside the door detects movement, the picture is automatically connected to
the TV screen notifying the user about a possible visitor. All this could also be aided by
giving voice commands to the devices. These are only some of the possible use cases. A lot
more can be possible, especially when the HAVi devices are connected to other home
appliances, PCs or even Internet.
The possibilities HAVi offers seem endless and many of them might sound like
science fiction or at least not likely in the near future, but that might not be the case. Many
products have already been announced and several working demos have been presented at
various consumer electronics fairs. The interoperability of HAVi devices seems pretty
extensive and complex. Will the installation and configuration of the network be as
complicated as in computer networks? Fortunately no, since devices are hot-pluggable and
they are supposed to automatically announce their presence and capabilities to other devices
and configure themselves when connected to the network saving the user from reading
installation instructions and configuring network addresses and drivers. Finally, HAVi
standard promises to be future proof by maintaining current functionality while making it
easy to upgrade and add new capabilities. Non-HAVi devices can also be connected to the
network if at least one of the HAVi devices supports the interface the legacy device provides.
3 HAVI ARCHITECTURE
The HAVi architecture can be divided into several different layers (see Figure 2). On the
bottom there is always vendor specific hardware and software Application Programming
Interface (API) that HAVi is built upon. Also, on the hardware level there is the connecting
IEEE 1394 wiring, which HAVi devices use as a connecting medium. Next, a media manager
for IEEE 1394 is needed as well as a messaging system. On top of the messaging system,
there are several software modules: Registry, Event Manager, Stream Manager, Resource
Manager, Device Control Modules (DCM) and DCM managers. These layers compose the
basic services for building portable distributed applications. Basic services provided by the
system, include:
Automatic discovery or devices added or removed from the network
Addressing scheme and message-transfer service
Lookup service for discovering resources
Posting and receiving local or remote events
-
8/2/2019 Havi Doc Edited
4/17
HAVi
Dept of E.C.E. B.I.T.Institute of Technology 4
Automatic installation and configuration of DCMs
Streaming and controlling isochronous data streams
Reserving devices and performing scheduled actions
Device control via DCMs and FCMs
User interaction with UI mechanisms
3.1 HAVi Devices
HAVi devices are classified into four categories (see Table 1): Full AV devices (FAV),
Intermediate AV devices (IAV), Base AV devices (BAV) and Legacy AV devices (LAV).
HAVi compliant devices fall into the first 3 categories and all other devices belong to the 4th
category. FAVs and IAVs are controlling devices in the HAVi network while BAVs andLAVs are the devices they control.
A Full AV device has the most complete set of HAVi features. FAV contains a runtime
environment for Java bytecode allowing it to upload bytecode from other devices. This
feature provides much enhanced capabilities for controlling devices. Common FAV devices
might be set-top-boxes, digital TV receivers, general-purpose home-control devices,
residential gateways or even PCs.
IAVs are generally a bit cheaper and do not contain the Java environment, thus having more
limited capabilities for controlling other devices. IAVs may provide native support for
controlling particular devices on the home network. Home theater amplifiers or DVD players
might fall into this category.
BAVs do not contain any of the HAVi software modules. However, their configuration Rom
must contain uploadable Java bytecode that makes it possible for FAV devices to control
them. They can also be controlled by a IAV device using native code. Most likely BAV
devices include portable audio players, camcorders and mass storage systems.
LAV devices do not recognize HAVi architecture. They use proprietary control protocols.
LAV devices can be divided into two categories, IEEE 1394 devices and those not supporting
it. They can be connected to the HAVi network, but they need a FAV or IAV device acting
as a gateway for them.
-
8/2/2019 Havi Doc Edited
5/17
HAVi
Dept of E.C.E. B.I.T.Institute of Technology 5
3.2 IEEE 1394
To meet the requirements for real-time transfer of high-data-rate streams, self-management
and autoconfiguration, low-cost cabling and interfaces, a natural choice was to adopt the
IEEE 1394 (FireWire) standard (IEEE, 1996) first conceived by Apple Computer. IEEE 1394meets all these requirements. Its high data rate of 400 Mbps (upgradeable to 800 Mbps or
even 1600 Mbps) is quite enough for several simultaneous data streams. Data can also be
fullduplex, i.e., both data and control instructions can flow to both directions at the same
time. Scalability of up to 63 devices in the same bus should be quite enough for normal
consumer electronics. FireWire can also connect almost any kind of computer peripherals
such as printers, scanners, keyboards, displays and hard drivers. However, so far it isnt very
popular in normal PC environment except connecting workstations with digital video
cameras for video editing. Naturally Apple products utilize it more commonly since it is a
built-in feature in their workstations.
On top of the IEEE 1394 layer, HAVi uses a simple Function Control Protocol (FCP) defined
in IEC 61883.1 (IEC, 1998,) for the transport of command requests and responses. IEC
61883.1 also specifies a Connection Management Protocol (CMP) for creating, breaking,
overlaying and restoring isochronous connections and for Common Isochronous Packet (CIP)
format.
3.3 Software Modules
HAVi software elements are self-contained entities that communicate with each other in
peerto- peer fashion. Each software element has a well-defined API through which the
services can be accessed. Elements also have a unique identifier assigned by the Messaging
System before they register to the Registry. Since this unique identifier is used to pass
messages between different modules, there is no distinction whether the modules reside
within the same device or different devices on the same network. In addition to assigningunique ID to the software elements, the messaging system fragments the messages into
multiple FCP packets and reassembles them. Software elements can request the messaging
system to supervise other elements and notify if they become unavailable. The HAVi
messaging system supports both acknowledged and unacknowledged messaging.
Registry acts as the directory service of the network. It enables objects to locate other objects
on the same network. In addition to the unique identifiers, the registry contains a small set of
software element attributes. Clients can then, e.g., query the attributes of a specified element
or locate an element matching a search predicate. Registry also forwards the queries to all
-
8/2/2019 Havi Doc Edited
6/17
-
8/2/2019 Havi Doc Edited
7/17
HAVi
Dept of E.C.E. B.I.T.Institute of Technology 7
suggest a preferred layout of the user interface, but the DDI controller might modify it
depending on the display capabilities. If more than one DDI controller is connected to the
target, all the views are synchronized by the target.
Level 2 UIs are constructed with Java and support more advanced features based on a subset
of Java AWT 1.1. HAVi also defines some extensions, such as support for different screen
sizes and aspect ratios, alpha blending and video/image layering, support for remote control
input and support for UI components patterned after Level 1 DDI elements.
3.5 Security
All devices can send messages and events to each other without any restrictions. To avoid
some of the problems that may arise, HAVi specifies what type of messages and events each
software element is allowed to send. Receiving system component will then check if the
sender is allowed to send this message or event. For example, some system components
might only accept messages from other system components. Protection from hostile or flawed
applications is left to the device manufacturer. HAVi protection scheme has only two levels,
trusted and untrusted. Vendors should thoroughly test all system and other software elements
before granting them trusted level. All dynamically installed software, like updates and
software patches, should be verified to make sure they are valid and come from verified
sources. This verification is done by digital signature algorithm specified in the HAVi
standard.
3.6 HAVi components in digital television
Regular television broadcasting services began in England and France in 1936 [1]. In
June 1999, the Finnish Ministry of Transportation granted licenses for three
terrestrial multiplexes to start operating digital television before 1st September 2001.
At the same time it was preliminarily decided that the complete transaction from
analogue to digital television would take place at the end of the year 2006 [2]. In
1936, the pictures in the system were composed of 405 lines and the viewer was only
able to sit in front of the television and watch what the stations decided to broadcast.
Today, this so-called dumb device is changing, the digital quality is coming,
interactive applications are arriving, and the number of new services available creates
a wide range of possibilities.
As mentioned above, a new period in the history of the television is beginning. A
revolution in this entertainment field is coming about. It has to be taken into account
-
8/2/2019 Havi Doc Edited
8/17
HAVi
Dept of E.C.E. B.I.T.Institute of Technology 8
that television has been a part of everybodys life for many years. So, habits,
practices and traditions have already been developed in the society. Consequently,
everyone involved in the process of providing this entertainment service, such as
station workers, developers, and manufactures, cannot forget that it is oriented to all
the population (i.e., people with different backgrounds). The main topic of this thesis
is to highlight the importance of having an adequate television-friendly Graphical
User Interface (GUI) when developing new applications for digital television.
This thesis has been written at the Telecommunications and Multimedia Laboratory
of the Helsinki University of Technology, in the Future TV research group under the
supervision of Professor Petri Vuorimaa. This thesis is divided into five chapters.
The first chapter consists of an overview of the digital television. The second chapter
talks about the different standards and organisations that are working on digital
television. The third chapter is focused on how to proceed, when developing digital
television applications. GUI aspect is emphasised. The fourth chapter is about the
practical part of the thesis, where a GUI framework is developed and used is real
applications. Finally, the last part of the thesis covers the conclusions and future
improvements.
3.7 STANDARDS AND ORGANISATIONS
The first intention of this chapter is to make clear who is who in digital television.
Nowadays, in every technological area, many acronyms are produced, which usually
originates a state of confusion and perplexity in the inexperienced. This chapter tries
to provide a clear picture about digital television acronyms.
Standards are documented agreements containing technical specifications or other
precise criteria to be used consistently as rules, guidelines, or definitions of
characteristic [36]. Consequently, standards have two different options. First, beingapproved by a recognised organisation (e.g., ETSI, ISO). Second, being accepted as a
de facto by the industry.
In the late 1940s, television standards engaged the emotional issue of national
sovereignty. The negotiators were under political pressure to resist all sorts of foreign
incursions into weakened economy of Europe and Soviet Union [1]. Nowadays, the
picture is completely different. With the European Union idea maturing, a common
European standard has been developed (i.e., DVB-MHP). Definitely, this is a good
thing if one takes a look at the actual incompatible analogue systems (i.e., Secam and
-
8/2/2019 Havi Doc Edited
9/17
HAVi
Dept of E.C.E. B.I.T.Institute of Technology 9
PAL) situation [7]. Also, there are other two standards in the world. Japanese, to be
used in their territory (i.e., ISDB) and ATSC Grand Alliance to be used in USA.
In addition, it is important to remark the importance of other organisations. They
have not developed standards for digital television, but anyway, their specifications
are necessary for digital television regulations. These are MPEG, HAVi, DAVIC, and
NorDig. MPEG is in charge of developing specifications for coded representation of
digital audio and video [37]. HAVi has stated specifications about the home network
[35]. DAVIC has created the standard for end-to-end interoperability of broadcast
and interactive digital audio-visual information, and of multimedia communication
[38]. Finally, NorDig is a co-operative organisation, which has specified a common
platform for digital television within the Nordic region (i.e., Denmark, Finland,
Norway, and Sweden) [39].
Finally, there are some other organisations related to the digital television. On one
hand there are the standards organisations (e.g., ETSI, CENELEC, and EBU). On the
other hand, two important groups called DigiTAG and DTG work to make easier the
shift from analogue to digital terrestrial television. DigiTAG aim is to organise and
facilitate the implementation and market driven introduction of digital terrestrial
television services in all transmission media [40]. DTG, based in UK, was created to
ensure that the new broadcast satisfies the standards and that new receivers work the
way they should in UK [41].
Taking into account what is said in the previous paragraphs, this second chapter is
divided into three parts. The first one, sub-section 3.1, discusses the standards
specified for digital television in the world. The second part, sub-section 3.2, is about
other important specifications related to the digital television. Finally, sub-section 3.3
talks about organisations, which, in some way, are related with the outgoing of digital
television.
3.8 Standards of Digital Television in the World
As said before, there are three different digital television standards in the world. In
this thesis, most attention is paid to the European standard (i.e., DVB-MHP) over the
rest, since it has been written in Europe. This section is structured as follows. First, in
sub-section 3.1.1, DVB-MHP is studied. Then, in sub-section 3.1.2, ATSC Grand
Alliance is introduced. After, in sub-section 3.1.3, ISDB is defined. Finally, in subsection
3.1.4, the current situation across the world is analysed.
-
8/2/2019 Havi Doc Edited
10/17
HAVi
Dept of E.C.E. B.I.T.Institute of Technology 10
When defining the different standards in this thesis, there is a structure followed.
First a little introduction about the organisation involved is given. Then the standard
is defined. The categorisation is done taking into account the bandwidth of the
channels to broadcast, the video resolution, the audio regulation, and the compression
system to be used. It is very important to remark that the last issue (i.e. the
compression system) is in all the standards MPEG-2.
3.8.1 DVB-MHP
DVB, formed in 1993, is a consortium of around 300 companies in the fields of
broadcasting, manufacturing, network operation and regulatory matters that have
come together to establish a common European standard for the move from analogue
to digital broadcasting [42].
From the beginning, DVB decided to be a politically independent group. This way,
no political decision could be taken to develop the standard. To assure it, the group
refused a grant offered by the European Community funding [7 and 43].
The principles guiding the DVB group behaviour are the following [42 and 44]:
1. System should be market-led rather than technology-driven. It is not
worthy to develop standards the market is not ready to accept, but use the
last technology hints.2. Interoperability. Ensuring the user all the systems in the market behaves
the same way. Multivendor interoperability is assured.
3. Open. The standard is agreed, approved, and published by a recognised
standardisation body. Then, they are available at a nominal cost,
worldwide.
The group has developed DVB-S, DVB-T, and DVB-C, the standards for satellite,
terrestrial and cable broadcast, respectively. The prime difference between them is
the delivery transmission system. DVB-S uses Quaternary Phase Shift Keying
Modulation (QPSK). DVB-C uses Quadrature Amplitude Modulation (QAM).
Finally, DVB-T, the most complex delivery system, uses Coded Orthogonal
Frequency Division Multiplexing (COFDM). The major difference between for the
terrestrial system is the use of a multicarrier modulation system [44].
In Europe, the TV channel is decided to be 8MHz. As COFDM states, the channel is
divided into several thousand of narrow sub-channels. The digital code is split into
many streams, with one stream sent on each sub-channel [8]. Consequently, the datacarriers in the COFDM can use QPSK or different levels of QAM modulation. This
-
8/2/2019 Havi Doc Edited
11/17
HAVi
Dept of E.C.E. B.I.T.Institute of Technology 11
method stands up to multipath interference and unwanted reflections can be
recognised and rejected.
In the early 1990s, there was a system, in Europe, called HD-MAC, which failed. It
was a project trying to co-ordinate the launch of a hybrid analogue-digital High
Definition Television (HDTV). Learning from it, DVB has chosen the standardresolution
television of 625 lines, 50 Hz interlaced pictures. HDTV is stated as
optional until it becomes a market necessity [7]. In addition, the wide screen aspect
ratio stated is 16:9.
The audio standard selected is MPEG-2 sound (i.e., six channels). Initially stereo
sound (i.e., two channels) can be used instead, because of the lack of multichannel
MPEG decoder. Stereo, anyway, can be upgraded to multichannel surround (i.e.,
another channel of rear information is mixed with the stereo pair) [7].
DVB has stated, also, the following [44]:
Service Information System (DVB-SI): to provide a comprehensive
identification system for the transmission parameters and service content.
Conditional Access Common Interface (DVB-CI): to control the access to
some programs to unauthorised viewers.
Teletext transmission transport system (DVB-Text): to carry fixed-format
teletext system in the MPEG-2 transport stream.
MHP is a subproject of DVB starting in 1997. While DVB activities are more related
to physical and transport layer, MHP concerns with the upper system layer [15]. The
scope of DVB-MHP is to define a common API, which provides a platform
independent interface between applications from different providers and the
manufacturer specific hardware and software implementation, which is called
middleware [45].
DVB-MHP has defined three different profiles, which state functional requirements
for supporting a wide range of application types. The profiles are enhanced
broadcasting, interactive broadcasting, and Internet access. The first two are already
developed and MHP is working on the third one.
The major components of the MHP are the following :
DVB-J platform: comprises a Java Virtual Machine and a set of specific
television oriented APIs.
Content Formats: including PNG, JPEG, MPEG, subtitles, and resident
downloadable fonts.
HTML: allowing the execution of HTML decoder written in Java, where
-
8/2/2019 Havi Doc Edited
12/17
HAVi
Dept of E.C.E. B.I.T.Institute of Technology 12
there isnt an HTML decoder resident in the MHP receiver.
Network Protocols: mandatory transport protocols, which are DSM-CC
object carrousel (broadcast) and IP (return channel).
Also, from the applications point of view, a security framework and the application
model and lifecycle is defined. The security model covers both the broadcasting and
data authentication (e.g., digital signature), and the return channel encryption (using
TLS). In DVB-MHP, a DVB-Java application is called Xlet application. The lifecycleof an
Xlet is similar to that used by Java applets in Internet, with four different states
(i.e., ready, running, paused, and dead) [45 and 46].
Finally, it is necessary to explain, what the APIs DVB-MHP defines. The APIs, as
said above, are used by an application to access the platform, where they are running
[47]. The APIs of DVB-MHP can be categorised into [45 and 47]:
Core Java: a subset of packages from JDK1.1.
JavaTV: Some packages selected from JavaTV API developed by Sun
Microsystems.
HAVi: The User Interface API from HAVi specifications.
DAVIC: Mostly addressed to MPEG transport and related subjects
(e.g., tuning, conditional access). Also, a number of extensions of the
JMF (Java Media Framework).
DVB: including packages to address the broadcast transport files, user
settings and preferences, DVB service information, and DVB related
extensions to the JMF.
3.8.2 The HAVi Standard
The HAVi standard specifies a set of distributed management services and
their interfaces as required in the home entertainment environment, for examplefor the management of video and audio streams. Furthermore, a controlled
device in the HAVi environment may provide its own device driver (called a
Device Control Module, DCM), which can be executed on a controlling device,
and its own user interface (in a so-called Havlet). This concept makes a HAVi
network extensible, because it allows to add previously not supported controlled
devices.
An important aspect of the HAVi architecture is the distinction between different
types of devices, which allows to have complex controlling devices (e.g.
-
8/2/2019 Havi Doc Edited
13/17
HAVi
Dept of E.C.E. B.I.T.Institute of Technology 13
set top boxes) as well as more simple and therefore cheaper controlled devices
(e.g. a CD player). Additionally, this concept allows to integrate legacy devices
that are not aware of HAVi. Both is important for the automotive environment,
as the former allows to include more of the numerous often simple Electronic
Control Units (ECUs) in the HAVi network and the latter because it allows a
reuse of existing devices, reducing the transition costs.
The HAVi architecture defines the following device categories:
" Full Audio/Video device (FAV): FAVs are controlling devices that run all
HAVi managers (see below) and are able to execute the DCMs for controlled
HAVi devices (BAVs and LAVs). To run an uploadable DCM provided
by a BAV, an FAV has to contain a runtime environment for Java
byte code. Applications using the HAVi framework will be executed on
an FAV or IAV. The head unit of a vehicle telematics system would be an
FAV.
" Intermediate Audio/Video device (IAV): An IAV is similar to an FAV but
has a reduced set of managers and no runtime environment for Java
byte code. This allows for cheaper controlling devices with less
resources. In the automotive domain, a rear-seat unit could be realized
as an IAV.
" Base Audio/Video device (BAV): BAVs are controlled devices that provide
HAVi-specific information and a DCM code unit as uploadable Java byte
code in its ROM. An FAV can download this code unit and run the DCM
for a BAV.
" Legacy Audio/Video device (LAV): Existing controlled devices that are
not aware of HAVi can be included in a HAVi network as LAVs. An FAV
or IAV can provide an embedded code unit and run a DCM for such a
device (e.g. a device supporting the IEEE 1394-based Audio/Video
Control protocol, AV/C). Existing controlled MOST devices, such as a CD
changer or a radio tuner, will have to be treated as LAVs.
4 PROBLEMS WITH HAVI
HAVi as a technology hasnt been widely tested and utilized in real environments. Naturally,
until it is proven that everything works as it is supposed to, there are several problems to be
foreseen.
One of the most important goals is platform-independent interoperability. However, it has
-
8/2/2019 Havi Doc Edited
14/17
HAVi
Dept of E.C.E. B.I.T.Institute of Technology 14
been seen that FireWire still isnt as solid as you would think considering that it has been on
the market for several years. In fact, FireWire alone has proven to be very complicated to
implement. The only guarantee is that devices of the same brand and same and same kind of
proprietary programming will most likely work together. Until all the major problems with
FireWire have been solved, they will hinder HAVi.
Also, distributing audio and video data is still quite difficult since theres no one format that
all devices understand. For example the data formats of a VCR, minidisc, CD player and
MP3 player are quite different. One important issue when dealing with home entertainment is
digital rights management. Without any copyright info data might be transferred freely
between devices or even outside the home network. While it is legal to copy material for your
self, the situation becomes more complicated when the HAVi network is connected to, for
example, the Internet. Big entertainment corporations will not like the fact that their material
could be freely distributed. This raises the question about how the devices are protected from
intrusions from outside. HAVi specification leaves this issue mostly to the device
manufacturers. It certainly wouldnt be nice if someone could disable your home network
from outside, thus rendering video cameras, set to watch your apartment, useless.
In another scenario, an intruder might get access to your personal home videos. These
scenarios might seem far-fetched, but more common situations might cause problems too.
The network must withstand an attack from within too. Faulty device might act in a wrong
way sending invalid messages or monopolizing the network with traffic. Also, since devices
can obtain bytecode from another devices or even Internet, it should be made sure that faulty
program code wont cause too much problems. Again, it can be visualized that one device
gets an update containing a virus which it then uploads to every other device.
Due to the growing complexity of the devices and various standards, the initial models will
most likely be priced quite highly for some time. A set-top-box implementing both HAVi and
Multimedia Home Platform (MHP) will probably start with the price of a full-featured
multimedia PC, which is too much for the majority of consumers. As long as these high-
priced devices suffer from incompatibilities, they arent too tempting. Users will not like to
have their expensive digital TV displaying error messages or crash once in a while. The high
complexity of the protocols makes the verification of products very difficult and even the
-
8/2/2019 Havi Doc Edited
15/17
HAVi
Dept of E.C.E. B.I.T.Institute of Technology 15
smallest mistakes in mass production of consumer electronics can cost quite a lot, both
financially and in credibility.
Engineers have nice visions about how devices can be connected with each other and the
Internet, but the reason to do this just shouldnt be because we can. Sure, a lot of things not
possible before can be realized with HAVi. HAVi promises easiness of use, which is
welcomed since even setting the VCR to record can be a very formidable task sometimes.
However, so far the discussion and development has been quite technology driven and issues,
such as usability and what consumers actually want, havent been discussed enough.
Hopefully this situation will change when the technology is ready and devices become more
common. Finally, Microsoft also has its position in the development of home networks and
has introduced a competing standard, Universal Plug and Play (UPnP). UPnP is more tilted
towards linking PCs with all kinds of home appliances together. HAVi and UPnP complete
each other in many ways, but clashes between the two efforts might make situation a bit more
complicated and slow down the development of devices.
5 THE FUTURE OF HAVI
HAVi technology was first demonstrated at Winter CES (Jan 2001) in Las Vegas. After that,
many of the participating companies have announced HAVi enabled products during the last
year. However, most of the products are not publicly available yet. Naturally, the first HAVi
compatible devices are targeted towards high-end markets, i.e., to professionals and home
theater enthusiasts. It is most likely that the situation wont change much with next 2-3 years
at least, not until HAVi technology is more mature and cheaper to implement.
To battle the high cost of the products and time to develop them, T. Nakajima (Nakajima et
al., 2001) presents a cost effective way of developing HAVi appliances. This solution uses
system and applications to the product is easy since the development platform and the final
product can both use Java and Linux. Linux was a natural choice, because it has recentlygained popularity in embedded systems. Since virtually no modifications are needed, the
development time and cost should be greatly reduced. However, Linux still has some
problems to be solved, such as real-time resource management and making the memory
footprint small enough.
Another development area is connecting HAVi to other networks, namely the Internet. This
allows appliances to be remotely commanded with any device with a browser connected to
the Internet. For example, it could be possible to use a PDA to remotely program the VCR.
R.G. Wendorf and M.P. Boedlander (2000) have demonstrated this in their paper. In this
-
8/2/2019 Havi Doc Edited
16/17
HAVi
Dept of E.C.E. B.I.T.Institute of Technology 16
solution, a Messaging System Proxy encodes HAVi messages into Extensible Markup
Language (XML) and SOAP. The encoded messages are then sent to Internet using
Hypertext Transfer Protocol (HTTP). Vice versa, incoming messages are stripped from XML
and SOAP and put on the HAVi network. All this functionality can be achieved without
modifying the HAVi specification itself or adding features to Internet connected devices.
6 CONCLUSIONS
HAVi comes with great promises, promises that seem to be quite troublesome to fulfill.
However, with so many large companies working for a common goal, there is a good chance
that HAVi will eventually prove to be what it promised. In the end, it is up to customers if
they want to adopt the new technology. When new features and possibilities are as great as
with HAVi, theres no question about the fact that HAVi will be something that customers
want, provided that it comes with a reasonable price tag and solid functionality.
-
8/2/2019 Havi Doc Edited
17/17
HAVi
Dept of E.C.E. B.I.T.Institute of Technology 17
7 REFERENCES
Bodlaender, M.P.; Wendorf, R.G., 2000, Adding full internet protocol functionality to HAVi,
Proceedings of the ICCE International Conference on Consumer Electronics 2001, pp.
300-301
IEEE, IEEE standard 1394, 1996, Standard for a High Performance Serial Bus,
Piscataway, N.J., IEEE Press, parts 1 - 5
IEC, IEC standard 61883, 1998, Consumer Audio/Video EquipmentDigital Interface,
Geneva, Switzerland , Intl Electrotechnical Commission,
HAVi, Inc., 2001a, The HAVi Homepage [online] [referenced
Nov-22, 2001]
HAVi, Inc., 2001b, The HAVi Specification Version 1.1, 529 p. Also available at
Lea, R.; Gibss, S.; Dara-Abrams, A.; Eytchison, E., 2000, Networking Home Entertainment
Devices with HAVi, Computer, Vol. 33 Issue 7, pp 171-178
Nakajima, T.; Soejima, K.; Matsuda, M.; Iino, T.; Hayashi, T, 2001, Design and
implementation of distributed object-oriented infrastructures for networked home appliances
on commodity operating systems, Proceedings of the Fourth International Symposium on
Object-Oriented Real-Time Distributed Computing 2001, pp. 171-178 Wendorf, R.G.;
Bodlaender, M.P., 2000, Remote execution of HAVi applications on
internet-based devices, Proceedings of the ICCE International Conference on Consumer
Electronics 2001, pp. 232-233.