Erre szolgál a Technology Readiness Level, vagyis a technológiai készenléti szint – TRL. Az eredetileg az űriparban kialakított, ma már számos kutatás-fejlesztési és innovációs programban alkalmazott rendszer 9 szinten írja le a technológia fejlődését az alapelvek megfigyelésétől a működési környezetben igazolt, piacképes rendszerig.
A pályázati projektek szempontjából különösen releváns a TRL 3–7 közötti tartomány. E szakaszban történik meg az átmenet a működési elv kísérleti igazolásától a laboratóriumi prototípuson és a mérnöki léptékű fejlesztésen át a valós környezetben működő integrált rendszerig.
A TRL azonban nem azt mutatja meg, hogy egy technológia mennyire innovatív, és nem is egyszerűen azt, hogy a fejlesztési munka hány százaléka készült el. A magasabb TRL-szintek azt jelzik, hogy a technológia működését egyre összetettebb formában, egyre valósághűbb környezetben és egyre meggyőzőbb bizonyítékokkal igazolták.
A TRL egyes szintjeinek konkrét tartalma ágazatonként eltér: mást jelent egy gyógyszerfejlesztési, egy gyártástechnológiai vagy egy szoftveres projekt esetében. A mögöttes logika azonban hasonló: a bizonyítás tárgya fokozatosan az egyes komponensekről a teljes rendszerre, a vizsgálati környezet pedig a laboratóriumból a tényleges alkalmazás irányába tolódik el.
Az alábbiakban két, egymást végigkísérő példán keresztül szemléltetjük a TRL 3–7 közötti szintek legfontosabb jellemzőit.
TRL 3 – a működési elv bizonyítása
TRL 3 szinten a fejlesztés már túlmutat a puszta elméleti koncepción. Megkezdődnek azok az analitikai vizsgálatok, laboratóriumi mérések, modellezések vagy szimulációk, amelyekkel a technológia alapjául szolgáló hipotéziseket és kulcsparamétereket ellenőrzik.
E fázisban általában még nem egy teljes rendszert vizsgálnak. Az egyes kritikus komponensek működése már igazolható, de azok még nem feltétlenül alkotnak integrált prototípust.
3/A példa: Egy szemléletes példa erre egy úgynevezett tartalékelem – vagyis szükség esetén aktiválható elektrokémiai energiaforrás – fejlesztése, amelynek különböző TRL-szakaszai jól szemléltethetők. A fejlesztők e szinten még kis térfogatú elektrokémiai rendszerekkel dolgoztak, különböző elektródaanyagokat, elektrolit-összetételeket és mikropumpákat vizsgáltak. A cél ekkor még nem egy végleges energiaforrás megalkotása volt, hanem annak kísérleti igazolása, hogy a meghatározó fizikai-kémiai paraméterek alapján a koncepció működőképes lehet.
3/B példa: Szoftverfejlesztésben hasonló lehet a helyzet. Vegyünk példaként egy ipari gyártósorokhoz fejlesztett, gépi látáson alapuló hibafelismerő rendszert. TRL 3 szinten már nem elegendő az algoritmus elméleti leírása. A kritikus képfeldolgozási vagy osztályozási megoldást kísérleti adatokon implementálni és kvantitatívan értékelni kell. Igazolható például, hogy a megoldás egy meghatározott típusú gyártási hibát megfelelő érzékenységgel képes felismerni. Ettől azonban még nem beszélhetünk kész hibafelismerő rendszerről. Elképzelhető, hogy az adat-előkészítés, a kameraillesztés, az adatkommunikáció és a felhasználói felület még különálló fejlesztési elemek.
A TRL 3 központi kérdése tehát: kísérletileg alátámasztható-e a technológia működésének alapja?
TRL 4 – amikor a komponensekből prototípus épül
TRL 4 szinten a hangsúly az egyes komponensek önálló vizsgálatáról azok integrációjára helyeződik.
A fő technológiai elemeket integrálják, és laboratóriumi körülmények között ellenőrzik együttes működésüket. Ez már prototípus, de kialakításában vagy léptékében még nem biztosan felel meg a későbbi alkalmazásnak.
4/A példa: A tartalékelem fejlesztésénél ebben a szakaszban került előtérbe a komponensek fizikai integrációja. CAD-tervezéssel és 3D nyomtatással különböző elektródatartó konstrukciókat hoztak létre, amelyeket gyors fejlesztési iterációk során lehetett tesztelni és módosítani. A kísérletek közben az is kiderült, hogy az eredetileg feltételezett alkalmazási irány nem bizonyult megfelelőnek, ezért magát a technológiai koncepciót is módosították.
Ez a TRL 3–4 körüli fejlesztések fontos sajátossága: a siker nem feltétlenül azt jelenti, hogy az eredeti elképzelés minden részlete igazolódik. Az is érdemi K+F-eredmény, ha a mérések alapján egy feltételezést el kell vetni, és egy alternatív műszaki irány bizonyul megvalósíthatónak.
4/B példa: A példaként vett hibafelismerő szoftvernél TRL 4-et jelenthet, amikor a képfeldolgozó algoritmus, az adat-előkészítő modul, a döntési logika és az első felhasználói interfész egyetlen alfa-prototípusban már együtt működik. A tesztelés azonban még helyi fejlesztői környezetben, ellenőrzött adatkészletekkel történik.
A különbség a TRL 3-hoz képest lényeges: ott azt igazoljuk, hogy egy kritikus megoldás működik; TRL 4-en már azt kell igazolni, hogy a rendszer meghatározó elemei együttesen is működőképesek.
TRL 5 – a prototípus közelít a tényleges alkalmazáshoz
A TRL 4 és 5 közötti átmenet nem mindig határozható meg egyértelműen, mert mindkét szinten prototípusról és tesztelésről beszélünk.
A két szintet elsősorban a rendszer integráltságának mértéke és a tesztelési környezet valósághűsége különíti el.
TRL 5 szinten a fő komponensek már integráltak, a rendszer konfigurációja pedig egyre inkább közelíti a tervezett végleges megoldást. A vizsgálatoknak már arra is választ kell adniuk, hogyan viselkedik a prototípus olyan feltételek között, amelyek a későbbi alkalmazás szempontjából relevánsak.
5/A példa: A tartalékelemnél ez jelentős léptékváltást jelentett. A korábbi 100 milliliteres konstrukciót először egy-, majd kétliteres rendszerre növelték, integrálták a komponenseket, és több alapvető műszaki megoldást is módosítottak. Elkészültek azok a teljesítménymérések és mérlegek is, amelyekből már a későbbi alkalmazás várható működésére lehetett következtetni.
5/B példa: A szoftveres példánál ugyanezen a szinten már egy integrált end-to-end prototípust várnánk. A hibafelismerő rendszer nem pusztán néhány előkészített képet dolgoz fel, hanem kommunikál a kamerarendszerrel, kezeli a szükséges adatformátumokat, továbbítja az eredményeket, és a célkörnyezethez hasonló interfészekkel működik.
A tesztadatokat ilyenkor célszerű a valódi alkalmazás körülményeihez is közelíteni. Nem egyenértékű például egy algoritmust gondosan kiválasztott képadatokon mérni azzal, mintha különböző fényviszonyok, eltérő alkatrészpozíciók, zajos képek és változó gyártási paraméterek mellett vizsgálnánk.
A meghatározó kérdés ezen a szinten már nem pusztán az, hogy működik-e a prototípus, hanem az, hogy a későbbi alkalmazáshoz érdemben hasonló körülmények között is megbízhatóan működik-e.
TRL 6 – a laboratóriumi fejlesztésből mérnöki rendszer lesz
TRL 6 szinten a prototípus már nagyobb léptékű és magasabb kidolgozottságú, a tesztelési környezetnek pedig szorosan közelítenie kell a tényleges működési környezethez. Itt már nemcsak az alapvető tudományos-technológiai működés, hanem a mérnöki megvalósíthatóság is központi kérdéssé válik.
6/A példa: A tartalékelem példájában 10 literes prototípust készítettek, amelyet már természetes vízi környezetben teszteltek. Ez azonnal olyan kérdéseket hozott felszínre, amelyek laboratóriumban nem jelentkeztek. Vizsgálni kellett az eltérő sótartalmú víz vezetőképességét, és meg kellett oldani a víz alatti elektromos csatlakozások megfelelő szigetelését.
Éppen ez a releváns környezetben végzett demonstráció egyik fő szerepe: olyan problémákat tárhat fel, amelyek a kontrollált laboratóriumi környezetben rejtve maradnak.
6/B példa: Szoftver esetében a „méretnövelés” nem fizikai értelemben történik, de létezik ennek közvetlen analógiája.
A TRL 6 szintű hibafelismerő prototípust például már a várhatóhoz közeli adatforgalom, gyártási sebesség és infrastruktúra mellett kell vizsgálni. Megjelenhetnek olyan problémák, amelyek kis léptékű tesztelés során nem voltak láthatók: feldolgozási késleltetés, párhuzamos kérések, hálózati hibák, memóriahasználat, interfészproblémák vagy a különböző hardver- és szoftverkomponensek közötti inkompatibilitás.
A szoftveres TRL-értékelési útmutatók TRL 6 esetében már magas kidolgozottságú, integrált prototípust, reális problémákon, várható terhelés mellett végzett tesztelést, valamint kialakuló rendszer- és felhasználói dokumentációt írnak le.
TRL 7 – a technológia belép a valós működési környezetbe
TRL 7 szinten már közel végleges, integrált prototípusrendszerről beszélünk.
A hangsúly már nem egyszerűen a releváns feltételek szimulálásán van: a technológiát tényleges vagy azt szorosan megközelítő működési környezetben kell demonstrálni. A rendszer kialakítása nagyrészt végleges, és a vizsgálatok egyik legfontosabb célja a fennmaradó mérnöki és integrációs kockázatok feltárása.
7/A példa: A tartalékelem esetében a fejlesztők ezen a szinten ismét természetes vízi környezetben végezték a tesztelést, de már integrált rendszerrel. A prototípusnak a víz alatti áramlás, az algák, kagylók és egyéb környezeti tényezők mellett kellett működnie. Az eredményeket folyamatosan, automatizáltan rögzítették. A vizsgálat ekkor már a teljes rendszer működését hitelesítette.
7/B példa: A szoftveres példában TRL 7-en a hibafelismerő rendszer már egy valódi vagy kísérleti gyártósor infrastruktúrájába integrálva működhet. Valós kamerákról kap adatot, együttműködik a gyártást támogató egyéb rendszerekkel, a várható adatstruktúrák és interfészek lényegében véglegesek, és a kritikus hibák többségét már kiküszöbölték.
Ez még nem feltétlenül jelenti azt, hogy a termék korlátozás nélkül kereskedelmi forgalomba hozható. A TRL 7 azonban már meggyőző bizonyítékot szolgáltat arra, hogy maga a technológiai rendszer működőképes a rendeltetésének megfelelő környezetben.
A szoftver TRL-je nem azonos a verziószámmal
Szoftveres projekteknél tipikus félreértés, hogy a technológiai érettséget összekeverik a termékfejlesztési állapottal.
Egy „2.0-s verzió” nem szükségképpen magasabb TRL-szintű, mint az 1.0. Elképzelhető például, hogy egy régóta működő szoftver új, K+F-tartalmú modult kap. A meglévő rendszer üzemszerűen működhet, miközben az új technológiai komponens még csupán proof-of-concept fázisban van.
Hasonló helyzet merül fel összetett platformoknál. Egy rendszer tartalmazhat több kipróbált komponenst, de ha a működés szempontjából kritikus új modul technológiai érettsége lényegesen alacsonyabb, önmagában a kiforrott környezet nem emeli az új fejlesztést magasabb TRL-szintre.
Egy részletes TRL-értékelési módszertan ezért az eltérő érettségű komponensekből álló rendszereknél azt javasolja, hogy a rendszer egészének értékelésekor a legalacsonyabb releváns technológiai érettséget is figyelembe kell venni. Ugyanez a módszertan külön kiemeli, hogy az egymást követő szoftverkiadások és a technológiai érettség növelése két különböző folyamat.
Nem a TRL-szám a döntő, hanem az azt alátámasztó bizonyíték
TRL 3-on az alapvető működési elvet bizonyítjuk. TRL 4-en a fő komponenseket integráljuk. TRL 5-ön a prototípust és a vizsgálati környezetet a tervezett alkalmazáshoz közelítjük. TRL 6-on a technológiát már releváns környezetben és reális léptékben vizsgáljuk. TRL 7-en pedig a közel végleges, integrált rendszernek kell bizonyítania, hogy valós működési környezetben is teljesíti a vele szemben támasztott követelményeket.
A TRL-szint meghatározásának legnehezebb része ezért általában nem maga az 1–9 közötti szám kiválasztása. A valódi kérdés az, hogy az adott technológiánál mit tekintünk laboratóriumi, releváns és tényleges működési környezetnek, valamint milyen bizonyíték tekinthető elegendőnek ahhoz, hogy egy fejlesztési szakaszt lezártnak minősítsünk.
Ezért érdemes a TRL-besorolással már a projekt szakmai tervezésének fázisában foglalkozni. A helyesen meghatározott kiinduló és cél-TRL segít kijelölni a szükséges kísérleteket, prototípusokat, validációs feladatokat és mérföldköveket is.
A TRL-rendszer tehát nem arra vállalkozik, hogy az egymástól gyökeresen eltérő fejlesztéseket technológiailag közvetlenül összehasonlíthatóvá tegye. Inkább arra, hogy egységes logika mentén lehessen róluk beszélni: ötletről vagy már kísérletileg igazolt megoldásról van-e szó; különálló komponenseket vagy integrált prototípust vizsgálunk; laboratóriumban, releváns környezetben vagy már tényleges működési körülmények között bizonyították-e a technológia működését. Éppen ezért az általános TRL-definíciókat számos területen szektorspecifikus útmutatókkal egészítik ki
További információért, tanácsadásért töltsd ki a kapcsolatfelvételi űrlapunkat.