WITS/WITSML

[REA]

ХМL вообще медленно парсится, но если там раз в секунду пакеты поступают, то проблем нет, а вот если сразу за сутки свалить материал компьютер конечно присядет.

[KOCMOHABT]

ХМL вообще медленно парсится, но если там раз в секунду пакеты поступают, то проблем нет, а вот если сразу за сутки свалить материал компьютер конечно присядет.

Так и не с одной скважины информация приходит.

[Prepodobie]

Согласен XML  это довольно затратная технология, но другой объединительной нет. Ведь информация с буровой это только часть информационной инфраструктуры, есть масса приложений на XML а вот они то увязываются без проблем. Вообще все эти стандарты это попытка формализовать информацию с буровых, тогда легче обрабатывать. Важно учитывать что впереди эра оптоволоконных датчиков, которые снимают данные с каждого метра скважины, с тактом один раз в 5 минут, причём через 1 м., максимум - строится температурный и давления профили, так же множество других производных данных. Причём на западе в развитие стандартов вкладывают большие деньги -консорциум http://www.energistics.org/ - сугубо коммерческая организация, живёт за счёт взносов членов а посмотрите кто в составе ....., практически все гранды. Нам в России так же нужен  подобный орган, дело в том что у нас причудливое переплетение технологий, оборудования, расчётов и представлений. Как зарубежных так и отечественных- в стандарт WITSML можно вставлять свои значения и объекты но какие? кто это должен решать?
А что касается скорости передачи данных над этим работают в energistics - протокол ЕТР, да и техника связи не стоит на месте.

[das124]

Конечно это будет звучать не много глупо, НО какая разница какой формат использовать если уже используются довольно широкие каналы связи и сравнительно мощные аппаратные ресурсы для отображение и передачи информации. Уже сколько сталкивался со станциями и с заказчиками суть одна "неважно как но что бы было". Отсюда и вывод, что каждый ***** как хочет.
Конечно стандартизация необходима, но с эти должна быть и поддержка ПО. смысл иметь стандарты если ПО само по себе не использует эти стандарты?
Тут ведь палка о двух концах. Либо имеем ПО которое имеет все необходимые стандарты передачи, и саму передачу, с одной стороны и протоколы алгоритмы, которые умеют понимать и работать с этими стандартами, с другой стороны. А все остальное зависит от коллегиальной прямоты руки и правильно их вырастания из нужного места.
А иначе нам счастья не видать.

[Prepodobie]

Когда мы работаем в Интернете , в локальной сети - нам всё равно кто произвёл сетевые карты, кто писал браузеры и т.д. - всё это результат стандартизации. НЕ пытаетесь же Вы сейчас создать собственный сетевой протокол отличный от стандартных. Создать можно но и работать с ним будете только Вы, это применимо в военном деле но в отрасли где много оборудования (имеется ввиду на промыслах) импортного, стандартизация не заменима. Мы например заинтересовались данной тематикой исходя из анализа вложений денег в Америке в стандарты передачи данных для нефтедобычи - а они довольно приличны и начали работу 20 лет назад, значит это имеет смысл.......

[das124]

Когда мы работаем в Интернете , в локальной сети - нам всё равно кто произвёл сетевые карты, кто писал браузеры и т.д. - всё это результат стандартизации. НЕ пытаетесь же Вы сейчас создать собственный сетевой протокол отличный от стандартных. Создать можно но и работать с ним будете только Вы, это применимо в военном деле но в отрасли где много оборудования (имеется ввиду на промыслах) импортного, стандартизация не заменима. Мы например заинтересовались данной тематикой исходя из анализа вложений денег в Америке в стандарты передачи данных для нефтедобычи - а они довольно приличны и начали работу 20 лет назад, значит это имеет смысл.......

Смотрите, в чем разница. Каждый все равно будет пилить real-time сервис под себя. Поскольку вы не сможете по факту взять и на глаз сказать какой протокол данных используется для получения данных со станции. И это будет до тех пор пока эти протоколы, как было выше сказано, не будут иметь вид которых будет легко и удобно обрабатываться.
По сути заказчик видеть только конечную картинку а каким "макаром" она к нему попадает он не когда мне сможет узнать. А общей стандартизации не будет никогда по одной простой причине, Менталитет. ))))
1)Всегда найдутся не причастные к этому делу люди которые захотят на это нажиться.
2)Типы станций разные и каждая система сбора будет передавать данные так как ее сделали.
3)Системы сбора написаны на том на чем было удобно писать разработчику.
Если GeoScape написан на Delphi А DTCIS НА чем то другом и не много .NET Framework
То станции АМТ написаны на JAVA. Тоже самое с методами и протоколами передачи.

[REA]

Когда мы работаем в Интернете , в локальной сети - нам всё равно кто произвёл сетевые карты, кто писал браузеры и т.д. - всё это результат стандартизации. НЕ пытаетесь же Вы сейчас создать собственный сетевой протокол отличный от стандартных. Создать можно но и работать с ним будете только Вы, это применимо в военном деле но в отрасли где много оборудования (имеется ввиду на промыслах) импортного, стандартизация не заменима. Мы например заинтересовались данной тематикой исходя из анализа вложений денег в Америке в стандарты передачи данных для нефтедобычи - а они довольно приличны и начали работу 20 лет назад, значит это имеет смысл.......

Если говорить о стандартах, то в области сетей компьютеров еще худо бедно научились как то их делать да и то все браузеры по разному картинку показывают, а в области промышленных сетей и ГТИ царит полная анархия. Взять хотя бы LAS файл - стандарт конечно есть, но все делают все равно кто во что горазд. На америку не советую равняться - они там как начали добычу так и закончили...

[Prepodobie]

Если говорить о стандартах, то в области сетей компьютеров еще худо бедно научились как то их делать да и то все браузеры по разному картинку показывают, а в области промышленных сетей и ГТИ царит полная анархия. Взять хотя бы LAS файл - стандарт конечно есть, но все делают все равно кто во что горазд. На америку не советую равняться - они там как начали добычу так и закончили...
[/quote]

Уважаемые господа.
Анализируя полемику о стандартах на различных форумах, я пришёл к выводу что на данном форуме собрались профессионалы, которые могут сказать что то дельное.
Тут вот какой вопрос, создавая программную платформу поддержки стандарта witsml 1.4.1, мы столкнулись с какой проблемой - схема данных стандарта практически не соответствует, например схеме данных ГТИ Геофит КУБ_2.Есть много похожего, но не  совпадает язык, размерности, иногда приходиться долго находить соответствие обозначений. И естественно что необходим конвертер, но тут ещё не так много значений. А вот что делать со стандартом witsml  2.0 или witsml 2.1, тут то  количество значений в схеме данных пойдёт на десятки тысяч, так как стандарт поддерживает и процессы добычи и состояние подземного резервуара. Отечественные технологии добычи всё таки отличаются от зарубежных.

[REA]

Стандарты достаточно объемистые да еще могут меняться. Пытался как то автоматизировать процесс привязки данных, но пока что безуспешно. Даже в WITS формате есть пробелы в описании данных и сложности с правильным переводом форматов, а тут и подавно.

[Prepodobie]

Спасибо за ответ, я с Вами согласен, но проблему надо решать...
Дальнейшее развитие импортных  стандартов и платформ поддержки, может привести к такой ситуации- весь ввод данных в геологическую и гидродинамическую модели будет осуществляться только в online -режиме, а значит надо либо закупать сервера witsml, либо хранить данные за рубежом. Что и получилось в Казахстане,  станции  ГТИ  китайские- сервера в Китае, а Вам дорогие владельцы только IP- адрес , с которого будете получать данные. Естественно что они доступны и владельцам сервера........
В связи с этим а как Вы считаете актуален ли вопрос разработки национального стандарта передачи данных для нефтегазовых предприятий. Ведь уже появились отечественные программы моделирования месторождений, станций ГТИ отечественных довольно много. Нет конечно переход на отечественный стандарт займёт не один десяток лет, но и американцы работали над этим с начала 90-х. Конечно на данный момент создание отечественных платформ поддержки стандартов witsml задача первоочередная, но когда то надо начинать

[MACTEP]

Стандарты достаточно объемистые да еще могут меняться. Пытался как то автоматизировать процесс привязки данных, но пока что безуспешно. Даже в WITS формате есть пробелы в описании данных и сложности с правильным переводом форматов, а тут и подавно.

Откуда такая растерянность и паника?
С форматом WITS какие пробелы в описании и сложности с переводом, что там непонятно?

[REA]

Стандарты достаточно объемистые да еще могут меняться. Пытался как то автоматизировать процесс привязки данных, но пока что безуспешно. Даже в WITS формате есть пробелы в описании данных и сложности с правильным переводом форматов, а тут и подавно.

Откуда такая растерянность и паника?
С форматом WITS какие пробелы в описании и сложности с переводом, что там непонятно?

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

[REA]

В связи с этим а как Вы считаете актуален ли вопрос разработки национального стандарта передачи данных для нефтегазовых предприятий. Ведь уже появились отечественные программы моделирования месторождений, станций ГТИ отечественных довольно много. Нет конечно переход на отечественный стандарт займёт не один десяток лет, но и американцы работали над этим с начала 90-х. Конечно на данный момент создание отечественных платформ поддержки стандартов witsml задача первоочередная, но когда то надо начинать

Я считаю, что такие стандарты не помешали бы, но сложно представить какой институт или сообщество могло бы предложить такой стандарт и он был бы согласован и воспринят как буровыми компаниями так и разработчиками и при этом конкурировал бы с уже используемыми стандартами. Я попытался как то формализовать структуру данных буровой и получилось порядка 30 таблиц только основных и порядка 50 справочников и это при том, много информации я даже не пытался описывать. Если брать не только ГТИ, то там данных будет на порядок больше.

[PDS]

Я попытался как то формализовать структуру данных буровой и получилось порядка 30 таблиц только основных и порядка 50 справочников и это при том, много информации я даже не пытался описывать. Если брать не только ГТИ, то там данных будет на порядок больше.

Я вообще не понимаю зачем в ГТИ нужны СУБД. Причем умудряются так накрутить, что даже программисту сложно настроить софт для работы. Помню первый раз пытался настроить WellDataPro, о боженьки ты мой, как же разработчики поиздевались над операторами. ГТИ-шный софт должен работать вообще с помощью простого копирования, без каких либо инсталляций. Вот прямо с флешки скопировал и запустил. Всякие там централизованные сервера пусть будут на СУДБ, но на буровой им явно не место.

[REA]

Я попытался как то формализовать структуру данных буровой и получилось порядка 30 таблиц только основных и порядка 50 справочников и это при том, много информации я даже не пытался описывать. Если брать не только ГТИ, то там данных будет на порядок больше.

Я вообще не понимаю зачем в ГТИ нужны СУБД. Причем умудряются так накрутить, что даже программисту сложно настроить софт для работы. Помню первый раз пытался настроить WellDataPro, о боженьки ты мой, как же разработчики поиздевались над операторами. ГТИ-шный софт должен работать вообще с помощью простого копирования, без каких либо инсталляций. Вот прямо с флешки скопировал и запустил. Всякие там централизованные сервера пусть будут на СУДБ, но на буровой им явно не место.

Сути дела это не меняет - структура данных все равно какая то должна быть. Мне удобнее для этого не изобретать велосипед, а использовать готовые решения, если они подходят. Этим, кроме всего прочего, обеспечивается открытость данных и облегчается доступ к данным сторонним разработчикам.