Deoarece:
- acum o săptămână se întâmplau lucruri interesante
- interwebsul a aflat noutăți vechi de câțiva ani și se isterizează pe marginea lor
- nu am mai scris de multă vreme
- acest subiect este planificat de mai mult de un an
astăzi ne vom uita la calculatoarele care se ocupă de rachetele Falcon 9 și de capsulele Dragon. Vom amâna astfel discuția despre calculatoarele de pe Saturn V, Apollo CM, Apollo LM/LEM pentru mai târziu. Informațiile prezentate nu sunt foarte actuale, nu există descrieri detaliate și la zi iar multe aspecte sunt contradictorii din cauza restricțiilor impuse de ITAR şi de păstrarea secretelor comerciale.
Prezentarea face parte din domeniul ghidare-navigație-control (engl GNC – Guidance, Navigation and Control), acesta fiind acel domeniu al ingineriei care se ocupă de proiectarea sistemelor folosite petru controlul mișcării vehiculelor – automobile, nave, avioane, rachete, nave spațiale.
Problema
Câteva aspecte generale înainte de toate, care ne vor permite să înțelegem problema.
Ghidarea unei rachete de la lansare până la destinație (în cazul nostru Falcon 9 + Dragon din Florida până pe ISS) are mai multe etape, fiecare cu provocările sale:
– în prima parte a traiectoriei (de la lansare și până la ieșirea din atmosferă) sistemul de conrol trebuie să ia în calcul rezistența la înaintare, să nu fie depășite forțele pe care le pot suporta vehiculul și echipajul, să răspundă la evenimente externe (rafale de vânt, accidente);
– urmează apoi ieșirea din atmosferă și eventuale manevre de schimbare a traiectoriei;
– oprirea motorului primei trepte, separarea treptei întâi și eventual recuperarea ei;
– oprinderea motorului treptei a doua și eventuale corecții;
– oprirea motorului treptei a doua și repornirea sa, dacă este cazul;
– aprinderea motoarelor capsulelor pentru a ajunge la destinație;
– diverse operații de schimbare a orientării (en attitude) și de deplasare.
Iată deci doar câteva din mulțimea de operații care au fost realizate de sistemele de ghidare, navigare și control, de la începutul explorării spațiale.
Din punct de vedere al mediului, echipamentele electronice trebuie să reziste la mai multe provocări – temperaturi ridicate sau joase (de la -150 la +150 grade Celsius), radiații, accelerații, vibrații. Unele probleme au fost detaliate în două postari anterioare – Tehnologii (episodul 2): inamicii tehnologiei – accelerația și Tehnologii (episodul 3): inamicii tehnologiei – spațiul.
Cum (hardware)
SpaceX a ales să utilizeze componente standard, disponibile comercial (engl COTS – Commercial Off-The-Shelf). Condițiile principale la alegerea sistemelor de calcul au fost:
- să fie suficient de performante pentru a rezolva problemele
- suita de programe folosite pentru dezvoltare disponibilă (engl toolchain)
Pe parcursul acestei expuneri vor fi folosiți cu același sens termenii calculator, sistem, sistem de calcul.
Prima informație foarte interesantă este că SpaceX folosește sisteme având procesoare Intel din familia x86, câte trei sisteme pentru fiecare operațiune unde sunt implicate sisteme de calcul. Sunt trei pentru redundanță, dar această discuție o vom avea mai târziu deoarece redundanța este asigurată prin software. Există informații care se referă la utilizarea pentru controlul diverselor elemente (ex: suprafețe de control, picioare, etc) pe prima și a doua treaptă a Falcon 9 a microcontrollerelor PowerPC.
Există informații contradictorii referitoare la sistemele care controlează motoarele (bazate pe procesoare x86 vs microcontrollere PowerPC) și număr de sisteme care este folosit la fiecare motor al primei trepte Falcon 9. Unele surse vorbesc de trei calculatoare pentru fiecare motor Merlin (deci 27 în total având o configurație redundantă), altele despre câte un calculator pentru fiecare motor (fără a detalia dacă se se referă la ansamblul format de trei sisteme redundante sau un singur sistem). De asemenea, şi alte sisteme (suprafețele de control de exemplu) au propriile calculatoare de control.
Pe lângă acestea, există încă trei sisteme care să facă operațiunile principale (navigație și ghidare), alături de supravegherea și controlul celorlalte calculatoare/microcontrollere. Avem deci o separare a funcției calculatoarelor – unele pentru control în timp ce ultimele ar fi responsabile cu navigația și deciziile referitoare la zbor – controlul traiectoriei la lansare și manevrele efectuate pentru recuperare. În oricare dintre variante ajungem la un număr de cel puțin 15 sisteme doar pentru prima treaptă.
A doua treaptă, păstrând aceleaşi principii de construcție putem presupune că ar avea trei sisteme pentru motorul Merlin Vacuum (engl orig MVac) sau unul singur și încă 3 pentru ghidare și navigație. Deci minimum 4 sisteme pentru a doua treaptă.
Capsula Dragon utilizată în programul de reaprovizionare al ISS avea același gen de calculatoare de ghidare şi navigație într-o configurație redundantă, cu 3 bucăți. Pe lângă calculatoarele de navigație există și calculatoarele de intrare-ieșire (o unitate cu 3 calculatoare), acestea comunicând cu restul componentelor capsulei (senzori și elemente controlate) folosind module (engl RIO – remote input/output). Utilizarea sistemului cu module oferă flexibilitate în alegerea placilor de achiziție de date și control. Arhitectura aceasta a fost aleasă pentru un proces de producție cât mai simplu. Una din surse vorbește despre un număr de 18 unități de calcul în capsula Dragon în 2012, ceea ce ar duce numărul calculatoarelor la 54, doar în capsulă.
Calculator cu module I/O ()
O altă sursă susține că pe capsula Dragon sistemele de navigație ar rula pe procesoare ARM și nu x86.
Părerea autorului este că oriunde a fost implementată o unitate de calcul, aceasta a avut și are configurație redundantă, cu trei calculatoare. Deci 27 de calculatoare, în unități de câte trei, pentru motoarele primei trepte. Deși pare ciudată utilizarea de calculatoare dedicate pentru motoare, ei bine nu este. Aceste calculatoare interacționează direct cu motoarele, primind informații de la senzori și trimițând comenzi către diverse componente ale motorului, acestea fiind controlate direct. Și naveta spațială folosea calculatoare pentru controlul motoarelor RS-25 – este vorba despre Honeywell HDC-601, care era deja folosit de USAF din 1972. Alegerea sa a fost determinată și de compatibilitatea software cu Honeywell DDP 516, deci exista disponibil și un mediu de dezvoltare.
RS-25 și HDC-601 (NASA)
Ca o observație de final, NASA nu a avut și nu are în cerințe ca procesoarele să fie rezistente la radiații (engl radiation hardened / RadHard), ci ca sistemele să funcționeze fără probleme, fiind luate în calcul condițiile cu care au de-a face. Pentru Dragon, SpaceX a trebuit să realizeze o analiză a mediului, efectele sale asupra capsulei și să prezinte modul în care vor reacționa/se vor comporta sistemele Dragon și SpaceX.
Cum (software)
Calculatoarele sunt ca oamenii: fără software se aseamănă cu jandarmii – doar niște obiecte contondente fără nici o utilitate reală; software-ul le face să își realizeze scopul. Să aruncăm deci o privire și la software-ul care rulează pe sistemele Falcon 9/Dragon și să vedem cum funcționează ele.
În primul rând, sistemul de operare de pe zburătoare: este, bineînțeles, Linux. Informațiile detaliate sunt oarecum contadictorii. Textul în original, publicat în 2012 în Aviation Week, este: There are actually six computers. They operate in pairs, so there are three computer units, each of which have two computers checking on each other. care se traduce De fapt sunt șase calculatoare. Ele funcționează în perechi, deci sunt trei unități de calcul, fiecare cu câte două calculatoare care se verifică reciproc..
Ce ar putea însemna aceasta? Că o unitate de calcul este de fapt un procesor cu două nuclee (engl dual core) sau o unitate de calcul sunt de fapt două calculatoare diferite?
Mai departe, unele informații vorbesc despre rularea unei instanțe de Linux pe un nucleu (deci o unitate de calcul rulează de fapt două sisteme de operare Linux) și în fiecare instanță software-ul SpaceX. Dar mai pot exista și alte variante. Paractic avem următoarele opțiuni:
– un singur sistem de operare rulează pe ambele nuclee și acesta are două instanțe ale software-ului GNC al SpaceX, fiecare instanță rulând pe câte un nucleu;
– două kerneluri Linux cu modificări majore, fiecare rulând pe câte un nucleu și fiecare kernel Linux rulează câte un software GNC al SpaceX;
– două mașini virtuale Linux, fiecare pe câte un nucleu al procesorului, în fiecare mașină virtuală rulând o instanță a softwareului GNC al SpaceX;
– două calculatoare distincte, în același modul formează o unitate de calcul; fiecare calculator rulează un sistem Linux și o instanță a softwareului GNC al SpaceX.
Cum funcționează sistemul? Cele două instanțe ale software-ului GNC fac calcule pe baza algoritmulilor implementați şi rezultă o comandă. Un supervizor compară cele două rezultate şi dacă sunt identice, comanda este trimisă pentru execuție. Dacă cele două rezultate sunt diferite, nu este trimisă nici o comandă.
Pentru a executa o comandă (de exemplu schimbarea orientării suprafețelor de control), microcontrollerul care se ocupă de acea activitate (orientarea suprafețelor de control în cazul nostru) trebuie să primească de la toate cele 3 sisteme aceeași comandă. Dacă una dintre comenzile primite diferă, atunci microcontrollerul va executa comanda primită de la celelalte două. În cazul în care toate sunt diferite se va păstra ultima stare sau o va alege pe cea de la sistemul considerat cel mai sigur. Dacă erorile primite de la unul dintre sisteme persistă, atunci acesta va fi trecut în modul defect. Acest model de redundanță (aceeași comandă primită de 3 ori) este folosit și de Airbus la sistemele fly-by-wire de pe avioanele sale. A fost aleasă de SpaceX pentru a nu cheltui sume exorbitante cu procesoarele și sistemele rezistente la radiații.
Poate exista – pentru capsula Dragon – situația în care calculatoarele au erori din cauza radiațiilor. În cazul în care în mod constant un calculator de navigație nu returnează rezultate corecte, acesta este repornit și copiază conținutul memoriei (datele utilizate pentru calcule) de pe unul din cele funcționale. Se va alătura apoi celor funcționale. În cazul unei erori care ar face ca toate cele 3 calculatoare de navigație să dea comenzi greșite, acestea pot fi oprite, de la sol fiind trimise comenzi prin unul din sistemele de comunicații (direct sau prin satelit) care ajung la calculatoarele de control, acestea executând direct operațiunile.
Din punct de vedere al cantității, estimarea în 2012 era la câteva sute de mii linii de cod sursă (între 100 k și 500 k conform SpaceX) pentru fiecare dintre vehicule. Andocarea Dragon la ISS a fost o provocare majoră necesitând scrierea unei bune părți de cod nou pentru capsula Dragon. Dar estimarea efortului depus pentru scrierea codului sursă doar cantitativ, după numărul de linii, este greșită. Vorba lui Bill Gates: este ca și cum ai estima gradul până la care a fost construit un avion strict pe baza masei sale.
Software-ul scris pentru Falcon 9 și Dragon este scris în C++. Evident, driverele (și alte componente software apropiate de sistemul de operare) sunt scrise în C. În 2016 exista informația că interfața cu utilizatorul este dezvoltată folosind browserul Chromium și JavaScript. Fiecare display este independent, cu propriul sistem de calcul, putând fi rebootat dacă este nevoie. De asemenea, există și opțiunea de a utiliza butoanele de sub display-uri pentru control, în cazul în care touchscreen-ul are probleme.
UI Dragon (NASA)
Sistemele aflate la sol (engl Mission Control) rulează sistemul de operare Windows cu aplicații scrise folosind LabView.
LabVIew (NASA/SpaceX)
Un alt pachet software folosit de SpaceX este Matlab.
Cum (dezvoltare și testare)
Una din surse vorbește despre faptul că dezvoltatorii SpaceX fac dezvoltarea și testarea pe birou, direct pe calculatoare reale gata de zbor. Costul redus al acestor sisteme le permite această abordare. I just walked around the factory this morning, just in the office area alone, and we have over 40 of the flight computers sitting on people’s desks. And if they were hard-to-come-by items, we wouldn’t have that many computers.
Ritmul de dezvoltare a fost incredibil până să se ajungă la versiunea curentă de Falcon 9. În 2013 deja se ajunsese la generația a treia de calculatoare de navigație.
Pe lângă acest mod de dezvoltare, există practic un întreg sistem care simulează o rachetă aflat la dispoziția dezvoltatorilor – o rachetă într-o cameră. Se poate realiza astfel testarea completă:
– dacă noii algoritmi funcționează corect
– dacă parametrii unei misiuni sunt corecți
– diverse erori sau situații neprevăzute (ex: oprirea unui motor, erori de calcul, erori de control, oprirea de calculatoare în timpul funcționării)
Inginerii sunt încurajați să adauge colectare de date în orice punct unde cred că ar fi de folos. Logurile sunt colectate și analizate automat, putând fi generate alarme în funcție de aceste valori. Acestea sunt stocate, alături de programele care rulau. Dacă o rachetă are o problemă, aceasta poate fi investigată, duplicându-se exact datele de intrare pentru a o putea rezolva. Mai mult, codul este testat automat pe racheta simulată.
Nu este folosit cod generat automat (de exemplu de Matlab).
Din punct de vedere al timpului cât rulează software-ul, Dragon oferă mult mai multe oportunități pentru rularea pe termen lung față de Falcon 9 (ore sau zile față de 10 minute). Evident, există posibilitatea de a rezolva erori și când vehiculul este în zbor. O situație problematică cu care s-a confruntat Dragon la începuturi a fost atunci când nu a putut andoca din cauza iluminării. Soluția a fost actualizarea software-ului capsulei, în zbor.
Cine
Echipa de dezvoltare pentru sistemele software ale vehiculelor avea în 2013 35 de dezvoltatori iar echipa de dezvoltare pentru sistemele de suport pentru misiune 9 dezvoltatori. Absolvenți de facultăți de inginerie (calculatoare, electronică), fizică, matematică sau chiar ingineri autodidacți.
Chiar astăzi am găsit disponibilă pe Glassdoor o poziție de dezvoltator software pentru sisteme Linux embedded la SpaceX (în Hawthorne, California). Cel mai probabil pentru a întreține acest software și a dezvolta componente noi. Despre ce este vorba?
Senior Software Engineer (Embedded Linux Software)
$88K-$149KAs a flight software engineer on the Embedded Linux Software team, you will be designing, developing, and testing software that is used to launch and operate SpaceX flight systems. You will engage with other SpaceX engineers to discover the needs of the mission and code highly reliable software that turns the mission into a reality. You will be responsible for the complete life-cycle of the software you create.
Aerospace experience is not required to be successful here – rather we look for smart, motivated, collaborative engineers who love solving problems and want to make an impact on a super inspiring mission
RESPONSIBILITIES:
– Develop highly reliable and available software systems
– Board bring-up of next-generation avionics computers
– Develop prototypes to prove out key design concepts and quantify technical constraints
– Write high quality structured bare metal and Linux-based software for embedded processors (e.g. ARM, PowerPC, x86, etc.)BASIC QUALIFICATIONS:
– Bachelor’s degree in computer science, engineering, math, or science discipline and 4+ years of experience in systems-level C (kernels, device drivers, hypervisors) OR 6+ years of experience in systems-level C (kernels, device drivers, hypervisors)PREFERRED SKILLS AND EXPERIENCE:
– Experience writing Linux kernel code for real-time systems
– Fluency in POSIX shell script and Python
– Have shipped embedded software in high volume products or real-time products that require high reliability and fault tolerance
– Significant understanding of embedded software principles and ability to contribute in design sessions
– Thorough knowledge of systems, computer architecture, software development, networks, and electronics
– Strong skills in debugging, performance optimization and unit testing
– Effective collaboration as a team member and in large code bases
– Creative approach to problem solving and exceptional analytical skills
– Ability to work effectively in a dynamic environment with changing needs and requirements
– Ability to work independently and in a team, take initiative, and communicate effectivelyADDITIONAL REQUIREMENTS:
– Willing to work extended hours and weekends when needed
Iulian
Surse:
1. Reddit ( https://www.reddit.com/r/spacex/comments/3y95y4/what_kind_of_embedded_systems_hardware_cpu_rtos/ )
2. Reddit ( https://www.reddit.com/r/spacex/comments/2y14y4/engineer_the_future_session_with_jinnah_hosein_vp/ )
3. Reddit AMA ( https://www.reddit.com/r/IAmA/comments/1853ap/we_are_spacex_software_engineers_we_launch/ )
4. StackXchange ( https://space.stackexchange.com/questions/9243/what-computer-and-software-is-used-by-the-falcon-9 )
5. Ycombinator news ( https://news.ycombinator.com/item?id=23368109 )
6. Aviation Week, Dragon’s „Radiation-Tolerant” Design, 2012-11-18
7. The space shuttle main engine controllers ( https://history.nasa.gov/computers/Ch4-7.html#:~:text=The%20computer%20chosen%20for%20the,a%20development%20environment%20was%20available. )
8. Test Harness ( http://en.wikipedia.org/wiki/Test_harness )
9. The Actor Model ( https://www.brianstorti.com/the-actor-model/ )
That’s a lot of brains…
off topic-ish…
Acelasi creier il va avea si asta mare. Deocamdata nici nu stie sa isi tina fluidele… ?
O lectură bună pentru sâmbătă dimineață. Mulțumim pentru articol, foarte bun.
Cofee time! Un fel de instersectie intre evenimentele actuale si tehnologii. Nice!
As fi curios sa aflu abordarea celor de la Boeing, si care ar fi diferentele majore, daca ai idee si chef.
La capitolul sarcinilor GNC poate ca ar intra si AFSS care asigura initierea autonoma a secventei de autodistrugere, lucru pe care din cate stiu doar SX il poate face. Dar poate revenim la asta in alt articol despre avantajele SX fata de altii 😉
Afara de calatoria „normala” (ascensiune si apoi reintrare), in cazul Crew Dragon, mai trebuie gestionat si profilul alternativ, in cazul aparitiei unei probleme care duce la anularea misiunii. Pentru aducerea in siguranta a echipajului sunt nu mai putin de 7 scenarii diferite, functie de momentul in zbor in care se petrece incidentul : de la maxq repetat inainte de validarea programului pana la aducerea lor in apele din jurul Irlandei (sau extremul abort to orbit) – vezi S.M.
Cred ca in acest moment SX lucreaza la GNC Starship; inginerii seniori (aia cu MIT si Cambridge ) au fost mutati de la F9/FH. Am gasit joburi cu o grila asemantoare cu cea din articol. Interesant sa aflii cat castiga un astfel de inginer:
https://lensa.com/gnc-engineer-starship-jobs/hawthorne/jd/c6813c4996b00325f6a097d212d94c22#salary
Chef am, idee am. Timp nu am.
Pe scurt, Starliner e un dezastru de proportii elefantine din punct de vedere al software-ului.
Trebuie să faci deosebirea între un microprocesor MPU și un microcontroler MCU.
Microcontrolerul MCU conține CPU (Central Processing Unit), memorie RAM, EEPROM, și posibil multe alte năzbâtii, circuitul de ceas, convertor digital analog ( pt sunet), controlere de magistrale seriale, și orice opțiuni mai dorește fabricantul să ofere într-un singur circuit integrat, utilizabile selectiv prin programare de către clienți/utilizatori. În acest caz frecvența de ceas a microcontrolerului e relativ mică (se mișcă mai greu), memoria de program este și ea relativ mică, nu poți scrie programe extrem de sofisticate, ci unele mai simple, scurte. Deci microcontrolerul este un fel de ”toate într-unul singur”, dar cu limitările de rigoare. Este util acolo unde utilizatorul vrea să-și scrie singur programul și să controleze cum vrea el microcontrolerul.
Microprocesorul conține doar CPU, și e utilizat acolo unde este nevoie de putere mai mare de calcul, necesitând circuite integrate dedicate separate, pentru fiecare funcție în parte. Are o frecvență de ceas mult superioară, memoria este externalizată, ai memorie mare RAM separată, ai memorie mare de progam separată, ai multe alte circuite integrate periferice dedicate separate pentru fiecare funcție dorită, și care prin intermediul magistralelor de date comunică cu microprocesorul.
Ideea ar fi că la un sistem complex ai microprocesor dedicat, iar microcontrolerul este pentru aplicații mici unde vrei să îngrămădești toate într-un singur cip, și eventual să faci ce vrei tu cu el prin programare.
O detaliere a acestui subiect
https://www.electronicshub.org/difference-between-microprocessor-and-microcontroller/
Adevarata teoria.
Dar granita dintre ele nu mai e atit de bine delimitata. Exista microcontrollere cu capacitate de procesare mai mare decit procesoarele din televizoare, cu frecvente de 500MHz sau mai mult, care pot folosi memorie DDR externa, cu conectivitate ethernet inclusa. Chiar si procesoarele x86 pot fi utilizate ca microcontrollere (ma refer la seriile cu consum redus si performante de neluat in seama pentru un sistem desktop), asta nemaivorbind ARM care sta exact pe granita.
Hey,
Definitia este prea complexa ca sa o putem descrie in cateva propozitii. Nu e gresit ca @Iulian a ales termenul de microcontroller in loc de microprocesor.
Diefrentele dintre microcontrollere, microprocesoare, si FPGA-uri, SOC-uri sau ASIC-uri sunt intradevăr foarte mari.
Si microprocesorul are o memorie DRAM (memoria cache), unele au implementate si VRM-uri (voltage regulating module), circuite GPU (graphic processing unit), controllere de memorie, iar altele dispun si de un FPGA auxiliat integrat pe aceeasi pastila de siliciu.
SOC-ul (system on a chip) este teoretic acel cip care imbina cele mai multe părți, dar in principiu tot o unitate de calcul bazata pe un microprocesor este.
Cred ca atentia ar trebui sa o concetram mai mult pe tipul de procesoare si arhitecturile folosite. In articol se spune despre arhitectura X86 (CISC), PowerPC (RISC) si ARM (RISC).
Toate aceste arhitecturi au softwareuri diferite căci sunt arhitecturi dferite.
Conteaza foarte mult suportul software pentru procesoare. Din cite am citit, se feresc sa ruleze pe metal si prefera sa scrie codul incit sa ruleze pe Linux. Microcontrollerele PowerPC (seria MPC5xxx de la NXP) suporta Linux AFAIK (https://www.nxp.com/design/software/embedded-software/linux-software-and-development-tools/bsps-for-power-architecture/bsps-for-power-architecture-technology-mpc5xxx:CW_BSP_PPC_5XXX).
Deci practic scrii codul si daca kernelul cu bibliotecile ruleaza pe arhitectura ta, si software-ul tau e portabil.
Intradevar linuxul poate rula pe toate arhitecturile mentionate mai sus. Dar de la a rula bine pana a ajunge „bug” free e cale lunga. De aia e mai cel mai bine (recomandat) ca fiecare ustensila cu software-ul ei dedicat, se cunosc reciproc si stiu care le sunt problemele.
Asta e si motivul pentru care unii prefera Apple, un singur ecosistem), o singura arhitectura + zeci de mii de revizii = crash free operating system, in timp ce la windows inca ii dai BSOD doar din programe, iar pe android e o lupta continua pentru „improvement”, o aplicatie poate avea probleme pe 2 telefoane diferite care au acelasi procesor dar o alta versiune de soft. ?
Utimul lucru pe care si l-ar dori ar fi un BSOD la primul sistem si un error bug la al doilea din cauza unei linii de cod uşor incompatibilă.
Asta nu inseamna ca sunt prosti, doar ca nu corespunde normei cu „ieftineala”. Arhitectura Power e scumpa, iar ca sa le faci pe toate sa mearga ceas e nevoie de multi programatori si multe simulari ori asta inseamna destui $$$.
Nu.
In primul rind, vorbim despre sisteme headless (adica fara monitor) si embedded. Ceea ce e alta liga fata de sistemele desktop.
Apoi, Linux are doua componente: kernelul Linux (dezvoltat initial de Linus Torvalds, acum un efort comun) si utilitarele si bibliotecile (dezvoltate de FSF sub umbrela lui Richard Stallman). Si de fapt numele lui real de buletin (al sistemului de operare) este GNU/Linux. SpaceX foloseste kernelul Linux cu citeva patch-uri (asa cum era de asteptat cel mai important este cel care aduce kernelul in lumea sistemelor de operare real-time/RTOS).
MacOS e consumer grade. Adica in categoria desktop. Asta sa nu spun hipster grade. Si nu are o singura arhitectura. Dar Apple are (avea e mai corect spus, nu mai stiu acum) hardware bun, cu drivere scrise ok. Nu are ce cauta in discutie decit pentru a spuns ca Apple erau unele din tastaturile pe care a fost scris codul. Ca si cum ar primi credit si soferul care l-a transportat pe Larry Page acasa si la scoala cu autobuzul scolii pentru faptul ca Larry Page a fondat Google.
Apoi sistemele de operare Linux pot avea timp de rulare continua de ani de zile, cu zeci si sute de miliarde de tranzactii efectuate (clienti serviti, cereri servite, etc). Un Windows 2000 Server redus la minimul necesar este aproape la fel de bun.
Linuxurile de la SpaceX sint diferite de Androizi, Ubuntu Desktop, Raspberry Pi. In sensul ca au kernelul, drivere pentru kernel scrise special pentru hardware custom de la bord, biblioteci minimale (UCLibc in locul GNU libc) dar compatibile cu cele de pe Linuxuri complete si binare minimale. Peste acest Linux minimal ruleaza software-ul SpaceX si atit. Fara UI, fara monitor, fara nimic altceva.
Cind crapa ceva… Pai, dupa cum se vede, au fost minimizate posibilitatile de eroare si poate fi cautata mult mai usor cauza: in hardware, in kernel, in biblioteci sau in software-ul propriu. Dar cum este un vehicul care trebuie sa functioneze, rezolvarea este statistica si probabilistica: probabilitatea a doua picari simultane este mult mai mica decit a uneia. Deci software-ul trebuie scris sa ia in calcul aceste situatii.
Apoi performanta. Vorbim de sisteme cunoscute, nu eterogene. Faptul ca ruleaza Linux inseamna ca la un eventual upgrade de hardware, software-ul va fi doar recompilat. Dar rularea unei aplicatii proprii pe un sistem fara display este diferita de sistemele care au o interfata grafica. In plus, hardware-ul este ales pentru a corespunde scenariului de folosire. Daca se adauga calcule noi, ajungem la priceperea programatorului care trebuie sa gaseasca solutia cea mai buna.
Arhitecturile, deci, in acest context, isi pierd relevanta.
Iulian, dezbaterea asta a plecat de la lectura mea „pe diagonala” a articolului tau. ?
Am inteles ulterior ca nu este cazul de interconectare multifuncționala arhitecturala sau back-up cu mai multe arhitecturi pentru aceeasi computing mission.
MacOS incepand din 2004 este optimizat pe o singura arhitectura: Intel X86/X86-64 fie ca vorbim de varianta pentru desktop sau laptop. Inainte de 2004 era pentru IBM Power (Power G3 si Power G4). Este intradevar consumer grade sau hipster grade daca preferi asa.
Exemplul desktopurilor era doar ca o comparatie mai simpla si mai cunoscuta de majoritatea. Multi stiu sa faca diferenta intre stabilitatea unui Mac si „diversitatea” unui windows. Putem la fel de bine sa luam ecemplul mainframurilor IBM care ruleaza de asemenea fară monitor.
Linuxul este intradevar un OS bun, dar la uptime nu intrece un AIX dedicat pentru IBM mainframes (arhitectura Power).
https://www.ibm.com/it-infrastructure/power/os/aix
„IBM Power Systems™ running AIX 7.2 have the lowest percentage of unplanned annual server downtime and best-in-class reliability.”
Comparatia este facuta incluzând si IBM mainframes care ruleaza Linux. Practic un AIX este mai optimizat pentru arhitectura Power decat orice alta aromă de Linux.
Asta e unul din principalele motive pentru care sistemele si softwareul IBM, desi extrem de scumpe, incă isi au locul lor pe piață. Prin anii 2000 HPC-ul era dominat printr-o majoritate absoluta de RISC-uri, apoi de prin 2004 le-au luat locul X86 (Xeon) dar totusi au ramas RISC-urile acolo unde este nevoie de avabilitate extremă.
Din 2004 Intel a scos o multime de generatii. Arhitectura e x86, dar daca pastrezi doar subsetul de instructiuni 386 pentru a pastra compatibilitatea nu ai facut nimic. E familia x86, dar diferentele intre generatii sint majore. Practic fiecare generatie vine cu elemente noi. Iar Windows-urile cu radacini in Windows server au fost si sunt stabile (XP, Vista, 10) ca desktop. CU un plus pentru 10 fata de celelalte.
Mere cu pere. Unul e enterprise altul e multi purpose server. AIX nu sint conectate direct la internet din cite stiu; linuxurile sint, daca vrei, coloana vertebrala a internetului. Deci sint mai multe aspecte:
– actualizari cu reboot (la kernel de exemplu) – scheduled maintenance
– ceea ce ai dat tu in link – uncheduled maintenance, care poate depinde de hardware (chinezarie de container vs servere recunoscute fara probleme) sau software
– talentul si experienta inginerului de sistem Linux de a alege si instala exact configuratia hardware+software care sa raspunda cerintelor si care sa aiba cit mai putine probleme
– necesitatea de a face upgrade hardware – lumea internetului e mai dinamica decit a unei banci
Exista linuxuri care ruleaza de minim 5-6 ani.
De acord ca Linuxul este mai raspandit si funtioneaza mai bine pe IoT, dar asta e alta discutie.
Eu ma refer la un anume task sau o serie limitata de taskuri unde avabilitatea si functionalitatea fara probleme surclaseaza nevoia de inercinectare.
Intel face ce face si tot implementeaza la nivel hardware seturi de instructiuni noi (FMA, AVX, AVX512, etc). CISC-urile au evoluat foarte mult ca si complexitate pentru a obtine anumite avantaje (accelerare) in anumite aplicatii. Doar ca multe revizii hardware necesita si multe revizii software pentru a lucra in armonie, ai facut revizie la hardware iar softwareul l-ai lasat pe tarla, ai glitchuri.
RISC-ul in schimb se bazeaza mai mult pe un software cat mai avansat pentru a obtine o eficienta cat mai sporită, dar si arhitectura asta a avansat foarte mult.
Avantaje si dezavantaje la ambele.
„lumea internetului e mai dinamica decit a unei banci”
De acord, diferenta e ca omu’ poate sta 5 minute fara p0rnake dar tranzactiile bancare trebuie sa meargă ceas, altfel totul se transforma in haos. ?
Daca bagi IOT in discutie ajungem si la prune, dupa mere si pere.
The rise of Linux mirrors the rise of the web, which just happens to have started around the same time. It’s hard to pin down exactly how popular Linux is on the web, but according to a study by W3Techs, Unix and Unix-like operating systems power about 67 percent of all web servers. At least half of those run Linux—and probably the vast majority.
Even Microsoft, once the sworn enemy of Linux, has embraced this open source OS. In 2012, the company announced that it would let companies run Linux on its cloud computing service, Microsoft Azure. About one third of Azure instances are now running Linux instead of Windows. And Microsoft itself is using Linux for some of the networking tech behind the scenes of Azure. In fact, Linux is so crucial to web development that Microsoft partnered with Linux vendor Canonical to make it easier for programmers to build Linux applications on their Windows laptops.
Tocmai faptul ca disponibilitatea este foarte buna a fost unul din avantajele Linux. Cind spun Linux nu ma refer la Android. Features ale procesoarelor Intel sint introduse in kernel ( https://software.intel.com/content/www/us/en/develop/blogs/does-software-actually-use-new-instruction-sets.html ). Vezi ca servicii de stocare si virtualizare enterprise de la IBM (la care se conecteaza AIX), sisteme de stocare multi-tier de zeci de peta ruleaza pe … Linux.
Iulian, poate ar fi trebuit sa incepi de la celalat capat al sistemelor: traductorii si transmiterii (transducers & transmitters) care vor converti anumite marimi fizice in altele, si in semnale electrice (digitale sau analoge) care sunt preluate de catre cardurile I/O si controlere
Multitudinea de cabluri (wiring) de la transmiteri catre cardurile I/O, adauga greutate (si alte dezavantaje: posibilitatea de interfenrenta, de a se defecta in timpul utilizarii, etc), astfel incat intotdeuana se cauta ca acest traseu al cablurilor sa fie cat ma scurt. De aceea un sub-sistem are propriile controlere (care este posibil sa aiba propriile intrari si iersiri analogice si/sau digitale; porturi pt comunicatii seriale cu celelate controller si/sau transmittere, si cu celelalte unitati de calcul, sursa proprie de alimnetare de backup – baterie) care ele insele sunt capabile sa gestioneze acele sub-systeme in mod independent (pot realize controlul unor bucle PID, pot rula aplicatii pt control logic si pot realiaze calcule matematice) comunicand insa datele primate de la transmitere si primind comenzile de la calculatoarele care gestioneaza intreg sistemul
Exemplul concret pe care l-ai dat (controlerul motoarelor navetei spatial) gestioneaza singur functionarea in bucla inchisa (closed loop) a unui motor (primeste informatiile de la transmiterele de temperatura, presiune, debit, etc) si functie de aceste date si de regimul prestabilit pt functionarea motorului, controleaza electroventile, actuatori pneumatici si/sau electrici, modul de functionare a turbopompelor, etc)
iat, nici eu nu sunt foarte multumit de rezultat din mai multe motive – e prea abrupt, l-am scris in conditii improprii (migrene), oarecum m-am fortat sa aiba logica ceea ce scriu, subiectul e extrem de vast dpdv al aspectelor twhnice si imi e greu sa imi dau seama de la ce punct scrierea devine un somnifer bun. L-am publicat pentru ca daca nu o faceam ajungea la zece revizii (e a doua ceea ce ai citkt) si eram mustrat in redactie pentru numarul de ciorne nefinalizate.
Da, ai dreptate, cred ca era o abordare mai buna sa plec de la sistemele controlate si monitorizate.
Pe linga avantajul spus de tine – controllerul dedicat motorului – un al doilea avantaj este cel dat de separarea sistemelor. In felul acesta complexitatea codului care ruleaza intr-un punct scade si creste posibilitatea de reutilizare a sa.
Repet, articolul e super, e e-learning
Nu stiam 90% din ce ai scris
Am citit ceva asemanator doar pe wired
Am căutat un pic, se pare că Curtiss-Wright este producătorul pentru sistemul de achiziție a datelor. Sistemul se numește Acra KAM-500, în diferite variante. Informații mai detaliate în pdf
https://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/20170002208.pdf
Informații mai detaliate despre Acra KAM-500 nu am găsit decât în pdf-ul ăsta produs la un seminar din 2012 ținut la Moscova, e parte în engleză parte în rusă
http://www.emtltd.com/pdf/KAM-500.pdf
Acra KAM-500 are o multitudine de module pentru magistrala de date serială ”serial bus”, printre care standardul militar MIL-STD-1553 , standardul obișnuit automotive CAN, sau din aviație ARINC-664, ARINC 429, în pdf-ul de mai sus, dar și pe site-ul producătorului
https://www.curtisswrightds.com/products/flight-test/data-acquisition/acrakam500/modules/bus-monitors/
foarte interesante informatiile. ty
In facultate invatam de eventualele avantaje pe care le-ar putea aduce sistemele computerizate. Pe atunci se credea ca viitorul va fi in sisteme pneumatice, deci un fel de calculatoare actionate cu aer, ar fi fost mult mai fiabile si mai putin influentate de temperatura, presiune etc. Pe vremea aia electronica era inca f sensibila.
Si astazi, atit la avioane, cit si la masini electrice se-ncearca climatizarea compartimentelor electronice.
Tin sa spun ca stiu extrem de putin de acest subiect, dar cred ca cele mai importante parti din sistem sunt senzorii care emit informatiile respective. Cele mai multe greutati au fost legate de senszori si mai putin d eunitiatile de prelucrare a informatiilor.
Senzorii – cel putin in cazul rachetelor – sunt maturi; s-a trecut la o noua generatie intre 95-05. Puterea de procesare trebuie sa tina pasul cu cantitatea de date culese (cresterea frecventei de esantionare a fost de la zeci sau sute de Hz la zeci si sute de kHz. Schimbarile in UI, avansul comunicatiilor, dorinta de a integra sistemele intr-un sistem complex au crescut mai departe nevoia de performanta.
Apoi exista alegerea care trebuie facuta: sisteme rezistente la radiatie sau COTS? Daca raspunsul este COTS atunci este nevoie de foarte multa creativitate pentru a avea un sistem care sa fie fiabil (Boeing a demonstrat cit de dificil este).
Vorbind despre dezvoltatori, SpaceX a declarat in mai multe ocazii ca prefera progrmatorii care au dezvoltat jocuri deoarece sint preocupati sa extraga cit mai multa performanta din hardware, la scrierea jocurilor existind constringeri de performanta. Dezvoltatorii care au experienta in domeniul aerospatial nu sunt suficient de flexibili iar dezvoltatorii standard sunt ‘lenesi’, fiind obisnuiti cu cresterea continua a performantei si memoriei disponibile.
La final este nevoie ca toti algoritmii implementati in toate sistemele sa functioneze impreuna, fara probleme, de fiecare data. Ceea ce face scrierea a 2 milioane de linii de cod o provocare majora.
Si la rachete sunt preferati actuatorii pneumatici (elementul de comanda nu este aerul comprimat, ci gaze inerte): sunt mai usori decat actuatorii electrici si elimna cablajul (wiring-ul) de la sursa de current pa la actuator (o butelie cu gaz inert sub presiune poate fi amplasata mai aproape de actuator)
Totusi transmiterele din ziua de azi (senzorii) sunt mult mai mici, pot utilize doar 2 fire (pe aceleasi fire se asigura ata alimentarea cu current cat si transmiterea semnalului), folosind anumite protocoale (exemplu HART) se pot transmite mai multe variabile (acelasi transmitter de presiune diferentiala pota transmite si presiunea statica, debitul; acelasi transmiter de debit poate transmite si densitatea, etc)
Una din problemele majore sunt conditiile in care opereaza acesti transmiter (senzori): conditii de temperature si vibratii (de unde si radiator pt a dispipa caldura, sau heat tracing pt ai tine la temperaturi positive)
Un exemplu clasic sunt debitmetrele utilizate la motoarele rachetelor Saturn. La acea vreme erau folosite contoare cu turbine pt masurarea lichidelor (carburant si oxidant). Contoarele cu turbine sunt utilizate pe scara larga si astazi pt masurarea fluidelor , principiul fiind acelasi: fluidul de lucru (gas sau lichid) invarteste o turbine, la fiecare 1, 10, 100, 1000 de rotatie ale turbinei se transmite un semanal (puls fie in frecventa inalta fie in frecventa joasa, pt siguranta ambele si HF si LF). In timpul lansarii, frecventa anumitor sunete din interiorul rachetei interfera cu frecventele utilizare pt generarea de impulsuri. Solutia de atunci: filtre si amplificarea semnalelor filtrate (care erau la randul lor niste echipamente mari si geoaie). In ziua de astazi sunt utilizate contoare care dau direct debitul masic, nu cel volumetric (densitatea fluidelor se schimba, mai ales ca unele sunt utilizate pt racirea motorulu sau ajutajului)
Ca nota de subsol, actuatorii de la motoarele Merlin folosesc combustibilul RP-1.
da, e vorba de actuatorii pt trust vector control vector, insa acestia functioneaza cu motorul odata pronit (adica fluidul de lucru in acest caz kerosenu, iese din rezervor, trece prin niste valve care erau anterior actionate pneumatic pt ai permite sa ajunga la actuatorii hidraulici)
aceste valve / robineti actionati penumatic sunt deobicei Main Fuel Valve (MFV), Main Oxidizer Valve (MOV), Gas Generator Fuel Valve (GGFV), Gas Generator Oxidizer Valve (GGOV), Oxidizer Turbine Bypass Valve (OTBV)
aici un test pt actuatorii hidraulici ai monturii stabilizatorilor cardanici (crd=ed ca gimbal pot traduce ca si cardan): https://www.youtube.com/watch?v=i2gU4CVDV6Y
Da, motorul trebuie sa fie pornit – AFAIK circuitul hidraulic preia RP-1 dupa turbina care impinge combustibil catre camera de ardere.
La prima treapta doar motorul central are TVC, celelalte sunt fixe.
Bun articol de citit dupa munca ca de azi a trebuit sa fiu prezent la munca….
Ca tot era vorba de rachete si tot sa pomenit si de motoare… https://www.youtube.com/watch?v=LbH1ZDImaI8
Discutii de genul asta sint ca cele despre cine bate – Bruce Lee sau Van Damme sau Chuck Norris. 🙂
In plus, nu stim despre el la fel de multe ca despre Merlin pentru a avea verdicte absolute.
Senior Software Engineer (Embedded Linux Software)
$88K-$149K
As a flight software engineer on the Embedded Linux Software team, you will be designing, developing, and testing software that is used to launch and operate SpaceX flight systems. You will engage with other SpaceX engineers to discover the needs of the mission and code highly reliable software that turns the mission into a reality. You will be responsible for the complete life-cycle of the software you create.
Aerospace experience is not required to be successful here – rather we look for smart, motivated, collaborative engineers who love solving problems and want to make an impact on a super inspiring mission
RESPONSIBILITIES:
– Develop highly reliable and available software systems
– Board bring-up of next-generation avionics computers
– Develop prototypes to prove out key design concepts and quantify technical constraints
– Write high quality structured bare metal and Linux-based software for embedded processors (e.g. ARM, PowerPC, x86, etc.)
BASIC QUALIFICATIONS:
– Bachelor’s degree in computer science, engineering, math, or science discipline and 4+ years of experience in systems-level C (kernels, device drivers, hypervisors) OR 6+ years of experience in systems-level C (kernels, device drivers, hypervisors)
PREFERRED SKILLS AND EXPERIENCE:
– Experience writing Linux kernel code for real-time systems
– Fluency in POSIX shell script and Python
– Have shipped embedded software in high volume products or real-time products that require high reliability and fault tolerance
– Significant understanding of embedded software principles and ability to contribute in design sessions
– Thorough knowledge of systems, computer architecture, software development, networks, and electronics
– Strong skills in debugging, performance optimization and unit testing
– Effective collaboration as a team member and in large code bases
– Creative approach to problem solving and exceptional analytical skills
– Ability to work effectively in a dynamic environment with changing needs and requirements
– Ability to work independently and in a team, take initiative, and communicate effectively
ADDITIONAL REQUIREMENTS:
– Willing to work extended hours and weekends when needed
Asaaa…
Articol misto si ai reusit sa-l faci de cacao cu un singur cuvant. E o performanta
E o performanta mult mai mare sa se faca de cacao constant si sa fie scosi basma curata de fiecare data. Constatarea realitatii a fost tradusa intr-o metafora.
Iulian, inteleg ca ai o problema cu asta. Get the f over it. Grow up. SpaceX e subiectul
Hmm… chestii nu chiar obisnuite pt rachete dar normale in aviatie civila (tripla redundanta spre exemplu).
Are sens daca ne gandim ca scopul este operatiuni cat mai similare cu aviatia civila. Putin surprins de cat de moderne sunt toate, de obicei ce zboara pe racheta e cu o generatie in urma a ce folosesc pustii pentru Pornhub :)))
Fain articol!
PS: Vazand ce ocupat esti, poate nu ar mai trebui sa mai trimit cv, ca te-ncurc… sau macar sa o organizez mai ca lumea si mai… publicabil, sa va mai scutesc. Numai ca nu prea stiu ce ar trebui….
Nu atit de ocupat incit sa nu ma bucur de un text bun. 🙂
Iti trimit un mail miine si poti raspunde la el. Nu a ajuns la adresa noastra mailul tau, deci va trebui sa imi trimiti scrierea ca raspuns. E posibil sa ai deja un mail de la mine de ceva vreme.
Hmm…nu am primit un mail inca.
Trimit scrierea daca-i nevoie, nu-i bai, numai sa stiu unde 🙂 .
Cicat de client de mail… Zice sending si uita sa trimita…
Edit: check mail.
Right back at ya!
chestii nu chiar obisnuite pt rachete dar normale in aviatie civila (tripla redundanta spre exemplu).
Tell me more about that…
O intimplare fericita ne aduce mai multe informatii. AMA pe Reddit cu SpaceX. Puteti citi cele 7000 de comentarii. Sau, la cerere, o parte a doua a acestui articol. Multumesc MariusB pentru link.
https://www.reddit.com/r/spacex/comments/gxb7j1/we_are_the_spacex_software_team_ask_us_anything/
We’re a few of the SpaceX team members who helped develop and deploy software that flew Dragon and powered the touchscreen displays on our human spaceflight demonstration mission (aka Crew Demo-2). Now that Bob and Doug are on board the International Space Station and Dragon is in a quiescent state, we are here to answer any questions you might have about Dragon, software and working at SpaceX.
We are:
Jeff Dexter – I run Flight Software and Cybersecurity at SpaceX
Josh Sulkin – I am the software design lead for Crew Dragon
Wendy Shimata – I manage the Dragon software team and worked fault tolerance and safety on Dragon
John Dietrick – I lead the software development effort for Demo-2
Sofian Hnaide – I worked on the Crew Displays software for Demo-2
Matt Monson – I used to work on Dragon, and now lead Starlink software
Btw cand ajungem pe Luna macar?
– NASA in 2024 sau 2030. Depinde de urmatorul presedinte al US.
– NASA pe orbita Lunii cu Orion, depinde de finantarea SLS. 2 mld costa o pansare parca.
– SpaceX pe orbita Lunii cu privati poate ajunge dupa 2022. Trebuie sa faca niste adaptari FH sau sa termine Spaceship.
Eu unul mizez pe Spacex sau alta masinarie lansata cu Falcon Heavy. Deja FH permite lansarea la costuri decente.
Daca combo-ul Starship + SuperHeavy se va dovedi functional, expeditiile lunare vor fi cam ca transportul pana la ISS in momentul de fatza. Adica treaba de rutina.
Daca nu, tot sunt posibile cu lansare FH + F9. Cumva tot programul ala Artemis e un fel de opereta redundanta. Falcon Heavy+Falcon 9 ar putea gestiona treaba de lansare in spatiu. Daca nu intervine vreo catastrofa geopolitica, probabil 2022 sau 2023 va fi anul intoarcerii pe Luna intr-un fel sau altul.
2021 ar trebui sa fie si anul Blue Origin. Mult mai secretosi decat SpaceX dar cu pedigree convingator.
SLS exista ca program social. Cat o mai exista.
Pentru excursie cu FH in jurul Lunii ar trebui ca portbagajul sa fie inlocuit cu un Service Module; treapta a doua a F9 (a treia a FH) cred ca i-ar putea pune pe orbita Lunii (nu am calculat, trebuie sa verific ipoteza).
FH cu fairing extins si in configuratie „de sacrificiu” duce masinariile (service module/command module + lander) – pe LEO. F9 duce echipajul si poate ceva combustibil suplimentar (tot vor ei sa exerseze realinentarea pe orbita pt Starship pt Marte).
Sau, ca sa fie si mai sigura povestea, FH duce pe LEO landerul, F-9 duce modulul de comanda/serviciu iar un F-9+Dragon duce echipajul. E o ipoteza in care ar putea fi recuperate toate boosterele. Se intalneste toata lumea pe orbita si de acolo pleaca veseli spre Luna.
La intoarcere, Dragonul care i-a dus pe LEO ii asteapta tot acolo si se intorc pe Pamant. Modulul de comanda&serviciu teoretic poate astepta pe LEO pt. o noua misiune.
Ideea e ca tehnologia exista…lucrurile sunt destul de COTS, nu e cine stie ce epopee.
Dragonul actual a fost facut si pentru calatorii Pamint-Luna. Adica, in functie de misiune am avea:
– o traiectorie a la Apollo 8 probabil poate fi realizata cu un FH reutilizabil, o treapta 3 standard si o capsula+modul de serviciu. Asta e varianta concediu in jurul lunii, cu 3-4 pasageri.
– FH care sa ridice agregate lunare, F9 cu Dragonul si modulul de serviciu, rendez-vous pe orbita, apoi calatorie a la Apollo 11, cu treapta 3 trimitind agregatul in jurul Lunii.
Lipseste un modul de serviciu pentru Dragon si landerul lunar. Realizabile in 2-3 ani.
Cred c-ati vazut amandoi The Martian. Macar aia din Holywood sunt creativi
Martian e extrem de realist. Multe din aspectele de acolo sint desprinse din cercetari actuale.
the martian e facut cu ajutorul nasa
https://www.csmonitor.com/Science/Science-Notebook/2015/0906/NASA-and-The-Martian-partner-to-make-space-cool-and-accurate
Starship e cu totul altceva. Pana acum SpaceX a mizat pe tehnologii mature, si verificate (cele in materie de motoare si combustibil), a putut sa utilizeze echipamente off the shelf. La Starship, are un combustibil nemaiutilizat, asa incat cred ca rezultatele nu vor venii atat de usor si atat de repede (nu ca nu mi-as dorii). Vor trebuii sa lanseze o multime de Falcon ca sa poata sustine dezvoltarea Starship
Ideea lui Musk (cel putin initiala; se poate schimba) era de a sustine dezvoltarea Starship din StarLink.
Asa ca modificari observ ca acum 2 ani a devenit brusc curajos cu Starship, accelerand dezvoltarea. Asta imi sugereaza ca banii din lansari erau mai mult decat preconiza (astfel nevoia de StarLink parea ca se diminuase nitel; bine, cel putin pana au inceput sa bubuie prototipurile…). De asemenea, imi sugereaza ca programul pentru Raptor era de mare succes (vreo 70 din constul final al unui sistem de lansare e in motoare; e la fel si la avioane, motorul e inima draciei; toate sistemele de lansare sunt caracterizate prin motoarele lor).
As avea niste choice words pt rusi si americani in legatura cu felul in care-si aleg combustibilii 🙂 . Metanul a stat in dulap decenii, desi era mult mai user friendly, dar nah… cand cursa spatiala e practic o intrecere de masurat prajini, lucrurile normale dpdv ingineresc incep a fi date deoparte.
„vreo 70 din constul final al unui sistem de lansare e in motoare”
Cred ca mai putin de atat. Mai degraba prima treapta 50%-60% din racheta, iar din prima treapta motoarele probabil undeva la 66%.Motorul pentru a doua treapta are un procent mic (cred eu ).
Metanul are si dezavantaje care l-au tinut pe bara o perioada . Caldura specifica si punctul de fierbere printre altele (vsRP!),
Si”performanta”/eficienta (impulsul specific) fata de hidrogen.
Nu e user friendly in comparatie cu kerosenul (mai ales nu e „storage friendly”, desi este mai user friendly daca mergi pe gaz-gaz, cand si daca se va intampla), dar este mai prietenos fata de H (cam peste tot, mai ales la volum-pastrare).
Aici poate Iulian sa fie mai concis.
https://www.rumaniamilitary.ro/tehnologii-episodul-6-propulsia-rachetelor-motorul-elemente-de-baza
Ar fi culmea sa ajunga indienii primii
Daca se continua in ritmul anilor 60 cred ca puneau pana acum si steagul pe Marte. Comenta la articolul cu avioane cu decolare verticala Neamtu Tiganu ca in anii 70 se faceau proiecte serioase. Are dreptate
@vlad. N-aveau cum sa continue in ritmul anilor ’60.
Rachetele s-au dezvoltat atat de repede in anii ’50-’60 pt ca tehnologiile „pe orizontala” existau in buna masura, trebuiau doar puse lucrurile cap la cap.
La fel ca aviatia cu piston in anii 20-40. Sau microprocesoarele in anii ’80-2000. Chestia aia cu Marte din anii ’70 era o utopie. Abia in zilele noastre avem cu chiu cu vai tehnologia sa ajungem pe Marte. A ajunge pe Marte e cu cel putin doua ordine de marime (daca nu trei) mai greu decat a ajunge pe Luna. In termeni de resurse, tehnologie, conditionari biollogice, samd. „Promisiunile” anilor ’70 nu erau serioase ci nerealiste. Aveau ideile dar n-aveau tehnologia. La fel ca si bombardierul lui Sanger din anii ’30. Daca pentru Luna tehnologia e destul de stapanita in zilele noastre, pt. Marte e cam pe muchie de cutit…cam cum a fost Luna in anii ’60-’70.
Stiu ca Musk nu agreeaza ideea dar pt. Marte probabil c-ar trebui luata f. in serios propulsia nucleara. Daca Starship si New Glenn vor deveni realitate, costurile de trimitere pe LEO vor scadea dramatic iar sarcinile utile de la 50 de tone in plus pe LEO vor deveni banalitate si probabil propulsia nucleara va fi de luat in considerare.
Tu ai vazut ce buget are NASA? Nu cred ca mai e interes
Mhmm…. da si nu.
NASA e o organizatie politica, si desi bugetul PARE ok, multe dintre acele resurse sunt bagate in programe cu iz usor electoralist. Facilitati sunt tinute deschise si well staffed, desi nu prea au de lucru, pet-programs sunt finantate desi nu prea au obiect, etc
Tind sa cred ca ocazional ajung la oameni tipi mai aventurosi, dar au un buget f restrans pt a face treaba de fapt. Daca taie din Michioud, se supara senatorul de Louisiana, daca taie de nush unde, se supara Boeing, etc. Aiureli.
https://en.wikipedia.org/wiki/Budget_of_NASA
Also, bugetul procentual e mult mai putin decat era o data. Acu e pe la 0.5 la suta. Si tine cont de ce spun mai sus.
Acuma, pe vremea lui von Braun, planul era:
1) misiuni umane pe Luna – anii 70.
2) misiuni umane pe Marte + baza pe Luna – anii 80
3) baza pe Marte + baza pe Luna – anii 90
Evident, muuult prea optimist. Apollo a fost un program de forta bruta, nascut cumva din disperare. Bugetul, resursele, totul era la limita. Nu putea fi continuat in acelasi mod. Ca sa-l citez pe Alex: „vise mari, chiloti mici”.
Mai exact, misiunile pe Marte urmau sa foloseasca niste tehnologii inca destul de noi, in conditiile in care… nu prea stiam nimic de Marte. Viking a ajuns pe Marte in 1975, la trei ani de la ultimul Apollo. (Mars 3 in 71, dar a dat fail 🙂 ).
Nu stiam nimic de circuite biologice inchise, nimic despre stat in zero-G mult timp, nimic despre sol, atmosfera, Zubrin era la liceu asa ca nema ISRU… Pnm, una e o misiune de 2 ani, alta e o saptamana ca la Apollo.
Ca anecdota, in 73 bajetii de la NASA planuisera o misiune fly-by al lui Venus (parte din Apollo Applications Programme). Nu s-a efectuat, si spre surprinderea lor, in 74, cat timp astronautii s-ar fi aflat in drum spre Venus, am fost pocniti de prima furtuna solara majora 🙂 . Daca aveai astronauti in afara magnetosferei (Venus, Pamant, Marte), erau prajiti. Literalmente. Nu existau observatoare solare la vremea aia… nici infrastructura de telecom la distantele alea….
Cel mai devreme am fi putut ajunge pe Marte folosind infrastructura din DRM 1 (poreclita Mars-Semi-Direct). Adica cu un crash-programe incepand din 1996, si terminand prin 2004-2006. Problema e ca la vremea aia, NASA era legata de viciul tehnologic denumit STS, si legata politic de statia spatiala Freedom (care era in curs de a se transforma in ISS). Nu avea sistem de heavy-lift. Si erau deja prea politzati dupa 20 de ani de invartit in cerc.
Iar scrisei de 10 ori cat mi-am propus….
@Iulian. Am reusit sa citesc tot articolul, ai depus o munca colosala ca sa aduni tot ghiveciul asta de informatii. ?
Totusi mie nu imi iese ceva. Nu inteleg de ce au ales sa foloseasca 3 arhitecturi diferite, bazate de 3 tipuri de software diferit. Motivatia cu „redundanța” nu o consider un argument bine inchegat deoarece dpdv al tehnologiei exista alte solutii mai simple pentru a obtine aceleasi rezultate. La fel nici motivatia cu rezistenta la radiatii nu o pot vedea ca un argument din cauza faptului ca si acolo ar exista alte solutii.
Daca informatiile astea sunt adevarate atunci inseamna ca au ales sa se scarpine la urechea stangă cu mâna dreapta, vorbind dpdv al programatorului.
Se pare ca nu am fost sufixient de clar in exprimare. 🙂
Un task (ex GNC, control motoare, etc) se face de un ansamblu de trei sisteme. Toate cele trei sisteme sint identice (aceeasi arhitectura si acelasi mod de functionare) si sint 3 din motive de redundanta.
@AlexIS: este esential sa faci diferenta intre redundanta si backup! Redundanta un sistem identic cu cel de baza (primul da kix, al doilea, similar intra in funnctiune), pe cand un sistem de backup se bazeaza pe alte principii (daca sistemul de baza este afectat de anumite conditii, cel de backpup, bazandu-se pe alte principii, nu este afectata de acestea avand sansa de a furniza rezultate corecte). Exemplu: daca am un contor cu turbina sa masor debitul, sistemul redundant este inca un contor cu turbina (primul se defecteaza, al doilea intra in fucntiune). atat doar ca uin contor cu turbina functioneaza corect pana la viteze de max 20 m/s a fluidului de lucru. Backup: un contor cu ultrasuntee, sau vortex, ori ,mass meter, (se bazeaza pe alt principiu de masurare astfel incat, daca viteza fluidului depaseste 20 m/s, masurarea nu este afectata)
@Iulian, ai fost suficient in exprimare, citisem eu putin pe diagonală. (eroare 0x007 ??)
@Iat, e foarte corect ce spui dpdv mecanic, dar in domeniul IT-ului sa ai un back-up perfect functional este mai recomandat decat sa dispui de un alt hardware + software care sa faca aceeasi treaba. Software-ul trebuie sa lucreze perfect cu hardware-ul ca impreuna sa poata citi si executa corect instructiunile. Orice semn/bit/formula care nu se pliaza cu software si hardware-ul poate da crash la sistem. Si atunci e nasol.
De aceea la servere/datacenter solutia de redundanta este sinonima cu cea de back-up, aceeasi arhitectura/SO.
E foarte posibil ca in spatiu, datorita radiatiilor, electronicele sa mai dea erori. Dar asta se poate rezolva ori printr-un hardware dedicat rezistent la radiatii ori prin ecranarea corespunzatoare a componentelor sistemelor de calcul (eg imersie in ulei antiradiatie, ermetizarea intr-o carcasa antiradiatie, etc).
Daca ar fi dupa mine as alege sa introduc un sistem intr-o carcasa antiradiatie plina cu ulei antiradiatie. Si impusc 3 iepuri dintr-o lovitura, adica am rezolvat-o si cu radiatia, am si racire buna (uleiul) si ma pot baza pe un software/hardware excelent, crash free.
E misto scena cu tipul ala care gaseste solutia
Si cu cartofii :D. Si cu banda izolier. Mai e un film fain cu o simulare de excursie pe Marte. S-a si facut un experiment
Mars, doua sezoane, NatGeo.
Cand trimitem si noi un satelit? Cu o racheta proprie.
Satelit RoSA cu racheta ARCA.???
Trimis cu balonu. Nu stiu cat e recordu de alritudine la noi probabil e cu scud sau volkov. Cred ca si sa-2 poate fi adaptata sa duca
Era o cercetare la Poli pentru S-75 parca. Dar trebuie modificata major. In plus, nu prea avem de unde sa lansam, decit daca invadam Galapagos sau Capul Verde sau Ascension. Bine, am putea face o lansare din zbor a la Orbital ATK, punind Volhov sub un RomBAC.
Pai si germanii nemti cum lansau?
La Peenemunde, cind nemtii contau. ?
E nevoie de spatiu cu riscuri juridice mici spre est. De preferat cit mai aproape de Ecuator.
Cam cum faceau ceilalti nemti (de fapt tot aia) de la OTRAG. Ce dream team mai erau si aia…rachete extrem de ieftine + tara africana + dictator cu ambitii = ce poa’ sa iasa nasol?
Mi-a placut, pentru mine au fost informatii noi, de care nu stiam.
High winds.
Stop.
Officer, speed is relative…
C’mon, do space stuff! A doua oara cu noroc.
1. Inca un sereleu capabil sa faca ICBM-uri.
2. Astia sunt ce trebuia sa fie ARCA „noastra”, nu? Vai, mi se incetoseaza privirea…sniff, sniff…Aaa…am uitat, aia fac acum rachete nepoluante pe baza de apa.
Dupa lansarea dragonului se pare va vom avea o luna foarte aglomerata pentru Space X, probabil cu 4 lansari:
– la inceputul lunii am avut Starlink 7;
– azi am avt Starlink 8. Lansarea perfecta, vreme frumoasa (si niste super poze pe net) prima treapta (folosita de 3 ori) a aterizat pe OfCourseIStillLoveYou. Semicarenele au fost si ele refolosite (dar provin din misiuni anterioare diferite) si au aparut poze cu motoarele carenelor folosite pentru reintrare. 58 de sateliti starlilnk si alti 3 Planet. De remarcat:
* cei 3 sateliti Planet semnaleaza debutul programului „ridesharing” al SpaceX prin care ofera catre companii mai mici spatiu in lansari deja programate. Daca pretul era avantajos pana acum, de aici inainte va fi si mai si. Probabil ridesharingul va pune presiune si mai mare pe concurenta;nu e ceva nou. o mai faceau si altii si din cate stiu era specialitatea europenilor,
* cu lansarea de azi sunt in jur de 500 de starlinci. Pe la 840 va porni functionarea retelei. Pentru teste ceva mai devreme, probabil peste cateva luni (august?). Deja a aparut site-ul pentru doritorii nerabdatori:
https://www.starlink.com
Lansarea aici:
https://www.youtube.com/watch?v=8riKQXChPGg
Mai nou avem streaming si pentru audio – mission ctrl:
https://www.youtube.com/watch?v=HamCYaX8WiU&feature=emb_logo
Pentru SX urmeaza tot luna asta:
– lansare F9 pentru armata: satelit GPS (block III);
– lansare F9 Starlink 9;
Tot luna asta vom avea reintoarcerea Vega dupa un an de pauza (de la rezastrul din 2019) cu o lansare test si validare pentru sistemul destinat microsatelitilor – deci tot rideshareing – al ESA, Ramane sa le tinem pumnii celor de la ArianeS. Posibil sa mai vedem inca o lansare Elctron pentru USAF.