Poziom TRL przypisz do konkretnej technologii i wyników wykonanych testów, a nie do wieku firmy lub procentu wydanego budżetu. Zacznij od określenia, co już działa, w jakich warunkach to sprawdzono i jaki dokument potwierdza wynik. Następnie porównaj dowody z definicjami używanymi w twoim programie. W ten sposób przygotujesz uzasadnienie poziomu początkowego i docelowego, zamiast deklaracji, której nie da się obronić raportem z prac.
Poradnik dotyczy projektów technologicznych. Skalę przedstawia na podstawie załączników ogólnych programu Horizon Europe 2026–2027; przykłady nie zastępują definicji i oceny projektu w wybranym naborze.
Co mierzy poziom gotowości technologicznej
TRL, czyli Technology Readiness Level, opisuje dojrzałość technologii od rozpoznania zasad do sprawdzenia rzeczywistego systemu w środowisku operacyjnym. Załączniki Horizon Europe wskazują dziewięć poziomów. Definicje mają zastosowanie, gdy temat konkursu wymaga TRL, chyba że określono inaczej. Komisja Europejska, General Annexes 2026–2027, s. 15.
Przed wyborem numeru nazwij przedmiot oceny. Może nim być technologia pomiaru, algorytm, urządzenie albo zintegrowany system. Firma może mieć gotowy moduł transmisji danych, lecz dopiero badać nową metodę pomiaru. Nie przypisuj do całości poziomu najwyżej rozwiniętego elementu.
Poziom docelowy opisuje stan, do którego dopiero chcesz dojść. Nie jest dowodem, że prace już wykonano. W karcie projektu rozdziel kolumny „wyniki dostępne dzisiaj” i „wyniki planowane”, a następnie przypisz do nich dokumenty albo zadania. Taki podział pozwoli zauważyć, czy harmonogram obejmuje wszystkie brakujące sprawdzenia.
Dziewięć poziomów i propozycja dowodu
Poniższe krótkie opisy są polskim objaśnieniem skali KE. Kolumna dowodów jest propozycją organizacji dokumentacji, nie oficjalną listą załączników.
| TRL | Znaczenie w skali KE | Co możesz zebrać jako dowód |
|---|---|---|
| 1 | Zaobserwowano podstawowe zasady | Opis zjawiska i źródła obserwacji |
| 2 | Sformułowano koncepcję technologii | Koncepcja wraz z założeniami zastosowania |
| 3 | Eksperymentalnie potwierdzono koncepcję | Raport z doświadczenia sprawdzającego zasadę działania |
| 4 | Technologię zweryfikowano w laboratorium | Protokół testu i warunki stanowiska laboratoryjnego |
| 5 | Technologię zweryfikowano w odpowiednim środowisku | Uzasadnienie reprezentatywności warunków i wyniki |
| 6 | Technologię zademonstrowano w odpowiednim środowisku | Dokumentacja demonstracji zintegrowanego rozwiązania |
| 7 | Prototyp systemu zademonstrowano w środowisku operacyjnym | Raport demonstracji w warunkach przewidzianego użytkowania |
| 8 | System jest kompletny i zakwalifikowany | Dokumentacja kompletnego systemu i jego sprawdzenia |
| 9 | Rzeczywisty system sprawdzono w środowisku operacyjnym | Wyniki rzeczywistego działania systemu |
Źródło poziomów: General Annexes 2026–2027, s. 15. Dla części technologii dokument doprecyzowuje środowisko przemysłowe lub operacyjne. Przeczytaj pełny zapis, zanim użyjesz tabeli we wniosku.
Nie traktuj listy jako automatycznej sekwencji obowiązkowych zakupów. Numer nie mówi, jak drogie ma być stanowisko ani ile miesięcy trwać badanie. Zadania wynikają z ograniczeń rozwiązania i zakresu brakujących dowodów. Koszt prototypu sam w sobie nie przesuwa technologii na wyższy poziom.
Laboratorium, odpowiednie środowisko i eksploatacja
Trzy określenia środowiska bywają mylone, bo każde może obejmować pomiary poza biurkiem. W laboratorium możesz kontrolować bodźce i odseparować badany element. W odpowiednim środowisku odtwarzasz istotne warunki zastosowania. W środowisku operacyjnym sprawdzasz działanie w warunkach przewidzianego użycia systemu. Rozróżnienie jest potrzebne do interpretacji skali, a szczegóły ustala technologia i dokumentacja programu.
Opisz środowisko przez czynniki, które mogą wpływać na wynik: temperaturę, wilgotność, obciążenie, rodzaj danych, zakłócenia i sposób obsługi. Dopisz, jakie czynniki pominięto oraz dlaczego. Określenie „warunki zbliżone do rzeczywistych” bez ich wykazu nie pozwala ocenić reprezentatywności testu.
W projekcie informatycznym środowisko nie musi oznaczać fizycznego miejsca. Różnicę może tworzyć pochodzenie danych, obciążenie, integracja z innymi systemami albo udział użytkowników. Własna próbka testowa nie staje się danymi operacyjnymi tylko dlatego, że zawiera dużo rekordów. Wyjaśnij jej pochodzenie i ograniczenia.
Przykład: czujnik w laboratorium i na linii
Przykład edukacyjny — dane fikcyjne. Firma opracowuje czujnik optyczny do wykrywania wad opakowań. W laboratorium sprawdziła model na próbkach nieruchomych, przy stałym oświetleniu. Ma raport z konfiguracji stanowiska i wynikami dla wszystkich próbek. Ten materiał uzasadnia rozmowę o etapie laboratoryjnym; nie dowodzi działania na ruchomej linii.
Firma planuje kolejny test z ruchem taśmy, zmiennym oświetleniem i drganiami. Najpierw zapisuje zakres tych czynników, ponieważ właśnie one odróżniają docelowe zastosowanie od obecnego stanowiska. Dopiero potem określa, jakie sprawdzenie mogłoby uzasadniać wyższy poziom według definicji programu.
Opis przed korektą brzmi: „Mamy gotowy prototyp, więc osiągnęliśmy TRL 7”. Po korekcie firma wskazuje, który element zweryfikowano laboratoryjnie, załącza raport i opisuje niewykonane jeszcze demonstracje. Cel projektu obejmuje działanie rozwiązania w określonych warunkach, a dowodem końcowym ma być protokół z wynikami oraz ograniczeniami.
Dodatkowe dane mogłyby zmienić ocenę: wcześniej wykonany test na rzeczywistej linii, inna konfiguracja czujnika albo niepełna integracja systemu. Dlatego przykład nie przypisuje ostatecznego poziomu całemu projektowi. Właściwy poziom wymaga odniesienia do obiektu oceny i dowodów.
Kontrprzykład: poziom wyznaczony przez harmonogram
Przykład edukacyjny — dane fikcyjne. Spółka wpisuje TRL 8, ponieważ zakończyła osiem z dziewięciu miesięcy projektu. Nie ma raportu potwierdzającego kompletny system ani dokumentacji jego sprawdzenia. Upływ czasu nie potwierdza poziomu technologii.
Podobnie nie wystarcza informacja o zakupie urządzeń albo faktura za prace programistyczne. Ocenę zmieniłyby wyniki testów potwierdzające stan odpowiadający definicji. Dokument wydatkowy może wykazać wykonanie zakupu, lecz nie opisuje zachowania technologii.
Procedura przypisania poziomu
Przeczytaj definicje naboru i określ datę, na którą deklarujesz stan początkowy. Zapisz nazwę oraz wersję technologii. Zbierz wykonane testy w tabeli: badany element, środowisko, metoda, wynik, dokument i ograniczenie. Dzięki temu późniejsza zmiana prototypu nie zostanie pomylona z wersją rzeczywiście sprawdzoną.
Porównaj tabelę z pełną definicją poziomu. Jeśli brakuje dowodu dotyczącego środowiska albo kompletności systemu, zapisz lukę. Do planu docelowego dodaj zadanie, które ją zamknie, i kryterium oceny. Nie podnoś numeru wyłącznie po to, żeby dopasować projekt do wymaganego progu.
Na koniec poproś osobę odpowiedzialną za technologię o sprawdzenie uzasadnienia. W pytaniu do instytucji pokaż wykonane testy i nierozstrzygnięty fragment definicji. Ocena numeru bez opisu środowiska będzie mniej użyteczna niż ocena konkretnego zestawu dowodów.
Błędy i korekty
- Błąd: TRL przypisujesz całej firmie. Skutek: nie wiadomo, czego dotyczy deklaracja. Korekta: wskaż technologię, konfigurację i datę oceny.
- Błąd: prototyp automatycznie oznacza wysoki poziom. Skutek: pomijasz środowisko i wyniki sprawdzenia. Korekta: opisz wykonane testy oraz ograniczenia.
- Błąd: cel projektu przedstawiasz jako stan aktualny. Skutek: opis przeczy harmonogramowi. Korekta: rozdziel dostępne dowody i planowane rezultaty.
Lista kontrolna
- Zapisano źródło definicji TRL obowiązujące w naborze.
- Określono obiekt oceny, wersję i datę stanu początkowego.
- Każda deklaracja ma wskazany raport lub inny dowód.
- Wyjaśniono reprezentatywność środowiska testowego.
- Poziom docelowy ma przypisane zadania i dowody końcowe.
- Ujawniono ograniczenia oraz elementy nadal niesprawdzone.
Następny krok
Zbuduj rejestr wykonanych testów dla jednej wersji technologii. Brakujące sprawdzenia przenieś do planu prac B+R.
Źródła i zakres aktualności
- Komisja Europejska, Horizon Europe Work Programme 2026–2027, 15. General Annexes, wydanie udostępnione na oficjalnej stronie 29 września 2026 r., s. 15, „Technology Readiness Levels” — poziomy 1–9 i zakres stosowania. PDF.
- Komisja Europejska, Horizon Europe work programmes, dział 2026–2027 — identyfikacja aktualnego zestawu załączników. Strona.
Źródła odczytano 2 października 2026 r. W innych programach używaj definicji wskazanej w ich dokumentacji; numer TRL nie jest samodzielną oceną kwalifikowalności projektu.