By making some changes to the automotive development process, and considering timing-related issues from the outset, you will discover the timings issues rather than having such issues discover you. This begins with the addition of clear timing definitions to the requirements, including items such as the maximum execution time of tasks and the latencies of event chains, the deadlines by which certain events should occur, and the maximum allowable age of data in sensor fusion paths.

By including these and defining them clearly they can also be tested at every stage of the development process. This can start right at project kick-off with modelling of the system.

Early on, during simulation of the system’s model, this allows potential timing issues to be detected very quickly. Because hardware has probably not yet been defined, different hardware architectures and processors can be tested with the model to see where potential timing conflicts may occur. The accuracy of the timing requirements can also still be modified at this point, providing a better basis for testing through the development process.

The timing used for these simulations form the basis of the timing requirements for the project. These can be set as limits in the model and can be tested against. If the model is updated or changed at any point, the model can be tested for potential timing issues immediately before any additional software development is undertaken. As the project progresses, these verified timing requirements form the basis for the tests needed to verify their fulfilment. Key here is the definition of how this should be achieved, and the results shared, throughout the project.

Once the processor hardware has been chosen, and the software development process has begun, regular testing against the timing requirements using Continuous Integration (CI) tools can also be included. By placing the results of timing tests prominently on the dashboard, the entire team can quickly see when timing requirements have been violated. These can be resolved immediately, rather than being silently carried over to later project phases. Clarity on timing also helps when working with multiple software partners in complex embedded projects.

The value of clear, verified timing requirements, and a battery of tests to check they are fulfilled, really comes into its own during the software integration phase of the project. This is where the most timing issues are found, disguised initially as issues with functionality. Experience in almost 200 customer projects has shown that, by following the methodology described here, the quantity and complexity of timing-related issues that arise at this stage are tiny in comparison with projects that have a more lax approach to timing requirements. The simulation models, testing, and use of instrumented or hardware trace inputs, that are available at this stage all contribute to a significantly better understanding of the timing challenges, and the ability to tackle them when they arise.

Customers, with whom INCHRON has worked with over the past 17 years, have stated publicly that the approach defined here has helped them to find timing issues in their complex automotive embedded system projects up to 12 months earlier. This is thanks to having a much better understanding of the timing complexity of their products.

If you would like to find out more, why not get in touch with our team to discover how we can help?