Некоторые замечания о проектировании программ АРМ оператора АЗС

Большинство из представленных на рынке программ АРМ отличаются следующими качествами. Это приложения ОС Windows, активно использующие вызовы системы управления реляционными базами данных (СУБД) или прямо являющиеся их надстройкой.

О недостатках и достоинствах Windows можно дискутировать, но это бесспорно не операционная система реального времени. Программы СУБД также изначально не предназначены для управления реальными объектами. Поэтому возникает множество проблем при попытках создания крупных многофункциональных АРМ АЗС, способных управлять десятками и сотнями разновидностей оборудования и попутно ведущих многочисленные базы данных. Не стоит даже упоминать, что эти монстры обычно пожирают огромные вычислительные ресурсы и крайне неповоротливы.

Обычно такие программы представляют собой скорее бесконечный процесс, нежели законченный продукт. За время тестирования и отладки одного типа оборудования, либо оно изменяется, либо появляется другое, которое также требует подключения к АРМ, тестирования, отладки, etc. Либо, в конце концов, изменяются компьютеры и ОС и все приходится переписывать с самого начала. Это произошло, например, со многими системами под DOS. Хотя ДОС гораздо лучше приспособлена для задач управления, нежели Windows, и мощности компьютеров класса 386-486 для управления АЗС тоже вполне достаточно, но давление рынка требует использования "современных" средств. Во многом такой подход определен скорее психологическими и историческими причинами, нежели логическими доводами и экономическими соображениями.

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

Этот подход имеет следующие преимущества:

1. Не требуется разработка и сопровождение одной громоздкой системы. Разработку программ, решающих отдельные задачи можно поручить независимым исполнителям. Многие производители, к примеру уровнемеров, для работы со своим оборудованием в комплекте предлагают свои отлаженные программы.

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

2. Настройка всего комплекса АРМ сводится к подбору программ, работающих конкретно с установленным на АЗС оборудованием: ТРК, уровнемерам, ридерами и т.п. При этом, например, система управления базой данных клиентов является независимой задачей и ее управляющая программа может быть на всех АЗС одинаковой, унифицированной для всей сети. При изменении структуры данных в базе - изменения коснутся только программы управления этой базой, которая может быть быстро заменена.

Например, если на какой-то АЗС организуется подсчет авто на мойке при помощи видеокамер, только на нее и устанавливается нужный программный модуль. Он может быть отлажен независимо и автономно. При этом на всех остальных АЗС не требуется переустановка всех программ.

3. Взаимодействие между отдельными программами производится при помощи оператора стандартными средствами используемой многозадачной операционной системы (Windows или UNIX). Поток информации между отдельными задачами, требующий ручной обработки оператором, минимален. Например, программе уровнемера абсолютно безразлична база клиентов и наоборот - потока информации между ними нет.

При этом средства управления задачами в любой операционной системе отлажены достаточно хорошо. Даже если из-за каких-либо ошибок в программах зависнет одна из задач, нарушение работоспособности АЗС в целом маловероятно.

4. Нагрузка на оператора при таком подходе не увеличивается, по сравнению с традиционным. Переключить задачи в многозадачной системе не сложнее и не проще, чем переключить окна в одном необозримом приложении АРМ, 90% функций которого на данной АЗС не используются.

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

При выборе операционной системы следует учитывать возможность обслуживания АРМ малоквалифицированным персоналом. Найти пользователя Windows пока что гораздо проще, чем администратора Linux или BSD. Но, весьма вероятно, ситуация со временем изменится. Использование программ для DOS на современных компьютерах, к сожалению, вызывает массу проблем. Ориентироваться на DOS в новых разработках следует, если решается только конкретная задача управления, и нет необходимости поддержки нового оборудования и сетей.

Конкретный пример взаимодействия с КУ ТРК на уровне последовательного порта под Windows приведен на отдельной странице. Пример может быть полезен программистам, ранее не работавшим через порты с реальным оборудованием.

Реально какие-либо заметные изменения ситуации с АРМ возникнут, вероятно, в том случае, если удасться создать договоренности о формате представления данных в АРМ, формализовать взаимодействие между модулями в программах и т.п. Но это пока не представляется реальным. Наиболее перспективный путь к созданию фактических стандартов в этой области - публикация разработчиками некоторой открытой документации по своим системам.

Некоторые шаги в этом направлении делаются. Лет десять назад раздобыть протокол обмена данными с ККМ было невозможно, никакие доводы, что совместимость оборудования выгодна всем сторонам, на производителей не действовали - это был их большой секрет. Сейчас же протоколы, например, фискальных регистраторов (ФР) или тех же уровнемеров вполне доступны.

Немаловажным шагом было и принятие "Универсального протокола". При всех его недостатках, он позволил быстро создать необходимое оборудование и частично решить задачи автоматизации на АЗС.