Лабораторна робота №02. Стандарти безпеки роботизованих систем та оцінювання ризику

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

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

Після виконання студент уміє:

1. пояснити різницю між законодавчою вимогою, стандартом типу A/B/C, оцінюванням ризику та оцінкою відповідності;
2. застосувати ітеративну логіку «межі — небезпеки — оцінка — зниження — перевірка» без оголошення непідтвердженого ризику прийнятним;
3. розділити вимоги до самого промислового робота й до інтегрованої роботизованої комірки;
4. сформулювати кандидатну функцію безпеки через тригер, реакцію, безпечний стан, умови відновлення та спосіб валідації;
5. проаналізувати одиничну відмову й показати, чому звичайне програмне дублювання не створює сертифіковану safety-функцію.

Передумови: виконана ЛР-01 або еквівалентне знання архітектури й правил доступу; базове володіння JSON/Python. Ця робота не надає кваліфікації фахівця з функціональної безпеки.

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

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

Знання

• терміни «небезпека», «небезпечна подія», «ризик», «залишковий ризик»;
• режими роботи та умови негайної зупинки з ЛР-01;
• словники, списки, винятки й assert у Python.

Обладнання та ПЗ

• фізичне обладнання не потрібне;
• текстовий редактор і Python зі стандартною бібліотекою;
• ліцензовані повні тексти стандартів — лише якщо їх законно надає заклад. Відкритих офіційних каталогових сторінок достатньо для цієї оглядової ЛР, але не для проєктування safety-функції.

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

• архітектура, експлуатаційні правила, довідник MG400 і політика допуску;
• офіційні сторінки нормативних документів у розділі «Джерела» нижче;
• шаблон реєстру небезпек із цієї роботи.

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

Нормативний огляд є навчальним, невичерпним і не є юридичною консультацією, оцінкою відповідності, CE-процедурою, сертифікацією або валідацією safety-функцій MERC-I5.

Ризики навчального процесу

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

• створювати реальну відмову, відключати канал, відкривати аварійний контур або перевіряти E-Stop;
• змінювати проводку, захист, координати, швидкість чи логіку відновлення;
• заявляти PLr, PL, SIL або SILCL для MERC-I5 без повного проєкту, розрахунку та валідації;
• автоматично скидати аварію чи виконувати рух «для підтвердження ризику».

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

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

Безпечний стан

Безпечний стан цієї ЛР: жодних фізичних виходів, запис позначено OPEN, непідтверджені заходи не зараховано, подальше рішення передано компетентній особі.

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

• Фізичний рух не входить до плану заняття.
• Огляд, якщо він є, дозволив локальний оператор.
• Студент не входить у небезпечну зону й не торкається обладнання.
• Версії джерел і дата доступу записані.
• Припущення відокремлені від підтверджених фактів.
• Кожна невизначеність блокує висновок про прийнятність ризику.

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

1. Нормативна ієрархія

Станом на 03.08.2026 офіційний консолідований текст Регламенту (ЄС) 2023/1230, з урахуванням corrigendum, установлює загальну дату застосування 20.01.2027. До 19.01.2027 для машин, що підпадають під право ЄС, продовжує застосовуватися Директива 2006/42/EC; конкретний перехідний випадок слід оцінювати юридично. Стандарти є технічними документами й самі по собі не визначають застосовність закону до конкретного стенда.

2. Ітеративний процес

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

flowchart TD
    B["Визначити межі та життєвий цикл"] --> H["Ідентифікувати небезпеки й неправильне використання"]
    H --> R["Оцінити ризик за затвердженою методикою"]
    R --> Q{"Потрібне подальше зниження?"}
    Q -->|"так"| D["Внутрішньо безпечне проєктування"]
    D --> G["Огородження та додаткові заходи"]
    G --> I["Інформація, навчання, залишковий ризик"]
    I --> V["Верифікація та валідація"]
    V --> B
    Q -->|"ні, з доказом"| C["Документований результат"]

Рис. 1. Ілюстративний ітеративний процес оцінювання та зниження ризику

Спочатку визначають межі використання, простору, часу й життєвого циклу. Далі системно шукають небезпеки в штатних режимах, обслуговуванні, відмовах і розумно передбачуваному неправильному використанні. Заходи розглядають у послідовності: усунення/зменшення небезпеки конструкцією; захисні й додаткові заходи; інформація для користувача. Інструкція не повинна замінювати конструктивний захист, який обґрунтовано потрібний.

3. Звичайне керування та функціональна безпека

Звичайна команда stop() може бути корисною для процесу, але safety-функція потребує специфікованого небезпечного стану, тригера, часу реакції, безпечного стану, заданої надійності, архітектури, діагностики, захисту від систематичних відмов і валідації. ISO 13849-1 не задає автоматично потрібний PLr для конкретної функції; IEC 62061 не робить звичайний PLC або Python safety-контролером. E-Stop є додатковим захисним заходом і не замінює основні захисти.

4. Поля навчального реєстру

5. Офіційні джерела

Дата доступу до всіх вебсторінок: 03.08.2026.

• Регламент (ЄС) 2023/1230, офіційний текст EUR-Lex і офіційне corrigendum — дата застосування 20.01.2027.
• Директива 2006/42/EC, EUR-Lex — машинне законодавство перехідного періоду; не поширювати на конкретний випадок без аналізу застосовності.
• ISO 12100:2010 — офіційний опис загальних принципів проєктування, оцінювання та зниження ризику.
• ISO 10218-1:2025, Edition 3, 2025-02 — офіційна сторінка вимог до промислових роботів як частково завершених машин.
• ISO 10218-2:2025, Edition 2, 2025-02 — офіційна сторінка інтеграції, введення в експлуатацію, використання, обслуговування й виведення з експлуатації роботизованих застосувань/комірок.
• ISO 13849-1:2023 — офіційний опис методології safety-related parts of control systems.
• ISO 13850:2015 — офіційний опис функціональних вимог і принципів E-Stop.
• IEC 60204-1:2016 та Amendment 1:2021 — офіційні сторінки загальних вимог до електрообладнання машин.
• IEC 62061:2021+AMD1:2024, consolidated version — офіційний опис вимог до safety-related control systems машин.

Повні ISO/IEC тексти захищені авторським правом. Для реального проєктування потрібен законний доступ до потрібних редакцій, національних впроваджень і гармонізованих переліків.

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

1. Визначити межі та режими системи.
2. Скласти реєстр небезпек.
3. Сформулювати кандидатні safety-функції.
4. Перевірити повноту записів кодом.
5. Проаналізувати одиничну відмову та залишкові прогалини.

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

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

Створіть бібліографічну таблицю: документ, редакція, офіційний URL, сфера, роль у ЛР, дата доступу. Окремо запишіть, що дата 20.01.2027 враховує corrigendum.

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

Очікуваний результат: дев'ять позицій із таблиці джерел; ISO 10218-1 і -2 не змішані.

Критерій правильності: усі URL належать EUR-Lex, ISO або IEC; перелік названо невичерпним; немає скопійованих розділів стандартів.

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

Крок 2. Визначити межі та небезпеки

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

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

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

Критерій правильності: кожен запис містить ланцюжок «небезпека — подія — особа — шкода — захід — перевірка»; припущення не позначені як наявний захист.

Якщо результат не отримано: звузьте сценарій, але не виключайте периферію з межі мовчки; зафіксуйте причину зміни.

Крок 3. Реалізувати валідатор реєстру

Збережіть код як lab02_risk_register.py. Це лінтер повноти, а не калькулятор допустимого ризику.

# safe-smoke
from __future__ import annotations

import json
from dataclasses import dataclass
from typing import Iterable

REQUIRED_FIELDS = (
    "id",
    "system_boundary",
    "life_cycle_phase",
    "hazard",
    "hazardous_event",
    "exposed_person",
    "possible_harm",
    "proposed_measure",
    "verification",
    "residual_risk",
    "status",
)
ALLOWED_STATUS = {"OPEN", "BLOCKED"}  # VALIDATED потребує реальних доказів.


@dataclass(frozen=True)
class Finding:
    record_id: str
    field: str
    message: str


def validate(records: Iterable[dict[str, object]]) -> list[Finding]:
    findings: list[Finding] = []
    seen: set[str] = set()
    for index, record in enumerate(records, start=1):
        record_id = str(record.get("id", f"row-{index}"))
        if record_id in seen:
            findings.append(Finding(record_id, "id", "duplicate id"))
        seen.add(record_id)
        for field in REQUIRED_FIELDS:
            value = record.get(field)
            if not isinstance(value, str) or not value.strip():
                findings.append(Finding(record_id, field, "missing non-empty text"))
        status = record.get("status")
        if status not in ALLOWED_STATUS:
            findings.append(Finding(record_id, "status", "must be OPEN or BLOCKED in this lab"))
    if not seen:
        findings.append(Finding("register", "records", "at least one record is required"))
    return findings


def completeness(records: list[dict[str, object]]) -> float:
    total = len(records) * len(REQUIRED_FIELDS)
    if total == 0:
        return 0.0
    filled = sum(
        isinstance(record.get(field), str) and bool(str(record[field]).strip())
        for record in records
        for field in REQUIRED_FIELDS
    )
    return round(100.0 * filled / total, 1)


def smoke_test() -> None:
    good = [{
        "id": "H-001",
        "system_boundary": "illustrative robot cell",
        "life_cycle_phase": "operation",
        "hazard": "unexpected mechanical movement",
        "hazardous_event": "command accepted while state is unknown",
        "exposed_person": "operator near the boundary",
        "possible_harm": "impact or crushing",
        "proposed_measure": "block commands and require operator review",
        "verification": "mock test: unknown state rejects command",
        "residual_risk": "not evaluated; factual assessment required",
        "status": "BLOCKED",
    }]
    assert validate(good) == []
    assert completeness(good) == 100.0

    bad = [dict(good[0], id="H-002", verification="", status="VALIDATED")]
    fields = {finding.field for finding in validate(bad)}
    assert fields == {"verification", "status"}
    assert validate([])[0].field == "records"
    print(json.dumps({"complete_percent": completeness(good), "negative_fields": sorted(fields)}, ensure_ascii=False))


if __name__ == "__main__":
    smoke_test()

python lab02_risk_register.py

Очікуваний результат: JSON із complete_percent: 100.0 і полями негативного тесту status, verification.

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

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

Крок 4. Сформулювати кандидатні функції безпеки

Для трьох найбільш критичних небезпечних подій опишіть: небезпечну подію; тригер; безпечну реакцію; максимальний час реакції (не підтверджено, якщо немає джерела); заборону автоматичного рестарту; потрібні докази валідації. Не призначайте PLr/SIL самостійно.

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

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

Критерій правильності: звичайну команду stop() не названо safety-функцією без доказів; невідомий час реакції явно блокує валідацію.

Якщо результат не отримано: поверніть статус BLOCKED і перелічіть потрібну схему, розрахунок та протокол.

Крок 5. Проаналізувати одиничну відмову

Оберіть одну відмову: залиплий сигнал, обрив каналу, зависання звичайної програми або втрата мережі. Побудуйте причинно-наслідковий ланцюжок та незалежний спосіб виявлення. Не створюйте відмову фізично.

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

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

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

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

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

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

Реєстр небезпек

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

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

Дотримуйтеся загальних вимог. Додатково подайте нормативну таблицю з датою доступу; межі обраного сценарію; реєстр мінімум із шести небезпек; три кандидатні safety-функції; аналіз одиничної відмови; код і вивід валідатора; усі тести; список припущень та фразу «Оцінка відповідності, PL/SIL і фізична апробація не виконувалися».

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

Безумовні недоліки: вигаданий PLr/SIL, непідтверджена юридична застосовність, копіювання захищеного тексту або фізичне створення відмови.

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

1. Чим відрізняються ISO 10218-1:2025 та ISO 10218-2:2025?
2. Чому ISO 12100 вимагає ітеративного процесу?
3. Яка дата загального застосування Regulation (EU) 2023/1230 після corrigendum?
4. Чому стандарт і законодавчий акт не є взаємозамінними?
5. Чому E-Stop не замінює огородження й оцінювання ризику?
6. Які дані потрібні для обґрунтування PLr або SIL?
7. Чим верифікація відрізняється від валідації?
8. Чому два звичайні програмні канали можуть мати спільну причину відмови?
9. Як враховують передбачуване неправильне використання?
10. Чому ця робота не є оцінкою відповідності MERC-I5?

Висновки

У висновку наведіть охоплені межі й фази, кількість небезпек, повноту реєстру, результати негативних тестів і найсуттєвішу невизначеність. Окремо поясніть, чому сформовані safety-функції залишаються кандидатами до появи схеми, розрахунків і валідації та чому фізична безпечність MERC-I5 цією роботою не підтверджена.