name: om-documentation-review description: "Use when проверяя ЭОМ/ИОС1.1-документацию на ошибки и нормы." version: 1.1.0 author: AI_Lab_SCRUM Co license: MIT platforms: [linux, macos, windows] metadata: hermes: tags: [engineering, electrical, eom, documentation, review, lighting, automation, pue, ntd] category: engineering

related_skills: [excel-data-reconciliation, xlsx]

Проверка ЭОМ-документации

Методика проверки проектной/рабочей документации по электрооборудованию (ЭОМ), электроосвещению и автоматизации зданий на ошибки, опечатки и несоответствия нормам.

Когда использовать

• Проверка однолинейных расчётных схем щитов (ЩС, ЩО, ЩАО, ЩР).
• Сверка номиналов автоматов с нагрузкой и сечением кабеля.
• Поиск опечаток, расхождений в обозначениях, ошибок в цепях отходящих и вводных.
• Проверка соответствия действующим нормам (33 НТД — см. references/ntd-list.md).
• Сверка ссылок на НД в комплекте с фактическим статусом документов (действует / изменён / заменён / отменён) и доступ к источнику статусов — references/ntd-source-kodeks-techexpert.md.
• Проверка ТЕКСТОВОЙ ЧАСТИ тома ИОС1.1 (ПЗ): балансы мощности и годовой расход, категорийность, учёт, заземление/молниезащита, освещение, ОЗДС. Для объёмных томов использовать трёхэтапный протокол — references/multi-model-review.md.

Порядок работы

1. Извлечь текст из PDF (pdf_read.py --text или встроенная экстракция read_file). При объёмном томе — постранично в JSON с числом символов на страницу: страницы с chars < 50 — сканы без текстового слоя, их надо назвать в ограничениях, а не молчать. Сразу построить карту тома (что на какой странице: ПЗ / ГЧ / таблицы / схемы).
2. Пересчитать всё, что считается, кодом — Decimal и регулярки, до чтения выводов: суммы нагрузок, Sр = √(Pр² + Qр²), tgφ до и после КРМ, годовой расход, количество × удельная мощность. Не глазами и не в уме. Подробно — references/multi-model-review.md.
3. Проверить опечатки — искать слитные слова, пропущенные буквы, «мм2» вместо «мм²», двойные буквы.
4. Сверить обозначения щитов — одна и та же позиция должна называться одинаково по всему комплекту (ЩО vs ШО, индексы этажей N).
5. Проверить вводные цепи — соответствие: вводной автомат ↔ расчётный ток ↔ сечение кабеля.
6. Проверить отходящие цепи — номинал автомата ↔ нагрузка группы ↔ сечение группового кабеля.
7. Сверить с нормами по списку НТД (ПУЭ 1.3, СП 256, ГОСТ Р 50571.5.52 и др.) и проверить статус ссылочных НД: каждый упомянутый в тексте и на схемах нормативный документ — на действующую редакцию и замену. Отменённый или заменённый ссылочный НД — замечание, даже если сам текст проекта корректен.
8. Проверить согласованность внутри тома — категорийность, перечни, нумерация, дефекты обозначений НТД. См. питфоллы ниже.
9. Оформить отчёт — по структуре из раздела «Отчёт».
10. Прогнать независимого аудитора (другое семейство моделей, по выдержкам первоисточника) и свести его находки со своими. Пропускать только для тома до ~20 стр.

Критерии соответствия (ключевые цифры)

Допустимые токи медных жил в воздухе

(ПУЭ табл. 1.3.4 / ГОСТ Р 50571.5.52-2011 табл. B.52.2)

При прокладке нескольких жил/кабелей в пучке применять понижающий коэффициент ~0,87.

Типовые пары «автомат ↔ кабель» (розеточные/осветительные группы)

• 16 А → ППГнг(А)-HF 3×2,5 мм² (розетки)
• 10 А → 3×1,5 мм² (освещение)
• 20 А → 3×2,5 мм²
• 25 А → 3×4 мм²
• 32 А → 5×6 мм²
• 63 А → 5×16 мм²

Правило выбора аппарата защиты

Iном.авт ≤ 1,25 × Iр (по СП 256.1325800.2016 п.6.1.5 / ПУЭ 3.1.4). Завышенный автомат = несрабатывание защиты при КЗ.

Чек-лист частых ошибок

• Автомат завышен/занижен относительно расчётного тока группы.
• Сечение кабеля меньше требуемого для номинала автомата.
• Опечатки в марках кабеля или обозначениях щитов.
• Расхождение одного и того же щита (например «ШО» vs «ЩО»).
• Несоответствие номеров проекта (PR-XXX) в титуле и в тексте.
• УЗО на розеточные группы отсутствует или установка ≠ 30 мА.
• Система заземления указана некорректно (TN-S vs TN-C-S).
• Электрощитовая/ВРУ/ГРЩ посажены под мусорокамерой ТБО, санузлом, кухней пищеблока,

  ИТП, насосной или иным помещением с мокрыми процессами (и наоборот — над ними
  жилые комнаты): `references/placement-rules.md`.

• Ссылочный НД отменён/заменён либо приведён без действующей редакции («с изм. N»).
• Дефект в САМОМ обозначении НД: опечатка номера, несуществующая редакция, ссылка без года.
• Строка таблицы нагрузок выпала из ОБОИХ сезонных режимов (лето — «зима», зима — «пожар»).
• Количество единиц × удельная мощность не даёт колонку Ру.
• Расчётная мощность к ТУ с запасом менее 1 % — проверить выпавшие строки на пересчёт.
• Категорийность надёжности разнится между п.4, п.5 и итоговыми сведениями о потребителе.
• Сводные мощности в тексте ПЗ не сходятся с таблицами того же тома (Ру/Рр/Рр сезонные).
• Ру по составу (типы квартир × кВт/кв) не даёт цифру в подытоге.
• Марка кабеля противоречит описанной конструкции (HF ≠ изоляция из ПВХ).
• Один НТД в томе в двух редакциях: в перечне новая, в тексте отменённая.
• Пропуски и повторы номеров таблиц (ссылки «в таблицах 2 и 3» становятся неоднозначными).
• Будущая/нереальная дата в штампе документа.

Отчёт

Формат отчёта: сначала критические замечания (безопасность — перегрев, несрабатывание защиты), затем административные (опечатки, оформление). Каждое замечание — со ссылкой на пункт НТД и конкретной рекомендацией (заменить X на Y).

Рабочая четырёхуровневая структура, которая себя оправдала на томах ИОС1.1:

1. Критические — то, что влияет на безопасность или на соответствие ТУ (выпавшие из баланса нагрузки, противоречия категорийности, неподтверждённые источники).
2. Существенные — арифметика, расхождения между документами тома, дефекты НТД.
3. Административные — округления, нумерация, неполнота перечней.
4. «Проверено и соответствует» — таблица того, что сходится, с результатом проверки. Обязательный раздел: он показывает объём работы и не даёт читателю думать, что непроверенное — плохое.
5. «Ограничения проверки» — что НЕ проверено и почему (нет графической части, нет текстового слоя, нет доступа к ИСС). Прямо и без смягчений.

Разделение томов: ПЗ (текстовая часть) и ГЧ (графическая) проверяются по-разному. По тексту проверяются балансы, формулы, ссылки, решения; сверка схем со спецификациями, селективность защит и номиналы по отходящим линиям — ТОЛЬКО по однолинейкам. Если графическая часть не разобрана, это пишется в ограничениях, а не замалчивается.

Список НТД — в references/ntd-list.md. Протокол проверки в три этапа (извлечение → сверка кодом → независимый аудитор другого семейства моделей) и разбор, какой этап что реально ловит — references/multi-model-review.md. Ограничения по размещению электрощитовых (мокрые процессы, мусорокамера ТБО, жилые комнаты, подвалы) — в references/placement-rules.md.

Питфоллы, харнесс и схема работы — в references

Полные списки вынесены, чтобы тело скилла оставалось коротким:

• references/check-pitfalls.md — все проверенные ловушки: номера пунктов, метки режимов, количество×мощность, дефекты обозначений НТД, класс точности, категорийность, пустые таблицы, шифры штампов. Читать перед проверкой.
• references/harness-eom-check.md — скрипт scripts/eom_check.py: три вёрстки таблиц нагрузок, что он ловит, и все питфоллы парсинга (рвущиеся заголовки, склейка номера НТД, «Лифт пожарных» и т.п.).
• references/review-workflow.md — порядок шагов: код → база НТД → аудитор другого семейства, что даёт каждый и почему не заменяет остальные.
• references/review-verdict-docx.md — итоговая ведомость заказчику на 4 колонки («ВОПРОС | МАСТЕРМАЙНД | AI_Lab_SCRUM Co | РАСХОЖДЕНИЯ»), правила красного, скрипт сборки scripts/build_review_docx.py и его питфоллы.
• references/multi-model-review.md — вызов аудитора через API (питфолл reasoning_tokens, выбор модели).

Три правила, которые держать в голове всегда

1. Статусы НТД — только база. Модель их выдумывает. Поиск по номеру → чтение текста пункта по номеру строки.
2. Арифметику считать кодом, не глазами и не моделью: Decimal, суммы, √(P²+Q²), tgφ, количество×мощность.
3. Итог меньше суммы строк — ошибка. Сумма нагрузок по вводам не может быть меньше каждого слагаемого. Встретилось — искать, из чего собран итог.

Связанные заметки

Живой источник правды — этот скилл. Методику можно вести и заметками в своём vault (например, «Проверка ЭОМ-документации», «НТД для ЭОМ», «Размещение электрощитовых»); при расхождении править скилл, а не заметку.