Вот, например, одна из причин неудачи STEP: как вместо нейтральной модели данных получилось изобилие "стандартных обменов данными" (APxCCn -- это обмен данными по application protocol X и conformance classes N -- ибо STEP это винегрет из многих маленьких слабо связанных между собой стандартов, совместимых не по содержанию, а только по форме):
Кроме того, неминуемы потери данных при каждом обмене в силу того, что любой протокол STEP не покрывает всех данных, которые возможно передать при таком обмене: нужно предусматривать расширения этого стандарта (аргумент прост: любой поставщик софта пытается отличиться на рынке, и предлагает бОльшую функциональность, чем это предусматривается любым на момент создания софта стандартом).
Кроме того, STEP не решает проблемы "объект-ориентированности" (что атрибут для одного проекта, то является объектом для другого -- и информация теряется в силу невозможности отождествления объекта одного приложения с атрибутом другого). Это жестко формулируется, как "STEP не нейтральный формат" (то есть он делает выбор в пользу тех приложений, в которых сущность является объектом, а не атрибутом).
Кроме того STEP оказался неудачен в применении трёхслойной архитектуры данных (различения концептуальной, внешней и физической схем данных). Начинали работать с трёхслойной архитектурой, а потом кончилось тем, что концептуальный уровень стандартизировать не удалось, он рассыпался на мелкие несовместимые части.
Основные выводы статьи:
-- парадигма обмена данными между приложениями (PDM, product data management) плохая, вместо неё нужно искать другие варианты (как ориентир предлагается вариант с общей информационной моделью, PLM -- product life cycle management).
-- вместо допотопных языков типа EXPRESS нужно двигаться в сторону более выразительных языков (например, OWL).
-- вообще нужно задуматься над концепцией "нейтрального формата": время выдвижения к нему новых требований сильно меньше времени, которое требуется на стандартизацию. Он всегда будет теоретически неадекватен, и отставать от жизни.
Мне кажется, что сообщество разработчиков PLM и ISO 15926 ответило на первую пару из поднятых вопросов:
-- по факту архитектура современных PLM как раз предполагает не столько обмен данными между приложениями и не "делёжку данными" от одного приложения к другому, сколько интеграцию данных в специальном репозитории (SPF, ENOVIA, NET Platform и т.д.).
-- по факту модель данных в ISO 15926 уже факт-ориентирована, а семантика определяется не EXPRESS (как в STEP), но RDF (я всё-таки противлюсь идее, что семантика базовых отношений онтологии ISO 15926 совпадает с семантикой базовых отношений онтологии OWL).
Плюс получены ответы на многие другие поднятые в стандарте проблемы:
-- механизм расширения стандарта путём разрабатываемой сообществом федерации RDL позволяет не отставать во времени от развития софта приложений.
-- в части 12 (Gellish), похоже, уже поднимается вопрос о встроенном электронном подписании передаваемых проектных данных.
-- точность представления информации об изменениях в 4D-парадигме в разы больше, нежели в 3D.
-- грамотно разработанная upper ontology решает не все вопросы, но многие (хотя есть критика и этого подхода: тезис о принципиальной невозможности существования каких-то развитых upper ontology, кроме очень лёгких таксономий для облегчения хранения, но не обработки данных. Но эта критика идет не от разработчиков инженерных систем с обилием формальных моделей, а от любителей поразбираться с компьютерным пониманием естественного языка).
-- ну, и так далее по мелочи (каждая из каковых мелочей не такая уж и мелочь получается, за 25 лет разработки много чего накопилось).
Но на вопрос о принципиальной невозможности нейтральной репрезентации данных тусовка ISO 15926 очевидным образом (т.е. опытом успешных применений) пока не ответила, в том числе в силу описанных в статье других трудностей с внедрением любых интеграционных решений: юридической сложности data handover не через бумагу, желания каждого вендора установить свой стандарт де-факто и т.д.. Так что саму возможность интеграции реальных данных в реальных проектах, использующих нейтральный формат данных, нужно специально проверять. Косвенно неуспех многих и многих проектов PLM (у которых де-факто архитектура "Нейтральная схема аутсайд" применяется к скупленным крупными поставщиками многим более мелким несовместимым САПР более мелких поставщиков) может свидетельствовать как раз о такой невозможности.
С другой стороны, внутренняя структура данных всех современных PLM настолько неуклюжа, и так стара (это "EPISTLE scheme snapshot 1997", а делали его выходцы из разработки STEP), что может сработать подход "ISO 15926 Inside": нейтральное хранилище данных, над которым возможна лёгкая разработка полноценных приложений или "умных" -- то есть "прагматичных", т.е. учитывающих контекст всей модели данных, а не просто семантику/значение каждого отдельного понятия -- адаптеров/трансляторов к другим приложениям.
Каковым ISO 15926 Inside мы и занимаемся в
dot15926.