Лабораторна робота №01. Будова MERC-I5 і безпечна експлуатація

Мета: навчитися визначати межі та підсистеми MERC-I5; розпізнавати небезпечні стани без запуску механізмів; реалізувати відтворюваний передпусковий чекліст; перевірити, що неповні або суперечливі дані блокують допуск; оформити навчальний запис про інцидент без персональних і секретних даних.

Результати навчання та передумови

Після роботи студент уміє:

1. співвіднести компонент зі структурною підсистемою і потоком «сенсор — обчислення — виконавчий механізм — зворотний зв'язок»;
2. відрізнити штатну, контрольовану й аварійну зупинку;
3. назвати заборонені дії та умови негайної зупинки;
4. перевести навчальний сценарій у визначений безпечний стан на рівні mock-моделі;
5. довести тестами, що запуск не дозволяється за неповного чекліста.

Передумови: базове розуміння алгоритмів, уміння запускати Python-скрипт і прочитані правила доступу студентів. Досвід керування роботом не потрібний.

Середовище виконання

Необхідні знання та матеріали

Знання

• різниця між небезпекою, небезпечною ситуацією, ризиком та заходом зниження ризику;
• логічні значення, словники й списки Python;
• правило: невідома поза, стан або команда означає зупинку.

Обладнання

• фізичне обладнання для виконання не потрібне;
• для огляду під наглядом: знеструмлений або гарантовано нерухомий MERC-I5, доступ до E-Stop і викладач/оператор;
• не використовувати інструменти з комплекту й не відкривати корпуси.

ПЗ

• текстовий редактор;
• інтерпретатор Python; приклад використовує лише стандартну бібліотеку;
• переглядач Markdown із підтримкою Mermaid бажаний, але не обов'язковий.

Вхідні матеріали

• архітектура MERC-I5;
• апаратна частина і технічна специфікація;
• експлуатація й безпека;
• довідник DOBOT MG400;
• політика допуску.
• Parts Feeder - електромеханічний подавач деталей
• Power Hub модуль живлення
• Pusher, подавач деталей на конвеєр
• raspberry pi 5 8 gb RAM, 64 gb
• Гріпер
• Конвеєр з регульованою швидкістю
• кріплення центрування на конвеєр
• модуль пакування коробки
• Набір навчальних деталей
• Палетизаційне поле
• подавач картонних коробок
• робот-маніпулятор MG400
• сенсор на конвеєр

Ризики та правила безпеки

Ця ЛР не містить команд руху, EnableRobot, керування I/O, конвеєром, подавачем або грипером. Програмний «допуск» нижче є лише навчальною перевіркою повноти даних і не надає дозволу на фізичний запуск.

Основні ризики

Заборонені дії

• розбирати модулі, змінювати кабелі, живлення, COM, полярність або захист;
• входити в робочу зону, торкатися робота чи утримувати деталь під час роботи сценарію;
• обходити E-Stop, блокування або програмні межі;
• скидати невідому помилку чи автоматично відновлювати цикл;
• запускати рух локально, через Python, DobotStudio Pro, ROS 2, SSH або VPN без дозволу відповідальної за комплекс особи.

Умови негайної зупинки

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

Безпечний стан для цієї роботи

SAFE_FOR_OBSERVATION означає: рухові команди не формуються; програмні виходи в mock-моделі вимкнені; студент перебуває поза робочою зоною; помилка не скидається; результат передано оператору. Це не твердження про фактичний електричний стан MERC-I5.

Передпусковий чекліст фізичного контексту

Слово «передпусковий» тут означає підготовку даних до можливої майбутньої операторської перевірки, а не дозвіл на запуск.

• Є локальний уповноважений оператор і доступна затверджена інструкція.
• E-Stop доступний, а його фактичну дію перевірено за локальною процедурою.
• Зона вільна, її межі відомі й позначені.
• Кріплення, кабелі, інструмент і вантаж оглянуті.
• Початкова поза, координатна система, межі, швидкість і навантаження підтверджені.
• Зв'язок і стани перевірені без руху.
• Код пройшов позитивні, негативні та граничні mock-тести.
• Є спосіб негайної зупинки й журнал апробації.

Методичні вказівки й теоретичні відомості

1. Межі та підсистеми

До MERC-I5 належать механічна рама, MG400 із кінцевим інструментом, транспортна й подавальна периферія, сенсори, камери, Raspberry Pi, операторський інтерфейс і засоби безпеки. Робочий пристрій, DobotStudio Pro, VPN та зовнішні репозиторії є зовнішніми системами. Межа важлива: відмова зовнішнього сервісу не повинна робити фізичний стан невизначеним.

flowchart LR
    O["Оператор і правила допуску"] --> S["Сенсори та камери"]
    S --> C["Raspberry Pi: логіка і журнал"]
    C --> A["MG400 та периферія"]
    A --> F["Підтвердження стану"]
    F --> C
    E["E-Stop / апаратний захист"] -. "має пріоритет" .-> A
    C -->|"невідомо або тайм-аут"| Z["Безпечна зупинка й оператор"]

Рис. 1. Ілюстративний потік керування, підтвердження та безпечної реакції MERC-I5

2. Режими та зупинки

Кнопка E-Stop є stop category 1 та наголошує на ручному відновленні після усунення причини. Після її натискання у робота блокуются сустави, зупиняєтся виконання програми, та визначаєтся стан E-Stop. щоб його зняти потрібно відтиснути кнопку та дати команду роботу ClearAlarm()

3. Джерела

• Архітектура MERC-I5 — підтверджений перелік логічних підсистем і принципи інтеграції.
• Експлуатація й безпека — передувімкнення, запуск, умови зупинки та післяробочі дії.
• DOBOT MG400: локальний довідник — стислий конспект User Guide V1.7 із застереженнями щодо фактичної ревізії.
• Допуск студентів — дозволені й заборонені дії.

Хід виконання роботи

1. Побудувати карту компонентів і меж.
2. Провести read-only аналіз небезпек.
3. Сформувати передпусковий чекліст.
4. Запустити mock-валідатор.
5. Перевірити відмови та оформити журнал.

Виконання лабораторної роботи

Крок 1. Класифікувати компоненти

За специфікацією заповніть таблицю щонайменше для MG400, Raspberry Pi 5, двох конвеєрів, камер, сенсора, подавача, грипера й E-Stop: підсистема, вхід/вихід, джерело підтвердження, безпечна реакція при невідомому стані.

Код/команда: не потрібні; не оглядайте проводку під напругою.

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

Критерій правильності: кожен компонент має рівно одну основну роль, джерело стану або позначку «не підтверджено», а для виконавчого механізму вказано зупинку/блокування продовження.

Якщо результат не отримано: поверніться до docs/02-architecture.md і технічна специфікація.md; невідоме позначте як прогалину, не оглядайте клеми.

Крок 2. Побудувати карту небезпек

Для режимів «вимкнено», «очікування», «налагодження», «автоматичний цикл», «відмова зв'язку» наведіть небезпеку, потерпілу особу, можливу подію та реакцію. Це навчальний аналіз, не оцінка відповідності.

Код/команда: не потрібні.

Очікуваний результат: щонайменше п'ять сценаріїв, серед них неочікуваний рух, затискання, падіння деталі й невідомий стан.

Критерій правильності: реакція кожного сценарію не містить автоматичного продовження або самостійного скидання невідомої помилки.

Якщо результат не отримано: зупиніть аналіз на суперечності, запишіть джерела й зверніться до викладача; не перевіряйте гіпотезу на обладнанні.

Крок 3. Створити й запустити mock-чекліст

Збережіть код як lab01_checklist.py. Він не має апаратних імпортів, мережі чи фізичних виходів.

# safe-smoke
from __future__ import annotations

import json
from dataclasses import dataclass
from typing import Mapping

REQUIRED = (
    "operator_assigned",
    "zone_clear",
    "estop_procedure_available",
    "coordinates_confirmed",
    "speed_confirmed",
    "load_confirmed",
    "communication_read_only_checked",
    "mock_tests_passed",
)


@dataclass(frozen=True)
class Decision:
    permitted: bool
    state: str
    blockers: tuple[str, ...]


def evaluate_checklist(values: Mapping[str, object]) -> Decision:
    missing = [name for name in REQUIRED if name not in values]
    invalid = [name for name in REQUIRED if values.get(name) is not True]
    blockers = tuple(dict.fromkeys(missing + invalid))
    if blockers:
        return Decision(False, "SAFE_FOR_OBSERVATION", blockers)
    return Decision(False, "READY_FOR_OPERATOR_REVIEW", ("operator_authorisation",))


def incident_record(event: str, observed_state: str) -> dict[str, str]:
    if not event.strip() or not observed_state.strip():
        raise ValueError("event and observed_state must be non-empty")
    return {
        "event": event.strip(),
        "observed_state": observed_state.strip(),
        "reaction": "stop_outputs_and_require_operator_acknowledgement",
        "hardware_tested": "no",
    }


def smoke_test() -> None:
    complete = {name: True for name in REQUIRED}
    review = evaluate_checklist(complete)
    assert review.state == "READY_FOR_OPERATOR_REVIEW"
    assert review.permitted is False

    incomplete = dict(complete)
    incomplete["zone_clear"] = False
    blocked = evaluate_checklist(incomplete)
    assert "zone_clear" in blocked.blockers
    assert blocked.state == "SAFE_FOR_OBSERVATION"

    record = incident_record("sensor states disagree", "unknown")
    assert record["hardware_tested"] == "no"
    print(json.dumps({"decision": blocked.__dict__, "incident": record}, ensure_ascii=False))


if __name__ == "__main__":
    smoke_test()

python lab01_checklist.py

Очікуваний результат: один JSON-рядок зі станом SAFE_FOR_OBSERVATION, блокером zone_clear та hardware_tested: no.

Критерій правильності: процес завершується з кодом 0, а жодне розгалуження не повертає фізичний дозвіл.

Якщо результат не отримано: перевірте точність копіювання й кодування UTF-8; не замінюйте відмову валідатора ручним дозволом.

Крок 4. Виконати негативні та граничні перевірки

Змініть у копії словника одне значення на False, потім вилучіть один ключ і передайте порожній опис інциденту до incident_record.

python lab01_checklist.py

Очікуваний результат: неповний чекліст залишається заблокованим; порожній запис спричиняє ValueError у контрольованому тесті.

Критерій правильності: 100% відсутніх/хибних обов'язкових полів виявлено, фізичний дозвіл не формується.

Якщо результат не отримано: відновіть вихідний скрипт, додайте окремі assert і повторіть лише mock-тест.

Крок 5. Оформити навчальний запис про інцидент

Заповніть час за годинником середовища, спостережуваний стан, безпечну реакцію, джерела даних і наступне рішення оператора. Не записуйте ПІБ, IP-адреси, токени або ключі.

Код/команда: використайте incident_record або таблицю звіту; команда обладнанню не потрібна.

Очікуваний результат: запис відрізняє спостереження від припущення й прямо вказує, що апаратної перевірки не було.

Критерій правильності: усі поля заповнені; причина не оголошена встановленою без доказу; повторний запуск не пропонується.

Якщо результат не отримано: збережіть первинні дані без редагування, позначте стан unknown і передайте запис викладачу.

Сценарії перевірки

Таблиці вимірювань і метрики

Карта компонентів

Підсумок перевірки

Вимоги до звіту

Дотримуйтеся загальних вимог. Додатково включіть карту меж і компонентів, заповнений передпусковий чекліст, таблицю п'яти небезпек, текст коду, вивід smoke-тесту, один позитивний і два негативні сценарії, навчальний запис про інцидент та явну фразу «Фізичний рух і апаратна перевірка не виконувалися».

Критерії оцінювання

Критична умова: фізична команда, обхід блокування або вигаданий результат апаратного тесту означає, що робота не може бути зарахована до усунення порушення.

Контрольні питання

1. Де проходить межа MERC-I5 і які системи є зовнішніми?
2. Чому зупинений робот усе ще слід вважати готовим до руху?
3. Чим контрольована зупинка програми відрізняється від E-Stop?
4. Чому повний програмний чекліст не є дозволом оператора?
5. Які дані не можна зберігати в журналі або Git?
6. Яка реакція потрібна за невідомої пози чи суперечливих сенсорів?
7. Чому межі небезпечної зони не можна визначити лише максимальною досяжністю робота?
8. Які докази потрібні, щоб заявити про фізичну апробацію?

Висновки

У висновку зіставте мету з метриками: скільки компонентів і режимів класифіковано, які блокери виявили тести, як mock-модель забезпечила відмову за замовчуванням і які фактичні дані ще потрібні. Не робіть висновку про працездатність E-Stop або фізичну безпечність комплексу: в цій ЛР їх не перевіряли.