CC BY
35
Соловейчик К.А.
РАЗРАБОТКА СИСТЕМЫ ИНТЕГРАЦИИ ПОДСИСТЕМЫ ДИСПЕТЧИРОВАНИЯ СО СТАНОЧНЫМ ЦЕХОВЫМ ОБОРУДОВАНИЕМ МАШИНОСТРОИТЕЛЬНОГО ПРЕДПРИЯТИЯ
Аннотация. В результате разработки алгоритма модуля диспетчироеания производства на машиностроительном предприятии с целью роста экономически эффективной глубины передела впервые был создан алгоритм диспетчироеания подразделения машиностроительного предприятия с возможностью интеграции со станочным цеховым оборудованием на базе программных продуктов, разработанных на платформе «1С:Предприятие 8» для отслеживания обеспеченности производственного процесса. Алгоритм отличается высокой степенью скорости расчетов на большом объеме данных.
Ключевые слова. Глубина передела, процессы управления, машиностроение, управление промышленным производством.
Soloveichik К.А.
INTEGRATION OF THE DISPATCHED SUBSYSTEM WITH EQUIPMENT (EXAMPLE OF MACHINE-BUILDING ENTERPRISE)
Abstract. As a result of the development of the algorithm of the production dispatching module at the machine-building enterprise with the purpose of increasing the economically effective depth of the redistribution, the algorithm for dispatching a subdivision of a machine-building enterprise with the possibility of integration with machine tool equipment on the basis of software products developed on the platform "1С: Enterprise 8" was first developed to track the availability of the production process. The algorithm is characterized by a high degree of speed calculations on a large amount of data.
Keywords. Process stage quotient, depth redistribution, management processes, mechanical engineering, industrial production management.
В продолжение цикла статей [1, 2] по методологическим вопросам оптимизации производственного планирования, автоматизации и компьютеризации процессов управления производством, вызванных необходимостью роста глубины передела промышленной продукции [6], данная статья рассматривает вопросы экономики и управления машиностроительного производства в части диспетчеризации. Также при подготовке данной статьи нами были использованы уже упоминавшиеся в предыдущих публикациях источники [4, 7, 8, 9].
В рамках НИОКР осуществлена разработка программного продукта, обеспечивающего автоматизацию процесса посменного планирования, автоматизированное поступление оперативной информа-
ГРНТИ 55.01.75 О Соловейчик К. А., 2017
Кирилл Александрович Соловейчик - доктор экономических наук, доцент, заведующий кафедрой процессов управления наукоемкими производствами Санкт-Петербургского политехнического университета Петра Великого, вице-президент Торгово-промышленной палаты Санкт-Петербурга, президент ОАО «ЛЕНПОЛИГРАФМАШ». Контактные данные для связи с автором: 197376, Санкт-Петербург, наб. реки Карповки, 5 (Russia, St. Petersburg, Karpovki emb., 5). Тел.: 8 (812) 234-85-95. Статья поступила в редакцию 12.05.2017 г.
ции о состоянии работы станочного оборудования машиностроительного предприятия. В результате исследования впервые были созданы запрограммированные в среде «1С:Предприятие» алгоритмы многокритериального планирования. Использование запрограммированных алгоритмов планирования и диспетчирования позволяет в разы (в зависимости от структуры производственного заказа) сократить время межоперационного пролеживания запасов, что приводит к сокращению производственного цикла, сроков поставки, затрат на хранение товарно-материальных ценностей.
Использование спроектированных автоматизированных средств интеграции позволяет значительно сократить время на сбор и агрегирование данных со станочного оборудования, повысить информированность об уровне загрузки оборудования и рабочих на производственных участках, сократить трудозатраты на дублирование ввода информации в информационные системы и на сбор исходных данных для выполнения учетной системой машиностроительного предприятия своих регламентных функций. Нами проведена разработка алгоритма, позволяющего обеспечить взаимосвязь производственного станочного оборудования с подсистемой диспетчеризации.
В разрабатываемом подмодуле предполагалось наличие следующего набора возможностей: сбор данных о состоянии оборудования в режиме реального времени; связывание поступающих сигналов с оборудования с данными, хранящимися в подсистеме диспетчирования; хранение собранных записей о событиях, поступивших с оборудования; обработка данных и представление аналитической информации по считанным данным (состояние станка, длительность выполнения работ и простоев, выполненная операция, рабочий) в виде отчетов с возможностью отборов и сортировки данных.
Для обеспечения считывания сигналов со станочного оборудования предполагалось задействовать следующие технические устройства: блок мониторинга СМПО, расположенный непосредственно на станке с ЧПУ; сканер штрих-кодов, подключенный к блоку мониторинга. Взаимодействие между подсистемой диспетчирования и устройствами предполагается организовать следующим образом: подсистема диспетчеризации выполняется на серверном оборудовании, блок мониторинга связан с серверным оборудованием при помощи локальной вычислительной сети. Сканер штрих-кодов подключается к блоку мониторинга при помощи кабеля, позволяющего передавать данные по протоколу 135-232.
Блок мониторинга связан со станком при помощи сигнальных кабелей, по которым передается информация о том, в каком состоянии находится станок в данный момент времени: в состоянии работы, простоя, либо в выключенном состоянии. На блоке мониторинга предусмотрено 6 кнопок для передачи уточняющей информации о состоянии работы оборудования. В подсистему диспетчеризации может быть передана информация о коде кнопки, нажатой на блоке мониторинга. Сигналы, формируемые оборудованием (станком, сканером штрих-кодов, блоком мониторинга), предлагают возможности для передачи данных в подсистему диспетчеризации. В предлагаемом алгоритме подмодуля интеграции предлагается использовать сигналы следующим образом:
• сигналы со сканера штрих-кодов предлагается использовать для передачи данных об отсканированном штрих-коде, размещенном на пропуске сотрудника, и штрих-коде операции в маршрутной карте. Для распознавания сотрудника по штрих-коду в подсистеме диспетчеризации предлагается добавить возможность печати штрих-кода сотрудника (рабочего) и прикреплять распечатанный штрих-код при предоставлении пропуска пришедшему на работу сотруднику;
• сигналы о состоянии оборудования предлагается использовать в моменты смены состояния оборудования для фиксации времени начала и окончания выполнения работ либо простоев. В случае если со станка не поступают сигналы о его состоянии, можно считать такой станок выключенным;
• в момент нажатия кнопки код кнопки может использоваться для получения кода причины простоя. Для этого предлагается назначить каждой кнопке блока мониторинга соответствующую причину простоя и разработать в подмодуле интеграции механизм сопоставления кода кнопки и причины простоя для каждой единицы оборудования.
С целью последующего использования поступающих данных, они, после поступления в подсистему диспетчирования, должны быть преобразованы в удобную для использования и анализа форму. Для преобразования данных об операции, рабочем, причине простоя предлагается использовать таблицы сопоставления исходных данных в составе подсистемы диспетчирования. Моменты изменения состояния предлагается преобразовывать в моменты начала/завершения выполнения работ и простоев оборудования в зависимости от состояния, в котором находилось оборудования до возникновения события смены состояния. В упрощенном варианте предполагается следующая последовательность получения информации в программе (рис. 1):
Инициация получения состояния оборудования
Зафиксировать завершение операции предыдущим рабочим
1
Зафиксировать окончание смены предыдущего рабочего
1 г
Зафиксировать начало смены следующего рабочего
1
Зафиксировать I следующи гачало операции м рабочим
Зафиксировать окончание смены предыдущего рабочего
1 г
Зафиксировал следующе! начало смены о рабочего
Зафиксировать причину простоя с момента нажатия на кнопку
Завершить операцию, которая выполнялась до начала простоя
1 г
Записать ш о следующе формацию ;й операции
Зафиксировать начало следующей операции на момент начала выполнения текущей работы
I
Сообщить, что данная операция выполняется
I
1. При выходе на смену рабочий сканирует штрих-код на собственном пропуске. Подмодуль интеграции должен передать в подсистему диспетчирования информацию о том, что завершена смена предыдущего рабочего и начата смена нового рабочего.
2. Рабочий запускает оборудование для обработки детали на операции. Подсистема диспетчеризации должна получить сигнал об окончании простоя и начале выполнения работ.
3. После начала операции рабочий сканирует по маршрутной карте штрих-код выполняемой в данный момент операции. Подмодуль интеграции должен связать начало операции с моментом начала текущей работы на станке. Таким образом, момент начала выполнения операции соответствует не моменту сканирования этой операции, а моменту начала текущих работ.
4. Станок завершает обработку детали на данной операции. Подмодуль должен передать информацию об окончании выполнения работ и начале простоя оборудования.
5. Рабочий нажимает одну из 6 кнопок на блоке мониторинга для того, чтобы зафиксировать причину простоя станка. Подмодуль интеграции должен связать начало простоя по определенной причине с моментом начала текущего простоя на станке. Таким образом, момент начала простоя по данной причине соответствует не моменту нажатия на кнопку на блоке мониторинга, а моменту начала текущего простоя.
6. Рабочий запускает оборудование для обработки детали на следующей операции. Подсистема диспетчеризации должна получить сигнал об окончании простоя и начале выполнения работ по ранее отсканированной операции.
7. После начала операции рабочий сканирует по маршрутной карте штрих-код выполняемой в данный момент операции. Подмодуль интеграции должен связать начало операции с моментом начала текущей работы на станке. Таким образом, на момент начала текущих работ подмодуль интеграции должен обновить информацию о начавшейся операции.
Возможны более сложные варианты последовательности событий, когда во время выполнения работ по одной операции станок многократно переходит в состояние простоя, сменяются рабочие, рабочие не нажимают на кнопки причин простоя либо нажимают многократно во время простоя, станок выключается. Разработан алгоритм работы подмодуля интеграции, учитывающий данные варианты. Алгоритм показывает шаги по опросу подмодулем интеграции текущего состояния оборудования. Инициация этапов опроса выполняется с заранее заданной периодичностью в несколько секунд либо непосредственно по сигналу с оборудования при сканировании штрих-кода, смене состояния станка, нажатии на кнопку блока мониторинга. При поступлении сигнала о том, что произошло сканирование, в подмодуль интеграции поступает отсканированный штрих-код (в числовом виде), после чего по данным подсистемы диспетчеризации происходит распознавание типа отсканированного объекта путем анализа таблиц сопоставления штрих-кода объекта со ссылкой на объект в информационной базе.
В случае, если произведено сканирование пропуска рабочего, подмодуль интеграции определяет, было ли ранее зафиксировано начало выполнение операции на рабочем центре. Если операция начата, подмодуль интеграции осуществляет фиксацию информации о том, сколько времени выполнял данную операция предыдущий рабочий с тем, чтобы при последующем завершении текущей операции начислить заработную плату данному рабочему пропорционально доле отработанного им на данной операции времени в общем времени выполнения операции.
В случае, если была нажата кнопка на блоке мониторинга на станке с ЧПУ, подмодуль интеграции определяет, находится ли оборудование в состоянии простоя. Только в этом состоянии возможна фиксация причины простоя. Если станок находился в простое длительное время, и при этом не происходило нажатий ни на одну из кнопок блока мониторинга, подмодуль интеграции передает в подсистему диспетчирования информацию о том, что простой является необоснованным. Если во время нажатия на кнопку на блоке мониторинга станок находился в состоянии необоснованного простоя, согласно разработанному алгоритму подмодуль интеграции должен принимать за время начала простоя, соответствующего нажатой кнопке, момент перехода в состояние необоснованного простоя.
Таким образом, предполагается, что рабочий будет обосновывать весь отрезок времени не обоснованного ранее текущего простоя. В случае, если отсканирована операция по маршрутной карте, подмодуль интеграции должен проверять, была ли начата данная операция. Если операция начата, подмодуль интеграции передает в подсистему диспетчирования информацию о том, что операция завершена. При этом должна учитываться смена рабочих на данном рабочем центре, если завершаемую
операцию последовательно выполняло несколько рабочих. После передачи сигнала о завершении операции подсистема диспетчеризации должна учесть эту операцию в интерфейсе сотрудников ОТК, которые имеют возможность отметить факт прохождения данной партией деталей контроля качества.
Блоки мониторинга производственного оборудования имеют дисплей для отображения текущей информации. Данную функциональность предполагалось использовать для отображения информации о состоянии оборудования, причине простоя (в случае, если оборудование простаивает), текущей операции (в случае выполнения работ на станке), рабочем и обрабатываемой детали, а также о длительности нахождения оборудования в текущем состоянии и моменте перехода в текущее состояние. Для обоснования простоев предполагалось задействовать все имеющиеся на блоках мониторинга кнопки. Разработан перечень причин простоя:
• наладка - процесс подготовки (настройки) станка с ЧПУ к обработке определенной детали. Замер инструмента, установка заготовки, поиск нулевых точек детали;
• техническое обслуживание (техническая проблема) - действия по замене масла, смазывающе-охлаждающей жидкости (СОЖ), настройке параметров системы ЧПУ, любые ремонтные работы;
• контроль детали - выполнение контроля за получившимися размерами, проверка качества изготовления детали. Данное событие позволяет оценить заключительное время обработки конкретной детали (партии деталей);
• нет программы - на станке отсутствует управляющая программа (УП) для обработки текущей детали. Причиной может служить ситуация, когда технолог-программист не подготовил или не передал на станок программу, либо оператор станка сам занят составлением программы обработки;
• нет материала - на станке отсутствует материал обработки (заготовка);
• нет работы - у оператора станка нет задания или документации (чертежа, технологической или маршрутной карты) для выполнения.
На каждом станке состав и порядок следования причин простоя, указанных на кнопках блока мониторинга, может различаться в зависимости от особенностей самого оборудования (степени изношенности оборудования, особенностей выполняемых операций и пр.) и требований участка к получению аналитической информации. В части информации о выполняемой операции в аналогичных алгоритмах предусмотрено либо автоматическое считывание информации непосредственно со стойки станка с ЧПУ (система Cimco MDC-Max), либо считывание из заранее внесенных маршрутных карт (Foreman MDC) [3, 8].
В отличие от рассмотренных ранее аналогичных алгоритмов, разработанный алгоритм предполагает наличие в подсистеме диспетчирования занесенных маршрутных карт, сформированных в автоматизированном режиме с использованием данных, передаваемых из PDM системы либо внесенных вручную. Таким образом, в разработанном алгоритме не предполагается наличие в подмодуле интеграции дублирующей информации о маршрутах производства. Информация о сотрудниках (вместе со штрих-кодами, печатаемыми на их пропусках) также не дублируется и используется подмодулем интеграции напрямую из подсистемы диспетчирования. Также важным отличием от аналогичных подмодулей интеграции с оборудованием является то, что разработанный алгоритм предполагает во время фиксации завершения операции передачу данной информации в подсистему диспетчирования для последующего начисления заработной платы данному рабочему.
В первую очередь, в разработку был запущен объект для установки в пользовательском режиме программных настроек для блоков мониторинга на станках с ЧПУ. Объект содержит иерархию рабочих центров по подразделениям (цехам и участкам). Предусмотрена возможность выбора рабочего центра для просмотра и изменения его настроек. Для каждого рабочего центра предусмотрена привязка к МАС-адресу блока мониторинга, установленного на рабочем центре. Такая привязка обеспечивает возможность однозначно определять поступающие с устройств сигналы и связывать их с соответствующим рабочим центром. На форме имеется возможность установить изображение рабочего центра, установить тип рабочего центра, а также стоимость станко-часа для определения суммарных затрат на простой оборудования.
Параметр «Тип станка» добавлен для возможности группировки однотипного оборудования в системе отчетности. Добавлена возможность изменения набора типов производственного оборудования, имеющегося на предприятии. Для этого используется справочник «Типы станков». Для установки ти-
па оборудования одновременно для нескольких рабочих центров, занесенных в подсистему диспетчи-рования, разработан интерфейс, автоматизирующий данную рутинную операцию. Данный интерфейс позволяет отобрать рабочие центры по определенным признакам (например, по принадлежности рабочего центра определенному подразделению, либо типу, либо группе в справочнике «Рабочие центры») и установить выбранный тип для всех отобранных рабочих центров. В ходе создания подмодуля интеграции с оборудованием был разработан код, позволяющий реагировать на события сканирования штрих-кода.
Данный механизм используется как для распознавания операции, отсканированной на рабочем месте сотрудника, использующего подсистему диспетчеризации на стационарном компьютере, так и для распознавания операции, отсканированной при помощи сканера штрих-кодов, подключенного к блоку мониторинга. Таким образом, при помощи сканеров штрих-кодов появилась, помимо автоматизации считывания данных с блоков мониторинга, также и возможность автоматизации считывания завершаемых операций на рабочих местах мастеров участков. Настройка сканеров штрих-кодов на стационарных компьютерах в программе реализована типовым механизмом платформы «¡(^Предприятие 8», поэтому в дополнительной разработке не было необходимости.
Был разработан главный инструмент оперативного отслеживания состояния оборудования, отображающий текущее состояние работы оборудования, выполняемую операцию (с указанием времени начала и длительности выполнения операции) и обрабатываемую деталь. Интерфейс предназначен для начальника производства, мастера участка и диспетчера. Пользователь имеет возможность установить интервал автоматического обновления информации о состоянии. Также предусмотрена сортировка списка оборудования по наименованию, продолжительности нахождения в текущем состоянии, по настраиваемому списку причин простоя. Также имеется возможность отобрать рабочие центры, находящиеся в интересующих пользователя состояниях. Если на рабочем центре поддерживается система сканирования штрих-кодов, в строке с оборудованием отображается фамилия рабочего и деталь, обрабатываемая им.
Связь с блоками мониторинга реализована посредством разработанного веб-сервиса, встроенного в подмодуль интеграции. С блоков мониторинга считываются данные на серверную часть, после чего серверная часть передает в подмодуль интеграции все данные. Для хранения полученных данных разработан регистр, хранящий в каждой строке данные на момент их получения. При этом в каждый момент времени в регистр записываются две строки: первая строка завершает ранее запущенное состояние оборудование, вторая строка фиксирует начало нового состояния с указанного момента времени. Предусмотрена корректировка считанных данных и дополнение данных в случае сбоев при передаче данных.
Большую ценность разрабатываемого подмодуля интеграции представляет возможность предоставления руководителям полезной аналитической информации об используемом оборудовании, а именно о загрузке оборудования, длительности простоев и удельном весе простоев в общей продолжительности рабочего дня либо в суммарной продолжительности всех простоев. Для этих целей в ходе разработки подмодуля интеграции был разработан ряд отчетов, агрегирующих поступающую в систему информацию и представляющую её в различных разрезах. Разработаны следующие отчеты:
1. Диаграмма событий. Отчет показывает как совокупные данные, так и данные по отдельным рабочим центрам. Имеется возможность составлять отчеты по различным рабочим центрам и периодам.
2. Отчет по необоснованным простоям - отображает долю необоснованных простоев в общей длительности всех простоев.
3. Отчет по основному и вспомогательному времени. В данном отчете состояния оборудования группируются на основное и вспомогательное время.
4. Отчет по производственным операциям - позволяет увидеть длительность операций, информацию о рабочих, выполнявших операции, и обрабатываемых деталях.
В целях тестирования подмодуля взаимодействия подсистемы диспетчирования со станочным цеховым оборудованием был задействован участок с современными токарными станками с ЧПУ производственного подразделения ООО «ЛПМ-Механика», находящегося в составе ХОЛДИНГа ЛЕНПОЛИГРАФМАШ. На данном участке работает сотрудник, обслуживающий одновременно несколько станков. Работа подмодуля взаимодействия подсистемы диспетчирования со станочным оборудованием тестировалась, задействовав мощности сервера, имеющего следующие технические ха-
рактеристики: материнская плата X9SCM-F; процессор Intel Xeon ЕЗ-1220 3.1 GHz; оперативная память 4GB, DDR3, 1333MHz; контроллер запоминающих устройств Adaptec RAID 6405.
Таким образом, поскольку сервер соответствовал минимальным техническим характеристикам, достаточным для работы с разрабатываемым бизнес-приложением, в ходе тестирования удалось убедиться в работоспособности разрабатываемой программы для ЭВМ при заложенных в техническое задание характеристиках. В ходе тестирования работы подмодуля интеграции были выявлены и решены некоторые проблемы, перечисленные ниже.
Выявлено, что между моментом завершения операции и моментом начала следующей операции может пройти длительное время, из-за чего завершение операции (закрепленное за моментом начала следующей операции) может быть произведено со значительной задержкой, что означает невозможность своевременной отметки в подсистеме диспетчеризации о проверке качества детали после выполнения операции, а также задержке в начислении заработной платы данному рабочему. Для решения данной проблемы решено откорректировать алгоритм работы подмодуля интеграции, чтобы подмодуль воспринимал двойной сигнал со сканера штрих-кодов, распознавая подобный сигнал как сигнал о завершении текущей операции. На рисунках 2 и 3 показан обновленный алгоритм реакции подмодуля интеграции на сигнал об одиночном и двойном сканировании операции.
Возникли сложности с учетом причин простоя, поскольку рабочие не справлялись с задачей оперативной отметки причины простоя на блоке мониторинга. Проблема оказалась в том, что простои могут иметь небольшую продолжительность. В течение этого времени рабочий выполняет полезную работу (по смене детали, контролю детали), не обращаясь к блоку мониторинга. Поэтому принято решение программно определять причину простоя оборудования при возникновении простоев небольшой длительности. В частности, при начале простоя подмодуль интеграции в течение первых 20 секунд воспринимает простой как время, затраченное рабочим на выполнение контроля детали после выполнения операции, последующие 40 секунд подмодуль воспринимает как время на смену детали. Таким образом, от рабочего не требуется указывать причину простоя в случае, если простой длится менее 1 минуты. При отсутствии нажатий на кнопки блока мониторинга в течение времени, большего чем 1 минута, длительность простоя сверх этого времени автоматически воспринимается как необоснованный простой.
<Дважды отсканирована операция
Рис. 3. Алгоритм реакции подмодуля на двойное сканирование операции
Возникли вопросы удобства местоположения блоков мониторинга на станках с ЧПУ. На примере тестируемых станков с ЧПУ было показано на практике, что наиболее удобным является размещение блока мониторинга в непосредственной близости от стойки станка с ЧПУ. Также появилась потребность иметь отчетность по работе оборудования в разрезе смен. Для этих целей в отчеты были добавлены параметры с возможностью выбора интересующих руководителя смен. При этом данные для построения отчета автоматически группируются в разрезе интервалов времени, указанных в свойствах смен. В целях проверки на работоспособность программы для ЭВМ проводился запуск в режиме тонкого клиента, толстого клиента, а также через Д\гЕВ-интерфейс. Во всех случаях программа отрабатывала в штатном режиме, предоставляя заложенный в неё функционал в полной мере.
Результаты проведенного исследования можно применить для автоматизации серийного, дискретного производства. Внедрение автоматизированной системы позволяет добиться повышения технико-экономической эффективности за счет: повышения конкурентоспособности за счет предоставлению заказчику оперативной информации о возможности исполнения заказа в заданные сроки; увеличения количества выполненных заказов за счет сокращения производственного цикла (уменьшения времени межоперационного пролеживания); сокращения складских запасов. Главным результатом разработки и внедрения механизма интеграции со станочным оборудованием и основной учетной системой предприятия явилось снижение трудоемкости занесения данных, так как исчезла необходимость ручного занесения исходной информации, требующейся для подсистемы диспетчирования, а также была выполнена автоматизация подготовки документов по выработке рабочих со сдельной формой оплаты труда.
Если рассматривать среднесрочную перспективу, то очевидно стремление многих предприятий следовать концепции «Индустрия 4.0». Реализация подобной концепции приводит к качественным скачкам в повышении требований к ИТ-инфраструктуре, к её как аппаратной, так и программной части. Эффективность системы будет зависеть, прежде всего, от степени интеграции аппаратного обеспечения (стойки, контроллеры, датчики, счетчики, промышленные роботы и др.) и программного обеспечения, предназначенного для автоматизации управления производством. Другими словами, разработка предполагаемого программного модуля будет иметь спрос не только для автоматизации
действующих, управляемых человеком производственных систем, но и для человеконезависимых, полностью автоматизированных гибких производств.
Рабочая группа Национальной технологической инициативы по передовым производственным технологиям (кросс-рыночное направление НТИ), обеспечивает впервые в России технологическую поддержку зарождения и развития рынков будущего и высокотехнологичных компаний посредством развития передовых производственных технологий как в рамках рынка, так и путем кросс-отрас-левого трансфера передовых технологий. Важным конкурентным преимуществом разрабатываемого модуля является адаптированность к потребностям отечественным машиностроительных предприятий. Отечественные машиностроительные предприятия имеют преимущественно дискретный тип производства. В условиях дефицита бюджетов на ИТ-развитие, у многих промышленных предприятий основной упор будет делаться на продвижение разрабатываемого решения для: предприятий ОПК; предприятий, уже использующих программную платформу «1С:Предприятие».
Суть бизнес-модели заключается в создании тиражируемого программного модуля. Единожды понесенные затраты на его создание окупаются при последующей реализации экземпляров программного модуля, точнее реализации неисключительных прав на его использование [5].
ЛИТЕРАТУРА
1. Аркин ПА., Соловейчик К.А., Аркина КГ. Методология оптимизационных подходов к процессам управления производством в машиностроении // Известия Санкт-Петербургского государственного экономического университета. 2017. № 1 (103), ч. 2. С. 69-77.
2. Аркин П.А., Соловейчик К.А., Аркина КГ. Реализация методологии оптимизационных подходов при разработке алгоритма модуля диспетчирования производства на машиностроительном предприятии // Известия Санкт-Петербургского государственного экономического университета. 2017. № 2 (104). С. 94-100.
3. Ловыгин A. Foreman MDC - система нового поколения для мониторинга станков с ЧПУ // CAD/CAM/CAE Observer. 2007. № 6. С. 71-73.
4. Прилуцкий М.Х., Власов С.Е. Многостадийные задачи теории расписаний с альтернативными вариантами выполнения работ // Системы управления и информационные технологии. 2005. № 2(19). С. 44-47.
5. Свидетельство о государственной регистрации программы для ЭВМ № 2016617323 от 01.07.2016.
6. Соловейчик К.А., Аркин П.А. Методические вопросы стимулирования роста глубины передела промышленной продукции субъектами Российской Федерации // Известия Санкт-Петербургского государственного экономического университета. 2015. № 4 (94). С. 25-30.
7. Kestner W., Blecker T., Hersatt С. Innovative Logistics Management. Schmidt Erich Verlag, 2008.
8. MDC-Max Configuration Manual. [Электронный ресурс]. Режим доступа: http://www.cimco.com/pro-ducts/manuals/CIMCOMDC-MaxManual(EN).pdf (дата обращения 29.04.2016).
9. MonkE.F., Wagner B.J. Concepts in enterprise resource planning. Boston: Thomson Course Technology, 2013.
10. Stadtler H., Kilger C. Supply Chain Management and Advanced Planning. Concepts, Models, Software and Case Studies. Berlin: Springer, 2008.
