Научная статья на тему 'Методы обеспечения функциональной безопасности программно-технологических комплексов для коммерческой диспетчеризации грузовой работы'

Методы обеспечения функциональной безопасности программно-технологических комплексов для коммерческой диспетчеризации грузовой работы Текст научной статьи по специальности «Компьютерные и информационные науки»

CC BY
52
12
i Надоели баннеры? Вы всегда можете отключить рекламу.

Аннотация научной статьи по компьютерным и информационным наукам, автор научной работы — Петров М. В.

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

i Надоели баннеры? Вы всегда можете отключить рекламу.

Похожие темы научных работ по компьютерным и информационным наукам , автор научной работы — Петров М. В.

iНе можете найти то, что вам нужно? Попробуйте сервис подбора литературы.
i Надоели баннеры? Вы всегда можете отключить рекламу.

Текст научной работы на тему «Методы обеспечения функциональной безопасности программно-технологических комплексов для коммерческой диспетчеризации грузовой работы»

УДК 681.5)8:656.2

М. В. Петров

МЕТОДЫ ОБЕСПЕЧЕНИЯ ФУНКЦИОНАЛЬНОЙ БЕЗОПАСНОСТИ

ПРОГРАММНО-ТЕХНОЛОГИЧЕСКИХ КОМПЛЕКСОВ

ДЛЯ КОММЕРЧЕСКОЙ ДИСПЕТЧЕРИЗАЦИИ ГРУЗОВОЙ РАБОТЫ

В сложных автоматизированных системах, в которых результаты обработки информации и управляющие воздействия непосредственно определяют работоспособность и качество функционирования подсистем управления не исключены аварии и отказы на протяжении всего жизненного цикла развития системы. В статье приводится анализ дестабилизирующих факторов, приводящих к дефектам и снижению функциональной безопасности, с учетом выделения основного критерия оценки эффективности работы — удовлетворенности грузоотправителя. Предлагаемый подход включает исследования отклоненных заявок и жизненного цикла прохождения за-Явки грузоотправителя.

На Куйбышевской железной дороге внедрен в промышленную эксплуатацию АРМ коммерческого диспетчера (АРМ КД), который является многоуровневой информационно-управляющей системой, оптимизирующей функции оперативного планирования погрузки на всех уровнях железной дороги. АРМ КД предназначен для формирования плана погрузки станции, отделений, железной дороги в целом в разрезе родов подвижного состава и номенклатурных групп грузов и разработан на основе автоматизированной системы сменносуточного планирования грузовой работы дороги. Планирование погрузки осуществляется на основании заявленных объемов на плановые сутки погрузки в пределах остатка невыполненных объемов погрузки по станциям назначения в целом по заявке. АРМ КД основан на постоянном автоматизированном контроле наличия и исполнения каждой согласованной заявки, учёте каждой заявленной отправки при формировании суточного плана погрузки дороги. Программный комплекс АРМа КД обеспечивает рабочу в едином информационном пространстве всех участников процесса создания детализированного плана грузовой работы дороги. Данное программное обеспечение позволяет реализовать технологию планирования и управления грузовой работой дороги согласно современным требованиям руководства ОАО «РЖД»

- исходя из наличия реально заявленного груза обеспечить приоритет погрузки высокодоходных грузов и оптимизировать использование подвижного состава. Внедрение и развитие взаимодействующих в реальном режиме времени систем АРМ КД, АСУ ПР, АСУ ЛР и АСУ ССП позволило за счет использования передовых технологий улучшить качество взаимодействия, планирования, обслуживания клиентов, повысить объемы перевозок грузов без привлечения дополнительных погрузочных ресурсов, снизить эксплуатационные расходы дороги за счет сокращения порожнего пробега, простоя и оборота вагонов [ 1 ].

Решение правления ОАО РЖД от 22-23.12.04 (протокол № 44, п. 4.1.7) подтвердило целесообразность создания взаимоувязанной технологии непрерывной системы приёма заявок, планирования перевозок, технического нормирования эксплуатационной работы и удовлетворения заявок грузоотправителей погрузочными ресурсами [2, 3]. АРМ КД является логическим развитием и продолжением автоматизированной системы сменно-суточного планирования (АСУ ССП). Программно-технологический комплекс АСУ ССП также имеет в своем составе подсистему планирования грузовой работы дороги по критериям максимального начисления тарифа и суточных норм занятия родов подвижного состава.

Понятие жизненного цикла (ЖЦ) программно-технологического комплекса занимает одно из центральных мест в методологиях программных средств. Оно образует базу для естественной систематизации инструментов и методов, ресурсов и результатов на разных этапах разработки и использования программных систем. Понятие это не является специфическим для программирования. Оно возникло и развивалось сначала применительно к техническим системам. В частности, еще недавно наши экономисты выражали беспокойство по поводу того, что зарубежный потребитель сравнительно дешевым советским тракторам предпочитает канадские, цена которых в несколько раз выше. Оказалось, что полная стоимость последних с учетом затрат всего "жизненного цикла существования машин" (включая их техническое обслуживание и ремонт) получается в конечном счете в несколько раз меньше. Не случайно вопрос технологичности с точки зрения не только изготовления, но и последующей эксплуата-100

ции имеет в технике первостепенное значение. Понятие жизненного цикла программного обеспечения появилось, когда программистское сообщество осознало необходимость перехода от кустарных ремесленнических методов разработки программ к более технологичному мануфактурному, а в перспективе и к промышленному, их производству.

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

Тем не менее, программные средства наиболее близко, за исключением математических структур, подходят к понятию настоящего искусственного объекта. Программы не подвержены физическому износу, но в ходе их эксплуатации обнаруживаются дефекты, требующие исправления. Ошибки возникают также от изменения условий использования программных систем. Последнее является принципиальным свойством программного обеспечения, иначе оно теряет смысл. Поэтому правомерно говорить о старении программ, правда, не о физическом, а о "моральном". Необходимость внесения изменений в действующие программы (как из-за обнаруживаемых ошибок, так и по причине развития требований) приводит, по сути дела, к тому, что разработка программного обеспечения продолжается после передачи его пользователю и в течение всего времени жизни программ.

Первоначально понятие жизненного цикла рассматривалось как цикл разработки. Однако понимание того, что стоимость программного обеспечения включает издержки в течение всего времени жизни системы, а не только затраты на разработку или исполнение программ, привело к естественной трансформации исходного понятия цикла разработки. Жизненный цикл —- это проекция пользовательского понятия "время жизни" на понятие разработчика "технологический цикл (цикл разработки)". Комбинацией этих понятий объясняется происхождение самого термина "жизненный цикл программного обеспечения".

ЖЦ разработанной АСУ ССП состоит из следующих этапов:

1. Анализ существующих автоматизированных систем планирования грузовой работы;

2. Разработка технологии АСУ ССП.

3. Разработка пилотной версии программного обеспечения (ПО).

4. Внедрение пилотной версии в опытную эксплуатацию на выделенном полигоне станций Куйбышевской железной дороги.

5. Доработка ПО АСУ ССП по результатам опытной эксплуатации.

6. Внедрение в промышленную эксплуатацию.

7. Доработка технологии и ПО АСУ ССП для интеграции в автоматизированное рабочее место коммерческого диспетчера (АРМ КД).

8. Внедрение АРМа КД в опытную эксплуатацию.

На каждом из этапов ЖЦ на АСУ ССП воздействует большое количество дестабилизирующих факторов, которые приводят к разнообразным дефектам. На р и с. 1 приведено распределение интенсивностей различного рода дефектов в жизненном цикле АСУ ССП. Цифрами 1 - 8 обозначены этапы ЖЦ системы.

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

Рис. 1. Распределение интенсивностей дефектов Р и с. 2. Процент отклоненных заявок во вре-в ЖЦ АСУ ССП мя ЖЦ прохождения заявки

На р и с. 2 отображено распределение количества отклоненных заявки на перевозку грузов во время ЖЦ прохождения заявки, который состоит из следующих этапов:

1. Подача заявки грузоотправителем.

2. Ввод и согласование заявки в АС ЭТРАН.

3. Передача данных заявки в АСУ ССП.

4. Выбор заявки для планирования заказа.

5. Ввод уточненных данных заказа.

6. Ввод кодов причин корректировки заявки.

7. Передача данных в автоматизированную систему пономерной привязки вагонов к заявке (АСУ ПР).

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

В АСУ ССП анализируются дефекты следующих типов, каждый из которых делится на составные части .

1. Человеческие: случайные ошибки оператора, предумышленные действия персонала, низкое качество технической документации и уровней технологических процессов и т.д.

2. Технические: ошибки в программном обеспечении, сбои СУБД, отказы коммутационного оборудования, недоступность сети передачи данных, сбои электроснабжения и т.д.

3. Организационные: разногласия между различными подразделениями, невыполнение прямых указаний вышестоящего руководства, неверное понимание телеграмм и приказов и т.д.

4. Эргономические: неудобство восприятия экранных форм ввода данных, мелкий шрифт в выходных формах, большое количество действий, необходимых для ввода данных и т.д.

Выделим следующие основные причины невыполнения заявок грузоотправителей на перевозку грузов:

- неподача подвижного состава под погрузку;

- неосуществление погрузки по вине грузоотправителя (отсутствие денег на счету для оплаты перевозки, отсутствие груза, отказ грузополучателя в приеме груза и т.д.);

- некачественное уточнение коммерческим диспетчером заказа на планируемые сутки.

В последнее время в связи с ростом промышленности и объемов грузов, перевозимых по железной дороге, все чаще возникает острая нехватка подвижного состава для удовлетворения потребностей грузоотправителей. Вагонный парк практически не обновляется, количество вагонов уменьшается в связи с естественным износом и окончанием технологического времени эксплуатации, что ведет к отказу от исполнения заявок на перевозку грл/зов. В то же время, часто возникает ситуация, когда грузоотправитель, заявив желание оформить погрузку, в дальнейшем отказывается от уже поданных вагонов по различным причинам. Это может быть и отсутствие самого груза, и отсутствие на расчетном счету достаточных денежных средств на оплату перевозки, и отказ грузополучателя от приема груза, и какие-то другие

причины. Несмотря на то, что при отказе грузоотправителя от перевозки на него налагается

102

денежный штраф, доля невыполнения заявок по вине грузоотправителя составляет около 10%, Например, в июле 2006 года по вине грузоотправителя было не погружено 10498 вагонов (550 тыс. тонн), при общей погрузке за июль 103680 вагонов (1 млн. 978 тыс. тонн). При этом, за тот же период по вине железной дороги было не подано всего 124 вагона (6 тыс. тонн), что составляет менее 1%. Из общей вины грузоотправителя около трети - 3872 вагонов (203 тыс. тонн) или 3.7% от общего количества - составляет отказ от погрузки по причине отсутствия грузов. Данные цифры показывают необходимость и актуальность использования АСУ ССП в грузовой работе железной дороги. АСУ ССП позволила совместно с грузоотправителем уточнять заявку на перевозку грузов на планируемые сутки, предотвращая, таким образом, подачу вагонов тем грузоотправителям, которые и не собирались осуществлять погрузку и предоставляя вагоны тем, кому это действительно необходимо.

АСУ ССП внедрена в промышленную эксплуатацию с 1 августа 2005 г. на 154 станциях Куйбышевской ж.д. Общее количество установленных рабочих мест составляет 389. До внедрения АСУ ССП уточнение заказа на планируемые сутки осуществлялось коммерческим диспетчером вручную, что приводило к многочисленным ошибкам. Например, до ввода АСУ ССП в опытную эксплуатацию в июле 2005 года количество не поданных вагонов под погрузку составляло 2326, а с использованием АСУ ССП к декабрю того же года цифра уменьшилась до 314, что дало существенное повышение доходов от грузоперевозок.

БИБЛИОГРАФИЧЕСКИЙ СПИСОК

1. Махонько В.П., Сугробов Н.В., Куренков П.В. Автоматизация с мен но-суточного планирования погрузки по номенклатурным группам грузов // Транспорт; наука, техника, управление: Сб. ОИ ВИНИТИ, 2004. - № 7.

2. Никищенков С. А., Петров М. В. Средства негров иного программного контроля автоматизированной системы управления сменно-суточным планированием (АСУ ССП) //Свидетельство об офиц. ре г. программ для ЭВМ № 2005611734, 2005.

3. Петров М.В. Функциональная безопасность программных средств в автоматизированных системах планирования грузовой работы железной дороги. // Вестник Самар, гос. техн. ун-та. Самара: Сам [ТУ, 2006. Вып. 40. Серия “Технические науки”,

4. Никищенков Петров М.В., Чурсин О.В., Черемухин А.Н. Программное обеспечение АСУ сменно-

суточным планированием грузовой работы железной дороги // Транспорт наука, техника, управление. М: ВИНИТИ РАН. 2005. №10. С.И-16.

Статья поступила в редакцию 23сентнбря 2006 г.

УДК 681.5 В. Я. Родионов

ОСОБЕННОСТИ ВЫБОРА УСЛОВИЙ МЕТРОЛОГИЧЕСКОГО ОБСЛУЖИВАНИЯ ДЛЯ СЕРИЙНЫХ ДОЗИМЕТРИЧЕСКИХ ПРИБОРОВ, ИЗГОТАВЛИВАЕМЫХ ОАО «ПРИБОРНЫЙ ЗАВОД «СИГНАЛ»

Рассмотрена особенность выбора частоты метрологических поверок для дозиметрических приборов, которые серийно изготавливает ОАО «Приборный завод «Сигнал». Предложена математическая модель для определена оптимальной частоты метрологических испытаний для серийных приборов дозиметрического контроля в ядерном приборостроении.

Надежность и точность измерений, которые проводятся с помощью современных серийных дозиметрических приборов, во многом зависит от качества их производства и правильного выбора числа и частоты последующих метрологических поверок на этапе эксплуатации этих приборов. Точность дозиметрических измерений информации, поступающей от одного или нескольких датчиков (счетчиков) радиоактивности, определяется рядом факторов, обусловленных особенностями современной концепции создания носимых дозиметрических приборов в ядерном приборостроении [1]. Приоритетом этой концепции в настоящее время является конструирование переносимых автономных приборов, как правило, на базе однокристальных микроЭВМ (ОМЭВМ). Особенность ОМЭВМ состоит в том, что в них на базе достижений нанотехнологий в одном кристалле реализована автономно функционирующая ЭВМ, которая является ядром серийных дозиметрических приборов. Благодаря широкому

103

i Надоели баннеры? Вы всегда можете отключить рекламу.