Система контроля жизненного цикла объекта и его инфраструктуры (варианты)
SYSTEM FOR MONITORING AND MANAGING LIFE CYCLE OF OBJECT AND ITS INFRASTRUCTURE AND SYSTEM FOR MONITORING LOCATION AND CONDITION OF PERSONNEL AND (OR) OTHER MOBILE OBJECTS (OPTIONS)

ОБЛАСТЬ ТЕХНИКИ, К КОТОРОЙ ОТНОСИТСЯ ИЗОБРЕТЕНИЕ
Группа изобретений относится к области автоматизированных систем, предназначенных для контроля жизненного цикла объекта и его инфраструктуры.
Заявляемая система позволяет в режиме реального времени получать полную информацию о процессах объекта и его инфраструктуры для контроля и принятия правильных управленческих решений.
УРОВЕНЬ ТЕХНИКИ
Из уровня техники известна система локального позиционирования персонала на крупных техногенных объектах по заявке № RU 2011107164, патент RU №108 184 U1, G08B 19/00, G06K 7/10, опубл. 10.09.2011, содержащая устройство контроля и группу радиомаяков-идентификаторов, по крайней мере, три измерительных приемопередающих устройства, соединенных по радиоканалу приема с группой радиомаяков-идентификаторов и измеряющих расстояние до соответствующих радиомаяков-идентификаторов по уровню принимаемого от них сигнала, а по каналу передачи - соединенных с устройством контроля, определяющим местоположение персонала на объекте, причем, по крайней мере, три измерительных приемопередающих устройства разнесены по площади объекта, а радиомаяки-идентификаторы установлены на персонале.
Недостатком системы по патенту RU №108184 U1, является то, что в предложенной полезной модели отсутствует информация о возможностях работы в различных условиях, в многоэтажных строениях, в том числе не раскрыта возможность работы с переотраженным сигналом, отсутствует возможность определения высотной отметки.
На сегодняшний день технической проблемой в сфере контроля комплексных объектов, в том числе на стадии строительства, является то, что указанный контроль осуществляется сотрудниками компании вручную, либо средствами дорогостоящих сложных комплексов. Например, при строительстве объекта и его инфраструктуры специалистами используется большое количество бумажных носителей, которые не позволяют осуществлять надзор за строительством комплексных объектов достаточно эффективно. Поэтому существует необходимость в комплексной системе, обеспечивающей эффективный контроль за счет визуализации цифровых моделей непосредственно на объекте, в том числе с помощью мобильных устройств.
Также есть необходимость в комплексной системе, обеспечивающей эффективный контроль за счет прохождения виртуальных туров по объектам и их инфраструктуре без очного присутствия специалистов на самих объектах и их инфраструктуре. Виртуальные туры предлагается составлять на основе фото и видео материалов, трехмерных моделей, ортофотопланов, лазерного сканирования, фотограмметрии сделанных, в том числе, посредством камер с беспилотных летательных аппаратов при целенаправленном облете объектов и их инфраструктуры. Одним из необходимых требований для обеспечения контроля и безопасности на объекте или его инфраструктуре является осуществление мониторинга местоположения и состояния персонала, и подвижных объектов, как вне, так и внутри помещений.
ПЕРЕЧЕНЬ УСЛОВНЫХ СОКРАЩЕНИЙ
API - application programming interface, программный интерфейс приложения, интерфейс прикладного программирования.
ArcGis - программное обеспечение для построения ГИС любого уровня.
Autocad - двух- и трехмерная система автоматизированного проектирования и черчения, разработанная компанией Autodesk.
BIM (Building Information Model или Modeling) - информационная модель (или моделирование) зданий и сооружений, под которыми в широком смысле понимают любые объекты инфраструктуры.
С - компилируемый статически типизированный язык программирования общего назначения, сейчас широко применяемый для программирования микросхем, микроконтроллеров.
С++ - компилируемый, статически типизированный язык программирования общего назначения. Поддерживает такие парадигмы программирования, как процедурное программирование, объектно-ориентированное программирование, обобщенное программирование, обеспечивает модульность, раздельную компиляцию, обработку исключений, абстракцию данных, объявление типов (классов) объектов, виртуальные функции.
COLLADA - формат, разработанный для обмена между 3D приложениями.
CPU (Central Processing Unit) - центральный процессор компьютера.
DSL (Digital Subscriber Line) - аббревиатура, обозначающая цифровую абонентскую линию.
dwg и dxf - файлы данных Autocad.
Excel - программа для работы с электронными таблицами.
geo tiff - открытый формат представления растровых данных в формате TIFF совместно с метаданными о географической привязке (геореференцированный растр).
GPS (Global Positioning System) - система глобального позиционирования.
GSM (Global System for Mobile Communication) - глобальный стандарт цифровой мобильной сотовой связи.
HTML (HyperText Markup Language, язык гипертекстовой разметки.
Http (HyperText Transfer Protocol) - протокол прикладного уровня передачи данных изначально - в виде гипертекстовых документов в формате «HTML».
IEEE 802.15.4 - стандарт, который определяет физический слой и управление доступом к среде для беспроводных персональных сетей с низким уровнем скорости.
IPC (Inter Process Communications) - компьютерная технология, обмен данными между потоками одного и/или разных процессов.
J2EE (Java 2 Enterprise Edition) - набор спецификаций и соответствующей документации для языка Java.
Java - строго типизированный объектно-ориентированный язык программирования.
JSF - Java спецификация для построения компонентно-ориентированных пользовательских интерфейсов для веб-приложений, написанный на Java.
JSPX - отдельная страница (web), которая означает, что она может работать без поддержки или базовой страницы.
JVM (Java Virtual Machine) - виртуальная машина Java - основная часть исполняющей системы Java, так называемой Java Runtime Environment (JRE). Виртуальная машина Java исполняет байт-код Java, предварительно созданный из исходного текста Java-программы компилятором Java (javac). JVM может также использоваться для выполнения программ, написанных на других языках программирования.
kmz - файл, в котором хранятся местоположения карт.
Linux - семейство операционных систем.
LoRa - технология модуляции, обеспечивающая большую дальность связи по сравнению с любыми другими стандартами.
LoRa WAN - открытый протокол для сетей LoRa.
Lz77 - алгоритм сжатия данных без потерь.
Maplnfo - географическая информационная система, которая предназначена для сбора, отображения, редактирования, хранения и анализа географических пространственных данных.
MODBUS - открытый коммуникационный протокол, основанный на архитектуре ведущий - ведомый.
OpenCL (Open Computing Language) - открытый язык вычислений, - фреймворк для написания компьютерных программ, связанных с параллельными вычислениями на различных графических и центральных процессорах.
OpenGL (Open Graphics Library) - спецификация, определяющая платформонезависимый (независимый от языка программирования) программный интерфейс для написания приложений, использующих двумерную и трехмерную компьютерную графику.
ORM (ОРМ) - object-Relational Mapping, объектно-реляционное отображение, или преобразование.
PNG - это формат файла, используемый для хранения изображений без потери качества.
POI (point of interest) - объекты точки интереса на карте.
РОЮ (Plain Old Java Object) - простой Java-объект.
PostgreSQL - свободная объектно-реляционная система управления базами данных (СУБД).
Protobuf - формат сериализации, используемый по умолчанию для передачи данных между клиентом и сервером.
RMI (Remote Method Invocation) - программный интерфейс вызова удаленных методов в языке Java.
RS485 - стандарт физического уровня для асинхронного интерфейса.
RTU (Remote Terminal Unit) - удаленное оконечное устройство
Scala - гибридный функциональный язык программирования.
SQL - Structured Query Language, язык структурированных запросов.
TCP (Transmission Control Protocol) - протокол управления передачей, один из основных протоколов передачи данных интернета, предназначенный для управления передачей данных.
TDoA (Time Difference of Arrival) - мультилатерация или гиперболическое позиционирование - процесс определения положения, основанный на разнице во времени прибытия сигнала, излучаемого объектом в направлении трех или более приемников.
Tomcat - частичная реализация JavaEE в той ее части, которая включает Web-приложения.
UDP (User Datagram Protocol) - протокол пользовательских датаграмм, один из ключевых элементов набора сетевых протоколов для Интернета.
UWB (UltraWideband) - беспроводная технология связи на малых расстояниях при низких затратах энергии, использующая в качестве несущей сверхширокополосные сигналы с крайне низкой спектральной плотностью.
VCTXO - кварцевые генераторы с температурной компенсацией ухода частоты с возможностью изменения частоты управляющим напряжением.
Wi-Fi (Wireless Fidelity) - беспроводная передача данных.
Word - программа, текстовый редактор, предназначенный для создания, просмотра и редактирования текстовых документов, с локальным применением простейших форм таблично-матричных алгоритмов.
XML (extensible Markup Language) - расширяемый язык разметки.
АПК обработки информации - аппаратно-программный комплекс обработки информации.
АИС НСК - Автоматизированная информационная система
Независимого строительного контроля на платформе С60.
АУ - абонентское устройство (202).
БД - база данных.
БОСД - блок обработки сигналов датчиков.
БПИ - блок приема информации.
БС - базовая станция (201).
БСМ - базовая станция малая.
БСПТИ - блок сбора и передачи телеметрической информации о состоянии линейного объекта с датчиков.
БСС - базовая станция синхронизации (203).
ГИС - геоинформационная система.
Глонасс - российская спутниковая система навигации, одна из двух полностью функционирующих на сегодня систем глобальной спутниковой навигации.
ИБП - источник бесперебойного питания.
ИТД - исполнительная техническая документация.
К.Н.Д. - коэффициент направленного действия.
ООП - объектно-ориентированное программирование.
Платформа С60 - платформа для разработки комплекса web приложений, разработанная ЗАО «Сервис-Газификация».
СЗИ НСД - средства защиты информации от несанкционированного доступа.
СЛП - система локального позиционирования.
РАСКРЫТИЕ СУЩНОСТИ ИЗОБРЕТЕНИЯ
Задачами, на решение которых направлено заявляемое техническое решение по п. 1 формулы изобретения, являются:
1. мониторинг безопасности объекта и его инфраструктуры;
2. мониторинг местоположения и состояния персонала и иных подвижных объектов;
3. контроль жизненного цикла объекта и его инфраструктуры;
4. объединение всех участников жизненного цикла объекта и его инфраструктуры, например, такого как цикл строительства, включая службы заказчика, технического и авторского надзора, материально-технического обеспечения и подрядных организаций в рамках единой рабочей среды взаимодействия при выполнении строительно-монтажных работ;
5. минимизация дублирования рутинных процедур, возникающих в процессе жизненного цикла объекта и его инфраструктуры.
Задачами, на решение которых направлено заявляемое техническое решение по п. 7 формулы изобретения, являются:
1. мониторинг безопасности объекта и его инфраструктуры;
2. контроль жизненного цикла объекта и его инфраструктуры;
3. объединение всех участников жизненного цикла объекта и его инфраструктуры, например, такого как цикл строительства, включая службы заказчика, технического и авторского надзора, материально-технического обеспечения и подрядных организаций в рамках единой рабочей среды взаимодействия при выполнении строительно-монтажных работ;
4. минимизация дублирования рутинных процедур, возникающих в процессе жизненного цикла объекта и его инфраструктуры.
Техническим результатом, достигаемым за счет использования заявляемой системы по п. 1 формулы, является сбор и анализ данных о жизненном цикле объекта законченного строительства или находящегося в стадии строительства и их инфраструктуры.
Техническим результатом, достигаемым за счет использования заявляемой системы по п. 7 формулы, является сбор и анализ данных о жизненном цикле объекта законченного строительства или находящегося в стадии строительства и их инфраструктуры.
Поставленные задачи решаются, а технический результат по п. 1 формулы изобретения достигается за счет того, что заявляемая система контроля жизненного цикла объекта и его инфраструктуры, на основе АИС НСК строящихся и введенных в эксплуатацию объектов, по п. 1 формулы изобретения включает следующие подсистемы и элементы:
(1) систему контроля за строительством с (2) АПК обработки информации;
(3) систему сбора, передачи, приема, обработки и анализа информации о состоянии объектов технической инфраструктуры, в том числе строящихся и введенных в эксплуатацию объектов, которая содержит:
(4) подсистему мониторинга местоположения и состояния персонала, и подвижных объектов;
(5) подсистему мониторинга состояния неподвижных объектов.
Поставленные задачи решаются, а технический результат по п. 7 формулы изобретения достигается за счет того, что заявляемая система контроля и управления жизненным циклом объекта и его инфраструктуры, на основе АИС НСК строящихся и введенных в эксплуатацию объектов, в том числе таких как объекты промышленного и гражданского строительства по п. 7 формулы изобретения включает следующие подсистемы и элементы: (1) систему контроля за строительством с (2) АПК обработки информации;
(3) систему сбора, передачи, приема, обработки и анализа информации о состоянии объектов технической инфраструктуры, в том числе строящихся и введенных в эксплуатацию объектов, которая содержит:
(4) подсистему мониторинга местоположения и состояния персонала или подвижных объектов;
или (5) подсистему мониторинга состояния неподвижных объектов.
Заявляемая система по п. 1 и п. 7 формулы изобретения по требованию заказчика может быть оснащена подсистемой «Исполнительская техническая документация» и подсистемой обеспечения целостности.
Поставленные задачи решаются, а технические результаты по п. 1 и п. 7 формулы изобретения достигаются также за счет того, что передача данных с датчиков на базовые станции и базовые станции синхронизации осуществляется при помощи автономных электронных средств с настроенной дискретизацией по каналам радиосвязи, передача принятой информации с базовых станций и базовых станций синхронизации собирается на сервере по каналам связи Ethernet, Wi-Fi либо GSM.
Система контроля жизненного цикла объекта и его инфраструктуры, на основе АИС НСК обеспечивает хранение информации об объекте, его характеристиках и текущем состоянии, позволяет долговременно и надежно хранить данные, поддерживать встроенные механизмы целостности данных, обеспечивает непрерывность комплексных бизнес-операций, отказоустойчивость и резервное копирование.
Система контроля жизненного цикла объекта и его инфраструктуры включает:
- систему контроля за строительством (1) с АПК обработки информации;
- систему сбора, передачи, приема, обработки и анализа информации о состоянии объектов технической инфраструктуры.
Данные в систему контроля жизненного цикла и его инфраструктуры поступают постоянно с настроенной дискретизацией для каждого элемента сбора информации. Каждое изменение информации, поступившее в систему становится доступно для пользователя моментально.
Благодаря изобретению решены, в том числе, такие задачи как:
- обеспечение контроля присутствия и передвижения персонала и техники на объектах с учетом допусков в охранные зоны и открытыми наряд допусками, разрешениями на высотные работы, аттестациями в области промышленной безопасности;
- организация оповещения в случае чрезвычайных ситуаций по данным от датчиков;
- контроль покидания работниками зоны ЧС и поиска пострадавших лиц;
- формирование отчетности по посещению производственных объектов.
Все датчики мониторинга и системы локального позиционирования являются автономными устройствами с питанием от аккумулятора или батареи. Данные передаются через систему сбора, передачи, приема, обработки и анализа информации о состоянии объектов технической инфраструктуры.
Для линейных объектов (трубопроводов) используется эстафетная передача данных.
Система контроля за строительством (1)
Система контроля за строительством позволяет осуществлять: управление строительно-монтажными работами; организацию пуско-наладочных работ на вводимых в эксплуатацию, строящихся и реконструируемых объектах; организацию авторского надзора и управление изменениями по объектам; передачу потребности в закупке и инициацию процедур выбора подрядчика (субподрядчиков) или поставщиков для выполнения производственных работ на объектах строительства; мониторинг процессов материально-технического обеспечения; управление отходами производства и потребления; обеспечение безопасности при проведении работ повышенной опасности; обеспечение безопасности при проведении стандартных операций-повышенная опасность. Система контроля за строительством включает:
- АПК обработки информации.
- АИС НСК на программной платформе С60.
- Персональные компьютеры, планшетные компьютеры, смартфоны и терминалы.
- Локально-вычислительные сети для передачи информации.
Процессы, затрагиваемые Системой:
- Управление строительно-монтажными работами;
- Организация пуско-наладочных работ на вводимых в эксплуатацию, строящихся и реконструируемых объектах;
- Организация авторского надзора и управление изменениями по строящимся и реконструируемым объектам;
- Передача потребности в закупку и инициация процедур выбора подрядчика / исполнителя на выполнение производственных работ и оказание услуг в Блоке разведки и добычи;
- Мониторинг процессов материально-технического обеспечения;
- Управление отходами производства и потребления;
- Обеспечение работников средствами индивидуальной защиты;
- Обеспечение безопасности при проведении работ повышенной опасности;
- Обеспечение безопасности при проведении стандартных операций-повышенная опасность.
В системе выделены 4 функциональные роли:
1) Заказчик - осуществляет общий контроль за процессом прохождения заявок и получением статистики;
2) Генподрядчик - осуществляет подачу заявок на осуществление строительного контроля;
3) Строительный контроль - осуществляет строительный контроль, управление и организацию автоматизируемого процесса строительного контроля;
4) Авторский контроль - осуществляет оперативное внесение изменений в проектную документацию.
Общая архитектура системы может быть представлена в виде взаимодействующих подсистем:
Подсистема «Журнал работ» предназначена для отображения сведений о проводимых контрольных мероприятиях по заявкам от Генерального подрядчика и оценке качества принимаемых работ специалистами строительного контроля Заказчика.
Подсистема «Информация» предназначена для обмена текстовыми сообщениями всех участников проекта строительно-монтажных работ в виде публичного чата.
Подсистема «Статистика» предназначена для отображения статистических данных по выбранному объекту работ.
Подсистема «Карта» предназначена для работы с картографическими данными по объектам строительных работ.
Подсистема «Проектный офис» предназначена для работы с заявками на проведение контрольных мероприятий. Заявки формируются как от Генерального подрядчика, так и ответственными специалистами контролирующей организации.
Подсистема «Авторский контроль» предназначена для работы по заявкам, имеющим статус «Отсутствие проектных решений».
Подсистема «Администрирование» предназначена для настройки и управления доступом пользователей в среде системы.
В систему контроля за строительством попадает информация, необходимая для проведения работы, из аппаратно-программного комплекса обработки информации, системы сбора, передачи, приема, обработки и анализа информации о состоянии объектов технической инфраструктуры.
АПК обработки информации (2)
АПК обработки информации позволяет осуществлять: контроль процесса проведения строительно-монтажных работ на соответствие проекту, требованиям нормативно-технической документации, календарному графику и бюджету; выборку и фильтрацию объектов отображения; настройку реакции системы на происходящие события при помощи настраиваемой системы уведомлений; привязку узкоспециализированной информации о подвижных и стационарных объектах.
АПК обработки информации представляет собой программное обеспечение и аппаратную часть, содержащую блоки:
- серверное оборудование для обработки информации.
- свободно распространяемая серверная операционная система Linux.
- свободно распространяемая Система управления базами данных PostgreSQL.
- программная платформа С60.
- локально-вычислительные сети для передачи информации.
В АПК обработки информации входит порядка 100 модулей, приведенных на Фиг. 1. Модули отсортированы сверху вниз по уменьшению абстрактности, в верхней части находятся модули ядра, ниже идут модули подсистем (от зависимостей к зависимым модулям). Заявителем приведены три иллюстрации, на которых изображены модули:
- модули сервера приложений (Фиг. 1);
- модули системы сборки и сервера интеграции (Фиг. 3).
- модули аппаратной части.
Модули сервера приложений (представлены на Фиг. 1).
Сервер приложения работает на Java машине, на переработанном и дополненном стеке технологий J2EE. В качестве сервлет - контейнера используется Tomcat.
scala (1) - модуль, который содержит стандартную библиотеку языка Scala с небольшим количеством доработок.
shared_core (2) - распределенный между клиентом и сервером код ядра, содержащий математические функции (матрицы, линейная алгебра, векторная алгебра, анализ графов, геометрия). Код данного модуля использует только базовые типы данных и коллекции из стандартной библиотеки Scala.
core_decl (4) - модуль, который содержит описание основных интерфейсов (API), используемых на уровне ядра. Обеспечивает возможность проксирования объектов, реализующих данные интерфейсы через RMI протокол, при этом удаленной стороне для работы с объектами нужны только интерфейсы из core_decl, но не само core.
shared_component (3) - модуль, который содержит код для работы с компонентами пользовательского интерфейса, распределенный между клиентом и сервером. Задача данного модуля обеспечить интеграцию клиентской и серверной части на уровне работы компонентов интерфейса.
orm_decl (5) - модуль с декларациями API для работы с ORM через RMI. Так же в системе имеются аналогичные модули gis_decl и map_decl (которые не указаны на схеме).
meta (6) - модуль, который содержит функции для анализа и преобразования абстрактных синтаксических деревьев AST, которые Scala компиллятор строит в результате анализа кода. Метапрограммирование применяется для анализа и проверки исходного кода платформы и прикладных модулей, а так же для генераций и модификации AST.
bootstrap (7) - очищенная от внешних зависимостей часть ядра, не использует сторонние библиотеки (кроме Scala), но может пользоваться стандартными классами Java и рефлексией (что не допустимо для shared_core). Помимо функций общего назначения содержит механизмы двух фазной инициализации приложения и межмодульной инъекции зависимостей (см. ниже).
code_gen (8) - модуль, который отвечает за генерацию java кода и его runtime компилляцию (ЛТ). Содержит набор вспомогательных функций для составления исходников, в частности функции для анализа параметрического полиморфизма в иерархии наследования java классов. Вычисления параметров типа требуется для генерации валидных исходников в случае, если мы создаем наследников класса, использующего параметрический полиморфизм. Имеется функционал для автоматического добавления импортов в генерируемый исходник. Так же модуль содержит кеши, позволяющие избежать повторное создание одинаковых классов.
scalac_plugin (9) - модуль, который представляет собой плагин для компилятора Scala. Позволяет внедрять в процесс компиляции прикладные фазы, фазы встраиваются через межмодульную инъекцию зависимостей от модулей, использующих данный модуль. Прикладную фазу можно расположить между любыми имеющимися в компиляторе фазами. При этом обработчику фазы будет доступна дополнительная информация, относящаяся к платформе С60: для каждого класса задан модуль платформы, к которому он относится. Кроме того, описывается весь список модулей текущего проекта и обозначен головной модуль проекта (который использует все остальные).
core (10) - модуль, содержащий функции общего назначения для работы с текстом, коллекциями, XML, рефлексией, логированием, файловой системой, ant скрипты и прочим. В отличии от bootstrap, данный модуль использует сторонние java библиотеки, что делает его непригодным для работы внутри Scala компилятора (метапрограммирование). Соответственно все модули, работающие с метапрограммированием наследуются от bootstrap, а остальные модули наследуются от core.
jdbc (12) - модуль, в основе которого модифицированная версия jdbc_postgres (проект с отрытым исходным кодом). На уровне внешнего модуля исправлены некоторые ошибки и недочеты, приводящие к снижению скорости работы.
На уровне нашей платформы добавлена поддержка бинарного формата передачи для всех типов данных, передаваемых между сервером приложения и БД.
Добавлена возможность передачи структур данных, которые на стороне Postgres задаются через Row тип. На стороне приложения эти структуры доступны как case class-ы.
За счет расширения (набором плагинов на уровне C/C++) и модификации на стороне сервера баз данных (на базе Postgres 11.1). Добавлен ряд функций общего назначения, в том числе функции для работы с массивами (которые ищут верхнюю и нижнюю границу множества, supremum и infimum).
Добавлен механизм взаимодействия между приложением и БД через общую память, на основе функций межпроцессного взаимодействия (IPC). Для простых запросов, время выполнения которых составляет порядка 3 мкс (на стороне БД), использование общей памяти вместо TCP сокета дает существенный выигрыш, поскольку задержка сокета на локальной петле составляет порядка 30 мкс. В итоге, при переходе на работу через IPC, время выполнения простых запросов сокращается на порядок.
ocl (13) - модуль для интеграции с OpenCL (использование графического ускорителя для массивных вычислений). Взаимодействует с библиотекой jocl. В данном модуле находятся оболочки для повышения работы с функционалом OpenCL (оболочки для буферов и ядер). Так же имеется набор функций для дополнительной обработки openCL кода, позволяющие использовать подобие импортов, а так же настроечные константы.
Так же на уровне данного модуля реализован алгоритм сжатия PNG изображений на стороне видеокарты. Данный алгоритм может быть сопряжен с OpenGL, в котором первоначально генерируется растр. Таким образом, растр сжимается в PNG, не покидая памяти видеокарты, а на сторону CPU приходит уже бинарный поток от сжатого файла.
PNG компрессор включает в себя общий алгоритм сжатия Lz77, реализованный в распараллеленном виде на графическом процессоре. При реализации алгоритма Lz77 использовалось динамическое дерево Хаффмана (которое формирует словарь символов с кодами; часто встречающиеся символы кодируются меньшим числом бит). Формирование PNG на графическом процессоре необходимо для работы высоконагруженного сервера (модуль ГИС), поскольку на сжатие изображений тайла может приходится большая часть вычислительной нагрузки.
gl (14) - модуль интеграции с OpenGL. Взаимодействует с библиотекой jogl и обеспечивает доступ к возможностям OpenGL рендеринга через удобные ООП оболочки на Scala. Содержит оболочки для шейдеров, программ, буферов и текстур. Так же обеспечивает диагностирование ошибки в случае ввода некорректных параметров для OpenGL программы.
network (15) - набор функций и DSL для работы на уровне TCP и UDP, а также для работы с протоколом protobuf.
translator (17) - модуль автоматического перевода пользовательского интерфейса, работает за счет добавления соответствующей фазы в Scala компилятор (подробности смотри ниже).
gpu (18) - модуль для работы с графическим ускорителем, объединяет функционал модулей ocl и gl. Позволяет использовать общие ресурсы между openCL и openGL, в частности можно передать растровый буфер OpenGL в качестве входного буфера OpenCL без копирования данных в память хоста.
graphics (19) - модуль, который определяет формат 2d/3d объектов, имеющих геометрический каркас, класс (набор стилей определяющих способ отрисовки), и принадлежащих к определенному слою/набору.
Также содержит алгоритмы отрисовки соответствующих объектов при помощи OpenGL4. Подобные алгоритмы оформляются в виде стилей, каждый из которых строит определенное отображение поверх геометрического каркаса объектов карты. Каждый тип стиля имеет параметры, задаваемые в конструкторе (такие как цвет, толщина линии и прочее). На уровне карты из этих стилей формируется последовательность (MapClass), которая и определяет оформление объектов на карте.
Модуль может применяться как в составе сервера для отрисовки тайлов веб-карты, а также на клиентской стороне в составе апплета для отрисовки 2D/3D в реальном времени.
orm (16) - модуль, который обеспечивает построение объектно-реляцинонной модели, поиск, загрузку и редактирование SQL данных на уровне объектов модели. Задача модуля - обеспечить работу с данными, хранимыми в БД через ООП прослой на уровне Scala, с поддержкой множественного наследования.
excel (20) - модуль для импорта и экспорта данных в формате excel. Содержит оболочки для работы с функционалом библиотеки POI через Scala фасады.
http (21) - базовый модуль для построения веб - приложений. Содержит обертки для работы с Http протоколом, сервлетами. Реализует RMI с клиентской стороной через Web Socket, позволяет конвертировать JSON структуры в POJO объекты, и case class-ы. Содержит функции для предоставления доступа клиентов к ресурсам сервера, выгружает файлы.
gis (22) - модуль, который обеспечивает работу с геометрической информацией, в том числе с той, которая находится на стороне БД. Реализует и интегрирует набор геометрических функций, таких как пересечение, объединение, поиск, построение буфера, снижение детализации, вычисление площади, длины, конвертации из одной системы координат в другую и прочее.
Так же реализована иерархия классов для поддержки основных типов двумерной геометрии (Point, Multipoint, Line String, MultiLine, Poly gone, Multipolygon, Collection). Реализован текстовый и бинарный формат передачи геометрических данных между БД и сервером приложений (по умолчанию используется бинарный). Реализована возможность передачи геометрии на клиент, через JSON.
map_graphics (33) - промежуточный модуль интеграции между API веб-карты и графическим движком. На данном уровне определен API для объектов веб-карты, имеется доступ к геометрической информации и функциям ее обработки. Так же существует возможность отображения 2d графической информации.
Данный модуль имеет базовый функционал для определения графических объектов карты, поэтому все модули, импортирующие и экспортирующие GIS данные наследуются от данного модуля. Для реализации экспортеров и импортеров существуют аспекты IGisFormatReader и IGisFormatWriter, в которых разработчику нужно реализовать набор методов. При реализации двух вышеупомянутых классов разработчик описывает только те функции, которые непосредственно связаны с чтением и записью внешнего формата, а вопросы дальнейшей обработки и сохранения прочитанных данных берет на себя системная прослойка GIS.
component (24) - модуль интеграции JSF технологии из J2EE стека в подсистему верстки веб - интерфейса. Как было написано выше, целью платформы С60 является обеспечение прикладного разработчика явными средствами разработки (на основе наследования аспектов и системы типов Scala). При этом JSF технология в ее изначальной реализации использует много неявных средств, таких как JSPX страницы, XML дескрипторы для построения библиотек компонентов, конфигурационные файлы faces.config и web.xml.
В связи с этим технология JSF была переработана и дополнена на уровне данного модуля, с тем чтобы весь изначальный функционал компонентов был реализован через явные объекты на языке Scala. При этом за сохранение состояния интерфейса и используемую память теперь отвечают непосредственно классы компонентов (ранее состояние выгружалась в другие объекты (Bean-ы), а сами объекты компонентов были лишь фасадами для наборов атрибутов).
На уровне данного модуля созданы Scala обертки для базового набора компонентов JSF, расширен функционал для частичного обновления страниц.
Созданы функции для взаимодействия между BackEnd и FrontEnd кодом в аспекте IComponentClientListener.
Также добавлен дополнительный набор компонентов:
а) компонент табличной верстки GeoTable, обеспечивает выравнивание внутренних компонентов при помощи табличной верстки с возможностью объединения строк и колонок, задания ширины колонок. Так же компонент предусматривает расположение подписей слева или сверху от содержимого.
б) автодополнение AF_AutoSuggest - осуществляет вывод списка возможных вариантов на основании поиска по тексту. Для поиска можно задать специальный критерий, либо использовать универсальный полнотекстовый. Предусматривает добавление кнопок вставки и удаления, при которых компонент можно использовать для редактирования реестровых данных.
в) WebSocket - компонент активирует связь по веб сокету с текущей страницы.
г) панель с вертикальным и горизонтальным выравниванием.
д) пользовательская статическая html верстка со вставкой других компонентов, строится через Scala xml, в который непосредственно вставляются другие компоненты.
е) динамический html.
ж) FrogressBar.
з) Lazylterator позволяет FrontEnd коду работать с ленивой прогрузкой блоков интерфейса; построен на основе коллекций значений определенного типа. Необходим для отображения коллекций, содержащих большой объем данных.
Также модуль содержит DSL для более удобной верстки интерфейса и расширяет многие механизмы работы JSF.
security (25) - модуль для работы с учетными записями пользователей и распределения прав доступа.
generalization (26) - модуль обеспечивает предварительную обработку GIS данных на этапе импорта. Содержит алгоритмы для снижения детализации различных графических объектов, линий, полигонов, облаков точек, растров. Так же позволяет разбить слишком крупные (по объему данных) геометрические объекты на части (работа с объектами, содержащими слишком большое количество вершин).
Генерализация нужна для улучшения производительности GIS системы когда данные просматриваются в уменьшенном масштабе, когда на экране отображается много объектов, но при этом их детализация уже не так заметна для пользователя.
gis3d (27) - модуль, который содержит определение для 3d геометрии. На данном уровне добавляется возможность работы с треугольными сетками в 3d пространстве (мешами). На уровне приложения был добавлен объект Mesh, и функции для работы с ним (площадь, пересечение, прямоугольное покрытие, топологический анализ, вычисление хеш кода, округление и прочее).
На стороне плагина БД были добавлены следующие типы SQL данных (и классы на стороне приложения)
а) MultiMesh - коллекция мешей, хранит топологически не связанные меши.
б) Ref3d - прямоугольное покрытие 3d объекта.
Для всех видов геометрии реализован бинарный формат передачи.
Для мешей задана процедура канонического преобразования и вычисления хеш кода, благодаря которой, меши отличающиеся друг от друга линейным преобразованием (умножением их координат на матрицу 4x4, в которой определен сдвиг, масштаб, поворот), получают одинаковый канонический хеш код. По каноническому хеш коду можно легко найти в базе аналогичный объект BIM (который был загружен ранее) и вместо полного описания исходного объекта достаточно указать ссылку на клон с заданной матрицей преобразования. Это позволяет многократно сократить объем памяти БД, используемый для размещения BIM моделей предприятий.
map_graphics3d (28) - модуль, который аналогичен map_graphics, но для 3d объектов. Модуль содержит определение API трех - мерных графических объектов, а также расширяет аспекты для импорта и экспорта графических данных (IGisFormatReader и IGisFormatWriter). Данный модуль служит основой для модулей, обеспечивающих поддержку внешних 3d форматов.
2d конвертеры (29) - набор модулей, унаследованных от map_graphics, каждый из которых реализует поддержку соответствующего 2d формата данных. Конвертеры переводят геометрические, семантические данные и оформление из формата в API объектов карты и обратно. Сохранением и дополнительной обработкой данных занимается системная логика. На данный момент поддерживаются следующие форматы: Maplnfo - tab и mif / mid форматы. Растры; Autocad - dwg и dxf; ArcGis - shp; geo tiff; kmz; фотографии с пространственной привязкой; импорт облака точек из excel.
3d конвертеры (36) - набор модулей, унаследованных от map_graphics3d, каждый из которых реализует поддержку определенного набора 3d форматов.
1. dwf - открытый обменный формат, базовая поддержка реализована библиотекой dwf_toolkit. Данный модуль обеспечивает ее интеграцию (из С++ в java) с генерацией склеивающего кода. Модуль обеспечивает загрузку древовидной структуры слоев и объектов BIM с сохранением названий, семантики, геометрии и оформления.
2. assimp - модуль, который построен на основе интеграции открытой библиотеки assimp, поддерживающей около 40 3d форматов. В том числе FBX, IFC, Collada, 3D, 3DS, DXF, 3MF, OBJ и прочее.
срр (11) - модуль, обеспечивающий быструю интеграцию C/C++кода и JVM кода. В основе лежит открытый проект djinni. В представленной платформе функциональность djinni (генерирующая склеивающий код из конфигурационных файлов) дополняется возможностями сборщика платформы, при сборке, сгенерированный С++ и java код автоматически размещается в определенных директориях системы, откуда С++ код подпадает в native сборку, a Java код в приложение. При этом поддерживается принцип модульной компоновки приложения.
interval (30) - группа модулей, которые реализуют алгебру для работы с интервалами. Содержит низкоуровневый модуль, в котором описаны классы интервалов и операции с ними. Под интервалом понимается один из трех случаев:
1) пустой интервал, пустое множество;
2) простой интервал содержит начало и конец (целое или дробное число). Левая и правая границы интервала могут быть бесконечностями;
3) множественный интервал - состоит из отсортированного, непустого, непересекающегося множества простых интервалов.
Основные операции, выполняемые при работе с интервалами:
а) сложение, вычитание;
б) инверсия;
в) проверка на пересечение и включение;
г) сдвиг;
д) определение общей длины;
е) квантификация (интервал, заданный дробными числами можно преобразовать в дискретный интервал при помощи квантификатора). Квантификатор содержит начальную точку отсчета и продолжительность единичного интервала. Так, например, время можно округлять по минутным, часовым, недельным интервалам.
Интервалы играют важную роль в аналитике, когда некоторый процесс разбивается на дискретные интервалы времени (например, объем произведенной работы в сутки).
Далее платформа С60 реализует поддержку интервалов в плагине БД (SQL типы данных+функции, реализованные на уровне C/C++), а также в расширении ОРМ. Таким образом, прикладная логика приложения может осуществлять хранение интервалов на стороне БД, а также выполнять поисково-аналитические операции с ними.
vis (31) - модуль интеграции открытой библиотеки JS компонентов Vis в BackEnd оболочки. Обеспечивает расширенный набор компонентов при верстке пользовательского интерфейса.
widgets (32) - модуль, который содержит набор составных компонентов (комбинаций из других компонентов), а также набор аспектов для задания сложных моделей поведения окон пользовательского интерфейса и коллекций.
tinymce (33) - модуль, обеспечивающий интеграцию открытой библиотеки TinyMCE в платформу. В данном модуле описан компонент, представляющий собой online текстовый редактор наподобие word, с возможностью редактировать текст, вставлять в него различные символы и блоки, таблицы, выводить на печать.
Данный компонент используется при работе с интерактивными отчетами, а также в качестве элемента графического конструктора, позволяющего создавать произвольную html верстку со вставкой других компонентов.
rept (37) - модуль отчетов, построенный на основе возможностей веб верстки, с использованием расширенного текстового редактора из модуля tinymce.
framework7_widgets (34) - группа модулей, первый модуль framework7 наследуется от модуля component и обеспечивает интеграцию открытой библиотеки, специализированной на верстке мобильных приложений. В результате такой интеграции появляется возможность создавать удобный интерфейс для мобильных устройств, библиотека содержит весь ряд компонентов: таблицы, деревья, всплывающие окна, панели с различным выравниванием.
Далее модуль второго уровня framework7_widgets интегрирует набор компонентов и методологию мобильной верстки с модулем widgets, в котором описывается поведение диалоговых окон и коллекций. Таким образом, верстка мобильной и ПК версии имеет схожие механизмы в своей основе, кроме того, некоторые части интерфейса могут быть использованы одновременно на ПК и в мобильной версии.
тар (35) - модуль, на уровне которого описывается пользовательский интерфейс, набор инструментов, панелей и диалоговых окон для работы с картой через web. В основе пользовательского интерфейса лежит компонент для вывода и редактирования GIS графики на стороне клиента. Компонент реализован на основе переработанной и дополненной открытой библиотеки OpenLayers.
Карта поддерживает работу с деревом слоев, выборками объектов, их семантикой. Содержит наборы инструментов для навигации, редактирования и измерений.
map3d (39) - модуль, содержащий расширение двумерной карты для работы с BIM, облаками точек, фотограмметрией и рельефом.
Клиентская часть карты в 3<1-режиме построена на основе интеграции открытой библиотеки Cesium, для которой созданы ScalaJS фасады и клиентская прослойка логики на Scala. Данная прослойка обеспечивает возможность подсветки объектов, составления выборок, вывода всплывающей подсказки с названием объекта, фильтрацию отображаемых на сцене объектов (по выборке или по категории слоя).
Серверная часть модуля поддерживает генерацию в формате 3dTiles, обеспечивающую вывод графических данных BIM, имеющихся на стороне сервера (в основном в БД).
Также сервер поддерживает генерацию terrain тайлов, описывающих рельеф поверхности земли. Изначально данные о поверхности земли могут быть загружены в формате COLLADA в виде треугольной сетки, на определенную площадку.
map_report (38) - модуль, который обеспечивает интеграцию карты в отчеты, для которых нужна графика с дополнительными построениями.
localization (40) - модуль системы локального и глобального позиционирования. Содержит модель для сохранения информации о GPS треках, описание геозон. Поддерживает работу с протоколами Teltonika, а также с базовыми станциями собственной системы локального позиционирования. Обеспечивает уровни контроля местоположения:
1) отображение текущего местоположения и статуса;
2) построение треков с временными отметками и стоянками;
3) отчет о посещении геозон;
4) тепловая карта, отображающая интенсивность посещения определенных участков площадки выбранной группой сотрудников.
Модули клиентской части (представлены на Фиг. 2).
shared_core (2) - модуль общего ядра, с набором математических функций. shared_components (3) - общий модуль компонентов, который работает также и на серверной стороне, содержит общие методы для работы с компонентами пользовательского интерфейса.
vis (31) - клиентская часть для интеграции открытой библиотеки компонентов vis.
map_client (41) - клиентская часть модуля веб-карты, обеспечивает работу инструментов, обладающих сложным поведением. Например, инструмент, позволяющий строить полигоны и полилинии через назначение углов и длин отрезков. Также обеспечивает работу «магнита», который позволяет осуществить точную привязку вершин редактируемой геометрии к другим объектам карты (к линиям, вершинам, или перпендикулярам).
cesium_scala (42) - набор фасадов для открытой JS библиотеки Cesium, позволяющий управлять объектами 3d сцены и задавать дальнейшую логику работы в типизированной среде ScalaJS.
map3d_client (43) - обеспечивает работу с BIM объектами на стороне клиента. Отвечает за:
а) переключение слоев 2d подложки и BIM (обеспечивает соответствующие изменения на стороне 3d сцены);
б) подсветка объекта и его части под курсором, вывод всплывающей подсказки с названием объекта и слоем, в котором он находится;
в) переключение режимов освещений 3d сцены, включение и выключение теней;
г) возможность выбора объекта кликом мыши, а также накопление выборки (+Shift). Подсветка объектов выборки, позиционирование на них;
д) возможность скрывать или отображать только выбранные объекты сцены. Модули системы сборки и сервера интеграции (представлены на Фиг. 3).
swing_component (44) - модуль, содержащий оболочки для Desctop компонентов библиотеки Swing, а так же классы для управления коллекциями. Модуль предназначен для упрощения Desctop верстки в среде Scala.
merger (45) - модуль, который содержит основной набор инструментов для сборки проектов, работы с GIT и SVN репозиториями, ветками, модулями.
merger4idea (46) - плагин для среды разработки IDEA, интегрирующий возможности системы сборки в графическом виде непосредственно в среду разработки. Основные функции:
а) построение проекта в формате Intellij IDEA для выбранного модуля;
б) построение сборщика проекта (содержит только код сборочной части модулей);
в) создание, удаление, редактирование веток;
г) создание, удаление, редактирование групп модулей;
д) создание, удаление модулей, редактирование их зависимостей;
е) обновление структуры существующего проекта;
ж) слияние веток;
з) исключение ревизии из последующей реинтеграции.
Прикладной сборщик проекта (47) - представляет собой набор модулей собираемого проекта, с той же структурой зависимостей, но вместо основного кода в сборщик помещаются подкаталоги assembly от каждого модуля, которые и описывают дополнительную логику сборки на уровне каждого модуля.
Модули полученные из сборочных частей наследуются от модуля merger, таким образом они получают прямой доступ к общему функционалу системы сборки.
Прикладной сборщик, в свою очередь, содержит описание тех задач, которые связаны с данным типом проекта. Например, настройка http сервера, генерация связующего кода между Java и С++, сборка общего jar или war файла, и. т.д.
Таким образом, сборка работает в двух - фазном режиме, на первой фазе плагин IDE или сервер интеграции собирает проект сборщика, компилирует его в исполняемый файл. На второй фазе уже запускается сам прикладной сборщик и решает ту задачу, которая нужна пользователю.
integra (48) - модуль, представляющий собой сервер интеграции, который, основываясь на вышеописанном функционале сборщика, обеспечивает построение проектов и их размещение на промышленных серверах.
Так же на сервере имеются различные вспомогательные функции для разработки и мониторинга. Например, веб-страница для системы автоматического перевода пользовательских интерфейсов.
Система сбора, передачи, приема, обработки и анализа информации о состоянии объектов технической инфраструктуры (3).
Система сбора, передачи, приема, обработки и анализа информации о состоянии объектов технической инфраструктуры собирает данные с датчиков положения объектов, с датчиков контроля доступа, а также данные из подсистем, структурирует, и производит анализ собранных данных в режиме реального времени.
Система сбора, передачи, приема, обработки и анализа информации о состоянии объектов технической инфраструктуры предусматривает следующие подсистемы:
(4) подсистему мониторинга местоположения и состояния персонала и (или) иных подвижных объектов, которая позволяет осуществлять: определение местоположения персонала и транспортных средств, занятых на строительно-монтажных работах, контроль доступа на объект; визуальное отображение на экранах операторов местонахождения выбранных объектов и траектории их движения, включая ориентацию по высоте, за заданный отрезок времени; планирование работ повышенной опасности, формирование наряд-допусков; построение прогнозных моделей о состоянии объекта на основе анализа накопленных данных от датчиков; построение тепловой карты объекта инфраструктуры; контроль нахождения персонала в зоне производства работ повышенной опасности, наличия действующих допусков к производству работ и медицинского осмотра, нахождения на местах производства работ инженерно-технического работника, отвечающего за производство работ и за их качество; отправку сигнала о нахождении объектов в заданных или запрещенных зонах, движении объектов по заданным маршрутам или отклонении от них; оповещение операторов системы о внештатных ситуациях или нарушениях, например, таких как падение, обездвиженный человек, нахождение в области работающего стрелового крана, сближение с действующим автотранспортным средством, контроль превышения скорости движения, свыше установленной режимом на объекте для транспортных средств, окончание действия аттестаций, нахождение в зоне повышенной опасности персонала, не имеющего допуск. Подсистема мониторинга персонала и транспортных средств обеспечивает идентификацию, определение координат, отображение на плане местонахождения контролируемых объектов в пределах территории, охваченной необходимой инфраструктурой, включая сигналы GPS. Подсистема мониторинга персонала и транспортных средств позволяет накапливать, обрабатывать и хранить информацию о местонахождении и перемещениях персонала, транспортных средств, мобильных механизмов с целью мониторинга технологических и бизнес-процессов, сигнализации об отклонениях от регламентов, а также с целью ретроспективного анализа тех или иных процессов и ситуаций;
(5) подсистему мониторинга состояния неподвижных объектов, которая осуществляет сбор данных с датчиков, накопление данных и предобработку. Отправка обработанных данных измерений на центральный диспетчерский пункт. В системе реализован прием и передача данных через различные каналы связи, такие как LoRa, Ultra Wideband и другие каналы связи стандарта.
Кроме того, система сбора, передачи, приема, обработки и анализа информации о состоянии объектов технической инфраструктуры содержит следующие элементы: БСПТИ и БПИ.
Изделие БСПТИ является автономным устройством с батарейным питанием, передающим информацию с БОСД в автоматическом режиме с использованием модуляции LoRa в частотном диапазоне 433 МГц или 868 МГц.
Изделие БСПТИ производит эстафетную передачу данных до БПИ вдоль линейного объекта с максимальной длиной участка не менее 50000 м и расстоянием между соседними БСПТИ не менее 1000 м, оптимальное размещение 2000 м.
Принцип работы эстафетной передачи данных системы сбора, передачи, приема, обработки и анализа информации о состоянии объектов технической инфраструктуры.
Передача осуществляется от БСПТИ к БСПТИ по радиоканалу посредством алгоритма эстафетной передачи данных с возможностями пропуска единичного БСПТИ в случае выхода из строя или плохих условий приема.
Реализация основного протокола работы подсистемы эстафетного сбора данных.
1. Автоматическая синхронизация отдельных модулей БСПТИ при включении в различное время на удалении друг от друга:
- синхронизация ведется по часам реального времени с синхронизацией их с помощью Глонасс/GPS;
- для работы подсистемы требуется радиовидимость между модулями БСПТИ.
2. Передача данных по эстафете в соответствии с заданным расписанием:
- данные по радиоканалу LoRa передаются со скоростью не менее 180 бит/с.
- объем данных одной посылки - 150 байт (полученных с датчиков БОСД), плюс 30 байт данных о состоянии модуля БСПТИ. Данные передаются в три приема по 60 байт;
- после каждого подпакета (60 байт) с БСПТИ №N на №(N-1) передается подтверждение о приеме с БСПТИ №(N -1) на №N;
- если подтверждения не получено, выполняется повторная передача этого же подпакета;
- повторная передача производится три раза; при не поступлении ответов с трех раз, система переходит в режим ожидания следующей посылки.
3. Передаваемые данные принимаются БПИ, реализованной на основе модуля БСПТИ с обработкой на одноплатном компьютере.
4. Обработанные данные через Ethernet или модем на основе GSM модуля передаются на Сервер.
В системе используется принцип чередования режимов работы автономных электронных средств («спящий» режим и «рабочий» режим, по заданному алгоритму).
КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ
Фиг. 1 - модули сервера приложений. Модули, помеченные символом «*» на Фиг. 1 входят в состав клиентской (FrontEnd) части платформы.
Фиг. 2 - модули клиентской части. Модули, помеченные символом «*» на Фиг. 2, используются и в серверной части.
Фиг. 3 - модули системы сборки. Модули scala (1), shared_core (2), core_decl (4), bootstrap (7), core (10) те же самые, что и у сервера приложений. Также на схеме не указано наследование модуля integra (48) от модуля widgets (32).
Каждому модулю на Фиг. 1, Фиг. 2, Фиг. 3 присвоено свое условное обозначение:
1 - scala;
2 - shared_core;
3 - shared_component;
4 - core_decl;
5 - orm_decl;
6 - meta;
7 - bootstrap;
8 - code_gen;
9 - scalac_plugin;
10 - core;
11 - cpp;
12 - jdbc;
13 - ocl;
14 - gl;
15 - network;
16 - orm;
17 - translator;
18 - gpu;
19 - graphics;
20 - excel;
21 - http;
22 - gis;
23 - map_graphics;
24 - component;
25 - security;
26 - generalization;
27 - gis3d;
28 - map_graphics3d;
29 - 2d конвертеры;
30 - interval;
31 - vis;
32 - widgets;
33 - tinymce;
34 - framework7_widgets;
35 - map;
36 - 3d конвертеры;
37 - rept;
38 - map_report;
39 - map3d;
40 - localization;
41 - map_client;
42 - cesium_scala;
43 - map3d_client;
44 - swing_component;
45 - merger;
46 - merger4idea;
47 - Прикладной сборщик проекта;
48 - integra.
Фиг. 4 - схема алгоритма эстафетной передачи. Условные обозначения операций, приведенных на Фиг. 4:
100 - начало;
101 - чтение расписания передач БСПТИ массив tTx[];
102 - формирование расписания приема БСПТИ tRx[];
103 - настройка СОМ-порта BaudRate=57600 DataBits=8, StopBit=1, No Parity;
104 - настройка RN2483 LoRa;
105 - чтение системного времени Т;
106 - T=tTx[i]?;
107 - T=tRx[i]?;
108 - прием данных от БСПТИ i=N+1;
109 - транспортировка данных на следуюгций БСПТИ i=N-1;
110 - получение данных Data;
111 - передача данных на следующий БСПТИ i=N-1;
112 - да;
113 - нет.
Фиг. 5 - вариант размещения системы локального позиционирования на объекте.
Условные обозначения позиций на Фиг. 5:
201 - БС;
202 - АУ;
203 - БСС;
204 - сервер обработки данных;
205 - Ethernet.
Фиг. 6 - структура кадра.
Условные обозначения элементов на Фиг. 6:
300 - кадр №0;
301 - кадр №1;
302 - синхросигнал;
303 - данные с АУ 202, тайм-слот 0;
304 - аварийный тайм-слот;
305 - t;
306 - SS;
307 - DO;
308 - Dl;
309 - D2;
310 - D3;
311 - D4;
312 - D5;
313 - D6;
314 - D7;
315 - AC.
ОСУЩЕСТВЛЕНИЕ ИЗОБРЕТЕНИЯ
Система по п. 1 и п. 7 формулы изобретения работает следующим образом: данные, полученные от системы контроля за строительством, от системы сбора, передачи, приема, обработки и анализа информации о состоянии объектов технической инфраструктуры единовременно или поочередно поступают на сервер подсистемы управления базами данных и приводятся в структурированный вид. Полученные и структурированные данные от сервера подсистемы управления базами данных поступают на сервер приложения, после чего, посредством программного обеспечения производится анализ полученных данных и вывод структурированной информации.
Пример реализации системы контроля жизненного цикла объекта и его инфраструктуры и система мониторинга местоположения и состояния персонала и (или) подвижных объектов при строительстве газоперерабатывающего завода.
Система реализована и позволяет решать следующие производственные задачи:
- централизация проектной, нормативной, строительной, пространственной и исполнительской информации в рамках проведения строительно-монтажных работ, его объектах, плановых и фактически принятых объемах работ, систематизация данных:
- обеспечение единства пространственной информации на базе единых требований к информационному наполнению системы и графическому отображению данных на основе единой программной платформы и организационных мер;
- обеспечение взаимодействия участников строительства в едином цифровом пространстве с возможностью формирования требований и контроля исполнительной дисциплины;
- дистанционный мониторинг и диспетчеризация за эксплуатационными характеристиками инженерной инфраструктуры объекта, в том числе:
- температура и влажность воздуха, необходимые для контроля точки росы, в покрасочных камерах, средствами датчиков Smart-HSOlOl с встроенным передатчиком LoRa;
- температурно-прочностной контроль бетона при возведении монолитных конструкций в зимний период, датчиками ТД-11 с встроенным передатчиком LoRa;
контроль вибрации металлоконструкций датчиками MPU6500, подключенными через БСПТИ;
- мониторинг деформации конструкций, датчиками НХ-711, подключенными через БСПТИ;
- мониторинг перемещения и смещения фундаментов, датчиками угла наклона ИН-ДЗц 720, подключенными через БСПТИ;
- контроль напряженности металла тензометрами, датчиками НХ-711, подключенными через БСПТИ;
- контроль давления газа и жидкости при проведении испытаний, цифровыми манометрами, подключенными через БСПТИ;
- контроль наличия утечек, датчиками SPH0645LM4H, подключенными через БСПТИ;
- единая система сбора, хранения, обработки и визуализации статистических данных и соответствующих средств и интерфейсов для работы с ними;
- обеспечение оперативного доступа ответственных за организацию строительства лиц к данным строительного контроля, отчетности, средствам анализа и прогнозирования с использованием BIM технологий;
- контроль присутствия и передвижения персонала и техники на объекте с учетом геопозиционирования.
В зависимости от требований заказчика система контроля жизненного цикла объекта и его инфраструктуры, на основе автоматизированной информационной системы независимого строительного контроля строящихся и (или) введенных в эксплуатацию объектов может включать различные подсистемы и (или) модули, например, такие как:
A) подсистема «Исполнительная техническая документация»; Б) подсистема обеспечения целостности;
B) система виртуальных туров по объектам строительства;
Г) система управления правами доступа к данным информационной системы.
А) подсистема «Исполнительная-техническая документация» предназначена для ведения архива исполнительно-технической документации, оформленной в установленном порядке, и предъявленной исполнителями при приемке работ и при приемке объекта капитального строительства в эксплуатацию. На основе данной подсистемы организуется постоянное хранение исполнительной технической документации, которая используется в последующем в процессе эксплуатации объекта капитального строительства.
Подсистема реализует следующие бизнес процессы работы с документацией ИТД: размещение документов ИТД на хранение; внесение изменений в ИТД, обеспечение версионности ИТД; согласование и утверждение документов ИТД.
Указанные бизнес процессы должны настраиваться для конкретного объекта строительства.
В подсистеме должна быть обеспечена следующая функциональность: организация производственного документооборота в электронном виде по согласованию документов и передаче в архив на основе подсистемы «ВРМ»; размещение исполнительной технической документации по объекту строительства, ее классификация и каталогизирование; привязка документов ИТД к графическим объектам подсистемы «Отображения пространственных данных BIM / GIS / CAD»; обеспечение совместного доступа участников СМР для просмотра исполнительной технической документации; подписание документов ИТД усиленной квалифицированной электронной подписью; поиск размещаемых документов и построение выборки по заданным параметрам; сквозной переход от размещаемых документов к связанным объектам других подсистем с выделением связанных объектов в другой подсистеме; проверка качества и полноты, размещаемой исполнительной технической документации.
Б) Подсистема обеспечения целостности позволяет обеспечивать целостность программных средств СЗИ НСД, а также неизменность программной среды. При этом целостность СЗИ НСД проверяется при загрузке системы по контрольным суммам компонент СЗИ; целостность программной среды обеспечивается использованием трансляторов с языков высокого уровня и отсутствием средств модификации объектного кода программ в процессе обработки и (или) хранения защищаемой информации.
В) система виртуальных туров по объектам строительства представляет собой CADVBIM систему, которая позволяет осуществлять: просмотр и редактирование пространственных объектов в режиме 2D или 3D; просмотр и редактирование атрибутов пространственных объектов, а также мест их расположения; печать графических форм (отчетов); поиск объектов по запросам пользователей; импортировать данные в различных графических форматах хранения данных с привязкой к любым системам координат.
Кроме того, система виртуальных туров по объектам строительства позволяет визуализировать информацию системы сбора, передачи, приема, обработки и анализа информации о состоянии объектов технической инфраструктуры. Система виртуальных туров по объектам строительства реализует следующие функциональные возможности: отображение информации о мониторинге состояния объекта в 2D или 3D; выведение информации данных мониторинга в заданном формате; выведение предупреждения и информации по заданным параметрам; осуществление поиска элементов объекта с привязкой к точкам мониторинга; визуализация состояния показателей жизненного цикла объекта и его инфраструктуры в 2D или 3D.
Г) система управления правами доступа к данным информационной системы позволяет осуществлять: регистрацию или удаление пользователей и организаций, управление правами доступа к системе в соответствии с правилами доступа, устанавливаемыми для групп пользователей и определением предустановленной функциональной роли (заказчик, технический заказчик, генеральный подрядчик, подрядчик, строительный контроль, авторский контроль); назначение прав пользователей к различным подсистемам и технологическим режимам работы; назначение прав пользователей к пространственным данным.
Принцип работы подсистемы мониторинга местоположения и состояния персонала, и подвижных объектов с высокоточным позиционированием на основе UWB радиоканала.
Подсистема с высокоточным позиционированием включает независимую подсистему высокоточного локального определения местоположения объектов на ограниченной территории. Подсистема включает следующий набор элементов:
1) радиомодуль, располагающийся в составе АУ 202, либо выполненный в независимом корпусе;
2) сеть базовых станций.
В основе подсистемы лежит возможность высокоточного замера времени полета (ToF Time of Fly) сигнала от АУ 202 до опорных станций. Погрешность замера времени составляет 3Е-10, что эквивалентно 0,1 м. Замер времени полета сигнала осуществляется на основе приемопередатчика DW1000 (или аналог), дальность работы 250 м, время одного замера 1 мс. Например, при опросе один раз в 3 секунды, на площадке может работать одновременно 3000 радиометок.
Синхронизация БС 201: для точного замера времени все опорные БС 201 должны иметь общую шкалу времени, к которой и привязывает момент прихода сигнала от АУ 202. Для этого используется одна станция с эталонным генератором частоты, использующим синхронизацию с GPS через секундный импульс (1PPS). Секундный импульс, выдаваемый GPS чипом (например, Sim68e) имеет джиттер (фазовое дрожание цифрового сигнала данных) 1Е-8, что достаточно много для нашей задачи. Поэтому на эталонной станции используется высокоточный VCTXO генератор (точность 5Е-10), который позволяет сгладить секундный джиттер за счет синхронизации один раз в минуту.
Далее эталонная БС 201 в каждом кадре (продолжительность кадра порядка 50 мс) выдает синхроимпульс по UWB каналу. Соседние станции получают этот импульс, вычитают задержку на время полета сигнала (расстояние до эталонной станции они могут замерить за счет радиорулетки, либо оно задается из геодезической привязки станции к общей системе координат). Остальные станции по каскаду посылают синхроимпульс дальше (ретранслируют его с фиксированной задержкой). Таким образом, синхроимпульс от эталонной станции по каскаду доходит до каждой станции, участвующей в системе локального позиционирования.
Вычисление положения радиометки: в начале кадра все БС 201 получают привязку к общей шкале времени, после этого АУ 202, зарегистрированные в данном кадре по порядку, выходят в эфир. БС 201 фиксируют время прилета сигнала от АУ 202 в общей шкале времени. Далее данные со всех станций пересылаются на сервер через многоканальный меш. По каждой радиометке сервер выбирает наиболее достоверные замеры времени (меток нужно минимум 4 для позиционирования в пространстве по 3 координатам в пространстве). После этого сервер использует алгоритм TDoA (Time Difference of Arrival) и по разности прихода сигнала вычисляет местоположение радиометки. При использовании алгоритма TDoA, импульс от радиометки получается широковещательным, он обрабатывается сразу всеми станциями, и нет необходимости обмениваться с каждой станцией отдельно, как в случае с радиорулеткой (ToF). В случае TDoA каждая БС 201 задает гиперболоид возможных местоположений радиометки, область их приблизительного пересечения и будет положением АУ 202.
Сеть базовых станций имеет аппаратный и программный набор модулей для построения многоканальной сети ретрансляторов (использующей приемопередатчики различных типов). Поверх физических каналов реализованных в наборе приемопередатчиков, строится меш с динамической маршрутизацией для передачи данных по TCP IP / UDP протоколам от одной точки меша к другой, либо к внешнему серверу за счет LTE модема, Wi-Fi или Ethernet 205. TCP IP / UDP строится на основе стека, реализованного во FreeRtos (или эквиваленте). При построении меша используются следующие каналы связи (соответствующие аппаратные и программные модули):
а) приемопередатчик Si4461 с мощностью выходного сигнала 16 дБм. Обеспечивает передачу данных на 1800 м при скорости 1 Мбит. Пассивная часть настроена на частоту 433 МГц.
б) приемопередатчик с мощностью до 20 дБм, работает на частоте от 800 до 900 МГц.
в) приемопередатчик с усилителем до 27 дБм, предназначен для передачи данных на большие расстояния в спектре от 350 до 450МГц.
г) UWB приемопередатчик, на микроконтроллере DW1000 (или аналог). Имеет 7 сверхширокополосных каналов от 3.5 до 7 Гц, обеспечивает передачу данных, точную синхронизацию и высокоточное позиционирование с погрешностью 0,1 м. Дальность связи составляет 250 м, скорость передачи данных 6.5 Мбит.
д) LTE модем 4 категории, например, на базе чипа SIM7600E-H (или аналог). Обеспечивает возможность работы с серверами и пользователями по сети Интернет через мобильные сети. Поддерживает стандарты (FDD и TDD)/H SPA+/H SDPA/UMT S/EDGE/G SM. Скорость работы до 150(DL)/50(UL) Мбит/с. Также данный модуль имеет встроенный Linux (Open Embedded), что позволяет развернуть на данном модеме Open VPN клиент и построить виртуальную частную сеть с собственным адресным пространством, в котором каждая станция меша и сервисы имеют IP адреса, выделенные по определенным правилам. За счет построения частной локальной сети, имеется возможность передачи данных между различными компонентами меша на разных объектах по Интернету. Также на БС 201, оснащенных модулем LTE имеется возможность установки Open SSH сервера, что позволяет в дальнейшем осуществлять их администрирование стандартными средствами.
Приведенные примеры реализации вариантов изобретения означают, что конкретные признаки и характеристики, описанные в примерах реализации, включены в состав, по меньшей мере, одного из вариантов осуществления. В тексте приведены несколько вариантов реализации изобретения. Подсистемы изобретения, компоновка и реализация, в том числе характеристики, конкретной модели, могут быть объединены любым подходящим образом в одном или нескольких вариантах осуществления.
Термины и определения, использованные в тексте, применяются в качестве описания и не являются исключительными, могут быть заменены на аналогичные.
Пример реализации принципа эстафетной передачи данных. Передаваемые на БПИ и впоследствии на Сервер данные содержат в себе следующую информацию: БСПТИ№1.
Датчик №1: Измеренное значение.
Датчик №2: Измеренное значение.
Датчик №3: Измеренное значение.
Датчик №4: Измеренное значение.
Датчик №5: Измеренное значение. Устройства для работы в составе конвейерной передачи информации вдоль протяженных объектов.
К устройству подключается измерительное оборудование, например, по протоколу MODBUS RTU через RS485 интерфейс (или иной аналогичный).
Структура передаваемого пакета данных устройства, которая включает в себя данные измерений, получаемых от измерительного оборудования, связь с которым устанавливается по стандартизированному протоколу обмена информацией, например, MODBUS RTU или аналогичному, а также поля для передачи диагностической информации, которая включает в себя номер устройства, отношение сигнал/шум, температуру, влажность, время, номер пакета передачи информации, данные с измерительного оборудования.
Показано, что для обеспечения продолжительности работы в течение 1 года с выбранным элементом питания (емкость 17 Ач) при требуемом объеме передачи данных (256 байт) необходимо жесткое ограничение времени работы передатчиков и приемников. Временные окна должны быть минимальными. Поэтому потребуется жесткая временная привязка и точный контроль хода системных часов. При указанных условиях ориентировочное число выходов в эфир при большом числе точек модулей устройства (БСПТИ) (порядка 20 и более) - не более 1-2 раз в сутки.
Схема алгоритма эстафетной передачи приведена на Фиг. 4.
Возможности устройства по обеспечению дальности радиосвязи в условиях, приближенных к планируемой работе (передача данных по радиоканалу вдоль трубы газопровода). Особенность состоит в том, что:
1) антенны не могут располагаться высоко (не более 1-1,5 м над землей);
2) радиосвязь в условиях «плохой» прямой видимости;
Число модулей устройств=п с номерами по мере удаления от базовой станции:
БСПТИ #1 БСПТИ #2 БСПТИ #3
БСПТИ #п
Базовая станция БСПТИ с номером #0 Отсчет номеров БСПТИ в блок-схеме ведется от текущего номера ECnTH=N, где N+1 - впереди стоящий модуль, N-1 - модуль, стоящий после.
Расчет дальности радиоканала передачи БСПТИ.
Рассчитаем дальность радиосвязи, обеспечиваемую передатчиком и приемником в свободном пространстве при отсутствии внешних помех.
Пусть радиоканал (система радиосвязи) имеет рабочую частоту 434 МГц (длина волны X=0,69 м).
Передатчик с антенной типа полуволнового вибратора - К.Н.Д.: D=1,64, излучает мощность Ризл=10 мВт.
Приемник характеризуется следующими параметрами.
Приемная антенна - тоже полуволновый вибратор, К.Н.Д. D=1,64. Эффективная площадь:
эв
S - эффективная площадь антенны, м;
D - диаметр антенны, м;
X - длина волны антенны, м.
Выходное сопротивление антенны является активным=73 Ом.
Полоса пропускания приемника Δf=125 кГц (в соответствии с данными на радиоканал LoRa).
В режиме максимальной помехоустойчивости по данным описания аппаратуры LoRa прием сигналов осуществляется при минимальной мощности -137 дБм (2.10-17 Вт).
Это значение пороговой чувствительности соответствует коэффициенту шума Fcp=4 (6 дБ).
Минимальное отношение сигнал/шум α=-20 дБ. Порог чувствительности приемника:
порог
Р - порог чувствительности приемника антенны, Вт;
k - постоянная Болыгмана;
Т - температура, С°;
cp
F- коэффициент шума, дБ;
пр
Δf - шумовая полоса приемника, Гц;
α - расстояние от оптической системы до предмета, м.
При входном сопротивлении приемника 50 Ом пороговое значение входного напряжения составляет 0,032 мкВ.
При этих данных максимальная дальность радиоканала LoRa в свободном пространстве:
max
R - максимальная дальность радиоканала, м;
изл
Р - мощность излучения, Вт;
nep
D - диаметр передающей антенны, м;
эф
2
S - эффективная площадь антенны, м;
вхмин
Р - мощность входа минимальная, Вт.
max
При таких параметрах и условиях потенциал радиоканала (максимальная дальность) составляет R=2000 м.
Если рабочую частоту выбрать 868 МГц, то при той же мощности передатчика и при такой же чувствительности приемника, с антеннами типа полуволновых вибраторов в передатчике и приемнике дальность радиосвязи составит 1000 м.
При прочих равных условиях в 4 раза будет меньше эффективная площадь приемной антенны.
Увеличение дальности как на частоте 434 МГц, так и на частоте 868 МГц может быть получено за счет применения антенн с увеличенной направленностью.
Дальность радиоканала в реальных условиях (с учетом действия преград и поглощения). Наличие преград на пути распространения радиоволн существенно уменьшает дальность радиоканала. При радиосвязи в условиях города (с преградами) плотность потока мощности, излученной передатчиком, ослабляется значительно быстрее, чем в свободном пространстве:
П - плотность потока мощности;
изл
Р - мощность излучения, Вт;
R - дальность радиоканала, м.
Закон изменения плотности потока мощности принимает вид:
0
0
где R>R, a R - расстояние до первой преграды. Показатель степени п характеризует дополнительное ослабление потока мощности из-за действия преград. Величина п может принимать значения от 0 до 3.
0
Дальность радиосвязи с преградами, при n=2 и R=10 м, при параметрах передатчика и приемника, описанных выше, составляет:
вхмин
Р - мощность входа минимальная, Вт;
k - постоянная Болыгмана;
Т - температура, С°;
cp
F - коэффициент шума, Дб;
пр
Δf - шумовая полоса приемника, Гц;
α - расстояние от оптической системы до предмета, м;
max
R - максимальная дальность радиоканала, м;
0
R - расстояние до первой преграды, м;
изл
Р - мощность излучения, Вт;
пер
D - диаметр передающей антенны, м;
эф
2
S - эффективная площадь антенны, м.
При n=3 дальность радиосвязи будет еще меньше.
Степень ослабления радиоволн при распространении существенно зависит от условий внешней среды и, в частности от расположения антенн. Расположение антенн низко над землей увеличивает потери за счет поглощения окружающими предметами, в том числе земной поверхностью. Дальность будет также ограничиваться за счет не плоскости земли. Без учета неровности рельефа, за счет сферичности земли дальность прямой видимости составляет 7000 м при установке антенн на высоте 1 м.
Экспериментальные данные по дальности радиосвязи, полученные в данной работе, дали величину, равную 2500-3000 м. Это соответствует простым расчетам, приведенным выше.
Принцип работы подсистемы мониторинга местоположения и состояния персонала, и подвижных объектов.
Состав функции компонентов:
1. АУ 202 - малогабаритные с батарейным питанием изделия, размещаемые на подвижных объектах или у персонала. АУ 202 оснащены:
1.1. микроконтроллером, управляющим взаимодействием всех компонентов;
1.2. радиомодулем LoRa для связи с БС 201;
1.3. GPS/ГЛОНАСС приемником для определения координат;
1.4. барометрическим датчиком для контроля изменения высоты;
1.5. акселерометром для определения двигательной активности;
2. БС 201 - приемопередающие устройства, располагаемые на территории контролируемого объекта для связи и управления АУ 202. БС 201 имеют в своем составе:
2.1. одноплатный компьютер, управляющий всеми составными частями;
2.2. радиомодули в количестве 7 штук для осуществления связи по 6 каналам и один в горячем резерве;
2.3. GPS-ГЛОНАСС приемник с выносной антенной;
2.4. выносной датчик температуры наружного воздуха;
2.5. GSM маршрутизатор;
2.6. модуль Wi-Fi (в составе одноплатного компьютера);
2.7. блок питания с функцией ИБП со встроенными аккумуляторами;
2.8. блок поддержания микроклимата с нагревателем и терморегулятором.
3. Сервер и сетевое оборудование: получение данных от БС 201, отображения информации в логах и на карте; ведение базы данных АУ 202, учет, регистрация, перерегистрация, снятие с регистрации; осуществление настройки системы, подача команд конфигурации на БС 201; передача на БС 201 прошивок АУ 202 и эфемеридной информации; индикация поступающих тревожных сигналов с АУ 202; передача тревожных сигналов на АУ 202.
Принцип работы
Система, для обеспечения приема информации с большого числа АУ 202, построена по принципу тактируемого приема. Для этого в эфир излучаются синхроимпульсы, несущие информацию о том, какие АУ 202 должны передавать информацию в ближайшую секунду. Такое построение системы дает возможность организовать работу АУ 202 на коротких интервалах времени, т.е. большую часть времени АУ 202 "спит", а включается только на момент передачи данных и определения своих координат. С целью получения наиболее качественной связи с наименьшими энергетическими затратами, а также с наибольшей способностью работать в условиях многолучевого приема, используются сигналы в частотном диапазоне 868 МГц с модуляцией LoRa. Для обеспечения совместимости с возможным пересечением с устройствами, работающими по протоколу LoRaWAN основной шириной канала связи выбрана величина 250кГц и, следовательно, в указанных частотных диапазонах размещается 6 частотных каналов. С целью минимизации межканального взаимодействия и создания частотных интервалов для части каналов установлена ширина спектра 125кГц. Каждое сообщение, передаваемое по радиоканалу, имеет в своем начале преамбулу 8 байт и в конце передается контрольная сумма. Радиомодули самостоятельно выделяют отдельные сообщения из потока, сравнивают контрольные суммы и отбрасывают неправильно принятые пакеты.
БС 201 размещаются на территории объекта контроля. Одна из БС 201 выбирается в качестве синхронизирующей (БСС 203) и размещается по возможности выше и ближе к центру объекта. Дальность действия БСС 203, как правило, составляет 2000 м. Остальные БС 201 служат для приема сигналов с АУ 202 и располагаются таким образом, чтобы покрыть всю территорию объекта. Интервал размещения БС 201 друг относительно друга желательно на расстоянии до 1000 м. Информация с БС 201 и БСС 203 собирается на сервере по каналам связи Ethernet 205, Wi-Fi либо GSM (см. Фиг. 5).
В качестве основного способа определения местоположения АУ 202 на территории объекта задан метод с использованием глобальных навигационных спутниковых систем, заключающейся в применении специализированных модулей самостоятельно принимающих спутниковую информацию и вычисляющие координаты АУ 202. В качестве энергосберегающего режима работы приемника GPS используется Periodic Standby, который характеризуется попеременной работой. Этот режим позволяет удлинять время работы приемника при необходимости скачивания эфемерид со вновь появляющихся спутников, а также укорачивать время работы приемника при быстром нахождении навигационного решения.
SF
Для реализации системы с тактированием в эфир по первому каналу излучаются синхроимпульсы с периодом 1 сек. Информация с АУ 202 передается с использованием модуляции LoRa, т.е. с расширением спектра - использование линейной частотной модуляции каждого импульса. И режимом накопления, так называемый спред (J)aKTOp(SF), который говорит о количестве элементарных посылок на один бит. Выбран SF=9 и, следовательно, каждый бит передается 2 импульсами. Для каналов с шириной спектра 125КГц спред фактор SF=8 с целью сохранения скорости передачи информации. Таким образом, на любом канале время передачи одного сообщения с АУ 202 составляет - 92 мс. По одному частотному каналу возможно передать информацию с восьми АУ 202 в течение одной секунды. Таким образом, при интервале опроса 1 мин по одному каналу можно опросить 480 АУ 202.
Время необходимое на опрос всех АУ 202 указано в таблице 1.
С целью осуществления контроля за изменением высоты расположения АУ 202 в его составе имеется барометрический датчик. Значения атмосферного давления передаются в сообщении с АУ 202 и анализируются сервером с целью выявления нарушения возможных запретов нахождения на высоте.
Работа с датчиками АУ 202:
1) датчик давления (в АУ 202 применяются датчики давления, такие как BMP-180, ВМР-280, DPS310 или аналогичные). Принцип действия датчика давления BMP: в датчике имеется герметичная камера, одна из стенок которой является гибкой мембраной с установленными на ней тензодатчиками. Мембрана прогибается пропорционально разности давлений внутри камеры и снаружи, что влияет на изменение сопротивления тензодатчиков электрическому току. Так же имеется термодатчик, сопротивление которого меняется пропорционально температуре.
2) датчик ускорения (с целью определения двигательной активности АУ 202 применен трех осевой датчик ускорения MMA8451Q или аналог). Микроконтроллер АУ 202 производит измерение ускорения по трем осям с интервалом 10 с и находит максимальное изменение ускорения по каждой оси. Эти изменения сравниваются с порогом и принимается решение о наличии или отсутствии двигательной активности. Значения изменения ускорений по осям сравниваются с порогами и устанавливается флаг двигательной активности 1, 2 или 3. Минимальная двигательная активность соответствует изменению суммарного вектора ускорения примерно на 7 градусов.
На основе датчика ускорения сформирован так же датчик удара. По прерыванию происходит измерение ускорения и заполняется буфер из 32 значений. После чтения буфера контроллер выбирает максимальное значение ускорения. Буфер заполняется после прихода прерывания по детектору начала быстрого движения с частотой 200 Гц.
Синхронизация
АУ 202 оборудовано радиомодулем LoRa (RFM95 или аналог), который принимает синхроимпульсы по первому каналу.
Каждый синхроимпульс содержит информацию:
0) NumObj - номер объекта, где производится контроль;
1) chnl - номер БСС 203, соответствующий частотному каналу=1;
2) intl - период опроса всех АУ 202, из таблицы 2.
3) cadr1 - номер кадра старший байт (меняется последовательно);
4) cadr2 - номер кадра младший байт (меняется последовательно);
5) comm - команда: таблица значений;
6) argum - аргумент команды;
7) powl - мощность передатчиков АУ 202 в дБм (от 1 до 17);
8) sleepL1 - интервал долгого сна АУ 202, значения из таблицы 2, где долгий сон - состояние АУ 202, в которое оно входит при отсутствии синхроимпульсов: микроконтроллер спит, GPS модуль спит, датчики не опрашиваются.
9) sleeps 1 - интервал короткого сна АУ 202, (параметры режима Periodic Standby) значения из таблицы 2, где
короткий сон - состояние АУ 202, в которое оно входит между очередными сеансами передачи информации (при наличии синхроимпульсов), микроконтроллер спит, GPS модуль спит.
Каждое АУ 202 принимает синхросигнал с БСС 203 и по номеру кадра, периоду опроса и своему номеру в кадре вычисляет время, на которое ему необходимо «заснуть», чтобы, проснувшись, попасть при передаче информации в свой тайм-слот в своем кадре. Структура кадра показана на Фиг. 6.
Если АУ 202 должно передавать свою информацию не на первом канале, то перед передачей оно переключается на свой рабочий канал и там передает свои данные. Такое решение возможно благодаря малому времени переключения частоты радиомодуля примерно за 50 мкс. Структура информации, передаваемая с АУ 202 следующая:
0) addr1 - номер устройства, старший байт - uint8_t.
1) addr2 - номер устройства, младший байт - uint8_t.
2) Ubat - степень заряженности аккумуляторной батареи в процентах - uint8_t.
3) Побитно:
Биты:СН-3 Тип сообщения:/0/ Биты: 4÷5
Версия протокола: III Биты: 6÷7 Тревога:/0/
4) latl - данные широты, старший байт - uint8_t.
5) lat2 - данные широты, средний байт - uint8_t.
6) lat3 - данные широты, младший байт - uint8_t.
7) lon1 - данные долготы, старший байт - uint8_t.
8) lon2 - данные долготы, средний байт - uint8_t.
9) lon3 - данные долготы, младший байт - uint8_t.
10) press1 - атмосферное давление, старший байт - uint8_t.
11) press2 - атмосферное давление, младший байт - uint8_t.
12) HDOP - коэффициент горизонтального отклонения координат HDOP - uint8_t.
13) побитно:
- 2-а младших бита - fixQuality минус 1: (0-2);
- 6 старших битов - sptl (число принимаемых спутников, 0-31);
14) Azim - курсовой угол - uint8_t.
15) Speed - скорость движения - uint8_t.
16) побитно:
- Биты: 0-11 - Уровень двигательной активности: (0-3), 0 - покой, 1 - минимальная активность, 2 - средняя активность, 3 - существенная активность;
- Бит: 2 - Признак нахождения в помещении: 1 - да, 0 - нет.
- Биты: 3-5 - Максимальное изменение высоты между сеансами связи из таблицы: 0, 3, 6, 9, 12, 15, >18. (0b0÷0b110)
- Биты: 6-7 - Срабатывание датчика удара максимальное ускорение: 0g, 3g, >8 g.
17) hh - число часов времени UTC - uint8_t.
18) mm - число минут времени UTC - uint8_t.
19) ss - число секунд времени UTC - uint8_t.
20) Резерв; /0/
21) TempAU - Значение температуры внутри АУ 202 - int8_t. Режим мульти БСС.
С целью организации работы АУ 202 в условиях наличия нескольких базовых станций, синхронизации на больших протяженных территориях, в синхронизацию АУ 202 внесены изменения, позволяющие работать при приеме хотя бы одного из четырех предшествующих требуемому кадру синхроимпульсу (СС). Принцип формирования синхроимпульсов на БСС 203 в режиме мульти БСС будет рассмотрен в разделе БС 201.
АУ 202 после первого включения переходит к приему синхроимпульсов и производит ожидание в течение 5 сек. При приеме за это время хотя бы одного синхроимпульса АУ 202 вычисляет время, на которое можно "уснуть", чтобы включиться за 5 сек до своего кадра. Когда АУ 202 "проснется" и произведет прием одного из 4-х синхроимпульсов, производится расчет задержки и последующая передача данных.
Прием синхросигналов и передача информации показана на временной диаграмме для примера с АУ 202 нулевого кадра. Нулевой кадр будет называться опорным. Относительно него АУ 202 синхронизируется и дополнительно вводится задержка 3 сек. для совместимости с предыдущими протоколами. В режиме мульти БСС синхронизация производится по СС с номерами от -2 до +1 относительно опорного кадра. Как только радиомодуль примет СС, прием выключается и рассчитывается задержка: Т4 или ТЗ или Т2 или Т1 в зависимости от того какой синхроимпульс был успешно принят. После задержки производится передача данных с АУ 202.
Прием и исполнение команд
Третий протокол обмена между БС 201 и АУ 202 предусматривает подачу и исполнение команд как с АУ 202 так и с сервера через БС 201. Основным способом доставки команд до АУ 202 (устройств) является использование байтов синхросигнала (СС):
1) - comm (команда);
2) - argum (аргумент команды).
При подаче команд, предназначенных для исполнения всеми АУ 202 значение команды в 5-м байте синхроимпульса должно передаваться в течении как минимум периода опроса всех АУ 202. Т.к. введен режим мульти БСС 203, то для передачи команды конкретному АУ 202 необходимо дублировать команду в четырех СС подряд. Какой при этом синхросигнал будет принят неизвестно. Поэтому аргумент команды в каждом из четырех СС должен указывать на конкретное АУ 202 со сдвигом, в зависимости от расположения СС относительно опорного кадра.
В ответ на различные команды АУ 202 может посылать различного вида информацию. Для расширения этой возможности в сообщении от устройств, введен параметр «Тип сообщения» передаваемые в байте 2 биты 0-3 стандартного сообщения с АУ 202. Возможные типы сообщений:
0 - нормальное сообщение;
1 - запрос регистрации;
2 - нормальное сообщение с устройства контроля температуры;
3 - получена команда тревоги (ответ) /сообщение нормальное/;
4 - получена команда смены прошивки (ответ) / сообщение нормальное/;
5 - передача версии прошивки;
6 - подтверждение регистрации;
7 - резерв для совместимости (тревога в старом протоколе);
8 - сообщение с БСМ;
9 - тревожное сообщение;
10 - подтверждение сброса всеобщей тревоги на АУ 202;
11 - подтверждение снятия регистрации с устройства.