ЖУРНАЛ «СТА» №1/2008

уровне низовых контроллеров значи- тельно упрощает интеграцию уровней. Схема программной организации виртуального ПЛК в DACHS приведе- на на рис. 2. В данный пример включе- ны, кроме собственно виртуальной ма- шины МЭК 611313, два сервера сете- вого взаимодействия (они предостав- ляют процессам сетевые сервисы) и два соответствующих драйвера сети, а так- же три модуля расширения на основе интерпретатора Python: подсистема протоколов высокого уровня, графиче- ская подсистема и подсистема БД. Все компоненты общаются друг с другом посредством программной шины QNX IPC — механизма межзадачного взаи- модействия QNX на основе обмена со- общениями. Для этого в те из них, ко- торые изначально не поддерживали этот механизм, добавлен модуль QNX IPC — для виртуальной машины МЭК 611313 это означало расширение ее собственного программного кода, для интерпретатора же Python этот модуль подключается как внешняя библиотека классов. Казалось бы, без внесения из- менений в код виртуальной машины обойтись всетаки не удалось, а значит, где обещанный выигрыш по надежнос- ти? Выигрыш по надежности здесь со- стоит в том, что модуль IPC — единст- венное изменение, внесенное в код виртуальной машины. Механизм об- мена сообщениями универсален, а зна- чит, будучи однажды реализован, он обеспечивает поддерживающим его за- дачам доступ сразу ко всем имеющим- ся сервисам. В случае же «классическо- го» варианта пришлось бы всякий раз дописывать код виртуальной машины с добавлением каждого нового модуля расширения. Работают модули расширения пре- дельно просто. Запрашивая определен- ный сервис, задача МЭК 611313 фак- тически через встроенный в виртуаль- ную машину модуль IPC вызывает со- ответствующий сценарий Python, ко- П Р О Г РАММНО Е ОБ Е С П Е Ч Е НИ Е / РАС П Р Е Д Е Л Е ННЫ Е СИС Т ЕМЫ У П РА В Л Е НИ Я 56 Рис. 2. Программная реализация расширенного виртуального ПЛК в DACHS® www.cta.ru СТА 4/2001 #361