Inovație cu sisteme critice pentru viață

Fiecare întreprindere are o infrastructură „critică”. În general, aceasta înseamnă că, dacă sistemul este offline, părți (sau toată) afacerea se vor opri până când tehnicienii îl vor putea pune din nou în funcțiune. Acest lucru se întâmplă adesea atunci când sunt necesare actualizări mari de software, hardware sau rețea: sistemele nou implementate conțin erori neașteptate care provoacă o defecțiune a sistemului sau utilizatorii greșesc cu noul sistem deoarece nu sunt familiarizați cu acesta, iar productivitatea se oprește până când tehnicienii pot. rezolvați erorile de implementare sau instruiți utilizatorii. În cea mai mare parte, o perioadă de nefuncționare sau productivitate redusă este un risc acceptabil în schimbul promisiunii de îmbunătățire a performanței și eficienței noii tehnologii, dar acest lucru nu este universal. Majoritatea companiilor își pot permite o anumită perioadă de nefuncționare fără a risca venituri mari sau a-și antagoniza clienții.

Dar ce se întâmplă atunci când sistemele pe care trebuie să le modificați sunt sisteme critice pentru viață, unde siguranța vieții depinde de capacitatea de a utiliza sistemul în mod fiabil?

Acest articol se îndepărtează de dezvoltarea de software mai tradițională pe care ne petrecem cea mai mare parte a timpului și, în schimb, aruncă o privire asupra elementului uman din sistemele critice pentru viață. Gândurile mele cu privire la acest subiect provin din experiența mea ca director al tehnologiei informației pentru un serviciu de ambulanță 911, ca specialist în tehnologie pentru o organizație internațională de răspuns la dezastre umanitare și cu doctoratul meu. în Integrarea Sistemelor Umane finalizat la Institutul de Tehnologie din Massachusetts.

Înainte de a începe, aș dori să explic de ce acest lucru poate fi relevant pentru dvs. Deși poate să nu fie evident că proiectul dvs. implică de fapt un sistem critic pentru viață, este mult mai probabil decât ați crede. Toate următoarele se califică, precum și nenumărate alte subiecte:

• Automobile. Lucrezi la un proiect cu un producător de vehicule sau cu oricare dintre furnizorii acestuia? Recrutat în afara universității de către o companie startup cu mașini autonome? Frânare automată, controlul vitezei de croazieră, controlul benzii de rulare, vizualizarea computerizată, recunoașterea obstacolelor, modulele electronice de control al motorului etc. Fiecare dintre acestea este un sistem critic pentru viață, unde o defecțiune poate fi fatală.
• Aviaţie. Când ești la 30.000 de picioare în aer, aproape orice defecțiune a sistemului poate fi critică pentru viață. Având în vedere evenimentele recente cu Boeing 737 MAX, există sistemele evidente, critice pentru viață, de pilot automat și control computerizat de zbor, dar există și o mulțime de lucruri la care s-ar putea să nu te gândești. Acasă, dacă ventilatorul din sistemul dvs. HVAC se defectează și scoate puțin fum, deschideți fereastra sau ieșiți afară pentru aer curat. Ai încercat vreodată să deschizi geamul și să ieși afară în timpul unui zbor transatlantic? Chiar și cele mai de bază sisteme, de la prizele de curent din bucătărie până la frânele de pe roțile căruciorului de băuturi, pot fi critice pentru viața aeronavelor.
• Comunicatii. Majoritatea dezvoltatorilor sau inginerilor vor lucra, la un moment dat în cariera lor, la un proiect de sistem de comunicații într-o calitate sau alta. Pentru mulți oameni, telecomunicațiile nu par inițial critice pentru viață; la urma urmei, civilizației s-a descurcat bine înaintea telefoanelor și a internetului. În calitate de persoană care s-a desfășurat în zonele de dezastru în care infrastructura de telecomunicații a fost distrusă, permiteți-mi să vă spun ce se întâmplă de fapt: oamenii se îmbolnăvesc grav sau sunt răniți și nu pot suna la 911; rezidenții în vârstă nu își pot suna copiii pentru a le cere să-și ridice rețetele de la farmacie; personalul de intervenție în caz de urgență nu poate comunica cu dispecerii lor sau între ei; iar oamenii care nu-și pot contacta membrii familiei devin îngrijorați și se pun în situații extrem de periculoase pentru a încerca să-i găsească. Sistemele de comunicații sunt absolut critice pentru viață.

În lumea de astăzi în care se bazează puternic pe tehnologie, proiectele pe care nu le-ați considerat niciodată semi-importante ar putea ajunge să fie o componentă vitală a unui sistem vital.

Dar dacă nu este stricat, nu-l repara

Ați auzit sau folosit vreodată cuvântul „moștenire” în legătură cu un sistem tehnologic? Este un cuvânt puternic, care invocă gânduri despre tradiții de lungă durată, descendență și vremuri dificile de odinioară. În lumea ingineriei, este folosit pentru a desemna proiecte care există de mult timp și s-a dovedit că funcționează în mod fiabil și este adesea văzută ca o trăsătură de dorit pentru reducerea riscului. În realitate, este un eufemism pentru tehnologia arhaică care nu a fost niciodată actualizată din cauza aversiunii față de risc și este răspândit în industriile în care defecțiunile sistemului pot duce la consecințe grave.

Există un motiv întemeiat în spatele acestei afinități față de software-ul și hardware-ul de patrimoniu. Se știe că funcționează, este puțin probabil să apară erori necunoscute, iar costurile sale sunt stabile și previzibile. Un exemplu excelent este industria zborurilor spațiale: nava spațială rusă Soyuz a lansat astronauți în spațiu de peste 50 de ani cu doar revizii minore în acest timp și continuă să fie folosită pentru că este fiabilă și sigură. Din păcate, asta înseamnă că este, de asemenea, extrem de ineficient în comparație cu design-urile moderne: în timp ce Soyuz costă NASA 81 de milioane USD per loc pentru a zbura astronauți către stația spațială folosind hardware-ul său de moștenire, SpaceX și Boeing sunt de așteptat să ofere locuri pentru 58 milioane USD fiecare. folosind modelele lor moderne de rachete.

Este de înțeles că puțini oameni doresc să actualizeze sisteme vechi care încă funcționează; directorii nu vor riscul, tehnicienii nu vor să aibă de-a face cu serverul misterios din dulap cu un timp de funcționare de 12 ani, iar clienții nu vor să fie nevoiți să învețe noi modele. Din păcate, există un punct de răsturnare între minimizarea riscurilor și economiile de costuri: designurile de patrimoniu vor trebui actualizate în cele din urmă, chiar și în medii cu risc ridicat .

Restul acestui articol acoperă câțiva dintre pașii mai importanți ai procesului de a face acest lucru atunci când sistemele dvs. sunt critice pentru viață, cum ar fi cele folosite de primii respondenți, unități militare sau aeronave.

Convingerea alamei

Din experiența mea, probabil cel mai greu pas al procesului este convingerea factorilor de decizie și a părților interesate că sunt necesare actualizări. Sistemele care funcționează în medii critice pentru viață sunt adesea guvernate de reglementări legale extinse și politici de organizare, ceea ce înseamnă că trebuie să-i convingi că nu numai că ar trebui să-și asume riscul și să cheltuiască banii, ci și că ar trebui să se angajeze în ceea ce ar putea fi cu ușurință mai multe. ani de tăiere birocratică a benzii. Cea mai puternică opoziție cu care te vei confrunta va fi probabil din partea echipei juridice, care va expune în detaliu chinuitor potențiala răspundere față de care vei deschide organizația prin introducerea noii tehnologii. Au dreptate: răspunderea este o problemă majoră , iar dacă ceva se sparge și cineva este rănit sau moare, ar putea fi o povară etică, reputațională și financiară masivă.

Indiferent dacă lucrați cu o corporație Fortune 500 sau cu departamentul local de pompieri voluntari, totul se reduce întotdeauna la același lucru: bani. Corporațiile nu vor să-l piardă, iar organizațiile nonprofit nu au cu ce să lucreze în primul rând. Singura modalitate fiabilă pe care am găsit-o de a convinge conducerea unei organizații să-și asume riscul de a schimba un sistem critic pentru viață este să demonstrez că, probabil, fie ei sunt mai probabil să câștige/economisească bani decât să-i piardă, fie că pot să-și reducă răspunderea prin modernizarea tehnologiei și îmbunătățirea siguranței.

Asta înseamnă că trebuie să faci calculul. Care este probabilitatea ca un timp de nefuncționare extins sau viitoare blocări din cauza erorilor (pe baza implementărilor anterioare în organizația dvs. sau a datelor de la alte organizații)? Care este impactul așteptat dacă eșuează și cât ar costa? În schimb, care sunt câștigurile de performanță sau fiabilitate așteptate și ce valoare ar fi acestea? Dacă poți arăta că există o mare probabilitate să ieși înainte, există șanse mari să obții undă verde.

Nu este vorba despre tine

S-ar putea să fiți familiarizați cu expresia „de către ingineri, pentru ingineri”, o expresie care sugerează că inginerii au construit ceva pentru a fi folosit de oameni cu calificări similare cu ale lor. Este o apariție extrem de comună și a fost unul dintre principalii factori precipitanți ai creșterii studiilor de utilizare a computerelor la începutul anilor 1990. În calitate de ingineri, avem adesea modele mentale diferite ale modului în care funcționează sistemele tehnologice față de utilizatorul final mediu, ceea ce duce la o tendință de a proiecta sisteme cu presupunerea că utilizatorul final știe deja cum funcționează. În sistemele convenționale, acest lucru duce la erori și clienți nemulțumiți; în sistemele critice pentru viață, poate duce la moarte.

Luați în considerare cazul zborului Air France 447. La 1 iunie 2009, Airbus A330 se afla deasupra Oceanului Atlantic pe drum de la Rio de Janeiro la Paris. Cristalele de gheață au obturat tuburile Pitot, provocând inconsecvențe în măsurătorile vitezei aerului. Calculatorul de zbor a dezactivat pilotul automat, recunoscând că nu putea pilota în mod fiabil avionul însuși cu date incorecte despre viteza aerului. Apoi sa plasat într-un mod „înveliș extins de zbor” , care a permis piloților să efectueze manevre pe care computerul nu le-ar permite în mod normal. Vă puteți imagina inginerii care au construit sistemul gândindu-se „dacă pilotul automat se decuplează singur, probabil că există o situație în care piloții ar putea avea nevoie de control suplimentar! ”

Acesta este trenul natural de gândire al inginerilor, care înțeleg ce fel de lucruri ar putea determina decuplarea pilotului automat. Pentru piloți, nu a fost cazul. Au forțat aeronava să urce abruptă în sus, ignorând avertismentele „STAL”, până când a pierdut toată viteza aerului și a căzut în ocean. Toți cei 228 de pasageri și echipaj au fost uciși. Deși există mai multe idei cu privire la motivația exactă a acțiunilor lor, teoria predominantă este că piloții au presupus că computerul de zbor va împiedica intrările de control care ar bloca aeronava (ceea ce este adevărat pentru anvelopa normală de zbor) și nu și-au dat seama că trecuse la modul plic extins pentru că nu împărtășeau modelul mental al inginerilor despre logica care conducea deciziile computerului.

Deși este un traseu obișnuit, acest lucru ne duce la punctul meu principal: acțiunile pe care doriți să le întreprindă utilizatorii în anumite condiții trebuie să fie acțiunile care par naturale pentru utilizator .

Utilizatorii pot fi instruiți să urmeze proceduri specifice, dar pur și simplu nu își vor aminti întotdeauna ce trebuie să facă sau să înțeleagă ce se întâmplă în condiții de stres ridicat. Este responsabilitatea dvs. să proiectați software-ul, controalele și interfețele într-o manieră intuitivă, care îi face pe utilizatori să își dorească în mod inerent să facă lucrurile pe care ar trebui să le facă.

Acest lucru înseamnă că este absolut esențial ca utilizatorii finali să fie implicați în fiecare etapă a procesului de proiectare și dezvoltare. Nu se pot face presupuneri despre ceea ce probabil vor face utilizatorii; totul trebuie să se bazeze pe dovezi. Când proiectați interfețe, trebuie să efectuați studii pentru a determina tiparele de gândire pe care acestea le induc utilizatorilor și să le ajustați după cum este necesar. Când testați noile sisteme, trebuie să le testați cu utilizatori reali în medii reale în condiții realiste. Și, din păcate, atunci când vă modificați designul, trebuie să faceți acești pași din nou.

Deși fiecare sistem complex este unic, aș dori să menționez trei considerente de proiectare, în special, care ar trebui aplicate universal:

• Controalele ar trebui să fie reprezentative pentru acțiunile pe care le invocă. Din fericire, acesta este destul de comun, văzut în general sub forma selectării pictogramelor relevante pentru butoanele GUI sau a formelor relevante pentru controalele fizice. Butoanele „Fișier nou” folosesc o pictogramă coală goală de hârtie, iar pârghiile trenului de aterizare din aeronave au un buton în formă de roată. Cu toate acestea, este ușor să devii mulțumit. De ce mai vedem pictograme de dischetă de 3,5” pentru butoanele „Salvare”? Știe cineva mai mic de 25 de ani ce este o dischetă? Continuăm să-l folosim pentru că credem că este reprezentativ, dar chiar nu mai este. Este nevoie de un efort constant pentru a ne asigura că reprezentările controalelor sunt semnificative pentru utilizatori, dar este, de asemenea, necesar și dificil să echilibrați acest lucru cu continuitatea.
• Dacă un sistem de avertizare se defectează, acesta trebuie să fie detectabil. Folosim adesea lumini de avertizare care se activează atunci când există o problemă, cum ar fi un indicator roșu intermitent. Este grozav pentru a atrage atenția unui utilizator, dar ce se întâmplă dacă lumina se stinge? Nava spațială folosită în misiunile lunare Apollo avea zeci de lumini de avertizare pentru tot felul de sisteme, dar acestea nu funcționau într-o manieră convențională. În loc să se lumineze atunci când a fost o problemă, au rămas iluminate când totul era în regulă și s-au oprit când a fost o problemă. Acest lucru a asigurat că o lumină de avertizare arsă nu i-ar determina pe astronauți să rateze o eroare de sistem potențial fatală. Nu spun că ar trebui să utilizați acest design, deoarece becurile au parcurs un drum lung în ceea ce privește fiabilitatea din anii 1960, dar oferă o idee despre cât de aprofundată trebuie să fie o parte din planificarea dvs. De câte ori s-a prăbușit un sistem, dar nu știați despre el, deoarece înregistrarea sau notificările nu funcționau corect?
• Tranzițiile de mod trebuie să fie evidente pentru utilizator. Ce se întâmplă dacă un Airbus A330 trece de la modul de control normal la modul de control avansat fără ca utilizatorul să observe și dintr-o dată aeronava face lucruri pe care utilizatorul nu credea că le poate face? Ce se întâmplă dacă o mașină cu conducere autonomă își decuplează pilotul automat, lăsând utilizatorul în mod neașteptat în control deplin? Ce se întâmplă atunci când există o tranziție majoră în mod sau funcționalitate care necesită o schimbare imediată a acțiunilor utilizatorului, dar utilizatorului îi ia un minut sau două pentru a-și da seama ce tocmai sa întâmplat? În timp ce o varietate de moduri de operare pot fi necesare într-un sistem complex, modurile nu pot trece fără o notificare adecvată, explicații și interacțiune cu utilizatorul în acest sens.

Scoaterea din magazin a sistemelor critice pentru viață

În conformitate cu cele mai bune practici din industrie, o fază beta este crucială pentru implementarea de noi sisteme critice pentru viață. Testele noii tehnologii v-au ajutat să corectați majoritatea erorilor și problemelor de utilizare, dar pericolele ascunse pot apărea atunci când trebuie utilizată împreună cu alte sisteme în medii reale. În disciplina ingineriei sistemelor, aceasta este cunoscută sub numele de „apariție”. Proprietățile emergente sunt „comportamente neașteptate care provin din interacțiunea dintre componentele unei aplicații și mediul lor” și prin însăși natura lor sunt în esență imposibil de detectat într-un cadru de laborator. Invitând un grup reprezentativ de utilizatori finali să testeze noul sistem sub supraveghere atentă, multe dintre aceste proprietăți pot fi detectate și evaluate pentru consecințele negative care pot apărea în implementarea la scară largă.

Un alt subiect care apare adesea în discuțiile de arhitectură cu clienții mei este cel al lansării în faze. Aceasta este alegerea între înlocuirea treptată a elementelor unui sistem preexistent cu elemente ale unuia nou până când în cele din urmă totul este înlocuit versus schimbarea totul deodată. Există argumente pro și contra pentru fiecare: o lansare treptată permite aclimatizarea treptată a utilizatorilor la noul design, asigurându-se că schimbările vin în cantități gestionabile și utilizatorii nu sunt copleșiți; pe de altă parte, poate trage procesul pe perioade lungi și poate duce la o stare constantă de tranziție. Lansările imediate sunt benefice în sensul că „smulg dispozitivul” și accelerează lucrurile, dar schimbările bruște drastice îi pot copleși pe utilizatori.

Pentru sistemele critice pentru viață, am constatat că lansările în etape sunt în general mai sigure, deoarece permit evaluarea incrementală a componentelor individuale într-un mediu de producție și permit reversiuni mai mici dacă ceva trebuie să fie anulat. Totuși, acesta este ceva care trebuie evaluat de la caz la caz.

Normalizarea Devianței

OK, deci testarea dvs. de utilizator v-a ajutat să proiectați un sistem intuitiv, faza beta a identificat probleme emergente, lansarea în etape a permis utilizatorilor să se simtă confortabil cu designul și totul funcționează fără probleme. Ai terminat, nu? Din nefericire nu.

Problemele cu sistemul dvs. vor apărea inevitabil, nu puteți ocoli asta. Când utilizatorii întâmpină aceste probleme, ei vor dezvolta adesea soluții alternative în loc să raporteze problema echipei de tehnologie. Soluțiile vor deveni o practică standard, împărtășită ca „sfaturi” de la veterani la începători. Sociologul Diane Vaughan a inventat o expresie pentru a descrie acest fenomen: „normalizarea devianței”. Utilizatorii devin atât de obișnuiți cu comportamentul deviant, încât nu își amintesc că acesta este, de fapt, deviant.

Exemplul clasic este naveta spațială Challenger: s-a observat în mod regulat că o componentă a rachetelor solide se erodează în timpul lansării și, deși toată lumea știa că erodarea componentelor rachetei este un lucru rău, s-a întâmplat atât de des încât s-au emis în mod regulat derogări și a fost luat în considerare. normal. Pe 28 ianuarie 1986, problema pe care toată lumea o știa inițial nu ar trebui permisă, dar pe care s-au normalizat, a dus la explozia lui Challenger și la moartea a șapte astronauți.

În calitate de administrator al unui sistem critic pentru viață, depinde de dvs. să preveniți astfel de evenimente. Studiați modul în care utilizatorii dvs. interacționează cu sistemul. Umbriți-le timp de câteva zile și vedeți dacă folosesc soluții neașteptate. Trimiteți periodic sondaje pentru a solicita modificări și îmbunătățiri sugerate. Dedicați timp și efort pentru a vă îmbunătăți sistemul înainte ca utilizatorii să găsească modalități de a rezolva problemele fără dvs.

Antrenament pentru performanță sub presiune

Este adesea cazul că defecțiunile în sistemele critice pentru viață apar atunci când utilizatorii suferă de stres, creșteri de adrenalină și vedere în tunel. S-a întâmplat piloților de pe Air France 447, s-a întâmplat cu paramedicii care nu își amintesc cum să-și opereze monitorul cardiac la primul pacient cu stop cardiac și s-a întâmplat soldaților care nu își pot opera corect radiourile în timp ce sunt sub foc.

O parte din acest risc este ameliorat prin utilizarea design-urilor intuitive, așa cum sa discutat mai devreme, dar numai acest lucru este insuficient. În special în mediile în care scenariile de mare stres apar, dar apar rar, este esențial să vă instruiți utilizatorii nu doar cum să vă opereze sistemul, ci și cum să gândiți clar în astfel de condiții. Dacă utilizatorii memorează acțiuni legate de operarea echipamentelor, ei nu pot face față defecțiunilor neașteptate, deoarece acțiunile pe care le-au învățat pot să nu mai fie adecvate; dacă se antrenează să gândească logic și clar în condiții de stres, ei pot răspunde la circumstanțe în schimbare și pot ajuta sistemul să rămână în viață atunci când ceva se sparge.

Concluzie

Evident, dezvoltarea, implementarea și întreținerea software-ului critic pentru viață este mult mai complexă decât poate fi detaliat într-un singur articol. Cu toate acestea, aceste domenii de luare în considerare vă pot ajuta să vă oferiți o idee mai bună despre ce să vă așteptați atunci când vă gândiți să lucrați la un astfel de proiect. În concluzie:

• Inovația este necesară, chiar și atunci când totul funcționează fără probleme
• Este greu să-i convingi pe directori că riscul merită, dar cifrele nu mint
• Utilizatorii finali trebuie să fie implicați în fiecare pas al procesului
• Testați și re-testați cu utilizatori reali în medii reale în condiții realiste
• Nu presupuneți că ați înțeles bine prima dată; chiar dacă funcționează, pot exista probleme nedetectate despre care utilizatorii dvs. nu vă vorbesc.
• Instruiți-vă utilizatorii nu doar despre cum să folosească sistemul, ci și despre cum să gândească clar și să se adapteze la stres.

În încheiere, aș dori să remarc că în sistemele complexe de siguranță critice, lucrurile vor merge prost la un moment dat, indiferent de cât de multă planificare, testare și întreținere faci. Când acele sisteme sunt critice pentru viață, este foarte posibil ca o defecțiune să ducă la pierderea vieții sau a unui membru.

În cazul în care o astfel de tragedie are loc cu ceva pentru care ești responsabil, va fi o greutate zdrobitoare asupra conștiinței tale și probabil vei crede că ai fi putut preveni dacă ai fi acordat mai multă atenție sau ai fi muncit mai mult. Poate că este adevărat, poate nu este, dar este imposibil să prevăd orice întâmplare posibilă.

Lucrează cu meticulozitate, nu fi înfățișat și vei face din lume un loc mai bun.