46679 (588420), страница 5

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 5)

Клиентские приложения Batch.21 связываются с сервером через интерфейс приложений Batch.21. Клиентские приложения позволяют организовать обмен периодическими данными с базой данных, настраивать базу данных, просматривать эти данные в Process Explorer и создавать отчеты в MS Excel.

Бизнес-логика системы Batch.21 сконцентрирована в сервере ППП (BCU) – программе преобразования партий (Batch Conversion Utility) и его компонентах, которые базируются на Microsoft Transaction Server. Эти компоненты осуществляют связь с реляционной СУБД и СУБД реального времени. Сервер ППП считывает данные из БД реального времени и преобразует их, согласно своим настройкам, в данные Batch.21. Через интерфейс приложений Batch.21 сервер ППП соединяется с сервером Batch.21.

Данные Batch.21 хранятся в реляционной базе данных Microsoft SQL Server или Oracle. Чтобы хранить технологические данные, необходимо использовать СУБД реального времени InfoPlus.21.

Таблица 1 – Особенности и преимущества Batch.21

Особенность	Преимущество
Периодические данные можно легко извлечь с помощью консоли запросов.	Это позволяет генерировать сложные отчеты по периодическим процессам без необходимости дополнительного программирования.
Временные диаграммы можно использовать для просмотра технологических данных, как периодических, так и обычных.	Пользователю нет необходимости изучать новые программные средства; быстрое переключение между графиками.
Псевдонимы тэгов	Пользователю нет необходимости знать, какой именно аппарат задействован для какой именно партии; он освобожден от необходимости запоминать имена тэгов.
Можно выбирать вид периодической диаграммы.	Можно сравнивать партии между собой, или сравнивать эффективность по различным параметрам для одной партии.
Имеются графические консоли для настройки Batch.21.	Упрощается настройка потока периодических данных.
С помощью ППП можно настраивать сбор периодических данных из базы данных реального времени.	Можно гибко настроить оптимальный баланс между текущей информацией и загрузкой системы; может накапливать данные в промежуточном хранилище.

Рассмотрев все аспекты для разработки автоматизированной системы управления документооборотом ЦЗЛ, изучив предметную область, в которой будет применяться данная система, и, собрав необходимые сведения о том, что бы хотели видеть пользователи данного программного продукта, в итоге получили конкретный метод решения:

• Клиент-серверная архитектура системы – трехзвенная

• Использование Web-forms (тонкий клиент)

• Язык программирования – Visual C #

• СУБД – Oracle

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

2. Специальная часть

2.1 Структура информационной системы

Web-browser Web-browser Web-browser

Рисунок 2 – Структура информационной системы и ее отдельных компонентов

Структура информационной системы построена по трехзвенной архитектуре «клиент – сервер».

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

• рабочих станций пользователей;

• серверов приложений;

• сервера базы данных.

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

СУБД Oracle представляет собой хранилище данных, к которым обращается система Batch.21. Используется Oracle 9i.

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

Все компоненты системы развернуты на серверах HP Proliant DL 360.

Batch.21 осуществляет выполнение запросов к базе и предоставляет два вида интерфейса:

• DCOM;

• Web‑сервисы.

Web‑сервисы используют передачу данных через XML. DCOM – технология распределенной компонентной модели.

Application Server – Web‑сервер, содержащий разработанные по технологии ASP. Net приложения для решения стоящих перед нами задач.

Клиентские ПК – «тонкие» клиенты, получающие доступ к приложениям Application Server через Web-browser.

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

1. Общие требования

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

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

Создаваемая система не должна влиять на работоспособность ИАСОУП, а лишь получать и предоставлять данные для общего использования.

2.2.2 Требования к структуре и функционированию системы

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

Серверная часть системы должна быть общей с ИАСОУП и использовать в качестве хранилища данных единую БД в СУБД Oracle.

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

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

2.2.3 Требования к удобству эксплуатации

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

1. Требования к защите информации от несанкционированного доступа

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

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

• человеко-машинный интерфейс;

• внешние носители (дискеты и т.п.);

• корпоративные компьютерные сети.

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

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

2.2.5 Требования по сохранности информации и надежности функционирования

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

2.2.6 Общие требования к функциям Системы

Все функции Системы должны выполняться с надежностью, оговоренной в п.п. 2.1. Выполнение любой из функций (основных или дополнительных) не должно приводить к останову или недопустимой задержке выполнения остальных функций Системы. Основными формами ввода информации должны быть экранные формы, соответствующие каждому виду испытаний. Основными формами представления журналов и протоколов являются сформатированные html‑документы. Формы ввода и структура выходных документов согласуются с Заказчиком в процессе выполнения проекта.

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

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

В состав ПО должно входить:

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

• специальное программное обеспечение.

Общее программное обеспечение представляет собой операционную систему Windows 2000 и выше с компонентами.NET Framework.

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

2.4 Описание программного состава информационной сети ЦЗЛ

В состав информационной сети ЦЗЛ входят приложения:

• Zakaz_web;

• Proba_web;

• DWTT_web;

• Rast_web;

• Udar_web;

• Xim_web;

Zakaz_web – данное приложение используется в цехах для оформления заказа на проведение испытаний в ЦЗЛ (Рисунок 4). В нем присутствуют все виды испытаний, проводимых в ЦЗЛ, а также основные характеристики испытываемых труб: толщина стенки, диаметр, номер плавки, номер трубы, марка стали и другие.

Рисунок 4 – Заказ на испытание труб

Также в данном приложении можно осуществить поиск уже имеющегося в базе данных заказа по номеру. Для формирования заказа необходмо выбрать цех (2, 3, 4, 5) и тип заказа (1‑сварное соединение, 2‑основной металл, 3‑зарезервировано, 4‑металлография) и нажать кнопку «Задать». Система сгенерирует очередной свободный номер заказа данного типа. После этого необходимо заполнить все поля формы и нажать кнопку «Сохранить». Если все поля заполнены правильно, заказ сохраняется и внизу появится сообщение «Заказ успешно сохранен», в противном случае выведется предупреждение. Из этой формы можно посмотреть бланк заказа, нажав кнопку «Бланк заказа».

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

DWTT_web – приложение, реализующее проведение испытаний на DWTT. В данном приложении используются такие параметры для проведения испытаний, как толщина образца трубы, высота сечения, высота хрупкой составляющей, толщина хрупкой составляющей, вязкая составляющая в процентах. Форма ввода данных DWTT является самой объемной, поскольку может сразу работать с несколькими заказами (до пяти). Это реализовано в связи со спецификой испытаний. Принятые к исполнению заказы можно загрузить в форму, нажав кнопку «Получить». После проведения испытаний и занесения параметров в поля формы, необходимо нажать кнопку «Рассчитать» для расчета вычисляемых величин и далее кнопку «Сохранить».

Rast_web – приложение, реализующее проведение испытаний на растяжение труб. В данном приложении присутствует два вида растяжений: продольное и поперечное. Главными параметрами для проведения испытаний служат начальная толщина, ширина, площадь, расчетная длина образца, а также конечная расчетная длин (Рисунок 7). Чтобы получить номер нужного заказа на испытания по растяжению труб, нелюходимо нажать кнопку «Получить», либо ввести номер нужного заказа. После ввода всех параметров необходимо нажать кнопку «Рассчитать» для получения результатов по испытанию, затем кнопку «Сохранить».

Udar_web – приложение, реализующее проведение испытаний на ударный изгиб по трубам.

Характеристики

Список файлов ВКР