Системы автоматизации проектирования: роль человека и компьютерной среды
Павел Леонидович Храпкин
Процесс создания проектов в наши дни неотделим от информационных технологий - тех, что зарождались и проникали в повседневную жизнь отечественных инженеров в 60-70 годы XX столетия. Инженер- проектировщик в нашем сознании непременно возникает перед экраном (сегодня - чаще перед парой экранов) персонального компьютера, так же, как 50 лет назад он представлялся рядом к кульманом, с чертежным карандашом в руках. Компьютер осуществляет связь с многочисленными источниками справочной информации, используется для координации работы между различными подразделениями проекта ответственным руководителем, для общения с коллегами и для управления проектом как таковым [1].
Историческое развитие
Само зарождение компьютеров - вычислителей - в XX веке связано с узкой, хотя и весьма важной ролью: проводить массовые математические операции с группой узкоспециальных данных - баллистическими таблицами для ведения артиллерийского огня или подсчетом статистических данных, собранных и перенесенных на картонные карточки.
Далее было естественно расширить эту роль в область систем управления - тем же артиллерийским огнем, полетом ракеты или работой технологической системы. Так возникли системы управления реального времени. И вычислительная и управляющая роли ЭВМ конечно существуют и развиваются в наше время, обрабатывая огромные массивы данных, собирая информацию от многих тысяч сенсоров или рассылая управляющие сигналы на большие расстояния в течении долей секунды. Для человека или любого человеческого коллектива подобная функциональность просто немыслима. Поэтому электронные вычислительные машины стали расширением, своего рода, придатком к работе человека или группы людей - автоматизированным рабочим местом (АРМ). Пик популярности этого термина пришелся на 70е - 80е годы прошлого столетия.
Однако, вместе с позитивной ролью АРМ, с позиций века XXI легко увидеть и их негативное воздействие на прогресс: Возникли «островки автоматизации», «островки информации». Связь между отдельными массивами данных - информационные потоки - и сейчас оставляет желать лучшего.
От «островов данных» к «среде». Проблемы
Параметры связи между компьютерами заметно улучшились за последние десятилетия. Возросла скорость передачи данных, и быстродействие самих ЭВМ, а значит, значительно выросли объёмы передаваемой информации. Однако, вопросы
- Что именно передавать?
- Куда?
- Зачем? Что делать с получаемыми данными получателю? Как их упорядочить?
- Что передать отправителю обратно? возникают с еще большей остротой.
Различные структуры соединения компьютеров в сети отражают отношение их создателей к перечисленным выше проблемам, но до решения - до создания компьютерной среды все еще далеко. От клиент- серверных иерархий 90х годов, одно- и многоранговых сетей, и «облаков» [2] следующего десятилетия, концепции Big Data и других идей в этой области, все еще ожидают новых плодотворных рецептов в наши дин.
Принципиально важным аспектом здесь является возможность объединять группы людей, позволяя соединить их умения и усилия для решения общей задачи.
Тут мы сталкиваемся с проблемой, которая далеко выходит за временные рамки компьютерной эры. она стара как мир: во время строительства Вавилонской башни Создатель смешал языки, сделав невозможным совместные усилия строителей, а значит и самого проекта. Подобным образом и «острова данных» - различные специализированные системы проектирования (САПР) - «говорят на разных языках». Технологи, архитекторы, электрики, изготовители, монтажники оперируют различными по своей природе данными.
Рис. 1. Самая высокая в мире токийская телебашня «Небесное дерево» 634м. 2012г
Степень детальной проработки этих данных, необходимая узким специалистам, лишь усложняет взаимодействие с их соседями, а несогласованность приводит к многочисленным коллизиям, устранение которых стоит немалых средств, и, в конечном итоге, ограничивает сложность выполняемого проекта. На рисунке 1 сверху самая высокая в мире телебашня Токио. Она сооружена в сейсмически активном районе, а это означает, что сооружение необходимо было контролировать с точки зрения сейсмоустойчивости на всех этапах строительства, проверять вес и положение центра тяжести каждого монтируемого элемента.
Другой рисунок - стадион Арена в Казани на 45 тысяч зрителей. Это геометрически совершенное сооружение с закрывающейся в случае дождя крышей и с множеством информационных табло и телемониторов, которые должны быть хорошо видны каждому зрителю.
Говоря об этих сложных современных проектах, проектировщики сообщают о том, что проекты удалось реализовать, лишь внедрив самые современные технологии обработки проектных данных BIM (Building Information Modeling - информационное моделирование здания) [3]. Здесь речь идет о том, что различные данные, относящиеся к проекту, хранятся в базе данных проекта, их легко выделить, отфильтровав по принадлежности к той или иной специальности проекта, принадлежности к компоненту или узлу в 3D модели или к стадии строительства.
Симптоматично то, что многие разработчики САПР, да и множества других систем, используемых людьми, сознательно стремятся к универсальности - к расширению спектра функциональных возможностей и сферы применимости их продукта. А устройства и системы с более широким спектром возможностей обречены на коммерческий успех.
Однако, стремление накопить разнородную информацию в базе данных модели - не самоцель. Лишь возможность выявить неизбежные коллизии, своевременно устранить ошибочные решения, скоординировать работу разобщенных коллективов, нередко работающих на разных предприятиях и разделенных во времени, может оправдать трудозатраты, связанные с компьютерным объединением данных в единую модель.
Во все времена координировать работы человеческих коллективов в больших проектах было непростой задачей, доступной лишь наиболее опытным, сведущим менеджерам (см. рисунок 3). Сложность, разнообразность и многочисленность проектных данных сегодня не позволяет отдельному руководителю ознакомиться с десятками тысяч рабочих чертежей, расчетов, следить за их точным и своевременным исполнением. А разбить проект и соответствующие этому фрагменты данных не всегда удается. Иерархически организованные разделы проекта, где потоки «привязок» и «проектных заданий» двигаются «сверху вниз», то и дело приходится корректировать, возвращать для переделки, контролировать исполнение. Вот тут и оказывается востребованной способность компьютера быстро обрабатывать огромные массивы информации.
Рис. 2. Стадион «Арена» Казань. Вместимость 45 тыс зрителей. Генпроект «Татинвестгражданпроект». Проектирование: «ЦНИИПромзданий» Поставщик: ТАТПРОФ
И все же, говорить об общей для большого числа работающих над сложным проектом людей компьютерной среде не приходится. На практике в каждой отдельной проектной организации сосуществуют десятки различных САПР, а на стыках между ними возникает немало вопросов, некоторые из которых остаются нерешенными. В разделе ниже приведены некоторые методы преодоления пограничных проблем. Многие программисты старшего поколения помнят образное выражение Брукса о динозаврах - проектах, которые с фатальной неизбежностью тонут в асфальтовых болотах проблем [4].
Методы преодоления границ применимости САПР
Внедрение новой - пусть самой совершенной и самой универсальной технологии никогда не может произойти одномоментно. Неизбежно оказывается, что часть людей, процессов, информации связаны с инородными системами - узкоспециализированными или просто старыми, а люди, работающие с этими системами - «островитянами». У многих руководителей возникает дилемма: наладить взаимодействие с такими процессами или отказаться от их использования совсем? Конечно, решение тут - система уравнений с множеством неизвестных; перечислим лишь некоторые часто используемые методы:
- Все практически используемые САПР имеют подсистемы импорта/экспорта данных. Использование различных файловых форматов (IFC, CIS/2, FEM и др) нередко позволяет наладить взаимодействие.
- Различные модули Interop, предлагаемые разработчиками САПР, специально предназначены для налаживания тех или иных связей между взаимодействующими системами. Но их освоение само по себе требует немало усилий.
- Ручной перенос данных. Фактически, это наиболее распространенная ситуация: Токарь, получивший рабочий чертеж, изготавливает деталь, глядя на рабочий чертеж. Лишь небольшая часть станков имеет числовое программное управление.
- Опорные или референтные модели по сути лишь облегчают ручной перенос данных: импортировав чертеж, отсканировав объект или его изображение в одной САПР, компоненты можно построить заново в другой системе, связав их с копией чертежа или привязав к характерным точкам отсканированного файла.
В статье [5] рассмотрена возможность обмена структурированными и неструктурированными данными. Стремление к согласованию структуры данных получателями и источниками информации заметно увеличивает шансы на успешное взаимодействие. Там, где структуру информации не удается согласовать, например, при работе с архивами бумажных чертежей, полезность хранения и привлечения архива под вопросом. Можно попытаться построить адаптивные алгоритмы структуризации данных, не забывая сопоставлять трудозатраты и ценность привлекаемой информации.
Вместо заключения: Взгляд в будущее
Сопоставление структур информации с человеческими языками общения не случайно. На заре компьютерной эры велись жаркие дискуссии о том, может ли машина осуществить перевод. Тогда казалось, что язык общения, сам являясь носителем разума, не может быть отдан на откуп «бездушным ЭВМ». Прогресс последних лет в этой области не оставляет места для когда-то модных рассуждений. Недавно Microsoft Research продемонстрировал переводчик устной речи, сохраняющий особенности голоса оригинала. Переводом же текстов между различными языками пользуются сотни миллионов землян, это бесплатный сервис Google. Конечно, машинный перевод нередко неточен, он требует человеческой проверки и исправлений, но в целесообразности машинного перевода сомнений нет.
Продолжая аналогию в область взаимодействия различных САПР, давайте представим будущую систему проектирования. Несомненно, нужные для работы модули системы проектирования будут доступны в сети. Их загрузка из Интернет и оплата по мере использования, станет простой, нередко автоматической процедурой. Впрочем, человек- конструктор сохранит за собой возможность перепроверить и изменить принятые инженерные решения. Поверочные расчеты, сделанные с помощью альтернативных программных модулей, также могут быть выполнены автоматически.
Информация из аналогичных проектов, хранящихся в архивах, также может быть привлечена - автоматически или полуавтоматически. Однако, настройка доступности тех или иных данных, конфиденциальности, прав на считывание или модификацию модели - отдельный вопрос, далеко выходящий за рамки этой работы.
Список литературы
- П. Л. Храпкин. Этапы развития информатики в нашей стране - от машинных залов к облачным вычислениям. Великий Новгород.: Труды SORUCOM-2011, сентябрь 2011, стр.308-312
- П. Храпкин. «Круглый стол "Применение облачных технологий при организации ИТ-поддержки бизнеса промышленных компаний.». Rational Enterprise Management, стр.6-13 в №1/2011 и 6-16 в №2/2011
- П. Л. Храпкин. Проектирование с Tekla. Санкт-Петербург, 2014. Журнал «Стройметалл».
- Брукс, Фредерик. Мифический человеко-месяц. 1975.
- А. А. Тучков, А. А. Рындин. «О путях создания систем управления инженерными данными». Rational Enterprise Management #1/2014.
Об авторе: Бюро ESG
Санкт-Петербург, Россия
khrapkin@esg.spb.ru
Материалы международной конференции Sorucom 2014 (13-17 октября 2014)
Помещена в музей с разрешения авторов
17 января 2016