Войти
(В средах автоматизации и инженерии аппаратное обеспечение Инженер или архитектор охватывает области электронной техники и электротехники, с узкими специализациями в аналоговом, цифровом или электромеханическом систем.)
архитектор аппаратных систем или аппаратный архитектор отвечает за:
Архитектура больших систем была разработана как способ работы с системами, слишком большими для понимания одним человеком, не говоря уже о проектировании. Системы такого размера быстро становятся нормой, поэтому архитектурные подходы и архитекторы все чаще требуются для решения проблем больших систем.
Инженеры как группа не имеют репутации для понимания и комфортного реагирования на человеческие потребности или для разработки функциональных и эстетически приятных продуктов. От архитекторов ожидается понимание человеческих потребностей и разработка функциональных и эстетически приятных для человека продуктов. Хороший архитектор - это переводчик между пользователем / спонсором и инженерами - и даже между инженерами разных специальностей. Хороший архитектор также является главным хранителем видения конечного продукта пользователем, а также процесса выработки требований и реализации этого видения.
Определение того, чего на самом деле хотят пользователи / спонсоры, а не того, что, по их словам, они хотят, - это не инженерия, а искусство. Архитектор не следует точной процедуре. Он / она общается с пользователями / спонсорами в интерактивном режиме - вместе они определяют истинные требования, необходимые для спроектированной системы. Аппаратный архитектор должен постоянно поддерживать связь с конечными пользователями (или системным архитектором). Следовательно, архитектор должен быть знаком со средой и проблемой пользователя. Инженеру нужно только хорошо разбираться в потенциальном пространстве инженерных решений.
Пользователь / спонсор должен рассматривать архитектора как представителя пользователя и предоставлять всю информацию через архитектора. Прямое взаимодействие с проектными инженерами обычно не приветствуется, так как вероятность взаимного непонимания очень высока. Спецификация требований пользователя должна быть совместным продуктом пользователя и архитектора оборудования (или архитекторов систем и оборудования): пользователь приносит свои потребности и список желаний, архитектор приносит знания о том, что может оказаться выполнимым в пределах затрат и времени. ограничения. Когда потребности пользователя переводятся в набор требований высокого уровня, это также лучшее время для написания первой версии приемочного теста, который после этого следует строго поддерживать в соответствии с требованиями. Таким образом, пользователю будет абсолютно ясно, что он / она получает. Это также гарантия от непроверяемых требований, недоразумений и сползания требований.
Разработка первого уровня требований к аппаратному обеспечению не является чисто аналитическим мероприятием, и в нем также должны участвовать как архитектор аппаратного обеспечения, так и инженер. Если необходимо пойти на какой-либо компромисс - для удовлетворения таких ограничений, как стоимость, график, мощность или пространство, архитектор должен убедиться, что конечный продукт и общий внешний вид не сильно расходятся с намерениями пользователя. Инженер должен сосредоточиться на разработке проекта, который оптимизирует ограничения, но гарантирует работоспособный и надежный продукт. Архитектора в первую очередь заботят комфорт и удобство использования продукта; инженер в первую очередь озабочен производительностью и полезностью продукта.
Предоставление необходимых услуг пользователю - истинная функция спроектированной системы. Однако по мере того, как системы становятся все более крупными и сложными, а акцент в них отходит от простых аппаратных компонентов, узкое применение традиционных принципов разработки аппаратного обеспечения оказывается недостаточным - применение более общих принципов аппаратной архитектуры для проектирования (под) системы необходимы. Аппаратная архитектура также является упрощенной моделью готового конечного продукта - ее основная функция состоит в том, чтобы определять аппаратные компоненты и их отношения друг к другу, чтобы можно было видеть в целом последовательное, полное и правильное представление того, что пользователь имел в виду - особенно для интерфейса компьютер-человек. Он также используется для обеспечения того, чтобы компоненты соответствовали друг другу и соотносились желаемым образом.
Необходимо различать архитектуру мира пользователя и спроектированную архитектуру аппаратного обеспечения. Первый представляет и рассматривает проблемы и решения в мире пользователя. Это в основном зафиксировано в (CHI) инженерной системы. Спроектированная система представляет собой инженерные решения - то, как инженер предлагает разработать и / или выбрать и объединить компоненты технической инфраструктуры для поддержки ОМС. В отсутствие архитектора возникает досадная тенденция путать две архитектуры, поскольку инженер думает в терминах оборудования, а пользователь может думать в терминах решения проблемы доставки людей из точки A в точку B в разумное количество времени и с разумными затратами энергии или предоставление необходимой информации клиентам и персоналу. Ожидается, что архитектор аппаратного обеспечения объединит знания как об архитектуре пользовательского мира, так и о (всех потенциально полезных) аппаратных инженерных архитектурах. Первый - это совместная деятельность с пользователем; последнее - совместная деятельность с инженерами. Продукт представляет собой набор требований высокого уровня, отражающих требования пользователя, которые могут использоваться инженерами для разработки требований к проектированию аппаратных систем.
Поскольку требования развиваются в ходе проекта, особенно длительного, требуется архитектор до тех пор, пока аппаратная система не будет принята пользователем: архитектор - лучшая гарантия того, что в ходе курса не будет сделано никаких изменений и интерпретаций. развития ставят под угрозу точку зрения пользователя.
Большинство инженеров по аппаратному обеспечению - специалисты. Они хорошо знакомы с приложениями проектирования и разработки аппаратного обеспечения, применяют свои знания в практических ситуациях, то есть решают проблемы реального мира, оценивают рентабельность различных решений в рамках своей специализации в области аппаратного обеспечения и обеспечивают правильную работу всего, что они разрабатывают. Архитекторы аппаратного обеспечения - универсалы. От них не ожидается, что они будут экспертами в какой-либо одной аппаратной технологии или подходе, но от них ожидается, что они будут осведомлены о многих и смогут судить об их применимости в конкретных ситуациях. Они также применяют свои знания в практических ситуациях, но оценивают стоимость / преимущества различных решений с использованием различных аппаратных технологий, например, специально разработанных и имеющихся в продаже аппаратных компонентов, и гарантируют, что система в целом работает в соответствии с ожиданиями пользователя.
Многие коммерчески доступные или уже разработанные аппаратные компоненты могут быть выбраны независимо в соответствии с такими ограничениями, как стоимость, время отклика, пропускная способность и т. Д. В некоторых случаях архитектор уже может собрать конечную систему без посторонней помощи. Или ему / ей может потребоваться помощь инженера по аппаратному обеспечению для выбора компонентов, а также для проектирования и создания какой-либо специальной функции. Архитекторы (или инженеры) также могут заручиться помощью специалистов - в области безопасности, защиты, связи, специального оборудования, графики, человеческого фактора, тестирования и оценки, контроля качества, RMA, управления интерфейсами и т. Д. Эффективная команда архитекторов аппаратного обеспечения должна иметь немедленный доступ к специалистам по критическим специальностям.
Архитектор, планирующий здание, работает над общим дизайном, чтобы он был приятен и полезен его обитателям. В то время как одного архитектора может быть достаточно, чтобы построить дом на одну семью, может потребоваться много инженеров, кроме того, для решения детальных проблем, возникающих при проектировании нового высотного здания. Если работа достаточно большая и сложная, части архитектуры могут быть спроектированы как компоненты. То есть, если мы строим жилой комплекс, у нас может быть один архитектор для комплекса и по одному для каждого типа здания в составе архитектурной группы.
Большие аппаратные системы также требуют архитектора и большого инженерного таланта. Если спроектированная система является большой и достаточно сложной, главный архитектор аппаратных систем может передать часть работы подчиненным архитекторам, хотя все они могут быть членами совместной архитектурной группы. Но архитектор никогда не должен рассматриваться как технический руководитель.
Архитектор должен распределить требования к аппаратному обеспечению по основным компонентам или подсистемам, которые входят в компетенцию одного инженера по аппаратному обеспечению, или технического менеджера, или подчиненного архитектора. В идеале каждый такой аппаратный компонент / подсистема является достаточно автономным объектом, чтобы его можно было протестировать как полный компонент, отдельный от целого, используя только простой стенд для моделирования входных данных и записи выходных данных. То есть не обязательно знать, как работает система управления воздушным движением, чтобы спроектировать и построить для нее подсистему управления данными. Необходимо только знать ограничения, при которых предполагается, что подсистема будет работать.
Хороший архитектор гарантирует, что система, какой бы сложной она ни была, построена на относительно простых и «чистых» концепциях для каждой (подсистемы) или уровня, легко понятных каждому, особенно пользователю, без специальной подготовки. Архитектор будет использовать минимум правил, чтобы гарантировать, что каждый раздел четко определен и очищен от кладжей, обходных путей, сокращений или запутанных деталей и исключений. По мере развития потребностей пользователя (после того, как система введена в эксплуатацию и используется), впоследствии намного проще разработать простую концепцию, чем концепцию, нагруженную исключениями, особыми случаями и большим количеством мелкого шрифта.
Многослойная архитектура оборудования важна для того, чтобы на каждом уровне она оставалась достаточно простой, чтобы она оставалась понятной для одного человека. По мере подъема на уровни целые системы на более низких уровнях становятся простыми компонентами на более высоких уровнях и могут вообще исчезнуть на самых высоких уровнях.
Приемочные испытания всегда остаются основной обязанностью архитектора (-ов). Это главное средство, с помощью которого архитектор докажет пользователю, что оборудование соответствует первоначальному плану и что все подчиненные архитекторы и инженеры достигли своих целей. Большие проекты, как правило, динамичны, с изменениями, которые необходимы пользователю (например, при изменении его проблем) или ожидаются от пользователя (например, по причинам стоимости или графика). Но приемочные испытания должны быть всегда актуальными. Они являются основным средством информирования пользователя о том, как будет работать конечный продукт. И они выступают в качестве основной цели, ради которой все подчиненные сотрудники должны разрабатывать, строить и проверять.
Архитектор здания использует эскизы, модели, чертежи. Архитектор аппаратных систем должен использовать эскизы, модели и прототипы для обсуждения различных решений и результатов с пользователем или системным архитектором, инженерами и подчиненными архитекторами. Ранняя, черновая версия руководства пользователя неоценима, особенно в сочетании с прототипом. Следует явно избегать набора (технических) требований как средства общения с пользователями. Хорошо написанный набор требований, или спецификация, понятен только инженерному сообществу, так же как юридический контракт для юристов.
