Friday, January 7, 2011

Really long term support

Recently, I began working on building the MeerKAT radio telescope and
possibly also the SKA radio telescope if South Africa wins the bid. There is
a whole variety of analog and digital hardware running or planned for this
telescope as well as quite a bit of software, with major part being written in
Python.

One of the major requirements, which is quite different than anything I have
worked on so far, is the lifetime of a telescope - something in range of 20-30
years from the time of commissioning (not from the time when decisions were
made). And this is not a fire-and-forget project where you just want software
to work over the entire lifespan: software as well as hardware will be updated
to take advantage of new available technologies. Nevertheless some pieces won't
or can't be updated and they'll have to stay operational anyway.

This leads to certain restrictions and requirements on software being written.

First is that the software (either written in-house or written by a 3rd party)
has to be maintainable. It doesn't have to be maintained, but it has to be
maintainable by in-house team in case some obvious bug appears late in
development.

This usually means that not only should source code be available (open source is
a plus, but not necessary), but also full revision history as well as unit
tests have to be present. One example here is Python. Even if we stick to
Python 2.x, for which the end of life is scheduled somewhere less than 30 years
from now, it still has source, tests and history so at worst it can be
maintained if needed (and if we stick to it, which is unlikely).

One very worrisome example here is Flex, which is used by the telescope GUI. If
adobe stops supporting flex (there's no reason to believe they'll support it for
30 years), we're stuck with GUI running only on old machines, and spare parts
for those machines will be increasingly hard to get.

Another important part is open standards for inter-device communication.
Fortunately this is a no-brainer, since for most part devices speak katcp
protocol already, which is well documented and has open source implementations.

Does anything else come to mind?

Cheers,

fijal