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