Core Packet Standard (CPS) V1.0

Bu doküman, Core Packet Standard (CPS) V1.0 kapsamında geliştirilen cihazlar tarafından backend sistemlerine gönderilen veri paketinin yapısal standardını tanımlar. Standardizasyonun amacı yalnızca veri iletmek değil, farklı donanım sınıflarına, farklı haberleşme kabiliyetlerine ve farklı operasyonel koşullara sahip cihazların ortak bir veri modeli altında güvenilir biçimde çalışmasını sağlamaktır. Aynı backend üzerinde birden fazla cihaz ailesinin birlikte yönetilebilmesi, paketlerin tek bir sözleşme üzerinden ayrıştırılabilmesi ve saha verisinin uzun ömürlü biçimde işlenebilmesi için veri paketinin açık, sade ve tutarlı bir çerçeveye sahip olması gerekir.

Bu ihtiyaç özellikle düşük kaynaklı, çoğu zaman batarya destekli, zaman zaman kesintili bağlantı koşullarında çalışan IoT cihazlarında daha belirgindir. Paket yapısının gereksiz ölçüde karmaşık olması; firmware tarafında maliyeti artırır, iletim yükünü büyütür ve backend tarafında veri işleme davranışını kırılgan hale getirir. Buna karşılık aşırı yalın ama yönsüz bir yapı da cihaz çeşitliliği arttıkça ortak modelin bozulmasına, aynı veri ailesinin farklı biçimlerde temsil edilmesine ve operasyonel izlenebilirliğin zayıflamasına yol açar. Bu standardın hedefi, bu iki uç arasında dengeli bir yapı kurmaktır: minimum zorunlu çekirdek, kontrollü opsiyonel genişleme ve uzun vadede yönetilebilir bir veri omurgası.

Yapısal ilkeler​

Bu standartta paket biçimi JSON olarak belirlenmiştir. JSON seçimi, cihaz ve backend tarafında uygulama kolaylığı, hata ayıklama görünürlüğü ve çoklu entegrasyon senaryolarında okunabilirlik avantajı sağladığı için korunur. Bununla birlikte JSON kullanımının getirdiği metinsel taşıma maliyeti, paket içeriğinin kontrollü tutulmasıyla dengelenir; bu nedenle zorunlu alan seti olabildiğince küçük, ek alanlar ise ihtiyaca bağlı olarak opsiyonel kurgulanır. JSON paketleri cihazda oluşturulurken boşluksuz yapıda oluşturulmaktadır.

Paket yapısı üç ana segmentten oluşur: Info, Device ve Payload. Bu ayrım, paketin bağlamsal kimliği, cihazın üretim anındaki operasyonel durumu ve uygulamaya özgü asıl verinin birbirinden ayrıştırılmasını sağlar. Böylece backend tarafında hem işleme akışları sadeleşir hem de veri modelinin genişletilmesi belirli sınırlar içinde kalır.

Temsil modelinde temel prensip, aynı veri ailesi için tek ve tutarlı bir gösterim kullanmaktır. Aynı semantik içeriğin bir cihazda tekil alanlar, başka bir cihazda dizi, başka bir firmware sürümünde farklı isimler ile taşınması kabul edilmez. Bu nedenle payload tarafında serbest görünüşlü ama kontrolsüz olmayan bir yapı benimsenir; düz obje yaklaşımı korunur, fakat değişkenlerin temsil tipi önceden tanımlanır. Böylece esneklik ile veri yönetişimi arasında dengeli bir model elde edilir.

Paketin genel yapısı​

Her veri paketi bir JSON nesnesi olarak taşınır ve aşağıdaki üç ana segmentten oluşur:

{
  "Info": {},
  "Device": {},
  "Payload": {}
}

Bu yapıda Info paketin kimliğini, üretim zamanını ve gönderim bağlamını taşır. Device, verinin üretildiği anda cihazın operasyonel durumuna ilişkin telemetriyi içerir. Payload ise uygulamaya özgü ölçüm, olay veya proses verisini taşır. Bölümlerin bu şekilde ayrılması, tek paket içinde hem izlenebilirlik hem de işlevsel veri taşımayı mümkün kılar.

Info Segmenti​

Info segmenti, her paketin asgari bağlamsal omurgasını oluşturur. Backend tarafında bir paketin hangi cihaz tarafından, hangi anda ve hangi üretim sırası içinde oluşturulduğunun anlaşılması bu segment üzerinden sağlanır. Bu nedenle Info, yalnızca metadata niteliğinde yardımcı bir bölüm değil, paketin anlamlandırılması için zorunlu çekirdek segmenttir.

Command​

Command, paketin türünü veya işlevsel gönderim nedenini ifade eder ve Info segmentinin zorunlu alanlarından biridir. Bu sürümde yalnızca aşağıdaki tabloda tanımlanan değerleri alır.

TimeStamp​

TimeStamp, cihazın paketi oluşturduğu anda sahip olduğu zamanı temsil eder ve Info segmentinin zorunlu alanlarından biridir. Bu zaman bilgisi cihaz içindeki ve GSM üzerinden senkron edilen RTC kaynağından okunur. Dolayısıyla alanın anlamı sunucuya ulaşma zamanı değil, paketin cihaz üzerinde üretildiği andır. Store-and-forward, gecikmeli iletim veya bağlantı kopması sonrasında toplu gönderim gibi senaryolarda bu ayrım kritik önem taşır.

Bu sürümde TimeStamp alanı aşağıdaki formatta taşınır:

YYYY-MM-DDTHH:mm:ss

Örnek:

2026-03-26T20:10:00

Bu alan cihazın yerel zamanını temsil eder. UTC işareti (Z) veya timezone offset bilgisi içermez. Backend tarafında bu alan yorumlanırken, timezone içermeyen yerel zaman semantiği korunmalıdır.

ID​

ID, DS28C tabanlı 48 bit ID + 8 bit CRC verisinin HEX string gösterimidir ve Info segmentinin zorunlu alanlarından biridir. Bu alan, cihaz kimliğinin hafif, taşınabilir ve backend tarafında kolay işlenebilir temsilidir. Bu dokümanda ID için ek alt alanlar veya ikincil kimlik yapıları tanımlanmaz.

Seq​

Seq, başarılı gönderim sayacı değildir; cihazın veri üretim sırasını ifade eder ve Info segmentinin zorunlu alanlarından biridir. Her yeni paket üretiminde artar ve cihaz reseti sonrasında sıfırlanabilir. Bu tanım, tekrar gönderim ile yeni veri üretiminin karıştırılmaması, eksik veya yinelenmiş kayıtların daha doğru yorumlanması ve göreli veri sırasının korunması açısından gereklidir.

IMEI / ICCID / Firmware​

IMEI, ICCID ve Firmware alanları opsiyonel tamamlayıcı alanlardır; zorunlu çekirdeğin parçası değildir. Bunlar her pakette tekrarlanan telemetri değil, gerektiğinde gönderilen tamamlayıcı envanter bilgisidir. İlk kayıt, modem veya SIM değişimi, firmware güncellemesi ya da envanter yenileme ihtiyacı gibi durumlarda iletilmeleri yeterlidir. Bu tercih, paket boyutunu büyütmeden backend envanterinin güncel tutulmasını sağlar.

Info alan sözlüğü​

Bu bölüm, Info segmentindeki alanların taşıma sözleşmesini normatif olarak sabitler. Aksi belirtilmedikçe aşağıdaki tip, format ve yokluk davranışları korunmalıdır.

Seq alanında sayaç taşması oluşursa değer mod $2^{32}$ davranışıyla 0 değerine döner. Cihaz yeniden başlatma sonrası Seq değerinin 0'dan başlaması kabul edilir.

Command üretim kuralları​

Command alanı serbest yorumla doldurulmamalıdır. Aynı kök olay için yalnızca tek bir Command değeri seçilmelidir.

1. Online, cihaz çalışır durumda iken haberleşme oturumu başarıyla kurulduğunda veya yeniden kurulduğunda üretilmelidir.
2. Offline, cihaz kontrollü biçimde bağlantıyı sonlandırabiliyorsa kapanış veya erişimden çıkış öncesinde üretilmelidir. Ani enerji kaybı gibi durumlarda üretilememesi protokol ihlali sayılmaz.
3. Timed, zamanlayıcı tabanlı normal periyodik gönderimlerde kullanılmalıdır.
4. Timed_Tiny, zamanlayıcı tabanlı daraltılmış içerikli gönderimlerde kullanılmalıdır. Aynı zaman dilimi için hem Timed hem Timed_Tiny üretilmemelidir.
5. Interrupt, periyodik akış dışında donanımsal veya yazılımsal kesme tetiklemesi ile anlık veri üretildiğinde kullanılmalıdır.
6. Event, alarm seviyesine çıkmayan ama kayıt altına alınması gereken durum değişimlerinde kullanılmalıdır.
7. Alarm, kritik eşik aşımı, arıza veya acil müdahale gerektiren koşullarda kullanılmalıdır.
8. Aynı kök olay hem Event hem Alarm koşulunu sağlıyorsa Alarm seçilmelidir.
9. Aynı kök olay hem periyodik gönderim hem kesme temelli gönderim koşulunu sağlıyorsa periyodik komut yerine olayın gerçek nedeni olan Interrupt, Event veya Alarm seçilmelidir.

Device Segmenti​

Device segmenti, cihazın veri ürettiği andaki operasyonel durumunu taşır. Bu segment, cihazın yalnızca ölçüm üreten bir uç nokta olarak değil, aynı zamanda saha koşullarına maruz kalan fiziksel bir sistem olarak izlenebilmesini sağlar. Özellikle güç durumu ve haberleşme kalitesi, veri güvenilirliği ve bakım gereksinimi üzerinde doğrudan etkili olduğu için Device segmenti operasyonel izlenebilirlik açısından kritik önemdedir.

Bu segment iki alt bölüm altında modellenir:

• Power
• IoT

{
  "Device": {
    "Power": {},
    "IoT": {}
  }
}

Bu ayrım korunur. Güç tarafına ait alanlar ile haberleşme bağlamına ait alanlar birbirine karıştırılmaz; ancak her iki alt bölümde de aynı temel yaklaşım geçerlidir: minimum zorunlu çekirdek ve kontrollü opsiyonel genişleme.

Device.Power Segmenti​

Bu ürün ailesi batarya destekli cihazlardan oluştuğu için güç durumu yardımcı bir bilgi olarak değil, cihaz davranışını doğrudan etkileyen çekirdek operasyonel bağlam olarak ele alınır. Buna rağmen her olası güç metriğinin her pakette taşınması tercih edilmez. Çünkü bu yaklaşım paket boyutunu gereksiz artırır, düşük enerji hedefleriyle çelişir ve firmware tarafında gereksiz taşıma maliyeti üretir. Bu nedenle çekirdek güç görünürlüğünü sağlayan minimum alan seti ile donanıma veya ihtiyaca bağlı ek alanlar ayrıştırılmıştır.

B_IV​

B_IV, batarya tarafı için çekirdek izleme alanıdır ve Device.Power alt segmentinin zorunlu alanlarından biridir.

B_AC​

B_AC, batarya davranışının yorumlanmasında kullanılan çekirdek alanlardan biridir ve Device.Power alt segmentinde zorunludur.

B_CS​

B_CS, şarj veya genel güç durumu bağlamını taşıyan çekirdek alanlardan biridir ve Device.Power alt segmentinde zorunludur.

B_IC​

B_IC, ihtiyaca bağlı ek güç telemetrisi taşımak için kullanılabilen opsiyonel alanlardan biridir.

B_FC​

B_FC, ihtiyaca bağlı ek güç telemetrisi için ayrılmış opsiyonel alanlardan biridir.

B_SOC​

B_SOC, yorumlanmış veya türetilmiş kapasite/seviye bilgisini taşımak için kullanılabilen opsiyonel alanlardan biridir.

B_T​

B_T, batarya sıcaklığı mevcutsa gönderilebilen opsiyonel alanlardan biridir.

Device.IoT Segmenti​

Device.IoT alt segmenti, cihazın haberleşme bağlamını taşır. Mevcut sistemler ağırlıklı olarak GSM tabanlı çalışsa da standart yalnızca bugünkü taşıyıcı yapıya kilitlenmez. Aynı veri modelinin ileride farklı erişim teknolojilerini de kapsayabilmesi için haberleşme alan seti genişlemeye açık tutulur. Bu nedenle haberleşme bağlamı paket içinde temsil edilir, ancak cihaz tipini tekrar eden ve backend tarafında zaten bilinebilen bilgiler zorunlu çekirdeğe dahil edilmez.

RSSI​

RSSI, haberleşme kalitesini pratik olarak izlemek için kullanılan temel alandır ve Device.IoT alt segmentinin zorunlu alanlarından biridir.

WDS​

WDS, haberleşme bağlamına ilişkin tamamlayıcı bilgi taşımak için kullanılabilen opsiyonel alanlardan biridir.

ConnTime​

ConnTime, bağlantı süresi veya bağlantı kurulma bağlamını taşımak için kullanılabilen opsiyonel alanlardan biridir.

MCC​

MCC, hücresel şebeke bilgisini taşıyan opsiyonel alanlardan biridir.

MNC​

MNC, hücresel şebeke bilgisini taşıyan opsiyonel alanlardan biridir.

TAC​

TAC, hücresel erişim alanına özgü bilgiyi taşıyan opsiyonel alanlardan biridir.

Cell_ID​

Cell_ID, hücresel hücre tanımlayıcısını taşıyan opsiyonel alanlardan biridir.

Device çekirdek alan sözlüğü​

Bu bölüm, Device segmentinde çekirdek izleme için kullanılan alanların taşıma sözleşmesini normatif olarak sabitler. Aşağıdaki semantik, birim ve aralık tanımları aynı cihaz ailesindeki tüm firmware sürümlerinde korunmalıdır.

Aralık dışı değer üretildiğinde verici cihaz alanı sessizce kırpmamalıdır; ilgili paket reddedilmeli veya cihaz hata kaydına alınmalıdır. Bu davranış firmware tarafında izlenebilir olmalıdır.

Payload Segmenti​

Payload segmenti, uygulamaya özgü asıl veriyi taşır. Bu bölüm bilinçli olarak dinamik tasarlanır ve sabit alt segmentlere ayrılmaz. Temel amaç, cihazın ürettiği ölçüm, olay veya proses verisinin düz ve hafif bir yapı içinde taşınmasıdır.

{
  "Payload": {
    "PCB_T": 27.125,
    "VRMS": [229.841, 228.992, 230.104]
  }
}

Bu segmentte alanların tamamı opsiyoneldir; paketin işlevsel içeriği cihaz tipine ve gönderim senaryosuna göre değişebilir. Buna rağmen yapı tamamen başıboş değildir. Hangi değişkenlerin hangi isimle taşınacağı backend tarafındaki variables tablosu üzerinden yönetilebilir. Payload'ın kendi içinde ek katmanlara ayrılmaması bilinçli bir karardır; çünkü ilave iç segmentler çoğu durumda semantik kazançtan çok taşıma maliyeti, firmware karmaşıklığı ve backend eşleme yükü üretir. Düşük kaynaklı cihazlar için düz anahtar-değer modeli daha sürdürülebilir bir omurga sunar.

IoT üzerinden veri gönderilirken JSON paketleri boşluksuz / minified biçimde iletilmelidir. Yani üretim paketleri; satır sonu, girinti ve okunabilirlik amaçlı boşluklar içermeyen en kompakt JSON formunda taşınmalıdır. Dokümanda gösterilen örnekler okunabilirlik içindir; cihaz tarafındaki gerçek iletim biçimi bunların sıkıştırılmış/boşluksuz karşılığı olmalıdır. Bunun nedeni özellikle GSM tabanlı sistemlerde veri maliyetini düşürmek, gereksiz byte tüketimini önlemek ve saha güvenilirliğini korumaktır. Pratik deneyim gereği paket boyutunun yaklaşık 1024 byte sınırını aşmaması tercih edilir.

Payload değerleri pratikte çoğunlukla sayısal olacaktır ve mevcut beklenti, değerlerin önemli bölümünün float biçiminde ve çoğu senaryoda üç ondalık basamağa kadar anlamlı hassasiyetle taşınabileceği yönündedir. Bu ifade katı bir zorunlu hassasiyet standardı değil, uygulamadaki pratik temsil yaklaşımıdır.

Paket Bütçesi​

Bu standart yalnızca anlamsal doğruluk açısından değil, saha tarafındaki taşıma güvenilirliği açısından da değerlendirilmelidir. Özellikle GSM tabanlı cihazlarda paket boyutunun büyümesi; iletim süresi, maliyet, modem kararlılığı ve kuyruk yönetimi üzerinde doğrudan etki yaratır.

Bu nedenle paket tasarımında yaklaşık 1024 byte güvenli çalışma sınırı referans alınmalıdır. Boşluksuz/minified gönderim kuralı Payload Segmenti bölümünde normatif olarak tanımlanmıştır.

Hesap yöntemi​

Bu dokümandaki byte hesapları aşağıdaki varsayımlarla değerlendirilir:

• paketler minified JSON olarak gönderilir,
• UTF-8 kullanılır,
• alan adları bu dokümandaki isimlerle taşınır,
• hesaplara JSON anahtar adı, tırnak işaretleri, iki nokta, virgül ve köşeli parantezler dahildir,
• sayısal alanlar tipik olarak float veya int olarak düz metin biçiminde taşınır.

Buradaki hesapların amacı bit seviyesinde kesin sıkıştırma hesabı yapmak değil; tasarım kararlarını yönlendirecek mühendislik byte bütçesi oluşturmaktır.

Referans minimum paket​

Aşağıdaki minimum paket, bu sürümde tanımlanan çekirdek alanların minified JSON temsiline göre hesaplanmıştır:

{"Info":{"Command":"Timed","TimeStamp":"2026-03-26T20:10:00","ID":"00112233445566","Seq":1842},"Device":{"Power":{"B_IV":3.981,"B_AC":0.124,"B_CS":1},"IoT":{"RSSI":-79}},"Payload":{}}

Bu paketin toplam boyutu yaklaşık 183 byte'tır.

Bu, çekirdek yapının 1024 byte sınırının oldukça altında olduğunu ve esas büyümenin Payload tarafından geleceğini gösterir.

Paket boyutu güvenli çalışma sınırını aşacaksa cihaz aşağıdaki öncelik sırasını izlemelidir:

1. Opsiyonel envanter alanları çıkarılmalıdır.
2. Opsiyonel Device alanları çıkarılmalıdır.
3. Düşük öncelikli Payload alanları cihaz ailesi kuralına göre budanmalıdır.
4. Zorunlu çekirdek alanlar korunamıyorsa paket gönderilmemeli ve cihaz tarafında hata kaydı üretilmelidir.

Genel byte bütçesi yorumu​

Pratikte paket boyutunu en hızlı büyüten alanlar şunlardır:

• uzun string alanlar (ICCID, IMEI, bazı kimlik alanları),
• çok elemanlı vektörler,
• harmonik dizileri,
• aynı veri ailesinin gereksiz tekrarları,
• fazla sayıda opsiyonel telemetri alanının aynı pakette birlikte taşınması.

Bu nedenle çekirdek strateji şu olmalıdır:

• Info mümkün olduğunca sabit ve küçük tutulmalı,
• Device minimum sağlık telemetrisi ile sınırlandırılmalı,
• Payload ise ihtiyaca göre genişlemeli, fakat veri ailesi başına temsil biçimi dikkatle seçilmelidir.

Değişken bazında byte değerlendirmesi​

Bu dokümanda değişkenler için Min Bayt, Tipik Bayt ve Maks Bayt değerleri verilirken aşağıdaki anlam kullanılır:

• Min Bayt: alanın kısa/alt sınır temsili ile pakette kaplayacağı yaklaşık yer
• Tipik Bayt: sahada beklenen normal kullanım örneğine göre kaplayacağı yaklaşık yer
• Maks Bayt: pratikte anlamlı sayılabilecek uzun temsil ile kaplayacağı yaklaşık yer

Bu hesaplar değişkenin paket içindeki gerçek JSON maliyetini gösterir; yani yalnızca değerin kendisini değil, anahtar adını ve JSON sözdizimini de içerir.

Payload Değişken Yapıları​

Payload segmenti serbest biçimli alanlar kümesi olarak ele alınmaz; kontrollü bir variable type system ile değerlendirilir. Bunun amacı, aynı veri ailesinin farklı cihazlarda veya farklı firmware sürümlerinde rastgele biçimlerde temsil edilmesini önlemektir. Veri ailesi bir kez tanımlandıktan sonra, temsil modeli o aile için tutarlı kalmalıdır.

Bu sürümde aşağıdaki temel tip ailesi tanımlanır:

scalar​

scalar, tek bir fiziksel veya mantıksal değeri temsil eder.

{
  "Payload": {
    "PCB_T": 27.125
  }
}

phase_vector​

phase_vector, aynı veri ailesinin faz bazlı gösterimidir. Temsil sırası sabittir ve bu taslakta örnek sıra [R,S,T] olarak kabul edilir.

Vektör taşıma örneği:

{
  "Payload": {
    "VRMS": [229.841, 228.992, 230.104]
  }
}

Bir veri ailesi için alternatif gösterimler tasarlanabilir; ancak üretimde yalnızca değişken kataloğunda o aile için kanonik olarak tanımlanan temsil kullanılmalıdır. Aşağıdaki örnek, alternatif şema gösterimidir ve ancak ilgili değişken ailesi bu biçimde sabitlenmişse kullanılabilir:

{
  "Payload": {
    "VRMS_R": 229.841,
    "VRMS_S": 228.992,
    "VRMS_T": 230.104
  }
}

Bu modelde temel karar şudur:

• aynı veri ailesi aynı pakette yalnızca tek bir temsil biçimiyle yer alabilir,
• yani VRMS vektörü ile VRMS_R / VRMS_S / VRMS_T alanları aynı pakette birlikte taşınmamalıdır.

Bu kural, veri tekrarını ve yorum çakışmasını önlemek için zorunludur.

Bir değişken ailesinin kanonik temsil biçimi tanımlandıktan sonra, aynı aile başka bir firmware sürümünde farklı temsil ile taşınmamalıdır. Temsil değişikliği gerekiyorsa bu değişiklik yeni bir katalog revizyonu ve uyumluluk değerlendirmesi ile yönetilmelidir.

harmonic_vector​

harmonic_vector, sabit harmonik dizileri için kullanılır. Örneğin IHARM_R değişkeni belirli harmonik sıralarını taşıyorsa bu sıralar cihaz ve backend tarafında önceden tanımlı, sabit ve ortak anlaşılmış olmalıdır.

Örnek temsil:

{
  "Payload": {
    "IHARM_R": [0.812, 0.441, 0.203, 0.000, 0.000]
  }
}

Bu modelde dizi uzunluğu ve indekslerin anlamı değişken tanımının parçasıdır. İlgili pakette bazı harmonikler ölçülmemiş veya mevcut değilse ayrı bir validity mask tanımlanmaz; bunun yerine zero fill yaklaşımı kullanılır ve eksik pozisyonlar 0 ile doldurulur.

stat_vector​

stat_vector, bir değişkenin belirli bir zaman penceresi veya örnekleme periyodu içindeki özet istatistiklerini sabit sıralı bir dizi halinde taşır.

Bu sürümde önerilen sabit sıra şöyledir:

[instant, min, max, average, datacount]

• instant: paketin üretildiği andaki güncel değer
• min: ilgili zaman penceresindeki minimum değer
• max: ilgili zaman penceresindeki maksimum değer
• average: ilgili zaman penceresindeki ortalama değer
• datacount: bu özetin kaç örnek üzerinden üretildiği

Örnek:

{
  "Payload": {
    "PCB_T_STAT": [28.125, 27.900, 29.100, 28.430, 60]
  }
}

Bu tip özellikle istatistiksel özet taşıyan veri aileleri için uygundur. İlgili zaman penceresinde bazı alanlar üretilememişse veya o cihaz/algoritma tarafından hesaplanmıyorsa, bu sürümde zero fill yaklaşımı uygulanabilir.

custom_vector​

custom_vector, standart faz, harmonik veya kanal sınıflarına girmeyen fakat yine de sıralı dizi mantığıyla temsil edilmesi gereken veri aileleri için kullanılır. Bu tip yalnızca gerçek ihtiyaç halinde kullanılmalı, kontrolsüz serbest alan gibi değerlendirilmemelidir.

Enerji Parametreleri​

Bu standartta Payload segmenti düz ve dinamik kalır; ancak belirli ürün aileleri için mantıksal değişken kümeleri tanımlanabilir. Bu sürümde ilk tanımlanan küme, enerji ölçümleme cihazları için kullanılan enerji verileri kümesidir. Bu küme gerilim, akım, güç ve enerji başlıkları altında toplanır.

Bu bölümün amacı yalnızca değişken adlarını listelemek değil, her veri ailesinin neyi temsil ettiğini, hangi tipte taşındığını ve örnek veri biçimini belirginleştirmektir. Böylece ileride aynı alanların farklı cihazlarda farklı yorumlarla kullanılmasının önüne geçilir.

Ortak kurallar​

Enerji ölçüm kümesi için aşağıdaki ortak kurallar geçerlidir:

• Faz bazlı tüm vektörlerde sıra sabittir: [R,S,T].
• Harmonik vektörlerde eksen, değişken tanımında önceden sabitlenmiş harmonik sırasını temsil eder.
• Harmoniklerde eksik veya hesaplanmayan bileşenler için zero fill yaklaşımı uygulanır.
• Bu bölüm, enerji ölçümleme cihazları için ilk tanımlı payload kümesidir; ileride aynı tip sistemi korunarak yeni değişken aileleri eklenebilir.

Gerilim verileri​

Gerilim grubu, sistemin faz bazlı voltaj davranışını, temel bileşenini ve harmonik içeriğini tanımlar.

VRMS​

VRMS, fazlara ait RMS gerilim değerlerini taşır.

• Veri tipi: phase_vector
• Sıra: [R,S,T]
• Birim: Volt
• Örnek veri: [220.1,224.2,221.8]
• Tahmini byte bütçesi: min ~14, tipik ~26, maks ~41

Bu alan, üç fazlı sistemlerde her fazın efektif gerilim seviyesini doğrudan gösterir. Tek fazlı sistemlerde bu tip alanların nasıl daraltılacağı veya tek elemanlı vektör olarak mı tutulacağı ayrıca karara bağlanabilir.

FQ​

FQ, sistem frekansını taşır.

• Veri tipi: scalar
• Birim: Hertz
• Örnek veri: 50.000
• Tahmini byte bütçesi: min ~7, tipik ~12, maks ~18

Frekans bilgisi tekil bir büyüklük olarak ele alınır ve bu sürümde ayrı fazlar için parçalanmaz.

VFUND​

VFUND, gerilimin temel bileşenini faz bazlı olarak taşır.

• Veri tipi: phase_vector
• Sıra: [R,S,T]
• Birim: Volt
• Örnek veri: [219.8,223.7,221.1]
• Tahmini byte bütçesi: min ~15, tipik ~27, maks ~42

Bu alan, toplam RMS büyüklükten farklı olarak temel frekans bileşenini izlemek için kullanılır.

VHARM_R, VHARM_S, VHARM_T​

Bu alanlar her faz için gerilim harmonik dizilerini taşır.

• Veri tipi: harmonic_vector
• Eksen örneği: [3,5,7,9,11]
• Birim: Volt
• Örnek veri: [0.012,0.031,0.020,0.006,0.000]
• Tahmini byte bütçesi: min ~17, tipik ~42, maks ~67

Her değişken tek bir faza aittir. Örneğin VHARM_R, R fazının seçilmiş harmonik bileşenlerini sabit sıralı dizi halinde taşır. İlgili harmonik değeri mevcut değilse veya hesaplanmıyorsa alan kaldırılmaz; 0 ile doldurma yaklaşımı korunur.

Akım verileri​

Akım grubu, faz bazlı yük akımını, tepe akım davranışını, temel bileşeni ve harmonik akım içeriğini tanımlar.

IRMS​

IRMS, faz bazlı RMS akım değerlerini taşır.

• Veri tipi: phase_vector
• Sıra: [R,S,T]
• Birim: Amper
• Örnek veri: [5.124,4.982,5.301]
• Tahmini byte bütçesi: min ~14, tipik ~23, maks ~38

IPEAK​

IPEAK, fazlara ait tepe akım değerlerini taşır.

• Veri tipi: phase_vector
• Sıra: [R,S,T]
• Birim: Amper
• Örnek veri: [7.410,7.052,7.630]
• Tahmini byte bütçesi: min ~15, tipik ~24, maks ~39

Bu alan ani yük davranışlarını, pik akım etkilerini veya sistem zorlanmalarını anlamakta yararlı olabilir.

IFUND​

IFUND, akımın temel bileşenini faz bazlı taşır.

• Veri tipi: phase_vector
• Sıra: [R,S,T]
• Birim: Amper
• Örnek veri: [4.910,4.755,5.110]
• Tahmini byte bütçesi: min ~16, tipik ~25, maks ~40

IHARM_R, IHARM_S, IHARM_T​

Bu alanlar her faz için akım harmonik dizilerini taşır.

• Veri tipi: harmonic_vector
• Eksen örneği: [3,5,7,9,11]
• Birim: Amper
• Örnek veri: [0.012,0.031,0.020,0.006,0.000]
• Tahmini byte bütçesi: min ~17, tipik ~42, maks ~67

Örneğin IHARM_R, R fazına ait seçilmiş harmonik akım bileşenlerini sabit dizi halinde taşır. Eksik veya hesaplanmayan harmonik değerlerinde zero fill yaklaşımı uygulanır.

Güç verileri​

Güç grubu, faz bazlı aktif, reaktif, görünür ve güç faktörü ilişkili büyüklükleri taşır.

P​

P, faz bazlı aktif güç değerlerini taşır.

• Veri tipi: phase_vector
• Sıra: [R,S,T]
• Birim: Watt
• Örnek veri: [1050.220,980.114,1120.450]
• Tahmini byte bütçesi: min ~10, tipik ~34, maks ~52

Q​

Q, faz bazlı reaktif güç değerlerini taşır.

• Veri tipi: phase_vector
• Sıra: [R,S,T]
• Birim: var
• Örnek veri: [120.410,98.200,132.005]
• Tahmini byte bütçesi: min ~10, tipik ~31, maks ~49

S​

S, faz bazlı görünür güç değerlerini taşır.

• Veri tipi: phase_vector
• Sıra: [R,S,T]
• Birim: VA
• Örnek veri: [1060.500,989.700,1132.100]
• Tahmini byte bütçesi: min ~10, tipik ~34, maks ~52

PF​

PF, faz bazlı toplam güç faktörünü taşır.

• Veri tipi: phase_vector
• Sıra: [R,S,T]
• Birim: -
• Örnek veri: [0.991,0.990,0.989]
• Tahmini byte bütçesi: min ~11, tipik ~20, maks ~35

PFUND​

PFUND, temel bileşen üzerinden hesaplanan güç faktörünü faz bazlı taşır.

• Veri tipi: phase_vector
• Sıra: [R,S,T]
• Birim: -
• Örnek veri: [0.995,0.994,0.996]
• Tahmini byte bütçesi: min ~14, tipik ~23, maks ~38

QFUND​

QFUND, temel bileşene karşılık gelen reaktif güç büyüklüğünü faz bazlı taşır.

• Veri tipi: phase_vector
• Sıra: [R,S,T]
• Birim: var
• Örnek veri: [100.120,91.540,108.310]
• Tahmini byte bütçesi: min ~14, tipik ~31, maks ~49

Enerji verileri​

Enerji grubu, faz bazlı birikimli enerji büyüklüklerini taşır.

AE​

AE, aktif enerji büyüklüğünü faz bazlı taşır.

• Veri tipi: phase_vector
• Sıra: [R,S,T]
• Birim: Wh
• Ölçek: ondalık değerler Wh cinsinden doğrudan taşınır, ek katsayı kullanılmaz
• Örnek veri: [1250.200,1198.400,1304.800]
• Tahmini byte bütçesi: min ~11, tipik ~34, maks ~55

RE_L​

RE_L, faz bazlı endüktif reaktif enerji büyüklüğünü taşır.

• Veri tipi: phase_vector
• Sıra: [R,S,T]
• Birim: varh
• Ölçek: ondalık değerler varh cinsinden doğrudan taşınır, ek katsayı kullanılmaz
• Örnek veri: [85.200,72.100,91.300]
• Tahmini byte bütçesi: min ~13, tipik ~28, maks ~46

RE_G​

RE_G, faz bazlı kapasitif veya karşı yöndeki reaktif enerji büyüklüğünü taşır.

• Veri tipi: phase_vector
• Sıra: [R,S,T]
• Birim: varh
• Ölçek: ondalık değerler varh cinsinden doğrudan taşınır, ek katsayı kullanılmaz
• Örnek veri: [12.400,10.200,14.100]
• Tahmini byte bütçesi: min ~13, tipik ~28, maks ~46

Bu alanlar birikimli enerji davranışını izlemek için önemlidir. AE, RE_L ve RE_G alanlarında yukarıdaki birim ve ölçek standardı normatiftir; farklı birimle taşıma yapılacaksa yeni revizyon kararı gerektirir.

Örnek paket​

Aşağıdaki örnek, bu standartta tanımlanan yapının temsil amaçlı örneğidir:

{
  "Info": {
    "Command": "Timed",
    "TimeStamp": "2026-03-26T20:10:00",
    "ID": "00112233445566",
    "Seq": 1842,
    "Firmware": "1.0.7"
  },
  "Device": {
    "Power": {
      "B_IV": 3.981,
      "B_AC": 0.124,
      "B_CS": 1,
      "B_T": 31.250
    },
    "IoT": {
      "RSSI": -79,
      "ConnTime": 12,
      "MCC": 286,
      "MNC": 1,
      "Cell_ID": 123456
    }
  },
  "Payload": {
    "PCB_T": 27.125,
    "VRMS": [229.841, 228.992, 230.104],
    "IHARM_R": [0.812, 0.441, 0.203, 0.000, 0.000]
  }
}

Örnekteki sayısal içerikler yalnızca yapıyı somutlaştırmak amacıyla verilmiştir; normatif örnekten ziyade temsil örneğidir.

Sürümleme ve Geriye Dönük Uyumluluk​

Bu doküman, paket sözleşmesinin normatif sürümünü tanımlar. Bu sürümde paket içinde ayrı bir şema sürüm alanı taşınmaz; sürüm yönetimi doküman revizyonu ve değişken kataloğu revizyonu üzerinden yürütülür.

Sürümleme ilkesi​

1. Alan ekleme yalnızca opsiyonel alan olarak yapılıyorsa geriye dönük uyumlu kabul edilir.
2. Mevcut bir alanın adını, tipini, anlamını, sırasını veya birimini değiştirmek geriye dönük uyumsuz değişiklik sayılır.
3. Bir phase_vector, harmonic_vector, stat_vector veya custom_vector alanının indeks anlamını değiştirmek geriye dönük uyumsuz değişiklik sayılır.
4. Yeni Command değeri eklemek, alıcı sistemler bu değeri güvenli biçimde reddetmeyi veya görmezden gelmeyi desteklemiyorsa geriye dönük uyumsuz değişiklik sayılır.

Alıcı ve verici kuralları​

1. Verici, bu dokümanda zorunlu tanımlanan alanları eksiksiz üretmelidir.
2. Alıcı, tanımlı çekirdek segmentler korunuyorsa bilinmeyen opsiyonel alanları paketi reddetmeden görmezden gelebilmelidir.
3. Alıcı, zorunlu alanı eksik veya tip kuralını ihlal eden paketleri geçersiz saymalıdır.
4. Aynı cihaz ailesi için geriye dönük uyumsuz değişiklik gerekiyorsa yeni doküman revizyonu ile birlikte backend ve firmware geçiş planı ayrıca tanımlanmalıdır.