MDB uyumlu ama çalışmıyor: sahadaki gerçek arıza modları

MDB protokolünü anlatan yazımız bir vaatle açılıyor: uyumlu herhangi bir bozuk para ünitesi, uyumlu herhangi bir makineye takılabilsin. Standardın varlık sebebi bu.

Sahada bu vaat her zaman tutmaz. Bir cihaz kutusunun üzerinde “MDB uyumlu” yazar, makinenin kataloğunda “MDB destekler” yazar, ikisini birleştirirsiniz ve hiçbir şey olmaz. Ya da daha kötüsü: bir hafta çalışır, sonra durur.

Bunun sebebi genellikle sandığınız şey değildir. Bu yazı, sebebin ne olduğunu ve hangi sırayla bakılacağını anlatıyor.

Neden “uyumlu” bir garanti değil

MDB bir belgedir. Makinedeki ve cihazdaki ise firmware'dir.

Aynı belgeyi iki ayrı mühendislik ekibi, birbirinden habersiz, farklı yıllarda okur ve kod yazar. Belgenin açık olduğu yerlerde ikisi de aynı şeyi yapar. Belgenin sustuğu, “isteğe bağlı” dediği veya iki okumaya açık olduğu yerlerde ise ikisi farklı seçim yapar. Uyumsuzluk tam olarak orada doğar.

Yani karşınızdaki genellikle bir arıza değil, iki geçerli yorumun buluşamamasıdır. Bu ayrım pratik: arıza aranırken sağlam cihazlar sökülür, yorum farkı aranırken sorun bulunur.

Teşhis, doğru sırayla

Çağrıların çoğu “cihaz öldü” diye gelir. Neredeyse hiçbiri değildir. Dört katman var ve alttan başlamak gerekir — üstten başlarsanız çalışan bir cihazı iade edersiniz.

1. Besleme — en sık, en çok yanlış teşhis edilen

MDB hattı veriyi de besler. Bir cihaz boştayken az, iş yaparken çok akım çeker: kart okurken, ekran yakarken, hele hücresel bağlantı kurarken.

Makinenin MDB hattı o tepe akımı kaldıramıyorsa, gerilim tam işlem anında düşer. Cihaz resetlenir, VMC onu kaybeder, tekrar gelir.

Belirti karakteristiktir: cihaz boşta sorunsuz görünür, sadece işlem sırasında düşer. Menüde “cihaz var” der, müşteri kart okuttuğunda yok olur. Bu bir yazılım sorunu gibi görünür ve sayısız cihaz bu yüzden boşuna iade edilmiştir.

Uzun kablo bu tabloyu ağırlaştırır: kablo üzerindeki gerilim düşümü, yükün en yüksek olduğu anda en büyüktür.

2. Hat — kablolama ve adres

MDB opto-izoledir ve kutupludur. Ters bağlanan bir hat cihazı yakmaz ama iletişim de kurmaz — sessizce hiçbir şey olmaz.

Adres tarafında ise klasik hata şu: nakitsiz cihaz sınıfının iki adresi vardır, 0x10 ve 0x60. Makineye zaten bir nakitsiz cihaz takılıyken ikincisi eklenir ve ikisi de 0x10 üzerinden konuşur. İki cihaz aynı anda yanıt verince hat çöp üretir; VMC ikisini birden kaybeder. Belirti kafa karıştırıcıdır çünkü daha önce çalışan cihaz da bozulmuştur.

3. Tanıma — açılışta olan biten

VMC, hangi cihazların hatta olduğunu açılışta belirler: adresleri sırayla yoklar ve yanıt verenleri kaydeder. Bu pencere dardır.

Bir cihaz kendi açılışını tamamlamadan bu pencere kapanırsa, VMC onu yok sayar ve bir sonraki resete kadar bir daha sormaz. Cihaz mükemmel çalışıyordur; kimse ona sormuyordur.

Belirti tanıdıktır: “makineyi kapatıp açınca düzeliyor” ya da “önce cihazı, sonra makineyi açarsak çalışıyor”. Bir kurulum ritüeli hâline gelmiş her sıra bağımlılığı, aslında bir tanıma penceresi sorunudur.

Reset davranışı da buraya girer. Hat resetlendikten sonra cihazın kendini yeniden tanıtması mı, yoksa sorulmayı beklemesi mi gerekir? Belgenin net olmadığı bu noktada iki taraf farklı seçim yapmışsa, cihaz sonsuza kadar “pasif” durumda oturur.

4. Oturum — paranın kaybolduğu yer

En pahalı katman bu, çünkü burada cihaz çalışıyordur; yanlış olan sadece sıralamadır.

Nakitsiz bir satış kısa bir durum makinesidir: yetkilendir → ürünü ver → satışı kesinleştir. Protokol parayı bilinçli olarak ürün düştükten sonra alır. Ama arada bir şey ters giderse — spiral takılır, makine “başaramadım” der, ya da hat tam o anda kopar — oturumu kimin ve ne zaman geri alacağı sorusu doğar.

İki taraf bu geri alma anını farklı yorumlarsa iki sonuçtan biri çıkar: müşteriden para alınır ama ürün gelmez, ya da ürün gider para alınmaz. İkincisi haftalarca fark edilmez; sadece gün sonu tutmaz.

Bu, mutabakat sorunu gibi görünen bir protokol sorunudur. Kasa sayımıyla uğraşmadan önce bakılacak yer burasıdır.

Bir de: isteğe bağlı komutlar

Belgede “opsiyonel” diye geçen komutlar vardır. Bir VMC, cihazın uygulamadığı opsiyonel bir komutu zorunlu sayarsa cihazı reddeder.

Belirti çok belirgindir: aynı cihaz bir makine modelinde sorunsuz çalışır, diğerinde hiç çalışmaz. Cihaz da makine de sağlamdır. Buluşamıyorlardır.

Bunu nereden biliyoruz

2005–2020 arasında otomat üreticilerinin mühendislik ekipleriyle birlikte MDB uyum sorunlarını sahada tespit ettik ve yazılım düzeltmeleriyle çözülmesini sağladık. Yukarıdaki maddelerin hepsi, bir makinenin başında geçirilmiş saatlerden geliyor.

DMS Tech, Avrupa otomat veri transfer standardında (EVA DTS) DMS üretici koduyla kayıtlıdır — sahadaki ünitelerin seri ve arıza kodları bu öneki taşır.

Bugün durum daha iyi — ama makineler hâlâ orada

Dürüst olmak gerekirse bu problemlerin çoğu artık eskisi kadar sık çıkmıyor. Üretici tarafındaki uygulamalar zamanla düzeldi, standardın kendisi olgunlaştı, belirsiz bıraktığı noktalar azaldı.

Ama sahadaki makine parkı bir gecede yenilenmiyor. 2008'de, 2012'de kurulmuş bir otomat hâlâ ciro üretiyor ve o makinede yukarıdaki her madde geçerli.

Bu yüzden asıl soru çoğu zaman “bu MDB sorunu nasıl çözülür” değil, **“bu makine yükseltilmeye değer mi”**dir. Cevap evetse yol açıktır: Hero Nexus hatta nakitsiz cihaz olarak katılır, makinenin kontrol kartına dokunulmaz ve makine kart, temassız, yemek kartı, İstanbulkart ve QR kabul etmeye başlar. Makinenin kendisi de yenilenmeliyse, akıllı VMC tarafı devreye girer.

Cevap hayırsa bunu da söyleriz. Otuz yıllık bir protokolde her arıza çözülmeye değmez.