Accelerated life testing of microcontroller software?

Hello,

If some software is supposed to do some action 100 days (or so) after being started (ie the microcontroller being powered up) , then how can you test that this action will really happen? (without having to wait for 100 days of software testing to elapse)? :-|
..We have an offline lamp which has dimming software inside it. It is a lamp for people with large gardens. It dims itself as dawn approaches so as to save energy, ..just before it turns off at dawn, it has already dimmed well down (because its getting lighter as dawn approaches). It uses its software in order to gauge the likely duration of darkness in any given night.
No prizes for guessing how this is done…it simply times the time between the light sensor output changing rapidly either up (for approaching dawn), or down (for approaching dusk). It then averages this time over a few nights to gauge what the darkness time duration will be for the next-to-come night. This is the well known “night time length forecaster”, very very well known throughout the world of lighting. :clap:
(obviously you cannot just use a cheap light sensor to gauge the exact darkness level, because light sensors are ridiculously wide in their tolerance).

The lamp also gradually uses more led current as time goes on, in order to counteract the fact that leds naturally get dimmer as time goes on.
We are worried that the software engineer (who lives 1000 miles away from us) has correctly coded these things…I mean, how are we supposed to know that the lamp will have adjusted its led current to the correct level in 1 years time?.. :shock: .i mean, how do you test for that before you ship the product? How do you know that the software that executes in 100 days time doesnt go wrong and just turn the lamp off for good?
Our software engineer says that its all very simple…and that we can do “accelerated life testing”. This is where he simply reduces the timer interval (in the code) by a factor of 100, so that we can test what would happen in 100 days time in just one day.
Is this right?...i mean, this kind of accelerated time testing is genuinely worthy?

Sounds like overkill on a huge scale to me but yes, essentially you speed up the internal timing so events that would normally take a long time to occur are more frequent.

I have a system at home here that turns one set of LEDs on from sunset to sunrise (all night) for outdoor lighting and another set of lights in a swimming pool from sunset to midnight with a one second dip in brightness at 23:55 as a warning of impending darkness. Being in an outdoor swimming pool in total darkness isn't a good idea! It adapts switching times to the date and latitude/longitude and observes DST/BST clock changes on the appropriate dates. It's been working perfectly for years except for slight clock drift which requires resetting it about once every three months. I built an MSF interface into it to keep the time accurate but never got around to building the receiver!

Brian.

Go to debug mode and change value of timer to force it start asap.

I think you have to cut apart the problem into two pieces.
There's the "takes forever to hit the code branch" problem
and there's the "hardware drifts, how does software react?"
problem.

The latter, you can go after by imposing "aged hardware"
test cases. Up the load current, by adding a shunt that
emulates that; what else? You should have endpoint
electrical limits for components and could do a bit of work
on what represents a credible worst case for all of the
"care-abouts" that the article under test, would see and
have to deliver.

Sounds like software boy is talking out his a## when it
comes to testing. Maybe he heard of burnin, once.
But software itself has no reliability bathtub curve.
Only failure modes waiting to be revealed (or better,
dug out in a methodical way, but a "software oven"
ain't that).

The concept of increasing the current to compensate for aging without using a live feedback system assumes you can predict the decrease in brightness and how to counteract it. It must add some fixed amount to the current at regular intervals. Given that these intervals are long, maybe several years each, it is improbable that a a hardware timer is being used directly, most likely a software 'post scaler' is used. For example counting 86400 seconds then incrementing a day counter. If that is the case, you should be able to pre-load the post-scaler so it reaches terminal count much sooner. Using the same example, instead of resetting the seconds count to zero each day, set it to say 86340 so it counts one day per minute to accelerate all subsequent timings.

I assume you have the source code to be able to modify it.

Brian.

My suggestion was meant to emulate the eventual increased
current burden for testing in the here and now, not as a design
mitigation for it.

- - - Updated - - -

My suggestion was meant to emulate the eventual increased
current burden for testing in the here and now, not as a design
mitigation for it.