Автоматизированная система управления метеорологических станций

Пример - В прогнозе по территории (10 станций) предусматривался западный ветер скоростью от 7 до 12 м/с, на побережье (3 станции) - от 15 до 20 м/с.

Фактически на побережье на 2 станциях отмечена скорость ветра от 16 до 18 м/с (прогноз оправдался), на 1 станции - 11 м/с (прогноз не оправдался). На остальных станциях скорость ветра была от 6 до 10 м/с (прогноз оправдался). Общая оправдываемость составила

Если максимальная скорость ветра по территории (части территории) прогнозировалась в градации, крайнее значение которой соответствовало установленному критерию ОЯ, или прогнозировалась в градации ОЯ (при этом было составлено и передано потребителям штормовое предупреждение), то прогноз считают оправдавшимся при условии, что фактическая максимальная скорость ветра достигла критерия ОЯ (с допуском 10 %) хотя бы на одной станции.

Если максимальная скорость ветра по территории (части территории) прогнозировалась в градации, крайнее значение которой соответствовало установленному критерию ОЯ, или прогнозировалась в градации ОЯ (при этом было составлено и передано потребителям штормовое предупреждение), но не наблюдалась ни на одной станции, то оценку прогноза производят по станциям.

Если на части территории максимальная скорость ветра прогнозировалась и наблюдалась (или не прогнозировалась, а фактически наблюдалась) в градациях ОЯ, расчет оправдываемости прогноза производят по формуле

                                                        (12)

где

= 100 %, если скорость ветра достигала критерия ОЯ на части территории;

= 0 %, если на части территории скорость ветра не достигала критерия ОЯ.

Оценка оправдываемости прогнозов погоды по пункту и территории

Оценку оправдываемости прогнозов погоды производят отдельно по пункту и территории.

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

                                                  (13)

где Pt - оправдываемость прогноза температуры;

Рос - оправдываемость прогноза осадков;

Pv - оправдываемость прогноза ветра (при скорости  12 м/с);

Рявл - оправдываемость прогноза атмосферных явлений.

При прогнозируемой и фактически наблюдаемой скорости ветра менее 12 м/с формула (13) приобретает вид

                                                       (14)

Расчет характеристик качества прогнозов погоды за месяц, квартал, год

Оценка качества прогнозов погоды по территории на сутки (вторые и третьи сутки) за календарный период (месяц, квартал, год) заключается в вычислении их средней оправдываемости за период Рпер по формуле

                                                             (15)

где m - число суток в месяце (квартале, году);

рc - оправдываемость прогноза погоды за каждые сутки (полусутки, вторые и третьи сутки) данного месяца (квартала, года).

По пункту, кроме средней оправдываемости прогнозов погоды, рассчитывают среднюю абсолютную ошибку прогноза температуры за период tпер по формуле

                                                            (16)

где tc - абсолютная ошибка прогноза максимальной (минимальной) температуры воздуха за каждые сутки (полусутки, вторые и третьи сутки) данного месяца (квартала, года).

5 Разработка модели проектируемой системы

5.1 Схема сети «МЕТЕО» метеорологического комплекса  «Космического центра «Южный»

Рисунок 2 - Схема сети «МЕТЕО»

5.2 Функциональные модели и модели данных проектируемой АС

5.2.1 Разработка модели

5.2.1.1 Краткая характеристика системы

Контекстная диаграмма представлена на рисунке 3.

Рисунок 3 – Контекстная диаграмма

Проведя анализ метео отдела, можно отобразить в виде диаграммы нулевого уровня.

Для автоматизации выбрана следующая функция:

-  прогноз;

Эта цель достигается за счет того, что собираются все необходимые данные о каждом объекте.

Диаграмма потоков данных нулевого уровня представлена на рисунке 4.

Рисунок 4 – Диаграмма потоков данных нулевого уровня

Процессы:

- Обработка информации;

- Распределение информации;

- Процесс прогнозирования;

Хранилища:

- БД метео данных.

Диаграмма потоков данных первого уровня процесса «Процесс прогнозирования» представлена на рисунке 5.

Рисунок 5 – Диаграмма первого уровня процесса «Процесс прогнозирования»

Процесс «Процесс прогнозирования» делиться на следующие задачи:

- Рисование карт;

- Расчет данных;

- Прогноз.

6 Разработка модели базы данных

Администратор может добавлять, изменять, удалять данные в базе. Пользователи в соответствии с их правами могут добавлять, редактировать, просматривать и удалять данные.

На рисунке 8 представлена схема базы данных.

Рисунок 6 – Схема БД

6.1 Требования к информации

6.1.1 Данные о работе системы

Автоматизация данной системы позволит повысить эффективность использования информации о погоде, в результате которой пользователю и его прикладным программам все данные представляются единым информационным массивом.

6.1.2       Дополнительная информация

1) Ploshadki – сущность номера площадок.

Атрибуты:

- Kod [Avtoincrement] -  код.

- Nazvanie[NVARCHAR] – название.

2) Meteouslovia – сущность содержит информацию о метеоусловиях.

Атрибуты:

- Kod [Avtoincrement] - код.

- Nazvanie[NVARCHAR] – название.

- Izmenenia[NVARCHAR] – изменения.

3) Meteodannie – сущность содержит информацию об используемых метеоданных.

Атрибуты:

- Kod [Avtoincrement] -  код.

- Kod_poshadki [NVARCHAR] -  код площадки.

- Kod_meteoUsloviya[NVARCHAR] -  код метеоусловия.

- Data [DATATIME] – дата.

- Znachenie[NVARCHAR] -  znacheie.

4) Prognozi.

- Kod [Avtoincrement] -  код.

- Kod_sinoptika[NVARCHAR] -  код синоптика.

- Kod_meteoUsloviya[NVARCHAR] -  код метеоусловия.

- Data [DATATIME] – дата.

- Znachenie[NVARCHAR] -  znacheie.

5) Sinoptik – сущность содержит информацию о синоптиках.

- ФИО [NVARCHAR (50)] – ФИО синоптика

- Prochee[NVARCHAR] –прочее.

7 Разработка диалогового интерфейса пользователя

              Диалоговый интерфейс для администратора должен содержать главную форму, на которой будет располагаться меню, обеспечивающее доступ ко всем данным.

8 Разработка алгоритмов, реализация и отладка компонент программного обеспечения АС.

8.1.1Структура программы сервер

Рисунок 7 – Структура программы сервер

8.1.2Структура программы клиент

Рисунок 8 – Структура программы Client

8.2 Сетевые компоненты

В компонентах indy, которые содержатся в delphi, ip-адрес определяется в свойстве host, как  правило, только в клиентских приложениях. Компоненты, размещаемые на сервере, имеют методы, позволяющие начать или прекратить опрос соответствующего порта, - например изменение свойства active компонента idtcpserver начинает или прекращает опрос соответствующего порта. После установки связи между клиентом и сервером можно начинать передачу данных.
В компонентах indy большое внимание уделяется безопасности и надежности при работе с данными. Например, в компоненте idtcpclient есть методы connect и disconnect. Применяя технику программирования, как в приведенном ниже коде со стороны клиента:

with tcpclient do

begin

connect;

try

lstmain.items.add(eadln);

finally

disconnect;

end;

end;

и используя свойство connection, передаваемое в качестве параметра экземпляра athread класса tidpeerthread, со стороны сервера:

with athread.connection do

begin

writeln('hello from basic indy server server.');

disconnect;

end;

можно рассчитывать либо на штатное выполнение соединения, либо на правильную обработку ошибки. Обратите внимание на методы readln и writeln соответствующих классов - они напоминают стандартные операторы ввода-вывода pascal. Это дань технике программирования в unix, где большинство системных операций выполняются благодаря чтению и записи в соответствующие файлы. Так же как у компонентов fastnet, у классов компонентов indy имеются события, при помощи которых можно организовывать событийное управление. Например, можно организовать вывод сообщения на форму при соединении с клиентом:

procedure tform1.idechoserver1connect(athread: tidpeerthread);

begin

lblstatus.caption := '[ serving client ]';

end;

В indy представлены компоненты, реализующие протоколы с клиентскими и серверными частями, присущие только этой библиотеке. Компоненты tidgopherserver и tidgopher, благодаря методам getextendedmenu, getfile, getmenu, gettextfile на клиентской стороне и returngopheritem, senddirectoryentry - на стороне сервера, помогают осуществить просмотр файлов различного типа, в том числе помеченных как скрытые, а также директорий на удаленном компьютере (подобно тому, как это делает команда dir *.* в операционной системе ms-dos).  При помощи компонентов idsmtp и idmessage можно легко создать свое web-приложение, способное отправлять почту по протоколу smtp. При этом класс idmessage (один из 23 компонентов со страницы indy misc) отвечает за формирование сообщения, что вытекает из его названия, а idsmtp - за организацию соединения с почтовым сервером. Технология, применяемая в indy, использует операции чтения и записи с блокировкой. Любая операция connect, используемая в indy, ожидает завершения соединения. При работе с клиентскими компонентами indy, как правило, требуется выполнение следующих операций: запросить соединение с сервером; осуществить запросы к серверу на чтение и запись (в зависимости от типа сервера шаг выполняется единожды или повторяется много раз); закончить соединение с сервером и разъединиться. Компоненты indy разрабатывались так, чтобы обеспечить сверхвысокий уровень абстракции. Запутанность и подробности стека tcp/ip скрыты от программиста, с тем чтобы он мог сосредоточиться на текущих задачах. Следующий небольшой пример показывает типичную сессию клиентского компонента:

with indyclient do begin

host := 'zip.pbe.com'; // host to call

port := 6000; // port to call the server on

connect;

try

// your code goes here

finally

disconnect;

end;

end;

В примере, даже если соединение с сервером не будет установлено, связь корректно разорвется благодаря использованию оператора try-finally.
Серверные компоненты indy описывают разнообразные модели серверов, которые можно использовать в зависимости от потребностей и применяемого протокола. tidtcpserver - наиболее часто используемый серверный компонент, который создает вторичный процесс, независимый от основного процесса приложения. Созданный процесс ожидает входящие запросы от потенциальных клиентов. Для каждого клиента, на запрос которого он отвечает, создается индивидуальный вторичный процесс. События, возникающие в процессе обслуживания, соотносятся с контекстом соответствующих процессов. Иными словами, для каждого клиентского подключения класс tidtcpserver использует уникальный
вторичный поток, вызывая обработчик события onexecute этого потока. Формальным параметром метода onexecute является ссылка на экземпляр класса athread, соответствующего созданному потоку. Свойство connection этого класса - ссылка на класс tidtcpconnection, экземпляр которого создается для обработки клиентского запроса. tidtcpconnection поддерживает чтение и запись через соединение, а также установление и завершение сеанса связи.
Протокол udp работает без предварительной установки соединения с сервером (каждый посланный пакет является самостоятельным набором данных, а не частью большой сессии или соединения). В то время как tidtcpserver порождает отдельные потоки для каждого соединения, tidudpserver использует или главный поток, или единственный вторичный поток, который обрабатывает все запросы протокола udp. Когда tidudpserver активен, создается поток для прослушивания входящих udp-пакетов. Для каждого полученного пакета возникает событие onudpread или в основном потоке, или в контексте прослушивающего потока - в зависимости от значения свойства threadedevent. Когда threadedevent принимает значение false, событие возникает в основном потоке, в противном случае - в прослушивающем потоке. Пока происходит обработка события, другие операции сервера блокируются. Поэтому важно следить, чтобы процедуры onudpread выполнялись как можно быстрее. Если нужно создать клиентское приложение нового клиента для существующего сервера с использованием существующего протокола, ваша задача состоит исключительно в разработке и отладке клиентского приложения. Однако, когда приходится разрабатывать и клиентское, и серверное приложения с применением существующего или нового протокола, мы сталкиваемся с классической проблемой 'яйца и курицы'. С чего начинать программирование - с клиента или с сервера? Очевидно, в итоге должны быть созданы и клиент, и сервер. Для многих приложений, особенно использующих текстовый протокол (например, http), проще начать создание приложения с проектирования сервера. А для его отладки имеется удобный клиент, который уже существует. Это - консольное приложение telnet, которое имеется и на windows, и на unix. Если набрать консольную команду telnet 127.0.0.1 80 с ip-адресом локального компьютера и номером порта 80, используемым по умолчанию web-серверами, то приложение откликнется текстом, представленным на рис. 6, в случае ОС windows 2000 и iis 5.0. Для создания самого простого сервера с использованием компонентов indy необходимо: Создать новый проект.
Поместить на главную форму проекта экземпляр компонента tidtcpserver с палитры indy servers. Присвоить свойству defaultport экземпляра класса tidtcpserver1 значение 6002 (рекомендуется присваивать большие значения, чтобы избежать дублирования номеров портов у различных приложений), а свойству active - значение true. Добавить следующий текст в метод экземпляра класса tidtcpserver1, обрабатывающий событие