Само ПО "ОрионПро" предусматривает объединение распределённых подсистем в единый комплекс (смотрите буклеты).
Объединение возможно несколькими путями:
1. если на каждом из 30-ти объектов установлен ПКУ С2000М, то объединить их на аппаратном уровне, а АРМ будет только один. При этом управление будет как локальное (ПКУ, БКИ и т.д.), так и дистанционное через АРМ.
2. если у Вас 30 именно АРМ ОриоПро, то объединить на уровне ПО. Т.е. на объектах ядро опроса+монитор (другие модули по желанию), а у единого оператора сервер+монитор+АБД.
3. комбинированный вариант - одно ядро опроса+сервер+АБД и мониторы на каждом из объектов, при этом пульты объединяются аппаратно.

Основной проблемой будет объединить 30 отдельных лицензий в одну, ну и все 30 БД в одну базу.

Для удалёного управления можно использовать. Программу TeamViewer. Очень удобная программа!

Небольшое дополнение по созданию большой системы - слияние нескольких баз.
В такой конфигурации встает вопрос отказоустойчивости. У ОрионПро есть программная реализация "Резервного сервера", когда при отказе основного происходит переключение на резервный. Решение на основе резервирования MS SQL сервера и сервера приложений - Центральный сервер Орион (ЦСО). Теоретически - должно работать, на практике я бы его не советовал, по крайней мере без наличия реально продвинутого sql-администратора.
В принципе, если модуль "Оперативная задача" на локальном объекте запущена на одном компьютере, то есть на одном компьютере запущено и "Ядро опроса" и "Монитор ОЗ", тогда в принципе это должно работать и в случае пропаданания связи между Оперативной задачей и ЦСО, локальный "Монитор ОЗ" будет показывать и управлять приборами, которые подключены к локальному "Ядру опроса". На практике чаще всего в момент нарушения связи между Оперативной задачей и ЦСО происходит отказ (ошибка) Оболочки (shell.exe), без которой локальная машина работать не будет. Проблема именно в Оболочке, потому, что Монитор и Ядро даже на локальном компьютере общаются только через неё.
Но в пожарке не так много событий, поэтому такой сценарий вполне реализуем - при восстановлении связи все события из ОЗ должный прогрузиться в ЦСО.
И на этом этапе снова возникает затык, так как при одновременном подключении к ЦСО сразу всех локальных объектов закончатся количество подключений и количество рабочих потоков, фактически это DDoS-атака... и сервак не устоит.
В 1.20.3 уже есть механизм блокировок, который позволит отклонять превышение подключений, пока не будет завершён обмен. Сейчас начинаем его тестировать, очень надеемся, что заработает.
Я бы попробовал но только на новой версии.

Номера разделов переписывать придётся и это для большой системы большая проблема - ограничение всего в 10000 разделов в версии 1.20.2 не перепрыгнешь... из разговора с разработчиками припоминаю, что это ограничение связано не с Орионом, а именно с пультом (у него максимум 9999).
 

Тоже объединял около 20 объектов. Проблем с объединением в принципе нет. Но я бы рекомендовал платный SQL, с функцией репликации. 
Единственное неудобство это огромное количество разделов. Для этого была реализована фунция ссылок и графически выведено на экран по адресам зданий. Орионы про нужно будет подводить под единую версию Орион Про. Если 1.20., может выйти затратно!

А КСПИ "Эгида"не рассматривали? Она как раз и создана для того, чтобы собирать информацию с удаленных объектов в единой диспетчерской. Это не задача АРМ Орион Про, которая используется локально.