The concept of broadcast automation was first developed for the control of robotic cart machines. Such machines as the Sony Betacart and LMS, Panasonic M.A.R.C and Odetics TCS2000 revolutionized operations in master control, cutting down mistakes on-air and easing the playout of commercials. Even today, many of the features of automated playout from servers have their roots in those cart systems.
As broadcasters migrate from using videotape as the primary medium for content to digital files, there is an opportunity to automate many more processes beyond straight master control. Since automation can be defined in the wider sense as the use of equipment to replace mental and manual labor, any repetitive process in the broadcast chain can possibly be replaced by some form of software application.
The traditional implementation has been to layer automation over the existing architecture, effectively swapping out manual processes with automated processes. In the case of the robotic cart, automation replaced the manual loading and cuing of tapes. But the existing systems were probably designed to fit the manual processes and their associated constraints. A typical example is the creation of viewing copies by dubbing a master tape to VHS or DVD. Most companies now use proxy video files to browse video, but the encoding and serving systems for the browse proxies may well be a shoe-in to the older processes.
Until the downturn in advertising in 2009, many broadcasters were happy to automate on an ad hoc basis, but that year businesses focused on cutting costs. Automation offers a way to cut head counts and so presented one possible solution to bring the business back on track.
Those who attempted to layer automation over their existing processes soon found out that they were building a system that was difficult to manage. The complex web of interfaces, often with proprietary or custom APIs, makes commissioning and maintenance challenging. Engineers could find that they are locked into a software version, unable to upgrade because it broke an interface.
It became apparent that such a system design was no longer technically fit for purpose, plus it did not meet contemporary business needs.
The simple linear flow that tape imposes has been replaced with file-based processes that feed multiplatform, multiformat delivery. Broadcasters have to be more agile to allow their businesses to adapt to the new landscape for media and entertainment. There is new competition and new expectations from viewers, who want to view when they want and on the device of their choosing.
There are many methodologies that have been adopted by other business sectors to cope with similar rapid change. One is business process management (BPM), and another is the service-oriented architecture (SOA).
Business process management uses software to give managers complete visibility of all the processes that are happening within the business. From a dashboard, managers can view the key performance indicators, giving them the ability to improve the efficiencies of the operations, and manage the execution of the workflow.
This should lead to reduced operational expenditure and more effective planning of capital expenditure. It also allows managers to better optimize workflows and adapt to changing business demands.
To take one example, encoding and rewrapping is a key part of file-based workflows. BPM gives a view of transcoder utilization, identifies bottlenecks and guides the need for future purchases to match demand.
Business process management includes many modules. A presentation layer provides users with a dashboard to access indicators and metrics of the business. A communication layer manages messages between users and also to and from services. A workflow engine drives the services according to the business rules laid down by the organization.
BPM doesn't have to be applied across the enterprise. It can be implemented at the project or departmental level as a pilot and later rolled out as a program across the rest of the organization. This means that a broadcaster can try out the principles before committing to an enterprise program. BPM can also be used just to monitor existing systems. This alone improves visibility of the workflow.
Service-oriented architecture, as the name implies, is an architecture, not an application. It is a way to orient the services of the business to implement the activities of the business. In an SOA, the individual processes are decoupled from the mesh of interconnections prevalent in older systems. (See Figure 1.) Instead, each process presents as a service to the middleware of the SOA.
The service is represented by a business, rather than technical, description. This opens the way to vendor-neutral services. For example, one transcoder model could provide the same service as another from a different manufacturer, or it could even be a cloud transcoding service. It is this abstraction that gives an SOA the agility that older systems cannot deliver.
The BPM oversees the processes, but the implementation is carried out within the framework of the SOA. A software middleware application orchestrates the processes to achieve the desired workflow. For example, a request to browse some content falls on the orchestration engine. It initiates the restoration of a file from an archive, the transcode to a browse version and the move of that browse file to the desired destination.
An SOA is an inherently loose-coupled system, in that each service communicates with the others via an enterprise service bus (ESB).
How does broadcast automation relate to BPM and SOA?
Several areas of broadcast have been automated for years. Playout, feed recording and transcoding are examples. In a modern broadcast facility that runs file-based operations, file transfer has replaced the runner pushing a tape cart and the courier; HSM replaces the library or vault; and copying and transcoding replaces tape dubbing.
All of these functions can present as services to an SOA. The BPM orchestrates the services through the SOA, and most importantly, provides visibility to higher management of the broadcast operations.
Problems with IT systems
Introduce any IT system to a broadcast station, and you get knowing looks from the video engineers. “The IT guys don't understand video.” Although the boundaries are rapidly breaking down, the two disciplines have different priorities. A broadcast engineer will cite several problems. One is file size. A typical program episode encoded at 100Mb/s is in the region of a 45GB file, around 1 million times the size of an office document.
The ESB is designed for small messages and documents. It would choke on media files. The solution is to run a separate media bus (network) to carry the media files out of band. A file mover service manages the transfers.
IT systems are not real-time and deterministic, a prime feature of broadcast equipment. Playout automation is real time, playing spots to air timed to the frame. To get around this, any real-time operations must exist outside the SOA, using conventional playout automation. The automation can still present as a service but carries out a business service, like “play out today's programs to the schedule and return an as-run log.” The real-time operations are all encapsulated within the automation, which looks like a black box to the outside.
Some processes take a long time by IT standards. Transferring files is one example, where it can take hours to transfer large files. A process like editing can take days or weeks. This can give problems to an off-the-shelf IT BPM/SOA, so the system should be supplemented with media-friendly features to accommodate such issues.
At the presentation layer, desktops cannot render broadcast resolution files in real-time, nor would you want the associated network traffic. A DAM manages lightweight proxies and synchronizes operations performed on the proxies back to the broadcast files. This is another layer of complexity that does not exist with simple IT assets such as documents and messages.
Broadcast is not the only industry with large files. The oil and gas, and medical sectors also have large files, but the video engineer will point out they don't have to deliver them in real time. This is leading to an architecture where DAM, HSM, QC, playout automation, traffic, sales and all the other services linked via the ESB are orchestrated to deliver the goals of the broadcaster using the BPM/SOA.
How do you migrate?
The first step in the implementation of a BPM project is to model and document the business processes. This alone can identify problem areas or inefficiencies of existing workflows. From there, the business and workflow rules can be written.
The difficult part of the implementation will most likely be change management. Workflows will change; it is inevitable in order to gain the advantages of using BPM, but creative types can be notoriously resistant to change.
The other aspect of migration is to wrap the processes so that they present as services. Some products already have a service interface; others may need some coding.
Any broadcaster looking to move to this new methodology and architecture should first choose a framework that supports interoperability, interchangeability and reusability of media specific services. The European Broadcasting Union (EBU) and Advanced Media Workflow Association (AMWA) have formed a joint task force to investigate all the issues around the use of an SOA in the context of the media industry.
Broadcast automation has grown on an ad hoc basis to meet the needs of the videotape era. File-based islands lent themselves to computer automation, but manual processes linked the islands. This unplanned evolution has run its course, and the demands that broadcasters now face call for a new approach. BPM and SOA have become widely adopted in other business verticals and present one way forward.
Broadcasting is a creative, craft-based industry, and many of the facilities offered by BPM and SOA may not be appropriate. However, creative processes can be implemented out as services to a SOA. These could range from preproduction, through editing and sound mixing, to signing to provide access to the hearing impaired. These processes all require human skills, yet can still present as a service to the software through work orders and the like.
BPM gives visibility of the processes of the business. From this visibility should stem better management. It also enables business agility, the potential to roll out a new channel for the latest consumer device, or to hook into the latest social media platform. As change in the media sector accelerates, broadcasters must look to tools that can help them not only to better manage their business, but also to keep pace with the changes.