Possibility of update of spacecraft’s computer software is a “must-have” feature. It may save vessel mission, improve spacecraft capabilities, gives better flexibility with choosing start occasions and many, many more benefits. Without software update there is no chance to recover from errors made by development team. The brutality of “production environment” is going to show weaknesses of the software which were missed during the development phase. Even though the project has introduced all top solutions to ensure quality and made hundreds of hours of specialized simulations and test sessions, it is still sure unpredictable situation will happen, and changes in the software become required.
Spacecrafts software update
Important thing is that after spacecraft is thrown into space, then possibilities of any rescue action are highly reduced. If update mechanism fails and moves on-board computer into incorrect state (e.g. new firmware doesn’t start), then repairing of this situation may be very difficult or even impossible.
It is also problematic to deliver new software to spacecraft. Time window when transfer is possible may be very narrow, possible transfer rates may be low and latency maybe high. Spacecraft may be prepared to works rather as a data sender, and to force it to receive data may require to switch it into special state in which its capabilities may be reduced.
Good update mechanism
Beneath I present properties of upgrade mechanism, which are in my opinion necessary to ensure that upgrade procedure will be reliable and safe.
Only two states after finishing upgrade procedure should be possible: the system works with a new version of the software, or system works with the old, unchanged version of the software. It means if anything fails during upgrading, then the system will back to the old state. It should be forbidden to allow for partially upgrade e.g. some components are upgraded, and others not and we need to take additional actions to fully upgrade the software. Although upgrades between versions are tested on Earth it is impossible to predict all situation which may happen during changing software in Space. If the process of the upgrade will not finish completely, then we got software in the uncertain, and untested state, so it is better to back to complete old version which is well known.
Atomicity is a method to make the upgrade procedure fail-safe – in case of any problem system will back to previous well know the state. It may happen that during the upgrade, the system does not report any problem, but it does not mean that system works correctly. Upgrade software is only a tool to improve spacecraft system, if upgrade procedure is finished without error it does not mean that system was improved and it does not ensure that system was not damaged. Unpredictable fault in the system may cause new version of software to works incorrectly. System correctness test is required. Depends of results of correctness test in the last phase of upgrade the procedure is considered as a success or as a fail (which force system to back to old state).
Computer systems usually have stored persistence data. Configuration data, mission data, databases, logs etc., all of them should not be lost during upgrade. Frequent situation is that persistence data have to be converted to new structure to be still useful with new version of software – upgrade process should execute data migration. Data migration is a complicate thing, software architecture should take this problem into consideration, otherwise it may happen that possibility of system development will be reduced.
It is important to be sure that if the upgrade fails, then already migrated data will back to its original state before the upgrade (e.g original date are restored from a stored copy).
It should be impossible to upgrade the software to unwanted version(not officially released or delivered by untrusted site). Release of software is a process which ensures that delivered software has hi-quality and won’t destroy the satellite system. Unofficially, experimental versions do not guarantee expected quality. The system should discard any tries of upgrading to unofficial version, e.g. it verifies if the software is signed with a digital key. Nowadays microprocessors have a mechanism of secure-boot, which prevent the booting of untrusted firmware.
Upgrade/downgrade to any version
Upgrade system should guarantee the possibility to change from any to any other released version. It means both upgrade and downgrade should be supported, and the new and old version doesn’t have to be consecutively released. It makes problems with data migration, because the structure of data may be completely different between two distant versions.
Process of an upgrade must be logged. In the case of spacecraft, it may be impossible to observe the upgrading process ‘live’. If something fails, then we could investigate what exactly happens in the next communication window, when the system has already back to old software.
Update vs Upgrade
Maybe it is obvious for native English speakers, but personally I had a problem with distinguishing update from an upgrade. Looking into the Oxford dictionary:
Upgrade: Raise (something) to a higher standard, in particular improve (equipment or machinery) by adding or replacing components.
Update: Make (something) more modern or up to date.
Per my understanding, in case of software, the upgrade will change kind of software version e.g from a free version to pro version. Update only change the version number of currently installed kind of software e.g from free version 2.0.3 to free version 2.0.4. It is important to have correct and consistent naming in the code, so I use ‘update’ word when creating functions/classes which service software update for satellite when only one kind of version is present.