Принципы построения универсальной платформы непрерывного мониторинга технического состояния инфраструктурных объектов

Принципы построения универсальной платформы непрерывного мониторинга технического состояния инфраструктурных объектов

Статья посвящена развитию технологий мониторинга объектов инфраструктуры промышленности и транспорта. Отмечается важность систем мониторинга для совершенствования технологий обслуживания технических объектов, а также возможностей определения предотказных состояний, прогнозирования дальнейших изменений и определения остаточного ресурса. Дается анализ подходов к реализации систем мониторинга с точки зрения обеспечения оптимальной компоновки. Имеется перечень критериев для оценки эффективности рассмотренных подходов к проектированию. Приведены рекомендации по рациональному подходу к проектированию систем мониторинга и определена оптимальная последовательность действий для создания универсальной платформы непрерывного мониторинга состояния технических объектов. Предложена концепция универсальной платформы непрерывного мониторинга для инфраструктурных объектов строительной отрасли, транспорта и промышленности.

Введение

Обеспечение безопасной эксплуатации сложных технических систем — одна из приоритетных задач современной промышленности и транспорта [1–3]. Существенным ее аспектом является обеспечение прочности металлических конструкций крупных машин, строительных и технологических сооружений [4].

При существующим уровне развития технологии не представляется возможным обеспечить безусловную надежность конструкции на этапе проектирования.

При моделировании несущей способности конструкций нельзя учесть влияние всех внешних воздействий, а также накопленных повреждений, возникающих при длительной эксплуатации. Поэтому для обеспечения безопасности ответственных объектов используются возможности мониторинга технического состояния конструкции [5–8].

Под мониторингом понимается непрерывный процесс наблюдения, систематическая регистрация параметров и обработка информации об объекте или процессе с целью изучения его динамики и проверки его соответствия заданным критериям. Мониторинг технического состояния — наблюдение за состоянием объекта для определения и предсказания момента перехода в неработоспособное или предельное состояние [4, 9]. Полученные данные позволяют сформировать оценку текущего технического состояния объекта (технический диагноз) и на основании полученной и априорной информации оценить возможность его дальнейшей безопасной эксплуатации. Результаты мониторинга дают основания для оценки остаточного ресурса конструкции, назначения внепланового технического обследования, обслуживания или ремонта, указания на неотложные действия персонала и т. д. [10–14]

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

1. Непосредственное измерение критических параметров (характеризующих состояние конструкции) и сопоставление их с пороговыми значениями, установленными при проектировании [15]. При низкой стоимости реализации этот метод имеет следующие ключевые недостатки:

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

Далеко не всегда удается найти параметр, непосредственно характеризующий состояние конструкции. Например, таким образом невозможно контролировать усталостное повреждение элементов.

2. Расширением предыдущего подхода можно считать анализ трендов снимаемых показаний для прогнозирования времени критического ухудшения состояния в точках непосредственных измерений [16–18]. Этот метод дает информацию для корректировки плана технического обслуживания и ремонта объекта. Остальные недостатки сохраняются.

Реализация систем мониторинга должна строиться на универсальной платформе.

При проектировании универсальной программно-аппаратной платформы необходимо максимально полно охватить исследуемую область:

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

Далее будет продемонстрировано, как:

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

1. Задачи, виды и состав систем мониторинга

Мониторинг требуется во множестве областей. В их числе контроль как над параметрами конструкций и активных механизмов, так и над пользователями (персоналом); наблюдение за состоянием человеческого организма; за окружающей средой (например, с целью сохранения природы или для предупреждения и предотвращения стихийных бедствий); за протеканием физических и химических реакций и т. д.

Несмотря на существенные отличия в этих сферах, сам процесс построения систем мониторинга, их архитектура и составные части практически идентичны вне зависимости от объекта контроля [19, 20].

С наступлением цифровой эры и развитием вычислительной техники и полупроводниковой электроники основой любых современных систем мониторинга (СМ) стал набор решений, приведенный в таблице.

Анализируя многообразие уже существующих СМ и областей, где они необходимы, можно заметить, что всем системам свойственны одни и те же элементы.

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

В системах малого размера (полуавтономные системы, мониторинг малого числа параметров, локальные системы) отдельные составляющие могут объединяться в пределах одного устройства. Например, автономная система измерения температуры: сигнал с датчика поступает сразу на АЦП ПЛК (аналогово-цифровой преобразователь программируемого логического контроллера), который одновременно является устройством сбора и обработки информации.

Типовые элементы систем мониторинга и их задачи

No Элемент Задача
1 Датчики Прямое или косвенное измерение требуемых параметров
с помощью оптимальных в данных условиях датчиков (с учетом среды функционирования, характеристик
устройства и экономического фактора).
2 Преобразователи Наиболее ранняя оцифровка измеренных датчиком значений для передачи сигнала в виде определенного цифрового кода с возможностью предварительной обработки
(усреднения), распознавания ошибок в линии связи, обеспечения помехозащиты, восстановления значений.
3 Сеть Передача оцифрованного сигнала в верхний уровень по оптимальным в заданных условиях каналам связи.
4 УСОД (устройства сбора и обработки данных) Сбор и обработка данных со всех узлов в хранилище
верхнего уровня*.
5 ПО Программа или набор взаимосвязанных программных модулей, обеспечивающие обработку, накопление
и передачу в интерфейс собираемой с датчиков информации, а также выполнение сопутствующих сервисно-
административных задач (архивирование, резервирование, разграничение прав доступа)**.
6 Интерфейс Выдача обработанной информации:

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

* Обычно между устройствами оцифровки сигнала и конечными серверами существуют промежуточные устройства сбора данных (несколько последовательных верхних уровней), а сами серверы четко выражены и являются вершиной структуры системы. Однако возможны и ситуации, когда средние уровни отсутствуют.
** Совокупность программ зачастую распределена по нескольких устройствам (УСОДы нижнего и верхнего уровней, АРМы операторов).

Однако и в этом случае при ближайшем рассмотрении присутствуют все обозначенные выше черты — АЦП соединен с микроконтроллером (МК) внутренней цифровой шиной (I2C, ISP), разделение на уровни выполнено в пределах единого программного обеспечения (ПО) устройства. Программная функция обработки измерения играет роль устройства сбора данных, а функция сохранения результата в постоянном запоминающем устройстве (ПЗУ) — корневого хранилища.

Что касается систем наблюдения за значимыми объектами, помимо центральных серверов, относящихся к СМ самого объекта, обычно существуют еще и системы регионального масштаба, куда должен передаваться сигнал со всех подконтрольных СМ.

И так вплоть до систем государственного уровня или мирового масштаба (при их наличии).

Существуют автономные/полуавтономные СМ, накапливающие информацию во внутренней памяти устройств. Зачастую они не имеют постоянной устойчивой связи с центральным хранилищем (из-за неблагоприятной для распространения сигнала среды, удаленности от корневого поста, для минимизации энергопотребления).

Но периодически выполняется считывание накопленных значений (оператором при подключении к блоку или после транспортировки блока на центральный пост и подключения на месте). Здесь также наблюдается разделение на уровни с наличием корневого центра, а канал связи характеризуется большой дискретностью снятия информации и необходимостью перемещения устройств, но он существует.

Оптические системы измерений протяженностью от 100 до 1000 м, несмотря на значительные покрываемые расстояния, не противоречат пункту о «ранней оцифровке», т. к. рассматриваются как единый датчик, на входе которого уже непосредственно размещен цифровой блок.

Проиллюстрируем структуру СМ на примере системы мониторинга искусственных конструкций (зданий и сооружений).

а) Датчики: акселерометры, датчики усилий и перемещений, инклинометры, прогибомеры, тензодатчики.

б) Преобразователи: АЦП на выходе аналоговых датчиков, преобразователи интерфейсов на выходе цифровых датчиков.

в) Сеть: промышленные сети и протоколы для объединения показаний со всех преобразователей и датчиков прямого подключения: 1-wire, CAN/CANopen, Ethernet (EtherCAT, IP, Modbus TCP), GSM/GPRS, LONworks, PLC, RS-232/422/ 485 (Modbus RTU/ASCII), Wi-Fi.

г) УСОД:

  • промышленные устройства сбора данных (концентраторы);
  • промежуточные и корневые серверы сбора и обработки данных.

д) ПО:

  • ПО на промежуточных компьютерах, серверах (ядро) и автоматизированных рабочих местах (оператора) АРМах (интерфейс).

е) Интерфейс:

  • АРМы с нативными приложениями либо web-интерфейсом;
  • связь с региональными системами мониторинга верхнего уровня;
  • sms- и e-mail-информаторы операторов, сообщающие о внештатных ситуациях.

2. Анализ подходов к построению систем мониторинга

При анализе практической реализации систем мониторинга конструкций можно выделить два диаметрально противоположных подхода к построению указанных систем.

Первый основывается на интеграции множества решений различных производителей.

Например, можно использовать датчики и устройства сбора данных разных производителей. Зачастую устройства сбора измерений с датчиков, сделанные разными фирмами, нельзя напрямую объединить в промышленную сеть и подключить к устройствам накопления. Необходимо использовать альтернативные пути (RS-485, Еthernet, Wi-Fi, GSM) либо дополнительные преобразователи с интерфейсом для единой сети.

На многих объектах наблюдается также комбинирование различного ПО для выполнения итоговой задачи — сбора, накопления, обработки и визуализации показаний датчиков.

Чаще всего используется заводское ПО либо драйверы производителя для опроса промежуточных устройств, т. к. протокол обмена с оборудованием может быть закрыт либо труднореализуем.

Второй подход базируется на использовании решений одного производителя.

Для построения масштабных систем мониторинга необходимо рационально выбрать компоненты системы. Предлагается использовать следующие критерии оценки:

  • ремонтопригодность и возможность модернизации;
  • оптимальность компоновки;
  • оптимальность стоимости;
  • оптимальность межкомпонентного взаимодействия.

Проведем анализ вышеописанных подходов к построению систем мониторинга по данным критериям.

1. Ремонтопригодность и возможность модернизации

Подход 1. Когда система изначально собирается из разрозненных компонентов, предполагается возможность замены некоторых частей на альтернативные.

Например, в процессе ремонта и модернизации системы (или если какое-либо оборудование/ПО сняты с производства). На практике далеко не все системы позволяют подключать дополнительные компоненты других производителей.

Такое возможно в том случае, если серверное ПО построено на базе SCADAсистемы с расширенной поддержкой различных промышленных протоколов, а планируемые к использованию блоки выполнены с использованием одного из этих интерфейсов.

Подход 2. Модернизация затруднена вследствие фиксированной компоновки системы. Крайне ограничена вариативность в перечне оборудования, в основном определяющемся производителем системы.

2. Оптимальность компоновки

Подход 1. Возможность применения в каждой составной части СМ лучших решений на рынке — наиболее точных датчиков, лучших АЦП, оптимальных промышленных сетей, стабильного ПО, передовых технологий постобработки информации.

Подход 2. Компоновка системы жестко фиксирована.

3. Оптимизация стоимости

Подход 1. В условиях ограниченного бюджета возможность подключить и использовать более дешевые элементы там, где это не столь критически важно, позволяет вложить сэкономленные средства в основные компоненты СМ. Отрицательной стороной подобных составных систем обычно становится проблема c запуском и корректной работой всего комплекса в целом.

Подход 2. Стоимость практически полностью определяется производителем.

Если нет возможности выбрать оборудование или ПО, итоговая стоимость проекта может оказаться завышенной. Ведь почти всегда на рынке присутствует более выгодное альтернативное решение, но его нельзя использовать в условиях системы единого производителя.

4. Оптимальность межкомпонентного взаимодействия

Подход 1. Реализованные разными производителями составные части не тестируются в заводских условиях на возможность полноценной и бесперебойной совместной работы.

Наладка, сбор системы воедино и устранение проблем (конфликт устройств на шине, сопряжение драйверов, организация обмена между программными частями) полностью производится разработчиками итоговой системы и службы ввода в эксплуатацию с дальнейшей поддержкой. Зачастую можно объединить в одну систему практически любые аппаратные и программные решения независимых производителей. Но если изготовитель не предусмотрел интерфейсы для взаимодействия с внешними компонентами, то дальнейшая интеграция может быть выполнена избыточными средствами. Например, использование неподходящего/устаревшего интерфейса в промышленном оборудовании приводит к необходимости установки дополнительных преобразователей. Отсутствие в ПО средств для межпроцессного взаимодействия или использование специфичных технологий ведет к созданию различных дополнительных программных прослоек.

Здесь каждый дополнительный элемент (оборудование/программный модуль) привносит в общую систему негативные факторы.

Среди них:

  • удорожание итоговой системы;
  • увеличение стоимости поддержки;
  • повышение риска отказа системы (поломка оборудования, сбой в ПО);
  • внесение дополнительных источников ошибок в систему (сбой в оборудовании, ошибки в ПО).

Полноценным SCADA-системам верхнего уровня эти недостатки свойственны в меньшей степени, т. к. за годы развития они обычно дополняются большим количеством модулей обмена с широким классом оборудования.

Подход 2. Обеспечивается слаженная работа компонентов за счет тестирования в заводских условиях.

Не ожидается значительных трудностей при развертывании системы, что, впрочем, не гарантирует отсутствия проблем при неудачной архитектуре системы или при использовании в неблагоприятных условиях (промышленные радиоэлектронные помехи, нестабильность питания, повышенная влажность, критический диапазон температур). Имеется согласованная документация по всем элементам системы, есть возможность получить консультацию по любому аспекту у единого производителя. Однако на практике нередки случаи, когда сотрудникам местных филиалов компании не хватает компетентности для решения возникших у заказчика проблем; документация недостаточно полна либо местами противоречива.

3. Рекомендации по рациональному подходу к проектированию систем мониторинга

При проектировании новой системы необходимо учитывать вышеописанные аспекты.

Разработка всех уровней (серверное ПО — УСОД — преобразователи — датчики) дает преимущество на конечном этапе, позволяя получить стабильную согласованную систему. При этом нужно принять во внимание, что стоимость разработки и последующего доведения системы до рабочего состояния существенно возрастает с каждым реализуемым уровнем.

Для начального этапа характерна также высокая сложность поддержки, т. к. нужно подготовить документацию на все компоненты системы. Чем больше элементов, тем выше нагрузка на технических писателей и отдел техподдержки пользователей.

Всегда есть вероятность, что на рынке появится устройство или ПО, которое превосходит аналогичный фрагмент разрабатываемой системы. Например, лучшие преобразователи, более эффективная сеть, усовершенствованные УСОД, более функциональное ПО. Подобные преимущества могут заставить отказаться от использования системы в пользу универсальной SCADA (Supervisory Control And Data Acquisition — система диспетчерского управления и сбора данных).

С другой стороны, возможна разработка не замкнутой (полностью проприетарной) системы, а более универсальной открытой платформы, обеспечивающей подключение к серверному ПО открытых библиотек, реализующих основные промышленные протоколы, и драйверов устройств сбора. Это позволит подключать оборудование сторонних производителей.

Чем ближе система по возможностям к SCADA, тем выше ее конкурентные преимущества.

1. На уже существующих объектах мониторинга со временем возникает необходимость модернизации системы для удовлетворения новых требований и решения новых задач. Используемое оборудование в большинстве своем (особенно датчики) еще находится в рабочем состоянии и если и требует ремонта, то небольшого. Более того, сами датчики, преобразователи и устройства сбора технологически не устаревают. Если они уже установлены, то свою функцию — измерение/преобразование/передачу данных — выполняют одинаково и в момент установки и через несколько лет эксплуатации (при отсутствии поломок).

2. Сети передачи данных проложены, точки измерений определены, датчики смонтированы, устройства сбора сопряжены с сервером. Если нет потребности в дополнительных измерениях и условия эксплуатации не меняются, созданная измерительная сеть может существовать годами (при надлежащем контроле — десятилетиями). И если к аппаратной части новых требований зачастую не предъявляется, то программная, напротив, должна покрывать всё больший класс задач. Могут потребоваться новые типы выгрузок и форматы экспорта данных, иная форма представления и визуализации работы системы (2D- и 3D-схемы), возможность прогнозирования или расширенного и перекрёстного анализа трендов. В этих условиях создание SCADA-подобной системы с возможностью подключения стороннего оборудования представляется оптимальной задачей: открывается перспектива замены ПО на существующих объектах новым.

3. С другой стороны, постоянно вводятся в эксплуатацию новые объекты.

Существует потребность в разворачивании систем мониторинга с нуля. Здесь создание универсальной платформы позволяет внедрить систему, даже если какой-либо из других уровней архитектуры (датчики, преобразователи, сеть, УСОД) лучше у других производителей.

Таким образом, оптимальным вариантом системы будет комплекс, максимально приближенный к SCADA-системе:

В первую очередь разрабатывается ПО верхнего уровня с возможностью подключения стороннего оборудования. Это открывает доступ и к существующим объектам (в рамках модернизации), и к новым, но уже либо с проектируемым оборудованием, либо с приборами других производителей.

УСОД также нужно проектировать с учетом возможности коммуникации со сторонними компонентами. Но поскольку УСОД является промежуточным компонентом между ПО/интерфейсом и сетью/преобразователями, он должен обладать широким набором интерфейсов на входе и выходе.

Преобразователи и сеть при создании системы удобно рассматривать в совокупности. Преобразователи не являются полноценными промышленными компьютерами, поэтому не имеют большого количества интерфейсов, обычно ограничиваясь одним.

При проектировании сеть и преобразователь прорабатываются совместно. Для этого выбирается оптимальный тип промышленной сети и соответствующий интерфейс преобразователя.

4. Концепция универсальной платформы непрерывного мониторинга

На основании анализа определена оптимальная концепция проектирования системы непрерывного мониторинга состояния технических объектов.

1) Проектирование цифрового программно-аппаратного комплекса: разрабатываются исключительно цифровые программно-аппаратные средства — преобразователи, сеть, УСОД, серверное ПО, интерфейсы. Уровень датчиков как устройств, содержащих аналоговые элементы, в достаточном количестве представленных на рынке и не подверженных быстрому устареванию, исключается из процесса разработки.

2) Обеспечение универсальности и расширяемости проектируемых компонентов:

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

3) создание трех основных макроблоков системы (преобразователи, УСОД, ПО) должно производиться совместно. При этом необходимо соблюдать базовые принципы:

  • требуется постоянное координирование действий при создании основных компонентов системы;
  • приоритет при распределении ресурсов отдается ПО как наиболее универсальному элементу комплекса, позволяющему осуществить раннее внедрение за счет интеграции с уже созданными системами.

4) Использование Ethernet в качестве промышленной сети целесообразно в силу следующих преимуществ:

  • широкого распространения технологии и оборудования;
  • недорогих промышленных микросхем;
  • обширного ассортимента повторителей;
  • наличия активных коммутаторов и разветвителей для построения шин типа «звезда»;
  • наличия преобразователей для всех видов интерфейсов — RS232/422/485Ethernet, USB-Ethernet, «Оптоволокно-Ethernet» и др.;
  • высокой помехоустойчивости и скорости передачи данных;
  • возможности передавать произвольный поток данных.

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

Заключение

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

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

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

Библиографический список

  1. Ефанов Д. В. Функциональный контроль и мониторинг устройств железнодорожной автоматики и телемеханики : монография / Д. В. Ефанов. – СПб. : ПГУПС, 2016. – 171 с.
  2. Belyi A. A. Structural Health and Geotechnical Monitoring During Transport Objects Construction and Maintenance / A. A. Belyi, E. S. Karapetov, Yu. I. Efimenko // Procedia Engineering. – 2017. – Vol. 189. – P. 145–151. https://doi.org: 10.1016/j.proeng.2017.05.024
  3. Smarsly K. Autonomous Monitoring of Masonry Dams Based on Multi-Agent Technology / K. Smarsly, D. Hartmann // The 4th Congress on Dams, Struga, Republic of Macedonia, 28–30 September 2017. – 2017. – P. 1–10.
  4. Соколов С. А. Методика прогнозирования разрушения сварных металлических конструкций подъемно-транспортных машин / С. А. Соколов, Д. Г. Плотников // Ремонт. Восстановление. Модернизация. – 2015. – No 12. – С. 22–28.
  5. Sokolov S. Analysis of the Fatigue Strength of Welds in Terms of Local Stress / S. Sokolov // Russian Engineering Research. – 2018. – Vol. 38. – No 3. – P. 151–156. https://doi.org: 10.3103/S1068798X18030218
  6. Sokolov S. Local criterion for strength of elements of steel-work. Mechanical Engineering Research and Education / S. Sokolov, A. Grachev // International Review of Mechanical Engineering. – 2018. – Vol. 12. – No 5. – P. 448–453.
  7. Shlepetinsky A. Yu. Trajectory and growth speed of fatigue cracks due to poor weld fusion in a weld joint / A. Yu. Shlepetinsky, K. P. Manzhula, A. G. Savelyev // Transport Engineering and Technology. – 2019. – No 13. – P. 46.
  8. ГОСТ 27.002–2015. Надежность в технике (ССНТ). Термины и определения. – М. : Стандартинформ, 2016. – 28 с.
  9. Сапожников В. В. Основы теории надежности и технической диагностики / В. В. Сапожников, Вл. В. Сапожников, Д. В. Ефанов. – СПб. : Издательство «Лань», 2019. – 588 с.
  10. Efanov D. Monitoring System of Vibration Impacts on the Structure of Overhead Catenary of High-Speed Railway Lines / D. Efanov, G. Osadchy, D. Sedykh, D. Pristensky, D. Barch // Proceedings of 14th IEEE East-West Design & Test Symposium (EWDTS`2016), Yerevan, Armenia, October 14–17. – 2016. – P. 201–208. https://doi.org: 10.1109/EWDTS.2016.7807691
  11. Efanov D. Development of Rail Roads Health Monitoring Technology Regarding Stressing of Contact-Wire Catenary System / D. Efanov, G. Osadchy, D. Sedykh // Proceedings of 2 nd International Conference on Industrial Engineering, Applications and Manufacturing (ICIEAM), Chelyabinsk, Russia, May 19–20. – 2016. – P. 1–5. https://doi.org: 10.1109/ICIEAM.2016.7911431
  12. Belyi A. Development of Automation Systems at Transport Objects of MegaCity / A. Belyi, D. Shestovitskii, V. Myachin, D. Sedykh // Proceedings of 17th IEEE East-West Design & Test Symposium (EWDTS`2019), Batumi, Georgia, September 13–16. – 2019. – P. 201–206. https://doi.org: 10.1109/EWDTS.2019.8884382
  13. Belyi A. Main Solutions of Structural Health Monitoring in Managing the Technical Condition of Transport Objects / A. Belyi, D. Shestovitskii, E. Karapetov, D. Sedykh, V. Linkov // Proceedings of 17th IEEE East-West Design & Test Symposium (EWDTS`2019), Batumi, Georgia, September 13–16. – 2019. – P. 213–218. https://doi.org: 10.1109/EWDTS.2019.8884435.
  14. Efanov D. V. Permanent Monitoring Systems of the Contact-Wire of Railroad Catenary : the Main Tasks of Implementation / D. V. Efanov, G. V. Osadchy, D. V. Barch, A. Belyi //Proceedings of 17th IEEE East-West Design & Test Symposium (EWDTS`2019), Batumi, Georgia, September 13–16. – 2019. – P. 484–487. https://doi.org: 10.1109/EWDTS.2019.8884442.
  15. Осадчий Г. В. Мониторинг технического состояния раздвижной крыши стадиона «Санкт-Петербург Арена» / Г. В. Осадчий, А. А. Белый, Д. В. Ефанов, Д. А. Шестовицкий // Строительство уникальных зданий и сооружений. – 2018. – No 6. – С. 10–24. – https://doi.org: 10.18720/CUBS.69.2.
  16. Smarsly K. Artificial Intelligence in Structural Health Monitoring International Workshop on Computing in Civil Engineering / K. Smarsly, K. Lehner, D. Hartmann. – 2017. – P. 111–118.
  17. Heidmann L. Smart Point Machines: Paving the Way for Predictive Maintenance / L. Heidmann // Signal+Draht. – 2018. – Iss. 9. – P. 70–75.
  18. Luckey D. Artificial intelligence techniques for smart city applications / D. Luckey, H. Fritz, D. Legatiuk, K. Dragos, K. Smarsly // Proceedings of the International ICCCBE and CIB W78 Joint Conference on Computing in Civil and Building Engineering 2020, Sao Paolo, Brazil, 06.02.2020. – 2020. – P. 1–14.
  19. Белый А. А. Концепция мониторинга искусственных сооружений Санкт-Петербурга / А. А. Белый, А. А. Белов, Г. В. Осадчий, К. Ю. Долинский // Дороги : инновации в строительстве. – 2018. – No 71. – С. 58–62.
  20. Белый А. А. Концепция мониторинга искусственных сооружений Санкт-Петербурга (окончание) / А. А. Белый, А. А. Белов, Г. В. Осадчий, К. Ю. Долинский // Дороги : инновации в строительстве. – 2018. – No 72. – С. 58–62.

Дата публикации: 22.12.2020

Принципы построения универсальной платформы непрерывного мониторинга технического состояния инфраструктурных объектов
PDF 0.32Мб
Скачать
 -

Автор статьи

Соавторы: А. В. Шинкаренко, Д. Г. Плотников, А. В. Баните

Другие статьи

Контакты

Остались вопросы?
Обсудим проект?

+7 (812) 775-10-82 (Пн-Пт 9:00 - 18:00 МСК office@ntc-ksm.ru

    Оставьте ваши данные, мы обязательно свяжемся с вами в ближайшее время:

    • Санкт-Петербург, ул. Фучика, д.4, лит. К, БЦ «Альянс», офис 408
    • +7 (812) 775-10-82
    • office@ntc-ksm.ru
    • Мы работаем Пн-Пт с 9:00 до 18:00 МСК