For mange år siden, lavede man radiomodtagere med spoler og kondensatorer.
Idag, tager du en signalprocessor, og sætter antennen på indgangen. Herefter lægges kode i.
Ovenstående, er måske lidt overdrevet - men ikke meget. Meget LF stof, går over i signal processorer, eller lægge i microcontrolere. MF stof, går samme vej. HF støj, digitaliseres meget hurtigt, så HF elektronikken reduceres. I mange tilfælde, bruges nye metoder i forhold til på krystalradioens tid, fordi det hele lægges på chips, og antallet af transistorer intet betyder. At således få adskillige "LF" signaler ind, og behandle dem, med advancerede signalprocessorer, betyder næsten intet.
Indenfor power elektronikken, har man for længst erstattet styreelektronikken med en PIC microcontroler. Mulighed for at lægge andet ind, end kun styringen af duty cycle, gør at de egner sig godt til strømforsyninger. Lavere standby-strøm, og advancerede power-up algorithmer, er blandt hvad PIC programmerne kan tilbyde. Selvom de har en begrænset drivkapacitet på deres udgange - kun 20mA, ses ofte at nogle ben kobles sammen, og at de fint kan drive enten en BJT transistor ved at forspænde basis-emitter dioden i spæreretningen, eller ved at direkte styre en MOS. Specielle SMPS chips, er ved at uddø, fordi PIC kredse har lavere standby, bedre og programmerbare algorithmer, kan indeholde andet end kun dutycycle og spændingsregulering, har væld af programmerbare analoge A/D konvertere og komperatorer indbygget osv.
Tendensen er tydeligt: Læg koden i en microcontroler, og ved højere frekvenser programmer en FPGA.
Analog elektronik er en saga blot...
Alligevel, mener jeg det er en meget farlig udvikling, og jeg synes ikke at vi skal satse så ensidigt, selvom udviklingstendenserne lægger op til det. I mange tilfælde, har softwarefolk mistet "jordforbindelsen", og det skal vi gøre noget ved. Kun, hvis de har en hardware uddannelse, er de i stand til, at lave mange programmeringsopgaver i høj kvalitet.
Jeg synes, at vi skal lægge højere vægt på kvalitet og sikkerhed. I langt de fleste tilfælde, underviser man eleverne, så de "bare" skal få noget til at fungere. Men, hvor store er komponent tolerancerne? Hvad sker, hvis en komponent fejler? Er systemet redundant osv? Hvorfor holder nogle konstruktioner godt, meddens andre går hurtigt i stykker? Kan det være korrekt, at komponenterne holder evigt når de ligger i en aflåst metalboks - men går i stykker indenfor nogle år, når de placeres i konstruktionen? Hvad er årsagen, og hvordan løses det? Hvis vi plugger en plyk igennem elektronikken - fungerer den så stadigt sikkert? Vi skal vide noget som sikkerhed, og fejlmekanismerne. Hvorfor hænger et relæ? Er et relæ sikkert at anvende? Hvordan beskyttes elektronik?
Indenfor software, skal det også gøres mere ud af sikkerheden. Idag, er software karakteriseret ved éen ting - og den er næsten uundgåelig: Software fejler. Hvad skal til, for at lave software der svarer enten før, eller til tiden, og ikke for sent. Hvordan bevises det? Hvordan laver vi software, der svarer eksakt til tiden. Sådanne problemstillinger er meget vigtigt indenfor styring og regulation, da tidsparametre kan have betydning indenfor løsningen af mange styre og regulations opgaver. De kan også have betydning indenfor mange andre typer opgaver, fordi at der måske sker et uheld, hvis der ikke kommer et signal i tide, eller på eksakt rette tidspunkt. Softwarefolkene skal kunne løse sådanne problemer - ikke kun så det "statistisk set", nok går godt. Men så det går godt, og går godt hver gang. De skal også have kendskab til redundans, og automatisk fejlkorrigering, så de kan lave sikre systemer, der fungerer uanset ledninger, netkabler osv. klippes over. Og ikke mindst - så skal de vide, hvordan man laver systemer, så problemer løses hvis der opstår hardwarefejl. Det kan være et register der muterer, eller en indstruktionspointer der hopper til forkert addresse.
Softwarefolk tænker meget sjældent på sådanne forhold, fordi de ikke har kendskab til hardware. De mangler forståelsen for, hvad der skal til, for at sikre et produkt ikke fejler, og ikke kan fejle. Der er ikke taget højde for, at der går noget galt, og at en bit står forkert. Eller, måske at indstruktionspointeren, pludseligt kører progammet, der er på en helt forkert addresse.
Ingeniørerne skal lære at tænke på, hvor fejl kan opstå, og hvad der skal ske når de opstår. De skal lære, at kunne opskrive algorithmer og metoder, og placerer computerne på en måde, således der automatisk tages hånd om fejlhåndteringer, og at de kun går til mennesker, når nødvendigt - så man ikke bliver overbebyrdet, af alle mulige fejl, som ikke kan løses automatisk, og ikke er vigtige i en snæver situtation. Til gengæld, skal man også sikre sig, at den automatiske fejlretning og løsning, går efter bogen, og sikre sig at en sådan bog findes. Og det er altid nødvendigt, at "logge" den, så man ikke har elektronik og software, der står og retter fejl hele tiden, fordi at fejl er gjort til en integreret del af dets desgin... Det er naturligvis ikke lovligt.
At kunne lave software, der svarer til tiden, er vigtigt, for eksempel indenfor microcontrolere. Her kan være vigtigt, at både kunne udvikle interrupt styret software, der har garanteret svartid, og software, der svarer eksakt til tiden. I nogle tilfælde, kan dette medføre at der tælles cycles, og tages hensyn til processorens hardware, timere ol. Det kan også kræve, at man har en teoretisk baggrund, så man kan prioritere interrupts, og finde ud af hvordan en løsning skal løses. Det er vigtigt, at kunne håndtere problemer, hvis en microcontroler pludseligt hænger, eller hopper til en forkert addresse, hvis ram eller registre muterer osv. Og, for enhver skyld, kunne lave hardware og software, så det med at første løsningsmetode er at genstarte, ikke er brugbart.
Også ved protokoller, ses at sikkerhed måske mangler - man har ikke tænkt sig grundigt om, og det kan betyde at opstartsrækkefølgen måske betyder noget. Igen, er det et eksempel på, at softwarefolk skal lære at tænke i sikkerhed.
Mange softwarefolk, starter med at beslutte hvilket programmeringssprog der skal anvendes. I mange tilfælde, besluttes det udfra religiøse årsager, der reelt mere beskriver, hvad de er gode til, end hvad der faktisk er egnet for opgaven. I stedet for, at bare kunne remse et sprogs fordele op, er meget vigtigt, at også have begreb om dets ulemper - da disse måske er dem, der reelt gør at sproget IKKE bør bruges. Ulemperne, er altså oftest mere vigtige end fordelene.
Programmører, bør måske ligefrem eksamineres i deres yndlingsprogrammringssprogs ulemper, så de ved hvad der er fordele og ulemper, og specielt kender sprogenes og hardwarens ulemper, så de kan vælge den rette måde at løse en opgave. Måske er det ikke den velkendte PC med Linux platform, der er den rette.
Jeg synes, at vi har brug for softwarefolk, der er mere tæt på jorden, end de klasiske PC softwarefolk. Det betyder ikke, at man kan have nogle "upålidelige" kodere, til at skrive nogle PC-programmer, eller java koder, der giver mulighed for at en PC kan bruges til at logge på et indstrument. Men, hvis man gør det, skal sikkerheden overvejes. Det skal overvejes, om man - hvis PC'en ikke virker - så har mulighed for at logge på med en anden PC. Og om at programmet virker, med et andet operativsystem, således at man også har denne mulighed, hvis man ikke kan få adgang. Og endeligt, om det er sikkert nok, at man ikke kan være 100% sikker. PC'er, behøver ikke altid at være udelukket. Visse steder kan de bruges. Men ofte, kun steder, hvor man har en reserve PC, måske med et andet operativsystem, til at stå parat til at løse situationen, i en snæver vending. Og så skal det naturligvis kunne accepteres, den tid, at det tager. Måske sammenholdt med, hvor stor sandsynligheden er, for at problemet opstår.
Det som jeg synes, er at vi skal uddanne danske ingeniører, til at tænke i sikkerhed. Man skal kunne bevise at sin software svarer til tiden, og man skal kunne dokumentere, at man har tænkt på fejlsituationerne. Ikke kun i softwaren, men også hvis computeren fejler, operativsystemet fejler, netværket fejler, og andet opstår, som der ikke er udenfor sit program.
I forbindelse med svartider, er det meget vigtigt at have begreb om algorithmer og deres kompleksitet. Om ram forbrug, og at kunne bevise der ikke er memory leaks. At kunne sikre, der ikke swappes ud på en harddisk, og ellers bevise - trods det - at svartiden er med garanti indenfor de fastsatte grænser. Worst case, er worst case, og ikke "average" worst case, eller andre selvopfundne begreber.
Indenfor softwareområdet, er teknisk dokumentation, såsom at dokumentere hvor lang tid at en operation tager, meget sjældent gjort. Ofte bruges applikationer og software fra 3. part, der ikke leverer sådanne data. Det er vigtigt, at softwarefolk forstår, at de så ikke kan bruge sådanne applikationer, med mindre de selv står inde for deres svartid, og det er jo teknisk set umuligt, da at producenten ikke står inde for det. Det, som kan måles er "average" worst case svartider, og de har intet med worst case at gøre. Tingene, skal være designet til at fungere - ikke "gættes" at fungere. Dette kan i nogle tilfælde, også medføre der skal anvendes sprog, og automatiske metoder, til at kunne lave den type dokumentationer.
Når vi så har fået indøvet evnen, til at kunne lave kvalitet, så kan vi begynde at se på "detaljer" som programmering af FPGA'er, microcontrolere osv. Jeg synes, at det er en god idé, at have nogle øvelser med microcontrolere, og programmering - specielt i maskinkode - fordi man så får lidt jordnær forståelse for, hvad der foregår internt i en computer.
Elektronik, komponenter, og hvad der "slider" på komponenter, synes jeg også er vigtigt at have kendskab til, for at kunne udvikle elektronik af høj sikkerhed. Men der er ingen tvivl om, at mange typer opgaver flyttes til digital elektronik, og programmering, og at det er vigtige områder at beherske. Skal man udvikle elektronik, er det dog meget vigtigt, at også have komponentforståelse.
Jeg ved ikke rigtigt, hvad jeg skal mene om den traditionelle undervisning i software og software design. I elektronikmæssigt sammenhæng, synes jeg stadigt, at softwarefolk ofte mangler sans for, at når de laver noget, skal det bygges på komponenter der fungerer - og som ikke bare "statistisk" set fungerer godt. De mangler ofte dokumentationer for resourceforbrug, ram forbrug, beviser for at der ikke er memory leaks, og beviser for, hvor stor svartid som er. Dette er nødvendigt, i næsten alle hardwarenære sammenhæng - og også i mange andre - da traditionen tro, så vil et program der ikke kan bevises svarer indenfor rimelig tid, hellerikke komme med et svar, uanset funktionen er bevisbar. Vi ser ofte, at der er tidsmæssige problemer på PC'er, såsom musen rykker, software staller og trækker andet med osv. Og der kan være ting der er designet forkert, og medfører andre tråde staller. Alle disse problemer, må ikke forekomme. Det er nødvendigt, at softwarefolk, lærer at være mere kritiske, og ikke accepterer alt som "godt", uanset det tydeligvis fejler, og er ubrugeligt.
Hvad nytter det, at softwarefolk lærer - og består alt om design - når de ikke er kritiske nok, til er erkende en "halv" gif, som en fejl? Eller en svartid på over 20 sekunder, hvor tråden ikke måtte være blokeret, og skulle svare til tiden? Softwarefolk, skal have optrænet deres kritiske sans. Det tror jeg, er mere vigtigt, end alverdens software design fag. Når de så har optrænet kritisk sans, kan de måske også bedre bruge de metoder de lærer. Eller, kritisere dem, hvis de ikke er brugbare.
Metoden, at få ting til at fungere på, er at bygge det på noget som fungerer. Kan dette ikke garanteres, så stopper man, og starter forfra. Ikke noget med, at bare "erkende" at vi jo ikke kan finde alle fejl. Så er det forfra og forfra og om igen. Indtil, at man har en sokkel, som kan holde. Det er lykkedes indnenfor alle andre ingeniørvidenskaber end software. Fordi, at man har vidst, at soklen skal kunne holde. Man farer ikke bare derudaf, før at problemerne er løste. I startet, bygges systematisk op, og i nogle tilfælde, tager det mange år, fordi at man netop skal have noget der dur.
Så kan vi så have noget upålidelig smart-software, der bruges i PC sammenhæng, og hvor pålidelighed ikke betyder en dyt. Men, egentligt, er denne software stort set urelevant, for ingeniøren. Ingeniører, har brug for ting der dur - uanset, vi så skal nøjes med grøn skærm, og en grænseflade fra 70'erne.
88
