>Хост авторизации сменит on-line PIN и отправит скрипт с установкой нового PIN.
Конечно, поскольку операция установки нового on-line PIN на хосте и замена PIN приложения карты, командой скрипта с хоста не транзакционна, то есть вероятность того, что on-line PIN сменился, а off-line нет.
(термин «транзакционна» в данном случае — это термин… ну как в СУБД. т.е. завершена полностью или откачена операция).
За все реализации и вендоров ПО хоста говорить не буду, но варианты компенсации этой ситуации прозрачно для клиента можете сами прикинуть.
Кто то просто игнорирует с сакраментальным «обращайтесь в офис банка».
Так я же сказал «поплакаться»! :)
А уж как наши банки клиенты от цены железки плачутся нам… «а нет ли чего подешевле?».
Была бы цена попроще, и покупали бы больше. Да и в большее количество решений можно было воткнуть.
Самое забавное что есть решения. Но… только для тестовых целей ибо на все тестовые комплексы этих плат не напасешься.
Иногда приходит мысль: «А не попробовать ли пройти тернисты путь сертификации».
Да любая китайская готовая демо плата с ARM за $35 справится с производительностью заявленной для PL25. Поставить сеточку… залить компаундом…
А можно и не заливать. Thales не стесняясь продавал RG7000 на базе Z80(!) c полностью незащищенной платой и несколькими микриками на «защиту от вскрытия» (tamper detect типа).
Ну… не совсем место для обсуждения приватной информации. И получения e-mail то же. (не в публичных же местах..).
В общем, все эти вопросы через другие официальные каналы c SafeNet решаем. И плату на разработку нам дали (на птичьих правах правда… что несколько напрягает).
— А так еще в рамках «плача» :) и общей не приватной информации, которая возможна и остальным будет интересна.
Почто второй RS-232 убрали!??
Все разработанные схемы и инструкции коту под хвост! Особенно когда нужно и консоль и принтер (матричный для печати приватных данных) подключать!
Это что, экономия на скрепках?!
Каждый раз после подобных неожиданностей хочется выйти на UTIMACO и попробовать аналогичный продукт. Останавливает только то, что все контакты нужно заново, а особых (принципиальных по цене) преимуществ нет. Ну и прочие чисто административные проблемы.
А ценовая политика…
Eracom вышел на рынок со своим PSO за $250-$300 (при тех же уровнях сертификатов и т.д.).
А потом вместо того что бы развивать рынок вширь (ну полезная же платка), кто то там «спохватился», что «О! плату активно используют в банковской сфере! А они богатые… поднимем ка мы цену в 20 раз!» покупают… деваться то некуда. Но единично, по сравнению с потенциальным объемом.
А маркетинговый ход с программным обеспечением. PLxxx — одно то же железо, с ограничением на программном уровне скорости (лично в разговоре инженер из Eracom говорил еще до покупки SafeNet).
Жду не дождусь когда китайцы нечто подобное на рынок вынесут… А у них появится когда ни будь. Они всерьез с UPI (EMV) начали играться.
Уменьшил период расчета для контура положения — линии стали практически прямыми! В общем практический результат вполне устраивает и при отсутствии контура по току.
Стал читать теорию ТАУ и стал смутно вспоминать курс лекций по ТАУ. Читали правда весьма абстрактно… без примеров практического приложения. Или у меня тогда не замкнулись ассоциативные цепочки в мозгу :)
Однако одно дело теория, а другой дело опыт приложения ее на практике.
Сейчас кажется очевидной ошибка в выборе частоты расчета.
Еще раз спасибо за консультации!
А авторам Математика на пальцах очень рекомендовал бы почитать теорию, а не пытаться изобрести велосипед с квадратными колесами.
В принципе можно организовать в режиме on-line платеж путем создания канала между картой в кармане жертвы и сотовым телефоном, эмулирующим работу бесконтактной карты (HCE приложение).
Всего то нужно два телефона с NFC, хост с белым IP для проброса трафика в on-line между двумя телефонами и очень четкая синхронизация двух злоумышленников.
И… они могут получить бесплатный завтрак в макдональс! (а на большее без ПИН лимита не хватит) или от 5 лет… Если кассир заподозрит неладное.
Но как то это фриково… Мелочь по карманам в том же общественном транспорте тырить — навар больше будет.
А уж просто стырить карту и расплатится ей в пределах без PIN лимита — еще безопаснее.
Не верю я в таких квалифицированных в области программизма мелких карманников.
Нет именно AAC карте(!) передает терминал в первой GenerateAC. Понятно что карта возвращает то же AAC и криптограмму. И с этой криптограммой терминал идет на авторизацию.
Авторизацию опять же служебной операции специально «раскрашенную» как служебный запрос.
Хочу обратить внимание, что по EMV не специфицированно ограничений и скрип выполняется вне зависимости от того AAC, или ARQC терминал выдал после первой GenerateAC.
Используется для служебных функций (не платежных!) в служебном терминале и/или ATM.
Например — запрос баланса.
Некоторые вендоры ПО, запрос баланса по EMV карте делают через обычный ARQC с '00..0' полями сумм, а некоторые через AAC. Видел и тот и другой вариант. И то и другое работает (нет стандарта на служебные операции).
Лично мне кажется, из очень общих соображений, что через AAC правильнее. Ну что бы точно было видно «ЭТО НЕ платежная транзакция»
Аналогично и смена PIN то же служебная операция.
Конечно смену PIN можно запрашивать и совместно с платежом, но концептуально не правильно мешать…
Время записи всего видеобуфера составляет примерно 20мсек. При желании можно выводить видео 50 кадров / сек, но контроллер будет заниматься только выводом. :) В реальных задачах необходимо осуществлять перезапись экрана от 3 до 10 раз в секунду.
Может я жесток, но раз написали статью, будьте готовы к критике.
Потому что авторы даже FSMC поленились/не получилось/не подходит прикрутить.
И стробируют запись программным дерганьем ножки порта, как ардуинисты…
В таком варианте DMA «не работает».
Хотя казалось… пишут что раньше использовали дисплеи… неужели так же через порт!?
Хотя может зря наговариваю и FSMC уже у них используется а мультиплексор ставить лень/некуда.
Забавно… с формированием и видеосигнала для телевизора из части основной адресной памяти проца вполне справлялся древний «Спектрум» на Z80. Там телевизор как монитор — был штатным решением.
Ну да… специализированная микросхема со своим буфером (заливаемым через порт… однако) вместо варианта как в «Спектрум»… это конечно круто.
А чем смысл статьи то? В том что нашли специализированную микросхему?
В общем правильно, чуть формулировка не точна :)
Хост авторизации сменит on-line PIN и отправит скрипт с установкой нового PIN.
Вот только жаль, что эту операцию не стандартизировали и смена PIN в общем случае доступна только в «своей» инфраструктуре.
Нет стандарта (в разных реализациях ПО процессинга) на данный тип «транзакции» и способ передачи нового PIN (PIN блок с новым PIN). У каждой реализации свои особенности и… межхост с большой долей вероятности запрос смены PIN не пройдет.
Ну и для подобных служебных операций в EMV зарезервирован фактически (ну по крайней мере его так используют) режим, когда терминал карте на первый GenerateAC говорит AAC и идет в on-line что бы получить скрипт.
Ну, даже если промахнетесь, можно отъехать назад и встать снова куда надо.
Да я понимаю, но на скорость упираю потому что в голове стоит комплексная задача управления координатой в 2D.
Наверное Вы правы. Слона нужно есть по частям. Попытаюсь абстрагироваться от задачи верхнего уровня (подготовки траектории) и забыть слово скорость
В сущности, добавить управление по скорости — это всего лишь ограничить сверху W из контура управления положением.
Помешать такой работе контура положения может только сила сухого трения, отсутствие контура тока и модленная дискретизация расчета контуров программы. Т.е. привод может «прыгнуть» на несколько меток с места быстрее, чем 100мс. И тогда начнутся колебания. А может быть и нет — тогда получится провести линию с точностью 1мм.
Вот так это у меня по выходным данным дебага и зрительно и выглядело перемещения по 2 мм за раз с остановов на 2 сек без ограничения скорости. Т.е. сведение к позиционированию:
1. перемещение = 0 -> PID положения повышает W
2. Следующий отчет координата уже перелетела за заказанную.
3. Реверс и автоколебания около заказанного значения.
Уменьшаю коэффициент…
1. перемещение = 0 -> PID положения повышает W
2. Следующий отчет координаты не долетел чуть… новое W
3. Следующий отчет координаты уже перелетел за…
4. Реверс и автоколебания.
Попытка проанализировать зависимость ШИМ и оборотов показала, что есть какое то граничное значение ШИМ (35% заполнения) до которого мотор вообще не вращается даже если вниз нужно разматывать. При медленном и плавном увеличении где то с 47-45% заполнения ШИМ (непредсказуемо) — весьма резко стартует да еще и ускоряет обороты.
А если вверх тянуть груз каретки нужно, то стартует с 49..55% в зависимости от текущего веса каретки и расположения звезд. Неужели это сухое трение червяной пары такой эффект дает?
(не занимался я раньше управлением коллекторным двигателем. не с чем сравнивать).
Поэтому я и говорил, что есть проблема на малых оборотах и старте/реверсе.
Реверс червячного редуктора с люфтом в 3 градуса (где то 1-3мм длины тросика в зависимости от объема намотке тросика на шкиве) это вообще непредсказуемая вещь.
Как ведет себя система, если скорость равна нулю? Если вы перемещаете фломастер контуром положения, по шагам?
Включили систему, фламастер стоит. И медленно, как секундная стрелка часов, меняете задание на свои две оси, чтобы по одной метке в секунду привода шли. Я пытаюсь понять результат этого эксперимента.
По моему я такой эксперимент проводил для подобных условий. Попробую вспомнить…
Фактически у меня те же два контура. Значение желаемой скорости используется просто как верхний ограничитель W (т.е. как граничное значение выходного сигнала PID регулятора положения.)
Параметры (взял эмпирический, возможно не правильно):
#define DELTA_DT_CALC_SPEED 100 // 100 ms
#define DELTA_DT_PID 100 // 100 ms
1. dt обсчета положения — 100ms (шаг PID по положению)
2. dt для расчета скорости — 100ms (заодно шаг PID по скорости). минимальная возможная измеряемая скорость (1 отчет на 100ms) -> 10 отчетов на сек * 0.5mm/отчет = 5мм/сек
Опс… начал писать и понял. Я кажется тормоз… Точнее чем 5мм/сек не получить на интервале измерения.
polargraph — это когда для получения декартовых X,Y необходимо рассчитать длину двух тросиков подвеса.
Волнистая линия возникает когда нужно, например, нарисовать произвольную прямую линию в декартовых координатах, что означает:
1. на каждом участке линии динамически считать длину подвесов и их синхронные скорость на заданное время.
2. Четко выдерживать скорость и длинну каждого троса.
Если dt в течении которого нужно поддерживать постоянную скорость достаточно большое, то можно считать, что все в порядке и скорость устанавливается стабильной (ну на уровне точности энкодера, как минимум и через где то в среднем 500ms).
Но как бы я не подбирал коэффициенты PID но выход на «линию» графика скорости меньше чем за 400-700ms добиться не удалось. Собственно, за счет этого волнистость похоже и получается. Линии фломастером вообще очень на классические графики PID похожи (ну с учетом того, что по радиусу а, не по прямой).
А что бы линия в декартовых координатах была прямой (в пределах 1-2 мм отклонений) нужно что бы укладывалось хотя бы в 100ms (ну по моим расчетам).
Да еще ситуация, когда направление меняется вносит свою проблему с люфтом червячного редуктора.
Вначале думал, что это упругие колебания троса свою лепту вносят, но дебаг с контроллера (время, координата по энкодеру, текущие значения PID) в принципе показывают ту же картину что я наблюдаю вживую.
Наверное надо не поленится и попробовать сделать третий контур регуляции по току. Что бы скорость быстрее устанавливалась. Опыт лишним не бывает. Тем более, что делаю больше для развлечения, а не результата.
Но боюсь проблема с люфтом энкодера и нелинейностью между фактической длинной троса и оборотами двигателя (трос 1мм диаметра наматывается в навал, а не ровными рядками) все равно результат не позволит улучшить.
Впрочем, наверное я хочу «странного», поскольку ни на одном видео работы аналогичных по принципу конструкций (на шаговиках в основном), я прямых линий не видел.
Конечно, поскольку операция установки нового on-line PIN на хосте и замена PIN приложения карты, командой скрипта с хоста не транзакционна, то есть вероятность того, что on-line PIN сменился, а off-line нет.
(термин «транзакционна» в данном случае — это термин… ну как в СУБД. т.е. завершена полностью или откачена операция).
За все реализации и вендоров ПО хоста говорить не буду, но варианты компенсации этой ситуации прозрачно для клиента можете сами прикинуть.
Кто то просто игнорирует с сакраментальным «обращайтесь в офис банка».
Действительно. Не место для таких обсуждения.
А уж как наши банки клиенты от цены железки плачутся нам… «а нет ли чего подешевле?».
Была бы цена попроще, и покупали бы больше. Да и в большее количество решений можно было воткнуть.
Самое забавное что есть решения. Но… только для тестовых целей ибо на все тестовые комплексы этих плат не напасешься.
Иногда приходит мысль: «А не попробовать ли пройти тернисты путь сертификации».
Да любая китайская готовая демо плата с ARM за $35 справится с производительностью заявленной для PL25. Поставить сеточку… залить компаундом…
А можно и не заливать. Thales не стесняясь продавал RG7000 на базе Z80(!) c полностью незащищенной платой и несколькими микриками на «защиту от вскрытия» (tamper detect типа).
В общем, все эти вопросы через другие официальные каналы c SafeNet решаем. И плату на разработку нам дали (на птичьих правах правда… что несколько напрягает).
— А так еще в рамках «плача» :) и общей не приватной информации, которая возможна и остальным будет интересна.
Почто второй RS-232 убрали!??
Все разработанные схемы и инструкции коту под хвост! Особенно когда нужно и консоль и принтер (матричный для печати приватных данных) подключать!
Это что, экономия на скрепках?!
Каждый раз после подобных неожиданностей хочется выйти на UTIMACO и попробовать аналогичный продукт. Останавливает только то, что все контакты нужно заново, а особых (принципиальных по цене) преимуществ нет. Ну и прочие чисто административные проблемы.
А ценовая политика…
Eracom вышел на рынок со своим PSO за $250-$300 (при тех же уровнях сертификатов и т.д.).
А потом вместо того что бы развивать рынок вширь (ну полезная же платка), кто то там «спохватился», что «О! плату активно используют в банковской сфере! А они богатые… поднимем ка мы цену в 20 раз!» покупают… деваться то некуда. Но единично, по сравнению с потенциальным объемом.
А маркетинговый ход с программным обеспечением. PLxxx — одно то же железо, с ограничением на программном уровне скорости (лично в разговоре инженер из Eracom говорил еще до покупки SafeNet).
Жду не дождусь когда китайцы нечто подобное на рынок вынесут… А у них появится когда ни будь. Они всерьез с UPI (EMV) начали играться.
Проблема только одна… клиенты привыкли к solaris unix.
Ну и то что в бюджет нужна новая плата для разработки и поддержки.
А так… что pso что новые платы. Для потребителя разници нет. Кроме новых рисков.
тогда да. одними резисторами и простым ЦАП не обойтись.
Хотя, если не требуется цветность и достаточно ЧБ изображения, то композитного выхода делается все просто.
Но я в данном случае критиковал еще большие частность — посылку данных через порт с программным стробом :)
Стал читать теорию ТАУ и стал смутно вспоминать курс лекций по ТАУ. Читали правда весьма абстрактно… без примеров практического приложения. Или у меня тогда не замкнулись ассоциативные цепочки в мозгу :)
Однако одно дело теория, а другой дело опыт приложения ее на практике.
Сейчас кажется очевидной ошибка в выборе частоты расчета.
Еще раз спасибо за консультации!
А авторам Математика на пальцах очень рекомендовал бы почитать теорию, а не пытаться изобрести велосипед с квадратными колесами.
Всего то нужно два телефона с NFC, хост с белым IP для проброса трафика в on-line между двумя телефонами и очень четкая синхронизация двух злоумышленников.
И… они могут получить бесплатный завтрак в макдональс! (а на большее без ПИН лимита не хватит) или от 5 лет… Если кассир заподозрит неладное.
Но как то это фриково… Мелочь по карманам в том же общественном транспорте тырить — навар больше будет.
А уж просто стырить карту и расплатится ей в пределах без PIN лимита — еще безопаснее.
Не верю я в таких квалифицированных в области программизма мелких карманников.
Авторизацию опять же служебной операции специально «раскрашенную» как служебный запрос.
Хочу обратить внимание, что по EMV не специфицированно ограничений и скрип выполняется вне зависимости от того AAC, или ARQC терминал выдал после первой GenerateAC.
Используется для служебных функций (не платежных!) в служебном терминале и/или ATM.
Например — запрос баланса.
Некоторые вендоры ПО, запрос баланса по EMV карте делают через обычный ARQC с '00..0' полями сумм, а некоторые через AAC. Видел и тот и другой вариант. И то и другое работает (нет стандарта на служебные операции).
Лично мне кажется, из очень общих соображений, что через AAC правильнее. Ну что бы точно было видно «ЭТО НЕ платежная транзакция»
Аналогично и смена PIN то же служебная операция.
Конечно смену PIN можно запрашивать и совместно с платежом, но концептуально не правильно мешать…
Может я жесток, но раз написали статью, будьте готовы к критике.
Google: «формирование видеосигнала stm32»
сразу нахожу…
http://we.easyelectronics.ru/STM32/generator-video-na-stm32f407-recept-bystrogo-prigotovleniya.html
8 выводов порта + 11 резисторов + использование DMA вместо специализированной микросхемы и запихивания в нее данных из буфера.
.
И стробируют запись программным дерганьем ножки порта, как ардуинисты…
В таком варианте DMA «не работает».
Хотя казалось… пишут что раньше использовали дисплеи… неужели так же через порт!?
Хотя может зря наговариваю и FSMC уже у них используется а мультиплексор ставить лень/некуда.
Ну да… специализированная микросхема со своим буфером (заливаемым через порт… однако) вместо варианта как в «Спектрум»… это конечно круто.
А чем смысл статьи то? В том что нашли специализированную микросхему?
Хост авторизации сменит on-line PIN и отправит скрипт с установкой нового PIN.
Вот только жаль, что эту операцию не стандартизировали и смена PIN в общем случае доступна только в «своей» инфраструктуре.
Нет стандарта (в разных реализациях ПО процессинга) на данный тип «транзакции» и способ передачи нового PIN (PIN блок с новым PIN). У каждой реализации свои особенности и… межхост с большой долей вероятности запрос смены PIN не пройдет.
Ну и для подобных служебных операций в EMV зарезервирован фактически (ну по крайней мере его так используют) режим, когда терминал карте на первый GenerateAC говорит AAC и идет в on-line что бы получить скрипт.
Если получится, сегодня-завтра вечером попробую. Или в выходные…
Такая мысль с обработкой по факту(прерыванию) счетчика сигналов энкодера мне не приходила в голову!
Обязательно попробую.
Да я понимаю, но на скорость упираю потому что в голове стоит комплексная задача управления координатой в 2D.
Наверное Вы правы. Слона нужно есть по частям. Попытаюсь абстрагироваться от задачи верхнего уровня (подготовки траектории) и забыть слово скорость
В сущности, добавить управление по скорости — это всего лишь ограничить сверху W из контура управления положением.
Вот так это у меня по выходным данным дебага и зрительно и выглядело перемещения по 2 мм за раз с остановов на 2 сек без ограничения скорости. Т.е. сведение к позиционированию:
1. перемещение = 0 -> PID положения повышает W
2. Следующий отчет координата уже перелетела за заказанную.
3. Реверс и автоколебания около заказанного значения.
Уменьшаю коэффициент…
1. перемещение = 0 -> PID положения повышает W
2. Следующий отчет координаты не долетел чуть… новое W
3. Следующий отчет координаты уже перелетел за…
4. Реверс и автоколебания.
Попытка проанализировать зависимость ШИМ и оборотов показала, что есть какое то граничное значение ШИМ (35% заполнения) до которого мотор вообще не вращается даже если вниз нужно разматывать. При медленном и плавном увеличении где то с 47-45% заполнения ШИМ (непредсказуемо) — весьма резко стартует да еще и ускоряет обороты.
А если вверх тянуть груз каретки нужно, то стартует с 49..55% в зависимости от текущего веса каретки и расположения звезд.
Неужели это сухое трение червяной пары такой эффект дает?
(не занимался я раньше управлением коллекторным двигателем. не с чем сравнивать).
Поэтому я и говорил, что есть проблема на малых оборотах и старте/реверсе.
Реверс червячного редуктора с люфтом в 3 градуса (где то 1-3мм длины тросика в зависимости от объема намотке тросика на шкиве) это вообще непредсказуемая вещь.
По моему я такой эксперимент проводил для подобных условий. Попробую вспомнить…
Фактически у меня те же два контура. Значение желаемой скорости используется просто как верхний ограничитель W (т.е. как граничное значение выходного сигнала PID регулятора положения.)
Параметры (взял эмпирический, возможно не правильно):
#define DELTA_DT_CALC_SPEED 100 // 100 ms
#define DELTA_DT_PID 100 // 100 ms
1. dt обсчета положения — 100ms (шаг PID по положению)
2. dt для расчета скорости — 100ms (заодно шаг PID по скорости). минимальная возможная измеряемая скорость (1 отчет на 100ms) -> 10 отчетов на сек * 0.5mm/отчет = 5мм/сек
Опс… начал писать и понял. Я кажется тормоз… Точнее чем 5мм/сек не получить на интервале измерения.
Мдаа… Дальше можно не суетится…
Спасибо за взгляд со стороны.
Волнистая линия возникает когда нужно, например, нарисовать произвольную прямую линию в декартовых координатах, что означает:
1. на каждом участке линии динамически считать длину подвесов и их синхронные скорость на заданное время.
2. Четко выдерживать скорость и длинну каждого троса.
Если dt в течении которого нужно поддерживать постоянную скорость достаточно большое, то можно считать, что все в порядке и скорость устанавливается стабильной (ну на уровне точности энкодера, как минимум и через где то в среднем 500ms).
Но как бы я не подбирал коэффициенты PID но выход на «линию» графика скорости меньше чем за 400-700ms добиться не удалось. Собственно, за счет этого волнистость похоже и получается. Линии фломастером вообще очень на классические графики PID похожи (ну с учетом того, что по радиусу а, не по прямой).
А что бы линия в декартовых координатах была прямой (в пределах 1-2 мм отклонений) нужно что бы укладывалось хотя бы в 100ms (ну по моим расчетам).
Да еще ситуация, когда направление меняется вносит свою проблему с люфтом червячного редуктора.
Вначале думал, что это упругие колебания троса свою лепту вносят, но дебаг с контроллера (время, координата по энкодеру, текущие значения PID) в принципе показывают ту же картину что я наблюдаю вживую.
Наверное надо не поленится и попробовать сделать третий контур регуляции по току. Что бы скорость быстрее устанавливалась. Опыт лишним не бывает. Тем более, что делаю больше для развлечения, а не результата.
Но боюсь проблема с люфтом энкодера и нелинейностью между фактической длинной троса и оборотами двигателя (трос 1мм диаметра наматывается в навал, а не ровными рядками) все равно результат не позволит улучшить.
Впрочем, наверное я хочу «странного», поскольку ни на одном видео работы аналогичных по принципу конструкций (на шаговиках в основном), я прямых линий не видел.