[Devel] [АСУ]

[Evgeny Sinelnikov]

30 сентября 2010 г. 16:24 пользователь Vadim Makarov
<vadmak на etersoft.ru> написал:
> Я так понимаю, проект 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,
> изменить способ "парсинга" не должно составить большого труда. Например,
> "спускаясь вниз" кешировать встреченные параметры.
> Таким образом, "парсер" для такой структуры должен работать и в случае
> текущего стиля конф.файла.
>
> Надеюсь, смог доходчиво изложить свою мысль.
> Объективная критика приветствуется. :)

Думаю, что это здравая идея. Причём реализовать её можно небольшой
кровью. Самое трудоёмкое, по времени, здесь продумать. Иерархию,
которая бы была удовлетворительна.

Я вижу, что кроме глобального списка <sensors/> можно дать возможность
обрабатывать те же объекты <item/> в другой части, например:
<group>
 <item>
  <sensors> <-- Обычная секция sensors, но своя для каждой группы
   <item>
   </item>
  </sensors>
 </item>
</group>

Детально продумать этот вопрос - это время. А времени на это, увы,
нет. Ни для стенда, ни для Яузы.

Виталик, кстати, давно предлагает сделать загрузку нескольких файлов.
Для этого нужно посмотреть как делается объединение двух корневых
узлов DOM-дерева в libxml2 и добавить возможность последовательной
загрузки нескольких файлов в код uniset, отвечающий за загрузку
configure.xml.

Возможность такой загруки настроек из нескольких файлов позволит:
- разбить настройки на группы по файлам;
- более корректно организовать разные настройки для разных
контроллеров при финальной сборке проекта. Сейчас у нас sed
используется.

В общем, добавить загрузку настроек из несколькоих файлов более полезно сейчас.

-- 
Sin (Sinelnikov Evgeny)