Embedded Software and Agile Hardware Development
Author: Kevin Thompson, Chief Scientist
The worlds of hardware development and software development merge when companies develop integrated products that contain both hardware and software. We see this in high-technology products ranging from personal fitness-trackers to rockets.
While some of the software that is associated with such devices can be external, much resides in the device itself. Broadly speaking, this internal software can itself be application oriented, or provide the low-level interfaces between the internal software and the physical device. The latter is usually referred to as embedded software, or firmware.
Development of embedded software poses challenges that go beyond those of application software. The engineers must address the fine details of the hardware and the specific chip sets and device drivers required for the device. Debugging may require logic analyzers, multimeters, oscilloscopes, spectrum analyzers, and other equipment as much as it does setting breakpoints and observing variables in the code.
Another difference between internal software development and application development is the use of Real-Time Operating Systems (RTOS). An RTOS differs from an OS like Windows or Linux in that it guarantees a response time to requests. This is a critical characteristic for environments where milliseconds of response time spell the difference between success and failure. Examples include automotive safety products, sensors, drilling equipment, avionics systems, and radiation-monitoring equipment.
The tight integration of embedded software with hardware requires careful management of their concurrent development. Fortunately, Agile techniques and frameworks (such as Scrum) make the management of this concurrent development easier than classic project-management approaches, such as the Waterfall process.
It is best to have firmware developers on the same Scrum team as mechanical and electrical engineers. This approach provides for maximum collaboration, and earliest discovery of integration errors. The latter is critically important, because late discovery of integration errors is a large source of cost and schedule risk in product development.