Е.С. СВИНЦОВ, Файт АППЕЛЬТ, В.Л. ШВЕЦОВ, С.А. ДАВЫДОВ. О сравнении и оценке технологии автоматизации проектирования автомобильных и железных дорог: текстовая версия

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

На рис. 1 и рис. 2 выделены исходные данные и результаты, которые должны учитываться системой автоматизиро ванного проектирования (САПР). Мы не будем рассматривать САПР для плани рования транспортной сети, системы оценки экологии и расчета экономи ческих показателей, так как эти задачи имеют различный набор исходных дан ных и выполняются отдельными под разделениями. В САПР дорог возможна только их поверхностная оценка.

К САПР дорог предъявляются следую щие требования:

Несмотря на то, что в данной статье мы не будем учитывать другие разделы проектирования, обмен данными с ними должен обеспечиваться. В связи с этим од ним из основных требований является на личие интерфейсов. Например, возмож ность экспортировать данные из прог раммы для проектирования дорог в программу для организации дорожного движения позволит с минимальным до полнением специфическими параметра ми продолжать расчет уже в другом разде ле без повторного задания параметров до роги. Нужно также подчеркнуть, что программ, используемых при проектиро вании дорог, существует множество, и не все они являются промышленными стан дартами. Поэтому необходимо, чтобы пользователь сам мог настраивать обмен ные форматы данных. Другим решением этой задачи может быть создание единого обменного формата для всех САПР на базе некоего сетевого внеплатформенного продукта, поддерживающего многофор матный асинхронный обмен между лю быми известными протоколами (Sагент). Такой принцип изображен на рис. 3.

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