S4000P Sürüm 2.2 ve Sürüm 3.0 Karşılaştırması

Nisan 2023'te yayımlanan S4000P 2.2 sürümünün son güncellemesi 28 Mayıs 2024 tarihinde gerçekleştirilmiştir. S4000P 2.1 sürümüne göre idari bir güncelleme olan 2.2 sürümü, telif haklarındaki değişiklikleri yansıtacak şekilde güncellenmiştir. 

S4000P 3.0 sürümü, 7 Aralık 2025 tarihinden itibaren S-Serisi resmi internet sitesinde (www.s-series.org) yayımlanmaya başlanmıştır. S4000P 3.0 sürümü; mevcut süreçlerde yapılan iyileştirmeler ve birkaç bölümde yeni içerik eklenmesinin bir sonucudur. Ayrıca, S4000P veri modeli, SX002D'de belgelenen S-Serisi IPS Özelliklerinin ortak veri modeliyle uyumlu olarak tanıtılmıştır. 

Yapılan değişiklik ile S4000P spesifikasyonunda yaklaşık 450 sayfalık bir hacim artışı sağlanarak önemli güncellemeler gerçekleştirilmiştir.  

TEKNİK VE EDİTORYAL DEĞİŞİKLİKLER 

Teknik ve editoryal değişiklikler bu S4000P 3.0 sayısında işaretlenmemiştir. Herhangi bir editoryal değişiklik öne çıkan sayfalarda belirtilmemiştir. 

Aşağıdaki genel değişiklikler yapılmıştır: 

• “Operatör” veya “müşteri” yerine, “Kullanıcı” kelimesinin kullanılması tutarlı bir şekilde kullanılması 

• Önleyici Bakım Planının tutarlı kullanımı ve Operatör Bakım Planının kaldırılması 

• Proje gereksinimleri yerine ürün geliştirmeye odaklanılması vurgulandı. 

• Uygulanabilir yerlerde “scheduled” yerine “preventive” kullanıldı. 

• Mantık şemaları, düzeni standart hale getirmek için yeniden çizildi. 

• Belirtilen ürünlerin logoları yeni logolarla değiştirildi. 

S4000P 3.0 sürümü ile birlikte;  

BÖLÜMLER 

BÖLÜM 1- SPESİFİKASYONA GİRİŞ 

Ek yayıncı olarak AIA eklendiği vurgulanmıştır.  

• Bölüm 1, 1.1 Para 1.2 içerisinde; S4000P’nin her sürüm içeriği, Avrupa’nın çeşitli sanayi kollarından ve ürün müşterilerinden uzmanlar tarafından hazırlanmıştır. Her belge sayısının S1000D kurallarına göre son bir editoryal kontrolünden sonra, ASD ve AIA spesifikasyonu yayımlamaya karar vermiştir. 

Yönlendirme Komitesi (Yönetim Kurulu) yerine “Önleyici Bakım İnceleme Kurulu”nun yer alması vurgulanmıştır.  

• Bölüm 2, 2.6 Para 1 Not 2 içerisinde; Önleyici Bakım İnceleme Kurulu (PMRB), bazen Yönlendirme Komitesi (SC) veya Sertifikasyon Komitesi (CC) olarak da bilinir. PMRB, sistem bütünleyiciden ve uygulanabilir olduğu durumlarda herhangi bir OEM, yetkili makam ve/veya kullanıcı temsilcisinden oluşur. PMRB üyeleri PPH'de tanımlanmıştır. Rollerin ve sorumlulukların dağılımı ürün türüne göre tanımlanmalı ve PPH'de belgelenmelidir.  

Öngörücü bakım dahil edildi. 

• Bölüm 1, 1.2 Para 1 içerisinde; PMTR geliştirilmesinde öngörücü bakımın entegrasyonu açıklamasıyla öngörücü bakım dahil edildi. 

PMRB'nin rolü vurgulandı. 

• Bölüm 1, 1.3 Para 1.1 içerisinde; PMRB’nin (Preventive Maintenance Review Board – Önleyici Bakım İnceleme Kurulu) sorumlulukları şunları içerir, ancak bunlarla sınırlı değildir: 

• Bir ürünün önleyici bakımı için genel yönetişimi sağlamak ve hem politika hem de başlangıç hedeflerini belirlemek 
  − Analiz çalışma grubu faaliyetlerine yön vermek 
  − Gerekli durumlarda üreticiler ve işletmeciler ile iletişim kurmak 
  − Araştırma ve/veya test kurumlarıyla temaslar kurmak 
  − Nihai önerileri hazırlamak 
  − PMTR geliştirme ve/veya PMTR optimizasyonu için ürün spesifikasyonunun tüm ürün (sistemler, yapılar ve bölgeler) üzerinde uygulanmasını sağlamak 
  − Ürünün önleyici bakımıyla ilgili girdileri koordine etmek 
  − Artık risklerin kabulünü sağlamak 
  − Üst düzey program kararlarını almak 

Analiz sonuçlarını kabul etmeden önce gözden geçirme uyarısı eklendi. 

• Bölüm 1, 1.3 Para 1.1 içerisinde; Benzer sistemlerden elde edilen bilgi ve analiz sonuçları her zaman gözden geçirilmelidir ve uygulanabilirlik ve etkinlik açısından bir inceleme yapılmadan asla kabul edilmemelidir, çünkü kullanım koşulları aynı olmayabilir ve daha da önemlisi, Üründeki çeşitli sistemler arasındaki, Ürünler ile bu Ürünlerin ortamları arasındaki etkileşim farklı olabilir ve bu da farklı arıza mekanizmalarına yol açabilir. 

BÖLÜM 2-PMTR GELİŞTİRME 

Entegre bir tasarım çalışması ihtiyacını vurguladı. 

• Bölüm 2, 2.2 Para 1 içerisinde; PMTR, tasarım gereksinimleri ve kısıtlamaları doğrultusunda geliştirilmelidir; bu, bakım stratejisi ve ilgili yaşam döngüsü maliyetleri (LCC) üzerinde etkisi olan tasarım ve sürdürülebilirlik çabalarının her paydaşından gelen kısıtlamaları da içerir. 

İzlenebilir bir karar sürecine duyulan ihtiyacı vurguladı. 

• Bölüm 2, 2.2 Para 1 içerisinde; Bir ürün için PMTR’ler, tasarım gereksinimleri ve kısıtlamalar doğrultusunda geliştirilir ve bakım stratejisi ile yaşam döngüsü maliyetlerini etkileyen paydaş kısıtlamalarını içerir. Gereksinimlerin dengelenmesi ve takas yapılması, farklı bilgi alanları arasında izlenebilir değişimler ve geri bildirim döngüleri gerektirir. Analiz sırasında ortaya çıkan sorunların çözümü için etkili bir karar süreci uygulanmalıdır. 

Bir ürün montajlanmadığında parçaların konfigürasyon yönetimi, tanımlanması ve izlenebilirliğine olan ihtiyaç vurgulandı. 

• Bölüm 2, 2.2 Para 1 içerisinde; Üründen çeşitli nedenlerle parçalar çıkarılabilir ve başka ürünlere takılabilir. Ürün, daha sonra bir sistemler sistemi veya Ürünler Ürünü haline gelir ve bu, tüm ilgili paydaşların konfigürasyon tanımlama ve izleme süreçleri tarafından desteklenmelidir. Bu nedenle, parçanın takılı olmadığında ve arızalanmış olabileceğinde tanımlanabilmesi mümkün olmalıdır. Bir parçayı farklı bir ürüne yeniden takabilmek için bakım ve kullanım geçmişi (ölçümler dahil) mevcut olmalıdır, bu da konfigürasyon yönetimi ve parça tanımlamaya ek gereksinimler getirir. Taraflar arasında bilgi alışverişini yönetme süreçleri de Ürün tasarım faaliyetlerinin bir parçasıdır. Yukarıda açıklanan süreç, Ürün gereksinimlerine göre uyarlanmalıdır. Tüm analiz türleri tüm Ürünler için geçerli değildir. 

Yeniden yapılandırılmış bakım stratejileri eklendi. 

• Bölüm 2, 2.2 Para 1.2 içerisinde; Bakım stratejisi, tüm ürün veya ürünün belirli sistemleri, yapısal elemanları ya da bölgeleri için tanımlanabilir. Analitik yöntemlerle belirlenen PMTR’ler, ürünün hizmet ömrü boyunca uygulanması gereken asgari önleyici bakım görevlerini oluşturur. PMTR’ler, PMTL/CMR gibi bakım kısıtları ve özel durumlara ait gereklilikler bir araya getirilerek Önleyici Bakım Programı oluşturulur. Bu program, ürün kullanım süresince edinilen saha tecrübelerine bağlı olarak güncellenebilir. 

PHCM ve SHCM, bir ürünün önleyici bakım stratejisini desteklemek amacıyla ek araçlar olarak kullanılabilir. Olası bozulmaları veya yaklaşan fonksiyonel arızaları tespit etmek için çok sayıda verinin toplanması cazip görünsede, deneyimler rastgele veri toplamanın genellikle maliyet ve emek açısından yeterli fayda sağlamadığını göstermektedir. Ayrıca, geleneksel bakım yöntemlerinin PHCM ve SHCM ile tamamen ikame edilmesi oldukça zordur; bu nedenle bu sistemler daha çok mevcut bakım yaklaşımlarını tamamlayıcı niteliktedir. 

Planlı bakım, Duruma dayalı bakım, Öngörücü bakım, Ürün Sağlığı ve Durum İzleme / Yapı Sağlığı ve Durum İzleme ve Özel olaylar hakkında açıklamalar eklenmiştir. 

Öngörücü bakım ve kısıtlamalar eklendi. 

• Bölüm 2, 2.2 Para 1.2.3 içerisinde; Duruma dayalı bakım (CBM), ekipmandaki bozulma parametrelerini izleyerek uyarlanabilir aralıklarla yapılır. Öngörücü bakım ise CBM’nin bir uzantısı olarak sabit aralık olmaksızın arızaya yönelik eğilimleri ölçüm ve gözlemlerle izleyip, arızanın olasılık ve zamanını öngörür. Başarılı uygulanabilmesi için ürünün teknik durumu, kullanım geçmişi ve planlanan kullanımı iyi bilinmeli, kullanım senaryosu tutarlı olmalı ve bakım planındaki değişiklikler belgelenmiş analizlere dayanmalıdır. Ayrıca, ölçüm verilerinin kaliteli ve izlenebilir şekilde yönetildiği kontrollü bir geri besleme süreci kurulmalı ve öngörücü bakımın kullanımı yetkili otoritelerce kabul edilmelidir. 
  Öngörücü bakım için yeterli veri yoksa, sabit aralıklı bakım stratejisi uygulanabilir ve aralıklar ile sınırlar S4000P sonuçlarına göre belirlenir.  

Karmaşık teknik ürünlerde tüm önleyici bakım görevleri CBM veya öngörücü bakım ile yapılamaz; detaylı muayene ve karmaşık testler zor uygulanırken, servis ve değiştirme gibi görevler genellikle daha kolay uygulanır. 

Sensörlerin kullanımı ve sensör verileri hakkında ek bilgiler eklendi. 

• Bölüm 2, 2.2 Para 1.2.2 içerisinde; S5000F, farklı tarafların bağlantısı kesik sistemleri arasında bilgi alışverişi sağlamak için bir mekanizma sunar. Ölçümler, sensör verilerinden (ör. sıcaklık veya titreşim ölçümleri) oluşabileceği gibi, manuel ölçümlerden (ör. bir fren diskinin kalınlığı) veya analizlerden (ör. yağ kirlilik ölçümü) de oluşabilir. 

• Bölüm 2, 2.2 Para 1.2.4 içerisinde; Bir ürün içinde veya ürünle ilgili sistemlerde sensör ve yazılım kullanımı, önleyici bakımın doğru zamanda yapılmasını belirlemek için ek olanaklar sağlar.  

PHCM ve SHCM kullanımından dolayı, tasarım değişiklikleri yalnızca Ürün sistemi, yapısı veya bölgesinin yeniden tasarımı ile sınırlı değildir ve yalnızca PMTR yürütülmesini sağlamak için erişimi geliştirmekle sınırlı değildir. PHCM/SHCM için ek sensörlerin, kameraların vb. entegrasyonu da (yeniden) tasarım seçenekleri arasındadır. Sensörler, arıza nedenlerinin altında yatan bozulma mekanizmalarına uygun şekilde seçilmelidir. Sensörler ayrıca bozulmayı gösteren belirtileri tespit etmek için de kullanılabilir. 

Çoğu analiz çalışmasının SRR ile PDR arasında yapıldığına vurgu yaptı. 

• Bölüm 2, 2.2 Para 1.5 içerisinde; Uygulanabilir ve/veya etkili bir PMTR tespit edilmezse, sorumlu mühendislik departmanlarına geri bildirimde bulunulması, çoğu analiz faaliyetinin Sistem Gereksinimleri İncelemesi (SRR) ile Ön Tasarım İncelemesi (PDR) arasında gerçekleşmesine rağmen, Kritik Tasarım İncelemesi (CDR) gerçekleşmeden önce en geç yapılması esastır. 

Tanımlanmış temeller (baselines) üzerinde gerçekleştirilen gereksinim odaklı analiz faaliyetleri hakkında açıklama eklendi. 

• Bölüm 2, 2.2 Para 1.6 içerisinde; Herhangi bir analiz faaliyeti, bir dizi gereksinime dayanan analiz hedefinin tanımlanmasıyla başlar. Herhangi bir analiz faaliyetinin çıktısı, bu gereksinimlerin doğrulanmasını içerir. Doğrulamanın amacı, analiz faaliyetinin tüm gereksinimlerinin karşılanıp karşılanmadığını değerlendirmek ve karşılanmamış gereksinimleri belgelemektir. Karşılanmamış gereksinimler belgelenmeli ve yeniden tasarım başlatmak veya olası çelişen gereksinimler arasında bir ödünleşimi sağlamak için ürün geliştirme ekibine raporlanmalıdır. Her analiz tanımlanmış bir temel çizgiye dayanmaktadır. Temele alınan nesneler, donanım ve/veya yazılım dışında işlevler ve Fonksiyonel Hatalar (arızalama modları) gibi diğer nesneleri de içerebilir. 

ISO 15288 referans olarak eklendi. 

• Bölüm 2, 2.3 Referanslar içerisine; ISO 15288- Sistemler ve yazılım mühendisliği - Sistem yaşam döngüsü süreçleri dokümanı referans olarak eklendi. 

Sistem analizi mantığının ayrıntılı açıklaması eklendi. 

• Bölüm 2, 2.3 Para 1.1 içerisinde; Sistem analizine ait süreç adımları açıklanmıştır. Gerekli durumlarda, yapılması gereken faaliyetlerin ayrıntılı tanımlarının yer aldığı ilgili paragraf numaralarına atıf yapılmaktadır. Süreç adımları tek tek açıklanmaktadır. 

Sistemler sistemi kırılımı hakkında açıklama eklendi. 

• Bölüm 2, 2.3 Para 2.2 içerisinde; Ürün Kırılım Yapısı (PBS), S1000D’de tanımlanan kurallara uygun olarak ve aşağıdaki hususlar dikkate alınarak oluşturulmalıdır. PBS belirlenirken iki ana ürün tipi göz önünde bulundurulmalıdır: Ürün Tipi 1, Ürün Tipi 2. 

Herhangi bir ürün, “Sistemler Sistemi” veya “Ürünler Ürünü” olarak yapılandırılabilir. Her bir sistem, sistem sınırları ve sistem arayüzleri ile tanımlanır. Fonksiyonlar, arayüzler aracılığıyla bir üst seviyeye sunulur. Bir ürünün konfigürasyon temel çizgisi (configuration baseline), her bir ürün varyantının birleşimiyle tanımlanır. 

• Bölüm 2, 2.3 Para 2.2.2 içerisinde; Ürün Tipi 2, Ürün Tipi 1 ile karşılaştırıldığında daha yüksek bir Ürün karmaşıklık seviyesine sahiptir. Ürün Tipi 2, bir Sistemler Sistemi’dir (örneğin, çeşitli yer istasyonları ve bileşenleri ile havada bulunan bileşenleri içerebilen İnsansız Hava Aracı (İHA) sistemleri), ISO 15288 referans alınmalıdır. Ürün Tipi 2 öncelikle ana Ürün bileşenlerine ayrılmalıdır. Bu Ürün tipinin her bileşeni, teknik sistemlerine, yapısına ve bölgesel alanlarına ayrılmalıdır. İlgili analiz verileri ve varsayımlar, her Ürün bileşeni için tanımlanmalıdır. Veriler/varsayımlar, bireysel Ürün bileşenleri arasında önemli ölçüde farklılık gösterebilir. 

Yazılım için bir kırılım içermesi önerisi eklendi. 

• Bölüm 2, 2.3 Para 2.2 içerisinde; ARC ve ARC olmayanı belirlemeden önce, Ürün geliştirme ekibi, analiz edilen Ürün için belirtilen işlevsel gereksinimleri karşılayan bir işlevsel mimari geliştirecek ve tüm ilgili paydaşlarla istişarede bulunacaktır. Mimarinin tanımı, tek bir departmanın değil, ortak bir çabadır. Ürün kırılım yapısında yapılacak herhangi bir değişiklik, ürün (ler)in yaşam döngüsü boyunca izlenebilir olmalıdır, bu nedenle ürün kırılım yapısının geliştirilmesi tüm paydaşları içerir. 

Bakım eforunun hesaplanması için bir temel oluşturmak amacıyla aralık türü ve sayısal değeri dahil edildi. 

Sayısal aralık belirlemesi için MTBF değerleri ve P-F eğrisi hakkında arka plan bilgisi eklendi. 

• Bölüm 2, 2.3 Not 1 içerisinde; Ortalama Arızalar Arası Süre (MTBF) değerleri bazen aralık belirleme kaynağı olarak gösterilir. MTBF değeri bazı bilgiler sağlasa da, özellikle mekanik parçalar için bu amaç için pek uygun değildir. MTBF değerleri, çalışma saati başına arıza sayısı (veya eşdeğeri) olarak ifade edilir. MTBF değerlerinin kaynağı genellikle bilinmeyen, arızanın tanımı çoğu zaman net olmayan ve en önemlisi, MTBF değerleri belirli bir örneklemde zaman içindeki arıza olasılığını ifade etmeyen bir parametredir; bu, aralık belirleme açısından önemli bir unsurdur çünkü arıza dağılımı hakkında bilgi içermez. MTBF değerleri, elektrikli ve elektronik bileşenler için minimum bir güven düzeyi sağlamak amacıyla dikkatle kullanılmalıdır. 

• Bölüm 2, 2.3 Not 2 içerisinde; P-F eğrisi, uygun bir sayısal aralığı belirlemek için daha uygun bir kaynaktır. P-F eğrisi, belirli bir FC için belirlenmelidir ve FC'nin bozulma mekanizmalarına dayanır; bu mekanizmalar arıza belirtileri aracılığıyla gözlemlenebilir. Sayısal aralık değeri, P ile F aralığı içinde olmalıdır. 

ARC ile SD arasındaki fark hakkında açıklama eklendi. 

• Bölüm 2, 2.4 Para 1 içerisinde; Bir ARC, farklı çevresel ve kullanım koşullarına ile yüklere maruz kalabilir ve bu durum farklı analiz sonuçlarına yol açabilir. Bu da analizi desteklemek amacıyla ARC’nin 2 veya daha fazla bölüm ya da özelliğe ayrılmasını gerektirebilir; böylece SD tanımlanmış olur. 

Depolama ve taşımacılık sırasında da önleyici bakımın gerekli olabileceğini vurguladı. 

• Bölüm 2, 2.5 Para 3 içerisinde; Analiz edilen her bölge, mevcut tasarım durumu ile, ürün kullanım aşamasında bakım personelini görevlerini yerine getirirken tehlikeye atabilecek kabul edilemez tehditler açısından incelenmelidir. Bu tehditler örneğin depolama veya taşıma sırasında da ortaya çıkabilir. Tehlikeli maddelere maruz kalmanın sonucunda oluşabilecek sağlık tehditleri, Sistem Güvenliği tarafından Uygun bir analiz, örneğin İş Sağlığı ve Güvenliği (İSG) değerlendirmesi ile doğrulanmalıdır. Bu değerlendirme, maksimum mesleki maruziyet sınırlarının (OEL) aşılma ihtimali olup olmadığını göstermelidir. Ekipman veya cihaz tahsisi ile ilgili tehlikeler veya diğer sağlık tehdit eden unsurlar, erken yeniden tasarım yapılabilmesini sağlamak amacıyla tasarım departmanına iletilmelidir. 

CMR ile PMTL arasındaki ilişki açıklandı. 

• Bölüm 2, 2.6 Para 1 Not içerisinde; PMTL’ler, sivil havacılık analiz süreçlerinde Sertifikasyon Bakım Gereksinimleri (Certification Maintenance Requirements – CMR) olarak adlandırılır. Aday Sertifikasyon Bakım Gereksinimleri (Candidate Certification Maintenance Requirements – CCMR), kabul edildikten sonra CMR’ye dönüşür. 

PMRB üzerinde detaylı bilgi verildi ve ürün ömrü boyunca PMRB'nin korunması gerekliliği vurgulandı. 

• Bölüm 2, 2.6 Para 1 içerisinde; Önleyici Bakım İnceleme Kurulu (PMRB), bazen Yönlendirme Komitesi (SC) veya Sertifikasyon Komitesi (CC) olarak da bilinir. PMRB, sistem bütünleyiciden ve uygulanabilir olduğu durumlarda herhangi bir OEM, yetkili makam ve/veya kullanıcı temsilcisinden oluşur. PMRB üyeleri PPH'de tanımlanmıştır. Rollerin ve sorumlulukların dağılımı ürün türüne göre tanımlanmalı ve PPH'de belgelenmelidir.  

• Bölüm 2, 2.6 Fig 6 içerisinde; Analizde yapılan tüm değişiklikler/güncellemeler PMRB tarafından gözden geçirilmeli ve onaylanmalıdır. 

BÖLÜM 3-PMTR OPTİMİZE ETME 

ISMO'nun amacını detaylandırdı. 

• Bölüm 3, 3.2 Para 1 içerisinde; ISMO Analiz Hazırlık Aşaması’nın amacı, analiz için bir bilgi temel hattı (baseline) oluşturmak ve tüm bilgi ile verilerin tam izlenebilirliğini sağlamaktır. Bu temel hat, ardışık ISMO döngüleri sırasında yeniden kullanılabilecek şekilde yapılandırılmalıdır. Tüm analiz aşamaları bir Politika ve Prosedürler El Kitabı’nda (PPH) dokümante edilmelidir. Analizin kendisi uygun yazılımlar tarafından desteklenmelidir. Bunun nedeni, her bakım görevinin planlı bakımın teknik FFC’si veya tetikleyicisiyle (örneğin Ömür Sınırlı Kalemler Listesi – LLIL) ilişkilendirilmiş olmasıdır. 

BÖLÜM 4-S4000P ARAYÜZLERİ 

Farklı sorumlulukları vurgulamak için figürlere “Sistem Güvenliği” açıkça dahil edildi. 

• Bölüm 4, 4.2 Para 2.1 içerisinde; Fonksiyonlar Sistem Mühendisliği ile birlikte geliştirilir. Hangi sistemlerin güvenlik açısından önemli olduğu ve kritik arızaların nasıl olacağı, Sistem Güvenliği ile birlikte geliştirilmelidir. 

• Bölüm 4, 4.3 Para 3.1 içerisindede; figürlere “Sistem Güvenliği” açıkça dahil edildi. 

S4000P ve S1000D arasındaki görev türlerini uyumlu hale getirmek için bir not eklendi ve bu durum bir PPH ve Rehber Belgesi'nde belgelendi. 

• Bölüm 4, 4.4 Para 3 Not içerisinde; S4000P'deki görev türlerinin tanımı henüz S1000D'deki bilgi kodlarıyla tamamen uyumlu değildir. Görev türlerinin eşleştirilmesi ve tanımı, Politika ve Prosedürler El Kitabı'nda (PPH) tanımlanmalıdır. 

Baselines aracılığıyla konfigürasyon kontrolünün sürdürülmesinin önemini vurguladı. 

• Bölüm 4, 4.4 Para 2 içerisinde; Analiz faaliyetleri, ürün tasarım ve geliştirme sürecinin erken aşamalarında başlar. Bu aşamada Ürün Kırılım Yapısı (PBS) henüz tam olmasa da mümkün olan en erken zamanda oluşturulmalıdır. Erken analizler için eksiksiz tasarım verileri gereklidir ve veri tutarlılığı için baseline ve revizyonların kullanılması önerilir. 

Kullanım verisi geri bildirimlerinin yapılandırılmasıyla ilgili paragraf eklendi. 

• Bölüm 4, 4.5 Para 2 içerisinde; Ürün tasarım ve geliştirme aşamasında, ürün tasarımından ve/veya tedarikçilerden, S4000P analistlerinden ve bu tür verileri alan diğer taraflardan gelen geri besleme kaynakları büyük önem taşımaktadır. S5000F’nin kapsamı, ürünün hizmette kullanım operasyonları ve görevleri sırasında üründen toplanan geri besleme verilerinin yönetilmesidir. S5000F kapsamındaki süreçler, operasyonel ve bakım geri besleme bilgilerine ve ürün yaşam döngüsünün operasyonel aşamasında gerçekleşen ürüne ilişkin faaliyetlere odaklanır. Hizmette kullanım (in-service) ve elden çıkarma (disposal) aşamaları, ürün yaşam döngüsünde S5000F kapsamına giren son iki aşamadır. 

Kullanım aşamasının birden fazla aşamaya bölünmesi gerekebileceğine dair not eklendi. 

• Bölüm 4, 4.6 Para 6 içerisinde; Hizmette kullanım (in-service) aşaması, kullanım sırasında gereken bakımdan farklı önleyici bakım gerektirebilen birden fazla alt aşama içerebilir; örneğin (uzun süreli) depolama veya taşıma gibi. Farklı kullanım profilleri de analizlerin yeniden gözden geçirilmesini gerektirebilir. Bu aşamaların tamamı PPH içerisinde dokümante edilmelidir. 

BÖLÜM 5-VERİ MODELİ VE VERİ ALIŞVERİŞİ 

CDM hakkında arka plan bilgisi eklendi. 

• Bölüm 5, 5.1 Para 1 içerisinde; Analiz sonuçları ve destekleyici bilgiler, Ortak Veri Modeli’ne (Common Data Model – CDM, SX002D) dayalı UML veri modelinden t&uum

  Share: