rapita's blog

The impending crash of automotive software: will ISO 26262 stop it?

Submitted by rapita on 19 January, 2012 - 13:56

A recent article we saw on electronic recalls reads like a Who’s Who of automotive manufacturers struggling to cope with the complexity of electronic systems and paying the price in higher costs and damaged reputations. Will the introduction of ISO 26262 put the brakes on this growing trend or can we expect more of the same?

The Safety Record article* starts with a list of global automotive brand names which it says have recalled models because of problems in complex electronic systems. The companies are:

News from the Certification Together International Conference in Toulouse

Submitted by rapita on 13 December, 2011 - 11:28

I've recently come back to the office from a whirlwind European tour that included a few days at the Certification Together International Conference in Toulouse. We're pleased that Aeroconseil and Certification Together have been able to continue this conference series.

Attendance was similar to last year, around 300 attendees represented 90 organisations (companies and universities) across three days of presentations and workshops. For us, the important buzz was:

4 key benefits of structural coverage for DO-178B systems

Submitted by rapita on 10 November, 2011 - 09:24

Sometimes the value of performing structural coverage (AKA code coverage) is questioned. When it’s performed as an end in itself, this might be true, but when it’s used to show the effectiveness of requirements-based testing, there are some really strong benefits.

DO-178C: The Next Avionics Safety Standard tutorial at the SIGAda conference

Submitted by rapita on 10 November, 2011 - 08:37

Andrew Coombes and Zoe Stephenson of Rapita Systems are in Denver to exhibit at and attend the ACM SIGAda Annual International Conference. Here are Andrew’s thoughts on a tutorial given by Ben Brosgol of AdaCore.

Eliminating timing variability: DRAM refresh times

Submitted by rapita on 8 September, 2011 - 12:23

If you're interested in getting accurate timing measurements of your software, you need to eliminate sources of variation to the software timing wherever possible.

Sources of variability include:

What’s the point of code coverage?

Submitted by rapita on 25 August, 2011 - 14:27

Testing has to satisfy two objectives: it has to be effective, and it has to be cost-effective. Testing is effective if it can distinguish a correct product from one that is incorrect. Testing is cost-effective if it can achieve all it needs to do at the lowest cost (which usually means the fewest tests, least amount of effort and shortest amount of time).

Measuring code coverage during testing can help to meet these two objectives by:

Minimize instrumentation overheads

Submitted by rapita on 4 August, 2011 - 17:13

A key challenge with on-target verification is the influence that the act of measurement itself can have on the results obtained. This is referred to as the called probe effect. For example, adding instrumentation points to the source code changes the code size, execution time, and may also increase stack usage.

Go beyond simple profiling

Submitted by rapita on 28 July, 2011 - 10:44

If you've measured execution time, eliminating the context switches and the variability they cause (see our last blog post), you may still have a wide variety of execution times that arise from the thread you're measuring. A natural question is why this should happen. To be able to answer such questions, you need to have the right level of information.

Some embedded development products, such as integrated development environments (IDEs) or debuggers feature simple performance measurement tools that measure minimum, maximum and average execution times.

Measuring Execution Times

Submitted by rapita on 15 June, 2011 - 12:47

In previous blog posts we defined the concept of execution time [see Explaining execution time and The difference between execution times and response times]. In brief the execution time is the time spent actually running a thread, and not time spent executing other threads.

Now it is time to consider how to actually measure execution times.

Software Optimization Techniques #18: Summary of Techniques

Submitted by rapita on 2 June, 2011 - 14:56

The final blog post in our series on optimizing embedded software with the aim of improving (i.e. reducing) worst-case execution times summarises the techniques outlined in previous posts.

Software optimization techniques which improve worst-case execution times #18: Summary of Techniques

In this series we’ve looked at a variety of techniques for optimizing worst-case execution times, giving quantitative results. Here is a summary of the techniques.

Pages

Subscribe to RSS - rapita's blog