Проектирование системы диспетчерского наблюдения
Автор работы: Пользователь скрыл имя, 04 Октября 2013 в 17:38, дипломная работа
Краткое описание
Геоинформационные системы (ГИС) – это информационные системы, предназначенные для сбора, хранения, анализа и визуализации (выдачи) пространственных данных. В настоящее время работу общественного пассажирского транспорта
большинства городов Украины контролируют с помощью систем диспетчерского управления, созданных более десятка лет назад. Имеющиеся автоматизированные системы диспетчерского управления отслеживают работу городских автобусов с помощью сети контрольных пунктов.
Содержание
СПИСОК ИСПОЛЬЗУЕМЫХ ТЕРМИНОВ И СОКРАЩЕНИЙ..................... 10
ВВЕДЕНИЕ............................................................................................................ 12
1
АНАЛИЗ ЗАДАЧИ СОЗДАНИЯ АВТОМАТИЗИРОВАННОЙ
СИСТЕМЫ ДИСПЕТЧЕРСКОГО НАБЛЮДЕНИЯ................................. 13
1.1 Анализ предметной области АСДН....................................................13
1.1.1 Область применения и виды ГИС.............................................13
1.1.2 Построение базовой модели предметной области АСДН......15
1.1.3 Существующие системы............................................................19
1.1.4 Общие требования к АСДН.......................................................28
1.2 Анализ требований к интерфейсу АСДН...........................................31
1.3 Анализ требований к аппаратной части АСДН.................................31
1.4 Постановка задачи на разработку АСДН ...........................................33
1.4.1 Требования к программной части АСДН.................................33
1.4.2 Требования к аппаратной части АСДН....................................37
1.5 Выводы...................................................................................................37
2
РАЗРАБОТКА АВТОМАТИЗИРОВАННОЙ СИСТЕМЫ
ДИСПЕТЧЕРСКОГО НАБЛЮДЕНИЯ ...................................................... 38
2.1 Выбор технических средств построения АСДН................................38
2.1.1 Среды разработки .......................................................................38
2.1.2 Хранилище данных и средства интеграции.............................39
2.1.3 Средства для реализации бизнес логики..................................40
2.1.4 Инструментальные средства для проектирования слоя
представления .............................................................................41
2.1.5 Инструментальные средства для обеспечения
безопасности................................................................................42
2.1.6 Выводы.........................................................................................42
2.2 Разработка архитектуры АСДН...........................................................42
2.3 Разработка программной подсистемы АСДН....................................43
2.3.5 Разработка классов сущностей системы ..................................57
2.3.6 Проектирование интерфейса пользователя..............................74
2.4 Разработка аппаратной подсистемы ...................................................84
2.4.1 Разработка структурной схемы.................................................84
2.4.2 Разработка схемы электрической принципиальной................85
2.5 Выводы...................................................................................................87
3
РЕАЛИЗАЦИЯ АВТОМАТИЗИРОВАННОЙ СИСТЕМЫ
ДИСПЕТЧЕРСКОГО НАБЛЮДЕНИЯ ...................................................... 88
3.1 Реализация программной подсистемы................................................88
--------------------------------------------------------------------------------
Page 2
8
3.3.1 Результаты реализации базы данных........................................88
3.3.2 Реализация интерфейса пользователя ......................................93
3.2 Выводы.................................................................................................116
4
ОХРАНА ТРУДА И ОКРУЖАЮЩЕЙ СРЕДЫ...................................... 117
4.1 Требования к помещениям для эксплуатации ВДТ ПК..................117
4.2 Гигиенические требования к параметрам среды в помещениях
с ВДТ ПК..............................................................................................118
4.2.1 Микроклимат.............................................................................118
4.2.2 Освещение.................................................................................119
4.2.3 Шум и вибрация........................................................................119
4.2.4 Неионизирующее электромагнитное излучение...................120
4.2.5 Ионизирующее электромагнитное излучение.......................120
4.3 Требования к организации и оснащению рабочих мест
с ВДТ ПК..............................................................................................121
4.4 Электробезопасность в помещениях с ВДТ ПК..............................123
4.5 Пожарная безопасность......................................................................123
4.6 Инженерный расчет задачи................................................................124
4.7 Выводы.................................................................................................126
ПЕРЕЧЕНЬ ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ...................................... 127
Вложенные файлы: 1 файл
7
СОДЕРЖАНИЕ
СПИСОК ИСПОЛЬЗУЕМЫХ ТЕРМИНОВ И СОКРАЩЕНИЙ..................... 10
ВВЕДЕНИЕ............................................................................................................ 12
1
АНАЛИЗ ЗАДАЧИ СОЗДАНИЯ АВТОМАТИЗИРОВАННОЙ
СИСТЕМЫ ДИСПЕТЧЕРСКОГО НАБЛЮДЕНИЯ................................. 13
1.1 Анализ предметной области АСДН....................................................13
1.1.1 Область применения и виды ГИС.............................................13
1.1.2 Построение базовой модели предметной области АСДН......15
1.1.3 Существующие системы............................................................19
1.1.4 Общие требования к АСДН.......................................................28
1.2 Анализ требований к интерфейсу АСДН...........................................31
1.3 Анализ требований к аппаратной части АСДН.................................31
1.4 Постановка задачи на разработку АСДН ...........................................33
1.4.1 Требования к программной части АСДН.................................33
1.4.2 Требования к аппаратной части АСДН....................................37
1.5 Выводы...................................................................................................37
2
РАЗРАБОТКА АВТОМАТИЗИРОВАННОЙ СИСТЕМЫ
ДИСПЕТЧЕРСКОГО НАБЛЮДЕНИЯ ...................................................... 38
2.1 Выбор технических средств построения АСДН................................38
2.1.1 Среды разработки .......................................................................38
2.1.2 Хранилище данных и средства интеграции.............................39
2.1.3 Средства для реализации бизнес логики..................................40
2.1.4 Инструментальные средства для проектирования слоя
представления .............................................................................41
2.1.5 Инструментальные средства для обеспечения
безопасности................................................................................42
2.1.6 Выводы.........................................................................................42
2.2 Разработка архитектуры АСДН...........................................................42
2.3 Разработка программной подсистемы АСДН....................................43
2.3.5 Разработка классов сущностей системы ..................................57
2.3.6 Проектирование интерфейса пользователя..............................74
2.4 Разработка аппаратной подсистемы ...................................................84
2.4.1 Разработка структурной схемы.................................................84
2.4.2 Разработка схемы электрической принципиальной................85
2.5 Выводы...................................................................................................87
3
РЕАЛИЗАЦИЯ АВТОМАТИЗИРОВАННОЙ СИСТЕМЫ
ДИСПЕТЧЕРСКОГО НАБЛЮДЕНИЯ ...................................................... 88
3.1 Реализация программной подсистемы................................................88
8
3.3.1 Результаты реализации базы данных........................................88
3.3.2 Реализация интерфейса пользователя ......................................93
3.2 Выводы.................................................................................................116
4
ОХРАНА ТРУДА И ОКРУЖАЮЩЕЙ СРЕДЫ...................................... 117
4.1 Требования к помещениям для эксплуатации ВДТ ПК..................117
4.2 Гигиенические требования к параметрам среды в помещениях
с ВДТ ПК..............................................................................................118
4.2.1 Микроклимат.............................................................................118
4.2.2 Освещение.................................................................................119
4.2.3 Шум и вибрация........................................................................119
4.2.4 Неионизирующее электромагнитное излучение...................120
4.2.5 Ионизирующее электромагнитное излучение.......................120
4.3 Требования к организации и оснащению рабочих мест
с ВДТ ПК..............................................................................................121
4.4 Электробезопасность в помещениях с ВДТ ПК..............................123
4.5 Пожарная безопасность......................................................................123
4.6 Инженерный расчет задачи................................................................124
4.7 Выводы.................................................................................................126
ПЕРЕЧЕНЬ ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ...................................... 127
ПРИЛОЖЕНИЯ................................................................................................... 128
9
10
СПИСОК ИСПОЛЬЗУЕМЫХ ТЕРМИНОВ И СОКРАЩЕНИЙ
GPS (англ. Global Positioning System – глобальная система
позиционирования) – спутниковая система, с помощью которой можно
определить координаты вашего нахождения в любой точке планеты.
АДМИНИСТРАТОР – актор системы, роль пользователя, дающая
право доступа к администрированию подсистемы безопасности.
Администрирование прав доступа – установление соответствия между
ролями и пользователями с одной стороны и правами доступа к функциям
системы и защищенным объектам предметной области.
Актор (или исполнитель) – внешняя по отношению к системе
сущность, взаимодействующая с системой.
Вариант использования – спецификация последовательности действий,
выполняемых в процессе взаимодействия системы и актора.
Защищенная функция системы – функция, доступ к которой имеют не
все пользователи системы, а лишь обладающие определенными правами, в
соответствии с их ролью.
Защищенный объект предметной области (Defensible object) – объект,
принадлежащий классу предметной области, доступ к которому зависит от
наличия или отсутствия прав у определенной роли или конкретного
пользователя. Доступ к объекту может быть полным или маскированным
(для отдельных функций или операций). В системе АСДН защищенными
являются объекты класса Unit.
Интерфейс системы – Desktop-форма, являющаяся частью системы
АСДН, предоставленная пользователю.
Лог сообщений – последовательность сообщений Юнита-ТС,
накопленная в памяти и передаваемая по команде ОПЕРАТОРА в БД
системы.
Маска доступа – упорядоченная битовая строка, определяющая права
доступа для защищенной функции или операции над объектом.
ОПЕРАТОР – Актор системы.
Подсистема безопасности – составная часть системы АСДН,
отвечающая за предоставления доступа к БД системы, разграничение прав
доступа и администрирование прав доступа к различным функциям системы.
Пользователь системы (User) – лицо, использующее систему АСДН.
Имеет право доступа к системе через интерфейс системы согласно своей
роли. Имеет права доступа к защищенным объектам системы согласно своей
роли и правам доступа для каждого конкретного объекта.
Прецедент – см. Вариант использования.
Роль (Role) – логическая группа пользователей, обладающих равными
правами по доступу к системе.
11
Сообщение Юнита-ТС
–
фиксированный
набор
значений,
передаваемых Юнитом-ТС ОПЕРАТОРУ и заносящийся в БД системы в виде
единичной записи.
Сценарий – определенная последовательность действий, которая
иллюстрирует поведение. Сценарий может использоваться для иллюстрации
взаимодействия или выполнения экземпляра варианта использования.
ТС (Car) – транспортное средство.
Функция системы (ProgramResourse) – функция системы АСДН,
предоставляемая пользователю через интерфейс системы. С точки зрения
подсистемы безопасности выделяются незащищенные функции, защищенные
функции и функции доступа к защищенным объектам.
Юнит (Unit) – блок, оборудованный GPS, устанавливаемый на ТС для
наблюдения и охраны.
ЮНИТ-ТС (Unit-Car) – транспортное средство (ТС), оборудованное
юнитом, актор системы.
12
ВВЕДЕНИЕ
Геоинформационные системы (ГИС) – это информационные системы,
предназначенные для сбора, хранения, анализа и визуализации (выдачи)
пространственных данных.
В настоящее время работу общественного пассажирского транспорта
большинства городов Украины контролируют с помощью систем
диспетчерского управления, созданных более десятка лет назад.
Имеющиеся автоматизированные системы диспетчерского управления
отслеживают работу городских автобусов с помощью сети контрольных
пунктов. Однако большинство маршрутов имеют только один контрольный
пункт. По этой причине оперативно получать информацию и воздействовать
на ситуацию невозможно.
В автоматизированных системах пассажирского транспорта ряда
крупных городов сведения о работе транспорта поступают от датчиков
индукционного типа по выделенным телефонным линиям.
В качестве средств автоматизированного контроля в таких системах
под асфальтом «зашиты» индукционные петли, к которым подведены
телефонные линии. С этой контактной точки и передаѐтся сигнал в
диспетчерский центр.
Существующие системы позволяют отслеживать работу только
городских автобусов и троллейбусов.
Существование систем управления только за пассажирским
транспортом определяет необходимость внедрения автоматизированной
системы диспетчерского наблюдения за движением любого наземного
транспорта с глобальной спутниковой системой.
Актуальность проектируемой в дипломной работе системы состоит в
том, что она предназначена для решения группы задач, которые при своей
значимости для автотранспортных предприятий не имеют широкого
распространения среди массово используемых ГИС.
13
1 АНАЛИЗ ЗАДАЧИ СОЗДАНИЯ АВТОМАТИЗИРОВАННОЙ
СИСТЕМЫ ДИСПЕТЧЕРСКОГО НАБЛЮДЕНИЯ
Геоинформационные системы базируются на нескольких основных
компонентах: проекционные преобразования, классификация данных,
система управления базами данных и аналитический аппарат.
Основным компонентом любой пространственной информации
являются данные о положении каждой точки контура объекта на местности
(метрика объектов). При этом стоит учитывать, что реальная местность не
является плоской, как экран монитора или лист бумаги. Для воспроизведения
земной поверхности на плоскости в картографии применяются специальные
проекционные преобразования, разные для разных за формой и
местоположением участков местности. Поэтому ГИС, которая хранит данные
на значительные по площади территории, должна постоянно выполнять
операции по преобразованию метрики. От скорости и точности выполнения
операций проекционных преобразований зависит качество работы всей
системы в целом.
1.1 Анализ предметной области АСДН
Для определения
особенностей
автоматизированной
системы
диспетчерского наблюдения и круг решаемых в процессе проектирования
задач проведем анализ предметной области разрабатываемой системы.
1.1.1 Область применения и виды ГИС
Наиболее распространенные на сегодня ГИС в сферах:
- геодезия и картография: ГИС используются для обработки
материалов
полевой
съемки,
хранения
и
обновления
картографических материалов, подготовки к печати и выдаче карт;
- навигационные системы и системы мониторинга транспорта:
возможности ГИС по отображению значительных объемов
разнотипных картографических данных позволяют в реальном
времени отслеживать местонахождение и движение транспортных
средств;
- муниципальные системы: на ГИС возлагаются задачи хранения
разнообразной пространственной информации и связанных с
объектами документов (планы территорий, земельно-кадастровая
информация,
информация
об
объектах
недвижимости,
коммуникации, и связанные с объектами чертежи, разрешения,
решения и другие документы);
14
- мониторинг окружающей природной среды: именно специалисты
этой сферы первыми начали работы по созданию ГИС для хранения
значительных массивов пространственной информации и ее
анализа, поэтому в этой сфере ГИС играют очень важную роль;
- военное дело: деятельность военных формирований всегда
требовала максимально точных и детальных сведений о местности,
на которой планируются или проводятся военные и специальные
операции, поэтому геодезия и картография всегда были на службе у
военного дела – сегодня, как для подготовки военно-
топографических карт, так и непосредственно для принятия
решений используют ГИС.
В последнее время геоинформационные системы удачно внедряются
также в сферах:
- сельского хозяйства: сельскохозяйственное производство – одна из
отраслей, где пространственная информация (месторасположение
участков, которые обрабатываются, их площадь, характерные
условия местности, размещение дорог) имеет ключевое значение, и
только финансовые возможности предприятий этой отрасли
задерживают внедрение современных ГИС в процесс управления;
- на предприятиях связи и энергетики: для предприятий этой отрасли
характерно наличие объектов управления, рассредоточенных на
значительных территориях, и поэтому именно эти отрасли требуют
системы, способные оперировать пространственной информацией;
- управление бизнесом: в последние годы бизнес становится все
больше разветвленным (филиалы предприятий в разных городах и
странах, сети магазинов и складов), что означает необходимость
оперировать данными об определенных и иногда достаточно
больших территориях, решать сложные транспортные задачи,
анализировать и сравнивать данные о собственной деятельности и
деятельности конкурентов в разных регионах;
- в информационно-справочных системах: глобализированный мир
требует от людей наличия представления не только о своем городе
или регионе, но и о других, совершать рабочие поездки в разные
регионы. Исходя из этого, возникает потребность в информации не
только о факте существования определенных объектов, но и об их
точном месторасположении, взаимном положении, путях, по
которым к ним можно добраться.
По своему предназначению ГИС делятся на универсальные и
специализированные.
Универсальные ГИС могут использоваться практически в любой сфере,
предоставляя пользователям определенный базовый набор операций по
хранению и обработке растровых, векторных и матричных картографических
данных, доступ к информации в базах данных и средства по созданию
собственных специализированных дополнений. Универсальные ГИС в
15
основном имеют модульную структуру. Использование тех или иных
модулей позволяет создавать на их основе специализированные системы.
Специализированные ГИС решают задачи только определенной
отрасли. Они имеют специализированый набор инструментов, который
лучше удовлетворяет пользователей, которым необходимо решать
определенный ограниченный круг задач. Такие ГИС создаются на платформе
универсальных ГИС или как самостоятельные системы.
1.1.2 Построение базовой модели предметной области АСДН
Для построения базовой модели предметной области АСДН
рассмотрим задачи, которые должна решать разрабатываемая система,
проблемы, которые она должна устранить. Определим роли пользователей и
распределим им права доступа. Также построим концептуальную модель
предметной области, для которой разрабатывается данная система, и
определим наличие дополнительных ограничений.
1.1.2.1 Задачи, которые должна решить разрабатываемая АСДН
В данном подразделе рассмотрим задачи, которые должна решить
разрабатываемая автоматизированная система диспетчерского наблюдения.
- Информационные:
1) визуализация статичных объектов на карте, быстрый доступ к
информации об объектах с использованием пространственных
запросов;
2) учет в базе данных выполненной транспортной работы;
3) предоставление справок и отчетов о выполненной транспортной
работе;
- Логистические:
1) расчет технологических карт выполнения транспортной работы
с учетом функционирования специализированных механизмов и
прогнозированных затрат;
- Параметризированные:
1) скорость;
2) расход топлива;
3) наличие топлива в баке, контроль слив/заправка;
4) показатели внешних систем и приборов;
- Функциональные:
1) контроль;
2) мониторинг;
3) удаленное управление;
4) обратная связь;
- Ведение базы данных:
1) транспортных средств;
2) водителей, экспедиторов;
16
3) грузов;
4) пунктов загрузки/разгрузки;
5) графиков работы;
6) заказов;
7) ограничений на грузы, которые перевозятся, сроки и т.д.
- Другие задачи:
1) места и время стоянок;
2) время фактической работы;
3) соответствие фактического движения плановому;
4) использование имеющегося в системе геокомпонента и карт.
Задачи учета, анализа и управления предусматривают наличие в
системе «обратной» связи, то есть средства финансового или
административного влияния на водителей по результатам работы в системе.
1.1.2.2 Описание проблемы, решение которой должна обеспечить
разрабатываемая АСДН
Имеющиеся автоматизированные системы диспетчерского управления
отслеживают работу городских автобусов, троллейбусов и маршрутных
такси с помощью сети контрольных пунктов. Однако большинство
маршрутов имеют только один контрольный пункт. По этой причине
оперативно получать информацию и воздействовать на ситуацию
невозможно.
Также существующие системы не могут предоставить такие условия,
которые
обеспечивают
постоянный
оперативный
контроль
за
местонахождением транспортного средства. Поэтому разрабатываемая
система должна обеспечить наблюдение за перемещением транспортного
средства со стороны диспетчера, соблюдение режима эксплуатации
транспортного средства, в том числе предотвращение возможности угона
автомобилей во время стоянки, нападения на водителей транспортных
средств, пассажиров или лиц, которые сопровождают людей или грузы,
допустимое правилами использование топлива, снизить время вызова или
прибытия групп реагирования в экстренных случаях.
1.1.2.3 Перечень ролей пользователей и распределение прав
доступа
Администратор – роль пользователя, дающая право доступа к
администрированию подсистемы безопасности, наследует права Оператора.
Оператор – роль пользователя, дающая право на взаимодействие с
Юнитом-ТС через каналы связи. Права доступа данной роли назначает
Администратор.
Юнит-ТС (транспортное средство, водитель, экспедитор). Прав доступа
не имеет, так как самой системой фактически не пользуется.
17
1.1.2.4 Концептуальная модель предметной области
Выделим основные сущности и их функции на самом высоком уровне
абстракции.
Предполагается, что разрабатываемая система будет получать данные
от блока, оборудованного GPS, устанавливаемого на транспортном средстве,
то есть Юнита. Поэтому Юнит – это первая сущность системы.
Второй сущностью примем данные со спутниковой системы GPS,
которые получает и обрабатывает Юнит.
Также Юнит получает и обрабатывает данные с датчиков,
установленных на транспортном средстве. Их мы и будем считать третьей
сущностью.
Юнит обрабатывает полученные данные и отправляет их
администраторам и диспетчерам. Администратор и диспетчер будут
четвертой сущностью.
Администраторы и диспетчеры могут запросить отчет о данном
транспортном средстве, который берет свои данные из тех, что обработал и
прислал Юнит. Поэтому отчет – это пятая сущность.
Также администраторы и диспетчеры могут еще посмотреть
информацию о транспортном средстве на карте, например, маршрут
передвижения за заданное время. Для выдачи информации на карте также
используются данные, полученные от Юнита. Шестой сущностью будет
отрисовка объекта на карте.
Таким образом, из ПО на 0 уровне абстракции были выделены такие
сущности, как «Юнит», «данные с GPS», «данные с датчиков»,
«администратор и диспетчер», «отчет» и «отрисовка объекта на карте».
На рисунке 1.1 приведена диаграмма «сущность-связь» для нулевого
уровня абстракции для разрабатываемой автоматизированной системы
диспетчерского наблюдения.
18
Рисунок 1.1 – Диаграмма «сущность-связь» для АСДН
1.1.2.5 Ограничения по использованию АСДН
При использовании разрабатываемой автоматизированной системы
диспетчерского наблюдения будут существовать некие ограничения.
Рассмотрим их.
- Скорость обработки информации.
19
Максимальный эффект обработки информации достигается при работе
с количеством транспортных средств не более 100. Так при запросе отчета о
100 транспортных средствах за 1 месяц отчет будет строиться около 1 часа.
Если потребуется отчет о 100 транспортных средствах за 1 день, то он
построится значительно быстрее. Или же отчет об одном транспортном
средстве за 1 месяц также будет построен быстро. Но такое ограничение
существует только для построения отчетов. На карте информация
выводиться относительно быстро в любом из случаев.
- Емкость накопителей информации.
Здесь ограничение зависит от жесткого диска, установленного на
компьютере, на котором используется программа.
- Использование платформ.
Для работы с автоматизированной системой диспетчерского
наблюдения потребуется установленная на компьютере платформа Windows,
а конкретней, Windows 2000 и Windows XP. Такое ограничение присутствует
по причине более популярного использования платформы Windows по
сравнению с платформой Linux/Unix.
- Использование СУБД.
Автоматизированная система диспетчерского наблюдения будет
использовать СУБД SQLServer, поэтому ограничения по данной части будут
зависеть только от возможностей данной СУБД.
- Ограничения по карте.
Также будет существовать некоторое ограничение по использованию
карты. То есть для ее использования нужно будет иметь специализированный
картографический
сервер. Также
будут существовать
небольшие
ограничения на самой карте, в том смысле, что на карте будет иметься строго
определенное достаточно небольшое количество функциональных кнопок:
увеличение, уменьшение, информация о местности, центрирование и др..
1.1.3 Существующие системы
Анализ существующих систем проведем на основе сравнения разных
проектов
систем
диспетчеризации,
разработанных
в
области
геоинформационных систем.
1.1.3.1 Система диспетчеризации работы такси на базе GPS
устройств WK Taxi Vision
Принцип построения системы диспетчеризации работы такси основан
на базе оборудованных специализированными GPS/GPRS/GSM устройствами
автомобилей и программного обеспечения диспетчерского центра.
Система диспетчеризации работы такси на базе специализированных
GPS/GPRS/GSM устройств разработана для автоматизации процесса
регистрации, организации и сопровождения выполнения поступающих
20
заказов на таксомоторное обслуживание централизованным Диспетчерским
центром.
Заявки на таксомоторное обслуживание поступают в Диспетчерский
центр средствами стационарной и мобильной телефонной связи, через
Интернет (при необходимости развертывается call-центр).
Система диспетчеризации работы такси предназначена для достижения
следующих целей:
- сократить временные и эксплуатационные затраты на процесс
диспетчерского сопровождения процесса таксомоторных перевозок,
за счѐт автоматизированного процесса управления таксомоторными
перевозками, сокращения времени на обслуживания заказов,
модернизации технологических решений
централизованного
процесса учета, контроля, управления и обработки показателей
процесса таксомоторных перевозок;
- повысить производительность труда диспетчеров за счет
увеличения количества обработанных заявок и расширения
функциональных обязанностей;
- исключить вероятность потери заказов;
- исключить вероятность оставления заказов без обслуживания;
- исключить ошибки при предоставлении информации руководству;
- исключить вероятность отсутствия информации о выполнении
заказов таксомоторного обслуживания;
- обеспечить централизованный доступ к данным по всем
показателям;
- создать информационную базу для финансовых расчетов между
участниками таксомоторного обслуживания с учѐтом всех
необходимых критериев;
- создать информационную базу для расчета диспетчерской
заработной платы и надбавок к ним с учѐтом всех необходимых
критериев.
Подсистема «Прием заказов» осуществляет автоматизированный
прием заказов и регистрацию по вызову такси, просчет стоимости поездки,
контроль подачи автомобилей по адресу заказа.
Подсистема «Выполнение заказов» обеспечивает выбор и подачу
автомобиля по адресу заказа, обеспечивает автоматический учет и
сопровождения выполнения заказа по маршруту прохождения машины, в том
числе и показатели тарификации поездки с учетом территориальных зон,
времени суток, категорий пассажиров.
Подсистема «Визуализация такси на карте» обеспечивает мониторинг
местоположения такси, территориальную привязку свободных такси к
адресному пространству заказов на обслуживание и др.
Подсистема «Мобильный терминал такси» функционирует на
мобильном устройстве в салоне такси и реализует двунаправленный
интерфейс водителя такси с серверной частью системы. Подсистема
обеспечивает:
21
- определение координат пребывания такси и передачи этой
информации в Диспетчерский центр;
- речевую связь диспетчер-водитель;
- использование функциональных клавиш – «Свободен», «Занят»,
«Запрос на связь», «Тревога» и др.
- пересылку текстовых сообщений и другой служебной информации;
- индикацию стоимости проезда;
- и другую актуальную информацию.
Подсистема «GPRS сервер» обеспечивает управление и обмен
информацией с мобильными терминалами такси.
Подсистема «Портал отчетов и справок» обеспечивает доступ к
информации системы и построение справок, отчетов.
Использование системы: применяется в Европе и Америке.
Ближайшие реализованные проекты для такси - Чехия, Румыния.
По такому принципу в Украине построена система для городской
скорой помощи и несколько систем для предприятий.
Состав системы:
- БС – ретранслятор DR3000 (в цифровом режиме 2 канала, в
аналоговом – 1 канал) + АФУ;
- пользователи – мобильные радиостанции DM3400 (без GPS),
DM3401(c GPS) + антенны;
- сервер + РМ диспетчера на основе современных, стандартных ПК;
- радиостанция для сервера – 1 шт. на канал;
- ПО управления, диспетчеризации + лицензии на РМ (в зависимости
от комплектации функционала ПО: карты, позиционирование,
текстовые сообщения, телеметрия, голос, запись, телефония и т.д.);
- все ретрансляторы системы должны быть соединены через IP (64
kbps min);
- сервер устанавливается в радиозоне системы и должен быть связан
с РМ диспетчера по IP (VPN);
- зона покрытия системы зависит от высоты подвеса системы;
- система позволяет все виды вызовов.
Архитектура построения системы «клиент-сервер»:
- обеспечивает одновременный доступ ко всем подсистемам с любого
диспетчерского места;
- обеспечивает
масштабирование
системы
по
количеству
диспетчерских мест и работающих такси;
- позволяет одновременно выполнять функции приема заказов,
выполнения заказов, анализ выполненной таксомоторной работы,
построение отчетов одному диспетчеру или распределять эту
работу между несколькими диспетчерами.
На схеме развертывания системы, приведенной на рисунке 1.2,
изображен Диспетчерский центр системы, состоящий из серверного
оборудования, рабочих мест диспетчеров и при необходимости call-центра.
22
Диспетчерский центр
Клиент
Диспетчер такси
Сервер диспетчерской
Подсистема Прием
заказов
Подсистема Выполнения
заказов
Диспетчер такси
Диспетчер такси
GPRS /GSM /GPS
Подсистема
Визуализации такси на
карте
Подсистема GPRS
сервер
Подсистема
Мобильный терминал
такси
Подсистема Портал
отчетов и справок
Call-центр
Рисунок 1.2 – Схема развертывания системы WK Taxi Vision
На серверном оборудовании (состоящем из 2 серверов) под
управлением системы Windows Server 2008 размещена база данных MS SQL
2005 и специальное программное обеспечение системы.
На рабочих станциях диспетчеров, работающих под управлением MS
Windows XP, размещено клиентское программное обеспечение.
Подвижной состав такси оборудован мобильными терминалами,
настроенными на обмен информацией и речевой связью с диспетчерским
центром. Мобильные терминалы функционируют под управлением
программной подсистемы «Мобильный терминал такси» реализуя функции
таксофона, дисплея, пульта управления и средства речевой связи.
Преимущества данной системы:
- гибкая структура построения;
23
- диспетчерские места легко размещаются в любой точке Украины и
других странах;
- дешевизна ПО;
- полное соответствие функционалу такси.
Недостатки системы:
- высокая стоимость оборудования такси;
- затратное содержание инфраструктуры связи.
1.1.3.2 Система
диспетчеризации
работы
пассажирского
транспорта (троллейбусов, автобусов)
Система предназначена
для
диспетчерского
управления
и
автоматизированного
контроля за
работой
городского
наземного
пассажирского транспорта путем передачи в диспетчерский центр
координатной GPS-информации о положении городского транспорта,
отображение этой информации на электронной карте и обработки
полученной
и
сопутствующей
информации
на 2-х
уровнях:
автотранспортных предприятий и Центральной диспетчерской станции.
Общая структура рассматриваемой системы представлена на
рисунке 1.3.
Рисунок 1.3 – Общая структура системы диспетчеризации работы
пассажирского транспорта
24
Подсистема «Программное обеспечение центральной диспетчерской
станции» обеспечивает реализацию следующих основных функций:
- внесение информации об изменениях в планах транспортной
работы;
- введение диспетчером и регистрация текстовых команд и
сообщений водителю;
- прием, регистрация и отображение сообщений от водителя;
- ведение суточной ведомости;
- контроль за выполнением расписания движения;
- контроль двойного интервала;
- контроль за наличием данных, которые должны поступать для
контроля за транспортом;
- контроль состояния наличия подвижной единицы на линии в
течение суток;
- анализ текущего состояния движения на конкретном маршруте;
- отображение расписания движения;
- анализ текущего состояния работы конкретной подвижной
единицы;
- анализ текущего состояния работы конкретной подвижной единицы
в течении суток;
- анализ статистики сбоев и отказов по движущимся объектам и
контрольным пунктам;
- регистрация внештатных ситуаций.
Проблемы для срочного решения:
- построить адекватную потребностям системы диспетчеризации
работы пассажирского транспорта среду эксплуатации, особенно в
части коммуникаций (Интернет, корпоративная сеть);
- оборудовать мобильными терминалами 1-2 маршрута полностью,
или решить вопрос, как внедрять систему диспетчеризации работы
пассажирского
транспорта при
частичном
оборудовании
маршрутов;
- определить
эксплуатационный
персонал,
а также
лиц,
уполномоченных решать вопросы согласования и составления
расписания, загрузки его в систему диспетчеризации работы
пассажирского транспорта, отслеживание выполнения и т.п.).
1.1.3.3 Информационная система спутникового мониторинга
субъекта «Мобилочка»
Система предназначена для контроля и анализа деятельности
подвижной единицы путем сбора и передачи данных для отображения их на
карте и построения отчетов.
Базовое решение информационной системы и принцип взаимодействия
цепи «субъект-передача данных-картографический сервер-просмотр трека и
отчетов» показаны на рисунке 1.4.
25
Рисунок 1.4 – Базовое решение информационной системы
Принцип работы системы:
Субъекту мониторинга выдается GPS-логгер, который определяет
координаты транспортного средства и записывает пройденный путь.
Просмотреть треки можно, загрузив данные с подключенного к компьютеру
26
GPS-логгера на картографический сервер через программу управления GPS
устройством. Для автомобилей информационной системы «Мобилочка»
используется GPS навигатор Holux M-1000C, данные которого считываются
и конвертируются в необходимый для работы с картографическим сервером
формат программой M1000C-Manager, разработанной компанией ИСГЕО.
Программное обеспечение на карте отображает маршрут движения, скорость,
остановки, длительность остановки. Информация выводится в виде треков, а
также в табличном виде.
Техническое обеспечение:
- GPS-логгер Holux M-1000C – выдается субъекту мониторинга;
- картографический сервер, подключенный к Интернету;
Информационное обеспечение:
- База данных системы;
- Пространственная БД – карта Украины и городов (единая карта);
Системное программное обеспечение:
- ОС Win 2003 server;
- СУБД SQL Server;
- MS Office (используется при формировании отчетов);
Прикладное программное обеспечение:
- программа управления GPS устройством M1000C-Manager, которая
поставляется вместе с GPS-логгером;
- модуль ведения справочников;
- построитель отчетов;
- программа отображения треков и редактирования «точек встреч» на
карте.
Базовые возможности программного обеспечения:
- получение треков от субъектов мониторинга (электронной почтой,
или непосредственной загрузкой на картографический сервер);
- просмотр треков выбранного автомобиля по дате, времени и
количеству точек;
- настраивание отображения треков с помощью фильтров;
- добавление/удаление на треке точки-встречи с указанием времени,
имени лица, с которым произошла встреча, и комментариев;
- просмотр отчета о пробеге автомобиля, количестве точек, в которых
были определены координаты транспортного средства, времени
начала и окончания движения;
- просмотр отчетов о движении: маршруты, скорость, пробег,
остановки, стоянки;
- просмотр списка встреч.
1.1.3.4 Сравнительный анализ
Подводя итоги анализа существующих систем, можно заметить, что
системы, в принципе, если и удобны, то только для определенных
предприятий.
27
Проведем сравнительный анализ рассмотренных существующих
систем (WK Taxi Vision, СДРПТ, Мобилочка) и разрабатываемой АСДН по
некоторым функциональным критериям (таблица 1.1).
Таблица 1.1 – Сравнение систем диспетчеризации
WK Taxi
Vision
СДРПТ
Мобилочка АСДН
Наличие свободного
расписания
+
-
+
+
Наличие свободного
маршрута
+
-
+
+
Определение адреса
остановки, парковки
-
-
+
+
Передача сигнала в on-
line режиме
+
+
-
+
Визуализация на карте
+
+
+
+
Распределение
наблюдения за
транспортным
средством
-
-
-
+
Наблюдение за
скоростью
передвижения ТС
-
-
-
+
Наблюдение за
расходом топлива
-
-
-
+
Наблюдение за
наличием топлива в
баке
-
-
-
+
Наблюдение за
сливом/заправкой
-
-
-
+
Реагирование на
несанкционированный
запуск двигателя или
открытие дверей
-
-
-
+
Сообщение тревоги
Водитель
диспетчеру
по
голосовой
связи
Водитель
диспетчеру
посредством
SMS-
сообщения,
цвет и звук
которого
можно
настроить
-
Просто
кнопка
тревоги
28
1.1.3.5 Выводы
При сравнении приведенных существующих систем диспетчеризации с
разрабатываемой автоматизированной системой диспетчерского наблюдения
можно заметить, что существующие системы выполняют только
минимальный набор требований, разработанных для какого-то конкретного
случая, а разрабатываемая автоматизированная система диспетчерского
наблюдения выполняет все приведенные функции, то есть является
практически универсальной. Также из таблицы сравнений видно, что
существующие системы никак не следят и не влияют на такие ситуации, как
мошенничество или угон транспортного средства, по сравнению с АСДН.
1.1.4 Общие требования к АСДН
Разрабатываемая
автоматизированная система диспетчерского
наблюдения за движением наземного транспорта должна будет создать
условия эксплуатации автотранспортных средств, которые обеспечивают
постоянный оперативный контроль за местонахождением транспортного
средства. Система должна обеспечить наблюдение за перемещением
транспортного средства со стороны диспетчера, соблюдение режима
эксплуатации транспортного средства, в том числе предотвращение
возможности угона автомобилей во время стоянки, нападения на водителей
транспортных средств, пассажиров или лиц, которые сопровождают людей
или грузы, допустимое правилами использование топлива. Введение данной
системы в эксплуатацию позволит для ее пользователей обеспечить
постоянное диспетчерское наблюдение за движением транспортных средств,
снизить время вызова или прибытия групп реагирования в экстренных
случаях.
Навигационные спутниковые (GPS) системы обеспечивают водителю
решение многих навигационных задач, а именно: определение своего места
нахождения, выбор оптимального маршрута, дистанционный контроль
состояния автомобиля, дистанционный контроль состояния функциональных
особенностей
специальных
автомобилей
(транспорта спецгрузов,
инкассаторских авто и т.п.), определение места нахождения автомобиля при
угонах и т.п.
На структурной схеме (рисунок 1.5) показан предполагаемый вариант
работы системы.
Структурные элементы:
ДЦ – диспетчерский центр;
АВ – автомобиль.
Функциональные элементы системы:
1 – компьютер с цифровой топографической картой и программным
обеспечением;
2 – модем диспетчерского центра;
3 – блок на автомобиле;
29
4 – датчики (например, датчик, реагирующий на открытие двери
автомобиля и т.п.);
5 – исполнительный элемент;
6 – антенна GPS:
7 – оператор мобильной связи;
8 – телефон владельца автомобиля;
9 – диспетчерский центр службы безопасности;
10 – средства связи между диспетчерским центром и диспетчерским
центром службы безопасности (мобильная, обычная телефонная или иная);
11 – средства связи между диспетчерским центром и телефоном
владельца автомобиля (мобильная или обычная телефонная);
12 – радиоканал между диспетчерским центром и автомобилем в
режиме SMS (Short Message Service);
13 – радиоканал между оператором мобильной связи и автомобилем.
Рисунок 1.5 – Структурная схема
Система должна будет работать следующим образом:
Автомобиль оснащен антенной GPS и блоком связи. Ко входу блока
подключаются датчики, которые входят в состав популярных автомобильных
сигнализаций, например, те, которые срабатывают на несанкционированный
запуск двигателя, открытие дверей и т.п.. А выход блока подключен к
исполнительному элементу, например, реле зажигания двигателя или
включение сирены.
Диспетчерский центр оборудуется компьютером, в котором заложены
цифровые топографические карты и программное обеспечение. К
компьютеру подключен модем в стандарте GSM-900 и обычный модем.
Радиосвязь
между
автомобилем
и
диспетчерским центром
обеспечивается с помощью оператора мобильной связи в стандарте GSM-900
в режиме SMS. Существует два варианта связи:
- между АВ та ДЦ с помощью SMS сообщений;
ДЦ
1
2
АВ
6
3
5
4
7
8
9
10
11
12
13
30
- между АВ и оператором мобильной связи с помощью SMS
сообщений, а ДЦ получает/передает эти сообщения с помощью
соединения з сервером SMS сообщения с помощью HTTP
протокола.
При несанкционированном открытии дверей и угоне автомобиля
срабатывает сигнализация, которая подает сигнал на блок автомобиля. Блок
связи передает в диспетчерский центр сигнал, причину, координаты
автомобиля и другие параметры. Эта информация через модем, поступает в
компьютер, где на экране монитора (на цифровой карте) высвечивается
символ автомобиля и вся информация о нем (тип, цвет, государственный
номер, Ф.И.О. владельца и другая необходимая информация). По данному
запросу диспетчер должен связаться с диспетчерским центром службы
безопасности (ГАИ) и с владельцем автомобиля, для принятия мер по
задержанию автомобиля. Кроме этого, диспетчер должен направить сигнал
для остановки автомобиля (принудительное отключение двигателя). С
помощью программного обеспечения весь процесс может быть
автоматизирован.
Разрабатываемая система будет иметь далекую перспективу и широкий
круг пользователей, а именно:
- Для охраны:
1) приватных автомобилей;
2) банковских (инкассаторских) автомобилей;
3) такси;
4) городского транспорта (особенно в часы «пик», после массовых
мероприятий, футбола и т.п.);
5) автомобилей, которые перевозят ценные и опасные грузы;
- Для наблюдения и управления движением:
1) маршрутными такси междугородних перевозок;
2) автомобилями ГАИ;
3) автомобилями вневедомственной охраны;
4) автомобилями скорой помощи;
5) пожарными автомобилями;
6) автомобилями экстренной помощи;
7) перевозкой грузов, как по Украине, так и за рубежом.
В процессе движения транспортного средства проводится запись
координат точек маршрута движения с указанием времени их прохождения,
фиксирование открытия и закрытия дверей, показания датчиков, отключение
питания от БНП.
После возвращения из рейса проводится обработка записанных данных
на компьютере с использованием цифровой карты маршрута. Это позволяет
получить достоверную картину движения и действий обслуживающего
персонала, зафиксировать факт схода с установленного маршрута, оценить
время и место задержек, момент и место слива топлива (для бензовозов),
проб обесточивания устройства и других подобных действий.
31
Накопленная статическая информация позволяет потом провести
оптимизацию маршрутов, повысить безопасность и экономичность
перевозок.
Учитывая
все
вышесказанное,
разработка
проектируемого
программного комплекса предназначена для обеспечения быстрой обработки
информации, которая поступает от мобильных объектов, а также для
управления автомобилями и автоперевозками.
1.2 Анализ требований к интерфейсу АСДН
Конечными
пользователями
автоматизированной
системы
диспетчерского наблюдения являются пользователи без особенных
потребностей относительно ее использования.
Также рассмотрим и примем во внимание такие характеристики
проекта, как частота использования системы, язык интерфейса.
По поводу частоты использования разрабатываемой АСДН, то эта
характеристика зависит от режима работы предприятия. То есть если
предприятие работает круглосуточно, например, скорая помощь, милиция, то
система будет работать круглосуточно.
Язык интерфейса в разрабатываемой системе русский, но добавление
новых языков возможно в процессе дальнейшей разработки АСДН.
1.3 Анализ требований к аппаратной части АСДН
Современная автоматизированная система диспетчерского наблюдения
за городским общественным транспортом предполагает использование
технологий спутниковой навигации GPS.
Как правило, для этого общественный транспорт должен быть оснащен
специальными устройствами с функцией обеспечения мобильной связи в
сети существующего оператора.
Оборудование предназначено для накопления и передачи информации
о передвижении, а также для организации двухсторонней связи водителя с
диспетчером. Каждое устройство имеет свой регистрационный номер, что
позволяет отслеживать местоположение конкретного пассажирского
транспортного средства.
Данные о прохождении маршрута фиксируются в памяти устройства.
По заданному временному интервалу или по факту прохождения
контрольного пункта собранная информация посредством беспроводных
технологий GPRS передаѐтся на аппаратный комплекс центрального
диспетчерского пункта, откуда обеспечивается поступление коротких
формализованных и экстренных циркулярных сообщений (отчетов),
ввод/вывод текущих данных, двухсторонняя радиотелефонная связь и пр.
Диспетчер в режиме он-лайн отслеживает движение пассажирских
транспортных средств (в том числе и визуально), принимает оперативные
32
решения в случае возникновения внештатных ситуаций, формирует отчѐт о
работе подвижного состава (отклонение от графика, суммарное время работы
и другие требуемые показатели).
Используемые GPS-приемники находятся на связи с орбитальными
спутниками системы глобального позиционирования (GPS) и позволяют в
режиме реального времени отследить, где находится автобус или троллейбус,
по какому маршруту движется.
Кроме того, глобальная спутниковая система значительно упростит
работу водителей. Например, все водители могут ориентироваться на
текущее, синхронизированное с сервером, а значит, единое для всех время.
Также есть возможность следить за графиком движения – насколько автобус
или троллейбус опережает или наоборот отстает от него. Передать водителю
важную информацию с диспетчерского пункта можно с помощью голосовой
связи или SMS-сообщений.
Основными преимуществами навигационной системы являются:
- глобальность и беспрерывность контроля во времени и
пространстве;
- высокая универсальность и гибкость при развитии и формировании
маршрутной сети;
- организация контроля маршрутного движения в любой местности,
доступной для средств радиосвязи;
- обмен
оперативными
сообщениями
между
водителем
контролируемого транспортного средства и диспетчером системы в
любой момент времени и в любой точке пространства, доступной
для применяемых средств радиосвязи;
- определение
точного
местонахождения
контролируемого
транспортного средства и его отображение на электронной карте
местности.
Всѐ это позволяет на качественно новом уровне решать комплекс таких
актуальных задач, как обеспечение безопасности пассажиров в пути,
своевременное предоставление медицинской помощи при дорожно-
транспортных происшествиях. В целом же оперативный контроль
выполнения расписания движения транспорта, возможность срочной замены
вышедшего из строя подвижного состава на маршруте, упорядочение и
координация государственных, частных и муниципальных перевозок
обеспечивают повышение качества доставки пассажиров.
К тому же соблюдение режимов движения увеличивает ресурс
двигателя, шин, тормозной системы, других узлов и агрегатов, приводит к
снижению потребления топлива, расходов при техническом обслуживании.
С помощью GPRS-системы обеспечивается социальная и правовая защита
водителей посредством объективного и точного документирования объѐма
выполненных работ, подлежащих оплате.
33
1.4 Постановка задачи на разработку АСДН
В результате проведения анализа предметной области, рассмотрения и
сравнения уже существующих систем определим цель и задание работы.
Целью создания разрабатываемой системы является наблюдение и
автоматизированный контроль за работой наземного пассажирского и
технологического транспорта путем передачи в диспетчерский центр
координатной GPS-информации о положении контролируемых подвижных
единиц транспорта, отображения этой информации на электронной карте,
представления всей аналитической информации в удобном для
соответствующих специалистов виде.
Для решения задачи существенного повышения качества обслуживания
населения и эффективности использования транспортных средств заданием
системы автоматизированного диспетчерского наблюдения является:
- своевременная разработка сбалансированных плановых заданий на
транспортную работу для предприятия в целом, его филиалов,
типов транспорта, направлений, видов перевозок, маршрутов и т.п.;
- обеспечение средствами эффективного выполнения этих планов, за
счет построения системы оперативного управления движением и
контроля выполнения транспортной работы подвижных единиц на
линии, в том числе с использованием средств разговорной связи
диспетчер - водитель, водитель - диспетчер;
- организация системы учета и аналитической обработки совокупной
информации о выполненной транспортной работе для оценки
эффективности и качества работы как предприятия в целом, так и
его филиалов, видов транспорта, маршрутов, водителей, т.д.;
- формирование обратной связи для оперативной корректировки
плановых заданий, организации информационного обмена
с
другими информационными
системами предприятия для
построения эффективной модели управления предприятием.
1.4.1 Требования к программной части АСДН
Чтобы
определить
требования
к
программной
части
автоматизированной системы диспетчерского наблюдения, разделим их на
две области: функциональную и нефункциональную.
1.4.1.1 Функциональные требования
По результатам анализа задач, заданий и проблем, которые должна
решать разрабатываемая автоматизированная система диспетчерского
наблюдения, определим основные функциональные требования, которые
должна выполнять программная подсистема.
34
Для упрощения рассмотрения функциональных требований, вынесем
их на UML-диаграмму (рисунок 1.6) и рассмотрим подробнее каждую из
функций.
Рисунок 1.6 – Функциональные требования к программной части
- Функции администрирования:
1) ведение ролей (добавление, удаление, редактирование роли) –
администратор может добавить новую роль, либо редактировать
(изменить) права этой роли, либо вовсе ее убрать;
2) ведение пользователей (добавление, удаление, редактирование
пользователя) – администратор имеет право добавить нового
пользователя,
например,
оператора,
редактировать
существующую информацию о нем, либо удалить пользователя,
например, при увольнении;
3) ведение соответствия роли и пользователя – администратор
может назначить роль пользователю, либо переназначить
(поменять), например, оператора назначить администратором на
время ухода другого администратора в отпуск;
4) определение доступа к возможностям – администратор может
определить разным ролям разные доступы к каким-либо
35
функциям (возможностям), например, разрешить какой-либо
роли работу с картой или запретить;
- Функции ведения базы данных:
1) ведение транспортного средства (добавление, удаление,
редактирование ТС) – пользователь может добавить новое
транспортное средство с введением всех данных о нем,
например, регистрационный номер, марка транспортного
средства и т.д.. Также эти данные можно отредактировать, либо
удалить транспортное средство, например, в случае выхода из
эксплуатации;
2) ведение списка водителей, прикрепленных к транспортным
средствам (добавление, удаление, редактирование списка
водителей) – пользователь имеет право добавить нового
водителя, редактировать данные о нем, либо удалить, например,
в случае увольнения из предприятия;
3) ведение списка юнитов, прикрепленных к транспортным
средствам (добавление, удаление, редактирование списка
юнитов) – пользователь может добавить новый юнит,
редактировать данные о нем, либо удалить, например, в случае
выхода из эксплуатации;
4) определение соответствия юнита транспортному средству
(добавление, удаление, редактирование соответствия) –
пользователь
может
добавить
соответствие
юнита
транспортному средству, удалить, либо редактировать,
например, при выходе из эксплуатации юнита, на транспортное
средство устанавливают новый юнит;
5) определение соответствия водителя транспортному средству
(добавление, удаление, редактирование соответствия) –
пользователь
может добавить
соответствие водителя
транспортному средству, удалить, либо редактировать,
например, при увольнении водителя, к транспортному средству
«привязывают» нового водителя;
- Функции работы с картой:
1) произвести поиск – пользователь может попытаться найти
какой-либо объект на карте, нажав на соответствующую кнопку
и в появившемся окне выбрать, что он ищет и ввести название
объекта;
2) обновить изображение – пользователь может обновить
изображение на карте, нажав соответствующую кнопку;
3) показать всю карту – пользователь может вернуться в
изначальный масштаб и центрирование той карты, на которой
находится, нажав на соответствующую кнопку;
4) центрировать – пользователь может перенести любую точку на
карте в центр монитора, нажав на соответствующую кнопку и
затем нажав курсором на желаемую точку на карте;
36
5) выбор карты – пользователь может выбрать карту желаемого
города, выпадающую из списка;
6) построение отчета на карте – пользователь может получить
отчет по дате или за период, а также последнее местоположение
транспортного средства, в которых будет получена информация
о времени фиксирования транспортного средства, широта,
долгота, направление движения, скорость автомобиля и т.д.;
7) показать информацию о местности – пользователь может узнать
информацию о местности, например, широта и долгота, нажав
на соответствующую кнопку и затем нажав курсором на
желаемую точку на карте;
8) изменение масштаба карты (увеличение и уменьшение) –
пользователь может увеличить/уменьшить масштаб карты,
нажав на соответствующую кнопку (+/-) и выделив курсором
область для увеличения/уменьшения;
9) специализированные функции:
а) мониторинг использования транспортного средства по дате –
пользователь может просмотреть некоторую информацию об
использовании транспортного средства прямо на карте, задав
определенную дату и выбрав одно или несколько
транспортных средств;
б) мониторинг использования транспортного средства по
периоду – пользователь может просмотреть некоторую
информацию об использовании транспортного средства
прямо на карте, задав период времени (начальную и
конечную дату) и выбрав одно или несколько транспортных
средств;
в) мониторинг использования транспортного средства по
последнему местоположению – пользователь может
просмотреть некоторую информацию об использовании
транспортного средства прямо на карте, задав необходимое
количество последних точек местоположения транспортного
средства и выбрав одно или несколько транспортных
средств;
- Функции просмотра результатов:
1) просмотр логов (журналов) – пользователь может просмотреть
логи, которые содержат данные об отправленных операторами
командах юнитам;
2) просмотр запросов – пользователь может построить запрос к
базе данных объектов, который при выполнении выдаст таблицу
с данными о запрашиваемом объекте.
37
1.4.1.2 Нефункциональные требования
По результатам анализа задач, заданий и проблем, которые должна
решать разрабатываемая автоматизированная система диспетчерского
наблюдения, определим основные нефункциональные требования, которые
должны присутствовать в разрабатываемой автоматизированной системе
диспетчерского наблюдения:
- обеспечить безопасный доступ к Интернету;
- реализовать разделенный доступ пользователей системы к
защищенным объектам системы и защищенным функциям;
- достичь максимальной отказоустойчивости механизма, так как
разрабатываемая система может использоваться долгий период
времени, даже круглосуточно;
- обеспечить возможность устранения недостатков в существующих
функциональных возможностях, не оказывая влияния на другие
компоненты, адаптацию к новой среде функционирования;
- максимально повысить производительность или улучшить другие
характеристики программного обеспечения;
- обеспечить достаточную мощность для обслуживания большего
количества транспортных средств.
1.4.2 Требования к аппаратной части АСДН
Юнит, установленный на транспортном средстве должен иметь:
- контроллер управления и обработки данных;
- модем GPRS/GSM;
- антенну GPRS/GSM;
- GPS-приемник;
- антенну GPS-приемника.
Основные особенности требований к GPS-приемнику:
- работа в режиме реального времени;
- контроль зажигания и напряжения бортовой сети;
- подключение датчиков уровня и расхода топлива;
- подключение кнопки "тревога";
- контроль открытия дверей.
1.5 Выводы
В данном разделе был выполнен детальный анализ предметной
области, проведено построение базовой модели ПО, произведен анализ
существующих в данной предметной области решений, анализ требований к
программной и аппаратной частям разрабатываемой автоматизированной
системы диспетчерского наблюдения и выполнена постановка задачи на
разработку АСДН.
38
2 РАЗРАБОТКА АВТОМАТИЗИРОВАННОЙ СИСТЕМЫ
ДИСПЕТЧЕРСКОГО НАБЛЮДЕНИЯ
2.1 Выбор технических средств построения АСДН
В данном разделе будет выбрана среда разработки, проведен выбор
хранилища данных, средств для реализации бизнес-логики, слоя
представления, безопасности.
2.1.1 Среды разработки
Для проектирования программных комплексов необходимо наличие
интегрированной среды (IDE). На данный момент существует широкий
выбор сред для разработки программ. Для решения поставленных целей
определенных в техническом задании были выбраны следующие среды
разработки:
MicrosoftVisualStudio
2010
–
линейка продуктов компании
Майкрософт,
включающих
интегрированную
среду
разработки
программного обеспечения и ряд других инструментальных средств. С
помощью
VisualStudio
2010
имеется возможность
разрабатывать
программное обеспечение, для расширения пакета приложений
MicrosoftOffice 2003 и SharePoint 2003 и более поздних версий. Новая версия
программы позволяет легко создавать приложения для последних версий
Windows;
Eclipse – свободная интегрированная среда разработки модульных
кроссплатформенных
приложений.
Развивается и
поддерживается
EclipseFoundation. Eclipse является программным обеспечением с открытым
исходным кодом. Eclipse в первую очередь полноценная Java IDE,
нацеленная на групповую разработку: среда интегрирована с системами
управления версиями – CVS в основной поставке, для других систем
(например, Subversion, MS SourceSafe) существуют плагины. В силу
бесплатности и высокого качества, Eclipse во многих организациях является
корпоративным стандартом для разработки приложений;
NetBeans IDE – свободная интегрированная среда разработки
приложений (IDE) на языках программирования Java, JavaFX, Python, PHP,
JavaScript, C++, Ада и ряде других. NetBeans IDE поддерживает плагины,
позволяя разработчикам расширять возможности среды. NetBeans IDE
расширяет возможности Java EE (включая поддержку JavaPersistence, EJB 3 и
JAX-WS). Дополнительно, NetBeansEnterprisePack поддерживает разработку
приложений Java EE 5 Enterprise, включая визуальные средства SOA,
средства для работы с XML schema, работу с веб-сервисами (для BPEL),
расширений для пакета OpenOffice и моделирование на языке UML.
39
2.1.2 Хранилище данных и средства интеграции
Для хранения и обеспечения целостности пользовательских и других
данных необходима система управления базами данных. В качестве системы
управления базами данных необходимо выбрать продукт, который
представляет собой совокупность программных и лингвистических средств
общего или специального назначения, обеспечивающих управление
созданием и использованием баз данных. Для реализации данных требований
было выбрано следующее программное обеспечение:
SQLServer – система управления реляционными базами данных
(СУБД), разработанная корпорацией Microsoft. Основной используемый язык
запросов — Transact-SQL, создан совместно Microsoft и Sybase. Transact-SQL
является реализацией стандарта ANSI/ISO по структурированному языку
запросов (SQL) с расширениями. Используется для работы с базами данных
размером от персональных до крупных баз данных масштаба предприятия;
конкурирует с другими СУБД в этом сегменте рынка.
Сервер баз данных Microsoft SQL Server в качестве языка запросов
использует версию языка SQL, получившую название Transact-SQL
(сокращѐнно T-SQL). Язык T-SQL является реализацией SQL-92 (стандарт
ISO для языка SQL) с множественными расширениями. T-SQL позволяет
использовать дополнительный синтаксис для хранимых процедур и
обеспечивает поддержку транзакций (взаимодействие базы данных с
управляющим приложением).
При взаимодействии с сетью Microsoft SQL Server и Sybase ASE
используют протокол уровня приложения под названием Tabular Data Stream
(TDS, протокол передачи табличных данных). Протокол TDS также был
реализован в проекте FreeTDS с целью обеспечения различным приложениям
возможность взаимодействия с базами данных Microsoft SQL Server и Sybase.
Для обеспечения доступа к данным Microsoft SQL Server поддерживает
Open Database Connectivity (ODBC) — интерфейс взаимодействия
приложений с СУБД. Версия SQL Server 2005 обеспечивает возможность
подключения пользователей через веб-сервисы, использующие протокол
SOAP. Это позволяет клиентским программам, не предназначенным для
Windows, кроссплатформенно соединяться с SQL Server. Компания Microsoft
также выпустила сертифицированный драйвер JDBC, позволяющий
приложениям под управлением Java (таким как BEA и IBM WebSphere)
соединяться с Microsoft SQL Server 2000 и 2005.
Также SQL Server поддерживает зеркалирование и кластеризацию баз
данных. Кластер сервера SQL — это совокупность одинаково
конфигурированных серверов; такая схема помогает распределить рабочую
нагрузку между несколькими серверами. Все сервера имеют одно
виртуальное имя, и данные распределяются по IP-адресам машин кластера в
течение рабочего цикла. Также в случае отказа или сбоя на одном из
серверов кластера доступен автоматический перенос нагрузки на другой
сервер.
40
SQL Server поддерживает избыточное дублирование данных по трем
сценариям:
- снимок: Производится «снимок» базы данных, который сервер
отправляет получателям.
- история изменений: Все изменения базы данных непрерывно
передаются пользователям.
- синхронизация с другими серверами: Базы данных нескольких
серверов синхронизируются между собой. Изменения всех баз
данных происходят независимо друг от друга на каждом сервере, а
при синхронизации происходит сверка данных. Данный тип
дублирования
предусматривает
возможность
разрешения
противоречий между БД.
В SQL Server 2005 встроена поддержка .NET Framework. Благодаря
этому хранимые процедуры БД могут быть написаны на любом языке
платформы .NET, используя полный набор библиотек, доступных для .NET
Framework, включая Common Type System (система обращения с типами
данных в Microsoft .NET Framework). Однако, в отличие от других процессов,
.NET Framework, будучи базисной системой для SQL Server 2005, выделяет
дополнительную память и выстраивает средства управления SQL Server
вместо того, чтобы использовать встроенные средства Windows. Это
повышает производительность в сравнении с общими алгоритмами Windows,
так как алгоритмы распределения ресурсов специально настроены для
использования в структурах SQL Server.
2.1.3 Средства для реализации бизнес логики
Для выполнения совокупности правил, принципов, зависимостей
поведения объектов предметной
области (области человеческой
деятельности, которую система поддерживает) необходимо реализовать
предметную область в информационной системе. Для этих целей выбрана
спецификация данной технологии являющейся частью JavaEE:
EnterpriseJavaBeans (также часто употребляется в виде аббревиатуры
EJB) – спецификация технологии написания и поддержки серверных
компонентов, содержащих бизнес-логику. Является частью Java EE. Каждая
EJB компонента
является
набором
Java классов со
строго
регламентированными правилами именования методов (верно для EJB 2.0, в
EJB 3.0 за счет использования аннотаций выбор имен – свободный).
Для быстрого и удобного способа создания двухстороннего
преобразования между XML документами и классами языка Java необходимо
средство, которому задавая DTD, компилятор создавал набор классов Java,
содержащий весь код, который необходим для анализа XML документов,
основанных на данной схеме. Для этих целей был выбран набор интерфейсов
Java XML API от SunMicrosystems:
JAXB – представляет собой компилятор на вход который подается
XML-схема или DTD-описание, а на выходе получается структура классов,
41
соответствующая структуре XML-схемы или DTD-описанию. Возможно и
обратное преобразование – из системы объектов получить XML-схему.
2.1.4 Инструментальные средства для проектирования слоя
представления
Для проектирования слоя представления необходимо набор
программных средств, позволяющих удобные и простые средства для
разработки графики и отображения информации на слое представления.
Данные решения должны соответствовать современным требованиям по
разработке приложений с использованием графики. Для данных целей были
выбраны следующие фреймворки:
SmartGWT– это фреймворк, предназначенный для написания веб-
ориентированных приложений на языке Java. Smart GWT представляет собой
пристройку к стандартномуфреймворкуGoogleWebToolkit (GWT) со своим
набором классов. GoogleWebToolkit не только предоставляет набор классов,
упрощающих разработку, но и еще имеет возможность компилирования
проекта в набор JavaScript и HTML файлов. Этот подход имеет множество
преимуществ: во-первых, для запуска такого приложения уже не требуется
наличие виртуальной Java-машины и во-вторых, он дает почти
стопроцентную кросс-платформенность, так как JavaScript на сегодняшний
день поддерживается всеми современными бразуерами, и кросс-
браузерность;
jQuery – библиотека JavaScript, фокусирующаяся на взаимодействии
JavaScript и HTML. Библиотека jQuery помогает легко получать доступ к
любому элементу DOM, обращаться к атрибутам и содержимому элементов
DOM, манипулировать ими. Также библиотека jQuery предоставляет
удобный API по работе с Ajax;
ApacheVelocity– веб-фреймворк с открытым кодом, процессор
шаблонов, один из группы шаблонных движков FreeMarker, webmacro, xmlc.
Удобен тем, что не требует предварительной подготовки модели переменных
для шаблона– в шаблон просто передаются ссылки на java-объекты, а движок
разбирает указанные методы и посредством javareflection получает их
значения. Ранее находился в составе ApacheJakartaProject и был известен как
JakartaVelocity;
Raphaеl – небольшая библиотека для построения векторной графики на
веб-сайтах. Она использует SVG и VML в качестве базы для создания
графики. Учитывая то, что каждый созданный объект – DOM объект, то при
помощи JavaScript обработчиков можно легко изменять их свойства и
действия.
ApachePOI – проект POIApache предназначен для того, чтобы
создавать и поддержать API Java для того, чтобы управлять различными
форматами файлов, основанными на OfficeOpen XML (OOXML) и Microsoft's
OLE 2 CompoundDocumentformat (OLE2). Что предоставляет возможность
42
считывать и записывать MS файлы Excel, MSWord и MS файлы PowerPoint,
используя Java.
2.1.5 Инструментальные средства для обеспечения безопасности
Для
обеспечения
сетевой
безопасности
пользователей
(аутентификации, авторизации) необходима поддержка сетевого протокола,
который поддерживает различные операции по работе с пользователями и их
данными.
LDAP (англ.LightweightDirectoryAccessProtocol
–
«облегчѐнный
протокол доступа к каталогам») – это сетевой протокол для доступа к службе
каталогов X.500, разработанный IETF как облегчѐнный вариант
разработанного ITU-T протокола DAP. LDAP – относительно простой
протокол, использующий TCP/IP и позволяющий производить операции
аутентификации (bind), поиска (search) и сравнения (compare), а также
операции добавления, изменения или удаления записей.
Протокол LDAP был разработан исследователями из Мичиганского
университета для упрощения доступа к сервисам каталогов X.500. Стандарт
CCITT X.500 описывает базовую структуру и функциональную модель
службы каталогов, но он очень сложен и громоздок, а его реализация требует
использования стека протоколов OSI.
2.1.6 Выводы
В данном подразделе были рассмотрены различные среды разработки,
хранилища данных, средства для реализации бизнес-логики, слоя
представления, безопасности. В результате чего средой разработки была
выбрана MicrosoftVisualStudio 2010, хранилищем данных – Microsoft SQL
Server, для обеспечения безопасности системы при эксплуатации будет
разработана собственная подсистема безопасности, где логины и пароли
пользователей будут храниться в собственной базе данных.
2.2 Разработка архитектуры АСДН
Рассмотрим архитектуру
разрабатываемой
автоматизированной
системы диспетчерского наблюдения (рисунок 2.1).
Юнит, который установлен на транспортном средстве, получает
данные от спутника с помощью системы позиционирования GPS и от
датчиков, установленных на транспортном средстве.
Информация о транспортном средстве поступает со спутника (по
антенне GPS-приемника в сам GPS-приемник, который установлен в Юните)
и с датчиков (установленных на транспортном средстве) поступает к Юниту.
Юнит, в свою очередь, обрабатывает полученную информацию с помощью
контроллера управления и обработки данных. Так как в Юнит встроены
43
GPRS/GSM-антенна и GPRS/GSM-модем, то по внешнему IP-адресу
коммуникационного сервера, на который настроен Юнит, через оператора
мобильной связи на коммуникационный GPS-сервер отправляются
обработанные данные. В свою очередь коммуникационный сервер принимает
сообщения от юнита на указанный IP адрес и порт и записывает их в базу
данных, хранящуюся на сервере баз данных. Таким же образом
коммуникационный сервер передает сообщение (запрос или команду) от
оператора на Юнит. К базе данных через главный клиент имеют доступ
операторы предприятия, которые могут вносить в нее изменения. Также к
базе данных через Интернет имеет доступ обычный пользователь, но он
может только просматривать ее.
Рисунок 2.1 – Архитектура АСДН
2.3 Разработка программной подсистемы АСДН
На этапе разработки программной подсистемы произведем
проектирование диаграмм вариантов использования. Затем на основании уже
имеющейся информации выполним проектирование модели данных и
структуры
АСДН,
произведем
описание
основных
аспектов
функционирования АСДН, а также выполним проектирование интерфейса
пользователя и т.д..
44
2.3.1 Определение и описание ролей пользователей АСДН
Разрабатываемая система будет иметь трех акторов: Администратор,
Оператор и Юнит-ТС. Определим данным акторам роли.
Администратор – предоставляет Операторам доступ к функциям
системы, имеет право доступа к администрированию подсистемы
безопасности.
Оператор – ведет наблюдение за Юнитами-ТС (воздействует на Юнит-
ТС) посредством передачи и приема данных и команд через каналы связи.
Юнит-ТС – транспортное средство, оборудованное юнитом. Юнит
принимает сигналы со спутниковой системы навигации GPS, обрабатывает
контроллером и передает их на коммуникационный сервер.
2.3.2 UML-диаграммы вариантов использования АСДН
Рассмотрим варианты использования разрабатываемой системы
сущностями Администратор, Оператор и Юнит-ТС подробнее.
2.3.2.1 Варианты
использования системы для сущности
Администратор
В обязанности Администратора входит настройка прав доступа,
ведение списка ЮНИТ-ТС, конфигурирование системы и аудит системы.
Прецеденты Администратора приведены на рисунке 2.2.
Рисунок 2.2 – UML-диаграмма вариантов использования АСДН для
сущности «Администратор»
45
Администратор является сущностью с наиболее важными и главными
функциональными возможностями. Рассмотрим прецеденты данной
сущности подробнее.
Ведение списка операций (команд), которые выполняются над
защищенными объектами – по отношению к защищенным объектам
разрабатываемой системы могут выполняться некоторые операции или им
могут передаваться команды. Например, для объекта «Юнит» может
выполняться операция «Смотреть трек» и передаваться команда
«Заблокировать двигатель». Такие операции и команды должны быть
определены в системе.
Ведение списка ролей – Администратор определяет процесс
добавления, удаления, редактирования списка ролей, имеющих доступ к
системе.
Назначение пользователю права доступа к защищенным объектам – по
отношению к защищенным объектам разрабатываемой системы могут
выполняться некоторые операции или им могут передаваться команды.
Например, для объекта «Юнит» может выполняться операция «Смотреть
трек» и передаваться команда «Заблокировать двигатель». Система должна
назначать права выполнения операций и команды для пары «пользователь-
объект».
Назначение прав доступа роли к защищенным функциям –
Администратор устанавливает права доступа роли к защищенным функциям.
Ведение списка пользователей системы (добавление, редактирование,
удаление пользователя) – Администратор редактирует список пользователей
и устанавливает соответствие между пользователем и ролью, которую он
может выполнять в системе.
Ведение списка устройств наблюдения, устанавливаемых в
транспортных средствах (добавление, редактирование, удаление устройств
наблюдения) – Администратор формирует в разрабатываемой системе список
Юнитов для установки в транспортные средства.
Ведение списка транспортных средств (добавление, редактирование,
удаление транспортного средства) – Администратор формирует в
разрабатываемой системе список транспортных средств, за которыми ведется
наблюдение.
2.3.2.2 Варианты использования системы для сущности Оператор
В обязанности Оператора входит слежение за Юнит-ТС и выполнение
других операций по эксплуатации системы. Прецеденты Оператора
приведены на рисунке 2.3.
Оператор является сущностью, которая взаимодействует с Юнитом и
«делает основную работу». Рассмотрим прецеденты данной сущности
подробнее.
46
Рисунок 2.3 – UML-диаграмма вариантов использования АСДН для
сущности «Оператор»
Настройка соединения через GSM-модемы – Оператор подключает к
компьютеру с программой управления модемным пулом GSM модемы и
настраивает их для связи с Юнитами-ТС.
Настройка соединения через SMPP – Оператор подключается к
провайдеру, обеспечивающему связь по SMPP.
Настройка соединения через GPRS – Оператор подключается к
провайдеру, обеспечивающему связь по GPRS.
Выбор способа связи с Юнитом-ТС – Оператор выбирает, каким
(одним или несколькими способами) связываться с Юнитом-ТС.
Подача команды Юниту-ТС – Оператор отправляет выбранному юниту
команду для выполнения. Команда выбирается из списка доступных
Оператору команд.
Подготовка макроса команд – Оператор готовит макрос из доступных
ему команд для посылки Юниту-ТС.
Выполнение макроса команд – Оператор выполняет макрос для
выбранного юнита.
Планирование дозвона – Оператор формирует план дозвона к Юнитам-
ТС, к которым имеет доступ.
Дозвон системы к Юнитам-ТС – система обращается к Юнитам-ТС в
соответствии с планами дозвона.
47
Просмотр сообщений от Юнитов-ТС – Оператор просматривает
сообщения от Юнита-ТС и реагирует на них соответствующим образом.
Выбор карты – в окно отображения карты загружается карта,
выбранная из списка доступных для работы.
Построение стандартного отчета – Оператор формирует отчет
стандартной формы из имеющихся форм отчета.
Выполнение некартографического запроса – Оператор формирует
запрос к БД системы с указанием (выбором) сущностей, связей между ними
и условий.
Настройка параметров отображения ТС на карте – по команде
Оператора устанавливаются (set) символы для отображения транспортного
средства на карте.
Отображение на карте одного ТС или группы ТС – на загруженной
карте отображается в виде точечных объектов (или треков) местоположение
одного или нескольких транспортных средств, выбранных оператором из
доступных ему.
Отображение на карте Юнита-ТС в реальном времени – Оператор
устанавливает для выбранного Юнита-ТС режим отображения в реальном
времени.
2.3.2.3 Варианты использования системы для сущности Юнит-ТС
В некоторых случаях Юнит-ТС выступает как внешняя по отношению
к системе сущность, инициирующая взаимодействие. Прецеденты Юнита-ТС
приведены на рисунке 2.4.
Юнит-ТС – это сущность с наименьшими, но очень важными
функциональными возможностями. Рассмотрим прецеденты данной
сущности подробнее.
Данные со спутника – Юнит-ТС принимает данные со спутника и
обрабатывает их с помощью встроенного в него контроллера управления и
обработки данных.
Передача единичного сообщения – Юнит-ТС передает единичное
сообщение вследствие произошедшего события.
Выгрузка лога событий – Юнит-ТС пересылает список событий.
Передача регулярных сообщений – Юнит-ТС передает единичное
сообщение через равные промежутки времени (для слежения в реальном
времени).
Данные с датчиков – Юнит-ТС принимает данные с датчиков,
установленных на транспортном средстве, и обрабатывает их с помощью
встроенного в юнит контроллера управления и обработки данных.
Отправка обработанных данных Оператору – Юнит-ТС отправляет
Оператору обработанные данные при запросе.
48
Рисунок 2.4 – UML-диаграмма вариантов использования АСДН для
сущности «Юнит-ТС»
2.3.3 Структура программной подсистемы АСДН
Описание аспектов поведения системы подразумевает в себе
логическое моделирование процессов, которые будут иметь место в
разрабатываемом комплексе. В данном случае такое описание необходимо
осуществить на основании уже имеющихся наработок по проектированию
различных вариантов структуры и архитектуры системы, а также
рассмотрению ее ключевых объектов в виде диаграмм вариантов
использования. Само по себе понятие аспекта в данном контексте следует
понимать как рассмотрение сущности поведения системы, подсистемы или
какой-либо отдельной функционирующей части системы, ее виденье с
определенных позиций.
Выполнить описание поведения системы можно сделать несколькими
способами:
- выполнить полное описание всех подсистем;
- выделить базовые аспекты.
Сделав полномерное рассмотрение всех подсистем, в итоге можно
получить очень подробную информацию о функционировании системы.
Однако этот подход не представляется возможным для выполнения,
поскольку в рамках дипломного проекта присутствуют ограничения, как в
49
человеческих, так и временных ресурсах. К тому же в случае внедрения
системы возможны некоторые изменения в ветках ее последовательностей и
деятельностей, полное документирование которых на данном этапе
разработки весьма спорно, и если будет полезно, то только для узкого круга
разработчиков. При подходе выделения именно базовых аспектов будет
затронута большая часть функциональности системы, можно достаточно
глубоко вникнуть в суть протекающих в ней процессов, как для
разработчика, пользователя, так и для простого человека, интересующегося
системами диспетчеризации.
Структурная схема взаимодействия подсистем изображена на
рисунке 2.5.
Рисунок 2.5 – Структурная схема взаимодействия подсистем АСДН
50
Как видно на рисунке 2.5 программная часть разрабатываемой
автоматизированной системы диспетчерского наблюдения должна состоять
из таких подсистем:
- подсистема работы с базой данных;
- подсистема работы с картографической информацией;
- подсистема отображения графической информации;
- подсистема отображения текстовой и статистической информации;
- подсистема работы с отчетами;
- подсистема приема данных от транспортного средства;
- подсистема дистанционного управления транспортным средством;
- подсистема удаленного доступа к базе данных.
Опишем основные функции каждой из перечисленных подсистем.
2.3.3.1 Подсистема работы с базой данных
Эта подсистема должна выполнять следующие функции:
- управление данными непосредственно в СУБД (функция
обеспечивает хранение данных, непосредственно входящих в БД, и
служебной информации, которая обеспечивает работу СУБД);
- управление данными в памяти компьютера. Функция связана,
прежде всего, с тем, что СУБД работает с БД большого размера, с
целью ускорения работы СУБД использовать буферизацию данных
в оперативной памяти (или в локальной версии БД). При этом
пользователь СУБД использует только необходимую для работы
информацию, но при необходимости может получить любую
другую информацию;
- управление транзакциями (функция, которая поддерживает
логическую целостность БД). Если транзакция успешно выполнена,
то СУБД производит смену данных в БД, в противном случае
проведенные действия никак не меняют БД;
- управление изменениями в БД и протоколирование. Функция
связана с надежностью хранения данных, то есть возможность
СУБД восстанавливать состояние БД в аварийных случаях,
например, при случайном отключении тока. С этой целью нужно
вести протокол внесения изменений в БД. В нем перед внесением
изменений в БД производится соответствующая запись, которая
содержит старые и новые данные. Для восстановления базы данных
после сбоя СУБД использовать протокол и архивную копию БД;
- обеспечение безопасности базы данных;
- контроль работы пользователей (ведение журнала работы
операторов по форме: оператор, автомобиль, дата и время события,
смысл события, действия оператора на событие и реакция
автомобиля);
51
- локальная версия базы данных должна иметь возможность получать
данные по запросу из главного сервера диспетчерского центра
(данные, непосредственно относящиеся к клиенту).
2.3.3.2 Подсистема работы с картографической информацией
Эта подсистема должна выполнять следующие функции:
- полнота отображения графической информации (отображение
графической информации в таком объеме, чтобы оператор имел
возможность точно определить местонахождение автомобиля и
определить ориентиры (для населенных пунктов: улицы, номера
домов, магазины, государственные учреждения и т.п.; в других
местах (номера дорог, расстояние до ближайших населенных
пунктов или стационарных постов ГАИ)));
- подключение к базе данных новых карт (по использованию);
- масштабирование карт.
2.3.3.3 Подсистема отображения графической информации
Эта подсистема должна выполнять следующие функции:
- точность отображения местонахождения автомобиля (отображение
графической отметки автомобиля на карте должно соответствовать
реальному положению на местности);
- исправление
незначительных
отклонений
отображения
местонахождения автомобиля от картографических объектов (а
именно дорог);
- при необходимости выводить справки различного характера, как и
по автомобилю, так и по стационарным объектам, которые
нанесены на карту (учреждениям, СТО, постам ГАИ, мотелям др.),
а именно географические координаты, адрес, название (для
автомобилей – номер и марку);
- вывод местонахождения автомобиля при возникновении активного
события с центрированием района;
- возможность
выбора
графического
отображения
каждого
автомобиля отдельно (например, для легковых и грузовых
автомобилей различные изображения (силуэт легкового и грузового
автомобиля), а цвет изображения соответствует цвету автомобиля).
2.3.3.4 Подсистема отображения текстовой и статистической
информации
Эта подсистема должна выполнять следующие функции:
- отображение данных, поступающих от транспортного средства в
режиме реального времени или тех, которые анализируются по
прибытии транспортного средства;
52
- получения журнала сообщений, который записывался блоком на
транспортном средстве (координаты объекта, тип, марка, цвет,
государственный номер транспортного средства, дата и время
события; содержание события, состояние всех датчиков и устройств
транспортного средства на время события);
- отображение отчетов по запросам пользователя по тем параметрам,
которые он определит;
- печать, сохранение на диске (в формате HTML, Word, Excel)
информации, отображаемой на экране.
2.3.3.5 Подсистема работы с отчетами
Эта подсистема должна выполнять следующие функции:
- формировать отчеты по запросам пользователей. Два варианта:
а) администратор системы может построить запрос к БД с
помощью SQL-запроса в окне (в текстовом поле вводится
запрос, а в нижней части формы в табличном виде выводится
результат выполнения этого запроса). При этом администратор
должен иметь возможность изменить последовательность
столбцов, определить порядок сортировки данных в таблице
нажатием на шапку таблицы (при этом текст запроса
автоматически должен меняться). Этот запрос хранится в базе
данных для возможности последующего использования
пользователями;
б) оператор или пользователь вызывают перечень существующих
запросов, выбирают нужный, вводят параметры и анализируют
полученные данные;
- иметь первичный перечень реализованных стандартных запросов.
Стандартные отчеты:
- отображение на карте и в таблицах пройденного маршрута (в
динамике, в масштабе реального времени и пошаговое). При
отображении информации графически, та же информация
выделяется в таблице, и наоборот;
- подсчет пройденного пути (в общем, между выбранными пунктами,
между ключевыми точками маршрута);
- общее время движения/остановок транспортного средства.
2.3.3.6 Подсистема приема данных от транспортного средства
Эта подсистема должна выполнять следующие функции:
- система должна работать совместно с таким видом сотовой связи,
как GSM;
- прием сообщений, их занесения в базу данных и сообщение о
происшествии оператору (время отображения информации о
53
событии не должен превышать 5-7 секунд с момента приема этого
сообщения модемом).
Перечень стандартных сигналов, приходящих от транспортного
средства:
- статус транспортного средства;
- подтверждение о выполнении команды;
- получение сигнала тревоги от датчиков системы безопасности
транспортного средства;
- начало/окончание движения транспортного средства;
- нарушение скоростного режима движения транспортного средства;
- нарушение границ района санкционированного использования
автомобиля;
- ручное нажатие кнопки оповещения о тревоге;
- другие сигналы.
2.3.3.7 Подсистема дистанционного управления транспортным
средством
Эта подсистема должна выполнять следующие функции:
- отправка команд управления к автомобилю (время отправления
команды модемом не должно превышать 5-7 секунд с момента
принятия решения оператором);
- направление сообщений клиенту или в службу безопасности
клиента;
- редактирование в диалоговом режиме сигналов и команд
(пользователь должен иметь возможность изменять SMS-
сообщения как те, которые приходят от автомобиля, так и те,
которые отсылает система).
Перечень стандартных команд для изменения SMS-сообщения:
- запрос статуса автомобиля;
- включить/выключить повторную тревогу;
- закрыть/открыть двери;
- открыть капот;
- резко/медленно отключить/включить подачу топлива;
- включить/выключить внутреннее освещение;
- разрешить/запретить активные сообщения;
- включить/отключить наблюдение;
- стереть/скачать сообщения, которые накапливаются.
Список команд и сигналов зависит от типа оборудования
установленного на транспортном средстве, а типовой перечень оборудования
постоянно меняется.
Для ускорения передачи информации к транспортному средству нужно
предусмотреть возможность формировать команды, которые будут
выполнять несколько действий одновременно. Все команды и сигналы имеют
примерно один и тот же формат (координаты, идентификационный код блока
54
на транспортном средстве, состояние датчиков (вкл. или выкл.)). Сигналы
передают состояние всех датчиков, а команды устанавливают новые
значения.
2.3.3.8 Подсистема удаленного доступа к базе данных
На сервере БД устанавливается WEB-сервер. На главной странице
(после аутентификации пользователя) выводится перечень отчетов, которые
находятся в базе данных. Пользователь выбирает нужный отчет, вводит
параметры и получает необходимую информацию (в табличном виде). Эти
действия производятся с помощью HTTP-протокола в сети Интернет.
2.3.4 Разработка базы данных
В данном подпункте будут описаны базовые таблицы базы данных для
автоматизированной системы диспетчерского наблюдения, основанные на
анализе концептуальной модели предметной области.
Для начала определим, какие будут колонки в таблице ролей SS_ROLE
(SS – System Security, таблица с данными по безопасности):
- SS_ROLE_ID – идентификатор роли, тип – int, длина – 10 бит;
- SS_ROLE_NAME – имя роли, тип – varchar, длина – 64 бита;
- SS_ROLE_DESCRIPTION – краткое описание роли, тип – varchar,
длина – 64 бита.
Далее нам нужно определить колонки в таблице, которая будет хранить
информацию о пользователе – SS_USER:
- SS_USER_ID – идентификатор пользователя, тип – int, длина – 10
бит;
- SS_USER_LOGIN – логин пользователя, varchar, 64 бита;
- SS_USER_PASSWORD – пароль пользователя, varchar, 64 бита;
- SS_USER_DESCRIPTION – краткое описание пользователя, varchar,
64 бита.
Теперь для соответствия роли пользователю определим колонки
таблицы SS_USER_ROLE:
- SS_ROLE_ID – идентификатор роли, тип – int, длина – 10 бит;
- SS_USER_ID – идентификатор пользователя, тип – int, длина – 10
бит;
Таблица для хранения информации о транспортном средстве –
VEHICLE_MASTER:
- VEHICLE_MASTER_ID – идентификатор транспортного средства,
тип – int, длина – 10 бит;
- VEHICLE_MASTER_NAME – название транспортного средства,
varchar, 50 бит;
- Registration_NO – регистрационный государственный номер
транспортного средства, varchar, 25 бит;
- Vehicle_Model – модель транспортного средства, varchar, 25 бит;
55
- Vehicle_Make – страна-производитель транспортного средства,
varchar, 25 бит;
- Colour – цвет транспортного средства, varchar, 10 бит;
- Category_Code – категория транспортного средства, int, 10 бит;
- Date_Of_Purchase – дата покупки транспортного средства, datetime,
24 бита;
- Insurance_Company – страховая компания, varchar, 50 бит;
- Insurance_Number – номер страхового полиса, varchar, 15 бит;
- Unit_Number – номер юнита, установленного на транспортном
средстве, int, 10 бит;
- License_Number – номер лицензии, varchar, 25 бит;
- Year_Of_Mft – год выпуска, int, 10 бит;
- Engine_Volume – объем двигателя, int, 10 бит;
- VIN – VIN-код транспортного средства, int, 10 бит;
- Serial_Number – серийный номер, varchar, 25 бит;
- Notes – примечания, varchar, 250 бит;
- DRIVER_MASTER_ID – идентификатор водителя, int, 10 бит.
Таблица для хранения информации о водителе транспортного
средства – DRIVER_MASTER:
- DRIVER_MASTER_ID – идентификатор водителя, int, 10 бит;
- Passport_No – номер паспорта водителя, varchar, 25 бит;
- Driver_LastName – фамилия водителя, varchar, 25 бит;
- Driver_FirstName – имя водителя, varchar, 25 бит;
- Driver_FatherName – отчество водителя, varchar, 25 бит;
- Driver_HomeTele – домашний телефон водителя, varchar, 12 бит;
- Driver_Mobile – мобильный телефон водителя, varchar, 12 бит;
- Driver_Email – электронная почта водителя, varchar, 50 бит;
- DRIVER_CITY – город водителя, varchar, 15 бит;
- DRIVER_DESCRIPTION – краткое описание водителя, varchar, 64
бита.
Таблица для хранения информации о юните, установленном на
транспортном средстве, – UNIT_MASTER:
- UNIT_MASTER_ID – идентификатор юнита, int, 10 бит;
- Unit_Number – номер юнита, int, 10 бит;
- UnitType_Code – тип юнита, varchar, 50 бит;
- SIM_Number – номер карточки в юните, varchar, 20 бит;
- Unit_AuthCode – аутентификационный код юнита, int, 10 бит;
- Manufacture_Code – название изготовителя, varchar, 50 бит;
- Channel_Info – информация канала, int, 10 бит;
- Protocol – протокол работы юнита (GSM или GPRS), varchar, 15 бит;
- Version – версия блока, находится на самом устройстве, varchar, 10
бит;
- Modem_number – номер модема GPRS/GSM, встроенного в юнит,
int, 10 бит;
56
- Modem_Id – идентификатор модема GPRS/GSM, встроенного в
юнит, int, 10 бит.
Таблица хранения данных, полученных с датчиков и по GPS –
GPSDATA:
- GPSDATA_ID – номер записи, int, 10 бит;
- REGISTRATION_NO – регистрационный номер, varchar, 25 бит;
- Unit_Number – номер юнита, int, 10 бит;
- LONGITUDE – долгота, float, 53 бита;
- LATITUDE – широта, float, 53 бита;
- ALTITUDE – высота, float, 53 бита;
- SPEED – скорость транспортного средства, float, 53 бита;
- SATELLITE – количество спутников, определенных GPS-модемом,
int, 10 бит;
- GPS_DATETIME – дата/время фиксирования объекта, datetime, 24
бита;
- UTC_DATETIME – дата/время по UTC, datetime, 24 бита;
- DIRECTION – направление, куда движется транспортное средство
(измеряется в радианах от 0 до 6,28…), float, 53 бита;
- ODOMETER – подсчет пройденного расстояния по GPS данным,
float, 53 бита;
- MESSAGE_NUMBER – номер сообщения, int, 10 бит;
- IGNITION – включено или выключено зажигание, tinyint, 3 бита;
- DOOR_SENSOR – датчик открытия/закрытия двери, tinyint, 3 бита;
- SHOCK_SENSOR – датчик удара (столкновения) транспортного
средства, tinyint, 3 бита;
- OILPRESSURE_SENSOR – датчик давления масла, tinyint, 3 бита;
- HOOD_LOCK – датчик открытия/закрытия капота, tinyint, 3 бита;
- DISTRESS_ALERT – сигнал тревоги, tinyint, 3 бита;
- INTERNAL_LIGHTS – свет в салоне включен/выключен, tinyint, 3
бита;
- FUEL_LEVEL – уровень топлива в баке, int, 10 бит.
Исходя из описанных выше базовых таблиц разрабатываемой базы
данных для автоматизированной системы диспетчерского наблюдения,
можно составить диаграмму их взаимодействия, представленную на
рисунке 2.6. На этой диаграмме показана связь «многие ко многим»,
разделенные на «многие к одному» и «один ко многим», а также связь «один
к одному». Таблицы «SS_ROLE», «SS_USER» и «SS_USER_ROLE»
относятся к части администрирования разрабатываемой системы, где будут
храниться данные о пользователях, ролях и их соответствии друг другу.
Таблицы «UNIT_MASTER», «DRIVER_MASTER» и «VEHICLE_MASTER»
показывают, какие данные будут храниться о юнитах, водителях и
транспортных средствах. Таблица «GPSDATA» будет хранить всю
необходимую информацию, получаемую от спутников и датчиков,
установленных на транспортном средстве.
57
Рисунок 2.6 – Схема связи основных таблиц разрабатываемой БД
2.3.5 Разработка классов сущностей системы
На основании разработанной базы данных были сгенерированы
основные классы
объектов постоянства,
которые
приведены
в
листингах 2.1 – 2.7.
Листинг 2.1 – Класс объекта постоянства «SS_USER»
package domain;
import javax.persistence.Column;
import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import static javax.persistence.GenerationType.IDENTITY;
import javax.persistence.Id;
import javax.persistence.Table;
@Entity
@Table(name="SS_USER"
,catalog="GISBD"
)
public class SS_USER implements java.io.Serializable {
private Integer SS_USER_ID;
58
private String SS_USER_LOGIN;
private String SS_USER_PASSWORD;
private String SS_USER_DESCRIPTION;
public SS_USER() {
}
public SS_USER(String SS_USER_LOGIN, String SS_USER_PASSWORD,
String SS_USER_DESCRIPTION) {
this.SS_USER_LOGIN = SS_USER_LOGIN;
this.SS_USER_PASSWORD = SS_USER_PASSWORD;
this.SS_USER_DESCRIPTION = SS_USER_DESCRIPTION;
}
@Id @GeneratedValue(strategy=IDENTITY)
@Column(name="SS_USER_ID", unique=true, nullable=false)
public Integer getSS_USER_ID() {
return this.SS_USER_ID;
}
public void setSS_USER_ID(Integer SS_USER_ID) {
this.SS_USER_ID = SS_USER_ID;
}
@Column(name="SS_USER_LOGIN", nullable=false, length=64)
public String getSS_USER_LOGIN() {
return this.SS_USER_LOGIN;
}
public void setSS_USER_LOGIN(String SS_USER_LOGIN) {
this.SS_USER_LOGIN = SS_USER_LOGIN;
}
@Column(name="SS_USER_PASSWORD", nullable=false, length=64)
public String getSS_USER_PASSWORD() {
return this.SS_USER_PASSWORD;
}
public void setSS_USER_PASSWORD(String SS_USER_PASSWORD) {
this.SS_USER_PASSWORD = SS_USER_PASSWORD;
}
@Column(name="SS_USER_DESCRIPTION", nullable=true, length=64)
public String getSS_USER_DESCRIPTION() {
return this.SS_USER_DESCRIPTION;
}
public void setSS_USER_DESCRIPTION(String SS_USER_DESCRIPTION) {
this.SS_USER_DESCRIPTION = SS_USER_DESCRIPTION;
}
}
Листинг 2.2 – Класс объекта постоянства «SS_ROLE»
package domain;
import javax.persistence.Column;
59
import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import static javax.persistence.GenerationType.IDENTITY;
import javax.persistence.Id;
import javax.persistence.Table;
@Entity
@Table(name="SS_ROLE"
,catalog="GISBD"
)
public class SS_ROLE implements java.io.Serializable {
private Integer SS_ROLE_ID;
private String SS_ROLE_NAME;
private String SS_ROLE_DESCRIPTION;
public SS_ROLE() {
}
public SS_ROLE(String SS_ROLE_NAME, String SS_ROLE_DESCRIPTION) {
this.SS_ROLE_NAME = SS_ROLE_NAME;
this.SS_ROLE_DESCRIPTION = SS_ROLE_DESCRIPTION;
}
@Id @GeneratedValue(strategy=IDENTITY)
@Column(name="SS_ROLE_ID", unique=true, nullable=false)
public Integer getSS_ROLE_ID() {
return this.SS_ROLE_ID;
}
public void setSS_ROLE_ID(Integer SS_ROLE_ID) {
this.SS_ROLE_ID = SS_ROLE_ID;
}
@Column(name="SS_ROLE_NAME", nullable=false, length=64)
public String getSS_ROLE_NAME() {
return this.SS_ROLE_NAME;
}
public void setSS_ROLE_NAME(String SS_ROLE_NAME) {
this.SS_ROLE_NAME = SS_ROLE_NAME;
}
@Column(name="SS_ROLE_DESCRIPTION", nullable=true, length=64)
public String getSS_ROLE_DESCRIPTION() {
return this.SS_ROLE_DESCRIPTION;
}
public void setSS_ROLE_DESCRIPTION(String SS_ROLE_DESCRIPTION) {
this.SS_ROLE_DESCRIPTION = SS_ROLE_DESCRIPTION;
}
}
60
Листинг 2.3 – Класс объекта постоянства «SS_USER_ROLE»
package domain;
import javax.persistence.Column;
import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import static javax.persistence.GenerationType.IDENTITY;
import javax.persistence.Id;
import javax.persistence.Table;
@Entity
@Table(name="SS_USER_ROLE"
,catalog="GISBD"
)
public class SS_USER_ROLE implements java.io.Serializable {
private Integer SS_ROLE_ID;
private Integer SS_USER_ID;
public SS_USER_ROLE() {
}
public SS_USER_ROLE(Integer SS_ROLE_ID, Integer SS_USER_ID) {
this.SS_ROLE_ID = SS_ROLE_ID;
this.SS_USER_ID = SS_USER_ID;
}
@Id @GeneratedValue(strategy=IDENTITY)
@Column(name="SS_ROLE_ID")
public Integer getSS_ROLE_ID() {
return this.SS_ROLE_ID;
}
public void setSS_ROLE_ID(Integer SS_ROLE_ID) {
this.SS_ROLE_ID = SS_ROLE_ID;
}
@Column(name="SS_USER_ID")
public Integer getSS_USER_ID() {
return this.SS_USER_ID;
}
public void setSS_USER_ID(Integer SS_USER_ID) {
this.SS_USER_ID = SS_USER_ID;
}
}
Листинг 2.4 – Класс объекта постоянства «UNIT_MASTER»
package domain;
import javax.persistence.Column;
import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
61
import static javax.persistence.GenerationType.IDENTITY;
import javax.persistence.Id;
import javax.persistence.Table;
@Entity
@Table(name="UNIT_MASTER"
,catalog="GISBD"
)
public class UNIT_MASTER implements java.io.Serializable {
private Integer UNIT_MASTER_ID;
private Integer Unit_Number;
private String UnitType_Code;
private String SIM_Number;
private Integer Unit_AuthCode;
private String Manufacture_Code;
private Integer Channel_Info;
private String Protocol;
private String Version;
private Integer Modem_number;
private Integer Modem_Id;
public UNIT_MASTER() {
}
public UNIT_MASTER(Integer Unit_Number, String UnitType_Code,
String SIM_Number, Integer Unit_AuthCode, String Manufacture_Code,
Integer Channel_Info, String Protocol, String Version, Integer
Modem_number, Integer Modem_Id) {
this.Unit_Number = Unit_Number;
this.UnitType_Code = UnitType_Code;
this.SIM_Number = SIM_Number;
this.Unit_AuthCode = Unit_AuthCode;
this.Manufacture_Code = Manufacture_Code;
this.Channel_Info = Channel_Info;
this.Protocol = Protocol;
this.Version = Version;
this.Modem_number = Modem_number;
this.Modem_Id = Modem_Id;
}
@Id @GeneratedValue(strategy=IDENTITY)
@Column(name="UNIT_MASTER_ID", unique=true, nullable=false)
public Integer getUNIT_MASTER_ID() {
return this.UNIT_MASTER_ID;
}
public void setUNIT_MASTER_ID(Integer UNIT_MASTER_ID) {
this.UNIT_MASTER_ID = UNIT_MASTER_ID;
}
@Column(name="Unit_Number")
public Integer getUnit_Number() {
return this.Unit_Number;
}
public void setUnit_Number(Integer Unit_Number) {
this.Unit_Number = Unit_Number;
62
}
@Column(name="UnitType_Code", nullable=false, length=50)
public String getUnitType_Code() {
return this.UnitType_Code;
}
public void setUnitType_Code(String UnitType_Code) {
this.UnitType_Code = UnitType_Code;
}
@Column(name="SIM_Number", nullable=false, length=20)
public String getSIM_Number() {
return this.SIM_Number;
}
public void setSIM_Number(String SIM_Number) {
this.SIM_Number = SIM_Number;
}
@Column(name="Unit_AuthCode")
public Integer getUnit_AuthCode() {
return this.Unit_AuthCode;
}
public void setUnit_AuthCode(Integer Unit_AuthCode) {
this.Unit_AuthCode = Unit_AuthCode;
}
@Column(name="Manufacture_Code", nullable=true, length=50)
public String getManufacture_Code() {
return this.Manufacture_Code;
}
public void setManufacture_Code(String Manufacture_Code) {
this.Manufacture_Code = Manufacture_Code;
}
@Column(name="Channel_Info")
public Integer getChannel_Info() {
return this.Channel_Info;
}
public void setChannel_Info(Integer Channel_Info) {
this.Channel_Info = Channel_Info;
}
@Column(name="Protocol", nullable=true, length=15)
public String getProtocol() {
return this.Protocol;
}
public void setProtocol(String Protocol) {
this.Protocol = Protocol;
}
@Column(name="Version", nullable=true, length=10)
public String getVersion() {
return this.Version;
63
}
public void setVersion(String Version) {
this.Version = Version;
}
@Column(name="Modem_number")
public Integer getModem_number() {
return this.Modem_number;
}
public void setModem_number(Integer Modem_number) {
this.Modem_number = Modem_number;
}
@Column(name="Modem_Id")
public Integer getModem_Id() {
return this.Modem_Id;
}
public void setModem_Id(Integer Modem_Id) {
this.Modem_Id = Modem_Id;
}
}
Листинг 2.5 – Класс объекта постоянства «DRIVER _MASTER»
package domain;
import javax.persistence.Column;
import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import static javax.persistence.GenerationType.IDENTITY;
import javax.persistence.Id;
import javax.persistence.Table;
@Entity
@Table(name="DRIVER_MASTER"
,catalog="GISBD"
)
public class DRIVER_MASTER implements java.io.Serializable {
private Integer DRIVER_MASTER_ID;
private String VEHICLE_MASTER_NAME;
private String Driver_LastName;
private String Driver_FirstName;
private String Driver_FatherName;
private String Driver_HomeTele;
private String Driver_Mobile;
private String Driver_Email;
private String DRIVER_CITY;
private String DRIVER_DESCRIPTION;
public DRIVER_MASTER() {
}
public DRIVER_MASTER(String Passport_No, String Driver_LastName,
String Driver_FirstName, String Driver_FatherName, String
64
Driver_HomeTele, String Driver_Mobile, String Driver_Email, String
DRIVER_CITY, String DRIVER_DESCRIPTION) {
this.Passport_No = Passport_No;
this.Driver_LastName = Driver_LastName;
this.Driver_FirstName = Driver_FirstName;
this.Driver_FatherName = Driver_FatherName;
this.Driver_HomeTele = Driver_HomeTele;
this.Driver_Mobile = Driver_Mobile;
this.Driver_Email = Driver_Email;
this.DRIVER_CITY = DRIVER_CITY;
this.DRIVER_DESCRIPTION = DRIVER_DESCRIPTION;
}
@Id @GeneratedValue(strategy=IDENTITY)
@Column(name="DRIVER_MASTER_ID", unique=true, nullable=false)
public Integer getDRIVER_MASTER_ID() {
return this.DRIVER_MASTER_ID;
}
public void setDRIVER_MASTER_ID(Integer DRIVER_MASTER_ID) {
this.DRIVER_MASTER_ID = DRIVER_MASTER_ID;
}
@Column(name="Passport_No", nullable=false, length=25)
public String getPassport_No() {
return this.Passport_No;
}
public void setPassport_No(String Passport_No) {
this.Passport_No = Passport_No;
}
@Column(name="Driver_LastName", nullable=false, length=25)
public String getDriver_LastName() {
return this.Driver_LastName;
}
public void setDriver_LastName(String Driver_LastName) {
this.Driver_LastName = Driver_LastName;
}
@Column(name="Driver_FirstName", nullable=false, length=25)
public String getDriver_FirstName() {
return this.Driver_FirstName;
}
public void setDriver_FirstName(String Driver_FirstName) {
this.Driver_FirstName = Driver_FirstName;
}
@Column(name="Driver_FatherName", nullable=false, length=25)
public String getDriver_FatherName() {
return this.Driver_FatherName;
}
public void setDriver_FatherName(String Driver_FatherName) {
this.Driver_FatherName = Driver_FatherName;
}
65
@Column(name="Driver_HomeTele", nullable=true, length=12)
public String getDriver_HomeTele() {
return this.Driver_HomeTele;
}
public void setDriver_HomeTele(String Driver_HomeTele) {
this.Driver_HomeTele = Driver_HomeTele;
}
@Column(name="Driver_Mobile", nullable=true, length=12)
public String getDriver_Mobile() {
return this.Driver_Mobile;
}
public void setDriver_Mobile(String Driver_Mobile) {
this.Driver_Mobile = Driver_Mobile;
}
@Column(name="Driver_Email", nullable=true, length=50)
public String getDriver_Email() {
return this.Driver_Email;
}
public void setDriver_Email(String Driver_Email) {
this.Driver_Email = Driver_Email;
}
@Column(name="DRIVER_CITY", nullable=false, length=15)
public String getDRIVER_CITY() {
return this.DRIVER_CITY;
}
public void setDRIVER_CITY(String DRIVER_CITY) {
this.DRIVER_CITY = DRIVER_CITY;
}
@Column(name="DRIVER_DESCRIPTION", nullable=true, length=64)
public String getDRIVER_DESCRIPTION() {
return this.DRIVER_DESCRIPTION;
}
public void setDRIVER_DESCRIPTION(String DRIVER_DESCRIPTION) {
this.DRIVER_DESCRIPTION = DRIVER_DESCRIPTION;
}
}
Листинг 2.6 – Класс объекта постоянства «VEHICLE_MASTER»
package domain;
import java.util.Date;
import javax.persistence.Column;
import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import static javax.persistence.GenerationType.IDENTITY;
import javax.persistence.Id;
import javax.persistence.Table;
66
import javax.persistence.Temporal;
import javax.persistence.TemporalType;
@Entity
@Table(name="VEHICLE_MASTER"
,catalog="GISBD"
)
public class VEHICLE_MASTER implements java.io.Serializable {
private Integer VEHICLE_MASTER_ID;
private String VEHICLE_MASTER_NAME;
private String Registration_NO;
private String Vehicle_Model;
private String Vehicle_Make;
private String Colour;
private Integer Category_Code;
private Date Date_Of_Purchase;
private String Insurance_Company;
private String Insurance_Number;
private Integer Unit_Number;
private String License_Number;
private Integer Year_Of_Mft;
private Integer Engine_Volume;
private Integer VIN;
private String Serial_Number;
private String Notes;
private Integer DRIVER_MASTER_ID;
public VEHICLE_MASTER() {
}
public VEHICLE_MASTER(String VEHICLE_MASTER_NAME, String
Registration_NO, String Vehicle_Model, String Vehicle_Make, String
Colour, Date Date_Of_Purchase) {
this.VEHICLE_MASTER_NAME = VEHICLE_MASTER_NAME;
this.Vehicle_Model = Vehicle_Model;
this.Vehicle_Make = Vehicle_Make;
this.Colour = Colour;
this.Date_Of_Purchase = Date_Of_Purchase;
}
public VEHICLE_MASTER(String VEHICLE_MASTER_NAME, String
Registration_NO, String Vehicle_Model, String Vehicle_Make, String
Colour, Integer Category_Code, Date Date_Of_Purchase, String
Insurance_Company, String Insurance_Number, Integer Unit_Number,
String License_Number, Integer Year_Of_Mft, Integer Engine_Volume,
Integer VIN, String Serial_Number, String Notes, Integer
DRIVER_MASTER_ID) {
this.VEHICLE_MASTER_NAME = VEHICLE_MASTER_NAME;
this.Registration_NO = Registration_NO;
this.Vehicle_Model = Vehicle_Model;
this.Vehicle_Make = Vehicle_Make;
this.Colour = Colour;
this.Category_Code = Category_Code;
this.Date_Of_Purchase = Date_Of_Purchase;
67
this.Insurance_Company = Insurance_Company;
this.Insurance_Number = Insurance_Number;
this.Unit_Number = Unit_Number;
this.License_Number = License_Number;
this.Year_Of_Mft = Year_Of_Mft;
this.Engine_Volume = Engine_Volume;
this.VIN = VIN;
this.Serial_Number = Serial_Number;
this.Notes = Notes;
this.DRIVER_MASTER_ID = DRIVER_MASTER_ID;
}
@Id @GeneratedValue(strategy=IDENTITY)
@Column(name="VEHICLE_MASTER_ID", unique=true, nullable=false)
public Integer getVEHICLE_MASTER_ID() {
return this.VEHICLE_MASTER_ID;
}
public void setVEHICLE_MASTER_ID(Integer VEHICLE_MASTER_ID) {
this.VEHICLE_MASTER_ID = VEHICLE_MASTER_ID;
}
@Column(name="VEHICLE_MASTER_NAME", nullable=false, length=50)
public String getVEHICLE_MASTER_NAME() {
return this.VEHICLE_MASTER_NAME;
}
public void setVEHICLE_MASTER_NAME(String VEHICLE_MASTER_NAME) {
this.VEHICLE_MASTER_NAME = VEHICLE_MASTER_NAME;
}
@Column(name="Registration_NO", nullable=false, length=25)
public String getRegistration_NO() {
return this.Registration_NO;
}
public void setRegistration_NO(String Registration_NO) {
this.Registration_NO = Registration_NO;
}
@Column(name="Vehicle_Model", nullable=false, length=25)
public String getVehicle_Model() {
return this.Vehicle_Model;
}
public void setVehicle_Model(String Vehicle_Model) {
this.Vehicle_Model = Vehicle_Model;
}
@Column(name="Vehicle_Make", nullable=true, length=25)
public String getVehicle_Make() {
return this.Vehicle_Make;
}
public void setVehicle_Make(String Vehicle_Make) {
this.Vehicle_Make = Vehicle_Make;
}
68
@Column(name="Colour", nullable=true, length=10)
public String getColour() {
return this.Colour;
}
public void setColour(String Colour) {
this.Colour = Colour;
}
@Column(name="Category_Code")
public Integer getCategory_Code() {
return this.Category_Code;
}
public void setCategory_Code(Integer Category_Code) {
this.Category_Code = Category_Code;
}
@Temporal(TemporalType.DATE)
@Column(name="Date_Of_Purchase", length=24)
public Date getDate_Of_Purchase() {
return this.Date_Of_Purchase;
}
public void setDate_Of_Purchase(Date Date_Of_Purchase) {
this.Date_Of_Purchase = Date_Of_Purchase;
}
@Column(name="Insurance_Company", nullable=false, length=50)
public String getInsurance_Company() {
return this.Insurance_Company;
}
public void setInsurance_Company(String Insurance_Company) {
this.Insurance_Company = Insurance_Company;
}
@Column(name="Insurance_Number", nullable=false, length=15)
public String getInsurance_Number() {
return this.Insurance_Number;
}
public void setInsurance_Number(String Insurance_Number) {
this.Insurance_Number = Insurance_Number;
}
@Column(name="Unit_Number")
public Integer getUnit_Number() {
return this.Unit_Number;
}
public void setUnit_Number(Integer Unit_Number) {
this.Unit_Number = Unit_Number;
}
@Column(name="License_Number", nullable=false, length=25)
public String getLicense_Number() {
return this.License_Number;
69
}
public void setLicense_Number(String License_Number) {
this.License_Number = License_Number;
}
@Column(name="Year_Of_Mft")
public Integer getYear_Of_Mft() {
return this.Year_Of_Mft;
}
public void setYear_Of_Mft(Integer Year_Of_Mft) {
this.Year_Of_Mft = Year_Of_Mft;
}
@Column(name="Engine_Volume")
public Integer getEngine_Volume() {
return this.Engine_Volume;
}
public void setEngine_Volume(Integer Engine_Volume) {
this.Engine_Volume = Engine_Volume;
}
@Column(name="VIN")
public Integer getVIN() {
return this.VIN;
}
public void setVIN(Integer VIN) {
this.VIN = VIN;
}
@Column(name="Serial_Number", nullable=false, length=25)
public String getSerial_Number() {
return this.Serial_Number;
}
public void setSerial_Number(String Serial_Number) {
this.Serial_Number = Serial_Number;
}
@Column(name="Notes", nullable=true, length=250)
public String getNotes() {
return this.Notes;
}
public void setNotes(String Notes) {
this.Notes = Notes;
}
@Column(name="DRIVER_MASTER_ID")
public Integer getDRIVER_MASTER_ID() {
return this.DRIVER_MASTER_ID;
}
public void setDRIVER_MASTER_ID(Integer DRIVER_MASTER_ID) {
this.DRIVER_MASTER_ID = DRIVER_MASTER_ID;
}
70
}
Листинг 2.7 – Класс объекта постоянства «GPSDATA»
package domain;
import java.math.BigDecimal;
import java.util.Date;
import javax.persistence.Column;
import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import static javax.persistence.GenerationType.IDENTITY;
import javax.persistence.Id;
import javax.persistence.Table;
import javax.persistence.Temporal;
import javax.persistence.TemporalType;
@Entity
@Table(name="GPSDATA"
,catalog="GISBD"
)
public class GPSDATA implements java.io.Serializable {
private Integer GPSDATA_ID;
private String REGISTRATION_NO;
private Integer Unit_Number;
private BigDecimal LONGITUDE;
private BigDecimal LATITUDE;
private BigDecimal ALTITUDE;
private BigDecimal SPEED;
private Integer SATELLITE;
private Data GPS_DATETIME;
private Data UTC_DATETIME;
private BigDecimal DIRECTION;
private BigDecimal ODOMETER;
private Integer MESSAGE_NUMBER;
private Integer IGNITION;
private Integer DOOR_SENSOR;
private Integer SHOCK_SENSOR;
private Integer OILPRESSURE_SENSOR;
private Integer HOOD_LOCK;
private Integer DISTRESS_ALERT;
private Integer INTERNAL_LIGHTS;
private Integer FUEL_LEVEL;
public GPSDATA() {
}
public GPSDATA(String REGISTRATION_NO, Data GPS_DATETIME, Data
UTC_DATETIME) {
this.REGISTRATION_NO = REGISTRATION_NO;
this.GPS_DATETIME = GPS_DATETIME;
this.UTC_DATETIME = UTC_DATETIME;
}
public GPSDATA(String REGISTRATION_NO, Integer Unit_Number,
BigDecimal LONGITUDE, BigDecimal LATITUDE, BigDecimal ALTITUDE,
71
BigDecimal SPEED, Integer SATELLITE, Data GPS_DATETIME, Data
UTC_DATETIME, BigDecimal DIRECTION, BigDecimal ODOMETER, Integer
MESSAGE_NUMBER, Integer IGNITION, Integer DOOR_SENSOR, Integer
SHOCK_SENSOR, Integer OILPRESSURE_SENSOR, Integer HOOD_LOCK, Integer
DISTRESS_ALERT, Integer INTERNAL_LIGHTS, Integer FUEL_LEVEL) {
this.REGISTRATION_NO = REGISTRATION_NO;
this.Unit_Number = Unit_Number;
this.LONGITUDE = LONGITUDE;
this.LATITUDE = LATITUDE;
this.ALTITUDE = ALTITUDE;
this.SPEED = SPEED;
this.SATELLITE = SATELLITE;
this.GPS_DATETIME = GPS_DATETIME;
this.UTC_DATETIME = UTC_DATETIME;
this.DIRECTION = DIRECTION;
this.ODOMETER = ODOMETER;
this.MESSAGE_NUMBER = MESSAGE_NUMBER;
this.IGNITION = IGNITION;
this.DOOR_SENSOR = DOOR_SENSOR;
this.SHOCK_SENSOR = SHOCK_SENSOR;
this.OILPRESSURE_SENSOR = OILPRESSURE_SENSOR;
this.HOOD_LOCK = HOOD_LOCK;
this.DISTRESS_ALERT = DISTRESS_ALERT;
this.INTERNAL_LIGHTS = INTERNAL_LIGHTS;
this.FUEL_LEVEL = FUEL_LEVEL;
}
@Id @GeneratedValue(strategy=IDENTITY)
@Column(name="GPSDATA_ID", unique=true, nullable=false)
public Integer getGPSDATA_ID() {
return this.GPSDATA_ID;
}
public void setGPSDATA_ID(Integer GPSDATA_ID) {
this.GPSDATA_ID = GPSDATA_ID;
}
@Column(name="REGISTRATION_NO", nullable=true, length=25)
public String getREGISTRATION_NO() {
return this.REGISTRATION_NO;
}
public void setREGISTRATION_NO(String REGISTRATION_NO) {
this.REGISTRATION_NO = REGISTRATION_NO;
}
@Column(name="Unit_Number")
public Integer getUnit_Number() {
return this.Unit_Number;
}
public void setUnit_Number(Integer Unit_Number) {
this.Unit_Number = Unit_Number;
}
@Column(name="LONGITUDE", precision=10)
public BigDecimal getLONGITUDE() {
72
return this.LONGITUDE;
}
public void setLONGITUDE(BigDecimal LONGITUDE) {
this.LONGITUDE = LONGITUDE;
}
@Column(name="LATITUDE", precision=10)
public BigDecimal getLATITUDE() {
return this.LATITUDE;
}
public void setLATITUDE(BigDecimal LATITUDE) {
this.LATITUDE = LATITUDE;
}
@Column(name="ALTITUDE", precision=10)
public BigDecimal getALTITUDE() {
return this.ALTITUDE;
}
public void setALTITUDE(BigDecimal ALTITUDE) {
this.ALTITUDE = ALTITUDE;
}
@Column(name="SPEED", precision=10)
public BigDecimal getSPEED() {
return this.SPEED;
}
public void setSPEED(BigDecimal SPEED) {
this.SPEED = SPEED;
}
@Column(name="SATELLITE")
public Integer getSATELLITE() {
return this.SATELLITE;
}
public void setSATELLITE(Integer SATELLITE) {
this.SATELLITE = SATELLITE;
}
@Temporal(TemporalType.DATE)
@Column(name="GPS_DATETIME", length=24)
public Date getGPS_DATETIME() {
return this.GPS_DATETIME;
}
public void setGPS_DATETIME(Date GPS_DATETIME) {
this.GPS_DATETIME = GPS_DATETIME;
}
@Temporal(TemporalType.DATE)
@Column(name="UTC_DATETIME", length=24)
public Date getUTC_DATETIME() {
return this.UTC_DATETIME;
}
public void setUTC_DATETIME(Date UTC_DATETIME) {
this.UTC_DATETIME = UTC_DATETIME;
73
}
@Column(name="DIRECTION", precision=10)
public BigDecimal getDIRECTION() {
return this.DIRECTION;
}
public void setDIRECTION(BigDecimal DIRECTION) {
this.DIRECTION = DIRECTION;
}
@Column(name="ODOMETER", precision=10)
public BigDecimal getODOMETER() {
return this.ODOMETER;
}
public void setODOMETER(BigDecimal ODOMETER) {
this.ODOMETER = ODOMETER;
}
@Column(name="MESSAGE_NUMBER")
public Integer getMESSAGE_NUMBER() {
return this.MESSAGE_NUMBER;
}
public void setMESSAGE_NUMBER(Integer MESSAGE_NUMBER) {
this.MESSAGE_NUMBER = MESSAGE_NUMBER;
}
@Column(name="IGNITION")
public Integer getIGNITION() {
return this.IGNITION;
}
public void setIGNITION(Integer IGNITION) {
this.IGNITION = IGNITION;
}
@Column(name="DOOR_SENSOR")
public Integer getDOOR_SENSOR() {
return this.DOOR_SENSOR;
}
public void setDOOR_SENSOR(Integer DOOR_SENSOR) {
this.DOOR_SENSOR = DOOR_SENSOR;
}
@Column(name="SHOCK_SENSOR")
public Integer getSHOCK_SENSOR() {
return this.SHOCK_SENSOR;
}
public void setSHOCK_SENSOR(Integer SHOCK_SENSOR) {
this.SHOCK_SENSOR = SHOCK_SENSOR;
}
@Column(name="OILPRESSURE_SENSOR")
public Integer getOILPRESSURE_SENSOR() {
return this.OILPRESSURE_SENSOR;
74
}
public void setOILPRESSURE_SENSOR(Integer OILPRESSURE_SENSOR) {
this.OILPRESSURE_SENSOR = OILPRESSURE_SENSOR;
}
@Column(name="HOOD_LOCK")
public Integer getHOOD_LOCK() {
return this.HOOD_LOCK;
}
public void setHOOD_LOCK(Integer HOOD_LOCK) {
this.HOOD_LOCK = HOOD_LOCK;
}
@Column(name="DISTRESS_ALERT")
public Integer getDISTRESS_ALERT() {
return this.DISTRESS_ALERT;
}
public void setDISTRESS_ALERT(Integer DISTRESS_ALERT) {
this.DISTRESS_ALERT = DISTRESS_ALERT;
}
@Column(name="INTERNAL_LIGHTS")
public Integer getINTERNAL_LIGHTS() {
return this.INTERNAL_LIGHTS;
}
public void setINTERNAL_LIGHTS(Integer INTERNAL_LIGHTS) {
this.INTERNAL_LIGHTS = INTERNAL_LIGHTS;
}
@Column(name="FUEL_LEVEL")
public Integer getFUEL_LEVEL() {
return this.FUEL_LEVEL;
}
public void setFUEL_LEVEL(Integer FUEL_LEVEL) {
this.FUEL_LEVEL = FUEL_LEVEL;
}
}
2.3.6 Проектирование интерфейса пользователя
В данном подпункте рассмотрим «зарисовки» интерфейсов основного
окна клиентского приложения и окна работы с картой. Также рассмотрим
несколько сценариев использования интерфейса автоматизированной
системы диспетчерского наблюдения.
2.3.5.1 Интерфейсы основных окон приложения АСДН
75
Интерфейс клиентского приложения должен обеспечить максимальную
функциональность по наблюдению за транспортными средствами.
Предполагается взаимодействие пользователя с следующими основными
интерфейсами:
- работа с главным клиентом;
- взаимодействие с картами.
Интерфейс каждой подсистемы имеет свои особенности, однако
проектируется с учетом общих для всего проекта принципов простоты
использования, эффективности дизайна и удобства стиля оформления.
На рисунке 2.7 приводится интерфейс основного окна работы с
главным клиентом.
В верхней части окна будет находиться название системы. Чуть ниже –
главное меню с расширенными функциями. Еще чуть ниже находится
комбобокс
со
списком доступных
определенному
пользователю
соотношений юнита и транспортного средства. Ниже находится
результирующее окно-таблица, в котором выводятся сообщения.
Рисунок 2.7 – Основное окно главного клиента
Для просмотра местоположений транспортных средств необходимо
будет окно работы с картой. Это окно представлено на рисунке 2.8.
В верхней части окна находится название окна. Чуть ниже – три
расширенных кнопки с функциями и семь функциональных кнопок.
76
Рисунок 2.8 – Окно работы с картой
Под функциональными кнопками расположено основное окно, в
котором находится сама карта, на которой можно будет увидеть, например,
местоположение транспортного средства.
2.3.5.2 Сценарии использования интерфейса
Для более углубленного понимания работы клиентского приложения
автоматизированной системы диспетчерского наблюдения рассмотрим
несколько сценариев.
Перед тем, как начать работу с клиентским приложением
автоматизированной
системы
диспетчерского
наблюдения, нужно
авторизироваться. Окно входа в систему представлено на рисунке 2.9.
Рисунок 2.9 – Окно входа в систему
2.3.5.2.1 Сценарий «Определение местоположения транспортного
средства в режиме реального времени»
В основном окне главного клиента (рисунок 2.7) в пункте меню
«Юнит\Авто» из выпадающего списка нужно выбрать необходимый
автомобиль (рисунок 2.10).
Здесь «12345» – номер блока, установленного на транспортном
средстве, «Авто1» – государственный регистрационный номер транспортного
средства.
Рисунок 2.10 – Выбор транспортного средства
77
Далее необходимо зайти в меню «Команды» и выбрать пункт меню
«Запрос статуса» (рисунок 2.11).
Рисунок 2.11 – Выбор команды «Запрос статуса»
Здесь «12345» – номер блока, установленного на выбранном
транспортном средстве.
После нажатия на команду «Запрос статуса» в главном окне АСДН
появится сообщение (рисунок 2.12).
Рисунок 2.12 – Сообщение «Запрос статуса»
Теперь нужно зайти в меню «Окна» и выбрать пункт меню «Данные
GPS» (рисунок 2.13).
Рисунок 2.13 – Выбор окна «Данные GPS»
78
После нажатия на «Данные GPS» откроется окно «Данные GPS в
реальном времени» (рисунок 2.14). Когда SMS вернется, в окне «Данные GPS
в реальном времени» появятся значения параметров автомобиля.
Рисунок 2.14 – Окно «Данные GPS в реальном времени»
Далее для получения местонахождения транспортного средства
необходимо два раза кликнуть левой кнопкой мыши на данной строке (или
по правой кнопке выбрать «Показать на карте»). Строка, по которой нужно
кликнуть показана на рисунке 2.15.
Рисунок 2.15 – Строка, по которой нужно кликнуть
Если все будет сделано правильно, на экране откроется окно «Карта»
(рисунок 2.8), где будет изображено местонахождение автомобиля,
соответствующее координатам «Долгота-Широта», дате и времени в данных
GPS.
2.3.5.2.2 Сценарий «Мониторинг использования транспортного
средства по заданному количеству позиций последнего местоположения»
В основном окне главного клиента (рисунок 2.7) в пункте меню
«Юнит\Авто» из выпадающего списка нужно выбрать необходимый
автомобиль (рисунок 2.10).
Далее необходимо загрузить информацию об использовании с
оборудования, установленного в выбранном транспортном средстве. Для
этого нужно зайти в меню «Команды», выбрать пункт меню «Другие» и там
выбрать, по какому алгоритму будет происходить загрузка информации,
нажав на подменю «Сгрузить накопленные события (дозвон)», либо
«Сгрузить накопленные события (SMS)» (рисунок 2.16).
79
Рисунок 2.16 – Загрузка накопленной информации с юнита
Сгрузить накопленные события (дозвон) – модем позвонит к юниту и
загрузит всю накопленную информацию. То есть дозвон будет осуществлен с
телефонной карты, установленной в офисе (тарифицируется как исходящий
офисный и входящий на карту, установленную в транспортном средстве).
Сгрузить накопленные события (SMS) – модем отправит SMS юниту,
которое инициирует звонок юнита на модем системы. То есть дозвон будет
осуществлен с телефонной карты, установленной в транспортном средстве,
после отправки SMS с карточки, установленной в офисе (тарифицируется как
исходящий с карты, установленной в транспортном средстве, и входящий на
офисную карту плюс одно SMS с офисной карты).
После этого в главном окне АСДН появится сообщение о дозвоне к
юниту транспортного средства (рисунок 2.17).
Данное сообщение говорит о том, что команда уже отправлена и
происходит процесс дозвона к юниту, установленному в автомобиле.
В случае появления в окне «NO CARRIER» – транспортное средство
находиться вне зоны покрытия сети GSM.
В случае удачного подключения, в главном окне АСДН появятся
надписи CONNECT и LOGON, свидетельствующие о подключении к юниту,
после чего начнется загрузка данных. Когда появится сообщение
NoMoreEvents, то это значит, что сообщений в памяти юнита больше не
осталось.
Рисунок 2.17 – Дозвон к юниту
80
Теперь вся загруженная информация записана в базу данных системы.
Для того, чтобы посмотреть результаты движения транспортного
средства, необходимо воспользоваться «Картой». Для этого нужно зайти в
меню «Окна» и выбрать подменю «Карта» (рисунок 2.18).
Рисунок 2.18 – Выбор пункта «Карта»
После нажатия на подменю «Карта» на экране откроется окно с картой
(рисунок 2.8). Теперь необходимо выбрать карту нужного города. Для этого
необходимо воспользоваться командой «Выбрать карту…» (рисунок 2.19).
Рисунок 2.19 – Выбор карты нужного города
После выбора карты необходимого города можно приступить к
обработке информации.
Вся информация, полученная от транспортного средства, извлекается
через пункт меню «Выбрать запрос…».
Пункт меню «Выбрать запрос…» содержит такие подпункты, как
«Запрос по дате», «Запрос за период» и «Запрос местоположения»
(рисунок 2.20).
81
Рисунок 2.20 – Выбор запроса последнего местоположения транспортного
средства
После нажатия на подменю «Запрос местоположения» появится окно, в
котором нужно будет выбрать необходимое транспортное средство (то есть
то, с юнита которого была загружена информация) и задать количество
последних зафиксированных спутником позиций транспортного средства
(рисунок 2.21).
Рисунок 2.21 – Задание параметров запроса
После задания необходимых параметров нужно нажать на кнопку
«ОК».
Результатом запроса будет таблица с информацией об использовании
выбранного транспортного средства за выбранное последнее количество
точек. Окно с данной таблицей показано на рисунке 2.22.
82
Рисунок 2.22 – Результат запроса последних 10 точек
1 – кнопка «Показать трек». Нажатие на данную кнопку позволит на
карте увидеть полностью маршрут следования транспортного средства.
2 – кнопка «Центрировать точку». Позволяет центрировать на карте
выбранную точку. При активации данной функции выбранная точка
окажется в центре экрана и несколько раз мигнет.
2.3.7 Обеспечение не функциональных требований к АСДН
Одним из важных
условий
для разработки
архитектуры
автоматизированной системы диспетчерского наблюдения является то, что
она должна учитывать нефункциональные (сервисные) требования. На этапе
постановки требований к системе был определен уровень сервисного
измерения для каждого из сервисных требований. Достижение при этом
максимального компромисса, учитывая, когда выполнение одного
нефункционального требования влияет на степень выполнения другого
нефункционального требования, есть главной задачей при обеспечении этих
требований.
Ниже приведены пути обеспечения требований, которые определяют
критерии работы системы в целом, а не отдельные сценарии поведения:
Обеспечение масштабируемости системы к нагрузке будет достигнуто
путем применения средств вертикального масштабирования. Вертикальная
масштабируемость будет достигнута путем увеличения мощности (память,
процессор, и т.д.) используемых серверов. Данный вид масштабируемости
позволит обеспечить достаточную мощность для обслуживания большего
количества клиентов и в меньшей степени требует управления ресурсами.
Тем более, данный метод сравнительно проще и дешевле, чем
горизонтальное масштабирование.
Производительность системы как сервис, который отвечает за время
реагирования системы, будет обеспечен путем использования балансировки
и распределения нагрузки между компонентами, для которых необходимо
достичь производительности.
Также, в перспективе внедрения автоматизированной системы
диспетчерского наблюдения, важно обеспечить возможность устранения
недостатков в существующих функциональных возможностях, не оказывая
влияния на другие компоненты, адаптации к новой среде функционирования,
83
а также повышение производительности или улучшение других
характеристик программного обеспечения. Для обеспечения удобства в
сопровождении, структура системы будет модульной и достаточно
сопровождаться соответствующей документацией.
Надежность системы можно будет обеспечить посредством
горизонтальной масштабируемости, например увеличением количества
серверов.
Для обеспечения гарантии того, что услуги, предоставляемые
системой, будут доступны необходимому числу пользователей в течение
необходимого времени, предположительно будет достигнута при помощи
отказоустойчивого механизма, чем может служить использование
репликации источников данных на отдельный сервер. Также как
альтернативу для обеспечения постоянной доступности можно будет
использовать географическую масштабируемость, в случаях, когда отказал в
выполнение запросов один сервер, вместо него эти запросы можно назначить
на другой сервер.
Для обеспечения безопасности системы при ее эксплуатации будет
реализован разделенный доступ пользователей системы к защищенным
объектам системы и защищенным функциям. На рисунке 2.23 Приведена
модель подсистемы безопасности.
Рисунок 2.23 – Модель подсистемы безопасности
Operation, Command – защищенная функция системы. Функция, доступ
к которой имеют не все пользователи системы, а лишь обладающие
определенными правами, в соответствии с их ролью.
DefensibleObject – защищенный объект предметной области. Объект,
принадлежащий классу предметной области, доступ к которому зависит от
наличия или отсутствия прав у определенной роли или конкретного
84
пользователя. Доступ к объекту может быть полным или маскированным
(для отдельных функций или операций). В автоматизированной системе
диспетчерского наблюдения защищенными являются объекты класса Unit.
User
–
пользователь
системы.
Лицо,
использующее
автоматизированную систему диспетчерского наблюдения. Имеет право
доступа к системе через интерфейс системы согласно своей роли. Имеет
права доступа к защищенным объектам системы согласно своей роли и
правам доступа для каждого конкретного объекта.
Role – роль. Логическая группа пользователей, обладающих равными
правами по доступу к системе.
Car – транспортное средство.
ProgramResourse – функция системы. Функция автоматизированной
системы диспетчерского наблюдения, предоставляемая пользователю через
интерфейс системы. С точки зрения подсистемы безопасности выделяются
незащищенные функции, защищенные функции и функции доступа к
защищенным объектам.
Unit – юнит. Блок, оборудованный GPS, устанавливаемый на
транспортном средстве для наблюдения и охраны.
Unit-Car – Юнит-ТС. Транспортное средство (ТС), оборудованное
юнитом, актор системы.
2.4 Разработка аппаратной подсистемы
В данном подразделе проведем разработку и выполнение структурной
и электрической принципиальной схем аппаратной подсистемы, которой
является блок (юнит), встроенный в транспортное средство.
2.4.1 Разработка структурной схемы
Блок, встроенный в транспортное средство, должен иметь в своем
составе:
- процессор для выполнения математических и логических операций;
- контроллер памяти для управления потоками входящих и
исходящих данных;
- Flash-память для хранения этих самых данных;
- GPS-модуль для принятия сигналов со спутников системы GPS и
определения
географических
координат
местоположения
приемника, точного времени, скорости и направления движения;
- GSM-модуль для доступа в сеть сотовой связи GSM.
На рисунке 2.24 изображена структурная схема разрабатываемого
блока.
85
Рисунок 2.24 – Структурная схема разрабатываемого блока
Данные с GPS-модуля будут передаваться на центральный процессор
ARM9, который в свою очередь обработает их, после чего контроллер памяти
их сохранит. GSM-модуль передает обработанную информацию оператору, а
также передает сообщения с командами от оператора на центральный
процессор.
2.4.2 Разработка схемы электрической принципиальной
При разработке принципиальной схемы нужно было выбрать GPS и
GSM-модули. Но в процессе сравнения нескольких модулей GPS и GSM,
было принято решение применить универсальный модуль SIM508, который
включает в себя компактный GSM-модуль с GPS-приемником в одном
корпусе. SIM508 поддерживает прием и передачу данных, голоса в стандарте
сотовой связи GSM (900/1800/1900). Модуль SIM508 включает в себя GPS и
GSM технологии, оптимально сочетающие функциональность и маленький
размер форм-фактора. Встроенный 20-канальный GPS-приемник выполнен
на высокочувствительном GPS-чипсете SIRF Star III, который позволяет
принимать сигналы со спутников и определять координаты в самых плохих
условиях видимости неба и в условиях плотной городской застройки. Также
модуль SIM508 имеет встроенный TCP/IP стек. SIM508 позволяет решать
различные задачи, такие как непрерывный мониторинг и контроль
автотранспорта, передвижений грузов, людей. Применяется так же в M2M
системах, носимых устройствах связи, системах навигации и логистики.
Основные технические характеристики GSM/GPRS/GPS модуля
SIM508 представлены в таблице 2.1.
На рисунке 2.25 представлена схема модуля SIM508. Выход STATUS
предоставит нам данные о покрытии сети GSM.
Центральный
процессор ARM9
GPS-модуль
GSM-модуль
Контроллер
памяти
Внутренняя
Flash-память
Внутреннее ОЗУ
(SDRAM)
86
Таблица 2.1 – Основные технические характеристики модуля SIM508
Диапазон частот
- GSM-GPRS 900/1800/1900 МГц;
- совместимость с GSM phase 2/2.
Управление модулем
AT Команды (GSM 07.07, 07.05, SIMCOM)
Передача данных
- GPRS Class 10/8 B;
- CSD до 14.4 Кбит/сек;
- Fax Group 3, Class 1;
- встроенный TCP/IP протокол.
Ток потребления
- в режиме ожидания 23 мА;
- в режиме передачи <470 мА;
- максимальный ток 2 А;
- напряжение питания от 3.4 до 4.5 В.
GPS
- чипсет SIRF Star III;
- число каналов 20;
- частота L1 1575.42 МГц;
- чувствительность;
- слежение 159 дБм;
- повторный захват 148 дБм;
- захват 144 дБм;
- время определения координат TIFF:
а) горячий старт 1 с;
б) теплый старт <38 с;
в) холодный старт <42 с;
- точность определения координат 10 м CEP;
- протоколы:
а) NMEA-0183;
б) SIRF binary;
в) RTCM SC-104.
Общие характеристики
- максимальный ток потребления 60 мА;
- напряжение питания от 3.3 до 3.6 В;
- температура:
а) рабочая от -20 °С до +55 °С;
б) рабочая с ограничением от -30 °С до
+80 °С;
в) хранения от -40 °С до +85 °С;
- размеры 34 х 55 х 3 мм;
- вес 12 г;
- системный разъем 552010878.
Дополнительные
функции
- функции работы с SIM картой SIM Application
Toolkit;
- наличие встроенного таймера реального
времени;
- мониторинг температуры модуля.
87
Рисунок 2.25 – Схема модуля SIM508
2.5 Выводы
В данном разделе были представлены некоторые из этапов
проектирования автоматизированной системы диспетчерского наблюдения
такие, как разработка архитектуры АСДН, разработка программной и
аппаратной подсистем, включая проектирование баз данных и программного
интерфейса системы.
88
3 РЕАЛИЗАЦИЯ АВТОМАТИЗИРОВАННОЙ СИСТЕМЫ
ДИСПЕТЧЕРСКОГО НАБЛЮДЕНИЯ
3.1 Реализация программной подсистемы
В данном подпункте будут показаны результаты реализации основных
таблиц базы данных и результаты разработки системы в виде основных
сценариев использования системы, представленных в разделе разработки.
Также будут описаны все компоненты и подменю основных окон системы.
3.3.1 Результаты реализации базы данных
При разработке автоматизированной системы диспетчерского
наблюдения была реализована база данных системы. Описание основных
таблиц данной БД приведено в таблицах 3.1 – 3.7.
Таблица 3.1 – Описание таблицы ролей SS_ROLE
Название колонки
Тип данных
Ограничения
Описание
SS_ROLE_ID
integer (10)
not null
Первичный
ключ,
уникальный
идентификатор
роли
SS_ROLE_NAME
character
varying (64)
not null
Название роли
SS_ROLE_DESCRIPTION character
varying (64)
-
Краткое
описание роли
Таблица 3.2 – Описание таблицы пользователей SS_USER
Название колонки
Тип данных
Ограничения
Описание
SS_USER_ID
integer (10)
not null
Первичный
ключ,
уникальный
идентификатор
пользователя
SS_USER_LOGIN
character
varying (64)
not null
Логин
пользователя
SS_USER_PASSWORD
character
varying (64)
not null
Пароль
пользователя
SS_USER_DESCRIPTION character
varying (64)
-
Краткое
описание
пользователя
89
Таблица 3.3 – Описание таблицы соответствия роли пользователю
SS_USER_ROLE
Название
колонки
Тип
данных
Ограничения
Описание
SS_ROLE_ID integer (10)
not null
Первичный ключ, уникальный
идентификатор роли
SS_USER_ID integer (10)
not null
Первичный ключ, уникальный
идентификатор пользователя
Таблица 3.4 – Описание таблицы транспортных средств VEHICLE_MASTER
Название колонки
Тип
данных
Ограничения
Описание
VEHICLE_MASTER_ID
integer (10)
not null
Первичный ключ,
уникальный
идентификатор
транспортного
средства
VEHICLE_MASTER_NAME character
varying
(50)
not null
Название
транспортного
средства
Registration_NO
character
varying
(25)
not null
Регистрационный
государственный
номер
транспортного
средства
Vehicle_Model
character
varying
(25)
not null
Модель
транспортного
средства
Vehicle_Make
character
varying
(25)
-
Страна-
производитель
транспортного
средства
Colour
character
varying
(10)
-
Цвет
транспортного
средства
Category_Code
integer (10)
-
Категория
транспортного
средства
Date_Of_Purchase
datetime
(24)
-
Дата покупки
транспортного
средства
Insurance_Company
character
varying
(50)
not null
Страховая
компания
90
Продолжение таблицы 3.4.
Название колонки
Тип
данных
Ограничения
Описание
Insurance_Number
character
varying
(15)
not null
Номер
страхового
полиса
транспортного
средства
Unit_Number
integer (10)
not null
Номер юнита,
установленного
на транспортном
средстве
License_Number
character
varying
(25)
not null
Номер лицензии
Year_Of_Mft
integer (10)
-
Год выпуска
Engine_Volume
integer (10)
not null
Объем двигателя
VIN
integer (10)
not null
VIN-код
транспортного
средства
Serial_Number
character
varying
(25)
not null
Серийный номер
Notes
character
varying
(250)
-
Примечание,
произвольная
информация о
транспортном
средстве
DRIVER_MASTER_ID
integer (10)
not null
Первичный ключ,
уникальный
идентификатор
водителя
Таблица 3.5 – Описание таблицы водителей DRIVER_MASTER
Название колонки
Тип данных
Ограничения
Описание
DRIVER_MASTER_ID
integer (10)
not null
Первичный
ключ,
уникальный
идентификатор
водителя
Passport_No
character
varying (25)
not null
Номер паспорта
водителя
Driver_LastName
character
varying (25)
not null
Фамилия
водителя
91
Продолжение таблицы 3.5.
Название колонки
Тип данных
Ограничения
Описание
Driver_FirstName
character
varying (25)
not null
Имя водителя
Driver_FatherName
character
varying (25)
not null
Отчество
водителя
Driver_HomeTele
character
varying (12)
-
Домашний
телефон
водителя
Driver_Mobile
character
varying (12)
-
Мобильный
телефон
водителя
Driver_Email
character
varying (50)
-
Электронная
почта водителя
DRIVER_CITY
character
varying (15)
not null
Город водителя
DRIVER_DESCRIPTION character
varying (64)
-
Краткое
описание
водителя
Таблица 3.6 – Описание таблицы юнитов UNIT_MASTER
Название колонки
Тип данных
Ограничения
Описание
UNIT_MASTER_ID integer (10)
not null
Первичный ключ,
уникальный
идентификатор юнита
Unit_Number
integer (10)
– not null
– default 0
Номер юнита
UnitType_Code
character
varying (50)
not null
Тип юнита
SIM_Number
character
varying (20)
not null
Номер карточки в
юните
Unit_AuthCode
integer (10)
default 0
Аутентификационный
код юнита
Manufacture_Code
character
varying (50)
-
Название
изготовителя
Channel_Info
integer (10)
-
Информация канала
Protocol
character
varying (15)
-
Протокол работы
юнита (GSM или
GPRS)
Version
character
varying (10)
-
Версия юнита,
находится на самом
устройстве
92
Продолжение таблицы 3.6.
Название колонки
Тип данных
Ограничения
Описание
Modem_number
integer (10)
default 0
Номер модема
GPRS/GSM,
встроенного в юнит
Modem_Id
integer (10)
default 0
Уникальный
идентификатор
модема GPRS/GSM,
встроенного в юнит
Таблица 3.7 – Описание таблицы данных, полученных с датчиков и по GPS
GPSDATA
Название колонки
Тип данных Ограничения
Описание
GPSDATA_ID
integer (10)
not null
Первичный ключ,
уникальный
идентификатор,
номер записи
REGISTRATION_NO
character
varying (25)
-
Регистрационный
номер GPS-
приемника
Unit_Number
integer (10)
not null
Номер юнита
LONGITUDE
float (53)
not null
Координата
долготы
LATITUDE
float (53)
not null
Координата
широты
ALTITUDE
float (53)
not null
Координата
высоты
SPEED
float (53)
not null
Скорость
транспортного
средства
SATELLITE
integer (10)
not null
Количество
спутников,
определенных
GPS-модемом
GPS_DATETIME
datetime (24)
not null
Дата и время
фиксирования
транспортного
средства
UTC_DATETIME
datetime (24)
not null
Дата и время по
UTC
93
Продолжение таблицы 3.7.
Название колонки
Тип данных Ограничения
Описание
DIRECTION
float (53)
not null
Направление, куда
движется
транспортное
средство
(измеряется в
радианах от 0 до
6,28…),
ODOMETER
float (53)
-
Подсчет
пройденного
расстояния по GPS
данным
MESSAGE_NUMBER
integer (10)
not null
Номер сообщения
IGNITION
tinyint (3)
not null
Включено или
выключено
зажигание
DOOR_SENSOR
tinyint (3)
not null
Датчик
открытия/закрытия
двери
SHOCK_SENSOR
tinyint (3)
not null
Датчик удара
(столкновения)
транспортного
средства
OILPRESSURE_SENSOR tinyint (3)
not null
Датчик давления
масла
HOOD_LOCK
tinyint (3)
not null
Датчик
открытия/закрытия
капота
DISTRESS_ALERT
tinyint (3)
default 0
Сигнал тревоги
INTERNAL_LIGHTS
tinyint (3)
not null
Свет в салоне
включен/выключен
FUEL_LEVEL
integer (10)
not null
Уровень топлива в
баке
3.3.2 Реализация интерфейса пользователя
В данном подпункте будут представлены основные формы
графического интерфейса пользователя реализованной автоматизированной
системы диспетчерского наблюдения. Также будут приведены сценарии
работы с интерфейсом пользователя.
94
3.3.2.1 Основные формы графического интерфейса пользователя
Основным интерфейсом разработанной системы является окно работы
с главным клиентом. Рассмотрим его подробнее (рисунок 3.1).
В самом верху окна изображено название системы, а также
стандартные кнопки «Свернуть окно на панель задач», «Свернуть/развернуть
окно», «Закрыть окно».
Чуть ниже расположено главное меню, которое состоит подменю
«Файл», «Разделение доступа», «Соединения», «Окна», «Слежение»,
«Рапорты» и «Команды».
Рисунок 3.1 – Основное окно работы с главным клиентом
В пункте меню «Файл» находятся подменю «Просмотреть лог»,
«Обновить список юнитов», «Выход».
В результате нажатия на подменю «Просмотреть лог» открывается
форма «Лог изменений» (рисунок 3.2).
Для поиска данных в Логе используются такие фильтры:
- выбор оператора (отметка в списке операторов);
- выбор юнита (отметка в списке юнитов);
- выбор интервала дат (выбор даты с … по …).
После задания параметров поиска нужно нажать на кнопку
. Для
сортировки по столбцу – нажать на заголовок столбца. Для экспорта
результатов запроса – нажать на кнопку
. Для окончания просмотра –
нажать на выход
.
95
Рисунок 3.2 – Окно «Лог изменений»
В результате нажатия на подменю «Обновить список юнитов»
обновляется список соответствия «Юнит \ Авто», который находится под
главным меню. Это обновление целесообразно проводить после
редактирования данных о юнитах, транспортных средствах и соответствиях
«юнит-транспортное средство» в таблицах БД.
В результате нажатия на подменю «Выход» происходит выход из
системы АСДН.
В пункте меню «Разделение доступа» находятся подменю
«Пользователи и группы» и «Наблюдение за автомобилями».
При выборе «Пользователи и группы» вызывается форма
«Пользователи и роли» (рисунок 3.3).
На закладке «Пользователи» можно:
- добавить, редактировать, удалить пользователя системы;
- отнести пользователя системы к одной или нескольким группам
(назначить пользователю роль(и)).
Добавление пользователя выполняется по нажатию на кнопку
«Добавить…». При этом выдается форма «Добавить пользователя». Для
добавления пользователя необходимо ввести значения в поля «Имя
пользователя», «Описание», «Пароль», «Подтвердите пароль». При нажатии
на кнопку «ОК» пользователь вносится в список пользователей системы. При
нажатии на кнопку «Отмена» происходит отмена операции.
После добавления пользователь сможет входить в систему при запуске,
вводя свой логин и пароль.
Удаление пользователя выполняется по нажатию на кнопку
«Удалить…». При этом выдается окно подтверждения или отмены операции.
Для переименования пользователя или изменения пароля следует
выбрать пользователя и нажать правую кнопку мыши для вызова
контекстного меню.
Для переименования нужно выбрать из контекстного меню действие
«Переименовать», при этом выдается форма с полем «Новое имя
пользователя». После введения нового имени при нажатии на кнопку «ОК»
96
измененное имя пользователя сохраняется. При нажатии на кнопку «Отмена»
происходит отмена операции. Если поле остается пустым и при этом нажать
на кнопку «ОК», то появляется сообщение об ошибке «Неверно введены
данные».
Рисунок 3.3 – Форма «Пользователи и роли» (закладка «Пользователи»)
Для изменения пароля нужно выбрать из контекстного меню действие
«Изменить пароль», при этом выдается форма с полями «Новый пароль»,
«Подтвердите новый пароль». После введения одинакового пароля в оба поля
при нажатии на кнопку «ОК» измененный пароль пользователя сохраняется.
При нажатии на кнопку «Отмена» происходит отмена операции. Если поля
остаются пустым и при этом нажать на кнопку «ОК», то появляется
сообщение об ошибке «Неверно введены данные». Если в поля введены
различные пароли, и при этом нажать на кнопку «ОК», то появляется
сообщение об ошибке «Пароль некорректно подтвержден».
Для отнесения пользователя к роли (группе) следует выбрать
пользователя из списка, после чего в нижней части окна будут показаны
доступные и назначенные роли. Для назначения роли пользователю, нужно
выбрать ее в списке доступных ролей и нажать на кнопку «>>». Для того,
чтобы убрать назначенную роль, нужно выбрать ее в списке назначенных
ролей и нажать на кнопку «<<».
На закладке «Роли» (рисунок 3.4) можно:
- добавить, редактировать, удалить роль;
- назначить ролям права доступа к защищенным объектам и
функциям системы.
97
Рисунок 3.4 – Форма «Пользователи и роли» (закладка «Роли»)
Для каждой роли списка формируется маска доступа – упорядоченная
битовая строка, определяющая права доступа для защищенной функции или
операции над объектом. Например, на рисунке 3.4 для роли Operator по
группе функций «Ведение БД объектов» разрешены лишь две операции:
просмотр информации о доступных авто\водителях и просмотр информации
о доступных юнитах.
Список ролей системы и их права доступа формируются
Администратором системы.
Для добавления новой роли в систему следует нажать на кнопку
«Создать…». При этом выдается форма «Новая роль». Для добавления новой
роли необходимо ввести значение в поле «Введите название роли». При
нажатии на кнопку «ОК» новая роль вносится в список ролей. При нажатии
на кнопку «Отмена» происходит отмена операции.
Для удаления роли необходимо выбрать нужную роль из выпадающего
списка «Имя» и нажать на кнопку «Удалить…». При этом выдается окно
подтверждения или отмены операции.
Для задания прав доступа для роли необходимо выбрать нужную роль
из выпадающего списка «Имя». После этого нужно установить (или снять)
указатели в графе «Разрешено» на закладках «Автомобиль», «Карта»,
«Функции», «Отчеты», «ПС безопасности» и «Ведение БД объектов». Далее
необходимо нажать на кнопку «Задать права доступа». При этом выдается
окно подтверждения или отмены операции. Нажать «ОК» для
подтверждения. Изменения вступают в силу после следующего входа в
систему.
Для окончания работы с пользователями и ролями необходимо нажать
на кнопку «Выход», которая находится на обеих вкладках.
98
В пункте меню «Соединения» находится подменю «Установки». При
нажатии на подменю «Установки» откроется окно «Установки», в котором
нужно отметить, какие соединения нужно установить (SMPP и GPRS).
В пункте меню «Окна» находятся подменю «Описание объектов»,
«Юниты», «Автомобили», «Водители», «Данные GPS», «Карта».
В результате нажатия на подменю «Описание объектов» открывается
форма «Администрирование Реестра», использующаяся для выполнения
операций администрирования реестра объектов, хранящихся в базе данных
(рисунок 3.5).
Форма «Администрирование Реестра» имеет такие пункты меню, как
«Типы объектов и отношения», «Отношения», «Связи между таблицами», а
также такие закладки, как «Типы объектов», «Отношения».
Закладка «Типы объектов» предназначена для редактирования
структуры реестра объектов (добавление, изменение, удаление таблиц БД,
состава их атрибутов). Изначально в базе данных присутствуют пять типов
объектов (Юниты, Автомобили, Водители, Клиенты, Данные GPS). Состав и
значения атрибутов таблиц
определяются Администратором БД
(должностным лицом предприятия).
На закладке "Типы объектов" расположены:
- в левой части – трехуровневый иерархический список типов
объектов;
- в правой части:
1) поля для описания таблиц и атрибутов;
2) кнопка команды «Сохранить», которую следует нажимать после
редактирования, иначе результаты редактирования на странице
не сохранятся.
Операции закладки «Типы объектов» вызываются через пункт меню
«Типы объектов и отношений». Перечень операций представлен в
таблице 3.8.
Рисунок 3.5 – Окно «Администрирование Реестра»
99
Таблица 3.8 – Операции закладки «Типы объектов»
Операция
Назначение
Вверх (Вниз)
Перемещение атрибута таблицы (на третьем уровне
иерархического списка) в указанном направлении на
одну позицию. Выполняется для формирования
порядка атрибутов на панели редактирования
объектов
Добавить атрибут
Добавление атрибута к набору атрибутов таблицы
типа объекта (не включает новый атрибут в
физическую таблицу в БД)
Включить атрибут в
таблицу
Добавление атрибута в состав атрибутов таблицы в
БД системы
Удалить атрибут
Удаление атрибута из атрибутов таблицы в БД
системы (если включен), либо удаление описания
атрибута
Добавить таблицу
Добавление таблицы в состав таблиц типа объекта
Включить таблицу в
БД
Добавление таблицы в состав таблиц типа объекта в
БД системы
Удалить таблицу
Удаление таблицы из БД либо удаление описания
таблицы
Закрыть
Завершение работы с формой
Сохранить
Сохранить введенные значения
Закладка «Отношения» предназначена для редактирования видов
отношений между объектами БД. Наименования отношений и значения
атрибутов их описания определяются Администратором БД (должностным
лицом предприятия).
Операции закладки «Отношения» вызываются через пункты меню
«Отношения» и «Связи между таблицами». Перечень операций представлен
в таблице 3.9.
Таблица 3.9 – Операции закладки «Отношения»
Операция
Назначение
Добавить
Добавление отношения
Удалить
Удаление отношения
Сохранить
Сохранить введенные значения
Пункт меню «Юниты» предназначен для внесения в базу данных
информации о блоке (номера блока, протокола работы блока…),
установленном в транспортном средстве. В результате нажатия на подменю
«Юниты» открывается окно «Юниты» (рисунок 3.6).
100
Рисунок 3.6 – Окно «Юниты»
В пункте меню «Юнит» окна «Юнит» нужно выбрать подменю
«Создать», после чего нижняя половина окна станет активной (рисунок 3.7).
Для внесения или изменения информации о юните (блоке) следует
дважды кликнуть на белое поле напротив описания интересующего
параметра. Изменение одного из параметров меню «Юниты» на неверное
может привести к неправильной работе оборудования.
Рисунок 3.7 – Атрибуты нового юнита
101
Определяющими для работы системы являются «Номер юнита»,
«Номер SIM» и «Тип юнита», поэтому их нужно заполнять обязательно.
Параметры «Информация канала», «Номер модема», «ID модема» следует
оставить без изменения. После заполнения полей для сохранения введенной
информации в базе данных необходимо нажать на кнопку «Сохранить».
В результате нажатия на подменю «Автомобили» открывается форма
«Автомобили» (рисунок 3.8).
Рисунок 3.8 – Окно «Автомобили»
Для создания учетной записи транспортного средства в пункте меню
«Автомобили» окна «Автомобили» нужно выбрать подменю «Создать»,
после чего нижняя половина окна станет активной (рисунок 3.9).
Для внесения или изменения информации о транспортном средстве
следует дважды кликнуть на белое поле напротив описания интересующего
параметра.
В строке «Примечание» указывается произвольная информация,
например, о состоянии транспортного средства.
102
Рисунок 3.9 – Атрибуты нового транспортного средства
Для присвоения определенному транспортному средству юнита
необходимо кликнуть на кнопку
в группе «Юнит» справа от поля «Юнит
№». В результате будет открыто окно «Выбор значения из классификатора»,
в котором следует выбрать номер блока, который установлен в автомобиле.
После чего нужно нажать на кнопку «ОК» для сохранения присвоения юнита
определенному транспортному средству. После нажатия на кнопку ОК в
меню «Юнит» будет указано, что данный юнит (блок), карточка, которая
установлена в юните (блоке) и тип юнита, автоматически присвоены
созданному транспортному средству. При нажатии на кнопку
в группе
«Юнит» справа от поля «Юнит №» можно быстро перейти к информации о
юните.
После проделанных выше действий для сохранения введенной
информации в базе данных и дальнейшей работы с ней необходимо нажать
на кнопку «Сохранить».
В результате нажатия на подменю «Водители» открывается форма
«Водители» (рисунок 3.10).
103
Рисунок 3.10 – Окно «Водители»
Для создания записи водителя и присвоения его транспортному
средству в пункте меню «Водители» окна «Водители» нужно выбрать
подменю «Создать», после чего нижняя половина окна станет активной
(рисунок 3.11).
Рисунок 3.11 – Атрибуты нового водителя
104
Ввод информации о водителях выполняется аналогично внесению
информации о транспортном средстве. Для сохранения введенной
информации в базе данных необходимо нажать на кнопку «Сохранить».
Для закрепления водителя за транспортным средством нужно перейти в
меню «Окна» подменю «Автомобили» главного окна «АСДН». Там в группе
«Водители» необходимо нажать на кнопку
«Добавить водителя», после
чего откроется окно выбора водителей. После чего нужно нажать на кнопку
«Сохранить».
Пункт меню «Данные GPS» предназначен для просмотра показаний
датчиков и состояния транспортного средства. В результате нажатия на
подменю «Данные GPS» открывается форма «Данные GPS в реальном
времени» (рисунок 3.12).
Форма «Данные GPS в реальном времени» имеет пункт меню
«Сообщения», а также такие закладки, как «Данные GPS и состояние»,
«Входы/Выходы датчиков».
Рисунок 3.12 – Форма «Данные GPS в реальном времени»
Пункт меню «Сообщения» содержит такие подпункты, как «Показать
на карте», «Удалить текущее», «Очистить все».
Подменю «Показать на карте» отображает на карте координаты
местонахождения транспортного, которые были выделены в закладке
«Данные GPS и состояние».
Подменю «Удалить текущее» удаляет выделенную в закладке «Данные
GPS и состояние» строку. При этом выдается окно подтверждения или
отмены операции.
Подменю «Очистить все» удаляет все строки в закладках «Данные GPS
и состояние» и «Входы/Выходы датчиков». При этом выдается окно
подтверждения или отмены операции.
105
В окне «Данные GPS в реальном времени» на закладках «Данные GPS
и состояние» и «Входы/Выходы датчиков» появятся значения параметров
транспортного средства в том случае, если пользователем был отправлен
запрос статуса, и от юнита был получен ответ.
В результате нажатия на подменю «Карта» открывается окно с картой
(рисунок 3.13).
Форма «Карта» имеет пункты меню «Запрос», «Отчет» и кнопки
«Загрузить карту», «Рука», «Увеличить», «Уменьшить», «Центрировать»,
«Вся карта», «Информация», «Поиск».
В меню «Запрос» содержаться подменю «Запрос по дате», «Запрос за
период», «Запрос последнего местоположения».
Рисунок 3.13 – Окно с загруженной картой
При нажатии на подменю «Запрос по дате» откроется окно «Запрос по
дате», в котором нужно будет выбрать интересующее транспортное средство,
либо все транспортные средства (для этого необходимо нажать на кнопку
«Все»), либо несколько транспортных средств (для этого необходимо, нажав
на клавиатуре клавишу «Ctrl», кликнуть на строке левой кнопкой мыши).
После чего нужно выбрать необходимую дату и нажать на кнопку «ОК». Для
отмены операции нужно нажать на кнопку «Отмена». После нажатия на
кнопку «ОК» откроется окно «Результат запроса», состоящее из двух таблиц
и кнопок «Показать трек» и «Центрировать точку». В правой таблице будет
содержаться список выбранных транспортных средств с их юнитами, а в
левой – следующая информация по этому дню:
- UTC Дата\время – дата и время фиксирования транспортного
средства по UTC;
106
- долгота – координата долготы на момент времени фиксирования
транспортного средства;
- широта – координата широты на момент времени фиксирования
транспортного средства;
- высота – координата высоты на момент времени фиксирования
транспортного средства;
- кол-во спутников – количество спутников, зафиксированных
транспортное средство;
- скорость – скорость транспортного средства;
- направление – направление движения транспортного средства;
- пройдено – подсчет пройденного расстояния по GPS данным;
- зажигание – включено или выключено зажигание;
- топливо – уровень топлива в баке.
При нажатии на кнопку «Показать трек» на карте будет полностью
отображен маршрут следования транспортного средства. При нажатии на
кнопку «Центрировать точку» выбранная точка окажется в центре экрана и
несколько раз мигнет.
При нажатии на подменю «Запрос за период» откроется окно «Запрос
за период», в котором нужно будет выбрать интересующее транспортное
средство, либо все транспортные средства (для этого необходимо нажать на
кнопку «Все»), либо несколько транспортных средств (для этого необходимо,
нажав на клавиатуре клавишу «Ctrl», кликнуть на строке левой кнопкой
мыши). После чего нужно выбрать две необходимых даты – с какого числа и
по какое число. Далее нужно нажать на кнопку «ОК». Для отмены операции
нужно нажать на кнопку «Отмена». После нажатия на кнопку «ОК»
откроется окно «Результат запроса», состав которого был описан выше.
При нажатии на подменю «Запрос последнего местоположения»
откроется окно «Запрос последнего местоположения», в котором нужно
будет выбрать интересующее транспортное средство, либо все транспортные
средства (для этого необходимо нажать на кнопку «Все»), либо несколько
транспортных средств (для этого необходимо, нажав на клавиатуре клавишу
«Ctrl», кликнуть на строке левой кнопкой мыши). После чего нужно выбрать
или ввести количество точек (последних зафиксированных спутником
позиций транспортного средства). Далее нужно нажать на кнопку «ОК». Для
отмены операции нужно нажать на кнопку «Отмена». После нажатия на
кнопку «ОК» откроется окно «Результат запроса», состав которого был
описан выше.
В меню «Отчет» содержаться подменю «Отчет по дате», «Отчет за
период».
При нажатии на подменю «Отчет по дате» откроется окно «Отчет по
дате», в котором нужно будет выбрать интересующее транспортное средство,
либо все транспортные средства (для этого необходимо нажать на кнопку
«Все»), либо несколько транспортных средств (для этого необходимо, нажав
на клавиатуре клавишу «Ctrl», кликнуть на строке левой кнопкой мыши).
После чего нужно выбрать необходимую дату и тип отчета. Далее нужно
107
нажать на кнопку «ОК». Для отмены операции нужно нажать на кнопку
«Отмена». После нажатия на кнопку «ОК» откроется окно сохранения отчета
«Сохранить как…», где нужно ввести название отчета и нажать на кнопку
«Сохранить». Отчет сохранится в формате «.html».
При нажатии на подменю «Отчет за период» откроется окно «Отчет за
период», в котором нужно будет выбрать интересующее транспортное
средство, либо все транспортные средства (для этого необходимо нажать на
кнопку «Все»), либо несколько транспортных средств (для этого необходимо,
нажав на клавиатуре клавишу «Ctrl», кликнуть на строке левой кнопкой
мыши). После чего нужно выбрать две необходимых даты (с какого числа и
по какое число) и тип отчета. Далее нужно нажать на кнопку «ОК». Для
отмены операции нужно нажать на кнопку «Отмена». После нажатия на
кнопку «ОК» откроется окно сохранения отчета «Сохранить как…», где
нужно ввести название отчета и нажать на кнопку «Сохранить». Отчет
сохранится в формате «.html».
При нажатии на кнопку «Загрузить карту» выпадет список карт
городов Украины, в котором нужно выбрать интересующий город.
После нажатия на кнопку «Рука» можно двигать карту.
Кнопка «Увеличить» нужна для увеличения изображения на карте.
Кнопка «Уменьшить» нужна для уменьшения изображения на карте.
После нажатия на кнопку «Центрировать» нужно нажать на любую
точку на карте, после чего выбранная точка окажется в центре экрана и
несколько раз мигнет.
После нажатия на кнопку «Вся карта» будет изображена карта всего
города.
После нажатия на кнопку «Информация» необходимо кликнуть на
интересующем месте на карте левой кнопкой мыши. После этого откроется
окно «Инфо» с информацией о данном месте (район, улица, координаты
долготы и широты и т.д.).
Для осуществления поиска необходимо нажать на кнопку «Поиск»,
после чего откроется окно «Поиск», в котором необходимо ввести название
искомого объекта, и нажать на кнопку «Найти».
В пункте меню «Слежение» находятся подменю «Слежение в реальном
времени», «Планировщик», «Тревоги».
Подменю «Слежение в реальном времени» имеет такие пункты, как
«Отменить», «Каждые 14 сек», «Каждые 28 сек», «Каждую 1 мин», «Каждые
2 мин», «Каждые 5 мин». Здесь нужно выбрать необходимый временной
режим, то есть, с какой периодичностью блок, установленный в автомобиле,
будет отправлять информацию о местоположении.
При нажатии на подменю «Планировщик» откроется окно
«Планировщик выгрузки логов» (рисунок 3.14). Окно «Планировщик»
предназначено для автоматической сгрузки информации с Юнитов,
установленных на транспортных средствах.
В данном окне следует выбрать, через сколько минут должна
происходить сгрузка информации с юнитов. Также нужно выставить
108
количество дозвонов к юниту при неудачной попытке выгрузить лог и снять
флажок «Остановить автоматическую загрузку логов» (если флажок стоит,
автоматическая выгрузка логов производиться не будет). Далее необходимо
отметить, с каких транспортных средств будет производиться выгрузка
логов.
Для выбора всех транспортных средств нужно нажать на кнопку
«Пометить все авто». Чтобы убрать все отметки с транспортных средств,
нужно нажать на кнопку
«Убрать все отметки». Чтобы инвертировать
отметки, необходимо нажать на кнопку
«Инвертор отметок». Для
сохранения изменений нужно нажать на кнопку
«Сохранить параметры».
Для выхода из планировщика следует нажать на кнопку
«Выйти из
планировщика».
Рисунок 3.14 – Окно «Планировщик выгрузки логов»
При нажатии на подменю «Тревоги» открывается окно «Тревоги», в
котором нужно выбрать диапазон дат и нажать на кнопку «ОК». После
нажатия на кнопку «ОК» откроется окно сохранения запроса тревог
«Сохранить как…», где нужно ввести название файла, в котором будут
сохранены результаты запроса, и нажать на кнопку «Сохранить». Результаты
запроса сохранятся в формате «.html».
В пункте меню «Рапорты» находятся подменю «Запросы», «Отчеты».
Действия, которые нужно совершить для работы с данными пунктами
подменю, аналогичны описанным выше для окна «Карта».
В пункте меню «Команды» находятся подменю «Запрос статуса»,
«Опросить все юниты», «Другие».
109
«Запрос статуса»
предназначено
для запроса
параметров
транспортного средства на данный момент времени.
Подменю «Опросить все юниты» аналогично предыдущему, только в
данном случае опрашиваются все юниты, которые прикреплены к
транспортным средствам.
Подменю «Другие» содержит такие пункты, как «Сгрузить
накопленные события (дозвон)» и «Сгрузить накопленные события (SMS)».
При нажатии на подменю «Сгрузить накопленные события (дозвон)»
модем позвонит к юниту и загрузит всю накопленную информацию. То есть
дозвон будет осуществлен с телефонной карты, установленной в офисе
(тарифицируется как исходящий офисный и входящий на карту,
установленную в транспортном средстве).
При нажатии на подменю «Сгрузить накопленные события (SMS)»
модем отправит SMS юниту, которое инициирует звонок юнита на модем
системы. То есть дозвон будет осуществлен с телефонной карты,
установленной в транспортном средстве, после отправки SMS с карточки,
установленной в офисе (тарифицируется как исходящий с карты,
установленной в транспортном средстве, и входящий на офисную карту плюс
одно SMS с офисной карты).
3.3.2.2 Сценарий «Определение местоположения транспортного
средства в режиме реального времени»
В основном окне главного клиента (рисунок 3.1) в пункте меню
«Юнит\Авто» из выпадающего списка нужно выбрать необходимый
автомобиль (рисунок 3.15).
Рисунок 3.15 – Выбор транспортного средства
110
Здесь «11653» – номер блока, установленного на транспортном
средстве,
«Murano» –
государственный
регистрационный
номер
транспортного средства.
Далее необходимо зайти в меню «Команды» и выбрать пункт меню
«Запрос статуса» (рисунок 3.16).
Рисунок 3.16 – Выбор команды «Запрос статуса»
Здесь «11653» – номер блока, установленного на выбранном
транспортном средстве.
После нажатия на команду «Запрос статуса» в главном окне АСДН
появится сообщение (рисунок 3.17).
Рисунок 3.17 – Сообщение «Запрос статуса»
111
Теперь нужно зайти в меню «Окна» и выбрать пункт меню «Данные
GPS» (рисунок 3.18).
Рисунок 3.18 – Выбор окна «Данные GPS»
После нажатия на «Данные GPS» откроется окно «Данные GPS в
реальном времени» (рисунок 3.19). Когда SMS вернется, в окне «Данные GPS
в реальном времени» появятся значения параметров автомобиля.
Рисунок 3.19 – Окно «Данные GPS в реальном времени»
112
Далее для получения местонахождения транспортного средства
необходимо два раза кликнуть левой кнопкой мыши на данной строке (или
по правой кнопке выбрать «Показать на карте»). Строка, по которой нужно
кликнуть показана на рисунке 3.20.
Рисунок 3.20 – Строка, по которой нужно кликнуть
Если все будет сделано правильно, на экране откроется окно «Карта»
(рисунок 3.21), где будет изображено местонахождение автомобиля,
соответствующее координатам «Долгота-Широта», дате и времени в данных
GPS.
Рисунок 3.21 – Местонахождение транспортного средства на карте
3.3.2.3 Сценарий «Мониторинг использования транспортного
средства по заданному количеству позиций последнего местоположения»
В основном окне главного клиента (рисунок 3.1) в пункте меню
«Юнит\Авто» из выпадающего списка нужно выбрать необходимый
автомобиль (рисунок 3.15).
Далее необходимо загрузить информацию об использовании с
оборудования, установленного в выбранном транспортном средстве. Для
этого нужно зайти в меню «Команды», выбрать пункт меню «Другие» и там
выбрать, по какому алгоритму будет происходить загрузка информации,
нажав на подменю «Сгрузить накопленные события (дозвон)», либо
«Сгрузить накопленные события (SMS)» (рисунок 3.22).
113
Рисунок 3.22 – Загрузка накопленной информации с юнита
После этого в главном окне АСДН появится сообщение о дозвоне к
юниту транспортного средства (рисунок 3.23).
Рисунок 3.23 – Дозвон к юниту
114
Для того, чтобы посмотреть результаты движения транспортного
средства, необходимо воспользоваться «Картой». Для этого нужно зайти в
меню «Окна» и выбрать подменю «Карта» (рисунок 3.24).
Рисунок 3.24 – Выбор пункта «Карта»
После нажатия на подменю «Карта» на экране откроется окно с картой
(рисунок 3.13). Теперь необходимо выбрать карту нужного города. Для этого
необходимо воспользоваться командой «Выбрать карту…». После выбора
карты необходимого города можно приступить к обработке информации.
Вся информация, полученная от транспортного средства, извлекается
через пункт меню «Выбрать запрос…» (рисунок 3.25).
Рисунок 3.25 – Выбор запроса последнего местоположения транспортного
средства
115
После нажатия на подменю «Запрос местоположения» появится окно, в
котором нужно будет выбрать необходимое транспортное средство (то есть
то, с юнита которого была загружена информация) и задать количество
последних зафиксированных спутником позиций транспортного средства
(рисунок 3.26).
Рисунок 3.26 – Задание параметров запроса
После задания необходимых параметров нужно нажать на кнопку
«ОК».
Результатом запроса будет таблица с информацией об использовании
выбранного транспортного средства за выбранное последнее количество
точек. Окно с данной таблицей показано на рисунке 3.27.
Рисунок 3.27 – Результат запроса последних 10 точек
116
3.2 Выводы
В данном разделе были представлены результаты реализации
автоматизированной системы диспетчерского наблюдения в виде нескольких
основных таблиц базы данных, скриншотов разработанного приложения и
программного кода, представленного в одном из приложений данной
дипломной работы.
117
4 ОХРАНА ТРУДА И ОКРУЖАЮЩЕЙ СРЕДЫ
Охрана труда − это система правовых, социально-экономических,
организационно-технических,
санитарно-гигиенических
и
лечебно-
профилактических способов, направленных на сохранение здоровья и
трудоспособности человека в процессе работы.
4.1 Требования к помещениям для эксплуатации ВДТ ПК
Размещение рабочих мест с ВДТ ПК в подвальных помещениях, на
цокольных этажах − запрещен.
Площадь на одно рабочее место может составлять не меньше, чем
6 кв.м, а объем – не менее 20,0 куб. м.
Помещение для работы по ВДТ должны иметь естественное и
искусственное освещения соответственно СНиП ІІ-4-79.
Естественное освещение может осуществляться через световые
прорезы, ориентированные преимущественно на север или северо-восток и
обеспечивать коэффициент естественной освещенности (КПО) не ниже 1,5%.
Рассчитывается КПО по методике, изложенной в СНиП ІІ-4-79.
Производственные помещения для работы с ВДТ (операторские,
диспетчерские) не должны граничить с помещениями, в которых уровни
шума и вибрации превышают допустимые значения (производственные цеха,
мастерские и т.п.) согласно СН 3223-85, СН 3044-84, ГР 2411-81, ГОСТ
12.1.003-83.
Звукоизоляция оградительных конструкций помещений с ВДТ может
обеспечивать параметры шума, которые отвечают требованиям СН 3223-85,
ГОСТ 12.1.003-83, ГОСТ 12.1.012-90.
Помещение для работы с ВДТ должны быть оборудованы системами
отопления, кондиционирования воздуха или вытяжной вентиляцией
соответственно СНиП 2.04.05-91. Нормированные параметры микроклимата,
ионного состава воздуха, содержимого вредных веществ должны отвечать
требованиям СН 4088-86, СН 2152-80, ГОСТ 12.1.005-88, ГОСТ 12.1.007-76.
Запрещается для обрамления интерьера помещений с ВДТ применять
полимерные материалы (деревянно-стружечные плиты, обои, которые
моются, рулонные синтетические материалы, слоистый бумажный пластик и
т.п.), которые поглощают из воздуха вредные химические вещества.
Полимерные материалы для внутреннего обрамления помещений с
ВДТ могут быть использованы при наличии разрешения органов
государственной санитарно-эпидемической службы.
Производственные помещения могут оборудоваться шкафами для
сохранения документов, магнитных дисков, полками, стеллажами,
тумбочками и т.п., с учетом площади помещений.
118
В помещениях с ВДТ следует ежедневно делать влажную уборку.
Помещение с ВДТ должны быть оснащены аптечками первой медицинской
помощи.
В помещениях с ВДТ должны быть оборудованные бытовые
помещения для отдыха во время работы, комната психологической
разгрузки. В комнате психологической разгрузки следует предусмотреть
установление устройств, для приготовления и раздачи тонизирующих
напитков, а также места для занятий физической культурой.
Требования для вспомогательных помещений должны отвечать СНиП
2.09.04-87.
4.2 Гигиенические требования к
параметрам среды
в
помещениях с ВДТ ПК
Рассмотрим основные параметры среды, обеспечивающие комфортную
работу с ВДТ ПК.
4.2.1 Микроклимат
Под метеорологическими условиями производственной среды согласно
ГОСТ 12.1.005-88 понимают сочетания температуры, относительной
влажности, скорости движения и запыленности воздуха. Перечисленные
параметры оказывают огромное влияние на функциональную деятельность
человека, его самочувствие и здоровье и на надежность работы средств
вычислительной техники.
С целью создания нормальных условий для персонала лабораторий с
использованием ПК установлены нормы производственного микроклимата
(ГОСТ 12.1.005-88). Эти нормы устанавливают оптимальные и допустимые
значения температуры, относительной влажности и скорости движения
воздуха для рабочей зоны помещений вычислительного центра.
Под оптимальными микроклиматическими параметрами принято
понимать такие, которые при длительном и систематическом воздействии на
человека обеспечивают сохранение нормального функционального и
теплового состояния организма без напряжения реакций терморегуляции,
создают ощущение теплового комфорта и являются предпосылкой высокого
уровня работоспособности.
Допустимые микроклиматические параметры могут вызывать
преходящие и быстро нормализующиеся изменения функционального и
теплового состояния организма и напряжение реакций терморегуляции, не
выходящие за пределы физиологических возможностей, не создающие
нарушений состояния здоровья, но вызывающие дискомфортные тепло
ощущения, ухудшение самочувствия и понижение работоспособности.
119
4.2.2 Освещение
К современному производственному освещению, в том числе
освещению помещений лабораторий, оснащенных ПК, предъявляются
высокие требования как гигиенического, так и технико-экономического
характера. Правильно спроектированное и выполненное освещение
обеспечивает высокий уровень работоспособности, оказывает положительное
психологическое воздействие на работающих, способствует повышению
производительности труда.
На рабочем месте обеспечивается совмещенное освещение
(естественное и искусственное).
Основные требования к естественному освещению были изложены в
документах ГОСТов. Искусственное освещение в помещениях с рабочими
местами, оборудованными ВДТ ПК, может осуществляться системой общего
равномерного освещения. В производственных и административно-
общественных помещениях, в случае преобладающей работы с документами,
допускается применение системы комбинированного освещения (кроме
системы общего освещения, дополнительно устанавливаются светильники
местного освещения).
Для искусственного освещения помещений, в которых используются
ПК и измерительная аппаратура, следует использовать люминесцентные
лампы, у которых высокая световая отдача (до 75 лм/Вт и более),
продолжительный срок службы (до 10000 ч), малая яркость светящейся
поверхности, близкий к естественному спектральный состав излучаемого
света, что обеспечивает хорошую цветопередачу.
Согласно действующим строительным нормам и правилам СНиП II-79
для совмещенного освещения регламентирован коэффициент естественной
освещенности КЕО.
В качестве источников света в случае искусственного освещения
должны применяться преимущественно люминесцентные лампы типа ЛБ. В
случае устройства отраженного освещения в производственных и
административно-общественных помещениях допускается применение
металогалогенных ламп мощностью 250 Вт. Допускается применение
газоразрядных ламп в светильниках местного освещения.
Показатель освещенности в случае использования источников общего
искусственного освещения в производственных помещениях может не
превышать 20, а показатель дискомфорта в административно-общественных
помещениях может быть не больше, чем 40.
Рекомендуемая яркость в поле зрения операторов должна находиться в
пределах 1:5 – 1:10.
4.2.3 Шум и вибрация
Шум является одним из наиболее распространенных в производстве
вредных факторов. Проявление вредного воздействия шума на организм
120
человека разнообразно − он вызывает различные биологические
раздражения, патологические изменения, функциональные расстройства и
механические повреждения.
Основными физическими величинами, характеризующими шум в
какой-либо точке пространства, с точки зрения воздействия на человека,
являются: интенсивность, звуковое давление, частота.
Согласно ГОСТ 12.1.003-83 ССБТ «Шум. Общие требования
безопасности» и СН №3223-85 нормируемой шумовой характеристикой
рабочих мест при постоянном шуме являются уровни звуковых давлений в
децибелах в октавных полосах.
Совокупность таких уровней называется предельным спектром, номер
которого численно равен уровню звукового давления в октавной полосе со
среднегеометрической частотой 1000 Гц.
Уровни звукового давления в октавных полосах частот, равные звука и
эквивалентные равные звука на рабочих местах, оборудованных ВДТ ПК,
должны отвечать требованиям СН 3223-85, ГОСТ 12.1.003-83.
Оборудование, которое представляет источник шума (АЦП, принтеры
и т.п.), следует располагать вне помещения для работы с ВДТ ПК.
Для обеспечения допустимых уровней шума на рабочих местах следует
применять средства звукопоглощения, выбор которых может обосновываться
специальными инженерно-акустическими расчетами.
4.2.4 Неионизирующее электромагнитное излучение
Значение напряженности электростатического поля на рабочих местах
с ВДТ (как в зоне экрана дисплея, так и на поверхностях оснащения,
клавиатуры, печатающего устройства) должны не превышать предельно
допустимых согласно ГОСТ 12.1.045-84, СН 1757-77.
Значение напряженности электромагнитных полей на рабочих местах с
ВДТ должны отвечать нормативным значениям (ГДР N 3206-85, ГДР N 4131-
86, СН N 5802-91, ГОСТ 12.1.006-84).
Интенсивность потоков инфракрасного излучения может не превышать
допустимых значений соответственно СН 4088-86, ГОСТ 12.1.005-88.
Интенсивность потоков ультрафиолетового излучения не может
превышать допустимых значений соответственно СН 4557-88.
Ионизирующие электромагнитные излучения на расстоянии 0,05 м от
экрана к корпусу видеотерминала при любых положениях регулировочных
устройств не должны превышать 7,74*10
–12
А/кг, что отвечает эквивалентной
дозе 0,1 мбер/ч. (100 мкР/ч.).
4.2.5 Ионизирующее электромагнитное излучение
На ЭЛТ часто накапливается электростатический заряд. Как
показывают измерения, в момент включения напряженность поля мгновенно
возрастает до максимума, а затем постепенно уменьшается до
121
квазистабильного уровня. После выключения ВДТ регистрируют
отрицательную напряженность поля, которая постепенно уменьшается.
Результаты свидетельствуют о
значительном
разбросе
значения
напряженности электростатических полей от разных ВДТ. В исследованиях
при разных условиях измерения эти значения колебались от 8 до 75 кВ/м.
Измерения электростатического поля необходимо проводить с учетом
закономерностей его изменения, зависящих от расстояния, т.к.
электростатическое поле уменьшается на r
-1
«вблизи» экрана и на r
–3
«на
больших расстояниях от экрана» (более 30 см). Для предотвращения
образования значительной напряженности поля и защиты от статического
электричества
в помещениях с
ВДТ необходимо
использовать
нейтрализаторы и увлажнители, а полы должны иметь антистатическое
покрытие.
Защита от статического электричества должна проводиться в
соответствии
с
санитарно-гигиеническими
нормами
допустимой
напряженности электрического поля. Допустимые уровни напряженности
электростатических полей не должны превышать 20 кВ в течение часа (ГОСТ
12.1045-84).
Согласно «Предельно допустимым уровням воздействия постоянных
магнитных полей при работе с магнитными устройствами и магнитными
материалами» №1742-77 напряженность постоянного поля на рабочем месте
не должна превышать 8 кА/м, а для магнитных полей промышленной
частоты (А/м) − можно определить по формуле.
Вредное действие магнитного поля на человека проявляется при
напряженности 150 – 200 А/м. Поглощенная телом человека энергия
магнитного поля в 50 раз меньше поглощенной им энергии электрического
поля. Следовательно, отрицательное действие на организм человека при
работе с дисплеем оказывает электрическое поле.
Согласно ГОСТ 12.1.045-84 предельно допустимый уровень
напряженности электростатических полей (Е
пред.
) устанавливается равным
60кВ/м в течение часа.
4.3 Требования к организации и оснащению рабочих мест
с ВДТ ПК
Оснащение и организация рабочего места работающих с ВДТ ПК
должны обеспечивать соответствие конструкции всех элементов рабочего
места и их взаимного расположения эргономическим требованиям с учетом
характера и особенностей трудовой деятельности (ГОСТ 12.2.032-78, ГОСТ
22.269-76, ГОСТ 21.889-76).
Конструкция рабочего места пользователя ПК с ВДТ может обеспечить
поддержание оптимальной рабочей дозы.
Рабочие места с ВДТ следует так располагать относительно световых
отверстий, чтобы естественный свет падал сбоку, преимущественно слева.
122
При размещении рабочих столов с ВДТ следует выдерживать такие
расстояния: между боковыми поверхностями ВДТ – 1,2 м, расстояние от
тыльной поверхности одного ВДТ к экрану другого ВДТ – 2,5 м.
Конструкция рабочего стола должна отвечать современным
требованиям эргономики и обеспечивать оптимальное размещение на
рабочей поверхности используемого оснащения (дисплея, клавиатуры,
принтера) и документов.
Высота рабочей поверхности рабочего стола с ВДТ может
регулироваться в границах 680...800 мм, а ширина и глубина – обеспечивать
возможность выполнения операций в зоне достижимости моторного поля
(рекомендованные размеры: 600...1400 мм, глубина – 800...1000 мм).
Рабочий стул может быть подъемно-поворотным, с регулируемой
высотой, углом и наклона сидения, спинки и расстоянием от спинки к
переднему краю сидения. Поверхность сидения должна быть плоской, а
передний край – закругленным вниз. Регулирование любого из параметров
должно осуществляться независимо, легко и надежно фиксироваться. Шаг
регулирования элементов стула может составлять:
- для линейных размеров – 15...20 мм;
- для угловых размеров – 2...5 град.
Сила регулирования не может превышать 20 Н.
Высота спинки стула должна составлять 300±20 мм, ширина – не
меньше 380 см, радиус кривизны горизонтальной плоскости – 400 мм. Угол
наклона спинки должен регулироваться в границах 1...30 град. от
вертикального положения. Расстояние от спинки к переднему краю сидения
должно регулироваться в границах 260...400 мм.
Экран ВДТ должен располагаться на оптимальном расстоянии от глаз
пользователя, которое составляет 600...700 мм, но не ближе, чем за 600 мм с
учетом размера буквенно-цифровых знаков и символов.
Клавиатуру следует располагать на поверхности стола на расстоянии
100...300 мм от края, обращенного к работнику. Высота средней строки
клавиш должна не превышать 30 мм. Поверхность клавиатуры должна быть
матовой с коэффициентом отражения 0,4.
Расположение устройства ввода-вывода информации
может
обеспечивать хорошую видимость экрана ВДТ, удобство ручного управления
в зоне достижимости моторного поля высотой 900...1300 мм, шириной
400...500 мм. Для обеспечения защиты и достижение нормированных
уровней компьютерных излучений необходимо применение экранных
фильтров, локальных светофильтров (средств индивидуальной защиты глаз)
и других средств защиты, которые прошли испытание в аккредитованных
лабораториях и имеют ежегодный гигиеничный сертификат.
При оснащенности рабочего места с ВДТ лазерным принтером
параметры лазерного излучения должны отвечать требованиям СанПин
№5804-91.
123
4.4 Электробезопасность в помещениях с ВДТ ПК
Электрические установки, к которым относится практически все
оборудование ПК и оборудование лабораторий, представляют для человека
большую потенциальную опасность, так как в процессе эксплуатации или
проведения профилактических работ человек может коснуться частей,
находящихся под напряжением. Специфическая опасность электроустановок:
токоведущие проводники, корпуса стоек ПК и прочего оборудования,
оказавшегося под напряжением в результате повреждения (пробоя) изоляции,
не подают каких-либо сигналов, которые предупреждали бы человека об
опасности. Реакция человека на электрический ток возникает лишь при
протекании последнего через тело человека.
Проходя через тело человека, электрический ток оказывает на него
сложное
воздействие,
вызывая
термическое,
электролитическое,
механическое и биологическое действие. Любое из перечисленных
воздействий тока может привести к электрической травме, т.е. к
повреждению организма, вызванному воздействием электрического тока или
электрической дуги (ГОСТ 12.1.009-76).
4.5 Пожарная безопасность
Пожаром называют неконтролируемое горение во времени и
пространстве, наносящее материальный ущерб и создающее угрозу жизни и
здоровью людей
В современных ПК очень высокая плотность размещения элементов
электронных схем. В непосредственной близости друг от друга
располагаются соединительные провода, коммутационные кабели. При
протекании по ним электрического тока выделяется значительное количество
теплоты, что может привести к повышению температуры отдельных узлов до
80 – 100 C.
При этом возможно оплавление изоляции соединительных проводов,
их оголение и, как следствие, короткое замыкание, которое сопровождается
искрением, ведет к недопустимым перегрузкам элементов электронных схем.
Последние, перегреваясь, сгорают с разбрызгиванием искр.
Пожарная опасность производственных зданий и помещений
определяется особенностями выполняемого в них технологического
процесса, свойствами применяемых веществ и материалов, а также
условиями их обработки. По взрывопожарной и пожарной опасности
помещения и здания подразделяют на категории А, Б, В, Г, Д.
В зависимости от пределов огнестойкости строительных конструкций
СНиП 2.01.02-85 "Противопожарные нормы" установлены восемь степеней
огнестойкости зданий: I, II, III, IIIа, IIIб, IV, IVа, V.
124
4.6 Инженерный расчет задачи
Исходные данные для расчета защитного заземления:
- грунт – супесок;
- длина уголка – 4 м;
- размеры уголка – 6 х 6 см;
- линейное напряжение сети – 0,38 кВ;
- сопротивление естественного заземлителя – 20 Ом;
- длина кабельных линий – 25 км;
- длина воздушных линий – 12 км;
- в качестве электродов принять уголки.
Расчет защитного
заземления произведем для
нескольких
вертикальных стержневых заземлителей, погруженных в землю на
определенную глубину и соединенных параллельно горизонтальной
соединительной полосой.
Цель расчета заземляющего устройства – определение количества и
размеров заземлителей.
При расчете общего сопротивления заземляющей системы считают,
что все электроды включены параллельно. Однако фактическое
сопротивление будет большей вследствие эффекта взаимного экранирования
заземлителей. Этот эффект возникает из-за того, что каждый заземлитель
имеет свою зону действия растекание тока.
Определим допустимое сопротивление заземляющего устройства R
д
.
Для электроустановок напряжением до 1000В в общем случае считаем
R
д
= 4Ом.
Определяем необходимое сопротивление искусственных заземлителей:
д
п
п
д
ш
R
R
R
R
R
,
(4.1)
где R
n
– сопротивление естественных заземлителей.
Ом
R
ш
5
4
20
20
*
4
Определяем удельное сопротивление грунта. Для супеска оно
составляет = 300 Ом*м. Рассчитаем сопротивление растекания тока с
одного вертикального электрода R
1
.
Значение сопротивления рассчитаем по формуле:
l
t
l
t
b
l
l
R
2,
4
2,
4
ln
2
1
*
1,
2
ln
2
1
,
(4.2)
где
;
5.
0
0
м
t
;b
l
;3
1
t
125
;
2
1
0
t
t
Тогда:
;
5.
2
2
4
5.
0
м
t
;
06
.0 м
b
Ом
R
9.
64
4
2
2.
4
4
2
2.
4
ln
2
1
06
.0
4
1.
2
ln
4
14
.3
2
300
1
Так как сопротивление одного вертикального электрода больше
нужного R
д
, заземляющее устройство состоит из нескольких параллельно
соединенных одиночных заземлителей.
Необходимое количество вертикальных электродов определяется
зависимостью:
ш
1
R
R
n
,
(4.3)
где
- коэффициент взаимного экранирования электродов, который
зависит от количества электродов и их взаимного расположения.
Таким образом, для определения необходимого количества
вертикальных электродов необходимо определить расположение (в ряд или
по контуру), условное количество электродов n
’
и отношение расстояния
между заземлителями к их длине.
Возьмем расстояние между вертикальными электродами a равное 8м.
То есть a/l=2. При n=20 и расположении заземлителей по контуру
=0,67,
рассчитаем n:
3,
20
76
,4
67
,0
9,
64
n
.
(4.4)
Условное количество электродов и рассчитанное количество не
отличаются более чем на 10%, поэтому это количество можно считать
верным.
Рассчитывается сопротивление растекания тока искусственных
заземлителей. В качестве соединительной полосы используется сталь,
протянутая в грунте на ширину b. Ширину полосы примем равной 12 мм.
t
b
l
l
R
Г
*
*
2
ln
2
2
,
(4.5)
где
;b
l
t
l
3
.
Ом
R
Г
3,
8
2,
0
012
,0
152
2
ln
152
14
,3
2
300
2
126
Рассчитаем результирующее сопротивление заземляющего электрода с
учетом соединительной полосы:
n
R
R
R
R
R
Г
Г
Г
ш
1
1
,
(4.6)
где
Г
- коэффициент экранирования горизонтального электрода.
Г =
0,56 при a / l = 2.
Ом
R
Ш
65
,3
67
,0
20
3,
8
56
,0
9,
64
3,
8
9,
64
Схема заземляющего устройства представлена на рисунке 4.1.
Рисунок 4.1 − Схема размещения заземляющего устройства и его
присоединения к заземляющей установке
4.7 Выводы
Полученное сопротивление заземления не превышает допустимое R
Ш
,
таким образом, расчет проведен правильно и предложенная схема заземления
гарантирует устранение опасности поражения электрическим током при
переходе напряжения на нетоковедущие части (корпус) используемого
электрооборудования.
127
ПЕРЕЧЕНЬ ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ
1)
Структура і оформлення кваліфікаційних та курсових робіт.
Методичні вказівки для студентів професійного спрямування
―Комп’ютерна інженерія‖ / Укл. А.І. Вервейко, С.О. Нестеренко,
Є.В. Нікітенко. – Чернігів: ЧДТУ, 2002. – 28 с., рос. мовою;
2)
Бродин В.Б., Шагурин И.И. Микроконтроллеры. Архитектура,
программирование, интерфейс. – М.: Издательство ЭКОМ, 1999.
– 400с.:илл.
3)
Крэг Ларман Применение UML и шаблонов проектирования:
Введение в объектно ориентирований анализ и проектирование. -
- М.: Из-дательский дом "Вильяме". 2001. - 496 с.
4)
А.В. Гордеев, А.К. Молчанов. Системное программное
обеспечение. -СПб.: Питер. 2001. - 468 с.
5)
О.О.Навакатикян, В.В.Кальниш, С.М.Стрюков. Охрана труда
пользователей компьютерных видеодисплейных терминалов К.,
1997.-400с.
6)
Охорона праці. Методичні рекомендації до дипломного проекту
для студентів инженерно-технічних спеціальностей / Уклад.: Л.Д.
Косухіна, О.И.Сиза.- Чернігів: ЧТІ, 1997.- 26с.
7)
Методические указания к лабораторным работам по дисциплине
«Охрана труда» для студентов всех специальностей /Сост.
В.И.Коробко. –Киев: КПИ, -52с.
8)
Методический сайт по правилам оформления курсовых и
квалификационных работ [электронный ресурс]. Режим доступа:
URL: http://opra.cnox.chernihiv.net/. – Оформляем правильно.
9)
Справочно-информационный
портал
по
электронике
[электронный
ресурс].
Режим
доступа:
URL:
http://www.electromonter.info/handbook/symbol_271081.html.
–
Обозначения буквенно-цифровые в электрических схемах (ГОСТ
2.710-81).
10) Сайт производственного альянса «Контракт Электроника»
[электронный
ресурс].
Режим
доступа:
URL:
http://gsm.contrel.ru/wireless/gsm/sim508/. – SIM508 – компактный
GSM/GPRS модуль с GPS приемником.
128
ПРИЛОЖЕНИЯ
Информация о работе Проектирование системы диспетчерского наблюдения