Dan Fogel, Chief Technology Officer, DNF Controls
Centralized or decentralized? That’s the key question when it comes to selecting a control system. Ultimately, either configuration will yield the same result, but from very different approaches. Each has advantages and disadvantages in various build phases, so it all comes down to preferred design and operational needs.
|One operating controller (plus offline backup if redundancy is needed) that touches every aspect of the facility, from routers to production switchers; multi-viewers to camera and device tallies.||Multiple operating controllers distributing connections across multiple hardware devices: routers, production switchers, multi-viewers, camera on-air tallies, etc., in a logical manner|
|One set of configuration files that covers every device connected to the system||Each operating controller contains its own configuration files for connected devices and their tasks|
|One device from which to control system configuration and operation||
Multiple devices from which to control system configuration and operation
A centralized system requires less hardware than a decentralized one, translating to less design effort and drawings; therefore, a lower system cost. A centralized design identifies the number of serial ports, GPI/O,
and Ethernet connections required. How the system will be used and configured is deferred to the Installation phase.
A decentralized system takes considerably more effort in the Design Phase to identify each deployment area and its specific functions. Compared to a centralized system, there will be more hardware, design drawings, and a higher overall cost. However, since more design thought will be expended up front, the Installation Phase, aside from physically positioning devices, will be much shorter.
This phase, or the project phase, will differ for every design. For a centralized system, this phase defines its use and operation as it is implemented. For a decentralized system, use and operation have already been detailed during System Design, so this phase consists of configuration and implementation.
The centralized system
- One device builds configuration files and specifies system operation
- User interface: Typically a computer or terminal connected to the primary controlling device
- Configuration process involves accessing and manipulating multiple screens of data
The Decentralized system
- Multiple devices need individual configurations and specified operational parameters
- User interface: Computer and Web browser connected to each system component using
its own unique IP address
- Data is accessed and manipulated across multiple web pages
- Built-in configuration files reside on their respective system components
The Test Phase on a centralized system may seem easier due to less hardware and fewer components. However, it may actually be the same or greater because, unlike a decentralized system, it can’t be broken down into manageable parts. In the end, both system types have their own challenges.
Daily use is the strongest measure of a successful design and systems can remain in operation for decades. User satisfaction, whether a centralized or decentralized operation, depends greatly on how its being used.
At one end of the Use Continuum is the static configuration where one customer / client / operator uses the system with a single setup that does not change, ever. At the opposite end is a dynamic configuration that supports many users with ever-changing needs. For example, a commercial production facility. Such changes might include adding, replacing, moving equipment, or making changes due to personnel, client, workflow,
or show changes. The challenge during the Design Phase is to identify where on the Use Continuum any given facility will fall.
By the nature of its design, a centralized system can potentially take down the entire system with a single change. A decentralized design spreads the risk among all its system components; a change made to a one component may take down that device, but never the entire system.
For centralized designs, all production control rooms are attached to the one system. A configuration change made to one control room may impact the operation of other control rooms. Restoring a configuration for one room will ripple the changes across the other rooms.
The potential cost of making a change is taking down the system or adversely impacting other in-use rooms. For this reason, it’s not uncommon for a facility to ask the manufacturer of their centralized system to make changes for them, or to discourage any changes at all. If the facility is closer to the dynamic end of the Use Continuum, then the system’s ability to meet the client’s needs in a reasonable timeframe may be severely impacted. If the facility is closer to the static end of the Continuum, there may be no significant impact.
In decentralized systems, production control room components are isolated from those in other rooms. Changes made in one room have no effect on any others. Restoring a show configuration in PCR #A will have no impact on PCR #B, which may currently be on-air. Changes can be made easily and quickly, at any time, affecting only the room where the change is occurring.
This allows the system to more easily meet client needs at the dynamic end of the Use Continuum in a reasonable timeframe. In addition, ease-of-use encourages an openness to making changes that may simplify, enhance, or improve a client’s production experience. For facilities that function closer to the static end of the Use Continuum, however, ease-of-use may not be a significant design consideration.
Maintenance is the second longest phase of any system build. It can include monitoring the system’s operation, troubleshooting operational and technical issues during and after productions, performing software upgrades and performing hardware and infrastructure repairs. Operational issues may include operator errors that occur due to incorrect use or a misconfigured system. Infrastructure repairs can include correcting wiring and power related problems, or fixing equipment connected to the system, such as routers, production switchers, multi-viewers, etc.
On a centralized system, any problem has the potential to affect the entire system. Correcting a misconfiguration in PCR #A by changing a configuration file may impact PCR #B while its in-use. Troubleshooting a cabling issue on the back of a central processor can adversely impact other devices and rooms connected to it. Because of the risks inherent by their being interconnected, centralized systems require maintenance personnel with a higher skill level and a deeper understanding of the overall facility’s configuration. It is not unusual for a facility to appoint one maintenance person to perform this role. Additionally, system troubleshooting may be delayed, or a client asked to live with or work around an issue, until it can be addressed without impacting other rooms.
Decentralized systems, on the other hand, isolate rooms so that problems can be addressed quickly and easily without affecting other areas. With only a general knowledge of the system and its configuration, maintenance personnel can readily identify, isolate and resolve problems. System changes can be made without a high level of experience or system knowledge, and troubleshooting can occur without impacting operations in other parts of the facility.
For those closer to the static end of the Use Continuum, the primary role of maintenance may be to service the system only when there’s a problem. For facilities at the opposite end of the Continuum, maintenance staff may implement changes as and when needed to keep the system up and operating correctly.
Choosing a tally control system is foremost about design and operational philosophy. What serves the facility best: Centralization or Decentralization? How will it be used? Where does it fall on the Use Continuum and what is the skill level of the facility’s personnel?
At each phase of a facility build, different levels of effort are required based upon the chosen system. The Use Phase – the longest of all – followed by the Maintenance Phase, should rank higher in consideration than any others because they have a much greater impact on the functionality that the facility was designed to achieve. Understanding how the facility will be used and where it falls on the Use Continuum is the best guide to selecting a tally control system that best meets both near and long-term goals.
DNF Controls’ Tally Manager™ system is a de-centralized tally control system.
DNF Flex Control Network DC21, part of Tally Manager.
About Dan Fogel
Dan Fogel’s contributions to the television production industry span four decades, with extensive experience in music recording and audio post on both East and West coasts. Dan founded DNF Controls in 1990 and serves as the company’s Chief Technology Officer, designing and developing innovative control interfaces to meet the real-world device management needs of studio and remote broadcast, teleproduction and similar facilities.
- Tally Control Systems: Centralized or Decentralized - April 10, 2016