Hur lär man sig "grundlläggande / avancerad elkunskap för villaägare"?

[G.L.]

Grundläggande kunskapen som behövs är vad denne får göra själv enligt ellagen. All information finns på elsäkerhetsverkets hemsida. Sen kan man liksom bilförare strunta i lagar, köra för fort eller mot rött och rättfärdiga beteendet med allehanda argument som ej har lagligt stöd

 

[blackarrow]

Grundläggande kunskapen som behövs är vad denne får göra själv enligt ellagen. All information finns på elsäkerhetsverkets hemsida. Sen kan man liksom bilförare strunta i lagar, köra för fort eller mot rött och rättfärdiga beteendet med allehanda argument som ej har lagligt stöd

Jag brukar tycka att jämförelser med bilar aldrig blir bra, men här kanske det fungerar.
Vad ska vi göra åt alla som kör bil utan körkort, som inte kör mot rött, som inte bryter mot trafikregler, som inte ställer till med olyckor, och som aldrig åker fast??
Detta är allvarligt.
Låt oss starta en kampanj.

Men hur stort är problemet?

P.S. Ellagen (SFS 1997:857) reglerar produktion, överföring och användning av el. Lagen ser till att elförsörjningen är säker och effektiv, och den styr hur elnätsföretag och elhandelsföretag får arbeta gentemot varandra och konsumenterna.

 

[lars_stefan_axelsson]

Ja, det kan bli mycket värre konsekvenser om man skriver lite kod fel, som de som programmerade Ariane 5-raketen som exploderade vid uppskjutningen. Det berodde på att programmerarna inte hanterade integer overflow på ett ställe i programkoden (det fanns fler fel, men det var antagligen det allvarligaste) så programmet kraschade varpå även raketen kraschade.
Det kostade, enligt uppgift 370 miljoner USD.

Eftersom den nu sammanfattats två gånger, och lite fel (eller ja, kanske inte formellt fel, men ändå) så kanske jag tillåts att såhär off topic lägga ut texten lite om precis vad som gick fel, eftersom det är lite intressant. Och min examinator när jag började min doktorandutbildning var chefsarkitekt för styrdatorn i Ariane 5 och var på plats när den small, så jag har lite koppling till händelsen. *

Man hade ett kostnadsproblem iom utvecklingen av Ariane 5 iom att man såg att projektet skulle bli mycket dyrt. Så man beslutade att spara in på verifieringen av delsystem som redan flugit på Ariane 4 eftersom man ansåg att dessa då borde vara felfria. Dels så hade de redan blivit verifierade men även faktiskt flugit framgångsrikt många gånger. Så man kan ju inte bli tryggare än så på att grejjorna kommer att fungera, eller?

Men se, så lätt är det inte. Vi skall inte gå in på precis alla detaljer i tröghetsnavigeringssystemet och dess tröghetsreferensplattform (även om det faktiskt är intressant och ledde till ytterligare ett fel **) mer än att säga att den exekverade kod som håller reda på var raketen är och hur den rör sig.

Problemet var att datorkraften inte räckte till för att köra Ada-koden direkt från kompilatorn. Ada har fördelen att typer och vilka värden de kan ta är mycket väl definerade och "overflow" och liknande kan inte inträffa under körning, åtminstone inte utan att ett fel registreras och särskild felhanterande kod anropas. Men det visade sig som sagt att i den inre loopen så kostade alla dessa kontroller för mycket tid. Man hann helt enkelt inte med. Så man gjorde en formell analys av vilka värden som kunde förekomma under normala (och relevanta abnormala) driftfall och visade att det inte skulle kunna bli några problem. Alla värden skulle "få plats" och beräknas korrekt. Så man tog bort de, bevisat överflödiga, kontrollerna och då hanns allt med.

Men så stoppade man samma plattform med dator och kod i Ariane 5 utan att ta med i beräkningen att det är en större raket. Som går fortare... Även hastigheten i x-led, dvs räknat jäms med jordytan blir större än för Ariane 4, som var mindre och långsammare.

Hastigheten blev så stor att den inte fick plats, beräkningen flödade över, programmet hamnade i ett ohanterat fel-läge, och navigationsdatorn startade om och lade ut ett testvärde på bussen. Ett värde som styrdatorn tolkade som ett kommando att vrida motorerna så långt åt sidan det gick. Med följd att raketen kantrade, de aerodynamiska lasterna på raketkroppen blev för stora, och självförstörelsesystemet utlöstes automatiskt när raketen via trådtöjningsgivare noterade att den överbelastats. (Man tryckte även på knappen i kontrollrummet, men var, om jag inte missminner mig en sekund långsammare.)

Så vad lär man sig av det här? Jo, även om något fungerat perfekt förut så behöver det inte fortsätta göra det om omgivningen man har erfarenhet av förändras. I det här fallet så var allt korrekt för Ariane 4 och dess envelop, och det hade man tom koll på och hade räknat på. Så det var inte slarv eller ett förbiseende. Men därmed inte sagt att det skulle fortsätta fungera när förhållandena ändrades.

Så då fastnar man i rävsaxen. Antingen så dokumenterar man var enda litet antagande som ligger till grund för konstruktionen och kollar att de fortfarande håller. Det leder till ett byråkratiskt helvete av sällan skådat slag, och man kommer fortfarande att missa den lilla detaljen som stjälper hela lasset eftersom ingen kommer att dokumentera precis varenda liten "självklarhet".

Eller så testar man allt igen. Vilket är dyyyyrt...

Idag så har vi valt den senare lösningen. Om man kan kalla det "lösning". Eller, vilket är vanligare, så håller man tummen och hoppas att det går ändå och tar smällen om den kommer.


*) Den fiskades upp ur ett träsk efter smällen, och flögs med träskvatten och allt till Göteborg, där den testades, och den startade och fungerade alldeles utmärkt.

**) Som lök på laxen så visade det sig att den faktiskt inte hade behövt köra i Ariane 5 på samma sätt som i Ariane 4 eftersom arkitekturen och det sättet man navigerade på hade ändrats. Så man föll på att en grej som man ändå inte behövde, havererade.

 

[Hannuse]

Eftersom den nu sammanfattats två gånger, och lite fel (eller ja, kanske inte formellt fel, men ändå) så kanske jag tillåts att såhär off topic lägga ut texten lite om precis vad som gick fel, eftersom det är lite intressant. Och min examinator när jag började min doktorandutbildning var chefsarkitekt för styrdatorn i Ariane 5 och var på plats när den small, så jag har lite koppling till händelsen. *

Man hade ett kostnadsproblem iom utvecklingen av Ariane 5 iom att man såg att projektet skulle bli mycket dyrt. Så man beslutade att spara in på verifieringen av delsystem som redan flugit på Ariane 4 eftersom man ansåg att dessa då borde vara felfria. Dels så hade de redan blivit verifierade men även faktiskt flugit framgångsrikt många gånger. Så man kan ju inte bli tryggare än så på att grejjorna kommer att fungera, eller?

Men se, så lätt är det inte. Vi skall inte gå in på precis alla detaljer i tröghetsnavigeringssystemet och dess tröghetsreferensplattform (även om det faktiskt är intressant och ledde till ytterligare ett fel **) mer än att säga att den exekverade kod som håller reda på var raketen är och hur den rör sig.

Problemet var att datorkraften inte räckte till för att köra Ada-koden direkt från kompilatorn. Ada har fördelen att typer och vilka värden de kan ta är mycket väl definerade och "overflow" och liknande kan inte inträffa under körning, åtminstone inte utan att ett fel registreras och särskild felhanterande kod anropas. Men det visade sig som sagt att i den inre loopen så kostade alla dessa kontroller för mycket tid. Man hann helt enkelt inte med. Så man gjorde en formell analys av vilka värden som kunde förekomma under normala (och relevanta abnormala) driftfall och visade att det inte skulle kunna bli några problem. Alla värden skulle "få plats" och beräknas korrekt. Så man tog bort de, bevisat överflödiga, kontrollerna och då hanns allt med.

Men så stoppade man samma plattform med dator och kod i Ariane 5 utan att ta med i beräkningen att det är en större raket. Som går fortare... Även hastigheten i x-led, dvs räknat jäms med jordytan blir större än för Ariane 4, som var mindre och långsammare.

Hastigheten blev så stor att den inte fick plats, beräkningen flödade över, programmet hamnade i ett ohanterat fel-läge, och navigationsdatorn startade om och lade ut ett testvärde på bussen. Ett värde som styrdatorn tolkade som ett kommando att vrida motorerna så långt åt sidan det gick. Med följd att raketen kantrade, de aerodynamiska lasterna på raketkroppen blev för stora, och självförstörelsesystemet utlöstes automatiskt när raketen via trådtöjningsgivare noterade att den överbelastats. (Man tryckte även på knappen i kontrollrummet, men var, om jag inte missminner mig en sekund långsammare.)

Så vad lär man sig av det här? Jo, även om något fungerat perfekt förut så behöver det inte fortsätta göra det om omgivningen man har erfarenhet av förändras. I det här fallet så var allt korrekt för Ariane 4 och dess envelop, och det hade man tom koll på och hade räknat på. Så det var inte slarv eller ett förbiseende. Men därmed inte sagt att det skulle fortsätta fungera när förhållandena ändrades.

Så då fastnar man i rävsaxen. Antingen så dokumenterar man var enda litet antagande som ligger till grund för konstruktionen och kollar att de fortfarande håller. Det leder till ett byråkratiskt helvete av sällan skådat slag, och man kommer fortfarande att missa den lilla detaljen som stjälper hela lasset eftersom ingen kommer att dokumentera precis varenda liten "självklarhet".

Eller så testar man allt igen. Vilket är dyyyyrt...

Idag så har vi valt den senare lösningen. Om man kan kalla det "lösning". Eller, vilket är vanligare, så håller man tummen och hoppas att det går ändå och tar smällen om den kommer.


*) Den fiskades upp ur ett träsk efter smällen, och flögs med träskvatten och allt till Göteborg, där den testades, och den startade och fungerade alldeles utmärkt.

**) Som lök på laxen så visade det sig att den faktiskt inte hade behövt köra i Ariane 5 på samma sätt som i Ariane 4 eftersom arkitekturen och det sättet man navigerade på hade ändrats. Så man föll på att en grej som man ändå inte behövde, havererade.

Man skulle ändå ha velat vara med på efterföljande fikarast 🙃

 

[pmd]

Jag vet inte om jag helt tycker att Sveriges system är så dåligt (likvärdigt i Tyskland, Österike, Norge också tex), i dom länder där det är fritt att koppla själv ställs ofta ganska tuffa besiktningskrav för att få ta anläggningen i bruk.

Det kanske vi borde ha i Sverige också, oberoende av vem som gjort installationen?

 

[Liljeros]

Det kanske vi borde ha i Sverige också, oberoende av vem som gjort installationen?

Ja ibland så kanske det vore det, alla fall efter större arbeten innan anslutning. Bara att upprätta ett underlag som plomberas, oklart av vem…

 

[Christer G.V.]

Anledningen till att specifik litteratur eller kurser saknas är ju att det helt enkelt inte är tillåtet.

Vad man sen väljer att göra är en annan sak. Antingen går du få Nösta nivå av böcker annars är nog nätet bättre.

Jag gick en kvällskurs på 80-talet som utmynnade ngt som hette begränsad behörighet. Finns kanske inte längre men bestod av el-lära matte och viss praktik. Väldigt bra kurs.