[This post is part of our Designing Hardware for HD series. Be sure to check it out!]

Video conferencing products, like most software products, are bound to need an upgrade:

• They need to interoperate with a large number of products – some of them unavailable or non-existent when the product was purchased.
• They are quite complex, which means that they bound to have bugs in them – some more annoying than others.
• Vendors often introduce innovative technology using software upgrades.
• They are communication devices, which mean that they might require special security patches once in a while.

This simply means that when designing your hardware, you will need to take into account the issue of upgrading the software on it.

What to Upgrade?

The first thing to keep in mind is that HD video products have multiple components in them, with different communication paths. So one of the initial things to decide, when designing the hardware, would be which components in your system will need to be upgraded. My simple answer? ALL:

• Make sure you can upgrade all of the code you have running around in your processors – the host, the video coding chip, the audio system – everything.
• If there are components that can be controlled through registers that can be accessed via drivers – make them available to your code. You never know when you will need to access them.
• Have specialized firmware on some of the more esoteric components, like the built-in Ethernet switch or an FPGA chip? Great. Now make sure it is part of your upgrade strategy.

How to Upgrade?

The next thing to deal with is the upgrade procedure itself. Here are a few pointers to get you started:

• File system. Make sure it is designed with your upgrading process in mind.
• Can you roll-back an upgrade? Usually that would mean holding two versions in parallel. It’s a safety measure against having the system crash due to a bad upgrade.
• Do you store the whole version on a single location and push it to all processors on boot time or would you rather have each processor have its own “local” image?
• Is your image really large? You might want to consider solutions that can aggressively compress the images such as the one offered by Red Bend.

When to Upgrade?

Who is your intended target customer?

• Is it an end user who would rather have automated upgrades without needing to search for an upgrade?
• Is it an IT manager or a federal agency, where the introduction of upgrades into their systems must be tightly controlled?
• Are upgrades something you want to push to the device from an external management system, or application, or is it something that your device would go and request?
• Do you expect customers to manually download upgrade packages received from customer support services?

These are some of the issues we see our customers struggling with, and they come up with rather different solutions – all depending on their hardware architecture and target customers. So don’t neglect this part in your design.