Obsolescence Management Plan, Как бороться с устареванием компонентов Опции

[syoma]

Вот на этапе индустриализации приспичило мне написать такой себе план - что если производитель A скажет, что Процессор Б больше не будет производиться, на что Производитель C скажет, что типа, либо покупаем мы плату с этим процессором на склад, либо он делает редизайн, а я должен ессно модифицировать свой софт, чтобы оно работало как было. Ни у все такое в этом роде.
Таких компонентов в системе куча, а срок службы изделия 25 лет+. А еще может достать и софт, если какой нибудь Ксайлинкс скажет - переходи на Vivado и неебет, или корку какую в следующеей версии пришьет. Или Open Source Community перестанет поддерживать Linux версии X.X, который, к несчастью, я как раз буду пользовать.

Вот сижу, курю IEC 62402 и думаю, что мне такое придумать, чтобы спать спокойно?

Вроде как есть методы - типа ждать пока не приспичит, а потом думать. Не подходит - можно попасть по срокам моих проектов, если вдруг будет не вовремя. Сейчас просчитываю проактивные стратегии - типа миграция на новый компонент каждые 5 лет, а не ждать пока рак свистнет. Также смотрю на прозрачность технологии - а ля эмуляция старого компонента новым и отделение софта от железа, чтобы верхний софт не переделывать под новую платформу, а только дрова подпилить и т.д. В результате хочу выработать план, чтобы было как можно меньше проблем при минимальной нагрузке на разработчиков по суппорту различных платформ на разных этапах жизни изделия.
В общем много интересного наклевывается, но опыта маловато - поэтому спрашиваю - а есть ли у кого работающие стратегии по Obsolescence - и как решаете такие проблемы в промышленных масштабах?

Собственно проблема касается в основном двух-трех таких компонентов, аналоги которых, наверное, у многих присутствуют в своих системах.

- Плата индустриального формата с процессором Intel Core i7 на борту, без каких либо особенных плюшек. Производитель заявляет минимум 5 лет безпроблемной доставабельности. На рынке с 2011 года. В общем геморрой не обещают, но Intel есть Intel. Есть несколько других производителей плат с такими же характеристиками.
- Плата индустриального формата с Xilinx Virtex 6 на борту, опять же без плюшек. Производитель заявляет EOL в 2021. Знаю - Xilinx гораздо лучше Intel в плане Obsolescence. Опять же альтернативы по платам есть. Знаю, что плата не должна беспокоить очень долгое время.
- И вот такая себе закорючка - мультиканальная плата аналогового ввода с АЦП от Analog Devices и контроллером на Virtex 2 судя по внешнему виду. Уже лет 15 производится на ура. Альтернативы пока не нашел, но работает, сволочь, хорошо однако. Че с ней делать, если снимут с производства, не знаю. Наверное свою разрабатывать.

ЗЫ - переход на другие производители не предлагать. Это не избавит от устаревания а только отсрочит момент. Поэтому разговор именно о стратегии. Возможно разной для разного класса компонентов и в зависимости от различных факторов.

[syoma]

С железом разобрался.
Теперь вопрос за софтом - он тоже может устареть. Вот вдруг перестанет развиваться Linux. Что делать?

[a123-flex]

С железом разобрался.
Теперь вопрос за софтом - он тоже может устареть. Вот вдруг перестанет развиваться Linux. Что делать?

Я думаю, Вы зря себя мучаете этим вопросом.
Linux исчезнет, когда исчезнут линуксоиды, а Бог пока вроде не доносил до нас вестей о готовящихся существенных мутациях человеческой расы.

% распределение людей по типам всегда одинаковое - всегда 16 психотипов - почитайте Юнга.

[syoma]

Я думаю, Вы зря себя мучаете этим вопросом.
Linux исчезнет, когда исчезнут линуксоиды, а Бог пока вроде не доносил до нас вестей о готовящихся существенных мутациях человеческой расы.

% распределение людей по типам всегда одинаковое - всегда 16 психотипов - почитайте Юнга.

Про Линукс это я для примера сказал. Но вот есть живой пример перед глазами, когда надо использовать виртуальную машину, чтобы на ней запускать компилятор, который работает под Windows XP. Компилятор нужен, чтобы поддерживать старые проекты, которые были разработаны еще 10 лет назад. Или надо держать человека за руку, потому что только он знает нужный язык программирования, а другие о нем и слышать не хотят.

Но возможно, если подумать об этом заранее, решение могло бы быть другим? Например выбрать другой язык для реализации, другую операционку, вовремя обновить средства разработки или железо. В конце концов возможно сэкономили бы денег по сравнению с текущим решением.

[a123-flex]

Про Линукс это я для примера сказал. Но вот есть живой пример перед глазами, когда надо использовать виртуальную машину, чтобы на ней запускать компилятор, который работает под Windows XP. Компилятор нужен, чтобы поддерживать старые проекты, которые были разработаны еще 10 лет назад. Или надо держать человека за руку, потому что только он знает нужный язык программирования, а другие о нем и слышать не хотят.

Но возможно, если подумать об этом заранее, решение могло бы быть другим? Например выбрать другой язык для реализации, другую операционку, вовремя обновить средства разработки или железо. В конце концов возможно сэкономили бы денег по сравнению с текущим решением.

Я вообще ненавижу линукс если честно. Но в вопросе кроется и сам ответ - если мы таки решили, что линукс вечен, может быть это и есть решение - разработки опирающиеся на наиболее распространенные open source продукты ?

Правда у открытого сообщества есть свои ньюансы- они довольно странные, и довольно трудные, по части готового продукта (это личное мнение). Я, собственно, за это их и не люблю - меня однажды чуть не убили заказчики, когда в моем проекте ведущим программистом был линуксоид, а он, оказывается за время проекта все 4 раза передумал и переделал, и не доделал ни разу.

Зато это решение удовлетворяет Вашему условию.

ну и вот так тоже надо делать:
http://www.devtopics.com/most-popular-programming-languages/

[syoma]

Я вообще ненавижу линукс если честно. Но в вопросе кроется и сам ответ - если мы таки решили, что линукс вечен, может быть это и есть решение - разработки опирающиеся на наиболее распространенные open source продукты ?
Правда у открытого сообщества есть свои ньюансы- они довольно странные, и довольно трудные, по части готового продукта (это личное мнение). Я, собственно, за это их и не люблю - меня однажды чуть не убили заказчики, когда в моем проекте ведущим программистом был линуксоид, а он, оказывается за время проекта все 4 раза передумал и переделал, и не доделал ни разу.
Зато это решение удовлетворяет Вашему условию.

Будете смеяться или нет, но это и есть один из вариантов решения проблемы устаревания ПО, описанный в IEC 62402. Правда, там рекомендуют использовать "коммерциализированные" версии Open-source софта, чтобы была хоть какая-никакая гарантированная поддержка.

Мой вопрос был - как это в реальности сработало или работает. Но, похоже, на этом форуме мало кто с этим сталкивался, или может быть не в том разделе спрашиваю. Неужели никто с какого-нибудь 8051 не переходил на AVR или PICи чисто по причине снятия с производства?