Anatoly Levenchuk (ailev) wrote,
Anatoly Levenchuk
ailev

Почему загнулся STEP, и как жить дальше.

До сих пор приходится отбиваться от сторонников стандарта STEP. Статья, внятно объясняющая, почему STEP плох -- Wim Gielingh, "An assessment of the current state of product data technologies", doi:10.1016/j.cad.2008.06.003 (Computer-Aided Design, Volume 40, Issue 7, July 2008 выпуск по Current State and Future of Product Data Technologies (PDT), Pages 750-759).

Вот, например, одна из причин неудачи 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.
Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

  • 7 comments