Онтологии и SysMoLan
Очередной заход к онтологии системной инженерии, ST4SE (semantic technologies for systems engineering): https://sercuarc.org/wp-content/uploads/2018/06/SE-Ontology_Smith_slides.pdf -- осторожно, там 318 слайдов, презентация декабря 2017 года (видно в "свойствах" файла). Это всё на базе BFO 2.0 в OWL (basic formal ontology, это upper ontology от Barry Smith) -- http://basic-formal-ontology.org/. Все примеры госфинансированы: биология, экология, военные. Подчёркивается авторитарный характер этих онтологий. На BFO порядка 250 таких проектов. В презентации традиционные попытки определить понятия system, lifecycle, capability, function, service и т.д.. -- на базе различалок BFO.
Ещё один подобный заход -- это IOF (industry ontology foundry, предметная область промышленного производства, проект начали в 2016 и готов кусочек на 600 сущностей) на SKOS с участием того же Barry Smith: https://ws680.nist.gov/publication/get_pdf.cfm?pub_id=925807, формальный сайт https://sites.google.com/view/industrialontologies/home.
В мире ISO 15926 тоже всё вяло, но проистекает: в этом году вышла часть 12, ISO/TS 15926-12:2018, Life-cycle integration ontology represented in Web Ontology Language -- https://www.iso.org/standard/70695.html.
Небольшой обзорчик по информационному моделированию и онтологиям (семантическим информационным моделям, как они там пишут) в системах автоматизации зданий знает про ISO 81346, но даже не поминает BFO, IOF, ISO 15926 -- https://www.researchgate.net/publication/321983944_A_survey_on_information_modeling_and_ontologies_in_building_automation
А ещё помним про knowledge graph и связанные с ними всякие SMART-DOG (Strathclyde Mechanical and Aerospace Research Toolbox for Domain Ontology Generation) https://blog.grakn.ai/semi-automatic-generation-of-a-reliable-knowledge-graph-for-space-mission-design-with-grakn-c96061eee2a3 -- имя этим проектам легион, там просто нет "официальной и большой" upper ontology, по большому счёту речь идёт об инженерных онтиках, и инженерных моделях данных (тех же онтиках). Их тьма.
Годы идут, а болото стандартов (standard quagmire) и не думает осушаться. Вот тут мои замечания 2010 года на этот счёт -- "стандарты каталогизации", https://ailev.livejournal.com/852642.html, и там дальше по цепочке ссылок на другие посты про стандарты производства-в-большом, кодификацию, каталогизацию, идентификацию, характеризакцию, классификацию. Похоже, ничего не изменилось, кроме необходимости в этих стандартах определять ещё и слово capability -- оно по-своему определено в каждом стандарте, равно как и слово service, так что улучшения ситуации не произошло.
Весь этот подход с необъятными upper ontology и reference library оказывается невзлетающим: профи разных предметных областей вдруг обнаруживают, что есть кроме их знания стандартов ещё и "нормативное знание", которое нужно выучить, чтобы разобраться с чьим-то чужим знанием. Бабах! Вместо знания своих стандартов и разборки с чужим нужно ещё и выучить "нормативное знание" -- не на уровне кругозора, а на уровне полного знания! А поскольку mapping делается не через попытку совместить смысловые пространства двух наборов концептов в их употреблениях в каких-то текстах (как это делается, например, в работах по переводу с одного языка на другой), а через попытку ручного сведения к отношениям род-вид с настаиванием на последующей возможности формально-логических рассуждений -- то легче не становится, работу эту могут выполнять только эксперты, но обязательно с приглашением онтологов. То есть задача федерирования данных с использованием справочных данных с учётом upper ontology становится не проще, она становится сложней и дороже. Но правительство всё окупает деньгами налогоплательщиков, и дальше идёт уже пиар этих сложностей.
Но если ты собираешься делать SysMoLan Studio, то все эти работы хорошо бы знать: они являются коллекцией тех граблей, на которые можно наступить. При этом системный язык в инженерии можно понимать как хочешь:
-- управление конфигурацией системы, то есть регистрация функциональных, конструктивных, пространственных частей системы и их описаний. IEC 81346 и связанное с ним версионирование/registry. Первые PDM были ровно для этого: не потерять ничего, что творят проектировщики/конструкторы. Описать систему -- выдать сводную заказную спецификацию для системы и передать её куда-то в ERP, систему планирования производства и т.д.. Чтобы в спецификации было что-то кроме кодов, вводится аннотирование. В отчётах -- таблички. Вся информация о компонентах, модулях, местах -- в файлах. SysMoLan для такого использования -- это язык аннотации обозначаемых кодами IEC 81346 объектов, а Studio должна генерировать Excel-таблички. Ура, "системный язык готов".
-- выражение архитектурных решений, то есть демонстрация совмещения функциональной, модульной и пространственной структур. Это означает, что упор делается на какую-то трассировку соответствующих объектов друг ко другу по заранее предписанным отношениям и формализации способов аннотации. Получаем варианты SysMoLan типа SysML или ArchiMate, кому что больше нравится. Дальше можно извлечь объекты и получить спецификацию из предыдущего пункта.
-- Но можно пройти на шаг дальше и научиться трассировать схемы принципиальные/технологические к каким-то 3D моделям прежде всего. Это PLM-системы датацентрические, и в такую PLM уже непосредственно втыкаются CAD, чтобы сама трассировка была "автомагической" -- схема данных такой PLM по сути дела представляет системный язык. ISO 15926 представляет собой попытку сделать ровно вот такой системный язык "интеграции данных жизненного цикла", независимый от конкретной PLM (а во многих реальных PLM просто по факту использовались предварительные наработки по ISO 15926 в их версии 1997 года). А язык типа SysML или ArchiMate там есть? А как же! На нём рисуется "логическая архитектура" перед тем, как поручить те или иные части системы спроектировать в CAD и после готовности материалов из CAD они трассируются к созданным объектам. Беда только в том, что это идеальная конструкция не выживала в силу монструозности: PLM системы существовали и существуют, с болью интегрируя результаты работы различных CAD и систем моделирования прочности и мультифизики (а это не системная инженерия, а инженерия по специальности), а рядом появляются "системноинженерные системы" на базе каких-то вариантов архитектурных языков. И эти системы в особо крупных военных проектах выживают, но не слишком интегрируясь с PLM, а в не особо крупных проектах так вместо них используются просто тематические CAD (типа редакторов принципиальных схем и технологических диаграмм, крепко адаптированных для конкретной предметной области). Можно поглядеть ещё на аналогичную жизнь в архитектуре предприятия: архитектурные диаграммы (почему-то сразу предполагается графическая/диаграммная форма!) предприятия (например, на ArchiMate) просят не путать с архитектурными описаниями (чаще всего тоже диаграммами, причём на UML) софта, оговаривают их неподробность (типа "идите в BPMN и другие стандарты/моделеры за подробностями"), но почему-то делают сверку архитектуры IT-решения с СMDB (база данных менеджмента конфигурации для IT-службы). По факту архитектура предприятия трассируется и к следующему уровню инженерных решений "с подробностью, достаточной для изготовления", и оказывается частью управления конфигурацией (ибо новые объекты прежде всего появляются в ней). Ну, и современные варианты архитектуры предприятия включают в себя бизнес-архитектуру и целеполагание -- в "обычной" системной инженерии это требования. Прикасаешься к архитектурному языку, тут же огребаешь и потребности-требования, и управление конфигурацией, и (с учётом всех трассировок) PLM с её вечной задачей мэппинга различных видов CAD и необходимостью иметь "генератор конверторов" прямо из коробки.
-- ... тут ещё много идей, что считать "системным языком". Например, это онтологический язык, в которой понятие "система" является центральным для управления вниманием, а онтология понимается как раз как чеклист для управления вниманием: мир в этой онтологии состоит не из объектов, а из систем, и эти системы сразу по-разному описываются разными стейкхолдерами, исходя из их интересов. Это ничего не добавляет, но обозвал же Ян Диец свои архитектурные соображения по устройству организации "онтология предприятия", и Захман тоже назвал свой архитектурный подход "онтологией предприятия" -- вот и SysMoLan можно обозвать systems ontology со всей сопутствующей дискуссией про то, как переводить -- "онтология систем" или "системная онтология" (победит "системная онтология"). И да, не забыть всунуть в эту онтологию соображения Диеца и Захмана -- ибо нужно описывать не только целевые системы, но и обеспечивающие! SysMoLan должен и архитектуру предприятия описывать! Так что учитывать нужно не только инженерные онтологии, но и менеджерские/организационные.
В любом случае от обсуждения онтологического статуса объектов SysMoLan не уйти. По факту SysMoLan должен быть какой-то системной (системноинженерной и системноменеджерской) онтологией и моделью данных. Это означает, что:
а) нельзя выдумывать эту онтологию из головы. И нужно как-то вписываться в текущие онтологические наработки. Понятия брать из инженерных стандартов, а вот что там в части upper ontology и какой там уровень формальности -- это нужно тщательно выбирать. Успех ArchiMate IMHO в том, что там существенно смягчённые онтологические нормы. Впрочем, SysML в этом плане не хуже. SysMoLan должен быть суперкомпактен, ибо даже ArchiMate считают излишне богатым. SysMoLan не должен быть полноценным онтологическим языком, в котором из коробки достаётся BFO и/или ISO 15926 и/или IOF, и/или даже ST4SE -- это угробит проект на старте. Он должен быть суперкомпактным для очень узкого круга задач, минимального числа сценариев. Но этот суперкомпактный язык онтологически должен быть получше ArchiMate и SysML -- иначе зачем мы его делаем?! Нас же в текущих языках не устраивает именно отсутствие онтологии системного подхода! И это Сцилла.
б) Харибда в том, что к архитектуре тут же захочется трассировать все остальные описания (например, архитектурные расчёты), и страстно захочется PLM с развитым мэппингом, и SysMoLan Studio окажется эпицентром в каком-то Smart Data Lake со всеми вытекающими. Если делать SysMoLan как DSL на Julia, то это не выглядит чем-то страшным, но это хорошо бы предусмотреть на старте. Если уж сказал слово "онтология", то мэппинг у тебя будет -- для других целей обычно без этого слова обходятся. Тут системная онтология отходит на десятый план и на первый план выходит обычное моделирование данных -- вся дискусссия из https://www.infoq.com/news/2018/10/das-modern-data-architecture (это William McKnight on Data Platforms and Creating a Modern Data Architecture) к нам в гости. И фраза из презентации Barry Smith по первой ссылке текущего поста о том, что "онтологические вопросы сводились к вопросу о моделировании данных, это и губило проекты" (ну, или наоборот, позволяло проектам выживать -- никто ж не знает!).
в) А есть больше чем Сцилла и Харибда: в тот момент, когда захочется что-то делать с самой архитектурой -- все эти search-oriented architecture, differential architecture. Закладываться сразу на это? Так в этом никто ничего не понимает. Но современный архитектурный язык должен ползти как раз в этом направлении. И онтология SysMoLan тогда должна быть современной, на вероятностной логике -- тоже, желательно, "из коробки". Иначе риск унаследовать всю головную боль с болотом онтологических стандартов. Я рассматриваю текст про language models, knowledge graphs, relational models https://ailev.livejournal.com/1449229.html ровно по этой линии, заодно решая проблему мэппинга инженерных описаний как проблему перевода с языка на язык. Но это абсолютно исследовательское направление в абсолютно неизведанных водах, когда это всё дойдёт до практики -- непонятно, каких это потребует ресурсов -- преогромных. Но зато полный фронтир и есть чем хвастаться. Из минусов -- за это никто не заплатит, если не найдётся какой-то меценат. Не в России, конечно. И такой меценат не найдётся. То есть в ближайшей перспективе года-двух это утопия, но уже в трёхлетней перспективе differentiable architecture будет очень, очень горячей темой -- и если заняться сейчас, то через три года будем в эпицентре (но кушать эти три года будет совсем нечего, в этом-то и утопичность: "невозможность" и "крайняя привлекательность" одновременно).
У меня такое ощущение, что весь наш сегодняшний опыт показывает ровно те места, где лежат хорошо заметные рельсы антикварных неудачных технологий или суперфронтирных несуществующих технологий, в совокупности надёжно заводящие разработку системного языка и его моделера/студии в тупик.
Итого: нужно срочно определиться с цепочкой "метамодель самого SysMoLan" -- "SysMoLan как метамодель для моделей систем" -- "модели систем, написанные на SysMoLan". С учётом всего тут написанного. При этом одним глазом смотреть сразу на инженерные стандарты и инженерные проекты (что делают и все остальные создатели языков и онтологий), другим поглядывая на инженерные онтологии (скажем, из первых абзацев текущего поста -- нужно же повторноиспользовать чужой труд по онтологизации!), а третьим глазом пытаясь высмотреть в тумане будущего "метамодель для дифференцируемой модели" (а про "дифференцируемые метамодели" я не пишу, и так уже всё сложно).
Описание проекта SysMoLan Studio -- https://ailev.livejournal.com/1446524.html, и там есть все нужные ссылки, чтобы понять проект.
Ещё один подобный заход -- это IOF (industry ontology foundry, предметная область промышленного производства, проект начали в 2016 и готов кусочек на 600 сущностей) на SKOS с участием того же Barry Smith: https://ws680.nist.gov/publication/get_pdf.cfm?pub_id=925807, формальный сайт https://sites.google.com/view/industrialontologies/home.
В мире ISO 15926 тоже всё вяло, но проистекает: в этом году вышла часть 12, ISO/TS 15926-12:2018, Life-cycle integration ontology represented in Web Ontology Language -- https://www.iso.org/standard/70695.html.
Небольшой обзорчик по информационному моделированию и онтологиям (семантическим информационным моделям, как они там пишут) в системах автоматизации зданий знает про ISO 81346, но даже не поминает BFO, IOF, ISO 15926 -- https://www.researchgate.net/publication/321983944_A_survey_on_information_modeling_and_ontologies_in_building_automation
А ещё помним про knowledge graph и связанные с ними всякие SMART-DOG (Strathclyde Mechanical and Aerospace Research Toolbox for Domain Ontology Generation) https://blog.grakn.ai/semi-automatic-generation-of-a-reliable-knowledge-graph-for-space-mission-design-with-grakn-c96061eee2a3 -- имя этим проектам легион, там просто нет "официальной и большой" upper ontology, по большому счёту речь идёт об инженерных онтиках, и инженерных моделях данных (тех же онтиках). Их тьма.
Годы идут, а болото стандартов (standard quagmire) и не думает осушаться. Вот тут мои замечания 2010 года на этот счёт -- "стандарты каталогизации", https://ailev.livejournal.com/852642.html, и там дальше по цепочке ссылок на другие посты про стандарты производства-в-большом, кодификацию, каталогизацию, идентификацию, характеризакцию, классификацию. Похоже, ничего не изменилось, кроме необходимости в этих стандартах определять ещё и слово capability -- оно по-своему определено в каждом стандарте, равно как и слово service, так что улучшения ситуации не произошло.
Весь этот подход с необъятными upper ontology и reference library оказывается невзлетающим: профи разных предметных областей вдруг обнаруживают, что есть кроме их знания стандартов ещё и "нормативное знание", которое нужно выучить, чтобы разобраться с чьим-то чужим знанием. Бабах! Вместо знания своих стандартов и разборки с чужим нужно ещё и выучить "нормативное знание" -- не на уровне кругозора, а на уровне полного знания! А поскольку mapping делается не через попытку совместить смысловые пространства двух наборов концептов в их употреблениях в каких-то текстах (как это делается, например, в работах по переводу с одного языка на другой), а через попытку ручного сведения к отношениям род-вид с настаиванием на последующей возможности формально-логических рассуждений -- то легче не становится, работу эту могут выполнять только эксперты, но обязательно с приглашением онтологов. То есть задача федерирования данных с использованием справочных данных с учётом upper ontology становится не проще, она становится сложней и дороже. Но правительство всё окупает деньгами налогоплательщиков, и дальше идёт уже пиар этих сложностей.
Но если ты собираешься делать SysMoLan Studio, то все эти работы хорошо бы знать: они являются коллекцией тех граблей, на которые можно наступить. При этом системный язык в инженерии можно понимать как хочешь:
-- управление конфигурацией системы, то есть регистрация функциональных, конструктивных, пространственных частей системы и их описаний. IEC 81346 и связанное с ним версионирование/registry. Первые PDM были ровно для этого: не потерять ничего, что творят проектировщики/конструкторы. Описать систему -- выдать сводную заказную спецификацию для системы и передать её куда-то в ERP, систему планирования производства и т.д.. Чтобы в спецификации было что-то кроме кодов, вводится аннотирование. В отчётах -- таблички. Вся информация о компонентах, модулях, местах -- в файлах. SysMoLan для такого использования -- это язык аннотации обозначаемых кодами IEC 81346 объектов, а Studio должна генерировать Excel-таблички. Ура, "системный язык готов".
-- выражение архитектурных решений, то есть демонстрация совмещения функциональной, модульной и пространственной структур. Это означает, что упор делается на какую-то трассировку соответствующих объектов друг ко другу по заранее предписанным отношениям и формализации способов аннотации. Получаем варианты SysMoLan типа SysML или ArchiMate, кому что больше нравится. Дальше можно извлечь объекты и получить спецификацию из предыдущего пункта.
-- Но можно пройти на шаг дальше и научиться трассировать схемы принципиальные/технологические к каким-то 3D моделям прежде всего. Это PLM-системы датацентрические, и в такую PLM уже непосредственно втыкаются CAD, чтобы сама трассировка была "автомагической" -- схема данных такой PLM по сути дела представляет системный язык. ISO 15926 представляет собой попытку сделать ровно вот такой системный язык "интеграции данных жизненного цикла", независимый от конкретной PLM (а во многих реальных PLM просто по факту использовались предварительные наработки по ISO 15926 в их версии 1997 года). А язык типа SysML или ArchiMate там есть? А как же! На нём рисуется "логическая архитектура" перед тем, как поручить те или иные части системы спроектировать в CAD и после готовности материалов из CAD они трассируются к созданным объектам. Беда только в том, что это идеальная конструкция не выживала в силу монструозности: PLM системы существовали и существуют, с болью интегрируя результаты работы различных CAD и систем моделирования прочности и мультифизики (а это не системная инженерия, а инженерия по специальности), а рядом появляются "системноинженерные системы" на базе каких-то вариантов архитектурных языков. И эти системы в особо крупных военных проектах выживают, но не слишком интегрируясь с PLM, а в не особо крупных проектах так вместо них используются просто тематические CAD (типа редакторов принципиальных схем и технологических диаграмм, крепко адаптированных для конкретной предметной области). Можно поглядеть ещё на аналогичную жизнь в архитектуре предприятия: архитектурные диаграммы (почему-то сразу предполагается графическая/диаграммная форма!) предприятия (например, на ArchiMate) просят не путать с архитектурными описаниями (чаще всего тоже диаграммами, причём на UML) софта, оговаривают их неподробность (типа "идите в BPMN и другие стандарты/моделеры за подробностями"), но почему-то делают сверку архитектуры IT-решения с СMDB (база данных менеджмента конфигурации для IT-службы). По факту архитектура предприятия трассируется и к следующему уровню инженерных решений "с подробностью, достаточной для изготовления", и оказывается частью управления конфигурацией (ибо новые объекты прежде всего появляются в ней). Ну, и современные варианты архитектуры предприятия включают в себя бизнес-архитектуру и целеполагание -- в "обычной" системной инженерии это требования. Прикасаешься к архитектурному языку, тут же огребаешь и потребности-требования, и управление конфигурацией, и (с учётом всех трассировок) PLM с её вечной задачей мэппинга различных видов CAD и необходимостью иметь "генератор конверторов" прямо из коробки.
-- ... тут ещё много идей, что считать "системным языком". Например, это онтологический язык, в которой понятие "система" является центральным для управления вниманием, а онтология понимается как раз как чеклист для управления вниманием: мир в этой онтологии состоит не из объектов, а из систем, и эти системы сразу по-разному описываются разными стейкхолдерами, исходя из их интересов. Это ничего не добавляет, но обозвал же Ян Диец свои архитектурные соображения по устройству организации "онтология предприятия", и Захман тоже назвал свой архитектурный подход "онтологией предприятия" -- вот и SysMoLan можно обозвать systems ontology со всей сопутствующей дискуссией про то, как переводить -- "онтология систем" или "системная онтология" (победит "системная онтология"). И да, не забыть всунуть в эту онтологию соображения Диеца и Захмана -- ибо нужно описывать не только целевые системы, но и обеспечивающие! SysMoLan должен и архитектуру предприятия описывать! Так что учитывать нужно не только инженерные онтологии, но и менеджерские/организационные.
В любом случае от обсуждения онтологического статуса объектов SysMoLan не уйти. По факту SysMoLan должен быть какой-то системной (системноинженерной и системноменеджерской) онтологией и моделью данных. Это означает, что:
а) нельзя выдумывать эту онтологию из головы. И нужно как-то вписываться в текущие онтологические наработки. Понятия брать из инженерных стандартов, а вот что там в части upper ontology и какой там уровень формальности -- это нужно тщательно выбирать. Успех ArchiMate IMHO в том, что там существенно смягчённые онтологические нормы. Впрочем, SysML в этом плане не хуже. SysMoLan должен быть суперкомпактен, ибо даже ArchiMate считают излишне богатым. SysMoLan не должен быть полноценным онтологическим языком, в котором из коробки достаётся BFO и/или ISO 15926 и/или IOF, и/или даже ST4SE -- это угробит проект на старте. Он должен быть суперкомпактным для очень узкого круга задач, минимального числа сценариев. Но этот суперкомпактный язык онтологически должен быть получше ArchiMate и SysML -- иначе зачем мы его делаем?! Нас же в текущих языках не устраивает именно отсутствие онтологии системного подхода! И это Сцилла.
б) Харибда в том, что к архитектуре тут же захочется трассировать все остальные описания (например, архитектурные расчёты), и страстно захочется PLM с развитым мэппингом, и SysMoLan Studio окажется эпицентром в каком-то Smart Data Lake со всеми вытекающими. Если делать SysMoLan как DSL на Julia, то это не выглядит чем-то страшным, но это хорошо бы предусмотреть на старте. Если уж сказал слово "онтология", то мэппинг у тебя будет -- для других целей обычно без этого слова обходятся. Тут системная онтология отходит на десятый план и на первый план выходит обычное моделирование данных -- вся дискусссия из https://www.infoq.com/news/2018/10/das-modern-data-architecture (это William McKnight on Data Platforms and Creating a Modern Data Architecture) к нам в гости. И фраза из презентации Barry Smith по первой ссылке текущего поста о том, что "онтологические вопросы сводились к вопросу о моделировании данных, это и губило проекты" (ну, или наоборот, позволяло проектам выживать -- никто ж не знает!).
в) А есть больше чем Сцилла и Харибда: в тот момент, когда захочется что-то делать с самой архитектурой -- все эти search-oriented architecture, differential architecture. Закладываться сразу на это? Так в этом никто ничего не понимает. Но современный архитектурный язык должен ползти как раз в этом направлении. И онтология SysMoLan тогда должна быть современной, на вероятностной логике -- тоже, желательно, "из коробки". Иначе риск унаследовать всю головную боль с болотом онтологических стандартов. Я рассматриваю текст про language models, knowledge graphs, relational models https://ailev.livejournal.com/1449229.html ровно по этой линии, заодно решая проблему мэппинга инженерных описаний как проблему перевода с языка на язык. Но это абсолютно исследовательское направление в абсолютно неизведанных водах, когда это всё дойдёт до практики -- непонятно, каких это потребует ресурсов -- преогромных. Но зато полный фронтир и есть чем хвастаться. Из минусов -- за это никто не заплатит, если не найдётся какой-то меценат. Не в России, конечно. И такой меценат не найдётся. То есть в ближайшей перспективе года-двух это утопия, но уже в трёхлетней перспективе differentiable architecture будет очень, очень горячей темой -- и если заняться сейчас, то через три года будем в эпицентре (но кушать эти три года будет совсем нечего, в этом-то и утопичность: "невозможность" и "крайняя привлекательность" одновременно).
У меня такое ощущение, что весь наш сегодняшний опыт показывает ровно те места, где лежат хорошо заметные рельсы антикварных неудачных технологий или суперфронтирных несуществующих технологий, в совокупности надёжно заводящие разработку системного языка и его моделера/студии в тупик.
Итого: нужно срочно определиться с цепочкой "метамодель самого SysMoLan" -- "SysMoLan как метамодель для моделей систем" -- "модели систем, написанные на SysMoLan". С учётом всего тут написанного. При этом одним глазом смотреть сразу на инженерные стандарты и инженерные проекты (что делают и все остальные создатели языков и онтологий), другим поглядывая на инженерные онтологии (скажем, из первых абзацев текущего поста -- нужно же повторноиспользовать чужой труд по онтологизации!), а третьим глазом пытаясь высмотреть в тумане будущего "метамодель для дифференцируемой модели" (а про "дифференцируемые метамодели" я не пишу, и так уже всё сложно).
Описание проекта SysMoLan Studio -- https://ailev.livejournal.com/1446524.html, и там есть все нужные ссылки, чтобы понять проект.