Funktionellt modellgränssnitt
| Förkortning | FMI |
|---|---|
| Status | Publicerad |
| Året började | 2010 |
| Senaste versionen |
3.0 11 maj 2022 |
| Organisation | Modelica Association Project (MAP) |
| Relaterade standarder | Samsimulering |
| Domän | Datorsimulering |
| Licens | CC BY-SA-3.0 |
| Hemsida | FMI hemsida |
Functional Mock-up Interface (eller FMI ) definierar ett standardiserat gränssnitt som ska användas i datorsimuleringar för att utveckla komplexa cyberfysiska system .
FMI:s vision är att stödja detta tillvägagångssätt: om den verkliga produkten ska sättas ihop av ett brett spektrum av delar som interagerar på komplexa sätt, var och en kontrollerad av en komplex uppsättning fysiska lagar, då borde det vara möjligt att skapa en virtuell produkt som kan sättas ihop från en uppsättning modeller som var och en representerar en kombination av delar, var och en en modell av de fysiska lagarna såväl som en modell av styrsystemen ( med elektronik , hydraulik och digital mjukvara ) monterade digitalt. FMI-standarden tillhandahåller således medel för modellbaserad utveckling av system och används till exempel för att designa funktioner som drivs av elektroniska enheter inuti fordon (t.ex. ESP-styrenheter, aktiva säkerhetssystem, förbränningsregulatorer). Aktiviteter från systemmodellering, simulering, validering och test kan täckas med den FMI-baserade metoden.
För att skapa FMI-standarden har ett stort antal mjukvaruföretag och forskningscentra arbetat i ett samarbetsprojekt etablerat genom ett europeiskt konsortium som har genomförts av Dassault Systèmes under namnet MODELISAR . MODELISAR-projektet startade 2008 för att definiera FMI-specifikationerna, leverera teknologistudier, bevisa FMI-koncepten genom användningsfall som utarbetats av konsortiets partner och göra det möjligt för verktygsleverantörer att bygga avancerade prototyper eller i vissa fall till och med produkter. Utvecklingen av FMI-specifikationerna koordinerades av Daimler AG . Efter slutet av MODELISAR-projektet 2011, drivs och utvecklas FMI som ett Modelica Association Project (MAP) .
De fyra nödvändiga FMI-aspekterna för att skapa modeller som kan monteras har täckts i Modelisar-projektet:
- FMI för modellbyte,
- FMI för samsimulering ,
- FMI för applikationer,
- FMI för PLM (integrering av modeller och relaterad data i produktlivscykelhantering).
I praktiken möjliggör FMI-implementeringen av ett mjukvarumodelleringsverktyg skapandet av en simuleringsmodell som kan kopplas samman eller skapandet av ett mjukvarubibliotek som kallas FMU (Functional Mock-up Unit).
FMI-metoden
Den typiska FMI-metoden beskrivs i följande steg:
- en modelleringsmiljö beskriver ett produktdelsystem genom differential-, algebraiska och diskreta ekvationer med tid, tillstånd och steghändelser. Dessa modeller kan vara stora för användning i off-line eller on-line simulering eller kan användas i inbyggda styrsystem;
- som ett alternativ definierar ett ingenjörsverktyg kontrollkoden för att styra ett fordonssystem;
- sådana verktyg genererar och exporterar komponenten i en FMU (Functional Mock-up Unit);
- en FMU kan sedan importeras till en annan miljö för att exekveras;
- flera FMU kan – på detta sätt – samarbeta under körning genom en samsimuleringsmiljö, tack vare FMI-definitionerna av deras gränssnitt.
Licens
FMI -specifikationerna distribueras under öppen källkod:
- specifikationerna är licensierade under CC BY-SA (Creative Commons Attribution-Sharealike 3.0 Unported) CC BY-SA 3.0
- C-header- och XML-schemafilerna som medföljer detta dokument är tillgängliga under BSD -licensen med tillägget att ändringar också måste tillhandahållas under BSD-licensen.
Arkitektur
Varje FMU (Functional Mock-up Unit) distribueras i en zip-fil med tillägget ".fmu" som innehåller:
- en XML-fil innehållande bland annat definitionen av de variabler som används av FMU;
- alla ekvationer som används av modellen (definierade som en uppsättning C- funktioner);
- valfri annan data, såsom parametertabeller, användargränssnitt, dokumentation som kan behövas av modellen.
Exempel
Nedan finns ett exempel på en FMI-modellbeskrivning utfärdad från Modelica .
<?xml version="1.0" encoding="UTF8"?> <fmiModelDescription fmiVersion= "1.0" modelName= "ModelicaExample" modelIdentifier= "ModelicaExample_Friction" > ... <UnitDefinitions> <BaseUnit unit= "rad" > <DisplayUnitDefinition display UnitDefinition = "deg" gain= "23.26" /> </BaseUnit> </UnitDefinitions> <TypeDefinitions> <Type name= "Modelica.SIunits.AngularVelocity" > <RealType quantity= "AngularVelocity" unit= "rad/s" /> </Type> </TypeDefinitions> <ModelVariables> <ScalarVariable name= "inertia1.J" valueReference= "16777217" description= "Tröghetsmoment" variability= " parameter" > <Real declaredType= "Modelica.SIunits.Torque" = "1" /> </ScalarVariable> ... </ModelVariables> </fmiModelDescription>
Jämförelse med Simulink S-Functions
FMI jämförs ofta med Simulink S-Functions eftersom båda teknologierna kan användas för att integrera tredjepartsverktyg tillsammans. S-funktioner används för att specificera en datorspråksbeskrivning av ett dynamiskt system. De är kompilerade som MEX-filer som länkas dynamiskt till MATLAB vid behov. S-funktioner använder en anropssyntax som interagerar med Simulinks ekvationslösare. Denna interaktion liknar den interaktion som sker mellan inbyggda Simulink-block och lösarna.
FMI-förespråkare förklarar att FMI-modeller har flera fördelar jämfört med Simulink S-Functions:
- S-Functions-formatet är proprietärt, medan FMI-schemat är licensierat under en BSD-licens .
- Byggstenarna i S-Functions är mycket mer komplexa än FMI, vilket gör det mycket svårt att integrera i andra simulatorer än Simulink själv.
- Dessutom är S-Functions-formatet specifikt för Simulink.
- S-Functions är inte lämpade för inbyggda system , på grund av minnesoverheaden för S-Functions.
Det finns också flera begränsningar som anges när du använder FMI/FMU:
- Minne - Parametrar, tillstånd, ingångar och utgångar exponeras inte direkt till utsidan, vilket står i motsats till hur ECU-programvara normalt är organiserad med avseende på minne för att tillåta transparens, enkelhet och effektivitet.
- Händelsehantering - Händelser kan öka körtiden för realtidssystem på ett oförutsägbart sätt.
- Potentiellt farliga funktioner kan inkluderas på ECU - Vissa funktioner som är meningsfulla för offline-simuleringar bör inte finnas på ECU:n. Exempel på funktioner som antingen stöds eller inte uttryckligen är förbjudna i FMI inkluderar loggning och I/O-operationer som print().
- Stöd för datatyper - Fler datatyper som stöds krävs för optimerad kod. Det finns till exempel inte något sätt att skilja mellan en uint8- och uint32-variabel.
| Förkortning | SSP |
|---|---|
| Status | Publicerad |
| Senaste versionen | 1.0 |
| Organisation | Modelica Association |
| Relaterade standarder | Samsimulering |
| Domän | Datorsimulering |
| Licens | CC BY-SA-3.0 |
| Hemsida | SSP hemsida |
Systemstruktur och parametrering (SSP)
System Structure and Parameterization ( SSP ) är ett standardiserat, öppet filformat för att beskriva komplexa, hierarkiska (tekniska) system som kan simuleras. En SSP-fil innehåller definitioner för systemarkitektur, gränssnitten för systemelementen och deras anslutningar och parametrering. Syftet med SSP är att förenkla utbytet och integrationen av systemelement som används i den distribuerade utvecklingen av ett system som ska simuleras med hjälp av en mängd olika verktyg.
SSP utvecklas som ett projekt av Modelica Association och bygger på FMI-specifikationen. FMI möjliggör utbyte av individuella simuleringskomponenter, medan SSP möjliggör utbyte av kompletta simuleringssystem, deras varianter och parametrering. Simuleringskomponenterna i ett simuleringssystem som beskrivs i SSP kan också vara oberoende av FMI och mappa till andra implementeringar.
SSP är utbyggbart för att stödja specifika krav eller domänspecifika utökningar: t.ex. OSI, dokumentation av krav, spårbarhet eller processsteg etc. SSP är öppen med avseende på komponentformaten. Även om den var baserad på FMI, kan den också användas med komponentspecifikationer av vilket annat format som helst.
Medföljande standarder och rekommendationer
I maj 2014 publicerade projektgruppen Smart Systems Engineering (SmartSE) från ProSTEP iViP Association sin rekommendation PSI 11 för utbyte av beteendemodeller mellan företag. FMI är därmed den tekniska basen. PSI 11 specificerar interaktionsscenarier, användningsfall, en referensprocess och mallar, som därigenom skulle kunna underlätta den industriella tillämpningen. I slutet av 2016 publicerade gruppen en film som borde belysa de industriella fördelarna.