Предотвращение ошибок пока екэ

Post Views:
4 293

Что означает “ПОКА-ЁКЭ”?

Термин “пока-ёкэ” переводится как “предупреждение ошибок” или “предупреждение отклонений”. Цель инструмента “пока-ёкэ” — предотвратить появление дефектов благодаря своевременному обнаружению, исправлению и устранению ошибок в первоисточнике проблем. Сам термин был придуман в 1960 — х годах японским инженером Сигэо Синго, одним из создателей производственной системы Тойота. Сам Сигэо Синго называл метод пока-ёкэ методом “защиты от дурака”. 

Инструмент “пока-ёкэ” позволяет улучшить производственные процессы с точки зрения качества. С помощью этого инструмента ошибки можно предотвратить, либо выявить их сразу после возникновения. Это позволяет не попадать дефектам на последующие производственные процессы. Более того, незамедлительное решение проблем позволяет значительно сократить время, по сравнению с тем, если бы пришлось искать причины дефекта или ошибки, обнаруженные на последнем этапе производственного цикла. 

Почему возникают ошибки?

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

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

1. Как и почему совершается ошибка?
2. Какие обстоятельства ведут к появлению ошибки?
3. Носит ли ошибка случайный характер или появляется систематически?
4. Как много людей совершают эту ошибку: все или трудности испытывает только один человек? 

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

Как внедрить пока-ёкэ в производственный процесс?

Пока-ёкэ можно внедрить в любой производственный процесс, где возникают ошибки. 

1. Необходимо определить место или зону, где могут возникать человеческие ошибки.
2. Определить источник каждой возможной ошибки.
3. Подумать, каким образом можно избежать возникновение каждой возможной ошибки. Рассмотреть возможность устранения действий или шагов, которые могут стать причиной ошибки. 
4. Если невозможно избежать возникновение ошибки, придумайте, каким тогда образом можно обнаружить возникающий дефект. 
5. Протестировать выбранные методы устранения ошибок и внедрить их в работу. 

Преимущества от внедрения пока-ёкэ

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

Примеры защиты от ошибок пока-ёкэ в повседневной жизни:

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

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

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

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

Система 5S и визуальный контроль в бережливом производстве

Концепция Канбан и система вытягивания на производстве

14 принципов менеджмента Тойота

Что такое поток единичных изделий и его отличие от массового производства

Разработка и внедрение карты потока создания ценности

Кайдзен — инструмент  непрерывного улучшения. Как внедрить кайдзен?

Стандартизация процессов и процедур

Генти генбуцу — концепция личного участия

Принцип Дзидока: остановка процесса ради встраивания качества

Андон и визуальный контроль на производстве

Всем привет! Я Алексей Грезов, разработчик Server Team Badoo. Мы в Badoo всегда стараемся сделать так, чтобы наш код было легко поддерживать, развивать и переиспользовать, ведь от этих параметров зависит, насколько быстро и качественно мы сможем реализовать какую-либо фичу. Одним из способов достижения этой цели является написание такого кода, который просто не позволит совершить ошибку. Максимально строгий интерфейс не даст ошибиться с порядком его вызова. Минимальное количество внутренних состояний гарантирует ожидаемость результатов. На днях я увидел статью, в которой как раз описывается, как применение этих методов упрощает жизнь разработчикам. Итак, предлагаю вашему вниманию перевод статьи про принцип «poka-yoke».

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

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

Итак, как мы можем предотвратить это? С помощью принципа «poka-yoke».

Что такое poka-yoke?

Poka-yoke – японский термин, который переводится на английский примерно как «mistake-proofing» (защита от ошибки), а в русском варианте более известен, как «защита от дурака». Это понятие возникло в бережливом производстве, где оно относится к любому механизму, который помогает оператору оборудования избежать ошибок.

Помимо производства, poka-yoke часто используется в бытовой электронике. Возьмём, к примеру, SIM-карту, которая благодаря своей асимметричной форме может быть вставлена в адаптер только правильной стороной.

Противоположным примером (без использования принципа poka-yoke) является порт PS/2, имеющий одинаковую форму разъёма и для клавиатуры, и для мыши. Их можно отличить только по цвету и поэтому легко перепутать.

Ещё концепция poka-yoke может использоваться в программировании. Идея в том, чтобы сделать публичные интерфейсы нашего кода как можно более простыми и понятными и генерировать ошибки, как только код будет использоваться неправильно. Это может показаться очевидным, но на самом деле мы часто сталкиваемся с кодом, в котором этого нет.

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

Прежде чем обсуждать конкретные меры, позволяющие сделать код более защищённым от ошибок, важно знать, что механизмы poka-yoke можно разделить на две категории:

• предотвращение ошибок
• обнаружение ошибок.

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

С другой стороны, механизмы обнаружения ошибок находятся вне нашего кода. Они контролируют наши приложения, чтобы отслеживать возможные ошибки и предупреждать нас о них. Примером может быть программное обеспечение, которое определяет, имеет ли устройство, подключённое к порту PS/2, правильный тип, и, если нет, сообщает пользователю, почему оно не работает. Такое ПО не могло бы предотвратить ошибку, поскольку разъёмы одинаковые, но оно может обнаружить её и сообщить об этом.

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

Примеры предотвращения ошибок

Объявление типов

Ранее известное как Type Hinting в PHP 5, объявление типов – это простой способ защиты от ошибок при вызове функций и методов в PHP 7. Назначив аргументам функции определённые типы, становится сложнее нарушать порядок аргументов при вызове этой функции.

Например, давайте рассмотрим уведомление, которое мы можем отправить пользователю:

<?php

    class Notification {
        private $userId;
        private $subject;
        private $message;

        public function __construct(
            $userId,
            $subject, 
            $message
        ) {
            $this->userId = $userId;
            $this->subject = $subject;
            $this->message = $message;
        }

        public function getUserId()
        {
            return $this->userId;
        }

        public function getSubject()
        {
            return $this->subject;
        }

        public function getMessage()
        {
            return $this->message;
        }
    }

Без объявления типов можно случайно передать переменные неверного типа, что может нарушить работу приложения. Например, мы можем предположить, что $userId должен быть string, в то время как на самом деле он может быть int.

Если мы передадим в конструктор неправильный тип, то ошибка, вероятно, останется незамеченной до тех пор, пока приложение не попытается что-то сделать с этим уведомлением. И в этот момент, скорее всего, мы получим какое-то загадочное сообщение об ошибке, в котором ничто не будет указывать на наш код, где мы передаём string вместо int. Поэтому обычно предпочтительнее заставить приложение сломаться как можно скорее, чтобы как можно раньше в ходе разработки обнаружить подобные ошибки.

В этом конкретном случае можно просто добавить объявление типов – PHP остановится и немедленно предупредит нас фатальной ошибкой, как только мы попытаемся передать параметр не того типа:

<?php

    declare(strict_types=1);

    class Notification {
        private $userId;
        private $subject;
        private $message;

        public function __construct(
            int $userId,
            string $subject, 
            string $message
        ) {
            $this->userId = $userId;
            $this->subject = $subject;
            $this->message = $message;
        }

        public function getUserId() : int
        {
            return $this->userId;
        }

        public function getSubject() : string
        {
            return $this->subject;
        }

        public function getMessage() : string
        {
            return $this->message;
        }
    }

Обратите внимание, что по умолчанию PHP попытается привести неверные аргументы к их ожидаемым типам. Чтобы этого не произошло и сгенерировалась фатальная ошибка, важно разрешить строгую типизацию (strict_types). Из-за этого объявление скалярных типов не является идеальной формой poka-yoke, но служит неплохой отправной точкой для уменьшения количества ошибок. Даже при отключённой строгой типизации объявление типов всё равно может служить подсказкой, какой тип ожидается для аргумента.

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

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

Объекты-значения

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

Когда аргументы имеют разные типы, PHP может предупредить нас о нарушении порядка аргументов, но это не cработает, если у нас несколько аргументов с одним и тем же типом.

Чтобы в этом случае избежать ошибок, мы могли бы обернуть наши аргументы в объекты-значения (value objects):

class UserId {
        private $userId;

        public function __construct(int $userId) {
            $this->userId = $userId;
        }

        public function getValue() : int
        {
            return $this->userId;
        }
    }

    class Subject {
        private $subject;

        public function __construct(string $subject) {
            $this->subject = $subject;
        }

        public function getValue() : string
        {
            return $this->subject;
        }
    }

    class Message {
        private $message;

        public function __construct(string $message) {
            $this->message = $message;
        }

        public function getMessage() : string
        {
            return $this->message;
        }
    }

    class Notification {
        /* ... */

        public function __construct(
            UserId $userId,
            Subject $subject, 
            Message $message
        ) {
            $this->userId = $userId;
            $this->subject = $subject;
            $this->message = $message;
        }

        public function getUserId() : UserId { /* ... */ }

        public function getSubject() : Subject { /* ... */ }

        public function getMessage() : Message { /* ... */ }
    }

Поскольку наши аргументы теперь имеют очень специфический тип, их почти невозможно перепутать.

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

Валидация

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

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

Чтобы предотвратить подобные ошибки, мы могли бы добавить некоторую валидацию в конструктор UserId:

class UserId {
        private $userId;

        public function __construct($userId) {
            if (!is_int($userId) || $userId < 0) {
                throw new InvalidArgumentException(
                    'UserId should be a positive integer.'
                );
            }

            $this->userId = $userId;
        }

        public function getValue() : int
        {
            return $this->userId;
        }
    }

Таким образом, мы всегда можем быть уверены, что при работе с объектом UserId он имеет правильное состояние. Это избавит нас от необходимости постоянно проверять данные на разных уровнях приложения.

Обратите внимание, что здесь мы могли бы добавить объявление скалярного типа вместо использования is_int, но это заставит нас включать строгую типизацию везде, где используется UserId. Если это не сделать, то PHP будет пытаться приводить другие типы к int всякий раз, когда они передаются в качестве UserId. Это может стать проблемой, так как мы могли бы, например, передать float, который может оказаться неправильной переменной, поскольку идентификаторы пользователя обычно не являются float. В других случаях, когда мы могли бы, например, работать с объектом Price, отключение строгой типизации может привести к ошибкам округления, поскольку PHP автоматически преобразует float-переменные в int.

Неизменяемость

По умолчанию объекты в PHP передаются по ссылке. Это означает, что, когда мы вносим изменения в объект, он мгновенно изменяется во всём приложении.

Хотя у этого подхода есть свои преимущества, он имеет и некоторые недостатки. Рассмотрим пример уведомления, отправляемого пользователю посредством SMS и электронной почты:

interface NotificationSenderInterface
    {
        public function send(Notification $notification);
    }

    class SMSNotificationSender implements NotificationSenderInterface
    {
        public function send(Notification $notification) {
            $this->cutNotificationLength($notification);

            // Send an SMS...
        }

        /**
         * Makes sure the notification does not exceed the length of an SMS.
         */
        private function cutNotificationLength(Notification $notification)
        {
            $message = $notification->getMessage();
            $messageString = substr($message->getValue(), 160);
            $notification->setMessage(new Message($messageString));
        }
    }

    class EmailNotificationSender implements NotificationSenderInterface
    {
        public function send(Notification $notification) {
            // Send an e-mail ...
        }
    }

    $smsNotificationSender = new SMSNotificationSender();
    $emailNotificationSender = new EmailNotificationSender();

    $notification = new Notification(
        new UserId(17466),
        new Subject('Demo notification'),
        new Message('Very long message ... over 160 characters.')
    );

    $smsNotificationSender->send($notification);
    $emailNotificationSender->send($notification);

Поскольку объект Notification передаётся по ссылке, получился непреднамеренный побочный эффект. При сокращении длины сообщения в SMSNotificationSender связанный объект Notification был обновлен во всём приложении, так что сообщение тоже было обрезанным, когда позже отправлялось в EmailNotificationSender.

Чтобы исправить это, сделаем объект Notification неизменяемым. Вместо того чтобы предоставлять set-методы для внесения в него изменений, добавим with-методы, которые делают копию исходного Notification перед внесением этих изменений:

class Notification {
        public function __construct( ... ) { /* ... */ }

        public function getUserId() : UserId { /* ... */ }

        public function withUserId(UserId $userId) : Notification {
            $c = clone $this;
            $c->userId = clone $userId;
            return $c;
        }

        public function getSubject() : Subject { /* ... */ }

        public function withSubject(Subject $subject) : Notification {
            $c = clone $this;
            $c->subject = clone $subject;
            return $c;
        }

        public function getMessage() : Message { /* ... */ }

        public function withMessage(Message $message) : Notification {
            $c = clone $this;
            $c->message = clone $message;
            return $c;
        }
    }

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

Однако обратите внимание, что в PHP очень сложно (если не невозможно) сделать объект по-настоящему неизменяемым. Но для того чтобы сделать наш код более защищённым от ошибок, будет достаточно добавить «неизменяемые» with-методы вместо set-методов, так как пользователям класса больше не нужно будет помнить о необходимости клонировать объект перед внесением изменений.

Возвращение null-объектов

Иногда мы сталкиваемся с функциями и методами, которые могут вернуть либо какое-то значение, либо null. И эти null’евые возвращаемые значения могут представлять проблему, поскольку почти всегда нужно будет проверять значения на null, прежде чем мы сможем что-то с ними сделать. Об этом опять же легко забыть.

Чтобы избавиться от необходимости проверки возвращаемых значений, мы могли бы возвращать вместо этого null-объекты. Например, у нас может быть ShoppingCart со скидкой или без:

interface Discount {
        public function applyTo(int $total);
    }

    interface ShoppingCart {
        public function calculateTotal() : int;

        public function getDiscount() : ?Discount;
    }

При вычислении конечной стоимости ShoppingCart перед вызовом метода applyTo нам теперь всегда нужно проверять, что вернула функция getDiscount(): null или скидку:

    $total = $shoppingCart->calculateTotal();

    if ($shoppingCart->getDiscount()) {
        $total = $shoppingCart->getDiscount()->applyTo($total);
    }

Если не выполнить эту проверку, то мы получим предупреждение PHP и/ или другие побочные эффекты, когда getDiscount() вернёт null.

С другой стороны, этих проверок можно избежать, если мы вернём null-объект, когда скидка не предоставляется:

class ShoppingCart {
        public function getDiscount() : Discount {
            return !is_null($this->discount) ? $this->discount : new NoDiscount();
        }
    }

    class NoDiscount implements Discount {
        public function applyTo(int $total) {
            return $total;
        }
    }

Теперь, когда мы вызываем getDiscount(), мы всегда получаем объект Discount, даже если скидка отсутствует. Таким образом, мы можем применить скидку к итоговой сумме, даже если её нет, и нам больше не нужна инструкция if:

    $total = $shoppingCart->calculateTotal();
    $totalWithDiscountApplied = $shoppingCart->getDiscount()->applyTo($total);

Опциональные зависимости

По тем же причинам, по которым мы желаем избежать null’евых возвращаемых значений, мы хотим избавиться и от опциональных зависимостей, просто сделав все зависимости обязательными.

Возьмём, к примеру, следующий класс:

class SomeService implements LoggerAwareInterface {
        public function setLogger(LoggerInterface $logger) { /* ... */ }

        public function doSomething() {
            if ($this->logger) {
                $this->logger->debug('...');
            }

            // do something

            if ($this->logger) {
                $this->logger->warning('...');
            }

            // etc...
        }
    }

Есть две проблемы:

1. Нам постоянно нужно проверять наличие логгера в нашем методе doSomething().
2. При настройке класса SomeService в нашем сервис-контейнере кто-то может забыть сконфигурировать логгер, или он может вообще не знать, что у класса есть возможность это сделать.

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

class SomeService {
        public function __construct(LoggerInterface $logger) { /* ... */ }

        public function doSomething() {
            $this->logger->debug('...');

            // do something

            $this->logger->warning('...');

            // etc...
        }
    }

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

Кроме того, мы избавились от необходимости постоянной проверки наличия логгера, что делает doSomething() более лёгким для понимания и менее восприимчивым к ошибкам всякий раз, когда кто-то вносит в него изменения.

Если бы мы захотели использовать SomeService без логгера, то могли бы применить ту же логику, что и с возвращением null-объекта:

$service = new SomeService(new NullLogger());

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

Public-методы

Чтобы сделать код проще в использовании, лучше ограничить количество public-методов в классах. Тогда код становится менее запутанным, и у нас меньше шансов отказаться от обратной совместимости при рефакторинге.

Свести количество public-методов к минимуму поможет аналогия с транзакциями. Рассмотрим, к примеру, перевод денег между двумя банковскими счетами:

$account1->withdraw(100);
$account2->deposit(100);

Хотя база данных с помощью транзакции может обеспечить отмену снятия денег, если пополнение не может быть сделано (или наоборот), она не может помешать нам забыть вызвать либо $account1->withdraw(), либо $account2->deposit(), что приведёт к некорректной операции.

К счастью, мы легко можем исправить это, заменив два отдельных метода одним транзакционным:

$account1->transfer(100, $account2);

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

Примеры обнаружения ошибок

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

Unit-тесты

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

Поскольку кто-то может забывать проводить unit-тестирование, рекомендуется автоматически запускать тесты при внесении изменений с использованием таких сервисов, как Travis CI и GitLab CI. Благодаря им разработчики получают уведомления, когда что-то ломается, что также помогает убедиться, что сделанные изменения работают так, как задумывалось.

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

Отчёты о покрытии кода тестами и мутационное тестирование

Поскольку мы можем забыть написать достаточно тестов, полезно при тестировании автоматически генерировать отчёты о покрытии кода тестами с помощью таких сервисов, как Coveralls. Всякий раз, когда покрытие нашего кода снижается, Coveralls отправляет нам уведомление, и мы можем добавить недостающие тесты. Благодаря Coveralls мы также можем понять, как меняется покрытие кода с течением времени.

Ещё один способ убедиться, что у нас достаточно unit-тестов, — использование мутационных тестов, например, с помощью Humbug. Как следует из названия, они проверяют, достаточно ли наш код покрыт тестами, слегка изменяя исходный код и запуская после этого unit-тесты, которые должны генерировать ошибки из-за сделанных изменений.

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

Статические анализаторы кода

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

Помимо анализаторов, встроенных в большинство IDE, в процесс сборки наших приложений можно включить сторонние и даже пользовательские анализаторы для выявления конкретных проблем. Неполный список анализаторов, подходящих для проектов на PHP, можно найти на GitHub.

Существуют также онлайн-решения, например, SensioLabs Insights.

Логирование

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

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

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

Не подавлять ошибки

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

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

Помимо error_reporting, важно всегда включать strict_types, чтобы PHP не пытался автоматически приводить аргументы функций к их ожидаемому типу, поскольку это может приводить к трудно обнаруживаемым ошибкам (например, ошибкам округления при приведении float к int).

Использование вне PHP

Поскольку poka-yoke скорее концепция, чем конкретная методика, её также можно применять в сферах, не связанных с PHP.

Инфраструктура

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

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

REST API

При создании REST API можно внедрить poka-yoke, чтобы упростить использование API. Например, мы можем убедиться, что возвращаем ошибку всякий раз, когда неизвестный параметр передаётся в URL или в теле запроса. Это может показаться странным, поскольку мы, очевидно, хотим избежать «поломки» наших API-клиентов, но, как правило, лучше как можно скорее предупреждать разработчиков, использующих наш API, о некорректном использовании, чтобы ошибки были исправлены на ранней стадии процесса разработки.

Например, у нас в API может быть параметр color, но кто-то, кто использует наш API, может случайно использовать параметр colour. Без каких-либо предупреждений эта ошибка может запросто попасть в продакшн, пока её не заметят конечные пользователи.

Чтобы узнать, как создавать API, которые не доставят вам хлопот, прочтите книгу Building APIs You Won’t Hate.

Конфигурация приложения

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

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

Предотвращение ошибок пользователя

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

Заключение

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

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

Чтобы ещё больше уменьшить количество ошибок, мы должны стремиться к тому, чтобы public-интерфейсы нашего кода были максимально простыми и понятными.

Большая часть несчастных случаев на производстве происходят из-за человеческого фактора: человек торопится, пытается сделать, как ему кажется, лучше, либо просто не знает, как работать с тем или иным оборудованием, и в результате получает травмы. А возможно ли организовать работу так, чтобы само оборудование исключало риск возникновения ошибки? Рассказываем в статье.

Обзоры, интервью, свежие новости и изменения в законодательстве — оперативно в нашем Telegram-канале. О самых важных событиях — в нашей группе ВКонтакте.

Человеческий фактор при возникновении несчастного случая

Одна из главных задач специалиста по охране труда — предотвращение возникновения на предприятии несчастных случаев и «почти происшествий» (near-miss).

Когда происходит несчастный случай, а в некоторых компаниях даже при возникновении near-miss, работодатель создает комиссию для расследования причин его возникновения. Согласно статистике Международной организации труда, 96% всех несчастных случаев происходят из-за человеческого фактора и лишь 4% — из-за опасных условий и неисправностей оборудования.

Для предотвращения повторения происшествия, как правило, реализуются различные мероприятия организационного характера. Наиболее распространённые:

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

Большинство из этих мероприятий направлено на изменение поведения человека на основе знаний и понимания рисков и опасностей. Но что делать, если обучение или инструктаж не даёт положительного эффекта? Тогда нужно работать с самим технологическим оборудованием, приёмами выполнения работ и рабочими местами. Такую работу можно организовать с помощью инструментов Poka Yoke.

Что такое Poka Yoke?

Инструменты Poka-yoke (читается как «пока ёкэ») — это приспособления и методы работы, которые помогают избежать ошибок, обусловленных человеческим фактором, или вовремя выявить их в процессе производства.

Подход, благодаря которому ошибки выявляются на уровне производства, а не результата, впервые был формально закреплён на заводах Toyota в Японии в 1960-х годах, и относился к контролю качества. Сигео Синго, эксперт в области производства, разработал концепцию Zero Defects, направленную на снижение производственного брака. Контроль качества продукции смещался с проверки готовой продукции на предупреждение брака на каждом отдельном этапе производства.

Позже подход, относящийся к контролю качества, стал распространяться и на охрану труда, получив название Poka Yoke (происходит от двух японских слов: poka — избегать, yokeru — ошибка).

В России этот термин ассоциируется с «принципом нулевой ошибки», ещё его называют «защитой от дурака», что переводится на английский как «foolproof». Обращались к нему ещё в Советском Союзе — об этом свидетельствует отрывок из утратившего силу ГОСТ 27.002-89, где поясняется термин «надёжность»: «Для характеристики отказоустойчивости по отношению к человеческим ошибкам в последнее время начали употреблять термин fool-proof concept».

На практике принцип Poka Yoke может применяться двумя способами:

1. Создание системы, которая будет предотвращать развитие неблагоприятной ситуации.
2. Создание системы, в которой полностью исключено возникновение ошибки (более предпочтительный способ).

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

Практика применения Poka Yoke

Примеры применения защиты от происшествий мы можем увидеть в повседневной жизни:

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

Стремясь обезопасить человека при выполнении работ, инженеры постоянно придумывают инновационные решения. Например, американский физик Стив Гасс в 1999 году изобрёл циркулярную пилу со стоп-механизмом Saw Stop, которая останавливается при касании с человеческой кожей в течение 5 миллисекунд.

Для обеспечения безопасности персонала на работе в компании Керри также внедрены инструменты Poka Yoke. Приведём некоторые из них.

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

Для перекрытия опасных участков пути на производстве установлены физические барьеры.

На оборудовании установлены специальные двери (ворота), которые открываются только в том случае, если оборудование отключено.

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

Как внедрить систему?

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

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

Замещение. Выбирается более надёжный процесс взаимен непредсказуемого путём роботизации или автоматизации.

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

Облегчение. Группировка шагов, визуальное упрощение механизмов/работ (цветовое кодирование, маркировка).

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

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

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

Алгоритм внедрения инструментов Poka Yoke на предприятиях

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

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

Poka-yoke (звучит как пока ёкэ) — забавный на слух японский термин, который обозначает один из инструментов бережливого производства. Оказывается, мы сталкиваемся с ним каждый день. Только на русском он звучит как «принцип нулевой ошибки» или «защита от дурака».

На английский poka-yoke дословно переводится как «avoid mistakes», т.е. «избегать ошибок». А на практике используется адаптированный перевод — mistake proofing или error proofing (защита от ошибок).

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

Устройства защиты от дурака предохраняют не просто от ошибок, а от ошибок, вызванных человеческим фактором:

• невнимательностью
• забывчивостью
• неосторожностью
• незнанием
• усталостью
• и даже саботажем.

Люди ошибаются, а poka-yoke приспособления не дают им допустить ошибку.

Принцип действия poka-yoke характеризуются:

Устройства poka-yoke работают по принципу pass no defect — не пропустить ни одного дефекта.

История создания методов poka-yoke

Poka-yoke призван устранить ошибки, основанные на человеческом факторе. Защита от ошибок использовалась на предприятиях в том или ином виде задолго до формирования концепции poka-yoke. Формализовали эту систему в Toyota.

Изобретатель методов poka-yoke — японский инженер Сигео Синго (1909-1990), эксперт в области производства и один из создателей производственной системы Toyota. Сигео Синго разработал подход Zero Quality Control (ZQC), или Zero Defects (ноль дефектов).

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

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

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

Poka-yoke или метод нулевой ошибки — один из ключевых аспектов ZQC. Система poka-yoke использует сенсоры или другие устройства, которые буквально не дают оператору совершить ошибку.

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

Poka-yoke не ищет виновных в ошибках, цель метода — найти и устранить слабые места в производственной системе, из-за которых ошибка стала возможной.

Уровни устройств poka-yoke

Способы защиты от дурака делятся на три уровня по возрастанию эффективности:

Принципы защиты от ошибок

Существует шесть принципов или методов защиты от ошибок. Они перечислены в порядке приоритета:

Основные методы poka-yoke

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

Контактные методы

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

Лучшие контактные методы — это пассивные устройства, такие как направляющие штыри или блоки, которые не дают неправильно разместить заготовки на конвейере.

Считывающие методы

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

Методы последовательного движения

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

Типы чувствительных устройств

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

Сенсоры физического контакта

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

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

Энергетические сенсорные датчики

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

Сенсор проверяет наличие крышек на бутылках. Если крышка отсутствует или плохо закручена, бутылка автоматически убирается с конвейера.

К другим типам энергетических сенсорных устройств относятся:

Сенсоры, которые определяют изменения физических условий

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

7 ключей к внедрению эффективной системы защиты от ошибок

Чтобы эффективно внедрить метод нулевой ошибки, нужно отталкиваться от следующих рекомендаций:

Poka-yoke устройства вокруг нас

Люди допускают ошибки не только на производстве, но и в процессе использования продуктов. Эти ошибки ведут, как минимум, к поломкам, как максимум, к возникновению серьезной опасности. Поэтому производители встраивают защиту от дурака в конструкцию своих изделий.

Poka-yoke в быту

Например, электрочайник отключится сам, когда вода закипит, благодаря датчику пара. Вы не забудете его выключить. Свисток на обычном чайнике для плиты — тоже что-то вроде poka-yoke приспособления.

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

Ребенок не попробует лекарство, которое упаковано в баночку со специальной защитой от детей.

Лифт автоматически откроет двери, если наткнется на препятствие при закрытии.

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

Poka-yoke в автомобиле

Современные автомобили просто напичканы устройствами защиты от дурака. Правда, они не такие дешевые, как предполагает концепция poka-yoke, но зато спасают жизни.

К ним относятся активные и пассивные системы безопасности, например:

Poka-yoke в программном обеспечении

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

Примерами защиты от дурака могут быть обязательные поля форм и поля с заданным форматом ввода данных.

Книги по теме

Zero Quality Control: Source Inspection and the Poka-Yoke System / Shigeo Shingo

Книга от создателя системы poka-yoke Сигео Синго, впервые опубликованная в 1986 году. В ней автор обосновывает важность применения устройств защиты от ошибок для достижения безупречного качества продукции. Он называет 112 примеров устройств poka-yoke, работающих в цехах. Внедрение этих устройств обошлось меньше $100.

Poka-Yoke: Improving Product Quality by Preventing Defects / Nikkan Kogyo Shimbun

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

Вердикт

Система poka-yoke — очередное гениальное изобретение японцев. За 30 лет устройства poka-yoke эволюционировали вместе с производственным оборудованием. Они перестали быть дешевыми, как гласит один из принципов концепции, но стали гораздо эффективнее.

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

Само понятие защиты от ошибок стало шире: специальные устройства, конструктивные особенности и просто предупреждения оберегают нас от ошибок в повседневной жизни.
Благодаря poka-yoke у нас определенно меньше проблем.

Предотвращение ошибок (пока-ёкэ)

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

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

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

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

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

Предотвращение ошибок снижает уровень стресса!

Рабочая инструкция

Системы защиты от ошибок (Poka Yoke)

1.ЦЕЛЬ

Установить порядок разработки и использования систем защиты от ошибок при выпуске продукции.

2.ТЕРМИНЫ, ОПРЕДЕЛЕНИЯ И СОКРАЩЕНИЯ

• Poka-Yoke (яп., произносится «пока-ёкэ»; рус. — защита от ошибок) — один из элементов системы бережливого производства, позволяющий операторам при работе избежать ошибок в результате невнимательности. (установка неправильной детали, пропуск детали, установка детали другой стороной и т.д.).
• НД — нормативный документ.
• ОГТ — отдел главного технолога.
• ООО — отдел обслуживания оборудования.
• ДР — дирекция по развитию.

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

3.ОПИСАНИЕ

Системы защиты от ошибок разделяют на:

• сигнализирующие (без остановки производства) — обнаруживающие ошибку и предупреждающие о ней, не разрешая осуществлять передачу дефектного изделия на следующую стадию производства;
• блокирующие (с остановкой производства) — не позволяющие совершить ошибку.

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

Исторически первый случай осознанного применения систем Poka Yoke — это изобретение ткацкого станка, который останавливался при обрыве нити, и таким образом не был способен производить дефектную ткань.

Другие примеры защиты от ошибок:

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

Рисунок 1 — пример устройства контактного типа для защиты от ошибок.

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

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

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

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

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

Места установки систем защиты от ошибок помечаются в карте потока процесса специальным значком «PY»

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

5.ССЫЛКИ

• СТП «Технологическая подготовка производства и управление технологической документацией»
• СТП «План управления»
• СТП «Порядок подачи, оценки и реализации кайдзен-предложений»
• CTП «FMEA»
• РИ «Определение ключевых характеристик продуктов и процессов»
• Ф «Карта потока процесса»
• Ф «5 почему»