Содержание к диссертации
Введение
Глава 1. Информационно-управляющая система астраханского гпз как объект исследования 11
1.1. Технологический процесс и его особенности 12
1.2. Основные характеристики и особенности применяемых АСУТП . 17
1.3. Обзор подсистем уровня асуп астраханского гпз 22
1.4. Выводы 24
Глава 2. Методы проектирования и анализа интегрированных риус .26
2.1. Основные свойства риус 27
2.2. Архитектурные особенности риус 28
2.3. Методы проектирования и анализа риус 30
2.3.1. Распределенные банки данных 30
2.3.2. Протокол вызова удаленных процедур 34
2.3.3. Объектно-ориентированные методы построения 36
2.3.4. Технология вызова удаленных методов rmi .39
2.3.5. Архитектура управления объектами ома 40
2.3.6. Общая архитектура объектных брокеров corba 42
2.3.7. Интеграция corba и интернет/интранет - приложений 48
2.4. Сравнительный анализ реализаций архитектуры corba 50
2.4. Выводы 52
Глава 3. Построение интегрированной риус астраханского гпз 54
3.1. Интеграция асутп с системами асуп 54
3.1.1. Выбор программных и технических средств интеграции 56
3.1.2. Организация передачи технологических данных 59
3.1.3. Обеспечение безопасности и защита данных 67
3.1.4. Интеграция с экономическими системами 74
3.2. Проектирование и разработка базы технологических данных 77
3.2.1. Определение функций разрабатываемой системы 82
3.2.2. Моделирование процессов предметной области 83
3.2.3. Реализация базы данных в системе клиент/сервер 85
3.3. Выводы 87
Глава 4. Построение модели распределенной иус промышленного предприятия 89
4.1. Формализация основных элементов риус 90
4.2. Риус как система массового обслуживания 91
4.2.1. Определение риус и её отдельных структурных элементов 92
4.2.2. Определение критерия эффективности функционирования .93
4.2.3. Задача выбора оптимальной конфигурации риус 95
4.3. Алгоритм расчета среднего времени обработки заявок 97
4.4. Построение модели риус в соответствии с ома 104
4.4.1. Определение интерфейсов реализаций объектов 106
4.4.2. Отношения между объектами 108
4.4.3. Особенности физической реализации объектов 109
4.5. Выводы 113
Глава 5. Разработка метода синтеза оптимальных конфигураций 114
5.1. Реконфигурация как метод повышения эффективности 114
5.2. Методы решения задач выбора оптимальных конфигураций 115
5.3. Применение биологической теории видов к задаче реконфигурации иус 117
5.3.1. Общее описание генетического алгоритма холланда 117
5.3.2. Представление и кодирование конфигураций 121
5.3.3. Критерии останова и выживаемости 123
5.3.4. Основные операции генетического алгоритма 123
5.3.5. Формирование начальной популяции 124
5.3.6. Определение функции штрафов 125
5.4. Алгоритм синтеза оптимальных конфигураций 126
5.4.1. Исследование алгоритма синтеза конфигураций 127
5.4.2. Влияние параметров модели риус на работу алгоритма 127
5.4.3. Общий алгоритм формирования конфигурации 129
5.5. Программное обеспечение системы «сириус» 129
5.5.1. Архитектурные особенности разработанной системы 129
5.5.2. Формирование базы данных 136
5.5.3. Средства администрирования системы 139
5.5.4. Пример решения задачи реконфигурации риус 141
5.6. Выводы 143
Заключение 145
Список литературы
- Основные характеристики и особенности применяемых АСУТП
- Распределенные банки данных
- Организация передачи технологических данных
- Определение критерия эффективности функционирования
Введение к работе
В настоящее время управление крупным предприятием характеризуется широким внедрением сложных распределенных информационно — управляющих систем (РИУС). Современная РИУС должна решать как вопросы управления технологическим процессом (АСУТП), так и обеспечивать поддержку решения финансовых, управленческих и организационных задач (АСУП), причем взаимосвязи между подсистемами РИУС изменяются в условиях постоянного наращивания количества функций системы.
В результате уменьшается общая производительность РИУС, перегружен канал передачи данных. Необходимо определение наилучшей конфигурации и механизмов взаимодействия подсистем интегрированной РИУС.
Этот процесс происходит обычно на этапах проектирования и разработки системы. Однако опыт эксплуатации Астраханского газоперерабатывающего завода (АГПЗ) показывает необходимость управления конфигурацией и в процессе её промышленной эксплуатации. Необходимо учитывать специфические особенности производства, технологического процесса и уже действующих систем управления, а также целый ряд исторически сложившихся факторов. В частности, неоднородность АСУТП и АСУП привела к созданию большого количества методов построения РИУС, иногда полностью несовместимых друг с другом: как по стандартам передачи данных, так и использующих разнородные платформы (Windows и Unix).
Разработка методов синтеза таких конфигураций РИУС, для которых структура программно-технических средств будет оптимальна (или близка к оптимальной) заключается в эффективном масштабировании системы путем перераспределения на множестве используемых вычислительных ресурсов -серверах, персональных компьютерах, рабочих станциях, управляющих процессорах и т.д. При этом необходимо определить критерии, позволяющие оценить эффективность полученных конфигураций.
Этим вопросам посвящены работы многих отечественных и зарубежных ученых таких, как О.И. Авен, Л.Б. Богуславский, Н.Н. Турин, Я.А. Коган, А.И. Ляхов, СВ. Назаров, С. Виноски, В.И. Задорожный, В.П. Иванников, Дурнов П.А. и других.
Данное исследование посвящено объектно-ориентированным методам анализа и синтеза интегрированных РИУС. Представляя собой перспективную и сравнительно новую технологию, рассматриваемая в работе Object Management Architecture (ОМА), не имеет встроенных возможностей для синтеза оптимальных конфигураций, а также средств интеграции между подсистемами различных уровней предприятия.
Астраханский ГПЗ, основанный в 1981 году, является крупнейшим предприятием юга России по переработке природного газа. Предъявляя повышенные требования к РИУС, взрывопожароопасное производство с получением большого количества токсичных продуктов непрерывно развивается: проводится реконструкция, вводятся новые технологические линии. Для управления технологическим процессом используется I/A Series версии 6.2. фирмы Foxboro, которая в настоящее время обслуживает более 15 тыс. полевых устройств. А на уровне АСУП локально функционирует около двух десятков разнородных подсистем.
Таким образом, разработка методов построения, анализа и синтеза оптимальных конфигураций РИУС для такого крупного предприятия, как Астраханский ГПЗ, является актуальной задачей.
Целью диссертационной работы является разработка методов построения интегрированных информационно-управляющих систем распределенного типа, а также методов анализа и синтеза оптимальных конфигураций, программно-алгоритмическая реализация этих методов, на примере Астраханского ГПЗ.
В соответствии с этим в диссертации ставятся и решаются следующие основные задачи:
исследование современного состояния проблемы построения РИУС, анализ и классификация существующих методов, выбор наиболее подходящего метода;
формализация основных структурных элементов и построение математической модели РИУС с целью определения показателя эффективности системы;
разработка метода синтеза оптимальной конфигурации интегрированной РИУС в соответствии с выбранным показателем;
разработка структуры и интерфейсов взаимодействия, программно-алгоритмическая реализация метода синтеза оптимальных конфигураций интегрированных РИУС в виде кросс - платформенных программных модулей (Windows — Unix) на примере Астраханского ГПЗ;
обеспечение требуемого уровня безопасности информации.
Объектом исследования является программно-технический комплекс, объединяющий несколько территориально распределенных вычислительных узлов, функционирующих с целью скоординированного выполнения процесса сбора, обработки и хранения технологической, финансовой и организационной информации — интегрированная РИУС Астраханского газоперерабатывающего завода ООО «Астраханьгазпром». Предметом исследования являются конфигурации интегрированных РИУС, реализованных в соответствии с объектно-ориентированными методами построения информационных систем.
В работе использованы методы теории систем массового обслуживания, теории вероятностей, математическая статистика, теория множеств, исследования операций, идеи и методы теории генетических алгоритмов, методы обеспечения защиты информации (криптография с открытым ключом), а также методы разработки программного обеспечения в среде объектных брокеров (CORBA). Использованы CASE-методы проектирования и построения реляционных баз данных и методы создания кросс-платформенных приложений (Windows-UNIX).
8 Научная новизна исследования заключается в следующем:
на основе уточненной модели взаимодействия уровней РИУС предложен формализованный комплексный подход к построению информационной системы промышленного предприятия, как интегрированной объектной ИУС распределенного типа, решающей, как задачи управления сложным технологическим процессом, так и организационные и финансовые задачи управления производством с обеспечением требуемого уровня безопасности информации;
на основе теории массового обслуживания разработана математическая модель для определения количественных оценок производительности конфигураций интегрированных РИУС;
впервые предложено использовать генетические алгоритмы для синтеза оптимальной конфигурации РИУС, что позволило уменьшить уровень загрузки канала передачи данных в среднем на 20%, а среднее время обработки заявок в системе - в 2-4 раза.
разработана и реализована универсальная модель реляционной базы технологических данных для хранения информации о средствах физического уровня интегрированной РИУС (более 15 тыс. приборов, обслуживаемых АСУТП Астраханского ГПЗ, сгруппированных в 200 технологических блоков).
Практическая ценность работы заключается в следующем:
реализован набор кросс-платформенных модулей для интеграции систем управления технологическим процессом (АСУТП) и систем управления предприятием (АСУП), реализованы методы обеспечения безопасности информации на основе генерации электронной цифровой подписи (ЭЦП) технологических данных;
даны практические рекомендации по выбору параметров работы алгоритма синтеза оптимальных конфигураций РИУС;
9
суммарный экономический эффект от внедрения мероприятий соста-
* вил 410 тыс. руб.
Методика и программное обеспечение для анализа распределенных РИ-
УС и формирования рациональных конфигураций внедрены на Астраханском
газоперерабатывающем заводе ООО «Астраханьгазпром», что подтверждено
соответствующими актами о внедрении и удостоверениями на рационализатор-
ч ские предложения.
Результаты исследования используются в учебном процессе в Астрахан-
*' ском государственном техническом университете в курсе «Средства проекти-
рования и сопровождения Интернет / Интранет технологий» для специальности 22.02 «Автоматизированные системы обработки информации и управления», в учебном процессе в Учебном центре ООО «Астраханьгазпром» в курсе «Компьютерные управляющие системы в ремонтном производстве.
Основные результаты работы изложены на IV Международной научно-
практической конференции «Наука-Техника-Технологии», г. Находка, 2002 г.,
\ научно-технической конференции «Новые информационные технологии в ре-
гиональной инфраструктуре - НИТРИ», г. Астрахань, 1999 г., IV Международной научно-методической конференции «Новые информационные технологии в преподавании электротехнических дисциплин - НИТЭ», г. Астрахань, 1998 г.
Работа состоит из 5 глав, заключения, библиографического списка и при
ложений. В первой главе рассмотрены особенности процесса переработки сы-
v рья на АГПЗ, отличительные характеристики применяемых систем управления
технологическим процессом. Рассматриваются также особенности используе
мых подсистем уровня управления предприятием, их недостатки, выявляются
основные задачи и определяются методы их решения. Вторая глава работы по
священа построению формализованного комплексного подхода к моделирова
нию и анализу интегрированных РИУС, а также детальному исследованию уже
имеющихся методов. Третья глава посвящена комплексной интеграции отдель-
« ных подсистем предприятия в единую ИУС распределенного типа. Четвертая
>
Основные характеристики и особенности применяемых АСУТП
Автоматизированная система управления технологическим процессом (АСУТП) - серьезное приложение, не допускающее неквалифицированного вмешательства в свою работу. В случае газо-взрывопожароопасного производства с получением токсичных продуктов требования к надежности и стабильности работы АСУТП чрезвычайно высоки.
В настоящее время на Астраханском ГПЗ используется две системы управления технологическим процессом: ? АСУТП I/A Series фирмы Foxboro; ? АСУТП «АСТРА» (на производстве №3).
Система «АСТРА» в настоящее время является морально и физически устаревшей. На смену ей после реконструкции производства №3 придет I/A Series. Поэтому в рамках данной работы эта АСУТП рассматриваться не будет. Рассмотрим более подробно программно-технический комплекс (ПТК) системы управления АГПЗ на базе I/A Series фирмы Foxboro, а также его специфические особенности.
ПТК является представителем нового поколения средств для построения высокоэффективных систем управления непрерывными производственными процессами. Система отличается использованием новейших достижений технологии производств, современных архитектурных решений и стандартных ин терфейсов. Она состоит из независимо работающих узлов, работающих под управлением ОС UNIX [44], выполняющих функции по управлению процессом. Узел состоит из набора модулей, монтируемых в специальном корпусе, каждый модуль является независимым и предназначен для выполнения определенной задачи. Модули объединяются и могут комбинироваться в любых сочетаниях.
Технические средства ПТК при правильной эксплуатации отличаются большой надежностью. Восстановление работоспособности заключается в замене отказавшего модуля и не требует дополнительных действий по конфигурации комплекса: каждый модуль имеет символьный код, задаваемый уникальным литером. После установки модуль автоматически загружается программой и включается в работу системы. Для предотвращения отказов в работе системы применено несколько уровней защиты электронных изделий от влияния окружающей среды. Кроме того, используется резервирование в системе электропитания.
Управление технологическим процессом осуществляется с рабочих мест операторов (рабочих станций), которые состоят из: ? многоцветного монитора; ? предметной клавиатуры; ? трекбола (или мыши). Предусмотрена также возможность подключения к станции стандартной алфавитно-цифровой клавиатуры.
Рабочее место оператора-технолога содержит 2-3 рабочих станции. Благодаря такой организации оператор может вызвать одновременно 2-3 различных фрагмента мнемосхем, среди которых один может быть постоянным обзором обслуживаемой установки, а остальные - текущими рабочими фрагментами. Кроме того, в случае каких-либо помех, сбоев или временных отказов, оператор может вызвать на исправный экран фрагмент мнемосхемы соседнего экрана.
В системе применяются цветные дисплей с диагональю 21 дюйм, жидкокристаллические дисплеи, плазменные панели, которые обеспечивают возможность простого, быстрого и удобного управления объектом (открытие и закрытие клапанов, заслонок и т.д.), а также возможность удобного вызова различных фрагментов и использования «меню» и «подменю» путем простого Windows-подобного интерфейса. На рисунке 2 представлена одна из мнемо схем.
Предметная клавиатура оператора-технолога содержит обычно 5 панелей по 16 клавиш. Каждая клавиша включает светодиод для сигнализации нарушений на видеограмме, имя которой написано на клавише. На предметной клавиатуре перечислены все видеограммы, которые использует оператор на конкретном рабочем месте. Рабочие станции оператора-технолога комплектуются печатающими устройствами, предназначенными для регистрации нарушений технологического процесса и действий операторов, а также для распечатки технологических протоколов и режимных листов (Рис.3).
Распределенные банки данных
Процессы, выполняющиеся под управлением операционных систем узлов называются компонентами уровня обработки. Для их разработки в виде интероперабельных программных модулей необходима разумная декомпозиция.
Первым шагом в этом направлении был механизм "программных гнезд" (sockets), разработанный в университете Беркли. Основным достижением этой разработки было то, что с использованием единого механизма межпроцессных взаимодействий можно было интегрировать программные компоненты, произвольным образом распределенные в локальных или территориально распределенных сетях.
Однако транспортная природа такого механизма привела к тому, что представление передаваемых по сети данных стало машинно-зависимым. Следовательно, в каждом узле сети нужно уметь правильно преобразовывать представление данных, получаемых из любого другого узла. А это - серьезная техническая проблема.
Затем появился протокол вызова удаленных процедур (Remote Procedure Calls - RPC). В большинстве случаев взаимодействие программных компонентов является асимметричным и синхронным (Рис. 8). Практически всегда можно выделить клиента, которому требуется некоторая услуга, и сервер, который такую услугу способен оказать. Как правило, клиент не может продолжать свое выполнение, пока сервер не произведет требуемые от него действия. Налицо процедурное взаимодействие.
С точки зрения клиентской программы обращение к серверу ничем не отличается от вызова локальной процедуры. При реализации механизма вызова удаленных процедур на основании спецификации интерфейса процедуры на стороне клиента генерируется локальный представитель удаленной процедуры - STUB (в терминах RPC), а на стороне сервера - специализированный переходник - PROXY.
Очень полезной составляющей семейства протоколов RPC является протокол внешнего представления данных (External Data Representation - XDR). В этом протоколе специфицировано машинно-независимое представление данных, понимаемых механизмом RPC. При передаче параметров вызова удаленной процедуры и при получении от неё ответных параметров происходит двойное преобразование данных сначала из исходного машинно-зависимого формата в формат XDR, а затем из этого формата в машинно-зависимый целевой формат. В результате взаимодействующие программы избавлены от потребности знания специфики машинно-зависимых представлений данных.
Таким образом, протокол RPC подразумевает декомпозицию взаимодействующих программ на процедуры. Однако применение данного протокола снижает управляемость полученных архитектурных решений, т.к. отсутствуют единые стандарты для языков описания интерфейсов процедур и способов отображения этих описаний в языки программирования.
Дальнейшее развитие проектирование РИУС получило с появлением объектно-ориентированного программирования (ООП) [22]. Это, пожалуй, наилучшая из известных сегодня моделей программирования для создания сложных систем, удовлетворяющих требованиям управляемости, расширяемости и повторного использования кода. Методы объектно-ориентированного программирования изначально ориентировались на функционирование программы как на процесс обмена сообщениями между объектами. В централизованных системах обмен сообщениями - обычные вызовы процедур. В распределенных системах вызовы процедур приводят к обмену сообщениями. Таким образом, естественным является использование объектно-ориентированных методов в создании РИУС. Их распространение в разработке программного обеспечения делает декомпозицию программ на объекты более привлекательной (по сравнению с процедурной декомпозицией).
Принципы ООП базируется на следующих основных понятиях: ? абстракция - процесс идентификации признаков, выделяющих множества сходных объектов. Это основной метод, позволяющий работать со сложными системами, используя каждый раз уровень с необходимой детализацией: абстракция позволяет выделить классы и их иерархию;
инкапсуляция - возможность доступа к внутренним данным объекта только с использованием специально определенных для этого методов. Инкапсуляция - языковой механизм, позволяющий разделить интерфейс объекта от его реализации, обеспечивая, таким образом, абстрагирование от деталей реализации. Это позволяет независимо от кода, использующего объект, изменять содержание методов, сохраняя интерфейс, обеспечивая легкость модификации и управляемость;
наследование - механизм, с помощью которого объект может включать атрибуты и методы, определенные для другого объекта. Таким образом, возможна реализация повторного использования кода. Иногда возможно изменить реализацию наследуемого метода. Наследование образует иерархию классов. Разделяют наследование интерфейса и наследование реализации, единичное и множественное наследование и т.д.; полиморфизм - механизм обработки заявок, позволяющий обрабатывать одну и ту же заявку методом, зависящим от конкретного класса объекта. Заявка, направленная объекту как представителю некоторого базового класса, будет обработана в соответствии с реализацией метода в классе, который реально представляет данный объект.
Объектно-ориентированные методы в разработке РИУС имеют следующие преимущества по сравнению с использованием протоколов межпроцессорных коммуникаций:
гарантия обслуживания. Сервер инкапсулирует от клиента детали реализации предоставляемого сервиса, и клиент отделяется от технологических решений, используемых при реализации, и не зависит от них. Этим обеспечивается возможность построения РИУС, состоящих из узлов с различной аппаратной и программной архитектурой. Система, построенная в терминах объектов, может эволюционировать, путем замены и добавления необходимых сервисов, не затрагивая при этом остальные части, это ведет к снижению расходов па сопровождение и снижает риск капиталовложений;
компонентно-ориентированная разработка позволяет рассматривать действующую РИУС так, как она представляется её разработчику. Путем рассмотрения интерфейсов компонент, составляющих систему, можно легко понять принципы её функционирования, не вдаваясь в детали реализации. Путем повторного использования готовьк простых компонент можно создавать более сложные компоненты и сколь угодно сложные системы. Управление проектом упрощается, и может быть выполнено различными коллективами разработчиков;
Организация передачи технологических данных
Для интегрирования информации основного технологического и вспомогательного производства необходимо объединение разнородных подсистем в единую систему мониторинга и диспетчеризации технологических и производственных процессов.
Для создания единой информационной системы необходимо решить такие задачи, как: горизонтальная интеграция - обеспечение информационного взаимодействия между существующими автономными подсистема ми технологического уровня. Основными компонентами таких подсистем являются следующие:
- объединенное промышленными шинами контроллерное оборудование, для обеспечения информационного взаимодействия с которым используются драйверы или серверы ввода вывода;
- SCADA-приложения, уже обеспечивающие сбор технологических данных с контроллерного уровня, информационное взаимодействие с которыми можно обеспечить, используя механизмы COM (DCOM), DDE (NetDDE), частнофирменные протоколы, если обмен осуществляется между SCADA-приложениями одного производителя;
- стандартные настольные программы (Excel, CrystalReports, Word); обмен информацией с данными приложениями может осуществляться на базе OLEAutomation-объектов, SQL-запросов, DDE-протокола;
- таблицы баз данных; добавление, удаление, модификация текущих записей в таблицах возможна с помощью языка SQL-запросов (драйверы ODBC, OLE DB).
Данные, которые поступают с технологического уровня, отличаются тем, что быстро изменяются во времени (по сравнению с бизнес-параметрами) и потому объем их, получаемый в единицу времени, огромен. Из этого следует, что подсистема, интегрирующая технологические данные, должна обеспечивать скоростной сбор данных, сжатие данных при сохранении, поддержку каналов обмена по вышеуказанным протоколам. Причём интегрирующие подсистемы должны не только поддерживать обмен с технологическим уровнем, но и обеспечивать передачу технологических данных на уровень ERP-систем. Существенно то, что большинство данных реального времени мало полезно в бизнес приложениях. Поэтому на бизнес-уровень должны подниматься технологические данные, предварительно обработанные интеграционной подсистемой.
вертикальная интеграция. В общем случае целью вертикальной интеграции является передача технологических данных на уровень бизнес - приложений. В полном объеме на этом уровне решаются следующие задачи:
- обеспечение хранения оперативных данных (данных реального времени) в объеме, оптимальном для конкретного предприятия. Именно эти данные, назовем их realtime-данные, должны стать источником обрабатываемой информации, в том числе востребованной в бизнес - приложениях, системах управления ресурсами предприятия;
- формирование данных, отражающих динамику и последовательность технологического процесса производства продукта от сырья до товара. Назовем эти данные продуктовыми или product-данными. Программное обеспечение, ориентированное на решение таких задач, относится к классу MES (Manufacturing Executive Systems), или систем управления производством. В качестве входных данных в MES-системы поступают параметры сырья, выходными параметрами является полная характеристика (например, технологический паспорт) полученного товара(ров);
- формирование данных, отражающих структуру и состояние фондов (активов) предприятия, прежде всего, основных фондов, с помощью которых реализуется технологический процесс. Назовем их данными поддержки или maintenance-данными. Программное обеспечение, ориентированное на отслеживание и сопровождение основных фондов производства,
относится к классу ЕАМ (Enterprise Assets Management) систем. Следует заметить, что realtime-данные часто являются основой формирования количественных значений product- и maintenance-данных.
При решении проблем интеграции одним из описанных способов практически всегда перед разработчиками стоит проблема выбора программно-технических средств её решения.
Собственно описанию различных программных средств посвящены многие источники. Проблема выбора целевой СУБД, CASE средства проектирования, среды разработки приложений часто осложняется также вопросами организационного и финансового характера. Поэтому предлагается все используемые при разработке программные средства свести в таблицу.
Определение критерия эффективности функционирования
Вопросы интеграции систем управления технологическим процессом, систем управления производством и бухгалтерско-экономических систем подробно описаны во многих источниках. Из анализа подходов к управлению затратами на предприятии можно сделать вывод, что эта проблема достаточно широко представлена в современной экономической литературе: описаны виды затрат, источники их возникновения и методы управления применительно к каждому виду [73]. К сожалению, большинство описанных в литературе предложений носит лишь качественный характер и сводятся к советам по совершенствованию оперативного учета типа «более тщательный учет», «минимизация расходов», «сведение затрат к минимуму» и так далее. В специальной литера туре отсутствует комплексная методика управления затратами вообще, и тем более приемлемая для предприятий газовой промышленности. Отсутствие научно-методического обеспечения управления затратами нередко делает невозможным достижение запланированного результата производственно-хозяйственной деятельности, негативно сказывается на результатах деятельности предприятий газовой промышленности, в условиях переходного периода и является совершенно недопустимой в развитой экономике. Это обстоятельство обостряет проблему совершенствования управления производственными затратами, которая сейчас серьезно стоит перед предприятиями газовой промышленности в целом.
При современном уровне развития рыночных отношений неизмеримо усложняется ориентация предприятия, что ведет не просто к возрастанию роли управления, а к качественным изменениям во всей его структуре и методах. Появляется необходимость ускорения процесса интеграции традиционных методов учета, анализа, нормирования, планирования и контроля в единую систему получения, обработки и обобщения информации и развития на ее основе управленческих решений. Адекватная система управления производственными затратами должна быть ориентирована не только на достижение оперативных (текущих) целей в виде получения прибыли того или иного размера, но и на глобальные стратегические цели: выживание предприятия, его экологический нейтралитет, сохранение рабочих мест, то есть на социальные факторы. Приоритетным становится не узкое, конкретное, ортодоксальное мышление управляющих делами, а системное, комплексное решение проблем.
Решение в целом проблем управления производственными затратами, является, в соответствии с положениями системного подхода, одной из подцелей, достижение которой позволит приблизиться к глобальной цели повышение эффективности предприятий газовой промышленности. Для достижения указанной подцели должны быть решены основные методологические и методические вопросы, связанные с экономической сущностью и группировкой затрат: спе цифическими особенностями формирования затрат в газовой промышленности; совершенствованием как отдельных функций управления затратами в целом, так и управления конкретными группами затрат: возможностями рационализации величины совокупных затрат за счет эффективного управления. В частности, методика калькулирования себестоимости товарной продукции Астраханского ГПЗ в виде укрупненных блоков изображена на Рис. 22.
Одним из методов решения описанных выше задач является интеграция АСУТП, АСУП и финансовых систем в единую РИУС промышленного предприятия. В рамках данной работы была разработана АИС «Калькуляция» [76].
Основное назначение разработанной АИС - расчет себестоимости товарной продукции Астраханского ГПЗ и полуфабрикатов. Программа существенно сократила трудоемкость работы сотрудников планово-экономического отдела завода, повысила эффективность путем анализа расходов и затрат на производство.
Главное окно АИС «Калькуляция». Архивные данные о технологическом процессе используются при построении материального баланса технологических установок. Далее полученные результаты разносятся по затратам соответствующих структурных подразделений, и в конечном итоге, собирается общая себестоимость товарной продукции и полуфабрикатов Астраханского ГПЗ. Результат работы программы используется в дальнейших расчетах администрацией ООО «АГП» и ОАО «Газпром» (г. Москва).
Процесс разработки базы данных любого приложения архитектуры клиент-сервер условно можно разделить на определенные этапы. Разработчик выполняет эти этапы, однако для того, чтобы добиться желаемого результата, нужно следовать им неукоснительно, какое бы приложение не разрабатывалось.
Процесс создания приложений баз данных архитектуры клиент-сервер можно разделить на следующие пять этапов: определение назначения и круга задач приложения; проектирование функциональности приложения и процессов, необходимых для реализации этой функциональности; воплощение проекта в реальное приложение путем создания необходимых программных объектов и объектов баз данных; обычно этот этап называют этапом разработки или этапом программирования. Однако в настоящее время - время повсеместного распространения средств визуального проектирования, программирование является лишь составной частью этапа разработки. Таким образом "разработка" - это программирование, визуальное проектирование или генерация приложения, в зависимости от используемых средств разработки; тестирование приложения на предмет соответствия его назначению и правильного функционирования; настройка и установка приложения;
Если быть менее многословным, то можно кратко обозначить суть каждого из этих этапов следующим образом: ? Анализ; ? Проектирование; ? Разработка; ? Тестирование; ? Совершенствование.
Процесс проектирования базы данных архитектуры клиент-сервер далеко выходит за рамки физического создания базы данных. Нужно разработать концептуальную модель, создать диаграммы "сущность-связь", смоделировать логические структуры данных. Постепенно продвигаясь от частного к общему, начиная от моделирования предметной области и кончая определением столб цов конкретных таблиц, можно вникнуть в мельчайшие детали работы будущего приложения. При этом необходимо будет пройти через следующие стадии (схема упрощена с пяти до трех стадий): ? описание предметной области и процессов, в ней протекающих, реализация которых необходима для выполнения основных функций приложения; ? создание диаграмм, показывающих связи между ними; ? создание логической структуры базы данных, реализующей эти связи и процессы.
