мы удоволетворены работой системы архивов TRACE MODE 5: они быстрые (особенно на запись информации), надежные, имеют ODBC-доступ. В новой версии планируются ряд улучшений: работа с множеством томов, оптимизация операций ввода/вывода, развитие сервиса по связи с СУБД и т.д.

А что бы Вы хотели видеть в системе архивирования ТМ6?
 

1. Вот выдержка из документации по ТМ5:

********************************************************************
Следует учитывать, что в таблицу заносится время изменения значений. Поэтому, чтобы узнать значение в определенный момент времени, нужно сделать следующее:

· Ввести в фильтр для поля времени выражение вида <TIME, где TIME – значение времени в формате данной прикладной программы;

· Отсортировать значения поля TIME в обратном направлении.
*********************************************************************

Именно по этой причине я никому не рекомендую пользоваться ODBC-драйвером к архиву, поскольку ради одного значения приходится выбирать весь архив, потом его еще отсортировать и еще проверить, работала ли система...
Для чего люди придумали SQL-сервера - чтобы не таскать набор данных целиком, а только результат запроса. Разве не очевидно, что работа по поиску данных должна выполняться ODBC-драйвером, а не клиентом?

2. Часто необходимо хранить разные параметры с разной глубиной (например, параметр с периодичностью обновления в 1 сек хочу хранить 3 дня, а параметр с периодичностью 1 сутки - год)

3. Часто необходима настройка архивирования отдельно каждого атрибута канала, а не как в ТМ5 - или все архивируем или ничего. Сейчас приходится либо создавать ради архивирования отдельного атрибута дополнительные каналы либо замусоривать архив значениями ненужных для архивации атрибутов.

4. Входное и аппаратное значение вообще невозможно архивировать, не прибегая к доп. каналам. Хотя сплош и рядом ситуация, когда при разборе аварий КИПовцу нужно входное или аппаратное значение, а технологу - реальное.
 

>Разве не очевидно, что >работа по поиску данных должна выполняться >ODBC-драйвером, а не клиентом?

Не очевидно. Принятая нами система промышленных архивов оптимизирует следующие параметры:

1) быстрая запись данных,
2) быстрое из извлечение данных
3) компактное хранение
4) резервирование, синхронизацию и восстановление данных

За эти свойства (для нас они представляются имеющими наивысший приоритет) приходится платить некоторым неудобством. У нас реализовано хранилище данных, в которое значения каналов заносятся по изменению, а не с указанным периодом. Это позволяет хранить данные очень компактно и иметь точную информацию о времени изменения параметра, чего нельзя добиться при сохранении с заданным периодом. В проекте Нассирия по ГРЕС в день заполняется 100 мегабайт - винчестера 100 Гб хватит на 3 года (такой винчестер стоит сейчас менее 200$).

Для чего люди придумали SQL-сервер? Не для АСУ ТП, а для хранения бизнесс-информации. Поэтому SQL-сервер очень медленный. Он оптимизирован на исполнение структурированных запросов к данным. Тогда как архив АСУ ТП должен в первую очередь обеспечивать быструю запись данных, быстрое из извлечение и компактное хранение. Поэтому основой ситемы архивов ТМ6 будет модернизированнаый СПАД. Впрочем писать данные в SQL-сервер можно уже и в ТМ5. Но не советую!

>2. Часто необходимо хранить разные >параметры с разной глубиной (например, >параметр с периодичностью обновления в 1 >сек хочу хранить 3 дня, а параметр с >периодичностью 1 сутки - год)

Это будет решено путем введения множества томов (об этом я уже писал).

>3. Часто необходима настройка архивирования >отдельно каждого атрибута канала,

Поясните, какие атрибуты каналов Вам требуется сохранять? В общем случае сохранение абсолютно всех атрибутов нецелесообразно. Это сильно раздует структуру канала и усложнит систему архивирования, что в свою очередь снизит быстродействие архивов и раздует их объем. Кроме того мы получим замедление пересчета базы каналов, более высокие требования по памяти и кучу других проблем. С другой стороны, атрибуты каналов меняются редко (как часто меняются границы каналов), а если они не меняются, то и запись в архив не производится - так что места в архиве они почти не занимают. Поэтому не очень понятно, чем реально Вы не довольны. Объем "мусора" минимален!

>4. Входное и аппаратное значение вообще >невозможно архивировать, не прибегая к доп. > каналам. Хотя сплош и рядом ситуация, >когда при разборе аварий КИПовцу нужно >входное или аппаратное значение, а >технологу - реальное.

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

<В проекте Нассирия по ГРЕС в день заполняется 100 мегабайт - винчестера 100 Гб хватит на 3 года (такой винчестер стоит сейчас менее 200$).>

Не надо уж так, всех под одну гребенку, далеко не у всех задачи 1:1 как в Насирии. И то что хорошо подходит для них вовсе не означает, что это именно то что нужно всем остальным. Кстати, не могли бы Вы озвучить такую статистику: как распределяются объемы продаж МРВ на 128, 1024, 32000 и 64000 точек в.в.?
Просто любопытно, какая же средняя "Крупность" АСУТП.

<Впрочем писать данные в SQL-сервер можно уже и в ТМ5. Но не советую!>

Я тоже не советую делать этого средствами ТМ5. БД то нынче "навороченные" пошли, хранимые процедуры и транзакции там всякие, понимаш... С простейшим INSERT INTO и не суйся.

<Поясните, какие атрибуты каналов Вам требуется сохранять? >

Помните, как на форуме asutp@yahoogroups.com на вопрос чем число точек в/в отличается от числа тэгов Вы ответили, что в ТМ на каждую точку в/в приходится >100 (точную цифру не помню) внутр. переменных. Замечательно, но допустимое число каналов = числу точек в/в. Платить за каждую перменную, требующую архивироания как за отдельный канал многим не по карману, поэтому исполнительные модули покупаются, как правило, именно строго по числу точек в/в. Как же быть с расчетными параметрами, если их нужно архивировать или сохранять в дамп? Вот и приходится писать их в атрибуты каналов.

<В общем случае сохранение абсолютно всех атрибутов нецелесообразно.
Это сильно раздует структуру канала и усложнит систему архивирования, что в свою очередь снизит быстродействие архивов и раздует их объем. Кроме того мы получим замедление пересчета базы каналов, более высокие требования по памяти и кучу других проблем.>

Сами же прекрасно осознаете проблему, не сделали наоборот - атрибуты можно архивировать только все сразу.

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

А вот это неправда. Запись по изменению производится только для реальных значений. Прочие атрибуты пишутся при каждом пересчете, независимо от того, менялись они или нет. Спросите у собственной техподдержки.
 

Запрос "дай мне значение параметра за такое-то время" - это штатная функция ODBC-драйвера, которая реализуется, если клиент обратится к нему с помощью соответствующего SQL-запроса. Для этого действительно не надо клиенту шерстить весь архив.

<Прочие атрибуты пишутся при каждом пересчете, независимо от того, менялись они или нет.>
Детальный анализ Вашего проекта показывает, что в пределах одного цикла пересчета выбранному атрибуту присваивается последовательно несколько различных значений от FBD, вызываемых разными каналами. Каждое присвоение вызывает запись в архив, но с одной и той же меткой времени - началом цикла пересчета базы каналов. В архиве может существовать только одна запись какого-либо атрибута с конкретной меткой времени - такова структура архива. Поэтому в архиве всегда остается та запись, которая в цикле пересчета базы была последней. Создается иллюзия, что в архив пишутся неизменяющиеся значения атрибутов.
Здесь надо бы начинать с постановки задачи - что Вы хотите хранить в этом атрибуте? Почему Вы допускаете, что в одном цикле пересчета в него могут быть записаны разные значения? Какое из этих значений должно быть правильным?
Если Вы соберете все операции присвоения значения этому атрибуту в одной FBD и безальтернативно определите это значение, все вопросы будут сняты.
 

Вы не находите, что противоречите сами себе. Еще раз привожу выдержку из документации:
********************************************************************
Следует учитывать, что в таблицу заносится время изменения значений. Поэтому, чтобы узнать значение в определенный момент времени, нужно сделать следующее:

· Ввести в фильтр для поля времени выражение вида <TIME, где TIME – значение времени в формате данной прикладной программы;

· Отсортировать значения поля TIME в обратном направлении.
*********************************************************************
Да, формально такой SQL-запрос есть, но возвращает он как правило пусто. И шерстить (выбрать весь и отсортировать) архив придется.

<Мы уведомили Вас об этом (с предоставлением примера), когда Вы с этой проблемой обратились в службу техподдержки.>

За это Я вам искренне благодарен. К техподдержке у меня ни каких претензий нет. Более того, пользуясь случаем хочу выразить им благодарность за чуткость и оперативность. Просто не хочется, чтобы другие разработчики были введены в заблуждение, как я в свое время, сообщением "а если они (атрибуты) не меняются, то и запись в архив не производится", поскольку, как Вы весомо подтвердили, "атрибуты пишутся в архив при каждой попытке записать в них значения, в том числе и при повторе старого значения".
Прежде чем обходить проблему, нужно ведь знать о ее существовании. В документации об этом не слова.
Впрочем, опять мы начинаем отклоняться от темы ТМ6.
 

Неточности в документации необходимо признать. Мы их, безусловно, вылавливаем и документацию выправляем.
Но в данном случае это не так. Я вынужден был откорректировать свой предыдущий ответ (см.мой ответ от 9.11.01) по поводу проблемы "атрибуты пишутся в архив при каждой попытке записать в них значения, в том числе и при повторе старого значения".
Здесь нет ошибок.

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

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

В соответствии с этим уточнением я откорректировал 2 своих предыдущих сообщения за 9.11.01

Фридлянд А.В.
 

1.
05.11.2001 18:02 Дмитрий А. Попов, инженер службы техподдержки пишет (мне директом):
"Функция сохранения в СПАД по изменению реализована на данный момент только для реального значения канала. Реализация этой функции для других атрибутов канала связана с необходимостью существенной переработки существующей структуры базы каналов, что не планируется в текущей, пятой версии"

2.
08 November 2001 11:34 Lev Anzimirov wrote:
"С другой стороны, атрибуты каналов меняются редко (как часто меняются границы каналов), а если они не меняются, то и запись в архив не производится - так что места в архиве они почти не занимают."

Следуя законам формальной логики утверждение №1 противоречит утверждению №2. Прошу дать однозначный ответ, которое из них истинно,а которое ложно. Вот и все что требуется. У меня не стоит цель подловить кого бы то ни было. Я лишь хочу понять как работает ТМ5. Просто сначала мне говорят одно, а потом утверждают другое. Любой на моем месте возмутился бы
 

Вы правы по поводу необходимости соблюдения тематической направленности данного раздела ФОРУМА. Извините.

Свои ответы переношу в раздел "Архивирование в Трейс Моуд", тема "Архивирование атрибутов".

Фридлянд А.В.