Atvērta arhitektūra nav tikai API logotips. Tā ir iespēja izvēlēties, kombinēt un nākotnē mainīt dažādus tehnoloģiju slāņus, neuzbūvējot visu sistēmu no jauna.
Drošības tehnoloģiju tirgū “open architecture” ir kļuvis par vienu no biežāk izmantotajiem terminiem. To var atrast gan VMS, gan piekļuves kontroles, gan videoanalītikas risinājumu aprakstos, taču integratoram ar frāzi “open platform” vien nepietiek.
Svarīgāks ir jautājums: ko tieši es varu integrēt, cik dziļi tas darbojas un kas notiks, ja pēc pieciem gadiem klientam būs nepieciešama cita kamera, analītikas risinājums, piekļuves kontroles sistēma vai mākoņpakalpojums?
Atvērta arhitektūra nav viens tehnoloģijas slānis
Vienkāršoti skatoties, drošības sistēmu var sadalīt vairākos slāņos:
ierīces → komunikācijas/protokoli → VMS vai cita platforma → integrācijas/API → lietotnes un biznesa sistēmas.
Atvērtai arhitektūrai būtu jāsniedz izvēles brīvība vairāk nekā vienā no šiem slāņiem. Piemēram, videonovērošanas projektā tas var nozīmēt iespēju izmantot dažādu ražotāju kameras, nevis tikai viena ražotāja ekosistēmu. Taču ar kameras pieslēgšanu vien nepietiek, jo svarīgi ir arī tas, kādas funkcijas pēc integrācijas paliek pieejamas.
ONVIF ir labs piemērs. Tas nodrošina standartizētu komunikāciju starp ierīcēm, taču “kamera ir ONVIF” automātiski nenozīmē, ka VMS izmantos visas kameras iespējas. Gan Genetec, gan Digifort dokumentācijā ir skaidri redzams, ka atbalstīto funkciju apjoms ir atkarīgs no konkrētā draivera, profila, ierīces un implementācijas. Tāpēc open architecture ≠ ONVIF. ONVIF ir viens no instrumentiem, ar kuru var panākt atvērtību.
Nākamais jautājums - cik dziļa ir integrācija?
Integratoram ir būtiska atšķirība starp: “sistēma saņem signālu” un “sistēmas patiešām strādā kopā”. Pieņemsim, ka objektā darbojas piekļuves kontrole un videonovērošana. Vienkāršā integrācijā VMS var saņemt notikumu: Door forced open. Dziļākā integrācijā šis notikums var automātiski:
- izsaukt konkrētu kameru;
- parādīt reāllaika video operatoram;
- izveidot piezīmes (bookmark);
- aktivizēt trauksmi;
- palaist noteiktu procedūru;
- nosūtīt notikumu uz citu sistēmu;
- iekļaut notikumu atskaitē.
Tieši šeit parādās API, SDK, plug-in un event-to-action mehānismu nozīme. Piemēram, Genetec Security Center SDK nodrošina piekļuvi tādām platformas funkcijām kā video, piekļuves kontrole, ielaušanās noteikšana un ALPR, savukārt Web SDK ļauj integrēt notikumus, trauksmi, durvju vadību, karšu turētāju datus un sistēmas statusu citās lietotnēs.
Digifort savukārt piedāvā SDK, ar kuru iespējams iegūt reāllaika un ierakstīto video no servera, kā arī integrācijas mehānismus trešo pušu sistēmām. Tā dokumentācija rāda arī starpprogrammatūras (middleware) pieeju, piemēram, piekļuves kontroles, perimetra ielaušanās un videosienas integrācijām.
Tātad abos gadījumos jautājums nav tikai “vai var integrēt?”, bet gan “ko mēs pēc integrācijas varam izdarīt?”

Ko tas nozīmē projektēšanas stadijā?
Atvērtā arhitektūra maina arī integratora darbu jau pirms instalācijas.
Tradicionālā pieeja var būt:
Izvēlamies VMS → meklējam tam atbilstošas kameras → piemeklējam pārējo aparatūru.
Atvērtā pieeja ļauj procesu sākt citādi:
Kādas ir projekta prasības? Kādi ir labākie risinājumi katram slānim? Un kā tos savienot vienā funkcionējošā sistēmā?
Tas ir īpaši svarīgi projektos, kuros ir specializētas tehnoloģijas, piemēram, transporta objektā var būt nepieciešamas videokameras, ALPR, piekļuves kontrole, interkomi, perimetra uzraudzība un transporta vadības sistēmas. Savukārt ražotnē prioritāte var būt video, piekļuves kontrole, industriālie sensori un automatizācija.
Atvērtā arhitektūra ļauj platformu izmantot kā integrācijas slāni, nevis obligāti kā vienīgo tehnoloģiju piegādātāju.
Genetec un Digifort: divi atšķirīgi ceļi uz atvērtību
Šeit ir svarīgi saglabāt neitralitāti: open architecture nenozīmē, ka visām platformām jābūt uzbūvētām vienādi.
Genetec Security Center pozicionē sevi kā vietnotu drošības platformu ar plašu tehnoloģiju partneru ekosistēmu. Genetec norāda uz SDK integrācijām, trešo pušu piekļuves kontroles aparatūru, SIP/VoIP ierīcēm, datu glabātuvi un citām partneru integrācijām. Platforma atbalsta arī trešo pušu ierīces, tostarp ONVIF kameras, un Genetec uztur Supported Device List un sertifikācijas programmas.
Digifort savukārt īpaši plaši izmanto atvērtību video infrastruktūras un integrāciju līmenī. Tā dokumentācijā norādīta saderība ar ONVIF ierīcēm, vairāk nekā 400 zīmolu partneru integrācija un atsevišķi starpprogrammatūras (middleware) risinājumi piekļuves kontrolei, perimetra ielaušanās novēršanai, videosienai (videowall) un citām sistēmām.
Tāpēc, izvērtējot divas “open” platformas, nav produktīvi vienkārši skaitīt integrāciju logotipus. Svarīgāk ir skatīties uz integrācijas veidu, dziļumu, sertifikāciju, atbalstītajām funkcijām un projekta prasībām.
Kāpēc tas 2026. gadā ir kļuvis vēl svarīgāk?
Drošības sistēmu dzīves cikls bieži ir daudz garāks par vienas tehnoloģijas paaudzi. Kamera var tikt nomainīta pēc dažiem gadiem, analītikas risinājums var mainīties vēl ātrāk. Savukārt VMS infrastruktūra, piekļuves kontrole un integrācijas var palikt objektā desmit vai vairāk gadus. Tāpēc 2026. gadā jautājums vairs nav tikai:
“Vai šis risinājums strādā šodien?”
Bet:
“Cik daudz izvēles mums būs rīt?”
To pastiprina arī mākoņtehnoloģiju attīstība, hibrīda infrastruktūra, AI analītika un pieaugošās kiberdrošības prasības. Eiropas Savienības 2026. gada ICT Supply Chain Security Toolbox tieši izceļ vairāku piegādātāju stratēģijas un atkarības no augsta riska piegādātājiem mazināšanu kā vienu no riska mazināšanas pieejām.
Savukārt interoperabilitāte (dažādu sistēmu, ierīču, programmatūru vai organizāciju spēja savstarpēji sadarboties, apmainīties ar datiem un izmantot šos datus bez papildu pūlēm no lietotāja puses) publiskajā sektorā arvien vairāk tiek skatīta arī caur atkarību no piegādātāja (vendor lock-in) prizmu - ne tikai kā tehniska savietojamība, bet arī kā iespēja nākotnē mainīt piegādātāju, saglabājot datus un izvairoties no nesamērīgām migrācijas izmaksām.
Ziemeļvalstu tirgū tas jau ir praktisks jautājums
Labs piemērs ir Zviedrija. 2026. gadā World of Volvo pieredzes centrā Gēteborgā Genetec Security Center tiek izmantots kopā ar vairāk nekā 100 i-PRO kamerām, bet citā Volvo objektā federācijas ļauj centralizēti pārvaldīt drošības funkcijas. Tas ilustrē svarīgu principu: atvērta arhitektūra nav mērķis pati par sevi. Tās vērtība parādās tad, kad integratoram ir jāapvieno konkrētam projektam piemērotas tehnoloģijas.
Līdzīga loģika ir aktuāla arī Baltijā, piemēram, pašvaldības, transporta infrastruktūra, ražotnes vai loģistikas centri reti sāk projektu ar pilnīgi “tukšu lapu”. Parasti jau pastāv kameras, piekļuves kontrole, domofoni, sensori, serveri vai citas sistēmas.
Tādēļ praktiskais jautājums ir nevis “vai visu nomainīsim?”, bet “ko varam saglabāt, ko ir vērts nomainīt un kā visu savienot vienā arhitektūrā?”
Un ko tas nozīmē integratoram?
Šeit open architecture kļūst par biznesa, ne tikai tehnisku jautājumu.
1. Vairāk izvēles projektēšanā.
Integratoram nav jāmeklē viena ražotāja risinājums katrai funkcijai. Var izvēlēties tehnoloģiju pēc projekta prasībām.
2. Vieglāka esošās infrastruktūras izmantošana.
Ja klientam jau ir funkcionējošas kameras, kontrolieri vai citas sistēmas, tās ne vienmēr ir jāizmet tikai tāpēc, ka tiek ieviesta jauna platforma.
3. Mazāks "vendor lock-in" risks.
Jo vairāk sistēma balstās uz dokumentētiem standartiem, API un integrācijas iespējām, jo vairāk iespēju saglabājas nākamajā sistēmas dzīves ciklā.
4. Plašākas iespējas diferencēt projektu.
Integratora vērtība vairs nav tikai aparatūras uzstādīšanā, bet gan spējā izveidot arhitektūru, kur dažādu ražotāju tehnoloģijas faktiski strādā kopā.
5. Taču arī lielāka atbildība.
Open architecture nenozīmē “pieslēdzam visu”. Jo vairāk sistēmu tiek integrētas, jo svarīgāk ir pārbaudīt versiju savietojamību, licences, API ierobežojumus, kiberdrošību, veiktspēju un to, kurš nodrošina atbalstu problēmas gadījumā. Tieši šeit integratoram ir jāskatās dziļāk par ražotāja prezentācijas slaidu ar desmitiem partneru logotipu.
Labs jautājums pirms projekta sākšanas
Nevis: “Vai šī platforma ir open architecture?”
Bet: “Kādas izvēles šī arhitektūra man reāli atstāj pēc pieciem gadiem?”
Kādas kameras varēšu izmantot?
Kādas sistēmas varēšu integrēt?
Cik dziļi tās būs integrētas?
Ko varēšu saglabāt no esošās infrastruktūras?
Kā varēšu pievienot jaunas tehnoloģijas?
Un, pats svarīgākais - vai sistēmu varēs attīstīt bez nepieciešamības katru reizi sākt no nulles?
Tieši šajā līmenī atvērtā arhitektūra kļūst par reālu priekšrocību integratoram, nevis kā logotips specifikācijā, bet kā brīvība projektēt, integrēt un nākotnē mainīt sistēmu atbilstoši klienta vajadzībām.