Компьютерные технологии в области автоматизации и управления

Самара

КОМПЬЮТЕРНЫЕ ТЕХНОЛОГИИ В ОБЛАСТИ АВТОМАТИЗАЦИИ И УПРАВЛЕНИЯ

 

Лекция 1. Автоматизация и управление. Компьютерные технологии и автоматизированные и автоматические системы.

Системы автоматизации и управления;

Информационные процессы в системах автоматизации и управления;

Компьютерные технологии. Определение автоматизированной системы;

Компьютерные технологии и управление производством. Три базовых иерархических уровня ПО управления производством и СТС. MES технологии;

Система управления, объект управления, виды управления;

Прямое управление и управление с отрицательной обратной связью;

Возмущения, управление по возмущению.

Лекция 2. Встроенные управляющие компьютеры. SCADA системы и управление в реальном времени. Работа персонала в составе АСУ.

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

Встроенные компьютеры. SCADA системы и управление в реальном времени;

Техническое и программное обеспечение компьютерных технологий;

Работа персонала в составе АСУ.

 

Лекция 3. Математические модели автоматических и автоматизированных систем.

Математические модели для исследования поведения систем автоматизации и управления и их адекватность;

Непрерывные и дискретные во времени математические модели. Математические модели, основанные на дискретных событиях;

Математические модели мехатронных систем;

Линейные системы, нелинейные системы, их линеаризация;

Математическое описание цифровых систем. Решетчатые функции. Импульсный элемент;

Экстраполятор нулевого порядка;

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

Лекция 4. Локальные вычислительные сети управления сложными техническими системами (СТС) и их особенности.

Сложные технические системы;

Схема систем управления с ЦВМ в качестве устройства управления. Системная и периферийные ЦВМ;

Задачи, вызвавшие появление вычислительных сетей;

Преимущества ЦВМ и сетей ЦВМ в качестве управляющих устройств;

Разделяемая среда передачи;

Особенности ЛВС управления СТС;

Определение времени ожидания абонентом освобождения шины, как общего ресурса.

Лекция 5. Структура пакетов ЛВСуСТС.

Контроль целостности сообщений. Циклический избыточный контроль (CRC);

Дуплексная и полудуплексная передача информации в ЛВС;

Топология шина и её характеристики;

Кодирование бит информации сетевых сообщений. Код NRZ;

Проблема синхронизации приемника и передатчика сообщений. Методы обеспечения синхронизации;

Самосинхронизирующиеся коды. Код RZ. Манчестерский код;

Искажение сообщений при передаче по ЛПИ.

Лекция 6. Защищенные ЛВСуСТС.

Защищенная сеть ГОСТ Р-5207-2003 (MILSTD 1553B). Физический уровень сети;

Централизованный метод доступа абонентов в сеть MILSTD1553B;

Защита информации в сети MILSTD1553B;

Сеть CAN-контроллерная местная сеть (Controller Area Network);

Распределенный доступ абонентов в сети CAN. Арбитраж при возникновении столкновений сообщений;

Обеспечение надежности передачи в сети CAN.

 

Лекция 7. Программное обеспечение УСТС. Параллельные физические процессы СТС и многозадачная работа ПО управления СТС.

Декомпозиция и интеграция СТС;

Реализация одновременно протекающих физических процессов через параллельную работу ПО;

Многозадачная работа ПО СТС. Причины многозадачности;

Иерархическое структурирование ПО - средство обеспечения его многофункциональности;

Удобство проведение изменений в иерархической структуре ПО.

Вопросы для самопроверки

Сложные технические системы

Схема систем управления с ЦВМ в качестве устройства управления

Задачи, вызвавшие появление вычислительных сетей.

Преимущества ЦВМ и сетей ЦВМ в качестве управляющего устройства

Схема процесса коммуникации и основные понятия сетевых технологий управления СТС

Разделяемая среда передачи

Классификация компьютерных сетей. Глобальные и локальные сети.

Структура пакетов ЛВС

Контроль целостности - Обнаружение ошибок при передаче данных. Циклический избыточный контроль CRC (Cyclic Redundancy Check).

Стандартизация и структуризация телекоммуникационных процессов. Модель OSI.

Дуплексная и полудуплексная передача информации в ЛВС

Топология вычислительных сетей.

Топология шина и её характеристики

Анализаторы протоколов сети

Кодирование бит информации сетевых сообщений. Непосредственный способ передачи цифровых данных.

Код NRZ и проблема синхронизации приемника и передатчика сообщений. Методы обеспечения синхронизации

Самосинхронизирующиеся коды. Код RZ. Манчестерский код.

Искажение сообщений при передаче по ЛПИ

Защищенная сеть ГОСТ Р-5207-2003 (MILSTD 1553B). Физический уровень сети

Сеть создана для управления бортовой аппаратурой авиационно-космических изделий, имеющих в своем составе встроенные в бортовую аппаратуру (БА) ЦВМ. Стандарт сети утвержден впервые военным ведомством США в 1972 году под именем MILSTD 1553A. Стандарт получил широкое распространение во всем мире, и под этот стандарт произведены сотни тысяч образцов оборудования, соответствующих этому стандарту. Стандарт был утвержден в СССР в виде ГОСТ, а позже и в России. Последняя версия имеет наименование ГОСТ-Р-5207-2003.

Отличительная особенность стандарта – многоуровневые меры по защите предаваемой информации.

Рассматриваемая сеть имеет шинную топологию, к которой подключены абоненты – устройства интерфейса. Подключения абонентов возможны напрямую, а возможны на шлейфах (в отводах от шин) длинной до шести метров, что упрощает компоновку аппаратуры на объектах управления (спутниках, ракетах, самолетах). В последнем случае для согласования волновых сопротивлений шлейфов и линии передачи необходимо применение специальных согласующих устройств, описанных в стандарте. Среда передачи, предусмотренная стандартом – экранированная витая пара. Передача ведется фазоманипулированным кодом Манчестер II на частоте 1 МГц. Код Манчестер II нами рассмотрен ранее, является самосинхронизирующимся. На такой частоте передачи в линии имеют место волновые эффекты. С этим связаны ограничения на длину шлейфов и количество абонентов на линии – 32 (под адрес выделено 5 бит).

 

Централизованный метод доступа абонентов в сеть MILSTD1553B

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

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

Передача команд и данных от контроллера к ОУ квитируется ОУ путем посылки им в ответ на полученную команду или данные «ответного слова» в контроллер. В ответном слове ОУ сообщает не только факт приема сообщения от контроллера, но и состояние абонента (его исправность или неисправность), а также состояние самого ОУ. Абонент формирует признаки своего состояния и засылает их в ОУ по своей внутренней логике, которая согласовывается дополнительно с разработчиком конкретной сети. Эта логика реализуется на прикладном уровне разработчиком ПО.

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

Типы и форматы сообщений сети MILSTD 1553B. Все сообщения, передаваемые в сети, имеют длину 20 бит и разделяются на три типа: командное слово, данные, ответное слово. В каждом двадцатибитном слове сообщений первые три бита – синхросигнал для вхождения в связь, а последний двадцатый бит – бит четности, для контроля целостности информации.

 

 

Командные слова передаются только контроллером. Здесь для ответного слова ОУ:

1. Бит четности

2. Бит «ошибка в сообщении»

3. Бит «признак ответного слова»

4. Бит «запрос на обслуживание»

5. Бит «групповая команда»

6. Бит «абонент занят и не может ответить»

7. Бит «абонент неисправен»

8. Бит «принято управление»

9. Бит «неисправное ОУ»

 

Кратко рассмотрим формат трех типов сообщений. Всего их шесть.

Кроме этих форматов существует формат группового сообщения, формат передачи данных от ОУ к ОУ, но только по команде котроллера и т.п.

Пауза t₁ формируется ОУ после полученного сообщения и должна быть 4-12 мсек. Отсутствие ответного слова через t₁>12 мсек воспринимается контроллером как неполучение ОУ направленного ему сообщения. Пауза t₂ формируется контроллером и должна быть не менее 4 мсек.

Максимально число слов данных в сообщении равно 32.

Максимальное число ОУ на линии – 31 + с учетом адреса контроллера общее число адресов устройств интерфейса в сети = 32. Под Адрес выделено 5 бит информации (2⁵=32).

Среди команд управления, число которых в стандарте задано 15 (остальные - резервные), имеется команда «переназначения котроллера» и команды к ОУ «дай ответное слово».

Если ОУ хочет по собственной инициативе начать передачу, то он этого сделать не может, но у него есть единственная возможность быть услышанным и в конце концов передать имеющееся у него сообщение. Для этого ОУ в ответном слове на команду «дай ответное слово» в 11 позиции должен установить в 1 – бит флага «запрос на обслуживание».

Получив в ответном слове эту информацию, контроллер по собственной логике, заложенной в его ПО может запросить информацию с ОУ командой запроса данных (формат 2). Таким образом, ОУ могут проявлять контролируемую инициативу по передаче данных в линию. Забота о периодическом опросе флагов ОУ «запрос на обслуживание» Лежит на контроллере, точнее на его ПО прикладного уровня, реализующем логику управления сетью.

 

Защита информации в сети MILSTD1553B

Разряд контроля четности во всех типах сообщений формируется таким образом, чтобы сумма всех 17 разрядов, несущих информацию, включая разряд контроля четности, была нечетной. Такой простой способ связан с тем, что он охватывает каждые 20 бит - очень короткие сообщения. На таких коротких сообщениях и на 1 МГц вероятность двойных и тройных сбоев очень мала. ОУ, контроллер и сама линия передачи информации дублированы – имеется канал А и канал В.

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

Имеется защита от органического недостатка шинной топологии возможности атаки на доступность путем генерации в линию непрерывных сигналов одним из абонентов следствии отказа путем или по злому умыслу. Для этого в контроллере предусмотрена специальная команда блокировки генерящего. Если генерящий ОУ в канале А, то эта команда выдается по В, если генерящий в В, то команда выдается по А. Это стало возможным потому, что дублирование производится не пользователем, а является неотъемлемым свойством сети.

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

Таким образом, в стандарте MILSTD1553B реализованы беспрецедентные меры по защите передаваемой в сети информации.

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

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

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

С точки зрения ИБ также имеются особенности работы MILSTD1553B., по­скольку она внутрисистемная. Здесь существует опасность уже рассмотренных внутренних угроз.

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

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

Вопросы для самопроверки

Физический уровень сети MILSTD 1553B

Централизованный метод доступа абонентов в сеть MILSTD1553B

Типы и форматы сообщений сети MILSTD 1553B

Защита информации в сети MILSTD1553B

Сеть CAN-контроллерная местная сеть (Controller Area Network).

Физический уровень сети CAN

Формат кадров сети CAN

Распределенный доступ абонентов в сети CAN. Арбитраж при возникновении столкновений сообщений

Обеспечение надежности передачи в сети CAN

Адресация сообщений в CAN

 

Лекция 7. Программное обеспечение УСТС. Параллельные физические процессы СТС и многозадачная работа ПО управления СТС.

Декомпозиция и интеграция СТС

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

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

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

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

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

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

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

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

Путь декомпозиции СТС и последующей её интеграции «проходит» через программное обеспечение встроенных в СТС вычислительных средств. Это происходит не столько потому, что выделенным из СТС подсистемам соответствуют выделенные части структуры ПО, управляющие ими, но прежде всего потому что взаимодействие между подсистемами осуществляются на программном уровне путем реализации связей по управлению и данным между соответствующими частями ПО.

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

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

В сложных системах одновременно протекают несколько физических процессов управления. Физический процесс управления - упорядоченная последовательность действий в системе над информацией, энергией или материей, приводящая к требуемому результату. Физические процессы состоят из задач. Задачами будем называть функциональные единицы деятельности, которые разбивают физические процессы системы как во времени, так и по физическим компонентам. Обычно в СТС одновременно активны и исполняются несколько задач и это можно использовать, чтобы описать параллелизм физических процессов в системе, реализующий сложное её поведение

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

Реализация одновременно протекающих физических процессов через параллельную работу ПО

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

 

Система Цели Задачи и связи

.

ДЕКОМПОЗИЦИЯ СИСТЕМЫ   …

 

ПРОЕКТИРОВАНИЕ ПРОГРАММНОГО КОМПЛЕКСА Структурная диаграмма Временная диаграмма для вариантов использования Диаграммы состояний для вариантов использования Схема информационных и управляющих связей ПО Структурные части ПО для управления взаимосвязанной работой подсистем

КОНСТРУИРОВАНИЕ СТРУКТУРНЫХ ЧАСТЕЙ ПО Процессы и потоки Синхронизация Защитное конструирование Получение и отладка кода

ИНТЕГРАЦИЯ СИСТЕМЫ Сборка системы Испытания подсистем совместно с ПО Испытание системы совместно с ПО

КОМПЛЕКСНАЯ ОТЛАДКА ПО Модель внешней среды (объекта управления и системы управления)

Подсистема n Цели Задачи и связи

Подсистема 1 Цели Задачи и связи

 

Рис. 7.1 - Путь декомпозиции и интеграции сложной системы проходит через ПО

 

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

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

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

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

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

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

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

 

Многозадачная работа ПО СТС. Причины многозадачности

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

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

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

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

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

Многозадачность поддерживается операционными системами (ОС). Реализация многозадачности может быть различной в различных ОС. Однако, в настоящее время сформировался некоторый единообразный подход, связанный с определением «процессов и потоков». В деталях эти понятия могут для различных ОС несколько различаться, но принципиально для авторитетных ОС эти понятия одинаковы благодаря стандарту POSIX (Portable Operation Systems Interface). Это развивающийся стандарт, призванный обеспечить переносимость исходных текстов прикладных программ между различными ОС. Термины, используемые в ОС UNIX, QNX и других юниксоподобных ОС, а также системные вызовы этих ОС соответствуют стандарту. Множество других ОС следуют стандарту POSIX, хотя и делают это не в полной мере, ссылаясь на сложившуюся практику. При рассмотрении стандарта иногда возникает впечатление, что некоторые формулировки имели цель: не вывести из категории удовлетворяющих стандарту какие-то прикладные программы или операционные системы. Однако, главная цель POSIX - это все-таки обеспечение мобильности прикладных программ.

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

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

Иерархическое структурирование ПО - средство обеспечения его многофункциональности

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

Рассмотрим простой пример - СТС, например, компьютеризированную стиральную машину, работа которой всем понятна (рис. 7.2). Управление работой этой системы осуществляется от встроенной ЦВМ. Стиральная машина многорежимна и обладает всеми признаками сложного поведения и по нашей классификации является СТС. Проектирование системы и ПО надо начинать с разработки её структуры. Этот процесс имеет также названия структурирование, декомпозиция. При декомпозиции сложной системы на ряд подсистем естественным образом происходит и декомпозиция (структуризация) ПО. Получаемые части ПО имеют названия – синонимы: программы, структурные единицы ПО, модули, компоненты ПО, подсистемы.

Рис. 7.2 - Иерархическая структурная схема ПО управления стиральной машиной и метод её получения

 

Проведем черту, ниже которой последовательно запишем наименования оборудования, которое должно управляться от ЦВМ (рис. 7.2). Сразу над чертой запишем задачи по управлению каждой единицей (подсистемой) оборудования. Каждой из этих задач в ЦВМ соответствует программа ПО, выполняющая только данную элементарную задачу. Например, программа, которая умеет включать и выключать двигатель на заданную угловую скорость вращения или программа, умеющая открывать и закрывать клапан холодной воды, конечно, когда ее об этом «попросят» – передадут на нее управление. Кто же это сделает? Это должна сделать специальная программа, обеспечивающая последовательное в нужном для проведении стирки порядке включение аппаратуры стиральной машины.

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

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

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

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

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

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

Удобство проведение изменений в иерархической структуре ПО

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

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

В данных структурных схемах ПКФ тот самый элемент ПО, который должен аккумулировать в себе все функциональные изменения при развитии системы и ПО путем создания новых «вариантов использования» системы. Изменением ПКФ можно вводить новые варианты функционирования системы, не затрагивая управление в подсистемах

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

 

Вопросы для самопроверки

Функциональные и нефункциональные требования к ПО компьютерных технологий управления СТС.

Качество ПО и технология его производства. Влияние человеческого фактора.

Стандартизация характеристик качества ПО. Управление качеством ПО