Gyula pontosan tudta, hogyan játsszák ki a biztonsági őrök az őrjárat-ellenőrző rendszereket. Nem specifikációval érkezett, hanem egy problémával. Ez a cikk arról szól, hogyan lett belőle működő, több kontinensen használt felhőalapú "csekkoló" applikáció.
Ügyfél: Trinity Guard LLC
Iparág: Vagyonvédelem
Együttműködés: 2022 vége óta, folyamatosan
Petadev szerepe: terméktervezés · mobilalkalmazás · webalkalmazás · backend · felhőinfrastruktúra · ügyfél-infrastruktúrára történő telepítés · AI-fejlesztés · folyamatos továbbfejlesztés
2022 végén Győrfi Gyula a Google-ben keresett fejlesztőcéget. Nem volt kész specifikációja, nem voltak képernyőtervei, még a termék végleges neve sem volt meg.
Egy problémája volt.
Huszonhat év rendőri szolgálat után, őrmestertől alezredesig, a magánbiztonsági szektorban dolgozott tovább, és pontosan tudta, hol csúszik félre a járőrellenőrzés a gyakorlatban. Nem elméletben: konkrét módszereket tudott mondani arra, hogyan lehet kijátszani a meglévő rendszereket.
A hagyományos, korongos ellenőrzőpontos rendszerek éppen ezt a problémát lettek volna hivatottak megoldani. A gyakorlatban viszont új lehetőséget teremtettek a visszaélésre. Az őr lecsavarta a korongokat, bevitte őket az őrbódéba, majd rövid idő alatt végigolvasta az egész útvonalat anélkül, hogy ténylegesen végigjárta volna.
A napló rendben volt. Az őrjárat viszont nem történt meg.
Ezzel a problémával keresett meg minket. Nem azzal, hogy „kellene egy app”.
Röviden: mi épült fel?
A Trinity Guard egy mobilalkalmazásból, webes üzemeltetői felületből és egyedi backendből álló őrjárat-ellenőrző és biztonsági üzemeltetési platform.
- Kültéren GPS-alapú, beltéren QR-kódos ellenőrzőpontok, dedikált olvasóeszköz nélkül, okostelefonnal
- Őrjárat- és beosztástervezés, feladatkiosztás és jelenlét-nyilvántartás
- Incidensjelentés fotóval, GPS-koordinátával és másodpercre pontos időbélyeggel
- Be- és kiléptetés nyilvántartása
- Titkosított belső chat
- Trinity Agent, amely AI segítségével összegzi egy adott objektum releváns előzményeit
- Saját tanítású neurális háló, amely felismeri a gyanús, reprodukált QR-ponttal történő beolvasásokat
- Nyolc nyelven, több régióban működő rendszer, önkiszolgáló regisztrációval és automatikus kártyás fizetéssel
A Trinity Guard ma Európában, az Egyesült Államokban, Dél-Amerikában és Afrikában is működik. Magyarországon több biztonsági cég és közvetlen megbízó használja.
A termék a trinity-guard.com oldalon érhető el.
A nehezebb rész nem a programozás volt
Sok projektnél az ügyfél már konkrét funkciókkal vagy képernyőkkel érkezik. Itt pont fordítva történt.
Gyula részleteiben ismerte a szakmát és a problémát. Nekünk azt kellett meghatározni, hogyan lehet ebből olyan szoftveres szabályokat és folyamatokat kialakítani, amelyek valódi üzemeltetési környezetben is működnek.
Ez volt a projekt egyik legfontosabb része.
Az, hogy „az őr járja végig az útvonalat”, vezetői elvárásként érthető. Szoftveres követelményként viszont még kevés. Ahhoz többek között ezekre a kérdésekre kellett választ adni:
Hogyan bizonyítható, hogy valaki fizikailag ott volt? A GPS kültéren jó közelítést adhat, de milyen pontosság fogadható el? Mi történik egy mélygarázsban vagy épületen belül, ahol a helymeghatározás bizonytalan?
Mi számít teljesített őrjáratnak? Minden ellenőrzőpontot érinteni kell? Meghatározott sorrendben? Adott időablakon belül? Mi történik akkor, ha az őr egy incidens miatt jogosan szakítja meg az útvonalat?
Kinek mit kell látnia? Az őrnek a saját feladatait, a parancsnoknak a saját objektumát, az adminisztrátornak pedig a teljes működést. Ugyanaz az adat, eltérő nézetekkel és jogosultságokkal.
Az első szakaszban ezért nem a fejlesztés volt a legfontosabb, hanem ezeknek a működési szabályoknak a tisztázása. Gyula hozta azt a szakterületi tapasztalatot, amellyel mi nem rendelkeztünk; mi pedig azokat a technikai kérdéseket, amelyek egy működő rendszer megtervezéséhez szükségesek.
Ez a közös munka tette lehetővé, hogy a gyakorlati üzemeltetési tapasztalatból egyértelmű, a rendszerben következetesen érvényesíthető szabályok szülessenek.
Az első verzió: okostelefon, semmi más
Volt egy döntés, amely az egész későbbi fejlesztést meghatározta: a terepi használathoz ne legyen szükség külön elektronikus olvasóeszközre.
Számos hagyományos őrjárat-ellenőrző megoldás dedikált eszközökre vagy külön olvasókra épül. Ez plusz beruházást és üzemeltetési terhet jelenthet, különösen akkor, ha sok őrt vagy több objektumot kell felszerelni.
A Trinity Guardnál ezért már az elején alapelv volt, hogy a terepen elég legyen az az okostelefon, amelyet az őr egyébként is használ.
Az első kiadás magja:
- GPS-sel ellenőrzött kültéri őrjáratok, idő- és helybélyeggel
- beosztástervezés objektumonként, automatikus értesítésekkel
- feladatkiosztás és teljesítéskövetés
- incidensjelentés fotóval és koordinátával
- titkosított belső kommunikáció
- exportálható napló tetszőleges időszakra
Alapesetben a rendszer felhőalapon működik, ezért nincs szükség helyszíni szerverre, központi számítógépre vagy külön telepített infrastruktúrára.
A beltéri probléma és amit az szült
A GPS kültéren általában jól használható, beltérben viszont könnyen pontatlanná vagy elérhetetlenné válik, például lépcsőházban, pincében vagy nagy raktárcsarnokok belsejében.
Márpedig az őrjáratok jelentős része éppen ilyen helyeken halad.
Beltérre ezért QR-kódos ellenőrzőpontokat vezettünk be: egyedi kódokat helyeztünk el a szükséges pontokon, amelyeket az őr a telefonjával olvas be.
Ezzel viszont az eredeti probléma új formában tért vissza.
A korongot le lehetett csavarni. A QR-kódot le lehet fényképezni. Ha valaki előre lefotózza az ellenőrzőpontokat, később anélkül is beolvashatja őket, hogy fizikailag ott lenne.
A kézenfekvő védekezések nem oldották meg megfelelően a problémát. A kódok rendszeres cseréjéhez újra és újra végig kell járni a helyszíneket, a GPS-alapú ellenőrzés pedig éppen ott bizonytalan, ahol a beltéri pontokra szükség van.
Ezért saját neurális hálót tanítottunk.
A modell a beolvasás vizuális jellemzőit elemzi, és képes felismerni, ha nem az eredeti fizikai QR-pontot, hanem annak lefényképezett, lefénymásolt vagy más módon reprodukált változatát olvassák be.
Több tízezer képen tanítottuk, működéséhez pedig nincs szükség további hardverre vagy az őr megszokott munkafolyamatának megváltoztatására.
A rendszer a gyanús esetet jelzi a webes felületen. Nem hoz automatikusan döntést az őr helyett vagy ellen, hanem információt ad az üzemeltetőnek ahhoz, hogy az esetet ellenőrizhesse.
Ez jó példa arra, miért nem minden problémára működik egy kész technikai recept. A visszaélési mód az adott szakterület működéséből következett, ezért a megoldást is ebből kellett levezetni.
Ami az első kiadás után jött
A Trinity Guard nem állt meg az első verziónál, és mi sem. Azóta több fejlesztési körön vagyunk túl.
Trinity Agent. A parancsnoknak nem kell hosszú naplókat végignéznie: megkérdezheti, mi történt egy adott objektumban, a rendszer pedig feldolgozza az őrjáratokat, incidenseket és releváns előzményeket, majd összegzi azokat.
Önkiszolgáló regisztráció és automatikus kártyás fizetés. Ez már nem egyszerű funkcióbővítés volt, hanem az üzleti modell változása. Az új ügyfelek értékesítési egyeztetés nélkül is regisztrálhatnak, 14 napig kipróbálhatják a rendszert, majd előfizethetnek rá.
Be- és kiléptetés. Azoknál az objektumoknál, ahol az őrszolgálat feladata a be- és kilépők nyilvántartása, ez a folyamat is ugyanabban a rendszerben kezelhető.
Nyolc nyelven, több régióban. A rendszer több nyelvi és regionális környezetet kezel összehangoltan. Ennek infrastrukturális oldala idővel önálló mérnöki feladattá nőtte ki magát, erről külön cikkben írunk majd.
Üzemeltetés a megbízó saját infrastruktúráján. A Trinity Guard alapértelmezetten felhőalapon működik, de olyan környezetben is telepíthető, ahol a megbízó belső biztonsági előírásai megkövetelik, hogy az adatok a saját infrastruktúráján maradjanak. Ilyen konfigurációban is működik már a rendszer.
Az architektúrát úgy alakítottuk ki, hogy több, egymástól független környezetben is futtatható legyen. Amikor később felmerült a saját infrastruktúrán történő üzemeltetés igénye, ezért nem kellett az alapoktól újratervezni a rendszert.
Az alkalmazások élesben futnak az App Store-ban és a Google Playen.
„Ajánlom a Petadevet. Megbízható, lelkiismeretes csapat, és nem mellesleg értenek is ahhoz, amit csinálnak.”
Győrfi Gyula - ügyvezető, Trinity Security Kft.
Miért működött ez az együttműködés?
Három tényező volt különösen fontos.
Az ügyfél ismerte a problémát. Gyula nem funkciólistával érkezett, hanem több évtizednyi tapasztalattal arról, hogyan bukik el ugyanaz a folyamat a gyakorlatban. Amikor felvetettünk egy megoldást, azonnal meg tudta mondani, hogy az megállja-e a helyét egy éjszakai műszakban, valós terepi körülmények között.
Ahol kellett, ellentmondtunk. Több funkció végül másképp épült meg, mint ahogy az első beszélgetéseken felmerült, mert a tervezés és a megvalósítás olyan korlátokat hozott felszínre, amelyek kívülről nem látszottak. Volt, amit Gyula elfogadott, és volt, amit nem. A fontos az volt, hogy ezek a kérdések még a megfelelő pillanatban kerültek elő.
Egyikünk sem tekintette az élesítést végpontnak. A csalásfelismerés, az AI-réteg, a fizetési folyamat és a beléptetés mind a működés során felmerült igényekből fejlődött tovább. Egy élesben használt rendszer olyan helyzeteket hoz felszínre, amelyeket a legjobb specifikáció sem tud teljes egészében előre megjósolni.
Ha te is szakterületi tudással érkeznél
A Trinity Guard történetéből több olyan tanulság is következik, amely más iparágakban ugyanúgy érvényes.
A szakmai tudásod előny, nem hátrány. Nem kell tudnod előre, milyen technológiával kell megoldani a problémát. Sokkal fontosabb, hogy pontosan tudd, hol akad el ma a folyamat, miért nem működtek a korábbi próbálkozások, és hogyan viselkednek az emberek valós helyzetekben. Ezt a szakterületi tudást az ügyfél hozza; a fejlesztő feladata, hogy működő rendszerré fordítsa.
Ha egy rendszer teljesítést ellenőriz, már a tervezéskor érdemes végiggondolni, hogyan próbálhatják majd kijátszani. A kerülőút gyakran egyszerűbb, mint elsőre gondolnánk, ezért ezeket a kivételes helyzeteket nem érdemes a fejlesztés végére hagyni.
A hardverigény üzleti döntés is. A Trinity Guard egyik fontos előnye, hogy a terepi működéshez nincs szükség külön elektronikus olvasóeszközre. Ez már a projekt elején eldőlt, és később számos technikai döntést is befolyásolt.
Van olyan problémád, amit egy mobilalkalmazással lehetne igazán jól megoldani?
Nem kell kész specifikációval érkezned. Mondd el, hogyan működik ma a folyamat, hol akad el, és mit kellene a felhasználóknak terepen vagy mobilról elvégezniük. Segítünk abból működő terméket tervezni és megépíteni.
