Elektrikli Araç Şarj İstasyonları Yönetim

Yazılımı Teklif Şartnamesi

1. GİRİŞ
1.1. İş bu şartnamede tedarikçi firmanın proje kapsamında geliştireceği yazılımların temel hususları
ve isterleri yer almaktadır.
1.2. Tedarikçi firma bu şartname kapsamında yer alan tüm hükümleri eksiksiz şekilde geliştirmeyi
taahhüt edecektir.

2. ŞARTNAMENİN KONUSU
2.1. İŞİN KONUSU: Bu şartname SATIN ALAN FİRMA aşağıda belirtilmiş olan senaryolar dahilinde
ihtiyaçlarını karşılayan Elektrikli Araç Şarj İstasyonları Yönetim Yazılımının geliştirilmesini konu
alır.
2.2. AMAÇ: Ön görülen senaryolar dahilinde tüm isterleri karşılayan yönetim yazılımın geliştirilmesi,
yayınlanması, bakım ve desteğinin sağlanması.
2.3. KAPSAM: Bu şartname SATIN ALAN FİRMA’nın istekleri doğrultusunda özel olarak geliştirilecek
ve tüm fikri mülkiyetleri SATIN ALAN FİRMA’ya devredilecek özel yazılım projesini kapsar.

3. TANIMLAR
3.1. OCPP: Open Charge Point Protocol (Açık Şarj Noktası Protokolü), Elektrikli araç şarj istasyonları
ile şarj ağının arasındaki iletişimi sağlayan protokoldür. Open Charge Alliance bünyesinde
geliştirilmeye devam edilmektedir.
3.2. MERKEZİ SİSTEM: OCPP protokolüne göre tüm istasyonların bağlanacağı sunucu uygulamasına
verilen isimdir.
3.3. OTURUM: Aktif Şarj İşlemi
3.4. ŞARJ NOKTASI (EVSE): Şarj üniteleridir.
3.5. SOKET/PLUG: Şarj ünitelerinin üzerinde bulunan çıkış prizleridir.
3.6. ŞARJ İSTASYONU (LOCATION): Birden çok şarj ünitesinin bir arada bulunduğu fiziksel alan.
4. TEKNİK ŞARTNAME HÜKÜMLERİ
4.1. GENEL ŞARTLAR
4.1.1. STANDARTLARA UYUM
4.1.1.1. Geliştirilecek olan yazılımda aşağıdaki standartların eksiksiz olarak desteklenmesi
beklenmektedir.
4.1.1.1.1. OCPP 1.6 ve OCPP 2.0.1 sürümleri tam olarak desteklenecektir
4.1.1.1.2. OCPI 2.0
4.1.1.1.3. Smart Charging özelliklerinin tam olarak desteklenmesi
4.1.1.1.4. Plug&Charge özelliklerinin desteklenmesi
4.1.1.1.5. V2G altyapısının sağlanması
4.1.1.1.6. S.A.F.E – OCMF desteğinin sağlanması
4.1.2. REGÜLASYONLARA UYUM
4.1.2.1. Geliştirilecek olan sistemde aşağıdaki regülasyonlara uyulması beklenmektedir.
4.1.2.1.1. EPDK
4.1.2.1.2. NSV, Eichrecht
4.1.2.1.3. EVSCP
4.1.2.1.4. NEVI
4.2. SENARYOLAR
4.2.1. YEREL KULLANIM SENARYOSU
4.2.1.1. Yerel kullanım senaryosunda şarj istasyonu ve merkezi sistem yazılımı bir
intranet/extranet üzerinde internet erişimine kapalı şekilde çalışan senaryodur.
4.2.1.2. Bu senaryoda şarj istasyonları yerel ağ üzerinde bulunan merkezi sisteme erişim
sağlarlar.
4.2.1.3. Yerel kullanım senaryosu minimum 100 şarj noktasına aynı anda hizmet verecek
şekilde tasarlanacaktır.
4.2.1.4. Yerel kullanım senaryosuna göre kurulumu yapılan sunucu uygulaması minimum
sistem gereksinimleri ile çalışabilecektir. Bu uygulama için özel bir sunucu kurulumu
yapılması gerekmeyecektir.
4.2.1.5. Yerel kullanım senaryosunda kullanılacak olan veri tabanı ve alt sistemler lisans
maaliyeti yaratmayacaktır.
4.2.1.6. Yerel kullanım senaryosuna göre geliştirilen yazılım kurulum ve konfigürasyonu
minimum teknik beceriyle gerçekleştirilebilecektir. “Installshield” yada benzeri bir
 yöntemle yereldeki cihaza kurulabilecek ve tek bir konfigürasyon dosyası ile sistem
kullanıma hazır duruma getirilebilecektir.
4.2.1.7. MERKEZİ SİSTEM YÖNETİM BÖLÜMÜ
4.2.1.7.1. Şarj Noktası Yönetimi: Yeni şarj noktaları ekleme, silme ve düzenleme
gibi tüm işlemlerin yapılabildiği bölümdür. Bu bölümde şarj noktalarına
doğrudan servis komutları gönderebilme ve cihazın anlık durumunu canlı
(realtime) olarak görüntüleyebilme olacaktır.
4.2.1.7.1.1. Şarj Noktası Monitoring: Şarj noktalarının ürettiği tüm mesaj kayıtların
görüntülenebildiği ve filtrelenebildiği bölümdür.
4.2.1.7.1.2. Şarj Noktası Uzaktan Yönetim: Şarj noktasına uzaktan servis
komutlarının gönderilebilmesine olanak sağlayan arayüzdür. Yöneticiler
bu bölümden şarj noktasına OCPP protokolünün desteklediği tüm
komutları veya servis parametreleri gönderebilir, cihazı durdurabilir,
başlatabilir veya bakım moduna alabilir.
4.2.1.7.2. Müşteri Yönetimi: Sistemi kullanacak olan kullanıcıların yönetildiği
bölümdür. Bu bölüm ile yeni müşteri tanımlama, silme ve düzenleme
işlemlerinin tümü yapılabilecektir.
4.2.1.7.2.1. Müşteri Grupları: Müşteriler, müşteri gruplarına ayrılabilir ve bu müşteri
gruplarının her biri için ayrı fiyat tarifeleri uygulanabilmelidir.
4.2.1.7.2.2. Müşteri Bakiye İşlemleri: Her müşteri birden fazla IDTag’a sahip olabilir
ve her IDTag için farklı bakiyeler tutulabilir. Bakiye işlemleri bölümü bu
hesapların içerisine bakiye yükleme, eksiltme, ekstre alma raporlama
dışarı aktarma gibi tüm özelliklerin bulunduğu bölümdür.
4.2.1.7.2.3. Anonim müşteriler: Müşteriler her zaman sisteme kayıt olmak zorunda
olmayabilirler. Bu yüzden anonim işlemler anonim müşteri kayıtları
üzerinden gerçekleşmelidir.
4.2.1.7.3. Oturum Yönetimi: Aktif şarj işlemlerinin yönetildiği bölümdür. Bu
ekranda anlık olarak tüm aktif şarj işlemlerini görüntüleyebilir ve aktif
oturumun üzerinde operatif işlemler gerçekleştirilebilir.
4.2.1.7.3.1. Anlık Oturum Monitoring Ekranı: Bu ekran yetkili kişilerin anlık şarj ağını
ve oturum durumlarını monitörize etmelerini sağlamak ve durum
bilgilerini görüntülemesine olanak sağlamak için geliştirilecektir.
 4.2.1.7.3.2. Oturum Yönetimi: Durdurma, İptal Etme, Tekrar Başlatma, Sorun
Giderme, Uzaktan Komut Yürütme, Geri Ödeme gibi işlemlerin yapılacağı
bölümdür.
4.2.1.7.4. İşlemler: Gerçekleşen tüm şarj işlemlerinin kayıtlarının tutulduğu
bölümdür.
4.2.1.7.4.1. İşlem geçmişi: Bu bölümde yöneticiler gerçekleşen şarj işlemlerini ve
durumlarını görüntüleyebilecek ve anlık özet bilgilerini (harcanan güç, kar,
işlem sayısı vb.) mikro grafiklerle anlaşılır şekilde izleyebileceklerdir.
4.2.1.7.4.2. İşlem Yönetimi: Bu bölümde yöneticiler gerçekleşen şarj işlemi üzerinde,
geri ödeme, ek bedel ekleme, işlemin kayıtlarını görme, faturalandırma
gibi işlemlerini yapabileceklerdir.
4.2.1.7.4.3. İşlem Raporları: Gerçekleşen Şarj işlemleri üzerinde detaylı filtrelemeler
uygulayarak (tarih, süre, tutar, ID tag, şarj noktası, fiyat listesi ve diğer
tüm parametreler) çeşitli raporları sistemden alabilecektir.
4.2.1.7.5. Rezervasyonlar: Şarj noktalarının rezervasyon kayıtlarının yönetildiği
bölümdür. Bu bölümden yöneticiler mevcut rezervasyonları görebilir yeni
rezervasyon kayıtları açabilirler.
4.2.1.7.6. Tarifeler: Şarj işlemlerinin ücret bilgilerinin yönetildiği bölümdür.
Yöneticiler belirli tarih aralıkları, müşteri grupları yada şarj istasyonları (AC/DC)
için özel fiyat tarifeleri belirleyebilirler. Fiyat tarifeleri, şarj işlemi birim fiyatı,
park ücreti yada diğer ek ücretler gibi serbest fiyatlamaya olanak sağlayacak
şekilde tasarlanmalıdır. Bu sayede çok sayıda fiyat senaryosuna cevap
verebilecektir. Ayrıca fiyat tarifelerindeki vergi ve komisyon oranları da
belirlenebilmelidir. Fiyat tarifelerinde maaliyetlere de yer verilmelidir. Bu
sayede sistemde kar/zarar hesabı yönetilebilir.
4.2.1.7.7. Şarj Profilleri: Bu bölümden şarj noktalarının kullanacağı şarj profilleri
oluşturulabilir. Şarj profilleri OCPP protokolünün belirlediği kurallara göre
oluşturulup zaman/tarih bazlı olarak işletilebilir.
4.2.1.7.8. Sistem Parametreleri: Yerel şarj ağının yönetilmesi için gerekli olan
sistem parametrelerinin tanımlandığı bölümdür. Bu bölümde yerelleştirme
ayarları, görünüm ayarları, 3.parti servis bağlantıları ve servis ayarları gibi tüm
parametreler yöneticiler tarafından girilebilir.
 4.2.1.7.9. Kullanıcılar: Sistemi kullanacak olan kullanıcıların yönetildiği bölümdür.
Bu bölümde kullanıcı ekleme, silme ve düzenleme gibi işlemler yapılabilecektir.
Sistem kullanıcılarının tüm yaptığı işlemler kullanıcı kimliği ile audit amaçlı kayıt
altına alınacaktır. Kayıt altına alınan loglar bu bölümden Super Admin
tarafından görüntülenebilecektir. Ayrıca her kullanıcı Erişim Kontrol Listesi (ACL)
tarafından yetkilendirilebilir olacaktır.
4.2.1.7.10. Diğer Özellikler:
4.2.1.7.10.1. Yönetim yazılımı, güncellemelerin otomatik olarak
uygulanabileceği bir mekanizma sağlamalıdır.
4.2.1.7.10.2. Geriye dönük uyumluluk kapsamında daha önceki verilerin
uygun şekilde desteklenmesi gereklidir.
4.2.1.7.10.3. White label özelliklerini barındırmalıdır.
4.2.1.8. MERKEZİ SİSTEM SUNUCU BÖLÜMÜ
4.2.1.8.1. OCPP 1.6 ve OCPP 2.0.1 sürümlerini tam olarak destekleyecektir.
4.2.1.8.2. Web Socket veya HTTP/HTTPS gibi uygun iletişim protokolleri kullanarak
istemcilerle güvenli iletişim sağlanmalıdır.
4.2.1.8.3. Minimum 100 adete kadar şarj noktasına aynı anda hizmet
verebilecektir.
4.2.1.8.4. İstekleri mesaj kuyruğuna alıp FIFO’ya göre cevap verecektir. Tüm
istekleri karşılayacak buffer’a sahip olacaktır.
4.2.1.8.5. Tüm istekleri (Gelen ve Giden) kayıt defterine kayıt edecektir.
4.2.1.8.6. SSL/TLS protokolü kullanarak verilerin güvenli iletimi sağlanmalıdır.
4.2.1.8.7. Kimlik doğrulama mekanizması sunulmalı ve yetkilendirme işlemleri
desteklenmelidir.
4.2.1.8.8. Socket bağlantıları ile anlık İletişimi yönetici ve monitoring ekranlarına
doğrudan iletebilecektir.
4.2.1.8.9. Oturum bilgilerini hafızasında tutabilecek, herhangi bir deadly fail
durumunda program crash olsa bile servis başlatıldığında bu bilgileri tekrar
hafızasına alıp kaldığı yerden devam edebilecektir.
4.2.1.8.10. Offline List, Charging Profile ve Configurations gibi parametreleri
istemcilere gönderme/alma işini yerine getirecektir.
 4.2.1.8.11. Otomatik Firmware denetimi yapmalı ve gerekli görülmesi durumunda
istasyonları güncelleyebilmelidir.
4.2.1.8.12. Uzaktan gönderilen komutları istemcilere asenkron olarak iletebilecek
gelen cevapları yönetim arabirimlerine iletebilecektir.
4.2.1.8.13. Sunucu uygulamasında performans son derece önemli olacaktır. Bu
bağlamda maksimum istek işleme süresi 200ms geçmeyecektir. Gerekli sistem
mimarisi bu husus dikkate alınarak tasarlanacaktır.
4.2.1.8.14. İstasyon ve şarj işlemleriyle ilgili önemli olaylar için bildirim mekanizması
sağlanmalıdır.
4.2.1.8.15. Şarj profilleri ve yöneticilerin belirlediği kurallar dahilinde Dinamik Yük
Dağıtımını (Dynamic Load Management) desteklemelidir.
4.2.1.8.16. Sunucu yazılımının güncellemelerinin otomatik olarak uygulanabileceği
bir mekanizma sağlanmalıdır.
4.2.1.8.17. Geriye dönük uyumluluk kapsamında daha önceki şarj istasyonu
verilerinin uygun şekilde desteklenmesi gereklidir.
4.2.1.8.18. Sunucu bakımı sırasında istasyonların etkilenmemesi için bakım modu
sunulmalıdır.
4.2.1.8.19. White label özelliklerini barındırmalıdır.
4.2.1.9. ÖDEME SİSTEMLERİ
4.2.1.9.1. Nakit para ile ödeme yapılabilmelidir
4.2.1.9.2. Sanal poslar üzerinden kredi kartı ile ödeme yapılabilmelidir.
4.2.1.9.3. 3. Parti ödeme kuruluşları üzerinden ödeme yapılabilmelidir.
4.2.1.9.4. Yapılan tüm ödeme işlemleri güvenli şekilde kayıt edilmeli, düzenlemeye
ve silmeye karşı korunmalıdır.
4.2.1.9.5. Tüm bu kanallar üzerinden geri ödeme yapılabilmesi sağlanmalıdır.
4.2.1.9.6. Ödemeler ile ilgili tüm raporlar alınabilmelidir.
4.2.2. ŞARJ İŞLETMESİ KULLANIM SENARYOSU
4.2.2.1. Şarj işletmesi senaryosu, bir veya birden fazla noktada bulunan şarj istasyonlarını
ve bu şarj istasyonları içerisinde bulunan tüm şarj noktalarının internet üzerinden
güvenli bir şekilde yönetilmesidir.
4.2.2.2. Bu senaryoda şarj istasyonları ve şarj noktaları internet üzerinde bulunan
merkezi sisteme erişim sağlarlar.
4.2.2.3. Yerel kullanım senaryosu minimum 500.000 şarj noktasına aynı anda hizmet
verecek şekilde tasarlanacaktır.
4.2.2.4. Şarj işletmesi kullanımı senaryosunda kurulum özel sunuculara yada bulut
tabanlı sistemlere yapılabilecek şekilde olmalıdır. Bulut tabanlı kurulumlarda çeşitli
kaynaklar (Object storage, logging, database, load balancing, high availability vb.)
bulut altyapısına uygun şekilde geliştirilecektir.
4.2.2.5. Şarj işletmesi kullanım senaryosunda kullanılacak olan ek yazılımların lisans
maaliyeti minimum seviyede maaliyet yaratacak şekilde tasarlanacaktır.
4.2.2.6. Şarj işletmesi kullanım senaryosunda yazılım bir CI/DI pipe’ı ile deploy edilecek,
yazılım güncellemelerini doğrudan ve eksiksiz alacaktır.
4.2.2.7. Geriye dönük uyumluluk kapsamında daha önceki verilerin uygun şekilde
desteklenmesi gerekmektedir. Bu kapsamda uygun migration işlemleri versiyonlama
şekilde yapılmalıdır.
4.2.2.8. MERKEZİ SİSTEM YÖNETİM BÖLÜMÜ
4.2.2.8.1. Merkezi sistem yönetim bölümü yerel kullanım senaryosundaki tüm
özellikleri desteklemelidir. Ayrıca aşağıdaki öğeler de yer almalıdır.
4.2.2.8.2. Harita: Yöneticilerin şarj ağını görsel olarak takip edebilmelerini sağlayan
bölümdür. Bu bölümde yöneticiler harita üzerinden şarj istasyonlarını ve bu
istasyonlarda yer alan şarj noktalarını ve soket durumlarını görebilir, toplam
güç, kullanımda olan güç gibi diğer metrikleri izleyebilirler.
4.2.2.8.3. Alt Yüklenici: Alt yükleniciler sisteme dahil olmak isteyen şarj istasyonu
sahiplerinin yönetildiği bölümdür. Bu bölümde dış kaynak şarj istasyonları ve
şarj noktaları sisteme dahil edilir ve komisyon karşılığı bu noktalardan
müşterilere şarj işlemi hizmeti sunulur.
4.2.2.8.3.1. Sözleşme Yönetimi: Alt yüklenici kabulü ve şözleşmelerin yönetiminin
yapılmasını sağlayan bölümdür.
4.2.2.8.3.2.Hakediş Yönetimi ve Ödeme: Alt yüklenicilerin hesap bakiyelerinin ve
hakedişlerinin yönetildiği ve payout işlemlerinin yapıldığı bölümdür.
4.2.2.8.4. Bilgilendirme Servisleri: Mobil uygulamalara anlık bildirimler
gönderilmesini sağlayan bölümdür. Bu sayede sisteme kayıtlı olan tüm
müşteriler manuel sistem güncellemelerini alabilirler.
 4.2.2.8.5. Webhooks: Sistem üzerinde oluşan olayların tümünün dış noktaya
güncelleme iletmesini sağlayan bölümdür. Şarj işlemleri, müşteri işlemleri, hata
bildirimleri gibi sistem üzerindeki tüm operasyonlar web hooklar tarafından bir
diğer sisteme transfer edilebilir. Bu sayede sistemler arasındaki entegrasyon
sorunsuz bir şekilde işleyebilir.
4.2.2.8.6. Regülasyon Uyumlulukları: Elektrikli araçlar yaygınlaştıkça ülkeler bu
işlemler için regülasyonlar getirmektedirler. Merkezi sistem yönetim paneli tüm
regülasyon işlemlerini yönetmekle görevlidir. Sistem varsayılan olarak EPDK,
Eichrecht, EVSCP, NEVI regülasyonlarını tam olarak entegre edecektir. Bunların
yanında yeni oluşabilecek regülasyonlara karşı da uyumluluk göstermesi
beklenmektedir.
4.2.2.8.7. Dolaşım (Roaming): Merkezi sistem yönetim paneli OCPI protokolü ile
roaming işlemlerini yönetebilmelidir. Sistem OCPI destekleyen EMSP’lere
doğrudan entegre olabilmeli ve aradaki veri akışını sağlayabilmelidir. Roaming
için kullanılacak OCPI sürümü minimum 2.2 olmalıdır.
4.2.2.9. SELF SERVİS İŞLEMLERİ
4.2.2.9.1. Şarj İşletmesi Kullanım Senaryosunda müşterilerin sisteme kayıt
olmaktan şarj işlemine geçmelerine kadar olan tüm işlemleri self-servis olarak
tamamlanması beklenmektedir. Bu nedenle kullanıcılara bir panel sunulmalıdır.
4.2.2.9.2. Müşteri authentication ve authorization işlemlerinin tamamını güvenli
bir şekilde kendi yapabilmelidir.
4.2.2.9.3. Müşteri kişisel bilgilerini, araç bilgilerini, faturalandırma bilgilerini
düzenleyebilmeli girişlerini sağlayabilmelidir.
4.2.2.9.4. Müşteri panel üzerinden yeni bir ID Tag oluşturabilmeli ve bu ID tag
üzerine bakiye işlemlerini kredi kartı ile kendi başına yapabilmelidir.
4.2.2.9.5. Müşteri, panelinden şarj ağının haritasını görebilmeli ve ilgilendiği şarj
soketinde tüm şarj işlemlerini yapabilmelidir.
4.2.2.9.6. Müşteri, panelinden daha önce gerçekleştirdiği şarj işlemlerine dair
gerekli tüm kayıtlara şeffaf ve güvenli bir şekilde erişebilmeli ve bu kayıtları
dışarıya aktarabilmelidir.
4.2.2.9.7. Müşteri yapılan tüm işlemlere dair şarj oturum işlem kayıtlarını
görebilmelidir.
 4.2.2.9.8. Müşteri gerçekleştirdiği tüm bakiye işlemlerini şeffaf ve güvenli bir
şekilde görüntüleyebilmeli ve dışarıya aktarabilmelidir.
4.2.2.9.9. Kişisel verilerin güvenliği ve saklanması kapsamında, müşteri tüm kişisel
verilerini dışarı aktarma, sistemden silinmesini isteme gibi tüm yasal
yükümlülükleri gerçekleştirmelidir.
4.2.2.10. ANONİM İŞLEMLER
4.2.2.10.1. Sistem üzerinde kayıt olmaksızın şarj işlemi gerçekleştirmek için
tasarlanan bölümdür.
4.2.2.10.2. QR kodu ile doğrudan kredi kartı ödemesi yapılıp şarj işlemi
başlatılabilmelidir.
4.2.2.10.3. Anonim yapılan işlemlerde vergilendirme için kullanıcıdan gerekli bilgiler
(VKN, IDNO vs) edinilmeli ve işlemler bu bilgilere kayıt edilmelidir.
4.2.2.10.4. Anonim işlemlerde fraud işlemleri engellemek için OTP kullanılması
gerekmektedir.
4.2.2.11. MOBİL UYGULAMALAR
4.2.2.11.1. Mobil uygulamalar self-servis ekranlarında yapılabilen tüm işlemleri
mobil cihazlar üzerinden yapabilecek şekilde tasarlanacaktır.
4.2.2.11.2. Mobil uygulamalar ANDROİD ve İOS sistemleri üzerinde çalışabilecektir.
4.2.2.11.3. Mobil uygulamalar kullanıcı girişi yapılmaksızın anonim işlemlere izin
verebilmelidir.
4.2.2.11.4. Mobil uygulamalar real-time durum bilgisini harita üzerinden kullanıcıya
sunabilmelidir.
4.2.2.11.5. Mobil uygulama üzerinden müşteriler ilgilendikleri sokete rezervasyon
yapabilmelidir.
4.2.2.11.6. Mobil uygulamalar üzerinden müşteriler arıza/istek talep formları
gönderebilmelidirler.
4.2.2.11.7. Mobil uygulama üzerinden müşteriler şarj noktasına yol tarifi
alabilmelidirler.
4.2.2.11.8. Mobil uygulamalar semantik versiyonlama kurallarına uygun olarak
güncellenmelidir. Mobil uygulamalarda güncelleme yapıldığında eski sürümlerin
tamamının işlevlerine devam etmesi sağlanacaktır. Bu işlem için gerekirse api
servisleri de aynı versiyonlama kurallarına göre versiyonlanacaktır.
 4.2.2.11.9. Mobil uygulamalar minimum kullanıcı izni ile çalışacaktır.
4.2.2.11.10. Mobil uygulamalar white label için uygun olarak hazırlanacaktır.
4.2.2.12. API
4.2.2.12.1. Şarj İşletmesi kullanım senaryosunda API desteği sağlanmalıdır.
4.2.2.12.2. API’ler REST kurallarına uygun olarak tasarlanmalıdır.
4.2.2.12.3. API’ler semantik versiyonlama kurallarına uygun olarak hazırlanmalıdır.
4.2.2.12.4. API servisleri, scopelar üzerinden yetkilendirilebilmelidir.
4.2.2.12.5. API anahtarları ancak sistem yöneticileri tarafından oluşturulabilir.
4.2.2.12.6. API dökümantasyonu detaylı açıklamalar yapılarak ve örnekler verilerek
hazırlanmalıdır.
4.2.2.12.7. API’ler üzerinden sistemdeki tüm işlemler yapılabilmelidir. Bu işlemler
arasında OCPP protokolü üzerinden şarj noktaların yönetimleri de dahildir.
4.2.2.13. MERKEZİ SİSTEM SUNUCU BÖLÜMÜ
4.2.2.13.1. Yerel Kullanım Senaryosu merkezi sistem sunucu bölümünün tüm
işlemlerini kapsamalıdır.
4.2.2.13.2. Yatay olarak scale edilebilmelidir.
4.2.2.14. DOLAŞIM (ROAMING)
4.2.2.14.1. EMSP rolü roaming için aktif edilmeli, bu sayede alt ağların kullanımı
sağlanmalıdır.
4.2.2.14.2. Komisyon ödemeleri yönetimi sağlanmalıdır.
4.2.2.15. ÖDEME SİSTEMLERİ
4.2.2.15.1. Sanal poslar üzerinden kredi kartı ile ödeme yapılabilmelidir.
4.2.2.15.2. 3. Parti ödeme kuruluşları üzerinden ödeme yapılabilmelidir.
4.2.2.15.3. Kart saklama servisleri kullanılarak kullanıcıların güvenli bir şekilde kredi
kartlarını sisteme tanımlamaları sağlanmalıdır.
4.2.2.15.4. Yapılan tüm ödeme işlemleri güvenli şekilde kayıt edilmeli, düzenlemeye
ve silmeye karşı korunmalıdır.
4.2.2.15.5. Tüm bu kanallar üzerinden geri ödeme yapılabilmesi sağlanmalıdır.
4.2.2.15.6. Ödemeler ile ilgili tüm raporlar alınabilmelidir.
4.3. TEKNİK ÖZELLİKLER
4.3.1. YAZILIM GELİŞTİRME EVRELERİ
 4.3.1.1. Gereksinim Analizi: Proje başlangıcında gereksinim analizi yapılmalıdır.
Gereksinim analizinde senaryoların tüm ihtiyaçlarına uygun detaylı bir analiz raporu
sunulmalıdır.
4.3.1.2. Mimari Tasarım: Yazılım projesinin mimari tasarımı en güncel mimari yaklaşımlar
ele alınarak tasarlanmalı sistem life cycle süresi 8 yıl olarak düşünülmelidir.
4.3.1.3. Test Etme: Yazılım geliştirilirken test edilebilirlik kurallarına uyularak
geliştirilmelidir. Birim testleri, Entegrasyon testleri, Sistem testleri, Performans
testleri ve Güvenlik testleri stratejisi sunulması beklenilmektedir.
4.3.2. YAZILIM GELİŞTİRME STANDARTLARI
4.3.2.1. Yazılımın Dili: Yazılım yüksek seviye yazılım geliştirme dilleri ile geliştirilmelidir.
Bu diller Golang, Rust, Java veya C# olmalıdır.
4.3.2.2. Kodlama Standartları: Yazılım geliştirilirken mutlaka belirli kodlama standartları
dahilinde geliştirilmelidir. Kullanılacak dillere göre uygun kodlama standartları
seçilmeli ve proje başlangıcında bildirilmesi beklenmektedir.
4.3.2.3. Veritabanı: ACID destekleyen ilişkisel veri tabanı kullanılmalıdır.
4.3.2.4. Caching: Sistem ön bellekleme yönetimi yapmalı ve mümkün olan her noktada
önbellek yeteneklerinden yararlanmalıdır.
4.3.2.5. Dökümantasyon: Yazılımın tüm bölümleri için ayrıntılı dökümantasyon ISO belge
standartlarına uygun şekilde oluşturulmalıdır. Ayrıca sistemin UML dosyaları da
oluşturulmalıdır.
4.3.2.6. Sürüm Kontrolü ve Dağıtım: Projenin geliştirilmesi esnasında tüm kod
değişikliklerinin takibinin ve sürüm yönetiminin kolay ve güvenli şekilde
yapılabilmesinin sağlanması amacıyla endüstri standartlarında bir sürüm kontrol
sistemi kullanılması beklenmektedir.
4.3.3. YAZILIM YAŞAM DÖNGÜSÜ
4.3.3.1. Projenin başarılı bir şekilde yönetilmesi ve hedeflenen sonuçlara ulaşılması için
ISO/IEC 12207, ISO/IEC 25010 standartlarına uygun Yazılım Yaşam Döngüsü (YYD)
yönetimi uygulanmalıdır.
4.3.4. KAYNAK KODUN DEVRİ
4.3.4.1. Projenin tamamlanmasının ardından tüm proje içeriği (kaynak kodlar,
dökümanlar, tasarımlar) eksiksiz bir şekilde teslim edilecek ve tüm fikri mülkiyet
hakları devredilecektir.
 4.3.5. LİSANSLAMA MODELLERİ
4.3.5.1. Geliştirilecek yazılım ve modülleri ayrı ayrı lisanslanabilir şekilde hazırlanacaktır.
4.3.5.2. Dağıtım esnasında ilgili lisanslara göre yazılım veya modüller aktif yada pasif
olabileceklerdir.

5. İŞİN SÜRESİ VE FAZLAR

5.1 İşin süresi maximum 14 Aydır.

5.1.1 AC Cihaz için 4. Ay

5.1.2 DC Cihaz için 8. Ay
5.1.3 Yönetim Yazılımı için finiş süresi 14. Ay’dır.

6. FİYAT VE ÖDEME
6.1 Teklifin içeriği açıkça belirtilmelidir.

6.2 Fazlar ve ödeme yöntemi Açıkça Belirtilmelidir.

7. GARANTİ VE SERVİS
7.1 Garanti süreleri açıkça belirtilmelidir.

7.2 Servis yöntemi Açıkça Belirtilmelidir.

8. DİĞER
8.1 Diğer Konular açıkça belirtilmelidir.