Ремонт атм что это

САЙТ СИСТЕМНОГО ИНТЕГРАТОРА ЗАО «АТМ-СЕРВИС»

Закрытое акционерное общество «АТМ-Сервис» – инжиниринговая компания, занимающаяся созданием автоматизированных систем управления технологическими процессами (АСУ ТП). Основное направление деятельности – проектирование и строительство АСУ ТП нефтегазодобывающего производства. При создании АСУ ТП выполняется полный комплекс работ: от предпроектного обследования объекта до сдачи в промышленную эксплуатацию.

С момента зарождения фирмы (февраль 1996 года) силами специалистов, работающих по настоящее время на предприятии, было выполнено проектирование и построено более 30 объектов. Среди них — различные технологические установки: от скважин до приемо-сдаточных пунктов нефти. При создании АСУ ТП проектирование ведется по всем составляющим: от КИПиА до программного обеспечения и систем связи. Правильно подобранное оборудование, предназначенное для работы в АСУ ТП, в совокупности с принимаемыми инженерными решениями гарантирует успешную работу технологического объекта в целом.

Руководящий состав предприятия обладает многолетним опытом работы в области измерительных и автоматизированных систем, полученным на предприятиях нефтегазовой промышленности. Ведущие специалисты предприятия прошли успешное обучение и обладают сертификатами фирм-изготовителей оборудования, используемого при построении АСУ ТП (Siemens, Auma, Альбатрос).
Молодые специалисты, принимаемые на предприятие после окончания ВУЗа привлекаются к работе еще будучи студентами.

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

ЗАО «АТМ-Сервис» предлагает свои услуги по выполнению комплекса или отдельных видов работ по созданию АСУ ТП от обследования объектов и постановки задачи до сдачи в эксплуатацию и гарантийного (сервисного) обслуживания.

Источник

Банкомат (ATM)

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

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

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

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

При возникновении каких-либо сбоев АТМ (например, банкомат «зажевал» деньги; деньги были списаны со счета, но банкомат их не выдал, и т. п.) необходимо незамедлительно обратиться в банк, обслуживающий данное устройство. Как правило, на самом банкомате указан номер телефона, по которому необходимо обращаться при возникновении сложных ситуаций.

Источник

Ремонт атм что это

Когда я начал разбираться в ATM, я был поражен тем, на сколько «навороченная» и непростая эта технология. Её на самом-то деле очень сложно сравнить с Frame Relay. Тут тебе и некое подобие NATa, что-то вроде VPNa, автоматическая сигнализация секитов через всю ATM сеть, динамическая маршрутизация, Tag Switching и многое другое. Даже Explicit Path можно указать для секита. Что-то знакомое, не правда ли? А я в своё время удивлялся, когда встретил большую межконтинентальную ATM сеть, которая впоследствии была заменена MPLSом. Ладно, давайте по порядку.

Немного лирики

Базовый принцип.

ATM подобно Frame Relay использует некие указатели для коммутации, но здесь они испольщуются иначе и имеют другой смысл. В заголовке ATM есть два поля — VPI (Virtual Path Identifier) и VCI (Virtual Channel Identifier). Они имеют только локальное значение на интерфейсе, как и во Frame Relay. Но, в отличии от FR, их никак нельзя сравнить с MAC адресами в Ethernet. Они никаким образом не определяют устройство и могут меняться от линка к линку.

ATM свитч может оперировать двумя этими числами. Разберем простой пример.

1. Посмотреть на:
   1. VPI в случае VP коммутации
   2. Пару VPI/VCI в случае VC коммутации
2. Полагаясь на значения VPI/VCI выбрать исходящий порт.
3. Произвести или не производить замену значений VPI/VCI.
4. Отправить данные дальше.

Virtual Connections

ATM — это connection-oriented сеть, что подразумевает установление соединения между двумя точками для передачи трафика. Типов таких соединений в ATM довольно много.

Во-первых, они делятся по тому какой тип коммутации выбран (VC или VP).

Во-вторых, такие соединения бывают постоянные и коммутируемы (permanent, switched).
В первом случае (permanent), на каждом коммутаторе по пути нужно прописать соответсвие входящий VPI/VCI, исходящий порт, исходящий VPI/VCI. Такое соединение будет всегда присутствовать на сети, независимо от наличия трафика в нем. Используется, например, для каналов по которым идет сигнализация.
Для второго типа (switched) характерна обратная ситуация. Когда появляется интересный трафик, начинает сигнализироваться соединение. Для этой цели используется специальный протокол сигнализации и маршрутизации, о котором чуть ниже. Плюсы очевидны. Во-первых, соединение поднимается по надобности, во-вторых, можно использовать все прелести динамической маршрутизации (поиск картчайшего пути, скажем).

Суммируем всю классификацию:

• Permanent Virtual Connection (PVC)
  • Permanent Virtual Channel Connection (PVCC)
  • Permanent Virtual Path Connection (PVPC)
• Switched Virtual Connection (SVC)
  • Switched Virtual Channel Connection (SVCC)
  • Switched Virtual Path Connection (SVPC)
• Soft Permanent Virtual Connection (soft PVC)
  • Soft Permanent Virtual Channel Connection (soft PVCC)
  • Soft Permanent Virtual Path Connection (soft PVPC)

Как видите, к классификации я добавил ещё и Soft PVC. Это некий гибрид между permanent и switched каналами. Из названия понятно, что он устанавливается перманентно. Однако его не нужно прописывать на каждом устройстве, такой соединение сигнализируется как SVC. Последнее обстоятельство значит, что для выбора кратчайшего пути будет использоваться протокол маршрутизации со всеми его возможностями. Представьте ситуацию, когда вы прописали PVC в своей ATM сети, а какой-либо коммутатор по пути взял да упал. В случае PVC единственным для вас вариантом будет судорожно прописывать новое соединение в обход (если он есть, разумеется). В случае Soft PVC такое соединение будет проложено по другому пути автоматичеки (reroute).

Сигнализация

1. Устройства А хочет отправит трафик устройству Z, для этого нужно сигнализировать SVC. A отправляет запрос на установление соединения, в котором содержится адрес устроства A и адрес назначения. В литературе часто можно встретить названия calling party и called party. В нашем случае это A и Z соответсвтенно. Вызывающая и вызываемая стороны. Важно так же, что в реквесте содержится необходимая информация о классе трафика и необходимых параметров для его передачи. Что-то вроде RSVP-TE прям.
2. ATM 1 устройство, получив запрос, проверяет есть ли у него адрем устройтсва Z в его таблице коммутации. Далее проверяется, сможет ли ATM 1 выделить необходимые ресурсы для прохождения трафика. Если ответ положительный, то такие ресурсы выдеряются и запрос передается дальше.
3. ATM 1 и ATM2 повторяют процедуру.
4. Устройство Z, получив запрос и осознав по адресу, что это для него, проверяет сможет ли оно выделить необходимые ресурсы. Если сможет, то в ответ отправляеся Accept сообщение, которое по такому же пути доходит обратно до устройтсва A.
5. VC сигнализирован.

Адресация

В последовательсти шагов выше, я упоминал адреса, которые передаются вместе с сигнальными кадрами. Можно сразу привести какой-нибудь типичный адрес в ATM для затравки. 47.00918100000000E04FACB401.00E04FACB401.00 А вы говорите IPv6.

Адреса в ATM глобально бывают двух видов:

1. E.164. Выглядит как телефонный номер в формате X-XXX-XXX-XXXX. Словом, обычный телефонный номер. Как я понимаю, такая адресация используется в глобальных ATM сетях.
2. NSAP. Если вы знакомы с IS-IS, то вы знаете что это формат адреса разработанный в стародавние времена OSI. Да-да, как модель OSI. Адрес имеет довольно сложную структуру, для ATM он обычно генерируется следующим образом (пример для Cisco):

• AA — AFI — Authority and Format Identifier. Например, 39 — выдан ISO, 45 — закодированный E.164 в NSAP. На деле практически всегда это одно число.
• IIII — ICD — International Code Designator. На деле для Cisco это всегда 0091
• HHHHHHHH — часть HO-DSP — High-Order Domain Specific Part. Для Cisco 81000000.
• SSSSSSSSSSSS — MAC. MAC аддрес коммутатора.
• MMMMMMMMMMMM — MAC. Mac аддрес интерфейса.
• SS — SEL. На деле всегда по нулям, а вообще это что-то вроде порта в TCP/IP.

Как видите, подобно IS-IS, сложный адрес генериться довольно простыми правилами. Также глобально адрес можно разделить ещё на две части. Первые 13 байт (47.0091810000) представляет из себя некое подобие префикса. Оставшаяся часть — идентификатор хоста. Стоит упомянуть важный момент, что в иерархичный ATM сетях схему генерации адреса придется серьезно доработать, в угоду масштабируемости. С измененной струкрурой можно суммаризировать адреса, например, наподобии того, как мы привыкли делать это в IP.

ILMI (Integrated Local Management Interface)

Как и во Frame relay, у ATMа есть свой протокол для упрощения жизни на «последних милях». Здесь он называется ILMI и выполняет несколько отличную от LMI во Frame Relay функцию. После подключения конечного устроства к ATM коммутатору через UNI линк, первый сообщает второму свой MAC адрес, коммутатор добавляет к нему свой префикс (13 байт, о которых я говорил ранее) и отправляет полный адрес назад хосту. Такая процедура составляет таблицу адресов на ATM интефейсе.

PNNI (Private Network Node Interface)

Строго говоря, в ATM есть два протокола. Interim Interswitch Signaling Protocol (IISP) и Private Network-Node Interface (PNNI). Первый позволяет прописывать статически маршруты на коммутаторах, а второй пользоваться всеми прелестями динамической маршрутизации. Поэтому далее речь пойдет только про второй.

Итак, PNNI это протокол, который:

1. Устанавливает соседство с помощью Hello-сообщений.
2. Динамически изучает топологию сети.
3. Способен учитывать QoS параметры при выборе маршрута.
4. Подерживает иерархичные топологии.
5. Отвечает за SVC сигнализацию в том числе.

PNNI работает схожим с любым другим протоколом маршрутицации. Как я думаю, многое скопировано с OSPF:

1. Установление соседства. С помощью Hello-сообщений, соседние коммутаторы устанавливают отношения сосетства. Я ранее упоминал, что в иерерхичных сетях аддресацию ATM придется немного поменять. В его часть должен входить идентификатор Peer Group. Если он совмадает на обоих соседях, то линк между ними считается внутренним, а если нет — внешним.
2. Синхронизация. Каждый сосед отправляет все свои знания о сети соседу, а потом запрашивает разницу. В результате этого шага, на двух соседях должна быть одинаковая база знаний.
3. Обновление состояний. Изменение топологий шлется с помощью PTSP (PNNI Topology State Packets) пакета, который содержит в себе несколько PTSE (PNNI Topology State Elements). Обновления так же содержат информацию необходимую для того, чтобы учитывать параметры QoS при прокладке маршрута.

PNNI использует простую метрику, которая по умолчанию равна 5040 у Cisco. Если никаких изменений не производить, то логика выбора маршрута становится сильно похожа на hop-count у RIP. Но вы всегда вольны настраивать метрику на интерфейсах, что скорее смахивает на IS-IS.

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

1. Cell delay variation (CDV) — максимальный delay на линке
2. Maximum cell transfer delay (MCTD) — CDV + прочие фиксированные задержки на линке
3. Available cell rate (AvCR) — доступный bandwidth на линке.
4. Cell loss ratio (CLR) — потери на линке.

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

Теперь, мы можем немного расширить описание предыдущей картинки.

1. Первый request приходит от конечного устроства A. Он содержит адрес источника и назначения.
2. ATM1 по своей локальной базе ищет адрес назначения и понимает, что конечная станция Z находится за устроством ATM3.
3. ATM1 производит просчет кратчайшего пути учитывая все метрики и атрибуты. После этого, он составляет лист, который включает в себя все ноды по пути. Этот лист добавляется в request и отправляется соседу ATM2. Лист на данном этапе содержит список ATM2-ATM3.
4. Каждая нода по пути проверяет, удовлетворяет ли требованиям путь из листа в реквесте. Если что-то идет не так, промежуточная нода пытается просчитать какой-то обходной маршрут до точки назначения. Если у неё это получается, то она сообщает информацию о причине и алтернативном пути тому, кто сгенерировал первоначальный лист. Тот пытается снова сигнализировать канал, но уже по другому пути. В нашем примере, ATM2 понимает, что трафик не пролезет в линк до ATM3, он понимает это по значению AvCR.
5. ATM2 просчитывает обходной путь до ATM3 через коммутатор ATMx. Генерируется новый лист ATMx-ATM3 и отправляется на ноду, которая сгенерировала первоначальный список (ATM1).
6. ATM1 получив такой совет от своего соседа, пытается сигнализировать канал, но уже по другому пути ATMx-ATM3. Снова отправляется request.
7. ATMx получив запрос проверяет соответсвует ли путь заданным требованиям и отправляет запрос дальше.
8. В итоге, запрос доходит до точки назначения и та отвечает сообщение Connect.
9. Ответное сообщение по тому же пути доходит до точки отправки трафика, после чего канал считается сигнализированным. Наконец-то можно отправлять трафик.

E.164 или плюс семь четыре семь четыре два.

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

На схеме ниже можно увидеть две приватные ATM сети, которые используют PNNI сигнализацию. Две эти сети связаны между собой через публичную ATM сеть, в которой используется E.164 сигнализация. Кроме того, что в этих двух сетях используется разный тип сигнализации, так ещё и адресация разная. В первом случае это NSAP, а во втором E.164. Ничего не напоминает? Подождите, дальше лучше.

NSAP адреса из приватных сетей не могут передаваться в открытом виде в публичных сетях, поэтому некие граничные коммутаторы должны производить что-то вроде трансляции из NSAP в E.164 и обратно. Ну как вам?

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

1. Gateway. Что-то вроде статического маршрута, который проинструктирует левый коммутатор с картинки отправлять данные на E.164 адрес правого коммутатора.
2. Autoconversion. В таком случае NSAP адрес будет сконверторован в E.164 адрес по определенному правилу, а на принимающей стороне будет произведена обратная операция.
3. Translation. Моё любимое. Настраивается таблица соответсвий NSAP адресов к E.164. После чего происходит трансляция один к одному. «Дык это ж NAT?», может воскликнуть читатель. Ну, в общем-то, да.

LANE (LAN Emulation)

Рано или поздно, инженеры столкнулись с проблемой эмуляции LAN в ATM. Учитывая тот факт, что концепции broadcast трафика в ATM нет как таковой, задача была не из легких. Да и вообще, ATM это Poin-to-Point технология. а нужно было Point-to-Multipoint. Пришлось обкладывать всю сеть костылями.

LANE довольно сложная тема, но мы не будем сильно на ней останавливаться. Для меня главное понять концепцию. А концепция проста, для того чтобы эмулировать broadcast придется использовать unicast.

Различают следующие типы устройств в LANE:

• LANE Client (LEC) — клиент, который хочет думать, что он подключен к локалке, а не к ATM сети.
• LANE Server (LES) — сущность, которая регистрирует клиентов. По сути, отвечает на ARPы и строить таблицу коммутации.
• Broadcast and Unknown Unicast Server (BUS) — принимает broadcast от хостов и отправляет его юникастом к другим клиентам.
• LANE Configuration Server (LECS) — хранит базу «какой клиент к какой сети принадлежит».

Т.е. для того, чтобы объединить два устроства в одну LAN сеть, нам понадобиться полный набор сущностей — один LES, BUS и LECS. Звучит непросто, выглядит тоже.

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

Подключение происходит следующим образом:

1. Наш клиент (LEC1) хочет подключиться к сети. Для этого ему нужно узнать, кто в этой сети LEC Server. Он сигнализирует VC до LECSа (VC 1). Его адрес он уже знает либо из статической конфигурации, либо через ILMI, либо это один из well-known стандартных адресов. VC которая только что была сигнализирована, к слову, двунаправленная. Обратите внимание на стрелки в обе стороны.
2. LECS узнает клиента и возвращает ему адрес LESа для нужной сети через тот же VC 1.
3. LEC сигнализирует VC до LES (VC 2).
4. LES идентифицирует клиента, после чего решает проверить, можно ли ему подключиться к этой эмулируемой сети.
5. Для этого LES сигнализирует VC до LECSа (VC 3).
6. Если подтверждение получено, LES сигнализирует VC до клиента для передачи трафика (VC 4).
7. Для того чтобы начать передавать трафик, для начала нужно узнать ATM адрес удаленной стороны. Значит, нужно отправить ARP (LE_ARP в терминах LANE). Для этого наш клиент должен узнать адрес BUSа. Для этого он отправляет LE_ARP с запросом broadcast адреса.
8. В ответ LECу от LESa приходит адрес BUS. После чего, он сигнализирует контрольный VC до BUSа (VC 5).
9. В обратном направлении, BUS сигнализирует до LEC VC 6 для передачи broadcast, multicast, unknown unicast трафика.
10. Почти Profit!11
11. Пришло время попробовать отправить трафик другому клиенту (LEC 2). Для этого LEC 1 отправляет LE_ARP на LES через уже сигнализированный VC 2. Цель данного мероприятия — получить уже наконец ATM адрес LEC 2, что бы уже докинуть до него VC и начать передавать трафик.
12. Если соответсвие MAC-ATM у LESa есть, то в ответ на запрос LEC 1 получит долгожданный адрес. Но это было бы не так интересно. Представим, что соответсвие не найдено. В таком случае, LES передает LE_ARP от LEC1 другим LECам. К LEC2 такой запрос попадает через VC 4′, которая уже должна быть сигнализирована (похожим образом, как описано в пункте 6).
13. Допустим, LEC2 узнал себя. После чего он отвечает своим ATM адресом через VC 2′. Этот VC также был сигнализирован ранее (см. пункт 3).
14. LES отправляет ответ от LEC2 в сторону LEC1 через VC 4.
15. LEC1 добавляет себе в кеш соответсвие MAC-ATM.
16. Теперь LEC1 в состоянии сигнализировать VC до LEC2 (VC 7). Что он и делает.
17. Profit!11
18. А что если LEC1 захочет отправить широковещательный кадр.
19. LEC1 уже знает адрес BUS, поэтому трафик прямико направится на BUS через VC 5 (он ждет своего часа ещё с пункта 8).
20. BUS множит трафик и отправляет его через ранее сигнализированные VC 6 и VC 6′.
21. Вот теперь точно Profit!111

Пора заканчивать. В ATM есть ещё много-много интересного, взять хотя бы аналог VPN — Closed User Group Signaling. Или тот же Tag Switching, который представляет из себя не что иное, как реализацию MPLS в ATM сетях. Ну и про QoS я умолчал, конечно.

Думаю, этого пока достаточно для Ethernet-инженера.

Источник