Bu makalede7 bölüm
- Teknoloji
- IATF 16949, MES, CMMS, SQL Server temporal tables, NTP, ALCOA+
- Konu
- Üretim ve bakım sistemlerinde kayıt güvenilirliği
- Seviye
- Orta–ileri
- Ön koşullar
- MES/CMMS yönetici erişimi
- Kritik kayıt türleri listesi
- NTP altyapısı bilgisi
MES’teki ölçüm sonucu, CMMS’teki bakım kaydı, bir parti için girilen kalite onayı: müşteri şikâyetinde, geri çağırma incelemesinde ve IATF denetiminde hepsi kanıt olarak masaya konur. Kayıt sonradan değiştirilebiliyorsa, kimin girdiği belli değilse ya da zaman damgaları birbirini tutmuyorsa kanıt değeri kalmaz. Aşağıda üretim ve bakım sistemlerinde kayıt bütünlüğünü değerlendirmek için denetim izi, kullanıcı hesapları, zaman senkronizasyonu ve veri düzeltme kontrollerini; BT, kalite ve OT sorumlularının sahada kontrol edeceği sırayla ele alıyoruz.
Kayıt bütünlüğü neden bir kalite konusudur?
ISO 9001’in 7.5.3 maddesi, dokümante bilginin uygun şekilde korunmasını ve bütünlüğünü kaybetmemesini ister. IATF 16949 bunun üzerine izlenebilirlik (8.5.2.1), toplam üretken bakım kayıtları (8.5.1.5) ve kayıt saklama (7.5.3.2.1) gibi gereklilikler ekler. Bu maddelerin hiçbiri “denetim izi” kelimesini kullanmaz. Hepsi kaydın güvenilir olduğunu varsayar.
Sahada kayıt bütünlüğü sorunu genellikle şu senaryolarla yüzeye çıkar:
- Tolerans dışı bir ölçüm sonucu, parti sevk edildikten sonra “giriş hatası” gerekçesiyle düzeltilmiş; düzeltmeyi kimin yaptığı ve orijinal değer görünmüyor.
- Bir makinenin periyodik bakımı CMMS’te “tamamlandı” olarak kapatılmış, ama kapanış saati ile bakım teknisyeninin vardiyası uyuşmuyor.
- Geri çağırma incelemesinde MES’teki üretim zamanı ile test standındaki test zamanı arasında açıklanamayan dakikalar var; parçanın hangi test kaydına ait olduğu kesinleştirilemiyor.
Üçüncü senaryonun kökü çoğu zaman tek bir şeydir: test standı PC’sinin saati aylardır kendi kafasına göre ilerliyordur. Kimse bakmamıştır.
İlaç sektöründe veri bütünlüğü için yaygın kullanılan ALCOA+ ilkeleri (kayıt atfedilebilir, okunaklı, eşzamanlı, orijinal ve doğru olmalı; ayrıca eksiksiz, tutarlı, kalıcı ve erişilebilir) IATF’in doğrudan gerekliliği değildir. Ama üretim kayıtlarını değerlendirmek için iyi bir kontrol çerçevesidir; aşağıdaki başlıkların her biri bu ilkelerden birine denk düşer.
Denetim izi (audit trail) gereklilikleri
Denetim izi, bir kayıt oluşturulduğunda, değiştirildiğinde veya silindiğinde kimin, ne zaman, neyi, hangi değerden hangi değere ve neden değiştirdiğini gösteren, kullanıcının değiştiremediği kayıttır. Mevcut MES veya CMMS’i değerlendirirken ya da yenisini seçerken şu soruları sorun:
- Denetim izi hangi tablolarda veya nesnelerde aktif? Ölçüm sonuçları, parti durumu, kalite kararları, reçete ve ana veri değişiklikleri kapsanıyor mu?
- Orijinal değer korunuyor mu, yoksa yalnız “değiştirildi” bilgisi mi tutuluyor?
- Değişiklik nedeni zorunlu alan mı?
- Uygulama yöneticisi denetim izini kapatabiliyor veya silebiliyor mu? Bu işlem ayrıca loglanıyor mu?
- Denetim izi kaydın kendisi kadar uzun süre saklanıyor mu?
Sahada en sık gördüğümüz durum şudur: denetim izi modülü lisansta var, ama performans gerekçesiyle kurulumda kapatılmış ya da yalnız birkaç tabloda açık bırakılmış. Ekrandaki “değişiklik geçmişi” sekmesi boş döner. İlk kontrol, uygulamanın yönetim konsolunda denetim izinin hangi nesnelerde gerçekten açık olduğudur.
Uygulamanın yerleşik denetim izi yetersizse veritabanı katmanında tamamlayıcı kontrol kurulabilir. Microsoft SQL Server’da sistem sürümlü geçici tablolar (temporal tables) her güncellemede satırın önceki halini otomatik olarak bir geçmiş tablosunda saklar:
CREATE TABLE dbo.OlcumSonuc (
OlcumId INT IDENTITY PRIMARY KEY,
SeriNo NVARCHAR(40) NOT NULL,
Karakteristik NVARCHAR(40) NOT NULL,
Deger DECIMAL(12,4) NOT NULL,
Kullanici NVARCHAR(128) NOT NULL,
DegisiklikNedeni NVARCHAR(200) NULL,
GecerliBas DATETIME2 GENERATED ALWAYS AS ROW START NOT NULL,
GecerliBit DATETIME2 GENERATED ALWAYS AS ROW END NOT NULL,
PERIOD FOR SYSTEM_TIME (GecerliBas, GecerliBit)
)
WITH (SYSTEM_VERSIONING = ON (HISTORY_TABLE = dbo.OlcumSonucGecmis));
-- Bir seri numarasının tüm değişiklik geçmişi
SELECT SeriNo, Karakteristik, Deger, Kullanici, DegisiklikNedeni, GecerliBas, GecerliBit
FROM dbo.OlcumSonuc FOR SYSTEM_TIME ALL
WHERE SeriNo = N'A2411-000123'
ORDER BY GecerliBas;
Bu yapının iki sınırını bilin. Birincisi, geçici tablo kimin değiştirdiğini kendiliğinden kaydetmez; Kullanici ve DegisiklikNedeni alanlarını her güncellemede uygulama doldurmalıdır. Uygulama tek bir servis hesabıyla bağlanıyorsa veritabanı yalnız o hesabı görür. İkincisi, dönem sütunlarındaki zaman damgaları UTC olarak tutulur; raporlamada yerel saate çevrilmelidir. Yüksek yetkili veritabanı kullanıcıları sürümlemeyi kapatabildiği için bu tür işlemler SQL Server Audit gibi ayrı bir mekanizmayla izlenmelidir.
Paylaşılan kullanıcı hesapları sorunu
Üretim sahasında “HAT1”, “OPERATOR” veya “BAKIM” gibi ortak hesaplar yaygındır. Gerekçe pratiktir: vardiya değişiminde oturum kapatmak zaman alır, eldivenle şifre yazmak zordur. Ama paylaşılan hesap, denetim izinin “kim” sorusunu boşa düşürür. Bir kalite kararını hangi operatörün verdiği bilinmiyorsa kaydın atfedilebilir olduğu ve bilgi güvenliği uyumu sağlandığı söylenemez.
| Yaklaşım | Avantaj | Sınırlama |
|---|---|---|
| Kişisel kullanıcı + şifre | Tam atfedilebilirlik | Sahada yavaş; şifre paylaşımına eğilim |
| Kart/RFID ile oturum | Hızlı, kişisel | Kart okuyucu entegrasyonu, kayıp kart süreci |
| Ortak istasyon oturumu + işlem bazlı kart onayı | Kritik işlemlerde kişisel iz | Hangi işlemlerin kritik olduğu tanımlanmalı |
| Ortak hesap + vardiya listesi | Kolay | Kişiye atfetme zayıf; yalnız düşük riskli ekranlar için |
Gerçekçi hedef, tüm sahayı bir gecede kişisel oturuma geçirmek değildir. Zorla yapılırsa şifreler çoğu zaman monitörün kenarındaki kâğıtta biter. Hedef, kalite kararı, parti serbest bırakma, ölçüm düzeltme, reçete değişikliği ve bakım kapanışı gibi kritik işlemlerde kişisel kimlik doğrulamayı zorunlu kılmaktır. Ortak hesaplar kalıyorsa yetkileri bu işlemleri içermeyecek şekilde daraltılmalı. Hesap ve yetkilerin periyodik gözden geçirilmesi için erişim gözden geçirme kanıtı yazısındaki yöntem MES ve CMMS kullanıcılarına da uygulanır.
Zaman senkronizasyonu ve zaman damgası
Bir parçanın üretim, test, etiketleme ve sevkiyat kayıtları farklı sistemlerde tutulur. Bu sistemlerin saatleri farklıysa kayıtları sıraya dizemezsiniz. Saat tutmazsa iz kopar. Zaman bütünlüğü için asgari kurallar:
- Tüm MES, CMMS, veritabanı, test standı PC’si, HMI ve PLC’ler (destekliyorsa) aynı kurumsal NTP hiyerarşisinden senkronize olmalıdır. NTP protokolü RFC 5905 ile tanımlıdır.
- OT ağı segmentasyon nedeniyle internete çıkamıyorsa DMZ’de veya OT tarafında yerel bir NTP sunucusu kurulmalıdır.
- Kayıtlarda zaman dilimi açık olmalıdır; tercihen UTC saklanıp yerel saat gösterilmelidir. Yaz saati uygulayan ülkelerdeki tesislerle veri paylaşılıyorsa saat değişim gecesinde aynı saat iki kez yaşanır ya da hiç yaşanmaz; UTC saklamak bu belirsizliği ortadan kaldırır.
- Saat sapması izlenmeli, belirlenen eşiği aşan cihazlar için alarm üretilmelidir.
Domain’e üye olmayan, çalışma grubunda kalmış istasyon PC’leri en sık sapan cihazlardır; varsayılan olarak internetteki zaman sunucusuna gitmeye çalışırlar, OT ağında ona ulaşamazlar ve sessizce kayarlar. Sapmayı kontrol etmek için Windows ve Linux’ta kullanılabilecek komutlar:
# Windows: senkron kaynağı ve durumu
w32tm /query /source
w32tm /query /status
# Windows: NTP sunucusuna göre anlık sapmayı ölç
w32tm /stripchart /computer:ntp1.kurum.local /samples:5 /dataonly
# Linux (chrony): senkron durumu ve kaynaklar
chronyc tracking
chronyc sources -v
Bu çıktılar kayıt bütünlüğü değerlendirmesinin kanıtı olarak saklanabilir. Merkezi log altyapısıyla birlikte ele alınması mantıklıdır; log saklama mimarisi için merkezi log saklama mimarisi yazısına bakabilirsiniz.
Veri düzeltme ve toplu güncelleme kontrolü
Hiçbir sistem hatasız veri girişi garanti etmez; düzeltme ihtiyacı olağandır. Sorun düzeltmenin yoludur. En riskli yol, BT’nin veya yazılım tedarikçisinin doğrudan veritabanında UPDATE çalıştırmasıdır: uygulamanın denetim izi devreye girmez, iş birimi onayı yoktur, değişiklik hiçbir kayıtta görünmez. Konsolda iki dakikalık iş. İzi ise hiç yok.
Düzeltme senaryoları için kontrol tablosu:
| Senaryo | Kim yapar | Gerekli kontrol |
|---|---|---|
| Tek kayıt giriş hatası | Yetkili kullanıcı, uygulamadan | Neden alanı, orijinal değer korunur |
| Sevk edilmiş partiye ait kalite kaydı | Kalite yetkilisi | Uygunsuzluk değerlendirmesi, ikinci onay |
| Toplu düzeltme (arayüz hatası vb.) | BT, betikle | Değişiklik kaydı, iş birimi onayı, önce/sonra dökümü |
| Ana veri değişikliği (ürün, reçete) | Ana veri sorumlusu | Değişiklik süreci, sürüm geçmişi |
| Tedarikçinin destek amaçlı veri müdahalesi | Tedarikçi, gözetimli | Talep kaydı, oturum kaydı, sonuç doğrulaması |
Toplu düzeltmede değişiklik öncesi ve sonrası verinin dökümünü alın, betiği değişiklik kaydına ekleyin, sonucu iş birimine doğrulatın. Veritabanına doğrudan yazma yetkisi olan hesapları asgari düzeyde tutun ve kullanımlarını loglayın; tedarikçinin destek için bıraktığı “sa” benzeri hesaplar bu listenin ilk satırıdır. Arayüz hatasından kaynaklanan bir düzeltme, ölçüm verisi zincirinin doğrulanmadığına da işaret edebilir; bu konu ölçüm ve test yazılımlarının doğrulanması yazısında ele alınıyor.
Kayıt bütünlüğü değerlendirme listesi
Aşağıdaki sorular bir MES veya CMMS için yıllık değerlendirmede ya da iç denetimde kullanılabilir. Her “hayır” bir aksiyon kaydıdır:
- Kritik kayıt türleri (ölçüm, kalite kararı, parti durumu, bakım kapanışı, reçete) belirlenmiş mi?
- Bu kayıt türlerinde denetim izi aktif mi ve orijinal değeri koruyor mu?
- Değişiklik nedeni zorunlu mu?
- Denetim izini kapatma veya silme yetkisi kimde ve bu işlemler izleniyor mu?
- Kritik işlemler kişisel kimlik doğrulamayla mı yapılıyor? Ortak hesapların yetkileri sınırlı mı?
- Tüm üretim sistemleri aynı NTP kaynağından senkronize mi ve sapma izleniyor mu?
- Kayıtlarda zaman dilimi açık mı?
- Doğrudan veritabanı yazma yetkisi olan hesaplar listelenmiş ve gözden geçirilmiş mi?
- Son 12 aydaki toplu düzeltmelerin her biri için değişiklik kaydı ve onay var mı?
- Denetim izi, kaydın saklama süresi boyunca saklanıyor ve arşivleniyor mu?
Burada kayıtların canlı sistemdeki doğruluğunu ele aldık. Saklama ve arşiv tarafı için PPAP ve kalite kayıtlarının arşivlenmesi, parçadan müşteriye uzanan zincirin tasarımı için üretimde izlenebilirlik sistemleri yazılarına bakabilirsiniz. Üretim sistemlerinde yetki ve kayıt kontrollerini birlikte değerlendirmek için üretim tesislerinde IT/OT uyum ve erişim yetkileri denetimi hizmetlerimizden yararlanabilirsiniz.
Sık sorulan sorular
MES’te kayıt düzeltmek tamamen yasaklanmalı mı?
Hayır. Giriş hatası olağandır ve düzeltilebilmelidir. Şart olan, düzeltmenin uygulama üzerinden, yetkili bir kullanıcı tarafından, neden belirtilerek ve orijinal değer korunarak yapılmasıdır. Sevk edilmiş ürünlere ait kayıtlarda ayrıca kalite onayı gerekir.
Paylaşılan operatör hesapları IATF denetiminde bulgu sebebi mi?
IATF 16949 kişisel hesabı açıkça şart koşmaz; ama kritik kalite kararlarının kime ait olduğu gösterilemiyorsa izlenebilirlik ve kayıt güvenilirliği sorgulanır. Kritik işlemlerde kişisel kimlik doğrulama, ortak hesaplarda yetki daraltma uygulayın.
PLC ve HMI saatlerinin senkronizasyonu gerekli mi?
Bu cihazlar kayıt üretiyorsa veya ürettikleri zaman damgası MES’e aktarılıyorsa gereklidir. Cihaz NTP desteklemiyorsa zaman damgasını MES veya veri toplama katmanında üretmek ve bu tasarım kararını belgelemek bir alternatiftir.
Veritabanı düzeyinde denetim izi uygulama denetim izinin yerini tutar mı?
Tamamen tutmaz. Veritabanı katmanı neyin değiştiğini gösterir; hangi uygulama kullanıcısının hangi nedenle değiştirdiğini ise uygulama bu bilgiyi aktarmadıkça bilemez. İki katman birbirini tamamlar.
- Teknoloji
- IATF 16949, MES, CMMS, SQL Server temporal tables, NTP, ALCOA+
- Konu
- Üretim ve bakım sistemlerinde kayıt güvenilirliği
- Seviye
- Orta–ileri
- Ön koşullar
- MES/CMMS yönetici erişimi
- Kritik kayıt türleri listesi
- NTP altyapısı bilgisi
IATF 16949 ve Üretim