Trace.Space laiž klajā Trinity — inženierijas dati nonāk vienā modelī

Rīgā 2022. gadā dibinātais Trace.Space, kas piesaistījis 6 miljonus ASV dolāru investīcijās, 29. septembrī paziņoja par Trinity palaišanu. Platforma ir pieejama ar uzņēmuma starpniecību. Tā vienā inženierijas modelī sasaista produkta prasības, testus, projektēšanas parametrus un variantus, lai komanda varētu izsekot, ko skar konkrēta izmaiņa.

Trace.Space tādējādi paplašina piedāvājumu ārpus prasību pārvaldības: jaunajā modelī var redzēt arī to, kā prasība saistīta ar pārbaudi un kurai produkta konfigurācijai pārbaudes rezultāts ir piemērojams. Tas ir svarīgi fiziskiem produktiem, kuru aparatūra un programmatūra mainās vairākās paaudzēs, kamēr iepriekšējās versijas vēl tiek izmantotas.

Ko Trinity sasaista

Trinity galvenā funkcija ir saglabāt saites starp dažādu veidu inženierijas datiem. Prasība apraksta, kas produktam jāspēj; projektēšanas parametrs raksturo izvēlēto risinājumu; tests palīdz noteikt, vai prasība ir izpildīta. Produkta variants šīm saitēm pievieno būtisku nosacījumu: uz kuru konkrēto konfigurāciju tās attiecas.

Trinity produkta aprakstā norādīts, ka, mainot parametru, modelis ļauj meklēt skartās prasības, testus un variantus. Tas paredz arī iespēju kopīgās produkta īpašības definēt vienreiz un atsevišķi norādīt katras versijas atšķirības. Līdz ar to izmaiņu analīze sākas no savienotajiem datiem, nevis no pieņēmuma, ka visas produkta versijas ir vienādas.

Uzņēmums šo uzbūvi raksturo ar trim darbībām: reģistrēt inženierijas informāciju, sasaistīt tās elementus un analizēt attiecības starp tiem. Redzamā funkcija ir atkarību parādīšana modelī; tas pats par sevi vēl nenosaka, vai jauns risinājums būs drošs vai sekmīgi izturēs pārbaudi. Lai izmaiņu ietekme būtu uzticama, modelī jābūt ievadītām pareizajām prasībām, konfigurācijām un pārbaužu saitēm.

Kāpēc vienam produktam vajadzīgas vairākas pārbaužu vēstures

Variantu pārvaldība risina problēmu, kas rodas, produktam attīstoties pēc sākotnējās izlaišanas. Vienai aparatūras versijai veikts tests ne vienmēr apliecina to pašu nākamajai versijai, kurā mainījies parametrs vai programmatūra. Komandai jāspēj atšķirt kopīgu prasību no konkrētā varianta pārbaudes rezultāta un noteikt, vai pēc izmaiņas pārbaude jāatkārto.

Trace.Space klienta Serve Robotics autonomajiem ietves piegādes robotiem vienlaikus tiek izmantotas vairākas robotu un autonomās programmatūras paaudzes. Šis piemērs parāda, kāpēc ar vienu visai produktu saimei piesaistītu testu sarakstu nepietiek: katra konfigurācija attīstās savā laikā. Saikne starp prasību, aparatūru un testu palīdz noteikt, uz kuru versiju attiecas jau iegūtais rezultāts.

Ja, piemēram, mainītos kādas robotu versijas projektēšanas parametrs, vispirms būtu jānoskaidro, kuri testi šo parametru pārbauda un vai pārējās versijās izmantots tas pats risinājums. Tas ir nosacīts darba plūsmas piemērs, nevis publiskots Serve Robotics testa rezultāts. Trinity uzdevums šādā situācijā ir parādīt modelī reģistrētās atkarības, lai inženieris varētu izlemt, kur nepieciešama atkārtota pārbaude.

Kāda loma ir mākslīgā intelekta aģentiem

Savienotais modelis paredzēts arī mākslīgā intelekta aģentu darbam. Trace.Space Space Agent var sagatavot prasību projektus, ieteikt saites starp datiem, analizēt izmaiņu ietekmi un meklēt pārklājuma nepilnības. Trinity piedāvā dokumentētu REST API un MCP serveri, lai ar to pašu produkta definīciju varētu strādāt arī citi aģenti.

Uzņēmuma aprakstītajā darba plūsmā komanda nosaka noteikumus aģentu darbības pārbaudei, bet inženieris var apskatīt izmantoto kontekstu un apstiprina ierosinātās izmaiņas. Tādējādi aģents var palīdzēt atrast iespējamu pārrāvumu starp prasību un testu, savukārt lēmums par tā nozīmi paliek cilvēkam. Ja saites modelī ir nepilnīgas, arī aģenta analīzei trūks daļas produkta konteksta.

Trace.Space sola, ka izmaiņu ietekmi varēs noteikt sekundēs un Space Agent spēs pēcpusdienā paveikt darbu, kas citādi prasītu nedēļu. Tie ir uzņēmuma ātruma apgalvojumi; līdz ar palaišanu nav publiskots neatkarīgs salīdzinājums ar vienādiem uzdevumiem un pārbaudes nosacījumiem. Konkrētāk pārbaudāms ir piedāvātais darbības princips: aģenti izmanto tās pašas prasību, testu, parametru un variantu saites, kuras redz inženieri.

Ko palaišana maina Trace.Space pozīcijā

Uzņēmums sāka ar prasību pārvaldību, bet ar Trinity pretendē uz plašāku vietu fizisku produktu izstrādē. Intervijā Tech.eu Trace.Space vadītājs Jānis Vāvere sacīja “But the plan was never to stay in requirements only” un lēsa, ka Trinity tagad aptver aptuveni 40 % produkta izstrādes cikla, salīdzinot ar aptuveni 10 % uzņēmuma darbības sākumā; ilgtermiņa mērķis ir 80 %. Šie procenti ir uzņēmuma vērtējums par produkta tvērumu, nevis izmērīts klientu ražīguma pieaugums.

Paplašināšanās maina arī to, ar kādu uzdevumu Trace.Space dodas pie klienta. Prasību uzskaitei pievienojas testu, parametru un variantu savienošana, kā arī izmaiņu analīze visā šajā modelī. Uzņēmums plāno vēlāk aptvert modelēšanu, simulāciju un ražošanu; šīs jomas pašlaik raksturo iecerēto attīstību, nevis jau aprakstītās Trinity funkcijas.

Latvijas jaunuzņēmumam tas paver iespēju konkurēt par inženierijas datu pārvaldību visā produkta attīstības gaitā, īpaši komandās, kuras uztur vairākas fiziska produkta versijas. Šī pozīcija būs atkarīga no tā, cik labi platforma reālā darbā saglabās saites starp mainīgiem produktiem un to pārbaudēm: tieši tur uzņēmuma plašākais piedāvājums sastop savu būtiskāko pārbaudījumu.