top of page

Hitomi Kazası: Emniyet-Kritik Yazılım ve Sistem Tasarımına Dair Dersler

  • Yazarın fotoğrafı: Umut Pisken
    Umut Pisken
  • 37 dakika önce
  • 7 dakikada okunur

Japon Uzay Keşif Ajansı (Japan Aerospace Exploration Agency – JAXA) tarafından evrendeki enerji değişim süreçlerini incelemek üzere tasarlanmış olan Hitomi (ASTRO-H) isimli uydu 17 Şubat 2016 tarihinde 3 yıl sürmesi planlanan görevini icra etmek üzere uzaya gönderilmiştir. Ancak uydunun tasarımı esnasında sistem ve yazılım seviyesinde yapılan hatalar sebebiyle Hitomi (ASTRO-H) uydusu sadece 37 gün görev yapabilmiş ve 26 Mart 2016 tarihinde kontrolden çıkıp parçalanmıştır.  286 milyon dolara üretilmiş olan uydunun erken sürede kaybı, bilimsel açıdan yapılması planlanan çalışmaları sekteye uğratmıştır [1].


26 Mart 2016 tarihinde Japonya saati ile sabah saat 03:01’de Hitomi uydusu önceden planlandığı şekilde Markarian 205 galaksisini gözlemlemek üzere manevra yapmaya başlamıştır [2]. Manevra esnasında Hitomi uydusu uzaydaki yönelimini tespit etmek için normal şartlarda kullandığı yıldız takipçisi (star tracker-STT) sistemindeki bir problem sebebiyle, yönelim bilgilerini jiroskoplar aracılığı ile hesaplamaya çalışmıştır.  Ancak, Hitomi uydusu gerçekte dönmemesine rağmen, hatalı bir hesaplama nedeniyle uydunun 21 derece/saat açısal hızla döndüğü hesaplanmıştır [2]. Bunun üzerine uydunun dönüş hızını düşürmek için tepki çarkı (reaction wheel) sistemindeki motorlar devreye girmiş ve ters yönde güç uygulayarak dönüşü yavaşlatmaya çalışmıştır [2]. Uydu gerçekte dönmediği hâlde, uygulanan kontrol eylemi uydunun kendi ekseni etrafında dönmeye başlamasına neden olmuştur. Uydu bu yanlış hesaplama sebebiyle başlayan dönüş hareketini durdurmak için yapılan işlem sonucunda daha da hızlı dönmeye başlamıştır. Dönüş hızı belirli seviyenin üzerine çıkınca, Japonya saati ile sabaha karşı saat 04:10’da uydu sistemleri güvenli bekleme moduna (Safe Hold) geçmiş ve bu tip durumlarda son çare olarak kullanılan iticiler (thrusters) ateşlenerek dönüş hızı yavaşlatılmaya başlanmıştır. Burada ise bu işlem esnasında hesaplamalarda kullanılan yazılım parametrelerinin yanlış yüklenmiş olması sebebi ile uydu iticilerin ateşlenmesinin ardından uydu daha da hızlanmış ve dönüş hızının uydunun tasarım limitlerinin üzerine çıkması sonucunda başta uydunun güneş panelleri olmak üzere uydu parçalanmaya başlamıştır [2]. Olayların olduğu esnada uydu Japonya açısından dünyanın diğer tarafında kaldığı için, JAXA tarafından gerçek zamanlı müdahale girişimleri de başarısız olmuş ve uydu kontrolden çıkıp parçalanmıştır [2].


Hitomi uydusunun yönelim tespit etme mekanizması, atalet referans birimi (Inertial Reference Unit) ile yıldız takipçisinden (star tracker-STT) gelen verileri kalman filtresine sokarak yönelim hesaplayacak şekilde tasarlanmıştı [3]. Atalet referans birimi (Inertial Reference Unit-IRU) uydu üzerinde yer alan jiroskoplardan gelen verileri kullanıp hesaplama yaparken, yıldız takipçisi (star tracker-STT) ise uzaydaki yıldızlar ve güneşi optik sistemleri aracılığıyla algılayarak bir hesaplama yapıyordu [3]. Yıldız takipçisinden (star tracker-STT) geçerli veri gelmemesi veya yıldız takipçisinin (star tracker-STT) hesapladığı yönelim değeri ile atalet referans birimi (IRU) hesaplamaları arasında 1 dereceden fazla fark olması durumlarında, sadece atalet referans birimi (IRU) hesaplamaları kullanılarak uydunun yönelimi belirleniyordu [3]. Ayrıca Yıldız takipçisinden (star tracker-STT) sağlıklı veri geldiği durumlarda, yıldız takipçisi (star tracker-STT) ile atalet referans birimi (IRU) arasındaki fark düzenli olarak kaydediliyor ve bu verinin eğilimine bakılarak bir sapma oranı değeri tahmin ediliyordu. Bu sapma oranı değeri, sadece atalet referans birimi (IRU) ile hesaplama yapıldığı durumlarda hesaplanan değere uygulanarak gerçeğe en yakın yönelim değeri bulunmaya çalışılıyordu [3].


Kazaya Yol Açan Ana Etkenler

JAXA’nın olay sonrası gerçekleştirdiği analiz sonucunda, uydunun kaybına yol açan 4 ana etken tespit edilmiştir [3]:

  1. Yıldız Takipçisi (star tracker-STT) Davranışı: Olayın başlangıcı esnasında yıldız takipçisi (star tracker-STT) sisteminin bir şekilde hesaplama yapamadığı ve bu sebeple hesaplamaların sadece atalet referans birimi (IRU) tarafından yapıldığı tespit edilmiştir.


  2. Yönelim ve Yörünge Kontrol Sistemindeki Tasarım Hataları: Yönelim ve Yörünge Kontrol Sistemi (Attitude and Orbit Control System – AOCS) tasarımı gereği, uydunun gözlem amaçlı yaptığı manevraların bitiminde, yönelim hesaplamakta kullanılan Kalman filtresi sıfırlanmakta ve bu işlem sonrasında, sapma oranı yüksek bir ilk değere atanarak hesaplamalar yeniden başlamaktaydı. Kalman filtresi sıfırlanması sonrasında yüksek sapma değeri atanması, sistemin belirsizlik değerini artırarak daha hızlı yakınsama sağlamayı amaçlıyordu. Bu tasarımda, Kalman filtresi sıfırlanması sonrasında, Yıldız Takipçisinden (star tracker-STT) gelecek sağlıklı veriler ile kısa sürede sapma oranı değerinin ilk başta varsayılan olarak atanan yüksek sapma değerinden normal değerlere dönmesi amaçlanıyordu. Hitomi uydusunun aktif olduğu 37 gün boyunca bu senaryo çeşitli kereler oluşmuş ve herhangi bir soruna yol açmayıp tasarlandığı şekilde çalışmıştı. Ancak olayın yaşandığı gün, Kalman filtresinin sıfırlanması sonrasında Yıldız Takipçisinden (star tracker-STT) geçerli veriler gelmediği için, sapma oranı ilk atanan varsayılan yüksek değerinde kalmıştı.

    Sistem tasarımındaki bir diğer problem ise, Hitomi uydusu üzerinde birden fazla Yıldız Takipçisi (star tracker-STT) bulunmasına rağmen, bunlar yedekli (redundant) değil yalnızca yedek (backup) olarak kullanılmaktaydı.  Bu tasarımda, sadece aktif Yıldız Takipçisinden (star tracker-STT) gelen veri, yönelim hesaplamalarında kullanılmakta ve bu veri geçersiz geldiği durumda diğer Yıldız Takipçi (star tracker-STT) sistemlerinden veri almaya çalışmak yerine sadece IRU sisteminden gelen değerler kullanılarak hesaplama yapılıyordu. Bu tasarımın altında yatan mantığa göre, IRU sistemleri zaten yönelim değerini hesaplarken büyük hata yapmıyordu, dolayısıyla Yıldız Takipçisinden (star tracker-STT) veri gelmese bile gerçeğe yakın bir yönelim değeri hesaplanabiliyordu. Ancak olay esnasında, Kalman filtresi sıfırlanması mekanizmasından dolayı yüksek sapma değeri düzeltilemeyerek hesaplamalara devam edildiği için, Hitomi uydusu dönmediği halde, 21 derece/saat hızla dönüyor şeklinde yönelim değeri hesaplaması yapılmıştır. Son olarak Yıldız Takipçisinden (star tracker-STT) gelen değerler ile IRU sisteminin hesapladığı değerler arasında 1 dereceden fazla fark olması durumunda da, yukarıda anlatılan mantık gereği, Yıldız Takipçisinden (star tracker-STT) gelen değer dikkate alınmamakta ve gene IRU sistemi ile hesaplamalara devam edilmekteydi. Bu sebeple olayın olduğu gün, önce Yıldız Takipçisinden (star tracker-STT) geçerli veri gelmediği ve Kalman filtresinin sıfırlanması sonucu kullanılan yüksek sapma oranı sebebiyle IRU hesaplamaları aşırı derecede sapmış, ardından Yıldız Takipçisi (star tracker-STT) tekrar geçerli veri göndermeye başladığında ise, IRU sistemindeki değer ile arasındaki fark 1 dereceden fazla olduğu için, Yıldız Takipçisinden (star tracker-STT) gelen veriler dikkate alınmadan yanlış yönelim değeri kullanılmaya devam edilmiştir. Olay esnasında uydunun yönelimi hesaplanırken gerçekleşen alt olaylar aşağıdaki şekilde verilmiştir.


    Hitomi Yönelim Hesaplaması Olay Dizisi

    Hitomi Yönelim Hesaplaması Olay Dizisi


  3. Hata Tespiti, Yalıtımı ve Yeniden Yapılandırma Sistemi Tasarım Hatası: Yanlış hesaplanan yönelim verisi sonucunda, Hitomi uydusu üzerindeki sistemler, uydunun 21 derece/saat açısal hız ile döndüğünü varsaymış; bu varsayıma bağlı olarak devreye giren kontrol eylemleri ise uydunun fiilen dönmeye başlamasına neden olmuştur. Hitomi uydusu dönmeye başladığında, Güneş Paneli Kanatları güneşe doğru bakmamaya başlamıştı. Dolayısıyla bu bilgiden hareketle, uydunun yöneliminin planlanandan farklı olduğu anlaşılabilirdi. Ancak uydunun Hata Tespiti, Yalıtımı ve Yeniden Yapılandırma Sistemi’nin (Fault Detection, Isolation and Recovery System- FDIR) tasarımında bunun kontrolüne yönelik bir mekanizma kurgulanmadığı için uydu güvenli bekleme moduna geçmemiştir. Uydu üzerinde bulunan Düşük Hassasiyetli Güneş Yönelim Sensörlerinden (Coarse Sun Aspect Sensor (CSAS)) gelen açı bilgisinin 41 dereceden büyük olması durumunda, otomatik olarak güvenli bekleme moduna geçilecek şekilde bir tasarım yapılmış olsaydı, uydunun dönüş hızının tehlikeli seviyelere gelmeden düzeleceği JAXA tarafından değerlendirilmiştir [3]. Uydunun tasarımında, gözlem sürelerini azami seviyede tutmak adına bilerek bu tip bir tasarıma gidildiği JAXA raporunda anlatılmaktadır. Raporda Düşük Hassasiyetli Güneş Yönelim Sensörlerinden (Coarse Sun Aspect Sensor (CSAS)) gelen açı bilgisinin yer operatörlerine iletildiği ve onların bu bilgiden hareketle gerekli işlemleri (güvenli bekleme moduna geçme gibi) yapmasının beklenildiği belirtilmiştir. Ancak olayın gerçekleştiği esnasında uydunun konumu sebebiyle yerden hızlı müdahale edilmesi mümkün olmamıştır.


  4. Yazılımda Yanlış Parametre Yüklenmesi: Uydu üzerinde bulunan Uzatılabilir Optik Platform’un (Extensible Optical Bench (EOB)) 25 Şubat 2016 tarihinde devreye alınmasıyla birlikte, uydu üzerindeki iticilere ait parametre değerlerinin güncellenmesi gerekmiştir. JAXA bu tip operasyonel destek işleri için bir altyüklenici firma ile anlaşmıştı. Altyüklenici firma parametre güncelleme işlemini yapmaya başladığında, bu işlemin nasıl yapılacağına ilişkin bir prosedür(hangi parametreler ne şekilde değiştirilmeli) JAXA tarafından altyüklenici firmaya iletilmemişti. Altyüklenici firma itici parametrelerini yanlış şekilde hesaplayıp, iş yoğunluğu sebebiyle gerekli doğrulamaları yapmadan parametrelerin hazır olduğu bilgisini JAXA’ya iletmişti. JAXA ise parametrelere ilişkin doğrulamaların yapılıp yapılmadığını kontrol etmeden, altyüklenici firmaya parametreleri uyduya yükleyebileceği bilgisini verdikten sonra, yanlış parametreler uyduya yüklendi. JAXA’nın kazaya ilişkin raporuna göre, hesaplanan bazı parametre değerlerinin negatif değer olsa bile mutlak değer şeklinde sisteme aktarılması gerektiği, ancak altyüklenici firmanın bir prosedür olmadığı için bu bilgiye sahip olmadığı ve negatif değerleri aynen uyduya aktardığı bilgisi mevcuttur [3]. Ayrıca altyüklenici firma yoğunluk sebebiyle hesapladığı parametre değerlerini simülatörler üzerinde doğrulamamıştır. JAXA bu işlemin yapılıp yapılmadığını kontrol etmediği için, hatalı parametreler uyduya gönderilmiştir. Parametreler uydunun dönüşünü yavaşlatmak için ters yönde verilecek itici gücünü hesaplamakta kullanıldıkları için, değerlerin negatif olarak verilmesi, iticilerin dönüş ile aynı yönde kuvvet vermesi ve uydunun dönüşünün daha da hızlanması ile sonuçlanmıştır.

 

Sonuç

Hitomi uydusu, yıldız takipçisi (star tracker-STT) sistemindeki bir problem sebebiyle başlayan olaylar zinciri sonucunda kaybedilmiştir. Hitomi kazası emniyet-kritik ve görev-kritik sistemlerin tasarımları ve işletilmesi esnasında nelere dikkat edilmesi gerektiğine yönelik çok önemli dersler içermektedir. Yukarıda listelenen dört ana etkenden herhangi birinin etkisi ortadan kaldırılabilmiş olsaydı, Hitomi uydusu kaybedilmemiş olacaktı. Bu olay, emniyet-kritik ve görev-kritik sistemlerin tasarımında yalnızca normal durum çalışma senaryolarının değil, hatalı varsayımlar ve beklenmeyen sistem davranışlarının da bütüncül bir yaklaşımla ele alınması gerektiğini açık biçimde göstermektedir. Sistemlerin tasarımında, olası hata senaryolarının tüm yönleriyle ele alınması ve sistem ile yazılım testleri esnasında bu durumların oluşturularak sistemin hata durumlarında bile emniyetli davranış sergileyip sergilemediğinin değerlendirilmesi gerekmektedir.


Kazanın bir diğer önemli boyutu, yazılım parametrelerinin yazılım ve sistem emniyeti açısından kaynak kod kadar kritik olduğunu gösteriyor olmasıdır. Parametre güncelleme sürecinde tanımlı prosedürlerin bulunmaması, doğrulama ve simülasyon adımlarının atlanması ve üstlenici-altyüklenici arasındaki sorumluluk sınırlarının net çizilmemesi, uydunun kontrolsüz dönüşünü durdurmak üzere devreye giren iticilerin ters yönde tepki vermesine neden olmuştur. Bu durum, emniyet-kritik sistemlerde operasyonel süreçlerin de en az yazılım geliştirme süreci kadar disiplinli ve izlenebilir olması gerektiğini ortaya koymaktadır.


Altyüklenici firmalar ile çalışılırken, üst yüklenicinin alan bilgisi sebebiyle açık olduğunu düşündüğü konularda bile, gerekli prosedürlerin detaylı şekilde altyüklenicilere iletilmesi gerekmektedir. Benzer şekilde altyükleniciden gelen çıktıların olgunluğuna, gerekli doğrulamaların yapılıp yapılmadığına dair kontrollerin gerekli süreç altyapısı kurularak atlanmadan yapılması şarttır.  Kaza raporunda altyüklenici firmanın “iş yoğunluğu sebebiyle” gerekli yazılım doğrulama aktivitelerini tam olarak yapmadığı belirtilmiştir. Bu ifade, emniyet-kritik sistem geliştirmede tehlikeli bir durum olan zaman baskısı altında emniyet gerekliliklerinden taviz verilmesine işaret etmektedir.


Hitomi kaza raporunun yayınlanmasının ardından, Institute of Space and Astronautical Science (ISAS) direktörü Saku Tsuneta'nın yaptığı basın açıklamasında yer alan “En temel ve açık gerekliliklerin dahi yeterince yerine getirilmediği görülmüştür ( The simplest and most obvious things were not done properly")” ifadesi aslında olayın bir özeti niteliğindedir [4]. Projelerin temposu içerisinde, olay sonrasında bariz hâle gelen bu tür hatalar çoğu zaman gözden kaçabilmektedir. Hitomi kazası, emniyet-kritik ve görev-kritik sistemler geliştiren tüm ekipler için, teknik doğruluğun yanında süreç olgunluğu, açık sorumluluk tanımları ve yerleşik bir emniyet kültürünün vazgeçilmez olduğunu güçlü biçimde ortaya koymuştur.


Kaynaklar:

  1. Klein, A. (29 Nisan 2016). “Japanese satellite's death spiral linked to software malfunction”, NewScientist. https://www.newscientist.com/article/2086422-japanese-satellites-death-spiral-linked-to-software-malfunction/  (Erişim Tarihi: 16 Aralık 2025)

  2. Witze, A. (29 Nisan 2016). Software Error Doomed Japanese Hitomi Spacecraft”, ScientificAmerican. https://www.scientificamerican.com/article/software-error-doomed-japanese-hitomi-spacecraft/  (Erişim Tarihi: 18 Aralık 2025)

  3. JAXA, “Hitomi Experience Report: Investigation of Anomalies Affecting the X-Ray Astronomy Satellite Hitomi (ASTRO-H)”, 31 Mayıs 2016.

  4. JAXA,  “Moving beyond the loss of X-Ray astronomy satellite ASTRO-H (Hitomi)”, https://www.isas.jaxa.jp/en/about/dgs_saku_tsuneta/files/ASTRO-H_fromDirector.pdf (Erişim Tarihi: 12 Şubat 2026)


 
 
 

Yorumlar


Copyright © Mehmet Umut Pişken | 2026 © HER HAKKI SAKLIDIR

bottom of page