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

• 1. Постановка задачи
• 2. Назначение и структура объекта проектирования

3. Анализ существующих языков программирования

• 4. Представление базы знаний по выбору языка программирования
• 5. Выбор и обоснование механизма вывода решения
• 6. Программа формирования основного меню
• 7. Программная реализации механизма выработки решения

8. Руководство пользователя

1. Постановка задачи

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

— С;

— С++;

— Java;

— Delphi;

— Perl;

— PHP;

— Basic;

— C#.

2. Назначение и структура объекта проектирования

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

Подсистема поддержки принятия решения состоит из:

— ядра ПППР. Основной процесс, выполняющий сбор, накопление, обработку и выдачу информации о состоянии объектов;

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

— сервера, обеспечивающий веб-интерфейс ПППР. Служебная подсистема, предназначенная для отображения результатов работы системы ПППР конечному пользователю или администратору ПППР при помощи браузера;

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

Структурную организацию ПППР можно представить как на рисунке 2.1.

Рисунок 2.1 — Структурная организация ПППР Компоненты ПППР выполняют следующие функции. Функциональная организация ПППР Ядро ПППР выполняет периодические проверки состояния машин (рабочих станций, серверов, межсетевых экранов, коммуникационного оборудования), входящих в сеть.

Проверки состояния производится при помощи Агента ПППР — вспомогательное программное обеспечение, входящее в систему ПППР и устанавливаемое на клиентских машинах (серверах, рабочих станциях). В состав Агента ПППР входят две подсистемы, обеспечивающие активные и пассивные проверки. В случае активных проверок ядро ПППР обращается к Агенту ПППР с требованием произвести проверку требуемых параметров. В случае пассивных проверок Агент ПППР самостоятельно производит проверки требуемых параметров и отсылает результаты ядру системы ПППР.

Ядро фильтрует сообщение. И выбирает сообщения о сбоях. Если сбой произошёл, администратору системы ПППР отправляется соответствующие уведомление. Ядро ПППР регистрирует принятое сообщение, определяет класс сбоя и сохраняет полученные данные в журнале. Классификация происходит по базе данных (БД), которая содержит все виды сбоев, его идентификационный номер, название сбоя, его подробное описание, возможные способы устранения сбоя. БД может пополняться администратором.

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

Для отображения уведомлений о сбоях и отчётов используется динамический веб-интерфейс. За поддержку веб-интерфейса в ПППР отвечает сервер.

Содержание отчёта, период времени, за который отправляется отчёт и другие параметры можно задать в настройках.

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

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

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

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

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

Можно выделить следующие три вида сбоев, вызывающих отказные ситуации:

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

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

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

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

— привлечение к разработке специалиста по автоматизируемой предметной области и/или специалиста по эргономике — это позволит сделать пользовательский интерфейс системы более удобным и понятным.

Для классификации сбоев по категориям выделим следующие параметры сбоя:

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

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

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

В табл. 2.1 приведена классификация типов сбоев по указанным выше признакам:

Таблица 2.1

Классификация типов сбоев системы

Отказы вызывают длительное нарушение функционирования системы, или, по ГОСТ 27.002−89 приводят ее в предельное состояние. Предельное состояние — это состояние, при котором дальнейшая эксплуатация системы недопустима или нецелесообразна, либо восстановление ее работоспособного состояния невозможно или нецелесообразно. Тем самым в ГОСТ 27.002−89 не делается разницы между отказом и аварией. Будем называть отказом состояние системы, при котором восстановление ее работоспособного состояния возможно.

Отказы классифицируются согласно ГОСТ 27.002−89 следующим образом:

— По временным характеристикам:

а) внезапный отказ — отказ, вызванный резким скачкообразным изменением одного из параметров системы или обрабатываемых системой данных. Ситуации, вызывающие такие отказы могут моделироваться при нагрузочном тестировании при помощи резкого повышения уровня нагрузки на систему (например, количества одновременно подключившихся пользователей) с последующей быстрой стабилизацией нагрузки.

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

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

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

— По причинам:

а) ресурсный отказ — отказ, в результате которого система достигает предельного состояния, т. е. такой отказ вызван в первую очередь нехваткой ресурсов (например, дискового пространства) для работы системы. Ситуации, вызывающие такие отказы, могут моделироваться при нагрузочном тестировании.

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

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

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

— По способу обнаружения:

а) явный отказ — отказ, который обнаруживается сразу после его возникновения штатными средствами контроля состояния системы.

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

— По связи с другими отказами:

а) независимый отказ — отказ, возникновение которого не обусловлено другими отказами.

б) зависимый отказ — отказ, возникновение которого вызвано другими отказами.

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

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

Примеры произошедших инцидентов:

— Транспорта СОД_А:

а) TATL 03А *** Неверен адрес УНО=<�адрес отправителя> в кодограмме Причина. Принята кодограмма с адресом получателя, отсутствующим в Адресной книге МКТК.

Действия оператора. Сообщить Администратору МКТК.

б) TATL 04А *** НС <�номер> НЕ ГОТОВО Причина. Информация оператору о переходе направления связи в неготовность по инициативе абонента.

Действия оператора. Не требуются.

в) TATL 10А *** Адресат <�адрес сети> не найден Причина. Информация оператору об отсутствии адреса получателя в Адресной книге МКТК.

Действия оператора. Исправить параметры объекта и перезапустить МКТК.

д) TATL 11А *** Получен запрет по НС=<�номер> и КС=<�категория срочности>

Причина. Информация оператору о запрете приема кодограмм указанной категории срочности.

Действия оператора. Не требуются.

е) TATL 80Е *** Ошибка выборки интерфейсного блока из очереди, RC=<�код ошибки>

Причина. Информация оператору об ошибке выборки интерфейсного блока из очереди. Транспорт СОД_А продолжает работу, но нормальная работа МКТК не гарантируется.

Действия оператора. Перезапустить МКТК. При устойчивом появлении ошибки сообщить разработчику.

ж) TATL 91S !!! Ошибка конфигурации !!! Не заданы направления связи, RC=<�код ошибки>

Причина. Обнаружена ошибка в конфигурации МКТК. транспорт СОД_А аварийно завершается. Нормальная работа МКТК не гарантируется.

Действия оператора. Исправить конфигурацию МКТК. Перезапустить МКТК.

— транспорта СОД_Р:

а) TRED 02A *** Транспорт НЕ ЗАГРУЖЕН Причина. Инициализация транспорта завершена из-за ошибок. Загрузка транспорта прекращается.

Действия оператора. Сообщить Администратору МКТК — возможно ошибка конфигурации МКТК.

б) TRED 13А *** Нет связи с аппаратурой передачи данных <�имя_направления>

Причина. Не выполнены условия функционирования аппаратуры изделия 9п20 или нет связи с драйвером.

Действия оператора. Проверить аппаратуру.

в) TRED 14A *** <�имя_направления> НЕ ГОТОВО Причина. Транспорт не может восстановить работоспособность направления связи.

Действия оператора. Если направление связи долго не восстанавливается или часто выходит в неготовность — сообщить Администратору МКТК.

г) TRED 80Е *** Ошибка <�операция> RC=<�код_ошибки><�доп_инф_разработчика>

Причина. Информация для разработчика об ошибке выполнения <�операции>. Ошибка устранена программными средствами.

Действия оператора. При устойчивом появлении ошибки сообщить разработчику.

д) TRED 90S !!! Системная ошибка !!! <�операция> RC=<�код_ошибки> <�доп_инф_разработчика>

Причина. Информация для разработчика об ошибке выполнения <�операции>. Продолжение функционирования программного обеспечения МКТК невозможно и транспорт завершен.

Действия оператора. Перезапустить МКТК.

е) TRED 91S !!! Ошибка конфигурации !!! <�доп_инф_об_ошибке>

Причина. Программа обнаружила ошибку в конфигурации таблиц МКТК. Продолжение функционирования программного обеспечения МКТК невозможно.

Действия оператора. Обратиться к Администратору МКТК для устранения ошибки конфигурирования МКТК.

После устранения ошибки перезапустить МКТК.

— Транспорта выделенных каналов:

а) TIMP 02A *** Транспорт НЕ ЗАГРУЖЕН Причина. Инициализация транспорта завершена из-за ошибок. Загрузка транспорта прекращается.

Действия оператора. Сообщить Администратору МКТК — возможно ошибка конфигурации МКТК.

б) TIMP 14A *** <�имя_канала> НЕ ГОТОВ Причина. Транспорт не может восстановить работоспособность канала связи.

Действия оператора. Если канал связи долго не восстанавливается или часто выходит в неготовность — сообщить Администратору МКТК.

в) TIMP 80E *** Ошибка <�операция> RC=<�код_ошибки> <�доп_инф_разработчика>

Причина. Информация для разработчика об ошибке выполнения <�операции>. Ошибка устранена программными средствами.

Действия оператора. При устойчивом появлении ошибки сообщить разработчику.

г) TIMP 90S !!! Системная ошибка !!! <�операция> RC=<�код_ошибки> <�доп_инф_разработчика>

Причина. Информация для разработчика об ошибке выполнения <�операции>. Продолжение функционирования программного обеспечения МКТК невозможно и транспорт завершен.

Действия оператора. Перезапустить МКТК.

д) TIMP 91S !!! Ошибка конфигурации !!! <�доп_инф_об_ошибке>

Причина. Программа обнаружила ошибку в конфигурации таблиц МКТК. Продолжение функционирования программного обеспечения МКТК невозможно.

Действия оператора. Обратиться к Администратору МКТК для устранения ошибки конфигурирования МКТК.

После устранения ошибки перезапустить МКТК.

— Транспорта коммутируемых каналов а) TTLF 02A *** Транспорт НЕ ЗАГРУЖЕН Причина. Инициализация транспорта завершена из-за ошибок. Загрузка транспорта прекращается.

Действия оператора. Сообщить Администратору МКТК — возможно ошибка конфигурации МКТК.

б) TTLF 14A *** <�имя_канала> НЕ ГОТОВ Причина. Не может восстановиться готовность драйвера, взаимодействующего с каналом связи, установившим соединение.

Действия оператора. Если канал связи долго не восстанавливается или часто выходит в неготовность — сообщить Администратору МКТК.

в) TTLF 80Е *** Ошибка <�операция> RC=<�код_ошибки><�доп_инф_разработчика>

Причина. Информация для разработчика об ошибке выполнения <�операции>. Ошибка устранена программными средствами.

Действия оператора. При устойчивом появлении ошибки сообщить разработчику.

г) TTLF 90S !!! Системная ошибка !!! <�операция> RC=<�код_ошибки> <�доп_инф_разработчика>

Причина. Информация для разработчика об ошибке выполнения <�операции>. Продолжение функционирования программного обеспечения МКТК невозможно и транспорт завершен.

Действия оператора. Выполнить действия. Перезапустить МКТК.

д) TTLF 91S !!! Ошибка конфигурации !!! <�доп_инф_об_ошибке>

Причина. Программа обнаружила ошибку в конфигурации таблиц МКТК. Продолжение функционирования программного обеспечения МКТК невозможно.

Действия оператора. Обратиться к Администратору МКТК для устранения ошибки конфигурирования МКТК. После устранения ошибки перезапустить МКТК.

— Транспорта СОД_Ш а) TSHR 02A *** Транспорт НЕ ЗАГРУЖЕН Причина. Инициализация транспорта завершена из-за ошибок. Загрузка транспорта прекращается.

Действия оператора. Сообщить Администратору МКТК — возможно ошибка конфигурации МКТК.

б) TSHR 12A *** Очередь <�имя_очереди> НЕ ДОСТУПНА Причина. Транспорту не доступен канал связи. Возможно, нет связи с РС_контроллером.

Действия оператора. Сообщить Администратору МКТК. После устранения неисправности будет восстановлена готовность канала СОД_Ш. Производить перезагрузку МКТК не следует, если нет ошибок в конфигурации МКТК.

в) TSHR 13A *** НЕТ СВЯЗИ <�имя_канала> <�имя_объекта>

Причина. Возможно, нет связи с РС-контроллером или удаленным объектом.

Действия оператора. Проверить связь с PC-контроллером на данном объекте. Производить перезагрузку МКТК не следует, если нет ошибок в конфигурации МКТК. Сообщить Администратору МКТК.

г) TSHR 14A *** <�имя_канала> НЕ ГОТОВ Причина. Транспорт не может восстановить работоспособность канала связи. Возможно, нет связи с РС-контроллером.

Действия оператора. Если канал связи долго не восстанавливается или часто выходит в неготовность — сообщить Администратору МКТК.

д) TSHR 80Е *** Ошибка <�операция> RC=<�код_ошибки><�доп_инф_разработчика>

Причина. Информация для разработчика об ошибке выполнения <�операции>. Ошибка устранена программными средствами.

Действия оператора. При устойчивом появлении ошибки сообщить разработчику.

е) TSHR 90S !!! Системная ошибка !!! <�доп_инф_разработчика>

Причина. Информация для разработчика об ошибке выполнения <�операции>. Продолжение функционирования программного обеспечения МКТК невозможно и транспорт завершен.

Действия оператора. Перезапустить МКТК.

ж) TSHR 91S !!! Ошибка конфигурации !!! <�доп_инф_об_ошибке>

Причина. Программа обнаружила ошибку в конфигурации таблиц МКТК. Продолжение функционирования программного обеспечения МКТК невозможно.

Действия оператора. Обратиться к Администратору МКТК для устранения ошибки конфигурирования МКТК. После устранения ошибки перезапустить МКТК.

— Драйвера КСхС:

а) DRKS 91S Ошибка конфигурации: <�доп_инф_об_ошибке>

Причина. Программа обнаружила ошибку в конфигурации МКТК. Продолжение выполнения программы МКТК невозможно.

Действия оператора. Обратиться к Администратору МКТК для устранения ошибки конфигурирования МКТК. После устранения ошибки перезапустить МКТК.

б) DRKS 91S Ошибка: не обнаружен драйвер плат <�тип_платы>

Причина. Не установлен системный драйвер плат указанного типа (КС2С или КС4С).

Действия оператора. Обратиться к Администратору МКТК для установки системного драйвера для плат указанного типа. После этого перегрузить операционную систему и перезапустить МКТК.

в) DRKS 91S Ошибка инициализации платы <�тип> #<�номер>: плата не обнаружена Причина. Драйвер не может обнаружить плату указанного типа с таким номером.

Действия оператора. Обратиться к Администратору МКТК, который должен:

1) Проверить, что плата вставлена в слот ISA ПЭВМ;

2) Проверить, что тип установленной платы соответствует типу платы, прописанной в конфигурации. В случае их несовпадения изменить конфигурацию МКТК;

3) Сравнить номер платы, выставленный с помощью джампера (см. документы УИАВ.469 535.151ПС, УИАВ.469 535.161ПС) с номером, заданным в конфигурации МКТК. В случае их несовпадения переставить джампер или изменить конфигурацию.

После этого загрузить ОС (если требуется) и перезагрузить МКТК. Если ошибка не исчезла, то возможны два варианта:

1) Плата конфликтует с операционной системой или другим устройством. Для устранения конфликта удалить неиспользуемые устройства или изменить номер платы, с помощью джампера и внести изменения в конфигурацию МКТК;

2) Плата неисправна — заменить её. Перегрузить ОС, перезапустить МКТК.

г) DRKS 91SОшибка инициализации платы <�тип> #<�номер>: порты заняты другим устройством Причина. Порты в/в платы уже используются другим устройством.

Действия оператора. Обратиться к Администратору МКТК, который должен:

1) Изменить настройки или удалить устройство, конфликтующее с нашей платой;

2) Изменить номер платы, с помощью джампера и внести изменения в конфигурацию МКТК. Если требуется, перегрузить ОС, перезапустить МКТК.

д) DRKS 91S Ошибка инициализации платы <�тип> #<�номер>: прерывание занято другим устройством Причина. Прерывание платы уже используются другим устройством.

Действия оператора. Обратиться к Администратору МКТК, который должен:

1) изменить настройки или удалить устройство, конфликтующее с нашей платой;

2) изменить прерывание платы (для КС2С с помощью джампера и внести изменения в конфигурацию МКТК. Если требуется, перегрузить ОС, перезапустить МКТК.

е) DRKS 91S Ошибка инициализации платы <�тип> #<�номер>: память занята другим устройством Причина. Память платы уже используются другим устройством.

Действия оператора. Обратиться к Администратору МКТК, который должен:

1) Изменить настройки или удалить устройство, конфликтующее с нашей платой;

2) Изменить номер платы, с помощью джампера и внести изменения в конфигурацию МКТК. Если требуется, перегрузить ОС, перезапустить МКТК.

ж) DRKS 91S Ошибка инициализации платы <�тип> #<�номер>: недопустимый номер прерывания Причина. В конфигурации МКТК задано прерывание, которое не используется в данном типе плат.

Действия оператора. Обратиться к Администратору МКТК для изменения номера прерывания в конфигурации МКТК на допустимый (см. документы УИАВ.469 535.151ПС, УИАВ.469 535.161ПС). Перезагрузить МКТК.

з) DRKS 91S Ошибка инициализации платы <�тип> #<�номер>: прерывание не обнаружено Причина. В конфигурации МКТК прописан номер прерывания, не соответствующий номеру прерывания, который установлен на плате. Если тип платы — КС4С, то плата неисправна или конфликтует с другим устройством.

Действия оператора. Обратиться к Администратору МКТК, который должен:

1) Изменить настройки или удалить устройство, конфликтующее с нашей платой;

2) Привести в соответствие номер прерывания платы прописанный в конфигурации МКТК и номер, заданный на плате джампером (для платы типа КС2С);

3) Если плата неисправна — заменить её.

Если требуется, перегрузить ОС. Перезапустить МКТК.

к) DRKS 91S Ошибка инициализации платы <�тип> #<�номер>: недопустимый синдром Причина. В конфигурации МКТК для данной платы некорректно заданы режимы каналов, т. е. задан 7-битный протокол и 8-битный синдром канала (см. документы УИАВ.469 535.151ПС, УИАВ.469 535.161ПС).

Действия оператора. Обратиться к Администратору МКТК для исправления конфигурации. Перезапустить МКТК.

л) DRXX 90S Системная ошибка <�доп_инф_об_ошибке>

Причина. Информация для разработчика об ошибке в поле <�доп_инф_об_ошибке>. Продолжение функционирования программы МКТК невозможно и драйвер завершён.

Действия оператора. Перезапустить МКТК.

м) DRXX 90S Ошибка функции МКТК <�операция> код=<�код ошибки>

Причина. Информация для разработчика об ошибке выполнения функции МКТК <�операция>. Драйвер завершён. Продолжение функционирования программы МКТК.

Действия оператора. Перезапустить МКТК.

н) DRXX 01А Ошибка данных Причина. В конфигурации МКТК для канала с номером XX задан 7-битный протокол. При этом транспорт пытается передать 8-битные данные через этот канал. Данные не могут быть переданы.

Действия оператора. Обратиться к Администратору МКТК для исправления режима канала в конфигурации. Перезапустить МКТК.

о) DRXX 02А Очередь транспорта <�имя очереди> не доступна Причина. Драйверу не доступна транспортная очередь. Возможно транспорт не запущен или не справляется с обработкой данных.

Действия оператора. При неоднократном появлении данного сообщения сообщить Администратору МКТК для устранения неисправности, перезапустить МКТК.

п) DRXX 03A Не готов Причина. Канал связи XX не готов к передаче данных.

Действия оператора. Если канал связи долго не восстанавливается — сообщить Администратору МКТК для устранения неисправностей в канале.

— Драйвера выделенных каналов:

Все сообщения начинаются с идентификатора драйвера, который имеет вид: DDXX, где XX — номер канала.

а) DDXX 01A Соединение разорвано <�причина>

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

Действия оператора. Если соединение часто рвётся или долго не может установиться, следует обратиться к Администратору МКТК для исправления ситуации.

б) DDXX 02A Невозможно установить соединение. <�Причина>

Причина. Драйвер не может установить соединение. Причиной являются некорректные настройки в конфигурации МКТК.

Действия оператора. Обратиться к Администратору для исправления конфигурации МКТК. Перезапустить МКТК.

в) DDXX 03A Не готов Причина. Драйвер не готов к передаче данных.

Действия оператора. Не требуются.

г) DDXX 04A Ошибка открытия порта: <�причина>

Причина. Драйвер не может получить доступ к последовательному порту.

Действия оператора. Обратиться к Администратору МКТК для устранения причины. Перезапустить МКТК.

д) DDXX 05A Ошибка настройки порта: порт не существует Причина. В конфигурации МКТК указан номер порта, которого физически нет в ПЭВМ.

Действия оператора. Обратиться к Администратору для исправления конфигурации МКТК. Перезапустить МКТК.

е) DDXX 06A Очередь <�идентификатор> не доступна <�причина>

Причина. Драйверу не доступна очередь компонента с указанным идентификатором. Указанный компонент не работает или не справляется с обработкой данных.

Действия оператора. При неоднократном появлении данного сообщения сообщить Администратору МКТК для устранения причин неисправности, затем перезапустить МКТК.

ж) DDXX 91S Ошибка конфигурации: <�доп_инф_об_ошибке>

Причина. Драйвер обнаружил ошибку в параметрах конфигурации. Продолжение функционирования драйвера невозможно.

Действия оператора. Обратиться к Администратору для исправления конфигурации МКТК. Перезапустить МКТК.

з) DDXX 90S Системная ошибка <�доп_инф_об_ошибке>

Причина. Информация для разработчика об ошибке в <�доп_инф_об_ошибке>. Продолжение функционирования программного обеспечения МКТК невозможно и драйвер завершен.

и) DDXX 90S Ошибка функции МКТК <�операция> код=<�код_ошибки>

Причина. Информация для разработчика об ошибке выполнения функции МКТК <�операция>. Продолжение функционирования программного обеспечения МКТК невозможно и драйвер завершён.

Действия оператора. Перезапустить МКТК.

— Драйвера Транспортного Контроллера:

а) DRTK 02A *** Драйвер НЕ ЗАГРУЖЕН Причина. Инициализация драйвера завершена из-за ошибок. Загрузка драйвера прекращается.

Действия оператора. Сообщить Администратору МКТК — возможно ошибка конфигурации МКТК.

б) DRTK 90S !!! Системная ошибка !!! <�операция> RC=<�код_ошибки> <�доп_инф_разработчика>

Причина. Информация для разработчика об ошибке выполнения <�операции>. Продолжение функционирования программного обеспечения МКТК невозможно и драйвер завершен.

Действия оператора. Перезапустить МКТК.

в) DRTK 91S !!! Ошибка конфигурации !!! <�доп_инф_об_ошибке>

Причина. Программа обнаружила ошибку в конфигурации таблиц МКТК. Продолжение функционирования программного обеспечения МКТК невозможно.

Действия оператора. Обратиться к Администратору МКТК для устранения ошибки конфигурирования МКТК.

После устранения ошибки перезапустить МКТК.

Индикация состояния драйвера Транспортного Контроллера:

Серый — драйвер не загружен (сообщение DRTK 02A);

Зеленый — драйвер готов (сообщение DRTK 01I);

Красныйдрайвер не готов к работе при отсутствии Транспортного Контроллера;

Синий — драйвер свою работу завершил по команде оператора, либо из-за возникновения системных ошибок (сообщение DRTK 90S);

— Транспортов TCP/IP

Транспорт осуществляет доставку информации по сети с использованием протокола TCP/IP. В зависимости от сети, в которой работает транспорт, он является локальным или межобъектовым. Локальный транспорт, обеспечивает обмен данными между Агентством и Службой Доставки в локальной сети объекта. Межобъектовый транспорт обеспечивает обмен данными между Службами Доставки объектов.

В сообщениях, выдаваемых оператору, ХХХХ заменяется идентификатором:

TLOW — локального транспорта;

TWAN — межобъектового транспорта.

а) ХХХХ 02A *** Транспорт НЕ ЗАГРУЖЕН Причина. Инициализация транспорта завершена из-за ошибок. Загрузка транспорта прекращается.

Действия оператора. Сообщить Администратору МКТК — возможно ошибка конфигурации МКТК.

б) TWAN 13A *** НЕТ СВЯЗИ по TCP/IP с объектом <�адрес_объекта> узел <�адрес_узла> IP=,, RC=<�код_ошибки>

Причина. Отсутствие связи по сети, ошибка в таблице маршрутизации или ошибка адресации в адресной книге МКТК.

Действия оператора. Проверить связь на данном объекте. Производить перезагрузку МКТК не следует, если нет ошибок в конфигурации МКТК. Сообщить Администратору МКТК.

в) XXXX 90S !!! Системная ошибка !!! <�операция> RC=<�код_ошибки> <�доп_инф_разработчика>

Причина. Информация для разработчика об ошибке выполнения <�операции>. Продолжение функционирования программного обеспечения МКТК невозможно и транспорт завершен.

Действия оператора. Перезапустить МКТК.

г) XXXX 91S !!! Ошибка конфигурации !!! <�доп_инф_об_ошибке>

Причина. Программа обнаружила ошибку в конфигурации таблиц МКТК. Продолжение функционирования программного обеспечения МКТК невозможно.

Действия оператора. Обратиться к Администратору МКТК для устранения ошибки конфигурирования МКТК. После устранения ошибки перезапустить МКТК.

— NULL-транспорта:

а) TNUL 02A *** Транспорт НЕ ЗАГРУЖЕН Причина. Инициализация транспорта завершена из-за ошибок. Загрузка транспорта прекращается.

Действия оператора. Сообщить Администратору МКТК — возможно ошибка конфигурации МКТК.

б) TNUL 90S !!! Системная ошибка !!! <�операция> RC=<�код_ошибки> <�доп_инф_разработчика>

Причина. Информация для разработчика об ошибке выполнения <�операции>. Продолжение функционирования программного обеспечения МКТК невозможно и транспорт завершен.

Действия оператора. Перезапустить МКТК.

в) TNUL 91S !!! Ошибка конфигурации !!! <�доп_инф_об_ошибке>

Причина. Программа обнаружила ошибку в конфигурации таблиц МКТК. Продолжение функционирования программного обеспечения МКТК невозможно.

Действия оператора. Обратиться к Администратору МКТК для устранения ошибки конфигурирования МКТК. После устранения ошибки перезапустить МКТК.

— Программы монитора РС-контроллера (РССМ):

3. Анализ существующих языков программирования

Среди наиболее популярных языков программирования можно выделить следующие:

— С;

— С++;

— Java;

— Delphi;

— Perl;

— PHP;

— C#.

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

— кроссплатформенность;

— стоимость;

— наличие библиотек;

— быстродействие;

— компилируемый / интерпретируемый;

— распространённость;

— специализация;

— поддержка ООП.

Сравнение рассматриваемых в данной курсовой работе языков программирования по вышеуказанным параметрам приведено в таблице 3.1.

Таблица 3.1

Сравнение языков программирования

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

— кроссплатформенность;

— компилируемость;

— быстродействие не обязательно;

— поддержка ООП.

— наличие библиотек;

— стоимость не важна;

— распространённость;

— универсальность.

4. Представление базы знаний по выбору языка программирования

Представление базы знаний по выбору языка программирования представлено на рисунках 4.1a, 4.1б, 4.1 В.

Рисунок 4.1-а — представление базы знаний по выбору языка программирования язык программирование реализация решение Рисунок 4.1-б — представление базы знаний по выбору языка программирования Рисунок 4.1-в — представление базы знаний по выбору языка программирования Рисунок 4.1-г — представление базы знаний по выбору языка программирования

5. Выбор и обоснование механизма вывода решения

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

Первый вопрос, задаваемый пользователю: «Разрабатываемое ПО должно быть кроссплатформенным?» Этот вопрос определяет, будет ли язык программирования являться кроссплатформенным. Кроссплатформенным называется программное обеспечение, работающее более чем на одной аппаратной платформе и/или операционной системе.

Второй вопрос предлагает пользователю выбрать на чём должен специализироваться языка. Варианты ответов:

— универсальный;

— скриптовый;

Третьим вопросом определяется компилируемость/ интерпретируемость языка.

Компилируемый язык программирования — язык программирования, в котором исходный код, написанный пользователем, преобразуется компилятором в машинный код, исполняемый компьютером.

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

Следующий вопрос определяет поддержку ООП Следующий вопрос касается наличия библиотек. Ответ «Да» пользователю следует давать только в том случае, если он чётко представляет, какую именно библиотеку он в дальнейшем подключит для реализации своей программы. Например, одной из наиболее распространенных библиотек мультиплатформенного программирования является объектно-ориентированная библиотека Qt, написанная на языке C++.

Затем задаётся вопрос: «Важна ли скорость выполнения программы?» Ответом на этот вопрос определяется быстродействие языка.

Для окончательного выбора языка программирования для реализации ПО задаются вопросы о распространённости и стоимости языка.

6. Программа формирования основного меню

На следующих рисунках представлены окна программы по выбору языка программирования для реализации ПППР.

7. Программная реализации механизма выработки решения

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

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

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

Для разработки экспертной системы использовалась среда разработки Borland C++ Builder.

Для структурирования баз знаний используется язык веб-онтологии OWL.

8. Руководство пользователя разработанной программой

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