>A simple guess suggests the the problem is a signed 32-bit overflow as 2^31 is the number of seconds in 248 days multiplied by 100, i.e. a counter in hundredths of a second.
The question that comes to my (perverted) mind is what is the counter for, or more strictly why it needs an accuracy of 1/100th second?
If it is related to a "periodical" action (a time interval) it makes little sense to have that degree of precision, and on the other hand, if the precision is needed, why not calculate it from a base point?
I mean, if it is related to "boot" time, I presume that noone would ever use a counter, rather a log of some kind with a timestamp and calculate (properly) the time elapsed ...
If the clock is being used for real-time dynamic model propagation, the 100 Hz speed is enough the capture the physical phenomena in the system, such as control system response. 10 Hz is a bit too slow, and 1 kHz is overkill.
During my graduate work in aerospace engineering, 100 Hz was pretty much standard for sensor filtering and simulation work.
The systems are controlling generators, which produce AC current. It's not unreasonable to think the controllers are monitoring the AC waveform, which has a frequency of 50-60Hz. Ergo, if the controller is checking the generator is producing the expected waveform (because a lot of sensitive things depend on the waveform being accurate), it makes sense that it could be using a 100Hz polling interval, which is where the counter comes into play.
It's possible that it's using a system-wide timer for convenience since the embedded hardware is very limited compared to a full computer, where spinning off a separate timer is trivial. When the requirement for different timers hit the program designer's desk, they probably took the most precise use case and designed one timer around it, and neglected to take into account the overflow.
Yep, but purely anecdotal data, I once was involved in the construction of a (small) hydroelectric plant (I was responsible for the construction/building, not for the electrical parts, our construction company had a couple electric partners for that).
For some reasons the tender was for the building and plant, but the client made a separate tender for the actual turbines.
Though I tried (vainly) to convince the manufacturer of the turbines to use a controller from the same firm we had as partner, they decided to use "their" way.
In theory not a problem as the turbines and their controllers would "talk" to the external control system (SCADA, etc.) through a "standard" RS422 connection.
After a couple days of testing, it was clear that the SCADA was going periodically "beserk".
Though not at all my field/responsability, I was willing to have the problem solved and after 3 (three) days of the engineers from the turbine manufacturer and from the control system manufacturer finding nothing (and BTW largely failing to communicate between them) I started looking with them, one by one, at the signals that were exchanged on the connection.
It was evident that there was some form of overflow, the on-turbine controller sent way too many data and "clogged" the receiving part.
There was a sensor for rotation speed and another one for oil pressure that were polled (and sent data) at a rate of 1000 per second.
The turbines were of the Pelton type, with an external (large) flywheel, and it took (literally) tens of seconds since you stopped the waterflow to have the actual wheel slow down and after several more tens of seconds stop, and viceversa once it got to the intended speed, it had in practice no variation.
So you had these two sensors polled 1000 times a second to measure something that would change - maybe - only after several seconds intervals and that could be as well corrected with a delay of tens of seconds.
Reducing the polling rate from 1000 to 10 times a second (still way overkill for the proper functioning of the system) all errors went away.
It came out that these sensors were a new type/make/model, the first to be capable of Khz polling, and the turbine engineers set them to the max only because they could.
Aircrafts operate at 400Hz to reduce the size and weight of transformers, motors and power supplies. Its less efficient than 60Hz, but planes aren't that long anyway.
Anectdotal like my brother, an interactive inverter product I developed sampled the 60hz voltage and current at 19.2khz to more accurately determine RMS voltage and current in the face of some really nasty distortion. It was probably overkill but another guy on the team who worked on revenue-grade watthour meters thought it was just fine.
I'd assume the software is not event driven but cyclical. In each cycle you gather inputs, compute, produce outputs. You need a cycle counter because event validity and response time limits are likely defined in terms of cycles (e.g. peripheral sensor A has to report at least once every three cycles or sound alarm). Bad things happen when the cycle counter overflows.
At the very least, the HUMS and CV/FDR systems need sub-second precision for maintenance and crash investigation reasons.
As for why they don't calculate it in a particular way, probably just an amateur mistake.
Lots of aerospace-related applications are moving towards the methodology where you cook up a model in matlab and then hit the AutoCode button. Things like this are the reason why.
>A simple guess suggests the the problem is a signed 32-bit overflow as 2^31 is the number of seconds in 248 days multiplied by 100, i.e. a counter in hundredths of a second.
The question that comes to my (perverted) mind is what is the counter for, or more strictly why it needs an accuracy of 1/100th second?
If it is related to a "periodical" action (a time interval) it makes little sense to have that degree of precision, and on the other hand, if the precision is needed, why not calculate it from a base point?
I mean, if it is related to "boot" time, I presume that noone would ever use a counter, rather a log of some kind with a timestamp and calculate (properly) the time elapsed ...