Принцип оптимальности Беллмана

Пусть есть многостадийный процесс

Каждая стадия характеризуется критерием оптимальности r. Есть вектор параметров состояния

,

Этот же вектор является вектором координат для i + 1 стадии

На каждой стадии есть вектор управления

,

 

Критерий оптимальности для всего процесса – это критерий оптимальности каждого аддитивного процесса

Существует ММ для i -ой стадии, которая связывает выходные, входные переменные и управление

Если это уравнение решать аналитически или численно, относительно выхода

то критерий оптимальности на этой стадии равен

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

N - стадия

Из условия максимума r_N определены оптимальные управления

Значение вектора оптимальности для любого вектора входных величин

N-1 - стадия

 

N-2 - стадия

Это рекуррентная формула Беллмана для многостадийных процессов

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

ВОПРОС №15

Техническое задание.

это основной документ. который определяет порядок создания равно как и развитие и модернизации, с нуля редко создают, чаще всего ведут модернизацию, т.е меняют например часть отвечающую за алгоритм. Развитие очень похоже на модернизацию, но это плановый процесс. Также техн. задание разрабатывается на систему в целом или как подсистемы. Доп. техническое задание – на части АС, комплектующие, программное обеспечение. В основе ТЗ лежат стандарты: ЕСКД, ЕСПД. Для группы объектов в ТЗ включ. общие требования. Если требования разработаны задание на проектирование всего объекта в целом, то тогда можно ТЗ на АС не разделять а ссылаться на условия. ТЗ должно соответствовать современному развитию науки и техники. ТЗ разрабатывается с учётом итоговой док-ии, исследовательски-обоснованных АС

Порядок изменения ТЗ

ТЗ изменяют на основании протокола заседания, служебных писем заказчика и т.д. Изменение оформляется дополнением(отдельный док-т) и подписываются заказчиком и разработчиком и далее являются неотъемлемой частью ТЗ

Состав ТЗ

Обязательно:

1. Общие сведения

2. назначение и цели создания системы(развитие или модернизация)

3. хар-ка объекта автоматизации

4. Требования к системе

5. Состав и содержание работ по созданию системы

6. Порядок контроля и проверки работы системы

7. Требования к составу и содержанию работ по подготовке объекта автоматизации и вводу системы в действие

8. Требования к документированию

9. источники разработки.

Некоторые пункты можно опускать, некоторые разделы выполняются в виде дополнений

1. Общие сведения: Наименование системы, условные обозначения, шифр темы, наименование предприятий разработчика и заказчика, инф-я кем и когда утверждается, плановые сроки начала и окончания работ, источник и порядок финансирования работ, указывается порядок оформления и предъявление результатов.

2. Назначение и цели создания: назначение системы, где указывается вид деят-ти АС или перечень объектов. Цели создания системы: технические и технологические, экономические и технико-экономические показатели, которые д.б достигнуты

3. Хар-ка объекта: краткие сведения об объекте, сведения об условиях эксплуатации объекта, хар-ки окружающей среды

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

5. Состав и содержании е работ: Содержание стадии работ, сроки выполнения, перечень организации исполнителей, записи, определяющие согласие участников и их ответственность. Перечень документов(ГОСТ34-201, ГОСТ24-601).Перечень документов, предъявляемых по окончании стадии этапов, вид и порядок проведения экспертизы технического задания, перечень работ по метрологическому обеспечению

6. Контроль и приемка системы: вид, состав, объем, и методы испытания системы, общие требования в приемке работ по стадиям, статус приемной комиссии.

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

8. Требования к документированию: перечень подлежащих к разработке комплектов и видов документов(ГОСТ34-201),требования к документированию межотраслевого применения, описать требования к документам м-ду стадиями.

9. Источники разработки: перечень документов и материалов, на основании которых, разработано технич. задание, разработка документов, на основе которых будет разрабатываться система,

Правила оформления ТЗ

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

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

А теперь «Метод явной декомпозиции»

Необходимость применения декомпозиции в задачах синтеза ХТС в целом и определения оптимальных управлений в частности обусловлено:

1. большая размерность задач (в т. ч. по вектору управления)

2. сложность ММ объекта

3. необходимость применения итерационных методов решения задач

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

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

Такая же задача решается для территориального ил функционального распределения

Критерий оптимальности представлен в виде аддитивной информации

Объект разбивается на q- подчастей локальных, каждая из которых выражается критерием

,

В простейшем случае, там, где выход является линейной зависимостью от входа:

Это для прерывных процессов для первой стадии

Для второй стадии – индекс – j + 1

Эта задача решается в условиях ограничений:

, (1 и 2 – нижний и верхний пределы)

Задача декомпозиции может решаться разными методами:

1. динамическое программирование (для дискретных многостадийных процессов)

2. метод неявной декомпозиции

3. метод явной декомпозиции

Пусть есть трехуровневая структура управления

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

В общем случае постановка задачи та же самая

Объект управления делится на q- стадий, работает в основном в статическом режиме

Для каждой стадии есть ММ

,

Вводится матрица

Для каждой части ТОУ модно сформулировать свою оптимизационную задачу, в которую вводятся дополнительно вектор параметров - которые являются решением центральной, координирующей задачей

Метод явной декомпозиции

При явной декомпозиции имеет смысл задание модели управления для r-ой локальной задачи поиска частного решения

^ - локальные уставки

Вычисляется

Далее решается q -ая локальная задача

Данная задача обычно решается поисковыми методами (итерационными), нелинейного программирования

ВОПРОС №16

Техническое задание.

это основной документ. который определяет порядок создания равно как и развитие и модернизации, с нуля редко создают, чаще всего ведут модернизацию, т.е меняют например часть отвечающую за алгоритм. Развитие очень похоже на модернизацию, но это плановый процесс. Также техн. задание разрабатывается на систему в целом или как подсистемы. Доп. техническое задание – на части АС, комплектующие, программное обеспечение. В основе ТЗ лежат стандарты: ЕСКД, ЕСПД. Для группы объектов в ТЗ включ. общие требования. Если требования разработаны задание на проектирование всего объекта в целом, то тогда можно ТЗ на АС не разделять а ссылаться на условия. ТЗ должно соответствовать современному развитию науки и техники. ТЗ разрабатывается с учётом итоговой док-ии, исследовательски-обоснованных АС

Порядок изменения ТЗ

ТЗ изменяют на основании протокола заседания, служебных писем заказчика и т.д. Изменение оформляется дополнением(отдельный док-т) и подписываются заказчиком и разработчиком и далее являются неотъемлемой частью ТЗ

Состав ТЗ

Обязательно:

10. Общие сведения

11. назначение и цели создания системы(развитие или модернизация)

12. хар-ка объекта автоматизации

13. Требования к системе

14. Состав и содержание работ по созданию системы

15. Порядок контроля и проверки работы системы

16. Требования к составу и содержанию работ по подготовке объекта автоматизации и вводу системы в действие

17. Требования к документированию

18. источники разработки.

Некоторые пункты можно опускать, некоторые разделы выполняются в виде дополнений

10. Общие сведения: Наименование системы, условные обозначения, шифр темы, наименование предприятий разработчика и заказчика, инф-я кем и когда утверждается, плановые сроки начала и окончания работ, источник и порядок финансирования работ, указывается порядок оформления и предъявление результатов.

11. Назначение и цели создания: назначение системы, где указывается вид деят-ти АС или перечень объектов. Цели создания системы: технические и технологические, экономические и технико-экономические показатели, которые д.б достигнуты

12. Хар-ка объекта: краткие сведения об объекте, сведения об условиях эксплуатации объекта, хар-ки окружающей среды

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

14. Состав и содержании е работ: Содержание стадии работ, сроки выполнения, перечень организации исполнителей, записи, определяющие согласие участников и их ответственность. Перечень документов(ГОСТ34-201, ГОСТ24-601).Перечень документов, предъявляемых по окончании стадии этапов, вид и порядок проведения экспертизы технического задания, перечень работ по метрологическому обеспечению

15. Контроль и приемка системы: вид, состав, объем, и методы испытания системы, общие требования в приемке работ по стадиям, статус приемной комиссии.

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

17. Требования к документированию: перечень подлежащих к разработке комплектов и видов документов(ГОСТ34-201),требования к документированию межотраслевого применения, описать требования к документам м-ду стадиями.

18. Источники разработки: перечень документов и материалов, на основании которых, разработано технич. задание, разработка документов, на основе которых будет разрабатываться система,

Правила оформления ТЗ

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

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

А теперь метод «Неявной декомпозиции»

Необходимость применения декомпозиции в задачах синтеза ХТС в целом и определения оптимальных управлений в частности обусловлено:

1. большая размерность задач (в т. ч. по вектору управления)

2. сложность ММ объекта

3. необходимость применения итерационных методов решения задач

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

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

Такая же задача решается для территориального ил функционального распределения

Критерий оптимальности представлен в виде аддитивной информации

Объект разбивается на q- подчастей локальных, каждая из которых выражается критерием

,

В простейшем случае, там, где выход является линейной зависимостью от входа:

Это для прерывных процессов для первой стадии

Для второй стадии – индекс – j + 1

Эта задача решается в условиях ограничений:

, (1 и 2 – нижний и верхний пределы)

Задача декомпозиции может решаться разными методами:

1. динамическое программирование (для дискретных многостадийных процессов)

2. метод неявной декомпозиции

3. метод явной декомпозиции

 

Пусть есть трехуровневая структура управления

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

В общем случае постановка задачи та же самая

Объект управления делится на q- стадий, работает в основном в статическом режиме

Для каждой стадии есть ММ

,

Вводится матрица

Для каждой части ТОУ модно сформулировать свою оптимизационную задачу, в которую вводятся дополнительно вектор параметров - которые являются решением центральной, координирующей задачей