4.Требования к подсистеме 4.1.Требования к подсистеме в целом 4.1.1.Требования к структуре и функционированию подсистемы
В ходе развития Подсистемы должно быть обеспечено представление Подсистемы в виде открытой информационной системы, взаимодействующей с информационными системами города Москвы, соответствующей централизованной структуре города Москвы и интегрируемой с другими информационными ресурсами России и мирового сообщества.
Модули создаваемых подсистем должны разрабатываться с учетом многоуровневой архитектуры.
Уровень представления должен быть отделен от уровня данных слоем бизнес-логики (Рисунок ).
Рисунок - Типовая схема трёхуровневой архитектуры
4.1.1.1.Перечень подсистем, их назначение и основные характеристики
В ходе работ должны быть модернизированы и созданы следующие функциональные и технологические модули Подсистемы:
Модуль сбора данных (технологический, модернизируемый);
Модуль хранения данных, переданных БНСО (технологический, модернизируемый);
Модуль биллинга (функциональный, модернизируемый);
Модуль диспетчеризации и управления БНСО (функциональный, модернизируемый);
Модуль интеграции с внешними системами (технологический, модернизируемый);
Модуль обработки и верификации (функциональный, модернизируемый);
Модуль управления заявками и инцидентами (функциональный, модернизируемый);
Модуль учета топлива (функциональный, создание);
Модуль обновления БНСО (функциональный, создание).
Исполнитель на этапе технического проектирования должен разработать или актуализировать и согласовать с Заказчиком архитектуру решения. Архитектура решения должна быть оформлена в соответствии с документом «Шаблон описания архитектуры». Решение по архитектуре должно отвечать, в том числе, нефункциональным требованиям, предъявляемым к системе.
4.1.1.1.1.Модуль сбора данных
Модуль сбора данных предназначен для обеспечения соединения, поддержания соединения с БНСО, приема, первичной обработки и накопления телеметрических и навигационных данных от БНСО, а также передачи управляющих команд БНСО из других модулей Подсистемы, трансляции ответов на команды, отправленные БНСО.
4.1.1.1.2.Модуль хранения данных, переданных БНСО
Модуль хранения данных, переданных БНСО предназначен для обеспечения хранения сырых данных, переданных БНСО и их передачи в неизменном виде во внешние системы.
4.1.1.1.3.Модуль биллинга
Модуль биллинга предназначен для обеспечения расчета показателей качества оказываемых услуг по передаче данных от БНСО и расчета сумм периодических платежей за оказываемые услуги.
4.1.1.1.4.Модуль диспетчеризации и управления БНСО
Модуль диспетчеризации и управления БНСО предназначен для обеспечения группового и индивидуального управления БНСО, а также ведения учетных данных БНСО и ТС и генерацию ключей защиты данных.
4.1.1.1.5.Модуль интеграции с внешними системами
Модуль интеграции с внешними системами предназначен для обеспечения передачи верифицированных навигационных и телеметрических данных во внешние системы.
Основным протоколом передачи является описанный в Приказе Минтранса РФ от 31.07.2012г. №285 протокол EGTS.
При этом поступающие пакеты данных от БНСО должны обрабатываться подсистемой и параллельно распределяться по нескольким потокам:
- для обработки внутри подсистемы (в формате подсистемы);
- для передачи информации во внешние системы (ЕСМЦ, РНИС и т.д.) в формате EGTS без учета шифрования;
4.1.1.1.6.Модуль обработки и верификации
Модуль обработки и верификации предназначен для обеспечения обработки данных, переданных БНСО, обработки телеметрии, пространственный и эвристический анализ навигационных данных.
4.1.1.1.7.Модуль управления заявками и инцидентами
Модуль управления заявками и инцидентами предназначен для обеспечения формирования заявок и инцидентов и рассылку уведомлений об отклонениях в навигационных данных и телеметрии, полученных от БНСО.
4.1.1.1.8.Модуль учета топлива
Модуль учета топлива предназначен для обеспечения трансляции и пересчета «сырых» показаний датчиков, поступающих от БНСО в физические единицы измерений: литры, кг и т.д.
4.1.1.1.9.Модуль обновления БНСО
Модуль обновления БНСО предназначен для обеспечения процессов группового обновления встроенного ПО БНСО.
4.1.1.2.Требования к способам и средствам связи для информационного обмена между компонентами Подсистемы
В качестве протокола взаимодействия между компонентами Подсистемы на транспортно-сетевом уровне необходимо использовать протокол TCP/IP.
Информационное взаимодействие между компонентами системы осуществляется посредством доступа к единому хранилищу данных (СУБД).
Для организации информационного обмена между компонентами Подсистемы должны использоваться специальные протоколы прикладного уровня.
Информационный обмен между компонентами Подсистемы и клиентскими приложениями должен осуществляться по локальной сети и по сети Интернет.
4.1.1.3.Требования по взаимосвязям Подсистемы с внешними и со смежными системами, обеспечению ее совместимости
Для сохранения единого информационного поля и корректной передачи данных при проведении работ по развитию ПСД АСУ ОДС должна быть реализована возможность взаимодействия с внешними системами:
АСУ ОДС;
ЕСМЦ;
РНИС;
УСМТ.
Требования к форматам данных, протоколам и режиму взаимодействия Подсистемы с внешними информационными системами должны быть определены на этапе Технического проектирования и описаны в рамках документа «Пояснительная записка к Техническому проекту».
4.1.1.3.1.Требования по интеграции с АСУ ОДС.
Взаимодействие между Подсистемой и АСУ ОДС должно осуществляться посредством веб-сервисов и/или прямого взаимодействия с БД АСУ ОДС согласно утвержденной спецификации взаимодействия.
4.1.1.4.Требования к режимам функционирования Подсистемы
В ходе работ по модернизации должно быть обеспечено функционирование Подсистемы в следующих режимах:
штатный режим, при котором обеспечивается выполнение задач в объеме функций, предусмотренных настоящим техническим заданием;
сервисный режим, необходимый для проведения обслуживания, реконфигурации и пополнения технических и программных средств Подсистемы новыми компонентами;
аварийный режим работы.
Пускового режима не предусмотрено.
В штатном режиме функционирования Подсистема должна обеспечивать следующий режим работы: доступность функций системы в режиме — 24 часа в день, 7 дней в неделю (24х7). Круглосуточный режим работы системы не требует организации круглосуточной работы пользователей и допускает работу пользователей в соответствии со штатным расписанием.
В сервисном режиме Подсистема должна обеспечивать возможность проведения следующих работ:
техническое обслуживание;
модернизацию аппаратно-программного комплекса;
устранение аварийных ситуаций.
Подсистема переходит в аварийный режим при возникновении нештатной ситуации и невозможности штатной работы. В случае перехода Подсистемы в аварийный режим, обслуживающему персоналу необходимо перевести Подсистему в сервисный режим в соответствии с инструкциями, изложенными в руководстве Администратора системы.
Должен быть предусмотрен механизм ручной фиксации сервисных и аварийных промежутков.
Регламентные работы должны производиться с учётом требований о доступности Подсистемы.
Функционирование Подсистемы при отказах и сбоях серверного общесистемного и специального программного обеспечения, и оборудования, в том числе структурных узлов Подсистемы, не предусматривается.
4.1.1.5.Требования по диагностированию Подсистемы
Для диагностирования Подсистемы должны использоваться штатные средства программно-аппаратного комплекса.
Диагностика программных и технических средств должна осуществляться с помощью стандартных режимов сетевой ОС, ОС АРМ и СУБД, а также путем прогона контрольного примера.
Программные компоненты модулей должны иметь проверочные методы, позволяющие провести контроль возможности функционирования основных режимов работы модулей.
При вводе в опытную эксплуатацию отдельных подсистем специалистами Исполнителя совместно с обслуживающим персоналом Подсистемы должно быть проведено полное тестирование и диагностика всех вводимых в опытную эксплуатацию элементов Подсистемы:
оборудования – элементов структурированной кабельной системы, активного сетевого оборудования, серверных кластеров и рабочих станций;
программного обеспечения – среды электронного взаимодействия, операционных систем серверов и рабочих станций, СУБД и СПО.
В процессе эксплуатации тестирование и диагностика программно-технических комплексов Подсистемы должны осуществляться в автоматическом режиме при запуске Подсистемы.
В рамках разработки Программы и методики испытаний должен быть сформирован Контрольный пример, обеспечивающий проверку работоспособности узла и подключения взаимодействующих систем как после первоначальной установки и загрузки БД, так и в процессе повседневной работы.
Инструменты диагностирования должны обеспечивать ведение и визуализацию журналов диагностических событий, в которых должны автоматически фиксироваться возникающие нештатные ситуации и ошибки. Данные журналы должны позволять сохранять набор информации, необходимой для идентификации и решения проблемы.
В штатном режиме должна осуществляться диагностика:
отказов комплекса технических средств (аппаратных средств):
серверного оборудования;
АРМ пользователей;
сетевого, телекоммуникационного оборудования и каналов связи;
оборудования резервного копирования информации;
отказы программных средств:
отказы общего ПО;
отказы СПО;
отказов в результате ошибок обслуживающего персонала и пользователей.
При обнаружении аварийных ситуаций, связанных с отказами аппаратных либо программных средств, Подсистема должна переходить в аварийный режим, обслуживающий персонал должен обеспечить выполнение работ по обслуживанию Подсистемы.
При отказах в результате ошибок пользователей средства диагностики должны обеспечивать формирование сообщений с описанием проблемы и способом ее устранения.
4.1.1.6.Перспективы развития, модернизации Подсистемы
Должна быть предусмотрена возможность масштабирования Подсистемы при увеличении нагрузки на Подсистему, т.е. учитываться требования к увеличению нагрузки, объемов информации и числа пользователей, последующему расширению функциональности.
Выбор КТС должен предполагать двукратное увеличение нагрузки без изменения архитектуры Подсистемы.
Прогнозные значения увеличения нагрузки на Подсистему в последующие 3 года функционирования Подсистемы:
Число пользователей 5000;
Объем хранимой информации 5 Тб.
Проектные решения, применяемые при создании Подсистемы, должны обеспечивать возможность дальнейшего развития и модернизации, как программного обеспечения, так и комплекса технических средств:
расширение функциональных возможностей за счет дополнительной разработки и внедрения новых подсистем;
информационное взаимодействие с внешними системами посредством веб-сервисов.
В рамках создания Подсистемы должны быть предусмотрены мероприятия по снижению трудозатрат при исполнении ее внутренних технологических процессов.
Технические решения, используемые на этапах проектирования и реализации Подсистемы, должны позволять минимизировать трудозатраты по модернизации, требуемые в связи с выпуском новых нормативных актов, приводящих к изменению технологического процесса.
|
