Бег с граблями
Проект начинался как обычно. Как говорится: “нужно еще вчера” и сроки ограничены. С первого взгляда проект простой – нужно организовать автоматизированную стоянку, для упорядочения регистрации автотранспорта. Система должна свести до минимума возможность каких бы то нибыло махинаций с очередью.
На первом этапе заказчику представлялась следующая схема работы:
- Автомобили заезжают на стоянку, пройдя предварительную регистрацию;
- При регистрации примерно рассчитывается время выезда;
- Водитель оплачивает сборы в расчетно кассовом центре (РКЦ);
- Очередность выезда автомобилей отображается на информационном табло;
- На выезде контролируется очередность и факт оплаты сборов;
- Должна быть учтена возможность временного выезда за пределы стоянки, без потери очереди;
- На рабочем месте старшего смены должна быть сформирована интерактивная графическая схема парковочной площадки, отражающая различными цветами и символами текущую обстановку. Что позволило бы оперативно реагировать на внештатные ситуации;
- Система должна работать круглосуточно, в режиме реального времени.
Для снижения стоимости сопутствующего программного обеспечения руководством было решено использовать операционную систему Linux и базу данных PostgreSql. Причем изначально планировалось использовать терминальные рабочие места (“пустышки” - компьютеры, не содержащие жестких дисков). Графическая X сессия должна была грузится по сети. Тестовые испытания показывали высокое быстродействие, удобство применения и администрирования данной схемы.
Имея большой опыт работы с Delphi и немного в Java выбор пал в пользу Java, как довольно перспективной среды разработки. Одним из критериев данного выбора стала необходимость реализации графического интерфейса для рабочего места администратора. На Delphi (Kylix) реализация данного модуля могла затянуться. А для Java был пример библиотеки org.tigris.gef. К тому же учитывая мощность современных компьютеров быстродействия последних должно было быть предостаточно.
Согласовав техническое задание и определив способы решения поставленной задачи мы приступили к работе. Для автоматизации идентификации автомобиля было решено использовать штриховое кодирование, как наиболее дешевый и достаточно надежный вариант. Было заказано соответствующее оборудование, но как это обычно бывает, состав оборудования не был согласован с разработчиками. Были заказаны просто сканеры и принтеры по приемлемой цене и характеристикам.
Предварительный этап разработки прошел с хорошими темпами. Оперативно была разработана схема структуры базы данных (которая в дальнейшем практически не изменялась). На базе анализа архитектуры построения графического интерфейса библиотеки org.tigris.gef была разработана собственная библиотека, которая позволяла творить с объектами на экране все что угодно. Соответственно были созданы рабочие макеты всех модулей системы, включая:
- Место первичной регистрации автомобилей;
- Дизайнер размещения парковочных площадок;
- Рабочее место старшего смены; li>Пункт временного въезда/выезда.
Первые грабли
Наконец то привезли заказанное оборудование. И конечно же не было драйверов под Linux. Но это пол беды (Решили пока отлаживать под Windows). Первыми граблями стало подключение радио-сканера. Мы и так его и сяк, а он ни в какую. Тестовая программа, наотрез отказывалась работать с базовой станцией, которая иногда пронзительно попискивала. Поставщик уверял, что дилеры уже длительное время торгуют данным оборудованием, и проблем не возникало. Вдоволь помучавшись с радио-сканером, мы решили, что он все таки неисправен и отправили его обратно поставщику. Через несколько недель нам его вернули. Оказалось, что они перепутали дата кабель. А сколько времени было убито.
Вторые грабли
Отсутствие стандартной java comm API библиотеки под Linux. В Internete была найдена свободная библиотека RxTx, но java код потерял свойство переносимости. Для Windows и Linux версий программы использовались разные библиотеки, что требовало перекомпиляции проекта. К тому же настройка прав доступа к портам в разных версия Linux различалась. Но и с этой проблемой мы справились. В последствии, когда потребовалось установить систему под Windows 98 было обнаружено, что и тут не все гладко. Порты под этой системой со стандартным comm Api, отказывались определяться. С горем пополам, блуждая по интернет форумам, удалось решить и эту проблему. От режима использования "пустышек" под Linux временно пришлось отказаться. В этом режиме локальные порты были не доступны, нужно писать специальные сервисы, а времени нет.
Третьи грабли
Отсутствие драйвера принтера под Linux не сказалось на нашем продукте. Но так, как использовались специализированные термо-принтеры Zebra, то для формирования шаблонов этикеток требовался Windows компьютер. Программа программирования шрифтов для данного принтера так же была написана для ОС Windows. К счастью эти операции разовые, и их можно произвести в нашем сервисном центре, или с laptop'а. Так что эти грабли били не так сильно, но все равно били.
Грабли номер четыре
Информационное табло еще было в стадии сборки – проект опять затянулся. Когда же его наконец привезли, выяснилось, что программа взаимодействия с микроконтроллером табло отказывается работать. Через несколько дней нам прислали тестовую программу, которая работала исправно. Тестировать табло приходилось у заказчика, на дорогу к которому ежедневно уходило около часа, и столько же времени на дорогу назад. Об условиях работы лучше не рассказывать – просто жуть (кругом стройка, побелка, компьютер на строительных лесах и постоянно пропадает электропитание). Несколько дней мучений, и попыток программирования табло не дали результатов. Кардинальным решением стало применение "шпионской" программы, которая отображала на мониторе весь процесс обмена данными с COM портом. Анализируя работу тестовой программы, мы выяснили, что присланный нам ранее протокол программирования микроконтроллера не соответствует истине. Нам прислали новую документацию, и после соответствующих корректировок табло наконец стало выводить требуемую информацию. Но задом наперед – во время сборки электроники неправильно запаяли панели индикаторов. Снова правим программу и наконец все заработало.
Наконец то разворачиваем всю систему у заказчика. Процесс обучения пользователей наверное многим знаком - народ просто шарахается от компьютеров. Обучение превращается в испытание нервной системы. Создается впечатление, что все проходит между ушей пользователей. За повторное обучение точно надо брать дополнительную плату.
Пятые грабли
Наступает день показа системы высокому начальству – оператор на пункте первичной регистрации трясется и говорит, что ничего не помнит. Начинаем тестовый прогон и тут система зависает, перезагрузка рабочих мест частично решает проблему. Но только после перезагрузки сервера удалось провести полную реанимацию. Последующие выяснения причин привели нас к проблемам с локальной сетью. Так же подвел postgresql jdbc драйвер. Вместо программно установленных 30 секунд таймаут длился пять минут. И соответственно это расценивалось как зависание. Основная же проблема была в подключении промежуточных хабов к общей электросети, а в режиме стройки броски тока и произвольное выключение питания явление очень частое. В результате чего подключили всю технику через источники бесперебойного питания. Ко всему прочему, смонтированное информационное табло не обеспечивало требуемый угол обзора и яркость. В результате чего было решено перерабатывать конструкцию, как следствие срок отодвинулся еще на несколько недель.
Проблемы с электропитанием заставили задуматься о возможности перехода на ручной режим. Пришлось писать дополнительный модуль автоматической распечатки оперативных данных при пропадании электропитания.
Снова привезли табло. Электроники исправили предыдущую ошибку пайки индикаторов знакомест, но теперь перепутали строки. Снова правим программу.
Последние грабли на нашем пути
Заказчик подумал, и решил: "Раз уж мы все автоматизируем, то надо управлять светофорами и шлагбаумами". Все сроки сорваны, заказываем контролер. А пока ведется его разработка местными умельцами собирается чудо агрегат, который по сигналам с LPT порта управляет устройствами. Все бы хорошо, но напрямую с портами под Linux и Windows XP не поработаешь, нужно писать драйвер. Временно разворачиваем рабочее место под Windows 98 (тут снова возникает проблема с java comm Api). Прямой доступ к портам осуществляем при помощи маленькой ассемблерной программы. Обратной связи со шлагбаумом нет, так что работаем наобум, в надежде на нормальное начальное состояние всего оборудования. Но при загрузке компьютера светофоры моргают, а шлагбаумы как “мертвые с косами” в фильме ужасов поднимаются и опускаются. Ясно, что практически это чудо использоваться похоже не будет, нужно ждать микроконтроллер. А время опять потеряно...
Выводы
Если вам придется создавать проекты, завязанные на оборудование, то готовьтесь к худшему. Сроки, как и в проектах требующих миграции данных, растут в геометрической прогрессии. Хотя на первый взгляд трезво оценить трудоемкость работ очень трудно, все кажется таким простым. Надеюсь, что у вас не будет таких проблем в проектах. По крайней мере несколько возможных подвохов, благодаря этой статье возможно удасться избежать.