Inbyggda Realtidsdatabaser för Motorstyrning

Transkript

1 Inbyggda Realtidsdatabaser för Motorstyrning Anders Göras 1, Sven-Anders Mellin 2, Jörgen Hansson 3 1) Mecel AB, Åmål, anders.goras@mecel.se 2) Saab Automobile AB, Södertälje, sven-anders.melin@saab.com 3) Inst. för datavetenskap, Linköpings universitet, 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.

2 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) 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.

3 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.

4 Ö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

5 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.