Aris scada прософт руководство

Никита писал(а): ↑22 май 2018, 17:41
кто сталкивался — как решали проблемы безопасности?

А если его просто не выводить в общую сеть, а конфигурировать только локально?

TEB писал(а): ↑23 май 2018, 10:40А если его просто не выводить в общую сеть, а конфигурировать только локально?

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

Никита писал(а): ↑23 май 2018, 10:53
Можно и так, но тут другая проблема — за минуту это не делается.

Это точно настолько сложно? Может не настолько?

ПНР на месте ведь все делают. Если установка насыщена разным оборудованием то и ПНР получается затяжной. Но это ведь ПНР, они не происходят постоянно, запустили и закончили. Если установка ёмкая и в обслуживании — значит вокруг неё обвязка соответствующая делается, службы сажаются локально.

Никита писал(а): ↑23 май 2018, 10:53
Нельзя подготовить конфиг, потом прийти и залить. Надо или снимать всю железку и нести в стационар, или сооружать по месту «мобильное рабочее место» из подручных материалов.

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

А чудес ведь не бывает. Вы либо включили устройство в общую сеть (и получили все неприятности по безопасности) либо не включили — под каждый случай своё проектное решение.

TEB писал(а): ↑23 май 2018, 11:22

Никита писал(а): ↑23 май 2018, 10:53
Можно и так, но тут другая проблема — за минуту это не делается.

Это точно настолько сложно? Может не настолько?
ПНР на месте ведь все делают. Если установка насыщена разным оборудованием то и ПНР получается затяжной. Но это ведь ПНР, они не происходят постоянно, запустили и закончили. Если установка ёмкая и в обслуживании — значит вокруг неё обвязка соответствующая делается, службы сажаются локально.

Прикиньте, сколько займет времени прописать в контроллере все параметры от той же системы управления ДЭС для передачи наверх и алгоритмы блокировок. Локально в будке КТП персонал постоянно не посадить точно, да и временно очень некомфортно, климатика есть, но не под людей а под оборудование рассчитана.

TEB писал(а): ↑23 май 2018, 11:22

Никита писал(а): ↑23 май 2018, 10:53
Нельзя подготовить конфиг, потом прийти и залить. Надо или снимать всю железку и нести в стационар, или сооружать по месту «мобильное рабочее место» из подручных материалов.

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

Мы вроде на ты переходили при последней встрече?) Ну да ладно, будем соблюдать традиции форума. Практически первый этап для контроллера обычно реализация алгоритмов без привязки к каналам. И начинается это иногда еще до оплаты железа поставщику. Дальше — в зависимости от ситуации. Чаще применяемый комплекс позволяет сконфигурить ввод-вывод без реального железа, а при появлении железа его забирает программист и допиливает у себя на столе. Ну и корректировки по месту на реальном объекте тоже никто не отменял. Кстати, многое делалось по ночам в гостиницах, для этого опять же офлайн-режим нужен.
Кстати, конфиги от GC в USW, насколько помню, спокойно набираются без контроллера, потом в несколько движений подключается ноут, заливается и отключается.

TEB писал(а): ↑23 май 2018, 11:22

Никита писал(а): ↑23 май 2018, 10:53
А чудес ведь не бывает. Вы либо включили устройство в общую сеть (и получили все неприятности по безопасности) либо не включили — под каждый случай своё проектное решение.

Ну с общим подходом согласен. Но почему-то у приличных людей хотя бы https для этих целей используется. Тоже, конечно, дыра еще та, но не такая явная. Про централизованные решения типа TIAPortal вообще не говорю.
Вообще да, оборудование ПС частенько конфигурится по месту, благо процесс нечастый. Но тоже не через 80й-порт. Или отдельный (аппаратный, последовательный) на морде, или IP 443, или свой софт со своими протоколами.
Но в нашем конкретном случае проблема осложняется тем, что доступа к железу у программиста не будет до тех пор, пока он не приедет на объект лично. Процедура так выстроена.

Никита писал(а): ↑23 май 2018, 12:13
Мы вроде на ты переходили при последней встрече?

Да. но тут не все в курсе.

Никита писал(а): ↑23 май 2018, 12:13
Прикиньте, сколько займет времени прописать в контроллере все параметры от той же системы управления ДЭС для передачи наверх и алгоритмы блокировок.

Это надо сделать всего 1 раз. Прикинуть не могу потому что не знаю что за контроллер такой.
На саму ДЭС у меня обычно уходит 2-3 часа на ПНР на всё, и то дольше по схемам ползаешь чем что-то делаешь. Когда вообще вся информация есть сразу и монтаж нормальный — за 2-3 часа можно всю электростанцию запустить (включая алгоритмы и блокировки).
А какими блокировками занимается этот контроллер? Он ещё и управлять собирается? Ох, не стал бы я этого делать — зачем этот велосипед когда «всё уже украдено до нас» кучей готовых изделий? Если кто-то собирается алгоритм работы станции писать с нуля — у него легко и месяц уйдёт и два, и то ошибки все не выловит.

Никита писал(а): ↑23 май 2018, 12:13
Локально в будке КТП персонал постоянно не посадить точно, да и временно очень некомфортно, климатика есть, но не под людей а под оборудование рассчитана.

И не надо сажать. Когда надо подкрутить — пришли, подкрутили, ушли. Обычно так и делается.

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

Никита писал(а): ↑23 май 2018, 12:13
Ну с общим подходом согласен. Но почему-то у приличных людей хотя бы https для этих целей используется. Тоже, конечно, дыра еще та, но не такая явная. Про централизованные решения типа TIAPortal вообще не говорю.

Подход у меня простой: Если есть дверь — значит через неё можно войти. Если есть замок то к нему найдётся и ключ. Для начала можно заменить замок на задвижку — упарятся ключ искать пока не поймут что его нет. А если нет и двери то и зайти не получится как ни старайся (только на танке).

Никита писал(а): ↑23 май 2018, 12:13
Но в нашем конкретном случае проблема осложняется тем, что доступа к железу у программиста не будет до тех пор, пока он не приедет на объект лично. Процедура так выстроена.

Во-1-х у программиста может быть аналогичное железо и он вполне может работать и с ним. Во-2-х, а зачем нужен программист? Для малой электростанции. Не понимаю. Если это известный нам подрядчик на букву «Зэ» — то я не удивлён, они по-другому не умеют и считают что именно так и правильно, а это давно не так (уже лет 20 как).

Ну или пусть программист посчитает смету на свою работу включая ПНР.

Что страшного? Я писал софт для ПЛК для управления всей электростанцией на судах. С нуля (так что знаю что это такое). И судно откинуло швартовы и ушло в море, автономно. Ходит уже лет 20 (если тот ПЛК ещё жив). Были недочёты — исправляли лично. Такого интернета тогда просто не было. Почему и сейчас без него не обойтись — я правда не всегда понимаю.

Отправлено спустя 58 минут 51 секунду:

Никита писал(а): ↑23 май 2018, 12:13
Прикиньте, сколько займет времени прописать в контроллере все параметры от той же системы управления ДЭС для передачи наверх и алгоритмы блокировок.

А вот вопрос: а как программист собирается отлаживать алгоритмы и блокировки, не находясь на объекте и не видя что с ним происходит в реальности? Так что придется ножками бегать как ни крути.
И потом, можно ведь технологическую сеть только этой системы ни с какой другой сетью не объединять физически. Тогда работа программиста будет заметно облегчена (бегать придётся меньше), к безопасности тоже требований нет потому что доступ в эту сеть можно будет получить только санкционированно нужным людям для нужных операций — в этом случае ничего страшного в открытом 80м порте нет, он открыт только изнутри.

B ещё кстати.

Разве это будет совершенно необслуживаемая станция? Никакого диспетчерского персонала не будет совсем?
Если будет персонал, то вот пусть он и подкручивает в процессе работы — при нормальном дружественном сервисном интерфейсе это не проблема. В микроэнергетике это нормально. И незачем будет расшаривать управляющий уровень.
Но я боюсь, при свободном программировании получить такой нормальный сервисный интерфейс — это прилично добавит стоимость работ. В готовых устройствах он есть и совершенно бесплатно.

TEB писал(а): ↑23 май 2018, 14:56
А какими блокировками занимается этот контроллер? Он ещё и управлять собирается? Ох, не стал бы я этого делать — зачем этот велосипед когда «всё уже украдено до нас» кучей готовых изделий? Если кто-то собирается алгоритм работы станции писать с нуля — у него легко и месяц уйдёт и два, и то ошибки все не выловит.

Это немного другая история, но рядом с ДЭС (в буквальном смысле). Речь про контроллер РТП. Его задачи, по большей части, типовые: сбор информации с устройств измерения, РЗА, собственных нужд, опертока и т.д. Сюда же входит сбор и передача наверх информации о работе ДЭС. Блокировкимежду рядом стоящей ДЭС и сетевыми вводами. Команда на запуск ДЭС и включения ее на шины по факту готовности оной принять нагрузку. Плюс, передача с верха в ДЭС требуемого резерва мощности. Из нетипового — управление потребителями второй категории. Вот тут, кстати, нюанс — для определения очередности требуется работа со списками/массивами, что на FBD очень неудобно.

TEB писал(а): ↑23 май 2018, 19:45
Разве это будет совершенно необслуживаемая станция? Никакого диспетчерского персонала не будет совсем?

Это несколько РТП на одной площадке. Персонал будет, но расстояние от РТП до диспетчерской (оперативный и ремонтный рядом) от полукилометра до двух. Не набегаешься, особенно зимой, там сначала добежать, потом ворота откопать, потом двери..
И самое главное, оборудование нужно сейчас, дабы успели изготовить, а программисты — потом. И нет уверенности что это будут одни и те же люди.
По ДЭС другая история, но тут процедура еще не запущена и документы официально не публиковались, поэтому пока вслух не комментирую.

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

Так вот если взять готовую систему, их много, то купить можно уже сейчас и собирать, а на ПНР настроить. Программист не нужен от слова «совсем».
Больше того, как только будет физический доступ к оборудованию (монтаж и готовность к пуску не требуются) — уже можно выполнять ПНР на мат.модели, настроив все алгоритмы и посмотрев как они работают, связь с верхним и нижним уровнем будет проверена по мере готовности монтажа.

Опробовать можно на стенде поставщика системы. Да, не каждая такая система может похвастаться наличием такой готовой мат.модели или стенда у поставщика, но даже если этого нет — страшного ничего, на предстоящей ПНР это не скажется слишком сильно.

Можно работать и с ПЛК, но тогда я бы в первую очередь проверил наличие в ПО для программирования полноценного имитатора (и именно по этому критерию и выбирал бы контроллер) и посадил бы программиста работать уже сейчас, а монтаж и закупка пусть себе идёт.
В процессе работы программист изобретёт очередной велосипед, не учтёт пару-тройку нюансов объекта и все равно просидит на ПНРе с месяц, и набегается. Но это тоже решение.

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

Вопрос был про выбор контроллера. Я бы брал (если не готовую систему, что было бы лучше и дешевле) резервированный контроллер с полной отладочной оффлайн-имитацией в ПО — под эту задачу.
В Aris есть отладчик, но его надо для начала пощупать. Резервирования не увидел. Для сбора и трансляции данных и телеуправления он вполне наверное неплох и даже очень пригодится, тем более что софт для верхнего уровня под него тоже есть готовый, но вот PMS я бы на него не стал вешать.

petr2off писал(а): ↑24 май 2018, 06:29
Насчет обработки, она весьма слабая и медленная. Стандартный цикл — 300 мс. Фактически это FDB скрипты, которые к тому же последовательно выполнятся. Сама реализация FDB — очень убогая. В ней например наличие внутренних переменных не предусмотрено. Т.е. рассчитывать на какое то сложное управление — я бы не стал. Задачи АСУ ТП у ПРософта решаются на других контроллерах — Regul.
По стандартной схеме ARIS почти не программируется, там идет настройка клиентов и серверов по части «телеизмерений», «телесигналов» и «телеуправления».

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

TEB писал(а): ↑23 май 2018, 23:05
В списке функций есть Power Management в полный рост, а также и управление нагрузками. АСУ генерации с такой структурой обречена положить всю станцию при единичном отказе в контроллере, который неминуемо случится. Смотри, я не знаю, можешь ли ты повлиять на структуру системы, но я рекомендую это сделать, иначе намучаются все.

Это отдельная история. Заниматься менеджментом надо как при работе от ДГУ, так и при работе от сети, потому как там тоже все весьма жестко по соотношению источник/приемники. ЕЭС мы конечно не развалим, но отключение по САОН словить можно запросто.
Так что эта затея должна работать не на уровне локальных РТП, а глобально на уровне предприятия. До этой части у меня руки еще не дошли. Хотя в ближайшее время придется заниматься и этим. Я пока для РТП условно требую ретрансляцию сигнала резерва мощности с верхнего уровня и сигнал доступной на ДЭС обратно.

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

АСУ генерацией — это в составе генерации. Тут только пуск ДЭС и взаимоблокировки с сетевыми аппаратами.

Вопрос был про выбор контроллера. Я бы брал (если не готовую систему, что было бы лучше и дешевле) резервированный контроллер с полной отладочной оффлайн-имитацией в ПО — под эту задачу.

Это к тому же. Сейчас, фактически, речь про закупку РТП с полукомплектом телемеханики. Второй полукомплект и система управления с мозгами будут отдельно.
Интерес был (точнее, возник по ходу обсуждения) в применимости мозгов ARIS для решения этих задач. Получается что и применимы плохо, и мозгов там не очень много.

petr2off писал(а): ↑24 май 2018, 06:29
Насчет резервирования — есть оно у Прософта. Эта часть у них очень неплохо сделана. Причем, возможно резервирования в 2-х вариантах: Горячий резерв, резервный контроллер стоит на подхвате и дублирование — оба параллельно работают. Организуется все на уровне настройки, эта часть мне понравилась. Можно и каналы связи дублировать, даже RS485.

Это хорошо.

petr2off писал(а): ↑24 май 2018, 06:29
Насчет обработки, она весьма слабая и медленная. Стандартный цикл — 300 мс.

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

Никита писал(а): ↑24 май 2018, 09:15
Тут только пуск ДЭС и взаимоблокировки с сетевыми аппаратами

Так это и есть PMS! Самое главное. И пуском и блокировками дело не ограничится — это я гарантирую.

Никита писал(а): ↑24 май 2018, 09:15
Интерес был (точнее, возник по ходу обсуждения) в применимости мозгов ARIS для решения этих задач. Получается что и применимы плохо, и мозгов там не очень много.

Я даю отрицательный ответ. Много-не много — это относительно (3 волоса — это когда на голове то мало, а когда в тарелке то много). Для телемеханики и сбора данных его вполне можно использовать, возможно даже избыточно (надо смотреть к чему он должен подключаться). Может подошёл бы любой привычный ПЛК для этих целей, а может и вовсе можно без него обойтись — надо весь объект смотреть. По крайней мере на нескольких объектах так и делали — ставили отдельный шкаф с 19″ серверами для хранения данных и один S7-300, задача которого была только опрашивать весь управляющий уровень и складывать данные на сервера. Верхний уровень брал данные с этих серверов для отображения и обработки.

TEB писал(а): ↑24 май 2018, 14:54
Не пойдёт. Было бы в принципе некритично, в генерации все процессы медленные, но кроме одного случая — реакция на исчезновение сети. Переключать режимы генераторов надо мгновенно и притом сразу все, чем быстрее тем лучше — чем быстрее переключимся — тем выше шанс удержать станцию от завала. Учитывая что и модбас сам по себе медленный для таких вещей, задержка может быть слишком большая — станция успеет развалиться. Поэтому это делается как правило на управляющем уровне без участия центрального поста, пульта или системы сбора данных. Опять же, сдохнет этот центральный ПЛК — и что, останемся без этого переключения (если эта функция висит на нём)? Нехорошо

Или мы о разных вещах говорим, или я пока не понял твою мысль. Станция начинает запускаться и собираться только после исчезновения сети. Запуск ДЭС в нашем случае выполняется как в том анекдоте: может ли замполит на пл запустить дизель? Может, через «каштан»: -шестой! — есть шестой! — пустить дизель! — есть пустить дизель!
Параллели с сетью нет и не предвидится. Обрыв питания в минуту-три некритичен. Более того, мгновенное переключение даже вредно. В нашем случае мощность ДГУ рассчитывалась только на первую группу. Если перед включением ДЭС на нагрузку не поотключать лишнее, станция свалится, какие бы чудесные дизеля не стояли.

Никита писал(а): ↑24 май 2018, 20:37
Или мы о разных вещах говорим, или я пока не понял твою мысль.

О разных.

Никита писал(а): ↑24 май 2018, 20:37
Параллели с сетью нет и не предвидится.

Тогда вычёркиваем всё что я написал про отвал сети. Но всё остальное остаётся в силе.

Никита писал(а): ↑24 май 2018, 20:37
Если перед включением ДЭС на нагрузку не поотключать лишнее, станция свалится, какие бы чудесные дизеля не стояли.

Верно. А кто потом будет включать отключенное? И сколько групп потребителей надо отключать?

В целом, мысль моя такова, что управление генерацией — это одно, ПАЗ — это другое, а диспетчеризация — это третье. Это совсем разные вещи и как бы ни хотелось их объединить — не стОит этого делать. То есть, по моему мнению, максимум того что можно возложить в части управления на этот контроллер — телемеханика (то есть трансляция команд управления). Отключение нагрузок — это защита. Последующее включение нагрузок — это управление генерацией (генерация даёт разрешение), то есть эти вещи можно совместить в генерации если там есть такие штатные функции (обычно есть).
Блокировка включения сети при работающей генерации — это функция ввода, генерация туда пришлёт сигнал(ы) о том что «низя» и ввод не должен включаться. Блокировка включения нагрузки при недостатке резерва мощности — это функция генерации потому что только генерация резерв мощности и определяет.

[+] Особенности учёта резерва мощности

Этот нюанс надо прописывать в алгоритме (а в готовой автоматике он учтён сразу). И такого много. В результате вроде бы простой алгоритм обрастает такими вот исключениями и вырастает до приличного объёма. И когда надо будет что-то поправить со временем, то что будет делать эксплуатация: снова звать программиста? Который будет неделю собираться, день ехать, пару дней править, ещё день проверять? Средняя командировка инженера это примерно 500 евро в сутки плюс дорога и проживание.
Чем больше таких насыщенных программных комплексов — тем больше ездить и платить за это.
В готовой автоматике это всё правится за 1 минуту на лету, на месте тем же персоналом, и главное работает независимо от телемеханики и верхнего уровня вообще. То есть пропадёт связь, обесточится всё (независимо друг от друга, но по закону подлости ведь за раз случатся все возможные неприятности, а не в порядке очереди) — генерация сама всё отработает, как связь появится — диспетчер получит известие о том что всё сделано без него, свет у людей есть.

[+] был как-то случай

Ну и по отказоустойчивости тоже есть вопросы: сдохла связь с верхом, сдох центральный контроллер — и всё? Ничего не работает?
Нелогично.

petr2off писал(а): ↑25 май 2018, 07:14
Прософт поддерживает Modbus, но он все таки у них «нелюбимый». Они ориентируются в первую очередь на 101,103,104 и 850

Верно. А генерация — это будет с большой вероятностью ModBUS.

petr2off писал(а): ↑25 май 2018, 07:14
С их точки зрения контроллер ARIS не должен заниматься быстрыми переключениями, на это есть комплексы аварийной защиты, он все быстро-быстро сделает, а потом потихоньку осциллограмму в ARIS перекачает, что бы в SCADA можно было на это дело посмотреть и понять — когда и что отвалилось/включилось.

Точно так.

Никита писал(а): ↑25 май 2018, 09:13
Модбас в данном случае имеет недостаток — в нем изначально не предусмотрена передача меток времени.

Метки времени присваиваются в локальных журналах внутри оборудования.

TEB писал(а): ↑25 май 2018, 10:09
Никита писал(а): ↑24 май 2018, 20:37
Если перед включением ДЭС на нагрузку не поотключать лишнее, станция свалится, какие бы чудесные дизеля не стояли.
Верно. А кто потом будет включать отключенное? И сколько групп потребителей надо отключать?

Верно. А кто потом будет включать отключенное? И сколько групп потребителей надо отключать?[/quote]
Вот в этом и был изначальный вопрос. Чтобы запомнить отключенное и потом включить обратно контролеру должно хватить мозгов. Я уже писал, реализация массивов на FBD — большая морока. Вот нашли ответ — включать надо кому-то еще. Или сверху, с уровня серверов, или на том же уровне ставить пару контроллеров. Первое дешевле, второе надежнее. Увы, решения принимаю не я один.

Последующее включение нагрузок — это управление генерацией (генерация даёт разрешение), то есть эти вещи можно совместить в генерации если там есть такие штатные функции (обычно есть).
Блокировка включения сети при работающей генерации — это функция ввода, генерация туда пришлёт сигнал(ы) о том что «низя» и ввод не должен включаться. Блокировка включения нагрузки при недостатке резерва мощности — это функция генерации потому что только генерация резерв мощности и определяет.

Это даже не обсуждается. Особенности резерва мощности остаются за поставщиком генерации. Как и вся генераторная и дизельная автоматика. Нагрузить машину 10кВ на 50% не получится, потому как нечем, кроме шин РТП. Испытательный нагрузочник сейчас обсуждается, но при испытаниях там должна быть минимум пара человек живых оперативников.
Второй вопрос — на чем будет эта генераторная автоматика. Увы, тоже пока грустный, хотя проблески есть.

Ну и по отказоустойчивости тоже есть вопросы: сдохла связь с верхом, сдох центральный контроллер — и всё? Ничего не работает?
Нелогично.

На «большую» энергетику глянь, там такое сплошь и рядом. Связь с верхом (ЕЭС и сетевой), противоаварийная автоматика уровня энергосистемы и много чего еще. Да, местная РЗА первична. Но устойчивость системы она не обеспечит, это делается с уровня РДУ, которое видит всю картину. Решается резервированием.
У нас попроще, но тоже могут быть ситуации, когда вмешательство с верха будет необходимо. Или с места, но проблему с лопатой я уже описывал.

Метки времени присваиваются в локальных журналах внутри оборудования.

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

Никита, задача как-то с конца решается. Я пожалуй пас.

Вопрос про точность времени не понял. В каком конкретно оборудовании? И тут все зависит ещё от того как синхронизировать собираетесь. А вообще это лучше у прософта спросить, раз они в эту железку ОСРВ засунули то с точностью времени там должно быть всё как в космосе (хорошо и дорого).

Задача решается по частям. Задачу управления генерацией решает поставщик генерации. Задачу управления авппаратами на стороне 150 решает поставщик ГПП. Задачу оснащения РТП и КТП релейкой и телемеханикой решает поставщик этого оборудования. Задачу общеплощадочного взаимодействия решает поставщик общеплощадочной АСУЭ. Вот ему то все косяки предыдущих и достанутся.

TEB писал(а): ↑25 май 2018, 23:17
В каком конкретно оборудовании?

В данном конкретном — это в вашем. Вопрос про генерацию и точность отметок в журналах ДЭСки. Вопрос по арису задам прософту)

Никита писал(а): ↑26 май 2018, 09:41

TEB писал(а): ↑25 май 2018, 23:17
В каком конкретно оборудовании?

В данном конкретном — это в вашем. Вопрос про генерацию и точность отметок в журналах ДЭСки. Вопрос по арису задам прософту)

А там есть что-то наше?
У нас разрешение 0.1 сек, время локальное. Могу пример журнала попозже показать,

TEB писал(а): ↑28 май 2018, 01:44
А там есть что-то наше?

Еще не знаю. Процедуру по ДГУ еще не запускали.

TEB писал(а): ↑28 май 2018, 01:44
У нас разрешение 0.1 сек, время локальное. Могу пример журнала попозже показать,

Вот тут уже интереснее. Для генерации это нормально. Но разбор полетов совместно с журналами РЗА, которые пишут, условно, до милисекунды, усложняется.
Контроллеры не для управления, а для защиты (та же ДЗ генераторов) тоже так со временными отметками работают?
Пример не очень интересен, интересен формат и возможность его экспорта в табличном виде, дабы потом можно было через SQL подгрузить в общий журнал событий.

Никита писал(а): ↑28 май 2018, 09:23
Вот тут уже интереснее. Для генерации это нормально. Но разбор полетов совместно с журналами РЗА, которые пишут, условно, до милисекунды, усложняется.

Ерунду пишут.
С РЗА берут осциллограммы чтобы увидеть первопричину аварии (легко отличить однофазное КЗ на землю от трёхфазного глухого). В осциллограммах будут миллисекунды и это необходимо.
С генерации берут журналы работы оборудования чтобы понять, как система (и генерация) среагировала на первопричину — здесь только дискретные события, для которых и одной секунды более чем достаточно. Если сложить такой журнал событий с осциллограммами — становится ясна картина события от начала и до конца. Не одно ЧП так разбирали. А если не складывать а смотреть только в журналы, то не всегда удаётся понять саму первопричину, но развитие ЧП всё равно видно.
Это релейщики пишут, которые не знают что кроме РЗА есть контроллеры, которые работают не как РЗА.

[+] лирика

Никита писал(а): ↑28 май 2018, 09:23Контроллеры не для управления, а для защиты (та же ДЗ генераторов) тоже так со временными отметками работают?

Могу отвечать только за наши. Проверю этот момент отдельно — для диф.защиты у нас отдельный контроллер.

Никита писал(а): ↑28 май 2018, 09:23
Пример не очень интересен, интересен формат и возможность его экспорта в табличном виде

Наши журналы по умолчанию забираются из контроллеров в Excel, можно также и в PDF забрать (как раз чтобы предотвратить обработку). Равно как и все параметры контроллера могут быть экспортированы в PDF и большинство — в Excel. Обычные .xls-файлы — я только по ним часто делаю разборы полётов и вообще удалённую отладку и помощь в настройках и техподдержку. Обычно их выгружают в наладочный ПК вручную сервисным ПО (бесплатным) и дальше работают с файлами. Однако никто не запрещает читать эти журналы из контроллера куда угодно — формат описан.

Отправлено спустя 17 минут 13 секунд:

Никита писал(а): ↑28 май 2018, 09:23
Контроллеры не для управления, а для защиты (та же ДЗ генераторов) тоже так со временными отметками работают?

Проверка у меня займёт много времени. Обычно этим не заморачивались потому что с контроллера дифзащиты обязательно летит дискретный сигнал в контроллер генерации (как правило для экстренного останова) — там он и регистрируется вместе с общими событиями.
А если требуется посмотреть в деталях осциллограммы внутреннего пробоя генератора (или трансформатора сразу за ним) — можно использовать функцию дифзащиты в той же релейке. Даже автоматы на 0,4 есть сейчас не только с защитой от утечек но и с журналами и быстрыми интерфейсами сразу. Только вот зачем — не знаю (наши производители тоже не знают и поэтому не сделали такую функцию). Для генерации причина пробоя не важна (её потом ремонтники увидят) — важен только факт, который означает «всё, приехали, быстро выключай!».