Cisco-routere dør efter 18 måneder
Det såkaldte clock-signal i flere typer netværksudstyr fra Cisco går i stå efter omkring 18 måneder, hvilket får udstyret til at gå i stå. Det fremgår af en meddelelse, som Cisco har publiceret på sin hjemmeside.
Det gælder flere typer netværksudstyr, herunder enheder til optiske netværk, routere, switches og sikkerhedskomponenter, oplyser selskabet. Der er primært tale om professionelt udstyr, der blandt andet bruges i industrien.
Udstyr kan ikke reddes
Clock-signalet genereres af en oscillator, der skaber et signal, der er med til at koordinere udstyrets interne handlinger. Når clock-signalet går i stykker, står udstyret derfor ikke til at redde.
‘I nogle enheder har vi set clock-signal-komponenten blive nedbrudt over tid. Selv om Cisco-produkterne med denne komponent nu fungerer normalt, forventer vi, at produktfejlene vil være stigende i løbet af årene, begyndende fra enhederne har været i brug i omkring 18 måneder,’ hedder det i meddelelsen.
Også i Danmark
Fejlen er meddelt via Ciscos internationale afdeling og findes i produkter i mange lande, oplyser selskabet. Det gælder også Danmark, bekræfter Ciscos danske afdeling over for Ingeniøren.
Cisco Danmark ønsker ikke at sætte tal på, hvor mange kunder eller enheder, det drejer sig om i Danmark, men selskabet er i gang med at samarbejde med de berørte kunder om at udbedre fejlen, oplyser selskabet. Cisco kender allerede ejerne af en del af udstyret, da det er omfattet af serviceaftaler, men nogle af enhederne er ældre, og deres placering er derfor ukendt.
Fejlen har ramt clock-komponenter fra en enkelt underleverandør og påvirker derfor også andre virksomheders udstyr, påpeger Cisco.
- emailE-mail
- linkKopier link

Fortsæt din læsning
- Sortér efter chevron_right
- Trådet debat
Du glemmer, at potentiometeret fysisk skal stå i samme stilling, når der er skruet op med fjernbetjeningen, som når der er skruet op ved at dreje på knappen på apparatet. Ellers er du ude i noget, der virkelig vil være råddent at betjene.Når der bruges en microcontroller ganges volumen på digitalt, så der kræves ingen servomotor.
Derfor servomotor.
Når der bruges en microcontroller ganges volumen på digitalt, så der kræves ingen servomotor.Hvis et apparat med gammeldags drejepotentiometre skal kunne betjenes med en fjernbetjening, skal drejepotentiometrene forsynes med servomotorer. Dyrt.
Fjernbetjeninger kan laves på mange måder, men det er korrekt at standard fjernbetjeninger kun har billige knapper. Der kan dog nemt placeres drejeknapper, f.eks. på siden, eller en stor knap til at dreje på midt på.
Man skal ikke blande bruger grænseflade og funktion sammen. Når man vælger at lave en "Glass user interface" så er det ofte af økonomiske grunde. Hardware og mekanik koster penge i hvert enkelt apparat. Det gør software ikke. Et af de første eksempler på "billig interface" var Sinclair ZX-80 og ZX-81. Man brugte et billigt tastatur og lagde alle funktionerne i software. Et andet eksempel er "den gode gamle" Apple ][. Den tekniske guru "Woz" var meget bevidst om at hardware kostede penge. Derfor blev alt der kunne laves i SW lavet på den måde. Eksempler
- Scanning af display memory, der også var en del af data/program lageret blev lavet så den samtidig lavede refresh af den dynamiske RAM.
- Busy signalet fra en printer gik direkte ind på et adresseben i ROM'en på interface kortet, så den adresse, og dermed den instruktion man fik fat i afhang af printerens tilstand, busy /non-busy.
- Da Apple skulle lave deres floppy disk tog de det billigste floppy drev de kunne få, Shugart SA-400. Derefter fjernede de 50% af komponenterne i drevet! Skrivning til disken foregik i software i en rutine på præcis 32 clocks. Hele interface kortet bestod af 12 komponenter. Ser vi på brugergrænseflade i f.eks. et fly så er der godt nok et "Glass cockpit" i dag, men alle de kritiske betjeningsgreb opfører sig som analoge greb. I små fly har grebene til de forskellige funktioner forskellige form, så man kan føle sig frem til, om man har fået fat i det rigtige greb. Når vi taler om måleinstrumenter, så bruges der på et oscilloskop stadigvæk drejeknapper, selv om der sidder en computer bagved. Markedet har tydeligt vist at det er hvad folk vælger. Det er selvfølgelig dyrere at 'emulere' de analoge funktioner, men så må du vælge - pris eller funktion, du får ikke begge dele ;).
Det undrer mig, at du kan vide så meget om teknikken uden nogen sinde at have forstået årsagen til den nuværende konstruktion. Årsagen er ellers simpel: Der medfølger fjernbetjeninger til stort set alle apparater i dag.Det med menuer, faneblade, og alt det andet "gejl" har intet med mikroprocessorer at gøre. Det er et modefænomen, og jeg fatter ikke årsagen.
Hvis et apparat med gammeldags drejepotentiometre skal kunne betjenes med en fjernbetjening, skal drejepotentiometrene forsynes med servomotorer. Dyrt.
En lidt billigere løsning er et endeløst drejehjul, som giver impulser til styringen. Men det bliver aldrig lige så godt, fordi man ikke kan mærke yderpunkterne og et eventuelt stop på midten. Og det er stadig dyrt, fordi det kræver en masse mekanik.
Nej, det er meget meget langsommere.Er det hurtigere at skulle ind i en menu for at stille disse parametre ved at skulle trykke og holde en tast nede, eller er betjeningen hurtigere med et gammeldags potentiometer af en ordentlig kvalitet?
En microcontroller kan bruges på mange måder, og kan nemt øge kvaliteten af et produkt. F.eks. kan den øge kvaliteten af en gammeldags potentiometer. Hvis du er dygtig til elektronik, kan du kode den, så den aftastes på en måde, så at det ikke betyder noget om der er god forbindelse til midterbenet. Den giver samme svar, uanset modstanden til midterbenet, og dermed det som bevæges. Og, når du aflæser den, kan du gange værdien på digitalt, og da de fleste signaler er digitale, derved få en højkvalitets potentiometer, selvom det er en billig type.
Det med menuer, faneblade, og alt det andet "gejl" har intet med mikroprocessorer at gøre. Det er et modefænomen, og jeg fatter ikke årsagen.
For ikke lang tid siden, sad jeg med et værktøj, der kunne lave et program med nogle få klik - man satte bare det hele op i nogle faneblade. Det, som de ikke havde tænkt på, var at det der ikke burde fylde mere end en halv linje i et program, nu krævede et screendump på en side, for at kunne dokumenteres. Og det var ikke mere muligt, at kopiere det ind med cut and paste, så det skulle sættes op i faneblade hver gang. Skulle forklares overfor andre, hvad der var gjort, så krævede det en bog med screenshots, for det som en gang kunne stå på få linjer. Men, nu var få linjer ikke mere mulige - for programmet genererede et megabyte stor kode for det som blev lavet. Tidligere, havde man biblioteker, man ikke lavede om på. Nu, var de undgået, og hele koden konstrueret af programmet, ud fra faneblade... Kan det blive dårligere, end når den indtastede kode ikke kan udskrives?
Det bedste - efter min opfattelse - er at undgå alt det moderne med faneblade. Tingene skal kunne dokumenteres. Det skal kunne skrives ud på printer. Og det skal ikke gøres med screendumps af faneblade. For det fylder nemt en side, for ingenting.
En radio skal naturligvis kunne justeres med en drejeknap. Ingen tvivl om det. Men, i stedet for, at bruge et gammeldags potentiometer, kan man evt. bruge en elektronisk drejeknap med gray output. Problemet er bare, at de fleste programmører ikke kan finde ud af at aftaste dem. Der findes masser af "how to do" på nettet, og stort set ingen gør det korrekt.
Der er også mange, der ikke kan finde ud af at aftaste en gammeldags drejepotentiometer. Det var der også i gamle dage. Mange amatører (f.eks. IBM), kunne ikke designe en forstærker, så overgansmodstanden på midterbenet ikke betød noget. Resultatet var masser af støj, når der blev drejet på knappen.
Jeg tror, at grunden til man i dag vælger knapper til at justere op og ned på lyden, skyldes at de færreste kan finde ud af at bruge en variabel modstand. Derimod knapper - dem kan man finde eksempler på på nettet.
Jeg undrer mig somme tider som elektroniktekniker over, at der i snart sagt alt udstyr i dag, skal være en microcontroller eller microprocessor, ofte med tilhørende lorte-software. Jeg kan i mange ting, bedre lide ordentligt hardware med almindelige komponenter. Hvis de udvikles ordentligt, holder og fungerer de i mange tilfælde bedre end noget "computerstyret". Tag som f.eks. bass, diskant, balance og volumeregulering i en forstærker. Er det hurtigere at skulle ind i en menu for at stille disse parametre ved at skulle trykke og holde en tast nede, eller er betjeningen hurtigere med et gammeldags potentiometer af en ordentlig kvalitet? Det samme kan siges om f.eks. fjernsyn. Der går en evighed, hver gang der skiftes program, til der kommer billede på, efter det er blevet digitalt. Digitale forstærkere (klasse D) er muligvis ganske små og effektive, MEN de spiller sgu ikke bedre end en god japansk forstærker fra 1980 med ægte analog lyd.
Hvis der er tale om designet indbygget forældelse i enheden, er artiklen vel yderst interessant?
Det er vel det samme som foran TV'et. Jo mindre engageret man er i hvad der foregår, jo større risiko for at falde i søvn.så det kan sikkert også ske i selvkørende biler.
Hvis det ikke er en del af sikkerheden, at hovedsikringen springer.Det er ikke alle komponenter der vil fejle, kun nogle.
Det er ikke alle komponenter der vil fejle, kun nogle.
Det er en udmærket introduktionsbog, men jeg syntes der er nogle vigtige detaljer, som ikke er tydelige. I et realtids system, skal selve realtidskernen helst være helt uden timing. Det må ikke indeholde et system, der sætter noget i gang, på et bestemt tidspunkt. Idéen med et realtidssystem, er at det er hurtigt nok, til at opfylde nogle specifikationer. Det må aldrig være længere tid om at svare, end disse specifikationer angiver. Men, det må heller aldrig selv indeholde noget ur. Hvordan skal systemet så sikre, at tingene kommer ud til tiden? Og hvordan, skal man lave f.eks. et delay? Jo, det sker først ved mødet med virkeligheden. Inde i maven, er tingene uden ur. Præcist som i kvantemekanik. Tid findes ikke. Tid opstår først, ved mødet med den virkelige fysiske verden. Derfor, vil man hvis der skal være f.eks. et delay, have et ekstra "lag" uden om real tids systemet, der håndterer tid. Når at noget påvirkes på et bestemt tidspunkt, så kan det kun ske ud fra data, der er af tidstype. Der følger således et tidstempel med. Dette kan ikke laves internt i realtidssystemet, for der findes ingen tid. Det kommer derimod fra den ydre verden. Når et signal skifter, så følger der et tidssignal med. Realtids kernen, kan nu f.eks. lægge noget tid til dette, og bruge det, når en f.eks. en udgang skifter. På den måde sikres, at udgangen skifter eksakt i forhold til indgangen. Der kan også specificeres, at den bare skal skifte så hurtigt som muligt - men ud fra et test og et bevis sammenhæng, er det ofte svært at styre, da det indføjer tilfældigheder. Disse tilfældigheder er oftest uønsket i et realtidssystem. Derfor, følger timingen faste retningslinjer, der bestemmes af koden i realtidskernen. Hardwaren omkring realtids kernen, sørger så for tidsstempling af input signaler, og sikrer at udgangssignalerne skifter, til det tidspunkt de er tidsstemplet. Er det ikke muligt at nå for realtids kernen, så giver hardwaren fejl, fordi at den ikke kan opfylde timingen. Timingen er således 100% garanteret, for kan et signal ikke påsættes udgangen, på præcist det angivne tidspunkt, så vil der opstå en hardware fejl. Dette er en af de vigtige tjek i et hardware realtids operativsystem.Følgende bog giver indsigt i sikkerheds kritiske realtids systemer:
<a href="https://goo.gl/attlD4">https://goo.gl/attlD4</a>
Tidsstemplingen kan også - hvis der ikke sættes store krav til præcisionen - laves i et software lag, der lægges uden om realtids kernen. Dette software lag, anvender interrupts til at stå for tidsstemplingen, samt et ur, for at stå for at sende data ud på det påstemplede tidspunkt.
Denne metode medfører også, at det er nemmere at sammenligne data, da udgangene skifter til tiden. Det er nemmere at håndtere redundans.
Endeligt, så giver den flest ressourcer til realtidsoperativsystemet. Der er ingen "forsinkelser" i denne. Forsinkelsen står først i den latch, der er ved udgangen. Og den kan i princippet placeres langt væk fra realtids kernen - f.eks. gå igennem busser, ethernet, osv. Så en udgangsport på et realtidsoperativ system, kan i princippet være på den modsatte side af jorden. Da realtids operativsystemet i sig selv er uden tid, så vil dataene foreligge i god tid, på det sted, hvor de manifesterer sig fysisk, også selvom dette sted er på modsatte side af jorden, og selvom det måske tager noget tid, inden dataene er der. Hvis det er over lange afstande, så har man systemer, der sikrer at dataene kommer synkront, trods forsinkelser.
I et godt realtids system, er alt deterministisk set fra omgivelserne, uanset det multitasker og er "tilfældigt" internt, og måske er forskellige identiske kerner, skrevet af forskellige softwarefolk. Udefra er timingen algorithmebestemt og præcist. Ofte, styres den af en FPGA eller af en timing chip.
Timingen er en vigtig del, af at sikre determinisme. Er der f.eks. to der indtaster data i en database, så vil der være en tidsstempling i tastaturet eller terminalen, hvor de indtastes. Og systemet tager hensyn til det fysiske tidspunkt, når der afgøres i hvilken rækkefølge data håndteres. Det er således ikke tidspunktet, at data når computeren og beregningsenheden som betyder noget, men det fysiske tidspunkt, hvor data måles, og det fysiske tidspunkt, hvor data bliver til noget i virkeligheden.
Realtidsoperativsystemer, minder på mange måder om måden kvantemekanik fungerer.
Ja, chips med hardware redundans findes på markedet, og de koster stort set intet, i forhold til en selvkørende bil. Det som koster, er at udvikle softwaren så den er sikker. Det kræver bunker af dokumentation, og trods det, er det ikke altid helt sikkert. Man kan også have flere uafhængige hold, til at udvikle softwaren til processorerne - det tror jeg, er mere sikkert, end at dokumentere sig ud af sikkerheden, fordi det tvinger individuelle hold, til at selv gennemtænke problemerne, og ikke tage det for gode varer, det de fortælles af dokumenterne. Og er de individuelle holds software ikke ens, så opdages hurtigt fejlene, når softwaren kan bevises at have været ude i gennem alle betingelser, og alle dele af koden. Det, som ofte giver fejl, er den del som er fælles, hvis den ikke tjekkes nok. Og det er der tendens til ikke sker, hvis man ikke selv skal bruge koden. Det betyder ikke, at det ikke er en god idé med dokumentation. Men, i nogle tilfælde, kan være mest sikkert, at den ikke bliver læst, da den ødelægger uafhængigheden.Der er forskel på at bygge 100 satellitter og når Bosch spytter 10 mio. self driving kits ud. Så kommer det ikke til at koste meget.
At føreren falder i søvn?Og noget lignende vil selvfølgelig aldrig kunne ske i en selvkørende bil?
Jo, det sker ofte i ikke-selvkørende biler, nogle gange med fatale følger, så det kan sikkert også ske i selvkørende biler.
Hvad er din pointe?
Dobbelte CPU'er betyder at der kan implementeres lock-stepping mellem de to CPU'er og hvis der er afvigelser kan systemet 'Fail-silent', dvs. undlade at sende forkert data videre. Ved at have to af disse systemer kan man implementere et Dual-Dual system.EDIT: Det ser faktisk ud til at nVidia's system allerede har en del redundans indbygget, i det at den består af to separate CPU'er i den konfiguration der kan klare autonom kørsel.
Ja det vil så minimum kræve triple redundans ... den ene cpu siger "undvig til højre" og den anden siger "undvig til venstre" ... hvem skal bilen stole på ? ;)
Følgende bog giver indsigt i sikkerheds kritiske realtids systemer:https://goo.gl/attlD4
De prøver at holde låg på indtil at garantien er udløbet.. Jeg har selv en Intel Atom Atom C2xxx i en 'Hjemmebygget' NAS Box hvor jeg køre Free NAS (Nano BSD). Jeg vil være lidt træt af hvis CPU'en fejlene kort efter garantiens udløb, og jeg igen skal ud og købe et nyt motherboard med ECC support.Intel prøver tilsyneladende at smålyve om hvor slemt det er (intel: "after multiple years of service", cisco: "18 måneder", intel: "slightly higher expected failure rates") og forbyde deres kunder, at omtale Intel ifm. fejlen.
Erfaring osv. kan der diskuteres om i 100 år, uden at alle bliver enige og det har som sådan, ikke noget med artiklen at gøre.
Der er 100 vis af ting man kan gøre for at øge sikkerhed.
I et computersystem bliver der sjældent taget beslutninger ud fra kun et spørgsmål, et objekt bliver spottet flere gange, derfor kan et "forkert svar" skrottes. Man kan detektere sig selv med en sensor og derved kontrollere om den virker og om den er calibreret korrekt. Man kan sætte interrupts op med en co processor, som kræver et opslag i en database indenfor ms, hvis svaret er forkert spørges der igen, hvis svar stadig er forkert bremses der og bilen kan kun køres manuelt. Man kan udstyre softwaren med en vurdering af dens egne målinger, så hvis den får et højt antal uventede svar, så kan den erklære sig selv defekt.
En normal PC kan fungere med mange fejlberegninger i sekundet, uden at det påvirker brugeren, på grund af diverse foranstaltninger.
Man kan lave en fælles sikkerheds software eller computer, som alle biler skal være udstyret med, for at kunne synes. Et syn kan kræve at man simulerer en køretur med bilen, for at kontrollere bilens beslutninger og alle dens målinger. Der findes i forvejen mange fælles standarter biler skal overholde, så man kan sagtens indføre lidt flere.
Afslutningsvis vil jeg lige pointere at jeg ikke programmerer til dagligt, men håber da på at starte op på Arduino programmering, på et tidspunkt jeg har mod på det.
Hvor urene ikke rigtig virker hele tiden.Særligt da der er afhængighed af andre eksterne systemer. Afvigelse i Galileo...
Suk.Du diskvalificerer dig selv, når du benytter sådanne udsagn, du har ingen viden, kun en mening.
Og du vil slet ikke mene at det måske er dig selv som er i gang med at diskvalificere sig selv, med udtalelser om noget du intet ved om, nemlig min viden.
Faktum er at min viden er gennem mange års udvikling af software - og jeg er ikke guddommelig, så jeg laver så sandelig mange fejl, og støder jævnligt på nye "udfordringer" som jeg ikke i min vildeste fantasi havde kunne forestille mig, hvorfor jeg har udviklet en sund skepsis, både over for egne evner, men sandelig også over for IT som så.
Men måske du heller skulle komme med nogle fakta, og ikke bare statements fra Teslas glittede brochurer!
Du diskvalificerer dig selv, når du benytter sådanne udsagn, du har ingen viden, kun en mening.naive tilgang til magisk IT-sovs (ikke kun for biler),
Den erfaring jeg har, har rigtig meget med computere og softwareudvikling at gøre, og det er meget centralt nå vi taler om køretøjer hvor man vil overlade alt til computere.Nej, du kan ikke komme med fakta, men hvorfor skal du så gentage og gentage den samme mening uendeligt, det bliver ikke fakta af at blive gentaget. Den erfaring du har, har tilsyneladende intet med selvkørende biler at gøre, så skal vi ikke holde den udenfor.
Og det er sådan set ikke for at prøve at få dig til at konvertere at jeg udviser min skepsis, men mere en forhåbning om at nogle af beslutningstagerne også udviser en sund skepsis, i stedet for at tro at de autonome biler dumper ned fra himlen om ganske føje år, så de passende kan indstille investeringer i offentlig transport mv.
Derfor mener jeg det er meget relevant at jeg fremfører min skepsis over for den naive tilgang til magisk IT-sovs (ikke kun for biler), så vi ikke om 10-20 år står med mega problemer på transportområdet, svarende til Stats problemer med de over 100 milliarder de ikke fik kradset ind, i naiv tiltro til magisk IT-sovs!
Nej, du kan ikke komme med fakta, men hvorfor skal du så gentage og gentage den samme mening uendeligt, det bliver ikke fakta af at blive gentaget. Den erfaring du har, har tilsyneladende intet med selvkørende biler at gøre, så skal vi ikke holde den udenfor.Nej Raymond, af gode grunde kan jeg ikke komme med fakta om om fremtiden, men jeg kan godt med erfaringer fra software (og hardware, som ovenstående handler om) tillade mig at være skeptisk over for ukritisk anvendelse af computere.</p>
<p>At det så støder din religion kan jeg sådan set ikke tage så tungt, kun ryste på hovedet over den blinde og naive tiltro til fagre nye verden som nogen udviser.
Jeg er hverken religiøs og slet ikke naiv, men den udvikling vi taler om, er idag slet ikke udenfor rækkevidde(computerkraft) som det var for bare få år siden.at det så støder din religion kan jeg sådan set ikke tage så tungt, kun ryste på hovedet over den blinde og naive tiltro til fagre nye verden som nogen udviser.
Og fakta er de oplysninger der kommer fra Mekka ^^^^^ Palo Alto?Ja, du gentager gerne din MENING(men lidt for ofte!), men du bringer meget lidt fakta til debatten.
Nej Raymond, af gode grunde kan jeg ikke komme med fakta om om fremtiden, men jeg kan godt med erfaringer fra software (og hardware, som ovenstående handler om) tillade mig at være skeptisk over for ukritisk anvendelse af computere.
At det så støder din religion kan jeg sådan set ikke tage så tungt, kun ryste på hovedet over den blinde og naive tiltro til fagre nye verden som nogen udviser.
OG så er der et helt andet aspekt, nemlig selve sikkerheden mod hackning eller andre former for sabotage, som man imo slet ikke har fokus nok på - her kan følgevirkningerne bare være en hel del mere alvorlige end en hullet router, eller andet Internet of Trash.
Javel ja:Biler har kørt med computerstyret Speeder i over 10 år og det har kun forsaget ganske få uheld.
Jeg mener at PHK vist også har underholdt om den sag på nærværende side.
Og her var der endda kun tale om speederen, hvad så når der ikke er rat og pedaler overhovedet?
Hvilket det så ikke nødvendigvis bliver, jævnfør ovenstående.Udstyr til biler er for det meste testet over lang tid, før det finder vej ind i en bil, så problemet burde blive opdaget inden fuld produktion.
Og der er nok ingen grund til at tro at det skulle være bedre for biler som f.eks. kommer fra Kina, hvor økonomien (altså profitmaksimeringen) vejer tungt.
Husk lige på at en bil har en levetid på i gennemsnit ca. 16 år.Hvis producenten har en dårlig batch, skulle det gerne blive fanget i en sideløbende langtids test, som det fleste bil producenter har kørende i forvejen.
Så er den jo ikke autonom, men fordrer en aktiv fører, klar til at træde til med sekunders varsel.På en 100% computerstyrret bil, skulle der ikke være noget til at forhindre, at man stadig har en fast forbindelse til bremsen, så man altid kan bremse bilen ned.
Og hvad er en given tid - ved 130 km/h bevæger bilen sig 36 meter frem i løbet af et sekund, samtidig med der kun er 2-3 meter til bilerne ved siden af.Der kan også installeres mere simple nødsystemer, som aktiveres, hvis hovedcomputeren ikke svarer korrekt eller indenfor en given tid.
Software til forsvar og rumfart (som så i øvrigt jo absolut ikke altid opfører sig som de skal, selv noget der ikke engang skal bevæge sig som f.eks. De Mars) tager lang, lang tid at udvikle, og det gennemtestes i hoved og røv, og fikses ikke bare lige med en ny opdatering til marts.Software til forsvaret, rumfart osv. er for det meste bygget så en computer ikke kan hænge fast i en korrupt kommando, computeren får muligvis et forkert resultat på den ene kommando, men fortsætter videre i dens software.
Ja, du gentager gerne din MENING(men lidt for ofte!), men du bringer meget lidt fakta til debatten. Biler slipper ikke rat og pedaler foreløbigt pga. lovgivning, men derfor kan de godt være selvkørende. Teslas AP1 har nedsat ulykker med 60%.Jeg gentager gerne, jeg tror vi får mere og mere driverassistance at se over de kommende år, og det er godt, men derfra og til den autonome bil, hvor der ikke er rat og pedaler, men en computer (hvor en enkelt bug, eller en fejl i clockgeneratoren, kan få fatale følger) som står for alt kørslen, er der altså langt.
Som f.eks.: https://phys.org/news/2017-01-clocks-onboard-europe-satellites-esa.html
Du har ret i at den ikke blev slået ud pga. redundans, men det sker dog.
Fordi, ud over Tesla, så har bilfabrikkerne reelt set meget lidt erfaring med software udvikling.For mig virker det lidt underligt, at nogen herinde mener at være så vidende på området, så de ved bedre end Tesla, Ford, Volvo , GM, VW, Audi, Nvida, Mobileye og mange andre. Men de tror vel også på, at GW ikke findes.
Det kan jo f.eks. også ses ud fra denne artikel, at toplederne fra bil industrien har deres eget verdenssyn:
https://ing.dk/artikel/topledere-diesel-doed-braendselsceller-lever-193469
Og så er det ikke et spørgsmål om at "være vidende", men om at være skeptisk over for udmeldinger om at man lige på magisk vis kan fikse tingene på nogle få år - prøv at se hvor svært det er at få noget i sammenligning simpelt som jernbanedrift til at fungere.
Jeg gentager gerne, jeg tror vi får mere og mere driverassistance at se over de kommende år, og det er godt, men derfra og til den autonome bil, hvor der ikke er rat og pedaler, men en computer (hvor en enkelt bug, eller en fejl i clockgeneratoren, kan få fatale følger) som står for alt kørslen, er der altså langt.
Men jeg tror egentlig det løses sig selv - inden for nogle få år ser vi givetvis en række fæle ulykker, og så træder myndighederne pedalen ned (hvis man kan bruge det udtryk) og stiller krav svarende til de krav der stilles til jernbanedrift og flyvning.
Ja, jeg læser at nogen herinde mener at de nævnte foretagender har for stor egeninteresse i projekterne, til at man helt kan stole på deres udtalelser.For mig virker det lidt underligt, at nogen herinde mener at være så vidende på området, så de ved bedre end
Biler har kørt med computerstyret Speeder i over 10 år og det har kun forsaget ganske få uheld.
Udstyr til biler er for det meste testet over lang tid, før det finder vej ind i en bil, så problemet burde blive opdaget inden fuld produktion. Hvis producenten har en dårlig batch, skulle det gerne blive fanget i en sideløbende langtids test, som det fleste bil producenter har kørende i forvejen.
På en 100% computerstyrret bil, skulle der ikke være noget til at forhindre, at man stadig har en fast forbindelse til bremsen, så man altid kan bremse bilen ned. Der kan også installeres mere simple nødsystemer, som aktiveres, hvis hovedcomputeren ikke svarer korrekt eller indenfor en given tid.
Software til forsvaret, rumfart osv. er for det meste bygget så en computer ikke kan hænge fast i en korrupt kommando, computeren får muligvis et forkert resultat på den ene kommando, men fortsætter videre i dens software.
Lidt info om problemet fra en Hardware side.https://www.guru3d.com/news-story/intel-atom-c2000-chips-are-bricking-products.html
Ja, jeg har også mere end 30 år med softwareudvikling på bagen og alligevel er jeg ikke så bekymret. For mig virker det lidt underligt, at nogen herinde mener at være så vidende på området, så de ved bedre end Tesla, Ford, Volvo , GM, VW, Audi, Nvida, Mobileye og mange andre. Men de tror vel også på, at GW ikke findes.Og efter at have arbejdet med software i over 30 år, så har man altså set et og andet, som gør en en del mere skeptisk.
Og før man kommer for godt i gang med at påstå at flyvning er meget mere kompliceret, så vil jeg faktisk sige tværtom, fordi der er meget mere plads i luften, end mellem 3 baner af motorvejstrafik med 130km/t - en selv lille ubetydelig fejl kan give fatale følger.
Særligt da der er afhængighed af andre eksterne systemer. Afvigelse i Galileo, GPS eller automatisk bare softwareopdatering der kikser. Hvor hurtigt opdages fejl til hvordan reageres der så på fejl. Ved høj hastighed betyder sekunder meget, så autonome nød-procedurer burde værre en vigtig komponent.
Og efter at have arbejdet med software i over 30 år, så har man altså set et og andet, som gør en en del mere skeptisk.Som datalog(under uddannelse)
Prøv lige at læse denne tråd igennem, det illustrerer meget godt hvad der kan ske når man blindt lægger sit liv i automatiske systemer, som så trækker i hver sin retning:
https://ing.dk/artikel/what-sagde-piloten-80-sekunder-efter-styrtede-han-ned-190362
Og før man kommer for godt i gang med at påstå at flyvning er meget mere kompliceret, så vil jeg faktisk sige tværtom, fordi der er meget mere plads i luften, end mellem 3 baner af motorvejstrafik med 130km/t - en selv lille ubetydelig fejl kan give fatale følger.
forstår ikke hvordan man kan få sig selv til at sige at en sådan opgave er triviel :) men det er jo selvfølgelig også en medvirkende faktor til at vi ser alle de fejlslagne it projekter i danmark.
Den herre og den dame misforstår hvordan et sådant system virker.
En ting er teori. En anden ting praksis! :-) Jeg har 1., 2., 3. hånds kenskab til hw fejl, som får alt til at fejle katastrofalt - selv med redundans, m.m. - dvs. at noget så simpelt, som at køre ind til siden ikke er en option da hardwaren er beyound reach - man må bare håbe at alt bliver sluppet, så bilen kan trilles ind til siden under "chaufførens" kontrol.
Ja det vil så minimum kræve triple redundans ... den ene cpu siger "undvig til højre" og den anden siger "undvig til venstre" ... hvem skal bilen stole på ? ;)
I misforstår hvordan et sådant system virker. I normal drift vil de to CPUer foretage vidt forskellige beregninger, så de vil på ingen måde komme i konflikt. Som datalog(under uddannelse) vil jeg også vove at påstå, at en hardware-fejl har usandsynligt lille chance for at være skyld i at man får et enkelt forkert resultat, og programmellet så ellers vil køre videre som om intet er hændt. I langt, langt, langt de fleste tilfælde vil enhver skade på eller overophedning af en CPU betyde, at hele den software den afvikler crasher. Der vil altså aldrig blive tale om at CPU 0 siger"drej til højre", og CPU 1 "drej til venstre", selv hvis de skulle afvikle nøjagtigt samme programmel. Naturligvis givet at de får samme input.Men hvilken CPU har så ret? Der var en grund til at Space Shuttle havde 5 uafhængige computere!
4 som i bogstaveligste forstand kunne kæmpe imod hinanden, ved hver især og hive i "roret". "Flertallet" vandt! Og hvis de gik ned, var der en 5. med et simplere program, som burde kunne få den ned på jorden igen i hel tilstand!
Det vi her har diskuteret er hvorvidt selvkørende biler er sikrede imod at en kernekomponent, såsom CPUen, bryder sammen. Hvis man har to uafhængige CPUer på samme printplade, er det trivielt at få dem til at holde øje med hinanden. I tilfælde af at den ene CPU fejler, vil den tilbageværende CPU næppe selv kunne føre bilen sikkert, hvis der normalt skal to af dem til for at håndtere alle beregningerne. Det den vil kunne gøre er at følge den nuværende vejbane, måske sænke farten, og bede føreren om at køre bilen ind til siden, eller evt. gøre det selv.
Igen væsentligt mindre farligt end en menneskelig fører der får et ildebefindende.
Jeg håber det besvarer dit spørgsmål. Bilen vil, selv med halv regnekraft, i langt de fleste tilfælde selv kunne køre ind til siden, tænde nødblinket og ringe efter vejhjælpen.Og hvordan gør man lige det på en level 5 bil?
Og hvordan gør man lige det på en level 5 bil?Forskellen er at her skal du bare detektere at der er noget galt, stoppe bilen og tænde katastrofeblinket. Det virker ikke med en Shuttle (eller et fly).
Præcis, det er der jeg gerne vil hen - udviklingen skal nok gå mod højere og højere grad af autonomitet, men jeg stiller mig bare skeptisk over for dem der tror at de selvkørende biler er her i overmorgen.Jeg er sådan set enig med Christian Nobel i, at vi skal forholde os skeptisk til teknologien. Ikke nødvendigvis sådan, at vi skal afvise den, men måske nærmere sådan, at vi er nødt til at tænke ind i designet af systemer hvad der skal ske, hvis teknologien svigter.
Og i det spil mener jeg det er meget sundt at gøre sig overvejelser om hvordan vi undgår ulykkerne, i stedet for bare blindt at stole på noget hw og sw.
Og hvordan vil det så lige påvirke prisen - mig bekendt er satellit udstyr ikke just billigt.
Der er forskel på at bygge 100 satellitter og når Bosch spytter 10 mio. self driving kits ud. Så kommer det ikke til at koste meget.
Men hvilken CPU har så ret? Der var en grund til at Space Shuttle havde 5 uafhængige computere!
4 som i bogstaveligste forstand kunne kæmpe imod hinanden, ved hver især og hive i "roret". "Flertallet" vandt! Og hvis de gik ned, var der en 5. med et simplere program, som burde kunne få den ned på jorden igen i hel tilstand!
Forskellen er at her skal du bare detektere at der er noget galt, stoppe bilen og tænde katastrofeblinket. Det virker ikke med en Shuttle (eller et fly).
Ja det vil så minimum kræve triple redundans ... den ene cpu siger "undvig til højre" og den anden siger "undvig til venstre" ... hvem skal bilen stole på ? ;)
Realistisk set opstår den slags fejl ikke i hardware lige når det er kritisk at træffe den rigtige beslutning. Problemet vil opstå fordi der er fejl i softwaren. Og det er en helt anden slags problem.
Men skal der være højere kvalitetskrav til elektronikken end til andre dele i en (selvkørende) bil?Og noget lignende vil selvfølgelig aldrig kunne ske i en selvkørende bil?
I selvkørende biler, satellit udstyr osv. sættes der formentligt så store krav til elektronikken, at den ikke slås ud af et ur, som går i stå, eller går forkert.
Problemet er måske elastikken i ordet "formentligt". Og selv hvis der stilles krav, hvem siger så, at de faktisk bliver opfyldt? ("dieselgate" in memoriam).
Jeg er sådan set enig med Christian Nobel i, at vi skal forholde os skeptisk til teknologien. Ikke nødvendigvis sådan, at vi skal afvise den, men måske nærmere sådan, at vi er nødt til at tænke ind i designet af systemer hvad der skal ske, hvis teknologien svigter.
Jeg tror at dette ville være et godt sted at hive Charles Perrow: "Normal accidents" ned fra hylden og genlæse hans betragtninger om tæt og løst koblede systemer. Så ved jeg da hvad aftenen skal gå med (bortset fra madlavning, opvask og løbende opfordringer til husets teenager om at rydde op på sit værelse...)
/Bo
Ifølge denne artikel er det en hel familie af processorer der bruges i en lang række af udstyr - herunder flere af mine maskiner herhjemme.
https://www.theregister.co.uk/2017/02/06/cisco_intel_decline_to_link_product_warning_to_faulty_chip/
EDIT: Det ser faktisk ud til at nVidia's system allerede har en del redundans indbygget, i det at den består af to separate CPU'er i den konfiguration der kan klare autonom kørsel.
Ja det vil så minimum kræve triple redundans ... den ene cpu siger "undvig til højre" og den anden siger "undvig til venstre" ... hvem skal bilen stole på ? ;)
EDIT: Det ser faktisk ud til at nVidia's system allerede har en del redundans indbygget, i det at den består af to separate CPU'er i den konfiguration der kan klare autonom kørsel.
Men hvilken CPU har så ret? Der var en grund til at Space Shuttle havde 5 uafhængige computere! 4 som i bogstaveligste forstand kunne kæmpe imod hinanden, ved hver især og hive i "roret". "Flertallet" vandt! Og hvis de gik ned, var der en 5. med et simplere program, som burde kunne få den ned på jorden igen i hel tilstand!
I dag vil det betyde at en bil udstyret med samme computer som en Tesla, nVidia's DRIVE-PX2, bliver rundt regnet 100.000 kroner dyrere. Indenfor ti år vil det næppe være en fordyrelse på mere end et par tusind kroner.Og hvordan vil det så lige påvirke prisen - mig bekendt er satellit udstyr ikke just billigt.
EDIT: Det ser faktisk ud til at nVidia's system allerede har en del redundans indbygget, i det at den består af to separate CPU'er i den konfiguration der kan klare autonom kørsel. Det lader altså til at være et løst problem, hvis de har opbygget systemet på en fornuftig måde.
Og hvordan vil det så lige påvirke prisen - mig bekendt er satellit udstyr ikke just billigt.I selvkørende biler, satellit udstyr osv. sættes der formentligt så store krav til elektronikken, at den ikke slås ud af et ur, som går i stå, eller går forkert.
I selvkørende biler, satellit udstyr osv. sættes der formentligt så store krav til elektronikken, at den ikke slås ud af et ur, som går i stå, eller går forkert.Det mener jeg faktisk ikke - for læren er at selv nok så gode komponenter kan dø efter relativ kort tid, hvilket, afhængig af situationen, kan resultere i alvorlige følgevirkninger.</p>
<p>Så det jeg egentlig gerne vil mane til, er en skeptisk holdning til de ting vi omgiver os med, og en forståelse for at træerne ikke gror ind i himlen.
Intel prøver tilsyneladende at smålyve om hvor slemt det er (intel: "after multiple years of service", cisco: "18 måneder", intel: "slightly higher expected failure rates") og forbyde deres kunder, at omtale Intel ifm. fejlen.
https://www.theregister.co.uk/2017/02/06/cisco_intel_decline_to_link_product_warning_to_faulty_chip/
Jo, selvfølgelig kan det ske at hardwaren brænder sammen i en selvkørende bil. Eller i en ikke-selvkørende, hvor motor og bremser jo nu om dage som regel er koblet op på en computer.
Det er dog langt mindre sandsynligt end at føreren får et ildebefindende, der efterlader dem ude af stand til sikkert at fremføre deres køretøj.
Det første problem kan løses ved at have en backup computer. Det andet problem er noget mere besværligt. Desuden vil en død CPU i en veldefineret bil blot resultere i at motoren slukker. En motorist med blodprop i hjernen er noget mindre forudsigelig.
Det mener jeg faktisk ikke - for læren er at selv nok så gode komponenter kan dø efter relativ kort tid, hvilket, afhængig af situationen, kan resultere i alvorlige følgevirkninger.Hvor er det dog inderligt ligegyldigt.
Så det jeg egentlig gerne vil mane til, er en skeptisk holdning til de ting vi omgiver os med, og en forståelse for at træerne ikke gror ind i himlen.
Hvor er det dog inderligt ligegyldigt.
Og noget lignende vil selvfølgelig aldrig kunne ske i en selvkørende bil?
"komponenten" er Intels C2000 CPU