802.15.4 / ZigBee stack

I've been working with ZigBee, and the ZigBee precursors, since 2001. I've seen the pre-15.4 platforms, ZigBee 2004, ZigBee 2006 and ZigBee 2007 (aka "Pro"). I've been doing some thinking recently about the software effort that goes into a stack. This is an area most people who buy ZigBee radios don't think much about. They tend to focus on the hardware characteristics of the radio, such as receive sensitivity and adjacent channel rejection.

It's software that makes ZigBee not hardware. After all, without software a ZigBee radio is just an ordinary point to point radio like any you'd see in a remote control toy.

Back in the ZigBee 2004 days, the intention was to fit in a 32kB part. The natural course of design by committee has changed that of course. With the swelling of the application support layers, the multiple layers of security, and concerns for application profile interoperability, we're now pushing outside of even the larger 128kB parts. Not many 256kB 8bit micros even existed in 2004. It makes you wonder if it's ZigBee that's driving the larger parts now available. It's like how Microsoft's bloated software used to drive Intel and the drive manufacturers. :)

So how much code is 128kB of flash? I figure on an 8-bit micro (the predominate ZigBee platform at the moment) you're getting about 2 bytes of machine code per line of C code. This means there are about 64,000 lines of code in the complete system. By complete I mean everything. The radio drivers, the MAC, networking layers, ZDO, ZCL, security, RTOS, application utility code, and interoperable applications.

Studies have shown that the average programmer generates about two lines of debugged C code per hour. That may be shocking if you've never heard it before, but trust me it will eventually sink in. This means that a ZigBee platform has about 15 man years of software effort in it. Assume that these programmers cost about $60k/year, this is $1m in software engineering for this little radio. In the real world, you'd also have to about double or triple those figures to account for documentation, QA, management, interoperability testing and overhead. And finally, don't even think about building a stack without both building simulation targets and real hardware networks (huge dollars on their own!).

Take a look at UC Irvine and USC Center for Systems and Software Engineering's COCOMO II model. Head over to the online calculator and enter 64,000 lines of code. Be sure to make your adjustments for team familiarity with the subjects and organization efficiency style. You'll find results in the 80 man year range once you account for the constrained system embedded nature, team unfamiliarity with the standards, and extreme necessity of unusual embedded tools (wired and wireless sniffers, diagnostics and scripted testing software, and commissioning tools).

Admittedly if you have top notch programmers you're probably getting 5x the stated COCOMO efficiency and paying them accordingly. However, as the team grows the law of averages takes over and you're no longer getting the 5% cream at the top, instead you're getting average performance.