Скажите, зачем применяется такое тестирование как Hardware in the loop?
под этим термином как я понимаю подразумевается тестирование в реальном времени.
Но разве нельзя сделать в отложенном времени, записав предварительно тестовый сигнал и проверив время реакции?

например здесь: http://en.wikipedia.org/wiki/Hardware-in-the-loop_simulation
пишут что такое моделирование позволяет снизить затраты времени на разработку.
каким образом?

Польза HIL когда нужно обсчитать большой вектор, каждый фрагмент которого требует большое количество параллельных вычислений. К примеру, у вас есть модель некого устройства(презентации Mathworks кажется был фильтр Sobel), и вам нужно проверить насколько ваш HW дизайн соответствует модели. для этого их запускают параллельно вместе. модель считают на Host'е, а HW-реализацию, через предварительно сформированный интерфейс загрузки - на target плате. На вход подают одинаковые данные и сверяют результат. это все хорошо для верификации. Можно мгновенно получить набор данных, который вызывает в HW реализации проблемы и уже этим набором воспроизводить проблему в HW симуляции.
Кроме того некоторые вычисления явно быстрее будут работать в HW, даже на пониженной частоте, чем CPU host'а, это больше относится к физическим расчетом, DSP.

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

недавно видел ролик, про автоматизированный BMW ('самоходный'), в котором штурман водителя сидит в матлабе, и явно у него там HIL....

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

Но для чего именно в реальном времени? Неужели нельзя просто смоделировать сигнал и затем подать этот сигнал на железку наблюдая реакцию.

в свое время что-то подобное делал... с поделками от NI

например, может возникнуть ситуация, когда доступа к ОУ нет или с ним просто нельзя тестировать (как раз для энергетики это и актульано), а работу УУ протестировать так как оно работает в железе. Тогда делается модель ОУ и к ней подключается созданное устройство.

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

Электроэнергетике HIL давно стало стандартом при разработке и исполнении любых проэктов.
При этом Hardware - это система управления, а Loop - это специальный симулятор электрических сетей. Обычно это RTDS, Opal-RT или Dspace на худой конец.
Смысл в том, что в конечном счете все разработанные алгоритмы должны проверяться в реальном времени на реальном железе.
Но в энергетике часто реальное железо - это установки типа SVC, STATCOM и другие
http://en.wikipedia.org/wiki/Static_VAR_compensator
http://www.ruselt-spb.ru/index.php?option=...view&id=986

мощностью от 50МВа до гигаВА и выше.
Вопрос в том, как, например, проверить реакцию системы управления на короткое замыкание на линии передач напряжением этак 100кВ? Чтоб понимать - такие вещи в реальности - ЧП на уровне страны и целые города остаются без света.
В реальности - никак или слишком дорого. А с помощью HIL такие процессы можно промоделировать с достаточно высокой точностью в реальном времени с реальной системой управления без риска что-нибудь угробить.
Обычно любые энергетические компании не допускают подключения высоковольтного оборудования к сети без таких тестов.

Всё это понятно. Но так ли нужен "реалтайм"? Неуэели мы не знаем токов и процессов протекающих при тех или иных видах КЗ?
К примеру:
записали сигнал и прогнали в отложеном времени, посмотрев на реакцию системы и время этой реакции.
или реалтайм это просто круто и дань моде.

Сигнал мы не знаем, так как такой процесс можно только промоделировать, а не записать "с натуры". Проблема заключается в том, что система управления активно влияет на сам процесс КЗ. То есть без нее процесс будет один, а с ней - совсем другой.
Моделирование в реальном времени позволяет увидеть реакцию алгоритма с учетом почти всех задержек и неопределенностей - входов АЦП, выходов буфферов и т.д.

Очень прошу вас подробнее об этом рассказать. Что вы имеете ввиду?
Мне как молодому специалисту очень интересно.
Я имел опыт испытаний РЗиА но для этого использовался Ретом-51, который мог выдать сигнал нужной амплитуды и формы, но не в реальном времени, чего казалось что хватает.
P.S. Если честно многие специалисты до сих пор не понимают необходимость той же RTDS, говоря толкьо что RTDS - это брэнд и "хороший тон".

Для испытаний РЗиА вышеназваного Ретома или omicron вполне хватает - ведь задача реле - тихо сидеть и слушать сеть и в случае аварии как можно быстрее отключить поврежденный участок, без отслеживания реакции на такие отключения.
То есть тут интерактивностью и не пахнет.
В то же время SVC и STATCOM - интерактивные устройства. Возможно Вы неправильно поняли что я имел ввиду под влиянием на процесс КЗ. Объясняю.
СТАТКОМ - это в двух словах очень быстрый источник синусоидального тока. Он может генерировать емкостной или индуктивный ток до 1000А с частотй 50Гц. При этом ток СТАТКОМа практически не зависит от сетевого напряжения. Что значит быстрый - СТАТКОМ может поменять амплитуду и знак выходного тока (т.е. перейти от генерации индуктивного к генерации емкостного или наоборот) за 1-5мс. То есть меньше одного периода сетевого напряжения. Кстати строятся СТАТКОМы на базе 2-х, 3-х и многоуровневых инвертеров с IGBT транзисторами, которые работают там на частотах 1-2кГц.
Зачем это нужно? Как известно емкостным и индуктивным током можно регулировать напряжение сети. Поэтому задача статкома - путем генерации тока поддерживать сетевое напряжение в определенных пределах. При КЗ сетевое напряжение значительно падает. Причем падает до 0В оно только на пораженном участке. В других участках сети напряжение может упасть до 50% или 70% - в зависимости от удаления от точки КЗ.
РЗиА, насколько я помню, срабатывают в пределах 100-1000мс (включая собственно сам контактор). Вот до времени отключения КЗ и работает СТАТКОМ. При КЗ статком должен мгновенно увеличить выходной ток до максимально емкостного, чтобы повысить сетевое напряжение в веренном ему участке и избежать возможного отключения потребителей из-за схем защиты от пониженного напряжения. После отключения пораженного участка статком должен опять-же мгновенно вернуться в нормальный режим, чтобы не вызвать перенапряжения.
В европе ситуация усложняется из-за наличия т.н. распределенной генерации - ветряных и солнечных электростанций, которые тут в каждом городе. Такая генерация требует еще более быстрой реакции СТАТКОМа.
В итоге в результате испытаний на RTDS и отрабатываются реакции системы управления СТАТКОМа на такие вещи. Причем эти реакции включают как, собственно саму генерацию тока, так и отработку всех алгоритмов управления транзисторами, контроля напряжения звена постоянного тока и т.д. - а там во время работы такие чудеса творятся - что можно офигеть просто.

Спасибо огромное за исчерпывающие объяснения.
Но, я имел опыт общения с представителями производителя РЗиА в России и они заявляли, что применение RTDS позволяет моделировать энергообъект (подстанцию) в реальном времени и осуществлять в реальном масштабе имитацию событий на объекте (включение секционного выключателя и прочее).
Я всегда недоумевал: неужели нельзя иметь "запись всех событий"(опыт накоплен достаточно большой) и имитировать эти события в "отложеном времени" более простыми методами (посредством того-же Omicron).
С другой стороны некоторые опытные релейщики говорят о том что RTDS для РЗиА - это больше "брэнд"...

Конечно это возможно. Но возможно это то же самое, что из пушки по воробьям.

А думаю для РЗиА это так есть. Я не вижу здесь особой необходимости в RTDS.

Здесь вы пишете о PIL, а не о HIL
PIL - это ни разу не HIL.
Суть HIL - это как раз пошаговая разработка некоего устройства и тестирование каждого шага разработки в реальном времени. Это устройство вставлено в "упряжку", которая вращается на хосте под RTOS типа VxWORKS. К этому хосту присоединено по какому-нибудь интерфейсу (чаще всего Ethernet или RS485 или CAN) разрабатываемое устройство. На первом шаге в роли устройства может выступать некий мощный компьютер, управляющий сложными исполнительными механизмами. А на последнем шаге в роли устройства может выступрать некий простейший дешёвый микроконтроллер, управляющий этими же исполнительными механизмами. Между этими этапами много промежуточных шагов. Но каждый раз вы имеете ту или иную ступень разработки некоего работающего в реальном времени устройства, т.е как говорили в свое время коммунисты - вы идёте от "побелы к победе".