Обсуждение

Подскажите, пожалуйста, можно ли описывать Variability Model на ISO 15926 и хранить в RDL? То есть, некие шаблоны в типовом окружении, как "профили фич". Например, "один или два (но не больше) погружной или штанговый (и никакой другой) насос в нефтяной или водяной (но не в нагнетательной) скважине, с соответствующей типовой обвязкой (для каждого типа насоса свой тип станции управления)", но не классами "обобщенный насос в скважине любого типа, с произвольной станцией управления", и не индивидами "насос номер 12345 в скважине 123, со станцией управления марки такой-то".

Ну, если у вас есть какие-то справочные данные и мета-модель для них (например, мета-модель для variability model), то их вполне можно описывать в ISO 15926, если зачем-то нужно (например, если кроме variability хочется выразить и много другого, для чего тоже есть много разных других мета-моделей). Самый обычный мэппинг, ничего особенного. Но мне кажется, что вы спрашиваете немного про другое -- и поэтому поглядите на margin management в ISO 15926 (http://www.15926.org/publications/HEED/introduction/index.htm). Как "допуски" связаны с переходом с одной фичи на другую фичу можно обсуждать, но это оказывается весьма связанными темами.

Модель вариабельности я много обсуждал с Хансом Тейглером в ходе работы над его моделями темплейтов с Ur-Class. Мы рассматривали моделирование для ситуаций исправления ошибок проектирования, появления опций дизайна и взаимоисключающих решений. Там используются примерно одинаковые приёмы моделирования. Именно моделирование в классах и является основной трудностью, так как в индивидах это сравнительно просто. С margin management это действительно связано, хотя способы моделирования интервалов свойств, проанализированные к настоящему моменту, явно не исчерпывают все возможные варианты. Но если вариабельность выражается не в свойствах, а в конфигурации/топологии предметов, то нужны другие модели. В RDL модель хранится в виде описаний темплейтов в основном.

Я как раз про мета-модель для variability model, но в терминах ISO 15926 и спрашиваю. То есть, если каталог оборудования (классы) в RDL, и сложный технический объект (индивид), то понятно обмениваться данными по этому стандарту и результаты жизненного цикла сохранять тоже в RDL. Но если технический объект не такой сложный, и при этом типовой, то хотелось бы выразить эту типовость с вариабельностью, и результаты такого описания тоже сохранить в RDL. Цели использования такого типового объекта (класса) могут быть разные - и генерация индивидов путем убирания вариативности, и формальное оперирование типовым проектом, и проверка индивидов на соответствие.

Вариабельность нужна не только в свойствах (например, использование погружных насосов с определенными паспортными данными в зависимости от свойств пласта скважины, которые на жизненном цикле меняются), но и в конфигурации/топологии (например, станции управления погружных и штанговых насосов обычно располагаются в совершенно разных типовых местах плюс появляется необходимость дополнительных сооружений для одного из этих типов насосов), а также в cardinality и optionality (например, некоторые элементы конструкции необязательны и применяются в исключительных прописанных случаях, а других элементов может быть от двух до четырех, а элементов А по количеству элементов B). Насколько я понял, margin management-а для этих целей недостаточно.

В этом плане (представление вариабельности) ISO 15926 не хуже любых других представлений, но всё одно нужно договориться, как именно выражать вариабельность: соответствующих справочных данных сегодня нет "из коробки", нужно проводить исследования и моделирование для этой предметной области. Конечно, можно начать с моделирования какого-то стандарта вариабельности и одновременно писать движок для соответствующих вычислений (например, в виде расширений к .15926 Editor). В любом случае, нужно иметь для начала какой-то конкретный кейс в руках, настоящие данные настоящего проекта -- а потом пытаться обобщить результаты. Надеюсь, у вас такой проект где-нибудь рядом есть (чтобы рассуждения и модели не были абстрактными, а были проверяемыми на практике).

Я правильно понимаю, что построение таких "промежуточных" моделей (не каталог оборудования, но и не проект сложного технического объекта) не является приоритетной задачей людей и организаций, продвигающих ISO 15926, поэтому и нет решения "из коробки"? Все нацелены на передачу данных между САПР-ами, а также на федерирование данных например в ГИС ТЭК? Проект рядом есть, кейс в руках ;-) Благодарю за отзывчивость

А также нужно как-то выражать иерархичность variability model, чтобы типовую обвязку скважины можно было как темплейт использовать в типовой обвязке куста скважин. В CVL такой пример Printer и PrinterPool.

"Из коробки" Gellish это примерно соответствует Knowledge models with product structure. Жду публикации одиннадцатой части стандарта, хотя бы драфт.

В тамошней тусовке все нацелены главным образом на федерирование данных САПРов (ISO 15926 outside), хотя и признают, что стандарт вполне может иметь много более широкое применение. В стандарт, конечно, намеренно закладывалась универсальность, просто она ещё не тестировалась. Кроме того, это тестирование немного сдерживалось тем, что от "семантической сетки" в терминах части 2 перешли совсем недавно к темплейтам, их тоже оказалось недостаточно, чтобы работать с инженерами непосредственно, и сейчас работают с паттернами. Так что "передовые отряды" возятся с паттернами (третий подход к снаряду -- проблемам передачи геометрии и P&ID, т.е. продолжают развивать "универсальную часть, дающую выразительность"), а остальные применяют там, где до того потоптались уже передовые отряды и оставили какие-то справочные данные. Отход в какую-то конкретную предметную область требует немедленного моделирования новых справочных данных для этой предметной области. Собственно, удобный софтварий для этого моделирования только-только появился (наш .15926 Editor мы разрабатывали именно для удобной инженерии справочных данных), так что сегодня препятствий для таких проектов нет. И то, мы планируем существенно доработать кусок, связанный с моделированием в паттернах темплейтов в следующей версии (надеемся, что она выйдет в июне). JORD только-только завершил первую фазу, и в неё даже не входила работа со справочными данными, только обновление инфраструктуры поддержки сервиса. Так что какие-то инфраструктурные условия для старта проектов создания справочных данных в новых областях только-только появились в этом году. Если проект у вас рядом, и кейс в руках, то вполне можно его делать. Можем немного помогать на общественных началах, и серьёзно помогать на коммерческих началах ;-)

Паттерны темплейтов - это http://iringug.org/wiki/index.php?title=ISO_15926_Information_Patterns_%28IIP%29_Project_Mappings ? Планируется ли стандартизировать "третий подход к снаряду"?

Да, этот третий подход к снаряду (третье поколение технологии, очередной подъем уровня языка моделирования мира -- паттерны темплейтов) сейчас главная тема дня: стандартизация, поддержка инструментарием. Конечно, не всё в этой области выложено в Сеть, значительная часть обсуждений идёт в частной переписке. vvagr активно участвует в этом процессе. Упрощённый вариант использования ISO 15926 по версии Яна Глендиннинга будет как раз "словарное использование паттернов темплейтов", так что мейнстрим упрощённого применения ISO 15926 в ближайшее время будет также именно в этом месте.

Боюсь, вы не найдёте в этой части того, что ожидаете. Пришлите мне письмо ;-)

Так я об этом и говорю - вариабельность в структурах и количествах объектов моделируется иначе, чем в свойствах. Иерахия опций моделируется как иерархия Ur-Class, их состав - как состав классов темпоральных частей. Разумеется, это целая система иерархий, так как в каждой опции есть под-опции. И для их набора используются общие над-классы. Собственно модель опций хранится в основном как набор темплейтов в RDL (некоторое количество классов тоже хранится, но темплейты - это основное). Конкретные конфигурации хранятся как набор инстансов этих темплейтов. Это достаточно просто организовать, сложность возникает если хочется проверить конкретную конфигурацию на соответствие тем или иным опциям, уж не знаю, есть ли такая задача в реальности. Относительно несложно решается и обратная задача - получать информацию о том что реализован набор опций с кодами (а1, б5, в35, ...) и генерировать по кодам опций полную модель - что где стоит и в каком количестве.

Да, с этой страницы можно скачать редактор паттернов и текущую версию списка паттернов. В ближайшее время у них будет версия мэппинга к паттернам, полностью интегрированная в iRING Tools. Но iRING Tools применимы не во всякой корпоративной (или межкорпоративной) IT-инфраструктуре, так что мы будем делать свой конвертер данных в паттерны. А вот RDF-представление паттернов пока не стандартизировано и даже не предложено публично. Только первые дискуссии идут.

Проверка на соответствие в рамках Semantic Web, насколько мне известно, осуществляется по OWL ризонерами типа Pellet. Если модель конкретной конфигурации соответствует ISO 15926-8, то её проверка на соответствие тем или иным опциям, видимо, может осуществляться тем же путем. Спасибо за информацию, буду изучать глубже.

Тут всё не просто. Единственная реально проработанная формальная аксиоматика в ISO 15926 - это аксиоматика Части 2 выполненная на FOL в Части 7 для работы с аксиомами темплейтов. Соответственно эта часть может быть формально верифицирована, но это не OWL, это ризонеры типа Prover 9, и проблема в том, что аксиоматикой темплейтов занимаются не многие, и стандарта для представления аксиом нет. А то что называется представлением ISO 15926 в OWL - это всего лишь формат сериализации, RDF с использованием ряда предикатов OWL. Самый простой пример - это специализации и классификации. Они не выражены в виде subClassOf и type, они встречаются в виде реифицированных отношений части 2 или инстансов темплейтов. Так что никакой OWL ризонер их не возьмёт. Более сложные примеры - это классы классов, тут предлагается использовать punning, и я что-то не уверен, что есть хоть один ризонер, умеющий учитывать punning и делать на этой основе выводы. Этот комплекс проблем собирается решить рабочая группа по Части 12 стандарта, её ещё называют группой по OWL 2 представлению. Однако что они собираются делать с необходимой для функционирования стандарта реификацией практически всех отношений - мне пока не ясно. Поэтому мы являемся сторонниками специализированных верификаторов и потихоньку развиваем их на базе нашего Editor. Собственно отчёт об итогах хакатона Онтолог Саммита включён в отчёты о наших прочих попытках верификации: http://15926.org/viewtopic.php?f=5&t=154

С тех пор, как написан пост, прошло довольно много времени. Может, что-то поменялось? Анатолий, не попадались ли вам хэндбуки или стандарты, в которых описывают проактивный подход? Я посмотрел ANSI 649B, военный хэндбук MIL-HDBK-61A(SE) (оба национальные, как видно из названий) - в них говорят про реактивный подход.

Похоже, что зарубежная научная мысль движется в направлении реализации проактивности через "мета": повторяющееся знание выносят не в "типовой чертёж" или "типовой набор элементов", а в очень умный инструментарий и расчётные к нему библиотеки -- и идёт реюз больше инструментов и справочных данных, нежели разработка "конструкторов, из которых вы соберёте бездну моделей". То есть "на поверхности" движение идёт в сторону реактивного подхода (проектируем только по потребности, agile тут мейнстримен), а в глубине разработчиков САПР и PLM движение идёт в сторону облегчения комбинирования уже накопленного знания: и реактивный проект с какого-то момента становится вполне проактивным, а инструментарий быстро склеивает все ранее наработанные технические решения и проверяет их на совместимость. То есть проактивных стандартов при таком подходе особо и быть не должно, если это не стандарты организации (которой нужно сразу в момент выхода на рынок выпустить пару десятков разноуровневых моделей, для чего заранее предусмотреть вариативность). А стандартов организации мы обычно не видим, они все за корпоративными файерволами. И ещё все лидеры PLM по-разному поддерживают сейчас платформенность. Похоже, что в продуктных линейках для мелкосерийного выпуска зоопарка на одной платформе сейчас лидирует PTC.

>> и идёт реюз больше инструментов и справочных данных, нежели разработка "конструкторов, из которых вы соберёте бездну моделей" Если при реюзе кода инструментов чаще всего остаются электронные следы в виде наследования классов и подключения библиотек, то при реюзе основных и справочных данных чаще пользуются копипастой (хорошо если с указанием источника в бумажной документации) при которой нормальных следов почти не остаётся, да и сами справочные данные зачастую скрываются в инструментах. из-за чего очень трудоемко определять , чем одна модель похожа на другую, что у них общего, и что делать если это общее директивно поменялось.