IoT telemetri - Ödev Yaptırma & Danışmanlık Merkezi

Elektrik Elektronik Mühendisliği Ödev Yaptırma: Uzaktan İzleme Sistemlerinde MQTT Protokolü

İçerik Üreticisi — Tue, 23 Sep 2025 07:00:14 +0000

Uzaktan izleme sistemleri; sensörler, aktüatörler, geçit (gateway), ağ altyapısı, bulut/edge servisleri ve operatör panellerinden oluşan uçtan uca bir mimarinin toplam performansına dayanır. Nesnelerin İnterneti (IoT) bu mimariyi yaygınlaştırırken, bant genişliği sınırlı bağlantılar, enerji kısıtları, yüksek cihaz sayıları ve güvenlik gereksinimleri yeni protokol ihtiyaçlarını doğurdu. Burada sahneye çıkan MQTT (Message Queuing Telemetry Transport); hafif, yayınla/abone ol (pub/sub) modelinde, durum/tutarlılık bilinci olan ve TCP/TLS üzerinde çalışan bir mesajlaşma protokolüdür.

1) MQTT’ye Genel Bakış: Neden MQTT?

Hafiflik: Başlık (header) yükü küçüktür; düşük bant genişliğinde çalışır.
Pub/Sub modeli: Üretici (publisher) ve tüketici (subscriber) gevşek bağlanır; sistem ölçeklenebilir olur.
Durum bilinci: Will mesajı, keep-alive, session present gibi özelliklerle “cihaz hayatta mı?” sorusuna yanıt verir.
QoS seviyeleri: 0 (at most once), 1 (at least once), 2 (exactly once) ile mesaj iletim garantisi/tekrar–gecikme dengesi kurulur.
Taşıma: TCP (çoğunlukla 1883/8883); WebSocket üstünden tarayıcı istemciler; TLS ile şifreli kanal.
Ne zaman tercih? Zayıf/metro alanı bağlantıları, binlerce–milyonlarca sensör, olay güdümlü telemetri, izleme–alarm sistemleri.

2) MQTT 3.1.1 ve 5.0: Saha İçin Farklar

Hata raporlama: 5.0’da nedensellik kodları (reason codes) ve özellikler (properties) ile daha zengin geri bildirim.
Paylaşımlı abonelik (shared subscription): Yük dengeleme (ör. \$share/group/topic/#).
User properties, session expiry, message expiry: Zamanlı davranış ve meta veri taşımak kolay.
Akış kontrolü (flow control) ve server-assigned client id: Geçici istemciler için faydalı.
Ödev tüyosu: Yeni geliştirmelerde MQTT 5.0 seçin; broker/istemci uyumluluğunu test edin. Eski cihazlarla 3.1.1 köprü (bridge) kurabilirsiniz.

3) QoS Seçimi ve İletim Stratejileri

QoS 0: “Fire and forget.” Sensör sıklığı çok yüksekse ve “tek kayıp tolere ediliyorsa” uygundur.
QoS 1: “En az bir kez.” Çoğu telemetri için altın orta; olası çiftleme için idempotent tüketici yazın.
QoS 2: “Tam bir kez.” Ağ ağırdır; genelde ödeme/emir sistemleri gibi kritik komutlarda.
Pratik kural: Telemetri → QoS 1, alarm/komut → QoS 1/2, yüksek frekanslı ham veri → QoS 0 + toplu/özetleme.

4) Oturum Yönetimi: Clean Session, Persistent Session, Keep-Alive

Clean Start/Session Expiry (MQTT 5.0): Oturum süresini belirleyerek çevrimdışı kuyruğu kontrol edin.
Keep-Alive: Cihazın uyku modlarıyla uyumlu seçilmeli (örn. 60–300 s).
Session Present: Uyanınca “kaldığı yerden” devam edebilme.
Enerji ipucu: Uykulu cihazlar için session expiry uygun, will ve retained ile sistem “sağlık” görünürlüğünü kaybetmez.

5) Last Will & Testament (LWT) ve Retained Mesajlar

LWT: Cihaz beklenmedik düşerde, broker önceden tanımlanmış “vedayı” yayınlar (örn. status/offline).
Retained: Son bilinen durum; yeni abone gelen son değeri hemen görür (örn. sensor/+/last).
Dikkat: Büyük retained mesajları bellek tüketir; TTL/message expiry (MQTT 5.0) ile sınırlayın.

6) Topic Tasarımı: Ad Alanı, Hiyerarşi ve Vahşi Kartlar

Kural: Sabit, makinece ayrıştırılabilir, kimlik taşımayan ve yetkiyle hizalı.
Örnek şema:
- Telemetri: site/{siteId}/device/{devId}/telemetry/{metric}
- Durum: site/{siteId}/device/{devId}/status
- Komut: site/{siteId}/device/{devId}/cmd/{action}
- Konfig: site/{siteId}/device/{devId}/cfg/{param}
Vahşi kart: + tek seviye, # çok seviye.
Güvenlik: ACL kurgusunu topic şemasıyla uyumlu yapın: cihaz sadece kendi alt ağacına yazabilsin/okuyabilsin.

7) Broker Mimarisi: Tekil, Kümelenmiş ve Bridge

Tekil broker: POC ve küçük saha; bakım kolay ama tek hata noktası.
Küme/HA: Yatay ölçek; shared subscription ve durum replikasyonu.
Bridge: Saha-edge broker’ı ile bulut broker arasında topic köprüleme; bağlantı kopsa bile edge çalışır.
Örnek: Fabrika içinde edge broker (LAN) + bulut broker. site/1/# edge’de tutulur, periyodik özetler buluta aktarılır.

8) Edge–Bulut Bölüşümü: Akış Diyeti ve Özetsel Telemetri

Edge analitik: Gürültü filtreleme, delta-encoding, downsampling; alarm/olay üretimi.
Bulut: Uzun dönem saklama, model eğitimi, filo görünürlüğü.
Fayda: Bant tasarrufu, gecikme azalır, kopukluk toleransı artar.
Uygulama: 1 dakikalık ortalamalar + istatistikler (min/max/p95) buluta; ham 1 s veriler sadece anomali sırasında gönderilir.

9) Güvenlik: TLS 1.3, mTLS, ACL, RBAC ve OTA

TLS 1.3: AES_128_GCM veya CHACHA20_POLY1305.
mTLS: İstemci sertifikası ile cihaz kimliği; broker’da CN/SAN → topic eşleme.
ACL/RBAC: Kullanıcı/cihaz rollerine göre publish/subscribe izinleri.
OTA: MQTT ile ikili parçalar taşınabilir; ama imzalı paket ve checksum şart.
İpucu: 0-RTT’yi (erken veri) MQTT’de kapalı tutun; yeniden oynatma riskine değmez.

10) Bağlantı Güvenilirliği: Keep-Alive, Reconnect, Backoff ve Store-and-Forward

Backoff: Üstel artışla yeniden bağlanma; senkron fırtınayı önler.
Store-and-forward: Uykulu/çevrimdışı cihazlarda kalıcı kuyruk; “message expiry” kullanın.
NAT/Firewall: Port 8883 yerine 443/TLS + ALPN mqtt ile uyumluluk artar.
Vaka: Mobil hücresel ağda ALPN ile 443 üstünden MQTT; bağlantı kabul oranı %20 arttı.

11) Performans ve Ölçek: Paket Boyu, Sıklık, QoS–Enerji Dengesi

Paket boyu: Küçük ve sabit alanlar; JSON yerine CBOR/MessagePack ile %40–60 tasarruf.
Sıklık: “Per 10 s” telemetri yerine olay güdümlü; deadband ve histerezis.
QoS–Enerji: QoS 1, resend nedeniyle enerji tüketimini artırır; session resumption ve TCP keep-alive ayarları ile denge.
Ölçütler: Bağlanma süresi, ilk publish gecikmesi, p95 uçtan uca latency, kayıp/tekrar oranı.

12) MQTT ve Endüstriyel Ekosistem: Sparkplug B, OPC UA, SCADA

Sparkplug B: MQTT üzerinde endüstriyel payload standardı; State of the Node/Device, birth/death mesajları; tag yapısı.
OPC UA köprüsü: OPC UA <→ MQTT dönüşüm (gateway); saha PLC/SCADA verisi MQTT’ye açılır.
SCADA entegrasyonu: Historian’a kural tabanlı topic–tag eşlemesi; alarm/olay mapping.
Ödev tüyosu: Fabrika ödevlerinde Sparkplug B’yi örnekleyin; “birth certificate” ile cihaz keşfi gösterin.

13) Komut ve İkiz (Digital Twin): Request–Response, RPC ve Gölge

Command/Control: .../cmd/... topic’leri ve ack/correlation id; MQTT 5.0 response topic özelliği.
Device Shadow (Twin): İstenilen durum (desired) – raporlanan (reported) eşlemesi; offline uyumlama.
Pratik: Konfig değişikliklerini versiyonlayın; cihaz son işlenen sürümü raporlasın.

14) Ağ Koşulları: Hücresel/LPWAN/ Uydu ve Proxy’ler

Hücresel (NB-IoT/LTE-M): Yüksek gecikme/jitter → QoS 1 + düşük keep-alive; RTO’ları büyütün.
Uydu: Yüksek RTT → büyük batch ve ack pencerelerini ayarlayın.
Proxy/CDN: Bölgesel broker uçları (edge POP); bridge ile küresel yayılım.
Vaka: Sondaj sahasında uydu bağlantısında MQTT batch; alarm pencereleri 250 ms yerine 2–3 s olarak tasarlandı—saha kabulü sağlandı.

15) Test, Doğrulama ve Gözlemlenebilirlik

Load test: 50k istemci simülasyonu, artan abone sayısı; broker CPU/RAM/FD sınırları.
Chaos test: Broker düşürme, ağ kesme, sertifika iptali; otonom yeniden bağlanma.
Gözlemlenebilirlik: Broker metrikleri (publish rate, inflight, queued), per-topic gecikme histogramları, istemci sağlık panosu.
Kayıt: Her publish’e timestamp; uçtan uca gecikmeyi ölçmek için “pub-sub echo” testi.

16) Güvenlik Vaka Çalışması — mTLS ile Sahte Cihazların Önlenmesi

Sorun: Kullanıcı adı/şifre ile kimlik doğrulanan saha; kimlik sızıntısı sonrası sahte yayınlar.
Çözüm: mTLS’e geçiş; cihaz sertifikası üretim hattında SE (Secure Element) içinde; broker’da CN→topic ACL.
Sonuç: Sahte publish engellendi; broker log’larında başarısız el sıkışmalar erken uyarı olarak kullanıldı.

17) Performans Vaka Çalışması — Edge Özeti ile Bant Kazancı

Sorun: 10 bin sensör, 10 s’de bir 1 kB JSON → 8 Mbps; hücresel maliyet ve sunucu yükü arttı.
Çözüm: Edge’de delta+RLE ve CBOR; 60 s’de bir pencere özeti (mean, min, max, p95) + olay anında ham veri. QoS 1.
Sonuç: Trafik %70 azaldı; alarm duyarlılığı korunarak p95 gecikme %40 düştü.

18) Güvenilirlik Vaka Çalışması — Bridge ve Yerel Devamlılık

Sorun: Dağ sahasında bulut erişimi kesiliyor; operatör paneli kör.
Çözüm: Edge broker ve yerel panel; bulut ile bridge. Kesinti sırasında edge çalışır, bulut gelince queue flush.
Sonuç: Operasyon kesintisiz; bulut bağımlılığı azalınca saha verimliliği arttı.

19) Örnek Topic/ACL Tasarım Kalıbı

Topic:
- org/{orgId}/site/{siteId}/dev/{devId}/tele/{metric}
- org/{orgId}/site/{siteId}/dev/{devId}/stat
- org/{orgId}/site/{siteId}/dev/{devId}/cmd/{action}
ACL (örnek):
- Cihaz {devId} → publish yalnız kendi tele/# ve stat’e.
- Operatör → subscribe org/{orgId}/site/{siteId}/#.
- Kontrol servisi → publish .../cmd/# kısıtlı aksiyonlarla.
  Not: Least privilege; işletme hatalarını sınırlamak için topic prefix koruması.

20) MQTT ile OTA: Parça Parça ve Güvenli Güncelleme

Parçalama: 64–256 kB chunk’lar; checksum doğrulaması; retry penceresi.
İmza: Firmware Ed25519 ile imzalı; cihaz imzayı doğrulamadan yüklemesin.
Akış kontrolü: QoS 1; cihaz throttle bildirir.
Risk yönetimi: A/B bölümü ve otomatik rollback; gradyan yayılım (canary).

21) MQTT–HTTP–AMQP Karşılaştırması (Kısa)

HTTP/REST: Talep–yanıt; telemetri için verimsiz olabilir; komut/konfig API’ları için iyi.
AMQP: Zengin yönlendirme/kuyruk; daha ağır başlıklar; kurumsal entegrasyon.
MQTT: Hafif telemetri, durum bilinci; edge-friendly.
Öneri: Telemetri/alarm MQTT; yönetim/rapor HTTP; kurumsal köprü AMQP/Kafka.

22) MQTT Broker Seçimi: Kriterler

Özellik: MQTT 5.0, paylaşımlı abonelik, bridge, WebSocket, ALPN, mTLS, OCSP stapling.
Performans: Bağlantı/mesaj/saniye kapasitesi; gecikme.
Operasyon: HA/cluster, yedekleme, gözlemlenebilirlik, policy engine.
Uyum: Sparkplug B, entegrasyon SDK’ları.
Ödev tüyosu: 3–5 broker kıyas tablosu; yük testi grafikleri ile rapora koyun.

23) Ölçüm ve KPI’lar: Sınır Değerler ve Hedefler

Bağlanma süresi (p50/p95), ilk publish gecikmesi, inflight boyutları.
İstikrar: Bağlantı düşme oranı (< %0.1/saat), yeniden bağlanma başarı oranı.
Kaynak: Broker CPU < %70, RAM < %75; ağ port/FD kullanımı.
Güvenlik: Sertifika yenileme otomasyonu; başarısız TLS handshake olay takibi.

24) Sık Hatalar ve Kaçınma Taktikleri

Topic kaosu: Rastgele adlar → yetki ve filtreleme imkânsız. → Önce şema, sonra kod.
QoS 2 aşırı kullanımı: Gecikme ve yük patlar. → QoS 1 yeterlidir.
Retained spam: Büyük retained → bellek şişer. → TTL/expiry kullanın.
Sertifikasız bağlantı: Üretimde asla. → TLS 1.3 + mTLS.
Senkron reconnect fırtınası: Dakikada on binlerce connect. → Üstel backoff + jitter.

25) Ödev Raporu Şablonu (Puan Kazandıran)

Mimari diyagram: Cihaz–edge broker–bulut broker–panel.
Topic şeması ve ACL: CN/SAN eşlemesi, en az ayrı 4 kategori (tele/stat/cmd/cfg).
QoS ve oturum politikası: Keep-alive, session expiry, message expiry.
Güvenlik: TLS 1.3, mTLS, sertifika yaşam döngüsü; OCSP/CRL.
Performans planı: Paket boyu, sıklık, CBOR; deadband/histerezis.
Edge analitik: Delta/RLE, pencereli özet, olay kuralı.
Bridge/HA: Kesintide devam; flush stratejisi.
Komut modeli: Response topic, ack/timeout, idempotency.
Gözlemlenebilirlik: Metrikler, log şeması, alarm kuralı.
Test planı: Load/chaos; hücresel/uydu senaryoları.
OTA tasarımı: İmzalı paket, A/B, canary.
Sonuç ve yol haritası: Ölçek büyütme, Sparkplug B, OPC UA köprü.

26) 10 Günlük Uygulanabilir Plan (Prototip–Saha Odaklı)

Gün 1: Kullanım senaryosu ve KPI’lar; topic/ACL şeması taslağı.
Gün 2: Broker kurulumu (HA/cluster); TLS 1.3/mTLS yapılandırma.
Gün 3: İstemci SDK seçimi (C/RTOS, Python/Node, mobile); “hello telemetri”.
Gün 4: QoS, keep-alive, session expiry ayarı; reconnect/backoff.
Gün 5: Edge analitik (delta, CBOR); bant kazancı ölçümü.
Gün 6: Komut & response topic; idempotent işleyici; shadow/twin.
Gün 7: Bridge (edge↔bulut); kesinti testi; flush ve veri bütünlüğü.
Gün 8: Gözlemlenebilirlik panelleri; p95 gecikme ve kayıp oranı.
Gün 9: OTA akışı; imza doğrulama; kademeli yayılım.
Gün 10: Load/chaos testleri; rapor, riskler ve yol haritası.

27) Hızlı Kontrol Listesi (Cheat-Sheet)

Topic/ACL şeması kararlaştırıldı ve belgelendi.
TLS 1.3 + mTLS etkin; sertifika yenileme otomatik.
QoS 1 varsayılan; QoS 0/2 kullanım kriterleri yazılı.
Keep-alive, session/message expiry ayarlı; uykulu cihazlar test edildi.
Edge analitik ve CBOR/MessagePack etkin; bant ölçümleri yapıldı.
Bridge yapılandırıldı; kesinti/kuyruk/flush senaryosu geçti.
Komut–yanıt modeli ve twin/shadow tanımlı; idempotent işleyici var.
Gözlemlenebilirlik panoları (latency, inflight, queue) hazır.
OTA imzalı; A/B ve rollback; canary planı var.
Load/chaos testleri raporlandı; broker kaynak limitleri içinde.

Sonuç

Uzaktan izleme sistemlerinde MQTT, ölçeklenebilirlik, hafiflik ve durum farkındalığı sayesinde hataya dayanımlı, enerji ve bant etkin çözümler sunar. Başarılı bir MQTT tasarımı yalnız protokolü “açmak” değil; topic/ACL şeması, QoS/oturum politikaları, edge–bulut bölüşümü, TLS/mTLS ve sertifika yaşam döngüsü, komut–yanıt ve ikiz modeli, bridge/HA, gözlemlenebilirlik ve OTA ile uçtan uca bir mimari inşa etmektir.

Bu yazıda; MQTT 5.0’ın akış kontrolü ve paylaşımlı abonelik gibi modern özelliklerinin yüksek cihaz sayılı filolarda nasıl fark yarattığını, edge özetleme ile bant/enerji kazanımlarının nasıl sağlanacağını, mTLS ve topic-tabanlı yetkisayesinde kimlik–yetki zincirinin nasıl kurulacağını gösterdik. Vaka çalışmalarında performans, güvenilirlik ve güvenlik açısından ölçülebilir kazanımları örnekledik.

Ödev/bitirme raporunuzda; KPI’lar, yük/kaos testleri, p95 gecikme/kayıp grafikleri, broker kaynak kullanımı, sertifika yenileme günlükleri, bridge kesinti senaryosu ve OTA ispatlarıyla kanıt üretin. Unutmayın: Bir MQTT çözümünün değeri, kopukluk anlarında ve yükselen yük koşullarında ortaya çıkar. Mimariniz bu anlara hazırsa, izleme sisteminiz yalnızca veri gönderen bir ağ değil, operasyonun sinir sistemi olacaktır.

Öğrencilerin akademik başarılarını desteklemek ve yoğun tempoda geçen okul yaşamlarında yardımcı olmak amacıyla kurulan “Ödev Yaptırma” platformu, özgün ve kaliteli ödev çözümleri sunmaktadır. Öğrencilerin farklı branşlardan ödevlerini, projelerini ve makalelerini profesyonel ve deneyimli ekip üyelerimiz aracılığıyla titizlikle hazırlıyoruz. Her bir ödevi, konunun gerektirdiği derinlemesine araştırmalar ve analizler doğrultusunda çözümleyerek, öğrencilerimizin özgün düşünce yapısını ön plana çıkarmasını sağlıyoruz.

“Ödev Yaptırma” olarak, müşteri memnuniyetini ve güvenilirliği en üst düzeyde tutmaktayız. Öğrencilerin bize teslim ettikleri ödevlerin tümü, gizlilik ve güvenlik ilkelerine sıkı sıkıya bağlı kalınarak işlenir. Her ödev, öğrencinin taleplerine ve öğretmenin yönergelerine uygun olarak özelleştirilir ve her zaman orijinal içerik üretmeye özen gösteririz. Öğrencilerin akademik itibarını korumak ve güvenilir bir öğrenme deneyimi sunmak için elinizdeyiz.

“Ödev Yaptırma” platformu, kullanıcı dostu arayüzü sayesinde öğrencilere kolayca ulaşılabilir bir hizmet sunmaktadır. Kullanıcılar, web sitemiz üzerinden basit adımlarla ödevlerini yaptırma taleplerini iletebilir ve ihtiyaç duydukları konuda uzmanlaşmış ekip üyelerimizle iletişime geçebilirler. Hızlı yanıt verme ve esneklik, öğrencilerin zaman baskısı altında olan durumlarında da yanlarında olduğumuzu hissettirir. “Ödev Yaptırma” olarak, öğrencilerin başarısını desteklemek ve onlara daha fazla öğrenme fırsatı sunmak için buradayız

The post Elektrik Elektronik Mühendisliği Ödev Yaptırma: Uzaktan İzleme Sistemlerinde MQTT Protokolü first appeared on Ödev Yaptırma & Danışmanlık Merkezi.

Elektrik Elektronik Mühendisliği Ödev Yaptırma: Arduino vs. Raspberry Pi — Hangi Proje İçin Hangisi?

İçerik Üreticisi — Sun, 07 Sep 2025 09:00:39 +0000

Elektrik–Elektronik Mühendisliği öğrencileri için Arduino ve Raspberry Pi, laboratuvar ile sahayı buluşturan iki temel yapı taşıdır. Birincisi mikrodenetleyici odaklı, gerçek zamanlı kontrol ve düşük güçte deterministik görevler için biçilmiş kaftanken; ikincisi Linux tabanlı bir tek kart bilgisayar (SBC) olarak yüksek seviye yazılım, ağ ve çoklu proses içeren zengin kullanıcı alanı işlerine hükmeder. Ödev/bitirme projelerinde seçim çoğu kez “hangisi daha güçlü?” sorusuna indirgenir; oysa asıl mesele görev doğası, zamanlama gereksinimi, çevresel kısıtlar (güç, ısı, güvenilirlik), maliyet, genişletilebilirlik ve bakım dengesidir.

1) Mimari Paradigmalar: MCU vs. SBC

Arduino (MCU sınıfı): Tek göreve odaklı, çıplak metal ya da hafif RTOS ile çalışan mikrodenetleyici. Giriş/çıkış pinleri doğrudan donanıma bağlanır; milisaniye–mikrosaniye mertebesinde deterministik zamanlama sağlar.
Raspberry Pi (SBC sınıfı): Çok çekirdekli CPU, GPU, RAM, dosya sistemi, Linux kernel ve kullanıcı alanı. Aynı anda ağ, dosya, grafik ve çoklu süreç yönetimi mümkündür; ancak genel amaçlı OS deterministik gerçek zamanlılık sunmaz (RT-preempt yamaları hariç).
Kural: “Zaman kritik kontrol” Arduino; “yoğun yazılım/çoklu servis” Pi.

2) Zamanlama ve Gerçek Zamanlılık: Jitter, ISR ve Kernel

Arduino’da interrupt gecikmeleri düşük ve tutarlıdır; PWM, sayıcı–zamanlayıcı, SPI/I²C çevre birimleri donanımsal olarak zamanlanır. Raspberry Pi’de kullanıcı alanındaki uygulamalar scheduler’a tabidir; kernel tarafında GPIO erişimi ve zamanlama jitter üretir. RT-preempt ve isolcpus gibi taktikler jitter’ı düşürse de “mikrosaniye hassas” servo/stepper zamanlamasında MCU hâlâ üstündür.
Mini vaka: 6 eksenli stepper sürüşünde Pi + userspace zamanlama %1–2 adım sapması üretirken; Arduino Due’de sabit 100 kHz step dalgası sapmasız üretildi.

3) Güç Bütçesi ve Termal: Pil ile Yaşam

Arduino kartları mA düzeyi tüketim ve derin uyku modlarıyla yıllarca pille çalışabilir. Raspberry Pi (özellikle 3/4/5) tipik olarak W seviyesinde güç ister; termal kısıtlarda throttle/soğutma gerekebilir.
Ödev ipucu: Mobil/uzak sahada telemetri gereken projelerde “Arduino + düşük güçlü RF (LoRa/NRF24) + uykudan uyan–yayınla–uyu” deseni altın standarttır.

4) I/O Deterministikliği: GPIO, ADC/DAC, Zamanlayıcılar

Arduino: Dahili ADC, çoğu kartta donanımsal PWM, sayıcı–zamanlayıcılar ve kesme hatlarıyla deterministik I/O.
Raspberry Pi: GPIO hızlıdır ancak Linux gecikmesi vardır; dahili ADC yoktur (harici ADC gerekir). PWM ve PIO için kütüphaneler olsa da hard-real-time değildir.
Karar: Analog ölçüm ve kapalı çevrim kontrol “kartın doğasında” ise Arduino daha uygundur.

5) Haberleşme ve Ağ Yeteneği: MQTT, HTTP, RTSP

Pi, Ethernet/Wi-Fi/BT yığınlarını, TLS, Docker ve broker (MQTT/Redis) gibi servisleri kolayca çalıştırır. Arduino tarafında (özellikle UNO/Nano sınıfı) TCP/TLS ağır gelir; ESP32 gibi MCU’lar Wi-Fi’yi iyi taşır ama tam Linux konforu yoktur.
Örnek: Kampüste RFID/IoT ağ geçidi; Pi üzerinde MQTT broker + veri işleme, kapıdaki Arduino ise sahadan deterministic sinyal okur ve Pi’ye iletir.

6) Depolama, Dosya Sistemi ve Kalıcılık

Pi, SD/SSD üzerinde dosya sistemiyle günlük (log), veritabanı, medya depolamayı destekler. Ani güç kesintisinde FS bozulmasına karşı journaling, read-only root, UPS HAT gibi önlemler gerekir. Arduino’da kalıcı veri tipik olarak EEPROM/Flash kısıtlıdır; ama güç kesintisi riski düşüktür.
Uygulama: Uzun süreli sensör kayıt projesinde Pi + InfluxDB/Grafana; uç sensörler Arduino.

7) Geliştirme Deneyimi ve Ekosistem

Arduino IDE/PlatformIO: Öğrenci dostu, sürücüler/örnekler bol, “blink–sensor–actuator” hattı hızlı.
Raspberry Pi: Python, C/C++, Node.js; OpenCV, GStreamer, PyTorch-Lite gibi geniş ekosistem.
Ödev notu: “Hızlı prototip + eğitim” için Arduino; “çok katmanlı yazılım ve servis kompozisyonu” için Pi eğitici.

8) Shield vs. HAT: Donanım Ekosistemi

Arduino Shield ekosistemi (motor sürücü, röle, sensör, LoRa) GPIO ile uyumlu ve yığınlanabilir. Pi tarafında HAT’ler (ADC, motor sürücü, PoE, kamera arayüz genişletici) mevcut; fakat yüksek akım/EMI senaryolarında harici sürücüler (TB67xx, DRV8xxx) tercih edilir.
İpucu: Yüksek akım motor sürücülerini Pi’nin aynı PCB’sinde değil, ayrı kart ve ayrı besleme ile kullanın.

9) Görü, Ses ve Medya: Kamera, Codec, OpenCV

Pi, CSI/USB kameralarla gerçek zamanlı görüntü işleme ve video akışı için idealdir; H.264/H.265 donanımsal hızlandırma, GStreamer/FFmpeg ile entegrasyon, OpenCV performansı yüksek. Arduino’da görüntü işleme pratik değildir; sadece sensör tetikleme/ışıklandırma gibi periferik görevler yapılır.
Vaka: Akıllı trafik ışığı: Pi + kamera + YOLO-Lite aracın gelişini algılar; Arduino saha rölelerini deterministik sürer.

10) Makine Öğrenmesi ve Edge AI

Pi üzerinde Python ekosistemi ile scikit-learn, TensorFlow-Lite, PyTorch-Mobile çalışır; USB/NPU hızlandırıcı (Coral, NCS2) eklenebilir. Arduino sınıfında tinyML (TensorFlow-Lite Micro) mümkündür ancak model boyutu ve RAM kısıtlıdır.
Karar: ML çıkarımı (vision/NLP/ses uyandırma sözcükleri) Pi; ultra düşük güç, küçük modeller (anomalı sensör) Arduino/ESP32.

11) Güvenlik, OTA ve Bakım

Pi, SSH, Ansible, Docker, systemd servisleriyle uzaktan yönetim, OTA ve çok cihazlı filo bakımı için uygundur; fakat saldırı yüzeyi geniştir. Arduino’nun yüzeyi dardır; OTA (ESP32 hariç) sınırlı ama kapalı bir kutu gibi güvenlidir.
Uygulama: Kampüs IoT’de Pi gateway’leri düzenli olarak apt/dpkg günceller; Arduino düğümleri sabit firmware ile çalışır.

12) Güvenilirlik ve “Brick” Riski

Pi’de yanlış kernel/driver güncellemesi, SD bozulması çalışmama doğurabilir. Endüstride “read-only root + uygulama veri bölümü” ve health-check scriptleri önerilir. Arduino’da firmware stabil kaldıkça risk azdır.
Öneri: Kritik sahada çift imajlı boot (A/B), watchdog ve otomatik rollback.

13) Maliyet ve BOM

Düşük bütçeli, tek işlevli projelerde Arduino klası ekonomiktir. Kamera, ekran, veritabanı, ağ ve çoklu modül gerektiren projelerde Pi’nin “tek kartta çok iş” sağlaması toplam maliyeti düşürebilir.
Hesap: “Bir Pi + kamera + PoE HAT” vs “MCU + kamera arayüz + kayıt + ağ”: ikinci seçenek karmaşıklık ve yazılım maliyeti yüzünden daha pahalıya gelebilir.

14) EMI/EMC ve Endüstriyel Dayanıklılık

Arduino’lu tasarımlar basit güç topolojisi ve düşük saat hızları nedeniyle EMI’de avantajlıdır. Pi’de yüksek hızlı hatlar (CSI, HDMI, USB, DDR) uygun grounding/filtreleme gerektirir. Endüstriyel ortamda surge/ESD ve izolasyon (opto, DC-DC izole) şarttır.
İpucu: Pi’nin GPIO’sunu doğrudan saha rölelerine bağlamayın; transistör–optokuplör katmanı kullanın.

15) Karma (Heterojen) Mimari: MCU + SBC “En İyi İkisi”

Gerçek dünyada en sağlam çözüm sıklıkla ikisini birlikte kullanmaktır:

Arduino: Zaman kritik sensör okuma, PWM, motor sürüş, güvenlik röleleri.
Raspberry Pi: Görü/ML, ağ, UI, veri tabanı, bulut bağlantısı.
İletişim: UART/I²C/SPI veya USB CDC; mesajlaşma için CBOR/Protobuf; “komut–telemetri–log” şeması.
Vaka: Otopark bariyeri: Pi plakayı tanır, karar verir; Arduino bariyeri sürer, limit switch’leri anında işler.

16) Tipik Proje Kalıpları ve Karar Ağacı

Gerçek zamanlı motor–servo kontrolü, kapalı çevrim, analog ölçüm → Arduino
Kamera, ekran, ağ, SQL/TSDB, web UI → Raspberry Pi
Giyilebilir/uzun pil ömrü → Arduino/ESP32
Saha gateway, çok protokollü köprü → Raspberry Pi
Emniyet rölesi, acil durdurma → Arduino (hatta iki MCU ile yedekli)
HMI (dokunmatik), çoklu kullanıcı, medya → Raspberry Pi
Hepsi biraz → Hibrit mimari

17) Örnek Olay I — Akıllı Sera

İhtiyaç: Toprak nemi, sıcaklık, ışık kontrolü; kamera ile yaprak stresi ve uzaktan erişim.
Mimari: Arduino sensörleri okur, vanaları PWM/relay ile sürer; Pi kamera + Python/OpenCV + mqtt-broker; Pi kararları yayınlar, Arduino uygular.
Kazanım: Vanalarda ms düzeyinde kontrol + uzaktan raporlama ve görsel denetim.

18) Örnek Olay II — Endüstriyel Bant Sayaç ve Görsel Denetim

İhtiyaç: 1 kHz enkoder sayımı, 24 V sahadan giriş, hatalı ürün görüntü denetimi.
Mimari: Arduino (24 V giriş kondisy.) enkoderi deterministik sayar, tetik verir; Pi görüntüyü işler ve veritabanına yazar.
Not: Pi GPIO → opto izolasyon; EMI önlemleri.

19) Örnek Olay III — Kampüs Erişim Paneli + Yüz Tanıma

İhtiyaç: Turnike kontrolü deterministik olmalı; görsel doğrulama ve loglama gerekli.
Mimari: Pi + kamera yüz tanır; yetki kararını üretir. Arduino kapı rölesini sürer, acil durumda fail-safe açar.
Güvenlik: Pi ↔ Arduino arasında imzalı komut, watchdog ve kalp atışı (heartbeat) hattı.

20) Performans ve Gecikme Ölçümü

Ödev raporlarında, “neden bu kartı seçtim?” gerekçesine ölçüm ekleyin:

Arduino: ISR gecikmesi, PWM jitter, ADC örnekleme hatası.
Pi: Kamera–algoritma–karar–GPIO tetik süresi; sistem yükünde gecikme dağılımı (p95/p99).
Araçlar: perf, htop, vcgencmd, LAUTERBACH/J-Link, logic analyzer.

21) Yazılım Mimarisi: İyi Ayrım, Basit Sözleşme

Arduino tarafı: “Komut makinesi” (finite state machine), non-blocking döngü, watchdog, hata kodları.
Pi tarafı: Servisler (systemd), sağlık denetleyicisi, günlük rotasyonu, konfigürasyon yönetimi.
Sözleşme: Versiyonlu mesaj şeması; geriye uyum.

22) Güvenlik ve Emniyet: Hatalı Karardan Zarar Görmeyin

Yetki, sınır ve emniyet röleleri MCU’da olmalı; Pi yalnızca “öneri” üretmeli. Kritik eylemler (kapı aç, motor tam hız) iki-kanallı onay (ör. Pi komutu + yerel sensör koşulu) ile yürüsün.
Check-list: E-stop, brown-out, “güvenli varsayılan”, iletişim kopması senaryosu.

23) Maliyet–Fayda–Risk Matrisi

Karar sadece performans değil; parça bulunabilirliği, yaşam döngüsü, saha desteği ve bakım faktörlerine göre alınmalı. Pi sürüm değişimleri (ör. yeni SoC) göç maliyeti doğurabilir; Arduino varyantları arasında geçiş genelde daha sorunsuzdur.

24) Ödev Raporu Şablonu (Puan Kazandıran)

Gereksinimler (zamanlama, I/O, ağ, güç)
Karar tablosu (Arduino vs Pi vs Hibrit)
Mimari diyagram (veri ve güç yolları)
Zamanlama/güç ölçümleri
Güvenlik–emniyet tasarımı
BOM ve maliyet analizi
Test senaryoları (p95 gecikme, kopma, yeniden başlatma)
Saha riskleri ve iyileştirme planı
Sonuç ve genişletme önerileri

25) 10 Günlük Uygulanabilir Proje Planı

Gün 1: Gereksinim matrisi ve seçim (Arduino/Pi/Hibrit)
Gün 2: Donanım tedarik, breadboard iskelet
Gün 3: Arduino I/O döngüsü + ISR testleri
Gün 4: Pi tarafı servisler (MQTT/REST), kamera/IO test
Gün 5: Protokol/sözleşme (CBOR/JSON), hata kodları
Gün 6: Zamanlama ve güç ölçümleri; p95/p99 gecikme
Gün 7: Güvenlik: watchdog, brown-out, fail-safe
Gün 8: EMI/EMC kaba test, kablo düzeni, izolasyon
Gün 9: Entegre senaryo, stres testi, log analizi
Gün 10: Rapor, mimari çizim, ölçüm tabloları, video/demo

Sonuç

Arduino ve Raspberry Pi, rakip değil tamamlayıcı araçlardır. Arduino, deterministik zamanlama, düşük güç, basitlikve yüksek güvenilirlik isteyen görevlerde (motor/servo sürüş, analog ölçüm, acil durum röleleri, uzun pil ömrü) üstünlük sağlar. Raspberry Pi ise ağ, medya, görsel algı, veritabanı, UI ve edge AI gerektiren projelerde Linux ekosistemi ve donanımsal hızlandırma ile öne çıkar. Çoğu gerçek dünyası projesinde en iyi çözüm ikisini birlikte kullanmaktır: Arduino, sahada “milisaniyelerle konuşan” kontrolcü; Pi, “megabaytlarla ve paketlerle konuşan” beyin.

Ödev ve bitirme projelerinde başarı, seçimi ölçümler ve risk analizi ile gerekçelendirmektir: jitter ve ISR süreleri, p95/p99 gecikmeler, güç tüketimi, SD/FS dayanıklılığı, emniyet senaryoları, OTA/bakım planı. Bu makaledeki karar ağacı, mimari kalıplar ve örnek olaylar, “hangi proje için hangisi?” sorusunu mühendisçe yanıtlamanıza yardım edecek. Unutmayın: Doğru araç, doğru iş için. Ve çoğu zaman “doğru iş”, Arduino + Raspberry Pi birlikteliğidir.

The post Elektrik Elektronik Mühendisliği Ödev Yaptırma: Arduino vs. Raspberry Pi — Hangi Proje İçin Hangisi? first appeared on Ödev Yaptırma & Danışmanlık Merkezi.