Главная Случайная страница


Полезное:

Как сделать разговор полезным и приятным Как сделать объемную звезду своими руками Как сделать то, что делать не хочется? Как сделать погремушку Как сделать так чтобы женщины сами знакомились с вами Как сделать идею коммерческой Как сделать хорошую растяжку ног? Как сделать наш разум здоровым? Как сделать, чтобы люди обманывали меньше Вопрос 4. Как сделать так, чтобы вас уважали и ценили? Как сделать лучше себе и другим людям Как сделать свидание интересным?


Категории:

АрхитектураАстрономияБиологияГеографияГеологияИнформатикаИскусствоИсторияКулинарияКультураМаркетингМатематикаМедицинаМенеджментОхрана трудаПравоПроизводствоПсихологияРелигияСоциологияСпортТехникаФизикаФилософияХимияЭкологияЭкономикаЭлектроника






Проблемы стыковки подсистем. Инфраструктура системы





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

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

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

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

Одна из причин проблемы стыка устройств – формальная. Документация на приобретаемый компонент очень часто не раскрывает всех технических тонкостей его интерфейса. Аналогично, техническое задание контрагентам на разработку (доработку) устройства не всегда отражает все технические детали, может содержать двусмысленные трактовки и банальные ошибки. Последнее обстоятельство во многом объективно. Невозможно на ранней стадии разработки (на стадии формирования технического задания) предугадать все нюансы. Ошибки и нюансы выясняются позже – на стадии стыковки и совместной отработки устройств в составе системы. Однако контрагенты неохотно соглашаются дорабатывать свои подсистемы для исправления ошибок технического задания. Для этого требуются дополнительное финансирование и сроки.

Другая проблема совместной отработки устройств системы заключается в сложности выявления причин нестыковки. Не редки ситуации, когда устройства по-отдельности работают нормально, а совместно не работают или же работают нештатно. Трудно понять в каком из устройств кроется причина проблемы. Причина может крыться не в самих устройствах, а в коммуникациях, адаптерах. Ярким примером может быть электромагнитная несовместимость устройств.

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

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

Разумеется, проблема стыка подсистем не нова. С ней сталкиваются практически все фирмы-разработчики сложных систем. Раз это так, то существуют и методы решения рассматриваемой проблемы.

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

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

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

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

Использование стандартов на уровне системы существенно упрощает проблемы увязки подсистем. При формировании технического задания контрагентам вместо объемного текста просто дается ссылка на соответствующий стандарт.

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

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

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

Показательным является пример использования номинала напряжения 110В в бытовых электросетях США. В свое время данный номинал был принят из гуманных, на первый взгляд, соображений безопасности. Однако безопасность по сравнению с номиналом 220В повышается символически, зато потери в электросетях возрастают в четыре раза. Кроме того, производителям электроприборов, стремящимся выйти на внешний рынок, приходится ориентироваться сразу на два стандарта: европейский и американский. Неудачный номинал напряжения в электросетях превратился в большую проблему, которая не может быть решена из-за наличия огромного числа абонентов.

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

Date: 2015-09-24; view: 449; Нарушение авторских прав; Помощь в написании работы --> СЮДА...



mydocx.ru - 2015-2024 year. (0.007 sec.) Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав - Пожаловаться на публикацию