ISO 15926 outside и inside
TechInvestLab разработал более-менее подробное описание метода "ISO 15926 outside" -- http://techinvestlab.ru/files/RefDataEng/RefDataEngr_ver_2_25feb11.doc. Тем не менее, проект .15926 посвящен совсем другому направлению -- это "ISO 15926 inside", у которого сейчас описания вообще нет. Это описание трудно сделать не только потому, что на данный момент нет никаких реализаций "ISO 15926 inside", но и потому что нет никаких внятных определений этого подхода, да и число возможных направлений реализации побольше, чем в outside с их пока лишь двумя ветками -- XMpLant и IRING.
"ISO 15926 inside" -- это методы, подразумевающие представление не только справочной информации, но и проектных данных в нейтральном формате ISO 15926, плюс использующие редактирование так представленных данных в разнообразных DSL, плюс использующих понимание онтологической/семантической/прагматической природы данных для организации быстрых (по сравнению с полноценным FOL) алгоритмов работы с данными -- на первых порах это будут алгоритмы проверки отсутствия коллизий в большом инженерном проекте, а затем и алгоритмы синтеза проектных решений.
На данный момент непрактично хранить проектные данные большого инженерного сооружения в требуемом ISO 15926 формате. Вся инфраструктура пока настроена на ISO 15926 outside, при этом хранятся только справочные данные. Проектные данные хранятся в виде, приближенном к используемым обработчиками информации (специализированными САПР) -- то есть в формате объектных хранилищ современных PLM (ENOVIA, AVEVA NET и т.д.), часто надстроенных над реляционными базами данных. ISO 15926 мог бы потребовать другого формата, другой надстройки над той же реляционной базой (или даже не реляционной, а какой-то другой -- это требует дальнейших исследований). А поскольку модель данных (т.е. Часть 2) ISO 15926 включает довольно существенные ограничения, то можно задумываться над быстрыми специализированными алгоритмами доступа к этой информации.
Мы исходим из того, что в формате ISO 15926 будут доступны огромные объемы информации: сотни человек займутся мэппингом, сотни человек будут писать адаптеры. Вся эта информация будет сваливаться в PLM, где отсматриваться (глазами! сейчас главное приложение PLM -- это "веб-портал") и оседать в архивных целях.
Интересно было бы получить не только универсальный браузер с поддержкой workflow между внешними обработчиками (это и есть нынешние PLM), но универсальный процессор, который может работать с этими проектными данными -- проверять целостность, "переводить" с одного языка на другой (не делать "внешний мэппинг", а именно что "переводить" -- запросить/вывести чего не хватает и показать в заданном DSL).
Тут нужно отстроиться от таких систем, как IBM Watson -- ибо в этом направлении сейчас побежит весь мир. Статистические алгоритмы, естественный язык, ответы на вопросы, заданные на естественном языке. Это не наш путь. Успехи инженерии -- это успехи в использовании формальных методов. Конечно, IBM Watson и подобные системы формализуют информацию -- но мы не будем заниматься мэппингом из естественного языка в ISO 15926. Это сделают другие. Мы будем развивать направление формального представления инженерной информации на предназначенных для этого DSL, а затем совместной обработки полученных в разных DSL инженерных данных -- как с целью нахождения коллизий, так и с целью синтеза проектных и реализационных (вплоть до строительной роботики) решений.
Тем самым, у нас смесь компиляции ("формального перевода" из одного DSL в другой DSL), семантического поиска (pattern matching, с паттернами, задаваемыми на DSL).
Мы не будем бороться за формализацию, мы будем профессионализироватья в обработке формальной информации. Например, две разных формализации могут быть противоречивы не из-за того, что "допускать разные толкования", а из-за того, что выполнены в разных онтологических парадигмах -- и мэппинг их в ISO 15926 был выполнен без надлежащего онтологического контроля. Не наша задача "править мэппинг" (хотя .15926 вполне можно было бы использовать для подобных целей тестирования адаптеров). Наша задача -- использовать преимущества компактной и однозначно определенной онтологии для работы с инженерными данными. В .15926 идёт внутренний контроль инженерных коллизий, но входной контроль связан с сохранением одной картины мира для всех "погруженных" в ISO 15926 отдельных групп инженерных описаний.
То есть мы делаем не столько "библиотеку справочных данных и генератор адаптеров", как IRING или XMpLant, сколько интегрируемся с ними, как входными модулями. И делаем что-то типа PLM 3.0 -- определяемой примерно так же, как Web 3.0, "хранилище информации с мозгами".
Как это будет устроено внутри? Language workbench для работы с ISO 15926-представлением в разных DSL ("универсальный редактор/моделер/САПР") и "движок ISO 15926" (виртуальная машина ISO 15926).
Текущий roadmap представляется так:
1. Хранилище ISO 15926, который может вкачать в себя любые данные ISO 15926 (их оказывается чуть бОльшее количество форматов, чем можно себе представить) и показать их унифицировано в соответствии с моделью данных ISO 15926.
2. Виртуальная машина ISO 15926, которая может выполнить ряд проверок непротиворечивости для собранных данных из нескольких разных библиотек справочных данных и нескольких разных хранилищ проектных данных.
3. Возможность исправить ошибки (удобный редактор "машинного формата"), и вернуть исправленные данные (форма возврата оговаривается: либо сами данные, либо скрипт исправления) туда, откуда взяли. Это будет нанесение первой непоправимой пользы от .15926 для реальных проектов.
4. Реализация language workbench, ибо в "машинном формате" ISO 15926 работать могут только особо одарённые инженеры данных. Просто инженеры в этом языке работать не могут, им для правки данных нужно давать привычные и удобные для них языки. Вот и нужно реализовать мультиязыковую среду над ISO 15926-представлением.
Конкурентные преимущества перед другими системами (теми же PLM 2.0):
-- компактность и гарантированная согласованность модели мира для самой разной поступающей информации (качество нашей модели мира, т.е. однозначность и непротиворечивость представления информации инженерных объектов) должно быть выше, чем качество модели мира конкурентов: за счет лучшей философско-логической проработки. Тут мы пока в крупном отрыве.
-- возможность кушать данные из самых разных адаптеров (хотя это сомнительное преимущество: через пару лет любая PLM сможет делать это).
-- возможность оптимизации алгоритмов "виртуальной машины" для нашего представления данных (хотя и это сомнительное преимущество: другие PLM тоже оптимизируют свои движки под свои модели данных. Но мы не связаны тут legacy и сможем попробовать что-то интересное: а хоть ту же теорию категорий для поиска возможных оптимизаций).
-- интерфейс редактирования данных: возможность указать какое-то подмножество данных для редактирования и непосредственное редактирование. В традиционных PLM редактирование с контролем непротиворечивости не предусмотрено: всё редактирование осуществляется в САПР, а ведь редактировать чаще всего нужно будет какие-то фрагменты данных, которые лежат на стыке разных САПР. Тут, похоже, можно будет добиться существенного отрыва -- если удастся сделать language workbench, в которой для каждого случая такого редактирования можно будет легко создавать свой специализированный DSL. Тут пока ни мы, ни конкуренты не преуспели.
А пока можно будет развиваться, редактируя не столько большие объемы проектных данных, сколько не такие уж большие объемы справочных данных. Вот и займёмся специализацией на работе со справочными данными -- разгребанием помоек, получающихся после "коллективной разработки", после "автоматической формализации текстов на естественном языке" и т.д.. Только (в отличие от, например, IRING) не будем забывать о возможности взять на борт кроме справочных и какие-то проектные данные -- хотя бы для верификационных целей.
"ISO 15926 inside" -- это методы, подразумевающие представление не только справочной информации, но и проектных данных в нейтральном формате ISO 15926, плюс использующие редактирование так представленных данных в разнообразных DSL, плюс использующих понимание онтологической/семантической/прагматической природы данных для организации быстрых (по сравнению с полноценным FOL) алгоритмов работы с данными -- на первых порах это будут алгоритмы проверки отсутствия коллизий в большом инженерном проекте, а затем и алгоритмы синтеза проектных решений.
На данный момент непрактично хранить проектные данные большого инженерного сооружения в требуемом ISO 15926 формате. Вся инфраструктура пока настроена на ISO 15926 outside, при этом хранятся только справочные данные. Проектные данные хранятся в виде, приближенном к используемым обработчиками информации (специализированными САПР) -- то есть в формате объектных хранилищ современных PLM (ENOVIA, AVEVA NET и т.д.), часто надстроенных над реляционными базами данных. ISO 15926 мог бы потребовать другого формата, другой надстройки над той же реляционной базой (или даже не реляционной, а какой-то другой -- это требует дальнейших исследований). А поскольку модель данных (т.е. Часть 2) ISO 15926 включает довольно существенные ограничения, то можно задумываться над быстрыми специализированными алгоритмами доступа к этой информации.
Мы исходим из того, что в формате ISO 15926 будут доступны огромные объемы информации: сотни человек займутся мэппингом, сотни человек будут писать адаптеры. Вся эта информация будет сваливаться в PLM, где отсматриваться (глазами! сейчас главное приложение PLM -- это "веб-портал") и оседать в архивных целях.
Интересно было бы получить не только универсальный браузер с поддержкой workflow между внешними обработчиками (это и есть нынешние PLM), но универсальный процессор, который может работать с этими проектными данными -- проверять целостность, "переводить" с одного языка на другой (не делать "внешний мэппинг", а именно что "переводить" -- запросить/вывести чего не хватает и показать в заданном DSL).
Тут нужно отстроиться от таких систем, как IBM Watson -- ибо в этом направлении сейчас побежит весь мир. Статистические алгоритмы, естественный язык, ответы на вопросы, заданные на естественном языке. Это не наш путь. Успехи инженерии -- это успехи в использовании формальных методов. Конечно, IBM Watson и подобные системы формализуют информацию -- но мы не будем заниматься мэппингом из естественного языка в ISO 15926. Это сделают другие. Мы будем развивать направление формального представления инженерной информации на предназначенных для этого DSL, а затем совместной обработки полученных в разных DSL инженерных данных -- как с целью нахождения коллизий, так и с целью синтеза проектных и реализационных (вплоть до строительной роботики) решений.
Тем самым, у нас смесь компиляции ("формального перевода" из одного DSL в другой DSL), семантического поиска (pattern matching, с паттернами, задаваемыми на DSL).
Мы не будем бороться за формализацию, мы будем профессионализироватья в обработке формальной информации. Например, две разных формализации могут быть противоречивы не из-за того, что "допускать разные толкования", а из-за того, что выполнены в разных онтологических парадигмах -- и мэппинг их в ISO 15926 был выполнен без надлежащего онтологического контроля. Не наша задача "править мэппинг" (хотя .15926 вполне можно было бы использовать для подобных целей тестирования адаптеров). Наша задача -- использовать преимущества компактной и однозначно определенной онтологии для работы с инженерными данными. В .15926 идёт внутренний контроль инженерных коллизий, но входной контроль связан с сохранением одной картины мира для всех "погруженных" в ISO 15926 отдельных групп инженерных описаний.
То есть мы делаем не столько "библиотеку справочных данных и генератор адаптеров", как IRING или XMpLant, сколько интегрируемся с ними, как входными модулями. И делаем что-то типа PLM 3.0 -- определяемой примерно так же, как Web 3.0, "хранилище информации с мозгами".
Как это будет устроено внутри? Language workbench для работы с ISO 15926-представлением в разных DSL ("универсальный редактор/моделер/САПР") и "движок ISO 15926" (виртуальная машина ISO 15926).
Текущий roadmap представляется так:
1. Хранилище ISO 15926, который может вкачать в себя любые данные ISO 15926 (их оказывается чуть бОльшее количество форматов, чем можно себе представить) и показать их унифицировано в соответствии с моделью данных ISO 15926.
2. Виртуальная машина ISO 15926, которая может выполнить ряд проверок непротиворечивости для собранных данных из нескольких разных библиотек справочных данных и нескольких разных хранилищ проектных данных.
3. Возможность исправить ошибки (удобный редактор "машинного формата"), и вернуть исправленные данные (форма возврата оговаривается: либо сами данные, либо скрипт исправления) туда, откуда взяли. Это будет нанесение первой непоправимой пользы от .15926 для реальных проектов.
4. Реализация language workbench, ибо в "машинном формате" ISO 15926 работать могут только особо одарённые инженеры данных. Просто инженеры в этом языке работать не могут, им для правки данных нужно давать привычные и удобные для них языки. Вот и нужно реализовать мультиязыковую среду над ISO 15926-представлением.
Конкурентные преимущества перед другими системами (теми же PLM 2.0):
-- компактность и гарантированная согласованность модели мира для самой разной поступающей информации (качество нашей модели мира, т.е. однозначность и непротиворечивость представления информации инженерных объектов) должно быть выше, чем качество модели мира конкурентов: за счет лучшей философско-логической проработки. Тут мы пока в крупном отрыве.
-- возможность кушать данные из самых разных адаптеров (хотя это сомнительное преимущество: через пару лет любая PLM сможет делать это).
-- возможность оптимизации алгоритмов "виртуальной машины" для нашего представления данных (хотя и это сомнительное преимущество: другие PLM тоже оптимизируют свои движки под свои модели данных. Но мы не связаны тут legacy и сможем попробовать что-то интересное: а хоть ту же теорию категорий для поиска возможных оптимизаций).
-- интерфейс редактирования данных: возможность указать какое-то подмножество данных для редактирования и непосредственное редактирование. В традиционных PLM редактирование с контролем непротиворечивости не предусмотрено: всё редактирование осуществляется в САПР, а ведь редактировать чаще всего нужно будет какие-то фрагменты данных, которые лежат на стыке разных САПР. Тут, похоже, можно будет добиться существенного отрыва -- если удастся сделать language workbench, в которой для каждого случая такого редактирования можно будет легко создавать свой специализированный DSL. Тут пока ни мы, ни конкуренты не преуспели.
А пока можно будет развиваться, редактируя не столько большие объемы проектных данных, сколько не такие уж большие объемы справочных данных. Вот и займёмся специализацией на работе со справочными данными -- разгребанием помоек, получающихся после "коллективной разработки", после "автоматической формализации текстов на естественном языке" и т.д.. Только (в отличие от, например, IRING) не будем забывать о возможности взять на борт кроме справочных и какие-то проектные данные -- хотя бы для верификационных целей.