Continuous Deliver and Embedded Automotive

I have worked on projects that employed continuous delivery for embedded products. The embedded product was an automotive component.  The core of the software (the operating system) was specified using conventional approach. This operating system consisted of the maximum model requirements for this globally used component. The component looked and acted differently depending upon market segment and geographic location, for example, there were two different European incarnations and more than two for the markets of the United States.  This was not just some parameter setting or configuration differences, but whole scale differences in feature content and manner of execution.

As we indicated, the operating system, though we called it an execution engine, was specified and developed using an incremental approach. This incremental approach was based upon a prioritized set of features. That prioritization was based on what it would take to produce a vehicle that would operate safely allowing for testing of key features.  In the past, this component would have had the entirety of the software outsourced with the exception of parameter settings for each geographic / market segment. The desire was to make common use of hardware, and core software and allow for ease of adaptation based on the local application requirements.

 Continuous Delivery, Prioritization, and Specifications

The continuous delivery started with the specifications for each unique incarnation of the product. These were feature specification for the product and there were more than 150 of these unique features and each feature had a number of variations.  The writing of these unique feature specifications was likewise prioritized based on the most important features to get a vehicle moving safely, and synchronized with the supplier operating system delivery.  This team consisted of 3 members; vehicle system experts and component experts. This team wrote specifications and reviewed with the system portion of the team in small iterations. For example, the top 5 feature specifications that supported the objective of a vehicle that was safe to drive.  Once written, these functional specifications would be reviewed with the systems engineering portion of the team, and upon passing the review, these feature requirements documents would be given a version number and sent to the second team that performed the development and testing of the product (more on that later).  There was a continuous delivery of feature specifications, a few at a time, to the developers.

Continuous Delivery

Continuous Delivery and Execution

The second team consisted of five people. Those were two developers for two different product versions, as well test and verification person for the products, as well as the person who was writing the specifications.  In fact, this person led the team using an agile approach.  The difference between these two products was not parameters only.  As the project progresses, the specifications and features of the two products would diverge. However, in the early phases, some of the specifications were common or described parameter setting and performance differences.  Since the team lead (scrum master) for this project was intimate with the development of the specifications, they were in a position to answer questions regarding the development.  This input, as well as that from the testing, are then fed back to the specifications for updates as the iterations progress.

After testing, and providing there were no safety ramifications, the iteration of software was provided to people within the organization that represented the customer and drove the vehicles to get constructive input to further guide and refine the development.

Continuous Delivery Summary

There were quick writing of the feature specifications just in time for the developers to code that part of the system. The developers would deliver iterations of the product that contained the latest specification content to the test personnel. The test personnel would test the product against the specifications (among other things) and review the results with team members to ascertain if what was found was a failure in the product or a defect in the specification.  The defect would then be reported assigning the appropriate area for the corrective action (update the specification or the software or even both when necessary).

Continuous delivery requires prioritizing the most important and then bringing a laser-like focus to those things.  We will continuously do the upstream work (specifications) and we will continuously build, test, and update the product.  This produces a product that can be demonstrated from which we can learn and take appropriate actions to bring the design to fruition effectively and efficiently.  Besides that, we are able to gather data on our execution and will be in a better position to predict the outcome of the work.