Mötesanteckningar Inga-Lill Bratteby-Ribbing, FMV: KC Ledstöd (018-120263, inga-lill.bratteby-ribbing@fmv.se)

IG Programvarusäkerhet: Möte # 4, 03-9-18

Antal mötesdeltagare: f.m.: 16, e.m.: 22 (se medlemslista).

Gruppmöte
0

Presentation av mötesdeltagare
En kort presentationsrunda kompletterad med en översikt av Simin Nadjm-Therani:s verksamhet inom RTSL, forskningslabbet för realtidssystem på LiTH.

1

Planering inför SESAM:s höstseminarium 21/10
Gruppen enades om att göra ett urval från de seminarier som hållits under de fyra IG-möten, som hållits. Ordf strukturerar upp o sänder programförslaget till de närmast berörda för slutputsning samt vidare till Anna Kåsjö.

2

AeroTechTelubs exjobbsarbetet på SpecTRM, Ann Eliasson
Detta arbete var ursprungligen avsett att inriktas mot SpecTRM. Då dess stödverktyg ej blev tillgängliga under den period som avdelats för examensarbetet, gjordes en omorientering mot en teoretisk studie av dess metodik, varvid en utvärderingsmodell av metoder o verktyg för kravspecificering av programvara utarbetades. Modellen baserades på ett antal attribut (Safety, Maintainability, Time efficiency), vilka i sin tur mappades på delattribut (Tracebility, User friendliness, Formal/informal analysis, Structure) och vidare i mer detaljerade, mätbara egenskaper för utvärdering av experter. Modellen applicerades därefter på V-modellen (enl ISO-9003, Mil Std 493) samt SpecTRM. En av slutsatserna från utvärderingen var att SpecTRM kompletterar V-modellen på en rad punkter (bl a genom ökad spårbarhet, möjlighet till specning av designavsikter, formell analys).

3

Saab:s exjobbsarbete på SpecTRM, Jonas Elmqvist, RTSLAB, LiTH
SpecTRM tillämpades här på en fjärrstyrd robot för förflyttning på begränsad yta med hinder. I o m att detta arbete låg senare i tiden kunde den 1:a officiella releaseversionen av verktyget provas (annonserad den 6/6), vilket med feed-back från exjobbarna ledde till att totalt 14 versioner kom att utväxlas. På plussidan: And/or-tabeller, spårbarhet, analysstöd. Bland förbättringsförslagen: Mindre textorientering o manuella ingrepp (länkning), mer visualiserings- o analysstöd samt stöd för konfigurationshantering o kodgenerering. Demo av simulerad modell.
Ett givande utfall i synnerhet med tanke på den korta tid som hittills nedlagts (11 v). Arbetet slutförs i höst.

4

STAMP, en systemövergripande säkerhetsanalys baserad på styrflöden, I-L Bratteby-Ribbing
De traditionella riskkälleanalyser, som hittills använts inom systemsäkerhetsmetodiken är inriktade mot att analysera de händelsekedjor som kan leda olycka (FTA, FMEA) eller de info-flöden som är involverade i olycksförloppet (HAZOP). STAMP är en ny typ av riskkälleanalys (hazard analysis), som i stället modellerar o analyserar olika typer av styrmekanismer inom ett system o dess operationella omgivning, för att finna bidragande olycksfaktorer.
Centralt för varje styrmekanism (o klassiskt i styr- o reglersammanhang) är att det i styrslingan (control loop) finns en återmatning (feed-back loop) av aktuellt status, vilket möjliggör dynamisk styrning. I många olycksscenarier har man funnit att detta saknats eller kortslutits för vissa delar av systemet. Exempel gavs, bl a Mars Polar Lander’s landningmod, Challenger’s O-ring, Den kolerasmittade dricksvattenreservoiren i Oregon 2000, Friendly-fire i Irak 1994 o 2003.

5

Övrigt

Finns några bra ex på krav ej uttryckbara i SpecTRM? –Ordf bad IG-medl återkomma med ex (f.v.b. Safeware).
Fler SpecTRM-prov? –Kockums hoppas kunna frigöra resurser för detta i höst.
Finns behov av heldagsseminarium i realtidssystem? –En idé kan vara att bjuda in bra föreläsare via SESAM.
Utdelning av div. artiklar från ISSC i augusti 2003 (International System Safety Conference).
Nästa möte:
Nr 5 under SESAM:s höstseminarium tis 21/10, Filmsal C, FMV, Sthlm.
Nr 6 i februari 2004. Föreslaget tema: UAV:er. Koberstein + Saab med i programkommittén.

 

 

Seminarier: Tidsstyrd programmering

6
Modellbaserad utveckling och syntes av tidsstyrda system, Martin Törngren, KTH, Mekatronik
Historik över teknikutvecklingen från renodlat maskinvarunära konstruktion av fristående system till ett mer abstrakt, modellbaserat samt disciplinöverbryggande o mekatroniskt angreppssätt (baserad på mekanik, styr- o reglerteknik samt programvaru- o elektronikutveckling) för inbyggda, distribuerade o säkerhetskritiska styrsystem. KTH:s Master-utbildning för bygge av en nedskalad bildemonstrator (1:5) i samarbete med Volvo o Chalmers inom FAR-projektet –en by-wire-tillämpning baserad på tids- o händelsestyrd realtidsteknik, stöttat m h a en uppsjö modelleringsspråk o ofta inkompatibla verktyg: det objektorienterad UML kontra det funktionellt orienterade Simulink, olika kodgeneratorer o CAD-stöd, blandat realtidsstöd i form av CAN, TTCAN, Flexray, samt Rubus OS.
7

By-wire-teknik för programmerad styrning av säkerhetskritiska funktioner, Roger Johansson
By-wire-teknik med kommunikationssystemet som den enskilt viktigaste komponenten för systemsäkerheten. Olika ansatser inom flyg- o fordonsindustri samt forskningsinstitut att ta fram en gemensam standard för att stödja skiftet från mekaniska kommunikationslänkar till datorbaserade (med olika grad av feltolerans): FlexRay (BMW mfl), SAFEbus (Honeywell för Boeing 777), TTCAN (Bosch, bl a i FAR-bilen) samt TTP/C (Wien Tekn Univ mfl, bl a i SIRIUS-bilen) –ett svar på dagens situation med kommunikationsprotokoll unika för varje biltillverkare o en stadig ökning av antalet processorer/bil (idag ca 60 st). Distribuerad övervakning o styrning, som en möjlighet att enkelt kunna lägga till ny funktionalitet (autonom global styrning/ bromsning/ stabilitetskontroll, antikollisionssystem, nedladdning av extra hästkrafter före motorvägsinfart) o att kunna nyttja modern mikroelektronik till minskade kostnader o med bibehållen säkerhet (en utveckling från passiv till olika typer av aktiv säkerhet) –dock till priset av ökad bandbredd (för X-by-wire, där X=fly: 110K-150K bits/s, steer: 35K-140K, brake:10K-20K).
Tekniken demonstrerad i bygget av SIRIUS: Chalmerteknologernas bilprototyp i fullskalemodell.

8

Tidsstyrning med RUBUS OS, Kurt-Lennart Lundbäck, Arcticus
Historik över företaget och utvecklingen mot Rubus, ett realtids-OS som erbjuder olika exekveringsparadigmer genom sin uppdelning i en röd, grön resp. blå kärna ovanpå en gemensam OS-bas –ett sätt att stödja en separering av applikationen i delar efter kritikalitet (hög, låg resp. icke-kritisk). Den röda, kompakta kärnan (med prioritet över den blå o gröna) används för tidsstyrd exekvering, vilket ger ett deterministiskt beteende. För att försäkra sig om att applikationens deadlines kan mötas krävs en schemaläggning av dess processer före exekvering (en statisk allokering av systemets resurser, vilken följaktligen måste ses över vid varje systemuppdatering). Den gröna kärnan hanterar förutom periodicitet, worst-case-execution-time etc. även avbrott o prioriteter. Den blå traditionella kärnan är händelsedriven (i termer av semaphorer köer, prioritet, worst-case-execution-time, period etc.). Grafiska stödverktyg finns. Visionen för framtiden är att generera ett RTOS utifrån applikationen. Då är vi tillbaka till de magra, ”egen”-tillverkade special-realtidskärnor som användes i säkerhetskritiska system före OS-COTS:ens intåg.

9

RUBUS OS i Volvo CE:s maskiner, Mats Karlsson, Volvo CE
Det elektroniska styrsystemet i Volvo CE:s produkter utgörs av ett antal kopplade styrsystem för fordon, förarhytt, instrument, motor samt transmission med Rubus som OS i tre av dessa. De största svårigheterna i realtidsapplikationerna har inte varit att i tid leverera krävd respons (svar kan snarare komma för tidigt) utan att få operationerna i rätt ordning. Tidsstyrning (som lätt leder till tillståndsexplosion) undvikes. 95% av applikationerna nyttjar Rubus röda kärna (vilken även använts för icke-kritiska delar). Växellådsfunktionen, som nyttjas frekvent, vilar på den gröna kärnan (vilket ger tillgång till interrupt). Förarinfo hanteras via den blåa kärnan. Köer används för meddelanden mellan blåa o röda delar. Det distribuerade nätverket underlättar diagnostik (”allt går att få ut samlat”). Rubus för- o nackdelar. Felmods- o systemsäkerhetsanalyser av hela systemet. Eftersom system ute hos kund tas in för modernisering / uppgraderingar blir varje exemplar av en fordonstyp/-modell unik o måste konfigurationshanteras ned till enskilt enhet.

10

Diskussioner –som vanlig intressanta– i samband med samt efter presentationerna.

11

Avslutning med ordförandens tack till deltagarna.


Aktivitetslista IG Programvarusäkerhet
Nr
Klar till
Ansvarig
Mötesnotiser senaste möte
4.1
031003
Ordf
Dagordning nästa möte
4.2
030919
Ordf
Förberedelser av presentationer nästa möte
4.3
031020
Ann, Mari, Peter, C-E, Tobias, Mats, Jonas, Ordf
Dagordning möte #6 (feb 2004)
4.4
040115
Ordf, Björn, Johan
Exempel på krav ej uttryckbara i SpecTRM 4.5 031021 Medl
Komplettering av # 3.2 med företagsspecifika frågeställningar
3.3
030917 
Deltagare 
Kompletteringsförslag till hemsida (verktyg, utb etc)
1.5
030330
IG-medl
Egen applikation strippad för verktygsprov
1.8
030409
IG-medl