Bir tarafta yükünü taşıtacak araç arayan şirketler ve insanlar var.

Diğer tarafta yük arayan lojistik şirketleri, boş dönen kamyonlar, kapasitesinin yalnızca bir bölümünü kullanan araçlar ve bir sonraki işini bulmaya çalışan filolar var.

Yani aslında çoğu zaman problem kapasitenin olmaması değil.

Problem, doğru yükün doğru araçla, doğru yerde, doğru zamanda ve ekonomik olarak doğru koşullarda buluşamaması.

Eurostat'ın Avrupa taşımacılığı verilerinde, 2023 yılında AB'de kayıtlı ağır yük araçlarının araç-kilometrelerinin yaklaşık %21,8'i boş yolculuklardan oluşuyordu.

Üstelik karayolu taşımacılığının problemi yalnızca boş kilometre değil. IRU'nun 2025 araştırmasına göre Avrupa'da yaklaşık 502 bin doldurulamamış kamyon şoförü pozisyonu bulunuyor. Bu, mevcut insan ve araç kapasitesinin daha verimli kullanılmasını giderek daha önemli hale getiriyor.

Biz de tam bu problemin ortasına LoadFlux ile giriyoruz.

Ama en başta bir şeyi netleştirelim:

LoadFlux bir yük ilan sitesi olmayacak.

Bir dijital nakliye komisyoncusu da olmayacak.

Sadece müşteriyi lojistik şirketiyle buluşturan klasik bir marketplace olarak da kalmayacak.

LoadFlux'un hedefi çok daha büyük:

Fiziksel lojistik ağındaki yükleri, araçları, rotaları, zamanı ve kullanılabilir kapasiteyi sürekli analiz ederek her aracın yapabileceği en mantıklı ticari hareketleri üretmek.

Başka bir ifadeyle:

LoadFlux, lojistik sektörünün fırsat ve karar motoru olacak.

Önce en basit problemden başlayalım

Bir üretici düşünelim.

İstanbul Tuzla'da 4 palet makine parçası var.

Toplam ağırlık yaklaşık 2,3 ton.

Ürün salı günü öğleden sonra hazır olacak ve en geç perşembe Samsun'a ulaşması gerekiyor.

Bugünkü süreçte şirket çeşitli nakliyecileri arayabilir, WhatsApp gruplarına yazabilir, tanıdığı taşıyıcılardan fiyat isteyebilir veya farklı platformlarda yük ilanı oluşturabilir.

LoadFlux'ta ise müşteri tek bir taşıma talebi oluşturacak.

Örneğin:

Çıkış: Tuzla / İstanbul Varış: Tekkeköy / Samsun Yük: Makine parçaları Ağırlık: 2.300 kg Palet: 4 Hazır olma zamanı: Salı 14:00 Teslim limiti: Perşembe 18:00 Araç gereksinimi: Tenteli / uygun parsiyel taşıma Bütçe: 28.000 TL

Fakat LoadFlux için bu bilgiler yalnızca ekranda gösterilecek birkaç metin alanı değildir.

Arka planda bunların tamamı makine tarafından işlenebilir bir Shipment Request haline gelir.

Yani sistem artık şunu bilir:

“Belirli koordinatlar arasında, belirli bir zaman penceresinde, belirli fiziksel özelliklere sahip bir yükün taşınması gerekiyor.”

Ve asıl işlem bundan sonra başlar.

LoadFlux'un diğer tarafında araçlar var

Lojistik şirketleri sisteme yalnızca şirket profillerini değil, filolarını da tanımlayacak.

Örneğin:

34 LF 061

• Tenteli TIR

• 24 ton maksimum taşıma kapasitesi

• 90 m³ kullanılabilir hacim

• Mevcut yük: 9,4 ton

• Kalan kapasite: 14,6 ton

• Başlangıç: İstanbul

• Hedef: Samsun

• Hareket: 3 Eylül, 07:30

• Planlanan rota: İstanbul → Bolu → Ankara → Çorum → Samsun

Burada LoadFlux'un bakış açısı değişiyor.

Klasik bir sistem şöyle düşünebilir:

“Bu araç İstanbul'dan Samsun'a gidiyor. İstanbul-Samsun yüklerini gösterelim.”

Biz böyle yapmayacağız.

LoadFlux şunu soracak:

Bu aracın mevcut rotası, zamanı, kapasitesi ve maliyet yapısı düşünüldüğünde hangi yük veya yük kombinasyonlarını alması ekonomik olarak mantıklı?

İki soru birbirinden tamamen farklı.

Ve LoadFlux'un bütün teknolojik yapısı ikinci sorunun üzerine kurulacak.

Opportunity Engine: LoadFlux'un kalbi

Sistemin merkezinde LoadFlux Opportunity Engine bulunacak.

Her araç ve her potansiyel taşıma işi arasında bir uyumluluk hesaplanacak.

Basitleştirirsek:

Araç
×
Rota
×
Yük
×
Kapasite
×
Zaman
×
Maliyet
×
Risk
×
Beklenen Gelir

↓

Transport Opportunity

Burada yalnızca iki şehrin aynı olup olmadığına bakmayacağız.

Sistem;

• rota uyumunu,

• aracın kalan kapasitesini,

• yükün ağırlığını,

• yükün hacmini,

• palet/geometri uygunluğunu,

• araç tipini,

• yükleme zamanını,

• teslim zamanını,

• ana rotadan yapılması gereken sapmayı,

• bekleme süresini,

• sürüş süresini,

• tahmini yakıt maliyetini,

• ücretli yolları,

• yükleme ve boşaltma süresini,

• operasyonel riski,

• müşterinin bütçesini,

• tahmini taşıma gelirini

birlikte değerlendirecek.

Sonuçta firmaya 300 ilan göstermek yerine mümkün olduğunca şöyle diyeceğiz:

“Bu sefer için ekonomik olarak anlamlı 4 fırsat bulduk.”

Bu fark LoadFlux'un temel ürün felsefesi olacak.

Bir yük rotanın üzerinde olmak zorunda değil

Burada önemli bir detay var.

İstanbul'dan Samsun'a giden aracın alabileceği yükün İstanbul-Samsun arasında birebir bulunması gerekmiyor.

Örneğin aracın ana güzergâhından 18 kilometre saparak alınabilecek bir yük varsa ve bu yük 14.000 TL ek gelir sağlayacaksa o sapma son derece mantıklı olabilir.

Başka bir yük 70 kilometrelik ek rota yaratıp yalnızca 5.000 TL kazandırıyorsa anlamsız olabilir.

Bu nedenle LoadFlux sadece mesafeyi değil, sapmanın ekonomisini hesaplayacak.

Kabaca:

Ek taşımanın değeri

=

Taşıma geliri

-

Ek yakıt
-

Ek sürücü zamanı
-

Yol ücretleri
-

Yükleme/boşaltma maliyeti
-

Bekleme maliyeti
-

Operasyonel risk

Böylece “rota üzerinde” kavramı geometrik olmaktan çıkıp ekonomik bir kavrama dönüşüyor.

Dynamic Capacity Engine: Bir araç ya boş ya dolu değildir

Lojistikte kapasiteyi yalnızca “boş araç” üzerinden düşünmek de ciddi bir kayıp.

24 ton kapasiteli bir araç 9 ton yük taşıyorsa hâlâ kullanılabilecek 15 tona yakın kapasitesi olabilir.

LoadFlux bu kapasiteyi görünür hale getirecek.

Fakat yine yalnızca ton hesabı yapılmayacak.

Sistem;

• ağırlık,

• hacim,

• palet sayısı,

• fiziksel boyutlar,

• yükleme sırası,

• boşaltma sırası,

• yük uyumluluğu,

• kasa tipi,

• özel taşıma şartları

gibi kısıtları birlikte değerlendirecek.

Çünkü 8 ton boş kapasitenin bulunması, her 8 tonluk yükün o araca konabileceği anlamına gelmiyor.

LoadFlux'un amacı yalnızca yük bulmak değil, gerçek kullanılabilir kapasiteyi hesaplamak.

Ve işin en sevdiğimiz kısmı: Opportunity Packages

LoadFlux'un en önemli özgün özelliklerinden biri burada ortaya çıkıyor.

Sistem yalnızca tek tek işleri analiz etmeyecek.

İş kombinasyonları oluşturacak.

Diyelim ki bir TIR İstanbul'dan Samsun'a gidiyor ve yaklaşık 15 ton kapasitesi boş.

Sistem üç farklı taşıma buldu:

İş A

İstanbul → Bolu 4 ton 14.000 TL

İş B

Düzce → Çorum 5 ton 18.500 TL

İş C

Çorum → Samsun 3 ton 15.300 TL

Tek başına üç ayrı ilan.

Ama LoadFlux için asıl soru şu:

Bu üç yük aynı sefer içerisinde birlikte alınabilir mi?

Sistem rotayı yeniden hesaplayacak.

Kapasiteyi her pickup ve delivery noktasından sonra yeniden değerlendirecek.

Zaman pencerelerini kontrol edecek.

Yükleme ve boşaltma sıralarını kontrol edecek.

Ardından firmaya şöyle bir çıktı verebilecek:

LoadFlux Opportunity Package

Araç: 34 LF 061 Ana rota: İstanbul → Samsun

Önerilen taşıma: 3 ek iş Toplam ek yük: 12 ton Ana rota: 731 km Optimize rota: 772 km Ek mesafe: +41 km Ek operasyon süresi: +1 saat 35 dakika

Tahmini ek ciro: 47.800 TL Tahmini ek operasyon maliyeti: 6.450 TL Tahmini katkı: +41.350 TL

Kapasite kullanımı:

%39 → %91

İşte LoadFlux'un kırılma noktalarından biri bu.

Çünkü artık:

“Sana yük ilanları gösteriyorum.”

demiyoruz.

Şunu söylüyoruz:

“Aracının bu seferini daha kârlı hale getirecek operasyon planını buldum.”

Bu problem teknik tarafta Vehicle Routing Problem, Pickup and Delivery, Time Windows, çok boyutlu kapasite optimizasyonu ve kombinatoryal optimizasyon gibi problemlerin birleşimine dönüşüyor.

Ve LoadFlux'un en ciddi teknoloji alanlarından biri tam olarak burada oluşacak.

Araç yoldayken sistem durmayacak

Planlanan seferler önemli.

Ama gerçek lojistik statik değil.

Bir araç yükünü erken boşaltabilir.

Bir müşteri işi iptal edebilir.

Yeni bir taşıma ilanı ortaya çıkabilir.

Trafik değişebilir.

Araç beklenenden farklı bir saatte müsait olabilir.

Bu nedenle LoadFlux uzun vadede yalnızca sefer oluşturulduğu anda hesaplama yapan bir sistem olmayacak.

Dynamic Dispatch Engine

Araçların canlı konumu sisteme aktarılabildiğinde LoadFlux sürekli yeniden değerlendirme yapabilecek.

Örneğin araç Ankara'daki yükünü boşalttı.

Normalde Samsun'a boş dönecek.

LoadFlux aracın:

• anlık konumunu,

• hedefini,

• kalan sürüş süresini,

• boş kapasitesini,

• çevredeki aktif yükleri,

• tahmini pickup sürelerini

analiz edecek.

Ve telefona şu bildirim gelebilecek:

Aracınızın dönüş rotasına uygun 2 yeni fırsat bulundu.

Bir dokunuşla detay açılacak.

Bu noktada LoadFlux artık yalnızca marketplace değil, hareket halindeki lojistik kapasitenin gerçek zamanlı karar katmanı haline geliyor.

LoadFlux Price Intelligence

Fiyat tarafını da yalnızca “müşteri bütçe yazsın, nakliyeci teklif versin” seviyesinde bırakmak istemiyoruz.

Sistem yeterli veri ürettikçe kendi fiyat zekâsını oluşturacak.

Model;

• kilometre,

• rota,

• araç tipi,

• yük türü,

• ağırlık,

• hacim,

• yakıt,

• ücretli yollar,

• mevsimsellik,

• bölgesel araç arzı,

• yük talebi,

• geçmiş teklifler,

• kabul edilen fiyatlar,

• reddedilen teklifler,

• gün,

• saat

gibi parametrelerden beslenecek.

Müşteri tarafında:

Tahmini piyasa aralığı: 31.000 – 35.500 TL

görülebilir.

Firma tarafında ise:

Bu iş için rekabetçi teklif aralığı: 32.800 – 34.100 TL

gibi bir karar desteği oluşabilir.

Daha da önemlisi sistem zamanla yalnızca “fiyat nedir?” sorusunu değil:

“Bu fiyattan teklif verirsem işi alma olasılığım nedir?”

sorusunu da cevaplayabilir.

Demand Heatmap: Yük henüz oluşmadan önce

LoadFlux yeterli veri biriktirdiğinde geçmişi görmek tek başına yeterli olmayacak.

Geleceği tahmin etmeye çalışacağız.

Hangi bölgelerde önümüzdeki saatlerde veya günlerde daha fazla taşıma talebi oluşma ihtimali var?

Hangi şehirden hangi şehre yük akışı artıyor?

Hangi günler belirli sanayi bölgelerinde taşıma yoğunluğu oluşuyor?

Bunların sonucunda filo yöneticisi haritada bir Demand Heatmap görebilecek.

Örneğin:

Önümüzdeki 24 saat içerisinde Gebze–Bursa koridorunda yüksek taşıma talebi bekleniyor.

Buradan sonra filo planlaması yalnızca eldeki yüklerden ibaret olmaktan çıkıyor.

Araçlar gelecekteki tahmini talebe göre konumlandırılmaya başlanıyor.

Empty Return Prediction

Lojistikte en pahalı sorulardan biri:

“Oraya yük götürürsem dönüşte yük bulabilecek miyim?”

LoadFlux bunu da ölçülebilir bir probleme çevirecek.

Sistem geçmiş operasyonları, bölgesel yük üretimini, araç tipini, günü, saati ve talep desenlerini analiz ederek:

Empty Return Probability

üretebilecek.

Örneğin:

Bu teslimat sonrası aracın boş dönüş riski: %73

ve ardından:

Teslimattan sonra 38 km güneydeki bölgeye yönlenmeniz halinde dönüş yükü bulma olasılığı belirgin şekilde yükseliyor.

Bu tek başına büyük bir filo optimizasyon özelliği.

Next Best City

Ve LoadFlux'un uzun vadede en güçlü sorularından birine geliyoruz:

Bu aracı bir sonraki hangi şehre göndermeliyim?

Diyelim araç Ankara'da boşaldı.

Samsun'a mı dönmeli?

Konya'ya mı gitmeli?

Bursa tarafına mı yönelmeli?

Beklemeli mi?

LoadFlux bunu yalnızca mevcut ilanlara göre değerlendirmeyecek.

Hesaba:

• aktif yükleri,

• tahmini yük talebini,

• spot fiyatları,

• dönüş yükü ihtimalini,

• kilometre maliyetini,

• sürücünün çalışma süresini,

• aracın özelliklerini,

• geçmiş operasyon sonuçlarını

katacak.

Sonuç olarak:

Seçenek A — Samsun

Beklenen gelir: X Boş kilometre riski: yüksek Operasyon riski: düşük

Seçenek B — Konya

Beklenen gelir: Y Boş kilometre riski: orta Talep görünümü: güçlü

Seçenek C — Bursa

Beklenen gelir: Z Ek yol: daha yüksek 48 saatlik tahmini toplam katkı: en yüksek

LoadFlux burada bir navigasyon uygulaması olmaktan da çıkıyor.

Ekonomik navigasyon yapmaya başlıyor.

Fleet Profitability Intelligence

Bir filo yöneticisinin “araçlarım çalışıyor” demesi yeterli değil.

Önemli olan nasıl çalıştıkları.

LoadFlux her araç için zaman içerisinde:

• toplam kilometre,

• yüklü kilometre,

• boş kilometre,

• ortalama kapasite kullanımı,

• kilometre başına gelir,

• kilometre başına maliyet,

• bekleme süresi,

• rota bazlı kârlılık,

• reddedilen fırsatlar,

• kabul edilen fırsatlar,

• LoadFlux sayesinde oluşturulan ek gelir

gibi metrikleri hesaplayabilecek.

Ve yalnızca grafik göstermek istemiyoruz.

Sistem veriyi yorumlayacak.

Örneğin:

34 LF 061 son 30 günde filonuzun ortalamasından %17 daha fazla boş kilometre yaptı.

veya:

İstanbul → Ankara operasyonlarınız yüksek gelir üretmesine rağmen Ankara sonrası boş dönüş nedeniyle toplam sefer kârlılığı düşük.

veya:

Bu ay LoadFlux tarafından oluşturulan fırsatlar filonuz için tahmini 184.000 TL ek katkı oluşturdu.

Yani analitik ekranı geçmişi gösteren bir dashboard değil, karar üreten bir sistem olacak.

LoadFlux AI Logistics Copilot

Burada “uygulamamıza bir chatbot koyduk, artık AI ürünüyüz” gibi bir şeyden bahsetmiyoruz.

LoadFlux AI sistemin gerçek operasyon verilerine bağlanacak.

Filo yöneticisi şunu yazabilecek:

“Yarın İstanbul'dan çıkacak araçlarımı mümkün olan en kârlı şekilde planla.”

LoadFlux:

1. müsait araçları bulacak,

2. kapasitelerini analiz edecek,

3. aktif taşıma işlerini değerlendirecek,

4. tahmini talebi inceleyecek,

5. rota kombinasyonları oluşturacak,

6. maliyetleri hesaplayacak,

7. boş dönüş riskini değerlendirecek,

8. alternatif senaryolar üretecek.

Ve örneğin üç plan döndürecek:

Plan A

En düşük operasyon riski Tahmini katkı: 118.000 TL

Plan B

Daha agresif rota kombinasyonu Tahmini katkı: 136.000 TL

Plan C

En düşük boş kilometre oranı Tahmini katkı: 124.000 TL

Son karar hâlâ insanda olacak.

Ama insan artık yüzlerce değişkeni kendi kafasında hesaplamak zorunda kalmayacak.

Müşteri tarafını da unutmadık

Bütün bu optimizasyon sisteminin diğer tarafında taşıma yaptırmak isteyen kullanıcı var.

Müşteri:

• yük ilanı oluşturabilecek,

• fotoğraf yükleyebilecek,

• konumları haritadan seçebilecek,

• tarih ve zaman penceresi girebilecek,

• yük özelliklerini tanımlayabilecek,

• bütçe belirleyebilecek,

• gelen lojistik tekliflerini karşılaştırabilecek,

• firma profilini inceleyebilecek,

• mesajlaşabilecek,

• anlaşabilecek,

• taşıma durumunu takip edebilecek,

• tamamlanan operasyonu değerlendirebilecek.

Daha ileri aşamada doğal dil ile ilan oluşturulabilecek.

Kullanıcı yalnızca:

“Yarın öğleden sonra Avcılar'dan Bursa'ya 6 palet yaklaşık 3 ton tekstil ürünü gidecek.”

yazacak.

LoadFlux bunu analiz ederek gerekli taşıma parametrelerini otomatik oluşturacak.

Teklif sistemi

Eşleşme, anlaşma değildir.

LoadFlux doğru tarafları bir araya getirdikten sonra görüşme başlayacak.

Lojistik firması:

• fiyat,

• araç,

• tahmini pickup,

• teslimat zamanı,

• taşıma koşulları

ile teklif verebilecek.

Müşteri farklı firmaları karşılaştırabilecek.

Karşı teklif yapılabilecek.

Mesajlaşma ve dosya paylaşımı gerçekleşebilecek.

Teklif değişiklikleri kayıt altında tutulabilecek.

Taraflar anlaşınca taşıma işi oluşturulacak.

İlerleyen aşamalarda elektronik sözleşme, ödeme altyapısı, sigorta ve finansal hizmetler de aynı işlem katmanına bağlanabilir.

Trust Score

Böyle bir sistemde algoritmanın iyi olması yetmez.

Güven gerekiyor.

LoadFlux içerisinde firmalar ve operasyonlar için çok katmanlı bir doğrulama yapısı tasarlıyoruz.

Bunlar zaman içerisinde;

• şirket doğrulama,

• yetki belgeleri,

• araç belgeleri,

• sürücü bilgileri,

• tamamlanan taşıma sayısı,

• zamanında teslimat oranı,

• iptal oranı,

• müşteri değerlendirmeleri,

• anlaşmazlıklar,

• teklif davranışları

gibi verilerden beslenecek.

Bunların sonucunda dinamik bir LoadFlux Trust Score oluşturulabilecek.

Amaç yalnızca beş yıldız vermek değil.

Platformun kendi operasyon verisiyle gerçekten güvenilir taşıma ağı yaratmak.

iOS, Android ve Web: Üç uygulama değil, tek ağ

LoadFlux aynı sistemin:

• iOS,

• Android,

• Web

istemcilerinde çalışacak.

Mobil uygulama özellikle hızlı ilan, saha operasyonu, araç ve bildirim deneyiminde güçlü olacak.

Web tarafında ise filo yöneticileri ve kurumsal müşteriler için daha yoğun bilgi içeren:

• filo ekranları,

• operasyon haritaları,

• analitikler,

• fırsat paketleri,

• rota planları

sunulacak.

Ama arka tarafta hepsi aynı lojistik ağına bağlı olacak.

Teknik tarafta nasıl yapacağız?

İlk günden yüzlerce mikroservis açıp mimari diyagramlarla kendimizi kandırmak istemiyoruz.

Önce güçlü ve yönetilebilir bir çekirdek oluşturacağız.

Mobil ve çoklu platform tarafında Flutter önemli adaylarımızdan biri.

Backend tarafında:

ASP.NET Core / .NET

Ana veritabanı:

PostgreSQL

Coğrafi işlemler:

PostGIS

Cache:

Redis

Gerçek zamanlı veri:

SignalR / WebSocket

Optimizasyon ve matematiksel modeller:

Python + OR-Tools ve gerektiğinde özel optimizasyon modelleri

kullanılabilecek.

İlk backend yaklaşımımız modüler monolith olabilir.

Çünkü ilk günden dağıtık sistem karmaşıklığı üretmek yerine ürün mantığını doğru kurmak daha önemli.

Ana domain'ler kabaca:

Identity

Customer

Company

Fleet

Vehicle

Driver

Shipment

Trip

Route

Matching

Opportunity

OpportunityPackage

Offer

Conversation

TransportOrder

Trust

Telemetry

Analytics

Forecast

şeklinde ayrılacak.

Sistem büyüdükçe özellikle:

• Matching Engine,

• Routing Engine,

• Optimization Engine,

• Telemetry,

• Notification,

• Forecasting

bağımsız servisler haline getirilebilir.

Neden PostGIS?

Çünkü LoadFlux'un dünyası yalnızca:

İstanbul
Ankara
Samsun

gibi stringlerden ibaret değil.

Bizim dünyamız koordinatlardan, yolların geometrisinden, pickup noktalarından, rota koridorlarından ve sapmalardan oluşuyor.

Örneğin sistemin:

“Bu pickup noktası aracın planlanan rotasına kaç kilometre gerçek sapma oluşturuyor?”

sorusunu doğru şekilde cevaplayabilmesi gerekiyor.

Coğrafi veri LoadFlux'un temel veri tiplerinden biri olacak.

Optimizasyon problemi sandığımızdan çok daha büyük

Bir araç ve bir yük için eşleşme yapmak nispeten kolaydır.

Ama:

20 araç,

500 açık yük,

farklı zaman pencereleri,

farklı pickup ve delivery noktaları,

farklı kapasiteler,

farklı araç gereksinimleri

olduğunda problem hızla büyür.

Opportunity Packages bunun üzerine bir de kombinasyon ekliyor.

Dolayısıyla LoadFlux'ta her şeyi tek bir “AI modeli” çözmeyecek.

Farklı problem sınıfları için farklı araçlar kullanılacak.

Bazı yerlerde:

deterministik kurallar,

bazı yerlerde:

constraint optimization,

bazı yerlerde:

operations research,

bazı yerlerde:

machine learning,

bazı yerlerde ise:

LLM tabanlı doğal dil ve karar arayüzleri

kullanılacak.

Bize göre gerçek mühendislik de tam olarak burada başlıyor.

Teknolojiyi probleme uydurmak.

Problemi moda olan teknolojiye değil.

LoadFlux Data Flywheel

LoadFlux büyüdükçe en değerli varlık yalnızca uygulamanın kaynak kodu olmayacak.

Veri olacak.

Her operasyon bize şunları öğretecek:

• hangi yük nereden nereye gidiyor,

• hangi araçlar hangi bölgelerde çalışıyor,

• hangi fiyat teklif ediliyor,

• hangi fiyat kabul ediliyor,

• hangi fiyat reddediliyor,

• hangi rota tercih ediliyor,

• hangi sapmalar kabul ediliyor,

• hangi araç tipine hangi bölgede talep var,

• hangi bölgede boş araç oluşuyor,

• hangi saatlerde yük yoğunlaşıyor,

• hangi rotalarda dönüş yükü bulunamıyor.

Bu da zaman içerisinde şu döngüyü oluşturacak:

Daha fazla operasyon
        ↓
Daha fazla veri
        ↓
Daha iyi tahmin
        ↓
Daha iyi eşleşme
        ↓
Daha yüksek ekonomik değer
        ↓
Daha fazla kullanıcı
        ↓
Daha fazla operasyon

Bir arayüz kopyalanabilir.

Bir özellik kopyalanabilir.

Ama yıllar içerisinde oluşmuş lojistik karar verisi çok daha zor kopyalanır.

LoadFlux'un uzun vadeli teknoloji hendeğini burada görüyoruz.

Avrupa'daki dönüşüm de önemli

Lojistik verisinin dijitalleşmesi yalnızca özel şirketlerin yönelimi değil.

Avrupa Birliği'nin eFTI düzenlemesi 9 Temmuz 2027'den itibaren tam olarak uygulanacak ve üye devlet makamlarının sertifikalı eFTI platformları üzerinden elektronik olarak paylaşılan yük taşımacılığı bilgilerini kabul etmesi gerekecek.

Bu nedenle LoadFlux'un veri yapısını en başından:

• makine tarafından okunabilir,

• yapılandırılmış,

• entegrasyona açık,

• API-first düşünceye yakın

oluşturmak istiyoruz.

Gelecekte eFTI, e-CMR, ERP, TMS, telematik ve farklı taşıma ekosistemleriyle entegrasyon bu yüzden önemli olacak.

Peki ilk sürümde ne olacak?

Burada önemli bir ayrım yapıyoruz.

LoadFlux'un ürün vizyonundaki bütün özellikler ana ürünün parçalarıdır.

Ama hepsini aynı gün geliştirmeye çalışmak mühendislik değil, plansızlık olur.

İlk çalışan uçtan uca zincir:

Müşteri
   ↓
Taşıma Talebi
   ↓
Lojistik Firmaları
   ↓
Araç
   ↓
Trip / Rota
   ↓
Matching
   ↓
Opportunity
   ↓
Teklif
   ↓
Görüşme
   ↓
Anlaşma
   ↓
Taşıma

olacak.

Ardından sırasıyla:

Phase 2

Route Compatibility Capacity Intelligence Advanced Matching

Phase 3

Opportunity Packages Multi-load Optimization Profit Optimization

Phase 4

Live GPS Dynamic Dispatch Real-Time Opportunities

Phase 5

Price Intelligence Demand Heatmap Empty Return Prediction Next Best City

Phase 6

AI Logistics Copilot Fleet-wide Optimization Predictive Dispatch

derinleşecek.

Yani ileri özellikler ayrı bir uygulama olmayacak.

Hepsi LoadFlux olacak.

LoadFlux'un başarı metriği kullanıcı sayısı olmayacak

Bir milyon indirme güzel görünebilir.

Ama bizim için asıl soru:

LoadFlux fiziksel lojistik sistemini gerçekten daha verimli hale getirdi mi?

Bu nedenle takip etmek istediğimiz esas metrikler arasında:

Empty Kilometer Reduction

Araçların boş kilometresini ne kadar azalttık?

Average Capacity Utilization

Araç kapasitesini ne kadar yükselttik?

Opportunity Acceptance Rate

Ürettiğimiz fırsatların ne kadarı gerçekten ekonomik değer yaratıyor?

Time to First Offer

Müşteri ilk kaliteli teklifini ne kadar hızlı alıyor?

Match-to-Booking Conversion

Ürettiğimiz eşleşmelerin kaçı gerçek taşıma operasyonuna dönüşüyor?

ve belki de en önemlisi:

Opportunity Value Generated

LoadFlux müşterileri için ne kadar yeni ekonomik değer oluşturdu?

olacak.

Nihai hedefimiz

Bugün bir nakliyeci şu soruyu soruyor:

“Aracım için yük var mı?”

LoadFlux'un ilk cevabı:

“Evet. Sana en uygun yükleri buldum.”

Sonra soru değişecek:

“Hangisini almalıyım?”

LoadFlux:

“Şu ikisini birlikte alırsan daha kârlı.”

Bir süre sonra:

“Bu teslimattan sonra nereye gitmeliyim?”

LoadFlux:

“Konya'ya yönelmek önümüzdeki 24 saat için daha avantajlı görünüyor.”

Ve en sonunda filo yöneticisi şunu soracak:

“Önümüzdeki 48 saat için filomu nasıl çalıştırmalıyım?”

LoadFlux bütün ağı değerlendirecek.

Araçları.

Yükleri.

Rotaları.

Sürücüleri.

Zamanı.

Talebi.

Kapasiteyi.

Maliyeti.

Riski.

Ve seçenekleri önüne koyacak.

İşte bizim LoadFlux ile ulaşmak istediğimiz yer tam olarak burası.

Bir ilan platformu kurmuyoruz

Bunu özellikle tekrar etmek istiyoruz.

LoadFlux'un meselesi ilan göstermek değil.

Yük sahibinin daha hızlı taşıyıcı bulması önemli.

Nakliyecinin daha fazla iş bulması önemli.

Ama bunlar başlangıç.

Asıl hedef:

Zaten var olan fiziksel lojistik kapasitesinden daha fazla ekonomik değer üretmek.

Yeni bir kamyon üretmeden.

Yeni bir yol yapmadan.

Yeni bir depo inşa etmeden.

Var olan araçları, var olan yükleri ve var olan hareketleri daha akıllı eşleştirerek.

Bugün lojistik ağı büyük ölçüde fiziksel.

Biz onun üzerine bir karar katmanı inşa etmek istiyoruz.

LoadFlux

Move Less Empty. Move More Value.

Bazen bir proje aylarca yapılan fizibilitelerden, onlarca toplantıdan ve yüzlerce sayfalık dokümandan doğar.

Bazen de insan bir futbol istatistiği paylaşımının altında birkaç satır okur ve şu soruyu sorar:

“Peki bunu gerçekten doğru yapmak isteseydik nasıl yapardık?”

TUNIX Football Digital Twin biraz böyle doğdu.

Bir takımın şampiyonluk ihtimalini yalnızca geçmiş maç skorlarından hesaplayan bir model üzerine düşünürken problem giderek büyüdü.

Çünkü futbol yalnızca geçmiş skorların toplamı değildi.

Bir futbol takımı yaşayan bir sistemdi.

Transfer yapıyor.

Oyuncu kaybediyor.

Teknik direktör değiştiriyor.

Sakatlanıyor.

Yoruluyor.

Taktik değiştiriyor.

Avrupa kupasına gidiyor.

Yoğun fikstüre giriyor.

Bir oyuncusu formunun zirvesine çıkıyor.

Başka bir oyuncusu aylardır sahaya dönemiyor.

Ekonomik olarak güçleniyor veya küçülüyor.

Rakibinin başına başka bir şey geliyor.

Ve bütün bunlar daha skor tabelasına yansımadan takımın gerçek durumunu değiştiriyor.

İşte bizim başlangıç sorumuz tam olarak burada değişti.

Artık mesele:

“Bu takım şampiyon olur mu?”

değildi.

Asıl soru şuydu:

Bir futbol kulübünün belirli bir andaki gerçek durumunu dijital ortamda temsil edebilir miyiz?

Ve daha önemlisi:

Bu dijital dünyayı geleceğe doğru binlerce, yüz binlerce kez çalıştırabilir miyiz?

Cevabımız:

Deneyeceğiz.

Vira Bismillah.

Bir tahmin sitesi yapmıyoruz

İlk günden bunun sınırını doğru çizmek gerekiyor.

TUNIX Football Digital Twin bir:

• skor tahmin sitesi,

• klasik futbol istatistik sitesi,

• Elo tablosu,

• transfer haber sitesi,

• “AI bugün ne dedi?” uygulaması

olmayacak.

Hedefimiz daha büyük.

Futbol dünyasının mümkün olduğunca geniş bölümünü zamana bağlı bir digital twin içerisinde temsil etmek istiyoruz.

Bir başka ifadeyle sistemin herhangi bir (t) anındaki futbol dünyası için bir state'i olacak:

$$\mathcal{W}_t = FootballWorldState(t)$$

Bu state içerisinde:

• kulüpler,

• oyuncular,

• teknik direktörler,

• kadrolar,

• sözleşmeler,

• transferler,

• sakatlıklar,

• cezalar,

• maçlar,

• organizasyonlar,

• fikstür,

• performans,

• form,

• piyasa değerleri,

• takım güçleri,

• oyuncu güçleri,

• belirsizlikler,

• taktik yapılar,

• hava koşulları,

• seyahat,

• dinlenme süreleri,

• tarihsel olaylar

ve zamanla ekleyeceğimiz çok daha fazla değişken yer alacak.

Amacımız tek bir sayı hesaplamak değil.

Amacımız futbol dünyasının hesaplanabilir bir temsilini oluşturmak.

Skoru sonuç olarak görüyoruz, sebep olarak değil

Bir takımın son beş maçta dört galibiyet alması önemli bir veridir.

Ama neden kazandı?

Yeni transfer mi geldi?

Rakipler mi zayıftı?

Forvet olağanüstü bitiricilik mi gösterdi?

Takımın gerçek üretimi mi arttı?

Kaleci normalin üzerinde mi kurtardı?

Teknik direktör sistem mi değiştirdi?

Rakipler kırmızı kart mı gördü?

Fikstür mü kolaydı?

Bunların tamamını yalnızca:

2-0
1-0
3-1
0-1
2-1

üzerinden öğrenmeye çalışmak mümkündür.

Fakat bilgi kaybı büyüktür.

Biz skoru çöpe atmıyoruz.

Tam tersine skor, maç modelimizin önemli gözlemlerinden biri olacak.

Fakat sistemin dünyaya açılan tek penceresi olmayacak.

Temel yaklaşım: Latent Football State

Bir takımın “gerçek gücü” doğrudan ölçülebilen bir büyüklük değil.

Bu nedenle takım durumunu bir latent state olarak ele almak istiyoruz.

Örneğin:

$$S_{team,t} = [ A_t, D_t, B_t, T_t, P_t, SP_t, DEP_t, FIT_t, FAT_t, CHEM_t, CONF_t, UNC_t ]$$

Burada örneğin:

• (A_t): hücum gücü

• (D_t): savunma gücü

• (B_t): build-up kapasitesi

• (T_t): transition gücü

• (P_t): pressing kapasitesi

• (SP_t): duran top gücü

• (DEP_t): kadro derinliği

• (FIT_t): oyuncu uygunluğu

• (FAT_t): yorgunluk

• (CHEM_t): takım uyumu

• (CONF_t): form/güven etkisi

• (UNC_t): model belirsizliği

gibi değişkenleri temsil edebilir.

Bunların nihai tanımları elbette araştırma, veri ve backtest sonucunda şekillenecek.

Buradaki kritik düşünce şu:

Takım gücü tek sayı olmak zorunda değil.

Ve daha da önemlisi:

Takım gücü sabit değil.

Futbol bir state-space problemi olarak ele alınabilir

Sistemin matematiksel omurgasında değerlendirdiğimiz yapılardan biri state-space yaklaşımı.

Basitleştirirsek:

$$x_{t+1}=f(x_t,u_t)+w_t$$

ve

$$y_t=g(x_t)+v_t$$

Burada:

• (x_t): doğrudan göremediğimiz gerçek futbol state'i

• (u_t): dışarıdan gelen olaylar

• (y_t): gözlediğimiz maç ve performans verileri

• (w_t): sistem belirsizliği

• (v_t): ölçüm gürültüsü

(u_t) dediğimiz şey ise tam olarak futbolun gerçek hayatı:

$$u_t = [ Transfer, Injury, Suspension, CoachChange, Fixture, Fatigue, SquadChange, ... ]$$

Bu ayrım bizim için çok önemli.

Çünkü bir takım dünya çapında bir futbolcu transfer ettiğinde gerçek takım state'i ilk maçın bitmesini beklemez.

Gerçek dünya o anda değişmiştir.

Dijital modelin de mümkün olduğunca o anda değişmesi gerekir.

Salah problemi

Basit bir örnek.

Bir takımın dün itibarıyla hücum gücü:

$$A_t = 72$$

olsun.

Bugün dünya çapında bir hücum oyuncusu transfer edildiğini düşünelim.

Sadece geçmiş skorlara dayanan bir sistem bu transferden habersizdir.

Takım birkaç maç oynar.

Yeni oyuncu gol atar.

Takım kazanır.

Model sonuçları görür.

Takım gücünü yükseltir.

Bizim hedefimiz farklı.

Transfer gerçekleştiği anda:

$$TransferEvent \rightarrow SquadState \rightarrow PlayerImpact \rightarrow TeamState$$

zinciri çalışmalı.

Maç oynandıktan sonra ise sistem ikinci kez güncellenmeli:

$$ExpectedPerformance \leftrightarrow ObservedPerformance$$

Yani model hem ön bilgiye hem de sahadaki kanıta sahip olacak.

Oyuncu yalnızca piyasa değerinden ibaret değil

Transfermarkt ve benzeri kaynaklar sistemimizin veri kaynaklarından bazıları olabilir.

Ancak:

$$MarketValue \neq FootballAbility$$

Bir futbolcunun piyasa değeri;

• yaştan,

• kontrat süresinden,

• potansiyelden,

• ticari değerden,

• ligden,

• kulüpten,

• talep seviyesinden

etkilenebilir.

Biz oyuncuyu çok boyutlu bir state ile temsil etmek istiyoruz.

Örneğin:

$$P_i = [ Finishing, ShotGeneration, Passing, Creation, Progression, Dribbling, PressResistance, Pressing, Tackling, Interception, Aerial, Physical, Positioning, Availability, Form ]$$

Bunların tamamının ilk sürümde bulunması gerekmiyor.

Ama mimari, gelecekte bulunmalarına engel olmayacak şekilde kurulmalı.

Oyuncu gücü bağlama göre değişmeli

Bir başka önemli düşüncemiz:

$$PlayerImpact \neq Constant$$

Bir oyuncunun katkısı sadece kendi yeteneğinin fonksiyonu değildir.

Daha doğru yaklaşım:

$$Impact = f( Player, Team, Coach, Role, League, Formation, Opposition )$$

Bir sağ kanat oyuncusunun zaten aynı bölgede elit oyuncuya sahip bir kadroya eklenmesi ile o pozisyonda büyük açık bulunan takıma transfer olması aynı marjinal etkiyi oluşturmayabilir.

İlk yaklaşımımız örneğin:

$$TransferImpact = Quality \times ExpectedMinutes \times TacticalFit \times PositionNeed \times LeagueAdjustment \times Adaptation$$

gibi modellenebilir.

Ama burada özellikle “formülü bulduk” demiyoruz.

Formülü veriden öğreneceğiz.

İlk 11 yetmez

İki takım düşünelim.

İkisinin de ideal ilk 11 gücü 85.

Birinin rotasyonu 83.

Diğerinin rotasyonu 67.

Bu iki takım 38 maçlık ligde aynı değildir.

Hele birisi Avrupa kupalarında oynuyorsa hiç değildir.

Dolayısıyla:

$$SquadStrength = w_1 FirstXI+ w_2 Rotation+ w_3 Depth$$

gibi bir yapı gerekir.

Üstelik (w_1,w_2,w_3) sabit olmak zorunda değildir.

Bir takım üç günde bir maç oynuyorsa kadro derinliğinin değeri artmalıdır.

Yorgunluk da state'in parçası

Bir futbolcu pazar günü 90 dakika, çarşamba günü 120 dakika, cumartesi tekrar 90 dakika oynuyorsa matematiksel model açısından üç maçta da aynı oyuncu değildir.

Bu nedenle oyuncu bazında bir workload/fatigue state'i düşünüyoruz:

$$ F_{i,t+1}

F_{i,t} + Load_{i,t}

Recovery_{i,t} $$

Takım yorgunluğu ise oyuncu durumlarından üretilebilir.

Böylece:

• Avrupa kupası,

• kupa maçları,

• seyahat,

• uzatma,

• rotasyon,

• dinlenme günü

gibi faktörler maç modeline girebilir.

Sakatlık: 0 veya 1 değil

Oyuncu durumunu:

healthy
injured

şeklinde iki değerli tutmak istemiyoruz.

Mümkün olduğu ölçüde:

• sakatlık türü,

• başlangıç zamanı,

• beklenen dönüş,

• recurrence riski,

• antrenman durumu,

• dakika kısıtlaması,

• maç kondisyonu

gibi bilgileri değerlendirebiliriz.

Dolayısıyla sistem:

$$P(Available_i,t)$$

veya

$$P(Start_i,t)$$

hesaplayabilir.

Bir futbolcu için gerçek dünya çoğu zaman %0 veya %100 değildir.

Teknik direktör bir metadata değildir

Teknik direktör değişikliği de yalnızca:

coach_id = 2819

güncellemesi olmayacak.

Uzun vadede teknik direktörleri de çok boyutlu modellerle temsil etmek istiyoruz.

Örneğin:

$$CoachVector = [ Attack, Defence, Press, Possession, Transition, Development, Rotation, GameManagement ]$$

ve:

$$CoachFit = f(Coach,Squad)$$

hesaplanabilir.

Çünkü aynı teknik direktör iki farklı kadroda aynı etkiyi göstermek zorunda değildir.

Taktik eşleşmeleri

Futbolun güzel taraflarından biri:

$$A>B$$

ve

$$B>C$$

olmasının mutlaka

$$A>C$$

anlamına gelmemesidir.

Çünkü futbol yalnızca strength karşılaştırması değildir.

Match-up problemidir.

Uzun vadede takımları birer style vector ile temsil etmeyi hedefliyoruz:

$$Style = [ Possession, Tempo, Width, PressIntensity, Directness, CounterAttack, HighLine, CrossFrequency, BuildUpRisk ]$$

Sonrasında:

$$Matchup(A,B)$$

takımların stil etkileşimini modele ekleyebilir.

Maç motoru

Dixon-Coles gibi akademik olarak bilinen modeller bizim için başlangıç noktası ve baseline olabilir.

Örneğin:

$$\lambda_H = f( Attack_H, Defence_A, HomeAdvantage, Lineup, Fatigue, Matchup, ... )$$

ve

$$\lambda_A = f( Attack_A, Defence_H, ... )$$

hesaplanabilir.

Buradan skor dağılımı:

$$P(X=x,Y=y)$$

elde edilir.

Ancak kendimizi tek modele kilitlemeyeceğiz.

Araştıracağımız adaylar arasında:

• Poisson modelleri

• Dixon-Coles

• Bivariate Poisson

• Bayesian hierarchical modeller

• state-space modeller

• Elo türevleri

• gradient boosting

• neural networks

• ensemble modeller

olacak.

Kazananı isminden dolayı değil, backtest sonucundan dolayı seçeceğiz.

Bize ait bir model

Burada önemli bir çizgimiz var.

PyTorch kullanabiliriz.

JAX kullanabiliriz.

NumPy kullanabiliriz.

PyMC kullanabiliriz.

Scikit-learn kullanabiliriz.

Hazır matematik kütüphanelerini yeniden yazmanın mühendislik açısından hiçbir anlamı yok.

Fakat:

• Player Intelligence Model,

• Team State Model,

• Transfer Impact Model,

• Match Engine,

• World Simulation Engine

bizim problem tanımımızla ve bizim verimizle geliştirilecek.

Bir başka şirketin API'sinden:

team_strength = 82

alıp üzerine arayüz yapmak istemiyoruz.

State'in sahibi biz olmalıyız.

En değerli varlığımız zamanla kod olmayacak

Bu projenin uzun vadede en önemli bölümü:

Temporal Football Knowledge Base

olacak.

Sistem yalnızca bugünü bilmeyecek.

Bir bilginin ne zaman doğru olduğunu da bilecek.

Örneğin:

player: X
club: Y

valid_from:
valid_until:

observed_at:

source:
confidence:
version:

tutacağız.

Burada iki farklı zaman kavramı özellikle önemli.

Valid time

O bilgi gerçek dünyada ne zaman geçerliydi?

Observed time

Biz o bilgiyi ne zaman öğrendik?

Bu ayrım geçmişe dönük model testleri için hayati.

1 Ağustos 2026 saat 18.00'de ne biliyorduk?

Sistemin ileride şu soruyu cevaplayabilmesini istiyoruz:

“1 Ağustos 2026 saat 18.00 itibarıyla veri tabanımız ne biliyordu?”

Bugünün bilgilerini alıp geçmişe götürmek kolaydır.

Ama bu data leakage yaratır.

Biz geçmiş modeli gerçekten geçmişte sahip olduğu bilgiyle çalıştırmak istiyoruz.

Bu nedenle altyapımızın merkezindeki fikirlerden biri:

Event Sourcing

olacak.

Her şey bir olay

Transfer:

PLAYER_TRANSFERRED

Sakatlık:

PLAYER_INJURED

İyileşme:

PLAYER_RETURNED

Teknik direktör:

COACH_CHANGED

Maç:

MATCH_FINISHED

Kadrolar:

LINEUP_CONFIRMED

Ceza:

PLAYER_SUSPENDED

Her olay world state'i değiştirecek.

Kabaca:

Event
   ↓
Football Event Bus
   ↓
State Engine
   ↓
Feature Engine
   ↓
Prediction Engine
   ↓
Simulation Engine

Veri: Tek kaynağa bağlı olmayacağız

Transfermarkt önemli bir kaynak.

Ama tek kaynak olmayacak.

Hedefimiz farklı kategorilerde çok sayıda kaynağı bağlayabilecek bir collector mimarisi.

Örneğin:

Federation Collectors
League Collectors
Club Collectors
Transfer Collectors
Statistics Collectors
News Collectors
Market Value Collectors
Odds Collectors
Weather Collectors
Historical Data Collectors
              ↓
           Raw Lake
              ↓
         Normalization
              ↓
      Entity Resolution
              ↓
        Validation
              ↓
        Canonical DB

Bazı kaynaklar API olabilir.

Bazıları lisanslı veri feed'i olabilir.

Bazıları izin verilen otomatik veri toplama yöntemleri olabilir.

Bazıları manuel doğrulama gerektirebilir.

Burada önemli bir prensibimiz daha olacak:

Bir kaynağa ulaşabiliyor olmak o verinin ticari kullanım hakkına sahip olduğumuz anlamına gelmez.

Bu nedenle kullanım koşulları, lisanslama, rate limit ve veri sahipliği projenin teknik mimarisi kadar ciddi ele alınacak.

Raw veriyi kaybetmeyeceğiz

Collector bir kaynaktan veri çektiğinde yalnız normalize edilmiş sonucunu saklamak büyük hata olur.

Ham veri de tutulacak.

Örneğin:

/raw
    /source-a
    /source-b
    /federation
    /clubs
    /matches

Neden?

Çünkü iki yıl sonra parser'ımızdaki bir hatayı fark edebiliriz.

Ham veri elimizdeyse:

yeniden işleyebiliriz.

Yoksa:

tarih kaybolmuştur.

Entity Resolution

Bu proje yapılırken muhtemelen en az konuşulup en çok küfür ettirecek bölümlerden biri bu olacak.

Aynı oyuncu farklı kaynaklarda:

Mohamed Salah
M. Salah
Mohamed S.
M Salah

olarak bulunabilir.

Kulüplerin isimleri değişebilir.

Liglerin sponsor isimleri değişebilir.

Oyuncular aynı isimde olabilir.

Transfer kayıtlarında yazım hatası olabilir.

Bu yüzden merkezi bir kimlik sistemi kuracağız.

Her gerçek dünya varlığının bizim sistemimizde canonical ID'si olacak.

PlayerId
ClubId
CoachId
CompetitionId
MatchId

Dış kaynak ID'leri bunlara map edilecek.

Model doğrudan kaynak isimleriyle çalışmayacak.

Kaynak güvenilirliği

Her veri aynı değerde değildir.

Resmi kulüp açıklaması ile sosyal medyada dolaşan transfer söylentisi aynı confidence ile modele giremez.

Bu nedenle kaynak katmanında:

$$R_s = SourceReliability$$

tutmayı planlıyoruz.

Örneğin olaylar:

source_count
source_reliability
event_confidence
verification_state

taşıyabilir.

Çelişkili bilgiler conflict resolution sistemine girebilir.

Söylenti bile ayrı bir evren olabilir

Bu bizi çok güzel bir özelliğe getiriyor.

Sistem yalnız gerçekleşen dünyayı simüle etmek zorunda değil.

Kullanıcı şunu sorabilmeli:

“Bu transfer gerçekleşirse ne olur?”

Örneğin:

Universe A

Mevcut dünya.

Universe B

Belirli oyuncu transfer edildi.

Sonra iki state ayrı ayrı simüle edilir.

Championship

Current: 18.4%
Scenario: 27.9%

Δ = +9.5 percentage points

Ama yalnızca şampiyonluk değil:

Expected Points
Expected Goals
Top 2
Top 4
European Qualification
Cup Probability
Squad Depth
Attack Strength
Rotation Quality

gibi sonuçlar karşılaştırılabilir.

Scenario Engine

Bu sistemin en heyecan verici parçalarından biri olacak.

Kullanıcı gelecekte gerçekleşebilecek olayları kendisi oluşturabilecek.

Örneğin:

Bir futbolcu üç ay sakatlanırsa?

Teknik direktör ayrılırsa?

Takıma altı puan ceza verilirse?

Yeni santrfor gelirse?

Rakip Avrupa'da yarı finale kadar gider ve fikstürü sıkışırsa?

Bir oyuncu sezon sonuna kadar oynayamazsa?

Current world-state'i değiştirmeyeceğiz.

Fork oluşturacağız.

$$World_A = Current$$

$$World_B = Current + Scenario$$

İki dünya ayrı ayrı simüle edilecek.

Bu noktada artık futbol tahmin sitesinden çıkıp gerçek bir:

Football Scenario Laboratory

haline geliyoruz.

World Simulation Engine

Bir şampiyonluk ihtimalinin tek sezon simülasyonundan anlamı yok.

Güncel world state'i aldıktan sonra geleceği:

$$N=10,000$$

$$N=100,000$$

ve gerektiğinde daha fazla kez simüle edeceğiz.

Her evrende:

• maç sonuçları,

• takım state belirsizliği,

• oyuncu availability,

• performans varyansı,

• fikstür,

• yorgunluk

örneklenebilir.

Sonrasında:

Championship        27.42%
Top 2               53.61%
Top 4               78.04%
Europe              89.12%
Relegation           0.19%

Expected Points      72.8
Median Points        73
90% Interval         62–83

gibi dağılımlar üretilebilir.

Tek sayı değil, belirsizlik

Bir başka temel prensibimiz:

Model kendinden ne kadar emin olmadığını da bilmeli.

Dolayısıyla:

Team Strength = 84

yerine mümkün olduğunca:

$$Strength = 84.1$$

$$90%CI=[80.8,87.4]$$

gibi dağılımlarla çalışmak istiyoruz.

Yeni yükselmiş bir takım hakkında çok az veri varsa belirsizliği yüksek olmalı.

Yıllardır takip ettiğimiz bir takımda belirsizlik daha dar olabilir.

Bilmiyorsak bilmiyoruz demeyi modelin matematiğine koymak istiyoruz.

Records Engine

Projeyi yalnız gelecekle sınırlamıyoruz.

Elimizde doğru temporal veri tabanı oluştuğunda futbol tarihini de sorgulanabilir hale getirmek istiyoruz.

Örneğin:

Süper Lig tarihindeki en uzun galibiyet serisi nedir?

kolay soru.

Ama sistem zamanla şunları da cevaplayabilmeli:

21 yaşından küçük bir oyuncunun bir sezonda attığı en fazla deplasman golü?

Trabzonspor'un Galatasaray karşısındaki en uzun yenilmezlik serisi?

Son 20 yılda lige yükselen takımlar arasında ilk 10 haftada en fazla puan toplayan takım?

Bir sezonda deplasmanda hiç kaybetmeden en uzun seri yapan teknik direktör?

Bunların her biri için önceden elle “rekor” tanımlamak istemiyoruz.

Bunun yerine bir:

Football Query Engine

kurmak istiyoruz.

Örneğin:

entity = player
competition = super_league
age < 21
metric = away_goals
scope = season
aggregation = sum
sort = descending
limit = 1

ve sorgu motoru rekoru kendi bulsun.

Doğal dil katmanı

Burada büyük dil modellerinin yeri de olacak.

Ama çok net bir mimari sınırla.

LLM'ye:

“Trabzonspor'un şampiyonluk ihtimali kaç?”

diye sorup kafasından sayı üretmesini istemiyoruz.

LLM'nin görevi:

$$NaturalLanguage \rightarrow StructuredFootballQuery$$

olacak.

Hesabı bizim sistemimiz yapacak.

Örneğin kullanıcı:

“Salah gelirse Trabzonspor'un Şampiyonlar Ligi'nde son 16 ihtimali ne kadar değişir?”

diye soracak.

Dil katmanı bunu:

1. entity resolution,

2. scenario creation,

3. competition query,

4. simulation request

haline çevirecek.

Rakamı ise Football Digital Twin üretecek.

Explainability

Model:

Championship
26.2% → 34.8%

dedi.

İlk sorumuz:

Neden?

olmalı.

Mümkün olduğunca contribution decomposition göstermek istiyoruz.

Örneğin:

New Transfer                 +4.2 pp
Recent Team Performance      +1.8 pp
Rival Points Loss            +1.4 pp
Fixture Change               +0.9 pp
Squad Availability           +0.5 pp
Other                        -0.2 pp

Modeli kara kutu halinde kullanıcıya bırakmak istemiyoruz.

Prediction History

Bugünkü tahmin de yarın unutulmayacak.

Her model snapshot'ı saklanacak.

Örneğin:

Trabzonspor Championship Probability

01 Aug     11.2%
08 Aug     13.8%
15 Aug     17.4%
22 Aug     23.9%
29 Aug     29.7%

Her değişimin yanında sebepler bulunabilecek.

Böylece yalnız:

“Bugün ne düşünüyoruz?”

değil:

“Neden fikrimiz değişti?”

sorusunu da cevaplayabiliriz.

Database Architecture

İlk canonical veri kaynağımız için tercihimiz:

PostgreSQL

Çünkü futbol verisinin önemli bölümü doğal olarak ilişkisel.

Player
↓
Contract
↓
Club
↓
Squad
↓
Match
↓
Competition

gibi ilişkiler SQL için son derece uygun.

Fakat her şeyi PostgreSQL'e zorlamayacağız.

Analytics: ClickHouse

Milyonlarca event oluşmaya başladığında analitik sorgular için farklı ihtiyaç doğacak.

Örneğin:

Son 15 yıldaki bütün şut eventlerini tara.

28 yaş üstü santrforların deplasman performanslarını karşılaştır.

Bir ligdeki 20 milyon pas eventini aggregate et.

Bu tarz OLAP workloads için ileride:

ClickHouse

kullanmayı planlıyoruz.

PostgreSQL:

canonical truth

ClickHouse:

analytical speed

Object Storage

Ham veriler, büyük çıktılar, model artifact'ları ve historical dump'lar için:

S3-compatible storage

kullanılabilir.

Geliştirme ortamında:

MinIO

iyi adaylardan biri.

Cache

Canlı kullanımda her sorguyu yeniden hesaplamak saçma olacaktır.

Bunun için:

Redis

• cache,

• ephemeral state,

• job information,

• rate limiting

gibi görevlerde kullanılabilir.

Event Stream

İlk gün Kafka kurup 47 mikroservis oluşturarak kendimize eziyet etmeyeceğiz.

Başlangıçta:

Modular Monolith

yaklaşımı daha doğru.

Fakat event mimarisini baştan düşünerek ilerleyeceğiz.

Ölçek büyüdüğünde:

• Redpanda

• Kafka

gibi event streaming çözümlerine geçilebilir.

Programlama dili

Bu proje için “tek dil kullanacağız” gibi ideolojik bir karar vermiyoruz.

Doğru işi doğru araca vereceğiz.

Modelleme

Python

Burada kararımız oldukça net.

Ekosistem:

• NumPy

• SciPy

• Polars

• PyTorch

• JAX

• PyMC

• scikit-learn

• XGBoost

• LightGBM

gibi araçlarla model araştırması için muazzam.

Backend

İlk sürümlerde:

Python + FastAPI

mantıklı başlangıç.

Model ile backend arasında gereksiz dil bariyeri oluşturmaz.

Ürün büyüdüğünde servisleri gerektiği şekilde ayırabiliriz.

Frontend

TypeScript + Next.js

Modern, hızlı, SSR/SEO tarafı güçlü ve ürün geliştirme temposu yüksek.

Performans kritik servisler

Her şeyi ilk günden Rust ile yazmanın anlamı yok.

Ama gerçekten ihtiyacımız olduğunda:

Rust

özellikle:

• yüksek hacimli collector,

• parsing,

• concurrency,

• simulation'ın bazı kritik parçaları,

• düşük latency servisler

için devreye girebilir.

İlk stack

Bugünkü mimari düşüncemiz kabaca:

MODEL / ML
Python

DATA PROCESSING
Python
Polars

COLLECTORS
Python
HTTPX
Playwright
Rust when necessary

BACKEND
FastAPI

FRONTEND
TypeScript
Next.js

CANONICAL DATABASE
PostgreSQL

ANALYTICS
ClickHouse

CACHE
Redis

OBJECT STORAGE
S3 / MinIO

EVENT STREAM
Redpanda / Kafka — when needed

ML EXPERIMENTS
MLflow

WORKFLOW ORCHESTRATION
Prefect / Dagster

CONTAINERS
Docker

Kubernetes?

Belki bir gün.

Ama daha ilk futbolcu kaydını oluşturmadan Kubernetes cluster kurup “ölçeklenebiliriz” diye kendimizi kandırmayacağız.

Önce çalışan sistem.

Sonra ölçek.

Database düşündüğümüzden çok daha büyük olacak

Uzun vadeli şema içerisinde yalnızca birkaç örnek:

players
player_aliases
player_states
clubs
club_states
squads
squad_memberships
contracts
transfers
transfer_rumours
market_values
injuries
suspensions
coaches
coach_tenures
competitions
competition_seasons
competition_rules
fixtures
matches
lineups
appearances
match_events
advanced_events
stadiums
referees
weather_events
travel_events
odds
rankings
sources
source_entities
source_reliability
raw_snapshots
football_events
model_versions
model_snapshots
simulations
simulation_runs
scenarios
scenario_events
records
record_queries

Ve bunun son liste olduğunu düşünmüyoruz.

Modelimizin rakibi yine kendi modelimiz olacak

En önemli bilimsel prensiplerden biri:

Yeni model eskisini yenemiyorsa production'a girmeyecek.

Baseline'larımız olabilir:

Naive Table
Elo
Poisson
Dixon-Coles
Market Consensus
Model v0.1
Model v0.2
Model v0.3

Her model historical backtest'e girecek.

Ölçmeden “iyi model” demeyeceğiz

Model performansında kullanacağımız metriklerden bazıları:

• Log Loss

• Brier Score

• Ranked Probability Score

• Calibration Error

• Goal likelihood

• MAE

• probability calibration

• championship calibration

• relegation calibration

Örneğin model tarih boyunca %30 dediği olayların gerçekten yaklaşık %30'unda başarılı mı?

Bu soru:

“Geçen hafta üç maçı bildik.”

cümlesinden çok daha değerlidir.

Ablation testleri

Bir başka kritik deney:

Model A

Sadece skor.

Model B

Skor + kadro.

Model C

Skor + kadro + transfer.

Model D

Skor + kadro + transfer + sakatlık.

Model E

Hepsi + gelişmiş event data + taktik + fikstür.

Sonra bakacağız:

Hangi veri gerçekten fayda sağlıyor?

Çünkü modele 700 değişken koymak otomatik olarak modeli iyi yapmaz.

Bazı değişkenler yalnızca gürültüdür.

Bunu sezgiyle değil, deneyle ayıracağız.

Subscription Product

Bütün bu altyapı yalnız laboratuvarda kalmayacak.

Son kullanıcıya web üzerinden abonelik modeliyle açmayı hedefliyoruz.

Ürün katmanları zamanla şu yapılara dönüşebilir:

Match Center

Maç tahmini, dağılımlar, kadrolar, team state ve açıklamalar.

League Intelligence

Şampiyonluk, Avrupa, küme düşme ve sıralama olasılıkları.

Club Intelligence

Bir takımın yaşayan digital twin'i.

Player Intelligence

Oyuncu state'i ve projeksiyonları.

Transfer Lab

Transfer gerçekleşirse ne olur?

Scenario Lab

Alternatif futbol evrenleri.

Records Lab

Tarihsel futbol sorguları.

Model Lab

Model metodolojisi, benchmark ve calibration.

API

Profesyonel kullanım.

B2C'den fazlası

Uzun vadede ürün yalnız futbolsevere hitap etmek zorunda değil.

Potansiyel kullanıcılar:

• taraftarlar,

• spor gazetecileri,

• içerik üreticileri,

• analistler,

• scouting ekipleri,

• kulüpler,

• medya kuruluşları,

• veri şirketleri

olabilir.

Dolayısıyla model:

$$B2C + B2B + API$$

olarak büyüyebilir.

Ama oraya daha çok yol var.

İlk hedefimiz dünya değil

Dünyanın bütün liglerini ilk günden modellemeye çalışmak yapılabilecek en büyük hatalardan biri olur.

İlk hedefimiz çok daha net:

Süper Lig'i mümkün olduğunca derin modellemek.

Bir ligi gerçekten iyi yapalım.

Veri pipeline'ı çalışsın.

Temporal database otursun.

Event sourcing çalışsın.

Entity resolution otursun.

Player Engine oluşsun.

Team State Engine oluşsun.

Match Engine kalibre olsun.

Simulation Engine doğrulansın.

Scenario Engine çalışsın.

Records Engine sorgu üretsin.

Sonra aynı mimari:

Premier League,

Bundesliga,

La Liga,

Serie A,

Ligue 1,

Avrupa kupaları

ve diğer organizasyonlara genişlesin.

Üç temel motor

Bugün kafamızdaki sistemin özü şu:

$$\boxed{ Player Intelligence \rightarrow Team State \rightarrow Football World Simulation }$$

1. Player Intelligence Engine

Oyuncuyu modelleyecek.

2. Team State Engine

Oyunculardan, teknik ekipten ve çevresel değişkenlerden takımın yaşayan state'ini üretecek.

3. Football World Simulator

Bu state'lerden geleceği simüle edecek.

Bunların üzerinde:

$$Scenario Engine$$

$$Records Engine$$

$$Query Engine$$

$$Explainability Engine$$

$$Natural Language Layer$$

bulunacak.

Peki neden bu kadar geniş?

Çünkü problemi küçültürsek alacağımız cevap da küçük olur.

Bir takımın şampiyon olup olmayacağını gerçekten analiz etmek istiyorsak sadece puan tablosuna bakamayız.

Bir futbolcunun değerini anlamak istiyorsak sadece piyasa değerine bakamayız.

Bir transferin etkisini anlamak istiyorsak yalnızca transfer olduktan sonra skorların değişmesini bekleyemeyiz.

Bir modelin iyi olduğunu söylemek istiyorsak üç doğru tahmin ekran görüntüsü paylaşamayız.

Ve geçmişi analiz etmek istiyorsak bugünkü bilgilerimizi geçmişe taşıyamayız.

Futbol karmaşık.

Biz de problemi sırf çözmesi kolay olsun diye olduğundan basit göstermeyeceğiz.

Koddan daha değerli bir şey inşa etmek

Bir noktadan sonra bu projenin asıl değeri yalnız algoritmalar olmayacak.

Yıllar içerisinde veri tabanımız şunları bilecek:

O futbolcu hangi gün hangi takımdaydı?

O gün piyasa değeri neydi?

Sakat mıydı?

Model onu nasıl değerlendiriyordu?

Takımın state'i neydi?

Piyasa ne düşünüyordu?

Fikstür nasıldı?

Hangi transfer söylentileri vardı?

Sonra ne gerçekleşti?

Model nerede yanıldı?

Sonraki versiyon bunu düzeltti mi?

Bu noktada elimizde yalnız bir uygulama olmayacak.

Elimizde:

yaşayan, versiyonlanmış, temporal bir futbol bilgi sistemi

olacak.

Bunun birkaç yılda oluşturacağı veri birikimi, sonradan yalnız kod yazarak kolayca kopyalanabilecek bir şey değil.

Şimdi başlıyoruz

Önümüzde oldukça uzun bir yol var.

Muhtemelen yanlış modeller kuracağız.

Bazı hipotezlerimiz çöpe gidecek.

Bazı veri kaynakları düşündüğümüz kadar faydalı çıkmayacak.

Bazı mimari kararlarımızı yeniden yazacağız.

Bazı geceler bir oyuncunun aynı kişi olduğunu iki farklı veri kaynağına anlatmaya çalışarak geçecek.

Bazı modeller çok güzel görünüp backtest'te darmadağın olacak.

Ve muhtemelen bundan keyif alacağız.

Çünkü mühendislik biraz da budur.

Gerçeği basitleştirerek haklı çıkmaya çalışmak değil;

kurduğun sistem yanlışsa onun yanlış olduğunu ölçebilecek kadar iyi bir sistem kurmak.

TUNIX Football Digital Twin ile futbol için tam olarak bunu yapmak istiyoruz.

Bir tahmin tablosu üretmek değil.

Bir API'nin verdiği sayıları güzel grafiklere koymak değil.

Bir yapay zekâya skor sordurmak hiç değil.

Kendi verimizi.

Kendi state'imizi.

Kendi modellerimizi.

Kendi simülasyon motorumuzu.

Kendi futbol dünyamızı.

sıfırdan kuracağız.

Ne kadarını başarabileceğimizi bugün bilmiyoruz.

Zaten heyecan verici olan tarafı da bu.

Vira Bismillah.

TUNIX — İnsan İçin Teknoloji.

Bazıları bütçesiz oldukları için de dağılmaz.

Eksik parça bulunur.
Bozulan sensör değiştirilir.
Yetişmeyen kartın etrafından dolaşılır.
Olmayan donanım simüle edilir.
Eksik insanın işi bir başkası tarafından öğrenilir.

Mühendislik zaten biraz da budur.

Elinizdekilerle, elinizde olmayanların arasındaki boşluğu kapatma sanatı.

Ama bir mühendislik takımının başına gelebilecek öyle bir problem vardır ki lehimle düzelmez, kodla patch’lenmez, torna tezgâhında yeniden üretilemez:

Koltuk sevdası.

Çünkü bir noktadan sonra projenin nasıl daha iyi olacağı değil, kimin yöneteceği konuşulmaya başlanır.

Teknik doğruların yerini kişisel otorite alır.

Üreten insanların rahatsız edici bulunmaya başladığı, sorgulamayan insanların ise “uyumlu” kabul edildiği bir düzen doğar.

Sonra herkes hâlâ bir takım olduğunu düşünür.

Formalar vardır.

Logolar vardır.

Kaptan vardır.

Toplantılar vardır.

Belki takım odasının kapısında aynı isim bile yazıyordur.

Ama içeride mühendislik kalmamıştır.

Benim anlatacağım hikâye biraz bunun hikâyesi.

İsim vermeyeceğim.

Çünkü gerek yok.

İnsanların isimleri birkaç yıl sonra unutulur.

Ortaya çıkardıkları — ya da çıkaramadıkları — şeyler kalır.

Bir tekne yapmıyorduk

Hydronom dışarıdan bakıldığında bir otonom deniz aracıydı.

Bir gövde.

Motorlar.

Sensörler.

Bilgisayar.

Elektronik.

Ve bunları taşıyan mekanik bir platform.

Ama benim için hiçbir zaman bundan ibaret olmadı.

Çünkü bir otonom sistemin asıl ürünü gövdesi değildir.

Asıl ürün, o gövdenin ne yapacağına kendi başına karar verebilmesini sağlayan zekâdır.

Zamanla Hydronom’un içerisinde navigasyon, görev yönetimi, arrival ve hold davranışları, güvenlik katmanları, aktüatör yönetimi, araç durum yönetimi, telemetri, haberleşme, sensör işleme ve karar mekanizmaları birbirinden ayrılmaya başladı.

Sistem büyüdü.

Bir yarışma teknesinin yazılımı olmaktan çıkıp gerçek bir otonom sistem mimarisine yaklaşmaya başladı.

Bu dönüşüm tesadüfen olmadı.

Çünkü önümüze sürekli problem çıkıyordu.

Ve çoğu zaman önümüzde iki seçenek vardı:

“Olmuyor.” demek.

Ya da:

“Başka nasıl yaparız?” diye sormak.

Biz yıllarca ikinci soruyu sorduk.

Olmayan şeylerle çalışan bir sistem

Bir noktada GPS yoktu.

Peki sistem tamamen kör mü kalacaktı?

Hayır.

IMU ve derinlik bilgisiyle daha düşük kabiliyetli bir çalışma modu tasarlandı.

Sistem bazı yeteneklerini kaybettiğinde tamamen çökmek yerine sahip olduğu sensörlere göre davranış değiştirebilecek hâle getirildi.

Bir başka yerde haberleşme güvenliği problemi vardı.

Telemetri yalnızca “paketi gönder, karşı taraf alsın” mantığında bırakılmadı.

Mesaj doğrulama ve bütünlük kontrolü düşünüldü.

Başka bir problemde sensör verisinin kendisi güvenilir değildi.

Bir sensöre körü körüne güvenmek yerine sistemin mevcut kabiliyetini değerlendiren yapılar geliştirildi.

Bir modül yetişmediğinde bütün sistemin onunla birlikte ölmemesi gerekiyordu.

Bu nedenle bileşenleri birbirinden ayırmaya başladık.

Decision başka bir şeydi.

Task başka bir şeydi.

Safety başka bir şeydi.

Actuator yönetimi başka bir şeydi.

Araç durumunun otoritesi bile ayrı düşünülüyordu.

Neden?

Çünkü mühendislikte çok erken öğrendiğim bir gerçek vardı:

Bir sistem ancak parçalarından biri hata verdiğinde hayatta kalabiliyorsa gerçekten sistemdir.

Kâğıt üzerinde güzel görünen mimariler yapmak kolaydır.

Asıl mesele cumartesi gecesi sensörünüz çalışmadığında ne yaptığınızdır.

Bizim hikâyemizin önemli bir bölümü de buydu.

Problem çıkıyordu.

Bakıyorduk.

Düşünüyorduk.

Bazen oldukça tuhaf bir çözüm buluyorduk.

Sonra kervanı yeniden yürütüyorduk.

Bir şey eksikse simüle ediyorduk.

Bir şey güvenilmezse çevresine koruma koyuyorduk.

Bir komponent yoksa sistem mimarisini onsuz yaşayabilecek hâle getiriyorduk.

Bazen mühendislik açısından ideal olmayan ama sistemi ayakta tutabilecek geçici çözümler geliştiriyorduk.

Çünkü laboratuvar ortamında “ideal sistem” tasarlamak başka bir şeydir.

Gerçek dünyada çalışan sistem yapmak başka bir şey.

Ve Hydronom’un asıl değeri biraz burada oluştu.

Sonra Hydrocard geldi

Bir süre sonra başka bir problem açıkça görülmeye başladı.

Otonom bir aracın içerisinde sürekli yeni kartlar, dönüştürücüler, bağlantılar, kablolar ve geçici elektronik çözümler birikiyordu.

Her yeni bağlantı başka bir hata noktasıydı.

Her konnektör başka bir risk.

Her ek kart başka bir entegrasyon problemi.

Bunun daha iyi bir yolu olmalıydı.

İşte Hydrocard burada doğdu.

Fikir aslında oldukça basitti:

Aracın beynini ve sinir sistemini dağınık kartlardan kurtarıp mümkün olduğunca bütünleşik bir platform hâline getirmek.

Hydrocard’ın görevleri düşünüldü.

Mimarisi oluşturuldu.

Kart baştan sona tasarlandı.

İş yalnızca “şöyle bir kart yapsak güzel olur” seviyesinde kalmadı.

Gerçek bir mühendislik ürünü olarak tasarlandı.

Sonra duvara çarptık.

Elektronik kartı tasarlamak yetmiyordu.

Onu hayata geçirmek gerekiyordu.

Ve daha da önemlisi:

O kartın içerisinde yaşayacak gömülü yazılımı yazabilecek bir ekip gerekiyordu.

İşte aylar boyunca çözülemeyen problemlerden biri buydu.

Kart vardı.

Fikir vardı.

Mimari vardı.

İhtiyaç vardı.

Ama kartın mikrodenetleyicisini gerçekten ayağa kaldırabilecek, çevre birimlerini sürebilecek, haberleşme katmanlarını güvenilir biçimde yazabilecek ve donanımı sistemin geri kalanıyla bütünleştirebilecek sürdürülebilir bir gömülü yazılım ekibi bir türlü oluşmadı.

Bu, dışarıdan bakıldığında küçük bir personel eksikliği gibi görülebilir.

Değildi.

Çünkü elektronik kart üzerinde birkaç LED yakmak gömülü sistem geliştirmek değildir.

UART çalıştırmak da değildir.

Bir yarışma demosunda motor döndürmek hiç değildir.

Gerçek gömülü sistem geliştirme;

watchdog’dur,

fault handling’dir,

zamanlamadır,

deterministik davranıştır,

memory yönetimidir,

sensör sürücüleridir,

haberleşme protokolleridir,

donanım-yazılım entegrasyonudur,

ve en önemlisi sistemin haftalar sonra da aynı güvenilirlikle çalışmasını sağlayabilmektir.

Hydrocard’ın önündeki büyük duvarlardan biri buydu.

Kartın zekâsını yazabilecek insan zinciri kurulamadı.

Aylar geçti.

Fakat ihtiyaç ortadan kalkmadı.

Ve daha büyük bir problem vardı: mekanik

Otonom araç projelerinde çok sevilen bir yanılgı vardır.

Ortaya güzel bir gövde çıkınca aracın büyük bölümünün tamamlandığı düşünülür.

CAD modeli güzeldir.

Gövde heybetlidir.

Metal parlar.

Motor yatakları yapılmıştır.

Montaj tamamlanmıştır.

Fotoğraf çekilir.

Ve ortaya fiziksel olarak “araç” diyebileceğiniz bir şey çıkar.

Ama çok basit bir soru sormak gerekir:

Sonra?

O gövde ne biliyor?

Ne görüyor?

Ne anlıyor?

Ne karar verebiliyor?

Beklenmeyen bir durumda ne yapıyor?

Rotasından çıktığında nasıl geri dönüyor?

Sensörü yanlış veri verdiğinde bunu anlayabiliyor mu?

Haberleşme kesildiğinde ne yapıyor?

Motorlardan biri beklenen tepkiyi vermediğinde bunu fark ediyor mu?

Eğer bunların cevabı yoksa karşınızda otonom araç yoktur.

Karşınızda yalnızca mekanik bir platform vardır.

Ve burada yıllarca canımı sıkan temel fikir ayrılıklarından biri buydu.

Mekanik, sistemin kendisi değildir.

Mekanik sistem, zekâyı dünyaya bağlayan bedendir.

Elbette çok değerlidir.

İyi mekanik tasarım olmadan kontrolcü ne kadar iyi olursa olsun araç başarısız olur.

Yanlış ağırlık merkezi bütün hesabınızı bozar.

Kötü tahrik yerleşimi kontrol edilebilirliği mahveder.

Titreşim sensör verisini kirletir.

Su izolasyonu kötü yapılırsa dünyanın en iyi yazılımı bir damla suya yenilebilir.

Ama bunun tersi de aynı derecede doğrudur.

Üzerinde karar sistemi bulunmayan mükemmel bir gövdenin otonom sistem açısından değeri sınırlıdır.

Çünkü:

Akıl taşımayan bir iskelet, ne kadar güzel imal edilirse edilsin yine iskelettir.

Hydronom’un gücü gövdesinin ne kadar güzel göründüğü değildi.

Onu diğer araçlardan ayırması gereken şey;

düşünmesi,

karar vermesi,

hata toleransı,

yazılım mimarisi,

sensörlerini anlamlandırması,

ve gerçek dünyada kendi davranışını üretebilmesiydi.

Bunu anlatmak ise her zaman kolay olmadı.

Çünkü fotoğrafta kod görünmez

Mekanik parçanın çok büyük bir avantajı vardır.

Fotoğrafını çekebilirsiniz.

Bir masanın üzerine koyabilirsiniz.

İnsanlara gösterebilirsiniz.

“Bunu biz yaptık.” dersiniz.

Yazılımda ise altı ay uğraştığınız bir safety architecture bazen ekranda yalnızca aracın saçma bir hareket yapmaması şeklinde görünür.

İki hafta uğraştığınız fault recovery sistemi yarışma boyunca hiç devreye girmezse kimse onun varlığını bile fark etmez.

İyi bir state management sistemi alkış almaz.

İyi bir embedded driver fotoğrafta güzel görünmez.

Doğru tasarlanmış bir haberleşme protokolünü elinize alıp Instagram’a koyamazsınız.

Ve öğrenci takımlarında bu yüzden tehlikeli bir durum oluşabilir:

Görünen mühendislik, görünmeyen mühendisliğin önüne geçer.

Oysa gerçek otonom sistemlerde çoğu zaman değer tam ters taraftadır.

Gövdeyi yeniden üretirsiniz.

Bir motoru değiştirirsiniz.

Yeni bir sensör satın alırsınız.

Ama yıllar içinde oluşmuş sistem bilgisini Amazon’dan sipariş veremezsiniz.

İşte kavga aslında burada başladı

Zamanla mesele teknik olmaktan çıktı.

Kim hangi işi yapıyor?

Kim hangi kararı veriyor?

Kim takımın başında?

Kim kime hesap verecek?

Kim hangi unvanı taşıyacak?

Bunlar giderek daha fazla önem kazanmaya başladı.

Ve benim açımdan en absürt taraf şuydu:

Biz bir yandan sistemdeki gerçek mühendislik açıklarını kapatmaya uğraşıyorduk.

Embedded ekip oluşmuyor.

Elektronik üretim yetişmiyor.

Mekanik tarafta entegrasyon problemleri çıkıyor.

Sensör sıkıntısı çıkıyor.

Haberleşme sıkıntısı çıkıyor.

Kaynak sıkıntısı çıkıyor.

Biz yine bir yol bulmaya çalışıyoruz.

Ama bütün bunların ortasında bazı insanlar için esas problem hâlâ organizasyon şemasındaki kutular olabiliyordu.

Bunu anlamakta zorlandım.

Hâlâ da zorlanıyorum.

Çünkü önünüzde çalışmayan bir araç varken kaptanlık makamının ne önemi vardır?

Araç çalışmıyorsa kaptan kimin kaptanıdır?

Koltuk korunurken makine kaybedildi

Sonunda ben ayrıldım.

Fakat ayrılık yalnızca bir insanın takımdan çıkması değildi.

Bunu o gün anlatmak zordu.

Bugün sonuçlara bakınca çok daha kolay.

Çünkü Hydronom benimle birlikte o yapıdan ayrıldı.

Hydrocard da ayrıldı.

Ve onlarla beraber;

yıllar içerisinde oluşan sistem mimarisi,

otonomi yaklaşımı,

yazılım altyapısı,

karar mekanizmaları,

geliştirme kültürü,

ve problemlere bakış biçiminin önemli bir bölümü de ayrıldı.

Bu cümle kibirli gelebilir.

O yüzden en sağlıklı ölçüyü kullanalım.

Sonrasına bakalım.

Çünkü mühendislikte iddiaların en acımasız hakemi sonuçtur.

Takımın önündeki yarışma süreçleri ilerleyemedi.

Teknik süreklilik kayboldu.

Bir dönem sürekli büyüyen sistemin yerine yeniden “yarışmaya araç yetiştirme” telaşı hakim oldu.

Ve zaman geçtikçe çok rahatsız edici bir soru ortaya çıktı:

Koltuk uğruna aslında ne korunmuştu?

Hydronom yok.

Hydrocard yok.

Otonomi mimarisi yok.

Teknik süreklilik yok.

Yarışma başarısı yok.

Peki geriye ne kaldı?

Unvanlar mı?

Fakat Hydronom ölmedi

İşin bütün ironisi burada başlıyor.

Çünkü Hydronom takımından ayrıldıktan sonra ortadan kaybolmadı.

Tam tersine hayatı ilk kez yarışma sınırlarının dışına çıktı.

Teknolojik birikiminin bir bölümü özel sektör tarafında gerçek ticari karşılık bulmaya başladı.

Ve başka bir tarafta Hydronom’un taşıdığı düşünce yaşamaya devam etti.

Oradan Tydronom doğdu.

Tydronom yalnızca isim değişikliği değildi.

Bir yarışma aracının öğrendiklerinin gerçek bir ürün yaklaşımına taşınmasıydı.

Hydronom artık yalnızca kendi başına bir proje değildi.

Bir teknolojik soyun başlangıcı olmuştu.

Daha sonra bu soy ATA gibi daha büyük sistem vizyonlarının içerisine uzanmaya başladı.

Bu yüzden bazen şakayla karışık söylediğim ama aslında oldukça ciddi bir cümle var:

Hydronom baba oldu.

Bir çocuk yaptı.

O çocuk başka sistemlerin yolunu açmaya başladı.

Bir zamanlar birkaç şamandıra arasında doğru rotayı bulmaya çalışan öğrenci projesinin genleri bugün bambaşka makinelerin içerisinde yaşamaya hazırlanıyor.

Bir proje için bundan daha büyük başarı olabilir mi?

Kupa mı?

Plaket mi?

Sahnedeki fotoğraf mı?

Bence değil.

Gerçek mühendislik mirası, projeniz artık sizin elinizde değilken bile yaşamaya devam ediyorsa oluşur.

Hydrocard’ın daha da acı ironisi

Hydrocard’ın hikâyesi ise belki bundan bile daha sert.

Çünkü kart üretilemedi.

Aylar boyunca onu gerçek anlamda ayağa kaldırabilecek elektronik ve gömülü geliştirme kapasitesi oluşturulamadı.

Ama problem gerçekti.

Dağınık elektronik mimarinin yarattığı entegrasyon yükü gerçekti.

Tek kart üzerinde daha fazla hesaplama ve kontrol fonksiyonunun birleştirilmesi ihtiyacı gerçekti.

Ve yalnızca birkaç ay sonra benzer ihtiyaçlara cevap veren bütünleşik platformların çok daha büyük yapılarda ortaya çıkmaya başlamasını görmek benim için oldukça öğreticiydi.

Bu bana şunu gösterdi:

Bizim problem tanımımız yanlış değildi.

Hydrocard gereksiz değildi.

Hayal ürünü hiç değildi.

Sadece doğru fikri ürüne dönüştürecek organizasyonel ve teknik zincir kurulamadı.

Ve mühendislik tarihinde bunun örnekleri doludur.

İyi fikirler her zaman iyi ürünlere dönüşmez.

Çünkü fikir ile ürün arasında insan vardır.

Disiplin vardır.

Teknik yeterlilik vardır.

Sabır vardır.

Ve ekip kültürü vardır.

Bir tanesi eksik olduğunda kâğıt üzerindeki en güzel kart bile yalnızca PCB dosyası olarak kalabilir.

En büyük yanılgımız neydi?

Belki benim de en büyük hatalarımdan biri şuydu:

Teknik olarak doğru bir şeyin, yeterince iyi anlatılırsa mutlaka kabul göreceğini düşünmek.

Öyle olmuyor.

Mühendislik ekipleri yalnızca mühendislikten oluşmuyor.

Ego var.

Statü var.

Gruplaşma var.

İnsan ilişkileri var.

Kendini tehdit altında hissetme var.

Ve bazen bir insan sizin ürettiğiniz şeyi kötü bulduğu için değil, sizin üretmeye devam etmenizin kendi pozisyonunu anlamsızlaştıracağından korktuğu için size direnebiliyor.

İşte burada bir takımın karakteri ortaya çıkar.

İyi kurum yetenekli insanı çoğaltır.

Kötü kurum ise yetenekli insanı törpüler.

İyi lider kendisinden daha iyi mühendisleri etrafında görmek ister.

Kötü lider ise en rahat kendisinden daha zayıf insanların arasında hisseder.

Çünkü birincisi ürün ister.

İkincisi kontrol ister.

Bir kaptanın gerçek testi

Kaptanlık bana hiçbir zaman romantik gelmedi.

Gerçek liderlik takım fotoğrafının ortasında durmak değildir.

Gerçek liderlik bazen herkes gittikten sonra laboratuvarda kalan son kişi olmaktır.

Bazen bilmediğiniz bir teknolojiyi üç gecede öğrenmektir.

Bazen başka disiplinin açık verdiği yerde “bu benim alanım değil” demek yerine problemi çözmektir.

Bazen aylarca geliştirdiğiniz şeyi çöpe atıp daha doğru bir mimariye geçmektir.

Ve en önemlisi:

Kendinizi gereksiz hâle getirecek kadar iyi bir sistem kurmaktır.

Çünkü iyi liderin en büyük başarısı, kendisi gittikten sonra takımın onu aramamasıdır.

Takım daha iyi çalışmalıdır.

Yeni insanlar gelmelidir.

Eski projeler büyümelidir.

Yeni projeler doğmalıdır.

Bilgi aktarılmalıdır.

Sonraki nesil öncekinden daha iyi olmalıdır.

Eğer bir insan gittikten sonra bütün kritik sistemler de gidiyorsa ortada kurumsallaşma problemi vardır.

Bunda giden kişinin de sorumluluğu olabilir.

Kalan yönetimin de.

Ben bugün kendi payımı da görüyorum.

Daha fazla dokümantasyon yapılabilirdi.

Daha fazla insan yetiştirilebilirdi.

Bilgi daha fazla dağıtılabilirdi.

Bazı çatışmalar daha iyi yönetilebilirdi.

Bunları inkâr etmiyorum.

Ama bir şey yine de değişmiyor:

Bir organizasyon, elindeki üretim kapasitesini korumak yerine onunla savaşmayı seçiyorsa sonuçlarına da katlanır.

Çünkü rozet makine yapmaz

Bütün bu hikâyeden sonra genç mühendislerin aklında tek bir şey kalmasını isterim.

Bir takımın değerini;

kaç kişilik olduğu,

kaç yöneticisi bulunduğu,

kaç alt takıma ayrıldığı,

kaç sponsoru olduğu,

kaç güzel render hazırladığı,

kaç sosyal medya paylaşımı yaptığı

belirlemez.

Bir soru belirler:

Çalışıyor mu?

Kart çalışıyor mu?

Kod çalışıyor mu?

Araç çalışıyor mu?

Sistem hata aldığında yaşamaya devam ediyor mu?

Gerçek dünyaya çıktığında tasarladığınız davranışı gösterebiliyor mu?

Gösteremiyorsa organizasyon şemanızın ne kadar güzel olduğunun hiçbir önemi yoktur.

Rozet makine yapmaz.

Unvan algoritma yazmaz.

Kaptanlık mikrodenetleyici programlamaz.

Toplantı tutanağı tekneyi otonom yapmaz.

Ve hiçbir yönetmelik fizik kanunlarını ikna edemez.

Sonunda zaman hakem oluyor

Bugün geriye dönüp baktığımda yaşananların hiçbirine sevinmiyorum.

Takımın başarısız olması benim başarım değildir.

Keşke ben ayrıldıktan sonra daha iyi bir Hydronom yapsalardı.

Keşke Hydrocard’dan çok daha iyi bir kart geliştirseydiler.

Keşke yarışmalara gidip bizim dönemimizin bütün sonuçlarını geçselerdi.

Bundan gerçekten mutluluk duyardım.

Çünkü teknoloji böyle ilerler.

Sonraki nesil öncekini geçer.

Geçmelidir.

Ama olmadı.

Ve aynı zaman diliminde çok garip bir terslik yaşandı.

Bir tarafta Hydronom’un çıktığı yapı küçülürken,

diğer tarafta Hydronom’un fikri büyüdü.

Bir tarafta Hydrocard yapılamazken,

diğer tarafta onun çözmeye çalıştığı problemin ne kadar gerçek olduğu hızla ortaya çıktı.

Bir tarafta makamlar korunurken,

diğer tarafta teknoloji başka yerlere göç etti.

İşte bu yüzden bugün geçmişe bakarken hissettiğim temel duygu öfke değil.

İroni.

Çok büyük bir ironi.

Çünkü yıllar boyunca korunmak için bu kadar mücadele edilen koltukların gerçekten ne kadar değersiz olduğunu sonunda zaman gösterdi.

Bir gün üniversiteden mezun oluyorsunuz.

Takım kartınız iptal ediliyor.

Laboratuvar anahtarını teslim ediyorsunuz.

WhatsApp grubundan çıkıyorsunuz.

LinkedIn’deki “Team Captain” satırı geçmiş deneyimlerin arasına gömülüyor.

Ve geriye tek bir soru kalıyor:

Ne ürettin?

Çalışan bir sistem mi?

Bir teknoloji mi?

Bir mühendis mi yetiştirdin?

Yeni bir yöntem mi bıraktın?

Senden sonra yaşamaya devam eden bir mimari mi?

Yoksa yalnızca bir dönem boyunca bir sandalyede mi oturdun?

Ben Hydronom’a baktığımda cevabımı biliyorum.

Hydronom hâlâ yaşıyor.

Başka biçimlerde.

Başka makinelerde.

Başka isimlerle.

Çocuklarıyla.

Belki bir gün torunlarıyla.

Onu doğuran takım ise bugün başka bir hikâyenin içinde.

Ve galiba bütün yaşananları anlatabilecek en kısa cümle hâlâ aynı:

Koltuk yerinde kaldı.

Gelecek ise kapıdan çıkıp gitti.

https://github.com/TunahanDso/Hydronom

Dalga boyu gerçekten fotonun toplam enerjisini mi belirliyor, yoksa yalnızca bu enerjinin uzay ve zaman içerisindeki dağılımını mı tanımlıyor?

Bu soru, Mutlak Foton Teorisi (MFT) adını verdiğim alternatif kuramsal yaklaşımın çıkış noktasını oluşturuyor.

MFT, tek bir fotonun toplam enerjisinin dalga boyundan bağımsız olabileceğini; dalga boyunun ise enerjinin miktarını değil, uzay-zaman içerisindeki yoğunluğunu ve maddeyle etkileşim biçimini belirleyebileceğini öne sürmektedir.

Bu ikinci yazıda, yaklaşımın üzerine kurulduğu üç temel aksiyomu ve bunların matematiksel anlamını ele alacağım.

Önemli bir notla başlayalım:

Burada sunulan yapı, yerleşik kuantum elektrodinamiğinin doğrulanmış sonuçlarının yerine geçtiği iddiasını taşımaz. MFT, farklı fiziksel sonuçlar üreten alternatif ve henüz doğrulanmamış bir araştırma hipotezidir.

1. Aksiyom: Fotonun Toplam Enerjisi Mutlaktır

Standart kuantum yaklaşımında bir fotonun enerjisi şu bağıntıyla ifade edilir:

$$E = h\nu = \frac{hc}{\lambda}$$

Burada:

• (E), foton enerjisini,

• (h), Planck sabitini,

• (\nu), frekansı,

• (c), ışık hızını,

• (\lambda), dalga boyunu

temsil eder.

Bu ilişkiye göre dalga boyu küçüldükçe foton enerjisi artar; dalga boyu büyüdükçe enerji azalır.

Mutlak Foton Teorisi ise ilk temel varsayımında farklı bir önerme ortaya koyar:

$$E_{\text{toplam}} = E_0 = \text{sabittir}$$

Bu varsayıma göre tek bir fotonun toplam enerjisi, dalga boyundan bağımsız ve mutlak bir büyüklüktür.

Dolayısıyla kısa dalga boylu bir foton ile uzun dalga boylu bir foton arasındaki temel fark, taşıdıkları toplam enerji miktarı değildir.

Fark, bu enerjinin uzay ve zaman içerisindeki dağılım biçimidir.

Bu ayrım oldukça önemlidir. Çünkü teorinin geri kalan bütün yapısı şu düşünce üzerine kuruludur:

Fotonun enerjisi değişmez; enerjinin yoğunluğu, yayılım biçimi ve etkileşim karakteri değişir.

Bu önerme, MFT’nin standart fizik çerçevesinden ayrıldığı en temel noktadır. Aynı zamanda teorinin deneysel olarak en ağır yükü taşıyan varsayımıdır.

Çünkü bu aksiyom doğruysa fotoelektrik etki, atomik geçişler, saçılma olayları ve elektromanyetik radyasyonun termodinamik davranışı gibi birçok olgunun yeniden açıklanması gerekir.

2. Aksiyom: Enerjinin Geometrik Bir Karşılığı Vardır

MFT’nin ikinci aksiyomu, foton enerjisi ile fotonun uzaysal profili arasında geometrik bir ilişki kurmayı amaçlar.

En basit temsil olarak bir periyotluk sinüzoidal profil ele alınabilir:

$$y(x) = A\sin(kx+\phi)$$

Burada dalga sayısı:

$$k = \frac{2\pi}{\lambda}$$

şeklinde tanımlanır.

Bu denklemdeki (y(x)), doğrudan klasik mekanikteki maddesel bir yer değiştirme olarak düşünülmek zorunda değildir.

MFT açısından bu fonksiyon, fotonun uzaysal veya alan-temelli imzasını temsil eden soyut bir geometrik profildir.

Bu profilin bir dalga boyu boyunca sahip olduğu yay uzunluğu şöyle ifade edilir:

$$ S(\lambda,A)

\int_{x_0}^{x_0+\lambda} \sqrt{ 1+ \left(\frac{dy}{dx}\right)^2 } ,dx $$

Türev alındığında:

$$ \frac{dy}{dx}

Ak\cos(kx+\phi) $$

elde edilir.

MFT’nin ikinci temel varsayımı, fotonun toplam enerjisinin bu geometrik yay uzunluğuyla ilişkili olabileceğini öne sürer:

$$E_0 = \kappa S(\lambda,A)$$

Buradaki (\kappa), birim geometrik yay uzunluğu başına düşen enerji ölçeğini temsil eden varsayımsal bir katsayıdır.

Bu yaklaşımın temel düşüncesi şudur:

Enerji yalnızca frekansla ilişkilendirilen soyut bir nicelik olmayabilir; fotonun uzaysal geometrisiyle bağlantılı bir fiziksel karşılığa da sahip olabilir.

Ancak bu noktada önemli bir açık problem bulunmaktadır.

(S(\lambda,A)) değeri genel olarak dalga boyuna ve genliğe bağlıdır. Eğer toplam enerji gerçekten sabit olacaksa, dalga boyu değiştiğinde genlik veya geometrik profil de enerjiyi koruyacak biçimde değişmelidir.

Başka bir ifadeyle MFT, yalnızca:

$$E_0 = \kappa S$$

bağıntısını ileri sürmekle yetinemez.

Aynı zamanda şu ilişkinin de açık biçimde çıkarılması gerekir:

$$A = A(\lambda)$$

Yani sabit enerji koşulu altında, genliğin dalga boyuna göre nasıl değiştiği matematiksel olarak belirlenmelidir.

Bu konu teorinin gelecekte çözülmesi gereken en önemli matematiksel problemlerinden biridir.

Küçük Eğim Yaklaşımı

Geometrik profilin eğimi yeterince küçükse:

$$\frac{2\pi A}{\lambda} \ll 1$$

koşulu altında yay uzunluğu yaklaşık olarak şu biçimde yazılabilir:

$$S(\lambda,A) \approx \lambda \left( 1+ \frac{\pi^2A^2}{\lambda^2} \right)$$

Bu yaklaşık ifade, geometrik yay uzunluğunun yalnızca dalga boyuna değil, genlik-dalga boyu oranına da bağlı olduğunu gösterir.

Sabit enerji varsayımı altında:

$$S(\lambda,A) = \text{sabittir}$$

olması gerektiğinden, dalga boyundaki bir değişim genlikte veya profilin başka bir geometrik özelliğinde karşılık bulmalıdır.

Bu nedenle MFT’nin geometrik yaklaşımı yalnızca “foton bir sinüs eğrisidir” demek değildir.

Asıl iddia şudur:

Fotonun gözlenen dalga boyu değişirken, toplam geometrik enerji ölçütünü koruyan başka iç parametreler de değişiyor olabilir.

Bu iç parametrelerin fiziksel olarak neyi temsil ettiği henüz açık değildir. Alan genliği, paket uzunluğu, polarizasyon yapısı veya daha farklı bir geometrik özellik bu modelin ilerleyen aşamalarında değerlendirilmelidir.

3. Aksiyom: Dalga Boyu Enerjiyi Değil, Yoğunluğu Belirler

MFT’nin üçüncü temel aksiyomu, toplam enerji ile enerji yoğunluğunu birbirinden ayırır.

Tek bir fotonun toplam enerjisinin sabit olduğu kabul edilirse, bu enerjinin bir dalga boyu boyunca ortalama uzaysal yoğunluğu şu şekilde tanımlanabilir:

$$ u(\lambda)

\frac{E_0}{\lambda} $$

Buradaki (u(\lambda)), ilk aşamada tek boyutlu ve etkili bir enerji yoğunluğu ölçüsüdür.

Bu bağıntıya göre:

• Dalga boyu küçüldükçe enerji daha kısa bir mesafeye yoğunlaşır.

• Dalga boyu büyüdükçe aynı toplam enerji daha geniş bir bölgeye yayılır.

• Toplam enerji değişmezken yerel etkileşim şiddeti değişebilir.

Bu düşünce, MFT’nin kısa dalga boylu ışığın maddeyle daha sert etkileşmesini açıklamak için kullandığı temel mekanizmadır.

Standart yaklaşım:

Kısa dalga boylu foton daha yüksek enerji taşır.

MFT yaklaşımı:

Kısa dalga boylu foton aynı toplam enerjiyi daha küçük bir uzay-zaman aralığında aktarır.

İki yaklaşım bazı gözlemler için benzer eğilimler üretebilir. Ancak fiziksel açıklamaları aynı değildir.

Bu nedenle MFT’nin bilimsel olarak anlamlı olabilmesi için, yalnızca bilinen sonuçları farklı kelimelerle açıklaması yeterli değildir.

Standart teoriden ayrılan, ölçülebilir ve nicel sonuçlar üretmesi gerekir.

Zamansal Yoğunluk ve Etkileşim Süresi

Bir dalga boyunun ışık hızında geçilmesi için gereken karakteristik süre yaklaşık olarak:

$$\Delta t \sim \frac{\lambda}{c}$$

şeklinde yazılabilir.

Eğer sabit toplam enerji (E_0), yaklaşık olarak bu zaman aralığında aktarılıyorsa karakteristik güç ölçeği:

$$P_{\text{etkileşim}} \sim \frac{E_0}{\Delta t}$$

olur.

Yerine koyduğumuzda:

$$P_{\text{etkileşim}} \sim \frac{E_0c}{\lambda}$$

elde edilir.

Bu ifade, dalga boyu küçüldükçe enerji aktarım hızının arttığını düşündürür.

MFT burada kısa dalga boylu fotonların daha güçlü yerel etkileşimlerini, toplam enerjinin büyümesiyle değil, enerjinin daha kısa bir zaman aralığına sıkışmasıyla açıklamaya çalışır.

Ancak bu yaklaşımın fiziksel olarak tamamlanabilmesi için şu soruların cevaplanması gerekir:

• Bir fotonun etkileşim süresi gerçekten (\lambda/c) ile mi belirlenir?

• Fotonun uzaysal uzunluğu tek bir dalga boyuna eşit midir?

• Gerçek bir foton, sonsuz sinüzoidal dalga yerine nasıl bir dalga paketiyle temsil edilmelidir?

• Enerji aktarım süresi atomik veya moleküler sistemin özelliklerine de bağlı mıdır?

Bu sorular, teorinin daha gelişmiş bir dalga paketi ve alan modeli gerektirdiğini göstermektedir.

“Foton Kuvveti” Kavramı

MFT taslağında enerji yoğunluğu yaklaşımından hareketle karakteristik bir kuvvet ölçeği önerilmektedir.

Foton momentumunun yaklaşık olarak:

$$p \sim \frac{E_0}{c}$$

olduğu ve momentum aktarımının:

$$\Delta t \sim \frac{\lambda}{c}$$

süresinde gerçekleştiği kabul edilirse:

$$F \sim \frac{\Delta p}{\Delta t}$$

ifadesinden:

$$F_{\text{foton}} \sim \frac{E_0}{\lambda}$$

ölçeğine ulaşılır.

Bu sonuç, dalga boyu küçüldükçe karakteristik kuvvetin artacağını öne sürer.

Fakat burada “kuvvet” sözcüğü dikkatli kullanılmalıdır.

Tek bir foton için ölçülebilir kuvvet, yalnızca fotonun kendi özelliğine değil;

• momentum aktarım biçimine,

• etkileşimin gerçekleştiği sisteme,

• soğurma veya yansıma durumuna,

• etkileşim süresine,

• hedef parçacığın veya yüzeyin dinamiğine

de bağlıdır.

Dolayısıyla:

$$F_{\text{foton}} \sim \frac{E_0}{\lambda}$$

ifadesi, bu aşamada evrensel ve tamamlanmış bir kuvvet yasası olarak değil, MFT içerisinde araştırılan karakteristik bir etkileşim ölçeği olarak değerlendirilmelidir.

Üç Aksiyom Birlikte Ne Söylüyor?

Mutlak Foton Teorisi’nin temel yapısı şu üç önerme üzerinde yükselir:

1. Mutlak Enerji

$$E_{\text{toplam}} = E_0$$

Tek bir fotonun toplam enerjisi dalga boyundan bağımsızdır.

2. Geometrik Enerji

$$E_0 = \kappa S(\lambda,A)$$

Enerji, fotonun uzaysal profilinin geometrik bir ölçüsüyle ilişkilidir.

3. Dalga Boyu–Yoğunluk Ayrımı

$$u(\lambda)=\frac{E_0}{\lambda}$$

Dalga boyu toplam enerjiyi değil, enerjinin uzay ve zaman içerisindeki yoğunluğunu belirler.

Bu üç aksiyom birlikte şu alternatif fiziksel tabloyu ortaya koyar:

Kısa ve uzun dalga boylu fotonlar farklı miktarda enerji taşımıyor olabilir. Aynı temel enerji, farklı geometrik ve zamansal yoğunluklarda taşınıyor olabilir.

Bu önerme güçlüdür; fakat gücü kadar ciddi bir kanıt yükü de taşımaktadır.

Teorinin Şu Anda Çözmesi Gereken Temel Sorunlar

Bir kuramsal yaklaşımın yalnızca ilgi çekici olması yeterli değildir. İç tutarlılığa ve mevcut deneylerle karşılaştırılabilir nicel sonuçlara sahip olması gerekir.

MFT açısından çözülmesi gereken başlıca problemler şunlardır:

Boyut Analizi

(\kappa) katsayısının fiziksel boyutu ve evrensel olup olmadığı açık biçimde tanımlanmalıdır.

Genlik–Dalga Boyu İlişkisi

Sabit enerji koşulunda (A(\lambda)) fonksiyonu türetilmelidir.

Lorentz Değişmezliği

Modelin özel görelilikle nasıl uyumlu olacağı gösterilmelidir. Farklı gözlemcilerin frekans ve dalga boyunu farklı ölçmesine rağmen “mutlak enerji” kavramının nasıl korunacağı açıklanmalıdır.

Fotoelektrik Etki

Elektronların neden yalnızca belirli frekansların üzerinde koparıldığı ve maksimum kinetik enerjinin frekansla neden doğrusal değiştiği, MFT tarafından nicel biçimde yeniden üretilmelidir.

Atomik Spektrumlar

Atomların belirli enerji farklarına karşılık gelen ayrık frekanslarda foton soğurması ve yayması açıklanmalıdır.

Compton Saçılması

Fotonun dalga boyu değişimi ile elektronun enerji ve momentum değişimi arasında gözlenen ilişki, sabit foton enerjisi varsayımı altında türetilmelidir.

Kara Cisim Işıması

Planck dağılımı ve sıcaklığa bağlı elektromanyetik spektrum, alternatif model içerisinde yeniden elde edilmelidir.

Çok Fotonlu Durumlar

Tek-foton varsayımının elektromanyetik alanlara, foton sayı durumlarına, girişime ve süperpozisyona nasıl genişletileceği belirlenmelidir.

Bu sorunlar teorinin kusuru olarak gizlenmemelidir.

Tam tersine, bir araştırma programının hangi sorunları çözmesi gerektiğini gösteren açık çalışma alanlarıdır.

Sonuç: Bir Teorinin Temeli, İddiası Kadar Sınırlarıyla da Tanımlanır

Mutlak Foton Teorisi, foton enerjisini dalga boyundan ayıran alternatif bir fiziksel yorum önermektedir.

Bu yaklaşıma göre:

• Fotonun toplam enerjisi sabit olabilir.

• Enerji, fotonun geometrik yapısıyla ilişkili olabilir.

• Dalga boyu enerji miktarını değil, enerji ve etkileşim yoğunluğunu belirleyebilir.

Ancak bu varsayımların bilimsel bir teoriye dönüşebilmesi için yalnızca kavramsal olarak ilgi çekici olmaları yeterli değildir.

Matematiksel olarak tutarlı, mevcut deneylerle uyumlu ve standart teoriden ayrılan yanlışlanabilir sonuçlar üretmeleri gerekir.

Bu nedenle MFT’nin sonraki aşaması, iddiaları büyütmek değil; onları daha kesin hale getirmektir.

Bir sonraki yazıda şu soruya odaklanacağım:

Mutlak Foton Teorisi standart kuantum fiziğinden tam olarak nerede ayrılıyor ve hangi gözlem iki yaklaşımı birbirinden ayırabilir?

Yazar: Tunahan Delisalihoğlu

Bu yazı, Mutlak Foton Teorisi üzerine yürüttüğüm kişisel ve deneysel olarak doğrulanmamış araştırma notları serisinin ikinci bölümüdür. Sunulan aksiyomlar yerleşik fizik kuramlarını temsil etmez; matematiksel olarak geliştirilmesi, mevcut deneylerle karşılaştırılması ve yanlışlanabilir testlere tabi tutulması gereken alternatif hipotezlerdir.

Yaklaşık bir asırdır foton enerjisi denildiğinde akla gelen ilk ifade şudur:

E = hν = hc/λ

Bu ilişki, modern kuantum fiziğinin en temel denklemlerinden biridir ve sayısız deneysel sonuçla desteklenmiştir. Ancak zaman zaman şu soruyu kendime sormaya başladım:

Dalga boyu gerçekten fotonun toplam enerjisini mi belirliyor, yoksa yalnızca bu enerjinin uzay ve zaman içerisindeki dağılımını mı tanımlıyor?

Bu soru, üzerinde çalıştığım ve Mutlak Foton Teorisi (MFT) adını verdiğim alternatif kuramsal çerçevenin çıkış noktası oldu. Bu teori, yerleşik fizik kuramlarının yerine geçtiğini iddia etmez; aksine, bazı fiziksel olgular için farklı bir yorum öneren, deneysel olarak sınanabilir bir araştırma hipotezi sunmayı amaçlar.

Çıkış Noktası

Standart yaklaşımda fotonun enerjisi dalga boyu kısaldıkça artar, dalga boyu uzadıkça azalır.

Mutlak Foton Teorisi ise farklı bir önerme ortaya koyar:

• Tek bir fotonun toplam enerjisi sabittir.

• Dalga boyu bu toplam enerjiyi değiştirmez.

• Dalga boyu, enerjinin uzay-zaman içerisindeki dağılımını ve etkileşim yoğunluğunu belirler.

Başka bir ifadeyle, teoriye göre dalga boyu enerji miktarını değil, enerjinin ne kadar "yoğun" aktarıldığını tanımlayan bir parametre olarak yorumlanabilir.

Geometrik Yaklaşım

MFT'nin en dikkat çekici yönlerinden biri, fotonu yalnızca frekans ve dalga boyuyla değil, uzaysal profilinin geometrisi üzerinden de ele almasıdır.

Bu çerçevede, bir periyotluk geometrik yay uzunluğu temel alınarak enerji için alternatif bir yorum önerilmektedir. Böylece enerji kavramı yalnızca frekansla ilişkilendirilmek yerine geometrik bir bakış açısıyla yeniden ele alınmaktadır.

Foton Kuvveti

Teoride önerilen bir diğer kavram ise "foton kuvveti" yaklaşımıdır.

Buradaki temel fikir şudur:

Kısa dalga boylu fotonlar, toplam enerjileri daha büyük olduğu için değil; aynı enerjiyi daha kısa bir uzay-zaman ölçeğinde aktarabildikleri için maddeyle daha güçlü etkileşebilir.

Bu nedenle teori, gözlenen etkileşimleri "enerji artışı" yerine "enerji yoğunlaşması" kavramıyla açıklamayı önerir.

Bu Bir Sonuç Değil, Bir Araştırma Başlangıcı

Bilimde her yeni fikir aynı sorumluluğu taşır:

Deneylerle sınanabilmek.

Mutlak Foton Teorisi de bu açıdan istisna değildir.

Teorinin bilimsel değeri, doğru çıkmasından değil; yanlışlanabilir öngörüler üretmesinden gelir.

Bu nedenle çalışmanın sonraki aşamalarında özellikle şu soruların araştırılması hedeflenmektedir:

• Atomik ve moleküler rezonansların dalga boyuna bağlı davranışı,

• Kozmolojik foton yoğunluğunun ölçeklenmesi,

• Momentum aktarımının dalga boyuna bağımlılığı.

Eğer deneysel veriler bu yaklaşımı desteklemezse, teori bu haliyle geçerliliğini yitirecektir. Bilimsel yöntemin gereği de budur.

Bundan Sonra Ne Olacak?

Bu yazı, Mutlak Foton Teorisi üzerine hazırladığım araştırma serisinin ilk notudur.

Önümüzdeki yazılarda;

• teorinin matematiksel temellerini,

• aksiyomatik yapısını,

• standart kuramla ayrıştığı noktaları,

• önerilen deneyleri,

• olası güçlü ve zayıf yönlerini

ayrıntılı olarak paylaşmayı planlıyorum.

Bilim; soru sormaktan, tartışmaktan ve fikirleri deneylerle sınamaktan güç alır.

Bu çalışma da tam olarak bu anlayışın bir ürünüdür.

Yazar: Tunahan Delisalihoğlu

Not: Bu yazı, alternatif bir kuramsal çerçeve üzerine yürütülen kişisel araştırma notlarının ilk bölümüdür. Burada sunulan fikirler, yerleşik fizik kuramlarının yerine geçtiği iddiasını taşımamakta; deneysel olarak sınanabilir bir araştırma hipotezi olarak tartışmaya açılmaktadır.

Tekstil boyahanelerinde bir rengin kumaş üzerinde doğru biçimde elde edilmesi, uzun yıllar boyunca büyük ölçüde deneyime, usta-çırak ilişkisine ve kişisel proses bilgisine dayandı.

Bu bilgi birikimi son derece değerlidir. Ancak yalnızca insanların hafızasında, alışkanlıklarında ve sezgilerinde yaşayan bir üretim modeli; büyüyen, hızlanan ve sürdürülebilirlik baskısı altına giren tekstil sektörü için artık yeterli değildir.

Geleneksel renk tutturma süreçleri çoğu zaman:

• Tekrarlanan laboratuvar denemeleri,

• Reçete düzeltmeleri,

• Bekleme süreleri,

• Hatalı üretimler,

• Yeniden boyama işlemleri,

• Fazladan su, enerji ve kimyasal tüketimi

ile sonuçlanmaktadır.

Buradaki temel problem yalnızca yanlış reçete hazırlanması değildir. Asıl maliyet; doğru reçeteye ulaşana kadar harcanan zaman, enerji, kimyasal ve üretim kapasitesidir.

Tunix Dyegen, bu problemi bir ölçüm cihazı yaklaşımıyla değil, bütünleşik bir mühendislik sistemi yaklaşımıyla ele alıyor.

Dyegen’ın amacı; referans numunenin analizinden üretilebilir reçetenin oluşturulmasına kadar uzanan süreci, 14 aşamalı disiplinli bir mühendislik iş akışına dönüştürmektir.

Bu yaklaşımda renk geliştirme süreci yalnızca gözlem ve tecrübeye dayanmaz. Ölçülür, modellenir, karşılaştırılır, simüle edilir ve fabrikanın gerçek üretim koşullarına göre optimize edilir.

Dyegen’ın temel iddiası nettir:

Tekstil boyama süreci, kontrol edilemeyen bir deneme-yanılma döngüsü değil; veriye dayalı, modellenebilir ve giderek otonomlaştırılabilir bir mühendislik problemidir.

2. Renk, Yalnızca Gördüğümüz Şey Değildir

Bir kumaşın rengi yalnızca yüzeyden ölçülen spektral değerlerden ibaret değildir.

Kumaşın ışıkla, boyayla ve proses koşullarıyla kurduğu ilişki; yapısal ve fiziksel özelliklerinden doğrudan etkilenir.

Aynı renk değeri hedeflense dahi şu değişkenler sonucu değiştirebilir:

• Lif türü ve lif karışım oranı,

• Kumaş gramajı,

• Kalınlık,

• Nem oranı,

• Örgü veya dokuma yapısı,

• Yüzey tüylülüğü,

• Parlaklık ve yüzey geometrisi,

• Ön terbiye durumu,

• Boyarmadde emilim karakteristiği.

Geleneksel spektrofotometreler yüzeyden güçlü ve değerli renk verileri üretir. Ancak üretilebilir bir reçete oluşturmak için yalnızca hedef rengin ölçülmesi yeterli değildir.

Dyegen, referans numuneyi daha geniş bir bağlam içinde değerlendirmeyi amaçlar.

Sistem; optik ölçümleri, spektral karakteristikleri, fiziksel kumaş parametrelerini, lif yapısını ve üretim koşullarını aynı karar mekanizmasında bir araya getirir.

Böylece yalnızca şu soruya cevap aranmaz:

Bu kumaş hangi renkte?

Asıl cevaplanması gereken soru şudur:

Bu renk, bu kumaş üzerinde hangi fiziksel ve kimyasal koşullar altında oluştu ve aynı sonuç kontrollü biçimde nasıl yeniden üretilebilir?

Dyegen’ın “kumaşın fiziksel DNA’sı” yaklaşımı tam olarak burada devreye girer.

Amaç yalnızca rengi tanımlamak değil; rengin kumaş üzerinde nasıl oluştuğunu anlamaktır.

Bu yaklaşım, teorik renk değeri ile gerçek kumaş davranışı arasındaki boşluğu kapatmayı hedefler.

3. Teorik Olarak Doğru Değil, Üretilebilir Reçete

Bir reçetenin laboratuvar ortamında başarılı olması, üretim makinesinde aynı sonucu vereceği anlamına gelmez.

Tekstil üretiminde sonuçlar yalnızca boya miktarına bağlı değildir. Fabrikanın fiziksel ve operasyonel gerçekliği, reçetenin başarısını doğrudan belirler.

Bu gerçeklik içerisinde:

• Su sertliği,

• Su iletkenliği,

• Başlangıç pH değeri,

• Kullanılan boya ve kimyasal markaları,

• Boya lotları,

• Makine hacmi,

• Flotte oranı,

• Sirkülasyon karakteristiği,

• Isıtma ve soğutma eğrileri,

• Dozajlama kabiliyeti,

• Kumaş yükü,

• Operasyon süresi,

• Sıkma, kurutma ve terbiye koşulları

gibi çok sayıda değişken bulunur.

Bu nedenle Dyegen’ın tasarım felsefesi yalnızca teorik renk eşleştirmeye dayanmaz.

Sistemin merkezindeki prensip şudur:

Dyegen, teorik olarak doğru bir reçete değil; belirli bir fabrikanın, belirli bir makinesinde, belirli bir kumaş ve kimyasal envanteriyle uygulanabilecek üretilebilir reçeteyi oluşturmalıdır.

Bu yaklaşım, Dyegen’ı klasik reçete hesaplama sistemlerinden ayıran temel noktadır.

Aynı hedef renk için iki farklı fabrikada aynı reçetenin kullanılması her zaman doğru olmayabilir. Çünkü her fabrikanın:

• Makine parkı,

• Su kalitesi,

• Kimyasal envanteri,

• Proses alışkanlıkları,

• Ölçüm geçmişi,

• Üretim toleransları

birbirinden farklıdır.

Dyegen, zaman içerisinde fabrikanın kendi proses karakterini öğrenebilecek şekilde tasarlanmaktadır.

Sistem yalnızca genel kimya kurallarını uygulayan bir yazılım değildir. Fabrikaya özel sapmaları, geçmiş üretim sonuçlarını ve makine davranışlarını karar sürecine dahil eden bir proses zekası olmayı hedefler.

Böylece oluşturulan reçete yalnızca matematiksel olarak doğru değil; sahada uygulanabilir, ekonomik ve tekrarlanabilir hale gelir.

4. Dyegen’ın 14 Aşamalı Mühendislik Yaklaşımı

Dyegen, numune analizinden reçete üretimine kadar uzanan süreci tek bir ölçüm işlemine indirgemez.

Sistem, her biri bir sonraki karar aşamasına veri sağlayan disiplinli bir mühendislik akışı üzerine kuruludur.

Bu yapının temel aşamaları şunlardır:

1. Referans numunenin kayıt altına alınması,

2. Numunenin standart koşullarda kondisyonlanması,

3. Fiziksel kumaş parametrelerinin ölçülmesi,

4. Lif yapısının ve kumaş sınıfının belirlenmesi,

5. Optik ve spektral ölçümlerin gerçekleştirilmesi,

6. Yüzey karakteristiğinin analiz edilmesi,

7. Hedef renk değerlerinin oluşturulması,

8. Fabrika ve makine bağlamının sisteme aktarılması,

9. Kullanılabilir boya ve kimyasal envanterinin belirlenmesi,

10. Alternatif reçete kombinasyonlarının oluşturulması,

11. Proses parametrelerinin hesaplanması,

12. Maliyet ve kaynak tüketiminin tahmin edilmesi,

13. Reçetenin sanal üretim koşullarında değerlendirilmesi,

14. Onaylı ve uygulanabilir üretim reçetesinin oluşturulması.

Bu yapı sayesinde Dyegen yalnızca bir renk ölçüm cihazı değil; ölçüm, modelleme, karar verme ve optimizasyon katmanlarını bir araya getiren bütünleşik bir mühendislik platformu haline gelir.

5. Sürdürülebilirlik Artık Ölçülebilir Bir Üretim Parametresi

Tekstil sektöründe sürdürülebilirlik uzun süre genel hedefler ve kurumsal raporlar üzerinden ele alındı.

Ancak gerçek sürdürülebilirlik, üretim başlamadan önce alınan mühendislik kararlarında ortaya çıkar.

Yanlış hazırlanan veya defalarca düzeltilen her reçete:

• Fazladan su,

• Fazladan enerji,

• Fazladan boya,

• Fazladan yardımcı kimyasal,

• Fazladan işçilik,

• Fazladan makine süresi

anlamına gelir.

Bu nedenle Dyegen, yalnızca renk doğruluğunu değil; reçetenin kaynak tüketimini ve ekonomik etkisini de değerlendirecek şekilde tasarlanmaktadır.

Sistem, üretim öncesinde şu değerleri tahmin etmeyi hedefler:

• Su tüketimi,

• Enerji ihtiyacı,

• Boya tüketimi,

• Yardımcı kimyasal tüketimi,

• Proses süresi,

• Tahmini üretim maliyeti,

• Reçetenin çevresel etkisi,

• Alternatif reçeteler arasındaki maliyet ve kalite farkları.

Böylece kullanıcı yalnızca “hangi reçete çalışır?” sorusuna değil, şu sorulara da cevap bulabilir:

• Hangi reçete daha düşük maliyetlidir?

• Hangi reçete daha az su tüketir?

• Hangi alternatif daha kısa sürede uygulanabilir?

• Hangi reçete hedef renge en düşük çevresel etkiyle ulaşır?

• Kalite, maliyet ve sürdürülebilirlik arasında en doğru denge hangisidir?

Dyegen’ın pilot uygulama sürecinde ölçülmesi hedeflenen temel performans göstergeleri şunlardır:

Bu değerler henüz ticari başarı iddiası olarak değil, pilot sistemin performansının doğrulanacağı mühendislik hedefleri olarak tanımlanmaktadır.

Dyegen’ın başarısı yalnızca renk tutturma oranıyla ölçülmeyecektir. Gerçek başarı; daha az deneme, daha az hata, daha düşük maliyet ve daha kontrollü üretim ile ortaya çıkacaktır.

6. Hassasiyet Hedefi: İlk Denemede Doğru Sonuca Yaklaşmak

Boyama prosesinde önemli olan yalnızca hedef renge ulaşmak değildir. Bu hedefe kaç denemede, ne kadar maliyetle ve hangi proses kararlılığıyla ulaşıldığı da belirleyicidir.

Dyegen’ın pilot aşamadaki temel teknik hedeflerinden biri, ilk laboratuvar denemesindeki başarı oranını yükseltmektir.

Pilot sistem için belirlenen hedefler:

• İlk laboratuvar denemesinde, vakaların en az %70’inde ΔE00 ≤ 1,5 değerine ulaşmak,

• En fazla bir reçete düzeltmesi sonrasında ΔE00 ≤ 1,0 seviyesine inmek,

• Reçete düzeltme ihtiyacını sistematik biçimde azaltmak,

• Aynı reçetenin tekrarlanabilirliğini artırmak,

• Laboratuvar sonucu ile üretim makinesi sonucu arasındaki farkı azaltmaktır.

Bu hedefler, Dyegen’ın yalnızca reçete üreten bir sistem olmadığını gösterir.

Dyegen, ürettiği reçetenin doğruluğunu ölçen, sapmaları analiz eden ve sonraki kararlarını bu sonuçlara göre geliştiren bir mühendislik sistemi olarak tasarlanmaktadır.

7. Otonomiye Giden Yol

Dyegen’ın uzun vadeli vizyonu yalnızca reçete hazırlamak değildir.

Amaç, tekstil fabrikalarının karar alma, doğrulama ve üretim süreçlerini adım adım otonomlaştırmaktır.

Bu yolculuk dört temel ürün fazı üzerinden ilerlemektedir.

Faz 1 — Analiz ve Reçete Üretimi

İlk fazda sistem:

• Referans numuneyi analiz eder,

• Kumaşın fiziksel ve optik özelliklerini belirler,

• Fabrika ve makine parametrelerini değerlendirir,

• Kullanılabilir boya ve kimyasalları dikkate alır,

• Uygulanabilir bir laboratuvar reçetesi oluşturur.

Bu fazın amacı, numune analizinden onaylanabilir reçeteye kadar uzanan mühendislik sürecini hızlandırmak ve standartlaştırmaktır.

Faz 2 — Laboratuvar Doğrulama

İkinci fazda reçete yalnızca kullanıcıya sunulmaz.

Sistem:

• Laboratuvar ekipmanlarıyla haberleşir,

• Reçeteyi otomatik olarak aktarır,

• Deneme sürecini izler,

• Ortaya çıkan numuneyi yeniden ölçer,

• Hedef ile sonuç arasındaki farkı hesaplar,

• Gerekli düzeltmeleri otomatik olarak oluşturur.

Bu aşamada Dyegen kapalı çevrim çalışan bir laboratuvar zekasına dönüşür.

Faz 3 — Üretim Makinesi Entegrasyonu

Üçüncü fazda onaylanmış reçete, üretim makinelerine doğrudan aktarılabilir bir görev paketi haline gelir.

Bu görev paketi yalnızca boya miktarlarını değil:

• Sıcaklık eğrilerini,

• Süreleri,

• pH hedeflerini,

• Kimyasal dozaj sırasını,

• Makine parametrelerini,

• Kontrol noktalarını,

• Kabul toleranslarını

da içerebilir.

Böylece reçete, statik bir belge olmaktan çıkar ve makinenin uygulayabileceği yapılandırılmış bir üretim komutuna dönüşür.

Faz 4 — Otonom Proses Zekası

Dördüncü fazda Dyegen, fabrikanın merkezi yönetim sistemiyle haberleşen, geçmiş üretimlerden öğrenen ve proses kararlarını sürekli geliştiren otonom bir yapıya dönüşür.

Bu seviyede sistem:

• Üretim geçmişini analiz eder,

• Makine sapmalarını öğrenir,

• Reçete sonuçlarını karşılaştırır,

• Kalite problemlerini önceden tahmin eder,

• Kaynak tüketimini optimize eder,

• Yeni üretimler için karar önerileri oluşturur,

• Gerektiğinde proses parametrelerini kendi kendine günceller.

Dyegen bu aşamada yalnızca bir ürün değil, fabrikanın proses kararlarını yöneten merkezi zeka katmanlarından biri olur.

8. Otonomi Seviyeleri: Dijital Kayıttan Fabrika Zekasına

Dyegen’ın gelişimi yalnızca ürün fazlarıyla değil, karar verme yeteneğini tanımlayan otonomi seviyeleriyle de ifade edilmektedir.

Seviye 0 — Dijital Kayıt

Sistem yalnızca üretim ve reçete verilerini kaydeder.

Seviye 1 — Karar Desteği

Sistem geçmiş verileri analiz eder ve kullanıcıya öneriler sunar.

Seviye 2 — Kısmi Otomasyon

Belirli reçete ve proses kararları otomatik olarak oluşturulur, ancak insan onayı gerekir.

Seviye 3 — Koşullu Otonomi

Sistem tanımlı sınırlar içinde laboratuvar ve üretim kararlarını kendi başına uygulayabilir.

Seviye 4 — Yüksek Otonomi

Sistem, üretim hattının büyük bölümünü insan müdahalesine ihtiyaç duymadan yönetebilir.

Seviye 5 — Fabrika Seviyesinde Otonomi

Fabrikanın reçete, proses, kalite, kaynak ve üretim kararları merkezi bir otonom sistem tarafından bütünleşik biçimde yönetilir.

Bu yapı, Dyegen’ın yalnızca bugünkü bir probleme çözüm üretmediğini; geleceğin otonom tekstil fabrikası için temel bir mühendislik altyapısı oluşturduğunu gösterir.

9. Tekstil Mühendisinin Rolü Ortadan Kalkmayacak, Güçlenecek

Otonom sistemler söz konusu olduğunda sıkça sorulan soru şudur:

Makineler karar vermeye başladığında mühendislere ihtiyaç kalacak mı?

Dyegen’ın vizyonunda mühendis ortadan kalkmaz. Aksine daha yüksek seviyeli bir role geçer.

Bugün tekstil mühendisleri ve laboratuvar çalışanları zamanlarının önemli bir bölümünü:

• Tekrarlanan hesaplamalara,

• Reçete karşılaştırmalarına,

• Veri girişine,

• Manuel düzeltmelere,

• Geçmiş üretim kayıtlarını incelemeye

ayırmaktadır.

Akıllı sistemler bu yükü devraldığında mühendislerin rolü:

• Proses tasarlayan,

• Sistem sınırlarını belirleyen,

• Kalite politikalarını yöneten,

• Üretim stratejisi geliştiren,

• Yeni malzeme ve prosesleri araştıran,

• Otonom sistemleri denetleyen

bir yapıya dönüşecektir.

Geleceğin tekstil mühendisi yalnızca reçete hazırlayan kişi değil, üretim sisteminin davranışını tasarlayan bir proses mimarı olacaktır.

10. Sonuç: Tekstilde Otonom Gelecek Başladı

Tekstil endüstrisinin geleceği yalnızca daha hızlı makinelerden oluşmayacak.

Geleceğin fabrikaları:

• Üretim verisini anlayan,

• Geçmiş hatalardan öğrenen,

• Kaynak tüketimini önceden hesaplayan,

• Kalite problemlerini tahmin eden,

• Reçete ve proses kararlarını optimize eden

akıllı sistemler üzerine kurulacak.

Tunix Dyegen, bu dönüşümün renk geliştirme ve boyama prosesindeki temel modüllerinden biri olarak tasarlanmaktadır.

Dyegen’ın amacı yalnızca daha hızlı reçete hazırlamak değildir.

Amaç:

• Deneme-yanılma ihtiyacını azaltmak,

• Üretim bilgisini sayısallaştırmak,

• Usta bilgisini kaybetmeden mühendislik modellerine dönüştürmek,

• Fabrikaya özel üretilebilir reçeteler oluşturmak,

• Su, enerji ve kimyasal tüketimini azaltmak,

• Laboratuvar ile üretim arasındaki farkı kapatmak,

• Tekstil fabrikalarını adım adım otonom hale getirmektir.

Bu nedenle Dyegen yalnızca bir renk ölçüm cihazı, yazılım veya reçete sistemi değildir.

Dyegen, tekstil fabrikasının ölçen, düşünen, öğrenen ve karar veren proses zekası olmayı hedeflemektedir.

Geleceğin fabrikalarında makineler daha fazla karar verecek. Ancak bu, insanın üretimden çekilmesi anlamına gelmeyecek.

Tam tersine insanlar; tekrarlanan hesaplamalardan ve manuel denemelerden kurtularak daha yaratıcı, daha stratejik ve daha yüksek seviyeli mühendislik problemlerine odaklanacak.

Tekstilde deneme-yanılma devri kapanıyor.

Yerini ölçülebilir, öğrenebilir ve otonom bir üretim çağı alıyor.