Аппаратный архитектор - Hardware architect

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

В архитектор аппаратных систем или же аппаратный архитектор Ответственный за:

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

Фон

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вступительный тест

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

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

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

Люди

Херб Саттер