``

Önce beklentiyi doğru ayarlayalım

Bir beyin–bilgisayar arayüzü, İngilizce kısaltmasıyla BCI, kas hareketlerini zorunlu tutmadan sinirsel etkinlik üzerinden iletişim kurmayı hedefler. Örneğin kullanıcı sağ veya sol elini hareket ettirdiğini hayal eder; sistem bu iki durumu ayırt etmeye çalışır. Bazı sistemlerdeyse kullanıcı yanıp sönen seçeneklerden birine odaklanır. Buradaki bilgi, serbest düşüncenin içeriği değil, önceden tanımlanmış bir görevle ilişkili örüntüdür.

Ölçüm yöntemleri aynı kapıya farklı yollardan ulaşır:

Sinyalden komuta: küçük bir çeviri fabrikası

Tipik işlem zinciri şöyledir:

Ölçüm → temizleme → özellik çıkarımı → sınıflandırma → komut → geri bildirim.

EEG, tek bir nöronun konuşması değildir. Çok sayıda kaynağın elektriksel etkileri, ölçüm noktasında birbirine karışır. Göz kırpması, çene kasları ve elektrik şebekesi de bu karışıma katılabilir. Dolayısıyla yüksek genlik, otomatik olarak güçlü bir niyet anlamına gelmez.

Motor imgelemede sık incelenen özellikler, yaklaşık 8–13 Hz mu ve 13–30 Hz beta bantlarındaki güç değişimleridir. Bu değişimler kişiye ve göreve göre farklılaşır; sabit bir düşünce sözlüğü oluşturmazlar. Özellik vektörünü $h$ ile gösterirsek, basit bir ikili sınıflandırıcı şöyle yazılabilir:

Burada $w$ öğrenilen ağırlıkları, $b$ sabit terimi, $p$ ise modelin bir sınıfa verdiği olasılık tahminini temsil eder. Bu tahminin güvenilirliği ayrıca değerlendirilmelidir. Model, kişinin niyetini doğrudan bilmez; eğitim verisindeki ilişkilere dayanarak karar verir. Korelasyon, zihin okuma değildir.

Python ile bant gücünden sınıflandırmaya

Aşağıdaki örnek, NumPy, SciPy ve scikit-learn kullanır. Dosyada artefaktları önceden ele alınmış EEG denemeleri bulunmalıdır: X boyutu (deneme, kanal, örnek), y sağ/sol imgeleme etiketleri, oturum kayıt oturumu kimlikleri, fs örnekleme frekansıdır. En az üç farklı oturum gerekir.

import numpy as np
from scipy.signal import welch
from sklearn.pipeline import make_pipeline
from sklearn.preprocessing import StandardScaler
from sklearn.linear_model import LogisticRegression
from sklearn.model_selection import GroupKFold, cross_val_score

d = np.load("eeg_denemeleri.npz")
X, y, oturum = d["X"], d["y"], d["oturum"]
fs = float(d["fs"])
f, psd = welch(X, fs=fs,
               nperseg=min(256, X.shape[-1]), axis=-1)

bantlar = []
for alt, ust in [(8, 13), (13, 30)]:
    sec = (f >= alt) & (f < ust)
    guc = np.trapezoid(psd[..., sec], f[sec], axis=-1)
    bantlar.append(np.log(guc + 1e-12))
F = np.concatenate(bantlar, axis=1)

model = make_pipeline(StandardScaler(),
                      LogisticRegression(max_iter=1000))
skorlar = cross_val_score(
    model, F, y, groups=oturum,
    cv=GroupKFold(n_splits=3), scoring="balanced_accuracy"
)
print(skorlar.mean())

Welch yöntemi güç spektrumunu tahmin eder; bant integralleri kanal başına özellik üretir. Logaritma, güç değerlerinin geniş aralığını sıkıştırır. Pipeline, ölçekleyicinin yalnızca eğitim bölümünde öğrenilmesini sağlar. Oturum bazlı bölme ise aynı kaydın benzer parçalarının eğitim ve teste karışmasını önler. Kod, NumPy 2 veya üzerindeki trapezoid işlevini kullanır.

Laboratuvardan gerçek hayata geçiş

Yüksek test başarısı, kullanışlı bir arayüz için tek başına yeterli değildir. Gecikme, yanlış komut sıklığı, kalibrasyon süresi ve kullanıcı yorgunluğu da ölçülmelidir. Dengeli doğruluk, sınıfların ayrı ayrı başarılarını eşit ağırlıkla değerlendirir. Rastgele deneme bölmek yerine yeni oturumlarda sınamak, günlük kullanım performansını anlamaya daha çok yardımcı olur.

Gerçek zamanlı sistemde kararsız tahminler komuta dönüştürülmeyebilir. Kullanıcıya geri bildirim vermek ve gerektiğinde onay istemek, özellikle tekerlekli sandalye gibi fiziksel sonuç doğuran uygulamalarda önemlidir. Bu örnek, güvenlik doğrulaması yapılmış bir kontrol sistemi değildir.

Sinirsel kayıtlar da hassas verilerdir: açık rıza, sınırlı saklama ve güvenli erişim tasarımın parçası olmalıdır. Klinik uygulamalarda profesyonel değerlendirme gerekir. Sonuç olarak düşünceden komuta geçmek mümkün; fakat başarılı BCI, sihirli bir okuyucu değil, kullanıcıyla birlikte öğrenen kontrollü bir çevirmen gibi çalışır.

Bir robotun sabah depoda kutu taşıyıp öğleden sonra serada bitki kontrolü yaptığını düşünün. Bunu iki ayrı makineyle çözmek mümkün; ancak modüler tasarım, aynı gövdenin hareket, algılama ve tutma bileşenlerini değiştirerek farklı görevlere uyarlanmasını sağlar. Robot biraz LEGO setine benzer, fakat burada parçaların yalnızca birbirine oturması değil, birlikte güvenle çalışması gerekir. ``

Modülerlik: Parçalardan Daha Büyük Bir Fikir

Modüler robot, belirli işlevleri bağımsız birimlere ayıran robot mimarisidir. Tekerlek takımı hareketi, kamera çevreyi algılamayı, kavrayıcı ise nesnelerle etkileşimi üstlenebilir. Her birimin görev sınırı ve bağlantı kuralları açıkça tanımlanır. Böylece bir bileşeni değiştirmek, robotun tamamını yeniden tasarlamayı gerektirmez. Buradaki temel ilke, işlevsel ayrıştırma ve standart arayüzlerdir.

Bu yaklaşımın iki yaygın biçimi vardır. Sabit gövdeli sistemlerde uç araçlar ve sensörler değiştirilir. Yeniden yapılandırılabilir sistemlerde ise bağlantılı modüller robotun fiziksel biçimini de değiştirebilir. İlk yaklaşım endüstriyel uygulamalarda daha kolay yönetilirken ikincisi daha geniş hareket olanakları sunar; buna karşılık kontrol ve bağlantı tasarımı zorlaşır.

Mimariyi $G=(V,E)$ grafiğiyle düşünebiliriz: $V$ modülleri, $E$ ise aralarındaki bağlantıları temsil eder. Bağlantının mekanik, elektriksel veya veri taşıyan niteliği önemlidir. Bir kameranın takılabilmesi, kontrol yazılımının onu kullanabileceği anlamına gelmez!

Esnekliğin Gizli Kahramanı: Arayüzler

Başarılı modülerlik, bağlantı noktasında başlar. Mekanik arayüz; ölçüleri, kilitleme yöntemini ve taşınabilecek yükü belirlemelidir. Elektriksel arayüz; gerilim, akım sınırı, kutuplama ve koruma düzenini tanımlar. Veri arayüzü ise mesaj biçimini, haberleşme hızını ve hata davranışını kapsar. CAN veya Ethernet kullanmak tek başına yeterli değildir; modüllerin aynı mesajların anlamında da anlaşması gerekir.

Yazılım tarafında sürücüler, donanım ayrıntılarını ortak yeteneklere dönüştürebilir. Örneğin farklı kavrayıcılar aynı “aç”, “kapat” ve “durum oku” işlemlerini sunar. Böylece görev planlayıcısı marka veya model yerine yeteneklerle çalışır. Yine de kavrama kuvveti ve konum hassasiyeti gibi sınırlar ayrıca bildirilmelidir.

Fizik kuralları ise tak-çıkar heyecanına kapılmaz. Bir kolun yükten kaynaklanan torku basitçe $T=F r$ ile hesaplanır. Burada $F$ kuvvet, $r$ dönme eksenine olan dik uzaklıktır. Aynı yükü iki kat uzağa taşımak, tork ihtiyacını iki katına çıkarır. Dolayısıyla daha uzun modül, daha güçlü motor veya daha düşük taşıma kapasitesi gerektirebilir.

Python ile Göreve Uygun Yapılandırma

Aşağıdaki örnek, seçilen modüllerin besleme gerilimini ve görev yeteneklerini denetler. Donanımı hareket ettirmez; yapılandırmanın yazılım düzeyindeki bir ön kontrolüdür. Python 3.9 ve üzeriyle çalışır.

from dataclasses import dataclass

@dataclass(frozen=True)
class Module:
    name: str
    capabilities: frozenset[str]
    voltage: int = 24

modules = {
    "drive": Module("Tekerlek", frozenset({"hareket"})),
    "gripper": Module("Kavrayıcı", frozenset({"kavrama"})),
    "camera": Module("Kamera", frozenset({"görüntüleme"})),
}

def configure(names, required):
    selected = [modules[name] for name in names]
    if any(module.voltage != 24 for module in selected):
        raise ValueError("Besleme gerilimi uyumsuz")
    available = frozenset().union(
        *(module.capabilities for module in selected)
    )
    missing = set(required) - available
    if missing:
        raise ValueError(f"Eksik yetenekler: {sorted(missing)}")
    return [module.name for module in selected]

print(configure(["drive", "gripper"], {"hareket", "kavrama"}))
print(configure(["drive", "camera"], {"hareket", "görüntüleme"}))

İlk çağrı taşıma, ikinci çağrı gözlem görevine uygun parçaları seçer. Gerçek uygulamada bu kontrole mekanik uyumluluk, akım bütçesi, haberleşme protokolü ve güvenlik kısıtları da eklenmelidir. Yetenek etiketi, performans garantisi değildir.

Parça Değiştiğinde Ne Yeniden Kontrol Edilmeli?

Modül değişimi sonrasında robotun kütlesi, ağırlık merkezi ve durma mesafesi değişebilir. Kamera değişirse kalibrasyon; kavrayıcı değişirse kuvvet sınırları ve araç koordinat sistemi güncellenmelidir. Yapılandırma kaydı tutmak, hangi donanımın hangi yazılım sürümüyle test edildiğini izlemeyi kolaylaştırır. Bu kayıtlar bakım ekibinin “Dün çalışıyordu!” bilmecesini çözmesinde özellikle değerlidir.

Sistem özel olarak enerjiliyken değişime uygun tasarlanmamışsa parçalar güç kesilerek değiştirilmelidir. Ardından bağlantılar doğrulanmalı, düşük hızda işlev testi yapılmalı ve güvenlik sınırları yeniden değerlendirilmelidir.

Modülerlik her durumda daha ucuz veya daha hafif değildir. Ek bağlantılar maliyet, boşluk ve arıza noktası yaratabilir. Ancak görevler sık değişiyorsa ortak gövdeyi korumak ciddi avantaj sağlar. İyi tasarlanmış modüler robot, her işi kusursuz yapan sihirli makine değil; yeni işleri kontrollü biçimde öğrenebilen bir mühendislik platformudur.

``

Olay nedir, komuttan farkı ne?

Olay, gerçekleşmiş bir durumun kaydıdır: “Hareket algılandı.” Komut ise yapılması istenen iştir: “Lambayı aç.” Bu ayrım önemlidir; hareket sensörü lambanın nasıl çalıştığını bilmek zorunda değildir. Yalnızca gözlemini yayınlar, otomasyon kuralları da uygun komutları üretir.

Tipik mimaride üç rol vardır: olayı üreten sensör, mesajı taşıyan olay veri yolu ve mesajı işleyen tüketiciler. MQTT kullanılan sistemlerde aracı sunucu mesajları abonelere iletir. Bununla birlikte, MQTT tek başına otomasyon kurallarını değerlendirmez; bu görev uygulamanıza veya otomasyon platformuna aittir.

Bu yöntemler rakip değil, takım arkadaşıdır. Örneğin hareket olayı lambayı açarken, zamanlanmış bir görev gecenin sonunda açık kalan lambaları kapatabilir.

Zincirin matematiği: olay, koşul ve durum

Bir kuralı “olay geldi, koşul doğruysa eylemi gerçekleştir” şeklinde düşünebiliriz. Hareketi $H$, gece koşulunu $G$, lambayı açma kararını $L$ ile gösterirsek:

Ancak yalnızca koşulları değerlendirmek yetmez. Lambanın mevcut durumunu da bilmeliyiz. Durum geçişini $S_{t+1} = f(S_t, E_t)$ olarak yazabiliriz: yeni durum, önceki durum ve gelen olay tarafından belirlenir.

Lamba zaten açıksa tekrar açma komutu göndermemek, gereksiz işlemleri azaltır. Üstelik zincirin bir sonraki halkasını yalnızca gerçek durum değiştiğinde tetiklememizi sağlar. Böylece eviniz, aynı düğmeye heyecanla yüz kere basan bir robot gibi davranmaz.

Python ile küçük bir olay zinciri

Aşağıdaki örnek, sensör olayını bir kuyruğa bırakır. Hareket işleyicisi gece koşulunu değerlendirir; lamba açıldığında yeni bir olay üretir. İkinci işleyici de telefon bildirimini temsil eden çıktıyı oluşturur. Gerçek cihaz bağlantıları yerine simülasyon kullanıyoruz.

import asyncio
from dataclasses import dataclass

@dataclass
class Event:
    kind: str
    data: dict

bus = asyncio.Queue()
state = {"light": False}

async def on_motion(event):
    hour = event.data["hour"]
    is_night = hour >= 22 or hour < 6
    if is_night and not state["light"]:
        state["light"] = True
        print("Koridor lambası açıldı.")
        await bus.put(Event("light.changed", {"on": True}))

async def on_light(event):
    if event.data["on"]:
        print("Telefon bildirimi: Koridor aydınlatıldı.")

handlers = {
    "motion.detected": on_motion,
    "light.changed": on_light,
}

async def main():
    await bus.put(Event("motion.detected", {"hour": 23}))
    while not bus.empty():
        event = await bus.get()
        try:
            handler = handlers.get(event.kind)
            if handler:
                await handler(event)
        finally:
            bus.task_done()

asyncio.run(main())

handlers sözlüğü, olay türlerini ilgili fonksiyonlarla eşleştirir. Kuyruk ise üretici ile tüketiciyi birbirinden ayırır. Bu örnekte işleyiciler sırayla beklenir; async kullanılması bütün işlemlerin otomatik olarak paralel çalıştığı anlamına gelmez. Ayrıca döngü kuyruk boşalınca biter; sürekli çalışan uygulamada yeni olaylar await bus.get() ile beklenir.

Gerçek lambada durum değişikliğini, komut gönderildiği anda değil cihazdan doğrulama geldiğinde yayınlamak daha güvenilirdir. Aksi hâlde bağlantısı kopmuş bir lambayı yazılımda açık sanabilirsiniz.

Zinciri güvenilir tutmak

Olay tabanlı sistemlerin eğlenceli tarafı bağlantı kurmaktır; zor tarafı ise bağlantıları kontrol altında tutmaktır.

• Tekrarlanan mesajlar: Olay kimliği ve idempotent işleyiciler kullanın. Aynı olayın yeniden gelmesi sonucu değiştirmemelidir.
• Sonsuz döngüler: Lambanın değişimi sensör kuralını yeniden tetikliyorsa döngü oluşabilir. Kaynak bilgisi ve açık geçiş kuralları ekleyin.
• Sensör titreşimi: Çok kısa aralıklarla gelen sinyalleri filtrelemek için debounce uygulayın. Hareketli bir perdeyi misafir sanmayın!
• Bağlantı kesintileri: Yeniden deneme, zaman aşımı ve durum uzlaştırma mekanizmaları tasarlayın. Tek bir mesajı mutlak gerçek kabul etmeyin.
• Güvenlik: MQTT erişimini kimlik doğrulama ve konu bazlı yetkilerle sınırlandırın; kritik cihazlarda manuel kontrolü koruyun.

Sonuç olarak iyi otomasyon, yalnızca cihazları bağlamak değildir. Olayın anlamını, koşullarını ve oluşturduğu durum değişikliklerini açıkça tanımlamaktır. Bu temel sağlam olduğunda, tek bir sensör evinizin geri kalanıyla düzenli ve anlaşılır bir sohbet başlatabilir.

Bir banka hesabını programlamak istediğinizi düşünün: hesabın bakiyesi vardır, para çekilebilir ve işlemin sonucu öğrenilebilir. C# bu dünyayı sınıflar, nesneler ve metotlarla temsil eder. İşin eğlenceli kısmı, aynı hesaba iki farklı değişkenle ulaşabilmenizdir. Ancak bir nesneyi değiştirmekle, değişkenin gösterdiği nesneyi değiştirmek aynı şey değildir!

``

Sınıf plan, nesne çalışan örnektir

Sınıf, verileri ve davranışları bir araya getiren tür tanımıdır. Nesne, bu sınıftan oluşturulan somut örnektir. Metot ise bir nesnenin gerçekleştirebildiği işlemi tanımlar; ayrıca sınıfa ait statik metotlar da bulunabilir.

Bir sınıftan oluşturulan iki nesnenin bakiyeleri birbirinden bağımsız olabilir. Buna karşılık iki değişken aynı nesneye bağlanabilir. Aynı televizyonu yöneten iki kumanda düşünün: kumandalar farklıdır, fakat değiştirilen televizyon aynıdır.

C# sınıfları referans türüdür. Bir sınıf değişkeninin değeri, nesnenin kendisi değil, ona erişmeyi sağlayan referanstır. Referansı kopyalamak, nesneyi çoğaltmaz.

Durumu davranışla korumak

Aşağıdaki sınıf, bakiyenin dışarıdan doğrudan değiştirilmesini engeller. Kurucu metot başlangıç durumunu oluşturur; ParaCek ise çekim kurallarını uygular ve sonucu bildirir.

using System;

public class Hesap
{
    public decimal Bakiye { get; private set; }

    public Hesap(decimal bakiye)
    {
        if (bakiye < 0)
            throw new ArgumentOutOfRangeException(nameof(bakiye));

        Bakiye = bakiye;
    }

    public bool ParaCek(decimal tutar, out decimal kalan)
    {
        kalan = Bakiye;

        if (tutar <= 0 || tutar > Bakiye)
            return false;

        Bakiye -= tutar;
        kalan = Bakiye;
        return true;
    }
}

private set, bakiyenin yalnızca sınıf içinden atanabilmesini sağlar. Bu yaklaşım kapsülleme olarak adlandırılır: veriyi saklamaktan çok, geçerli durumları korumak önemlidir. Negatif başlangıç bakiyesi reddedilir; geçersiz çekim ise hesabı değiştirmez.

Başarılı çekimin matematiksel modeli şöyledir:

Burada $T$ çekilen tutardır; işlemin kabul koşulu $0 < T \leq B_{ilk}$ şeklindedir. Kod, bu koşulu denetleyerek nesnenin tutarlılığını korur. Para hesaplarında decimal, ondalık değerleri temsil etmek için genellikle double türünden daha uygundur.

Varsayılan aktarım, ref ve out

C# parametreleri varsayılan olarak değer ile aktarır. decimal parametresinde sayısal değer kopyalanır. Hesap parametresinde ise referansın değeri kopyalanır. Bu yüzden normal bir parametre üzerinden nesnenin özelliklerini değiştirmek mümkündür; bunun için ref gerekmez.

Ancak metot içinde normal parametreye new Hesap(...) atamak, çağıranın değişkenini başka nesneye yönlendirmez. Yalnızca parametrenin yerel kopyası değişir. İşte ref, çağıranın değişkenine erişim sağlayarak bu ayrımı görünür kılar.

ref ve out, hem metot bildiriminde hem çağrıda belirtilir. out parametresi, metot içinde okunmadan önce atanmalıdır. Örneğimizde kalan başlangıçta atanır; böylece başarısız çekimde bile kullanılabilir bir sonuç döner.

Referansı değiştirmek başka bir iştir

.NET 6+ konsol projesinde aşağıdaki üst düzey kullanım kodunu sınıf bildiriminden önce yerleştirebilirsiniz:

var hesap = new Hesap(100m);
var ortak = hesap;

bool basarili = hesap.ParaCek(30m, out decimal kalan);
Console.WriteLine($"Başarılı: {basarili}, kalan: {kalan}");

ortak.ParaCek(10m, out kalan);
Console.WriteLine(hesap.Bakiye); // 60

Yenile(ref hesap);
Console.WriteLine(hesap.Bakiye); // 0
Console.WriteLine(ortak.Bakiye); // 60

static void Yenile(ref Hesap hedef)
{
    hedef = new Hesap(0m);
}

İlk atamada ortak ve hesap aynı nesneyi gösterir. Dolayısıyla ortak üzerinden yapılan çekim, hesap üzerinden görülen bakiyeyi de değiştirir. Yenile ise ref sayesinde doğrudan hesap değişkeninin referansını değiştirir. ortak, eski nesneyi göstermeyi sürdürür; nesne topluca sıfırlanmamıştır.

Küçük bir seçim rehberi

Tek sonuç için çoğunlukla dönüş değerini kullanın. Başarı bilgisiyle ek sonuç gerekiyorsa out kullanışlıdır; int.TryParse bunun klasik örneğidir. Çağıranın mevcut değişkenini değiştirmek gerekiyorsa ref düşünülebilir. Son kontrol sorunuz şu olsun: “Nesnenin durumunu mu, değişkenin değerini mi değiştiriyorum?” Bu ayrım, referans karmaşasının büyük bölümünü çözer.

``

Titreşim neden değerli bir ipucudur?

Dönen tambur, motor, rulmanlar ve amortisörler farklı titreşim bileşenleri üretir. Dengesiz yük, dönme frekansı çevresindeki hareketi artırabilir; rulman hasarı ise darbe benzeri bileşenler oluşturabilir. Ancak aynı belirti birden fazla nedenden kaynaklanır. Sensörümüz dedektiftir, kahin değil!

Dakikada 1200 devir yapan tamburun dönme frekansı $1200/60=20\,\text{Hz}$ olur. Frekans analizi, titreşim enerjisinin hangi bölgelerde yoğunlaştığını gösterir. Bu bilgi, toplam titreşim seviyesinden daha açıklayıcı olabilir.

Bunlar kesin teşhis değildir. Aynı makine, aynı hızda bile farklı yüklerle farklı davranabilir.

Önce doğru veriyi toplayalım

Bir ivmeölçer, üretici önerilerine uygun ve güvenli bir gövde noktasına sabitlenebilir. Sensörün konumu ve montajı değişirse referans da değişir. Elektrik veya hareketli parçalar çevresindeki müdahaleler uzmanlık gerektirir.

Örnekleme hızı, ilgilenilen en yüksek frekansın iki katından büyük olmalıdır: $f_s>2f_{\max}$. Pratikte uygun kenar payı ve örnekleme öncesi anti-aliasing filtresi gerekir. Örneğin 2 kHz örnekleme, aşağıdaki örnekte kullanılan 300–800 Hz bandını incelemeye uygundur; bu bant her makine için evrensel değildir.

İki saniyelik pencerelerde üç özellik çıkaralım: RMS, basıklık ve bant enerjisi oranı. RMS genel titreşim seviyesini özetler:

Basıklık, darbe karakterine duyarlıdır. Bant enerjisi oranı ise seçilen frekans bölgesinin toplam güç içindeki payını gösterir. Öncesinde sinyal ortalamasını çıkararak sabit bileşeni azaltırız.

Python ile küçük bir erken uyarı motoru

Aşağıdaki kod, tek eksenli ivme penceresinden özellik çıkarır. Sağlıklı çalışma pencerelerinden hazırlanmış referans matrisiyle karşılaştırarak bir anomali puanı üretir. Her referans satırı aynı üç özelliği içermelidir.

import numpy as np
from scipy.signal import welch
from scipy.stats import kurtosis


def ozellikler(ivme, fs=2000):
    a = np.asarray(ivme, dtype=float)
    a = a - a.mean()
    f, p = welch(a, fs=fs, nperseg=min(len(a), 1024))
    bant = (f >= 300) & (f <= 800)
    return np.array([
        np.sqrt(np.mean(a ** 2)),
        kurtosis(a, fisher=False),
        p[bant].sum() / (p.sum() + 1e-12)
    ])


def alarm_puani(ivme, referans, fs=2000):
    ref = np.asarray(referans, dtype=float)
    medyan = np.median(ref, axis=0)
    mad = np.median(np.abs(ref - medyan), axis=0)
    z = (ozellikler(ivme, fs) - medyan) / (1.4826 * mad + 1e-6)
    return float(np.maximum(z, 0).max())

Medyan ve MAD, uç değerlerin referansı bozmasını azaltır. Puan yalnızca referansın üzerindeki sapmaları toplar; arıza olasılığı değildir. Sabit veya geçersiz sensör verileri ayrıca filtrelenmeli, çok küçük MAD değerleri için özellik bazında ölçek tabanları belirlenmelidir.

Veriyi değil, anlamını gönderelim

Sensör verisi önce yerel işlemcide özetlenebilir. Özellikler, tambur hızı, program aşaması ve zaman damgasıyla MQTT üzerinden TLS kullanılarak sunucuya iletilir. Cihaz kimlik doğrulaması ve erişim yetkileri de şarttır.

Bağlantı kesilirse yerel tampon kullanılabilir. Böylece internetin molası, izleme sisteminin hafızasını silmez.

Alarmdan gerçek tahmine geçiş

Referansları program, yük ve hız koşullarına göre ayırmak gerekir. Tek bir yüksek puan yerine birkaç karşılaştırılabilir pencerede kalıcı artış aranmalıdır. Eşikler gerçek saha verisiyle ayarlanır; yanlış alarm oranı ve bakım öncesi uyarı süresi birlikte ölçülür.

Gerçek kestirimci bakım için zaman içindeki eğilimler, servis kayıtları ve doğrulanmış arıza etiketleri gerekir. Bakım sonrası titreşimin normale dönmesi de değerli geri bildirimdir. Yalnızca titreşimden “rulman üç gün sonra bozulacak” demek güvenilir değildir. Başarılı sistem, gerektiğinde “alışılmadık bir değişim var, kontrol ettirelim” diyendir. Banyonun yeni dansçısını erken fark etmek bile iyi bir başlangıçtır!

``

Temel fikir: Aynı başlangıç, aynı sonuç

Her istemci, oyun dünyasının tamamını yerel olarak simüle eder. Ağ üzerinden genellikle “birlikleri şu noktaya gönder” veya “kışla inşa et” gibi komutlar taşınır. Başlangıç durumu ve işlenen komutlar aynıysa, simülasyonun her bilgisayarda aynı sonucu üretmesi beklenir.

Bunu şu bağıntıyla düşünebiliriz:

Burada $S_k$ dünya durumu, $C_k$ ilgili simülasyon adımının sıralanmış komutları, $F$ ise deterministik güncelleme fonksiyonudur. Lockstep, istemcilerin aynı adım için gereken komutlar tamamlanmadan ilerlememesini sağlar. Determinizm ise ilerlediklerinde aynı yere ulaşmalarını sağlar. Bu iki kavram birbirinin yerine geçmez.

Determinizm neden zor?

“Aynı kod çalışıyor, sonuç da aynıdır” düşüncesi burada tehlikelidir. Kayan noktalı hesaplamalar; işlemci, derleyici optimizasyonu veya matematik kütüphanesine göre farklılaşabilir. Küçük bir sapma, yüzlerce adım sonra iki istemcide farklı savaş sonuçları doğurabilir.

Bu yüzden kritik hesaplarda tam sayı veya sabit noktalı aritmetik tercih edilebilir. Sabit noktalı temsil, örneğin bir metreyi 1000 birim olarak saklar. Ancak taşma ve yuvarlama kuralları da tutarlı olmalıdır; yalnızca veri tipini değiştirmek sihirli çözüm değildir.

Rastgelelik de yasak değildir: Aynı algoritma, başlangıç tohumu ve çağrı sırası kullanılmalıdır. Koleksiyon dolaşım sırası, yol bulmadaki eşitlik kararları ve paralel işlerin tamamlanma sırası da sabitlenmelidir. Simülasyona duvar saati, değişken kare süresi veya yerel görsel efektlerden karar taşımayın.

İnternet bekler, simülasyon sayar

Simülasyon sabit zaman adımlarıyla ilerler: $t_k=k\Delta t$. Ekran çizimi daha hızlı olabilir; aradaki görüntüler enterpolasyonla yumuşatılabilir. Böylece 30 simülasyon adımıyla çalışan bir oyun, 144 Hz ekranda akıcı görünebilir.

Oyuncunun emri çoğunlukla mevcut adıma değil, birkaç adım sonrasına atanır. Bu giriş gecikmesi, paketlerin ulaşması için zaman kazandırır. Tamamlanan her oyuncu paketi, emir yoksa bile boş bir komut listesi içermelidir. Aksi halde “oyuncu hiçbir şey yapmadı” ile “paket henüz gelmedi” ayırt edilemez.

Paket kaybında yeniden gönderim gerekir. Komutlar adım ve oyuncu kimliğiyle eşleştirilmeli, tekrar gelenler ayıklanmalıdır. Geç kalan oyuncuyu sonsuza kadar beklemek yerine zaman aşımı ve bağlantı koparma politikası da tasarlanmalıdır.

Küçük bir lockstep çekirdeği

Aşağıdaki Python örneği, ağ katmanının doğrulanmış ve eksiksiz oyuncu paketlerini inbox[adım][oyuncu] yapısına koyduğunu varsayar:

def step_tick(state, tick, inbox, players, advance_fixed):
    bundles = inbox.get(tick, {})
    if set(bundles) != set(players):
        return False

    for player in sorted(players):
        commands = sorted(
            bundles[player], key=lambda command: command['seq']
        )
        for command in commands:
            if command['kind'] == 'move':
                unit = state['units'][command['unit']]
                unit['target'] = (command['x'], command['y'])

    advance_fixed(state)
    del inbox[tick]
    return True

Fonksiyon eksik paket varsa durur; aksi halde komutları ortak sırayla uygular ve dünyayı bir adım ilerletir. Çağıran döngü, yalnızca True sonucunda adım sayacını artırmalıdır. advance_fixed hareketi, çatışmayı ve kaynak üretimini deterministik biçimde yürütür. Gerçek uygulamada birim sahipliği, hedef geçerliliği ve sıra numarası benzersizliği ayrıca denetlenmelidir.

Senkron kaymasını yakalamak

Belirli aralıklarla dünya durumunun özeti karşılaştırılabilir. Ancak bellekteki ham nesneleri veya Python’ın yerleşik hash() sonucunu kullanmak güvenilir değildir. Birimleri kimliklerine göre sıralayıp alanları tanımlı bir biçimde serileştirerek kararlı bir özet üretin.

Özetler farklıysa bir desync vardır. İlk ayrışan adımı bulmak için başlangıç durumunu, komut günlüğünü ve ara özetleri saklamak çok değerlidir. Kurtarma gerekiyorsa güvenilir bir referans durumdan yeniden yükleme düşünülebilir; özet karşılaştırması tek başına hatayı düzeltmez.

Lockstep’in ödülü, binlerce birimin sürekli durum aktarımı olmadan birlikte çalışabilmesidir. Bedeli ise titiz mühendisliktir. Kısacası ağdan orduyu taşımayın; emirleri taşıyın ve bütün generallerin aynı kurallarla düşündüğünden emin olun.

Bir karakter düşünün: Karnı aç, uykusu var, ama komşusuyla dedikodu yapmayı da bırakamıyor. Simülasyon oyunlarını eğlenceli kılan tam olarak bu küçük çelişkilerdir. The Sims benzeri oyunlarda karakterler, yalnızca hazır animasyonlar oynatan kuklalar değildir; ihtiyaçları, çevresel fırsatları ve karar kuralları sayesinde yaşayan bir mahalle izlenimi yaratırlar.

``

Yapay yaşam: Bilinç değil, etkileşim

Yapay yaşam, canlı sistemlerin bazı özelliklerini hesaplamalı modellerle yeniden üretmeyi amaçlar. Oyunlarda bunun karşılığı; ihtiyaçları değişen, çevresini algılayan ve eylemlerinin sonuçlarından etkilenen ajanlardır. Buradaki ajan, kendi durumunu taşıyan bir karakterdir.

İnandırıcılık için insan zihnini bütünüyle simüle etmek gerekmez. Basit kuralların birleşmesiyle ortaya çıkan davranışlar üretilebilir: Aynı buzdolabına yönelen iki karakterden biri bekler, diğeri sohbet eder. Küçük bir kaynak çatışması, oyuncunun gözünde komik bir hikâyeye dönüşür.

Aşağıdaki model, bu yaklaşımı öğretmek içindir; The Sims’in gerçek kaynak kodunun birebir açıklaması değildir.

İhtiyaçları sayılara çevirmek

Her ihtiyacı $n_i$ ile gösterelim. Değerler sıfır ile bir arasında olsun: Sıfır, ihtiyaç karşılanmış; bir, ciddi eksiklik demektir. Böylece açlık ve enerji eksikliği aynı ölçekte karşılaştırılabilir.

Basit bir zaman güncellemesi şöyle yazılır:

Burada $h$ geçen süre, $r_i$ ise saniye başına artış hızıdır. Eylem tamamlandığında ilgili eksiklik azaltılır ve değer sıfırın altına düşmeyecek şekilde sınırlandırılır. Gerçek projelerde uyku gibi uzun eylemlerin etkisini tamamlanma anında değil, zaman boyunca uygulamak daha doğal sonuç verir.

Karar vermek: En faydalı eylem hangisi?

Utility AI, uygulanabilir eylemlere fayda puanı vererek seçim yapar. Basit bir puanlama kullanabiliriz:

$w_i$ ihtiyacın önemini, $d_i(a)$ eylemin sağlayacağı azalmayı, $T(a)$ süresini temsil eder. Minimum işlemi, zaten karşılanmış bir ihtiyaca gereğinden fazla fayda yazılmasını önler. Süre cezası ise uzak mutfağa yürümek gibi maliyetleri hesaba katabilir.

Python ile küçük bir karar motoru

Aşağıdaki örnek, önceden uygulanabilir olduğu belirlenmiş eylemler arasından seçim yapar. Karakterin mevcut eylemini değiştirmek için küçük bir avantaj eşiği kullanır:

from dataclasses import dataclass

@dataclass
class Action:
    name: str
    relief: dict[str, float]
    seconds: float

weights = {"hunger": 1.4, "energy": 1.2, "social": 0.8}
needs = {"hunger": 0.8, "energy": 0.5, "social": 0.3}

actions = [
    Action("yemek", {"hunger": 0.6}, 8),
    Action("uyumak", {"energy": 0.7}, 30),
    Action("sohbet", {"social": 0.5}, 12),
]

def score(action):
    benefit = sum(
        weights[key] * needs[key] * min(needs[key], relief)
        for key, relief in action.relief.items()
    )
    return benefit - 0.002 * action.seconds

def choose(available, current_name=None):
    if not available:
        return None
    best = max(available, key=score)
    current = next(
        (a for a in available if a.name == current_name), None
    )
    if current and score(best) < score(current) + 0.05:
        return current
    return best

print(choose(actions).name)

Action, eylemin etkisini ve süresini taşır. score, ihtiyaçlarla faydayı eşleştirir; choose ise en yüksek puanı seçer. Örnekte yemek kazanır. Eşik sayesinde karakter, puanlar birbirine yakınken sürekli fikir değiştirmez. Bu teknik histerezis olarak bilinir. Yine de mevcut eylem geçersizleşirse korunmaz; karar motoru başka bir seçenek arar.

Mahalleye hayat veren ayrıntılar

Puanlama tek başına yeterli değildir. Eylem adayları üretilirken nesnenin erişilebilirliği, kullanım kapasitesi ve yol bulma sonucu kontrol edilmelidir. Tuvaleti iki karakter aynı anda kullanmaya çalışıyorsa bir rezervasyon sistemi gerekir; yoksa dijital eviniz trafik kazasına döner.

Kişilik, ağırlıkları değiştirerek davranış çeşitliliği sağlar. Dışa dönük bir karakter sosyalliğe daha çok önem verebilir. İlişkiler, sohbetin beklenen faydasını; ruh hâli, eylem tercihlerini etkileyebilir. Bunlar rastgelelikten daha tutarlı farklılıklar üretir.

Son olarak aç kalma süresi, eylem değiştirme sıklığı ve nesne önündeki kuyrukları ölçün. Zaman adımını değiştirince davranışlar bozuluyorsa modeli yeniden ayarlayın. Başarılı yapay yaşam, en karmaşık algoritma değil; oyuncunun anlamlandırabildiği, tutarlı ama şaşırtıcı küçük hikâyeler üreten sistemdir.

Bir domatesin yolculuğu, market rafında başlamaz. Tarlada hasat edilir, paketlenir, kamyona yüklenir ve sonunda sofranıza ulaşır. Peki ambalajdaki “yerel üretim” iddiasını nasıl doğrulayabilirsiniz? Blok zincir, bu yolculuğun kayıtlarını farklı işletmeler arasında paylaşmayı ve sonradan yapılan değişiklikleri fark etmeyi sağlayabilir. Domatese dijital pasaport çıkarmaya hazır mısınız?

``

Temel Mantık: Birbirine Bağlanan Kayıtlar

İzlenebilirlik, bir ürünün kim tarafından, nerede ve ne zaman işlendiğini takip edebilmektir. Klasik sistemlerde kayıtlar çoğunlukla ayrı veritabanlarında tutulur. Çiftçinin defteriyle lojistik firmasının tablosu uyuşmadığında, gerçeği bulmak dedektiflik işine dönüşebilir.

Blok zincirde işlemler, ortak kurallarla doğrulanan bir deftere eklenir. Bloklar önceki blokların kriptografik özetlerine bağlanır. Basitleştirilmiş bir olay zincirini şöyle düşünebiliriz:

Burada $E_i$ yeni olay, $H$ özet fonksiyonu, $h_i$ yeni özettir. $\Vert$ verilerin birleştirilmesini gösterir. Eski kayıtta küçük bir değişiklik bile özeti değiştirir. Ancak güvenlik yalnızca bu matematikten gelmez: dijital imzalar, doğrulayıcılar ve uzlaşma mekanizması da gerekir.

Önce Ürünü Değil, Partiyi Tanımlayın

Her domatese ayrı kimlik vermek genellikle pahalıdır. Bunun yerine aynı hasattan gelen ürünler bir parti numarasıyla izlenebilir: DOM-2026-042 gibi.

Her olay; parti kimliği, aşama, zaman, işletme kimliği, miktar ve konum referansı taşımalıdır. Parti bölünürse yeni alt partiler oluşturulur; karıştırılırsa kaynak partiler açıkça ilişkilendirilir. Yoksa dijital pasaport, yolculuğun yarısında hafızasını kaybeder!

Miktar kontrolü de önemlidir. Basit bir denge için $Q_g = Q_c + Q_f + Q_k$ kullanılabilir: giren miktar; çıkan ürün, fire ve kalan stok toplamına eşit olmalıdır. Böylece 120 kilogram domatesten sihirli biçimde 180 kilogram ürün çıkması işaretlenir.

Küçük Bir Kod Deneyi

Aşağıdaki Node.js örneği, bir olayın önceki özete bağlanmasını gösterir. Bu, çalışan bir blok zincir değil; kayıt bağlantısının öğretici bir modelidir.

import { createHash } from "node:crypto";

const stages = new Set([
  "hasat", "paketleme", "sevkiyat", "teslim"
]);

function makeRecord(previousHash, event) {
  if (!stages.has(event.stage)) {
    throw new Error("Geçersiz aşama");
  }
  if (!(event.quantityKg > 0)) {
    throw new Error("Miktar pozitif olmalı");
  }

  const payload = JSON.stringify([
    event.batchId, event.stage, event.time,
    event.actorId, event.quantityKg
  ]);
  const hash = createHash("sha256")
    .update(previousHash + payload)
    .digest("hex");

  return { previousHash, payload, hash };
}

const harvest = makeRecord("0".repeat(64), {
  batchId: "DOM-2026-042", stage: "hasat",
  time: "2026-10-06T08:00:00Z",
  actorId: "ciftci-17", quantityKg: 120
});
console.log(harvest.hash);

Sabit alan sırası, aynı verinin aynı özeti üretmesine yardımcı olur. Sonraki olayda previousHash olarak harvest.hash kullanılır. Gerçek uygulamada şema doğrulaması, yetkilendirme ve imza kontrolü eklenmelidir. Tek kişinin yönettiği bu örnek zincir baştan hesaplanabilir; onu ortak uzlaşmayla korunan ağla karıştırmayın.

Değiştirilemezlik, Doğruluk Demek Değildir

Sensör yanlış ölçüyorsa blok zincir yanlış sıcaklığı sadakatle saklar. Buna fiziksel dünya ile dijital kayıt arasındaki güven problemi diyebiliriz. Kalibrasyon, mühürlü ambalaj, denetim ve güvenilir veri girişleri hâlâ gereklidir.

“Değiştirilemez” ifadesi de koşulludur: geçmişin değiştirilmesi ağın güvenlik varsayımları altında zorlaştırılır. Hatalı kayıt silinmek yerine, önceki olaya referans veren düzeltme işlemiyle tamamlanır.

Pilot Projeyi Nasıl Kurarsınız?

Bir üretici, paketleme tesisi ve marketle başlayın. Belgeleri ve ayrıntılı sensör verilerini erişim kontrollü depoda tutun; zincire özetlerini ve gerekli referansları yazın. Özet, belgenin değiştiğini gösterebilir ama belgenin erişilebilirliğini garanti etmez.

Ambalajdaki QR kod, tüketiciyi izlenebilirlik ekranına götürsün. Ticari sırları herkese açmadan köken ve aşamaları gösterin. Başarıyı işlem sayısıyla değil; geri çağırma süresi, kayıt eksikliği ve doğrulama maliyetiyle ölçün. Amaç domatesi teknolojiyle süslemek değil, sorun çıktığında doğru partiyi hızla bulmaktır.

Sabah mutfakta başlayan hareketlilik, öğleden sonra salona taşınan sakinlik… Evlerin de kendine özgü bir ritmi vardır. Hareket sensörleri, bu ritimdeki beklenmedik değişiklikleri görünür kılabilir. Ama amaç eve dijital bir Sherlock yerleştirmek değil; yaşlı veya yalnız yaşayan bireylerin bağımsızlığını korurken, gerektiğinde iletişim kurulmasını destekleyen, mahremiyete saygılı bir yardımcı geliştirmektir. ``

Sensör gerçekten neyi bilir?

Yaygın PIR sensörleri, görüş alanlarındaki kızılötesi değişimlerden hareket çıkarır. Birinin kim olduğunu, ne yaptığını veya sağlık durumunu doğrudan söylemezler. Dolayısıyla “hareket yok” ile “kişi tehlikede” aynı anlama gelmez: Uyku, dışarı çıkma, kitap okuma veya bağlantı arızası benzer kayıtlar oluşturabilir.

Temel veri akışı şöyledir: Sensör olayı, zaman damgası ve oda bilgisi yerel bir ağ geçidine ulaşır; ardından analiz için özetlenir. Saatlerin eşitlenmesi ve yinelenen kayıtların temizlenmesi önemlidir. Olay kaydı göndermeyen cihazın çalıştığını anlayabilmek için ayrıca düzenli durum mesajları gerekir. Aksi hâlde arızalı sensör, sessiz bir ev gibi görünür.

Ham olaylardan anlamlı özelliklere

Sensörün yeniden tetikleme süresi, olay sayısını etkiler. Bu nedenle yalnızca tetikleme sayısını karşılaştırmak yanıltıcıdır. Daha dengeli bir özellik, otuz dakikalık pencerede hareket görülen farklı dakikaların sayısıdır. Bütün odaların kayıtları birleştirilir; aynı dakika iki odada hareket varsa toplamda bir kez sayılır.

İlk üç veya dört hafta, kişinin kendi referansını oluşturmak için kullanılabilir. Hafta içi ve hafta sonu ayrı değerlendirilmelidir. Karşılaştırma başka insanların ortalamasıyla değil, aynı kişinin benzer zaman dilimlerindeki geçmişiyle yapılır.

Normalden uzaklığı ölçmek

Başlangıç için karmaşık bir sinir ağı şart değildir. Medyan, sıra dışı günlerden ortalamaya göre daha az etkilenir. Yayılımı ölçen medyan mutlak sapma ise $MAD = \operatorname{medyan}(\vert x_i-m\vert )$ şeklinde hesaplanır; burada $m$, geçmiş değerlerin medyanıdır.

Azalan etkinlik için kullanılabilecek sağlamlaştırılmış skor:

Burada $x_t$, güncel penceredeki hareketli dakika sayısıdır. Paydadaki 1, bir dakikalık alt sınırdır; geçmiş değerler aynı olduğunda sıfıra bölmeyi önler. Büyük pozitif skor, beklenenden düşük etkinlik gösterir. Örneğin medyan 18, MAD 3 ve güncel değer 2 olduğunda skor yaklaşık 3,6 olur. Ancak 3 gibi bir eşik yalnızca başlangıç tercihidir; klinik olarak doğrulanmış bir sınır değildir.

Python ile aday sapmaları çıkaralım

Aşağıdaki kod, geçmiş özetlerden profil oluşturur ve güncel pencereleri karşılaştırır. dilim, gün içindeki otuz dakikalık zaman aralığını temsil eder. Güncel kayıtların geçmiş eğitim verisine katılmaması önemlidir.

import pandas as pd

anahtar = ['gun_tipi', 'dilim']
grup = gecmis.groupby(anahtar)['aktif_dakika']

profil = grup.agg(merkez='median', ornek='count')
profil['mad'] = grup.apply(
    lambda s: (s - s.median()).abs().median()
)
profil['olcek'] = (1.4826 * profil['mad']).clip(lower=1)

sonuc = guncel.merge(
    profil.reset_index(),
    on=anahtar,
    how='left',
    validate='many_to_one'
)
sonuc['puan'] = (
    sonuc['merkez'] - sonuc['aktif_dakika']
) / sonuc['olcek']

sonuc['aday'] = (
    (sonuc['puan'] > 3)
    & (sonuc['ornek'] >= 6)
    & sonuc['sensorler_cevrimici']
    & sonuc['evde_olmasi_bekleniyor']
)

gecmis ve guncel, önceden hazırlanmış DataFrame tablolarıdır. Çıktı acil durum kararı değil, inceleme adayıdır. Evde bulunma beklentisi, yalnızca hareket yokluğundan çıkarılmamalı; kişinin belirttiği program gibi izinli bağlamlarla desteklenmelidir.

Alarm değil, kontrollü iletişim

Tek pencere yerine ardışık pencerelerdeki sapmalar değerlendirilebilir. Ancak beklemek acil durumları geciktirebileceğinden, bu sistem tıbbi alarmın yerine geçmez. Bildirim politikası kişiyle birlikte belirlenmeli; önce nazik bir kontrol mesajı, gerekiyorsa yetkilendirilmiş yakına bildirim düşünülmelidir.

Başarıyı yalnızca doğrulukla ölçmeyin. Haftalık yanlış bildirim sayısı, tespit gecikmesi ve gözden kaçan olaylar da izlenmelidir. Tatiller veya kalıcı rutin değişiklikleri sonrasında profil kontrollü biçimde güncellenmelidir.

Son olarak, açık rıza, bildirimleri durdurabilme, sınırlı saklama süresi ve erişim kontrolü tasarımın temelidir. Mümkünse ham verileri evde tutup yalnızca gerekli özetleri paylaşın. İyi sistem, her sessizliği felaket sayan değil; belirsizliğini kabul edip insan iletişimini destekleyen sistemdir.

``

HIL tam olarak neyi test eder?

HIL düzeninde uçuş bilgisayarı ve üzerinde çalışan yazılım gerçektir; aracın hareketi, çevresi ve bazı fiziksel bileşenleri ise modellerle temsil edilir. Simülatör, bilgisayara sensörlerden geliyormuş gibi veriler gönderir. Bilgisayarın ürettiği çıkışlar da modele geri aktarılır. Böylece tek yönlü veri oynatımından farklı olarak kapalı bir geri besleme döngüsü oluşur.

SIL, Software-in-the-Loop anlamına gelir. Burada hedef donanım yerine bilgisayar ortamı kullanılır. HIL ise işlemci yükü, iletişim gecikmesi ve sürücü davranışı gibi “masada çalışıyordu!” sürprizlerini görünür kılar. İkisi rakip değil, birbirini tamamlayan test katmanlarıdır.

Teorik temel: Model ve zaman aynı sahnede

Bir simülasyon modeli genel biçimde $x_{k+1}=f(x_k,u_k,w_k)$ ile gösterilebilir. Burada $x_k$ sistemin durumunu, $u_k$ bilgisayardan gelen çıkışları, $w_k$ ise çevresel etkileri veya bozucuları temsil eder. Sensör modeli de bu durumdan ölçüm üretir; ölçümlere gecikme, gürültü ve çözünürlük sınırları eklenebilir.

HIL için doğru değer üretmek kadar doğru zamanda üretmek de önemlidir. Sabit adımlı bir döngüde kabaca şu bütçe korunmalıdır:

Yani model hesaplama, haberleşme ve giriş-çıkış işlemleri ayrılan zaman adımına sığmalıdır. Ancak ortalama süre yeterli değildir: En kötü gecikme ve zamanlama değişkenliği de izlenmelidir. Simülasyon sürekli yetişemiyorsa test, gerçek donanım davranışı hakkında yanıltıcı sonuçlar verebilir.

Sanal araç, gerçek bağlantılar

Tipik düzenek; gerçek uçuş bilgisayarı, gerçek zamanlı simülatör, arayüz donanımı ve kayıt sisteminden oluşur. Arayüz katmanı dijital mesajları veya analog sinyalleri hedef bilgisayarın beklediği biçime dönüştürür. Paket içeriği kadar elektriksel seviyeler ve zaman damgaları da önemlidir.

Tehlikeli eyleyiciler yerine izole edilmiş yükler veya güvenli benzetimler kullanılmalıdır. Amaç motor çalıştırmak değil, bilgisayarın kararlarını gözlemlemektir. Hangi bileşenlerin gerçek, hangilerinin benzetim olduğu test raporunda açıkça belirtilmelidir.

Hataları davet edin, sonuçları ölçün

Başarılı senaryonun yanında arızalı senaryolar da gerekir. Her arıza için beklenen davranış önceden tanımlanmalıdır; aksi hâlde renkli grafikler yalnızca pahalı bir ekran koruyucuya dönüşür.

Kabul ölçütleri; tepki süresi, kayıp paket sayısı ve gereksinimle eşleştirilmiş durum geçişleri olabilir. Test girdileri, yazılım sürümü ve model parametreleri kaydedilirse aynı hata yeniden üretilebilir. Rastgele senaryolarda kullanılan tohum değeri de saklanmalıdır.

Python ile kavramsal bir test akışı

Aşağıdaki örnekte bench gerçek karta bağlanan test arayüzünü, plant ise fiziksel sistem modelini temsil eder. Bunlar hazır kütüphaneler değildir; kullanılan düzeneğe göre uygulanması gereken soyut arayüzlerdir. Örnek, kısa süreli sıcaklık verisi geçersizliği enjekte eder.

from time import monotonic, sleep


def run_case(bench, plant, steps=200, dt=0.01):
    deadline = monotonic()
    trace = []

    for k in range(steps):
        t = k * dt
        sensors = dict(plant.sample())
        if 0.5 <= t < 0.6:
            sensors["temperature_valid"] = False

        bench.send_sensors(sensors, timestamp=t)
        outputs = bench.read_outputs(timeout=dt / 2)
        plant.step(outputs, dt)
        trace.append((t, outputs))

        deadline += dt
        remaining = deadline - monotonic()
        if remaining <= 0:
            raise RuntimeError("Zaman bütçesi aşıldı")
        sleep(remaining)

    return trace

Döngü, sensör verisini gönderir, kartın çıkışını toplar ve modeli ilerletir. Birikimli son tarih kullanılması zaman kaymasını azaltır. Bununla birlikte standart Python ve sleep, kesin gerçek zaman garantisi vermez; örnek üretim düzeneği değil, akışı açıklayan bir iskelettir. Gerçek testte kayıtların ayrıca otomatik doğrulayıcılardan geçirilmesi gerekir.

HIL güçlüdür, ama sihir değildir

Model yanlışsa test kusursuz görünse bile sonuç yanlış olabilir. Bu nedenle modeller deneysel verilerle doğrulanmalı, belirsizlikler belgelenmeli ve farklı koşullar taranmalıdır. HIL; titreşim, elektromanyetik uyumluluk veya gerçek fiziksel sistem testlerinin yerine geçmez. En büyük kazancı, pahalı denemelerden önce hataları tekrarlanabilir biçimde yakalamaktır: Roketi değil, önce varsayımlarımızı havaya uçururuz.