Problems with the Dreamliner battery

[anorlunda]

Not sure about never touching it. Look at the Linux kernel. It could very likely be one of the most complex software codes out there. But bugs are still getting regularly fixed. And Linux kernels get eventually used in many fairly critical tasks.

That's a different scenario. If Linux was used for a critical task, and if it had not been touched for 10 years, and if nobody today had experience changing Linux in the past 10 years, would you change it then?

 

[rollingstein]

That's a different scenario. If Linux was used for a critical task, and if it had not been touched for 10 years, and if nobody today had experience changing Linux in the past 10 years, would you change it then?

The Linux kernel gets already used for critical tasks. Well, depends on what your definition of critical is. Not where Real Time OSs are needed but Critical tasks nevertheless.

The "not touched for 10 years" point I agree with you. But will codes like the aircraft software go untouched & unmaintained for 10 years? Is the source really as ill-documented as you mention for nuclear industry codes?

Software engineering in the 1960's was a totally different beast than when the Dreamliner codes got written.

 

[anorlunda]

The Linux kernel gets already used for critical tasks. Well, depends on what your definition of critical is. Not where Real Time OSs are needed but Critical tasks nevertheless.

The "not touched for 10 years" point I agree with you. But will codes like the aircraft software go untouched & unmaintained for 10 years? Is the source really as ill-documented as you mention for nuclear industry codes?

Software engineering in the 1960's was a totally different beast than when the Dreamliner codes got written.

Good points. Time will tell.

But eventually, someone will notice that most Dreamliner bugs found in service result from the most recent software changes, and that someone will blow the whistle. Think of incidents such as the recent nationwide outage at Starbucks. Consider the risk-benefit ratio if auto manufacturers broadcast updates to all those embedded microcontrollers in cars. When things run well, there are strong incentives to leave them alone.

I would be interested to hear how many embedded Linux apps run with the software initially installed (perhaps burned in ROM) and never updated. I have a GPS chartplotter on my vessel that fits that description. It's function is pretty critical.

 

[rollingstein]

But eventually, someone will notice that most Dreamliner bugs found in service result from the most recent software changes, and that someone will blow the whistle. Think of incidents such as the recent nationwide outage at Starbucks. Consider the risk-benefit ratio if auto manufacturers broadcast updates to all those embedded microcontrollers in cars. When things run well, there are strong incentives to leave them alone.

I would be interested to hear how many embedded Linux apps run with the software initially installed (perhaps burned in ROM) and never updated. I have a GPS chartplotter on my vessel that fits that description. It's function is pretty critical.

I think purely aesthetic patches will be frowned upon. Or patches that add marginal functionality. But what about known bugs & the resultant bug fixes? Often a bug fix can trigger an unintended, unanticipated disaster.

What's the empirical observation, though? Are most inconvenient / massive bug-related-down-times the result of proximal updates?

Given the combinatorically large number of states a complex software can be, isn't it about as likely that a bug latent since inception gets accidentally triggered at some later time just by pure chance leading to disastrous consequences? Without being the result of any new updates really.

Ergo, is ROMing critical software & never updating it a better option in practice?

 

[donpacino]

Stole this from a comment elsewhere but sounds most plausible:

"248 days == 2^31 100ths of a second. even in 2015, our airplanes have integer overflow bugs "

A few things to consider about aircraft control computers.
There are independently reset-able paths usually using dissimilar hardware. Resetting a CPU or event an entire board will barely effect system operation.

Most electrical systems on a modern airplane reset once or twice a flight due to single event upsets (SEUs).

 

[rollingstein]

A few things to consider about aircraft control computers.
There are independently reset-able paths usually using dissimilar hardware. Resetting a CPU or event an entire board will barely effect system operation.

Most electrical systems on a modern airplane reset once or twice a flight due to single event upsets (SEUs).

Very interesting. In this context when you talk about an electric system resetting itself what is the smallest resettable unit? e.g. when a SEU happens how large is the system that gets reset?

Or when you talk about resetting a Dreamliner CPU, how many CPUs are on board in the first place?

 

[donpacino]

Very interesting. In this context when you talk about an electric system resetting itself what is the smallest resettable unit? e.g. when a SEU happens how large is the system that gets reset?

Or when you talk about resetting a Dreamliner CPU, how many CPUs are on board in the first place?

So a single flight computer system is typically made up of multiple boards. You can typically reset on a box (multiple boards), board(multiple functions), or function level. examples of functions are com channels, watchdog channels, and flight mode channels. You can sometimes even reset individual memory blocks (which will most likely disable that entire function for that frame). I would say the smallest electronic system you can reset is a function.

I don't know the dreamliner's architecture, but think of it this way. If there are 3 redundant paths in each computer, and you have say 8 actuators computers, 2 mission/flight computer, at a minimum you'll have 30 flight critical cpus. I would say that's a LOW estimate.

 

[rollingstein]

You can typically reset on a box (multiple boards), board(multiple functions), or function level.

box & board resets I can understand but what does a function level reset mean? Or even a memory reset. i.e. If you reset memory how do you get a coherent state for the OS wherever it was last before the reset? Ditto for a function reset. A function is a software entity right? So this would be a soft reset?

 

[donpacino]

box & board resets I can understand but what does a function level reset mean? Or even a memory reset. i.e. If you reset memory how do you get a coherent state for the OS wherever it was last before the reset? Ditto for a function reset. A function is a software entity right? So this would be a soft reset?

I shouldn't have used the word function. By function I meant a 'block' or a circuit that preforms a particular task. An example of this is on a typical PC if you had the ability to reset the hardware (not the software) of an individual usb port.

with the memory reset issue you may need to restart the OS or some higher level function depending on what part of memory was affected. In flight critical applications all or most memory is partitioned for specific use. Even then, the reset times for most systems are not that long (hard resets are anywhere from 10 ms to 200 ms). software can be much longer (seconds). But compared to windows operating systems, its blazing fast

 

[rollingstein]

Are the single event upsets so much more often due to the altitude of flights & related increase in energetic particle bombardment?

 

[donpacino]

Are the single event upsets so much more often due to the altitude of flights & related increase in energetic particle bombardment?

I don't know that much about SEUs. I know what they are. I know how they effect electronics. I know that the thinner the atmosphere, the more prevalent they are.

 

[rollingstein]

I don't know that much about SEUs. I know what they are. I know how they effect electronics. I know that the thinner the atmosphere, the more prevalent they are.

How come they don't cause laptops or similar electronic devices that have no special protection against SEUs to keep crashing when used on aircraft?

 

[nsaspook]

How come they don't cause laptops or similar electronic devices that have no special protection against SEUs to keep crashing when used on aircraft?

The sensors, wiring and interfaces are exposed to high energy transients from power control activators and hull discharges from static. A person sitting at a seat is usually well shielded by the cabin and are far away from most EMI/ESD sources.