2488

ние транспортным средством, находящихся в федеральном розыске, а также о разыскиваемом оружии.

Одной из важных задач, связанных с безопасностью дорожного движения, является задача учета и анализа дорожно-транспортных происшествий (ДТП), которая лежит в рамках ответственности ГИБДД. Перечислим лишь некоторые решения в данной сфере, которые нуждаются в компьютерной поддержке: определение виновника/виновников ДТП; определение мер взыскания по отношению к виновным в ДТП; соотнесение пунктов ПДД со схемами ДТП; определение травмоопасных участков и другие. На возникновение ДТП во время дорожного движения оказывают влияние множество факторов, таких как освещение, состояние дорожного полотна, погодные условия, психофизические человеческие факторы и многое другое. При возникновении ДТП сотрудник ОГИБДД ОВД выезжает на место происшествия, где производит сбор информации и первичный учет по карточкам ДТП. В результате первичного анализа полученной информации проводятся работы по выявлению виновников ДТП. Для этого сотруднику приходится учитывать множество факторов, повлиявших на возникновение ДТП, и степень влияния каждого из них.

Чтобы правильно оценить ситуацию и достоверно определить виновников ДТП, инспектору ДПС необходимо оценить всю совокупность факторов и сформировать соответствующий протокол. Поэтому решения, принимаемые работниками ГИБДД, нуждаются в компьютерной поддержке. Применение КСППР позволит достигнуть следующих целей, представленных на рис. 16.

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

В результате анализа было выявлено несколько программ, отвечающих данной теме: автоматизированная информационнопоисковая система «Отчет БДД и ГАИ КРАЙ»; справочная инфор- мационно-аналитическая система Государственной инспекции по безопасности дорожного движения (ГИБДД); автоматизированная система «Учет дорожно-транспортных происшествий'» (АС «Учет ДТП'») в г. Санкт-Петербурге; пилотная версия ГИС «Дороги Югры»; комплексная автоматизированная система управления автомобильными дорогами. Рассмотрим каждую информационную систему в отдельности, выявим их достоинства и недостатки.

111

Повысить эффективность работы сотрудников ОГИБДД

Рис. 16. Возможности ГИБДД при использовании КСППР

Рассмотрим программный комплекс «АИПС Отчет БДД и ГАИ КРАЙ». Данный программный комплекс предназначен для автоматизации работ по сбору и учету отчетов по формам №555 и №560 Департамента обеспечения безопасности дорожного движения. В состав АИПС «Отчет БДД и ГАИ КРАЙ» должны входить: подсистема «Отчет БДД»; подсистема «Отчет ГАИ».

АИПС «Отчет БДД и ГАИ КРАЙ» обеспечивает выполнение

ний, допущенных юридическими лицами; нарушение правил дорожного движения и эксплуатации транспортных средств; оставление места дорожно-транспортного происшествия; недоброкачественный ремонт транспортных средств и выпуск их в эксплуатацию с техническими неисправностями; количество нарушителей правил дорожно-

112

го движения (водителей, пешеходов, пассажиров); сведения о выявленных нарушениях правил дорожного движения и мерах, принятых к нарушителям; сведения о рассмотрении народными судьями материалов о ДТП; сведения о наличии и техническом состоянии транспортных средств; сведения о регистрации транспортных средств; сведения о работе службы организации движения и дорожной инспекции; сведения о работе по пропаганде и безопасности дорожного движения; сведения об участии работников ГАИ в розыске транспортных средств и охране общественного порядка.

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

Рассмотрим автоматизированную систему «Учет дорожнотранспортных происшествий» (АС «Учет ДТП») в г. СанктПетербурге. Система обеспечивает учет ДТП как с пострадавшими, так и без пострадавших на двух уровнях: городском и районном.

Система позволяет проводить углубленный анализ информации с целью выявления причин и условий, способствующих совершению ДТП, и принятия мер по их предупреждению. В АС «Учет ДТП» учитываются не только требования ГИЦ МВД РФ, но и опыт УГИБДД Санкт-Петербурга. Система разработана средствами СУБД PROGRESS и функционирует в Управлении и в ряде районных отделений ГИБДД Санкт-Петербурга и Ленинградской области.

Рассмотрим пилотную версию ГИС «Дороги Югры». Центральное место в системе занимает реестр объектов управления (автомобильных дорог), который формируется на основе Перечня автомобильных дорог общего пользования, утверждаемого правительством округа. Вся остальная хранимая и обрабатываемая системой информация содержится в так называемых «специализированных хранили-

113

щах». Два специализированных хранилища («Цифровые карты» и «Банк дорожных данных») входят в состав системы, а остальные хранилища рассматриваются как внешние источники данных. Такое решение позволяет организовать непротиворечивый, целостный банк данных об автомобильных дорогах, одновременно сохраняя гибкость и расширяемость системы.

Возможность подключения внешних источников данных является одним из основных преимуществ ГИС «Дороги Югры» в сравнении с конкурирующими аналогами. Было разработано 2 специализированных модуля системы: модуль «Учет работ» и модуль «Учет ДТП».

Модуль «Учет работ» содержит сведения о проводимых подрядчиками в рамках процесса эксплуатации дорожной сети работах.

ГИС «Дороги Югры» позволяет учитывать дорожнотранспортные происшествия для дальнейшего анализа с использованием пространственной информации. Система позволяет регистрировать в банке данных ДТП с учетом показателей стандартной формы, предоставляемой в Дорожный департамент инспекцией ГИБДД. В плане накопления данных есть возможность сформировать сводный отчет, сформировать выборку и отобразить ДТП на карте.

Рассмотрим комплексную автоматизированную систему управления автомобильными дорогами. Программа предназначена для ведения электронного журнала дорожно-транспортных происшествий и их анализа с целью определения уровня безопасности движения на автомобильных дорогах. Программа разработана с учетом требований «Правил учета и анализа дорожно-транспортных происшествий на автомобильных дорогах Российской Федерации».

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

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

114

ственной сети автодорог в разрезе района за период; сведения о ДТП на подведомственных дорогах за период; результаты анализа безопасности движения на автомобильной дороге за год; журнал ДТП за период.

Информация, вводимая в программу, и результаты анализа доступны другим программам, входящим в состав Комплексной автоматизированной системы. В электронном журнале ДТП информация хранится несколько лет. Предусмотрено ручное заполнение журнала ДТП и автоматизированное. Последнее предполагает программный перенос карточек ДТП из местной базы данных ГИБДД в электронный журнал ДТП.

Впроцессе сравнительного анализа автоматизированных информационных систем были выделены функции, предъявляемые к системе заказчиком. Эти функции и являются основными критериями оценки систем-аналогов. Были рассмотрены и дополнительные критерии, такие как стоимость программного продукта на одно рабочее место в рублях, технические требования, необходимость установки дополнительного программного обеспечения для полноценного функционирования системы-аналога, возможность изменения модулей и разработка новых, частота выпуска релизов, легкость освоения языка программирования системы и поддержка территориального распределения сети. Все перечисленные характеристики отражены в табл. 4.

Втабл. 4 знаки «+» / « - » означают наличие / отсутствие данной системы в подобных организациях и совместимость/несовместимость

сСУБД Oracle. Число «3» говорит о наличии весьма слабой реализации подобной функции в рассмотренных системах. Число «4» говорит о возможности работы определенной функции, но с некоторыми ограничениями. Число «5» говорит о полной реализации данной функции в рассмотренной системе.

При рассмотрении данной таблицы можно сказать, что лидером в этой отрасли является «Комплексная АС управления автомобильными дорогами», но данный пакет не позволяет анализировать ДТП с точки зрения ПДД, поэтому необходима совокупность качеств системы «Комплексная АС управления автомобильными дорогами» и системы анализа ДТП.

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

115

116

Это можно объяснить тем, что информационно-аналитические системы (ИАС) объединяют, анализируют и хранят как единое целое информацию, извлекаемую как из учетных баз данных организации, так и из внешних источников. Входящие в состав информационноаналитических систем хранилища данных обеспечивают преобразование больших объемов сильно детализированных данных в обобщенную выверенную информацию, которая пригодна для принятия обоснованных решений. В отличие от обычных баз данных хранилища содержат обработанное, упорядоченное и понятное руководителям представление данных. Хранилище данных является сборочным конвейером по подготовке информации в интегрированном, непротиворечивом, наглядном виде для поддержки принятия управленческих решений.

Современные СППР, построенные на основе хранилищ данных, предполагают организацию анализа на основе единого информационного пространства, в которое стекаются данные из действующих систем оперативной обработки информации (СОД). При этом информация в хранилище пополняется регулярно и располагается в хронологическом порядке. В основе поддержки принятия решений на основе технологии хранилища данных лежат три концепции:

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

2)многомерный анализ данных, позволяющий организовать агрегированную информацию из хранилища в виде гиперкубической модели и обеспечить ее удобный просмотр и анализ, включая формирование кросс-табличных отчетов, диаграмм деловой графики, раскрашенных определенным образом карт. При этом в ячейках гиперкуба хранятся числовые значения агрегированных показателей, а измерения позволяют упорядочить данные в соответствии с хронологической, географической и другими классификациями на основе справочников хранилища;

3)поиск зависимостей в накопленной информации на основе алгоритмов интеллектуального анализа данных.

Используя средства поддержки принятия решений, можно решать такие задачи, как мониторинг состояния ресурсов области, проверка гипотез, анализ и прогнозирование событий, поиск зависимостей, из которых можно извлекать новые сведения, выявлять аномалии, моде-

117

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

Хранилище данных (англ. Data Warehouse) – очень большая предметно-ориентированная информационная корпоративная база данных, специально разработанная и предназначенная для подготовки отчётов, анализа бизнес-процессов с целью поддержки принятия решений в организации. Хранилище данных строится на базе клиентсерверной архитектуры, реляционной СУБД и утилит поддержки принятия решений. При разработке КСППР важное значение играет выбор модели хранилища данных. Хранилище данных существует на основе реляционной СУБД, следовательно, можно говорить о КСППР как о ROLAP-системе. В этой структуре можно хранить очень большие объемы данных.

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

При создании системы управления метаданными необходимо решать следующие задачи:

1)анализ процессов возникновения, изменения и использования метаданных;

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

3)организация прав доступа к метаданным;

4)разделение метаданных между витринами данных;

5)согласование метаданных ХД с репозиториями;

6)реализация пользовательского интерфейса с репозиторием.

В дальнейшем необходимо заполнить хранилище данными. Для этого необходимо провести сбор, очистку и агрегирование данных. При детальном изучении структуры КСППР можно сказать, что для решения задач учета и анализа ДТП необходимо использовать двухуровневое хранилище данных. Информация поступает из источников данных в хранилище, где обрабатывается. На рис. 17 представлена схема двухуровневого хранилища данных.

118

Хранилище данных

Рис. 17. КСППР как двухуровневое хранилище данных

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

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

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

ихранения, а не для нестандартных запросов или аналитических отчетов;

-данные распределены между различными доставшимися по наследству разнородными системами, разработанными в разное время;

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

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

119

ных.

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

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

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

Для потока «Вид, место и схема ДТП» необходимо сформировать следующие данные: значение дороги (федеральная, территориальная, ведомственная, частная, иная, другие места); категория дороги; расстояние (километры, метры); статус населенного пункта (областной центр, райцентр, иной населенный пункт, вне городов или населенных пунктов); населенный пункт; район, улица; категория улицы (магистральная дорога, магистральная улица, улица районного значения, прочие улицы, иные места); вид ДТП (столкновение, опрокидывание, наезд на стоящее транспортное средство, наезд на препятствие, наезд на пешехода, наезд на велосипедиста, иной вид ДТП); количество транспортных средств, участвующих в ДТП; количество участников ДТП; количество погибших, количество раненых; схема ДТП; дополнительные сведения о ДТП.

Для потока «Дорожные условия» необходимо сформировать следующие данные: элементы плана и профиля дороги (прямая в плане,

120