Узкие места функционирования опасных производственных моментов. Система сбалансированных показателей. Система Планирования и Мониторинга SCMo

Руководитель направления производственных решений, СофтБаланс

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

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

Тем не менее, не стоит забывать, что любая автоматизированная система - это, прежде всего, инструмент для решения конкретных задач. Главной остается, все же, методология .

Рассмотрим основные проблемы, с которыми сталкиваются менеджеры, ответственные за управление производственным процессом, а также - роль и основные варианты автоматизации некоторых производственных процессов на цеховом и межцеховом уровне.

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

Борьба с просроченными заказами на производстве - пожалуй, основная проблема любого завода. «У нас слишком много заказов, поэтому мы не успеваем » - основное объяснение, которое можно слышать от менеджеров по производству. Так ли это? В большинстве случаев при детальном анализе бизнес-процессов того или иного производственного предприятия мы видим, что ключевая проблема - не в повышенной загрузке («коммерческий департамент заключил слишком много контрактов ») и не в автоматизированной системе (когда ее вообще нет или когда «система не работает »), а - в рациональном планировании производства до уровня конкретного станка .

«Узкие места» и их роль в рациональном планировании производства

Первый шаг в решении проблем пропускной способности производства - это найти «узкие места » (англ. - «bottleneck», дословно - «бутылочное горлышко»). Согласно Голдратту, под «узким местом» понимается рабочий центр (станок, рабочее место, линия), пропускная способность которого меньше или равна потребности в нем со стороны запросов рынка (выраженной, например, в объеме текущего портфеля заказов). В 90% производств есть такие рабочие центры. В зависимости от специфики той или иной отрасли, это могут быть как рабочие места ручной обработки, так и самые современные станки с ЧПУ.

Главный признак «узкого места» - это сравнительно большие очереди деталей и полуфабрикатов на входе станка или рабочего места. «Перед какими станками самая длинная очередь деталей и полуфабрикатов? На каком этапе производственного цикла наблюдается максимальное время пролеживания? Между какими точками маршрута наблюдается максимальный остаток незавершенного производства? » - ответив на эти вопросы, мы приблизимся к определению «узких мест» на производстве. Вычислив такие рабочие центры, можно приступать к следующему шагу - эффективному производственному менеджменту, основанному на посменном планировании «от узких мест» .

Минимизация - «узких мест» на производстве может обеспечиваться следующими организационными мероприятиями:

• Метод предварительного планирования

Пропускная способность всей производственной линии определяется пропускной способностью самого «медленного» рабочего центра в технологическом процессе. С точки зрения планирования загрузки производственных мощностей, это правило используется при так называемом предварительном планировании производства .

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

Суть метода - в определении загрузки всей производственной линии по анализу загрузки рабочих центров, относящихся к «узким местам». Такой расчет основывается только на одном показателе - производительность рабочего центра для той или иной номенклатуры готовой продукции . При этом не имеет значения, на каком этапе в производственный процесс включается «узкое место». Главное - чтобы технологический процесс включал данный рабочий центр.

Предварительный план производства требует минимум входных данных и рассчитывается относительно быстро (учитывая производительность современных систем автоматизации и при наличии входных данных - практически мгновенно). При применении на предприятии метода предварительного планирования схема иерархии планов производства может выглядеть следующим образом:

Рисунок 1.

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

• Использование приоритетов заказов. Цветовая маркировка партий и штрихкодирование

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

Рисунок 2.

Приоритеты заказов, назначенные коммерческим отделом или начальником производства (в зависимости от специфики бизнес-процессов), - влияют на визуальную маркировку всех материалов и полуфабрикатов (деталей и сборочных единиц - ДСЕ), которая - в дальнейшем становится ориентиром - приоритетности обработки для рабочих на всем маршруте производства.

Другой аспект идентификации партий незавершенного производства (НЗП) - это штрихкодирование . Главная задача штрихкодирования партий НЗП - это автоматизация учета факта перемещения деталей, сборочных единиц и прочих полуфабрикатов по маршруту производства. Практика показывает снижение затрат на учет факта движения товарно-материальных ценностей (ТМЦ) по производству на десятки процентов. На сегодняшний день - учет факта движения ТМЦ посредством штрихкодирования партий - атрибут почти любого дискретного производства.

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

• код и наименование полуфабриката;
• код и наименование конечной продукции;
• номер и статус заказа;
• код подразделения и обрабатывающего рабочего центра;
• плановое время подачи на обрабатывающий рабочий центр.

Таким образом, при выпуске сменных заданий в системе посменного планирования (как правило - часть MES-системы, от англ. «Manufacturing Enterprise Solution»), оператор системы (или, как вариант, диспетчер) одновременно выпускает этикетки на продукцию, получаемую на конкретном рассматриваемом рабочем центре. По завершении изготовления деталей первого передела, этикетка крепится к детали, и все ее дальнейшие перемещения по маршруту производства отмечаются на рабочем месте учета движения материальных потоков, имеющем сканер штрихкода (СШК).

«У нас на производстве работает самое современное высокопроизводительное оборудование. Мы не можем работать быстрее. » - как правило, это не так. Часто, несмотря на высокую производительность в рамках одного станка, производительность всего предприятия может быть снижена неоптимальным использованием рабочего времени обслуживающего персонала.

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

Детальное посменное планирование. Общая концепция

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

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

• Объемно-календарные (стратегические) планы производства;
• План выпуска по заказам;
• Индивидуальные внеплановые выпуски продукции;

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

НСИ для посменного планирования состоит из двух разделов:

• Нормативный состав изделия;
• Технология изготовления.

Нормативный состав изделия - это дерево вложенных спецификаций (для многопередельного производства), содержащее информацию о составе готового изделия и всех его узлов вплоть до каждого материала. Технология изготовления - это набор технологических карт производства, элементарными частями которых являются технологические операции . Ключевым показателем здесь является норматив выполнения операции (время в секундах, требуемое для совершения одной операции того или иного вида). Примечание: некоторые эксперты в области автоматизации посменного планирования считают, что построению эффективной системы планирования производства часто мешает отсутствие тщательно выверенной базы нормативов выполнения производственных операций. Однако следует помнить, что наиболее критично иметь точные нормативы только по «узким местам».

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

Рисунок 3

Общий алгоритм формирования посменных планов

Большинство современных систем посменного планирования так или иначе основывается, или, по крайней мере, учитывает теорию ограничений Голдратта, которая привносит ряд критериев оптимизации посменного плана . Задача алгоритма планирования - составить план работы оборудования, а также план потребностей в материалах в краткосрочном периоде (горизонт планирования - месяц, неделя, сутки). Критерии оптимизации в данном случае являются дополнительными ограничителями всех возможных вариантов построения производственной программы (плана производства по сменам). Существует две основных группы критериев оптимизации:

• Критерии оптимизации распределения загрузки рабочих центров;
• Критерии выбора порядка исполнения технологических операций;

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

Критерии оптимизации распределения загрузки рабочих центров определяют правила выбора, в какой момент и на какой рабочий центр должен быть передан тот или иной материал/полуфабрикат. Существуют следующие основные критерии оптимизации:

• Максимальная мощность грузопотока (объем перерабатываемых ТМЦ в единицу времени в натуральных показателях).
• Минимизация времени переналадки.
• Минимизация времени транспортировки (между рабочими центрами и подразделениями).
• По приоритетам заказов.

Критерии выбора порядка исполнения технологических операций позволяют автоматически определять последовательность технологических операций в пределах очереди технологических операций на одном рабочем центре. Классически выделяются следующие правила распределение операций в очереди одного рабочего центра:

• FCFS (first come, first served - «первой поступила, первой обслужена»);
• LCFS (last come, first served - «последней поступила, первой обслужена»);
• SPT (shortest processing time - выбор в первую очередь коротких операций);
• LPT (longest processing time - выбор в первую очередь длительных операций);
• STPT (shortest total processing time remaining - выбор операций в порядке, обратном оставшемуся времени исполнения маршрута);
• EDD (earliest due date - выбор операции с наиболее ранним сроком выполнения);
• STR/OP (slack time remaining per operation - первыми выполняются операции маршрутов с наименьшим запасом времени в расчете на одну операцию);
• CR (critical ratio - первыми выполняются операции маршрутов с наименьшим критическим отношением, рассчитываемым по формуле:

ВремяДоЗавершенияМаршрута / ДлительностьОперацийМаршрута)

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

Помимо использования вышеупомянутых критериев оптимизации, современная система посменного планирования реализует второй цикл планирования «от узких мест»: непосредственно при посменном планировании система автоматически определяет список самых загруженных рабочих центров. В этом случае поиск «узких мест» система проводит уже не по критерию соотношения пропускной способности рабочего центра и запросов рынка, а по признакам «узкого места», т.е. - по статистике уровня НЗП, длине очереди и пр.

Заключение

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

В данной статье тезисно приведены основные возможности систем посменного планирования (как правило - входящих в состав MES-систем) без привязки к конкретному разработчику или решению - для того, чтобы на уровне концепции показать важность подхода, как базы для автоматизации. Каким бы ни был объект автоматизации - сама система посменного планирования всегда остается инструментом в достижении конечной цели производственного предприятия. А конечная цель производственного предприятия - это приносить прибыль (Элияху Голдратт, бизнес-роман «Цель», 1984г.).

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

Целевая функция организационного управления в указанных случах имеет вид, аналогичный (9.36):

v =min (9.39),

где время простоя аппарата обслуживания (или канала, или отдельной фазыпри соответствующем выборе индексов) перед поступлением на обслуживаниеi -го требования из общей партии вN требований.

Так, для одноканальных однофазных объектов суммарная величина простоев аппарата обслуживания для всей партии изN требований определяется выражением (9.8), поэтому целевая функция организационного управления, в том числе автоматизированного, в этом случае имеет вид:

v =[ 1sign(+)]min (9.40).

Аналогичные выражения можно получить для многофазных и/или многоканальных объектов как систем массового обслуживания на основе (9.16), (9.26) или (9.34).

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

3. Выявление и ликвидация "узких мест"

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

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

Признаком наличия "узких мест" в технологической схеме объекта, интерпретируемого как СМО, является образование очереди или задержки на предыдущих агрегатах или фазах перед аппаратом (или фазой), являющихся "узким местом", и, наоборот, простой аппаратов (или фаз) непосредственно после него.

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

Пусть, например, объект как одноканальная СМО состоит из нескольких последовательно расположенных одноканальных однофазных аппаратов обслуживания, технологическая схема которого соответствует рис.9.5.

Рис.9.5. Схема многоаппаратной одноканальной СМО.

Аппараты обслуживания технологической схемы данной СМО обозначены индексом k и именноk -ый из них является "узким местом". Пустьi -ое требование находится на обслуживании в указанномk -ом аппарате в течение времени, причем оно поступило в этот аппарат с интерваломпо отношению к ранее пришедшему требованию.

На предыдущем (k 1)-ом аппарате находящееся там требование уже закончило обслуживание и ждет освобожденияk -го аппарата; возможно, на входе в (k 1)-ый аппарат уже находится еще одно требование в ожидании обслуживания. Таким образом, ситуация на (k 1)-ом аппарате отражается временной характеристикой (9.4):

= +при+>для (9.41);

Следующий, (k +1)-ый аппарат находится в состоянии простоя, поэтому для него в общем случае на основании (9.8) будем иметь:

= при>+для [k +1, ...,n ] (9.42).

Что же касается непосредственно k -го аппарата технологической схемы, являющегося "узким местом", то конкретно для него может быть справедливо как соотношение (9.41), так и (9.42), в зависимости от того, что конкретно лимитирует его функционированиелибо начало обслуживания требования (т.е. вход аппарата; может быть, начальные фазы обслуживание, если оно многофазно, и т.д.), либо его состояние (внутренние элементы, связи между ними, заключительные фазы и т.п.

Целевая функция организационного управления v , направленного на ликвидацию "узкого места" и увеличение за счет этого производительности всей технологической схемы, имеет следующий общий вид:

v =(9.43).

Аналогично можно получить выражения при других структурах объекта и других дисциплинах обслуживания. Реализовав имитационную модель исследуемого объекта на ЭВМ применительно к различным условиям его функционирования и получив в количественном виде значения критериев (9.41) и (9.42) для каждого компонента и/или технологической схемы, что всегда можно сделать, по этим полученным результатам легко установить, имеет ли место в данной технологической схеме "узкое место" и какой конкретно компонет объекта и в каких конкретно условиях им является. После чего можно предлагать комплекс организационно - технических мероприятий по ликвидации “узкого места” (распараллеливание обслуживания требований в этом месте технологической схемы производства, ускоренные технологии, т.е. с существеннно более быстрым обслуживанием и соответственно меньшим средними т.п.), а также затем проверить их эффективность на той же имитационной модели объекта.

Узкое место

Узкое место - явление, при котором производительность или пропускная способность системы ограничена одним или несколькими компонентами или ресурсами. В соответствующем англоязычном термине (англ. bottleneck ) прослеживается аналогия с горловиной бутылки, узость которой не позволяет вылить или высыпать всё её содержимое сразу, даже если её перевернуть. При увеличении её ширины увеличивается и скорость, с которой бутылка опустошается. Относительно бизнеса, узким местом организации является то, что снижает её производительность.

Управление проектами

Узкие места в программном обеспечении

См. также

Wikimedia Foundation . 2010 .

Синонимы :

Смотреть что такое "Узкое место" в других словарях:

Ситуация принятия решения при недостаточных производственных мощностях, в которой калькуляция покрытия показывает, какой ассортимент продукции предприятию следует выбрать для того, чтобы получить как можно более высокое покрытие. См. также:… … Финансовый словарь

Заковырка, трудность, затруднение, заколупка, проблема, препятствие, закавычка, зацепка, закорючка, загвоздка, закавыка, пиковое положение, запятая, осложнение Словарь русских синонимов. узкое место сущ., кол во синонимов: 19 загвоздка (26) … Словарь синонимов

- (bottleneck) Реальное ограничение (constraint) максимальных темпов развития или уровня какой либо деятельности. В экономике данный термин употребляется по аналогии с физикой. Например, максимальная скорость вытекания жидкости из бутылки… … Экономический словарь

узкое (место) - узкая часть — Тематики нефтегазовая промышленность Синонимы узкая часть EN criticalnarrow …

узкое место - узкий проход — Тематики нефтегазовая промышленность Синонимы узкий проход EN bottleneckbottle neck … Справочник технического переводчика

«узкое место» - 3.46 «узкое место»: Объект газотранспортной системы (магистральный газопровод, газопровод отвод, газопровод перемычка, распределительный газопровод или их участок, компрессорная станция, ГПА, станция подземного хранения газа, ГИС, узел… … Словарь-справочник терминов нормативно-технической документации

«УЗКОЕ МЕСТО» - – ситуация, складывающаяся в результате недостатков в организации производства, когда рабочее место не обеспечивается материальными, трудовыми или топливно энергетическими ресурсами; превышение производительности труда при предыдущей… … Краткий словарь экономиста

узкое место - в чём. Наиболее слабая, уязвимая сторона в каком л. деле, создающая затруднения, осложнения и т.п. У ое место в производстве … Словарь многих выражений

- (сленг.) 1) недостаток производственных мощностей в цепи технологического процесса, определяемый каким либо компонентом: оборудованием, персоналом, материалами или доставкой, транспортировкой; ликвидируется в ходе организационно технических… … Энциклопедический словарь экономики и права

Публ. Недостаток в слабых звеньях производственного процесса, ведения хозяйства. НРЛ 96; БТС, 1378; Мокиенко 2003, 57 … Большой словарь русских поговорок

Книги

• Синергетика и самоорганизация. Социально-экономические системы , Милованов В.П.. В настоящей книге подробно рассматривается синергетика и самоорганизация в социально-экономических системах, и, в частности, в ценообразовании. Предлагаются формулы для расчета цен, эмиссии…

Выполним расчет плановой загрузки оборудования и определим "узкие места". Построим календарный план производства и проанализируем производственную программу на предмет ее выполняемости.

Определение узких мест производственной программы. Расчет и баланс загрузки оборудования при планировании производства.

Любой начальник производства регулярно задается вопросом «Сможет ли он сделать все запланированные заказы в срок . Достаточно ли для этого производственных мощностей предприятия? Насколько напряженной предполагается работа в этом плановом периоде?»

В данном ролике будут продемонстрированы модули системы TCS , позволяющие, во-первых, рассчитать и проанализировать объёмные показатели загрузки оборудования в интересующий временной период, а во-вторых, визуализировать календарный план производства в виде диаграммы Ганта с одновременным отображением загрузки интересующего оборудования.

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

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

Следующим шагом выполним расчёт дат запуска для товарных позиций и их составляющих, а также комплектующих, изготавливаемых отдельным заказом для склада унифицированных деталей. Выделим все производственные спецификации планового периода и запустим макрос "Расчёт дат запуска/выпуска ".

В результате, для всех изготавливаемых деталей и сборочных единиц мы получаем ориентировочные даты начала и окончания производства, рассчитанные исходя из заданных сроков и применяемых технологических процессов.

Сделаем эти производственные спецификации рабочими , и получим на соответствующей закладке номенклатурный план производства . В нём перечислены позиции с количеством, которое необходимо изготовить, и сроки.

Итак, самая ранняя дата запуска партии – 18 февраля, самая поздняя дата выпуска – 23 марта 2010 года.

На закладке "Техпроцесс " представлена более детальная информация, а именно план по операциям. Т.е. список всех работ, которые необходимо выполнить для изготовления всех запланированных позиций. Для каждой работы рассчитана трудоемкость её выполнения, а также в соответствии с технологическим процессом отображено оборудование, цех, участок, профессия и разряд.

Также, в системе TCS ведется информация о станочном парке предприятия, т.е. реальном количестве каждой модели оборудования и их наличие в подразделениях. Например, у нас на первом участке седьмого цеха расположены пресс Amada и пресс FINN-POWER, на втором участке оборудование для сварки, на третьем столы для сборки и контроля.

Для оценки выполнимости данного плана используем модуль "" системы TCS . Установим даты начала и конца периода, в который предполагается выполнять запланированные работы, а именно 18 февраля и 23 марта 2010 года. Выполним расчёт.

В результате расчёта показывается список всех моделей оборудования, задействованных для выполнения работ. Указывается, в какие группы оно входит и где расположено. Для каждой модели считается фонд рабочего времени в часах на заданный период. При расчёте учитывается количество этого оборудования в подразделении и график его плановых ремонтов и обслуживания. Также, рассчитывается, сколько часов суммарно данное оборудование будет занято выполнением запланированных операций. В последней колонке отображается плановая загрузка.

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

Например, показать загрузку только по одному интересующему нас подразделению. Выберем первый участок двенадцатого цеха или второй участок седьмого цеха. Можно показать загрузку только интересующей нас Группы оборудования , например, Контрольной . Оборудование этой группы присутствует в разных подразделениях предприятия.

Чтобы быстро выявить потенциальные узкие места нашего производственного плана достаточно ввести пороговое значение загрузки . Введем 70%, считая, что оборудование, загрузка которого в плановом периоде превышает 70-80%, составляет так называемую группу риска. Скроем строки с меньшей загрузкой. В нашем примере только гидравлический координатно-револьверный пресс FINN-POWER загрузится более чем на 70%, т.е. для плана на март, он является тем самым узким местом.

Случайный выход из строя данного оборудования может привести к срывам исполнения если не всего плана, то многих заказов планового периода. Что обычно приводит не только к финансовым штрафным санкциям, но и к потерям не финансового характера. Например, это негативное событие может повлиять и на деловую репутацию предприятия.

Изучим, на какое оборудование также следует обратить особое внимание. Вводим пороговое значение 50% и просто раскрасим такие строки в выбранный цвет. К FINN-POWER добавился листогибочный пресс Amada , его расчётная загрузка составляет 57%. Все остальные цеха и оборудование в них загружены не так сильно и, скорее всего, не потребуют к себе повышенного внимания плановика.

Таким образом, используя модуль "", можно сделать следующие выводы:

Осуществим или не осуществим, принципиально, наш план. Критерием этой оценки будет превышение 100% загрузки по какой-либо модели. Если где-то загрузка более 100%, то не помогут никакие современные методы оптимизации производственного расписания. В этом случае надо увеличивать фонд работы оборудования, т.е. либо увеличивать временной период, либо нанимать дополнительный персонал, который будет трудиться во вторую смену, либо запускать рядом второй экземпляр оборудования.
План нашего примера не имеет ни одной позиции, у которой значение загрузки превышало бы 100%. Значит, по крайней мере, теоретически, заданный объём работ возможно выполнить в установленные сроки на имеющемся оборудовании. Осуществим или не осуществим план в реалиях нашего производства. Данная оценка также позволяет сделать вывод о выполнимости представленного плана, но не теоретически, как первая, а ближе к жизни и индивидуальным особенностям каждого производства. Например, очевидно, что загрузка оборудования в 99%, позволит выполнить план, только при условиях работы без сбоев, задержек и простоев, когда все системы продублированы и на предприятии работают роботы. В реальности же сбои и задержки регулярно случаются по разным причинам. То материал во время не привезли, то станок не наладили, то рабочий заболел, то авария в электросети и т.д. и т.п. Поэтому на каждом предприятии, даже для разных цехов и участков этого предприятия или разного вида работ этот критерий имеет различное значение. Например, для одного участка критической считается загрузка в 80%, а для другого – 60%.
Т.е. для каждого типа работ или участка можно выполнить сравнение с соответствующим индивидуальным пороговым значением, которое опытным плановикам обычно известно из практики. Соответствует ли структура существующего на предприятии станочного парка производственной программе. Такой вывод будет особенно полезен для предприятий, имеющих стабильную производственную программу, т.е. производственный план которых можно построить заранее, и он не подвержен сильным изменениям из месяца в месяц.
В нашем примере большинство моделей оборудования не загружено и на 40%, в то время как загрузка пресса FINN-POWER достигает критического значения. Если бы подобное положение дел имело место в серийном производстве, то для увеличения объема производства, нам следовало бы купить в первую очередь именно заготовительное оборудование.

Существует такая статистика: 20% кода выполняется 80% времени. Точность ее
вряд ли полностью соответствует реальному положению вещей, а вот общий смысл
довольно интересен: получается, что оптимизация всего приложения – занятие
неблагодарное и глупое, а реальные результаты может дать только оптимизация тех
20% приложения, которые выполняются дольше всего. Причем найти эти 20% не так уж
и сложно.

В этой статье мы будем говорить о профилировании . Если верить Википедии,
профилирование есть не что иное, как "сбор характеристик работы программы, таких
как время выполнения отдельных фрагментов, число верно предсказанных условных
переходов, число кэш-промахов и так далее". В переводе на русский язык это
означает "выявление узких мест программы" (или, как говорят англофилы,
"бутылочных горлышек"), а именно – всех тех участков кода, на которых программа
начинает "пробуксовывать", заставляя пользователя ждать.

Простейшее профилирование можно произвести голыми руками (и ниже я покажу,
как это сделать), однако лучше положиться на сообщество, представители которого
уже создали все необходимые инструменты. Первый и наиболее популярный инструмент
носит имя GNU Profiler (или gprof). Он испокон веков используется для
профилирования кода, генерируемого компилятором GCC. Второй - GNU Coverage
testing tool (gcov), утилита для более детального анализа производительности.
Третий - набор инструментов отладки и профилирования под общим именем Google
Performance Tools (сокращенно GPT). Ну а четвертый - это Valgrind, который хоть
и предназначен для поиска ошибок работы с памятью, но содержит в своем арсенале
ряд утилит для анализа производительности программ.

Начнем, как и полагается, с классики.

GNU Profiler

GNU Profiler (gprof) - один из старейших профайлеров, доступных для
операционных систем типа UNIX. Он входит в состав пакета gcc, и потому может
быть использован для профилирования программ, написанных на любом поддерживаемом
им языке (а это не только C/C++, но и Objective-C, Ada, Java).

Сам по себе gprof не является инструментом профилирования, а лишь позволяет
отобразить профильную статистику, которая накапливается приложением во время
работы (само собой разумеется, по умолчанию никакое приложение этого не делает,
но может начать, если собрать программу с аргументом "-pg").

Рассмотрим, как это работает в реальных условиях. Чтобы ощутить все
достоинства gprof, мы применим ее не к какому-нибудь абстрактному, искусственно
созданному приложению, а к самому настоящему повседневно используемому. Пусть
это будет gzip.

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

$ wget www.gzip.org/gzip-1.3.3.tar.gz
$ tar -xzf gzip-1.3.3.tar.gz
$ cd gzip-1.3.3

Устанавливаем инструменты, необходимые для сборки (в Ubuntu это делается
через инсталляцию мета-пакета build-essential):

$ sudo apt-get install build-essential

Запускаем конфигуратор сборки, передав в переменной окружения CFLAGS аргумент
"-pg":

$ CFLAGS="-pg" ./configure

Компилируем программу:

Теперь у нас есть бинарник gzip, способный вести статистику своего
исполнения. Каждый его запуск будет сопровождаться генерацией файла gmon.out:

$ ls -l gmon.out
-rw-r--r-- 1 j1m j1m 24406 2010-11-19 14:47 gmon.out

Этот файл не предназначен для чтения человеком, но может быть использован для
создания подробного отчета об исполнении:

$ gprof ./gzip gmon.out > gzip-profile.txt

Наиболее важная часть полученного файла показана на скриншоте.

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

Попробуем проанализировать отчет. Первой в списке идет функция deflate,
которая была вызвана всего один раз, но "сожрала" 29% всего времени исполнения
программы. Это реализация алгоритма компрессии, и, если бы перед нами стояла
задача оптимизировать gzip, мы должны были бы начать именно с нее. 22% времени
ушло на исполнение функции longest_match, но, в отличие от deflate, она была
вызвана аж 450 613 081 раз, поэтому каждый отдельный вызов функции занимал
ничтожное количество времени. Это второй кандидат на оптимизацию. Функция
fill_window отняла 13% всего времени и была вызвана "всего" 22 180 раз.
Возможно, и в этом случае оптимизация могла бы дать результаты.

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

Столбцы содержат следующую информацию (слева направо): индекс (index, он есть
только в первичной строке и, по сути, ничего не значит); процент времени,
который уходит на выполнение функции (% time); количество времени, затрачиваемое
на ее выполнение в секундах (self); количество времени, затрачиваемое на
выполнение функции и всех вызываемых ею функций (children); количество вызовов
функции (called) и ее имя (name).

Граф вызовов оказывается очень полезен, когда речь заходит об оптимизации
чужого кода. Становятся видны не только узкие места программы, но и вся логика
ее работы, которая может быть неочевидна при изучении исходников.

GNU Coverage testing tool

Кроме gprof, компилятор GCC имеет в своем составе еще один инструмент
профилирования, который позволяет получить более детальный отчет о выполнении
приложения. Утилита называется gcov и предназначена для генерации так
называемого аннотированного исходного кода, который напротив каждой строки
содержит количество ее исполнений. Это может понадобиться для более глубокого
изучения проблем приложения, когда функции, виновные в "тормозах", найдены, а
суть проблемы так и остается неясна (например, непонятно, какая строка в
многократно вложенном цикле внутри длиннющей функции несет ответственность за
аномальное падение производительности).

Gcov не может полагаться на статистику, генерируемую приложением при сборке с
флагом "-pg", и требует пересборки с флагами "-fprofile-arcs" и "-ftest-coverage":

$ CFLAGS="-fprofile-arcs -ftest-coverage"
./configure && make

$ ./gzip ~/ubuntu-10.10-desktop-i386.iso

Для каждого файла исходного кода будет сгенерирован граф вызовов, на основе
которого можно создать подготовленный для чтения человеком аннотированный
исходник:

$ gcov deflate.c
File "deflate.c"
Lines executed:76.98% of 139
deflate.c:creating "deflate.c.gcov"

Полученный в результате файл состоит из трех колонок: количество исполнений
строки, номер строки и сама строка. При этом для строк, не содержащих кода, в
первой колонке будет стоять знак минуса, а для строк, ни разу не выполненных -
последовательность шарпов: #####.

Google Performance Tools

Google Performance Tools (сокращенно GPT) - это разработка сотрудников Google,
предназначенная для поиска утечек памяти и узких мест приложений. Как и gprof,
GPT не является внешней по отношению к тестируемому приложению программой и
заставляет его самостоятельно вести статистику своего исполнения. Однако
используется для этого не внедренный на этапе сборки приложения код, а
библиотеки, которые могут быть прилинкованы к приложению во время сборки или
подключены при запуске.

Всего разработчикам доступно две подключаемых библиотеки: tcmalloc (которая,
по уверению авторов GPT, представляет собой самую быструю на свете реализацию
функции malloc, а также позволяет производить анализ того, как память
расходуется, выделяется и течет) и profiler, генерирующая отчет о выполнении
программы, наподобие gprof. Также в комплект входит утилита pprof,
предназначенная для анализа и визуализации накопленных данных.

Исходный код, а также rpm- и deb-пакеты всего этого набора доступны на
официальной страничке (code.google.com/p/google-perftools), однако я бы не
советовал заморачиваться с ручной установкой, так как набор доступен в
стандартных репозиториях Fedora и Ubuntu, и его можно установить одной простой
командой:

$ sudo apt-get install google-perftools \libgoogle-perftools0
libgoogle-perftools-dev

$ LD_PRELOAD=/usr/lib/libprofiler.so.0.0.0 \
CPUPROFILE=gzip-profile.log ./gzip \
/home/j1m/ubuntu-10.10-desktop-i386.iso

Однако сами гугловцы не советуют применять этот метод (очевидно из-за проблем
с программами, написанными на C++), рекомендуя линковать библиотеку во время
сборки. Что ж, не будем спорить.

Для экспериментов возьмем все тот же gzip и повторно пересоберем его,
слинковав бинарник с нужной библиотекой:

$ cd ~/gzip-1.3.3
$ make clean
$ ./configure
$ LDFLAGS="-lprofiler" ./configure && make

Теперь gzip вновь готов вести лог своего исполнения, но не будет делать этого
по умолчанию. Чтобы активировать профайлер, необходимо объявить переменную
окружения CPUPFOFILE и присвоить ей путь до файла профиля:

$ CPUPROFILE=gzip-cpu-profile.log ./gzip \
~/ubuntu-10.10-desktop-i386.iso
PROFILE: interrupts/evictions/bytes = 4696/946/91976

Как и в случае с gprof, получившийся отчет имеет бинарную форму и может быть
прочитан только с использованием специальной утилиты. В GPT ее роль выполняет
perl-скрипт pprof (в Ubuntu во избежание путаницы с другой одноименной утилитой
он переименован в google-pprof), который может генерировать не только таблицы и
аннотированные исходники на манер gcov, но и визуальные графы вызовов. Всего
существует 11 типов вывода этой утилиты, за каждым из которых закреплен
соответствующий аргумент командной строки:

1. Текстовый (--text) - таблица, подобная выводу gprof;
2. Callgrind (--callgrind) - вывод в формате, совместимом с утилитой kcachegrind (из пакета valgrind);
3. Графический (--gv) - граф вызовов, немедленно отображаемый на экране;
4. Листинг (--list=) - аннотированный листинг указанной функции;
5. Дизассемблированный листинг (--disasm=) - аннотированный
   дизассемблированный листинг указанной функции;
6. Символьный (--symbols) - листинг декодированных символьных имен;
7. Графический файл (--dot, --ps, --pdf, --gif) - граф вызовов, сохраняемый
   в файл;
8. Сырой (--raw) - подготовка бинарного файла профиля к передаче по сети
   (перекодируется с помощью печатаемых символов).

Наибольший интерес для нас представляют текстовый ("--text") и графический
("--gv") типы вызовов. Только они могут дать полную информацию о выполнении
приложения и всех его проблемных местах. Текстовый вывод генерируется следующим
образом:

$ google-pprof --text ./gzip gzip-cpu-profile.log

Как видно на скриншоте, вывод представляет собой таблицу с перечислением всех
функций и затрат на их исполнение. На первый взгляд она кажется очень похожей на
таблицу, генерируемую утилитой gprof, но это не так. Будучи всего лишь
библиотекой, GPT не может вести статистику исполнения программы так же детально
и точно, как это делает код, внедренный прямо в приложение. Поэтому вместо
записи всех фактов вызова и выхода из функций (поведение программы, собранной с
флагом "-pg"), GPT применяет метод, называемый сэмплированием. Сто раз в секунду
библиотека активирует специальную функцию, в задачи которой входит сбор данных о
том, в какой точке в текущий момент происходит выполнение программы, и запись
этих данных в буфер. По завершению работы программы из этих данных формируется и
записывается на диск профильный файл.

Именно поэтому в выводе pprof нет информации о том, сколько раз функция была
вызвана за время работы программы, или сколько процентов времени ушло на ее
исполнение. Вместо этого для каждой функции указывается количество проверок, во
время которых было выяснено, что в данный момент программа занималась
исполнением этой функции. Поэтому количество проверок, приведенное для каждой
функции, можно смело считать за общее время ее исполнения.

Во всем остальном таблица сильно напоминает вывод gprof: по функции на
строку, по показателю на столбец. Всего столбцов шесть:

1. Количество проверок для данной функции;
2. Процент проверок на все остальные функции программы;
3. Количество проверок для данной функции и всех ее потомков;
4. То же число в процентах от общего количества проверок;
5. Имя функции.

Поначалу такой подход к измерению времени исполнения кажется слишком
неточным, но если сравнить таблицы, полученные с помощью gprof, с таблицами
pprof, становится ясно, что они показывают одинаковую картину. Более того, GPT
позволяет изменить количество проверок на секунду времени с помощью переменной
окружения CPUPROFILE_FREQUENCY, так что точность можно увеличить в десять, сто
или тысячу раз, если того требует ситуация (например, если необходимо
профилировать исполнение очень небольшой программы).

Несомненным достоинством GPT перед gprof является умение представлять
информацию в графическом виде. Для активации этой функции pprof следует
запускать с флагом "--gv" (кстати, для показа графа будет использована
одноименная утилита):

$ google-pprof --gv ./gzip gzip-cpu-profile.log

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

Еще одно достоинство GPT заключается в способности использовать разные уровни
детализации для вывода данных, позволяя пользователю самому выбирать единицы
дробления. По умолчанию в качестве такой единицы используется функция, поэтому
любой вывод pprof логически разделен на функции. Однако при желании в качестве
единицы дробления можно использовать строки исходного кода (аргумент "--lines"),
файлы ("--files") или даже физические адреса памяти ("--addresses"). Благодаря
такой функциональности GPT очень удобно использовать для поиска узких мест в
больших приложениях, когда сначала ты анализируешь производительность на уровне
отдельных файлов, затем переходишь к функциям и, наконец, находишь проблемное
место на уровне исходного кода или адресов памяти.

И последнее. Как я уже говорил выше, GPT - это не только хороший профайлер,
но и инструмент для поиска утечек памяти, поэтому у него есть один очень
приятный побочный эффект в виде способности к анализу потребления памяти
приложением. Для этого приложение должно быть собрано или запущено с поддержкой
библиотеки tcmalloc, а в переменную HEAPPROFILE записан адрес для размещения
профильного файла. Например:

$ LD_PRELOAD=/usr/lib/libtcmalloc.so.0.0.0 \
HEAPPROFILE=gzip-heap-profile.log \
./gzip ~/ubuntu-10.10-desktop-i386.iso
Starting tracking the heap
Dumping heap profile to gzip-heap-profile.log.0001.heap (Exiting)

К полученному файлу будет добавлено окончание 0000.heap. Если натравить на
этот файл утилиту pprof и указать флаг "--text", она выведет на экран таблицу
функций и уровень потребления памяти каждой из них. Столбцы значат все то же
самое, что и в случае обычного профилирования, с тем исключением, что вместо
количества проверок и их процентных отношений таблица теперь содержит количество
потребляемой памяти и процент от общего потребления памяти.

При необходимости эту информацию можно получить в графическом виде, а также
изменить единицы дробления. Библиотека может быть настроена с помощью различных
переменных окружения, наиболее полезная из которых носит имя HEAP_PROFILE_MMAP.
Она включает профилирование для системного вызова mmap (по умолчанию GPT
собирает статистику только для вызовов malloc, calloc, realloc и new).

Пара слов о Valgrind

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

1. Cachegrind - позволяет собирать статистику по попаданию данных и
   инструкций программы в кэш первого и второго уровней процессора (мощный и
   сложный инструмент, который полезен при выполнении профилирования
   низкоуровневого кода).
2. Massif - профайлер кучи, схожий по функциональности с аналогом из пакета GPT.
3. Callgrind - профайлер, во многом похожий на таковой в gprof и GPT.

По умолчанию в качестве основного плагина Valgrind использует memcheck
(отладчик памяти), поэтому для его запуска в режиме профилирования необходимо
указать нужный плагин вручную. Например:

$ valgrind --tool=callgrind ./program

После этого в текущем каталоге будет создан файл с именем
callgrind.out.PID-программы, который можно проанализировать с помощью утилиты
callgrind_annotate или графической программы kcachegrind (устанавливается
отдельно). Я не буду расписывать формат генерируемых этими программами данных
(он хорошо представлен в одноименных man-страницах), скажу лишь, что
callgrind_annotate лучше запускать с флагом "--auto", чтобы он смог
самостоятельно найти файлы исходных текстов программы.

Для анализа расхода памяти Valgrind следует запускать с аргументом "--tool=massif".
После чего в текущем каталоге появится файл massif.out.PID-программы, который
может быть проанализирован с помощью утилиты ms_print. В отличие от pprof, она
умеет выводить данные не только в виде стандартной таблицы, но и генерировать
красивые ascii-art графики.

Выводы

Такие инструменты, как gprof, gcov и GPT, позволяют провести анализ работы
приложения и выявить все его узкие места вплоть до отдельной процессорной
инструкции, а подключив к процессу профилирования еще и Valgrind, можно добиться
удивительных результатов.

INFO

По умолчанию gprof не выводит профильной информации для функций
библиотеки libc, но ситуацию можно исправить, установив пакет libc6-prof и
собрав тестируемое с библиотекой libc_p: "export LD_FLAGS="-lc_p"".

Активировать профайлер GPT можно не только с помощью переменной окружения
CPUPROFILE, но и обрамив тестируемый участок кода функциями ProfilerStart()
и ProfilerStop(), которые объявлены в google/profiler.h.

WARNING

Из-за требований к безопасности GPT не сработает в отношении приложений с
установленным битом SUID.