ISSN 0236-235X (P)
ISSN 2311-2735 (E)

Journal influence

Higher Attestation Commission (VAK) - К1 quartile
Russian Science Citation Index (RSCI)

Bookmark

Next issue

4
Publication date:
09 December 2024

Complex industrial projects data representation models in automated information systems of industrial institutions

Date of submission article: 30.09.2015
UDC: 004.043
The article was published in issue no. № 4, 2015 [ pp. 210-218 ]
Abstract:A great number of various information systems is used during the process of complex industrial projects management. Each of them solves independent projects data processing tasks. Thus, as for new production setup projects, product information is distributed between computer-aided design systems (CAD) and automated process control systems (APCS), information about necessary resources is distributed between APCS, management information system (MIS), automated project management system (APMS), etc. Project data exchange between stated systems is complicated by using different hardware and software, data formats, data representation models. The article considers object and relation data representation models of complex industrial projects. The first type of model is used as base of data processing using object-oriented programming languages. The relation model is necessary for data storage in industrial institutions databases. This situation is caused by information technologies evolution, i.e. data processing a pplication development using object-oriented programming and relation DBMS dominance. Different units of information systems use different data models. This requires decision-making on transforming data representations. There is no one-stop solution for the stated task for now. The paper considers the example of such transformation for an object model in Java and for a relation model in DBMS Oracle.
Аннотация:В процессе управления сложными производственными проектами на промышленных предприятиях используется множество разнообразных информационных систем, каждая из которых решает отдельные задачи обработки проектных данных. Так, для проектов по организации производства новых образцов продукции сведения об изделии распределены между САПР и АСУ производством, информация о необходимых производству ресурсах – между АСУ производством, АСУ предприятием, АСУ проектами и т.д. Обмен проектными данными между указанными системами осложняется отличиями используемых ими программно-аппаратных платформ, форматов данных, моделей представления этих данных. В статье рассмотрены два вида моделей представления данных сложных производственных проектов: объектная и реляционная. Модель первого вида используется в качестве основы обработки данных с помощью объектных языков программирования, реляционная модель необходима для организации хранения данных в БД промышленных предприятий. Данный выбор обусловлен современными тенденциями развития информационных технологий в сфере автоматизации промышленных предприятий: использование объектного программирования для реализации приложений по обработке данных и доминирование реляционных СУБД. Использование различных моделей данных в отдельных компонентах информационной системы требует разработки решений по обеспечению преобразования данных из одного представления в другое. Указанная задача не имеет на сегодняшний день универсального решения. В статье рассмотрен пример такого преобразования для объектной модели, реализованной в Java, и реляционной модели для СУБД Oracle.
Authors: Dli M.I. (midli@mail.ru) - (Smolensk Branch of the Moscow Power Engineering Institute, Smolensk, Russia, Ph.D, Stoyanova O.V. (ovstoyanova@list.ru) - Smolensk Branch of the Moscow Power Engineering Institute, Smolensk, Russia, Ph.D, Belozersky А.Yu. (ovstoyanova@ list.ru) - D. Mendeleev University of Chemical Technology of Russian Federation (Professor), Moscow, Russia, Ph.D
Keywords: automated information system, project management, project data model, industrial project
Page views: 14770
Print version
Full issue in PDF (9.58Mb)
Download the cover in PDF (1.29Мб)

Font size:       Font:

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

В свою очередь, в классе АСУ принято выделять АСУ технологическими процессами (АСУ ТП) (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

Функция

Класс систем, подсистемы

Планирование работ проекта

MES, Оперативное/Детальное планирование производства (ODS)

Планирование и контроль материальных ресурсов проекта

MES, Контроль состояния и распределение производственных ресурсов (RAS)

MES, Управление производственными фондами (техобслуживание) (MM)

Распределение работ между исполнителями

MES, Управление персоналом (LM)

ERP, Управление человеческими ресурсами (HR)

Планирование организационной структуры управления проектом

ERP, Управление человеческими ресурсами (HR)

Планирование и контроль исполнения бюджета

ERP, Управление финансами (FM)

Контроль качества продукции и процессов

MES, Управление качеством продукции (QM)

Анализ рисков

Анализ сценариев проекта

ИСУП (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

Аннотация

Описание

@Entity

Сообщает Hibernate о взаимодействии класса с Hibernate

@Table

Явно указывает название таблицы, к которой обращаются

@Column

Указывает название атрибута таблицы, с которым осуществляется работа

@Id 

Указывает первичный ключ Primary-ключа

@Gene- rated-Value

Обеспечивает автоматическую генерацию при добавлении нового объекта в базу

@Many- ToOne

Используется при работе с полем в случае, когда таблица связана с другой типом связи «один-ко-многим»

@Join- Column

Имя поля таблицы, по которому осуществляется связь «один-ко-многим» с другой таблицей

@Many- ToMany

Используется при работе с полем в случае, когда таблица связана с другой типом связи «многие-ко-многим»

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

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

Эффективная автоматизация управления сложными производственными проектами возможна только при наличии достоверной, актуальной и непротиворечивой информации. Задача поддержания ее в таком состоянии осложняется наличием нескольких представлений: реляционного – для хранения в БД, объектного – для обработки. В статье предложены реляционная и объектная модели данных по проектам, которые могут использоваться в автоматизированных информационных системах промышленных предприятий для решения задач проектного управления. Пример преобразования данных из объектов 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).


Permanent link:
http://swsys.ru/index.php?page=article&id=4092&lang=&lang=en
Print version
Full issue in PDF (9.58Mb)
Download the cover in PDF (1.29Мб)
The article was published in issue no. № 4, 2015 [ pp. 210-218 ]

Perhaps, you might be interested in the following articles of similar topics: