Easy enough to imagine. Something improperly was judged to not need concencus, running the calculation twice, or some other software mitigation. Revise process to include mitigation.
"just run the calculation twice. surely the darned solar radiation will take care not to hit random parts of the memory or any critical registers in the cpu"
Best explanation I've seen (and claims to be from a published but not public report on it), is that their 3 way consensus didn't smooth over repeated wildly wrong outputs correctly. Concestency problem strikes again.
Original 1984 critical hardware: the box has an EEPROM module, you swap it on the plane.
FMS (which requires monthly nav data updates) and all modern hardware: the box can be updated over the ARINC 429 serial bus or Ethernet (newer systems/planes), called dataloading
Dataloading had different methods. A320s through the 2000's, most airlines had a 3.5 floppy disk drive on board (Airbus FDDU), and a mechanic fed floppies in. It was slow. Evolution of that was a USB port that took a flash drive.
Most current planes of older models just got rid of on-board dataloading. The mechanic uses a laptop with a cable or purpose-built tablet and plugs into a port. The mechanic can download the software via Wi-Fi or cellular onto the device: https://www.teledynecontrols.com/products/hardware-systems/p...
Airlines can indeed buy a on-board box that connects to Wi-Fi and LTE at the gate which downloads software. This is standard for the latest models that produce more data (A350, 787), but optional for older models. The mechanic still needs to go to the plane and push the buttons to tell it to load.