Skip to Content

Report from the PSIA Developers Meeting

Report from the PSIA Developers Meeting

I snuck out of the Honeywell event to hit this first PSIA Developers Meeting, headed up by head David Bunzel, who began the group/is executive director (search PSIA to get all the details on that - no time to link right now). Depending on battery life, I may return to the Honeywell live blog. 1:03 - Bunzel - I came to ISC West in 2006 and I couldn't believe it, it was chaos. Everything was totally proprietary. All these small companies with total solutions, but very small and the industry was very fragmented. I saw there were no industry standards so everyone was trying to do everything. So, I got a group of companies together and said, "why don't we get together and identify some things that could actually be done in the industry." So we decided to create the PSIA and come up with some answers that would maybe help the industry. VMS suppliers were dealing with hundreds, if not thousands, of products. So we identified discovery, control of the device, and command and control of PTZ. Those were the initial topics. So we formed working groups: IP video, Analytics, Recording and Content Management (used to be just storage), Area Control (used to be access control, no contains intrusion, too), Core. Timeline: Feb. 08 - formed June 08 - core spec contributed by Cisco Sept. 08 - v.9 IP Media Device API spec Feb. 09 - v1.0 Service Model March 09 - v1.0 IP Media Device API spec March 09 - sample implementation Big slide of lots and lots of companies who are participating. Virtually all of the major VMS companies, many integrators. These companies are not only contributing, but the individual people are advocating this internally to their companies. 1:10 - Bob Cutting from OV, to talk about analytics: He's taking a while with his slides, so let me note that this is a scruffy looking crowd - I'm thinking these are actual engineers and designers of products. These are not sales guys, that's clear. No ties in the room, I don't think. Lots of T-shirts and scruff on the chin. Big difference from the Honeywell group, who are mainly business owners and sales types. I do wonder if there's a disconnect between the engineers and what they want and the sales people and what they want. Back to Bob: Analytics group was formed about six months ago, kind of a natural off-shoot of the IP video group. We agreed to focus initially on the output - the alerts and the metadata, which is really what the VMS companies are looking for. It's what systems integrators and customers want, too. Also includes capabilities discovery, so that the platforms and talk to each other, so the device knows what's going on and what's supported. One of the things that's going to be passed in a standard way is the rules and behaviors that are supported, and that will help with the rules configuration which will happen next. We've had great support from the industry, including GE, TI, Honeywell, Vidient, OV, Milestone, AgentVI, Cisco, Pelco, NICE, VideoIQ, Genetec, OnSSI, IBM, Vidsys - I like that it's not all analytics companies, it's a nice balance of everyone in the analytics spectrum, from device to the analytics to the application. Progress? We started with various contributions, SDKs that are out there, work in the open standards area, collected that and decided on a baseline, then opened it up. First we decided on REST, which the Core group will talk about more. We've made some decisions after that on event mechanisms, stream vs. push, using those models and considering multi-cast, looking at more push mentality. Looking at event types, from alert sampling, from system health standpoint. And looked at what does OV use for its format, what does Milestone gather? Came up with a standard event format, and we're just now producing a format for that. Also made decisions around what's a basic and full event. An application might choose just basic data - time stamp, that an alert happened, and what rule - or it might choose the full information, which might include the mark-up, the originating rule data. Just a two-layer approach depending on how much data you want to be passed. Can't just look at a single-channel event, have to consider whether it's an edge device, whether it's centralized, whether it's multi-channel or single-channel. We'll have to take all of that into consideration. (Looking at a flow chart, it looks like the analytics group is about 70 percent done toward a first working specification.) The next major discussion will be around metadata, which will be very interesting because there's a lot of different ways to approach that. Just happening starting this week, actually. (Bob Cutting talks really fast, by the way.) One of the great things that's come out of PSIA is that we have an established Core architecture team that serves as a liaison between all the working groups. So if we're working on similar things, we don't reinvent what other groups are doing. Working on: metadata, the baseline document, looking at a .9 version for public review in June (dang, that's soon - this PSIA group works fast). 1:22 - Back to Dave - introduces Dave DeLisser from Pelco to talk about the IP video working group. Dave D: This was a significant focus for PSIA right from the beginning. Video has gone through huge transformations. We have the ability to transport over networks, etc., but the one area that was a challenge was interoperability. As we got better and better, that whole interoperability really struggled for a while. We focused on those things that will really drive - get the industry back to the point where we can almost be a BNC simplicity. Get a consistent way of connecting cameras to VMS systems, in a standard method, and figure out what the capabilities were from the head-end, and address things like configuration, have standard methods for getting streams, for making corrections. I want to have plug and play connectivity. Make it easy for the users and installers to connect manufacturer A to manufacturer B. There are about 15 companies participating in our working group. We've had great contributions and generated a great specification. The process: The focus was the media device spec, which is the one that's been released. And we looked at the best method to get us where we wanted to go as quickly as possible. There are great tools out there, but the one we settled on was contributed by Cisco eventually, because it had a good foundation and we felt comfortable that it would create a platform to build on and get to the interoperability we needed. We had weekly meetings where we went through each capability and functionality that it needed. Started with use cases, what we were trying to satisfy. Then vetted the Cisco contribution, and removed elements that were not really in the scope of what we were trying to achieve. So, the spec is out now, and this is where we're going: Sample implementation, that's pretty much happening now, and we're close to the first of many plugfests, where we can get beyond the documents and the individual things working, and every manufacturer can be in a room and all plug in with each other and demonstrate real interoperability. Question: Are you guys working with codecs? Frank Yeh, of IBM, who will talk later, too: We already do have some groups out there in the world, JPEG and MPEG, so we're letting them do that. Q: Yeah, but they say they're MPEG 4, but what flavor? Yeh: Yeah, no kidding, and part of that is just publishing what you really do as a camera maker. Just saying you're MPEG 4 isn't enough. 1:39 - back to Dave B., introduces the Recording and Content Management working group. The guy who chairs it is from NICE, but lives in Israel and couldn't make it over. So Dave runs it down: Group is still in its early stages, we've had a couple of calls - we tend to work virtually - typically conference calls. Starting to use some online tools like meetingplace and webX - a lot of companies have difficulty traveling right now. We meet at ISC and ASIS, plus four times for board members and steering committee. Have about 450 companies that have registered for the spec. Back to storage group: Looking at recording NVR/DVR vs. edge device; playback functionality, search capability, transfer - remote client and the ability to pull content; storage policy - who can access the information and how; content integrity; security - preventing unauthorized access; diagnostics for system health. There's been a call for contributions - NICE has made a contribution - and there's been a definition of requirements. And they're developing a use case to understand what problem we're trying to solve. 1:52 - Cool stuff, Ian Johnston from IQinVision has got a camera here with the media device discovery spec actually working. So they show Bonjour actually find the camera, ask it how it's configured, what's the configuration like, and you can actually just name the camera, which then writes to the software and updates the device's status. And there's something about actually watching the packets going back and forth. I'm not sure how you do this exactly. "It's human readable." I'm way over my head here. But they're showing it to us in real-time. Unfortunately, it crashes (it does that a lot, apparently, this "VLC," which I don't know what stands for). And he's focusing the camera right there, and Frank Yeh just happens to have a tripod handy, which is kind of strange. He tells the device that it's motion JPEG and we want it some HTP something or other way, so then he calls up a browser (there's lots of crashing going on and weird error messages - not sure if that's a PC problem or what). But now it's working with a standard rtp/rtsp stream. Whatever that means. Apparently when you look at the packet stream, "it's not very chatty at all," which is apparently the nice part. And you can call up the device info, and it spits you out an xml stream about what the camera is, what it's ethernet specs are, firmware version, etc. Seems to be pretty cool beans, even if it's meaningless to me. Basically, you can ask for a ton of information about the device and get an expected response that's pretty helpful for integrators who have to work with these devices. "It's pretty exciting that within a year of this being started real fingers are being put to code." Now they're showing something called Wireshark so we can all see the packets. This excites "the geek in me," says Ian. I'm on reserver power, so that's pretty much the end of this. But cool stuff, nonetheless. I've got to find a plug - hard to do in these convention centers.

Comments

To comment on this post, please log in to your account or set up an account now.