Looking into this topic was a big part of my MSc thesis, I thought it might be interesting to share some of the discussion here rather than watch all that work sit on my computer doing nothing! Let's start from the beginning:
Shows are getting larger and technically more demanding. Installations are becoming more intelligent, and health and safety regulations are getting stricter. This means that there is an ever increasing need for equipment to operate as a cohesive whole; not only within and across individual departments (Audio, Video, Lighting, Communications), but crossing over into other industries such as building automation, IT, and communications.
Achieving a unified method of control is problematic because most devices do not use the same control protocol (they do not speak the same language). The most popular solution to this is to use equipment originating from a single manufacturer because their products will be designed to work together. However, this leads to compromises in design (as the manufacturer may not make exactly the product you require) and often increased costs (due to the captive market). With a compromised design no parties involved in the system specification can reach their full potential.
Every event or installation consists of a unique collection of equipment, thoughtfully designed to fulfil a brief. Integration problems create an undesirable barrier, often preventing the ideal solution from being realised.
This is not a new problem in either the wider world or the entertainment industry. The same solution to the problem can be found in many examples: Ethernet, IP, USB HID to name a few. All solutions use a standardised protocol.
Standardised Protocols
Within the entertainment industry there are many examples where protocol standardisation has been used to achieve interoperability, the most successful example can be found within the lighting industry.From the onset of modern live entertainment lighting it was clear that different manufacturers would build control consoles, dimmers, and lighting fixtures, but yet they must all work together seamlessly. This meant that all manufacturers must agree on a method of control; a control standard was required.
Released in 1986, DMX512 was designed to replace the large number of proprietary control methods in existence and it has been very successful. It is “the most widely used entertainment lighting control standard in the world”[1]. You would struggle to find a controllable light designed for the entertainment industry not featuring DMX.
Standardisation has drawbacks
However, the lighting industry is quickly outgrowing the capabilities of DMX5121. With 8-bit resolution, DMX was never designed for the complex lighting fixtures in use today. This means that it is not uncommon to see devices with high resolution modes where two channels of DMX are used to specify attributes requiring finer control (giving 16-bit resolution). It was also not designed to handle the sheer number of fixtures that are used on modern events. It is clear that a replacement is required or DMX must evolve to fit the new requirements of modern lighting fixtures.Unfortunately, this is causing the lighting industry some problems because all manufacturers must agree to use the same protocol. This means that the final protocol must suit the current (and future) needs of all manufacturers.
These control requirements are hugely diverse. For example, the new protocol must still cope with a simple single channel dimmer, but it must also be able to cope with situations where life-safety is a concern such as pyrotechnics, and equipment for flying scenery. It also must be updated to work on standard IT infrastructure that exists everywhere. It may also need to be secure so that a “hacker” cannot turn out the lights at the inaugural speech of the President. With the increased use of video content perhaps the new protocol needs to carry multiple channels of video as well?
For these reasons and more, there is still no official, stable, and widely supported protocol for controlling lights in the entertainment industry other than DMX512-A.
Standardised protocols try to satisfy the needs of as many different users as possible which usually renders them huge and difficult to implement, thereby increasing development time and costs. A simple fixture that only has dimmer control will not have the development budget to implement these huge industry-wide protocols. To keep the costs low they’re unlikely to even have the Ethernet capabilities required to implement the majority of these protocols.
Control standardisation in the audio industry
In the audio industry there is more call than ever before to ensure that products are remotely configurable and monitorable.Unfortunately the audio industry has never been able to produce a control protocol that has been adopted industry wide. The AES have published many different standards in an attempt to find one that suits the needs of every user. Other industry bodies have also tried, some of the most ambitious are attempting to produce a single control protocol for the entire entertainment industry (AVB).
Advantages of using proprietary protocols
Rather than embracing control protocols published by industry bodies, manufacturers quite reasonably often choose control protocols based on their product requirements and development expertise, often ending up with unique proprietary protocols.These protocols are designed to suit their product requirements exactly, they do not have to compromise to fit to the rest of the industry. This is useful because it allows the developer to design the smallest, most efficient control protocol required; minimising processing overheads and leading to an efficient product, which is often more reliable. These protocols are also very quick to implement and develop, reducing costs.
Manufacturers do not have time to implement a protocol that they will only utilise a small fraction of. If a protocol offers features that are not needed in their product it is effectively wasted development time.
Importantly, allowing the developer to specify the control protocol encourages innovation. The developer is not locked to a set of rules defined by an external body. No standardised protocol can leave enough room for future requirements because it is not know what these requirements may be. By the time a new version of a protocol can be written and approved, the once innovative idea is old technology.
Translating between protocols
It is unrealistic to expect an entire industry to be able to agree on the description of one single control protocol. This is especially apparent at the boundaries of multiple industries. The entertainment industry cannot expect the building automation industry to implement a protocol designed for and by the entertainment industry.Eventually the concept of a single interoperable control protocol becomes untenable and protocols must be translated to achieve device integration. Currently this is often achieved using an entertainment industry designed controller with a GPIO port. The GPIO port is then connected to a building automation industry designed controller via its GPIO. An engineer must then dictate what each GPIO port represents. Not an elegant solution.
An alternative approach to industry wide integration is to translate between the pre-existing small, specialised control protocols that manufacturers already use.
Protocol translation is entirely achievable, it's what I studied and implemented for my Thesis. I made a working proof-of-concept control protocol translator. If you want to know how it works drop me an email and I'll happily send you some stuff across.
It should be noted that protocol translation can only reach its full potential if the application-specific proprietary control protocols used by manufacturers are released openly. Having to purchase a licence from a manufacturer in order to implement a protocol would make a universal translator prohibitively expensive.
That is not to say that control of a product cannot be monetised. The ability for a product to respond to control commands could be licensed, but the actual control protocol must be freely available.
Conclusion
Encouraging the use of small, open-source, application-specific control protocols would mean that it would be quicker to develop new, innovative products. The final product would be more efficient, reliable and less prone to bugs. Writing translations to move between protocols would be less arduous because each protocol is quick to implement.Protocol translation would be a faster route to industry wide integration than designing one protocol to suit everybody.
No comments:
Post a Comment