Ideen om at man kan lave det hele computerstyret og science-fiction-agtigt er selvfølgelig "den danske stil" og alt det der, men faktum er at den slags ikke virker ordentligt.
På en måde gør det lidt ondt i mig - jeg mener nemligt, at det må være en spændende opgave, at lave softwaren og hardwaren, så det faktisk fungerer. Og opgaven, er ikke uoverskueligt, og indeholder bunker af features, så det er ikke noget om, at det er en voldsom software opgave. Det at gøre opgaven mindre, gør ikke opgaven nemmere - for det som er det interessante - men også problemet - ved en sådan opgave, er at kunne gøre det sikkert og godt. Og, hvis du har nogle (undskyld) uduelige softwarefolk, så vil du ikke kunne opnå, at de kan det, uanset hvor simpel at opgaven er. Giver du dem en meget simpel opgave, som at aflæse en kontakt, og tænde en lampe hvis kontakten er tændt - så kan de ganske enkelt ikke løse opgaven. Hvorfor? Fordi, at de ikke ved, at de af sikkerhedsmæssige årsager skal bruge en kontakt der kan stå i to stillinger (on, off), og hvor begge kan aflæses, for at sikre at kontakten fungerer. Hvis kun den ene stilling kan aflæses, så vil en løs ledning, eller en dårlig kontakt, ikke afsløres. Det er også vigtigt at vide, at ingen mekanisk kontakt skifter fra off, til on - og modsat momentant, men har såvel skiftetid, som prel, og at tage hensyn til dette, uden det medfører data logges i fejlfiler. Og endeligt er vigtigt, at vide at kommunikationen på en linie teoretisk kan forstyres af støj - trods det er sjælden. Man skal have styr på dette, og gensende enhver ordre der ikke forstås straks - i princippet skal du kan fjerne netforbindelsen, og sætte den på igen, og så skal det fungere når den sættes på. At det skal dette, er nok logik for burhøns, og de fleste elektrikkere vil synes det er underligt, hvis de tager en ledning af, og sætter den på igen, at lyset så ikke mere skulle fungere. Men, bruger du dårlige programmører, er ikke sikkert at de håndterer den slags. Måske skriver de en fejlmelding ud, dumper et image, og får det totale system til at gå ned. Endeligt, er vigtigt, at ikke overbebyrde med warnings og fejlmeldinger, så der hele tiden skrives ud, hvis der er en lille fejl, f.eks. at det er nødvendigt at gensende en ordre, fordi der er støj - ingen gidder at læse dette alligvel, og det giver indtryk af, at noget som fungerer som det skal ikke fungerer. Derimod, er vigtigt at "notere" det, og f.eks. angive det på en statistik - og der kan eventuelt være en skjult log, hvor en teknikker kan hente de seneste forekomster af hver fejltype, hvor det kan ses med klokslet hvornår det er sket. Sker flere fejl, umiddelbart efter hinanden, er ofte en idé, at slå dem sammen, så logfilen ikke "spammes", men at det bare noteres, at der er opstået så mange fejl umiddelbart efter hinanden, med få millisekunders mellemrum. Dertil kommer, at man skal have en pålidelig computer, der ikke går ned. Dette kan løses på mange måder. Hvis den går ned, skal det naturligvis "logges", så man har kendskab til det, under de normale regler (uden at spamme). Og, den skal have en hurtig oppetid, efter en eventuel "hang-up". Typisk, vil man som minimum hardwaremæssigt have en timer, der er lavet til at være enormt stabil, og ikke fejler (kan ikke have hang-up tilstande selv), en såkaldt watch-dog timer. Ikke alle watch-dog timere er af god kvalitet, da nogle udbydere ikke forstår funktionen, og tror den er en general applikation timer der typisk bruges til at vågne computeren fra sleep tilstand, og ikke forstår det som en vigtig sikkerhedsmæssig komponent. Skal den brugs som watch-dog, skal den dog være sikker, og den må ikke pludseligt kunne hænge, eller indeholde en bit, der tilfældigvis kan disable den. Watch-dog timeren, får en "godkend" ordre fra softwaren, der indikerer at alt softwaren fungerer og er ok, og det er softwarens opgave at sikre, at "ok" tilstanden kun gives, når dette er sikker. Man må ikke lave en process, der bare siger ok uafbrudt til watch-dog timeren, så vi er af med det problem, selvom det måske er fristende... Sker en fejl, vil watch-dog timeren, udføre en fysisk reset af CPU'en og systemet, således det efter få millisekunder er oppe igen: Ikke noget med et tungt operativsystem, der ikke klarer dette hurtigt. For så må du leve uden computer, i meget lang tid, og det er ikke godt, hvis det du laver er bare en smule kritisk. Naturligvis, er det også en fejlhændelse der skal logges med tidspunkt osv. i den sædvanlige logfil, for at du kan se om der er en fysisk årsag til problemet, eller om noget er galt. Det må ikke ske, hvis vi ikke kan finde en fysisk årsag. Watch-dog timere, og anden "fejljhåndtering", må ikke være en del af funktionen, således det er nødvendigt for at det fungere - men det er kun en sikkerhed, som kun må og skal være der, hvis noget går galt, og vi er tvungen til at undersøge om noget rimeligt har været årsag til funktionen er aktiveret. Typisk, vil side en kontakt, der også registrerer om dækslet åbnes ind til elektronikken, så det kan sammenholdes med det. Når computeren genstartes efter watch-dog timeren har reset den, skal vi forvente at der kan være opstået fejl - så de tilstande, der "overleveres" og som vi stadigt skal bruge, skal være fejltollerante. Typisk, vil vi altid gemme alle data på en fejlsikker måde, således der gemmes ekstra bits, der gør at vi kan fejlrette data. I så fald, behøver vi ikke at foretage os noget vildt. For alt, gælder at hvis vi opdager en fejl i en register, på data fra ram osv. så gælder de sædvanlige regler til logning.
Alle disse ting, er almindeligt, bare for at tænde/slukke en lampe, på baggrund af en omskifter der er on/off. Dertil kommer, at man skal have en pålidelig computer, der "ikke går ned". Og alt vores programmerede knowhow, aldrig bruges. Ikke noget med at bruge en "ustabil" computer, der gør at fejl rettes et par gange i sekundet, og som på grund af vores fantastiske software faktisk fungerer. Der må aldrig komme en fejl, og logfilen skal være tom. Er der data i, kan vi eventuelt tænde en lampe, så man kan se der er sket en fejl, og man bør tilkalde service straks. Logfilerne, vil så blive undersøgt, og man vil tage stilling til, hvad det skal gøres. Måske skyldes det noget kendt, f.eks. en elektrikker, eller anden, der har midlertidigt fjernet ledningen til infodisplayet, eller toiletkontakten. Eller det skyldes en meget sjælden årsag, vi ikke vil tage hensyn til, såsom direkte lynnedslag i toget, og vi accepterer at elektronikken kun retter fejl i det pågældende tilfælde på datanet og andet, der går rundt i toget.
Som ses, kræves en vis knowhow, bare for at aflæse en toiletkontakt - og det gælder præcis det samme, med enhver anden kontakt.
Derfor, er opgaven reelt ikke væsentligt større, selvom vi både har et infodisplay, passagersystem osv.
Det, som går galt, er at dem der koder det, end ikke kan lave en aflæsning korrekt af en toilet kontakt. Og så har de hellerikke kunnen nok, til at kunne lave det andet.
Normalt, er den type opgaver, også med data for svartider - og det betyder, at du skal have styr på din kode, og på dens svartid. I nogle tilfælde, kan anvendes specielle programmeringssprog, der kan garantere svartiden for din kode. Men, under alle omstændigheder, skal det kodes, så svartiden er under kontrol. Og der kan ikke anvendes kode fra en dårlig programmør, der ikke har styr på sit ram forbrug, og sine svartider. Alle, dokumenter sådanne vigtige karakteristika for alle deres objekter/funktionsblokke, således de andre som bruger dem, også har styr på deres timing når de ser data på modulerne/komponenterne.
Og til sidst - men ikke mindst - kræves også en vis logik. F.eks. kan jeg ikke bruge en programmør, som ikke forstår at problemerne skal løses så der sikres at A+B = B + A, hvis det er et rimeligt krav at sætte til operatoren "+". Det er så uanset, om det er prisudregninger på strækninger, eller andet. Problemstillinger, af den slags, som selv børn forstår, skal en programmør beside evner til at forstå. Og de skal kunne analysere, om deres algorithmer gør noget forkert, og ikke bare kode. Er der et problem, skal det klares helst inden det kodes. Måske, er problemet, at der ganske enkelt er noget, man ikke har forstået, eller fejl i opgavens formulering. Og så skal man have det på plads, så man får skrifteligt at det skal være "ulogisk", fra dem der har lavet opgaven, så de tager det fulde ansvar og står inde for at det fungerer på den pågældende måde. Og, måske skal man sende det endnu videre i systemet, hvis man mener det er forkert.
Så det at kode en toiletkontakt, er ikke nødvendigvis enkelt. I togsammenhæng, er krav til, at enhver ledning der "kappes" oftest skal detekteres. Ofte, overvåges også ledningsmodstande, således man kan detektere kontakter og ledninger, der er beskadiet. Dette bør også være med i vores aftastning af toiletventilen. Hardwaren, der kan måle modstande, er forholdsvis billigt, da de fleste microcontrolere idag er forsynet med præcise A/D konvertere. Typisk, vil man også "måle" på modstand i relæer, og lamper, for at sikre deres funktion og holde kontrol med ælde eller eventuelt beskadielse. Men, det kræves jo også, at de kodes, så de opdager problemer med modstand i ledninger.
Kan du først kode toiletkontakten og toiletventilen ordentligt, tror jeg først på, at du kan kode det samlede infosystem. Her gælder omtrent samme regler, for overvågning af ledninger, modstand, om de kappes/sættes på igen, fejl på transmissionen, og fejltollerante registre i såvel infodisplayet, som i styrecomputeren, samt verifikation af, at det faktisk står det som skal. Man skal altid "verificere" at det man har kontakt med fra hovedcomputeren fungerer som det skal, og ellers udsende ordrene igen, så fejlene rettes, og det logges. Uanset, om det er et relæ (ved at tjekke på både on/off kontakten), eller om det er display (ved at tjekke som minimum checksum på samtlige segmenter, eller lignende).
Det er ganske simple regler, som bare gælder, og hvor man også skal tjekke at det er gjort, f.eks. ved at ændre bits, indføre fejl i kommunikation mv. Fejl i kommunikation, sker normalt samlet (i byger), og det skal et system altid håndtere.
Min opfattelse er, at hvis du kan kode aflæsning af en kontakt, samt styring af en indikator, og tager hensyn til alt du skal tage højde for, og gør det korrekt - så er du en god programmør der sandsynligvis kan løse hele opgaven. Det, at kode en advanceret opgave, er ikke væsentligt sværre, end at styre en toilet kontakt. Men, åbentbart er problem at finde programmører som kan styre en lampe, på baggrund af en kontakt, og ikke mindst gøre det korrekt, så det lever op til vores krav om verifikation, fejlretning, sikkerhed og logning. Og, naturligvis, skal det kunne gennemgå et tjek, der viser at softwaren faktisk fungerer som det skal, f.eks. hvis modstande ændres, ledninger afbrydes/sættes sammen, fejl introduceres i byger, og endog at der indføres fejl i programmet kortvarrigt, hvor indstruktionspointeren hopper af helvede til i kort tid, eller går i uendelig løkke, eller registre muterer, og sikre at systemet kører trods det, og laver korrekt logning. Ofte, vil man endog studere programmet, med henblik på at finde worst-case omstændigheder.
Kan du løse toiletlampen så ovenstående opfyldes, så vil du med stor sandsynlighed kunne løse togopgaven. Er du typen, som starter med at sige, at det behøves da ikke, så må du holde dig til Linux, og C, eller HTML. Ikke fordi, at det ikke er noget. Det er da også noget, at kunne XML.
2
