www.InTouch.su

У меня в приложении ArchestraA IDE 3.0.200 2859.0066.0239.0010, организован скрипт который восстанавливает исторические данные, после устранения обрыва связи с контроллером, т.е. поднимает с контроллера важные данные, которые в нем частично архивируются. Но как показала практика восстановление идет очень нестабильно, например за сутки, восстанавливаются только 3..20 значений, одного параметра, хотя положено каждые 15 минут. Сам скрипт работает стабильно и никаких ошибок не выдает, данные пропадают при выполнении SQL запроса на добавление записей. Теже SQL запросы, я испробовал через Microsoft SQL Server Management Studio, и также не получил результата. Версия inSQL 9,0,2,0368 (Enterprise).

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

Запрос на запись значения:

INSERT INTO [Runtime].[dbo].[_]
(Datetime,TagName,Value,QualityDetail) VALUES
('2012-02-21 10:55:00.000', 'GPP4_RP11_ElHistTGs.CI118EIRIS485_R', 4323122, 192)

Сообщение на выполнение запроса:

(1 row(s) affected)

После этого проверяю, добавилось значение или нет:

select * from Runtime.dbo._
WHERE Datetime between '2012-02-21 9:07:00' AND '2012-02-21 11:08:00'
and ( TagName = 'GPP4_RP11_ElHistTGs.CI118EIRIS485_R' )
and wwretrievalmode = 'full'
and wwcyclecount = 10000

В выданном ответе мое значение не появилось, оно должно было быть с меткой - 10:55, но до 11:06, никаких данных нет:

DateTime TagName Value Quality QualityDetail OPCQuality
21.02.2012 9:07:20 GPP4_RP11_ElHistTGs.CI118EIRIS485_R 4322821 0 192 192
21.02.2012 9:07:38 GPP4_RP11_ElHistTGs.CI118EIRIS485_R 4322822 0 192 192
21.02.2012 9:08:03 GPP4_RP11_ElHistTGs.CI118EIRIS485_R 4322823 0 192 192
21.02.2012 9:08:21 GPP4_RP11_ElHistTGs.CI118EIRIS485_R NULL 1 24 0
21.02.2012 10:27:28 GPP4_RP11_ElHistTGs.CI118EIRIS485_R NULL 1 10 0
21.02.2012 11:06:43 GPP4_RP11_ElHistTGs.CI118EIRIS485_R 4323141 0 44 192
21.02.2012 11:07:04 GPP4_RP11_ElHistTGs.CI118EIRIS485_R 4323142 0 192 192
21.02.2012 11:07:25 GPP4_RP11_ElHistTGs.CI118EIRIS485_R 4323143 0 192 192
21.02.2012 11:07:49 GPP4_RP11_ElHistTGs.CI118EIRIS485_R 4323144 0 192 192

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

beachbear писал(а):должно быть сообщение, что обрабатывается файл пакета MDAS

INSERT/Update действует не только на MDAS теги.

несмотря на то является ли тег MDAS тегом или нет, вставка неупорядоченных старых данных через Т-SQL в конечном счёте производится процессом Manual Storage через обработку MDAS пакетов, что и должно быть видно в логе.

beachbear писал(а):несмотря на то является ли тег MDAS тегом или нет, вставка неупорядоченных старых данных через Т-SQL в конечном счёте производится процессом Manual Storage через обработку MDAS пакетов, что и должно быть видно в логе.

Совершенно верно. Попутал сервис и тип тега
Добавлю, вставлять необходимо с wwVersion = 'Latest' (помимо DateTime, TagName,...)
Так же и опрашивать.
Вставка с wwVersion = 'Original' недопустима.
Протестировал, данные пусть и не мгновенно, но записываются в БД.

В логах inSQL, на моменты загрузки данных, упоминание MDAS пакетов, я не нашел. Попробовал вручную добавить данные и посмотреть что добавиться в логах, пять минут прождал и ничего...
С wwVersion пробовал, ни лучше не хуже..

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

Нагрузка процессора под ноль, памяти достаточно, единственно "Overall data rate (per sec.)" в статусе inSQL скачет от 200 до 3000, не знаю насколько это много или мало.

наверное нужно обращаться в службу техподдержки, потому что логически это поведение необъяснимо.
данные INSERTa версии LATEST физически не могут быть записаны в историю никем другим как процессом Manual Storage через обработку MDAS пакета или импорта CSV файла. Если вы видите LATEST данные в истории, но не видите их как ORIGINAL, то значит они были записаны этим процессом и лог неизбежно должен содержать сообщения об обработке МDAS пакетов примерно в то время когда выполнялась вставка данных. Может быть те самые спорадические значения, что вы видите вовсе не LATEST вставленные через INSERT, a посланы источником данных напрямую и являются на самом деле ORIGINAL? попробуйте выбрать эти данные SELECTом с wwVersion ='ORIGINAL'. Ecли покажет эти точки, это может означать что никакие INSERTы на этой системе вообще не работают по какой-то причине.

Попробуйте слегка видоизменить SQL-запрос:
INSERT Insql.Runtime.dbo.History (Datetime,TagName,Value,QualityDetail, wwVersion)
VALUES
('2012-02-21 10:55:00.000', 'GPP4_RP11_ElHistTGs.CI118EIRIS485_R', 4323122, 192, 'Latest')

'2012-02-21 10:55:00.000' - Вы уверены, что разделители для даты дефисы?

При запросе SELECTом с wwVersion ='ORIGINAL' и wwVersion ='LATEST', выдается одинаковая наборка данных.

Генератор зла писал(а):Попробуйте слегка видоизменить SQL-запрос:
INSERT Insql.Runtime.dbo.History (Datetime,TagName,Value,QualityDetail, wwVersion)
VALUES
('2012-02-21 10:55:00.000', 'GPP4_RP11_ElHistTGs.CI118EIRIS485_R', 4323122, 192, 'Latest')

Конечно пробовал, не дает результата.

Генератор зла писал(а): '2012-02-21 10:55:00.000' - Вы уверены, что разделители для даты дефисы?

При записи принимаются форматы даты: 02.21.2012, 02/21/2012 , 2012-02-21, при других формах выдается ошибка. При разных форматах даты, запрос проходит, но в таблице так и не появляется..

Проверьте через SMC-Managenent Console-Status запущена ли служба MDAS.
Сделайте Stop Historian, обнулите логи, Start Historian. Проверьте логи.
Что за версия Historian? Случаем, не Express Edition (Personal)?

Генератор зла писал(а):Проверьте через SMC-Managenent Console-Status запущена ли служба MDAS.

Запущена: MDAS: Tags: 9081, Status: Receiving, Values: 1 552 971 000, Rate: 3000 (примерно), Connection:1.

Генератор зла писал(а):Сделайте Stop Historian, обнулите логи, Start Historian. Проверьте логи.

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

Генератор зла писал(а):Что за версия Historian? Случаем, не Express Edition (Personal)?

InSQL Server Management Console Extension Invensys Systems, Inc. Версия: 9.0
9,0,2,0368 (Enterprise).

В логах с периодичностью примерно 5 мин, выходит предупреждение:

114741607 02.03.2012 9:49:00 4140 4940 Warning aahIndexSvc MinThreshold for circular path too small to accommodate average history block size (threshold; average block size) (131072000, 1086798225) [VINSQL; dataset.cpp; 2639; 1]

Выскакивает вне зависимости от работы моего скрипта, и не синхронизировано по времени.

Настройки Historian:

System Parameters
aaHistClientSchemaVersion 6
AIAutoResize 1
AIResizeInterval 5
AllowOriginals 0
AutoStart 1
ConfigEditorVersion 9,0,000,000
DatabaseVersion 9,0,015,057
DataImportPath E:\InSQL\Data\DataImport
EventStorageDuration 168
Headroom A_nalog2 100
Headroom A_nalog4 100
Headroom A_nalog8 0
Headroom Discrete 100
Headroom String 20
HistorianVersion 9,0,2,0368 (Enterprise)
HistoryCacheSize 0
HistoryDaysAlwaysCached 0
HoursPerBlock 24
InterpolationTypeInteger 0
InterpolationTypeReal 1
LicenseRemoteIDASCount 65535
LicenseTagCount 25000
ModLogTrackingStatus 0
QualityRule 0
RealTimeWindow 60
SuiteLinkTimeSyncInterval 60
SummaryStorageDuration 336
SysPerfTags 1
TimeStampRule 1
TimeSyncIODrivers 1
TimeSyncMaster

Tag Counts
Tag Type Tag Count Licensed Tags
A_nalog 19437 19332
Discrete 3150 3139
String 53 52
Event 1 0
Total 22641 22523
Note: System tags and Event tags are excluded from the Licensed tag count.

A_nalog Tag Storage Detail
Storage Type Tag Count
Cyclic 81
Delta 24
Forced 19332

Cyclic Storage Detail
Storage Rate (in sec) Tag Count
1 1
5 72
10 4
60 4

Data Acquisition Detail
IDAS Location IO Server Location Application Name Topic Protocol
Historian MDAS VINSQL InSQL_MDAS MDAS SuiteLink
Historian System VINSQL SysDrv System SuiteLink

AlexStone писал(а):Я не один работаю, ради "побаловаться" мне остановить Хисториан не дадут. Обнулять логи тоже не вижу смысла, если есть фильтрация по дате.

Ну, это дело 2 минут Но я Вас понимаю.

AlexStone писал(а):114741607 02.03.2012 9:49:00 4140 4940 Warning aahIndexSvc MinThreshold for circular path too small to accommodate average history block size (threshold; average block size) (131072000, 1086798225) [VINSQL; dataset.cpp; 2639; 1]

Это предупреждение, что настройка по автоматической очистке базы Circular меньше, чем средний размер Hist блока (131072000 против 1086798225). Подправьте, и предупреждение оставит Вас в покое.

AlexStone писал(а):A_nalog Tag Storage Detail
Storage Type Tag Count
Cyclic 81
Delta 24
Forced 19332

Зачем так много форсед-тегов?

Проверьте по таскманагеру среднюю загрузку ЦП и выделение памяти.
Посмотрите в historian значения тегов SysCPUxPerfomance (как то так)
После неудачного выполнения Insert проверьте системные журналы ОС за этот момент.

Генератор зла писал(а):Проверьте по таскманагеру среднюю загрузку ЦП и выделение памяти.

Загрузка сервера 2..4%, с редкими всплесками на 10..20%. Занятая память 2.6 гига, при физической 3 гига.
Вставка Insert, по нагрузке проходит незаметно.

Генератор зла писал(а):Зачем так много форсед-тегов?

А вот это вопрос...
В основном исторические теги хранятся с периодичностью 1 сек, и где-то 30% от всех тегов, периодичность записи 5 минут, но когда смотришь, тот же тег в Хисториан, на нем стоит отметка Forced.



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

AlexStone писал(а):В основном исторические теги хранятся с периодичностью 1 сек, и где-то 30% от всех тегов, периодичность записи 5 минут, но когда смотришь, тот же тег в Хисториан, на нем стоит отметка Forced.

Добавьте настройку DeadBand
Встречался с подобными "косяками". Иногда помогало только Undeploy Platform/Engine, удаление тегов из конфигурации Historian, перезапуск Historian, Deploy. Но это Вам не подходит

Генератор зла писал(а):Добавьте настройку DeadBand

К сожаление это не подойдет, у нас часть важных параметров может не меняться по несколько дней (счетчики), но они входят в отчеты. Я уже пробовал, такие параметры переводить на unCange, в итоге они переходили в плохое качество и отчеты рушились..

Генератор зла писал(а):Встречался с подобными "косяками". Иногда помогало только Undeploy Platform/Engine, удаление тегов из конфигурации Historian, перезапуск Historian, Deploy. Но это Вам не подходит

А вот это может помочь! Я думаю для хорошего дела уговорю "товарищей", но только не в пятницу..
Спасибо Вам!

AlexStone писал(а):К сожаление это не подойдет, у нас часть важных параметров может не меняться по несколько дней (счетчики), но они входят в отчеты. Я уже пробовал, такие параметры переводить на unCange, в итоге они переходили в плохое качество и отчеты рушились..

Это не из-за DeadBand, а из-за таймаута сервера в/в.

Генератор зла писал(а): Это не из-за DeadBand, а из-за таймаута сервера в/в.

Да, я уже в другой теме про это спрашивал... Мы используем для сбора данных компонент: $ModbusSerial , нету в нем никаких таймаутов...

А по-подробнее? Там масса объектов.

Из help:

ModbusSerial Object
The ModbusSerial object, representing the communications path to several possible Schneider Electric Modicon and Modbus-compatible controllers, belongs to a family of objects called DeviceIntegration Objects (DIObjects). This object is a DINetwork Object that represents just one part of a hierarchy of objects. All the other components in the hierarchy are represented by DIDevice Objects.

The ModbusSerial object embeds the actual ModbusSerial DAServer within it. Configuring and deploying this object actually installs, configures, and runs the associated ModbusSerial DAServer on the target computer.

See the Glossary of ArchestrA™ terms in the Integrated Development Environment (IDE) documentation for additional information about the relationship between DIObjects. You can access the IDE Help (IDE.chm) from within the IDE by clicking Help Topics on the Help menu.

Основные настройки объекта ModbusSerial:
Я конечно не прав, там есть таймауты, но все они относятся к приему данных, а данные принимаются хорошо. Когда смотрю в SMC консоли все значения хорошего качества, а те же параметры в Historian уже идут под плохим качеством (редкоменяющиеся параметры).

В настройках DASMBSerial, в SMC консоли тоже нет таймаутов относящихся к передаче данных:

У нас ест пар-ры, которые не меняются месяцами И история ведётся исправно.
Посмотрите, эти пар-ры расположены в отдном топике? Точнее, в топиках с такими пар-рами есть пар-ры, меняющиеся стабильно часто?

Генератор зла писал(а):У нас ест пар-ры, которые не меняются месяцами И история ведётся исправно.

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

У нас были проблемы с платформами (некоторые не видели друг друга), платформы удалили, завели заново, сейчас вроде все друг друга видят, но нестабильная работа, связанная с передачей данных в Галактику, осталась .

AlexStone писал(а):Сейчас мы все перевели на запись по циклу, но когда стоял параметр "запись по изменению"

Я пользуюсь обеими настройками. DeadBand = 1 1 EU, Period = 60000 ms. Либо изменится, либо раз в минуту

AlexStone писал(а):может быть есть короткие перерывы связи, но ведь все равно при восстановлении связи поверх плохого качества должно записаться хорошее..

Посмотрите внимательно, у Вас на Рис. 4 Restart Attempts = 3, т.е. 3 попытки переподключения, а далее - вечный сон

AlexStone писал(а):У нас были проблемы с платформами (некоторые не видели друг друга), платформы удалили, завели заново, сейчас вроде все друг друга видят, но нестабильная работа, связанная с передачей данных в Галактику, осталась

Раб. группа или домен?

Генератор зла писал(а): DeadBand = 1 1 EU, Period = 60000 ms. Либо изменится, либо раз в минуту

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

Генератор зла писал(а): Посмотрите внимательно, у Вас на Рис. 4 Restart Attempts = 3, т.е. 3 попытки переподключения, а далее - вечный сон

Данные у нас принимаются (тфу, тфу ) нормально, после длительных обрывов связи, обмен поднимается самостоятельно, так что настройки вроде правильные..

Генератор зла писал(а):Раб. группа или домен?

Домен.

Мы кстати попробовали почистит теги в Historian, правда раздеплаивали не платформу, а только движек, после перезагрузки теги восстановились, но все равно с параметром записи: Forced а не Cyclic .

AlexStone писал(а): а есть которые меняются по сотне единиц за секунду, и нам такое количество записей не надо

Ну, я привёл пример для своих пар-ров, например напряжение на батарее (до 50 В). 1 В - вполне нормальная дискрета.

AlexStone писал(а):Домен.

Тогда нестабильность видимости платформ - проблема DNS.
У нас серверная часть (сервера AS, Historian) - домен; сервера в/в - другие подсети, не домен; АРМы - другие подсети, домен. В недоменных серверах в Hosts прописаны нужные доменные сервера (и наоборот). Доменные компьютеры видят друг друга хорошо и так. Правда пароль от администратора домена знаю только я, да и я его забыл

Слегка отклонились от темы.
У Вас InSQL 9.0 Patch 02.
А ОС с учётом SP ?
А MSSQL с учётом SP ? Std или Ent ?
Можно попробовать вставлять данные с помощью хранимой процедуры. Хотя, если это косяк InSQL - не поможет.
Попробуйте ещё раз (в который ужО? ) вставить данные и проверьте логи системных журналов ОС за этот момент (System, Application).

У меня проблема, вчера почистил все теги в Historian, и теперь он не заводится, пишет ошибку:

ERROR: Timeout on lock request for TagInfoMap [VINSQL; BlockInfoMapCacheManager.cpp; 392; 1]

Сорри, лень переводить, но и так понятно.
Please try to peform a clean InSQL restart by selecting "shutdown and disable" from the InSQL console menu.
Then after a few minutes verify that all key InSQL processes are down (aaCfgSvc.exe, aahIndexSvc.exe, aahManStSvc.exe, aahStoreSvc.exe).
Then select "enable and allow to run" and start InSQL again. These steps will ensure that the ActiveImage is reset.
If you see those ActiveImage warnings again please contact Wonderware Tech support and let them know how to reproduce the problem.

Спасибо! заработало

Вот видите, небольшой неплановый перерыв в работе сервера Надеюсь, обойдётся без оргвыводов.