SE518408C2 - Metod och anordning för framtagning av systemprotokoll för styr- och/eller kontrollutrustning - Google Patents

Description

518 408 REDOGÖRELSE FÖR UPPFINNINGEN TEKNlSKT PROBLEM Protokollet CAN täcker bara de lägsta fiinktionerna i ett protokoll för distribuerad styr- system. Den enda service som erbjuds är att sända meddelanden av begränsad längd, maximalt åtta byte, och att begära sändning av ett meddelande. Därför erfordras alltid ett eller flera högre protokollager. För CAN föreligger idag ett flertal sådana protokollförslag, exempelvis Smart Distributed System, J 1939, DeviceNet, OSEK, CAL/CANopen, M3 S, CAN Kingdom, etc. och flera lär komma. De flesta av nämnda protokoll är endast grund- protokoll och förutsätter att ytterligare lager, så kallade profiler, tillfores. Ofia ställs också krav utöver de i CAN specifikationen angivna på kablar, kontakter, drivsteg, skydds- kretsar, etc. Profilerna kan sägas vara en detaljerad specifikation utöver protokollspeci- fikationen som vissa moduler måste uppfylla. Exempelvis finns i DeviceNet bland annat profiler för gränslägesbrytare, induktiva brytare, fotoelektriska givare och motsvarande profiler finns i andra protokoll som Smart Distributed Systems. Tanken är att man med en profil skall kunna skapa ett fullständigt protokoll for varje modul och när dessa sedan sammankopplas med CANbussen så skall hela systemet fungera. Så är fallet endast i mycket enkla system och det krävs därför ofta att modulerna kan anpassas till det slutliga systemet. Exempel på sådan anpassning är att systemkonstruktören kan göra ett slutligt val av vilka CANidentifierare som skall användas i systemet. CAN Kingdom utgör i proto- kollfloran en särställning efiersom det protokollet förutsätter att systemkonstruktören åtminstone fritt kan tilldela CANidentifierare till alla moduler och att modulkonstruktören har möjlighet att till systemkonstruktören överlämna ett flertal beslut om hur det slutliga protokollet skall vara uppbyggt.

Om man studerar förefintliga profiler så finner man att samma profiler med små modifie- ringar finns föreslagna både för något visst CANprotokoll och för andra protokoll, exem- pelvis Interbus-S eller Profibus. Man finner vidare att vissa funktioner återfinns på ett ej överensstämmande sätt i olika profiler för samma protokoll samt att profiler for samma modultyper återfinns i olika protokoll. Många gånger kan skillnaderna vara forargligt små. 518 408 Exempelvis kan en variabel ha samma dataformat men ha olika namn, två protokoll fore- skriver olika handskakningsförfarande mellan två moduler som skall utbyta information mellan varandra, etc. Exempelvis föreskriver DeviceNet "Double MACID check" något som CAN Kingdom saknar. Förutom detta så skulle en DeviceNet modul kunna utbyta information med en CAN Kingdom modul. En systemkonstruktör som skulle vilja integrera en DeviceNetmodul i sitt CAN Kingdomsystem kan göra så genom att låta sin systemmodul (Capital enligt CAN Kingdomspecifikationen) utföra "Double MAClD-"för- farandet och på så sätt "lura" DeviceNetmodulen att tro att den arbetar i ett Devic- Netsystem. Oíta är det så att alla egenskaper i en modul inte finns beskrivna i profilen utan modulkonstruktören har sett profilen som ett minimikrav och sedan lagt till ytterligare egenskaper.

För att minska utvecklingstiden och sänka kostnader vill en systemkonstruktör gärna kunna använda standardmoduler i sitt system. Av ovan sagda framgår att det är ett kompli- cerat arbete att välja lämpliga moduler, speciellt om systemet inte är av standardtyp. Om han väljer protokoll med profiler så har han att välja inom ett stort antal profiler. Väljer han istället moduler av CAN Kingdomtyp så har han att i detalj studera varje moduls specifikation för att avgöra om den är lämplig eller ej. Det kan också vara så att han skulle kunna använda moduler som följer olika högre lagers protokoll som i exemplet ovan med DeviceNet och CAN Kingdom. Genom att utnyttja funktioner som ligger utanför standardprofiler, kombinera moduler konstruerade för olika protokoll, etc. kan en skicklig systemkonstruktör skapa system som har bättre prestanda eller är kostnadseffektivare jäm- fört med system som följer en gängse standarduppbuggnad. I och med att antalet högre lagers protokoll for CAN, antalet profiler inom varje sådant protokoll och antalet moduler som kan kommunicera över CANbussen ökar, så får systemkonstruktören större möjlig- heter att skapa unika systemlösningar. Dessa möjligheter motverkas av att det till sist blir en hart när omöjlig uppgift att välja de rätta modulerna bland alla tillgängliga och att efter valet slutligt justera de utvalda for att passa i systemet. 518 408 LÖSNINGEN Det som huvudsakligen kan anses vara kännetecknande for en metoden enligt uppfin- ningen är att den innefattar beskrivningar av moduler och system i för datorbearbetning lämplig form och att systemkonstruktören med hjälp av dator kan bygga upp en modell av sitt system och att han kan införa en databas i datorn med beskrivning av moduler och sammankopplingsenheter och att datorn sedan kan jämföra delarna i systemmodellen med motsvarande eller liknande delar i databasen och ur denna utvälja och föreslå lämpliga enheter för systemet. Beskrivningen av moduler är uppbyggda med ett basprotokoll, i detta fall CAN, och ett antal tilläggsprotokoll som refererar till olika standards samt i förekom- mande fall till profiler for dessa tilläggsprotokoll. Vid varje sådan nivå beskrivs också eventuella avvikelser från vad som beskrivs i standard, profil eller annan allmän doku- mentation som hänvisas till. Denna information lagras i ett minnesutrymme i datorn och överförs sedan på lämpligt format till ett for systemkonstruktörer åtkomligt medium. Detta kan vara en databas tillgänglig över Internet, CD-ROM skiva som distribueras via post, floppydiskar, etc. Det kan vara lämpligt att samtidigt lagra all för systenikonstruktören relevant övrig information om modulen, exempelvis specifikationer, handhavandebeskriv- ning, etc., i en eller flera textfiler på samma ställe.

Metoden enligt uppfinningen innebär att systemkonstruktörens arbete indelas i tre faser: En första fas där systemkonstruktören arbetar med modulmodeller enligt hans egna önsk- ningar, i fortsättningen kallade "dummymodu1er" Dessa behöver inte motsvaras av existe- rande moduler. Ett datorprogram, hädanefter kallat "systemverktyget", hjälper honom att kontrollera att systemet är logiskt korrekt och att beräkna prestanda. I en andra fas jämförs dummymodulerna med i en databas beskrivna verkliga moduler. För varje dummymodul utväljer systemverktyget möjliga verkliga moduler. Systemkonstuktören kan nu byta ut sina dummymoduler mot verkliga moduler och systemverktyget gör förnyad test av logik och prestanda samt presenterar eventuella avvikelser och nödvändiga korrigeringar.

Systemkonstruktören kan nu göra en slutlig modell av systemet. I en tredje fas kan systemverktyget, åtminstone om alla moduler följer CAN Kingdom, generera erforderlig 518 408 anpassningsinformation for varje modul samt en dokumentation av systemet. Om system- konstuktören valt en av systemverktyget känd systemmodul, i CAN Kingdom kallad Capital, så kan systemverktyget också generera en komplierbar kod for konfigurerings- och uppstartningsfórfarandet enligt CAN Kingdom.

Det hänvisas även till de kännetecknande delarna i de efterföljande oberoende patent- kraven.

FIGURBESKRIVNTNG Uppfinningen skall beskrivas med hjälp av efterföljande riktningar där figur 1 figur 2 figur 3 figur 4 figur 5 figur 6 figur 7 figur 8 visar i blockschemaform ett CAN-systems principiella uppbyggnad, visar i blockschemaform en modul ansluten till en CAN-buss, visar principiellt exempel på användbar hårdvara, visar i blockschemaform den principiella arbetsgången for att skapa en moduldefmition, i diagramform visar principiellt förfarandet for att skapa beskrivning av ifrågavarande layout, visar principiellt kopplingen mellan variabler och forms, visar utseende på skärmbild under arbetets gång, visar i diagramform och principiellt kopplingen och samverkan mellan olika block i anslutning till den genomförda processen, 518 408 figur 9 visar i blockschemaform och principiellt kopplingen mellan olika variabler och moduler, figur 10 visar i blockschemaform och principiellt generering av systemanpassnings- information, figur ll visar i blockschemaform och principiellt hur en dummymodell kan ersättas med modell av verklig modul, figur 12 visar i bla. blockschemaform och principiellt hur information kan över föras till en systemnod, figur 13 visar i blockschemaform och principiellt i datorenhet engagerade enheter och signaler dem emellan, och figur 14 visar en konstruktiv uppbyggnad på aktuella utnyttjade hårdvaru- komponenter.

DETALJERAD UTFÖRINGSFORM Målet är att med hjälp av datorstöd skapa ett CAN-system. Figur 1 visar ett sådant med bussen 101 som innehåller ett tvinnat ledarpar för CANsignalering och ett tvinnat led- ningspar för strömförsörjning. Till bussen 101 är anslutet moduler 102, 103, 104, 105 samt en systemnod, så kallad "Capital" i CAN Kingdom, 106. CANbussen är på sedvanligt sätt avslutad med termineringarna 107 och 108 och modulerna är strömförsörjda med ström- försörjningsenheten 109. Bussen 101 består av olika delar ll, 12, 13, 14, 15, 16 som kan ha olika längder och egenskaper som impedans, vågutbredningshastighet, motstånd, etc. vilket illustreras med avvikande tjocklek på delen 13. Modulema är anslutna med anslut- ningar a2 - a6 och strömförsörjningsenheten 109 med a9. Dessa anslutningar har också olika egenskaper. Figur 1 visar en vanlig uppbyggnad med en ren busstopologi, men system kan ha andra uppbyggnader som är varianter på busstopologi eller stjärntopologi. 518 408 Figur 2 visar en modul 201 som är ansluten till CANbussen 202 och strömförsörjnings- bussen 203 via kontaktdonet 200. Modulen 201 har en eller flera CPU:er 204, minnen 205, i CPU inbyggd eller fristående CAN controller 206 (exempelvis Intel 527), CAN driver 207 (exempelvis Philips 251), kommunikationsanpassningskretsar 208, spänningsregulator 209, oscillator 210, etc., schematiskt visat, byggd för CANprotokollet, som är ansluten/ /anslutningsbar till en enhet 211, ej närmare beskriven, som ger modulen dess fysiska egenskaper som utnyttjas i systemet, exempelvis styra en motor, läsa av läget på en spak, el. dyl.

Beskrivningen av datorhjälpmedlen är indelad i två delar: a) Beskrivning av modulverk- tyget och b) beskrivning av systemverktyget. a) Beskrivning av modulverktyget.

Modulverktyget är ett datorprogram, som exekveras i en forsta dator, för modulkonstruk- törer och har till uppgift att generera en så fullständig beskrivning av en modul som möjligt i en form som senare är tolkningsbar för systemverktyget. Exempel på lämplig hårdvara visas i figur 3 där 301 är en PC-dator med en Pentium CPU, hårddisk rymmande l Gbyte och 16 Mbyte RAM samt floppydiskdriver 302, CDdriver 303 och som via modem 304 är ansluten till telenät 300. Den kan även var vara ansluten till ett LAN på känt, ej i figuren visat, sätt. Datom är utrustad med tangentbord 305, datorskärm 306, mus 307 och eventuellt också med digitizer 308 samt en skrivare 309. Modulverktygs- programmet levereras med ett datamedium, exempelvis på diskett 310, CD-skiva 311 eller från en annan dator 312 som datafil il via telenätet 300.

Modulverktyget har två delar, en som beskriver modulen hårdvarumässigt och en som beskriver den mjukvarumässigt.

I den mjukvammässiga delen införes information om vilket higher layer protokoll som används. För varje higher layer protokoll följer sedan en anpassad inläsningsrutin. Om higher layer protokollet exempelvis är CAN Kingdom följer därtill relevant information 518 408 som vilka kungsbrev som supportas och till vilken del de supportas. Är protokollet DeviceNet följer inläsning om vilken profil som följs mm, Varje higher layer protokoll har någon forrn av identitet för tillverkaren och modultypen. I DeviceNet hänför sig denna till ett register hos ODVA, i CAN Kingdomfallet till registrering av EAN-B kod hos organisationen EAN International som har kontor i de flesta industriländer. Denna infor- mation införes. Vidare införes information om vilka variabler som modulen kan sända respektive mottaga, vilka datafomfiat som de har, alternativt om de återfinnes i någon allmänt accepterad profil eller om formatet är uppbyggbart med kommandon från en systemnod, verktyg eller dyl. i beroende av valt higher layer protokoll. Modulverktyget organiserar informationen i ett databasformat på ett sådant sätt att systemverktyget senare kan koppla variabler i olika moduler till varandra, beräkna prestanda, etc. Information som systemverktyget inte kan utnyttja, men som kan vara av värde för systemkonstruktören, läggs i en eller flera filer som systemkonstruktören kan läsa via systemverktyget. Exempel på sådan information kan vara personuppgifier på den som skapat modulbeskrivningen, detaljuppgifier om modulen som har betydelse för systemet men som systemverktyget inte (ännu) kan ta hänsyn till såsom måttuppgifter, valda komponenter, MTBF, detaljerad handhavande beskrivning, etc. Den så organiserade informationen överförs därefier till ett media som ger systemkonstruktören möjlighet att införa den i sitt verktyg. För detta ändamål kan informationen i2 läggas på en databas 315 allmänt tillgängligt på något data- nät, exempelvis Internet via telenätet 300, eller på CD-ROMskiva 313, diskett 314, etc.

Det fördelaktigt att informationen genereras i form av en textfil som sedan kan inläsas av systemverktyget. Eftersom informationen är viktig för den vidare behandlingen så bör textfilen förses med uppgifi om ansvarig person och/eller firma för filens skapande, med vilket verktyg det skapats och någon form av skydd mot förvanskning. För att identifiera firma och verktyg kan en EANkod vara lämplig. Denna medger också att identifikation av person ingår, exempelvis att serienumret utgörs av personnummer. För kontroll av att text- filen förblir oförvanskad kan den förses med checkod enligt någon gängse accepterad metod.

Den principiella arbetsgången för att skapa en moduldefinition med modulverktyget fram- går av figur 4. Först definieras variabler 401: Ett grundläggande begrepp i modulbeskriv- 518 408 ningen är variabeln. Variablerna i en modul definierar vilken information modulen kan producera eller konsumera. En variabel definieras med ett namn, ett symboliskt kortnamn, sin datarepresentation, sin datatyp, sin riktning (sändningsvariabel, mottagningsvariabel eller båda), sitt normalvärde (default), sin produktions- (for sändvariabler) eller utförande- tid (for mottagningsvariabler), möjligen en bitmask, samt en utforlig beskrivning på fritt format. Vidare kan man definiera fysikaliska parametrar som enhet (volt, kelvin, ampere, meter per sekund, ...), samt maxvärde och minvärde. Variabler är ett protokolloberoende begrepp och varje moduldefinition innehåller således ett antal variabler, oavsett vilket higher layer protokoll man väljer att använda. Variabler kan godtyckligt sammanforas till olika grupper vilka i sin tur kan grupperas. Denna gruppering har enbart administrativt syfte och tjänar till att underlätta arbetet med verktyget. Datarepresentationen är i det enklaste fallet sådana välkända begrepp som “unsigned integei”,“signed small integef, etc; for varje variabel kan individuellt anges längd i bitar och byte-ordning (intel eller motorola). Man kan dessutom definiera sammansatta variabler, vilket är en grupp av variabler definierade enligt ovan, under gemensamt namn (jfr struct i c). Den samman- satta variablen hanteras sedan som en enhet. Det finns möjlighet att definiera olika, tids- mässigt åtskilda faser i en modul, t ex uppstartfas, drifisfas och vilofas. En variabel kan definieras att gälla endast under en eller flera sådana faser.

Då variablerna är definierade måste meddelandelayouten definieras på något vis. Olika HLP tillåter olika mycket flexibilitet i detta avseende. Använder man CAN Kingdom defi- nierar man ett antal Forms 402. Varje Form definieras i sig med ett namn, ett symboliskt kortnamn, ett nummer, ett listnummer, riktning (sändning eller mottagning), och en beskrivning i fritt format. Sedan definieras Formens layout: variabler kan placeras på godtycklig plats i Formen, som i princip tjänar som en mappning till eller från ett CAN- meddelande. Figur 5 visar principiellt förfarandet. Varje variabels plats definieras med sin startposition, som är positionen for den minst signifikanta biten i variabeln. Utsträckning och riktning i formen är sedan implicit givet av variabelns definition (längd och byte-ord- ning). Användaren gör detta med ett grafiskt gränssnitt som visar Formen som ett antal konsekutiva bitar (som, när man använder CAN, är numrerade från -29 - -1 for arbitre- ringsdelen (CAN ID) och 0 - 63 for datadelen). Användaren kan sedan från en lista 500 518 408 10 över tillgängliga variabler “drå' variabler, exempelvis 501, till formen och“släppá* dem på önskad plats, exempelvis 502, och på samma sätt justera redan utlagda variablers plats i formen. Överlappande variabler visas med speciell färg. Förutom variabler definierade enligt ovan tillhandahåller programmet ett antal fördefinierade variabler med speciell betydelse, exempelvis “Reserveradfl “Sidnummef (används i nästa steg), “Nodnummefl “Basnummefl m fl modulparametrar.

Under definitionen av formens layout kan olika sökbegrepp användas i variabellistan, t ex att bara variabler med viss datarepresentation visas. Även for forms gäller att de kan grupperas till godtyckliga administrativa grupper, eller definieras att gälla endast i vissa driftsfaser.

Nästa steg är att definiera en mappning från innehållet i en viss del av meddelandet (sidnummer) till en viss meddelandelayout (Fornf). I CAN Kingdom görs detta genom att definiera Dokument, 403, som är en samling av Forms. Varje dokument definieras i sig av ett namn, ett symboliskt kortnamn, ett nummer, ett listnummer, en riktning och en utförlig beskrivning. Användaren definierar sedan vilka forms som ska höra till dokumentet och ger varje form ett nummer i dokumentet. Programmet kontrollerar sedan att att alla forms inom dokumentet har sina sidnummer på samma plats (bitposition). Modulen kommer sedan att använda innehållet på denna plats i CAN-meddelandena för att avgöra vilken Form som skall användas för att tolka det aktuella meddelandet. För utgående meddelanden används inversen: modulen konstruerar innehållet i sidnumret med ledning av vilket nummer formen har i det aktuella dokumentet. Dokument identifieras av ett nummer plus ett listnummer. Dessa nummer definieras av modulkonstruktören (enligt ovan).

För att möjliggöra en enhetlig numrering av dokumenten i systemet definierar modul- konstruktören (då CAN Kingdom används) Foldrar, 404, vilka tjänar som en avbildning från dokumentnummer i systemet till dokumentnummer i modulen, och vice versa. En Folder definieras i likhet med Dokument och Forms av ett namn, ett symboliskt kortnamn, ett nummer och en utförlig beskrivning. Modulkonstruktören definierar sedan varje 518 408 ll F olders innehåll, dvs. om det är tomt och att systemkonstruktören kan lägga in ett Doku- ment däri eller vilket Dokument som ligger där när någon annan modul refererar till mot- svarande Folders nummer.

Vidare har modulkonstruktören möjlighet att definiera en avbildning från CANbusidenti- fierare (Envelopes) till Foldrar och tvärtom, 405. Detta sker genom att räkna upp vilka Envelopes som motsvarar en given Folder. Använder man CAN Kingdom utelämnas normalt detta steg eftersom modulen då får denna information under systemets drift, men för andra protokoll kan det vara nödvändigt.

De ovannämna strukturerna (Variables, Forms, Documents, Folders, Envelopes) kan antingen definieras av modulkonstruktören enligt ovan, eller definieras dynamiskt under systemets uppstartfas eller under pågående drift. För dynamisk definition krävs naturligt- vis stöd för detta av det HLP (Higher Layer Protokoll) som modulen implementerar. För HLP som medger sådan dynamisk definition kan modulkonstruktören ange vilka defini- tionsprimitiver (Kings Pageš'i CAN Kingdom) som modulen tillhandahåller. För varje Kings Page kan anges till vilken grad primitiven är implementerad och också om några irreguljariteter förekommer. Ytterligare modulparametrar som nödnummer, basnummer, seriennummer, EAN -nummer, m.fl. kan också anges och sparas i moduldefinitionen.

I den håivarumässiga delen inläses information (406) om egenskaper som beror av hur CAN-delen, exemplifierad i figur 2, är uppbyggd. Exempel på sådan information år vilken CAN-Controller som används, tidsfördröjningar pga använd hårdvara, oscillatoms nog- grannhet, kontakteringens utformning, matningsspänning, strömförbrukning, etc. Vidare definieras hur modulens fysiska del (211) kan konfigureras (407) och information som måste finnas innan CANkommunikation kan ske, exempelvis modulens plats i systemet, baudrate, etc. Vidare definieras i 408 vilket HLP som följs och vilka delar inom detta, eventuella profiler, etc. Många moduler kan omkonfigureras på många sätt via CANmed- delanden vilket också definieras.

Modulkonstruktören kan också definiera dummymoduler. Detta år en normal modul där all meddelandelayout (Forms, Documents, Folders, Envelopes) är odefinierad. 518 408 12 Definitionen innehåller dock variabler och hårdvaruparametrar på samma sätt som ovan.

Dummymodulen markeras särskilt på skärmen och tjänar som mall (dvs. sökprofil) för systemkonstruktören då en modul ska utväljas ur moduldatabasen.

Organisation och implementering För att organisera en moduldefinition i datoms minne kan man använda någon form av kommersiellt tillgänglig objekt- eller relationsdatabas, exempelvis Paradox från Borland. I det följande beskrivs för överskådlighetens skull en enkel modell för hur tabellerna ska organiseras. Alla variabler lagras i en tabell, där modul-id och variabel-id utgör en sammansatt nyckel. Följande SQL-sats skapar variabeltabellen (Local SQL för Paradox 5.0) CREATE TABLE VARS ( MODULENO INTEGER, VARNO INTEGER, NAME CHAR(lO0), DESCRIPTION BLOB(l,l), DATASIZE INTEGER, DATAREPR INTEGER, DATATYPE CHAR(25), TRANSMIT BOOLEAN, RECEIVE BOOLEAN, OWNER SMALLINT, LITTLEENDIAN BOOLEAN, EXECTIME INTEGER, NICKNAME CHAR(32), DEFCONTENTS CHAR(32), PRIMARY KEY(MODULENO, VARNO)) Formarna lagras i en annan tabell, definierad av följande SQL-sats: CREATE TABLE FORMS ( MODULENO INTEGER, FORMID INTEGER, NAME CHAR(lOO), DESCRIPTION BLOB(l,l), OWNER SMALLINT, NICKNAME CHAR(32), RATIONALE BLOB(l,l), FORMNO INTEGER, PRIMARY KEY (MODULENO, FORMID)) CREATE INDEX FORMNUMBER ON FORMS(MODULENO, FORMNO) 518 408 Dokumenten lagras i en tabell enligt följande: CREATE TABLE DOCS ( MODULENO INTEGER, DOCID INTEGER, NAME CHAR(l28), DESCRIPTION BLOB(l, l), OWNER SMALLINT, NICKNAME CHAR(32), RTR BOOLEAN, DOCNO INTEGER, PRIMARY KEY(MODULENO, DOCID)) CREATE INDEX DOCNUMBER ON DOCS(MODULENO,DOCNO) Foldrama lagras i följande tabell: CREATE TABLE FOLD( MODULENO INTEGER, FOLDERID INTEGER, NAME CHAR(50), DESCRIPTION BLOB(l,l), OWNER SMALLINT, NICKNAME CHAR(32), DLC INTEGER, RTR BOOLEAN, FOLDERNO INTEGER, PRIMARY KEY(MODULENO, FOLDERID)) CREATE INDEX FOLDERNUMBER ON FOLD(MODULENO,FOLDERNO) Envelopen lagras i följande tabell: CREATE TABLE ENV( MODULENO INTEGER, ENVID INTEGER, FOLDERID INTEGER, STANDARD BOOLEAN, OWNER SMALLINT, ENVNO INTEGER, PRIMARY KEY(MODULENO, ENVID)) CREATE INDEX ALLENV ON ENV(ENVNO) CREATE INDEX ENVNBR ON ENV(MODULENO,FOLDERID,ENVNO) CREATE INDEX ENVNBR2 ON ENV(MODULENO,ENVNO) 518 408 14 Kopplingen mellan variabler och Forms görs med följ ande tabell: CREATE TABLE FORMLAY ( MODULENO INTEGER, FORMID INTEGER, LAYOUTNO AUTOINC, VARIABLENO INTEGER, STARTPOS INTEGER, OWNER SMALLINT, DATASIZE INTEGER, PRIMARY KEY(MODULENO, FORMID, LAYOUTNO)) CREATE INDEX POS ON FORMLAY(MODULENO, FORMID, STARTPOS) CREATE INDEX VAR ON FORMLAY(MODULENO, VARIABLENO) Kopplingen mellan Forms och Documents görs med följande tabell: CREATE TABLE DOCLAY( MODULENO INTEGER, DOCID INTEGER, FORMID INTEGER, PAGENO INTEGER, OWNER SMALLINT, PRIMARY KEY(MODULENO, DOCID, FORMID, PAGENO)) CREATE INDEX PAGENUMBER ON DOCLAY (MODULENO, DOCID, PAGENO) CREATE INDEX FORMNUMBER ON DOCLAY (MODULENO, FORMID) Kopplingen mellan Dokument och Foldrar görs med följande tabell: CREATE TABLE FOLDCONT ( MODULENO INTEGER, FOLDERID INTEGER, DOCID INTEGER, OWNER SMALLINT, PRIMARY KEY(MODULENO, FOLDERID)) CREATE INDEX DOCUMENTNUMBER. ON FOLDCONT (MODULENO, DOCID, FOLDERID) Modulerna lagras i följande tabell: CREATE TABLE MODULES( NUMBER INTEGER, NAME CHAR(lOO), SCHEMATICNAME CHAR(50), DESCRIPTION BLOB(l,l), VENDOR CHAR(50), EAN CHAR(l6), VENDORID CHAR(32), PICTURE BLOB(O,5), BITMAP BLOB(O,5) I 518 408 15 NODENO INTEGER, BASENO INTEGER, CAPITAL BOOLEAN, BASENOUNKNOWN BOOLEAN, SERIALNO CHAR(l6), HWNAME CHAR(32), CANDRIVER CHAR(32), CANCTRL CHAR(32), CLOCKFREQ INTEGER, CLOCKACC INTEGER, EXTRADRIVERDELAY INTEGER, CSUM CHAR(l6), FLAGS INTEGER, DUMY BOOLEAN, PRIMARY KEY(NUMBER)) Kopplingarna mellan variabler görs med följande tabell: CREATE TABLE VARASSG( MODULENO INTEGER, SRCVARNO INTEGER, DSTMODULENO INTEGER, DSTVARNO INTEGER, PHASE INTEGER, PERIOD INTEGER, DEADLINE INTEGER, OWNER INTEGER, PRIMARY KEY(MODULENO, SRCVARNO, DSTMODULENO, DSTVARNO)) CREATE INDEX DEAD ON VARASSG(DEADLINE) CREATE INDEX DSTVAR ON VARASSG(DSTMODULENO, DSTVARNO) Uppgifier om modulens olika datatyper lagras i tabellen DATAREP: CREATE TABLE DATAREP ( NR INTEGER, NAME CHAR(40), DESCRIPTION CHAR(64), DATASIZE SMALLINT, COMPATIBLE_WITH INTEGER, PRIMARY KEY(NR)) och tabellen VARS lagrar för respektive variabel ett nummer som motsvarar fältet NR i denna tabell.

Kopplingarna mellan tabellerna görs genom att kopplade poster innehåller identiska värden i sina indexfált. Exempelvis (se figur 6) kopplas variabler och Forms genom att man i varje post i tabellen FORMLAY anger modulnummer, variabelnummer, form- 518 408 16 nummer samt ett löpnummer. Denna fyrtupel identiflerar unikt en post i FORIVILAY, samtidigt som tupeln (modulnummer, variabelnummer) unikt identifierar en variabel och tupeln (modulnummer, formnummer) unikt identifierar en Form. För varje på detta vis definierad post i FORMLAY anger man dessutom kopplingsattribut, i detta fall variabelns position på Formen (fältet STARTPOS) samt en del administrativ information (exempel- vis fältet OWNER).

Kopplingar mellan övriga tabeller sker på liknande vis.

Det är mindre lämpligt att använda databasformatet direkt när en moduldefinition eller systemdefinition ska distribueras på datamedium till andra användare av verktyget. Det finns nämligen ingen garanti för att alla verktyg använder samma sorts databas. Av den anledningen finns det möjlighet att exportera en modul- eller systemdefinition i form av en vanlig textfil, vilken sedan kan importeras till mottagarens verktyg på ett enkelt sätt.

Formatet på denna textfil är konstruerat så att det skall vara möjligt att i framtiden lägga till ny information utan att behöva förändra formatet eller skapa inkompabiliteter av annan SOIT.

Textfilen består av ett antal block vilka består av ett namn (identifierare) och ett godtyck- ligt antal poster. En post kan antingen i sin tur vara ett block, eller bestå av ett namn (identifierare), ett likhetstecken (=), och ett värde, som kan vara ett tal eller en sträng, omgiven av citationstecken (“). För att kunna medtaga även tecken som saknar grafisk representation (t ex vagnretur, bakåtsteg m fl.) kan det i en sådan sträng finnas speciella escape-koder, vilka typiskt består av bakåtsnedstreck O), bokstaven “x och två hexa- decimala siffror vilkas värde (tolkat enligt gällande ISO-standard) anger vilket tecken som aVSCS.

Posterna inom ett block avgränsas av radslut. Blocket inleds med vänsterklammer ({) och avslutas med högerklammer (}). Textfilen inleds med ett speciellt block som definierar versionsnumret på textfilen som sådan; detta medger att ett verktyg kan tolka olika text- filer, även om de har genererats av olika versioner av verktyget. 518 408 17 I den nuvarande definitionen av textfilens innehåll innehåller den ett block för varje tabell i databasen. Varje post i databasen motsvaras av ett underblock, och varje fält i en post motsvaras av en post i detta underblock.

Nycklarna i databasen är unika endast inom varje installation av programmet. För att lösa problemet med distribution av modul- och systemdefmitioner (nycklarna i en med en modul distribuerad definition blir inte med säkerhet unika när de används i en viss instal- lation) sker vid import av den ovan nämnda textfilen en omnumrering av modulnumret i varje post. Eflersom tabellerna alltid är indexerade delvis med modulnumret räcker denna omnumrering (inga andra fält behöver ändras) och proceduren går snabbt och är enkel att implementera, Modulkonstruktören definierar sin modul enligt ovan, men kan, om han välj er ett lämpligt HLP, t ex CAN Kingdom, lämna vissa delar odefinierade. Dessa delar fylls sedan i av modulens slutanvändare/systemkonstruktören.

För varje post i databasen lagras information om vem som lagt till den (eller ändrat den) - dels information om användarens identitet, dels finns ett fält som indikerar om posten “iillhöïmodulen eller systemet, och om den är manuellt eller automatiskt genererad. Alla poster som läses från moduldatabasen anses tillhöra modulen och är följaktligen ändrings- skyddade i systemverktyget. Systemverktyget kan sedan generera en lista över hur syste- met ska konfigureras vid uppstart helt enkelt genom att se efier vilka poster i projektdata- basen som “tillhöf systemet och för varje sådan post generera lämplig anpassningsinfor- mation. Vidare kan systemverktyget skilja automatgenererade poster från manuellt gene- rerade via samma fält, och har därigenom möjlighet att ta bort sådan information ur data- basen som genererats vid tidigare kömingar med systemverktyget, utan att samtidigt ta bort sådan information som användaren lagt dit manuellt. Att det för varje post lagras information om vem (personidentifikation) som ändrat en viss post gör att man har spår- barhet i ett projekt (eller modul). Verktyget kan också lagra information i en separat logg- fil om vilka ändringar som gjorts, så man kan också spåra borttagningar av information. 518 408 18 b) Systemverktyget I systemverktyget kan modulmodeller konstrueras på samma sätt som i modulverktyget.

Systemkonstruktionen sker i en andra dator ekvivalent med den förut beskrivna forsta datorn i figur 2. Information om flera moduler inläses i datorn via datamedium(-a) Systemkonstruktören börjar sitt arbete med att på dataskärmen lägga ut det antal dummy- moduler som han har for avsikt att använda i sitt system. Dessa sammankopplas med linjer som representerar CANbussen och anslutningar till denna. CANbussen kan bestå av flera delar och vara grenad. I systemverktyget finns, kan av konstruktören skapas, eller av leve- rantör tillhandahållas for inläsning i systemverktyget, modeller av kablar, termineringar, kontakter, strömförsörjning, etc. med relevanta fysikaliska data som elektriskt motstånd, motstånd per meter, impedans, vågutbredningshastighet, spänning, ström, etc. Med hjälp av dessa data skapas en modell av systemets hårdvaruuppbyggnad och egenskaper genom att CANbussegmenten och anslutningarna kopplas till kabelmodellerna, modell av spän- ningsforsörjningen infores, etc. Dummymodulerna kan redan från början ha defaultvärden på hårdvarubeskrivningen av dessa och med denna information kan systemverktyget redan nu räkna fram for systemkonstruktören relevant information som teoretisk maximal bit- hastighet, teoretisk amplitudnivå vid varje modul, etc. Detta kan leda till att system- konstruktören gör en revidering av sitt kabelval, val av strömförsörjning och placering, layout på systemet, ändra tidsfordröjningar, oscillatornoggrarmhet, etc. Exempel på hur en skärmbild kan te sig under arbetets gång visas i figur 7.

När systernkonstruktören är nöjd med den fysiska konstruktionen av sitt nät så börjar han tillföra information till dummymodulerna. Detta innefattar, men är inte begränsat till, defi- nition av variabler på samma sätt som i modulverktyget. Variablerna i dummymodulen representerar den information som systemkonstruktören vill skicka mellan de olika noderna i systemet. Systemkonstruktören definierar sedan informationsflödet genom att associera sändvariablerna i de olika dummymodulerna med mottagningsvariabler i andra dummymoduler i systemet. För varje sådan koppling anges bland annat tidsmässiga krav på överföringen, som till exempel en största tillåten överforingstid, ett minsta intervall mellan två överföringar, om överforingen är periodisk eller aperiodisk, etc. I likhet med 518 408 19 vad som gäller för variabeldefinition i modulverktyget kan en association definieras att gälla endast i vissa, av systemkonstruktören definierade, systemfaser, t ex en driftsfas, en vilofas eller en uppstartfas.

Med den givna informationen kan nu systemverktyget, med hjälp av vissa antaganden (t ex att alla variabler transporteras i separata CAN-meddelanden), räkna ut om systemet är schemaläggningsbart, dvs. om all information kan garanteras nå fram inom högst den angivna maximala överföringstiden. I verktyget finns en eller flera schemaläggnings- modeller (som t ex deadline monotonic, se Tindell m fl) för schemaläggning av meddelan- den. Modellerna kan vara av enklare slag som förutsätter att inga överföringsfel förekom- mer, eller av mera komplicerat slag som också tar hänsyn till att fel kan förekomma.

Systemkonstruktören välj er lämplig modell och verktyget kontrollerar att de uppgifter som behövs for att generera schema är inläst av konstruktören. Om uppgifier saknas begärs de av konstruktören, i annat fall genomförs en generering av schemaläggningen. Algoritmer for sådana beräkningar är kända (Tindell m fl). Om analysen ger vid handen att vissa meddelanden inte kan garanteras nå fram inom den angivna maxtiden, får system- konstruktören vidta lämpliga åtgärder som t ex öka bithastigheten på bussen eller minska informationsflödet i systemet. Schemaläggningen kan exempelvis utmynna i en prioritets- ordning för sändobjekten, generera tidpunkter för när meddelanden skall sändas, ange vilka meddelanden som skall initiera sändning av andra meddelanden, etc. allt i beroende av kring vilka principer schemaläggningsmodellen/algoritmen är uppbyggd kring. Vidare frarnräknas maximala fördröjningstider alt. statistisk sannolik framkomsttid, och kontrolle- ras att dessa ligger inom de av konstruktören angivna gränserna. Om några gränser inte kan mötas, visas dessa i en tabell, alt, grafiskt på skärmen.

Nu har systemkonstruktören en kravspecifikation på alla moduler. Systemverktyget kan nu gå igenom databasen och ge förslag på moduler som helt eller delvis motsvarar respektive dummymodul, Detta sker genom att matcha dummymodulens variabler mot i den verkliga modulen definierade variabler och jämföra dessa med avseende på dataformat, fysikalisk enhet m fl definierade variabelparametrar. Lämpliga moduler presenteras i en lista på skärmen. Systemkonstruktören byter ut en, flera eller alla dummymoduler mot lämpliga 518 408 20 modeller av verkliga moduler. I vissa fall kan systemverktyget direkt koppla dummy- variablerna mot motsvarande variabler i respektive modulmodell, i andra fall får konstruktören gör denna koppling för hand. Enklast är givetvis om alla moduler supportar samma higher layer protokoll, men det är inte nödvändigt. Ofia kan, när det finns en systemmodul i systemet, moduler som följer olika higher layerprotokoll fås att utbyta information relevant för systemets fiinktion. Systemnoden programmeras då att simulera funktioner som krävs enligt respektive protokoll hos alla moduler, men som saknas i de av konstruktören valda som följer ett annat higher layer protokoll. I en enklare variant av systemverktyget anger detta bara att den valda modulen avviker beträffande higher layer protokoll, i en avancerad variant genererar verktyget vilka funktioner och vilken informa- tion som saknas och hur den skall tillföras systemet. När dummymodulen eller -modulema är ersatta så kan systemverktyget genomföra en förnyad kontroll och schemaläggning och systemkonstruktören kan successivt förfina sin konstruktion.

Kopplingen mellan variabler framgår av figur 9. I moduler 901, 902, 903 anslutna till CAN-bussen 905 finns variabler V1, V2, V3, V4 och V5. Med systemverktyget associerar systemkonstruktören V2 med V4 och anger därmed att informationen representerad av V2 i modulen 901 skall skickas till modulen 902, där den skall tilldelas variabeln V4. En variabel kan även ha flera mottagare; i figuren är variabeln V1 kopplad till V3 i modul 902 och till V4 i modul 903.

Utgående från denna information kan systemverktyget alstra systemanpassningsinforma- tion, vilket minst innebär att associerade variabler tilldelas samma CAN-id och samma plats i CAN-meddelandet. Användes CAN Kingdom kan även ytterligare information genereras, såsom Form-layout, sammansättning av Dokument, etc. I figur 10 visas för ett enkelt fall hur systemanpassningsinformationen genereras. I systembeskrivningen 1004 är två variabler 1001 och 1002 associerade (1003) med beskriven metod. Från detta genere- rar systemverktyget mallar för CAN-meddelanden 1006 och 1007, med arbitreringsfält il och i2, kontrollfalt cl och c2, och datafalt dl och d2 respektive. Eftersom variablerna är hopkopplade skall il = i2, cl = c2 och datafälten dl och d2 ska ha samma plats och struk- tur i de båda meddelandena. Informationen överförs sedan till det verkliga systemet 1012 518 408 21 med motsvarande verkliga moduler 1008 och 1009, sammankopplade via CAN-bussen 1011. Den mellan modulerna överenskomna meddelandelayouten 1006,1007 kan nu användas i det verkliga CAN-meddelandet 1010. För val av CAN-identifierare kan den tidigare nämnda prioritetsordningen över systemets alla sändvariabler användas. Den högst prioriterade variabeln tilldelas en CAN-identifierare med lägsta numeriskt värde som inte redan är upptaget i systemet. Motsvarande mottagningsvariabler tilldelas samma identifierare. Den näst högst prioriterade variabeln tilldelas nästa identifierare i numerisk följd, varvid systemverktyget kan ta hänsyn till att ett visst bitmönster i identifieraren krävs av t ex filtreringsskäl eller för att någon modul i systemet använder ett HLP där vissa bitar i identifieraren används för att beteckna vissa egenskaper hos meddelandet (t ex DeviceNet).

Figur 11 visar hur en dummymodul 1103 i en systembeskrivning 1112, med variabler V1 och V2 (associerade 1101, 1102 till variabler V3, V4 i annan modul 1104, dummy eller verklig) ersätts med en modell av en verklig modul. Modulen 1103 markeras (1105) och dess variabler Vl,V2 identifieras med andra modulers variabler (V3,V4, hörande till modulen 1106, och V5,V6 hörande till modulen 1107). De verkliga modulmodellerna 1106 och 1107 lagras i databasen 1113. I detta fall passar modul 1107 men inte 1106. 1107 extraheras därför ut ur databasen och placeras in (1110) i systembeskrivningen 1114.

Variabelassociationer 1108 och 1109 är oförändrade, likaså modulen 1104.

När han så är nöjd genererar systemverktyget en i stort sett fiillständig dokumentation av systemets väsentliga delar. Om modulerna i systemet följer ett higher layer protokoll som kräver att modulerna under en uppstartnings eller konfigureringssekvens via CANmed- delanden konfigureras att passa systemet så genererar systemverktyget erforderlig anpass- ningsinformation. (Se ovan) Om higher layer protokollet är CAN Kingdom, så genererar systemverktyget erforderliga kungssidor till varje modul att utsändas av kungen. I vissa fall krävs också att modulen tillförs viss information före anslutning till CANbussen, exempelvis fysisk adress i nätet, bithastighet för systemet och base number. Verktyget ger en lista på sådan information för varje modul. 518 408 22 Figur 12 visar hur informationen överförs till systemnoden 1201 (“Capital” om CAN Kingdom används). Med systemverktyget som körs i en dator 1209 genereras system- anpassningsinformation 1210 enligt beskriven metod. Informationen överförs (1211) exempelvis via CAN-bussen eller annan seriekommunikation, beroende på vad modulen 1201 klarar, eller programmeras direkt in i modulens PROM. Modulen 1201 kan nu genom att skicka CAN-meddelanden 1204,1205,1206 enligt något lämpligt I-HJP (Device- Net, CAN Kingdom) etablera förbindelse mellan modulerna 1202 och 1203, så att de i systembeskrivningen definierade associationema 1207, 1208 förverkligas. Modulerna 1202 och 1203 kommer efier detta att skicka ut CAN-meddelanden (1010) på överens- kommen layout och med överenskommen identifierare, på det sätt visas i figur 10.

Systemkonstruktören har nu en systemspecifikation och en grund för systembeskrivning. I beroende på valt higher layer protokoll kan systemverktyget generera erforderlig anpass- ningsinformation, exempelvis ovan nämnda kungssidor för CAN Kingdom. Verktyget kan generera denna information på flera sätt, exempelvis som pappersutskrifi. I många fall är det fördelaktigt att informationen genereras i form av en textfil som sedan kan inlåsas i andra datorprogram, exempelvis ordbehandlare, för vidare bearbetning. Eñersom infor- mationen är viktig för vidare behandling så bör textfilen förses med uppgifi om ansvarig person och/eller firma för filens skapande, med vilket verktyg det skapats och någon form av skydd mot förvanskning. För att identifiera firma och verktyg kan en EANköd vara lämplig. Denna medger också att identifikation av person ingår, exempelvis genom att serienumret utgörs av personnummer. För kontroll av att textfilen förblir oförvanskad kan den förses med checkod enligt någon gängse accepterad metod. Om systemnoden suppor- tas av systemverktyget kan detta generera en kompilerbar kod, exempelvis en C-kod, av anpassningsinformationen. 518 408 23 Under arbetets gång kan användaren av systemverktyget analysera systemet ur olika aspekter. Exempelvis kan man beräkna huruvida systemet är realiserbart ur realtidssyn- punkt. Detta sker genom att man for varje variabel-till-variabelkoppling anger en deadline och en periodicitet. Systemverktyget kan sedan enligt kända algoritmer (Tindell) beräkna vilka identiflerare som de olika meddelandena måste använda, eller ge felmeddelande om inte alla deadlines kan uppfyllas.

Claims (24)

518 408 . . a | n: 24 PATENTKRAV

1. Metod att medelst en eller flera datorenheter alstra ett systemprotokoll för styr- och/eller kontrollutrustning till en eller flera maskiner och/eller processer där utrustningen innefattar ett antal moduler (styrmoduler) som är kommunicerbara med varandra via en seriell digital förbindelse i enlighet med nämnda systemprotokoll, k ä n n e t e c k n a d därav, att i ett första minnesutrymme införes första data om ett basprotokoll, företrädesvis ett protokoll enligt CAN (Controller Area network, standard ISO 11 898) och att till nämnda första minnesutrymmen kan tillföras andra data om ett eller flera päbyggnadsprotokoll som anvisar möjliga grundfunktioner för rnodulernas inbördes beteende i samkommunikationen, och att i ett andra minnesutrymme införes tredje data om ett basprotokoll, företrädesvis ett protokoll enligt CAN (Controller Area network, standard ISO 11 898) och att till nämnda andra minnesutrymme kan tillföras fjärde data om ett eller flera påbygg- nadsprotokoll som anvisar önskade grundfunktioner för modulernas inbördes bete- ende i samkommunikation, ß att medelst datorenheten(-erna), i ett interaktivt samspel mellan denna/dessa och en användare, t.ex. en systemkonstruktör, genereras systemprotokollet baserat på första, andra, tredje och fjärde data i nämnda första och andra minnesutrymmen.

2. Metod enligt patentkravet 1, k ä n n e t e c k n a d därav, att nämnda datorenhet(-er) innefattar en utskrivningsdel, medelst vilken till systemprotokollet hänförbar data genereras och överföres till en databas som tillhandahälles som sepa- rat komponent till datorenheten(-erna).

3. Metod enligt patentkravet 1, k ä n n e t e c k n a d därav, att nämnda datorenhet(-er) innefattar en utskrivningsdel, medelst vilken till systemprotokollet 518 408 25 hänförbara data genereras och överföres eller tillföres via nämnda förbindelse, t.ex. till utvalda moduler.

4. Metod enligt patentkravet 1, 2 eller 3, k ä n n e t e c k n a d därav, att på en nämna datorenhet(-er) tillhörig datorskärm presenteras uppbyggnadssärdrag för grundprotokollet medelst första aktiveringar av datorenheten(-erna), att i beroende av andra aktiveringar på datorenheten(-erna) presenteras uppbyggnadssärdrag för ett eller flera av påbyggnadsprotokollen, och att medelst tredje aktiveringar på datoren- heten(-erna) utväljes åtminstone delar av sistnämnda uppbyggnadssärdrag och inter- folieras eller inlemmas helt eller delvis i förstnämnda uppbyggnadssärdrag.

5. Metod enligt patentkravet 4, k ä n n e t e c k n a d därav, att nämnda presentationer, utval och interfolieringar/inlemningar effektueras medelst datoren- heten(-erna) tillhörande program.

6. Metod enligt patentkravet 4, k ä n n e t e c k n a d därav, att variabler definieras, att forms definieras, att dokumenten dokomenteras, att folders eventuellt definieras och att envelopes definieras för ernående av moduldeñnition och att som parallell och eventuell samtidig aktivitet hårdvaran definieras, modulparametrarna definieras samt konfigurativprimitiverna definieras.

7. Metod enligt något av föregående patentkravet, k ä n n e t e c k n a d därav, att medelst programmet och interaktion utväljes CAN-idcntifierare som skall ingå i systemet.

8. Metod enligt något av föregående patentkrav, k ä n n e t e c k n a d därav, att medelst programmet och interaktion utväljes och sammansättes systemets moduler och sammankopplingsenheter.

9. Metod enligt patentkravet 8, k ä n n e t e c k n a d därav, att anpass- ningsinformationen genereras i form av en textfil. 518 408 26

10. Metod enligt patentkravet 9, k ä n n e t e c k n a d därav, att textfilen innehåller information om systemkonstruktörens och/eller hans företags identitet.

11. Metod enligt något av föregående patentkrav, k ä n n e t e c k n a d därav, att en graflsk bild av modellen visas på bildskärm utvisande logisk sammankoppling av modulerna.

12. Metod enligt patentkravet 11, k ä n n e t e c k n a d därav, att ledarnas förbindelselängd mellan modulerna och fysikaliska data om ledarna och termine- ringarna införes samt att för kommunikation prestandabegränsande egenskaper såsom tidsfördröjningar och oscilatornoggrannhet införes i respektive modulmodell och att programmet använder denna information för att framräkna teoretiskt begrän- sande fysikaliska värden för en säker kommunikation som amplitudnivâer och högsta värde på tillåten bithastigheten och presenteras.

13. Metod enligt patentkravet 12, k ä n n e t e c k n a d därav, att tidskrav införes på maximalt tillåten överföringstid av meddelanden och att det i programmet ingår en eller flera beräkningsalgoritmer som användes av programmet för schema- läggning av meddelanden för att möta dessa krav.

14. Metod enligt något av ovanstående patentkrav, k ä n n e t e c k n a d därav, att anpassningsinformationen genereras i form av kompilerbar datakod.

15. Metod enligt något av ovanstående patentkrav, k ä n n e t e c k n a d därav, att i den andra enheten skapas dummymoduler med önskade egenskaper i systemmodellen och att datorn medelst programvara jämför önskade egenskaper med de i databasen liggande modulmodeller och att de(-n) bäst passande modellen(-erna) presenteras och att systemkonstruktören i sin systemmodell kan utbyta dummy- modul(-er) mot modellmodul(-er) i databasen.

16. Metod enligt något av ovanstående patentkrav, k ä n n e t e c k n a d därav, att modulinformationen genereras i en första enhet och att systemmodellen 518 408 " 1? kan skapas i en andra enhet och modulinformationen överföres från den första en- heten till den andra enheten via dataöverföringsmedium och att informationen från den första enheten lagras i den andra enheten i en databas där den kan knytas till en eller flera modulmodeller i systemmodellen.

17. Metod enligt något av ovanstående patentkrav, k ä n n e t e c k n a d därav, att modeller skapas av i systemet ingående moduler, dessa sammankopplas till ett nätverk, modulsammankopplingarnas fysikaliska egenskaper modelleras, koppla sända meddelanden till mottagare, skapa modell av systemet, med hjälp av datorn och ingående program presenteras erhållna prestanda alternativt testas att systemmodellen motsvarar ställda systemkrav och om dessa inte är uppfyllda, kan modifieras i systemmodellen ingående delmodeller eller kraven så att en modell av systemet törefinnes som motsvarar ställda krav och att kraven på i systemet ingå- ende delar med hjälp av datorn och ingående program jämföres med i databasen föreliggande modeller och utväljas de som bäst motsvarar de i systemmodellen ingå- ende delar, att dessa presenteras på bildskärmen och att skapade modeller kan utby- tas mot de i databasen utvalda och att datorn med ingående programvara kan testas av datorn den nya systemrnodellen mot uppställda krav.

18. Anordning för att medelst en eller flera datorenheter åstadkomma systemprotokoll, företrädesvis baserat på CAN-protokollet, för styr- och/eller kon- trollutrustning till en eller flera maskiner och/eller processer där systemet innefattar ett antal datoriserade moduler som är kommunicerbara med varandra via en seriell digital förbindelse i enlighet med nämnt eller nämnda protokoll samt utnyttjande en åfëffiflfilwvfir' prototyp på hela eller delar av systemet, k ä n n e t e c k n a d därav, att nämnd eller nämnda datorenheter innefattar eller är anslutna till minnesorgan och/eller datorbas(-er), i vilken/vilka dels första informationer (första data) om i systemet användbara basprotokoll och påbyggnadsprotokoll för basproto- l kollet(-en) för bildandet av systemprotokollet är införda och åtkomliga, dels andra informationer (andra data) om i systemet användbara modultyper och dessas upp- byggnader och funktioner i modulernas sarnkommunikation via förbindelsen är in- förda och åtkomliga, att nämnd eller nämnda datorenheter är anordnad(-e) att med 518 408 28 hjälp av ett verktyg (första program) och i beroende av interaktion med en använ- dare alstra baserat på de första och andra informationerna nämnda prototyp på hela eller delar av nämnt system, effektuera en aktivering av prototypens funktionsut- övning samt granska prototypens prestanda, t.ex. med avseende på prioritetsord- ningen mellan modulernas utväxlade meddelanden, bithastigheter för förbindelsen, etc., att nämnd eller nämnda datorenheter innefattar en prestandaavkännande gene- rator (andra program), till vilken signaler hânförbara från nämnda prestanda är på- matningsbar, att den prestandaavkännande generatorn ur nämnda signaler (prestandasignaler) utvinner tredje informationer inmatningsbara på ett datoren- heten(-erna) tillhörande presentationsorgan, t.ex. i form av en skärm, VDU, etc., vilka tredje informationer ligger till grund för modifiering av prototypen, osv.

19. Metod för att medelst en eller flera datorenheter åstadkomma systempro- tokoll, företrädesvis baserat på CAN-protokollet, för styr- och/eller kontrollutrust- ning till en eller flera maskiner och/eller processor där systemet tilldelas ett antal datoriserade moduler som är kommunieerbara med varandra via en seriell digital förbindelse i enlighet med nämnt eller nämnda protokoll samt där en prototyp fram- tages och granskas på hela eller delar av systemet, k ä n n e t e c k n a d av att första och andra informationer tillföres i nämnd eller nämnda datorenheter ingående eller till dessa anslutna minnesorgan, där de första informationerna utgöres av i systemet användbara basprotokoll och påbyggnadsprotokoll för respektive basproto- koll som möjliggör bildandet av systemprotokollet samt de andra informationerna utgöres av i systemet användbara modultyper och dessas uppbyggnader och funktio- ner i modulernas samkommunikation via förbindelsen, att i ett interaktivt förfarande mellan nämnd eller nämnda datorenheter och en användare alstras prototypen som därvid baseras på de första och andra informationerna, effektueras en aktivering av prototypens funktionsutövning samt granskas prototypens prestanda, t.ex. med avse- ende på prioritetsordningen mellan modulerna, bithastigheter på förbindelsen, etc., att signaler hänförbara från nämnda prestanda extraheras från prototypen och påma- tas en prestandaavkännande generator, att ur generatorn utvinnes i beroende av nämnda signaler (prestandasignalerna) tredje informationer som inmatas på ett 518 408 2°7 datorenheten(-erna) tillhörande presentationsorgan, och att de tredje informationerna lägges till grund för modifiering av prototypen, osv.

20. Metod för att medelst en eller flera datorenheter åstadkomma systempro- tokoll, företrädesvis baserat på CAN-protokollet, för styr- och/eller kontrollutrust- ning till en eller flera maskiner och/eller processer där systemet innefattar ett antal datoriserade moduler som är kommunicerbara med varandra via en seriell digital förbindelse i enlighet med nämnt eller nämnda protokoll samt där hela eller delar av systemet är indikeringsbart på en eller flera datorskärmar som prototyp, k ä n n e- te c k n a d därav, att ett första verktyg (program) för att möjliggöra beskrivningar av modulerna alstras i respektive berörda dator i en interaktion med en användare där inmatning effektueras av information, såsom typ av protokoll, parametrar, data- format, osv., att det första verktyget (programmet) är läsbart av ett andra verktyg (program) som med hjälp av det första programmet och eventuellt minneslagrat ytterligare information om modulerna och/eller systemet alstrar systemprotokollet i en interaction med användaren.

21. Metod för att medelst en eller flera datorenheter åstadkomma systempro- tokoll, företrädesvis baserat på CAN-protokollet, för styr- och/eller kontrollutrust- ning till en eller flera maskiner och/eller processer där systemetinnefattar ett antal datoriserade moduler som är kommunicerbara med varandra via en seriell digital förbindelse i enlighet med nämnt eller nämnda protokoll där på en eller flera dator- maskiner hela eller delar av systemet är indikerbart, k ä n n e t e c k n a d därav, att i en första fas alstras i prototypen ingående preliminära moduler (dummy model- ler) enligt uppställda önskemål, att medelst ett systemverktyg (datorprogram) kon- trolleras företrädesvis i interaktion med en användare, att det därvid erhållna syste- met arbetar på ett logiskt korrekt (förutbestämt) sätt samt att medelst systemverk- tyget systemets prestanda är mätbara och/eller beräkningsbara; att i en andra fas jämföres de preliminära modulerna med i en databas och/eller andra minnesorgan beskrivna verkliga eller existerande moduler (t.ex. standardmo- duler), att systemverktyget utväljer en eller flera verkliga moduler för ersättning av 518 408 30 en eller flera preliminära moduler, företrädesvis samtliga preliminära moduler, att i prototypen resp. utvalda modul ersätter resp. preliminära modul samt att medelst systemverktyget utföres förnyad kontroll av systemets logik och prestanda och att medelst systemverktyget initieras och anges eventuella avvikelser och nödvändiga korrigeringar, osv., för möjliggörande av slutlig prototyp av systemet och därmed fastställande av systemprotokollet.

22. Metod enligt patentkravet 21, k ä n n e t e c k n a d därav, att i en tredje fas genereras med systemprotokollet en anpassningsiriformation för varje modul samt en dokumentation av systemet varjärnte medelst systemverktyget eventuellt genereras en kompilerbar kod för konflgurerings- och uppstartningsförfarandet av systemet.

23. Metod för att medelst en eller flera datorenheter åstadkomma systempro- tokoll, företrädesvis baserat på CAN-protokollet, för styr- och/eller kontrollut-rust- ning till en eller flera maskiner och/eller processer där systemet innefattar ett antal datoriserade moduler som är kommunicerbara med varandra via en seriell digital förbindelse i enlighet med nämnt eller nämnda protokoll samt där hela eller delar av systemet är indikeringsbart på en eller flera datorskärmar som prototyp, k ä n n e te c k n a d av a) framtagning, Lex. från olika häll (av olika beskrivare), beskrivningar av modulerna medelst ett eller flera modulverktyg (program) i en' eller flera första datorer, b) framtagning av ett antal preliminära moduler ingående i prototypen i en eller flera andra datorer, C) framtagning av iterativa förfarande av en beskrivning av den fram- ställda prototypen, d) bearbetning av beskrivningen till en dokumentation av systemet samt - underlag för programmering av respektive modul i den andra datorn(-erna), 518 408 3! o u ~ n :n e) framtagning av källkod med hjälp av underlaget, f) kompilering av källkoden till objektkod anpassad till mottagande modul, g) överföring av objektkoden till en dator med anslutningsorgan till förbin- delsen, t.ex. en CAN-bus.

24. Metod enligt patentkravet 23, k ä n n e t e c k n a d av överföring av objektkoden till en modul (nod) som skall programmeras upp medelst ett medde- lande (CAN-meddelande) som ett fragmenterat filöverföringsprotokoll, varvid i fallet med CAN-kingdom överföringen följer den specificerade blocköverföringen då noden/modulen är kungsnoden/-modulen i systemet.