Jun 2026
Present
Present
Experience
Kale Jet Engines
Engineering Intern
KvA Software Design Directorate · engine-control simulation & reliability testing
Demir Akın
Works
Selected
Profile / 02
Profile.
About.
I am an electrical and electronics engineering student at Koç University, based in Istanbul. My work spans control and embedded systems, from engine-control simulation and low-level firmware to industrial AI research.
- Discipline
- Electrical & electronics engineering
- Focus
- Control & embedded systems
- Based
- İstanbul · TR
Technical range.
Control & Embedded
Programming
Applied AI / Algorithms
Languages
- Turkish (native)
- English (B2)
Experience.
Apr 2023
Present
Present
Experience
ARDES
Social Media & Process Development
Digital content, management workflows and reporting · Çanakkale
Education.
2023
2027
2027
Education
Koç University
Electrical & Electronics Engineering
Undergraduate · Class of 2027
Full curriculum vitae
Experience · education · affiliations
Contact
Open to internship & project opportunities
Contact.
demirakin.tr@gmail.comEGEMEN
A self-verifying, triple-channel (TMR) FADEC simulation for a single-engine UCAV turbofan.
RoleFADEC · control law · 2oo3 redundancy · jet-engine control systems (embedded)
ScopeBrowser FADEC test bench for a single-engine UCAV turbofan.
ProofLive v36 simulation, 52 built-in self-test scenarios, and English and Turkish v35 technical reports.
BoundaryIllustrative plant model; not flight code or certification.
CO-DEVELOPED WITH EMRE KARAUSTA · plant physics · sensor data modeling · 2oo3 edge-case testing
01 — Overview
EGEMEN: From command to proof.
For readers already familiar with FADEC.
Engineering problem
A FADEC is the full-authority digital control system that manages an engine's fuel command. It has complete authority over fuel, so every decision in that path can change spool speed and temperature. An untrustworthy measurement is therefore more than a bad indication: if accepted as truth, it can become a bad command. A single drifting sensor or one diverging ECU channel must be identified before it can distort the control path.
EGEMEN makes that responsibility visible in a browser simulation for a single-engine UCAV turbofan. It is a working environment in which command ownership, engine response and protective action can be observed together. It is not flight code, a real-engine model or certification evidence; its purpose is to expose and test the relationships that a fault-tolerant control architecture must keep separate.
One chain of authority
The path begins outside the FADEC. The mission and environment model establishes flight state, atmosphere and engine target. AUTO FAB or External FAB supplies an automatic target, and autothrottle applies that target N2 at a finite rate. A MANUAL target bypasses autothrottle, but it does not bypass the FADEC; both paths meet at the active N2 demand. The FADEC then turns the limited demand into a fuel command through its min-max protection logic. The illustrative plant model produces the engine response, sensors return that result, and the interface displays the published state without making a control decision of its own.
Live cockpit evidenceNominal 3oo3 / running state
The running simulation places primary engine indications, distributed TMR authority and the 2oo3 voting matrix in the same observable system view.
When information cannot be trusted
Consider one critical measurement watched independently by three channels. Triple modular redundancy (TMR) keeps those lanes separate. If one sensor drifts away from the other two, 2oo3 median voting preserves the trusted value by selecting the middle channel result. FDIR is the layer that can detect the confirmed fault, isolate the affected channel and manage the system response while showing that redundancy has been lost.
Voting alone cannot reveal every failure. If all channels move together in the wrong direction, their agreement can hide a common-mode mismatch. OBM is the on-board model that compares the sensor result with an independent expectation of engine behavior and exposes that disagreement. A separate latched overspeed path outside the main control law provides the final protective boundary: once excessive speed trips it, fuel remains cut until reset. These layers do not trust the same information: voting compares channels, the model uses an engine expectation, and the separate overspeed path reads raw maximum N2 without waiting for the main control law's result. The scenario therefore links voting, fault isolation, analytical redundancy and protective shutdown without pretending that any one mechanism covers every case.
Three sources, one active authority
MANUAL, AUTO FAB and External FAB are distinct command owners, and only one may be active at a time. MANUAL belongs directly to pilot demand and stays outside autothrottle. AUTO FAB belongs to the internal mission supervisor; External FAB is an independently seeded source that publishes its own validated mission frames. Both automatic paths remain subject to health and fuel engagement gates, and moving the pilot lever drops the active automatic source rather than blending authorities.
This separation keeps three decisions legible. The mission source decides what the vehicle needs, autothrottle controls how quickly an automatic demand is applied, and the FADEC decides how the engine may meet that demand within its limits. Changing the source never gives the interface control authority and never removes the FADEC from the path.
How behavior is proven
EGEMEN's proof chain begins with a deterministic 50 ms fixed step: control, plant response and fault handling advance on the same explicit clock. The bench then applies 52 built-in self-test scenarios to the resulting behavior. With the same seed and inputs, the run produces a bit-identical replay, which allows a response to be compared instead of judged by appearance.
The live simulation exposes the command, fuel path, engine response and protection state. Latched fault and maintenance records remain inspectable during the active session and can be carried into the downloadable .xlsx evidence export. The English and Turkish v35 reports document the architecture and its limits. The headless harness runs the same simulation core without relying on the visible interface. Together these surfaces make a self-verifying test bench rather than a display-only demo. Because the system is one HTML file with no build or external dependency, the simulation and its built-in scenarios can also run offline; the reports and records are evidence outputs, not executable evidence.
Honest boundary
The plant is illustrative and hand-tuned. It preserves different response rates so that control limits, voting and fault reactions can be exercised, but it is not derived from a manufacturer's engine cycle, aerodynamic model or validated flight data. EGEMEN therefore does not establish real-engine performance, hard-real-time behavior, airworthiness or certification.
What it does establish is narrower and inspectable: a system architecture with one explicit authority path; separation between mission choice, rate-limited application and engine control; observable fault management; deterministic replay; and a verification discipline tied to the behavior on screen. The full technical sections below retain the mechanisms and the detailed limits behind that claim.
TECHNICAL DEEP DIVE
Control architecture, subsystem mechanics and verification evidence follow in full.
02 — How it works
Architecture: one data contract
The simulation core advances the system and publishes one FADECState contract. The interface consumes that state; it does not make control decisions.
Pilot / FAB sources
Manual, AUTO · FAB or External FAB produces target N2. Outside the FADEC.
→
Simulation core · 20 Hz
realStep(dt) selects the source, runs control and advances the plant.
→
FADECState
writeFADECState() writes one contract. Single source of truth.
→
render()
The UI only displays the contract. Decoupled from control.
The responsibility chain is explicit. The mission and environment model chooses the flight state, atmosphere and engine target. Autothrottle applies the target N2 at a finite rate. The FADEC maps that limited target into a fuel command, and the plant produces the engine response.
The data contract keeps this chain testable and leaves the render layer outside control. The headless harness runs the same simulation core without relying on the visible interface.
Random streams remain isolated by subsystem. External FAB missions use their own seed; preparing a new mission advances it deterministically, while a recorded seed can still reproduce the same plan. PACER handles bounded background catch-up, and separate test interfaces cover raw control mathematics and user-facing paths.
03 — What's inside
Subsystems
Numbers are illustrative and hand-tuned ("TUNABLE") — not derived from a real engine. Each subsystem matters both for what it does and why it's built that way.
Plant model deterministic
The plant converts fuel flow Wf into N2, N1 and EGT response. First-order lags represent the fuel actuator and spool inertia: τ_FMV=0.25 s, τ_N2=1.3 s and τ_N1=3.5 s.
N1 follows N2 aerodynamically rather than through a mechanical shaft model, using N1 ≈ (N2−18)×1.15. EGT combines fast combustion response (τ=1.5 s) with slow metal soak (τ=60 s) in an 85/15 blend.
Why: the model is deliberately reduced, but it preserves the different response rates needed to exercise spool and EGT limits. The slight temperature drift at steady throttle is intentional.
WF_MAX 2600N2_IDLE 60N2_MAX 112WF_MIN 120 kg/h
Control law — min-max limit selector control
The control law converts target N2 into fuel command Wf. It starts with equilibrium fuel as feedforward, then adds a PI trim whose integrator pauses while the command is saturated.
Upper candidates constrain acceleration, N2 and EGT. Lower candidates enforce the deceleration floor and WF_MIN flameout-safety floor. The min-max selector applies the binding candidate and exposes the active physical limit in the interface.
Why: this is a multi-limit architecture, not one unconstrained PID. Tracking the winning limit makes every intervention visible while the lower floor prevents the selector from commanding below minimum fuel.
KP 22KI 9N2 limit 108→112EGT limit 900→950
Autothrottle control
Autothrottle applies an automatic source's target N2 without a command discontinuity. It slews upward at 7 %N2/s, downward at 4 %N2/s and uses a 12 %N2/s emergency rate in AUTO · FAB.
Engagement is bumpless because the demand starts from the current target. The mission supervisor may change its decision immediately; autothrottle controls how that demand reaches the FADEC.
Why: separating the supervisory decision from rate-limited application keeps command ownership clear and avoids an artificial step at the engine target.
AT_UP 7 %/sAT_DN 4 %/sAT_EMERG 12 %/s
Live capture / AUTO + FABPilot input + mission supervisor
The Pilot Console and FAB mission panel are two targeted views from the same running AUTO / FAB frame.
2oo3 voting and health FDIR
The voting layer rejects a disagreeing measurement while preserving the remaining authority. Each ECU channel, A, B or C, receives two sensor instances for every N2, EGT and N1 signal. An instance is one reading; the channel's resulting signal is the lane presented to the distributed voter.
The three channel lanes are compared by median. A lane outside its ε band is an outlier, while HARD and SOFT classifications distinguish invalid signals from plausible deviations. Voting runs across the CCDL with no central voter.
Isolation requires 3 consecutive confirmed cycles, so a seeded one-cycle F-BLIP can recover without a latch. A persistent fault remains out of the vote until maintenance reset. With only two channels left, a second-layer monitor reports disagreement but does not assign blame.
Why: distributing the voter removes a central single point of failure, while debounce separates transient noise from confirmed degradation.
ε(N2) 2.5ε(EGT) 18ε(N1) 2.5
Live capture / half-blindEGT-C isolated / redundancy 2oo3
The half-blind scenario exposes EGT-C isolation in the voting matrix and sensor-health board while the system continues at 2oo3.
OBM — analytical redundancy FDIR
The on-board model (OBM) provides an independent expectation for N2 and EGT. It compares that prediction with the voted measurements and raises a residual flag outside the N2 ±6 or EGT ±60 band.
If all three channels agree on the same wrong value, voting has no outlier to reject; the OBM can still identify the common-mode discrepancy. With one healthy channel remaining, it can synthesize N2 and EGT for reversionary control.
Common-mode flags reach the crew alert and black box only in RUN after the same 3-cycle confirmation. This prevents normal start transients from leaving false maintenance records.
Why: voting asks what the channels agree on; the OBM asks whether that agreement is physically plausible.
Reversionary control, leader arbitration and overspeed FDIR
Reversionary control preserves a fuel command when sensor authority is lost but an ECU's computation remains alive. That lane continues on OBM-synthesized N2, so CPU liveness and sensor health remain separate decisions.
Leader arbitration prefers a fully healthy channel, then any channel with a live CPU. A 0.3 s hold prevents chatter and handover is bumpless. Election also runs with the engine off, allowing ground faults and leadership changes to remain observable before fuel flows.
A separate latched overspeed path reads raw maximum N2, cuts fuel above 115% and remains tripped until reset. It does not depend on the main control law.
Why: measurement loss need not become control loss, and the final overspeed barrier must survive a failure of the control path it protects.
overspeed >115%SWITCH_HOLD 0.3 sladder 3oo3→2oo3→1·K11→SAFE
Start sequence FSM
The start state machine coordinates starter, ignition, fuel and transfer to closed-loop control. It progresses through OFF → CRANK → LIGHT-OFF → ACCEL → RUN, with ignition at N2 ≥ 18, starter cut at 50% and the control law taking over at idle.
HUNG and HOT paths abort a start that fails to accelerate or exceeds 720 °C EGT. Fault injections armed on the ground survive the start-time auto-reset, so the selected failure is still present on the next start.
Why: explicit states and abort paths make start behavior testable instead of reducing it to a single speed threshold.
Live capture / start sequenceHUNG START / START ABORT
HUNG START and the latched START ABORT state are visible in the running start-state view.
FAB supervisor — vehicle-level autonomy control
The mission/FAB layer sits outside the FADEC and chooses flight state, environment and target N2. Internal AUTO · FAB runs 10 fixed legs from TAXI to SHUTDOWN. External FAB is an independently seeded command source that publishes validated altitude, Mach and phase frames, then derives an N2 request.
The mission and environment model owns altitude progression and atmosphere updates. Internal AUTO · FAB advances leg altitude with a 350 m/s bound; External FAB feeds its mission frame through the same environment bridge. Autothrottle only rate-limits the resulting N2 demand.
The internal AUTO · FAB supervisor can override its script when engine health changes. Its priority is EMERGENCY > RTB > DERATE > SCRIPT; derate and RTB require 3-cycle confirmation, while EMERGENCY remains immediate. Both automatic sources apply engagement gates for insufficient redundancy or fuel.
MANUAL, AUTO · FAB and External FAB are mutually exclusive, and touching the lever drops either automatic source. Every automatic decision is recorded with its mission state and reason.
Why: command source, environment progression and engine control remain separate responsibilities, while current system health always outranks the mission script.
Fault word, black box and IETM observability
The observability layer preserves why the system changed state. Faults travel in a 16-bit word, [FIELD:3 | CODE:4 | CH:2 | VOTER:2 | COMP:5], using a 1553-aligned frame.
The PFR / black box latches and deduplicates those words, while the live decoder exposes every field. The IETM links a gauge to its definition and a state-dependent explanation.
Master Caution is acknowledgeable per cause, and a new cause relights it. The same producer feeds the cockpit, snap-cursor chart and downloadable .xlsx report, keeping displayed and exported evidence aligned.
The power-margin observer samples corrected N2 and normalized fuel against hand-tuned schedule proxies. It displays surge and LBO proxy margins plus life counters, but does not feed the control law. It is not a compressor map or a lifing model.
Why: fault, voter, maintenance and observer evidence stay inspectable without giving the display layer control authority.
Live capture / maintenancePFR / CMC black box
Latched channel-isolation fault words remain visible in the in-session PFR / CMC maintenance log.
04 — How it's proven
Test discipline
The claim isn't "it works when I click around." The bench carries its own evidence:
- Self-test52 built-in self-test scenarios cover voting, latching, mission authority, the environment bridge and the power-margin observer. Each scenario checks one or more expected end conditions; a discrimination check proves the suite can fail.
- Deterministic replaySubsystem random streams remain independent. The same seed and inputs replay bit-identically; a new External FAB mission advances its seed deterministically without removing manual reproduction.
- Equivalence proofsWhen a release must not alter protected behavior, manual and AUTO · FAB trajectories are compared between versions, including physics, events and the black box.
- Targeted probesThe mission supervisor was hardened against sensor noise with a 20-run seeded probe: false RTB latches went 2/20 → 0/20 with detection time unchanged.
- Fault agentAn autonomous agent drives each built-in fault scenario to PASS/FAIL in audit mode, and injects seeded MTBF faults during autonomous flight for realism — never in manual mode.
- ProcessThe v30-v35 releases are recorded in version reports and regression evidence. The current release passes 52/52 self-test scenarios and a 214/214 TR/EN i18n parity check.
Independent engineering domains, carried together in one working, checkable system:
Redundancy & FDIR
2oo3, HARD/SOFT split, debounced isolation latch, degrade ladder, analytical redundancy, common-mode awareness, separate latched overspeed path.
Control law
Min-max limit selector, feedforward + PI, multi-limit safety, flameout protection, autothrottle, reversionary modes.
Systems discipline
Clean data contract, deterministic replay, equivalence proofs, separate test interfaces — a core exercised headlessly outside rendering.
Engine / start domain
Spool dynamics, light-off / hung / hot start, two-time-constant EGT thermal behavior.
Vehicle autonomy
Internal and External FAB sources, environment bridge, health-driven supervisor, NO-GO gate and auditable decisions.
Observability
16-bit fault word, black box / PFR, IETM, schedule-proxy power margins and .xlsx flight report.
05 — In the cockpit
Driving the bench
The glass-cockpit interface exposes control, redundancy and evidence in one system view. Primary gauges, the TMR authority matrix, 2oo3 voting, sensor lanes, OBM residuals and overspeed show the current engine-control state. Separate panels expose AUTO · FAB and External FAB authority, the mission/environment frame, schedule-proxy power margins, fault injection and the PFR / CMC record. Every color is a state code.
- Try thisStart the engine, inject an N2 drift on one channel, and watch: the outlier is isolated in 3 cycles, degrade drops 3→2, a coded record latches in the black box. FDIA RESET clears it.
- Keyboard1–9/0 fire one-click fault scenarios, S start/stop, R flight report, T self-test, L language — every shortcut drives the same code path as a click, so replays stay valid.
- IETMClick any gauge for its definition plus a live "why" analysis grounded in the current state — the manual explains what the system is doing right now.
- AuthoritySelect MANUAL, AUTO · FAB or External FAB and inspect the active source, mission frame and resulting target without giving the UI control logic.
- ReportsIn-app flight chart with a snap cursor; downloadable .xlsx with summary, time series and fault-pulse analytics.
Live interfaceDesktop + real 375 px viewport
The same live interface shown in its desktop composition and its real 375 px viewport.
06 — How it grew
An audited evolution
The demo started life as v9. The milestones below show how its behavior and evidence developed through v35:
- v13Deterministic core and bit-exact replay.
- v14–v15Debounced channel-isolation latch; confirmed degrade hold — transients leave no scars.
- v17Ground-armed fault injections survive the start auto-reset; misleading dual-loss records debounced.
- v19–v20Noise-immune mission supervisor (0/20 false RTB) and the MISSION NO-GO engage gate.
- v21–v22Fault-pulse analytics in the .xlsx; truthful start transitions; acknowledgeable Master Caution.
- v23–v24Render gating (self-test 3.1→1.3 s), 375px mobile layout, keyboard + accessibility; PACER background pacing; chart cursor.
- v25–v26Leader election with the engine off; finite-rate autothrottle and bounded mission-altitude progression.
- v28–v29Fuel system (600 kg tank, BINGO 180 kg, leak injection, bingo-to-RTB, dispatch gate); live mission profile with a real clock and an amber replan line when RTB latches.
- v30–v31Offline font closure, a CI self-test gate, first-run briefing memory and clearer panel discovery without changing the protected core.
- v32Independent External FAB authority, validated mission frames, environment bridge, source exclusivity, NO-GO gates and deterministic replay.
- v33Observational power-margin schedule proxies and life counters, explicitly outside the control loop.
- v34–v35Deterministic new-mission seed advancement, separate manual reproduction, privacy controls and release guards with protected trajectories unchanged.
The v30-v35 releases are recorded in version reports and regression evidence; where behavior had to remain frozen, bit-identical trajectory checks verify it.
07 — Honest limits
What it does not claim
An artifact's credibility comes partly from clearly stating what it does not model:
- Aerodynamics and thermodynamics are deliberately simplified lumped first-order models, not an OEM cycle deck. N1 is an algebraic function of N2; EGT is a two-lag heuristic.
- Constants are illustrative / hand-tuned, not derived from a real engine.
- The atmosphere is an ISA approximation; weather, wind, turbulence and 3D aircraft dynamics are absent. External FAB demand is an engineering heuristic, not a certified gain-scheduled flight-control law.
- The power-margin panel uses schedule proxies, not a compressor map or validated lifing model, and it does not feed control.
- MIL-STD-1553 is stylized / aligned, not an actual bus implementation or a compliance claim.
- This is a browser simulation: not flight code, not certified and not hard-real-time guaranteed.
- The scope remains one engine and one fault-word format. Seeded scenarios are deterministic, while new External FAB missions advance their seed by design.
EGEMEN · TMR FADEC — case studysingle file · 50 ms fixed-step · deterministic replay · 52/52 validation
The live simulation opens from the link above. This write-up describes v35 using the project's own verified facts; no standards compliance is claimed.
Demir Akın — FADEC, control law, 2oo3 redundancy, jet-engine control systems (embedded), UX optimization. Emre Karausta — plant physics, sensor data modeling, 2oo3 edge-case testing.
EGEMEN
Tek motorlu bir SİHA turbofanı için kendini doğrulayan, üç kanallı (TMR) FADEC simülasyonu.
RolFADEC · kontrol yasası · 2oo3 yedeklilik · jet motoru kontrol sistemleri (gömülü)
KapsamTek motorlu bir SİHA turbofanı için tarayıcıda çalışan FADEC test tezgâhı.
KanıtCanlı v36 simülasyonu, 52 yerleşik öz-test senaryosu ve EN/TR v35 teknik raporları.
SınırTemsili motor modeli; uçuş kodu veya sertifikasyon kanıtı değildir.
EMRE KARAUSTA İLE ORTAK GELİŞTİRİLDİ · plant fiziği · sensör veri modelleme · 2oo3 uç-durum testleri
01 — Genel bakış
EGEMEN: Komuttan doğrulamaya.
FADEC'e hâkim okurlar için.
Mühendislik problemi
FADEC, motor yakıt komutunu yöneten tam yetkili dijital kontrol sistemidir. Bu tam yetki, yakıt yolundaki her kararın motor devrini ve sıcaklığını etkileyebileceği anlamına gelir. Güvenilmeyen bir ölçüm yalnızca hatalı bir gösterge üretmez; doğru kabul edildiğinde hatalı bir komuta dönüşebilir. Bir sensörde sürüklenme oluştuğunda veya bir ECU kanalı diğerlerinden ayrıştığında, hata kontrol yolunu bozmadan önce tespit edilmelidir.
Emniyet yalnızca motorun hedefe ulaşıp ulaşmadığıyla değerlendirilmez; hedefin hangi kaynaktan geldiği, hangi ölçümle sınırlandığı ve arıza durumunda hangi kaynağın kontrol yetkisini kaybettiği de izlenebilmelidir. EGEMEN, bu sorumluluk ilişkisini tek motorlu bir SİHA turbofanı için tarayıcıda çalışan bir simülasyonda görünür kılar. Bu ortamda komut sahipliği, motor tepkisi ve koruyucu müdahale birlikte izlenebilir. Uçuş kodu, gerçek motor modeli veya sertifikasyon kanıtı değildir; amacı, arıza toleranslı bir kontrol mimarisinin birbirinden ayırması gereken ilişkileri sınanabilir hale getirmektir.
Tek yetki zinciri
Zincir FADEC'in dışında başlar. Görev ve çevre modeli uçuş durumunu, atmosfer koşullarını ve motor hedefini belirler. OTO · FAB veya DIŞ FAB otomatik hedefi üretir; autothrottle, hedef N2 talebini belirli bir değişim hızıyla uygular. MANUEL hedef autothrottle'ı atlar, ancak FADEC'i atlamaz; iki yol etkin N2 talebinde birleşir. FADEC, sınırlandırılmış talebi min-max koruma mantığıyla yakıt komutuna dönüştürür. Temsili motor modeli motor tepkisini üretir, sensörler bu tepkiyi geri bildirir. Arayüz yalnızca yayımlanan durumu gösterir; kendi başına kontrol kararı vermez. Bu tekil akış, komut kaynaklarının yakıtı doğrudan kumanda etmesini ve arayüzün karar yoluna karışmasını önler; her sorumluluğun girdisi ile çıktısı ayrı tutulur.
Canlı kokpit görünümüNominal 3oo3 / çalışan durum
Çalışan simülasyon; ana motor göstergelerini, dağıtık TMR yetkisini ve 2oo3 oylama matrisini tek bir sistem görünümünde bir araya getirir.
Bilgiye güvenilemediğinde
Aynı kritik ölçümün üç bağımsız kanal tarafından izlendiğini düşünün. Üçlü modüler yedeklilik (TMR) bu kanalları birbirinden ayrı tutar. Bir sensör diğer ikisinden saparsa, 2oo3 medyan oylama orta kanal sonucunu seçerek güvenilen ölçümü korur. FDIR, doğrulanan arızayı tespit eder, etkilenen kanalı ayırır ve yedeklilik kaybını görünür tutarak sistem tepkisini yönetir.
Oylama tek başına her arızayı ortaya çıkaramaz. Tüm kanallar aynı yönde ve birlikte yanlış değere giderse, aralarındaki uyum ortak-mod uyuşmazlığını gizleyebilir. OBM, sensör sonucunu motor davranışına ilişkin bağımsız bir beklentiyle karşılaştırarak bu farkı ortaya çıkarır. Ana kontrol yasasının dışında çalışan ayrı ve kilitlenen aşırı devir yolu son koruma sınırını oluşturur: aşırı devir tetiklendiğinde yakıt, sıfırlama yapılana kadar kesik kalır. Bu katmanlar farklı bilgilere dayanır: oylama kanalları karşılaştırır, model motor beklentisini kullanır, ayrı aşırı devir yolu ise ham en yüksek N2 değerini izler ve ana kontrol yasasının sonucunu beklemez. Böylece tek senaryo; oylama, arıza izolasyonu, analitik yedeklilik ve koruyucu kapatmayı, tek bir mekanizmanın her durumu çözdüğü iddiasına düşmeden birbirine bağlar.
Üç kaynak, tek aktif yetki
MANUEL, OTO · FAB ve DIŞ FAB ayrı komut sahipleridir; aynı anda yalnızca biri etkin olabilir. Bu kural, farklı hedeflerin motor talebi üzerinde aynı anda yarışmasını engeller ve sorumlu kaynağı kayıtta açık tutar. MANUEL doğrudan pilot talebine aittir ve autothrottle'ın dışında kalır. OTO · FAB iç görev süpervizörüne aittir; DIŞ FAB ise kendi doğrulanmış görev çerçevelerini yayımlar ve bağımsız bir tohum kullanır. Her iki otomatik yol da sağlık ve yakıt için tanımlanmış devreye giriş koşullarına bağlıdır. Pilot kumanda kolunu hareket ettirdiğinde yetkiler birleşmez; etkin otomatik kaynak devreden çıkar.
Bu ayrım, üç kararın kaynağını açık tutar. Görev kaynağı aracın neye ihtiyaç duyduğunu belirler; autothrottle otomatik talebin hangi hızla uygulanacağını yönetir; FADEC ise motorun bu talebi kendi sınırları içinde nasıl karşılayacağını belirler. Komut kaynağının değişmesi arayüze kontrol yetkisi kazandırmaz ve FADEC'i zincirden çıkarmaz.
Davranış nasıl doğrulanıyor?
EGEMEN'in doğrulama zinciri deterministik 50 ms'lik sabit adımla başlar: kontrol, motor tepkisi ve arıza yönetimi aynı açık zaman adımında ilerler. Test düzeneği, oluşan davranışa 52 yerleşik öz-test senaryosu uygular. Aynı tohum ve girdiler kullanıldığında bit düzeyinde özdeş bir tekrar elde edilir; böylece tepki yalnızca görünüşüne göre değerlendirilmez, önceki çalışmayla doğrudan karşılaştırılabilir.
Canlı simülasyon; komutu, yakıt yolunu, motor tepkisini ve koruma durumunu görünür kılar. Kilitlenen arıza ve bakım kayıtları etkin oturum boyunca incelenebilir; ayrıca indirilebilir .xlsx doğrulama kaydına aktarılabilir. EN ve TR v35 raporları mimariyi ve sınırlarını belgeler. Arayüzsüz test düzeneği, aynı simülasyon çekirdeğini görünür arayüze bağlı olmadan çalıştırır. Bu unsurlar birlikte, yalnızca görsel sunum yapan bir demo yerine kendi davranışını doğrulayabilen bir test düzeneği oluşturur. Sistem, derleme veya dış bağımlılık gerektirmeyen tek bir HTML dosyası olduğu için simülasyon ve yerleşik senaryolar çevrimdışı da çalışır. Raporlar ve kayıtlar çalıştırılabilir doğrulama araçları değil, doğrulama sürecinin çıktılarıdır.
Dürüst sınır
Temsili motor modeli, sistem davranışını örneklemek üzere elle ayarlanmıştır. Kontrol sınırlarını, oylamayı ve arıza tepkilerini sınamak için gereken farklı tepki hızlarını korur; ancak bir üreticinin motor çevriminden, aerodinamik modelinden veya doğrulanmış uçuş verisinden türetilmemiştir. EGEMEN bu nedenle gerçek motor performansını, katı gerçek zamanlı davranışı, uçuşa elverişliliği veya sertifikasyonu doğrulamaz.
Bu sınır, ekranda görülen davranışın gerçek bir motor için doğrulanmış kabul edilmesini engeller; çalışma, mimariyi ve yöntemi gösteren bir doğrulama örneği olarak okunmalıdır. Ortaya koyduğu alan daha dar ve denetlenebilirdir: tek ve açık bir yetki zincirine sahip sistem mimarisi; görev seçimi, belirli değişim hızıyla uygulama ve motor kontrolü arasındaki sorumluluk ayrımı; gözlemlenebilir arıza yönetimi; deterministik tekrar; ekrandaki davranışa bağlanan doğrulama disiplini. Aşağıdaki teknik bölümler, bu yapının mekanizmalarını ve ayrıntılı sınırlarını eksiksiz açıklar.
TEKNİK AYRINTILAR
Kontrol mimarisi, alt sistemlerin işleyişi ve doğrulama dayanakları aşağıda eksiksiz ele alınır.
02 — Nasıl çalışır
Mimari: tek veri sözleşmesi
Simülasyon çekirdeği sistemi ilerletir ve tek bir FADECState sözleşmesi yayımlar. Arayüz bu durumu tüketir; kontrol kararı vermez.
Pilot / FAB kaynakları
MANUEL, OTO · FAB veya DIŞ FAB hedef N2'yi üretir. Bu kaynaklar FADEC'in dışındadır.
→
Simülasyon çekirdeği · 20 Hz
realStep(dt) kaynağı seçer, kontrolü çalıştırır ve plant modelini ilerletir.
→
FADECState
writeFADECState() tüm durumu tek sözleşmeye yazar. Sistem için tek doğruluk kaynağıdır.
→
render()
Arayüz yalnızca sözleşmeyi gösterir. Kontrolden bağımsızdır.
Sorumluluk zinciri açıktır. Görev ve çevre modeli uçuş durumunu, atmosfer koşullarını ve motor hedefini belirler. Autothrottle, hedef N2'yi belirli bir değişim hızıyla uygular. FADEC bu sınırlandırılmış hedefi yakıt komutuna dönüştürür; plant modeli motor tepkisini üretir.
Veri sözleşmesi bu zinciri test edilebilir tutar ve gösterim katmanını kontrolün dışında bırakır. Arayüzsüz test düzeneği, aynı simülasyon çekirdeğini görünür arayüze bağlı olmadan çalıştırır.
Rastgele sayı akışları alt sistemlere göre ayrılır. DIŞ FAB görevleri kendi tohumunu kullanır; yeni bir görev hazırlanırken tohum deterministik olarak ilerler, kaydedilmiş bir tohum ise aynı planı yeniden üretir. PACER, arka planda kaçırılan zamanı sınırlı biçimde telafi eder; ayrı test arayüzleri ise ham kontrol hesaplarını ve kullanıcı akışlarını sınar.
03 — İçinde neler var
Alt sistemler
Sayılar temsilî ve elle ayarlanmıştır ("TUNABLE"); gerçek bir motordan türetilmemiştir. Her alt sistem, yaptığı iş ve bu tasarımın gerekçesiyle birlikte açıklanır.
Plant modeli deterministik
Plant modeli, yakıt akışı Wf'yi N2, N1 ve EGT tepkilerine dönüştürür. Yakıt eyleyicisi ile spool ataleti birinci dereceden gecikmelerle temsil edilir: τ_FMV=0.25 s, τ_N2=1.3 s ve τ_N1=3.5 s.
N1, mekanik bir şaft modeli yerine N2'yi N1 ≈ (N2−18)×1.15 bağıntısıyla aerodinamik olarak izler. EGT ise hızlı yanma tepkisini (τ=1.5 s), metal kütlenin yavaş ısınmasıyla (τ=60 s) %85/%15 oranında birleştirir.
Neden: model bilinçli olarak indirgenmiştir; buna karşın spool ve EGT sınırlarını sınamak için gereken farklı tepki hızlarını korur. Sabit gaz konumundaki hafif sıcaklık sürüklenmesi kasıtlıdır.
WF_MAX 2600N2_IDLE 60N2_MAX 112WF_MIN 120 kg/h
Kontrol yasası — min-max limit seçici kontrol
Kontrol yasası, hedef N2'yi yakıt komutu Wf'ye dönüştürür. Denge yakıtını ileri besleme olarak kullanır; komut doygunluğa ulaştığında integratörü duran bir PI düzeltmesi ekler.
Üst adaylar ivmelenmeyi, N2'yi ve EGT'yi sınırlar. Alt adaylar yavaşlama sınırını ve yanma sönmesini önleyen WF_MIN emniyet tabanını uygular. Min-max seçici, o anda sınırlayıcı olan adayı komuta taşır ve etkin fiziksel sınırı arayüzde gösterir.
Neden: bu yapı, tek bir sınırsız PID yerine birden çok limiti birlikte yöneten bir mimaridir. Seçilen limitin izlenmesi her müdahaleyi görünür kılar; alt taban da seçicinin minimum yakıtın altında komut vermesini önler.
KP 22KI 9N2 limit 108→112EGT limit 900→950
Autothrottle kontrol
Autothrottle, otomatik kaynağın hedef N2 talebini komut sıçraması oluşturmadan uygular. Talep artarken 7 %N2/s, azalırken 4 %N2/s hız sınırı kullanılır; OTO · FAB acil durumunda bu sınır 12 %N2/s olur.
Devreye geçişte sıçrama oluşmaz; talep mevcut hedeften başlar. Görev süpervizörü kararını anında değiştirebilir, autothrottle ise bu talebin FADEC'e hangi hızla ulaştığını yönetir.
Neden: süpervizör kararını belirli bir değişim hızıyla uygulamadan ayırmak, komut sahipliğini açık tutar ve motor hedefinde yapay bir basamak oluşmasını önler.
AT_UP 7 %/sAT_DN 4 %/sAT_EMERG 12 %/s
Canlı kayıt / OTO + FABPilot girişi + görev süpervizörü
Pilot Konsolu ile FAB görev paneli, aynı çalışan OTO / FAB karesinin iki ayrı ayrıntısını gösterir.
2oo3 oylama ve sağlık FDIR
Oylama katmanı, kalan yetkiyi korurken uyuşmayan ölçümü reddeder. A, B ve C ECU kanallarının her biri N2, EGT ve N1 için iki sensör örneği alır. Her örnek tek bir okumadır; kanalın ürettiği birleşik sinyal ise dağıtık oylayıcıya gönderilen veri hattıdır.
Üç kanalın veri hatları medyan değere göre karşılaştırılır. ε bandının dışındaki veri hattı aykırı kabul edilir; HARD ve SOFT sınıfları geçersiz sinyalleri makul görünen sapmalardan ayırır. Oylama, merkezî bir oylayıcı olmadan CCDL üzerinden yürür.
İzolasyon için 3 ardışık çevrimde doğrulama gerekir; böylece tek çevrimlik tohumlu F-BLIP, kilitli kayıt bırakmadan düzelebilir. Kalıcı arıza, bakım sıfırlamasına kadar oylama dışında kalır. İki kanal kaldığında ikinci katman uyuşmazlığı bildirir, ancak hangi kanalın hatalı olduğunu belirleyemez.
Neden: oylayıcıyı kanallara dağıtmak merkezî tek hata noktasını kaldırır; art arda çevrim doğrulaması ise geçici gürültüyü doğrulanmış bozulmadan ayırır.
ε(N2) 2.5ε(EGT) 18ε(N1) 2.5
Canlı yakalama / yarı-körEGT-C izole / yedeklilik 2oo3
Yarı-kör senaryosu, EGT-C izolasyonunu oylama matrisi ve sensör sağlık panosunda gösterirken sistem 2oo3 ile çalışmayı sürdürür.
OBM — analitik yedeklilik FDIR
On-board model (OBM), N2 ve EGT için bağımsız bir beklenti üretir. Bu tahmini oylanmış ölçümlerle karşılaştırır; fark N2 ±6 veya EGT ±60 artık (residual) bandını aşarsa bir durum bayrağı üretir.
Üç kanal aynı hatalı değeri bildirirse oylamanın reddedeceği aykırı bir veri hattı kalmaz; OBM yine de ortak-mod uyuşmazlığını belirleyebilir. Tek sağlıklı kanal kaldığında alternatif kestirime dayalı kontrol için N2 ve EGT üretebilir.
Ortak-mod bayrakları, yalnız RUN fazında ve 3 çevrimlik doğrulamadan sonra mürettebat uyarısına ve kara kutuya ulaşır. Böylece normal çalıştırma geçişleri yanlış bakım kaydı bırakmaz.
Neden: oylama, kanalların birbiriyle tutarlı olup olmadığını; OBM ise bu tutarlılığın fiziksel açıdan makul olup olmadığını değerlendirir.
Alternatif kestirime dayalı kontrol, lider seçimi ve aşırı devir FDIR
Alternatif kestirime dayalı kontrol, sensör ölçümüne dayalı yetki kaybolsa da ECU hesabı çalışmayı sürdürdüğünde yakıt komutunu korur. İlgili kanal, OBM'nin ürettiği N2 kestirimiyle çalışmaya devam eder; böylece CPU'nun çalışır durumda olması ile sensör sağlığı ayrı kararlar olarak kalır.
Lider seçimi önce tamamen sağlıklı kanalı, ardından CPU'su çalışan herhangi bir kanalı tercih eder. 0.3 s tutma süresi sık ve gereksiz değişimi önler; lider değişimi komut sıçraması oluşturmaz. Seçim motor kapalıyken de yürür; yerdeki arıza ve lider değişimi, yakıt akışı başlamadan önce görünür kalır.
Ayrı ve kilitlenen aşırı devir yolu ham en yüksek N2 değerini okur, %115'in üzerinde yakıtı keser ve sıfırlamaya kadar tetiklenmiş durumda kalır. Ana kontrol yasasına bağlı değildir.
Neden: ölçüm kaybı kontrol kaybına dönüşmek zorunda değildir; son aşırı devir koruması da koruduğu kontrol yolundaki bir arızadan etkilenmeden çalışabilmelidir.
aşırı devir >115%SWITCH_HOLD 0.3 skademeler 3oo3→2oo3→1·K11→SAFE
Çalıştırma sırası FSM
Çalıştırma durum makinesi; marşı, ateşlemeyi, yakıtı ve kapalı çevrim kontrole geçişi koordine eder. OFF → CRANK → LIGHT-OFF → ACCEL → RUN sırasını izler; N2 ≥ 18'de ateşleme başlar, %50'de marş kesilir ve rölantide kontrol yasası devralır.
HUNG ve HOT durumları, yeterince hızlanamayan veya EGT'si 720 °C'yi aşan çalıştırma sürecini iptal eder. Yerde kurulan arıza enjeksiyonları, çalıştırma sırasındaki otomatik sıfırlamadan korunur; seçilen arıza bir sonraki çalıştırmada da etkin kalır.
Neden: açıkça tanımlanmış durumlar ve iptal yolları, çalıştırma davranışını tek bir hız eşiğine indirgemeden sınanabilir kılar.
Canlı kayıt / çalıştırma sırasıHUNG START / START ABORT
HUNG START ve kilitlenen START ABORT durumu, çalışan durum makinesi görünümünde birlikte izlenir.
FAB süpervizörü — araç düzeyinde otonomi kontrol
Görev/FAB katmanı FADEC'in dışında yer alır; uçuş durumunu, çevreyi ve hedef N2'yi belirler. İç OTO · FAB, TAXI'den SHUTDOWN'a uzanan 10 sabit görev bacağını yürütür. DIŞ FAB ise doğrulanmış irtifa, Mach ve faz çerçeveleri yayımlayan ve bağımsız bir tohum kullanan komut kaynağıdır; N2 isteğini bu çerçeveden türetir.
İrtifa ilerlemesi ile atmosfer güncellemesi görev ve çevre modeline aittir. İç OTO · FAB, görev bacağının irtifasını 350 m/s sınırıyla ilerletir; DIŞ FAB kendi görev çerçevesini aynı çevre köprüsünden geçirir. Autothrottle yalnızca ortaya çıkan N2 talebinin değişim hızını sınırlar.
İç OTO · FAB süpervizörü, motor sağlığı değiştiğinde kendi görev akışını geçersiz kılabilir. Öncelik ACİL > RTB > DERATE > SCRIPT sırasındadır; DERATE ve RTB için 3 çevrimlik doğrulama gerekirken ACİL kararı anında uygulanır. Her iki otomatik kaynak da yetersiz yedeklilik veya yakıt durumunda devreye girişi engelleyen koşullar uygular.
MANUEL, OTO · FAB ve DIŞ FAB birbirini dışlar. Pilot kumanda kolunu hareket ettirdiğinde iki otomatik kaynak da devreden çıkar. Her otomatik karar, görev durumu ve gerekçesiyle kaydedilir.
Neden: komut kaynağı, çevre ilerlemesi ve motor kontrolü ayrı sorumluluklar olarak kalır; güncel sistem sağlığı da görev akışından her zaman önce gelir.
Arıza sözcüğü, kara kutu ve IETM gözlemlenebilirlik
Gözlemlenebilirlik katmanı, sistemin neden durum değiştirdiğine ilişkin kaydı korur. Arızalar, 1553 ile hizalı bir çerçevede 16 bitlik arıza sözcüğüyle taşınır: [ALAN:3 | KOD:4 | CH:2 | VOTER:2 | COMP:5].
PFR / kara kutu bu sözcükleri kilitli olarak saklar ve yinelenen kayıtları ayıklar; canlı kod çözücü ise her alanı görünür kılar. IETM, bir göstergeyi tanımı ve duruma bağlı açıklamasıyla eşleştirir.
Master Caution uyarısı her neden için ayrı ayrı onaylanabilir; yeni bir neden lambayı yeniden yakar. Kokpit, noktalara kilitlenen imleçli grafik ve indirilebilir .xlsx raporu aynı veri üreticisinden beslenir.
Güç marjı gözlemcisi, düzeltilmiş N2 ile normalize edilmiş yakıtı elle ayarlanmış temsili çizelgelerle karşılaştırır. Surge ve LBO için temsili marjları ve ömür sayaçlarını gösterir; ancak kontrol yasasına geri besleme yapmaz. Bir kompresör haritası veya ömür modeli değildir.
Neden: arıza, oylama, bakım ve gözlemci kayıtları denetlenebilir kalırken arayüz katmanı kontrol yetkisi kazanmaz.
Canlı kayıt / bakımPFR / CMC kara kutu
Kilitlenen kanal izolasyonu arıza sözcükleri, oturum içindeki PFR / CMC bakım kaydında görünür kalır.
04 — Nasıl doğrulanır
Test disiplini
İddia yalnızca “tıklayınca çalışıyor” değildir. Test düzeneği, doğrulama araçlarını ve kayıtlarını kendi içinde taşır:
- Öz-test52 yerleşik öz-test senaryosu; oylamayı, kilitlenmeyi, görev yetkisini, çevre köprüsünü ve güç marjı gözlemcisini kapsar. Her senaryo bir veya daha fazla beklenen son koşulu denetler; ayırt edicilik kontrolü, test takımının gerektiğinde gerçekten başarısız olabildiğini doğrular.
- Deterministik tekrarAlt sistemlerin rastgele sayı akışları birbirinden ayrıdır. Aynı tohum ve girdiler bit düzeyinde özdeş biçimde tekrar oynatılır; yeni bir DIŞ FAB görevi, kayıtlı tohumla elle tekrar üretme olanağını bozmadan kendi tohumunu deterministik olarak ilerletir.
- Eşdeğerlik kontrolleriBir sürümün korunan davranışı değiştirmemesi gerekiyorsa MANUEL ve OTO · FAB yörüngeleri; fizik, olaylar ve kara kutu kayıtlarıyla birlikte sürümler arasında karşılaştırılır.
- Hedefli testlerGörev süpervizörü, sensör gürültüsüne karşı tohum kontrollü 20 çalıştırmalık bir testle sağlamlaştırıldı: yanlış RTB kilitlenmeleri 2/20'den 0/20'ye inerken tespit süresi değişmedi.
- Otomatik arıza denetimiOtonom bir ajan, denetim modunda her yerleşik arıza senaryosunu PASS veya FAIL sonucuna kadar yürütür. Otonom uçuşta gerçekçilik için tohumlu MTBF arızaları enjekte eder; bunu manuel modda hiçbir zaman yapmaz.
- Süreçv30-v35 sürümleri, sürüm raporları ve regresyon test kayıtlarıyla belgelenmiştir. Güncel sürüm 52/52 öz-test senaryosundan ve 214/214 TR/EN yerelleştirme eşliği kontrolünden geçer.
Çalışma, birbirinden ayrı mühendislik alanlarını çalışan ve denetlenebilir tek bir sistemde bir araya getirir:
Yedeklilik & FDIR
2oo3, HARD/SOFT ayrımı, art arda çevrim doğrulamalı izolasyon kilidi, kademeli yedeklilik kaybı, analitik yedeklilik, ortak-mod farkındalığı ve ayrı kilitlenen aşırı devir yolu.
Kontrol yasası
Min-max limit seçimi, ileri besleme + PI, çok limitli emniyet, yanma sönmesi koruması, autothrottle ve alternatif kestirime dayalı modlar.
Sistem disiplini
Temiz veri sözleşmesi, deterministik tekrar, eşdeğerlik kontrolleri, ayrı test arayüzleri ve gösterim katmanından bağımsız, arayüzsüz çalıştırılabilen çekirdek.
Motor / çalıştırma alanı
Spool dinamiği, LIGHT-OFF / HUNG / HOT çalıştırma durumları ve iki zaman sabitli EGT termal davranışı.
Araç otonomisi
İç ve DIŞ FAB kaynakları, çevre köprüsü, sistem sağlığına göre karar veren süpervizör, NO-GO koşulu ve denetlenebilir kararlar.
Gözlemlenebilirlik
16 bitlik arıza sözcüğü, kara kutu / PFR, IETM, temsili güç marjı çizelgeleri ve .xlsx uçuş raporu.
05 — Kokpitte
Test düzeneğini kullanmak
Cam kokpit arayüzü; kontrolü, yedekliliği ve doğrulama kayıtlarını tek bir sistem görünümünde sunar. Ana göstergeler, TMR yetki matrisi, 2oo3 oylama, sensör veri hatları, OBM artık değerleri ve aşırı devir durumu; motor kontrolünün güncel durumunu gösterir. Ayrı paneller OTO · FAB ve DIŞ FAB yetkisini, görev ve çevre çerçevesini, temsili güç marjlarını, arıza enjeksiyonunu ve PFR / CMC kaydını sunar. Her renk bir durum kodudur.
- Şunu deneMotoru çalıştır, bir kanala N2 sürüklenmesi uygula ve izle: aykırı veri hattı 3 çevrimde izole edilir, yedeklilik 3'ten 2'ye düşer ve kodlu bir kayıt kara kutuda kilitlenir. FDIA RESET bu durumu sıfırlar.
- Klavye1–9/0 tek tıklamalı arıza senaryolarını, S start/stop işlevini, R uçuş raporunu, T öz-testi ve L dil geçişini çalıştırır. Her kısayol, tıklamayla aynı kod yolunu kullanır; böylece tekrar kayıtları geçerli kalır.
- IETMHerhangi bir göstergeye tıklandığında tanımı ve o anki duruma dayalı canlı “neden” açıklaması açılır. Kılavuz, sistemin o anda ne yaptığını açıklar.
- YetkiMANUEL, OTO · FAB veya DIŞ FAB'ı seç; arayüzün kontrol kararı vermediği bu yapıda etkin kaynağı, görev çerçevesini ve oluşan hedefi izle.
- RaporlarNoktalara kilitlenen imleçli uygulama içi uçuş grafiği; özet, zaman serisi ve arıza darbesi analizi içeren indirilebilir .xlsx raporu.
Canlı arayüzMasaüstü + gerçek 375 px görünüm alanı
Aynı canlı arayüzün masaüstü düzeni ve gerçek 375 px genişliğindeki görünümü birlikte gösterilir.
06 — Nasıl gelişti
Sürümlerle izlenen gelişim
Çalışmanın ilk sürümü v9'du. Aşağıdaki kilometre taşları, davranışın ve doğrulama kayıtlarının v35'e kadar nasıl geliştiğini gösterir:
- v13Deterministik çekirdek ve bit-birebir tekrar oynatma.
- v14–v15Art arda çevrim doğrulamalı kanal izolasyonu kilidi ve doğrulanmış yedeklilik kaybının korunması; geçici sapmalar kalıcı kayıt bırakmaz.
- v17Yerde kurulan arıza enjeksiyonları, çalıştırma sırasındaki otomatik sıfırlamadan korunur; yanıltıcı çift kayıp kayıtları art arda çevrim doğrulamasıyla süzülür.
- v19–v20Sensör gürültüsüne dayanıklı görev süpervizörü (0/20 yanlış RTB) ve MISSION NO-GO devreye giriş koşulu.
- v21–v22.xlsx raporunda arıza darbesi analizi, durumu doğru yansıtan çalıştırma geçişleri ve onaylanabilir Master Caution.
- v23–v24Gösterim kapısı (öz-test 3,1→1,3 sn), 375 px mobil düzen, klavye ve erişilebilirlik desteği, PACER arka plan zamanlaması ve grafik imleci.
- v25–v26Motor kapalıyken lider seçimi, belirli değişim hızına sahip autothrottle ve sınırlandırılmış görev irtifası ilerlemesi.
- v28–v29Yakıt sistemi (600 kg tank, BINGO 180 kg, sızıntı enjeksiyonu, BINGO→RTB ve kalkış koşulu), gerçek zaman saatiyle çalışan canlı görev profili ve RTB kilitlendiğinde görünen amber yeniden planlama çizgisi.
- v30–v31Çevrimdışı font bütünlüğü, CI öz-test kapısı, ilk açılış brifing durumunun hatırlanması ve korunan çekirdeği değiştirmeden panellerin daha kolay bulunması.
- v32Bağımsız DIŞ FAB yetkisi, doğrulanmış görev çerçeveleri, çevre köprüsü, kaynakların birbirini dışlaması, NO-GO koşulları ve deterministik tekrar.
- v33Kontrol çevriminin dışında çalışan temsili güç marjı çizelgeleri ve ömür sayaçları.
- v34–v35Yeni görev tohumunun deterministik ilerletilmesi, kayıtlı tohumla bağımsız tekrar üretimi, gizlilik kontrolleri ve korunan yörüngeleri değiştirmeyen sürüm kapıları.
v30-v35 sürümleri, sürüm raporları ve regresyon test kayıtlarıyla belgelenmiştir. Davranışın değişmemesi gereken noktalar, bit düzeyinde özdeş yörünge kontrolleriyle doğrulanır.
07 — Dürüst sınırlar
İddia etmedikleri
Bir çalışmanın güvenilirliği, modellemediği unsurları da açıkça belirtmesine bağlıdır:
- Aerodinamik ve termodinamik, kasıtlı olarak basitleştirilmiş toplu parametreli birinci dereceden modellerle temsil edilir; bunlar üreticiye ait bir motor çevrim modeli değildir. N1, N2'nin cebirsel bir fonksiyonudur; EGT ise iki gecikmeli sezgisel bir modeldir.
- Sabitler temsilî ve elle ayarlanmıştır; gerçek bir motordan türetilmemiştir.
- Atmosfer, ISA yaklaşımıyla temsil edilir; hava durumu, rüzgâr, türbülans ve üç boyutlu uçak dinamiği modellenmez. DIŞ FAB talebi bir mühendislik sezgisidir; sertifikalı, kazanç çizelgeli bir uçuş kontrol yasası değildir.
- Güç marjı paneli temsili çizelgeler kullanır; bir kompresör haritası veya doğrulanmış ömür modeli değildir ve kontrole geri besleme yapmaz.
- MIL-STD-1553 yalnızca stil ve çerçeve düzeni bakımından hizalanmıştır; gerçek bir veri yolu uygulaması veya uyum iddiası değildir.
- Bu bir tarayıcı simülasyonudur: uçuş kodu değildir, sertifikalı değildir ve katı gerçek zaman garantisi vermez.
- Kapsam, tek motor ve tek arıza sözcüğü formatıyla sınırlıdır. Tohumlu senaryolar deterministiktir; yeni DIŞ FAB görevleri ise tohumlarını tasarım gereği ilerletir.
EGEMEN · TMR FADEC — proje incelemesitek dosya · 50 ms sabit adım · deterministik tekrar · 52/52 doğrulama
Canlı simülasyon yukarıdaki bağlantıdan açılır. Bu metin, v35 sürümünü projenin doğrulanmış olgularına dayanarak açıklar; herhangi bir standarda uyum iddiasında bulunmaz.
Demir Akın — FADEC, kontrol yasası, 2oo3 yedeklilik, jet motoru kontrol sistemleri (gömülü) ve UX optimizasyonu. Emre Karausta — plant fiziği, sensör veri modelleme ve 2oo3 uç durum testleri.
TUĞRUL
Fixed-wing flight-control firmware built from scratch on STM32F446RE.
RoleRegister-level firmware · hardware verification
ScopeFixed-wing flight-control firmware on an STM32 Nucleo-F446RE.
ProofReal hardware acceptance logs and a live evidence station.
BoundaryBench-measured firmware; real flight remains outside scope.
01 — What it is
At a glance
TUĞRUL is a register-level fixed-wing flight controller written from scratch for the STM32 Nucleo-F446RE, without HAL or an RTOS.
The portfolio claim is intentionally narrow: this is flight-control firmware measured on real hardware. The accompanying station replays the project's own acceptance evidence and keeps measured records separate from simulation and pending evidence.
02 — How it is built
Register-level architecture
The firmware configures the controller directly at register level and carries the flight-control path through attitude estimation, control output, failsafe behavior and watchdog recovery. The ordering of those responsibilities is treated as part of the design, not as an interface detail.
- PlatformSTM32F446RE on a Nucleo-F446RE development board.
- RuntimeBare-metal firmware with no HAL and no RTOS.
- Control pathAttitude estimation, control output and failsafe ownership kept in an explicit execution order.
03 — What supports the claims
Hardware acceptance evidence
Public claims are tied to the project's hardware-acceptance records rather than presented as unqualified feature statements.
The live station separates real records, simulation and pending evidence. Its evidence matrix and replay panels make that status visible so a reviewer can distinguish what was measured from what remains an engineering next step.
The public station replays the project's own UART acceptance record and keeps the latched safe state visible.
Measured, code-level and pending evidence remain visibly separated in the station.
04 — Honest limits
What it does not claim
- This is bench-measured flight-control firmware, not a flying UAV.
- Real flight testing remains outside the current scope.
- Items without completed evidence remain visibly marked as pending in the station.
TUĞRUL · register-level flight controllerbare metal · real hardware · acceptance evidence
The evidence station opens from the links above. This case study uses only the project's existing public claims and scope labels.
TUĞRUL
STM32F446RE üzerinde sıfırdan geliştirilen sabit-kanat uçuş kontrol yazılımı.
RolRegister düzeyi yazılım · donanım doğrulaması
KapsamSTM32 Nucleo-F446RE üzerinde sabit-kanat uçuş kontrol yazılımı.
KanıtGerçek donanım kabul logları ve canlı kanıt istasyonu.
SınırTezgâh üzerinde ölçülmüş yazılım; gerçek uçuş kapsam dışında.
01 — Nedir
Bir bakışta
TUĞRUL, STM32 Nucleo-F446RE için HAL veya RTOS kullanmadan sıfırdan geliştirilmiş register düzeyinde sabit kanat uçuş kontrol yazılımıdır.
Portfolyodaki iddia bilinçli biçimde dardır: gerçek donanım üzerinde ölçülmüş uçuş kontrol yazılımı. Eşlik eden istasyon, projenin kendi kabul kanıtlarını yeniden oynatır; ölçülmüş kayıtları simülasyondan ve kanıt bekleyen maddelerden ayırır.
02 — Nasıl kuruldu
Register düzeyi mimari
Yazılım, denetleyiciyi doğrudan register düzeyinde yapılandırır; uçuş kontrol yolunu tutum kestirimi, kontrol çıkışı, failsafe davranışı ve watchdog toparlanması boyunca yönetir. Bu sorumlulukların sırası, bir arayüz ayrıntısı değil tasarımın parçasıdır.
- PlatformNucleo-F446RE geliştirme kartı üzerinde STM32F446RE.
- Çalışma ortamıHAL ve RTOS kullanmayan bare-metal yazılım.
- Kontrol yoluTutum kestirimi, kontrol çıkışı ve emniyetli durum yönetimi açık bir yürütme sırasına bağlıdır.
03 — İddiaları ne destekliyor
Donanım kabul kanıtı
Projeye ilişkin her iddia, donanım kabul kayıtlarıyla birlikte sunulur.
Canlı istasyon gerçek kayıt, simülasyon ve kanıt bekleyen durumları birbirinden ayırır. Kanıt matrisi ve tekrar panelleri bu durumu görünür kılar; inceleyen kişi neyin ölçüldüğünü, neyin sıradaki mühendislik adımı olduğunu ayırt edebilir.
Halka açık istasyon, projenin kendi UART kabul kaydını yeniden oynatır ve kilitli emniyet durumunu görünür tutar.
Ölçülen, kod düzeyindeki ve kanıt bekleyen maddeler istasyonda açıkça ayrı tutulur.
04 — Dürüst sınırlar
İddia etmedikleri
- Bu çalışma tezgâh üzerinde ölçülmüş uçuş kontrol yazılımıdır; uçan bir İHA değildir.
- Gerçek uçuş testi mevcut kapsamın dışındadır.
- Kanıtı tamamlanmayan maddeler istasyonda açıkça kanıt bekleyen olarak işaretlenir.
TUĞRUL · register düzeyinde uçuş kontrolübare metal · gerçek donanım · kabul kanıtı
Kanıt istasyonu yukarıdaki bağlantılardan açılır. Bu vaka çalışması yalnızca projenin mevcut kamuya açık iddialarını ve kapsam etiketlerini kullanır.
Research Archive
Üretken Yapay Zekâ Çağında Havacılık Mühendisliği
This Turkish-language structured narrative review examines how generative AI is being used across engineering tasks such as requirements, modelling, coding, testing and documentation, then asks what can be transferred responsibly to aviation. It brings together evidence on productivity, error, overconfidence, traceability and human oversight, while distinguishing direct aerospace findings from broader software and engineering studies. The review does not treat AI as an autonomous authority or claim that it replaces professional competence. Its central concern is the working relationship between AI-assisted production, independent verification and accountable human acceptance in safety-critical practice. The full Turkish text and source record are available on request.
- Generative AI
- Verification
- Traceability
- Professional responsibility
Türkçe hazırlanan bu yapılandırılmış anlatı derlemesi, üretken yapay zekânın gereksinim, modelleme, kodlama, test ve dokümantasyon gibi mühendislik görevlerindeki kullanımını inceler; ardından bu bulguların havacılığa hangi sınırlar içinde aktarılabileceğini değerlendirir. Çalışma; verim, hata, aşırı güven, izlenebilirlik ve insan denetimine ilişkin kanıtları bir araya getirirken doğrudan havacılık bulgularını daha genel yazılım ve mühendislik çalışmalarından ayırır. Yapay zekâyı bağımsız karar mercii olarak sunmaz ve mesleki yetkinliğin yerini aldığını iddia etmez. Odağında, güvenlik-kritik uygulamalarda yapay zekâ destekli üretim, bağımsız doğrulama ve sorumluluğu açık insan kabulü arasındaki çalışma ilişkisi vardır. Tam Türkçe metin ve kaynak kaydı talep üzerine paylaşılabilir.
- Üretken yapay zekâ
- Doğrulama
- İzlenebilirlik
- Mesleki sorumluluk
AI-Based Defect Detection Literature Review
Prepared as co-authored coursework, this comparative literature review examines how Edge Computing and Edge AI divide work across industrial IoT systems. It covers low-latency local processing, edge-node scheduling, container migration, predictive maintenance and AI-assisted defect detection on resource-constrained devices. The review compares local and cloud responsibilities rather than presenting one architecture as universally superior. Its synthesis points to hybrid edge-cloud systems, where time-sensitive processing and inference remain close to industrial equipment while heavier analysis and coordination stay in the cloud. It reports findings from eight reviewed sources and does not present them as experiments performed by the authors. The submitted full text is available on request, subject to co-author and coursework-sharing limits.
- Edge Computing
- Edge AI
- Defect detection
- Industrial IIoT
Ders kapsamında ortak yazarlı olarak hazırlanan bu karşılaştırmalı literatür incelemesi, Edge Computing ile Edge AI'ın endüstriyel IoT sistemlerinde görevleri nasıl paylaştığını ele alır. Düşük gecikmeli yerel işleme, edge node seçimi ve zamanlama, container migration, predictive maintenance ve kaynakları kısıtlı cihazlarda yapay zekâ destekli kusur tespiti başlıklarını kapsar. İnceleme, tek bir mimariyi her koşulda üstün göstermek yerine yerel katman ile bulutun farklı sorumluluklarını karşılaştırır. Sentez, zamana duyarlı işleme ve çıkarımın endüstriyel kaynağa yakın kaldığı; daha ağır analiz ve koordinasyonun bulutta yürütüldüğü hibrit edge-cloud yapılara işaret eder. Sekiz kaynaktaki bulguları aktarır; bunları yazarların gerçekleştirdiği deneyler olarak sunmaz. Teslim edilen tam metin, ortak yazarlık ve ders paylaşım sınırları gözetilerek talep üzerine değerlendirilebilir.
- Edge Computing
- Edge AI
- Kusur tespiti
- Endüstriyel IIoT
Privacy / KVKK · concise notice
Privacy &
Privacy &
Data Notice.
demirakin.com is a personal portfolio. It has no account, contact form, advertising profile or marketing tracker. The site uses cookie-free Vercel Web Analytics and stores only your language preference locally in your browser.
01Controller
Data Controller
For the processing described in this notice, the data controller is Demir Akın. Questions and requests about personal data can be sent directly by email.
ControllerDemir Akın
Contactdemirakin.tr@gmail.com
02Data
What the site processes
Visits and aggregate analytics
Vercel Web Analytics may record an event timestamp, the visited URL or path, filtered query parameters, referrer, approximate geolocation, device type, operating system and browser details, and analytics script version. Vercel states that these data points are anonymous and are not associated with an individual, customer or IP address. Its request-derived visitor hash is discarded after 24 hours.
Language preference
The portfolio stores a localStorage language preference for EN/TR. This value remains on your device until you clear the site's browser data and is not sent elsewhere by the portfolio's own code.
Direct correspondence
There is no web form. If you choose to send an email, your address, name, message and any attachment you provide are processed through your selected email service and the recipient mailbox solely as part of that correspondence.
The site does not use advertising or marketing cookies. Vercel Web Analytics is cookie-free, and the language preference is browser storage rather than a cookie.
03Purpose
Purposes and legal basis
- Operating, delivering and protecting the portfolio; understanding aggregate traffic and improving the site.
- Responding to messages that you choose to send and, where relevant, taking steps connected with an opportunity or professional request.
Collection method
Visit information is collected automatically in electronic form through the hosting and analytics infrastructure when the site is opened. The language preference is created on your device when you choose EN or TR. Correspondence data is obtained directly from you only if you send an email.
Under Article 5 of Türkiye's Personal Data Protection Law No. 6698 (KVKK), these activities rely, as applicable, on steps directly related to establishing or performing a contract, the establishment or protection of a right, and the controller's legitimate interests where your fundamental rights and freedoms are not harmed (Article 5/2(c), (e) and (f)). No consent is requested for a purpose that does not require it.
04Recipients
Service providers and international processing
Technical visit data is processed by Vercel, Inc. and its service providers for hosting, security and aggregate analytics. Vercel is a United States provider and states that its services may be processed in the United States and other locations where it or its subprocessors operate. Technical data may therefore be processed outside Türkiye, subject to the applicable transfer rules and safeguards.
Email correspondence is processed by the email services used by you and the recipient. LinkedIn and Instagram receive data only when you choose to open those external services; no social-media content or tracking widget is embedded in this portfolio.
05Retention
How long data remains
Vercel discards its request-derived visitor session hash after 24 hours. Aggregate analytics records are retained according to Vercel's current service and reporting terms. The language preference remains on your device until you clear site data. Correspondence is kept only for as long as needed to respond, maintain necessary records or protect a right, and is deleted or anonymised when those purposes end.
06Your rights
KVKK Article 11
You may ask whether your personal data is processed; request information about processing, its purpose and recipients; request correction; request deletion or destruction where the legal conditions apply; ask that correction or deletion be notified to recipients; object to an exclusively automated result against you; and claim compensation for damage caused by unlawful processing.
Send a request to demirakin.tr@gmail.com with enough information to identify the relevant interaction and the right you wish to exercise.
Effective / 19 July 2026demirakin.com · privacy / data
Gizlilik / KVKK · kısa aydınlatma
Gizlilik ve Veri
Gizlilik ve Veri
Aydınlatma Metni.
demirakin.com kişisel bir portfolyodur. Hesap, iletişim formu, reklam profili veya pazarlama takipçisi kullanmaz. Site, çerezsiz Vercel Web Analytics ile sınırlı trafik ölçümü yapar ve yalnızca dil tercihinizi tarayıcınızda yerel olarak saklar.
01Veri sorumlusu
Veri sorumlusu
Bu metinde açıklanan veri işleme faaliyetleri bakımından veri sorumlusu Demir Akın'dır. Kişisel verilerle ilgili soru ve talepler doğrudan e-posta ile iletilebilir.
Veri sorumlusuDemir Akın
İletişimdemirakin.tr@gmail.com
02Veriler
Sitenin işlediği veriler
Ziyaret ve toplu trafik ölçümü
Vercel Web Analytics; olay zamanı, ziyaret edilen URL veya yol, filtrelenmiş sorgu parametreleri, yönlendiren site, yaklaşık coğrafi konum, cihaz türü, işletim sistemi ve tarayıcı bilgileri ile Analytics betiğinin sürümünü kaydedebilir. Vercel, bu ölçüm noktalarının anonim olduğunu ve kişi, müşteri veya IP adresiyle ilişkilendirilmediğini; gelen isteğe dayalı ziyaretçi özetinin 24 saat sonra silindiğini belirtir.
Dil tercihi
Portfolyo, EN/TR seçiminizi tarayıcınızdaki localStorage alanında saklar. Bu değer, site verilerini temizleyene kadar cihazınızda kalır ve portfolyonun kendi kodu tarafından başka bir yere gönderilmez.
Doğrudan yazışma
Sitede iletişim formu yoktur. E-posta göndermeyi seçerseniz adresiniz, adınız, mesajınız ve eklediğiniz dosyalar; seçtiğiniz e-posta hizmeti ve alıcı posta kutusu üzerinden yalnızca bu yazışma kapsamında işlenir.
Site reklam veya pazarlama çerezi kullanmaz. Vercel Web Analytics çerezsizdir; dil tercihi ise çerez değil, tarayıcıdaki yerel depolama alanıdır.
03Amaç
Amaçlar ve hukuki sebepler
- Portfolyoyu sunmak, işletmek ve korumak; toplam trafik eğilimlerini anlamak ve siteyi geliştirmek.
- Göndermeyi seçtiğiniz mesajlara cevap vermek ve gerektiğinde bir fırsat veya profesyonel taleple bağlantılı adımları yürütmek.
Toplama yöntemi
Ziyaret bilgileri, site açıldığında barındırma ve Analytics altyapısı üzerinden elektronik ortamda otomatik yollarla toplanır. Dil tercihi, EN veya TR seçtiğinizde cihazınızda oluşturulur. Yazışma verileri ise yalnızca e-posta göndermeniz hâlinde doğrudan sizden elde edilir.
Bu faaliyetler, duruma göre 6698 sayılı Kişisel Verilerin Korunması Kanunu'nun 5'inci maddesinde yer alan; sözleşmenin kurulması veya ifasıyla doğrudan ilgili olma, bir hakkın tesisi, kullanılması veya korunması ve temel hak ve özgürlüklerinize zarar vermemek kaydıyla veri sorumlusunun meşru menfaati hukuki sebeplerine dayanır (KVKK md. 5/2(c), (e) ve (f)). Açık rıza gerektirmeyen bir amaç için rıza talep edilmez.
04Aktarım
Hizmet sağlayıcılar ve yurt dışı işleme
Teknik ziyaret verileri; barındırma, güvenlik ve toplu trafik ölçümü amacıyla Vercel, Inc. ve hizmet sağlayıcıları tarafından işlenir. Vercel, ABD merkezli bir sağlayıcıdır ve hizmetlerin ABD'de ve kendisinin veya alt işleyenlerinin faaliyet gösterdiği diğer ülkelerde işlenebileceğini belirtir. Bu nedenle teknik veriler, uygulanabilir aktarım kuralları ve güvenceler çerçevesinde Türkiye dışında işlenebilir.
E-posta yazışmaları sizin ve alıcının kullandığı e-posta hizmetleri üzerinden işlenir. LinkedIn ve Instagram'a yalnızca bu dış hizmetleri açmayı seçtiğinizde veri iletilir; portfolyo içine sosyal medya içeriği veya takip bileşeni gömülmemiştir.
05Saklama
Verilerin saklandığı süre
Vercel, gelen isteğe dayalı ziyaretçi oturumu özetini 24 saat sonra siler. Toplu Analytics kayıtları Vercel'in güncel hizmet ve raporlama koşullarına göre saklanır. Dil tercihi, site verilerini temizleyene kadar cihazınızda kalır. Yazışmalar; cevap vermek, gerekli kayıtları tutmak veya bir hakkı korumak için gereken süreyle sınırlı olarak saklanır; bu amaçlar sona erdiğinde silinir veya anonim hâle getirilir.
06Haklarınız
KVKK 11'inci madde
Kişisel verilerinizin işlenip işlenmediğini öğrenme; işlenmişse bilgi isteme; işleme amacını, amaca uygun kullanılıp kullanılmadığını ve aktarılan kişileri öğrenme; şartları varsa düzeltme, silme veya yok etme ve bu işlemlerin alıcılara bildirilmesini isteme; yalnızca otomatik analiz sonucunda aleyhinize bir durum oluşmasına itiraz etme ve hukuka aykırı işleme nedeniyle doğan zararın giderilmesini talep etme haklarına sahipsiniz.
Talebinizi, ilgili etkileşimi ve kullanmak istediğiniz hakkı belirlemeye yetecek bilgiyle demirakin.tr@gmail.com adresine iletebilirsiniz.
Yürürlük / 19 Temmuz 2026demirakin.com · gizlilik / veri
American Football /
Koç Rams
Number 6 · Koç Rams
Koç Rams.
Koç Rams became one of the turning points of my life. It came to represent much of my university experience, carrying dozens of friendships and hundreds of memories with it.
Through Rams, I learned what it means to win and lose together, to fight for someone else and to know that others will fight for you in return. Our football field gradually became a second home, while my teammates became brothers of different ages. They stood beside me during difficult periods, celebrated a championship with me and gave me friendships I intend to carry throughout my life.
My Rams career began during my first year at university. In my third month, however, a shoulder dislocation forced me away from the field. I returned after two to three months of recovery and physiotherapy, only to dislocate the same shoulder again two weeks later.
When I eventually returned, I decided to continue on offense as a receiver after beginning my career on defense. During the 2024–25 season, I earned occasional playing time. In the final quarter of an away game against the Gazi Warriors, I scored a touchdown that remains unforgettable to me.
That moment made every injury, disappointment, period of self-doubt and exhausting day feel worthwhile. Yet the most valuable thing Rams gave me was never limited to what happened on the field. Its lasting legacy is the people I want to keep in my life and the memories we created together.
In short: I am grateful to be a Ram.
Koç Rams.
Koç Rams, hayatımdaki dönüm noktalarından biri oldu. Üniversite yıllarımın büyük bölümüne ait anıların, onlarca arkadaşlığın ve yüzlerce güzel anın taşıyıcısı hâline geldi.
Rams’te birlikte kazanmayı ve kaybetmeyi; biri için mücadele etmeyi ve gerektiğinde birilerinin de senin için mücadele edeceğini bilmeyi öğrendim. Futbol sahamız zamanla benim için ikinci bir eve, takım arkadaşlarım ise abilerime ve kardeşlerime dönüştü. Zor zamanlarımda yanımda oldular, birlikte şampiyonluk kutladık ve hayatım boyunca sürdürmek istediğim dostluklar kurduk.
Rams kariyerim üniversitedeki ilk yılımda başladı. Ancak üçüncü ayımda yaşadığım ilk omuz çıkığı nedeniyle sahalardan uzaklaşmak zorunda kaldım. İki ila üç aylık bekleme ve fizyoterapi sürecinin ardından geri döndüm; fakat dönüşümden yalnızca iki hafta sonra omzum yeniden çıktı.
İkinci sakatlığın ardından sahaya tekrar döndüğümde, savunmada başlayan kariyerimi hücumda receiver olarak sürdürmeye karar verdim. 2024–25 sezonunda zaman zaman forma şansı buldum. Gazi Warriors deplasmanının son çeyreğinde yaptığım touchdown ise benim için unutulmaz bir an oldu.
O an; yaşadığım sakatlıklara, hayal kırıklıklarına, kendimi yetersiz hissettiğim dönemlere ve bütün yorgunluğa değdi. Ancak Rams’in bana kazandırdığı en değerli şey hiçbir zaman yalnızca sahadaki başarılar olmadı. Asıl kazancım, ömür boyu hayatımda tutmak istediğim insanlar ve birlikte oluşturduğumuz anılar oldu.
Kısacası: iyi ki Rams.