Anatoly Levenchuk (ailev) wrote in dot15926,
Anatoly Levenchuk
ailev
dot15926

Categories:

К созданию методологии использования ISO 15926

В настоящий момент мне известны следующие обрывки методологии использования ISO 15926 (кроме разных наборов слайдов, или зачастую одиночных слайдов, которые предполагают устное комментирование авторами):

1. Часть 1 стандарта, описывающая "пирамиду справочных данных" и прочие важные сведения (важность которых трудно понять, пока не приступишь к какому-то конкретному проекту).
2. Раздел 4 Части 2 "Fundamental concepts and assumptions" -- как "кодировать на ассемблере", т.е. в языке Части 2.
3. Часть 7, описывающая способ подъема уровня языка шаблонами, и раздел про полное определение шаблона в части 8.
4. Проект части 6 про то, как оформлять записи (reference data items) в RDL -- как формулировать "определения" и т.д.
5. Полуготовое руководство "Beginners's guide to 15926 modeling", пока всего 15 страниц крупным шрифтом с комментариями -- https://www.posccaesar.org/svn/pub/SIG/MMT/MMT2010_revisedBasedOnComments.pdf
6. Template characterization methodology -- https://www.posccaesar.org/wiki/TemplateCharacterization (старый документы, еще в старинной терминологии short-hand и long-hand templates).
7. ISO15926 Primer -- https://www.posccaesar.org/wiki/ISO15926Primer (больше о том, что такое ISO 15926, чем как с ним работать).
8. ISO 15926 HOWTO -- https://www.posccaesar.org/wiki/ISO15926HowTo_Introduction, но не нужно ждать многого от этих недоделанных страниц
9. Руководство по соответствию -- https://www.posccaesar.org/wiki/IdsAdiComplianceSpecification
10. Ряд демонстрирующихся на разных семинарах слайдов Магне, в которых он приводит почти сотню примеров кодирования шаблонов (на самом деле -- графов поднятия-опускания, а то и вообще "паттернов" в виде куска семантической сетки в языке Части 2).
11. Наша инициатива -- .15926M, но эту методику только предстоит разработать (чему и посвящен этот постинг).

В презентациях можно также усмотреть несколько полностью разных стилей использования, и несколько уровней соответствия. Например, использование только части 2 для мэппинга (так называемое "промышленное использование") против пополнения справочных данных части 4 "промежуточными" классами из учебников и стандартов ("стандартное использование"). Также можно указать на моделирование и мэппинг в терминах сигнатур шаблонов только, и с указанием графов поднятия-опускания. Возможность частичного соответствия также добавляет разнообразия в подходах к использованию ISO 15926.

Тем самым, никакой особой "методологии" на сегодня не существует -- она заключается главным образом в комментариях, которые дают "модельеры с черным поясом". Более того, существую серьезные расхождения во мнениях этих "модельеров с черным поясом" по поводу методологии моделирования -- взять хотя бы дискуссию вокруг FunctionalPhysicalObject, развернувшуюся в группе "ISO 15926" в LinkedIn. Есть различия и в экспертизе самих "чернопоясников", например использование логики (аксиом шаблонов) или упор на "инженерность-без-этой-вашей-FOL".

Возможные роли для методологии:
1. Разъяснять, "с какой стороны подойти к корове". В данном случае -- к слону (любимое сравнение авторов стандарта, подчеркивающее огромность стандарта и неохватность его содержания одним человеком). Проблема в том, что сам многочастный стандарт не является "учебным текстом".
2. Обращать внимание на важные моменты, которые мало кто вычитывает из стандарта с первого раза (например, зачем в стандарте есть не только class, но и class_of_class, и почему столько споров вокруг FunctionalPhysicalObject). Ну, или разъяснять накопившиеся за много лет разночтения (типа невыразимости различения классификации, членства и специализации Части 2 в EXPRESS, но выразимости их в OWL -- "классофклассика" https://www.posccaesar.org/wiki/ISO15926inOWLPart2EntityMembership).
3. Дополнять стандарт тем, что в нем не написано:
-- руководство по локализации. Вообще, "в стандарте есть всё необходимое для создания словарей" -- но никто не знает, как нужно делать многоязычность в RDL.
-- IT-инфраструктура в типичных производственных конфигурациях САПР/PLM/ERP/EAM -- все эти data stores и data warehouse, трехсхемная архитектура, мэппинги, хранилища RDL и т.д.. Тут нужно учесть, что речь даже не идет о будущей Части 9 (которую пока никто не видел, и в которой ожидается стандартизация SPARQL-запросов к федерации RDL, которая предполагается соответствующей Части 8 -- глядите http://www.infowebml.ws/ и http://15926.org для информации двухлетней давности, а для свежей скудной информации http://iringug.org), а о растолковывании невнятного текста Части 1.
-- технология мэппинга и использования адаптеров (IRING, XMpLant и разные другие).
-- технология data handover,
-- как организовать модульность (онтолеты)
-- как организовать и администрировать RDL
-- как воткнуться в федерацию RDL,
4. Разъяснять не только то, что задумывалось в Части 2, но и "что получилось в Части 4", и "что получилось в WIP/RDS" (ибо хотели, как лучше -- а получилось, как всегда). Сейчас это -- устное предание.
5. Разъяснять template characterization в разных "особых случаях", типа "шаблоны для кодировки по KKS" или "выражение закупаемого по каталогу оборудования для тэга в составе функциональной системы".
6. Излагать технологию ISO 15926 для конкретной конфигурации софта какого-то поставщика (или набора софта разных поставщиков).

Трудность тут в том, что методология не должна просто "переписывать стандарт" -- она не замена стандарта, а дополнение к стандарту. В методологии, например, может говориться, почему в стандарте выбрано то или иное решение -- чтобы следующий методологии человек случайно не пошел "поперек стандарта", не поняв его "духа".

Есть два разных понимания методологии:
а) это стандарт действия, которому необходимо следовать
б) это учебник, по которому можно научиться

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

В случае (б) нормативные высказывания вкраплены в объясняющий и растолковывающий их текст -- и тем самым существенно снижается "нормативный градус" в пользу дидактичности.

Опять же, остается тонкая граница между уточнением и дополнением стандарта новыми нормами, и дидактичной обработкой текста стандарта плюс нормативного текста методологии.

Подход ISO 24744 и ISO 24774 (обратите внимание: это разные номера стандартов, это не опечатка!) предполагает структурное разделение нормативной части и "руководств", но ничего не говорит о возможном формате итогового текста. Пока мы не сделали .15926LMN, у нас нет софта для подобного структурирования. Поэтому придется сразу писать "вордовый документ", склоняясь к "шрифтовому" разделению нормативной, обосновывающей и дидактической/поясняющей информации.

Еще один вопрос -- это предмет методологии (scope). Понятно, что Ontology Handbook (в котором ISO 15926 занимает весьма немного места) -- это книжка на много сотен страниц. Можно начинать с того, "что такое EXPRESS" (что довольно актуально, ибо описания этого языка на дороге не валяются, а Часть вторая написана в нём -- или наоборот, неактуально, ибо реализаций в EXPRESS на сегодня по факту нет). Но тогда можно просто не дойти до сути дела. Можно приступить сразу к сути дела: "как моделировать промышленные кодировки, используя встроенный в Часть 2 парсинг текстовых строк на правую-левую части -- и оформлять это шаблонами", но это явно "дело нижнего уровня" -- и такие дела нужно объединять в мероприятия, мероприятия в практики, практики -- в дисциплины.

Учитывая, что "справочные данные" в ISO 15926 включают в том числе любые часто используемые классы (например, данные каталога оборудования), а RDL определяется просто как "набор/collection справочных данных", мы тут отходим от терминологии с RDL и переходим к терминологии "схема данных" и "НСИ" (считая, что в RDL хранится и схема данных, и НСИ).

Практики дисциплины "Инженерия схемы данных жизненного цикла":
1. Моделирование, с мероприятиями/паттернами кодирования:
-- общие принципы моделирования ("это не объект-ориентированное программирование, а онтологическое моделирование данных", разъяснение 4D)
-- типовые паттерны (архитектура "функциональный тэг, спецификация, объект в каталоге, железка", заводские кодировки типа KKS или RDS-PP, стандарты с типоразмерами и т.д.), таксономия этих паттернов/шаблонов моделирования должна оговариваться отдельно.
-- оформление шаблонами (как "порезать огромную семантическую сетку на шаблоны")
2. Мэппинг ("ISO 15926 outside") и работа с адаптерами для конкретного хранилища/склада данных.
3. Управление схемой данных (разворачивание/организация и ведение схемы данных в форме RDL), в том числе Handover схемы данных.
4. Локализация схемы данных.
5. Управление данными (экземплярами, а не схемой) с использованием схемы данных - handover.
6. Постановка метода инженерии схемы данных жизненного цикла

Дисциплина "Ведение нормативно-справочной информации" (не хочется использовать "управление НСИ", или "инженерия НСИ")
1. Практика ведения Каталогов промышленной продукции
2. Практика ведения Нормативных баз данных (техрегулирование, Sarbanes-Oxley и т.д.)

Дисциплина "Управление данными инжинирингового проекта"
1. Практика Plant Design and Project Data handover

Дисциплина "Инженерия IT-инфраструктуры для ISO 15926"
1. Практики разворачивания систем конкретных поставщиков софта в варианте использования ISO 15926

В методе, конечно, указываются не только практики -- еще и типовые жизненные циклы, и типовые профессиональные роли и их инструментарий, а еще языки с нотациями и рабочие продукты. Но это всё потом.

Комментируйте.
Subscribe

  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

  • 5 comments