Svenska ElektronikForumet

Jag har en fråga som jag har undrat över i några år

Först lite bakgrund:
Jag jobbade för några år sedan på ett föreag som tog fram ett vinterfordon ämnat åt att gå i snö på fjället och i skogen.
Elen som skulle finnas var huvudstrålkastare, bakljus, bromsljus, backspegel-värme, gas-reglering, on/off-hydraulventiler, start-motor och start-spärr. De fanns ett antal knappar som skulle användas för input och det fanns instrument som skulle ge feed-back om status på diverse olika saker(bränslemängd, ljus-indikeringar, motor-temp mm).
Det skulle alltså vara en elektronik-box som styrde det mesta.

Jag hade väll ganska nyss börjat intressera mig för elektronik då, jag jobbade med något helt annat där och var inte involverad i elektroniken över huvudtaget. Men jag hade just(på min fritid) lyckats blinka någon LED med hjälp av AVR så jag var väldigt intresserad av hur elektonik-delen på fordonet skulle bli. Jag räknade lite ingångar på min Atmega168 och tänkte att det borde faktiskt räcka med en sådan för själva styrningen och sedan lite kring-komponenter som OP-förstärkare, ström-matningar, reläer mm.

Nåväl, elektronik-box inklusive kablage lades ut på en annan firma och efter en del väntan så kom grejerna. Det var då jag blev MYCKET förvånad!
Det kom elektronik-lådor som var ca 20 x 30 x 5 cm. Dessa var INTE vattentäta. Inuti satt det kretskort som var ca 18 x 28 cm med verkligen massor med komponenter på. Jag hade trott att det skulle komma en liten förseglad box på max ca 10 x 15 x 3 cm eller nått.
Nyfiken som jag var så sökte jag på kortet efter något som kunde vara en micro-processor eller liknande...men hittade inget i den stilen. Blev så förbryllad att jag lite försynt blev tvungen att fråga högre upp i företaget var styrande processorn satt. Svaret blev ”Det finns ingen, allt är uppbyggt med olika halvledar-kretsar och är därför i princip analogt”. Jag fick stora ögon och frågade varför man hade gjort så. Svaret blev att det var mycket bättre och säkrare, inga mjukvaror som hänger upp sig eller nått. Jag tackade för svaren och gick tillbaka till mina ordinarie arbets-uppgifter. Jag var helt ställd och förstod inte hur det kunde bli bättre så, än att göra ett kort men en prosessor och några kring-komponeter som är lätt att gjuta in eller sätta i en liten vatten-tät box för att skydda mot vatten.
Tror även att det blev mycket dyr elektronik både för utvecklingen och tillverkningen. Den krånglade en hel del också pga just vatten och snö i el-boxen.

Jag visste inte så mycket om elektronik på den tiden men har ju sedan dess, tack vare mitt intresse och min envishet i kombination all hjälp jag fått från er på detta fantastiska forum, lärt mig en hel del(även om jag fortfarande ser mig själv som väldigt okunnig på området).

Nu äntligen till min fråga: Varför väljer man ett stort analogt kort i en icke vattentät låda framför ett kort med en uC i det läget?

Svaren jag har hittills är:
Det är drift-säkrare om det är analogt
Det är bättre utan någon mjukvara som kan hänga upp sig

Jag tycker att det känns som konstiga förklaringar till att välja en sådan lösning. Vad tycker ni som håller på med sånt här? Varför gör man så i så fall?

Man slipper utveckla och testa mjukvara. Fast man låser sig samtidigt vad boxen klarat.

Det kan finnas många anledningar och kombinationer av dom:
* Utvecklaren var inte en µC-person.
* En dedikerat lösning ger en ny dedikerat lösning vid ändring = ny utveckling.
* Mjukvara tar tid att utveckla - men ännu längre tid att testa i alla lägen.

Den bristande vattentäthet och storleksproblemet visar att beställningsunderlaget var bristfälligt!

Det är ju inte helt trivialt att bara koppla in en knapp till en uC heller, särskilt inte i ett fordon där man antagligen har en hel del störningar.

Jag kan tänka mig att själva logiken var relativt simpel, i en uC hade det kanske blivit ett par dussin rader kod. Men avstörningar och signalanpassning hade blivit så pass stort att det inte lönat sig.

Visst man kan skriva ett par NAND-funktioner i en uC, men det är betydligt enklare att ta en 7400.

Aha, ja ni har en del poänger där. En sak som jag tyckte var lite konstigt var att lysen skulle styras av boxen. Alltså:
Hel/halv-ljus som styrdes med en knapp
Bakljusen som lyste när tändningen var på
Broms-ljusen som skulle lysa när man bromsade

Till hel och halv-ljus satt någon typ av FET istället för relä, strömmen till lyset gick alltså genom kortet. En kopparbana brann av och lyset slocknade efter en stund.

Om man nu vill göra en elektronik som är driftsäkrare och bättre än en uC-lösning, varför envisas man då med att även dra lysen genom elektronik-boxen?

Kan det vara så att specen var oerhört bristfällig och att företaget som tog fram elektroniken ville att det skulle bli så mycket jobb som möjligt?

Ni är inne lite på att mjukvaran tar tid att utveckla, är det inte svårt och tar tid att få det att fungera analogt också?
Vill minnas att gasregleringen hade någon typ av fördröjning eller dämpning som vi justerade genom att byta en SMD-kondensator på kortet. Jag tyckte hela tiden att det borde varit lättare att finjustera om man haft en uC som styrde fördröjningen.

Jag är ju egentligen inte ute efter något särskilt utan var mest nyfiken på om det ofta är så när elektronik utvecklas. Jag har grubblat mycket på detta, just VARFÖR?

Minns att även nödstoppen gick genom boxen och en gång när det blev vatten i boxen så varvade motorn upp till över halvgas(gasen styrdes av boxen) nödstoppen slutade fungera samtidigt. Eftersom transmissionen hade automat-låda så var det bromsarna som fick plågas till det yttersta för att få stopp(växla gick bara när man stod stilla). Tror man ryckte en kontakt för att motorn skulle stanna. Jag hade på eget bevåg satt en extra nödstopp på fordonet som jag körde eftersom jag inte litade på nödstoppen som gick genom boxen. Min nödstopp var helt enkelt en knapp på ledningen till bränslepumpen. Jag kunde ganska klart säga "Va vare ja sa?" efter det

Känns som att något var ganska bristfälligt i kommunikation mellan företagen.

Men ni har övertygat mig om att det faktiskt inte alltid är bra med en uC, även om det i detta fallet kanske hade varit bra(även om huvudproblemet troligtvis inte alls hade med det att göra).

Med en mikroprocessor kan det bli ganska knepigt att testa allting.

Säg att det finns följande ingångar:
* Hel/halvljusknapp.
* Gashandtag.
* Blinkers höger.
* Blinkers vänster.
* Nödstopp.

Sedan tillkommer ett antal utgångar men om vi bara stoppar med ingångarna är det 4 digitala funktioner och en analog som (teoretisk) ska testas i alla kombinationer som kan finnas. Alltså alla sekvenser och värden som kan skapas med dessa ingångar - och det blir jäkligt många! Var och en av dessa ska komma i alla de sekvenser som kan skapas och testande ska starta om vid varje ändring av mjukvaran...

Som Nerre skriver är det nog ganska enkelt att göra det med en µC men att få till en stabil spänningsmatning från fordons-ström är inte alltid så enkelt, det borde dock vara samma problem om man använder logik-kretsar.

Men jag tror att med tanke på den icke-vattentäta låda, storleken osv. att specifikationerna vid beställningen enbart berörde funktionerna och inte hade storlek, IP-grad eller liknande med, alltså helt enkelt en dålig kravbeskrivning. Antagligen har en del krav kommit in under: "men det är ju självklart att det ska vara så, det behöver man inte skriva!"

Man kan mycket med µC men de är inte alltid det bästa val! Att skydda in- och utgångar väl kan vara en pärs - men det går!

Och som jag skrev tidigare: det kan ha varit en äldre icke-µC person som fick till uppgift att designa enheten, sannolikt en som inte var van att ha mönsterkort med 70µm folie men snarare var van vid 120µm osv. (strömmar, lampor).

Icecap: Okej, det måste ju ha varit specifikationen som var bristfällig. Varför jag är så fundersam är för att jag tror att det kostade över 500 000:- för 10 st boxar inkl. kablage. Men det är väll kanske inte otroligt mycket men det känns som att man nästan hade kunnat fixa det billigare själv, att det skulle fungera med avsett ändamål verkade ju inte ingå i specen heller.

Jag förstod inte riktigt hur du menade att man ska "testa alla kombinationer"? Du menar i programmet då eller?
Tex. ADC-ingångar kan väll bara ha "tre olika lägen": För hög, för låg eller lagom? Om man har hanteringar för det i programmet så kan man väll lita på att det fungerar? Eller måste man testa alla tänkbara kombinationer på input för att vara säker? Miljontals alltså?
Eller menar du att programmet spårar ur pga något annat?
Alltså ursäkta om jag låter korkad, det är jag inte, men jag är ju ganska grön på detta ändå. Därför jag undrar saker

Program kan lätt gå åt h**** om man inte gör rätt från början
Det är lätt att göra ett program som löser en specifik uppgift
men att programmet även skall tåla felaktig input utan att spåra ur är
oftast det som man missar.

Så mjukvara måste testas noga med alla tänkbara märkliga indata..

Swech

beskrivningen på de funktioner som behövdes får mig att undra varför man öht skulle använda ngn mikroprocessor eller ens en elektroniklåda?
alla funktioner i ett fordon som innfattar en omkopplare/brytare som styr en 12v funktion kan ju lösas med enbart kabel och knappar och reläer där det är höga strömmar.
bränslemängd? det finns kompletta mätare med givare och instrumentdel.
indikeringar? varför itne vanliga instrumentlampor?
varför krångla till det?
mikroprocessorer använder man när man måste, typ att styra inspruningen på en motor....
men inte för att slå av eller på hellyset? eller mäta soppan?

Glattnos skrev: Eller måste man testa alla tänkbara kombinationer på input för att vara säker? Miljontals alltså?

I princip ja. När jag pluggade 80p elektroingenjör så läste vi just en kurs om "Designing for testability". Det handlade om att om man t.ex. designar en logikkrets så ska man lägga in en "test mode" som testar alla funktioner. Tänk dig en 32-bitars räknare. Ska du testa HELA räknaren så måste du testa att den räknar från 0 till 4294967295. Med en klocka på 1 MHz tar det 71 minuter. Ponera nu också att räknaren har en Reset, hur vet du att den funkar oavsett vad räknaren står på? Du kasnke måste prova Reset från ALLA 4294967296 värden... Om man istället lägger in en funktion som kopplar om vipporna till ett skiftregister så kan man istället skifta igenom "testvektorer" (som man då får designa på ett smart sätt) och snabba upp testet. Testvektorerna anpassas efter hur kretsen är kopplad, om jag inte minns fel så testar man bland annat efter:

Stuck at zero - för varje enskild intern nod i kretsen
Stuck at one - för varje enskild intern nod i kretsen
Överhörning mellan närliggande noder (kan vara svårt att veta exakt vilka som ligger bredvid varandra)

Liknande fenomen får du med mjukvara. Du måste testa alla villkor och båda håll (d.v.s. har du en IF-sats så måste du testa den både som sann och falsk), du måste köra igenom alla loopar och kolla att du inte får overflow, du måste kolla att alla variabler verkligen rymmer det du tänkt stoppa in i dem osv.

Har man "flaggor" i programmet så behöver man i princip testa alla kombinationer, det går inte att säga "den flaggan kan aldrig vara satt samtidigt som den flaggan". Det måste testas, för rätt vad det är gör man nån ändring som faktiskt innebär att bägge flaggorna kan vara satta samtidigt.

Genom att göra moduler och verifiera och validera dessa så kan man få ner testandet lite grann. (Jag går inte in på vad verifiering och validering är, delvis eftersom jag faktiskt inte riktigt själv har 100 koll på skillnaden mellan dem, jag vet bara att det är två olika saker:)

Är det kritisk programvara så måste man även ta hänsyn till situationer som normalt inte kan uppstå. Kosmisk strålning eller störningar kan få en bit i en uC eller ett minne att slå om så man hamnar i ett läge man inte har förutsett (eftersom ingen del av koden ändrar värdet så räknar man inte med att det plötsligt kan ha ändrats).

Sen får man inte glömma att man även kan behöva ta hänsyn till hårdvaran. Välja rätt plattform, bygga redundans etc.

Det råkar inte vara så att beställare och leverantör är bekanta/kompisar på ett eller annat sätt?

Tack för svaren! Det är alltså så viktigt att testa alla kombinationer på input. Det är alltså inte ett problem vid analoga kort, där behöver man inte testa alla kombinationer och behöver inte ta lika stor hänsyn till störningar. Har jag fattat rätt då?
Det gör isf att jag kan förstå att det valdes analogt före uC

svanted: Jag förstår faktiskt inte varför det skulle krånglas till så. Man tycker att lysen borde kunna hållas utanför boxen av många anledningar.

Nerre: Tack för förklaringarna! Men om vilken bit som helst kan slå om pga kosmisk strålning, går det verkligen att göra program som kan hantera det? Reset med jämna mellanrum eller vadå?

ristomemo: Jag vet faktiskt inte hur det var. Om dom kände varann, kanske var det så. Det kan ha varit något uppgjort alltså? Låter ju inte otroligt

Program som ändras pga. strålning kan t.ex. hejdas vid att startrutinen kollar igenom programminnet och gör en checksum som sedan jämförs med en sparat checksum, är de lika tillåts programmet att starta. Men vad om felet ligger i denna check-rutin?

Ett "analogt" system kan vara minst lika svårt att testa, om inte värre. Men består systemet av ett antal skilda funktioner som bara har mönsterkortet som gemensam nämnare kan man testa varje funktion för sig och då blir det ganska mycket enklare.

En orsak till att ljusen och andra mindre avancerade funktioner går via kretskortet kan vara att man ville ha ett "plug-n-play"-system, alltså att man bara kopplar in saker i den ena ända och tar ut i den andra. Ingen lösa reläer som ska monteras, ingen ledningar som ska skarvas eller liknande. Det kan vara en bra idé men inte alltid den rätta.

Glattnos skrev: Nerre: Tack för förklaringarna! Men om vilken bit som helst kan slå om pga kosmisk strålning, går det verkligen att göra program som kan hantera det? Reset med jämna mellanrum eller vadå? :humm:

Det där handlar ju om oerhört kritiska program (JAS styrsystem, pacemaker eller liknande), där får man i såna lägen kanske använda redundans i nån form. För sannolikheten att två bitar påverkas samtidigt är mer eller mindre försumbar. T.ex. alltid lagra alla data i dubbla variabler, regelbundet räkna ut en checksumma på koden etc.

Man måste ju för såna grejer göra en riskanalys och se vilka eventuella konsekvenser ett sånt fel kan få och hur man eventuellt kan reducera sannolikheten eller skadans allvarlighet.

Nu verkar det ju visserligen som om det i det aktuella fallet inte var en särskilt bra konstruktion som gjordes trots att den inte var gjord med mjukvara.

Det finns ytterligare en aspekt.
CE märkning dvs EMC tålighet och utsänd radiostörning.
Ett Analogt eller DC baserat system kan man i princip betrakta som onödigt att testa då dessa problem "inte" finns.
Då spar man från 50-100kSEK.
Men den troligaste orsaken är mossig konstruktör.
Jag och många med mig skulle tagit ett utvecklingskort som man byggt på med extern kraftförsörjning och I/O enheter.
Men 500kSEK låter mycket pengar, hade gissat på maximalt hälften varav 200kSEK varit utvecklingstid.