Century Support: Why long-term care is a real problem

In this guest article by Carsten Pitz is about a topic that has become highly topical in recent years: how do you ensure that a product can be maintained over its entire life cycle if this is measured in decades? A period of one hundred years - i.e. century support - is not so far-fetched.
I have heard of enough examples over the years where this is a major problem. From train control systems where defects were only discovered decades later and signaling systems that have to be operated in a reduced mode because a (software) repair is not profitable due to a lack of information.
Enjoy reading the first part on a topic that is becoming increasingly important in today's fast-paced world.
Guest article by Carsten Pitz: Motivation (Part 1)
Century Support: This means product support for a hundred years - or more. To show why this is even necessary, I would like to give you an example from my product environment. It was about a S1000D based IETD system. IETD stands for interactive electronic technical documentation, and S1000D is an international specification for the production of technical publications.
In 1999 and 2000, as an architect and senior developer, I created the technical concept for the IETD system and managed the development of the prototypes. My employer at the time was a small systems consultancy with around 100 employees. We were geared towards project work and had neither suitable employees nor the infrastructure to maintain a product in the long term. Accordingly, the prototypes and development documents were handed over to the customer in 2000, who then commissioned another company to develop them further.
By 2002, the first pilot projects were using the IETD system productively. Our concept had worked, the customer was satisfied. And then things went quiet for a few years.
In the meantime, the customer had already documented over 400 systems with the IETD system. These included systems with a very long service life. In 2009, the customer approached us with a request to create a concept to ensure 50+ years of product support. The 50 years was the official statement, but the customer made it clear to us that they wanted a concept for unlimited support.
Officially, support was required for 50 years, but what was actually wanted was support for an unlimited period Officially, support was required for 50 years, but what was actually wanted was support for an unlimited period
The S1000D is a documentation standard from the Aerospace. It originates from the AeroSpace and Defence Industries Association of Europe (ASD) and has been adopted by the Aerospace Industries Association of America (AIA) and the ATA e-Business Program. However, our customer has not exclusively documented airplanes with the IETD system.
The life cycle of aircraft
Why such a long support period is needed at all will be shown using the example of the life cycle of aircraft:
Airbus A300
| 1972 | Development of the Airbus A300 began in 1972. |
| 2007 | The Airbus A300 was produced until 2007. |
| 2040 | According to current planning, the Airbus A300 is to be maintained until 2040. |
| 78 years | That makes a life cycle of 78 years. |
Boeing B-52
| 1946 | Development of the Boing B-52 Stratofortress began back in 1946. |
| 1952 | The first flight took place in 1952. |
| 2044 | According to current plans, the Boeing B-52 Stratofortress will be maintained until 2040, just like the Airbus A300. |
| 98 years | That makes a life cycle of 98 years. |
Well, 98 years of life cycle rounded up a little results in 100 years of life cycle, and thus the Century Support. That corresponds to about four generations. Have you ever discussed this with your great-grandparents?
Century support is comparable to a discussion with your great-grandparents [tweetthis]Century support is comparable to a discussion with your great-grandparents[/tweetthis]
Four generations mean changes of both a technical and social nature. How does that work? I am aware that many people see the cut here as mean, as a cliff-hanger. But this cut is neither mean nor a cliff-hanger, as it gives you a month to think about it: How would I approach this? I look forward to hearing your opinion in the comments section.
Image: Bigstock







Thank you, Carsten, for bringing this to everyone's attention. Many people in IT industries and a few people in the systems industries don't know about this, but it is a serious concern for quite a few people. I remember working with a team, about 10-15 years ago, that still had to maintain software written in the early 1960’s (in FORTRAN).
This is something that is recognized at the Eclipse Foundation though its Long Term Support (LTS) Working Group - and PolarSys (Eclipse's Systems Working group) is a member of LTS.
Hi Charles,
I got a bad cold, so my answer is late.
Some time ago I noticed an 80 years number as a PolarSys LTS requirement. Is this number still in discussion?
/Carsten
Hi Carsten,
PolarSys provides both Eclipse's LTS (0-10 years) and VLTS (Very Long Term Support 10-50 years) services to its members. Note that VLTS supports assumes the availability of virtualization technology. For longer term support, one would have to discuss their requirements with the Eclipse Foundation's LTS Group steering committee, who is responsible for defining the length of the offerings. The PolarSys working group, being a member of Eclipse LTS, uses the defined offerings.
This initially seems to be a question of the business case. So: Which insurance company would agree to take out a contract for 100 years? My guess is none.
Only a forest owner who knows that his „product“ is tied to a generational contract can have a say here. Fortunately, forests with a 5-year term do not yet exist.
The issue of intergenerational knowledge management is therefore primarily a cultural, legal and therefore also a political problem.
I know the problem in a modified form. In plant engineering, there are certainly machines that have been in productive operation for 20 - 30 years or even 40 years and naturally require software changes from time to time. If you know in advance, you can take precautions. But at some point the last byte will definitely be changed, at the latest when there is no longer a functioning programming device for the 3-voltage EPROMs. Then only function replacement and partial refit will help. But the machine itself can still be operated. IT specialists always look at me in disbelief at such lifetimes.
If some IT people knew how old some of the infrastructure they use every day is, they would call it that. Some DSL (digital subscriber line) still uses oil-paper coated copper cables that our grandfathers buried. The power supply is usually no younger either.
/Carsten