Архитектор оборудования

(В автоматизации и проектирования сфере инженер или архитектор аппаратного обеспечения охватывает области электроники и электротехники со специализацией в аналоговых , цифровых или электромеханических системах.)

Архитектор аппаратных систем или архитектор аппаратного обеспечения несет ответственность за:

Взаимодействие с системным архитектором или заинтересованными сторонами клиента . В настоящее время чрезвычайно редко встречаются достаточно большие и/или сложные аппаратные системы, которым требуется архитектор аппаратного обеспечения, а не существенное программное обеспечение и системный архитектор. Поэтому архитектор аппаратного обеспечения обычно взаимодействует с системным архитектором, а не напрямую с пользователем(ами), спонсором(ами) или другими заинтересованными сторонами клиента. Однако в отсутствие системного архитектора архитектор аппаратных систем должен быть готов напрямую взаимодействовать с заинтересованными сторонами клиента, чтобы определить их (развивающиеся) потребности, которые необходимо реализовать в аппаратном обеспечении. Архитектору аппаратного обеспечения также может потребоваться напрямую взаимодействовать с архитектором программного обеспечения или инженером(ами) или с другими инженерами-механиками или электриками.
Формирование требований к аппаратному обеспечению высочайшего уровня на основе потребностей пользователя и других ограничений, таких как стоимость и график.
Обеспечение того, чтобы этот набор требований высокого уровня был последовательным, полным, правильным и функционально определенным .
Проведение анализа затрат и выгод для определения лучших методов или подходов для удовлетворения требований к оборудованию; максимальное использование имеющихся в продаже или уже разработанных компонентов.
Разработка алгоритмов разделения (и других процессов) для распределения минимум связи . всех существующих и прогнозируемых (аппаратных) требований по дискретным аппаратным разделам таким образом, чтобы между разделами, а также между пользователем и системой требовался
и компоненты (последовательные уровни), Разделение больших аппаратных систем на подсистемы каждый из которых может обслуживаться одним инженером по аппаратному обеспечению или командой инженеров.
Обеспечение максимально надежной аппаратной архитектуры . разработки
Создание набора требований к приемочным испытаниям совместно с проектировщиками, инженерами-испытателями и пользователем, которые определяют, что все требования к аппаратному обеспечению высокого уровня были выполнены, особенно для компьютерно-человеческого интерфейса .
Создание продуктов, таких как эскизы, модели , ранние руководства пользователя и прототипы, чтобы пользователь и инженеры были постоянно в курсе последних событий и согласовывали систему, которая будет предоставляться по мере ее развития.

Фон

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

Пользователи и спонсоры

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

Определение того, чего на самом деле хотят пользователи/спонсоры, а не того, что они говорят, — это не инженерия, а искусство. Архитектор не следует точной процедуре. Он/она общается с пользователями/спонсорами в интерактивном режиме — вместе они извлекают истинные требования, необходимые для спроектированной системы. Архитектор аппаратного обеспечения должен постоянно поддерживать связь с конечными пользователями (или системным архитектором). Следовательно, архитектор должен быть знаком со средой и проблемами пользователя. Инженеру нужно только хорошо знать потенциальное пространство инженерных решений.

Требования высокого уровня

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

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

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

Необходимо различать архитектуру пользовательского мира и инженерную аппаратную архитектуру. Первый представляет и рассматривает проблемы и решения в мире пользователя . В основном он фиксируется в интерфейсах компьютер-человек (CHI) инженерной системы. Проектируемая система представляет собой инженерные решения — то, как инженер предлагает разработать и/или выбрать и объединить компоненты технической инфраструктуры для поддержки ОМС. В отсутствие архитектора существует досадная тенденция путать две архитектуры, поскольку инженер думает с точки зрения аппаратного обеспечения, а пользователь может думать с точки зрения решения проблемы доставки людей из точки А в точку Б в разумное количество времени и с разумными затратами энергии или на предоставление необходимой информации клиентам и персоналу. Ожидается, что архитектор аппаратного обеспечения объединит знания как об архитектуре мира пользователя, так и о (всех потенциально полезных) архитектурах аппаратного обеспечения. Первое представляет собой совместную деятельность с пользователем; последнее является совместной деятельностью с инженерами. Продукт представляет собой набор требований высокого уровня, отражающих требования пользователя, которые могут быть использованы инженерами для разработки требований к проектированию аппаратных систем.

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

Анализ затрат и выгод

Большинство инженеров по аппаратному обеспечению являются специалистами. Они хорошо знают применение проектирования и разработки аппаратного обеспечения, применяют свои знания в практических ситуациях, то есть решают реальные проблемы, оценивают соотношение затрат и выгод различных решений в своей области аппаратного обеспечения и обеспечивают правильную работу всего, что они проектируют. Архитекторы аппаратного обеспечения — универсалы. От них не ожидается, что они будут экспертами в какой-либо одной аппаратной технологии или подходе, но ожидается, что они будут хорошо осведомлены о многих из них и смогут оценить их применимость в конкретных ситуациях. Они также применяют свои знания в практических ситуациях, но оценивают стоимость/выгоды различных решений, использующих разные аппаратные технологии, например, специально разработанные или коммерчески доступные аппаратные компоненты, и гарантируют, что система в целом работает в соответствии с ожиданиями пользователя.

Многие готовые к продаже или уже разработанные аппаратные компоненты могут быть выбраны независимо в соответствии с такими ограничениями, как стоимость, отклик, пропускная способность и т. д. В некоторых случаях архитектор уже может собрать конечную систему без посторонней помощи. Или ему/ей может понадобиться помощь инженера по аппаратному обеспечению для выбора компонентов, а также для проектирования и создания какой-либо функции специального назначения. Архитекторы (или инженеры) также могут заручиться помощью специалистов по безопасности, защите, связи, аппаратному обеспечению специального назначения, графике, человеческому фактору, тестированию и оценке, контролю качества, RMA, управлению интерфейсами и т. д. Эффективная команда архитекторов аппаратного обеспечения должна иметь немедленный доступ к специалистам критических специальностей.

Разделение и наслоение

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

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

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

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

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

Приемочный тест

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

Хорошее общение с пользователями и инженерами

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

Люди

Херб Саттер

См. также

Ссылки