Разработка программного обеспечения МПС.

Последовательность разработки программного обеспечения приведена на рисунке 74.

Рис.74

На рисунке хорошо видно место отладки ПО в общей последовательности разработки ПО. Прежде всего разрабатывается структурный алгоритм, под которым понимается такая степень детализации функционального алгоритма, которая обеспечивает реализацию последнего, на конкретной структуре МПС. Примерное соотношение объема структурного и функционального алгоритма 1:3 и 1:5. Для каждого ВУ разрабатывается протокол обмена, который должен содержать типовые компоненты процесса обмена, представленные на рисунке 75.

Рис.75

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

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

При выборе языка необходимо учитывать следующее. Потери по быстродействию языков высокого уровня относительно Ассемблера составляют: Фортран - 28%, Паскаль - 7...12%, ПЛ/М - 17%, ЛИСП и Форт – 12…15%, Бейсик – 20…30%, а по объему памяти - в 1,15…3 раза. Однако длина программы на компиляторе в 2...10 раз меньше, чем на Ассемблере. Следует учесть, что производительность программиста постоянна и составляет ориентировочно 5…20 отлаженных строк в день.

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

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

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

Отладка МПС.

В настоящее время ведущее место при построении встроенных систем автоматического управления и систем программно-логического управления занимают микроконтроллеры. При этом важнейшая проблема заключается в необходи­мости обеспечения высокой надежности систем на их основе, сократив при этом стоимость контроля и диагностики, затраты на которые достигают 40…60% их общей стоимости. Кроме этого постоянное снижение цен на аппаратные компоненты при­водит к возрастанию доли зарплаты разработчиков. Поэтому их труд по разработке и отладке МПС необходимо оптимизировать.

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

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

1. Неправильно определены функции системы и, следовательно, неминуемы ошибки в ее базовой концепции.

2. Построение математической модели управления объектом выполнено некорректно.

3. Плохо продумана последовательность действий в алгоритме (возможны недопустимые действия; поставлена недостижимая цель; пропущены необходимые операции и др.).

4. Неудачно выбран МП или допущены ошибки структуры МПС,

и т.д.

При обнаружении ошибки в процессе отладки МПС ее доработка и отладка повторяются, то есть процесс отладки - итератив­ный. Одна итерация называется циклом проекти­рования. Часто цикл проектированияопределяют по-другому.

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

2. Это время между обнаружением двух ошибок.

Контроль корректности разработки и отладка должны пронизывать весь процесс разработки и изготовления МПС. Для этого существует три группы методов: тестирование, моделирование и верификация.

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

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

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

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

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

2. Реализация процедур анализа реакции системы на тестовую последовательность.

3. Построение полного информационного массива о неисправ­ностях МПС.

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

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

Рис.76

Типичная структура автоматизированного устройства контроля и технической диагностики приведена на рис.77.

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

Рис.77