IBMS · Архитектура
Архитектура IBMS — эталонная модель, которая доживает до передачи объекта
Эталонная архитектура IBMS: полевые устройства, сетевой уровень и уровень шлюзов, ядро надзора с единой моделью данных и приложения с ролевым доступом.
Краткий ответ
Архитектура IBMS включает четыре уровня: полевые устройства и контроллеры, сетевой уровень и уровень шлюзов, ядро надзора с единой моделью данных и приложения с ролевым доступом. Управление остаётся локальным, логика интеграции находится в ядре, а приложения читают данные из него, а не опрашивают подсистемы напрямую.
Четыре уровня, один источник истины
Рассматривайте архитектуру как четыре уровня. Полевые устройства измеряют и приводят в действие. Контроллеры выполняют локальные последовательности. Сетевой уровень и уровень шлюзов передают данные между протоколами и сетями. Ядро надзора нормализует точки в единую объектную модель и отвечает за тревоги, расписания, историю и блокировки. Приложения располагаются сверху и представляют представления для разных ролей. Уровни определяются ответственностью, а не названиями продуктов. В небольшом здании один блок может выполнять два уровня, но ответственность всё равно следует зафиксировать письменно, потому что именно это делает систему проверяемой и обслуживаемой после ухода проектной команды. Когда уровень пропускают, недостающая ответственность обычно возвращается в виде ручной процедуры. Записывайте ответственность рядом с каждым блоком на схеме.
Сетевой уровень и уровень шлюзов
Большинство сбоев интеграции начинается здесь. BACnet/IP, Modbus TCP, KNX и DALI имеют собственные модели синхронизации, адресации и диагностики. Держите сеть здания сегментированной от корпоративной сети, документируйте каждый шлюз и его карту точек и избегайте каскадирования преобразователей. Шлюз должен преобразовывать протокол, а не владеть последовательностью управления. Там, где подсистема предоставляет стабильный API, используйте его напрямую; где нет — определите владельца шлюза, электропитание, политику обновления прошивки и поведение при отказе. Схемы сети, нарисованные после пусконаладки, — признак тревоги, а не результат работы. Ведите перечень портов и план адресации; пусконаладка идёт быстрее, когда карта верна. Шлюз, для которого нужен ноутбук и пароль, которого ни у кого нет, — не открытый интерфейс.
Ядро надзора
В ядре IBMS перестаёт быть простым набором коннекторов. Каждой точке нужны идентификатор, единица измерения, признак качества, политика хранения истории и класс тревоги. Каждой подсистеме нужно соглашение об именовании, которое сможет прочитать новый инженер. Расписания и блокировки должны находиться здесь, чтобы их можно было видеть, тестировать и изменять без правки кода поставщика. Ядро также отвечает за синхронизацию времени, роли пользователей и журнал аудита. Если два приложения расходятся в значении, решать это должно ядро, а не третья база данных, которую ведёт команда отчётности. Имена точек должны описывать оборудование, местоположение и функцию — именно в таком порядке. Имя, которое понимает только исходный программист, — это будущий вызов сервисной службы.
Отказоустойчивость и безопасность по проекту
Местное управление должно выдерживать недоступность надзора, сбой сети и перезапуск сервера. Это означает, что контроллеры сохраняют свои последовательности и безопасные положения, а у сети есть документированный режим отказа. Безопасность — часть того же проекта: сегментированные VLAN, именованные учётные записи, минимальные привилегии, обновление, журналирование и контролируемый канал удалённого доступа. Резервные копии должны восстанавливаться силами заказчика, а не только исходного интегратора. Тестируйте отказы в ходе пусконаладки: архитектура, которую ни разу намеренно не отказывали, остаётся лишь чертежом. Документируйте шаги восстановления и проверяйте их с командой заказчика, а не только с ноутбука монтажника. Резервная копия, которая никогда не восстанавливалась, — надежда, а не средство контроля.
Уровни IBMS и ответственность
5 rows| Уровень | Отвечает за | Вопрос проектирования |
|---|---|---|
| Поле | Измерение и приведение в действие | Определены ли места установки датчиков и положения при отказе? |
| Контроллер | Локальные последовательности и безопасность | Что работает при недоступности сети? |
| Сеть и шлюз | Преобразование протоколов и передача данных | Кто отвечает за каждый шлюз и его карту точек? |
| Ядро надзора | Модель данных, тревоги, история, блокировки | Есть ли у каждой точки единый идентификатор? |
| Приложения | Представления и отчёты по ролям | Читает ли оно из ядра или опрашивает подсистемы? |
Изображения проекта
3 images
Частые вопросы
01Сколько уровней нужно архитектуре IBMS?
Три или четыре — в зависимости от того, считается ли сеть отдельно. Важно, чтобы у каждого уровня был владелец и чёткое поведение при отказе, а не само число.
02Где в архитектуре должны располагаться шлюзы?
На периферии, рядом с подсистемой, которую они преобразуют, в документированном сетевом сегменте. Они не должны нести логику управления или становиться недокументированной единой точкой отказа.
03Может ли IBMS работать в облаке?
Уровень приложений может и часто работает в облаке. Надзор и местное управление следует оставлять на объекте, чтобы здание продолжало работать при потере соединения.
04Как обеспечивать кибербезопасность?
Сегментируйте сети, используйте именованные учётные записи с минимальными привилегиями, обновляйте ПО по установленному циклу, журналируйте административные действия и контролируйте удалённый доступ. Это требования проекта, а не запоздалая мысль ИТ-службы.
05Какой документ определяет архитектуру?
Схема сетевых стояков, перечень точек, матрица протоколов и матрица ответственности. Вместе они показывают, что с чем соединено, кто отвечает за каждый интерфейс и как он будет проверен.
Следующий шаг
Приведите нам здание.
Расскажите о типе здания, системах в объёме работ и нужном результате. Мы покажем кратчайший путь к работающей системе.