После проведённых изысканий, был сделан вывод, что для хранения мгновенных значений применение дисковой субд не оправдано вследствие низкого быстродействия и




Скачать 101.04 Kb.
НазваниеПосле проведённых изысканий, был сделан вывод, что для хранения мгновенных значений применение дисковой субд не оправдано вследствие низкого быстродействия и
Дата публикации15.06.2013
Размер101.04 Kb.
ТипДокументы
vbibl.ru > Информатика > Документы
Базы даных.
После проведённых изысканий, был сделан вывод, что для хранения мгновенных значений применение дисковой СУБД не оправдано вследствие низкого быстродействия и даже применение резидентной БД eXtremeDB не обеспечивает необходимого быстродействия. Поэтому, для хранения оперативных данных будут применяться сегменты разделяемой памяти. СУБД будут применяться для хранения архивных данных и конфигурации системы (причём архив и конфигурация будут храниться в разных базах). Архивную базу данных настоятельно рекомендуется хранить на отдельном компьютере.

Аппаратная конфигурация.
В результате получается следующая архитектура – для связи с контроллерами и хранения мгновенных данных выделяется отдельный сервер. Для визуализации нужен отдельный компьютер, так как задачи отрисовки в системе X-Window достаточно ресурсоёмкие. Кроме того, отдельный компьютер необходимо выделить под сервер архивной базы данных. В случае, если для ПО верхнего уровня будет выделен всего один компьютер, все задачи можно будет выполнять и на нём – для этого не понадобится изменения ПО - локальное сокетное соединение устанавливается точно так же, как и сетевое. Но в случае запуска клиентской и серверной частей ПО верхнего уровня на одном компьютере, возможно, система не будет обеспечивать требуемого уровня быстродействия.
Структура ПО.
ПО верхнего уровня разделяется по выполняемым им функциям на серверную и клиентскую части. В список задач, решаемых серверной частью ПО входят :
Опрос технологических параметров

Передача команд

Сохранение мгновенных значений

Передача мгновенных значений клиентской части ПО

Передача команд от клиентской части ПО
Задачи, выполняемые клиентской частью ПО :
Визуализация техпроцесса

Архивация данных

Настройка системы как в момент развёртывания, так и в процессе работы
Взаимодействие программ серверной и клиентской частей системы.
Система должна обеспечивать высокое быстродействие при сборе данных. Основная нагрузка для обеспечения требуемого быстродействия ложится на серверную составляющую ПО, так как именно она должна работать в режиме "реального времени". С учётом этого, функции, выполняемые серверной частью ПО должны быть максимально простыми - вся "логика" должна быть перенесена на клиент. Сервер в данном случае будет выполнять роль своебразного неискажающего передачтчика между сетью контроллеров и ПО верхнего уровня, реализующего задачи контроля, управления (если в этом есть необходимость), визуализации технологического процесса, архивации данных и т.п. Связь серверного и клиентского ПО происходит по сети Ethernet.

Протокол - двоичный. Есть следующие команды (определены в файле connector.h):
CONN_CLOSE - закрыть текущее соединение (отладочная команда). Отправляется только команда без дополнительных параметров.
GIVE_ONE - запросить содержимое одной ячейки буфера чтения. Структура команды следующая:

Номер команды

Индекс запрашиваемой ячейки

1 байт

4 байта


Формат ответа:

Служебные данные

Номер техобраза

Данные

16

4

фиксированная длина



GIVE_SOME - запросить содержимое нескольких ячеек буфера чтения. Структура команды:

Номер команды

Количество ячеек

Индекс ячейки 1

Индекс ячейки 2

...

Индекс ячейки N

1 байт

4 байта

4 байта

4 байта

...

4 байта


Формат ответа:


Служебные данные

Номер техобраза1

Данные1


...

Номер техобразаN

ДанныеN

16 байт

4

фиксированная длина


...

4

фиксированная длина


GIVE_STRUCT - запросить содержимое нескольких ячеек буфера чтения. Структура команды:

Номер команды

Количество ячеек

Индекс ячейки 1

Индекс ячейки 2

...

Индекс ячейки N

1 байт

4 байта

4 байта

4 байта

...

4 байта


Формат ответа:


Служебные данные

структура 1

структура 2


...

структура N

16 байт

16 байт

16 байт


...

16 байт


структура определена в файле connector.h и имеет вид:
strcut _complex {

float p_real;

float p_imag;

};
union dataItem {

char ch;

unsigned char uch;
short sh;

unsigned short ush;

float fl;

_complex cplx

};
struct serverItem {

int id;

unsigned char error;

dataItem data;

};
GIVE_ALL - запросить всё содержимое буфера чтения. Отправляется только команда без дополнительных параметров.
Формат ответа аналогичен ответу на предыдущую команду.
PUT_ONE - поместить одну команду в буфер команд


Номер команды

Длина набора данных

Набор данных

1 байт

1 байт

...


В случае успешного выполнения команды, сервер возвращает строку "ОК"
PUT_SOME - поместить несколько команд в буфер команд


Номер команды

Количество наборов данных

Длина набора данных 1

Набор данных 1

...

Длина набора данных N

Набор данных N

1 байт

4 байта

1 байт




...

1 байт





В случае успешного выполнения команды, сервер возвращает строку "ОК"
STOP_APP - остановить сервер (отладочная команда). Отправляется только команда без дополнительных параметров.
Список только предварительный. Возможно, будут добавлены дополнительные команды.
Вся работа серверной стороны сводится к опросу контроллеров, передаче контроллерам команд, сохранению полученной информации в буфере чтения и выдаче необходимой информации клиентским программам. Буфер чтения представляет собой линейный массив в разделяемой памяти. Все параметры системы, будь то технологические параметры, настройки каналов или уставки воспринимаются сервером как "техобразы", у каждого из которых есть порядковый номер, который и является его индексом в буфере чтения. Кроме буфера чтения существует также буфер команд - для хранения очереди команд. Буфер команд представляет собой кольцевой буфер с перезаписью (т.е. в случае переполнения буфера, старые команды перезаписываются новыми). Результат выполнения команды ложится в ячейку буфера чтения, соответствующую "техобразу", к которому относится команда. После передачи команды контроллеру, команда удаляется из буфера. Буфер команд предназначен для передачи "разовых" команд. "Постоянные" (т. е. периодически отсылаемые) команды хранятся в локальной памяти процессов в массиве структур "информация о техобразе". Этот массив заполняется при запуске процесса из конфигурационной базы данных. В данной структуре хранятся следующие данные :
Индекс техобраза

Косвенный адрес

Прямой адрес

Канал

Регистр

Команда

Данные

Период опроса
Структура "разовой" команды повторяет "информацию о техобразе" за исключением поля "период опроса". Структура пакета "разовая команда" :


Индекс техобраза

Флаг

Косвенный адрес

Прямой адрес

Канал

Регистр

Команда

Данные

CRC

4 байта

1 байт

9 байт

1 байт

1 байт

1 байт

1 байт

...

1 байта


Лучше всего складывать в буфер команд готовые к отсылке пакеты с расчитанной CRC. Подсчёт CRC и формирование пакета нужно проводить на верхнем уровне.
Эти данные позволяют однозначно определить "нахождение" нужного "техобраза" в сети контроллеров. Все "техобразы", информация о которых хранится в массиве структур, опрашиваются постоянно с определённым периодом. Сервер не различает команды по типам - он передаёт команды контроллерам и помещает ответы в соответствующие ячейки буфера чтения. На сервере не производится никаких преобразований полученных данных (например, приведения к некоторым единицам измерения). При записи "разовой" команды в буфер команд, к ней добавляется поле "длина комманды".
Структура Буфера Чтения.
На каждый технический образ в буфере чтения выделяется определенное количество байт, которое определено в файле конфигурации (param_length). После приема данных с контроллеров, модуль связи с контроллерами записывает необходимую информацию в буфер чтения: длинна пакета, ошибка, данные.

Длинна пакета

Ошибка

Данные

Неиспользуемое пространство

2 байта

1 байт

... байт

...

\___________________________param_length__________________________/

Примечание: для того чтобы узнать правильную длинну пакета нужно преобразовать первые два байта в целочисленный тип и отнять 2, так как в длинну пакета не входит контрольная сумма.

На сервере выполняется три процесса:
Модуль слежения за системой (watcher) – запускает остальные модули и следит за их выполнением. В случае нештатного завершения работы каким-либо из модулей, перезапускает его. В текущий момент добавлен также модуль слежения за модулем слежения (scan)
Модуль связи с контроллерами – обеспечивает опрос контроллеров и сохранение мгновенных значений в буфере чтения (реализованым в виде сегмента разделяемой памяти). Кроме того, этот модуль обеспечивает передачу контроллерам команд от верхнего уровня системы. Команды помещаются в буфер команд (сегмент разделяемой памяти) модулем связи с верхним уровнем кроме того, по предложению Вадима, предполагается посылка сигнала (SIGUSR1 или SIGUSR2) от модуля связи с верхним уровнем по факту помещения команды в буфер команд (от сигналов отказались - бессмысленный расход ресурсов). После пересылки команды и получения ответа, команда из буфера удаляется (т.е. команда выполняется один раз) независимо от того, что вернула команда. Решения по поводу повторной посылки команды принимаются на уровне клиента. Результат выполнения команды помещается в буфер чтения (поскольку ответа на команду не предполагается, то в буфер ничего не помещается). Для синхронизации обращения к буферам предполагается использовать семафоры (они уже используются). PID модуля хранится в файле /tmp/ он записываеися туда при старте модуля (в текущий момент в этом нет необходимости - PID модуля вычитывается из виртуальной файловой системы /proc).
Модуль связи с верхним уровнем – обеспечивает передачу "мгновенных" данных из буфера чтения клиентским приложениям и передачу команд от клиентских приложений контроллерам (через буфер команд). Связь этого модуля с верхним уровнем происходит через сокет по протоколу TCP/IP. Это позволит унифицировать способ обращения к данным и в то же время обеспечит их целостность, потому что только один процесс будет выбирать данные из буфера чтения, а все остальные компоненты системы будут получать данные от этого модуля через сокеты. Этот модуль может только читать данные из буфера чтения. PID модуля хранится в файле /tmp/ он записываеися туда при старте модуля (в текущий момент в этом нет необходимости - PID модуля вычитывается из виртуальной файловой системы /proc).
Предполагается, что на стороне клиента будут выполняться следующие модули (список не окончательный):
Модуль обработки - на основании полученных мгновенных данных производит расчёты.
Модуль визуализаци – обеспечивает отображение техпроцесса в виде пиктограмм, графиков, трендов и т.д. Связь с нижним уровнем – по сети Ethernet. Модуль работает в момент эксплуатации системы. Через него предполагается отправка дополнительных комманд контроллерам.

Модуль архивирования – обеспечивает протоколирование работы системы. Можно реализовать несколько модулей архивирования – в зависимости от того, в каком виде будут сохраняться данные (файл, база данных) и, в случае хранения архивной информации, какая СУБД будет использоваться для хранения архивных данных. Данные для сохранения модуль архивирования получает от модуля связи с верхним уровнем через сокет. В данный момент предполагается, что модуль архивации будет выполняться на отдельном компьютере.
Модуль составления и просмотра отчётов - на основе шаблонов отчётов и данных из конфигурационной и архивной баз данных строит отчёты о работе системы в формате HTML.
Модуль настройки сети – предназначен для создания иерархии коммутационных контроллеров. Применяется на этапе развёртывания системы или в случае её реконфигурации.
Модуль построения визуальных схем – предназначен для создания шаблонов технологических схем, которые в процессе работы системы “оживляет” модуль визуализации. Применяется на этапе развёртывания системы или в случае реконфигурации.
Модуль создания шаблонов устройств – предназначен для создания шаболнов устройств, из которых потом строятся визуальные схемы.

Список модулей может быть изменён или дополнен. Данная версия является предварительной.

Добавить документ в свой блог или на сайт

Похожие:

После проведённых изысканий, был сделан вывод, что для хранения мгновенных значений применение дисковой субд не оправдано вследствие низкого быстродействия и iconЧто такое jdbc?
Субд. В реальности оказывается, что некоторые объектные субд и иногда даже совсем не субд предоставляют jdbc интерфейс для работы...

После проведённых изысканий, был сделан вывод, что для хранения мгновенных значений применение дисковой субд не оправдано вследствие низкого быстродействия и iconРекомендации по установке субд версия 4 8
Данный документ предназначен для администраторов системы. В нём содержаться рекомендации по установке и настройке субд необходимые...

После проведённых изысканий, был сделан вывод, что для хранения мгновенных значений применение дисковой субд не оправдано вследствие низкого быстродействия и iconЭто совокупность связанных данных, организованных по определенным...
Обращение к базам данных осуществляется с помощью системы управления базами данных (субд). Субд обеспечивает поддержку создания баз...

После проведённых изысканий, был сделан вывод, что для хранения мгновенных значений применение дисковой субд не оправдано вследствие низкого быстродействия и iconВопросы для самопроверки
Выводы, сделанные после проведенных исследований, заключаются в том, что за последние годы наблюдается резкая активизация использования...

После проведённых изысканий, был сделан вывод, что для хранения мгновенных значений применение дисковой субд не оправдано вследствие низкого быстродействия и icon7. Транзакционное управление в субд. Методы сериализации транзакций
Сотрудники и отделы в одну транзакцию. Таким образом, поддержание механизма транзакций является обязательным условием даже однопользовательских...

После проведённых изысканий, был сделан вывод, что для хранения мгновенных значений применение дисковой субд не оправдано вследствие низкого быстродействия и iconПрограмма тура «Галантный Петербург» : 1 день субб. Встреча с гидом...
...

После проведённых изысканий, был сделан вывод, что для хранения мгновенных значений применение дисковой субд не оправдано вследствие низкого быстродействия и iconПрограмма тура «Морские ворота Российской империи» : 1 день Встреча...
Встреча с гидом на вокзале у вагона поезда. (Расчет сделан для группы, приезжающей после 00, при более раннем приезде – требуется...

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

После проведённых изысканий, был сделан вывод, что для хранения мгновенных значений применение дисковой субд не оправдано вследствие низкого быстродействия и iconРазработка информационного программного обеспечения для автоматизации...
Обоснование выбора субд и средств разработки прикладного программного обеспечения. 5

После проведённых изысканий, был сделан вывод, что для хранения мгновенных значений применение дисковой субд не оправдано вследствие низкого быстродействия и iconКоллегия адвокатов города Москвы
«Бизяя». Обвиняемый в организации убийства Константин Прокошев был полностью оправдан судом присяжных после 1,5 лет, проведенных...

Вы можете разместить ссылку на наш сайт:
Школьные материалы


При копировании материала укажите ссылку © 2013
контакты
vbibl.ru
Главная страница