Inbyggda Realtidsdatabaser för Motorstyrning

Relevanta dokument
Parallellprogrammering i C++ 17 EDT621 Datorarkitekturer med Operativsystem Viktor Lindgren

Outline. Datorsystemtekni. Kravspecifikation. Kravspecifikation (forts.)

Vad händer egentligen före en krasch? Svarta lådor och tidsmaskiner sparar pengar för företag

Systemrekommendation. Artvise Contact Center

Introduktion till hårdvara, mjukvara och operativsystem

Realtidssystem HT03. Vad är realtidssystem? Inbyggda system. Att programmera, Tasks (Uppgifter) Realtidssystem kräver analys

Systemkrav. Artvise Kundtjänst

Fö 7: Operativsystem. Vad är ett operativsystem? Målsättning med operativsystem. Styr operativsystemet datorn?

Hyper-Threading i Intelprocessorer

Hjälpmedel: Inga hjälpmedel förutom penna, suddgummi och glatt humör.

Realtidssystem. - Schemaläggning - EDAF85 - Realtidssystem (Helsingborg) Elin A. Topp. Föreläsning 6

Datalagringsmetodik och arkitektur i Java. Projektdefinition. Projektdefinition. Björn Brenander. 7 maj 2001

Software Technology. Josef Svenningsson

Pipelining i Intel Pentium II

Trådar. Aktiva objekt

Operativsystem DVG A06. Definition. Varför operativsystem? - Vad är ett operativsystem?

Databaser design och programmering Säkerhetsproblem Databashanteraren SQL-injektion

Föreläsning 2 Datastrukturer (DAT037)

In- och Utenheter. Fö 3: In/Ut matning och kopplingsstruktur. Några exempel. Egenskaper. In- och Utenheter. Styrning.

Introduktion till migrering till molnet. PART 4: Plattformar för molntjänster

Lunds Tekniska Högskola Datorarkitektur med operativsystem EITF60. Superscalar vs VLIW. Cornelia Kloth IDA2. Inlämningsdatum:

Databaser design och programmering. Transaktionshantering och säkerhet säkerhetsproblem fleranvändarproblem transaktioner låsning

Realtidssystem. - Schemaläggning - EDA698 - Realtidssystem (Helsingborg) Elin A. Topp. Föreläsning 6

Behörighetssystem. Ska kontrollera att ingen läser, skriver, ändrar och/eller på annat sätt använder data utan rätt att göra det

Svar till tentamen den 16 december 2013 Datorarkitekturer med operativsystem, EDT621, 7,5 poäng

Prestandapåverkan på databashanterare av flertrådiga processorer. Jesper Dahlgren

Föreläsning 7: Transaktioner

Hyper Threading Intels implementation av SMT. Datorarkitekturer med operativsystem - EITF60. Felix Danielsson IDA2

Hantering av hazards i pipelines

JavaRats. Kravspecifikation. Version 1.1. Gustav Skoglund Marcus Widblom Senast ändrad: 13 / 05 / 08

Datorteknik ERIK LARSSON

Öka prestanda i Shared-Cache multi-core processorer

Tentamen i Realtidsprogrammering för Au3, D3, E3

Visionen om en Tjänstekatalog

Proaktivt forum för Elmätare. Från elmätare till energiserviceenhet, din ingång till smarta nät, en branschrekommendation

Skriftlig tentamen i kursen TDTS04 Datornät och distribuerade system kl. 8 12

PARALLELLISERING AV ALGORITMER PROCESSORER FÖR FLERKÄRNIGA

ITinstitutionen bit för bit

effektiv tillståndskontroll för alla branscher

DVG A06. Operativsystem, mm. Karlstads universitet Datavetenskap. DVG A06 Johan Eklund. Datavetenskap, Karlstads universitet 1

Förslag på examensarbete

Databaser - Design och programmering. Säkerhetsproblem. SQL-injektion. Databashanteraren. Transaktion. Exempel. Transaktionshantering och säkerhet

IRIS Integrerat Dynamiskt Prognostiserande Underhållsstöd

Examensarbete. Teknikområde: Digital bildbehandling. Rubrik: Tactical overlay system, del III. Arbetsuppgifter: Signalbehandling av IR-bild

INSTALLATIONSANVISNING BC500G2 6 CYL, MED GENERELLT KABLAGE

Karlstads Universitet, Datavetenskap 1

In- och utenheter. Händelsebaserad programmering i GLUT. Interrupt-baserad interaktion. Sampling / polling. Händelsebaserad interaktion (forts.

Definition DVG A06. Varför operativsystem? Operativsystem. Översikt. - Vad är ett operativsystem?

Big Data i spelbranchen

produktöversikt OptiMaster III

Kurskatalog 2010 INNEHÅLLSFÖRTECKNING

Digitalteknik och Datorarkitektur 5hp

IRIS Integrerat Dynamiskt Prognostiserande Underhållsstöd

Prestanda och skalbarhet

Målriktad prestanda för IoT-arkitektur. SAUTER modulo6

Digital elektronik och inbyggda system

Aktivitetsschemaläggning för flerkärninga processorer

Introduktion till integrering av Schenkers e-tjänster. Version 2.0

TDDC30. Objektorienterad programmering i Java, datastrukturer och algoritmer. Föreläsning 11 Jonas Lindgren, Institutionen för Datavetenskap, LiU

Systemkonstruktion LABORATION REALTIDSPROGRAMMERING

Databaser & databasdesign. Personuppgiftslagen, säkerhet och transaktioner.

Undervisningen i ämnet webbutveckling ska ge eleverna förutsättningar att utveckla följande:

LIPs Martin Lindfors ChrKr Projdir2017_sbd.doc CKr

PROGRAMMERING. Ämnets syfte. Kurser i ämnet

Filtac AB grundades 1982 i Göteborg. Allt sedan dess har vi specialiserat oss på filtrering,

Datorarkitekturer med operativsystem ERIK LARSSON

Mål med lektionen! Repetera och befästa kunskaperna.

Datakom II (MNP) ht 1998 Bengt Ahlgren 1. Vad är speciellt med implementering av kommunikationsprotokoll?

AVR 3 - datorteknik. Avbrott. Digitala system 15 hp. Förberedelser

ELEKTRONISKT TRYCKHÅLLNINGSSYSTEM

Föreläsning 11 Tisdag 6/6 2000

12 principer of agile practice (rörlig)

Pressrelease Artes Industriambassadör Mer realistiska skuggor i datorspel och virtual reality-applikationer

Tentamen i Realtidsprogrammering

Tentamen i Digitala system - EITA15 15hp varav denna tentamen 4,5hp

Transaktioner och samtidighet

Programmering II (ID1019) :00-11:00

fem områden för smartare marknadsföring

Svensk installationsmanual Nissan S14 SR20 (76-pin) MaxxECU Plugin

PROGRAMMERING. Ämnets syfte. Kurser i ämnet

Leverans och installation

DATALAGRING. Ämnets syfte

Tentamen DATABASTEKNIK - 1DL116

SKOLFS. beslutade den XXX 2017.

TDDIU81. Processer och trådar. Andreas Dahlberg, Jonathan Doherty, Tony Magnusson, Patrik Ottosson, Rasmus Siljedahl

Datorarkitekturer med operativsystem ERIK LARSSON

Tidseffektiv administration av Creo Parametric och Windchill PDMLINK

DIG IN TO Administration av nätverk- och serverutrustning

INSTITUTIONEN FÖR DATA- OCH INFORMATIONSTEKNIK

EasyTherm PLASMA OCH GASSKÄRNING: PRODUKTIV, PRAKTISK, PRECIS

IE1204/IE1205 Digital Design

Introduktion Schenker-BTL AB, Stab IT Beskrivning över informationsintegreringmed Schenker, metodbeskrivning version 1.

TIAP-metoden för statusbestäming

Carl-Fredrik Lindberg, ABB Corporate Research. Automation Scandinavia, Trådlös kommunikation i industrin - ett PiiA-projekt

1:5 SLUTRAPPORT - POST MORTEN LARS EHRMAN WP

Objektorienterad Programkonstruktion. Föreläsning jan 2017

Leica ScanStation C10 Allt-i-ett laserscanner för alla applikationer

Algoritmer, datastrukturer och komplexitet

Tentamen PC-teknik 5 p

Daniel Akenine, Teknikchef, Microsoft Sverige

Transkript:

Inbyggda Realtidsdatabaser för Motorstyrning Anders Göras 1, Sven-Anders Mellin 2, Jörgen Hansson 3 1) Mecel AB, Åmål, email: anders.goras@mecel.se 2) Saab Automobile AB, Södertälje, email: sven-anders.melin@saab.com 3) Inst. för datavetenskap, Linköpings universitet, email: jorha@ida.liu.se Bakgrund Denna rapport ger en översikt om dagens situations rörande datahantering i motorstyrsystem, och identifierar ett antal problemställningar som behöver lösas för nästa generations motorstyrsystem. Dessa problemställningar finner vi lämpliga för utföras inom ramen av ett ISIS-projekt med en doktorand. Dagens situation I dagens motorstyrsystem så finns det ett antal trender. q Reglerfunktionaliteten går mot modellbaserad utveckling. q Kodmängden ökar mest inom diagnos och säkerhetssystemet. q Det som driver ökad diagnosfunktionalitet är lagkrav och ökad tillgänglighet med ökad enkelhet att byta rätt del som falerat. Dagens situation: Vision: Control Algorithms Control Algorithms Diagnos s Diagnos s Globalt Data RAM Database I/O-SW: HW-related SW I/O-SW: HW-related SW Fig 1. Bilden illustrerar de process-typer som är involverade i motorstyrningen, samt hur de jobbar mot data lagrat i primärminne.

Idag så är systemen anpassade till de höga realtidskrav som de snabbaste regleralgoritmerna ställer (storleksordningen millisekunder). Dessa krav härstammar från att alla motorstyrsystem har två tidbaser, dels den vanliga tiden som är konstant och dels motorvarvtalet som varierar. Systemet måste klara av att hantera alla händelser som sker på motorposition avseende både sensorer och aktuatorer (tändning, bränsle, motorpositionsgivare etc). Denna problemställning är illustrerad i figur 2. Processer med tiden som tidbas representeras med A, B, C och D. Process A exekverar var 6,25 ms, process B exekverar var 12,5 ms, process C exekverar var 25 ms och process D exekverar var 100 ms. Figuren visar hur motorpositionshändelser med vevaxelgrader som tidbas interakterar med processerna A till D. I bilden så hålls gällande tidbas till vevaxelgrader, den övre delen med processena A till D visar hur ofta dessa exekverar i vevaxelgrader vid 1000 rpm och den nedre delen hur ofta processerna A till D exekverar i vevaxelgrader vid 6000 rpm. Time based execution at 1000rpm A A&C A A&C A A&C A&D A&C A A&C A Measure: air, rpm Calculate: fuel, ignitioon Ignite Read knock Exhaust valve open Intake valve open Crank angle for one cylinder (deg) 0 180 360 540 654 720 (0) Time based execution at 6000rpm Inject fuel 380 Ignition Read misfire A A&C Fig 2. Bilden illustrerar med två exempel hur de två olika tidbaserna samverkar vid två olika varvtal, 1000 och 6000rpm. Alla funktioner styrs av ett operativsystem som dels aktiverar funktioner på tid och som hanterar alla motorpositionshändelser i form av avbrott. Ökade lagkrav och diagnoskrav för felhantering har inneburit att datamängd och kodstorlek vuxit under de senaste åren; denna trend måste brytas, bland annat genom tillgången till bättre verktyg för att hantera utökad funktionalitet och komplexitet. Vi tror att en databas anpassad efter dessa behov är ett viktigt vertyg för detta. Figur 1 beskriver transaktionsflödet i motorstyrsystemet. I/O-SW producerar globalt data specificerat för Control Algorithms. Data som krävs av Diagnos s skapas av funktionerna själva. Med avseende på de prestandakrav som finns, så är det realtidskraven på Control Algorithms som är den begränsande faktorn med avseende på systemets övriga prestanda och funktionalitet. När det gäller Diagnos s, så har dessa som huvudsaklig uppgift att hantera datasekvenser och utvärdera dessa.

För att klara dessa realtidskrav innebär det att I/O-SW direkt skriver till och läser från globala variabler som lagras i RAM. Dessa variabler läses odelbart av samtliga typer av funktioner (dvs som atomiska operationer). Inga variabler är större än 32 bitar vilket processorerna klarar att läsa och skriva odelbart. Funktioner som har lägre realtidskrav men ställer andra krav på historik och filtrering av data anropas då periodiskt för att undersöka om de skall utföra någon aktiv åtgärd eller spara på sig data för senare bearbetning, dvs en form av polling. Vision Morgondagens system har förutom ett operativsystem som hanterar processerna dessutom en databas. Databasen hanterar alla datatransaktioner. För de snabba processerna så innebär inte det mer än vad som görs idag. Men för de långsamma så innebär det att databasen tar in allt data bevakar det och ser till att operativsystemet aktiverar en process först då önskvärd data finns tillgänglig och uppfyller de krav som är uppställda. Fördelen är att data levereras dessutom samlat och är samstämmigt i tid. Tabell 1 sammanfattar de nödvändiga transaktioner som databasen behöver kunna hantera. Transaktionsflöde Transaktionstyp TLA I/O-SW till Control Rapid Read Transaction RRT Control till I/O-SW Rapid Write Transaction RWT Control till Control Rapid Transfer Transaction RTT Control till Diagnose Rapid Write Transaction RWT I/O-SW to Diagnose Slow Read Transaction SRT Diagnose till I/O-SW Slow Write Transaction SWT Diagnose till Diagnose Slow Transfer Transaction STT Tabell 1. Beskrivning av transaktionsflöde och typ av transaktion Detta innebär att man kan förenkla långsamma processer genom att delar av dess funktionalitet ligger i databasen. I databasen finns alla krav på data samlade och i funktionerna så ligger endast de aktiviteter som skall utföras. I detta scenario så innebär det att I/O-SW producerar data för databasen, där databasen hanterar tidsstämpling och dataserier. Specifikationen på I/O-SW tar hänsyn till krav både för för Control Algoritms och Diagnos functions. Det förutsätter också att databasen är realtidsmässig och kan hantera de realtidskrav på dataflödet som Control Algorithms kräver. Diagnos s ställer frågor till databasen om definierat körfall och databasen levererar färdiga dataserier som direkt utvärderas av funktionen. De krav på som ställs på databasen är: q Skydd mot att flera funktioner kan skriva till samma data. q Motverka dubletter, d v s dubblerad lagring av data i flera processer. q Säkerställa rätt ålder på datat, t ex genom gruppering av data för samtidig användning av någon funktion, d v s data har tidskrav. q Måste vara minnes- och tidsoptimerat för minimal overhead. q Reglerfunktioner med höga realtidskrav måste kunna realiseras.

Öppna Frågeställningar De primära forskningsfrågeställningar som identifieras i sammanhanget kan delas in i tre grupper: databassystemets arkitektur, reaktivt beteende (händelseorienterad databehandling), samt modeller och algoritmer för paralleliserad transaktionsexekvering (eng. concurrency control) och schemaläggning. Arkitektur av databassystem När man analyserar dagens motorstyrsystem (se tidigare beskrivning) kan man notera att transaktionerna har distinkta egenskaper när det gäller (i) typ av operationer de utför (läs-, skrivtransaktioner, d v s sensor-transaktioner, samt uppdateringstransaktioner, d v s både läsoch skrivoperationer utföres; (ii) storlek; (iii) samt deras realtidskrav. RRT-transaktioner (se tabell 1) som matar data till till reglerfunktionerna, samt RWT-transaktionerna som skriver data till databasen har de realtidsmässigt högsta kraven, både med avseende på frekvens och stringens, dvs, de utförs ofta och deras deadlines är viktiga att möta. Dessa transaktioner tar dock inte så lång tid p g a av deras enkla struktur. Dock kan befintlig databasteknik och existerande databasarkitekturer erbjuda endast begränsat stöd för transaktionshantering av detta slag. De specificerade realtidskraven ställer speciella krav på databasarkitekturen för att kunna hantera RRT- och RWT-transaktioners höga frekvens. Databasarkitekturen bör ha stöd för differentierade transaktionshantering i databasen så att RRT- och RWT-transaktioner kan få optimerad exekvering med minimal påverkan på, och av, andra transaktioner. Detta påverkar designen av både arkitekturen och underliggande komponenter, bland annat schemaläggning, concurrency control, minneshantering, och delvis loggning av data. En frågeställning berör också kopplingen mellan hårdvara, operativsystemet och databasen, där databasen är delvis integrerad med operativsystemet för att maximera prestanda samtidigt som att minska resursbehovet. Reaktivt beteende Dataanalyser genomförs av systemet i diagnossyfte. Önskvärt är att när data finns tillgänglig skall en process aktiveras för att utföra någon bearbetning av data, och som följd initiering av lämplig åtgärd. I nuvarande teknik används polling, dvs processerna aktiveras regelbundet och kollar om nödvändig data finns tillgängligt, vilket kostar processortid utan att egentligt arbete utförs. Ett bättre alternativ är att ha händelsestyrd aktivering av processer, dvs ett reaktivt beteende. ECA-regler (on Event E, if Condition C, then do Action) har framgångsrikt använts i traditionella databaser och vissa typer av realtidsdatabaser. Modellering av reaktivt beteende med, möjligtvis förenklade, ECA-regler skulle maximera processorutnyttjande, men också erbjuda en uniform plattform för att hantera händelser i systemet (dock ej avbrott av typen interrupt). Parallelliserad transaktionsexekvering Parallell transaktionsexekvering är nödvändigt för att hantera laster som innehåller långa transaktioner (i avsaknad av långa transaktioner kan varianter av strikt seriell exekvering ofta tillämpas). Långa transaktioner innebär i vår specifika applikation huvudsakligen uppdaterings- och bearbetningstransaktioner. Vid närmare analys av den data som behandlas i motorstyrsystemet så har flera dataobjekt tidskrav på sig i form av ett absolut validitetsintervall, d v s dataobjekt har ett bäst före datum och efteråt är det att betrakta som inaktuellt. För transaktioner som är beroende av multipla dataobjekt så innebär det att bearbetning av dessa dataobjekt måste ske när alla objekt är absolut valida. Det intervall i vilket samtliga dataobjekt för bearbetning är absolut valida kallas relativt validitetsintervall. I realtidssammanhang har tidskrav traditionellt abstraherats/kopplats till processer eller uppgifter, inte sällan onaturligt. Viss forskning på parallell transaktionsexekvering med fokus

på validitetsintervall finns, men har huvudsakligen gjorts på transaktionslaster som är mer homogena än den som är aktuell här. Av primärt intresse är att hitta metoder och algoritmer som tillåter den differentiering av transaktioner som vi tidigare nämnt, och som tillåter parallellisering av långa transaktioners exekvering medan kortare transaktioner normalt inte avbryts under exekvering (d v s en form av strikt seriell exkvering). Integrationen av parallell transaktionsexekvering (här åsyftas begreppet concurrency control explicit) och schemaläggning, mot bakgrunden av differentierad transaktionshantering, är starkt beroende av de olika metoder och algoritmer som används, vilket i sig ökar komplexiteten. Förväntade resultat och Impact Förväntade forskningsresultat inbegriper bland annat: (i) metoder för differentierad hantering av heterogena transaktionslaster, där heterogeniteten kommer från olika typer av tidskrav (deadlines på processer och databobjekt), tidskravens stringens, och transaktionernas struktur och storlek; (ii) metoder för händelseorienterad styrning av vilka processer som skall aktiveras; och (iii) förståelse för vilka krav som mjukvaruarkitekuren måste tillfredsställa. Vid framgång av utvecklandet av en databas för detta ändamål finns det flera positiva effekter av signifikant mervärde, bland annat följande: q Genom att använda en databas som central lagringsplats så kan dubbellagring av data hos olika processer undvikas, vilket i sig enklare struktur och underhåll av mjukvaran (bland annat blir det lättare att utöka befintlig mjukvara med ytterligare funktionalitet och dataobjekt). q Programmerarens uppgift underlättas rejält då programmeraren inte längre behöver försäkra sig om att data låses ute i processen för att undvika att data uppdateras samtidigt av flera; detta åläggs databasen att låsa dataobjekt samt möjliggöra maximal parallellisering av transaktioners exekvering. q Tidskraven på data hanteras explicit. Projektorganisation Industriella partners är Mecel AB, kontaktperson Anders Göras, och Saab Automobil, kontaktperson Sven-Anders Melin. Handledargrupp föreslås innehålla Jörgen Hansson, Lars Nielsen, samt ytterligare en person (det är brukligt att handledargrupper består av tre disputerade personer). Övrig information För närvarande bedrivs ett doktorand-projekt med två doktorander som fokuserar på inbyggda realtidsdatabaser (eng. embedded real-time databases) av Hansson. Detta projekt bedrivs i samarbete med bland annat Upright Database Technology och finansieras av ARTES (ett forskningsnätverk för realtidsforskning i Sverige). Det projektet tittar på komponentisering av databasfunktionalitet för att möjliggöra skräddarsydda databaser för inbyggda realtidssystem med begränsade resurser. Fokus ligger på komponentbaserad utveckling av realtidsmjukvara, där design av databasen ställs i fokus, d v s underliggande algoritmer antas vara kända. Båda projekten kan dra fördel av varandra, framförallt eftersom de attackerar olika frågeställningar så kompletterar de varandra på ett gynnsamt sätt.