Трансфёр технологий BIM или ещё раз об инженерию справочных данных
К вопросу про "перенос западной практики BIM" в Россию, поднятый в https://www.facebook.com/photo.php?fbid=10210467827357183&set=a.10201102000737371.1073741828.1389467354
Все эти потуги с "адаптацией" иностранных PLM и прочими системами этого класса (и поддерживающий BIM софт туда же) упираются обычно в проблему отсутствия справочных данных. По определению, справочные данные (reference data) -- это данные, которые используются в различных проектах. Да, это совпадает с формулировкой для "знаний". И совпадает с формулировкой для нормативно-справочной информации (НСИ). И статус этих данных -- стандарт (корпоративный, отраслевой какой-то ассоциации, национальный -- это обсуждается), разве что это не стандарт-текст, а структурированные данные "базы данных". Если эти данные специфичны для одного проекта, то это конфигурационные и трансакционные данные, с ними обычно полегче: они порождаются и потребляются в проекте и поэтому по их поводу всегда можно договориться (в том числе с использованием для их описания справочных данных). Подробней про справочные, конфигурационные, трансационные данные см. в http://ailev.livejournal.com/1067013.html -- я несколько лет назад много и часто писал на эти темы.
Обычно у западного софта стандартных справочных данных для отечественных применений нет. Вендоры софта не прогибаются с созданием нейтральных справочных данных, ибо совсем не дураки -- они делают какие-то "библиотеки" только под себя. Ну, или не делают, а ждут, пока их кто-то сделает, ибо создание справочных данных это стандартизация, это очень дорогое удовольствие для одного игрока на рынке (если только это не очень и очень крупный игрок).
Поддерживать разговор про инженерию справочных данных мало кто может. Чаще поддерживают разговор про управление справочными данными. Это проще, ибо когда справочные данные есть, то ими можно управлять. А когда нет -- то сначала их нужно сделать, этим занимается уже инженерия справочных данных, чистого "управления" не хватает.
Но для начала нужно хотя бы понимать, что ключевой вопрос -- это не вопрос софта, а вопрос данных. Мы, когда советуем на очередном предприятии создать службу PLM, рекомендуем сразу разворачиваться к НСИ в рамках этой службы, именовать её "управление инженерными данными" или как-то так, и не ориентироваться на поддержку САПР (ибо поддержка САПР потом всё равно уйдёт в отдельную от PLM службу). И действительно, сам софт PLM и его развитие отступает буквально через годик на второй план, и вся деятельность новой службы дальше идёт уже по линии НСИ, главным образом структурированной. В отечественных разговорах про BIM вся эта история пока не полностью проявлена, хотя в OPEN BIM иногда про эти отечественные справочные данные иногда разговаривают. А без справочных данных софт "из коробки" не работает. "Настроить" -- это и есть создать необходимые справочные данные.
Вся боль и печаль с ISO 15926 ("почему ISO 15926" -- http://dot15926.livejournal.com/39300.html) это была попытка capital projects industry (owner-operators) вывернуть руки вендорам софта PLM/CAD/CAE по вопросу о справочных данных. С очень неоднозначным результатом: полной смерти всего проекта нет, но и бурной жизни тоже не наблюдается. Вендоры пока успешно сопротивляются. BIM всё-таки больше про гражданское строительство сейчас, а когда у вас появляется большое количество оборудования в проекте, то традиционно обсуждаемого в тусовке OPEN BIM маловато будет, и всю ту же песню нужно петь по-новой, уже с какими-нибудь "реакторами" и лесом труб на борту хитро устроенной бетонной коробки.
Опять же, справочные данные раскиданы по ГОСТ (http://ailev.livejournal.com/1027975.html -- "политические дискуссии, обсуждение стандартов и религиозные споры -- это одного поля ягоды, и чисто технократическая постановка вопроса в стандартизации неверна"), и договориться поэтому о них трудно. Но также очень трудоёмко их уже после договорённости об их сути формализовать и уложить в структуру данных. Просто запретительно трудоёмко, поэтому никаких кавалерийских наскоков в создании "единых информационных пространств" не получается. Вот у нас были попытки описать методологию инженерии справочных данных на примере ISO 15926 (http://techinvestlab.ru/files/RefDataEng/RefDataEngr_ver_2_25feb11.doc), за прошедшие пять лет в плане снижения трудоёмкости этой работы изменилось не слишком много, даже с учётом того, что мы разработали онтологический редактор, поддерживающий ISO 15926 -- https://github.com/TechInvestLab/dot15926.
Прямо сейчас начались очень осторожные разговоры по использованию неестественного интеллекта для этих целей, но это пока только разговоры. После того, как появится хоть какая-то автоматизация в вопросе создания справочных данных -- вот после этого ситуация со всеми этими OPEN BIM и ISO 15926 может начинать меняться. Но вкладываться в НИР, когда даже НИОКР под вопросом -- этого никто не хочет, это опять же под силу только самым крупным игрокам.
В управлении информацией в масштабах жизненного цикла и обсуждении справочных данных и их места во всей этой истории технологического развития PLM/CAD/CAE систем в целом и BIM в частности есть несколько совсем разных разговоров, которые нещадно путаются, но которые нужно как-то различать:
а) архитектура предприятия. Тут обсуждают, какие именно практики управления инженерными данными (синоним: управление инженерной информацией, управления жизненным циклом, управления конфигурацией) будут использоваться и для чего, кто этим будет заниматься, какой софт нужно будет адаптировать, где какие данные будут преобразовываться, какие приложения это затронет. Обсуждаются деятельность, программы, сервера и линии связи. Тут решается, "корпоративная шина" или обмен данными "точка-точка" по потребности, тут принимается решения о "брокерах" или "единых хранилищах", тут звучат слова про "единое информационное пространство" (и не спрашивайте, что они означают -- это чисто корпоративно-политический термин). Именно в этой точке обсуждается, чем "библиотека справочных данных" (reference data library) отличается от типовой MDM-системы (master data management) и кому это вообще нужно в крупной компании (а в мелкой компании это вообще никому не нужно, там согласны на то, что попросит в этом плане заказчик -- если он вообще о чём-то попросит).
б) разговор про форму, foundational ontology. Тут договариваются про "базовый формат" -- JSON, OWL, XML, эксель-таблицы и т.д. Именно на этом уровне договариваются о моделере данных: под каждым из этих форматов есть какая-то теория (триплы, реляционные таблицы, деревянные структуры данных и т.д. -- противопоставление факт-ориентированного представления, объектного как в ООП, реляционного и т.д.) и моделер должен поддерживать эту дисциплину (технология всегда ведь поддерживает какую-то дисциплину, даже если это явно не обсуждается!). Именно на этом уровне принимаются решения про структуру хранилищ данных: SQL, NoSQL, triple-store, объектные базы и т.д..
в) вопрос о наличии или отсутствии общей "картины мира" (upper ontology), соглашений о моделировании данных в рамках выбранного формализма -- справочные данные самого верхнего уровня. Либо у вас есть какое-то понимание, как моделировать пространство, время, оборудование и его классы, процессы, отличать компоненты от модулей, разбираться со множественностью классификаторов на разных стадиях жизненного цикла, либо этого нет.
г) справочные данные для всех инженерных практик -- все эти бесчисленные каталоги оборудования, таблицы типоразмеров, классификаторы изделий и прочие справочники материалов, их несть числа. И ещё представление 3D, календарного планирования и issue в PLM, включая все их атрибуты. Нужно понимать, откуда они все берутся и как сделать так, чтобы был всегда один источник правды: какой-нибудь "адрес поставщика" отслеживался и менялся только в одном месте, а остальные этим адресом только пользовались. Утопия, конечно, но мы к ней стремимся.
д) вопросы автоматизации получения справочной информации за счёт технологий обработки естественного языка, участие в организациях по стандартизации и прочие способы снижения стоимости получения справочных данных. Это НИРы, для России почти неактуально. Хотя без этого пункта всегда будут догонялки с западом, всегда вопрос "трансфёра технологий" будет в одну сторону (несмотря на то, что в том же deep learning полно русскоговорящих людей).
Все эти потуги с "адаптацией" иностранных PLM и прочими системами этого класса (и поддерживающий BIM софт туда же) упираются обычно в проблему отсутствия справочных данных. По определению, справочные данные (reference data) -- это данные, которые используются в различных проектах. Да, это совпадает с формулировкой для "знаний". И совпадает с формулировкой для нормативно-справочной информации (НСИ). И статус этих данных -- стандарт (корпоративный, отраслевой какой-то ассоциации, национальный -- это обсуждается), разве что это не стандарт-текст, а структурированные данные "базы данных". Если эти данные специфичны для одного проекта, то это конфигурационные и трансакционные данные, с ними обычно полегче: они порождаются и потребляются в проекте и поэтому по их поводу всегда можно договориться (в том числе с использованием для их описания справочных данных). Подробней про справочные, конфигурационные, трансационные данные см. в http://ailev.livejournal.com/1067013.html -- я несколько лет назад много и часто писал на эти темы.
Обычно у западного софта стандартных справочных данных для отечественных применений нет. Вендоры софта не прогибаются с созданием нейтральных справочных данных, ибо совсем не дураки -- они делают какие-то "библиотеки" только под себя. Ну, или не делают, а ждут, пока их кто-то сделает, ибо создание справочных данных это стандартизация, это очень дорогое удовольствие для одного игрока на рынке (если только это не очень и очень крупный игрок).
Поддерживать разговор про инженерию справочных данных мало кто может. Чаще поддерживают разговор про управление справочными данными. Это проще, ибо когда справочные данные есть, то ими можно управлять. А когда нет -- то сначала их нужно сделать, этим занимается уже инженерия справочных данных, чистого "управления" не хватает.
Но для начала нужно хотя бы понимать, что ключевой вопрос -- это не вопрос софта, а вопрос данных. Мы, когда советуем на очередном предприятии создать службу PLM, рекомендуем сразу разворачиваться к НСИ в рамках этой службы, именовать её "управление инженерными данными" или как-то так, и не ориентироваться на поддержку САПР (ибо поддержка САПР потом всё равно уйдёт в отдельную от PLM службу). И действительно, сам софт PLM и его развитие отступает буквально через годик на второй план, и вся деятельность новой службы дальше идёт уже по линии НСИ, главным образом структурированной. В отечественных разговорах про BIM вся эта история пока не полностью проявлена, хотя в OPEN BIM иногда про эти отечественные справочные данные иногда разговаривают. А без справочных данных софт "из коробки" не работает. "Настроить" -- это и есть создать необходимые справочные данные.
Вся боль и печаль с ISO 15926 ("почему ISO 15926" -- http://dot15926.livejournal.com/39300.html) это была попытка capital projects industry (owner-operators) вывернуть руки вендорам софта PLM/CAD/CAE по вопросу о справочных данных. С очень неоднозначным результатом: полной смерти всего проекта нет, но и бурной жизни тоже не наблюдается. Вендоры пока успешно сопротивляются. BIM всё-таки больше про гражданское строительство сейчас, а когда у вас появляется большое количество оборудования в проекте, то традиционно обсуждаемого в тусовке OPEN BIM маловато будет, и всю ту же песню нужно петь по-новой, уже с какими-нибудь "реакторами" и лесом труб на борту хитро устроенной бетонной коробки.
Опять же, справочные данные раскиданы по ГОСТ (http://ailev.livejournal.com/1027975.html -- "политические дискуссии, обсуждение стандартов и религиозные споры -- это одного поля ягоды, и чисто технократическая постановка вопроса в стандартизации неверна"), и договориться поэтому о них трудно. Но также очень трудоёмко их уже после договорённости об их сути формализовать и уложить в структуру данных. Просто запретительно трудоёмко, поэтому никаких кавалерийских наскоков в создании "единых информационных пространств" не получается. Вот у нас были попытки описать методологию инженерии справочных данных на примере ISO 15926 (http://techinvestlab.ru/files/RefDataEng/RefDataEngr_ver_2_25feb11.doc), за прошедшие пять лет в плане снижения трудоёмкости этой работы изменилось не слишком много, даже с учётом того, что мы разработали онтологический редактор, поддерживающий ISO 15926 -- https://github.com/TechInvestLab/dot15926.
Прямо сейчас начались очень осторожные разговоры по использованию неестественного интеллекта для этих целей, но это пока только разговоры. После того, как появится хоть какая-то автоматизация в вопросе создания справочных данных -- вот после этого ситуация со всеми этими OPEN BIM и ISO 15926 может начинать меняться. Но вкладываться в НИР, когда даже НИОКР под вопросом -- этого никто не хочет, это опять же под силу только самым крупным игрокам.
В управлении информацией в масштабах жизненного цикла и обсуждении справочных данных и их места во всей этой истории технологического развития PLM/CAD/CAE систем в целом и BIM в частности есть несколько совсем разных разговоров, которые нещадно путаются, но которые нужно как-то различать:
а) архитектура предприятия. Тут обсуждают, какие именно практики управления инженерными данными (синоним: управление инженерной информацией, управления жизненным циклом, управления конфигурацией) будут использоваться и для чего, кто этим будет заниматься, какой софт нужно будет адаптировать, где какие данные будут преобразовываться, какие приложения это затронет. Обсуждаются деятельность, программы, сервера и линии связи. Тут решается, "корпоративная шина" или обмен данными "точка-точка" по потребности, тут принимается решения о "брокерах" или "единых хранилищах", тут звучат слова про "единое информационное пространство" (и не спрашивайте, что они означают -- это чисто корпоративно-политический термин). Именно в этой точке обсуждается, чем "библиотека справочных данных" (reference data library) отличается от типовой MDM-системы (master data management) и кому это вообще нужно в крупной компании (а в мелкой компании это вообще никому не нужно, там согласны на то, что попросит в этом плане заказчик -- если он вообще о чём-то попросит).
б) разговор про форму, foundational ontology. Тут договариваются про "базовый формат" -- JSON, OWL, XML, эксель-таблицы и т.д. Именно на этом уровне договариваются о моделере данных: под каждым из этих форматов есть какая-то теория (триплы, реляционные таблицы, деревянные структуры данных и т.д. -- противопоставление факт-ориентированного представления, объектного как в ООП, реляционного и т.д.) и моделер должен поддерживать эту дисциплину (технология всегда ведь поддерживает какую-то дисциплину, даже если это явно не обсуждается!). Именно на этом уровне принимаются решения про структуру хранилищ данных: SQL, NoSQL, triple-store, объектные базы и т.д..
в) вопрос о наличии или отсутствии общей "картины мира" (upper ontology), соглашений о моделировании данных в рамках выбранного формализма -- справочные данные самого верхнего уровня. Либо у вас есть какое-то понимание, как моделировать пространство, время, оборудование и его классы, процессы, отличать компоненты от модулей, разбираться со множественностью классификаторов на разных стадиях жизненного цикла, либо этого нет.
г) справочные данные для всех инженерных практик -- все эти бесчисленные каталоги оборудования, таблицы типоразмеров, классификаторы изделий и прочие справочники материалов, их несть числа. И ещё представление 3D, календарного планирования и issue в PLM, включая все их атрибуты. Нужно понимать, откуда они все берутся и как сделать так, чтобы был всегда один источник правды: какой-нибудь "адрес поставщика" отслеживался и менялся только в одном месте, а остальные этим адресом только пользовались. Утопия, конечно, но мы к ней стремимся.
д) вопросы автоматизации получения справочной информации за счёт технологий обработки естественного языка, участие в организациях по стандартизации и прочие способы снижения стоимости получения справочных данных. Это НИРы, для России почти неактуально. Хотя без этого пункта всегда будут догонялки с западом, всегда вопрос "трансфёра технологий" будет в одну сторону (несмотря на то, что в том же deep learning полно русскоговорящих людей).