Вход на сайт

МЕДИАМЕТРИКА

Облако тегов

ITER: Система измерения и управления

Аватар пользователя Лектор

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


  1. Как оказалось, СИУ ITER еще не существует в целостном виде! В отличии от других систем, она не проходила предварительного дизайна, CDR - PDR - FDR (экспертизы разных детализаций проекта системы), она не вручена какому-то из агенств для производства и поставки.
  2. Вместо этого, был создан набор свободно распространяемого софта и железа и правил, по которым из это набора надо собирать свой кусок системы управления для каждого из изготавливаемых блоков ИТЭРа.
  3. Из этого вытекает, что управление созданием этой системы сильно отличается от других - ей занимается в основном международное агенство и оно же в ежедневном режиме занимается интеграцией создаваемых кусков.
  4. Важным фактором, который влияет на облик СИУ является то, что каждый запуск ИТЭР будет собирать научную информацию темпом примерно 20 гигабайт в секунду, которые надо в промежутке между запусками (это всего 10-15 минут) проанализировать, промоделировать и визуализировать.
  5. Как ни странно, при этом СИУ - наиболее документированная система ИТЭР из всего, что я видел. Море информации.



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


Итак, основой СИУ ИТЭР является CODAC - это система сервисов обмена информацией, софтовая часть которой устанавливается в каждый компьютер СИУ, и подсистема CODAC - набор приложений EPICS, который занимается конкретно передачей данных, управлениеми и отображением на мониторах происходящего. CODAC исполняется в ОС RHEL (Red Hat Enterprise Linux), и это стандарт для всех элементов СИУ ИТЭР.



Рис. 1. Архитектура СИУ.


CODAC и EPICS - это т.н. data driven системы, т.е. они не передают неструктурированные данные, не занимаются оцифровкой - про эту часть чуть ниже. Структурированность данных означает, что процесс интеграции любой автоматизируемой системы, будь то система водооборота здания, высоковольтный источник напряжения или система управления плазмой начинается с структурной декомпозиции на измеряемые параметры, управляющие воздействия и функционального определения конечных автоматов и алгоритмов, связывающих входные состояния и состояния управляющих элементов (клапанов, приводов, токов и т.п.). Описанные модели на языке SDD заносятся в базу данных CODAC (на базе PostgreSQL) и автоматически генерируются конфигурационные файлы для локальных копий EPICS и CODAC, что позволяет при интеграции в общую систему автоматически подцепить этот кусок.

Основой хардварной части СИУ является  шкаф или cubicle -  фактически стойка с установленным в нем специальным контроллером PSH (Plant system host), который обеспечивает присутсвие CODAC в этом шкафу и минимальные сервисы (мониторинг температуры и потребления шкафа, мониторинг работоспособности остального оборудования шкафа) а так же отслеживает текущее состояние данной подсистемы (стенд-бай, запуск, селфчек и т.п.).



Рис.2. Синие шкафы - стандарные cubicles ИТЭРа, примерно так будет выглядеть вся автоматизация. Здесь показан запуск системы точного времени TCN ИТЭР.


В каждый шкаф, кроме этих сервисов может быть установлено так же необходимое количество быстрых  и медленных контроллеров. Под первыми, в общем-то понимаются обычные сервера, с запущенной на них той же RHEL + CODAC либо ОС реального времени MRG-R (тоже дериватив Линукса). Задача быстрых контроллеров - работа с большими объемами данных, в основном научных, а для MRG-R версий - еще и скоростное управление, например плазмой, а так же работа с аудио-видео потоками. Медленные контроллеры - на базе Siemens SIMATIC S-7 (было удивительно встретить старых знакомых) - это промышленная автоматизация систем, управление насосами, клапанами, силовыми реле, прием информации с датчиков давления, сухих контактов и т.п. Каждый такой датчик или исполнительный элемент, описывается в базе данных, как я писал выше, и через локальный сервис CODAC попадает в общую одноранговую сеть PON. Кроме цифровой части, в шкафы ставятся так называется Signal Condition Unit - элементы сбора данных (аналоговые усилители + АЦП, например) или наоборот - выдачи аналоговых данных.


Сетевая архитектура СИУ ИТЭР образована 7-ю физически разделенными сетями: это сеть общего управления PON на базе Ethernet 100/1000, скоростная оптическая сеть управления-измерения SDN на базе протокола SDN, оптическая сеть синхронного времени TCN (синхронизация 50 наносекунд по всему комплексу), скоростная оптическая сеть научных данных DAN - 10 гигабитный Ethernet, выделенная сеть для аудио-видеоданных AVN (тоже на базе Ethernet 10G), сеть CIN - это обмен данными интерлоков, об этом подробнее ниже и отдельная сеть CSN - защит и безопасности.



Рис.3. Сети СИУ ИТЭР.


Надо понимать, что любой cubicle - это не самая низовая часть автоматизации, это стандартизированная часть СИУ ИТЭР. Еще ниже лежит стандартные решения поставщиков подсистем (от готовых индустриальных, например для вентиляции зданий, до полностью разрабатываемых с нуля - как в случае элементов автоматизации источника ионов NBI). Эта, низовая часть, может включать в себя не только аналоговые и цифровые датчики всего, чего угодно (в основном температуры и давления, конечно же), но и свои контроллеры. Например, в прошлой статье я описывал разрабатываемые в НИИЭФА быстродейсвующие пневматические выключатели. Естественно они автоматизированны - средствами контроллеров INSAT.



Рис.4. Схема автоматизации блока SNU.


На блок схеме видно, что “сверху” стоит медленный контроллер S7-300, выполняющий роль шлюза управления в CODAC, а само управление и измерение параметров блока SNU (а на схеме именно он) происходит на базе контроллеров и свичей INSAT. При этом вынесенная система сбора данных отвечает сетевой архитектуре CODAC - она будет подключена через быстрый контроллер к сети DAN, а не PON, куда будет воткнут медленный контроллер этого блока.


Всего предполагается более 4,5 тысяч шкафов оборудования автоматизации, которые будут отслеживать до 100 000 точек автоматизации, и рождать потоки по 50 мегабайт в секунду данных в сетях PON и SDN. Латентность петли автоматизации для медленных подсистем и сети PON составит 100 миллисекунд, а для быстрых контроллеров и сети SDN - 500 микросекунд (фантастическая скорость, честно говоря). Обновление операторских экранов - 5 раз в секунду.



Рис.5. Распределение количества зарегистрированных в базе данных шкафов автоматизации по зданиям ИТЭР. 11 здание - сам токамак, 74 - здание диагностик.


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


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


Поговорив о низовой автоматизации (кому не хватило, могут прочесть этот документ, где описан workflow автоматизации части системы охлаждения вакуумной камеры) переместимся на самый верх. EPICS будет отвечать за отображение параметров на экранах примерно 60 операторов, которые будут задействованы в работе ИТЭР. У EPICS (который используется в десятках физических эксперементов по всему миру) есть сетевой протокол Channel Access, использующийся для доставки параметров к серверу и мониторам операторов и управляющих воздействий обратно. Пример интерфейса EPICS, кстати.



Рис. 6. Комната управления ИТЭР, концепт.


Есть и концепт комнаты управления токамаком (которая будет располагаться в отдельном здании). В принципе - ничего интересно - куча столов с мониторами и несколько больших экранов на стене.  Этот концепт был нужнее всего архитекторам, которые проектировали Control Building Гораздо интереснее центральная серверная инфраструктура, однако по ней в сети есть только некоторые разрозненные параметры - 500 петабайт под хранилище архивов, 1 петафлоп кластер для моделирования процессов. Сейчас на площадке ИТЭР развернут небольшой кластер в 84 блейд-сервера, как для задач разработки CODAC, так и для задач работы с базой данных SDD (в которой постепенно пользователями во всех компаниях - изготовителях элементов будущего ИТЭР структурируется СИУ ИТЭР), которая уже достигла более чем миллиона объектов. Кроме того на этом серверном кластере крутится мини-СИУ будущего ИТЭР, в которой включена автоматизация электроснабжения площадки а таки же зданий сборки полоидальных катушек.

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







Фонд поддержки авторов AfterShock

Комментарии

Аватар пользователя Laimingas
Laimingas(3 года 9 месяцев)(17:47:05 / 27-12-2014)

простите... редкого идиотизма билиберда

Аватар пользователя Лектор
Лектор(3 года 6 месяцев)(18:00:08 / 27-12-2014)

Неожиданно. А можно поконкретнее?

Аватар пользователя Laimingas
Laimingas(3 года 9 месяцев)(18:18:37 / 27-12-2014)

не, ну в Склоково, на попробовать гранта хватит))) - шутка, не вздумайте пробовать... еще раз простите, но напоминает курсовик балбеса студента-асушника... отойдите от реакторов с таким ужасом!!! как я понимаю про ПАЗ и РСУ у Вас смысла спрашивать нет?

Аватар пользователя Лектор
Лектор(3 года 6 месяцев)(18:30:54 / 27-12-2014)

>еще раз простите, но напоминает курсовик балбеса студента-асушника

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

>
отойдите от реакторов с таким ужасом!!! 

Хватит бредить-то.


>как я понимаю про ПАЗ и РСУ у Вас смысла спрашивать нет?

Дык они описаны, вы текст не забыли прочитать? CIN, CSN, EPICS. 

Аватар пользователя Лектор
Лектор(3 года 6 месяцев)(18:35:28 / 27-12-2014)

Реально, кстати не пойму. Я специально везде даю ссылочки - по CODAC куча более подробных документов, идите и читайте, если вам это описание кажется слишком примитивным. 

Аватар пользователя mastak
mastak(5 лет 1 неделя)(19:39:54 / 27-12-2014)

Необращайте внимания. Это очередной гуманитарий нахватавшийся слов из физики. Осмысленного понимания у него никогда не будет.

Ждем продолжения.

Аватар пользователя SKY
SKY(5 лет 8 месяцев)(20:08:08 / 27-12-2014)

Согласен.

Аватар пользователя Gbanderlog
Gbanderlog(3 года 8 месяцев)(20:35:50 / 27-12-2014)

ребят, прям гуру)), заклевали товарисча. А он в чем то прав.

Аватар пользователя SKY
SKY(5 лет 8 месяцев)(12:34:12 / 28-12-2014)

Посмотрим, пока читаем, нужна полная картина.

Аватар пользователя LvKiller
LvKiller(3 года 5 месяцев)(21:57:28 / 27-12-2014)

Легко. Когда что-то усложняется до такого уровня, что становится белибердой, это означает только одно - нас хотят обмануть. Видели мы, уважаемый, кучу примеров того, как оптимизации и "повышение эффективности" приводили к скоропостижной смерти проектов. Не стоит, увидев нечто подобное, задаваться вопросом: как же мы жили без этого? Вопрос возникает лишь один (у профессионалов) - СКОЛЬКО на этом можно поиметь, желательно быстро.

Аватар пользователя Лектор
Лектор(3 года 6 месяцев)(22:06:04 / 27-12-2014)

>Когда что-то усложняется до такого уровня, что становится белибердой, это означает только одно - нас хотят обмануть. 


Да, я думаю, неграмотный кресьянин из танзании, если ему начать рассказывать про устройство любого мобильника с той же подробностью, что я тут про ИТЭР рассказываю - скажет что-нибудь в таком же стиле: слишком сложно, никому не нужно, нас хотят обобрать. 


>Не стоит, увидев нечто подобное, задаваться вопросом: как же мы жили без этого?

Лучше задаться вопросом, зачем вы это (например интернет, изобретенный военными и невоенными учеными) начали использовать.


>Вопрос возникает лишь один (у профессионалов) - СКОЛЬКО на этом можно поиметь, желательно быстро.


Меня вот единственное поражает, все говорят про "поиметь", что вы хотите от ИТЭРа-то, что бы это было за 10к баксов? Ок, ученые вам предложат проект и на 10к баксов - но вы скажете, что он вообще почти не имеет отношения к УТС (и будете правы). Могут и за миллион, и за миллиард. Здесь было конкретное предложение - сделать реактор с Q=10, его политики приняли, где попил-то? Есть предложения у ученых и на 100 триллионов долларов (какая-нибудь база на марсе) - это тоже попил? 

Аватар пользователя iStalker
iStalker(5 лет 10 месяцев)(18:28:24 / 27-12-2014)

Я могу предположить что в России только у Газпрома есть системы автоматизации подобного масштаба, только построены буржуями скорее всего и на платном софте.

Аватар пользователя andyt78
andyt78(4 года 2 месяца)(19:32:38 / 27-12-2014)

Вы заблуждаетесь. Есть энергетики - там свои системы. Есть нефтяники. Среди ЧАСТНЫХ нефтяников БЫЛИ люди которые САМИ создавали подобные системы. Причем интегрировать кучу подсистем собранных по разрозненным проектам на тот же с7-300 проблем не было - надо было только времени)))

ВАШ главный посыл - в сраной рашке лаптем щи хлебают?)))

Комментарий администрации:  
*** Окрашиваю нашествие нацистов в розовые тона ***
Аватар пользователя Лектор
Лектор(3 года 6 месяцев)(19:42:41 / 27-12-2014)

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

Аватар пользователя aegis
aegis(3 года 7 месяцев)(19:35:25 / 27-12-2014)

СИУ ITER еще не существует в целостном виде!

Дело в том, что на уровне систем и конкретного оборудования идёт дикая грызня. Каждая компания стремиться пропихнуть свой стандарт. Уверен без OPC (соотв. OPC foundation и microsoft) тут не обошлось. А ведь есть ещё туева хуча протоколов и технологий. Я просто уверен, что сейчас серверы обмена информацией раскалены добела.

UPD: Чуть не забыл, из-за чего полез комментировать. Дело в том, что нормальных систем автоматизации просто не существует. Достаточно сказать того, что есть системы на 1С (sic!) которые используются наравне с остальными. Ничего против 1С не имею, но можете себе представить общий уровень.

Аватар пользователя andyt78
andyt78(4 года 2 месяца)(19:35:32 / 27-12-2014)

в технике была такая штука - взаимозаменяемость. Если вы посмотрите информационные стандраты ЭТОЙ страны, вы ВНЕЗАПНО обнаружите странную склонность к взаимозаменяемости протоколов передачи данных. Я не стану идеализировать ученых, но человечество в целом движется в правильном направлении - 3,4 промышленых протокола и 3,4 интерфеса. Это поверьте, не так уж и много, дедушка Сталин бы одобрил)))

Комментарий администрации:  
*** Окрашиваю нашествие нацистов в розовые тона ***
Аватар пользователя aegis
aegis(3 года 7 месяцев)(20:19:15 / 27-12-2014)

Если вы посмотрите информационные стандраты ЭТОЙ страны, вы ВНЕЗАПНО обнаружите странную склонность к взаимозаменяемости протоколов передачи данных.

Стандарты это одно, а реальность это другое. Я работаю в системном интеграторе в области телеметрии. Сходу скажу: есть только два стандарта - OPC 2.05a и ODBC. Первый жутко тормозит уже на считанных тысячах каналов. Второй требует изучения базы данных сторонней системы. Больше стандартов нет. Даже в модбас некоторые умудряются впихнуть что-то своё. И ладно бы отдельной командой - чёрта-с-два! 

Аватар пользователя Лектор
Лектор(3 года 6 месяцев)(20:23:54 / 27-12-2014)

Кстати, если брать модбас конверторы (TCP -> RS-485) то мы в свое время с удивлением обнаружили, что ISPDAS, MOXA - все они модбас на PHY уровне понимают по своему. Аналогичная ситуация и у сименса с мицубиши, но у них хотя бы честно свои реализации.

Аватар пользователя aegis
aegis(3 года 7 месяцев)(20:54:26 / 27-12-2014)

По модбасу работал только с сименсом (горелка котла). Ничего такого не заметил - всё вроде стандартное. Но я пишу пару регистров, да парочку считываю. Возможно если бы копнул глубже, то удивился бы.

Аватар пользователя andyt78
andyt78(4 года 2 месяца)(09:41:21 / 28-12-2014)

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

Комментарий администрации:  
*** Окрашиваю нашествие нацистов в розовые тона ***
Аватар пользователя andyt78
andyt78(4 года 2 месяца)(09:46:00 / 28-12-2014)

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

Комментарий администрации:  
*** Окрашиваю нашествие нацистов в розовые тона ***
Аватар пользователя Лектор
Лектор(3 года 6 месяцев)(19:53:04 / 27-12-2014)

Как раз верхний-средний уровень жестко определен - железо можно ставить из короткого каталога, софт един. Такая ситуация сложилась, потому что невозможно нарисовать СИУ для такого проекта сходу, когда многие вещи еще только обретают проектную плоть.

Аватар пользователя Gbanderlog
Gbanderlog(3 года 8 месяцев)(20:34:23 / 27-12-2014)

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

 Да блин, заводской роботизированный конвеер по сборке автомашин, с полусотней роботов это система как раз на пол процента от заявленной мощи.

И ,да, порадовало "не бывает циклов управления меньше 1 мс!". Как бы 200-300 нс на обработку логической операции контроллером еще при ельцине было нормой, сейчас думаю и подавно.

 

Вывод: автор, если хочешь писать интересное, пиши КОНКРЕТНОЕ и о чем четко и точно знаеш, а не фантазии больных головоногих. 

 

 

Аватар пользователя Лектор
Лектор(3 года 6 месяцев)(20:58:41 / 27-12-2014)

>Не понял смысла статьи вообще. 


Печально...


>Набор символов, что пытаются выдать за что то важное просто удручает. Подружить пяток интерфейсов в масштабах одной скады можно было и 10 лет назад. Один техпроцес даже масштаба реактора не превысит тысячи, максимум полторы входов выходов (это если додуматься стянуть все в один узел. ВСЕ , начиная с реакций и кончая инженеркой). 


Масштаба какого реактора? Если вы про ИТЭР, то наверное у вас есть посистемная прикидка точек автоматизации, вы же не пальцем в небо ткнули, да? Вот сколько точек автоматизации нужно для магнитных конверторов ИТЭР?

>Нахрена мутить главное зло любой работующий системы , а именно - "переавтоматизацию".

Т.е. вы думаете что ИТЭР - это что-то типа конвеера по производству плазменых выстрелов? Типа один раз настроил и нехай работает?

>Да блин, заводской роботизированный конвеер по сборке автомашин, с полусотней роботов это система как раз на пол процента от заявленной мощи.


Что, 500 сигналов? По 10 сигналов на робота? Кажется кто-то конкретно гонит.


>И ,да, порадовало "не бывает циклов управления меньше 1 мс!". Как бы 200-300 нс на обработку логической операции контроллером еще при ельцине было нормой, сейчас думаю и подавно.


Пардон, 1 микросекунда, опечатался. Для ПЛК вообще есть такое понятие как цикл (или scan что бы точнее). Уложить скан + латетность ввода-вывода в 1 микросекунду - весьма нетривиальная задача, нужны тактовые частоты за гигагерц везде. Конечно, сделать кастомный приборчик с однозадачным вечным циклом не сложно, но вы пойдите интегрируйте это в такую систему.

 

Аватар пользователя Federal
Federal(5 лет 11 месяцев)(23:31:19 / 27-12-2014)

Я конечно не работал с такими быстрыми, наносекундными, циклами, самое быстрое, что я щупал и программировал лично - это 50-микросекундный цикл, но думаю, тут основная проблема будет в обеспечении консистентности данных для матмодели на таких бешеных скоростях. Про быстрые контроллеры, "в общем-то понимаются обычные сервера, с запущенной на них той же RHEL + CODAC либо ОС реального времени MRG-R" - тема совсем не раскрыта, особенно по управлению. Жду продолжения с нетерпением. 

Аватар пользователя Лектор
Лектор(3 года 6 месяцев)(00:56:46 / 28-12-2014)

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

>самое быстрое, что я щупал и программировал лично - это 50-микросекундный цикл, но думаю, тут основная проблема будет в обеспечении консистентности данных для матмодели на таких бешеных скоростях.


Особенно для нелокальных данных. Но, думаю, еще встает проблема обработки асинхронных событий - а ведь ни одна система ИТЭР не работает без взаимодействия с другими. С аппаратной же точки зрения оцифровка с точность 10-14 бит - до 100 мегасемплов вообще никаких проблем нет, потом до 1-2 гигасемплов есть специфика, а выше - уже искусство.

Аватар пользователя Federal
Federal(5 лет 11 месяцев)(09:01:41 / 28-12-2014)

Оцифровать это ж не всё, сейчас уже есть стандартные ADC 12-bit 4 GSPS, может уже и выше, вся проблема как всегда в интеграции - я так понимаю, мало считать данные, их надо вывести.

Аватар пользователя andyt78
andyt78(4 года 2 месяца)(10:25:04 / 28-12-2014)

потому и стоимость зависит от кол-ва каналов - визуализировать на АРМ что 1200 каналов водяной насосной что 1200 каналов реактора - человеко-дней будет одинаково)))

Комментарий администрации:  
*** Окрашиваю нашествие нацистов в розовые тона ***
Аватар пользователя Federal
Federal(5 лет 11 месяцев)(11:02:07 / 28-12-2014)

Ты не понял, о чем речь. Речь о скоростных преобразованиях.

А что касается вашей навязшей на зубах насосной c фактически простейшей технологией, я эти 1200 сигналов с участием программера для верхнего уровня, будь то InTouch или WinCC, могу вывести на визуализацию за одну смену. Причем половина действий будет происходить автоматически, без моего участия. Это же касается и того, что Лектор в своей системе называет "медленным контроллером", да, там обычная технология. Стоимость там не в человеко-днях дело, а просто в стоимости железа, я не имел в виду работу программистов, конструкторов и интеграторов...

Аватар пользователя Лектор
Лектор(3 года 6 месяцев)(21:20:45 / 27-12-2014)

>Один техпроцес даже масштаба реактора не превысит тысячи, максимум полторы входов выходов (это если додуматься стянуть все в один узел. ВСЕ , начиная с реакций и кончая инженеркой). 

Кстати, Рублевская водопроводная станция москвы - 1200 сигналов. Наверное, сложнее реактора.

Аватар пользователя Federal
Federal(5 лет 11 месяцев)(23:41:28 / 27-12-2014)

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

Аватар пользователя Gbanderlog
Gbanderlog(3 года 8 месяцев)(11:22:36 / 28-12-2014)

не сравнивай жилищную диспетчеризацию и техпроцес, вещи не соизмеримые в разы, ибо если ты глянешь на структуру того самого водопровода, то наверх к диспетчеру идет не более 40-60 общих авариек и "кнопочек", остальное низовая статистика которая может масштабироватся хоть до трех тысяч хоть до пяти. Она варится внизу и капает на свои же сервера . Диспетчеру насрать на выборки расходомеров. И реактор с обвязкой он не проще, он просто рациональней сделан, никто не гоняет по сети (этож какая сеть нужна под 50 или сколько там гигов) всю статистику и данные вверх и обратно, структура там дерево, а не шина типа какого нибудь лона с адресными датчиками. Там сугубо спартанская система обмена между управляющими блоками и модулями, ибо чем меньше весит в сети, тем живучей и надежней процес. К примеру резервные дизель генераторы для Бушерской АЭС : на их обвязке стоит крейт Л кардовский около 40/6о вх./вых. и дублирующая - дополняющая флотская "Пурга", которую еще на подлодки лепят, и к блоку резервного пуска идет в обе стороны 8 сигналов и все (причем не цифровых, а махровая бинарная логика). Все остальное может прийти только на монитор в каптерку местных киповцев.

Все что описано в статье - это мать ее гигантомания , как с тем титаником. И мудрить ее собираются совсем не от большого ума, а скорее как сказал товарисч выше скорее ради сколковского гранта. 

и по роботу промышленному тебе отвечу. из его сигналов только пуск стоп есть, да аварийные биты на верх даст если засбоит, а может и битов не дать, а замкнуть адин единственный контакт, мол встал я ,зови спеца пусть коды ошибок уже с СОБСТВЕННЫХ мозгов считывают (в этих же мозгх и рабочий цикл сидит, который только по внешке синхронизируется). итого получаем 3 сигнала, остальное это порнография которую порой суют инсталяторы что бы заказчика жаба не душила если у него на хми мониторчике лампочек разноцветных мало. Переавтоматизация -это или болезнь студентов, или умысел врагов. В первом сучае лечится  временем и пиз****ми, а во втором даже и не знаю.

 

 

 

 

Аватар пользователя Лектор
Лектор(3 года 6 месяцев)(11:43:09 / 28-12-2014)

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

О, пошло виляние. Типа те сигналы, которые остались внизу - мы не считаем.


>И реактор с обвязкой он не проще, он просто рациональней сделан, никто не гоняет по сети (этож какая сеть нужна под 50 или сколько там гигов) всю статистику и данные вверх и обратно, структура там дерево, а не шина типа какого нибудь лона с адресными датчиками. 

Ну да, и в случае радиационной или не дай бог ядерной аварии мы будет туда роботов посылать, что бы посмотреть закрыт ли клапан, в каком положении СУЗ, какая температура и фон в помещении Х. 


>Там сугубо спартанская система обмена между управляющими блоками и модулями, ибо чем меньше весит в сети, тем живучей и надежней процес.

Подход понятный, но если все делать однородно, без бриджированных сетей, без кривых передачей параметров, то надежность можно поднять при весьма разветленной системе автоматизации.

Сетевые ограничения в современном мире - тоже бред, я писал выше, что поток данных от автоматизации в ИТЭР оценивается в 100 мегабайт в секунду на всю систему, по двум сетям - это  просто ни о чем для такой мегасинсталляции. 

>Все что описано в статье - это мать ее гигантомания , как с тем титаником. И мудрить ее собираются совсем не от большого ума, а скорее как сказал товарисч выше скорее ради сколковского гранта.  

Сколковский грант? Что за бред? Вы считаете что это можно было сделать дешевле - возмите одну систему и покажите на ее примере, как можно сделать проще. Там в тексте есть ссылка на подробный разбор системы охлаждения, я вот посмотрел - необходимый минимум сигналов, ни одного лишнего. А вот это "надо оставлять автономно все, не тащить в сервер" - это классная сказочка, пока у вас автономные системы. А когда у вас петелька типа "скоростное измерение магнтиных параметров - моделирование - управляющее изменение конфигурации магнитных полей - измененение токов в 15 катушках - управляющее воздействие на 15 AC/DC БП катушек - управляющее воздействие на компенсаторы реактивной мощности" идея локально циркулирующих параметров тоже не от большого ума.


>и по роботу промышленному тебе отвечу. из его сигналов только пуск стоп есть, да аварийные биты на верх даст если засбоит, а может и битов не дать, а замкнуть адин единственный контакт, мол встал я ,зови спеца пусть коды ошибок уже с СОБСТВЕННЫХ мозгов считывают (в этих же мозгх и рабочий цикл сидит, который только по внешке синхронизируется). итого получаем 3 сигнала, остальное это порнография которую порой суют инсталяторы что бы заказчика жаба не душила если у него на хми мониторчике лампочек разноцветных мало.

А СОБСТВЕННЫЕ мозги - это не автоматизация? А расскажите нам, в такой инфраструктуре переналадка - это к 50 роботам подойти, перепрошить, потом найти ошибку, еще раз подойти-перепрошить? А синхронизация у вас каким образом происходит - бинарным сигналом 24 вольта? А вот видео, тоже думаете автономные циклы крутятся, и через реле синхронизируются? ABB наверное один студенты. Давайте, больше треша, расскажите нам еще про переавтоматизацию.  

Аватар пользователя Gbanderlog
Gbanderlog(3 года 8 месяцев)(12:03:26 / 28-12-2014)

 автор ты дебил. извини что перешел на личности. Ты понятия не имеешь какую чушь несешь, со святой уверенностью в своей правоте. мы тут про архитектуру , а ты "тоже все автоматизация" , "пределов по сети нет", да все зачепись работает. Все твои петельки измерения-моделирование-управление это нижний уровень автоматизации который максимум оператору выдаст красивый график , или они у тебя украинские киборги которые считывают по гигу информации на подкорку? Как только на управление агрегатами реактора электростанции предложат поставить сеть (я не офис с секретутками имею в виду), этих дебилов увольняют сразу за профнепригодностью, это я как бы намекаю. 

 

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

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

 

 

Аватар пользователя Лектор
Лектор(3 года 6 месяцев)(12:19:44 / 28-12-2014)

Ок, ты так и не пояснил нихрена, зато ни личности перешел. Забанил.

Аватар пользователя cgi
cgi(4 года 10 месяцев)(08:26:31 / 29-12-2014)

В указанном споре соглашусь с автором статьи.

Нужно так же понимать, что все что будет сделано к старту мероприятия нужно будет еще:

1. Проверить

2. Исправить

3. Внести коррективы (хотя бы из-за расхождений между планирующимся и фактическим алгоритмом работы соседней системы).

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

Аватар пользователя lindorenan2
lindorenan2(5 лет 11 месяцев)(21:28:30 / 27-12-2014)

интересно, спасибо

Аватар пользователя Виктор Т.
Виктор Т.(3 года 4 месяца)(16:20:00 / 29-12-2014)

Всё это очень интересно (кому-то). Но вот ходят упорные слухи, что дейтеритий-тритиевую плазму пытались поджечь взрывом атомной бомбы.

Попытка оказалась неудачной.

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

Комментарий администрации:  
*** Оранжевая рыбка, выглядывающая из унитаза ***
Аватар пользователя Лектор
Лектор(3 года 6 месяцев)(16:33:56 / 29-12-2014)

>Всё это очень интересно (кому-то). Но вот ходят упорные слухи, что дейтеритий-тритиевую плазму пытались поджечь взрывом атомной бомбы. Попытка оказалась неудачной.

Вот эта попытка (ниже на фотке). Ivy Mike. Ну прям совсем неуспешная, да. 

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

В нашей стране в энергетику на быстрых нейтронах вливается примерно в 10 раз больше денег, чем в термоядерную. БН-800, МБИР, "Прорыв" (а это 2 реактора, масса стендов и 2 завода по рефабрикации топлива), ТЭМ, СВБР-100 - еще парочку проектов замутить?

Аватар пользователя Alex Grybin
Alex Grybin(2 года 6 месяцев)(19:31:46 / 01-06-2015)

))) Поджечь, хоть дейтерий-тритий, хоть дровишки - это одно. А вот чаёк вскипятить на огоньке - совсем другое. )) 

Лидеры обсуждений

за 4 часаза суткиза неделю

Лидеры просмотров

за неделюза месяцза год

СМИ

Загрузка...