Possibility of update of spacecrafts computer software is a “must have” feature. It may save vessel mission, improve spacecrafts 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. Brutality of “production environment” is going to show weaknesses of the software which were missed during development phase. Even though project has introduced all top solutions to ensure quality and made hundreds 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: system works with new version of software, or system works with old, unchanged version of software. It means if anything fails during upgrading, then system will back to old state. It should be forbidden to allow for partially upgrade e.g. some components are upgraded, and other not and we need to make 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 process of upgrade will not finish completely, then we got software in 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 state. It may happen that during upgrade, system do not reports any problem, but it does not mean that system works correctly. Upgrade software is only a tool to improve spacecrafts system, if upgrade procedure is finished without error it does not mean that system was improved and it does not ensures that system was not damaged. Unpredictable fault in 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 upgrade fails, then already migrated data will back to its original state before upgrade (e.g original date are restored from stored copy).
It should be impossible to upgrade 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 satellite system. Unofficially, experimental versions do not guarantee expected quality. System should discard any tries of upgrading to unofficial version, e.g. it verify if software is signed with digital key. Nowadays microprocessors have mechanism of secure-boot, which prevent booting of untrusted firmware.
Upgrade/downgrade to any version
Upgrade system should guarantee possibility to change from any to any other released version. It means both upgrade and downgrade should be supported, and new and old version don’t have to be consecutive released. It makes problems with data migration, because structure of data may be completely different between two distant versions.
Process of upgrade must be logged. In case of spacecrafts it may be impossible to observe upgrading process ‘live’. If something fail, than we could investigate what exactly happen in the next communication window, when system has already back to old software.
Update vs Upgrade
Maybe it is obvious for native English speakers, but personally I had problem with distinguish update from upgrade. Looking into 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, upgrade will change kind of software version e.g from 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 create functions/classes which service software update for satellite, when only one kind of version is present.