Even the youngest of scouts know the mantra be prepared. To be prepared is to understand, as best you can, what lies ahead. This is the maiden voyage of our new blog. Right now the horizon is perfectly flat but we are looking to fill it with interesting topics related to the embedded world with a focus on hardware and software integration, embedded industry trends, innovative technologies, and insights centered on hardware verification. The goal is to be prepared for change and I believe we are in a great position to begin conversations on what lies ahead.
2003 is the year that we started Kozio with the idea of accelerating and simplifying the integration of new hardware with new software for embedded systems. I am often asked how Kozio got started and wanted to take this opportunity to fill you in.
For many years leading up to the start of Kozio I had been making plans on starting my own business. I spent many years observing in person the inner workings of a number of startups, as well as a couple large companies. My career in Colorado took me from Array Technology to EMC, from Mylex to IBM, and then a stint at Vicom Systems before starting Kozio. Through all these experiences, I witnessed firsthand the various aspects of getting embedded products to market. I worked with many teams bringing new technology and embedded systems to market. One of the most successful systems that a prior team started from scratch and released sold over 50,000 units. Not a huge volume by any means, but certainly a success in the storage industry.
In the winter of 2002 after we had left Vicom, Keith Short, Merlin Arduini, and I, sat around a kitchen table discussing starting our own business. We discussed what the prior years had been like and the trends we noticed in embedded systems. The past projects we worked on all had a few items in common.
- The ratio of software engineers to hardware engineers continued to increase – We saw six or seven firmware engineers for every one hardware engineer. The hardware teams were doing a great job with reuse to pump out new hardware platforms that adopted new technologies (e.g. the latest and greatest storage interfaces.) In an EE Times blog, Jack Ganssle noted that a 2001 survey found that the average embedded project used about 7 software developers, so we were not alone.
- Firmware content was rapidly expanding – The same study confirmed what we witnessed; our firmware content was rapidly increasing year over year in an effort to keep with the new hardware, interfaces and other features. All of this made it very difficult to add features and support the new hardware platforms. It was often the case that the hardware team had to work very hard to pull a firmware engineer over for board bring-up (that first stage of bringing new hardware and software together.) Because there were so many features to be added to the application software, it was very difficult to find a free resource to work on the new hardware platform, and even harder to find someone skilled in that area.
- Low-level firmware required a specialized skill set – We also found that there were only a few individuals on our many teams that understood the very low-level interactions of hardware and software. Only a few individuals knew what it took to get a boot loader and kernel up and running on hardware and the rest of team relied on that platform to get their application code completed. We estimated that 99% of embedded firmware engineers were actually application engineers and 1% had knowledge of both hardware and software and actually able to get early hardware working.
With this in mind, I thought that it would be great to auto-generate a hardware abstraction layer for any given platform based on a hardware platform specification. The hardware specification file could be used to pull source modules from a library and those modules would provide the basic framework of a boot loader, drivers, and other needed basic input/output functions. The core vision was to provide known-good software that would quickly accelerate the integration of new hardware with embedded software. A user could use a hardware specification file to generate this layer of software and be booting the operating system the same day with no additional coding effort.
To get started though, we all agreed that it would be best to focus on a smaller niche area, such as hardware diagnostics. We felt that it would be best to focus on an area with little commercial competition. We also looked at the total market opportunity and found through Embedded Market Forecasters that there were roughly 40,000 design starts annually for 32-bit embedded designs. That seemed like plenty, as long as we could find them. With this plan in mind, we incorporated Kozio, Inc. and have been growing significantly year over year.
With the original vision, we have created a flexible and reusable framework that allows us to quickly adapt to new technologies and deliver a proven solution for custom hardware in hours. We have not fully reached our vision, but we are well on our way and have worked with hundreds of processor technologies, hundreds of custom platforms, and been used to validate hundreds of thousands of embedded system devices. The knowledge we have gained over the years has been embodied in a million lines of code which is available to customers as a packaged software solution.
We have set our course and we are on our way. We continue to help improve the discrepancy between software engineering efforts versus hardware engineering efforts for embedded systems. We encourage you to join us and add your thoughts on what lies ahead.