Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:

№146.11.Барщевский

.pdf
Скачиваний:
92
Добавлен:
15.02.2015
Размер:
7.19 Mб
Скачать

261

РАЗДЕЛ 5. ВОПРОСЫ ПРИКЛАДНОЙ РЕАЛИЗАЦИИ АВТОМАТИЗИРОВАННОЙ СИСТЕМЫ

Глава 13. Реализация адаптивного автоматизированного управления

13.1. Структура реализации процессов управления производством

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

Реализуемая часть структуры автоматизированной системы обведена на рис. 13.1 пунктиром.

Маркетинг

ТЭП

 

 

 

 

 

 

 

 

 

МТС

 

 

ОУОП

 

МТС

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

ТПП

 

 

 

 

БУ

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

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

Подсистема маркетинга учитывается изменением спроса R(t).

Полагаем, что для старой, стандартной продукции нормы подсистемой ТПП уже сформированы. Считается, что подсистема ТПП разрабатывает как специфицированные нормы для подсистемы ОУОП, так и укрупненные (сводные) нормы для подсистемы ТЭП. При появлении спроса на новую продукцию подсистема ТПП оперативно разрабатывает новые нормы. Этот процесс учитывается запаздыванием θ по сравнению с моментом времени t появления спроса. В момент времени (t + θ) начинается пересчет плана.

Возможно учитывать и динамику подсистемы МТС. Однако предполагаем, что подсистема сбыта успешно справляется со своими функциями, а подсистема снабжения учитывается изменениями в поступлении материалов b(t).

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

262

Схема ТЭБД показана в главе 5, поэтому сосредоточим внимание только на алгоритмах приложения.

Выделим две группы алгоритмов: алгоритмы имитационной модели и динамического линейного программирования.

Руководитель

производства

Диспетчер

Начальник цеха

 

Начальник цеха

 

Начальник цеха

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Цех

Цех

Цех

Рис. 13.2. Структура рассматриваемой системы

Возможны различные варианты структуры программной реализации.

В работе [9] выделены “проектировочная ” и “эксплуатационная” части. Наличие в современных персональных компьютерах огромной вычислительной мощности позволяет в принципе не разделять эти части. Тем более, что скорректированный план вводится в действие после одобрения соответствующим ЛПР. Именно такой вариант используется в данной работе.

Покажем возможности реализации без детализации уровней иерархической структуры (рис. 13.2) и разновидностей ресурсов.

13.2. Специфика реализации

Предлагаемая программная реализация должна стыковаться не только с ERPсистемой, но и с CAD-, CAM-, PDM-реализациями. В связи с этим целесообразно первоначально рассмотреть структуру реализации автоматизированной системы целиком с указанием в ней места рассматриваемого программного продукта.

Автоматизированные системы, построенные на персональных компьютерах, все чаще называют корпоративными информационными системами (КИС),

263

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

Система моделей автоматизированного управления производством является частью КИС, распределенная база данных для которой показана на рис. 13.3. Такая база данных состоит из конструкторско-технологической (КТБД) и планово-экономической (ТЭБД) локальных баз данных.

КИП

КТБД

ПЭБД

АСТПП

АСУП

Админис-

трация

 

 

АРМ-К

АРМ-Т

АРМ ПЭО

АРМ ПДО

АРМ МТС

АРМ сбыта

АРМ-П

АРМ-ГПС

АРМы гл.

АРМ цеха

АРМ

АРМ ОТиЗ

cпециалис-

складов

 

 

 

 

 

 

тов

 

 

 

 

 

 

АРМ цеха

АРМ

 

 

 

 

бухгалтерии

 

 

 

 

 

 

Рис. 13.3. Распределенная БД:

КТБД – БД с конструкторско-технологическими данными; ТЭБД – БД с планово-экономическими данными

ТЭБД реализуется с помощью комплекса технических средств (КТС), элементами структуры которого являются практически автоматизированные рабочие места. Количество уровней структуры должно быть не менее числа уровней организационной структуры «руководитель предприятия – диспетчерская служба – цехи».

Распределенная структура системы говорит о необходимости применения полного режима «клиент-сервер».

В качестве программной основы возможно использовать электронные таблицы Excel, СУБД Access (для быстрой первоначальной проверки работоспособности алгоритмов) и InterBase в среде Delphi – для создания рабочей версии режима клиент-сервер.

264

Естественно, что предпочтительнее использовать один программный продукт, которым является Excel. Однако ему присущи многочисленные недостатки:

1. Интерфейс зависит от поставленной задачи. В табл. 13.1 показано решение на Excel задачи ДЛП для трех интервалов времени.

Нетрудно видеть неудобства для пользователя. Данные лучше организовывать в виде базы данных, что для продукта Excel проблематично;

2.Полученный на Excel результат трудно передать для использования в других приложениях;

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

Таким образом, следует для расчетов использовать СУБД.

В названных СУБД отсутствуют алгоритмы оптимизации, поэтому возможны два варианта сочетания алгоритмов баз данных с оптимизационными алгоритмами:

1.Оптимизационный алгоритм, например, алгоритм задачи линейного программирования, разрабатывается пользователем непосредственно внутри применяемой СУБД. Такая алгоритмическая организация описана в работе [9]. Ее достоинством является применение только одного вида программного продукта. Вместе с тем такая реализация не отличается тщательностью проработки всех возможных случаев процесса оптимизации (в том числе и зацикливания решении);

2.СУБД согласуется с одним из эффективных стандартных программных продуктов, осуществляющих оптимизацию (рис. 13.4). Для оперативной проверки работоспособности может быть использована электронная таблица Excel,

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

СУБД

 

Буфер

 

Стандартные

 

 

приложения

 

 

 

 

Рис. 13.4. Использование стандартных приложений

Последнее обстоятельство определяет дальнейшее использование для моделирования второго варианта, для чего необходима проработка вопросов взаимодействия СУБД InterBase и LINDO.

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

265

266

LINDO позволяет решать следующие задачи:

1.Находить решения задачи линейного программирования;

2.Проводить параметрические исследования.

Результаты ввода данных и решения задачи оптимизации с помощью LINDO представлены на рис. 13.5.

Рис. 13.5. Визуальное представление задания исходных данных и результа-

тов в LINDO

267

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

Удобство данного метода состоит в том, что для его использования не требуется специального программного обеспечения.

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

Недостатками этого способа является необходимость представления модели в текстовом виде и в обратном преобразовании. Уже при незначительных изменениях модели её необходимо передавать программе LINDO заново, что затрудняет расчет моделей в динамике. К тому же отсутствует возможность обработки нескольких моделей одновременно.

В то же время требуется проработка автоматического или автоматизированного ввода-вывода информации. Это достигается включением LINDOпродукта в программу пользователя посредством вызова функций LINDO API.

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

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

Приведем технологию расчёта оптимизационной задачи с применением пакета LINDO API. Исходные данные и результаты размещаются в базе данных (InterBase). Выборка коэффициентов из БД и последующая их демонстрация производится стандартными средствами Delphi с использованием цепочки ком-

понентов Database-Query-DataSource-DBGrid. Для вызова функций пакета

LINDO API набор данных (НД), содержащий коэффициенты, сначала преобразуется в матрицу (двумерный массив чисел), а затем в векторную форму, необходимую для пакета LINDO API. Результат записывается в базу данных также с помощью компонента Query и выводится на экран через компонент DBGrid. Фрагменты программы приведены в приложении.

LINDO API позволяет, как показано в [9], использовать функции LINDO непосредственно из сред визуального программирования, в частности, Delphi.

LINDO API, стыкующийся с Delphi, требует лицензирования, поэтому окончательно принят такой вариант стыковки программных продуктов. Связь их осуществлялась с помощью OLE-контейнера, через который данные из тек-

268

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

Успешное апробирование такой связи было выполнено по схеме рис. 13.6.

Нормы

 

 

 

 

 

 

 

 

 

 

 

 

m

 

 

 

 

 

 

План

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Шифр_р

 

 

m

 

 

 

 

 

 

Дата

 

 

 

 

 

 

 

 

 

Шифр_п

 

 

 

 

 

 

 

 

 

 

m

 

 

 

 

 

 

 

 

 

 

 

Шифр_п

 

 

 

 

 

 

 

 

 

 

 

 

Норма

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

План_п

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

API

 

 

 

API

 

 

Спрос_п

 

 

 

 

 

или

 

LINDO

 

или

 

 

 

 

 

 

 

 

Коэффициент_п

БД

 

 

 

 

OLE

 

 

 

OLE

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

БД

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Продукция

Ресурсы

 

 

1

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Шифр_р

 

 

 

 

 

 

 

 

 

1

Шифр_п

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Название_п

Название_р

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Ед_изм_п

Ед_изм_р

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Цена_п

Цена_р

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Рис. 13.6. Связь БД и LINDO.

Визуальные результаты работы представлены на рис. 13.7.

Заметим, что в версии Delphi 7 задание исходных данных в виде таблиц любой размерности и получение результатов в табличном виде удобно с помо-

щью компонент StringGrid закладки Additional.

Сравнение решений по рис. 13.7 с решениями непосредственно в LINDO говорит о полном совпадении результатов. Назовем схему, показанную на рис. 13.8, схемой ЛП.

Программное решение задачи динамического линейного программирования возможно следующими способами:

1.Прямым методом с помощью моделирования по схеме ЛП;

2.Методом Габасова;

3.Методом Егорова.

269

Рис. 13.7. Ввод исходных данных и вывод результатов

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

Заметим, что и при реализации имитационной модели (рис. 13.9, б) используются дифференциальные уравнения.

270

Рис. 13.8. Схема связей базы данных

Линейное программирование

а)

Объект управления

Имитационное

решение

б)

Объект управления

Рис. 13.9. Реализация ДЛП (а) и имитационной модели (б)