- •Введение
- •Общие принципы проектирования информационных систем (ис)
- •Системный подход к проектированию. Описание объекта управления. Общие принципы построения и структура систем управления технологическими процессами.
- •Автоматные таблицы. Назначение. Правила составления. Примеры применения.
- •Графы переходов. Назначение. Правила составления. Примеры применения.
- •Автоматы Мура, Мили.
- •Схемы алгоритмов. Назначения. Правила составления. Примеры применения.
- •Распределение алгоритма процесса управления на подсистемы.
- •Декомпозиция алгоритма подсистемы на частные алгоритмы
- •Технология проектирования ис Основные понятия и определения
- •Жизненный цикл (жц) ис
- •Системный анализ
- •Системный синтез
- •Внедрение проекта
- •Эксплуатация и сопровождение проекта
- •Состав стадий и этапов канонического проектирования ис
- •Состав и содержание работ на предпроектной стадии
- •Состав и содержание работ на стадии технорабочего проектирования
- •Состав и содержание работ на стадии внедрения, эксплуатации и сопровождения проекта
- •Методы неканонического проектирования ис Проектирование как трехступенчатый процесс
- •Выбор стратегий и методов проектирования.
- •Описание некоторых неканонических методов проектирования.
- •I. Методы дивергенции.
- •II. Методы трансформации.
- •III. Методы конвергенции.
- •Особенности проектирования некоторых подсистем информационной системы Проектирование системы питания ис
- •Проектирование системы связи в управляющих системах
- •Проектирование информационной базы при различных способах реализации
- •Проектирование экранных форм электронных документов
- •Специфика управления проектированием ис
- •Типы схем организации проектирования
- •Построение структуры су процессами и производством. Назначение, цели и функции асу тп
- •Структура управляющей системы и ее вычислительных средств
- •Основные типы структур асу
- •Оценка деления системы на части
- •Иерархический принцип построения систем управления производством.
- •Системы диспетчерского управления (Scada-системы)
- •Функциональная структура Scada
- •Особенности Scada как асутп
- •Основные требования к Scada-системе
- •Область применения
- •Оперативное управление в реальном времени Определение и виды систем реального времени (срв)
- •Комплекс технических средств (ктс) срв
- •Устройства связи с оперативным персоналом (усоп)
- •Датчики
- •Исполнительные устройства (механизмы)
- •Специфика и свойства операционных систем реального времени (осрв)
- •Параметры осрв
- •Краткий обзор и классификация осрв
- •Требования к языкам рв
- •Структура программ срв
- •Последовательное программирование и программирование задач рв
- •Задачи, процессы, потоки в рв
- •Основные свойства задач
- •Планирование задач в срв
- •Циклический (круговой) алгоритм
- •Разделение времени
- •Кооперативная многозадачность
- •Приоритетная многозадачность с вытеснением
- •Синхронизация задач в осрв
- •Связанные задачи
- •Общие ресурсы
- •Синхронизация с внешними и внутренними внештатными событиями
- •Синхронизация по времени
- •Применение сетей Петри для проектирования в рв.
- •Заключение
- •Список рекомендуемой литературы.
Требования к языкам рв
Программирование в РВ требует специальных средств, которые не в полном объеме встречаются в обычных языках. Язык для программирования в РВ в совокупности с ОСРВ должен предоставлять следующие возможности:
Описание параллельных процессов;
Переключение процессов на основе динамических приоритетов;
Синхронизация процессов;
Обмен данными между процессами;
Функции, связанные с часами и таймерами, абсолютное и относительное время ожидания;
Прямой доступ к внешним аппаратным портам;
Обработка прерываний;
Обработка исключений.
Некоторые компании разрабатывали специальные языки для поддержки своих собственных аппаратных средств. Они не претендуют на универсальность и ориентированы на конкретные компьютеры и их интерфейсы. Обычно подобные языки базируются на существующих (FORTRAN, BASIC) с расширениями, включающими функции РВ, о чем свидетельствует их название типа «Process Basic» или «Real-Time Fortran». Некоторые языки не поддерживают программирование в РВ в строгом смысле, но они легко расширяются (С++).
В 70-е годы выдвигалась концепция единого переносимого многоцелевого языка программирования в РВ, а именно языка ADA. Его главная идея состоит в том, что среда программирования должна быть полностью отделена от аппаратных средств. Программист не должен сталкиваться с деталями аппаратного уровня, а работать только в терминах абстрактных структур и типов данных. Опыт показал (не реалистичность) низкую эффективность этого подхода. Поскольку универсальные сильно типизированные языки существенно ограничивают гибкость. А быстрое развитие технических средств диктует новые требования, которые не могут быть предусмотрены в типизированном универсальном языке.
Вывод: Не существует наилучшего языка программирования в РВ, поскольку для каждого приложения и программно-аппаратной платформы необходимо подбирать свои средства (инструменты), учитывая квалификацию и предпочтения разработчиков.
Структура программ срв
Разработка специального ПО РВ начинается с анализа и описания задач СРВ. Функции СРВ декомпозируются на достаточно простые части, с каждой из которых связывается программный модуль.
Принципиальной особенностью программ РВ является постоянная готовность и отсутствие условий нормального, а не аварийного завершения. Если программа не исполняется, она остается в режиме ожидания прерывания (событие) или истечение некоторого интервала времени. По сути, программы РВ – последовательный код, исполняемый в бесконечном цикле.
В каком-то месте программы есть оператор, приостанавливающий ее исполнение до наступления внешнего события или истечения интервала времени.
При разработке каждого программного модуля должны быть четко выделены области (участки) кода, в котором происходит обращение к защищенным ресурсам, т.е. критической секции. Вход и выход из этих областей координируется каким-либо методом синхронизации или межпрограммных коммуникаций, например, семафор.
В общем случае, если процесс находится в критической секции, можно считать, что данные, с которыми он работает, не изменяя каким-либо другим процессам. Кроме того прерывание исполнения процесса не должно оказать влияние на защищенные ресурсы. Эти требования снижают риск системных ошибок для гарантии живучести программы РВ нештатной ситуации, которая может блокировать или аварийно завершать процесс, должна своевременно распознаваться и исправляться, причем лучше всего в рамках самой программы.
Эффективность исполнения является наиболее важным параметром СРВ. Процессы должны выполняться быстро и часто приходится искать компромисс между ясностью и структурностью программы и ее быстродействием. Опыт создания СРВ показывает, что если для достижения цели нужно чем-то пожертвовать, то это обычно делается, но если структурность программы должна быть принесена в жертву ее эффективности, то совершенно необходимо тщательно документировать все принятые решения, связанные с разработкой приложения. Такой подход обеспечивает возможность дальнейшего сопровождения программы.
