The NAB continues to push a software-based solution for Emergency Alert System equipment, allowing broadcasters to replace physical encoder/decoder hardware with digital options. The suggestions build off the NAB’s EAS stance submitted in late 2022.
NAB representatives met with staff from the FCC’s Media Bureau and Public Safety and Homeland Security Bureau at Hubbard Broadcasting’s WTOP in Washington, DC, on October 16. During the visit, the NAB emphasized that the software-based EAS approach would be a voluntary option for broadcasters, who could continue using existing hardware if preferred. The proposed software would seamlessly integrate into current EAS systems, ensuring no negative impact on station operations.
The NAB says the technology could be installed on existing computers or separate devices located at a station’s studio or transmission site, similar to traditional hardware boxes.
They clarified that the software solution would not rely on cloud-based systems, maintaining functionality even if Internet connectivity is lost. The association stressed that virtualizing certain EAS elements could improve system readiness and resilience by reducing downtime for equipment repairs, enabling quick failover to backup systems, and supporting geographically diverse redundancy in case of major disasters.
Recently, additional focus has been directed onto the need for an FCC-standardized cybersecurity risk management plan template for broadcasters, specifically focused on the Emergency Alert System. In September, the NAB highlighted that small and mid-sized broadcasters may struggle to create adequate cybersecurity plans due to limited resources and lack of in-house expertise. Without a standardized template, these broadcasters might need to hire costly external consultants to comply with FCC requirements.
The NAB also questioned the FCC’s proposals on the timely repair of faulty EAS equipment and the reporting of equipment failures. They argued that since the FCC does not assist in repairing EAS equipment and repair times are often beyond broadcasters’ control, these requirements may not effectively enhance the system’s security.
Three points here.
One, software solutions for the EAS have existed for over twenty years, they just haven’t been approved by the FCC. I played around with a Windows-based demo version all the way back in the early 2000’s. It did have some bugs, but they could have been ironed out. I wouldn’t trust this job to a consumer OS, though. It needs to be running on something that dedicates all resources to the task. A custom and very light version of Linux, for example.
Two, the reduced cost for stations would certainly be a good thing. Those boxes are basically just computers in and of themselves, there’s no reason why they have to be purpose-built. There’s nothing the EAS does that needs a ton of power or resources; you could probably do it on a Raspberry Pi. The machines just need to have enough audio ins and outs, redundant power supplies, and be hooked up to a decent UPS. Even a cheap used server would be overkill.
And three, the ONLY way this should be allowed is if the computer being used is a DEDICATED MACHINE. No other software can run on it. The EAS is Priority ONE when it comes to any broadcast station’s airchain. If there is ANYTHING else on that box to bog it down, things WILL go wrong, and that is NOT acceptable. The system is already a mess of 80’s digital technology slapped on top of 60’s analog technology, we don’t need any MORE points of failure making it worse.
Overall, it’s a good cost-saving measure, and one that I’m frankly surprised hasn’t happened sooner. We just need to make sure it’s done CORRECTLY.