SEMINAR

RACUNALNISKO PODPRTO KONSTRUIRANJE

Izdelal: Ales DROLC

Januar 1996

V seminarju je predstavljen mednarodni standard ISO 10303, ki pripravlja pogoje za prezentacijo in izmenjavo podatkov. Prikazana so pravila, ki jih je potrebnoo upostevti pri kreiranju dokumentov, v nadaljeanju pa se del Part-205 imenovan Exchange of Sculptured Surfaces Models, ki omogoca predstavitev teles na razlicnih izvedbenih stopnjah.

Kazalo

Slike

Tabele

Uvod

1 SOLIS - Step On Line Information Service

1.1 Predstavitev

1.2 Navodila za uporabo ftp

1.3 Navodila za uporabo AMS - Archive Mail Server - ja

2 Napotki za nacrtovanje in prezentacijo dokumentov ISO 10303

2.1 Sestavni deli ISO 10303

2.1.1 Kaj upostevamo pri oblikovanju elementov, ki so sestavni deli ISO 10303

2.1.2 Uvodni elementi

2.1.3 Splosni dolocilni elementi

2.1.4 Tehnicni dolocilni elementi

2.1.5 Dopolnilni elementi

2.2 Zahtevani formati pri pisanju dokumentov ISO 10303

2.3 Dokumentacija ISO 10303

2.3.1 Aneksi

2.4 Dokumentiranje aplikacij v ISO 10303

2.5 Pisanje v obliki EXPRESS

3 Izmenjava oblikovnih modelov

3.1 Vloga aplikacij pri izmenjavi oblikovnih modelov

3.2 Razdelitev na izvedbene stopnje

3.3 Oblika, topologija in geometrija

3.3.1 Oblika

3.3.2 Topologija

3.3.3 Geometrija

3.3.3.1 Elementi geometrije

3.3.4 Elementi, ki jih SS-AP ne podpira

3.4 Izvedbeni nivoji

3.4.1 Izvedbeni nivo 1

3.4.2 Izvedbeni nivo 2

3.4.3 Izvedbeni nivo 3

3.5 Primeri zapisa

3.5.1 Primeri zapisa iz naslova oblike

3.5.2 Primeri zapisa iz naslova topologije

3.5.3 Primeri zapisa iz naslova geometrije

Slike

Slika 1 - Primer tekstualnega definiranja

Slika 2 - Zahtevani elementi pri dokumentiranju aplikacij

Slika 3 - Odnosi med elementi oblike

Slika 4 - Odnosi med elementi topologije

Slika 5 - Odnosi med elementi geometrije

Slika 6 - Seznam elementov pri posamezni definiciji

Slika 7 - Osnovni elementi iz B_Spline_Surface_Form

Slika 8 - Osnovni elementi iz B_Spline_Curve_Form

Slika 9 - Koordinatni sistem

Slika 10 - Transformacija

Slika 11 - Smer in vektor

Slika 12 - Tocka v kartezijskem koordinatnem sistemu

Slika 13 - Tocka na krivulji

Slika 14 - Tocka na povrsini

Slika 15 - Opcije v IL 1

Slika 16 - Opcije v IL 2

Slika 17 - Opcije v IL 3

Tabele

Tabela 1 - Ureditev elementov

Uvod

ISO 10303 je mednarodni standard za racunalnisko prezentacijo in izmenjavo podatkov o izdelkih. Namen projekta je ustvariti nevtralen mehanizem, ki bo sposoben popisovanja podatkov o izdelku skozi ves njegov proizvodni proces, neodvisno od sistema, v katerem bo produkt nastajal. Narava podatkovnega zapisa bo tako omogocala razne operacije s temi podatki in arhiviranje.

ISO 10303 je organiziran kot skup posameznih delov krovnega standarda, ki pa se zdruzujejo v posamezne sklope glede na vsebino dela. Vsak del standarda je v okviru krovnega standarda samostojna enota.

Vzporedno z nastajanjem proizvoda nastaja skupek podatkov o tem proizvodu. Ti podatki se med proizvodnim procesom uporabljajo v najrazlicnejse namene. V tem procesu lahko sodeluje vec racunalniskih sistemov, ki so lahko postavljeni v razlicnih organizacijah. Pri takih pogojih mora biti zagotovljena moznost prenosa podatkov mad razlicnimi sisteni.

Namen standarda je torej zagotoviti jasen mehanizem za predstavitev in izmenjavo podatkov o dolocenem produktu in procesu, v katerem ta produkt nastaja, neodvisno od sistema, v katerem se odvija proces. ISO 10303 dovoljuje uporabo razlicnih izvedbenih tehnologij za shranjevanje, dostop do podatkov, prenos in arhiviranje, vendar je potrebno prilagajanje. Te izvedbene oblike morajo biti preverjene.

Prezentacija zagotovi poenoteno definicijo informacije o produktu, ki pa mora imeti lastnost, da se jo da prikrojiti katerikoli aplikaciji.

Standard ISO 10303 uporablja oblikovni jezik, imenovan EXPRESS, ki omogoca prezentacijo podatkov o posameznih produktih. Uporaba formalnega jezika omogoca natancnost in zgoscenost predstavitve ter pospesuje hitrost razvoja in izvedbe.

V ISO 10303 so definirane metode, ki naj se uporabljajo pri prenosu podatkov v podporo prezentaciji le teh. Prav tako so dolocene metodologije za preskusanje.

ISO 10303 je razdeljen v sedem glavnih skupin - serij, od katerih ima vsaka svojo funkcijo v sistemu standarda. Vsaka skupina nadalje vsebuje veè delov. Struktura standarda je tako:

-- Descriptions metods, Parts 11 - 19;

-- Integrated resources: Generic resources, Parts 41 - 99;

-- Integrated resources: Application resources, Parts 101 - 199;

-- Application protocols, Parts 201 - 1199;

-- Conformance testing metodology and framework, Parts 31 - 39;

-- Abstract test suites, Parts 1201 - 2199;

-- Implementation methods, Parts 21 - 29.

V nadaljevanju je predstavljen del, ki spada v skupino aplikativnih protokolov. Ti vsebujejo definicijo podrocja, kjer so npr. definirane funkcije, procesi ali informacije, ki jih zaradi jasnosti dokumenta iz njega izkljucimo ter povezave in informacije oz. zahteve. Izjave v glavnem delu dokumenta, njegovo podrocje se lahko podpre z raznimi modeli, ki povecujejo jasnost dokumenta. Vsaka zahteva, izrazena v glavnem delu, mora imeti za seboj vsaj en primer, s katerim lahko izjavo oz. zahtevo testiramo, preverimo.

Nadaljevanje je razdeljeno na tri dele:

-- V prvem delu je predstavljen postopek prakticnega dostopa do iformacij v raèunalniski mrezi.

-- V drugem delu je predstavljen dokument, ki se imenuje "Supplementary Directives for the Drafting and Presentation of ISO 10303". Predsatitev je samo okvirna in ne podaja natancnih dolocil za oblikovanje in prezentacijo, temvec nanje samo opozarja in jih skusa povrsno predstaviti bralcu. Originalna oblika dokumenta je prilozena v angleskem jeziku. "Supplementary Directives for the Drafting and Presentation of ISO 10303, Version 3, September 1991". Nekateri izrazi so zaradi boljse pomenske razumljivosti ostali neprevedeni v angleskem jeziku.

-- V tretjem delu je predstavljen del standarda, ki spada v skupino Application protocols. To je Part 205 ali Exchange of Sculptured Surfaces Models. Pojasnjena je njegova uporabna vloga in razvojne smernice, ki so projekt usmerjale v smer, po kateri se danes razvija. Predstavljeni so trije nacini, oblike, topologije in geometrije, s pomocjo katerih se lahko lotimo opisovanja posameznega produkta, ki sodeluje v nekem procesu. Opis lahko nadalje prilagajamo glede na zahteve oz. potrebnost predstavitve v treh razlicnih izvedbenih stopnjah, ki se med seboj razlikujejo po nacinu opazovanja produkta (kot telo ali samo kot osnovno sliko, ki jo vidimo s pogledom od spredaj itd.). Princip predstavitve je v bistu sestavljanje posameznih osnovnih elementov, kot je npr. tocka, s pomocjo logicnih struktur v visje nivojske elemente in te spet naprej, v koncno obliko ali geometrijsko strukturo, odvisno od zahtevanega. Na koncu so predstavljeni primeru posameznih elementov in logicnih struktur, ki se nanasajo na originalni dokument (prilozen). V originalnem dokumentu je predstavljen glavni del dokumenta in aneks, v katerem je podan primer za uporabo AP. Ostalih aneksov v original nisem vkljuceval, ker so ze vkljuceni v glavnem delu. Prevajalnika, s katerim bi lahko s pomocjo primera preveril dejansko funkcioniranje AP, nisem imel na razpolago, zato tega dela v nadaljevanju ni. Originalni del prav tako nima nobenih slikovnih prikazov, tako, da so slike v nadaljevanju narisane na osnovi dejstev, podanih v tekstovnem delu dokumenta.

1. SOLIS - Step On Line Information Service

1.1 Predstavitev

V posameznih datotekah STEP On-Line Information Service (SOLIS), so identificirani dokumenti o standardih, aplikacijah, podatki o komercialnih produktih, itd.. Identifikacija ne vsebuje priporocila National Institute of Standards and Technology (NIST), niti ne vsebuje garancije, da so ti produkti najboljsi mozni med produkti, ki so na razpolago.

Katerkoli software, pridobljen preko SOLIS-a, nima garancije in ga je dovoljeno prosto kopirati in uporabljti. Vendar ni jamstva, da bo ta software deloval na uporabnikovem racunalniskem okolju, oziroma, da bo opravljal naloge, za katere je bil predviden.

Mozni so trije nacini dostopa do on - line kopij posameznih STEP delov, SC4 in dokumentacije delovnih skupin z zapisniki ter ostale dokumentacije: anonimen ftp, Kermit server in Email archive server.

V njem je moc dobit razne dokumente, zapisnike, software, dokumentacijo, ki je nastajala in nastaja vzporedno z razvojem sistema. Ta materijal je dostopen vsem uporabnikom, ga je mogoce prosto kopirati, vendar ni nobene garancije, da, npr. software, deluje brezhibno. Premikanje po samem sistemu naceloma ni tezko. Tezje pa je iskanje zeljenih datotek, saj njihovi naslovi najveckrat ne sugerirajo njihove vsebine. V ta namen je potrebno pregledati izpis direktorija, kjer je poleg imena datoteke podana tudi njena velikost, datum nastanka in opis v nekaj besedah. Obstajajo pa tudi posebne datoteke, v katerih so izpisani nalslovi delov posameznega sklopa. V pomoc iskalcu so oznacene datoteke, ki so starejsega datuma in je s tem njihova aktualnost nicna. to velja predvsem za razne zapisnike, dokumente, ki se dodelujejo in podobno. Glede na vrsto datotek (koncnica), je razlicen tudi vpogled v datoteko. Nekatere datoteke lahko pregledamo takoj, na primer datoteke oblike *.txt, za vpogled v druge pa potrebujemo dodaten software. Predvsem za te zadnje se izkaze, da predstavljajo v vecini ze nekako dodelane dokumente, vendar spet brez garancije, da so povsem popolne in da bodo zadovoljile odjemalceve zelje. To so datoteke oblike *.tex in *.sty, ter druge te vrste.

Sam sistem STEP nastaja ze dalj casa. Zdruzuje se delo razlicnih projektnih skupin, ki dodelujejo posamezne sklope. S tem se ustvarja neka tehnicna stabilnost dokumentov, ki s privolitvijo drzav clanic ISO, STEP uvrsca med standarde. Metode, ki so bile uporabljene pri nastajanju standarda STEP, pa se ze uporabljajo pri drugih projektih standardizacije.

1.2 Navodila za uporabo ftp

Navodila za uporabo ftp (file transfer protocol) nacina za dostop na STEP On-Line Information Service (SOLIS):

1.3 Navodila za uporabo AMS - Archive Mail Server-ja

Navodila za uporabo STEP Archiv Mail Server-ja. Prosnje posljite na ntpserver@cme.nist.gov. Vsaka prosnja mora vsebovati niz ukazov, ki jih napisete po enega v vsako vrstico. Ce naletite na kakrsenkoli problem, posljite e-mail na ntpserver-admin@cme.nist.gov.

Seznam veljavnih mail server ukazov:

-- HELP

Uporaba ukaza 'help' priklice seznam veljavnih ukazov.

-- INDEX [<item>]

Uporaba ukaza 'index' priklice glavni izpis direktorijev.

Uporaba ukaza 'index <dname>' priklice izpis datotek specificnega direktorija.

Primer: 'index part11'

Uporab ukaza 'index all' priklice izpis datotek vseh direktorijev.

-- SEND <item> [<item>...]

Uporaba ukaza 'send step/<dname>' prekopira vse datoteke direktorija na vaso pozicijo.

Primer: 'send step/part11'

Opozorilo: Bodite pozorni na prostor, ki ga lahko zasede v celoti prekopiran direktorij.)

Uporaba ukaza 'send step/<dname>/<filename>' omogoca kopiranje dolocene datoteke.

Primer: 'send step/part11/iso.sty'

-- MCI

-- UUENCODE

-- BTOA

Ti trije formati prekodirajo iz binarnega zapisa v ascii tekst, primeren za prenos. Pri *.txt datotekah

prekodiranje ni potrbno. Posebno je potrebno omeniti prekodiranje v povezavi z ukazom 'send', kjer bi bila ne uporaba le tega nepravilna.

Primer: Ce uporabljate MCI mail in potrebujete binarni dokument, imenovan foo,

uporabite na step direktoriju naslednji "mail message".

mci

send step/foo

Posledica je, da bo poslan dokument prekodiran v ustrezen MCI nacin.

-- LIMIT <number>

Najvecje stevilo bytov, ki bodo poslani po racunalmiski posti. Ukaz 'limit' se povezuje zukazom 'send'.

-- RESEND <item> <part> [<part>...]

Poslje zeljene <parts> iz dolocenega <item>. Format in limit morata biti identicna kot v originalni

prosnji 'send'.

-- PATH <path>

Opise povratno pot. Ta ukaz se uporablja, kadar nismo sigurni, ce nam bo "mail system" pravilno

generiral povratni naslov.

-- END

-- EXIT

V sistemu SOLIS se uporabljajo datoteke naslednjih tipov:

-- *.c1x ChartX datoteka;

-- *.com Izvrsilen sistemski ukaz;

-- *.dir ASCII tekstovna datoteka, ki izpise seznam datotek na direktoriju;

-- *.dvi 'Device-Independent' datoteka (narejena v TeX);

-- *.exe Datoteka, ki se odkomprimira, ko je izvrsena na DOS-u;

-- *.mac Datoteka, narejena s katerokoli Macintosh aplikacijo;

-- *.pak Datoteka, ki je bila komprimirana s 'pak' programom;

-- *.ps PostScript;

-- *.tex LaTeX datoteka, ASCII format;

-- *.sty LaTeX 'style' datoteka, ASCII format;

-- *.trz Komprimirana 'tar' datoteka;

-- *.txt ASCII tekstovna datoteka;

-- *.w42 WorldPerfect Version4.2;

-- *.w50 WorldPerfect Version 5.0;

-- *.w51 WorldPerfect Version 5.1.

2 Napotki za nacrtovanje in prezentacijo dokumentov ISO 10303

Dokument v obliki napotkov podaja zahteve, s pomocjo katerih bi se poenotila oblika vseh dokumentov v ISO 10303 (International Organization for Standardization), z namenom enotne prezentacije in moznosti zamenjave.

Dokument je sestavljen iz petih glavnih delov, od katerih opisujejo:

-- prvi sestavne elemente ISO 10303;

-- drugi zahtevane formate teh elementov;

-- tretji ustvarjanje pomoznih shem;

-- cetrti uporabniske protokole;

-- peti pisanje v obliki EXPRESS.

Z upostevanjem teh pravil pri pisanju dokumentov, ki so del standarda ISO 10303, bi bilo dosezeno poenotenje strukture, stila in terminologije ne samo v okviru tega standarda, temvec v celi seriji leteh.

2.1 Sestavni elementi ISO 10303

2.1.1 Kaj upostevamo pri oblikovanju el., ki so sestavni deli dokumentov ISO 10303

Standard je sestavljen iz uvodnih, dolocilnih in dopolnilnih elementov.

Tabela 1 - Ureditev elementov


Vrsta elementa                                  Element                         

Uvodni                                          naslovna stran, seznami,        
                                                slike,                          
                                                tabele, uvodna beseda,          
                                                predstavitev                    

                        Splosen                 naslov, podrocje, napotitve     

Dolocilen               Tehnicen                clen ali vec o zahtevah         

Dopolnilen                                      indeks                          



2.1.2 Uvodni elementi

Dokument predstavimo z naslovno stranjo, ki jo oblikuje vsak pisec dokumenta sam, vendar za dokoncno obliko naslovne strani poskrbi 'ISO Central Secretariat'. Vsak dokument mora biti opremljen s kazalom in seznamom slik in tabel, od katerih vsakega pisemo na svojo stran. Vsak dokument mora imeti uvodno besedo. Ta je obvezna, medtem ko so posamezni deli uvodne besede poljubni. Predvidana so besedila, ki naj se v uvodni besedi uporabljajo. To je samo okvirno besedilo, saj mora pisec dokumenta v ta okvir vnesti podatke, ki so specificni za doticni dokument. Priporoceno je tudi vkljucevanje besedila, ki omenja sponzorje oz. podpornike (samo mednarodne), ki so pri projektu sodelovali ali ga gmotno podprli.

Kadar nek dokument ponovno izdajamo, je to potrebno natancno oznaciti. Omeniti je potrebno tudi povezave s katerimikoli drugimi enotami standarda.

Uvod zakljucimo z besedilom, ki doticni dokument poveze z ostalimi, spodaj nastetimi dokumenti, v vecji sklop, ki obravnava neko doloceno podrocje. Koncno obliko uvodne besede doloci 'ISO Central Secretariat'.

Predstavitve posameznih dokumentov so potrebne. Dolocena so celo besedila, s katerimi predstavimo dokumente standarda oziroma dele 4x in 1xx, aplikacije in druge dele standarda ISO 10303.

2.1.3 Splosni dolocilni elementi

Vsak dokument je potrebno nasloviti. To naredimo z dvodelnim naslovom, ki dokument pripise vecji skupini, ki obdeluje isto tematiko, ter opredeli vsebino tega standarda v tej vecji skupini. Opredeliti je potrebno tudi podrocje oziroma povezave in specifikacije. Pri imenovanju standarda ISO zahteva, da se uporablja izraz "Mednarodni Standard".

2.1.4 Tehnicni dolocilni elementi

Za boljse razumevanje dokumenta, temu prilozimo seznam definicij, ki morajo natancno razloziti pomen nerazumljivih strokovnih izrazov, ter seznam kratic in simbolov. Ponavadi vse te tri elemente zdruzimo v enega. Med tehnicne dolocilne elemente stejejo tudi dolocilni aneksi, ki morajo biti nedvoumno oznaceni in postavljeni za glavni del dokumenta in pred informativne anekse.

2.1.5 Dopolnilni elementi

Med dopolnilne elemente stejeo informativni aneksi, v katerih se podajo dodatne informacije o temi, ki jo dokument obravnava. Postavljeni so za dolocilnimi aneksi. Narava informativnih aneksov mora biti nedvoumno dolocena, tako po naslovu, kot po vsebini. Razumljivost dokumenta se lahko poveca z dodajanjem opomb, preglednost pa se poveca z razdeljevanjem snovi na poglavja in podpoglavja, ter dalje na posamezne odstavke , ki pa jih ne stevilcimo. V dokumentu opisana dejstva se lahko se najbolj nazorno prikaze s pomocjo primerov.

2.2 Zahtevani formati pri pisanju dokumentov ISO 10303

V napotitvah za nacrtovanje in prezentacijo dokumentov ISO10303 so natancno predpisani formati, ki naj se uporabljajo. Za kazalo je npr. predpisano, da mora biti med naslovom 'Kazalo' in kazalom prazna vrstica, da morajo biti naslovi na levi poravnani, prav tako stevilke na desni strani (povezava s pikami). Nadalje se natancno dolocajo postavitve glavnih naslovov in naslovov poglavij in podpoglavij ter stevilo praznih vrstic med njimi in tekstom. V bistvu gre tu za naslavljanje na razlicnih nivojih. Vzporedno z naslavljanjem je predpisano tudi ostevilcenje naslovov, aneksov in strani (ostevilcimo jih v spodnjem zunanjem kotu strani). Uporabljajo se arabske stevilke, zacensi z ena.

Nadalje je predpisana uporaba velikih crk v naslovih in v tekstu, poravnavanje besedila na levi in na desni strani, razmiki med vrsticami, itd..

Tabele je potrebno postaviti takoj za tekst, ki se nanasa na podatke v njih, ce se le da, na isto stran. Ce smo primorani tabelo postaviti na sredino strani, jo od teksta locimo s tremi praznimi vrsticami. Tekstovnih poglavij ali podpoglavij se s tabelo ne sme razbiti. Predpisana je oblika ostevilcenja in naslavljanja tabel (uporaba velikih crk v naslovu tabel). Tabelo je dovoljeno deliti, tako da jo prikazemo na dveh ali vecih straneh. Pravila, ki jih je potrebno upostevati pri oblikovanju, ostevilcenju, postavljanju v tekst in naslavljanju slik, so zelo podobna pravilom za oblikovanje tabel.

Obicajne so povezave dokumenta z nekim drugim (drugimi) dokumentom. Povezave oz. napotitve je potrebno omeniti s predpisanimi besednimi zvezami (tudi ce se sklicujemo na nek drug standard).

Nadalje je predpisana oblika raznih dopolnilnih elementov, kot so opombe, primeri, itd.. Pri nastevanju je potrebno nastevanje najprej nasloviti, potem pa pisati tocke vsako v svojo vrsto.

Za izrazanje zahtev ali priporocil, so namesto raznih moznih besednih zvez, nekatere natancno predpisane. Tako se predpisuje uporaba naslednjih besednih zvez (v anglescini, ki je edini dovoljeni jezik v mednarodni uporabi dokumentov ISO 10303):

-- "shall";

-- "shall not";

-- "should";

-- "should not";

-- "may";

-- "need not";

-- "can";

-- "cannot".

Na koncu je predpisana se vrsta pisave, ki se jo sme uporabljati in njena velikost ter slovarji, iz katerih naj se crpajo pravopisnia pravila.

2.3 Dokumentacija ISO 10303

Dokument je sestavljen iz glavne sheme, v kateri je opisan glavni problem oz. tema, ki jo dokument obravnava in pomozne sheme, ki glavni shemi dodajo razne pomozne in dodatne informacije. Tako se lahko zgodi, da se deli pomoznih shem ujemajo s tistimi, ki to niso. V takih primerih je potrebno nakazati odnos med njimi.

V predstavitvenem delu dokumenta se posvetimo predvsem tehnicni dovrsenosti standarda. V nadaljevanju sledi dokumentacija o doloceni temi. Tu se povdarjajo predvsem aplikativna podrocja in razlage o tehnicnih omejitvah. Uporabljata se primarni in sekundarni oznacitveni mehanizem. Prvi je v obliki pripovednega teksta in opisuje razna pravila, omejitve in dogovore, ki dolocajo, kaj naj bi se v dele standarda vkljucilo in kaj ne. Pri drugem mehanizmu pa se uporabljajo aktivni modeli, opisi stalisc, relacije do drugih modelov in aplikacij, kjer se informacije lahko koristi.

Struktura poglavja zahtev naj bi bila:

x <ime sheme>

x.1 Predstavite

x.2 Temeljna zamisel in predpostavke

x.3 <Ime sheme> definicije: <Ime funkcionalne skupine>

:

:

Sledijo se definicije tipa, pravil, funkcij ter na koncu x.n <Ime sheme> Razporeditvena struktura.

Enotno interpretacijo oz. branje dokumentov omogoca pisanje v obliki EXPRESS. Iz te oblike prevajalnik prevede dokument v enotno berljivo (zgoraj omenjene oblikovne zahteve) obliko. Berljivost in razumljivost se lahko poveca s funkcionalnim grupiranjem, ki pa ni nujno. Pri tem je pomembna ureditev, ki med drugimi dopusca hierarhicen odnos med deli. Ce ni predpisano drugace, se uporablja preprosta alfanumericna ureditev.

Pri dokumentiranju sheme se je potrebno drzati predpisanih pravil. Nekatera so:

-- potrebna je natancno predpisana predstavitev sheme;

-- deklaracija sheme z vsemi smernicami

*)

SCHEMA <schema_1 name>;

REFERENCE FROM <schema_2 name>

(<e1 name, e2 name>);

(* ;

-- razne opombe...

Shemo je potrebno natancno predstaviti (ponavadi je predstavljena ze v uvodnih dokumentih, vendar mora biti predstavitev tu poglobljena). Na tem mestu se ponavadi predstavijo perspektive in opisi glavnih komponent.

Pri predstavitvi se pretezno uporablja tekst, vendar je slikovna predstavitev zaradi nazornosti boljsa, bolj zazeljena. V tem primeru naj bo ta spisana v obliki EXPRESS.

Temeljne zamisli in predpostavke so bistvo dokumenta, ki predstavijo avtorjeve zamisli in moznosti razvoja in so pomembne pri razumevanju dokumenta. Zapisane so lahko v tekstovni obliki ali pa v bolj strukturirani, z nastevanjem in krajsimi opisi.

Pri opisu glavnih zahtev, se je prav tako potrebno drzati pravil. Z upostevanjem teh ima tekstovno definiranje obliko, kot je prikazano na sliki 1.


                                                                                  
x . x . x <ENTITY NAME>                                                           
                                                                                  
  _ _ _<entity definition>_ _ _                                                   
                                                                                  
EXPRESS specification:                                                            
                                                                                  
*)                                                                                
                                                                                  
ENTITY ; _ _ _ _ _ _                                                              
       a :   INTEGER;                                                             
       b:   REAL;                                                                 
    UNIQUE                                                                        
    UR1: a, b;                                                                    
    WHERE                                                                         
        WR1:  f (a, b);                                                           
END ENTITY;                                                                       
(*                                                                                
                                                                                  
Attribute definitions:                                                            
                                                                                  
<attribute1 name>: _ _ _ _ _ _ _                                                  
                                                                                  
<attribute2 name>: _ _ _ _ _ _ _                                                  
                                                                                  
Formal propositions:                                                              
                                                                                  
UR1: _ _ _ _ _ _                                                                  
WR1: _ _ _ _ _ _                                                                  
                                                                                  
Informal propositions:                                                            
                                                                                  
<proposition 1>: _ _ _ _ _                                                        



Slika 1 - Primer tekstualnega definiranja

Formalni predlogi morajo biti napisani v obliki EXPRESS in uporabljeni samo v primeru, ko je vrednotenje odvisno od vrednosti atributov.

PRIMER:

UR1: Ime naj bo edinstveno.

WR1: Vrednost naj bo pozitivna.

Neformalni predlogi naceloma niso napisani v obliki EXPRESS, vendar kljub temu obstajajo pravila o obliki. Tudi neformalne predloge je moc razumeti kot zahteve.

Tudi za popisovanje funkcij in postopkov v obliki EXPRESS, veljajo dolocena pravila.

Funkcija, pravilno opisana v obliki EXPRESS.

PRIMER

1 Funkcija oz. pravilo je v podpoglavju:

*)

FUNCTION function_name (x: INTEGER) : LOGICAL;

<function body in EXPRESS>

END_FUNCTION;

(*

PRIMER

2 Funkcija oz. pravilo je v glavnem delu dokumenta, njegovem bistvu:

*)

ENTITY ....

....

WHERE

WR1: function_name (...) ;

END_ENTITY;

(*

..........

Formal proposition:

WR1: _ _ _

Funkcije, ki ne delujejo v obliki EXPRESS, vendar za njih potrebujemo posebne aplikacije.

PRIMER

3 Funkcija oz. pravilo je v podpoglavju:

*)

FUNCTION function_name (x: INTEGER) : LOGICAL;

(* <text which explains what the function is supposed to do.

Note that the text is commented out between the function head and tail.> *)

END_FUNCTION;

(*

PRIMER

4 Funkcija oz. pravilo je v glavnem delu dokumenta, njegovo bistvo:

*)

ENTITY ....

....

WHERE

WR1: function_name (...);

....

END_ENTITY;

(*

..........

Formal propositions:

WR1: function_name (...);

....

Funkcije, ki so neizvedljive.

PRIMER

*)

ENTITY ....

....

WHERE

....

END_ENTITY;

(*

..........

Informal proposition:

<constraint name or title>

<constraint explanation> .....

Vsako shemo zakljucimo z zakljucno deklaracijo.

*)

END_SCHEMA; - - <schema_name>

(*

2.3.1 Aneksi

Aneksi so del dokumenta, ki so predstavljeni cisto na koncu. Njihova naloga je poglabljanje glavne teme oz. dodajanje informacij, ki so z glavnim dokumentom povezane, niso pa omenjene v glavnem delu dokumenta. Oznacujemo jih z velikimi crkami.

Aneksa A in B sta dolocilna aneksa. Prvega naslovimo z "Annex A-EXPRESS source listing", drugega pa z "Annex B-Entity and type abbreviations".

Aneks C je bibliografija, kjer se opisejo vsi dokumenti, ki so bili uporabljeni pri nastajanju sestavnega dela ISO 10303.

Aneks D je predstavitev tehnicnih razprav, ki so nastajale med razvojem standarda. Pripomore predvsem k boljsemu razumevanju namena in vsebine dokumenta.

Aneks E je naslovljen kot "Annex E-Model Scope" in je poljuben. Tu se skusa dejstva, omenjena v dokumentu, prikazati z modeli, slikami in preglednicami. Posamezne elemente se skusa predstaviti v globalnem, kasneje uporabnem okolju.

V aneksu F so predstavljeni primeri. Primerov ne dajemo v jedro dokumenta, ker bi ga to precej povecalo. Z njimi skusamo plasticno predstaviti elemente oz. dejstva, ki jih dokument standarda obdeluje.

V aneksu G so predstavljeni modeli, ki so spisani v drugih graficnih jezikih, kot sta IDEFIX in NIAM. Iz teh dveh oblik se prevede v EXPRESS obliko in model, najveckrat sliko, predstavi v aneksu G.

2.4 Dokumentiranje aplikacij v ISO 10303

Aplikacije so v standardu ISO 10303 predstavljene posebej. Za le te veljajo v vecini ista pravila, kot so opisana zgoraj, le nekatera so specificna za aplikacije. Informacije o aplikacijah in njihovem razvoju je moc dobiti pod uradnim naslovom "Guidelines for the Development and Approval of STEP Application Protocols." Zahtevani dolocilni elementi pri dokumentiranju aplikacij so prikazani na sliki 2.


                                                                                  
Foreword                                                                          
                                                                                  
Introduction                                                                      
                                                                                  
1 Scope                                                                           
                                                                                  
2 Normative references                                                            
                                                                                  
3 Definitions                                                                     
                                                                                  
4 Information requirements                                                        
   4.1 Construct definitions; 4.2 Construct assertions                            
                                                                                  
5 Application interpreted model                                                   
   5.1 ARM to AIM mapping; 5.2 AIM EXPRESS short form                             
                                                                                  
6 Conformance requirements and test purposes                                      
   6.1 Conformance requirements; 6.2 Test group structure; 6.3 Conformance test   
purposes                                                                          
                                                                                  
Annex A  AIM EXPRESS long form (required and normative)                           
                                                                                  
Annex B  PICS (Protocol Implementation Conformance Statament) proforma (required  
and normative)                                                                    
                                                                                  
Annex C  Implementation specific requirements (required and normative)            
                                                                                  
Annex D  Application activity model (required and normative)                      
           D.1 AAM definitions; D.2 AAM diagrams                                  
                                                                                  
Annex E  Application reference model (required and normative)                     
           E.1 Units of functionality: E.1.1 UOF definitions; E.1.2 UOF and ARM   
correspondence;                                                                   
           E.2 ARM diagrams                                                       
                                                                                  
Annex F  AIM EXPRESS-G (required and normative)                                   
                                                                                  
Annex G  Application protocol usage guide (optional and informative)              
                                                                                  
Annex H  Tehnical discussions (optional and informative)                          
                                                                                  
Annex J  Bibliography (optional and informative)                                  



Slika 2 - Zahtevani elementi pri dokumentiranju aplikacij

Pri dokumentiranju nekega podrocja. moramo zaradi usklajevanja, dokumentu dodati opis nekaterih pomembnejsih katakteristik:

-- Type of product;

-- Typed of product data;

-- Supported stages in the life cycle of the product;

-- Supported application uses of the product data;

-- Discipline views of the product that are acommodated;

-- Exclusions from scope;

-- Associations with other APs.

Pri dokumentiranju aplikacij moramo ravno tako poskrbeti za definicije, zahteve (formalne in neformalne), itd., kot je to omenjeno v prejsnjih poglavjih. Dodano je podpoglavje, ki definira zgradbo aplikacije. Pri prikazu zgradbe aplikacije se je potrebno drzati predpisanih pravil.

Pri aplikacijah imajo pomembno vlogo razlicni modeli. Aplikativno Interpretiran Model (AIM) je npr. zapis v obliki EXPRESS, ki vzporedno z glavno shemo dokumenta pomaga pri razumevanju aplikacije. Ustreznost oz. skladnost med AIM in ARM, ki je tudi ena izmed oblik modela, je potrebno podati na predpisan nacin.

AIM model lahko interpretiramo v kratki ali dolgi obliki. Interpretacija v kratki obliki izgleda:

USE FROM a_resource_schema (an_entity );

ENTITY aim_entity

SUBTYPE OF (an_entity );

- - maybe some additional attributes

WHERE

- - some constraints

END_ENTITY

(* definitions and propositions appropriate to this "new" entity *)

Dolgo obliko AIM modela prikazemo v aneksu A (za aplikacije).

Aplikacijam dodamo tudi poglavje, katerega namen je prilagajanje in testiranje aplikacij na doloceni stopnji njenega razvoja oziroma dopolnjevanja.

Pri aplikacijah anekse oznacujemo:

-- A AIM EXPRESS long form (required and normative);

-- B PICS (Protocol Implementation Conformance Statement proforma

(required and normative);

-- C Implementation specific requirements (optional, but normative if appears);

-- D Application activity model (required and normative);

-- E Application reference model (required and normative);

-- F AIM EXPRESS-G (required and normative);

-- G Application protocol usage guide (optional and informative);

-- H Tehnical discussions (optional and informative);

-- J Bibliography (optional and informative).

Dolocilni aneksi so A, B in C, ki je neobvezen, a dolocilen, ce se pojavi. V aneksu A je predstavljena prej omenjena dolga oblika modela AIM, ki pa temelji na njeni krajsi inacici. Napisana je v obliki EXPRESS, pri cemer se dovoljuje pisanje opomb, ki niso pisane v tej obliki. V aneksu B se poda vse funkcije, elemente, procedure, parametre, opcije in druge sposobnosti aplikacije. Vse aplikacije morajo imeti anekse D, E in F, ki so informativni, aneksi G, H in J so prav tako informativni, vendar neobvezni.

2.5 Pisanje v obliki EXPRESS

EXPRESS je oblika pisanja dokumentov. Ko tako napisan dokument spustimo skozi prevajalnik, dobimo koncno, enotno obliko dokumentov, slik, itd.. Pri pisanju v tej obliki veljajo nekatera pravila. Pri pisanju shem moramo v dokument vkljuciti naslednje elemente, ki pa so med seboj popolnoma enakovredni:

-- uporaba napotitvenih izjav;

-- deklaracija bistev;

-- deklaracija tipov;

-- pravila;

-- funkcije in procedure.

Deklaracije, ki jih locujemo med seboj s prazno vrstico, so sestavljene iz:

-- sheme;

-- uporabe;

-- napotitev;

-- konstant;

-- bistva;

-- tipa;

-- pravila;

-- funkcije;

-- procedure.

Vse deklaracije, ki so pisane v obliki EXPRESS, locimo od ostalih delov dokumenta z oznako " *) " na zacetku in " (* " na koncu.

Nacrt sheme predstavimo:

SCHEMA . . . . ;

TYPE . . .

ENTITY . . . . ;

END_SCHEMA;

Pri predstavitvi zvez oz. odnosov uporabimo enega od naslednjih dveh nacinov:

USE FROM s-name

(e1 AS s1,

e2 AS s2);

ali

REFERENCE FROM s-name

(e1 AS s1,

e2 AS s2);

Konstante predstavimo:

CONSTANT

name1 : NUMBER := 1000;

name21 : NUMBER := name1**2;

END_CONSTANT;

Tipski nacrt lahko predstavimo na tri nacine:

TYPE name = SET OF ent;

END_TYPE;

ali

TYPE name = SELECT

(ent1,

ent2);

END_TYPE;

ali

TYPE name = ENUMERATION OF

(enum1,

enum2);

END_TYPE;

Nacrt algoritma predstavimo:

PROCEDURE procedure_name (parameter_list);

LOCAL

local declarations

END_LOCAL

-- explains following section

code body

-- explains following section

code body

END_PROCEDURE;

Parametre predstavimo na nacine:

FUNCTION func_name (a, b, c: INTEGER;

d, e, f: REAL;

x, y, z: AGGREGATE OF point) : REAL;

PROCEDURE proc_name (a, b, c: INTEGER;

d, e, f: REAL;

VAR x, y, z: AGGREGATE OF point);

Spremenljivke predstavimo na nacin:

LOCAL

i, j, k: INTEGER;

END_LOCAL;

Glabno telo, v katerem so predstavljeni odnosi med posameznimi elementi izgleda:

IF cond THEN

statement;

ELSE

statement;

END_IF;

REPEAT . . . ;

statement;

. . .

END_REPEAT;

CASE . . . ;

label : statement;

label :

BEGIN

statement;

statement;

. . .

END;

END_CASE;

BEGIN;

statement;

. . .

END;

Pri pisanju v EXPRESS moramo posamezne elemente poimenovati, najveckrat funkcije. Tu se drzimo pravila, da naj bo ime cim bolj sugestivno, vendar brez odvecnih besed (predlogov, veznikov).

3 Izmenjava oblikovnih modelov

3.1 Vloga aplikacij pri izmenjavi oblikovnih modelov

Aplikacija za izmenjavo oblikovnih modelov je predstavljena v sestavnem delu 205 standarda ISO 10303 (STEP Part 205 - Exchange of Sculptured Surface Models). Koncept te aplikacije je bil predstavljen leta 1989 v Frankfurtu kot mozno orodje pri koristni uporabi STEP-a (STEP - mednarodni standard za izmenjavo podatkov). Projekt CADEX je sploh eden prvih, ki se ukvarja z aplikacijami, ki bi se lahko uporabile v okviru projekta STEP. Vse verzije so v glavnem se v uvodni, pripravljalni fazi.

Pri razvoju aplikacij bi se stvaritelji lahko opirali na vac razvojnih smernic. Razvoj bi lahko temeljil na informacijah, ki so specificne za posamezne produkte (npr. avtomobilske karoserije) ali na informacijah, ki so specificne za posamezne proizvodnje procese. Odlocili so se za princip, ki ga uporablja CAD modeliranje.V prvem obdobju razvoja bodo aplikacije dovoljevale le prenos podatkov o mrezah, povrsinah itd., kasneje pa bi bile lahko postale osnova pri dolocenih proizvodih in proizvodnih procesih. Po tem je pokazala potrebo prav analiza razvoja karoserij in njihovih oblik. Vzporedno se je pokazla potreba po delitvi na geometrijo in topologijo, kar omogoca bolj natancen pristop na podrocjih kot so oblikovanje karoserij, raznih analizah oblik in podobno.

3.2 Razdelitev na izvedbene stopnje

Topolosko gledano se ponujajo tri moznosti, razdeljene v tri izvedbene nivoje ali IL - Implementation Level:

-- IL 1, podatki brez topoloskih informacij;

-- IL 2, podatki, ki opredeljujejo pogled od spredaj;

-- IL 3, podatki, ki opredeljujejo topologijo na osnovi skoljke oz. lupine.

3.3 Oblika, topologija in geometrija

Celovitost prikaza in analize objektov je mozna s pogledom iz razlicnih zornih kotov. Oblike, topologije in geometrije:

-- ipim_nominal_topology_schema;

-- ipim_topology_schema;

-- ipim_geometry_schema,

pri cemer ipim pomeni Integrated Product Information Model.

3.3.1 Oblika

Pri obravnavanju oblike si lahko pomagamo z naslednjimi elementi, ki so med seboj soodvisni oz. povezani v hierarhicno drevesno strukturo (Slika 1):

-- Surface-Model;

-- Shell-Based-Surface-Model;

-- Face-Based-Surface-Model;

-- Geometric-Set;

-- Geometric-3D-Surface-Set.

Hierarhicen odnos med elementi oblike

Slika 3 - Odnos med elementi oblike

Z elementi Shell-Based-Surface-Model, Face-Based-Surface-Model in Geometric-3D-Surface-Set prikazemo osnovne elemente oblikovnega prikaza. To je prikaz na osnovnem, najnizjem nivoju. Sledi zdruzevanje s katerim dobimo prikaza na visjem nivoju, to sta Surface_Model in Geometric_Set. Zadnja, najvisja opcija, ki jo dobimo z zdruzitvijo S_M in G_S je oblikovni model oziroma Shape_Model

3.3.2 Topologija

Pri obravnavanju topologije si pomagamo z naslednjimi elementi, ki so med seboj hierarhicno soodvisni (Slika 4) in logicnimi strukturami:

-- Shell;

-- Open-Shell;

-- Connected-Face-Set;

-- Face;

-- Loop;

-- Edge-Loop;

-- Vertex-Loop;

-- Edge;

-- Vertex;

-- Shell-Logical-Structure;

-- Edge-Logical-Srtucture;

-- Curve-Logical-Structure;

-- Face-Logical-Structure;

-- Surface-Logical-Structure;

-- Loop-Logical-Srtucture.

Hierarhicen odnos med elementi topologije

Slika 4 - Odnos med elementi topologije

Topologijo nekega predmeta predstavimo z elementi edge, loop, shell, conected_face_set in vertex. Elementa loop in shell prikazemo s podelementi, vertex_loop in edge_loop za prvega in open_shell za drugega. Pri oblikovanju si pomagamo z logicnimi strukturami za shell, face, surface, loop, edge in curve.

3.3.3 Geometrija

Geometrijo predmeta oblikujemo z naslednjimi hierarhicno soodvisnimi elementi:

-- Surface;

-- Bounded-Surface;

-- B-Spline-Surface;

-- Curve;

-- Bounded-Curve;

-- B-Spline-Curve;

-- Curve-On-Surface;

-- Pcurve;

-- Surface-Curve;

-- Intersection-Curve;

-- Point;

-- Cartesian-Point;

-- Point-On-Curve;

-- Point-On-Surface;

-- Vector;

-- Direction;

-- Transformation;

-- Coordinate-System.

Hierarhicen odnos med elementi geometrije

Slika 5 - Odnos med elementi geometrije

Pri poglavju o geometriji so podane tudi definicije, ki se lahko koristno uporabijo pri SS-AP (Sculptured Surfaces Applocation Protocol). To so:

-- Type definitions utilized in the SS - AP geometry subset;

-- Enumeration-Curve1-Pcurves1;

-- Bspline-Curve-Form;

-- Bspline-Surface-Form;

-- Intersection-Enumeration;

-- Uniform-Type.

Slika 6 - Seznam elementov pri posamezni definiciji

Slika 6 prikazuje tipe definicij, ki se uporabljajao v podpoglavju Geometrija. Tu so prikazane osnovne oblike ploskev, linij, krivulj in njihovih kombinacij.

Plane_Surface, Cilindrical_Surface, Conical_Surface, Spherical_Surface

Slika 7 - Osnovni elementi iz Bspline_Surface_Form

S kombinacijo osnovnih elementov iz naslova Bspline_Surface_Form lahko oblikujemo poljubno zeljeno povrsino. Na sliki so prikazane le osnovne povrsine:

-- ravna;

-- cilindricna;

-- konicna;

-- sfericna.

Poleg teh so mozne se npr. toroidna povrsina, kvadratasta itd...

Line_Segment, Circular_Arc, Eliptic_Arc, Parabolic_Segment

Slika 8 - Osnovni elementi iz Bspline_Curve_Form

Slika 8 prikazuje nekaj osnovnjih linij, s kombinacijo katerih lahko predstavimo poljubno zeljeno linijo oz. konturo.

3.3.3.1 Elementi geometrije

Z zdruzevanjem elementov pod naslovom geometrija, dosezemo predstavitev geometrije nekega predmeta oz. telesa. V nadaljevanju je prikazanih nekaj elementov iz podpoglavja geometrija.

Koordinatni sistem je element, s pomocjo katerega natancno dolocimo lego tocke, krivulje ali kakega drugega elementa v ravnini ali prostoru. Koordinatni sistem je naceloma poljuben in ni nujno, da je kartezijev pravokotni koordinatni sistem, kot je to prikazano na sliki. Pri koordinatnem sistemu je pomembno definiranje osnovne enote oz. "en.", kot je to ozanceno na sliki 9.

Slika 9 - Koordinatni sistem

Transformacija je element, s pomocjo katerega preslikamo nek objekt - tocko iz prvotnega koordinatnega sistema (1, 2, 3) preko transformacije u1, u2, u3 v OBJ'. Transformacija je prikazana z ortogonalnimi komponentami zaradi boljse preglednosti.

Slika 10 - Transformacija

Smer oziroma "Direction" je podopcija vektorja. Smer je podana s premico, ki povezuje izhodisce koordinatnega sistema z neko tocko, ki je podana s T(x, y, [z]). Ko smeri pripisemo neko dolzino, velikost, dobimo vektor, ki ima poleg smeri tudi velikost. Glede na dvodimenzionalen oz. trodimenzionalen prostor, ga dolocata dve oz. tri koordinate.

Slika 11 -Smer in vektor

Tocko lahko predstavimo na tri nacine. Pri prvem jo predstavimo kot tocko v kartezijevem koordinatnem sistemu. Glede na dimenzijo prostora jo predstavimo z dvema ali tremi realnimi vrednostimi.

Slika 12 - Tocka v kartezijskem koordinatnem sistemu

Tocka na krivulji je drugi nacin dolocitve tocke. Dolocimo jo z enim parametrom pp ali point_parameter. Poznati moramo osnovno krivuljo, za parameter pa velja odnos:

{parametric_lower_limit (bassis_curve) < point_parameter <

parametric_upper_limit (basis_curve)}

Slika 13 - Tocka na krivulji

Tocka na povrsini ali point_on_surface je tretji nacin dolocitve tocke. Dolocena je z dvema koordinatama oz. dvema parametroma. To sta pp1 in pp2 (point_paarameter). Parametra pp1 in pp2 zavzemata vrednost med zgornjo in spodnjo vrednostjo parametra ena ali dva. Velja odnos:

{parametric_lower_limit (bassis_surface) [1] < point_parameter_1 <

parametric_upper_limit (basis_surface) [1] }

Podoben odnos lahko pripisemo tudi parametru pp2.

Slika 14 - Tocka na povrsini

V poglavju Geometrija sta predstavljeni se opciji krivulja in povrsina ter njune kombinacije.

3.3.4 Elementi, ki jih SS-AP ne podpira

Pri oblikovanju podatkov obstajajo tudi omejitve. So elementi, ki jih za razliko od zgoraj navedenih, SS-AP (Sculptured Surfaces Application Protocol) ne podpira. Ti elementi so:

-- Podopciji od Shape_Model (solid_model in wireframe_model);

-- Podopcije od Geometric_Set (geometric_2d_set, geometric_projective_set in

geometric_3d_curve_set);

-- Podopcije od Topology (path, subface, connected_edge_set in region);

-- Podopcije od Shell (vertex_shell, wire_shell in closed_shell);

-- Podopcija od Loop (poly_loop)

-- Podopcija od Geometry (axis_placement);

-- Podopcije od Bounded_Surface (rectangular_trimmed_surface, curve_bounded_surface in

rectangular_composite_surface);

-- Podopcije od Curve (line, conic_curve in offset_curve);

-- Podopcije od Bounded_Curve (poly_line, trimmed_curve in composite_curve);

-- Podopcija od Curve_On_Surface (composite_curve_on_surface);

-- Podopcije od Vector (vector_with_magnitude, default_x_axis, default_y_axis in

default_z_axis)

3.4 Izvedbeni nivoji

3.4.1 Izvedbeni nivo 1 - IL 1

Prvi izvedbeni nivo pokrije osnovne potrebe pri prenosu in predstavitvi podatkov. Na tem nivoju je mozen prenos oblikovanih krivulj in povrsin skupaj s kartezijskimi tockami ali nizom teh. Vecinoma opcij, ki se uporabljajo pri IL 1 je predstavljeno pod naslovom Geometrija. Vse oblike krivulj in povrsin so predstavljene pod naslovi b_spline_curve in b_spline_surface. Tocke v kartezijevem koordinatnem sistemu so predstavljene pod opcijo cartesian_point. Niz tock predstavimo s pomocjo opcije cartesian_point in geometric_3d_surface_set.

Slika 15 - Opcije v IL 1 (oblika in geometrija)

3.4.2 Izvedbeni nivo 2 - IL 2

IL 2 se posveca urejevanju, grupiranju in topologiji.Pri tem se uporabljajo naslednje opcije:

Slika 16 - Opcije v IL 2 (oblika in topologija)

Pod naslovom Geometrija se pri IL 2 uporabljajo vse opcije, kot so prikazane na sliki 5.

Kot je razvidno s slik, je IL 2 razsirjena IL 1 po topoloski in geometrijski plati. Pomembno pa je, da geometrijske opcije (point_on_curve, point_on_surface in curve_on_surface), niso nujno potrebne za modeliranje face_based_surface_models. Te vsebujejo topoloske lastnosti, ki jih lahko oblikujemo z drugimi topoloskimi opcijami. Smotrnost vkljucevanja nujno nepotrebnih opcij v sistem je predvsem dolgorocna. Izkaze se, da je precej operacij bolj ucinkovito izvrsljivih v parameterski obliki, kot v 3d prostoru. Pri tem je potrebno upostevati tudi dejstvo, da razlicni sistemi razlicno podajajo podatke. STEP pa mora tu poskrbeti za univerzalnost ob cim manj moznih pretvorbah.

3.4.3 Izvedbeni nivo 3 - IL 3

IL 3 je naslednja razvojna stopnja, ki omogoca prezentacijo in izmenjavo trdnih teles.

Slika 17 - Opcije v IL 3 (oblika in topologija)

Pod naslovom Geometrija se pri IL 3 uporabljajo vse opcije, kot so prikazane na sliki 3.

3.5 Primeri zapisa

3.5.1 Primeri zapisa iz naslova oblika

-- Shell_Based_Surface_Model

shell_based_surface_model_occurrence = ENTITY_NAME "="

"SHELL_BASED_SURFACE_MODEL" [sb_sm_scope_section]

"(" reference_list ")" ";" .

#500 = Shell_Based_Surface_Model((#490));

Zadnji primer predstavlja dejansko obliko podatka. Kazalec #490 se nanasa na opcijo iz topologije, Shell_Logical_Structure, ki je pod to stevilko tudi dolocena. (Glej original dokumenta Part 205)

-- Face_based_Surface_Model;

face_based_surface_model_occurrence = ENTITY_NAME "="

"FACE_BASED_SURFACE_MODEL" [fb_sm_scope_section]

"(" reference_list ")" ";" .

#380 = Face_Based_Surface_Model((#370));

Zadnji primer predstavlja dejansko obliko podatka. Kazalec #370 se nanasa na opcijo iz topologije, Connected_Face_Set, ki je pod to stevilko tudi dolocena. (Glej original dokumenta Part 205)

-- Geometric_3d_Surface_Set.

geometric_3d_surface_set_occurrence = ENTITY_NAME "="

"GEOMETRIC_3D_SURFACE_SET" [geometric_3d_surface_set_scope_section]

"(" reference_list "," reference_list "," reference_list ")" ";" .

#660 = Geometric_3d_Surface_Set((),(#130),((#1));

Zadnji primer predstavlja dejansko obliko podatka. Prvi kazakec, v tem primeru ga ni, bi definiral tocko. Drugi kazalec, #130, doloca krivuljo, ki je definiran apod tem naslovom, #1 pa definira povrsino, ki je definirana pod naslovom #1.

3.5.2 Primeri zapisa iz naslova topologija

-- Shell_Logical_Structure

shell_logical_structure_occurrence = ENTITY_NAME "="

"SHELL_LOGICAL_STRUCTURE" [shell_logical_structure_scope_section]

"(" ENTITY_NAME "," ".TRUE." ")" ";" .

#490 = Shell_Logical_Structure(#480,.TRUE.);

Zadnji Primer predstavlja dejansko obliko podatka. Pod naslovom #480 (v tem primeru) je definirana oblika, na katero se Logical_Structure nanasa. V tem primeru kazalec #480 definira Open_Shell. Oblika je podobna za vse ostale Logical_Structure, le da se kazalec nanasa na tisto opcijo, ki jo Logical_Structure doloca. To so se:

-- Face_Logical_Structure

-- Surface_Logical_Structure

-- Loop_Logical_Structure

-- Edge_Logical_Structure

-- Curve_Logical_Structure

-- Open_Shell

open_shell_occurrence = ENTITY_NAME "=" "OPEN_SHELL"

[open_shell_scope_section] "(" reference_list ")" ";" .

#480 = Open_Shell((#470));

Zadnji promer predstavlja dejansko obliko podatka. Kazalec #470 se nanasa na opcijo Face_Logical_Structure, ki Open_Shell doloci.

-- Connected_Face_set

connected_face_set_occurrence = ENTITY_NAME "=" "CONNECTED_FACE_SET"

[connected_face_set_scope_section] "(" reference_list ")" ";" .

#370 = Connected_Face_Set((#360);

Zadnji primer predstavlja dejansko obliko podatka. Kazalec #360 se nanasa na opcijo Face, ki Connected_Face_Set doloci.

-- Face

face_occurrence = ENTITY_NAME "=" "FACE" [face_scope_section]

"(" reference_list "," ENTITY_NAME ")" ";" .

#360 = Face((#330,#340),#350);

Zadnji primer predstavlja dejansko obliko podatka. Kazalca #330 in #340 se nanasata na opcijo Loop_Logical_Structure, Kazalec #350 pa na opcijo Surface_Logical_Structure.

-- Edge

edge_occurrence = ENTITY_NAME "=" "EDGE" [edge_scope_section]

"(" ENTITY_NAME "," ENTITY_NAME "," ENTITY_NAME ")" ";" .

#240 = Edge(#220,#221,#230);

Zadnji primer predstavlja dejansko obliko podatka. Kazalca #220 in #221 se nanasata na opcijo Vertex, kazalec #230 pa na opcijo Curve_Logical_Structure.

3.5.3 Primeri zapisa iz naslova geometrija

-- Cartesian_Point

cartesian_point_occurrence = ENTITY_NAME "="

"CARTESIAN_POINT" "(" REAL "," REAL "," [ REAL ] ")" ";".

#111 = Cartesian_Point(100.0000,-50.0000,-0.1629E-4)

Zadnji primer predstavlja dejansko obliko podatka. Podatki voklepaju predstavljajo koordinate kartezijskem koordinatnem sistemu.

-- Point_On_Curve

point_on_curve_occurrence = ENTITY_NAME "="

"POINT_ON_CURVE" [ ponc_scope_section ]

"(" ENTITY_NAME "," REAL ")" ";" .

#99 = Point_On_Curve(#60,0.50000);

Zadnji primer predstavlja dejansko obliko podatka. Pod naslovom #60 je definirana krivulja, na katero postavljamo tocko. Številka 0.50000 je Point_Parameter, ki doloca pozicijo tocke na krivulji.

-- Point_On_Surface

point_on_surface_occurrence = ENTITY_NAME "="

"POINT_ON_SURFACE" [ pons_scope_section ]

"(" ENTITY_NAME "," REAL "," REAL ")" ";" .

#98 = Point_On_Surface(#60,0.50000,0.40000);

Zadnji primer predstavlja dejansko obliko podatka. Pod naslovom #60 je definirana povrsina, na katero postavimo tocko. Ta je dolocena z dvema parametroma. 0.50000 je pp1 in 0.40000 je pp2.

Krivulje, kot so B_Spline_Curve, Pcurve in Surface_Curve, definiramo z osnovnimi enotami, kartezijskimi tockami. Na isti nacin definiramo tudi povrsine, npr. B_Spline_Surface. Ko so definirane vse tocke, ki predstavljajo krivulje ali povrsine, jih je potrebno zdruziti v te elemente. To dosezemo z logicnimi strukturami, ki podane tocke zdruzijo v zeljeno konturo oz. obliko. Konstrukcija slikovnega prikaza se nato nadaljuje na podoben nacin, ko ze ustvarjene elemente zdruzujemo, vkljucujemo v nastalo sliko.


A. Drolc
Pirnice 59
Ljubljana
Slovenija