fixik_papus (![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
fixik_papus) wrote2016-07-24 11:21 pm
fixik_papus) wrote2016-07-24 11:21 pm
Entry tags:
Человек и механизм. Часть 2.
В первой части мы посмотрели сатирический киножурнал.
Это, конечно, кино; но похожие события происходят и в реальной жизни.
Сравните с парочкой из "фитиля"...
Из заключения экспертной подкомиссии.
Материал отсюда. За наводку спасибо mik25.
А теперь вернемся на линию формовки конфет с начинкой.
После прошлого инцидента и проведенных мероприятий - все успокоились и расслабились.
И весьма напрасно.
Операторы были полностью уверены, что уж теперь-то все замечательно и можно не переживать.
Про всякие там новые наладочные режимы они были и вовсе не в курсе.
Потому что операторам их включать не положено. Отчет с дополненным мануалом был разослан всем заинтересованным лицам по списку, но операторов в списке том не было.
Тем не менее, у них возникли некоторые сомнения.
Но вот незадача: программист (не я, но рядом, посему тэг "накосячил") поленился и закрыл доступ в сервисное меню целиком. Потому что это ж на целых 15 минут быстрее - запаролить одну кнопочку, вместо кучи настроек.
Однажды после плановых работ - наладчики забыли отключить в настройках вновь сделанный "автономный режим работы" разливочной машины начинки.
При этом - отключается проверка не то что форм без шоколада, а вообще наличия форм :)
И никому об этом не сказали.
Прошло достаточно много времени. И вот как-то из-за очередной моргушки темперирующая машина шоколада вышла из режима. А входит она обратно в режим минут 20.
(почему вылететь из режима достаточно несколько десятков секунд, а обратно - десятки минут - это вопрос хороший и интересный, но другой).
Разливать нетемперированный шоколад можно, но бесполезно (все уедет в брак). Разливочная машина шоколада остановилась.
Описывать еще раз результат удара теми же граблями по тому же лбу смысла нет.
Зато есть смысл сделать выводы.
Первый и главный, и вообще универсальный. Делать нужно "как хорошо", а не "как быстро", "как дешево" или "как просто".
Вся эта экономия перекроется много раз первой же аварийной ситуацией.
Второй: не нужно считать всех операторов идиотами, а себя гением. Это не соответствует истине и не подтверждается практикой :)
Следствие: операторы должны всегда быть в курсе внесенных в оборудование доработок.
Третий: настройки должны быть доступны для просмотра всем, не только наладчикам. Кроме секретных, но таких очень немного.
Больше того: это на благо самим же наладчикам.
Потому что процент проблем, которые можно разрулить удаленно - возрастает. Добежать в цех через санпропускник - это минимум 5-7 минут.
Стало быть, коэффициент готовности растет (вместе с премией, ага).
Четвертый: отключение любой защиты, даже плановое - это само по себе потенциально аварийная ситуация. Об этом должно быть отдельное предупреждение, с квитированием. И желтый фонарь на сигнальной колонне. Вот сирена - это лишнее; я же сам ее и отключу, чтобы над ухом не верещала постоянно.
В данном-конкретном случае придумали и еще одну простую, но надежную блокировку: автономный режим можно включить только на остановленной линии; а запустить линию можно только при выключенной "автономке", как мы говорим.
Я весьма рад, что в комментариях собрался толковый народ, совершенно правильно предположивший место и способ размещения граблей :)
Виртуальную шоколадную медаль получает eddie-blackarch.
Будем надеятся, что теперь грабли если и не убраны, то по крайней мере, лежат зубьями вниз.
Хотя...
Хотя "ошибки в программах неисчерпаемы, как вселенная" (с).
Это, конечно, кино; но похожие события происходят и в реальной жизни.
Сравните с парочкой из "фитиля"...
Из заключения экспертной подкомиссии.
В 22.47 легли на курс 36о в точке - 44о 32,5 сев. широты, 37о 48,9 вост. долготы. По радиотелефону связались с ПРДС порта Новороссийск и получили информацию о п/х "Адмирал Нахимов", который прошел буи Пенайской банки, его курсе 160о и о просьбе пропустить его.
В это время на мостик поднялся капитан, которому была доложена обстановка и просьба. Капитан согласился и дал подтверждение п/х "Адмирал Нахимов".
Капитан Ткаченко В.И. встал к САРП (система автоматической радиолокационной прокладки курса) у и начал работу с ним с целью оценки ситуации расхождения с п/х "Адмирал Нахимов". В это время дистанция между судами составляла 7,2 мили.
Сосредоточив свое внимание на работе с САРПом, капитан Ткаченко полностью отключился от визуального контроля развивающейся обстановки, не предпринимал никаких мер, чтобы уступить дорогу п/х "Адмирал Нахимов" заблаговременно.
Вахтенный помощник Зубюк П.А. производил определение места судна и визуальное наблюдение за обстановкой, вел радиотелефонные переговоры с п/х "Адмирал Нахимов" и несколько раз напоминал капитану о режиме работы главного двигателя, готового к маневрам, давая понять, что можно уменьшить скорость движения, чтобы п/х "Адмирал Нахимов" прошел впереди по курсу на безопасном расстоянии.
Однако, продолжая работать только с САРПом, капитан не обращал внимания на информацию вахтенного помощника, не менял скорости и курса. Судно следовало курсом 36о полным ходом со скоростью 11,5 узлов на опасное сближение с п/х "Адмирал Нахимов".
Материал отсюда. За наводку спасибо mik25.
А теперь вернемся на линию формовки конфет с начинкой.
После прошлого инцидента и проведенных мероприятий - все успокоились и расслабились.
И весьма напрасно.
Операторы были полностью уверены, что уж теперь-то все замечательно и можно не переживать.
Про всякие там новые наладочные режимы они были и вовсе не в курсе.
Потому что операторам их включать не положено. Отчет с дополненным мануалом был разослан всем заинтересованным лицам по списку, но операторов в списке том не было.
Тем не менее, у них возникли некоторые сомнения.
Но вот незадача: программист (не я, но рядом, посему тэг "накосячил") поленился и закрыл доступ в сервисное меню целиком. Потому что это ж на целых 15 минут быстрее - запаролить одну кнопочку, вместо кучи настроек.
Однажды после плановых работ - наладчики забыли отключить в настройках вновь сделанный "автономный режим работы" разливочной машины начинки.
При этом - отключается проверка не то что форм без шоколада, а вообще наличия форм :)
И никому об этом не сказали.
Прошло достаточно много времени. И вот как-то из-за очередной моргушки темперирующая машина шоколада вышла из режима. А входит она обратно в режим минут 20.
(почему вылететь из режима достаточно несколько десятков секунд, а обратно - десятки минут - это вопрос хороший и интересный, но другой).
Разливать нетемперированный шоколад можно, но бесполезно (все уедет в брак). Разливочная машина шоколада остановилась.
Описывать еще раз результат удара теми же граблями по тому же лбу смысла нет.
Зато есть смысл сделать выводы.
Первый и главный, и вообще универсальный. Делать нужно "как хорошо", а не "как быстро", "как дешево" или "как просто".
Вся эта экономия перекроется много раз первой же аварийной ситуацией.
Второй: не нужно считать всех операторов идиотами, а себя гением. Это не соответствует истине и не подтверждается практикой :)
Следствие: операторы должны всегда быть в курсе внесенных в оборудование доработок.
Третий: настройки должны быть доступны для просмотра всем, не только наладчикам. Кроме секретных, но таких очень немного.
Больше того: это на благо самим же наладчикам.
Потому что процент проблем, которые можно разрулить удаленно - возрастает. Добежать в цех через санпропускник - это минимум 5-7 минут.
Стало быть, коэффициент готовности растет (вместе с премией, ага).
Четвертый: отключение любой защиты, даже плановое - это само по себе потенциально аварийная ситуация. Об этом должно быть отдельное предупреждение, с квитированием. И желтый фонарь на сигнальной колонне. Вот сирена - это лишнее; я же сам ее и отключу, чтобы над ухом не верещала постоянно.
В данном-конкретном случае придумали и еще одну простую, но надежную блокировку: автономный режим можно включить только на остановленной линии; а запустить линию можно только при выключенной "автономке", как мы говорим.
Я весьма рад, что в комментариях собрался толковый народ, совершенно правильно предположивший место и способ размещения граблей :)
Виртуальную шоколадную медаль получает eddie-blackarch.
Будем надеятся, что теперь грабли если и не убраны, то по крайней мере, лежат зубьями вниз.
Хотя...
Хотя "ошибки в программах неисчерпаемы, как вселенная" (с).
no subject
Ибо автомат не обрудован глупостью.
no subject
С идиотом порою не сладить матчасти.
no subject
no subject
Совершенно другая область.
no subject
no subject
no subject
no subject
no subject
no subject
а мне показалось это как раз образцовый случай кг/ам...
no subject
no subject
no subject
no subject
no subject
Вот в чем разница. Саму по себе программу контроллера протестировать можно и несложно. Тем более что программы очень простые и короткие (скажем, 7000 строк - это по меркам IT вообще мизер)
Но основная часть проблем возникает не из-за косяков в программе (хотя это тоже бывает, конечно).
А из-за ошибок в понимании технологии, физических процессов, происходящих в оборудовании, и так далее
К ним же стандартное (для IT) QA не прикрутишь вообще никак.
Как результат, основная задача программиста промышленной автоматики - вовсе не программировать (это маленькая и простая часть работы).
А разобраться, с помощью технолога, литературы и прочая - в том, как оборудование устроено, что в нем происходит, как оно может сломаться...
А "классического" (IT) программиста это вообще не волнует. Он может даже и не знать, а где, собственно, физически выполняется его программа.
no subject
в реальности же эти байки сочиняют лентяи программеры, которым "повезло" с начальниками неучами.
то, что программер не озаботился изучением девайса, для которого пишет код, это и есть самый страшный баг. второй самый страшный баг - отсутствие квалифицированного тестера, способного написать соответствуюлие тест-кейсы
no subject
Зная изнутри, что творится в ЖКХ - я не стану серьезно спорить с этим утверждением.
Классический (IT) программер вообще не изучает девайс, для которого пишет код.
Больше того, он может вообще не знать, где этот девайс находится и как выглядит.
Программирование системное, прикладное, embedded и промышленной автоматики - это совершенно разные области.
Тест-кейсы на алгоритмы и логику - ОК
Но кто и как сумеет написать тест-кейсы на тему ошибок персонала?
no subject
Любой тестировщик, это типовая задача. На ошибки персонала "чистые" IT систему тестируют постоянно. Конкретно в этом случае. Конкретно в этом случае кейсы формируются по сценарию "отказ датчика": наличие форм контроллируется датчиком. Что произойдет если датчик выдаст false positive или false negative сигнал? Грамотная декомпозиция на черные и белые ящики позволяет легко обрабатывать такие кейсы. Более того, для того чтобы их проверять, достаточно ревью алгоритма работы, даже запускать оборудование не обязательно.
Сложность промавтоматики только в неочевидных связях между оборудованием: отказала машина А и этот отказ неочевидным образом повлиял на машину Б. Например, случилась вибрация насоса, а датчика вибрации нет, гироскоп на соседнем оборудовании начал показывать лажу и в результате установка начала гнать брак. Если вибрация случается раз в сутки, в каком-нибудь переходном режиме, такую проблему не то что тестировать, ее ловить замаешься.
no subject
Это и есть КЛЮЧЕВОЕ отличие от IT
Второе отличие - "ревью алгоритма работы" ага, если он есть и правильный.
Реально на оборудовании, существующем в одном экземпляре, доведение алгоритма работы до правильного это постоянный и вечный процесс.
Для любого алгоритмического тестирования нужно корректное тех.задание и корректные наборы данных.
А если их нет?
no subject
Алгоритм по определению есть, как-то же вы настраиваете логику работы своих контроллеров. Как раз нормальный тестировщик тут бы помог извлечь алгоритм, в том числе и из голов инженеров, и придумать для него тест кейсы.
>Для любого алгоритмического тестирования нужно корректное тех.задание и корректные наборы данных. А если их нет?
Существуют техники тестирования, позволяющие обходиться без ТЗ: белый ящик, свободный поиск, fuzz testing и т.п. Наборы данных тестировщики умеют составлять самостоятельно.
Не нужно думать что в IT все здорово и правильно. Зачастую тестировщики приходят в проект с десятилетним легаси, когда уже все забыли что, как и почему должно работать, и тем не менее как-то умудряются проверять корректность изменений.
no subject
Если алгоритм есть - дальше все легко, просто и надежно.
А если нет - никакие методики тестирования не помогут.
Да, программа работает замечательно... а вот оборудование с ней работает - плохо.
no subject
если нет техзадания, тот, кто руководит всем проектом явно просит пинка под зад.
no subject
Программист системный, прикладной, эмбеддед и пром.автоматики - это 4 разных человека, никак не взаимозаменяемые. (хотя с последними двумя еще могут быть варианты)
В промышленном оборудовании - основная работа автоматчика и состоит в том, чтобы это ТЗ с алгоритмами, аварийными ситуациями и прочая правильно составить. Делается это в тесном взаимодействии с механиками, технологами и так далее.
Если это есть - собственно программирование дело недолгое и несложное. Программы реально простые; сотни, максимум - тысячи строк на контроллер обычно.
Такая вот специфика работы.
no subject
+++ Хех, мне приходиться все это совмещать :)) в той или иной степени.
Так вот соглашусь с Вами(поработав и там и там), в пром автоматике возможности тестов сильно ограничены, как достоверно сэмулировать поведение железа особенно некорректное?. А "классические" программисты в пром автоматику(ну или схожие задачи) иногда такое предлагают, что диву даешься. Например уже проехавшие машины как транзакцию "откатывать". У меня только один вопрос, а это как, бульдозером?
no subject
no subject
no subject
no subject
Или он их и не знал никогда.
И вообще никто не знал.
no subject
no subject
no subject
no subject
no subject
При том, что я вообще никого не баню. Максимум - вежливо прошу выяснять проблемы, скажем, российско-украинских отношений, в более подходящем для того месте
no subject
no subject
Я просто обожаю распутывать цепочки событий, приведшие к аварии. И очень часто диву даюсь "ну надо же вообще как это могло сложиться вместе и одновременно!"
И наоборот, продумывать "а что будет, если навернется вот это, а потом еще вот то, и вдобавок нажму не ту кнопочку?".
no subject
no subject
Боюсь, этот миф стремительно устаревает. Один из этапов создания программы - тестрование во всех возможных ситуациях. Если раньше это делали руками, то сейчас нанимают кодеров и те пишут автоматические тесты, проверяющие программу на все возможные и невозможные комбинации. Список ошибок отправляется разработчикам программ и у тех нет шансов выпустить программу с ошибкой.
no subject
А с железом все не так просто.
Вылезает какая-нибудь физическая бяка - и все тут
no subject
no subject