hothing писал(а):
Алексей, в том то и дело, что часто алгоритм работы агрегата/установки/процесса не зависит от средств реализации (ПЛК/ПК/Homo Sapiens).
На работе столкнулись с проблемой: часто необходимо управление агрегатом/установкой/процессом реализовать разными средствами (такая вот засада). В результате, у нас просто огромное количество реализаций одного и того же алгоритма для разных "сред", с отличиями (зависит от программиста).
Мне кажется - это тупик.
Ильченко Эдуард писал(а):
hothing писал(а):
Но все равно, у меня пазл не складывается!
Я тоже столкнулся с подобной проблемой.
Отголоски столкновения
здесь.
Аналогичный случай в нашей деревне (точнее оба случая).
Проблема в целом такая:
Параллельное, в общем случае, алгоритмическое обеспечение (подсистема алгоритмического обеспечения)
САПР автоматизированных технологических систем.
В предельно широкой интерпретации показателя автоматизации - от нуля и выше:
от ручных и механизированных рабочих мест и производственных подразделений (как объектов автоматизации)
до гибких (автоматизированных и роботизированных) производственных модулей и систем.
Это была реальная задача в конце перестройки, затем все это грохнулось (по понятным причинам),
сейчас теплится в учебном процессе и медленно снова реально надвигается.
Ждем-с. Бьем копытами.
В частности, в свое время я очень удивился, когда обнаружил:
обычная (ручная)
маршрутная и операционная технологияэто
специализированная форма алгоритмов - предписаний (описаний технологических процессов и операций), подлежащих выполнению.
Это как известный персонаж, который удивился, что говорит прозой.
У меня есть мечта.
Затеять
алгоритмический анализ (
алгоритмическую экспертизу - в терминологии автора Дракона) реальных технологий:
-- первичных (ручных) технологий как объектов алгоритмизации и автоматизации;
-- описаний технологий в условиях их автоматизации и роботизации.
Она, кажется, вот-вот на подходе.
Правда сам я не технолог, и есть проблемы, хотя имел когда-то механико-технологическое образование.
Проблемы такие, в частности.
------------------------------------
1) Простой пример - упрощенная запись токарной технологической операции:
Вложение:
ПредвПример-02.PNG [ 99.39 КБ | Просмотров: 18507 ]
-------------------------------------
1.1) Реальные технологии задаются маршрутными и операционными картами - в табличной форме.
Раньше, это была вполне читабельная (без умственного напряга) списочная табличная форма:
-- перечень операций технологического процесса или переходов технологической операции (с разными данными);
-- он дополняется технологическими эскизами.
В связи с задачами внедрения САПР технологических процессов появилась новая система стандартов.
Первоначально документация была очень универсальная и реальные технологии получались слабо заполненные.
Затем их уплотнили и получились довольно мудреные форматы заполнения.
Я в свое время не успел разобраться, но надо будет.
Вопрос № 1 - может быть у кого-то будут ссылки на примеры.
Как увязать такую техдокументацию с графическими схемами алгоритмов:
проще говоря -
куда вставлять Дракон-схемы и т.п.
-------------------------------------
1.2) Традиционная маршрутная и операционная технология (как алгоритмическая документация) - это линейные алгоритмы, в которых отражается не вся алгоритмическая информация.
Некоторые составляющие действия и переходы не указываются в операционной карте, в предположении, что рабочий знает, когда они необходимы, и умеет их выполнять, например:
• переключение режимов обработки перед выполнением основных переходов обработки;
• сопутствующий технический контроль результатов обработки детали по переходам:
• дополнительные действия при обнаружении исправимого или неисправимого брака – в этом случае формируется нелинейный последовательный алгоритм (если бы он явно оформлялся).
Вопрос № 2 - может быть у кого-то будут ссылки на примеры.
Нужно или не нужно
явно отображать эту информацию алгоритмами, например
в Драконе и т.п.:
в учебной или рабочей документации.
1.2.1) В частности, в отношении сопутствующего технического контроля.
В терминах
Эдуарда Ильченко традиционная технологическая документация - это "
нормальные алгоритмы"
здесь:
Цитата:
выкристализировалось понятие «нормализованный алгоритм»
(более точно «нормализованное описание алгоритма»).
Т.е. такое описание алгоритма, при котором схема явным образом описывает только действия,
которые выполняются при нормальной работе оборудования и при нормальных технологических условиях.
Вот это очень кстати, спасибо автору такой клисталлизации.
У меня лично это давно зудило, но пока руки не доходили заняться этим.
Идея очень подходящая по смыслу. Только предлагается различать:
--
нормальные или нормализованные алгоритмы -
по содержанию алгоритмических процессов:
это, как в данном случае - нормальные режимы работы и т.п.;
--
нормальные или нормализованные алгоритмы -
по форме представления алгоритмической информации:
например, нормальные алгорифмы (алгоритмы) Маркова.
Вопрос № 3 - может быть у кого-то будут соображения и ссылки на примеры:
- нужна ли
дополнительная полная алгоритмическая информация с учетом наличия и последствий технического контроля, например
в Дракон-схемах;
- как она сочетается с первичной
нормальной технологией:
какая-то иерархия?
---------------------------
2) Традиционная технологическая (алгоритмическая) документация обычно (или часто)
содержит
потенциальный (естественный, скрытый) параллелизм, который:
-- в ручных режимах не используется;
-- реализуется при автоматизации техпроцессов.
Правда необходимо при этом различать автоматизацию технологических и производственных процессов.
Но это уже другая тема.