Как понять, что сломалось у вашего Mac. Включаем Apple Hardware Test
Компьютеры Apple имеют множество полезных фишек и возможностей. Одной из таких особенностей является встроенный тест оборудования.
С его помощью можно самостоятельно диагностировать неисправность компьютера, найти неработоспособный элемент и разобраться в причине поломки.
Тест производительности не заменит полноценный поход в сервисный центр, но в ряде случаев окажется очень полезен для обычных пользователей.
Как можно проверить Mac в домашних условиях
На всех современных компьютерах Mac есть встроенная утилита для диагностики аппаратной части компьютера. Она позволяет произвести проверку большинства узлов и компонентов, выявить сбои в работе или нерабочий элемент на устройстве.
Разделяют две принципиально отличающиеся версии утилиты для диагностики Mac: Apple Hardware Test (Функциональный тест оборудования Apple) и Apple Diagnostics.
Первая версия программы (Apple Hardware Test) запускается на компьютерах Mac, которые были выпущены до июня 2013 года, а на более новых моделях используется вторая (Apple Diagnostics).
Подобные тесты могут выявить проблемы с большинством из компонентов Mac. Система поочередно опрашивает на наличие ошибок накопители, оперативную память, беспроводные модули, контроллер питания, аккумулятор и другие компоненты компьютера.
Проверка не займет много времени, обычно тест оборудования проходит от 2 до 5 минут.
Что нужно сделать перед проверкой
Перед запуском утилиты для проверки железа следует сделать следующее:
▪️ Отключите все периферийные устройства от Mac. Нужно отсоединить проводные принтеры, накопители, приводы для дисков, любое стороннее аудио- или видеооборудование, внешние видеокарты.
Рекомендуется оставить подключенными лишь клавиатуру, мышь\трекпад и монитор.
▪️ Перед запуском теста на MacBook обязательно подключите ноутбук к источнику питания.
▪️ Убедитесь, что Mac подключен по Wi-Fi или Ethernet кабелю к сети. В некоторых случаях может потребоваться загрузка дополнительных файлов для проведения тестирования.
Как запустить Apple Hardware Test на моделях до 2013 года
Интерфейс Apple Hardware Test на старых компьютерах Mac до 2013 года
1. Выключите Mac. Именно выключите, а не перезагрузите.
2. Включите компьютер и сразу же зажмите клавишу D (иногда cmd+D) до появления окна восстановления по интернету.
3. Введите пароль от вашего Wi-Fi и дождитесь загрузки теста.
4. Выберите русский язык в диалоговом окне и нажмите серую кнопку для продолжения.
5. Откроется меню Hardware Test.
6. Когда кнопка Тест станет активна, можно начать проверку. Для этого нажмите на кнопку или на клавишу T на клавиатуре.
7. Дождитесь окончания проверки, запишите полученные коды ошибок или сфотографируйте их на телефон, чтобы не потерять.
Как запустить Apple Diagnostics на моделях Mac с 2013 по 2016 годы
Интерфейс Apple Diagnostics на компьютерах Mac с 2013 по 2016 годы выпуска
1. Выключите Mac.
2. Включите компьютер с нажатыми клавишами D (иногда cmd+D) до появления системного меню.
3. Выберите русский язык в диалоговом окне и нажмите копку Далее.
4. Подтвердите запуск теста оборудования.
5. Дождитесь окончания проверки, запишите полученные коды ошибок или сфотографируйте их на телефон, чтобы не потерять.
После окончания тестирования доступны такие действия и горячие клавиши:
▸ запуск повторного тестирования Command + R
▸ получение дополнительной информации Command + G
▸ перезагрузка Mac клавиша R
▸ выключение компьютера клавиша S
Как запустить Apple Diagnostics на моделях Mac с 2016 года и новее
Интерфейс Apple Diagnostics на компьютерах Mac с 2016 года выпуска по настоящее время
1. Выключите Mac.
2. Включите компьютер с нажатой клавишей D (иногда cmd+D) до появления системного меню.
3. Тестирование начнется автоматически. Дождитесь окончания проверки, запишите полученные коды ошибок или сфотографируйте их на телефон, чтобы не потерять.
После окончания теста будут доступны те же действия, что и в предыдущем случае.
Почему не запускается тест оборудования
Тест оборудования может не запускаться и Mac будет переходить к обычной загрузке в следующих случаях:
Во-первых, если вы не отключили какие-либо сторонние устройства. Мешать запуску теста могут даже подключенные флешки или Type-С переходники.
Во-вторых, если вы используете неоригинальную беспроводную клавиатуру с Mac. Только родная Bluetooth клавиатура может подключаться к компьютеру на этапе загрузки и посылать команды перед запуском операционной системы. Подойдут лишь сторонние проводные клавиатуры.
В-третьих, загрузочная область системы с тестом оборудования может быть повреждена. При этом попробуйте запустить Mac с зажатыми клавишами Option (Alt) + D. Компьютер запустит систему диагностики по сети.
В-четвертых, запуску утилиты может мешать установленный пароль прошивки.
На время тестирования компьютера его следует отключить:
1. Перезагружаем Mac с зажатыми клавишами Command + R для загрузки в режиме восстановления.
2. В строке меню выбираем Утилиты – Утилита пароля прошивки (в некоторых версиях macOS пункт называется Утилита безопасного запуска).
3. Нажимаем Выключить пароль прошивки и указываем установленный ранее пароль.
4. Перезагружаем компьютер.
Как трактовать результаты теста
Тест Apple Diagnostics не выявил проблем
После окончания проверки на экране увидите один или несколько кодов ошибок, например:
Код ADP000: отсутствие проблем с аппаратным обеспечением Mac.
Коды CNW007 или CNW008: невозможность подключения к сети или проблемы с беспроводным модулем.
Код PPT001: проблемы с аккумулятором на MacBook. Это может быть как слишком высокий износ батареи, так и проблемы с зарядкой.
Детально со всеми возможными кодами ошибок аппаратного теста Mac можете ознакомиться на сайте Apple.
Когда нужно делать тест оборудования
Результат теста Apple Diagnostics с парой ошибок
Если изучить предложенные варианты действий в случае возникновения ошибок, заметите, что купертиновцы почти всегда рекомендуют посетить сервисный центр. Зачем же тогда производить тест оборудования в домашних условиях?
Во-первых, тест оборудования рекомендуется запускать при покупке Mac на вторичном рынке. Так можно сразу выявить неработающие модули или компоненты компьютера.
Во-вторых, тест пригодится в случае возникновения проблем после самостоятельного апгрейда Mac.
В-третьих, перед походом в сервисный центр нелишним будет самому знать о возможных проблемах с компьютером.
Не ленитесь запускать Apple Hardware Test или Apple Diagnostics, если Mac начал вести себя странно. Тестирование займет всего несколько минут, зато сразу сможете отбросить проблемы с железом и искать причину в ПО.
Hardware разработка: что стоит знать тем, кто затеял «железный» стартап
Аналитики компании Cbinsights выяснили, что только 48% стартапов удается привлечь второй раунд инвестиций, до третьего и четвертого доходят 15%, а единорогами становятся лишь 1%. Их успешность складывается из многих составляющих. Одна из них – успешный электронный дизайн в Hardware разработке, о котором и пойдет речь в этой статье.
Hardware разработка – сложный процесс. Она сильно отличается от software разработки и, например, не позволяет сделать бэкап или обновиться в случае обнаружения ошибки. Процесс разработки состоит из последовательных шагов. Пропуск любого из них несет большие риски, которые, увы, могут быть выявлены только на более поздних стадиях разработки.
Благодаря таким крупным IT-компаниям, как Яндекс, Сбер и Mail.ru сейчас на рынок поступает много девайсов российской разработки, и рынок «железных» продуктов быстро растёт. Однако менеджеров по управлению железной продуктовой разработкой на рынке совсем немного. Причина в том, что исторически «железной» и продуктовой разработкой занимались разные специалисты.
В своих подходах я ищу баланс между надежными подходами космического приборостроения и гибкими методами коммерческих компаний. На основании своего опыта работы я выделила основные этапы разработки девайса и их результаты. Вы можете ознакомиться с ними на этой диаграмме:
В этой статье я расскажу о разработке электронного дизайна устройства. Я не буду затрагивать тему разработки дизайна корпуса девайса, так как в сети есть отличная статья на эту тему.
Перед подробным разбором хочу выделить несколько этапов в разработке электронного дизайна. Это разработка технических требований (technical requirements), прототипирование (proto stage), разработка электронного дизайна (schematics, layout), изготовление сэмплов (samples production), тестирование (reliability tests) и утверждение электронного дизайна (confirmation). Для более простого запоминания ниже привожу схематичное изображение последовательности шагов. Далее в статье я детально остановлюсь на каждом шаге.
На самом начальном этапе, при определении концепции устройства, продукт-менеджер формирует требования и описывает пользовательские сценарии использования девайса. Затем вместе с командами разработки проджект менеджер описывает технические требования.
Продуктовые требования очерчивают пользовательские функции продукта, их вы обычно видите в магазине в описании девайсов. Технические требования описывают эти функции более детально и являются входными требованиями к разработке для профильных инженеров. В них указываются погрешности, диапазоны значений, требования к производительности, пропускная способность каналов, уровни напряжений и прочие технические параметры.
Чтобы лучше разобраться в отличиях продуктовых требований от технических, предлагаю вам взглянуть на эту таблицу, которую я составила из технических описаний, найденных в интернете.
Некоторые требования не существуют как продуктовые, а фигурируют только как технические. Например, требование к тепловыделению проектора или умной колонки пользователю не важно и не несет для него никакой практической пользы (если вы не разработчик обогревателей 😀 ). Но оно важно с технической точки зрения, так как перегрев некоторых компонентов может вывести девайс из строя, и пользователь не сможет больше прослушивать музыку или смотреть видосики.
Технические требования – это то, что обязательно проверяется перед утверждением электронного дизайна. Если, например, по какой-то причине требование по объему перегоняемого воздуха датчиком загрязнения воздуха не будет прописано как техническое, то на этапе тестирования оно не будет валидировано, и электронный дизайн будет утвержден без его проверки. В результате после начала продаж мы можем получить жалобы на то, что датчик загрязнения воздуха меняет свои показания при перемещении на каждые 10 см.
Чтобы не допускать таких оплошностей, предлагаю использовать мой чек-лист технических требований.
Предлагаю самостоятельно вводить и другие подразделы, если вам необходимо указать какие-то уникальные и специфические требования. Каждый параметр в подразделе стоит указывать с допустимыми отклонениями и погрешностями, ведь в мире нет ничего абсолютного.
На втором этапе проджект менеджер заказывает изготовление прототипов тех частей электронного дизайна, которые требуют проверки и подтверждения работоспособности.
Например, если это компактный девайс, то нужно проверить, влезают ли платы и самые крупные компоненты в требуемые размеры корпуса. Если мы сомневаемся, что более дешевый процессор потянет требуемую нагрузку, то покупаем отладочную плату и проверяем его работу под предполагаемой нагрузкой. Если же у команды небольшой опыт, или она делает девайс нового типа или применения, то можно быстро собрать схемотехническое решение на макетных платах и посмотреть, работают ли основные функции. Команда разработки в результате прототипирования должна убедиться, что проект реализуем.
На этапе прототипирования я рекомендую утвердить состав изделия, описанный в технических требованиях, основные функциональные блоки девайса и их назначение.
Состав работ на этапе прототипирования всегда стоит сначала обговорить с командами разработки. Прототипирование может занять несколько дней или недель, но, если вы уделите ему должное внимание, то на выходе получите более качественные и продуманные решения.
При определении объема работ прототипирования стоит также учесть, что к разным проектам предъявляются разные требования по срокам, стоимости и надежности в зависимости от особенностей их использования.
Например, технические характеристики чайника, пульта управления и умной колонки отличаются радикально. Чайник постоянно подключен к сети 220 В и пожароопасен, колонка с дешевым аккумулятором при сильном перегреве может взорваться и нанести увечья пользователю, а с пультом управления для ТВ на батарейках вряд ли может случиться что-то катастрофическое. Поэтому прототипом пульта для ТВ на батарейках может быть просто габаритный макет для проверки удобства положения в руке, а при прототипировании чайника и колонки уже нужно производить платы или отдельные функциональные узлы и проводить функциональные тесты.
Понимаю, что такое легкомысленное суждение может вызвать критику у инженеров, которые склонны перестраховываться по надежности технических решений.
Однако я оцениваю процесс с точки зрения менеджера. То есть для меня важны, в первую очередь, сроки выполнения работ и стоимость конечного продукта.
На этом этапе может возникнуть конфликт интересов, в ходе решения которого мы как команда выбираем наиболее оптимальное решение по надежности, срокам и стоимости конечного продукта.
Электронная часть устройства состоит из печатных плат с установленными электронными компонентами, коннекторов, шлейфов, антенн, кнопок и других электронных компонентов.
На этом этапе команда разработки готовит документацию для изготовления электроники. Я рекомендую использовать такой набор документации:
Чтобы не тратить время и ресурсы впустую, я бы посоветовала переходить к разработке топологии печатных плат сразу же после прототипирования и проверки электрической схемы. В противном случае, если на одном из последующих этапов будет выявлена ошибка, разработанную топологию печатной платы будет сложно и практически невозможно откорректировать, и ее придется переделывать заново.
Планированием и организацией процесса разработки в первую очередь занимаются технические лиды команд, поэтому я не буду останавливаться на нем подробно.
В VC уже были публикации про подготовку этих процессов. Например, много ценных рекомендаций по работе с БОМ файлом вы можете найти в этой статье.
Перед тем, как приступить к работе с фабрикой по производству девайсов, проджект менеджер заказывает их образцы, чтобы проверить разработанные технические решения в действии. Вместе с командой конструкторов проджект менеджер может подобрать быстрые и наиболее дешевые способы изготовления образцов, подходящие для единичного производства.
На этапе тестирования команда разработки совместно с тестировщиками проверяет, выполняет ли разработанный девайс все технические и продуктовые требования. А владельцы бизнеса, совместно с продукт-менеджером, окончательно утверждают внешний вид девайса.
Ни один вид тестирования не проводите только лишь на одном девайсе. Тестирование на разных устройствах минимизирует влияние случайных факторов. Например, ошибок монтажа, неисправностей, возникших при транспортировке, бракованного электронного компонента и даже пыли, вызвавшей короткое замыкание на плате.
Количество девайсов для каждого вида испытаний, уточняет проджект-менеджер совместно с командой разработки и QA на этапе согласования программы испытаний.
При выборе количества устройств исходите из бюджета проекта, уровня технических решений (чем сложнее устройство девайса, тем больше экземпляров потребуется). Если у вас большая команда разработки и мало времени, то рекомендую всем функциональным командам раздать минимум по три девайса, чтобы проводить проверки параллельно.
К примеру, на термоиспытания и стресс-тесты я рекомендую выделять большее количество девайсов (по 5-10 штук), чем на другие виды испытаний (2-5 шт) из-за погрешностей измерения температуры и возможной неравномерности в нагрузке девайса. То же самое касается и других важных тестов. Минимальное количество девайсов на испытания – 2-3 штуки, чтобы исключить ошибки сборки или брак какого-то одного компонента на единственном девайсе из-за того, что сборщик чихнул при сборке =D
Например, для тестирования я изготавливала 20 девайсов в корпусе и 30 комплектов плат без корпуса. Девайсы использовались для тестов, в которых корпус влияет на измерения. При проведении стресс-тестов измеряется тепловыделение девайса, и корпус играет важную роль в этом процессе – форма корпуса напрямую влияет на процесс рассеивания тепла внутри девайса.
Также на девайсах в корпусах обычно проверяются акустические параметры, работа при повышенной и пониженной температуре окружающей среды, работа компонентов, закрепленных непосредственно на корпусе (разъемы, микрофоны, кнопки и т.п.).
В одном из моих проектов на этапе EVT возникла ситуация, когда уровня напряжения сигнала управления шаговым мотором не хватило до уровня логической единицы. В итоге шаговый мотор совсем не работал, несмотря на то, что мы предварительно макетировали схему управления шаговым мотором, а в макете всё работало отлично. Также оказалось, что режим работы шагового мотора в нашем целевом железе гораздо более громкий, чем на макете. Поэтому в итоге пришлось сильно изменять схему управления, добавлять микроконтроллер и планировать повторение полного цикла EVT-тестов на следующей стадии разработки.
Из опыта своей работы, я выделила пять основных этапов испытаний электронного дизайна (EVT tests):
Приведу пример набора тестов:
Часто на этапе EVT девайс много раз собирается и разбирается, происходят замены плат и иногда компонентов, где-то что-то отваливается, отклеивается, раскручивается и ломается. Все замечания я рекомендую собирать в списки и на этапе DVT/PVT возвращаться к ним и перепроверять. На этом этапе стоит составить два списка потенциальных рисков для проверки на следующих стадиях разработки: конструктивные и сборочные.
Я рекомендую отметить все компоненты, которые плохо прикручены, раскручены, отклеены, шатаются, плохо затянуты, разбалтываются, криво посажены и припаяны, плохо стоят и упираются друг в друга и т.п.
Примером потенциального риска сборочного процесса может быть раскрученный винт (он мог раскрутиться при транспортировании или недостаточно закручен при сборке); компонент, упирающийся в другие детали; разъем, мешающий установке других компонентов; болтающиеся провода и шлейфы; ненадежное приклеивание проводов, шлейфов и прочих компонентов. Это может быть даже выкрутившийся звенящий винт, перекатывающийся внутри девайса (и такое встречалось в нескольких проектах =) )
По результатам испытаний команда разработки и тестирования принимает совместное решение: можно ли считать текущую стадию разработки завершенной. Если в процессе испытаний команда тестирования выявила недостатки, требующие доработки электронного дизайна, то проджект-менеджер совместно с командой тестирования и разработки согласовывает план мероприятий по их устранению. В зависимости от критичности недостатка и от способа его устранения я предлагаю работать по нескольким сценариям:
Если недостаток некритичный (например, необходима замена номинала резистора в том же типоразмере компонента), то можно перепаять элемент и провести повторные тесты, на которых недостаток выявился.
При некритичном недостатке с необходимостью переразведения платы, лучше всего переизготовить платы и повторить тест. Однако в зависимости от сроков проекта и процессионализма команды разработки можно принять и другие более рискованные решения. Например, иногда может потребоваться внести доработку на текущих платах, перерезав ненужные дорожки и спаяв дополнительные компоненты на проводах, и повторить испытание. В таком случае схемотехническое решение будет проверено, и останется риск только в возможной ошибке разведения платы.
При критичном недостатке с необходимостью замены микросхемы на другую в точно таком же корпусе, нужно принимать решение по ситуации. Например, если вопрос тепловыделения критичен или близок к критичному, лучше переизготовить плату, так как некачественный пропай сложного корпуса может непредсказуемо повлиять на тепловыделение.
Если недостаток критичный, то чаще всего требуется переразведение платы. Это чаще всего повлечет за собой увеличение сроков разработки.
После успешного прохождения всех испытаний команда разработки и тестирования принимает решение об утверждении электронного дизайна. Это означает, что команды разработки и тестирования создали документанцию, изготовили девайсы и проверили выполнение всех технических и продуктовых требований. Можно переходить на следующую стадию разработки – DVT.
Все выявленные ошибки должны быть устранены до начала этой стадии разработки. Если какая-то проблема будет выявлена на стадии DVT, это потребует перезапуска туллинга. То есть нужно будет заново начать стадию DVT с новой оплатой и потерей 45 дней.
Поэтому так важно внимательно отнестись к составу работ на каждом этапе до запуска туллинга, произвести прототипирование важных функциональных узлов и проверить все технические требования.
Это мой первый опыт публикации в VC. Буду рада узнать, откликнулась ли у вас эта статья и почитать в комментариях о вашем опыте в hardware разработке. В следующих статьях я хотела бы подробнее рассказать о видах испытания «железа» и поделиться своим опытом запуска серийного производства в одной российской компании. Хотели бы узнать больше об этих темах?:)
П.С.: Спасибо Насте Седухиной за помощь в ректировании текста.
Hardware-in-the-Loop
Сложным, дорогостоящиям и требующим длительной разработки техническим системам для проверки и подтверждения работоспособности архитектуры нужны тщательные и надежные тесты. Но по мере усложнения современных систем, особенно в случае программного обеспечения, об этом критическом шаге проще говорить, чем действительно его сделать.
Представьте себе тестирование электронных компонентов нового автомобиля. Чтобы оставаться актуальными на современном рынке, современные автомобили должны включать в себя современные системы помощи водителю (ADAS), камеры, радары и многое другое. Тестирование этих подсистем на собранном продукте в желаемых сценариях использования гарантирует, что испытания проводятся в идеальном контексте, но оно также влечет за собой значительные накладные расходы и сложность проверки каждого сценария.
Откладывание испытаний до окончательной сборки сопряжено со значительным риском, а изменения, которые необходимо внести по результатам испытаний, могут привести к катастрофическим последствиям для графика. Обязательно нагрянут немыслимая стоимость тестирования и неопределенность времени выхода на рынок. Сложность этой проблемы возрастает еще больше, если учесть, что каждый элемент из множества электронных блоков управления (ECU) в автомобиле работает с огромным количеством сигналов, представляющих различные функции и типы входов/выходов, что затрудняет тестирование с полным покрытием. Все эти факторы приводят к формированию нерешаемой задачи, ставящей под сомнение возможность тщательного тестирования, которое будет эффективным с точки зрения затрат и времени.
Решение должно обеспечивать тестирование с полным покрытием без использования готового конечного продукта в полевых условиях. Позволяя тестируемым блокам ECU взаимодействовать с имитируемым сценарием использования, вы можете проводить раннее тестирование и обнаруживать как можно больше дефектов программного обеспечения. Это — основа программно-аппаратного моделирования (Hardware-in-the-Loop).
Что такое Hardware-in-the-Loop
Программно-аппаратное моделирование (Hardware-in-the-Loop) — это метод, в котором реальные сигналы от контроллера подключаются к тестовой системе, которая имитирует реальность, заставляя контроллер думать, что он находится в собранном продукте. Тестирование и проектирование выполняются так, как если бы использовалась реальная система. Вы можете легко выполнять тысячи различных сценариев, чтобы должным образом проверять и улучшать свой контроллер без затрат и времени, требуемых реальными физическими испытаниями.
Рассмотрим машину еще раз. ECU двигателя отвечает за преобразование измерений датчика в такие действия, как регулировка подачи воздуха при нажатии на педаль газа.
Программно-аппаратное моделирование заменяет двигатель симуляцией, состоящей из аппаратного и программного обеспечения, которое взаимодействует с реальным вводом/выводом, как если бы мы работали с настоящим двигателем. Поскольку в программном обеспечении могут быть сделаны изменения, вы можете быстро включить эти изменения в программное обеспечение ECU или двигателя, протестировать широкий спектр различных сценариев использования и расширить тестовое покрытие по мере необходимости, чтобы провести тесты безбоязненно и всесторонне без необходимости рисковать дорогостоящей физической системой.
Для того, чтобы программно-аппаратное моделирование приносило пользу, качество программного обеспечения имеет первостепенное значение. Программное обеспечение для моделирования должно быть связано с аппаратной частью, которая не только учитывает технические характеристики, вроде типа разъема или ввода/вывода, но и позволяет вводить в систему неисправности, а также способна тестировать сценарии из реального мира.
Именно здесь вы почувствуете бремя выбора программного и аппаратного обеспечения, которое вы будете использовать для обеспечения полного тестового покрытия при минимальном времени, затрачиваемом на настройку системы, и максимальном удобстве использования. Кроме того, чтобы идти в ногу с быстро меняющимися рыночными требованиями, вам необходимо найти решение, которое подходит не только для одного определенного теста, но и для следующих, а значит, это решение должно быть настраиваемым и отвечать требованиям завтрашнего дня.
Платформо-ориентированный подход решает проблемы с тестами
National Instruments предлагает комплексное аппаратное и программное решение, которое поможет вам быстро начать работу с конфигурационными программным обеспечением и модульным вводом/выводом. Вместо использования универсального решения с дорогостоящими функциями и вводом/выводом, которые не имеют отношения к вашему тесту, решения NI адаптированы для вашего конкретного приложения. Вы можете свободно настраивать аппаратное и программное обеспечение для учета нестандартных сигналов и для увеличения количества операций ввода-вывода по мере необходимости.
Дизайн и для нынешнего и для следующего поколения
Интеграция изменяющихся требований безопасности и государственных нормативов, включение новых датчиков и реагирование на востребованные на рынке технологии — это лишь несколько примеров, иллюстрирующих, что тестирующие устройства являются наиболее удобным и экономичным решением в том случае, если они могут реагировать на эти изменяющиеся требования.
Hardware-in-the-Loop-симуляторы от NI построены на открытой архитектуре, основанной на готовых коммерческих компонентах вроде PXI или модулей коммутации, нагрузки и согласования сигнала, чтобы вы могли настраивать ваши системы в соответствии с требованиями к тестированию и идти в ногу с развивающимися трендами индустрии. По мере появления новых идей в вашей конструкции и по мере развития технологий, вы можете снизить риск отставания за счет обеспечения технической перспективности вашей тестовой системы, используя программное и аппаратное обеспечение, которое адаптируется под ваши задачи.
Борьба с растущей сложностью
Цель тестирования – внесение осознанных изменений в программное обеспечение, которые приведут к желаемому конечному продукту. Тестовые системы должны адаптироваться по мере обнаружения ошибок и внесения исправлений. Зафиксированные системы типа «черный ящик» усложняют (если не делают невозможным) учет увеличения количества каналов и изменения типов ввода/вывода. Модульное оборудование от NI, вроде PXI или перестраиваемого ввода/вывода (RIO), основано на отраслевом стандарте, позволяющем добавлять ввод/вывод или изменять его тип без необходимости перестраивать тестовую систему. В случае моделей, используемых в таких областях, как силовая электроника, где точность модели и аппаратная надежность являются ключевыми характеристиками, VeriStand может использовать ваш код для ППВМ (программируемая пользователем вентильная матрица), позволяя вам выбрать уровень настройки, необходимый для вашего приложения.
Шагайте в ногу с меняющимися требованиями к конструкции
С открытой платформой от NI вы можете воспользоваться преимуществами функционально совместимого аппаратного и программного обеспечения и выбрать подход, который вы считаете лучшим. Например, вы можете использовать партнерское аппаратное обеспечение, выбрать Python для автоматизации и импортировать модели из различных сред, включая Simulink. Продукты NI совместимы по стандарту ASAM XIL, что означает, что вы инвестируете в надежный и адаптируемый отраслевой стандарт, а не в одноразовое решение.
VeriStand — конфигурационное тестовое программное обеспечение от NI, работающее на детерминированной операционной системе реального времени, в которой вы можете сразу проводить тесты без необходимости программировать. Однако при возникновении особых случаев это же программное обеспечение можно настроить с помощью собственного кода LabVIEW. Перенастраиваемые ППВМ обеспечивают точный контроль вашего ввода/вывода и позволяют вам реализовать обработку, встроенную в оборудование, которую можно будет изменить как только вас посетит новая идея.
Вы – эксперт
Никто не знает вашу конструкцию так, как вы. Hardware-in-the-Loop гарантирует, что ваш конечный продукт соответствует вашим ожиданиям, а затраты и время выхода на рынок минимизированы. Аппаратное и программное обеспечение для Hardware-in-the-Loop от NI дает вам возможность разработать тестовую систему, необходимую для производства любого надежного продукта, который вы можете себе представить.
Мы большая компания-разработчик automotive компонентов. В компании трудится около 2500 сотрудников, в том числе 650 инженеров.
Мы, пожалуй, самый сильный в России центр компетенций по разработке автомобильной электроники. Сейчас активно растем и открыли много вакансий (порядка 30, в том числе в регионах), таких как инженер-программист, инженер-конструктор, ведущий инженер-разработчик (DSP-программист) и др.
У нас много интересных задач от автопроизводителей и концернов, двигающих индустрию. Если хотите расти, как специалист, и учиться у лучших, будем рады видеть вас в нашей команде. Также мы готовы делиться экспертизой, самым важным что происходит в automotive. Задавайте нам любые вопросы, ответим, пообсуждаем.
