MENU

Continuous Delivery In Automotive Environments

Continuous Delivery In Automotive Environments

Technology News |
By eeNews Europe



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 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.

Automation

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 organization) 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 optimization. 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.

Feedback

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?

From the experience of Continuous Integration, much testing can be automated and run on every check-in of a change to the version management system. That doesn’t mean all testing gets run on every check-in but an important subset will be. These tests might verify the core functionality or validate regressions haven’t been introduced. Some automation systems put extreme loads on the version management engine so having one that can scale for such usage is critical. Choosing which tests get run at this stage is also very important. They have to be a reasonable validation, but also run quickly enough not to bring the development teams and systems to a halt waiting for test results.

Another key element of feedback is how it is used to change future plans. With common Agile development methods such as Scrum or Kanban releases are broken into short “sprints” with planning and retrospective review phases planned in to ensure that working systems could be released at any point and feedback influences the plans for the next iteration. These approaches can be applied to hardware as well as software. Interestingly, these approaches were originally inspired by innovations in the automotive industry.

Versioning

It’s impossible to automate unless it’s very clear where the CI and CD can get the definitive versions of all the assets involved in making a release. That may be system source code, configuration information, firmware images, hardware designs, test plans, test data, system documentation and much more. If multiple version management systems are involved then so are the risks in ensuring a complete and consistent build is possible. What is the “single source of truth” and what is the “chain of custody” for every element being used in the release?

For teams that are geographically distributed, or working in parallel, a common version management system ensures visibility of changes and easier collaboration. If conflicting changes are flagged during check-in, either by the version management system or CI build & test, then the version management system should help resolve the conflicts with complete change history.

The automotive industry is seeing increased regulation such as ISO 26262 for Functional Safety and ISO 16949 for Quality Management. They both place increasing demands on manufacturers to show they have safety and quality processes in place and that those processes are being followed.

This requires the ability to maintain records of what is being implemented, what is changing and who is making the change. The only way to ensure compliance is via a version management repository that can securely store all assets generated during vehicle design & build including hardware designs, software source code, documentation, test plans and test results. With such a broad set of assets being stored an equally diverse set of contributors will be involved – from C programmers, through to graphic artists designing maps and icons for the SatNav, to accountants keeping track of production costs.

Configuration management is critical to embedded systems development. Systems such as braking are a collection of components (hydraulics, pads, firmware, sensors etc.) and delivered into different configurations (e.g. different variants of the same vehicle or different models within the manufacturers range). Being able to manage components from different suppliers, whether inside your organisation or not, and where each configuration is being delivered is critical for quality and compliance recording. The version management system should be able to handle these relationships and record how components are being used.

 

Key actions for successful adoption of continuous delivery in embedded systems:

  1. Version Everything. Not just source code but test data, environment configuration, firmware images, documentation, and more.
  2. Automate Everything. Or at least as much as is possible. Understand the potential impact of manual elements.
  3. Feedback early and often. Automate test plans to be executed on every change or check-in whether hardware or software. Review and update plans regularly. Iterate and improve continuously.
  4. Include all possible configurations. Include in your automated continuous integration process, record in your version management engine.
  5. Universal usage. Make sure your chosen tools can be used by all non-technical staff as well as the development team for efficient collaboration and versioning.

 

Conclusion

Time to market has never been a more critical element of product development in the automotive industry than it is today. Ensuring that products fit customer demand is what makes products profitable. Agile methods, particularly Scrum, offer a chance to address both challenges during the development phase. Continuous Delivery automates the process of moving those changes through the product lifecycle into production as quickly and reliably as possible. A strong Version Management tool is required to enable distributed, multi-skilled teams to fully exploit the promise of Agile methods and Continuous Delivery.

 

About the author and Perforce Software

Mark Warren is Marketing Director, Europe, for Perforce Software. Mark has over 25 years experience as a consumer and vendor of enterprise development and configuration management products. Perforce’s products are used by over 5,500 organisations and 400,000 users worldwide, many of which are in Europe. www.perforce.com

 

If you enjoyed this article, you will like the following ones: don't miss them by subscribing to :    eeNews on Google News

Share:

Linked Articles
10s