?

Log in

No account? Create an account
Лабораторный журнал -- Day [entries|friends|calendar]
Anatoly Levenchuk

[ website | Лабораторный журнал ]
[ userinfo | livejournal userinfo ]
[ calendar | livejournal calendar ]

Будущее инженерии [12 Jun 2011|03:48pm]
16 июня 2011 я планирую выступать в Нижнем Новгороде на форуме (http://niaep.ru/ru/455/) с лекцией по будущему инженерии. Вот текущий план:

1. Тренд слияния с программной инженерией:
-- software-intensive systems и cyber-physiсal systems как целевые системы;
-- model-oriented engineering (virtual system: testing в компьютере). Подробнее: systems definition -- полностью уходит в компьютеры.
-- generative engineering (порождение инженерных решений в компьютере: knowledge aquisition не для обучения).
-- итоги проекта BKCASE и GRCSE -- образование системного инженера должно включать в себя полноценное образование программного инженера. Это же будет относиться к любой другой инженерии.

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

2. Тренд слияния инженерии и инженерного менеджмента:
-- ISO 15288 из четырёх групп практик только одну содержит собственно инженерную. Остальные -- инженерный менеджмент.
-- ASEM считает, что управление технологиями и системная инженерия являются частью инженерного менеджмента. Не менее половины инженеров получает через пять лет работы менеджерские задачи (результаты опроса ASEM в США).
-- отход от "водопада": collaborative engineering, concurrent engineering, lean и agile требуют особой организации работ. Выбор вида жизненного цикла -- это менеджмент, или инженерия?
-- обратное слияние: enterprise engineering, factory physics

Вывод: инженерию и менеджмент путают уже сейчас, а дальше и вовсе будет невозможно разделить.

3. Тренд экспликации инженерного знания (от инженерного искусства и ремесла к инженерной технологии):
-- системный подход, философская логика в основании (не только математика)
-- исследования инженерного метода (эвристики, в отличие от "научных теорий")
-- ситуационная инженерия методов
-- языки паттернов
-- растёт число reference process frameworks, body of knowledge, method component catalogs по инженерии
-- generative design и manufacturing: пусть думает машина, а мы дадим ей знания

Вывод: то, что сейчас считается искусством и мастерством завтра будет знанием и элементарными навыками, планка искусства и мастерства существенно повысится

4. Новые методы systems definition:
-- модели GORE
-- архитектурные языки (SysML и AADL -- это только начало, онтологические языки -- продолжение)
-- ТРИЗ, DSM
-- имитационное моделирование (расчётные коды)
-- model-oriented engineering и поиск коллизий моделей: PLM и интеграция данных -- с философской логикой в основе (в том числе системные онтологии, позволяющие объединять разные виды моделей). Collaborative design и concurrent engineering.
-- generative design

Вывод: без существенного переучивания старые инженеры просто не смогут работать.

5. Новые методы system realization:
-- новые (композитные, нано и т.д.) материалы
-- additive manufacturing
-- generative manufacturing
-- robotics
-- новая модульность, новая логистика, новая сборка (китайская группа Broad: 15-этажное здание за 6 дней, планы строительства небоскрёба 666 метров высотой за 4 месяца).

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

6. Дополнительные требования и ответственность за них:
-- безопасность круче, чем в естественных условиях
-- окружающая среда: чище, чем сама природа
-- бездефектность: 6 сигма
-- уменьшение роли интеллектуальной собственности

Вывод: изменяющиеся требования меняют само понятие "невозможного".

7. Экспансия на нетрадиционный материал:
-- программная инженерия (это уже "бывший тренд", но он остаётся важным)
-- генная и биоинженерия
-- молекулярные и наномашины, метаматериалы
-- опять же, enterprise engineering
-- продолжаются попытки социальной инженерии (невзирая на критику)
-- подводные разработки ископаемых
-- новая физика (квантовые компьютеры, плазма, пока еще сомнительные LENR и эффект Маха)
-- системы систем (инженерия сверхбольших распределенных систем, основанных на стандартах -- например, интернет)

Вывод: невероятная ранее диверсификация инженерии и инженерных специальностей
12 comments|post comment

Датацентричность и моделе-ориентированность [12 Jun 2011|11:10pm]
Слова "датацентричность" и "моделе-ориентированность" сегодня уже что-то вроде привычных техно-заклинаний. Все хотят "датацентричности" и "моделе-ориентированности" (нет, я не против -- это хорошо, что хотят!), но не очень-то понимают, что это конкретно в их ситуации значит, и какие именно выгоды будут получены. В итоге в презентациях и технических заданиях появляются слова "датацентричность" и "моделеориентированность", но много реже датацентричность и моделе-ориентированность проявляются в реальных системах.

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

"Датацентрическая архитектура" (data-centric architecture), противопоставляемая "документо-центричной архитектуре" -- это указание на то, что система строится на основе приоритета разбирательства с данными, и подчиненной роли информационных объектов (различение информации, данных и информационных объектов -- http://ailev.livejournal.com/908102.html). В датацентрических архитектурах обсуждаются учётные проблемы (раскладка "оригинальных" данных по информационным объектам, находящимся под разным администрированием, а также проблемы, возникающие при управлении конфигурацией данных -- трассировка изменений в данных к изменениям в информационных объектах).

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

Конечно, два предыдущих абзаца определений сами по себе совершенно непонятны и недостаточны. Эта непонятность, увы, не только в их краткости, но и в предполагаемой этими формулировками смене мыслительных парадигм:
-- в датацентричности это учётная парадигма (см. также "вопрошание об учёте", http://ailev.livejournal.com/593013.html), меняющая собой парадигму документирования. Учёт подразумевает позицию регистратора данных, полномочия по регистрации данных, реестры, формирование выписок и т.д.. Документирование всего этого не предусматривает, там просто составляются и передаются документы -- информационные объекты. Переход от "банков документов" к "базам данных" как раз представляет собой сдвиг в сторону датацентричности. Датацентричность -- это даталогическое обсуждение, где важны данные сами по себе (их сбор, хранение, маршрутизация заинтересованным сторонам и т.д.). Содержание данных в датацентричности обсуждается только по сопричастности.
-- в моделе-ориентированности это знаниевая парадигма (аккуратное представление информации данными, отображение возможно только после специальной обработки этих данных для целей представления человеку) против парадигмы документа-как-изображения-для-человека. Подробное разбирательство с моделями данных (например, отдельное хранение имени, отчества и фамилии в базе данных; хранение аннотированных разнообразными атрибутами 3D параметрических моделей в САПР вместо хранения растровых или даже векторных "картинок") представляет собой сдвиг в сторону моделеориентированности. В моделе-ориентированности обсуждение инфологическое: обсуждается адекватность представления информации в данных, но вопросы самих учёта самих данных (сбора, хранения, маршрутизации и т.д.) обсуждаются только по сопричастности.

Путаница появляется в том числе и оттого, что как датацентричность, так и моделе-ориентированность связаны с различными группами описания работы с данными (датацентричность -- как данные раскладываются по информационным объектам, т.е. носителям данных; моделецентричность -- какие именно данные доступны для учёта). И оба этих аспекта (знаний и учёта) противопоставляются простейшим формам работы с документами (где учитываются сами документы, а не данные в них; документы предназначены только для предъявления человеку, поэтому не содержат машинно-читаемых знаний). Важно учитывать оба сдвига парадигмы (учётный/даталогический и знаниевый/инфологический), а не только один. Так, переход к структурированным документам -- это только половина дела. Переход к навороченным (на сегодня чаще всего -- уже объект-ориентированным, а не реляционным) базам данных -- это тоже половина дела.

Вот примеры проблем, которые решаются в рамках перехода к датацентричности:
-- как передать оригинал модели? Так, при проектировании в SP3D содержится полная 3D модель (но только в последней версии!), в SPF уже передаётся неполная модель (.vue файл) и информация о версии модели имеется не для 3D модели, а только для "модели для просмотра". В архив же уходят не модели, а полученные из модели двумерные чертежи. В ситуациях передачи модели другим проектировщикам, восстановление истории (в том числе откаты к предыдущим версиям, или восстановление конфигурации), работа с вариантами дизайна и т.д. возникают огромные проблемы. Нет проблем с учётом в части архивного хранения "выписок из модели" (полученных двумя разными огрублениями -- переход от полного 3D представления к просмотровому .vue, и параллельно вывод в архивные чертежи), но ничего содержательного без перехода к датацентричности (т.е. решения вопроса об учёте оригинальной модели системы в SP3D, а не разных выписок из этой модели в других информационных системах) с этими документами делать нельзя. Есть также проблема с "утверждениями": утверждается "фотография" (выписка), а не то, с чего сделана фотография (исходная база данных) -- но утвержденная фотография оказывается главней оригинала, который никем не утверждается и продолжает оставаться "рабочим"! Если возникает проблема "объекту нужно сбрить усы", то нельзя гарантировать, что вместо сбривания усов не будет подретуширована фотография (т.е. данные исходной базы и утвержденных выписок из неё совпадут).
-- data handover со стадии на стадию. Ежели передавать документы, то совершенно непонятно, как работать с изменениями: в документах коллизии не проверишь. Ежели базу данных, то какую из многочисленных?
-- нужно ли "физически" собирать все данные разных САПР в какой-то одной PLM для поиска коллизий, или возможно организовать распределенную разработку? Какова архитектура информационной системы разработки, обеспечивающей принципиальный (логический, абстрактный) сбор правильной конфигурации системы для поиска коллизий или в виде проектного базиса?
-- практика управления информацией в ISO 15288 обеспечивает, чтобы данные были доступны тем заинтересованным сторонам, которым они нужны, и тогда, когда они нужны. Как это обеспечить технологически, ежели эти данные уже где-то находятся, а все информационные системы в предприятии находятся под разным администрированием?

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

Вот примеры проблем, которые решаются в рамках перехода к моделе-ориентированности:
-- действительно ли нужно использовать просмотровые форматы в PLM, или нужно передавать оригинальные модели с сохранением всей информации?
-- совместимы ли используемые модели данных (интеграция данных разных САПР) при попытках собрать общую непротиворечивую модель инженерного объекта?
-- можем ли мы обеспечить "подъем в цифру" бумажных чертежей? При этом речь идет не о сканировании (это бы обсуждалось как маленький шажок к датацентричности, смена вида носителя для "картинки" с бумаги на растровый файл), а "распознавании" -- то есть представление в виде атрибутированной 3D-модели с привязкой к другим моделям (например, P&ID).
-- какие виды коллизий мы можем проверить, имея тот или иной вид данных? Какие данные нужно собрать и хранить, как обеспечить связанность этих данных между собой, чтобы проверка коллизий была возможна?
-- какие виды моделей (технологические/процессные -- P&ID, 3D, финансовые, графики работ, органиграммы и т.д.) должны быть разработаны в инженерном проекте, и какие должны быть модели данных (метамодели) этих моделей?
-- какое программное обеспечение должно быть выбрано, чтобы поддержать работу с необходимыми моделями (например, САПР должен поддерживать 3D моделирование, а не 2D).
-- какое имитационное моделирование можно выполнить с использованием данных модели? Какие программы имитационного моделирования (коды) поймут данные модели?

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

А теперь повторюсь: это два парадигмальных сдвига. Так что не думайте, что быстро разберётесь, даже если всё написанное тут кажется очевидным и понятным. Но и не надейтесь, что эти проблемы обойдут стороной: датацентричность и моделе-ориентированность представляют сейчас основной архитектурный тренд в инженерных и корпоративных информационных системах, и с этим неминуемо придётся разбираться.
post comment

navigation
[ viewing | June 12th, 2011 ]
[ go | previous day|next day ]