1.1.4 Потоки данных предметной области

Анализ предметной области начинается с выделения основных объектов и установления взаимосвязей между ними. При проектировании системы используется принцип концептуализации предметной области, т.е. система состоит из компонентов, под которыми понимают некоторую абстрактную единицу, обладающую функциональностью (способностью выполнять функции).

Выделим основные объекты предметной области, участвующие в автоматизации:

• локомотив;

• поезд;

• железнодорожный путь:

• сортировочная станция;

• диспетчерская;

• поездной диспетчер;

• процесс оптимизации:

• ЭВМ (процесс выполнения алгоритмов),

• выходные данные (отчёт).

На рисунке 1.6 представлены потоки данных предметной области.

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

1.1.5 Процесс подготовки поезда к отправлению

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

Информация о прибывших локомотивах и поездах поступает на сортировочную станцию. Все нужные данные для процесса оптимизации оборота локомотивов через сортировочную станцию, хранящиеся в универсальной базе данных АСУ СТ поступают в ЭВМ. В ЭВМ на основании написанных алгоритмов происходит процесс оптимизации привязки локомотива к поезду, вычисление пути и времени готовности к отбытию. Далее формируются отчёты по проделанной работе и через форму выводятся в диспетчерской. Поездной диспетчер, сидящий за своим автоматизированным рабочим местом видит результат работы программы и с помощью связи передаёт команду и формировании нового поезда или отправки дальше существующего на сортировочную станцию.

Далее сотрудники железной дороги формируют документы для создания и отправки поезда и организуют работу локомотивных бригад. Во время этого должен последовательно успешно быть выполнены все виды работ:

• проверка технического состояния локомотива;

Рисунок 1.6 — Потоки данных предметной области

• проведение профилактических работ;

• буксировка поезда на железнодорожный путь.

Далее сообщить об успешно выполненной работе и поезд готов к отправлению.

2. Обзор существующих систем

1.2.1 Автоматизированная система управления станцией «асус» от оао «агат-системы управления»

Рассмотрим подробно автоматизированную систему управления станцией от компании ОАО «АГАТ-системы управления»: её особенности, строение и функционал.

Назначение автоматизированной системы управления станцией (АСУС):

• автоматизации технологических процессов по обработке вагонопотоков на сортировочной станции;

• создания динамической вагонной модели состояния приемо-отправочных, сортировочных и других путей станции;

• организации грузовой работы станции;

• ведения архива вагонно-отправочной модели станции с глубиной хранения 7 лет;

• решения прикладных задач станционной отчетности;

• информационного обмена с системой верхнего уровня.

• Состав автоматизированной системы (АСУС):

• универсальное рабочее место АСУС, настраиваемое в соответствии с должностными обязанностями персонала (УРМ);

• АРМ выдачи предупреждений машинистам локомотивных бригад (АРМ ПРЕД);

• АРМ оператора пункта технического осмотра (АРМ ПТО);

• АРМ оператора коммерческого осмотра вагонов (АРМ ПКО);

• АРМ оператора станционной отчетности (АРМ ОСО);

• автоматизированные рабочие места руководителей: начальника станции, заместителя начальника станции, начальника технической конторы и т.д. (АРМ РД).

Подробно опишем все функции которые выполняются системой АСУС.

УРМ – в зависимости от особенностей технологического процесса станции имеет возможность совмещения либо перераспределения функций между рабочими местами персонала станции, включенными в состав АСУС. Настройка УРМ производится с АРМ администратора системы. Количество рабочих мест – не ограничено.

Рисунок 1.7 –Форма работы УРМ

АРМ ПРЕД:

• регистрация заявок на выдачу предупреждений локомотивным бригадам;

• печать и выдача предупреждений на отправляемые поезда и маневровые локомотивы, работающие на узле либо станции;

• ведение архива введенных и выданных предупреждений;

• автоматическое отслеживание времени действия предупреждений.

Рисунок 1.8 –Форма работы АРМ ПРЕД

АРМ ПТО:

• ввод схемы осмотра поезда (как по прибытию, так и по отправлению) с регистрацией в архиве станции для последующего выявления ошибок, допущенных осмотрщиками при браковке вагонов;

• получение информации о требующих ремонта вагонах (по пробегу, дате) в виде сообщения «204″ из ГВЦ;

• ввод информации о неисправных вагонах в составе поезда в базу данных, автоматическая разметка натурного листа поезда в части забракованных по техническим неисправностям вагонов;

• выдача формы ВУ-36 и акта разбраковки на выпускаемые из ремонта вагоны;

• выдача комплекта документов на вагоны, пересылаемые для ремонта на другие станции.

Рисунок 1.9 –Форма работы АРМ ПТО

АРМ ПКО:

• ввод и корректировка информации о неисправных вагонах (контейнерах) в составе поезда или одиночных вагонах;

• автоматическая разметка натурного листа поезда в части забракованных по коммерческим неисправностям вагонов;

• предварительный просмотр, выдача на печать данных из формы ГУ-98 за определенный интервал времени;

• составление, корректировка и выдача на печать акта общей формы на коммерчески неисправные вагоны (контейнеры);

• выдача на печать отчета по вагонам с коммерческими неисправностями.

Рисунок 1.10 – Форма работы АРМ ПКО

АРМ ОСО:

• расчет и выдача отчетных данных о вагонном парке станции на отчетный час (отчет о вагонном парке станции по форме ДО-2);

• расчет и выдача отчетных данных о прибывших и отправленных поездах по форме ДУ-4;

• расчет и выдача отчетных данных о груженых вагонах на 17.00 по форме ДО-15;

• формирование отчета о простое вагонов;

• формирование помесячно отчета о вагонном парке;

• отработка запросов на формирование различного рода справок  и отчетов по работе станции на основании информации архива.

Рисунок 1.11 – Форма работы АРМ ОСО

АРМ РД – оснащаются программным модулем доступа к архиву станции, а также к информации об оперативной обстановке на станции.

ОСОБЕННОСТИ / ПРЕИМУЩЕСТВА

Автоматизированных рабочих места АСУС ориентированы на выполнение функций, непосредственно связанных с должностными обязанностями персонала.

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

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

2. Виды баз данных

Базой данных является представленная в объективной форме совокупность самостоятельных материалов (статей, расчетов, нормативных актов, судебных решений и иных подобных материалов), систематизированных таким образом, чтобы эти материалы могли быть найдены и обработаны с помощью электронной вычислительной машины (ЭВМ) [6].

База данных— организованная в соответствии с определёнными правилами и поддерживаемая в памяти компьютера совокупность данных, характеризующая актуальное состояние некоторой предметной области и используемая для удовлетворения информационных потребностей пользователей [7].

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

Далее указаны основные классификации:

• классификация БД по модели данных:

• иерархические;

• сетевые;

• реляционные;

• объектные;

• объектно-ориентированные;

• объектно-реляционные;

• классификация БД по технологии физического хранения:

• БД во вторичной памяти (традиционные);

• БД в оперативной памяти (in-memory databases);

• БД в третичной памяти (tertiary databases);

• классификация БД по содержимому:

• географические;

• исторические;

• научные;

• мультимедийные;

• классификация БД по степени распределенности:

• централизованные;

• распределённые [7].

Реляционная модель данных (РМД) включает следующие компоненты:

• структурная составляющая – данные в базе данных представляют собой набор отношений;

• составляющая целостности – отношения (таблицы) отвечают определенным условиям целостности;

• составляющая обработки – реляционная модель данных поддерживает операторы манипулирования отношениями.

Следует отметить три важных обстоятельства:

• модель является логической, то есть отношения являются логическими (абстрактными), а не физическими (хранимыми) структурами;

• для реляционных баз данных верен информационный принцип: всё информационное наполнение базы данных представлено одним и только одним способом, а именно – явным заданием значений атрибутов в кортежах отношений; в частности, нет никаких указателей (адресов), связывающих одно значение с другим;

• наличие реляционной алгебры позволяет реализовать декларативное программирование и декларативное описание ограничений целостности, в дополнение к навигационному (процедурному) программированию и процедурной проверке условий [8].

Кроме того в состав реляционной модели данных включают теорию нормализации.

Реляционная база данных– база данных, основанная на РМД. Слово «реляционный» происходит от англ. relation (отношение). Для работы с реляционными БД применяют реляционные системы управления базами данных (СУБД) [7].

Нормальная форма– формальное свойство отношения, которое характеризует степень избыточности хранимых данных и возможные проблемы. [7].

2. Виды клиент-серверных архитектур

Клиент-сервер— вычислительная или сетевая архитектура, в которой задания или сетевая нагрузка распределены между поставщиками услуг (сервисов), называемыми серверами, и заказчиками услуг, называемыми клиентами. Нередко клиенты и серверы взаимодействуют через компьютерную сеть и могут быть как различными физическими устройствами, так ипрограммным обеспечением[9]. На рисунке 1.2 представлены роли клиента и сервера.

Рисунок 1.12 – Роль клиента и сервера

Основные преимущества архитектуры клиент-сервер:

• возможно, в большинстве случаев, распределить функции вычислительной системы между несколькими независимыми компьютерами в сети;

• все данные хранятся на сервере, который, как правило, защищён гораздо лучше большинства клиентов;

• возможно объединение разных клиентов.

Двухуровневая архитектура (толстый клиент)— этоприложение, обеспечивающее расширенную функциональность независимо от центральногосервера. Частосерверв этом случае является лишьхранилищем данных, а вся работа по обработке и представлению этих данных переносится на машину клиента [9].

Данная технология обладает следующими достоинствами:

• толстый клиент обладает широким функционалом в отличие от тонкогоклиента;

• доступен режим многопользовательской работы;

• предоставляется возможность работы даже при обрывах связи с сервером;

• высокое быстродействие.

Недостатки архитектуры:

• большой размер дистрибутива.

• многое в работе клиента зависит от того, для какой платформы он разрабатывался.

• при работе с ним возникают проблемы с удаленным доступом к данным.

• довольно сложный процесс установки и настройки.

• сложность обновления и связанная с ней неактуальность данных.

Многоуровневая архитектура– разновидность архитектуры клиент-сервер, в которой функция обработки данных вынесена на один или несколько отдельных серверов. Это позволяет разделить функции хранения, обработки и представления данных для более эффективного использования возможностей серверов и клиентов [9].

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

• масштабируемость;

• конфигурируемость — изолированность уровней друг от друга позволяет быстро и простыми средствами переконфигурировать систему при возникновении сбоев или при плановом обслуживании на одном из уровней;

• высокая безопасность;

• высокая надёжность;

• низкие требования к скорости канала (сети) между терминалами и сервером приложений;

• низкие требования к производительности и техническим характеристикам терминалов.

Недостатки вытекают из достоинств:

• более высокая сложность создания приложений;

• сложнее в разворачивании и администрировании;

• высокие требования к производительности серверов приложений и сервера базы данных;

• высокие требования к скорости канала (сети) между сервером базы данных и серверами приложений.

2. Стандарт построения ER-модели данных IDEF1X

Методология IDEF1Xпредназначена для моделирования структур баз данных на основе диаграмм сущность-связь (ER-диаграмм) [10]. При проектировании баз данных обычно выделяют три уровня абстракции, на которых происходит последовательное уточнение модели:

• концептуальный;

• логический;

• физический.

IDEF1Xпредусматривает проектирование модели базы данных на логическом и физическом уровнях.

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

Сущность– объект, информация о котором должна сохраняться. Сущности должны иметь наименование в виде существительного в единственном числе. Каждый экземпляр сущности на диаграмме уникален.

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

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

На логическом уровне можно установить следующие связи между сущностями:

• идентифицирующую связь один-ко-многим;

• неидентифицирующую связь один-ко-многим;

• связь многие-ко-многим.

Идентифицирующая связь устанавливается между независимой (родительский конец связи) и зависимой (дочерний конец связи) сущностями. Зависимая сущность не может существовать самостоятельно – экземпляр зависимой сущности определяется только через отношение к сущности, которая его идентифицирует. В дочерней сущности добавляются новые атрибуты, помечаемые как внешний ключ.

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

Связь многие-ко-многим существует только на логическом уровне. При переходе на физический уровень это отношение должно быть преобразовано: вместо связи многие-ко-многим добавляется новая зависимая сущность, связанная идентифицирующими связями один-ко-многим с сущностями, находившимися в исходном отношении [10].

На рисунке 1.13 представлены графические примитивы IDEF1X.

Рисунок 1.13 – Графические примитивы IDEF1X

2. Разработка информационно-логической модели