The most recent innovations being in the area of “Continuous Delivery” – reducing the time taken between requirement definition and delivering business value by iterating frequently to introduce changes. Although these approaches primarily deal with software, embedded systems that involve hardware and firmware can also benefit from the best practices included in Continuous Delivery.
Introducing Continuous Delivery
For software developers, Continuous Delivery (CD) might be considered an extension of the already popular approach of Continuous Integration (CI). CI is concerned with the automation of the build and, to some degree, testing processes so that errors in source code can be identified and remediated as early in the development process as possible.
CD takes this to the next level – once the code is in build and it's passing tests, how quickly can that package be deployed into production? Importantly, if this is to happen rapidly, how can you ensure the quality of such rapid releases and, if necessary, back them out? How can you show adherence to compliancy policies? For even the most traditional businesses, such as banking, goals of releasing code monthly, weekly or even daily are now being set to be able to respond to customer demand and competitive pressures.
Image 1: Handling complexity like in this example from a a truck requires a high degree of IT support. For full resolution click here .
For embedded systems and the automotive industry this may seem like an impossible goal. Surely hardware can’t be continually re-built and released into an assembly line as frequently as that? That may be true, but cycle times in the automotive industry have been falling rapidly for exactly the same reasons as for the banks. Customers demand the latest innovations, much of it software-driven – for example SatNav, self-parking, adaptive cruise control, improved power/fuel management - and competitors are always working hard to maintain or grow their market share. Even if fully automated delivery