РАЗРАБОТКА СИМУЛЯТОРА СБОРА ДАННЫХ С ДАТЧИКОВ ЛОКОМОТИВА В УСЛОВИЯХ НЕСТАБИЛЬНОЙ ПЕРЕДАЧИ ИНФОРМАЦИИ Текст научной статьи по специальности «Компьютерные и информационные науки»

2. Клещев А.С., Москаленко Ф.М., Черняховская М.Ю. Онтология и модель онтологии предметной области «Медицинская диагностика». - Владивосток: Изд-во ИАПУ ДВО РАН, 2005.

3. Кобринский Б.А. Триединство факторов уверенности в задачах медицинской диагностики // Искусственный интеллект и принятие решений. - 2018. - № 2. - С. 62-72.

4. Кобринский Б.А., Благосклонов Н.А., Демикова Н.С., Грибова В.В., Шал-феева Е.А., Петряева М.В. Возможности применения онтологического подхода к диагностике орфанных заболеваний // Семнадцатая Национальная конференция по искусственному интеллекту с международным участием. КИИ-2019. Сборник научных трудов. В 2 т. - Ульяновск: УлГТУ, 2019. - Т.2. - С. 227.

5. Намазова-Баранова Л.С., Вашакмадзе Н.Д., Бабайкина М.А., Басаргина Е.Н., Журкова Н.В., Геворкян А.К., Кузенкова Л.М., Подклетнова Т.В., Жер-дев К.В., Челпаченко О.Б., Дегтярёва Т.Д. Эффективность современных методов лечения пациентов с мукополисахаридозом I типа // Педиатрическая фармакология. - 2014. - Т. 11. - № 6. - С. 76-79.

6. Ivanovic M., Budimac Z. An overview of ontologies and data resources in medical domains // Expert Systems with Applications. - 2014. - Vol. 41. - No 11. - Pp. 5158-5166.

7. Leshcheva I., Begler A. A method of semi-automated ontology population from multiple semi-structured data sources // Journal of Information Science. - 2022. -Vol. 48. - № 2. - Pp. 223-236.

УДК 004.6

doi:10.18720/SPBPU/2/id23-85

Долматов Роман Александрович 1,

аспирант;

л

Сараджишвили Сергей Эрикович ,

доцент, канд. техн. наук, доцент

РАЗРАБОТКА СИМУЛЯТОРА СБОРА ДАННЫХ С ДАТЧИКОВ ЛОКОМОТИВА В УСЛОВИЯХ НЕСТАБИЛЬНОЙ ПЕРЕДАЧИ

ИНФОРМАЦИИ

1 2

' Россия, Санкт-Петербург,

Санкт-Петербургский политехнический университет

1 2 Петра Великого, d_roman.kst@mail.ru, ssaradg@yandex.ru

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

Ключевые слова: беспилотные транспортные средства, симулятор, нестабильная передача данных, devops.

Roman A. Dolmatov \

Graduate Student;

Sergei E. Saradgishvili 2,

Candidate of Technical Sciences, Docent

DEVELOPMENT OF A SIMULATOR FOR COLLECTING DATA FROM SENSORS OF A LOCOMOTIVE IN CONDITIONS OF UNSTABLE INFORMATION TRANSFER

1 2

' Peter the Great St. Petersburg Polytechnic University, 1 2

St. Petersburg, Russia, d_roman.kst@mail.ru, ssaradg@yandex.ru

Abstract. This paper discusses the issue of creating a simulator for unmanned railway transport, comparing a comparative simulator, the proposed method for compiling a simulator that is different from a significant one, considering the issue of unstable data transfer.

Keywords: unmanned vehicles, simulator, unstable data transfer, devops.

Введение

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

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

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

В нулевом уровне — водитель-человек несет ответственность за 100% того, что SAE называет «динамической задачей вождения», что означает работу по фактическому вождению транспортного средства на постоянной основе [2].

Уровень 1 — система, которая обеспечивает либо рулевое управление, либо управление ускорением и торможением на постоянной основе, но только при ограниченных, конкретных обстоятельствах. Это не считается «автоматизацией» в рамках SAE, потому что динамическая часть задачи вождения не автоматизирована: человек по-прежнему должен быть готов нажать на тормоз (и деактивировать систему), если впереди более медленное движение.

Уровень 2 — «частичная автоматизация». Это для систем помощи водителю, которые обеспечивают как рулевое управление, так и управление ускорением и торможением, но опять же, только при ограниченных обстоятельствах. Если водитель-человек должен регулярно вмешиваться, например, когда автомобиль съезжает с шоссе, то это, вероятно, система уровня 2. Важно отметить, что это не «беспилотное вождение», даже если вроде как кажется, что автомобиль ведет себя сам.

SAE определяет уровень 3 как «условную автоматизацию». Разница между уровнем 2 и уровнем 3 заключается в степени. На практике это зависит от ответа на вопрос: насколько внимательным должен быть человек, сидящий за рулем автомобиля? С системой уровня 2 водитель должен быть очень бдительным, готовым немедленно взять на себя задачу вождения, если система обнаружит что-то, с чем она не может справиться. Ожидается, что на уровне 3 система сможет управлять вождением, пока оно находится в пределах своей «области операционного проектирования», а это означает, что роль человека состоит в том, чтобы быть «запасным вариантом».

Уровень 4 — это «высокая автоматизация вождения»: система вообще не нуждается в поддержке человека, пока она работает в своей «области эксплуатационного проектирования». Эти системы обычно используют несколько лидаров для моментального «картографирования» окружения автомобиля. Затем лидарные изображения сравниваются с сохраненной 3D-картой.

Уровень 5 — безусловное (то есть безлимитное) автоматизированное вождение без ожидания вмешательства человека-водителя. Иными словами, система уровня 5 должна быть способна проехать везде, куда может доехать опытный водитель-человек, в любых условиях, с которыми может справиться опытный водитель-человек, полностью самостоятельно. случаях возникают проблемы, связанные с безопасностью жизни человека [3].

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

Таблица 1

Сравнение трех симуляторов

Параметр срав- Симуляторы

нения CARLA CA GAzebo

Системные требования Intel i7 gen 9th - 11th / Intel i9 gen 9th - 11th / AMD ryzen 7 / AMD Четырёхъядерный процессор с тактовой частотой 4ГГц, Двухъядерный процессор с тактовой частотой 4

ryzen 9 Nvidia GTX 1080 ГГц

+16 GB RAM memory 8GB Nvidia GTX 2080

NVIDIA RTX 2070 /

NVIDIA RTX 2080 /

NVIDIA RTX 3070,

NVIDIA RTX 3080

Ubuntu 18.04

Операционная Linux, Windows (64- Linux, Windows 10 Linux, Windows

система для исполнения битная ОС) (64-битная ОС) (на Windows работает стабильнее, чем на Linux) (64-битная)

Графический Unreal Engine Unity Unity 3D

движок

Возможность Присутствует Отсутствует Отсутствует

параллелизации

тестов

Количество раз- 14 4 6

личных видов

транспортных

средств

Возможность Присутствует Присутствует ча- Присутствует

моделирования собственных стично

сценариев

1. Разработанный симулятор

Движок для симулятора был выбран, исходя из начальных условий. Использовался движок Unity 3D, было решено использовать этот же движок. Для написания клиента был выбран язык программирования Python, так как он очень удобен и легок в применении для данной задачи. Для передачи данных от сервера клиенту был выбран протокол передачи данных protobuf [4]. В процессе создания симулятора осталось объединить наработки двух компаний, добавить необходимых актеров, управляющие воздействие, создать клиент-серверную архитектуру для приема данных и управления симуляцией.

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

Симулятор включает в себя SD-модели (пешеходы, животные, велосипедисты, деревья и др.) и сценарий поведения этих объектов. Есть возможность моделировать поведение людей и животных и тестировать реагирование алгоритмов на появление препятствий в разных зонах. Клиент же посылает серверу сигналы управляющего воздействия: включение/выключение фар, подача гудка, экстренное торможение. Физика разгона и торможения состава тоже вынесена в клиентскую часть, данные берутся из протоколов испытаний, а на сервере скорость задается константой. Вся схема представлена на рисунке 1.

Основные компоненты симулятора:

- Симулятор, расположенный на операционной системе Windows.

- Программное обеспечение, развернутое на OS Linux, обеспечивающее работу тренажера и подключение к симулятору.

На операционной системе Windows запускается сервер Flask, после чего запускается программное обеспечение на Linux [5]. Так как с сервером связан клиентский компонент, то запускается именно он. Клиент отправляет сообщение в сервер о начале работе. Сервер после получения сигнала запускает одновременно симулятор и тренажер. Следующий компонент, с которым связан симулятор — адаптер.

Работающий симулятор с включенной камерой отправляет кадры адаптеру, после чего идет преобразование в zcm-формат. Клиент отправляет в симулятор данные из тест-кейсов и принимает данные из симуля-тора и следит, прошел тест-кейс или нет.

Рис. 1. Схема работы симулятора

Когда все тест-кейсы пройдены, то клиент посылает сообщение на сервер, чтобы тот закончил работу симулятора [6]. Все будет выполняться до тех пор, пока все вариации тест-кейсов не закончатся.

2. Понятие нестабильной передачи данных

Для управления информационными пакетами, передаваемыми по сети, разработана технология Quality of Service — это набор технологий, которые запускают высокоприоритетные приложения и трафик при лимитированной пропускной способности. Это означает, что более важный трафик будет обработан быстрее, а задержки по сети будут минимальны. Необходимо разделить трафик с помощью инструментов классификации. Так организации смогут контролировать доступность ресурсов для приоритетных приложений [7].

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

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

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

- Задержка сериализации (Serialization Delay) — время, за которое узел разложит пакет в биты и поместит в линк к следующему узлу. Она определяется скоростью интерфейса. Так, например, передача пакета размером 1500 байтов через интерфейс 100Мб/с займёт 0,0001 с, а на 56 кб/с — 0,2 с.

- Задержка передачи сигнала в среде (Propagation Delay) — результат ограничения скорости распространения электромагнитных волн. Физика не позволяет добраться из Нью -Йорка до Томска по поверхности планеты быстрее чем за 30 мс (фактически порядка 70 мс).

- Задержки, вносимые QoS — это томление пакетов в очередях (Queuing Delay) и последствия шейпинга (Shaping Delay).

- Задержка обработки пакетов (Processing Delay) — время на принятие решения, что делать с пакетом: lookup, ACL, NAT, DPI — и доставку его от входного интерфейса до выходного [7].

Заключение

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

Список литературы

1. История беспилотных автомобилей: статья [Электронный ресурс]. - URL: https://bespilot.com/info/istoriya (дата обращения 10.10.2022).

2. Rosevear J. Self-Driving Cars: Understanding the 6 Autonomous Levels, 2018.

3. Banks J., Carson J., Nelson B., Nicol D. Discrete-Event System Simulation. -Prentice Hall, 2001. - P. 3. - ISBN 978-0-13-088702-3.

4. Dosovitskiy A., Ros G., Codevilla F., López A., Koltun V. CARLA: An open urban driving simulator // Conference on Robot Learning (CoRL), 2017.

5. Hopsfs: Scaling hierarchical file system metadata using newsql databases / S. Niazi [et al] // 15th USENIX Conference on File and Storage Technologies (FAST 17), 2017. -Pp. 89-104.

6. Dosovitskiy A. CARLA Simulator. Documentation. [Electronic source]. - URL: https://carla.readthedocs.io/en/latest/start_introduction (date of access 10.10.2022).

7. Rong G., Shin B., Tabatabaee H., Lu Qiang, Lemke S., Mozeiko M., Boise E., Uhm G., Gerow M., Mehta Sh., Agafonov E., Kim T., Sterner E., Ushiroda K., Reyes M., Zelenkovsky D., Kim S. LGSVL simulator: a high fidelity simulator for autonomous driving. arXiv preprint, 2020.

8. Ermakov N. V., Molodyakov S. A. A caching model for a quick file access system // Journal of Physics: Conference Series. IOP Publishing, 2021. - Vol. 1864. No. 1.

УДК 528.06+681.2 doi:10.18720/SPBPU/2/id23 -86

Гаранин Владимир Александрович,

ассистент

МЕТРОЛОГИЧЕСКИЙ АНАЛИЗ ЗАДАЧИ СОГЛАСОВАНИЯ РЕЗУЛЬТАТОВ СОВМЕСТНЫХ ИЗМЕРЕНИЙ КОНЦЕНТРАЦИЙ

ВЕЩЕСТВ В МНОГОКАНАЛЬНЫХ СИСТЕМАХ ГАЗОВОГО

АНАЛИЗА

Россия, Санкт-Петербург, Санкт-Петербургский Политехнический университет Петра Великого, garanin_va@spbstu.ru

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