Cum ajunge o propoziție tehnică să conducă un camion de zeci de tone

Acest articol face parte din seria „Când viitorul are roți”, despre proiectul camioanelor autonome Volvo dezvoltat în ecosistemul Volvo Autonomous Solutions, Aurora și AUMOVIO și despre lumea tehnică, operațională și umană din spatele lui, din care fac și eu parte.

Articole anterioare în serie:

• Când viitorul are roți: proiectul pe care îl ador
• Un camion construit de la început pentru autonomie
• Cum vede și înțelege lumea un camion autonom
• Ochii camionului trebuie să știe și când nu mai văd
• Cum ajunge un camion autonom din fabrică pe autostradă
• Când tehnologia ajunge înaintea legislației
• De la prototip impresionant la produs industrial
• De la hub-to-hub la transport direct pentru client

În spatele fiecărei decizii luate de camion sunt decizii luate de oameni

În spatele fiecărei decizii luate de camion se află, mai întâi, decizii luate de oameni. Oameni care definesc ce trebuie să facă sistemul, ce nu are voie să facă, în ce condiții trebuie să reacționeze și cum demonstrăm că reacția este sigură. În trafic, camionul poate decide în câteva secunde. Dar acele câteva secunde sunt pregătite cu mult înainte, în discuții, analize, cerințe, arhitecturi, interfețe și teste.

• Ce se întâmplă dacă un senzor nu mai transmite date?
• Dacă vizibilitatea scade?
• Dacă un alt participant la trafic reacționează imprevizibil?
• Dacă două componente interpretează diferit aceeași situație?
• Dacă funcția principală nu mai este disponibilă exact când vehiculul are nevoie de ea?

Niciuna dintre aceste întrebări nu poate fi lăsată pentru momentul în care camionul se află deja pe autostradă. Acolo nu mai este loc pentru brainstorming, interpretări creative sau pentru formula atât de iubită în proiecte: „Revenim asupra subiectului într-o ședință separată.” Camionul nu poate deschide un action item în timp ce se apropie de un obstacol. Din păcate sau din fericire, depinde de perspectivă.

Răspunsurile trebuie găsite înainte. Trebuie transformate în arhitectură, funcții, interfețe, cerințe și teste. Apoi trebuie verificate, revizuite și urmărite până în momentul în care sistemul demonstrează că se comportă așa cum a fost gândit.

De la nevoie la cerință

Totul începe, de obicei, cu o nevoie. Uneori este o nevoie a clientului: marfa trebuie să ajungă în siguranță, la timp și într-un flux operațional previzibil. Alteori este o nevoie de siguranță: vehiculul trebuie să reacționeze corect atunci când o funcție se degradează. Alteori este o nevoie legislativă, de service, de producție sau de operare. Pe scurt, cineva are nevoie ca sistemul să facă un anumit lucru, într-un anumit context, cu un anumit nivel de încredere.

Rolul requirements engineering este să transforme această nevoie într-o cerință suficient de clară încât să poată fi proiectată, implementată, verificată și urmărită. Nu ajunge să spunem „vehiculul trebuie să fie sigur”, deși ar fi minunat dacă lumea ar funcționa pe baza unor propoziții atât de elegante și atât de nefolositoare practic. Trebuie să explicăm ce înseamnă acel comportament, când se aplică, cine îl folosește, ce condiții îl declanșează, ce interfețe sunt implicate și cum demonstrăm că sistemul face ceea ce trebuie.

Eu: „Scriem o cerință clară.” Tot eu, după prima revizie: „Excelent, acum avem o cerință, trei interpretări, două dependențe și o întrebare existențială despre interfață.”

De exemplu, o nevoie precum „vehiculul trebuie să poată informa echipa de asistență atunci când nu mai poate continua în condiții normale” nu este încă o cerință suficientă. Trebuie clarificat ce înseamnă „nu mai poate continua”, cine primește informația, prin ce canal, cât de repede, ce conține mesajul și ce acțiune trebuie să urmeze. Altfel, avem o intenție bună, dar sistemul nu poate implementa intenții bune. Are nevoie de definiții.

Cerința nu trăiește singură

O cerință nu există niciodată în vid. Ea are un context, un motiv, o sursă, o persoană sau o organizație care are nevoie de acel comportament și, aproape întotdeauna, o listă de alte lucruri de care depinde. Dacă o cerință pare perfect izolată, de obicei înseamnă doar că nu am descoperit încă legăturile ei. Și legăturile au obiceiul foarte nepoliticos de a apărea exact când credeai că ai terminat analiza.

Într-un sistem autonom, o cerință despre oprirea sigură poate avea legături cu frânarea, direcția, percepția, comunicațiile, alimentarea cu energie, monitorizarea operațională, service-ul și chiar modul în care este informat clientul. O cerință despre curățarea unui senzor poate influența arhitectura hardware, logica software, diagnosticarea, mentenanța și criteriile de revenire în operare.

De aceea, requirements management nu înseamnă doar să depozităm propoziții tehnice într-un instrument și să sperăm că ele vor crește frumos, ordonat și fără conflicte. Înseamnă să înțelegem relațiile dintre ele, să urmărim schimbările și să ne asigurăm că fiecare decizie tehnică importantă rămâne conectată la motivul pentru care a fost luată.

Aici intră în scenă lumea în care lucrez eu: systems engineering, requirements engineering și requirements management.

Este o lume care nu se vede în imaginile spectaculoase cu vehiculul pe autostradă. Nu apare în fotografiile cu senzorii și nici în videoclipurile în care camionul schimbă banda impecabil. Nu este partea care strânge cele mai multe priviri, pentru că un tabel cu trasabilitate nu are, în general, aceeași prezență scenică precum un camion de zeci de tone.

Arhitectură, funcții, interfețe și dependențe

După ce o nevoie devine cerință, ea trebuie să își găsească locul în arhitectura sistemului. Arhitectura este, simplificat, modul în care sistemul este împărțit în părți care lucrează împreună: vehicul, senzori, unități de calcul, funcții software, comunicații, service, operațiuni și interfețe între toate acestea.

O funcție descrie ce trebuie să facă sistemul. O interfață descrie cum comunică două părți ale sistemului între ele. O dependență arată că o decizie sau o funcție dintr-o zonă poate afecta o altă zonă. Și aici începe distracția, în sensul foarte ingineresc al cuvântului: nimic nu mai este chiar local, chiar simplu sau chiar „doar o mică schimbare”.

De exemplu, dacă modificăm comportamentul camionului atunci când percepția se degradează, nu schimbăm doar o propoziție. Putem afecta logica de decizie, limitele de viteză, modul de comunicare cu echipa de asistență, criteriile de oprire, testele de verificare și procedurile de service. Aceasta este frumusețea sistemelor complexe: o schimbare mică poate avea o viață socială foarte activă.

Un exemplu și mai banal, dar foarte real: dacă schimbăm textul unei cerințe din „sistemul informează echipa de asistență” în „sistemul transmite automat un mesaj către echipa de asistență”, am schimbat deja nivelul de așteptare. Nu mai vorbim doar despre o informație disponibilă undeva, ci despre un canal, un moment, un conținut, o responsabilitate și probabil încă trei întrebări care se uită la noi din colțul camerei. Cerințele au acest talent: par propoziții cuminți până când le inviți în sistem.

Dar fără această lume, toate componentele sistemului nu ar putea vorbi aceeași limbă. Cerințele fac legătura dintre ceea ce își dorește clientul și ceea ce trebuie să construiască echipele. Conectează hardware-ul cu software-ul, senzorii cu funcțiile vehiculului, logica de decizie cu mecanismele de siguranță, operațiunile de pe șosea cu procesele din fabrică, service și infrastructură.

O cerință aparent simplă poate traversa un număr impresionant de discipline înainte să devină realitate. Poate porni de la o nevoie operațională. Apoi ajunge în arhitectură, este împărțită între sisteme, transformată în funcții, implementată în hardware și software, verificată prin teste și urmărită până la comportamentul final al vehiculului.

Iar pe acest drum poate întâlni suficiente interfețe, dependențe și interpretări încât să își piardă sensul inițial dacă nimeni nu o urmărește cu atenție. Pentru că fiecare cerință poartă în ea o întrebare. Fiecare interfață ascunde o dependență. Fiecare presupunere poate deveni un risc. Fiecare modificare poate produce efecte în alte zone ale sistemului.

Trasabilitate: firul care leagă ideea de comportamentul real

Trasabilitatea este firul care leagă o nevoie inițială de comportamentul real al sistemului. Ea arată de unde a pornit o cerință, ce funcții o implementează, ce componente sunt implicate, ce teste o verifică și ce dovezi arată că sistemul face ceea ce trebuie.

Fără trasabilitate, o cerință riscă să devină o propoziție frumoasă, dar orfană. Există undeva în documentație, toată lumea speră că este acoperită, dar când cineva întreabă „unde se implementează?” sau „cum demonstrăm că funcționează?”, începe acea activitate foarte sănătoasă, dar deloc dorită vineri după-amiază: căutarea sensului pierdut.

Într-un camion autonom, trasabilitatea nu este un exercițiu birocratic. Este modul prin care poți arăta că o nevoie de siguranță, o cerință legală sau o solicitare operațională a ajuns în arhitectură, în funcții, în interfețe și în teste. Este diferența dintre „știm că am discutat despre asta” și „putem demonstra unde este definit, cum este implementat și cum este verificat”.

De exemplu, dacă există o cerință ca vehiculul să reducă viteza atunci când percepția se degradează, trasabilitatea trebuie să arate de unde vine acea nevoie, ce funcție o implementează, ce senzori și ce logică sunt implicați, ce teste verifică reacția și ce rezultate demonstrează că vehiculul se comportă corect. Altfel, rămânem cu o idee bună și cu multă încredere. Iar în sisteme critice, încrederea fără dovezi este doar optimism cu font profesionist.

Alt exemplu: o cerință legală despre semnalizarea unui vehicul oprit trebuie să poată fi urmărită până la comportamentul vehiculului, la sistemele de avertizare, la comunicarea cu echipa de asistență, la procedurile operaționale și la testele care demonstrează că soluția funcționează. Dacă firul se rupe undeva, întrebarea „dar unde este acoperit acest lucru?” nu mai este enervantă. Este necesară.

Un alt exemplu foarte practic este o cerință despre actualizarea software. Dacă o versiune nouă schimbă modul în care sistemul interpretează datele de la senzori, trasabilitatea trebuie să arate ce funcții sunt afectate, ce teste trebuie refăcute, ce configurații sunt permise și ce dovezi confirmă că vehiculul rămâne în limitele de siguranță definite. Pentru că „am actualizat software-ul” nu este, în sine, o demonstrație. Este doar începutul unei conversații cu multe consecințe.

Impact analysis: pentru că nimic nu se schimbă singur

Impact analysis înseamnă analiza efectelor pe care o modificare le poate avea asupra sistemului. Cu alte cuvinte: dacă schimbăm acest lucru, ce altceva se mișcă odată cu el? În sisteme simple, răspunsul poate fi scurt. În sisteme autonome critice, răspunsul are adesea ambiții de roman.

De exemplu, dacă se schimbă criteriul după care camionul decide să reducă viteza atunci când percepția se degradează, analiza de impact trebuie să verifice dacă sunt afectate logica de decizie, limitele de operare, testele existente, mesajele transmise către echipa de asistență, procedurile de service sau documentația pentru client.

Alt exemplu: dacă se schimbă un senzor sau versiunea software care procesează datele acelui senzor, nu este suficient să spunem că noua variantă este „mai bună”. Trebuie verificat ce cerințe sunt afectate, ce interfețe se schimbă, ce teste trebuie repetate, ce configurații sunt valide și dacă vehiculul se comportă în continuare conform așteptărilor în scenariile relevante.

Acesta este motivul pentru care o modificare aparent mică poate deschide o discuție mult mai mare. Nu pentru că oamenii din requirements engineering iubesc complicațiile — deși recunosc că uneori părem foarte confortabili în prezența lor — ci pentru că într-un sistem critic fiecare schimbare trebuie înțeleasă înainte să devină comportament real.

Un alt caz foarte concret: dacă o cerință de service spune că un senzor poate fi înlocuit în teren, analiza de impact trebuie să întrebe ce înseamnă „în teren”. Cine face intervenția? Ce instrumente sunt necesare? Este nevoie de recalibrare? Ce test confirmă că noul senzor este aliniat corect? Poate vehiculul pleca imediat sau trebuie să treacă printr-o verificare suplimentară? O formulare mică poate deschide o operațiune întreagă.

Verificare și validare: cum demonstrăm că sistemul face ce trebuie

După ce o cerință este definită, conectată și implementată, urmează întrebarea care nu iartă: cum demonstrăm că sistemul face ceea ce am spus că trebuie să facă? Aici intră verificarea și validarea. Pe scurt, verificarea întreabă dacă am construit corect sistemul conform cerințelor, iar validarea întreabă dacă sistemul răspunde nevoii reale pentru care a fost construit.

Dacă o cerință spune că vehiculul trebuie să reacționeze într-un anumit mod când un senzor se degradează, verificarea poate arăta că funcția detectează degradarea și declanșează comportamentul definit. Validarea merge mai departe și întreabă dacă acel comportament este potrivit în contextul real: este suficient de sigur, suficient de clar pentru operațiune și suficient de robust pentru scenariile în care camionul va circula efectiv?

Un test poate confirma că o funcție produce rezultatul așteptat. Dar pentru un sistem autonom critic, nu este suficient să avem un rezultat bun o singură dată, într-un scenariu frumos controlat. Trebuie să înțelegem dacă reacția se repetă, dacă limitele sunt respectate, dacă datele susțin concluzia și dacă rezultatul poate fi explicat. Pentru că „a mers în test” este începutul conversației, nu finalul ei.

Aici documentația și testarea se întâlnesc foarte serios. Cerința spune ce trebuie să se întâmple. Testul arată dacă s-a întâmplat. Rezultatul spune ce am observat. Iar trasabilitatea leagă toate aceste lucruri într-un fir pe care îl putem urmări fără să organizăm o expediție arheologică prin foldere, e-mailuri și amintiri selective.

De exemplu, pentru o cerință despre semnalizarea vehiculului oprit, verificarea poate demonstra că sistemul activează corect avertizarea definită. Validarea trebuie să meargă mai departe: este avertizarea suficient de vizibilă pentru ceilalți participanți la trafic? Este ușor de înțeles pentru echipele de intervenție? Funcționează în condițiile reale în care vehiculul ar putea opri? Aici diferența dintre „am implementat funcția” și „funcția rezolvă problema reală” devine foarte importantă.

Schimbi o formulare și poate trebuie reevaluată arhitectura. Modifici o funcție și trebuie verificate interfețele. Schimbi o componentă și trebuie analizat dacă testele existente mai demonstrează ceea ce trebuie demonstrat.

Într-un proiect atât de complex, nimic nu se modifică singur. Doar pare singur, pentru aproximativ zece minute, până când analiza de impact găsește încă șapte elemente afectate.

Uneori, în spatele unei singure propoziții tehnice există săptămâni de discuții, clarificări și negocieri. Nu pentru că oamenii nu știu să scrie o propoziție, ci pentru că acea propoziție trebuie să însemne același lucru pentru toate echipele care o vor folosi.

Trebuie să fie suficient de clară încât să poată fi implementată, suficient de precisă încât să poată fi verificată, suficient de completă încât să nu lase exact partea critică la libera interpretare, și suficient de stabilă încât să nu se transforme, după trei luni, într-un mic mister arheologic despre ce a vrut autorul să spună.

Rolul de traducător între discipline

Într-un proiect autonom, fiecare disciplină vede sistemul prin propriul unghi: software, hardware, siguranță, vehicul, service, producție, operațiuni, client, legislație. Toate au dreptate din perspectiva lor. Problema este că vehiculul nu funcționează pe perspective separate. Funcționează ca un întreg.

Aici rolul meu este adesea acela de traducător între discipline. Nu traduc doar cuvinte, ci intenții, constrângeri, riscuri și presupuneri. Încerc să mă asigur că atunci când o echipă spune „sistemul trebuie să informeze operatorul”, toată lumea înțelege același lucru: cine este operatorul, ce informație primește, prin ce interfață, când, în ce format și ce trebuie să facă mai departe.

Aici se află, pentru mine, una dintre cele mai mari responsabilități ale rolului meu. Nu este vorba doar despre administrarea unor documente sau despre menținerea unor legături într-un instrument software. Este vorba despre păstrarea coerenței într-un sistem uriaș, construit de echipe diferite, din companii diferite, cu propriile procese, propriile priorități și propriul mod de a vorbi despre aceeași realitate. Cu alte cuvinte, încerc să fac în așa fel încât aceeași propoziție să nu ajungă să însemne cinci lucruri diferite doar pentru că a trecut prin cinci discipline diferite. Ceea ce, în proiecte mari, este aproape un sport de performanță.

Uneori, rolul unui requirements manager seamănă cu cel al unui traducător între lumi inginerești. Alteori, cu cel al unui detectiv care încearcă să afle unde s-a pierdut sensul inițial. Iar uneori, cu cel al unei persoane care întreabă pentru a douăsprezecea oară “Dar unde este scris acest lucru?”

Nu din obsesie birocratică, deși, privit din exterior, poate exista această impresie, ci pentru că într-un sistem critic nu este suficient ca cineva să știe ceva. Informația trebuie să fie clară, documentată, acceptată, urmărită și disponibilă tuturor celor care depind de ea.

Aceasta este partea nevăzută a autonomiei: munca lentă, atentă și uneori obositoare prin care o idee este transformată într-un sistem în care oamenii trebuie să poată avea încredere. Este multă analiză, multă documentație, multe întrebări, multe versiuni ale aceleiași idei, până când ea devine suficient de matură pentru a fi construită.

Dar unde este scris?

Dacă ar fi să aleg o întrebare care urmărește requirements engineering-ul ca o umbră foarte consecventă, aceasta ar fi: „Dar unde este scris?” Este întrebarea care poate opri elegant entuziasmul unei discuții, poate strica o presupunere comodă și poate transforma o afirmație vagă într-o clarificare necesară.

Nu o întreb pentru că îmi place să privesc oamenii cum caută prin documente, deși recunosc că uneori acest moment are un dramatism aparte. O întreb pentru că, într-un sistem critic, ceea ce nu este scris, urmărit și acceptat riscă să devină interpretare. Iar interpretarea poate fi utilă în literatură, dar este mult mai puțin recomandată atunci când discutăm despre comportamentul unui vehicul autonom.

„Dar unde este scris?” nu este o întrebare birocratică. Este o întrebare de siguranță. Dacă un comportament trebuie să existe, trebuie să fie definit. Dacă o decizie a fost luată, trebuie să fie justificată. Dacă o cerință a fost schimbată, trebuie să știm ce a fost afectat. Dacă o echipă spune că „așa am discutat”, trebuie să putem transforma acel „discutat” într-un artefact pe care și ceilalți îl pot vedea, verifica și folosi.

În proiectele mari, memoria colectivă este un instrument periculos de optimist. Astăzi toată lumea își amintește același lucru. Peste trei luni, aceeași decizie poate avea patru versiuni, două interpretări și o persoană care spune cu o încredere îngrijorătoare: „Eu parcă țin minte altfel.” Documentația nu elimină toate problemele, dar măcar le oferă o adresă la care pot fi găsite.

Pentru mine, întrebarea aceasta este una dintre formele cele mai practice de responsabilitate. Nu blochează progresul. Îl protejează. Îl obligă să fie explicit, urmărit și demonstrabil. Pentru că, atunci când o propoziție tehnică ajunge să influențeze comportamentul unui camion de zeci de tone, nu mai este suficient să știm că cineva a avut intenția corectă. Trebuie să știm unde este definită acea intenție, cum este implementată și cum demonstrăm că funcționează.

Și, din când în când, vine acel moment rar în care vezi camionul pe drum și recunoști în comportamentul lui ceva ce a existat mai întâi într-o discuție, într-un scenariu sau într-o cerință. Atunci toate acele ore nevăzute capătă formă. Documentația devine funcție, analiza devine decizie, iar munca unor oameni pe care publicul nu îi va vedea niciodată ajunge să se deplaseze, foarte concret, pe autostradă.

Concluzie: când documentația ajunge pe autostradă

Dacă există un lucru pe care acest proiect mi l-a arătat foarte clar, este că documentația nu este partea moartă a tehnologiei. Nu este doar arhivă, formalitate sau decor administrativ. Într-un sistem autonom critic, documentația este unul dintre modurile prin care deciziile oamenilor pot deveni comportamente sigure ale sistemului.

În spatele fiecărei reacții a camionului există o întrebare pusă la timp, o cerință clarificată, o dependență urmărită, o modificare analizată, un test definit și o dovadă păstrată. Uneori pare lent, uneori pare prea riguros, iar uneori pare că un singur cuvânt poate genera o discuție disproporționat de lungă. Dar într-un sistem de zeci de tone, cu oameni reali în jurul lui, cuvântul acela poate conta.

Pentru mine, requirements engineering este exact această punte dintre intenție și realitate. Între ceea ce vrem ca sistemul să facă și ceea ce poate fi proiectat, implementat, verificat și demonstrat. Între nevoia unui client, o constrângere legală, o decizie de arhitectură și comportamentul final al vehiculului pe drum.

Documentația devine funcție, analiza devine decizie, iar munca nevăzută ajunge să se deplaseze pe autostradă.