Приложение В (справочное). Примеры использования для проектирования

Приложение В
(справочное)

Примеры
использования для проектирования

В.1 Использование перечней свойств в процессе проектирования

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

Рисунок В.1 - Использование типов LOP на отдельных этапах проекта

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

- заказчик должен иметь доступ к инструменту для обработки перечней свойств, например инструмент САЕ;

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

- заказчик вводит данные запроса в шаблон ввода инструмента. Обычно создается ALOP, OLOP и DLOP;

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

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

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

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

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

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

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

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

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

Рисунок В.2 - Обмен данными в технологическом процессе

На рисунке В.2 также показано, как обрабатываются сообщения, содержащие требуемые типы LOP, в рамках технологического процесса. Сообщение-запрос состоит из ALOP ₁, OLOP ₁ и DLOP ₁. Все три перечня должны быть включены в один файл. ALOP ₁ содержит информацию о том, что речь идет о запросе, а также данные об авторе сообщения; в нашем случае данные хотя бы одного контактного лица поставщика. OLOP ₁ содержит информацию об условиях эксплуатации, которые должны выполняться при проектировании запрошенного устройства. Владельцем данных OLOP ₁ является заказчик, поэтому он несет за них ответственность. Как правило, DLOP ₁ пуст, но у заказчика могут быть особые требования к устройству.

Ответное сообщение поставщика отправляется через другой файл. Оно состоит из ALOP ₂, DLOP ₂ и СLОР ₂. ALOP ₂ содержит информацию о том, что речь идет о предложении, а также данные об авторе сообщения; в нашем случае данные хотя бы одного контактного лица заказчика. Роль DLOP ₂ в данном сообщении - предоставить описание устройства, являющегося объектом предложения. Поставщик является владельцем данных, содержащихся в DLOP ₂, и несет за них ответственность. CLOP ₂ содержит коммерческую информацию о предлагаемом устройстве, а его владелец также является поставщиком. Заказчик не может менять содержимое DLOP ₂ и СLОР ₂ при использовании этих LOP для создания заказа.

LOP: DLOP ₁ и DLOP ₂, имеющие формат транзакционных данных, выполняют разные функции в рамках рабочего процесса, несмотря на то, что они создаются на основе одних и тех же структурных данных. То же самое относится к ALOP ₁ и ALOP ₂. Оба документа выполняют одну и туже роль (содержат данные заголовка сообщения), но имеют разное наполнение. Индексы 1 и 2 имеют такое же значение, как и на рисунке В.1.

Основными задачами LOP в рабочем процессе проектирования являются:

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

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

- заказ устройства через систему закупок;

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

- предоставление данных об устройстве для планирования с помощью инструментов САЕ.

Структурные данные о каждом типе устройства содержатся в LOP для этого типа устройства. Данные для этого LOP берут из OLOP или DLOP (см. также раздел 5). Структурные данные определяют последовательность свойств или блоков свойств и порядок структурных элементов, которые индексируются соответствующим образом.

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

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

Рисунок В.3 - Структурные и транзакционные данные в запросах и предложениях

Исходя из опыта работы, заказчик утверждает, что максимальная температура эксплуатации на его установке составляет 40 °C. Затем заказчик вводит это значение в OLOP. Кроме того, заказчику необходим аналоговый сигнал выхода тока с нижним значением, равным 4 мА, и верхним значением, равным 20 мА. Также указывают, что устройство рассчитано на максимальную рабочую температуру 80 °C. Заказчик указывает эти значения (транзакционные данные) в свойствах (структурные данные) "максимальная температура окружающей среды", "тип выхода", "минимальное значение диапазона выхода тока", "максимальное значение диапазона выхода тока", а также "верхний предел температуры для осуществления процесса". Заказчик также указывает значение "запрос" для свойства ALOP "тип документа".

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

Эта информация передается в виде транзакционного файла или другого файла похожего типа. В идеальном случае такой транзакционный файл должен создаваться и использоваться системами САЕ обеих сторон автоматически (см. В.2).

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

Предложение принимает форму LOP, состоящего из ALOP, DLOP и CLOP, и преобразуется в транзакционный файл в системе поставщика, а затем отправляется заказчику. После этого заказчик может полностью или частично импортировать этот LOP непосредственно в свою систему САЕ при условии, что система способна правильно интерпретировать транзакционный файл. Запрос заказчика и ответ поставщика представляют собой два разных файла. В приведенном примере заказчик получает следующую информацию:

- транзакционный файл содержит предложение;

- подтверждены требуемый тип сигнала выхода и диапазоны значений;

- у поставщика нет возможности обеспечить желаемый верхний предел температуры эксплуатации 80 °C. Он может предложить только устройство с предельной температурой 70 °C, о чем сообщает в DLOP. В этом случае заказчик может принять предложение либо поискать другого поставщика;

- из переданных дополнительных данных для этого примера было выбрано свойство "Вес", значение которого, декларируемое поставщиком, составляет 2 кг;

- срок доставки составляет 20 дней.

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

Таблица В.1 - Структурные и транзакционные данные для приведенного примера

Структурные данные						Транзакционные данные
ID	Предпочтительное имя	Единица	Формат		Дополнительные атрибуты	ID	Значение	Единица
По запросу
IEC-АВА274	Тип документа			Строка	(...)	IEC-ABA274	Запрос
IEC-АВА291	Максимальная температура окружающей среды	°С	Вещественное число		(...)	IEC-АВА291	40	°С
IEC-АВА169	Тип выхода		Строка		(...)	IEC-ABA169	Аналоговый выход тока
IEC-АВА190	Минимальное значение диапазона выхода тока	мА	Вещественное число		(...)	IEC-АВА190	4	мА
IEC-АВА183	Максимальное значение диапазона выхода тока	мА	Вещественное число		(...)	IEC-АВА183	20	мА
IEC-АВА292	Верхний предел температуры процесса	°С	Вещественное число		(...)	IEC-ABA292	80	°С
По техническому предложению
IEC-АВА274	Тип документа		Строка		(...)	IEC-АВА274	Предложение
IEC-АВА169	Тип выхода		Строка		(...)	IEC-АВА169	Аналоговый выход тока
IEC-АВА190	Минимальное значение диапазона выхода тока	мА	Вещественное число		(...)	IEC-АВА190	4	мА
IEC-АВА183	Максимальное значение диапазона выхода тока	мА	Вещественное число		(...)	IEC-ABA183	20	мА
IEC-АВА292	Верхний предел температуры процесса	°С	Вещественное число		(...)	IEC-ABA292	70	°С
IEC-ABA243	Вес	кг	Вещественное число		(...)	IEC-ABA243	2	кг
IEC-ABA127	Время доставки	День	Вещественное число		(...)	IEC-ABA127	20	День

В.2 Роль CAE и других систем

Для практического применения настоящего стандарта решающую роль играют системы САЕ, используемые заказчиком. Они обеспечивают требуемый уровень эффективности планирования и повышают его. Согласно настоящему стандарту системы САЕ, используемые в процессе планирования, должны соответствовать предварительным условиям производственного процесса, изображенного на рисунке В.2.

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

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

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

Рисунок В.4 - Обмен данными в ходе жизненного цикла устройства

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

Данные могут храниться с использованием других методов, например методов, приведенных в ГОСТ Р 55340. Если необходим обмен данными между базами данных, использующими указанный стандарт или другую модель, следует проводить сопоставление данных.