Первый шаг зделан. Что дальше?
| 1 | 2 | 3 | Дальше | В конец
| Автор |
Сообщение |
|
Сообщение создано: 10. 03. 2011 [17:51]
|
|
Nika
Николай Емакаев
Создатель темы
Зарегистрирован(а) с: 10.03.2011
Сообщения: 18
|
Система получилась на удивление устойчивой. С чем и поздравляю всех разработчиков. Но как развивать систему.
1. Технологический процесс ведут технологи, которые игнорируют ператор "if" и все что с ним связано. Технологи оперируют понятиями отличными от понятий програмиста. Технологи с навыками програмного обеспечения очень редки. Но АСУ ТП делается для облегчения именно технологов. Применение совместно с java подобным языком - функциональных блоков приведет к расширению применимости системы.
2. Технологический процесс формируется технологическим оборудованием. Без оценки состояния технологичеакого оборудования финансовые потери при ведении техпроцесса значительно выше. На первом этапе необходимо в системе иметь прогнозные характеристики по параметру. Причем надо учитывать что закон изменения, чаще всего, неизвестем. Интересует всех время достижения критерия. (отказа оборудования).
3. Образ техпроцесса формируется средствами АСУ ТП. (датчиками, линиями связи, контроллерами и системой). Всё это железо имеет подлое свойство отказыват в самый неродходящий момент. Цель системы выявлять скрытые отказы и корректировать воздействия. Для начала доработать протокол MADBUS.
3.1 Интегральная оценка - отношение неудачных сеансов связи к общему числу связей для данного контроллера. Причем этим параметром можно оперировать. (обробатыват, выводить на график и т.д.)
3.2. Дифференциальные оценки - отношение ошибки с конкретным номером к общему количеству ошибок. (вес ошибки).
Буду блогодарен всем, кто выскажется по поводу сделанных предложений.
|
|
Сообщение создано: 10. 03. 2011 [19:08]
|
|
Aleksey
Aleksey Popkov
Contributor
Зарегистрирован(а) с: 31.07.2008
Сообщения: 326
|
Аминь.
|
|
Сообщение создано: 10. 03. 2011 [19:56]
|
|
Maxim
Maxim Lisenko
Contributor
Зарегистрирован(а) с: 18.08.2008
Сообщения: 141
|
"Nika" wrote:
Система получилась на удивление устойчивой. С чем и поздравляю всех разработчиков. Но как развивать систему.
Спасибо за поздравления. По поводу развития системы есть обобщенный план развития системы: http://wiki.oscada.org/Works/RoadMap . Никто не мешает вносить свои предложения.
"Nika" wrote:
Технологический процесс ведут технологи, которые игнорируют ператор "if" и все что с ним связано.
Это очень спорно. Зачастую технолог не является разработчиком программы контроллера, "верхнего" уровня и т.п. К тому же, в том же Step7 большой популярностью пользуется STL и все больше популярности получает SCL, а во всех серьезных SCADA на "верхнем" уровне применяется тот или иной скриптовый язык. Да и не стоит в 21 веке так абстрагироваться от программирования, так как оно уже всюду в той или иной степени.
"Nika" wrote:
Но АСУ ТП делается для облегчения именно технологов.
Правильно! Но это же не обязывает технологов заниматься непосредственно созданием программ, скриптов, и т.д. Разделение труда в этом, как и во многих других случаях, очень ускоряет процесс!
"Nika" wrote:
2. Технологический процесс формируется технологическим оборудованием. Без оценки состояния технологичеакого оборудования финансовые потери при ведении техпроцесса значительно выше. На первом этапе необходимо в системе иметь прогнозные характеристики по параметру. Причем надо учитывать что закон изменения, чаще всего, неизвестем. Интересует всех время достижения критерия. (отказа оборудования).
Собственно, очень тяжело понять, что имелось в виду.
|
|
Сообщение создано: 11. 03. 2011 [08:01]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
Зарегистрирован(а) с: 12.12.2007
Сообщения: 3750
|
Возможно это Вы зделали первый шаг, а у проекта это всего навсего очередной шаг за 8 лет существования.
"Nika" wrote:
1. Технологический процесс ведут технологи, которые игнорируют ператор "if" и все что с ним связано. Технологи оперируют понятиями отличными от понятий програмиста. Технологи с навыками програмного обеспечения очень редки. Но АСУ ТП делается для облегчения именно технологов. Применение совместно с java подобным языком - функциональных блоков приведет к расширению применимости системы.
Предельно ошибочное заявление. ТП ведёт, вёл и будет вести оператор! Основными пользователями SCADA систем всегда были программисты SCADA и операторы, и никогда технологи, кроме редких случаев получения истории для автономного анализа в средствах для этого предназначенных. Технологи привлекаются только на момент создания или модернизации ТП с автоматикой. Из чего все остальные выводы и соображения так-же ошибочны!
Про функциональные блоки уже лет шесть как здесь: http://wiki.oscada.org/Doc/BlockCalc
"Nika" wrote:
2. Технологический процесс формируется технологическим оборудованием. Без оценки состояния технологичеакого оборудования финансовые потери при ведении техпроцесса значительно выше. На первом этапе необходимо в системе иметь прогнозные характеристики по параметру. Причем надо учитывать что закон изменения, чаще всего, неизвестем. Интересует всех время достижения критерия. (отказа оборудования).
Нет проблем. JavaLikeCalc вам в руки и делайте любую аналитику. Хотя любая аналитика это уже не АСУТП и не SCADA, а АСУП и ERP.
"Nika" wrote:
3. Образ техпроцесса формируется средствами АСУ ТП. (датчиками, линиями связи, контроллерами и системой). Всё это железо имеет подлое свойство отказыват в самый неродходящий момент. Цель системы выявлять скрытые отказы и корректировать воздействия. Для начала доработать протокол MADBUS.
Скорее Вам нужно сходить сюда http://oscada.org/ru/razrabotka/pomoshch и для начала внимательно прочитать последний абзац!
"Nika" wrote:
3.1 Интегральная оценка - отношение неудачных сеансов связи к общему числу связей для данного контроллера. Причем этим параметром можно оперировать. (обробатыват, выводить на график и т.д.)
3.2. Дифференциальные оценки - отношение ошибки с конкретным номером к общему количеству ошибок. (вес ошибки).
Всё та же динамическая аналитика и типовая диагностика, что без каких либо проблем делается.
Learn, learn and learn better than work, work and work.
|
|
Сообщение создано: 11. 03. 2011 [20:09]
|
|
Nika
Николай Емакаев
Создатель темы
Зарегистрирован(а) с: 10.03.2011
Сообщения: 18
|
Спор о том кто значимее, оператор - технолог или програмист столь же древен и бесперспективен как и вопрос есть ли жизнь на марсе. Если я задел ваше самолюбие - прошу извинить. Теперь о деле. Протокол ModBus имеет функцию передачи ошибок, обнаруженных контроллером. Разработаный Вами модуль сбора ModBus данной функции не имеет. Входит ли в планы разработчиков дополнить модуль данной функцией или мне писать собственный протокол, удовлетворяющий требованиям ModBus.
Теперь о диагностике. 1. Все системы диагностики, о которых я знаю, порождены принципом еденичного отказа сформулированного документом SQ-50 требований МАГАТЕ.
Система должна сохранять свою работоспособность при:
1. Наличии одного скрытого дефекта.
2. Одного обнаруженного дефекта.
3. Одного канала, выведенного в ремонт для устранения дефекта.
Если соответствовать данному требованию в лоб необходимы 4 независимые системы. Но можно пойти путём оценки состояния и прогноза изменения данного состояния во времени. В данном случае обнаруживается и анализируется не сам дефект, а признаки сопутствующие появлению дефекта. Данный метод позволяет сократиь количество оборудования. (а это деньги и на обслуживании в том чесле.) Для Максима Лысенко Мой адрес Nika1150@mail.ua Пришлите весточку, я перешлю вам материалы по диагностике оборудования и средств АСУ ТП включая диагностику датчиков.
|
|
Сообщение создано: 11. 03. 2011 [21:18]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
Зарегистрирован(а) с: 12.12.2007
Сообщения: 3750
|
"Nika" wrote:
Спор о том кто значимее, оператор - технолог или програмист столь же древен и бесперспективен как и вопрос есть ли жизнь на марсе. Если я задел ваше самолюбие - прошу извинить.
Это не спор про значимость и моё самолюбие тут не при чём, ибо я себя не отношу ни к одной категории полностью, а по статусу выполняю роль всех их!
"Nika" wrote:
Теперь о деле. Протокол ModBus имеет функцию передачи ошибок, обнаруженных контроллером. Разработаный Вами модуль сбора ModBus данной функции не имеет.
Я таких контроллеров лично не знаю ни одного.
"Nika" wrote:
Входит ли в планы разработчиков дополнить модуль данной функцией или мне писать собственный протокол, удовлетворяющий требованиям ModBus.
Не входит ибо не нужен был и оборудования для проверки этого у меня нет. Если это нужно Вам и Вам легче всё писать с нуля, чем добавить банальное чтение этого признака в существующий то пишите.
В конце концов скажите, что это за функция и я сам её добавлю, хотя все нестандартности протокола ModBus сейчас легко решаются и без этого, с помощью функции пользовательского API SYS.Transport.messIO() ( http://wiki.oscada.org/Doc/OpisanieProgrammy?v=x3w#h920-10 ).
"Nika" wrote:
Теперь о диагностике. 1. Все системы диагностики, о которых я знаю, порождены принципом еденичного отказа сформулированного документом SQ-50 требований МАГАТЕ.
Атомная энергетика это уже панацея всех систем автоматизации?
"Nika" wrote:
Система должна сохранять свою работоспособность при:
1. Наличии одного скрытого дефекта.
2. Одного обнаруженного дефекта.
3. Одного канала, выведенного в ремонт для устранения дефекта.
Если соответствовать данному требованию в лоб необходимы 4 независимые системы. Но можно пойти путём оценки состояния и прогноза изменения данного состояния во времени. В данном случае обнаруживается и анализируется не сам дефект, а признаки сопутствующие появлению дефекта. Данный метод позволяет сократиь количество оборудования.
Это узко-специализированная проблема области в которой Вы работаете. В тех областях которых работал я этого нет, поэтому и не нужно требовать решения Ваших проблем.
Просто сформулируйте проблему конкретно, реализуйте и проверьте на доступном оборудовании.
А будут вопросы - поможем их оптимально решить.
Learn, learn and learn better than work, work and work.
|
|
Сообщение создано: 11. 03. 2011 [21:23]
|
|
Maxim
Maxim Lisenko
Contributor
Зарегистрирован(а) с: 18.08.2008
Сообщения: 141
|
"Nika" wrote:
Спор о том кто значимее, оператор - технолог или програмист столь же древен и бесперспективен как и вопрос есть ли жизнь на марсе. Если я задел ваше самолюбие - прошу извинить.
Да причем здесь значимость профессий. Вам же уже ответили, что тех. процесс ведет оператор, для которого и разрабатывается интерфейс, программист программирует, а технолог принимает участие в разработке алгоритмов управления и, возможно, в создании "верхнего" уровня SCADA системы. Банальное разделение труда. :-)
"Nika" wrote:
Теперь о диагностике. 1. Все системы диагностики, о которых я знаю, порождены принципом еденичного отказа сформулированного документом SQ-50 требований МАГАТЕ.
Попробовал найти указанные требования и у меня это не получилось. Касательно принципа единичного отказа, так на деле принцип единичного отказа реализуется путем резервирования, как программного, так и аппаратного и от него никуда не деться. Если нужна надежная система, она должна быть полностью резервирована, или хотя бы критически важная ее часть.
"Nika" wrote:
Но можно пойти путём оценки состояния и прогноза изменения данного состояния во времени. В данном случае обнаруживается и анализируется не сам дефект, а признаки сопутствующие появлению дефекта.
Опять же повторюсь, кто мешает Вам анализировать эти признаки, хранить информацию в архиве, отображать ее на графиках, мнемосхемах и т.д.
Информацию можете прислать на mlisenko@oscada.org .
[Сообщение редактировалось 1 раз(а), в последний раз 11.03.2011 в 21:24.]
|
|
Сообщение создано: 12. 03. 2011 [18:21]
|
|
Nika
Николай Емакаев
Создатель темы
Зарегистрирован(а) с: 10.03.2011
Сообщения: 18
|
Роман Вы правы. Я птинец средьмаша. Но Вы наверно помните что средьмаш не только атомные электростанции. Принцип еденичного отказа применяют в министерствах металургии, нефтяной и невтеперерабатывающей прмышленности, авиционной промышленности, транспорте, химической промышленности и т. д. Если Вас интересует - приведу конкретные примеры. Контроллеры с анализом состояния каналов связи, включая датчики, и передачи ошибок по протоколу ModDus выпускает на Украине. Тип ТЕР107. Ближайшие аналоги на сигнальных процессорах существуют в штатах, европе (Франция, Германия) России и Китае но с запретом поставок в третьи страны и ограничением во вторые. Протоколы спецефичные, Наверняка для войны.
Протокол при обноружении ошибки. Ответ контроллера.
Адрес 0хХХ
Функция 1ХХХХХХХ 1- признак ошибки обнаруженной контроллером.
Код ошибки 0хХХ
Контрольная сумма (LRC) 0хХХ
Прошу обратить внимание что 3 ошибки определяются SCADA системой и если их добавить 0х8Х то будет единообразие последующей обработки.
|
|
Сообщение создано: 12. 03. 2011 [20:50]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
Зарегистрирован(а) с: 12.12.2007
Сообщения: 3750
|
"Nika" wrote:
Прошу обратить внимание что 3 ошибки определяются SCADA системой и если их добавить 0х8Х то будет единообразие последующей обработки.
Не понятно вообще о чём речь. То что Вы написали это транспортные ошибки и ошибки запроса, но ни разу не ошибки модулей контроллера и его состояния.
И эти ошибки обрабатываются сейчас.
case 0x1: err = TSYS::strMess(_("1:Function %xh is not supported."),pdu[0]&(~0x80)); break;
case 0x2: err = _("2:Requested address not allow or request area too long."); break;
case 0x3: err = _("3:Illegal data value into request."); break;
case 0x4: err = _("4:Server failure."); break;
case 0x5: err = _("5:Request requires too long time for execute."); break;
case 0x6: err = _("6:Server is busy."); break;
case 0x7: err = _("7:Programm function is error. By request functions 13 or 14."); break;
case 0xA: case 0xB: err = _("10:Gateway problem."); break;
default: err = TSYS::strMess(_("12:Unknown error: %xh."),pdu[1]); break;
Learn, learn and learn better than work, work and work.
|
|
Сообщение создано: 14. 03. 2011 [08:46]
|
|
Nika
Николай Емакаев
Создатель темы
Зарегистрирован(а) с: 10.03.2011
Сообщения: 18
|
Не понятно:
1. Куда это вставить.
2. Что делать с ошибками больше чем 0хА.
3. При искуственном формировании ошибки от контроллера, в системе отображения сохраняются результаты предыдущего опроса.
4. Нарушение принципа Котельникова - решение на управление принимается на основании ложных данных.
С уважением Емакаев Н.
|
| 1 | 2 | 3 | Дальше | В конец
|
|
