Cтраница 2
Характеристики каждой из подсистем неразрывно связаны с характеристиками всей системы и поэтому проектирование подсистем и всей системы должно вестись взаимосвязанно. К тому же следует учесть и то обстоятельство, что требования, предъявляемые отдельными подсистемами к системе в целом, часто противоречивы и, следовательно, получаемые проектные решения почти всегда оказываются компромиссными. [16]
![]() |
Распределение этапов формирования системы РУТ по стадиям оргпроектирования. [17] |
Указанная детализация объекта, безусловно, вызывает значительные изменения в содержании этапов проектирования подсистемы. [18]
В результате анализа модели радиосистемы находятся параметры, которые используются для составления технических заданий на проектирование подсистем, отдельных устройств и блоков. [19]
В то же время развитие работ по автоматизации управления капитальным строительством, в том числе и планирования капитальных вложений, требуют комплексного подхода к проектированию подсистемы автоматизированного управления капитальным строительством и проектированием. [20]
В идеальном варианте разработки системы альтернативные конфигурации системы должны были бы разрабатываться ИЧФ, но реально ИЧФ, во-первых, почти никогда не несут ответственности за проектирование подсистем или оборудования и, во-вторых, редко обладают теми инженерными знаниями, которые для этого необходимы, потому что альтернативные решения проекта вначале осмысливаются и принимаются либо отвергаются с точки зрения работы механизмов, а уже потом рассматриваются в свете деятельности персонала. [21]
В идеальном варианте разработки системы альтернативные конфигурации системы должны были бы разрабатываться ИЧФ, но реально ИЧФ, во-первых, почти никогда не несут ответственности за проектирование подсистем или оборудования и, во-вторых, редко обладают теми инженерными знаниями, которые лля этого необходимы, потому что альтернативные решения проекта вначале осмысливаются и принимаются либо отвергаются с точки зрения работы механизмов, а уже потом рассматриваются в свете деятельности персонала. [22]
Сведения о влиянии принципов организации данных действительно могут оказаться полезными при разработке конкретных типов индикаторов, а также при реализации четко определенных функций связи и принятия решений, однако из-за сложности взаимодействия большого числа процессов вывести общую формулу для их учета при проектировании подсистем индикации, вообще говоря, нельзя. [23]
Непосредственное использование полученной математической модели представляет большие трудности, связанные с раскрытием его для конкретных объектов и регуляторов. Поэтому для проектирования подсистем НЦУ рационально применять вместо математического выражения его графический аналог, полученный имитационным моделированием на ЭВМ. Методика имитационного моделирования представлена в разделе П, а результаты, полученные по математической модели для П - закона регулирования, могут служить для оценки достоверности результатов, полученных имитационным моделированием. [24]
Описывается опыт проектирования подсистемы планирования и управления запасами горячекатаной заготовки ( полуфабриката трубного производства) на Первоуральском новотрубном заводе. [25]
Формирование технического задания осуществляется на основе принципа локальной оптимизации с учетом назначения подсистем объекта и общих целей его создания и использования. В результате задачи проектирования подсистем формируются на основе декомпозиции критериев качества объекта. [26]
Существующие технические средства позволяют механизировать или автоматизировать информационные элементы бухгалтерского учета. В этой связи при проектировании подсистемы бухгалтерский учет решаются информационные задачи, включающие первичный учет, получение учетной информации на технических носителях, ее обработку и выдачу информации с помощью ЭВМ. [27]
Во - вторых, процесс собственной разработки является весьма трудоемким и длительным, а темпы технологического обновления в информатике очень высоки. К моменту, когда начинается проектирование очередной подсистемы, оказывается, что технологическая основа предыдущих разработок ( это могут быть и языки программирования, и используемые базы данных, и комплекс технических средств) уже устарели, и для следующей разработки используются другие средства. [28]
Подсистемы объекта имеют между собой функциональные связи, которые при раздельном проектировании подсистем должны быть выражены в виде информационных связей: выходная информация процесса проектирования одной подсистемы должна частично войти как входная информация в процесс проектирования другой подсистемы. Так, например, при проектировании гидроэнергетической подсистемы ГЭС выбирают число и мощность гидроагрегатов. Это проектное решение гидроэнергетической подсистемы должно войти в исходную информацию при проектировании электротехнической подсистемы. [29]
Принцип действия: ПС МОМДИС состоит из совокупности двух больших подсистем: подсистемы пользовательского интерфейса и математической подсистемы. Математическая подсистема состоит из необходимых для проектирования подсистем моделирования и оптимизации. Пользовательский интерфейс позволяет гибко управлять процессом проектирования и получать полную информацию в виде графиков и таблиц. После введения в ПС динамической модели сложной системы в виде набора коалиционных структур на множестве взаимодействующих объектов управления производится оптимизация управления многообъектной системой по вектору показателей. Подсистема оптимизации содержит ряд модулей, которые отдельно и в совокупности позволяют найти оптимальное управление или закон управления при бескоалиционном, коалиционном и кооперативном взаимодействии объектов на основе методов оптимизации по Нэшу, Парето, Шепли, по методу угроз и контругроз и др. Проектировщик имеет возможности комбинировать решения для получения стабильно-эффективных компромиссов. [30]