Обсуждение

поделитесь презентацией, если можно

Вступайте в INCOSE, и пришлю (для вступления платить кредиткой $105 тут: http://incose.org, указать Russian chapter при вступлении).

Не могу удержаться - в телевизоре сидит президент, и говорит русским языком, что в цифре у нас конечно сделан уже самолет Сухой Региональный, но это новый самолет... А вообще нам бы надо и все старые наработки перевести в цифровые модели... Вот например украинский Ан-148 мы собираемся делать вместе, и его бы в первую очередь... НА ЦИФРОВЫЕ МОДЕЛИ...!!!! Это у ИНКОСЕ филиал в Кремле открылся, что ли??? И пусть глюпые "менеджеры" говорят, что у модернизации, инноваций и "регулярного менеджмента" нету ресурса. Он есть! Просто надо уметь вытаскивать и приватизировать себе политический ресурс самого высокого уровня, как бы страшно это ни было делать. Метод номер раз: публичить. Публичить по всем каналам, что вот тут есть такие инициативы, что мы делаем то-то и то-то, и со ссылками на верхние высказывания. Рано или поздно ресурс сработает.

Про порождение конструкции согласно намерению был у меня в прошлом ноябре некоторый спор о том, что это алгоритмически возможно http://sergeyvi.livejournal.com/21487.html. Считаю, что его выиграл, правда, в дискуссии стало понятно, что главный вопрос, как обычно, не то, возможно ли это алгоритмически, а вопрос источников - из чего порождать http://alexsword.livejournal.com/41841.html?thread=11452529#t11452529. Нет необходимой открытой инфраструктуры, хранящей прототипы и элементы, по сути именно ее нужно создавать (в т.ч. возможно на базе iRing-ов и иже с ними), а вместе с ней и систему отношений, которая позволит зарабатывать не на сокрытии, а на раскрытии информации http://sergeyvi.livejournal.com/23559.html, чтобы не быть в позиции догоняющих.

Да, iRING и каталоги продукции именно про это. В этой сфере сейчас много чего происходит.

А я (как понимаю, моя позиция всем остальным кажется экстремистской) считаю, что нужно уже сейчас думать о том, как от простой "виртуальной сборки" и "подтверждающего моделирования" переходить к порождающему проектированию (generative design), "порождению конструкции согласно намерению". Позиция очень даже конструктивная, ибо чтобы завтра заниматься порождающим моделированием, думать об этом надо уже сегодня.

Теперь про конструктивность моей позиции нужно объяснить всем остальным :)

Меня смущает тот факт, что каталоги продукции, даже когда речь идет о моделеориентированных вариантах, практически не содержат общих моделей, начиная с которых, путем например, поиска решений, который я описывал в том споре, позволяют синтезировать конструкцию. Все то, что я видел, скорее направлено на то, чтобы получить удобное для инженерного решения описание (например, чертежи или 3D-модель - в основном для упрощения продажи устройства), но практически никогда не видел выложенную модель работы устройства (ну например, удобную для интеграции потоковую или сеточную модель). Есть ли уже решения, которые позволяют строить сети моделей работы устройств, чтобы можно было как из лего, собрать например, двигатель внутреннего сгорания новой конфигурации, и посмотреть, например, где и как он будет греться?

Про порождение конструкции согласно намерению был у меня в прошлом ноябре некоторый спор о том, что это алгоритмически возможно Ну то что это возможно алгоритмически, это понятно. Проблема в другом, надо еще такую систему заинженирить. Т.е. чтобы она была технологичной, экономически выгодной, в сравнении с ручным порождением. Причем понятно, что это когда-то будет сделано, вопрос доживем ли мы до этого? :) Скажем, тесты я генерю уже лет 15 - это очень технологично. А вот с чем-то другим уже сложнее. За эти 15 лет приличного инструментария широкого профиля так и не появилось. Хотя может где-то и есть, просто я не в курсе. В основном, это какая-то ботва вокруг UML.

Ну тут какбы разделение труда :). Обе позиции правильны: надо и текущие результаты иметь и о будущих задумываться. Я вот для себя не могу определится, что представляет определенную проблему по жизни :)

Я уже приводил ссылку на обзорчик (Stephen Fox, Generative Production Systems for sustainable product creation, 2009, http://www.vtt.fi/inf/pdf/workingpapers/2009/W129.pdf).

Скайнет уже не за горами. в Последнем терминаторе на мой взгляд один из лучших на сегодня примеров порождающего проектирования ))) если не брать негативный остаток...

Ну с теорией-то все понятно. Абыдно, что за 15 лет ничего практичного даже в софтовой сфере не возникло, хотя оговорюсь, что все-таки может я плохо искал. Такое впечатление, что все усилия сконцентрировали на какой-то фигне вроде UMLя. Хотя опять-таки может я что-то не втыкаю. Но с другой стороны, есть ведь и обнадеживающие примеры. Подумал о примерах, и понял, что все примеры так или иначе касались моей любимой верификации :). Но это не спроста. Дело ведь в том, что все могучие идеи они как обоюдоострый меч - можно ведь порезаться и нагенерить хрен знает что. А в крупных проектах много усилий уходит именно на тестирование (до 80%). Т.е. если нагенерить кучу артефактов, то их замучаешься тестировать. Это кстати видимо основное ограничение для использования продвинутых подходов в софте типа АспектДж и т.д. И кстати, именно поэтому всякого рода тестирование выгодно автоматизировать. Ведь моделирование с целью найти коллизию на компьютере и есть такое тестирование. Т.е. на первых этапах оно все и идет в соответствии с моим опытом (софтовым). Но чтобы сделать следующий шаг, и порождать дизайн, нужно быть уверенным, что дизайн будет удовлетворять требованиям (которых дофига). А тут очень важно применять верификации. Например, верифицировать что процедура генерации соблюдает какие-то свойства. Чтобы порожденный дизайн можно было верифицировать на соответствие различным требованиям. Вобщем, меня посетила идея, что для промышленного внедрения нужно порождать proof-carrying артефакты. Которые бы можно было автоматически верифицировать на предмет критичных и важных для заказчика свойств. Тут кстати надо отметить, что производство микросхем широко основано и на порождениях и на верификациях. Т.е. дизайнеры-то работают на высоких уровнях, а потом это транслируют на более низкие (в несколько этапов). Ну и на фабриках есть спец софт для проверки их требований. Ну и т.д. и т.п.

Вобщем, меня посетила мысль, что производство микросхем-то глубоко моделе- и порожденческо-центрично :). Ну и более-менее системно :).

Конечно: кремниевые компиляторы они именно про это "порождение" были (я, кстати, любое порождение считаю выполняемым "компилятором", или как говорили раньше, "текст программы компилятор исполняет в особом смысле"). Поэтому-то у нас в компьютерах по сравнению со строительством такой прогресс и случился. Хотя с небоскрёбами наметился уже прогресс и в строительстве, не в последнюю очередь именно из-за применения порождающего проектирования в современных строительных САПР (они этим сейчас дико хвастаются). Но в целом -- техника и методы уже созрели, а мозги разработчиков (и, соответственно, венчурных капиталистов) еще нет. Думаю, будет буквально взрыв в ближайшие годы, только под разными другими именами (типа "автоматическая разводка трубопроводов" и т.д.).

Как раз сейчас обдумывал мыслю, что венчурные капиталисты такое финансировать не будут :). У них есть огромная куча менее рисковых проектов для инвестиций, так что я не верю, что венчурные капиталисты будут тут инвестировать. Вот фонды типа DARPA и аналогичные европейские финансируют подобные разработки. И это очень выгодно, только горизонт инвестирования у них совсем не два-три года, а лет 25.

В инженерии такая верификация называется assurance case. Но я согласен: методы формальной верификации главным образом получили распространение именно в дизайне железа, эти методы вошли в состав кремниевых компиляторов как неотъемлимая часть. Как я понимаю, сейчас порождающие системы в CAD просто "генерируют по правилам", а сгенерированный ими код соответствует правилам "в силу того, что он сгенерирован по этим правилам" ;)

Да-да, последнее стремно :). И вполне справедливо вызывает недоверие. Ведь всю эту нагенеренную кучу артефактов надо проверить. Т.е. нужно строить мостики от требованиям к правилам. Т.е. сгенерированный по правилам код, должен соответствовать требованиям. А вот формулировка этих требований - сама по себе нетривиальная задача.

"порождению конструкции согласно намерению". Почему профессиональные программисты категорически избегают моделировать жизнь человека и свою? Заранее знают ответ? Почему моделированием человеческого поведения и биополитическим моделированием приходится заниматься программистам-любителям? Если связать биологию и наноэкономику(экономику физического лица)то всё становиться измеряемым. Профессионалы - математики, тоже говорят, что не знают, почему все избегают просчитывать жизнь отдельного человека. Избегание идет на уровне подсознания. Может у Вас есть ответ? Клуб "Биополитика" МГУ