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

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

Автоматизация диспетчерской службы - возможность серьезного повышения эффективности ее работы, учета, контроля и управления деятельностью. Для компаний и организаций, имеющих в составе такое подразделение, разработка и внедрение системы автоматизации обеспечивает решение целого комплекса задач, обусловленных спецификой деятельности:
  • повышение оперативности реагирования на заявки и события;
  • снижение влияния человеческого фактора;
  • выход на качественно новый уровень во взаимоотношениях и установление эффективного взаимодействия с заявителями, клиентами, контрагентами и другими лицами, работа с которыми ведется через диспетчерскую службу;
  • оптимизация и повышение эффективности использования ресурсов, в том числе благодаря равномерному распределению нагрузки на персонал диспетчерской службы;
  • упрощение и ускорение рабочих процессов, автоматизация рутинных операций;
  • эффективный мониторинг, контроль, учет и управление, в том числе в режиме реального времени.
Разработка систем автоматизации диспетчерских служб должна осуществляться на основе индивидуального подхода. Практика показывает, что даже в случае применения отраслевого решения, ориентированного на строго конкретное направление деятельности, например, ЖКХ, такси, торговля, склад, охрана объектов и т.д., добиться максимальной эффективности невозможно. Это объясняется различием алгоритмов и механизмов работы диспетчерских служб даже у компаний одной узкой отраслевой принадлежности. Свою роль в этом играют сложившаяся система управления, состав ИТ-инфраструктуры, необходимости конкретизации задач и их решений.

Разработка систем автоматизации диспетчерских служб

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

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

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

Мы создаем системы автоматизации с простым для понимания интерфейсом, гибкими настройками параметров, внедряем передовые средства защиты и безопасности, в том числе используем разграничение прав доступа. Разработанная система может быть интегрирована с другими внешними/внутренними информационными системами заказчика и сервисами (телефония, картография, навигация, системы онлайн-расчетов и другие). Она также может быть включена в состав системы комплексной автоматизации, функционирующей в организации.

Поддержка стран:
Операционная система: Windows
Семейство: Универсальная Система Учета
Назначение: Автоматизация бизнеса

Система диспетчерского управления

Основные возможности программы:

    У Вас сформируется единая база клиентов и поставщиков со всеми необходимыми контактными данными

    Чтобы ничего не забыть, по каждому клиенту можно будет отмечать любую планируемую или выполненную работу

    Вы сможете легко контролировать каждый свой заказ

    По каждому заказу можно будет отслеживать этап исполнения и задействованных сотрудников

    Вы получите возможность вести учет по любым услугам

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

    Все сотрудники будут у Вас под контролем

    Контроль
    сотрудников

    Наша программа напомнит Вам обо всех важных делах

    Вы сможете посмотреть список дел на любую дату по каждому своему специалисту

    Каждое ваше маркетинговое решение будет учтено и проанализировано по числу новых клиентов и платежам

    Все совершенные платежи будут под вашим полным контролем

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

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

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

    Статистика заявок поможет вам легко проанализировать деятельность и доходность компании

    Все финансовые взаимоотношения с вашими поставщиками услуг будут под полным контролем

    Интеграция с новейшими технологиями позволит вам эпатировать клиентов и заслуженно получить репутацию самой современной компании


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

    Система диспетчерского контроля включает в себя: контроль непрерывного функционирования всех участков предприятия; обеспечение качественного выполнения работы; работа с непредвиденными ситуациями.

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

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

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

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

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

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

    Программой могут пользоваться:

    Посмотрев следующее видео, можно быстро ознакомиться с возможностями программы УСУ - Универсальной Системы Учета. Если Вы не видите загруженное на YouTube видео, обязательно напишите нам, мы найдем другой способ показать демонстрационный ролик!

    Кроме мнений о программе УСУ обычных пользователей Вашему вниманию теперь представляются мнения экспертов. Анатолий Вассерман родился 9 декабря 1952 года. Окончил Одесский технологический институт холодильной промышленности, по специальности инженер. После окончания института работал программистом. Затем - системным программистом. Впервые на экране появился в 1989 году в клубе «Что? Где? Когда?», затем - на «Брэйн-ринге». В телевизионной «Своей игре» одержал пятнадцать побед подряд в 2001-2002 годах и стал лучшим игроком десятилетия в 2004 году. Пятикратный чемпион Украины по спортивной версии «Своей игры». Четырёхкратный чемпион Москвы по спортивной версии «Своей игры», бронзовый призёр того же соревнования, серебряный 2017 года. Серебряный призёр «Знатокиады» - Всемирных игр знатоков - 2010 года по «Своей игре».

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

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

    Кроме мнений о программе УСУ обычных пользователей Вашему вниманию теперь представляются мнения экспертов. Александр Друзь - первый магистр интеллектуальной игры "ЧГК". Шесть раз награждался призом "Хрустальная сова" как лучший игрок клуба. Обладатель "Бриллиантовой совы" – приза лучшему игроку. Чемпион телевизионной версии «Брейн-ринга». В телевизионной передаче «Своя игра» выигрывал «Линейные игры», «Суперкубок», выигрывал с командой «III Кубок Вызова», установил абсолютный рекорд результативности за одну игру. Автор и ведущий интеллектуальных игр и познавательных программ на различных телеканалах.

    Кроме мнений о программе УСУ обычных пользователей Вашему вниманию теперь представляются мнения экспертов. Максим Поташев - магистр игры «Что? Где? Когда?», четырёхкратный обладатель приза «Хрустальная сова», дважды чемпион мира, трижды чемпион России, шестикратный чемпион Москвы, трёхкратный победитель Открытого чемпионата Москвы по игре «ЧГК». По итогам всеобщего зрительского голосования в 2000 году признан лучшим игроком за все 25 лет существования элитарного клуба. За кандидатуру Максима Поташёва проголосовало 50 тысяч телезрителей программы. Получил «Большую хрустальную сову» и главный приз юбилейных игр - «Бриллиантовую звезду» магистра игры. Член правления и с 2001 года - вице-президент Международной ассоциации клубов. По профессии - математик, маркетолог, бизнес-тренер. Окончил факультет управления и прикладной математики, преподавал на кафедре общей и прикладной экономики в МФТИ. В августе 2010 года избран президентом Общероссийской общественной организации «Федерация спортивного бриджа России». Возглавляет консалтинговую компанию, которая помогает различным организациям решать задачи, связанные с продажами, маркетингом, клиентским сервисом и оптимизацией бизнес-процессов.

    Кроме мнений о программе УСУ обычных пользователей Вашему вниманию теперь представляются мнения экспертов. Сергей Карякин. В возрасте 12 лет стал самым молодым гроссмейстером в истории человечества. Внесён в Книгу рекордов Гиннесса. Одержал победу в турнире претендентов. Обладатель Кубка мира ФИДЕ. Чемпион мира по быстрым шахматам, чемпион мира по блицу. Заслуженный мастер спорта Украины. Заслуженный мастер спорта России, гроссмейстер России. Награждён орденом «За заслуги» ІІІ степени. Член Общественной палаты Российской Федерации VI состава. Неоднократный победитель детских и юношеских чемпионатов мира и Европы. Победитель и призёр ряда крупных турниров. Чемпион XXXVI Всемирной Шахматной олимпиады в составе сборной Украины, серебряный призёр Олимпиады в составе сборной России. На своей доске показал лучший результат и получил первый индивидуальный приз (на 4 доске). Чемпион России с лучшим результатом на 1-й доске. Чемпион мира в составе сборной России. Полуфиналист Кубка мира. Победитель ряда международных турниров.

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

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

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

Компания «ИндаСофт» планомерно разрабатывает и совершенствует решения по автоматизации процессов управления производственной деятельностью, максимально ориентируясь на специфику отечественных предприятий. Специализированный программный продукт I-DS (I-Dispatch System), разработанный сотрудниками компании, представляет собой комплексное решение по автоматизации всех составляющих процесса диспетчерского контроля и управления, включая:

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

В октябре 2016 года программные продукты ЛИМС I-LDS и Система диспетчерского управления I-DS , разработанные компанией «ИндаСофт », включены в Единый реестр российских программ для электронных вычислительных машин и баз данных .

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

Технологический мониторинг

Главной задачей автоматизации процессов технологического мониторинга является обеспечение всех служб предприятия оперативной информацией о состоянии производства. Для решения этой задачи I-DS автоматизирует процессы сбора, обработки, хранения данных, представления текущей, исторической и агрегированной информации о ходе технологических процессов. Пользовательский интерфейс настраивается под нужды каждого специалиста и позволяет осуществлять доступ как к типовым утвержденным формам отображения производственной информации, так и к динамически формируемым пользователем таблицам, трендам, мнемосхемам и диаграммам.

В состав I-DS входит набор разработанных специалистами «ИндаСофт» шаблонов мнемо-графического представления производственной информации:

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

Диспетчерская отчетность

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

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

Ручной ввод и управление данными

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

В составе I-DS для формализации алгоритмов ввода и обработки данных используются специальные визуальные инструменты конфигурации рабочих процессов (так называемые workflow или блок-схемы). Данные средства позволяют наглядно описать (выстроить) и регламентировать процессы автоматизированного сбора, ручного ввода, корректировки, утверждения и публикации учетно-отчетных данных, используемые большим числом операторов технологических объектов, диспетчеров производственных служб. Описание стандартных процедур позволяет оперативно влиять на указанные процессы, адаптируя систему под изменения технологии или организации производства.

Управление событиями

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

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

Инструменты оповещения (SMS, e-mail, звуковые тревоги), визуализации на мнемосхемах, аналитика по истории событий позволяют специалистам предприятия быть уверенными, что они не пропустят ни одного события и оперативно смогут принять решение о том, как реагировать на ту или иную ситуацию.

Контроль соблюдения норм технических регламентов

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

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

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

Диспетчерские журналы и задания

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

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

Работа с нештатными и аварийными ситуациями

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

Автоматизация процессов работы в нештатных и аварийных ситуациях:

  • обеспечивает регистрацию нештатных ситуаций;
  • упрощает проведение классификации, оценки и определения категории важности событий;
  • позволяет осуществлять поддержку принятия диспетчерских решений при возникновении нештатных и аварийных ситуаций;
  • обеспечивает оповещение ответственных специалистов предприятия в соответствии с утвержденным регламентом;
  • упрощает контроль развития нештатных и аварийных ситуаций;
  • осуществляет хранение архива событий для «разбора полетов» с возможностью приложения любой необходимой документации в форматах *.pdf, *.doc, *.jpg и др.

Расчет масс по ГОСТ

Достоверность и легитимность учетных данных по материальным и энергетическим потокам при распределенной системе сбора информации от различных источников определяет качество производственного учета. На любом предприятии стоит задача обеспечения единства первичных измерений, а также минимизации влияния «человеческого фактора» на расчет масс запасов, потребления сырья и энергоресурсов, выработки полуфабрикатов и товарной продукции по каждому технологическому объекту и по предприятию в целом. Основной подход заключается в сборе первичных измерений с уровня КИПиА и централизации расчетов масс в едином сервере системы диспетчеризации - что обеспечивает единство измерений и быстрое изменение алгоритмов вычислений при выходе новых нормативных документов.

Специалистами «ИндаСофт» разработан и сертифицирован в составе общего решения серверный модуль расчета масс I-DS/CM, предназначенный для построения и выполнения вычислительных алгоритмов по ГОСТ, МИ и локальным для конкретных предприятий методикам. Таким образом, реализуется функция нахождения способа расчета (и собственно расчета) необходимых массовых и энергетических величин из некоторых известных параметров (например, давление, перепад давления, температура продукта, лабораторная плотность и т.п.) путем:

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

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

Учет движения материалов

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

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

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

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

Мониторинг работы оборудования

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

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

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

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

Расчет ключевых показателей эффективности производства

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

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

ПО I-DS обеспечивает автоматизацию процесса сбора данных для расчета KPI, автоматизацию процессов расчета KPI и организацию единого информационного пространства с возможностью наглядного представления KPI в виде бизнес-графики и анализа факторов влияния на показатели.

УДК 614.8:351.86+519.8

Проблемы организации информационного взаимодействия дежурно-диспетчерских служб экстренных оперативных служб в процессе создания Системы-112

В. Н. Зубков, С. В. Агеев, О. В. Денисов, В. В. Тыминский, А. С. Акульшин Аннотация

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

Ключевые слова: Система-112, вызов экстренных служб, единая дежурно-диспетчерская служба муниципального образования, поддержка принятия решения, автоматизированные средства.

Problems of the Organization Information Interaction of Emergency Field services in the Course of Creation of sistemy-112

V. Zubkov, S. Ageev, O. Denisov, V. Tyminsky, A. Akulshin, Abstract Abstract

In article the basic problems of creation and functioning of information systems of emergency field services are stated.

Key words: System-112, call emergency services, united dispatch office of the municipal entity, decision support, automated tools.

Задолго до идеи создания Системы-112 в России появились и до настоящего времени существуют различные службы, которые осуществляют прием вызовов от населения о различных происшествиях и организовывают экстренное реагирование на них. При этом заявитель сам квалифицирует проблемное событие, по которому желает получить помощь с известной ему компетенцией оперативной службы и сам выбирает, какой экстренной службе адресовать свою проблему по одному из специализированных номеров служб (01, 02, 03, 04 и т. д.). Как правило, это не вызывает каких-либо сложностей. Случаи обращения «не по адресу» не являются системными, и их количество не превышает обыч-

ное количество ложных сообщений, получаемых данными службами.

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

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

практически везде регистрация сообщений и действий сил и средств по реагированию на них, а также учет результатов реагирования ведется в электронной форме (от простых форм в формате Word или Excel до неких «программ», разработанных, как правило, ведомственными специалистами на местах). Для разработки полноценных диспетчерских комплексов всегда требуются специалисты высокого уровня и различных направлений в области информационных технологий, поэтому таких систем на самом деле сегодня немного. При этом даже в рамках одного какого-нибудь ведомства нет единого подхода, поэтому разные подразделения на территориях оснащены различными системами различных разработчиков, с различным уровнем проработки функционала, различной степенью автоматизации. Это вызывает удивление, т. к. структура подразделений всех рассматриваемых ведомств строго централизована от федерального до муниципального уровней, во всех ведомствах имеются утвержденные данными ведомствами алгоритмы и правила приема, обработки сообщений, организации реагирования на них, учета результатов и статистики, единые для всех подразделений данного ведомства во всех субъектах.

Необходимо отметить, что МЧС России и МВД России предпринимали и предпринимают усилия по созданию систем и комплексов, автоматизирующих оперативно-диспетчерские функции, однако централизованно разрабатываемые и внедряемые в данных ведомствах системы носят характер скорее информационно-справочный и учетно-статистический, чем оперативно-диспетчерский и управляющий.

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

а) прием, обработка и регистрация сообщений;

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

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

г) информационная поддержка принятия решений (при необходимости) участникам реагирования;

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

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

Проведенный анализ используемых в различных министерствах и ведомствах РФ систем, автоматизирующих процесс оперативно-диспетчерского управления,

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

С появлением идеи (концепции) создания Систе-мы-112 появилась возможность создания программно-технической и информационной платформы, объединяющей все ДДС экстренных оперативных служб (и, возможно, не только экстренных) в единое информационное пространство (или даже сообщество «e-emergency» - электронные экстренные службы) с целью удобного для населения вызова экстренных оперативных служб по принципу «одного окна» и организацию комплекса мер, обеспечивающих ускоренное реагирование и улучшение взаимодействия оперативных служб при вызовах (сообщениях о происшествии) от населения. Унифицированный программно-технический комплекс Системы-112 смог бы стать программной основой (модулем) для организации информационного взаимодействия ДДС оперативных служб в субъектах РФ.

Таким образом, Система-112 может стать информационно-коммуникационной платформой объединенной системы оперативно-диспетчерского управления (ОСОДУ) субъекта.

Однако вначале, исходя из задач и функций, возлагаемых Концепцией на Систему-112, необходимо уяснить, что такое Система-112: информационная (информирующая), диспетчерская, управляющая система или все вместе, а затем определить роль и место данной системы среди иных систем субъекта, реализующих аналогичные и смежные задачи и функции.

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

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

Концепция определяет Систему-112 как террито-риально-распределенную информационную систему, предназначенную объединять на основе единых дежурно-диспетчерских служб (ЕДДС) муниципальных образований дежурно-диспетчерские службы экстрен-

ных оперативных служб (служба пожарной охраны; служба реагирования в чрезвычайных ситуациях; служба милиции; служба скорой медицинской помощи; аварийная служба газовой сети; служба «Антитеррор»).

В описании алгоритма действий операторов «112» усматриваются управленческие функции, а также предусматривается управленческая вертикаль; поэтому можно считать, что Система-112 является информационно-управляющей.

На почве согласия или отрицания такого подхода происходит большинство споров.

С нашей точки зрения Система-112 является в повседневном режиме работы информационной системой, но при переходе в режим «ЧС» она должна иметь возможность перехвата функции управления, что в общем-то и заложено в Концепции.

Окончательно свести вместе позиции сторонников Системы-112 как информирующей и рассматривающих ее как управляющую, позволит разработка нормативно-правового акта, возможно Типового положения об ОСОДУ субъекта или самой Системы-112, где найдет отражение и законодательное закрепление роль и место ЕДДС и каждой экстренной оперативной службы. В свою очередь понимание целей, задач и функций ОСОДУ в целом и отдельных ее элементов, особенно ЕДДС, позволит подготовить технические требования к программно-аппаратному комплексу, автоматизирующего процессы управления и межведомственного взаимодействия между отдельными элементами системы.

В соответствии с одобренной Правительством РФ Концепцией создания Системы-112 ее построение должно базироваться на ЕДДС муниципальных образований. Поэтому одним из ключевых моментов при создании Системы-112 является определение статуса и нормативно-правовой основы ЕДДС.

Проведенный анализ создаваемых в субъектах РФ ЕДДС показал, что, как правило, они не имеют никакого штата и тем более юридического статуса (самостоятельного юридического лица, организации), а являются какими-то нештатными подразделениями при администрации. Такой подход занижает роль и место ЕДДС в системе экстренного реагирования на ЧП, а также не позволяет правильно организовать финансовое обеспечение данной службы, а следовательно - и системы в целом.

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

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

Такой подход, на наш взгляд, позволит решить проблемы как организационного характера при создании Системы-112, так и в дальнейшем решить вопрос с ба-

Также одним из ключевых моментов при создании Системы-112 является оценка готовности информационно-коммуникационной (ИК) инфраструктуры региона к возможности использования современных информационных технологий (ИТ) в системе вызова экстренных служб. Как показал анализ, каналы связи между ДДС экстренных оперативных служб в большинстве субъектов РФ были созданы в 60-е годы и физически изношены, что приводит периодически к проблемам по доведению оператором связи вызова до экстренных служб, а тем более организации передачи информации (данных), дежурно-диспетчерский персонал не владеет современными информационными средствами и технологиями. По Концепции Система-112 это многофункциональная информационно-коммуникационная территориально-распределенная система, которая предполагает создание развитой и современной телекоммуникационной составляющей, т. е. оптоволоконных каналов передачи данных, с достаточно большой пропускной способностью и надежностью, внедрение WEB-технологий в систему передачи данных и вызовов между ЕДДС и ДДС.

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

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

Подсистема приема и обработки вызовов, или так называемая диспетчерская подсистема, является управляющей подсистемой в автоматизированной системе (АС) ЕДДС.

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

Рассмотрим два наиболее часто встречающихся варианта.

Вариант 1

В ДДС экстренных служб (01, 02, 03 и т. д.) уже имеются свои ведомственные диспетчерские системы.

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

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

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

Недостатки данного подхода определяются непосредственным способом его реализации. Так, например, при размещении в ДДС экстренной службы дополнительного клиентского АРМ с СПО ЦОВ ЕДДС оператору придется обрабатывать сообщения, поступившие по линии Системы-112 и по ведомственной системе, раздельно. Для выравнивания статистики в обеих системах оператору придется вручную переносить информацию из одной в другую, что не только не ускоряет процесс обработки сообщений и реагирования на них, но склоняет оператора в определенном смысле к «саботированию» новой системы, отдавая приоритет работе пусть и не современной и менее функциональной, но более знакомой старой системе. Кроме того, одной из задач, стоящих перед Системой-112, является «гармонизация способа вызова экстренных оперативных служб с законодательством Европейского союза», а в соответствии с Европейскими требованиями у оператора должно быть одно автоматизированное рабочее место (одна клавиатура, мышь и т. д.). Внедрение интеграционных модулей проблематично по иной причине. Простой подсчет количества ДДС потенциальных объектов интеграции показывает, что на практике в лучшем случае придется интегрироваться с четырьмя-шестью АС в субъекте - служб 01, 02, 03, 04, служба реагирования на ЧС (или ЦУКС), служба «Антитеррор». При этом в каждом субъекте возможно наличие АС отличных от АС в такой же службе соседнего региона. То есть мы имеем более 250 потенциальных объектов интеграции. Кроме того, анализ наличия и состояния автоматизированных систем в ДДС экстренных служб показывает, что большинство ДДС не оснащены какими-либо не то, чтобы диспетчерскими программами, а даже более или менее современными информационно-справочными или учетно-статистическими системами. Поэтому интеграция вызовет сложности на программном уровне. Для успешного сопряжения систем разработчикам необходимо открыть друг другу свои разработки, специалистам в области безопасности информации предпринять дополнительные усилия по защите своих сетей и информационных ресурсов после интеграции. Не способствует эффективной работе по интеграции и позиция многих руководителей служб, направленная на некую ведомственную изолированность. При значительных организационных усилиях и безусловно больших затратах как финансовых, так и ресурсов специалистов в области информационных технологий положительный эффект от реализованного решения совсем не очевиден.

Вариант 2

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

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

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

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

Однако в данном варианте положительные моменты представляются очевидными - каждое ведомство получает специализированный программный продукт, разработанный по согласованию (или при участии) «под задачи» данного ведомства; система управления в кризисных ситуациях субъекта получает единство программной платформы всех ДДС, ЕДДС и ЦУКС, позволяющее реализовать единые и согласованные правила информационного обмена в системе РСЧС. Кроме того, с учетом рассматриваемых выше роли и месте Системы-112 в ОСОДУ субъекта целесообразна разработка АС в рамках именно данного проекта.

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

Но, на наш взгляд, более предпочтительным является второй вариант, который является более сложным в начальной стадии (при разработке единой АС), но впоследствии при тиражировании системы в регионах внедренческий эффект нивелирует проблемы, возникшие при разработке.

То, что Концепцией предусмотрено развертывание Системы-112 на базе именно ЕДДС муниципальных

образований, являющихся органами повседневного управления территориальной подсистемы РСЧС субъекта, представляется верным и весьма оправданным. На сегодняшний день у ЕДДС имеются легитимные полномочия по организации и осуществлению повседневного управления ДДС, в том числе и экстренных оперативных служб (определенных Постановлением Правительства РФ...), однако по факту отсутствует техническая основа для управления. С другой стороны в Системе-112 такая программно-техническая основа заложена. Сходство большинства задач и функций также позволяет рассматривать Систему-112 на базе ЕДДС муниципальных образований как неотъемлемую часть системы оперативно-диспетчерского управления на базе органов повседневного управления территориальной подсистемы РСЧС, т. е. на базе ЕДДС. И централизация оперативно-диспетчерского управления всеми ДДС всех взаимодействующих служб, а не только оперативных на базе ЕДДС является еще одним аргументом в пользу разработки типовой автоматизированной системы объединенной системы оперативно-диспетчерского управления для субъекта.

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

литература

1. Распоряжение Правительства РФ от 25 августа 2008 г № 1240-р об одобрении Концепции создания Системы-112.

2. Приказ МЧС России от 15.12.2008 г №779 «О реализации распоряжения Правительства РФ от 25 августа 2008 г № 1240-р.

3. Распоряжение Министра от 27.10.2009 г № 379 « О создании рабочей группы по развертыванию системы обеспечения вызова экстренных оперативных служб через единый номер «112» на базе ЕДДС муниципальных образований в Российской Федерации».

4. Приказ МЧС России от 9.04.2009 г № 224 «Об отработке методологии развертывания и функционирования системы обеспечения вызова экстренных оперативных служб через единый номер «112» на базе ЕДДС муниципальных образований в пилотных регионах Российской Федерации».

5. Приказ МЧС России от 1. 06.2009 г № 331 «О межведомственной рабочей группе для отработки методологии развертывания и функционирования системы обеспечения вызова экстренных оперативных служб через единый номер «112» на базе ЕДДС муниципальных образований в пилотных регионах Российской Федерации».

6. Постановление Правительства РФ от 31 декабря 2004 г. № 894 «Об утверждении перечня экстренных оперативных служб, вызов которых круглосуточно и бесплатно обязан обеспечить оператор связи, и о назначении единого номера вызова экстренных оперативных служб».

7. Решение коллегии МЧС России от 29 августа 2007 г № 7/1 «О подготовке к развертыванию на территории Российской Федерации и системы вызова экстренных оперативных служб через единый номер «112».

9. ГОСТ Р22. 7.01-99 ЕДДС. Основные положения.

зубков Василий николаевич, Главное управление МЧС России по Курской области, начальник. агеев Сергей Владимирович, к.т. н., ФГУ ВНИИ ГОЧС (ФЦ), ведущий научный сотрудник. денисов Олег Вячеславович, ЦФ ФГУ ВНИИ ГОЧС (ФЦ), начальник.

тыминский Владимир Валентинович, ГУ «ЦУКС МЧС России по Курской области», начальник. акульшин Сергей Борисович, ГУ «ЦУКС МЧС России по Курской области», специалист.

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

Размещено на http://www.allbest.ru/

[Введите текст]

Введение

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

1. Предметная область

Областью рассмотрения является деятельность диспетчеров службы такси, которые должны:

Вести список клиентов, в котором вводится номер карточки, фамилия и имя, домашний адрес и мобильный телефон.

Список автомобилей, в котором вводится номер автомобиля, марка автомобиля, государственный номер автомобиля, водитель автомобиля.

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

Список водителей, в котором вводится фамилия водителя, имя, стаж работы.

2. Постановка задачи

Разработка моделей процесса приведена на примере создания базы данных «Диспетчерская служба такси».

Моделирование элементов системы.

Диаграммы IDEF0

Диаграммы DFD

3. Концептуальные требования

Для проектирования базы данных выбран универсальный методы проектирования ER-метод (метод “сущность-связь”). При использовании этого метода необходимо, прежде всего, создать ER- модель, отражающую связи сущностей заданной предметной области. Далее, на основании ER-диаграммы, строится базы данных.

Сущности - концептуальные требования, которые необходимо учесть при разработке БД: каталоги клиентов, заказов, автомобилей, водителей.

Нормализация

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

I нормальная форма

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

Раскрываем сущности концептуальных требований:

Автомобили (НомерАвто, МаркаАвто, ГосНомерАвто, Водитель).

Клиент (Номеркарточки, ФамилияИмя, ДомашнийАдрес, НомерТелефона).

Заказ (КодЗаказа, ДатаЗаказа, ВремяЗаказа, НомерАвто, НомерКарточки, СуммаЗаказа, СостояниеЗаказа).

Водитель (Фамилия, Имя, СтажРаботы).

II нормальная форма

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

Таблица 1 - Автомобиль

Таблица 2 - Заказы

Таблица 3 - Клиенты

III нормальная форма

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

Рисунок 3 - Таблица Автомобиль

Рисунок 4 - Таблица Заказы

Рисунок 5 - Таблица Клиенты

Рисунок 6 - Таблица Водитель

4. Структурная схема

На основании третьей нормальной формы создаем структурную схему базы данных «Диспетчерская служба такси».

Создание структурной схемы базы данных.

Войти в схему данных: вкладка Работа с базами данных.

На панели инструментов нажать «Схема данных».

Рисунок 7

Окно с перечнем таблиц

Двойным щелчком по имени таблицы добавить таблицы на поле

Рисунок 8

Установить связь между таблицами

Рисунок 9

5. Порядок выполнения работы

Для начала создадим базу данных, нажав «Файл - Создать - Новая база данных». Задаем имя базы, место сохранения, щелкаем Создать.

Рисунок 10

Теперь задаем структуру таблиц.

На закладке главная выбираем режим «Конструктор».

Рисунок 11

Сохраняем таблицу под выбранным именем.

Рисунок 12

Создаем таблицу в окне конструктора.

Рисунок 13

6. Создание таблиц в режиме конструктора

Нажать «Создать таблицу в режиме конструктора».

Ввести имя поля.

Выбрать тип данных.

Поставить первичный ключ, щелкнув по кнопке «Ключ» на панели инструментов, предварительно установив курсор на поле слева от нужного имени (ключевое поле должно находиться на первом месте списка полей).

Задать имя таблицы призакрытие после ввода всех требуемых полей и их типов.

Аналогичным способом построены таблицы:

Автомобиль.

Водитель.

Создание связи между таблицами.

Щелкнуть по значку «Схема данных» на панели инструментов, открыть схему данных.

Из появившегося дополнительного окна «Добавить таблицы» выделить щелчком необходимые имена таблиц и щелкнуть по кнопке «Добавить».

Объединить ключевые поля таблиц: щелчком мыши выделить в одной из таблиц поле, которое будет соединяться в одноименном поле другой таблицы, и, зажав мышь, перетащить это поле на соединяемое поле. Отпустить мышь, при этом откроется окно «Изменение связей» с указанием соединяемых полей соответствующих таблиц и тип связи этих полей: «один-к-одному», «один-ко-многим»:

При типе связи «один-к-одному» ставим флажок в поле обеспечения целостности данных и щелкаем кнопку ОК.

При типе связи «один-ко-многим».

Обеспечение целостности данных.

Каскадное обновление связанных полей.

Каскадное удаление связанных полей.

Нажимаем кнопку ОК.

В результате имеем схему связей между таблицами БД «Диспетчерская служба такси».

7. Создание форм

Переходим на вкладку Создание. Жмем на кнопку «Форма» на панели сверху. Создается форма на заполнение. Сохраняем форма под название «Форма ввода». Сохраняем. Жмем правой кнопкой мыши по названию формы и выбираем «Режим формы». Либо во вкладке «Создание» выбираем «Мастер форм»:

8. Создание запросов

база данная такси конструктор

Типы запросов:

Простой запрос - создание запроса из определенных полей.

Перекрестный запрос - создание запроса, выводящего данные в компактном формате, подобному формату электронной таблицы.

Повторяющиеся записи - создание запроса на поиск повторяющихся записей в простой таблице или запросе.

Записи безподчиненных - создание запроса на поиск записей, которым не соответствует ни одна запись в подчиненной таблице.

Простой запрос

На вкладке Создание в группе Запросы щелкните Мастер запросов.

Рисунок 14

В диалоговом окне Новый запрос выберите вариант Простой запрос и нажмите кнопку ОК.

Рисунок 15

Рисунок 16

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

9. Перекрестный запрос

На вкладке Создание в группе Другие щелкните Конструктор запросов.

Рисунок 17

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

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

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

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

10. Создание отчетов

Для того чтобы создать отчет нужно перейти на вкладку «Создание» и выбрать «Отчет»

Отчеты можно создать при помощи:

Конструктор отчетов.

Мастера отчетов.

И вручную.

В нашей базе данных отчет создается при помощи мастера отчетов. Нужно нажать на «мастер отчетов». Откроется окно.

Рисунок 18

Переносим доступные поля по одному нужно нажать кнопку «>».

Чтобы перенести все поля сразу нужно нажать кнопку «>>»

Рисунок 19

В следующем окне можно распределить уровни группировки.

В следующем шаге можно выбрать вид макета отчета, а так же выбрать ориентацию книжную или альбомную.

К отчету можно прикрепить наклейки. Так же можно создать пустой отчет.

В конце создания базы данных должен быть создан общий отчет, включающий в себя все поля.

Заключение

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

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

Литература

1. Гвоздева В.А., Лаврентьева И.Ю., основы построения автоматизированных информационных систем - Москва, ИД Форум - ИНФРА - М, 2007. - 320с.

2. Фуфаев Д.Э., Фуфаев Д.Э. Разработка и эксплуатация автоматизированных информационных систем - Москва, издательский центр Академия, 2010. - 304с.

3. Гагарина Л.Г., Киселев Д.В., Е.Л. Федотова. Разработка и эксплуатация автоматизированных информационных систем - Москва, ИД Форум - ИНФРА - М, 2009. -384с.

4. Димов Ю.В. Метрология, Стандартизация и Сертификация - Питер, 2005

5. Пирогов В.Ю. Информационные системы и базы данных: организация и проектирования: учеб. Пособие - СПБ.БВХ- Петербург, 2009. -528с.

6. Харитонова И.А., Михеева В.Д. MicrosoftAccess 2000 - СПБ. : БВХ- Петербург, 1999. - 1088с.

7. Максимов Н.В. и др. Современные информационные технологии. Учебник- М: “ФОРУМ”: ИНФРА-М, 2011.

Размещено на Allbest.ru

Подобные документы

    Создание таблиц базы данных в режиме конструктора. Схема связей между таблицами и содержание таблиц. Установление связи с поддержанием целостности. Структуры двух запросов (в режиме конструктора) и описание процесса их создания. Результаты вывода отчетов.

    курсовая работа , добавлен 28.06.2015

    Понятия основных компонентов базы данных Access. Таблицы, отчеты, макросы и модули, форма, запросы к базе и их виды. Типы данных. Создание базы данных "Кадры". Создание таблицы в режиме конструктора. Использование мастера подстановок для создания связей.

    курсовая работа , добавлен 10.03.2016

    Создание базы данных в Microsoft Access с помощью мастера шаблонов. Создание таблиц путём ввода данных, с помощью мастера таблиц или таблицы в режиме конструктора таблиц. Создание запросов в Microsoft Access, с помощью мастера или конструктора запросов.

    реферат , добавлен 08.09.2010

    Создание таблиц базы данных с помощью MS Access "Страны Азии". Форма базы данных и запросы к выборкам данных. Модификация структуры таблиц, создания связей между главными таблицами, редактирование данных и проектирование форм для реальной базы данных.

    контрольная работа , добавлен 25.11.2012

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

    контрольная работа , добавлен 24.07.2009

    Понятие нормализации таблиц базы данных и ее цели. Этапы процесса нормализации. Пример ненормализованных данных. Нормальные формы, к которым приводятся таблицы. Реляционная алгебра над учебной базой. База данных для предметной области "Учебные пособия".

    контрольная работа , добавлен 30.07.2010

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

    курсовая работа , добавлен 18.07.2014

    Автоматизация деятельности книжного магазина. Информация базы данных. Заполнение полей таблиц "Книги", "Покупатель", "Поставщик", "Сотрудники". Создание запроса в режиме конструктора. Вывод данных с помощью форм. Разработка приложения СУБД MS Access.

    курсовая работа , добавлен 13.01.2015

    Создание базы данных, планирование разработки и системные требования. Проектирование базы данных в среде Microsoft Access, элементы и типы данных. Создание таблицы и использование конструктора для их модернизации. Построение запросов и создание макросов.

    курсовая работа , добавлен 16.04.2011

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



 

Пожалуйста, поделитесь этим материалом в социальных сетях, если он оказался полезен!