Маскировка ошибки это

В качестве маскировки ошибок (англ. Error hidement ) используются процессы маскировки ошибок в потоках цифровых данных соответственно.

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

Еще одно необходимое требование для использования маскировки ошибок — это обнаружение ошибок .

литература

• Андреас Фризеке: аудиоэнциклопедия . Справочная работа для звукорежиссеров, Saur, Мюнхен 2007, ISBN 978-3-598-11774-9 .
• Томас Гёрне: Звуковая инженерия. 1-е издание, Карл Хансер Верлаг, Лейпциг, 2006 г., ISBN 3-446-40198-9 .
• Филипп Акерманн: Компьютер и музыка. Введение в цифровую обработку звука и музыки, Springer Verlag, Вена 1991, ISBN 978-3-211-82291-3 .
• Ад ван ден Энде, Ник Верхоэккс: Цифровая обработка сигналов. Friedrich Vieweg & Sohn Verlagsgesellschaft mbH, Висбаден 1990, ISBN 978-3-528-03045-2 .
• Олаф Манц: Коды, исправляющие ошибки. Построить — применить — декодировать, Springer Fachmedien, Висбаден, 2017 г., ISBN 978-3-658-14651-1 .

веб ссылки

• Сокрытие ошибок в знаниях ИТ (по состоянию на 4 сентября 2017 г.)

Исключение — твой друг

В середине девяностых, когда я переходил с программирования под DOS на Windows, мой наставник познакомил меня с механизмом исключений.
С тех пор в моём сознании укоренилось мнение: программа, падающая с исключением — плохая программа. Все исключения надо обрабатывать и завершать работу приложения в случае нештатной ситуации самостоятельно.
И это вполне актуально для обычного приложения под Windows. Ведь в случае падения приложения пользователь получает невнятное сообщение об ошибке и, как результат, негативное восприятие нестабильно работающего приложения.
Моё мнение начало меняться после знакомства с инструментами автоматической обработки исключений (таких как EurekaLog и аналогов).
И окончательно поменялось после знакомства с системой отчетов Google Play.
Этот пост — крик души против тех тысяч примеров, которые учат нас пихать в свой код необдуманные проверки.

Поводом для написания данного поста стал диалог с товарищем, который просил совета по реализации взаимодействия NDK с Java-кодом. Мне были показаны исходные коды, написанные на основе этого мануала.
Код, вызывающий вопросы:

    jmethodID method = env->GetStaticMethodID(interfaceClass, "callBack", "(Ljava/lang/String;)V");
    if(!method) {
        LOGE("callback_handler: failed to get method ID");
        return;
    }
    env->CallStaticVoidMethod(interfaceClass, method, js);

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

Проверка лишь замаскирует ошибку.

Очень важно понимать, что маскировка ошибок — это плохо. Гораздо хуже, чем падение приложения с исключением.
Вы можете сказать, что сообщение выводится в лог и всплывает во время тестирования.
Ну, отлично, если всплывает. А если не всплывёт? Если пользователю уйдёт неработающий код, который будет просто молча игнорировать вызов callBack?
Ваши пользователи будут работать с программой, которая не выполняет задуманный функционал. Хорошо, если это какая-нибудь мелочь, не влияющая серьёзно на работу приложения. Но что, если там скрывается важная часть кода, из-за которого все результаты работы пользователя оказываются некорректными?
Уберите проверку и первый пользователь, столкнувшийся с вызовом callBack, получит падение приложение. А Вы — отчёт об ошибке с заполненным call stack. Как минимум, это обратит Ваше внимание на проблему. Да, пользователь будет недоволен. Но Вы уже через пять часов зальёте на Google Play новую версию и тысячи пользователей даже не узнают об этой проблеме.
Это гораздо лучше, чем огромная клиентская база, работающая с приложением с миной замедленного действия.

Проверки на ошибки — это важная часть работы приложения. Ошибки самого разного рода возникают постоянно. Не бывает ни одного запуска сколь-либо сложного приложения, который бы произошел без возникновения нескольких ошибок. Но надо отделять штатные ошибки от нештатных. Штатные ошибки — те ошибки, которые допустимы и влияение которых предсказуемо. Эти ошибки нужно обрабатывать внутри приложения и менять логику работы в зависимости от ситуации. Нештатные ошибки ни в коем случае нельзя обрабатывать стандартными проверками. Нельзя просто взять и засунуть блок кода в if c проверкой на NULL. Вы всегда должны чётко понимать, почему объект стал NULL и чем это грозит в работе вашего приложения.

Так что же делать с проверками?

Можно не делать ничего. Просто убрать проверку. В приведённом примере мы точно знаем, что в случае отсутсвия метода будет вызвано исключение на следующем шаге.
Этот вариант приемлем, но не очень хорош, потому что вызов исключения находится за пределами нашего кода и мы не можем гарантировать, что исключение будет вызвано.
Поэтому, в идеальном случае, проверка нужна, но не с записью ошибки в лог, а с возбуждением исключения, чтобы гарантировать остановку выполнения кода и отправку отчёта об ошибке.

Конечно, я не открыл Америку для профессионалов, которые на собственном опыте знают, насколько вредна маскировка ошибок.
Этот текст нацелен на новичков, которые изучают программирование по примерам из интернета… А примеры, тем временем, пестрят бессмысленными и беспощадными проверками…

^ ОБЩЕТЕХНИЧЕСКИЕ ЗАДАЧИ И ПУТИ ИХ РЕШЕНИЯ

УДК 004.896+656:25

М. А. Гордон, М. Н. Василенко, Д. В. Седых, Д. В. Зуев

МАСКИРОВКА ОШИБОК В ЭЛЕКТРОННОЙ ТЕХНИЧЕСКОЙ ДОКУМЕНТАЦИИ И МЕТОДЫ ИХ ОБНАРУЖЕНИЯ

Дата поступления: 16.08.2016 Решение о публикации: 16.12.2016

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

Электронный документооборот, АРМ-ВТД, кибербезопасность, техническая документация.

Mikhail A. Gordon, engineer, gordon_ma@mail.ru; Mikhail N. Vasilenko, D. Eng., professor, vasilenko. m.n@gmail.com; *Dmitry V. Sedykh, engineer, sedyhdmitriy@gmail.com; Denis V. Zuev, Cand. Eng., associate professor, zuevdv@gmail.com (Emperor Alexander I St. Petersburg State Transport University) CONCEALED ERRORS IN ELECTRONIC TECHNICAL DOCUMENTATION AND METHODS FOR THEIR DETECTION

Objective: Research the types of concealed errors in technical documentation and elucidate methods for their elimination. Methods: Information theory methods and graph theory methods for presenting technical documentation in electronic format are employed. Results: A definition is given for error in technical documentation. Main problems and specifics pertaining to work with electronic technical documentation are examined. Specifics of particular types of documents wherein errors may cause severe repercussions such as train breakdowns and derailment are examined. Causes of errors are investigated, along with the extent of their detectability in various documents and at various stages of automatic systems operation. A classification was developed for concealed deliberate errors, based on the following criteria: technological time point, error repetition factor, error existence time and error detectability. Additionally,

the research investigates error concealment based on the repetition factor and specifics for various automatics designs. Examples are given for concealment of various types of errors in real automatics structure diagrams, with investigation of their consequences. Methods of protection against errors in electronic documentation are suggested. Practical importance: The application of the suggested error classification allows to proceed toward practical design of technical solutions for automated checking of technical documentation. This article describes errors in technical documentation stored in electronic format. The article suggests methods for protections against errors in electronic technical documentation, which, when applied in an integrated fashion, will allow for a new level of safety in the application of modern approaches toward planning and maintaining technical documentation.

Electronic document flow, automated workplace for technical documentation maintenance, cybersecurity, technical documentation.

Введение

В настоящее время хозяйство автоматики и телемеханики ОАО «РЖД» переходит на безбумажные технологии. В ближайшее время вся техническая документация (ТД) будет только электронной, в частности и на микропроцессорные системы электрической централизации. В связи с тем, что ТД на объекты железнодорожной автоматики и телемеханики (ЖАТ) переходит полностью в киберпростран-ство, возникает вопрос о кибербезопасности электронной ТД [1, 2].

Главным вопросом кибербезопасности является защита объектов (в рассматриваемом случае это ТД) от кибератак, которые могут либо нарушать конфиденциальность ТД, либо изменять ТД, внося в нее ошибки.

Понятие ошибки и ее маскировки в технической документации

Перед тем, как дать определение ошибки, будем разделять ТД ЖАТ на проектную (до ввода в эксплуатацию) и исполненную (после ввода в эксплуатацию систем ЖАТ и соответствующую действующим устройствам). Внесение изменения в исполненную документацию возможно только в случаях, определенных инструкцией по ведению технической документации железнодорожной автоматики и телемеханики, утвержденной распоряжением ОАО «РЖД» от 18 августа 2015 г. № 2080р.

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

По причине возникновения ошибки можно разделить на:

1) случайные — ошибки в электронном документе, возникшие в случае какого-либо технического сбоя без влияния человека;

2) преднамеренные — изменение электронного документа посредством кибератаки, включая изменение ТД на каком-либо этапе ее жизненного цикла как по злому умыслу, так и по незнанию нормативной документации, приводящее к изменению логики системы или не стабильной ее работе.

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

Маскировки преднамеренных ошибок в ТД можно классифицировать по следующим критериям:

— по выбору технологического момента времени (внесение ошибки после сохранения

и утверждения проекта, после внешнего контроля, по результатам необходимых изменений при производстве, в результате плановых изменений в ТД);

— по выбору типа ТД (внесение ошибки в текстовые документы, эксплуатационные чертежи, принципиальные схемы, монтажные схемы, программное обеспечение);

— по кратности ошибки (одиночные, кратные);

— по времени существования (статические, временные);

— по обнаружимости (в процессе стандартных проверок при пуско-наладочных работах (ПНР), не обнаружимые).

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

— в процессе проектирования;

— после сохранения и утверждения проекта институтом-проектировщиком в момент передачи ТД на внешний контроль, экспертизу, согласование, утверждение;

— после внешней экспертизы, согласования и утверждения в момент передачи на завод-изготовитель и в производство;

— в процессе ПНР;

— в результате процесса плановых изменений ТД в эксплуатирующей организации.

Ошибки по типам ТД

Ошибки по выбору типа ТД можно разделить на следующие:

1. Ошибки, внесенные в текстовые документы.

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

Ошибки в таблице зависимости особенно опасны на этапе проектирования. Таблица

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

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

2. Ошибки, внесенные в эксплуатационные чертежи.

Так же как и ТВЗ, схематический план есть исходные данные для составления ПО МПЦ. Ошибки в схематическом плане особенно опасны на этапе проектирования. Если произойдет кибератака на схематический план после его согласования и утверждения и передачи задания на формирования ПО, то это не повлияет на функциональность системы.

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

Ошибка в чертежах кабельных сетей может привести к задержкам поездов, снижению производительности труда, дополнительным материальным затратам, в частности когда она изменяет тип кабеля, то к влияниям в цепях ЖАТ, таким как ложное занятие рельсовых цепей.

3. Ошибки, внесенные в принципиальные схемы.

В связи с тем, что вся логика систем ЖАТ приведена в принципиальных схемах, то и ошибки в них могут вызвать различные последствия, поэтому они являются наиболее опасными.

Ошибки в принципиальных схемах можно разделить на три вида:

— обнаруживаемые системой и приводящие ее в защитное состояние;

— не обнаруживаемые системой, но выявляемые в процессе ПНР;

— не обнаруживаемые системой и не выявляемые в процессе ПНР.

4. Ошибки, внесенные в монтажные схемы.

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

5. Ошибки, внесенные в схемы аппаратов управления.

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

6. Ошибки, внесенные в программное обеспечение.

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

Маскировка кратностью ошибки

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

Под одиночной ошибкой будем понимать одно изменение в одной единице ТД, приводящее к изменению логики системы (исключение какой-либо одной проверки в каком-либо

алгоритме системы, добавление одной лишней проверки в каком-либо алгоритме системы, исключение одного защитного устройства и т. д.).

Под кратной ошибкой будем понимать совокупность нескольких одиночных ошибок.

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

Маскировка по времени существования ошибки

Ошибки по состоянию можно разделить на статические и временные.

Под временными будем понимать такие ошибки, которые проявляются либо в ТД только в какой-нибудь промежуток времени, например во время монтажа на производстве или на объекте строительства, а потом автоматически исчезают, либо, наоборот, после ПНР и ввода в эксплуатацию объекта в какой-нибудь заранее определенный момент времени.

Под статическими будем понимать те ошибки, которые по истечению времени автоматически не исчезают.

Временным ошибкам более всего подвержена ТД на ПО микропроцессорных систем.

Маскировка обнаружения при ПНР

Ошибки по обнаружимости можно разделить на обнаружимые в процессе стандартных проверок во время ПНР и необнаружимые.

Под обнаружимой будем понимать такую ошибку в ТД, которая проявляется при процессе стандартных проверок во время ПНР, регламентируемых инструкцией ЦШ/571.

Под необнаружимой будем понимать ошибку, которая не проявляется в процессе ПНР.

Примеры ошибок в ТД

В качестве ошибок в ТД приведем такие примеры:

1. Одиночная ошибка, обнаруживаемая системой и приводящая ее в защитное состояние. На рис. 1 показана схема управления стрелкой для системы ББ1Ьоск 950. В качестве изменения схемы выступает перепутывание фаз питания стрелочного электропривода. При этом по команде перевода стрелки в «плюс» стрелка переведется в «минус». Но система, получив минусовой контроль стрелки, перейдет в защитное состояние.

2. Одиночная ошибка, не обнаруживаемая системой и приводящая ее в опасное состояние, но выявляемая в процессе ПНР. На рис. 2 показана схема релейного шкафа входного светофора для системы ББ1Ьоск 950. В качестве изменения схемы выступает перепутывание проводов «1Ж» и «з», идущих с поста ЭЦ в релейный шкаф. При этом по команде зажигания желтого огня на светофоре загорится зеленый огонь. В системе будет ложно осуществляться контроль горения желтого огня. Но при ПНР это обнаруживается визуально. На рис. 3 показано то же изменение в схеме, но представленное в монтажной документации.

3. Кратная ошибка, не обнаруживаемая системой, приводящая ее в опасное состояние и не выявляемая в процессе ПНР. На рис. 4 показана схема релейного шкафа входного светофора для системы ББ1Ьоск 950. В качестве изменения схемы служит включение переключающего контакта реле «ДСН» в цепь включения желтого огня, тыловой контакт присоединен с проводом «з». При этом при включенном режиме двойного снижения напряжения по команде зажигания желтого огня на светофоре

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

Методы защиты от ошибок в электронной ТД

Для защиты от ошибок (в том числе и ки-бератак) должен быть использован комплекс мер защиты, включающий в себя:

1. Использование отечественного ПО для ведения ТД [3-5] на всех этапах ее жизни (проектирование, производство на заводе-изготовителе, ведение в эксплуатирующей организации), обеспечивающее исключение недекларированных возможностей и несанкционированного доступа к ТД.

2. Применение технологии электронной цифровой подписи для защиты ТД и проверки наличия несанкционированного изменения в ТД на всех стадиях жизни (от проектирования до эксплуатации) [6].

3. Создание эталонного образца ТД, периодическая сверка используемой ТД с эталонной копией (контрольным экземпляром) [7-9].

4. Внедрение экспертной системы проверки ТД АС-ЭСР [10-16], которая проводит полную функциональную проверку эксплуатационной ТД, включая текст ПО для релейно-процессорных и микропроцессорных систем, выполняет соответствие одного типа ТД с другим типом (соответствие двухниточ-ного плана станции со схематическим планом, таблиц зависимости положения стрелок и сигнальных показаний светофоров в маршрутах со схематическим планом, монтажных схем с принципиальными схемами и т. д.).

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

м о

СП

1Л

со

о п Ф

га о. и» ю

ф

сг с

О)

он «О О

—! <-+

С <■

ф

105К

3×220 В

15Н 15Н 15Н 15Н

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

Л7

«Ж Л5 Л4

15Н

15Н —•—

15Н

лз

Л2

Л1

Электропривод

Рис. 1. Ошиока, обнаруживаемая системой и приводящая ее в защитное состояние

0 № £

ф х

1

-С

ф

Г)

л ^

ф

ы Си

О) -С

п

X

«О

ф

Е

ф

I

О-

Н21р-2

СГ-5Г

с

нгю-в

-Нз.

0}

Н210-Ю

сы

СГ-5Г

63

№10-14 ига

65

-‘•32

I 33

нко

1 глг

63

нгп-1 ни<

20 0,зз/1в5

-Чз 72

ш_дсн

ЗГ-

33

РК

63

№11-3 НРК

6(М

РИ.2-3

БЛ59 V-РР14-1

52 65

Щ_,НК0

51

66

ЧТО

2Ж

№11-5

О 20 0,33/185

67 67

нм на «зЛ-1-32 ,2Р|1~

67

НСА_

-Н2

I 15

еао

л НП1М ИвОЩ-24

МБ

~НБ~

«И»

23

Н25-2 5

~тг

НТК

«ШЕЕ=гГ

III?

СМ

45

£

СТ-5Г

47 НР2¥

раж

№11—Э

Н21]-11

Г

51

СТ-5Г 37

06

№11.-13

5″

з,»

СТ-5Г

Лпмпн 25Вт ,12В

ниж

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

Н}

64 НРК1

нп;-б

НС№

411-<-42

41

НК Н212-2

ж

СТ-5Г

43 НРК

ж

СГ-5Г

Н212-6

НРК

№12-4

НОК

Н11^-12

нгж

Н112-8

НР2Ж

64 КРК1 «я1-^52

Н112-10

НБ

Н112—14

НСЮКБ

Рис. 2. Ошибка, не обнаруживаемая системой и приводящая ее в опасное состояние, но выявляемая в процессе ПНР (принципиальная схема)

/

Ря^ J

5 3 2^^^ 1

NN komi Нз NN NN kfiHIll НР1Ж NN ксшгт NN kflHItï Н1Ж

1 JJJ^ H212-10 1 H212-12 1 Hl 12-+

2 17-2 3-2 2 1-2 5-2 2 3-2 64-41

Ъ 17-3 Н2КЫС 3 1-3 Ъ 3-3 H210-4

4 4 4

H2ia-B 5 Н210-Б 5 И2Ш-2

6 e

7 7 7

Рис. 3. Ошибка, не обнаруживаемая системой и приводящая ее в опасное состояние, но выявляемая в процессе ПНР (монтажная схема)

01 с6.*ЕТ

а ж

№10-2

№10-4

31 Н1Ж

Ж

стз!г ник

Н21д-в

з

«V

Ж

£

СУ

Оз

Н210-10

5н

т

НРз.

Рз

СТ-5Г

63

кгю-м НРК

65

-■■32

нко

ок

63

№11-1 НРК

0,33/185

42 72

|_43_ДСН

ЗГ1-^32″

33

РК

63

№11-3 НРК

БЛ60 РР1.2-3

ьгаэ

1,—4=—. 2

-«•52 65 |_53_.НКО

5ТС

Г53 1

2Ж

№11-5

66 НРКО

о 20 0.33/185

67

НСА

67

НСА

ДБ

67 НСА

«+Т1-

I 13

1Н110-4 ЛВ0ЧЧ-24

МБ

ЕВ

23

83

73

Н25-2 5

нтк

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

С0БС-2Г

ПЬ

ПК

Р23К

нац-э

№11-11

СГ-5Г

Ланпн 25Вт ,12В

I_.ДСН I

123-Гп

Н212-10

1012-12

_НЩ=4

К21£-14

64

НРЮ

_НЩ=6

411-1+2

41

НИ №12-2

а-5г

£

+3 НРК

Ж

СГ-5Г

№12-6

НЙ

НОШ

НК

Рис. 4. Ошибка, не обнаруживаемая системой, приводящая ее в опасное состояние, и не выявляемая в процессе ПНР (принципиальная схема)

/

Ряд 7

2

NN кон m дсн

1 H18-4-2

2 H18-3-2

3 4

4 3

12 31-1

11 H212-10

13 35-1

22

21

23

32 БЛ60-1

31 63-43

33 БЛ59-1

42

Рис. 5. Ошибка, не обнаруживаемая системой и приводящая ее в опасное состояние, но не выявляемая в процессе ПНР (монтажная схема)

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

Заключение

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

Библиографический список

1. Василенко М. Н. Кибербезопасность технической документации ЖАТ / М. Н. Василенко, Д. В. Зуев // Автоматика, связь, информатика. -2015. — № 7. — С. 21-23.

2. Василенко М. Н. Кибербезопасность технической документации железнодорожной автоматики и телемеханики / М. Н. Василенко, Д. В. Зуев // Транспорт Российской Федерации. — 2015. — № 2(57). -С. 55-58.

3. Василенко М. Н. Принципы организации электронного документооборота технической документации / М. Н. Василенко, Б. П. Денисов, П. Е. Бу-лавский, Д. В. Седых // Транспорт Российской Федерации. -2006. — № 7. — С. 31-35.

4. Василенко М. Н. Развитие электронного документооборота в хозяйстве АТ / М. Н. Василенко, В. Г. Трохов, Д. В. Зуев, Д. В. Седых // Автоматика, связь, информатика. -2015. — № 1. — С. 14-16.

5. Седых Д. В. Применение отраслевого формата технической документации на устройства железнодорожной автоматики и телемеханики для интеграции приложений / Д. В. Седых, С. А. Суханов // Изв. ПГУПС. — 2005. — Вып. 3. — С. 74-79.

6. Василенко М. Н. Согласование и утверждение технической документации с использованием электронной цифровой подписи / М. Н. Василенко, П. Е. Булавский, Б. П. Денисов, Д. А. Имануилов // Наука и техника транспорта. — 2010. — № 1. -С. 18-23.

7. Василенко М. Н. Сверка технической документации ЖАТ / М. Н. Василенко, А. М. Горбачев, Р. Т. Мустафаев // Автоматика, связь, информатика. — 2013. — № 4. — С. 11-13.

8. Балуев Н. Н. Проблемы внедрения отраслевого формата / Н. Н. Балуев, М. Н. Василенко,

B. Г. Трохов, Д. В. Седых // Автоматика, связь, информатика. — 2010. — № 3. — С. 2.

9. Матушев А. А. Распознавание структуры монтажных схем ЖАТ / А. А. Матушев, Д. В. Седых // Автоматика, связь, информатика. — 2015. -№ 10. — С. 4-7.

10. Горбачев А. М. Автоматизация анализа, экспертизы и сверки технической документации системы железнодорожной автоматики и телемеханики / А. М. Горбачев // Изв. ПГУПС. — 2012. — Вып. 4. —

C. 73-78.

11. Безродный Б. Ф. Автоматизация проверки проектов на основе АРМ-ТЕСТ / Б. Ф. Безродный, М. Н. Василенко, Б. П. Денисов, Д. В. Седых // Автоматика, связь, информатика. — 2008. — № 9. -С. 22-24.

12. Седых Д. В. Учет работы приборов с помощью АРМ-УРП / Д. В. Седых // Автоматика, связь, информатика. — 2007. — № 3. — С. 7-8.

13. Василенко М. Н. Автоматизированная система экспертизы схемных решений железнодорожной автоматики и телемеханики / М. Н. Василенко, А. М. Горбачев, Д. В. Зуев, Е. В. Григорьев // Транспорт Российской Федерации. — 2011. — № 5(36). -С. 64-67.

14. Тележенко Т. А. Автоматизированная система экспертизы схемных решений / Т. А. Теле-женко // Автоматика, связь, информатика. — 2009. -№ 5. — С. 24-26.

15. Гладкий А. В. Формальные грамматики и языки / А. В. Гладкий. — М. : Наука, 1973. — 368 с.

16. Люгер Дж. Ф. Искусственный интеллект : стратегии и методы решения сложных проблем / Дж. Ф. Люгер ; пер. с англ. К. Протасова. — М. : Вильямс, 2005. — 864 с.

References

1. Vasilenko M. N., Zuev D. V. Kiberbezopasnost’ tekhnicheskoj dokumentatsii ZhAT [Cybersecurity of technical documentation for railway automatics and telemechanics]. Avtomatika, svyaz’, informatika [Automatics, communication, informatics], 2015, no. 7, pp. 21-23. (In Russian)

2. Vasilenko M. N., Zuev D. V. Kiberbezopasnost’ tekhnicheskoj dokumentatsii zheleznodorozhnoj av-tomatiki i telemekhaniki [Cybersecurity of technical documentation for railway automatics and telemechanics]. Transport Rossijskoj Federatsii [Transport of the Russian Federation], 2015, no. 2 (57), pp. 55-58. (In Russian)

3. Vasilenko M. N., Denisov B. P., Bulavskij P. E., Sedykh D. V. Printsipy organizatsii jelektronnogo do-kumentooborota tekhnicheskoj dokumentatsii [Technical documentation: electronic workflow management]. Transport Rossijskoj Federatsii [Russian Federation Transport], 2006, no. 7, pp. 31-35. (In Russian)

4. Vasilenko M. N., Trokhov V. G., Zuev D. V., Sedykh D. V. Razvitie jelektronnogo dokumentooboro-ta v khozyajstve AT [Developing electronic document workflow in AT units]. Avtomatika, svyaz’, informatika [Automatics, communication, informatics], 2015, no. 1, pp. 14-16. (In Russian)

5. Sedykh D. V., Sukhanov S. A. Primenenie otraslevogo formata tekhnicheskoj dokumentatsii na us-trojstva zheleznodorozhnoj avtomatiki i telemekhaniki dlya integratsii prilozhenij [Applying industry-specific formats of technical documentation for railway automatics and telemechanics equipment for integration of applications]. Izvestiya Peterburgskogo universiteta putej soobshcheniya [The St. Petersburg Transport University Bulletin]. Saint Petersburg, PGUPS Publ., 2005, no. 3, pp. 74-79. (In Russian)

6. Vasilenko M. N., Bulavskij P. E., Denisov B. P., Imanuilov D. A. Soglasovanie i utverzhdenie tekh-

nicheskoj dokumentatsii s ispol’zovaniem jelektronnoj tsifrovoj podpisi [Coordinating and approving technical documentation using an electronic digital signature]. Nauka i tekhnika transporta [Science and engineering of transport], 2010, no. 1, pp. 18-23. (In Russian)

7. Vasilenko M. N., Gorbachev A. M., Musta-faev R. T. Sverka tekhnicheskoj dokumentatsii ZhAT. [Verification of technical documentation for railway automatics and telemechanics]. Avtomatika, svyaz’, informatika [Automatics, communication, informatics], 2013, no. 4, pp. 11-13. (In Russian)

8. Baluev N. N., Vasilenko M. N., Trokhov V. G., Sedykh D. V. Problemy vnedreniya otraslevogo formata [Industry format implementation issues]. Avtomatika, svyaz’, informatika [Automatics, communication, informatics], 2010, no. 3, pp. 2. (In Russian)

9. Matushev A. A., Sedykh D. V. Raspoznavanie struktury montazhnykh skhem ZhAT [Identification of wiring diagrams for railway automatics and telemechanics]. Avtomatika, svyaz’, informatika [Automatics, communication, informatics], 2015, no. 10, pp. 4-7. (In Russian)

10. Gorbachev A. M. Avtomatizatsiya analiza, jek-spertizy i sverki tekhnicheskoj dokumentatsii sistemy zheleznodorozhnoj avtomatiki i telemekhaniki [Automation of analysis, expert assessment and verification of technical documentation for railway automatics and telemechanics systems]. Izvestiya Peterburgskogo universiteta putej soobshcheniya [The St. Petersburg Transport University Bulletin]. Saint Petersburg, PGUPS Publ., 2012. 4, pp. 73-78. (In Russian)

11. Bezrodnyj B. F., Vasilenko M. N., Denisov B. P., Sedykh D. V. Avtomatizatsiya proverki proektov na os-nove ARM-TES [Automation of project checking based on automated workplace testing]. Avtomatika, svyaz’, informatika [Automatics, communication, informatics], 2008, no. 9, pp. 22-24. (In Russian)

12. Sedykh D. V. Uchet raboty priborov s pomo-shch’ju ARM-URP [Logging of device operation based on the automated workplace for equipment operation control]. Avtomatika, svyaz’, informatika [Automatics, communication, informatics], 2007, no. 3, pp. 7-8. (In Russian)

13. Vasilenko M. N., Gorbachev A. M., Zuev D. V., Grigoriev E. V. Avtomatizirovannaya sistema jekspert-izy skhemnykh reshenij zheleznodorozhnoj avtomatiki i telemekhaniki [Automated system for expert analysis

of circuit design in railway automatics and telemechanics]. TransportRossijskoj Federatsii [Transport of the Russian Federation], 2011, no. 5 (36), pp. 64-67. (In Russian)

14. Telezhenko T. A. Avtomatizirovannaya sistema jekspertizy skhemnykh reshenij [Automated expert analysis system for circuit design]. Avtomatika, svyaz’, informatika [Automatics, communication, informatics], 2009, no. 5, pp. 24-26. (In Russian)

15. Gladkij A. V. Formal’nye grammatiki i yazyki [Formal grammar and languages]. Moscow, Nauka Publ., 1973, 368 p. (In Russian)

16. Luger George. F. Iskusstvennyj intellekt: strate-gii i metody resheniya slozhnykhproblem [Artificial Intelligence. Structures and Strategies for Complex Problem Solving]. 4th edition/translated from English. Moscow, Williams Publ., 2005, 864 p. (In Russian)

ГОРДОН Михаил Аркадьевич — инженер, gordon_ma@mail.ru; ВАСИЛЕНКО Михаил Николаевич — доктор техн. наук, профессор, уа8Непко. m.n@gmail.com; *СЕДЫХ Дмитрий Владимирович — инженер, sedyhdmitriy@gmail.com; ЗУЕВ Денис Владимирович — канд. техн. наук, доцент, zuevdv@gmail.com (Петербургский государственный университет путей сообщения Императора Александра I).