Abstract and keywords
Abstract (English):
The article focuses on the problem of jointly control of titanium sponge recovery and magnesium electrolysis stages. Analysis of operational process of segments of electrolysis and reduction of spongy titanium is made; it helps to determine systemic links and to investigate methods of joint control over them. The shortcomings of traditional simulation systems have been stated as applied to this task. A set of C++ classes is created to obtain possibility of designing simulation systems (and, potentially, multi-agent and active systems) of industrial processes that differ in absence of structurally pre-determined links between objects and complex algorithms of action and interaction of objects. Links between objects occur in the course of model developing, so the set can flexibly change. Technically, classes of all model objects are inherited from one base class, which allows to properly arrange their calling from a simulated time step function. Modelling time step is achieved by Δ t method, i.e. when special states are accounted after termination of a certain time segment. A unified time step function is cyclically going over all objects, until their state stops changing. Depth of inquiry is set a-priori. A check of created modeling tool made by solving a task with the known solution has been made. A model of elementary queuing system cell based on the class set has been developed. Comparison of the simulation results with results of a similar cell in GPSS. The correspondence of simulation results is shown. The problem of the necessary inquiry depth of objects using time step function has been investigated.

Keywords:
titanium sponge, production, control, simulation modeling
Text
Титан и его сплавы являются важными конструкционными материалами. Титановые сплавы имеют высокую удельную прочность, высокую жаропрочность и коррозионную стойкость. Они широко применяются в космической технике, авиа- и автомобилестроении, строительстве, медицине и других отраслях промышленности [1, 2]. Россия является крупным производителем титана, который производится ПАО «Корпорация ВСМПО-АВИСМА», - единственной в мире титановой компанией, осуществляющей полный цикл производства от переработки сырья до выпуска конечной продукции. В составе корпорации две промышленные площадки: «ВСМПО» в городе Верхняя Салда Свердловской области и «АВИСМА», филиал в городе Березники Пермского края, которые связаны между собой единой технологической цепочкой. От поставок титана из России зависят крупные машиностроительные компании. Так, Boeing получает от ВСМПО около 35 % титана, необходимого для производства гражданских самолетов, а самолет AirbusA380 на 60 % сделан из уральского титана [3]. Следовательно, повышение эффективности и решение проблем титанового производства в России является важной задачей общегосударственного уровня. Производство губчатого титана осуществляется химической реакцией TiCl4 + 2Mg = Ti + 2MgCl2, определяющей круговорот магния в производстве. Металлический магний в расплаве вакуумными ковшами подается из основного производственного участка № 3 (ОПУ-3) на восстановление тетрахлорида титана на ОПУ-2. В ходе восстановления образуется хлорид магния, который порционно возвращается на электролиз в ОПУ-3. При этом из-за ошибок в планировании процессов возникает необходимость слива хлорида магния в короба с последующей длительной и дорогостоящей переработкой в ОПУ-1, что приводит к удорожанию производства (рис. 1). Рис. 1. Схема процессов, протекающих между ОПУ-2 и ОПУ-3 Описание объекта моделирования Процессы восстановления и электролиза в производстве титана можно отнести к классу сложных объектов управления [4, 5]. Одним из возможных инструментов исследования таких производственных систем является имитационное моделирование систем массового обслуживания (СМО, queuing system) [6]. Многочисленные зарубежные [7, 8] и российские [9, 10] источники показывают эффективность применения имитационного моделирования при изучении и оптимизации деятельности предприятий и их подразделений. В частности, показано, что мультиагентное моделирование, являющееся развитием моделей массового обслуживания, служит эффективным средством поддержки принятия решений по управлению производством [11]. Напомним, что мультиагентная система (МАС) - это, в сущности, имитационная модель, в которой объектам («агентам») свойственна некоторая автономность, децентрализованность и ограниченность представлений [12]. Предельная автономность и ограниченность свойственны каналам и транзактам СМО. Программные агенты МАС описываются алгоритмами собственных действий и взаимодействия с другими программными агентами. Совместная имитационная модель деятельности двух участков позволила бы установить причины, приводящие к отсутствию в нужный момент ковшей в ОПУ-2, вплоть до полного исключения ОПУ-1 из технологической схемы. Для построения такой модели в 2016-17 гг. были выполнены измерения продолжительности основных процессов, представленных на рис. 1. Кроме этого, для объектов технологической схемы (ковш, вакуум-ковш, печь восстановления, электролизер) определены их особые состояния, условия перехода из одного состояния в другое и т. д. В укрупненном виде они представлены на рис. 2. В задаче совместного моделирования двух производственных участков, описанной выше, имеется кольцевое движение между участками транспортных средств, перевозящих порции химических веществ. В этой ситуации не слишком понятно, что выбрать в качестве «классического» канала, а также каким образом совместить модель СМО и модель технологического процесса, в ходе которого вырабатываются требуемые вещества, тем более, что выборка веществ из десятков реакторов осуществляется по довольно сложному алгоритму. Таким образом, в данной системе не возникает постоянной связи между реакторами и средствами транспортировки. В то же время набор реакторов нельзя рассматривать как обычную многоканальную СМО, т. к. производительность реакторов несколько отличается, и необходимо будет моделировать каждый отдельно. Рис. 2. Имитационная модель взаимодействия участков электролиза и восстановления губчатого титана Подобная модель может быть создана средствами среды AnyLogic. Однако она предназначена главным образом для моделирования систем с одинаковыми транзактами, неразличимыми по сути задачи - например, пассажиропотока в аэропорту. Кроме того, общедоступная бесплатная версия среды ограничена по времени моделирования и количеству транзактов и устройств в модели. А по условию задачи требуется очень продолжительное моделирование совместной работы участков (недели и месяцы непрерывно). Поэтому в данном конкретном случае целесообразна разработка специального средства имитационного моделирования на одном из общецелевых языков программирования. Это, собственно, является целью данной работы. Выбор языка несущественен, для этой реализации был выбран С++ (freeware реализация TDM GCC). Программная часть модели делится на универсальную основу и конкретную реализацию устройств конкретной модели. Универсальная основа упрощена по сравнению с «полноценными» средствами имитационного моделирования в том смысле, что в ней не предусмотрено непосредственное программирование связей между устройствами (стабильных потоков транзактов). Вместо этого метод, реализующий продвижение времени для класса конкретного объекта, содержит алгоритм проверки изменения состояния произвольного количества других объектов, с которыми ситуативно связан данный. Такой подход усложняет реализацию конкретных классов: выражаясь упрощенно, вместо оператора входа в 1-й канал SEIZE 1 (в GPSS) необходимо для устройства № 1 описать на общецелевом языке программирования все связи, существующие в данный момент. Зато существенно упрощается глобальный метод продвижения времени, как это описано ниже. Разработка средства моделирования Разработанное средство имитационного моделирования выполнено в виде иерархии классов и их дружественных функций. Вспомогательным классом является event - класс состояния устройства, содержащий строчный список описания состояний и их номера. Базовым классом для всех устройств является абстрактный класс obj. Он содержит общие для всех возможных устройств переменные в защищенной (protected) области, такие как строковое имя объекта, целочисленный номер текущего состояния объекта now_event, модельное время, в которое наступит смена состояния next_time, справочный номер следующего состояния объекта (если он используется) next_event, количество возможных состояний объекта len_event и др. Большинство данных класса обрабатываются конструкторами производных классов и функцией продвижения времени. Класс также содержит указатель на двухпараметрическую функцию генератора случайных чисел (ГСЧ) и его параметры для конкретного объекта. Генератор случайных чисел с равномерным статистическим распределением моделируется библиотечной функцией С++ rand (), остальные ГСЧ (нормальное, экспоненциальное распределения, распределение Пуассона и др.) реализованы методом обратной функции. Конструктор базового класса присваивает каждому объекту уникальный номер и инициализирует некоторые данные. Конструктор каждого производного класса должен: 1) завершить изменение всех необходимых этому объекту внутренних переменных базового и производного классов (например, объект «очередь» LIFO или FIFO будет, очевидно, содержать список объектов в этой очереди, который надо инициализировать); 2) добавить в список необходимое количество своих возможных состояний (их количество передается конструктору obj::obj () перед выполнением конструктора производного класса); 3) указать, какой ГСЧ использовать, и его параметры; 4) возможно, установить время первого события с этим экземпляром класса (иначе obj::obj () установит next_time в 0, и первый же вызов функции обработки продвижения времени констатирует особое состояние); 5) добавить этот экземпляр объекта производного класса в односвязный список list объектов типа obj*, реализованный очевидным образом в виде класса. Порядок объектов в этом списке определяет порядок их перебора при продвижении времени. Класс obj содержит также переменную state_change, позволяющую реализовывать обработку продвижения времени до тех пор, пока изменения состояний одних объектов будут вызывать изменения состояний других объектов. Главная функция продвижения времени main_run (), дружественная (friend) к классу obj, реализована следующим образом. Порядок перебора объектов в ней - в том порядке, в котором они были добавлены в список, а не по противотоку. Это, конечно, вызывает дополнительную погрешность моделирования. Так как в ядре этой системы моделирования вообще не предусмотрено понятие «связь между объектами», то противоток и невозможен в принципе. Поэтому цикл изменения и опроса состояний вызывается, пока хоть один объект в списке сообщает, что он изменился сейчас. Количество повторов цикла опроса всех объектов схемы ограничено переменной max_cycle. Изменился или нет, решает метод run (), обязательно переопределенный в объекте (класс obj является абстрактным, функция run () в нем чистая виртуальная и не имеет реализации). Если run () обнаруживает, что между прошлым и наступившим моментом времени произошло изменение состояния (т. е. obj::next_time < now_time), он устанавливает obj::state_changed = 1, изменяет obj::now_event и делает все, что ему необходимо с внутренними переменными, в том числе обязательно устанавливает новое значение obj::next_time так, чтобы оно было больше now_time (даже если его ГСЧ выдает меньше): нельзя несколько раз за шаг менять состояние. Иначе, если run () обнаруживает, что obj::state_changed, он просто сбрасывает его в 0. Затем, если state_changed == 0, run () проходит по всему списку объектов *list и проверяет, есть ли объекты, у которых их state_changed == 1. Метод run () должен отреагировать на изменение состояния тех объектов, которые ему известны как связанные с данным объектом. Если изменение состояния какого-то объекта вызывает изменение состояния другого объекта, то и в нем производятся необходимые изменения (точно меняется obj::now_event, возможно, меняются obj::next_time и obj::next_event; возможно, меняются внутренние параметры (типа длины очереди), а после этого obj::state_changed устанавливается в 1. Методу run () достаточно вернуть state_changed, чтобы сообщить, нужен ли еще один проход по списку объектов в главной функции. Однако чтобы все это не было слишком долго, количество проходов в главной функции ограничено целочисленной переменной max_cycle. Для проверки реализуем на созданном средстве моделирования элементарную ячейку СМО с неограниченной очередью и производительностью канала 11 ± 2 единицы модельного времени на транзакт, которая нагружена потоком транзактов, поступающих каждые 12 ± 5 единицы модельного времени (ЕМВ). Результатом моделирования в течение 1 млн ЕМВ является обработка в канале 83 356 транзактов, загрузка канала 0,916 (что близко к очевидному теоретическому значению 11/12 = 0,916 66…), максимальное количество транзактов в очереди - 5, среднее время пребывания в очереди 3,268 ЕМВ. Для моделирования в С++ понадобились классы, производные от класса obj: генератор, транзакт, очередь, канал. Терминатор, собственно, не нужен, т. к. время моделирования будет задано непосредственно в main (), а функцию удаления из памяти транзактов назначим каналу в момент окончания обработки транзакта. Схема реализована, получен результат прогона продолжительностью 1 млн ЕМВ. В результате моделирования получена максимальная длина очереди 5, загрузка канала 0,916 018. Количество транзактов от GPSS отличается на 0,9 %. Максимальная длина очереди та же самая. Загрузка канала отличается от теоретической на 0,7 % (под загрузкой подразумевается отношение времени, в течение которого канал обрабатывает транзакты, к общему времени моделирования). Возникает вопрос - какое максимальное количество циклов опроса за шаг необходимо установить? Ведь увеличение глубины опроса может существенно увеличить время моделирования. В этой элементарной системе все достаточно просто, т. к. в системе всего три устройства, и значение max_cycle > 3 избыточно. Однако проверим все же это экспериментально, изменяя глубину опроса и контролируя значения результатов моделирования (табл.). Исследование влияния значения переменной max_cycle на результаты моделирования Max_cycle Средняя глубина опроса Максимальная глубина опроса Длина очереди Загрузка канала 10 000 0,215 2 5 0,916 1 000 0,215 2 5 0,916 100 0,215 2 5 0,915 10 0,215 2 5 0,915 2 0,215 2 5 0,915 1 0,234 1 57 0,914 Очевидно, что в глубине опроса более 2 нет необходимости. Однако как только потребная глубина опроса перестает достигаться, модель выдает неадекватные результаты. В исходной задаче моделирования участков электролиза магния и восстановления губчатого титана количество устройств (донные ковши, вакуумные ковши, электрокары, электролизеры, печи восстановления, монтажный участок и т. д.) будет исчисляться сотнями, поэтому в ней необходимы будут дополнительные исследования зависимости погрешности моделирования от максимальной глубины опроса. Заключение В итоге поставленная в данной статье цель достигнута. Создано и опробовано средство, позволяющее моделировать системы массового обслуживания, в том числе те, которые сложно реализовать в стандартных имитационных средствах. Показано соответствие результатов моделирования в новой системе и в языке GPSS. Определены потенциальные проблемы моделирования сложных систем с помощью созданного ПО. Очевидно, что ПО может использоваться не только для классических СМО (queuing system), но и для активных, и для многоагентных систем, которые будут отличаться только реализацией метода run () в соответствующих классах.
References

1. Proizvodstvo cvetnyh metallov. URL: http://metalspace.ru/education-career/osnovy-metallurgii/ proizvodstvo-tsvetnykh-metallov/542-proizvodstvo-titana.html (data obrascheniya: 05.04.2018).

2. Seagle S. R. Titaniumprocessing. URL: https://www.britannica.com/technology/titanium-processing #accordion-article-history (data obrascheniya: 05.04.2018).

3. Polunin A. «Titanovye sankcii»: «Boing» i «Aerobus» ustroyat Rossii zhestkuyu posadku. URL: http://svpressa.ru/economy/article/179910/ (data obrascheniya: 05.04.2018).

4. Kirin Yu. P., Zatonskiy A. V., Bekker V. F., Kraev S. L. Identifikaciya tehnologicheskih processov proizvodstva gubchatogo titana // Problemy upravleniya. 2008. № 4. S. 71-77.

5. Kirin Yu. P., Zatonskiy A. V., Bekker V. F., Bil'fel'd N. V. Sovremennye napravleniya sovershenstvovaniya i razvitiya proizvodstva gubchatogo titana // Titan. 2003. № 2 (13). S. 11-16.

6. Rashid R., Hoseini S. F., Gholamian M. R., Feizabadi M. Application of queuing theory in production-inventoryoptimization // Journal of Industrial Engineering International. 2015. Vol. 11. P. 485-494.

7. Brown A. J. A study of queuing theory in low to high rework environments with process availability. URL: https://uknowledge.uky. edu/ms_etds/2 (data obrascheniya: 05.04.2018).

8. Bitran G. R., Dasu S. A. Review of the Open Queueing Network Models of Manufacturing Systems. Working papers 3229-90, Massachusetts Institute of Technology (MIT), Sloan School of Management, 1990. 64 p.

9. Mul'tiagentnye sistemy dlya upravleniya proizvodstvom v real'nom vremeni. URL: http://www. iki.rssi.ru/seminar/2011030204/presentation/20110303_04.pdf (data obrascheniya: 05.04.2018).

10. Zatonskiy A. V. Modelirovanie tehnologicheskogo uchastka obogatitel'noy fabriki v pakete MATLAB // Obogaschenie rud. 2014. № 4 (352). S. 49-54.

11. Skobelev P. O. Mul'tiagentnye tehnologii v promyshlennyh primeneniyah: k 20-letiyu osnovaniya Samarskoy nauchnoy shkoly mul'tiagentnyh sistem // Mehatronika, avtomatizaciya, upravlenie. 2010. № 12. S. 33-46.

12. Ivanova E. V., Zatonskiy A. V. Ocenka i modelirovanie nauchno-issledovatel'skoy raboty studentov kak mnogoagentnoy sistemy // Sovremennye naukoemkie tehnologii. 2009. № 7. S. 75-78.

13. Kirin Yu. P., Zatonskiy A. V., Bekker V. F., Bil'fel'd N. V. Sintez i analiz optimal'nogo pozicionnogo upravleniya tehnologicheskimi processami proizvodstva gubchatogo titana // Avtomatizaciya i sovremennye tehnologii. 2010. № 9. S. 18-21.

14. Timochkina V. A., Ufimceva V. N. Tehnologicheskie problemy v processe vosstanovleniya gubchatogo titana // Reshenie. 2017. T. 1. S. 333-335.


Login or Create
* Forgot password?