Global Sources
EE Times-India
Stay in touch with EE Times India
EE Times-India > Embedded

Explore continuous delivery in automotives

Posted: 12 Aug 2013     Print Version  Bookmark and Share

Keywords:Continuous Delivery  CI  CD  Automation  Versioning 

The are recent innovations seen in the area of “Continuous Delivery”, such as 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 is 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.

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 from designer or programmer to the assembly line isn't yet achievable, speeding the processes from inception to integration testing can bring huge improvements in overall production cycle times. With so much testing now being performed in computer models and simulators it may be possible to see code or design changes getting into "acceptance testing" within days or even hours.

There are several keys to successful Continuous Delivery, but this paper focuses on three:

Automation: Manual processes introduce effort and risk. Fast cycles demand automated processes.

Feedback: If something is wrong, whether it's a test failing or customers not happy with the functionality delivered, the quicker that is fed back to the developers the quicker and cheaper the fix.

Versioning: At the core of automated systems, versioning is a critical requirement, not just to support automation, but also for compliance.

As is well understood in the auto industry the move from manual assembly to mass production made an enormous impact on cost of production and quality. Production of software or embedded systems is no different.

If deploying changes relies on manual processes then errors will occur. That could be for any number of reasons such as the "expert" that normally does the releases not being available (for example, the change is out of office hours or the expert is no longer with the organisation) or some change in the environment that has not been accounted for. What ensures that manual processes are recorded and validated? As systems become more complex, it's doubtful a single person can really know enough about all the components to deploy them accurately.

Automation also enables optimisation. If code takes time to compile, can the process be distributed across multiple processors or machines? Can some component not be compiled every time? Can testing being automated? If something goes wrong, how easy is it to revert to a previously working environment? How do you measure performance of each stage of a manual process?

Manual processes may still be needed in some situations. For example to make the final "push" to the assembly line or where automation isn't physically possible. These situations need to be fully understood and management processes implemented to mitigate the risks outlined above.

In terms of Continuous Delivery, "feedback" is any information about the performance of the system: Is it passing its tests? Is it delivering the performance, functionality or value that the customer requires? Is the development team delivering the required functionality at a pace that will see schedules achieved?

1 • 2 Next Page Last Page

Comment on "Explore continuous delivery in autom..."
*  You can enter [0] more charecters.
*Verify code:


Visit Asia Webinars to learn about the latest in technology and get practical design tips.


Go to top             Connect on Facebook      Follow us on Twitter      Follow us on Orkut

Back to Top