Teamcenter MRO - IDEAL PLMService Management – управление структурой...

© 2011 Siemens Product Lifecycle Management Software Inc. Все права защищены. Siemens и логотип Siemens являются торговыми марками Siemens AG. www.siemens.com/plm 1

Siemens PLM Software (RU)

Teamcenter MRO® Teamcenter для поддержки процессов технического обслуживания, эксплуатации и ремонтов

13.07.2012


Оглавление

ОГЛАВЛЕНИЕ ................................................................................................................................................................. 2

1. ОСНОВНЫЕ СВЕДЕНИЯ ......................................................................................................................................... 3

2. ПРИНЦИПЫ ПОЛУЧЕНИЯ ЭКСПЛУАТАЦИОННОГО СОСТАВА ИЗДЕЛИЯ ............................................................. 4

3. ИДЕОЛОГИЯ TEAMCENTER MRO .......................................................................................................................... 7

4. ПРОЦЕСС, РЕАЛИЗОВАННЫЙ В TEAMCENTER MRO ........................................................................................... 10

5. ПРИЛОЖЕНИЯ TEAMCENTER MRO ..................................................................................................................... 12

6. ПРИЛОЖЕНИЯ TEAMCENTER, ОБЕСПЕЧИВАЮЩИЕ ИНФОРМАЦИОННУЮ ПОДДЕРЖКУ ПРОЦЕССОВ ТОИР .. 27


1. Основные сведения

Teamcenter MRO (Maintanance, Repair and Overhaul) – одно из направлений информационной поддержки жизненного цикла изделия в части управления процессами технического обслуживания, эксплуатации и ремонта (ТОиР), поддерживаемое PLM-системой Teamcenter с целью повышения эффективности следующих инженерных процессов:

As-Built Management – управление структурой изделия «как изготовлено»

Service Management – управление структурой изделия в эксплуатации

Service Event Management – управление сервисными событиями

Service Planning – планирование состава работ ТОиР

Service Request Management – управление запросами на проведение ТОиР

Service Scheduling – планирование проведения ТОиР

Рисунок 1 Teamcenter MRO


2. Принципы получения эксплуатационного состава изделия

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

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

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

Teamcenter MRO – это набор модулей, являющийся неотъемлемой частью PLM-системы Teamcenter, обеспечивающий поддержку инженерных процессов, связанных с подготовкой к эксплуатации и непосредственно эксплуатацией изделия. Модули Teamcenter MRO позволяют использовать как конструкторские составы изделий, так и технологические для разработки альтернативных эксплуатационных представлений и дополнять информационные объекты состава изделия логистической информацией (серийные номера, номера партий, физическое размещение узлов и деталей, ведение характеристик и т.п.). Эксплуатационный состав изделия может создаваться на основе родительского: конструкторского, технологического или иного созданного состава изделия, существующего на момент инициации создания эксплуатационного состава. Эксплуатационный состав изделия может включать в себя как весь перечень элементов изделия, входящих в родительский состав, так и не полный перечень, в случае, если не все элементы родительского состава подлежат эксплуатации. Кроме того обычно группировка узлов и деталей в эксплуатационном составе изделия при необходимости может отличаться от группировки элементов родительского состава.

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

Функционал Teamcenter, относящийся к задачам управления составами изделия в части управления вариантными опциями, применяемостью вхождений и правил модификаций позволяет добиться синхронности конфигурирования различных структур таким образом, что при конфигурировании одной структуры изделия (например, применении вариантной опции к конструкторскому составу «Модификация 1»), будут сконфигурированы все связанные с ней структуры. Возможность отслеживания изменений в конфигурациях базовых структур позволяет своевременно отражать их на альтернативных структурах изделия.

На рисунке 2 представлена модель получения эксплуатационного состава изделия из конструкторского состава.


А1000/А

Трактор

350-14060/А

Установка трансмиссии

140-f400001-11/А

Установка редуктора

привода насосов

S1000/А

Сервис трактора

140-f400001-23/А

Система

гидроуправления

331-47365/А

Сцепление

250-112190/А

Коробка передач

350-12105/А

Система ходовая

140-f10002/А

Мост передний

140-f20002/А

Мост задний

331-48737,38,39,40/А

Колеса 4шт

345-00060/А

Подвеска передняя

141-S10001/А

Подвеска задняя

141-K40001/А

Передача карданная

141-K40002/А


Модификация 1


S100/А

Сервис сцепления

331-47365/А

Сцепление

S350-14060/А

Сервис трансмиссии

S350-14060/А

Сервис ходовой

системы

S200/А

Сервис мостов

140-f10002/А


140-f20002/А


S500/А

Сервис карданной

передачи

141-K40001/А


141-K40002/А




S400/А

Сервис подвесок

345-00060/А


141-S10001/А


S300/А

Сервис колес

331-48737,38,39,40/А

Колеса 4шт

EBOM

(Конструкторский состав изделия)

SBOM

(Эксплуатационный состав изделия)

Конструкторская

сборка Эксплуатационная

сборка

Деталь/

Сборочная единица

Вариантные

условия

Рисунок 2 Получение эксплуатационного состава изделия

На примере виден переход элементов конструкторского состава изделия в эксплуатационный состав трактора. Например, система гидроуправления не входит в эксплуатационный состав, так как не обслуживается. Элементы, входящие в эксплуатационный состав изделия сгруппированы в новые эксплуатационные сборки в соответствии со спецификой их обслуживания. В соответствии с вариантным


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


3. Идеология Teamcenter MRO

В основе идеологии, реализованной в Teamcenter MRO, заложены создание и управление виртуальными нейтральными и физическими структурами изделия.

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

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

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

Схема получения и трансформации нейтральной структуры изделия в физическую структуру представлена на рисунке 3.

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

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


SBOM

(Физическая структура изделия

модификации 1)

SBOM

(Нейтральная структура изделия)

SBOM

(Физическая структура изделия

модификации 2)

S1000/А


S100/А


331-47365/А

Сцепление

S350-14060/А


S350-14060/А

Сервис ходовой

системы

S200/А


140-f10002/А


140-f20002/А


S500/А

Сервис карданной

передачи

141-K40001/А


141-K40002/А


S400/А


345-00060/А


141-S10001/А


S300/А


331-48737,38,39,40/А

Колеса 4шт

S1000/А


S/№ 033331

S100/А


S/№ 312010

331-47365/А

Сцепление

S/№ 312011

S350-14060/А


S/№ 312000

S350-14060/А

Сервис ходовой системы

S/№ 313000

S200/А


S/№ 313010

140-f10002/А


S/№ 313014

140-f20002/А


S/№ 313015

S500/А

Сервис карданной передачи

S/№ 313040

141-K40001/А



S/№ 313041

S400/А


S/№ 313030

345-00060/А


S/№ 313031

141-S10001/А


S/№ 313032

S300/А


S/№ 313020

331-48737,38,39,40/А

Колеса 4шт

S/№ 313026,17,18,19

S1000/А


S/№ 033332

S100/А


S/№ 3222000

331-47365/А

Сцепление

S/№ 322011

S350-14060/А


S/№ 322100

S350-14060/А

Сервис ходовой системы

S/№ 323000

S200/А


S/№ 323010

140-f10002/А


S/№ 323014

140-f20002/А


S/№ 323015

S500/А

Сервис карданной передачи

S/№ 323040

141-K40002/А



S/№ 323041

S400/А


S/№ 323030

345-00060/А


S/№ 323031

141-S10001/А


S/№ 323030

S300/А


S/№ 323020

331-48737,38,39,40/А

Колеса 4шт

S/№ 323026,17,18,19

Рисунок 4 Родительская нейтральная и дочерние физические эксплуатационные структуры изделий


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


4. Процесс, реализованный в Teamcenter MRO

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

цифровой макет изделия: полное описание модели изделия в электронном виде: (3D-модели, чертежи, структура изделия, характеристики элементов структуры изделия и т.п.);

доступность информации: предоставление доступа к информации сразу же после ее появления;

параллельный инжиниринг: выполнение процессов разработки и проектирования одновременно с моделированием процессов изготовления и эксплуатации.

Запуск тех или иных процессов, связанных с подготовкой к эксплуатации и непосредственно эксплуатацией изделия производится с использованием модулей Teamcenter MRO и ряда других компонентов Teamcenter. Возможность запуска того или иного процесса, связанного с подготовкой и проведением ТОиР, зависит от состояния цифрового макета на соответствующих стадиях его развития.

В соответствии с описанными выше принципами получения эксплуатационного состава изделия и идеологией Teamcenter MRO на основании конструкторского или технологического состава изделия средствами Teamcenter Multistructure Manager и других базовых компонентов платформы Teamcenter Foundation может быть подготовлен эксплуатационный состав изделия для работы в Teamcenter MRO.

На рисунке 5 представлен процесс управления изделием и его эксплуатацией.

Управление изделием и его эксплуатациейР

азр

або

тка

сер

висн

ого

п

лан

а

Уп

рав

лен

ие

и

здел

ием

Раб

ота

с

сер

висн

ым

и

зап

ро

сам

и

Пл

ани

ро

ван

ие

пр

ове

ден

ия

сер

висн

ых

раб

от

Оф

ор

мл

ени

е се

рви

сны

х р

або

т

Вы

по

лн

ени

е се

рви

сны

х р

або

т с

внес

ени

ем

соо

твет

ству

ющ

их

зап

исе

й

Service Planning

As-BuiltFoundation

Добавление логистической информации

Производство физического

изделия

Проектирование

Проектирование изделия

Service Data Management

Записи об эксплуатации

изделия

Обнаружение неисправностей

Ручное обновление

конфигурации

Автоматическое обновление

конфигурации

Разработка сервисного

плана изделия

Определение сервисных

требований и частоты их

выполнения

Выпуск рабочих карт/ рабочих

инструкций

Требование, связанное с неисправностью

Service Forecasting

Прогнозирование сервисных работ

Service Request Processing

Создание сервисного

каталога

Привязка сервисных

предложений к сервисным

требованиям

Создание сервисного

запроса

Планирование выполнения сервисного

запроса

Закрытие сервисного

запросаВыполнение работ не отслеживается

Сервисный запрос, связанный с неисправностью

Service Scheduling

Создание рабочего задания

Генерация нарядов на

работы

Выпуск нарядов на работы

Назначение ресурсов и

планирование сроков

выполнения работ

Оформление нарядов на

работы

Утверждение планируемых

работ

Внутреннее выполнение

Регистрация внешнего

сервисного события

Внешнее выполнение

Service Data Management

Service ForecastingВыполнение сервисного действия в

рамках наряда на работу

Выполнение сервисного действия в

рамках сервисного

события

Выполнение сервисного запроса в

рамках наряда на работу

Выполнение сервисного запроса в

рамках сервисного

события

Service Request Processing

Изготовление Сдача в эксплуатацию Сервис

В разработке



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


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

В случае использования расширения Service Event Management пользователи Teamcenter MRO получают возможность представлять каждое проводимое плановое или внеплановое сервисное мероприятие (ремонт, техобслуживание, инспекцию и т.п.) в виде отдельного сервисного события – объекта Teamcenter, содержащего исчерпывающую информацию о проведенной сервисной работе и включающего в себя информацию об обслуженном узле или детали, характере работы, затраченном на нее времени, дате начала и завершения, материальных ресурсах и другую полезную информацию.

Информация о выявленных неисправностях может использоваться для определения и корректировки сервисных требований к изделию. Средства модуля Service Planner позволяют планировать состав работ ТОиР для изделий. Средствами модуля возможно создавать сервисные требования к изделию с учетом периодичности их выполнения и необходимой квалификации сервисного персонала. Сервисные требования для изделия объединяются в рамках сервисных планов изделия. На основании сервисных требований в Service Planner можно выпускать типовые рабочие карты и инструкции.

Модуль Service Request Manager позволяет управлять запросами на проведение сервисных работ. В модуле реализован полный цикл создания, планирования, управления и закрытия сервисных запросов. Возможно создание сервисных запросов на основании информации о выявленных неисправностях. После выпуска в следующих версиях Teamcenter MRO нового модуля прогнозирования сервисных работ появится возможность создания сервисных запросов в соответствии с прогнозируемыми работами. Модуль управления сервисными запросами также позволяет создавать стандартные сервисные предложения для заказчиков и объединять их в рамках сервисных каталогов для обслуживаемых изделий.

Средства нового модуля Service Scheduler позволяют осуществлять планирование проведения работ ТОиР. Пользователи могут для конкретного физического изделия создавать рабочие задания на основании информации о выявленных неисправностях, сервисных требованиях, или планируемом выполнении сервисного запроса. После выпуска модуля Forecasting у пользователей также появится возможность создавать рабочие задания в соответствии с прогнозируемыми сервисными работами. Для рабочих заданий средствами данного модуля могут быть выпущены наряды на работы, а также назначены требуемые для выполнения работ материальные и человеческие ресурсы. Для всех типов работ планируются и задаются сроки их выполнения. После выхода в одной из следующих версий Teamcenter еще одного нового модуля Physical Service Planner у пользователей появится возможность автоматического создания нарядов на работы, требуемых ресурсов и перемещений изделия, узлов и деталей на основании сервисных планов и рабочих заданий.


5. Приложения Teamcenter MRO Менеджер «как изготовлено» (As-Built Manager)

Менеджер «как изготовлено» является средством создания и управления нейтральными и физическими структурам изготовленного изделия. Инструменты данного компонента позволяют выполнять следующие задачи:

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

оригинальных узлов и деталей; o управление перемещениями узлов и деталей (установка, демонтаж, замена) o идентификация каждого из одинаковых узлов и или деталей по месту их размещения в

изделии; o разнообразное визуальное отображение узлов и деталей с разными статусами

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

структуры изделия и входящих в него узлов и деталей; o сервис визуального и отчетного сравнения структур изделия между собой; o возможность 3D визуализации структуры изделия с входящими в нее узлами и

деталями o возможность импорта/экспорта данных в формате PLMXML

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

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

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

Рисунок 6 Ввод логистической информации

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


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

Рисунок 7 Создание партии

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

Рисунок 8 Назначение альтернативной детали

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


Рисунок 9 Установка детали на изделие

В менеджере «как изготовлено» предусмотрена возможность дублирования уже существующих физических структур изделия. Пример дублирования структуры приведен на рисунке 10.

Рисунок 10 Дублирование физической структуры изделия

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

Менеджер «как изготовлено» позволяет создавать и управлять ревизиями, как всего изделия, так и его отдельных узлов и деталей. Изделие, а также его отдельные узлы и детали могут быть выпущены в релиз. Кроме того в менеджере «как изготовлено» реализована возможность использования более сложных механизмов перебазирования и перестроения физических структур. На рисунке 11 представлен пример выпуска (релиза) физической структуры изделия.


Рисунок 11 Выпуск (релиз) физической структуры изделия

В Teamcenter MRO реализована возможность 3D-визуализации структур изделий. Если та или иная деталь на физическом изделии в данный момент не установлена, то ее не будет и при визуализации. Кроме того в менеджере «как изготовлено» реализована возможность сравнения структур изделия в различных сочетаниях, а настраиваемый визуально понятный интерфейс позволяет достоверно оценивать все различия в нейтральных и физических структурах. На рисунке 12 приведен пример визуализации и сравнения структур изделия.

Рисунок 12 Визуализация и сравнение структур изделия


Менеджер управления сервисом (Service Manager)

Менеджер управления сервисом расширяет возможности управления изделием в процессе его эксплуатации, добавляя к возможностям менеджера «как изготовлено» ряд дополнительных опций. Если средствами As-Built Manager можно создавать и управлять структурой «как изготовлено», то в модуле Service Manager ведется управление структурой «как эксплуатируется». При этом в менеджере управления сервисом реализована такая же схема работы с нейтральными и физическими структурами, как и в менеджере «как изготовлено».

Менеджер управления сервисом предназначен для выполнения следующих задач:

o все задачи, выполняемые в менеджере «как изготовлено»; o создание и ведение эксплуатационных характеристик изделия, узлов и деталей; o создание и управление статусами изделия, узлов и деталей; o создание физических локаций и управление перемещением изделия, узлов и деталей

между локациями; o создание и ведение групп однотипных физических активов; o ведение и просмотр истории эксплуатации и перемещений изделия, узлов и деталей

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

Выделяют четыре типа характеристик: характеристики жизненного цикла, наблюдения, даты и производные характеристики.

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

Характеристики наблюдения описывают разнообразные параметры, измеряемые в процессе эксплуатации и проведения работ ТОиР (температура, давление и т.п.).

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

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

На рисунке 13 приведен пример создания характеристики даты.

Рисунок 13 Создание характеристики даты

Менеджер управления сервисом позволяет управлять физическим расположением и статусами изделия, узлов и деталей.

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


Структура локаций может быть многоуровневой и содержать сублокации. К отдельным локациям могут быть привязаны расположенные там организации. Каждой локации присваивается выбранный тип (например, склад в Новосибирске, мастерская в Москве, подрядчик в Ростове и т.п.). На рисунке 14 представлен пример создания физической локации.

Рисунок 14 Создание физической локации

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

Рисунок 15 Создание статуса физического элемента

Таким образом, в любой момент жизненного цикла изделия менеджер управления сервисом обеспечивает получение достоверной информации о месте нахождения и статусе любого узла или детали, установленной или демонтированной с изделия, а также изделия в целом. В Service Manager доступна для просмотра вся история перемещений и статусов физических изделий, узлов и деталей.

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

На рисунке 16 представлен пример создания группы активов.


Рисунок 16 Создание группы активов

Управление сервисными событиями (Service Event Management - расширение для Service Manager)


Расширение Service Event Management предоставляет еще большие возможности в части автоматизации управления сервисными работами.

Расширение предназначено для выполнения следующих задач:

o создание и управление сервисными событиями; o объединение однотипных сервисных событий в группы; o выявление отклонений и несоответствий и применение корректирующих сервисных

событий; o отслеживание перемещений физических узлов и деталей как результата проведенных

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

Использование Service Event Management позволяет представлять каждое плановое или внеплановое сервисное мероприятие (ремонт, техобслуживание, инспекцию и т.п.) в виде отдельного сервисного события – объекта Teamcenter, содержащего исчерпывающую информацию о проведенной сервисной работе и включающего в себя данные об обслуженном узле или детали, характере работы, затраченном на нее времени, дате начала и завершения, материальных ресурсах, исполнителях работы и другую полезную информацию. В рамках сервисного события фиксируются все перемещения физических узлов и деталей, могут заноситься выявленные значения их характеристик. Для применения всех изменений в физической структуре изделия, вызванных наступлением сервисного события, оно должно быть утверждено. Процесс утверждения сервисного события реализован в Service Manager с помощью соответствующей функции. Пример создания сервисного события представлен на рисунке 17.

Рисунок 17 Создание сервисного события

Выявленные в рамках сервисных событий проблемы и неисправности могут быть оформлены в виде сервисных несоответствий, которые создаются в виде отдельных объектов Teamcenter и привязываются к сервисным событиям. В соответствии с идеологией, заложенной в Service Manager, для каждого выявленного сервисного несоответствия должно быть выполнено корректирующее действие, оформленное как дополнительное отдельное сервисное событие. Пример создания сервисного несоответствия представлен на рисунке 18.


Рисунок 18 Создание сервисного несоответствия

Типовые проблемы и неисправности могут быть оформлены в виде кодов ошибок. Коды ошибок создаются в Service Manager в виде отдельных объектов и могут использоваться при идентификации типовых проблем в рамках сервисных несоответствий.

Сервисные события можно помещать в сервисные группы, которые являются контейнерами отдельных сервисных событий, объединенных по тем или иным признакам. В рамках Service Manager возможно создание многоуровневой иерархической структуры сервисных групп и подгрупп с входящими в них сервисными событиями. На рисунке 19 приведен пример создания сервисной группы.

Рисунок 19 Создание сервисной группы

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


Планировщик состава работ ТОиР (Service Planner)

Service Planner позволяет управлять планированием состава сервисных работ для различных изделий.

Планировщик состава работ ТОиР предназначен для выполнения следующих задач:

o создание и управление сервисными планами для изделия, улов и деталей; o определение в рамках сервисных планов и управление сервисными требованиями, их

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

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

В основе методологии работы, заложенной в планировщике состава работ ТОиР, лежит понятие сервисных требований, предъявляемых к обслуживаемым изделиям. Сервисное требование имеет определенный тип (ремонт, инспекция и др.) и определяет, какие сервисные работы должны проводиться для того или иного изделия с какой периодичностью и с учетом требуемой квалификации персонала. В Service Planner сервисные требования могут быть логически увязаны между собой. Например, для выполнения требования А необходимо выполнить требование Б, или при выполнении требования С автоматически выполняется требование Б и т.п. После создания сервисные требования должны быть прикреплены к узлам и деталям нейтральной структуры изделия, для которой эти требования предназначены. Пример создания сервисного требования приведен на рисунке 20.

Рисунок 20 Создание сервисного требования

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


Рисунок 21 Создание периодичности выполнения сервисного требования

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

Рисунок 22 Создание рабочей карты

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


Рисунок 23 Создание сервисного плана

Менеджер управления сервисными запросами (Service Request Manager)

Менеджер управления сервисными запросами позволяет автоматизировать учет и управление всеми поступающими от заказчиков запросами на проведение сервисных работ.

Менеджер управления сервисными запросами предназначен для выполнения следующих задач:

o создание и управление сервисными каталогами; o создание в рамках каталогов стандартных сервисных предложений для заказчиков; o создание и управление запросами на проведение ТОиР; o учет заказчиков запросов и их дислокации; o назначение и учет се работ по запросам и исполнителей этих работ; o учет прогнозируемых и фактических стоимости и времени выполнения сервисных

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

кодов

Service Request Manager позволяет создавать сервисные каталоги и предложения для изделия в целом и для любого элемента нейтральной структуры изделия.

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

Рисунок 24 Создание сервисного предложения

Все сервисные предложения, относящиеся к одному элементу нейтральной структуры, помещаются в единый контейнер - сервисный каталог для этого нейтрального узла или детали. На рисунке 25 представлен


пример создания сервисного каталога.

Рисунок 25 Создание сервисного каталога

При обращении заказчика с просьбой о выполнении работ ТОиР в Service Request Manager необходимо создать сервисный запрос. Сервисный запрос должен содержать информацию обо всех работах, которые необходимо выполнить в соответствии с обращением заказчика. Сервисный запрос создается для конкретного физического изделия в целом, или входящих в него физических узлов и деталей. Функционал Service Request Manager позволяет разделять работы внутри основного запроса и включать их в отдельно созданные подзапросы. Для выполнения работ в рамках сервисного запроса возможно назначение исполнителей. Пример создания сервисного запроса приведен на рисунке 26.

Рисунок 26 Создание сервисного запроса

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

Рисунок 27 Создание карточек контакта и местоположения заказчика

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


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

Рисунок 28 Создание сервисного действия

Планировщик проведения ТОиР (Service Scheduler)

Планировщик проведения ТОиР позволяет определять объемы необходимых работ ТОиР, планировать сроки их проведения с учетом имеющихся материальных и человеческих ресурсов. Service Scheduler дает возможность отслеживать выполнение работ ТОиР и при необходимости корректировать планы проведения ТОиР.

Планировщик проведения ТОиР предназначен для выполнения следующих задач:

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

Ганта; o назначение исполнителей работ с учетом их текущей загрузки и квалификации; o управление материальными ресурсами для выполнения работ; o учет планируемой и фактической стоимости выполнения работ; o ведение и просмотр истории выполненных работ; o согласование и утверждение сервисных работ с использованием workflow; o доступ к эксплуатационной документации для выполнения работ

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

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


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

После создания структуры работ и соответствующего графика их выполнения в планировщике проведения ТОиР формируется структура планируемых работ ТОиР с отображением план-графике в виде диаграммы Ганта.

В Service Scheduler можно задавать зависимости между рабочими нарядами, а также между сервисными действиями. Эти зависимости отражаются на графике выполнения работ. На графике также можно создавать контрольные точки, использовать критические пути, а также выполнять другие действия, характерные для работы с диаграммами Ганта. Состояние выполнение рабочих нарядов и сервисных действий управляется с помощью статусов и реализованных в Teamcenter workflow.

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

В планировщике проведения ТОиР реализовано управление человеческими ресурсами, требующимися для выполнения работ ТОиР. Средствами Service Scheduler можно создавать структуры человеческих ресурсов с учетом квалификации персонала, специфики их работы и других особенностей. Исполнители могут назначаться на выполнение рабочих нарядов, сервисных действий и рабочих заданий в целом. При этом в Teamcenter отображается текущая загрузка отдельных специалистов и их квалификация.

В процессе выполнения работ Service Scheduler позволяет управлять стоимостью работ ТОиР, используя прогнозируемую и фактическую стоимость тех или иных этапов работ или в целом рабочего задания. Возможно использования различных механизмов расчета стоимости работ ТОиР.


6. Приложения Teamcenter, обеспечивающие информационную поддержку процессов ТОиР

Для обеспечения поддержки процессов, связанных с подготовкой к эксплуатации и непосредственно эксплуатацией изделия, в состав Teamcenter входят следующие компоненты:

Менеджер многовидовых структур (Multistructure Manager)

Эксплуатационный состав изделия может отличаться от конструкторского и технологического состава как входящими в него элементами, так и иной структурой входящих в него эксплуатационных сборок, составленных в соответствии с требованиями ТОиР. Именно такой преобразованный эксплуатационный состав изделия желательно использовать в Teamcenter MRO, как исходную нейтральную структуру.

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

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

o разработка и совместное управление связанными структурами данных (конструкторский или технологический состав изделия и эксплуатационный состав изделия и т.п.) в рамках одного контекста взаимодействия;

o объединение несвязанных структур данных в один информационный пакет с целью управления этими данными как единым целым;

o получение однозначного описания составов изделия, определенных в рамках информационного пакета, при помощи наложения вариантных опций и правил модификации спецификаций

Функциональные возможности Multistructure Manager позволяют:

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

созданные альтернативные структуры (например, эксплуатационный состав); o поддерживать в базовой структуре ссылки на компоненты, помещенные в

альтернативную структуру; o конфигурировать структуры данных по модификациям (ревизиям); o конфигурировать структуры данных по применяемости вхождений; o конфигурировать структуры данных по вариантным правилам; o отслеживать изменения в конфигурациях базовых структур и отражать их на

альтернативных структурах; o выполнять поиск компонентов в рамках информационного пакета, как по

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

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

Конструктор процессов и Просмотр процессов (Workflow Designer & Workflow Viewer)

При работе с эксплуатационными данными может возникнуть необходимость использования


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

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

Функциональные возможности модулей позволяют:

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

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

o автоматизировать действия, выполняемые над объектами при выполнении определенных процессов;

o описывать сложные процессы, состоящие из подпроцессов с неограниченной степенью вложенности;

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

автоматического запуска других этапов по истечении указанного срока или обеспечения кворума согласующих участников процесса;

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

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

получения необходимых отчетов; o обеспечивать интеграцию Workflow с электронной почтой

Построитель отчетов и Генератор отчетов (Report Generator & Report Builder)

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

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

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

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

Новые шаблоны отчетов можно создать посредством:

o встроенного средства преобразования XML в формат документов HTML или PDF на основе языка XSLT;

o встроенного средства экспорта данных в формат XML. В этом случае определение правил выгрузки данных производится в модуле Конструктор отчетов.

Управление контентом и документацией (Content & Document Management)

На этапе подготовки изделия к эксплуатации неотъемлемой частью этой работы является создание разнообразной эксплуатационной документации. Только при наличии у сервисных специалистов доступа к


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

Модуль управления контентом и документацией позволяет работать с различными типами контента и документации. Кроме того, модуль интегрирован со средством разработки интерактивной эксплуатационной документации Cortona3D. Cortona 3D предлагает инструментарий для разработки интерактивных 3D/2D каталогов деталей, руководств по обслуживанию и ремонту, обучающих курсов.

Интеграция Teamcenter и Cortona 3D позволяет внедрить процессы создания эксплуатационной документации в PLM-среду, где происходит разработка изделия и поддержка его эксплуатации. Благодаря синхронизации этих систем создание эксплуатационной документации начинается на этапе конструирования изделия, и в ней оперативно отражаются все инженерные изменения. В результате существенно сокращаются сроки подготовки документации, повышается ее качество, уменьшается риск использования устаревшей и противоречивой информации.

Teamcenter MRO - IDEAL PLMService Management – управление структурой...

Documents

Transcript of Teamcenter MRO - IDEAL PLMService Management – управление структурой...