ISO TR 26999 - Pravidla a pokyny pro použití procesně (funkčně) orientované metodiky v normách ITS, datových registrech a datových slovnících

Úvod

Cílem této technické zprávy je poskytnout návod na používání „procesně orientované metody“ nazývané také „modelování toku dat“ při zpracovávání mezinárodních norem a dokumentů pro „inteligentní dopravní systémy“ (ITS) a při tvorbě a zavádění ITS. Jejím účelem je sloužit především za základ pro vývoj systémových architektur vysoké úrovně pro ITS. Tyto architektury jsou nástroji, jež mají pomáhat při zavádění ITS, a mechanizmem pro identifikaci a podporu tvorby a používání norem.

Užití

Tato zpráva je navržena tak, aby popsala použití procesně orientované metodiky při tvorbě mezinárodních norem a dokumentů pro inteligentní dopravní systémy (ITS) a rovněž při vlastním návrhu a implementaci těchto systémů. Popisuje především základy návrhu systémových architektur vysoké úrovně pro ITS. Při procesně orientované metodice návrhu architektury vysoké úrovně je využíváno modelování toku dat a souvisejících procesů.

Použití architektury je důležité hlavně proto, že mnoho budoucích problémů je možno eliminovat nebo zmírnit již ve fázi návrhu systému a ušetřit tak značné náklady.

Hlavní výhodou použití procesně orientované metodiky při návrhu architektury ITS je její jednoduchost a srozumitelnost, zejména pro účastníky bez technické přípravy (např. řídicí pracovníky), kteří často právě na základě architektury systému rozhodují o jeho realizaci.

Výsledný návrh architektury systému je možno snadno využít v poptávkách, tendrech, výběrových řízeních a dalších podobných dokumentech jak pro software, tak pro hardware. Pro návrh architektury rozsáhlých systémů je procesně orientovaná metodika již překonaná, a proto je obvykle nutný převod do Unifikovaného modelovacího jazyka UML.

1. Předmět normy

Tato technická zpráva je určena pro používání procesně orientované metodiky (POM) v mezinárodních normách, technických specifikacích, technických zprávách a souvisejících dokumentech.

Tato technická zpráva popisuje používání POM při vývoji systémových architektur vysoké úrovně pro ITS. Vychází z výsledků práce v rámci projektu FRAME-S a fóra FRAME.

2. Souvisící normy

ISO TR 24529 Inteligentní dopravní systémy – Architektura systémů – Používání unifikovaného modelovacího jazyka (UML) v mezinárodních normách a dokumentech pro ITS

3. Termíny a definice

aktor (actor) dílčí prvek terminátora

architektura (generická definice) (architecture –generic definition) soubor koncepcí a pravidel pro systém, který popisuje vzájemný vztah mezi subjekty v celém systému, a to nezávisle na hardwarovém a softwarovém prostředí

očekávání (aspiration) vyjádření toho, co účastník chce, aby zavedení ITS přineslo; obvykle formulované v jazyce účastníka a proto zpravidla téměř nebo zcela bez formální struktury

komunikační rovina (communications viewpoint) pohled na architekturu, jenž znázorňuje vazby mezi stavebnicovými prvky ve fyzické rovině, které jim umožní navzájem komunikovat; bude obsahovat údaje o očekávaných propustnostech dat a případných ostatních omezeních, která budou mít vliv na konečný výběr komunikačního hardwaru a softwaru

funkční rovina (functional viewpoint) pohled na architekturu, jenž znázorňuje funkcionalitu, která bude potřebná pro splnění požadavků vyjádřených v potřebách uživatelů; funkcionalita je vykreslena jako soubor funkcí a datových skladů plus toky dat mezi nimi a toky dat mezi funkcemi a terminátory

architektura ITS (ITS architecture) forma systémové architektury sloužící jako nástroj v úvodních etapách zavádění ITS

model (model) znázornění subjektu, z něhož byly vyčleněny důležité prvky odstraněním určité jednotlivosti, a přitom byl zachován vzájemný vztah mezi klíčovými prvky celku

organizační rovina (organisational viewpoint) rovina znázorňující, jak stavebnicové prvky z fyzické roviny (nebo funkční roviny) mohou být přiřazeny různým typům organizace (nebo organizacím samotným, jsou-li známy), které budou zapojeny do zavádění ITS

fyzická rovina (physical viewpoint) rovina znázorňující, jak lze funkcionalitu z funkční roviny přiřadit různým fyzickým místům a sloučit do jednotlivých stavebnicových prvků

účastník (stakeholder) subjekt určitým způsobem zapojený do zavádění ITS

potřeby účastníků (stakeholder needs) oficiální formulace toho, co účastníci očekávají od zavedení ITS a z čeho je vytvořena funkční rovina založená na používání slova „bude“ nebo „musí“ (v angličtině "shall"); také se používá označení „potřeby uživatelů“.

systémová architektura (system architecture) ucelený, z vysoké úrovně provedený popis hlavních prvků nebo předmětů systému včetně jejich vzájemných vazeb

terminátor (terminator) subjekt, který působí vně systému, s nímž ale systém komunikuje buď proto, aby získal vstupy, anebo jemuž může odesílat výstupy; terminátory mohou být rozděleny na aktory, pokud je třeba

unifikovaný modelovací jazyk (UML) (unified modelling language) objektově orientovaný modelovací jazyk popsaný v ISO 19501

potřeby uživatelů (user needs) jiné označení potřeb účastníků

4. Symboly a zkratky

E-FRAME- Rozšířená rámcová architektura vytvořená pro Evropu

FRAME- Rámcová architektura vytvořená pro Evropu

ITS- Inteligentní dopravní systémy

KAREN- Základní architektura vyžadovaná pro evropské sítě

POM- Procesně orientovaná metoda

5 Vysvětlující informace

V kapitole jsou uvedeny informace, které blíže vysvětlují:

• ISO TC 204 – pracovní skupina WG1, která se zabývá tvorbou norem pro architekturu ITS, jako subjekt, pro který je technická zpráva hlavně určena.

• Pojmy systémy a architektury.

• Principy způsobů tvorby architektury ITS.

6 „Procesně orientovaný“ model

Procesně orientovaný model je poměrně účinný způsob popisu rámcové architektury ITS vysoké úrovně a, který je nezávislý na technologii použité při realizaci systému. Architektury ITS nižších úrovní (vyšší podrobnosti) jsou z tohoto modelu odvozovány. Rámcová architektura ITS obvykle není úplná a po doplnění podle požadavků účastníků vzniká „Definovaná architektura ITS“. Model zahrnuje tyto prvky:

1. Očekávání účastníků
   jsou obvykle neformalizovaná přání různých účastníků ITS (žadatelé, tvůrci, uživatelé, regulující orgány apod.)

2. Potřeby účastníků
   jsou strukturovaná vyjádření, která tvoří požadavky architektury ITS na systém. Měly by být formulovány jednoduchými standardizovanými prohlášeními, která popisují funkci nebo vlastnost, kterou by mělo zajistit zavedení ITS.

3. Funkční rovina
   někdy nazývaná funkční (logická) architektura obsahuje funkce, datové sklady a terminátory, které jsou navzájem propojeny toky dat. Vztahy mezi těmito komponentami jsou znázorněny schématy toku dat.

1. Kontextové schéma
   definuje systém jako ucelený subjekt, identifikuje však i všechny externí subjekty, s nimiž musí systém komunikovat. Proto se používá k ilustraci hranice mezi systémem a vnějším světem.

   1. Funkce
      definuje, co je třeba učinit, aby z daného souboru vstupů od jednoho terminátora(ů) byly vytvořeny požadované výstupy pro dalšího terminátora(y).

   2. Datové sklady
      slouží k ukládání dat, která je zapotřebí uchovávat po určitou dobu, po kterou budou tato data použita jednou nebo více funkcemi.

   3. Funkční toky dat
      slouží k zajištění datových spojení mezi funkcemi, datovými sklady a terminátory.

2. Schémata toku dat
   slouží ke znázornění vzájemné komunikace mezi funkcemi a datovými sklady, používanými k uspokojování potřeb účastníků a jejich komunikaci s terminátory a aktory, pomocí funkčních toků dat.

3. Model řízení
   definuje, jakým způsobem budou data zpracovávána.
   Na následujícím obrázku je znázorněn příklad jednoduchého kontextového schématu

4. 

4. Fyzická rovina
   Fyzická rovina (fyzická architektura) obsahuje subsystémy a případně moduly, které jsou propojeny fyzickými toky dat. Reprezentuje fyzickou realizaci systému, kde vztahy mezi jednotlivými komponentami jsou znázorněny schématy.

1. Kontextové schéma
   je stejné jako ve funkční rovině, protože je znázorňován stejný systém. Ve fyzické rovině je znázorněn pohled na fyzickou realizaci systému na rozdíl od „funkčního“ pohledu poskytovaného funkční rovinou.

2. Subsystémy a moduly
   tvoří základní stavební kameny, kde pro každou část systému je při fyzické realizaci přidělen samostatný subsystém, který se dále ještě obvykle dělí na moduly. Způsob tohoto přidělení závisí na tom, jaké fyzické části jsou považovaná za vhodné pro realizaci různých částí funkčnosti systému.

3. Schémata fyzické roviny
   znázorňují strukturu subsystémů a modulů ve fyzické rovině, kde se nejlépe jedno nebo více schémat použije k ilustraci vzájemné komunikace (fyzických toků dat) mezi subsystémy a moduly i jejich komunikace s terminátory a aktory.

5. Komunikační rovina
   obsahuje požadavky nejvyšší úrovně na komunikační linky mezi subsystémy a moduly. Tyto požadavky slouží k vytvoření komunikačního prostředí a používají se k výpočtu parametrů komunikace.

7 Typy architektury ITS

V procesně orientovaném modelu se v zásadě dají vytvořit tyto typy architektury ITS:

1. Rámcová architektura ITS
   přináší ucelený a flexibilní přístup k tvorbě architektur ITS. Používá se k vyjádření, co je třeba učinit pro naplnění „vize“ ITS. Jde o soubor výroků o službách, které by měly být podle předpokladů podporovány v budoucnu, bez určení způsobu realizace.

2. Definovaná architektura ITS
   se vytváří z rámcové architektury ITS. Zahrnuje potřeby účastníků a funkční rovinu, coby podmnožinu potřeb účastníků a funkčních rovin v rámcové architektuře ITS. Vybrané potřeby účastníků jsou odvozeny z očekávání účastníků v oblasti služeb, které mají být zajištěny zavedením ITS, podporovaného definovanou architekturou ITS.

3. Přeurčeně definovaná architektura ITS
   se vyznačuje tím, je několik možností seskupení funkcí do subsystémů a modulů ve fyzické rovině, což znamená, že jedna funkce může být ve více fyzických prvcích, i když uživatel vždy vybere jen jeden z nich pro dané nasazení ITS.
   Přeurčeně definovaná architektura ITS proto obsahuje také fyzickou rovinu a (případně) komunikační rovinu plus (případně) některé výstupy architektury ITS, které z nich mohou být vytvořeny.

4. Specifická architektura ITS
   je podobná definované architektuře ITS, ale proces její tvorby je odlišný. Tvorba specifické architektury ITS začíná použitím souboru očekávání účastníků pro danou službu, region, zemi nebo projekt.

8 Tvorba architektury ITS s použitím „procesně orientovaného“ modelu

Základní proces tvorby architektury ITS je vždy stejný, ať již se vychází z rámcové architektury ITS nebo definované architektury ITS. Rozdíl spočívá v tom, kdo provádí jednotlivé části tohoto procesu.

1. Tvorba rámcové architektury ITS
   představuje víceméně klasický sekvenční proces. Očekávání obvykle vyplynou z jednoho nebo více jednání se zástupci různých účastníků a vyjadřují jejich přání v oblasti služeb, které by ITS měl poskytovat v následujícím období. Tato očekávání je třeba transformovat do potřeb uživatelů, např. podle „Evropské rámcové architektura ITS“. Funkční rovina pak ukazuje funkcionalitu potřebnou k uspokojení potřeb účastníků. Architekt ITS musí zvolit a vytvořit toky dat, datové sklady i terminátory a aktory pro vytvoření konzistentní funkční roviny.

2. Tvorba definované architektury ITS
   je podobná jako u rámcové architektury ITS, ale je v něm doplněna navíc fyzická rovina a komunikační rovina. Po dokončení stejných procesů jako při tvorbě rámcové architektury ITS se vytvoří fyzická rovina přidělením každé funkce a datové sklady ve funkční rovině určitému subsystému (nebo místu) a případným rozdělením některých nebo všech subsystémů na moduly. Z funkčních toků dat mezi funkcemi obsaženými v subsystémech a modulech se vytvoří fyzické toky dat mezi subsystémy a moduly.

3. Přeurčeně definovaná architektura ITS
   se používá pro zajištění flexibility definované architektury ITS, protože bývá potřebné vytvořit více než jednu fyzickou rovinu nebo fyzickou rovinu s více částmi, aby funkce a datové sklady byly při přidělování subsystémům, resp. modulům seskupovány různými způsoby. Toto „přeurčení“ fyzické roviny přináší flexibilitu při výběru subsystémů (i modulů) a vede ke vzniku přeurčeně definované architektury ITS. Jako příklad lze uvést Americkou národní architekturu ITS.

4. Tvorba specifické architektury ITS
   je stejná jako v případě definované architektury ITS až na to, že specifické architektury ITS nejsou určeny k používání pro tvorbu dalších dílčích architektur ITS. Příkladem specifické architektury ITS může být architektura ITS pro informační systém veřejné dopravy nebo architektura ITS, která má zajistit plnění očekávání města v oblasti ITS.

Tvorba architektury ITS může být podpořena různými nástroji (software), které celý proces usnadňují a standardizují. Například v americké architektuře je používán nástroj „turbo-architektura“, v „Evropské rámcové architektuře ITS“ může být využit nástroj „FRAME Selection Tool“ apod.