Prepping for food shortages

[Pat "5mph"]

If you do have your own generator, presumably you would have to be able to disconnect your house from the grid. Or maybe have a different circuit. How does it work in hospitals? You'd think hospitals would have a lot of sensitive equipment that needs its power just so.

We have a mega back up generator, mega as it's the size of a small building.
The hospital I work in is small, I guess larger ones will have several back up generators.

Anyway, back to food shortages: today I friend (she is a chef) gave me a large tub (over a dozen portions) of homemade veg curry.
Food has a way to find me, now I've got 2 freezers and a fridge full of stuff, most of it already cooked.
Plus what's in my cupboards.
I'm however prepping for Christmas baking

 

[Yellow Fang]

We have a mega back up generator, mega as it's the size of a small building.
The hospital I work in is small, I guess larger ones will have several back up generators.

Anyway, back to food shortages: today I friend (she is a chef) gave me a large tub (over a dozen portions) of homemade veg curry.
Food has a way to find me, now I've got 2 freezers and a fridge full of stuff, most of it already cooked.
Plus what's in my cupboards.
I'm however prepping for Christmas baking

Your hospital might have a big generator, but if you have a power outage then presumably you have to disconnect from the grid to switch in the power generator. Otherwise your power generator would try to power the whole district and maybe zap anyone trying to fix the outage.

 

[Oldhippy]

The inverter on my boat automatically switches from solar to generator to battery so I'd imagine it is the same.

 

[Yellow Fang]

totally this, we absolutely did tons of work and testing for at least 18months in advance as prep, so that it wasnt a problem because we made sure we fixed it.

but theres a litany of worked examples with time in software code that will do stupid things like lock a supermarket door, especially where alot of the lessons we learnt back then have already been lost, theres that one about the Boeing plane software that must be hard cold rebooted within 6months because if the clock overflows, it reboots the whole electrical system regardless of what stage of flight it is in, which shuts the engines down as the fuel pumps turn off because they dont get a signal from the master system telling them to stay on, and you have had to rely on airline maintenance doing patching and this reboot, always something fun o think about when you sit on a plane jetting to somewhere.

but of course everyone has forgotten Unix ntp rollover date is still there, less than 10 years to go now, followed swiftly by the Unix epoch rollover couple years laer which back in Y2K world was the ah its decades away Im sure someone else will fix it all by then test.

I used to be in a team that wrote and tested software to control jet engines. That sort of software was tested up the aris*. The software librarian would hand each of us a module. We would amend it in line with the diagrams the nice man from Pratt & Witney drew. We would submit the module and someone else in the team would test it. We would test all the paths through the module. When all the modules were tested, they were linked into tasks and the tasks were tested. Then the tasks were all linked together into a build, and blown into a chip, which was put into the an engine controller, and somebody integration tested it for a week on the rig. Then someone had to get the software build signed off by various persons and archived in the software library. Then the nice man from Pratt & Witney went back to Canada and they tested it themselves on a proper engine. Then the process would start again with the next iteration. I expect these days the nice man from Pratt & Witney could do all our jobs using Matlab or Simulink. One of our colleagues on our team was moved to another project when he wrote Ada code for a card that went into some avionics on a military jet. He wrote it with interrupt handlers, but he was told to take them out and replace them with polling. The reason was that the software reviewers from the DRA wanted to be sure that the path through the software was entirely predictable. So they were pretty hot on testing in the avionics industry. Despite all our testing some bugs did get through. All the lines of code were numbered and in one module someone repeated the same last line number. Another person tested the module and tested all the inputs and outputs correctly, but we were not required to test all the internal variables. In this module the internal variables stored their value from iteration to the next, like static variables in C. The last line being numbered incorrectly meant these variables got zeroed, and because they weren't tested the bug was missed. We got our aris's kicked for that. Another problem with our unit, which was not the software team's fault, was that someone misread a diagram and drilled a drainhole on the top of the unit, not the bottom. The board was covered in a water resistant coating, but over the years, water dripping onto the board wore away the coating until it caused a short circuit. During a landing in bad weather with an important person from the DoD aboard, the pilot had to switch off the engine because it was over or under revving. Our company got our aris's kicked for that too, because Pratt & Witney had pointed out that flaw to us years previously, but probably due to a wave of redundancy, it had been overlooked.

*Aris is Cockney rhyming slang for a word I suspect I can't type on this forum. I just looked it up.