Программные продукты и системы

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

В свою очередь, в классе АСУ принято выделять АСУ технологическими процессами (АСУ ТП) (SCADA), АСУ производством (АСУ П) (MES), АСУ предприятиями (АСУП) (ERP).

SCADA-системы (Supervisory Control and Data Acquisition, диспетчерское управление и сбор данных) предназначены для управления удаленными техническими объектами в режиме реального времени. Данные SCАDA-систем собираются в опе- ративных БД предприятия и анализируются в процессе управления производством, в том числе с использованием MES-систем (Manufacturing Execution System, система управления производственными процессами).

MES-система  позволяет решать задачи координации, синхронизации, анализа и оптимизации процессов выпуска продукции [1, 2]. MES-системы получают задания на планирование процессов от ERP-систем (Enterprise Resource Planning, системы управления ресурсами предприятия).

ERP-системы предназначены для управления всеми видами ресурсов предприятия. Наиболее распространенными среди таких систем являются BAAN (компания BAAN), R/3 (SAP), Oracle Applications (Oracle), SAS System (SAS Institute), Галактика (корпорация «Галактика»), 1C: Управление производственным предприятием («1С»), М-3 (К-Т-С). Функции ERP-систем могут быть расширены за счет интеграции с другими системами управления предприятием, например, SCM – планирование цепочек поставок, SSM – продажи и управление сервисом.

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

На основании таблицы можно сделать следующие выводы:

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

–      некоторые задачи решаются с применением данных систем лишь частично, например, планирование работы может быть выполнено с использова- нием MES-системы лишь для производственных работ;

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

Таблица 1

Реализация функций управления проектами в автоматизированных системах предприятия

Table 1

Projects management functions implementation in enterprise automated systems

ИСУП (PMS – Project Management System) предназначены для планирования и мониторинга проектов различных типов.

Существует множество программных средств PMS, ориентированных как на решение отдельных задач проектного управления, таких как планирование бюджета, контроль выполнения плана и т.д., так и на весь жизненный цикл проекта. Стабильно на российском рынке присутствуют около 10 систем. Среди лидеров такие общепризнанные решения, как Microsoft Enterprise Project Management Solution (EPM), Oracle Primavera, Deltek Open Plan. Есть и отечественные разработки, в том числе Spider Project от компании «Технологии управления Спайдер», Project Kaiser компании Triniforce. Сравнительный анализ данных систем приведен в работе [3].

Для решения аналитических задач проектного управления возможно использование систем OLAP (Online Analytical Processing, аналитическая обработка в реальном времени) и BI (Business Intelligence, бизнес-аналитика), однако подобные си- стемы пока не получили широкого распростра- нения на отечественных промышленных предприятиях, хотя примеры их использования существуют [4].

В последнее время большое внимание уделяется интеграции систем АСУ и САПР. Это связано с тем, что в числе наиболее важных исходных данных для MES-систем технологические процессы производства [5, 6].

В соответствии с ГОСТ 23501.101-87 «Системы автоматизированного проектирования. Основные положения», САПР – это организационно-техническая система, входящая в структуру проектной организации и осуществляющая проектирование при помощи комплекса средств автоматизированного проектирования.

В зависимости от разных признаков классификации можно выделить несколько классов систем САПР [7]. Наиболее часто применяемый признак целевого назначения данных систем разделяет их по аспектам проектирования на CAD (двумерное и/или трехмерное геометрическое проектирование, создание конструкторской и/или технологической документации), CAE (системы автоматизации инженерных расчетов, анализа, симуляции физических процессов, динамического моделирования, проверки и оптимизации изделий), CAM (системы автоматизации программирования и управления оборудованием с ЧПУ или ГАПС) и CAPP (системы автоматизации планирования технологических процессов).

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

Примерами российских и западных PDM-сис­тем являются 1С: Интегратор, 1С: PDM Управление инженерными данными, Lotsia PDM Plus, T-FLEX DOCs, TechnologiCS, Windchill, Smar­Team, IDPM CADISON PDM, SolidWorks Enterprise PDM.

В последнее время в сфере промышленной автоматизации наблюдается переход на интегрированные платформы PLM (Product Lifecycle Management, управление жизненным циклом продукции). При функционировании PLM опирается на использование совокупности рассмотренных выше информационных систем. Лидерами на рынке PLM являются Teamcenter (Siemens PLM Software), Agile PLM (Oracle), решения от Dassault Systemes. Данные решения являются дорогостоящими, поэтому область их внедрения ограничивается на сегодняшний день крупными предприятиями и концернами.

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

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

–      постоянное развитие информационных систем в направлении расширения функциональных возможностей и увеличения производительности;

–      дублирование ряда функций или наличие нескольких их реализаций;

–      избыточность хранимой информации в связи с ее дублированием в отдельных системах;

–      использование различных представлений одних и тех же данных и необходимость их согласованного изменения.

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

Реляционная модель данных производственного проекта

Для управления сложным производственным проектом необходимо иметь полный объем плановой и оперативной информации, характеризующей данный проект, а именно сведения о работах, про- цессах, целях, событиях, мероприятиях, а также о результатах, получаемых на каждой стадии проекта [8].

Данная информация хранится в БД автоматизированной информационной системы, поэтому при проектировании ее структуры необходимо принимать во внимание тип СУБД, используемой на предприятии. В зависимости от используемой модели данных выделяют пять видов СУБД: иерархические, сетевые, реляционные, объектные и объектно-реляционные. Несмотря на широкие возможности СУБД последних двух типов, самыми используемыми на отечественных предприятиях являются реляционные СУБД, такие как Microsoft SQL Server, Oracle Database, Teradata Database, DB2 и др.

Разработка структуры реляционной БД включает построение логической и физической мо- делей. Логическая модель отражает понятия предметной области и их связи между собой. В ходе проведенного анализа было выделено 11 основных сущностей, описание которых приведено в таблице 2, а графическое представление дано на рисунке 1.

Как видно из рисунка 1, между многими сущностями существует связь «многие-ко-многим», то есть одному элементу первой сущности соответствует множество элементов второй и наоборот. Данный вид связи является естественным для производственных проектов, однако ее нельзя отра- зить в БД. В связи с этим физическая модель реляционной БД (рис. 2) отличается от логической.

Таблица 2

Сущности логической модели данных

Table 2

Data logical model entities

Как видно из рисунка 2, для организации связи «многие-ко-многим» дополнительно создаются связующие таблицы, такие как REAL_EVENT_ MER, AIM_EVENT_MEROPRIYT, AIM_PRO­CESS, PROC_WORK, WORK_PERSON, WORK_ EQUIPMENT, PERSON_MEROPR, EQUIPMENT_ MEROPR. Кроме этого, создаются еще две справочные таблицы, отражающие тип события и тип работы: EVENT_TYPE и WORK_TYPE.

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

Объектная модель данных производственного проекта

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

Объектная модель данных производственного процесса, ориентированная на создание програм- мных средств на языке Java, приведена на рисун- ке 3. Данная модель представляет собой диаграмму классов в соответствии с методологией UML.

На диаграмме видим, что между классами существуют четыре вида отношений.

Отношения обобщения (заканчиваются стрелкой) отражают факт наследования классов Real_ event, Indicator_Value и Result от родительских и их расширения от него. Расширение реализуется через ключевое слово «extends». Такая организация позволила использовать объекты класса-потомка как отдельно, так и включая в объекты класса-предка.

Агрегатные отношения (заканчиваются незакрашенным ромбом) реализуют логику включения одних классов в виде части целого в другой класс. Например, в классе Project (проект) должны быть установлены цели конкретного проекта, соответственно он должен включать в себя объекты класса Aim (цель). Аналогично связаны классы Aim–Process (цель–процесс), Process–Work (процесс–работа), Work–Result (работа–результат). Такое построение модели наглядно отражает логику опи- сания проекта и гарантирует включение всех его необходимых элементов. Отношение Work–Result (работа–результат), изображенное на рисунке с закрашенным ромбом, является частным случаем агрегации – композицией. Суть данного отношения заключается в большей степени зависимости составных частей и целого, когда каждый результат выполнения тех или иных задач может быть связан только с конкретной работой.

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

Из рисунка 3 видно, что количество классов в данном случае меньше количества таблиц в БД, при этом пять из них – это классы-наследники, работа с которыми облегчается за счет наличия в объектном программировании механизма наследования [9]. Таким образом, применение объектного подхода к представлению информации о производственном проекте дает возможность сократить ее объем, что, в свою очередь, позволяет повысить производительность алгоритмов обработки.

Пример преобразования данных из объектной модели в реляционную

Существует несколько технологий для разработки схемы обмена данными (маппинга) между объектами прикладного решения и таблицами реляционной БД. На основании проведенного анализа для организации преобразования объектов Java в реляционную структуру была выбрана технология JPA (Java Persistence API). Пример реализации данной технологии был выполнен с использованием библиотеки Hibernate JPA [10].

Hibernate – это библиотека, разработанная для языка программирования Java, которая обеспечивает отображение объектов в структуры реляционных данных. Использование данной библиотеки существенно сокращает время проектирования приложений, ориентированных на работу с БД, позволяя легко организовывать связь между клас- сами Java и таблицами БД и типами данных Java и Oracle. Кроме этого, Hibernate обладает средствами автоматического создания запросов и извлечения данных [11].

Визуально процесс взаимодействия Java и реляционных данных посредством Hibernate можно представить в виде, показанном на рисунке 4.

Полный набор файлов приложения для полноценного функционирования системы:

–      description.jar – пакет классов, определяющий основные рабочие классы приложения и методы доступа к их атрибутам;

–      core.jar – набор классов, реализующих бизнес-логику приложения;

–      Hibernate Library.jar – подключаемая библиотека, содержащая набор пакетов и классов для реализации технологии Object-Relational Mapping;

–      condb.jar – набор файлов, отвечающих за ассоциирование java-классов приложения с таблицами БД Oracle;

–      JRE System Library.jar – пакет, включающий в себя стандартный набор библиотек, необходимых для работы приложения;

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

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

Пунктирными линиями на рисунке изображен процесс импортирования классов одного пакета в другой, сплошными – обращение к методам классов.

В классах пакета description методы получения и внесения данных по каждому атрибуту класса реализованы в соответствии с логикой объектно-ориентированного программирования и отвечают их прямому назначению. Методы set устанавливают значения переменных классов, методы get получают значения и предоставляют доступ к ним из других классов, обеспечивая возможность взаимосвязанной работы модулей приложения.

Двусторонней стрелкой на рисунке отражена связь приложения с БД через драйвер JDBC. Линии, завершающиеся точками, отражают связь mapping-файлов пакета condb.jar с объектами приложения.

Организация связи с БД в приложении осуществляется в соответствии с технологией Object-Relational Mapping (ORM), которая предназначена для преобразования данных из реляционных СУБД в привычную для языка Java объектную форму. Реализует данную технологию механизм, описывае- мый подключаемой библиотекой Hibernate Library.jar [Хемранж].

Работа с механизмом Hibernate включает в себя следующие этапы.

· Установка параметров соединения с БД. За соединение с БД системы отвечает конфигурационный файл hibernate.cfg.xml (см. http://www.swsys. ru/uploaded/image/2015-4-dop/5.jpg), который содержит в себе необходимые сведения и параметры для подключения к БД и описывает связанные с базой классы. Для организации соединения используется технология Java DataBase Connectivity (JDBC). Необходимый драйвер загружается из подключаемой библиотеки ojdbc7.jar.

· Инициализации механизма Hibernate.

В связи с тем, что работа с БД осуществляется с помощью транзакций в пределах сессии, необходимо создать фабрику сессий (см. http://www. swsys.ru/uploaded/image/2015-4-dop/6.jpg).

Механизм активируется с помощью служебного класса HibernateUtil.java (см. http://www. swsys.ru/uploaded/image/2015-4-dop/7.jpg). При загрузке данного класса создается специальный объект sessionFactory, который считывает данные из файла hibernate.cfg.xml и осуществляет подключение к БД.

· Отображение классов на таблицы.

· Описание отношений между классами.

Соотношения классов приложения с таблицами БД, а также отношения между классами описываются в файлах вида name_class.hbm.xml. Пример отображения класса на таблицы БД представлен на рисунке 6.

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

Затем для организации непосредственно работы с БД создаются базовые классы DAO, которые содержат методы работы с Hibernate. Кроме этого, здесь описывается ряд аннотаций, перечень которых приведен в таблице 3.

Таблица 3

Перечень аннотаций

Table 3

Annotation list

Использование данных классов и аннотаций в них обеспечивает быструю и простую работу с БД.

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

Эффективная автоматизация управления сложными производственными проектами возможна только при наличии достоверной, актуальной и непротиворечивой информации. Задача поддержания ее в таком состоянии осложняется наличием нескольких представлений: реляционного – для хранения в БД, объектного – для обработки. В статье предложены реляционная и объектная модели данных по проектам, которые могут использоваться в автоматизированных информационных системах промышленных предприятий для решения задач проектного управления. Пример преобразования данных из объектов Java в таблицы СУБД Oracle, выполненный с применением библиотеки Hiber­nate, служит иллюстрацией преобразования моделей данных различных типов. Он может быть взят за основу при разработке модулей обмена данными между реляционными БД и прикладными программами, созданными с помощью объектных языков программирования.

Литература

1.     Загидуллин Р.Р. Управление машиностроительным производством с помощью систем MES, APS, ERP. Старый Оскол: ТНТ, 2011. 372 с.

2.     Фролов Е.Б., Загидуллин Р.Р. MES-системы, как они есть, или эволюция систем планирования производства // Металлообрабатывающее оборудование. 2008. № 10 (55). С. 31–37.

3.     Стоянова О.В. Оценка соответствия существующих информационных систем управления проектами особенностям проектного управления в наноиндустрии // Программные продукты и системы. 2013. № 3. С. 193–199.

4.     Палюх Б.В., Бурдо Г.Б. Метод интеллектуальной оценки решений при проектировании технологии в многономенклатурных производствах // Вестн. Тамбовского гос. технич. ун-та. 2011. Т. 17. № 2. С. 342–350.

5.     Бурдо Г.Б., Стоянова О.В. Автоматизированная система управления процессами создания наукоемких машиностроительных изделий // Программные продукты и системы. 2014. № 2. С. 164–170.

6.     Гришина Т.Г. Моделирование и оптимизация циклов выработки решений при управлении автоматизированным производством // Инженерный вестник Дона. 2012. № 3 (21). С. 390–394.

7.     Андреев В.В., Тесленко Е.В., Хранилов В.П. Динамическая модель управления конструкторско-технологическим взаимодействием в САПР // Науч.-технич. вестн. Поволжья. 2013. № 3. С. 64–67.

8.     Туровец О.Г., Родионов В.Б., Бухалков М.И. Организация производства и управление предприятием. М.: Инфра-М, 2013. 3-e изд. 506 с.

9.     Хабибуллин И.Ш. Java 7: Наиболее полное руковод- ство. СПб: БХВ-Петербург, 2012. 768 с.

10.  Хемраджани А. Гибкая разработка приложений на Java с помощью Spring, Hibernate и Eclipse; [пер. с англ. В. Коваленко]. М.: Вильямс, 2008. 352 с.

11.  Браусоу К. Hibernate упрощает преобразование наследования. IBM developerWorks. URL: http://www.ibm.com/ developerworks/ru/library/j-hibernate/ (дата обращения: 28.09.2015).