Имитационный стенд для тестирования алгоритмов управления

[ydm]

На форуме поднимался вопрос по актуальности тренажеров. В продолжение темы хотелось бы услышать мнение по актуальности следующего решения в вашей практике.

Цель решения - полноценная проверка функций и алгоритмов управления АСУТП с помощью имитационного стенда. Предполагается, что в результате это позволит:

• сократить время пуско-наладочных работ;
  снизить риски возникновения аварийных ситуаций во время испытаний АСУТП;
  повысить рентабельность технологической установки благодаря улучшению эксплуатационных качеств системы управления.
  Требования к имитационному стенду

Состав стенда
Стенд оснащен динамической моделью, осуществляющей имитацию поведения реального объекта с заданной точностью.
Взаимодействие стенда с АСУТП осуществляется как на уровне физических каналов связи, так и по OPC.
Обеспечивается возможность автоматизированного тестирования алгоритмов управления.
Стенд реализован в мобильной стойке для организации выездного тестирования АСУТП на объекте.

Пример реализации
На данный момент имитационный стенда для тестирования алгоритмов управления газоизмерительной станции (АСУТП ГИС). Газоизмерительная станция представляет собой технологический объект, входящий в состав газотранспортной системы, который осуществляет коммерческий учет природного газа.


Рис.1 Структурная схема имитационного стенда и АСУТП на примере ГИС

Модель газоизмерительной станции осуществляет вычислительный процесс для расчета значений технологических параметров. Далее эти значения передаются в SCADA-приложение, которое осуществляет вывод информации на экран оператора стенда, а так же производит дальнейшее преобразование данных для передачи информации по физическим каналам связи в АСУТП ГИС. В свою очередь АСУТП ГИС в соответствии с заложенными алгоритмами формирует управляющие воздействия на объект, а так же передает данные на верхний уровень.

Функции имитационной модели ГИС:

• расчет технологических параметров процесса в динамике;
  моделирование основных режимов эксплуатации, такие как: пуск, останов, переход с режима на режим;
  возможность имитации отказов оборудования.

Имитационная модель ГИС, разработана в пакете Pipel. На фрагменте приведены основные технологические узлы газоизмерительной станции:

• участок линейного газопровода с двумя секущими кранами;
  узел подключения ГИС;
  пять измерительных трубопроводов;
  свечная обвязка ГИС.

АСУТП, операторский интерфейс

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

• технологическая схема ГИС с измерительными и исполнительными устройствами;
  тренды основных технологических параметров;
  панель задания краевых условий моделирования;
  органы переключения режимов управления и подачи сигнала аварийного останова.

Менеджер тестирования

Функции менеджера тестирования:

• задание сценариев работы объекта;
  проверку выполнения алгоритмов АСУТП;
  формирование отчетов о результатах тестирования.

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

• сократить время пуско-наладочных работ;
  снизить риски возникновения аварийных ситуаций во время испытаний и эксплуатации АСУТП;
  повысить рентабельность установки благодаря улучшению эксплуатационных качеств системы управления.

Буду рад комментариям специалистов по АСУТП.

[ydm]

Это хорошо, кода куча типовых объектов есть...иначе с массой моделей только время терять.
Мы разработали например специальную утилиту для проектирования. Нажал кнопку- 90% проекта сделано :)

Спасибо за ответ.

Стенд предназначен для тестирования уже спроектированной и смонтированной АСУТП, чтобы определить ошибки, как в алгоритмах, так и в монтаже. Если исправить выявленные ошибки на базе производителя АСУТП, то снижается время на пуско-наладку на объекте.

Утилита тоже скорее всего предназначена под определённый класс объектов для которых уже есть типовые решения.

[alex_ugrumov]

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

бывает вот так http://iprog.pp.ru/forum/read.php?f=1&i ... eply_66523

[ydm]

К слову по теме- Заказчик готов оплачивать этот стенд или вы по собственной инициативе его ваяете?

Пока договоренность с заказчиком об отладке и внедрении у него в производственном отделе.

[ydm]

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

бывает вот так http://iprog.pp.ru/forum/read.php?f=1&i ... eply_66523

Аналогично тестирование АСУ ТП на имитационных моделях в атомной отрасли перед ПНР было (не знаю как сейчас) стандартом. В нефтянке пока в новинку, кроме Транснефти.

[ydm]

В нефтянке пока в новинку

Не совсем. Для одного заказчика из нефтянки мы делали такой стенд. На нем же они потом тренировали операторов, на нем же- обучали обслугу- КИПцов, АСУТПшников... Но правда с тех пор подобных запросов просто не было. Стенд до сих пор живой, хотя ПТУшники доламывают наверное :)

На каком железе и софте делали?

[alex_ugrumov]

Алекс, там про передачу исходников речь. Не понял, как это к ПНРу относится.

Дмитрий, из поста Антона Стратулы (на который я приводил ссылку) выдержки

О том, что "всё равно на объекте по месту допиливать"

все переключения со старого КЦ (без резерва ЦП)
на новый КЦ (со 100% резервом ЦП)- подключение УСО, перепрошивка роутеров, перепрошивка адресов модулей ИО, ПНР, Индивидуальные испытания (2 часа работы ) и Комплексное опробование (72 часа)

О том как организуется стенд и что это стоит

параллельно-
в Тобольске была лаборатория МПСА (на базе отдела АСУ ТП Тобольского УМН)
на которой все алгоритмы обкатывались на ситенде- эмулятора на базе Modicon Quantum с модулями IO.- первый этап.

коллектив проектировщиков - около 15 человек...

парадокс- стоимость ПИР в итоге встала больше стоимости железа и софта по итогам торгов
и в 2 раза дольше было чем СМР.

[Михайло]

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

[ydm]

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

Моделирование этого не исключает, а как раз наоборот.

Тогда Вы поймете, что моделирование (имитация) - это пустая трата времени.

Если есть возможность, хочется услышать аргументы.

[agent_serg]

Тогда Вы поймете, что моделирование (имитация) - это пустая трата времени.

Если есть возможность, хочется услышать аргументы.

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

[Михайло]

Если есть возможность, хочется услышать аргументы.

А зачем аргументы? Зачем доказывать, что клей держит лучше, чем пластилин?
В автоматизации наиболее распространен и эффективен подход "пришел, увидел, победил". Это касается профессионалов. Есть, правда, редчайшие исключения...

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

Лично на своем опыте: на ПНР вылазят несколько мелочных косяков, которые устраняются за полчаса, ну пусть два часа. Все остальное время - это многодневная битва с непредсказуемыми нюансами.

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

[ydm]

При моделировании процессов Вы все факторы не учтёте.

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

Вы предполагаете одно, а реальный процесс преподнесёт Вам массу "невероятных приключений" по "допиливанию".

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

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

3. Могу представить. Как это связано с темой?

Именно в этом и есть опыт.

4. Опыт есть обобщенная модель субъективных суждений о частных явлениях (поведениях) в рамках конечного множества состояний объекта наблюдений. Можно ли этот опыт обобщать на всё множество объектов наблюдений и их состояний?

[ydm]

А зачем аргументы?

1.Тема топика.

В автоматизации наиболее распространен и эффективен подход "пришел, увидел, победил". Это касается профессионалов. Есть, правда, редчайшие исключения...

2.

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

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

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

4. Например?

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

5.1 Что вы имеете под методологией создания систем управления: ТАУ, конечные автоматы, UML...? Она формализуема?
5.2 Не понял в чём фабула - создавать системы управления по наитию или использовать модели для обучения проектировщиков? Если для обучения, то понятно, что инженер АСУТП использует стенд в качестве исследовательского полигона - не вижу противоречий.

[Михайло]

5.1 Что вы имеете под методологией создания систем управления: ТАУ, конечные автоматы, UML...?

Да, да, да. Это все вместе и не только это.

5.2 Не понял в чём фабула - создавать системы управления по наитию или использовать модели для обучения проектировщиков? Если для обучения, то понятно, что инженер АСУТП использует стенд в качестве исследовательского полигона - не вижу противоречий.

Вы спросили про применяемость моделирования/имитирования. Я ответил таким образом. Другие может ответят по-другому и скажут, что тратят время и деньги на создание имитационных стендов. У кого-то, действительно, стоимость ошибок при ПНР может превышать стоимость затрат на моделирование/имитирование.
Я сам, когда начинал, верил в силу и возможности моделирования, пока в этом не отпала необходимость. Аргументация: отлов ошибок в ПО занимает малую долю по сравнению с глюками железа, течью масла, поисками ошибок электромонтажа и т.д. На ПНР берешь блокнот, записываешь все глюки, потом, пока устраняют течь масла, можно поправить часть кода. Да, бывает немного задерживаешь других своими корректировками, но имитационный стенд - это тоже задержка и немаленькая.
Кстати, практически все мои объекты ПНР находятся рядом. Это наверное немаловажный фактор.

[Степа]

Тогда Вы поймете, что моделирование (имитация) - это пустая трата времени.

Профнепригоден.
Надо же так догадаться: ратовать за безопасность, но проверять алгоритмы исключительно на живых объектах...
И самое страшное: таких "инженеров" все больше и больше...

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

Все - не учтете. Но проверить те, которые на живом объекте проверять чревато или невозможно - вполне.
Более того. "Невероятные приключения" точно так же вводятся в модель и допиливаются на модели. На модели можно играть вообще в любые игры: отключать что левой пятке захочется, имитировать любые неприятности, какие только в голову могут войти... И при этом все это делать со спокойной душой: "еще никто не слышал о героически погибшем экипаже тренажера" (с)
А вот без моделей все только на словах. И никакой опыт тут Вам не поможет. Да, на бумажке расписано все правильно, но - банальнейшая опечатка, и...

В автоматизации наиболее распространен и эффективен подход "пришел, увидел, победил". Это касается профессионалов.

Это касается безграмотных, называющих себя профессионалами. Которым пока еще повезло и их объект по их вине не принес убытков и человеческих жертв.

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

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

Лично на своем опыте: на ПНР вылазят несколько мелочных косяков, которые устраняются за полчаса, ну пусть два часа. Все остальное время - это многодневная битва с непредсказуемыми нюансами.

И вся эта битва проходит на живом объекте...

[Михайло]

Надо же так догадаться: ратовать за безопасность, но проверять алгоритмы исключительно на живых объектах...

Согласно стандартам система управления и система безопасности должны быть разделены. Это закон! Если Вы не знаете об этом, то что тут уж говорить? Если Ваша система управления способна уничтожить живое и Вы тестируете ее на имитационном стенде, а затем допускаете на ПНР, то ждем инцидентов. Со временем.

Так что про профнепригодность здесь не ко мне относится.

[ydm]

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

2. Предлагаемая в этом топике тематика не нова как идеология, и за достаточно долгий период удачных и неудачных попыток применения на практике получила определённое клише.

3. Хотелось бы подойти к обсуждению без предубеждений с чистым сиянием разума и подумать, какие пути развития предлагаемой технологии тестирования АСУ ТП с помощью моделей могут быть на практике .

4. Хотелось бы отметить, что за последние годы развития имитационного моделирования существенно сократились сроки и стоимость на разработку моделей. Разработаны алгоритмы и методики идентификации параметров модели, что с успехом применяется на практике, например, в технологии APC + виртуальные анализаторы.

5. Если не думать о том, сколько времени займет разработка модели: вы получаете<censored> с моделью и физическими каналами к которым можно подключать АСУТП, аналогично монтажу на объекте. Если хотите тестировать только алгоритмы без затрат времени на подключение АСУТП к <censored>, то можно подключить теги к модели по ОРС.

[Jackson]

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

Моделирование этого не исключает, а как раз наоборот.

Тогда Вы поймете, что моделирование (имитация) - это пустая трата времени.

Если есть возможность, хочется услышать аргументы.

Трата может и не пустая, иметь тренажёр лучше чем не иметь его - это ж понятно. Но ни одна модель не сымитирует вам мокание мордочкой об стол за косяки в проекте и нерабочее железо. Более того, ни одна модель не позволит вам понять по-настоящему, что будет при аварии на установке. Авария на мониторе скучна, это даже не кино. К примеру я у себя на реальном физическом стенде раз 50 устраивал несинхронное включение, видел как срывается синхронизм, как машина втягивается, какие при этом токи. Это познавательно когда нужно понять причину аварии. Но вот когда несинхронно включаешь хотя бы 2-мегаваттный генератор, от чего валится вся станция, посёлок остаётся без света и ущерба в лучшем случае на миллион, после чего тебя пытаются повозить той же мордочкой по столу - этого ни один имитатор не в состоянии продемонстрировать. Также он не даст понимания того, как то или иное техническое решение поведет себя в нештатной ситуации. Увидеть позволит, но понять что страшнее - нет.

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

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

[Jackson]

5. Если не думать о том, сколько времени займет разработка модели: вы получаете <censored> с моделью и физическими каналами к которым можно подключать АСУТП, аналогично монтажу на объекте. Если хотите тестировать только алгоритмы без затрат времени на подключение АСУТП к <censored>, то можно подключить теги к модели по ОРС.

Это разве переход к более конструктивному диалогу? По-моему, это просто реклама, не?

[ydm]

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

Зависит от аварийной ситуации, которую вы хотите моделировать. Если математический аппарат модели позволяет имитировать физику, происходящую во время аварийной ситуации, то почему не исследовать поведение объекта в такой ситуации?

К примеру я у себя на реальном физическом стенде раз 50 устраивал несинхронное включение, видел как срывается синхронизм, как машина втягивается, какие при этом токи. Это познавательно когда нужно понять причину аварии. Но вот когда несинхронно включаешь хотя бы 2-мегаваттный генератор, от чего валится вся станция, посёлок остаётся без света и ущерба в лучшем случае на миллион, после чего тебя пытаются повозить той же мордочкой по столу - этого ни один имитатор не в состоянии продемонстрировать. Также он не даст понимания того, как то или иное техническое решение поведет себя в нештатной ситуации. Увидеть позволит, но понять что страшнее - нет.

Не понятно, стенд воспроизводит физику поведения объекта в аварийном режиме и вам стало понятно как при этом действовать, как этого не допустить, или нет?

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

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

В необходимости опыта никто и не сомневается. Собственно, в том числе, получение опыта обеспечивает стенд при исследовании работы АСУТП. Можно рассматривать предусмотренные моделью нештатные ситуации, чего вам не дадут сделать на реальном объектом.

Тренажер всегда можно поставить на паузу и уйти пить кофе. Если это тренажер самолета или реактора, то реальный самолет при таком действии упадет, а реактор например перегреется и сдетонирует.

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

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

Зависит от того сколько каналов, много место занимают модули связи с объектом. Если каналов немного, то всё очень даже элегантно помещается в стойку. Если говорить об АРМ оператора, то зависит от процесса. Если это рубка корабля, то одна площадь, если рабочее место оператора УПН - другое. Также зависит от детализации и воспроизводимого функционала. Но это уже полноценные тренажерные комплексы для обучения и в меньшей мере для проектирования.

Для тестирования АСУТП мозги помещаются в стойку, остальное количество модулей зависит от тестируемых алгоритмов управления.

[ydm]

Это разве переход к более конструктивному диалогу? По-моему, это просто реклама, не?

Скорее скрытая реклама подхода. Цель топика была услышать мнение специалистов о необходимости тестирования алгоритмов АСУТП на практике и найти направления развития и внедрения.

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

Как отмечал BigDog у компаний алгоритмы управления давно отлажены и не нуждаются в дополнительном тестировании на модели.
Как часто возникают проблемы на объекте из-за неверно сконфигурированных контроллеров и неверного монтажа стоек АСУТП?

[Jackson]

Это разве переход к более конструктивному диалогу? По-моему, это просто реклама, не?

Скорее скрытая реклама подхода. Цель топика была услышать мнение специалистов о необходимости тестирования алгоритмов АСУТП на практике и найти направления развития и внедрения.

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

Если я говорю о физической модели - зачем меня переспрашивать, воспроизводит ли стенд физику? Да, конечно воспроизводит - любая физическая модель для того и строится чтоб физику воспроизвести.

[Jackson]

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

И потом, вопрос: что считать моделью физической и математической? К примеру, реальный контроллер, а точнее их набор, которые стоят в реальных шкафах, внутри которых крутится мат.модель - это мат.модель или физ.модель? :) Я бы её назвал ФизМат-модель, потому что физика проводов тоже проверяется, а физика объекта моделируется. Чистая мат.модель не имеет физических интерфейсов. Мне видится что те стойки которые Вы предлагаете - это как раз и есть такая ФизМатМодель, по принципу ровно такая же какая есть у нас. Значит речь идет не о голой математике, а о математике, крутящейся в физической оболочке (шкаф, щит, стойка).

[ydm]

Если я говорю о физической модели - зачем меня переспрашивать, воспроизводит ли стенд физику? Да, конечно воспроизводит - любая физическая модель для того и строится чтоб физику воспроизвести.

Тогда мне непонятно, почему Ваш стенд не моделирует эту ситуацию:

Но вот когда несинхронно включаешь хотя бы 2-мегаваттный генератор, от чего валится вся станция

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

В чем заключается тестирование? По результатам тестирования выдаётся отчет?

Теперь давайте отбросим абстракцию к чертям (вторая страница уже): в чём конкретно вопросы? :) До сих пор они были общие.

Какие алгоритмы тестируются на стенде?
Каким образом осуществляется отладка алгоритмов для новых объектов управления?
Есть ли сертификаты на результаты тестирования алгоритмов управления?
Какие модели объектов используются и на чем разработаны?

И потом, вопрос: что считать моделью физической и математической? К примеру, реальный контроллер, а точнее их набор, которые стоят в реальных шкафах, внутри которых крутится мат.модель - это мат.модель или физ.модель? :) Я бы её назвал ФизМат-модель, потому что физика проводов тоже проверяется, а физика объекта моделируется. Чистая мат.модель не имеет физических интерфейсов. Мне видится что те стойки которые Вы предлагаете - это как раз и есть такая ФизМатМодель, по принципу ровно такая же какая есть у нас. Значит речь идет не о голой математике, а о математике, крутящейся в физической оболочке (шкаф, щит, стойка).

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

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

[Jackson]

Если я говорю о физической модели - зачем меня переспрашивать, воспроизводит ли стенд физику? Да, конечно воспроизводит - любая физическая модель для того и строится чтоб физику воспроизвести.

Тогда мне непонятно, почему Ваш стенд не моделирует эту ситуацию:

Но вот когда несинхронно включаешь хотя бы 2-мегаваттный генератор, от чего валится вся станция

Да потому что на стенде не двухмегаваттная турбина стоимостью в миллион евро! И не электростанция из 6-8-ми таких турбин. Никто не даст мне взять и просто сломать это всё за полчаса. Если Вы краш-тест проводите на модели автомобиля 1:100 и на натурном образце - наверное есть разница, правда? То что выдерживает киловаттный агрегат, двухмегаваттный не выдержит - массы-то! Киловаттному я устраивал несинхронное со сдвигом градусов 60 раз десять подряд, как максимум регулятор можно сжечь и всё, и то у меня этого не случилось. А двухмегаваттный уже при 30-градусном несинхронизме срывает редуктор, а иные агрегаты просто слетают с фундамента и отправляются в свободный полёт по цеху и далее в тундру, снося всё на своём пути. Регулятор при этом остаётся цел и невридим. Вот вам и разница.

Я даже не знаю что Вам еще ответить если Вы не понимаете разницы между физ.моделью и натурным объектом. Ибо если так то пропасть между мат.моделью и натурным объектом будет просто чудовищная.

В чем заключается тестирование? По результатам тестирования выдаётся отчет?

А как Вы полагаете, я это лично для себя делаю? Есть программа, по итогам протокол оформляется.

Какие алгоритмы тестируются на стенде?
Каким образом осуществляется отладка алгоритмов для новых объектов управления?

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

Есть ли сертификаты на результаты тестирования алгоритмов управления?

А протоколов испытаний недостаточно? Вот сейчас на одном из объектов прошли уже и натурные испытания, они же приемо-сдаточные. Впервые слышу чтобы сертификат кто-то требовал.

Какие модели объектов используются и на чем разработаны?

А это уже, извините, know-how. Фирма десятилетиями работает над алгоритмами управления и регулирования и над их моделями.