Автоматические тз на статьи: Как сделать ТЗ на статью, чтобы получить максимум трафика — SEO на vc.ru

Содержание

Как сделать ТЗ на статью, чтобы получить максимум трафика — SEO на vc.ru

Как составить ТЗ для копирайтера? Что учесть в техническом задании, чтобы получить качественную статью? Рассказываем в статье.

8217 просмотров

Содержание:

Для чего нужно ТЗ

Выбор темы

Сбор семантики

Подготовка ТЗ для статьи

Заключение

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

Для чего нужно ТЗ

Наша задача — сделать так, чтобы статьи в блоге клиента нравились и читателям, и поисковым системам. Без правильного технического задания добиться этого очень сложно.

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

  • Общие требования к тексту (стиль, оформление, уникальность).
  • Тему.
  • Title, h2, Description.
  • Объем.
  • Требования к изображениям в статье.
  • Список ключевых слов.
  • Структуру статьи с заголовками h3 и h4.
  • Примеры статей конкурентов.

Это позволяет автору раскрыть тему в полном объеме. Набор простых и понятных требований делают коммуникацию с копирайтерами проще.

Выбор темы

Начинаем с выбора темы для будущей статьи. Для этого выясняем, что ищут пользователи в данной тематике. Используем сервис Keys.so, который помогает анализировать запросы и страницы конкурентов. Мы находим самые трафиковые материалы, изучаем их, собираем семантику и в итоге получаем список тем — темник.

Скрин темника

Затем определяем очередность написания. Ориентируемся на частотность главного ключа и показатель конкурентности по сервису Mutagen. Это важно, потому что выйти в топ по высокочастотным и высококонкурентным запросам молодому сайту будет сложно.

Сбор семантики

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

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

Пример: если пишем статью о продвижения бизнеса в Инстаграм — не подойдут статьи о продвижении личного аккаунта.

Полученный список статей анализируем в keys.so с помощью инструмента «Групповой отчет».

Выгружаем список запросов и чистим в Key Collector. Удаляем мусор, неявные дубли, низкочастотные запросы и запросы, которые не соответствуют теме статьи или целевой аудитории. Итоговый список запросов используем для ТЗ.

Подготовка ТЗ

Для создания ТЗ используем Semparser. Добавляем новый проект и загружаем наши запросы.

Из полученных групп запросов выбираем самую частотную и соответствующую теме. На ее основе автоматически формируем ТЗ.

Далее открываем шаблон и заполняем его на основе информации из Semparser.

Пример ТЗ для скачивания: https://docs.google.com/document/d/1rw1ezoNPp7QVX9CiWeFkaJ1VOoxx6CZ_2migLJM1_MY/edit?usp=sharing

Нам понадобятся:

Запросы. Запросы и количество их вхождений с вкладки «Тексты» из колонки таблицы «Встречается раз, среднее количество».

Средний объем статьи. Semparser показывает его в символах с пробелами.

Количество изображений в тексте. Считаем на основе топа выдачи на вкладке «ТЗ копирайтеру NEW».

План статьи. Для создания структуры анализируем заголовки и подзаголовки конкурентов, представленные на вкладке «ТЗ копирайтеру NEW». Важно, чтобы структура была последовательной и логичной, а заголовки — простыми и понятными. Помним про ЦА — не берем пункты конкурентов, которые рассчитаны на аудиторию, отличную от нашей.

Мета-теги. Составляем title, h2 и description на основе частотных поисковых запросов. Стараемся не дублировать заголовки конкурентов.

После того, как перенесли всю важную информацию из Semparser, заполняем шапку ТЗ.

  • Тип статьи — это формат контента. Информационная статья, подборка, текст услуги пишутся и оформляются по-разному.
  • Цель статьи. Автор должен понимать, для чего пишет текст.
  • Целевая аудитория.

Текст должен быть написан с учетом интересов целевой аудитории

  • О чем писать — указываем автору то, что нужно раскрыть обязательно, на что обратить особое внимание.
  • О чем писать не нужно — устанавливаем ограничения для автора, обозначаем аспекты темы, которые не стоит освещать.
  • Уникальность текста. Гарантирует, что автор не пришлет нам чужой текст, который уже был опубликован и проиндексирован. Значение этого показателя можно менять в зависимости от темы и специфики ниши. Например: в юридических текстах не обойтись без цитирования законов, из-за этого процент уникальности будет ниже.
  • Частотность повторяющихся фраз. В статье не должно быть переспама. Проверяем по ссылке на Semparser. Автору не придется регистрироваться, чтобы проверить текст в сервисе.

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

Заключение

Качественное ТЗ — это залог хорошей статьи. Оно помогает создавать контент, который нравится читателям и приносит трафик. Надеемся, что наш опыт был вам полезен. А как делаете ТЗ вы? Делитесь своим опытом в комментариям, задавайте вопросы.

Как написать ТЗ на запуск автоматических писем

Советы

Пишем ТЗ разработчику. В конце пример

Читайте наc в Telegram

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

Смотреть канал

Станьте email-рокером 🤘

Пройдите бесплатный курс и запустите свою первую рассылку

Подробнее

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

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

Но такой путь подойдёт не всегда. Иногда сервис не может реализовать сценарий: у него не хватает функционала или нужна слишком сложная интеграция.

Решить проблему можно 2 способами.

Подключить более продвинутый сервис рассылок.

Это дорого и долго — нужно переносить базу, настраивать все старые интеграции и только после этого подключать новую.

Настроить отправку писем своими силами, через CMS или CRM-систему. Этот способ дешевле, быстрее и проще. В CMS/CRM, которую мы используем на проекте, уже есть все нужные данные. Как правило, этот движок умеет отправлять письма — остаётся настроить нужный сценарий. Для этого нам понадобится помощь веб-программиста / студии, которая разрабатывала наш сайт или занимается его техподдержкой.

При этом мало просто поручить специалисту настройку триггерных писем. Чтобы получить хороший результат на выходе, нужно написать подробное техническое задание на внедрение (ТЗ).

В своей работе я пользуюсь следующей структурой ТЗ по каждому триггерному письму, которое собираюсь запустить:

Постановка задачи

Условия отправки

Момент отправки

Базовые настройки

Содержание письма

Динамический контент

Пример реализации

Поговорим о каждом разделе ТЗ подробнее, а в конце посмотрим на пример конкретного ТЗ, который можно использовать в качестве образца в работе.

Постановка задачи

Начинаем ТЗ, как водится, с общей постановки задачи:

запустить напоминание о брошенной корзине…

автоматически запрашивать отзыв после заказа…

предложить пользователю сопутствующие продукты…

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

Условия отправки

В данном разделе сообщим всё, что требуется, о том, при каких условиях мы хотим отправить письмо. Например, пользователь:

не продлил подписку на издание на следующий месяц…

сделал первый заказ, но не делает второй…

скачал брошюру «Шпаргалка по выбору цвета»…

Момент отправки

Если условие наступило, это не значит, что письмо должно уйти мгновенно.

Я предпочитаю обособлять это отдельным пунктом ТЗ, где конкретно описываю всё, что касается момента отправки:

  • сколько ждать после того, как все условия выполнены; 
  • в какое время запускать письмо, возможно, в какой день недели — по понедельникам, только в будни, только в выходные.

Например, письмо отправляется:

7-го числа каждого месяца, в 12:00 по мск…

через 30 дней после присвоения заказу статуса «Выполнен» (в то же самое время, в которое был присвоен статус)…

через 3 дня после скачивания брошюры, в 11:00 по мск (только будний день — если отправка приходится на выходной, сдвигаем на ближайшие понедельник)…

Базовые настройки

Почти в любой системе есть какой-то простой интерфейс для работы с письмами. 

Как правило в нём отдельными полями выносятся:

  • Email отправителя — с какого адреса будет отправлено письмо / куда присылать ответы.
  • Имя отправителя — содержание строки «От кого» (From) в почтовом клиенте.
  • Тема письма — содержание строки «Тема» (Subject line) в почтовом клиенте.

Тему, адрес и имя отправителя удобно прописать отдельно в ТЗ, в качестве «базовых» настроек.

Содержание письма

Даём ссылку на HTML-код письма. На мой взгляд, это принципиальный момент. Не стоит нагружать программиста ещё и «упаковкой» контента. Это специфическая работа, которую лучше или выполнить самому — на базе онлайн-конструктора писем — или поручить email-верстальщику.

Содержание письма, которое мы приводим в ТЗ, должно быть подготовлено по всем правилам вёрстки для email, корректно отображаться в разных почтовиках, адаптироваться на смартфонах.

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

Динамический контент

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

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

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

В ТЗ, в отдельном разделе я прописываю, что именно нужно подставлять вместо тегов:

{{Имя}} — подставляем имя пользователя (например, Сергей).

{{email}} — подставляем email-адрес пользователя, на который отправили рассылку.

{{ДД.ММ.ГГ}} — подставляем дату окончания действия промокода (например, 03.02.20).

Я рекомендую предусматривать ссылку отписки как элемент динамического контента.

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

Пример реализации

Также я добавляю в ТЗ конкретный пример, как задуманный сценарий должен срабатывать:

Часто это значительно упрощает понимание задачи и добавляет объёма к ТЗ.

Результат

На выходе мы получаем документ — в нём где-то по 2-3 страницы на каждое письмо:

Пример ТЗ на внедрение триггерных писем

Далее передаём его в работу программисту. Не пускаем дело на самотёк и активно сопровождаем внедрение — отвечаем на вопросы, возможно, что-то корректируем по ходу дела:

Затем принимаем результат. На тестирование и отладку писем лучше заложить отдельное время — это полноценная задача, которая требует нашего внимания. Даже если мы детально прописали всё в ТЗ, вряд ли задуманная механика заработает как нужно с первого раза. Скорее всего понадобится несколько циклов тестирования / исправления ошибок.

Во время тестов испытываем систему «на прочность», инициируя несколько событий одновременно, в разной последовательности, с разными условиями. Например, бросаем корзину, затем оформляем заказ, снова добавляем товары в корзину, но почти сразу удаляем их. Смотрим, какие письма нам в этом случае приходят.

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

Другие материалы по теме

Поделиться

СВЕЖИЕ СТАТЬИ

Другие материалы из этой рубрики

Не пропускайте новые статьи

Подписывайтесь на соцсети

Делимся новостями и свежими статьями, рассказываем о новинках сервиса

Статьи почтой

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

Оставляя свой email, я принимаю Политику конфиденциальности

Наш юрист будет ругаться, если вы не примете 🙁

Спасибо, ждите письмо.

Проверяйте почту — письмо придет в течение 5 минут (обычно мгновенно).

Как запустить email-маркетинг с нуля?

В бесплатном курсе «Rock-email» мы за 15 писем расскажем, как настроить email-маркетинг в компании. В конце каждого письма даем отбитые татуировки об email ⚡️

*Вместе с курсом вы будете получать рассылку блога Unisender

Оставляя свой email, я принимаю Политику конфиденциальности

Наш юрист будет ругаться, если вы не примете 🙁

ТЗ для копирайтера (часть 7)

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

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

Мы хорошо подготовились, но у нас нет статей. Даже если вы хорошо разбираетесь в выбранной тематике, но никогда не пробовали писать тексты с заданными ключевыми словами (по ТЗ для копирайтера), то не спешите брать в руки перо и бумагу. Закажите ваши первые 5-10 статей копирайтеру. Во-первых он напишет быстрее вас, а во-вторых вы не теряя времени начнете искать хорошего специалиста.

Не заказывайте все 10 статей сразу, одному копирайтеру. Дайте ТЗ нескольким копирайтерам и выберите лучшего, с которым и будете дальше работать. После выдачи ТЗ лучшему копирайтеру, со спокойной душой сядьте за написание своих текстов. Расчет на то, что пока вы пишите свои опусы, сайт уже можно наполнять заказным материалом, чтобы поисковикам было что индексировать.

Как составить ТЗ для копирайтера

Как пишут ТЗ большинство заказчиков?
  • вхождение ключей не более 4%
  • академическая тошнота до 12%
  • Кол-во символов: до 5000
  • уникальность: 95% по Адвего
Список ключей:
  • окрасы французских бульдогов
  • прикус у французского бульдога
  • стандарт французского бульдога
  • французский бульдог морда
  • хвост французского бульдога стандарт

Копирайтер будет сосредоточен на вписывание ключей и выполнение ваших требований, а не над написанием хорошей статьи.

Пример, как я пишу ТЗ для копирайтера:
  • Кол-во символов: до 5000
  • Уникальность: 95% по Адвего
  • Тема: Стандарт породы французского бульдога
Раскрыть темы:
  • Какие окрасы входят в стандарт породы?
  • Правильный прикус у …
  • Опишите стандарт для морды …
  • Опишите стандарт хвоста …
  • Стандарт ушей головы шерсти глаз

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

Что добавить в ТЗ при выборе кандидата?

  • Текст нужно разбить на абзацы до 7-ми предложений.
  • Пишите, опираясь на три источника, своими словами, не повторяя и не разбавляя фразы источников кучей прилагательных. Пишите, как школьное изложение на уроке русского языка.
  • Статьи с большим количеством бесполезных фраз и вводных слов, типа «Это очень важная тема в современном веб-дизайне, таким образом, эта тема занимает важное место на сайте», будут отправляться на доработку.
  • Пустые тексты, много льется воды в виде общих фраз, что-то типа «При правильном подходе, язык PHP можно выучить за короткий промежуток времени и использовать для создания сайтов». Кто бы сомневался? Капитан очевидность.

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

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

Где заказывать контент

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

  • contentmonster.ru
  • text.ru
  • fl.ru

Проверить уникальность текста

Я, по личному опыту знаю, что 100% уникальности очень трудно добиться, когда в статье идут вставки из кусков кода какого-нибудь языка программирования. В таких случаях, мне приходится, писать код на codepen.io и вставлять через embed в статью. Тексты без примеров кода, со своей структурой деления на абзацы и написанные своими словами, всегда получаются уникальными на 100%. Я проверяю свои опусы на сервисе-лидере среди подобных программ — text.ru.

Показатели SEO-анализа

Топ 5 должен состоять из ключевых слов, по которым мы продвигаемся:

  • как составить ТЗ для копирайтера
  • пример ТЗ для копирайтера
  • ТЗ для копирайтера

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

Роботы ориентируются на плотность ключевых слов при выдаче в топе. Нельзя превышать показатель воды выше 30% и заспамленность больше 60%, поисковик не допустит такую страницу в индекс.

Заключение

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

  • Создано 24.12.2018 10:14:29
  • Михаил Русаков

Копирование материалов разрешается только с указанием автора (Михаил Русаков) и индексируемой прямой ссылкой на сайт (http://myrusakov.ru)!

Добавляйтесь ко мне в друзья ВКонтакте: http://vk.com/myrusakov.
Если Вы хотите дать оценку мне и моей работе, то напишите её в моей группе: http://vk.com/rusakovmy.

Если Вы не хотите пропустить новые материалы на сайте,
то Вы можете подписаться на обновления: Подписаться на обновления

Если у Вас остались какие-либо вопросы, либо у Вас есть желание высказаться по поводу этой статьи, то Вы можете оставить свой комментарий внизу страницы.

Если Вам понравился сайт, то разместите ссылку на него (у себя на сайте, на форуме, в контакте):

TK Автоматические и ручные правила распределения рабочих заданий: Поддержка

СОДЕРЖАНИЕ

  • Кому может быть предложено вручную распределить свой день?
  • Как определить, является ли сотрудник не-GPS или GPS?
  • Сотрудникам разрешено распределять: когда они должны?
  • Что побуждает сотрудников к распределению?
    • Условия, необходимые для автоматического распределения
    • Правило «1 площадка, 2 рабочих задания»

Сотруднику может быть предложено вручную распределить свой день, только если для него настроена роль «Требуется распределение WO». Проверьте карточку входа сотрудника для сотрудника.

Правила распределения различаются для сотрудников GPS и не-GPS.

2 критерия, оба из которых необходимы, чтобы Сотрудник не имел GPS :

  • Роль «Фиксированное местоположение»
  • Устройство «Стена» или «Без GPS», зарегистрированное и используемое в мобильном приложении FCX.

Сотрудники GPS по умолчанию. Сотрудник может иметь GPS только в том случае, если у него нет ни того, ни другого:

  • Зарплата
  • Фиксированное местоположение

Актив не может быть идентифицирован с помощью имени / номера телефона Сотрудника. Если это не так, проверьте его или ее недавний ввод времени для устройства.

  Если Актив имеет категорию Актива «Настенное устройство» или «Без GPS», Сотрудник не является Сотрудником GPS.  
  • Сотрудникам без GPS с этой ролью ВСЕГДА предлагается вручную распределить свой день.
  • GPS Сотрудникам с этой ролью ИНОГДА предлагается вручную распределить свой день.

Сотрудникам, не использующим GPS, всегда предлагается выделить , если у них есть роль «Требуется распределение WO» в их карточке входа.

2 исключения:

  • TAR за день ожидает рассмотрения.
  • День был предварительно введен TKA как нерабочий.

Сотруднику GPS предлагается распределить  день при соблюдении нескольких условий:

  • Им назначена роль «Требуется выделение WO» на их карточке входа.
  • TAR за день НЕ ожидает рассмотрения.
  • День НЕ был предварительно введен TKA как выходной.
  • Если какое-то время дня не может быть выделено автоматически.

Условия, необходимые для автоматического распределения

Когда / при каких условиях может быть автоматически распределено время:

  1. GPS сотрудник
  2. Радиус геозоны > 0 м
  3. За указанный период времени были собраны адекватные данные GPS. (Слишком большой разрыв в данных может помешать экстраполяции.)
  4. Устройство остановилось внутри известной геозоны Зоны.

Когда и при каких условиях время НЕ может быть распределено автоматически:

  1. Сотрудник, не использующий GPS, никогда не может быть назначен автоматически.
  2. Радиус геозоны площадки = 0 м
  3. Неадекватные данные GPS из-за проблем с:
    • Плохой сигнал
    • Разряд батареи (несоблюдение политики батареи сотрудником)
    • Приложение принудительно закрыто, телефон долгое время не работает.
  4. Устройство НЕ остановилось внутри геозоны.
  5. Более 1 WO запланировано для одного и того же сайта для данного сотрудника и дня.
  6. Сотрудник GPS с ролью «Не диспетчер».

Роль «Без отправки»

Существует еще одна «Роль» входа, кроме «Фиксированное местоположение», которая влияет на распределение: «Без отправки». Несмотря на название, «недиспетчерские» сотрудники могут быть отправлены, но это не обязательно.

Обычно недиспетчерские сотрудники также не используют GPS, но не всегда.

  Если Сотрудник работает с GPS И Без Отправки, его Складское Время НЕ будет распределяться автоматически, и ему придется распределять его вручную!  

Правило «1 сайт, 2 заказа на работу»

Время НЕ МОЖЕТ быть назначено автоматически, если 2 ТО ЖЕ ОБЪЕКТ и день для Emp.  Система требует ручного ввода того, сколько времени должно идти на один WO по сравнению с другим.

Время STILL Автоматически назначается для ПЕРЕКРЫТИЯ геозон для одинакового времени и Emp.

В системе есть способ угадать, какое перекрывающееся место относится к зарегистрированной остановке:

  1. Система измеряет среднее расстояние от допустимых точек остановки до центров геозон Мест, применимых к временному блоку.
  2. Создает список приоритетов на основе расстояния.
  3. Место с наибольшим количеством точек остановки выделяется.
  ПРИМЕЧАНИЕ
   Если время на месте прерывается из-за привода, WH и т. д., каждый блок времени на месте оценивается отдельно для определения распределения.  

Уполномоченный сотрудник GPS ВСЕГДА выделяет, если ни одна геозона не нарушена.

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

Уполномоченный сотрудник GPS НИКОГДА не будет выделять, если нарушена только одна геозона.

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

 ВАЖНО
Даже если второй WO был опубликован сотруднику за данный день, у него НЕ будет возможности выделить его вручную, если он нарушил только одну геозону. 

GTDB-Tk: набор инструментов для классификации геномов с помощью базы данных таксономии геномов | Биоинформатика

Журнальная статья

Пьер-Ален Шомей,

Пьер-Ален Шомей

Ищите другие работы этого автора на:

Оксфордский академический

пабмед

Google ученый

Аарон Дж. Массиг,

Аарон Дж. Массиг

Ищите другие работы этого автора на:

Оксфордский академический

пабмед

Google ученый

Филип Хугенгольц,

Филип Гугенгольц

Ищите другие работы этого автора на:

Оксфордский академический

пабмед

Google ученый

Донован Х Паркс

Донован Х Паркс

Ищите другие работы этого автора на:

Оксфордский академический

пабмед

Google ученый

Биоинформатика , Том 36, Выпуск 6, 15 марта 2020 г., Страницы 1925–1927, https://doi.org/10.1093/bioinformatics/btz848

Опубликовано:

15 ноября 2019 г.

История статьи

Получен:

12 июля 2019 г.

Полученная ревизия:

15 октября 2019 г.

Принято:

13 ноября 2019

Опубликовано:

15 ноября 2019

  • PDF

  • Разделенный вид
    • Содержание статьи
    • Рисунки и таблицы
    • видео
    • Аудио
    • Дополнительные данные
  • Цитировать

    Cite

    Пьер-Ален Шомей, Аарон Дж. Массиг, Филип Хьюгенгольц, Донован Х. Паркс, GTDB-Tk: набор инструментов для классификации геномов с помощью базы данных таксономии геномов, Биоинформатика , том 36, выпуск 6, 15 марта 2020 г., Страницы 1925–1927, https://doi.org/10.1093/bioinformatics/btz848

    Выберите формат Выберите format.ris (Mendeley, Papers, Zotero).enw (EndNote).bibtex (BibTex).txt (Medlars, RefWorks)

    Закрыть

  • Разрешения

    • Электронная почта
    • Твиттер
    • Фейсбук
    • Подробнее

Фильтр поиска панели навигации БиоинформатикаЭтот выпускЖурналы по биоинформатикеБиоинформатика и вычислительная биологияКнигиЖурналыOxford Academic Термин поиска мобильного микросайта

Закрыть

Фильтр поиска панели навигации БиоинформатикаЭтот выпускЖурналы по биоинформатикеБиоинформатика и вычислительная биологияКнигиЖурналыOxford Academic Термин поиска на микросайте

Расширенный поиск

Резюме

Резюме

Инструментарий базы данных таксономии генома (GTDB-Tk) обеспечивает объективное таксономическое распределение геномов бактерий и архей на основе GTDB. GTDB-Tk эффективен в вычислительном отношении и способен параллельно классифицировать тысячи черновиков геномов. Здесь мы демонстрируем точность таксономических назначений GTDB-Tk, оценивая его эффективность на филогенетически разнообразном наборе из 10 156 геномов, собранных метагеномами бактерий и архей.

Доступность и реализация

GTDB-Tk реализован на языке Python и распространяется под лицензией GNU General Public License v3.0. Исходный код и документация доступны по адресу: https://github.com/ecogenomics/gtdbtk.

Дополнительная информация

Дополнительные данные доступны по адресу Bioinformatics онлайн.

1 Введение

Недавно стало возможным получить тысячи образцов бактериальных и архейных геномов непосредственно из образцов, связанных с окружающей средой и человеком (Anantharaman и др. , 2016; Паркс и др. , 2017; Пасолли и др. , 2019). Точная таксономическая классификация таких геномов является основным требованием для их анализа и существенным условием для облегчения коммуникации в исследовательском сообществе (Godfray, 2002). Обычно это достигается путем ручной проверки размещения геномов в филогениях 16S рРНК или связанных белков, а также статистики процента идентичности 16S рРНК или средней идентичности нуклеотидов (ANI; Konstantinidis and Tiedje, 2005) для поддержки отнесения к определенным таксономическим рангам. Это трудоемкая и субъективная работа (Катушка и др. , 2019), и не хватает специализированных инструментов для классификации геномов, за исключением PhyloPhlAn (Segata et al. , 2013) и MiGA (Rodriguez-R et al. , 2018), которые в настоящее время на основе таксономии NCBI (Federhen, 2015). Здесь мы представляем набор инструментов базы данных таксономии генома (GTDB-Tk), эффективный в вычислительном отношении набор инструментов, который обеспечивает автоматическую и объективную таксономическую классификацию бактериальных и архейных геномов, помещая их в доменно-специфичные конкатенированные эталонные деревья белков. GTDB-Tk определяет таксономические классификации, согласующиеся с недавно предложенной таксономией GTDB, нормализованной по рангу, используя те же критерии относительной эволюционной дивергенции (RED) и ANI для установления таксономических рангов (Parks и др. , 2018, 2019).

2 Материалы и методы

2.1 Эталонные деревья и таксономии

GTDB-Tk использует эталонные деревья бактерий и архей, множественные выравнивания последовательностей и таксономию, предоставленные на веб-сайте GTDB (gtdb.ecogenomic.org). GTDB обновляется два раза в год, чтобы включить последние геномы в базу данных NCBI Assembly (Kitts et al. , 2016), и GTDB-Tk следует этому циклу обновления. Представленные здесь результаты основаны на GTDB-Tk v0.3.2 и GTDB R04-RS89.где эталонные деревья охватывают 23 458 видов бактерий и 1248 видов архей.

2.2 Размещение геномов в эталонных деревьях

GTDB-Tk принимает сборки геномов в виде файлов FASTA, называет гены с помощью Prodigal (Hyatt et al. , 2010) и идентифицирует набор из 120 бактериальных и 122 архейных маркерных генов с помощью HMMER (Eddy, 2011), как описано ранее (Parks et al. , 2018). Геномы присваиваются домену с наибольшей долей идентифицированных маркерных генов. Выбранные специфичные для домена маркеры выравниваются с помощью HMMER, объединяются в одно множественное выравнивание последовательностей и обрезаются с помощью маски бактерий или архей примерно на 5000 столбцов, используемой GTDB. Затем геномы помещаются в референсные деревья доменов с помощью pplacer (Matsen и др. , 2010).

2.3 Таксономическая классификация

Классификация генома запроса основана на сочетании его положения в справочном дереве GTDB, его RED (Parks et al. , 2018) и его ANI относительно эталонных геномов (рис. 1 и Дополнительный рис. S1). Во многих случаях классификация генома запроса очевидна из топологии дерева (рис. 1a и b). RED используется для разрешения случаев, когда присвоение рангов неоднозначно (рис. 1c и d). Отнесения видов устанавливаются с использованием ANI, рассчитанного с помощью FastANI (Jain 9). 0050 и др. , 2017). В частности, геном запроса, помещенный в пределах рода, назначается виду ближайшего эталонного генома с долей выравнивания> 65%, если он находится в пределах радиуса охвата ANI этого вида (обычно 95%), как определено GTDB (рис. 1e). ;Parks и др. , 2019). В противном случае геном запроса классифицируется как новый вид внутри рода.

Рис. 1.

Открыть в новой вкладкеСкачать слайд

Наглядные примеры таксономических назначений GTDB-Tk. ( a ) Одно только положение запрашиваемого генома в эталонном дереве может быть достаточным для определения его таксономического назначения, как в этом примере, где он обязательно является новым типом. ( b ) Запрос генома представляет новый класс внутри типа Actinobacteria. ( c ) Геном запроса будет классифицирован либо как новый, базальный вид Escherichia , либо как новый род в семействе Enterobacteriaceae в зависимости от его значения RED. ( d ) Аэрофобия — единственный класс в пределах типа Aerophobetota, и поэтому геном запроса может быть классифицирован как самый базовый порядок в Aerophobetota, новый класс в пределах Aerophobetota или новый тип в зависимости от его значения RED. ( e ) ANI рассчитывается между геномом запроса и репрезентативными геномами для всех видов Staphylococcus . Геном запроса присваивается ближайшим видам Staphylococcus , если ANI превышает радиус охвата вида ANI или иным образом классифицируется как новый вид.

2.4 Требования

GTDB-Tk предназначен для работы на сервере с несколькими процессорами и ≥128 ГБ оперативной памяти. Он может классифицировать около 1000 геномов в час при использовании 64 процессоров. Мы рекомендуем применять GTDB-Tk к геномам, которые, по оценкам, полны на ≥50% с контаминацией ≤10% в соответствии со стандартами сообщества для однократно амплифицированных и метагеномных геномов среднего или высокого качества (MAG; Bowers и др. , 2017).

3 Результаты

Здесь мы оцениваем точность классификации GTDB-Tk, применяя ее к набору из 10 156 филогенетически разнообразных бактериальных (9386 геномов) и архейных (770 геномов) MAG разного геномного качества, которые были отобраны вручную в GTDB R04. -РС89. Эти геномы включают набор данных некультивируемых бактерий и архей (UBA; Parks et al. , 2017) и его расширение, выпущенное как часть GTDB. Эффективность классификации GTDB-Tk оценивалась с использованием выведенных эталонных деревьев de novo без геномов UBA, в результате чего MAG представляют новые таксоны во всех таксономических рангах (таблица 1). На классификацию этих MAG ушло 14 часов с использованием 32 процессоров Intel Xeon E5-2650 с тактовой частотой 2,30 ГГц и 100 ГБ оперативной памяти. Из 10 156 MAG 1071 (10,6%) не имели идентичных классификаций GTDB-Tk и GTDB (таблица 1 и дополнительные таблицы S1–S3). Однако только 8 (0,08%) MAG были помещены в эталонное дерево в положение, приводящее к конфликту между назначениями GTDB и GTDB-Tk (например, семейство Cycloclasticaceae против Methylomonadaceae; дополнительный рисунок S2). GTDB-Tk предсказал как минимум на один ранг больше, чем ожидалось, для 644 (6,34%) MAG (переклассифицированных; например, o__ Methylococcales; f__Methylomonadaceae, хотя MAG принадлежит к новому семейству в GTDB; дополнительные рисунки S2 и S3) и по крайней мере один меньше ранга, чем ожидалось для 419(4,13%) MAG (недоклассифицированные; например, c__Anaerolineae; o__[новый порядок], хотя MAG принадлежит к o__Anaerolineales, отряду, представленному в справочном дереве de novo GTDB; дополнительный рисунок S4). По оценкам, геномы UBA заполнены на ≥50% с загрязнением ≤10%, и систематической ошибки не наблюдалось в чрезмерной и недостаточной классификации в зависимости от качества генома (дополнительная рис. S5). Поскольку размещение геномов в эталонном дереве не является детерминированным, мы исследовали воспроизводимость таксономических назначений на случайных подмножествах 100 геномов UBA. Ни один из геномов UBA не имел другого таксономического назначения в 50 независимых испытаниях (дополнительная таблица S4).

Таблица 1.

Эффективность классификации в наборе геномных данных 10 156 UBA с указанием самого низкого ранга, для которого классификации, соответствующие назначениям GTDB, могут быть получены с помощью GTDB-Tk

044450445044450444504445044445044450444504444444щей0 9049. 0450
Ранг . № Геномы UBA . Идентичный . Конфликтующие . Сверхклассифицированный a . Низкоклассифицированный б .
Domain  20  15.0%  0%  85.0%  0% 
Phylum  56  69.6%  0%  28.6%  1.79%
Класс 130 56,2% 0% 40,8% 3,08%
9504509450945044444444444444444444444444444444444444444444444444444444444444444444444444445н
0.45%  32.4%  8.14% 
Family  1788  71.8%  0.22%  21.6%  6.42% 
Genus  3927  92.6%  0,05% 0,74% 6,60%
виды 3793 99,9% 0% 0%99,9% 0% 0%99,9% 0% 0%99,9% 0% 0%99,9.10 156 89,5% 0,08% 6,34% 4,13%

6 Ранг . № Геномы UBA . Идентичный . Конфликтующие . Сверхклассифицированный a . Недоклассифицированный b . Домен  20  15.0%  0%  85.0%  0%  Phylum  56  69. 6%  0%  28.6%  1.79%  Class  130 56.2%  0%  40.8%  3.08%  Order  442  59.1%  0.45%  32.4%  8.14%  Family  1788  71.8%  0.22%  21.6%  6.42%  Genus  3927  92.6%  0.05%  0.74%  6.60%  Species  3793  99.9%  0%  0%  0.11%  Total  10 156  89.5%  0.08%  6.34%  4.13% 

a

GTDB-Tk предоставляет более четкие классификации, чем GTDB (дополнительные рисунки S2 и S3).

b

GTDB-Tk обеспечивает классификацию с меньшим разрешением, чем GTDB (дополнительный рисунок S4).

Открыть в новой вкладке

Таблица 1.

Эффективность классификации в наборе геномных данных 10 156 UBA с указанием самого низкого ранга, для которого классификации, соответствующие назначениям GTDB, могут быть получены с помощью GTDB-Tk

950
Ранг . № Геномы UBA . Идентичный . Конфликтующие . Сверхклассифицированный a . Недоклассифицированный b .
Домен 20 15,0% 0% 85,0% 0%
0%
0 0%
0 0%
0%50 0% 950% 0%.0450 56  69.6%  0%  28.6%  1.79% 
Class  130  56. 2%  0%  40.8%  3.08% 
Order  442  59.1%  0.45%  32.4%  8.14% 
Family  1788  71.8%  0.22%  21.6%  6.42% 
Genus  3927  92.6%  0.05%  0.74%  6.60% 
Species  3793  99.9%  0%  0%  0.11% 
Total  10 156  89.5%  0.08%  6.34%  4.13% 

Rank . № Геномы UBA . Идентичный . Конфликтующие . Сверхклассифицированный a . Недоклассифицированный b .
Domain  20  15.0%  0%  85.0%  0% 
Phylum  56  69.6%  0%  28.6%  1.79%
Class  130  56.2%  0%  40.8%  3.08% 
Order  442  59.1%  0.45%  32.4%  8.14% 
Family 1788  71.8%  0.22%  21.6%  6.42% 
Genus  3927  92.6%  0.05%  0.74%  6.60% 
Species  3793  99.9%  0%  0%  0.11% 
Total  10 156  89.5%  0.08%  6.34%  4. 13% 

a

GTDB-Tk предоставляет более точные классификации, чем GTDB (дополнительные рисунки S2 и S3).

b

GTDB-Tk обеспечивает классификацию с меньшим разрешением, чем GTDB (дополнительный рисунок S4).

Открыть в новой вкладке

На предполагаемые эволюционные отношения влияет набор рассматриваемых таксонов (Nabhan and Sarkar, 2012). Это, естественно, приводит к некоторой степени чрезмерной и недостаточной классификации при рассмотрении геномов UBA по отдельности в соответствии с GTDB-Tk, а не как полный набор геномов в соответствии с классификациями GTDB (дополнительный рисунок S6). Чрезмерная и недостаточная классификация также происходит в результате различий между строгими количественными правилами, применяемыми GTDB-Tk, и таксономическим мнением кураторов GTDB, которые используют относительно широкий диапазон RED для руководства классификациями (Parks 9). 0050 и др. , 2018). Например, кураторы GTDB могут решить определить два класса, даже если объединение их в один класс приведет к тому, что значение RED будет ближе к среднему RED для таксонов уровня класса (дополнительный рисунок S7A). Это происходит по ряду причин, включая предпочтение отнесения таксонов к узлам с высокими значениями поддержки и приоритет сохранения установленных названий таксонов. Обратная ситуация также возникает, когда ручное курирование может определить один таксон, что приводит к недоклассификации классификаций GTDB-Tk по сравнению с GTDB (дополнительный рисунок S7B).

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

Общий результат сравнительного анализа заключается в том, что классификации GTDB-Tk в значительной степени соответствуют ручному курированию (89,5%), особенно на более низких рангах. Важно отметить, что подавляющее большинство разногласий ограничивается разницей в одном ранге (1057 из 1071 случая; 98,7%). Тем не менее, исследования, в первую очередь связанные с выяснением эволюционных отношений или поддержкой таксономической переклассификации, должны использовать GTDB-Tk в качестве руководства для проведения дополнительных анализов, составляющих передовую практику в этой области.

4 Резюме

GTDB-Tk служит удобным средством для исследовательского сообщества для классификации растущего числа микробных геномов, извлеченных из наборов метагеномных данных. Он уже прошел независимую и положительную оценку для классификации MAG (Coil et al. , 2019) и доступен в качестве онлайн-ресурса через KBase (Arkin et al. , 2018) в дополнение к тому, что он является отдельным инструментом. . GTDB-Tk будет служить основой для классификации новых геномов, включенных в будущие выпуски GTDB, при этом кураторы будут принимать альтернативные классификации только в том случае, если они учитывают известные нестабильности в предполагаемых эталонных деревьях или придерживаются таксономического мнения исследовательских групп, вносящих предложения, которые, хотя и не соответствуют соответствии с GTDB-Tk, удовлетворяют более широким критериям классификации, лежащим в основе GTDB.

Благодарности

Мы благодарим первых пользователей GTDB-Tk за их отзывы и вклад.

Финансирование

Эта работа была поддержана стипендией лауреата Австралийского исследовательского совета [FL150100038 to P. H.].

Конфликт интересов : не объявлено.

Ссылки

Анантараман

К.

и др. (

2016

)

Тысячи микробных геномов проливают свет на взаимосвязанные биогеохимические процессы в системе водоносных горизонтов

.

Нац. Коммуна

.,

7

,

13219

.

Аркин

А.П.

и др. (

2018

)

KBase: База знаний по биологии Министерства энергетики США

.

Нац. Биотехнолог

.,

36

,

566

.

Бауэрс

Р.М.

и др. (

2017

)

Минимальная информация об одном амплифицированном геноме (MISAG) и геноме, собранном на основе метагенома (MIMAG) бактерий и архей

.

Нац. Биотехнолог

.,

35

,

725

731

.

Катушка

D.A.

и др. (

2019

)

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

.

PLoS One

,

14

,

e0214354

.

Эдди

С.Р.

(

2011

)

Ускоренный поиск профиля HMM

.

Вычисл. PLoS. Биол

.,

7

,

е1002195

.

Федерхен

С.

(

2015

)

Типовой материал в таксономической базе данных NCBI

.

Рез. нуклеиновых кислот

.,

43

,

D1086

D1098

.

Годфрей

Х.К.Дж.

(

2002

)

Проблемы таксономии

.

Природа

,

417

,

17

19

.

Hyatt

D.

и др. (

2010

)

Prodigal: распознавание прокариотических генов и идентификация сайта инициации трансляции

.

Биоинформатика BMC

,

11

,

119

.

Джайн

С.

и др. (

2017

)

Высокопроизводительный анализ ANI 90 тыс. геномов прокариот выявляет четкие границы видов

.

Нац. Коммуна

. ,

9

,

5114

.

Китс

П.А.

и др. (

2016

)

Сборка: ресурс для собранных геномов в NCBI

.

Рез. нуклеиновых кислот

.,

44

,

D73

D80

.

Константинидис

К.Т.

,

Тиедже

Дж. М.

(

2005

)

Анализ генома, расширяющий определение вида прокариот

.

Проц. Натл. акад. науч. США

,

102

,

2567

2572

.

Матсен

Ф.

и др. (

2010

)

pplacer: максимальное правдоподобие линейного времени и байесовское филогенетическое размещение последовательностей на фиксированном эталонном дереве

.

Биоинформатика BMC

,

11

,

538

.

Набхан

А.Р.

,

Саркар

И.Н.

(

2012

)

Влияние выборки таксонов на филогенетические выводы: обзор двух десятилетий споров

.

Краткая информация. Биоинформ

.,

13

,

122

134

.

Парки

D.H.

и др. (

2017

)

Восстановление почти 8 000 метагеномных геномов существенно расширяет древо жизни

.

Нац. Микробиол

.,

2

,

1533

1542

.

Парки

D.H.

и др. (

2018

)

Стандартизированная таксономия бактерий, основанная на филогении генома, существенно пересматривает древо жизни

.

Нац. Биотехнолог

.,

36

,

996

1004

.

Парки

D.H.

и др. (

2019

)

Выбор репрезентативных геномов для 24 706 кластеров видов бактерий и архей обеспечивает полную таксономию на основе генома

.

bioRxiv

,

771964

, doi: https://doi.org/10.1101/771964.

Pasolli

E.

и др. (

2019

)

Обширное неисследованное разнообразие микробиома человека, выявленное более чем 150 000 геномов из метагеномов, охватывающих возраст, географическое положение и образ жизни

.

Ячейка

,

176

,

649

662

.

Rodriguez-R

LM

и др. (

2018

)

Веб-сервер «Атлас микробных геномов» (MiGA): анализ таксономического и генетического разнообразия архей и бактерий на уровне всего генома

.

Рез. нуклеиновых кислот

.,

46

,

W282

W288

.

Segata

N.

и др. (

2013

)

PhyloPhlAn — новый метод улучшенного филогенетического и таксономического распределения микробов

.

Нац. Коммуна

.,

4

,

2304

.

© Автор(ы), 2019. Опубликовано Oxford University Press.

Это статья в открытом доступе, распространяемая в соответствии с лицензией Creative Commons Attribution License (http://creativecommons.org/licenses/by/4.0/), которая разрешает неограниченное повторное использование, распространение и воспроизведение на любом носителе при условии, что оригинальная работа правильно цитируется.

© Автор(ы), 2019. Опубликовано Oxford University Press.

Раздел выдачи:

Геномный анализ

Помощник редактора: Джон Хэнкок

Джон Хэнкок

Ассоциированный редактор

Ищите другие работы этого автора на:

Оксфордский академический

пабмед

Google ученый


Скачать все слайды

  • Дополнительные данные

  • Дополнительные данные

    btz848_Supplementary_Data — zip файл

    Реклама

    Цитаты

    Просмотры

    31 582

    3 Альтметрика

    3 Дополнительная информация о метриках

    Оповещения по электронной почте

    Оповещение об активности статьи

    Предварительные уведомления о статьях

    Оповещение о новой проблеме

    Получайте эксклюзивные предложения и обновления от Oxford Academic

    Ссылки на статьи по номеру

    • Последний

    • Самые читаемые

    • Самые цитируемые

    scSemiGAN: полуконтролируемая структура аннотации и уменьшения размерности с одной ячейкой на основе генеративно-состязательной сети

    statgenMPP: пакет R, реализующий подход смешанной модели на основе IBD для картирования QTL в широком диапазоне популяций с несколькими родителями

    Изучение вложений временной разницы для создания биомедицинских гипотез

    wenda_gpu: быстрая адаптация домена для геномных данных

    WMSA: новый метод множественного выравнивания последовательностей ДНК

    Младший научный сотрудник

    Нью-Хейвен, Коннектикут

    Врач-инфекционист

    Брисбен, Другое / Не США

    АССИСТЕНТ или АССОЦИИРОВАННЫЙ ПРОФЕССОР: Отдел эпидемиологии, Департамент здоровья населения

    Нью Йорк, Нью Йорк

    Научный сотрудник, профессор эпидемиологии

    Новый Орлеан, Луизиана

    Посмотреть все вакансии

    Реклама

    Автоматическое сопряжение устройств Bluetooth LE

    Твиттер LinkedIn Фейсбук Эл. адрес

    • Статья
    • 3 минуты на чтение

    Windows 10 поддерживает автоматическое сопряжение периферийных устройств LE Bluetooth с одним ПК после подготовки и включения всех устройств в процессе производства. Пользователям не нужно держать устройства LE сопряженными и подключенными после того, как главный ПК и связанные устройства впервые получат питание. Эти периферийные устройства по-прежнему можно использовать как обычные устройства Bluetooth и сохранять полную функциональность, когда они находятся вне зоны действия хост-компьютера. Однако, если периферийные устройства не сопряжены и находятся в пределах досягаемости главного ПК, они автоматически повторно сопрягаются и подключаются.

    Когда на периферийное устройство LE, поддерживающее эту функцию, подается питание в первый раз, оно отправляет проприетарные данные, определенные Microsoft, в ненаправленном рекламном объявлении с возможностью подключения. Эта реклама затем подхватывается хост-компьютером. Если устройство находится в пределах досягаемости и его реклама соответствует шаблону, предварительно созданному на хост-компьютере во время производства, то устройство сопряжено. Это осуществляется через внешнее сопряжение, в котором используется отдельный секретный ключ OOB, который также был предварительно подготовлен. Расстояние от хост-компьютера, на котором может выполняться сопряжение периферийных устройств, определяется другим предварительно заданным минимальным значением RSSI, которое представлено в дБ, поэтому диапазоны могут различаться. Все предварительно подготовленные данные должны храниться в UEFI, чтобы сохранить эту функциональность при чистой установке и восстановлении системы.

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

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

    Требования к функциям

    ПК

    • Юбилейное обновление Windows 10
    • Хранимые переменные UEFI
    • Определенные корпорацией Майкрософт команды Bluetooth HCI для оптимизации времени автономной работы.

    Периферийное устройство

    • Bluetooth LE
    • Сохранение идентификатора устройства (хешированного из адреса Bluetooth) и значения TK
    • Пользовательское объявление (определение приведено ниже)

    UEFI на хост-компьютере

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

    Для каждого устройства, поддерживающего автоматическое сопряжение, хост-компьютер должен запрограммировать в NVRAM следующую информацию OOB:

     const unsigned long BTH_LE_DEVICE_ID_SIZE = 8;
    # пакет прагмы (push, 1)
    структура typedef
    {
        СИМВОЛ RssiПорог;
        UCHAR DeviceId[BTHLE_PREPAIRING_DEVICE_ID_SIZE];
        УЧАР SmpTK[16]; // Максимальный размер ТК
    } BTHLE_PREPAIRING_ENTRY;
    #pragma pack (поп)
     

    Определение общедоступного интерфейса UEFI NVRAM

     static const LPWSTR BTH_LE_PREPAIRING_NVRAM_VAR_NAME = L"BluetoothPairingInfo";
    статическая константа LPWSTR BTH_LE_PREPAIRING_NVRAM_VAR_GUID = L"{3C

    8-0243-4778-8ADC-BC2D3C6E6B0E}";

    Рекламное расположение периферийных устройств

    Тип секции [1 байт] Производитель [2 байта] MsftSectionType [4 байта] Идентификатор устройства [8 байт]
    0xff (зависит от поставщика) 0x0006 (MSFT) 0x00000004 (Подготовка) идентификатор устройства

    Вопросы безопасности

    Во время производства

    Существует вероятность атаки «Человек посередине», если будут получены данные обеспечения.

    Добавить комментарий

    Ваш адрес email не будет опубликован. Обязательные поля помечены *