ÚŘAD PRO OBRANNOU STANDARDIZACI, KATALOGIZACI A STÁTNÍ OVĚŘOVÁNÍ JAKOSTI ČESKÝ OBRANNÝ STANDARD Praha 2020 990503 3. vydání VZÁJEMNÁ VÝMĚNA ELEKTRONICKÝCH DAT TÝKAJÍCÍCH SE SLEDOVÁNÍ MATERIÁLU ZAVÁDÍ STANAG 2185, Ed. 3 NATO ASSET TRACKING INFORMATION EXCHANGE REQUIREMENTS AND SYSTEM ARCHITECTURE GENERAL Požadavky NATO na výměnu informací o sledovaném materiálu a architektura systémů NAHRAZUJE ČOS 990503, 2. vydání, Oprava 1 VZÁJEMNÁ VÝMĚNA ELEKTRONICKÝCH DAT TÝKAJÍCÍCH SE SLEDOVÁNÍ MATERIÁLU
Transcript
ÚŘAD PRO OBRANNOU STANDARDIZACI, KATALOGIZACI A STÁTNÍ OVĚŘOVÁNÍ JAKOSTI
ČESKÝ OBRANNÝ STANDARD
Praha 2020
990503 3. vydání
VZÁJEMNÁ VÝMĚNA ELEKTRONICKÝCH DAT TÝKAJÍCÍCH SE SLEDOVÁNÍ MATERIÁLU
ZAVÁDÍ STANAG 2185, Ed. 3
NATO ASSET TRACKING INFORMATION EXCHANGE REQUIREMENTS AND SYSTEM ARCHITECTURE GENERAL
Požadavky NATO na výměnu informací o sledovaném materiálu a architektura systémů
NAHRAZUJE ČOS 990503, 2. vydání, Oprava 1
VZÁJEMNÁ VÝMĚNA ELEKTRONICKÝCH DAT TÝKAJÍCÍCH SE SLEDOVÁNÍ MATERIÁLU
ČOS 990503 3. vydání
2
(VOLNÁ STRANA)
ČOS 990503 3. vydání
3
ČESKÝ OBRANNÝ STANDARD
VZÁJEMNÁ VÝMĚNA ELEKTRONICKÝCH DAT TÝKAJÍCÍCH SE SLEDOVÁNÍ
MATERIÁLU
Základem pro tvorbu tohoto standardu byl originál následujícího dokumentu:
STANAG 2185, Ed. 3 ASSET, CONSIGNMENT AND PERSONNEL TRACKING INFORMATION EXCHANGE
Výměna informací ke sledování materiálu, zásilek a osob
5 Použité zkratky, značky a definice .............................................................. 7 5.1 Zkratky a značky ...................................................................................... 7
5.2 Definice a objasnění pojmů ...................................................................... 10
6 Předmět a účel SYSTÉMU sledování zásilek NATO .................................. 21
7 Základní charakteristika navrženého systému sledování zásilek NATO .... 21
8 Důvody a předpoklady pro zapojení ČR do systému sledování zásilek NATO ................................................................................................................. 22
PŘÍLOHY
PŘÍLOHA A – Model architektury systému sledování zásilek NATO (NATO CT SAM) ………………………………………………………….…
25
PŘÍLOHA B – Model architektury systému sledování zásilek NATO (NATO CT SAM) – Zásady a požadavky …………………………………
51
PŘÍLOHA C – Model architektury systému sledování zásilek NATO (NATO CT SAM) – Specifikace schémat XML ………………………….
139
PÍŘLOHA D – Model architektury systému sledování zásilek NATO (NATO CT SAM) – Schéma XML (v kódu XML) …………………………
205
PŘÍLOHA E – Model architektury systému sledování zásilek NATO (NATO CT SAM) – Příklady zpráv v jazyku XML ………………………..
221
PŘÍLOHA F – Model architektury systému sledování zásilek NATO (NATO CT SAM) – Zprávy a požadavky EDI …………………………….
PŘÍLOHA G – Rozšiřiteelný značkovací jazyk XML – základní informace a jeho použití v systému sledování zásilek NATO ………………..
235
PŘÍLOHA H – Unifikovaný modelovací jazyk UML – doplňující informace o jeho použití v systému sledování zásilek NATO ………………..
241
ČOS 990503 3. vydání
5
1 PŘEDMĚT STANDARDU
Základem pro tvorbu ČOS 990503, 3. vydání je STANAG 2185 Ed. 3. který byl nahrazen vyhlášeným STANAG 2185 Ed. 4. Ke STANAG 2185 Ed. 4 se ČR rozhodla přistoupit a zavést v budoucnu a požadavky v něm stanovené nejsou v tomto ČOS zohledněny.
ČOS definuje požadavky na sledování zásilek NATO podle STANAG 2185 Ed. 3, které jsou podmínkou pro zapojení do tohoto systému. Stanovuje a standardizuje výměnu informací ze sledování zásilek a architekturu systému sledování.
2 NAHRAZENÍ STANDARDŮ (NOREM)
Tento standard nahrazuje ČOS 990503, 2. vydání, Oprava 1.
3 SOUVISEJÍCÍ DOKUMENTY
V tomto standardu jsou normativní odkazy na následující citované dokumenty (celé nebo jejich části), které jsou nezbytné pro jeho použití. U odkazů na datované citované dokumenty platí tento dokument bez ohledu na to, zda existují novější vydání/edice tohoto dokumentu. U odkazů na nedatované dokumenty se používá pouze nejnovější vydání/edice dokumentu (včetně jeho změn).
ČOS 814501 - STANDARDNÍ ZNAČENÍ MATERIÁLU PRO PŘEPRAVU A SKLADOVÁNÍ
ČOS 990502 - DATOVÉ FORMÁTY PRO SLEDOVÁNÍ MAJETKU (MATERIÁLU)
ČOS 990504 - PŘEPRAVNÍ ETIKETY PRO SLEDOVÁNÍ MAJETKU (MATERIÁLU)
STANAG 1059 - LETTER CODES FOR GEOGRAPHICAL ENTITIES
Kódové označení zeměpisných celků
STANAG 2014 - FORMATS FOR ORDERS AND DESIGNATION OF TIMINGS, LOCATIONS AND BOUNDARIES
Struktura rozkazů, uvádění časových údajů, názvů míst a rozhraní
STANAG 2183 - NATO CONSIGNMENT TRACKING COMMUNICATIONS AND SECURITY REQUIREMENTS
Požadavky na spojení pro sledování materiálu v rámci NATO
STANAG 2233 - NATO CONSIGNMENT AND ASSET TRACKING BY RADIO FREQUENCY IDENTIFICATION
Sledování zásilek a materiálu v NATO pomocí radiofrekvenční identifikace
STANAG 2290 - UNIQUE IDENTIFICATION OF ITEMS
Jednotná identifikace výrobků
STANAG 2291 - NATO ASSET TRACKING „TO BE“ BUSINESS PROCESS MODEL - AAP-51(A)
Model obchodních procesů vhodných pro sledování zásilek
ČOS 990503 3. vydání
6
NATO - AAP-51(A)
STANAG 2493 - NATO GLOSSARY OF ASSET TRACKING TERMS AND DEFINITIONS – AAP-35
Terminologický slovník pojmů a definic NATO z oblasti sledování materiálu (zdrojů, prostředků)
STANAG 4329 - STANDARD BAR CODE SYMBOLOGIES – AAP-44(A)
Standardní znaky (symbolika) čárového kódu v NATO – AAP-44(A)
AAP-35 - NATO GLOSSARY OF ASSET TRACKING TERMS AND DEFINITIONS
Slovník termínů a definic NATO pro oblast sledování materiálu
ČSN ISO/IEC 8859-1
- Informační technologie - Jedním 8-bitovým bytem kódované soubory grafických znaků - Část 1: Latinská abeceda č. 1
ČSN 97 7117 - Elektronická výměna dat - Základy realizace normy EDIFACT
v systému EAN.UCC (EANCOM)
ČSN ISO 3166-1 - Kódy pro názvy zemí a jejich částí – Část 1: Kódy zemí
ČSN ISO 7372 - Výměna obchodních dat - Sborník datových prvků pro obchod
ČSN ISO 8601 - Datové prvky a formáty výměny - Výměna informací - Zobrazení data a času
ČSN ISO 9735-1 - Elektronická výměna dat pro správu, obchod a dopravu (EDIFACT) – Pravidla syntaxe aplikační úrovně (číslo verze syntaxe: 4, číslo vydání syntaxe: 1) - Část 1: Pravidla syntaxe společná pro všechny části
ČSN ISO 9735-2 - Elektronická výměna dat pro správu, obchod a dopravu (EDIFACT) – Pravidla syntaxe aplikační úrovně (číslo verze syntaxe: 4, číslo vydání syntaxe: 1) - Část 2: Pravidla syntaxe specifická pro dávkovou EDI
ČSN ISO/IEC 646 - Informační technika. 7-bitový kódovaný soubor znaků ISO pro výměnu informací
IEEE 754 - Reprezentace čísel s pohyblivou řádovou čárkou
ISO 15.434 - Transfer Syntax for high capacity ADC-media
Syntaxe přenosu pro vysokokapacitní média ADC. (Dosud nezavedena v ČR)
EANCOM® 1997
(UN/EDIFACT D.96A)
- EDI Standards Manual
Standardy elektronické výměny dat (EDI) – příručka
GS1 General
Specifications
- Všeobecné specifikace GS1
ČOS 990503 3. vydání
7
4 ZPRACOVATEL ČOS
Vojenský technický ústav, s.p., odštěpný závod VTÚPV, Ing. Jaromír Navrátil, CSc.
ID Identifikation Identifikace (ověření totožnosti), identifikátor
IEC International Electrotechnical Commission
Mezinárodní elektrotechnická komise
IFTSTA Transport Status Označení zprávy o přepravním stavu zásilky
ISAF International Security Assistance Force
Mezinárodní pomocné bezpečnostní síly
ISO International Organization for Standardization
Mezinárodní organizace pro standardizaci
JOA Joint Operational Area Prostor společných operací (společný operační prostor)
LLN Logistic Lead Nation Vedoucí stát v logistickém zabezpečení
ČOS 990503 3. vydání
9
Zkratka Název v originálu Český název
LOGFAS Logistics Functional Area Services
Služby logistických funkčních oblastí
LOGNET Logistics Net (Network) Logistická síť
LOGREP Logistics Reporting Logistická hlášení
LRSN Logistics Role-Specialization Nation
Stát specializovaný na vymezenou roli v logistickém zabezpečení
M&T Movement and Transportation Přesuny a přeprava
MC Military Committee Vojenský výbor
MEE Mission Essential Equipment Vybavení (prostředky) nezbytné pro plnění úkolu (mise)
MILU Multinational Integrated Logistics Unit
Nadnárodní integrovaná logistická jednotka
MNDDP Multinational Detailed Deployment Plan
Nadnárodní detailní prováděcí plán
NAMSA NATO Maitenance and Supply Agency
Agentura NATO pro technické zabezpečení a zásobování
NATIES NATO Asset Tracking Information Exchange Services
Služby NATO pro výměnu informací o sledování materiálu
NATO North Atlantic Treaty Organization
Organizace Severoatlantické smlouvy
NC3A NATO Consultation, Command and Control
Agentura NATO pro konzultace, velení a řízení
NDSS NATO Depot Support System Systém NATO pro zabezpečení skladů
NIC National Item Code Národní kód položky
NSN National Stock Number Skladové číslo NATO
OO Object Oriented Objektově orientovaný
PARTIN Party Information Informace o zúčastněné straně
PK Primary Key Primární klíč
POD Port of Debarkation Místo vyložení
POE Port of Embarkation Místo naložení
PSČ Postal Code Poštovní směrovací číslo
RECADV Receiving Advice Potvrzení příjmu
RFID Radio Frequency Identification Identifikace na rádiové frekvenci
RIC Reportable Item Code Kód hlášení položky
RIL Reportable Item List Seznam hlášení položky
ČOS 990503 3. vydání
10
Zkratka Název v originálu Český název
SAM Systems Architecture Model Model architektury systémů
SCAC Standard Carrier Alpha Code Standardní alfa kód dopravce (2-4 písmena)
SFOR Stabilisation Force Mírová mise v Bosně a Hercegovině
SI Système International d'Unites (francouzské označení)
Mezinárodní soustava jednotek fyzikálních veličin
SNLC Senior NATO Logisticians Conference
Konference hlavních logistiků NATO
SSCC Serial Shipping Container Code Sériový kód pro logistické jednotky
STANAG NATO standardization agreement
Standardizační dohoda NATO
TBD To be determined Dosud nestanoveno
TCN Transportation Control Number Kontrolní číslo přepravy
UCC Uniform Code Council Organizace, která stanovuje standardy čárových kódů v USA
UI User Interface Rozhraní uživatele
UK United Kingdom Spojené království
UML Unified Modeling Language Unifikovaný modelovací jazyk
UN United Nation Organizace spojených národů
UN/EDIFACT United Nation / Electronic Data Interchange For Administration, Commerce and Transport
Elektronická výměna dat pro správu, obchod a dopravu, vyvinutá v rámci OSN
UOM Unit of Measure Měrná jednotka
URL Uniform Resource Locator Jednoznačné umístění zdroje
WGS World Geodetic System Globální souřadnicový systém
XML Extensible Markup Language Rozšiřitelný značkovací jazyk
XSLT eXtensible Stylesheet Language Transformations
Transformace rozšiřitelného stylového jazyka
5.2 Definice a objasnění pojmů
Pojem Objasnění pojmu
ACROSS Tato sada nástrojů je částí LOGFAS. ACROSS se používá pro dlouhodobé plánování výzbroje pro obě strategická velitelství NATO. Sestává z Lineárního programovacího modelu, který vypočítává optimální složení výzbroje pro zásoby a nákup, aby se čelilo daným hrozbám a cílům.
ČOS 990503 3. vydání
11
Pojem Objasnění pojmu
Aktivace štítku RFID, uvedení štítku do používání (Tag Commissioning)
V případě štítku RFID jeho naprogramování unikátním identifikačním číslem. V případě čárového kódu jeho zhotovení.
Aktivita, činnost
(Activity)
Aktivita je to, co je modelováno pomoci diagramu aktivit, tedy business proces, pracovní postup nebo procedurální logika.
AMCC AMCC je modelová agentura pro celkové řízení strategických přesunů. V tomto směru AMCC ve spolupráci s členskými státy NATO sestavuje nadnárodní detailní prováděcí plán (MNDPP) a řeší strategické deficity podpory.
Architektura nasazení (Deployment
Architecture)
Zobrazení navrženého hardware, který bude tvořit nový systém spolu s technickými komponenty, které budou realizovat tento hardware. Zahrnuje specifikace pro zařízení, operační systém, síťové spoje, zálohovací jednotky apod.
Asociace, sdružení (Association)
Vztah mezi dvěma nebo více subjekty. Předpokládá připojení nějakého typu - například jeden subjekt využívá služeb jiného, nebo jeden subjekt je připojen k dalšímu přes síťové připojení.
ATM Asynchronní přenos dat znamená, že – na rozdíl od synchronního přenosu - okamžiky přechodu mezi jednotlivými přenášenými bity nejsou stejné (nemá konstantní délku bitového intervalu). Jednotlivé časové úseky musí mít svou vlastní identifikaci, aby bylo zřejmé, jaké údaje jsou přenášeny.
Audit sledování zásilky (Consignment Audit Trail)
Auditovací řetězec zásilky sestává ze:
- všech událostí ze sledování nebo jiných událostí, které spouští sama zásilka;
- všech událostí ze sledování spuštěných pro jakoukoli zásilku, jejíž součástí je nebo byla, a to po dobu trvání tohoto vztahu.
Audit sledování, audit trail
(Audit Trail)
Monitorování a zaznamenávání vybraných událostí a činností.
Poznámka: Často se používá originální výraz audit trail.
Board Foot Specializovaná míra používaná v USA a Kanadě pro objem řeziva. Představuje desku o rozměrech 1 ft x 1 ft x 1 in (ft = stopa, in = palec) ÷ 30,5 x 30,5 x 2,54 cm.
Business rules Pravidla fungování, pravidla činnosti (v tomto ČOS).
Poznámka: Je tendence výraz Business rules automaticky překládat jako obchodní pravidla, což v mnoha případech není přesné, protože zpravidla má výraz obecnější obsah (ne pouze obchod). Proto byl v tomto ČOS ponechán originální výraz.
CT Cell Jednotka (článek, buňka) systému sledování zásilek.
CT Collect Point Sběrné místo dat RFID systému sledování zásilek.
CT Query Point Dotazovací místo systému sledování zásilek.
Časové razítko (Timestamp)
Časové razítko prokazuje nezpochybnitelné datum a čas vzniku elektronického dokumentu. Zaručuje, že konkrétní data v elektronické podobě v daný časový okamžik existovala.
Číslo průvodního dokladu dopravy
(Shipping Manifest Number)
Shipping Manifest je průvodní doklad vydaný dopravcem, který slouží jako kontrolní seznam. Obsahuje soupis nákladních listů pro konkrétní jízdu určitého vozidla, odkud kam zásilka směřuje a po podepsání příjemcem slouží také jako doklad o doručení zásilky.
Datové typy Základní (zabudované v jazyku XML):
- double – 64- bitové číslo s plovoucí řádovou tečkou a dvojnásobnou přesností dle IEEE 754;
- boolean - booleovská hodnota - pouze 0 (pro hodnotu „false“) nebo 1 (pro hodnotu „true“);
- string – textový řetězec;
- celé číslo – int – celé 32 bitové číslo;
- datum a čas – datum a čas podle ISO 8601 (dateTime).
Deaktivace štítku RFID, vyřazení štítku z používání (Tag Decommissioning)
Odstranění (výmaz) dat ze štítku RFID.
Diagram aktivit
(Activity Diagram)
Je jedním z diagramů UML, které popisují chování. Tento diagram se používá pro modelování procedurální logiky, procesů a zachycení pracovního postupu (workflow).
Diagram případu užití
(Use Case Diagram)
Zobrazuje chování systému nebo jeho částí z pohledu uživatele. Je primárně určen k definici chování systému, aniž by odhaloval jeho vnitřní strukturu. (Užití v jazyku UML).
EAN Evropský systém pro číslování zboží. Kód (8 nebo 13 znaků), užívaný pro evropské obchodní položky obsahuje ID země, kontrolní seznam, ID podniku a ID produktu.
EANCOM EANCOM® vznikl a je udržován jako subset (podmnožina) mezinárodní multi-oborové normy pro elektronickou komunikaci UN/EDIFACT (ISO 9735) a je zaměřen na oblast obchodu a distribuce zboží v rámci dodavatelského řetězce.
Fazeta je vlastnost množiny informačních objektů, kterou lze použít k vytvoření přehledu o těchto objektech.
Geografická poloha
(Geolocation)
Identifikace geografického umístění nějakého objektu. Typ identifikace není jednoznačně vymezen – lze např. použít přesnou poštovní adresu, hrubou adresu (např. město a stát nebo kraj, město a stát aj.) nebo jen zeměpisnou délku a šířku určitého místa apod.
Globální lokalizační číslo (Global Location Number)
GLN (globální lokalizační číslo) poskytuje standardní prostředek pro identifikaci (stanovení totožnosti) právnických subjektů, obchodních partnerů a lokalit na podporu požadavků elektronického obchodování. Je administrován organizací GS1.
GLN je 13-ti místné číslo používané pro unikátní (jednoznačnou) identitu všech právnických, funkčních nebo fyzických subjektů. Jeho základní složky jsou:
- GS1 předčíslí organizace,
- odkaz na lokalitu,
- kontrolní číslice.
Poznámka: Ve STANAG, Ed. 3 je místo organizace GS1 uváděna organizace EAN.UCC, jejíž název však byl již v roce 2003 změněn na GS1.
Příklady zúčastněných stran a lokalit, které mohou být identifikovány pomocí GLN:
- funkční subjekty, např. nákupní oddělení v rámci právnické osoby (organizace), účtárna, reklamační oddělení, ošetřovatelská stanice, nemocniční oddělení, číslo zákazníka právnické osoby apod.,
- fyzické subjekty, např. určitá místnost v budově, sklad, brána skladu, nakládací rampa, skříň, policová skříň, místnost v budově, křídlo budovy nemocnice apod.;
- právnické osoby, obchodní partneři, např. kupci, prodejci, celé společnosti, dceřiné společnosti nebo divize, jako dodavatelé, odběratelé, finanční služby, speditéři apod.
GS1 předčíslí organizace
(GS1 Company Prefix, Global Company Prefix)
Zajišťuje globální unikátnost identifikace organizace (firmy, společnosti). Je součástí kódů používaných v logistice (GS1, GLN, SSCC apod). Vzniká kombinací národního předčíslí (prefixu) státu (pro ČR je třímístné předčíslí 859) + smluvně přiděleného identifikačního čísla firmy, jehož délka je odvislá od počtu druhů výrobků, které firma produkuje (číslo firmy může být 4, 5 či 6 místné).
Poznámka: Běžně se používá originální výraz GS1 Company Prefix (nejvhodnější tvar), případně Global Company Prefix bez překladu.
ČOS 990503 3. vydání
14
Pojem Objasnění pojmu
GS1 GS1 je nadnárodní organizace, která je tvořena jednotlivými členskými (většinou národními) organizacemi GS1.
Systém GS1 je globálním standardem pro identifikaci, automatický sběr dat a jejich komunikaci mezi obchodními partnery.
Poznámka: Ve STANAG, Ed. 3 je místo organizace GS1 uváděna organizace EAN.UCC, jejíž název však byl již v roce 2003 změněn na GS1.
GTIN Globální číslo obchodní položky je unikátní identifikátor přidělený organizací položce (nebo skupinám stejných položek) pro použití při sledování této položky.
Identifikace na rádiové frekvenci, RFID
(Radio Frequency Identification)
Radiofrekvenční systém identifikace je moderní technologie identifikace objektů pomocí radiofrekvenčních vln. Umožňuje rychlé a přesné zpracování informací a okamžitý přenos těchto načtených dat k následnému zpracování.
Technologie RFID je v současné době považována za přímého nástupce čárových kódů, z hlediska budoucího vývoje se však nepředpokládá úplné nahrazení čárových kódů. V některých oblastech budou dominovat technologie RFID, jinde najde uplatnění kombinace značení RFID s čárovým kódem. Již dnes se využívají tiskárny, které dokážou potisknout štítek RFID informacemi s čárovým kódem. Takové tiskárny při potisku zároveň zapisují informace na štítek a dokonce pokud je štítek RFID poškozen, toto zjistí a štítek označí.
Instance
(Instance)
Realizace objektu instance. Příklad: Člověk je instancí objektu živočich. Podle potřebné míry rozlišení jsou jinými instancemi objektu živočich např. muž, dítě, Jan Novák apod.
Kód hlášení položky (Reportable Item Code)
Kódovací systém pro hlášení položky je vytvořen pro kategorizaci a identifikaci úkolu kritických položek pro zpravodajské účely NATO. Kódy hlášení položky (RIC) indikují operační schopnosti položky nebo kategorii použití. RIC se skládá ze šesti alfanumerických znaků a sleduje hierarchickou stromovou strukturu; neposkytuje položce unikátní identitu, ale identifikuje její kategorii.
Kritický majetek (Critical Asset)
Majetek, jehož nedostatek či selhání by mohlo způsobit podstatnou ztrátu operační schopnosti pro bojový úkol.
Kvalifikovaná zásilka
(Qualifying Consignment)
Zásilka, která splňuje zadaná kritéria (např. z hlediska velikosti, původu, obsahu).
Log Log je název pro záznam nebo soubor záznamů (často soubory s příponou .log), které si některé programy vytvářejí pro ukládání informací o své činnosti a běhu. Logy slouží při zpětné analýze k rozpoznání, zda došlo k nějaké chybě a pakliže ano, pak
pomáhají určit, k jaké chybě došlo a proč. Mohou také obsahovat informace o tom, jak a kým byla daná aplikace či služba využívána. Logování je uložení dat do souboru k pozdějšímu zpracování.
Majetek (Asset) Jednotky, personál, výbava a materiál.
Model komponent (Component Model)
Datový model komponent poskytuje detailní pohled na různé hardwarové a softwarové komponenty, které tvoří navrhovaný systém. Ukazuje jak umístění těchto komponent, tak jejich vzájemné vztahy s dalšími komponenty. Požadavky na komponentu podrobně uvádějí odpovědnosti, které určitá komponenta má za poskytnutí funkčnosti nebo chování v systému.
Model nasazení (Deployment
Model)
Model systému v jeho fyzickém nasazení (rozvinutí).
Modelování pod-nikových procesů
(Business Process Modeling)
V softwarovém inženýrství označuje modelování či reprezentaci procesů probíhajících v realitě nějakého podniku (v tomto ČOS je ekvivalentem „podniku“ systém GCTC). Model sestává z jednotlivých dílčích procesů (anglicky business process, česky často „business process“ nebo „obchodní proces“).
Toto modelování je nezbytné pro správný návrh systému programátorem. Pro správnou formulaci modelu je nezbytné správné rozpoznání procesů: tedy zejména aktérů, zpracovávaných dat, vztahů k jiným procesům, různých podmínek apod.
Národní kód položky (National Item Code)
Unikátní kód přidělený státem jeho výstroji a výzbroji nebo personálu, aby se snadno odlišili od jiných.
Nesledované události (Non-Tracking Events)
Následující události, které se vztahují k zásilce, se považují za významné, ale nesledované události:
Kategorie událostí A
- generován kód SSCC,
- zásilka spojena,
- zásilka rozdělena,
- připojeno k zásilce,
- odděleno od zásilky.
Kategorie událostí B
- zásilka vytvořena,
- zásilka aktualizována,
- aktualizován obsah zásilky.
Události v kategorii B mají omezený význam – poskytnout audit sledování pro záznam životního cyklu zásilky.
ČOS 990503 3. vydání
16
Pojem Objasnění pojmu
Notifikace (Notification)
Písemné sdělení nějaké skutečnosti. Notifikační (ohlašovací) zpráva zásilky (Consignment Notification Message) ohlašuje existenci zásilky. Zpráva ze sledování zásilky (Consignment Tracking Message) sděluje informace z přepravy zásilky.
Objednatel, zákazník (Customer)
Osoba nebo společnost, která žádá nějaký subjekt o přepravu zboží na svůj účet.
Obsah zásilky (Consignment Content)
Skupina položek asociovaných s danou zásilkou (nebo přepravním balením) úrovně 0. Položky definující obsah zásilky mohou být identifikovány buď jako jednotlivé, nebo agregované entity.
Obsažení vztahu (Includes Relationship)
Vztah mezi dvěma případy užití, v němž jeden případ užití „obsahuje“ chování. Takový vztah se projeví tam, kde existují zvláštní provozní případy užití, které jsou použity z mnoha jiných míst – např. aktualizace dopravního deníku může být součástí mnoha větších provozních procesů.
Ohraničení (Boundary)
Udává hranice systému/subsystému; obecně je to vlastně klasifikátor (systém/subsystém/třída), jehož funkcionalita se popisuje pomocí případu užití.
Operace (Operation)
Operace specifikuje transformaci stavu cílového objektu (a potenciálně stavu zbytku systému dosažitelného z cílového objektu) nebo dotaz (query), který vrací hodnotu volajícímu objektu. Operace specifikuje výsledek chování, nikoliv vlastní chování.
Položka (Item)
Položka je nejnižší identifikovaná součást zásilky úrovně 0. Může být definována buď jako individuální entita (identifikovaná pomocí NIC nebo NSN), nebo jako agregovaná entita ((identifikovaná pomocí RIC).
Poznámka: Je zřejmé, že ani NIC, ani NSN neposkytuje unikátní identifikaci položky; ale pojem "individuální" byl použit, protože to je nejnižší požadovaná úroveň identifikace položek v rámci ICTC.
Přepravní balení (Transport Package)
Přepravní balení sestává z jedné nebo několika položek přepravovaných jako jeden objekt s unikátním identifikátorem, který lze jednoznačně sledovat. Představuje nejnižší nedělitelnou úroveň balení z hlediska přepravy. Jako unikátní identifikátor pro přepravní balení (stejně jako pro zásilku) systém ICTC používá SSCC. Ten může generovat buď NC3A, nebo organizace, která vlastní přepravní balení.
Případ užití; typová činnost; (Use Case)
Případ užití (často se používá originální výraz use case) představuje diskrétní jednotku interakce mezi uživatelem (člověk nebo stroj) a systémem. Případ užití je jednotka jednotlivé smysluplné činnosti; např. vytvoření kolony, úprava kolony nebo vytvoření objednávky – to jsou všechno případy užití. Každý
ČOS 990503 3. vydání
17
Pojem Objasnění pojmu
případ užití má popis funkcí, které se budou vykonávat v navrženém systému. Případ užití může „zahrnovat“ („include“) funkci jiného případu užití nebo „rozšiřovat“ („extend“) jiný případ užití o vlastní chování. Případy užití se typicky vztahují na účastníky (aktéry, actors). Účastník je lidská nebo strojová entita, která vzájemně reaguje se systémem tak, aby se vykonávala smysluplná činnost.
Rozdělení (Deconsolidation)
Operace rozdělení spojené zásilky na složky nižší úrovně (tj. zásilky nebo přepravní balení). Okamžikem rozdělení nastává konec životního cyklu zásilky. Složky nižší úrovně mohou být dodány samostatně nebo mohou být znovu spojeny do jiné spojené zásilky a tak pokračovat v cestě do cílového místa určení.
Rozšíření vztahu (Extends Relationship)
Vztah mezi dvěma případy užití, v němž jeden případ užití „rozšiřuje“ chování druhého. Typickým příkladem je volitelné chování v případu užití scénář – například v určitém bodu provádění agendy scénáře uživatel může volitelně požadovat soupis nebo hlášení.
Sériový kód kontejnerové přepravy (Serial Shipping Container Code - SSCC)
Unikátní identifikace logistických jednotek je dosažena v systému GS1 (dříve EAN.UCC) použitím kódu SSCC. Kód SSCC je datová struktura s 18-ti číslicemi. Unikátnost datové struktury je zajištěna použitím GS1 předčíslí organizace, který dodá UCC nebo jiná členská organizace GS1. GS1 předčíslí organizace v kombinaci se sériovým číslem přiděleným členskou společností působí jako „poznávací značka“ a poskytuje přístup k informacím uloženým v počítačových souborech, které jsou předávány prostřednictvím elektronických obchodních transakcí.
Seznam hlášení položky (Reportable Item List)
Seznam kódů hlášení položky (RIC) je důležitý pro velitele specifické operace. Podřízené jednotky budou podávat hlášení podle kódů RIC v tomto seznamu.
Sledování majetku (Asset Tracking - AST)
Sledování majetku (AST) je prostředek, který poskytuje NATO a členským státům včasné a přesné informace o lokalitě, přesunu, stavu a identitě majetku pomocí sběru, zpracování, uložení a prezentace dat ze sledování majetku (AST).
Sledování zásilky (Consignment
Tracking)
Sledování zásilky je prostředek, který poskytuje NATO a členským státům včasné a přesné informace o lokalitě, přesunu, stavu a identitě zásilek pomocí sběru, zpracování, uložení a prezentace dat ze sledování zásilky.
Spojení (Consolidation)
Operace seskupení zásilek nižší úrovně (včetně zásilek a přepravních balení úrovně 0), které se mohou přepravovat společně, na vyšší úroveň zásilky. Výsledkem této operace je nová zásilka s unikátním identifikátorem zásilky, která je zaslána jako jeden fyzický kus do příští destinace.
ČOS 990503 3. vydání
18
Pojem Objasnění pojmu
Stát specializovaný na vymezenou roli v logistickém zabezpečení (Logistics Role - Specialisation Nation)
Jeden členský stát převezme celkovou odpovědnost za poskytování nebo zprostředkování specifických logistických funkcí nebo služeb pro všechny nebo část mnohonárodních sil ve vymezené zeměpisné oblasti po stanovenou dobu. Kompenzace nebo refundace pak budou předmětem dohody mezi zúčastněnými stranami (MC 319/2).
Subskripce
(subscription)
Pravidelně zasílané informace podle objednávky nebo se souhlasem příjemce. Subskribovat = zavazovat se k něčemu.
Swimlanes, plavecké dráhy, zóny, realizátoři
(Swim lanes)
Části diagramů aktivit znázorňující odpovědnost za jednotlivé části aktivity.
Systém CT NATO (NATO CT System)
Systém, který poskytuje NATO a jeho členským státům včasné a přesné informace o lokalitě, přesunu, stavu a identitě zásilek s využitím dat ze sledování zásilek NATO nebo vnitrostátních zásilek.
Systém sledování majetku
(Asset Tracking
System)
Systém, který poskytuje viditelné a přesné informace o lokalitě, přesunu, stavu a identitě majetku pomocí sběru, zpracování, uložení a prezentace dat ze sledování majetku (AST).
Štítek RFID
(RFID tag)
Podobně jako u čárových kódů se informace zaznamenávají na nosič dat - tzv. štítek RFID (často se používá originální výraz RFID tag), který je připevněn na sledované objekty. Štítek RFID obsahuje malý čip s anténou a pamětí. Štítky RFID jsou základem systému pro ukládání a přenos informací pomocí elektromagnetických vln. Může je hromadně přečíst a zaznamenat příslušné čtecí zařízení, které může být pevné nebo mobilní. Pomocí vln vyzářených z čtecího zařízení dojde k nabití čipu a následně se informace uložená v čipu bezdrátově přenese zpět do čtecího zařízení (každý štítek RFID obsahuje tzv. kód EPC - Electronic Product Code; jedná se o jednoznačné sériové číslo štítku RFID). Z EPC lze odvodit informace o zboží (zásilce) ve formátu XML.
Tag 1. Štítek, visačka, etiketa
2. Zápis elementu XML v lomených závorkách, např. <xs:annotation>
Poznámka: V tomto ČOS se pojem „tag“ používá ve významu ad 2.
ČOS 990503 3. vydání
19
Pojem Objasnění pojmu
Téměř reálný čas (Near Real Time)
Týká se časové přímky s daty nebo informacemi, které se opozdily vlivem času potřebného pro spojení elektronickými prostředky a automatizovaným zpracováním dat. To znamená, že se nejedná o podstatné zpoždění. (AAP-6).
Tok
(Flow)
Tok událostí (v UML) je podrobný postup, jakým je dosaženo hlavního funkčního záměru případu užití.
Třída (Class)
Logická entita (v UML), která zapouzdřuje data a chování. Třída je šablona pro nějaký objekt - třída je forma, objekt je instancí třídy.
Účastník, aktér
(Actor)
V jazyku UML reprezentuje kohokoliv (či cokoliv) mimo systém, kdo se systémem komunikuje a vzájemně reaguje (člověk, HW, čidlo, jiný systém, ...); jediné, co účastník může, je přijímat nebo předávat do systému informace.
Poznámka: Spíše než konkrétního uživatele reprezentuje aktér roli. Jeden konkrétní účastník (člověk, technické zařízení, jiný informační systém, ...) může být vyjádřen i více účastníky (vystupují ve stejné roli) a více různých konkrétních účastníků může být vyjádřeno jedním aktérem (vystupují ve společné roli).
Událost
(Event)
Událost (v UML) - něco, co se stane v určitém časovém okamžiku, nemá trvání. Příklady: událost po uplynutí (stanoveného) času, po splnění podmínky, ve stavu (vstup, výstup).
Události ze sledování (Tracking Events)
Následující události, které se vztahují k zásilce, se považují za události ze sledování:
- odesláno,
- přijato,
- detekováno v lokalitě,
- aktualizován stav.
Následující události, které se vztahují ke štítkům RFID se také mohou považovat za události ze sledování:
- štítek aktivován,
- štítek vyřazen,
poněvadž odkazují na příslušnou zásilku a poskytují informace o času a lokalitě.
Uzel sledování zásilky (Consignment
Tracking Node)
Bod v dodavatelském řetězci nebo v komunikačních linkách, v němž jsou data získána nebo aktualizována.
Validace (Validation)
Ověření platnosti.
ČOS 990503 3. vydání
20
Pojem Objasnění pojmu
Vedoucí stát v logistickém zabezpečení (Logistic Lead Nation)
Členský stát, který převzal celkovou odpovědnost za organizaci a koordinaci dohodnuté šíře spektra logistické podpory pro všechny nebo část mnohonárodních sil, včetně velení, ve vymezené zeměpisné oblasti po stanovenou dobu. Tento LLN může také poskytovat ve stejnou dobu funkce LRSN (MC 319/2).
Vlastnosti
(properties)
Zde vlastnosti datových typů:
- vlastnost lenght (délka): určuje délku příslušného záznamu. Typ jednotky je závislý na příslušném datovém formátu;
- maxLenght (maximální délka): určuje maximální délku příslušného záznamu v použitém formátu (32, 64 bitů, příp. i jiný počet);
- vlastnost pattern: pomocí regulárních výrazů určuje množinu přípustných výrazů, které může záznam obsahovat;
- vlastnost enumeration: výčtový typ. Mohou být použity pouze hodnoty, které jsou předem definovány;
- vlastnost nillable: udává, že element může mít nulovou hodnotu (prázdný řetězec).
Vybavení nezbytné pro plnění úkolu (Mission Essential Equipment)
Vybavení (prostředky), jehož nedostatek by pravděpodobně bránil úspěšnému splnění úkolu velitele.
Výdejní jednotka
(Unit of Issue)
Termín Unit of Issue (zkratka U/I) má původ v USA. Vyjadřuje se dvoupísmenným kódem. Znamená fyzické míry, množství, počet, balení, tvar nějaké položky pro výdej koncovému uživateli. Příklady: AM (ampule), BE (balík), DZ (tucet), SE (sada).
Výměna – informací, dat
(Exchange – information, data)
Výměna (informací, dat) mezi dvěma nebo více subjekty systému pro sledování zásilek.
Zásilka (Consignment)
Zásilka je přepravní jednotka zaslaná od odesílatele k příjemci jako jeden objekt a určená svým unikátním identifikátorem.
V ICTC:
- zásilka má hierarchickou strukturu, v níž zásilky vyšší úrovně (vytvořené spojením zásilek) sestávají z jedné nebo několika zásilek nižší úrovně. Speciálním typem zásilky je zásilka úrovně 0;
- unikátním identifikátorem zásilky je SSCC. Kód SSCC může být generován agenturou NC3A nebo organizací, která zásilku vlastní nebo za ni odpovídá (v případě spojení).
ČOS 990503 3. vydání
21
Pojem Objasnění pojmu
Zásilka úrovně 0 (Level 0 Consignment)
Speciální typ zásilky – viz Přepravní balení.
Zulu Time Koordinovaný světový čas. Je to čas na nultém poledníku v Greenwich.
6 PŘEDMĚT A ÚČEL SYSTÉMU SLEDOVÁNÍ ZÁSILEK NATO
Předmětem systému sledování zásilek NATO (dále také jen systém GCTC) jsou zásilky hmotného charakteru, tj. materiál, který je v přepravitelném stavu. To znamená, že je zabalen nebo uložen v manipulačních jednotkách (na paletách, v kontejnerech apod.) a označen. Doprava zásilek může být zabezpečena vojenskými i civilními dopravními prostředky, včetně přímého dodání výrobcem nebo dodavatelem materiálu.
Účelem sledování je zjištění aktuálních a přesných informací o aktuální lokalitě, pohybu a stavu sledované zásilky v průběhu jejího životního cyklu, tj. od vytvoření zásilky do doručení do cílového místa. Informace se využívají zejména pro odesílatele a příjemce materiálu a také pro velitelské orgány NATO a jeho členských států, pro něž je dodávka sledovaného materiálu důležitá pro plnění jejich úkolů a záměrů.
7 ZÁKLADNÍ CHARAKTERISTIKA NAVRŽENÉHO SYSTÉMU SLEDOVÁNÍ ZÁSILEK NATO
Systém GCTC je navržen pro fungování v mezinárodním prostředí v téměř reálném čase. Komunikace v systému se provádí výhradně elektronicky standardizovanými zprávami, a to buď ve formátu XML, nebo EDI.
Každá sledovaná zásilka má být zavedena do systému GCTC pomocí notifikační zprávy, která obsahuje mj. identifikátor zásilky – rozlišuje se základní a alternativní typ identifikátoru. Po ukončení přepravy musí být zásilka vyřazena ze systému, resp. údaje o ní musí být vymazány. Je-li to účelné, jednotlivé zásilky se mohou v průběhu přepravy libovolně spojovat do větších zásilek a naopak, spojená zásilka se může částečně nebo úplně rozdělit.
Každá sledovaná zásilka musí být označena buď štítkem s čárovým kódem, nebo štítkem RFID (nosičem dat technologie RFID). Údaje o zásilce se snímají automaticky (bez ručního zápisu) skenováním čárového kódu nebo přečtením štítku RFID, a to ručním nebo automatickým čtecím zařízením. Snímané údaje obsahují zejména identifikátor zásilky. Mohou také obsahovat složení zásilky (její jednotlivé položky), ale to není vždy nutné.
Údaje zásilky se snímají v místech jejího naložení a vyložení a na dalších místech vhodně umístěných na trase přepravy (sběrná místa, collect points, přepravní uzly). K sejmutým údajům se připojí další předepsané údaje, jako datum a čas a identifikace lokality (místa, kde proběhla událost). Ručně se připojí, pomocí předepsaných kódů, informace o přepravním stavu (tj. co se děje se zásilkou, zejména z hlediska časového plánu přepravy) a technickém stavu (dobrý stav, poškozená, neúplná) zásilky.
ČOS 990503 3. vydání
22
Údaje ze sledování zásilky se předávají stanoveným účastníkům systému GCTC pomocí výměny standardizovaných zpráv.
Uživatelé systému GCTC kromě toho, že dostávají zprávy ze sledování, se mohou též sami dotazovat na průběh přepravy zásilky.
Do systému GCTC se mohou registrovat další subjekty, tzv. zúčastněné strany (viz příloha F).
Model architektury systému GCTC je představen v příloze A. V příloze B jsou podrobně popsány všechny požadavky na činnost systému. K popisu se používají pojmy a nástroje jazyka UML, a to zejména diagramy případů užití a diagramy aktivit.
Sestavení standardizovaných zpráv ve formátu XML s příklady je obsahem příloh C, D a E. Informace o standardizovaných zprávách EDI jsou uvedeny v příloze F. V příloze G jsou uvedeny základní informace o jazyku XML. Příloha H doplňuje vysvětlení některých použitých pojmů jazyka UML.
Navržený systém GCTC se považuje za funkční, ale připouští se, že bude nutné provést, po zkušenostech s jeho provozem, některé korektury. Zároveň pracovní skupina NATO dále rozvíjí tento systém, zejména z hlediska provázanosti s dalšími platnými STANAG.
8 DŮVODY A PŘEDPOKLADY PRO ZAPOJENÍ ČR DO SYSTÉMU SLEDOVÁNÍ ZÁSILEK NATO
Základní důvody pro zapojení ČR do systému GCTC jsou:
- ČR posílá svou zásilku NATO (např. jednotkám ISAF, kde působí jednotka AČR, ale adresátem mohou být i jednotky jiných států v rámci ISAF) nebo jinému členskému státu NATO,
- přes území ČR nebo území při zahraniční misi, na němž působí jednotka AČR, vede trasa přepravy zásilek z NATO nebo jejího členského státu do ČR nebo do jiného členského státu.
Předpoklady pro zapojení ČR do systému GCTC:
- označení zásilek ČR podle ČOS 990502, 990504 a 814501,
- software pro přenos zpráv ze sledování zásilek, které splňují požadavky tohoto ČOS,
- subskripce příjmu zpráv ze systému GCTC.
Komunikace se systémem GCTC se vede v angličtině.
ČOS 990503 3. vydání
23
PŘÍLOHY
ČOS 990503 3. vydání
24
(VOLNÁ STRANA)
ČOS 990503 3. vydání Příloha A (normativní)
A-1
MODEL ARCHITEKTURY SYSTÉMU SLEDOVÁNÍ ZÁSILEK NATO (NATO CT SAM)
OBSAH PŘÍLOHY A Strana
A.1 ROZSAH ................................................................................................... . A-2 A.1.1 Určení ....................................................................................................... . A-2 A.1.2 Další vývoj ................................................................................................ . A-2 A.1.3 Celková rekapitulace ................................................................................. . A-2 A.1.4 Rekapitulace přílohy A .............................................................................. . A-2
A.2 MODEL ARCHITEKTURY SYSTÉMŮ SLEDOVÁNÍ ZÁSILEK (CT SAM) . A-3 A.2.1 Popis složek architektury .......................................................................... . A-4 A.2.2 Architektura GENISIS ............................................................................... . A-4 A.2.3 Provozní zásady a koncepce .................................................................... . A-6 A.2.4 Procesy a systémy .................................................................................... . A-6 A.2.5 Obecné procesy ........................................................................................ . A-7 A.2.6 Detaily architektury systémů GENISIS ...................................................... . A-8 A.2.7 Provozní režimy ........................................................................................ . A-9
A.3 PROVOZNÍ SCÉNÁŘE ............................................................................. A-13 A.3.1 Pracovní proces ........................................................................................ A-13 A.3.2 Spojování zásilek v článku sledování zásilek (viz obrázek A.4) ................ A-15 A.3.3 Detekce zásilky na sběrném místě sledování zásilek ............................... A-17 A.3.4 Zásilka odeslaná z POE ............................................................................ A-17 A.3.5 Sledování spojené zásilky vnitrostátní a nebo NDSS ............................... A-18 A.3.6 Sledování spojené zásilky ......................................................................... A-20 A.3.7 Popisy ....................................................................................................... A-22
A.5 ANALÝZA NAVRHOVANÉHO SYSTÉMU ................................................ A-24 A.5.1 Shrnutí zlepšení ........................................................................................ A-24 A.5.2 Nevýhody a omezení ................................................................................ A-24 A.5.3 Předpoklady v souvislosti se systémem RFID .......................................... A-24
ČOS 990503 3. vydání Příloha A (normativní)
A-2
A.1 ROZSAH
A.1.1 Určení
Tento dokument popisuje potřeby a očekávání uživatelů od systému schopnosti sledování zásilek GENISIS (GCTC) na zabezpečení požadavků bojeschopnosti NATO. Agentura NATO C3 v současné době připravuje první realizaci systému GCTC. Projekt se nazývá prozatímní schopnosti sledování zásilek (ICTC) pro ISAF. Systém GCTC vyvíjí pobočka vývoje aplikací divize operačního výzkumu agentury NATO C3.
GCTC je nadstavbový prostředek pro provozní oblast služeb logistických funkčních oblastí (LOGFAS). Jeho účelem je umožnit sledování zásilek (CT) ve společném mezinárodním prostředí a spoléhá se jak na vojenské, tak komerční dopravce.
A.1.2 Další vývoj
Podle STANAG 2185, Ed. 3, příloha A, článek 1.1, v současné době systém je systém GENISIS použitelný a určen pro státy, které jej chtějí začít používat pro sledování zásilek. Dále pokračují práce na rozšíření STANAG 2185 v jeho 4. vydání, které bude zahrnovat:
1. Schopnost aktivního sledování a zpracování zpráv ze sledování.
2. Úprava STANAG 2185 a jeho zpráv ve formátu XML pro dosažení souladu s:
a) STANAG 5500 Koncepce systému formátování textových zpráv NATO (CONFORMETS) - ADatP-3 b.
b) STANAG 5524 Standardy a profily interoperability (NISP-ADatP-34),
c) Publikováním zpráv podle STANAG 7149 Katalog zpráv NATO - APP-11.
A.1.3 Celková rekapitulace
Cílem systému GENISIS je poskytnout přehled o zásilkách od okamžiku, kdy stát nebo NATO vytvoří záznam mezistátní zásilky materiálu až do doby, kdy je zásilka vyřazena nebo doručena do místa určení podle objednávky, a to vše v rámci dodavatelského řetězce ISAF. Systém bude vybudován na základě experimentálního prototypu ACT RFID.
A.1.4 Rekapitulace přílohy A
Tato příloha dokumentuje veškeré koncepce, které jsou zpracovávány pro sledování zásilek.
Základem tohoto dokumentu je Model činnosti procesu sledování zásilek NATO AAP- 51, který popisuje koncept sledování zásilek.
V celém dokumentu se GCTC vztahuje na nový prozatímní systém schopnosti sledování zásilek, který se dále rozvíjí.
Kapitola A.1 Obsahuje určení dokumentu a dává celkový přehled o systému GCTC.
Kapitola A.2 Popisuje koncepce pro navrhovaný systém schopnosti sledování zásilek GCTC.
Kapitola A.3 Popisuje zamýšlené provozní scénáře GCTC.
ČOS 990503 3. vydání Příloha A (normativní)
A-3
Kapitola A.4 Shrnuje dopad, který bude mít GCTC v procesu definování řádného pracovního postupu mezi různými plánovacími a logistickými orgány.
Kapitola A.5 Analyzuje navrhovaný modul GCTC.
Na přílohu A navazují:
Příloha B Popisuje Business rules a podrobné požadavky.
Příloha C Popisuje schémata XML potřebná k výměně informací mezi členskými státy a NATO.
A.2 MODEL ARCHITEKTURY SYSTÉMŮ SLEDOVÁNÍ ZÁSILEK (CT SAM)
OBRÁZEK A.1 – Architektura systémů NATO pro sledování zásilek POZNÁMKA Národní server je server členského státu NATO.
NATO
Velitel / štáb
EVE
AMCC
Genisis Obecná architektura sledování zásilek NATO
Národní server
1
Národní server
2
Národní server
n
DVD
Server NATO
Národní server
3
AIT se sběrnými zařízeními
AIT se sběrnými zařízeními
EDEN
Rozhraní a webové služby
Rozhraní a webové služby
ADAMS
ČOS 990503 3. vydání Příloha A (normativní)
A-4
A.2.1 Popis složek architektury
GENISIS
Informační systém s obecným rozhraním (GENISIS). Architektura GENISIS zahrnuje soubor systémů a rozhraní mezi příslušnými systémy poskytujícími optickou kontrolu stavu a aktuální lokality přepravované zásilky v přibližně reálném čase v mezinárodním prostředí. GENISIS je model architektury systémů sledování zásilek NATO (NATO CT SAM).
ADAMS
Spojenecký systém pro řízení přesunů a nasazení (ADAMS). Tato aplikace slouží pro plánování nasazení.
EVE
Realizace účinného zviditelnění (EVE). Jedná se o nový modul LOGFAS pro podporu provádění a monitorování nasazení.
Národní (vnitrostátní) server
Ústřední server každého členského státu NATO pro systém sledování zásilek. Tyto systémy poskytují serveru NATO zprávy ve formátu XML pro aktualizaci stavu zásilek.
DVD
Přímé doručení dodavatelem (DVD). Informační systém obchodní organizace, která dodává zboží přímo v dějišti operace. Tento systém sledování má vždy vazbu na vnitrostátní server. Vnitrostátní server poskytuje nezbytné informace serveru NATO.
Server NATO
Centrální server systému sledování zásilek NATO zajišťuje sledování zásilek pro orgány NATO. Tento server NATO také zastřešuje funkčnost sítě EDEN.
EDEN
EDEN je zkratka sítě pro výměnu elektronických dat. EDEN zastřešuje vše potřebné: rozhraní webových služeb a databázi sledování zásilek NATO.
EDEN poskytuje soubor služeb, které umožňují, aby národní (vnitrostátní) servery byly aktualizovány z jiných národních serverů nebo ze serveru NATO pomocí zpráv ve formátu XML. EDEN také umožňuje vznášení dotazů k zobrazení události, týkající se stavu a lokality přepravované zásilky v přibližně reálném čase v mezinárodním prostředí.
Automatické identifikační nástroje (AIT)
Jakýkoli druh automatického identifikačního nástroje (AIT), používaného ve vnitrostátních systémech sledování zásilek v členských státech NATO. Patří sem čtečky čárových kódů, RFID, (sledovače) GPS atd. A.2.2 Architektura GENISIS
Architektura GENISIS spojuje výsledek modelování v pracovní skupině sledování materiálu s vývojem koncepce definování sledování zásilek a souvisejících dohod STANAG:
ČOS 990503 3. vydání Příloha A (normativní)
A-5
sledování zásilek NATO podle modelu fungování procesu, jaký je (schválený SNLC);
sledování zásilek NATO podle modelu fungování procesu, jaký má být (schválený SNLC);
různé sledování zásilek – podle souvisejících dohod STANAG.
Výsledkem je model architektury systémů sledování zásilek NATO (NATO CT SAM) se zkratkou GENISIS.
GENISIS umožňuje zobrazení zviditelněné události a lokality přepravované zásilky v přibližně reálném čase v mezinárodním prostředí.
Cíle této architektury jsou:
zajistit viditelnost zásilek od místa, kde členský stát nebo NATO zřídí záznam o mezistátní zásilce materiálu do místa, kde je zásilka rozdělena nebo v místě konečného určení převzata podle objednávky;
uskutečňovat sledování zásilek v mezinárodním spojeneckém prostoru, a to jak vojenskou, tak komerční cestou;
poskytnutí podpory pro zaznamenávání stavu a lokalizace zásilek během pohybu od odesílatele k příjemci;
vytvořit nová čísla zásilek (v souladu s dohodami STANAG 2184, 2185, 2494 a 2495) pro zásilky, které dorazily do uzlu sledování zásilek bez dohodnutého formátu dat a symboliky NATO, včetně závažných přepravních údajů (např. čísel sledování komerčního dopravce nebo poškozených štítků NATO) a zaznamenávat vztah mezi formátem čísla, který neodpovídá NATO k novému formátu čísla, který se používá v uzlu sledování zásilek;
zajistit audit sledování zásilek;
zabezpečit příjem a odeslání informací pro každou základní zásilku v rámci spojené zásilky sejmutých (odečtených) jednotlivým prostředkem AIT;
zabezpečit výměnu informací ze sledování zásilky s vnitrostátním informačním systémem řízení zásilek státu, jemuž zásilka patří a jinými systémy, které jsou definovány řídicími procesy;
zajistit schopnost dotazovat se a odpovídat na dotazy o stavu zásilky a vytvořit základní hlášení pro řízení;
realizovat harmonizaci se Službami logistických funkčních oblastí NATO (LOGFAS), včetně Spojeneckého systému pro řízení přesunů a nasazení (ADAMS), Realizace účinného zviditelnění (EVE), Logistických hlášení (LOGREP) tak, aby nenastala duplicita systémů návrhu a provozu.
POZNÁMKA „Viditelnost“ zásilek nebo událostí z jejich sledování se týká příslušných dat; obrazové informace GENISIS neposkytuje.
GENISIS používá koncepci sítě pro výměnu elektronických dat (EDEN). Koncepce EDEN popisuje architekturu zaměřenou na služby, jejímž účelem je výměna informací mezi odlišnými systémy sledování zásilek, které jsou v činnosti v NATO nebo v jeho členských státech. EDEN poskytuje soubor služeb, které akceptují
ČOS 990503 3. vydání Příloha A (normativní)
A-6
zprávy v jazyku XML pro výměnu informací mezi různými systémy sledování zásilek, pokud možno při dodržení STANAG 2494.
A.2.3 Provozní zásady a koncepce
Systém GCTC se bude skládat ze softwaru LOGFAS ve spojení s rozhraními, které mohou sbírat data z RFID, čárových kódů nebo z jiných systémů s technologií sledování zásilek prostřednictvím řady standardních rozhraní. Vzhledem ke své povaze systém sledování zásilek nemá používat obtížné ruční zadávání a sběr dat. Informace o trase budou pocházet z různých externích zdrojů ve formě zpráv ze sledování. Proto systém, prostřednictvím svého webového rozhraní, bude provádět pouze základní ruční operace pro usnadnění aktualizace stavu a spojení zásilky, případně pro její rozdělení. Poskytne však také dobře definovaný dotazový mechanismus pro usnadnění přístupu uživatelů k informacím ze sledování zásilek.
A.2.4 Procesy a systémy
Následuje popis typického použití architektury a systémů.
GENISIS obdrží upřesňující informace o sledovaných zásilkách jedním z následujících způsobů:
z vnitrostátních systémů sledování zásilek (v případě zásilek, u nichž členské státy souhlasily se sdílením informací s NATO nebo které jsou sledovány na serveru NATO);
ze systému NDSS agentury NAMSA (v případě přepravy NATO).
Ve všech těchto případech server NATO na základě získaných informací vytvoří záznam o zásilce, pokud je k dispozici minimum požadovaných informací (identifikace prostřednictvím SSCC nebo státu vlastnícího zásilku). Obdržené informace mohou být buď v minimálním formátu, nebo v podrobném formátu, včetně obsahu zásilky (položky jsou označeny buď jako spojené objekty prostřednictvím RIC, nebo jako jednotlivé objekty prostřednictvím NIC nebo skladových čísel).
Štítky RFID jsou asociovány se zásilkami. V určité chvíli zásilka může nebo nemusí mít odpovídající záznam o zásilce na serveru NATO. V případě potřeby systém vytvoří záznam zásilky a aktualizuje ho informacemi ze štítku RFID.
Účastnické stanice RFID (ruční nebo namontované na rámu) na POE/POD sledují zásilky (tj. zjišťují údaje o zásilkách buď čtením štítků RFID nebo skenováním štítků s čárovými kódy – podle toho, čím je zásilka opatřena) a server RFID odesílá řádně detekované (rozpoznané, sestavené) zprávy XML o zásilce do LOGFAS.
Server NATO ze záznamů rozpozná, o jakou zásilku se jedná a generuje odpovídající informace auditu sledování (lokalitu, čas, typ události, identifikaci štítku, identifikaci sledovacího zařízení) pro sledovanou zásilku a její složky až na nejnižší úroveň zaznamenanou v databázi o sledování zásilek.
Zprávy ze sledování jsou směrovány systémem RFID do státu vlastnícího zásilku, který je rozeznán pomocí směrového kódu obsaženého na štítku RFID.
Lokalita sledování nepřipojená na RFID posílá na server NATO zprávy s hlášením o odeslání, příjmu, aktualizaci stavu, spojení nebo rozdělení zásilky. Server NATO identifikuje záznamy o zásilce, aktualizuje je a vytváří odpovídající informace auditu sledování. Také směruje informace ze sledování zúčastněným stranám. Pověření
ČOS 990503 3. vydání Příloha A (normativní)
A-7
pracovníci se mohou přihlásit do systému sledování zásilek pomocí webového rozhraní a dotazovat se na informace ze sledování. Pravidla prohlížení budou předepsána na základě pověření uživatele (členského státu) a případně podle dalších skupin kritérií. Alternativně systém sledování zásilek může stáhnout potřebné údaje pomocí dotazovacích služeb EDEN.
A.2.5 Obecné procesy
OBRÁZEK A.2 – Obecný přehled procesů
Sběr zpráv ze sledování zásilek - proces zodpovědný za sběr informací ze sledování ze všech podporovaných zdrojů.
Zpracování zpráv ze sledování zásilek - ověření a zpracování veškerých zpráv ze sledování přijatých systémem (s odstraněním chyb). Zpracování zprávy obnáší:
využití zprávy ze sledování – zaznamenání informací o zásilce a kontrola význačných událostí,
vytvoření zprávy ze sledování zásilky - vypracování a dodání zpráv ze sledování zúčastněným (subskribovaným) systémům.
Dotaz ke sledování zásilky – proces, který objasňuje okolnosti zásilky a je založen na stanovených kritériích a načítání souvisejících informací ze sledování.
Umožní se také:
Zprávy ze sledování poslat zúčastněným stranám
CT = sledování zásilky
Článek CT
Systém CT
Uživatel LOGNET
Dotaz na stav sledování
«objekt» Historie zásilky
«výstup»
«výstup»
«výstup»
«výstup»
«výstup»
«získává»
«získává»
«realizuje»
LOGISTICKÁ ZÁKLADNA
«realizuje»
Vytvoření zprávy ze sledování
Využití zprávy ze sledování
Sběr zpráv ze sledování
Zpracování zpráv ze sledování
«objekt» Zásilka
POD
POE
ad Přehled procesů ICTC
ČOS 990503 3. vydání Příloha A (normativní)
A-8
přijímat a zpracovávat informace o obsahu zásilek z automatizovaných informačních vnitrostátních systémů nebo ze systému NATO,
přijímat a zpracovávat rozšířenou sadu zpráv ze sledování zásilek u zásilek označených čárovým kódem, včetně návěští o odeslání, příjmu, aktualizaci stavu, spojení a rozdělení.
Nový server NATO a systém RFID budou kooperativně rozesílat informace ze sledování zásilek zúčastněným stranám (informačnímu systému státu, který je vlastníkem zásilky nebo NATO).
A.2.6 Detaily architektury systémů GENISIS
OBRÁZEK A.3 – Architektura systémů GENISIS
EDEN bude využívat následující rozhraní:
1. Webové rozhraní uživatele (UI) poskytující následující funkce:
hledání zásilky podle různých kritérií a zobrazení výsledků,
zobrazení dat o zásilce, včetně historie a obsahu,
ruční spojení a rozdělení zásilky,
ruční aktualizaci stavu zásilek,
Prohlížeč klienta
Zobrazení údajů o zásilce
Spojení zásilky
Aktualizace zásilky
Zpráva o funkčnosti systému sledování zásilek
1
Systém NATO / národní systém
(dodává do EDEN k zásilkám)
2
NATO / vnitrostátní klient nebo server (uživatel informací ze sledování
ze sítě EDEN) 2
Třetí strana systému sledování (infrastruktura serveru RFID)
(dodává do EDEN s informacemi
ze sledování zásilky) 3
Webové rozhraní
uživatele
Webové služby e-mailové služby
(založené
na XML)
služby sledování
(založené
na XML)
„Business rules“
a služby
Přístup
k datům
Databáze
CT NATO
server EDEN (na internetu)
Architektura systémů GENISIS
ČOS 990503 3. vydání Příloha A (normativní)
A-9
vytvoření různých hlášení.
2. Rozhraní XML (webové a e-mailové služby) s cílem usnadnit interoperabilitu s externími vnitrostátními systémy nebo systémy NATO, uznanými pro dodávání informací o obsahu a sledování zásilky na server NATO a také pro poskytování informací ze sledování. Systémy vlastníka zásilky (vnitrostátní systémy nebo systémy NATO) jsou automaticky informovány prostřednictvím sítě EDEN o sledování jejich zásilek pomocí rozhraní XML (webovými a e-mailovými službami).
3. Rozhraní XML pro příjem informací ze sledování zásilky ze sytému RFID NATO.
Údaje sdělené externími systémy nebo ručně zadané budou zkontrolovány systémem podle pravidel pro sledování zásilek a zaznamenány v databázi NATO (LOGBASE).
A.2.7 Provozní režimy
Systém GCTC má 5 režimů činnosti.
1. Režim sledování, v němž se v systému sledování zásilek aktualizují údaje ze sledovací činnosti (jako zprávy o detekci, aktivaci a vyřazení štítků RFID, skeny čárového kódu, zprávy o odeslání, příjmu, stavu a průběhu dopravy).
2. Režim řízení zásilky zajišťuje základní operace pro vytváření, aktualizaci, spojování a rozdělování zásilek NATO. Režim také umožňuje automatické vytvoření a aktualizaci zásilek NATO v systému GCTC. Tyto operace jsou založeny na oznámení o zásilce (notifikaci) zaslaném v předstihu z vnitrostátních systémů řízení zásilek (v případě vyjmenovaných zásilek nebo zásilek, u nichž se členské státy dohodly, že budou sledovány pomocí systému pro sledování NATO) nebo systémů NATO.
3. Režim dotazování, v němž oprávnění uživatelé a systémy se mohou dotazovat na stav zásilek, které je zajímají.
4. Výměna údajů ze sledování, v níž systém GCTC rozesílá obdržené údaje ze sledování přihlášeným externím informačním systémům, které mají právo na výměnu informací. Omezení přístupu k zásilkám v systému GCTC bude ponecháno na rozhodnutí jednotlivých členských států:
uživateli nebo systému je dovoleno zobrazit a načítat data o zásilce, která podle průvodních dokladů patří jeho státu;
uživatel nebo systém registrovaný ve státu, který provozuje systém GCTC bude mít přístup ke všem zásilkám v systému;
každý uživatel nebo systém může zobrazit a načítat data o zásilkách, jejichž stát - vlastník není znám.
5. Administrativní režim pro správu a údržbu systému.
A.2.7.1 Režim 2 - Řízení zásilek
Systém GCTC umožní základní ruční operace pro zásilky NATO, tj. vytvoření, aktualizaci, spojování a rozdělení. Režim také umožňuje automatické vytvoření a aktualizaci zásilek NATO v systému GCTC. Tyto operace jsou založeny na notifikaci zásilky zaslané v předstihu z:
ČOS 990503 3. vydání Příloha A (normativní)
A-10
vnitrostátních systémů řízení zásilek v případě vyjmenovaných zásilek nebo zásilek, u nichž se členské státy dohodly, že budou sledovány pomocí systému pro sledování zásilek NATO;
jiných systémů NATO (např. z NDSS).
A.2.7.1.1 Vytvoření zásilky
Pro normální funkci systému jsou zapotřebí minimálně následující údaje:
identifikátor zásilky,
stát - vlastník zásilky.
Zásilka NATO může být vytvořena:
identifikátorem zásilky NATO (SSCC), který dodá uživatel systému. Tento identifikátor nesmí být v systému již obsažen;
použitím identifikátoru zásilky NATO (SSCC), který generuje systém (v případě, že identifikátor nedodá uživatel). Systém GCTC bude provádět kontroly unikátnosti (jedinečnosti) SSCC a případného alternativního identifikátoru, pokud je udán.
Je zapotřebí určit stát – vlastníka zásilky v případech, kdy zásilka není opatřena SSCC. Určení státu je nezbytné pro:
jednoznačnou identifikaci zásilky v systému,
zjištění totožnosti zájemce o výměnu dat pro danou zásilku,
stanovení uživatelských práv pro přístup k informacím ze sledování dané zásilky.
Zprávy, v nichž chybí požadované informace, budou odmítnuty jako neplatné (v tomto případě bude třeba ručně odsouhlasit tyto informace).
K zásilce mohou být přidány další nepovinné informace:
alternativní identifikátor zásilky (číslo průvodního dokladu dopravy NDSS, TCN u zásilek USA, identifikátor zasílaného DVD, skladové číslo NATO - NSN);
hmotnost a rozměry;
odesílatel a příjemce;
výchozí a cílová lokalita přepravy zásilky;
přepravní a technický stav;
aktuální poloha;
předpokládaná doba příjezdu.
A.2.7.2 Režim 1 - Sledování zásilek
Systém GCTC musí být schopen přijmout informace ze sledování pocházející z různých zdrojů AIT (čárové kódy, štítky RFID), aby se údaje o zásilce automaticky shromáždily. Všechna data z POD/POE musí být časově udána v koordinovaném světovém času.
ČOS 990503 3. vydání Příloha A (normativní)
A-11
Všechny události týkající se zásilky musí být zaznamenávány a uchovávány po celou dobu života zásilky. Příslušné záznamy budou vytvořeny jak pro sledovanou zásilku, tak i pro každou zásilku obsaženou ve spojené zásilce. Systém GCTC bude pracovat s následujícími scénáři sledování.
A.2.7.2.1 Zásilky opatřené štítkem RFID v lokalitách vybavených technologií RFID
Obsah štítku
Zásilky opatřené štítkem RFID převezmou do svých štítků následující informace (ČOS 990502):
kód SSCC,
kód trasy - obsahuje seznam jednoho nebo více států: státu - vlastníka zásilky, státu - provozovatele systému GCTC (NATO) a dalších států, které mají zájem a oprávnění pro sledování informací týkajících se dané zásilky. NATO bude nastaveno jako oprávněný stát. Formát je stanoven ve STANAG 2233.
Zprávy serveru RFID
Systém GCTC bude očekávat od serveru RFID následující typy zpráv ze sledování:
detekování zásilky (TAG_READ – štítek přečten),
aktivace štítku (TAG_WRITE – štítek napsán),
vyřazení štítku.
Ve všech případech budou zprávy obsahovat identifikaci zásilky NATO (kód SSCC), ID štítku, ID lokality (GLN), ID zařízení, které provedlo identifikaci a datum a čas události.
Kód trasy
Kód trasy používá:
pouze stát - vlastník zásilky – u zásilek NATO nebo vnitrostátních zásilek sledovaných systémem, u nichž není nutné sdílení informací;
stát - vlastník zásilky a NATO – pro vnitrostátní zásilky, u nichž členské státy souhlasily se sdílením informací s NATO.
Server RFID odpovídá za směrování zprávy ze sledování do příslušných států podle kódu trasy.
U zásilek, které se spojují na POE, bude spojování organizovat stát - vlastník nově připojené zásilky; pro všechna následně přijatá data ze spojené zásilky bude systém GCTC generovat kontrolní informace pro původní zásilku a všechny její známé složky. Potom systém GCTC bude vyměňovat příslušná data s každým vlastnickým státem, který je podílníkem spojené zásilky.
Vzhledem k povaze procesu detekce štítků RFID je možné, že systém sledování zásilek přijme současně zprávy o detekci (TAG_READ) jak „obsahujících“ tak „obsažených“ zásilek. Jak již bylo uvedeno, systém GCTC bude automaticky generovat kontrolní informace pro původní zásilku a pro všechny její známé složky.
ČOS 990503 3. vydání Příloha A (normativní)
A-12
Tato kombinace faktorů bude mít za následek dvojí nahrávání a dvojí výměnu údajů o dění v „obsažené“ zásilce z jejího štítku a štítku kontejneru, v němž je obsažena.
A.2.7.2.2 Zásilky opatřené čárovým kódem
Sledování zásilek opatřených čárovým kódem se může provádět na těchto typech stanovišť (lokalit):
stanoviště s RFID, kde lze skenovat čárové kódy;
stanoviště, na nichž se používá místní řídicí informační systém a kde lze pořídit minimální informace o zásilce (ID a lokalitu).
A.2.7.2.3 Zásilky v lokalitách vybavených technologií RFID
Na těchto stanovištích (lokalitách) lze předpokládat, že budou k dispozici minimálně ID zásilky NATO (SSCC), ID stanoviště a datum a čas události. V tomto případě údaje ze sledování budou vždy směrovány do NATO a systém GCTC bude odpovědný za výměnu dat se státem - vlastníkem zásilky. Systém GCTC určí stát - vlastníka z údajů o zásilce zaznamenaných v systému (při normálním pracovním postupu je zásilka již definována v systému GCTC) nebo na základě jeho kódu SSCC.
POZNÁMKA První případ bude fungovat pouze pro čárové kódy SSCC. Jiné čárové kódy na zásilce budou ignorovány.
A.2.7.2.4 Zásilky v lokalitách bez RFID
Sledování zásilek na stanovištích bez RFID využívá místní informační systém řízení schopný poskytnout podrobné informace ze sledování. Předpokladem je, že tato stanoviště budou posílat na GCTC následující zprávy v souladu se STANAG 2185, Ed. 3:
zprávu o odeslání zásilky (avízo odeslání),
potvrzení příjmu zásilky,
zprávu o stavu přepravy.
A.2.7.3 Režim 3 - Dotazy k zásilce
Systém umožní interaktivní i webové dotazování na:
kód SSCC,
alternativní ID zásilky (jako je číslo průvodního dokladu přepravy NDSS, ID zásilky DVD apod.),
lokalitu, kde se zásilka právě nachází,
činnost v daném místě a času,
ID štítku,
stát - vlastník zásilky.
Informace o specifikovaných zásilkách budou navíc omezeny na základě autorizace uživatele systému (například uživatel ze státu, který není členem NATO, by měl mít omezený přístup k zásilkám členských států NATO). Pro dotazy bude použit logický a uživatelsky přívětivý protokol.
ČOS 990503 3. vydání Příloha A (normativní)
A-13
A.2.7.4 Režim 4 - Výměna dat ze sledování zásilek
Systém GCTC musí být schopen si vyměňovat data ze sledování zásilek s příslušnými systémy sledování zásilek, které jsou nakonfigurovány pro výměnu dat. Systém GCTC bude zajišťovat výměnu dat ze sledování zásilky obdržených z jiných zdrojů než státu - vlastníka s informačním systémem státu - vlastníka. Výměna dat může být prováděna různými metodami. Systém GCTC bude předpokládat, že zpráva XML, jejíž obsah je konzistentní se STANAG 2185 – z hlediska dostupné úrovně informací - může být zaslána příslušným systémům sledování zásilek.
A.2.7.5 Režim 5 - Administrace systému GCTC
Správci uživatelů systémů GCTC budou moci provádět následující činnosti pomocí webového rozhraní:
uživatelskou obsluhu,
subskribovanou údržbu,
místní údržbu,
čištění údajů o zásilkách.
A.3 PROVOZNÍ SCÉNÁŘE
Tato kapitola uvádí nejobvyklejší scénáře sledování zásilek.
A.3.1 Pracovní proces
Tato kapitola uvádí nejobvyklejší scénáře sledování zásilek s dosažením interoperability systému GCTC s vnitrostátními systémy a systémem NATO.
Aby scénáře interoperability fungovaly řádně, musí systém GCTC a všechny vnější připojené systémy postupovat následovně:
1. Systém GCTC dovolí systému NATO a vnitrostátním systémům hlásit zásilky a operace s nimi prováděné jedním z následujících způsobů:
pomocí kódu SSCC (preferuje se), nebo
kombinací alternativního ID, typového ID a státu - vlastníka.
Každá zásilka musí být jednoznačně identifikovatelná prvním nebo druhým způsobem.
POZNÁMKA Kromě toho systém GCTC vytvoří jeden referenční ID pro záznam doplňkového vnitrostátního ID nebo ID DVD bez uplatnění požadavku na unikátnost (pouze pro odkaz).
2. Systémy NATO a vnitrostátní systémy, které používají kódy SSCC jako standardní identifikátory zásilek pro vlastní systémy musí dodržovat následující pravidla:
a) Vždy používat kódy SSCC, a to jak ve zprávách ze sledování, tak v notifikačních zprávách.
b) Alternativní ID může být specifikován pouze příslušnými státy pomocí notifikační zprávy zásilky (nikdy ne pomocí zprávy ze sledování). Tím se předchází situacím, kdy notifikační zpráva je opožděna a systém GCTC automaticky generuje kód SSCC agentury NC3A ze zprávy ze sledování
ČOS 990503 3. vydání Příloha A (normativní)
A-14
pomocí alternativního ID, který ještě není systému znám - tyto situace je obtížné napravit.
c) Stát musí zaregistrovat (oznámit) v systému GCTC svá GS1 předčíslí organizací (GS1 Company Prefix), a to ještě před zahájením jakékoliv interoperabilitní činnosti.
Systém GCTC uloží křížové reference na stát a GS1 předčíslí organizací a použije je k dedukci státu, který je vlastníkem zásilky, ve zprávách o dosud neznámých zásilkách v systému GCTC, které obsahují pouze kódy SSCC (bez explicitně stanoveného státu - vlastníka).
3. V případě, že systém NATO nebo vnitrostátní systémy nepoužijí kód SSCC:
V notifikační zprávě zásilky bude uveden pouze alternativní ID (ne kód SSCC).
Pro takové zásilky systém NATO nebo vnitrostátní systémy automaticky vygenerují kód SSCC příslušný NATO.
Zprávy ze sledování zásilky budou obsahovat buď SSCC příslušný NATO, nebo alternativní ID. Tento scénář vede k následujícím konfiguracím identifikátorů zásilek v systému GCTC:
SSCC příslušný NATO,
alternativní ID,
stát vlastnící zásilku, který je uveden v notifikační zprávě zásilky (skutečný stát - vlastník).
Je třeba zdůraznit, že v tomto případě stát odvozený z kódu SSCC by nebyl stejný jako „stát - vlastník“ (je nesoulad mezi státem a kódem SSCC).
4. Kód SSCC příslušný NATO může být automaticky generován pouze systémem GCTC a v žádném případě nějakým externím systémem. V důsledku toho každá zpráva (jak notifikace zásilky, tak zprávy ze sledování zásilky), která používá kód SSCC příslušný NATO, který již neexistuje v systému GCTC bude považována za neplatnou.
5. Stát - vlastník zásilky bude určen a zapsán v systému GCTC na základě následujících pravidel:
a) Když se vytváří nová zásilka v systému GCTC – buď na požadavek (jako důsledek notifikační zprávy zásilky), nebo automaticky (po přijetí zprávy o zásilce, která do systému GCTC ještě není zavedena), pak se stát - vlastník určí:
podle specifikace ve zprávě (pokud je ve zprávě obsažena),
odvozením z udaného kódu SSCC (pokud je to možné – např. podle GS1 globálního předčíslí organizace, je-li registrováno v GCTC); jinak bude zásilka vedena jako patřící „neznámému“ státu s kódem „XX“.
b) Když se aktualizuje zásilka, která je zavedena v systému GCTC na základě své notifikační zprávy:
je-li stát - vlastník uveden ve zprávě, aktualizuje se záznam o něm v GCTC;
ČOS 990503 3. vydání Příloha A (normativní)
A-15
není-li stát - vlastník uveden ve zprávě, záznam o vlastnickém státu v GCTC se nemění.
6. Systém GCTC si bude vyměňovat údaje ze sledování zásilky se státem, který vlastní zásilku. Ten bude pro danou zásilku v GCTC vždy zaznamenán (viz bod 5). Data se budou vyměňovat pouze v případě, když stát - vlastník:
neprovozuje systém GCTC
A
není shodný se státem, který poslal počáteční informace ze sledování (směrovací stát)
A
je znám (není označen „XX“).
7. Spojování zásilek
a) Normální scénář – vnitrostátní systémy nebo systém NATO nejprve vytvoří novou spojenou zásilku ve svém systému a přidělí jí ID. Notifikační zpráva této zásilky se pošle do systému GCTC (podle bodu 2. nebo 3.). Zpráva o spojené zásilce se pošle do GCTC se stejným ID jaký je uveden v notifikační zprávě.
b) Alternativní scénář k odst. a) – zprávě o spojené zásilce nepředchází odpovídající notifikační zpráva zásilky. Vzhledem k tomu, že zpráva o spojené zásilce musí dodržovat pravidla podle bodu 2. nebo 3, nová zásilka bude stále vytvářena automaticky.
c) Další alternativní scénář – ruční postup: NATO nebo vnitrostátní uživatel pomocí webového rozhraní systému GCTC. Jediným důvodem pro tento postup je zaplnit mezeru v případě, když stát v místě, v němž spojuje zásilku, nemá k dispozici vlastní systém. Lze předpokládat, že nová zásilka je ve vlastnictví státu, který vysílá zprávu (uživatelský stát). Spojená zásilka bude mít automaticky generovaný kód SSCC agentury NC3A (může vzniknout nesoulad mezi státem a kódem SSCC). Při dodržování tohoto postupu bude jako stát - vlastník pro nově spojené zásilky zapsán v systému GCTC vždy stát, který provádí spojení.
A.3.2 Spojování zásilek v článku sledování zásilek (viz obrázek A.4)
Tento kombinovaný scénář popisuje proces ručního spojení národní zásilky a zásilky NATO v článku sledování zásilek. Zahrnuje následující dílčí scénáře:
a) Stát informuje NATO o nové zásilce, která bude sledována systémem GCTC NATO.
b) Systém NDSS informuje NATO o nové zásilce, která bude sledována systémem GCTC NATO (Tento scénář předpokládá nespojenou zásilku nebo spojenou zásilku, jejíž složky se nesledují systémem GCTC NATO).
c) V článku sledování zásilek se provádí ruční spojení dvou předtím zaznamenaných zásilek.
d) V článku sledování zásilek se aktivuje štítek RFID nové spojené zásilky.
ČOS 990503 3. vydání Příloha A (normativní)
A-16
OBRÁZEK A.4 – Spojování zásilek v článku sledování zásilek (ICTC považovat za GCTC)
A.3.3 Detekce zásilky na sběrném místě sledování zásilek
Tento scénář představuje normální proces probíhající na POD/POE vybavených systémem RFID. Zahrnuje dva systémy: systém RFID a systém GCTC.
Systém RFID detekuje štítky a vytváří odpovídající zprávy o detekci zásilek v lokalitě a směruje je k příslušnému systému (v tomto případě k systému GCTG, protože se jedná o zásilku NATO).
Systém GCTC přijme zprávu o detekci v lokalitě a zpracuje ji. To znamená, že aktualizuje informace jak pro zásilku jako celek, tak pro její jednotlivé složky (v místě a čase) a zkontroluje provedené operace a výměny informací ze sledování zásilky se zúčastněnými státy.
Tento scénář používá stejné 3 zásilky spojené na předcházejícím stanovišti pro sledování zásilek:
vnitrostátní zásilka C1 s použitím vnitrostátního ID a odpovídající kódu SSCC NATO – kód SSCC1;
zásilka systému NDSS používající kód SSCC NATO – kód SSCC2;
spojená zásilka NATO používající kód SSCC NATO – kód SSCC3.
OBRÁZEK A.5 – Detekce zásilky na POD/POE
A.3.4 Zásilka odeslaná z POE
Tento scénář představuje normální proces probíhající v místě naložení (POE) nevybaveném systémem RFID:
POE provede odeslání (odbavení) zásilky a odešle zprávu o odeslání do systému GCTC;
Sběrné místo dat sledování zásilek (CT Collect Point)
«výstup»
«výstup»
od Detekce zásilek na POD/POE
:Výměna dat z CT se státem
Detekce zásilky
Detekce štítku
Detekována v lokalitě: SSCC3
SSCC1: zásilka
SSCC2: zásilka
SSCC3: zásilka
«Rodič. zás.» detekována
v lokalitě: SSCC2
«Rodič. zás.» detekována
v lokalitě: SSCC1
Systém RFID
GCTC Stát NDSS
«výstup»
ČOS 990503 3. vydání Příloha A (normativní)
A-18
systém GCTC přijme zprávu o odeslání zásilky a zpracuje ji. To znamená, že aktualizuje informace jak pro zásilku jako celek tak pro její jednotlivé složky (v místě a čase) a zkontroluje provedené operace a výměny informací o sledování zásilky se zúčastněnými státy.
Tento scénář používá stejné 3 zásilky spojené na stanovišti pro sledování zásilek:
vnitrostátní zásilka C1 s použitím vnitrostátního ID a odpovídající kódu SSCC NATO - kód SSCC1;
zásilka NDSS používající kód SSCC NATO – kód SSCC2;
spojená zásilka NATO používající kód SSCC NATO – kód SSCC3.
POZNÁMKA Podobný scénář bude platit pro příjem zásilek v místě vyložení (POD). Dotyčné zprávy budou „přijaté“ (místo „odeslaných“).
OBRÁZEK A.6 – Zásilka odeslána z POE
A.3.5 Sledování spojené zásilky vnitrostátní a nebo NDSS
Tento scénář se vztahuje na normální cyklus sledování spojené zásilky, která pochází z vnitrostátního systému anebo ze systému NDSS:
stát - vlastník pošle notifikační zprávy o zásilce pro spojenou zásilku a pro každou její složku;
systém GCTC zaznamená obdržené informace;
systém GCTC přijme zprávu o odeslání spojené zásilky. Zaznamená ji a zašle informaci o přijetí zprávy státu - vlastníkovi zásilky;
sběrné místo systému sledování zásilek detekuje štítek týkající se spojené zásilky a nasměruje zjištěné informace na odpovídající systém (v tomto případě na vnitrostátní systém a nebo NDSS).
POZNÁMKA Odpovídající aktivace štítku pro kód SSCC6 není na obrázku A.7 znázorněna, protože je již uvedena v jiném scénáři.
od Zásilka odeslána z POE
«výstup»
Odeslání zásilky
«výstup»
«výstup»
«Rodič. zás.»
odeslána: SSCC2
«Rodič. zás.»
odeslána: SSCC1
:Výměna dat z CT se státem
Odeslána: zásilka SSCC3
SSCC3: zásilka
SSCC2: zásilka
SSCC1: zásilka
POE: Systém CT
GCTC Stát:
Systém CT
NDSS: Systém CT
ČOS 990503 3. vydání Příloha A (normativní)
A-19
OBRÁZEK A.7 – Sledování národních (NDSS) spojených zásilek
Stát (NDSS) notifikuje (ohlašuje) ICTC jednotlivé a spojené zásilky
Tento scénář se vztahuje na normální cyklus sledování spojené zásilky, jejíž složky vznikly ve vnitrostátním systému nebo v NDSS:
státy - vlastníci zásilek pošlou notifikační zprávy o zásilkách;
systém GCTC přijme zprávu o spojení zásilek;
systém GCTC zaznamená přijatou informaci;
systém GCTC přijme zprávu o odeslání spojené zásilky. Zaznamená ji a vymění si informaci o tom se státem - vlastníkem zásilky. To provede pro každou složku spojené zásilky;
sběrné místo systému sledování zásilek detekuje štítek týkající se spojené zásilky a nasměruje zjištěné informace na odpovídající systém - v tomto případě na systém GCTC. Ten si vymění informace s vlastnickými státy složek spojené zásilky.
POZNÁMKA Odpovídající aktivace štítku pro kód SSCC7 není na obrázku A.8 znázorněna, protože je již uvedena v jiném scénáři.
ČOS 990503 3. vydání Příloha A (normativní)
A-21
OBRÁZEK A.8 – Sledování spojených zásilek pomocí GCTC
Stát (NDSS) notifikuje (ohlašuje) ICTC nové zásilky včetně spojených zásilek
Detekována v lokalitě: SCC4 Detekována v lokalitě: SCC5
SSCC7: zásilka
SSCC4: zásilka
SSCC5: zásilka
«výstup» «výstup
»
«výstup»
:Vytvoření zásilky NATO
ČOS 990503 3. vydání Příloha A (normativní)
A-22
A.3.7 Popisy
A.3.7.1 Vytvoření zásilky NATO
Popis se vztahuje k obrázkům A.4, A.7 a A.8.
Na obrázcích je popsán proces vytvoření jedné zásilky NATO v systému GCTC. To znamená vygenerování nového kódu SSCC, pokud není udán, ale je potřebný, vytvoření záznamu o zásilce a audit události, jakož i výměna dat s příslušnými systémy (např. stát - vlastník potřebuje znát kód SSCC, který byl přiřazen jeho zásilce). Zároveň AIT vytvoří nový záznam (log), který se použije jako vstup buď do procesu aktivace štítku pomocí rozhraní zařízení klienta, nebo v případě potřeby do procesu tisku štítků s čárovým kódem.
A.3.7.2 Štítek zásilky (obrázek A.4)
Proces odpovědný za aktualizaci zásilky a logu AIT informacemi ze štítku.
A.3.7.3 Připojit AIT k zásilce
Připojení (připevnění) štítků k příslušným zásilkám. Tento fyzický proces provádějí pracovníci paletové přepravy zásilek.
A.3.7.4 Aktivovat štítek (obrázek A.4)
Proces prováděný softwarem zákazníka (systém RFID). Jedná se o fyzický záznam informací o zásilce do štítku RFID.
A.3.7.5 Spojení zásilky (obrázky A.7, A.8)
Proces odpovědný za záznam spojení zásilek v systému GCTC.
A.3.7.6 Odeslání zásilky (obrázky A.6, A.8)
Systém GCTC přijme a zpracuje zprávu o odeslání. Výsledkem je aktualizovaný záznam o spojené zásilce a o všech jejích složkách s uvedením lokality (místa), data a času provedení. Stav kořenové zásilky je nastaven na „odeslaná“.
A.3.7.7 Detekce zásilky (obrázky A.5, A.8)
Systém GCTC přijme a zpracuje zprávu o detekci zásilky s kódem SSCC3 v lokalitě. Výsledkem je aktualizovaný záznam o spojené zásilce SSCC3 a a o všech jejích složkách (SSCC1 a SSCC2) s uvedením lokality, data a času provedení.
A.3.7.8 Detekce štítku (obrázek A.5)
Systém RFID detekuje štítek spojený se zásilkou, generuje zprávu o detekci v lokalitě a odešle ji do příslušného systému.
A.3.7.9 Výměna dat ze sledování zásilky se státem (obrázky A.5, A.6, A.7, A.8)
Systém GCTC generuje a vyměňuje informace ze sledování zásilky se zúčastněnými systémy sledování zásilek.
A.3.7.10 Generovat data AIT (obrázek A.4)
Pro zásilky vybrané uživatelem systém GCTC vytváří soubor dat sejmutých pomocí AIT. Soubor je vstupem procesu označení zásilky. Ruční zadávání dat do tohoto bodu procesu je vyloučené.
ČOS 990503 3. vydání Příloha A (normativní)
A-23
A.3.7.11 Generovat záznam AIT (obrázek A.4)
Pro zásilky vybrané uživatelem systém GCTC pořídí záznam s uvedením ID zásilky a ID AIT. Tento záznam pomůže pracovníkům paletové přepravy zásilek zásilky fyzicky opatřit médii AIT.
A.3.7.12 Záznam AIT (obrázek A.4)
A.3.7.13 Zásilka s kódem SSCC1
Záznam o zásilce v systému GCTC vytvořený pomocí generovaného kódu SSCC NATO: SSCC1. Systém GCTC také zaznamená odkaz na udaný vnitrostátní ID (u vnitrostátní zásilky C1). POZNÁMKA Zásilka s kódem SSCC1 je na obrázku A.4 vyjádřena instancí aktivity „SSCC1: zásilka“ – vysvětlení použitých pojmů jazyka UML je uvedeno v příloze B. To platí obdobně také pro následující články.
A.3.7.14 Zásilka s kódem SSCC2
Záznam o zásilce v systému GCTC vytvořený s použitím kódu SSCC NATO: SSCC2, který poskytla agentura NAMSA. Kódem SSCC je zásilka opatřena již před zasláním informace o ní do GCTC.
A.3.7.15 Zásilka s kódem SSCC3
Záznam o zásilce v systému GCTC vytvořený pomocí generovaného kódu SSCC NATO.
A.3.7.16 Zásilka s kódem SSCC4
Záznam o zásilce v systému GCTC vytvořený s použitím poskytnutého kódu SSCC (NAMSA) NATO: SSCC4.
A.3.7.17 Zásilka s kódem SSCC5
Záznam o zásilce v systému GCTC vytvořený pomocí poskytnutého kódu SSCC (NAMSA) NATO: SSCC5.
A.3.7.18 Zásilka s kódem SSCC6
Záznam o zásilce v systému GCTC vytvořený pomocí poskytnutého kódu SSCC (NAMSA) NATO: SSCC6.
A.3.7.18 Zásilka s kódem SSCC7
Záznam o zásilce v systému GCTC vytvořený pomocí generovaného kódu SSCC NATO: SSCC7.
A.4 SOUHRN DŮSLEDKŮ
A.4.1 Provozní důsledky
Jedním z důležitých důsledků systému GCTC bude nutnost vytvoření komunikačního toku dat souvisejících se zásilkami mezi plánovacími orgány dopravy a logistiky v rámci NATO a jednotlivých států a systémem sledování zásilek. To bude přínosem pro správné uplatnění informací ze sledování v aktuálních plánech a poskytne velitelům jednotný přístup k potřebným informacím.
ČOS 990503 3. vydání Příloha A (normativní)
A-24
A.4.2 Organizační důsledky
Systém sledování zásilek může plnit své poslání poskytovat zpětné informace ze sledování příslušným vnitrostátním systémům nebo systému NATO pouze tehdy, když mu tyto systémy dodávají smysluplné (úplné) informacemi o sledovaných zásilkách.
Bude proto důležité koordinovat přístup k podrobným datům o zásilkách buď podporou informačně obsažných štítků zásilek, nebo tím, že státy budou tato data poskytovat přímo systému sledování zásilek NATO. Vzhledem k tomu, že kvalita přijatých informací bude záviset na spolupráci pracovníků v místě operace, může nastat nutnost změnit systém sledování nebo související procesy. To může vyžadovat zpracování srozumitelných postupů a školení pracovníků.
A.4.3 Důsledky v průběhu rozšiřování
Rozšiřování systému GCTC bude muset být postupné. Rozšiřování se musí sladit s vývojem serveru RFID.
A.5 ANALÝZA NAVRHOVANÉHO SYSTÉMU
A.5.1 Shrnutí zlepšení
Systém GCTC bude sledovat zásilky na základě kódů SSCC a bude se opírat o zprávy ve formátu XML ke spuštění záznamu aktualizací stavu zásilky. Obdobné formáty zpráv budou použity pro různá média AIT pro označování zásilek etiketami.
Systém GCTC bude mít možnost podat další informaci o stavu zásilky buď odesláním zpráv zúčastněným stranám (vnitrostátním systémům), nebo odpovědí na dotazy vydané těmito stranami.
Systém GCTC chronologicky zaznamená příslušné kontrolní informace ke sledované zásilce a ke všem jejím známým složkám, umožňující interaktivní i neinteraktivní dotazy ke sledování dat na některé z těchto úrovní. Tímto způsobem lze informace přiřadit zpět na odpovídající úroveň všem zúčastněným (a oprávněným) systémům zapojeným do plánování nebo sledování zásilek.
Data se budou vyměňovat zasíláním zpráv ve formátu XML, které se snadno přizpůsobí různým pracovním postupům a mechanismům výměny.
A.5.2 Nevýhody a omezení
Kvalita informací ze sledování bude závislá na podrobnosti informací o zásilce zadaných do systému.
Různé státy budou využívat ve svých systémech různá technická řešení, což se projeví v mechanismech výměny dat.
A.5.3 Předpoklady v souvislosti se systémem RFID
Jak již v tomto dokumentu bylo uvedeno, systém GCTC má být postaven na základě stávajícího experimentálního prototypu ACT RFID. To implicitně znamená použití technologie RFID, a tím je dáno mnoho závislostí mezi oběma systémy jak po stránce funkční, tak týkající se rozhraní.
Jak už bylo zmíněno dříve, experimentální prototyp ACT RFID měl omezený rozsah. Aby zcela vyhovoval potřebám GCTC podle tohoto dokumentu, je nutná zdokonalená spolupráce mezi oběma programovými vybaveními.
ČOS 990503 3. vydání Příloha A (normativní)
A-25
Druh spolupráce předpokládaný ve STANAG 2185, Ed. 3 je založen na následujících předpokladech týkajících se použité technologie RFID.
A.5.3.1 Identifikace státu - vlastníka pomocí směrových kódů (podle definice ve STANAG 2233)
Stát - vlastník bude určen pomocí směrových kódů zapsaných na štítku RFID:
software infrastruktury serveru RFID musí být schopen přijmout seznam států - vlastníků určených pomocí směrových kódů a náležitě je zapsat na štítek;
infrastruktura serveru RFID odpovídá za nasměrování zpráv TAG_READ, TAG_WRITE, DECOMMISSION zúčastněným stranám, které byly určeny pomocí směrových kódů.
A.5.3.2 Podpora různých AIT (čárové kódy a RFID)
Ruční čtečky RFID mohou číst štítky RFID a snímat čárové kódy. Infrastruktura serveru RFID v obou případech pošle stejnou zprávu TAG_READ (sejmutý čárový kód obsahuje méně informací).
POZNÁMKA Jestliže čárový kód neobsahuje ekvivalent směrového kódu, předpokládá se, že se jedná o zásilku NATO. Když systém GCTC již obsahuje správné informace o zásilce, bude povinností GCTC přesměrovat zprávy ze sledování zúčastněným stranám.
A.5.3.3 Podpora vyřazení štítku z používání
Bez vyřazení (deaktivace) štítku bude zásilka stále existovat a systém sledování zásilek nemůže rozhodnout, kdy byla doručena do místa určení a kdy bylo ukončeno její sledování. Předpokládá se, že systém RFID vydá zprávy o vyřazení štítků v patřičnou dobu.
ČOS 990503 3. vydání
50
(VOLNÁ STRANA)
ČOS 990503 3. vydání Příloha B (normativní)
B-1
MODEL ARCHITEKTURY SYSTÉMU SLEDOVÁNÍ ZÁSILEK NATO (NATO CT SAM) – ZÁSADY A POŽADAVKY
B.4 PŘEDPOKLADY A ZÁVISLOSTI .............................................................. B-31
B.5 POŽADAVKY ............................................................................................ B-33 B.5.1 Požadavky na provoz ................................................................................ B-34 B.5.2 GCTC_BM Business Model Requirement (požadavky na model provozu)
B-35 B.5.3 GCTC_BP_INMSG Incoming Messages (příchozí zprávy) ....................... B-40 B.5.4 Požadavky na případ užití systému GCTC ............................................... B-43
B.6 AKTIVITY SYSTÉMU GCTC .................................................................... B-58 B.6.1 Základní operace se zásilkou ................................................................... B-58 B.6.2 Notifikace zásilky ...................................................................................... B-58 B.6.3 Vytvoření zásilky NATO ............................................................................ B-59 B.6.4 Spojování a rozdělení ............................................................................... B-62 B.6.5 Činnosti při sledování zásilek .................................................................... B-67 B.6.6 Zpracování zpráv ze sledování zásilek ..................................................... B-69 B.6.7 Řízení zásilky ............................................................................................ B-71 B.6.8 Dotaz na data zásilky ................................................................................ B-72 B.6.9 Výměna dat ze sledování zásilky .............................................................. B-73 B.6.10 Administrativní úkoly ................................................................................. B-74 B.6.11 Zpracování příchozích zpráv ..................................................................... B-74 B.6.12 Validace lokalit .......................................................................................... B-75 B.6.13 Validace zásilek potomků ......................................................................... B-76 B.6.14 Validace složek zprávy ............................................................................. B-76 B.6.15 Společné aktivity ....................................................................................... B-76
B.7 LOGICKÝ PŘEHLED SYSTÉMU GCTC ................................................... B-80 B.7.1 Zprávy GCTC ............................................................................................ B-80 B.7.2 Třídy GCTC .............................................................................................. B-83 B.7.3 Podpůrné třídy procesu systému GCTC ................................................... B-84 B.7.4 Doplňkové požadavky na systém GCTC .................................................. B-84 B.7.5 GCTC_REL: Reliability (provozní spolehlivost) ......................................... B-84 B.7.6 GCTC_PERF: Performance (výkon) ......................................................... B-84
ČOS 990503 3. vydání Příloha B (normativní)
B-2
B.7.7 GCTC_SUP: Supportability (možnosti podpory) ....................................... B-84 B.7.8 GCTC_DC: Design Constraints (omezení v návrhu systému) .................. B-84 B.7.9 GCTC_UDH: User Documentation and Online Help (uživatelská dokumentace
a nápověda online) ................................................................................... B-85 B.7.10 GCTC_TRA: Training-related requirements (požadavky na školení) ........ B-85 B.7.11 GCTC_PER: Personnel-related requirements (požadavky na obsluhu) ... B-85 B.7.12 GCTC_CRR: Computer Resource Requirements (požadavky na počítačové
Systém GENISIS pro sledování zásilek (systém GCTC) je doplňkem služeb funkčních oblastí logistiky (LOGFAS). Tato příloha definuje technické podmínky a požadavky na vývoj software systému.
B.1.2 Předmět
Cílem systému GCTC je poskytnout přehled o zásilkách od okamžiku, kdy stát nebo NATO vytvoří záznam mezistátní zásilky materiálu do doby, kdy je zásilka vyřazena nebo doručena do místa určení podle objednávky. Vše probíhá v rámci řetězce zásobování NATO.
Tento dokument dává přehled zjištěných funkčních požadavků.
B.1.3 Odkazy
Procesní model pro sledování zásilek NATO, edice 1.5, Velitelství spojeneckých sil pro transformaci, NC3A, únor 2005.
B.1.4 Celkový přehled
Tento dokument definuje veškeré podrobnosti potřebné pro pochopení celkových požadavků na systém GCTC.
Kapitola B.1 Úvodní kapitola popisuje účel, předmět a přehled přílohy. Kapitola B.2 Popisuje průzkumný model případu užití (use case), který ukazuje
obecné případy užití v diagramu. Kapitola B.3 Popisuje všechny subjekty obsažené v případech užití. Kapitola B.4 Obsahuje specifické požadavky na systém GCTC, které jsou
představeny v podrobných popisech případu užití a v diagramech aktivit.
Kapitola B.5 Specifikuje požadované činnosti systému GCTC.
Kapitola B.6 Uvádí aktivity systému GCTC.
Kapitola B.7 Popisuje logický přehled systému GCTC a stanovuje dodatečné požadavky na GCTC.
B.1.5 Zápis
Unifikovaný modelovací jazyk (UML) je standardní způsob zápisu pro dokumentaci softwarového inženýrství. Aktuální verze UML 2.0 podporuje mnoho typů diagramů na pomoc detailního modelování systémů nebo procesů. V tomto prozatímním systému jsou využity dva základní diagramy: Diagramy případu užití a diagramy aktivit.
POZNÁMKA V příloze H jsou uvedeny některé rozšiřující informace o jazyku UML.
B.1.5.1 Diagramy případu užití
Diagram případu užití zachycuje interakce případu užití (use case) a účastníka (actor). Popisuje funkční požadavky systému, způsob interakce vnějších subjektů (účastníků) na hranici systému a odezvu systému.
ČOS 990503 3. vydání Příloha B (normativní)
B-4
OBRÁZEK B.1 – Zápis případu užití (use case)
B.1.5.2 Diagramy aktivit
Diagramy aktivit slouží k modelování chování systému a způsobu, jak se chování projeví v celkovém chodu systému. Proces probíhá logickými cestami, je založen na různých podmínkách, souběžném zpracování, přístupu k datům, přerušeních a jiných odlišnostech logické cesty. To vše slouží k sestavení procesu, systému nebo postupu. Je možné ukázat aktivity a cestu, po níž by proces mohl probíhat za zmíněných okolností, ale je také možné zobrazit tok informací mezi těmito činnostmi, i když jen v koncepční formě (ne v softwarovém datovém toku).
Použít spojení znamená, že jeden prvek vyžaduje další prvek pro vykonání nějaké interakce. Použitý vztah nespecifikuje, jak je cílový poskytovatel použit, ani zda ho zdrojový klient používá při definici nebo při implementaci. Použitý vztah je subtyp závislosti.
Účastník, aktér
případ užití
Účastník (aktér) je uživatel systému nebo účastník obchodního procesu. "Uživatelem" může být člověk, technické zařízení, nebo dokonce jiný systém. Cokoliv, co komunikuje se systémem zvenčí nebo za ohraničením systému se nazývá účastník. Účastníci (aktéři) jsou typicky spojeni s případy užití.
Obecný účastník
Konkrétní účastník 3
Konkrétní účastník 2
Konkrétní účastník 1
ud Zápis případu užití
Případ užití (use case) je modelovací prvek UML, který popisuje, jak uživatel navrhovaného systému bude působit na systém, aby vykonal diskrétní jednotku práce. Ta je popsána a vyjádřena jednou interakcí za dobu, která je významná pro koncového uživatele (osoba, stroj nebo jiný systém), přičemž se požaduje zanechat systém v kompletním stavu: buď dokončením interakce, nebo
vrácením do původního stavu.
Zobecňování se používá k označení dědič-nosti. Je nakresleno spojení od konkrét-ních účastníků k obecnému účastníkovi, jehož zobecněným důsledkem je, že zdroj zdědí charakteristiky cíle.
ČOS 990503 3. vydání Příloha B (normativní)
B-5
Aktivita organizuje a určuje účast podřízených činností (např. subaktivit nebo akcí) na řízení a datovém toku procesu. Aktivity slouží pro různé modelovací účely – od procesních vývojových aplikací pro návrh systému k modelování business procesů organizačních struktur nebo pracovních postupů.
Počáteční prvek definuje zahájení toku akcí po vyvolání aktivity.
ad Zápis diagramu aktivity
Tento symbol označuje dokončení aktivity. Po dosažení cíle se ukončí všechny akce v diagramu aktivity.
UML zahrnuje dva prvky, které slouží pro modelování událostí. Prvek „příchozí událost“ se znázorňuje obdélníkem s vykrojením na levé straně ve tvaru „V“. Tento prvek označuje událost, jež v systému nastane v důsledku nějakého vnějšího nebo vnitřního podnětu. Obvykle vyvolá další aktivity a procesy.
Aktivita 2
Řídící tok je spojení dvou uzlů v diagramu aktivity. Po ukončení aktivity v uzlu je řídící tok nasměrován k cílovému uzlu. Je-li použit správný symbol aktivity (ovál), očekává se, že tyto aktivity budou nastávat vždy ve stanoveném pořadí.
Tok může mít jméno, které reprezentuje tok fyzického zboží nebo informací v procesu. U jména toku může být malá šipka, která udává směr toku.
úspěch
nezdar
Rozhodnutí
Rozhodnutí je prvek v diagramu aktivity, který označuje bod podmíněného postupu. Je-li určitá podmínka splněna, proces pokračuje jedním směrem, v opačném případě druhým směrem.
Aktivita 1
Informace Aktivita 1
Počátek
Aktivita
Konec
Spuštění události
Příchozí událost
ČOS 990503 3. vydání Příloha B (normativní)
B-6
OBRÁZEK B.2 – Zápis diagramu aktivity
B.1.5.3 Plavecké dráhy
Plavecké dráhy (swim lanes) jsou vertikální nebo horizontální pásma v diagramu, která člení diagram na logické oblasti nebo části. V diagramech aktivit slouží plavecké dráhy k zachycení účastníků, kteří budou hlavními vykonavateli aktivit znázorněných v diagramu. Pokud se aktivita dostane do plavecké dráhy určitého účastníka, je to chápáno tak, že tento účastník je hlavním vykonavatelem dané aktivity. Pokud aktivita zasahuje do více plaveckých drah, odpovědnost za výkon této aktivity sdílejí společně odpovídající účastníci.
Následující diagram ukazuje aktivity seskupené do plaveckých drah reprezentujících účastníky podle toho, kterému účastníku aktivita patří (nebo který účastník má hlavní roli v aktivitě).
:Aktivita 2 :Aktivita 1 Akce 1 :Aktivita 1
„Instance“ aktivity se může použít v diagramu pro zobrazení obecné, standardní aktivity. Když je v diagramu znázorněn tok mezi dvěma instancemi, je tím míněno, že tok se v jiných diagramech (představující procesy) může vyskytnout v jiné formě anebo se vůbec nemusí vyskytnout. Instance aktivit se zobrazují v obdélníku s podtrženým názvem obecné aktivity. Instance také může mít jméno, které se píše podtrženým písmem před dvojtečkou s názvem aktivity.
Prvek „akce“ popisuje základní proces nebo transformaci, která nastává v systému (symbol vlevo). Je to základní funkční jednotka diagramu aktivity. Akce mohou být považovány za potomky aktivit. Akce a aktivity reprezentují procesy, ale aktivity mohou obsahovat násobné kroky nebo rozložitelné procesy, které jsou vyjádřeny akcemi. Akce nemůže být dále dělena nebo rozložena na menší prvky. Akce může být použita také jako instance aktivity (symbol vpravo).
ČOS 990503 3. vydání Příloha B (normativní)
B-7
OBRÁZEK B.3 – Plavecké dráhy (Swim lanes)
B.2 MODEL PŘÍPADU UŽITÍ
Tato kapitola obsahuje přehled o modelu případu užití, který je vhodný pro systém GCTC. Jsou uvedeny pojmy a krátké popisy všech případů užití a účastníků, spolu s příslušnými diagramy a vztahy. V kapitole B.5 týkající se zvláštních požadavků případu užití je část B.5.4 věnovaná zprávám případu užití, které pojednávají podrobněji o podřízených případech užití majících význam pro systém GCTC.
B.2.1 Celkový přehled o sledování zásilky
Obrázek B.4 podává celkový přehled požadavků systému GCTC pro sledování zásilek.
ad Plavecké dráhy
Aktivita 1
Konec
Účastník 1 Účastník 2
Aktivita 2
Aktivita 3
Aktivita 4
Start
ČOS 990503 3. vydání Příloha B (normativní)
B-8
OBRÁZEK B.4 – Celkový přehled sledování zásilek
ud Přehled sledování zásilek
Štítek zásilky
Detekce zásilky
Vyřazení štítku
Výměna dat ze sledování zásilky
Příchozí zprávy procesu
Identifikace smluvní strany
Dotaz na data o zásilce
Rozdělení zásilek
Odeslání zásilky
Příjem zásilky
Aktualizace stavu
zásilky
Hlášení o zásilce
Spojení zásilek
Jednotka CT
Sběrné místo CT
POE
POD
Systém CT
Řízení štítků
Záznam událostí ze sledování
Vytvoření zásilky NATO
Vytvoření instance historie
NATIES
Prohlížení zásilek
Řízení zásilek
Ověřený uživatel
Správce ICTC
Prohlížení štítků
Oprávněný uživatel
Uživatel LOGNET CT
«rozšiřuje»
«vkládá»
«vkládá»
«vkládá»
«vkládá»
«vkládá»
«vkládá»
«vkládá»
«rozšiřuje»
«rozšiřuje»
«rozšiřuje»
«rozšiřuje»
«rozšiřuje»
«rozšiřuje»
«rozšiřuje»
«rozšiřuje»
«rozšiřuje»
«vkládá»
«vkládá»
«vkládá»
«vkládá»
«rozšiřuje»
«vkládá»
«vkládá»
«vkládá»
ČOS 990503 3. vydání Příloha B (normativní)
B-9
B.2.2 Popisy případu užití
B.2.2.1 Správa systému GCTC
Systém GCTC musí poskytnout soubor správních úkolů prostřednictvím webového rozhraní:
uživatelskou údržbu,
subskribovanou údržbu,
údržbu lokality,
vyčištění zásilky (záznamů o ní). Uvedené úkoly mohou vykonávat pouze uživatelé s oprávněním správce.
Označení souborů požadavků (k systému GCTC) - viz kapitola B.5: GCTC_UC_ADMIN_Locations GCTC_UC_ADMIN_Purging GCTC_UC_ADMIN_SUB_Interface GCTC_UC_ADMIN_Users GCTC_UC_AUT_AdminUser
B.2.2.2 Ověřený uživatel
Systém GCTC bude provádět ověření uživatele podle ID a hesla.
Označení souborů požadavků (k systému GCTC) - viz kapitola B.5: GCTC_SR_LOGIN
B.2.2.3 Oprávněný uživatel
Oprávnění k uživatelskému přístupu k datům ze sledování zásilek bude omezeno na uživatele s pověřením podle státu a druhu uděleného oprávnění (oprávnění správce, oprávnění na prohlížení vs. oprávnění k provádění úprav).
Označení souborů požadavků (k systému GCTC) - viz kapitola B.5: ICT_BM_Consignment_OwnerNation GCTC_BM_Authorization GCTC_SR_AUTHORIZATION GCTC_UC_ADMIN_AuthorizedUsers GCTC_UC_AUT_AdminUser GCTC_UC_AUT_GCTCUser GCTC_UC_AUT_NationalUser GCTC_UC_AUT_Privileges
B.2.2.4 Notifikace (hlášení) zásilky
V tomto procesu se zpracovávají notifikační zprávy zásilek v systému GCTC. Proces zahrnuje vytvoření nové zásilky NATO (když dosud neexistuje) nebo aktualizaci již existující zásilky, nahrávání všech poskytovaných informací (informace o hmotnostních, rozměrových a jiných parametrech fyzikální povahy a/nebo o obsahu zásilky) a vhodný záznam události.
Tento tok se spustí, když systém přijme notifikační zprávu zásilky a stane se způsobilým k následným procesům.
Označení souborů požadavků (k systému GCTC) - viz kapitola B.5: GCTC_UC_HST_ContentRecorded
Pokud je zásilka v systému již zaznamenaná, zahájí se následující činnosti:
aktualizace dané zásilky – informace fyzikální povahy, obsah zásilky;
záznam událostí jako ConsignmentContentUpdated (aktualizovaný obsah zásilky) nebo ConsignmentUpdated (aktualizovaná zásilka), vyhodnocených v tomto pořadí.
B.2.2.4.3 Osudná chyba {alternativní cesta}
V notifikační zprávě zásilky mohou nastat následující výjimky: 1. Jsou stanoveny oba typy identifikátorů (kód SSCC a alternativní ID), avšak
v zaznamenané zásilce je rozpor (např. např. zásilka je identifikována podle jednoho ID a druhý ID nesouhlasí).
2. Je udán obsah existující spojené zásilky. 3. Neplatný kód SSCC (kód SSCC zásilky odpovídá systému GCTC nebo
neregistrovanému vnitrostátnímu systému). Ve všech případech bude příslušná chyba ve zprávě zaznamenána a proces selže.
B.2.2.5 Spojení zásilek
Představuje proces spojení dvou nebo více zásilek do jedné (spojené) zásilky vyšší úrovně. Normální tok procesu bude využívat:
ČOS 990503 3. vydání Příloha B (normativní)
B-11
pro rodičovskou zásilku – vytvoření zásilky NATO (pokud není vytvořena v předstihu) a vytváření instance historie (s odpovídajícím kódem události Consolidated - spojeno);
pro zásilky potomků – vytvoření zásilky NATO (pokud ještě neexistuje), připojené k rodičovské (spojené) zásilce a vytvoření instance historie (s kódem události AttachedToConsignment – připojeno k zásilce).
V případě potřeby systém GCTC vymění data se zúčastněnými vlastnickými státy zásilek. Tento tok se spustí, když systém přijme zprávu o spojení zásilek a ta je použitelná pro procesy. Předpoklady:
ID rodičovské zásilky,
seznam ID zásilek, které byly spojeny (potomků).
Označení souborů požadavků (k systému GCTC) - viz kapitola B.5: GCTC_BM_ConsignmentDefinition GCTC_BM_ConsolidatedConsignment GCTC_BP_INMSG_CONS GCTC_UC_CH_New GCTC_UC_CH_RecordEvent. GCTC_UC_COC GCTC_UC_COC_AbnormalSituations GCTC_UC_COC_AssociateChild GCTC_UC_COC_LevelUncertain. GCTC_UC_COC_UnspecifiedChildren GCTC_UC_CON_CreateModes GCTC_UC_HST_Attached. GCTC_UC_HST_Consolidated
B.2.2.5.1 Spojení {základní cesta}
Postup:
vytvoření zásilek NATO pro kořenovou (základní) zásilku a zásilky potomků, pokud ještě neexistují;
provedení spojení zásilek, označení kořenové zásilky jako zásilky, která nemá úroveň 0;
záznam události spojení (Consolidation) pro rodičovskou zásilku a událost připojení k zásilce (AttachedToConsignment) pro každou zúčastněnou zásilku potomků;
výměna dat se státy - vlastníky rodičovských zásilek i zásilek potomků.
B.2.2.5.2 Osudná chyba {alternativní cesta}
Jestliže kořenová zásilka má úroveň 0, proces selže a bude zaznamenána chyba.
B.2.2.5.3 Opravitelná chyba {alternativní cesta}
Viz řešení výjimek při spojování a rozdělování zásilek.
B.2.2.6 Ruční spojení
Ruční spojení pomocí webového uživatelského rozhraní. Validační pravidla použitelná pro tento případ jsou uvedena v požadavcích:
ČOS 990503 3. vydání Příloha B (normativní)
B-12
Označení souborů požadavků (k systému GCTC) - viz kapitola B.5: GCTC_UC_AUDT_Operations GCTC_UC_CON_CreateModes GCTC_UC_MAN_COC GCTC_UC_MAN_COC_Rules
B.2.2.7 Vytvoření záznamu o zásilce s unikátním ID
Systém GCTC vytvoří záznam o nové zásilce opatřené unikátním (jedinečným) identifikátorem, kterým může být jedna z možností:
kód SSCC;
kombinace unikátního alternativního ID, typu alternativního ID, státu - vlastníka;
obě výše uvedené možnosti.
Nová zásilka může být vytvořena:
s minimálním souborem poskytnutých informací (kód SSCC, stát - vlastník);
s detailním souborem informací o zásilce fyzikální povahy (stav, hmotnost, vnější rozměry, objem, odesílatel, termíny apod.).
Ve výchozím nastavení bude nově vytvořená zásilka považována za zásilku úrovně 0.
POZNÁMKA Hierarchie zásilek, které tvoří spojenou zásilku a jejich obsah (materiálové položky) nejsou součástí odpovědností tohoto procesu.
Označení souborů požadavků (k systému GCTC) – viz kapitola B.5:
GCTC_BM_Consignment_NATOIdentifier
B.2.2.8 Vytvoření instance historie
Systém GCTC musí zaznamenat všechny události, které jsou důležité pro zásilku během jejího životního cyklu. Zaznamenávají se následující události shrnuté v tabulce B.1.
Tabulka B.1 – Záznam událostí týkajících se zásilky
Zkratka Popis události
CD Zásilka je odeslána
CR Zásilka je přijata
CL Zásilka je detekována v lokalitě (v místě na trase zásilky)
CS Ohlášená změna stavu zásilky
CM Ruční změna stavu zásilky
TC Štítek uveden do používání (aktivován)
TD Štítek vyřazen z používání (vyřazen)
CO Zásilka byla spojena
DE Zásilka byla rozdělena
AC Připojeno k zásilce
DE Odpojeno od zásilky
CN Zásilka byla vytvořena
CG Byl vygenerován kód SSCC
CC Byl zaznamenán obsah zásilky
ČOS 990503 3. vydání Příloha B (normativní)
B-13
Zkratka Popis události
CU Zásilka byla aktualizována (resp. záznamy o ní)
PR Rodičovská zásilka byla odeslána
PL Rodičovská zásilka byla detekována v lokalitě
PM Ruční změna stavu rodičovské zásilky
PS Ohlášená aktualizace stavu rodičovské zásilky
Označení souborů požadavků (k systému GCTC) – viz kapitola B.5: GCTC_UC_HST_ConStatusUpdated GCTC_UC_HST_ContentRecorded. GCTC_UC_HST_ConUpdated ICT_BM_ConsignmentData_Visibility GCTC_BM_ConsignmentData_Availability GCTC_BM_CT_Consignment_Location GCTC_BM_CT_Consignment_Status GCTC_BM_RecordAuditTrail GCTC_UC_HST_Attached GCTC_UC_HST_ConCreated GCTC_UC_HST_Consolidated GCTC_UC_HST_DeConsolidated GCTC_UC_HST_Detached GCTC_UC_HST_SSCCGen. GCTC_UC_HST_TrackingEvent GCTC_UC_LOC_Tracking
B.2.2.9 Vytvoření zásilky NATO
Představuje proces vytvoření jedné zásilky NATO v systému GCTC. To znamená vygenerování nového kódu SSCC, pokud není dosud poskytnut, vytvoření záznamu o zásilce, zaznamenání této události a výměna dat s příslušnými systémy (např. stát - vlastník potřebuje znát, jaký kód SSCC byl přidělen jeho zásilce).
Tento tok může být spuštěn:
explicitně vnitrostátním systémem CT, přičemž existující zásilka ve výchozím (vnitrostátním) systému musí být známa systému GCTC NATO (z notifikace zásilky),
implicitně zprávou ze sledování, spojení nebo rozpojení zásilky, když zásilka(-y) ještě není známa systému GCTC.
Zásilka může být vytvořena jedním z následujících způsobů:
použitím poskytnutého národního kódu SSCC (jiného než je kód SSCC NATO),
použitím nově vygenerovaného kódu SSCC NATO (pokud má zásilka zatím pouze unikátní vnitrostátní ID).
Označení souborů požadavků (k systému GCTC) – viz kapitola B.5: ICT_BM_Consignment_OwnerNation GCTC_BM_Consignment_NATOIdentifier GCTC_BM_Consignment_XRef_DVD GCTC_BM_Consignment_XRef_NonNatoIdentifier GCTC_BM_ConsignmentDefinition GCTC_BP_ConsignmentIdentification
B.2.2.9.1 Příchozí zásilka s platným kódem SSCC (nejedná se o kód SSCC NATO) {základní cesta}
Vytvořit záznam zásilky s unikátním ID s využitím přiděleného kódu SSCC (jako platného ID zásilky NATO). Vytvořit instanci historie (typ události = Consignment Created - vytvořená zásilka).
B.2.2.9.2 Příchozí zásilka s alternativním ID {alternativní cesta}
Vygenerovat jedinečný kód SSCC NATO. Vytvořit záznam zásilky s jedinečným ID s využitím nově vygenerovaného kódu SSCC. Vytvořit instanci historie (typ události = SSCCGenerated - vygenerovaný SSCC). Vyměnit (zasláním) CT data pro nový kód SSCC.
B.2.2.9.3 Příchozí zásilka s kódem SSCC NATO {alternativní cesta}
To se bude považovat za chybu, protože kód SSCC NATO může být generován pouze automaticky. Chyba bude zaznamenána a proces selže
B.2.2.10 Vyřazení štítku z používání
Tento proces se v systému GCTC spustí, až událost „Tag Decommission“ (vyřazení štítku) přijatá ze serveru RFID bude k dispozici pro proces. Tok procesu zahrnuje aktualizaci záznamu zásilky (vynulování nejen identifikačních údajů, ale také nastavení aktuální lokality na trase zásilky, data a času poslední události), vytvoření instance historie (událost = Tag Decommissioned - štítek vyřazen z používání) a výměnu dat ze sledování zásilky.
POZNÁMKA Jestliže ID zásilky již není systému CT znám, odpovídající záznam zásilky bude přesto vytvořen pro kontrolní účely.
Označení souborů požadavků (k systému GCTC) – viz kapitola B.5: GCTC_BM_ConsignmentData_TrackingInfo GCTC_BM_CTDataSource_SimpleDetectMessage GCTC_UC_CON_CreateModes GCTC_UC_HST_TrackingEvent
B.2.2.11 Rozdělení zásilek
Tento proces se spustí u spojené zásilky a zahrnuje oddělení jednotlivých zásilek, z nichž každá pak může být odeslána na jinou trasu, v jiný čas nebo jiným způsobem přepravy. Spojená zásilka může být rozdělena úplně nebo částečně.
Označení souborů požadavků (k systému GCTC) – viz kapitola B.5: GCTC_BM_ConsignmentDefinition GCTC_BM_ConsolidatedConsignment GCTC_BP_INMSG_DECONS GCTC_UC_CH_New GCTC_UC_CH_RecordEvent
Proces probíhá až do doby, kdy již není k dispozici žádná zásilka potomků. Tok procesu bude využívat:
odpojení každé zásilky potomků,
vytvoření instance historie jak pro zásilky, které se spojily, tak pro spojenou zásilku (odpovídající události jsou DetachedFromConsignment/Deconsolidated - odpojeno od zásilky a rozdělená zásilka),
výměna dat ze sledování zásilky se státem – vlastníkem jak pro rodičovské zásilky, tak pro zásilky potomků,
nastavení stavu pro rozdělenou zásilku na „Closed“ (uzavřeno).
B.2.2.11.2 Částečné rozdělení {základní cesta}
Proces se spustí, když je k dispozici seznam zásilek potomků pro oddělení. Tok procesu bude využívat:
vytvoření zásilky NATO (pokud ještě neexistuje) pro rodičovskou a každou zásilku potomků uvedenou v seznamu pro oddělení,
vytvoření instance historie jak pro spojující, tak pro spojené zásilky (odpovídající události jsou DetachedFromConsignment/Deconsolidated - odpojeno od zásilky a rozdělená zásilka),
výměna dat ze sledování zásilky se státem – vlastníkem jak pro rodičovské zásilky, tak pro zásilky potomků.
B.2.2.11.3 Opravitelná chyba {alternativní cesta}
Viz řešení výjimek při spojování a rozdělování zásilek.
B.2.2.11.4 Osudná chyba {alternativní cesta}
Jestliže kořenová zásilka má úroveň 0, proces selže a bude zaznamenána chyba.
B.2.2.12 Ruční rozdělení
Ruční rozdělení zásilky pomocí webového rozhraní. Validační pravidla jsou obsažena v následujících souborech požadavků.
Označení souborů požadavků (k systému GCTC) – viz kapitola B.5: GCTC_UC_AUDT_Operations GCTC_UC_MAN_DEC GCTC_UC_MAN_DEC_Rules
B.2.2.13 Odeslání zásilky
Tento tok procesu se spustí poté, co POD systému CT pošle zprávu o odeslání zásilky do systému GCTC, ten zprávu přijme, a tím ji dá k dispozici pro proces.
ČOS 990503 3. vydání Příloha B (normativní)
B-16
Informace o zásilce jsou aktualizovány obdobným způsobem (aktuální lokalita, ETA apod.), je vytvořen audit sledování pro zásilku a její složky (budou použity kódy událostí Despatched (odesláno), resp. ParentDespatched (rodičovská zásilka odeslána)) a jsou vyměněna data se zúčastněnými stranami.
Označení souborů požadavků (k systému GCTC) – viz kapitola B.5: GCTC_BM_ConsignmentData_TrackingInfo GCTC_BM_CTDataSource_DetailedTrackingMessage GCTC_UC_CON_CreateModes GCTC_UC_HST_TrackingEvent.
B.2.2.13.1 Odeslání zásilky, která existuje v GCTC {základní cesta}
Normální tok předpokládá, že zásilka NATO již existuje v systému CT. Pro danou zásilku a její složky je třeba:
aktualizovat záznam o zásilce (aktuální lokalita atd.),
vytvořit instanci historie zásilky (událost = Despatched (odesláno), resp. ParentDespatched (rodičovská zásilka odeslána)),
výměna informací ze sledování zásilky se státem - vlastníkem (je-li požadována).
B.2.2.13.2 Odeslání zásilky, která neexistuje v GCTC {alternativní cesta}
Vytvořit zásilku NATO a potom postupovat po základní cestě.
B.2.2.14 Detekce zásilky
Tento tok procesu se spustí poté, co systém GCTC přijme zprávu ze sledování DetectedAtLocation (detekováno v místě), čímž ji dá k dispozici pro proces. Systém CT může poslat zprávu o detekci zásilky v lokalitě v jednom z následujících případů:
systém RFID detekuje štítek,
na místě je sejmut čárový kód.
Odezva systému GCTC na tento podnět bude zahrnovat:
aktualizaci informací o zásilce (aktuální lokalita) pro kořenové a na nich závislé zásilky,
záznam události pro danou zásilku a zásilky na ní závislé (typ události = DetectedAtLocation (detekováno v místě), resp. ParentDetectedAtLocation (rodičovská zásilka detekovaná v místě)),
výměna informací ze sledování zásilek se státy - vlastníky dané zásilky a zásilek na ní závislých.
POZNÁMKA Zprávy RFID by měly mít vždy ID původu dat ze sledování. Ty mohou být sděleny čtením štítků RFID nebo skeny čárových kódů, což znamená, že AIT je volitelné.
Pravidla procesu
Odfiltrovány budou po sobě jdoucí zprávy RFID o detekci stejné sledované entity vyslané ze stejné lokality (která je identifikována jako ID lokality + ID zdroje sledování). To znamená, že první událost tohoto typu bude zaznamenána do historie, jakékoli další zprávy tohoto typu budou zaznamenány při aktualizaci. Tímto způsobem budou uloženy v historii pouze první a poslední zpráva tohoto typu.
"Stejná sledovaná entita" se určí na základě:
ČOS 990503 3. vydání Příloha B (normativní)
B-17
Identifikace zásilky + ID AIT + CurrentLocation (aktuální lokalita) + ID konkrétního zařízení. Označení souborů požadavků (k systému GCTC) – viz kapitola B.5: GCTC_BM_ConsignmentData_TrackingInfo GCTC_BM_CTDataSource_SimpleDetectMessage GCTC_UC_CON_CreateModes GCTC_UC_HST_TrackingEvent
B.2.2.14.1 Detekovaná zásilka v GCTC existuje {základní cesta}
Normální tok předpokládá, že v systému GCTC již existuje záznam o zásilce NATO:
aktualizace záznamu o zásilce,
vytvoření instance historie pro danou zásilku a zásilky na ní závislé (typ události = DetectedAtLocation (detekováno v místě), resp. ParentDetectedAtLocation (rodičovská zásilka detekovaná v místě)),
výměna informací ze sledování zásilek se státy - vlastníky dané zásilky a zásilek na ní závislých.
B.2.2.14.2 Detekovaná zásilka v GCTC neexistuje {alternativní cesta}
Vytvořit záznam o zásilce s unikátním ID, vytvořit instanci historie (typ události = DetectedAtLocation (detekováno v lokalitě)) a aktualizovat log AIT.
B.2.2.15 Výměna dat ze sledování zásilek
Vyměňují se data ze sledování zásilek s příslušnými externími systémy: státy, vnitrostátními systémy (podskupina státu) a externími informačními systémy. Systémy příslušné pro každou událost budou určeny podle události a státu – vlastníka zásilky s použitím předtím nastavené subskripce dat. Výměna dat bude prováděna způsobem, který je stanoven v subskripci (zprávami ve formátu XML, e-mailem, webovými službami). Obsah dat musí odpovídat STANAG 2185.
Výměna informací o událostech u sledované zásilky bude znamenat výměnu informací o:
spuštění události pro danou zásilku,
spuštění události jako „předávané“ události pro každou závislou zásilku (Poznámka: Jedná se o „předávanou“ událost, protože není přímo spuštěna pro tyto zásilky, ale je vyvolána na základě složení zásilky).
Seznam událostí při sledování, které vyžadují předávání:
detekce v lokalitě,
odesláno,
přijato,
hlášená změna stavu,
ruční změna stavu.
Vyměňovaná zpráva pro předávané události (výstup) bude podobná zprávě o spuštění události (vstup), ale zaznamená jak ID dotyčné zásilky, tak ID zásilky, která spustila událost (jako „událost hlášená pro“).
Nepředávané události:
štítek aktivován,
ČOS 990503 3. vydání Příloha B (normativní)
B-18
štítek vyřazen.
Označení souborů požadavků (k systému GCTC) – viz kapitola B.5: GCTC_BM_ExchangeCTData GCTC_UC_LOC_PresentationMsg
B.2.2.16 Výměna dat ze sledování zásilek se státem
Systém GCTC bude provádět výměnu veškerých údajů ze sledování, které přijme pro zásilku z jiných zdrojů než ze státu - vlastníka s informačním systémem státu - vlastníka.
Jak požadavek na provedení výměny, tak prostředky této výměny budou stanoveny na základě nastavení subskripce pro daný vnitrostátní systém, stát, operační kód a událost.
Výměna dat se požaduje, je-li systém vlastníka zásilky jiný než systém GCTC (který je založen na kódu SSCC) A:
systém vlastníka zásilky (je určen na základě kódu SSCC – GS1 předčíslí organizace) je subskribován k dané události (subskripce pro přesný operační kód a žádný operační kód bude vyhodnocena v tomto pořadí) NEBO
stát - vlastník zásilky je rozdílný od zpravodajského státu a je subskribován k dané události (subskripce pro přesný operační kód a žádný operační kód bude vyhodnocena v tomto pořadí).
Označení souborů požadavků (k systému GCTC) – viz kapitola B.5: ICT_BM_Consignment_OwnerNation GCTC_BM_ExchangeData_Nations GCTC_UC_LOC_PresentationMsg GCTC_UC_XCHG_Consolidation GCTC_UC_XCHG_Deconsolidation GCTC_UC_XCHG_ExchangeScenarios GCTC_UC_XCHG_Rules GCTC_UC_XCHG_NewSSCC GCTC_UC_XCHG_Subscription GCTC_UC_XCHG_Tracking
B.2.2.17 Výměna dat ze sledování zásilek se subskribovanými IS
Systém GCTC bude vyměňovat data ze sledování zásilky s informačními systémy (jinými než vnitrostátní systémy sledování zásilek), které mají subskribovanou výměnu.
Označení souborů požadavků (k systému GCTC) – viz kapitola B.5: GCTC_BM_CT_ZULUTIME GCTC_BM_ExchangeData_IS GCTC_UC_LOC_PresentationMsg
B.2.2.18 Generování informací AIT
Systém GCTC se schopností vytvářet informace „zápisem“ na média AIT bude u vybraných zásilek svým uživatelům poskytovat:
uživatelské vyhledávání požadovaných zásilek (seznam dostupných zásilek bude předfiltrován na základě podmínky "není přiřazen žádný ID AIT"),
ČOS 990503 3. vydání Příloha B (normativní)
B-19
uživatelský výběr požadovaných zásilek (jedné nebo více),
uživatelské požadavky na generování údajů AIT.
Označení souborů požadavků (k systému GCTC) – viz kapitola B.5: GCTC_UC_MAN_AITGenerate
B.2.2.19 Generování unikátního ID zásilky NATO
Schválený ID pro zásilky NATO je kód SSCC (s použitím přiděleného GS1 předčíslí organizace).
Označení souborů požadavků (k systému GCTC) – viz kapitola B.5: GCTC_UC_CON_GenerateSSCC
B.2.2.20 Údržba subskripcí
Uživatel s oprávněním správce může definovat (vytvořit, aktualizovat, vymazat) subskripce pro státy, vnitrostátní systém a informační systémy na soubor událostí v systému GCTC. Subskripce mohou být definovány buď celkově, nebo na úrovni operačního kódu.
Označení souborů požadavků (k systému GCTC) – viz kapitola B.5: ICT_BM_Consignment_OwnerNation GCTC_UC_ADMIN_SUB_Contact GCTC_UC_ADMIN_SUB_Entities GCTC_UC_ADMIN_SUB_Events GCTC_UC_ADMIN_SUB_Interface GCTC_UC_AUDT_Operations GCTC_UC_XCHG_Subscription
B.2.2.21 Údržba uživatelů
Uživatel s oprávněním správce může vytvořit, aktualizovat, vymazat všechny typy uživatelů systému GCTC.
Označení souborů požadavků (k systému GCTC) – viz kapitola B.5: GCTC_UC_ADMIN_Users GCTC_UC_AUDT_Operations
B.2.2.22 Správa zásilek
Proces zodpovědný za ruční operace se zásilkami může být spuštěn uživatelem LOGNET. Jedná se o operace spojení či rozdělení zásilek, aktualizaci stavu zásilky v systému GCTC apod.
Označení souborů požadavků (k systému GCTC) – viz kapitola B.5: GCTC_BM_Consignment_OwnerNation GCTC_BM_ConsignmentData_Visibility GCTC_BM_ConsignmentManagement GCTC_UC_AUT_AdminUser GCTC_UC_AUT_GCTCUser GCTC_UC_AUT_NationalUser GCTC_UC_AUT_Privileges GCTC_UC_MAN_AITGenerate GCTC_UC_MAN_COC GCTC_UC_MAN_DEC
Uživatel s oprávněním správce může aktualizovat informace o lokalitě (místě, kde se zásilka nachází).
Označení souborů požadavků (k systému GCTC) – viz kapitola B.5: GCTC_UC_ADMIN_Locations GCTC_UC_AUDT_Operations
B.2.2.24 Správa štítků
Systém GCTC bude automaticky registrovat sledované štítky RFID. Bude také automaticky aktualizovat jejich stav na základě příchozích zpráv Tag Commissioned / Tag Decommissionned (štítek aktivován / vyřazen).
Označení souborů požadavků (k systému GCTC) – viz kapitola B.5: GCTC_UC_TAG_Record GCTC_UC_TAG_Status
B.2.2.25 Identifikace zúčastněné strany
K tomu, aby systém GCTC přijal zprávy, které používají vnitrostátní identifikátory lokalit, musí být notifikovány dotyčné externí (vnitrostátní) definice lokalit. Vnitrostátní lokalita má pro identifikaci systémem GCTC dvojici údajů skládající se z ID a pozice:
ID - může to být buď vnitrostátní GLN, nebo dvojice tvořené ID vnitrostátní lokality a státem - vlastníkem;
pozice – musí být dána zeměpisnou šířkou a délkou (je to volitelný parametr, ale když by nebyl udán, nebylo by možné lokalizovat informace ze sledování).
Přijetí příchozích informací o identifikaci strany bude založeno na následujících business rules systému GCTC:
a) Lokalita identifikovaná pomocí GLN:
pokud je udáno GLN „GCTC NATO“ (založené na GS1 předčíslí organizace) - jedná se o chybu (čísla GLN NATO mohou být generována pouze automaticky);
pokud je udán vnitrostátní GLN – zkontrolovat stát – vlastníka. Je-li již lokalita v systému, aktualizovat; v opačném případě uznat lokalitu.
b) Lokalita identifikovaná pomocí ID státu a státu - vlastníka:
zkontrolovat stát - vlastníka. Je-li již lokalita v systému, aktualizovat; v opačném případě uznat lokalitu.
Označení souborů požadavků (k systému GCTC) – viz kapitola B.5: GCTC_UC_AUDT_Operations GCTC_UC_LOC_PartyIdentify GCTC_UC_LOC_RegisterLocation
B.2.2.26 Zpracování příchozích zpráv
Systém GCTC vystaví (bude mít) rozhraní pro přijímání a zpracování zpráv z externích systémů. Jedná se o zprávy ze sledování, notifikační zprávy a zprávy
ČOS 990503 3. vydání Příloha B (normativní)
B-21
k identifikaci zúčastněných stran. Budou provedena všechna možná ověření a ke každé zprávě budou shromážděny a připojeny všechny v ní zjištěné chyby.
Pravidla ověření (aby výsledek ověření byl pozitivní):
všechny požadavky na obsah zprávy (podle typu zprávy) jsou splněny (viz požadavky v souboru GCTC_BP_INMSG);
jestliže zpráva obsahuje jak zásilku rodičů, tak zásilky potomků, ověření bude provedeno pro oba druhy.
Závažné nedostatky ve výsledku ověření se vyjádří následujícími chybovými kódy:
MissingInformation (chybějící informace),
SSCCInvalid (neplatný SSCC),
ContentInvalidForConsolidatedConsignment (neplatný obsah pro spojenou zásilku),
ConflictingIDs (rozporné identifikátory),
ConsoldationInvalidForLevel0 (neplatné spojení pro úroveň 0),
DeconsoldationInvalidForLevel0 (neplatné rozdělení pro úroveň 0).
Označení souborů požadavků (k systému GCTC) – viz kapitola B.5: GCTC_BP_INMSG_LOC GCTC_BP_INMSG_VALID GCTC_UC_LOC_PresentationMsg GCTC_UC_TRACK_OutOfSequenceMessages GCTC_UC_TRACK_PROC_New GCTC_UC_TRACK_RFID_ConsecRead
B.2.2.27 Vytváření zpráv
Systém GCTC bude poskytovat webové uživatelské rozhraní pro tvorbu a tisk zpráv.
Označení souborů požadavků (k systému GCTC) – viz kapitola B.5: GCTC_UC_LOC_PresentationReports GCTC_UC_REP_AITReport GCTC_UC_REP_Generate GCTC_UC_REP_Items GCTC_UC_REP_NonRegLoc GCTC_UC_REP_Query
B.2.2.28 Čištění dat zásilek
Uživatel s oprávněním správce může odstraňovat záznamy o „uzavřených“ zásilkách podle kritérií času a lokality.
Označení souborů požadavků (k systému GCTC) – viz kapitola B.5: GCTC_UC_ADMIN_Purging.
B.2.2.29 Dotazy na data zásilky
Systém GCTC vystaví různé možnosti dotazů pro získání odpovědí ke stavu zásilky a lokalitě, které budou dostupné v interaktivních i neinteraktivních režimech. Dotazy na kvalifikované zásilky budou navíc omezeny na základě uživatelských povolení (např. uživatel, který je partnerem určitého státu, jiného než NATO, by měl mít přístup pouze k zásilkám, jejichž vlastníkem je tento stát).
Označení souborů požadavků (k systému GCTC) – viz kapitola B.5:
Systém bude poskytovat možnosti dotazování k zásilkám založené na kombinacích lokality "při přepravě" a časového intervalu. Na zaslané dotazy budou vráceny odpovědi, jejichž obsahem bude ověřená aktivita v dané lokalitě v daném časovém intervalu kvalifikovaných zásilek. Protože sledování událostí může být hlášeno systémy CT pomocí vnitrostátních identifikátorů pro lokalitu, pro odpovídající lokality bude použit mechanismus, založený na geografické poloze.
Označení souborů požadavků (k systému GCTC) – viz kapitola B.5: GCTC_BM_Query_Activity. GCTC_BM_Query_Location. GCTC_UC_LOC_VicinityCalc GCTC_UC_LOC_VicinityCalcAlg
B.2.2.31 Dotazy na informace o zásilce
Systém umožní dotazování založené na:
identifikátorech: kód SSCC, alternativní ID, referenční ID;
skupinových kódech: stát, operační kód;
doplňkových informacích: aktuální lokalita, ID štítku, rozměry, stav apod.
Označení souborů požadavků (k systému GCTC) – viz kapitola B.5: GCTC_BM_Query_AlternateID GCTC_BM_Query_GroupingCodes GCTC_BM_Query_Location GCTC_BM_Query_NATOID GCTC_BM_Query_TagID
ČOS 990503 3. vydání Příloha B (normativní)
B-23
B.2.2.32 Dotazy na identifikátory zásilek
Způsobilost k vznášení dotazů na data ze sledování zásilek, která je založena na kódech RIC, NIC, NSN, referenčním ID. Povede ke kvalifikačním zásilkám „úrovně 0“, které obsahují daný kód hlášení položky (RIC).
Označení souborů požadavků (k systému GCTC) – viz kapitola B.5: GCTC_BM_Query_ItemID
B.2.2.33 Příjem zásilky
Tok se spustí, když systém GCTC přijme zprávu obsahující avízo příjmu zaslanou z POE a zpráva je k dispozici pro proces. Tok procesu je podobný procesu při odeslání zásilky s rozdílem, že auditované události budou 'Received', resp. 'ParentReceived' („přijato“, resp. „rodič přijat“ (tj. zásilka rodiče)).
Označení souborů požadavků (k systému GCTC) – viz kapitola B.5: GCTC_BM_CTDataSource_DetailedTrackingMessage GCTC_UC_CON_CreateModes GCTC_UC_HST_TrackingEvent
B.2.2.34 Záznam události ze sledování
Tento proces odpovídá za zaznamenání události ze sledování dané zásilky; událost je zaznamenána jak pro dotyčnou zásilku, tak pro všechny zásilky na ní závislé. Toho se dosáhne předáváním události (např. zrcadlením události) na každou závislou zásilku až do nejnižší úrovně hierarchie.
Označení souborů požadavků (k systému GCTC) – viz kapitola B.5: GCTC_BM_AuditConsolidatedConsignments GCTC_UC_HST_PropagateTrackingEvent
B.2.2.35 Řešení výjimek při spojování a rozdělování zásilek
B.2.2.35.1 Výjimky pro operace spojování zásilek
Výjimky mohou nastat v následujících situacích:
a) Jestliže specifikovaná zásilka potomků je již spojena s daným rodičem. V tomto případě auditovat aktuální událost spojení zásilky, je-li to potřebné (např. uchování existující události AttachedToConsignment (připojeno k zásilce) pro potomka, je-li starší než probíhající spouštěcí událost; v opačném případě ji aktualizovat podle probíhající spouštěcí události). Vyměnit CT data se státem, je-li to potřeba.
b) Jestliže specifikovaná zásilka potomků existuje a je spojena s různými rodiči. Jestliže stávající rodič není součástí jiné zásilky a existující spojená zásilka pro potomka je starší než probíhající událost:
aktualizovat strukturu (odpojit od stávajícího rodiče, žádnou událost nezaznamenávat);
spojit s novým rodičem a zaznamenat aktuální událost spojení (na úrovni potomků).
Jestliže existující spojená zásilka je novější nebo stávající rodič je součástí jiné zásilky, zaznamenat obdrženou událost spojení zásilek (na úrovni potomků).
B.2.2.35.2 Výjimky pro operace rozdělování zásilek
Mohou nastat v následujících situacích:
ČOS 990503 3. vydání Příloha B (normativní)
B-24
a) Specifikovaná zásilka potomků existuje a není spojena s žádným rodičem. V tom případě zaznamenat současnou událost rozdělení (zachovat nejnovější, pokud stejná událost již byla auditována).
b) Specifikovaná zásilka potomků existuje a je spojena s různými rodiči:
jestliže stávající zásilka potomků je starší, aktualizovat strukturu (odpojit od stávajícího rodiče). Zaznamenat aktuální událost rozdělení a vyměnit odpovídající informace o události;
jestliže stávající zásilka potomků je novější, auditovat současné rozdělení; vyměnit odpovídající informace o této události.
Označení souborů požadavků (k systému GCTC) – viz kapitola B.5: GCTC_UC_COC_AbnormalSituations GCTC_UC_DEC_AbnormalSituations
B.2.2.36 Směrování zpráv RFID ze sledování
Servery RFID budou automaticky posílat zprávy ze sledování štítků do státu, který je vlastníkem zásilky, a to podle směrových kódů zaznamenaných v záhlaví štítku RFID.
Označení souborů požadavků (k systému GCTC) – viz kapitola B.5: ICT_BM_Consignment_OwnerNation GCTC_PC_RFID_RoutingCodes
B.2.2.37 Štítek zásilky
Představuje proces v systému GCTC, který se spustí po přijetí zprávy o aktivaci štítku (štítek zásilky je uveden do používání) poslané ze sběrného místa CT do systému GCTC a zpráva je k dispozici pro zpracování.
Proces zodpovídá za aktualizaci (nebo vytvoření) záznamu o zásilce, zaznamenává odpovídající vstup do auditu sledování (událost = Tag Commissioned = štítek zásilky je uveden do používání) a provádí výměnu dat se státem - vlastníkem.
Označení souborů požadavků (k systému GCTC) – viz kapitola B.5: GCTC_BM_ConsignmentData_TrackingInfo GCTC_BM_CTDataSource_SimpleDetectMessage GCTC_UC_CON_CreateModes GCTC_UC_HST_TrackingEvent.
B.2.2.37.1 Nový štítek pro existující zásilku v systému GCTC, která dosud nemá štítek {základní cesta}
Normální tok předpokládá, že záznam o zásilce NATO již existuje v systému CT a nemá přiřazen žádný AIT_ID (identifikátor zařízení AIT):
aktualizovat záznam o zásilce (AIT_ID),
vytvořit instanci historie (událost = Tag Commissioned (štítek zásilky je uveden do používání)),
uskutečnit výměnu dat CT.
B.2.2.37.2 Nový štítek pro zásilku, která není známa systému GCTC {alternativní cesta}
Zásilka NATO s platným kódem SSCC, která systému CT dosud není známa:
ČOS 990503 3. vydání Příloha B (normativní)
B-25
vytvořit záznam o zásilce s unikátním ID,
vytvořit instanci historie (událost = Tag Commissioned (štítek zásilky je uveden do používání)),
uskutečnit výměnu dat CT.
B.2.2.37.3 Kontrola zásilky GCTC již opatřené štítkem {alternativní cesta}
Když v systému CT již existuje záznam o zásilce a má přiřazen AIT_ID:
je-li stejný AIT_ID, aktualizovat odpovídající instanci historie (pro událost = Tag Commissioned a daný AIT_ID), jestliže příchozí událost je starší než již zaznamenaná událost; potom si o tom vyměnit data CT;
je-li rozdílný AIT_ID a odpovídající instance historie (pro událost = Tag Commissioned a zaznamenaný AIT_ID) je starší než příchozí událost, postupovat podle základní cesty (aktualizovat zásilku, zaznamenat událost a vyměnit data). Jinak zaznamenat událost a vyměnit si data.
B.2.2.38 Sledování zásilky
Zahrnuje všechny základní požadavky na systém GCTC:
vytvoření zásilek na základě automatizovaných odeslání notifikací,
zaznamenání spojování a rozdělování zásilek podle postupů externích systémů CT,
zaznamenání všech informací ze sledování přijatých z externích systémů CT,
výměna všech důležitých dat CT se zúčastněnými stranami podle předdefinice v nastavení subskripce,
poskytnutí webového rozhraní pro data CT,
umožnění dotazování jak pro externí systémy, tak pro uživatele s webovým rozhraním.
Označení souborů požadavků (k systému GCTC) – viz kapitola B.5: ICT_BM_ConsignmentData_Visibility GCTC_BM_Authorization GCTC_BM_ConsignmentData_Availability GCTC_BM_ConsignmentData_Ownership GCTC_BM_ConsignmentData_TrackingInfo GCTC_BM_CT_ConsignmentData GCTC_BM_CT_ZULUTIME GCTC_BM_CTSystemScope GCTC_BM_ExchangeCTData GCTC_BM_QueryCTData GCTC_BM_Tracking_DataSources
B.2.2.39 Sledování zásilky s použitím systému RFID
Zahrnuje požadavky na systém RFID vztažené na sledování národních zásilek a zásilek NATO za použití technologie RFID a směrování příslušných informací do systému GCTC NATO a/nebo do států, které vlastní zásilky:
zprovoznění štítků založených na poskytnutých identifikátorech zásilek SSCC a na směrových kódech;
detekce zásilek podle štítků RFID nebo čárových kódů;
vyřazení (zrušení) štítků po jejich odpojení od zásilek;
ČOS 990503 3. vydání Příloha B (normativní)
B-26
vydání odpovídajících zpráv pro všechny výše uvedené události do systému GCTC podle směrového kódu na štítku;
vydání odpovídajících zpráv pro všechny výše uvedené události do států - vlastníků pro příslušné zásilky podle směrového kódu na štítku.
Označení souborů požadavků (k systému GCTC) – viz kapitola B.5: GCTC_BM_CT_ZULUTIME GCTC_PC_RFID_Barcodes GCTC_PC_RFID_MessageFormat GCTC_PC_RFID_TagCommissioned GCTC_PC_RFID_TagDecommissioned GCTC_PC_RFID_TagDetected GCTC_PC_RFID_TagInfo
B.2.2.40 Aktualizace záznamu o zásilce
Aktualizace reprezentace zásilky v systému GCTC. Proces se spouští zprávou ConsignmentNotification (notifikace zásilky) pro zásilku již existující v systému GCTC.
Označení souborů požadavků (k systému GCTC) – viz kapitola B.5: GCTC_UC_HST_ConUpdated. GCTC_BM_CT_Consignment_Status
B.2.2.41 Aktualizace stavu zásilky
Proces se spustí, když POD/POE/stát systému CT pošle do systému GCTC zprávu o stavu přepravy (IFTSTA – viz příloha F) a ta je k dispozici pro zahájení procesů. Výsledkem je fyzická aktualizace stavu zásilky GCTC a současné lokality, zaznamenání události a výměna dat CT se zúčastněnými stranami.
Minimální soubor stavů požadovaných dohodou STANAG je: ztracená, poškozená, zpožděná, poslaná do různých uzlů. Viz „Ruční aktualizace stavu zásilky“ pro kompletní seznam stavů zásilky, který bude podporován a vystaven (exponován) systémem GCTC.
Označení souborů požadavků (k systému GCTC) – viz kapitola B.5: GCTC_BM_CT_Consignment_Status GCTC_BM_CTDataSource_DetailedTrackingMessage
B.2.2.41.1 Stav existující zásilky GCTC {základní cesta}
Normální tok předpokládá, že v systému CT již existuje záznam o zásilce NATO:
pro kořenovou zásilku aktualizovat stav zásilky a současnou lokalitu a vytvořit instanci historie (kód události = CS, zaznamenaná změna stavu zásilky);
pro každou závislou zásilku aktualizovat současnou lokalitu a vytvořit instanci historie (kód události = PS, zaznamenaná aktualizace stavu rodičovské zásilky).
Výměnit data CT se zúčastněnými stranami (pro kořenovou a závislé zásilky).
B.2.2.41.2 Stav neexistující zásilky GCTC {alternativní cesta}
Vytvořit zásilku NATO a vytvořit instanci historie (událost - stejná jako pro normální tok).
ČOS 990503 3. vydání Příloha B (normativní)
B-27
B.2.2.42 Ruční aktualizace stavu zásilky
Uživatelé budou mít možnost ručně aktualizovat stav zásilky. Jakékoliv ruční aktualizace stavu, kromě aktualizace stavu zásilky, budou také zaznamenány v historii zásilky s kódem události "Consignment Manual Status Change - ruční změna stavu zásilky"; aktualizace budou také zaznamenány u všech závislých zásilek (princip předávání) s kódem události "Parent Manual Status Change - ruční změna stavu zásilky rodičů". POZNÁMKA Pokud pro tuto operaci nebude k dispozici žádná aktuální
lokalita, v rámci tohoto procesu tyto informace nebudou aktualizovány.
Zásilka bude podporovat dva stavy.
Přepravní stav
Tato informace bude zohledňovat současný stav z hlediska přepravy – viz níže. „Kódy stavu přepravy“ představují stav, že zásilka může být skladována v systému CT a v případě potřeby vyměněna s jinými systémy.
Delivered (doručená)
Zásilka byla doručena příjemci.
Awaiting
transport
(čekající přeprava)
Pro zásilku dosud nebyl stanoven způsob přepravy nebo transport materiálu dosud nebyl vypraven do dalšího uzlu CT.
Ready for
Transport (připravená pro přepravu)
Zásilka je připravena pro odeslání do dalšího uzlu CT.
Delayed (zpožděná)
Zásilka nesplní svůj odhadovaný čas příjezdu (ETA) do následujícího uzlu CT.
On time (včasná)
Očekává se, že zásilka splní svůj odhadovaný čas příjezdu (ETA) do následujícího uzlu CT.
Early (uspíšená)
Očekává se, že zásilka dorazí do následujícího uzlu CT dříve, než je její plánovaný čas příjezdu nebo ETA.
Missing (nezvěstná)
Zásilka zmizela a sledování je v plném proudu.
Lost (ztracená)
Zásilka zmizela a sledování potvrdilo, že je nenávratně ztracená.
Awaiting further instructions (čekající na další instrukce)
Jsou potřebné další informace před rozhodnutím, co provést se zásilkou v uzlu CT.
Closed (uzavřená)
Životní cyklus zásilky byl ukončen.
ČOS 990503 3. vydání Příloha B (normativní)
B-28
Technický stav
Tato informace odráží kvantitativní a kvalitativní hlediska technického stavu zásilky:
Undamaged (nepoškozená)
Zásilka nebyla poškozena.
Damaged (poškozená)
Zásilka byla poškozena.
Quantity Discrepancy (neúplná)
Obsah zásilky není úplný.
Ruční proces je podobný aktualizaci stavu zásilky podle předchozího článku. V tomto případě se používají kódy událostí:
CM Ruční změna stavu zásilky.
PM Ruční změna stavu zásilky rodičů.
Označení souborů požadavků (k systému GCTC) – viz kapitola B.5: GCTC_UC_HST_ConStatusUpdated GCTC_BM_CT_Consignment_Status GCTC_UC_AUDT_Operations GCTC_UC_MAN_Status
B.2.2.43 Žádost o validaci
Proces zodpovídá za validaci podle externího požadavku. Existují dva typy pravidel validace:
společné pro všechny požadavky,
specifické pro individuální požadavky nebo podskupiny požadavků.
Označení souborů požadavků (k systému GCTC) – viz kapitola B.5: ICT_BM_Consignment_OwnerNation GCTC_BP_INMSG_CONS GCTC_BP_INMSG_DECONS GCTC_BP_INMSG_LOC GCTC_BP_INMSG_OWNERNATION GCTC_BP_INMSG_SSCC GCTC_BP_INMSG_TAG GCTC_BP_INMSG_TRACK GCTC_UC_CON_NATOSSCCGenerateOnly GCTC_UC_LOC_NationOwnID GCTC_UC_LOC_TrackingLocation GCTC_UC_LOC_TrackUnknown
B.2.2.44 Prohlížení zásilek
Interaktivní schopnost dotazovat se na data sledovaných zásilek. Data zásilek budou k dispozici:
ve formě seznamu - seznam vymezených (kvalifikovaných) zásilek podle stanovených kritérií, s omezeným rozsahem informací (ID, aktuální lokalita, datum a čas poslední události, stav);
ČOS 990503 3. vydání Příloha B (normativní)
B-29
v podrobné formě - pro vybranou zásilku uživatel bude mít možnost zobrazit detailní informace o zásilce, o jejím obsahu (položkách) a historii informací.
Označení souborů požadavků (k systému GCTC) – viz kapitola B.5: GCTC_UC_LOC_PresentationUI GCTC_UC_MAN_Query
B.2.2.45 Prohlížení záznamů o chybách
Uživatelé budou mít možnost prohlédnout záznamy o chybách (Error Log) ze zpracování zprávy. Přístup k tomuto souboru bude rovněž omezen státem.
Označení souborů požadavků (k systému GCTC) – viz kapitola B.5: ICT_BM_Consignment_OwnerNation GCTC_BP_INMSG_VALID GCTC_UC_AUT_AdminUser GCTC_UC_AUT_GCTCUser GCTC_UC_AUT_NationalUser GCTC_UC_CON_NotificationException
B.2.2.46 Prohlížení štítků
Interaktivní schopnost dotazovat se na informace o štítku:
současná lokalita štítku (místo, kde se štítek právě nachází),
seznam štítků v dané lokalitě,
seznam všech dostupných štítků, (tj. neaktivovaných i používaných).
Tato schopnost bude dostupná pouze pro uživatele a správce systému.
Označení souborů požadavků (k systému GCTC) – viz kapitola B.5: GCTC_UC_AUT_AdminUser GCTC_UC_AUT_GCTCUser GCTC_UC_TAG_AtLocation GCTC_UC_TAG_CurrentLocation. GCTC_UC_TAG_ListTags
B.3 ÚČASTNÍCI (AKTÉŘI, ACTORS)
Obrázek B.5 znázorňuje hlavní účastníky v ATM (režim asynchronního přenosu) a typické použití systému, na němž se budou podílet. V praxi účastníci představují role a mohou také představovat osoby, které danou roli hrají.
ČOS 990503 3. vydání Příloha B (normativní)
B-30
OBRÁZEK B.5 – Souhrnný přehled aktérů globálního systému
Popisy účastníků
ADAMS Spojenecký systém pro řízení přesunů a nasazení (ADAMS) je účastník informačního systému. Tato aplikace slouží k plánování nasazení.
Jednotka, článek CT (CT Cell)
Tento účastník je zodpovědný za sledování zásilek pomocí dostupných vnitrostátních systémů nebo systému NATO. Poskytuje velení spojených sil nebo jinému příslušnému vojenskému orgánu požadované informace o stavu zásilek a lokalitě, kde se na své trase nacházejí.
Sběrné místo CT (CT Collect Point)
Tento účastník může být jakákoli lokalita (POD, POE apod.) s funkcemi RFID. Je odpovědný za sledování zásilek pomocí dostupných systémů RFID NATO. Poskytuje velení spojených sil nebo jinému příslušnému vojenskému orgánu požadované informace o stavu zásilek a lokalitě, kde se na své trase nacházejí.
Dotazovací místo CT (CT Query Point)
Tímto účastníkem může být stát či systém CT zapojený a oprávněný k prohlížení informací ze sledování zásilek.
Systém CT (CT Systém)
Tento účastník představuje externí vnitrostátní systém nebo systém NATO pro správu nebo sledování zásilek, který je způsobilý komunikovat o informacích o zásilkách se systémem GCTC.
NATIES
Jednotka CT
Sběrné místo CT
POE POD
Trasa zásilek
LOGNET-uživatel CT
Dotazovací místo
CT
Informační systém
ADAMS EVE LOGREP Systém řízení
přepravy
Trasa zásilek za použití
systému RFID
Trasa zpráv RFID ze sledování
zásilek
Systém RFID
«rozšiřuje»
ud Souhrnný přehled aktérů globálního systému
Systém CT
NDSS
ČOS 990503 3. vydání Příloha B (normativní)
B-31
EVE Účinné zviditelnění realizace (EVE) je účastník informačního systému. Je to nový modul LOGFAS pro podporu realizace nasazení a monitorování informací.
Systém (System)
Tento účastník představuje různé informační systémy vnitrostátní nebo NATO, které se budou přímo nebo nepřímo používat pro podporu procesu CT.
Uživatel CT LOGNET (LOGNET CT User)
Tímto účastníkem může být uživatel, který má oprávnění pro systém CT LOGNET: Stát, POD, POE, CT Cell apod.
LOGREP Systém logistických hlášení (LOGREP) je účastník informačního sytému. Je to systém pro podporu logistických hlášení a funguje tak, že poskytuje informace o aktuální dostupnosti a očekávaných dodávkách materiálu a vybavení pro vojenské jednotky.
Systém řízení přepravy (Movement Control System
Tento účastník představuje ruční nebo automatizovaný systém, který uchovává a vyměňuje informace o přesunech a přepravě jednotek nebo výzbroje.
EDEN Síť pro výměnu elektronických dat (EDEN) je rozhraní zaměřené na služby, jehož cílem bude způsobilost provádět výměnu informací mezi různými systémy CT, které působí v rámci NATO nebo jeho členských států. EDEN bude poskytovat soubor služeb, které akceptují zprávy pro výměnu informací mezi různými systémy CT v jazyku XML, v souladu se tímto ČOS.
NDSS Je to účastník informačního systému, který reprezentuje Systém NATO pro zabezpečení skladů.
POD (místo vyložení)
Tímto účastníkem jsou myšleny osoby, které provádějí odbavení zásilky v místě vyložení. (Tzn., že místo by mohl vymezit vedoucí stát logistického zabezpečení, stát specializovaný na úkoly logistiky, hostitelský stát nebo nadnárodní integrovaná logistická jednotka (MILU)).
POE (místo naložení)
Tímto účastníkem jsou myšleny osoby, které provádějí odbavení zásilky v místě naložení. (Tzn., že místo by mohl vymezit obchodní manipulant nebo národní jednotky provádějící nakládku).
Systém RFID (System RFID)
Systém RFID pro sledování zásilek využívaný systémem GCTC.
B.4 PŘEDPOKLADY A ZÁVISLOSTI
K tomu, aby tyto prvky scénáře pracovaly správně, GCTC a všechny externí systémy se musí řídit následujícím procesem (Business Process):
1. Systém GCTC umožní systémům NATO a vnitrostátním systémům hlásit zásilky a jejich aktivity pomocí následujících alternativ:
kódu SSCC (preferuje se) NEBO
kombinací alternativního ID, typového ID a státu - vlastníka.
Každá zásilka musí být jednoznačně identifikovatelná jedním z uvedených způsobů.
ČOS 990503 3. vydání Příloha B (normativní)
B-32
POZNÁMKA Kromě toho GCTC poskytuje jeden referenční ID pro záznam dalšího vnitrostátního ID nebo identifikátoru DVD bez podmínky unikátnosti (pouze pro informaci).
2. Systém NATO a vnitrostátní systémy, které používají kódy SSCC jako standardní identifikátory pro své systémy, musí dodržovat následující pravidla: a) Vždy použít kód SSCC, a to jak ve zprávách ze sledování, tak v notifikačních
zprávách zásilky. b) Alternativní ID mohou tyto státy specifikovat pouze v notifikační zprávě zásilky
(nikdy ne ve zprávě ze sledování). Dodržováním těchto zásad se předejde situacím, kdy notifikace zásilky je opožděna a systém GCTC automaticky generuje kód SSCC NC3A podle zprávy ze sledování a použije alternativní ID, které se v systému dosud nevyskytuje – taková situace se obtížně napravuje.
c) Ještě před zahájením interoperačních aktivit musí stát zaregistrovat (sdělit) své GS1 předčíslí organizace v systému GCTC. Systém GCTC uloží sdělené národní GS1 předčíslí organizace a použije je k odvození státu - vlastníka zásilky pro zprávy týkající se zásilky, která ještě není systému GCTC známa a obsahuje pouze kód SSCC zásilky (bez explicitně stanoveného vlastníka zásilky).
3. V případě, že systém NATO a vnitrostátní systémy nepoužívají SSCC jako standardní identifikátory pro své systémy: a) Notifikační zpráva zásilky bude specifikovat pouze alternativní ID (ne kód
SSCC). b) Systém GCTC pro takové bude automaticky generovat kód SSCC NC3A. c) Sledování pak může být hlášeno pomocí buď kódu SSCC NC3A, nebo
alternativního ID. Tento scénář povede k zásilkám systému GCTC s následujícími konfiguracemi identifikátorů:
kód SSCC NC3A,
alternativní ID,
stát - vlastník je zaznamenán podle specifikace v notifikační zprávě zásilky (je o skutečný stát - vlastník zásilky).
POZNÁMKA Je možné si povšimnout, že stát odvozený z kódu SSCC nemusí být stejný jako „stát - vlastník“ (nesoulad stát – kód SSCC).
4. Kód SSCC NC3A může být pouze automaticky generován systémem GCTC. V žádném případě nemůže být sdělen externím systémem. Bezprostředním důsledkem je, že zpráva (ze sledování zásilky nebo notifikační) pomocí kódu SSCC NC3A, která již neexistuje v systému GCTC bude považována za neplatnou.
5. Stát - vlastník zásilky bude určen a zaznamenán v systému GCTC podle následujících pravidel: a) Když se tvoří nová zásilka v systému GCTC – buď na základě požadavku
(jako důsledek notifikační zprávy zásilky), nebo automaticky (když je přijata zpráva o zásilce, která ještě není v systému GCTC zaznamenána), stát - vlastník se určí:
podle specifikace ve zprávě (pokud je v ní stát - vlastník uveden),
ČOS 990503 3. vydání Příloha B (normativní)
B-33
odvozením podle udaného kódu SSCC – je-li to možné (tj. pokud je odpovídající GS1 předčíslí organizace registrováno v GCTC); v opačném případě bude zásilka považována za zásilku „neznámého státu“ (s uvedením kódu státu „XX“).
b) Když se aktualizuje zásilka existující v GCTC na základě notifikační zprávy zásilky:
je-li stát - vlastník uveden ve zprávě, aktualizuje se záznam o něm v GCTC,
není-li stát - vlastník uveden ve zprávě, záznam o něm v GCTC zůstává beze změn.
6. Systém GCTC bude provádět výměnu dat se státem - vlastníkem zásilky; ten bude pro danou zásilku vždy zaznamenán v systému GCTC (viz článek 5). Data se budou vyměňovat pouze, když stát - vlastník:
není shodný se státem, který provozuje GCTC A
není shodný se státem, který zaslal původní informace ze sledování zásilky (stát na trase zásilky)
A
není „neznámý“ (není označen kódem „XX“).
7. Spojování zásilek
a) Normální scénář: Systém NATO nebo vnitrostátní systémy, které provádějí spojení, nejprve vytvoří nově spojenou zásilku ve svém systému s odpovídajícím ID. Notifikační zprávu této zásilky je třeba zaslat do systému GCTC (podle článku 2 nebo 3). Zprávu ze sledování zásilky je třeba zaslat do systému GCTC (za použití téhož ID jako v notifikační zprávě).
b) Alternativní scénář – varianta předchozího odstavce 7 a), když je zaslána zpráva ze sledování zásilky, které nepředcházela notifikační zpráva zásilky. Poněvadž zpráva ze sledování musí dodržovat pravidla podle článku 2 nebo 3, nová zásilka se stále bude tvořit automaticky. Alternativní scénář – ruční postup: NATO nebo stát používá systém prostřednictvím webového rozhraní GCTC. Jediným důvodem pro tento postup je zaplnit mezeru, kdy stát provádějící spojení nemá v místě realizace spojení k dispozici svůj systém. V tomto případě je rozumné předpokládat, že nová zásilka je ve vlastnictví státu, který hlásí spojení zásilek (stát uživatele). Spojená zásilka bude mít automaticky generovaný kód SSCC NC3A (je možný rozdíl mezi státem a kódem SSCC).
Dle tohoto postupu bude v systému GCTC zapsán jako stát - vlastník nově spojené zásilky vždy ten stát, který provádí spojení zásilek.
B.5 POŽADAVKY
Tato kapitola uvádí detailní požadavky na systém GCTC a obsahuje:
nejvyšší úroveň požadavků na fungování systému, uvedené na základě BPM pro sledování zásilek,
nejnižší úroveň požadavků na případ užití (use case),
podrobné rozšíření obecného přehledu případ užití (viz kapitola B.2)
ČOS 990503 3. vydání Příloha B (normativní)
B-34
Model pro analýzu systému GCTC (pro datové struktury a rozhraní zpráv) je zahrnut v Logickém přehledu systému GCTC v kapitole B.7, který definuje entity použité v této kapitole.
Každý požadavek má unikátní ID. Identifikátor má následující syntaxi: GCTC_[AA]_[XXXX]_[volný formát], kde
AA určuje typ požadavku: BM pro požadavky původem z modelu provozu systému, BP pro požadavky vztažené k fungování procesů, které lze použít, PC požadavky na systém RFID, SR požadavky na systém, UC pro požadavky spojené s případem užití. XXXX je zkratka pro kategorii funkce volný formát stanovuje podrobnější úroveň funkčnosti.
B.5.1 Požadavky na provoz
V následujících diagramech považovat ICTC za GCTC.
ČOS 990503 3. vydání Příloha B (normativní)
B-35
pd
OBRÁZEK B.6 – Požadavky na provoz systému GCTC
B.5.2 GCTC_BM Business Model Requirement (požadavky na model provozu)
Tato kapitola pojmenovává požadavky na provoz1), které pocházejí z modelu provozu (STANAG 2291).
Každá zásilka v systému CT musí uvádět stát, který je jejím vlastníkem, aby mohla probíhat výměna dat a autorizační požadavky.
1)
Originální výraz „Business“ má v tomto kontextu význam „fungování, provozu“, ne „obchodu“.
ICTC_PC_RFID Požadavky na systém RFID
ICTC_BP_INMSG Příchozí zprávy
pd Požadavky na provoz ICTC
ICTC_BM Požadavky na model provozu
(Převzaté prvky z ICTC_PC)
ČOS 990503 3. vydání Příloha B (normativní)
B-36
B.5.2.2 GCTC_BM_ConsignmentData_Visibility (viditelnost dat zásilky)
Zajištění optické kontroly dat zásilky během všech fází provozu. Oblast viditelnosti je definována od vytvoření zásilky do rozdělení nebo příjmu zásilky.
B.5.2.3 GCTC_BM_AuditConsolidatedConsignments (audit spojených zásilek)
Systém CT musí zajistit přijetí a odeslání informací o každé základní zásilce ve spojené zásilce odečtem z jednotlivých médií AIT.
B.5.2.4 GCTC_BM_Authorization (autorizace)
Přístup k datům ze sledování zásilek musí být možné omezit podle států:
uživateli bude dovoleno prohlížet, načíst, upravit či smazat údaje pouze o zásilkách svého státu podle jeho písemného pověření;
uživatel registrovaný u státu, který provozuje systém CT, bude mít dovolen přístup ke všem zásilkám v systému.
Systém GCTC musí být schopen pro účely sledování přijmout a zaznamenat obsah zásilky úrovně 0. To může být umožněno formou buď jednotlivých položek (označených pomocí kódů NIC nebo NSN), nebo spojených položek (označených kódy RIC).
Každá zásilka NATO nebo zásilka státu (v případech, kdy státy souhlasí se sdílením údajů s NATO nebo jejich zásilky jsou sledovány systémem GCTC) musí mít unikátní sériový kód zásilky NATO, který je zaznamenán v systému GCTC. V souladu se STANAG 2495 je tímto identifikátorem SSCC, který zajišťuje požadovanou unikátnost na základě „GS1 předčíslí organizace“ (neboli „prefixu organizace, firmy“), vytvořením 18-ti místného číselného kódu (proto se označuje jako SSCC-18).
Tento unikátní identifikátor musí být buď generován systémem GCTC, nebo poskytnut systémem uživatele nebo původce zásilky. Když systém GCTC generuje SSCC NATO pro zásilku vlastněnou státem, je nutné provést přeznačení a zásilka bude mít také svůj alternativní (národní) ID nebo alternativní typ ID zásilky, který je zaznamenán systémem GCTC pro odkazy. Sledování může být prováděno pomocí těchto ID.
B.5.2.7 GCTC_BM_Consignment_XRef_DVD (odkaz na zásilku dopravovanou DVD)
Systém musí uchovat odkaz mezi obchodním záznamem a ID zásilky NATO pro audit sledování (v případě zásilky dopravované prostřednictvím DVD).
B.5.2.8 GCTC_BM_Consignment_XRef_NonNatoIdentifier (odkaz na identifikátor zásilky, kterým není identifikátor NATO)
Systém musí zaznamenat vztah mezi ID zásilky NATO (STANAG 2185 a 2494) a odpovídajícím formátem identifikátoru, kterým není identifikátor NATO. Příklady aplikace tohoto požadavku jsou:
zásilka původem z NDSS je označena číslem průvodního dokladu (NDSS Manifest Number - tento identifikátor není unikátní napříč zásilkami),
zásilky USA označené TCN.
ČOS 990503 3. vydání Příloha B (normativní)
B-37
B.5.2.9 GCTC_BM_ConsignmentData_Availability (dispozice údajů o zásilce)
Sledování zásilky z místa, kde stát nebo NATO pořídí záznam o zásilce do místa, kde objednatel rozebere nebo přijme tuto zásilku. Údaje ze sledování budou zaznamenány a budou k dispozici v průběhu celého životního cyklu zásilky.
B.5.2.10 GCTC_BM_ConsignmentData_Ownership (vlastnictví údajů o zásilce)
Vnitrostátní systémy nebo systém NATO budou zdrojem podrobných informací o obsahu a hierarchii jednotlivých zásilek.
Podrobnosti týkající se majetku (materiálu) NATO se uloží v systému NATO. Údaje o majetku státu se normálně uloží ve vnitrostátním systému, ale budou přístupné veliteli NATO podle dohody s dotyčným státem. Na základě souhlasu států se údaje o majetku státu mohou uložit do systému NATO.
B.5.2.11 GCTC_BM_ConsignmentData_TrackingInfo (informace ze sledování zásilky)
Systém CT musí být schopen zaznamenat informace ze sledování zásilky získaných z různých zdrojů.
Zásilka je definována jako jeden nebo několik identifikovaných majetků, které jsou přepravovány jako jeden objekt od odesílatele k příjemci a jsou označeny unikátním identifikátorem. Hierarchie zásilky se může vyvinout, když několik zásilek je spojeno do jedné zásilky vyšší úrovně:
zásilky úrovně 0; typickým představitelem jsou přepravní balení (např. krabice a bedny), jejichž obsahem je jedna nebo více položek přepravovaných jako jeden objekt;
zásilky úrovně 1; typickým představitelem jsou spojené zásilky úrovně 1 (např. v triwall2) obalech);
zásilky úrovně 2; typickým představitelem jsou spojené zásilky úrovní 0 a 1 (např. letecké palety).
Systém GCTC musí zaznamenat stav zásilky při její přepravě od odesílatele k příjemci.
2)
tri-wall obaly jsou třívrstvé obaly na bázi lepenky. Mají pevnost srovnatelnou s obaly z překližky, ale mají až o 70 % nižší hmotnost.
ČOS 990503 3. vydání Příloha B (normativní)
B-38
B.5.2.17 GCTC_BM_CT_ConsignmentData (údaje o zásilce)
V každém přepravním uzlu v mezinárodní přepravě vedoucí stát v logistickém zabezpečení (LLN) nebo stát specializovaný na vymezenou roli v logistickém zabezpečení (LRSN) musí použít systém pro sledování zásilek k získání a zaslání údajů o zásilce (např. hmotnost a vnější rozměry) v souladu se STANAG 2494.
Data ze sledování zásilky musí mít „časové razítko“, aby se zajistil správný časový sled dat v systémech sledování zásilek. Datum a čas příjmu, odeslání a jiné hlášené stavy budou udány v koordinovaném světovém času (Zulu time) a předány do GCTC.
B.5.2.19 GCTC_BM_CTDataSource_ConsignmentNotification (zdroj dat CT – notifikace zásilky)
Státy budou zasílat – podle požadavků nebo v případě potřeby – informace o určených zásilkách do úložiště NATO pro data ze sledování zásilek.
POZNÁMKA Určené zásilky by měly mít kód hlášení položky (RIC), kódy RIC jako součást seznamu hlášení položek (RIL) nebo deníku seznamu priorit velitele. Systém GCTC musí přijmout a reagovat na notifikační zprávy zásilek.
B.5.2.20 GCTC_BM_CTDataSource_DetailedTrackingMessage (zdroj dat CT – detailní zprávy ze sledování)
Vnitrostátní systémy nebo systém NATO budou sbírat údaje o zásilkách na POD, POE a v jiných uzlech CT v souladu s popisem ve STANAG 2185 pro:
zprávu o odeslání zásilky (avízo odeslání),
zprávu o příjmu zásilky (potvrzení příjmu),
zprávu o přepravním stavu v různých uzlech pro stavy ztracená/poškozená/zpožděná/ zaslaná.
Systém GCTC musí přijmout a reagovat na podrobné zprávy ze sledování zásilek.
B.5.2.21 GCTC_BM_CTDataSource_SimpleDetectMessage (zdroj dat CT – zpráva z jednoduché detekce)
V některých případech mohou automatizované systémy poskytovat informace systému sledování zásilek zkrácenými postupy. Například uzel RFID pro sledování zásilek bude aktivovat zprávy CT, které budou obsahovat pouze ID zásilky, identifikátor AIT, lokalitu, datum a čas. Tyto informace budou získány z detekce štítku RFID nebo skenů čárových kódů. Systém GCTC musí přijmout a reagovat na zkrácené zprávy ze sledování zásilek.
B.5.2.22 GCTC_BM_CTSystemScope (rámec systému CT)
Zřídit vnitrostátní a alianční systém sledování zásilek schopný sledovat a spravovat, v téměř reálném čase, přepravu národních zásilek a zásilek NATO ve společném nadnárodním prostředí, kterou zabezpečují vojenští i komerční dopravci.
B.5.2.23 GCTC_BM_ExchangeCTData (výměna dat CT)
Rozesílat informace ze sledování zásilky systému řízení informací vlastníka zásilky a dalším systémům, jak jsou definovány řídícími procesy informací.
ČOS 990503 3. vydání Příloha B (normativní)
B-39
B.5.2.24 GCTC_BM_ExchangeData_IS (výměna dat s informačními systémy)
Systém sledování zásilek musí provádět výměnu dat ze sledování s dalšími systémy, které jsou definovány procesy řízení informací (ADAMS, EVE, LOGREP).
B.5.2.25 GCTC_BM_ExchangeData_Nations (výměna dat se státy)
Systém CT musí být způsobilý provádět výměnu všech dat ze sledování, které přijme pro každou zásilku z jiných zdrojů než ze státu - vlastníka zásilky, s informačním systémem státu - vlastníka. Systém GCTC bude získávat informace ze sledování jak pro určené zásilky, o nichž NATO musí být informováno, tak pro zásilky patřící jednotce NATO; ale pak je bude muset odlišit a zahájit výměnu správných dat s vnitrostátními systémy, jichž se daná transakce týká.
Poskytovat schopnost dotazovat se na zásilky, která je založena na kombinaci dané lokality a časového intervalu.
B.5.2.27 GCTC_BM_Query_AlternateID (dotazy na alternativní ID)
Poskytovat schopnost dotazovat se na zásilky, která je založena na:
alternativním ID zásilky (jako TCN, ID zásilky DVD, apod.),
referenčním čísle zásilky (jako NDSS Manifest Number).
B.5.2.28 GCTC_BM_Query_GroupingCodes (dotazy na seskupení kódů)
Poskytovat schopnost dotazovat se na zásilky, která je založena na každém identifikovaném seskupení kódů dostupných pro zásilku. Skupiny by mohly zahrnovat:
stát vlastníka,
operační kódy.
B.5.2.29 GCTC_BM_Query_ItemID (dotazy na ID položky)
Poskytovat schopnost dotazovat se na zásilky, která je založena na kódech hlášení položek RIC, NSN nebo NIC.
B.5.2.30 GCTC_BM_Query_Location (dotazy na lokalitu)
Poskytovat schopnost dotazovat se na zásilky, která je založena na aktuální lokalitě.
B.5.2.31 GCTC_BM_Query_NATOID (dotazy na ID NATO)
Poskytovat schopnost dotazovat se na zásilky, která je založena na unikátním identifikátoru zásilek NATO (tj. kód SSCC).
B.5.2.32 GCTC_BM_Query_TagID (dotazy na ID štítku)
Poskytovat schopnost dotazovat se na zásilky, která je založena na identifikátoru štítku.
B.5.2.33 GCTC_BM_QueryCTData (dotazy na data CT)
Poskytovat schopnost vznášet dotazy k odpovědím o stavu zásilky a lokalitě a spouštět základní řídicí hlášení. Systém bude způsobilý k provádění interaktivních dotazů a také dotazů k přijatým zprávám.
ČOS 990503 3. vydání Příloha B (normativní)
B-40
Dotazy na kvalifikované zásilky budou navíc omezeny na základě oprávnění uživatele (např. uživatel z určitého státu mimo NATO by měl mít přístup omezen jen na zásilky patřící jeho státu).
B.5.2.34 GCTC_BM_QueryRules (pravidla pro dotazy)
Systém GCTC pro dotazy vytvoří konzistentní a uživatelsky přívětivý protokol.
Systém GCTC musí zajistit audit sledování pro přepravu zásilky od odesílatele k příjemci.
B.5.2.36 GCTC_BM_Tracking_DataSources (zdroje dat ze sledování)
Systém GCTC musí být způsobilý přijmout informace ze sledování pocházející z různých zdrojů, které používají rozdílné druhy AIT k automatickému zjišťování dat zásilky, a to:
čárový kód (lineární),
RFID.
B.5.2.37 GCTC_BM_UnitsOfMeasure (měrné jednotky)
Systém GCTC bude používat individuální měrné jednotky pro délku, objem, hmotnost a výdejní jednotky pro množství. Všechny rozměry a množství systém přijme v jejich hlášených jednotkách a množstvích; nebudou se provádět žádné převody. Pro měrné a výdejní jednotky budou akceptovány příslušné standardní kódy NATO (viz ACodP-1).
Systém GCTC musí být způsobilý jednoznačně identifikovat každou systémem sledovanou zásilku:
zásilky přijaté se standardním ID zásilky (kód SSCC) musí systém jednoznačně identifikovat podle jejich SSCC;
zásilky přijaté s národním nebo jiným alternativním identifikátorem musí systém jednoznačně identifikovat podle jejich alternativního ID, typu alternativního ID a státu - vlastníka;
zásilky přijaté s oběma typy identifikátorů musí mít jednoznačné obě identity.
Tato kapitola uvádí požadavky na funkční procesy pro přijímání příchozích zpráv.
B.5.3.1 GCTC_BP_INMSG_VALID (validace)
Příchozí zprávy týkající se zásilek budou validovány podle pravidel fungování systému GCTC a chyby budou zaznamenány pro pozdější použití.
B.5.3.2 GCTC_BP_INMSG_CONS (spojování zásilek)
Každá operace spojování bude mít následující povinné údaje:
identifikátor zásilky (buď kód SSCC, nebo kombinaci alternativního ID, alternativního typu ID a státu - vlastníka) – to je rodičovská zásilka, k níž se připojí jeden nebo několik potomků; to může být nějaká existující zásilka nebo nová zásilka;
ČOS 990503 3. vydání Příloha B (normativní)
B-41
datum a čas události (tj. datum a čas, kdy byla aktuální událost sledována – v koordinovaném světovém času);
lokalitu (aktuální místo, kde probíhá sledování);
stát podávající hlášení – požaduje se, aby se předešlo kruhové výměně dat ze sledování;
jeden nebo několik identifikátorů reprezentujících zásilky (stávající nebo nové), které se musí spojit dohromady (např. připojit k rodičovské zásilce).
B.5.3.3 GCTC_BP_INMSG_DECONS (rozdělení zásilky)
Každá operace rozdělení bude mít následující povinné údaje:
identifikátor zásilky (buď kód SSCC, nebo kombinaci alternativního ID, alternativního typu ID a státu - vlastníka) – to je rodičovská zásilka, která musí být rozdělena;
datum a čas události (tj. datum a čas, kdy byla aktuální událost sledována – v koordinovaném světovém času);
lokalitu (aktuální místo, kde probíhá sledování);
stát podávající hlášení – požaduje se, aby se předešlo kruhové výměně dat ze sledování;
žádný nebo několik identifikátorů zásilky (buď kód SSCC, nebo kombinaci alternativního ID, alternativního typu ID a státu - vlastníka) reprezentujících zásilky potomků, které se musí oddělit od rodičovské zásilky. Není-li udána žádná zásilka potomků, předpokládá se úplné rozdělení.
B.5.3.4 GCTC_BP_INMSG_LOC (lokalita)
Zpráva ze sledování bude přijata a zpracována i v případě, bude-li obsahovat identifikátory lokality, které systém GCTC nezná.
Stát - vlastník každé nové zásilky uvedené ve zprávě bude určen jako:
stát - vlastník udaný ve zprávě, pokud je udán;
stát odvozený z kódu SSCC, pokud je to možné;
„neznámý stát“ ve všech ostatních případech.
B.5.3.6 GCTC_BP_INMSG_SSCC (kód SSCC)
Každý kód SSCC zásilky musí splňovat následující podmínky:
formát (18 číslic),
kontrolní číslici pro validaci.
B.5.3.7 GCTC_BP_INMSG_TAG (štítek)
Všechny zprávy o aktivaci a vyřazení štítku musí obsahovat, kromě jiného:
identifikátor AIT (ID štítku),
identifikátor zdroje sledování – to bude ID sledovacího zařízení.
B.5.3.8 GCTC_BP_INMSG_TRACK (trasa)
Každá příchozí zpráva ze sledování bude mít následující povinné informace:
identifikátor zásilky (buď kód SSCC, nebo kombinaci alternativního ID, alternativního typu ID a státu - vlastníka);
ČOS 990503 3. vydání Příloha B (normativní)
B-42
datum a čas události (tj. datum a čas, kdy byla aktuální událost sledována – v koordinovaném světovém času);
lokalitu (aktuální místo, kde probíhá sledování);
stát podávající hlášení – požaduje se, aby se předešlo kruhové výměně dat ze sledování.
ČOS 990503 3. vydání Příloha B (normativní)
B-43
B.5.4 Požadavky na případ užití systému GCTC
OBRÁZEK B.7 – Požadavky na případ užití GCTC
pd Požadavky na případ užití ICTC ICTC_UC_AUT autorizace uživatele
ICTC_UC_CON vytvoření zásilek ICTC_UC_CC obsah zásilek
ICTC_UC_DEC pravidla rozdělení
ICTC_UC_COC pravidla spojení
ICTC_UC_HST záznamy historie událostí
ICTC_UC_XCHG výměna dat z CT se státy
ICTC_UC_TRACK pravidla pro zpracování zpráv ze sledování
ICTC_UC_MAN ruční operace řízení zásilek ICTC_UC_QC dotazy k zásilkám
ICTC_UC_LOC lokality
ICTC_UC_REP hlášení
ICTC_UC_AUDT auditování
ICTC_UC_TAG správa štítku ICTC_UC_ADMIN_SUB
subskripce ICTC_UC_ADMIN administrativní úkoly
ČOS 990503 3. vydání Příloha B (normativní)
B-44
B.5.4.1 GCTC_UC_LOC Locations (lokality)
B.5.4.1.1 GCTC_UC_LOC_NationOwnID (ID státu - vlastníka)
Systém GCTC musí umožnit externím systémům ve zprávách ze sledování používat jejich identifikátory lokalit. Platné identifikátory lokalit pro zprávy ze sledování budou:
GLN (NATO nebo národní);
identifikátor vnitrostátní lokality použitý ve spojení se státem, který podává hlášení;
Každá vnitrostátní lokalita, která má význam pro proces sledování, by měla komunikovat se systémem GCTC za použití svého identifikátoru (může to být GLN nebo ID vnitrostátní lokality) a zeměpisných souřadnic (aby bylo možné sladit určení lokalit podle odhadů blízkého okolí a dešifrování ID lokality). Zpráva o identifikaci lokality (PartyIdentification message) by měla být zaslána přes odpovídající rozhraní systému GCTC.
POZNÁMKA Za normální situace se dává přednost identifikaci lokality v samostatné zprávě před zasláním uvedených údajů v rámci zprávy ze sledování.
Vnitrostátní lokality budou registrovány v systému GCTC pomocí identifikačních zpráv (PartyIdentification messages). Registrační proces bude:
kontrolovat, zda udaný identifikátor lokality (GLN, zeměpisná poloha nebo kombinace vnitrostátního ID a státu) je již systému známa a podle zprávy aktualizovat údaje o této lokalitě (včetně zeměpisné šířky a délky);
není-li lokalita systému dosud známa, bude v něm zaznamenána jako nová lokalita.
B.5.4.1.4 GCTC_UC_LOC_Tracking (sledování vztažené k lokalitě)
Všechny události ze sledování zaznamenané v systému GCTC budou vztaženy k ID lokality, který byl uveden ve zprávě ze sledování.
B.5.4.1.5 GCTC_UC_LOC_TrackUnknown (sledování v neznámé lokalitě)
Když je přijata zpráva ze sledování z neznámé lokality, systém vytvoří novou lokalitu GCTC bez nezbytných údajů o zeměpisné šířce a délce; tyto informace musí být získány později ze zprávy o identifikaci zúčastněné strany (Party Identification message). Pro usnadnění řídicích operací v lokalitě musí být tato lokalita identifikována jako neregistrovaná lokalita.
Každá lokalita bude automaticky označena v systému GCTC jako „sledovací lokalita“, když se poprvé uvede v příchozí zprávě ze sledování.
B.5.4.1.7 GCTC_UC_LOC_VicinityCalcAlg (algoritmus výpočtu blízkého okolí lokality)
Systém GCTC bude provádět výpočet pro určení všech lokalit, které jsou „dostatečně blízko“ uživateli dané lokality, aby mohly být považovány za „stejnou lokalitu“. Tento
ČOS 990503 3. vydání Příloha B (normativní)
B-45
výpočet bude nutný, protože je třeba podporovat a sjednocovat vícečetné kodifikace pro lokality (na národní bázi). Sjednocení se bude provádět podle zeměpisné šířky a délky lokalit a poloměru vzdálenosti pro okolí, který lze nastavit při výpočtu.
B.5.4.1.8 GCTC_UC_LOC_VicinityCalc (výpočet blízkého okolí lokality)
Sjednocení lokalit do jedné podle výpočtu se bude provádět dynamicky (při vznášení dotazu).
B.5.4.1.9 GCTC_UC_LOC_SearchConsignment (vyhledání zásilky v lokalitě)
Dotazy na lokality, kde se zásilka nachází, budou vždy založeny na „blízkosti“. Systém bude zjišťovat pro uživatelem stanovenou lokalitu její odpovídající blízké lokality a bude v nich vyhledávat všechny kvalifikované zásilky.
Pro stanovení blízkých lokalit bude použit algoritmus výpočtu blízkého okolí a nebude se provádět žádná dodatečná filtrace výsledku výpočtu.
B.5.4.1.10 GCTC_UC_LOC_SearchHistory (hledání historie lokalit)
Dotazy na lokality v historii zásilky (tj. ve kterých lokalitách a kdy se zásilka nacházela) se vždy budou provádět následovně:
jestliže uživatelem stanovená lokalita je označena jako „sledovací lokalita“ („Tracking Location“), bude se provádět přesné vyhledání;
v ostatních případech (uživatelem stanovená lokalita není označena jako „sledovací lokalita“) se bude provádět hledání podle „blízkých“ lokalit (tj. systém identifikuje odpovídající lokality v blízkosti lokality stanovené uživatelem a vyhledá všechny kvalifikované zásilky ve všech identifikovaných blízkých lokalitách).
Pro stanovení blízkých lokalit bude použit výpočtový algoritmus a identifikované lokality budou dodatečně filtrovány tak, že budou vzaty v úvahu pouze ty, které jsou označeny jako „sledovací lokalita“.
B.5.4.1.11 GCTC_UC_LOC_PresentationUI (prezentace lokality na rozhraní)
Identifikátor lokality pro expozici na webovém rozhraní uživatelů bude následující:
seznamy zásilek budou vždy používat ID sledovací lokality, který je zaznamenán v systému;
všechny detaily zásilky nebo stránka historie na webovém rozhraní budou používat ID sledovací lokality, který je zaznamenán v systému. Uživatel bude mít také možnost zobrazit seznam odpovídajících blízkých lokalit pro všechny zásilky a historii lokalit (aktuální, z, do, odesílatel, příjemce, lokalita z historie); tento seznam se vytváří podle kódu státu.
Každá zpráva zaslaná systémem GCTC nějakému externímu systému, která má specifikovat lokalitu sledování, bude obsahovat dvě identifikační struktury dotyčné lokality:
ID lokality sledování (může to být každý typ lokality, který je podporován systémem GCTC). To je skutečný identifikátor lokality, který je hlášen při sledování;
ČOS 990503 3. vydání Příloha B (normativní)
B-46
ID vnitrostátní lokality. Vypočítá se podle algoritmu výpočtu blízkých lokalit; použije se ID první zjištěné „blízké“ lokality (pokud existuje) patřící dotyčnému státu.
Hlášení budou používat pro lokality stejný prezentační mechanismus, jaký se využívá pro zprávy (stát se určí buď podle uživatele sytému, který podal hlášení, nebo podle preference uživatele v času podání hlášení).
B.5.4.2 GCTC_UC_AUT User Authorization (autorizace uživatele)
Uživatelé získají přístup k informacím ze sledování zásilky podle svých pověření: uživatel s oprávněním správce, uživatel systému, vnitrostátní uživatel (v rámci státu) nebo uživatel s právem prohlížení či provádění úprav (editace).
B.5.4.2.2 GCTC_UC_AUT_GCTCUser (uživatel systému GCTC)
Systém GCTC musí být schopen rozpoznat uživatele systému (příslušníky organizací, které provozují systém GCTC), aby jim poskytl přístup ke všem zásilkám v systému (bez omezení jen na stát - vlastníka).
B.5.4.2.3 GCTC_UC_AUT_AdminUser (uživatel s oprávněním správce)
Systém GCTC musí být schopen rozpoznat uživatele s oprávněním správce systému: příslušníky organizací, které provozují systém GCTC, mají stejný typ oprávnění jako uživatelé systému a navíc přístup ke správním úkolům.
Systém GCTC musí být schopen rozpoznat vnitrostátní uživatele. Uživatelé tohoto typu budou asociováni se státem definovaným v systému GCTC a jejich přístup k zásilkám bude omezen podle státu, k němuž patří.
B.5.4.2.5 GCTC_UC_AUT_Privileges (výsady)
Každý typ uživatele vnitrostátního nebo uživatele systému bude mít výsady k zobrazení či editaci definované pro ruční operace a vystavené prostřednictvím webového rozhraní. Uživatelé s oprávněním správce budou mít editační výsady ke všem operacím. Práva k zobrazení budou zakazovat přístup ke spojování, rozdělování, generování záznamu AIT a aktualizacím stavu zásilek.
Vytvoření zásilky NATO bude vyžadovat jeden z následujících identifikačních prvků: a) Kód SSCC (bude to pouze „vnitrostátní“ kód SSCC a ne kód SSCC NATO); b) Alternativní identifikátor zásilky tvořený kombinací alternativního ID,
alternativního typu ID a státu - vlastníka.
ČOS 990503 3. vydání Příloha B (normativní)
B-47
B.5.4.3.2 GCTC_UC_CON_CreateModes (způsoby tvorby zásilky)
Vytvoření zásilky NATO může probíhat pouze jedním z následujících způsobů: a) Podle konkrétního požadavku v notifikaci zásilky; b) Podle příchozí zprávy pro neidentifikovanou zásilku. c) Ruční tvorba nové spojené zásilky.
Úroveň zásilky bude nastavena následovně: V případě podle odstavce a):
je-li obsah zásilky uveden v notifikační zprávě, bude úroveň = „0“ (tj. zásilka úrovně 0);
jinak bude úroveň = „-1“ (tj. neurčitá). V případě podle odstavce b): úroveň = „-1“ (tj. neurčitá). V případě podle odstavce c): úroveň = „1“ (tj. spojená).
Systém GCTC musí být schopen generovat unikátní identifikátor zásilek NATO, kterým je kód SSCC, a to na základě GS1 předčíslí organizace přidělené NATO, v souladu se STANAG 2495 (SSCC-18).
Kód SSCC-18 pro zásilku NATO bude mít následující skladbu:
1. číslice – nula nebo dosud nestanovena,
číslice 2 až 8 se použijí pro GS1 předčíslí organizace NC3A,
číslice 9 až 17 tvoří sériové referenční číslo, které se generuje automaticky (pořadové číslo),
číslice 18 je kontrolní číslo (modulo 103) s váhovými faktory 3,1,3,1 … použitými zprava doleva) (viz http://www.gs1uk.org/EANUCC/HTML_Files/Document_Library/Bar_Code/00103/03/03a1-01.html).
Proces notifikace zásilky selže, pokud nastanou následující výjimečné okolnosti: 1. Jsou udány oba ID. Problém bude se zaznamenanou zásilkou (např. zásilka
je identifikována podle jednoho ID a druhý ID je rozdílný). 2. Je uveden obsah existující spojené zásilky. 3. Neplatný kód SSCC (SSCC NATO je stanoven pro novou zásilku).
Při tvorbě zásilky se požaduje stanovit její stát – vlastník v následujících případech: a) Při použití alternativního identifikátoru zásilky; po stanovení státu - vlastníka
se o tom provede záznam;
3)
modulo 10 = zbytek po dělení číslem 10
ČOS 990503 3. vydání Příloha B (normativní)
B-48
b) Při použití kódu SSCC se stát - vlastník odvodí, je-li to možné, z GS1 předčíslí organizace a kódu státu; pokud to možné není, stát - vlastník bude nastaven na „neznámý stát“.
Platný kód státu je:
dvoumístný kód státu podle ISO 3166-1 pouze pro zprávy ze sledování technologií RFID,
„XN“ nebo „XXN“ pro NATO,
třímístný kód státu podle ISO 3166-1,
pro neznámý stát se použije „XX“.
POZNÁMKA ISO 3166-1 používá prefixy (předčíslí, směrové znaky) pro dvou a třípísmenné kódy zemí. Tento ČOS umožňuje použití dvou i třípísmenných kódů včetně použití prefixů. Například výsledný tvar užití prefixu „k“ ke kódu České republiky je kCZ nebo kCZE.
B.5.4.3.7 GCTC_UC_CON_SSCC (kód SSCC zásilky)
Při vytváření zásilky NATO se bude generovat kód SSCC NATO v případě, když není udán národní kód SSCC.
Systém GCTC bude podporovat dva typy zásilek: s obsahem (položkami) a spojené zásilky. Tyto typy se vzájemně vylučují. Zásilka úrovně 0 (neboli přepravní obal) může mít jednu nebo několik asociovaných položek (obsah zásilky).
Systém GCTC bude uznávat obsah zásilky (jednu nebo více položek) takto:
pro zásilky úrovně 0 ve „výměnném způsobu“ (např. pokud daná zásilka již má položky zaznamenané v databázi, existující položky budou vyměněny za nově opatřené položky). U položek nebudou přípustné žádné dílčí změny;
pro původní zásilky, tj. zásilky s neurčitou úrovní, konvenčně označené jako zásilky úrovně „-1“, bude obsah (sada položek) zapsán tak, jak je udán a úroveň zásilky bude nastavena na „0“.
B.5.4.4.2 GCTC_UC_CC_ItemID (ID položky)
Systém GCTC bude přijímat položky označené jedním nebo několika z následujících kódů: RIC, NSN nebo NIC.
B.5.4.5 GCTC_UC_COC Consolidation Rules (pravidla pro spojování zásilek)
Pravidla pro spojování zásilek jsou uvedena níže.
5.4.5.1 GCTC_UC_COC
Systém musí být schopen spojit několik zásilek do jedné spojené zásilky. Tato funkčnost musí být vydávána za zvláštní činnost.
Události týkající se operací spojování a rozdělování by měly být auditované, a to jak pro dotyčné rodičovské zásilky, tak pro zásilky potomků.
ČOS 990503 3. vydání Příloha B (normativní)
B-49
B.5.4.5.3 GCTC_UC_CH_New (nová zásilka)
Z každé zásilky (rodičů nebo potomků) zapojené do vstupní struktury operací spojování i rozdělování, která v současnosti neexistuje v systému GCTC, bude vytvořena jedna zásilka.
U operace spojení se nebudou přijímat žádná opatření vůči zásilkám potomků, které jsou již spojeny se zásilkou rodičů a které nejsou uvedeny v probíhající operaci spojení; tyto zásilky zůstanou spojeny.
Jestliže pro operaci rozdělení nejsou stanoveny žádné identifikátory potomků, bude se předpokládat, že daná zásilka rodičů musí být úplně rozdělena (všichni potomci budou odpojeni).
B.5.4.6.4 GCTC_UC_DEC_Level0 (úroveň 0)
Zásilka úrovně 0 nemůže být rozdělena (v operaci rozdělení taková zásilka nemůže být stanovena jako rodičovská).
Systém GCTC musí být schopen se vypořádat s nesprávným sledem přicházejících požadavků (např. zpráva o vytvoření přijde po zprávě ze sledování téže zásilky).
B.5.4.7.2 GCTC_UC_TRACK_PROC_New (nový proces)
Každá přijatá zpráva ze sledování zásilky, která dosud není systému známa, aktivuje v systému vytvoření záznamu o zásilce.
POZNÁMKA V tomto případě nesmí být udaným identifikátorem zásilky kód SSCC GCTC.
B.5.4.7.3 GCTC_UC_TRACK_RFID_ConsecRead (čtení po sobě jdoucích zpráv RFID)
Pevné čtečky RFID budou průběžně aktivovat zprávy z detekce štítku pro zásilky opatřené štítky, které se nacházejí v detekčním dosahu čtečky. Po sobě jdoucí zprávy z detekce štítku pro stejnou zásilku či štítek vydaný stejným sledovacím zařízením ve stejné lokalitě se odfiltrují tak, že v systému GCTC se uchovají pouze první a poslední zpráva.
B.5.4.8 GCTC_UC_MAN Manual Consignment Management Operations (operace ručního řízení zásilek)
Požadavky systému GCTC na řízení operací se zásilkami prostřednictvím webového rozhraní.
B.5.4.8.1 GCTC_UC_MAN_AITGenerate (generování pomocí AIT)
Systém GCTC poskytne funkci automatického generování vstupních souborů pro proces uvedení štítku do používání u uživatelem vybraných zásilek, které nemají asociovaný identifikátor štítku.
B.5.4.8.2 GCTC_UC_MAN_COC
Dovoluje ruční spojení zásilek pomocí webového rozhraní,
B.5.4.8.3 GCTC_UC_MAN_COC_Rules (pravidla pro ruční spojení zásilek)
Ruční spojení zásilek bude probíhat podle následujících pravidel:
zásilka stanovená jako rodičovská nemůže mít položky (její platná úroveň není 0);
ČOS 990503 3. vydání Příloha B (normativní)
B-51
zásilka stanovená jako zásilka potomků nemůže být částí nějaké spojené zásilky;
zásilky specifikované jako rodičovské a potomků nesmí mít stav „uzavřena“ („Closed“);
v případě, když nová spojená zásilka je vytvořena ručním spojením: 1. Identifikátorem zásilky bude automaticky generovaný kód SSCC GCTC, 2. Státem - vlastníkem bude stát uživatele.
POZNÁMKA I když z hlediska fungování není dovoleno stanovit jako rodičovskou zásilku, která je již částí jiné spojené zásilky (tj. nemůže být zásilkou potomků), bude tato situace tolerována, aby bylo možné provést ruční opravy chyb v hierarchii zásilky.
B.5.4.8.4 GCTC_UC_MAN_DEC (ruční rozdělení)
Povolení ručního rozdělení zásilky pomocí webového rozhraní.
B.5.4.8.5 GCTC_UC_MAN_DEC_Rules (pravidla pro ruční rozdělení zásilek)
Ruční rozdělení zásilek bude probíhat podle následujících pravidel:
zásilka stanovená jako rodičovská nesmí mít úroveň jinou než 0,
zásilka stanovená jako rodičovská nesmí být „uzavřena“ („Closed“).
POZNÁMKA I když z hlediska fungování není dovoleno rozdělit zásilku, která není na nejvyšší úrovni hierarchie, bude tato situace tolerována, aby bylo možné provést ruční opravy chyb v hierarchii zásilky.
B.5.4.8.6 GCTC_UC_MAN_Query (hledání)
Prostřednictvím webového rozhraní může uživatel interaktivně hledat zásilky podle stanovených kritérií.
B.5.4.8.7. GCTC_UC_MAN_Status (stav)
Prostřednictvím webového rozhraní může uživatel nastavit stav zásilky (technický a přepravní).
Systém GCTC poskytne přístup k zobrazení informací o historii zásilky.
B.5.4.9 GCTC_UC_HST Recording History Events (zaznamenávání historie událostí)
Zaznamenávání událostí týkajících se zásilky (z jejího sledování i jiných) se bude řídit podle následujícího souboru požadavků.
B.5.4.9.1 GCTC_UC_HST_TrackingEvent (historie zpráv ze sledování)
Systém GCTC bude provádět chronologické záznamy událostí o zásilce:
detekována v lokalitě (v místě) (DetectedAtLocation),
odeslána (Despatched),
přijata (Received),
hlášení stavu (StatusReported),
aktivace štítku (TagCommissioned),
vyřazení štítku (TagDecommissioned).
ČOS 990503 3. vydání Příloha B (normativní)
B-52
Ve všech případech kromě „detekována v lokalitě“ se uloží pouze nejnovější událost. Ze zpráv o události typu „detekována v lokalitě“ zaslaných systémem RFID se uloží první a poslední (nejnovější) zpráva.
B.5.4.9.2 GCTC_UC_HST_PropagateTrackingEvent (vztahování událostí ze sledování)
Pro usnadnění hlášení informací ze sledování bude systém GCTC vztahovat následující události ze sledování, které přijal o určité zásilce na každou zásilku, jež je její součástí, až po nejnižší úroveň hierarchie:
detekována v lokalitě (v místě) (DetectedAtLocation) – pouze v případě, když není spuštěna detekcí štítku systémem RFID;
odeslána (Despatched);
přijata (Received);
změna ohlášeného stavu (ReportedStatusChange);
ruční změna stavu (ManualStatusChange).
Ekvivalent „vztaženého“ kódu se použije pro auditování v těchto případech:
rodičovská zásilka detekována v lokalitě (v místě) (Parent Detected at Location);
rodičovská zásilka odeslána (ParentDespatched);
rodičovská zásilka přijata (Parent Received);
ohlášená aktualizace stavu rodičovské zásilky (Parent Status Update Reported);
ruční změna stavu rodičovské zásilky (Parent Manual Status Change).
Systém GCTC zaznamená událost aktualizace zásilky.
B.5.4.9.11 GCTC_UC_HST_ConStatusUpdated (aktualizován stav zásilky)
Systém GCTC zaznamená událost aktualizace stavu zásilky. Použijí se samostatné kódy událostí pro ruční změnu stavu a změnu stavu na základě obdržené zprávy.
B.5.4.10 GCTC_UC_XCHG Exchange CT Data With Nations (výměna dat CT se státy)
Následující skupina pravidel se použije, když systém GCTC posílá informace ze sledování vlastnickém státu zásilky.
Systém GCTC bude provádět výměnu údajů o zásilce s jejím vlastnickým státem pouze na základě subskripce. V systému GCTC se předtím musí pro každý stát definovat řádné subskripční informace.
Systém GCTC si může vyměnit data ze sledování zásilky s jejím vlastnickým státem podle následujících scénářů: 1. Když GCTC přijme jeden z následujících typů zpráv ze sledování ze systému CT
(sledování zpráv):
odeslání (Despatch),
příjem (Receive),
přepravní stav (Transport Status),
detekováno v lokalitě (DetectedAtLocation) – ale pouze v případech, když zpráva není aktivována detekcí štítku systémem RFID (protože v takových případech se předpokládá, že RFID nasměroval informace přímo vlastnickému státu).
2. Když GCTC přijme zprávu ze systému CT o spojení nebo rozdělení zásilky. 3. Když GCTC vygeneruje kód SSCC pro národní zásilku. 4. Když uživatel LOGNET aktualizuje stav zásilky. V tomto případě budou vyměněny
příslušné zprávy, pokud také splňují kritéria pro záznam do historie.
B.5.4.10.3 GCTC_UC_XCHG_Rules (pravidla pro výměnu informací)
Když jsou data CT k dispozici pro výměnu s externími systémy, výměna se uskuteční nebo neuskuteční podle následujících pravidel.
1. JESTLIŽE daná zásilka má v databázi kód SSCC, který není kódem SSCC GCTC:
stáhnout stát - vlastníka a operační kód z databáze,
odvodit GS1 předčíslí organizace z kódu SSCC,
odvodit stát na trase ze zprávy (tj. stát, z něhož byla zpráva odeslána),
kód události, který řídí, zda má být vytvořena odchozí zpráva, je zaznamenán v historii dotyčné zásilky. Tentýž kód se použije pro kontrolu, zda existuje subskripce.
1.1 Vyhodnotit potřebu výměny (zaslání) informací v tomto pořadí: 1.1.1 Pokud stát - vlastník či GS1 předčíslí organizace = GCTC – výměnu
neprovádět.
ČOS 990503 3. vydání Příloha B (normativní)
B-54
1.1.2 Pokud stát na trase = stát - vlastník – výměnu neprovádět. 1.1.3 Pokud technický informační systém (prostředek výměny) není definován
na žádné úrovni (ani pro GS1 předčíslí organizace státu - vlastníka, ani pro stát - vlastníka) – výměnu neprovádět.
1.1.4 Pokud pro daný kód události neexistuje subskripce na stát - vlastníka / GS1 předčíslí organizace / operační kód NEBO na stát - vlastníka / operační kód – výměnu neprovádět.
1.2 Pokud podle kroku 1.1 musí být výměna dat uskutečněna, technická stránka (URL apod.) musí být stanovena podle stejných kritérií a ve stejném pořadí jako krok 1.1.3.
2. JINAK (daná zásilka má v databázi kód SSCC GCTC) – proces je podobný procesu v postupu 1, kromě toho, že se na něm nepodílí žádné GS1 předčíslí organizace:
stáhnout stát - vlastníka a operační kód z databáze,
odvodit stát na trase ze zprávy (tj. stát, z něhož byla zpráva odeslána),
kód události, který řídí, zda má být vytvořena odchozí zpráva je zaznamenán v historii dotyčné zásilky. Tentýž kód se použije pro kontrolu, zda existuje subskripce.
2.1 Vyhodnotit potřebu výměny (zaslání) informací v tomto pořadí: 2.1.1 Pokud stát - vlastník = GCTC – výměnu neprovádět. 2.1.2 Pokud stát na trase = stát - vlastník – výměnu neprovádět. 2.1.3 Pokud technický informační systém (prostředek výměny) není definován
(na úrovni státu - vlastníka) – výměnu neprovádět. 2.1.4 Pokud pro daný kód události neexistuje subskripce na stát - vlastníka / operační
kód – výměnu neprovádět. 2.2 Pokud podle kroku 2.1 musí být výměna dat uskutečněna, technická stránka
(URL apod.) musí být stanovena podle stejných kritérií a ve stejném pořadí jako krok 2.1.3.
B.5.4.10.4 GCTC_UC_XCHG_Tracking (výměna dat ze sledování)
Jako odezvu na příchozí zprávu ze sledování nebo na ruční změnu stavu systém GCTC:
pošle ekvivalentní zprávu státu - vlastníku zásilky, pokud je rozdílný od státu, který poslal zprávu a od státu - vlastníka GCTC;
pošle „vztažené“ ekvivalentní zprávy pro každou závislou zásilku jejímu státu – vlastníku, pokud je rozdílný od státu, který poslal zprávu a od státu - vlastníka GCTC.
Poslané zprávy budou mít podobnou strukturu jako příslušná příchozí zpráva ze sledování.
„Vztažené“ zprávy budou obsahovat přídavný element: ID zásilky, u níž nastala dotyčná událost.
B.5.4.10.5 GCTC_UC_XCHG_Consolidation (výměna dat ze spojení zásilky)
Když systém CT, který je majetkem státu podávajícího hlášení hlásí spojení zásilky vlastněné nějakým státem, systém GCTC pošle:
stejný typ zprávy státu - vlastníku, pokud je rozdílný jak od státu podávajícího hlášení, tak od státu - vlastníka systému GCTC;
ČOS 990503 3. vydání Příloha B (normativní)
B-55
zjednodušenou zprávu o spojení pro každou zásilku potomků ze seznamu jejímu státu – vlastníku, pokud je rozdílný jak od státu podávajícího hlášení, tak od státu – vlastníka systému GCTC (tato zpráva bude obsahovat pouze kořenovou zásilku a příslušnou zásilku potomků).
B.5.4.10.6 GCTC_UC_XCHG_Deconsolidation (výměna dat z rozdělení zásilky)
Když systém CT, který je majetkem státu podávajícího hlášení hlásí rozdělení zásilky vlastněné nějakým státem, GCTC pošle:
stejný typ zprávy vlastnickému státu, pokud je rozdílný jak od státu podávajícího hlášení, tak od státu - vlastníka systému GCTC;
zjednodušenou zprávu o rozdělení pro každou zásilku potomků ze seznamu jejímu státu – vlastníku, pokud je rozdílný jak od státu podávajícího hlášení, tak od státu – vlastníka systému GCTC (tato zpráva bude obsahovat pouze kořenovou zásilku a příslušnou zásilku potomků).
B.5.4.10.7 GCTC_UC_XCHG_NewSSCC (výměna dat u nově generovaného SSCC)
Když systém GCTC generuje nový kód SSCC pro zásilku vlastněnou státem B, pošle zprávu státu - vlastníku B v případě, že je odlišný od státu - vlastníka systému GCTC. Zpráva bude notifikačního typu.
B.5.4.11 GCTC_UC_QC Query Consignments (dotaz k zásilkám)
Systém GCTC poskytne schopnost dotazování splňující následující požadavky.
B.5.4.11.1 GCTC_UC_QC_SearchTypes (typy hledání)
Webové rozhraní systému GCTC musí poskytnout rychlé a rozšířené vyhledávání zásilek. Bude orientováno podle:
informací o zásilce,
položek,
činnosti při sledování.
B.5.4.11.2 GCTC_UC_QC_Consignments (dotazy k zásilkám)
Všechny dotazy po rozhraní budou „vracet“ (tj. odpovědi na dotazy budou obsahovat) seznam kvalifikovaných zásilek.
Bude dovoleno zadávat více než jedno kritérium pro vyhledávání.
B.5.4.11.4 GCTC_UC_QC_SingleValue (jedna hodnota)
Každé vyhledávací kritérium bude akceptovat hodnoty 0 nebo 1 (více hodnot není dovoleno).
B.5.4.11.5 GCTC_UC_QC_Generic (obecné)
Vyhledávání podle identifikátorů může být implicitně „obecné vyhledávání“ (tj. typu dotazů „JAKO“).
Vyhledávání podle lokalit bude používat „přesný“ kód lokality (v kombinaci s výpočtem blízkého okolí).
ČOS 990503 3. vydání Příloha B (normativní)
B-56
B.5.4.11.6 GCTC_UC_QC_Strategy (strategie)
Pro dotazy podle složených vyhledávacích kritérií bude systém GCTC používat strategii „A“ (A jako opakovatelná spojka – čili kritérium 1 „A“ kritérium 2 „A“ ...).
B.5.4.11.7 GCTC_UC_QC_Sequencing (seřazení)
Zásilky budou seřazeny podle „data a času poslední události“. Zásilka s poslední událostí bude na prvním místě.
Systém GCTC poskytne infrastrukturu pro podporu seznamu „uložených hledání“ pro uživatele. Každý uživatel bude mít alespoň jeden seznam. Poslední seznam se použije jako „default“ (automaticky nastavený) po přihlášení pro přístup k vyhledávání a stránce s výsledky vyhledávání.
B.5.4.12.4.1 GCTC_UC_ADMIN_SUB_Interface (rozhraní pro subskripce)
Systém GCTC musí vystavit webové rozhraní vnitrostátním a externím systémům pro definování (vytvoření / aktualizaci / vymazání) jejich subskripcí na události v systému GCTC (vytvoření / aktualizaci / vymazání).
Subjekty, které mohou subskribovat události v GCTC jsou: a) Státy. b) Vnitrostátní systémy (společnosti s kódem GS1 předčíslí organizace) v majetku
státu. c) Informační systémy (které nejsou vázány na stát) – například EVE.
Subjekty add a) a b) se vzájemně vylučují (komunikace mohou být stanoveny buď s jednotlivými vnitrostátními systémy určitého státu, nebo se samotným státem).
ČOS 990503 3. vydání Příloha B (normativní)
B-57
B.5.4.12.4.3 GCTC_UC_ADMIN_SUB_Events (subskribované události )
Každý subjekt může subskribovat skupinu událostí v systému GCTC.
B.5.4.12.4.4 GCTC_UC_ADMIN_SUB_Contact (kontakt pro subskripce)
Každý subjekt, který provádí subskripci, musí mít prostředek pro výměnu zpráv definovaný v systému GCTC.
B.5.4.13 GCTC_UC_REP Reports (zprávy)
Systém GCTC umožní vytváření zpráv (hlášení) splňující dále uvedené požadavky.
Systém GCTC musí poskytnout možnosti pro tvorbu a tisk předdefinovaných souborů zpráv.
B.5.4.13.2 GCTC_UC_REP_Query (dotaz pro vyvolání zprávy)
Systém GCTC poskytne odpovídající zprávu pro všechny podporované dotazy.
B.5.4.13.3 GCTC_UC_REP_AITReport (zpráva o připojení médií AIT)
Systém GCTC poskytne zprávu o tom, že obsluha fyzicky připojila média AIT na kontejnery (obaly a nádoby se zásilkami), která obsahují kombinace identifikátorů zásilek NATO (SSCC), alternativního ID zásilky, referenčního ID a ID štítku.
Uvedená zpráva bude vytvořena pro zásilky vybrané uživatelem, které mají asociovaný identifikátor štítku.
B.5.4.13.4 GCTC_UC_REP_Items (zprávy o položkách)
Systém GCTC poskytne funkci hlášení spočívající ve vznesení dotazu k zásilce nebo její položce a vrácení odpovědi.
Kromě záznamů historie událostí systém GCTC přidá, kvůli stanovení odpovědnosti, příslušné vstupy do záznamu (logu) auditu (prostý seznam s původci) následujících činností:
veškerých ručních operací,
operací k identifikaci zúčastněné strany,
správních činností.
Záznam bude obsahovat záznamy o činnostech, odpovědného uživatele nebo systém a datum a čas činnosti.
B.5.4.15 GCTC_UC_TAG Tag Management (správa štítku)
B.5.4.15.1 GCTC_UC_TAG_Record (záznam štítku)
Štítky RFID budou automaticky registrovány v systému GCTC: budou registrovány všechny zprávy ze sledování zásilek obsahující identifikátor štítku, který ještě systém nezná.
ČOS 990503 3. vydání Příloha B (normativní)
B-58
B.5.4.15.2 GCTC_UC_TAG_Status (stav štítku)
Stav štítku (aktivován, vyřazen) bude aktualizován, jakmile systém přijme příslušnou zprávu o aktivaci či vyřazení štítku.
B.5.4.15.3 GCTC_UC_TAG_ListTags (seznam štítků)
Systém GCTC poskytne interaktivní funkci pro určení:
úplného seznamu štítků,
seznamu dostupných štítků (tj. vyřazených štítků),
seznamu používaných štítků (tj. aktivovaných štítků).
Systém GCTC poskytne interaktivní funkci pro určení lokality, v níž se štítek právě nachází. Lokalita bude určena podle nejnovější události z historie daného štítku.
B.5.4.15.5 GCTC_UC_TAG_AtLocation (štítky v lokalitě)
Systém GCTC poskytne interaktivní funkci pro určení seznamu štítků v dané lokalitě. Seznam bude určen podle nejnovějších událostí z historie týkajících se (nějakého) štítku a dané lokality.
B.6. AKTIVITY SYSTÉMU GCTC
B.6.1 Základní operace se zásilkou
Systém GCTC musí poskytnout soubor základních činností se zásilkami:
vytvoření zásilek,
spojení zásilek,
rozdělení zásilek,
sledování zásilek.
B.6.2 Notifikace zásilky
Schéma na obrázku B.8 znázorňuje základní tok pro přijetí notifikace zásilky v systému GCTC. Notifikace zásilky by mohla vyústit v jednu z následujících akcí:
vytvoření nové zásilky NATO, pokud zatím neexistuje, a zaznamenání všech o ní poskytnutých informací (informace technického charakteru anebo o obsahu zásilky). Auditovaná událost bude kód SSCC generován (SSCCGenerated) nebo zásilka vytvořena (ConsignmentCreated) – hodnotí se v uvedeném pořadí;
aktualizace odpovídající zásilky, a to informací o ní technického charakteru, nebo jejího obsahu – případ od případu. Auditovaná událost bude obsah zásilky aktualizován (ConsignmentContentUpdated) nebo zásilka aktualizována (ConsignmentUpdated) – hodnotí se v uvedeném pořadí.
Uvedený tok se může spustit při zpracování notifikační zprávy zásilky přijaté systémem.
ČOS 990503 3. vydání Příloha B (normativní)
B-59
OBRÁZEK B.8 – Proces notifikace zásilky
B.6.3 Vytvoření zásilky NATO
Schéma na obrázku B.9 znázorňuje základní tok vytvoření zásilky NATO v systému GCTC. Tento tok se může spustit:
explicitně vnitrostátním systémem sledování zásilek, když existující zásilka ve výchozím systému musí být známa systému GCTC NATO (z notifikace zásilky);
implicitně prostřednictvím zprávy ze sledování, ze spojení nebo rozdělení zásilky, jestliže zásilka ještě není známa systému GCTC.
Systém CT
Notifikace zásilky
Vytvoření instance historie
Aktualizace záznamu o zásilce
Vytvoření zásilky NATO
Výměna dat ze sledování
zásilky
Vytvoření záznamu o zásilce
s unikátním ID
Generování unikátního ID zásilky NATO
ud Notifikace zásilky
«rozšiřuje»
«vkládá»
«vkládá»
«rozšiřuje»
«vkládá»
«vkládá»
«vkládá»
ČOS 990503 3. vydání Příloha B (normativní)
B-60
OBRÁZEK B.9 – Notifikace zásilky
Konec aktivit
Kód události = SSCC generován nebo zásilka vytvořena
Počátek aktivit
Kontrola existence
zásilky
:Provozní stav kód = neplatný SSCC chyba = pravdivé
ad Notifikace zásilky
Vytvoření zásilky NATO
Aktualizace
záznamu o zásilce
Záznam o obsahu zásilky (položky)
Záznam události a výměny dat
Kód události = obsah zásilky aktualizován nebo zásilka aktualizována – ověření v tomto pořadí
:Provozní stav kód = neplatný obsah spojené zásilky chyba = pravdivé (nastala chyba)
:Provozní stav kód = rozporný ID chyba = pravdivé
Neplatný kód SSCC
Zásilka neexistuje
Chyba
[ano] [ne]
[správně]
[chybně]
Zásilka existuje – ID jsou bezrozporné
Zásilka existuje – ID je rozporný
Zásilka úrovně 1 (z databáze) NEBO obsah není znám (zpráva)
ČOS 990503 3. vydání Příloha B (normativní)
B-61
OBRÁZEK B.10 – Vytvoření zásilky NATO
B.6.3.1 Vytvoření záznamu o zásilce s unikátním ID
POZNÁMKA U vytvoření záznamu o zásilce s unikátním identifikátorem se nejedná o identifikátor zásilky generovaný systémem s použitím pro vnitřní odkazy.
Unikátním identifikátorem může být:
kód SSCC;
unikátní kombinace alternativního ID / typu alternativního ID / státu - vlastníka;
obě výše uvedené možnosti.
Nová zásilka může být vytvořena: a) S minimálním souborem udaných informací (SSCC, stát - vlastník). b) S podrobným souborem informací fyzikálního charakteru (stav, hmotnost, vnější
rozměry, objem, odesílatel, data apod.). c) Výchozí nastavení úrovně zásilky, v průběhu její tvorby, bude „-1“.
POZNÁMKA Tento proces neodpovídá za hierarchii obsažených zásilek a obsahu zásilky (položek).
kód SSCC podle GS1 předčíslí organizace
ICTC
Kód události = SSCC generován nebo zásilka vytvořena
Úspěch
Start
ad Vytvoření zásilky NATO
Generování kódu SSCC
Vytvoření záznamu o zásilce s unikátním ID
Záznam události a výměny dat
Použití odvozeného státu – vlastníka nebo „neznámého“ státu – případ od případu
[SSCC není udán]
Použití zadaného státu - vlastníka
Zásilka je vytvořena s prozatímní úrovní „-1“ (nejistá)
chyba – neplatný
kód SSCC
[SSCC je udán]
[je udán SSCC nebo alt.ID/typ alt.ID/stát]
[ano]
[ne]
ČOS 990503 3. vydání Příloha B (normativní)
B-62
B.6.3.2 Generování kódu SSCC
Kód SSCC-18 pro zásilku NATO bude mít následující skladbu:
1. číslice – nula nebo bude určena (není dosud stanovena),
číslice 2 až 8 se použijí pro GS1 předčíslí organizace NC3A,
číslice 9 až 17 tvoří sériové referenční číslo, které se generuje automaticky (pořadové číslo),
číslice 18 je kontrolní číslo (modulo 10 s váhovými faktory 3,1,3,1 … použitými zprava doleva).
Kód SSCC NATO se vždy bude automaticky generovat. Nikdy se nebude do systému zavádět.
B.6.4 Spojování a rozdělení
Systém GCTC musí poskytnout prostředky pro záznam činností při spojení a rozdělení zásilek. Použitá strategie vezme v úvahu možnost obdržení nesynchronizovaných zpráv a bude zahrnovat vytváření zásilek (když ještě v systému neexistují).
Normální toky:
1. Pokud stanovená rodičovská zásilka v systému existuje, avšak je již spojena na vyšší úrovni zásilky, činnost selže (zpráva je označena pro budoucí urovnání). Pokud stanovená rodičovská zásilka v systému neexistuje, bude vytvořena. Auditovat událost spojení nebo rozdělení pro rodičovskou zásilku.
2. Každá zásilka potomků, která v systému dosud neexistuje, bude vytvořena a: a) Operace spojení: provést spojení a auditovat události spojení (pro potomka). b) Rozdělení: auditovat událost rozdělení pro potomka.
3. Každá zásilka potomků, která v systému již existuje a: a) Není připojena k žádné rodičovské zásilce, v případě operace spojení provést
tuto operaci a auditovat události spojení (pro potomka); b) Je připojena k dané rodičovské zásilce, v případě operace rozdělení provést
tuto operaci a auditovat událost rozdělení (pro potomka).
Výjimečné toky:
4. Každá zásilka potomků, která v systému již existuje a: a) Je již připojena k rodičovské zásilce (ke stejné nebo k jiné), v případě operace
spojení by se systém GCTC mohl pokusit událost urovnat; b) Je připojena k jiné nebo k žádné rodičovské zásilce, v případě operace
rozdělení by se systém GCTC mohl pokusit událost urovnat.
B.6.4.1 Spojení zásilek
Schéma na obrázku B.12 znázorňuje tok operace spojení zásilek. Předpoklady pro operaci spojení jsou:
identifikátor rodičovské zásilky,
jeden nebo několik identifikátorů zásilek potomků, které se budou připojovat k dané kořenové zásilce.
ČOS 990503 3. vydání Příloha B (normativní)
B-63
B.6.4.2 Připojení ke spojené zásilce
Aktivita je vyvolána zásilkou potomka a odpovídá za záznam spojení páru stávající zásilky potomků a dané rodičovské zásilky.
OBRÁZEK B.11 – Spojení a rozdělení zásilky
B.6.4.3 Řešení výjimek při spojení zásilek
Výjimka pro operaci spojení nastane v následujících situacích:
a) Pokud zásilka potomka existuje a je již připojena ke stejné rodičovské zásilce. V tom případě provést „záznam události a výměnu dat“ pro danou zásilku potomka (tím se aktualizuje příslušný záznam v historii a výměna dat se státem - vlastníkem se uskuteční v případě potřeby).
b) Pokud zásilka potomka existuje a je připojena k jiné rodičovské zásilce. V tom případě: 1. Je-li existující spojení pro potomka starší A událost rozdělení pro potomka
se stejnými rodiči není zaznamenána v historii jako nová:
aktualizovat strukturu (odpojit od stávajících rodičů, nezaznamenávat žádnou událost);
připojit k novým rodičům provedením „připojení ke spojené zásilce“ a poté prakticky provést „záznam události a výměnu dat“.
2. Je-li existující spojení pro potomka novější NEBO událost rozdělení pro potomka se stejnými rodiči je již zaznamenána v historii jako nová:
pouze zaznamenat událost spojení pro potomka (bez spojování) provedením „záznamu události a výměny dat“.
Systém CT
Spojení zásilek
Vytvoření instance historie
Rozdělení zásilek
Vytvoření zásilky NATO
Výměna dat ze sledování
zásilky
Vyřešení výjimek při spojení nebo rozdělení zásilek
ud Spojení a rozdělení
«rozšiřuje»
«vkládá»
«vkládá»
«rozšiřuje»
«rozšiřuje»
«rozšiřuje»
«vkládá»
«vkládá»
ČOS 990503 3. vydání Příloha B (normativní)
B-64
OBRÁZEK B.12 – Spojení zásilek
[ID rodičovské zásilky]
ad Spojení zásilek Počátek aktivity
Vytvoření zásilky NATO
:Provozní stav
chyba = pravda (nastala chyba)
kód = neplatné spojení pro úroveň 0
Záznam události a
výměna dat
:Zásilka
úroveň = 1
Smyčka: dané zásilky potomků
:Kontrola
existence zásilky
:Kontrola
existence zásilky
Vytvoření zásilky NATO
Řešení výjimek při spojení
Připojení ke spojené zásilce
:Záznam události
a výměna dat Událost pro zásilku potomka: „Připojena k zásilce“
Auditovaná událost pro rodičovskou (spojenou) zásilku. Kód události = „spojena“ (Consolidated)
[ano]
[ne] Existenc
e Typ rodičovské zásilky [asociované položky
existují (úroveň = 0)] [asociované položky nejsou (úroveň ≠ 0)]
Chyba [ne] [ano
]
Konec aktivity
Konec aktivity
Smyčka
[smyčka]
[konec smyčky]
[potomek neexistuje] [potomek existuje]
[chybně]
[správně]
Potomek není připojen k žádné zásilce
Je předcházející rozdělení stejného páru rodič / potomek již
zaznamenáno v historii potomka?
[ano]
[ne] [ne]
[ano]
Chyba
ČOS 990503 3. vydání Příloha B (normativní)
B-65
B.6.4.4 Rozdělení zásilky
Schéma na obrázku B.13 znázorňuje tok operace rozdělení zásilky. Předpoklady pro operaci rozdělení jsou:
ID rodičovské zásilky,
žádný nebo několik identifikátorů zásilek potomků – pro připojení na danou kořenovou zásilku.
Jestliže nejsou udány žádné zásilky potomků, předpokládá se úplné rozdělení rodičovské zásilky (budou odpojeny všechny přímo spojené zásilky potomků).
ČOS 990503 3. vydání Příloha B (normativní)
B-66
OBRÁZEK B.13 – Rozdělení zásilky
ad Rozdělení zásilky
[ID kořenové zásilky]
Počátek aktivity
Vytvoření zásilky NATO
:Kontrola
existence zásilky
[ano]
[ne] Existenc
e
Zásilka úrovně 0
Chyba
[ne] :Provozní stav chyba = pravda (nastala chyba) kód = neplatné spojení pro úroveň 0
Záznam události a
výměna dat
[ano]
[ne] Událost pro rodičovskou zásilku: Kód události = „rozdělena“
[ano]
Konec aktivity
Smyčka (cyklus): udané zásilky potomků
Smyčka (cyklus): asociované zásilky
potomků
[ne] [ano]
Udané zásilky potomků
:Kontrola
existence zásilky
:Oddělení od spojené zásilky
:Záznam události a výměna dat
Konec aktivity
Nastavení stavu zásilky
Vytvoření zásilky NATO
Oddělení od spojené zásilky
Řešení výjimek z rozdělení
:Záznam události a výměna dat Pro zásilku potomka: Kód události
= „odpojena od zásilky“; nastavit ID rodičovské zásilky
Existence
[ano]
[ne]
[ne]
[ano]
Je zásilka připojena ke správným
rodičům?
Úplné rozdělen
í
[smyčka]
[konec smyčky]
[ne]
[ano]
[ano]
[ne]
Chyba
[smyčka] [konec smyčky]
Pro rodičovskou zásilku: Stav = „uzavřena“
ČOS 990503 3. vydání Příloha B (normativní)
B-67
Vstup: Volitelné: seznam identifikátorů zásilek ke spojení (potomci). Pokud seznam není udán, budou od dané rodičovské zásilky odpojeny všechny připojené zásilky potomků.
B.6.4.5 Oddělení od spojené zásilky
Aktivita, kterou spouští zásilka potomků a která odpovídá za záznam rozdělení páru stávající zásilky potomků a rodičovské zásilky.
B.6.4.6 Řešení výjimek při rozdělení
Výjimka při operaci rozdělení nastane, jestliže:
zásilka potomků existuje a není spojena se žádnou rodičovskou zásilkou. Pak je třeba zaznamenat událost aktuálního rozdělení a v případě potřeby vyměnit o tom data provedením „záznamu události a výměny dat“ (zachovat nejnovější stejnou událost, která již byla auditována);
zásilka potomků existuje a je spojena s jinou rodičovskou zásilkou: Pokud je stávající spojení pro potomka starší, aktualizovat strukturu (odpojit od stávajících rodičů) provedením „oddělení od spojené zásilky“ (poznámka: tato událost nebude zaznamenána v historii, protože se jedná o odvozenou událost). Zaznamenat událost nynějšího rozdělení a provést výměnu odpovídajících informací o ní (provedením „záznamu události a výměny dat“). Pokud je stávající spojení pro potomka novější, pak zaznamenat událost nynějšího rozdělení a provést výměnu odpovídajících informací o ní (provedením „záznamu události a výměny dat“).
B.6.5 Činnosti při sledování zásilek
Tyto činnosti zahrnují všechny aktivity při sledování, které mohou provádět články sledování zásilek, včetně POD a POE. Zahrnují také aktivity během sledování zásilek, které vyvíjejí vnější vnitrostátní systémy nebo systém NATO a jež zahrnují systém GCTC.
B.6.5.1 Správa lokalit vybavených systémem RFID
Schéma na obrázku B.14 popisuje toky událostí, které mohou být spuštěny v lokalitě vybavené technologií RFID (sběrná místa CT). Je vhodné si všimnout, že taková lokalita bude vždy používat AIT, které zaznamenají ID zásilky NATO (SSCC), a proto tento identifikátor bude vždy k dispozici jako součást spouštěcí zprávy.
Procesy, které mohou být iniciovány v takové lokalitě, zahrnují:
štítek zásilky (aktivaci štítku),
detekci zásilky,
vyřazení štítku.
ČOS 990503 3. vydání Příloha B (normativní)
B-68
OBRÁZEK B.14 – Řízení lokality vybavené systémem RFID
B.6.5.2 Správa lokalit nevybavených systémem RFID
Schéma na obrázku B.15 popisuje možné toky událostí, které mohou být spuštěny v lokalitě nevybavené technologií RFID. Předpokládá se, že lokalita bude komunikovat se systémem GCTC prostřednictvím zpráv obsahujících hlášení stavu s informačním obsahem podle tohoto ČOS. Jedná se o oznámení o odeslání zásilky, oznámení o příjmu zásilky a zpráva o stavu přepravy.
POZNÁMKA Uvedené zprávy mohou obsahovat také další podrobnosti ze sledování zásilek.
Systém GCTC zareaguje na tyto zprávy spuštěním příslušných interních akcí:
odeslání zásilky,
příjem zásilky,
aktualizace stavu zásilky.
ud Lokalita vybavená RFID
Sběrné místo CT
Štítek zásilky
«rozšiřuje»
Detekce zásilky
Vyřazení štítku
Systém CT
Vytvoření instance historie
Aktualizace záznamu o zásilce
Validace požadavk
u
Záznam události
ze sledování
Vytvoření zásilky NATO
Správa štítků Výměna dat
ze sledování
Sledování zásilek pomocí systému RFID
Směrování zpráv RFID
ze sledování
«vkládá»
«vkládá»
«vkládá»
«vkládá»
«rozšiřuje»
«rozšiřuje»
«vkládá»
«vkládá»
«rozšiřuje»
«rozšiřuje»
«rozšiřuje» «vkládá» «vkládá»
«vkládá»
«vkládá»
«vkládá»
«vkládá»
«vkládá»
«rozšiřuje»
Systém RFID
ČOS 990503 3. vydání Příloha B (normativní)
B-69
OBRÁZEK B.15 – Řízení lokality nevybavené systémem RFID
B.6.6 Zpracování zpráv ze sledování zásilek
Obrázek B.16 znázorňuje akce, které se spustí při zpracování zprávy ze sledování zásilky. Předpokládá se, že při procesu zaznamenání (logování) zprávy bylo provedeno veškeré předběžné zpracování a validace a že tento proces je průběžně monitorován pro zaznamenané zprávy v „nevyřízeném“ stavu, kde je na prvním místě nejstarší zpráva (viz kapitoly o zpracování logovaných zpráv a logování příchozích zpráv).
ud Lokalita nevybavená RFID
Článek CT
Příjem zásilky
«rozšiřuje»
Detekce zásilky
Rozdělení zásilky
Systém CT
Vytvoření instance historie
Aktualizace záznamu o zásilce
Validace požadavku
Záznam události
ze sledování
Vytvoření zásilky NATO
Výměna dat ze
sledování
«vkládá»
«vkládá»
«vkládá»
«vkládá»
«rozšiřuje» «rozšiřuje»
«vkládá»
«vkládá»
«rozšiřuje»
«rozšiřuje»
«rozšiřuje»
«vkládá»
«vkládá»
«vkládá»
«vkládá»
«vkládá»
Aktualizace stavu zásilky POD
POE
«rozšiřuje»
«rozšiřuje»
ČOS 990503 3. vydání Příloha B (normativní)
B-70
OBRÁZEK B.16 – Zpracování zpráv ze sledování
Počátek aktivity
[Zásilka existuje]
ad Zpracování zpráv ze sledování
Kontrola existence
zásilky
Vytvoření zásilky NATO
Kontrola duplicitního sledování události
[Zásilka neexistuje]
Chyba (neplatný SSCC)
[neplatný SSCC]
[ano]
Spuštěno pro: zásilka
Přepravní stav = hlášený přepravní stav Z = aktuální lokalita ETA = hlášená ETA (odhadovaná doba příjezdu) Do = další uzel Fyzický stav = hlášený stav
Spuštěno pro: zásilka Z = aktuální lokalita Přepravní stav = přijata nebo doručena Fyzický stav = hlášený stav
Spuštěno pro: zásilka
Z = aktuální lokalita ID AIT = hlášený ID štítku Přepravní stav = v lokalitě
Spuštěno pro: zásilka
Z = aktuální lokalita ID AIT = hlášený ID štítku
Spuštěno pro: zásilka
Z = aktuální lokalita ID AIT = nulový (žádný)
Spuštěno pro: zásilka
Z = aktuální lokalita Přepravní stav = odeslána ETA = hlášená ETA (odhadovaná doba příjezdu) Do = další uzel Fyzický stav = hlášený stav
Proces vyřazení štítku
Rozšíření aktuální lokality
Rozšíření události
sledování
Konec aktivity
Nová zpráva
[hlášena změna stavu]
Sledování události
[přijata]
[odeslána]
[detekována v lokalitě]
[štítek aktivován]
[štítek vyřazen]
[ne]
ČOS 990503 3. vydání Příloha B (normativní)
B-71
B.6.6.1 Kontrola duplicitního sledování události
Zkontrolovat historii akcí, které byly spuštěny u dané zásilky pro již existující vstup téže události ze sledování. Duplikace budou zjištěny podle:
kombinace kódu události, lokality a zdroje (původce) sledování – v případě událostí detekovaných v lokalitě;
kombinace kódu události a lokality – v případě všech ostatních událostí ze sledování.
Jestliže takový vstup ještě neexistuje, zpráva bude považována za novou zprávu tohoto typu a bude normálně zpracována.
Jestliže takový vstup již existuje a je starší než aktuální událost, zpráva bude považována za novou zprávu s výjimkou: když existující vstupy historie budou aktualizovány rychleji než vytvoření nového vstupu.
Jestliže takový vstup již existuje a je novější než aktuální událost, zpráva ze sledování zásilky nebude zpracována.
B.6.6.2 Proces vyřazení štítku
Žádný takový proces není.
B.6.6.3 Rozšíření (předávání) stávající lokality
Aktualizovat stávající lokalitu a datum a čas poslední události pro všechny závislé zásilky.
B.6.7 Řízení zásilky
Schéma na obrázku B.17 znázorňuje ruční řízení operací se zásilkami, které může spustit uživatel sítě LOGNET, aby se v systému GCTC provedlo spojení nebo rozdělení zásilek nebo aktualizoval stav zásilky.
ČOS 990503 3. vydání Příloha B (normativní)
B-72
OBRÁZEK B.17 – Řízení zásilky
B.6.8 Dotaz na data zásilky
Schéma na obrázku B.18 znázorňuje typy dotazů, které lze vznášet k datům v systému GCTC.
ud Řízení zásilky
Uživatel LOGNET CT
Systém CT
Vytvoření instance historie
Prohlížení zásilek
Vytvoření zásilky NATO
«rozšiřuje»
«vkládá»
«vkládá»
Ruční aktualizace stavu zásilky
Dotaz na data o zásilce
Spojení zásilek
Ruční spojení
Řízení zásilek
Zpracování zpráv
Autorizace uživatele
«rozšiřuje»
«vkládá»
Rozdělení zásilky «rozšiřuje
»
«rozšiřuje»
Výměna dat ze sledování
«realizuje»
«realizuje»
«realizuje»
«realizuje»
«vkládá»
«vkládá»
«vkládá»
«rozšiřuje» «realizuje»
«realizuje»
«rozšiřuje»
Ruční rozdělení
Generování dat AIT
Prohlížení záznamů o chybách
ČOS 990503 3. vydání Příloha B (normativní)
B-73
OBRÁZEK B.18 – Dotazy na data zásilky
B.6.9 Výměna dat ze sledování zásilky
Jedná se o proces odpovědný za generování a zaslání důležitých událostí ze sledování zásilky a jiných událostí zúčastněným informačním systémům.
Zprávy budou generovány pro subskribované strany (definované předtím v nastavení) podle relevantních událostí, které zajímají zúčastněnou stranu. Touto stranou může být:
národní subskripce, což může být vnitrostátní systém sledování zásilek státu, který je vlastníkem zásilky;
subskripce informačního systému, což může být informační systém zapojený do výměny dat ze sledování zásilek se systémem GCTC.
OBRÁZEK B.19 – Výměna dat ze sledování zásilky
ud Výměna dat CT
Informační systém (IS)
Systém CT
Výměna dat ze sledování zásilky
NATIES
Výměna dat ze sledování zásilky se
subskribovaným IS
Výměna dat ze sledování zásilky
se státem Trasování zpráv RFID ze
sledování zásilky
«rozšiřuje»
«rozšiřuje»
ud Dotazy na data zásilky
Uživatel LOGNET CT
Systém CT
Dotaz na data zásilky
Řízení zásilek
Prohlížení zásilek
«rozšiřuje»
Dotaz na informace o zásilce
Dotaz na aktivitu zásilky
Dotaz na identifikátory
položek
«rozšiřuje»
«rozšiřuje»
«rozšiřuje»
«rozšiřuje»
ČOS 990503 3. vydání Příloha B (normativní)
B-74
B.6.10 Administrativní úkoly
Schéma na obrázku B.20 znázorňuje souhrnný přehled požadovaných administrativních úkolů v systému GCTC.
OBRÁZEK B.20 – Administrativní úkoly
B.6.11Zpracování příchozích zpráv
Tato kapitola popisuje proces přijetí příchozích zpráv do systému, jejich validaci a zpracování podle business rules systému GCTC.
ud Administrativní úkoly
Uživatel LOGNET CT
Správa ICTC
Čištění údajů o zásilce
Správa informací o lokalitě
Údržba subskripcí
Údržba uživatelů
«rozšiřuje»
«rozšiřuje»
«rozšiřuje»
«rozšiřuje»
ČOS 990503 3. vydání Příloha B (normativní)
B-75
OBRÁZEK B.21 - Zpracování příchozích zpráv
B.6.12 Validace lokalit
Ke kontrole platnosti (validaci) udané lokality (lokalit): Pokud systém ještě lokalitu nezná, vytvořit lokalitu systému GCTC, ale neudávat její zeměpisné souřadnice. Chybějící údaje by měla dodat opožděná identifikační zpráva zúčastněné strany nebo by měly být doplněny ručně. Lokalitu označit jako „sledovací“.
Počátek aktivity
Validace SSCC a odvození státu
- vlastníka
Zpracování zpráv ze sledování
Validace složek zprávy
Validace zásilek potomků
Validace lokalit
[kód SSCC]
Identifikace zásilky
ad Zpracování příchozích zpráv
[Alternativní ID zásilky]
Spojení zásilek Rozdělení zásilky
Notifikace zásilky
Kód události
[Událost ze sledování] [Spojeno] [Rozděleno]
[Notifikace zásilky]
Konec aktivity
ČOS 990503 3. vydání Příloha B (normativní)
B-76
B.6.13 Validace zásilek potomků
Vybrat z položek seznamu zásilek zásilky potomků a pro každou z nich:
je-li udán kód SSCC, ověřit správnost SSCC a vypsat (odvodit) z něho stát - vlastníka zásilky;
je-li zjištěna chyba, zaznamenat ji: kód chyby = neplatný kód SSCC (SSCCInvalid).
B.6.14 Validace složek zprávy
Budou provedeny všechny možné validace a u každé zprávy budou všechny zjištěné chyby shromážděny a zaznamenány (logovány). Validační pravidla:
ověření je úspěšné, jestliže jsou splněny všechny požadavky na obsah zprávy podle jejího typu (viz GCTC_BP_INMSG requirements);
ověření je neúspěšné v případě, že chybí některé informace (ErrorCodes = MissingInformation).
B.6.15 Společné aktivity
B.6.15.1 Kontrola existence zásilky
Existence se bude kontrolovat podle kritérií v následujícím pořadí:
kombinace alternativního ID / alternativního typu / státu - vlastníka, jsou-li tyto udány;
kód SSCC, je-li udán.
Výsledkem kontroly bude:
zásilka neexistuje, nebo
zásilka existuje, nebo
zásilka existuje, ale má rozporné identifikátory, nebo
kód SSCC je neplatný.
Použije se následující logika. 1. JESTLI je udán alternativní ID – kontrolovat existenci JESTLI existuje záznam je-li udán kód SSCC JESTLI zjištěný záznam již obsahuje SSCC
zkontrolovat, jestli dva kódy SSCC jsou shodné – výsledkem je „zásilka existuje“ („Consignment Exists“), nebo „rozporné identifikátory“ („Conflicting IDs“)
JINAK (není zaznamenán žádný SSCC) zkontrolovat, že nový SSCC není SSCC GCTC (je-li to tak, výsledkem je „zásilka existuje“) a že již neexistuje v databázi (je-li to tak, výsledkem je „neplatný SSCC“)
JINAK (není zaznamenán žádný SSCC) – „zásilka existuje“ JINAK (záznam neexistuje) je-li udán kód SSCC
zkontrolovat, že nový SSCC není SSCC GCTC (je-li to tak, výsledkem je „zásilka neexistuje“, není-li to tak, tj. nový SSCC = SSCC GCTC, výsledkem je „neplatný SSCC“)
jinak (není udán žádný SSCC) - vrátit (tj. výsledkem je) „zásilka neexistuje“.
ČOS 990503 3. vydání Příloha B (normativní)
B-77
2. JINAK (alternativní ID není udán, SSCC je udán) – kontrolovat existenci JESTLI záznam existuje – vrátit „zásilka existuje“ JINAK
zkontrolovat, že nový SSCC není SSCC GCTC (je-li to tak, výsledkem je „zásilka neexistuje“, není-li to tak, tj. nový SSCC = SSCC GCTC, výsledkem je „neplatný SSCC“).
B.6.15.2 Vytvoření zásilky NATO
Představuje proces vytvoření samostatné zásilky NATO v systému GCTC. Proces zahrnuje generování nového kódu SSCC, jestliže není udán, vytvoření záznamu o zásilce a záznam těchto událostí a rovněž výměnu dat s příslušnými systémy.
B.6.15.3 Výměna dat ze sledování zásilky se státem
Jedná se o výměnu informací o události pro danou zásilku. Výměna se požaduje, když vlastník zásilky je jiný než systém GCTC (stát - vlastník je zaznamenán v GCTC)
A
systém státu - vlastníka je subskribován pro danou zásilku NEBO
stát - vlastník je subskribován pro danou zásilku a je jiný než stát podávající hlášení.
Výměna informací o událostech ze sledování se promítá do následujících činností:
výměna informací o spouštěcí události pro kořenovou zásilku,
výměna informací o spouštěcí události jako „předávané“ události na všechny zásilky závislé na kořenové zásilce, pokud existují (Poznámka: jedná se o „předávanou“ událost, poněvadž není spuštěna přímo pro závislé zásilky, ale je na ně vztažena na základě sestavení zásilky).
Výměna informací o předané události ze sledování pro všechny závislé zásilky znamená:
identifikaci všech zásilek závislých na dané kořenové zásilce,
výměnu informací pro každou závislou zásilku s jejím vlastnickým státem.
Seznam událostí ze sledování, které vyžadují předání, obnáší:
detekce v lokalitě (DetectAtLocation),
odeslána (zásilka) – kód události pro závislé zásilky = Despatched,
přijata (zásilka) – kód události pro závislé zásilky = Received,
hlášena změna stavu (ReportedStatusChange),
ruční změna stavu (ManualStatusChange).
Zpráva o předaných událostech bude podobná zprávě o spuštěné události, ale nahraje jak ID hlášené zásilky, tak ID zásilky, která spustila událost.
Nepředávané události jsou:
štítek aktivován,
štítek vyřazen.
Výměna informací o událostech spojení a rozdělení zásilek:
u kořenové zásilky bude vyměněna originální zpráva;
u zásilek potomků zapojených do operace bude vyměněna zjednodušená verze originální zprávy pouze s kořenovou a danou zásilkou potomka
ČOS 990503 3. vydání Příloha B (normativní)
B-78
(Poznámka: Pro každou zapojenou zásilku potomka bude vyměněna, v případě potřeby, jedna zpráva).
B.6.15.4 Záznam události a výměna dat 1. Vytvořit instanci historie pro události bez sledování:
vytvořena (zásilka),
aktualizována,
aktualizován obsah,
spojena (pro úroveň rodičů),
rozdělena (pro úroveň rodičů),
připojena k zásilce (pro úroveň potomků; zaznamenat také ID rodičů),
odpojena od zásilky (pro úroveň potomků; zaznamenat také ID rodičů),
zásilka vytvořena,
kód SSCC generován.
U událostí týkajících se spojení zásilek (spojena, rozdělena, připojena k zásilce, odpojena od zásilky) se v historii uchová pouze nejnovější událost z kombinace událostí pro danou zásilku. To se projeví následovně:
na úrovni zásilky potomků, pokud pro odpovídající událost (připojena k zásilce, odpojena od zásilky) a kombinaci stávající zásilky potomka a dané rodičovské zásilky již existuje auditovaný vstup (tj. záznam události), bude provedena aktualizace, jestliže je tato událost starší, nebo nebude provedena aktualizace, jestliže je novější než stávající událost. Pokud dosud neexistuje, bude vytvořen nový takový vstup;
na úrovni rodičovské zásilky, pokud pro odpovídající událost (připojena k zásilce, odpojena od zásilky) existuje auditovaný vstup, bude provedena aktualizace, jestliže je tato událost starší nebo nebude provedena aktualizace, jestliže je novější než stávající událost. Pokud dosud neexistuje, bude vytvořen nový takový vstup.
2. Je-li auditovaný vstup aktualizován nebo vytvořen, bude provedena výměna dat se státem (viz článek B.6.15.3).
B.6.15.5 Předání události ze sledování
Tato aktivita je odpovědná za tvorbu a aktualizaci historie a výměnu dat ze sledování dané zásilky a všech na ní závislých zásilek: 1. Přihlásit spouštěcí událost pro „spuštěno pro: zásilka“ (viz obrázek B.16). To bude
znamenat vytvořit instanci historie (nebo provést aktualizaci, pokud odpovídající událost již existuje; viz kontrola duplicitního sledování události na zjištěných příslušných vstupech podle článku B.6.6.1).
2. Přihlásit spouštěcí událost jako „předanou“ událost pro každou ze zásilek závislých na „spuštěno pro: zásilka“. (Poznámka: jedná se o „předanou“ událost, poněvadž není spuštěna přímo pro závislé zásilky, ale podle předpokladu je pro ně auditována). Instance historie bude zahrnovat u těchto zásilek také ID kořenové zásilky, která „předala“ událost.
3. V případě potřeby vyměnit data ze sledování se státem pro rodičovskou a všechny na ní závislé zásilky.
Seznam událostí ze sledování, u nichž je nutné předání a příslušná „předaná“ událost, která bude auditovaná pro závislé zásilky, zahrnuje:
ČOS 990503 3. vydání Příloha B (normativní)
B-79
detekce v lokalitě (DetectAtLocation) – kód události pro závislé zásilky = ParentDetectAtLocation (detekce rodičovské zásilky v lokalitě),
odeslána (zásilka) – kód události pro závislé zásilky = ParentDespatched,
přijata (zásilka) – kód události pro závislé zásilky = ParentReceived,
hlášená změna stavu – kód události pro závislé zásilky = ParentReportedStatusChange,
ruční změna stavu – kód události pro závislé zásilky = ParentStatusChange.
Nepředávané události jsou:
štítek aktivován,
štítek vyřazen.
Vstup:
identifikátor „spuštěno pro: zásilka“,
kód události.
B.6.15.6 Kontrola unikátnosti podle udaného identifikátoru
Unikátnost bude kontrolována podle:
kódu SSCC, je-li udán;
kombinace alternativní ID / alternativní typ / stát - vlastník, jsou-li udány.
POZNÁMKA Mohou nastat případy, že jsou k dispozici údaje pro obě možnosti a unikátnost je potvrzena u každé z nich.
B.6.15.7 Záznam obsahu zásilky (položek zásilky)
Je-li udán obsah zásilky, pak je třeba odstranit všechny asociované položky (jsou-li) a nahradit je nově poskytnutými položkami.
B.6.15.8 Validace SSCC a odvození státu - vlastníka
Bude validován kód SSCC a z něho bude odvozen stát - vlastník. (Poznámka: Odvozený stát by se použil pouze pro vytvoření zásilky v případě, že ve zprávě nebyl jednoznačně uveden stát - vlastník).
Vstup:
kód SSCC – je požadován,
stát - vlastník – nepovinný.
Výstup:
stát - vlastník,
chybový kód: úspěch (chyba nezjištěna) nebo neplatný kód SSCC.
Pracovní režimy: 1. Je udán stát – vlastník. Tento stát musí mít platnou subskripci. Výstup: stát -
vlastník. 2. Není udán stát - vlastník. Z kódu SSCC určit GS1 předčíslí organizace a s ní
spojený stát. Výsledek porovnat s GS1 předčíslími organizací registrovaných v systému GCTC. Je-li tento postup úspěšný, ve výstupu uvést takto odvozený stát - vlastník. Je-li tento postup bezvýsledný, ve výstupu uvést kód „neznámý stát“. (Stát uvedený ve výstupu se použije pro nastavení státu - vlastníka nové zásilky).
ČOS 990503 3. vydání Příloha B (normativní)
B-80
B.7 LOGICKÝ PŘEHLED SYSTÉMU GCTC
B.7.1 Zprávy GCTC
Systém GCTC musí mít otevřená rozhraní pro:
zprávy ze sledování (vstup),
zprávy s dotazy (vstup) a odpověďmi na dotazy (výstup) pro dotazy na stav zásilky podle stanovených kritérií,
zprávy pro výměnu dat (výstup).
Minimální soubor zpráv, jimž má být systém GCTC otevřen za účelem sledování je:
a) Hlášení o přepravě
Může se použít pro:
avízo odeslání, avízo příjmu, přepravního stavu;
detekci štítku (a dokonce i pro přidělení nebo vyřazení štítku).
POZNÁMKA Pro každou uvedenou událost může být určena samostatná zpráva, ale jsou možné poměrně velké duplikace z hlediska obsahu a funkce.
Všechny tyto zprávy budou mít:
povinné společné části jako totožnost zásilky,
nepovinné společné části (např. zpráva o přepravním stavu bude vždy obsahovat (hlásit) přepravní stav. Ale přepravní stav by také mohlo obsahovat avízo příjmu - např. v hlášení, že zásilka je „přijata“ by se současně mohlo uvést, že tato zásilka je „poškozena“).
b) Notifikace zásilky
Akceptuje se všeobecná informace o zásilce a nepovinně obsah zásilky (informace o položkách mohou být uvedeny buď souhrnně, nebo podrobně).
c) Spojení a rozdělení zásilky
Akceptuje se struktura rodiče / seznam potomků, v obou částech s použitím totožnosti zásilky.
ČOS 990503 3. vydání Příloha B (normativní)
B-81
OBRÁZEK B.22 – Zprávy v systému GCTC
Typ záhlaví zprávy
1
cd Zprávy v systému GCTC
+ typ hlášení: typ ohlašovací zpráva
Typ zpráva ze sledování
Sledování NATO
+ stát - vlastník: 2 znaky + zeměpisná šířka: double + zeměpisná délka: double
Typ identifikace strany
+ SSCC: 18 znaků + alternativní ID: typ alternat. ID + datum a čas události: čas. razítko
Typ notifikace zásilky Typ spojení zásilky
+ SSCC: 18 znaků + alternat. ID: typ alternat. ID
«volba» Typ identity zásilky
+ GLN: 13 znaků + typ ID národní lokality:celé číslo + GeoLoc: znaky
«volba» Typ vnitrostátní lokalita
+ operační kód: znaky (???) [0..1] + požad. datum a čas dodání: [0..1] + referenční ID: celé číslo + popis: znaky
Typ informace o zásilce
+ GLN: 13 znaků + typ ID národní lokality: celé číslo + zeměpisná šířka: double + zeměpisná délka: double
«volba» Typ lokalita
+ RIC: znaky (???) + NIC: typ NIC + NSN: znaky (???) + popis: popisný typ + referenční ID: znaky (???)
Typ obsah zásilky
+ předpokládaný čas příjezdu: celé číslo + ID AIT: celé číslo + ID sledovacího zařízení: celé číslo
Typ informace ze sledování
+ fyzický stav: typ fyzický stav + přepravní stav: typ přepravní stav
- DV: (doručena) - AT: (čeká na přepravu) - RT: (připravená na přepravu) - DL: (zpožděná) - OT: (včasná) - MS: (nezvěstná) - ER: (uspíšená) - AI: (čeká na další instrukce) - LT: (ztracena) - CL: (uzavřena)
Typ přepravní stav
ČOS 990503 3. vydání Příloha B (normativní)
B-83
B.7.2 Třídy GCTC
OBRÁZEK B.23 – Třídy sledování zásilky
cd Třídy sledování zásilky - globální lokalizační číslo (GLN): 13
znaků
Globální lokalita
- ID vnitrostátní lokality: celé číslo
Vnitrostátní lokalita - popis: popisný typ - stát - vlastník: 2 znaky - zeměpisná šířka: double - zeměpisná délka: double - sledovací lokalita: boolean
Lokalita ICTC
- «PK» SSCC: celé číslo - alternativní ID: celé číslo - typ alternativního ID: typ identity zásilky - referenční ID: 30 znaků - «FK» stát - vlastník: 2 znaky - operační kód: znaky (xx) - popis: popisný typ - AIT_ID: celé číslo - AIT_ID_2: celé číslo - úroveň nula: boolean - «FK» stav přesunu : 2 znaky - «FK» fyzikální stav : 2 znaky - požadovaný termín dodání: datum a čas - odhadovaná doba příjezdu (ETA): datum a čas - priorita: celé číslo - třída HAZMAT (nebezpečný materiál): znaky (YY) - DT poslední události: datum a čas
Zásilka
- «FK» kód události: typ kód události - DT události: datum a čas - ID zdroje sledování: znaky (??) - «FK» ID rodičovské zásilky: celé číslo - «FK» stav přesunu : 2 znaky - «FK» fyzikální stav : 2 znaky - AIT_ID: celé číslo
Instance historie zásilky
Spojení zásilky
+ GLN odesílatele
+ do
GLN
+ z GLN
+ GLN příjemce
+ GLN stávající lokality
+ GLN lokality události
1 0..*
+ ID rodičů
+ ID potomka
- «FK» kód události: typ kód události - popis: popisný typ
Sledovaná událost
- «PK» ID obsahu: číslice - RIC: celé číslo - NIC: celé číslo - NSN: celé číslo - popis ICTC: popisný typ - popis NIC: popisný typ - množství: celé číslo - referenční ID: celé číslo
Položky ICTC
0..n
- «FK» kód události: typ kód události - popis: popisný typ
Fyzikální stav - «PK» stav: typ přepravní stav - popis: popisný typ
Přepravní stav
- délkový typ: měrná jednotka délky - hmotnostní typ: měrná jednotka hmotnosti - objemový typ: měrná jednotka objemu
Tato kapitola uvádí doplňkové požadavky na systém GCTC, resp. způsob jejich zápisu. Každý požadavek má unikátní identifikátor (ID). Tento identifikátor má následující skladbu:
GCTC_XXXX_[volný formát] kde
XXXX je zkratka pro kategorii doplňkového požadavku.
Jednotlivé požadavky v dané kategorii jsou stanoveny ve volném formátu.
B.7.8 GCTC_DC: Design Constraints (omezení v návrhu systému)
B.7.8.1 GCTC_DC_OO
Režim asynchronního přenosu (ATM) má být navržen pomocí objektově orientované (OO) metodologie.
*
cd Státy a uživatelé
- operační kód: znaky (xx)
Subskripce
- «PK» ID státu (dle ISO): 2 znaky - směrový kód: 3 znaky
Státy - «PK» ID uživatele: znaky (??) - uživatel systému: boolean - editace dovolena: boolean - «FK» stát - vlastník: 2 znaky
Uživatel ICTC
0..*
- typ výměny: celé číslo - technické spojení: celé číslo
Technický informační systém
- «PK» GS1 předčíslí organ.: 7 znaků
GS1 předčíslí organizace
- ID systému: celé číslo
Subskripce systému
- «PK» kód události: typ kód události - popis: popisný typ
Třídy ICTC: sledované události
0..* 0..*
0..*
ČOS 990503 3. vydání Příloha B (normativní)
B-85
B.7.9 GCTC_UDH: User Documentation and Online Help (uživatelská dokumentace a nápověda online)
B.7.9.1 GCTC_UDH_Use_Help_System (použití systému nápovědy)
Systém GCTC by měl používat uživatelskou dokumentaci a online nápovědu RoboHelp, kterou používají jiné moduly služeb LOGFAS. Systém nápovědy by měl poskytnout uživateli kontextovou nápovědu.
B.7.9.2 GCTC_UDH_User_Manual (příručka uživatele)
Musí být k dispozici návod pro uživatele systému GCTC, který má:
popsat každou hlavní funkci včetně vzájemných vazeb a logického pořadí,
upřednostňovat aktivní popis (např. uvádět četné příklady, dávat přednost obrázkům před zdlouhavým popisem),
popsat rozhraní.
B.7.10GCTC_TRA: Training-related requirements (požadavky na školení)
Významným požadavkem je, aby školicí (tréninkový) systém pomáhal zvládnout proces sledování zásilek s použitím snadno pochopitelných a ovládaných rozhraní a chování.
B.7.11 GCTC_PER: Personnel-related requirements (požadavky na obsluhu)
Neuplatňují se.
B.7.12 GCTC_CRR: Computer Resource Requirements (požadavky na počítačové prostředky)
B.7.12.4 GCTC_CRR_SoftwareNU (software charakteru NATO UNCLASSIFIED)
Požadavky na software charakteru NATO UNCLASSIFIED.
B.7.13GCTC_SR: Security Requirements (požadavky na zabezpečení)
B.7.13.1 GCTC_SR_LOGIN (přístupové heslo)
Přístup do systému smí mít pouze ověřený uživatel.
B.7.13.2 GCTC_SR_NUData (data charakteru NATO UNCLASSIFIED)
Data označená jako NATO UNCLASSIFIED (NU) nesmí obsahovat žádnou informaci, která umožní zjištění delikátního obsahu zásilky.
ČOS 990503 3. vydání Příloha B (normativní)
B-86
B.7.13.3 GCTC_SR_NUNS (přístup k utajovaným datům ze strany dat charakteru NATO UNCLASSIFIED )
Utajovaná data NATO nesmí být v žádném případě přístupná ze strany dat charakteru NATO UNCLASSIFIED.
B.7.13.4 GCTC_SR_NUNSMethod (metoda převodu mezi utajovanými daty a daty charakteru NATO UNCLASSIFIED)
Data mohou být převedena pouze z charakteru NATO UNCLASSIFIED (UN) do utajovaných (NS) pomocí mechanismu sdílení adresářů. Není dovolen žádný přesun dat z NS do NU.
Formáty všech zpráv ze systému RFID budou vyhovovat nové zprávě GCTC „hlášení o přepravě“. Minimální požadované informace jsou:
ID štítku (s výjimkou skenů čárových kódů),
ID zdroje sledování (ID zařízení),
kód SSCC zásilky,
ID lokality,
datum a čas události (v koordinovaném světovém čase).
B.7.14.6 GCTC_PC_RFID_TagInfo (informace na štítku)
Systém RFID musí být schopen přijmout následující informace o zásilce z vnitrostátního systému a ze systému GCTC:
kód SSCC zásilky,
směrový kód.
Systém RFID musí tyto informace zapsat na štítek při jeho aktivaci.
ČOS 990503 3. vydání Příloha B (normativní)
B-87
B.7.14.7 GCTC_PC_RFID_RoutingCodes (směrové kódy)
Systém RFID poskytne informace ze sledování každé detekované zásilky do země jejího původu. To se provede následovně:
do záhlaví štítků RFID se zaznamená jeden nebo více směrových kódů. Použijí se kódy států podle ISO 3166, které sestávají ze dvou alfanumerických znaků (NATO má svůj vlastní kód);
všechny zprávy poskytnuté systémem RFID budou směrovány podle směrových kódů.
C.1 SCHÉMA XML SLEDOVÁNÍ NATO (XML SCHEMA NATO TRACKING) .. C-5 C.1.1 Element NATO Tracking ............................................................................. C-5 C.1.2 Element NATO Tracking Consignment Notification .................................... C-8 C.1.3 Element NATO Tracking Consignment Content ......................................... C-9 C.1.4 Element NATO Tracking Consolidate Consignment ................................... C-9 C.1.5 Element NATO Tracking DeConsolidate Consignment ............................. ..C-
10 C.1.6 Element NATO Tracking Party Identification ............................................. C-10 C.1.7 Element NATO Tracking Track Message .................................................. C-11
C.2 ID ALTERNATIVNÍHO TYPU - KOMPLEXNÍ TYP (COMPLEX TYPE ALTERNATE ID TYPE) ............................................................................ C-11
C.2.1 Element Alternate ID Type ID ................................................................... C-12 C.2.2 Element Alternate ID Type ID Type .......................................................... C-12 C.2.3 Element Alternate ID Type Owner Nation ................................................. C-12
C.3 TYP OBSAH ZÁSILKY - KOMPLEXNÍ TYP (COMPLEX TYPE CONSIGNMENT CONTENT TYPE) ......................................................... C-13
C.3.1 Element Consignment Content Type SSCC ............................................. C-14 C.3.2 Element Consignment Content Type Alt ID .............................................. C-14 C.3.3 Element Consignment Content Type Event Date Time............................. C-14 C.3.4 Element Consignment Content Type Item ................................................ C-15
C.4 TYP ZÁSILKA - KOMPLEXNÍ TYP (COMPLEX TYPE CONSIGNMENT TYPE) ....................................................................................................... C-16
C.4.1 Element Consignment Type SSCC ........................................................... C-17 C.4.2 Element Consignment Type Alt ID ............................................................ C-18 C.4.3 Element Consignment Type Event Date Time .......................................... C-18 C.4.4 Element Consignment Type Owner Nation ............................................... C-18 C.4.5 Element Consignment Type Operation Code ........................................... C-18 C.4.6 Element Consignment Type Reference ID ................................................ C-19 C.4.7 Element Consignment Type Description ................................................... C-19 C.4.8 Element Consignment Type Consignor .................................................... C-19 C.4.9 Element Consignment Type Consignee .................................................... C-19 C.4.10 Element Consignment Type Weight.......................................................... C-20 C.4.11 Element Consignment Type Length .......................................................... C-20 C.4.12 Element Consignment Type Width ........................................................... C-20 C.4.13 Element Consignment Type Height .......................................................... C-21 C.4.14 Element Consignment Type Volume......................................................... C-21 C.4.15 Element Consignment Type HAZMAT Class ............................................ C-21 C.4.16 Element Consignment Type Priority.......................................................... C-21 C.4.17 Element Consignment Type From Location .............................................. C-22
ČOS 990503 3. vydání Příloha C (normativní)
C-2
C.4.18 Element Consignment Type To Location .................................................. C-22 C.4.19 Element Consignment Type Required Delivery Date ................................ C-22 C.4.20 Element Consignment Type Item .............................................................. C-23
C.5 TYP SPOJENÍ ZÁSILEK - KOMPLEXNÍ TYP (COMPLEX TYPE CONSOLIDATION TYPE) ........................................................................ C-23
C.5.1 Element Consolidation Type Parent SSCC ............................................... C-24 C.5.2 Element Consolidation Type Parent ALT ID ............................................. C-24 C.5.3 Element Consolidation Type Reporting Nation ......................................... C-25 C.5.4 Element Consolidation Type Event Date Time ......................................... C-25 C.5.5 Element Consolidation Type Current Location .......................................... C-25 C.5.6 Element Consolidation Type Child SSCC ................................................. C-25 C.5.7 Element Consolidation Type Child ALT ID ................................................ C-26
C.6 TYP ROZDĚLENÍ ZÁSILEK - KOMPLEXNÍ TYP (COMPLEX TYPE DECONSOLIDATION TYPE) ................................................................... C-26
C.6.1 Element Deconsolidation Type Parent SSCC ........................................... C-27 C.6.2 Element Deconsolidation Type Parent ALT ID .......................................... C-27 C.6.3 Element Deconsolidation Type Reporting Nation ..................................... C-28 C.6.4 Element Deconsolidation Type Event Date Time ...................................... C-28 C.6.5 Element Deconsolidation Type Current Location ...................................... C-28 C.6.6 Element Consolidation Type Child SSCC ................................................. C-28 C.6.7 Element Consolidation Type Child ALT ID ................................................ C-29
C.7 TYP POLOŽKA ZÁSILKY - KOMPLEXNÍ TYP (COMPLEX TYPE ITEM TYPE) ............................................................................................. C-29
C.7.1 Element Item Type RIC ............................................................................. C-30 C.7.2 Element Item Type NIC ............................................................................. C-30 C.7.3 Element Item Type NSN ........................................................................... C-31 C.7.4 Element Item Type Reference ID .............................................................. C-31 C.7.5 Element Item Type Quantity ..................................................................... C-31 C.7.6 Element Item Type Description ................................................................. C-31 C.7.7 Element Item Type Weight ........................................................................ C-32 C.7.8 Element Item Type Length ........................................................................ C-32 C.7.9 Element Item Type Width .......................................................................... C-32 C.7.10 Element Item Type Height ........................................................................ C-33 C.7.11 Element Item Type Volume ...................................................................... C-33
C.8 TYP DÉLKA - KOMPLEXNÍ TYP (COMPLEX TYPE LENGHT TYPE) ..... C-33
C.9 TYP ID LOKALITY - KOMPLEXNÍ TYP (COMPLEX TYPE LOCATION ID TYPE) .................................................................................................. C-34
C.9.1 Element Location ID Type GeoLoc ........................................................... C-34 C.9.2 Element Location ID Type GLN ................................................................ C-35 C.9.3 Element Location ID National Loc ID ........................................................ C-35 C.9.4 Element Location ID Type LatLong ........................................................... C-35 C.9.5 Element Location ID Type Description ...................................................... C-35
C.10 TYP LOKALITA - KOMPLEXNÍ TYP (COMPLEX TYPE LOCATION TYPE) ....................................................................................................... C-36
C.11 TYP IDENTIFIKACE ZÚČASTNĚNÉ STRANY - KOMPLEXNÍ TYP (COMPLEX TYPE Party Identification Type) ............................................ C-36
ČOS 990503 3. vydání Příloha C (normativní)
C-3
C.11.1 Element Party Identification Type Owner Nation ...................................... C-37 C.11.2 Element Party Identification Type Location ............................................... C-37
C.12 TYP STAV ZÁSILKY - KOMPLEXNÍ TYP (COMPLEX TYPE STATUS TYPE) ........................................................................................ C-38
C.12.1 Element Status Type Transport Status ..................................................... C-38 C.12.2 Element Status Type PhysicalStatus ........................................................ C-38
C.13 TYP INFORMACE ZE SLEDOVÁNÍ - KOMPLEXNÍ TYP (COMPLEX TYPE TRACKING INFO TYPE) .......................................................................... C-39
C.13.1 Element Tracking Info Type AIT_ID .......................................................... C-39 C.13.2 Element Tracking Info Type Tracking Source ........................................... C-39
C.14 TYP ZPRÁVA ZE SLEDOVÁNÍ - KOMPLEXNÍ TYP (COMPLEX TYPE TRACKING MESSAGE TYPE) ................................................................. C-40
C.14.1 Element Tracking Message Type SSCC ................................................... C-41 C.14.2 Element Tracking Message Type ALT ID ................................................. C-41 C.14.3 Element Tracking Message Type Reporting Nation .................................. C-41 C.14.4 Element Tracking Message Type Event Date Time .................................. C-42 C.14.5 Element Tracking Message Type Current Location .................................. C-42 C.14.6 Element Tracking Message Type Estimated Time Arrival ......................... C-42 C.14.7 Element Tracking Message Type Next Location ....................................... C-43 C.14.8 Element Tracking Message Type Message Type ..................................... C-43 C.14.9 Element Tracking Message Type Tracking Info ........................................ C-43 C.14.10 Element Tracking Message Type Status ................................................. C-44
C.15 TYP VÝDEJNÍ JEDNOTKA - KOMPLEXNÍ TYP (COMPLEX TYPE UNIT OF ISSUE TYPE) ..................................................................................... C-44
C.16 TYP OBJEM - KOMPLEXNÍ TYP (COMPLEX TYPE VOLUME TYPE) .... C-44
C.17 TYP HMOTNOST - KOMPLEXNÍ TYP (COMPLEX TYPE WEIGHT TYPE) ................................................................................................................. C-45
C.18 TYP ID AIT - JEDNODUCHÝ TYP (SIMPLE TYPE AIT_ID TYPE)........... C-45
C.19 TYP ALTERNATIVNÍ ID - JEDNODUCHÝ TYP (SIMPLE TYPE ALTERNATE ID TYPE) ............................................................................ C-45
C.20 TYP UDÁNÍ DÉLKY - JEDNODUCHÝ TYP (SIMPLE TYPE LENGTH TYPE ENUM) ........................................................................................... C-46
C.21 TYP UDÁNÍ LOKALITY - JEDNODUCHÝ TYP (SIMPLE TYPE LOCATION TYPE ENUM) ........................................................................................... C-48
C.22 TYP VOLBA ZPRÁVY - JEDNODUCHÝ TYP (SIMPLE TYPE MESSAGE SELECT TYPE) ........................................................................................ C-48
C.23 JEDNODUCHÝ TYP KÓD STÁTU - JEDNODUCHÝ TYP (SIMPLE TYPE NATION CODE) ....................................................................................... C-49
C.24 TYP NIC - JEDNODUCHÝ TYP (SIMPLE TYPE NIC TYPE) ................... C-49
C.25 TYP NSN - JEDNODUCHÝ TYP (SIMPLE TYPE NSN TYPE) ................. C-50
C.26 TYP TECHNICKÝ STAV - JEDNODUCHÝ TYP (SIMPLE TYPE PHYSICAL STATUS TYPE) ..................................................................... C-50
ČOS 990503 3. vydání Příloha C (normativní)
C-4
C.27 TYP RIC - JEDNODUCHÝ TYP (SIMPLE TYPE RIC TYPE) ................... C-51
C.28 TYP ID SSCC - JEDNODUCHÝ TYP (SIMPLE TYPE SSCC ID TYPE) ... C-51
C.29 TYP ŘETĚZEC 256 ZNAKŮ - JEDNODUCHÝ TYP (SIMPLE TYPE STRING256) ............................................................................................. C-52
C.30 TYP ŘETĚZEC 64 ZNAKŮ - JEDNODUCHÝ TYP (SIMPLE TYPE STRING64) ............................................................................................... C-52
C.31 TYP PŘEPRAVNÍ STAV - JEDNODUCHÝ TYP (SIMPLE TYPE TRANSPORT STATUS TYPE) ................................................................. C-53
C.32 TYP VÝČET VÝDEJNÍCH JEDNOTEK - JEDNODUCHÝ TYP (SIMPLE TYPE UNIT OF ISSUE TYPE ENUM) ...................................................... C-54
C.33 TYP VÝČET JEDNOTEK OBJEMU - JEDNODUCHÝ TYP (SIMPLE TYPE VOLUME TYPE ENUM) ........................................................................... C-61
C.34 TYP VÝČET JEDNOTEK HMOTNOSTI - JEDNODUCHÝ TYP (SIMPLE TYPE WEIGHT TYPE ENUM) .................................................................. C-63
ČOS 990503 3. vydání Příloha C (normativní)
C-5
ÚVOD
Základní informace o jazyku XML jsou uvedeny v příloze G tohoto ČOS.
Názvy jednotlivých elementů a jejich atributů se používají v anglickém originálu (aby souhlasily se jmenným prostorem). Pro použití v rámci NATO je nutné používat v angličtině také textové údaje (např. zkratky jednotek, doprovodný text).
C.1 SCHÉMA XML SLEDOVÁNÍ NATO (XML SCHEMA NATO TRACKING)
umístění schéma: C:\ICTC\NATOTrackingSchemas\NATOTracking.xsd
Elementy Komplexní typy Jednoduché typy NATOTracking AlternateIDType AIT_IDType ConsignmentContentType ConsignmentAlternateIDType ConsignmentType LengthTypeEnum ConsolidationType LocationTypeEnum DeconsolidationType MessageSelectType ItemType NationCode LengthType NICType LocationIDType NSNType LocationType PhysicalStatusType PartyIdentificationType RICType StatusType SSCCIDType TrackingInfoType string256 TrackingMessageType string64 UnitOfIssueType TransportStatusType VolumeType UnitOfIssueTypeEnum WeightType VolumeTypeEnum WeightTypeEnum
C.1.1 Element NATO Tracking
Schéma
Element NATOTracking (sledování NATO) popisuje zprávy, které přijímá systém sledování zásilek NATO. Popis sledování NATO ve formátu XML může obsahovat jednu nebo zřetězené zprávy.
POZNÁMKA Skutečnost, že kořenový element NATOTracking se může skládat z jedné zprávy nebo z řetězce zpráv, je vyjádřena ve
ČOS 990503 3. vydání Příloha C (normativní)
C-6
schématu symbolem přepínače s neomezenou četností tvorby elementů potomků.
Elementy potomků:
element ConsignmentNotification (notifikace zásilky) dovoluje vytvořit a aktualizovat zásilku,
element ConsignmentContent (obsah zásilky) obsahuje obsah dané zásilky,
element ConsolidateConsignment (spojení zásilky) dovoluje spojení jedné zásilky s jinou zásilkou,
element DeConsolidateConsignment (rozdělení zásilky) dovoluje rozdělení dříve spojených zásilek,
element PartyIdentification (identifikace zúčastněné strany) dovoluje třetí straně registrovat lokalitu,
element TrackMessage (zpráva ze sledování) je zpráva ze sledování, kterou odešle systém sledování zásilek.
Popisuje zprávy, které přijímá systém sledování zásilek NATO. Popis sledování zásilek NATO ve formátu XML může obsahovat jednu nebo zřetězené zprávy:
- ConsignmentNotification = dovoluje vytvořit a aktualizovat zásilku.
- ConsignmentContent = obsahuje obsah dané zásilky.
-
ConsolidateConsignment = dovoluje spojení jedné zásilky s jinou zásilkou.
- DeconsolidateConsignment = dovoluje rozdělení dříve spojených zásilek.
- Party identification = dovoluje třetí straně registrovat lokalitu.
- TrackMessage = zpráva ze sledování, kterou odešle systém sledování zásilek.
zápis ve schématu XML
<xs:element name="NATOTracking"> <xs:annotation>
<xs:documentation>
Popisuje zprávy, které přijímá systém sledování zásilek NATO. Popis sledování NATO ve formátu XML může obsahovat jednu nebo zřetězené zprávy: - ConsignmentNotification = umožňuje vytvořit a aktualizovat
zásilku. - ConsignmentContent = obsahuje obsah dané zásilky. - ConsolidateConsignment = dovoluje spojení jedné zásilky
s jinou zásilkou. - DeconsolidateConsignment = dovoluje rozdělení dříve
spojených zásilek.
ČOS 990503 3. vydání Příloha C (normativní)
C-7
- Party identification = dovoluje třetí straně registrovat lokalitu.
- TrackMessage = zpráva ze sledování, kterou odešle systém sledování zásilek.
použito elementy TRACKING MESSAGE TYPE ALT ID Consignment Type ALT ID ConsignmentContentType/ALT ID CONSOLIDATION TYPE ChildALT ID DeCONSOLIDATION TYPE ChildALT ID CONSOLIDATION TYPE ParentALT ID DeCONSOLIDATION TYPE ParentALT ID
anotace popis Pro definici alternativního ID nelze použít kód SSCC. zápis ve schématu XML
<xs:COMPLEX TYPE name="AlternateIDType"> <xs:annotation>
POZNÁMKA Schéma kódu státu ([0-9,A-Z]){2,3} vyjadřuje, že kód je dvou nebo třímístný. Podle ČSN ISO 3166 je dvoumístný kód tvořen kombinací písmen A až Z, třímístný kód je složen z číslic.
C.3 TYP OBSAH ZÁSILKY - KOMPLEXNÍ TYP (COMPLEX TYPE CONSIGNMENT CONTENT TYPE)
anotace popis Udává informace o položce pro přidání a odebrání položek ze zásilek. Pro zprávu je nutný kód SSCC nebo obecný identifikátor zásilky. Obsah informací o položce je uveden v elementu ItemInfoType v kapitole D. Každá zpráva o obsahu zásilky zcela nahradí předchozí obsah zásilky (nepřipouští se přičítání nebo odečítání položek).
zápis ve schématu XML
<xs:COMPLEX TYPE name="ConsignmentContentType"> <xs:annotation>
<xs:documentation>
Udává informace o položce pro přidání a odebrání položek ze zásilek. Pro zprávu je nutný kód SSCC nebo obecný identifikátor zásilky. Obsah informací o položce je uveden v elementu ItemInfoType v kapitole D. Každá zpráva o obsahu zásilky zcela nahradí předchozí obsah zásilky (nepřipouští se přičítání nebo odečítání položek).
Podle uvedeného schéma položka zásilky musí mít jeden z identifikátorů (RIC, NIC nebo NSN) a musí být udáno její množství (počet). Další údaje jsou nepovinné – odkaz, popis, vnější rozměry, hmotnost.
ČOS 990503 3. vydání Příloha C (normativní)
C-16
C.4 TYP ZÁSILKA - KOMPLEXNÍ TYP (COMPLEX TYPE CONSIGNMENT TYPE)
elementy potomků: SSCC ALT ID EventDateTime OwnerNation OperationCode ReferenceID Description Consignor Consignee Weight Length Width Height Volume HAZMATClass Priority FromLocation ToLocation RequiredDeliveryDate Item
použity elementem NATOTracking/ConsignmentNotification
anotace popis Popisuje vytvoření zásilky a aktualizaci zprávy v systému
ČOS 990503 3. vydání Příloha C (normativní)
C-17
sledování NATO. Kromě obecných informací umožňuje přidání položek k zásilce. Zpráva musí obsahovat kód SSCC nebo obecný identifikátor zásilky. Obsah informací o položce je uveden v elementu ItemInfoType v kapitole D.
zápis ve schématu XML
<xs:COMPLEX TYPE name="ConsignmentType"> <xs:annotation>
<xs:documentation>
Popisuje vytvoření zásilky a aktualizaci zprávy v systému sledování NATO. Kromě obecných informací umožňuje přidání položek k zásilce. Zpráva musí obsahovat kód SSCC nebo obecný identifikátor zásilky. Obsah informací o položce je uveden v elementu ItemInfoType v kapitole D.
elementy potomků: ParentSSCC ParentALT ID ReportingNation EventDateTime CurrentLocation ChildSSCC ChildALT ID
použity elementem NATOTracking/ConsolidateConsignment
ČOS 990503 3. vydání Příloha C (normativní)
C-24
anotace popis Uvádí informace o spojení pro spojování a rozdělování zásilek. Pro zprávu je potřebný kód SSCC nebo obecný identifikátor zásilky rodičů. Pro zprávu je dále potřebný jeden nebo více identifikátorů potomků nebo obecný identifikátor zásilek potomků.
zápis ve schématu XML
<xs:COMPLEX TYPE name="ConsolidationType"> <xs:annotation>
<xs:documentation>
Uvádí informace o spojení pro spojování a rozdělování zásilek. Pro zprávu je potřebný kód SSCC nebo obecný identifikátor zásilky rodičů. Pro zprávu je dále potřebný jeden nebo více identifikátorů potomků nebo obecný identifikátor zásilek potomků. <xs:documentation>
elementy potomků: ParentSSCC ParentALT ID ReportingNation EventDateTime CurrentLocation ChildSSCC ChildALT ID
použity elementem NATOTracking/ConsolidateConsignment
anotace popis Udává informace o rozdělení zásilky. Je-li udán pouze kód SSCC nebo alternativní identifikátor zásilky rodičů, celá zásilka se rozdělí do úrovně potomků. Pro zprávu je potřebný SSCC nebo obecný identifikátor zásilky rodičů. Pro částečné rozdělení zásilky má zpráva nepovinný SSCC nebo obecný identifikátor zásilky potomků.
ČOS 990503 3. vydání Příloha C (normativní)
C-27
zápis ve schématu XML
<xs:COMPLEX TYPE name="DeconsolidationType"> <xs:annotation>
<xs:documentation>
Udává informace o rozdělení zásilky. Je-li udán pouze kód SSCC nebo alternativní identifikátor zásilky rodičů, celá zásilka se rozdělí do úrovně potomků. Pro zprávu je potřebný SSCC nebo obecný identifikátor zásilky rodičů. Pro částečné rozdělení zásilky má zpráva nepovinný SSCC nebo obecný identifikátor zásilky potomků.
elementy potomků: RIC NIC NSN ReferenceID Quantity Description Weight Length Width Height Volume
použity elementy Consignment Type Item ConsignmentContentType/Item
ČOS 990503 3. vydání Příloha C (normativní)
C-30
anotace popis Popisuje informace o položce, která je určena podle RIC, NIC, NSN, proto musí být udán jeden z těchto identifikátorů. Množství udává počet položek.
zápis ve schématu XML
<xs:COMPLEX TYPE name="ItemType"> <xs:annotation>
<xs:documentation>
Popisuje informace o položce, která je určena podle RIC, NIC, NSN, proto musí být udán jeden z těchto identifikátorů. Množství udává počet položek.
soulad s Obsah dat v tomto elementu musí splňovat STANAG 2014. požadovaný formát údajů
[DDMM.MMMMLaH-DDDMM.MMMMLoH] D = stupně (zeměpisné) M = minuty (zeměpisné) LaH = N pro sever a S pro jih LoH = E pro východ a W pro západ Údaje musí být uvedeny vždy v souřadnicovém systému WGS1984
C.9.5 Element Location ID Type Description
schéma
(popis) typ string64
vlastnosti (properties)
isRef 0 obsah jednoduchý
fazety (omezení)
maximální délka 64
ČOS 990503 3. vydání Příloha C (normativní)
C-36
zápis ve schématu XML
<xs:element name="Description" type="string64"/>
C.10 TYP LOKALITA - KOMPLEXNÍ TYP (COMPLEX TYPE LOCATION TYPE) Schéma
použity elementy Consignment Type Consignee Consignment Type Consignor TRACKING MESSAGE TYPE CurrentLocation CONSOLIDATION TYPE CurrentLocation DeCONSOLIDATION TYPE CurrentLocation Consignment Type FromLocation TRACKING MESSAGE TYPE NextLocation Consignment Type ToLocation
fazety (omezení) maximální délka 64 atributy Name Type Use Default Fixed Annotation
jednotka LocationTypeEnum požadován
anotace popis Definice všech lokalit identifikačními metodami. zápis ve schématu XML
<xs:COMPLEX TYPE name="LocationType"> <xs:annotation>
<xs:documentation>
Definice všech lokalit identifikačními metodami. </xs:documentation>
anotace popis Tento typ obsahuje informace pro registraci nové zúčastněné strany. Registrující stát musí uvést stát - vlastníka a zeměpisnou délku a šířku. Kromě toho poskytne buď GeoLoc, GLN, nebo identifikátor vnitrostátní lokality.
zápis ve schématu XML
<xs:COMPLEX TYPE name="PartyIdentificationType"> <xs:annotation>
<xs:documentation>
Tento typ obsahuje informace pro registraci nové zúčastněné strany. Registrující stát musí uvést stát - vlastníka a zeměpisnou délku a šířku. Kromě toho poskytne její buď odpovídající GeoLoc, GLN, nebo identifikátor vnitrostátní lokality.
maximální délka (maxLength) 64 výčet (enumeration) DV (doručena)
enumeration AT (čeká na přepravu) enumeration RT (připravená na přepravu) enumeration DL (zpožděná) enumeration OT (včasná) enumeration ER (uspíšená) enumeration MS (nezvěstná) enumeration LT (ztracena) enumeration AI (čeká na další instrukce) enumeration CL (uzavřena)
SSCC ALT ID ReportingNation EventDateTime CurrentLocation EstimatedTimeArrival NextLocation MessageType TrackingInfo Status
použit elementem
NATOTracking/TrackMessage
anotace popis Popisuje obsah všech zpráv systému sledování, které jsou akceptovány systémem sledování zásilek NATO. Pro zprávy jsou nutné kódy SSCC nebo obecný identifikátor zásilky. Obsah informací ze sledování je uveden v kapitole C.13.
zápis ve schématu XML
<xs:COMPLEX TYPE name="TrackingMessageType"> <xs:annotation>
<xs:documentation>
Popisuje obsah všech zpráv systému sledování, které jsou akceptovány systémem sledování zásilek NATO. Pro zprávy jsou nutné kódy SSCC nebo obecný identifikátor zásilky. Obsah informací ze sledování je uveden v kapitole C.13.
typ restrikce (restriction of) string64 použit atributem LengthType/@unit
fazety (omezení)
maximální délka 64 výčet (enumeration) BF
enumeration CM enumeration DE enumeration FT enumeration HF enumeration HY enumeration IN enumeration KM enumeration LF enumeration MF enumeration MI enumeration ML enumeration MM enumeration MR enumeration SO enumeration YD
anotace popis Definice všech přípustných jednotek délky. BF Board Foot (míra řeziva = 1 ft x 1 ft x 1 in) CM Centimeter (centimetr) DE Decimeter (decimetr) FT Foot (stopa) HF Hundred Feet (100 stop) HY Hundred Yards (100 yardů) IN Inch (palec) KM Kilometer (kilometr) LF Linear Foot (přímá stopa = „normální
ČOS 990503 3. vydání Příloha C (normativní)
C-47
stopa“) MF Thousand Feet (1 000 stop) MI Mile (míle) ML Milliliter (mililitr) MM Millimeter (milimetr) MR Meter (metr) SO Shot (1 shot = 44.3602943 millilitrů)
YD Yard (yard) zápis ve schématu XML
<xs:SIMPLE TYPE name="LengthTypeEnum"> <xs:annotation>
<xs:documentation>
Definice všech přípustných jednotek délky.
BF Board Foot (míra řeziva = 1 ft x 1 ft x 1 in) CM Centimeter (centimetr) DE Decimeter (decimetr) FT Foot (stopa) HF Hundred Feet (100 stop) HY Hundred Yards (100 yardů) IN Inch (palec) KM Kilometer (kilometr) LF Linear Foot (přímá stopa = „normální stopa“) MF Thousand Feet (1 000 stop) MI Mile (míle) ML Milliliter (mililitr ÷1 x 1 x 1 cm) MM Millimeter (milimetr) MR Meter (metr) SO Shot (1 shot = 44.3602943 millilitrů)
typ restrikce (restriction of) xs:string použit elementy LocationIDType/Description LocationIDType/GeoLoc
LocationIDType/GLN Consignment Type HAZMATClass AlternateIDType/ID LocationIDType/LatLong LocationIDType/NationalLocID Consignment Type OperationCode ITEM TYPE ReferenceID TRACKING INFO TYPE TrackingSource
typ restrikce (restriction of) string64 použit elemente
m
Status Type TransportStatus
fazety (omezení)
maximální délka 64 výčet (enumeration) DV
enumeration AT enumeration RT enumeration DL enumeration OT enumeration ER enumeration MS enumeration LT enumeration AI enumeration CL
anotace popis Definice přepravního stavu ve zprávě o stavu přepravy. DV
AT RT DL OT ER MS LT AI CL
- Delivered - Awaiting transport - Ready for transport - Delayed - On Time - Early - Missing - Lost - Awaiting further instructions – Closed
(doručena) (čeká na přepravu) (připravená k přepravě) (zpožděná) (včasná) (uspíšená) (nezvěstná) (ztracená) (čeká na další instrukce) (uzavřena)
zápis ve schématu XML
<xs:SIMPLE TYPE name="TransportStatusType"> <xs:annotation>
<xs:documentation>
Definice přepravního stavu ve zprávě o stavu přepravy. DV - Delivered AT - Awaiting transport RT - Ready for transport DL - Delayed OT - On Time ER - Early MS - Missing LT - Lost
typ restrikce (restriction of) string64 použit atributem UnitOfIssueType/@unit
fazety (omezení)
maximální délka 64 výčet (enumeration) AM
enumeration AT enumeration AY enumeration BA enumeration BC enumeration BD enumeration BE enumeration BF enumeration BG enumeration BI enumeration BK enumeration BL enumeration BO enumeration BR enumeration BT enumeration BX enumeration CA enumeration CB enumeration CE enumeration CH enumeration CK enumeration CL enumeration CN enumeration CO enumeration CP enumeration CR enumeration CS
ČOS 990503 3. vydání Příloha C (normativní)
C-55
enumeration CT enumeration CY enumeration DI enumeration DR enumeration DZ enumeration EA enumeration GP enumeration GR enumeration GS enumeration HD enumeration HF enumeration HG enumeration HK enumeration HS enumeration HW enumeration HY enumeration JR enumeration KE enumeration KT enumeration LG enumeration LL enumeration LO enumeration ME enumeration MX enumeration PC enumeration PD enumeration PG enumeration PK enumeration PM enumeration PO enumeration PR enumeration PZ enumeration QR enumeration RA enumeration RL enumeration RM enumeration RO enumeration SA enumeration SB enumeration SC enumeration SD enumeration SE enumeration SH enumeration SK enumeration SL enumeration SO enumeration SP enumeration SX enumeration TI
ČOS 990503 3. vydání Příloha C (normativní)
C-56
enumeration TL enumeration TR enumeration TT enumeration TU enumeration VC enumeration VI enumeration XX
anotace popis Definice možných výdejních jednotek. Není-li použitelná žádná uvedená jednotka, použít kód EA.
AM AT AY BA BC BD BE BF BG BI BK BL BO BR BT BX CA CB CE CH CK CL CN CO CP CR CS CT CY DI DR DZ EA GP GR
Ampoule Assortment Assembly Ball Block Bundle Bale Board Foot Bag Brick Book Barrel Bolt Bar Bottle Box Cartridge Carboy Cone Chest Cake Coil Can Container Capsule Crate Case Carton Cylinder Dispenser Drum Dozen Each Group Gross
(ampule – malá uzavřená láhev) (souprava) (sestava, komplet) (klubko) (blok = 5,5x2,75x1,375 in ÷ 140x 70x35 mm dxšxv) (svazek) (velký svazek, v USA cca 225 kg) (deska, objemová jednotka řeziva) (brašna, pytel, taška – kontejner s poddajnými stěnami) (cihla – blok keramického mater.) (kniha, svazek listů) (sud, obvykle 158,9 litrů) (bolt, jednotka délky textilu ÷ 36,57 m) (bar, jednotka tlaku) (nádoba, láhev pro tekutiny i plyny) (krabice, bedna, přepravka) (náplň, kazeta, náboj) (láhev na přepravu kapalin, vody i chemikálií objem cca 20 – 60 l) (nádoba, předmět kuželovitého tvaru) (skříň, bedna, truhla, pokladna) (kus, tabulka, slitek) (cívka, kotouč) (kanystr, plechovka, pouzdro) (kontejner, přepravní obal) (ampulka, kapsle, malé pouzdro) (koš, laťová nebo proutěná bedna) (bedna pro přepravu lahví, ovoce) (karton, krabice papírová, lepenková) (válcová nádoba, buben, tlaková láhev) (zásobník, dávkovač) (buben, válcová nádoba pro přepravu sypkého zboží, ocelová i z vláken)
ČOS 990503 3. vydání Příloha C (normativní)
C-57
GS HD HF HG HK HS HW HY JR KE KT LG LL LO ME MX OT PC PD PG PK PM PO PR PZ QR RA RL RM RO SA SB SC SD SE SH SK SL SO SP SX TI
Glass 100 Hundred Feet Half-Gross Hank Hundred Square Feet Hundred Weight Hundred Yard Jar Keg Kit Length Fifty Lot Meal Thousand Outfit Piece Pad Package Pack Plate Pouch Pair Packet Quire Ration Reel Ream Roll Sack Slab Section Skid Set Sheet Skein Spool Square Strip Stick Tin
(tucet) (univerzální kvalifikátor „každý“, všechno) (hromada, kolekce, seskupení) (veletucet = 144 jednotek) (skleněné výrobky, sklenice, tabule skla) (sto jednotek) (100 stop; 1 stopa = 30,5 cm) (polovina veletuctu = 72 jednotek) (jednotka příze ve stočeném stavu) (100 čtverečných stop = 100 x 0,0929 m2) (jednotka hmotnosti; 50,8 kg ve Velké Británii, 45,4 kg v USA) (100 yardů = 91,44 m) (válcová nádoba s širokým hrdlem nebo poklopem) (malý sud, soudek, do cca 40 l) (souprava, sada, stavebnice) (délka, vnější rozměry) (50 jednotek) (skupina zboží, položek, větší množství „spousta“) (množství, jídlo, krmení, mouka) (1 000 jednotek) (výbava, výstroj a výzbroj) (kus, díl, jednotka) (podložka, výplň, vložka, blok) (balení, komplex) (balík, pouzdro) (deska, plech, tabule) (brašna na náboje, vak, pytlík) (pár, dvojice) (blok, balík, paket) (blok papíru nebo kniha o 24 až 25 listech, archů) (dávka, příděl – např. potravin) (svitek, navinutý materiál) (480 nebo 500 archů, listů papíru) (kotouč, roura, štůček) (pytel, sáček, vak) (deska, prkno, plát) (blok, součást) (paleta, zarážka, podpěrný klín) (agregát, sada, soustava) (list, arch papíru, plachta, fólie) (délková míra na bavlněnou přízi
ČOS 990503 3. vydání Příloha C (normativní)
C-58
TL TR TT TU VC VI XX
Ten Barrels Tray Tablet Tube Five Hundred Vial Ten
<xs:SIMPLE TYPE name="UnitOfIssueTypeEnum"> <xs:annotation>
<xs:documentation>
Definice možných výdejních jednotek. Není-li použitelná žádná uvedená jednotka, použít kód EA. AM Ampoule AT Assortment AY Assembly BA Ball BC Block BD Bundle BE Bale BF Board Foot BG Bag BI Brick BK Book BL Barrel BO Bolt BR Bar BT Bottle BX Box CA Cartridge CB Carboy CE Cone CH Chest CK Cake CL Coil CN Can CO Container CP Capsule CR Crate CS Case CT Carton CY Cylinder DI Dispenser
ČOS 990503 3. vydání Příloha C (normativní)
C-59
DR Drum DZ Dozen EA Each GP Group GR Gross GS Glass HD 100 HF Hundred Feet HG Half-Gross HK Hank HS Hundred Square Feet HW Hundred Weight HY Hundred Yard JR Jar KE Keg KT Kit LG Length LL Fifty LO Lot ME Meal MX Thousand OT Outfit PC Piece PD Pad PG Package PK Pack PM Plate PO Pouch PR Pair PZ Packet QR Quire RA Ration RL Reel RM Ream RO Roll SA Sack SB Slab SC Section SD Skid SE Set SH Sheet SK Skein SL Spool SO Square SP Strip SX Stick TI Tin TL Ten Barrels TR Tray
Uvedený seznam jednotek slouží k pochopení obsahu cizích zásilek, včetně původem z anglosaských zemí, na jejichž sledování se bude ČR podílet. Převod udaných jednotek na jiné se neprovádí – viz článek B.5.2.37.
Vlastní zásilky ČR, určené pro mezistátní přepravu a sledování, se vytvářejí podle interních předpisů a pro vyjádření kvantitativních ukazatelů je dovoleno používat pouze jednotky soustavy SI a ty jednotky ze seznamu, které mají upřesňující, resp. popisný charakter – například PC, KT, CT.
C.33 TYP VÝČET JEDNOTEK OBJEMU - JEDNODUCHÝ TYP (SIMPLE TYPE VOLUME TYPE ENUM)
<xs:SIMPLE TYPE name="VolumeTypeEnum"> <xs:annotation>
<xs:documentation>
Definice možných jednotek objemu. CC Cubic Centimeter CD Cubic Yard CF Cubic Foot CI Cubic Inch CZ Cubic Meter DL Deciliter GB Gallon Imperial GL Gallon LI Liter MC Thousand Cubic Feet PT Pint QT Quart
Uvedený seznam jednotek objemu slouží k pochopení obsahu cizích zásilek, včetně původem z anglosaských zemí, na jejichž sledování se bude ČR podílet. Převod udaných jednotek na jiné se neprovádí – viz článek B.5.2.37.
Objemové ukazatele vlastních zásilek ČR, určených pro mezistátní přepravu a sledování je dovoleno vyjadřovat pouze v soustavě SI, tj. v m3 a jeho dekadických násobcích nebo podílech.
C.34 TYP VÝČET JEDNOTEK HMOTNOSTI - JEDNODUCHÝ TYP (SIMPLE TYPE WEIGHT TYPE ENUM)
typ restrikce (restriction of) string64 použit atributem WeightType/@unit
fazety (omezení)
maximální délka 64 výčet (enumeration) CC
enumeration CG enumeration DC enumeration DG enumeration DM enumeration GM enumeration GN enumeration HP enumeration HW enumeration KG enumeration LB enumeration LT enumeration MG enumeration OZ enumeration TM enumeration TN
anotace popis Definice možných jednotek hmotnosti. CG
DC DG DM GM GN HP HW KG LB LT
Centigram Decagram Decigram Dram Gram Grain Hundred Pounds Hundred Weight Kilogram Pound Long Ton
(centigram, cg = 0,01 g) (dekagram, Dg = 10 g = 0,01 kg) (decigram = 0,1 g) (dram = 1,772 g) (gram, g = 0,001 kg) (grain = 64,79891 mg) (100 liber = 45,359 kg) (= 50,8023 kg – UK) (kilogram, kg = 1 000 g) (libra = 0,45359 kg) (dlouhá tuna = 1 016,05 kg – UK)
ČOS 990503 3. vydání Příloha C (normativní)
C-64
MG OZ TM TN TO
Milligram Ounce Metric Ton Ton Troy ounce
(miligram = 0,001 g) (unce = 0,02834 kg) (tuna, t = 1 000 kg) (tuna = 2 000 liber = cca 907 kg - USA) (trojská unce = 0,0311 kg)
zápis ve schématu XML
<xs:SIMPLE TYPE name="WeightTypeEnum"> <xs:annotation>
<xs:documentation>
Definice možných jednotek hmotnosti. CG Centigram DC Decagram DG Decigram DM Dram GM Gram GN Grain HP Hundred Pounds HW Hundred Weight KG Kilogram LB Pound LT Long Ton MG Milligram OZ Ounce TM Metric Ton TN Ton TO Troy ounce
Uvedený seznam jednotek objemu slouží k pochopení obsahu cizích zásilek, včetně původem z anglosaských zemí, na jejichž sledování se bude ČR podílet. Převod udaných jednotek na jiné se neprovádí – viz článek B.5.2.37.
ČOS 990503 3. vydání Příloha C (normativní)
C-65
Hmotnostní ukazatele vlastních zásilek ČR, určených pro mezistátní přepravu a sledování je dovoleno vyjadřovat pouze v soustavě SI, tj. v kilogramech a jeho dekadických násobcích a podílech.
ČOS 990503 3. vydání
204
(VOLNÁ STRANA)
ČOS 990503 3. vydání Příloha D (normativní)
D-1
MODEL ARCHITEKTURY SYSTÉMU SLEDOVÁNÍ ZÁSILEK NATO (NATO CT SAM) – SCHÉMA XML (V KÓDU XML) OBSAH PŘÍLOHY
V příloze D je uvedeno souhrnné schéma XML pro sledování zásilek NATO, jehož jednotlivé části jsou popsány v příloze C. NATO Tracking XML Schema <?xml version="1.0" encoding="utf-8"?> <xs:schema xmlns:xs=http://www.w3.org/2001/XMLSchema targetNamespace="https://lognet.nc3a.nato.int/NATOTracking" xmlns="https://lognet.nc3a.nato.int/NATOTracking">
</xs:restriction> </xs:simpleType> <!-- string64 type definition --> <!--***********************************************************************************--> <xs:simpleType name="string64"> <xs:annotation> <xs:documentation> Řetězec s možnou délkou až 64 znaků. Definuje obecný řetězec s omezenou délkou. </xs:documentation> </xs:annotation> <xs:restriction base="xs:string"> <xs:maxLength value="64" /> </xs:restriction> </xs:simpleType> <!-- string64 type definition --> <!--***********************************************************************************--> <xs:simpleType name="string256"> <xs:annotation> <xs:documentation> Řetězec s možnou délkou až 256 znaků. Definuje obecný řetězec s omezenou
délkou. </xs:documentation> </xs:annotation> <xs:restriction base="xs:string"> <xs:maxLength value="256" /> </xs:restriction> </xs:simpleType> <!-- StatusType --> <!--***********************************************************************************--> <xs:complexType name="StatusType"> <xs:annotation> <xs:documentation> Informace o stavu, které jsou použitelné ve všech typech zpráv. </xs:documentation> </xs:annotation> <xs:sequence> <xs:element name="TransportStatus" type="TransportStatusType" minOccurs="0"/> <xs:element name="PhysicalStatus" type="PhysicalStatusType" minOccurs="0"/> </xs:sequence> </xs:complexType> <!-- ItemInfoType --> <!--***********************************************************************************--> <xs:complexType name="ItemType"> <xs:annotation> <xs:documentation>
Popisuje informace o položce podle jejích kódů RIC, NIC, NSN. K identifikaci položky se musí nastavit jeden z uvedených kódů. Množství se vyjadřuje počtem položek.
</xs:choice> <xs:element name="ReportingNation" type="NationCode" /> <xs:element name="EventDateTime" type="xs:dateTime" /> <xs:element name="CurrentLocation" type="LocationType" /> <xs:element name="EstimatedTimeArrival" type="xs:dateTime" minOccurs="0" /> <xs:element name="NextLocation" type="LocationType" minOccurs="0" /> <xs:element name="MessageType" type="MessageSelectType" /> <xs:element name="TrackingInfo" type="TrackingInfoType" minOccurs="0"/> <xs:element name="Status" type="StatusType" minOccurs="0" /> </xs:sequence> </xs:complexType> <!-- TransportStatusType --> <!--***********************************************************************************--> <xs:simpleType name="TransportStatusType"> <xs:annotation> <xs:documentation> Definuje stav přepravy ve zprávě o stavu přepravy. DV – Delivered (doručena) AT - Awaiting transport (čeká na přepravu) RT - Ready for transport (připravena na přepravu) DL – Delayed (zpožděná) OT - On Time (včasná) ER – Early (uspíšená) MS – Missing (nezvěstná) LT – Lost (ztracená) AI - Awaiting further instructions (čeká na další instrukce) CL – Closed (uzavřena) </xs:documentation> </xs:annotation> <xs:restriction base="string64"> <xs:enumeration value="DV" /> <xs:enumeration value="AT" /> <xs:enumeration value="RT" /> <xs:enumeration value="DL" /> <xs:enumeration value="OT" /> <xs:enumeration value="ER" /> <xs:enumeration value="MS" /> <xs:enumeration value="LT" /> <xs:enumeration value="AI" /> <xs:enumeration value="CL" /> </xs:restriction> </xs:simpleType> <!-- QualityStatusType --> <!--***********************************************************************************--> <xs:simpleType name="PhysicalStatusType"> <xs:annotation> <xs:documentation> Definuje technický stav zásilky ve zprávě o stavu přepravy. GD - Undamaged (good) (nepoškozená, dobrý stav) DM – Damaged (poškozena) QD - Quantity Discrepancy (nesrovnalosti v obsahu) </xs:documentation> </xs:annotation> <xs:restriction base="string64"> <xs:enumeration value="GD" /> <xs:enumeration value="DM" /> <xs:enumeration value="QD" /> </xs:restriction>
ČOS 990503 3. vydání Příloha D (normativní)
D-6
</xs:simpleType> <!-- ConsolidationType --> <!--***********************************************************************************--> <xs:complexType name="ConsolidationType"> <xs:annotation> <xs:documentation> Udává informace o spojení pro spojení a rozdělení zásilek. Pro zprávu je potřeba
kód SSCC nebo jiný celkový identifikátor zásilky rodičů. Dále je potřebný kód SSCC nebo jiný celkový identifikátor každé zásilky potomka.
</xs:documentation> </xs:annotation> <xs:sequence> <xs:choice> <xs:element name="ParentSSCC" type="SSCCIDType" nillable="true"/> <xs:element name="ParentAltID" type="AlternateIDType" nillable="true"/> </xs:choice> <xs:element name="ReportingNation" type="NationCode" /> <xs:element name="EventDateTime" type="xs:dateTime" /> <xs:element name="CurrentLocation" type="LocationType" /> <xs:choice minOccurs="1" maxOccurs="unbounded"> <xs:element name="ChildSSCC" type="SSCCIDType" nillable="true"/> <xs:element name="ChildAltID" type="AlternateIDType" nillable="true"/> </xs:choice> </xs:sequence> </xs:complexType> <!-- DeconsolidationType --> <!--***********************************************************************************--> <xs:complexType name="DeconsolidationType"> <xs:annotation> <xs:documentation> Udává informace o rozdělení zásilek. Je-li udán pouze kód SSCC nebo alternativní
identifikátor zásilky rodičů, celá zásilka se rozdělí na jednotlivé zásilky potomků. Pro zprávu je potřeba kód SSCC nebo jiný celkový identifikátor zásilky rodičů. Zpráva může mít také kód SSCC nebo jiný celkový identifikátor zásilek potomků pro částečné rozdělení zásilky rodičů.
BF Board Foot (jednotka pro rozměry řeziva) CM Centimeter (centimetr) DE Decimeter (decimetr) FT Foot (stopa) HF Hundred Feet (100 stop) HY Hundred Yards (100 yardů) IN Inch (palec) KM Kilometer (kilometr) LF Linear Foot (přímá stopa) MF Thousand Feet (1 000 stop) MI Mile (míle) ML Milliliter (mililitr ÷1 x 1 x 1 cm) MM Millimeter (milimetr) MR Meter (metr) SO Shot (shot) YD Yard (yard)
<xs:enumeration value="ML" /> <xs:enumeration value="MM" /> <xs:enumeration value="MR" /> <xs:enumeration value="SO" /> <xs:enumeration value="YD" /> </xs:restriction> </xs:simpleType> <!--UnitType--> <xs:complexType name="LengthType"> <xs:simpleContent> <xs:extension base="xs:double"> <xs:attribute name="unit" type="LengthTypeEnum" use="required" /> </xs:extension> </xs:simpleContent> </xs:complexType> <!-- UnitOfIssueTypeEnum --> <!--***********************************************************************************--> <xs:simpleType name="UnitOfIssueTypeEnum"> <xs:annotation> <xs:documentation> Výčet možného vyjádření výdejních jednotek. V případě, že není vhodná žádná
jednotka ze seznamu, použije se EA. AM
AT AY BA BC BD BE BF BG BI BK BL BO BR BT BX CA CB CE CH CK CL CN CO CP CR CS CT CY DI DR DZ EA GP
Ampoule Assortment Assembly Ball Block Bundle Bale Board Foot Bag Brick Book Barrel Bolt Bar Bottle Box Cartridge Carboy Cone Chest Cake Coil Can Container Capsule Crate Case Carton Cylinder Dispenser Drum Dozen Each Group
(ampule – malá uzavřená láhev) (souprava) (sestava, komplet) (klubko) (blok = 5,5x2,75x1,375 in ÷ 140x 70x35 mm dxšxv) (svazek) (velký svazek, v USA cca 225 kg) (deska, objemová jednotka řeziva) (brašna, pytel, taška – kontejner s poddajnými stěnämi) (cihla – blok keramického mater.) (kniha, svazek listů) (sud, obvykle 158,9 litrů) (bolt, jednotka délky textilu ÷ 36,57 m) (bar, jednotka tlaku) (nádoba, láhev pro tekutiny i plyny) (krabice, bedna, přepravka) (náplň, kazeta, náboj) (láhev na přepravu kapalin, vody i chemikálií objem cca 20 – 60 l) (nádoba, předmět kuželovitého tvaru) (skříň, bedna, truhla, pokladna) (kus, tabulka, slitek) (cívka, kotouč) (kanystr, plechovka, pouzdro) (kontejner, přepravní obal) (ampulka, kapsle, malé pouzdro) (koš, laťová nebo proutěná bedna) (bedna pro přepravu lahví, ovoce) (karton, krabice papírová, lepenková) (válcová nádoba, buben, tlaková láhev) (zásobník, dávkovač) (buben, válcová nádoba pro přepravu sypkého zboží, ocelová i z vláken) (tucet) (univerzální kvalifikátor „každý“, všechno) (hromada, kolekce, seskupení)
ČOS 990503 3. vydání Příloha D (normativní)
D-9
GR GS HD HF HG HK HS HW HY JR KE KT LG LL LO ME MX OT PC PD PG PK PM PO PR PZ QR RA RL RM RO SA SB SC SD SE SH SK SL SO SP SX TI TL TR TT TU VC VI XX
Gross Glass 100 Hundred Feet Half-Gross Hank Hundred Square Feet Hundred Weight Hundred Yard Jar Keg Kit Length Fifty Lot Meal Thousand Outfit Piece Pad Package Pack Plate Pouch Pair Packet Quire Ration Reel Ream Roll Sack Slab Section Skid Set Sheet Skein Spool Square Strip Stick Tin Ten Barrels Tray Tablet Tube Five Hundred Vial Ten
Centigram Decagram Decigram Dram Gram Grain Hundred Pounds Hundred Weight Kilogram Pound Long Ton Milligram Ounce Metric Ton Ton Troy ounce
(centigram, cg = 0,01 g) (dekagram, Dg = 10 g = 0,01 kg) (decigram = 0,1 g) (dram = 1,772 g) (gram, g = 0,001 kg) (grain = 64,79891 mg) (100 liber = 45,359 kg) (= 50,8023 kg – UK) (kilogram, kg = 1 000 g) (libra = 0,45359 kg) (dlouhá tuna = 1 016,05 kg – UK) (miligram = 0,001 g) (unce = 0,02834 kg) (tuna, t = 1 000 kg) (tuna = 2 000 liber = cca 907 kg - USA) (trojská unce = 0,0311 kg)
<xs:enumeration value="QT" /> </xs:restriction> </xs:simpleType> <!--VolumeType--> <xs:complexType name="VolumeType"> <xs:simpleContent> <xs:extension base="xs:double"> <xs:attribute name="unit" type="VolumeTypeEnum" use="required" /> </xs:extension> </xs:simpleContent> </xs:complexType> <!-- ConsignmentType --> <!--***********************************************************************************--> <xs:complexType name="ConsignmentType"> <xs:annotation> <xs:documentation> Popisuje vytvoření zásilky a aktualizaci zprávy v systému sledování NATO. Kromě
obecných informací umožňuje přidání položek k zásilce. Zpráva musí obsahovat kód SSCC nebo obecný identifikátor zásilky. Informace o položce jsou uvedeny v elementu ItemInfo Type.
</xs:sequence> </xs:complexType> <!-- ConsignmentContentType --> <!--***********************************************************************************--> <xs:complexType name="ConsignmentContentType"> <xs:annotation> <xs:documentation> Popisuje informace o položce pro přidání a odebrání položek ze zásilek. Pro zprávu
je nutný kód SSCC nebo obecný identifikátor zásilky. Složení informací o položce je uvedeno v elementu ItemInfoType. Každá zpráva o obsahu zásilky zcela nahradí předchozí obsah zásilky (nepřipouští se přičítání nebo odečítání položek).
Popisuje zprávy, které přijímá systém sledování zásilek NATO. Popis sledování zásilek NATO ve formátu XML může obsahovat jednu nebo zřetězené zprávy. - ConsignmentNotification = umožňuje vytvořit a aktualizovat zásilku. - ConsignmentContent = obsahuje obsah dané zásilky.
- ConsolidateConsignment = dovoluje spojení jedné zásilky s jinou zásilkou.
- DeconsolidateConsignment = dovoluje rozdělení dříve spojených zásilek. - Party identification = dovoluje třetí straně registrovat lokalitu. - TrackMessage = zpráva ze sledování, kterou odešle systém sledování zásilek.
MODEL ARCHITEKTURY SYSTÉMU SLEDOVÁNÍ ZÁSILEK NATO (NATO CT SAM) – PŘÍKLADY ZPRÁV V JAZYKU XML OBSAH PŘÍLOHY E
V příloze E jsou uvedeny příklady zpráv ze systému sledování zásilek NATO podle schémat XML v přílohách C a D. Příklady nepostihují všechny možnosti, které se mohou vyskytnout v praxi.
POZNÁMKA Příklady mají ilustrativní význam. Některé hodnoty elementů a atributů evidentně nevycházejí z reality nebo nemají předepsaný formát. Například regulérní hodnota GLN má 13 znaků, zatímco v příkladech je pouze 6 znaků.
E.1 Zpráva o vytvoření zásilky
!-- Creation of a consignment --> <ConsignmentNotification xmlns="">
Zpráva (nebo část zprávy) obsahuje následující údaje o obsahu zásilky:
zásilka má kód SSCC = 12345678901234567890;
událost nastala, tj. obsah zásilky byl zjištěn, 23. ledna 2000 v 02:20 h Greenwichského času;
zásilka se skládá ze tří položek: - 1. položka je udána třemi identifikátory (RIC, NIC a NSN). Jedná se o textový
popis. Počet je 5, jednotka není udána; - 2. položka je udána identifikátorem NIC. Počet je 5, jednotka není udána; - 3. položka je udána identifikátorem NSN. Počet je 5 souprav.
POZNÁMKA Používá se pro nastavení nebo obnovu celkového obsahu zásilky a zpravidla pouze pro zásilky s utajovaným obsahem.
E.3 Spojení zásilek
<!-- To consolidate a consignment based on SSCC, national identifier --> <ConsolidateConsignment xmlns="">
rodičovská zásilka má kód SSCC = 12345678901234567890;
hlášení podává Nizozemí;
událost nastala, tj. ke spojení zásilek došlo 23. ledna 2000 v 02:20 h Greenwichského času;
stávající lokalita: NL1234 (odpovídá lokalitě v Nizozemí s uvedeným PSČ);
ČOS 990503 3. vydání Příloha E (informativní)
E-3
k uvedené zásilce rodičů se připojují 3 zásilky potomků. Dvě z nich mají své kódy SSCC, třetí je udána alternativním identifikátorem, který je složen z ID, typu ID (je jím TCN) a státu - vlastníka (USA).
E.4 Rozdělení zásilky
<!-- To deconsolidate specific childs from a parent consignment based on SSCC, national identifier-->
První zpráva udává oddělení tří zásilek potomků od zásilky rodičů, z toho dvě zásilky potomků jsou specifikovány svými kódy SSCC a třetí alternativním ID.
Druhá zpráva je příkladem situace, kdy nejsou specifikovány zásilky potomků pro oddělení od zásilky rodičů. V tom případě se zásilka rodičů rozdělí úplně na jednotlivé zásilky potomků.
E.5 Potvrzení příjmu zprávy ze sledování
<!-- A receive advice track message --> <TrackMessage xmlns="">
Zpráva se od předchozí liší pouze svým typem. Je to však změna zásadní, protože uvedené informace (kód SSCC zásilky, stát podávající hlášení, datum a čas události a informace o způsobu identifikace) se vztahují k události detekce zásilky, zatímco v předchozí zprávě se vztahovaly k události vyřazení štítku.
E.10 Zpráva o stavu přepravy
<!-- A transportation status message --> <TrackMessage xmlns="">
Zpráva se týká stejné zásilky jako předchozí zprávy. Hlášení však pochází z jiné lokality v Nizozemí a v ní byla zásilka identifikována místním prostředkem (zařízením). Typem zprávy (událostí) je hlášení o přepravním stavu s výsledkem, že zásilka je zpožděna vůči předpokladu a její technický stav je dobrý.
E.11 Zpráva o identifikaci zúčastněné strany
<!-- A party identification message --> <PartyIdentification xmlns="">
Zpráva uvádí příklad identifikace 4 lokalit ve vlastnictví USA, 4 lokalit ve vlastnictví Nizozemí a 1 lokality ve vlastnictví Dánska. Každá lokalita je určena některým z identifikátorů (NationalLocID, GLN nebo GeoLoc), zeměpisnou polohou v souřadnicích WGS 1984 a textovým popisem.
ČOS 990503 3. vydání
228
(VOLNÁ STRANA)
ČOS 990503 3. vydání Příloha F (informativní)
F-1
MODEL ARCHITEKTURY SYSTÉMU SLEDOVÁNÍ ZÁSILEK NATO (NATO CT SAM) – ZPRÁVY A POŽADAVKY EDI
OBSAH PŘÍLOHY F Strana
F.1 OBECNĚ ..................................................................................................... F-2
F.2 ZPRÁVA S INFORMACEMI O ZÚČASTNĚNÉ STRANĚ, PARTNEROVI (PARTIN) .................................................................................................... F-3
F.2.1 Identifikace zúčastěné strany, partnera ....................................................... F-3 F.2.2 Název zúčastněné strany, partnera ............................................................. F-3
F.3 AVÍZO ODESLÁNÍ (DESADV) (TÉŽ DODACÍ LIST) ................................... F-4 F.3.1 Datum a čas odeslání .................................................................................. F-4 F.3.2 Datum a čas dodání .................................................................................... F-4 F.3.3 .. Místo odjezdu ............................................................................................. F-4 F.3.4 Následující tranzitní uzel ............................................................................. F-4 F.3.5 Příjemce ...................................................................................................... F-4 F.3.6 Způsob dopravy ........................................................................................... F-4 F.3.7 Obsah zásilky .............................................................................................. F-4
F.4 POTVRZENÍ PŘÍJMU (RECADV) ............................................................... F-4 F.4.1 Datum a čas dodání .................................................................................... F-5 F.4.2 Tranzitní uzel nebo cílové místo určení ....................................................... F-5 F.4.3 Totožnost zásilky ......................................................................................... F-5 F.4.4 Nesrovnalosti ............................................................................................... F-5
F.5 ZPRÁVA O STAVU PŘEPRAVY (IFTSTA) ................................................. F-5 F.5.1 Ztráta zásilky ............................................................................................... F-5 F.5.2 Poškození zásilky ........................................................................................ F-5 F.5.3 Zpoždění zásilky .......................................................................................... F-6 F.5.4 Zásilka byla odeslána (do dalšího tranzitního uzlu nebo do cílového
místa určení) ............................................................................................... F-6 F.5.5 Zásilka v termínu ......................................................................................... F-6
ČOS 990503 3. vydání Příloha F (informativní)
F-2
F.1 OBECNĚ
Účelem popsaných zpráv EDI (vzájemné výměny elektronických dat) je výměna informací mezi členskými státy a orgány NATO o totožnosti, lokalitě, pohybu a podmínkách přepravovaných zásilek.
Rozlišují se čtyři typy zpráv: 1. Zpráva s informacemi o zúčastněné straně, partnerovi (PARTIN)
Zpráva tohoto typu se používá pro specifikaci a identifikaci fyzických nebo funkčních lokalit jako jsou vojenské jednotky. Zpráva se vyměňuje při přípravě operace a bude se vyměňovat znovu, když bude nutné aktualizovat její obsah.
2. Avízo odeslání (DESADV) (též dodací list) Zpráva, která se posílá, když odesílatel expeduje zásilku z počátečního místa odeslání nebo když je zásilka odeslána z tranzitního uzlu logistického koloběhu zásobování.
3. Potvrzení příjmu (RECADV) Zpráva, která se posílá, když zásilka je přijata v tranzitním uzlu zásobovacího řetězce nebo když zásilku přijme její příjemce (adresát).
4. Zpráva o přepravním stavu (IFTSTA) Zpráva, která se posílá, když se přeprava zásilky odchyluje od plánovaného průběhu, je potřeba aktualizovat přepravní stav nebo když je potřeba ohlásit rušivou událost.
Všechny zprávy musí sdělit všechny potřebné informace, ale mají mít co nejužší šířku pásma.
Všechny zprávy musí splňovat požadavky EANCOM jako podskupiny UN/EDIFACT, pokud tento ČOS neurčuje jinak.
Různé zprávy uvedené v tomto ČOS obsahují identifikaci zúčastněné strany (partnera) pomocí Globálního lokalizačního čísla (GLN) nebo alternativního identifikátoru partnera.
Globální lokalizační číslo (GLN) je 13-ti místné číslo pro unikátní identifikaci jednotlivých lokalit. Skládá se z:
GS1 předčíslí organizace (7 míst),
identifikace lokality (5 míst),
kontrolní číslice.
GLN je unikátní datová struktura pro identifikaci právní, funkční nebo fyzické lokality jako:
právnických osob, jako vojenských jednotek (např. 1. Mechanizovaná brigáda AČR);
funkčních celků v jednotkách (např. expedice v rámci 1. roty);
fyzických objektů jako konkrétní brána nebo náklad ve skladu (např. brána č. 1 v logistické základně B jednotek SFOR).
Alternativní identifikátor partnera musí obsahovat alternativní typ identifikátoru partnera, který popisuje typ identifikátoru partnera. Všeobecné specifikace GS1 obsahují seznam možných typů (např. kód EAN/DUN, kód SCAC apod.).
ČOS 990503 3. vydání Příloha F (informativní)
F-3
Ačkoli všeobecné specifikace GS1 ponechávají možnost použití alternativního identifikátoru partnera, požaduje se, aby partneři NATO používali GLN vždy, když je to možné.
Země, které používají alternativní identifikaci zúčastněné strany, se musí ujistit, že jejich identifikátory nemohou duplikovat již vydané nebo k vydání připravené GLN.
GLN nebo alternativní identifikátor zúčastněné strany, jehož použití bylo ukončeno, se může použít znovu teprve po uplynutí nejméně tří let. Prodleva musí umožnit, aby se ze souborů partnerů odstranily všechny odkazy na staré GLN. Když se GLN dá zpět do používání, musí se znovu přenést detailní informace o nové straně nebo lokalitě (např. pomocí zprávy PARTIN).
Ve zprávách EDI se čas udává v greenwichském času.
Podrobnosti dohody
Kapitola F.2 pojednává o použití zprávy s informacemi o zúčastněné straně, partnerovi (PARTIN).
Kapitola F.3 pojednává o použití zprávy – avíza odeslání zásilky (DESADV).
Kapitola F.4 pojednává o použití zprávy – potvrzení příjmu zásilky (RECADV).
Kapitola F.5 pojednává o použití zprávy o stavu přepravy (IFTSTA).
F.2 Zpráva s informacemi o zúčastněné straně, partnerovi (PARTIN)
Zpráva tohoto typu musí obsahovat následující informace.
F.2.1 Identifikace zúčastěné strany, partnera
Jedná se totožnost strany (partnera), kterou má příjemce použít podle přání odesílatele. Obvykle půjde o vojenskou jednotku pro doručování zásilek. Údaje o této jednotce budou obsaženy v segmentu zprávy č. 10. Kvalifikátor strany je DP (delivery party – doručitel, přepravní služba) a GLN nebo alternativní identifikátor strany se použijí tak, aby jednotka měla unikátní (jednoznačnou) totožnost.
F.2.2 Název zúčastněné strany, partnera
Je to název (označení) vojenské jednotky pro doručování zásilek. Název musí být obsažen v segmentu zprávy č. 10.
POZNÁMKY
1 Na rozdíl od EANCOM nepotřebuje PARTIN nezbytně adresové údaje jako ulici, číslo popisné, p.o. box, název města, PSČ a stát. Použití těchto údajů se volí podle operačních postupů a stupně utajení specifických operací.
2 Vydávání GLN nebo alternativních identifikátorů vojenských jednotek je záležitostí členského státu.
3 Údaje o zúčastněné straně jsou vyměňovány podle potřeby spolupracujících stran.
ČOS 990503 3. vydání Příloha F (informativní)
F-4
F.3 Avízo odeslání (DESADV) (též dodací list)
Zpráva tohoto typu musí obsahovat následující informace.
F.3.1 Datum a čas odeslání
Jedná se o datum a čas, kdy zásilka opustila místo odjezdu. Místem odjezdu může být výchozí bod odeslání nebo tranzitní uzel. Datum a čas odeslání musí být uvedeny v segmentu zprávy DESADV č. 3. Kvalifikátor data a času odeslání je 11 (konkrétní datum a čas odeslání) a kvalifikátor formátu data a času odeslání je 203 (CCYYMMDDHHMM – rok, měsíc den, hodina, minuta).
PŘÍKLAD Datum a čas 20. ledna 2012, 08:35 h se zapíše: 201220010835.
F.3.2 Datum a čas dodání
Jedná se o plánovaný datum a čas příjezdu zásilky do místa určení. Místem určení může následující tranzitní uzel nebo cílové místo určení. Datum a čas dodání musí být uvedeny v segmentu zprávy č. 3. Kvalifikátor data a času dodání je 359 (konkrétní termín dodání) a kvalifikátor formátu data a času dodání je 203 (CCYYMMDDHHMM – rok, měsíc den, hodina, minuta).
F.3.3 Místo odjezdu
Místo odjezdu se uvede v segmentu zprávy č. 6. Kvalifikátor strany je SH (shipper – dopravce). Pro identifikaci místa odjezdu se použije GLN nebo alternativní identifikátor místa odjezdu. Doplňkové identifikační číslo se může uvést v segmentu č. 7.
F.3.4 Následující tranzitní uzel
Jestliže místem určení zásilky není cílové místo určení, následující tranzitní bod se uvede do segmentu č. 6. Kvalifikátor strany je DP (delivery party – doručitel). Pro identifikaci následujícího tranzitního uzlu se použije GLN. Doplňkové identifikační číslo se může uvést v segmentu č. 7.
F.3.5 Příjemce
Příjemce se uvede v segmentu č. 6. Kvalifikátor strany je UC (Ultimate consignee – konečný příjemce). Pro identifikaci příjemce se použije GLN nebo alternativní identifikátor příjemce. Doplňkové identifikační číslo se může uvést v segmentu č. 7.
F.3.6 Způsob dopravy
Způsob dopravy se uvede v segmentu č. 12.
F.3.7 Obsah zásilky
Tato část zprávy bude popisovat hierarchickou strukturu zásilky v kódu SSCC a je-li to nutné, obsahy příslušných nákladních listů. Totožnost nákladních listů se uvede v segmentu č. 22; označení instrukce je 33E (SSCC). Samotný kód SSCC se uvede v segmentu č. 25, kvalifikátor totožnosti je BJ (Seriál Shipping Container Code – SSCC). Jestliže nějaká část zásilky obsahuje kodifikované položky NATO, NSN se uvede v segmentu č. 27. Kód typu číslo položky je AU (NSN), který je odchylný od EANCOM, ale vyhovuje UN/EDIFACT.
F.4 Potvrzení příjmu (RECADV)
Zpráva tohoto typu musí obsahovat následující informace.
ČOS 990503 3. vydání Příloha F (informativní)
F-5
F.4.1 Datum a čas dodání
Jedná se o skutečné datum a čas příjezdu zásilky do tranzitního uzlu nebo cílového místa určení. Datum a čas dodání musí být uvedeny v segmentu zprávy č. 3. Kvalifikátor data a času dodání je 35 (skutečné datum a čas dodání) a kvalifikátor formátu data a času dodání je 203 (CCYYMMDDHHMM – rok, měsíc den, hodina, minuta).
F.4.2 Tranzitní uzel nebo cílové místo určení
Tranzitní uzel nebo cílové místo určení se uvede v segmentu č. 6. Kvalifikátor strany – tranzitního uzlu je DP (delivery party – doručitel) a pro cílové místo určení je to UC (Ultimate consignee – konečný příjemce). Pro identifikaci tranzitního uzlu nebo cílového místa určení se použije GLN nebo jeho alternativní identifikátor. Doplňkové identifikační číslo se může uvést v segmentu č. 7.
F.4.3 Totožnost zásilky
Pokud celá zásilka bude doručena a přijata bez jakýchkoli nesrovnalostí, její totožnost se může vyjádřit jen v hierarchii zásilky tak, že kód SSCC je v nejvyšší úrovni. Potom se v segmentu č. 11 uvede pouze posloupnost jednotlivých balení v zásilce kódem 1. Kód SSCC se uvede v segmentu č. 15 pomocí kvalifikátoru BJ (SSCC).
F.4.4 Nesrovnalosti
Při zjištění nesrovnalostí zpráva RECADV bude obsahovat posloupnost jednotlivých balení v zásilce v segmentu č. 11 a odpovídající kód SSCC v segmentu č. 15. Počet položek s nesrovnalostmi se uvede v segmentu č. 16. Má-li položka kód NSN, označí se kódem AU. Tento kód je odchylný od EANCOM, ale vyhovuje UN/EDIFACT. Konkrétní nesrovnalost se uvede v segmentu č. 19.
F.5 Zpráva o stavu přepravY (IFTSTA)
Zpráva se posílá, když se přeprava zásilky odchyluje od plánovaného průběhu, je potřeba aktualizovat přepravní stav nebo když je potřeba ohlásit rušivou událost. Kontroly pro zjištění nesrovnalostí se omezí na zjevné fyzické poškození jako je únik, promáčknutí, propíchnutí apod. Není dovoleno zásilky otevírat kvůli hlášení nesrovnalostí.
Zpráva o stavu přepravy se může poslat jednotce odpovědné za přepravu (původci přepravy nebo přepravních prostředků a musí poskytnout následující informace (je-li to možné).
F.5.1 Ztráta zásilky
Ztráta se označí kódem události 49 (ztráta) v segmentu č. 8. V segmentu č. 16 se musí uvést kód SSCC zásilky pomocí kvalifikátoru BJ (SSCC).
F.5.2 Poškození zásilky
Poškození se označí kódem události 18 (poškozena během přepravy) v segmentu č. 8. V segmentu č. 16 se musí uvést kód SSCC zásilky pomocí kvalifikátoru BJ (SSCC).
ČOS 990503 3. vydání Příloha F (informativní)
F-6
F.5.3 Zpoždění zásilky
Zpoždění se označí kódem události 20 (zpožděna během přepravy) v segmentu č. 8. V segmentu č. 10 se uvede nové očekávané datum a čas dodání. Kvalifikátor data a času dodání je 67 (aktuální plánovaný termín dodání) a kvalifikátor formátu data a času dodání je 203 (CCYYMMDDHHMM – rok, měsíc den, hodina, minuta). V segmentu č. 16 se musí uvést kód SSCC zásilky pomocí kvalifikátoru BJ (SSCC).
F.5.4 Zásilka byla odeslána (do dalšího tranzitního uzlu nebo do cílového místa určení)
Další odeslání se označí kódem události 74 (odeslána dále) v segmentu č. 8. V segmentu č. 10 se uvede nové očekávané datum a čas dodání. Kvalifikátor data a času dodání je 67 (aktuální plánovaný termín dodání) a kvalifikátor formátu data a času dodání je 203 (CCYYMMDDHHMM – rok, měsíc den, hodina, minuta). V segmentu č. 12 se uvede další tranzitní uzel. Kvalifikátor strany – dalšího tranzitního uzlu je DP (delivery party – doručitel) a pro cílové místo určení je to UC (Ultimate consignee – konečný příjemce). Pro identifikaci tranzitního uzlu nebo cílového místa určení se použijí GLN nebo jejich alternativní identifikátory. V segmentu č. 16 se musí uvést kód SSCC zásilky pomocí kvalifikátoru BJ (SSCC).
F.5.5 Zásilka v termínu
Událost, že přeprava zásilky probíhá podle časového plánu, se kóduje 31 (na cestě) v segmentu č. 8. V segmentu č. 16 se musí uvést kód SSCC zásilky pomocí kvalifikátoru BJ (SSCC).
ČOS 990503 3. vydání Příloha G (informativní)
G-1
ROZŠIŘITELNÝ ZNAČKOVACÍ JAZYK XML – ZÁKLADNÍ INFORMACE A JEHO POUŽITÍ V SYSTÉMU SLEDOVÁNÍ ZÁSILEK NATO
G.1 Obecně o jazyku XML
XML je zkratkou z výrazu eXtensible Markup Language, který znamená „rozšiřitelný značkovací jazyk“. Jazyk XML byl vytvořen proto, aby umožnil přenos dat v neutrálním formátu bez ohledu na operační systémy zpracovatele a příjemce dat. Data se zapisují mezi tzv. značky (proto „značkovací“ jazyk) neboli elementy a to tak, jak je zamýšlena jejich prezentace. Názvy a počet elementů je neomezen (proto „rozšiřitelný“ jazyk) a přizpůsobuje se dané aplikaci. Názvy elementů se volí pokud možno tak, aby naznačily účel jimi uvozených dat – např. „location“, „item“ (položka). Protože každá aplikace jazyka XML může používat vlastní značky, je nezbytné uložit jejich definici na webu, aby byly přístupné všem uživatelům aplikace. K tomu slouží tzv. jmenné prostory (namespaces). Každý element se zapisuje do lomených závorek. Koncový element je označen lomítkem. Každý element může mít jeden nebo více atributů.
Zatímco vytváření značek je volné, jejich struktura je předepsána a musí se přesně dodržovat. Předpis struktury vychází jednak z obecně závazné struktury XML (data musí být vložena vždy mezi počáteční a ukončovací značku elementu, elementy vnořené do kořenového elementu se nesmí překrývat …), tak z definované struktury pro danou aplikaci (dodržovat pořadí vnořených elementů – pokud je předepsáno, opakování vnořených elementů, typ vkládaných dat mezi dané elementy – např. textový řetězec, číslo, logický výraz atd.). Popis závazné struktury lze vyjádřit několika způsoby, např. pomocí souborů DTD. Novějším způsobem, který je použit také v systému sledování zásilek NATO je popis pomocí souborů XSD (XML Schéma Definition), které udávají strukturu dokumentu XML.
G.2 Schéma XML
Schéma XML definuje:
místa v dokumentu, na kterých se mohou vyskytovat různé elementy,
atributy,
které elementy jsou potomky jiných elementů,
pořadí elementů,
počty elementů,
zda element může být prázdný, nebo zda musí obsahovat text,
datové typy elementů a jejich atributů,
standardní hodnoty elementů a atributů.
Použití XSD:
popisuje přípustný obsah dokumentu,
umožňuje kontrolovat správnost dat,
umožňuje pracovat s daty uloženými v databázi,
umožňuje konvertovat data mezi různými datovými typy.
Schéma XML rozlišuje elementy podle toho, jestli mohou obsahovat potomky, tj. další elementy nebo atributy (complexType – komplexní typ), nebo nemohou (simpleType – jednoduchý typ).
ČOS 990503 3. vydání Příloha G (informativní)
G-2
Veškeré elementy ale i názvy vestavěných datových typů používají prefix xs:
Schéma XML se zapisuje v textové formě a doplňkově se vyjadřuje graficky. Textový zápis má být přehledný, což se dosahuje zejména odsazováním elementů od levého okraje stránky. Začátek a konec elementu má mít stejné odsazení, elementy vnořené do určitého elementu jsou více odsazeny. Je-li schéma XML uvedeno v textovém dokumentu, obvykle se používá odlišení od jiného textu – např. jiným typem písma, velikostí nebo barvou fontu. Grafické vyjádření podává názorný přehled o souvislostech a návaznosti jednotlivých elementů, neobsahuje však všechny potřebné informace – např. předpis datového typu.
Základní prvky schémat XML
Element – je základní prvek schéma XML, který musí mít vždy počátek a konec.
Tag – je zápis elementu v lomených závorkách, např. <xs:documentation> - je to zároveň příklad počátečního tagu. Koncový tag se odlišuje lomítkem před názvem elementu, např. </xs:documentation>. Uvedený element má význam popisu a tento popis se pak v dokumentu XML vkládá mezi počáteční a koncový tag.
Atribut – je hodnota či vlastnost, kterou může nabývat element. Atributy jsou buď povinné (musí být udána jejich hodnota) nebo volitelné. Některé atributy mohou nabývat typové hodnoty, hodnoty jiných se vybírají ze seznamu.
Příklady a význam prvků pro grafické vyjádření schéma XML
Obsah elementu
Element obsahující text (symbol odstavce v levém horním rohu naznačuje, že obsahem je čistý text nebo smíšený text)
Element s indikátory
Element se subelementy, které se mohou nacházet v jiném schématu. To vyjadřuje znak „+“.
Element je povinný (rámeček je z plné čáry)
Element je nepovinný, volitelný (rámeček je z čárkované čáry)
Element je povinný a opakovatelný
Element je nepovinný a opakovatelný
Atributy
Atribut elementu, povinný
Konektory
Sled rozvětvení, povinný. Připojené elementy ve stanoveném pořadí musí být v seznamu připojitelných elementů ke konektoru.
ČOS 990503 3. vydání Příloha G (informativní)
G-3
Sled rozvětvení, nepovinný a opakovatelný. Připojené elementy musí být v seznamu připojitelných elementů ke konektoru. V připojené větvi musí být elementy ve stanoveném pořadí.
Volba větví, povinná. Z definovaných větví musí být vybrána právě jedna.
Volba větví, nepovinná a opakovatelná. Z definovaných větví může být vybrána jedna nebo několik v libovolném pořadí. Avšak nemusí být vybrána žádná větev.
Volba větví, povinná a opakovatelná. Z definovaných větví může být vybrána jedna nebo několik v libovolném pořadí. V připojené větvi se volí jeden z několika elementů.
Na 2. řádku je odkaz na jmenný prostor (xmlns) na webu. Deklarace „sequence: značí, že vnořené elementy musí následovat v daném pořadí (pokud by mohlo být pořadí elementů libovolné, použila by se deklarace „choice“). Výrazy „string“ značí, že data v daném elementu se zapisují jako textový řetězec. Naproti tomu „integer“ znamená, že se musí vždy vložit kladné celé číslo. Počet dětí tedy nelze zapsat slovy „pět“.
Uvedenému schéma vyhovuje následující dokument XML
Povinný 1. řádek udává, že se jedná o dokument XML a použité kódování. Kořenovým elementem je element „uzivatel“, který má atribut „uid“. Hodnota atributu je 6541. Jedná se o nějaký identifikátor, např. osobní číslo zaměstnance. Vnořenými elementy jsou „jmeno“, „uzivatel“ a „pocetDeti“. Přenášená data jsou zřejmě určena pro nějakou databázi, proto mají uvedené členění. Tato data lze zapsat i souhrnně:
ČOS 990503 3. vydání Příloha G (informativní)
G-4
Jiří Novák, osobní číslo 6541, počet dětí 5 – pak by bylo nutné použít vhodný element (např. „para“- tj. textový odstavec) a data by byla využitelná v nějaké popisné informaci o zaměstnanci (a bylo by potřeba též upravit schéma XML). V označení elementu je nutné přesně dodržovat velká a malá písmena. Data se musí vkládat vždy mezi počáteční a koncový element – např. <prijmeni>, </prijmeni>.
G.3 Převod dat ve formátu XML
Data zapsaná ve formátu XML je třeba převést u příjemce zprávy do obvyklého čitelného tvaru (obvykle do formátu .pdf, příp. .doc). K tomu slouží transformace XSLT, která se provádí pomocí procesoru XSLT. Procesorem je míněn program podporující tuto transformaci. Procesor XSLT může být napsán v libovolném programovacím jazyce nebo využít knihovny XSLT daného programovacího jazyka.
Podrobnější vysvětlení k jazyku XML a souvisejícím datovým formátům lze nalézt v řadě odkazů na webu.
G.4 Použití formátu XML v systému sledování zásilek NATO
Elementy, atributy a schémata XML jsou popsány a definovány v přílohách C a D tohoto ČOS. Jmenný prostor je na webové adrese https://lognet.nc3a.nato.int/NATOTracking.
Názvy elementů a atributů se používají v anglickém originálu (aby souhlasily se jmenným prostorem). Pro použití v rámci NATO je nutné používat v angličtině také textové údaje (např. zkratky jednotek, doprovodný text).
Pro výhradní použití v rámci ČR lze vytvořit českou verzi s názvy elementů a atributů v českém jazyku; v tom případě je nutné vytvořit vlastní jmenný prostor.
POZNÁMKA Pojem tag pro způsob zápisu elementu XML je v jazyku XML zcela běžný a frekventovaný.
G.5 Předpoklady implementace ČOS 990503 na zprávy ze sledování zásilek v jazyku XML
Schéma XML podle ČOS 990503 (resp. podle STANAG 2185, Ed. 3) je celkem jednoduché a zprávy ze sledování by bylo možné napsat bez použití speciálního softwaru – např. v Notepadu (poznámkovém bloku). Obecně se však doporučuje i v jednoduchých případech používat specializovaný aplikační software, který má zejména následující přednosti:
snadná a rychlá editace dokumentu XML v režimu WYSIWYG ("Co vidíte, to dostanete“),
vestavená kontrola správnosti zápisu – syntaxe XML,
zobrazení příchozích zpráv v požadovaném výstupním tvaru.
Snadná a rychlá editace spočívá zpravidla v nabídce elementů, atributů a jejich hodnot – např. volby jednotky hmotnosti, délky, objemu ze seznamu definovaných (použitelných) hodnot. Tím se odstraní činnost, která je při ručním zápisu nezáživná, zdlouhavá a může být častým zdrojem chyb (např. vkládání lomených závorek, důsledné používání malých a velkých písmen v označení elementů a atributů). Obsluha se tak může soustředit na vkládání zjištěných dat a snižují se nároky na její kvalifikaci. Software také zajistí, že struktura odeslané zprávy splňuje všechny požadavky odpovídajícího schéma XML, což je základní předpoklad, aby byla pro příjemce čitelná a využitelná.
UNIFIKOVANÝ MODELOVACÍ JAZYK UML – DOPLŇUJÍCÍ INFORMACE O JEHO POUŽITÍ V SYSTÉMU SLEDOVÁNÍ ZÁSILEK NATO
H.1 Obecně o jazyku UML
UML (Unified Modeling Language) byl navržen pro snadné zachycení skutečností do grafické podoby. V softwarovém inženýrství se používá pro vizualizaci, specifikaci, navrhování a dokumentaci programových systémů. UML nabízí standardní způsob zápisu jak návrhů systému včetně konceptuálních prvků jako jsou business procesy a systémové funkce, tak konkrétních prvků jako jsou příkazy programovacího jazyka, databázová schémata a znovupoužitelné programové komponenty.
UML podporuje objektově orientovaný přístup k analýze, návrhu a popisu programových systémů. UML neobsahuje způsob, jak se má používat, ani neobsahuje metodiku, jak analyzovat, specifikovat či navrhovat programové systémy.
Má, na rozdíl od převážně textově orientovaných programovacích jazyků, vlastní grafickou syntaxi (tj. pravidla pro sestavování jednotlivých elementů jazyka do větších objektů) a sémantiku (tj. jednoznačná pravidla určující jednotlivým syntaktickým výrazům jejich význam).
Výhody grafické notace:
grafická notace je mezinárodní a mezikulturní,
grafické notaci porozumí i člověk, který neumí programovat,
grafickou notaci je snadnější pochopit,
grafická notace je většinou úsporná.
Nevýhody grafické notace:
stručný diagram nemusí být úplný,
úplný diagram nemusí být přehledný,
špatný diagram je horší než žádný diagram (nebo dobrý slovní popis).
H.2 Použití jazyka UML v systému sledování zásilek NATO
V systému sledování zásilek NATO se jazyk UML používá k vyjádření, jaké požadavky má uvedený systém splňovat. Nejpoužívanějšími nástroji přitom jsou diagramy případů užití (diagramy use case) a diagramy aktivit, které jsou vysvětleny v úvodních kapitolách přílohy B. Uvedený systém však používá i další nástroje jazyka UML – objektový diagram, diagram tříd a diagram balíčků.
Typ použitého diagramu se označuje v levém horním rohu diagramu zkratkou před názvem diagramu takto: ud – diagram případu užití (use case), ad – diagram aktivit, od – objektový diagram, cd – diagram tříd, pd – diagram balíčků.
Objektem může být osoba, místo, věc, událost, koncepce nebo sestavy. Objekt lze také chápat jako popis jedince ve skupině, zatímco třídy popisují vlastnosti sdílené skupinou.
Objekt je uzavřený, lokální data jsou obalena metodami, ale ani metody nejsou zvenčí přístupné - jediný způsob, jak použít objekt či jak s ním komunikovat, je poslat objektu zprávu: pak objekt spustí svou metodu, která může použít atributy objektu a další metody objektu, může také poslat zprávu jinému objektu.
Objektový diagram (Object Diagram) je snímkem objektů a jejich vztahů v systému v určitém časovém okamžiku. Používá se především pro znázornění určité konfigurace objektů či zobrazení vzájemně propojených objektů. Objektový diagram může být chápán jako speciální případ diagramu tříd vytvářený za účelem zdůraznit vazby mezi instancemi
Objektový diagram je užitečný také v počátečních fázích projektu pro modelování ukázek problémové domény, které odhalují objekty a jejich vztahy. Často se také používá pro modelování testovacích případů (test cases) pro ověření správnosti diagramu tříd.
Objektovými diagramy v tomto ČOS jsou obrázky A.4 až A.8.
H.2.2 Diagram tříd
Třída reprezentuje šablonu pro objekty a popisuje interní strukturu těchto objektů.
Diagram tříd (Class Diagram) představuje „statický pohled na modelovaný systém“ a jeho úkolem je znázornit typy objektů v systému a jejich vztahy. Návrh tříd, jejich odpovědností a následné vytvoření tohoto diagramu je jedním z prvních a základních kroků analýzy navrhovaného programového systému.
Mezi prvky používané v diagramu tříd lze zařadit třídy (classes), asociace (associations), rozhraní (interfaces) a popřípadě balíčky (packages). Každá třída má popsány vlastnosti a operace (souhrnně označovány jako features), které může provádět, a omezení definující, jak mohou být jednotlivé třídy propojeny. Vlastnosti tříd jsou v UML označovány jako atributy, operace ve fázi návrhu jako metody (V rámci analýzy se používá označení operace). Třídy jsou vzájemně propojeny pomocí asociací.
Diagramy tříd v tomto ČOS jsou obrázky B.22 až B.24. Význam použitého zobrazení lze demonstrovat na výřezu z diagramu na obrázku B.23:
- «PK» SSCC: celé číslo - alternativní ID: celé číslo - typ alternativního ID: typ identity zásilky ………
Zásilka
- «FK» kód události: typ kód události - DT události: datum a čas …………
Instance historie zásilky
1 0..*
ČOS 990503 3. vydání Příloha H (informativní)
H-3
Třída je znázorněna obdélníkem. V horní části je uveden název třídy, pod ním je seznam atributů.
Atributy jsou uvozeny symbolem přístupnosti. Symbol „-„ značí, že atribut je přístupný jen uvnitř třídy. Symbol „+“ (použitý u jiných tříd na obrázku B.22) značí, že je přístupný ze všech tříd.
Relace (vztah) mezi dvěma (popř. více než dvěma) třídami jsou asociace. Instance asociace (link - vazba) je n-tice (seřazený seznam) referencí na objekty, tj. link má přesně specifikováno, který jeho konec je připojen na který objekt. Asociace právě určuje kolekci takových linků. Linky mohou mít názvy (viz obrázky B.22 a B.23).
Násobnost (multiplicity) udává, jaký počet objektů se v libovolném okamžiku účastní vztahu. Násobnost se udává ve tvaru minimum...maximum, popř. přesná hodnota. Implicitní násobnost je [1].
Syntaxe násobnosti:
1 přesně jedna
5 přesně pět
0..1 nula nebo jedna
* nula nebo více
0..* nula nebo více
1..* jedna nebo více
2..8 dva až osm
V uvedeném výřezu instance historie zásilky je vždy jedna, zatímco zásilka může být neomezený počet (včetně žádné).
Řiditelnost (navigability) určuje, že objekt zdrojové třídy vidí objekt cílové třídy, že mu může poslat zprávu. Objekt z cílové třídy na objekt zdrojové třídy nevidí, neví o něm a nemůže mu poslat zprávu (toto ale neplatí doslova - pokud nějak získá odkaz na zdrojový (či na jakýkoliv jiný) objekt, tak mu zprávu poslat může). Asociace bez šipek je obousměrná (jakoby šipky byly na obou koncích), tj. objekty na sebe navzájem vidí a mohou si posílat zprávy (asociace zobrazená bez šipek ovšem může znamenat také to, že zobrazení šipek je potlačeno).
Kromě vztahu asociace se používají specifičtější vztahy agregace a kompozice.
Agregace (seskupování) je zvláštním typem asociace. Znázorňuje složení objektů jedné třídy z objektů jiných tříd (objekt je agregací objektů jiných tříd). Znázorňuje se kosočtvercem s navazující čarou (čára mívá jednoduchou šipku, ale šipka se nemusí použít).
Kompozice (skladba) je nejsilnějším z trojice vztahů asociace – agregace – kompozice. Odkazovaný objekt je zásadní součástí majitele. Existence
+ typ hlášení: typ ohlašovací zpráva
Typ zpráva ze sledování
+ datum a čas události: čas. razítko + ohlášeno státem: 2 znaky
Typ záhlaví zprávy 1
ČOS 990503 3. vydání Příloha H (informativní)
H-4
odkazovaného objektu bez majitele nemá smysl. Zánikem majitele tak většinou zaniká i odkazovaný objekt. Znázorňuje se obdobně jako agregace s rozdílem, že kosočtverec je vyplněný (černou barvou). Příklad kompozice je na obrázku B.24.
H.2.3 Diagram balíčků
Balíček (Package) - umožňuje uspřádat prvky diagramu do skupin (např. pro účely znázornění podsystému).
Diagram balíčků (Package Diagram) umožňuje sdružit elementy modelů UML (např. třídy či případy užití) do skupin a mezi těmito skupinami znázornit závislosti.
Typicky se balíčky používají pro sdružení souvisejících tříd. Balíčky mohou být členy jiných balíčků, a tak je možné vyjádřit hierarchickou strukturu. Důležité je, že v rámci jednoho balíčku musí mít třídy vždy unikátní název.
Sdružování tříd do balíčků se může provádět buď podle architektury aplikace (uživatelská rozhraní, logika, číselníky), nebo dle různých tematických oblastí (např. leasing, aktiva, zákazník atd.).
Diagramy balíčků v tomto ČOS jsou obrázky B.6 a B.7.
ČOS 990503 3. vydání
246
(VOLNÁ STRANA)
ČOS 990503 3. vydání
247
(VOLNÁ STRANA)
ČOS 990503 3. vydání
248
Účinnost českého obranného standardu od: 23. listopadu 2017
Změny:
Změna číslo
Účinnost od Změnu zapracoval Datum
zapracování Poznámka
U p o z o r n ě n í: Oznámení o českých obranných standardech jsou uveřejňována měsíčně ve Věstníku Úřadu pro technickou normalizaci, metrologii a státní zkušebnictví v oddíle „Ostatní oznámení“ a Věstníku MO.
V případě zjištění nesrovnalostí v textu tohoto ČOS zasílejte připomínky na adresu distributora
Rok vydání: 2020, obsahuje 124 listů Distribuce: Odbor obranné standardizace Úř OSK SOJ, nám. Svobody 471/4, 160 01
Praha 6 Vydal: Úřad pro obrannou standardizaci, katalogizaci a státní ověřování jakosti www.oos.army.cz NEPRODEJNÉ
