Настройки и роли

Здесь настраивают роли, их права и правила всей системы наряд-допуска.
Правки сохраняются автоматически. У каждой вкладки - своя «История изменений».
PTWHUB - гибкий конструктор: права каждой роли вы задаёте сами, под порядок своей компании. По умолчанию загружен международный пресет (готовый набор настроек) по признанным мировым нормам наряда-допуска - HSE HSG250.

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

Таблица работников: имя, логин, роль, зоны, статус, последний вход, действия
Статусы жизненного цикла: Приглашён (письмо отправлено, входа ещё не было - можно отправить снова или отозвать) → Активен → Приостановлен (временно, права заморожены) → Отозван (доступ закрыт навсегда, история сохранена). Каждая смена статуса записывается в «Историю изменений».

Роли площадки

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

Плитка «+ Добавить роль» - роль не зашита в код, это данные тенанта.

Матрица прав: роль x действие

Поставьте или снимите галочку - право реально переключается и сразу сохраняется как настройка тенанта (в демо - в браузер, localStorage), а запись «кто · что · когда» уходит в «Историю изменений». Текущая роль выделена.

🧪 Симулятор доступа: «сможет ли…»

Три поля - и система отвечает «сможет / не сможет» с раскрываемой цепочкой «почему»: при пяти слоях проверок (роль · зона · допуск · разделение обязанностей · статус) причина отказа неочевидна, симулятор её объясняет. У обычных PTW-систем такого окна нет.

Что доказывает эта матрица (аудит-пробел закрыт). Аудитор/регулятор видит аналитику, но не имеет ни создания, ни подписи, ни выдачи - только наблюдает. Заявитель создаёт наряд, но не может его сам выдать (разделение полномочий). Выдающий - единственный, у кого есть «Выдавать». HSE может закрыть и согласовать, но не выдать. Газоаналитик/наблюдающий по умолчанию не управляют нарядом - они вносят данные на своих экранах. Это и есть юридическая суть PTW, и она теперь редактируется под заказчика.
Движок «правила как данные» без кода.
Пороги газа, интервалы ре-теста и сроки тут - не вшиты в программу, а редактируются прямо здесь и применяются к нарядам. Нельзя сохранить опасное правило (например O₂ вне коридора 19-24%). Сохранённое правило версионируется: новые наряды берут новую версию, активные доживают на старой (аудит-пробел версионирования).
🧪 Когда нужны газ-замеры, а когда нет
Нужно: замкнутые пространства, огневые рядом с горючим, газоопасные, глубокие траншеи - там, где можно вдохнуть опасную атмосферу или есть риск взрыва.
НЕ нужно: открытая площадка без газа, работа на высоте, грузоподъём, замена светильника. Система сама показывает блок газа только у тех типов, где он положен (зашит в тип как данные).
⛏️ Пример настройки: «Земляные работы»
Нужно: любая копка глубже ~1.2 м или рядом с коммуникациями - требует схему подземных сетей, крепление стенок; для глубоких траншей - газ-замеры (скопление газа внизу).
НЕ нужно: поверхностная работа без выемки грунта (укладка плитки сверху, покос). Нажмите «?» - подробный разбор типа работ.

Каталог правил по типам наряда ядро

Всё ниже - переключатель или число, не текст. Обязательные требования включены по умолчанию (можно осознанно выключить). «Ролей» - сколько ролей задействовано в типе, «Показать» - живая связь с правами вкладки «Роли и доступ» (измените право там - здесь сразу другая сводка).

lvl - уровень согласования (1 - простой, 3 - самый строгий). Ре-тест - интервал повторного замера газа, «-» - типу газ не положен. JSA/LOTO/наблюдающий/фото - обязательные требования типа.
Тип нарядаРолейlvlРе-тест, минJSA+вложенияLOTOНаблюдающийФото

Маршрут согласования - по уровню (lvl)

Тип наряда наследует маршрут своего уровня (lvl - колонка каталога выше). Порядок шагов важен: следующая роль подписывает только после предыдущей. Список, не drag-drop (бюджет JS <50 КиБ).

Конфликты SIMOPS - пары типов, опасных рядом

Если на карте площадки одновременно активны два наряда из конфликтующей пары в одной зоне - движок подсвечивает конфликт (см. «Карта SIMOPS»). Пары - тоже данные тенанта, не зашиты в код.

Срок хранения (retention/WORM) по региону

Закрытый наряд хранится в режиме WORM (нельзя изменить/удалить) минимум N дней - у разных стран разные законные сроки, поэтому это данные по региону, а не один глобальный текст.

РегионСрок, днейСтатус значения

Пороги газ-контроля по типам наряда

Что значат пороги: O₂ - кислород, коридор нормы 19.5-23.5% (ниже - удушье, выше - риск возгорания); LEL - нижний предел взрываемости, держим <10% (запас до взрыва); H₂S - сероводород, ядовит, <10 ppm; CO - угарный газ, <25 ppm. Значения-ориентир из открытых EI/OSHA 1910/GB 30871 (не копия норматива). На внедрении сверяются с HSE-стандартом площадки NIOC.

Окно продления

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

Истёк ре-тест или срок - наряд автоматически приостанавливается до нового замера/продления (защита от просрочки).

Правило эскалации

Что значит: согласование висит дольше N часов - система сама уведомляет руководителя на уровень выше, чтобы наряд не «завис». Закрывает пробел «эскалация по таймауту» (фича 15).

Здесь настраивается политика электронной подписи - «чем и как подписывают».
Сам акт подписи происходит на экране наряда; тут - правила: какой метод обязателен на каждом шаге, какие условия безопасности должны быть выполнены до подписи, срок метки времени, ключи и юридическая привязка. Это данные тенанта, а не зашитый код. Отдельного права «подписывать» в матрице нет - кто подписывает, вытекает из прав выдачи, согласования и закрытия.

Сила метода подписи по шагам наряда

Чем ответственнее шаг, тем сильнее требуемый метод. ПИН - для низких шагов; на выдаче и закрытии - надёжная биометрия устройства (passkey) или рукопись с фото. Слабый метод на ответственном шаге система выбрать не даст.

Шаг нарядаМинимальный метод подписи
Создание заявки
Согласование
Выдача наряда
Приёмка исполнителем
Закрытие наряда
Почему passkey - сильнейший метод. Он привязан к устройству и биометрии (WebAuthn/FIDO2), не передаётся как пароль, не подсматривается через плечо. ПИН можно подсмотреть или передать - поэтому он запрещён на выдаче и закрытии. Рукопись + фото - для юрисдикций и подрядчиков, где привычна «живая» подпись.

🚦 Гейт безопасности - предусловия подписи

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

Как это защищает. Просрочен газ-тест, не наложена LOTO или нет пожарного поста - подпись выдачи физически невозможна, с понятной причиной отказа. Так подпись нельзя поставить «на автомате» в обход безопасности.

Метка времени, хранение и ключи

Доказуемость «когда и что подписано» и защита от подделки задним числом. Криптографию делает сервер; здесь - только политика.

Закрытый наряд с подписями уходит в неизменяемый WORM-архив; серверный ключ хранится в файле с правами 600 или SoftHSM, не в базе данных - иначе доступ к БД означал бы возможность подделать подпись.

Юридическая привязка

Какому правовому уровню соответствует подпись. Уровень выбирается под юрисдикцию площадки; полное обоснование и ссылки - в отчёте-спеке.

Честная граница. Не позиционировать подпись как «квалифицированную» (QES по eIDAS) - для этого нужен внешний доверенный удостоверяющий центр из списка ЕС, которого у нас в иранском контуре нет. Наш уровень - «защищённая» (Иран ECA) и «усиленная» (AdES): юридически значима и доказуема, но не приравнена к QES.
Связь с системой. Подпись синхронизирована с RBAC (кто вправе - производное от прав), «Движком правил» (маршрут и пороги гейта), уведомлениями (событие «ждём вашу подпись») и общей «Историей изменений» - отдельного журнала не заводим. Полную последовательность подписания по шагам, для мобильного и десктопа, можно посмотреть в живом симуляторе отчёта-спеки.
Здесь настраивается справочник активов - «как устроены теги и что идёт из коробки».
Сам реестр объектов, оборудования, инструмента и точек изоляции - в разделе «Объекты и оборудование». Тут - правила тенанта: формат тега, какие дефолтные наборы загрузить, откуда берётся «истина» по газ-порогам и кто вправе их менять. Это данные вашей компании, а не зашитый код.

Маска тега единицы

Формат уникального обозначения единицы. Возьмите признанный стандарт или задайте свой шаблон. Тег - это идентичность единицы, на которой стоит детектор SIMOPS, поэтому формат фиксируется один раз на площадку.

Пример: P-1203

A - буква, N - цифра, остальные символы (- = /) вставляются как есть. Дубли не допускаются: цифры нормализуются по кодпоинту (персидские ۲۰۰ и арабские ٢٠٠ сводятся к 200), поэтому «одинаковые на вид» теги не создают две единицы.

Дефолтные отраслевые наборы

Стартовое наполнение реестра «из коробки»: типовые единицы с уже привязанными опасностями, СИЗ и шаблонами изоляции. Включите подходящие вашей площадке - дальше пополняете своим (форма или импорт KKS/ISA-реестра).

В реестр загрузится: 46 дефолтных единиц. Это ускоряет старт: не заводить типовое оборудование с нуля. Уникальное для площадки добавляете сами.

«Хозяин истины» опасностей и газ-порогов

Откуда наряд берёт опасности и пороги газа единицы: ссылается на живую карточку реестра или копирует снимок. Отраслевой паттерн: флаги наследования на уровне атрибута.

В обоих режимах: ручная правка порога в конкретном наряде помечается замком (снапшот атрибута) и авто-обновление её не затирает; у закрытого наряда - неизменяемый снимок для аудита.

Кто вправе менять газ-пороги (RBAC)

Газ-пороги (LEL, O₂, H₂S) - safety-критичное поле: ошибка стоит жизни. Права на их изменение - отдельно от общего редактирования единицы.

Почему это здесь, а не в матрице RBAC. Общее право «редактировать оборудование» не должно автоматически давать право менять пороги газа - иначе кладовщик, ведущий тип насоса, мог бы занизить LEL. Поле выделено в отдельное право с 4-eyes.
Связь с системой. Настройки применяются к разделу «Объекты и оборудование», наследуются в наряд (опасности, газ, шаблон LOTO) и питают детектор SIMOPS (идентичность по тегу). Полный разбор модели, UX и рисков - в отчёте-спеке фичи (research/objekty-oborudovanie-research). Бэкенд (PostgreSQL, флаги INHERITEDFROMITEM / ITEMSPECVALCHANGED) - демо.
Кто вправе выдавать и принимать наряды - по типу работ и зоне.
Право занять роль в наряде (Выдающий, HSE, Газоаналитик, Пожарный наблюдающий и т.д.) даётся не «любому сотруднику», а компетентному и формально допущенному лицу: нужен действующий сертификат под этот тип работ и допуск к зоне. Если квалификация просрочена или отозвана - система снимает право автоматически и блокирует выдачу/приёмку наряда, где человек назначен на эту роль. Это требование HSG250 («competent person»), OSHA 1910.146 (authorized entrant/supervisor), NFPA 51B (PAI).
Таблица ниже - данные тенанта (кадровый учёт допусков), не HR-система: заносит и снимает допуск HSE-администратор на этой вкладке кнопками «+ Добавить человека» / «Снять допуск» в строке.
Зона:
Зелёный - допуск действует, янтарь - истекает скоро (предупреждение, ещё можно работать), красный - блок: квалификация просрочена/отозвана, право на роль снято. Демо-данные - только вымышленные персоны.
Сотрудник Роль в наряде Требуемая квалификация Обучение Статус допуска Что вправе делать
Блок при истечении - не «предупреждение, которое можно проигнорировать». Если у назначенного отвалилась нужная корочка, переход наряда «черновик -> выдан» структурно не происходит (guard в жизненном цикле, см. карточку наряда). Активный наряд в поле система не аннулирует молча - эскалирует ответственному (HSG250: решение о приостановке - за компетентным лицом, не за скриптом). Ежедневный фоновый скан шлёт предупреждение за N дней до истечения через локальный SMS-шлюз региона.
Где физически живут данные нарядов.
Это критично для нефтегаза - и в Иране, и в странах Залива, и в РФ данные нельзя класть в зарубежное облако: санкционные провайдеры (AWS/Vercel/Azure) отрезают Иран, плюс требование держать данные критической инфраструктуры внутри страны действует параллельно в нескольких юрисдикциях. Поэтому продукт ставится на сервер заказчика (on-premise / self-host, «свой контур»), и при этом тот же самый образ умеет работать общим SaaS («облако» - когда несколько заказчиков делят один сервер вендора) - разница только в переменных окружения, без форка кода.

Три способа поставки из одной кодовой базы

🏭 On-premise (dedicated) для крупных

Выделенный контур внутри сети оператора (для НПЗ, Нацинфосети Ирана)
  • Контейнеры Docker (упаковка приложения, чтобы ставить одинаково на любой сервер) ставятся на сервер/ЦОД заказчика, изолированная сеть, без выхода наружу.
  • Данные нарядов не покидают предприятие и страну - санкции и комплаенс соблюдены.
  • Вход через учётные записи заказчика (SSO / LDAP), интеграция с его ERP и датчиками газа по API.
  • Один тенант на контур; режим TENANCY_MODE=dedicated в .env (файл настроек сервера).

☁️ Общий SaaS (shared) для мелких

Много операторов в одной базе на иранском/российском хостинге (не AWS/Vercel)
  • Тот же Docker-образ, режим TENANCY_MODE=shared.
  • Изоляция тенантов на уровне самой БД (PostgreSQL Row-Level Security, «строчная защита» - каждый запрос к базе автоматически фильтруется по тенанту): даже забытый WHERE в коде не отдаст чужие данные.
  • Каждый оператор и его площадки строго разделены (мультитенантность), конфиги форм - тоже данные тенанта.
  • Быстрый старт без своего ЦОД, оплата по подписке.

🇷🇺 Облако в РФ п.11 брифа

Российский хостинг для заказчиков, которым нужны данные внутри РФ, не Ирана
  • Тот же образ, тот же принцип изоляции, что и общий SaaS - меняется только страна размещения.
  • Годится, когда заказчик - российская или СНГ-компания, а не иранский НПЗ.
  • ⚠ Юрисдикция и конкретный хостинг - ориентир, юридически не проверено (как и OFAC-статус любого шлюза/провайдера - проверяется отдельно перед каждым внедрением).

Различие режимов - только переменные окружения (.env) и compose-профиль (набор Docker-контейнеров). Это и есть «одна кодовая база -> SaaS и self-hosted» (фича 20, паттерн Microsoft Deployment Stamp).

Как заказчик входит и как обмениваются данные

Сотрудник НПЗ
браузер / PWA
-> SSO / LDAP
учётка заказчика (Keycloak)
-> ptwhub
Docker на сервере
-> PostgreSQL
наряды (RLS по тенанту)
-> SeaweedFS
файлы (self-host, без AWS)
Вход (SSO/LDAP)Сотрудники логинятся своими корпоративными учётными записями через Keycloak (единый вход, протоколы OIDC/SAML) или LDAP/Active Directory заказчика - не заводим отдельные пароли. Self-hosted, не Auth0 (Auth0 недоступен Ирану).
Если нет ни Keycloak, ни готового LDAP/AD - крайний случай, локальные учётки в самом ptwhub (без SSO, но работает).
Обмен по APIИнтеграции (ERP, датчики газа, кадры) идут через REST API (стандартный протокол обмена данными между системами) внутри периметра заказчика. Наружу в санкционные сервисы продукт не ходит.
Что если нет интеграции: наряд заполняется вручную, без автоподстановки из ERP/датчиков - работает, но медленнее.
Хранилище файловФото, PDF, подписи, газоанализ - в self-host объектном хранилище SeaweedFS (S3-совместимое, Apache-2.0), а не в AWS S3. Закрытый наряд - в режиме WORM (Write Once Read Many - нельзя изменить/удалить), срок хранения - по региону (вкладка «Движок правил»).
Изоляция тенантаМультитенантность (много заказчиков на одной инфраструктуре, но данные не пересекаются): данные оператора A физически невидимы оператору B (PostgreSQL Row-Level Security + tenant_id). Защита держится на уровне БД, а не аккуратности кода.
Данные в странеВесь контур (приложение, БД, файлы) - на железе внутри периметра нужной страны (Иран/РФ/Залив - выбор при внедрении). Ни одной зависимости от облаков, отрезающих Иран.
🔧 Для ИТ заказчика - стек, кнопки-проверки, .env (свёрнуто - не для HSE-администратора)
🐳
Docker / Docker Compose
Тот же образ для on-prem и SaaS, разница - в .env
Apache-2.0
🐘
PostgreSQL 18 + RLS
Наряды; Row-Level Security изолирует тенантов на уровне БД
PostgreSQL License
🔑
Keycloak
Вход через SSO/LDAP заказчика, self-hosted (не Auth0)
Apache-2.0
🗄️
SeaweedFS
S3-совместимое хранилище файлов на своём железе, WORM для закрытых нарядов
Apache-2.0
🛡️
Casbin
Права роль -> действие (RBAC), поверх изоляции данных
Apache-2.0
🔤
Vazirmatn + Inter (WOFF2)
Шрифты self-hosted, без Google Fonts (заблокированы в Иране)
OFL / SIL
🔒 Подробнее: «Безопасность и Иран»
Backend и железо - демо. На этой странице показан интерфейс и архитектура. Реальные сервер, БД, SSO и хранилище разворачиваются на стороне заказчика по гайдам - тут их работа симулирована (тосты/модалки), чтобы показать, как это устроено. Все блоки стека выше реальны, открыты и Иран-safe (без copyleft, без санкционных облаков).
SMS - через локальный шлюз региона.
Международные провайдеры (Twilio и т.п.) недоступны в части юрисдикций, поэтому шлюз выбирается по пресет-профилю площадки: Иран - местный шлюз (например Kavenegar / Melipayamak), Залив (GCC) - местный оператор GCC, РФ/СНГ - российский шлюз. Все названия - ориентир, доступность и OFAC-статус проверяются перед каждым внедрением. Email - через self-hosted SMTP в не-санкционном дата-центре. Это симуляция UI: переключатели меняют настройку, но реальную отправку делает бэк.

Каналы доставки

Тихие часы и резервный канал

Не-критичные уведомления копятся и приходят одним пакетом после тихих часов. Критичные (см. пометку «критично» ниже) идут всегда, без задержки.

События, по которым уведомлять

Привязаны к шагу жизненного цикла наряда и получателю по роли - не общий список «включено/выключено» без адресата.

Многоязычные уведомления. Текст уведомления уходит на языке получателя (EN/AR/FA/RU) и в его календаре (Jalali/Hijri/григорианский - по региону площадки). Закрывает пробел «многоязычные SMS/email через локальные шлюзы региона».
Локальные настройки площадки.
Язык интерфейса, календарь, часовой пояс и тема - тоже данные тенанта, не зашиты в код: у площадок в разных регионах разные умолчания. Ниже - пресет-профиль (быстро подставляет умолчания под регион) и три независимых переключателя. Пресет только предзаполняет - ничего не скрывает и не блокирует: после выбора можно вручную переключить любое поле, как и без пресета.

Пресет-профиль площадки структура

4 стартовых профиля под регионы развёртывания. Часть 1 - структура и умолчания языка/календаря; наполнение остальных региональных значений (розетка SMS-шлюза, сроки хранения, часовой пояс) - Часть 2. Без выбора пресета продукт работает на нейтральном EN-умолчании.

Язык интерфейса по умолчанию

По умолчанию интерфейс открывается на английском; для фарси и арабского включается полный RTL. Кнопка в шапке переключает язык вживую (фича 5).

Календарь

Даты считаются по-настоящему (алгоритм jalaali). Сегодня:

Часовой пояс и выходные

Отметки времени в журналах и уведомлениях - в этом поясе. Выходные дни - для правильного счёта «дней до истечения» и расписания уведомлений.

Тема оформления

Четыре темы: две светлых и две тёмных (ориентир - VS Code). Контрастные - для яркого солнца на площадке или ночной смены. Переключаются вживую, выбор запоминается.

Как это работает в продукте. Все эти настройки - это и есть «движок правил как данные»: типы нарядов, пороги газа, маршруты согласования, права ролей и уведомления хранятся как данные тенанта, а не вшиты в код. Меняя их здесь, HSE-администратор перенастраивает поведение всех нарядов площадки без программиста. Версионирование гарантирует, что активные наряды не «поедут» из-под рук. Связано с фичами 1 (rule-as-data), 4 (маршрут ролей), 15 (уведомления/эскалации), 20 (мультитенант + self-hosted).