``

Uzaktan açma isteği nasıl ilerler?

Tipik bir sistemde telefon doğrudan kilide bağlanmak yerine üreticinin sunucusuyla haberleşir. Kullanıcı önce parola, biyometri veya geçiş anahtarıyla oturum açar. Sunucu kullanıcının ilgili kapıyı açma yetkisini denetler ve kilide imzalanmış bir komut gönderir. Kilit, komutun doğruluğunu kendi içindeki güvenli anahtarla kontrol ettikten sonra motoru çalıştırır.

Bu süreç üç temel soruya cevap vermelidir:

1. Kim gönderdi? Kimlik doğrulama bunu belirler.
2. Mesaj değiştirildi mi? Bütünlük kontrolü bunu gösterir.
3. İçeriği başkası okuyabilir mi? Şifreleme gizliliği sağlar.

Kimlik doğrulama ile yetkilendirme aynı şey değildir. Kimlik doğrulama, “Bu kişi Ayşe mi?” sorusunu; yetkilendirme ise “Ayşe bu kapıyı şu anda açabilir mi?” sorusunu cevaplar. Örneğin temizlik görevlisinin hesabı gerçek olabilir, fakat erişimi yalnızca 09.00–11.00 arasında geçerli olabilir.

Şifreleme hangi katmanlarda kullanılır?

Telefon, sunucu ve kilit arasındaki ağ trafiği genellikle TLS ile korunur. Böylece ortak Wi-Fi ağındaki saldırgan komutu okuyamaz veya değiştiremez. Ancak yalnızca bağlantı şifrelemesine güvenmek yeterli değildir. Açma komutunun ayrıca dijital imza ya da HMAC ile doğrulanması, aradaki sunucu veya ağ katmanlarına karşı ek güvence sağlar.

HMAC kabaca şu şekilde ifade edilir:

Burada $K$ gizli anahtar, $m$ ise mesajdır. Anahtarı bilmeyen saldırgan geçerli doğrulama kodunu pratikte üretemez.

Tekrar saldırısı neden tehlikelidir?

Bir saldırgan şifreli paketi okuyamasa bile paketi kaydedip daha sonra yeniden gönderebilir. Buna replay saldırısı denir. Savunma için her isteğe rastgele bir nonce, kısa son kullanma süresi ve benzersiz işlem kimliği eklenir. Kilit daha önce gördüğü nonce değerlerini reddeder.

import hmac, hashlib, time, secrets

key = b"cihaz-icin-gizli-anahtar"
nonce = secrets.token_hex(16)
expires = int(time.time()) + 30
message = f"OPEN|front-door|{nonce}|{expires}".encode()
signature = hmac.new(key, message, hashlib.sha256).hexdigest()

Bu örnek, kapı kimliğiyle birlikte rastgele nonce ve 30 saniyelik geçerlilik süresi içeren bir mesaj üretir. HMAC, mesajın değiştirilip değiştirilmediğini denetlemeyi sağlar. Gerçek bir üründe anahtar kaynak koda yazılmaz; secure element, TPM benzeri güvenli donanım veya işletim sisteminin anahtar kasasında tutulur.

256 bitlik ideal bir anahtarı rastgele tahmin etmenin tek denemedeki başarı olasılığı $1/2^{256}$ seviyesindedir. Fakat güçlü matematik, kötü anahtar yönetimini kurtaramaz. Aynı anahtarın bütün kilitlerde kullanılması, güncelleme imzalarının doğrulanmaması veya hata ayıklama portlarının açık bırakılması sistemi savunmasız yapabilir.

Güvenli tasarımın tamamlayıcı parçaları

Akıllı kilit güvenliği; çok faktörlü kimlik doğrulama, erişim süresi sınırları, başarısız denemelerde hız kısıtlama, imzalı yazılım güncellemeleri ve denetlenebilir olay kayıtlarıyla tamamlanır. İnternet kesildiğinde sistemin nasıl davranacağı da önceden belirlenmelidir. Acil çıkış güvenliği korunurken dışarıdan yetkisiz girişe izin verilmemelidir.

Kısacası güvenli bir akıllı kilit, sadece “şifreli bağlantı kullanan motorlu kapı” değildir. Kimlik, yetki, mesaj bütünlüğü, anahtar saklama ve fiziksel güvenlik birlikte tasarlandığında uzaktan açma işlemi hem kullanışlı hem de güvenilir hale gelir.

Elektrik faturası bazen evde görünmez bir canavar dolaşıyormuş hissi verir: Buzdolabı sessizce çalışır, televizyon bekleme modunda enerji tüketir, elektrikli ısıtıcı ise bütçeyi adeta közler. Akıllı prizler bu canavarı görünür hâle getirir. Cihaz bazında güç ve enerji ölçümü yaparak hangi cihazın ne zaman, ne kadar tükettiğini anlamamızı; tahminlere değil, verilere dayalı tasarruf kararları almamızı sağlar.

``

Akıllı priz hangi verileri toplar?

Tipik bir akıllı priz belirli aralıklarla gerilim, akım ve aktif güç değerlerini kaydeder. Bazı modeller güç faktörü, frekans ve toplam enerji tüketimi de sunar. Temel elektrik ilişkisi şöyledir:

Burada $P$ aktif gücü (W), $V$ gerilimi, $I$ akımı ve $\cos(\varphi)$ güç faktörünü gösterir. Bir cihazın tükettiği enerji ise gücün zaman boyunca birikimidir:

$P_i$ watt, $\Delta t_i$ saat cinsindeyse sonuç kilovatsaat, yani kWh olur. Faturanın enerji kısmını yaklaşık hesaplamak için $E$ değeri birim fiyatla çarpılır.

Ham veriden anlamlı sonuca

Akıllı priz kayıtları önce temizlenmelidir. Eksik ölçümler, tekrarlanan satırlar ve gerçek dışı sıçramalar analizi yanıltabilir. Örneğin normalde 100 W çeken bir televizyonun bir saniyeliğine 30.000 W görünmesi büyük olasılıkla ölçüm veya iletişim hatasıdır.

Temiz veride şu göstergeler özellikle değerlidir:

• Baz yük: Cihaz kapalı sanılırken devam eden tüketim.
• Pik güç: Cihazın ulaştığı en yüksek güç seviyesi.
• Çalışma süresi: Gücün belirlenen eşiğin üzerinde kaldığı süre.
• Günlük enerji: Gün boyunca biriken kWh miktarı.
• Kullanım deseni: Cihazın hangi saatlerde ve ne sıklıkta çalıştığı.

Aşağıdaki Python örneği, CSV dosyasındaki ölçümlerden günlük enerji ve maliyet üretir:

import pandas as pd

BIRIM_FIYAT = 2.60  # Örnek TL/kWh

veri = pd.read_csv("priz_verisi.csv", parse_dates=["zaman"])
veri = veri.sort_values("zaman").drop_duplicates("zaman")

# Ölçümler arasındaki süreyi saate çevirir.
veri["sure_saat"] = veri["zaman"].diff().dt.total_seconds() / 3600
veri["sure_saat"] = veri["sure_saat"].clip(lower=0, upper=1)

# Watt-saat hesabını kWh değerine dönüştürür.
veri["enerji_kwh"] = veri["guc_watt"] * veri["sure_saat"] / 1000
veri["gun"] = veri["zaman"].dt.date

ozet = veri.groupby("gun")["enerji_kwh"].sum().to_frame()
ozet["maliyet_tl"] = ozet["enerji_kwh"] * BIRIM_FIYAT
print(ozet)

Kod, ardışık kayıtlar arasındaki süreyi hesaplar ve ölçülen güçle çarpar. Bir saatten uzun veri boşluklarını sınırlamak, eksik kayıtların tüketimi yapay biçimde büyütmesini engeller.

Tasarruf fırsatlarını sınıflandırmak

Her yüksek tüketim gereksiz değildir. Buzdolabının sürekli çalışması normal olabilir; fakat eski bir modelin yeni modele göre iki kat enerji harcaması değişim kararını destekleyebilir.

Bir önlemin aylık kazancı yaklaşık olarak

formülüyle bulunabilir. Yeni cihaz alınacaksa geri ödeme süresi de $Yatırım\ Maliyeti / Aylık\ Tasarruf$ şeklinde hesaplanır.

Sonuç olarak akıllı priz, tek başına faturayı düşüren sihirli bir düğme değildir; doğru soruları sormayı sağlayan küçük bir veri laboratuvarıdır. En etkili yaklaşım, birkaç hafta ölçüm yapmak, baz tüketimi ve çalışma döngülerini karşılaştırmak, ardından zamanlama, bakım veya cihaz değişimi gibi müdahalelerin sonucunu yeniden ölçmektir. Ölç, değiştir, tekrar ölç: Enerji optimizasyonunun en kısa ve en güvenilir döngüsü budur.

``

Risk tahmini nasıl çalışır?

Makine öğrenmesi, geçmişte sonucu bilinen hasta verilerindeki örüntüleri öğrenir. Örneğin diyabet riskini tahmin eden bir sistem; yaş, vücut kitle indeksi, açlık glukozu, aile öyküsü ve fiziksel aktivite gibi değişkenleri kullanabilir.

Bir hastanın özelliklerini $x$ ile gösterirsek modelin temel amacı şu olasılığı kestirmektir:

Burada $Y=1$, belirlenen süre içinde hastalığın geliştiği anlamına gelir. Lojistik regresyon gibi açıklanabilir bir model bu olasılığı şöyle hesaplayabilir:

Katsayılar, her değişkenin risk üzerindeki etkisini temsil eder. Derin öğrenme modelleriyse çok daha karmaşık ilişkileri öğrenebilir; fakat kararlarını açıklamak genellikle daha zordur.

Hangi veriler erken sinyal taşıyabilir?

Tek bir ölçüm yerine zaman içindeki değişim çoğu zaman daha değerlidir. Örneğin nabzın 80 olması tek başına anlamlı olmayabilir; kişinin aylar boyunca 60 civarında seyreden nabzının sürekli 80’e çıkması dikkat çekici olabilir.

Basit bir risk modeli

Aşağıdaki örnek, hasta özelliklerinden ikili risk tahmini yapan sade bir Python iş akışıdır:

from sklearn.model_selection import train_test_split
from sklearn.preprocessing import StandardScaler
from sklearn.pipeline import make_pipeline
from sklearn.linear_model import LogisticRegression
from sklearn.metrics import roc_auc_score

X_train, X_test, y_train, y_test = train_test_split(
    X, y, test_size=0.2, stratify=y, random_state=42
)

model = make_pipeline(
    StandardScaler(),
    LogisticRegression(class_weight="balanced")
)

model.fit(X_train, y_train)
risk_scores = model.predict_proba(X_test)[:, 1]
print("ROC-AUC:", roc_auc_score(y_test, risk_scores))

StandardScaler, değişkenleri benzer ölçeklere getirir. class_weight="balanced" ise hasta sayısının sağlıklı bireylerden çok az olduğu dengesiz veri kümelerinde modele yardımcı olur. predict_proba, kesin bir etiket yerine risk skoru üretir.

Başarı yalnızca doğruluk değildir

Nadir hastalıklarda herkese “sağlıklı” diyen bir model yüksek doğruluk gösterebilir. Bu nedenle farklı ölçütler birlikte değerlendirilmelidir:

Tarama sistemlerinde yanlış negatifler tehlikelidir; ancak çok fazla yanlış pozitif de gereksiz testlere, maliyete ve kaygıya yol açabilir. Bu yüzden karar eşiği klinik bağlama göre belirlenmelidir.

Peki gerçekten mümkün mü?

Evet, bazı hastalıklar için belirtilerden önce anlamlı risk tahmini yapılabilir. Fakat veri kalitesi, farklı topluluklarda doğrulama, mahremiyet, algoritmik önyargı ve klinik denetim vazgeçilmezdir. Bir hastanede başarılı olan model, başka bir bölgede aynı sonucu vermeyebilir.

En sağlıklı yaklaşım, makine öğrenmesini doktorun yerine geçen dijital bir kâhin olarak değil, dikkat edilmesi gereken hastaları önceliklendiren bir erken uyarı sistemi olarak görmektir. Nihai tanı; hekim değerlendirmesi, doğrulayıcı testler ve hastanın klinik öyküsüyle konmalıdır.

Bulut oyun döngüsü nasıl çalışır?

Sistem, oyuncunun bir tuşa basmasıyla başlayan sürekli bir veri alışverişi üzerine kuruludur. Klavye, fare veya oyun kolundan alınan komut önce istemci uygulaması tarafından küçük bir ağ paketine dönüştürülür. Paket sunucuya ulaştığında oyun motoru yeni durumu hesaplar, ekran kartı kareyi oluşturur ve video kodlayıcı bu kareyi sıkıştırır. Son olarak görüntü istemciye gönderilip ekranda gösterilir.

Bu zincirin toplam gecikmesi kabaca şöyle modellenebilir:

Örneğin komutun sunucuya ulaşması 20 ms, oyunun kareyi üretmesi 12 ms, kodlama ve çözme işlemleri toplam 15 ms, görüntünün dönüşü ise 20 ms sürerse gecikme yaklaşık $67\,ms$ olur. Bu değer strateji oyunlarında kabul edilebilirken rekabetçi bir nişancı oyununda oyuncuya belirgin gelebilir.

Yerel oyun ile bulut oyunun karşılaştırması

Bulut oyun cihaz maliyetini azaltır; ancak hesaplama yükünü ortadan kaldırmaz, yalnızca veri merkezine taşır. Sunucularda güçlü GPU’lar, çok çekirdekli işlemciler ve hızlı depolama sistemleri bulunur. Aynı fiziksel GPU, sanallaştırma teknolojileri sayesinde birden fazla oyuncuya bölüştürülebilir.

Video akışı neden kritik?

Ham görüntüleri internetten göndermek pratik değildir. Saniyede 60 kare üreten, 1920×1080 çözünürlüklü ve piksel başına 24 bit kullanan sıkıştırılmamış bir akışın yaklaşık veri hızı şöyledir:

Bu nedenle H.264, H.265 veya AV1 gibi kodekler kullanılır. Kodek, birbirini takip eden karelerde değişmeyen bölgeleri tekrar göndermek yerine hareket ve fark bilgilerini taşır. Böylece gerekli bant genişliği çoğu senaryoda 15–50 Mbit/s aralığına düşebilir. Buna karşılık daha güçlü sıkıştırma, kodlama süresini veya görüntü bozulmasını artırabilir.

Ağ kalitesi yalnızca hız değildir

Yüksek indirme hızı tek başına kusursuz deneyim sağlamaz. Ping, paketin gidiş-dönüş süresini; jitter, gecikmedeki düzensizliği; paket kaybı ise ulaşmayan veri oranını belirtir. Video aktarımında çoğunlukla düşük gecikmeli UDP tabanlı protokoller tercih edilir. Kayıp bir paketin yeniden gönderilmesini beklemek yerine sonraki karenin gösterilmesi, oyunun donmasını engelleyebilir.

Aşağıdaki basit Python kodu, yaklaşık toplam gecikmeyi hesaplar:

def bulut_oyun_gecikmesi(gidis, isleme, kodlama, donus, cozme):
    return gidis + isleme + kodlama + donus + cozme

gecikme = bulut_oyun_gecikmesi(18, 10, 8, 18, 6)
print(f"Tahmini gecikme: {gecikme} ms")

Gerçek sistemler ağ durumunu sürekli ölçerek bit hızını ve çözünürlüğü dinamik biçimde değiştirir. Bağlantı kötüleştiğinde 4K görüntüyü korumaya çalışmak yerine çözünürlüğü düşürmek, oynanabilirliği sürdürür.

Gelecekte bizi ne bekliyor?

Edge computing sayesinde oyun sunucuları oyunculara daha yakın noktalara yerleştiriliyor. 5G, gelişmiş AV1 kodlayıcıları ve gecikme tahmin teknikleri de deneyimi iyileştiriyor. Bulut oyun, güçlü bilgisayarları tamamen gereksiz kılmasa da donanımı bir ürün olmaktan çıkarıp uzaktan erişilen bir hizmete dönüştürüyor. Kısacası geleceğin oyun konsolu, salonunuzdaki kutudan çok size en yakın veri merkezindeki sunucu olabilir.

``

Numaralandırma: enum

enum, ilişkili tam sayı sabitlerini tek bir başlık altında toplar. Bir trafik lambasının durumlarını ele alalım:

#include <stdio.h>

enum TrafikIsigi {
    KIRMIZI,
    SARI,
    YESIL
};

int main(void) {
    enum TrafikIsigi aktif = YESIL;

    if (aktif == YESIL) {
        printf("Geçebilirsiniz.\n");
    }

    return 0;
}

Değer belirtilmediğinde ilk eleman 0 olur ve sonraki elemanlar birer artar. Yani burada KIRMIZI = 0, SARI = 1 ve YESIL = 2 kabul edilir. Genel olarak ilk değer $v_0 = 0$ ise sıralama $v_i = v_0 + i$ biçimindedir.

Değerleri kendimiz de belirleyebiliriz:

enum HttpDurumu {
    HTTP_OK = 200,
    HTTP_BULUNAMADI = 404,
    HTTP_SUNUCU_HATASI = 500
};

Böylece durum == 404 yerine durum == HTTP_BULUNAMADI yazılır. İki ifade sayısal olarak aynı sonucu üretse de ikincisi niyeti açıklar.

typedef ile tiplere takma ad vermek

typedef, mevcut bir tipe yeni bir isim tanımlar. Yeni ve bağımsız bir veri tipi oluşturmaz; derleyici açısından çoğunlukla bir takma addır.

typedef unsigned long KullaniciId;
typedef float Sicaklik;

KullaniciId id = 12045;
Sicaklik oda = 23.5f;

Burada KullaniciId, unsigned long ile aynı temsile sahiptir. Dolayısıyla bellek boyutu için şu ilişki geçerlidir:

Asıl avantaj, değişkenin ne amaçla kullanıldığını göstermesidir. Yine de typedef güçlü tip güvenliği sağlamaz; KullaniciId ile başka bir unsigned long değer yanlışlıkla karıştırılabilir.

struct, enum ve typedef birlikte

C dilinde yapı değişkeni tanımlarken normalde struct anahtar kelimesi tekrar edilir. typedef bu gürültüyü azaltabilir:

typedef enum {
    ROL_MISAFIR,
    ROL_EDITOR,
    ROL_YONETICI
} KullaniciRolu;

typedef struct {
    unsigned int id;
    char ad[40];
    KullaniciRolu rol;
} Kullanici;

void rolYazdir(Kullanici kullanici) {
    switch (kullanici.rol) {
        case ROL_MISAFIR:
            printf("Misafir\n");
            break;
        case ROL_EDITOR:
            printf("Editör\n");
            break;
        case ROL_YONETICI:
            printf("Yönetici\n");
            break;
        default:
            printf("Geçersiz rol\n");
    }
}

Bu örnekte KullaniciRolu, numaralandırmanın; Kullanici ise yapının kısa tip ismidir. switch kullanımı olası değerleri görmeyi kolaylaştırır. default dalı eklemek de dışarıdan veya hatalı dönüşümle gelebilecek geçersiz değerlere karşı savunma sağlar.

Dikkat edilmesi gerekenler

C, enum değişkenine yalnızca listelenen değerlerin atanmasını kesin olarak engellemez. Örneğin açık bir dönüşüm veya doğrudan atama sonucunda beklenmeyen sayılar oluşabilir. Bu nedenle giriş doğrulaması hâlâ gereklidir. Ayrıca bir enum türünün boyutunun her platformda mutlaka int boyutunda olduğunu varsaymak taşınabilir kod açısından doğru değildir.

İsim çakışmalarını önlemek için sabitlerde ROL_, HTTP_ veya RENK_ gibi önekler kullanmak iyi bir alışkanlıktır. Özetle enum, “hangi seçenek?” sorusunu; typedef ise “bu veri neyi temsil ediyor?” sorusunu yanıtlar. Birlikte kullanıldıklarında C kodu yalnızca çalışan değil, aynı zamanda kendi hikâyesini anlatan bir yapıya kavuşur.

Mobil bankacılıkta birkaç saniye içinde tamamlanan para transferi, kullanıcıya son derece basit görünür: IBAN yazılır, tutar girilir ve düğmeye dokunulur. Oysa bu kısa yolculuğun arkasında kimlik doğrulama servisleri, dolandırıcılık motorları, muhasebe kayıtları, mesaj kuyrukları ve dış ödeme ağlarından oluşan kalabalık bir ekip çalışır. Kısacası ekrandaki “Başarılı” mesajı, dağıtık sistemlerin birlikte verdiği küçük bir konserdir.

``

Büyük resim: Katmanlı mimari

Dijital bankacılık mimarisi genellikle istemci, erişim, iş servisleri, veri ve entegrasyon katmanlarına ayrılır. Mobil uygulama doğrudan hesap veritabanına bağlanmaz; böyle bir tasarım güvenlik ekibinin uykularını kaçırırdı. Bunun yerine istekler önce API Gateway üzerinden geçer.

Bu ayrımın amacı yalnızca düzen değildir. Her katman bağımsız ölçeklenebilir, izlenebilir ve güvenlik politikalarıyla sınırlandırılabilir.

Bir transferin adım adım yolculuğu

Kullanıcı transfer emrini gönderdiğinde mobil uygulama, erişim belirtecini ve benzersiz işlem anahtarını isteğe ekler. API Gateway oturumu doğrular, olağan dışı istek sıklığını kontrol eder ve çağrıyı transfer servisine iletir.

Transfer servisi sırasıyla şu soruları sorar:

1. Hesap aktif mi ve kullanıcı yetkili mi?
2. Kullanılabilir bakiye yeterli mi?
3. Alıcı bilgileri biçimsel olarak doğru mu?
4. İşlem, kara para aklama veya dolandırıcılık kuralına takılıyor mu?
5. Aynı istek daha önce işlendi mi?

Son soru idempotency kavramına dayanır. Mobil bağlantı kopunca kullanıcı düğmeye tekrar basabilir. Aynı anahtarla gelen istek ikinci kez para düşürmemelidir.

POST /transfers
Authorization: Bearer token
Idempotency-Key: tx-2026-8f31
Content-Type: application/json

{
  "sourceAccount": "TR-A",
  "targetIban": "TR-B",
  "amount": 1250.00,
  "currency": "TRY"
}

Sunucu, Idempotency-Key değerini sonuçla birlikte saklar. Aynı anahtar yeniden geldiğinde işlemi tekrarlamak yerine önceki yanıtı döndürür.

Para neden yalnızca bir sayı değildir?

Bankalar bakiyeyi doğrudan değiştirip geçmez; çift taraflı muhasebe defteri kullanır. Bir hesaptaki azalma başka bir hesaptaki artışla dengelenmelidir. Temel eşitlik şöyledir:

Transfer özelinde defter hareketlerinin toplamı sıfır olmalıdır:

Gönderen için $-1250$ TL, alıcı için $+1250$ TL kaydedilir. Kayıtlar değiştirilmeye çalışılmaz; hata varsa ters kayıt oluşturulur. Böylece denetim izi korunur.

Gerçek zamanlılık ve tutarlılık dengesi

Her adımı tek, devasa veritabanı işlemi içinde yürütmek güvenilir görünse de dış bankalar ve ağ gecikmeleri bunu zorlaştırır. Bu nedenle modern sistemler çoğunlukla olay güdümlü mimari ve Saga yaklaşımı kullanır.

Transfer kaydedildikten sonra TransferCreated olayı Kafka’ya gönderilebilir. Bildirim, raporlama ve analiz servisleri bu olayı ayrı ayrı tüketir. Kritik muhasebe işlemi ise güçlü tutarlılıkla korunur.

Güvenlik ve gözlemlenebilirlik

TLS iletişimi şifreler; OAuth 2.0 ve kısa ömürlü belirteçler erişimi sınırlar. Biyometri tek başına yeterli değildir: cihaz bağlama, işlem imzalama, limit kontrolleri ve davranış analizi birlikte kullanılmalıdır.

Son olarak her istek bir korelasyon kimliğiyle izlenir. Loglar, metrikler ve dağıtık izler sayesinde ekipler transferin hangi serviste yavaşladığını görebilir. İyi bir dijital banka yalnızca parayı hızla taşımaz; işlemi kanıtlanabilir, tekrarlanamaz ve gerektiğinde saniye saniye açıklanabilir hâle getirir.

Bir köprüyü inşa etmeden trafiğe açmak, yeni metro hattını kazı başlamadan çalıştırmak veya şiddetli yağmurun hangi sokakları göle çevireceğini önceden görmek mümkün mü? Dijital ikiz teknolojisi sayesinde şehir yöneticileri, gerçek dünyada pahalı ve riskli kararlar almadan önce bir şehrin sanal kopyası üzerinde deneyler yapabiliyor. Kısacası şehir, dev bir strateji oyununa dönüşüyor; ancak bu oyunda verilen kararlar gerçek insanların yaşamını etkiliyor. ``

Dijital ikiz nedir?

Dijital ikiz, fiziksel bir varlığın veya sistemin verilerle sürekli güncellenen sanal temsilidir. Şehir ölçeğinde bu temsil; yolları, binaları, enerji hatlarını, kanalizasyon sistemlerini, toplu taşımayı ve hatta hava kalitesini kapsayabilir.

Sıradan bir üç boyutlu model yalnızca şehrin görünüşünü gösterirken dijital ikiz, şehrin davranışını taklit eder. Trafik sensörleri, uydu görüntüleri, hava istasyonları ve Nesnelerin İnterneti cihazları gerçek zamanlı veri gönderir. Böylece sanal şehir, fiziksel kardeşiyle birlikte değişir.

Sanal şehir nasıl oluşturulur?

İlk adım veri toplamaktır. Coğrafi Bilgi Sistemleri parsel ve yol geometrisini, LiDAR taramaları bina yüksekliklerini, sensörler ise trafik yoğunluğu gibi değişkenleri sağlar. Bu veriler ortak bir koordinat sistemi içinde birleştirilir.

Ardından fiziksel süreçler matematiksel modellere dönüştürülür. Örneğin bir yol bölümündeki trafik akışı basitçe şöyle ifade edilebilir:

Burada $q$ birim zamanda geçen araç sayısını, $k$ yol üzerindeki araç yoğunluğunu, $v$ ise ortalama hızı temsil eder. Yoğunluk arttığında hızın her zaman sabit kalmaması, daha gelişmiş modellerin kullanılmasını gerektirir. İşte dijital ikizin gücü, binlerce bağlantılı değişkeni aynı simülasyonda değerlendirebilmesidir.

Altyapı kararları nasıl test edilir?

Belediyenin yoğun bir kavşağa yeni şerit eklemeyi düşündüğünü varsayalım. Dijital ikiz üzerinde mevcut durum, yeni şerit ve toplu taşımaya öncelik veren alternatif ayrı ayrı çalıştırılabilir. Yolculuk süresi, emisyon, maliyet ve yaya güvenliği karşılaştırılır.

Benzer yöntemle yağmur suyu altyapısı da sınanabilir. Simülasyona aşırı yağış verilir; suyun nerede biriktiği ve hangi rögarların kapasitesini aştığı gözlenir. Yeni drenaj hattı önce sanal ortamda eklenerek etkisi ölçülür.

Küçük bir senaryo hesabı

Aşağıdaki Python kodu, farklı ulaşım politikalarını basit bir puanlama modeliyle karşılaştırır:

senaryolar = {
    'ek_serit': {'sure': 35, 'emisyon': 80, 'maliyet': 90},
    'otobus_onceligi': {'sure': 31, 'emisyon': 45, 'maliyet': 55},
    'mevcut_durum': {'sure': 42, 'emisyon': 95, 'maliyet': 0}
}

for ad, veri in senaryolar.items():
    puan = 0.4 * veri['sure'] + 0.35 * veri['emisyon'] + 0.25 * veri['maliyet']
    print(ad, round(puan, 2))

Buradaki ağırlıklar, belediyenin önceliklerini temsil eder. Düşük puan daha iyi sonuç anlamına gelir. Gerçek bir dijital ikizde hesap; nüfus hareketleri, saatlik talep, kaza riski ve hava durumu gibi çok daha fazla değişken içerir.

Kusursuz bir kristal küre mi?

Hayır. Eksik sensör verileri, hatalı varsayımlar ve insanların beklenmedik davranışları tahminleri bozabilir. Ayrıca kameralar ve konum verileri kullanıldığında mahremiyet, veri güvenliği ve algoritmik tarafsızlık kritik hâle gelir. Model ne kadar etkileyici görünürse görünsün sonuçları uzmanlar ve kent sakinleri birlikte değerlendirmelidir.

Doğru kullanıldığında dijital ikiz, beton dökmeden önce düşünmeyi sağlar. Böylece şehirler yalnızca daha teknolojik değil; daha güvenli, sürdürülebilir ve insan odaklı biçimde planlanabilir.

DNA, canlıların yapım talimatlarını taşıyan devasa bir metin gibi düşünülebilir. Ancak bu metnin alfabesinde yalnızca dört harf bulunur: adenin (A), sitozin (C), guanin (G) ve timin (T). İnsan genomu yaklaşık 3 milyar harften oluştuğu için iki DNA dizisini gözle karşılaştırmak pek gerçekçi değildir. İşte biyoinformatik algoritmaları burada devreye girer: Diziler arasındaki benzerlikleri, farklılıkları ve olası biyolojik ilişkileri bilgisayarlarla araştırır.

``

DNA karşılaştırması neden yapılır?

Genom karşılaştırması; hastalıklarla ilişkili mutasyonları bulmak, türler arasındaki evrimsel yakınlığı ölçmek, virüs varyantlarını takip etmek ve kişiselleştirilmiş tedaviler geliştirmek için kullanılır. Temel amaç, iki dizide aynı kalan veya değişen bölgeleri belirlemektir.

Örneğin aşağıdaki dizileri ele alalım:

Dizi 1: ACGTACG
Dizi 2: ACGTTCG

Burada beşinci karakter A yerine T olmuştur. Bu değişime substitüsyon denir. DNA’da ayrıca karakter eklenmesi anlamına gelen insersiyon ve karakter kaybı anlamına gelen delesyon görülebilir.

Dizi hizalama mantığı

Bilgisayarlar DNA dizilerini karşılaştırırken karakterleri uygun konumlarda alt alta getirmeye çalışır. Bu işleme dizi hizalama denir. Her eşleşmeye pozitif, uyumsuzluğa veya boşluğa negatif puan verilerek en yüksek puanlı hizalama aranır.

Basit bir puan fonksiyonu şöyle tanımlanabilir:

Diziye eklenen boşlukların puanı da örneğin $-2$ olabilir. Algoritma, toplam puanı

ifadesine göre en büyük yapan hizalamayı seçer. Böylece yalnızca kaç harfin aynı olduğuna değil, ekleme ve silmelerin diziyi nasıl kaydırdığına da dikkat edilir.

Global ve lokal hizalama

İki temel yaklaşım bulunur:

Global hizalama, uzunlukları ve kökenleri benzer diziler için uygundur. Lokal hizalama ise büyük bir genom içinde belirli bir gen bölgesini ararken daha kullanışlıdır. Her iki yöntem de dinamik programlama kullanır. Problem küçük alt problemlere ayrılır ve daha önce hesaplanan sonuçlar bir tabloda saklanır. Böylece aynı işlem tekrar tekrar yapılmaz.

Python ile basit benzerlik hesabı

Aşağıdaki kod, eşit uzunluktaki iki DNA dizisinde aynı konumda bulunan bazların oranını hesaplar:

def dna_benzerligi(dizi1, dizi2):
    if len(dizi1) != len(dizi2):
        raise ValueError("Diziler eşit uzunlukta olmalı")

    eslesme = sum(
        baz1 == baz2
        for baz1, baz2 in zip(dizi1, dizi2)
    )
    return eslesme / len(dizi1)

oran = dna_benzerligi("ACGTACG", "ACGTTCG")
print(f"Benzerlik: %{oran * 100:.2f}")

Bu örnek yaklaşık %85.71 benzerlik verir. Ancak insersiyon ve delesyonları doğru değerlendiremez; çünkü boşluk ekleyerek hizalama yapmaz. Gerçek projelerde Biopython, BLAST ve minimap2 gibi araçlar tercih edilir.

Milyarlarca harf nasıl aranıyor?

Klasik dinamik programlama algoritmalarının zaman karmaşıklığı genellikle $O(nm)$ düzeyindedir. Milyarlarca baz söz konusu olduğunda bu maliyet fazlasıyla büyür. BLAST gibi araçlar bu nedenle önce kısa ve umut vadeden eşleşmeleri bulur, ardından yalnızca bu bölgeleri ayrıntılı biçimde hizalar. Bu yaklaşım kesin sonucu garanti etmek yerine hız ile doğruluk arasında kullanışlı bir denge kurar.

Kısacası genom analizi, DNA’yı sıradan bir metin olarak görmekten çok daha fazlasıdır. Dizi algoritmaları, olasılık, dinamik programlama ve yüksek performanslı hesaplama birlikte çalışarak dört harfli biyolojik alfabenin içindeki yaşam hikâyesini okunabilir hâle getirir.

Katman mantığı nedir?

GIS ortamında gerçek dünyanın farklı özellikleri ayrı veri katmanlarında tutulur. Yol ağı bir çizgi katmanı, binalar poligon katmanı, hastaneler nokta katmanı olabilir. Uydu görüntüsü ve yükseklik modeli gibi kesintisiz veriler ise genellikle raster biçimindedir.

Bu katmanların birlikte kullanılabilmesi için aynı koordinat referans sistemine dönüştürülmesi gerekir. Örneğin mesafe ve alan hesabı yapılacaksa derece kullanan coğrafi koordinatlar yerine metre tabanlı uygun bir projeksiyon tercih edilmelidir. Aksi hâlde harita güzel görünürken hesaplar sessizce hatalı sonuç verebilir.

Uygunluk modeli nasıl kurulur?

Yeni bir konut bölgesi aradığımızı düşünelim. Düz araziler, ana yollara yakın bölgeler ve mevcut altyapıya erişebilen alanlar avantajlıdır. Taşkın riski yüksek, orman niteliğindeki veya aşırı eğimli bölgeler ise elenmelidir.

Her ölçüt ortak bir ölçeğe, örneğin 0 ile 1 arasına normalize edilebilir. Ardından ağırlıklı doğrusal birleşim uygulanır:

Burada $S$ toplam uygunluk puanı, $x_i$ normalize edilmiş ölçüt değeri ve $w_i$ karar vericinin belirlediği ağırlıktır. Ağırlıkların toplamı genellikle $\sum w_i = 1$ olacak şekilde düzenlenir. Örnek olarak eğim için 0,30; ulaşım için 0,25; altyapı için 0,25 ve nüfus talebi için 0,20 kullanılabilir.

Ancak yüksek puan, alanın otomatik olarak imara açılması gerektiği anlamına gelmez. Yasal koruma sınırları gibi kesin kısıtlar ayrı bir maske ile uygulanır:

$M$ değeri yasak bölgelerde 0, değerlendirilebilir bölgelerde 1 olur. Böylece çok erişilebilir olsa bile bir sulak alan sonuç listesinden çıkarılır.

Python ile basit bir mekânsal eleme

Aşağıdaki GeoPandas örneği, aday parsellerden taşkın alanlarıyla kesişenleri çıkarır ve yollara yakın olanları seçer:

import geopandas as gpd

parseller = gpd.read_file("aday_parseller.geojson")
yollar = gpd.read_file("ana_yollar.geojson")
taskin = gpd.read_file("taskin_alani.geojson")

# Tüm katmanları metre tabanlı aynı koordinat sistemine getirir.
hedef_crs = "EPSG:32636"
parseller = parseller.to_crs(hedef_crs)
yollar = yollar.to_crs(hedef_crs)
taskin = taskin.to_crs(hedef_crs)

# Ana yolların çevresinde 1000 metrelik erişim bölgesi oluşturur.
yol_tamponu = yollar.buffer(1000).union_all()

# Yola yakın ve taşkın alanıyla kesişmeyen parselleri belirler.
uygun = parseller[
    parseller.intersects(yol_tamponu)
    & ~parseller.intersects(taskin.union_all())
].copy()

uygun.to_file("uygun_parseller.geojson", driver="GeoJSON")

Bu işlem yalnızca ilk elemedir. Sonraki aşamada parsel alanı, eğim ortalaması, toplu taşımaya mesafe ve altyapı maliyeti gibi nitelikler puanlanabilir.

Harita kararın kendisi değildir

GIS güçlü bir karar destek aracıdır; fakat verinin güncelliği, çözünürlüğü ve kaynağı sonucu doğrudan etkiler. Ayrıca ağırlıklar teknik uzmanlar, yerel yönetimler ve bölge halkıyla birlikte belirlenmelidir. Farklı ağırlık senaryolarını karşılaştıran duyarlılık analizi, hangi kararların sağlam kaldığını gösterir.

Sonuç olarak katmanlı analiz, şehir planlamasını sezgisel bir çizim çalışmasından şeffaf bir değerlendirme sürecine taşır. En iyi harita yalnızca nerede yapılaşılabileceğini değil, neden orada yapılaşmanın daha dengeli olduğunu da açıklayabilen haritadır.

``

Sistemin Temel Mimarisi

Akıllı sera sistemi üç katmandan oluşur. Sensör katmanında sıcaklık ve hava nemi için DHT22, toprak nemi için kapasitif sensör, ışık seviyesi için BH1750 kullanılabilir. Kontrol katmanındaki ESP32 veya Raspberry Pi verileri işler. Eyleyici katmanında ise fan, sulama pompası, sisleme sistemi, ısıtıcı ve LED lambalar bulunur.

Sensör düğümleri MQTT gibi hafif bir mesajlaşma protokolüyle merkezi denetleyiciye veri gönderir. Örneğin sera/sicaklik konusu sıcaklık ölçümlerini, sera/toprak_nemi konusu ise sulama kararında kullanılacak değerleri taşıyabilir.

Kontrol Mantığının Teorisi

En basit yöntem eşik tabanlı kontroldür. Ölçülen değer $x$, alt sınır $L$ ve üst sınır $U$ ile karşılaştırılır:

Buradaki $u$, cihazın açık veya kapalı olmasını temsil eder. Ancak tek bir eşik kullanılırsa ölçüm sınır çevresinde dalgalandığında röle sürekli açılıp kapanabilir. Bunu önlemek için histerezis uygulanır. Örneğin pompa, toprak nemi %40’ın altına düşünce açılır; %55’e ulaşınca kapanır.

Daha hassas sıcaklık kontrolünde PID algoritması kullanılabilir:

Burada $e(t)$, hedef sıcaklık ile ölçülen sıcaklık arasındaki farktır. Oransal bileşen mevcut hataya, integral bileşen birikmiş hataya, türev bileşeni ise değişim hızına tepki verir.

Örnek Kontrol Algoritması

Aşağıdaki Python kodu, sensör verilerine göre fanı, pompayı ve lambayı yönetir. Gerçek projede değişkenler MQTT mesajlarından veya sensör sürücülerinden alınabilir.

sicaklik = 30.2
toprak_nemi = 37
isik = 7200

pompa_acik = False

if sicaklik > 28:
    fan = True
elif sicaklik < 24:
    fan = False

# Histerezisli sulama kontrolü
if toprak_nemi < 40:
    pompa_acik = True
elif toprak_nemi > 55:
    pompa_acik = False

# Yetersiz doğal ışıkta destek aydınlatması
lamba = isik < 10000

print({'fan': fan, 'pompa': pompa_acik, 'lamba': lamba})

Kodun belirli aralıklarla çalıştırılması yerine olay tabanlı MQTT mesajlarıyla tetiklenmesi ağ trafiğini ve enerji tüketimini azaltabilir. Kablosuz sensörler pille çalışıyorsa ölçümlerin her saniye değil, örneğin her 30 saniyede bir gönderilmesi daha mantıklıdır.

Daha Güvenilir Bir Sera İçin

Otomasyon sistemi yalnızca anlık ölçümlere güvenmemelidir. Hareketli ortalama kullanılarak gürültü azaltılabilir:

Ayrıca sensör kopması, aşırı sıcaklık veya uzun süre çalışan pompa için güvenlik kuralları tanımlanmalıdır. Verilerin InfluxDB gibi zaman serisi veritabanında saklanması, Grafana üzerinden izlenmesi ve kritik durumlarda telefona bildirim gönderilmesi sistemi tamamlar. Böylece sera, bitkilerin ihtiyaçlarını tahmin eden küçük ama çalışkan bir dijital bahçıvana dönüşür.