[Devel] [АСУ]

Vadim Makarov vadmak на office.etersoft.ru
Чт Сен 30 16:24:28 MSD 2010


Я так понимаю, проект standpm - явно не последний с настройками в
конф.файле xml-вида.

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

......
<!-- Индикаторы для ПЧ1 -->
        <item id="10000" group_pc1="1" name="PC1_U_AS" pc1_alarm="1"
rss_a1_alarm="1"
              textname="ПЧ1: Напряжение" iotype="AI" tcp_mbtype="mtr"
mtrtype="T5" tcp_mbaddr="0x01" tcp_mbfunc="0x04" tcp_mbreg="0x4A"
mbtcp="VRS_Gateway" group_mtr_pc1="1"/>

        <item id="10001" group_pc1="1" name="PC1_P_AS" pc1_alarm="1"
rss_a1_alarm="1"
              textname="ПЧ1: Мощность" iotype="AI" tcp_mbtype="mtr"
mtrtype="T6" tcp_mbaddr="0x01" tcp_mbfunc="0x04" tcp_mbreg="0x5A"
mbtcp="VRS_Gateway" group_mtr_pc1="1"/>

        <item id="10002" group_pc1="1" name="PC1_I_AS" pc1_alarm="1"
rss_a1_alarm="1"
              textname="ПЧ1: Сила тока" iotype="AI" tcp_mbtype="mtr"
mtrtype="T5" tcp_mbaddr="0x01" tcp_mbfunc="0x04" tcp_mbreg="0x4C"
mbtcp="VRS_Gateway" group_mtr_pc1="1"/>
	.... и т.д.
<!-- ПЧ1 -->
        <item id="2000" group_pc1="1" name="PC1_R_AS" pc1_alarm="1"
rss_a1_alarm="1" mbtcp="VRS_MasterController"
	      textname="ПЧ1: реальная частота" iotype="AI" tcp_mbtype="rtu"
tcp_mbaddr="0x01" tcp_mbfunc="0x04" tcp_mbreg="0x01" group_ctrl_vrs="1"/>

        <item id="2001" group_pc1="1" name="PC1_S_AS" pc1_alarm="1"
rss_a1_alarm="1" mbtcp="VRS_MasterController"
	      textname="ПЧ1: заданная частота" iotype="AI" tcp_mbtype="rtu"
tcp_mbaddr="0x01" tcp_mbfunc="0x04" tcp_mbreg="0x02" atype="2"
group_ctrl_vrs="1">
.......
<ObjectsGroups>
	<!-- *********** Группы датчиков (логические объекты) ************ -->
	<groups name="groups" section="Groups">
		<item name="PC1"    textname="ПЧ1"     type="PC"       
subsystem="Generating"   filter="group_pc1"/>
		.....
		<item name="MTR_PC1"    textname="МТР: ПЧ1"       
subsystem="Generating"   filter="group_mtr_pc1"/>
		.....
		<item name="Ctrl_VRS" textname="Контроллер: ВРЩ" subsystem="Generating"
filter="group_ctrl_vrs"/>
		.....
	</groups>
</ObjectGroups>

Как видно, сведения о датчиках содержат уйму дублирующей друг друга
информации, которую довольно муторно редактировать и задавать.
Собственно, идея в том, чтобы вынести общие и для всех датчиков параметры
в группы (подчеркиваю, именно группы), чтобы можно было с этими группами
взаимодействовать, как с классами в С++: наследовать данные от
группы-"предка" и "перегружать" их по необходимости.
Мы же не "набиваем" схожие по функциональности классы одинаковыми методами
с одинаковой реализацией, а пользуемся наследованием.

Вот в данном случае мы имеет такую ситуацию: Имеется несколько датчиков,
входящих в группу ПЧ1, которая подразделяется на группы датчиков, значения
которых снимаются с МТР, и датчиков, значения которых снимаются с
контроллера.
Так почему бы, например, создать иерархию примерно следующего вида: группа
"ПЧ1" задает параметры, такие как iotype, tcp_mbfunc и ссылки на другие
группы, и содержит в себе группы "МТР" и "Контроллер" (упрощенно), которые
задают собственно tcp_mbaddr, tcp_mbtype, mbtcp и другие. А уже датчики,
находящиеся в этих группах содержат свои уникальные параметры. Само собой,
они могут содержать в себе и "перегруженные" значения "отнаследованных"
параметров.

Как я понял во время исследования классов UniXML и UniXML_iterator,
изменить способ "парсинга" не должно составить большого труда. Например,
"спускаясь вниз" кешировать встреченные параметры.
Таким образом, "парсер" для такой структуры должен работать и в случае
текущего стиля конф.файла.

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


Подробная информация о списке рассылки Devel