CC BY
54
среднее время контроля знаний, среднее время повторения учебного материала или восстановления знаний. Критерии оптималь-
ности: 1) максимум коэффициента профессиональной готовности обучаемого и 2) минимум средних удельных затрат.
Литература
1. Ушинский К. Д. Человек как предмет воспитания. Опыт педагогической антропологии. - М.: Учпедгиз, 1950.
2. Талызина Н. Ф. Управление процессом усвоения знаний (психологические основы). 2-е изд. - М.: МГУ, 1984. 344 с.
3. Свиридов А. П. Ведение в статистическую теорию обучения и контроля знаний. Ч. 2. Элементы статистической динамики знаний. - М.: МЭИ, 1974. 152 с.
4. Свиридов А. П. Основы статистической теории обучения и контроля знаний. - М.: Высшая школа, 1981. 262 с.
5. Süsse R., SviridovA. P. Statistische Kenntnis-Dynamik. - Ilmenau: Wissenschaftsverlag, 1998. 256 s.
6. Свиридов А. П. Статистическая теория обучения. - М.: РГСУ, 2009. 577 с.
ЭРНО-2012. С 16-19 сентября 2012 г. Педагогический институт Южного федерального университета совместно с Министерством образования и науки России, Академией информатизации образования, Институтом информатизации образования РАО проводит в г.Анапа Краснодарского края Международный научно-методический симпозиум "ЭЛЕКТРОННЫЕ РЕСУРСЫ В НЕПРЕРЫВНОМ ОБРАЗОВАНИИ", "ЭРНО-2012".
Подробности на сайте www.erno-simp.ru
УДК 004.415.2
ЭКОНОМИЧНЫЕ ПРОГРАММНЫЕ СРЕДСТВА ДЛЯ ОБУЧЕНИЯ РАЗРАБОТКЕ РАСПРЕДЕЛЕННЫХ ПРИЛОЖЕНИЙ ПРОМЫШЛЕННЫХ СЕТЕЙ LonWorks
В. Г. Гончаровский, к. т. н., доцент кафедры «Автоматика и телемеханика», Тел.: (342) 239-18-16, e-mail: [email protected] E. Л. Кон, к. т. н., профессор кафедры «Автоматика и телемеханика», руководитель сектора «Инфокоммуникационные и информационно-управляющие сети»,
Тел.: (342) 239-18-16, e-mail: [email protected] Пермский национальный исследовательский политехнический университет
www.http://pstu.ru
Educational Neuron C SDK is proposed. It provides the efficient training of application development and analyzing different approaches to the design and modeling of LonWorks networks. The example of designing centralized and decentralized LonWorks systems application is examined.
Предлагаются учебные программные средства, позволяющие эффективно обучать разработке приложений на языке Neuron C, анализировать различные подходы к проектированию и моделированию сетей LonWorks. Рассмотрен пример проектирования распределенного приложения как централизованной, так и децентрализованной системы.
Ключевые слова: распределенная система, LON, Neuron C, централизованная и децентрализованная система.
Keywords: distributed system, LON, Neuron C, centralized system, decentralized system.
1. LON-технология. Постановка задачи
Различные технологии Fieldbus-систем широко применяются для автоматизации технологических процессов, и в частности объектов критической инфраструктуры, автоматизации на транспорте и грузоперевозках, а также при автоматизации инженерных систем интеллектуального здания, таких как управление освещением, отоплением, вентиляцией, кондиционированием и других. Наиболее распространенной и универсальной полевой технологией для распределенных Fieldbus-систем является LON-технология, реализуемая на программно-аппаратной платформе LonWorks [1]. В основе LonWorks лежит децентрализованный принцип построения сети и опосредованный обмен информацией при помощи сетевых переменных, что облегчает программирование на
языке Neuron С, узаконенном в этой технологии.
Коммуникации выполняются через FAN (Field Area Network) или LON (Local Operating Network) сети. Их поддержка реализуется на аппаратном уровне специализированной микросхемой Neuron Chip (NC), содержащей три процессорных узла.
В LonWorks используется модифицированный произвольный доступ с контролем несущей и предотвращением коллизий (CSMA/АБ), преимущество которого заключается в том, что при малой нагрузке на шину время доступа к ней стремится к нулю и это достигается следующими мерами.
Отказ от опроса - датчик посылает данные «по событию», т. е. только тогда, когда измеряемая величина меняется (принцип
«send on delta» -посылать при изменении). Сообщения о событиях интеллектуальный датчик посылает, как только измеряемая им величина достигает заранее заданного значения. Сравнение заданного значения величины с текущим выполняется самим
датчиком циклически, с высокой частотой, без загрузки шины.
Установка максимальной частоты посылки сообщений, которую датчик не может превышать, исключает «наводнение» шины сообщениями при быстром изменении измеряемой величины.
Изоляция сегментов шины - локально используемые сообщения могут быть изолированы от остальной Fieldbus-системы посредством маршрутизатора.
Разработка распределенного интероперабельного приложения в LonWorks ведется на базе функциональных профилей LonMark. LonMark представляет пять основных прикладных объектов: датчик без обратной связи, датчик с обратной связью, исполнительный механизм без обратной связи, исполнительный механизм с обратной связью, управляющий объект. Следует отметить, что создание сетевых проектов требует использования дорогостоящего программного инструментария, в основе которого лежит программа LonMaker для установления связи между сетевыми переменными и настройки конфигурационных свойств NC и программа Node Builder для формирования приложения NC. Подобные коммерческие средства автоматизации проектирования LonWorks-систем в большинстве случаев недоступны для бюджетного учебного процесса из-за их высокой стоимости.
В то же время в процессе обучения студентов большой интерес представляет разработка распределенных приложений для случая, когда не удается реализовать проект на базе уже существующих функциональных профилей и требуется применение инструментальной среды для разработки программ на Neuron C. Таким образом, задача состоит в создании экономичных программных средств для моделирования и проектирования LonWorks-систем (SDK - Software Development Kit) и учебной методики разработки сетевых проектов, позволяющих обучать студентов проектированию приложений на языке Neuron C с меньшими затратами. В данной статье предлагается подход к решению поставленной задачи.
2. Программные средства для моделирования и проектирования LonWorks-систем
Предлагаемое учебное программное средство для моделирования и проектирования LonWorks-систем - это руководство пользователя, набор библиотек и открытых
исходных текстов-примеров для персональных компьютеров под Windows и аппаратных прототипов NC (в дальнейшем рКС) под FreeRTOS.
рNC базируется на OEM-модуле СгцшЬ128 для быстрой разработки приложений под микроконтроллер AVR Atmega-128 (аналог CPU3 Neuron Chip), сетевом OEM-модуле WIZ811MJ, поддерживающем 10/100 Base TX и стек TCP/IP и/или сетевом радиочастотном OEM-модуле Xbee Series 2, работающем по технологии ZigBee - недорогих маломощных беспроводных сетей датчиков (аналог CPU1 и CPU2 Neuron Chip). Таким образом, сеть - прототип LON (в дальнейшем р^^ реализуется на обычном Ethernet или ZigBee, а рNC может выполнять функции моста между LAN и WLAN.
Рассмотрим основные этапы и пример создания проекта распределенного приложения с помощью SDK для моделирования и проектирования LonWorks-систем.
Пусть задано описание объекта на неформальном языке. Необходимо распределить функции между физическими узлами сети. Функции датчиков, исполнительных механизмов и контроллеров могут выполняться как в различных узлах, так и в одном из них. Ограничения в основном накладываются ресурсами NC. Наиболее важными критериями полноценного распределения функций реального процесса по различным узлам являются географические факторы (расстояние) и универсальность узлов.
На следующем этапе совершается переход от неформального задания поведения объекта к формальному заданию в форме детерминированного конечного автомата. На третьем этапе необходимо реализовать автомат в виде программ на Neuron C для узлов NC, т. е. произвести декомпозицию распределенного приложения.
Предусмотрены следующие сценарии разработки ПО с помощью SDK. Первый предусматривает отладку распределенного приложения на одном компьютере. Приложение для каждого узла запускается на одном рабочем месте. Сетевой адрес у всех один - это локальный шлейф, а каждое приложение привязано к своему порту,
Второй сценарий предусматривает отладку распределенного приложения на нескольких компьютерах. Приложение для каждого узла запускается на своем рабочем месте. Каждое приложение может быть привязано к одному и тому же порту. Каждый компьютер моделирует NC.
Третий сценарий предусматривает отладку распределенного приложения с использованием устройств рNC, подключенных к локальной сети. В этом случае необходимо приспособить приложения для работы с FreeRTOS и выполнить их компиляцию под микроконтроллер AVR Atmega-128.
Концепция программирования распределенной системы, принятая в LonWorks, основана на языке Neuron C [2], базирующемся на ANSI C. ANSI C дополнен операторами сетевого взаимодействия, ввода-вывода и управлением по событиям.
Решение задачи по разработке библиотек для SDK основано на анализе синтаксиса и семантики элементов Neuron C для их определения и реализации на С.
Планирование прикладных задач в Neuron C является событийно-управляемым процессом, при котором если данное условие принимает значение TRU, то выполняется тело кода (задача), сопоставленное этому условию. Таким образом планировщик позволяет разработчику определять задачи, которые вызываются на выполнение при наступлении определенного события. Примерами подобных событий могут быть изменение состояния входного сигнала, получение нового значения сетевой переменной или истечение установленного времени таймера. События определяются через предложения when. Предложение when содержит выражение, которое, если принимает значение TRUE, вызывает для исполнения следующее за ним тело задачи. Предложение when и сопоставленную задачу называют when-задачей или оператором when. В предлагаемой SDK реализован аналог Neuron C (в дальнейшем aNeuron C) , являющийся моделью на С основных элементов Neuron C.
В качестве примера ниже приводятся выражения некоторых операторов и функций на языке aNeuron C.
отличному от других.
Oператор when моделируется в aNeuron C переименованием if.
#define when if.
Планировщик задач Neuron C в среде Windows (APIWIN32) моделируется процессом с функцией.
DWORD WINAPI NeuronChip(LPVOID lpParam){ IniAdc(); //инициализация портов р^шт Chip или программной модели
ConnectNetworkVariables(); //связывание сетевых переменных while(1){ Sleep(100);
io_in(); //отслеживает изменения входных переменных . . . when (событие_) { задача_i; . . . }
Nvwrite(); //отслеживает изменения выходных сетевых переменных и отправляет их через сеть
}
return 0;
}
Сделаны следующие определения:
#define aNEURON_C_ DWORD WINAPI NeuronChip(LPVOID lpParam) \
{ \
IniAdc(); \
ConnectNetworkVariables(); \ while(1){ \ Sleep(100); \ io_in();
#define _aNEURON_C NVwrite();\
} \
return 0; \
}
Окончательно программа на аNeuron C выглядит следующем образом:
aNEURON_C______________
when (событие_1)
{ задача_1; . . . } when (событие^ { задача_щ }
_aNEURONC
Большинство предопределенных событий Neuron C реализованы и в aNeuron C. Например, iochanges - это событие становится TRUE, когда величина, прочитанная из входного объекта, изменяет состояние. iochanges моделируется в aNeuron C функцией unsigned char io_changes(AdcChannalType *x), аргументом которой является указатель на объект ввода-вывода типа AdcChannalType:
typedef struct
{ UINT16 value; //текущее значение UINT16 old; //предыдущее значение
UCHAR event,//принимает значение 1, когда текущее значение отличается от //предыдущего
} AdcChannalType;
Большинство встроенных функций Neuron C также реализованы в aNeuron C. Например, void msgsend(void) - эта функция посылает сообщение, предварительно сформированное в объекте msgout. В aNeuron C msgout определяется следующим образом:
struct {
UCHAR priorityon; // TRUE, если приоритетное сообщение
UCHAR tag; // признак
UCHAR code; // код сообщения
UCHAR len; //длина сообщения
UCHAR data[MAXDATA]; //сообщение
UCHAR authenticated; // TRUE, если требуется аутентификация
UCHAR service; // тип сервиса
ULONG destaddr; // IP-адрес
CHAR Acknowledged; } msg out;
Функция aNeuron C void Nvwrite(void) отправляет их значения через сеть скрыта от пользователя. Она отслеживает соответствующим устройствам. изменения выходных сетевых переменных и
Проектирование сети в LonWorks базируется на том, что для каждого узла разработана прикладная программа. Остается только объединить множество узлов в общую систему. При проектировании с помощью соответствующего инструментария следует определить коммуникационные связи между узлами, и прежде всего их сетевыми переменными. Этот процесс называется связыванием. В сложных случаях с большим числом узлов необходим мощный инструментарий, для того чтобы постоянно иметь полную картину проекта.
Связывание в aNeuron C состоит в заполнении для каждого узла двух структур (определенных полей) - одна для выходных сетевых переменных, другая для входных сетевых переменных. В этих структурах данных указываются идентификаторы сетевых переменных, сетевые адреса их потребителей, а также сервис доставки.
3. Пример разработки распределенного приложения
Рассмотрим простой пример применения предлагаемой SDK и методики разработки распределенного приложения.
Пусть дан гипотетический объект. Его работа задана следующим образом. По команде «старт» включается исполнительный механизм А1. Датчик S1 сигнализирует о достижении измеряемой величиной значения v1, при этом выключается А1 и включается А3. Спустя время t1 А3 выключается и включается А2. Датчик S2 сигнализирует о достижении измеряемой величиной значения v2, выключается А2 и снова включается А3. Спустя время t1 А3 выключается и включается А4. Датчик S1 сигнализирует о достижении измеряемой величиной значения v3, выключается А4, и процесс останавливается до следующего старта. Ход процесса доступен для наблюдения через узел контроля С.
Технология LonWorks позволяет производить гибкое
распределение ?sl=v3,^Cfc=l/AA=0
функций между физическими узлами сети. Таким образом, функции датчиков, исполнительных механизмов и контроллеров могут выполняться как в различных узлах
кладываются ресурсами Neuron Chip. Наиболее важными критериями полноценного распределения функций реального процесса по различным узлам являются географические факторы (расстояние) и универсальность узлов.
Пусть в нашем примере определяющим является географический фактор, который не оставляет выбора, а именно. узел контроля С (старт процесса и индикация его состояния), узел исполнительного механизма А1, узел датчиков S1, S2 и исполнительного механизма A2, узел исполнительных механизмов A3, A4. Все исполнительные механизмы, используемые в объекте, имеют 2 состояния. Исходя из соображений минимизации числа узлов и связей, не будем обеспечивать каждый исполнительный механизм собственным узлом, а объединим A3 и A4 (пусть это можно сделать) в один. На рис. 1 представлена структурная схема распределенной системы управления гипотетическим объектом, где С - узел контроля, А1 - узел исполнительного механизма, S1_S2_A2 - узел датчиков и исполнительного механизма, A3_A4 - узел исполнительных механизмов.
С S2 А2
J 1 aLON
1 Г Г
AI A3 A4
Рис. 1. Структурная схема распределенной системы управления
Совершим переход от неформального задания поведения объекта к формальному заданию в форме автомата. На рис. 2 приведен его граф управления, где
START, A1_ON, A3_ON1, A2_ON, A3_ON2, A4_ON - состояния автомата;
Str, Clr - входные двоичные сигналы;
S1 и S2 - входные цифровые сигналы от датчиков S1 и S2;
T - входной сигнал от таймера;
A1, A2, A3 - двоичные выходные сигналы
1=0jU=1
?T=tl A3
так и в
одном из них. Ограничения в основном на-
Рис. 2. Граф управления гипотетическим распределенным объектом
включения/выключения соответствующих
исполнительных механизмов;
у1, у2, уЗ - значения измеряемых величин;
t1 - время срабатывания таймера; ?Str=0, ?Str=1, ?Clr=1, ?S1=v1, ?T1=t1, ?S1=v3 - условия перехода.
?S2=v2,
toHMKKtCMirofHtH'Lhubbtpii
ffri «'i Г rp_ pril
r- f«i5l d
: м-] ^ш^шг ilj^i'
JW
[I
T ?
Q
CH'F
Далее согласно рекомендуемому подходу необходимо реализовать автомат в виде программ на а№игоп С (распределенное приложение) для четырех рКС.
На рис. За приведена структурная схема информационных потоков централизо-ван-ного варианта реализации, где Уз1,У82 -значения сигналов датчиков, Са1, Са2, Са3, Са4 - сигналы управления для испол-ни-тельных механизмов. Блок контроля реализует рассмотренный выше граф управления. Алгоритм работы блока датчиков и исполнительного механизма сводится к преобразованию сигналов датчиков 81, 82 и отправке их значений в рЬОК, прием из
Уб1.У82 _
ных сигналов (нет сигналов управления, за исключением сигнала запуска процесса). Сигналы управления формируются в соответствующих блоках на основе сигналов от датчиков и текущего состояния управляющего автомата и являются локальными.
На рис. 4 приведен скриншот
«^r frj pr Г
"У1
1_
^JjjfAp
«i-P^t]
crJ ^1 1
rfculpre
Г
ili
Р
Г .
L -
_ njpnfc njanT
N_P
CKitHlJxb
ifiC
М-Lft.» L»J
ouljwrf
CUJf£ nJjpi?
J". I r-
SH
F R
П—rtrW? Ot»|
]ffi_
-pr
1Д|.',"„ИЛИЯД
rttfpra
Г «LjMr<0 ~ njMiI c l n_prO . .
.-...riJ^J
JSSwiiSJ-
"im" bp
••■•Jг-J |wi:
»jurfF"
ftJFJWl
"J« _
_
UL^jrf
-ICd >4
Г rjrli t~ I\_!ih1 ii
т[р1_ '"HCP
^ftAttfiJ*
С
SIR --
Рис. 3. Структурная модель информационных потоков централизованного (а) и децентрализованного (б) варианта
реализации
рЬОК сигнала управления Са2 для исполнительного механизма А2, а для остальных двух блоков - к приему соответствующих сигналов управления и их реализации.
На рис. 3б приведена структурная схема децентрализованного варианта реализации информационных потоков. В отличие от предыдущего варианта, все сигналы широковещательные. Блоки реализуют автоматы с графами управления, гомоморфными автомату, рассмотренному выше. Автоматы работают синхронно, т. е. во всех блоках в один и тот же момент времени автоматы находятся в одноименных состояниях, а переходы выполняются одновременно в одноименные состояния. В децентрализованной реализации задействовано меньше глобаль-
Литература
Рис. 4. Модель LonWorks-системы из примера SDK
программной модели LonWorks-системы из примера SDK.
4. Заключение
Одним из необходимых условий успешного обучения студентов знаниям и навыкам разработки распределенных приложений широко распространенной в мире технологии LonWorks-систем (как, впрочем, и других «полевых» технологий) является применение соответствующих программно-аппаратных средств разработки. Следует отметить, что не все вузы могут приобрести подобные коммерческие продукты. В этом случае целесообразно воспользоваться сравнительно недорогими разработками российских вузов,
функциональная спецификация которых содержит необходимые программные модули. Подобный программно-аппаратный продукт и методическое обеспечение для проектирования и моделирования LonWorks-систем разработан и рассмотрен авторами в
настоящей статье.
1. Дитрих Д., Лой Д., Швайнцер Г.-Ю. ЛОН-технология. Построение распределенных приложений / Пер. с нем. под ред. О. Б. Низамутдинова. - Пермь: Звезда, 1999. 424 с.
2. Neuron® C Programmer's Guide. Revision 7. Document No. 29300. www.echelon.com.
