Виртуальная структура прикладной области

Программное обеспечение прикладной области электроавтоматики в своем вертикальном сечении имеет многоуровневую структуру и полностью соответствует виртуальной машине. Рис. 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 уровня матрицы – это означает отсутствие модульности для функций приложения в прикладной задаче.

Применение матрицы компонентов позволяет:

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

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

• исследовать модульность системы с целью ее последующего развития и расширения;

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

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

Вопросы:

1. Опишите принципы классификации прикладных компонентов систем управления

2. Инструменты конфигурирования и их принципы работы

3. Опишите трехуровневую архитектуру Windows DNA и уровни прикладной области электроавтоматики.

4.Что означает «Матрица компонентов»?

5.Расскажите о принципе построения матрицы компонентов.

Лекция № 11-12. Анализ и систематизация набора прикладных компонентов с применением матрицы.

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

Принципы взаимодействия .Net с разработанным кодом

Принципы взаимодействия с разработанным кодом. Преобразование исходных кодов в новый формат. Использование двоичных компонентов для организации взаимодействия (COM, ActiveX, DLL).

Зачем нужна миграция приложений на новую платформу? .Net обособленная платформа, обладающая своими механизмами работы (CLR, CTS, CLS). Однако, в мире уже существует более 200 млрд. строк активно используемого кода. Поэтому успех .NET (впрочем, как и любой другой платформы) во многом будет зависеть от успешности миграции существующих приложений разработанных с использованием определённых технологий.

Преимущества .NET для использования существующих систем:

• Неизменность языка программирования (сохранение инвестиций (обучение, окружение) психологические преимущества);

• Возможность использовать старую систему как базу для новых разработок;

• Межъязыковое взаимодействие и улучшенные возможности для повторного использования без привязки к тому или иному языку программирования или компонентной модели В .Net можно выделить следующие два направления во взаимодействии с предшествующими технологиями:

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

• использование двоичных компонентов(COM и DLL) для организации взаимодействия с компонентами .NET