- •Семестр 9 р1. Принципы построения пользовательского интерфейса в приложениях систем управления р1: Лекция №1. Обобщенная архитектура прикладной составляющей программного обеспечения систем управления
- •Жизненный цикл изделия и программные средства его поддержки
- •Обобщенная архитектура систем управления электроавтоматикой
- •Характеристики современного процесса разработки прикладной составляющей электроавтоматики
- •Вопросы:
- •Р1: Лекция №2. Базовые элементы платформы приложений су для построения интерфейса пользователя
- •Компоненты каркаса
- •Компоненты конфигурирования
- •Компоненты средств интерфейса пользователя
- •Конфигурирование компонентов в составе системы
- •Вопросы
- •Р1: Лекция №3. Принципы классификации прикладных компонентов систем управления
- •Виртуальная структура прикладной области
- •Матрица компонентов
- •Анализ и систематизация набора прикладных компонентов с применением матрицы
- •Определение минимально необходимого набора прикладных компонентов системы
- •Вопросы
- •Семестр 9 р2. Технологии .Net в разработке приложений систем управления р2: Лекция №4. Основные понятия платформы .Net
- •Строительные блоки .Net (clr, cts, cls)
- •Преимущества с#
- •Промежуточный язык msil
- •Работа с пространствами имен
- •Память в приложениях .Net
- •Проверка наличия утечек
- •Получение дополнительной информации о пространстве имен и типах сборки
- •Вопросы
- •Р2: Лекция №5. Принципы взаимодействия .Net с разработанным кодом
- •Преобразование исходных кодов в новый формат языков .Net
- •Использование двоичных компонентов для организации взаимодействия с компонентами .Net
- •Вопросы
- •Р2: Лекция №6. Инструментарий процесса разработки
- •P2: Лекция №6. Инструменты отладки приложений в .Net Framework 2.0 и выше Утилиты
- •Загрузка расширения отладки sos
- •Примеры:
- •Базовые различия
- •Сборка мусора в .Net Framework
- •Причины смешивания управляемого и неуправляемого кодов
- •Концепция CoDeSys
- •Окно приложения Сodesys:
- •P3. Лекция № 9. Возможности CoDeSys как открытой системы
- •Архитектура приложений современных систем управления
- •Выявление открытых интерфейсов среды
- •Встраивание сцены трёхмерного моделирования объекта управления
- •P3. Лекция № 10. Взаимодействие с аппаратными средствами платформы CoDeSys
- •Основные характеристики и назначение
- •Построения средств диагностики и управления устройствами электроавтоматики на базе opc технологии
- •Особенности механизмов работы opc серверов
- •Реализация интерфейсов opc в сервере
- •Реализация opc компонентов диагностики для контроллеров CoDeSys sp
- •Вопросы
- •Семестр 9 р4. Тестирование приложений систем управления через интерфейс оператора p4. Лекция № 11. Базовые понятия процесса тестирования
- •Жизненный цикл разработки программного обеспечения
- •Модели жизненного цикла
- •Каскадный жизненный цикл
- •Спиральный жизненный цикл
- •Экстремальное программирование
- •Тестирование, верификация и валидация - различия в понятиях
- •Задачи и цели процесса верификации
- •P4. Лекция № 12. Использование пакетов автоматизации тестирования
- •Методы проведения тестирования пользовательского интерфейса, повторяемость тестирования пользовательского интерфейса
- •1) Ручное тестирование
- •2) Сценарии на формальных языках
- •Тестирование удобства использования пользовательских интерфейсов.
- •Принцип использования коммерческих приложений для тестирования пользовательского интерфейса
- •Обзор Quickt Test. Основные понятия
- •Использование Actions, Iterations
- •Использование объекта DataTable и параметризация
- •Распознавание объектов в qtp и уникальность их свойств
- •P4. Лекция № 13 Модульное тестирование
- •Цели и задачи и модульного тестирования
- •Понятие модуля и его границ. Тестирование классов
- •Подходы к проектированию тестового окружения
- •P4. Лекция № 14. Возможности uiAutomation
- •Начальное представление
- •Представление элемента управления
- •Представление содержимого
- •Шаблоны элементов управления uia
Виртуальная структура прикладной области
Программное обеспечение прикладной области электроавтоматики в своем вертикальном сечении имеет многоуровневую структуру и полностью соответствует виртуальной машине.
Рис. 11 Трехуровневая архитектура Windows DNA и уровни прикладной области электроавтоматики
На Рис. 11 проведена аналогия между виртуальной структурой и архитектурой концепции Microsoft Windows DNA (Distributed interNet Applications), которая вводит промежуточные слои бизнес-логики для отделения компонентов представления в интерфейсе пользователя от компонентов специализированных на работе с данными.
В многоуровневой структуре прикладной области необходимо ввести дополнительный подуровень - взаимодействия с аппаратурой. Который будет реализовывать доступ к конкретным аппаратным средствам электроавтоматики.
Уровень взаимодействия с аппаратурой маскирует особенности работы аппаратных решений. На этом уровне инкапсулируют доступ к PLC-устройствам, реализуют работу с протоколами промышленных сетей (Profibus, CANbus, ProfiNet, DeviceNet и другие), встраивают OPC-серверы для интеграции в SCADA-системы.
Уровень хранения и доступа к данным определяет внутреннее представление информации, работу с базой данных, с файловой системой, с сетевыми протоколами обмена данных и т.д. Здесь реализуют менеджеры для предоставления данных, их хранения во внутреннем формате, а также для записи и чтения данных в различных файловых форматах.
Уровень управления данными реализует функциональность двунаправленного управления потоками данных. На этом уровне располагают трансляторы, компиляторы, генераторы кодов для различных процессоров, механизмы конвертирования и фильтрации баз данных. Уровень, отвечающий за преобразование данных, полностью соответствует функциональности уровня бизнес-логики Windows DNA-архитектуры.
Уровень визуального представления реализует компоненты пользовательского интерфейса по типу виртуальных приборов. На этом уровне располагают редакторы управляющих программ, инструменты моделирования объекта управления, инструменты для построения графиков диагностики и отслеживания состояния процесса, панели управляющих элементов, а также реализуют диалог взаимодействия с оператором.
Многоуровневая структура прикладной области предполагает применение общего подхода при разработке прикладных компонентов электроавтоматики. В этом подходе компоненты специализируются на реализации пользовательского интерфейса и на работе с данными. При этом нет зависимости между компонентами представления и компонентами работы с данными.
Подуровень взаимодействия с аппаратурой позволяет разделять компоненты, работающие с данными приложений и данными PLC устройств. Это обусловлено различиями в способах организации работы с данными.
Матрица компонентов
Для анализа состава компонентов прикладной части электроавтоматики предлагается оригинальный исследовательский аппарат - матрица компонентов. Матрицу компонентов построим в виде пересечения пользовательских задач по горизонтали с логическими уровнями виртуальной структуры по вертикали (см. Рис. 12). Таким образом, столбцы полученной матрицы определяют многообразие пользовательских задач системы управления электроавтоматикой, а строки - способ компонентой реализации (организации) программного обеспечения.
Почему классификация имеет представление в виде матрицы? Системы управления имеют большое число компонентов. Например, 5-ая версия 2000-ого года Windows Control Center от Siemens (сокращенно WinCC) содержит более 30 основных компонентов и множество опций и дополнений, ряд которых может расширяться.
Матрица формирует общее представление о наборе компонентов прикладных приложений для систем управления.
На Рис. 12 показано абстрактное представление матрицы прикладных компонентов электроавтоматики. Здесь можно представить, в каких ячейках следует искать традиционные модули электроавтоматики, такие как редакторы языков управляющих программ в стандарте МЭК 61131-3, OPC-сервер, драйвера промышленных сетевых протоколов Profibus, CANbus, сервис сетевых подключений, модуль шифрования данных и т.д.
Рис. 12. Принцип построения матрицы компонентов
Например, в задаче создания управляющих программ на уровне визуального представления размещаются редакторы языков программирования для контроллеров (см. Рис. 12). Драйвера для сетевых протоколов можно разместить сразу на 2 уровнях: хранения и предоставления данных и взаимодействия с аппаратурой.
Модульность в реализации пользовательской задачи системы характеризуется количеством логических уровней, которые занимает компонент. Если компонент занимает все 4 уровня матрицы – это означает отсутствие модульности для функций приложения в прикладной задаче.
Применение матрицы компонентов позволяет:
-
упорядочить необозримое множество компонентов прикладной составляющей современных систем управления электроавтоматикой, разделив их на группы по задачам пользователя и на логические уровни в специализации компонентов в задаче;
-
выявить полноту охвата пользовательских задач и выделить минимальный (базовый) набор компонентов, достаточный для скорейшего выпуска на рынок изделий с ограниченным набором функций;
-
исследовать модульность системы с целью ее последующего развития и расширения;
-
определить набор компонентов на этапе проектирования и разработки системы, что предотвратит дублирование функциональностей.
Более того, как видно из принципа построения матрицы, ряд пользовательских задач не ограничивается. Т.е. в матричном представлении возможно с необходимой детализацией представлять пользовательские задачи.
Например, задача разработки управляющих программ может быть разделена на задачу разработки управляющих программ в языках МЭК и задачу разработки управляющих программ на других языках. В матрице можно представить только те задачи, для которых будет вестись разработка. Например, при внедрении функций ряда компонентов внешних производителей.