FAKULTET ZA SAOBRAĆAJ I KOMUNIKACIJE

UNIVERZITET U SARAJEVU

SEMINARSKI RAD IZ PREDMTA INTELIGENTNI TRANSPORTNI SISTEMI

Tema: Europska ITS okvirna arhitektura 3.6.

SADRŽAJ

Sažetak..................................................................................................................................................4

1. Uvod..................................................................................................................................................5

1.1. Kratak opis.................................................................................................................................5

1.2. Područje primjene.......................................................................................................................5

1.3. Popis kratica...............................................................................................................................5

2. Pozadina............................................................................................................................................6

2.1. Potreba za europskom ITS okvirnom arhitekturom...................................................................6

2.2. Povijesna pozadina.....................................................................................................................7

2.2.1. Uvod....................................................................................................................................7

2.2.2. SATIN Task Force (borbena grupa).....................................................................................7

2.2.3. QUARTEX..........................................................................................................................8

3. Karen projekat...................................................................................................................................8

3.1. Uvod...........................................................................................................................................8

3.2. Europska ITS okvirna arhitektura..............................................................................................9

3.3. Odnos s drugim aktivnostima Arhitekture 3.3.1. Međunarodne Aktivnosti.............................10

3.3.2. RAID.................................................................................................................................10

4. Karakteristike i definicije I uvjeti okvirne arhitekture.....................................................................11

4.1. Uvod.........................................................................................................................................11

4.2. Definiranje okvirne arhitekture.................................................................................................11

4.3. Karakteristike okvirne arhitekture............................................................................................12

4.4. Korištenje sustava Arhitektura imena i pojmova......................................................................13

4.4.1. Uvod..................................................................................................................................13

4.4.2. Definicije sustava arhitektura za imena i pojmove.............................................................13

5. Proces razvoja okvirne arhitekture...................................................................................................16

5.1. Uvod.........................................................................................................................................16

2

5.2.Opća Arhitektura – opis procesa razvoja..................................................................................16

5.3. Korištenje opšteg procesa razvoja arhitekture pri Karen projektu.............................................20

5.4. Korištenje opšteg procesa razvoja arhitekture...........................................................................21

6. Dokumentacija za okvirnu arhitekturu.............................................................................................21

6.1.UVOD.......................................................................................................................................21

6.2. D3.1 - Funkcionalna arhitektura...............................................................................................21

6.3. D3.2 – Fizička arhitektura.......................................................................................................22

6.4. D3.3 - Komunikacijska arhitektura.........................................................................................23

6.5. D3.4 – Izvještaj o troškovima i koristima...................................................................................23

6.6. D3.7 - Modeli Inteligentnih transportnih sustava.....................................................................27

7. Usporedba Europske ITS okvirne arhitekture sostalim ITS arhitekturama.......................................27

7.1. Uvod.........................................................................................................................................27

7.2. US National svojom arhitekturom.............................................................................................27

7.3. Usporedba između europske i američke Nacionalne ITS arhitekture............................................28

7.3.1. Uvod......................................................................................................................................28

7.3.2. Korisnički zahtjevi.................................................................................................................28

7.3.3. Kontekst.................................................................................................................................30

7.3.4. Funkcionalnost.......................................................................................................................30

7.3.5. Fizička Arhitektura................................................................................................................31

7.3.6. Komunikacijska arhitektura...................................................................................................32

7.3.7. Ostali arhitektura dijelovi.......................................................................................................32

7.4. Usporedba između Europskog ITS okvira i ISO TICS referentna arhitektura...............................32

7.4.1. Uvod......................................................................................................................................32

7.4.2. Korisnički zahtjevi.................................................................................................................33

7.4.3. Arhitektura Definicija............................................................................................................33

7.5. Usporedba s australijanskom arhitekturom...................................................................................33

3

Sažetak

Ovaj dokument je izdan da djeluje kao "baza" Dokument za europsku ITS okvirnu Arhitekturu dokumentaciju. Ona ispunjava ovu ulogu na tri načina. Prvo ovaj dokument daje opis opće arhitekture razvojnog procesa koji je nakon Karen projekta za proizvodnju europske ITS okvirne arhitekture.

Drugo ovaj dokument pruža "pregled" od svih šest aktuelnih europskih ITS Okvirnih Arhitektura isporučenih dokumenata proizvedenih od strane Work Package 3. Između njih ti dokumenti opisuju glavne dijelove okvirne arhitekture (funkcionalni, Fizička i komunikacijska Arhitektura), izvještaj o rezultatima istraživanja na pitanja troškovne Prednosti i proučavanje načina na koji modeli se mogu koristiti u ITS-u. Rezultati rada implementacije su proizvodeni kao interno izvješće. Oni su bili uključeni u implementaciju isporučivog dokumenta (D 4.2) proizvedenog drugim dijelom Karen projekta.

Treće, ovaj dokument sadrži bilo koji materijal koji je zajednički za neke ili sve od ostalih šest dokumenata. Stoga obuhvaća dijelove koji pokrivaju potrebu za europsku okvirnu Arhitekturu, povijesnu pozadinu, odnos s drugim aktivnostima Arhitektura I karakteristike Okvirne arhitekture. Posebice je dio posvećen usporedbi između američke nacionalne arhitekture i europskih ITS Okvirnih Arhitektura.

Dokument također uključuje Aneks kao poseban dokument. Ovaj Dodatak omogućuje Trace Tablice pokazujući odnos između potreba korisnika i funkcija. Te tablice su korištene u arhitekturi i fizičkom sistemu stvaranja procesa opisane u poglavljima 4 i 5 europskih ITS fizičke arhitekture dokumenata (D 3.2).

4

1. Uvod

1.1. Kratak opis

Ovaj dokument se posmatra kao "osnovni dokument" za ostale europske ITS okvirne Arhitekture isporučene Dokumente koji su proizvedeni od strane Work Package 3 Karen projekta i koji su u javnoj domeni. To uključuje pregled svakog Dokumenta u obliku svog Sažetka, plus pozadinski material na razvoju sustava arhitekture u Europi i razlozima za osnivanje Karen projekta. Dijelovi dokumenta opisuju opće arhitekture sustava procesa razvoja korišteni od Karena i usporedbu s drugim Arhitekturama.

1.2. Područje primjene

Ovaj dokument je jedan od isporučivih Dokumenata koji je osiguran od strane Karen Projekta kao dio njegovog rada za definiranje europske ITS okvirne arhitekture. Ona pokriva svaku od šest javno dostupnih Okvirnih Arhitektura isporučivih Dokumenata koji su razvijeni od strane Work Package 3 u okviru Projekta. Drugi dokumenata u skupu su slijedeći:

D3.1 Europska funkcionalna arhitektura - ovaj dokument D3.2 Europske ITS fizička arhitektura D3.3 Europskih ITS komunikacijska arhitektura D3.4 Europski ITS izvještaj troškovnih prednosti D3.6 Europska ITS okvirna arhitektura Pregled D3.7 Europski ITS model za implementaciju ITS

Rad na ITS implementaciji uključen je u D 3.5, nije uključena u gore navedenom popisu kao Dokument koji je proizveden za uporabu unutar Karen projekta. Njegov sadržaj je bio uključen u implementaciju Studija Izvještaja (D 4.2) urađenog sa Work Package 4. Sve pojedinosti o Dokumentu navedeni u ovom dokumentu, uključujući i izvore osim europskih ITS Okvirne Arhitekture CD-ROM-u, su navedene u promatranom dijelu ovog dokumenta.

1.3. Popis kratica

Sljedeće kratice koriste se u ovom dokumentu i njegovom Dodatku dokumenta. Svaki od drugih dokumenata europskih ITS okvirnih arhitekturi će imati dio svojih vlastitih kratica:

DRIVE Namjenska Cestovna infrastruktura za sigurnost vozila u Europi ITE Integrirani Transport okoliša ITS Inteligentni transportni sustavi KAREN Keystone Arhitektura obavezna za europske mreže SATIN Arhitektura sustava za kontrolu prometa i integracija QUARTET četverostrano unaprijeđeno istraživanje telematike za zaštitu okoliša i prijevoz QUARTEX Proširenje QUARTET-aRAID analize rizika za ITS implementaciju

5

TARDIS prometa i cesta-DRIVE integrisani sustavi TCC Traffic Control Centar – saobraćajni kontrolni centarTIC prometni Informacijski centar TICS Informacije o prometu i kontrolni sustavi US () Američke Države UML unificirani jezik modeliranja

2. Pozadina

2.1. Potreba za europskom ITS okvirnom arhitekturom

Tijekom posljednjeg desetljeća, Europa je dobila značajno rano vodstvo u razvoju i razmještanju telematike tehnologija u transportu. Tempo u kojem je ovaj napredak postignut je impresivan i čini se da izravna posljedica je jasan fokus na razvoj dobro definirane "gradivne blokove" kao što su informisanje vozača, kontrole prometa, vođenje rute ili informacijski sustavi javnog prijevoza.

Inženjering sistema također je usmjeren duž slične linije, s razvojem nespojivih arhitektura koje predstavljaju temeljit pristup inženjeringu sustava specifičnim i usmjerenim aplikacijama područja. U nekim slučajevima, arhitektura šireg sustava koji obuhvaća više aplikacija su razvijene, iako su dizajnirani da zadovolje lokalne zahtjeve u gradu i / ili na regionalnoj razini, a ne europske.

Europa se danas suočava s izazovom integracije ovih "gradivnih blokova" u pan- Europski sustav arhitektura koji bi ponudili neki stupanj dosljednosti i sinergije u svim aplikacijama. Potrebu za napretkom i učinkovitost je velika i Europa se suočava s ogromnim izazovom. Kako može se široko-opsežna implementacija transportnog telematičkog sustava, koji se sada zove Inteligentni transportni sustavi ili ITS, u Europi poticati i koordinirati?

Provedba ITS-a mora proizvesti koristi za javni sektor i krajnjim korisnicima, kao i na privatne industrije i uslužnom sektoru. Druga važna razmatranja su konkurentnost europske industrije ITS-a, i kod kuće I u drugim dijelovima svijeta.

Jedan od načina da se s tim izazovima suoči je da zahtijeva svim zainteresiranim stranama da se pridržavaju dogovorenih Europskog okvira. Ovaj Okvir mora smjestiti nacionalne planove i podrškuraznih napora u istraživanju, standardizacija, puštanje u rad i ulaganja. Ona također moraju osigurati migracijski plan koji uključuje i gradi se na postojećim 'ostavštinama' sustava.

6

2.2. Povijesna pozadina

2.2.1. Uvod

Osnova za integrirani promet okoliša (ITE) koncept je utvrđen u EC Okvirni II DRIVE I projekt TARDIS (V1018), te je dalje razvijan brojnim projekatima tijekom EC okvirnog III DRIVE II programa.

Iako oba od tih programa su orijentirana na cestovni način prijevoza, brojne temeljne aktivnosti su poduzete koje su također primjenjuju i na druge načine, sad su uzete u obzir u EC Framework IV Telematika za transportni program. ITE može se smatrati da se sastoji od nekoliko različitih područja primjene, i dizajn ITE mora omogućiti tim različitim područjima razmjenu informaciju u zajedničkom formatu, za ažuriranje svoje strategije, te za obavljanje koordinirane akcije kontrole na prometnu mrežu. Razlozi za to su:

• Osigurati dosljednu i up-to-date sliku prometa i stanje prometne mreže;

• Za kontrolu državne mreže oko zajedničke reference optimalno koristi kolektivne kontrolne akcije (npr. prometne znakove, VMS);

• Za širenje relevantnih i ne-proturječnih informacija korisnicima, operatorima i vlasti.

Zajedničke optimalne reference gore navedene bit će propisane dodatnom lokalnom prijevozonom politikom upravljanja. Stoga će se razlikovati barem od zemlje do zemlje, a možda i između regija unutar zemlje.

2.2.2. SATIN Task Force (borbena grupa)

Tijekom DRIVE II SATIN Task Force je uveden 31. siječnja 1994 kako bi se proširio rad koji je započet u forumu Topic Grupe 10, koji je grupa sustava arhitektura postavljen kao dio Europske concertation aktivnosti tijekom DRIVE II programa. U radu su sljedeće stavke uključene: • Preporuka metodologije prikladna za pripremu transportne telematičke arhitekture, uključujući i kriterij procjene (za optimizaciju) i analiza sigurnosti;

• Prijedlog arhitekture sustava za ceste ITE koja bi uključivala sve transportne telematičke usluge.

Radove koje je vršio SATIN bio je ograničen u vremenu, te stoga u opsegu, uzimajući u doprinose iz velikog broja DRIVE II projekata. Njezin je cilj bio pokušati i izraditi konsenzus o metodološkim pitanjima utvrđivanjem dobrih praksi arhitekture razvijenih tijekom programa DRIVE II – vidi referencu 8 (i).

Paralelno sa prikupljanjem i sintezom rezultata, SATIN također je razvio metodologiju za potporu razvoju transportnog telematičkog sustava arhitekture - vidi referencu 8 (b).

7

2.2.3. QUARTEX

QUARTEX je proširenje DRIVE II projekata QUARTET (V2018) i GERDIEN (V2044) čiji je cilj bio pružiti smjernice za praktičnu ocjenu puta ITE arhitekture. U ovom radu urađeno je sljedeće:

• Metodologija za procjenu arhitektura - vidi referencu 8 (g). • Softver baziran alat za analizu arhitekture - vidi referencu 8 (h).

2.2.4. CONVERGE-SA

EC Okvirni IV Telematika za promet projekt CONVERGE-SA (TR1101) temelji se na radu i SATINA i QUARTEX. Ona proizvodi sljedeće:

• Smjernice za razvoj i procjenu sustava arhitektura - vidi referencu 8 (a); • Alat za analizu arhitekture sustava - vidi referencu 8 (c).

CONVERGE Smjernice su koristili kao izvor referenci po Karen Projektu za definiranje metodologije koja je korištena za stvaranje europskoe ITS Okvirne arhitekture. Ova metodologija je vrlo usko vezana uz opće arhitekturu stvaranja procesa koji je opisan u poglavlju 5. ovog dokumenta. CONVERGE Smjernice također čine osnovu za metodologiju koja je opisana u Europskoj ITS fizičkoj arhitekturi dokumenta (D 3.2) za stvaranje "primjera Sustavi "- vidi referenca 8 (m). Ovaj " primjer sustava " može biti bilo koji fizički sustav koji se mogu izraditi i provesti, ili druge arhitekture. Fizički sustavi su dakle isto kao i "ITS sustavi" prikazan na slici 2 u Dodatku ovom Dokumentu.

3. Karen projekat

3.1. Uvod

Karen (Keystone Arhitektura obavezna za europske mreže) Projekt je kreirao minimalno čvrst okvir potreban za implementaciju rada i izvodljiv ITS unutar Europske unije najmanje do 2010. To je napor Europske ITS arhitekture sustava, zahtjevan od skupine na visokoj razini High Level Group na putu transportne telematike, odobren od strane Europskog vijeća ministara i financiran DGXIII kao dio 4-og Okvirnog Programa. Projekt je započeo 1. travnja 1998, a čiji je cilj isporučiti dogovoreno, I promaknuto, transportna telematička

8

Okvirna Arhitektura koja će:

Definirati potrebne elemente za otvoreno tržište svojih proizvoda u cijeloj Europe i ostatka svijeta, za europske ITS industrije;

biti osnova za izgradnju konsenzusa o pitanjima koja će još uvijek spriječiti rasprostranjene implementacije ITS-a u Europi, a time i dopustiti svim kategorijama korisnika na kupnju troškovno učinkovitih ITS proizvoda koji će raditi na isti način u cijeloj Europi;

Osigurati most između njegove zajednice i onih stvaranju trenutne i budućnosti tehnologije koje se mogu koristiti ITS;

Budite vodič za javne investicije na osnovnu infrastrukturu potrebnu za implementaciju ITS usluga;

Podrška identifikaciji područja u kojima nova istraživanja i demonstracije su potrebna.

Karen Projekt je izradila sljedeće glavne izlaze - vidi reference (k) (q) u Poglavlju 8:

konsolidirani Popis europskih ITS potreba korisnika (ovaj dokument);

Europska ITS okvirna arhitekturi (dokumenti D3.x);

Preporuke za implementaciju Okvirne arhitekture (dokumenti D4.x).

Svi ovi se mogu naći na bilo kojoj europskoj ITS okvirnoj Arhitekturi CD-ROM izdanom od strane Europske komisije.

3.2. Europska ITS okvirna arhitektura

Europska ITS okvirna Arhitektura mora uskladiti nacionalne planove i podršku raznih napora u istraživanju, standardizaciji, puštanju u rad i ulaganju. Također mora osigurati migracijski plan koji uključuje i gradi se na postojećim 'ostavštinama' sustava. (Za raspravu o tome što se podrazumijeva pod Okvirnom Arhitekturom vidi Dodatak). Zajednički okvir daje specifikacije koje omogućavaju:

Kompatibilnost informacije isporučene krajnjim korisnicima, kroz različite medije;

Kompatibilnost opreme sa infrastrukturom, omogućivši bešavna putovanja u cijeloj Europi;

osnova za regionalne, nacionalne i europske vlasti za proizvodnju master planova i preporuks kako bi se olakšalo uvođenje ITS-a;

9

otvoreno tržište za usluge i oprema gdje kompatibilan pod-sustav je ponuđen (nema više ad hoc rješenja);

Ekonomija razmjera u proizvodnji opreme dopuštaju konkurentne cijene i jeftinija ulaganja kada kompatibilnost je zajamčena;

Poznato mjesto na tržištu u kojem proizvođači mogu dostaviti proizvode sa smanjenim financijskim rizikom.

3.3. Odnos s drugim aktivnostima Arhitekture 3.3.1. Međunarodne Aktivnosti

Postoje dvije glavne međunarodne (tj. izvan Europe) djelatnosti arhitekture iz kojih informacija je lako dostupna, I to US nacionalna ITS arhitektura i posao koji obavlja ISO/TC204/WG1. Valja napomenuti da je rad također ide drugdje, npr. U Japan, Koreju i Australiju. Oba US nacionalna Arhitektura i ISO/TC204/WG1 Referentna arhitektura počinje s "green field", a ne uzima u obzir bilo koji postojeći sustav ili opremu. Iako su trebali biti razumno sveobuhvatni, američki servis korisničkih zahtjeva je sada prepoznat kao nepotpuno primjenjivan izvan SAD-a. 32 transportna informisanja i kontrolna sustava (TICS) osnovnih usluga proizvedene od strane ISO/TC204/WG1 bazirani su uglavnom na američkom servisu korisničkih zahtjeva, kao rezultat toga, oni imaju tendenciju da budu usmjereni prema američkim problemima i željama. Američka nacionalna ITS arhitektura i ISO TICS Referentna arhitektura su opisani detaljnije u Poglavlju 7. ovog dokumenta.

3.3.2. RAID

To je studija o arhitekturi sustava izvedena kao dio EC 4-og Okvirnog programa. od siječnja 1998 do ožujka 1999 pomoću pod-seta Karen konzorcija. Cilj RAID-a je identificirati prepreke koje bi mogle spriječiti uspješnu implementaciju ITS-a unutar EU, i preporučiti moguća rješenja za prevazilaženje njih. Rizici koji su smatrani su one koje mogu ometati ili spriječiti provedbu:

• Europska ITS okvirna arhitektura generalno;

• Bilo koji pojedinačni ITS.

Sva područja ITS-a su uzeta u obzir, koristeći znanje i stručnost oba člana tima, i opsežne grupe vanjskih organizacija osnovane od strane Karen Projekta. Iako nije specifičan cilj, izlaz RAID projekta služi kao dodatna osnovna informacija za rad Karen projekta. RAID izvješće koji opisuje glavne rizike i njihove predložene strategije ublažavanja, nalazi se na Europskoj ITS okvirnoj arhitektura CD-ROM-a koji je dostupan iz europskih Komisija.

10

3.3.3. COMETA

COMETA projekt (TR4005) se izvodi istovremeno sa Karen i ima za cilj razvoj otvorene arhitekture za on-board sustave u komercijalnim vozilima. U COMETA-i je definiranje i projektiranje modularnih asocijacija širok raspon on-board funkcija za podršku stručnih poslova prijevoza cestom, i učinkovita sučelja s globalnim prijevoznim sustavom telematike. Primjeri komponenata uzeti u obzir za on-board sustave uključuju uređaje za on-board uzimanje podataka i obradu podataka, podrška pri vožnju, alati za on-board dijagnostiku na daljinu, mehanizme za razmjenu podataka unutar vozila i razni akteri uključeni u prijevoznom lancu, digitalni tahograf, uređaji za elektroničku cestarine i sl. Dodatne informacije mogu se naći o COMETA Projektu iz reference 8 (j), ili iz vlastite web stranice na "http://www.cometaproject. com / ". COMETA i Karen imaju neke zajedničke članove, a tu je aktivna veza i suradnja između njih. Praktična posljedica ove veze i suradnje je u tome što su arhitekture kompatibilne.

4. Karakteristike i definicije I uvjeti okvirne arhitekture

4.1. Uvod

Prije nego što krenemo na pregled onoga što je u ovom okviru europske arhitekture važno je da pogledate njihove karakteristike i date definicije mnogih pojmova korištenih u razvoju arhitekture. To će pomoći čitateljima ovog i drugih dokumenata europskih ITS Okvirnih Arhitektura da razumiju ono što Arhitektura i jest i nije.

4.2. Definiranje okvirne arhitekture

Okvirna Arhitektura definira i opisuje što treba biti uključeno u sustav koji može ispuniti zahtjeve skupa korisničkih potreba. Za Europsku ITS okvirnu arhitekturu nalaze se u odvojenom dokumentu (vidi referencu 8 (k)) urađenom u drugom dijelu Karen projekta.

Okvirna arhitektura izražava sustav na više načina. Ovdje su dani različitih dijelovi arhitekture koji su kao što slijedi.

• Funkcionalna arhitektura: potrebna funkcionalnost sustava da ispuni korisničke potrebe.

• Fizička arhitektura: način na koji funkcionalnost se može provoditi kao aplikacije da zadovolje potrebe korisnika. Ove aplikacije također mogu ispunjavati korisničke potrebe na način koji se ne može izraziti u funkcionalnom smislu, kao što je fizička karakteristika. Oni predstavljaju jedan od načina za stvaranje aplikacija, može naravno biti drugih, ali postojanje tih ovisit će o stvarima kao što su provedba ograničenja za pojedine sustave.

11

• Komunikacijska arhitektura: veza koje omogućuju da podaci budu razmijenjeni između programi u fizičkoj arhitekturi, i između aplikacije i vanjskog svijeta.

Europska ITS okvirna arhitektura također uključuje i druge stvari kao što su Cost Benefit Study i implementacija studija. Ove studije opisuju prednosti koje se mogu očekivati da narastu od implementacije arhitekture, a neki od načina na koji se postojeći sustavi mogu biti premješteni u skladu s arhitekturom. Svaki od pet opisanih dijelova arhitekture su urađeni za Europsku ITS arhitekturu.

4.3. Karakteristike okvirne arhitekture

U općim uvjetima Europske ITS okvirne arhitekture ima neke glavne, ili temeljne, karakteristike. To se može izraziti u sljedeća dva načina. Okvirna arhitektura je sve od sljedećeg.

• Otvorena: - to znači da sve dobavljači, operatori i korisnici će moći iskoristiti ono što je u arhitekturi.

• Multi-modalna: - to znači da arhitektura je dizajnirana da se odnosi na sve oblike cestovnog prijevoza, ne samo privatne automobie. Tu su i sučelja prema drugim oblicima prijevoza koji ne koriste ceste. Primjeri su teške željeznice, more i zrak.

• Nezavisna tehnologija: - Arhitektura ne zahtijeva ili unapređuje uporabu posebne tehnologije. To međutim kako god unapređuje korištenje generičkih rješenja za što više tehnologije koje su dostupne. Na primjer komunikacijska arhitektura (vidi referencu 8 (n)), može se unaprijediti uporaba bežične komunikacije u neke njegove analize, ali ne i točan tip. Drugim riječima, ne postoje uvjeti za korištenje pojedinih frekvencija, protokola, itd.

Okvirna arhitektura nije bilo što od sljedećeg.

• Dizajn sustava ili komponente: - nije moguće proizvesti ništa (hardware ili software) direktno iz sadržaja Okvirne arhitekture. Definicije i opisi u arhitekturui su na razini koja je previsoka za ovo da se izravno postigne.

• Specifikacija sustava: - Arhitektura neće biti predstavljena na takav način da može se izravno koristiti kao specifikacije za sustav, bilo da je to za neke hardvere, ili neki softvere. Međutim, dijelovi arhitekture mogu se koristiti kao polazište za izradu sustava specifikacije za komponente pojedinačnih sustava. To je objašnjeno u Fizičkoj Arhitekturi izrađenog Dokumenta - vidi referencu 8 (m). Uvažavanje tih karakteristika će pomoći čitateljima tih dokumenata i korisnika arhitekture da razumiju svrhu i ograničenja.

12

4.4. Korištenje sustava Arhitektura imena i pojmova

4.4.1. Uvod

Postoji nekoliko Arhitektura sustava za imena i pojmove koji su u uporabi u Europi i u ostataku svijeta. Neki od njih proizlaze iz razlike u pristupu arhitekture razvoja, dok drugi su različiti nazivi za slične dijelove arhitekture. Taj dio dokumenta koji daje definicije uglavnom koriste imena I pojmove koji su i relevantne za europske ITS okvirne arhitekture.

4.4.2. Definicije sustava arhitektura za imena i pojmove

Imena i uvjeti navedeni su u nastavku abecednim redom, a ne u bilo kojem redoslijedu važnost. (A) Komunikacijska Arhitektura

Ova arhitektura definira komunikacijske mehanizme koje se koriste za povezivanje komponenti prostorne Arhitekture - vidi kasnije definiciju. Za daljnje informacije pogledajte Poglavlje 5, gdje se također raspravljalo o njegovoj uporabi u Europskoj ITS okvirnoj arhitekturi.

(B) Konceptualni model Općenito govoreći, modeli su način na koji ljudi razmišljaju o stvarima. Kada osoba ima mentalnu sliku u svom umu o onome što sustav izgleda, ili način na koji se sustav ponaša, onda je to konceptualni model.

Više strogo to je bilo na visokoj razini opisa koji je u stanju da: • predstavljaju određeno sustavsko pitanje; • olakšaju komunikaciju i razumijevanje o pitanju; • pojednostave temu ili pitanje; • predstave ukupne odnose; • definiraju određene konstrukte.

(C) Kontekst dijagram

Ovaj dijagram pokazuje kontekst u kojem će postojati sustav koji predstavlja arhitekturu. Kontekst je dio vanjskog svijeta s kojima sustav se mora sučeljavati, ako je to raditi i dostaviti usluge i sadržaje potrebne za korisnike. Vanjski svijet predstavlja Terminatora - vidi u nastavku.

13

(D) Kontrolna arhitektura

Ova arhitektura se koristi za prikaz toka kontrole podataka u okviru arhitekture. Kontrola podataka je podatak koji se koristi za uzrokovanje dijelova arhitekture za obavljanje funkcionalnosti. Tako se može koristiti za aktiviranje funkcija ili procesa (vidi dolje). Kontrola podataka može biti poslana u isto vrijeme i na istom mjestu kao i druge podaci, na primjer prometnih tokova, video snimke, itd. U Europskoj ITS okvirnoj arhitekturi, gledanje kontrole je snimljeno korištenjem "Okidača" protoka podataka u Funkcionalnoj arhitekturi. Ovo su tokovi podataka koji se mogu biti korišteni od samo jedne funkcije za pokretanje aktivnosti od strane druge funkcije. Daljnja rasprava o tome je predviđena u Poglavlju 2 funkcionalne arhitekture izrađenog dokumenta (D 3.1).

(E) Troškovi Prednosti

To su rezultati analize troškova proizvodnje nečega kad se usporedi s prednostima koje će pružiti. Za Arhitekturu "nešto" je ono što se proizvodi od njega. U slučaju Europske ITS okvirnae arhitekture ovo može biti bilo fizički sustavi ili arhitekture. Za daljnje informacije pogledajte Poglavlje 5, gdje je njegova uporaba u Europskoj ITS okvirnoj arhitekturi je također raspravljana.

(F) Podaci

Podaci su sirove vrijednosti, npr. brojevi ili znakovi, koji će nakon obrade definirati stanja ili uvjete. U arhitekturi se primjenjuju na sve koji se prikupljaju od izvora koji je izvan sustava i da predstavlja arhitekturu. Mogu biti dvije osnovne vrste podataka, analogni i digitalni. Analogni tip obično se obrađuje u sučelju za sustav da se pretvore u digitalne podatke. Digitalni podaci mogu se također prikupljajti izravno, npr. iz drugog sustava. To može ostati "podatak" u Arhitekturi čak i nakon obrade, analize i skladištenja.

(G) Podaci Arhitektura

Ovo je drugo ime za informacijsku arhitekturu - vidi u nastavku.

(H) Protok podataka

To je definicija načina na koji podaci sele iz jednog elementa u drugi. Europska ITS okvirna arhitektura može koristi tri osnovna tipa protoka podataka: funkcionalni, prostorni i Terminator. Prvi i posljednji od njih su dijelovi Funkcionalne arhitekture - vidi u nastavku, a definirani su u Dodatku 2 referenci 8 (l). Fizički protok podataka dio je fizičke arhitekture - vidi u nastavku, te su definirani u referenci 8 (m).

14

(I) Spremišta podataka

Ovo se koristi za predstavljanje zbirke podataka koje mogu biti pozvane preko jednog ili više funkcija, a time i sastavni dio funkcionalne arhitekture - vidi u nastavku. To može biti upravljano jednom funkcijom, ili otvoren za pristup od strane više funkcija. Njegov sadržaj može biti definiran u smislu identiteta podataka koje ona sadrži. Korištenje spremišta podataka unutar Europske ITS funkcionalne arhitekture je definirana u referenci 8 (m).

(J) Implementacija

To je proces koji se koristi za stavljanje nečega u uporabu. Za fizikalni sustav to će biti proces koji omogućava da se stavljaju u uporabu u njegovoj stvarnoj fizičkoj lokaciji. U slučaju arhitekture to će značiti što ga čini dostupnim za korištenje za razvoj vlastitih fizičkih sustava - vidi kasnije definiciju. Vrlo često arhitektura će uključivati "Deployment studiju" koja će razmotriti načine na koje arhitektura može se primjenjivati u stvarnom svijetu. Za raspravu o njegovoj uporabi u Europskoj ITS okvirnoj arhitekturi vidi poglavlje 5.

(K) Funkcija

To je dio funkcionalne arhitekture, - vidi u nastavku, koja radi nešto, to jest obavlja funkciju. Ova funkcija može biti jednostavna ili može biti složena. To gotovo uvijek uključuje obradu podataka koje je primila funkcija za proizvodnju informacije, - vidi u nastavku, da je funkcija izlaza. Ove informacije će biti poslane na druge funkcije, Terminatora (vidi dolje) ili na spremište podataka (vidi gore). Za definiciju njihove upotrebe unutar Europske ITS funkcionalne arhitekture pogledajte Poglavlje 2 od reference 8 (l).

L) Funkcionalna arhitektura

Ova arhitektura omogućuje definiranje funkcionalnosti koje je potrebno osigurati ITS usluge i sadržaje koji su definirani u Uputama za potrebe - kasnije vidjeti definicije. Sastoji se od funkcija, protoka podataka i spremišta podataka, od kojih je svaki definiran na drugom mjestu u ovom poglavlju. Za daljnje informacije pogledajte Poglavlje 5, gdje je njegovo korištenje unutar Europske ITS okvirne arhitekture također raspravljano.

(M) Provedba arhitektura

Ovo ime je dato kao izvedenica fizičke arhitekture. Implementacija arhitekture dodaje operativno tehničke detalje elemenata opisanih u podsustavu i modulu Zakona o fizičkoj arhitekturi. Ovi detalji uključuju opise komponenti, jezika i komunikacijskih protokola. Također, proizvodi koji izvode funkcije i interakcije identificirani su pomoću fizičke i funkcionalne arhitekture, a dodatni detalji dizajna su pod uvjetom da se omogući stvaranje specifičnog koda. Provedba arhitekture se sastoji od dva glavna elementa. Prvi je specifikacija hardvera, operativnog sustava, i komunikacijskih protokola koji se koriste za provedbu sustava. Drugo sustavski model se koristi za identifikaciju specifičnih (komercijalnih) proizvoda koji provode podsustave i module definirane u Fizičkoj arhitekturi.

15

5. Proces razvoja okvirne arhitekture

5.1. Uvod

Svrha ovog poglavlja je u opsiu opće Okvirne arhitekture sistema razvoja procesam, kao i odnose i interakciju koja se dešava sa KAREN projektom, koji igra jako bitnu ulogu u razvoju cjelokupnog sistama Okvirne arhitekture. Dokument također treba pomoći u shvatanju kako svaka od cjelina zavisi jedna od druge, to jest kako su u međusobnoj interakciji

 5.2.Opća Arhitektura – opis procesa razvoja Opći proces za razvoja arhitekture sustava najbolje je ilustriran dijagramomprikazanim na sljedećoj stranici. To vrijedi za arhitekturu koja je na razinama 1 do 3 (uključeno) kao definirano u odnosu 8 (a). Proces je opisan u sljedećim paragrafima, i proizvodi broj arhitekture komponenti. Oni su identificirani od strane "kvadratića" na slici, a dodatno su označene podebljanim u tekstu koji slijedi. Identifikacija potreba korisnika je najvažniji dio arhitekture i u razvojnom procesu, jer je to temelj na kojem je izgrađena. To uključuje dobivanje ulaza sa sadašnjim i budućim zainteresiranim stranama o tome što bi htjeli to jest koje usluge bi sustavi iz arhitekture trebali pružiti na izlazu. Pokrit će se ne samo funkcionalni zahtjevi korisnika, nego i mngi drugi zahtjevi koje moraju ispuniti sustavi. Primjeri su održavanje, pouzdanost i sigurnost. Ovaj dio procesa razvoja arhitekture najbolje opisan u Smjernicama Arhitekture .U ovom, trenutku modeli se trebaju razvijati. Oni predstavljaju "stvarni svijet " situacije i, u nekim slučajevima mogu predstavljati scenariji o tome koju funkcionalnosti osigurava Arhitektura. Postoje tri vrste modeli, obuhvaća, Poduzetnost, Primarni proces i Slojevite preporuke. Prvi korak je razviti stvarnisustav arhitekture u tom kontekstru. Ovim se određuje kako će se vanjski svijet odnositi na sustave. Taj odnos je definiran kroz specifikacije za Terminatora. Ovi podaci opisuju što sistem treba pružiti vanjskom svijetu i ono što će morati učiniti s podacima koje dobiva od sustava. Terminatora su prikazani u kontekstu dijagramu.Terminator služi da opise kontekst dijagrama, zajedno s potrebama korisnika a zatim se koriste za razvoj funkcionalne arhitekture. Ovaj definira funkcionalnost potrebne za ispunjavanje potreba korisnika i sučelje s vanjskim svijetom preko Terminatora. To će također uključivati definiciju podataka koje sustav koristi kao ulaz, u sebi kao procesuator i kao izlaz. To rezultira Informacijonom arhitekturom, koja može biti upotrijebljenja odvojeno od funkcionalne arhitekture. Sljedeći korak u razvoju arhitekture je uspostava fizičke arhitekture. Tako se svaki od zahtjeva može svrstati u određeni pod-sustav. Mora postojati jedan podsustav za svaku fizičku lokaciju koja se koristi od strane sustava. Treba koristiti do šest različitih generičkih fizička lokacija. To obuhvaća, glavnu, uz cestu, vozila, osobnie uređaje, teretnih uređaja i kiosk. Pod-sustavi mogu se podijeliti u Module funkcionalnosti koje oni sadrže, oni su složeni zbog različitih potreba korisnika. Za svaki pod-sustav i / ili modula specifikacije su napisane na temelju popisa funkcionalnosti koje oni sadrže. Ove specifikacije se onda mogu koristiti kao početna točka iz koje stvarnog sustava i / ili njihove komponente mogu biti proizvedeni. Fizička Arhitektura mora također uzeti u obzir sve potrebe korisnika, za razliku od funkcionalnih zahtjeva.Slika 1. KAREN dijagram procesa okvirne arhitektureKomunikacijska arhitektura je razvijena od fizičke arhitekture i ona definira komunikacije potrebe sustava. Ona opet također može uključivati neke zahtjeve i potrebe korisnika, gdje se oni prvenstveno odnose na specifične komunikacijske potrebe. Outpute komunikacijske arhitekture će predstavljati to jst činiti specifikacije

16

komunikacijske infrastrukture koje sustavi zahtijevaju, plus definicija sučelja za koja su potrebni standardi. Drugi izlaz iz fizičke arhitekture je organizacijska arhitektura. Dodjeljuje se organizacijama koje će ih koristiti samostalno. Razlog za stvaranje ove arhitekture je da pomaže definirati bilo kakvih problema koji mogu nastati zbog različitostosti koje odlikuju organizacije, kao i upute koje se odnose na različite dijelove sustave. Od fizičke i komunikacije arhitekture uvođenja studija i troškova Prednosti studija su proizvedene. Deployment Studija pokazuje kako sustavi izvedeni iz arhitekture može se primjenjivati. To se mora odrediti rokove koji su uključeni i kako se postojeći sustavi biti smješteni. Studija troškova ikoristi, daje prognozu očekivanih troškova i koristi koje proizilaze iz implementacije sustava. Analiza rizika se odnosi na fizičku, komunikacijsku i organizacionu arhitekturu, kao dodatno i troškova i koristi koje se odnose direktno na implementaciju studije. Ona definira rizika generiranih po svim ovim Arhitekture i studije. Obično oni će se kategorizirati na neki način prema težini i / ili utjecaja. Oni u većini teške kategorije imat će smanjenje strategija razvijenih za njih. Ove će se definirati mjere potrebne za smanjenje (ublažavanje) ili prijenos utjecaj rizika. Linije označene "ocjena" na slici 1 pokazuju gdje rade na kasnije faze razvoja arhitekture može uzrokovati revizije za rad u ranijim fazama. Ove izmjene može biti u više oblika, ali obično će zahtijevati promjene, kao što su dodatak na Arhitektonskom komponenti kao što su funkcije, Data prodavaonice, sustavi, podsustavi, moduli, plus funkcionalne i prostornog protok podataka. Izlaza iz procesa razvoja sačinjeni se iz nekoliko komponenti koje su identificirane gore. Oni se mogu sažeti u sljedećoj tabliciTabela1.

Komponenta arhitekture Izlaz Opis i buduće korištenje

Fizička arhitektura Sistemska specifikacija Koristi se za razvoj pod-sustavai modula koji se koriste za proizvodnju "pravog" sustava. Onmora biti sposoban da se koriste u razvojnom procesu. Moduli trebaju moći pokriti hardver, softvera, ili kombinaciju oba.

Komunikacijska arhtiketura Definisanje infrastrukture Identificira arhitkekturu koja će biti potrebna za podršku fizičkoj arhitekturi, to jest potrebne linkove.

Komunikacijska arhitketura Definisanje standarda Identificira bilo koji standard koji treba razviti zasučelja između da bi bila moguća komunikacija između modula ili unutar podsustava

17

Analiza rizika Migracione strategije Koraci koji su potrebni zaprijenos. Identificirani rizici ako i kada se oni ostvare . Obično projektivani za najviše značajni rizik.

Studija razvoja Strategija razvoja Opis rasporeda unutar sustava.Treba sadržavati kretanje sistema to jest strategije razvoja već postojećih.

Organizacijska arhitektura Ključna pitanja

Opis svih ključnih pitanjakoji se odnose na to kako različiti organizacije koje posjeduju i / ilikoristite sustav raditi jedne s drugima. To također može uključivati analizu podataka odnose između organizacija

Studija troškova i koristi Pitanja troškova i koristi Identifikacija bilo kakvih pitanja koja se odnose na trošak sustavaimplementacije i / ili koristikoje će pružiti. Mora postojati zbog smanjenja rizika.

5.3. Korištenje opšteg procesa razvoja arhitekture pri Karen projektu Razvoj europskoe okvirne arhitekture kao i Karen Projekt je slijedio proces razvoja arhitekture koji je opisan u prethodnom odjeljku. Odstupanja koja su prisutna, a uglavnom su rezultat visoke razine na kojoj je definirana okvirna arhitektura. Odstupanja od arhitektur predstavljaju komponente koje slijede:   Informaciona arhitektura: nisu razvijene odvojeno i uključene u funkcionalnu arhitekturu.

Organizacijska arhitektura: nije razvijena za sve. Ne postoji niti jedna (ili općenito) struktura za europske organizacije koje su uključene u vlasništvu i / ili korištenje svojih. Stoga se ne smatra odgovarajućim da se razvije ova arhitektura.

Analiza rizika: To provodi RAID projekt. Njegovi rezultati su dokumentirani zasebno, na CD-ROM-a koje donosi Europska komisija.

18

Odstupanja koja je napravio Karen Projekt s popisa rezultata prikazani su u tablici:Tabela 2. Komponenta arhitekture Izlaz Opis i buduće korištenje

Fizička arhitektura Sistemska specifikacija Uzorak specifikacije sistema je proizveden za primjer jednog sistema

Komunikacijska arhtiketura Definisanje infrastrukture Analiza pojedinih primjera sistema je pružena.

Komunikacijska arhitketura Definisanje standarda Potencijal za norme iz KAREN projekta

Analiza rizika Migracione strategije Prikazani rezultati RAID projekta.

Studija razvoja Strategija razvoja Izlazi pruženi od projekta 4 i Karen

Organizacijska arhitektura Ključna pitanja Nije prikladno zaEuropsku okvirnuarhitekturu, kao i kada organizacijskastruktura varira izmeđuEuropskih naroda, država,Okruzi, pokrajina, gradova,Županije, itd

Studija troškova i koristi Pitanja troškova i koristi U finansijskim izvještajima

5.4. Korištenje opšteg procesa razvoja arhitekture

Ako je potrebna potpuno nova arhitektura, ona može ( ili ne može) biti utemeljena na Evropskoj okvirnog ITS arhitekturi, tada je proces opisan u 5.3.i potrebno ga je slijedit.On je korišten i od strane Karen projekta i timova koji su odgovorni za razvojUS nacionalne arhitekture - vidi Poglavlje 7 ovog dokumenta. Svatko tko želi razvijati vlastiti prostorni sustav ili arhitekture iz europskih ITS treba slijediti upute iz dokumenata.za razvoj okvirne arhitekture treba slijediti korake i procese koji su opisani u implementaciji strategije radnog paketa 4 unutar Karen projekta - vidi referencu8 (p). Međutim,u svim tim dokumentima se ne opisuje razvoj stvarnog fizikalnog sustava ili arhitekture. Njihov razvoj je opisan u razvoju evropke fizičke arhitekture.

19

6. Dokumentacija za okvirnu arhitekturu

6.1.UVOD

Ovo poglavlje obuhvaća strukturu dokumentacije koja opisuje europsku ITS okvirnu arhitekturu. Ova dokumentacija koja je javno dostupna je podijeljen u šest dijelova kako slijedi:

D3.1 - Funkcionalna arhitekturaD3.2 – Fizička arhitekturaD3.3 - Komunikacijska arhitekturaD3.4 – Izrada izvjšća troškova i koristi D3.6 - Pregled (ovaj dokument)D3.7 - Modeli Inteligentni transportni sustavi

Dokument (D 3.5) koji nedostaje je proizveden samo za Karen Projekt to jest interna upotreba. Međutim, njezin sadržaj su uključene u europsku ITS Deployment studija (D 4.2) -vidi referencu 8 (p). Preostali dijelovi ovog poglavlja daju pregled svakog oddokumenta. Oni dokumenti koji su prilozima kao zasebni dokumenti imat će sažetke aneksa na kraju glavnog dokumenta.

6.2. D3.1 - Funkcionalna arhitektura

Ovaj dokument daje opis funkcionalne arhitekture koja je dio europske okvirne arhitekture. Funkcionalna arhitektura definira i opisuje što se funkcionalno treba uključiti u sustav koji treba da može ispuniti zahtjeve korisnika, kao i same Evropske okvirne arhitekture. Ove potrebe korisnika nalaze u posebnom dokumentu sadržanog u drugom dijelu Karen projekta. Ovaj dokument opisuje Funkcionalna arhitektura u nekim detaljima, a također obuhvaća metodologiju koja se koristi za njegov razvoj. To pokazuje veze s vanjskim svijetom putem Terminatora i kako je podijeljen u funkcionalnim područjima. Način na koji su podijeljeni u funkcije je također uključen, zajedno s dijagramima za sva područja. Ovi dijagrami (tzv. dijagrami protoka podataka) pokazuju kako se funkcije odnose jedne prema drugima, prema podacima prodavaonice i Terminatora kroz protok podataka. Detaljne informacije pružaju kroz opis protok podataka i podataka prodavaonice. Ti opisi funkcija nalaze se u tri odvojena aneksa dokumentu. Razlozi za korištenje ova tri dodatka je pojednostaviti studij arhitekture i kako bi se izbjegle konfuzije koje može stvoriti jedan veliki dokument. Pregled onoga što je u svakom funkcionalnom području mogu se dobiti od glavnog dijela dokumenta:Funkcije, protok podataka i podataka prodavaonice, koristeći svaku od tri aneksa. Ovaj dokument čini polaznu osnovu za opis Europske okvirne arhitekture. Taj opis će se proširiti na dalje dokumente koji će pružiti opisi drugih dijelova arhitekture, kao što su Fizička arhitektura i implementacija studije i tako dalje.

6.3. D3.2 – Fizička arhitektura

Ovaj dokument daje opis arhitekture koja je dio europske okvirne arhitekture. Fizička

20

arhitektura definira i opisuje kako funkcionalno stvorena u Europska svoju funkcionalnu arhitekturu može biti grupirana u obliku sustava koje se mogu proizvesti. Ovi sustavi će koristiti komponente koje su proizvedene od hardvera, softvera, ili mješavina dva. Kroz njihovo povezivanje u dijelove funkcionalne arhitekture, ovi sustavi će, naravno, biti u mogućnosti zadovoljiti neke ili sve od zahtjevima korisnika. Ove potrebe korisnika nalaze se u posebnom dokumentu koji je dio Karen projekta.U ovom dokumentu se posmatranje fizičke arhitekture vrši kroz primjere projekata. Ovaj pristup je izabran zbog toga što se fizička arhitektura može proizvesti na mnogo načina pomoću funkcionalne. Svrha ovih "primjera sistema" je primjena fizičkih sustava koji bi mogli biti proizvedeni i ispuniti neke odpotreba korisnika . Opis svakog sustava je sadržan u posebnom Dodatku (Aneks 1) u glavnom dokumentu radi lakšeg pristupa i čitanja. To uključuje podatke o dijelovima funkcionalna arhitektura (Funkcije, protok podataka i podataka prodavaonice) koji su uključeni u svaku sustav, kao i pružanje informacija o tome što oni mogu pružiti. Primjer specifikacije sustava koja se može koristiti za nabavku opreme za provedbu sustava, uključen je u drugom posebnom prilogu (Prilog 2) za glavni dokument. Također je dat opis metodologije korištene za stvaranje fizičkoh sustava. Također je dat opis metodologije korištene za stvaranje fizičkoh sustava i što se može koristiti za stvaranje arhitekture koji se temelje na europskim ovom okviru Arhitektura se raspravlja i opisani. Predlošci za dijagrame i dijelove opisa su u posebnom Dodatku (2). Tu su i savjeti o tome kako napraviti promjene u arhitekturi za razne opsege usluga koje sustav ili arhitekturu nudi i osigurava. Završni dio svakog sustava sadrži odjeljak "Ključna pitanja". To su pitanja koja treba rješavati i riješiti kako bi se omogućilo svakom sustavu da se uspješno koristi i provede.

Oni su istaknuti i grupirani u jednom poglavlju u glavnom dokument na razmatranje i druge poslove u okviru projekta Karen. Preliminarne sigurnosne analize (PSA) uključene su u jedan od sustavi. Namjera bi trebala da bude korišten kao model koji služi kao osnova za druge eventualno zatražene sisteme.Način na koji bi ovaj dokument trebao biti korišten i njegova uloga u ovom okviru Europske arhitekture bit će opisan u Pregled dokumenta.

6.4. D3.3 - Komunikacijska arhitektura

Ovaj dokument daje opis komunikacijske arhitekture koja je dijela Europske arhitekture kao njegove okvirne arhitekture. Komunikacija arhitektura definira i opisuje kakva komunikacijska veza treba da se koristi u sustavu u cilju podrške njegovom fizičkom protoku podataka. Ovi podaci fizičkih tokova prikazani su u posebnom dokumentu - drugi dio KarenProjekt.Komunikacijska arhitektura je opisana u nekim detaljima u ovom dokumentu, koji je također obuhvaća metodologiju koja se koristi za njegov razvoj, osnovne koncepte komunikacije uključujući opće točke o karakteristikama veze unutar sustava između različitih fizičkih lokacija, i između sustava i dijelova vanjskog svijeta s kojim se komunicira. Komunikacijski zahtjevi od nekoliko su opisani pomoću nekoliko primjera sustava.

21

6.5. D3.4 – Izvještaj o troškovima i koristima

Kako bi bila učinkovita za izrada i provedba bilo koje vrste okvirne arhitekture, bitno je da se jasno shavate troškovi i koristi koji su uključeni u čitav taj poduhvat. Na taj način, arhitektura može biti usmjerena na područja gdje se za novac može dobiti najbolja rijednost. Ovaj dokument ima za cilj da se naglasi potreba predstavljanja troškova i koristi pri studijama razvoja i usvajanja arhitekture Inteligentnih transportnih sustava (ITS). Cilj ovog zadatka je da se sagledaju vjerojatne prednosti koje će se dobiti od uvođenja Okvirne arhitekture (FA). Konkretno, smatra se da rezultati dobiveni Europskim Telematika projektima gdje je provedena integracija različitih aplikacija u zajedničku infrastruktura pokazala prednosti predsnosti u odnosu na djelovanja koja su pojedini segmenti činili odvojeno.

Cost – benefit analiza uzima u obzir

Uzmima u obzir troškove koji će nastati implementacijom određenog prijekta, kao i troškove koji će nastati ako se taj način en implementira.

Postoje mnogi sudionici u ovom cjelikupnom veoma složenom procesu, a neki od njih su :

Prizivođači ITS sistema

Operatori koji pružaju usluge (infrastruktura i javni prijevoz operatori idrugih usluga, kao što su stanice, elektronski mediji i tisak, automobilizmuorganizacije, itd.);

privatni korisnici (pojedini članovi javnosti);

komercijalni korisnici (tvrtke koje imat će koristi od ITS);

vlade i ostalih državnih tijela, te

tijela za standardizaciju.

Učesnici mogu biti korisnici ili davatelji ITS, ili u nekim slučajevima oba. U slučaju tijela ili organa za standardizaciju oni nisu ni korisnici niti davatelji usluga.

Troškovi

Što se tiče troškova, implementacija Okvirne arhitekture zahtijeva investicije, kao što su:

Ulaganja koja su već posvećena europskim arhitekturama (u 4. okvirna programa, a posebno Karen) i

Ulaganje koje će biti potrebno na nacionalnoj, pa čak i na regionalnoj razini za osnivanju EU-a u skladu sa nacionalnom ili regionalnom FA.

Troškovi njegovog okvira Arhitektura mogu se svrstati na dva načina: 22

Vrste troškova, i Po tome kako su nastali (to su sudionici gore navedeni).

Vrste troškova mogu se svrstati u smislu tri široke grupe kako slijedi:

Arhitektura troškova razvoja (identifikacija sustava arhitekture, u fazi planiranja, natječajnog procesa, tehničkog razvoja i pregleda rezultata);

Troškovi iskorištavanja (širenje / svijest / promocija, trening / obrazovanja, političke prihvaćanje; definiranje financiranja pristup );

Provedba troškovi (pronalaženje sredstava financiranja, migracije postojećih sustava, nabave i natječaja procesima, izgradnji i održavanju njegove države-, isporuka i prihvaćanje sustava, obuka o korištenju novih sustava i održavanje sustava).

Prednosti

Prednosti implementacije zajedničkog okvira arhitekture mogu se posmatrati na različitim razinama:

Pogodnosti dobivene kroz konkretne ITS aplikacija / usluga koje će koristiti zajedničku okvir arhitekture. Općenito, ove pogodnosti će dobiti smanjenje troškovi provedbe;

Pogodnosti dobivene kao rezultat interoperativnog rješenja između različitih usluga ili različitih geografskih područja

koristi dobivene kao rezultat njegovog raspoređivanje u Europi. To će povećati broj svojih usluga i smanjiti provedbu puta, sa svakim od tih usluga donosi svoje troškove i koristi.

Te prednosti mogu poprimiti sljedeće oblike:

Smanjena zapreke za ulazak na tržište za ITS proizvođačima i davateljima usluga, vodeći ka povećanju konkurencije i smanjenju troškova;

Smanjenje troškova za razvoj nacionalne ili lokalne arhitekture (kao što oni mogu koristiti Karen kao baza);

Smanjenje troškova razvoja ITS sustava sebe; Smanjenje troškova za kupnju opreme; Smanjuje troškove rada i održavanja; Smanjenje troškova korisnicima usluga (gdje proizvođači i operatori proći na štednju

u korisnici - iako u ovom slučaju, financijsku korist za operatere i dobavljačima navedenih gore će biti smanjena);

Smanjen rizik u razvoju i implementaciji sustava; Bolje poznavanje potražnja / prijevoz uzoraka; Poboljšana komunikacija između sudionika (na nacionalnoj i međunarodnoj razini)

23

Poboljšanje upravljanja u istraživanje i razvoj i standardizacija na nacionalnoj razini;

Interoperabilnost usluga (npr. tehničke, funkcionalne i ugovornim interoperabilnost); Više koordiniran i dosljedan uslugama, što dovodi do poboljšane kvalitete za

krajnji korisnik; Povećana multimodaliteta i Povećana veličina tržišta uslijed nižih troškova i više standarda usluga, dovodi do

povećanja zaposlenosti.

Te prednosti su međusobno u da su neki od njih nisu konačne ciljeve kao takve, ali su preduvjeti za postizanje druge pogodnosti, na primjer, interoperabilnost dovodi do više koordinirane, dosljedna i bešavne usluge.

Koristi se također može biti sakupljeno u smislu sljedećih skupina:

Tehničke prednosti; Socijalne naknade; Pravno-institucionalna koristi; Financijske koristi.

Koristi koje proizlaze iz zajedničkog okvira arhitekture su neizravni u tome da su učinkovito trećoj fazi od sljedeće sekvence:

1. Proizvodnja prihvaćeni standard ili rezultat (kao što je Karen arhitekture).

2. Primjena standarda / rezultirati putem ITS provoditelji (u razvoju lokalnih arhitekture ili u sustavu implementacije).

3. Prednosti koje proizlaze iz ove prijave, u smislu smanjenja troškova i vremena za razvoju i provedbi i smanjenja troškova pogona i održavanja.

Tabela3.Evropski nacionalni projekti implementacije arhtiekture

Država Finska Francuska Italija Nizozemska Švedska

Naziv projekta

TelemArk ACTIF ARTISTA Koepelarchitectu

ur

OPTIS

Područje Prijevoz putnika svim

Cestovni, željeznički i

Svi vidovi unutraš. Cestovni

željeznički i

Cesta

24

djelovanja vidovima(zeljeznica, cesta, voda i zrak)

unutarnjim plovnim putovima, plus

njihoveveze szračnim i morskim putevima.

transp. unutarnjim plovnim putovima, plus veza zrak i more

Ciljevi/ pristup

Usvaja pristup kroz radionice

Komunikacija između učesnika u prijevozu

Razvojnacionalnearhitektura zaITS koji služi kaoreferencaplatforma za provedburealne usluge

Pokazatikoherentnostirazličitih ITSelemenata, pokazatiusklađenost temeljza dalji razvoj arhitektura

Fokus na servise tokom vožnje

Troškovi (€)

0.6m (1998-

2000)

2m (1999-2001) 3m (2000-2001) 0.2m for

Koepelarchitectu

ur (1999-2000)

plus 2m for subarchitectures

0.1m

6.6. D3.7 - Modeli Inteligentnih transportnih sustava

Ovaj dokument daje uvod u ITS arhitekture i modele, a opisuje odnos europskih arhitektura na razinama kao što su nacionalna, lokalna, nivou usluga kao i sustava arhitekture. Razvijeni su razni modeli koji predstavljaju neke od mogućih ITS usluga sa različitih gledišta. Svaki model je dat pomoću pregleda, cjelinai kratkih opisa glavnih potrebe korisnika koje treba zadovoljiti. One se mogu koristiti za proizvodnju arhitekture ili sustava koja u sebi ima implementiran model. Referentnih modela, npr. 'Toranj Modeli' hvatanje i konstrukcijskih odnos između funkcije, i cjelokupnog ponašanja bilo kojeg sustav koji u skladu s njima. Enterprise modeli pokazuju strukturu odnosa koji postoje između organizacija, osoba, usluga i / ili funkcije, a modeli su opisani za promet i prometno tržište, tereta kao i menadžment, javni prijevoz, automatski sistem naplate naknade i institucionalna i pravna pitanja respektivno. Primarno proces nastoji opisati način na koji se se sve u sistemu

25

odvija. Modeli su se razvili da opišu ITS i njegovu okolinu da opišu lanac pružanja informacija i hitne usluge. Razvijanje ITS-modela je uključeno u cijenu. Završno poglavlje identificira pet različitih vrsta korisnika ovih modela, naime donositelje odluka, krajnjie korisnike, projektanate, infrastrukturne operatore i davatelje usluga, te predstavlja modele koji će biti od važnosti za njih.

7. Usporedba Europske ITS okvirne arhitekture sostalim ITS arhitekturama

7.1. Uvod

Svrha ovog poglavlja je da pružaju visoku razinu usporedbe između Europske ITSokvirne Arhitekture i drugih ITS arhitektura. Glavna je usporedba s američkom acionalnom ITS arhitekturom, kao metodologija je vrlo slična onoj koju koristi KarenProjekt za stvaranje europskog ITS okvira arhitekture. Druge arhitekture su također uzete u obzir.To obuhvaća one arhitekture razvijene na međunarodnoj razini od strane ISO sustava arhitektura radne skupine i one razvijene u Australiji. Ovo poglavlje ne namjerava dabude kritičan prema svakom arhitekturi, ali će pružiti pogled na njihov odnos prema Europskoj ITS okviru arhitekture.

7.2. US National svojom arhitekturom

Američka nacionalna ITS arhitektura duguje svoje postojanje Intermodalnom prijevozu na površini učinkovitost Zakona (ISTEA), koji je donio američki Kongres krajem 1992. Iz toga SAD-DOT, kroz Savezne autocestom uprave (FHWA) pokrenula program za izradu rhitektura sustava za ceste na temelju prometa u SAD-u. U prvom dijelu programaproizvedena je korisnik usluga Zahtjevi. Ove opisuju usluge koje arhitektura mora podržavati. Ostatak programa je podijeljen u sljedeće dvije faze:

Faza 1 (juni1993 - juni 1994): pripremu inicijalne arhitekture četiri odvojena timova koji djeluju u paralelnim i natjecanje za odabir Faza 2.Faza 2 (veljača 1995 - lipanj 1996): priprema konačne verzije arhitektura po jedan tim sastavljena od dva sudionika odabranih od četiri koja sudjelovao je u Fazi 1.

Sastoji se od sljedećih aktivnosti:

1. Održavanje arhitekture. To uključuje ispravak grešaka i uvođenja novih usluga na iskoristivost elektronsku dokumentaciju. Nedavno ovo je uključivao razvoj softverskih alata ("Turbo arhitektura") koji će pomoći u razvoju implementacije regionalne ITS arhitekture koja se temelji na SAD nacionalnoj ITS arhitekturi.

26

2. Arhitektura poboljšanja. Ove su proizvedene kao rezultat stvaranja novih korisničkih servisa. Prvi od njih je za autoceste i arhiviranje podataka za upravljanje uslugama.Trenutno pažnja je usmjerena na široki paket održavanja i ruralnog orijentirane korisničke usluge

3. Dostava kurseva. Cilj ovih kurseva je educirati

4. Osigurati podršku za arhitekturu. Osim za implementaciju, glavno korištenje arhitekture je pružiti temelj za stvaranje ITS standarda.

Oni su na temelju preporuka iz arhitekturnog razvoja, te u glavnom pokrivaju komunikacije između ITS aplikacija u raznim lokacijama - centralno, uz cestu, vozila, itd.

7.3. Usporedba između europske i američke Nacionalne ITS arhitekture

7.3.1. Uvod

Ovo poglavlje pruža stvarne usporedbe između Europske ITS okvirnearhitekture i američke naacionalne ITS arhitekture. usporedba je podijeljen u sekcijekoji odgovaraju glavnim dijelovima dvije arhitekture.

7.3.2. Korisnički zahtjevi

Zahtjevima korisnika za obje američke nacionalne ITS arhitekture i europske ITS Okvirne arhitekture su definirane prije glavne arhitektura stvaranje posla. U Karen projektu, ovo djelo je učinjeno u radu paket 2 (WP2) i bili su dokumentirani odvojeno od arhitekture same. Zahtjevi korisnika definiraju usluge koje arhitekture će pružiti i podršku.

Njihova struktura je u osnovi ista, povezane zahtjevi su grupirani zajedno. U SAD arhitektura zahtjevi su u podjeljeni "Pakete" dok u Karen su u "grupe". Ovo je prikazano u donjoj tablici.

Tablica 3 američkih snopova i Karen korisnik grupe:

Američki Korisnik usluge „Paketi „ Karen potrebe korisnika „grupe“

1.Upravljanja prometom 1. Opći

2. Upravljanje javnim prijevozom 2. Aktivnosti upravljanja

27

3. Elektroničko plaćanje 3. Policije / Izvršenje

4. Operacije komercijalnim vozila 4. Financijske transakcije

5.Upravljanje incidentnim situacijama 5. Hitne usluge

6. Sigurnosni sustavi 6. Informacije o putovanju

7.Upravljanje informacijma 7. Upravljanje prometom

8. Sustavi u vozilu

9. Upravljanje kolonom vozila

10. Javni prijevoz

US nacionalna ITS arhitektura

1.6.2.2 Prometno nadziranje uključuje funkciju prikupljanja podataka i pružiti sposobnost za prikupljanje podataka koji su potrebni za određivanje protoka prometa i predviđanje.

Europska ITS okvirna arhitektura

7.1.1.1 Sustav mora biti u stanju pratiti dijelove cestovne mreže za pružanje trenutnih prometni uvjeti (npr. tokova, brzine i vremena putovanja i sl.) kao u stvarnom vremenu podatke. Bilo koja razlika između dva seta zahtjeva korisnika će biti posljedica više faktora. To uključuje stvari kao što su razlike u transportna politika, zakonodavne procedure, upute zaprakse i jezika. Također, uporabu i značenje terminologije znatno varira.

7.3.3. Kontekst

Svaka arhitektura ima kontekst dijagram, koji pokazuje veze s vanjskim svijetom u kojoj svaki od njih postoje. U oba slučaja izvan svijet je prikazan pomoću "Terminatora". Američka nacionalna ITS arhitektura ima 60 "Terminatora" dok europske ITS okvirna arhitekture ima 20 godina. To je velika razlika, jer Europska Arhitektura je odlučila koristiti "generičke Terminatore", od kojih se svaki može sastojati od dva ili više "glumaca".

7.3.4. Funkcionalnost

Obe arhitekture su odlučile razviti funkcionalnost koje oni sadrže koristeći proces orijentirane metodologije. Za Europsku ITS okvirnu arhitekturu razloga za ovaj izbor su date u Poglavlju 2

28

funkcionalne arhitekture dokumenta (D 3.1). U arhitekture i funkcionalne analize je predviđeno kroz "top-down" pristup, tako da korisnici mogu vidjeti što više detalja kao što oni žele od onoga što je predviđeno po arhitekturama. Glavna značajka ovog pristupa je da je lako razumjeti, i mogu biti cijenjeni od strane onih koji nisu softver ili sustav stručnjaka

Međutim postoje dvije očite razlike u načinu na koji dvije Arhitekture opisuju njihove funkcionalnosti koje oni uključuju. Prvi je da se u US nationalna svojom arhitekturom opisa pruža Logičku arhitekturu", dok je u EuropskojITS okvirnoj arhitekturi predviđeno za "Funkcionalnu arhitekturu". Iako različita imena se koriste, njihov sadržaj je identičan. Druga glavna razlika je u tome što u US Nacionalna ITS arhitektura, funkcionalnost je podijeljena na "Procese", dok je u Europskoj ITS okvirnoj arhitekturi podijeljen u "funkcije". Format i sadržaj"Procesa" i "funkcija " su slični, a veze između oba su prikazani na protoka podataka Dijagrami (DFD's). TS

Tablica 4 funkcionalnih područja u SAD-u i Europskoj Arhitekturi

SAD Logičke Arhitektura Europski Funkcionalna arhitektura

1. Upravljanje kolonom vozila 1. Osigurano elektroničko plaćanje

2. Upravljanje gospodarskim vozilima 2. Osigurati sigurnost i hitneSadržaji

3. Osigurati praćenja vozila ikontrola

3. Upravljanje prometom

4. Upravljanje transitom 4. Upravljanje javnim operacije prometa

5. Upravljanje hitnim uslugama 5. Osigurati naprednu pomoć vozaču

6. Osugurati usluge vozaču 6. Osigurati pomoć putniku u toku putovanja

7. Osigurati elektroničke usluge plaćanja 7. Pružiti zakonsku podršku

8. Upravljanje arhiviranim podatcima 8. Upravljanje teretom

29

Unutar svakog od područja, funkcionalnost je podijeljena na "Proces"i "funkcije" kao što je gore opisano. U SAD-u nacionalna ITS arhitektura postoji u 482 "Procesa" te u Karen arhitekturi postoji 253 "funkcije ". Osim razlike u opsegu zahtjeva korisnika, glavni razlog za to razlika je američke nacionalne ITS arhitekture opisuje njegovu funkcionalnost u puno veću razinu detalja.Obje "logička"i "funkcionalna" Arhitekture uključuje opise "prodavaonice" koje drže podatke i "protok podataka" koje vode "Procesi"ili "funkcije" jedni s drugima, s "Terminatora" i "prodavaonice".

7.3.5. Fizička Arhitektura

Svrha prostorne arhitekture kao dio američke Nacionalne ITS arhitekture je potrebno dati nešto što zapravo može se koristiti za implementaciju ITS. Ona također pruža izvorneke od podataka koji se koriste u SAD komunikacijske arhitekture. Fizička Arhitekturaje podijeljena u 19 pod-sustava koji pokriva četiri klase. Ove četiri klase čine centarna cesti, putnički i vozila pod-sustave. Grupiranje se također uzima uračun pojedinog korisnika usluga koje je specifičan primjer pod-sustava pa će možda trebatipotporu i na taj način potrebu za smještaj različitim razinama funkcionalnosti.

Osim toga, tržište paketa su pod uvjetom da raspoređivanje orijentirane perspektiveUS National svojoj arhitekturi. Oni su prilagođeni da stanu - pojedinačno ili u kombinaciji -primjer stvarnog svijeta transportnih problema i potreba. Tržište paketa treba prikupljati zajedno s jednim ili više specifičnih podsustava s posebnim paketom opreme sposobnosti koje moraju raditi zajedno za isporuku zakupljene usluge prijevoza. U razvoju ITS arhitekture regionalne na temelju nacionalne ITS arhitekture, tržište Paketa općenito moraju biti prilagođeni za određene aplikacije.

Europska ITS fizička arhitektura je dizajnirana za različite namjene. Ovo djeluje kaopolazište za izradu ostalih nižih razina arhitekture i prostornog sustava. To može biti za provedbu na nacionalnoj ili lokalnoj razini, ili ITS proizvođača. Europska ITS arhitektura sama sadrži ono što se naziva "primjer sustavi". Nedavno uvođenje ideje nacionalnih arhitektura i regionalne ITS arhitekture slojeva US DOT donosi povezanost SAD i Karen arhitekture.Iako je sloboda za dodjelu funkcija i pod-funkcija tijekom pod-sustava je, u skladus europskim raznolikosti, to je veća u Karen.

7.3.6. Komunikacijska arhitektura

Opet SAD i europske verzije za komunikacije arhitekture su dizajnirani za različite svrhe. Američke komunikacije arhitektura pruža detaljnu analizu podataka opterećenja zahtijeva arhitekture. Arhitektura, plus podaci za implementaciju generičke scenarija, npr. urbane, ruralne i međugradski. To također se koristi za podršku aktivnosti američkih standarda koji je

30

nadodlazeći od juna 1996.Europski ured za komunikacije arhitektura gleda karakteristike glavnih "podataka tokova "u neki od" primjera sustava "proizvedeni za fizikalnu arhitekture. Neke preporuke su za stvaranje budućih standarda, a savjet je pod uvjetom da na željene karakteristike podataka veza, uključujući i one sa "Terminatora". Preporuča se metodologija za analizu je primijenjena na komunikacije u "primjer Sustava "koje su stvorene od strane korisnika Europske ITS okvirne arhitekture.

7.3.7. Ostali arhitektura dijelovi

Američka nacionalna ITS arhitektura uključuje analizu rizika dokumenta. Ovom dokumentupredstavlja analizu potencijalnih kritičnih rizika koji mogu odgoditi ili spriječiti razvoj ITStehnologije, i preporučuje ublažavanje planova, koji će eliminirati i smanjiti ove rizike zaimplementaciju procesa.

7.4. Usporedba između Europskog ITS okvira i ISO TICS referentna arhitektura

7.4.1. Uvod

ISO Arhitektura sustava je poznat kao TICS (prometne informacije i kontroluSystems) Referentna arhitektura. Razlog za njegovo stvaranje je osigurati platformu za druge grupe unutar dijela prometna telematike ISO, nego da djeluje kao "World-wide standard". Ipak je se koristi kao polazište za stvaranje arhitekture u Australiji.

Stvarne usporedbe s Europskom ITS okvirnom arhitekturom je teško, jerISO TICS arhitektura je kreirana koristeći različitu metodologiju.

7.4.2. Korisnički zahtjevi

Za ISO arhitektura, korisnički zahtjevi su definirani kao TICS temeljna usluge. Kao što je s Europskom ITS okvirnom arhitekturom, oni su bili proizvedeni prije početka arhitekture same, a opisani su u posebnom dokumentu u rasponu od ISO TICS arhitekturne dokumentacije. Temeljne usluge su podijeljene u 32 grupe usluga. ISO TICS temeljnih usluga korišteni su kao jedan od glavnih polazišta za određenje europskog ITS potreba korisnika. Njihov odnos je prikazan u sekundi dvije proračunske tablice (Dodatak F) s Europskom ITS potrebama korisnika.

7.4.3. Arhitektura Definicija

ISO TICS Arhitektura nema kontekst dijagram jer to ne postoji kao u OO metodologiji. veze s vanjskim svijetom prikazani su u na najvišoj razini, ili skupnih Use Case dijagram. U ISO

31

TICS arhitekturi, vanjskom svijetu zastupa 9 "glumaca ", obuhvaća, usklađenosti agencije, financijske, informacije dobavljač / potrošača, infrastruktura, mjesto izvora podataka, usluge Enabler, davatelja usluga, korisnik i vozila. Ovi "Glumci" su sve u interakciji s arhitekturom i svi od njih imaju hijerarhije drugih sudionika ispod njih. Kod hijerarhije su uključeni, ukupnibroj "glumaca" s kojima arhitektura sučelja postaje 33. ISO TICS arhitektura ignorira "pasivne glumce" na najvišoj razini, iako su osiguravaju ulazne podatake za arhitekturu. Oni su modelirane kao "sučelje klase" te su fizički povezani s hardver senzorom.

7.5. Usporedba s australijanskom arhitekturom

Australska ITS arhitektura je stvorena kako bi pomogao implementaciju ITS u toj zemlji. Glavni razlog za njegovo stvaranje je australski okruženja koje su vrlo različite od onih u drugim zemljama. To je uglavnom odraz geografije i klime Australije koji zahtijeva da putuju u nekim urbanim i ajudaljenijim područjima samo da treba poduzeti kada su se sve više i / ili različite informacije dostupne putniku. Arhitektura je sama po sebi vrlo slična ISO Arhitekturi koja je opisana u prethodnom dijelu. Ona koristi OO metodologiji s ima visoku razinu Use Case i "glumaca". Glavna razlika je u naglasku koji je stavljen na potrebe urbanog područja. To se posebno vidi u područjima funkcionalnosti, kao što su prija putovanja podatci, na izlet informacije, na izlet javni prijevoz informacija i putno vodstvo.

32