IT-продукт, которым вы пользуетесь на каждой АЗС
Когда вы заезжаете на заправку, выбираете колонку и вставляете пистолет в бак — вы взаимодействуете с программным обеспечением. Причём с несколькими его слоями одновременно.
Кассовый терминал, экран над головой у оператора, сама топливораздаточная колонка, система учёта остатков, процессинг платежей — всё это разные программные компоненты, которые должны работать согласованно в реальном времени. Один сбой в цепочке — и колонка зависла, топливо не отпускается, касса не бьёт чек.
Большинство людей не думают об этом. И правильно делают: хорошее ПО незаметно. Но за каждой такой «невидимостью» стоит команда разработчиков, которая это спроектировала, написала и поддерживает.
В нашем случае — команда из Кемерово.
Как устроена АЗС с точки зрения программиста
Прежде чем рассказывать, что конкретно мы делали, — немного контекста о том, как вообще устроен программный стек автозаправочной станции.
Уровень оборудования: ТРК
Топливораздаточная колонка (ТРК) — это не просто механика. Современные колонки — это embedded-системы с собственными протоколами связи. Они умеют:
отпускать строго заданное количество топлива (до десятых долей литра),
фиксировать каждую транзакцию в собственном журнале,
принимать команды от управляющей системы по протоколу (обычно это RS-485 или TCP/IP в зависимости от производителя и возраста колонки),
сообщать о своём состоянии: готова, занята, неисправна, нет топлива.
Интеграция с ТРК — это работа на стыке embedded и backend. Нужно знать протоколы конкретного производителя, уметь обрабатывать события в реальном времени и не допускать рассинхронизации между тем, что физически налилось в бак, и тем, что записала система.
Уровень кассы и терминала
Оператор АЗС работает с кассовым программным обеспечением. Это не просто «1С на кассе». Это специализированное ПО, которое:
получает данные с ТРК,
управляет отпуском (разрешает или запрещает колонке начать налив),
ведёт учёт топлива по каждому резервуару,
обрабатывает платежи (наличные, карты, топливные карточки корпоративных клиентов),
формирует сменные отчёты,
интегрируется с фискальными регистраторами.
Уровень экранного модуля
Тот самый экран на терминале, который показывает «Хлеб пшеничный — 45 руб.», когда вам пробивают покупку в магазине при заправке. Или отображает сумму к оплате. Это отдельный программный компонент — экранный модуль для покупателя (pole display), который синхронизирован с кассой и обновляется в реальном времени.
Уровень бэк-офиса и интеграций
Над всем этим стоит система управления сетью АЗС: мониторинг остатков топлива в разрезе всех станций, управление ценами, отчётность, интеграции с ERP-системами нефтяной компании.
Что конкретно делала наша команда
Интеграции с ТРК новых типов
Одна из самых технически насыщенных задач — это интеграция с новыми моделями колонок, которые производители периодически выпускают с обновлёнными протоколами или изменённой логикой работы.
Оборудование на реальной сети АЗС — это зоопарк. Колонки разных лет, разных производителей, разных поколений прошивок. Управляющая система должна «разговаривать» с каждой из них на её языке и при этом предоставлять наверх единый интерфейс.
Мы реализовывали именно эту часть: драйверы и адаптеры для ТРК новых типов. Каждый литр фиксируется, каждая транзакция атрибутируется к конкретной колонке и конкретному моменту времени. Никаких «пропавших» литров и возможности что-то списать мимо кассы.
Это не просто про честность — это про то, что система управления топливом в крупной сети работает с реальными деньгами. Погрешность в учёте в масштабах тысяч АЗС превращается в очень конкретные убытки.
Экранный модуль для кассовых терминалов
Покупательский дисплей (pole display) — это то, что видит клиент, стоя у кассы. Строчка с наименованием, цена, итог, сумма сдачи.
Написать «просто вывод на экран» звучит несложно. На практике это требует:
синхронизации с кассовым ПО в реальном времени без задержек,
корректной кодировки кириллицы под конкретное оборудование (в нулевые это был отдельный квест),
обработки edge-кейсов: что показывать в режиме ожидания, что при ошибке, как усекать длинные названия товаров.
Первый прототип безоператорной АЗС
Это, пожалуй, самый интересный проект из этого периода.
Концепция безоператорной АЗС — «заправился, оплатил, уехал» без участия человека — не нова, но в начале 2010-х это было по-настоящему передовой темой для российского рынка. Мы участвовали в разработке первого рабочего прототипа такой системы.
Это принципиально другой уровень архитектуры: нет оператора, который принимает решения и разруливает нештатные ситуации. Всё должна делать система. Идентификация клиента, авторизация платежа, управление отпуском топлива, обработка ошибок, журналирование, взаимодействие с банком или процессинговым центром — и всё это в реальном времени, без права на зависание.
Коммерчески эта история тогда не взлетела в широкую розницу — российский рынок не был к этому готов ни технически, ни регуляторно. Но прототип был рабочим. Концептуально мы сделали то, что сейчас называют unattended retail, за двадцать лет до того, как это стало трендом.
Что умеет SaaSoft: за пределами «сайтов и CRM»
Когда говорят «IT-компания из регионов», большинство людей представляют: сайты, приложения, может быть CRM. Это тоже про нас — мы делаем и это, и делаем хорошо.
Но наш профиль шире.
Заказная разработка на .NET — основная специализация. Это enterprise-системы, сложная бизнес-логика, высоконагруженные приложения. Не вёрстка и не конструкторы.
Интеграции с оборудованием — именно то, о чём эта статья. Мы умеем писать код, который разговаривает не с REST API, а с железом: по протоколам RS-485, Modbus, OPC-UA и другим промышленным стандартам.
Нестандартные архитектуры — когда типовое решение не подходит, мы проектируем своё. Прототип безоператорной АЗС — хороший пример: там не было готового шаблона, это был R&D в полном смысле слова.
QA и тестирование — отдельная компетенция. Сложные системы требуют серьёзного тестирования, и у нас есть команда, которая этим занимается профессионально.
Аутстафф и аутсорс — для компаний, которым нужны конкретные специалисты в команду или полная передача разработки на внешнего подрядчика.
Если вам нужна команда, которая умеет в хардкорную интеграционную разработку — вы знаете, к кому обратиться.
