Itogi_Shpory

18. Полевые системы

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

Для связи с удаленными цифровыми устройствами промышленного назначения принято использовать бит-последовательные промышленные или полевые шины (bit serial Fieldbus). Нельзя было использовать Ethernet, т.к. они не надежны в промышленном производстве. К этой группе относятся несколько европейских

(PROFIBUS, Bitbus, CAN и тд) и американских (Foundation, HART) конкурирующих стандартов. Ведется разработка общеевропейского стандарта, объединяющего

PROFIBUS и FIP.

Основные возможности – PROFIBUS

Открытый стандарт

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

Существует три основных варианта PROFIBUS: FMS, DP и ISP.

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

Модель PROFIBUS позволяет определить коммуникационные связи, объединяющие распределенные прикладные процессы в один общий. Все объекты реального устройства, с которыми можно взаимодействовать (переменные, программы, диапазоны данных), называются объектами коммуникации. Отображение функций VFD на реальное устройство обеспечивается в коммуникационной модели PROFIBUS интерфейсом прикладного уровня. OD( локальный словарь объектов, загружается в устройство либо производителем, либо разработчиком) содержит структуру и типы всех объектов, а также их внутренние адреса в устройстве и представление на шине (индекс/имя). Доступ к объектам при функционировании происходит через сервисные функции протокола PROFIBUS-FMS, которые позволяют, например, опросить/установить значения переменных и массивов, запустить/остановить программу.

PROFIBUS-DP – это оптимизированная по производительности версия PROFIBUS, предназначенная специально для взаимодействий, критичных по времени.

PROFIBUS-ISP – проект взаимодействующих частей, базируется на технологии PROFIBUS и дополняет ее возможностями управления процессами, включая внутреннюю защиту.

19.Программное обеспечение промышленных систем

Всфере промышленной автоматизации свой мир операционных систем – ОС реального времени (ОС РВ). Для VME-процессоров, например, существует 17 ОС (PDOS, LynxOS, VMEexec,QNX и т. д.). Крупные компании-производители обеспечивают для своих процессоров и устройств ввода/вывода полную поддержку сразу нескольких ОС РВ.

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

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

Всфере промышленной автоматизации распространены ОС общего назначения: Unix в разных реализациях, NT, OS/2, VMS. Причины:

1.В Unix стали включать ядра реального времени. Это поддержано открытыми

стандартами, в POSIX,	например,	стандартизованы диспетчеризация и
синхронизация процессов,	нити, тайм-ауты, управление прерываниями.

2.Распространение ПК и рабочих станций.

3.Наличие на платформах общего назначения широкого разнообразия

инструментальных средств.

Все ОС РВ имеют собственные среды разработки (FasTrack, Microtec, MasterWorks), их возможности в определенных аспектах превосходят аналогичные общецелевые средства, которые, например, не могут помочь разработчику систем РВ в конце отладки, когда нужно измерить время выполнения программ и время реакции системы=>Надо выбрать подход, при котором ОС используются в качестве среды для разработки ПО целевого приложения РВ, а в качестве среды исполнения применяется та или иная ОС РВ.

Если создать ПО системы автоматизации, опираясь на общецелевые средства, то цена такой разработки будет высокой.

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

В системах автоматизации для непосредственного управления оборудованием применяются простые и дешевые устройства – программируемые логические контроллеры (ПЛК). Сначала ПЛК были релейными схемами, сейчас устройства типа Smart I/O имеют конфигурацию, в которой центральный процессор на базе дешевого микропроцессора MC68302, последовательные порты и DC/DC-преобразователь собраны в одном компактном промышленном кожухе. Здесь можно гибко изменять конфигурацию, сокращать и наращивать число каналов ввода/вывода за счет широкой номенклатуры производимых модулей.

На уровне ПО мониторинга и управления (SCADA) существенное место занимает интерфейс человек-компьютер (MMI). Процесс разработки приложений SCADA обычно делится на две части.

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

создание пользовательского интерфейса.

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

Пакет InTouch (Wonderware, США) лучшее инструментальное средство для разработки SCADA-систем. InTouch реализован для среды Windows NT: управление окнами, работа со шрифтами, механизм межзадачного интерфейса (DDE) – все это базируется на штатных средствах API Windows, что создает привычную для пользователей ПК обстановку.

Основная задача InTouch – разработка графического интерфейса к переменным (текстовым, дискретным, действительным и целым). Переменные определяет разработчик, и они могут быть двух категорий: DDE (для связи с внешними объектами) либо Memory (внутренние).

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

Т.к. InTouch – инструментальная система, все вводимые разработчиком переменные заносятся в БД, которая в целевой системе начинает работать как БД РВ. Установив связи через DDE-интерфейс между переменной InTouch и переменной любого программного пакета, можно сохранять и обрабатывать данные InTouch в стандартной БД или электронной таблице.

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

20. Управление производством

Верхний уровень в комплексе FactorySuite занимает пакет InTrack – инструментарий для разработки систем управления производством. Продолжая линию, заложенную в пакете InTouch, он поддерживает объектно-ориентированный стиль разработки и имеет архитектуру клиент/сервер. Назначение InTrack – создание интерактивных приложений, способных контролировать и управлять всеми стадиями производственных процессов – от загрузки сырья до выпуска готовой продукции.

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

Всоставе InTouch поставляется постоянно

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

Т.к. InTouch – инструментальная система, все вводимые разработчиком переменные заносятся в БД, которая в целевой системе начинает работать как БД РВ. Установив связи через DDE-интерфейс между переменной InTouch и переменной любого программного пакета, можно сохранять и обрабатывать данные InTouch в стандартной БД или электронной таблице.

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

21.UML проектирование систем реального времени

Развитие микропроцессоров, рост их производительности и снижение цен сделали прибыльными распределенные системы и СРВ на базе микрокомпьютеров.

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

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

22. Объектно-ориентированные методы и UML

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

Язык UML - нотация для описания объектно-ориентированных моделей, которая стала промышленным стандартом. Для эффективного применения нотации UML необходимо сочетать ее с каким-либо методом объектно-ориентированного анализа и проектирования.

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

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

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

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

Результаты динамического моделирования:

Разрабатываются диаграммы кооперации и последовательности, отражающие кооперацию объектов в каждом прецеденте.

Зависящие от состояния аспекты системы описываются с помощью диаграмм состояний, причем для каждого объекта составляется своя диаграмма.

Ваналитической модели основное внимание уделяется пониманию проблемы: выявлению объектов предметной области и передаваемой между ними информации. Объекты и классы предметной области группируются на основе критериев выделения объектов. Рассмотрение вопросов, активен объект или пассивен, синхронно или асинхронно посылаемое сообщение и какая вызывается операция у объектаполучателя, откладывается до стадии проектирования.

На этапе проектирования среди объектов выявляются активные (их называют задачами) и пассивные (их называют объектами). Для определения задач применяются критерии разбиения на задачи. Разрабатываются также интерфейсы задач и описываются операции каждого пассивного класса.

23. Метод и нотация Нотация проектирования ПО предназначена для описания самого проекта.

Метод проектирования ПО представляет собой систематическое описание этапов создания проекта.

Нотация проектирования ПО описывает проект программы в графическом или текстовом виде. Например, диаграмма классов – это графическая нотация, а псевдокод

– текстовая.

Концепция проектирования ПО – это фундаментальная идея, применимая к проектированию всей системы, например сокрытие информации.

Стратегия проектирования ПО – общий план и методика выполнения проекта. Одной из стратегий является объектно-ориентированная декомпозиция.

Критерии структурирования ПО – это формальные правила, следуя которым разбивают систему на отдельные компоненты. Критерии разбиения - это правила декомпозиции системы.

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

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

24. Системы и приложения реального времени Системы реального времени – это параллельные системы с временными

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

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

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

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

Программные системы реального времени имеют дополнительные характеристики: 1. Встраиваемые системы. Система реального времени часто является частью

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

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

2. Взаимодействие с внешней средой. Обычно, СРВ осуществляет такое взаимодействие без участия человека. (при помощи датчиков)(см. рис.).

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

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

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

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

25. Обзор нотации UML. Диаграммы UML. Диаграммы прецедентов. Нотация UML для классов и объектов.

Унифицированный язык моделирования (UML) предлагает стандартизованную нотацию для описания объектно-ориентированных моделей. В нотации UML

поддерживаются девять видов диаграмм:

1.диаграммы прецедентов;

2.диаграммы классов;

3.диаграммы объектов, являющиеся вариантом диаграмм классов в применении к экземплярам. В методе COMET вместо них работают консолидированные диаграммы кооперации (В COMET сочетаются прецеденты использования, статическое моделирование, диаграммы состояний и диаграммы последовательности событий);

4.диаграммы кооперации;

5.диаграммы последовательности;

6.диаграммы состояний;

7.диаграммы деятельности (в COMET не используются);

8.диаграммы компонентов (в COMET не используются).

9.диаграммы развертывания.

Диаграммы прецедентов

Актер (actor) инициирует прецедент (это любая сущность, взаимодействующая с системой извне). Прецедент (use case) описывает последовательность взаимодействий между актером и системой. Актер изображается на диаграмме прецедентов в виде фигуры человечка, система – в виде прямоугольника, прецедент – в виде эллипса внутри этого прямоугольника. Между прецедентами могут быть отношения include (включает) и extend (расширяет).

Нотация UML для классов и объектов

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

средней – атрибуты, а в нижней – операции. Для того чтобы отличить класс (тип) от объекта (экземпляра типа), имя объекта подчеркивается.

26. Диаграммы классов

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

–ассоциации. Ассоциация между двумя классами изображается в виде линии, соединяющей прямоугольники классов. У нее есть имя и, возможно, стрелка, поясняющая, в каком направлении следует это имя читать. На каждом конце ассоциации проставляется кратность – число, свидетельствующее, сколько экземпляров одного класса связано с одним экземпляром другого класса: ровно один (1), присутствие экземпляра класса необязательно (0..1), нуль или более (*), один или более (1..*) и точное задание числа экземпляров классов (m..n), где m и n - числа;

–иерархии агрегирования и композиции. Это отношения вида целое/часть. Отношение композиции (изображается закрашенным ромбом) накладывает более сильные ограничения на экземпляры классов, чем отношение агрегирования (показывается не закрашенным ромбом);

–иерархия обобщения/специализации. Это отношение вида «является». Обобщение изображается в виде стрелки, ведущей от подкласса (потомка) к суперклассу (родителю), причем стрелка упирается в прямоугольник суперкласса.

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