Anatoly Levenchuk (ailev) wrote,
Anatoly Levenchuk
ailev

Об единую/ое информационную/ое систему/пространство инжинирингового проекта

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

При этом помним, что репозиторий информационной модели проекта может быть централизованный (думаем об CVS и SVN) и распределенный (думаем о git), дело не в "хранении данных в одной базе данных". Хотя исторически поначалу будет превалировать централизация репозитория, и с этим невозможно бороться. Но нужно помнить, куда течёт речка истории, и почему появился git (по поводу которого спорят до сих пор). Для распределенной по разным юридически независимым контракторам системе управления конфигурацией информационной модели проекта (где "система" в глазах каждого смотрящего) язык как-то сам собой (без знания про system of systems) начинает говорить про "единое пространство", но для описания получаемых пряников этого не нужно.


1. Создать полное и детальное многоаспектное описание проекта, чтобы предотвратить коллизии:
-- объекты, наличествующие в одном описании, отсутствуют в другом (например, не все детальки из чертежа заказаны. Не все насосы из принципиальной схемы есть на чертеже. В планах испытаний только присутствующее в объекте оборудование, но и не меньше).
-- разные физические объекты занимают одно и то же пространство-время (например, балка из одного чертежа проходит сквозь трубу из другого чертежа)
-- характеристики из разных описаний не совпадают (заземленный провод из одной принципиальной схемы является фазой в другой)
-- нет неописанных коллизий со стандартами и нормативными актами (техрегулирование/compliance).

Тут три последовательных этапа:
-- обеспечить хоть какие-то разовые передачи между разными САПР в ходе проектирования (например, чтобы все насосы и трубопроводы из P&ID появились в 3D. Или чтобы в плане производства работ появился монтаж всего оборудования) -- "обмен данными" (data exchanges), "точка-точка".
-- собраться "в модели" полностью хотя бы раз, непосредственно перед сборкой "в металле": коллизии, которые проявятся при "виртуальной сборке" существенно дешевле коллизий, которые проявятся "в металле" и "в бетоне". Символизируется в data handover (моменте передачи данных проектирования на воплощение/сооружение), но не факт, что handover подразумевает "виртуальную сборку" с отловом коллизий, это нужно оговаривать отдельно. Это уже "интеграция данных" (data integration), "все со всеми".
-- переход к "непрерывной сборке" (сборке рано и часто: http://en.wikipedia.org/wiki/Continuous_integration). Появление слов mainline (текущая общая модель) вдобавок к baseline (утвержденная общая модель). Это уже другая парадигма, изменение способа проектирования. В частности, тут есть подзадача интеграции поверочных расчетов (которые начинают приравниваться к рабочим расчётам), и проект simantics показывает, что не все решения, пригодные для интеграции "документов проекта" пригодны для интеграции "динамических моделей проекта".

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

4. Информационная модель пригодна для порождающего проектирования (синтеза, "трансформации модели") -- "возврат буквы А в слово САПР".
-- разводка трубопроводов;
-- расстановка железобетонной арматуры;
-- ...
-- в пределе: автоматизированный синтез всей системы -- и не "из требований", а "в диалоге со всеми заинтересованными сторонами" (ибо требования на старте проекта противоречивы).
Тот же вопрос: начинать можно в рамках конкретных САПР (другой вопрос, откуда берется начальная проектная информация!) и обмена данными, и продолжать до уровня полной связной информационной системы проекта.
Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

  • 58 comments