CC BY
143
САПР
Разработка проектов организации дорожного движения: настоящее и будущее
Кривопалов А.Д., ведущий разработчик ГИС автомобильных дорог ООО «ИндорСофт» (г. Томск) Петренко Д.А., технический директор ООО «ИндорСофт» (г. Томск)
Скворцов А.В., д.т.н., профессор, генеральный директор ООО «ИндорСофт» (г. Томск)
Рассматривается традиционный подход к разработке проектов организации дорожного движения и подход в рамках программных комплексов информационной модели дороги. Приводится обзор программного обеспечения, используемого для решения этой задачи, описываются недостатки существующих систем и предлагаются способы их устранения.
Использование автомобильной дороги невозможно без наличия на ней элементов инженерного обустройства: дорожных знаков, разметки, светофоров, различных направляющих устройств и т.д. Все технические средства организации дорожного движения служат целому ряду целей: они контролируют движение пешеходов, автомобилей и иных транспортных средств, обеспечивают их безопасность и позволяют повысить пропускную способность участков дороги, оптимально управляя транспортными потоками. Размещение элементов дорожного обустройства на каждой конкретной дороге или даже отдельно взятом участке дороги определяется проектом организации дорожного движения (ПОДД), иногда также называемом проектом дислокации (рис. 1). Разумеется, планирование организации дорожного движения является непростой и трудоёмкой задачей, которая актуальна не только при разработке проекта строительства дороги, но и на этапе её эксплуатации. В России применение технических средств организации дорожного движения регламентируется рядом нормативных документов, основным из которых является ГОСТ Р 52289-2004 [1], а процесс разработки ПОДД, его содержание и формат — «Порядком разработки и утверждения проектов организации дорожного движения на автомобильных дорогах» [2], утверждённым в 2006 году.
Изначально разработка проектов организации дорожного движения, как и разработка любых других дорожных проектов, проводилась в два этапа: сначала проводились полевые измерения, а затем инженерами создавались «бумажные» схемы и ведомости. Набор отчётных документов по сути и являлся проектом, который согласовывался с государственными организациями,
отвечающими за безопасность дорожного движения, и после утверждения сдавался заказчику. Первым шагом к автоматизации этого процесса стало использование векторных графических редакторов и универсальных программ для создания чертежей. Некоторые проектные организации пользовались и пользуются до сих пор различными САПР и реже ГИС, позволяющими получать в том или ином виде чертёж дороги, который затем доводится до требуемой формы вручную. Хотя такой подход и облегчил работу специалистов, заметно сократив количество рутинных действий, связанных с созданием и редактированием схемы дороги, стала очевидной необходимость создания специализированного программного обеспечения, направленного на комплексную разработку ПОДД, оперирующего цифровой моделью дороги и способного автоматизировать решение специфических задач, таких как проектирование размещения технических средств организации дорожного движения, генерация ведомостей, подсчёт объёмов работ и т.д.
Индустрия программного обеспечения ответила на требования рынка, создав ряд коммерческих систем, предназначенных для разработки ПОДД: CREDO Дислокация («Кредо-Диалог», Беларусь) (рис. 2а), модуль «Проектирование схем дислокации ТС ОДД», входящий в состав комплекса Титул-2005 («Титул-2005», г. Саратов) (рис. 2б), RapidPlan (Invarion, Австралия) (рис. 2в), CONE (CONE Software, Великобритания) (рис. 2г), ConeZone (SignCAD Systems, США). Однако иностранные программы зачастую не содержат инструментов, необходимых отечественному специалисту, и проект в них выполняется в произвольном формате. Так, RapidPlan, несмотря на наличие удобных инструментов для рисования
86 | САПР и ГИС автомобильных дорог | №2(3), 2014
САПР
Рис. 1. Титульный лист (а) и пример схемы (б) проекта организации дорожного движения
дорог в плане, не позволяет создавать такие необходимые элементы дороги, как полосы уширения. Отсутствуют в нём и другие важные возможности: создание площадной разметки, светофоров и ограждений, поддержка таблиц линейного графика и информации о продольном профиле доро-
ги, возможность указывать состояние объекта (является ли он фактически размещённым или проектируемым). К тому же в RapidPlan невозможны привязка к географическим координатам и обеспечение точности, необходимой для разработки ПОДД в рамках проекта строительства. CONE, помимо
обладания некоторыми из недостатков RapidPlan, неудобен, например, тем, что выполнен в виде модуля для AutoCAD/BricsCAD и автономно работать не может.
Впрочем, самым важным ограничением при использовании перечисленных программ является отсутствие
Рис. 2. Рабочие окна программ: а) CREDO Дислокация, б) Титул-2005 «Дислокация ТС ОДД», в) Invarion RapidPlan, г) ConeSoftware CONE
САПР и ГИС автомобильных дорог | №2(3), 2014 | 87
САПР
Согласование
Сдача
отчёта
Рис. 3. Традиционный процесс разработки ПОДД
международных стандартов на документацию по организации дорожного движения, равно как и существенные различия в правилах и требованиях разных государств к обеспечению безопасности на дорогах. Это приводит к тому, что программные продукты, разрабатываемые на Западе, либо не подходят российскому проектировщику, либо могут использоваться только для решения ограниченного круга задач.
С другой стороны, программы, разрабатываемые в нашей стране, учитывают актуальные для России стандарты и нормативные документы, и при их использовании подобных проблем не возникает. Но и отечественным системам есть куда стремиться. В свете тенденций, наметившихся в дорожном хозяйстве в последние годы, существующие методики разработки ПОДД быстро теряют актуальность. В частности, проект транспортной стратегии Российской Федерации на период до 2030 года [3] предусматривает внедрение инновационных технологий строительства, реконструкции и содержания транспортной инфраструктуры, и, как следствие, переход на контракты жизненного
цикла в отношении автомобильных дорог. Вследствие этого устаревшим оказывается сам подход к созданию проектов ОДД, состоящий из следующих этапов (рис. 3):
1. Проведение полевых изысканий на проектируемом участке дороги и фиксация существующих технических средств ТС ОДД.
2. Сбор информации по интенсивности движения и аварийности на проектируемом участке.
3. Ввод исходных данных в программный продукт.
4. Разработка схемы ОДД средствами программного продукта.
5. Согласование проекта с заказчиком и органами ГИБДД.
6. Формирование отчётной документации, которая сдаётся заказчику, и является в его глазах проектом.
При этом протяжённые участки дороги выпрямляют и масштабируют, сжимая в продольной оси (рис. 4). Также такие участки снабжаются таблицами линейного графика, содержащими информацию о продольных уклонах, радиусах кривых в плане и прочих характеристиках дороги. Для развязок и дорожных узлов, имеющих сложную конфигурацию, схемы
оформляются на отдельных листах без искажений.
Недостатки такого подхода очевидны: полевые изыскания и сбор данных, равно как и последующий ввод полученной информации в программу, являются трудоёмким процессом, занимающим львиную долю времени работы над проектом. При создании схемы дороги к ней применяется большое число различных искажений: спрямление изогнутых участков дороги, сжатие в продольном масштабе (согласно «Рекомендациям» проекты должны выполняться в продольном масштабе 1:3000 и произвольном поперечном масштабе), упрощение геометрии как самой дороги, так и объектов обустройства. Полученная схема, хоть и более удобна для печати отчёта по плану ОДД, лишена точности, необходимой для использования полученного проекта ОДД совместно с проектом строительства или для выгрузки запроектированных элементов обустройства в ГИС, являющейся основой системы управления жизненным циклом автомобильной дороги. Очевидно, что при разработке ПОДД в рамках такой системы спрямлённая схема дороги должна использоваться только как вспомогательный инструмент при проектировании, а также в качестве выходного формата отчёта, но ни в коем случае не может являться исходной моделью дороги.
Применение технологии информационного моделирования при эксплуатации автомобильной дороги [4-7] позволяет отбросить или значительно упростить шаги, связанные со сбором и вводом данных. Программный комплекс, оперирующий такой моделью дороги, уже должен содержать всю информацию, необходимую для начала работы над проектом организации дорожного движения. Таким образом, отпадает надобность в полевых изысканиях, равно как и во вводе исходных данных, поскольку для построения проекта используется информация, полученная на основании выполненной ранее исполнительной съёмки и
Рис 4. Схема проекта ОДД для протяжённого участка дороги в программе разработки проекта дислокации ООО «СибДор» (г. Томск)
88 | САПР и ГИС автомобильных дорог | №2(3), 2014
САПР
хранящаяся в системе. Кроме того, информационная модель дороги должна содержать в себе накопленные сведения по интенсивности движения и аварийности, а программный комплекс, использующий эту модель, — инструменты обработки и анализа такой информации, например расчёт участков концентрации ДТП. К помощи подобных средств информационной системы и может прибегнуть инженер-дорожник, вместо того чтобы вручную обобщать и анализировать огромное количество отчётов о ДТП, пытаясь выявить аварийно-опасные участки. Конечно, первые два этапа актуальны только для дороги, уже находящейся на стадии эксплуатации, а проекты ОДД не менее часто выполняются бок о бок с проектами строительства новых дорог или участков реконструкции существующих. Впрочем, ситуацию это кардинально не меняет, поскольку данный этап также должен охватываться информационной моделью дороги. Разница заключается лишь в том, что создаваемая схема ОДД опирается на проект дороги, а не на суще-
ствующее положение дел, в системе отсутствуют данные об аварийности, а размещение ТС ОДД осуществляется «с нуля», без учёта уже размещённых элементов обустройства.
За подготовительными шагами следует этап непосредственной расстановки средств ОДД на схеме, на которую приходится основной объём интеллектуальной работы над проектом. Несмотря на то, что существующие программы предлагают некоторые базовые средства автоматической расстановки элементов инженерного обустройства, решать эту задачу без вовлечения специалиста они могут только в самых тривиальных случаях, как правило, только для двухполосных дорог без разделительной полосы. Понятно, что такая сложная задача требует наличия адекватной детализированной модели дороги. К сожалению, простые продукты, не входящие в соответствующий программный комплекс, ориентированы только на получение проектной документации и используют упрощённые модели данных.
Отдельным пунктом при проектировании плана организации дорожного движения являются развязки и иные узлы дорожной сети, имеющие сложную конфигурацию. Эти узлы, в отличие от протяжённых участков дороги, не искажаются, а просто изображаются на отдельных листах в подходящем масштабе, индивидуальном для каждого узла (рис. 5).
На данный момент многие программы для создания ПОДД либо вообще не поддерживают создание и редактирование узлов, либо делают это чисто формально, по сути предлагая инженеру вручную создавать чертёж интересующей его развязки или участка. Очевидно, что интеграция модуля ПОДД с системой, уже содержащей в себе модель дороги на плане (ГИС, САПР), существенно упростила бы проектирование, сразу предоставляя специалисту не только изображение узла на плане местности, картографические и любые иные подложки, но и цифровую модель дороги с отдельными элементами развязок, линиями осей, кромок, бровок и т.д. Все эти дан-
Рис. 5. Схема проекта ОДД для развязки типа «кольцо»
САПР и ГИС автомобильных дорог | №2(3), 2014 | 89
САПР
Рис. 6. Модуль разработки проектов ОДД в составе IndorCAD/Road
ные могут быть использованы как для упрощения процесса ручного проектирования, так и для автоматического проектирования технических средств ОДД на развязках и узлах. Кроме того, возможность видеть проектируемую дорогу на плане была бы весьма удобна и полезна даже при работе с линейно-протяжёнными участками, поскольку человеку иногда может быть сложно оценить параметры дороги, ориентируясь только на спрямлённую схему и табличные сведения.
Такую возможность проектировщику предоставит система проектирования автомобильных дорог IndorCAD/Road следующего поколения, объединяющая в себе возможности разработки не только проектов строительства, реконструкции или ремонтов автомобильных дорог и городских улиц, но и проектов организации дорожного движения (рис. 6). Высокая точность модели, используемой в IndorCAD, переносится и на проект дислокации, выполняемый на той же дороге, что позволяет в итоге получить схему расстановки технических средств ОДД, не содержащую искажений, в отличие от аналогичных схем, создаваемых традиционными инструментами разработки ПОДД.
Точность особенно важна для проектов организации дорожного движения в местах проведения дорожных работ. Согласно ВСН 37-84 [8] любой проект ремонта, строительства или реконструкции должен сопровождаться схемой организации движения на время проведения работ. Учитывая, что зачастую в рамках таких проектов на ремонтируемом или реконструируемом участке не только устанавливаются временные ТС ОДД, но и изменяются геометрические параметры дороги (например, когда на время работ создаются новые элементы, такие как объезды или площадки), документация, необходимая для согласования работ, сама превращается в миниатюрный
проект строительства, предъявляющий в соответствии с нормативной базой жёсткие требования к точности проектируемых элементов, и, как следствие, чертежей.
IndorCAD в рамках одного проекта позволяет создавать не только основные проектируемые трассы, но и вспомогательные, используемые, например, для объезда участка проведения работ. На время проведения работ можно также создавать проект временной ОДД, который удобно выполнять непосредственно в системе проектирования IndorCAD.
Помимо этого, инструменты, встроенные в IndorCAD, значительно упростят процесс расстановки элементов инженерного обустройства, автоматически размещая знаки, разметку и ограждения в соответствии со множеством правил, встроенных в систему.
Возвращаясь к вопросу несовершенства специализированных систем для разработки ПОДД, стоит заметить, что иным распространённым недостатком является отсутствие модели обустройства, и, как следствие, отсутствие контроля целостности проекта. Выражается это в том, что после расстановки на участке дороги элементов инженерного обустройства эти элементы не поддерживают связи между собой, равно как и с дорогой. Например, если проектировщик передвинет пешеходный переход, то соответствующие знаки 5.19 останутся стоять на прежнем месте, и их придётся или переносить отдельно, или удалять старые и создавать другие. Порой возникают проблемы и с линейно-протяжёнными объектами, такими как ограждения. Элемент обустройства, который имеет большую протяжённость и проходит через несколько листов проекта или даже по узлам дороги, в большинстве программ разбивается на несколько отдельных объектов по границам этих листов или узлов. При этом каж-
90 | САПР и ГИС автомобильных дорог | №2(3), 2014
САПР
Разработка ПОДД с поддержкой автоматического и вариантного проектирования
Согласование
Хранение результатов в информационной модели дороги
Рис. 7. Процесс разработки ПОДД в концепции информационной модели ЖЦ дороги
дый из получившихся объектов пользователю придётся редактировать и удалять индивидуально либо использовать вспомогательные средства, чтобы объединить объекты в группу или участок. Если этого не делать, то в ведомости и отчёты эти объекты тоже попадут как отдельные записи, что, конечно же, неверно. Также в большинстве случаев модули ПОДД не проверяют всевозможные ограничения, налагаемые на средства технического обустройства государственными стандартами. Например, они могут игнорировать то, что пользователь разместил более четырёх знаков на одной стойке или не соблюдает дистанцию между стойками знаков. Зачастую не проверяются даже элементарные ограничения, и пользователь может, например, по ошибке разместить стойку знака прямо на проезжей части, а затем, не заметив или забыв про это, сохранить изменения, которые впоследствии попадут в отчёт.
Как было замечено выше, при разработке ПОДД на существующей дороге нужно учитывать имеющиеся средства организации движения, и в таком случае проект должен показывать, какие изменения следует внести, чтобы привести инженерное обустройство дороги из текущего состояния в желаемое. Иными словами, нет смысла выполнять лишнюю работу и разрабатывать весь проект с чистого листа, если требуется только добавить пару знаков и перенести пешеходный переход. Эти изменения выделяются цветом или условными символами на схеме дороги и попадают в ведомости, позволяя сократить объём полевых работ по размещению запроектированных технических средств ОДД. Для этого в системах проектирования ОДД предусмотрена возможность указывать состояние элементов обустройства — являются ли они существующими или проектируемыми. Однако такой подход приводит к тому, что при необходимости показать, например, перенос дорожного знака, пользователь должен создать два дорожных знака, а затем указать, что один из них является проектируемым. Из-за
этого может возникнуть путаница, когда имеется множество объектов, не связанных между собой. Впрочем, даже при наличии возможности связать два элемента (существующий и проектируемый) не исключается вероятность человеческой ошибки. Этих проблем можно избежать, если использовать модель данных, в которой каждый элемент обустройства просто имеет разные состояния — фактическое и проектное. Такая модель позволяет вести контроль целостности для объектов обустройства и даже прибегать к вариантному проектированию, когда каждый объект может иметь более одного проектного состояния. Вариантное проектирование, в частности, позволило бы ощутимо облегчить предпоследний этап, на котором происходит согласование проекта с заказчиком и государственными органами безопасности дорожного движения.
Наконец, на заключительном этапе исполнитель проекта должен сдать заказчику результаты разработки. Традиционно ими является просто набор бумажной документации: схемы участков дороги и ведомости обустройства. Однако при переходе на программные комплексы, работающие с дорогой в течение всего её жизненного цикла, этот формат отчётности стремительно ухсдит в прошлое. Проект организации дорожного движения должен являться частью информационной модели дороги и храниться в её составе (рис. 7).
При этом сам проект должен быть привязан к той точке во времени, когда он разрабатывался. Если впоследствии, через 5 или 10 лет, дорога была реконструирована, то старый проект не должен измениться, и пользователь, желающий изучить его, должен увидеть дорогу и этот проект так, как он выглядел на момент создания. В то же время, если речь идёт о разработке ПОДД для проектируемой дороги, изменения в проекте строительства должны приводить к изменениям в проекте ОДД (рис. 8). Например, если дорога была расширена, а кромка сдвинута за счёт до-
Новый проект ОДД
Рис. 8. Модуль ПОДД в контексте программного комплекса жизненного цикла дороги
САПР и ГИС автомобильных дорог | №2(3), 2014 | 91
САПР
Рис. 9. Модуль ПОДД в ГИС автомобильных дорог IndorRoad
бавления укреплённой обочины, то соответствующим образом должны сдвинуться знаки, ограждения и иные элементы дорожного обустройства, размещённые на этом участке дороги. Достигнуть этого невозможно без глубокой интеграции модуля разработки проектов организации дорожного движения с программным комплексом, включающим в себя ГИС и САПР автомобильных дорог, так, как это делается в грядущих версиях систем IndorRoad и IndorCAD.
В частности, в состав следующей версии геоинформационной системы IndorRoad, предназначенной для содержания и эксплуатации автомобильных дорог и успешно используемой в Росавтодоре и ГК «Автодор», войдёт модуль разработки проектов организации дорожного движения (рис. 9). Данный модуль, в отличие от своего собрата в IndorCAD, предназначен для создания ПОДД на уже существующей дороге и опирается на имеющиеся в системе данные и измерения, что позволяет организациям, содержащим дорогу, экономить время и средства на повторном сборе данных. Создание и разбивка проекта максимально упрощена: все развязки автоматически выделяются в узлы и размещаются на отдельных листах, а гибкая настройка обеспечивает возможность задавать индивидуальные масштабы для различных участков проекта. Таким образом, на пригородном участке,
где элементы обустройства и съезды расположены часто, проектировщик может выбрать крупный масштаб, чтобы получить более наглядную схему. Кроме того, будучи геоинформационной системой, IndorRoad даёт возможность управлять самими проектами ОДД и работами по их реализации. Пользователь может находить на карте проектируемые участки, изучать их в совокупности с различными картографическими подложками, просматривать информацию по исполнителям проекта и работ. Обладая набором рассмотренных в статье инструментов, нужным для разработки проектов дислокации, этот модуль позволяет вести разработку проекта, не изменяя актуального состояния дороги. Такой подход даёт пользователю возможность переключаться между фактическим и проектным состоянием или различными его вариантами, сравнивать их и рассматривать отличия и изменения. По завершении работы над проектом он, после проведения соответствующих работ, может быть превращён в новое актуальное состояние дороги, в соответствии со стадиями жизненного цикла дороги. При этом все проектные объекты станут существующими, проект со всей сопутствующей информацией ляжет в архив, а на обновлённый участок будут добавлены соответствующие гарантии [9].
Конечно, стоит заметить, что не всегда у организации, занимающейся
разработкой проекта ОДД, может быть доступ к такому программному комплексу, даже если заказчик проекта работает именно с его базой. В таком случае представляется полезной возможность работать с системой ПОДД как с отдельным приложением, поддерживающим все базовые функции, необходимые для разработки ПОДД, и позволяющим создать проект «по старинке», с нуля, но в то же время имеющим возможность обмена данными с вышеописанным комплексом программ.
Подводя итоги, можно сказать, что программным продуктам по разработке ПОДД ещё предстоит пройти длинный путь, но новая линейка продуктов компании «ИндорСофт» призвана дать проектировщику возможность создавать проекты дислокации в соответствии с современными требованиями к подобным системам. S
Литература:
1. ГОСТ Р 52289-2004 Правила применения дорожных знаков, разметки, светофоров, дорожных ограждений и направляющих устройств. 111 с.
2. Порядок разработки и утверждения проектов организации дорожного движения на автомобильных дорогах. М., 2006. 21 с.
3. Транспортная стратегия Российской Федерации на период до 2030 года. Проект. М.: Минтранс, 2013. 326 с.
4. Скворцов А.В. BIM для дорожной отрасли: что-то новое или мы этим уже занимаемся? // САПР и ГИС автомобильных дорог. 2014. №1(2). С. 8-11.
5. Скворцов А.В. BIM автомобильных дорог: оценка зрелости технологии // САПР и ГИС автомобильных дорог. 2014. №2(3). С. 12-21.
6. Скворцов А.В. Нормативно-техническое обеспечение BIM автомобильных дорог // САПР и ГИС автомобильных дорог. 2014. №2(3). С. 22-32.
7. Бойков В.Н. IT-технологии в поддержке жизненного цикла дорог // САПР и ГИС автомобильных до-рог. 2014. №1(2). С. 1-7.
8. ВСН 37-84. Инструкция по организации движения и ограждению мест производства дорожных работ / Минавтодор РСФСР.
М.: Транспорт, 1985. 40 с.
9. Скачкова А.С, Субботин С.А., Кривых И.В. Учёт гарантийных обязательств на выполненные работы в ГИС IndorRoad // САПР и ГИС автомобильных дорог. 2014. №2(3). С. 115-119.
92 | САПР и ГИС автомобильных дорог | №2(3), 2014
