Разработка организационных документов по созданию и развитию аппаратно-программного комплекса «Безопасный город» (2016 год)

СОДЕРЖАНИЕ

Содержание

Определения

Обозначения и сокращения

Введение

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

управляющих и других систем в области природно-техногенной и

общественной безопасности в аппаратно-программный комплекс «Безопасный

городª

1.1.

Общие положения

1.2.

Перечень функций (задач), ранее созданных и действующих

автоматизированных информационно-управляющих систем различной

ведомственной принадлежности, интегрируемых в состав АПК «Безопасный

городª

1.2.1 Место АПК «Безопасный городª в структуре РСЧС

1.2.2 Перечень действующих АС различной ведомственной принадлежности,

интегрируемых в состав АПК «Безопасный городª

1.2.3

Перечень функций (задач) и назначение подсистем в составе АПК

«Безопасный городª

1.3

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

действующих автоматизированных информационно-управляющих систем в

системы АПК «Безопасный городª

1.3.1

Определение перечня категорий передаваемой информации

1.3.2

Определение требований к содержанию информации, передаваемой

от действующих АС в АПК «Безопасный городª

1.4

Алгоритм информационного обмена действующих автоматизированных

систем с АПК «Безопасный городª

1.4.1

Техническая основа информационного обмена

1.4.2

Алгоритм информационного обмена

1.5

Требования к организации обмена данными между действующими АС

различной ведомственной принадлежности на муниципальном и региональном

уровне и системами в составе АПК «Безопасный городª

2 Предложения по применению действующих информационно-аналитических

управляющих и других систем для предупреждения и ликвидации

чрезвычайных ситуаций и происшествий, обеспечения правопорядка в составе

АПК «Безопасный городª

2.1

Анализ действующих и перспективных автоматизированных

информационно-управляющих систем различной ведомственной

принадлежности на муниципальном и региональном уровне на предмет

соответствия их функциональных характеристик требованиям, указанным в

Концепции построения и развития АПК «Безопасный городª

2.1.1

Исходные данные анализа

2.1.2

Функциональные подсистемы АПК "Безопасный город"

2.1.3

Функциональная схема АПК «Безопасный городª

102

2.1.4

Функциональные задачи организаций, задействованных в

информационном обмене в АПК «Безопасный городª

105

2.2

Анализ возможности и условий сопряжения действующих

автоматизированных информационно-управляющих систем различной

ведомственной принадлежности на муниципальном и региональном уровне с

системами АПК «Безопасный городª

105

2.2.1

Общие положения

105

2.2.2

Требования к Единому стеку открытых протоколов

информационного взаимодействия АПК «Безопасный городª

106

2.2.3

Требования к протоколу информационно-технического

взаимодействия АПК «Безопасный городª

115

2.2.4

Требования к программным средствам поддержки информационно

взаимодействия (интеграционной шине)

116

2.3

Модель взаимодействия действующих информационно-управляющих

систем и систем в составе АПК «Безопасный городª

1255

2.3.1

Общие положения по взаимодействию

1255

2.3.2 Модель информационного взаимодействия

12930

3 Проект архитектуры решений АПК «Безопасный городª

1322

3.1

Требования к архитектуре АПК «Безопасный городª

1322

3.2

Функциональные сегменты, системы и подсистемы (типовой вариант)

АПК «Безопасный городª, их функции и технические характеристики,

предложения по сопряжению

1333

3.2.1

Архитектура АПК «Безопасный городª

1333

3.2.2

КСА «Региональная платформаª

1354

3.2.4

КСА Единый центр оперативного реагирования

1422

3.2.5

КСА функционального блока «Безопасность населения и

муниципальной (коммунальной) инфраструктурыª

159

3.2.6

КСА функционального блока «Безопасность на транспортеª

177

3.2.7

КСА функционального блока «Экологическая безопасностьª

189

3.3

Основные технические требования к параметрам оборудования АПК

«Безопасный городª

201

3.3.1

Требования к надежности

201

3.3.2

Требования безопасности

204

3.3.3

Требования к эргономике и технической эстетике

206

3.3.4

Требования к эксплуатации, техническому обслуживанию

и ремонту

207

3.3.5

Требования по сохранности информации при авариях

2088

3.3.6

Требования к защите от влияния внешних воздействий

2099

ОПРЕДЕЛЕНИЯ

Абонент

Лицо, пользующееся средствами связи и осуществившее

передачу информации в Систему

АПК

Аппаратно-программный комплекс технических средств

«Безопасный

«Безопасный городª

городª

Заявитель

Абонент, обратившийся с сообщением о происшествии

Злонамеренный

Событие, в основе которого лежит заведомо неверная

вызов

информация

Интерфейс

Граница взаимодействия разнородных автоматизированных

сопряжения

систем, посредством которой они обмениваются информацией.

(Сопряжение)

Карточка

Интерфейс для отображения информации по

зарегистрированному событию

Классификатор/

Систематизированный перечень наименованных объектов или

Справочник

один объект, которому в соответствие дан уникальный код

Консультация

Оказание пояснительно-информационных услуг Заявителю

Конференция

Телефонный вызов, охватывающий трех и более абонентов

Критически

Объект, значимость которого определяется органами

важный объект

государственной власти Российской Федерации, ее субъектов

или местного самоуправления с целью определения мер по

защите интересов государства, юридических и физических лиц

от преступных посягательств и предотвращения ущерба,

который может быть нанесен природе и обществу, а также от

возникновения чрезвычайной ситуации

Ложный вызов

Событие, отработка по которому выявила факт ошибочности

вызова

Область

Участок территории и/или перечень объектов, на которой

ответственности

конкретная ДДС осуществляет деятельность по

ДДС

предназначению, определенную законодательством РФ и/или

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

формирующей ДДС

Обращение

Факт сообщения о происшествии в ЕДДС

Обучение

Процесс подготовки, переподготовки и повышения

квалификации диспетчеров ЦУКС, ЕДДС и ДДС

Объект

Природный, техногенный или природно-техногенный объект

мониторинга

или его часть, в пределах которого по определенной программе

осуществляются регулярные наблюдения за окружающей

средой с целью контроля за её состоянием, анализа и оценки

происходящих в ней процессов, выполняемых для

своевременного выявления и прогнозирования их изменений и

оценки

Отработка

Действия, совершенные бригадой реагирования для

происшествия/

осуществления мер по устранению происшествия

Действия по

отработке

Процесс объединения автоматизированных систем единое в

Интеграция

целое.

Интеграционная

Программно-техническое решение, обеспечивающее

шина

сопряжение, интеграцию и/или информационное

взаимодействие разнородных автоматизированных систем.

Интернет -

Интернет-ресурс для граждан, представителей организаций и

Портал

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

информационным материалам, базе знаний консультативного

обслуживания и сервисам для регистрации заявки о КСП

Инцидент

Происшествие или ситуация, зарегистрированное в ЕДДС

Процесс обмена данными, находящимися в составных частях

Информационное

автоматизированной информационно-управляющей системы.

взаимодействие

Регламент

Совокупность правил, определяющих порядок работы

Оперативная

Совокупность действий, событий, происшествий, кризисных

обстановка

ситуаций, ЧС на территории муниципального образования за

определенный период времени, ведущих к изменению уровня

рисков общественной безопасности, правопорядка,

безопасности среды обитания.

Силы и средства

Специально подготовленные силы и средства федеральных

реагирования

органов исполнительной власти, органов исполнительной

власти субъектов Российской Федерации, органов местного

самоуправления, организаций и общественных объединений,

предназначенные и выделяемые (привлекаемые) для

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

Событие

Зарегистрированный в Системе факт обращения

Специалист

Лицо, сведущее в любой профессиональной области и

оказывающее консультационные услуги

Стационарный

Объект мониторинга, на котором установлен датчик

объект

мониторинга ситуации

мониторинга

Статус

Этап в процессе обработки инцидента

(автоматический

или ручной)

(инцидента)

Факсимильное

Графическое сообщение, передаваемое по телефонным сетям с

сообщение

помощью специального аппарата

Черный список

Список номеров телефонов абонентов, отмеченных в

злоумышленных или ложных вызовах

ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ

HTML

HyperTextMarkupLanguage — язык разметки гипертекста

IVR

InteractiveVoiceResponse — интерактивные голосовые

сообщения

PDF

PortableDocumentFormat — межплатформенный формат

электронных документов, созданный фирмой AdobeSystems

SMS

ShortMessageService — технология, позволяющая осуществлять

приём и передачу коротких текстовых сообщений сотовым

телефоном

XLS,XLSX

Формат файла программы MS Excel

АБД ГИС

Автоматизированная база данных на основе геоинформационных

технологий

АС РСЧС

Автоматизированная информационно-управляющая система

Единой государственной системы предупреждения и ликвидации

чрезвычайных ситуаций

АРМ

Автоматизированное рабочее место

АСКАВ

Автоматизированная система контроля аварийных выбросов на

химически опасных объектах

АСКРО

Автоматизированная система контроля радиационной обстановки

АСКОС

Автоматизированная система контроля окружающей среды

АС

Автоматизированная система

АХОВ

Аварийно-химически опасные вещества

БД ЭПТ

База данных электронных паспортов территорий

ГИС

Геоинформационная система

ГЛОНАСС/GPS

Глобальная навигационная спутниковая система

ГОСТ

Государственный стандарт

ДДС

Дежурно-диспетчерская служба

ЕДДС

Единая дежурно-диспетчерская служба

ИГИП

Интеграционная географическая информационная подсистема

ИС

Информационная система

ИУС

Информационно-управляющая система

ИСПДн

Информационная система персональных данных

КСА

Комплекс средств автоматизации

КСОБЖН

Комплексная система обеспечения безопасности

жизнедеятельности населения

КСЭОН

Комплексная система экстренного оповещения населения об

угрозе возникновения или о возникновении чрезвычайных

ситуаций

КСП

Кризисные ситуации и происшествия, а именно ситуации и

происшествия, сложившиеся на определенной территории или

акватории, в результате аварий, природных явлений,

противоправных действий и иных факторов,

которые при отсутствии необходимой профилактики могут

привести к возникновению чрезвычайной ситуации.

ЛИДАР

Автоматизированная система дистанционного мониторинга

окружающей среды

ЛСО

Локальная система оповещения

МГПО

Местный гарнизон пожарной охраны

МЧС России

Министерство Российской Федерации по делам гражданской

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

стихийных бедствий

НДВ

Не декларированные возможности

НПА

Нормативно-правовые акты

ОДС

Оперативная дежурная смена

ОМПЛ

Объект массового пребывания (постоянного и/или временного

нахождения) людей

ОКСИОН

Общероссийская комплексная система информирования и

оповещения населения в местах массового пребывания людей

ОС

Операционная система

ОПО

Общее программное обеспечение

ПАК

Программно-аппаратный комплекс

ПО

Программное обеспечение

ПОО

Потенциально-опасный объект

ПСЧ

Пункт связи пожарной части

ПТ

Паспорт территории

ПТК

Программно-технический комплекс

КТС

Комплекс технических средств

ПДн

Персональные данные

ПЭМИН

Побочные электромагнитные излучения и наводки

РСЧС

Единая государственная система предупреждения и ликвидации

чрезвычайных ситуаций

РЦОВ

Резервный центр обработки вызовов

РФ

Российская Федерация

Система-112

Система обеспечения вызова экстренных оперативных служб по

единому номеру «112ª

СКУД

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

СС ТМК

Система сбора результатов технического мониторинга и

контроля объектов транспортной инфраструктуры

СУБД

Система управления базами данных

ТЗ

Техническое задание

ТУ

Технические условия

ФОИВ

Федеральный орган исполнительной власти

ЦОВ

Центр обработки вызовов

ЦОВ-112

Центр обработки вызовов Системы-112

ЦОД

Центр обработки данных

ЦППС

Центральный пункт пожарной связи

ЦУКС

Центр управления в кризисных ситуациях

ИКТ

Информационно-коммуникационные технологии

ЦУКС ГУ МЧС

Федеральное казенное учреждение «Центр управления в

кризисных ситуациях ГУ МЧС России по Республики Саха

(Якутия)ª

ЧС

Чрезвычайная ситуация

ЭОС

Экстренная оперативная служба

ВВЕДЕНИЕ

К настоящему времени в рамках развития системы обеспечения

общественной безопасности, правопорядка и безопасности среды обитания в

муниципальных образованиях внедрены различные аппаратно-программные

комплексы (АПК). В целом, существующие АПК справляются с решением

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

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

усиливающуюся тенденцию урбанизации, способствуют возрастанию рисков ЧС

и тем, самым, создают угрозы для создания устойчивого социально-

экономического развития и роста инвестиционной привлекательности

муниципальных образований. Линейное наращивание состава АПК

безопасности на уровне субъекта Российской Федерации и муниципального

образования уже не дает желаемого роста эффективности, а ведет к чрезмерному

росту сложности системы безопасности муниципальных образований,

существенному увеличению затрат, затрудняет эксплуатацию и управление

этими системами, что в конечном итоге не создает предпосылок к эффективному

и адекватному управлению возрастающими рисками ЧС.

Эти обстоятельства выдвигают новые требования к функциональному

наполнению систем безопасности и обуславливают необходимость

комплексирования имеющихся автоматизированных, информационных систем

на уровне субъекта Российской Федерации и муниципального образования в

многоуровневую систему обеспечения общественной безопасности,

правопорядка и безопасности среды обитания.

Комплексирование имеющихся автоматизированных систем в

многоуровневая систему обеспечения общественной безопасности,

правопорядка и безопасности среды обитания позволит сформировать единое

информационное пространство, позволяющее использовать современные

подходы к мониторингу, прогнозированию, предупреждению правонарушений,

происшествий и чрезвычайных ситуаций и реагированию на них.

Работа выполнялась на основании технического задания на НИР

«Разработка организационных документов по созданию и развитию аппаратно-

программного комплекса «Безопасный городª (НИР «АПК Безопасный городª)

и проводится в соответствии с пунктом № 2-1-3-11/Б5 изменений в План научно-

исследовательских и опытно-конструкторских работ МЧС России на 2015 и

направлений перспективных научных исследований до 2020 года, утвержденных

приказом МЧС России от 28.09.2015 №519 на 2015 год.

Результаты, полученные в рамках выполнения данной НИР рекомендуется

использовать при построении и развитии АПК

«Безопасный городª в

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

1. Предложения по интеграции действующих информационно-

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

техногенной и общественной безопасности в аппаратно-программный

комплекс «Безопасный городª

1.1. Общие положения

Большинство современных автоматизированных систем состоят из

следующих компонентов:

Платформа, на которой функционируют остальные компоненты

системы, включающая в себя аппаратуру (железо) и системное ПО.

Данные, с которыми работает система. Состоят из СУБД и баз

данных.

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

системой. Состоят из компонентов бизнес-логики, пользовательского

интерфейса, вспомогательных компонентов (фрэймворк) и сервера приложений,

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

Бизнес-процессы, представляющие из себя сценарии работы

пользователей с системой.

Поэтому, интеграция информационных систем заключается в интеграции

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

(объектов интеграции):

интеграция платформ;

интеграция данных;

интеграция приложений;

интеграция бизнес-процессов.

Целями интеграции платформ является:

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

работающими на различных программно-аппаратных платформах (например,

между приложениями, работающими на серверах Windows, Solaris, Linux и др;

обеспечение возможности работы приложений, разработанных для

одной программно-аппаратной платформы, на других программно-аппаратных

платформах (например, приложений Windows на платформах Linux, Solaris и

др.).

Существует несколько подходов, направленных на достижение этих целей:

удаленный вызов процедур (RPC, CORBA, DCOM, Web-сервисы);

ПО промежуточного слоя (Microsoft.Net, Java Runtime);

виртуализация.

Технологии удаленного вызова процедур

(в широком смысле под

процедурой понимается некоторая функциональность приложения) позволяют

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

(передачи

входящих параметров и получения выходных результатов) для приложений,

работающих на других платформах. Элементами таких технологий обычно

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

WSDL), «адаптерª (переходник) процедуры, который транслирует внешние

вызовы во внутренние и передает результаты обратно (стабы) и менеджеры,

отвечающие за доставку запросов и результатов между платформами в сети

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

CORBA, DCOM, Web-сервисы.

Концепция программного обеспечения промежуточного слоя (framework,

среда исполнения, виртуальная машина) состоит в разработке прикладного ПО

не с использованием сервисов конкретной операционной системы (например,

Windows API), а с использованием сервисов ПО промежуточного слоя.

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

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

соответствующих функций фрэйворка в вызовы соответствующей операционной

системы. Типичным примером является технология Java Runtime Environment.

Приложения, разработанные для этой технологии работают на любых

программно-аппаратных платформах (Windows, Linux и др.) без каких-либо

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

Microsoft .Net Framework.

Интересной и современной концепцией является «виртуализацияª. К

интеграции платформ она имеет отношение постольку, поскольку позволяет

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

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

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

функционирование N операционных сред на N серверов, то применение

технологий виртуализации позволяет обеспечить функционирование N

операционных сред на M серверов. Если N > M - это позволяет сократить

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

использования. Если N < M - это простой путь увеличения производительности

систем. Например, виртуализация позволяет развернуть и одновременно

использовать на одном физическом сервере несколько операционных систем:

Windows, Linux и др. На каждом из таких «виртуальныхª серверов могут быть

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

По определению информационная система работает с данными. В

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

для их хранения. Интеграция на уровне данных предполагает совместное

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

проще, чем интеграция приложений, т.к. промышленные СУБД, в которых

обычно хранят данные информационные системы, имеют развитые возможности

программного доступа к данным из других приложений. Сами приложения при

этом могут иметь весьма ограниченные возможности программного

(вне

собственного пользовательского

интерфейса) использования своей

функциональности внешними системами.

Подходы к интеграции данных:

универсальный доступ к данным;

хранилища данных.

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

единообразный доступ к данным различных СУБД. Посредником для работы с

конкретной СУБД в данном случае является драйвер для соответствующей

СУБД. Это позволяет абстрагироваться от специфики конкретных СУБД и легко

осуществлять интеграцию данных, хранящихся в различных СУБД. Наиболее

распространенные технологии этого класса: ODBC, JDBC.

Концепция хранилищ данных состоит в создании корпоративного

хранилища данных. Хранилище данных - база данных, хранящая в себе данные,

собираемые из баз данных различных информационных систем, для целей их

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

(OLAP), отличные от технологий создания оперативных БД (OLTP). В основном

это делается для повышения производительности выполнения сложных

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

(многомерные запросы).

Подходы к созданию и наполнению хранилищ данных отражены в парадигме

ETL (extraction, transformation, loading = извлечение, преобразование и загрузка).

Технологии и инструментальные средства анализа больших массивов данных с

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

«Data Miningª. Термин для совокупности технологий хранилищ данных и

инструментальных средств и - «Business Intelligenceª.

Интеграция данных включает объединение данных, находящихся в

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

унифицированном виде. Роль интеграции данных возрастает, когда

увеличивается объём и необходимость совместного использования данных.

Системы интеграции данных могут обеспечивать интеграцию данных на

физическом, логическом и семантическом уровне. Интеграция данных на

физическом уровне с теоретической точки зрения является наиболее простой

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

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

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

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

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

структурных и, возможно, поведенческих

(при использовании объектных

моделей) свойств данных. Семантические свойства данных при этом не

учитываются. Поддержку единого представления данных с учетом их

семантических свойств в контексте единой онтологии предметной области

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

Процессу интеграции препятствует неоднородность источников данных, в

соответствии с уровнем интеграции. Так, при интеграции на физическом уровне

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

логическом уровне интеграции может иметь место неоднородность

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

схемы данных, хотя используется одна и та же модель данных. Одни источники

могут быть веб-сайтами, а другие — объектными базами данных и т. д. При

интеграции на семантическом уровне различным источникам данных могут

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

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

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

понятийная система, и эти фрагменты пересекаются.

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

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

относятся:

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

создание интегрирующей модели данных, являющейся основой

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

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

отображений в интегрирующую модель для конкретных моделей,

поддерживаемых отдельными источниками данных.

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

данных.

преодоление неоднородности источников данных.

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

данных.

Архитектуры систем интеграции:

а) Консолидация. В случае консолидации данные извлекаются из

источников, и помещаются в Хранилище данных. Процесс заполнения

Хранилища состоит из трех фаз — извлечение, преобразование, загрузка (Extract,

Transformation, Loading — ETL). Во многих случаях именно ETL понимают под

термином

«интеграция данныхª. Еще одна распространенная технология

консолидации данных

— управление содержанием корпорации

(enterprise

content management, сокр. ECM). Большинство решений ECM направлены на

консолидацию и управление неструктурированными данными, такими как

документы, отчеты и web-страницы.

Консолидация

— однонаправленный процесс, то есть данные из

нескольких источников сливаются в Хранилище, но не распространяются из него

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

основой для приложений бизнес-аналитики (Business Intelligence, BI), OLAP-

приложений.

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

между моментом обновления информации в первичных системах и временем,

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

места хранения данных, содержащие данные с большими временами отставания

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

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

определенными, заранее заданными интервалами. Конечные места хранения

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

приложений интеграции данных, которые постоянно отслеживают и передают

изменения данных из первичных систем в конечные места хранения.

б) Федерализация. В федеративных БД физического перемещения данных

не происходит: данные остаются у владельцев, доступ к ним осуществляется при

необходимости

(при выполнении запроса). Изначально федеративные БД

предполагали создание в каждом из n узлов n-1 фрагментов кода, позволяющего

обращаться к любому другому узлу.

При использовании медиатора создается общее представление (модель)

данных. Медиатор — посредник, поддерживающий единый пользовательский

интерфейс на основе глобального представления данных, содержащихся в

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

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

терминах единого интерфейса, декомпозируется на множество подзапросов,

адресованных к нужным локальным источникам данных. На основе результатов

их обработки синтезируется полный ответ на запрос. Используются две

разновидности архитектуры с посредником — Global as View и Local as View.

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

каждом запросе специальной оболочкой

(wrapper). Для этого необходима

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

полученных данных в единую модель. Сейчас этот способ также относят к

федеративным БД.

Интеграция корпоративной информации (Enterprise information integration,

сокр. EII)

— это пример технологии, которая поддерживает федеративный

подход к интеграции данных.

Изучение и профилирование первичных данных, необходимые для

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

консолидации.

в) Распространение данных. Приложения распространения данных

осуществляют копирование данных из одного места в другое. Эти приложения

обычно работают в оперативном режиме и производят перемещение данных к

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

первичной системе могут передаваться в конечную систему синхронно или

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

происходили во время одной и той же физической транзакции. Независимо от

используемого типа синхронизации, метод распространения гарантирует

доставку данных в систему назначения. Такая гарантия

— это ключевой

отличительный признак распространения данных. Большинство технологий

синхронного распространения данных поддерживают двусторонний обмен

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

поддерживающих распространение данных, являются

интеграция

корпоративных приложений (Enterprise application integration, сокр. EAI) и

тиражирование корпоративных данных (Еnterprise data replication, сокр. EDR).

От федеративных БД этот способ отличает двустороннее распространение

данных.

г) Сервисный подход. Сервисно-ориентированная архитектура SOA

(Service Oriented Architecture), успешно применяемая при интеграции

приложений, применима и при интеграции данных. Данные также остаются у

владельцев и даже местонахождение данных неизвестно. При запросе

происходит обращение к определённым сервисам, которые связаны с

источниками, где находится информация и ее конкретный адрес.

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

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

— это не запрос в традиционном смысле обращения к данным, скорее, это

извлечение некоторой бизнес-сущности (или сущностей), которое может быть

выполнено сервисом интеграции через серию запросов и других сервисов.

Подход SOA концентрируется, в первую очередь, на определении и совместном

использовании в форме сервисов относительно ограниченного количества самых

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

ориентированные интерфейсы в довольно большой степени строятся на

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

нужно представить потребителю.

Имея соответствующие учетные данные системы безопасности,

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

почти неограниченное количество различных запросов SQL. Но для этого

потребитель должен иметь представление о модели источника данных и способе

создания результата с использованием этой базовой модели. Чем сложнее модель

источника данных, тем более сложной может оказаться эта задача.

Вне зависимости от выбранных технологии и метода интеграции данных,

остаются вопросы, связанные с их смысловой интерпретацией и различиями в

представлении одних и тех же вещей. Именно, приходится разрешать

несоответствие схем данных и несоответствие самих данных.

Типы несоответствия схем данных:

Конфликты неоднородности

(используются различные модели

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

Конфликты именования

(в различных схемах используется

различная терминология, что приводит к омонимии и синонимии в именовании);

Семантические конфликты (выбраны различные уровни абстракции

для моделирования подобных сущностей реального мира);

Структурные конфликты (одни и те же сущности представляются в

разных источниках разными структурами данных).

Структурные и семантические конфликты выливаются в следующие

проблемы:

Различие в типах данных. Некоторый домен в одном источнике

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

третьем — строкой переменной длины;

Различие в единицах измерения. В одной БД указана величина в

сантиметрах, в другой — в дюймах;

Различие в множестве допустимых значений;

Различие

«домен-отношениеª. Домен в одной БД

(например

строковое значение) соответствует таблице в другой БД (записи из таблицы-

справочника);

Различие «домен — группа доменовª. В одном источнике адрес

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

строения, квартиры;

Различие «данные-схемаª. Данные одной БД соответствуют схеме

(метаданным) другой. В одной БД «инженерª — значение атрибута «должностьª

отношения «работникª, в другой

«инженерыª

— отношение, содержащее

некоторых работников, в то время как «бухгалтерыª содержит других;

Отсутствующие значения. В каком-то из источников может

отсутствовать информация, имеющаяся в большинстве других.

Разрешение этих несоответствий часто выполняется вручную.

Интеграция на уровне приложений подразумевает использование готовых

функций приложений другими приложениями.

Стоит упомянуть следующие подходы к интеграции приложений:

интерфейсы прикладного программирования;

обмен сообщениями (Корпоративная шина сервисов);

сервис-ориентированная архитектура;

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

Интерфейс прикладного программирования конкретной системы

представляет из себя «опубликованныйª функционал этой системы, который

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

функций (пример - Windows API) или в виде объектной модели (объекты со

свойствами и методами, пример - объектные модели приложений Microsoft

Office).

В большинстве случае интеграция нескольких систем заключается в

передаче информации между ними, например, в форме запрос-ответ. Если

системы функционируют в гетерогенных распределенных средах, то

принципиальное значение имеет обеспечение гарантированности, безопасности,

управляемости доставки информации между приложениями. Эти и другие

принципы реализуются в корпоративных системах обмена сообщениями. В

данном случае речь идет об обмене сообщениями между приложениями, а не

людьми, как, например, в случае E-mail или ICQ. Функциональность этих систем

достаточно прозрачна

- прием сообщения от одного приложения,

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

приложению. При этом может производиться шифрование сообщений (для

невозможности прочтения данных в процессе транспортировки), цифровая

подпись

(для защиты от умышленного изменения данных во время пути

сообщения), настройка подписки

(для отправки одного сообщения сразу

нескольким приложениям), определение метаданных для сообщений

(для

облегчения использования сообщений со сложной структурой содержимого) и

др [http://en.wikipedia.org/wiki/Enterprise_service_bus].

Сервис-ориентированная архитектура

(SOA) является современной

парадигмой. Она является логическим продолжением концепции Web-сервисов,

которая состоит в публикации функциональных блоков какого-либо приложения

в виде, позволяющем получить к ним доступ другим приложением через Web.

Web (протокол HTTP) в данном случае привлекателен ввиду возможности его

использования и, соответственно, использования опубликованных в Web

приложений на любых программно-аппаратных платформах. Web-сервис -

небольшая программная надстройка над функционалом приложения,

преобразующая вызовы, получаемы через Web во внутренние вызовы функций

приложения и возвращающая результаты обратно.

Публикация функционала корпоративных приложений в виде Web-

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

Построение на основе Web-сервисов новых приложений путем их

комбинации.

Понятно, что в данном случае создания новых приложений на основе

существующих Web-сервисов будет существенно ниже, чем разработка

приложений «с нуляª или обширная интеграция с другими системами.

Также часто используется следующий подход

- интеграция

пользовательских интерфейсов. Например, для создания приложений «одного

окнаª. Простейший пример - фреймы в вэб-странице. Внутри каждого фрэйма

при этом содержится отдельное вэб-приложение. Благодаря фрэймам, все эти

приложения отображаются на экране одновременно. Пользовательские

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

возможности интегрировать и «классическиеª пользовательские интерфейсы и

их фрагменты (ActiveX).

Наиболее целостным подходом к интеграции систем является интеграции

на уровне бизнес-процессов. В рамках интеграции бизнес-процессов происходит

и интеграция приложений, и интеграция данных и, что не менее важно, людей,

вовлеченных в этот бизнес-процесс. Интеграция на уровне бизнес-процессов

является наиболее

«естественнойª для организаций, т.к. их деятельность

состоит, прежде всего, именно из бизнес-процессов, а не приложений, баз

данных и платформ.

Идеи, лежащие в основе интеграции бизнес-процессов, достаточно просты

и включают следующие шаги:

составить сценарий некоторого бизнес-процесса, происходящего в

организации;

описать в нем операции взаимодействия пользователей с

различными системами и систем между собой.

Таким образом, бизнес-процесс является элементом, логически

интегрирующим различные системы. Сценарий создается при помощи

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

ходом этого бизнес-процесса согласно сценарию.

Операции взаимодействия с системами в рамках бизнес-процесса детально

описываются в терминах информационного обмена: форматы обмена,

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

К интегрирующему программному обеспечению, при помощи которого

описан сценарий бизнес-процесса, подключаются посредством адаптеров

интегрируемые системы, вовлеченные в бизнес-процесс. Таким образом,

становится возможным автоматизированный информационный обмен между

системами.

Готовый к выполнению бизнес-процесс выводится на «пульт управленияª

менеджера, при помощи которого, он может запускать и останавливать бизнес-

процессы, отслеживать их состояние, вводить данные и принимать решения на

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

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

осуществляется автоматически интегрирующим ПО.

Существует большое количество программных продуктов для интеграции

систем: коммерческий и бесплатных, с закрытыми исходниками и Open Source,

дорогих и дешевых, с различной функциональностью, рассчитанных на

различный масштаб бизнеса пользователей.

Можно выделить следующие классы продуктов для интеграции систем:

реализующие идеологию SOA;

реализующие идеологию Messaging (промежуточное ПО);

корпоративные шины сервисов;

средства интеграции на уровне бизнес-процессов (BPEL, Business

Process Execution Language);

средства интеграции данных.

Серьезные продукты для интеграции корпоративных приложений от

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

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

вендоров: Microsoft, Oracle и IBM.

Microsoft BizTalk Server.

BizTalk Server представляет собой программный продукт для интеграции

приложений и бизнес-процессов. Архитектура BizTalk Server, основана на

идеологии обмена сообщениями между приложениями.

Центральной частью системы является механизм обмена сообщениями

(Engine), который состоит из двух частей:

Messaging - транспортный уровень (прием, хранение и отправка

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

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

для подключения к системам и др.;

Orchestration - правила (логика) обработки сообщений. Например,

при помощи визуального дизайнера можно определить алгоритм, в соответствии

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

CRM-системы и бухгалтерской системы с целью дальнейшей обработки факта

продажи.

«Надстройкиª над BizTalk Server Engine (Business Activity Monitoring и

Services) предоставляют возможности управления бизнес-процессами в

организации на основании информации, собираемой в процессе «общенияª

интегрированных приложений.

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

необходимой информации (Tracking, задается при настройке правил обработки

сообщений в Engine) для целей дальнейшего мониторинга бизнес-процессов.

Например, можно описать бизнес-процесс продажи, включающий несколько

стадий (заказ, оплата, отгрузка и т.п.). Далее при получении сообщения от

соответствующей системы (POS, бухгалтерия, склад и т.п.), отражающего факт

изменения стадии конкретной продажи, это регистрируется и становится

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

Также следует отметить, что Microsoft BizTalk Server позиционируется

вендором как продукт для B2B-интеграции. Это означает, что интегрируемые

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

одной компании, а могут затрагивать несколько взаимодействующих компании,

например, в цепочке поставок. В этом случае каждая такая компания использует

Microsoft BizTalk Server для интеграции внутренних процессов и приложений и

взаимодействует с BizTalk-серверами других компаний для внешнего обмена

[http://www.microsoft.com/rus/biztalk/].

Microsoft SQL Server.

Общеизвестная СУБД Microsoft SQL Server является также примером

платформы для интеграции данных. Функции интеграции реализуются в MS SQL

Server следующими компонентами: Integration Services и Analysis Services.

Integration

Services является ETL-инструментом, позволяющим

[http://www.microsoft.com/sqlserver/2008/ru/ru/default.aspx]:

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

БД, текстовых файлов, RSS-каналов в Интернете, вэб-сервисов и др.);

Преобразовать их из исходных форматов в необходимые с

использованием промежуточных хранилищ или без них. Правила

преобразование и консолидации задаются разработчиками хранилища;

Поместить результат в информационное хранилище, в котором они

становятся доступными потребителям интегрированной информации.

Analysis Services поддерживает процесс интеграции данных на следующих

этапах, а именно:

Создание OLAP-хранилищ, в которое стекаются данные из

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

Обеспечение доступа к OLAP-данным, выполнения многомерных

запросов. Типичный пример - работа с данными при помощи Pivot Table.

Интеллектуальный автоматизированный анализ данных

(Data

Mining).

Oracle SOA Suite.

Данный продукт от Oracle похож по своей функциональности на BizTalk

сервер от Microsoft. Он разработан на технологиях Java, поэтому может работать

на различных платформах (Windows, Solaris, HP-UX, Linux).

Также, в отличие от BizTalk Server Oracle SOA Suite представляет из себя

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

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

[http://www.oracle.com/global/ru/ip/10g/as/bpel.html]:

Oracle BPEL Process Manager

- средство создания

(при помощи

визуального дизайнера),

«хостингаª и управления бизнес-процессами,

включающими в себя взаимодействие между людьми и интегрируемыми ИТ-

приложениями.

Oracle Business Activity Monitoring

- панель управления

(dashboard)

интегрированными бизнес-процесами. Позволяет просматривать различные

показатели бизнес-процессов (например, KPI), сервисов и их компонентов в

«одном окнеª.

Oracle Business Rules

- средство описания бизнес-правил и политик,

используемых в интегрированных бизнес-процессах.

Oracle Service Bus

«транспортный уровеньª, корпоративная шина

сервисов

(ESB), обеспечивает взаимодействия между различными

приложениями в организации.

Oracle Web Services Manager - инструмент централизованного доступа к

вэб-сервисам, существующим в организации, обеспечивающий создание

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

вэб-сервисы.

Oracle JDeveloper - среда разработки на Java от Oracle.

Connectivity - набор адаптеров (более 300) для подключения к различным

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

Oracle SOA Suite входит в состав продуктов middleware, для которых

вендор использует обобщающее название Oracle Fusion.

IBM WebSphere.

IBM WebSphere - это middleware от IBM, аналог Oracle Fusion. В составе

IBM WebSphere есть продукты, обеспечивающие интеграцию систем в

парадигме SOA (по аналогии с Oracle SOA Suite). Состав и функционал

продуктов

похож

на

аналогичное

ПО других вендоров

[http://www.ibm.com/products/ru/ru/]:

WebSphere Business Modeler

- средство визуального описания

интегрирующих бизнес-процессов.

WebSphere Process Server - хостинг и исполнение бизнес-процессов.

WebSphere Integration Developer

- среда разработки сервисных

компонентов.

WebSphere Business Monitor - инструмент мониторинга бизнес-процессов

WebSphere Enterprise Service Bus

- система, обеспечивающая

взаимодействие между сервисами, реализованным в компании в рамках SOA.

WebSphere MQ - система обмена сообщениями между приложениями, в

т.ч. в рамках SOA.

Интеграция данных включает объединение данных, находящихся в

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

унифицированном виде. Этот процесс становится существенным как в

коммерческих задачах (когда двум похожим компаниям необходимо объединить

их базы данных), так и в научных (комбинирование результатов исследования из

различных биоинформационных репозиториев, для примера). Роль интеграции

данных возрастает, когда увеличивается объём и необходимость совместного

использования данных.

Итоги сравнения интеграционных решений приведены в «Приложении Иª

В этом приложении показано, что сравнивались 16 интеграционных продуктов,

которые доступны на российском рынке. Альтернативы сравнивались по

следующим критериям:

Функциональность, технологичность и соответствие современным

взглядам;

Устойчивость к "Санкциям" и др. политическим демаршам;

Информационная безопасность;

Масштабность и сложность выполненных Проектов, особенно с

Госструктурами;

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

(сути) решений;

Сертификация;

Возможности доработки, гибкость;

Наличие исходных кодов и документации;

Наличие адаптеров взаимодействия с подсистемами АПК «БГª.

1.2. Перечень функций (задач), ранее созданных и действующих

автоматизированных информационно-управляющих систем различной

ведомственной принадлежности, интегрируемых в состав АПК

«Безопасный городª

1.2.1 Место АПК «Безопасный городª в структуре РСЧС

1.2.1.1 Согласно Концепции построения и развития аппаратно-

программного комплекса

«Безопасный городª возросшие требования к

функциональному наполнению систем безопасности обусловили необходимость

формирования на уровне субъекта Российской Федерации и муниципального

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

безопасности, правопорядка и безопасности среды обитания, базирующейся на

современных подходах к мониторингу, прогнозированию, предупреждению

правонарушений, происшествий и чрезвычайных ситуаций и реагированию на

них.

Целью построения и развития аппаратно-программного комплекса

«Безопасный городª является повышение общего уровня общественной

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

существенного улучшения координации деятельности сил и служб,

ответственных за решение этих задач, путем внедрения на базе муниципальных

образований комплексной информационной системы, обеспечивающей

прогнозирование, мониторинг, предупреждение и ликвидацию возможных

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

правонарушений.

На АПК «Безопасный городª муниципального образования возлагаются

задачи автоматизации процессов взаимодействия территориальных и

функциональных подсистем РСЧС, а также ведомственных подсистем на

территории муниципального образования.

Разработка организационных документов по созданию и развитию аппаратно-программного комплекса «Безопасный город» (2016 год) - часть 1