1. Топология KNX TP: линия, область, магистраль (backbone)
2. Individual Address (IA): формат Area.Line.Device
3. Group Address (GA): 2- и 3-уровневая структура
4. Рабочий цикл ETS: назначение → download → verify
5. Диагностика: Bus Monitor и Group Monitor
6. Напряжение и ток шины: что измерять на объекте
7. Типовые неисправности ПНР KNX
8. Чек-лист пусконаладки KNX / ETS

KNX (стандарт ISO/IEC 14543-3 / EN 50090, спецификации KNX Association) — распространённая шина в системах автоматизации зданий (BMS, Building Management System) и локальной автоматики освещения, жалюзи, HVAC-зон. Для инженера пусконаладки (ПНР) критичны не «красота» визуализации в ETS (Engineering Tool Software), а корректная топология TP (Twisted Pair), уникальность Individual Address, согласованность Group Address с проектом и повторяемая проверка после download. Ниже — практическая методика адресации, загрузки и диагностики без подмены норм производителя вымышленными пунктами ГОСТ.

1. Топология KNX TP: линия, область, магистраль (backbone)

На физическом уровне KNX TP — это витая пара с питанием по шине. Логическая структура, заложенная KNX Association:

• Line (линия) — сегмент устройств под одним линейным соединителем (Line Coupler) или источником питания линии. На одной линии обычно до 64 устройств (точное число — по документации устройств и бюджета питания линии).
• Area (область) — группа линий, связанных через Area Coupler / Backbone Coupler.
• Backbone (магистраль) — линия области «0» (часто обозначают как backbone line), соединяющая области между собой.

Типовые диапазоны адресации (классическая модель KNX): Area 0…15, Line 0…15, Device 0…255, с ограничениями на резервные/служебные адреса. Конкретные допустимые комбинации и исключения (например, адрес линейного соединителя) сверяйте с руководством ETS и паспортом устройства — не с произвольными «нормами ГОСТ».

Что проверить до программирования

• Соответствие трассы проекту: нет недопустимых длинных ответвлений, если проект запрещает star-топологию.
• Полярность шины (+/− / красный-чёрный — по маркировке производителя кабеля и клемм).
• Разделение линий через line coupler там, где в проекте разные Area/Line.
• Бюджет тока источника питания линии vs сумма токов устройств (datasheet).

2. Individual Address (IA): формат Area.Line.Device

Individual Address (индивидуальный адрес, IA) — уникальный физический адрес устройства на шине. Формат в ETS: A.L.D (Area.Line.Device), например 1.2.15.

Назначение IA выполняется в режиме программирования: устройство переводится в programming mode (кнопка Prog на корпусе или программный способ — по datasheet), ETS выдаёт адрес. После назначения устройство должно отвечать на свой IA; повторный programming mode на другом устройстве с тем же адресом — прямой путь к коллизии.

3. Group Address (GA): 2- и 3-уровневая структура

Group Address (групповой адрес, GA) — логический адрес телеграмм: датчик пишет в GA, исполнитель слушает GA. Физический IA при этом не «управляет» напрямую логикой функции — связь строится через группы в ETS.

В ETS обычно используют:

• 3-level: Main / Middle / Sub (например 1/2/15) — удобно для больших зданий: этаж / система / точка.
• 2-level: Main / Sub — проще на малых объектах.

Тип данных (DPT, Datapoint Type) должен совпадать на всех концах группы: нельзя смешивать в одной GA разные DPT (например, 1-bit switch и 2-byte float) — иначе визуализация и BMS-шлюз будут читать «мусор». Имена GA в проекте ETS должны совпадать с таблицей точек проекта BMS / ТЗ.

4. Рабочий цикл ETS: назначение → download → verify

Устойчивый порядок работ на объекте (независимо от версии ETS — уточняйте меню по руководству конкретной версии):

1. Подключение интерфейса — USB/IP-интерфейс KNX, проверка связи с шиной (online).
2. Открытие проекта — актуальная копия .knxproj с контролем версии (дата, автор, changelog).
3. Назначение IA — Programming mode → Assign individual address → подтверждение в дереве устройств.
4. Параметризация — application program, параметры (задержки, сцены, пороги) по проекту.
5. Привязка GA — group objects ↔ group addresses; проверка флагов C/R/W/T/U по назначению объекта.
6. Download — полная или частичная загрузка application + addresses; дождаться статуса OK без ошибок.
7. Verify / unload check — сравнение загруженного с проектом (где доступно в ETS); функциональный тест: нажатие кнопки / изменение уставки → реакция исполнителя.
8. Фиксация — экспорт проекта, резервная копия на носитель заказчика, запись в журнал ПНР.

5. Диагностика: Bus Monitor и Group Monitor

В ETS два основных инструмента «живого» трафика:

• Bus Monitor — сырые телеграммы шины: источник, назначение, приоритет, тип кадра, ACK/NACK. Нужен при подозрении на коллизии, отсутствие ACK, «шум» линии, неправильный line coupler filter.
• Group Monitor — телеграммы по Group Address с декодированием DPT (если задан). Удобен для ПНР функций: отправили Write на GA — увидели значение и подтверждения.

Типовой сценарий диагностики

1. Открыть Group Monitor, фильтр по целевой GA.
2. Спровоцировать событие (кнопка, изменение уставки с панели, Write из ETS).
3. Убедиться, что телеграмма ушла и исполнитель ответил / изменил состояние.
4. Если телеграмм нет — Bus Monitor: есть ли вообще кадры от IA источника? Есть ли ACK?
5. Если кадры есть, но исполнитель молчит — проверить привязку GA, флаги, фильтр line coupler (routing), DPT.

Фильтры линейных/магистральных соединителей могут блокировать группы между линиями — это штатное поведение, а не «сломанный» исполнитель. Сверяйте таблицу маршрутизации с проектом.

6. Напряжение и ток шины: что измерять на объекте

Питание KNX TP обычно в диапазоне порядка 21…30 В DC (ориентир; точные пределы — datasheet источника питания и устройств). На ПНР измеряйте:

Допустимое падение напряжения и максимальный ток — по документации производителя PSU и проекту. Если U_bus на конце линии заметно ниже, чем у источника, ищите длинный тонкий кабель, лишние соединения, перегруз.

7. Типовые неисправности ПНР KNX

8. Чек-лист пусконаладки KNX / ETS

KNX сдаётся не «по зелёным лампочкам в ETS», а по совпадению физической топологии, уникальных IA, логики GA и протоколу функциональных испытаний. Bus Monitor и Group Monitor — обязательный инструмент, а не «опция для сложных случаев».