Что такое «интерфейс» и «протокол»?

   25.02.2016    Нет комментариев    Рубрика: Основы автоматики

Понятия «Протокол» и «Интерфейс» неразрывно связаны друг с другом, именно поэтому их так часто путают не только новички, но и опытные специалисты в области IT-технологий. Эти термины используются всегда, когда речь идёт о передаче данных. Причём, не важно, какой обмен данными имеется в виду, это может быть обмен между приложениями, устройствами, между человеком и компьютером – во всех этих случаях мы имеем дело с «интерфейсом» и «протоколом». Однако не многие могут дать внятный ответ на вопрос: «в чём разница между этими понятиями?», попросту путают эти термины или считают их синонимами. В данной статье мы постараемся раз и навсегда внести ясность в этот вопрос.

Для начала дадим определения.

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

д.

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

Сложно? На самом деле всё проще, чем кажется. Давайте разбираться!

Что такое интерфейс

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

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

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

Как вы понимаете, чтобы организовать обмен данными по какому-либо интерфейсу, необходимо чтобы все участники взаимодействия обладали этим интерфейсом: для того, чтобы написать другу по электронной почте – нужно, чтобы у него был e-mail, а для того чтобы управлять беспроводным пылесосом, нужен пульт.

Интерфейс может содержать в себе другие интерфейсы. Когда мы говорим про передачу сообщения обычной почтой, мы говорим про один интерфейс. Но на самом деле наше письмо может доставляться поездом, самолётом, автотранспортом – это тоже интерфейсы, но они «скрыты» от нас, мы никак не участвуем в их выборе, поэтому для нас это один интерфейс «Почта России».

Что такое протокол

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

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

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

Заключение

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

Получается своеобразная «матрёшка» из данных, которая потом «разбирается» обратно до исходного сообщения, которое и получает адресат.

На этом всё! Надеемся, что было интересно! До встречи на страницах LAZY SMART.

Чтобы не пропустить новую статью, вступай в нашу группу Вконтакте, а также подписывайся на наш канал YouTube.

   Tags: интерфейс, Протокол

---

Интерфейсы/протоколы для начинающих / Хабр

1. Введение

Тема интерфейсов часто сбивает с толку начинающего разработчика. При первом знакомстве они кажутся странным излишком, ненужным при наличии наследования у классов. Зачем с помощью интерфейсов описывать класс в одном месте, чтобы написать его в итоге в другом? В дальнейшем буду описывать всё для языка Swift, где интерфейсы принято называть «протоколы», но логика в остальном не сильно отличается, синтаксис будет понятен при начальных знаниях любого другого языка.

Протоколы не просто про «костяк класса». Идейная их суть в том, чтобы выдвигать конкретные требования к классам и давать за это взамен возможность модульно работать с этим классом на чуть более высоком уровне абстракции.

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

2. Теоретический пример для самых маленьких

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

• Заводим класс Птица

• Определяем свойство «Имя» типа String

• Определяем функцию «Спой» сигнатуры ()->(), т. е. ничего не принимает, ничего не возвращает, внутри только print(текстПесни)

• Определяем инициализатор

• Готово! Можно проводить концерт! Делаем массив Птиц и каждую птичку зовём на сцену циклом for-in

Но что, если для некоторых мы хотим в ином контексте иной функциональности? Может некоторые хотят спеть дважды или трижды?

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

  Но что если мы хотим ещё и большей переиспользуемости кода без if’ов и множества switch-case конструкций?

• Каждая птичка будет отдельной сущностью, будет наследовать класс Птица и переопределять функции оттуда.

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

• Можно приписать нужным методам required, требуя их переопределения для каждого потомка.

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

Птичий концерт, Франс Снейдерс. Около 1630-1640г

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

3. Практический пример в Xcode

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

protocol СпособноПеть { //обязательство уметь петь
    func спой() //требование реализовать умение петь
}

Для самых-самых маленьких и любопытных

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

Что такое Playground в Xcode и как с ним изучать Swift можно спросить в Google.

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

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

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

class Петух : СпособноПеть {
    func спой() {
        print("Ку-ка-ре-куууууууу")
    }
}
class Кукушка : СпособноПеть {
    func спой() {
        print("Ку-ку ку-ку ку-ку") 
    }
}

Что будет, если кто-то из птичек захочет нас обмануть?

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

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

При нажатии на кнопку Fix редактор сам добавит нужный метод внутрь класса Ворона, т.е. имплементирует его — заставит класс соответствовать требованиям протокола, после чего уже от самого пользователя потребуется реализовать всё остальное

Отлично, мы научили птичек петь и умеем понимать кто правда умеет, а кто только притворяется. Но что делать с выступлениями? Концерт должен состояться!

class Выступление { //схема выступления конкретного певца
    let певец : СпособноПеть //да-да, прям так, как полноценный тип
    init(предлагаемыйПевец : СпособноПеть) {
        self.певец = предлагаемыйПевец
    }
}

За счёт того, что певцом в выступлении мы определили объект, который должен реализовывать протокол СпособноПеть, то и взаимодействовать с ним мы теперь будем через этот протокол. Все певцы для нас теперь равны и отвечают правилам, на которые согласились, подписывая особый «договор»

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

Даже подсказки редактора намекают, что Каркуша пусть и умеет каркать, но это в её договор не входит! Если хотите — связывайтесь с менеджером, Каркуша — талант нарасхват, просто так кому хочешь каркать не будет.

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

Однако подобные ограничения для певца ощутимо развязывают руки для нас. Вы заметили как мы перешли от конкретных птичек до более общего понятия «певец»? И не спроста, потому что «певцом» теперь может быть кто угодно. Да-да, кто угодно, кто подписывает договор и продаёт душу дьяволу реализует протокол СпособноПеть, причём внутри можем творить вообще любую дичь. Главное — факт реализации, а детали уже за нами.

extension String : СпособноПеть { //дату можем вывести, почему бы нет
    func спой() {
        print(self)
        let currentDate = NSDate.now 
        print("Вижу я, что сегодняшняя дата - \(currentDate)")
    } //любой каприз за ваши вычислительные мощности, как говорится
}

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

4. Show time!

Теперь всё готово, осталось только позвать выступающих и начать шоу.

//Зовём всех!
let воронаКаркуша = Ворона() //позвали Каркушу
let петухПетя = Петух() //позвали Петю
let кукушкаВасилиса = Кукушка() //позвали Василису
//Ставим с каждым уникальный перфоманс
let номерКаркуши = Выступление(предлагаемыйПевец: воронаКаркуша)
let номерПети = Выступление(предлагаемыйПевец: петухПетя)
let номерВасилисы = Выступление(предлагаемыйПевец: кукушкаВасилиса)
//Определем очерёдность всех выступлений и собираем сцену
let концерт = [номерКаркуши, номерПети, номерВасилисы]
концерт. forEach {выступление in выступление.певец.спой()}
//если непонятно написанное строчкой выше почитайте про Closures в Swift

Результат:

Аплодисменты!

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

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

Заключение

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

Подводя итог можно сказать, что протоколы — крайне мощный инструмент. В рамках языка Swift настолько, что на одной из WWDC(Apple Worldwide Developers Conference) Swift не без оснований назвали протокол-ориентированным языком. Надеюсь, я смог чуть прояснить протоколы для вас или, как минимум, достаточно заинтересовать для самостоятельного изучения.

Замечание про намеренно неоптимальный код

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

Спасибо за внимание! Я только начинаю свой путь в iOS-разработке, но хочу периодически писать подобные информационно-развлекательные материалы на разные темы по мере продвижения по изучаемому материалу и буду рад замечаниям от более опытных разработчиков.

Протоколы сетевого интерфейса и протоколы связи

Сетевые интерфейсы и коммуникационные протоколы

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

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

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

---

Канальный уровень Ethernet

Сети

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

Протокол интерфейса связи Fibre Channel

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

Протокол интерфейса sFPDP

Serial Front Panel Data Port (sFPDP) — это высокоскоростной двухточечный протокол связи с низкими издержками, разработанный специально для сенсорных интерфейсов. sFPDP в основном используется для перемещения многочисленных типов данных датчиков из источника данных в синхронизацию данных. Эти датчики включают, но не ограничиваются: радар, видео, оцифрованные РЧ, медицинские изображения и средства связи. Serial FPDP также поддерживает не только топологию «точка-точка», но и ряд других топологий, в том числе:  9топология 0022 с цепочкой (также известная как с петлей или с кольцевой ), однонаправленная или двунаправленная .

Mil1394 (1394b-AS5643) Протокол интерфейса связи

Протокол Mil1394, до недавнего времени известный как 1394b-AS5643, специально разработан и создан для поддержки двухточечных, последовательных, древовидных и многоконтурных соединений. Отказоустойчивость может быть легко достигнута за счет использования замкнутых соединений, когда трафик направляется в направлении кратчайшего пути к месту назначения. 139Сетевые интерфейсы 4b-AS5643 регулярно используются военными и аэрокосмическими системами для критически важных операций, связанных с высокоскоростной связью и изохронной передачей данных в реальном времени.

---

Свяжитесь с New Wave DV для сетевых интерфейсов и коммуникационных протоколов сегодня

Свяжитесь с нами для получения дополнительной информации о нашем сетевом интерфейсе и вариантах протокола связи или позвоните нам по телефону 952-224-9201, если у вас возникнут вопросы.

---

Что такое промышленные интерфейсы и протоколы?

Поиск товаров

Различные протоколы промышленных интерфейсов подряд!

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

В этой статье мы рассмотрим эти вопросы и попытаемся показать вам эту интересную область промышленной автоматизации.

Что такое интерфейс?

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

Эта важная связь осуществляется через так называемый интерфейс. Это соединение между сетями, по которому осуществляется управление всеми подключенными устройствами. Через этот интерфейс осуществляется обмен всеми данными между устройствами, а также с системой управления. Таким образом, можно сказать, что интерфейс — это соединение, обеспечивающее связь между системами.

Примеры промышленных интерфейсов

Промышленный Ethernet	Ethernet — это промышленный интерфейс, а также сетевой стандарт, для которого разработаны многочисленные известные протоколы, такие как Ethernet/IP и EtherCAT.	Преобразователи для Ethernet.
	Как и Ethernet, RS232 также является сетевым стандартом для передачи и обмена данными. RS232 также называют последовательным портом. Это один из первых сетевых стандартов.	Преобразователи для RS232.
	Интерфейс RS422 является преемником RS232 и имеет ряд улучшений, таких как увеличение скорости и уменьшение помех.	Преобразователи для RS422.
	Усовершенствованный преемник RS422 с более широкими возможностями подключения.	Преобразователи для RS485.

Что такое протоколы?

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

Примеры промышленных протоколов

Ethernet/IP	. Ethernet/IP-проток .
EtherCAT	EtherCAT основан на Ethernet, но предназначен для использования в сетях с высокой скоростью передачи данных. Это хорошо для использования в приложениях с высокой скоростью обнаружения.
Profinet	Profinet — это специально разработанный протокол для использования с интерфейсом Ethernet/IP.
Modbus TCP/IP	Протокол, который можно использовать на существующем интерфейсе Ethernet. Широко поддерживается.
IO-Link	Ведущий и подчиненный протокол связи для процессов с большей эффективностью по времени и затратам.

IO-Link получает дополнительную поддержку

IO-Link — это новинка в блоке . Это будет первый глобально стандартизированный протокол ввода-вывода для промышленного использования! Таким образом, это помогает создавать новые, хорошо организованные сети между системами управления и датчиками. Существующие сети также можно легко заменить или расширить благодаря очень удобным возможностям модернизации.