HAVi

Common issues for distributed systems

• Types of devices
• "legacy" versus "aware" devices
• Transport mechanisms
• Identity of devices and components
• Advertisement of services
• Service discovery
• Service invocation
• Failure
• User interfaces

HAVi

HAVi (Home Audio Visual Interoperability Architecture) is concerned with the following home devices

• tuner
• VCR
• clock
• camera
• AV disk
• display
• amplifier
• modem
• web proxy

Firewire

• IEEE 1394 standard arising from Apple Computers, also known as i.LINK
• Data transfer rates to 400Mbps, with 3200Mbps planned
• Connect upto 63 devices without needing hubs
• An isochronous protocol - it provides guaranteed delivery of data packets at regular time intervals. i.e. a real-time transport, unlike best-effort ethernet. It gives QOS by bandwidth-reservation
• Plug and play: when a device joins or leaves a network, it causes a bus reset which generates events and reassigns firewire addresses
• Firewire addresses share a 64-bit address space: 10-bit bus number, 6-bit node number (64-1 nodes per subnet), 48-bit node memory address
• Nodes are daisy-chained together, with upto 4.5 metres between nodes;
• Nodes may have multiple ports, allowing tree topologies on each subnet
• Bridges may connect subnets

HAVi devices

• HAVi is strongly tied to a particular transport mechanism, firewire (IEEE 1394)
• HAVi devices are classified by
  • non-firewire devices (legacy devices)
  • firewire devices that do not understand the HAVi protocols (legacy devices)
  • firewire devices that support HAVi
• HAVi devices are further divided into
  • Full AV devices (FAV)
  • Intermediate AV devices (IAV)
  • Base AV devices (BAV)

Full AV devices (FAV)

• These can run all elements of the HAVi architecture
• This includes a Java runtime engine, and the ability to run Java code uploaded from other devices
• They can act as controllers for other HAVi devices
• They can e.g. upload a Java UI from a device and use that to allow a user to control the device
• e.g set-top boxes, TVs, PCs

Intermediate AV devices (IAV)

• Cannot run Java bytecodes, so cannot act as a general purpose controller
• May be able to run particular native code programs, so may be able to act as special-purpose controllers for some devices

Base AV device (BAV)

• These can store Java bytecode and upload it to a FAV
• They can be controlled by code running on the FAV
• The protocol between this code and the device is not specified, and could be anything (sockets, serial ports, etc)

HAVi control

Components of HAVi devices

• HAVi devices may be made up of parts
• These parts are not made explicit e.g. this is not how the parts are specified

  
        class TV {
            Tuner tuner;
            Display display;
        }
        

• Instead, the DCM code unit (a boot loader) installs each component, something like

  
        class TV_code_unit {
            TV tv;           // device controller
            Tuner tuner;     // functional unit
            Display display; // functional unit
        
            install() {
                install(tv);
                install(tuner);
                install(display)
            }
        }
        

HAVi transport mechanisms

• HAVi requires firewire transport mechanism
• This is because
  • firewire is high-speed, and can carry AV data
  • firewire is hot-swappable, and devices reset the firewire bus when they join or leave, so that join/leave events can be generated
  • firewire will support a large number of devices per bus
• HAVi builds a messaging layer above this, so all HAVi clients and services communicate by message passing

Device and Function control modules

• HAVi devices are represented by device control module (DCM) objects
• Each device may have several functional elements
• Each functional element is represented by a functional control element (FCM) object

HAVi device and component indentifiers

• Firewire identifies all devices on the bus
• After a firewire bus reset, all identifiers may change
• HAVi uses a GUID (globally unique identifier) to identify devices independent of these bus resets
• Components within a device also have a swHandle
• A software element identifier SEID is made up of the GUID and the swHandle
• The SEID is used to register, find and manipulate devices

HAVi registry

• HAVi maintains a registry which lists all device control modules (DCMs) and Functional Component Modules (FCMs)
• The registry is home-network wide
• Each registry entry contains the SEID (Software entity Id) and a set of attributes
• Each attribute is of the form

  
        Attribute {
            Class    // 1 bit private or system
            Name     // 31 bit integer id
            Size     // size in bytes of value
            Value
        }
        

• System defined attribute values include:
  • VendorId
  • DeviceManufacturer
  • DeviceModel
  • UserPreferredName
  • TargetID (which device this s/w controls)
• The registry service is globally (network-wide) accessible to each FAV and IAV

HAVi object booting

• When a HAVi device starts up, it locates an FAV or IAV
• It uploads a DCM (device controller module) code unit which acts to boot the device into the HAVi network network
• The FAV/IAV runs the DCM code unit, which installs
  • the Device Control Module (DCM) for the device
  • Functional Component Modules (FCM) for each component of the device

HAVi service advertisement

• Devices are not registered - their s/w representatives are
• Each DCM and FCM is registered with the Registry
• This is done as part of the boot sequence
• It is also done after firewire bus resets

HAVi service discovery

• Clients lookup the registry using
  • Registry::GetElement(in SimpleQuery, out sequence<SEID;> seidList)
  • Registry::MultipleGetElement(in ComplexQuery query, out sequence<SEID;> seidList)
• The registry supports a comparison operation which includes
  • equals, not equals, greater than, etc
  • bitwise and/or
  • sequence equals, greater than, etc
• A simple query is

  
        struct SimpleQuery {
            AttributeName   attr;
            sequence<octet>   compareValue;
            CompOperation   compareOp;
        }
        

• A complex query is performed on two sequences of SEIDs - not quite sure what this does - some sort of recursive hack?

HAVi clients

• A HAVi client runs as an application on a Full AV device e.g. an ordinary computer
• It can search for FCM's and DCM's and will get SEID'd for them
• From an SEID it can create client-side
  • DCMClient
  • FCMClient
  • Specific objects such as VCRClient, ClockClient or TunerClient
• Register event listeners
• Set up stream connections between FCMs
• Control devices

DCMCLient methods

Methods applicable to an entire device

• getDeviceClass() one of FAV, IAV, BAV
• getDeviceManufacturer()
• getFcmCount() number of FCM modules
• getFCMSeidList() list of FCM SEIDs
• nativeCommand() send a native (non-HAVi) command to the device

FCMClient methods

Methods applicable to functional modules in a device

• getFCMType()
• getPowerState()
• canWink() can it "flash" or "blink"?
• wink()
• getWorstCaseStartupTime()

VCRClient methods

• play()
• stop()
• record()
• fastForward()
• eject()
• getFormat() current media format
• getCapability() formats supported by device

TunerClient methods

• selectService() tune to a service
• getServiceList() possible services
• getService() info about currently tuned service

HAVi service invocation

• For DCM (devices) or FCM (functions) on the same FAV (full), objects can communicate using
  • direct procedure calls
  • callback functions
• HAVi objects on different FAVs must communicate using HAVi messaging
• Typically, a client uses a client-side object for the remote object, and makes method calls on the client-side object. The client-side object uses messages to the remote object

HAVi messaging

• Messages are handled by a communications manager that interfaces between HAVi objects and firewire
• Messages are

  
        Message {
            DestSEID
            SourceSEID
            MessageType  // simple, reliable
            MessageLength
            MessageBody
        }
        

• Simple messages have no response
• Reliable messages have the response of msg_reliable_ack or msg_reliable_noack for failure

HAVi streams

• Multimedia data such as video or audio streams are transferred on a Connection object
• A connection is made between two FCMs
• At each end of a connection is an FCMPlug
• First the plug at each end is created using the FCMs SEID, then the connection si constructed from the plugs

HAVi user interface

• HAVi objects can upload a user-interface as Java code to a FAV
• The HAVi user interface assumes a TV-like display device
• A subset of java.awt is used, with additional classes such as a "remote control" input object
• All of the AWT high-level presentation classes such as List, TextArea etc are gone
• Events, layout managers, basic drawing objects such as Point, Rectangle remain (This is pretty much the subset needed to implement Swing)

HAVi remote control

• The remote control device can be used as a source of events
• The keyboard generates KEY_PRESSED, KEY_RELEASED events
• The remote can generate events such as
  • VK_CHANNEL_UP
  • VK_VOLUME_DOWN
  • VK_POWER

Naive PVR

• The following code illustrates a very simple version of a personal video recorder
• It is based on the code from "HAVi Programming by Example" by Rodger Lea et al
• The full code is available from www.vividlogic.com/hbx
• For simplicity it finds (any) digital VCR, and (any) AVDisk recorder, sets up a connection between them and starts the VCR playing
• The code style is very much like CORBA

PVR communications

PVR class diagram

Naive PVR code