WITS/WITSML

[REA]

Дорогие коллеги! А не кажется ли вам, что вы разрабатываете "молоток для забивания зеленых гвоздей"? Я не настолько силен в программировании, но знаю о существовании ряда СУБД не понаслышке. И связаннх с ним (рядом) всевозможных АРМов. Полагаю, я на знакомом языке изъясняюсь. Ведь это работа для техника - сконфигурировать СУБД (любую, или выбрать подходящую) для конкретного АРМа. И в CDT, и в DTCIS, и в АМТ-121 (это то, с чем я работал) есть всевозможные редакторы, в тч экранные. И "простому" пользователю-оператору освоить их не составляет великого труда. Какой же еще зеленый велосипед вы так скрупулезно изобретаете? Я не говорю, что не надо. Надо! Но... Что-то в консерватории не так... А?

Все несколько сложнее. Помимо самих СУБД должны быть спроектированы структуры данных (это довольно трудоемкая работа, требующая знания предметной области). Кроме того есть еще форматы и протоколы передачи данных - о них собственно и речь.

[PDS]

Все несколько сложнее. Помимо самих СУБД должны быть спроектированы структуры данных (это довольно трудоемкая работа, требующая знания предметной области). Кроме того есть еще форматы и протоколы передачи данных - о них собственно и речь.

В таких проектах нужно заниматься проектированием еще раньше, нежели создавать структуру данных в базе. Нужно спроектировать основу, разбить на модули, создать логическое ядро так сказать. Плюс выбрать технологии. Вот один из примеров. Я думаю все знают DTCIS. Создавалось оно на заре всеобщей эйфории над технологией COM, ну и разработчики думали что вот она халява, не нужны никакие сокеты и разработка протоколов. Но какой же геморрой они создали таким решением. Потом делали какой то костыль, для конвертирования СОМ и сокетов. Насколько были грамотные настройщики станций в ИМС(кто запускал станции с нуля), но не один не понимал как настроить этот чертовый СОМ по сети.

[Prepodobie]

Ну хорошо, подключите в режиме on-line режиме по стандарту WITSML 1.3.1 станцию АМТ к серверу Petrel, пользуясь экранными редакторами??

[REA]

Все несколько сложнее. Помимо самих СУБД должны быть спроектированы структуры данных (это довольно трудоемкая работа, требующая знания предметной области). Кроме того есть еще форматы и протоколы передачи данных - о них собственно и речь.

В таких проектах нужно заниматься проектированием еще раньше, нежели создавать структуру данных в базе. Нужно спроектировать основу, разбить на модули, создать логическое ядро так сказать. Плюс выбрать технологии. Вот один из примеров. Я думаю все знают DTCIS. Создавалось оно на заре всеобщей эйфории над технологией COM, ну и разработчики думали что вот она халява, не нужны никакие сокеты и разработка протоколов. Но какой же геморрой они создали таким решением. Потом делали какой то костыль, для конвертирования СОМ и сокетов. Насколько были грамотные настройщики станций в ИМС(кто запускал станции с нуля), но не один не понимал как настроить этот чертовый СОМ по сети.

Абсолютно согласен. Я раз пять пытался осилить внутреннюю архитектуру COM/DCOM и т.д. и так и не осилил. Она сама по себе достаточно мутна сделана. ИМС решили видимо не искать легких путей.

[Prepodobie]

Все несколько сложнее. Помимо самих СУБД должны быть спроектированы структуры данных (это довольно трудоемкая работа, требующая знания предметной области). Кроме того есть еще форматы и протоколы передачи данных - о них собственно и речь.

В таких проектах нужно заниматься проектированием еще раньше, нежели создавать структуру данных в базе. Нужно спроектировать основу, разбить на модули, создать логическое ядро так сказать. Плюс выбрать технологии. Вот один из примеров. Я думаю все знают DTCIS. Создавалось оно на заре всеобщей эйфории над технологией COM, ну и разработчики думали что вот она халява, не нужны никакие сокеты и разработка протоколов. Но какой же геморрой они создали таким решением. Потом делали какой то костыль, для конвертирования СОМ и сокетов. Насколько были грамотные настройщики станций в ИМС(кто запускал станции с нуля), но не один не понимал как настроить этот чертовый СОМ по сети.

В вот вопрос господа инженеры и программисты
Создают американцы стандарты, а что такое стандарт?
Это по существу формализованные данные - каждый объект и его характеристики приведены к некому стандарту- посылать данные по стандарту и никак более. И тут возникает вопрос а можно ли описать все процессы допустим при бурении неким стандартом. Ну небольшие станции со стандартным набором функций наверное можно, номенклатура данных небольшая. А вот описать в стандарте процесс добычи, поддержания ППД, работу УПН -это сколько же нужно параметров описывать и будут ли они удовлетворять пользователей

[REA]

Все несколько сложнее. Помимо самих СУБД должны быть спроектированы структуры данных (это довольно трудоемкая работа, требующая знания предметной области). Кроме того есть еще форматы и протоколы передачи данных - о них собственно и речь.

В таких проектах нужно заниматься проектированием еще раньше, нежели создавать структуру данных в базе. Нужно спроектировать основу, разбить на модули, создать логическое ядро так сказать. Плюс выбрать технологии. Вот один из примеров. Я думаю все знают DTCIS. Создавалось оно на заре всеобщей эйфории над технологией COM, ну и разработчики думали что вот она халява, не нужны никакие сокеты и разработка протоколов. Но какой же геморрой они создали таким решением. Потом делали какой то костыль, для конвертирования СОМ и сокетов. Насколько были грамотные настройщики станций в ИМС(кто запускал станции с нуля), но не один не понимал как настроить этот чертовый СОМ по сети.

В вот вопрос господа инженеры и программисты
Создают американцы стандарты, а что такое стандарт?
Это по существу формализованные данные - каждый объект и его характеристики приведены к некому стандарту- посылать данные по стандарту и никак более. И тут возникает вопрос а можно ли описать все процессы допустим при бурении неким стандартом. Ну небольшие станции со стандартным набором функций наверное можно, номенклатура данных небольшая. А вот описать в стандарте процесс добычи, поддержания ППД, работу УПН -это сколько же нужно параметров описывать и будут ли они удовлетворять пользователей

Не обязательно описывать все сразу. Можно создать действующую комиссию по утверждению стандарта и все поправки вносить по ходу дела. Достаточно создать некий общий протокол или стандарт, который был бы достаточно гибким к дополнениям. Кроме самого стандарта нужны еще утилиты верификации, которые бы уменьшали бы уровень анархии, возникающий из за разночтений стандарта.

[amt]

Все несколько сложнее. Помимо самих СУБД должны быть спроектированы структуры данных (это довольно трудоемкая работа, требующая знания предметной области). Кроме того есть еще форматы и протоколы передачи данных - о них собственно и речь.

В таких проектах нужно заниматься проектированием еще раньше, нежели создавать структуру данных в базе. Нужно спроектировать основу, разбить на модули, создать логическое ядро так сказать. Плюс выбрать технологии. Вот один из примеров. Я думаю все знают DTCIS. Создавалось оно на заре всеобщей эйфории над технологией COM, ну и разработчики думали что вот она халява, не нужны никакие сокеты и разработка протоколов. Но какой же геморрой они создали таким решением. Потом делали какой то костыль, для конвертирования СОМ и сокетов. Насколько были грамотные настройщики станций в ИМС(кто запускал станции с нуля), но не один не понимал как настроить этот чертовый СОМ по сети.

В вот вопрос господа инженеры и программисты
Создают американцы стандарты, а что такое стандарт?
Это по существу формализованные данные - каждый объект и его характеристики приведены к некому стандарту- посылать данные по стандарту и никак более. И тут возникает вопрос а можно ли описать все процессы допустим при бурении неким стандартом. Ну небольшие станции со стандартным набором функций наверное можно, номенклатура данных небольшая. А вот описать в стандарте процесс добычи, поддержания ППД, работу УПН -это сколько же нужно параметров описывать и будут ли они удовлетворять пользователей

Не обязательно описывать все сразу. Можно создать действующую комиссию по утверждению стандарта и все поправки вносить по ходу дела. Достаточно создать некий общий протокол или стандарт, который был бы достаточно гибким к дополнениям. Кроме самого стандарта нужны еще утилиты верификации, которые бы уменьшали бы уровень анархии, возникающий из за разночтений стандарта.

Судьба стандарта на ГТИ ни на что не намекает?
Обычно, стандарт есть реакция на уже существующие варианты решений.
Например IEEE-488 просто копировал разработку HP.

[amt]

Да но как тогда быть производителям оборудования и ПО, всякий раз договариваться? Ведь амеры не зря придумали стандарты....

Так они их давно придумали. Вы их обогнать хотите? Может, освоить что есть по-быстрому и идти дальше?

[amt]

Ну хорошо, подключите в режиме on-line режиме по стандарту WITSML 1.3.1 станцию АМТ к серверу Petrel, пользуясь экранными редакторами??

И передергивать не надо. И не дело оператора ГТИ подключать станцию к серверу Petrel.
Если у заказчика появится такой запрос, разработчик его реализует. Либо за деньги, либо так, если сочтет перспективным.

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

[Prepodobie]

Нет не хочу их обгонять. Я просто думаю что нам нужен свой стандарт передачи данных для нефтяной промышленности, пускай не сразу постепенно, но методично и настойчиво.
А то я уже приводил пример с Казахстаном...........

[Prepodobie]

Ну хорошо, подключите в режиме on-line режиме по стандарту WITSML 1.3.1 станцию АМТ к серверу Petrel, пользуясь экранными редакторами??

И передергивать не надо. И не дело оператора ГТИ подключать станцию к серверу Petrel.
Если у заказчика появится такой запрос, разработчик его реализует. Либо за деньги, либо так, если сочтет перспективным.

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

Если у заказчика появился запрос, разработчик его реализует- дело в том что у нас появиться дикая смесь, что по существу сейчас и происходит. Одному надо так другому так, а в результате покупайте импортное, там всё стандартизовано. Но их стандарт не совсем подходит для наших технологий, и мы опять зависим и в перспективе будем хранить данные за рубежом

[amt]

Ну хорошо, подключите в режиме on-line режиме по стандарту WITSML 1.3.1 станцию АМТ к серверу Petrel, пользуясь экранными редакторами??

И передергивать не надо. И не дело оператора ГТИ подключать станцию к серверу Petrel.
Если у заказчика появится такой запрос, разработчик его реализует. Либо за деньги, либо так, если сочтет перспективным.

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

Если у заказчика появился запрос, разработчик его реализует- дело в том что у нас появиться дикая смесь, что по существу сейчас и происходит. Одному надо так другому так, а в результате покупайте импортное, там всё стандартизовано. Но их стандарт не совсем подходит для наших технологий, и мы опять зависим и в перспективе будем хранить данные за рубежом

За рубежом вовсе не все стандартизировано. У каждого игрока на рынке свои протоколы. Какой-то становится популярным и начинается ползучая стандартизация. В мире модно все заворачивать в XML - появился WITSML.
Это так естественно. В смысле, онтологично.
Правда, они еще и монетизировали его, хотя кто мешает повторить такое почти в точности со своим словарем.
Кто вам мешает создать сервер переводов одного формата в другой и попытаться монетизировать? Ответ на этотвопрос будет близок к ответу о неоходимости, а главное, реализуемости идеи создания российского стандарта.

И не надо путать протоколы передачи с форматами хранения.

[REA]

XML это неплохо для небольших объемов данных, особенно если стандарт хорошо описан. На практике же объемы большие, а режимы докачки данных, параллельной передачи данных, слияния данных, промежуточного кэширования и т.п. этим форматом не оговариваются. Т.е. надо делать и форматы и протоколы вариативные, гибкие (допускающие неконфликтные расширения), поддерживающие двусторонний обмен в реальном времени и так далее. Опять же уже сказали, что их технологии бурения и наши не на 100% подходят и нужно как минимум подмножество стандарта типа WITSML-RU, учитывающее эти особенности.

[Prepodobie]

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

[PDS]

XML это неплохо для небольших объемов данных, особенно если стандарт хорошо описан. На практике же объемы большие, а режимы докачки данных, параллельной передачи данных, слияния данных, промежуточного кэширования и т.п. этим форматом не оговариваются.

Буквально недавно приезжали одни заказчики и спрашивали насчет подключения ЗТС. Я сказал что проблема может быть при дисконнекте, могут быть потери данных, а докачки данных при текущем протоколе не предусмотрено. Они очень удивились и подумали что это у нас недоработка, я им попытался объяснить что это принцип WITS протокола. Т.е. на текущий момент эти WITS протоколы это архаичные костыли. Было бы очень не плохо разработать современный и универсальный протокол (на базе json, меньше перерасхода чем у xml). Где бы можно было бы учесть и докачку и запрос только нужных параметров.