ЖУРНАЛ СТА 4/2014

При использовании протокола MODBUS номер функции и входные аргументы отображаются на один или несколько Holding -регистров удалённо- го сервера, а результат выполнения – на один или несколько Input -регистров. Помимо счётчика вызова, можно пере- давать между клиентом и сервером те- кущее состояние вызова, если предпо- лагается имитировать объекты команд DNP3, подобные AOB или CROB. Сле- дует отметить, что описанная идея при- менима к любым сетевым промышлен- ным протоколам, поддерживающим циклический обмен данными по сети. Ещё один вопрос, который время от времени возникает у пользователей контроллеров FASTWEL I/O с под- держкой протокола MODBUS: как пе- редать в контроллер CPM712 или CPM713 от SCADA-системы значения уставок и других параметров алгоритма, которые в контроллере хранятся в энер- гонезависимых переменных, деклари- рованных в секции VAR_GLOBAL RETAIN или VAR RETAIN? Данный вопрос связан с тем, что на Holding -регистры сервера MODBUS контроллеров FASTWEL I/O могут быть отображены только переменные во входной части образа процесса, имеющие спецификаторы адреса %I* и недоступные для записи из кода прило- жения. Энергонезависимые переменные (да- лее RETAIN -переменные) контролле- ров CPM71x в общем случае имеют три источника значений. Первым источни- ком является область декларации пере- менных, в которой пользователь задаёт начальные значения переменных, как показано на рис. 8 . Если начальные значения для пере- менных не заданы, им присваиваются исходные нулевые значения: 0 для чи- словых типов, FALSE – для типа BOOL , T#0ms – для типа TIME и т.д. Началь- ные значения используются при первом запуске загруженного приложения. Вторым источником является энерго- независимая память, из которой при за- пуске контроллера считываются значе- ния RETAIN -переменных, если до этого запуска они были сохранены в ней хотя бы один раз. Это связано с тем, что при включении питания контроллера перед запуском приложения нужно убедить- ся, что значения RETAIN -переменных не были повреждены, пока у контрол- лера было выключено питание. Третьим источником значений RE- TAIN -переменных является код прило- жения во время исполнения, и при этом формировать значения энергонезави- симых переменных могут прикладные алгоритмы, выполняющиеся под управ- лением разных циклических задач. Если RETAIN -переменные сделать доступными через Holding -регистры, то поведение системы может стать слабо предсказуемым, поскольку одновре- менно с задачами приложения RETAIN - переменные могут быть изменены по сети, а в случае MODBUS TCP сделать это могут одновременно несколько раз- ных клиентов MODBUS TCP. В случае если все или часть RETAIN - переменных являются уставками и должны задаваться только по сети, то проблема становится менее острой, осо- бенно в случае если известно, что запи- сывать новые значения может только один MODBUS-клиент. Но при этом остаётся вопрос проверки корректности значений уставок, поступивших по сети. 1. А правильные ли по смыслу значения записаны? 2. А правилен ли момент записи, и нет ли каких-либо внутренних для при- ложения условий, ограничивающих запись именно сейчас? 3. А имел ли право этот сетевой клиент менять значения? Для сетиMODBUS на все три вопроса ответ можно дать только способом, спе- цифическим для приложения, причём только в коде самого приложения. Но сделать это нужно до того, как получен- ные значения попали в энергонезависи- мую память. Поэтому даже если часть RETAIN -переменных всегда является уставками, значения которых могут быть изменены только по сети, делать любые RETAIN -переменные доступными через Holding -регистры в многозадачной/мно- гоклиентской системе исполнения край- не опасно, так как некоторые логические ошибки не смогут быть обнаружены да- же при длительной отладке и продумы- вании. Проблема в том, что при исполь- зовании протокола MODBUS и MOD- BUS TCP неизвестно, в каких регистрах передаются уставки, а в каких данные реального времени, то есть уставка яв- ляется прикладным понятием, выходя- щим за рамки модели данныхMODBUS. В то же время система исполнения конт- роллера не может самостоятельно опре- делить, какие RETAIN -переменные яв- ляются уставками, а какие архивными данными, формируемыми самим алго- ритмом, и, наконец, какой источник данных является доминирующим для тех или иных RETAIN -переменных: сетевые клиенты или сам алгоритм. При разра- ботке максимально безопасной системы исполнения контроллера на этот счёт не могут делаться какие-либо неявные предположения, которые невозможно формально проверить при создании или исполнении пользовательского прило- жения. И, вообще говоря, сказанное можно отнести не только к RETAIN -пе- ременным, но и к любым глобальным переменным с произвольным доступом по чтению и записи. В контроллерах других производите- лей с однозадачной системой исполне- ния, в которой сетевой ввод-вывод все- гда отделён от исполнения пользователь- ского кода по времени, вопрос синхро- низации множества источников значе- ний переменных с исполняемым кодом алгоритма решается автоматически, но за это приходится платить тем, что период цикла пользовательского алгоритма и время реакции на сетевые запросы не- возможно предсказать заранее. Кроме того, при этом высока вероятность по- 82 СТА 4/2014 АППА РАТ НЫЕ С Р Е ДС Т В А / П РОМЫШЛ Е ННЫЕ КОН Т РОЛЛ Е РЫ www.cta.ru Рис. 7. Тайм-аут ответа подчинённого узла в конфигурации клиента MODBUS CPM712 Рис. 8. Декларация RETAIN -переменных с начальными значениями