I usually like standards. They can crop up in standards organizations and committees and make it easier to plug things together. Then, de facto standards can grow organically - and get pushed by companies with big bucks. Unfortunately, such pushing often results in standards that don't necessarily provide interoperability. Likewise, there can be issues as to whether a standard is open or closed. Closed standards tend to limit the field, often allowing vendors to maintain higher prices.
The home market has been ripe for standards, especially in the booming multimedia space. The two major organizations in this segment of the industry are DLNA (Digital Living Network Alliance) and HANA (High-Definition Audio-Video Network Alliance). Both are pushing standards that ride atop an IP network and are designed to provide vendor interoperability.
In theory, they could potentially simplify the plethora of cabling found behind most component multimedia systems. Initially, though, it's unlikely that they will reduce the interface complexity found on devices like HDTVs, which will continue to sport half a dozen interfaces to satisfy the range of buyers.
HANA's more conservative goals target a specific class of multimedia devices, such as DVD players, PVRs, HDTVs, and stereo receivers. Although HANA can utilize different network implementations, its primary platform will be IEEE 1394. This wonderful standard is mandated for set-top boxes and found on many camcorders and even a few PCs, but it's not as ubiquitous as Ethernet or 802.x Wi-Fi. The HANA standard should be making its rounds soon, but that puts it behind DLNA.
DLNA is an interesting group (see "What Can We Say About DLNA?" p. 52). The DLNA standard is designed to provide interoperability, but the organization does not define new standards. Instead, it refines existing standards, particularly UPnP (Universal Plug-n-Play).
The UPnP standard is open and available without charge, but DLNA is closed and available only to member companies. In theory, a UPnP-based device could be used in a DLNA environment, but the limitations and difficulties of using a non-DLNA certified device would be problematic. Interestingly, DLNA stacks for Linux are readily available, for a fee.
The big advantage to DLNA is its certification. Each product must be certified before the DLNA logo can go on the product's box. The DLNA logo is popping up, but searching your local electronics store for DLNA may not deliver the list you expect. That will likely change as DLNA compliance becomes more important to buyers.
These standards offer an opportunity to embedded developers to make solutions that are better integrated with third-party products, reducing the cost of the solution. For example, a DLNA environment would typically have at least one controller and server that can service any DLNA device on the network.
This would include something like linking a computer-controlled sprinkler system to a security and monitoring system. Incorporating the solution into the network would reduce the number of interface devices a user had to contend with. Likewise, it opens up a potentially more robust display interface that would otherwise increase the cost of the solution.
Hopefully, these standards will clean up cabling clutter - and developers will be able to hear about how to implement them.
Reprints
