I noted, as did others, that the automation supplier openly struggled with the question, to the point of eagerly handing it off to ARC's Greg Resnick to answer. ARC coined the PAC term some 10+ years ago by providing a list of functions that such a controller should provide and/or facilitate in order to be termed a PAC.
I don't single out the supplier here, because this isn't even remotely the first time I've heard an automation supplier stumble over explaining a PAC's capabilities compared with other controllers. It's been 10 years, and it still retains a cloak of a term that means whatever anybody wants it to mean.
It seems that our community still has a tendency to latch on the perceived hot acronym and pepper its marketing pitch with it, so it can proclaim that "Hey, we got us one of them things too!"
This time it reminded me a little about the days when automation suppliers grappled with explaining what constituted an "open system."
To celebrate our 15th anniversary in 2012, we brought back older pieces of content to print and promote on the web site. They were really well-received, so we're continuing to present "retro" from time to time this year, as well.
"Open Systems? Who You Gonna Call?" is a guest column from 1998 about the pain and gain and hope and fears [and definitions] about open systems. In my head anyway, some of this resonates with today's acronym acrobatics. Once again, note company names have not been changed to protect the innocent. That's who they were back then.