211service.com
Konstruere fremtidens mobilitet
I samarbeid med Siemens Digital Industries-programvare
Fra biler til fly, fremtiden for transport er allerede her – og endrer seg raskt. Software engineering er stadig mer sentral både i utvikling og vedlikehold av alle typer kjøretøy. Det betyr at flere mennesker må begynne å tenke som systemingeniører. Dale Tutt, visepresident for romfart og forsvarsindustri for Siemens Software, sier at dette betyr at selskaper må tilby mer opplæring og planlegging for de som designer og utvikler fremtidens kjøretøy.
Når du prøver å løse talentgapet, er det mye du kan gjøre for å gjøre verktøyene enklere å bruke. Ved å integrere verktøyene bedre og ved å bringe inn teknologier som AI for å automatisere genereringen av forskjellige designkonsepter og analysen av disse konseptene ved hjelp av simuleringsverktøy, kan du utvide funksjonene til systemet slik at det bidrar til å styrke ingeniørene dine, sier Tutt.
Bedrifter som er de mest suksessrike med å ta i bruk systemteknikk, gjør det fordi systemteknikk og verktøyene som brukes, blir nesten som DNA-et til deres ingeniørorganisasjon. Alle begynner å tenke litt som en systemingeniør, selv i sin vanlige jobb. Verktøyene og økosystemet du bruker for å gjøre systemutvikling har en stor rolle i å lette adopsjon.
Nand Kochhar, visepresident for bil og transport for Siemens Software, sier at en systemteknisk tilnærming kan strekke seg bredere, ettersom ingeniører tenker på hvordan biler og kjøretøy kobles til alt annet i deres miljøer.
I en smart by er systemet blitt selve byen. Ta for eksempel et kjøretøy i byen. Definisjonen av systemet har flyttet seg fra et enkelt kjøretøy til å inkludere trafikkflyten i byen og til hvordan trafikklysene fungerer. Du kan utvide det ekspansive økosystemet til andre aspekter som bygningsforvaltning, for eksempel inn i smartbymiljøet, sier han.
Det blir en helt annen business case enn det vi har i dag. Disse nye teknologiene fremmer innovasjon, både på teknisk nivå og på forretningsmodellnivå. Så, som et resultat av autonomi og den autonome kjøretøydistribusjonen, dannes nye forretningsmodeller.
Full utskrift
Laurel Ruma: Fra MIT Technology Review. Jeg heter Laurel Ruma, og dette er Business Lab, showet som hjelper bedriftsledere å forstå nye teknologier som kommer ut av laboratoriet og inn på markedet.
Temaet vårt i dag er det programvaredrevne ingeniørmiljøet. Hvordan en bil eller et fly er bygget nå er mye annerledes enn i Henry Fords og Wright-brødrenes dager. Kjøretøy og fly har nå mer programvare enn maskinvare. Etter hvert som innovasjon utvikler seg, utvikler kompleksiteten til programvaren seg også, noe som åpner for nye typer oppfinnelser.
To ord for deg: systemteknikk.
Gjestene mine i dag er Nand Kochhar og Dale Tutt. Nand er visepresident for bil og transport for Siemens Software. Han begynte i Siemens i 2020 etter nesten 30 år i Ford Motor Company, hvor han hadde en rekke stillinger, inkludert sjefingeniør for globale sikkerhetssystemer og teknisk leder.
Dale Tutt er visepresident for romfart og forsvarsindustri for Siemens Software. Før denne rollen jobbet Dale i The Spaceship Company. Og i desember 2018 ledet han teamet på en vellykket flytur til verdensrommet. Velkommen Nand og Dale.
Nand Kochhar : Takk, Laurel.
Dale Tutt : Takk, Laurel, vi er veldig glade for å være her i dag.
Laurel : Så, ettersom produktutvikling på tvers av bransjer – inkludert romfart og forsvar, og bilindustrien – går over fra maskinteknikk til et programvaredrevet ingeniørmiljø, øker systemene i kompleksitet. Programvaredrevet engineering har gitt opphav til det tverrfaglige feltet system engineering. På hvilken måte har dette nye feltet eller nye tilnærmingen påvirket industrien som helhet – og spesielt luftfart og forsvar, og bilindustrien?
nand : Dette feltet har gitt bilindustrien en mulighet til å fortsette å innovere. Som du vet, er trendene i bransjen i endring – vi går fra forbrenningsmotorer til nye fremdriftssystemer, og går mot elektrifisering. Kjøretøyene våre tilpasser seg også autonominivåer, fra SAE nivå 1 til 5.
Alt dette medfører mye kompleksitet. Faktisk kan du si at programvare spiser bilen, ettersom programvare blir en dominerende del av dagens bil- og fremtidig bilutvikling. Den programvareingeniørbaserte disiplinen har gjort det mulig for oss å ta tak i den økende kompleksiteten, og det har gjort det mulig for ingeniørene våre å fortsette å innovere og tilby produkter sluttkunden ønsker. Det er den store endringen – hvordan produktutviklingen og produksjonen i bilindustrien endrer seg.
Gå videre : Som Nand sa om bilindustrien, ser vi et behov for å innovere mye mer enn vi har gjort tidligere innen romfart og forsvar. Enten det er å bygge nye lufttaxier eller EVTOL-flyene, utviklingen innen romsystemer og å sette flere og flere mennesker inn i, endrer vi måten vi gjør romutforskning på.
Når vi beveger oss inn i fremtiden, har behovet for mer bærekraft og å ta tak i å bruke mindre drivstoff og ha større effektivitet i systemene våre drevet mye innovasjon i bransjen. Bedrifter bruker programvare for å muliggjøre mye mer komplekse systemer med forventning om at de vil fungere mer effektivt, mer effektivt. Når det gjelder fly er det forventede resultatet et fly med lavere vekt, som da bruker mindre energi på å reise fra ett sted til et annet.
Systemteknikk har vært dominerende innen romfart og forsvar i flere tiår nå. Den brukes nå for å hjelpe til med å drive noe av den innovasjonen, for å sikre at vi har sett på alle mulige kombinasjoner av et komplekst system, og mulige feilmoduser for disse systemene, slik at vi kan tilby den sikreste, mest pålitelige, høyest mulig produkt for kundene. Så selv om det har eksistert i lang tid, når vi ser på disse komplekse systemene, har vi sett en enorm vekst i behovet for systemteknikk og modellbasert systemutvikling blant alle våre kunder for å få den innovasjonen de ønsker å ha .
Laurel : Så, biler utvikler seg som fly, og man kan til og med si at det er et massivt skifte, ikke bare fra forbrenningsmotorer til elektriske kjøretøy, men også til autonome kjøretøy for begge disse store innovasjonene. Nand, hvordan påvirker det biler generelt og når vi tenker på hvordan systemene brukes og endres så drastisk?
nand : Ja, som du sa, det endrer hele produktutviklingstilnærmingen når du ser på autonome kjøretøy eller elektriske kjøretøy. Så, la oss ta en om gangen. I elektriske kjøretøy, i stedet for å ha forbrenningsmotorer, er det selvfølgelig nå et batterisystem som kilde til kraftproduksjon. Deretter har du overføringen av den kraften som går gjennom hjulene. Så mange av mekanismene i mellom endres.
Når vi sier at den er batteridrevet, for å levere elektrifisering, er det ikke bare batteriet. Det er hele elektronikken som endrer seg med hele arkitekturen så vel som programvaren. Programvaren utfører det vi kaller batteristyring fordi den kontinuerlig optimerer driften av batteriet slik at den kan levere kraften på forespørsel og være den mest effektive, samtidig som den tar tak i tverrattributtproblemene ved enhver termisk ytelse.
Det grunnleggende skiftet skjer på et kjøretøyattributtnivå, på et fører-kjøretøyytelsesnivå, og ikke bare på komponentnivået som du nå har i rotorer og motorer og batterier, kontra de tidligere systemene. Når du ser på autonomi, blir det enda mer komplekst, og starter med nivåene av autonomi til SAE Level 2, hvor du har både bremsefunksjonene så vel som styrefunksjonene og beslutningstakingen som skjer. Så nå har du et ekstra sett med sensorer i bilen. De samler inn informasjon, samler inn data hele tiden. Denne informasjonen blir sendt til en sentral behandlingsenhet for å ta avgjørelser, så du har et ekstra sett med programvare, algoritmene, som tar disse avgjørelsene. Disse beslutningene går tilbake til drift, enten det er bremsing eller om det er styring. Så kompleksitetsnivået har økt.
Du kan ta den enda lenger til SAE Level 3 eller 4. Nå har du kameraet og LIDAR-radaren. Sensorsystemer må også snakke med infrastrukturen, enten det er trafikklys i byen eller om det er andre deler av transponderene som er installert i byene. Definisjonen av systemene har endret seg. Tidligere, da vi ikke hadde avanserte kjøretøy med nivåer av autonomi, ble selve kjøretøyet kalt systemet. Det var et system av systemer, og disse undersystemene var karosseri, chassis, drivlinje, elektronikk. Nå, når du ser på dette autonome miljøet, har selve kjøretøyet blitt et delsystem, og det fungerer i systemet med andre biler på veien og med infrastrukturen, så definisjonen av systemer har endret seg. Dette er hvordan tilnærmingen til system av systemer er den eneste måten å adressere den typen autonomi vi ønsker å nyte på veien.
Laurel : Dale, med EVTOL, eller elektriske vertikale start- og landingsfly, bare ett eksempel, er det likt i hvordan systemene til systemene endrer seg og utvikler seg?
Gå videre : Absolutt. Som Nand sa, har det i mange år vært mye fokus på flyet eller selve produktet og å tenke på det som et system av systemer. Med bruken av droner ble det mer et system med systemproblem, og EVTOL-ene er et problem som ligner veldig på det vi ser i bilindustrien når vi snakker om autonome kjøretøy. Hvordan samhandler flyet med miljøet med sensorer i en by, fordi du skal fly mellom bygninger? Du må kunne sanse og unngå andre fly som flyr. Du må samhandle med ladestasjonene som er en del av infrastrukturen.
Det blir et mye bredere og mer komplekst problem. Du har et høyere nivå av tilkobling mellom de forskjellige kjøretøyene som flyr rundt. Deretter trenger du funksjoner så enkle som å kunne spore dem og gjøre dem i stand til å samhandle med en app på en telefon, ettersom folk ser for seg noe sånt som samkjøring. Det er en del av hvordan hele systemet av systemer fungerer. Det er et mye mer komplekst problem enn vi har hatt tidligere, og du må kunne koble alle delene sammen og administrere dem og få dem til å samhandle riktig slik at du får ønsket ytelse og brukervennlighet til tjenesten.
Laurel : Når vi snakker om den typen utfordringer, ettersom bedriftens infrastrukturer blir mer som systemer med systemer for å inkorporere teknologier som AI, kunstig intelligens og maskinlæring, er det kanskje fornuftig å skifte tenkning til en systemteknisk tilnærming brukt på et helt selskap. Hvilke typer teknologiske endringer møter bedrifter når de integrerer systemteknikk i en eksisterende arkitektur?
Gå videre : Det er alltid litt av en kulturell utfordring også, når du begynner å bringe inn den nye systemtilnærmingen som noen ganger bare vil hoppe rett inn og begynne å designe noe. Som ingeniør antar jeg at jeg har gjort meg skyldig i det noen ganger selv, men du trenger virkelig å ha systemene som hjelper deg med å håndtere kravene dine. Du kan automatisere kontrollen av disse kravene slik at de er skrevet riktig og at de brytes ned fra et system av systemer til et produkt, til de individuelle undersystemene i et fly eller i et kjøretøy. Så det er mye teknologi. Du har større interaksjoner mellom simuleringene dine, designprogramvaren du bruker, og deretter verktøyene du bruker for å administrere systemmodelleringen, men med den høyere grad av autonomi de ønsker, begynner du å ha mer av en systemsikkerhetspåvirkning også. Så du må virkelig kunne koble disse løsningene sammen slik at du ikke går glipp av ting, slik at du kan se et fullstendig bilde. Det er mye enklere å optimalisere produktene dine når programvareløsningene dine er koblet sammen i ett enkelt økosystem.
Det er den tekniske siden. Jeg nevnte litt om kulturen og behovet for folk til å endre tankesett, å ta i bruk en systemteknisk tankegang. De jobber ikke lenger bare med sin lille del av kjøretøyet, men de tenker på det i sammenheng med hvordan det påvirker og samhandler med alle de andre systemene på flyet – eller innenfor økosystemet, i tilfelle av noe sånt som flytaxier. Du må se på prosessene dine, du må se på folkene dine, og du må se på teknologien du tar med deg for å sette sammen en komplett prosess som gir ingeniørene mulighet til å være mer innovative og tenke på nye løsninger .
Laurel : Apropos det, Nand, hvordan ser dyktige ingeniører ut når du jobber med et prosjekt?
nand : Fra et systemteknisk ståsted, slik at de først kan definere problemet som må løses, og deretter gi dem verktøyene og prosessene som kreves for å levere det, er der empowerment kommer inn i bildet. Det er flere nivåer av tekniske utfordringer og løsninger, og å styrke betyr å sette dem i stand med alle disse.
Avhengig av hvor en enkelt bedrift eller organisasjon befinner seg i sin digitale transformasjonsreise, vil disse utfordringene og løsningene være forskjellige. Fra et rendyrket infrastruktur- eller maskinvareperspektiv vil noen ha tilstrekkelig maskinvare installert, som kan håndtere den omfattende mengden modellering og databehandling i deres miljø. Andre vil møte utfordringer med å sørge for at det ikke er siloer, til Dales kulturpunkt, i selskapet, og sikre at informasjonen flyter sømløst fra den ene enden til den andre i et digitalt trådformat. Det er utfordringene. Det er der det er veldig viktig å ha en overordnet plan for å få teknologidelen, så vel som kulturen og menneskesiden av virksomheten adressert fra et talentperspektiv, for å kunne levere en systemteknisk tilnærming.
Laurel : Litt mer om det, Dale – hvordan ser selskaper på den slags utfordringer, med å overvinne talenthullene og bryte ned disse informasjonssiloene? Det er to hovedfokus, kan du si, for digital transformasjon på tvers av alle bransjer, men spesielt for romfart og forsvar og bilindustrien. Så det er et virkelig skifte å tenke på dette på en annen måte.
Gå videre : Ja. Når du begynner å se på hvordan du skal løse dette, må du gå gjennom litt trening med folkene dine og få dem ikke bare til å lære ferdighetene, men til å ta i bruk tankegangen som kreves for å bli systemingeniør. Den andre delen av det er på jakt etter løsningene som faktisk hjelper til med å automatisere noen av disse prosessene.
Noen ganger, når du begynner å bryte ned barrierene, hvis du tenker på tradisjonell strukturell design og strukturanalyse, som når du designer et komposittpanel på et fly, tidligere, ville designeren designe det i CAD og deretter levere det over til en analytiker å gjøre stressanalysen på den delen. Da må de snakke frem og tilbake. Nå, når du begynner å bringe verktøyene sammen og du begynner å bringe simuleringen og designet sammen, kan du nå begynne å la den samme personen gjøre begge oppgavene fordi verktøyene er enkle å bruke, de er integrerte og de er godt automatiserte sammen.
Når du utvider det til systemutvikling, mens du prøver å adressere talentgapet, er det bare så mye du kan gjøre med trening, men det er mye du kan gjøre for å gjøre verktøyene enklere og enklere å bruke. Ved å gjøre dem bedre integrert, ved å bringe teknologier som AI inn i det, der du kan hjelpe til med å automatisere genereringen av forskjellige designkonsepter og analysen av disse konseptene ved hjelp av simuleringsverktøy, kan du utvide funksjonene til systemet slik at det bidrar til å styrke ingeniørene dine .
Selskapene som er mest vellykkede med å ta i bruk systemteknikk, gjør det fordi systemteknikk og verktøyene som blir brukt blir nesten som DNA-et til deres ingeniørorganisasjon - alle begynner å tenke litt som en systemingeniør, selv i deres vanlig jobb. Så ved å gjøre det, har du endret hele organisasjonen din. Du trenger ikke stole på en superspesialisert gruppe systemingeniører for å administrere den prosessen. Alle er en interessent i den prosessen. Verktøyene og økosystemet du bruker til å gjøre systemutvikling har en veldig stor rolle i å hjelpe med det problemet.
Laurel : Å holde på ideen om simulering og kunstig intelligens, det er absolutt noe som trenger mye data, mye ingeniørarbeid for å løse disse virkelig store problemene. Hvor mange ganger drar du til månen og tilbake når du tester et autonomt kjøretøy? Hundrevis, ikke sant? Så du trenger en enorm mengde data for å kunne kjøre simuleringen eller modellene. Kan du forklare litt mer om hvordan simulering – eller til og med konseptet med digital tvilling, som skaper et digitalt nettmiljø for å etterligne det du faktisk ville bygge i feltet – hvordan passer det inn i systemutvikling?
Gå videre : Det spiller en veldig stor rolle. Det er nesten i sentrum av det. Vi tenker ofte på systemutvikling i sammenheng med krav, systemmodellering og deretter bekreftelsesprosessene for å demonstrere at du har tilfredsstilt disse kravene. Det er en klassisk lukket sløyfeprosess innen systemutvikling, men simulering blir et svært kritisk verktøy for å kunne utvikle arkitekturen til produktet ditt og optimalisere disse produktene. Du kan nå se på tusenvis av alternativer. Du kan kjøre forskjellige tester. Så det spiller en veldig stor rolle i å hjelpe med å definere produktet ditt på forhånd.
Deretter, når du starter verifiseringsprosessen, fordi du har simuleringsverktøyene for å evaluere ytelsen til produktet i mange forskjellige konfigurasjoner, kan du identifisere designendringer før du begynner å bygge et produkt og før du begynner å teste det. Det spiller en nøkkelrolle i definisjonen av arkitekturen, deretter definisjonen av produktet, og til slutt, verifiseringen av produktet. Det hjelper med å optimalisere prosessene dine som brukes til å utvikle et nytt produkt.
Laurel : Nand, hvordan hjelper det sikkerheten, når du kan bruke simulering eller digitale tvillinger, eller bare har mer data for å gjøre disse kjøretøyene tryggere?
nand : Simulering danner grunnlaget for å levere en digital tvilling – eller systemutvikling, etter min mening. Så, med simuleringen i forhåndsfasene, kan du gjøre de riktige arkitekturvalgene, og deretter gå videre til de detaljerte designene. Den lar deg utforske plassen for optimalisering i å levere den løsningen. Når du kombinerer det med den fysiske representasjonen av de samme simuleringene og du bringer disse to tingene sammen, er det slik du øker tilliten til simuleringen og de fysiske testresultatene, som kalles en CAE-testkorrelasjon. Det bidrar til å levere systemutvikling. Så du kan si simulering, digital tvilling, de går hånd i hånd med å levere eller gjøre det mulig for systemutvikling å gå fra ende til annen.
Laurel : Så, Nand, hvordan hjelper systemutvikling med å skalere produktutvikling og/eller skape denne industrielle effektiviteten? Hva er avkastningen på investeringen?
nand : Det er interessant. Industriell effektivitet er en av de største sluttleveransene, hvordan du tjener penger på alle disse investeringene. Jeg skal bruke et par eksempler du spurte om tidligere. For det første, hvordan leverer du et trygt kjøretøy? Når du har gjort mange simuleringer, er et av målene å redusere antallet fysiske prototyper som er bygget slik at du kan stole på den simuleringen. Per definisjon er dette billigere fordi du ikke bruker deler og maskiner for å bygge disse prototypene, og det er en stor ting i bilindustrien. Samtidig driver du med mye innovasjon. Det er noen ting som ikke har blitt gjort i et fysisk testmiljø, så du må gå hånd i hånd og gjøre en CAE-korrelasjon for å bygge tillit. Etter det punktet genererer du et nytt sett med data gjennom simulering. Nå, i ditt neste program eller neste iterasjon av designet, er du mye mer effektiv.
La meg ta det enda lenger: hvordan passer kunstig intelligens sammen med disse massive simuleringsdataene inn? Det er mange tilfeller hvor du tar simuleringsdataene, og gjennom maskinlæring trener du algoritmene på utfallet av den aktuelle simuleringen. Så hvis du gjør en aerodynamisk analyse og ser på en luftmotstandskoeffisient, er det intensivt fra et beregningsmessig synspunkt. Noen ganger går de opptil fem dager for å få resultater. Hvis du har trent algoritmene dine gjennom maskinlæring og kunstig intelligens, kan du fortsette å bygge databasen din, for gitte testforhold, på hva resultatene vil bli. På slutten, når du har et nytt designscenario, trenger du ikke å gjøre de fem dager lange simuleringene. Du setter det gjennom disse algoritmene, og det gir deg resultatene i løpet av få minutter. Du kan se en enorm effektivitet, både når det gjelder tid det tar å gjøre det og også databehandlingen, som senker kostnadene for alle disse tingene. Slik øker du avkastningen på investeringene og utvider produktutviklingen din. Du skalerer produktutvikling for flere perspektiver ved å gjøre mer med mindre, med færre mennesker, fordi med simuleringer og alle disse teknologiene kombinert, kan du gjøre samme mengde arbeid. Eller du kan spare med samme antall personer ved å presse gjennom flere produkter. I bilindustrien har du samtidig, noen ganger, opptil 20 programmer i gang, og du kan være mer effektiv.
Laurel : Dale, når vi snakker om avkastning på investeringen og fly for romforsvar, snakker vi om å investere i et system og maskinvare som kan vare i årevis. Et fly erstattes ikke innen et år. Det må vare lenge. Hvordan påvirker ROI måten folk tenker på det med systemutvikling?
Gå videre : Det er et flott spørsmål. Noen av kommentarene Nand kom med fanget mye av det veldig godt. Jeg tenker vanligvis på dette på to måter. Den ene er at når du tenker på et program, og i romfart, går det gjennom utviklingsprogrammet, jobber du med store team. Du ser på budsjettene som brukes til noen av disse programmene, og de kan bruke 10 millioner, 20 millioner, kanskje til og med 100 millioner dollar i måneden. Som en del av den finansieringen går de gjennom sertifiseringsprosessen. Hvis du kan bruke simulering for å unngå en måned eller to med forsinkelser, er det en betydelig sum penger. Mange ganger, hvis du bare hadde en håndfull simuleringsfolk som jobbet med dette problemet, kan avkastningen være 10, 20, 30, 40x. Det er en ganske utrolig besparelse når du går gjennom prosessen, eller kanskje det er en ganske utrolig kostnadsunngåelse.
Den andre delen av det, som du nevnte, er å kunne støtte disse programmene over en livssyklus på 50, 60 år. Ved å ha simuleringsstedet for å kunne forstå hvordan flyet presterer når det først er ute i felten, og ved å oppdatere den digitale tvillingen, simuleringen, er du i stand til å optimere vedlikeholdssyklusene, noe som kan være en stor kostnadsbesparelse for operatørene . Igjen, avkastningen kan være i multipler på 10 eller 20 på noe av det. Noen ganger er disse kostnadene skjult, men det er betydelige besparelser.
Så, når du vil oppgradere eller legge til nye funksjoner, fordi du har den digitale tvillingen og du har simuleringen på plass, har du allerede gjort det systemtekniske arbeidet. Det er lettere å integrere og bringe nye muligheter til kunden. Du fortsetter å tilføre verdi gjennom hele produktets levetid. Så ROI er betydelig med mange av disse verktøyene og går utover første gang du simulerer og begynner å designe kjøretøyet. Det gir utbytte gjennom hele produktets livssyklus.
Laurel: Så, Nand, tidligere nevnte du smarte byer og at systemtekniske tilnærminger kan utvides til mange forskjellige problemtyper i smarte byer. Hvordan tror du systemutvikling vil bidra til ytterligere oppfinnelser og innovasjon?
nand : I en smart by har systemet ditt blitt byen og kjøretøyet i byen, for eksempel. Din definisjon av system har flyttet seg fra et kjøretøy til trafikkflyten i byen, hvordan trafikklysene fungerer i byen, og du kan fortsette å utvide det til andre aspekter av bygningsforvaltning, for eksempel inn i smartbymiljøet . I tilfellet med autonome kjøretøy vil kjøretøyene bevege seg på egen hånd uten sjåfør, så det er en del av byen. De må jobbe med hele byens infrastruktur, hele byens trafikksystemer, trafikklederne og det autonome kjøretøyet. Så det blir en helt annen business case enn det vi har i dag. Alle disse tingene fortsetter å tillate innovasjon, både på teknisk nivå så vel som på forretningsmodellnivå. Som et resultat av autonomi og autonom kjøretøydistribusjon, dannes nye forretningsmodeller. Enten det er å dele selve kjøretøyet eller levere varene eller samkjøring, det er det jeg mener med å fortsette å innovere rundt hva som er fornuftig og hvordan vi kan tjene penger og selskaper kan være lønnsomme.
Når det gjelder den tekniske siden av virksomheten, er tilkobling en stor del av det. Ettersom forbrukertrender som at folk ser på Netflix på telefonen hjemme, når de flytter inn i bilen for å reise et sted, ønsker de kontinuitet. De ønsker å fortsette å se i bilstereovideosystemet. Tilkobling gir mulighet for flere ideer rundt produktutvikling.
Den store i bilindustrien er over-the-air oppdateringer. Så hele paradigmeskiftet fra å måtte skaffe en ny modell av bilen med noen års mellomrom til at de fleste bilfunksjonene oppdateres gjennom programvare, gjør at maskinvaren din forblir den samme. Du kan kjøpe nye funksjoner uten å gå til en forhandler fordi disse funksjonene distribueres gjennom programvare, og de kan leveres over-the-air mens kjøretøyet er parkert hjemme hos deg, eller hvor som helst. Igjen har vi utvidet definisjonen av system. Systemet har blitt programvaren som blir presset fra forfatteren av den programvaren til sluttforbrukeren for produktene deres.
Laurel : Dale, hva synes du om innovasjon og oppfinnelse med systemutvikling?
Gå videre : Alt vi har snakket om her i dag rundt tilkoblede byer og tilkoblede biler og tilkoblede fly og EVTOL, eller flytaxier generelt, er utrolig når du tenker på forretningsmodellene vi ikke har tenkt på ennå. Noe vi drømmer om, i det minste innen romfart, er som å gå til månen – med et system av systemtilnærming og muligheten til alle de nye verktøyene nå til å kunne se på flere alternativer, kan du se på et helt annet sett med hvordan komme til månen og leve på månen. I stedet for en rakett som skyter ut, og deretter overfører du til en månelander, og du tenker på hvordan Apollo-oppdragene ble satt opp, var det mye optimalisering som gikk inn i det, men nå kan du se på det gjennom linsen av helt andre modeller.
Når vi begynner å tenke på hvordan vi bruker energi rundt om i verden og hvordan vi jobber mot en mer bærekraftig fremtid, og etter hvert som smarte byer blir mer og mer sammenkoblet, hvordan bruker du energi effektivt til transporten din? Hvordan bruker du den mer effektivt med kraftproduksjonen din – når solen kommer på det varmeste punktet på dagen og du trenger klimaanlegg, hvordan gjør du bygninger smartere slik at når det er færre mennesker i bygningen, bygningen kan regulere temperaturen for å spare strøm?
Det er så mange muligheter til å tenke på hvordan vi bruker ressursene vi har og koble folk bedre sammen. Det kommer til å være mange muligheter når folk begynner å koble alle disse enhetene sammen, for å virkelig bli mye mer bevisste på omgivelsene våre og hvordan vi samhandler med byer og andre mennesker. Jeg er spent på det.
Laurel : Utmerket. Nand og Dale, tusen takk for at dere ble med meg i dag på Business Lab.
Gå videre : Det var flott å være her, og jeg likte samtalen i dag. Takk skal du ha.
nand : Takk igjen. Jeg likte samtalen også.
Laurel : Det var Nand Kochhar, og Dale Tutt, fra Siemens Software, som jeg snakket med fra Cambridge, Massachusetts, hjemmet til MIT og MIT Technology Review, med utsikt over Charles River. Det var alt for denne episoden av Business Lab. Jeg er verten din, Laurel Ruma. Jeg er direktør for Insights, den tilpassede publiseringsavdelingen til MIT Technology Review. Vi ble grunnlagt i 1899 ved Massachusetts Institute of Technology, og du kunne finne oss i utskrifter på nettet og på arrangementer hvert år rundt om i verden. For mer informasjon om oss og showet, vennligst sjekk ut nettstedet vårt på technologyreview.com. Dette programmet er tilgjengelig uansett hvor du får podcastene dine. Hvis du likte denne episoden, håper vi at du tar deg tid til å vurdere og anmelde oss. Business Lab er en produksjon av MIT Technology Review. Denne episoden ble produsert av Collective Next. Takk for at du lyttet.
Denne podcasten ble produsert av Insights, den tilpassede innholdsarmen til MIT Technology Review. Den ble ikke skrevet av MIT Technology Reviews redaksjon.