Автор: Пользователь скрыл имя, 09 Марта 2013 в 08:54, дипломная работа
С целью обеспечения возможности взаимодействия человека с ЭВМ в интерактивном режиме появляется необходимость реализовать в рамках АСУ так называемое АРМ – автоматизированное рабочее место. АРМ представляет собой совокупность программно-аппаратных средств, обеспечивающих взаимодействие человека с ЭВМ, т.е. такие функции как:
возможность ввода информации в ЭВМ;
возможность вывода информации из ЭВМ на экран монитора, принтер или другие устройства вывода (в настоящее время этот перечень достаточно широк – графопостроители, и т.п.).
РЕФЕРАТ 4
ОСНОВНАЯ ЧАСТЬ 5
ВВЕДЕНИЕ 5
1. АНАЛИЗ КОНЦЕПЦИИ ПОСТРОЕНИЯ КОМПЛЕКСА СРЕДСТВ АВТОМАТИЗАЦИИ 8
1.1. Общая характеристика систем управления 8
1.2. Структурная схема комплекса средств автоматизации. 11
1.3. Описание функционирования АСУ комплекса средств автоматизации 13
1.4. Функциональное назначение АРМ РД 14
1.5. Требования, предъявляемые к АРМ РД 15
2. ОБОСНОВАНИЕ ВЫБОРА ТЕХНИЧЕСКИХ СРЕДСТВ АРМ РД 17
2.1. Возможность функционировать в рамках автоматизированной системы 17
2.2. Требования по обеспечению надежности 17
2.3. Требование круглосуточной работы 17
2.4. Работа в реальном масштабе времени 18
2.5. Обеспечение требований ко времени реакции системы 18
2.6. Хранение и обработка данных 18
2.7. Возможность выдачи информации на принтер и экран монитора АРМ РД 19
3. СТРУКТУРА БАЗЫ ДАННЫХ 20
3.1. Алгоритм обработки информации 20
3.2. Обоснование необходимости организации базы данных 34
3.2.1. Понятие базы данных 34
3.2.2. Достоинства интеграции данных. 35
3.2.3. Проблемы интеграции данных 37
3.2.4. Необходимость организации БД на АРМ РД 38
3.3. Логическая организация базы данных 39
3.4. Выбор СУБД 45
4. СТРУКТУРА КОМПЛЕКСА ПРОГРАММ АРМ РД 51
4.1. Обоснование структуры комплекса программ 51
4.1.1. ПО общесистемного назначения 51
4.1.2. ПО специального назначения 53
4.1.3. Требования, предъявляемые к специальному ПО АРМ РД 53
4.2. Программная реализация 54
4.3. Состав программ 59
4.4. Описание программ 61
4.5. Оценка результатов работы программ 63
ОРГАНИЗАЦИОННО-ЭКОНОМИЧЕСКАЯ ЧАСТЬ 66
ВВЕДЕНИЕ 66
1. ПЛАНИРОВАНИЕ РАЗРАБОТКИ С ИСПОЛЬЗОВАНИЕМ СЕТЕВОГО ГРАФИКА 67
2. РАСЧЕТ СТОИМОСТИ РАЗРАБОТКИ 79
2.1. Расчёт статьи “материалы, покупные изделия, полуфабрикаты” 79
2.2. Расчёт основной заработной платы по теме 80
2.3. Расчет дополнительной заработной платы 81
2.4. Расчёт отчислений на социальные нужды 82
2.5. Расчёт накладных расходов 82
2.6. Расчёт договорной цены 83
3. ЭКОНОМИЧЕСКАЯ ЭФФЕКТИВНОСТЬ РАЗРАБОТКИ 84
4. ОСНОВНЫЕ РАЗДЕЛЫ ХОЗЯЙСТВЕННОГО ДОГОВОРА 84
ЗАКЛЮЧЕНИЕ 86
ОХРАНА ТРУДА И ТЕХНИКА БЕЗОПАСНОСТИ 87
ВВЕДЕНИЕ 87
1. ХАРАКТЕРИСТИКА ПОМЕЩЕНИЯ И ФАКТОРЫ, ДЕЙСТВУЮЩИЕ НА ОПЕРАТОРА В ПРОЦЕССЕ ЕГО ТРУДА 88
2. РАСЧЁТ ОСВЕЩЕНИЯ РАБОЧЕГО МЕСТА ОПЕРАТОРА 89
3. РАСЧЁТ ИНФОРМАЦИОННОЙ НАГРУЗКИ 94
ВЫВОДЫ 95
ГРАЖДАНСКАЯ ОБОРОНА 97
ВВЕДЕНИЕ 97
1. ТЕОРЕТИЧЕСКАЯ ЧАСТЬ 98
1.1. Оценка воздействия ударной волны на объект 98
1.1.1. Характеристики ударной волны 98
1.1.2. Поражающие факторы ударной волны 99
1.2. Оценка пожарной обстановки 101
1.2.1. Влияние степени огнестойкости зданий и сооружений на развитие пожарной обстановки 102
1.2.2. Влияние категорий пожароопасности производства на развитие пожарной обстановки 102
1.2.3. Влияние расстояний между зданиями на распространение пожаров 103
1.2.4. Влияние погодных условий на распространение пожаров 103
1.2.5. Оценка воздействия теплового импульса огненного шара на пожарную обстановку 103
1.2.6. Оценка воздействия вторичных поражающих факторов на пожарную обстановку 105
1.2.7. Воздействие пожара на людей и элементы объекта 105
1.3. Оценка устойчивости элементов объекта 105
2. РАСЧЕТНАЯ ЧАСТЬ 106
2.1. Исходные данные 106
2.2. Расчет 106
2.2.1. Оценка воздействия воздушной ударной волны на элементы объекта 106
2.2.2. Оценка пожарной обстановки 107
3. ПРЕДЛОЖЕНИЯ ПО ЗАЩИТЕ 109
3.1. Отнесение хранилища на безопасное расстояние от здания 109
3.2. Уменьшение массы хранимого пропана 110
3.3. Меры по предупреждению аварийной ситуации на хранилище пропана 111
3.4. Меры по защите административного здания 112
3.5. Меры по индивидуальной защите оператора 112
ЭРГОНОМИКА 113
1. ТЕОРЕТИЧЕСКАЯ ЧАСТЬ 114
1.1. Базовый подход к конструированию рабочего места оператора 114
1.2. Понятие рабочего места и рабочей зоны оператора 115
1.3. Формирование типового состава рабочей зоны 115
1.3.1. Организация пространства рабочего места оператора 116
1.3.2. Условия, которым должна удовлетворять рабочая зона 116
2. РЕАЛИЗАЦИЯ ЭРГОНОМИЧЕСКОЙ ОЦЕНКИ РАБОЧЕГО МЕСТА ОПЕРАТОРА 117
2.1. Основные эргономические требования, предъявляемые к дисплею 118
2.2. Основные эргономические требования, предъявляемые к клавиатуре 120
2.3. Размещение кресла оператора в рабочей зоне 121
2.4. Размещение устройств документирования 121
2.5. Расположение рабочего места оператора в помещении 122
ЗАКЛЮЧЕНИЕ 124
ЗАКЛЮЧЕНИЕ 127
ПРИЛОЖЕНИЕ 1 128
ПРИЛОЖЕНИЕ 2 131
СПИСОК ЛИТЕРАТУРЫ 163
Эти задачи можно осуществить при помощи создания единого хранилища – базы данных и использования средств СУБД.
3.3. Логическая организация базы данных
Для реализации логической организации БД необходимо определить, что является объектом предметной области информационной системы. Как уже было отмечено выше (п. 3.1.1.), любое сообщение в системе, или кодограмма, имеет формат в рамках заранее оговоренного Протокола информационного обмена. Разряды кодограмм регистрации содержат ряд характеристик, определяемых типом поступающей по устройству информации:
В зависимости от типа передаваемого по устройству сообщения, содержимое разрядов кодограмм различно, а, следовательно, различны и атрибуты объектов информационной системы. Если рассматривать информационную систему в части отображения информационного и технического состояния устройств (ФК), то объектом предметной области является информация о состоянии устройств.
В общем случае объектом предметной области является, например, распоряжение администратора, директора, т.е. те управляющие воздействия, которые циркулируют в АСУ в процессе ее функционирования. Прежде чем говорить о формировании отношений, необходимо привести перечень атрибутов, выявляющих сущность объектов, которые затем формируются в отношения:
После составления перечня атрибутов, очередная задача состоит в определении набора отношений и составлении логической структуры БД. Логическая структура базы данных представлена на рис. 18 и состоит из набора отношений, представленных в третьей нормальной форме.
Отношение 1: “Вся информация”. Ключевыми доменами являются первые два поля: “Дата”, “Время”.
Отношение 2: “Оперативная информация”. Ключевыми доменами в данном отношении являются “Дата”, “Время”, “Направление”, “Режим работы”, “Источник”, “Вид сообщения”.
Отношение 3: “Информация Ш” Ключевыми доменами являются “Дата”, “Время”, “Направление”, “Режим работы”.
Отношение 4: “Сбойные кодограммы”. Ключевыми доменами являются: “Дата”, “Время”, “Направление”, “Количество”, “Вид сообщения”, “Слово1”, “Слово2”, “Слово3”, “Слово4”.
Отношение 5: “Функциональный контроль”. Ключевыми доменами являются: “Дата”, “Время”, “Тип”, “Признак”, “Вид сообщения”.
Отношение 6: “Связь с ВК”. Ключевыми доменами являются “Дата”, “Время”.
Отношение 7: “Текущая контрольная сумма”. Ключевыми доменами являются:
“Дата”, “Время”.
Отношение 8: “Контрольная сумма при пуске ВК”. Ключевыми доменами являются: “Дата”, “Время”.
При формировании отношений были поставлены следующие цели: осуществить группировку записей в такие структуры, которые достаточно малы по размеру и поэтому управляемы. При этом данные могут дублироваться, например, отношение ФК может включать в себя информацию о связи с ВК. Однако созданием отношения “Связь с ВК” мы выделяем его в логически самостоятельное отношение и тем самым уменьшаем время поиска важной для нас информации. Это означает, что информация, требующая к себе первостепенного внимания, выделяется в отдельные отношения с целью уменьшения времени поиска по БД, давая возможность персоналу, обслуживающему КСА своевременно реагировать на изменения, возникающие в системе.
С такой же целью выделяется в отдельные отношения информация контрольного суммирования, информация контрольного суммирования при пуске ВК, информация Ш.
Отношения “Вся информация”, “Оперативная информация” и “Функциональный контроль” также выделяются в отдельные отношения из логических соображений и для минимизации времени поиска.
Еще одна причина, по которой отношения организуются подобным образом – это разграничение доступа пользователей.
Информация фиксируется в восьми не связанных друг с другом таблицах, и один пользователь, например, может иметь доступ только к БД “Информация контрольного суммирования”, другой – к БД “Информация Ш”. В дипломном проекте рассматривается только та информация, которая содержится в БД ФК.
Отношение ФК содержит информацию о результатах ФК, среди которой имеется информация о БС устройств. Кроме БС, отношение ФК содержит и другую информацию, например, о несанкционированном доступе (НСД), о навязывании ложной информации (НЛИ), информацию о ФК, об обращении к памяти (НОП), и т.д. Информация ФК имеет внутренний формат представления для хранения в памяти ЭВМ и формат для предъявления оператору на экране дисплея или на принтере в виде таблиц и справок.
Вид полей БД ФК представлен на рис. 19.
Структура БД ФК включает в себя следующие элементы: “Дата”, “Время”, “Тип устройства”, “Признак” (признак группирования информации), “Вид сообщения” (БС, НСД, ФК, НЛИ, и т.д.), “Текст сообщения”. В поле “Текст сообщения" находится сообщение типа: “НСД снято”, или “Нет связи по линии 1”, или “разблокировано по ФК”, и т.п., т.е. раскрывается конкретное значение поступившего по устройству сообщения. Остальные элементы, перечисленные ранее, являются ключевыми, и служат для поиска последнего элемента “Текст сообщения”.
3.4. Выбор СУБД
Выделение СУБД - претендентов
Проектировщику в настоящее время предоставляется достаточно большой выбор СУБД, разработанных для разных конфигураций и типов ЭВМ. Анализ основных параметров этих систем позволяет сразу же отвергнуть ряд СУБД, заведомо непригодных к использованию в разрабатываемой информационной системе, оставив для последующего рассмотрения не более 2-х – 3-х систем - претендентов.
На выбор СУБД – претендентов наибольшее влияние оказывает согласование ряда параметров среды реализации и СУБД. Наиболее значимые параметры перечислены ниже (в скобках указаны характеристики АРМ РД):
Перечислим СУБД подобного класса: D-Base, Clipper, Paradox. Перед тем как приступить к сравнительному анализу моделей баз данных, и, следовательно, к окончательному выбору СУБД, необходимо выделить набор факторов, которые влияют на окончательный выбор варианта.
Наиболее часто используемые факторы оценки моделей баз данных:
На этом этапе необходимо несколько детализировать требования к реализуемому ПО АРМ РД.
Как было отмечено в п.3.3.1., обмен информацией в системе происходит при помощи кодограмм, которые содержат информацию о состоянии устройств в двоичном коде, поэтому требования к СУБД, и соответственно к программам-приложениям достаточно жестки – необходимо обеспечить выборку сведений об устройствах, причем с возможностью их представления не в двоичном виде, а в удобной для анализа форме – в виде таблиц и справок.
Следовательно, большие требования предъявляются даже не к СУБД, а к языку программирования, на котором будут создаваться программы-приложения. Реализация программных средств окружения СУБД и приложений достаточно трудоемкий процесс.
При выборе СУБД необходимо учесть и такой фактор, как наличие опыта у разработчиков в создании прикладных программ для данной СУБД, часто он является определяющим.
В качестве программного продукта для создания ПО АРМ РД была выбрана разработка фирмы Borland – язык программирования Турбо Си++ версии 3.0 и библиотека стандартных программ на языке Турбо Си++ Paradox Engine для реализации обслуживания реляционных баз данных.
Paradox Engine является уникальным программным средством, позволяющим программистам языка Си в полном объеме использовать архитектуру системы Paradox.
Engine - библиотека стандартных программ на языке Си, которые можно объединить с любой прикладной программой на языке Си. В большинстве современных систем общий доступ к данным можно осуществить лишь при выполнении дополнительных операций - обычно файлы одной операционной среды переводятся в форматы другой, и наоборот. Если при анализе задачи выясняется, что исходные данные хранятся в разных системах, то проблемы обобщения становятся важной областью решения задачи.
Engine устраняет эту проблему, открывая структуру данных Paradox для программ на языке Си. Таким образом, прикладные программы на языке Си получают возможность обрабатывать данные системы Paradox.
Paradox Engine - это удобное средство для разработчиков программ обслуживания реляционных баз данных на традиционном языке программирования. Разработчики Engine могут использовать данные системы Paradox или разрабатывать приложения, которые в дальнейшем можно развивать на основе Paradox. Разработчики Paradox могут расширить функции системных программ Paradox, дополнив их вспомогательными программами на языке Си.
Основные характеристики системы Paradox.
Таблицы Paradox - это стандартные файлы DOS с расширением “.DB”. Имена таблиц отвечают стандартным соглашениям об идентификации файлов, принятым в ОС MS DOS.
Каждая таблица может содержать до двух биллионов записей, а при ее записи на диск размер таблицы ограничен только размером диска или объемом свободной памяти на диске.
Каждая запись может включать до 255 полей, а каждое поле до 255 символов.
В Paradox используется пять типов полей: алфавитно-цифрового типа, которые позволяют использовать полный набор символов кода ASCII, числовые поля данных, позволяющие использовать до 15-ти значащих цифр, включая место для десятичной точки в интервал значений, а также текущие поля данных, короткие числовые поля и поля даты.
Для упорядочения и поиска ключевых полей таблицы в Paradox Engine предусмотрены специальные функции, использующие индексный метод доступа. Индекс таблицы позволяет ускорить процесс поиска нужной записи. Первичный индекс упорядочивает записи в порядке возрастания ключевых полей. Paradox хранит записи отсортированными по ключу и не позволяет дублировать ключи. Вторичные индексы, как правило, организуются для очередей таблиц и служат для улучшения представления данных.
Для создания оконного интерфейса пользователя используется библиотека СXL- библиотека функций на языке С, что дает возможность ускорить написание программы, так как позволяет уделить больше времени решению основной задачи.
Конечно, нельзя однозначно сказать, что выбранная СУБД идеально соответствует поставленной перед разработчиками задаче. Для иллюстрации сравним Paradox Engine и СУБД Paradox с внутренним языком программирования PAL.
PAL - это внутренний язык программирования системы Paradox. Сравнивая PAL и Си, можно отметить, что и тот и другой обладают рядом преимуществ и недостатков.
Например, PAL обладает обширным встроенным аппаратом для обслуживания баз данных, однако не обладает гибкостью и управляющими возможностями языка Си. С другой стороны, Си, обеспечивая максимально возможный уровень управления программой, и, следовательно, ее гибкость, не обладает возможностью обслуживания баз данных.