0 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

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

Требования, предъявляемые к комплексам средств и компонентов САПР

Общие технические требования к комплексам средств, относящихся к продукции производственно-технического назначения, устанавливает ГОСТ 23501.201—85, требова­ния к компонентам видов обеспечения САПР — ГОСТ 23501.101—87.

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

Комплексы средств для САПР должны обеспечивать:

автоматизацию проектирования изделий, технологиче­ских процессов, объектов строительства и организацион­ных систем;

заданный научно-технический уровень проектных ре­шений;

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

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

Комплексы средств для САПР должны обладать сле­дующими свойствами:

высоким качеством функционирования;

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

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

Стадии разработки, состав работ по стадиям, ком­плектность документации на компоненты и комплексы средств для САПР должны соответствовать ГОСТ 23501.119—83.

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

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

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

Общесистемные ПМК должны быть инвариантны к объектам проектирования и защищены от пользователей САПР. Их функционирование должно обеспечиваться специальными подразделениями (специалистами) в соста­ве службы САПР.

Базовые ПМК предназначены для проектирования объектов определенного класса, вида (деталей общема­шиностроительного применения, печатных плат, больших интегральных схем, технологической оснастки, сборочных единиц и изделия в целом и др.) или выполнения унифи­цированных проектных процедур (выбор физического принципа действия, проектирования маршрута обработки деталей и др.).

Базовые ПМК подразделяются на: проблемно-ориен­тированные; объектно-ориентированные.

Проблемно-ориентированные базовые ПМК предназна­чены для выполнения унифицированных проектных про­цедур, объектно-ориентированные — для проектирования объектов определенного класса (вида).

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

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

Требования, предъявляемыек ПТК. Центральный вычислительный комплекс (ЦБК) представляет собой ПТК, предназначенный для объединения действий со­вокупности АРМ в единый процесс проектирования, хра­нения и предоставления общесистемной информации, а также для дополнения вычислительных мощностей отдельных АРМ.

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

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

АРМ в зависимости от вида входящих в них програм­мно-методических комплексов подразделяют на проблем­но-ориентированные, объектно-ориентированные. Они должны функционировать как в автономном режиме, так и совместно с ЦВК.

В зависимости от вида и производительности исполь­зуемых процессоров различают АРМ высокой, средней и малой производительности.

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

В качестве АРМ низкой производительности широко применяются персональные ЭВМ, имеющие раз­витые технологические и инструментальные средства программирования.

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

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

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

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

Основной формой реализации компонентов информа­ционного обеспечения являются БД в распределенной или централизованной форме, организация данных в ко­торых обеспечивает их оптимальное использование в кон­кретных применениях.

Совокупность БД САПР должна удовлетворять прин­ципу информационного единства, т. е. использовать тер­мины, символы, классификаторы, условные обозначения, способы представления данных, принятые в САПР объ­ектов конкретных видов.

Независимо от логической организации данных БД должны обеспечивать:

информационную совместимость проектирующих и об­служивающих подсистем САПР;

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

возможность одновременного использования данных Из различных БД и различными пользователями;

возможность интеграции неоднородных БД для совме­стного их использования различными подсистемами САПР;

возможность наращивания БД;

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

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

К компонентам методического обеспечения относят:

утвержденную документацию инструктивно-методическо­го характера, устанавливающую технологию автоматизи­рованного проектирования; правила эксплуатации КСАП, ПТК и ПМК; нормативы, стандарты и другие руководя­щие документы, регламентирующие процесс и объект проектирования.

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

К компонентам математического обеспечения относят методы математического моделирования объектов и про­цессов проектирования, математические модели объектов и процессов проектирования, алгоритмы решения задач в процессе проектирования.

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

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

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

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

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

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

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

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

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

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

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

Требования к современным программным комплексам ИСБ. Часть 2

Эргономичность пользовательских приложений ПК

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

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

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

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

Дизайн и функционал пользовательского интерфейса должны обеспечивать:

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

Их набор зависит от роли пользователя на данном АРМ. На практике, в основном, можно выделить следующие основные роли:

1) Администратор системы.

В обязанности данного пользователя, как правило, входит:

2) Оперативный дежурный.

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

3) Сотрудник службы безопасности.

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

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

4) Сотрудник отдела кадров.

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

5) Сотрудник бюро пропусков.

Обеспечивает регистрацию посетителей и выдачу им гостевых пропусков. Его основные задачи:

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

Реализация пользовательских приложений ПК

При анализе существующих на рынке ПК для управления ИСБ, можно выделить два подхода к реализации пользовательских приложений:

1. Для каждой роли, или для каждой более-менее крупной пользовательской функции реализуется отдельное приложение (например, «Генератор отчетов», «Учет рабочего времени», «Дежурный режим» — такого рода приложения можно увидеть во многих ПК);

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

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

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

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

1) АРМ администратора.

Для эффективного решения задач администратора АРМ должно обеспечивать:

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

2) АРМ оперативного дежурного.

Основное требование к пользовательскому интерфейсу данного АРМ — отображение информации о наступившем событии, таким образом, чтобы оператору не нужно было производить лишних действий для получения дополнительной информации:

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

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

3) АРМ службы безопасности.

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

4) АРМ сотрудника отдела кадров.

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

5) АРМ оператора Бюро пропусков.

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

Дополнительные требования

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

Открытость

Под открытостью понимается возможность расширения функционала программного комплекса путем внедрения новых модулей, реализованных как силами заказчика, так и силами третьих сторон. Такая возможность значима для организаций, имеющих в своем составе IT-подразделение. В этом случае программный комплекс может быть сравнительно быстро и недорого модифицирован разработчиками ПО данной организации. Ограничения по расширению функционала зависят от архитектуры комплекса. Если ПК имеет модульную архитектуру, строился на стандартной технологии с открытым интерфейсом (типа COM, .NET, CORBA, J2EE, OPC и т.д.), то это позволяет разработать полноценный функциональный модуль для данной системы (новый драйвер оборудования, специализированное рабочее место и т.д.).

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

Переносимость (межплатформенность)

Переносимость – это возможность запуска комплекса на разных платформах (Intel, SUN SPARK) и операционных системах (ОС) – Windows, Linux, Unix, Solaris и т.д. Она позволяет использовать комплекс в гетерогенных сетях. Например, если в соответствии с политикой организации, для серверов запрещено использовать ОС Windows (по соображениям надежности, безопасности), то в этом случае серверная часть комплекса работает под управлением любой другой поддерживаемой операционной системы, а для пользовательских станций может также применяться ОС семейства Windows.

Если ПК обладает переносимостью, то возможно 2 варианта реализации:

1) для каждой поддерживаемой ОС существует своя реализация;
2) общая для всех ОС реализация (например, комплекс написан на Java).

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

Выводы

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

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

1. Надежность:

2. Защита от НСД (несанкционированного доступа):

Моделирование и проектирование программного комплекса

Требования, предъявляемые к программному комплексу

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

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

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

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

2) редактирование хранящейся информации;

3) удаление устаревшей информации.

б) классифицирование выпускников:

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

2) выдавать список студентов, классифицированных по вышеперечисленным признакам;

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

в) авторизация пользователей:

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

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

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

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

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

Диаграмма вариантов использования для проектируемого программного комплекса представлена на рисунке 2.1.

Рисунок 2.1 — Диаграмма вариантов использования

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

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

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

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

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

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

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

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

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

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

а) CPU (Процессор) — Intel Pentium/Celeron/Core2, AMD K6/Athlon/Duron/Phenom с частотой не менее 300 МГц;

б) рекомендуется не менее128 МБ ОЗУ;

в) монитор и видеоадаптер SVGA с разрешением не менее 800*600;

г) OC семейств Windows или Linux;

1) Mozilla Firefox v.2.0 — v.3.0.10;

3) Internet Explorer v8.0.

е) Клавиатура, мышь.

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

Программа должна работать под управлением любой 32-разрядной Windows системы без необходимости использования сторонних библиотек.

Для проектирования программы необходимо использовать такие среды проектирования как Microsoft Visio, ArgoUML, DbWrench и Microsoft Word. Для реализации данного программного продукта используется среда разработки PHP, Web-сервер Apache и СУБД MySQL.

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

Алдошин В. М., Ашурбейли И. Р., Соловьёв В. И.
ОАО «НПО «Алмаз» имени академика А. А. Расплетина»

Опубликовано в сборнике «Труды 58 научной сессии Российского научно-технического общества радиотехники, электроники и связи им. А. С. Попова»

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

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

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

2. В общем случае комплекс программно-технических средств и организационных (процедурных) решений по защите информации от НСД должен реализоваться в рамках «Концепции защиты средств вычислительной техники и автоматизированных систем от несанкционированного доступа к информации», разработанной Гостехкомиссией при Президенте Российской Федерации [ 1 ].

3. Системы защиты от НСД (СЗИ НСД) должны состоять из четырёх подсистем:

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

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

Уже в настоящее время в соответствии с указанными требованиями начинают формироваться состав и основные тактико-технические характеристики операционных систем, предназначенных для обеспечения организации защищённого вычислительного процесса ЭВМ различного уровня, поддержки работы систем управления базами данных (СУБД), программных приложений, специального программного обеспечения при использовании на высокотехнологичных предприятиях оборонно­промышленного комплекса Российской Федерации.

При этом следует учитывать, что основными стандартами, определяющими методы защиты информации, являются:

  • ГОСТ Р ИСО 10303-1 – 99 «Системы автоматизации производства и их интеграция. Представление и обмен данными об изделии. Методы описания. Общий обзор и основополагающие принципы»;
  • ГОСТ Р ИСО 10303-21 – 99 «Системы автоматизации производства и их интеграция. Представление и обмен данными об изделии. Методы реализации. Текстовый обменный файл»;
  • ГОСТ Р 1-001 – 99 «CALS-технология. Техническая документация в электронном виде. Основные положения и общие требования»;
  • ГОСТ Р 50.1.031 – 2001 «Информационные технологии поддержки жизненного цикла продукции. Терминологический словарь. Стадии жизненного цикла продукции. Рекомендации по стандартизации»;
  • ГОСТ 28147 – 96 «Системы обработки информации. Защита криптографическая. Алгоритмы криптографического преобразования».

Литература

1. Гостехкомиссия России. Руководящий документ. Концепция защиты средств вычислительной техники и автоматизированных систем от несанкционированного доступа к информации. – М.: Воениздат, 1992.

BASIC REQUIREMENTS FOR DATA SECURITY COMPLEX AT HIGH-TECH ENTERPRISES

Abstract. The demands for data security complex at high-tech plants are considered. The claims for information security in automated systems are summarized. There are also cited general standards for data security methods.

ОСНОВНЫЕ ТРЕБОВАНИЯ К КОМПЛЕКСУ ЗАЩИТЫ ИНФОРМАЦИИ НА ВЫСОКОТЕХНОЛОГИЧНЫХ ПРЕДПРИЯТИЯХ

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

Опубликовано в сборнике «Труды 58 научной сессии Российского научно-технического общества радиотехники, электроники и связи им. А. С. Попова». — М., 2003 год

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

Блок-2. Конструирование наземных автоматизированных комплексов управления (30)

21. Процесс проектирования наземных автоматизированных комплексов управления.

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

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

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

22. Этапы проектирования наземных автоматизированных комплексов управления.

23. Итерации при проектировании наземных автоматизированных комплексов управления.

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

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

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

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

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

Требуемые зоны видимости космического аппарата в значительной мере определяют количество антенн и наземных станций, необходимое для обслуживания данной космической системы. Зоны видимости в данном случае определяют частоту сеансов связи и процент времени, на протяжении которого космический аппарат должен поддерживать связь с наземной системой. Для геостационарных орбит одна наземная станция может обеспечить практически 100% видимость космического аппарата. Но космические аппараты на низких околоземных орбитах могут требовать привлечения большого количества наземных станций, поскольку каждая наземная станция может поддерживать связь с космическим аппаратом на протяжении ограниченного периода времени. Указанные временные ограничения рассмотрены в разделе 5.3, в котором в примере расчета определено, что время, в течение которого спутник находится в зоне радиовидимости наземной станции, составляет 12,3 мин. Обратите внимание, что это время практически равно максимальному времени, поскольку трасса спутника проходит почти через наземную станцию. Среднее время прохождения спутника через зону радиовидимости наземной станции будет значительно меньше 12 мин.

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

Требуемые зоны видимости космического аппарата в значительной мере определяют количество антенн и наземных станций, необходимое для обслуживания данной космической системы. Зоны видимости в данном случае определяют частоту сеансов связи и процент времени, на протяжении которого космический аппарат должен поддерживать связь с наземной системой. Для геостационарных орбит одна наземная станция может обеспечить практически 100% видимость космического аппарата. Но космические аппараты на низких околоземных орбитах могут требовать привлечения большого количества наземных станций, поскольку каждая наземная станция может поддерживать связь с космическим аппаратом на протяжении ограниченного периода времени. Указанные временные ограничения рассмотрены в разделе 5.3, в котором в примере расчета определено, что время, в течение которого спутник находится в зоне радиовидимости наземной станции, составляет 12,3 мин. Обратите внимание, что это время практически равно максимальному времени, поскольку трасса спутника проходит почти через наземную станцию. Среднее время прохождения спутника через зону радиовидимости наземной станции будет значительно меньше 12 мин.

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

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

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

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

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

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

28. Состав и назначение земных станций.

В состав оборудования типового ТК входит ТлОб следующих видов (рисунок 7.1):

— монтажно-стыковочное оборудование (МСО);

— подъемно-перегрузочное оборудование (ППО);

— стендовое оборудование (СтО);

— транспортное оборудование (ТрО).

— пневмовакуумное оборудование (ПВО);

— комплект проверочного оборудования (КПО);

— системы термостатирования (СТС);

— заправочно-нейтрализационные системы (ЗНС);

— комплект оборудования для хранения РКН и ее составных частей и содержания их в готовности;

— системы наземного электроснабжения специальными токами (СНЭСТ)

29. Состав и назначение основных элементов ракетно-космического комплекса.

Космический комплекс представляет собой совокупность функционально взаимосвязанных орбитальных и наземных технических средств, предназначенных для решения задач в космосе и из космоса в составе космической системы. КК предназначен для решения следующих задач [11, 12, 30]: 1) подготовка и запуск КА на заданную орбиту; 30 2) прием КА на управление на основании телеметрической информации о соответствии параметров орбиты заданным значениям и состоянии бортовых систем КА; 3) ввод КА в летную эксплуатацию и снятие КА с эксплуатации; 4) управление орбитальным полетом КА, контроль состояния и оценка качества функционирования бортовых систем КА в полете; 5) выполнение целевых задач в космосе и подготовка информации для доставки потребителю; 6) обнаружение и обслуживание возвращаемых с орбиты элементов КА, а также отделяемых частей РН; 7) поддержание ОГ КА в требуемом составе. Как было отмечено выше, КК является неотъемлемой частью КС.

30. Классификация ракетно-космических комплексов.

Ракетно-космические комплексы являются универсальными и входят в состав различных космических комплексов. Технический облик РКК определяется ракетой-носителем. Название ракеты-носителя дает название и самому РКК. Например, РН «Протон» и РКК «Протон». Структура РКК представлена на рисунке 2.2. КСИСО предназначен для обеспечения контроля параметров РКН и ее составных частей при подготовке на ТК и СК, а также при полете РКН на участке выведения, обработки, документирования и распределения информации между потребителями. Основными функциями КСИСО являются: — привязка измерений к единой шкале времени; — автоматизированный сбор, обработка, отображение и документирование информации о параметрах систем РКН на ТК и СК; — внешние траекторные измерения на активном участке полета РКН (на участке выведения) с помощью радиолокационных станций; — прием радиосигналов от системы телеметрических измерений РКН;

31. Состав и назначение основных элементов ракетно-космического комплекса.

Ракетно-космический комплекс предназначен для подготовки РН, КА, РБ к применению по назначению и вывода КА (ОБ) на околоземную орбиту. Анализ выполняемых РКК функций показывает, что все они могут быть разделены на две группы [11, 18, 30]: 1) приведение бортовых систем РН, КА, РБ в состояние, позволяющее провести пуск РКН в установленное время, вывести КА на заданную орбиту и обеспечить функционирование КА в полете; 2) проверка технического состояния бортовых систем РН, КА, РБ и устранение обнаруженных неисправностей. Технология всех проводимых при функционировании РКК работ определяется конструкцией КСр. Объем и длительность процесса подготовки РН, КА, РБ, степень автоматизации работ и обработки их результатов характеризуют эксплуатационное совершенство КСр. При функционировании РКК решаются следующие задачи: — транспортирование РН, КА, РБ и комплектующих элементов с предприятия-изготовителя или арсенала на космодром; — хранение РН, КА, РБ и комплектующих элементов; — подготовка РН, КА, РБ на техническом комплексе и сборка РКН; — транспортирование РКН на стартовый комплекс; — подготовка РКН к пуску на стартовом комплексе, заправка РН (и РБ) КРТ, пуск РКН

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

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

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

Задача определения оптимальной структуры КТС является многофакторной в связи с многообразием требований ( структурных, функциональных, технических экономических ) предъявляемых к этой структуре АСУ. АСУ требует рационального распределения вычислительных мощностей по уровням управления обеспечивающих наиболее эффективную обработку данных. С этой точки зрения централизация обработки данных на более высоких уровнях управления и создание мощных вычислительных центров увеличивает загрузку технических средств и уменьшает затраты на их обслуживание. В тоже время при такой структуре КТС резко увеличивается загрузка каналов связи, а значит, и стоимость затрат на функционирование АСУ. Поэтому целесообразнее объединить обработку информации в условиях АСУ не более чем двух ближайших уровней. Например, при создании ОАСУ ( отрасль – подотрасль – предприятие ) целесообразно объединить вычислительные мощности для отраслей и подотраслей предприятий, цехов и т. д. Функциональные требования выражаются в том, что КТС должен объединить решение задач АСУ в заданное время и с необходимой точностью. При этом следует учесть, что любая АСУ является постоянно развивающейся системой и ее КТС должен иметь возможность при необходимости перестраиваться на решение новых задач.

С точки зрения эффективного функционирования КТС в АСУ можно выделить следующие задачи:

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

-оптимизационные и прогнозные, решаемые по расписанию;

-справочные, решаемые с высокой оперативностью в случайные моменты времени;

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

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

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

Каждая из перечисленных задач определяет соответствующее требование к КТС.

К техническим требованиям, предъявляемым к КТС, относятся:

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

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

-надежность КТС, т. е. возможность бессбойного функционирования в АСУ.

К экономическим требованиям относятся :

-минимальная стоимость КТС;

-минимальная стоимость обслуживания КТС.

Таким образом при разработке КТС приходится решать задачу синтеза: построить КТС из заданных элементов, так, что бы он удовлетворял заданному критерию эффективности функционирования АСУ.

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

Где — время обработке данных в подсистеме i для варианта j;

N – количество вариантов по способам обработки в каждой подсистеме;

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

-стоимость обработке данных в подсистеме i для варианта обработки j;

-общая допустимая стоимость обработки, если исходить из допустимых затрат на создание КТС и его эксплуатацию.

К подсистемам КТС по приведенному выше перечню классов задач на данном уровне управления можно отнести:

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

-подсистему обработки, накопления и хранения данных;

-подсистему вывода, передачи и выдачи данных.

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

-средства сбора, регистрации и обработки данных;

-оперативного обмена данными;

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

Дата добавления: 2015-06-17 ; просмотров: 2966 ; ЗАКАЗАТЬ НАПИСАНИЕ РАБОТЫ

Ссылка на основную публикацию
Adblock
detector