?

Log in

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

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

Трансфёр технологий BIM или ещё раз об инженерию справочных данных [21 Aug 2016|06:51pm]
К вопросу про "перенос западной практики 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 полно русскоговорящих людей).
post comment

Бессерверные микросервисы по пятаку за пару [21 Aug 2016|09:51pm]
Какой интересный поворот в бессерверные микросервисы: https://www.infoq.com/news/2016/08/serverless-autodesk. Самое интересное там -- The cost. In their [Autodesk] experience, running the lambda solution costs a small fraction (~1%) of the traditional cloud approach. The costs are further reduced by not having to pay operational staff to set up and overview the EC2 and ELB instances.

За этим ходом довольно много и других интересных слов, например Function-as-a-Service, эти лямбды ведь неспроста. A Serverless application can be a single Lambda function that responds to an event, or an entire REST API comprised of hundreds of Lambda functions and API Gateway endpoints. By plugging serverless functions into your infrastructure events you can even automate operations of your non function based infrastructure. -- это из http://serverless.com/ для управления всем этим хозяйством.

И ссылаются там на публикацию API для всего этого: http://apigee.com

Это всё для меня пока загадочно, будет ли выживать, ибо непонятно что легче: размазать по разным серверам функции и базу данных состояний, или организовать обмен сообщениями между акторами. Может быть, дальше мы услышим Actor-as-a-Service, ещё не вечер (шевеления-то уже идут -- но не в Амазоне, а в Азуре: https://azure.microsoft.com/en-us/documentation/articles/service-fabric-reliable-actors-introduction/). И там тоже есть варианты с микросервисами, только в профиль и пока без выпячивания бессерверности: Reliable Services in Service Fabric is different from services you may have written before. Service Fabric provides reliability, availability, consistency, and scalability.

А дальше по "бессерверному" облаку и все остальные парадигмы программирования размажут за small fraction (~1%) of the traditional cloud approach.
1 comment|post comment

Modern Agile и его книжки [21 Aug 2016|11:43pm]
Я тут не буду обсуждать modern agile (вот тут ругают старый agile и провозглашают модерновый -- https://www.agilealliance.org/resources/videos/modern-agile/, вот тут делают то же самое -- https://www.infoq.com/interviews/anzen), но интересен набор книжек, которые лежат в его основе: http://modernagile.org/#learnMore и не совпадающий с этим список книжек тут: https://www.infoq.com/news/2016/08/agile2016-modern-agile и эти же и ещё кое-какие книжки, помянутые в самом подробном на сегодня, но очень коротком и структурированном тексте про modern agile -- https://www.industriallogic.com/blog/modern-agile/. А вот практики modern agile из этого текста:


Дальше традиционные вопросы про а) масштабируемость всех эти lightweight методов за пределы небольшой однородной команды программистов -- скажем, в них и речи не идёт об архитектуре предприятия, а когда у вас где-то 1000 человек этот вопрос встаёт ребром, и б) применимость к системной, а не программной инженерии, то есть проектам с железом -- и не мейкерского масштаба, а побольше. Но и эти вопросы постепенно получают свои ответы. Так, я три книжки ровно из этого списка давно рекомендую на тренинге системного менеджмента -- хотя люди там приходят отнюдь не только из программистских лавок. Список литературы в http://system-school.ru/spisok-rekomendovannh-knig/ их содержит, хотя у меня в курсе и даётся немного другой набор чтива -- общий список литературы содержит много специальных книжек, которые явно не всем подряд нужны.
8 comments|post comment

navigation
[ viewing | August 21st, 2016 ]
[ go | previous day|next day ]