Доработки этапа 2 — список замечаний

1. Источник (как есть)

Список доработок, которые надо сделать на этапе 2:

• "при расчете некоторых зданий появлялась ошибка о том, что верхнее перекрытие и высота здания не могут быть равны. Это не так. Надо поправить" — формулировка заказчика

• проверка условий расчётов — "Во всех расчетах высота и уровень верхнего перекрытия должны быть одинаковыми"

• "вывести тип светильников в лампе(светодиодные, люминесцентные)"

• Поведение модели здания ПС, если Климатический район здания не определён

• при загрузки нового справочника классов энергоэффективности из АИС не удаляются записи справочника, которых в АИС уже нет, а в Сервисе они остались. А оставшиеся записи синхронизируются. В результате может возникать перекрытие диапазонов для разных классов: "обновлённого" и "не удалённого"

2. Разбор

1. Ошибка «верхнее перекрытие и высота здания не могут быть равны» — требование снято.

Ошибка возникает, если наличие чердака = «Да» и при этом не выполняется условие «высота здания больше уровня верхнего перекрытия»: \(H > z_{ВП}\). Проверка стоит именно в ветке «чердак есть» секции te.attic_wall_area — при отсутствии чердака она не применяется, потому что высота чердака в расчёт не входит.

Пример из данных: здание ЗВН ПАО «Россети» / МЭС Центра / Валдайское ПМЭС / Тверицкая — крыша односкатная, наличие чердака = «Да», высота здания = уровень верхнего перекрытия = 4,42 м. При таких данных высота чердака равна нулю: чердака, объявленного в модели, геометрически не существует.

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

4. Климатический район здания не определён. Замечание охватывает три причины неправильного поведения: сообщение о следствии вместо причины, отсутствие подстановки климатического района подстанции и невидимость данных района в интерфейсе.

Почему сообщаются последствия, а не причина. Климатический район — характеристика здания, и в расчёт он приходит не сам, а тремя производными величинами. Данные отопительного периода — продолжительность, средняя температура наружного воздуха, скорость ветра — берутся из района, когда источник данных отопительного периода = «Справочные данные»; широта района определяет выборку записей справочника солнечной радиации. Если района нет, при сборке входной модели недостающие значения приводятся к нулю, а широта — к нулю, и выборка солнечной радиации оказывается пустой. Дальше падают валидаторы секций, которым эти данные нужны: te.heating_degree_days — на правиле \(z_{ht} \in [1; 365]\), te.solar_radiation_by_direction — на отсутствии записей справочника по каждой стороне света. Оба сообщения верны, и оба — про следствие.

Отсюда правка: отсутствие климатического района должно проверяться до того, как из района выводятся значения, и сообщаться как ошибка исходных данных здания. Приведение отсутствующего значения к нулю — тот же дефект, что и с длиной конька в CR по четырёхскатным крышам: пустое значение подменяется правдоподобным числом и теряет причину. Где именно ставить проверку — вопрос архитектуры расчёта: сборка входной модели знает, что района нет, но не сообщает; валидаторы секций видят только нули.

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

Данные района не видны в интерфейсе. Пользователь не может обнаружить, что широта не задана, до запуска расчёта: он её нигде не видит. Спецификация этого не требует — в описании полей карточки здания есть строки «Климатический район здания. Широта» и «Долгота», в карточке подстанции — такие же по району подстанции. В реализации выводится только наименование района (building.util.ts, substation.util.ts, heating-period.util.ts), а из климатических величин у подстанции показаны три параметра отопительного периода, и те скрываются, когда значение пустое. Широты нет нигде, хотя API её отдаёт (climateRegionLatitude).

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

Решение. Принят сценарий, в котором подстановки нет: источник климатических данных становится явным выбором пользователя — район здания, район подстанции или собственные значения. Пункт вынесен в отдельный CR CR 2026-09-03: обработка источников климатических данных, там же разбор, blast radius и план. Открытые вопросы этого пункта закрыты: подстановки нет (выбор виден и хранится в модели), а для зданий вне подстанций в списке источников просто нет варианта «район подстанции».

Остальные пункты не разбирались.

3. Blast radius

Не определён. Структурные связи на затронутые документы будут проставлены при разборе.

4. План

Не составлен.

5. Итог