Понятие платформы. Несколько слов о тестировании сложных аппаратных комплексов

Аппаратные платформы

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

Для ПК сейчас остались только две конкурентоспособные аппаратные платформы: IBM PC и Apple Macintosh (рисунок 3).Причем IBMPC явно доминирует, свыше 90% компьютеров относится к этой платформе. Одно время Apple Macintosh были более приспособленными для работы с графикой и в издательском деле, но сейчас возможности обеих платформ здесь сравнялись. Тем не менее,

компьютеры Apple не исчезают, а по-прежнему находят применение.
Для высокопроизводительных серверов, или наоборот – примитивных чипов существуют и другие аппаратные платформы: SunMicrosystems, Compaq, HewlettPackard и др.

В аппаратной конфигурации компьютера важную роль играет принцип открытой архитектуры . Это построение компьютера по модульному принципу, когда все однотипные устройства компьютера имеют:

1. взаимно согласованные протоколы (стандарты) передачи данных;

2. стандартные геометрические размеры и унифицированные разъемы для подключения.

Открытая архитектура позволяет совершать Апгрейд (Upgrade), т.е. модернизацию компьютера путем простой замены одних устройств на другие, не затрагивая всего остального.

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

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

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

Платформа IBMPC обладает открытой архитектурой, а Apple – закрытой.

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

Однако сама IBM, введя открытую архитектуру своих изделий, успешно решила тактические задачи, но стратегически проиграла. Устройства с открытой архитектурой для компьютеров IBM стали делать сотни компаний во всем мире – в Америке, Европе, Азии. Юридических запретов на это не существует. А технически открытая шинная архитектура позволяет довольно просто это сделать.

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

Один доцент постоянно талдычит нас одним и тем же: «Вы-аналитки. Вы должны ориентироваться в современных машинных архитектурах. Вам надо научиться выбирать аппаратную платформу, потому что скорость обработки данных и выполнения прикладных программ является ключевым фактором для бизнеса. Поэтому темой сегодняшней лекции будет микрокоманда выборки операндов из памяти в процессорах третьего поколения». Я думаю Вы поняли, насколько глубоко мы изучим современные аппаратные платформы=).

Я задумался(что уже само по себе здорово): «На основе каких критереев , каких подходов стоит выбирать аппаратную платформу? По каким принципам, корпорации выбирают или должны выбирать аппаратную составляющую своей IT-инфраструктуры ?» Конкретных ответов на все вопросы я не нашел, а нашел статью «Оптимизация процесса выбора аппаратной платформы для критических бизнес-приложений» и решил познакомить Вас с самым интересным. И так как ссылка на Elashkin Research при использовании материалов сайта обязательна, с удовольствием ставлю ее - http://www.elashkin.com :

Обязательной операцией при любом внедрении или изменении существующей информационной системы является оценка необходимого быстродействия системы и планирование необходимых вычислительных ресурсов для ее реализации. В настоящее время не существует точного решения этой задачи в общем виде, и если, несмотря на ее сложность и стоимость, такой алгоритм будет предложен каким-либо производителем, то даже небольшие изменения в аппаратной части, версии программного обеспечения, конфигурации системы или количестве или стандартном поведении пользователей приведут к появлению значительных ошибок. Тем не менее существует достаточное количество способов оценить необходимую для достижения требуемой производительности конфигурацию программного и аппаратного обеспечения . Все эти способы могут применяться в процессе выбора, но потребитель должен понимать их области применения и ограничения. Большинство существующих методов оценки производительности основывается на том или ином типе тестирования. Можно выделить два основных типа тестирования: компонентное и интегральное . При компонентном тестировании проводится тестирование отдельных компонентов решения, начиная от производительности процессоров или подсистем хранения информации до тестирования производительности сервера в целом, но без полезной нагрузки в виде того или иного бизнес-приложения. Интегральный подход характеризуется оценкой производительности решения в целом, как его программной, так и аппаратной частей. При этом может использоваться как бизнес-приложение, которое будет использовано в конечном решении, так и некоторые модельные приложения, эмулирующие некоторые стандартные бизнес-процессы и нагрузки. В основе классификации тестов компании Elashkin Research лежит сравнение аппаратного и программного обеспечения, использованного в тестах и планирующегося к установке у заказчика. В соответствии с этой классификацией можно выделить следующие типы тестов:

Остановимся подробнее на каждой группе тестов. Существует огромное число универсальных тестов (SPECint2000 для операций, ориентированных на целочисленные вычисления, SPECfp2000 для операций с плавающей точкой и т. п.), но наиболее известными из них являются тесты TPC (Transaction Processing Performance Council – Совета по обработке транзакций). TPC является независимой некоммерческой организацией, создан- ной для исследования обработки транзакций и производительности систем управления базами данных (СУБД) и распространения объективной и воспроизводимой информации о производительности в тестах TPC для компь- ютерной индустрии. Наиболее используемые в индустрии тесты этой организации: TPC-C (тесты по обработке транзакций) и TPC-H (запросы к хранилищам данных). Сама процедура проведения тестов включает четкую стан- дартизацию и обязательное проведение аудита независимой сертифицированной компанией. С другой стороны, сами тесты являются исключительно упрощенными и значительно отличаются от реальных систем. С нашей точки зрения, эти тесты дают исключительно важную информацию для сравнения различных аппаратных и программных решений, позволяют сравнивать их между собой, но не применимы для выбора конкретной системы для решения задачи заказчика . Специализированные тесты гораздо более соответствуют действительности. В этих тестах используется программное обеспечение, которое может применяться в проекте. Наиболее известны тесты SAP benchmark . При тестировании по методике SAP происходит тестирование работы всех систем и подсистем: процессоров, вводавывода, сетевого трафика, обработки ошибок и других. Каждый SAP Standard Application Benchmark состоит из набора исполняемых сценариев, симулирующих типичные транзакции и бизнес-процессы, соответствующие обычным сценариям работы с системой. SAP предлагает набор тестовых данных для проведения испытаний. Для того чтобы тесты производительности SAP соответствовали реальным условиям эксплуатации и могли использоваться для сайзинга, в них симулируется поведение клиента, заполняющего стандартные формы. Каждому такому симулированному клиенту задается время задержки в 10 секунд перед выполнением очередного шага в диалогах, что соответствует среднему реальному времени размышления живых опытных операторов. Во время выполнения тестов число одновременно работающих симулированных клиентов непрерывно возрастает до тех пор, пока время отклика системы в диалоговом режиме не превысит установленные спецификацией на тесты 2 секунды. Такая нагрузка намного больше соответствует реальным системам, чем нагрузка в тестах TPC, т. к. учитывает тот факт, что приемлемое время отклика системы более важно для работы, чем общее число проведенных транзакций. Это сравнительно небольшое изменение оказывает решающее влияние на настройки системы и на нагрузку всех ее компонентов, делая ее максимально близкой к реальной работе пользователей. В результате чего специализированные тесты, и особенно SAP benchmark, лучше подходят для оценки производительности серверных платформ. В связи с направленностью тестов на понимание их результатов людьми, принимающими решения и не обязан- ными разбираться в технических деталях и терминах, результатом теста является число полностью обработан- ных бизнес-операций. Такими операциями могут быть: число введенных заказов, число произведенных товаров, число заказов на сборку и т. п. В целом такие тесты гораздо более приближены к реальной жизни, но также обладают рядом недостатков . В первую очередь это небольшое количество приложений, для которых разработаны такие тесты. Кроме SAP benchmark, можно отметить Oracle Applications Standard Benchmark, тесты PeopleSoft, Siebel и ряд других приложений. Если планируется использовать другие приложения или нестандартные аппаратные и программные приложения, то эти тесты также мало информативны. Кроме того, конфигурация аппаратных средств, как и в случае тестов TPC, ориентирована на достижение максимальной производительности и отличается от тех конфигураций, которые будут использованы в реальном проекте.

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

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

«Производительность систем - один из ключевых аспектов функционирования информационной инфраструктуры. Однако это одна из наиболее сложных и комплексных проблем. Многие сложные моменты лежат в области тонкого взаимодействия программных и аппаратных компонентов систем и для их понимания недостаточно опыта работы только с программным или аппаратным слоем. К сожалению, число специалистов, понимающих глубинные процессы в таких системах невелико, притом, что только за счет глубинной оптимизации можно достичь роста производительность в десятки, сотни и даже тысячи процентов. Влияние грамотного выбора платформы и ее оптимизации на экономические параметры функционирования систем и возврат инвестиций трудно переоценить, но сложившаяся в индустрии практика выбора программно-аппаратных платформ и их настройки весьма далека от совершенства. Это тем более удивительно, что в открытом доступе находится огромное количество фактической информации о производительности различных систем и результатов тестов, но для того чтобы ее можно было использовать необходимо понимать условия и принципы тестирования, сущность процессов, происходящих в таких системах, и ограничения и достоинства каждого метода…» Михаил Елашкин, директор компании Elashkin Research

«Особенностью современного подхода к ИТ со стороны бизнеса является то, что ИТ инфрастуктура более не является вспомогательной, затратной. Сегодня она есть часть самого бизнеса. Мы видим, как заказчики перестают относиться к нашим услугам с позиции «сервер с тем или иным количеством процессоров, объёмом оперативной памяти, дисков и т.д». Они ставят нам теперь совсем иные задачи. «Мне нужно обрабатывать 25000 документов в час». «Мне нужно, что бы мы могли запустить 30 обработчиков одновременно». «Мне нужно поддерживать в оперативном режиме 28 отделений» - вот типичные требования современного бизнеса. Как мы можем сказать, что данное оборудование удовлетворяет требованиям заказчика? Разумеется, не из результатов отраслевых тестов. Наиболее точную оценку мы можем получить из результатов проведения нагрузочных испытаний. Это работа для настоящих профессионалов, глубоко разбирающихся в прикладных и системных программных средствах, тонко чувствующих аппаратную часть. В нашей компании существует специализированная экспертная группа, занимающаяся тестированием прикладных программных средств. Только на основании её экспертных оценок мы можем гарантировать заказчику, что предлагаемое решение справится с возложенной на неё задачей…» Вячеслав Елагин, компания Ай-Теко, директор Центра компетенции.

PS: я конечно не знаю как это переводится с французкого, но очень смешно …
________________
Заказывайте вывоз строительного мусора www.grigus.ru . Очень быстро и профессионально работают. Бытовые отходы, отходы по строительству — все увозят грузовыми машинами и КАМАЗами. Вывоз мусорных баков.

This entry was posted on Ноябрь 23, 2006 в 12:52 дп and is filed under .

Согласно официальному определению, предложенному организацией OSHWA.org: «Открытые аппаратные решения - это решения, дизайн которых является общедоступным и открытым для изучения, модификации, распространения, продажи. Это касается как самого решения, так и его производных и составных частей. Исходные данные проекта и его составляющие должны быть представлены в формате, который позволяет их дальнейшее изменение. В идеальном варианте открытое аппаратное обеспечение использует легкодоступные инструменты и материалы, стандартные процессы, открытую инфраструктуру, свободный контент и инструменты разработки с открытым исходным кодом, чтобы дать пользователям максимальную свободу в его использовании».

Здесь стоит отметить, что открытые аппаратные платформы не обязаны предлагать бесплатные инструменты разработки. Под «инструментами разработки» понимается широкий спектр средств проектирования и отладки, начиная от измерительных приборов (мультиметры, осциллографы) и интегрированных сред (IDE), и заканчивая веб-утилитами, которые обеспечивают функциональное управление проектами. Важно отметить, что многие из известных открытых платформ, например, Arduino, LaunchPad, BeagleBone и STM Nucleo, предоставляют бесплатные программные библиотеки, примеры кода и даже целые интегрированные среды, такие, как Arduino IDE или mbed.org.

Некоторые инструменты разработки сами являются открытыми платформами, что делает их весьма доступными из-за относительно низкой стоимости. В качестве примера можно привести универсальную измерительную плату Red Pitaya, работающую под управлением Linux. По сути, Red Pitaya является измерительным комплексом, который заменяет собой лабораторное оборудование, недоступное для рядовых пользователей из-за высокой цены. Red Pitaya предлагает к услугам разработчиков аналоговые входы со скоростью измерений до 125 MSPS и выходы со скоростью 100 KSPS. Этот универсальный измерительный прибор может выступать в роли различных стандартных приборов, таких как: как осциллограф с полосой пропускания около 50 МГц, анализатор спектра, LCR-измеритель импеданса, анализатор Боде, тесламетр, функциональный генератор с 14-битным разрешением, в том числе подходящий для аудио, и т.д. Для отображения результатов измерений Red Pitaya подключается к планшету, ПК или смартфону. Добавьте модуль расширения Sensor Extension Module и вы сможете подключить Red Pitaya к платам Arduino и датчикам SEEED Studio Grove sensors , что еще больше расширит функциональность этого измерительного комплекса.

Рис. 1. Универсальная измерительная система Red Pitaya представляет собой пример открытой аппаратной платформы и отличается максимальной доступностью. Red Pitaya обладает функционалом осциллографа, анализатора спектра, измерителя импеданса, анализатора Боде, тесламетра, как функционального генератора и т.д.

Плата Red Pitaya была представлена на интернет-платформе Kickstarter в 2013 году. Она стала побочным продуктом для компании, которая занимается разработкой приборов для ускорителей частиц. Таким образом, Red Pitaya - это инструмент измерения и управления с открытым кодом и программным обеспечением с поддержкой визуального программирования. Red Pitaya поддерживается Matlab, LabView, Python и Scilab. Благодаря открытому программному коду возможности Red Pitaya могут быть расширены за счет дополнительных функций и утилит, создаваемых пользователями.

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

Рассмотрим наиболее распространенные инструменты, используемые при работе с открытыми аппаратными платформами.

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

Еще одним инструментом разработки встраиваемого ПО являются интегральные среды (IDE). IDE представляют собой программные платформы, которые объединяют редактор исходного кода, компилятор/ интерпретатор, отладчик, инструмент автоматизации сборки и иногда инструменты тестирования. Многие интегральные среды позволяют отлаживать код и анализировать его работу в реальных устройствах. Существуют инструменты, помогающие визуализировать работу устройства и выполнять моделирование до того, как будет собран реальный прототип. IDE значительно оптимизируют и ускоряют процесс разработки.

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

Рассмотрим основные типы IDE, используемые для создания встраиваемого ПО:

1. Бесплатные интегральные среды разработки (IDE), например, Arduino IDE, Energia IDE для TI LaunchPads, которые можно свободно скачать с сайта производителя и установить на своем ПК.
2. Онлайн IDE, которые не требуют установки на ПК, но нуждаются в доступе к Интернету. Их плюсами является то, что они не требуют обновлений и не занимают места на жестком диске. Примером таких программ является Mbed.org.
3. Платные среды разработки. Как было сказано выше, компиляторы позволяют работать с определенным типом процессорных ядер, а если быть точным, то с определенным набором конкретных процессоров/ микроконтроллеров. Например, если используется пара процессоров с ядром ARM ® Cortex ® -M4, то вполне реальной может оказаться ситуация, когда один процессор поддерживается IDE, а второй нет. Поэтому прежде чем купить IDE следует проверить, что целевой процессор есть в списке поддерживаемых устройств. Примером, платной среды разработки являются, например, Keil от ARM и IAR Embedded Workbench от IAR Systems.
4. Бесплатные пробные версии платных сред с ограничением по времени. Многие IDE, например, IAR и Keil, имеют бесплатные пробные версии с ограниченным сроком бесплатной работы. После того как пробный срок заканчивается, программа блокируется и требует приобретения лицензии.
5. Бесплатные версии платных сред с ограничением функционала. Существуют ограниченные версии платных сред с урезанным функционалом. Примером такой среды может служить сборка Keil для микроконтроллеров STM32L0 с ограничением по размеру кода.
6. Бесплатные среды с открытым исходным кодом, например, различные GNU-решения. В качестве примера бесплатной среды можно привести Eclipse IDE. Eclipse IDE позволяет добавлять плагины для поддержки различных языков программирования, в частности C ++ или Python. Стоит отметить, что в большинстве случаев бесплатные компиляторы уступают коммерческим собратьям по качеству оптимизации кода. Однако со временем это отставание сокращается.
7. Микроконтроллеры поступают от производителя в незапрограммированном виде. Для физической «прошивки» программ требуются специальное устройство - программатор. Исключение составляют микроконтроллеры, которые имеют встроенный загрузчик (бутлодер). Загрузчик представляет собой небольшую встроенную программу, которая позволяет программировать микроконтроллеры с помощью одного из популярных интерфейсов USB, UART, CAN и т.д.

Рассмотрим варианты программирования микроконтроллеров без встроенного загрузчика.

• Многие популярные платы (такие как LaunchPad и Nucleo) имеют встроенные программаторы. Это позволяет подключать их к ПК с помощью USB и выполнять программирование.
• Для плат, в которых нет встроенного программатора, приходится использовать внутрисхемное программирование (In-System Programming, ISP). Для этого требуется внешний программатор. Обычно программатор подключается к ПК через USB или COM-порт, а к микроконтроллеру через специальный интерфейс программирования (SWIM, JTAG, SPI, UART и др.). В качестве примеров можно привести программатор ST-LINK/V2-1 для микроконтроллеров STM32/STM8 от STMicroelectronics, программаторы от Atmel для микроконтроллеров AVR, программаторы от Microchip для микроконтроллеров семейства PIC.

Рис. 2. STM32 Nucleo представляет собой яркий пример открытой платформы. Платы Nucleo поставляются со встроенным отладчиком ST-LINK / V2-1 (выделен красной рамкой)

1. Отладчики. Отладчик представляет собой набор инструментов, который позволяет программистам отслеживать выполнение программы и выявлять ошибки в коде. Отладчик состоит из трех основных частей: программная часть, выполняемая в среде IDE, аппаратная часть, реализованная в микроконтроллере, аппаратная часть, реализованная в специальном устройстве, которое также называют отладчиком. Здесь стоит отметить, что для всех современных микроконтроллеров программатор и отладчик представляют одно и то же устройство. Поэтому, например, для программирования и отладки STM32/STM8 будет достаточно программатора/ отладчика ST-LINK/V2-1.

Рассмотрим некоторые ключевые элементы и инструменты, применяемые при отладке встраиваемых систем:

• GDB или GNU Debugger - популярные программные отладчики, которые используются для работы с различными языками программирования. Многие из них поддерживают «удаленный режим», позволяющий контролировать отлаживаемое устройство с помощью приложения, запущенного на ПК.
• JTAG - интерфейс, который изначально разрабатывался для тестирования встраиваемых систем, но в дальнейшем «де-факто» ставший промышленным стандартом. В настоящее время JTAG широко используется, в том числе в открытых платформах.
• Точки останова используются для того, чтобы прерывать выполнение программ в нужных местах. Эта функция необходима для детального рассмотрения контекста, например, состояния портов ввода-вывода, содержимого регистров и т.д. Еще одной полезной функцией отладчиков является возможность пошаговой отладки программы.
• Open OCD (Open On-Chip Debugger) - пакет с открытым исходным кодом, который обеспечивает встроенную отладку, внутрисхемное программирование и тестирование для огромного множества платформ, что делает Open OCD привлекательным для многих производителей микросхем. Open OCD поддерживает множество отладчиков, в том числе и JTAG.

1. Инструменты для отслеживания ошибок и контроля версий

• Наличие инструмента для отслеживания ошибок является обязательным требованием для открытых платформ вне зависимости от числа разработчиков и пользователей. Существует множество инструментов отслеживания ошибок. Например, Bugzilla или Mantis BT могут быть загружены и установлены на серверах бесплатно, кроме того, есть сервисы, которые могут предоставить хостинг за символическую плату.
• Системы контроля версий - еще один инструмент, который имеет решающее значение для открытых платформ, тем более что открытые платформы подразумевают совместную работу множества пользователей и разработчиков. Такие инструменты, как Git и Subversion, являются популярными системами управления версиями и контентом. Сервисы, аналогичные GitHub, обеспечивают хостинг содержимого проектов отслеживание ошибок и совместные обзоры кода.

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

Вместо заключения еще одна мысль вдогонку

Очень часто разработчики ограничиваются тем, что становятся специалистами в рамках какого-то одного процессора или микроконтроллера. Конечно, доскональное изучение всех регистров и особенностей процессорного ядра является большим плюсом для конкретного проекта. Однако, стоит отметить, что технологии не стоят на месте, и умение быстро адаптироваться к различным платформам является гораздо более ценным навыком, чем знание всех тонкостей одного единственного решения. Открытые проекты значительно упрощают такое широкомасштабное обучение за счет уменьшения затрат средств и времени. Попытайтесь получить опыт с Arduino, приложите свои руки к микроконтроллерам PIC, поработайте с внешним программатором! Этот самообразовательный процесс может даже помочь получить работу, например, неопытным студентам, если они «засветятся» на каком-либо форуме. Освоение различных решений и архитектур отточит ваш навык самообучения, что станет залогом долгой и успешной карьеры.

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

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

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

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

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

В заключение перечисления списка проблем, возникающих в процессе разработки и тестирования, нужно привести еще одну. Зачастую складывается такая ситуация, когда требуется проверка сборки программного продукта «на дым» (так называемое дымовое тестирование, Smoke Testing), что означает быстрый прогон наиболее важных тестов. Но что если мы разрабатываем приложение, для которого требуются различные версии Internet Explorer? В этом случае будет тратиться много времени на загрузку подходящей системы, где установлена требуемая версия.

Суммируя описанные ситуации, обобщим проблемы, часто встречающиеся в процессе разработки и тестирования программных продуктов:

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

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

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

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

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

Инструменты виртуальных машин для тестирования и разработки

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

• Неуправляемое развертывание виртуальных машин на клиентских машинах или серверах тестирования, при котором либо сами тестировщики создают необходимые им конфигурации, либо копируют шаблоны виртуальных систем на свои компьютеры из центральной библиотеки виртуальных шаблонов (файлового сервера). Преимущество данного подхода – дешевизна решения, можно воспользоваться одной из многих бесплатных систем виртуализации (VMware Server, Virtual PC, VirtualBox и другие). Основные недостатки – стихийное развертывание виртуальных машин порождает конфликты в сетевой инфраструктуре, отсутствие контроля над использованием лицензий на операционные системы и прикладное ПО, невозможность интеграции в существующую ИТ-среду организации.
• Управляемое развертывание виртуальных систем из централизованных библиотек виртуальных шаблонов, с полным контролем над использованием виртуальных машин в рамках ИТ-инфраструктуры компании. К достоинствам данного подхода надо отнести возможность разрешения конфликтов между виртуальными и физическими системами в сети, контроль использования лицензий, возможность мониторинга использования виртуальной инфраструктуры и создания общего пространства между различными участниками процесса разработки и тестирования, интеграция в реальную ИТ-инфраструктуру предприятия. Основной недостаток данного подхода – высокая стоимость решений. Примеры продуктов, обеспечивающих управляемое развертывание виртуальных машин: VMware LabManager, VMLogix LabManager, Microsoft System Center Virtual Machine Manager.

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

1. Создание множества пользовательских конфигураций.

   При наличии большого объема свободного дискового пространства на машине тестировщика с помощью платформы виртуализации можно создать неограниченное число виртуальных систем, каждая из которых может быть загружена по требованию, без остановки рабочей деятельности работника в хостовой системе. Виртуальные машины могут также применяться на специализированных серверах тестирования на основе платформ VMware ESX Server, XenEnterprise или Virtual Iron. При этом могут быть назначены определенные права пользователям виртуальных систем, а также ограничены физические ресурсы сервера, которые могут быть использованы конкретным пользователем. На файловом сервере с виртуальными шаблонами могут храниться предустановленные виртуальные машины, которые развертываются на сервера тестирования или рабочие станции. В этом случае нужно учитывать особенности использования виртуальных машин в соответствии с лицензией. В большинстве случаев каждая виртуальная машина требует отдельной лицензии, однако есть и исключения: например, лицензия Windows Server 2003 Datacenter Edition позволяет запускать неограниченное число виртуальных экземпляров ОС.

   Если настроенное тестовое окружение уже развернуто на физической машине, его можно мигрировать на виртуальную с помощью продуктов вендоров платформ виртуализации и сторонних разработчиков. К таким решениям относятся продукты PlateSpin PowerConvert, VMware Converter, Microsoft Migration Toolkit.

2. Создание многомашинных конфигураций на одном физическом сервере.

   Платформы виртуализации, ориентированные на тестирование ПО (VMware Workstation, Virtual PC, VirtualBox, Xen), позволяют создавать целые виртуальные инфраструктуры с различными типами сетевого взаимодействия в пределах одного физического хоста. Например, можно создать несколько «блоков» из виртуальных серверов (сервер баз данных, сервер приложений, окружение клиента), настроить сетевые адаптеры виртуальных машин (у одной машины их может быть несколько, в VMware Workstation - до десяти), и запустить тестируемую связку серверов. При этом платформы виртуализации позволяют подключать сетевые адаптеры виртуальных машин к различным сегментам виртуальной сети.
   

   После того, как тестовая виртуальная инфраструктура будет создана, можно настроить параметры каналов связи между виртуальными машинами.
   

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

3. Резервное копирование виртуальных машин при тестировании.

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

   Если тестирование производится на выделенных серверах тестирования, то для создания резервных копий виртуальных машин могут применяться специализированные решения вендоров платформ виртуализации, такие как vRanger Pro компании Vizioncore, VMware Consolidated Backup (VCB), или еще не выпущенное решение Microsoft Data Protection Manager для Virtual Server 2005 R2, которые позволяют создавать резервные копии виртуальных машин без их остановки.

4. Демонстрация дефектов разработчикам.

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

5. Гибкая настройка аппаратной среды.

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

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

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

   Современные платформы виртуализации поддерживают стандарт USB 2.0, большое количество виртуальных сетевых адаптеров в виртуальной машине, эмуляцию SCSI-дисков, а также представление различного числа процессоров в гостевой системе посредством виртуального SMP (Symmetric Multi Processing).

6. Работа с несколькими виртуальными системами одновременно.

   Эта возможность позволяет тестировщикам не только использовать экземпляры различных гостевых систем при тестировании, но и осуществлять простой обмен файлами как между хостом и гостевой ОС, так и между гостевыми ОС с помощью механизма Drag&Drop. При этом некоторые платформы виртуализации позволяют производить простой обмен файлами либо через общие папки хостовой системы (Shared Folders), либо «перетаскивать» файлы между гостевыми системами (VMware Workstation).

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

Инструменты для разработки и тестирования при неуправляемом развертывании

Основой при управляемом развертывании виртуальных машин являются специализированные решения для создания и обслуживания тестовых виртуальных лабораторий (Virtual Labs), в пределах которых осуществляется контроль над использованием виртуальных систем различными группами пользователей, автоматизированное развертывание виртуальных машин на компьютеры участников проекта и создание общей рабочей среды. Эти решения довольно дорогостоящие (например, инфраструктура VMware LabManager обойдется не менее чем в $15 000), однако оправдывают себя в больших масштабах использования. Крупные компании, такие как Dell, очень широко используют виртуальные машины в пределах виртуальных лабораторий для испытаний программных продуктов. Такие системы используют сети хранения данных SAN, где в общей библиотеке виртуальных шаблонов располагаются шаблоны виртуальных машин, которые развертываются по требованию на свободных серверах тестирования на основе платформ виртуализации. Использование виртуальных лабораторий дает следующие преимущества:

• Работа с многомашинными конфигурациями как с единым модулем, возможность публикации этих модулей
• Снижение временных затрат на конфигурирование систем
• Разграничение доступа к виртуальным машинам и демонстрация дефектов путем передачи ссылок на проблемную ситуацию, сохраненную в виде снимка состояния гостевой системы
• Общая библиотека шаблонов с возможностью разрешения сетевых конфликтов при развертывании (идентификаторы безопасности SID, назначение уникальных MAC-адресов виртуальным сетевым интерфейсам)
• Централизованное обслуживание и развертывание обновлений в тестовых окружениях
• Мониторинг загрузки серверов тестирования

В данный момент наиболее популярными решениями для управляемого развертывания виртуальной тестовой инфраструктуры являются продукты VMware LabManager (для платформы ESX Server) и VMLogix LabManager (для платформ Microsoft, VMware и XenSource).

Тестовые лаборатории VMware LabManager

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

Помимо всех перечисленных достоинств систем управления виртуальными лабораториями, VMware LabManager предоставляет интеграцию с популярными средствами тестирования и , имеет возможности для развертывания шаблонов в несколько кликов мыши, поддерживает протокол LDAP, легко интегрируется с другими решениями для виртуальной инфраструктуры VMware и имеет возможности для автоматизации операций посредством собственного API (Application Program Interface). Основной недостаток этого продукта - возможность обслуживания виртуальных серверов только на платформах VMware.

Тестовые лаборатории VMLogix LabManager

В отличие от решения компании VMware, продукт поддерживает платформы виртуализации различных вендоров. В качестве основы виртуальной тестовой лаборатории можно использовать платформы Microsoft (Virtual Server), Xen (XenEnterprise) и VMware (ESX Server и Server). Кроме того, LabManager компании VMLogix поддерживает обслуживание физических серверов организации. Архитектура решения VMLogix LabManager представлена ниже:

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

Заключение

Модель организации процесса разработки и тестирования с помощью виртуальных машин позволяет существенно снизить затраты на развертывание тестовых пользовательских окружений и конфигурацию тестовых сред. По статистике, при тестировании программных продуктов на физических серверах и рабочих станциях на эти задачи уходит до 50 процентов времени команды тестирования. Виртуальные машины на платформах различных вендоров позволяют сократить это время в несколько раз, до 5% от общих затрат на тестирование. Повышенная гибкость виртуальных систем и их независимость от оборудования позволяют работать с ними, как с некими блоками, из которых строится виртуальная тестовая инфраструктура компании. Возможность предоставления общего доступа к найденным дефектам участникам команды разработки и пользователям продукта позволяет существенно ускорить поиск и исправление ошибок. Во многих компаниях уже стало стандартом де-факто тестирование с помощью виртуальных машин.

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

Предварительная подготовка

- Everyone please observe the fasten seat belt and no smoking signs have been turned on. Sit back and enjoy your ride.

Итак, по порядку.
Тестирование осуществляется на всех стадиях жизни аппаратуры. Тестирование бывает первоначальное (bringup), компонентное, функциональное, нагрузочное, производственное, и даже тестирование на заказчиках.

Еще на стадии разработки аппаратуры инженер думает о том, как он будет оживлять свое детище. Платы обсыпаются контрольными точками, отладочными коннекторами, перемычками, посадочными местами для запасных компонентов и прочим подобным. Совокупность возможностей для тестирования, заложенных в аппаратуру, называется DFT (Design for Testability). Плата, выпущенная в DFT фазе, может содержать в два раза больше компонентов, чем плата, вышедшая в тираж. Естественно, следуя принципу «работает – не трогай», потом ее никто не переделывает, и конечный потребитель недоуменно рассматривает пустующие посадочные места на материнской плате из магазина, придумывая различные конспирологические теории по поводу их предназначения.

Итак, забрали с фабрики наш борд – что делать дальше? Ну конечно же – воткнуть в розетку и выпустить из него весь белый дым.

- Everybody falls the first time.

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

Но обычно всё происходит по-другому. Первая фаза тестирования – bringup (в народе «оживляш»).

Оживление Рождение

- Wake up, Neo...

Для bringup обычно изготавливается 3-5 образцов (в расчете на то, что как минимум два будут уничтожены в бреду дебага). Если в составе устройства есть дорогие чипы - на один из образцов они не устанавливаются. Фаб может предложить вам сэкономить на золоте - НИ В КОЕМ СЛУЧАЕ НЕ СОГЛАШАЙТЕСЬ (ну просто паять придется много и часто).

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

• прозвонить землю-питание, там частенько есть КЗ;
• визуально осмотреть плату – там запросто бывает перепутана полярность конденсаторов, чипы стоят вверх ногами, присутствует стружка, с лёгкостью можно найти пассивные компоненты, которые оторвали;
• отдельно изучить – а не поставили ли вам на плату компоненты, которые вы просили не ставить (лайфхак: не делайте черную маску на первых сэмплах – на ней не видно установлены или нет чип-резисторы).

Наигрались с первой жертвой – идем пускать дым из боевой платы. При этом необходимо запастись пилотом с кнопкой отрубания питания и тепловизором. Пилот надо поставить под ногу, на случай если по рукам будет бить 220 В (ну или просто руки будут заняты), а в тепловизор можно увидеть КЗ.

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

И еще припаять немножко проводов:

Термоклей - наше все, лучший друг разработчика, почти как скотч в обычной жизни.
Сразу после Дремеля:

И молотка, которым приходится забивать бонки в плату, - не всегда выходит аккуратно.

Иногда приходится делать пациенту рентген или томографию. Выглядит это так:

Отсканировать плёнку, оказывается, не очень просто. Сняли телефоном на просвет напротив окна.

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

Отдельно стоит сказать про bringup материнских плат, потому что делается он по-другому. DFT сэмплов матерей обычно заказывается много – порядка 20 штук. Стоит это дорого, поэтому тут своя стратегия.

Берутся разработчики и отправляются на фабрику. Собирается порядка 5 плат и конвейер останавливается. Далее у разработчиков есть порядка 30 минут, чтобы плату включить (для x86-систем критерий успеха - загрузить BIOS). Если всем повезло - собираются остальные образцы. Если нет - производство отменяется, а разработчики едут домой думать. Деньги затраченные на PCB - потеряны, зато компоненты ждут на складе следующей попытки.

Хорошо - мы запустили нашу плату, и даже запустили другие, которые должны работать вместе с ней. Что дальше? Собираем стенд.
И тут вы, наверное, ожидаете увидеть такое?

Это все показуха для замминистров. Настоящий стенд должен быть собран из палок и желудей, и выглядит так:

- I didn"t say it would be easy, Neo. I just said it would be the truth.
(стакан для противовеса, фломастер - чтоб радиатор внатяг сидел - оно там проводом примотано)

В лабораторию набивается вот такая орда:

И все начинают наперегонки зашивать свои прошивки, программки, и тыкать везде осциллографом.
Иногда в процессе то и дело раздается вежливая просьба «Дорогой коллега, пожалуйста, уберите паяльник от моей руки - уж очень горячо» или «Будьте так добры - больше не включайте источник питания, когда я привинчиваю плату к шасси».

В нашем конкретном случае основная цель проверки совместной работы нескольких устройств - узнать, работает ли PCI Express, соответствует ли он стандарту. Просто без всего остального в принципе можно жить. Обычно функционал, закладываемый в железку, избыточен. Тонны GPIO выводов, I2C/SPI шин, термодатчиков, ледов и прочего, как правило, остаются невостребованными, так как их отладку откладывают на последний момент, который никогда не наступает.

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

Иногда видим опасный прищур:

А иногда ловим кальмаров:

Кальмары - самые опасные. Это нелинейные искажения, и встроенные эквалайзеры с таким бороться особо не умеют. Кальмары означают, что где-то в канале связи есть что-то очень плохое - слишком длинное переходное отверстие, существенный перепад импеданса, попадание какой-то неравномерности в 1/4 или 1/2 длины волны каких-то гармоник в полезной полосе и прочее подобное.

Кто-то, возможно, заметит, что кальмар немного похож на то, что делает с принятым сигналом DFE в эквалайзере приемника PCIe. Но в данном случае это таки кальмар, а не результат работы DFE (просто результат работы DFE используемое нами ПО отображать не умеет).

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

Ну и да - если вы планируете снимать глаза по интерфейсу I2C - забудьте, это будет очень очень очень медленно. Только in-band. Проблема в том, что для съема in-band у вашего устройства должен быть рабочий PCIe линк с компьютером, где работает тестовое ПО, что весьма проблематично, когда ваша железка не устанавливается в стандартный PCIe слот. И что самое забавное - у вас уже должен быть хоть как-то работающий линк на том канале, который вы отлаживаете, причем именно в том режиме (gen2/3) в котором вам нужно (ибо в разных режимах разные глаза и по разному работают эквалайзеры). Нет ножек, нет мультиков линка, нет глаз - вот как хотите, так и выкручивайтесь.

Про то, как выкручиваться с PCIe - я ранее написал отдельную .

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

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

Мы с подобным сталкивались несколько лет назад, когда тесты NVIDIA (да, многие производители предоставляют специфические наборы тестов, которые позволяют проверить вещи, недоступные программным путем при использовании стандартных утилит) давали редкие одиночные ошибки при длительных (сутки и более) прогонах на некоторых экземплярах плат. Тогда все дело оказалось в неудачной трассировке референсного клока (100 MHz) - хотя прежде чем мы к этому пришли, проверено было много всего, начиная от качества питания и заканчивая глазковыми диаграммами по всем линиям.

И кстати, это хорошо. Самый большой кошмар разработчика - когда все работает сразу. Это значит только одно - где-то закопана мина, которая сработает после отгрузки 100500 единиц оборудования заказчику. Дело в том, что в процессе поиска причины какой-то глобальной проблемы осуществляется проверка нескольких гипотез и как правило выявляется множество мелких неисправностей, никак с возникшей проблемой не связанных. Нет большой проблемы - не найдёте маленьких. Их за вас найдут ваши заказчики.

Проверка по списку

- All I do is what he tells me to do.

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

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

И почему-то вот в такой вот конфигурации при нагрузочном тесте все начало перегреваться. До сих гадаем - почему. Кабели грелись, наверное.

А два арбуза в каждой руке унести сможешь?

- You"re faster than this. Don"t think you are, know you are…

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

Кроме того, здесь помогают отладочные средства от производителя аппаратной платформы (например, Hardware Tests Executive от IBM). Таким образом можно загнать процессор в совсем предельные режимы, принципиально недостижимые при работе реальных приложений. Основные проблемы, выявляемые при нагрузочном тестировании – перегрев, нестабильность питания или перегрузка по максимальному току, ошибки при активной работе с интерфейсами ввода-вывода.

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

На стадии тестирования мы используем в основном микробенчмарки:
Для процессоров это обычно однопоточные нагрузки, типа spec2006 (сейчас уже speccpu2017 ), parsec , но вообще их огромное количество от сборки ядра linux и компрессии (lzma , gzip ), до перемножения матриц и вычисления быстрого преобразования Фурье (fftw ).
Для памяти много лет ничего не меняется: STREAM , RAMspeed SMP , lmbench .

Для дисков: fio , iozone .

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

P.S.: После того как мы на функциональных тестах первой ревизии сервера все проверили и обрадовались, у нас в лаборатории внезапно обвалилось три сервера. Мы начали проверять питание и на линии 1.2В (питание шины PCIe процессоров) увидели вот такое:

Акцентирую ваше внимание - одна клетка 500mV. Номинал 1.2 В. Резистором ошиблись в цепи компенсации одного из VRM. Вот с таким вот питанием были успешно пройдены все нагрузочные тесты, бенчмарки, прожарки и прочее подобное, и дизайн радостно поехал на вторую ревизию.
Так что, когда на Вашем уютном домашнем компьютере именитого бренда внезапно появляется экран смерти - не стоит думать, что это непременно «глючит винда».