|
|
|
SCC20Skrivet av Lars-Olov Larsson Uppdaterat 2018-05-02 INNEHÅLL Technical Coordination Committee Hur samverkar ABBET, TMIMS och AI-ESTATE? Vad blev resultaten av arbetena i SCC20?
HistorikATLAS dök för första gången upp någon gång på 1960 Talet. Det var de civila flygbolagen som började använda ett sätt att specificera test av flygelektronik. ATLAS var då en akronym för Abbreviated Test Language forAvionic Systems. Meningen var att det så mycket som möjligt skulle likna instruktioner som de skulle kunna se ut om de gavs på engelska. På så sätt skulle det bli lätt att se vad som gjordes. Någon gång under 1970 talet flyttades ATLAS till standardiserings-organisationen IEEE (The Institute of Electrical and Electronics Engineer), en amerikansk standardiseringsorganisation, som lyder under ANSI (American NationalStandard Institute). Hos IEEE fick ATLAS benämningen ATLAS-416. En kommitté med beteckningen SCC20 (Standard Coordination Committee 20) skapades. ATLAS var vid den här tiden ett rent specifikationsspråk. Efter varje möte, som hölls 2 ggr/år, kom det ut en ny utgåva eller level t.ex. ATLAS Level 14. De civila flygbolagen fortsatte med att utveckla ATLAS på egen hand men de skedde nu som en standard hos ARINC (American Radio INCorporated). Den fick beteckningen ATLAS-616. I dagligt tal när man säger ATLAS kommittén menar man vanligtvis SCC20. Med tiden har SCC20 kommit att hantera många andra standarder förutom ATLAS som anses passa in här. I början av 1980 talet tog en grupp användare som kallade sig för the five major user ett initiativ för att skapa en ny ATLAS. The five major users bestod av US-Mod (US Ministry of Defence), UK-Mod (UK Ministry of Defence), FRG-Mod( Federal Republic of Germany Ministry of Defence) och ARINC. Riktlinjerna var:
För att administrera den nya ATLAS:en som fick namnet ATLAS-716 eller C/ATLAS (Common ATLAS) skapades en ny sub-kommitté under SCC20. Denna sub-kommitté var inte organiserad på samma sätt som övriga. Den styrdes av något som kallades Executive Board som bestod av the five major users. Notera namnteckningen från Alf Gustafsson som var Sveriges representant i Executive Board. Executive Board hade egna slutna möten och kunde underkänna alla beslut som togs i kommittén vilket var helt emot IEEE´s regler. För detta fick man också mycket kritik.
Logotype för C/ATLAS
I slutet av sjuttiotalet började man framförallt i USA få problem med den stora floran av programmeringsspråk. Varje leverantör hade sitt eget programmeringsspråk vilket resulterade i att man måste kunna hantera ett mycket stort antal programmeringsspråk. Något som man i längden såg som helt ohållbart. Därför beslöt man att, för test skulle ATLAS användas. Även Storbritannien, Västtyskland och Frankrike anslöt sig till detta. När Sverige i början av 1980-talet skulle ta fram testutrusningar till JAS, bestämde man i IGJAS (IndustriGruppen JAS) att ATLAS skulle användas som testprogrammeringsspråk. Detta krav skrevs också in i den offertförfrågan som i samband med upphandlingen av testutrusningar skickades ut till ett antal tänkbara leverantörer.
Vad är SCC20´s ansvar för ATLAS?SCC20 tar fram en standard för att specificera tester av olika signaler. Testerna kan sedan implementeras manuellt, eller i ett program som exekveras på en dator.
Vad görs inte i ATLAS kommittén?ATLAS kommittén tillhandahåller inte kompilatorer. Behöver man en sådan får man antingen utveckla en själv eller köpa en från någon tillverkare. ATLAS ger inget stöd, i varje fall litet, för att lösa mättekniska problem. Detta är helt och hållet en implementeringsfråga. Kort sagt kan man säga att ATLAS specificerar vad som skall göras, men inte hur.
Vårt deltagandeÅr 1983 började vi regelbundet delta i SCC20 möten. Det var två möten varje år, ett vårmöte och ett höstmöte. I bland var det också extra möten, s.k. arbetsmöten, mellan de ordinarie. Vid de första mötena var det drygt 200 deltagare. Sedan blev det färre och färre. Under ca 15 års tid besökte vi de flesta mötena. För att hålla nere reskostnaderna för deltagarna var det noga reglerat var mötena skulle hållas. Gången var följande USA västkust, USA östkust och Europa. I och med att deltagarantalet minskade så avtog också tillämpningen av dessa regler.
I bland kunde valet av mötesplats resultera i att det var svårt att få resan beviljad, även om övriga alternativ var dyrare. Det hävdades att valet av mötesplats kunde tolkas som en semesterresa. Nu var det inte bara deltagare från Sverige som ställdes inför detta problem. Liknande tongångar hördes också från andra deltagare. Man ville inte skicka deltagare till ”Exotiska platser”.
Bild från ett ATLAS möte i Fort Lauderdale i Florida 1984. Här har vi ätit middag på Gerd Müller´s restaurang. Gerd Müller var för Västtyskland vad Zlatan är för Sverige idag. Från vänster: No 2 Bernd Eichenauer, No 3 Lars-Olov Larsson,
En bild från ett möte i Chiemsee Västtyskland 1985.
Bild från ett möte på Guadelope Västindien 1989. Vid ett tillfälle ordnade French Mod med en segeltur i Karibien Från vänster: No 1 Alf Gustafsson, No 4 Roy Oishi, No 6 Albert Sanson,
Hur gick ett SCC20 möte till?Mötena pågick normalt en vecka. Mötet inleddes på söndag eftermiddag med registrering av deltagarna. Då delades också det material som skulle behandlas under veckan ut liksom namnbrickor till deltagarna. Det fanns fyra kategorier av deltagare, varje kategori hade sin egen färg på namnbrickan.
Namnbrickorna för officers och voting members visade också namnet på aktuell subkommitté eller working group. Varje morgon under veckan inleddes med ett plenary (plenum) då samtliga deltagare var samlade. Ordförande eller vice ordförande för resp. subkommitté rapporterade då vad som gjorts under föregående dag. Därefter blev det fortsatt arbete i arbetsgrupperna. Den som var där för första gången besökte vanligtvis olika grupper för att orientera sig om vad som gjordes. Efter ett tag fastnade man för någon grupp som man tyckte bäst motsvarade ens intresseområde. Det var fritt fram för var och en att framföra sina synpunkter i arbetsgrupperna. Däremot fick man inte delta i omröstningarna om man inte var Voting Member i den gruppen. Voting member kunde man bli om man besökte en tredjedel av sammankomster under två av tre på varandra följande möten. Denna regel ändrades med tiden.
Vid varje SCC20 möte hölls på onsdagskvällen ett socialt event. Vanligtvis bestod det av att man ordnade en middag på någon för orten känd plats. Som exempel kan nämnas:
SCC20 mötena avslutades vid lunchtiden på fredag.
Efter några veckor skickades Minutes of meeting ut till deltagarna där det fanns dokumenterat vad som gjorts under veckan.
OrganisationSCC20´s organisation har ändrats mycket under årens lopp. Nya subkommitteér har tillkommit medan andra har försvunnit. SCC20 var i princip organiserat enligt följande.
Bild på organisation SCC20
Arbetsgrupper inom SCC20Här följer en uppräkning av några av SCC20´s arbetsgrupper och en kort beskrivning över vad man sysslade med.
Steering committeeDeras uppgift var att skapa riktlinjer för hur arbetet skulle bedrivas. För att kunna göra detta tog man fram ett dokument som kallades Managment Procedures och var vid varje möte föremål för genomgång och uppdatering. Ett utdrag ur Managment Procedures följer nedan.
”The primary functions of the Steering Committee are to establish basic policy and provide overall guidance for the ATLAS Committee. It is responsible for admistering the development to ensure that approved procedures have been followed and that the output complies with approved technical constraints. It is the principal Court of Appeal for aggrieved Committee Members.”
Technical Coordination CommitteeHade till uppgift att koordinera och förbereda förslagen som skulle behandlas.
ATLAS-416I början av 80-talet var denna den stora gruppen. Gruppen hade också ett antal undergrupper som arbetade med olika delar av ATLAS-416. Efter varje möte gavs en ny version, en s.k. level, ut. I och med att man i början av 80 talet började arbeta med ATLAS-716 eller C/ATLAS som den också kallades avtog intresset för ATLAS-416, för att sedan upphöra någon gång under 90-talet.
ATLAS-716 (C/ATLAS)Arbeten i denna grupp har under årens lopp varit vår huvudsakliga målsättning. Ett antal utgåvor har skapats. Av de större förändringarna som gjorts kan följande nämnas:
De standarder som getts ut är följande:
Den version som vi valde att använda för test av elektronikenheter i JAS var ATLAS-716-1985. Den var långt ifrån perfekt, men med den kompilator som vi inköpte från det tyska företaget GPP (Gesellschaft für processrechner Programmierung) kunde vi själva utöka språket efter våra egna önskemål och behov. På så vis kunde vi genomföra alla krav som krävdes för att testa enheterna i flygplanet.
Users Guide 771Denna grupp arbetade med att ta fram en guide för hur ATLAS bör användas. Det är numera en etablerad IEEE standard och kan köpas från IEEE. Den har genomgått flera uppdateringar.
P981Här arbetade man med att ta fram ett standardiserat sätt att styra instrument. Kommandona för att mäta t.ex. frekvens skulle vara detsamma om man nu hade ett instrument från HP, RACAL eller någon annan tillverkare. Kommandospråket kallades CIIL (Control Interface Intermediate Language). Gruppen flyttades någon gång i början av 80-Talet från SCC20 till en annan grupp inom IEEE.
TEDLTEDL står för Test Equipment Description Language. Uppgiften här var att utveckla en standard för att beskriva testutrustningar och ingående instrument. Ett antal produkter fanns redan på marknaden. T.ex. hade Boeing, Aerospatiale och GPP utvecklat egna standarder, men ingen uppfyllde de krav som man ställde. Därför beslöt man att utveckla en egen standard. Visserligen sneglade man på vad som redan fanns. Man gick oerhört ambitiöst till väga. Inte bara instrumentens egenskaper och toleranser skulle kunna beskrivas, utan också hur temperatur och ålder påverkade olika funktioner. Ingen enkel uppgift. 1990 gavs TEDL ut som en Trial-Use Standard. År 1996 blev den godkänd av SCC20 och överlämnades till IEEE för publicering. Då hade standardiseringsarbetet pågått från 1985 till 1996. Standarden fick benämningen IEEE std 993. Inom JAS projektet har aldrig denna standard använts. Det som användes var i stället en TEDL som utvecklats av GPP. Kanske inte den bästa men det var fullt möjligt att uppfylla kraven som ställdes där.
ATPGATPG är en förkortning för Automatic Test Program Generation. Gruppen bildades någon gång i början av 80-talet. Dess uppgift var att ta fram en standard för att beskriva digitala testobjekt. Under de kommande mötena arbetade man flitigt för att utveckla standarden. Så vi ett möte framförde Al Loewenstein, kommittens ordförande och en synnerligen karismatisk och driven person, synpunkten att han inte hade för avsikt att arbeta med en standard som aldrig skulle komma att användas. I stället förslog han att man skulle ta ett befintligt språk som utvecklats av bland annat Texas Instruments och IBM m.fl. på uppdrag av Amerikanska försvarsdepartementet. Detta resulterade givetvis i en hel del diskussioner i gruppen, men Loewenstein var van att få sin vilja fram och så blev det även den här gången. De fördelar man ansåg att man fick med detta var att man fick ett språk som redan var etablerat på marknaden. Dessutom hade det en ADA-lik syntax, och allt som påminde om ADA ansågs som en fördel på 80-talet. Efter några smärre justeringar skickades språket ut för omröstning. Förslaget gick i genom och så blev det en IEEE standard. Språket fick namnet VHDL som är en förkortning VHSIC Hardware DescritionLanguage. VHSIC är en förkortning för Very High SpeedIntegrated Circuits. Därefter flyttades språket till en annan del av IEEE. Med tiden blev det en mycket framgångsrik standard som används av många företag. En del högskolor och universitet i Sverige håller också kurser i språket. När nu denna arbetsuppgift försvann började man att försöka standardisera in och utdata till simulatorer som användes för att skapa testprogram för digitala testobjekt.
Inom JAS projektet har vi aldrig använt detta. Vi löste det i stället på detta sätt: Till den simulator (HILO) och det testprogramspråk (VETO) som vi använde utvecklade vi en pre- och postprocessor för att få rätt form på datat.
TMIMSTMIMS står för Test and Maintenance Information ManagementStandard. Målet med denna standard var att standardisera formatet på data som erhölls vid exekvering av test och underhåll för att möjliggöra analys av underhållsdata och logikdata från olika plattformar, från olika datainsamlingssystem, från olika industrier och från fabrik till fält. Den här gruppen hade ett nära samarbete med AI-ESTATE.
AI-ESTATEAI-ESTATE är en förkortning av Artificiell Intelligence and ExpertSystems Tie to Automatic Test Equipment. Målsättningen för den här gruppen var att skapa en standard för hur AI kan användas inom området autotest. Vi ägnade aldrig denna grupp något större intresse. Däremot kan nämnas att i ATS10 gjordes en del utredningar och prov med AI, dock inte med AI-ESTATE. Meningen var förstås att snabbare kunna hitta felen i testobjekten.
ABETABET är en förkortning av ADA Based Environment for Test. Målsättningen här var att skapa en standard för hur man skulle kunna exekvera Testprogram med en ATLAS syntax i ADA miljö. Gruppen skapades i slutet av 80-Talet, vid en tidpunkt då ADA ansågs vara framtidens programmeringsspråk. Sätt i det perspektivet är det inte så konstigt att man började snegla på ADA. Så småningom började glansen kring ADA att blekna och man tittade på andra tänkbara s.k. carrier languages. Bland de kandidater som man tittade på var C, C++, Visual BASIC m.fl. Namnet på den här arbetsgruppen ändrades också från ABET till ABBET (A Broad Based Environment for Test).
Hur samverkar ABBET, TMIMS och AI-ESTATE?
Så här tänkte man att ABBET, TMIMS och AI-ESTATE skulle samarbeta
ATLAS-2000ATLAS-2000 var en vidareutveckling av C/ATLAS -95. Arbetet började i mitten av 90-talet vid en tidpunkt då vi började dra ner på vårt deltagande. Därför finns inte så mycket att rapportera om, men en del saker kan i alla fall nämnas. Språket skulle få en modernare struktur. Tidigare versioner hade en struktur som påminde om FORTRAN med bl.a. fasta positioner för statements. Ett alternativ var att använda C som ett Carrier Language. Vidare skulle man vidga användningen från att tidigare varit ett språk för test av militär elektronik till test inom medicin och andra kommersiella områden. Man pratade om att upprätta ett antal ”Normative Annexes”, som skulle tjäna som rättesnören.
Bild på ATLAS-2000 Road Map ATLAS 2000 and associated applications domains
Hur lades ett förslag?Hur förslag (Proposals) skulle ställas fanns noggrant beskrivet i Management Procedures. I korthet gick det ut på följande: Författaren skulle på en särskild blankett beskriva problemet och föreslå en möjlig lösning. Därefter skickades förslaget till IEEE sekretariatet som i sin tur vidarebefordrade det till SCC20.
Hur behandlades ett förslag?Behandlingen av förslag var noga uppstyrt i Managment Procedures. Ungefär så här skulle det gå till. Förslaget behandlades först av SC och TCC som analyserade om förslaget var relevant. Om så var fallet överlämnades det till aktuell ”subcommitté”. Förslaget analyserades och man utredda vilken påverkan det hade på övriga delar av språket. Man gjorde en kvalitetsanalys av förslaget för att utröna om det var konsistent med övriga delar av standarden. Förslaget skickades ut för omröstning (ballot) till kommitténs röstberättigade medlemmar. För att omröstningen skulle vara giltig krävdes att minst 75 % svarat. De negativa svaren analyserades och man gjorde ett nytt utskick av de negativa rösterna (negativ ballot review) för att de som tidigare röstat ja skulle få chansen att ändra sig när man såg på vilka grunder personen röstat nej. Om de som röstat ja kom upp till mer än 75 % var det klart. Förslaget inarbetades i standarden och kom med i nästa utgåva av standarden.
Vad blev resultaten av arbetena i SCC20?Man har skapat en standard för att specificera tester inom huvudsak avionikområdet (ATLAS-416 och ATLAS-716 som också kallades C/ATLAS). För att ge riktlinjer för hur ATLAS bör användas finns en users guide. (IEEE std 771) Testutrustningar med instrument kan beskrivas med språket TEDL. (IEEE Std 993). För att på ett enhetligt sätt styra instrument togs språket CIIL fram. Med VHDL kan man beskriva digitala testobjekt och det finns också en standard för in och utformat till simulatorer. Med ABBET har man skapat en miljö där ATLAS statements kan exekveras. I TMIMS har man standardiserat testdata så att det passar till AI-ESTATE som i slutändan skall resultera i att man snabbare hittar ett fel. Med ATLAS 2000 försöker man sprida ATLAS till andra områden förutom avionik.
Vad har då vi på FFV sysslat med? Under de första mötena skaffade vi oss en uppfattning över vad som pågick i de olika arbetsgrupperna. Så småningom blev det att vårt fokus riktades mot C/ATLAS 716. Vid den här tiden höll man på att förbereda för att färdigställa C/ATLAS 716 1985 års utgåva. Vi deltog i revideringen av denna. Nästa stora steg i utvecklingen var att ta fram 89 års utgåva av C/ATLAS. Här engagerade vi oss i utvecklingen av något som kallades Event Based Timing och var avsett att användas för att mäta tider mellan olika händelser. Även digitaltesten förbättrades. Vi ställde också egna förslag. Följande kan nämnas.
|
