Память MRAM (http://www.mram-info.com/)Впрочем, все эти технологии приведены только как примеры -- и при необходимости могут быть заменены другими (так, онтология Gellish вполне может быть заменена какой-нибудь другой, прежде всего ISO 15926 -- хотя это все и плохого качества онтологии. Для такого дела можно и "с нуля" онтологию сделать -- или выпустить апгрейд уже существующих). И так со всеми этими слоями.
Процессор "неконвенциональной архитектруры", аппаратно поддерживающий виртуальную машину COLA и работающий с памятью MRAM -- (http://vpri.org/html/work/ifnct.htm).
Среда мультипарадигмального (функционального, объектного, аспектного, DSL и т.д.) программирования на COLA -- (http://www.vpri.org/vp_wiki)
Крокет, как распределенная мультипарадигмальная операционная среда, обеспечивающая коллаборацию. (http://opencroquet.org)
Онтологическая "шина приложений" -- Gellish и протоколы обмена информацией между приложениями (включая Gellish-запросы) -- (http://gellish.wiki.sourceforge.net/).
Набор приложений с "фасадами" для "шины приложений" Gellish
-- управление вариантами (family engineering) и распределенное хранение версий информационной модели системы/проекта (типа git) с нотаризацией -- синхронизация работ и учет продукционных и координационных фактов: кто что кому когда обещал, кто что кому когда publish сделанного. Протоколы и структуры данных, независимый нотариат.
-- порождающий дизайн (САПРы конструкторские и проектировщиков), включая программы симуляции.
-- организационное моделирование для проекта расширенной организации
-- ресурсы/логистика и финансы для проекта расширенной организации, включая эксплуатацию
-- надежность и риски (ремонты по состояниям) при эксплуатации
-- courseware (документация, задачи, последовательность освоения и т.д. -- не софт, ибо софт уже есть: каждое предметное приложение является еще и учебным софтом, хотя на нем можно решать и заведомо неучебные, т.е. исследовательские и инженерные задачи).
Термоядерная электростанция, сделанная и эксплуатируемая при помощи указанного набора приложений (по факту ITER сейчас использует ISO 15288).
Весь вопрос в том, что в реальности эти все технологии могут быть сами по себе разработаны, но совершенно необязательно выстроятся в стек. Фактически, в (пока абсолютно непромышленный) стек могут быть выстроены только COLA и Croquet, ибо в них обоих заводилой Алан Кей и у Крокета прописаны уже планы в будущем сесть на Колу. Но даже процессорные планы COLA, хотя и подразумевают неконвенциональную архитектуру разрабатываемого ими железа (опять же -- спасибо Алану Кею), не включают в себя изменения архитектуры, связанные с использованием MRAM. Даже САПР в Крокете появился, но это явно не мощный промышленный онтологический САПР, который должен бы быть в данном стеке.
Пофантазируем, что нужно сделать, чтобы такой стек получился (помня при этом, что можно добиться всего чего угодно, если необязательно чтобы лавры принадлежали именно тебе):
1. Решить нерешаемые политические задачи и получить много-много государственных денег на "прорывные НИОКР", затем бездарно их потратить на то, чтобы такой стек получился (законтрактовать все команды на то, чтобы они прицелились друг во друга -- с учетом того, что значительной части команд вообще еще нет, а во многих других случаях речь идет не о командах, а о не пойми чем). По факту, все эти деньги ученые пустят на много-много интереснейших "боковых побегов" для их любимых технологий, но меньше всего на обеспечение вертикального ст
2. Писать прочувствованные письма командам, занимающимся различными слоями стека, чтобы они обратили внимание друг на друга, и договорились. Лично ездить и уговаривать. Разработать презентации, писать статьи с разъяснением взаимной пользы смежных технологий, чтобы поисковые технологии тыкали их со всех экранов в необходимость обратить внимание друг на друга. В общем, поработать свахой. С примерно той же вероятностью результата, что и у обычной свахи. Беда в том, что женихи не имеют плотных очертаний (многих так вообще нет), а также не имеют собственных ресурсов, чтобы вести необходимые работы -- даже если они почему-то и будут друг другом очарованы.
3. Подружиться с венчурным капиталистом и сделать много-много связанных стартапов -- но венчурным капиталистам не нужны взаимные риски всех этих стартапов, им и "прорывность" не слишком нужна, а нужна массовость рынка. Тут же массовостью рынка не пахнет. Насколько я знаю, все крутые САПР и средства их интеграции были сделаны под совершенно конкретные заказы совершенно конкретных крупных фирм, которым нужно было много дизайнить. И уж точно для таких проектов принято выбирать "общепринятые средства разработки", а не "прорывные" (грубо говоря, писать на Java а не Haskell, и уж точно не на COLA).
4. Внедриться в какой-нибудь ВУЗ (например, я знаю, что мой блог читают люди из МИФИ -- почему бы и не туда?), сделать учебные проекты на соответствующих кафедрах -- ибо где еще можно встретить такой зоопарк разных тематик, как не в ВУЗе? Жесткими административными методами потребовать этим проектам сотрудничать друг с другом. Дальше решать задачу, как учебный проект довести до характеристик промышленного. По мере накопления опыта выпускниками и профессорами переходить к стратегии по п.3.
5. Продолжите, плиз, в комментах. Мне интересно.
