ES o meradlách)

WELMEC 7.2 Vydanie 2

WELMEC Európska spolupráca v legálnej metrológii

Príru ka o softvéri (Smernica 2004/22/ES o meradlách)

Január 2008

Realizované s finan nou podporou Európskej únie v rámci programu Prechodný fond

WELMEC WG7

Príru ka o softvéri

WELMEC 7.2, vydanie 2

WELMEC Európska spolupráca v legálnej metrológii

WELMEC je spolupráca medzi autoritami v oblasti legálnej metrológie lenských štátov Európskej únie a EFTA. Tento dokument je jednou z príru iek publikovaných WELMEC, ktorých cie om je poskytnú návod výrobcom meradiel a notifikovaným orgánom zodpovedným za posudzovanie zhody ich výrobkov. Príru ky majú isto odporú ajúci charakter a samy o sebe nekladú žiadne obmedzenia alebo dodato né technické požiadavky nad rámec príslušných smerníc ES. Možno akceptova aj iné alternatívne prístupy, ale návody poskytnuté v tomto dokumente reprezentujú uvážený názor WELMEC pokia ide o najlepšiu prax, pod a ktorej by sa malo postupova .

Vydal: Sekretariát WELMEC, BEV Arltgasse 35 A-1160 Viede Rakúsko Tel: +43 676 8210 3608 Fax: +43 1 49 20 875 8006 E-mail: [email protected] Website: www.welmec.org

2 Realizované s finan nou podporou Európskej únie v rámci programu Prechodný fond

WELMEC WG7



Príru ka o softvéri (Smernica o meradlách 2004/22/ES) Obsah Predslov................................................................................................................................................... 5 1

ÚVOD.............................................................................................................................................. 6

2

Terminológia ................................................................................................................................... 7

3

Ako s touto príru kou pracova ..................................................................................................... 10 3.1

Všeobecná štruktúra príru ky................................................................................................... 10

3.2

Ako vybra príslušné asti príru ky .......................................................................................... 12

3.3

Ako pracova so skupinou požiadaviek.................................................................................... 13

3.4

Ako pracova s kontrolnými záznamami .................................................................................. 14

4

Základné požiadavky na softvér v jednoú elových meracích prístrojoch (Typ P) .............. 15 4.1

Technický popis........................................................................................................................ 15

4.2

Špecifické požiadavky na Typ P............................................................................................... 16

5

Základné požiadavky na softvér meradlách využívajúcich univerzálny po íta (Typ U).... 23 5.1

Technický popis........................................................................................................................ 23

5.2

Špecifické požiadavky na Typ U .............................................................................................. 24

6

Rozšírenie L: Dlhodobé uchovávanie nameraných dát .......................................................... 34 6.1

Technický popis........................................................................................................................ 34

6.2

Špecifické požiadavky na softvér na dlhodobé uchovávanie ................................................... 35

7

Rozšírenie T: Prenos meraných dát cez komunika né siete ................................................. 43 7.1

Technický popis........................................................................................................................ 43

7.2

Špecifické požiadavky na softvér na dátový prenos ................................................................ 44

8

Rozšírenie S: Oddelenie softvéru ............................................................................................. 51 8.1

Technický popis........................................................................................................................ 51

8.2

Špecifické požiadavky na softvér na rozdelenie softvéru......................................................... 52

9

Rozšírenie D. S ahovanie softvéru legálnej metrológie ......................................................... 55 9.1

Technický popis........................................................................................................................ 55

9.2

Špecifické požiadavky na softvér ............................................................................................. 56

10

Rozšírenie I: Špecifické požiadavky na softvér pre konkrétne meradlo............................... 61

10.1

Vodomery ............................................................................................................................. 64

10.2

Plynomery a prepo ítava e objemu..................................................................................... 69

10.3

Elektromery na meranie aktívnej energie ............................................................................ 77

10.4

Mera e tepla ........................................................................................................................ 83

10.5 Meracie zostavy na kontinuálne a dynamické meranie prete eného množstva kvapalín okrem vody ........................................................................................................................................ 88 10.6

Vážiace zariadenia............................................................................................................... 89


WELMEC WG7



10.7

Taxametre ............................................................................................................................ 95

10.8

Materializované miery .......................................................................................................... 98

10.9

Meradlá rozmerov ................................................................................................................ 99

10.10

Analyzátory výfukových plynov .......................................................................................... 100

11

Definícia triedy rizika ................................................................................................................ 101

11.1

Všeobecný princíp.............................................................................................................. 101

11.2

Popis úrovní ochrany, skúšania a zhody ........................................................................... 101

11.3

Odvodenie tried rizika ........................................................................................................ 102

11.4

Interpretácia tried rizika...................................................................................................... 102

12

Vzor správy o skúške (vrátane kontrolných záznamov)....................................................... 104

12.1

Vzor pre všeobecnú as správy o skúške ........................................................................ 105

12.2 Príloha 1 správy o skúške: Kontrolné záznamy podporujúce výber primeraného súboru požiadaviek ...................................................................................................................................... 108 12.3

Príloha 2 správy o skúške: Špecifické kontrolné záznamy pre konkrétne technické asti 109

12.4

Informácie, ktoré majú by sú as ou certifikátu skúšky typu ............................................. 113

13

Krížové referencie pre softvérové požiadavky MID na lánky a prílohy MID ..................... 114

13.1

Stanovené softvérové požiadavky, vz ah k MID................................................................ 114

13.2

Interpretácia lánkov a príloh MID k Softvérovým požiadavkám MID ............................... 116

14

Literatúra ................................................................................................................................... 120

15

História revízie .......................................................................................................................... 120

16

Index........................................................................................................................................... 121


WELMEC WG7



Predslov Tento dokument vychádza na základe dokumentu „Požiadavky na softvér a príru ka validácie“, verzia 1.00 z 29. októbra 2004, vypracovaného v rámci projektu „MIDSoftvér“, ktorý sa s podporou Európskej komisie uskuto nil pod registra ným íslom G7RT-CT-2001-05064 v období od januára 2002 do decembra 2004. Príru ka má iba odporú ací charakter a neobsahuje žiadne obmedzenia alebo dodato né technické požiadavky, okrem tých, ktoré sú obsiahnuté v MID. Môžu by akceptovate né len ako alternatívne prístupy, ale nasledovné poradenstvo poskytnuté v tomto dokumente predstavuje stanovisko WELMECU, o sa týka najlepšej praxe. Aj ke je príru ka zameraná na meradlá regulované smernicou MID, výsledky majú všeobecnú povahu a môžu by aplikované aj v iných oblastiach.


WELMEC WG7

1



ÚVOD

Tento dokument poskytuje poradenstvo každému, kto sa zaoberá aplikáciou smernice o meradlách (MID), obzvláš pre softvérové vybavenie meradla. Je adresovaný výrobcom meradiel a notifikovaným osobám, ktoré sú zodpovedné za posúdenie zhody meradiel. Dodržaním tejto príru ky sa môže predpoklada , že sú splnené požiadavky týkajúce sa softvéru. Predpokladá sa, že všetky notifikované osoby akceptujú túto príru ku ako výklad smernice MID v otázkach týkajúcich sa softvéru. Ako príklad previazania požiadaviek tejto príru ky a požiadaviek smernice MID sú v kapitole 13 uvedené krížové referencie. Táto príru ka vychádza z príru ky 7.1, vypracovanej skupinou WELMEC WG7. Obidve príru ky majú základ na rovnakých princípoch a boli odvodené z požiadaviek smernice MID. Príru ka 7.1 bola revidovaná a na alej existuje (vydanie 2), ale v sú asnej dobe má len informatívny charakter, zatia o príru ka 7.2 je jednou z tých, ktoré majú odporú ací charakter WELMEC pre softvéroví vývoj, skúšanie a validáciu softvéru na kontrolovanie meradiel, ktoré spadajú pod smernicu MID. Najnovšie informácie týkajúce sa príru iek a práce pracovnej skupiny WELMEC WG 7 sú k dispozícii na webovej stránke http://www.welmecwg7.ptb.de.


WELMEC WG7

2



Terminológia

Terminológia vysvetlená v tejto asti opisuje sloví ka, tak ako sú použité v tejto príru ke. Odkazy na normy alebo na hociktoré iné zdroje sú stanovené, ak je definícia kompletná alebo je vzatá zo základných astí. Prijate né riešenie: návrh alebo princíp softvérového modulu alebo hardvérovej jednotky alebo funkcie, ktorá je považovaná za prijate nú s konkrétnymi požiadavkami. Prijate né riešenia poskytujú príklad, ako môžu by splnené konkrétne požiadavky. Nie sú poškodené iné riešenia, ktoré tiež sp ajú požiadavky. Kontrolný záznam: softvérový íta (napr. „ íta udalostí“) a/alebo informa ný zapisova (napr. „zapisova udalostí“) zmien softvéru alebo parametra pre legálnu metrológiu. Autentifikácia: overenie vyhlásenia alebo konštatovania zhodnosti užívate a, postupu alebo zariadenia. Základná konfigurácia: návrh meradla s oh adom na základnú architektúru. Rozlišujeme dve základné konfigurácie: jednoú elové meradlo a meradlo využívajúce univerzálny po íta . Termíny sú primerané k použitiu na iastkových zostavách. Jednoú elové meradlo (typ P): meradlo navrhnuté a zostrojené špeciálne pre konkrétny ú el. Kompletný aplika ný softvér je konštruovaný pre primerané meracie ú ely. Podrobnejší popis je uvedený v kapitole 4.1. Uzavretá sie : sie s pevným po tom ú astníkov s nemennými identifikáciami, funkciami a rozmiestnením (pozri tiež otvorená sie ). Komunika né rozhranie: elektronické, optické, rádiové alebo iné technické rozhranie, ktoré umož uje automatické prevzatie informácii medzi komponentmi meradla, iastkových zostáv alebo externými zariadeniami. Špecifické parametre zariadenia: legálne relevantné parametre s hodnotou, ktorá závisí na individuálnom meradle. Špecifické parametre zariadenia zah ajú kalibra né parametre (napr. nastavenie rozsahu alebo iné úpravy alebo korekcie) a konfigura né parametre (napr. maximálna hodnota, minimálna hodnota, jednotka merania at .). Môžu by nastavované alebo vybraté len v špeciálnom opera nom režime meradla. Špecifické parametre zariadenia môžu by klasifikované ako tie, ktoré by mali by zabezpe ené (nemenné) a tie, ktoré môžu by sprístupnené (nastavite né parametre) autorizovanej osobe, napr. vlastníkovi meradla alebo predajcovi tovaru. Stanovený softvér: as softvéru definované ako stabilná v skúške typu, t.j. menite ná len so schválením NO. Stabilná as je identická v každom individuálnom meradle. Integrovaná pamä : neodstránite né uchovávanie, ktoré je sú as ou meradla, napr. RAM, EEPROM, pevný disk. Neporušite nos dát a softvéru: záruka, že data a softvér neboli predmetom nejakých neoprávnených zmien v priebehu používania, prenosu alebo uchovávania. Konfigurácia IT: návrh meradla s oh adom na funkcie a vlastnosti IT sú – pokia ide o požiadavky – nezávislé od funkcii merania. V tejto príru ke sú stanovené štyri konfigurácie IT: dlhodobé uchovávanie nameraných dát, prenos nameraných dát, s ahovanie softvéru a rozdelenie softvéru (pozri tiež základnú konfiguráciu). Termíny 7 Realizované s finan nou podporou Európskej únie v rámci programu Prechodný fond

WELMEC WG7



sú primerane použite né na iastkové zostavy. Legálne relevantné parametre: Parameter meradla alebo iastkovej zostavy podliehajú kontrole z h adiska legálnej metrológie. Typy legálne relevantných parametrov môžeme rozpoznáva nasledovne: typovo-špecifické parametre a špecifické parametre zariadenia. Legálne relevantný softvér: programy, data a typovo-špecifické parametre pre dané meradla alebo iastkovú zostavu a charakterizujú alebo plnia funkcie, ktoré sú predmetom kontroly z h adiska legálnej metrológie. Dlhodobé uchovávanie meraných dát: pamä používaná pre uchovávanie meraných dát po ukon ení merania za ú elom ich neskoršieho využitie v legálnej metrológii (napr. po skon ení obchodnej transakcie). Meradlo: akéko vek zariadenie alebo systém s meracou funkciou. Prídavné meno „merací“ vypúš ame, ak nie je možná zámena. [MID, lánok 4] Meradlo využívajúce univerzálny po íta (typ U): meradlo, ktoré zah a univerzálny po íta , zvy ajne založenom za základe PC systému, pre funkcie, ktoré sú predmetom kontroly z h adiska legálnej metrológie. Za systém typu U sa považujú tie meradlá, ktoré nesplnili podmienky na jednoú elový merací prístroj (typ P). Otvorená sie : sie s ubovo ným po tom ú astníkov (zariadenia s ubovo nými funkciami). Po et, identita a umiestnenie ú astníkov sa môže dynamicky meni a nemusí by jednotlivým ú astníkom známa (pozri tiež uzavretú sie ). Trieda rizika: trieda typov meradla s porovnate ným rizikom. S ahovanie softvéru: proces automatického prenosu softvéru do cie ového meradla alebo hardvérovej jednotke, ktorá využíva hocijaké technické prostriedky z lokálneho alebo vzdialeného zdroja (napr. vymenite né pamä ové média, prenosný po íta , vzdialený po íta ) prostredníctvom ubovo ného pripojenia (napr. priame prepojenie, siete). Identifikácia softvéru: sekvencia itate ných znakov softvéru spojených s identitou softvéru (napr. íslo verzie, kontrolný sú et).

jednozna ne

Oddelenie softvéru: jednozna né rozdelenie softvéru na legálne relevantný softvér a na legálne nerelevantný softvér. Ak neexistuje takéto rozdelenie softvéru, tak celý softvér sa považuje za legálne relevantný. iastková zostava: hardvérové zariadenie (hardvérová jednotka), ktorej funkcie sú nezávislé a spolu s inými kompatibilnými iastkovými zostavami (alebo meradlami) tvorí meradlo [MID, lánok 4]. Prenos meraných dát: prenos meraných dát cez komunika nú sie alebo iné prostriedky vzdialeného zariadenia za ú elom ich alšieho spracovania a/alebo využitie v oblasti legálnej metrológie. TEC: certifikát skúšky typu. Typovo-špecifický parameter: legálne relevantný parameter s hodnotou, ktorá je závislá len na type meradla. Typovo-špecifické parametre sú as ou legálne relevantného softvéru. Sú pevne stanovené v skúške typu meradla. Užívate ské rozhranie: rozhranie tvoriace as meradla alebo meracieho systému, ktoré umož uje odovzdanie informácii medzi užívate om ako lovekom a meradlom alebo ich hardvérovými alebo softvérovými komponentmi, ako napr. prepína , 8 Realizované s finan nou podporou Európskej únie v rámci programu Prechodný fond

WELMEC WG7



klávesnica, myš, displej, monitor, tla iare , dotyková obrazovka. Validácia: potvrdenie skúškou a objektívne overite ným dôkazom (napr. informácia dokazujúca pravdu, založená na faktoch získaných zo záznamov, meraní, skúšok, at .), že sú splnené konkrétne požiadavky s oh adom na zamýš ané použitie meradla. V tomto prípade sú zamýš anými požiadavkami tie, ktoré sú v smernici MID. Nasledovné definície sú skôr špecifické. Sú použité len v niektorých rozšíreniach a pre triedy rizika D alebo vyššie. Hash algoritmus: algoritmus, ktorý komprimuje obsahy z bloku dát do ísla definovaného d žkou (hash kód) tak, že zmena akéhoko vek bitu v bloku dát vedie v praxi k inému hash kódu. Hash kód je vyberaný tak, že je malá pravdepodobnos dvoch rozdielnych blokov dát, ktoré by mali rovnaký hash kód. Algoritmus podpisu: kryptografický algoritmus, ktorý šifruje (zakóduje) jasný text do kódovaného textu (skrytého alebo tajného textu) s použitím k ú a podpisu, a ktorý umož uje dekódovanie kódového textu, ak je k dispozícii príslušný dekódovací k ú . K ú podpisu: hocijaké íslo alebo sekvencia znakov používaná pri zakódovaní a dekódovaní informácii. Existujú dve rozdielne triedy k ú ov podpisu: symetrické systémy k ú a alebo nesymetrické systémy k ú a. Symetrický k ú znamená, že vysiela a prijíma informácii používajú rovnaký k ú . Nesymetrickým systémom k ú a je nazývaný vtedy, ke k ú e pre vysiela a prijíma sa odlišujú, ale sú navzájom kompatibilné. Zvy ajne k ú vysiela a je známy vysiela u a k ú prijíma a je verejný pre definované prostredie. Systém verejného k ú a (PKS): pár dvoch rozdielnych k ú ov podpisu, z ktorých jeden je súkromným k ú om a druhý je verejným k ú om. Aby bolo možné overi integritu a autentickos informácii, hash hodnota informácii je vygenerovaná hash algoritmom, ktorý je zakódovaný so súkromným k ú om vysiela a tvoreného podpisom, ktorý sa dá dekódova prijíma om s použitím verejného k ú a vysiela a. Infraštruktúra systému verejného k ú a (PKI): organizácia zaru í dôveryhodnos systému verejného k ú a. S týmto súvisí udelenie a distribúcia digitálnych certifikátov všetkým lenom, ktorý sa zú ast ujú na výmene informácii. Certifikácia k ú ov: proces pridelenia hodnoty verejného k ú a jednotlivcovi, organizácii alebo inému subjektu. Elektronický podpis: krátky kód (podpis), ktorý je jasne priradený k textu, bloku da alebo binárnemu súboru softvéru na preukázanie integrity a autentickosti uchovávaných alebo prenesených dát. Podpis je vytvorený za použitia algoritmu podpisu a súkromného k ú u. Vytvorenie elektronického podpisu sa obvykle skladá z dvoch krokov: (1) po prvé hash algoritmus skomprimuje objem informácii k podpisu do krátkej hodnoty, a (2) potom algoritmus podpisu skombinuje toto íslo so súkromným k ú om k vytvoreniu podpisu. Dôveryhodné centrum: združenie, ktoré je dôveryhodné a vytvára, udržuje a vydáva informácie oh adne autentickosti verejných k ú ov od osôb alebo iných subjektov, napr. o meradlách.


WELMEC WG7

3



Ako s touto príru kou pracova

Táto sekcia popisuje štruktúru príru ky a vysvet uje ako s ou pracova .

3.1

Všeobecná štruktúra príru ky

Príru ka je organizovaná ako štruktúrovaný súbor skupiny požiadaviek. Celková štruktúra príru ky je lenená v nasledovných klasifikáciách meradiel do základných konfigurácii a klasifikácii, tzv. konfigurácii IT. Súbor požiadaviek je doplnený pod a špecifickými požiadavkami na meradlo. V dôsledku toho sú tri typy súborov požiadaviek: 1. požiadavky na dve základné konfigurácie meradiel (nazývaných typ P a U), 2. požiadavky na štyri konfigurácie IT (nazývané L, T, S a D) 3. špecifické požiadavky na meradlo (nazývané I.1, I.2, ...) Prvý typ požiadaviek je aplikovate ný na všetky meradlá. Druhý typ požiadaviek sa týka nasledovných funkcií IT: dlhodobé uchovávanie meraných dát (L), prenos meraných dát (T), s ahovanie softvéru (D) a oddelenie softvéru (S). Každý z týchto súborov požiadaviek je platný len vtedy, ak existuje príslušná funkcia. Posledným typom je súbor alších špecifických požiadaviek na meradlo. Nasledovné íslovanie špecifických požiadaviek na meradlo je pod a íslovania príloh v smernici MID. Blok súboru požiadaviek, ktoré môžu by aplikované na dané meradlo je schematicky zobrazené na obrázku 3-1.

Požiadavky na jednu zo základných konfigurácii meradla

+

Požiadavky konfigurácie aplikujú

IT,

na ktorá

tie sa

+

Špecifické požiadavky na meradlo, ktorá sa aplikujú

Obrázok 3-1: Typ súborov požiadaviek, ktoré môže by aplikované na meradlo

Nasledovná schéma v obrázku 3-2 znázor uje existujúce súbory požiadaviek.


WELMEC WG7



Softvérové požiadavky na základnú konfiguráciu meradla Požiadavky na meradlá využívajúce univerzálny po íta (Typ U)

Požiadavky na jednoú elové meracie prístroje (Typ P)

Blok požiadavky P1

Blok požiadavky U1

Blok požiadavky P2

Blok požiadavky U2

Softvérové požiadavky na konfiguráciu IT

Požiadavky na dlhodobé uchovávanie legálne relevantných dát (rozšírenie L)

Požiadavky na oddelenie softvéru (rozšírenie S) Požiadavky na s ahovanie legálne relevantného softvéru (rozšírenie D)

Požiadavky na prenos legálne relevantných dát (rozšírenie T) Blok požiadavky L1

Blok požiadavky T1

Blok požiadavky S1

Blok požiadavky D1

Blok požiadavky L2

Blok požiadavky T2

Blok požiadavky S2

Blok požiadavky D2

Špecifické softvérové požiadavky na meradlo Vodomery Plynomery Blok požiadavky I1-1 Blok požiadavky I2-1

Elektromery

Prietokomer

Mera e tepla Blok požiadavky I3-1 Blok požiadavky I4-1


Váhy Blok požiadavky I5-1 Blok požiadavky I6-1

WELMEC WG7



Obrázok 3-2: Preh ad súborov požiadaviek Okrem vyššie opísanej štruktúry sa požiadavky tejto príru ky rozlišujú aj pod a triedy rizika. Pre tieto ú ely je zavedených šes tried rizika, íslovaných do A po F s predpokladom stúpania rizika. Najnižšia trieda rizika A a najvyššie trieda rizika F sa zatia nepoužívajú. Sú rezervované pre eventuálny prípad, keby boli potrebné v budúcnosti. Zvyšné triedy rizík B až E pokrývajú všetky meradlá, ktoré spadajú pod smernicu MID. Navyše oni pokrývajú dostato ný preh ad príležitostí pre prípadné zmeny hodnotenia rizík. Triedy sú zadefinované v kapitole 11 tejto príru ky, ktorá má len informatívny charakter. Každému meradlu musí by priradená trieda rizika, pretože konkrétne softvérové požiadavky k aplikovaniu sú ur ené triedou rizika k meradlu ku ktorému patria.

3.2

Ako vybra príslušné asti príru ky

Táto komplexná softvérová príru ka je aplikovate ná na ve ké množstvo meradiel. Príru ka je v modulárnej forme. Primerané súbory požiadaviek môžu by ahko vybrané sledovaním nasledovných procedúr. Krok 1: Výber základnej konfigurácie (P alebo U) Z dvoch súborov požiadaviek na základné konfigurácie potrebujeme len jednu k aplikovaniu. Rozhodnite preto, ktorú základnú konfiguráciu meradla prispôsobíme k: jednoú elovému meraciemu prístroju s vstavaným softvérom (typ p, pozri kapitolu 4.1) alebo meradlu využívajúceho univerzálny po íta (typ U, pozri kapitolu 5.1). Pokia neposudzujeme celé meradlo, ale len komponent meradla, potom rozhodujeme adekvátne na komponent. Aplikujeme kompletný súbor požiadaviek, ktoré sú stanovené pre jednotlivé základné konfigurácie. Krok 2: Výber aplikovate ných konfigurácii IT (rozšírenie L, T, S a D) Konfigurácia IT zahr uje: dlhodobé uchovávanie legálne relevantných dát (L), prenos legálne relevantných dát (T), oddelenie softvéru (S), a s ahovanie legálne relevantného softvéru (D). Príslušný súbor požiadaviek, nazývaný modulárne rozšírenia, sú nezávislé jeden od druhého. Súbor vybraných závisí len na konfigurácii IT. Ak je vybraný súbor rozšírenia, potom tieto musia by aplikované v celom rozsahu. Rozhodnite, ktorý, ak vôbec nejaký, z modulárnych rozšírení ste schopný aplikova a aplikujte ich adekvátna (obrázok 3-2). Krok 3: Výber špecifických požiadaviek na meradlo (rozšírenie I) Vyberte – pod a použitia jednotlivých meradiel špecifické rozšírenie I.X – na ktoré, ak vôbec nejaké, špecifické požiadavky na meradlo sú aplikovate né a aplikujeme ich adekvátne (obrázok 3-2). Krok 4: Výber aplikovate ných tried rizika (rozšírenie I) 12 Realizované s finan nou podporou Európskej únie v rámci programu Prechodný fond

WELMEC WG7



Vyberte triedu rizika ako je zadefinovaná v jednotlivých meradlách špecifického rozšírenia I.X, podkapitola I.x.6. Pod a jednotlivých oblastí môže by zadefinovaná trieda rizika rovnomerne pre triedu meradiel alebo môže by rozdelená na kategórie, oblasti použitia at . Ako náhle bola vybraná aplikovate ná trieda rizika, potrebujeme len považované príslušné požiadavky a poradenstvo pri validácii.

3.3

Ako pracova so skupinou požiadaviek

Každá skupina požiadaviek obsahuje dobre definovanú požiadavku. Skladá sa z definujúceho textu, vysvet ujúcich špecifikovaných poznámok, predpokladanej dokumentácie, validácie a príkladu prijate ných riešení (ak sú dostupné). Obsah v rámci skupiny požiadaviek môže by rozdelený pod a tried rizika. Toto vedie k schematickej prezentácii skupiny požiadaviek zobrazených na obrázku 3-3. Názov požiadavky Opis požiadavky (prípadné delenie pod a tried rizika) Špecifikované poznámky (predmet aplikácie, alšie vysvetlenia, neobvyklé prípady, at .) Predpokladaná dokumentácia (prípadné delenie pod a tried rizika) Validácia pre jednu triedu Validácia pre rizika rizika

alšiu triedu ...

Príklad prijate ného Príklad prijate ného ... riešenia pre jednu triedu riešenia pre alšiu triedu rizika rizika Obrázok 3-3: Štruktúra skupiny požiadavky Skupina požiadavky opisuje technický obsah požiadavky vrátane validácie. Preto je adresovaná aj výrobcom aj notifikovaným osobám v dvoch pokynoch: (1) zváženie požiadavky ako minimálnej podmienky, a (2) neuklada požiadavky okrem tejto požiadavky. Poznámky pre výrobcu: - Dodržiava základné prehlásenie a alšie špecifikované poznámky. - Poskytnutie dokumentácie ako je požadovaná. - Prijate nými riešeniami sú príklady, ktoré vyhovujú požiadavke. Neexistuje žiadna povinnos sledova ich. - Validácia má len informa ný charakter. Poznámky pre notifikované osoby: - Dodržiava základné prehlásenie a alšie špecifikované poznámky. - Sledova validáciu. - Potvrdi kompletnos poskytnutej dokumentácie.


WELMEC WG7

3.4



Ako pracova s kontrolnými záznamami

Kontrolné záznamy sú prostriedkami zabezpe ujúcimi, že všetky požiadavky v rámci kapitoly boli pokryté výrobcom alebo skúšajúcim. Sú sú as ou vzorovej správy o skúške. Je potrebné si uvedomi , že kontrolné záznamy majú len sumariza ný charakter a nerozlišujú triedy rizík. Kontrolné záznamy nenahrádzajú definície požiadavky. Pre kompletné popisy sa odvolávajú na skupiny požiadaviek. Postup: - Získajte kontrolne záznamy, ktoré sú potrebné pod a výberu opísaného v krokoch 1, 2 a 3 v asti 3.2. - Preberte kontrolne záznamy a preukážte, i všetky požiadavky boli splnené. - Vypl te požadované kontrolné záznamy.


WELMEC WG7

4



Základné požiadavky na softvér v jednoú elových meracích prístrojoch (Typ P)

Súbory požiadaviek tejto kapitoly platia pre jednoú elové meradlá alebo pre komponenty meradiel, ktoré sú jednoú elovými. Platnos je dokonca zahrnutá aj na iastkové zostavy, ak to nie je výlu ne zmienená v texte. Ak meradlo používa univerzálny po íta (univerzálne PC), musí by ozna ený súbor požiadaviek v nasledovnej kapitole (prístroj typu U). Požiadavky prístroja typu U musia by tiež použité, ak nie je alší technický popis jednoú elových meradiel.

4.1

Technický popis

Prístroj typu P je meradlo so zabudovaným systémom IT (vo všeobecnosti ide o mikroprocesor alebo mikroradi založený na systéme). Toto je charakterizované nasledovnými funkciami: •

Celý aplika ná softvér bol konštruovaný na ú ely merania. Toto obsahuje dva druhy funkcii, funkcie podliehajúce kontrole z h adiska legálnej metrológie a ostatné funkcie.

•

Užívate ské rozhranie je ur ené na ú ely merania, t.j. pri bežnom užívaní v opera nom režime podlieha kontrole z h adiska legálnej metrológie. Je možné, že prepínanie opera ného režimu nie je predmetom kontroly legálnej metrológie.

•

Opera ný systém ak nemá schránku užívate a, ktorá je dostupná užívate ovi (na s ahovanie alebo zmenu programov, posielanie príkazov do opera ného systému (OS), zmenu prostredia aplikácie at .).

Prístroj typu P môže my alšie vlastnosti a funkcie, ktoré sú pokryté nasledovnými rozšírenými požiadavkami: •

Softvér je navrhnutý a spracovaný ako celok, pokia bolo dodržané softvérové rozdelenie pod a rozšírenia S.

•

Softvér je nemenný a neexistujú žiadne prostriedky programovania alebo zmenenia legálne relevantného softvéru. S ahovanie softvéru je dovolené len v tom prípade, ak je dodržané rozšírenie D.

•

Rozhranie umož uje prenos nameraných údajov cez otvorenú alebo zatvorenú komunika nú sie (musí by dodržané rozšírenie T).

•

Uchovávanie nameraných dát je možné bu na integrovanú pamä , na prenosnú alebo na vymenite nú pamä (musí by dodržané rozšírenie L).


WELMEC WG7

4.2



Špecifické požiadavky na Typ P

P1: Dokumentácia

Triedy rizika B až E

Okrem špecifickej dokumentácie, ktorá je požadovaná v každej z nasledovných požiadaviek, dokumentácia v podstate musí obsahova : a. Popis legálne relevantného softvéru. b. Popis presnosti meracích algoritmov (napr. cenová kalkulácia a algoritmus zaokrúh ovania). c. Popis užívate ského rozhrania, ponuky a dialógy. d. Jednozna nú softvérovú identifikáciu. e. Preh ad hardvérového systému, napr. topologickú blokovú schému, typu po íta a(ov), typu siete, at ., ak už nie sú popísané v opera nom manuáli. f. Opera ný manuál.

Trieda rizika B P2: Softvérová identifikácia

Trieda rizika C

Trieda rizika D

Legálne relevantný softvér musí by jednozna ne identifikovaný. Identifikácia softvéru musí by obsiahnutá v samotnom softvéri. Musí by uvedená pri príkazoch alebo po as prevádzky.

Špecifikované poznámky. Špecifikované poznámky:

1. Pri zmena metrologicky 1. Okrem 1B: Každá zmena legálne relevantného softvéru relevantného softvéru sa zadefinovaného ako stanoveného v skúške typu, musí by vyžaduje informova NO. NO doplnená novou softvérovou identifikáciou. sa rozhoduje, i je alebo nie je potrebná nová osobitná softvérová identifikácia. Nová softvérová identifikácia je potrebná len ak zmeny v softvéri vedú k zmene schválených funkcii alebo charakteristík. 2. Softvérová Identifikácia musí by ahko vidite ná pre overovanie a ú ely inšpekcie ( ahko znamená pomocou štandardného užívate ského rozhrania, bez použitie alších nástrojov. 3. Softvérová identifikácia musí ma štruktúru, ktorá sa dá jednozna ne identifikova verzie, ktoré vyžadujú skúšku typu a ktoré je nevyžadujú. 4. Ak funkcie softvéru môžu by prepínané typom – špecifickými parametrami, každá funkcia alebo variant môžu by identifikované oddelene alebo alternatívne, a kompletný súbor môže by identifikovaný ako celok.

Požadovaná dokumentácia:

V dokumentácii musí by zoznam softvérovej identifikácie a opis ako bola vytvorená softvérová identifikácia, ako je obsiahnutá v samotnom softvéri, ako by mohla by sprístupnená na prehliadnutie a ako bola štruktúrovaná za ú elom rozlíšenia medzi zmenenými verziami a verziami, ktoré nevyžadujú skúšku typu.


Požadovaná dokumentácia

(dodato ne okrem dokumentácie vyžadovanej pre triedy rizík B a C): V dokumentácii musia by vidite né opatrenia, ktoré chránia softvérovú identifikáciu pred falšovaním.

WELMEC WG7


Validácia:

Kontrola založená na dokumentácii: • Skúmame popis generovania a vizualizácie softvérovej identifikácie • Kontrolujeme, i všetky programy vykonávajúce legálne relevantné funkcie sú jednozna ne identifikované a popísané tak, že je to jednozna né aj pre notifikovanú osobu aj pre výrobcu, že ktoré softvérové funkcie sú a ktoré nie sú pokryté softvérovou identifikáciou. • Kontrolujeme, i nominálne hodnoty identifikácie boli dodané výrobcom ( íslo verzie alebo kontrolný sú et). Toto musí by citované v certifikáte skúšky. Kontroly funkcii: • Softvérová identifikácia môže by zobrazená tak, ako je popísaná v dokumentácii. • Prezentovaná identifikácia je správna. NO u seba uchováva dokumentáciu (plus vykonate ný kód, ak je nevyhnutný)


Validácia (dodato ne okrem triedy rizík B a C): Kontrola založená na dokumentácii: • Kontrolujeme, i opatrenia, ktoré chránia pre falšovaním sú vhodné.

Príklad prijate ného riešenia:

• Identifikácia legálne relevantného softvéru sa skladá z dvoch astí: as (A) musí by zmenená, ak zmeny na softvéri si vyžadujú novú skúšku. as (B) indikuje len nepatrné zmeny na softvéri, napr. opravu chýb, ktoré nevyžadujú novú skúšku. • Identifikácia je generovaná a zobrazená v príkazoch • as (A) identifikácie sa • as (A) identifikácie sa skladá z automaticky vygenerovaného skladá z ísla verzie alebo kontrolného sú tu, ktorý je vygenerovaný z legálne relevantného ísla TEC. softvéru, ktorý bol deklarovaný v skúške typu. Pre alšie asti legálne relevantného softvéru, as (A) je íslo verzie alebo íslo TEC. • Príklad prijate ného riešenia pre vykonanie kontrolného sú tu je algoritmus CRC-16.

Dodatok pre triedu rizika E Požadovaná dokumentácia (dodato ne okrem požiadaviek pre triedy rizík B a C):

Zdrojový kód obsahujúci generovanie identifikácie. Validácia (dodato ne okrem triedy rizík B a C): Kontrola založená na zdrojovom kóde: • Kontrolujeme, i všetky legálne relevantné asti sú pokryté algoritmom, ktorý generuje identifikáciu. • Kontrolujeme správnos implementácie algoritmu.


WELMEC WG7


Trieda rizika B Trieda rizika C P3: Ovplyvnenie cez užívate ské rozhranie


Trieda rizika D

Príkazy zadávané cez užívate ské rozhranie nesmú ovplyvni legálne relevantný softvér a namerané data.

Špecifikované poznámky:

1. Príkazy môže by zadávané ru ne jednoduchým alebo sekven ným prepínaním alebo klávesovým ovládaním. 2. Každý príkaz musí by jednozna ne pridelený k inicializovaní funkcii alebo dátovej zmene. 3. Prepína alebo klávesové ovládanie, ktoré nie sú deklarované a zdokumentované ako príkazy, nesmú ma žiadny vplyv na funkcie meradla alebo na namerané data.


Pokia má meradlo schopnos prijíma príkazy, dokumentácia musí obsahova : • Kompletný zoznam všetkých príkazov (napr. položku v menu) spolu s deklaráciou kompletnosti. • Stru ný opis ich významov a následkov na funkcie a data meradla.


(dodato ne okrem dokumentácie vyžadovanej pre triedy rizík B a C): • V dokumentácii musia by vidite né opatrenia validácii kompletnosti zdokumentovaných príkazov. • Dokumentácia musí obsahova protokol, ktorý preukazuje skúšky všetkých príkazov. Validácia: Validácia (dodato ne okrem triedy rizík B a C): Kontrola založená na dokumentácii: • Hodnotíme, i všetky zdokumentované príkazy sú prijate né, t.j. i Kontrola založená na majú nejaký prípustný vplyv alebo nemajú vôbec žiadny na dokumentácii: meracie funkcie (a relevantné data). • Kontrolujeme, i opatrenia • Kontrolujeme, i výrobca dodal explicitnú deklaráciu kompletnosti a protokoly sú vhodné pre príkazovej dokumentácie. vysokú úrove ochrany. Kontroly funkcii: • Realizujeme praktické skúšky (náhlou kontrolou) za pomoci zdokumentovaných ako aj nezdokumentovaných príkazov. Skúšajú sa všetky položky v menu, ak vôbec nejaké sú.


Je tam softvérový modul, ktorý prijíma a interpretuje príkazy z užívate ského rozhrania. Tento modul patrí k legálne relevantnému softvéru. Tento modul napred povolil príkazy k alším legálne relevantným softvérovým modulom. Všetky ostatné neznáme alebo nepovolené sekvencie prepína a alebo klávesového ovládania sú odmietnuté a nemajú žiadny vplyv na legálne relevantný softvér alebo na namerané data.

Dodatok pre triedu rizika E Požadovaná dokumentácia (dodato ne okrem požiadaviek pre triedy rizík B a C): Zdrojový kód meradla.

Validácia (dodato ne okrem triedy rizík B a C):

Kontrola založená na zdrojovom kóde: • Kontrolujeme návrh softvéru, i tok dát týkajúci sa príkazov je jednozna ne zadefinovaný v legálne relevantnom softvéri a i môže by overený. • H adáme neprijate né údaje, ktoré vyplývajú z užívate ského rozhrania k doménam, ktoré sú chránené. • Kontrolujeme s nástrojmi alebo ru ne, i príkazy sú dekódované správne a že neexistujú žiadne nezdokumentované príkazy.

Trieda rizika B

Trieda rizika C 18


Trieda rizika D

WELMEC WG7



P4: Ovplyvnenie cez komunika né rozhranie

Príkazy zadávané cez komunika né rozhranie meradla nesmú ovplyvni legálne relevantný softvér a namerané data.


1. Každý príkaz musí by jednozna ne pridelený k inicializovaní funkcii alebo dátovej zmene. 2. Signály alebo kódy, ktoré nie sú deklarované a zdokumentované ako príkazy nesmú ma vplyv na funkcie meradla alebo na data. 3. Príkazy môžu by sekvenciami elektrických (optickými, elektromagnetické, at .) signálov na vstupných kanáloch alebo kódoch v protokoloch dátových prenosov. 4. Požiadavky, ktoré sú tu uvedené sa netýkajú s ahovania dát pod a rozšírenia D. 5. Táto požiadavka sa aplikuje len na rozhrania, ktoré nie sú úradne zape atené.


Pokia má meradlo rozhranie, dokumentácia musí obsahova : • Kompletný zoznam všetkých príkazov (napr. položku v menu) spolu s deklaráciou kompletnosti. • Stru ný opis ich významov a následkov na funkcie a data meradla.


(dodato ne okrem dokumentácie vyžadovanej pre triedy rizík B a C): • V dokumentácii musia by vidite né opatrenia validácii kompletnosti zdokumentovaných príkazov. • Dokumentácia musí obsahova protokol, ktorý preukazuje skúšky príkazov alebo alternatívne hocijaké iné vhodné opatrenia preukazujúce správnos . Validácia: Validácia (dodato ne okrem triedy rizík B a C): Kontrola založená na dokumentácii: • Hodnotíme, i všetky zdokumentované príkazy sú prijate né, t.j. i Kontrola založená na majú nejaký prípustný vplyv alebo nemajú vôbec žiadny na dokumentácii: meracie funkcie (a relevantné data). • Kontrolujeme, i opatrenia • Kontrolujeme, i výrobca vyhotovil explicitnú deklaráciu a protokoly sú vhodné pre kompletnosti príkazovej dokumentácie. vysokú úrove ochrany. Kontroly funkcii: • Realizujeme praktické skúšky (náhlou kontrolou) s použitím periférneho vybavenia, ak je dostupné. Poznámka: Ak nie je možné znemožni neprijate né vplyvy na funkcie merania (alebo relevantné data) cez rozhranie a softvér nemôže by adekvátne upravený, potom sa na certifikát skúšky musí ozna i , že rozhranie nie je chránené a popíše sa jeho zabezpe enie/zaplombovanie požadovanými prostriedkami. Toto platí tiež pre rozhrania, ktoré nie sú popísané v dokumentácii.


Je tam softvérový modul, ktorý prijíma a interpretuje data z užívate ského rozhrania. Tento modul je as ou legálne relevantného softvéra. Tento modul napred povolil príkazy k alším legálne relevantným softvérovým modulom. Všetky ostatné neznáme alebo nepovolené signály alebo kódy sekvencii sú odmietnuté a nemajú žiadny vplyv na legálne relevantný softvér alebo na namerané data.


WELMEC WG7






Trieda rizika B Trieda rizika C Trieda rizika D P5: Ochrana proti náhodným alebo neúmyselným zmenám Legálne relevantný softvér alebo namerané data musia by neúmyselným zmenám.

chránené proti náhodným alebo


Možné prí iny pre náhodné zmeny a závady sú: nepredvídate né fyzikálne vplyvy, efekty spôsobené užívate om funkcií a pozostatky chýb zo softvéru, napriek tomu, že zákonom stanovené vývojové techniky musia by aplikované. Táto požiadavky zah a: a) Fyzikálne vplyvy: uchovávané namerané data musia by chránené proti korupcii alebo vymazaniu, pokia by nastala chyba alebo alternatívne, musí by odhalená porucha. b) Užívate ské funkcie: potvrdenie musí by požadované pred mazaním alebo zmenením dát. c) Chyby v softvéri: Musia by podniknuté hodné opatrenia na ochranu dát pred neúmyselnými zmenami, ktoré by mohli nasta prostredníctvom nesprávneho návrhu programu alebo chyby v programe, napr. hodnovernos šekov.

Požadovaná dokumentácia: V dokumentácii musia by zmenám.

vidite né opatrenie, ktoré chránia softvér a data proti neúmyselným

Validácia:

Kontrola založená na dokumentácii: • Kontrolujeme, i kontrolný sú et kódu programu a relevantných parametrov je automaticky vygenerovaný a overený. • Kontrolujeme, i prepísanie dát nemôže nasta ešte pred koncom doby uchovávania dát, ktorá je predpísaná a zdokumentovaná výrobcom. • Kontrolujeme, i varovanie je vydané, ak užívate chce zmaza súbory nameraných dát. Kontroly funkcii: • Pokia je možné zmaza data, kontrolujeme praktickými náhlymi kontrolami, i pre zmazaním nameraných dát je dané varovanie.


• Náhodná modifikácia softvéru a nameraných dát sa môže kontrolova výpo tom kontrolného sú tu relevantnej asti, ktorý sa porovná s nominálnou hodnotou a zastaví sa, ak boli akéko vek modifikácie. • Namerané data sa nedajú vymaza bez predchádzajúceho schválenia, napr. oznamujúci dialóg alebo okno požadujúce potvrdenie vymazania. • Pre odhalenie chyby pozri tiež rozšírenie I.


Zdrojový kód meradla. Validácia (dodato ne okrem triedy rizík B a C): Kontrola založená na zdrojovom kóde: • Kontrolujeme, i opatrenia na zis ovanie zmien (chyby) sú vhodné. • Ak sa realizuje kontrolný sú et, kontrolujeme i sú ním pokryté všetky asti legálne relevantného softvéra. 20 Realizované s finan nou podporou Európskej únie v rámci programu Prechodný fond

WELMEC WG7



Trieda rizika B Trieda rizika C P6: Ochrana proti úmyselným zmenám

Trieda rizika D

Legálne relevantný softvér musí by chránený proti nedovoleným modifikáciám, s ahovaniu alebo presunu hardvérovej pamäti.


1. Meradlo bez rozhrania: Manipulovanie kódom programu by mohlo by možné len prostredníctvom manipulovania s fyzickej pamäte, t.j. pamä je fyzicky odstránená a nahradená inou, ktorá obsahuje falošný softvér alebo data. Aby sa tomuto zabránilo, musí by zabezpe ený kryt meradla lebo samotná fyzická pamä je zabezpe ená proti neoprávnenej demontáži. 2. Meradlo s rozhraním: Rozhranie musí obsahova len tie funkcie, ktoré podliehajú skúške. Všetky funkcie v rozhraní musia by predmetom skúšania (pozri P4). Ak sa k softvérovému s ahovaniu využíva rozhranie, musí toto vyhovova rozšíreniu D. 3. Data sú považované za dostato ne chránené, ke sa používajú len postupy legálne relevantného softvéru. Ak sa po schválení zamýš a zmeni softvér, ktorý nepodlieha legálnej metrológii, musia by splnené požiadavky rozšírenia S.


V dokumentácii musí by poskytnuté uistenie, že relevantný softvér nemôže by nedovolene modifikovaný.

Požadovaná

legálne dokumentácia (dodato ne okrem dokumentácie vyžadovanej pre triedy rizík B a C): Ochranné opatrenia chrániace pred úmyselnými zmenami musia by zobrazené. Validácia: Validácia (dodato ne okrem triedy rizík B a C): Kontrola založená na dokumentácii: • Vyskúšajme, i sú dostato né zdokumentované prostriedky Kontrola založená na zabezpe enia proti neoprávneným výmenám pamäti, ktoré dokumentácii: obsahujú softvér. • Kontrolujeme, i opatrenia sú • Ak môžu by pamäte programované bez ich vybratia (bez vhodné pokia ide o požiadavky, demontáže) skontrolujeme, i programovací režim môže by ktoré sú stanovené zákonom vyradený elektricky a prostriedky na ich zablokovanie môžu by pre vysokú úrove ochrany. zabezpe ené/zaplombované. (Pre kontrolu s ahovania zariadenia pozri rozšírenie D). Kontroly funkcii: • Prakticky vyskúšajme programovací režim a skontrolujme i sa zablokuje práca.


Meradlo je zaplombované a rozhranie je v zhode s požiadavkami P3 a P4.


Zdrojový kód meradla. Validácia (dodato ne okrem triedy rizík B a C): Kontrola založená na zdrojovom kóde: • Kontrolujeme v zdrojovom kóde, i opatrenia na zis ovanie úmyselných zmien sú vhodné.


WELMEC WG7

Trieda rizika B P7: Ochrana parametra



Trieda rizika C

Trieda rizika D

Parametre, ktoré sú stanovené legálne relevantnými charakteristikami meradla musia by zabezpe ené proti neoprávnenej modifikácii.


1. Typovo-špecifické parametre sú identické pre každú vzorku typu a sú vo všeobecnej asti kódu programu. Preto sa na ne aplikuje požiadavka P6 2. Špecificky zabezpe ené parametre zariadenia môžu by zmenené s použitím vlastnej klávesnice alebo prepína a alebo prostredníctvom rozhrania, ale len v tom prípade, ke boli predtým zabezpe ené. 3. Nastavite né špecifické parametre zariadenia môžu by zmenené po ich zabezpe ení.


V dokumentácii musia by opísané všetky legálne relevantné parametre, ich rozsah a nominálne hodnoty, kde sú uchovávané, ako môžu by prezerané, ako sú zabezpe ené a kedy, t.j. pred alebo po overení.


(dodato ne okrem dokumentácie vyžadovanej pre triedy rizík B a C): Ochranné opatrenia pre parametre musia by ukázané. Validácia: Validácia (dodato ne okrem triedy rizík B a C): Kontrola založená na dokumentácii: • Kontrolujeme, i je možné zmeni alebo upravi zabezpe ené Kontrola založená na špecifické parametre zariadenia po ich zabezpe ení. dokumentácii: i príslušné • Kontrolujeme, i všetky relevantné parametre pod a zoznamu • Kontrolujeme, opatrenia sú vhodné vzh adom (daný v rozšírení I) boli klasifikované ako zabezpe ené. na zákonom stanovené Kontroly funkcii: • Skúšame nastavenie (konfiguráciu) režimu a kontrolujeme i sa požiadavky pre vysokú úrove ochrany. po zabezpe ení zablokujú. • Preskúšame klasifikáciu a stav parametrov (zabezpe ených/nastavite ných) na displeji meradla, ak tomu je primeraná položka v menu


a) Parametre sú zabezpe ené zape atením meradla alebo krytu pamäte a je zablokovaná možnos písania/zablokovaný vstup pamä ových obvodov cez priradený mostík alebo prepína , ktoré je tiež zablokovaný. kontrolný záznam: b) íta udalostí zaznamenáva každú zmenu hodnoty parametra. Aktuálny výpo et môže by zobrazený a môže by porovnávaní s po iato nou hodnotou udalosti, ktorá bola zaznamenaná pri poslednom overení a je nezmazate ne ozna ená na meradle. c) Zmeny parametrov sú zaznamenávané v zapisova i udalostí. Je to vo forme informa ného záznamu uloženého v stálej pamäti. Každý vstup je generovaný automaticky legálne relevantným softvérom a obsahuje: • identifikáciu parametra (napr. meno) • hodnotu parametra (aktuálnu alebo predchádzajúcu hodnotu) • asový udaj zmeny Zapisova udalostí nemôže by vymazaný alebo zmenený bez porušenia plomby.

÷


Zdrojový kód ukáže formu zabezpe enia a predvedie legálne relevantné parametre. Validácia (dodato ne okrem triedy rizík B a C): Kontrola založená na zdrojovom kóde: • Kontrolujeme v zdrojovom kóde, i opatrenia na ochranu parametrov sú vhodné (napr. nastavenie režimu zablokovania po zabezpe ení). 22 Realizované s finan nou podporou Európskej únie v rámci programu Prechodný fond

WELMEC WG7



5

Základné požiadavky na softvér využívajúcich univerzálny po íta (Typ U)

5.1

Technický popis

meradlách

Súbor softvérových požiadaviek v tejto asti sa aplikujú na meradlo so základom na všeobecne použite nom po íta i. Technický popis typu U meracieho systému je zosumarizovaný nižšie. V podstate, systém typu U musí by prijatý, ak podmienky meradla typu P (pozri kapitole 4.1) neboli splnené. Hardvérová konfigurácia a) Modulárny všeobecne použite ný po íta so základom na systéme. Po íta ový systém môže by nezávislý, as uzatvorenej siete, napr. miestna po íta ová sie , rozlíšite ný kruhová LAN sie alebo as otvorenej siete, napr. internet. b) Pretože systém je všeobecne použite ný, senzor môže by bežnou externou po íta ovou jednotkou a bežne môže by prepojený s uzatvorenými komunika nými spojmi. Komunika ná linka by mohla by tiež otvorená, napr. sie , prostredníctvom oho by mohlo by prepojených nieko ko senzorov. c) Užívate ské rozhranie môže by prepína om z opera ného režimu, ktorý nie je pod kontrolou legálnej metrológie, k inému, ktorý je pod kontrolou a naopak. d) Uchovávanie môže by fixované, napr. pevným diskom, alebo vymenite ným, napr. disketami, CD-RW. Softvérová konfigurácia e) Môže by požitý hocijaký opera ný systém. Okrem aplikovaného meradla, môžu by aplikované aj iné softvérové aplikácie, ktoré sú s ním sú asne v jednom systéme. as softvéru, napr. aplikácia meradla, sú predmetom právnej kontroly a nesmú by po schválení nedovolene modifikované. as , ktorá nie je predmetom právnej kontroly môže by modifikovaná. f) Opera ný systém a nízka úrove ovláda ov, napr. ovláda e grafiky, ovláda e pevných diskov, at ., nie sú legálne relevantnými, len dovtedy, pokia ide o špeciálne programovanie pre špecifické meracie úlohy.


WELMEC WG7

5.2



Špecifické požiadavky na Typ U

U1: Dokumentácia

Triedy rizika B až E

Okrem špecifickej dokumentácie, ktorá je požadovaná v každej z nižšie uvedenej požiadavky, dokumentácia v podstate musí obsahova : a. Popis legálne relevantných softvérových funkcií, významu dát, at . b. c. d. e.

Popis presnosti meracích algoritmov (napr. cenová kalkulácia a algoritmus zaokrúh ovania). Popis užívate ského rozhrania, ponuky a dialógy. Identifikácia softvéru legálnej metrológie. Preh ad hardvérového systému, napr. topologickú blokovú schému, typu po íta a(ov), typu siete, at ., ak už nie sú popísané v opera nom manuáli. f. preh ad bezpe nostných aspektov opera ného manuálu, napr. ochrana, ú ty užívate a, privilégia, at . g. Opera ný manuál.

Trieda rizika B U1: Softvérová identifikácia

Trieda rizika C

Trieda rizika D

Legálne relevantný softvér musí by jednozna ne identifikovaný. Identifikácia softvéru musí by obsiahnutá v samotnom softvéri. Musí by stanovený a prezentovaný pri príkazoch alebo po as prevádzky.

Špecifikované poznámky.


1. Identifikácia výlu ne opera ného 1. Obmedzenia z 1B: (Nízka úrove ) Ovláda e, ktoré sú systému a nízkej úrovni zadefinované ako relevantné v skúške typu musia by ovláda ov, napr. ovláda e identifikované. grafiky, ovláda e tla iarní, 2. Okrem 2B: Každá zmena legálne relevantného kódu ovláda e pevných diskov, at ., programu zadefinovaného ako stanoveného v skúške typu ale tiež obsahujú ovláda e alebo pri zmene typovo-špecifických parametrov špeciálne programovaných pre zadefinovaná ako nemenná, musí by doplnená novou špecificky legálne relevantné softvérovou identifikáciou. úlohy. 2. Pri zmena metrologicky relevantného softvéru sa vyžaduje informova NO. NO sa rozhoduje, i je alebo nie je potrebná nová osobitná softvérová identifikácia. Nová softvérová identifikácia je potrebná len ak zmeny v softvéri vedú k zmene schválených funkcii alebo charakteristík. 3. Softvérová Identifikácia musí by ahko vidite ná pre overovanie a ú ely inšpekcie ( ahko znamená pomocou štandardného užívate ského rozhrania, bez použitie alších nástrojov. 4. Softvérová identifikácia musí ma štruktúru, ktorá sa dá jednozna ne identifikova verzie, ktoré vyžadujú skúšku typu a ktoré je nevyžadujú. 5. Identifikácia môže by aplikovaná na rozdielne úrovne, napr. pre kompletné programy, moduly, funkcie, at . 6. Ak funkcie softvéru môžu by prepínané parametrami, každá funkcia alebo variant môžu by identifikované oddelene alebo kompletný súbor môže by identifikovaný ako celok.


V dokumentácii musí by zoznam softvérovej identifikácie a opis ako bola vytvorená softvérová identifikácia, ako je obsiahnutá v samotnom softvéri, ako by mohla by sprístupnená na prehliadnutie a ako bola štruktúrovaná za ú elom rozlíšenia medzi zmenenými verziami a verziami, ktoré nevyžadujú skúšku typu.


(dodato ne okrem dokumentácie vyžadovanej pre triedy rizík B a C): V dokumentácii musia by vidite né opatrenia, ktoré chránia softvérovú identifikáciu pred falšovaním.


WELMEC WG7



Validácia:

Validácia (dodato ne okrem triedy rizík B a C): Kontrola založená na dokumentácii: • Skúmame popis generovania a vizualizácie softvérovej Kontrola založená na dokumentácii: identifikácie • Kontrolujeme, i opatrenia, ktoré pre falšovaním sú • Kontrolujeme, i všetky legálne relevantné softvéri sú chránia jednozna ne identifikované a popísané tak, že je to vhodné. jednozna né aj pre notifikovanú osobu aj pre výrobcu, že ktoré softvérové funkcie sú a ktoré nie sú pokryté softvérovou identifikáciou. • Kontrolujeme, i nominálne hodnoty identifikácie boli dodané výrobcom ( íslo verzie alebo kontrolný sú et). Toto musí by citované v certifikáte skúšky. Kontroly funkcii: • Kontrolujeme, i softvérová identifikácia môže by zobrazená tak, ako je popísaná v dokumentácii. • Kontrolujeme, i prezentovaná identifikácia je správna. NO u seba uchováva dokumentáciu (plus vykonate ný kód, ak je nevyhnutný) Príklad prijate ného riešenia:

• Identifikácia legálne relevantného softvéru sa skladá z dvoch astí: as (A) musí by zmenená, ak zmeny na softvéri si vyžadujú novú skúšku. as (B) indikuje len nepatrné zmeny na softvéri, napr. opravu chýb, ktoré nevyžadujú novú skúšku. • Identifikácia je generovaná a zobrazená v príkazoch • as (A) identifikácie sa skladá • as (A) identifikácie sa skladá z automaticky z ísla verzie alebo ísla TEC. vygenerovaného kontrolného sú tu, ktorý je vygenerovaný cez Aby sa zabránilo tomu aby bol pevný kód Pre alšie asti legálne relevantného softvéru, as zmenený s pomocou (A) je íslo verzie alebo íslo TEC. jednoduchých softvérových nástrojov, uloží sa v binárnom • Prijate né riešenie pre • Prijate nými algoritmami pre formáte vo vykonate nom vykonanie kontrolného kontrolný sú et sú SRS-32 alebo programovom súbore. sú tu je algoritmus hash algoritmy ako napr. SHA-1, CRC-16. MD5, RipeMD160, at .


Zdrojový kód obsahujúci generovanie identifikácie. Validácia (dodato ne okrem triedy rizík B a C): Kontrola založená na zdrojovom kóde: • Kontrolujeme, i všetky legálne relevantné asti sú pokryté algoritmom, ktorý generuje identifikáciu. • Kontrolujeme správnos implementácie algoritmu.


WELMEC WG7



Trieda rizika B Trieda rizika C U3: Ovplyvnenie cez užívate ské rozhranie

Trieda rizika D

Príkazy zadávané cez užívate ské rozhranie nesmú ovplyvni legálne relevantný softvér a namerané data.


1. Každý príkaz musí by jednozna ne pridelený k inicializovaní funkcii alebo dátovej zmene. 2. Prepína alebo klávesové ovládanie, ktoré nie sú deklarované a zdokumentované ako príkazy, nesmú ma žiadny vplyv na funkcie meradla alebo na namerané data. 3. Príkazy môže by jednoduchou innos ou alebo sekven ným innos ami vykonanými operátorom. Užívate musí ovláda len tie príkazy, ktoré sú mu povolené. 4. Užívate ská schránka bude uzatvorená, t.j. užívate nesmie ma možnos s ahova programy, písa programy alebo vykonáva príkazy opera ného systému.

÷


Dokumentácia musí obsahova : • Kompletný zoznam všetkých príkazov spolu s deklaráciou kompletnosti. • Stru ný opis ich významov a následkov na funkcie a data meradla.


(dodato ne okrem dokumentácie vyžadovanej pre triedy rizík B a C): • V dokumentácii musia by vidite né opatrenia validácii kompletnosti zdokumentovaných príkazov. • Dokumentácia musí obsahova protokol, ktorý preukazuje skúšky všetkých príkazov. Validácia: Validácia (dodato ne okrem triedy rizík B a C): Kontrola založená na dokumentácii: • Hodnotíme, i zdokumentované príkazy sú prijate né, t.j. i majú Kontrola založená na nejaký prípustný vplyv alebo nemajú vôbec žiadny na meracie dokumentácii: funkcie (a relevantné data). • Kontrolujeme, i opatrenia • Kontrolujeme, i výrobca dodal explicitnú deklaráciu a protokoly sú vhodné pre kompletnosti príkazovej dokumentácie. vysokú úrove ochrany. Kontroly funkcii: • Realizujeme praktické skúšky (náhlou kontrolou) za pomoci zdokumentovaných ako aj nezdokumentovaných príkazov. Skúšajú sa všetky položky v menu, ak vôbec nejaké sú.

Prijate né riešenie: •

Modul v legálne relevantnom softvéri odfiltrováva nedovolené príkazy. Príkazy môže prijíma len tento modul, a neexistuje žiadne jeho obídenie. Hocijaké falošné vstupy sú zablokované. Užívate je kontrolovaný alebo riadený, ke zadáva pri vstupe príkazy špeciálneho softvérového modulu. Tento riadený modul je samostatne prepojený s modulom, ktorý odfiltrováva nedovolené príkazy. • Prístup k opera nému systému je zablokovaný.

÷


Zdrojový kód legálne relevantného softvéru. Validácia (dodato ne okrem triedy rizík B a C): Kontrola založená na zdrojovom kóde: • Kontrolujeme návrh softvéru, i tok dát týkajúci sa príkazov je jednozna ne zadefinovaný v legálne relevantnom softvéri a i môže by overený. • H adáme neprijate né údaje, ktoré vyplývajú z užívate ského rozhrania k doménam, ktoré sú chránené. • Kontrolujeme s nástrojmi alebo ru ne, i príkazy sú dekódované správne a že neexistujú žiadne nezdokumentované príkazy. 26 Realizované s finan nou podporou Európskej únie v rámci programu Prechodný fond

WELMEC WG7


Trieda rizika B Trieda rizika C U4: Ovplyvnenie cez komunika né rozhranie


Trieda rizika D

Príkazy zadávané cez nezaplombované komunika né rozhranie zariadenia nesmú ovplyvni legálne relevantný softvér a namerané data.


1. Každý príkaz musí by jednozna ne pridelený k inicializovaní funkcii alebo dátovej zmene. 2. Signály alebo kódy, ktoré nie sú deklarované a zdokumentované ako príkazy nesmú ma vplyv na funkcie meradla alebo na data. 3. Príkazy môžu by sekvenciami elektrických (optickými, elektromagnetické, at .) signálov na vstupných kanáloch alebo kódoch v protokoloch dátových prenosov. 4. Požiadavky, ktoré sú tu uvedené sa netýkajú s ahovania dát pod a rozšírenia D. 5. Tieto asti opera ného systému, ktoré interpretujú 5. Všetky zapojené programy a asti legálne relevantné príkazy musia by stanovené programov do prenášania a prijímania legálne relevantným softvérom. legálne relevantných príkazov alebo 6. Ostatné asti softvéru môžu používa poskytnuté dát musia by kontrolované legálne rozhranie, ktoré nenarúša alebo falšuje prijímanie relevantným softvérom. alebo prenos legálne relevantných príkazov alebo dát. 6. Rozhranie, ktoré prijíma alebo prenáša legálne relevantné príkazy alebo data, musí by ur ené na túto úlohu a môže používa len legálne relevantný softvér. Avšak bežné rozhranie nie je vylú ené, len ak sú ochranné prostriedky zrealizované pod a rozšírenia T.


Požadovaná

dokumentácia

Dokumentácia musí obsahova : (dodato ne okrem dokumentácie • Kompletný zoznam všetkých príkazov (napr. položku vyžadovanej pre triedy rizík B a C): v menu) spolu s deklaráciou kompletnosti. • V dokumentácii musia by vidite né • Stru ný opis ich významov a následkov na funkcie opatrenia validácii kompletnosti a data meradla. zdokumentovaných príkazov. • Dokumentácia musí obsahova protokol, ktorý preukazuje skúšky príkazov alebo alternatívne hocijaké iné vhodné opatrenia preukazujúce správnos . Validácia: Validácia (dodato ne okrem triedy rizík B a C): Kontrola založená na dokumentácii: • Hodnotíme, i všetky zdokumentované príkazy sú Kontrola založená na dokumentácii: prijate né, t.j. i majú nejaký prípustný vplyv alebo • Kontrolujeme, i opatrenia a protokoly nemajú vôbec žiadny na legálne relevantný softvér (a sú vhodné pre vysokú úrove ochrany. relevantne namerané data). • Kontrolujeme, i výrobca vyhotovil explicitnú deklaráciu kompletnosti príkazovej dokumentácie. Kontroly funkcii: • Realizujeme praktické skúšky (náhlou kontrolou) s použitím periférneho vybavenia, ak je dostupné.


Je tam softvérový modul, ktorý prijíma a interpretuje príkazy z užívate ského rozhrania. Tento modul patrí k legálne relevantnému softvéru. Tento modul napred povolil príkazy k alším legálne relevantným softvérovým modulom. Všetky ostatné neznáme alebo nepovolené príkazy sú odmietnuté a nemajú žiadny vplyv na legálne relevantný softvér alebo na namerané data.


WELMEC WG7







WELMEC WG7



Trieda rizika B Trieda rizika C Trieda rizika D U5: Ochrana proti náhodným alebo neúmyselným zmenám Legálne relevantný softvér alebo namerané data musia by neúmyselným zmenám.

chránené proti náhodným alebo


1. Neúmyselné zmeny by mohli nasta prostredníctvom: a. Nesprávnym návrhom programu, napr. nesprávnou metódou operácie, zmenou globálnej premennej vo funkcii at . b. Nesprávne použitie opera ného systému. c. Náhodným prepísaním alebo vymazaním uložených dát a programov (odvolávka tiež na rozšírenie L) d. Nesprávne pridelenie meraných prenášaných dát. Merania a data prislúchajúce k jednému prenosu meraní nesmie by zmiešaná s rozdielnymi prenosmi a to z dôvodu nesprávneho programovania alebo uchovávania. e. Fyzikálne javy (elektromagnetická interferencia, teploty, vibrácie, at .).

Požadovaná


dokumentácia

V dokumentácii musia by vidite né opatrenie, ktoré chránia (dodato ne okrem dokumentácie softvér a data proti neúmyselným zmenám. vyžadovanej pre triedy rizík B a C): V dokumentácii musia by vidite né opatrenia validácii efektívnosti ochranných prostriedkov. Validácia: Validácia (dodato ne okrem triedy rizík B a C): Kontrola založená na dokumentácii: • Kontrolujeme, i kontrolný sú et kódu programu Kontrola založená na dokumentácii: a relevantných parametrov je automaticky vygenerovaný • Kontrolujeme, i opatrenia a kontrolovaný. a protokoly sú vhodné pre vysokú • Kontrolujeme, i sa prepísanie dát nemôže sta ešte pred úrove ochrany. koncom doby uchovávania dát, ktorá je predpísaná a zdokumentovaná výrobcom. • Kontrolujeme, i boli vydané upozornenia pre užívate ov, ak by sa chystali vymaza súbory nameraných dát. Kontroly funkcii: • Pokia je možné zmaza data, kontrolujeme praktickými náhlymi kontrolami, i pre zmazaním nameraných dát je dané varovanie.


• Prevencia pre nesprávnym návrhom programu – toto je nad rozsah tried rizík. • Nesprávne použitie opera ného systému, prepisovanie alebo vymazanie uložených dát a programov – výrobca vypracuje plnú verziu ochranného alebo súkromného práva poskytnuté pri opera ným systémom alebo programovacom jazyku. • Náhodná modifikácia softvéru a súborov dát sa môže kontrolova výpo tom kontrolného sú tu relevantného kódu, ktorá sa porovná s nominálnou hodnotou a zastaví sa, ak bol kód modifikovaný alebo primerane reaguje, ak boli parametre alebo data zainteresované. • Pokia to opera ný systém umož uje, je iba odporú aním pre všetkých užívate ov práva pre vymazanie, pohyb alebo dodatok k legálne relevantnému softvéru by mali by odstránené a prístup by mal by kontrolovaný prostredníctvom obslužných programov. Je odporú aním aby prístupová kontrola programov a dát mala by za použitia hesiel, len ak sú použité mechanizmy na ítanie. Kontrolný systém by mal obnovi práva, len na požiadanie.


Zdrojový kód meradla. Validácia (dodato ne okrem triedy rizík B a C): Kontrola založená na zdrojovom kóde: • Kontrolujeme, i opatrenia na zis ovanie zmien (chyby) sú vhodné. • Ak sa realizuje kontrolný sú et, kontrolujeme i sú ním pokryté všetky asti legálne relevantného softvéra.


WELMEC WG7


Trieda rizika B Trieda rizika C P6: Ochrana proti úmyselným zmenám


Trieda rizika D

Legálne relevantný softvér a data musia by chránené proti nedovoleným modifikáciám.


1. Zmeny s úmyslom podvodu by sa mohli pokúsi prostredníctvom:


1. Úrove ochrany by mala by

a. Zmena kódu programu vrátane integrovaných dát – ak je kód programu ekvivalentná k elektronickej v spustite nom formáte (.exe), potom je dostato ná ochrana pre triedy platbe. rizík B a C. Vo všeobecnosti, univerzálny b. Zmena nameraných dát – odvolávka na rozšírenie L. po íta je vhodný len pre túto

2. Zámena schváleného softvéru nesmie by možná s použitím triedu rizika s alším hardvérom opera ného systému, napr. na s ahovanie a používanie potrebným na zabezpe enie. neschváleného softvéru namiesto schváleného (pozri napr. U3). Pre s ahovanie softvéru pozri rozšírenie D. 3. Ak to je nevyhnutné, prostriedky musia chráni legálne relevantný softvér proti modifikácii prostredníctvom jednoduchých nástrojov, napr. textovými alebo oknovými editormi.



V dokumentácii musí by poskytnuté uistenie, že legálne relevantný (dodato ne okrem dokumentácie softvér nemôže by nedovolene modifikovaný. vyžadovanej pre triedy rizík B a C): Ochranné opatrenia musia by zobrazené. Validácia (dodato ne okrem Validácia: Prípad 1: Uzatvorená softvérová schránka podliehajúca právnej triedy rizík B a C): kontrole. Kontrola založená na dokumentácii: Kontrola založená na dokumentácii: • Kontrolujeme, i opatrenia sú • Softvérové moduly zavedené automaticky. • Užívate nemá prístup k opera nému systému PC. vhodné pokia ide • Užívate nemá prístup k inému softvéru než ku schválenému. o požiadavky, ktoré sú • Zapísaná deklarácia je daná, a i nie sú žiadne skryté funkcie na stanovené zákonom pre obídenie uzatvorenej schránky. vysokú úrove ochrany. Prípad 2: Užívate sprístupní opera ný systém a/alebo softvér. Kontrola založená na dokumentácii: • Kontrolný sú et cez strojový kód softvérových modulov je vygenerovaný. Legálne relevantný softvér nemôže by naštartovaný, ak je kód sfalšovaný.

Príklad prijate ného riešenia: Príklad prijate ného riešenia: • Kód programu a data môžu by chránené pomocou kontrolného sú tu. • Kód programu môže by Program vypo íta svoj vlastní kontrolný sú et a porovná ho zabezpe ený uchovaním s požadovanou hodnotou, ktorá je skrytá v spustite nom kóde. Ak legálne relevantného softvéra zlyhá samokontrola, program sa zablokuje. v priradenej zásuvnej • Každý podpisový algoritmus by mal ma d žku k ú a najmenej 2 byty; jednotke, ktorá je kontrolný sú et CRC-16 s utajeným po iato ným smerom (ukrytý zaplombovaná. Zásuvná v spustite nom kóde) by mohol by prijate ný. (Pozri tiež rozšírenie L a jednotka môže zah a napr. T). pamä ur enú len na ítanie • Neoprávnené manipulovanie legálne relevantného softvéru môže by a mikroradi . kontrolované riadením prístupom alebo súkromnou ochrannou hodnotou opera ného systému. Úrove administratívy v týchto systémoch musí by zabezpe ená plombou alebo ekvivalentnými prostriedkami.

Dodatok pre triedu rizika E

Požadovaná dokumentácia (dodato ne okrem požiadaviek pre triedy rizík B a C): Zdrojový kód meradla.


Kontrola založená na zdrojovom kóde: • Kontrolujeme komunikáciu s alším zabezpe eným hardvérom. • Kontrolujeme, i zmeny programov alebo dát sú detegované a zastavia sa v tomto prípade spustite ným programom.


WELMEC WG7

Trieda rizika B U7: Ochrana parametra



Trieda rizika C

Trieda rizika D

Legálne relevantné musia by zabezpe ené proti neoprávnenej modifikácii.


1. Typovo-špecifické parametre sú identické pre každú vzorku typu a sú vo všeobecnej asti kódu programu, t.j. asti legálne relevantného softvéra. Preto sa na ne aplikuje požiadavka P6 2. Špecifické parametre zariadenia: • „Zabezpe ené“ parametre môžu by zmenené s použitím vlastnej klávesnice alebo prepína a alebo prostredníctvom rozhrania, ale len pred postupom jeho zabezpe enia. Pretože so špecifickými parametrami zariadenia by sa mohlo manipulova pomocou jednoduchých nástrojov na univerzálnom po íta i, tieto nesmú by uchovávané v univerzálnom po íta i. Uchovávanie týchto parametrov je akceptovate né len mimo hardvéru. • Nastavite né špecifické parametre zariadenia môžu by zmenené po ich zabezpe ení.


V dokumentácii musia by opísané všetky legálne relevantné parametre, ich rozsah a nominálne hodnoty, kde sú uchovávané, ako môžu by prezerané, ako sú zabezpe ené a kedy, t.j. pred alebo po overení.

Validácia:

Kontrola založená na dokumentácii: • Kontrolujeme, i metóda na ochranu typovo-špecifických parametrov je vhodná. • Kontrolujeme, i špecifické parametre zariadenia nie sú bežne uchovávané na univerzálnom po íta i, ale na osobitnom hardvéri, ktorý môže by zaplombovaný a blokovaný na písanie.. Kontroly funkcii: • Skúšame nastavenie (konfiguráciu) režimu a kontrolujeme i sa po zabezpe ení zablokujú. • Preskúšame klasifikáciu a stav parametrov (zabezpe ených/nastavite ných) na displeji meradla, ak tomu je primeraná položka v menu. Na TEC musí by zoznam tých parametrov, ktoré sú nastavite né ako aj to kde sú umiestnené.


(dodato ne okrem dokumentácie vyžadovanej pre triedy rizík B a C): Ochranné opatrenia pre parametre musia by ukázané. Validácia (dodato ne okrem triedy rizík B a C): Kontrola založená na dokumentácii: • Kontrolujeme, i príslušné opatrenia sú vhodné vzh adom na zákonom stanovené požiadavky pre vysokú úrove ochrany.

Príklad prijate ného riešenia: •

•

Špecifické parametre zariadenia sú uchovávané na zásuvnej pamäti, ktorá je zaplombovaná proti odstráneniu alebo priamo na senzore jednotky. Zapisovaniu parametrov je zabránené plombou a prepína om povo ujúcim zapisovanie v prevádzkovom stave. Kontrolné záznamy je možné skombinova s bezpe nostným hardvérom (pozri P7). Nastavite né parametre sú uchovávané na bežnej pamäti univerzálneho po íta a.


Zdrojový kód meradla. Validácia (dodato ne okrem triedy rizík B a C): Kontrola založená na zdrojovom kóde: • Kontrolujeme, i opatrenia na ochranu parametrov sú vhodné.


WELMEC WG7


Trieda rizika B Trieda rizika C U8: Autentickos softvéru a prezentácia výsledkov


Trieda rizika D

Prostriedky musia zaisti autentickos legálne relevantného softvéra. Autentickos výsledkov, ktoré sú prezentované musia by zaru ené.


1. Nesmie by možnos falošnej simulácie (napálením) schváleného legálne relevantného softvéra za použitie jednoduchých softvérových nástrojov. 2. Prezentované výsledky môžu by akceptované ako autentické, ak prezentácia je vydaná v rámci legálne relevantného softvéra.


Obmedzenia k 1B, 2B: Prostriedky sa považujú za ochranné proti úmyselnému zneužitiu, vrátane simulácie, pri om sú založené na základe alšieho hardvéru. 3. Odprezentované namerané hodnoty musia by sprevádzané hocijakou informáciou nevyhnutnou na zabránenie zámeny s ostatnými (z h adiska legálnej metrológie nerelevantnými) informáciami. 4. Technickými prostriedkami musí by zaistené, že na univerzálnom po íta i môžu fungova legálne relevantné funkcie iba schváleného softvéru na legálne relevantné ú ely (napr. senzor musí pracova spolu len so schváleným programom).


V dokumentácii by malo by opísané ako je zaru ená autentickos softvéru.


(dodato ne okrem dokumentácie vyžadovanej pre triedy rizík B a C): Ochranné opatrenia musia by vidite né. Validácia (dodato ne okrem Validácia: triedy rizík B a C): Kontrola založená na dokumentácii: • Pri skúške potrebujeme stanovi , ktorá prezentácia je Kontrola založená na vygenerovaná legálne relevantným softvérom a ako má by dokumentácii: zabránené zavádzaniu prostredníctvom programu, ktorý nie je • Kontrolujeme, i príslušné legálne relevantný. opatrenia sú vhodné • Kontrolujem, i legálne relevantné úlohy môže by vykonané len vzh adom na zákonom schváleným softvérom legálnej metrológie. stanovené požiadavky pre vysokú úrove ochrany. Kontroly funkcii: • Prekontrolujeme vizuálnou kontrolou, i prezentované výsledky sú ahko rozlíšite né od ostatných informácii, ktoré môžu by tiež prezentované. • Kontrolujeme pod a dokumentácii, i prezentované informácie sú kompletné.


Formálne prostriedky: 1. Softvérová identifikácia asti (B) (kontrolný sú et alebo íslo TEC, pozri U2) indikovaná softvérom je porovnávaná s požadovanou hodnotou uvedenou v TEC. Technické prostriedky: 1. Okno meracích aplikácii je vygenerované legálne relevantným softvérom. Technické opatrenia požadované na okná sú: • Namerané hodnoty sú najprv indikované a až potom k ním musí by daný prístup pre programy, ktoré nie sú legálne relevantné. • Okno je pravidelne obnovované. Program priradený na kontrolovanie kontroluje, i je vždy vidite né. • Spracovávanie nameraných hodnôt sa zastaví kedyko vek, ke toto okno je zatvorené alebo nie je kompletne vidite né. Opera ný manuál (a EC) musia obsahova kópie okna pre ú ely porovnania. 2a Senzorová jednotka šifruje namerané hodnoty s k ú om známym schválenému softvéru na bežiacom univerzálnom po íta i. (napr. ich íslo verzie). Len schválený softvér vie rozlúšti a použi namerané hodnoty, neschválené programy na univerzálnom po íta i toto nevedie, ak nemajú k ú . Pre spracovávanie s k ú om pozri rozšírenie T. 2b Pred odoslaním nameraných hodnôt senzor nadviaže sekven né spojenie s legálne relevantným 32 Realizované s finan nou podporou Európskej únie v rámci programu Prechodný fond

WELMEC WG7



softvérom na univerzálnom po íta i na základe tajného k ú a. Len ak program na univerzálnom po íta i za ne komunikova správne, senzorová jednotka odošle namerané hodnoty. Pre spracovávanie s k ú om pozri rozšírenie T. 3. K ú použitý v 2a/2b môže by 3. K ú použitý v 2a/2b je hash kódom programu na univerzálnom vybraný a zadaný senzorovej po íta i. Softvér na univerzálnom po íta i je zakaždým jednotke a softvéru na zmenený, nový k ú musí by zadaný do senzorovej jednotky univerzálnom po íta i bez a zaplombovaný. porušenia plomby.


Zdrojový kód legálne relevantného softvéra. Validácia (dodato ne okrem triedy rizík B a C): Kontrola založená na zdrojovom kóde: • Kontrolujeme, i legálne relevantný softvér prezentuje namerané výsledky. • Kontrolujeme, i všetky opatrenia sú vhodné a správne zaru ujú autentickos softvéru (napr. legálne relevantné úlohy môže by vykonané len schváleným softvérom legálnej metrológie).

Triedy rizík B až E U9: Ovplyvnenie iným softvérom

Legálne relevantný softvér musí by navrhnutý tak, aby nemohol by nedovolene ovplyvnený iným softvérom.


Tieto požiadavky nazna ujú softvérové oddelenie medzi legálne relevantným softvérom a softvérom, ktorý nie je legálne relevantný. Musí by splnené rozšírenie S. Toto je typickým prípadom pre univerzálny po íta .

Požadovaná dokumentácia: Pozri rozšírenie S.

Validácia:

Pozri rozšírenie S.

Príklad prijate ného riešenia: Pozri rozšírenie S.


WELMEC WG7

6



Rozšírenie L: Dlhodobé uchovávanie nameraných dát

Toto rozšírenie dodáva dodato né špecifické požiadavky na zabudovaný softvér pre jednoú elový merací prístroj (požiadavky typu P) a na softvér pre meradlá využívajúce univerzálny po íta (požiadavky typu U). Popisuje požiadavky na uchovávanie nameraných dát od kedy je meranie fyzicky ukon ené až dovtedy, ke sú všetky procesy spravené a ukon ené legálne relevantným softvérom. Toto môže by tiež aplikované na následné dlhodobé uchovávanie dát,

6.1

Technický popis

Súbor požiadaviek tohto rozšírenia sa aplikujem len vtedy, ak je v om zahrnuté dlhodobé uchovávanie nameraných dát. Týka sa to len tých nameraných dát, ktoré sú relevantné z h adiska legálnej metrológie. V nasledovnej tabu ke je zoznam troch rozdielnych technických konfigurácii pre dlhodobé uchovávanie. Pre jednoú elové zariadenia, je typický variant integrovanej pamäte: v tomto prípade je uchovávanie nevyhnutnou sú as ou metrologického hardvéru a softvéru. Pre meradlá využívajúce univerzálny po íta , je typický alší variant: použitie už existujúcich zdrojov, napr. pevný disk. Tretím variantom je vymenite né pamä : v tomto prípade môže by pamä odstránite ná zo zariadenia, ktoré môže by bu jednoú elovým zariadením alebo univerzálnym po íta om a môže by vzatý aj z iného po íta a. Ke sa získajú data z vymenite nej pamäte na právne ú ely, napr. vizualizácia, tla lístkov, at ., prístroj, musí takto vyberané zariadenie podlieha právnej kontrole. Integrovaná pamä Jednoduché meradlo, jednoú elové, bez žiadneho ved ajšieho použitie nástrojov alebo prostriedkov dostupných na úpravu alebo zmenu dát, integrovaná pamä na namerané data alebo parametre, napr. RAM, flash pamä , pevný disk. Pamä pre univerzálny po íta Univerzálny po íta , grafické užívate ské rozhrania, viacúlohový opera ný systém, úlohy podliehajúce právnej kontrole a nepodliehajúce právnej kontrole existujú paralelne, pamä môže by odstránite ná zo zariadenia alebo obsahy môžu by kopírované hocikedy vo vnútri alebo mimo po íta a. Vymenite ná alebo prenosnú (externá) pamä ubovo né základné meradlo (jednoú elový prístroj alebo meralo využívajúce univerzálny po íta ), pamä môže by odobratá z meradla. Tieto môžu by , napr. diskety, pomocné karty alebo prenosné databázy pripojené cez sie . Tabu ka 6-1: Technický popis meradla typu U.


WELMEC WG7

6.2



Špecifické požiadavky na softvér na dlhodobé uchovávanie

Požiadavky stanovené v tejto asti sa dajú aplikova okrem iného na súbor požiadaviek, bu na základné jednoú elové prístroje alebo na meradlá využívajúce univerzálny po íta . Trieda rizika B Trieda rizika C L1: Úplnos uchovávaných nameraných dát

Trieda rizika D

Uchovávané namerané data musia obsahova všetky relevantné informácie potrebné k rekonštrukcii skorších meraní.


1. Uchované namerané data môže by neskôr potrebné na referencie, napr. pri kontrole ú tovania. Všetky data, ktoré sú nutné pre právne a metrologické zdôvodnenia musia by uchovávané spolu s nameranými hodnotami.


Popis všetkých oblastí z dátových súborov.

Validácia:

Kontrola založená na dokumentácii: • Kontrolujeme, i všetky informácie potrebné pre právne relevantné a metrologické ú ely sú obsiahnuté v dátovom súbore.


Kompletný právny a metrologický dátový súbor sa skladá z nasledovných oblastí: • Nameranú(é) hodnotu(y) s dostato ným rozlíšením • Jednotky merania korigované z h adiska metrológie • Jednotkovú cenu alebo splatnú cenu (ak je aplikovate ná) • Miesto a as merania (ak je aplikovate ný) • Identifikáciu meradla ak je aplikovate né (externá pamä ) • Data sú uchovávané v rovnakom rozlíšení hodnôt, jednotiek at . ak sú uvedené alebo vytla ené na dodacom liste.

Dodatok pre triedu rizika E Požadovaná dokumentácia (dodato ne okrem požiadaviek pre triedy rizík B, C a D): Zdrojový kód, ktorý vygeneruje dátový súbor pre ukladanie.

Validácia (dodato ne okrem triedy rizík B, C a D):

Kontrola založená na zdrojovom kóde: • Kontrolujeme, i dátové súbory sú správne vytvorené.


WELMEC WG7



Trieda rizika B Trieda rizika C Trieda rizika D L2: Ochrana proti náhodným alebo neúmyselným zmenám Uložené namerané data musia by chránené proti náhodným a neúmyselným zmenám.


1. Náhodné zmeny dát môžu vzniknú fyzikálnymi vplyvmi. 2. Neúmyselné zmeny sú spôsobené užívate om zariadenia. Administratívne povinnosti môžu požadova data, ktoré prináležia k vloženiu alebo asovému skon eniu ú tovania po ich vymazanie, ktoré môže by z asu na as. Automatické alebo poloautomatické prostriedky by mali zabezpe i , aby boli vymazané len data, ktoré sa vyšpecifikujú a aby sa vyhlo náhodnému vymazaniu „živých“ dát. Toto je obzvláš dôležité pri prepojenom systéme a prenosnou alebo vymenite nou pamä ou, kde si užívatelia neuvedomujú dôležitos dát. 3. Kontrolný sú et musí by vypo ítaný prijíma om a porovná sa s priradenou nominálnou hodnotou. Ak hodnota zodpovedá, dátový súbor je platný a môže sa používa ; v opa nom prípade sa musí vymaza alebo ozna i ako neplatný.


Požadovaná

dokumentácia

Popis ochranných opatrení (napr. algoritmus kontrolného (dodato ne okrem dokumentácie sú tu, vrátane d žky pôvodného polynómu). vyžadovanej pre triedy rizík B a C): V dokumentácii musia by vidite né opatrenia validácii efektívnosti ochranných prostriedkov. Validácia: Validácia (dodato ne okrem triedy rizík B a C): Kontrola založená na dokumentácii: • Kontrolujeme, i kontrolný sú et dát je vygenerovaný. Kontrola založená na dokumentácii: • Kontrolujeme, i legálne relevantný softvér, ktorý íta data • Kontrolujeme, i opatrenia a vypo ítava kontrolný sú et skuto ne porovnáva a protokoly sú vhodné pre vysokú vypo ítané hodnoty s nominálnymi hodnotami. úrove ochrany. • Kontrolujeme, i sa prepísanie dát nemôže sta ešte pred koncom doby uchovávania dát, ktorá je predpísaná a zdokumentovaná výrobcom. • Kontrolujeme, i boli vydané upozornenia pre užívate ov, ak by sa chystali vymaza súbory nameraných dát. Kontroly funkcii: • Pokia je možné zmaza data, kontrolujeme praktickými náhlymi kontrolami, i pre zmazaním nameraných dát je dané varovanie.


•

•

Na zistenie zmeny dát spôsobených fyzikálnymi javmi po ítame kontrolný sú et pomocou algoritmu CRC-16 na celý dátový súbor a vkladáme ich do uloženého dátového súboru. Poznámka: Algoritmus nie je utajovaný na rozdiel od požiadavky L3 a nie je utajovaný ani úvodnému vektoru z registra CRC a ani pôvodnému polynómu, t.j. odkaz v algoritme. Úvodný vektor a pôvodný polynóm sú známe obom programom, t.j. programu, ktorý tvorí ako aj programu, ktorý overuje kontrolný sú et

Namerané data/vyú tované súbory musia by chránené pridelenou automatickou pe iatkou dátumu pri vytvorení a známkou alebo štítkom, na ktorom je uvedené, i je faktúra uhradená/neuhradená. Servisný program vie iba vymaza /presunú súbory, ak by faktúra nebola uhradená alebo by bola po dátume splatnosti. Namerané data nie sú vymazané bez predchádzajúceho povolenia, napr. dialógovým prehlásením alebo okno požadovaným pre potvrdenie zmazania.

Dodatok pre triedu rizika E Požadovaná dokumentácia (dodato ne okrem požiadaviek pre triedy rizík B, C a D): Zdrojový kód, ktorý realizuje ochranu uložených dát.


Kontrola založená na zdrojovom kóde: • Kontrolujeme, i opatrenia na ochranu uložených dát sú vhodné a správne implementované.


WELMEC WG7


Trieda rizika B L3: Integrita dát

Trieda rizika C


Trieda rizika D

Uchovávané namerané data musia by chránené proti úmyselným zmenám.



1. Táto požiadavka platí pre všetky typy pamätí okrem 1. Táto požiadavka platí pre všetky typy integrovaných pamätí. pamätí okrem integrovaných pamätí. 2. Ochrana musí by aplikovaná proti úmyselným 2. Ochrana musí by aplikovaná proti zmenám, ktoré sa dajú vykona jednoduchými bežnými úmyselným zmenám, ktoré sa dajú vykona softvérovými nástrojmi. špeciálnymi sofistikovanými softvérovými 3. Pod jednoduchými bežnými softvérovými nástrojmi sa nástrojmi. rozumejú nástroje, ktoré sú ahko dostupné 3. „Sofistikované softvérové nástroje“ sú napr. a ovládate né ako napr. kancelárske aplikácie. debuggeri, rekompilátory, softvérové vývojové prostriedky, at . 4. Úrove ochrany musí by ekvivalentná k požiadavkám na elektronickú platbu. 5. Ochrana je realizovaná elektronickým podpisom s algoritmom, ktorým sa garantuje, že z rozdielnych dátových súborov neexistuje identický výsledok podpisu. Poznámka: Aj ke algoritmus a k ú sú vo vysokej úrovni, technické riešenie s bežným univerzálnym po íta om nevedia zrealizova túto úrove ochrany, ak nie sú vhodné ochranné opatrenia pre programy, ktoré podpisujú alebo overujú dátové súbory (pozri základnú príru ku U pre univerzálne po íta e, komentár k požiadavke U6-D).


Metóda ako ochráni zdokumentovaná.

je

zrealizovaná

a musí

by

Požadovaná dokumentácia (dodato ne

okrem dokumentácie vyžadovanej pre triedy rizík B a C): Ochranné opatrenia musia by vidite né. Validácia: Validácia (dodato ne okrem triedy rizík B a C): Kontrola založená na dokumentácii: • Ak je použitý kontrolný sú et alebo podpis Kontrola založená na dokumentácii: Kontrolujeme i kontrolný sú et alebo podpis je • Kontrolujeme, i príslušné opatrenia sú vygenerovaný z celého dátového súboru. vhodné vzh adom na zákonom stanovené Kontrolujeme, i legálne relevantný softvér, ktorý íta požiadavky pre vysokú úrove ochrany. data alebo vypo ítava kontrolný sú et alebo dekóduje podpis skuto ne porovnáva hodnoty vypo ítane s hodnotami nominálnymi. • Kontrolujeme, i utajené data (napr. po iato ná hodnota k ú a, ak je použitá) sú držané v tajnosti pred špiónmi vystupujúcimi s jednoduchými nástrojmi. Kontroly funkcii: • Kontrolujeme, i sfalšované dátové súbory sú odmietnuté vybraným programom.


Ešte pred tým ako s použijú data, je hodnota kontrolného sú tu prepo ítavaná a porovnaná s uloženou nominálnou hodnotou. Ak hodnota zodpovedá, dátový súbor je platný a môže sa používa ; v opa nom prípade sa musí vymaza alebo ozna i ako neplatný. Prijate ným riešením je algoritmus CRC-16.


Namiesto CRC, je podpis vypo ítaný. Primeraný algoritmus podpisu vie by jedným z hash algoritmov, napr. SHA-1 alebo RipeMD160, v kombinácii so zakódovaným algoritmom ako napr. RSA alebo eliptické krivky. Minimálna d žka k ú a je 768 bitov Poznámka: Algoritmus nie je utajovaný, ale na rozdiel od (RSA) alebo 128-160 bitov (EK).

požiadavky L2, úvodného vektora registra CRC alebo po iato ného polynómu (t.j. delite v algoritme) musí by . Úvodný vektor a po iato ný polynóm sú známymi len programom generujúcim a overujúcim si kontrolný sú et. Tieto musia by spracované ako k ú e (pozri L5).


WELMEC WG7




Požadovaná dokumentácia (dodato ne okrem požiadaviek pre triedy rizík B a C): Zdrojový kód, ktorý realizuje integritu uložených dát.


Kontrola založená na zdrojovom kóde: • Kontrolujeme, i opatrenia na zabezpe enie integrity sú vhodné a správne implementované.

Trieda rizika B Trieda rizika C L4: Autentickos uložených nameraných dát

Trieda rizika D

Uložené namerané data musia by schopné spätne zisti autentickos vygenerovaného merania.


1. Autentickos nameraných dát môže by potrebná pre neskoršie preukazovanie, napr. pri kontrolovaní ú tovania. 2. Autentickos vyžaduje správne priradenie (spojenie) nameraných dát k meraniu, ku ktorému boli vygenerované data. 3. Pri autentickosti sa predpokladá identifikácia dátových súborov. 4. Zaistenie autentickosti nevyhnutne požaduje zakódovanie dát.

Požadovaná


Popis metódy použitej pri zaistení autentickosti.

dokumentácia

(dodato ne okrem dokumentácie vyžadovanej pre triedy rizík B a C): Ochranné opatrenia musia by vidite né. Validácia: Validácia (dodato ne okrem triedy rizík B a C): Kontrola založená na dokumentácii: • Kontrolujeme, i je správne spojenie medzi každou Kontrola založená na dokumentácii: nameranou hodnotou a príslušným meraním. • Kontrolujeme, i príslušné opatrenia sú • Ak je použitý kontrolný sú et alebo podpis, vhodné vzh adom na zákonom skontrolujeme, i kontrolný sú et alebo podpis sú stanovené požiadavky pre vysokú úrove ochrany. vygenerované z celého dátového súboru. • Kontrolujeme, i utajené data (napr. po iato ná hodnota k ú a, ak je použitá) sú držané v tajnosti pred špiónmi vystupujúcimi s jednoduchými nástrojmi. Kontroly funkcii: • Kontrolujeme, i sú identické príslušné uložené data s datami vytla enými na lístku alebo ú tenke.


Uložený dátový súbor obsahujú nasledovné oblasti dát (navyše k oblastiam zadefinovaným v L3). • Jedine né identifika né íslo. Identifika né íslo je tiež skopírované v dodacom liste. • as, kedy bolo meranie vykonané ( asový údaj). asový údaj je tiež skopírovaný v dodacom liste. • Identifikáciu meradla, ktoré vygenerovalo hodnotu. • podpis, ktorý je použitý na zaistenie integrity dát a sú asne môže by použitý aj na zaistenie autentickosti. Podpis pokrýva všetky oblasti dátový súbor. Odvolávka na požiadavku L2, L3. • Na lístku môže by stanovené, že namerané hodnoty môžu by porovnávané s referen nými datami prostriedkami na uchovávanie, ktoré podliehajú právnej kontrole. Prira ovanie je porovnávanie identifika ného ísla alebo asového údaju vytla eného na dodacom liste s tým, ktorý je uložený dátový súbor.


Zdrojový kód, ktorý generuje dátový súbor pre ukladanie a realizuje autentickos . Validácia (dodato ne okrem triedy rizík B a C): Kontrola založená na zdrojovom kóde: • Kontrolujeme, i sú dátový súbor správne postavené a spo ahlivo autentifikované.


WELMEC WG7


Trieda rizika B Trieda rizika C L5: Dôveryhodnos k ú ov


Trieda rizika D

K ú e a sprievodné data musia by legálne relevantnými datami a musia by udržiavané v tajnosti a musia by chránené proti odhalením softvérovými nástrojmi.




Požadovaná



1. Táto požiadavka sa aplikuje len ak je použitý utajený 1. Táto požiadavka platí pre pamä kú . v univerzálnom po íta i a pre 2. Táto požiadavka platí pre uložené namerané data, 2. Ochrana musí by aplikovaná proti ktoré sú externého meradla alebo boli realizované na úmyselnými zmenám, ktoré sa dajú univerzálnom po íta i. vykona špeciálnymi sofistikovanými 3. Ochrana musí by aplikovaná proti úmyselnými softvérovými nástrojmi. zmenám, ktoré sa dajú vykona bežnými 3. Musí by použitá vhodná metóda, ktorá je jednoduchými softvérovými nástrojmi. ekvivalentnou k elektronickej platbe. 4. Ak je zamedzený prístup k utajeným k ú om, nar. Užívate musí by schopný overi Zaplombovaním krytu jednoú elového zariadenia, nie autentickos verejného k ú a. sú požadované žiadne alšie ochranné softvérové prostriedky.

dokumentácia

Popis manažmentu k ú a a prostriedkov pre držanie (dodato ne okrem dokumentácie k ú ov a priradených tajných informácii. vyžadovanej pre triedy rizík B a C): Ochranné opatrenia musia by vidite né. Validácia: Validácia (dodato ne okrem triedy rizík B a C): Kontrola založená na dokumentácii: • Kontrolujeme, i je tajné informácie nemôžu by Kontrola založená na dokumentácii: odhalené. • Kontrolujeme, i príslušné opatrenia sú vhodné vzh adom na zákonom stanovené požiadavky pre vysokú úrove ochrany. Utajený k ú a sprievodné data sú ukladané v binárnom formáte v spustite nom kóde legálne relevantného softvéru. Nie je jasné, v ktorom adresári sú tieto data uchované. Softvérový systém neponúka žiadne funkcie na zobrazenie alebo editovanie týchto dát. Ak je používaný ako podpis CRC algoritmus, tak po iato ný vektor alebo pôvodný polynóm sú v roly k ú a.

Utajený k ú je ukladaný v hardvérovej asti, ktorá môže by fyzicky zaplombovaná. Softvér neponúka žiadne funkcie na zobrazenie alebo editovanie týchto dát. Poznámka: Technické riešenia štandardným osobným po íta om nie sú dostato né na to, aby zabezpe ili vysokú úrove ochrany, ak tam nie je vhodná hardvérová ochrana prostriedkami pre k ú a pre ostatné tajné data (pozri základnú príru ku pre univerzálny po íta U6).

1) Infraštruktúra verejného k ú a: Pamä verejného k ú a podliehajúca právnej kontrole bola certifikovaná akreditovaným dôveryhodným centrom. 2) Priama dôvera: Nie je nevyhnutné požadova dôveryhodnos centra, ak predošlou dohodou oboma stranami, je schopnos priamo íta verejný k ú meradla v zariadení, ktoré podlieha právnej kontrole, a ktorý zobrazuje relevantný dátový súbor.


Požadovaná dokumentácia (dodato ne okrem požiadaviek pre triedy rizík B a C): Zdrojový kód, ktorý realizuje manažment k ú a.


Kontrola založená na zdrojovom kóde: • Kontrolujeme, i opatrenia pre manažment k ú a sú vhodné.


WELMEC WG7


Trieda rizika B Trieda rizika C L6: Na ítanie uložených dát


Trieda rizika D

Softvér používaný pri overení uložených meraní dátových súborov musí zobrazi alebo vytla i data, skontroluje zmeny v dátach a upozorní ak sa vyskytli nejaké zmeny. Uložené namerané data musia by schopné spätne zisti autentickos vygenerovaného merania. Data, pri ktorých sa zistilo, že boli poškodené sa nesmú používa .


1. Ukladané namerané data by v neskoršej dobe mohli by potrebné k predloženiu, napr. pri transakciách, ktoré sú spochybnite né. Ak je z dodacieho listu alebo lístku spochybnite ná správnos , musí by možné identifikova uložené namerané data k spornému meraniu bez dvojzna nosti (odvolávka na L1, L3, L4 a L5). 2. Identifika né íslo (pozri L1) musí by vytla ené na dodacom liste/lístku pre zákazníka sú asne spolu s vysvetlením a odkazom na ukladanie podliehajúce právnej kontrole. 3. Overenie znamená kontrolu integrity, autentickosti a správneho pridelenia uložených nameraných dát . 4. Overený softvér používaný pri zobrazení alebo tla i uložených dát musí podlieha právnej kontrole. 5. Pre prístroje so špecifickými požiadavkami, odkaz na rozšírenie I.

Požadovaná

Požadovaná dokumentácia: • • •

Popis funkcii vybraného programu. Popis vyh adávania korupcie. Opera ný manuál pre tento program.

dokumentácia

(dodato ne okrem dokumentácie vyžadovanej pre triedy rizík B a C): Ochranné opatrenia musia by vidite né. Validácia: Validácia (dodato ne okrem triedy rizík B a C): Kontrola založená na dokumentácii: • Kontrolujeme, i vybraný softvér skuto ne porovnáva Kontrola založená na dokumentácii: vypo ítané hodnoty s nominálnymi hodnotami. • Kontrolujeme, i príslušné opatrenia sú • Kontrolujeme, i vybraný softvér je as ou legálne vhodné vzh adom na zákonom relevantného softvéru. stanovené požiadavky pre vysokú úrove ochrany. Kontroly funkcii: • Kontrolujeme, i program odhalí poškodenie dátové súbory. • Vykonáme náhlu kontrolu overenia, ktorá vyh adá všetky relevantne poskytnuté informácie.


Dátový súbor je na ítaný z pamäte overeného programu a podpis na všetkých oblastiach dát je prepo ítaný a porovnaný s uloženými nominálnymi hodnotami. Ak sa obe hodnoty porovnajú, dátový súbor je správny, v opa nom prípade sú sa data nepoužívajú a sú vymazané alebo ozna ené ako neplatné.


Požadovaná dokumentácia (dodato ne okrem požiadaviek pre triedy rizík B a C): Zdrojový kód vybraného programu.


Kontrola založená na zdrojovom kóde: • Kontrolujeme, i opatrenia pre výber, overenie podpisu at . sú vhodné a správne implementované.


WELMEC WG7


Trieda rizika B Trieda rizika C L7: Automatické ukladanie


Trieda rizika D

Namerané data musia by automaticky ukladané po skon ení merania.


1. Táto požiadavka platí pre všetky typy ukladanie 2. Táto požiadavka znamená, že funkcia ukladania nesmie závisie od rozhodnutia operátora. Napriek tomu, pri ur itých typoch meradiel, napr. pri váhach je požadované rozhodnutie alebo príkaz od operátora, i sa akceptuje výsledok alebo nie. Inými slovami, tam kde by mohlo ís o pomocné merania, ktoré nebude ukladané (napr. po as s ahovania alebo pred množstvom výrobkov požadovaných v s ahovaných sníma och. Alebo, ešte v tomto prípade, ke výsledok bude automaticky ukladaný, až ke operátor akceptuje výsledok. 3. V prípade zaplnenia pamäte, odkaz na požiadavku L8.


Potvrdenie o vykonaní automatického ukladania. Grafický popis užívate ského rozhrania.

Validácia:

Kontroly funkcii: • Kontrolujeme náhlymi kontrolami, i namerané hodnoty sú automaticky ukladané po meraní alebo je ukon ené prijatie merania. Kontrolujeme, i nie sú nejaké tla idlá alebo položky v menu, ktoré by prerušili alebo vypli automatické ukladanie.


Neexistujú žiadne položky v menu alebo tla idlá v grafickom užívate skom rozhraní (GUI), ktoré podporujú manuálne spustenie ukladania nameraných výsledkov. Namerané hodnoty sú obsiahnuté v dátovom súbore spolu s alšími informáciami, ako napr. asový údaj a podpis a tieto sú ukladané ihne po meraní, alebo po prijatí merania, v tomto poradí.


Požadovaná dokumentácia (dodato ne okrem požiadaviek pre triedy rizík B, C a D): Zdrojový kód meradla.


Kontrola založená na zdrojovom kóde: • Kontrolujeme, i opatrenia na automatické uchovávané sú vhodné a správne implementované.


WELMEC WG7


Trieda rizika B Trieda rizika C L8: Kapacita pamäte a kontinuita


Trieda rizika D

Dlhodobé uchovávanie musí ma kapacitu, ktorá je dostato ná pre plánovaný ú el.


1. Ak je pamä plná alebo odstránená/odpojená z meradla, musí by dané varovanie operátorovi. Varovanie nie je nutné, ak je konštruk ne zaistené prepisovanie starých údajov. Pre alšie nevyhnutné aktivity odkazujúce na meradlo - špecifické požiadavky (rozšírenie I). 2. Usmernenie týkajúce sa minimálnej doby uchovania nameraných dát je nad rámec tejto požiadavky a odkazuje sa na národné predpisy. Je na zodpovednosti vlastníka ma meradlo s dostato nou kapacitou pamäte k splneniu požiadavky aplikovanej na jeho aktivitu. Notifikovaná osoby na ES skúšku typu kontroluje len, i údaje sú uložené a získané správne a i je zabránené novým transakciám, ke je pamä plná. 3. Taktiež je nad rámec tejto požiadavky požadova ur ité nápisy na zariadení, pokia ide o kapacitu pamäte alebo iné sprievodné informácie, ktoré umož ujú výpo et kapacity. Napriek tomu, výrobca musí poskytnú informáciu o kapacite.


Popis manažmentu výnimo ných prípadov ukladania nameraných hodnôt.

Validácia:

Kontrola na základe dokumentácie: • Kontrolujeme, i je výrobcom daná kapacita ukladania alebo vzorec na výpo et. • Kontrolujeme, i nie je možné prepísanie údajov pred koncom doby ukladania dát, ktoré sú prednastavené a zdokumentované výrobcom. Kontroly funkcii: • Kontrolujeme, i je vydané varovanie používate ovi, ak ja chystá vymaza dátové súbory (ak je vôbec možné mazanie). • Kontrolujeme, i je varovanie, ak je pamä plná alebo odstránená.


Na prerušenie merania, ktoré môže by zatavené ahko a rýchlo, napr. pri vážení ako meraní paliva, at ., môže by meranie ukon ené aj ke sa pamä stane nedostupnou. Meradlo alebo zariadenia by mali ma zásobník, ktorý je dostato ne ve ký na ukladanie aktuálnych transakcii. Po tomto, nemali by by naštartované žiadne nové transakcie a ochránené hodnoty by mali by držané pre neskorší prenos do novej pamäte. • Merania, ktoré sú prerušite né, napr. meranie energie, objemu at . nepotrebujú špeciálny do asný zásobník, pretože tieto merania sú vždy kumulatívne. Kumulatívny zoznam môže by ítaný alebo prenášaný do pamäte v neskoršom ase, ke je už pamä znova k dispozícii. • Namerané data môžu by automaticky prepísané utilitou, ktorá kontroluje, i namerané data nie sú zastaralé (odkaz na národné predpisy pre relevantné obdobie) alebo, í ú et bol zaplatený. Utilita musí vyzva používate a na dovolené vymazanie a data musia by vymazané v poradí od najstaršej.


Požadovaná dokumentácia (dodato ne okrem požiadaviek pre triedy rizík B, C a D): Zdrojový kód, ktorý realizuje uchovávanie dát.


Kontrola založená na zdrojovom kóde: • Kontrolujeme, i opatrenia na uchovávanie sú vhodné a správne implementované.


WELMEC WG7

7



Rozšírenie T: Prenos meraných dát cez komunika né siete

Toto je rozšírenie v softvérových požiadavkách základných príru iek P a U. Musia by používané len v tom prípade, ak sú namerané data prenášané prostredníctvom komunika nej siete do vzdialeného zariadenia, kde sú oni alej spracovávané a/alebo používané na zákonne regulované ú ely. Toto rozšírenie nie je aplikované, ak neexistujú žiadne alšie legálne relevantne spracované data. Ak je softvér stiahnutý do zariadenia, ktoré podlieha právnej kontrole, aplikujú sa požiadavky z rozšírenia D.

7.1

Technický popis

Súbor požiadaviek z tohto rozšírenia sa aplikujú len ak je posudzovaný prístroj pripojený na sie a prenáša alebo prijíma namerané data, ktoré sú legálne relevantné. V nasledovnej tabu ke sú identifikované tri konfigurácie siete. Najjednoduchšia je rada zariadení, kde všetky podliehajú právnej kontrole. Ú astníci sú zafixovaný v overení pod a zákona. Variantom k tomuto (uzavretá sie , iasto ne pod právnou kontrolou) je sie s ú astníkmi, ktorí nie sú predmetom právnej kontroly, ale všetci sú známy a nemožno ich zmeni po as operácie. Otvorená sie nemá žiadne limity v identite, funk nosti, postavení a lokalitou ú astníkov. Popis konfigurácií Uzavretá sie , kompletne pod právnou kontrolou Len fixný po et ú astníkov s jasnou identitou, funk nos ou a lokalitou je pripojených. Všetky zariadenia podliehajú právnej kontrole. V sieti neexistujú zariadenia, ktoré nie sú predmetom právnej kontroly. Uzavretá sie , iasto ne pod právnou kontrolou Zafixovaný po et ú astníkov s jasnou identitou a lokalitou je pripojených na sie . Nie všetky zariadenia podliehajú právnej kontrole a preto je ich funk nos neznáma. Otvorená sie ubovo ný ú astníci (zariadenia s ubovo nými funkciami) môžu by pripojený k sieti. Identita a funk nos ú asti zariadenia a ich poloha môžu by neznáma pre ostatných ú astníkov. Každá sie , ktorá obsahuje právne kontrolované zariadenia s IR alebo bezdrôtovým sie ovým komunika ným rozhraním musí by považovaná za otvorenú sie . Tabu ka 7-1:

Technický popis meradiel typu U


WELMEC WG7

7.2



Špecifické požiadavky na softvér na dátový prenos

Trieda rizika B T1: Úplnos prenesených dát

Trieda rizika C

Trieda rizika D

Prenesené data musia obsahova všetky relevantné informácie nevyhnutné k prezentovaniu alebo k neskoršiemu spracovaniu výsledkov merania v prijímacej jednotke.


1. Metrologická as prenášaných dátových súborov sa skladá z jednej alebo viacerých nameraných hodnôt so správnym rozlíšením, zákonne správnej jednotky merania a je závislá na aplikácii jednotkovej ceny alebo splatnej ceny a na mieste merania.


Dokument všetkých oblastí dátového súboru.

Validácia:

Kontrola založená na dokumentácii: • Kontrolujeme, i všetky informácie na neskoršie spracovanie nameraných hodnôt v prijímacej jednotke sú obsiahnuté v dátovom súbore.


Dátový súbor sa skladá z nasledovných oblastí: • Nameranú(é) hodnotu(y) s dostato ným rozlíšením • Jednotky merania korigované z h adiska metrológie • Jednotkovú cenu alebo splatnú cenu (ak je aplikovate ná) • as a dátum merania (ak je aplikovate ný) • Identifikáciu meradla ak je aplikovate né (prenesenie dát) • Miesto merania (ak je aplikovate né)

Dodatok pre triedu rizika E Požadovaná dokumentácia (dodato ne okrem požiadaviek pre triedy rizík B, C a D): Zdrojový kód, ktorý vygeneruje dátový súbor na prenášanie.


Kontrola založená na zdrojovom kóde: • Kontrolujeme, i dátové súbory sú správne vytvorené.


WELMEC WG7



Trieda rizika B Trieda rizika C Trieda rizika D T2: Ochrana proti náhodným alebo neúmyselným zmenám Prenesené data musia by chránené proti náhodným a neúmyselným zmenám.


1. Náhodné zmeny dát môžu vzniknú fyzikálnymi vplyvmi. 2. Neúmyselné zmeny sú spôsobené užívate om zariadenia. 3. Prostriedky musia odhali chyby pri prenose.


Požadovaná

dokumentácia

Popis algoritmus kontrolného sú tu, ak je použitý, vrátane (dodato ne okrem dokumentácie d žky vygenerovaného polynómu. vyžadovanej pre triedy rizík B a C): Popis alternatívnej metódy ak je použitá. V dokumentácii musia by vidite né opatrenia validácii efektívnosti ochranných prostriedkov. Validácia: Validácia (dodato ne okrem triedy rizík B a C): Kontrola založená na dokumentácii: • Kontrolujeme, i kontrolný sú et dát je vygenerovaný. Kontrola založená na dokumentácii: • Kontrolujeme, i legálne relevantný softvér, ktorý prijíma • Kontrolujeme, i opatrenia data prepo ítané kontrolným sú tom a i ich porovnáva a protokoly sú vhodné pre vysokú s nominálnou hodnotou obsiahnutou v dátovom súbore. úrove ochrany.


1) Na detekciu zmien dát je vypo ítaný kontrolný sú et s algoritmom CRC-16 zo všetkých bytov dátového súboru a sú vložené do dátového súboru k prenosu. Ešte predtým sú data znovu použité, hodnoty kontrolného sú tu sú prepo ítané prijíma om a porovnané s prípustnými nominálnymi hodnotami. Ak tieto hodnoty zodpovedajú, dátový súbor je platný a môžu by použité, v opa nom prípade musia by vymazané alebo ozna ené ako neplatné. Poznámka: Algoritmus nie je utajovaný na rozdiel od požiadavky T3 a nie je utajovaný ani úvodnému vektoru z registra CRC a ani pôvodnému polynómu, t.j. odkaz v algoritme. Úvodný vektor a pôvodný polynóm sú známe obom programom, t.j. programu, ktorý tvorí ako aj programu, ktorý overuje kontrolný sú et

2) Poskytnuté použité prostriedky pod a odovzdávacieho protokolu napr. TCP/IP, IFSF.

Dodatok pre triedu rizika E Požadovaná dokumentácia (dodato ne okrem požiadaviek pre triedy rizík B, C a D): Zdrojový kód, ktorý realizuje ochranu prenesených dát.


Kontrola založená na zdrojovom kóde: • Kontrolujeme, i opatrenia na ochranu prenesených dát sú vhodné.


WELMEC WG7

Trieda rizika B T3: Integrita dát



Trieda rizika C

Legálne relevantné prenesené data musia by nástrojmi..

Trieda rizika D

chránené proti úmyselným zmenám so softvérovými



1. Táto požiadavka je aplikovate ná len na siete, ktoré sú 1. Táto požiadavka platí pre otvorenú sie a as uzatvorenej siete, ktorá podlieha právnej otvorené alebo len na as , ktorá je pod právnou kontrole. kontrolou, nie na uzatvorenú sie . 2. Ochrana je realizovaná elektronickým 2. Ochrana musí by aplikovaná proti úmyselným podpisom s algoritmom, ktorým sa garantuje, zmenám, ktoré sa dajú vykona jednoduchými bežnými že z rozdielnych dátových súborov neexistuje softvérovými nástrojmi. identický výsledok podpisu. 3. Pod jednoduchými bežnými softvérovými nástrojmi sa 3. Ochrana musí by aplikovaná proti rozumejú nástroje, ktoré sú ahko dostupné úmyselným zmenám, ktoré sa dajú vykona a ovládate né ako napr. kancelárske aplikácie. špeciálnymi sofistikovanými softvérovými nástrojmi. 4. „Sofistikované softvérové nástroje“ sú napr. debuggeri, rekompilátory, softvérové vývojové prostriedky, at . 5. Úrove ochrany musí by ekvivalentná k požiadavkám na elektronickú platbu.

Poznámka: Aj ke algoritmus a k ú sú vo vysokej úrovni, technické riešenie s bežným univerzálnym po íta om nevedia zrealizova túto úrove ochrany, ak nie sú vhodné ochranné opatrenia pre programy, ktoré podpisujú alebo overujú dátové súbory (pozri základnú príru ku U pre univerzálne po íta e, komentár k požiadavke U6-D).


Požadovaná dokumentácia (dodato ne okrem dokumentácie vyžadovanej pre triedy rizík B a C): Ochranné opatrenia musia by vidite né. Validácia: Validácia (dodato ne okrem triedy rizík B a C): Kontrola založená na dokumentácii: • Ak je použitý kontrolný sú et alebo podpis Kontrola založená na dokumentácii: Kontrolujeme i kontrolný sú et alebo podpis je • Kontrolujeme, i príslušné opatrenia sú vygenerovaný z celého dátového súboru. vhodné vzh adom na zákonom stanovené Kontrolujeme, i legálne relevantný softvér, ktorý požiadavky pre vysokú úrove ochrany. prijíma data prepo ítané kontrolným sú tom alebo dekóduje podpis a i ho porovná s nominálnou hodnotou obsiahnutou v dátovom súbore. • Kontrolujeme, i utajené data (napr. po iato ná hodnota k ú a, ak je použitá) sú držané v tajnosti pred špiónmi vystupujúcimi s jednoduchými nástrojmi. Popis ochrannej metódy.


•


Kontrolný sú et je vygenerovaný dátovým súborom na • prenesenie. Ešte predtým sú data znovu použité, hodnoty kontrolného sú tu sú prepo ítané a porovnané s nominálnymi hodnotami, ktoré sú obsiahnuté v dátovom súbore. Ak tieto hodnoty zodpovedajú, je dátový súbor platný a môžu by použité, v opa nom prípade musia by vymazané alebo ozna ené ako neplatné. • Prijate ným riešením je algoritmus CRC-16.

Poznámka: Algoritmus nie je utajovaný, ale na rozdiel od požiadavky T2, úvodného vektora registra CRC alebo po iato ného polynómu (t.j. delite v algoritme) sú tajné. Úvodný vektor a po iato ný polynóm sú známymi len programom generujúcim a overujúcim si kontrolný sú et. Tieto musia by

Namiesto CRC, je podpis vypo ítaný. Primeraný algoritmus podpisu vie by napr. jedným z hash algoritmov, napr. SHA-1 alebo RipeMD160, v kombinácii so zakódovaným algoritmom ako RSA alebo eliptické krivky. Minimálna d žka k ú a je 768 bitov (RSA) alebo 128-160 bitov (EK). Ochrana je za predpokladu niektorých odovzdávacích protokolov napr. HTTPS.


WELMEC WG7



spracované ako k ú e (pozri T5).


Zdrojový kód, ktorý realizuje integritu prenesených dát. Validácia (dodato ne okrem triedy rizík B a C): Kontrola založená na zdrojovom kóde: • Kontrolujeme, i opatrenia na zabezpe enie integrity prenesených dát sú vhodné.

Trieda rizika B Trieda rizika C T4: Autentickos prenesených dát

Trieda rizika D

Pre program, ktorý prijíma prenesené relevantné data musí by umožnené overi si jeho autentickos a pridelené namerané hodnoty k ur itému meraniu.


1a V sieti s neznámymi ú astníkmi je nevyhnutné identifikova pôvodne namerané data prenesené bez pochybností. (Autentickos sa spolieha na identifika né íslo dátového súboru a na adresu siete). 1b V uzatvorenej sieti sú všetci ú astníci známy. Nie sú potrebné alšie prostriedky IT, ale topológia siete (po et ú astníkov) musí by fixne zaplombované. 2. Nepredvídané oneskorenie je možné v priebehu prenášania. Pre správne pridelenie prijatých nameraných hodnôt k ur itému meraniu musí by zaregistrovaný as z merania. 3. Na zabezpe enie autentickosti nie je nutné zakódovanie nameraných dát.


Požadovaná

dokumentácia

Sie s neznámymi ú astníkmi: Popis prostriedkov IT pre (dodato ne okrem dokumentácie správne priradenie nameranej hodnoty k meraniu. vyžadovanej pre triedy rizík B a C): Uzatvorená sie : Popis hardvérových prostriedkov Ochranné opatrenia musia by vidite né. zachovávajúcich po et ú astníkov v sieti. Popis po iato nej identifikácie ú astníkov. Validácia: Validácia (dodato ne okrem triedy rizík B a C): Kontrola založená na dokumentácii: • Kontrolujeme, i je správne spojenie medzi každou Kontrola založená na dokumentácii: nameranou hodnotou a príslušným meraním. • Kontrolujeme, i príslušné opatrenia sú • Kontrolujeme, i data sú digitálne podpísané a i je vhodné vzh adom na zákonom zabezpe ená ich správna identifikácia a autentickos . stanovené požiadavky pre vysokú úrove ochrany.

Príklad prijate ného riešenia: • • • •

Každý dátový súbor má jedine né (platné) identifika né íslo, ktoré môže as kedy bolo meranie vykonané ( asový údaj). Každý dátový súbor obsahuje informácie o pôvode nameraných dát, t.j. výrobné íslo alebo identifikáciu meradla, ktoré vygenerovalo hodnotu. V sieti s neznámymi ú astníkmi, je zaru ená autentickos ak dátový súbor bol prenesený jednozna ným podpisom. Podpis obsahuje všetky tieto oblasti dátového súboru. Prijíma dátového súboru kontroluje všetky data i sú prijate né.


Požadovaná dokumentácia (dodato ne okrem požiadaviek pre triedy rizík B a C): Zdrojový kód zariadenia, ktoré odosiela a prijíma.


Kontrola založená na zdrojovom kóde: • Kontrolujeme, i opatrenia na zabezpe enie autentickosti prenesených dát sú vhodné.


WELMEC WG7


Trieda rizika B Trieda rizika C T5: Dôveryhodnos k ú ov


Trieda rizika D

K ú e a sprievodné data musia by legálne relevantnými datami a musia by udržiavané v tajnosti a musia by chránené proti odhalením softvérovými nástrojmi.




Požadovaná



1. Táto požiadavka sa aplikuje len ak je existuje v 1. Táto požiadavka sa aplikuje len ak je systéme utajený k ú . (Nie je bežné v uzatvorenej existuje v systéme utajený k ú . (Nie je sieti) bežné v uzatvorenej sieti) 2. Ochrana musí by aplikovaná proti úmyselnými 2. Ochrana musí by aplikovaná proti zmenám, ktoré sa dajú vykona bežnými úmyselnými zmenám, ktoré sa dajú jednoduchými softvérovými nástrojmi. vykona špeciálnymi sofistikovanými 3. Ak je zamedzený prístup k utajeným k ú om, napr. softvérovými nástrojmi. zaplombovaním krytu jednoú elového zariadenia, nie 3. Prijaté namerané data sú ítané sú požadované žiadne alšie ochranné softvérové z dátového súboru a ich podpis je prostriedky. kontrolovaný s pomocou verejného k ú a zaslaného k meradlu (alebo zariadenia, ktoré generuje relevantné dátové súbory). S touto kontrolou prijíma a môžeme preukáza , že hodnota a podpis patria k sebe. 4. Musí by použitá vhodná metóda, ktorá je ekvivalentnou k elektronickej platbe.

dokumentácia

Popis manažmentu k ú a a prostriedkov pre držanie (dodato ne okrem dokumentácie k ú ov a priradených tajných informácii. vyžadovanej pre triedy rizík B a C): Ochranné opatrenia musia by vidite né. Validácia: Validácia (dodato ne okrem triedy rizík B a C): Kontrola založená na dokumentácii: • Kontrolujeme, i je tajné informácie nemôžu by Kontrola založená na dokumentácii: odhalené. • Kontrolujeme, i príslušné opatrenia sú vhodné vzh adom na zákonom stanovené požiadavky pre vysokú úrove ochrany. Utajený k ú a sprievodné data sú ukladané v binárnom formáte v spustite nom kóde legálne relevantného softvéru. Nie je jasné, v ktorom adresári sú tieto data uchované. Softvérový systém neponúka žiadne funkcie na zobrazenie alebo editovanie týchto dát. Ak je používaný ako podpis CRC algoritmus, tak po iato ný vektor alebo pôvodný polynóm sú v roly k ú a.

Utajený k ú je ukladaný v hardvérovej asti, ktorá môže by fyzicky zaplombovaná. Softvér neponúka žiadne funkcie na zobrazenie alebo editovanie týchto dát. Poznámka: Technické riešenia štandardným osobným po íta om nie sú dostato né na to, aby zabezpe ili vysokú úrove ochrany, ak tam nie je vhodná hardvérová ochrana prostriedkami pre k ú a pre ostatné tajné data (pozri základnú príru ku pre univerzálny po íta U6).

1) Infraštruktúra verejného k ú a: Pamä verejného k ú a podliehajúca právnej kontrole bola certifikovaná akreditovaným dôveryhodným centrom. 2) Priama dôvera: Nie je nevyhnutné požadova dôveryhodnos centra, ak predošlou dohodou oboma stranami, je schopnos priamo íta verejný k ú meradla v zariadení, ktoré podlieha právnej kontrole, a ktorý zobrazuje relevantný dátový súbor.


WELMEC WG7




Požadovaná dokumentácia (dodato ne okrem požiadaviek pre triedy rizík B a C): Zdrojový kód, ktorý realizuje manažment k ú a.


Kontrola založená na zdrojovom kóde: • Kontrolujeme, i opatrenia pre manažment k ú a sú vhodné.

Trieda rizika B Trieda rizika C T6: Zaobchádzanie s poškodenými datami

Trieda rizika D

Data, pri ktorých sa zistilo, že boli poškodené sa nesmú používa .


1. Komunika né protokoly bežne opakujú prenosy až do skon enia, napriek tomu sa môže sta , že sú prijaté aj poškodené dátové súbory.


Popis zis ovania úmyselných zmien.

prenášaných

Požadovaná

poškodení

dokumentácia

alebo (dodato ne okrem dokumentácie vyžadovanej pre triedy rizík B a C): Opatrenia pre zaobchádzanie s poškodenými datami musia by vidite né. Validácia: Validácia (dodato ne okrem triedy rizík B a C): Kontrola založená na dokumentácii a kontrole funkcií: • Kontrolujeme, i poškodené data nie je možné používa Kontrola založená na dokumentácii: pod a dodanej koncepcie. • Kontrolujeme, i príslušné opatrenia sú vhodné vzh adom na zákonom stanovené požiadavky pre vysokú úrove ochrany.


Ke program, ktorý prijíma dátové súbory zistí nezhodu medzi dátovým súborom a nominálnou hodnotou podpisu, v prvom rade sa pokúsi opravi pôvodné hodnoty, ak sú k dispozícii informácie, ktoré sú prebyto né. Ak táto oprava zlyhá, vygeneruje sa varovanie užívate a a to aby nerobil výstupy nameraných hodnôt a • Umiestnil ozna enie v špeciálnom poli dátového súboru (stavovej oblasti) v znení „neplatné“ ALEBO • Vymazal poškodený dátové súbory.


Požadovaná dokumentácia (dodato ne okrem požiadaviek pre triedy rizík B a C): Zdrojový kód zariadenia, ktoré prijíma.


Kontrola založená na zdrojovom kóde: • Kontrolujeme, i opatrenia pre zaobchádzanie s poškodenými datami sú vhodné.

Trieda rizika B Trieda rizika C T7: Oneskorenie pri prenose

Trieda rizika D

Meranie nesmie ma vplyv na oneskorenie pri prenose.


Výrobca musí preskúma asovú náro nos prenosu dát a musí sa zaru i , že ani pri najhorších prípadoch podmienok merania nedôjde k ovplyvneniu oneskorenia pri prenose.


Popis koncepcie, ako sú chránené merania proti oneskoreniu prenosom.

Validácia: •

Kontrolujeme koncepcie, i nie je vplyv na oneskorenie pri prenose.


Implementácia odovzdávacích protokolov pre oblasti field bus. 49 Realizované s finan nou podporou Európskej únie v rámci programu Prechodný fond

WELMEC WG7




Požadovaná dokumentácia (dodato ne okrem požiadaviek pre triedy rizík B, C a D): Zdrojový kód, ktorý realizuje prenos dát.


Kontrola založená na zdrojovom kóde: • Kontrolujeme, i opatrenia na zaobchádzanie s oneskoreným prenosom sú vhodné.

Trieda rizika B Trieda rizika C T8: Dostupnos služieb prenosu

Trieda rizika D

Ak sa služby siete stanú nedostupnými, žiadne namerané data sa nesmú strati .


1. Užívate meracieho systému nesmie poškodi namerané data pri prenášaní. 2. Prenos porúch sa môže sta náhodne a nemôžu by vy até. Prístroj, ktorý odosiela musí by schopný zachova tento stav. 3. Reakcia meradla, ak sa služba prenosu stala neprípustnou, závisí na princípe merania (pozri as I).


Popis ochranných opatrení proti prerušeniu prenosu alebo iných porúch.

Validácia:

Kontrola na základe dokumentácie: • Kontrolujeme, pri ktorých opatreniach je implementovaná ochrana pred stratou dát. • Kontrolujeme, ktoré opatrenia sú predvídané pre prípad poruchy pri prenose. Kontroly funkcii: • Náhodné kontroly musia preukáza , že žiadne relevantné data sa nestratia po as poruchy pri prenose.


1) Na prerušenie merania, ktoré môže by zatavené ahko a rýchlo, napr. pri vážení ako meraní paliva, at ., môže by meranie dokon ené aj ke je prenos nedokon ený. Meradlo alebo zariadenie, ktoré prenášajú legálne relevantné data musia ma buffer (zásobník), ktorý je dostato ne ve ký na ukladanie aktuálnych transakcii. Po tomto, nemali by by naštartované žiadne nové transakcie a ochránené hodnoty by mali by držané pre neskorší prenos. Pre ostatné príklady pozri as I. 2) Merania, ktoré sú prerušite né, napr. meranie energie, objemu at . nepotrebujú špeciálny do asný zásobník, pretože tieto merania sú vždy kumulatívne. Kumulatívny zoznam môže by ítaný alebo prenášaný v neskoršom ase, ke je pripojenie znova k dispozícii.


Požadovaná dokumentácia (dodato ne okrem požiadaviek pre triedy rizík B, C a D): Zdrojový kód, ktorý realizuje prenos dát.


Kontrola založená na zdrojovom kóde: • Kontrolujeme, i opatrenia na reagovanie pri prerušení služieb prenosu sú vhodné.


WELMEC WG7

8



Rozšírenie S: Oddelenie softvéru

Oddelenie softvéru je dobrovo nou metodiku, ktorá dovo uje výrobcovi ahko modifikova softvér, ktorý nie je legálne relevantný z h adiska metrológie. Ak sa uskuto ní oddelenie softvéru, potom okrem základných požiadaviek pre typy P a U musí by stanovené aj toto rozšírenie.

8.1

Technický popis

Softvér kontrolujúci meradlá alebo systémy vo všeobecnosti je komplexne závislí a ovláda moduly, ktoré sú ako aj tie, ktoré nie sú legálne relevantnými modulmi. Toto je výhodné pre výrobcu a skúšajúceho – aj ke to nie je predpísané – oddelenie týchto softvérových modulov meracieho systému. V nasledovnej tabu ke sú popísané dva varianty oddelenia softvéru. Oba varianty sú pokryté súborom požiadaviek. Popis Oddelenie softvéru je realizované nezávisle od opera ného systému vo vnútri aplika nej domény, t.j. na úrovni programovacieho jazyka (nízka úrove oddelenia softvéru). Poznámka: Táto vlastnos univerzálnom po íta i.

je realizovaná aj pri jednoú elovom zariadení aj pri

Moduly softvéru, ktoré sa oddelia sú realizované ako nezávislé predmety kvôli opera nému systému (vysoká úrove oddelenia softvéru). Poznámka: Tento typ oddelenia je bežne prijate ným len na univerzálnom po íta i. Príklady riešení sú nezávislé na spustite ných programoch, dynamickom prepojení knižníc at . Tabu ka 8-1: Technický popis meradla typu U Ochrana proti nedovoleným zmenám nameraných hodnôt a parametrov je adresovaná len nepriamo, zatia o programátor softvérovej asti, ktorá nie je predmetom právnej kontroly nesmie poskytnú užívate ovi možnos poškodenia meracieho systému. Ale toto by malo by v každom prípade stanovené programátorom (s alebo bez oddelenia) a vhodné požiadavky sú stanovené v základných astiach P a U (kapitola 4 a 5) príru ky.


WELMEC WG7

8.2



Špecifické požiadavky na softvér na rozdelenie softvéru

Trieda rizika B Trieda rizika C S1: Realizácia rozdelenia softvéru

Trieda rizika D

Musí by as ou softvéru, ktorý obsahuje všetky legálne relevantné softvéry a parametre, ktoré sú jasne oddelené od iných astí softvéru.


1. V prípade nízkej úrovni oddelenia, všetky programové jednotky (podprogramy, procedúry, funkcie, triedy, at .) a v prípade vysokej úrovni oddelenia všetky programy a knižnice • ktoré prispievajú k výpo tu nameraných hodnôt alebo na ktoré majú dopad, • ktoré prispievajú k dopl ujúcim funkciám ako napr. zobrazenie dát, ochranu dát, ukladanie dát, identifikáciu softvéru, s ahovanie softvéru, prenos dát alebo ukladanie, overenie prijatých alebo uložených dát, at . patriacich k legálne relevantnému softvéru.1 2. Všetky premenné, do asné súbory a parametre, ktoré majú dopad na namerané hodnoty alebo na legálne relevantné funkcie alebo data 3. Komponenty z ochranného softvérového rozhrania (pozri S3) sú sú as ou legálne relevantného softvéru. 4. Legálne nerelevantný softvér obsahuje ostatné programové jednotky, data alebo parametre, ktoré nie sú zahrnuté do vyššie spomínaných bodov. Modifikácie tejto asti sú možné bez toho aby bola o tom informované NO, pokia sú splnené alšie požiadavky na softvérové oddelenia.

Požadovaná


dokumentácia

Popis všetkých komponentov opísaných v hore uvedených (dodato ne okrem dokumentácie špecifikovaných poznámkach patriacich k legálne vyžadovanej pre triedy rizík B a C): relevantnému softvéru. Správna implementácia rozdelenia softvéru bude zobrazená v dokumentácii. Validácia: Validácia (dodato ne okrem triedy rizík B a C): Kontrola založená na dokumentácii: • Kontrolujeme, i všetky legálne relevantné komponenty Kontrola založená na dokumentácii: spomenuté v špecifikovaných poznámkach 1 až 3 sú • Kontrolujeme, i realizácia rozdelenia softvéru je správna. zahrnuté do legálne relevantného softvéru.

Príklad prijate ného riešenia: Je popísaná v samotnej požiadavke.


Požadovaná dokumentácia (dodato ne okrem požiadaviek pre triedy rizík B a C): Zdrojový kód legálne relevantného softvéru.


Kontrola založená na zdrojovom kóde: • Kontrolujeme návrh softvéru, i tok dát týkajúci sa legálne relevantných dát sú definované jednozna ne v legálne relevantnom softvéri a i môžu by overené. • Kontrolujeme (napr. pomocou nástrojov alebo manuálne analýzu toku dát), i všetky programové jednotky, programy alebo knižnice, ktoré sú zapojené do procesu nameraných hodnôt sú zaznamenané legálne relevantným softvérom. • Vyh adávame neprijate ný tok dát z astí, ktoré nie sú predmetom právnej kontroly do domén, ktoré sú chránené.

1

Poznámka: Nízka úrove oddelenia: Zlu ovacie komponenty na úrovni programovacieho jazyka alebo zlu ovacie asti programu (t.j. podprogramy, procedúry, funkcie, triedy) tvoriace as legálne relevantného programu. Zvyšok programu nie je as ou, ktorá je legálne relevantnou. Vysoká úrove oddelenia: Zlú enie všetkých astí softvéru do jedného objektu, ktorý je identifikovate ný opera ným systémom (program, DLL at .). Zvyšok programu nie je as ou, ktorá je legálne relevantnou. 52


WELMEC WG7

Trieda rizika B S2: Zmiešané indikácie


Trieda rizika C


Trieda rizika D

Dodato né informácie vygenerované softvérom, ktorý nie je legálne relevantným, môžu by len zobrazené na displeji alebo vo výpise, len v tom prípade ke by sa nemohli zameni s informáciami, ktoré vznikli as ou, ktorá je legálne relevantnou.


Ke programátor legálne nerelevantného softvéru nesmie vedie prijate né indikácie, je na zodpovednosti výrobcu, aby garantoval, že všetky indikované informácie sp ajú požiadavku.


Popis softvéru, ktorý realizuje indikáciu. Popis ako sú chránené indikácie legálne relevantných informácii proti zavádzajúcim indikátorom vygenerovaných legálne nerelevantným softvérom.

Validácia:

Kontroly funkcií: • Hodnotíme vizuálnou kontrolou, i dodato né informácie vygenerované z legálne nerelevantného softvéru a informácie, ktoré sú prezentované na displeji alebo vo výpise by nemohli by zamenené s informáciami vytvorenými legálne relevantným softvérom.

Požadovaná

dokumentácia

(dodato ne okrem dokumentácie vyžadovanej pre triedy rizík B a C): Realizácia zmiešania indikácii musí by zobrazená v dokumentácii. Validácia (dodato ne okrem triedy rizík B a C): Kontrola založená na dokumentácii: • Kontrolujeme, i realizovaná implementácia zmiešania indikácii je správna.


•

Informácie zobrazené legálne nerelevantným softvérom sú prenášané cez ochranné rozhranie (pozri S3) do legálne relevantného softvéru. Za rozhraním prechádza filtrom, ktorý deteguje neprípustné informácie. Prijate né informácie sú potom vložené do indikácii kontrolovaných legálne relevantným softvérom. V okne obrazovky (univerzálny po íta ) legálne relevantný softvér v krátkosti kontroluje, i sú okná s legálne dôležitou informáciou vždy vidite né a i sú na vrchu zo všetkých okien. Ak sú skryté, minimalizované alebo sú na vonkajšej hranici, softvér vygeneruje upozornenie alebo zastaví výstupy a spracovávanie nameraných hodnôt. Ak je meranie ukon ené, môže by okno pre ú ely legálnej metrológie zatvorené.




Kontrola založená na zdrojovom kóde: • Kontrolujeme, i legálne relevantný softvér vygeneruje indikátory nameraných hodnôt. • Kontrolujeme, i tieto indikátory nemôžu by zmenené alebo potlá ané legálne nerelevantnými programami.


WELMEC WG7


Trieda rizika B Trieda rizika C S3: Ochrana softvérového rozhrania


Trieda rizika D

Výmena dát medzi legálne relevantným a legálne nerelevantným softvérom musí by vykonaná cez ochranné softvérové rozhranie, ktoré sa skladá zo vzájomného ovplyv ovania a toku dát.


1. Všetky vzájomné ovplyv ovania a toky dát nesmú ma neprípustný vplyv na legálne relevantný softvér, vrátane dynamického správania sa meracieho procesu. 2. Jednozna nou úlohou každého príkazu musí by posielanie cez softvérové rozhranie do spúš acej funkcie alebo dát zmenených v legálne relevantnom softvéri. 3. Kódy a data, ktoré nie sú deklarované a zdokumentované ako príkazy nesmú ma žiadny vplyv na legálne relevantný softvér. 4. Rozhranie musí by kompletne zdokumentované a žiadne iné nezdokumentované rozhranie alebo tok dát (na obídenie rozhrania) nesmie by realizovate né nijakým programátorom legálne relevantného softvéru ako ani programátorom legálne nerelevantného softvéru. Poznámka: Programátori sú zodpovedný za všimnutie si tohto obmedzenia. Technické prostriedky zabra ujúce obídenie softvérového rozhrania nie sú možné. Programátor ochranného rozhrania musí by s touto požiadavke oboznámený.

Požadovaná dokumentácia: •

• •

Popis softvérového rozhrania, špeciálne ktoré dátové domény realizujú rozhranie. Kompletný zoznam všetkých príkazov deklarujúcich kompletnos . Stru ný popis ich významu a vplyvu na funkcie a data meradla.

Požadovaná

dokumentácia

(dodato ne okrem dokumentácie vyžadovanej pre triedy rizík B a C): Realizácia softvérového rozhrania musí by zobrazená v dokumentácii.

Validácia:

Validácia (dodato ne okrem triedy rizík B a C): Kontrola založená na dokumentácii • Kontrolujeme, i funkcie legálne relevantného softvéru, Kontrola založená na dokumentácii: ktoré môže by spustené cez ochranné rozhranie, je • Kontrolujeme, i realizované softvérové zadefinované a popísané. rozhranie je správne. • Kontrolujeme, i parametre, ktoré môžu by menené cez rozhranie, sú zadefinované a popísané. • Kontrolujeme, i popis funkcií a parametrov je jasný a kompletný. Príklad prijate ného riešenia: • • •

Dátové domény astí legálne relevantného softvéru sú obsiahnuté len v deklarácii lokálnych premenných v asti legálne relevantnej. Rozhranie je realizované ako podprogram patriaci k legálne relevantnému softvéru, ktorý je pomenovaný z legálne nerelevantného softvéru. Data, ktoré sú prenesené do legálne relevantného softvéru sú prevzaté ako parametre podprogramu. Legálne relevantný softvér odfiltrováva rozhraniu neprípustné príkazy.




Kontrola založená na zdrojovom kóde: • Kontrolujeme návrh softvéru, i tok dát je jednozna ne definovaný v legálne relevantnom softvéri a môže by overený. • Kontrolujeme tok dát prostredníctvom softvérového rozhrania pomocou nástrojov alebo manuálne. Kontrolujeme, i všetky toky dát medzi as ami sú zdokumentované (žiadne obídenie deklarácie softvérového rozhrania). • Vyh adávame neprípustné toky dát z asti, ktorá nie je predmetom kontroly, do domén, ktoré sú chránené. • Kontrolujeme, i príkazy, ak sú nejaké, sú dekódované správne a neexistujú žiadne iné neopísané príkazy.


WELMEC WG7

9



Rozšírenie D. S ahovanie softvéru legálnej metrológie

Toto rozšírenie musí by použite né pre s ahovanie legálne relevantného softvéru, napr. bugfixes, aktualizácie, nových aplikácii, at . do meradla pre oba typy vhodných meradiel, typ P a U. Tieto požiadavky sú stanovené navyše k základným požiadavkám pre typ P a typ U, popísané v kapitole 4 a 5 tejto príru ky.

9.1

Technický popis

Softvér môže by s ahovaný len do meradiel, ktoré sú charakterizované nasledovnými vlastnos ami: Hardvérová konfigurácia Cie ové zariadenia sú predmetom právnej kontroly. Môžu by jednoú elovými meracími prístrojmi (typ P) alebo založené na báze univerzálneho po íta a (Typ U). Komunika né linky pre s ahovanie môžu by priame, napr. RS 232, USB, cez as zatvorenej sieti, alebo výlu ne v súlade s právnou kontrolou, napr. Ethernet, LAN, alebo cez otvorenú sie , napr. Internet. Softvérová konfigurácia Celý softvér cie ového zariadenia môže by právne kontrolovaný alebo môže ma softvérové rozdelenie. S ahovanie legálne relevantného softvéru musí spracova nižšie uvedené požiadavky. Ak nie je v meradli softvérové rozdelenie, potom všetky nižšie uvedené požiadavky sa aplikujú na s ahovanie. Tabu ka 9-1:

Technický popis meradla typu U.


WELMEC WG7

9.2



Špecifické požiadavky na softvér

Trieda rizika B Trieda rizika C D1: Mechanizmus s ahovania

Trieda rizika D

Mechanizmus s ahovania a následná inštalácia softvéru musí by automatická a musí by zabezpe ená tak, že ochrana softvérového prostredia je na úrovni schválenia pri jeho ukon ení.


1. S ahovanie musí by automaticky zabezpe ené tak, že nie sú dohodnuté existujúce úrovne ochrany. 2. Cie ové zariadenie má pevne stanovený legálne relevantný softvér, ktorý obsahuje všetky kontroly funkcii, ktoré sú nevyhnutné na splnenie požiadaviek D2 až D5. 3. Meradlo by malo by schopné detekcie, ak zlyhá s ahovanie alebo inštalácia. Musí by vydané upozornenie. Ak je s ahovanie alebo inštalácia prerušená, pôvodný stav meradla nesmie by ovplyvnený. Eventuálne, meradlo musí zobrazi trvalé chybové hlásenie a jeho metrologická funk nos musí by spomalená až dovtedy, kým nie sú opravené chyby. 4. Po úspešnom dokon ení inštalácie musia by všetky ochranné prostriedky uvedené do pôvodného stavu, pokia má NO oprávnenie stiahnutý softvér pozmeni v TEC. 5. Po as s ahovania a následnej inštalácie stiahnutého softvéru, musí by meranie meradlom spomalené alebo musí by garantovaná správnos merania. 6. Požiadavky na odstránenie poruchy opísané v rozšírení I môžu by zrealizované, len ak tieto poruchy nastanú po as s ahovania. Po et re-inštala ných pokusov musí by limitovaný. 7. Ak požiadavky D2 až D5 nemôžu by splnené, ešte stále je možné stiahnu as softvéru, ktorá nie je legálne relevantná. V takomto prípade musia by splnené nasledovné požiadavky: • Jednozna né rozdelenie medzi legálne relevantným a legálne nerelevantným softvérom pod a rozšírenia S. • Celá as legálne relevantného softvéra je zafixovaná, t.j. nemôže by s ahovaná alebo zmenená bez porušenia plomby.. • Ak je v TEC stanovené s ahovanie legálne nerelevantnej asti, je to akceptovate né.

Požadovaná


dokumentácia

Dokument musí stru ne popisova automatickú povahu (dodato ne okrem dokumentácie s ahovania, kontroly, inštalácie, ako aj úrove ochrany vyžadovanej pre triedy rizík B a C): zaru ujúca dokon enie, ak by nastalo poškodenie. Realizácia mechanizmu s ahovania musí by zobrazená v dokumentácii. Validácia: Validácia (dodato ne okrem triedy rizík B a C): Kontrola založená na dokumentácii: • Kontrolujeme dokumentáciu, ako je zorganizovaný Kontrola založená na dokumentácii: proces s ahovania. • Kontrolujeme, i realizovaný • Kontrolujeme, i s ahovanie a inštalácia sú ovládané mechanizmus s ahovania je správny. automaticky, i meradlo je zamknuté (ak je to vhodné) a i je ochrana softvéru po stiahnutí nekompromisná.. • Kontrolujeme, i existuje nestiahnute ný fixný legálne relevantný softvér pre kontrolu integrity a autentickosti. • Kontrolujeme, i po as s ahovania softvéru nie je možné mera alebo i je garantovaná správnos merania. Kontroly funkcii: • Vykonáme prinajmenšom jedno softvérové s ahovanie kontrolujúce správnos softvérového s ahovania.


Obslužný program stály v pevnej asti softvéru, ktorý: a. Nadväzuje spojenie s vysiela om a kontroluje ho jeho súhlas b. Automaticky zabra uje meraniu pokia nie je garantovaná správnos metania c. Automaticky stiahne legálne relevantný softvér do zabezpe eného priestoru d. Automaticky zrealizuje kontrolu požiadaviek D2 až D4 e. Automaticky nainštaluje softvér na správne pamä ové miesto f. Stará sa o organizovanie, napr. vymazáva prebyto né súbory, at . g. zais uje, že ochrana po s ahovaní alebo inštalácii je automaticky po dokon ení nastavená do pôvodného stavu h. Inicializuje vhodné procedúry na odstránenie porúch, ak nejaké chyby nastali


WELMEC WG7




Požadovaná dokumentácia (dodato ne okrem požiadaviek pre triedy rizík B a C):

Zdrojový kód z fixnej asti softvéru, ktorý zodpovedá za manažovanie procesu s ahovania.


Kontrola založená na zdrojovom kóde: • Kontrolujeme, i opatrenia na riadenie procesu s ahovania sú vhodné.


WELMEC WG7


Trieda rizika B Trieda rizika C D2: Autentickos s ahovaného softvéru


Trieda rizika D

Prostriedky musia zaru i , že s ahovaný softvér je autentický a musí by ozna ený, že bol schválený NO.


1. Predtým než je stiahnutý softvér prvý krát použitý musí meradlo automaticky skontrolova , i: a. softvér je autentický (nejde o simuláciu založenú na podvode) b. softvér je schválený pre daný typ meradla. 2. Softvér, prostredníctvom ktorého sa identifikuje schválený stav NO musí zabezpe i zabráneniu sfalšovaniu stavu NO. 3. Ak s ahovaný softvér nevyhovie vyššie uvedeným skúškam, postupujeme pod a D1.


Dokumentácia opisuje: • Ako je zaru ená autentickos softvérového ozna enia. • Ako je zaru ená autentickos schválenia NO. • Ako je zaru ené, že s ahovaný softvér je schválený pre daný typ meradla, do ktorého bol stiahnutý.

Požadovaná

dokumentácia

(dodato ne okrem dokumentácie vyžadovanej pre triedy rizík B a C): Realizácia autentickosti musí by zobrazená v dokumentácii.

Validácia:

Validácia (dodato ne okrem triedy rizík B a C): Kontrola založená na dokumentácii: • Kontrolujeme dokumentáciu, ako je zabránené Kontrola založená na dokumentácii: s ahovanie falošného softvéru. • Kontrolujeme, i zadané opatrenia sú vhodné vzh adom na požadovaný stav • Kontrolujeme, cez skúšky funk nosti, i je zabránené pre vysokú úrove ochrany. s ahovaniu falošného softvéru. Zabezpe íme autentickú kontrolu softvéru pod a dokumentácie a prostredníctvom skúšok funk nosti. Príklad prijate ného riešenia:

1. Autentickos Z dôvodu zaistenia integrity (pozri D3) je vygenerovaný elektronický podpis prostredníctvom s ahovanej asti softvéru. Autentickos je zaru ená, ak k ú uložený v pevnej softvérovej asti meradla potvrdí, že podpis pochádza od výrobcu. Porovnanie k ú ov musí by vykonané automaticky. 2. NO. Pred prvotným overením je k ú uložený v pevnej softvérovej asti. 3. Správny typ meradla Kontrola typu meradla vyžaduje automatické porovnanie identifikácie typu meradla, ktorý je uložený v pevnej softvérovej asti meradla s kompatibilným zoznamom pripojeným k softvéru. 4. Schválenie NO 4. Schválenie NO Ak je zaru ená autentickos prostredníctvom Kontrolujeme, i bol softvér naozaj výrobcovho k ú a, potom môže by predpokladané schválený, jedným z riešení je, že schválenie NO. všetky s ahované schválené softvéri obsahujú podpis zodpovednej osoby. Verejný k ú zodpovednej osoby je uložený v meradle a je použitý na automatickú kontrolu podpisu pripojeného k softvéru. Táto kontrola môže by vizuálna v meradle pre porovnanie s verejným k ú om zodpovednou osobou.


Zdrojový kód z fixnej asti softvéru zodpovedný za kontrolu autentickosti s ahovaného softvéru. Validácia (dodato ne okrem triedy rizík B a C): Kontrola založená na zdrojovom kóde: • Kontrolujeme, i opatrenia na kontrolu autentickosti sú vhodné.


WELMEC WG7



Trieda rizika B Trieda rizika C D3: Integrita s ahovaného softvéru

Trieda rizika D

Prostriedky musia zaru i , že s ahovaný softvér nebol nedovolene menený po as s ahovania.


1. Predtým než je stiahnutý softvér prvý krát použitý musí meradlo automaticky skontrolova , s ahovaný softvér nebol nedovolene menený. 2. Ak s ahovaný softvér nevyhovie vyššie uvedeným skúškam, postupujeme pod a D1.


Požadovaná



i

dokumentácia

Dokumentácia musí popisova ako je garantovaná integrita (dodato ne okrem dokumentácie softvéru. vyžadovanej pre triedy rizík B a C): Opatrenia na zistenie integrity musia by zobrazené v dokumentácii. Validácia: Validácia (dodato ne okrem triedy rizík • Zabezpe íme kontrolu integrity softvéru po s ahovaní B a C): pod a dokumentácie a prostredníctvom skúšok Kontrola založená na dokumentácii: • Kontrolujeme, i zadané opatrenia sú funk nosti. vhodné vzh adom na požadovaný stav pre vysokú úrove ochrany. •

•

Integrita môže by preukázaná vykonaním kontrolného • sú tu cez legálne relevantný softvér a porovnaním ho proti kontrolnému sú tu pripojeného softvéru (pozri tiež U2, príklad prijate ného riešenia) Prijate ný algoritmus: CRC, tajný po iato ný vektor, d žka 32 bitov. Po iato ný vektor je uložený v pevnej • softvérovej asti.

Vytvorenie hash hodnoty softvéru k s ahovaniu (algoritmus, napr. SHA-1, RipeMD-160) a zakódovaním ho (RSA, Eliptickými kruhmi) s vhodnou d žkou k ú a. K ú k dešifrovaniu je uložený v pevnej softvérovej asti.


Zdrojový kód z fixnej asti softvéru zodpovedný za kontrolu integrity s ahovaného softvéru. Validácia (dodato ne okrem triedy rizík B a C): Kontrola založená na zdrojovom kóde: • Kontrolujeme, i opatrenia na kontrolu integrity sú vhodné.


WELMEC WG7



Trieda rizika B Trieda rizika C Trieda rizika D D4: Jednozna nos legálne relevantného s ahovaného softvéru

Musí by zaru ené vhodnými technickými prostriedkami, že s ahovanie legálne relevantného softvéru je adekvátne zjavné v rámci meradla pre následné kontroly.


1. Tieto požiadavky umož ujú inšpekciu orgánov, ktoré sú zodpovedné za metrologický dozor ur ených meradiel, vystopova s ahovania z legálne relevantného softvéru po as primeraného asového úseku (ktorý závisí od národných predpisov). 2. Jednozna nos prostriedkov a záznamov je sú as ou legálne relevantného softvéru a musia by ako také chránené.


Dokumentácia musí • stru ne popisova ako je implementovaná a chránená jednozna nos prostriedkov • stanovi ako môže by vystopovate ný s ahovaný softvér.

Požadovaná

dokumentácia

(dodato ne okrem dokumentácie vyžadovanej pre triedy rizík B a C): Opatrenia na zistenie jednozna nosti musia by zobrazené v dokumentácii.

Validácia:

Validácia (dodato ne okrem triedy rizík B a C): Kontrola založená na dokumentácii: • Kontrolujeme, i jednozna né prostriedky sú Kontrola založená na dokumentácii: • Kontrolujeme, i zadané opatrenia sú implementované a chránené. vhodné vzh adom na požadovaný stav Kontrola funkcii: pre vysokú úrove ochrany. • Kontrolujeme funk nos prostriedkov prostredníctvom náhlych kontrol. Príklad prijate ného riešenia: •

•

Kontrolný záznam. Meradlo môže by vybavené zapisova om udalostí, ktoré automaticky zaznamená prinajmenšom dátum a as s ahovania, identifikáciu s ahovaného legálne relevantného softvéru, identifikáciu s ahovanej strany a záznam úspešnosti. Záznam je vygenerovaný pre každé s ahovanie bez oh adu na jeho úspešnos . Po dosiahnutí hranice zapisova a udalostí musí by zaistené pomocou technických prostriedkov, že nebude umožnené alšie s ahovanie. Kontrolný záznam môže by vymazaný, len ke sa pretrhne fyzická alebo elektronická plomba a môže by znovu zaplombovaná len kontrolným orgánom


Požadovaná dokumentácia (dodato ne okrem požiadaviek pre triedy rizík B a C):

Zdrojový kód z fixnej asti softvéru zodpovedný za sledovanie procesu s ahovania a za manažovanie kontrolného záznamu. Validácia (dodato ne okrem triedy rizík B a C): Kontrola založená na zdrojovom kóde: • Kontrolujeme, i opatrenia na sledovanie procesu s ahovaniu sú vhodné. • Kontrolujeme, i opatrenia na ochranu kontrolného záznamu sú vhodné.

Povolenie s ahovania Predpokladá sa, že výrobca meradla informuje používate a o aktualizácii softvéru, špeciálne legálne relevantnej asti, a že používate neodmieta jeho aktualizáciu. Navyše sa ešte predpokladá, že výrobca a používate alebo vlastník meradla súhlasia s vhodnými postupmi vykonávajúcimi s ahovanie, ktoré je závislé na použití a umiestnení meradla.


WELMEC WG7

10



Rozšírenie I: Špecifické požiadavky na softvér pre konkrétne meradlo

Toto rozšírenie je ur ené k doplneniu všeobecných softvérových požiadaviek predchádzajúcich kapitol a nemôžu by považované za oddelite né od astí P alebo U a alších rozšírení (pozri kapitolu 3). Toto odzrkad uje existenciu špecifických meradiel príloh MI-x smernice MID, a obsahuje špecifické aspekty a požiadavky na meradlá alebo systémy (alebo iastkové zostavy). Tieto požiadavky nie sú posta ujúce, alebo nepresahujú požiadavky smernice MID. Pokia sa odkazujú na odporú ania OIML alebo normy ISO/IEC, je to v tom prípade, len ak môžeme tieto považova za normatívne dokumenty v zmysle smernice MID a ak sú podporované harmonizovanou interpretáciou požiadaviek smernice MID. Okrem špecifických softvérových aspektov meradla a požiadaviek rozšírenia I obsahuje meradlo (alebo skupina meradiel) špecifické ur enie triedy rizika, ktoré zabezpe ujú harmonizovanú úrove softvérového skúšania, ochrany softvéra a zhody so softvérom. Na predstavenie, rozšírenie I má by úvodným návrhom k ukon eniu príslušnej pracovnej skupiny WELMEC, ktorá má príslušné špecifické poznatky. Z tohto dôvodu rozšírenie I má „otvorenú štruktúru“, t.j. poskytuje kostru, ktorá je – okrem úvodného pridelenia triedy rizika – vyplnená len iasto ne (napr. pre distribu né meradlá a pre váhy s automatickou innos ou). Toto môže by použité aj pre ostatné meradlá MID (alebo aj na meradlách, ktoré nie sú pokryté smernicou MID) pod a získaných skúseností a rozhodnutí zodpovednej pracovnej skupiny WELMEC. íslovanie x v podkapitolách 10.x nasleduje íslovanie špecifických príloh MI-x smernice MID. Meradlá, ktoré nespadajú pod smernicu MID môžu by íslované od 10.11. Odlišné špecifické softvérové aspekty meradla, ktoré by mohli by potrebné na stanovenie ur itého typu x meradla. Tieto aspekty by mali by spracované nasledovne do systematickej metódy: Každá podkapitola 10.x by mala by rozdelená do sekcií 10.x.y, kde y pokrýva nasledovné aspekty. 10.x.1 Špeciálne nariadenia, normy a iné normatívne dokumenty Tu by mali by spomenuté špecifické nariadenia, normy a iné normatívne dokumenty (napr. odporú ania OIML) alebo príru ky WELMEC, ktoré môžu by užito nými z poh adu vývoja meradla (alebo skupiny) špecifických softvérových požiadaviek ako interpretácia požiadaviek smernice MID v prílohe I a špecifické prílohy MI-x. Bežne sa špecifické softvérové požiadavky aplikujú aj na všeobecné uvedené v predchádzajúcej kapitole. Inak by to malo by jasne stanovené, i špecifická softvérová požiadavka nahrádza v jednom prípade (alebo vo viacerých) všeobecné softvérové požiadavky, alebo i jedna (alebo viac) všeobecných požiadaviek je (sú) neaplikovate né a uvies dôvod pre o.


WELMEC WG7



10.x.2 Technický popis Tu by mali by -

príklady naj astejších špecifických technických konfigurácii,

-

použitie astí P, U a rozšírení do týchto príkladov, a

-

užito né (špecifické meradlo) kontrolné listy pre oboch, pre výrobcu a pre skúšajúceho

Popis by mal poukazova na -

meracie princípy (súhrnné meranie alebo jednoduché nezávislé meranie; opakovate né alebo neopakovate né meranie; Štatistické alebo dynamické meranie, a

-

zistenie poruchy a reakcie; sú možné dva prípady; a) výskyt chyby je o ividný alebo môže by jednoducho skontrolovaný alebo sú tam hardvérové prostriedky pre detekciu porúch, b) výskyt chyby nie je o ividný a nemôže by hardvérové prostriedky na odhalenie poruchy.

ahko kontrolovaný a nie sú žiadne

V poslednom prípade (b) na zistenie poruchy a reakcia sa vyžadujú vhodné softvérové prostriedky a z toho dôvodu aj vhodné softvérové požiadavky. -

hardvérová konfigurácia; prinajmenšom by mali by adresované nasledovné otázky: a) Ide o modulárny, všeobecne použite ný po íta založený na základe systému alebo o jednoú elové priradené meradle so zabudovaným systémom podliehajúcom právnej kontrole? b) Je po íta ový systém nezávislý alebo je as zatvorenej siete, napr. Etherner, kruhový LAN, alebo as otvorenej siete, napr. Internet? c) Je senzor oddelený (oddelený krytom alebo oddelený elektrickým napájaním) od systému typu U alebo je sú as ou alebo celkom za lenený? d) Je užívate ské rozhranie vždy pod právnou kontrolou (pre meradlá typu P a typu U) alebo môže by prepojené do opera ného režimu, ktorý nie je pod právnou kontrolou? e) Predpokladá sa dlhodobé ukladanie dát? Ak áno, potom je ukladanie miestne (napr. na pevnom disku) alebo prenosnú (napr. serverový súbor)? f)

-

Je pamä ové médium fixné (napr. zabudovaný ROM) alebo vymenite né (napr. floppy disk, CD-RW, karta smart-media, memory stick)?

softvérová konfigurácia a prostredie; prinajmenšom by mali by adresované nasledovné otázky: a) Ktorý opera ný systém je použitý alebo môže by použitý? b) Sú aj iné softvérové aplikácie na systéme okrem legálne relevantného softvéru? c) Je tam softvér, ktorý nepodlieha právnej kontrole, ktorý má by vo ne modifikovaný po schválení?

10.x.3 Špecifické softvérové požiadavky Tu by mal by zoznam špecifických softvérových požiadaviek a komentár použitia v podobnej formy ako v predchádzajúcej kapitole. 62 Realizované s finan nou podporou Európskej únie v rámci programu Prechodný fond

WELMEC WG7



10.x.4 Príklady legálne relevantných funkcií a dát Tu by mali by dané napríklad -

špecifické parametre zariadenia (napr. individuálna konfigurácia a kalibra né parametre špecifických meradiel),

-

typovo-špecifické parametre (napr. špecifické parametre, ktoré sú pevne stanovené v type danej skúšky) alebo

-

legálne relevantné, špecifické funkcie.

10.x.5 Ostatné aspekty Tu by mali by spomenuté iné aspekty, napr. špecifická dokumentácia požadovaná pre daný typ (softvérového) skúšania, špecifický popis a inštrukcie dodané v certifikáte skúšky typu, alebo iné aspekty (napr. požiadavky týkajúce sa skúšania). 10.x.6 Priradenie triedy rizika Tu by mali by zadefinované vhodné triedy rizika pre meradlá daného typu x. Môže to by spracované -

bu všeobecne (pre všetky skupiny v rámci príslušného typu) alebo

-

v závislosti na oblasti použitia alebo skupiny, alebo iných aspektov, ak tieto existujú.


WELMEC WG7



10.1 Vodomery 10.1.1 Špeciálne nariadenia, normy a iné normatívne dokumenty lenský štát môže – v súlade s lánkom 2 smernice MID – zaradi vodomery používané v domácnosti, na komer né ú ely a v ahkom priemysle medzi meradlá podliehajúce smernici MID. Špecifické požiadavky tejto kapitoly vychádzajú len z prílohy MI-001. Odporú ania OIML a normy nie sú brané do úvahy. 10.1.2 Technický popis 10.1.2.1 Hardvérová konfigurácia Vodomery sú typickým príkladom jednoú elových zariadení (v tomto dokumente ako typ P). 10.1.2.2 Softvérová konfigurácia Pre každého výrobcu je softvérová konfigurácia špecifická, ale bežne sa predpokladajú tieto nasledovné odporú ania stanovené v hlavnej asti tejto príru ky. 10.1.2.3 Princíp merania Vodomery priebežne na ítavajú prete ený objem vody. Celkový objem je zobrazený na meradle. Pre jeho meranie využívajú rôzne princípy. Meranie sa nesmie opakova . 10.1.2.4 Zistenie poruchy a reakcia Požiadavky MI-001, 7.1.2 sa zaoberajú elektromagnetickým rušením. Je potrebné interpretova tieto požiadavky na softvér kontrolujúci meradlá, pretože detekcia poruchy a obnova je možná len v spolupráci so špecifickými as ami hardvéru a špecifickým softvérom. Z poh adu softvéru nie je rozhodujúce o aké rušenie išlo (elektromagnetické, elektrické, mechanické, at .): procesy obnovy sú pre všetky typy rušenia rovnaké. 10.1.3 Špecifické softvérové požiadavky


WELMEC WG7

Trieda rizika B


Trieda rizika C


Trieda rizika D

I1-1: Obnova po chybe

Softvér sa musí dokáza obnovi z rušenia a vráti sa do bežného procesu.

Špecifikované poznámky: Pe iatka s dátumom by malo by zvidite nené pomocným záznamom obdobie od kedy sú operácie chybné.

Požadovaná dokumentácia: Stru ný popis mechanizmu na obnovu po chybe a popis kedy ho vyvoláva.

Validácia Kontrola založená na dokumentácii: •

Kontrolujeme, i je zrealizovaná obnova po chybe primeraná.

Kontroly funkcii: •

Nie sú potrebné žiadne alšie skúšky na ukon enie priebehu skúšky typu, ktoré by potvrdili správne fungovanie prítomných zadefinovaných veli ín rušenia.

Príklad prijate ného riešenia: Hardvérový dohliadací obvod je zresetovaný cyklicky spracovaným mikroprocesorovým podprogramom za ú elom zabránenia spustenia dohliadacieho obvodu. Ak neboli niektoré z funkcií spracované, alebo – v najhoršom prípade – mikroprocesor zostal visie v nekone nej slu ke, nenastane zresetovanie dohliadacieho obvodu a ten sa spustí až po ur itom asovom rozpätí.

Trieda rizika B

Trieda rizika C

Trieda rizika D

I1-2: Prostriedky na zálohovanie

V prípade poruchy tu musí by zariadenie, ktoré zabezpe uje periodické zálohovanie legálne relevantných dát, ako napr. namerané hodnoty a stav merania. Tieto data musia by ukladané do stálej pamäte.

Špecifikované poznámky: Interval ukladania musí by dostato ne malý, aby odchýlka medzi sú asnými a uloženými celkovými hodnotami bola malá.

Požadovaná dokumentácia: Stru ný popis dát, ktoré sa zálohujú a kedy sa majú zálohova . Výpo et maximálnej chyby pre súhrnné hodnoty, ktorá môže nasta .


Kontrolujeme, i sú všetky legálne relevantné data uložené do stálej pamäte a ich môžeme nájs .



Príklad prijate ného riešenia: Legálne relevantné data sú zálohované tak, ako je požadované (napr. každých 60 minút).


WELMEC WG7

Trieda rizika B


Trieda rizika C


Trieda rizika D

I1-3: MID- Príloha I, 8.5 (zabráni zresetovaniu súhrnných nameraných hodnôt)

Pre distribu né meradlá, ktoré zobrazujú celkové množstvo alebo zobrazujú celkové množstvo, z ktorého môžu by odvodené, celkové alebo iasto né odkazy, na základe ktorých sa ú tuje, nesmie by umožnené zresetovanie po as používania.

Špecifikované poznámky: Hromadný zoznam meradiel môže by zresetovaný pred ich uvedením do používania.

Požadovaná dokumentácia: Zdokumentovanie ochranných prostriedkov pred zresetovaním rozsahu zoznamu.


Kontrolujeme, i celkové legálne relevantné namerané hodnoty nemôžu by možnosti spätného zistenia.

zresetované bez



Príklad prijate ného riešenia: Zoznamy rozsahu sú chránené proti zmenám a zresetovaniu prostredníctvom tých istých prostriedkov ako parametrov. (pozri P7).


WELMEC WG7

Trieda rizika B


Trieda rizika C


Trieda rizika D

I1-4: Dynamické chovanie

Softvér, ktorý nie je predmetom legálnej metrológie, nesmie nepriaznivo ovplyvni dynamické chovanie meracieho procesu..

Špecifikované poznámky: • Táto požiadavka aplikuje navyše aj S-1, S-2 a S-3 v tom prípade, ak bolo softvérové rozdelenie zrealizované v súlade s rozšírením S. • Dodato né požiadavky zaistia, že po as reálneho asu, kedy sa na meradle aplikuje dynamické chovanie legálne relevantného softvéru nie je nedovolene ovplyvnené softvérom, ktorý nie je predmetom legálnej metrológie, t.j. prostriedky legálne relevantného softvéru nie sú nedovolene zredukované as ou, ktorá nie je predmetom legálnej metrológie.

Požadovaná dokumentácia: • Popis hierarchie prerušenia. •

asová schéma softvérových úloh. Limity s primeranej doby asu pre úlohy legálne nerelevantného softvéru.


Zdokumentované limity primeranej doby asu pre úlohy legálne nerelevantné sú k dispozícii programátorovi asti softvéru, ktorý nie je predmetom legálnej metrológie.



Príklad prijate ného riešenia: Hierarchia prerušenia je navrhnutý takým spôsobom, ktorý zabra uje nepriaznivým vplyvom.


WELMEC WG7



10.1.4 Príklady legálne relevantných funkcií a dát Vodomery využívajú parametre, ako napr. konštanty pre výpo et, pre konfiguráciu at ., ale ja na nastavenie funk nosti zariadenia. Pokia ide o identifikáciu a ochranu parametrov a súboru parametrov, na tieto sa vz ahujú požiadavky P2 a P7 z príru ky P. V nasledovnej tabu ke sú uvedené typické parametre vodomerov. (Táto tabu ka bude zaktualizovaná po kone nom rozhodnutí pracovnej skupiny 11 WELMECu.) Parameter

Chránený

Faktor kalibrácie

x

Faktor linearity

x

Nastavite ný

Poznámka

10.1.5 Ostatné aspekty Pre použitie v domácnosti je predpokladom, že s ahovanie softvéru (rozšírenie D, kapitola 9) nebude ve mi dôležitým. Kumulovaná energia alebo rozsah registra meradiel v domácnosti nie je dlhodobo uchovávaný v zmysle rozšírenia L (kapitola 6). Pre meradlo, ktoré len kumuluje energiu/rozsah nie je nevyhnutné rozšírenie L. 10.1.6 Priradenie triedy rizika Pod a rozhodnutia zodpovednej pracovnej skupiny 11 WELMECu (na druhom stretnutí, 3.-4. marca 2005) sa stanovila nasledovná trieda rizika za prijate nú a mala by by aplikovaná, vtedy ak sú softvérové skúšky vykonané na základe tejto príru ky pre (softvérovo –kontrolované) vodomery: - Trieda rizika C pre meradlo typu P Rozhodnutie nie je ešte definitívne a WG 11 bude uvažova nad touto položkou v súvislosti s diskusiou o primeranej triede rizika (rizík) pre meradlo typu U.


WELMEC WG7



10.2 Plynomery a prepo ítava e objemu 10.2.1 Špeciálne nariadenia, normy a iné normatívne dokumenty lenský štát môže – v súlade s lánkom 2 smernice MID – zaradi plynomery a prepo ítava e objemu používané v domácnosti, na komer né ú ely a v ahkom priemysle medzi meradlá podliehajúce smernici MID. Špecifické požiadavky tejto kapitoly vychádzajú len z prílohy MI-002. Odporú ania OIML a normy nie sú brané do úvahy. 10.2.2 Technický popis 10.2.2.1 Hardvérová konfigurácia Plynomery a prepo ítava e objemu sú typickým príkladom jednoú elových zariadení (v tomto dokumente ako typ P). Môžu ma jeden alebo viac vstupov pre externú jednotku sníma a a meradlo a prepo ítava môžu ma odlišnú hardvérovú jednotku. 10.2.2.2 Softvérová konfigurácia Pre každého výrobcu je softvérová konfigurácia špecifická, ale bežne sa predpokladajú tieto nasledovné odporú ania stanovené v hlavnej asti tejto príru ky. 10.2.2.3 Princíp merania Plynomery priebežne na ítavajú prete ený objem. Celkový objem je zobrazený na meradle. Pre jeho meranie využívajú rôzne princípy. Prepo ítava objemu je používaný na výpo et objemu v základných podmienkach. Prepo ítava môže by neoddelite nou sú as ou meradla. Meranie objemu sa nesmie opakova . 10.2.2.4 Zistenie poruchy a reakcia Požiadavky MI-002, 7.1.2 sa zaoberajú elektromagnetickým rušením. Je potrebné interpretova tieto požiadavky na softvér kontrolujúci meradlá, pretože detekcia poruchy a obnova je možná len v spolupráci so špecifickými as ami hardvéru a špecifickým softvérom. Z poh adu softvéru nie je rozhodujúce o aké rušenie išlo (elektromagnetické, elektrické, mechanické, at .): procesy obnovy sú pre všetky typy rušenia rovnaké.


WELMEC WG7



10.2.3 Špecifické softvérové požiadavky Trieda rizika B

Trieda rizika C

Trieda rizika D





Validácia Kontrola založená na dokumentácii: • Kontrolujeme, i je zrealizovaná obnova po chybe primeraná. Kontroly funkcii: • Nie sú potrebné žiadne alšie skúšky na ukon enie priebehu skúšky typu, ktoré by potvrdili správne fungovanie prítomných zadefinovaných veli ín rušenia.



WELMEC WG7

Trieda rizika B


Trieda rizika C


Trieda rizika D


V prípade poruchy tu musí zariadenie, ktoré zabezpe uje periodické zálohovanie legálne relevantných dát, ako napr. namerané hodnoty a stav merania. Tieto data musia by ukladané do stálej pamäte.



Validácia Kontrola založená na dokumentácii: • Kontrolujeme, i sú všetky legálne relevantné data uložené do stálej pamäte a ich môžeme nájs . Kontroly funkcii: • Nie sú potrebné žiadne alšie skúšky na ukon enie priebehu skúšky typu, ktoré by potvrdili správne fungovanie prítomných zadefinovaných veli ín rušenia.


Trieda rizika B

Trieda rizika C

Trieda rizika D

I2-3: MID-002, 5.2 (primeraná indikácia)

Displej na zobrazenie celkového nekorigovaného objemu musí ma dostato ný po et ísiel zais ujúcich, aby zodpovedalo aspo na 8000 hodín prevádzky pri Qmax.

Špecifikované poznámky: Požadovaná dokumentácia: Dokumentácia vnútornej reprezentácie registra objemu.

Validácia Kontrola založená na dokumentácii: • Kontrolujeme, i je dostato ná kapacity pamäte.

Príklad prijate ného riešenia: Typickými hodnotami pre domáce plynomery sú Qmax = 6 m3/h. Požadovaný rozsah je 48000 m3. (aktuálne elektronické plynomery zobrazujú až do 99999 m3).


WELMEC WG7

Trieda rizika B


Trieda rizika C


Trieda rizika D





Validácia Kontrola založená na dokumentácii: • Kontrolujeme, i celkové legálne relevantné namerané hodnoty nemôžu by možnosti spätného zistenia.

zresetované bez

Kontroly funkcii: • Nie sú potrebné žiadne alšie skúšky na ukon enie priebehu skúšky typu, ktoré by potvrdili správne fungovanie prítomných zadefinovaných veli ín rušenia.



WELMEC WG7

Trieda rizika B


Trieda rizika C


Trieda rizika D

I2-5: MID- 002, 5.2 (životnos zdroja energie)

Ur ený zdroj energie musí ma životnos najmenej pä rokov. Po 90 % jeho životnosti musí by zobrazené primerané upozornenie..

Špecifikované poznámky: Životnos je tu použitá v zmysle kapacity dostupnej energie. Ak sa môže zdroj energie vymeni v priestore, nesmú sa po as výmeny poškodi parametre a legálne relevantné data.

Požadovaná dokumentácia: Dokumentácia kapacity zdroja energie, maximálnej životnosti ( nezávisle na spotrebe energie) merania stanovujúce spotrebu alebo využite nú energiu, popis prostriedkov na upozornenie nízkej využite nej energie.

Validácia Kontrola založená na dokumentácii: • Kontrolujeme, i sú vhodné opatrenia na dozor nad využite nou energiou.

Príklad prijate ného riešenia: Prevádzkový pracovný as alebo udalosti preberajúce zariadenia sa po ítajú, sú uložené v stálej pamäti a sú porovnané s nominálnou hodnotou životnosti batérie. Ak uplynie 90 % životnosti, zobrazí sa primerané upozornenie. Softvér deteguje výmenu zdroja energie a zresetuje íta . Iným riešením bude zdravotnícke monitorovanie, ktoré musí by napájané plynule.


WELMEC WG7


Trieda rizika B Trieda rizika C I2-6: MID- 002, 9.1 (Elektronické prepo ítava e)


Trieda rizika D

Elektronické prepo ítava e musia by schopné detekcie, ke pôsobia mimo prevádzkového rozsahu stanoveného výrobcom, v prípade parametrov, ktoré sú podstatné pre správnos merania. V takomto prípade musí prepo ítava zatavi integrované konvertované množstvo a môže úplne oddeli konvertované množstvo pre as, kedy pôsobí mimo prevádzkového rozsahu.

Špecifikované poznámky: Poruchový stav musí by zobrazený na displeji.

Požadovaná dokumentácia: Dokumentácia rôznych registrov pre konvertované množstvo a poruchové množstvo.

Validácia Kontrola založená na dokumentácii: • Kontrolujeme, i sú vhodné opatrenia na manažovanie nezvy ajných prevádzkových podmienok.

Príklad prijate ného riešenia: Softvér monitoruje podstatné vstupné hodnoty a porovnáva ich s predefinovanými limitmi. Ak sú všetky hodnoty v rámci limity, konvertované množstvo je integrované do nominálneho registra (ur ená premenná). V inom prípade je celkové množstvo v alšej premennej. Iným riešením musí by len jeden kumulovaný register alebo záznam po iatku a konca dátumu, asu a doby registra hodnôt mimo rozsahu v zapisova i udalostí (pozri P7). Obe množstvá môžu by indikované. Používate môže jasne indikova a rozlíši pravidelné a zlyhané indikácia prostredníctvom indikácie stavu.

Trieda rizika B

Trieda rizika C

Trieda rizika D

I2-7: MI-002, 5.5 ( iastkové skúšanie) Plynomer musí ma

iastkové skúšanie, ktoré musí umož ova vykonanie skúšky v primeranom ase..

Špecifikované poznámky: iastkové skúšanie pre zrýchlenie a v bežnej prevádzke.

asu skúšky je bežne používané na skúšanie pred montážou

Po as režimu skúšania musia by použité tie isté zoznamy a asti softvéru ako po as štandardného opera ného režimu.

Požadovaná dokumentácia: Zdokumentovanie iastkového skúšania a inštrukcie na aktiváciu režimu skúšania.

Validácia Kontrola založená na dokumentácii: • Kontrolujeme, i všetky ubehnuté asi postupu skúšky plynomera môžu by prostredníctvom iastkového skúšania

skompletizované

Príklad prijate ného riešenia: as založený na základe vnútorných hodín môže by zrýchlený. Procesy, ktoré prebehli napr. týžde , mesiac alebo dokonca rok a presiahli zoznamy sa môžu skúša v skúšobnom režime v rámci asového rozpätia minút alebo hodín.


WELMEC WG7

Trieda rizika B


Trieda rizika C


Trieda rizika D






Validácia Kontrola založená na dokumentácii: • Zdokumentované limity primeranej doby asu pre úlohy legálne nerelevantné sú k dispozícii programátorovi asti softvéru, ktorý nie je predmetom legálnej metrológie. Kontroly funkcii: • Nie sú potrebné žiadne alšie skúšky na ukon enie priebehu skúšky typu, ktoré by potvrdili správne fungovanie prítomných zadefinovaných veli ín rušenia.



WELMEC WG7



10.2.4 Príklady legálne relevantných funkcií a dát Plynomery a prepo ítava e objemu asto majú vä šie množstvo parametrov. Používajú parametre, ako napr. konštanty pre výpo et, konfigura ný parameter at ., ale ja na nastavenie funk nosti zariadenia. Pokia ide o identifikáciu a ochranu parametrov a súboru parametrov, na tieto sa vz ahujú požiadavky P2 a P7 z príru ky P. V nasledovnej tabu ke sú uvedené typické parametre plynomerov a prepo ítava ov objemu. (Táto tabu ka bude zaktualizovaná po kone nom rozhodnutí pracovnej skupiny 11 WELMECu.) Parameter

Chránený

Faktor kalibrácie

x

Faktor linearity

x

Nastavite ný

Poznámka

10.2.5 Ostatné aspekty Pre použitie v domácnosti je predpokladom, že s ahovanie softvéru (rozšírenie D, kapitola 9) nebude ve mi dôležitým. Kumulovaná energia alebo rozsah registra meradiel v domácnosti nie je dlhodobo uchovávaný v zmysle rozšírenia L (kapitola 6). Pre meradlo, ktoré len kumuluje energiu/rozsah nie je nevyhnutné rozšírenie L. 10.2.6 Priradenie triedy rizika Pod a rozhodnutia zodpovednej pracovnej skupiny 11 WELMECu (na druhom stretnutí, 3.-4. marca 2005) sa stanovila nasledovná trieda rizika za prijate nú a mala by by aplikovaná, vtedy ak sú softvérové skúšky vykonané na základe tejto príru ky pre (softvérovo –kontrolované) plynomery a prepo ítava e objemu: - Trieda rizika C pre meradlo typu P Rozhodnutie nie je ešte definitívne a WG 11 bude uvažova nad touto položkou v súvislosti s diskusiou o primeranej triede rizika (rizík) pre meradlo typu U. WG 11 považuje predplatené a intervalové funkcie merania za funkcie dodato né k základným meracím funkciám špecifikovaných v prílohe MI-002 smernice MID, z tohto dôvodu nie je nutné prideli vä šiu skupinu rizík k týmto variantom, ako základné typy meradla už pokryté touto softvérovou príru kou. Avšak, základné meracie funkcie musia by stanovené, tak ako u ostatných typov meradiel P, zárove s inými odhadovanými domnelými nevyhnutnými na dokázanie, že priradený softvér poskytujúci tieto funkcie nemá neprijate ný vplyv na základné meranie.


WELMEC WG7



10.3 Elektromery na meranie aktívnej energie 10.3.1 Špeciálne nariadenia, normy a iné normatívne dokumenty lenský štát môže – v súlade s lánkom 2 smernice MID – zaradi elektromery na meranie aktívnej energie používané v domácnosti, na komer né ú ely a v ahkom priemysle medzi meradlá podliehajúce smernici MID. Špecifické požiadavky tejto kapitoly vychádzajú len z prílohy MI-003. Odporú ania OIML a normy nie sú brané do úvahy. 10.3.2 Technický popis Elektromery na meranie aktívnej energie využívajú napätie a prúd ako vstup, pochádzajúce z aktívneho elektrického výkonu a integrujú ho vzh adom v ase na stanovenie aktívnej elektrickej energie. 10.3.2.1 Hardvérová konfigurácia Elektromery na meranie aktívnej energie zvä ša sú realizované ako jednoú elové zariadenia (v tomto dokumente ako typ P). Môžu ma jeden alebo viac vstupov a môžu by použité v kombinácii s externými meracími transformátormi. 10.3.2.2 Softvérová konfigurácia Pre každého výrobcu je softvérová konfigurácia špecifická, ale bežne sa predpokladajú tieto nasledovné odporú ania stanovené v hlavnej asti tejto príru ky. 10.3.2.3 Princíp merania Elektromery na meranie aktívnej energie priebežne na ítavajú energiu spotrebovanú v obvode. Celková energia je zobrazená na meradle. Pre jeho meranie využívajú rôzne prevodníky a princípy násobku. Meranie energie sa nesmie opakova . 10.3.2.4 Zistenie poruchy a reakcia Požiadavky MI-003, 4.3.1. sa zaoberajú elektromagnetickým rušením. Je potrebné interpretova tieto požiadavky na softvér kontrolujúci meradlá, pretože detekcia poruchy a obnova je možná len v spolupráci so špecifickými as ami hardvéru a špecifickým softvérom. Z poh adu softvéru nie je na druhej strane rozhodujúce o aké rušenie išlo (elektromagnetické, elektrické, mechanické, at .): procesy obnovy sú pre všetky typy rušenia rovnaké.


WELMEC WG7




Trieda rizika C

Trieda rizika D



Špecifikované poznámky: Požadovaná dokumentácia: Stru ný popis mechanizmu na obnovu po chybe a popis kedy ho vyvoláva. Stru ný popis súvisiacich skúšok vykonaných výrobcom.







WELMEC WG7

Trieda rizika B


Trieda rizika C


Trieda rizika D



Špecifikované poznámky: Ak je používané záložné príslušenstvo pre obnovu pri chybe, potom má by vypo ítaný minimálny interval na zaisti , že kriticky zmenená hodnota nie je presiahnutá.

Požadovaná dokumentácia: Stru ný popis dát, ktoré sa zálohujú a kedy sa majú zálohova .


Kontrolujeme, i sú všetky legálne relevantné data uložené do stálej pamäte a ich môžeme nájs .



Príklad prijate ného riešenia: Legálne relevantné data sú zálohované tak, ako je požadované.

Trieda rizika B

Trieda rizika C

Trieda rizika D

I3-3: MID-002, 5.2 (primeraná indikácia)

Displej na zobrazenie celkovej energie musí ma dostato ný po et ísiel zais ujúcich, aby zodpovedalo aspo na 4000 hodín prevádzky pri plnom za ažení (I = Imax, U = Un a PF = 1)

Špecifikované poznámky: Požadovaná dokumentácia: Dokumentácia vnútornej reprezentácie registra elektrickej energie a pomocnej veli iny (premenné veli iny typu).


Kontrolujeme, i je dostato ná kapacity pamäte.

Príklad prijate ného riešenia: Typickými hodnotami pre trojfázové elektromery sú Pmax (4000h) = 3*60 A * 230 V * 4000h = 165600 kWh. Toto vyžaduje vnútornú reprezentáciu 4 bytov.


WELMEC WG7

Trieda rizika B


Trieda rizika C


Trieda rizika D






Kontrolujeme, i celkové legálne relevantné namerané hodnoty nemôžu by zresetované bez dôkazu o zásahu.


Nie sú potrebné žiadne alšie skúšky na ukon enie priebehu skúšky typu, ktoré by potvrdili správne fungovanie. Odkaz na P3 a P4.

Príklad prijate ného riešenia: Zoznamy pre energiu sú chránené proti zmenám a zresetovaniu prostredníctvom tých istých prostriedkov ako parametrov. (pozri P7).


WELMEC WG7

Trieda rizika B


Trieda rizika C


Trieda rizika D






Validácia Kontrola založená na dokumentácii: • Zdokumentované limity primeranej doby asu pre úlohy legálne nerelevantné sú k dispozícii programátorovi asti softvéru, ktorý nie je predmetom legálnej metrológie. Kontroly funkcii: •



10.3.4 Príklady legálne relevantných funkcií a dát Elektronické distribu né meradlá asto majú vä šie množstvo parametrov. Používajú parametre, ako napr. konštanty pre výpo et, konfigura ný parameter at ., ale ja na nastavenie funk nosti zariadenia. Pokia ide o identifikáciu a ochranu parametrov a súboru parametrov, na tieto sa vz ahujú požiadavky P2 a P7 z príru ky P. V nasledovnej tabu ke sú uvedené typické parametre elektromery na meranie aktívnej energie. (Táto tabu ka bude zaktualizovaná po kone nom rozhodnutí pracovnej skupiny 11 WELMECu.) Parameter

Chránený

Faktor kalibrácie

x

Faktor linearity

x

Nastavite ný

Poznámka

10.3.5 Ostatné aspekty Pre použitie v domácnosti je predpokladom, že s ahovanie softvéru (rozšírenie D, 81 Realizované s finan nou podporou Európskej únie v rámci programu Prechodný fond

WELMEC WG7



kapitola 9) nebude ve mi dôležitým. Kumulovaná energia alebo rozsah registra meradiel v domácnosti nie je dlhodobo uchovávaný v zmysle rozšírenia L (kapitola 6). Pre meradlo, ktoré len kumuluje energiu/rozsah nie je nevyhnutné rozšírenie L. 10.3.6 Priradenie triedy rizika Pod a rozhodnutia zodpovednej pracovnej skupiny 11 WELMECu (na druhom stretnutí, 3.-4. marca 2005) sa stanovila nasledovná trieda rizika za prijate nú a mala by by aplikovaná, vtedy ak sú softvérové skúšky vykonané na základe tejto príru ky pre (softvérovo –kontrolované) elektromery na meranie aktívnej energie: - Trieda rizika C pre meradlo typu P Rozhodnutie nie je ešte definitívne a WG 11 bude uvažova nad touto položkou v súvislosti s diskusiou o primeranej triede rizika (rizík) pre meradlo typu U. WG 11 považuje predplatené a intervalové funkcie merania za funkcie dodato né k základným meracím funkciám špecifikovaných v prílohe MI-003 smernice MID, z tohto dôvodu nie je nutné prideli vä šiu skupinu rizík k týmto variantom, ako základné typy meradla už pokryté touto softvérovou príru kou. Avšak, základné meracie funkcie musia by stanovené, tak ako u ostatných typov meradiel P, zárove s inými odhadovanými domnelými nevyhnutnými na dokázanie, že priradený softvér poskytujúci tieto funkcie nemá neprijate ný vplyv na základné meranie.


WELMEC WG7



10.4 Mera e tepla 10.4.1 Špeciálne nariadenia, normy a iné normatívne dokumenty lenský štát môže – v súlade s lánkom 2 smernice MID – zaradi mera e tepla používané v domácnosti, na komer né ú ely a v ahkom priemysle medzi meradlá podliehajúce smernici MID. Špecifické požiadavky tejto kapitoly vychádzajú len z prílohy MI-004. Odporú ania OIML a normy nie sú brané do úvahy. 10.4.2 Technický popis 10.4.2.1 Hardvérová konfigurácia Mera e tepla sú typicky realizované ako jednoú elové zariadenia (v tomto dokumente ako typ P). Mera e tepla sú bu samostatnými meradlami alebo kombinovanými meradlami zložených z iastkových zostáv ako napr. sníma e prietoku, párované sníma e teploty a prepo ítava e, tak ako sú zadefinované v lánku 4 (b) smernice MID, alebo ich kombináciou. 10.4.2.2 Softvérová konfigurácia Pre každého výrobcu je softvérová konfigurácia špecifická, ale bežne sa predpokladajú tieto nasledovné odporú ania stanovené v hlavnej asti tejto príru ky. 10.4.2.3 Princíp merania Mera e tepla priebežne na ítavajú energiu spotrebovanú v tepelnom okruhu. Celková tepelná energia je zobrazená na meradle. Pre jeho meranie využívajú rôzne princípy. Meranie energie sa nesmie opakova . 10.4.2.4 Zistenie poruchy a reakcia Požiadavky MI-004, 4.1 a 4.2 sa zaoberajú elektromagnetickým rušením. Je potrebné interpretova tieto požiadavky na softvér kontrolujúci meradlá, pretože detekcia poruchy a obnova je možná len v spolupráci so špecifickými as ami hardvéru a špecifickým softvérom. Z poh adu softvéru nie je rozhodujúce o aké rušenie išlo (elektromagnetické, elektrické, mechanické, at .): procesy obnovy sú pre všetky typy rušenia rovnaké.


WELMEC WG7




Trieda rizika C

Trieda rizika D











WELMEC WG7

Trieda rizika B


Trieda rizika C


Trieda rizika D





Validácia Kontrola založená na dokumentácii: • Kontrolujeme, i sú všetky legálne relevantné data uložené do stálej pamäte a ich môžeme nájs . Kontroly funkcii: • Nie sú potrebné žiadne alšie skúšky na ukon enie priebehu skúšky typu, ktoré by potvrdili správne fungovanie prítomných zadefinovaných veli ín rušenia.


Trieda rizika B

Trieda rizika C

Trieda rizika D





Validácia Kontrola založená na dokumentácii: • Kontrolujeme, i celkové legálne relevantné namerané hodnoty nemôžu by možnosti spätného zistenia.

zresetované bez

Kontroly funkcii: • Nie sú potrebné žiadne alšie skúšky na ukon enie priebehu skúšky typu, ktoré by potvrdili správne fungovanie prítomných zadefinovaných veli ín rušenia.



WELMEC WG7

Trieda rizika B


Trieda rizika C


Trieda rizika D






Validácia Kontrola založená na dokumentácii: • Zdokumentované limity primeranej doby asu pre úlohy legálne nerelevantné sú k dispozícii programátorovi asti softvéru, ktorý nie je predmetom legálnej metrológie. Kontroly funkcii: •



10.4.4 Príklady legálne relevantných funkcií a dát Mera e tepla využívajú parametre, ako napr. konštanty pre výpo et, pre konfiguráciu at ., ale ja na nastavenie funk nosti zariadenia. Pokia ide o identifikáciu a ochranu parametrov a súboru parametrov, na tieto sa vz ahujú požiadavky P2 a P7 z príru ky P. V nasledovnej tabu ke sú uvedené typické parametre vodomerov. (Táto tabu ka bude zaktualizovaná po kone nom rozhodnutí pracovnej skupiny 11 WELMECu.) Parameter

Chránený

Faktor kalibrácie

x

Faktor linearity

x

Nastavite ný

Poznámka

10.4.5 Ostatné aspekty Pre použitie v domácnosti je predpokladom, že s ahovanie softvéru (rozšírenie D, kapitola 9) nebude ve mi dôležitým. Kumulovaná energia alebo rozsah registra meradiel v domácnosti nie je dlhodobo uchovávaný v zmysle rozšírenia L (kapitola 6). Pre meradlo, ktoré len kumuluje 86 Realizované s finan nou podporou Európskej únie v rámci programu Prechodný fond

WELMEC WG7



energiu/rozsah nie je nevyhnutné rozšírenie L. 10.4.6 Priradenie triedy rizika Pod a rozhodnutia zodpovednej pracovnej skupiny 11 WELMECu (na druhom stretnutí, 3.-4. marca 2005) sa stanovila nasledovná trieda rizika za prijate nú a mala by by aplikovaná, vtedy ak sú softvérové skúšky vykonané na základe tejto príru ky pre (softvérovo –kontrolované) mera e tepla: - Trieda rizika C pre meradlo typu P Rozhodnutie nie je ešte definitívne a WG 11 bude uvažova nad touto položkou v súvislosti s diskusiou o primeranej triede rizika (rizík) pre meradlo typu U.


WELMEC WG7



10.5 Meracie zostavy na kontinuálne a dynamické prete eného množstva kvapalín okrem vody

meranie

Meracie zostavy na kontinuálne a dynamické meranie prete eného množstva kvapalín okrem vody sú predmetom smernice MID. Špecifické požiadavky sú v prílohe MI-005. Ani špecifické požiadavky a ani žiadne normatívne dokumenty nie sú doposia brané do úvahy. 10.5.1 -10.5.5 budú v prípade nutnosti doplnené v budúcnosti. 10.4.6 Priradenie triedy rizika Pod a výsledkov dotazníka skupiny WELMEC WG 7 (2004) a predmetom alších rozhodnutí zodpovednej pracovnej skupiny WELMEC, by mali by aplikovaná nasledovná trieda rizika, vtedy ak sú softvérové skúšky vykonané na základe tejto príru ky pre (softvérovo –kontrolované) meracie zostavy na kontinuálne a dynamické meranie prete eného množstva kvapalín okrem vody. - Trieda rizika C


WELMEC WG7



10.6 Vážiace zariadenia Vážiace zariadenia rozde ujeme do dvoch hlavných kategórii: 1. Neautomatické vážiace zariadenia (NAWI),a 2. Automatické vážiace zariadenia (AWI). Zatia o najpo etnejšie AWI spadajú pod smernicu MID, NAWI pod u nespadajú; oni sú regulované Európskou smernicou . 91/384/EHS. Z tohto dôvodu pre NAWI platí softvérová príru ka WELMEC 2.3, a pre AWI platí táto softvérová príru ka. Špecifické požiadavky tejto kapitoly vychádzajú z prílohy MI-006 a normatívnych dokumentov uvedených v 10.6.1, pokia tieto dokumenty sú v súlade s interpretáciou požiadaviek smernice MID. 10.6.1 Špeciálne nariadenia, normy a iné normatívne dokumenty Prílohe MI-006 smernice MID podlieha 5 kategórii automatických vážiacich zariadení: - Kontrolné váhy s automatickou innos ou (R51) - Plniace váhy s automatickou innos ou (R61) - Diskontinuálne s ítavacie váhy (R107) - Kontinuálne s ítavacie váhy (pásové váhy) (R50) - Mostové váhy s automatickou innos ou ko ajové (R106) ísla v zátvorke sa odvolávajú na príslušné odporú anie OIML, ktoré sú normatívnymi dokumentmi v zmysle smernice MID. Navyše WELMEC vydal príru ku WELMEC 2.6, ktorá podporuje skúšanie kontrolných váh s automatickou innos ou. alej existuje jeden typ AWI, ktorý nespadá pod smernicu MID: - Automatické váhy na váženie cestných vozidiel za pohybu (R134) Všetky kategórie AWI môžu by realizované ako typ P alebo typ U, a všetky rozšírenia by mohli by relevantné pre každú z týchto kategórii. Avšak, z týchto 6 kategórii, len na diskontinuálne a kontinuálne s ítavacie váhy (pásové váhy) môžu by identifikované požadované špecifické softvérové požiadavky (pozri 10.6.3). Dôvod je ten, že meranie je kumulované prostredníctvom pomerne dlhej asového doby a nemôže sa opakova , ak by nastala nejaká zna ná porucha. 10.6.2 Technický popis 10.6.2.1 Hardvérová konfigurácia Diskontinuálne s ítavacie váhy sú váhy s násypkou, ktoré stanovujú hmotnos objemového produktu (napr. obilie) prostredníctvom rozde ovania ich na nespojité asti. Systém vä šinou pozostáva z jednej alebo viacerých násypiek uložených na sníma i, napájacom zdroji, elektronickej kontrole a zobrazujúcom zariadení. Kontinuálne s ítavacie váhy sú pásovými váhami, ktoré merajú vä šinou produkt na posúvajúcom sa páse cez dynamometer. Systém obvykle pozostáva z pásového 89 Realizované s finan nou podporou Európskej únie v rámci programu Prechodný fond

WELMEC WG7



dopravníka, valcov, podporovaného sníma a, napájacieho zdroja, elektronickej kontroly a zobrazujúceho zariadenia. Napätie pása je možné nastavova . 10.6.2.2 Softvérová konfigurácia Pre každého výrobcu je softvérová konfigurácia špecifická, ale bežne sa predpokladajú tieto nasledovné odporú ania stanovené v hlavnej asti tejto príru ky. 10.6.2.3 Princíp merania V prípade diskontinuálne s ítavacích váh objemový produkt je vkladaný do násypky a váži sa. Hmotnos každého oddeleného nákladu je stanovená v sekvenciách a spo ítaná. Každý oddelený náklad je potom distribuovaný k zvyšne hromade. V prípade kontinuálne s ítavacích váh je kontinuálne meranie plynule na páse cez sníma . Merania sú robené v oddelených jednotkách od asu, ktorý je závislý na rýchlosti pásu a sile sníma a. V tomto prípade neexistujú žiadne zámerné delenia produktu alebo prerušenia pásového dopravníka, tak ako to je u diskontinuálnych s ítavacích váh. Celková hmotnos je integrovaním oddelených vzoriek. To znamená, že sníma používa napätie merané dynamometrom alebo technológie ako napr. vibra nú linku. 10.6.2.4 Poruchy K by v páse môžu spôsobi rázové javy, ktoré môžu vies k chybným udalostiam napr. pri nulovaní. V prípade diskontinuálnych s ítavacích váh, jeden alebo všetky výsledky z váženia z oddeleného nákladu môžu vies k strate niektorých z nich ešte pred ich pripo ítaním k ostatným. 10.6.3 Špecifické s ítavacie váhy)

softvérové

požiadavky

(Diskontinuálne

a kontinuálne

Príloha MI-006 smernice MID v kapitole IV asti 8 a v kapitole V, asti 6 sa zaoberá elektromagnetickým rušením. Je potrebné interpretova tieto požiadavky na softvér kontrolujúci meradlá, pretože detekcie poruchy (chyby) a následnej obnovy sú možné len v spolupráci so špecifickými as ami hardvéru a špecifickým softvérom. Z poh adu softvéru nie je rozhodujúce o aké rušenie išlo (elektromagnetické, elektrické, mechanické, at .): procesy obnovy sú pre všetky typy rušenia rovnaké.


WELMEC WG7

Trieda rizika B


Trieda rizika C


Trieda rizika D

I6-1: Odhalenie poruchy

Softvér musí odhali , i bežné spracovanie bolo prerušené.

Špecifikované poznámky: Na zistenie poruchy: a. kumulatívne meranie a iné relevantné data z poh adu metrológie musia by automaticky uložené v stálej pamäti (pozri požiadavku I6-2), a b. násypka váh alebo pásový dopravník musia by zastavené automaticky alebo musia by dané vidite ným alebo po ute ným poruchovým signálom (pozri požadovanú dokumentáciu)

Požadovaná dokumentácia: Stru ný popis toho o je kontrolované, o je požadované na spustenie procesu odhalenia poruchy, aká akcia je podniknutá zistenie poruchy. Ak, pri zistení poruchy nie je možné zastavi systém dopravy automaticky bez oneskorenia (napr. kvôli bezpe nostným dôvodom) dokumentácia musí obsahova popis o tom, ako je nemeraný materiál upravený alebo správne braný do úvahy.


Kontrolujeme, i je zrealizované odhalenie poruchy primerané.


Ak je možné: simuláciou ur i hardvérové poruchy a skontrolova základe softvéru tak, ako je popísané v dokumentácii.

i sú detegované a reagujú na

Príklad prijate ného riešenia: Hardvérový dohliadací obvod je zresetovaný cyklicky spracovaným mikroprocesorovým podprogramom za ú elom zabránenia spustenia dohliadacieho obvodu. Pre resetovaním, podprogram skontroluje stav systému, napr. i boli spracované všetky metrologicky relevantné podprogramy po as posledného intervalu. Ak neboli niektoré z funkcií spracované, alebo – v najhoršom prípade – mikroprocesor zostal visie v nekone nej slu ke, nenastane zresetovanie dohliadacieho obvodu a ten sa spustí až po ur itom asovom rozpätí.


WELMEC WG7

Trieda rizika B


Trieda rizika C


Trieda rizika D


V prípade poruchy tu musí by zariadenie, ktoré zabezpe uje zálohovanie legálne relevantných dát, ako napr. namerané hodnoty a stav merania.

Špecifikované poznámky: a. Stavová charakteristika a dôležité data musia by uložené v stálej pamäte. b. Táto požiadavka bežne nazna uje kontrolované úložné miesta, ktoré automaticky zálohujú v prípade poruchy. Pravidelné zálohovanie je akceptovate né len v tom prípade, ak sú kontrolované úložné miesta nedostupné z dôvodu hardvérovým alebo funk ným obmedzeniam. V takomto výnimo nom prípade musia by intervaly ukladania dostato ne malé. T.j. maximálne možné nezrovnalosti medzi aktuálnymi a uloženými hodnotami musia by v rámci definovanej asti maximálnej dovolenej chyby (pozri požadovanú dokumentáciu). c. Záložné zariadenie by malo bežne obsahova primerané budiace zariadenie aby vážiaci systém, vrátane jeho softvéru, sa nedostalo kvôli poruche do neobmedzeného stavu.

Požadovaná dokumentácia: Stru ný popis záložného mechanizmu a dát, ktoré sú zálohované ako aj definovanie kedy nastane toto zálohovanie. Špecifikovanie a vypo ítanie maximálnej chyby, ktorá môže nasta pri kumulovaní hodnôt, v prípade, že ide o pravidelné (periodické) zálohovanie.

Validácia Kontrola založená na dokumentácii: • Kontrolujeme, i sú všetky legálne relevantné data uložené v prípade poruchy. Kontroly funkcii: • Kontrolujeme pomocou simulácie poruchy, i záložný mechanizmus pracuje tak, ako je popísaný v dokumentácii.

Príklad prijate ného riešenia: Hardvérový dohliadací obvod (watchdog) sa spustí, ke nie je cyklicky zresetovaný. Táto signalizácia ovláda prerušenie v mikroprocesore. Tento priradený prerušovací program okamžite za ne zbiera namerané hodnoty, stavové veli iny a iné relevantné data a uloží ich do energeticky nezávislej pamäte, napr. EEPROM alebo do inej primeranej pamäte. Poznámka: Predpokladá sa, že prerušenie dohliadacieho odvodu má najvyššiu prioritu prerušenia a môže dominova hocijakému bežnému procesu alebo hocijakej doplnkovej nekone nej slu ke, t.j. programová kontrola sa vždy zmení do prerušovacieho programu, ak sa spustí dohliadací obvod.


WELMEC WG7



10.6.4 Príklady legálne relevantných funkcií a dát Tabu ka 10-1: Príklady legálne relevantných, špecificko-prístrojových a typovošpecifických funkcií a dát (DF, DD, TF, TD) pre AWI v porovnaní s s váhami s neautomatickou innos ou (R76). VV ozna ujeme premenné hodnoty. Funkcie/data

Typ

. odporú ania OIML 50 X

51

51

61

76

106

107

(X)

(Y)

X

X

X

X

X

X

X

X

X

X

X

X

Výpo et hmotnosti

TF, TD

Analýza stability

TF,TD

Výpo et ceny

TF, TD

X

X

Algoritmus zaokrúhlenie ceny

TF, TD

X

X

Rozpätie (citlivos )

DD

X

X

X

X

X

X

X

Korekcia nelinearity

DD (TD)

X

X

X

X

X

X

X

Max, Min, e, d

DD (TD)

X

X

X

X

X

X

X

Jednotky merania (napr. g, kg)

DD (TD)

X

X

X

X

X

X

X

Zobrazená hodnota hmotnosti (zaokrúhlená k násobku e alebo d)

VV

X

X

X

X

Tara, stanovenie tary

VV

X

X

Jednotková cena, splatná cena

VV

Hodnota rozlíšení

v internom

VV

X

X

X

X

X

X

X

Stavové signály (napr. indikácia nuly, stabilita rovnováhy)

TF

X

X

X

X

X

X

X

Porovnanie aktuálnej hmotnosti so stanovenou

TF

Automatická tla , napr. pri prerušení automatickej operácie

TF

X

TF (TD)

X

hmotnosti

Doba zahrievania Vzájomné blokovanie funkcií

X

X

X

X

X

X

TF

napr. nastavenie nuly/tary

X

X

X X

X

X

X

X

X

X

X

X

X

X

Automatická/neautomatická operácia

X

X

Nastavenie nuly/súhrnu

X

Záznam z prístupu k dynamickému nastaveniu

TF (VV)

Maximálna rýchlos výkonu/rozsah opera ných rýchlosti (dynamické váženie)

DD (TD)

(Produkt) – Parametre pre výpo et dynamického váženia Prednastavená hmotnosti

hodnota

X

X X

X

X

X

VV

X

X

VV

X

X


X

X

X X

X

WELMEC WG7



Nastavenie rozsahu

DD (TD)

X

X

Kritérium na automatické nastavenie nuly (napr. asový interval, koniec vážiaceho cyklu)

DD (TD)

X

X

Minimálne plnenie, minimálne plnenie

stanovené

DD

X

X

X

Limitné hodnoty dôležitých chýb (ak nie je 1e alebo 1d)

DD (TD)

X

Limitná hodnota životnosti batérie

DD (TD)

X

X

X

X X

X

X

X

X

Tabu ka 10-1: Príklady legálne relevantných, špecificko-prístrojových a typovo-špecifických funkcií a dát

Vyzna ené funkcie a parametre sa pravdepodobne vyskytujú na rôznych typoch váh. Ak je váhach jedna z týchto funkcií alebo parametrov, potom ich môžeme považova za „legálne relevantné“. To ale neznamená, že tabu ka nie je ur eným ako povinným zoznamom indikujúcim, že hocijaké funkcie a parametre, ktoré sú v nej uvedené musia by na každom meradle.

10.6.5 Ostatné aspekty Žiadne

10.6.6 Priradenie triedy rizika Pod a rozhodnutia zodpovednej pracovnej skupiny WELMEC (24. stretnutie WG2, 22.-23. január2004) musí by trieda rizika „B“ aplikovaná na všetky kategórie AWI bez oh adu na typ (P alebo U). Avšak pod a výsledku dotazníku skupiny WG7 (2004) nasledovné rozlišovanie týkajúce sa meradiel typu P a U a diskontinuálnych a kontinuálnych s ítavacích váh sa zdajú by vhodné a budú opä prediskutované na WG2 (rozhodnutie na 25. stretnutí WG2, 14.-15. október 2004). - Trieda rizika B pre meradlo typu P (okrem s ítavacích) - Trieda rizika C pre meradlá typu U a s ítavacie váhy typu P a U


X

WELMEC WG7



10.7 Taxametre Taxametre sú predmetom smernice MID. Špecifické požiadavky sú stanovené v prílohe MI-007. Doposia nie sú brané na zváženie ani tieto špecifické požiadavky a ani žiadne normatívne dokumenty. 10.7.1 Špeciálne nariadenia, normy a iné normatívne dokumenty Európska norma EN50148, ktorá by mohla by normatívnym dokumentov v zmysle smernice MID nebola doposia ou stanovená. Spolu s touto normou je výsledkom projektu „MID-Procedures“ aj publikácia s poradným dokumentom o taxametroch. V budúcnosti by sa tento dokument mohol sta základom príru ky WELMEC. Taktiež obsahuje vôbec prvý návrh odporú ania OIML na taxametre. Terajší OIML dokument nie je na takej úrovni, aby mohol by používaný ako normatívny dokument (situácia z októbra 2004). 10.7.2 Technický popis Taxametre tak, ako sú zadefinované v smernici MID merajú as, vzdialenos (s použitím výstupu generátora signálu vzdialenosti, ktorý nie je predmetom smernice MID) a vypo ítava cestovné za jazdu na základe aplikovaných taríf. Sú asné taxametre používajú zabudované zostrojenie, o znamená, že taxametre sú v zmysle tejto príru ky jednoú elovými meracími prístrojmi (typ P). Predpokladá sa, že v budúcnosti sa budú vyrába aj taxametre, ktoré budú požíva univerzálny po íta (typ U). 10.7.3 Špecifické softvérové požiadavky Príloha MI-007, as 9 smernice MID: V prípade, že napájanie poklesne pod minimálnu hodnotu danú výrobcom, taxameter musí: - na alej pracova správne alebo pokra ova v správnom fungovaní bez straty dát, ktoré boli k dispozícii pred poklesom napätia, ak je pokles napätia prechodný, t.j. zavinením reštartovania motora, - ukon i existujúce merania a vráti sa do polohy „Obsadené“ ak bol pokles napätia dlhodobejší. Taxametre taktiež potrebujú ma dlhodobú pamä , pri om data v taxametri musia by k dispozícii najmenej 1 rok, pozri MI-007, 15.2.


WELMEC WG7


Trieda rizika B

Trieda rizika C


Trieda rizika D


Ak nastane pokles dlhodobejší napätia, musí zariadenie automaticky zálohova dôležité data, napr. namerané hodnoty a aktuálny stav procesu.

Špecifikované poznámky: 1) Tieto data by mali by bežne ukladané do energeticky nezávislej pamäte. 2) Detektor zis uje úrove napätia, ke je potrebné namerané hodnoty uloži . 3) Záložné zariadenia musia obsahova príslušné budiace zariadenia aby sa taxametre, vrátane ich softvéru nedostali do asovo neobmedzeného stavu.

Požadovaná dokumentácia: Stru ný popis dát, ktoré sú zálohované a kedy sa zálohujú.





Príklad prijate ného riešenia: Detektor úrovne napätia spustí prerušenie, ke poklesne úrove napätia na dobu 15 s. Priradený prerušovací program pozbiera namerané hodnoty, stavové veli iny a iné relevantné data a uloží ich v energeticky nezávislej pamäti, napr. EEPROM. Po stabilizovaní úrovne napätia sú data obnovené a ich funkcia bu pokra uje alebo je zastavená (pozri MI-007, 9). Poznámka: Predpokladá sa, že prerušenie úrovni napätia má vysokú prioritu prerušenia a môže dominova hocijakému bežnému spracovaniu alebo hocijakej ubovo nej nekone nej slu ke, .t.j. pri poklese napätia vždy prejde kontrola programu do prerušovacieho programu.

10.7.4 Príklady legálne relevantných funkcií a dát V nasledovnej tabu ke sú dané typické parametre taxametrov. Parameter

Ochrana

k-faktor

x

Tarify

x

Parametre rozhrania

Nastavenie Poznámka Impulzy na km x

mena jednotka/km, mena jednotka/h

x

Prenosová rýchlos

10.7.5 Ostatné aspekty Odporú a sa, že smernica o automobiloch bude revidovaná alebo sa vypracuje nejaké iné nariadenie, ktoré stanoví požiadavky na generátory signálu vzdialenosti vozidiel používaných ako taxíky. Predbežný návrh znie: Pre vozidlá, pri ktorých sa plánuje ich využitie na taxíky sa aplikujú nasledovné požiadavky: 1. Generátory signálu vzdialenosti musí dáva signál s rozlíšením najmenej 2 m. 96 Realizované s finan nou podporou Európskej únie v rámci programu Prechodný fond

WELMEC WG7


2. Generátory signálu vzdialenosti musia dáva rýchlostiach po as jazdy.


stabilný signál

pri všetkých

3. Generátory signálu vzdialenosti musia ma zadefinované charakteristiky týkajúce sa úrovni napätia, rozpätia impulzu a spojitos rýchlosti a frekvencie. 4. Skúšky schopnos .... 10.7.6 Priradenie triedy rizika Pod a výsledku dotazníka skupiny WELMEC WG7 (2004) a predmetu nasledovných rozhodnutí zodpovednej pracovnej skupiny WELMEC mali by by aplikované nasledovné triedy rizík ak sa skúšky softvéru vykonávajú na základe tejto príru ky pre (softvérovo-ovládané) taxametre: -

Trieda rizika C pre meradlá typu P

-

Trieda rizika C pre meradlá typu U


WELMEC WG7



10.8 Materializované miery Materializované miery sú predmetom smernice MID. Špecifické požiadavky sú stanovené v prílohe MI-008. Materializované miery v zmysle smernice MID nie sú predmetom budúcich vývojov a rozhodnutí považované za softvérovo - vybavené meradlá. Z tohto dôvodu sa táto príru ka neaplikuje na materializované miery.


WELMEC WG7



10.9 Meradlá rozmerov Meradlá rozmerov sú predmetom smernice MID. Špecifické požiadavky sú v prílohe MI-009. Ani špecifické požiadavky a ani žiadne normatívne dokumenty nie sú doposia brané do úvahy. 10.9.1 -10.9.5 budú v prípade nutnosti doplnené v budúcnosti. 10.9.6 Priradenie triedy rizika Pod a výsledkov dotazníka skupiny WELMEC WG 7 (2004) a predmetom alších rozhodnutí zodpovednej pracovnej skupiny WELMEC, by mali by aplikovaná nasledovná trieda rizika, vtedy ak sú softvérové skúšky vykonané na základe tejto príru ky pre (softvérovo –kontrolované) meradlá rozmerov. - Trieda rizika B pre meradlá typu P - Trieda rizika C pre meradlá typu U


WELMEC WG7



10.10Analyzátory výfukových plynov Analyzátory výfukových plynov sú predmetom smernice MID. Špecifické požiadavky sú v prílohe MI-010. Ani špecifické požiadavky a ani žiadne normatívne dokumenty nie sú doposia brané do úvahy. 10.10.1 -10.10.5 budú v prípade nutnosti doplnené v budúcnosti. 10.10.6 Priradenie triedy rizika Pod a výsledkov dotazníka skupiny WELMEC WG 7 (2004) a predmetom alších rozhodnutí zodpovednej pracovnej skupiny WELMEC, by mali by aplikovaná nasledovná trieda rizika, vtedy ak sú softvérové skúšky vykonané na základe tejto príru ky pre (softvérovo –kontrolované) analyzátory výfukových plynov. - Trieda rizika B pre meradlá typu P - Trieda rizika C pre meradlá typu U


WELMEC WG7

11



Definícia triedy rizika

11.1 Všeobecný princíp Požiadavky z tejto príru ky sú odlišné pod a (softvérových)tried rizík. Riziká, ktoré súvisia so softvérom meradla nie sú žiadnymi inými rizikami. Pre u ah enie zdôvodnenia sú používa skrátený termín „trieda rizika“. Každému meradlu musí by pridelená trieda rizika, pretože špecifické softvérové požiadavky, ktoré sa aplikujú sú ur ené triedou rizika k meradlu, ku ktorému patria. Trieda rizika je definovaná kombináciou príslušných požadovaných úrovní pre ochranu softvéru, skúšky softvéru a zhody softvéru. Pre každú z týchto skupín sú uvedené tri úrovne, nízka, stredná, vysoká.

11.2 Popis úrovní ochrany, skúšania a zhody Pre príslušné úrovne sa používajú nasledovné definície. Úrovne ochrany softvéru Nízka:

Proti úmyselným zmenám nie sú požadované žiadne špecifické ochranné opatrenia.

Stredná: Softvér je chránený proti úmyselným zmenám s použitím ahko dostupných a jednoduchých spolo ných softvérových nástrojov (napr. textový editor). Vysoká: Softvér je chránený proti úmyselným zmenám s použitím sofistikovaných softvérových nástrojov (debuggerov a editorov pevných diskov, softvérových vývojových nástrojov, at .). Úrovne skúšania softvéru Nízka:

Vykoná sa štandardný skúška typu funk nosti meradla. Nie sú požadované žiadne ved ajšie preskúšanie softvéru.

Stredná: Softvér je skúšaný na základe svojej dokumentácie, o je navyše oproti nízkej úrovni. Dokumentácia obsahuje popis softvérových funkcií, parametrický popis, at . Praktické skúšky programovej podpory funkcií (náhlymi kontrolami) sa môžu vykona skontrolovaním prijate nej dokumentácie a efektívnosti ochranných opatrení. Vysoká: Vykoná sa h bkové preskúšanie softvéru, zvy ajne na základe zdrojového kódu, o je navyše oproti strednej úrovni. Úrovne zhody softvéru Nízka:

Funk nos implementovaného softvéra pre každé meradlo je v zhode so 101


WELMEC WG7



schválenou dokumentáciu. Stredná: V závislosti na technických vlastnostiach, musia by asti softvéru zadefinované ako stanovené v skúške typu, t.j. môžu by zmenené len so schválením NO, o je navyše oproti „nízkej“ úrovni. Fixná as musí by v každom meradle identická. Vysoká: Implementovaný schváleným.

softvér

v kompletnom

meradle

je

identický

so

11.3 Odvodenie tried rizika Z 27 teoreticky možných permutácii majú praktický význam len 4 nanajvýš 5 (triedy rizika B, C, D a E, eventuálne aj F). Tieto triedy rizík pokrývajú všetky triedy meradiel, ktoré spadajú pod smernicu MID. Navyše poskytujú dostato né priestor pre prípadné zmeny hodnotení rizík. V nasledovnej tabu ke sú zadefinované tieto triedy.

Ochrana softvéru

Skúšanie softvéru

Stupe zhody softvéru

A

nízka

nízka

nízka

B

stredná

stredná

nízka

C

stredná

stredná

stredná

D

vysoká

stredná

stredná

E

vysoká

vysoká

stredná

F

vysoká

vysoká

vysoká

Trieda rizika

Tabu ka 11-1: Definícia tried rizika

11.4 Interpretácia tried rizika Trieda rizika A:

Je najnižšou triedou rizika zo všetkých. Proti úmyselným zmenám nie sú požadované žiadne špecifické opatrenia. Skúšanie softvéru je sú as ou preskúšania funkcií zariadenia. Zhoda je požadovaná na úrovni dokumentácie. Nepredpokladá sa, že by bolo nejaké meradlo zaradené do triedy rizika A. Táto trieda je zadefinovaná len pre prípadné využitie v budúcnosti.

Trieda rizika B:

V porovnaní s triedou rizika A sa v tejto požaduje úrove ochrany softvéru na strednej úrovni. Príslušná úrove skúšania je tiež zlepšená na strednú úrove . Zhoda zostáva nezmenená v porovnaní s triedou rizika A.

Trieda rizika C:

V porovnaní s triedou rizika B je v tejto triede zvýšená úrove zhody na „strednú“ úrove . To znamená, že as softvéru môže by deklarovaná ako stanovená v skúške typu. Zvyšok softvéru sa 102


WELMEC WG7



považuje za zhodný s úrov ou funk nosti. Úrovne ochrany a skúšania zostávajú neznemené v porovnaní s triedou rizika B. Trieda rizika D:

Dôležitým rozdielom v porovnaní s triedou rizika je C je zvýšenie na „vysokú“ úrove ochrany. Ke že úrove skúšania zostáva nezmenená na dostato nej „strednej“ úrovni v informatívnej dokumentácii musí by preukázané, že tieto ochranné opatrenia sú vhodné. Úrove zhody v porovnaní s triedou rizika C zostáva nezmenená.

Trieda rizika E:

V porovnaní s triedou rizika D je v tejto triede zvýšená úrove skúšania na „vysokú“ úrove . Úrovne ochrany a zhody zostávajú nezmenené.

Trieda rizika F:

Úrovne s oh adom na všetky aspekty (ochrana, skúšanie a zhoda) sú na úrovni „vysokej“. Tak ako pri triede rizika A sa nepredpokladá, že by nejaké meradlo bolo zaradené v triede rizika F. Táto trieda je zadefinovaná len pre prípadné využitie v budúcnosti.


WELMEC WG7

12



Vzor správy o skúške (vrátane kontrolných záznamov)

Vzor správy o skúške sa skladá z hlavnej asti a z dvoch príloh. Hlavná as obsahuje všeobecné vyhlásenia na predmet, ktorý sa skúša. Musí korešpondova a by prispôsobený s tým, ktorý s používa v praxi. Príloha 1 sa skladá z dvoch kontrolných záznamov, ktorými sa podporuje výber vhodnej asti z príru ky, ktorá sa bude aplikova . Príloha 2 pozostáva zo špecifického kontrolného záznamu pre príslušné technické asti príru ky. Tieto majú charakter odporú ací a sú nápomocné pre výrobcu a osobu, ktorá vykonáva skúšku takým spôsobom, že zhodnotia všetky aplikovate né požiadavky. Okrem vzoru správy o skúške a kontrolných dotazníkov, sú v poslednej podkapitole tejto príru ky uvedené aj informácie potrebné pre certifikát skúšky typu.


WELMEC WG7



12.1 Vzor pre všeobecnú as správy o skúške Správa o skúške . XYZ122344 Prietokomer Dynaflow, model DF101 Validácia softvéru (n príloh) Poslanie Smernica o meradlách (MID) udáva základné požiadavky na meradlá používané v Európskej únii. Softvér v meradle bol validovaný, a bola preukázaná zhoda so základnými požiadavkami smernice MID. Validácia bola založená na dokumente WELMEC MID Príru ka k softvérovým požiadavkám (príru ka WELMEC 7.2), v ktorej sú interpretované a vysvetlené základné požiadavky na softvér. Táto správa popisuje skúšanie softvéru, ktoré bolo vykonané, aby bola preukázaná zhoda so smernicou MID. Klient Dynaflow P.O.BOX 1120333 100 Reykjavik Island Kontaktná osoby: Bjarnur Sigfridson

Predmet skúšania Prietokomer Dynaflow DF10 je meradlo ur ené na meranie prietoku kvapalín. Rozsah merania je od 1 l/s do 200 l/s. Základnými funkciami meradla sú: -

meranie prietoku kvapalín

-

indikácia nameraného množstva

-

rozhranie k prevodníku

Pod a príru ky WELMEC 7.2 je prietokomer popísaný nasledovne. -

jednoú elový merací prístroj (so zabudovaným systémom)

-

meradlo obsahujúce dlhodobé ukladanie relevantných dát

Prietokomer DF100 je samostatné meradlo s pripojeným prevodníkom. Prevodník je pripevnený k meradlu a nemôže by z neho odpojený. Meraný objem je indikovaný na displeji. Nie je možná žiada komunikácia s inými zariadeniami, nako ko prietokomer na túto komunikáciu nemá prostriedky. Softvér zabudovaný v meradle bol vyvinutý v Dynaflow, P.O.BOX 1120333, 100 Reykjavik, Island


WELMEC WG7



Verzia validovaného softvéru je V1.2c. zdrojový kód sa skladá z nasledovných súborov: main.c 12301 bytov 23 Nov 2003 int.c 6509 bytov 23 Nov 2003 filter.c 10891 bytov 20 Oct 2003 input.c 2004 bytov 20 Oct 2003 diplay.c 32000 bytov 23 Nov 2003 Ethernet.c 23455 bytov 15 June 2003 driver.c 11670 bytov 15 June 2003 calculate.c 6788 bytov 23 Nov 2003

Validácia sa opierala o nasledovné dokumenty dodané výrobcom: -

DF 100 Užívate ský manuál 106


WELMEC WG7



-

DF 100 Manuál na údržbu

-

Popis softvéru DF100 (interne navrhnutý dokument, datovaný k 22. novembru 2003)

-

Elektronická schéma DF100 (nákres 222-31, dátum 15. október 2003)

Predmet skúšania v závere nej verzii bol dodaný Národnému metrologickému inštitútu d a 25. novembra 2003. Postup skúšania Validácia sa vykonala pod a Príru ky k softvéru WELMEC 7.2, Vydanie 1 (stiahnutý z www.welmec.org) . Validácia bola vykonaná v období od 1. novembra do 23. decembra 2003. Návrh bol posúdený d a 3. decembra Dr. K. Fehlerom v sídle firmy Dynaflow v Reykvjaviku. Ostatné valida né skúšky boli vykonané v národnom metrologickom inštitúte Dr. K. Fehlerom a M. S. Problème. Validovali sa nasledovné požiadavky: -

Špecifické požiadavky na zabudovaný softvér pre jednoú elový merací prístroj (typ P)

-

Rozšírenie L: dlhodobé ukladanie relevantných dát

Kontrolný záznam pre vybranú konfiguráciu je v prílohe 1 tejto správy. Na toto meradlo bola aplikovaná trieda rizika C. Na meradlo boli aplikované nasledovné metódy validácie: -

identifikácia softvéru kompletnos dokumentácie skúšanie z opera ného manuálu preskúšanie funkcii zhodnotenie návrhu softvéru zhodnotenie softvérovej dokumentácie analýza toku dát simulácia vstupných signálov

Strana 2 / 3

Výsledok Nasledovné požiadavky Príru ky k softvéru WELMEC 7.2 boli bezchybne splnené: -

P1, P2, P3, P5, P6, P7 (požiadavka P4 sa nevz ahuje k tomuto softvéru)

-

L1, L2, L3, L4, L5, L6, L7

Kontrolné záznamy pre požiadavky P sú uvedené v prílohe 2.1 tejto správy. Kontrolné záznamy pre požiadavky L sú uvedené v prílohe 2.2 tejto správy. Pri skúšaní sa našli dva príkazy, ktoré neboli na za iatku popísané v opera nom manuáli. Tieto dva príkazy boli zahrnuté do opera ného manuálu s dátumom 10. december 2003. Softvérová chyba, ktorá predpisuje mesiac február s 28 d ami a tiež s priestupným rokom bola nájdená v softvérovom balík V1.2b. Toto bolo opravené vo verzii V1.2c.


WELMEC WG7



Softvér Dynaflow DF100 V1.2c. splnil základné požiadavky smernice o meradlách. Výsledok platí len na skúšaný druh.

Národný metrologický inštitút Oddelenie validácie softvéru

Dr. K.E.I.N. Fehler

M. S.A.N.S Prolbème

Technický manažér

Technický vedúci

Dátum: 23. december 2003 Strana 3 / 3

12.2 Príloha 1 správy o skúške: Kontrolné záznamy podporujúce výber primeraného súboru požiadaviek Prvý kontrolný záznam podporuje rozhodnú sa užívate ovi, ktorý zo základných konfigurácii, P alebo U, aplikuje na meradlo v štádiu skúšania. Výber typu pre meradlo (P)

1

Je celý aplika ný softvér konštruovaný na meracie ú ely? (A)

2

Ak je softvér všeobecne-použite ný, je dostupný alebo (N) vidite ný používate om? Ak je možnos zmeni opera ný režim, ktorý nie je (A) predmetom právnej kontroly, je používate ovi zabránený prístup do opera ného systému?

3


Poznámka

WELMEC WG7

4 5



Sú implementované programy a softvérové prostredie (A) nemenné (okrem aktualizácie)? Sú v meradle nejaké prostriedky na programovanie? (N) Zaškrtnite vhodné polí ka

Ak sú všetky odpovede na 5 otázok len v st pci (P), potom sa aplikujú požiadavky asti P (kapitola 4). Vo všetkých ostatných prípadoch je nutné aplikova požiadavky asti U (kapitola 5). Druhý kontrolný záznam podporuje rozhodnú sa, ktorý z IT konfigurácii sa aplikuje na meradlo v štádiu skúšania.

L T

S D

Poznámky

N/A

NIE

ÁNO

Pož. rozšírenie

Výber požadovaného rozšírenia

Má zariadenie schopnos uloži namerané data bu na integrovanú pamä alebo na prenosnú alebo vymenite nú pamä ? Má zariadenie rozhranie na prenos dát do zariadení, ktoré podliehajú právnej kontrole ALEBO je zariadenie, ktoré prijíma data z iného zariadenia, ktoré podlieha právnej kontrole? Má as softvéru funkcie, ktoré nie sú predmetom právnej kontroly A je tieto softvérové asti potrebné po zmene typovo schváli ? Je možné alebo požadované s ahovanie softvéru? Posú te požadované rozšírenie pre každú otázku zodpovedanú s ÁNO!

Posú te požadované rozšírenie pre každú otázku zodpovedanú s ÁNO!

12.3 Príloha 2 správy o skúške: Špecifické kontrolné záznamy pre konkrétne technické asti 1) Kontrolný záznam základných požiadaviek na meradlo typu P

P1 P2

Splnil výrobca požadovanú dokumentáciu požiadavky P1 (a-f)? Je identifikácia softvéru zrealizovaná tak, ako je požadované v P2? 109


Poznámky* N/A

Nevyhovel

Vyhovel

Proces skúšania

Požiadavka

Kontrolný záznam pre požiadavky typu P

WELMEC WG7



Je užívate ské rozhranie pre zadané príkazy vytvorené tak, že neumož uje neprijate ne ovplyv ova legálne relevantný softvér a namerané data? Je nezabezpe ené komunika né rozhranie meradla pre vstupné príkazy vytvorené tak, že neumož uje neprijate ne ovplyv ova legálne relevantný softvér a namerané data? Je legálne relevantný softvér a namerané data chránené pred náhodnými alebo neúmyselnými zmenami? Je legálne relevantný softvér zabezpe ený pred nedovolenou modifikáciou, vložením alebo presunom hardvérovej pamäte? Sú parametre, ktoré sú pevnými charakteristikami legálne relevantného softvéru meradla zabezpe ené pred neoprávnenou modifikáciou?

P3 P4

P5 P6 P7

* V prípade odlišných softvérových požiadaviek je potrebné ich vysvetli .

2) Kontrolný záznam základných požiadaviek na meradlo typu U

U1 U2 U3 U4

U5 U6 U7 U8 U9

Splnil výrobca požadovanú dokumentáciu požiadavky U1 (a-f)? Je identifikácia softvéru zrealizovaná tak, ako je požadované v U2? Je užívate ské rozhranie pre zadané príkazy vytvorené tak, že neumož uje neprijate ne ovplyv ova legálne relevantný softvér a namerané data? Je zabránené, aby príkazy vstupujúce cez nezabezpe ené komunika né rozhranie meradla nedovolene ovplyv ovali legálne relevantný softvér a namerané data? Je legálne relevantný softvér a namerané data chránené pred náhodnými alebo neúmyselnými zmenami? Je legálne relevantný softvér zabezpe ený pred nedovolenou modifikáciou? Sú legálne relevantné parametre zabezpe ené pred neoprávnenou modifikáciou? Sú použité prostriedky na zabezpe enie autentickosti legálne relevantného softvéru a sú autentické výsledky, ktoré sú prezentované ako garantované? Je legálne relevantný softvér navrhnutý tak, že iné softvéri ho nedovolene neovplyvnia?


3) Kontrolný záznam špecifických požiadaviek rozšírenia L Kontrolný záznam pre požiadavky rozšírenia L


Poznámky* N/A

Nevyhovel

Vyhovel

Proces skúšania

Požiadavka

Kontrolný záznam pre požiadavky typu U

Poznámky* N/A

Vyhovel


Nevyhovel


Proces skúšania

Požiadavka

WELMEC WG7

Obsahujú uložené namerané data všetky relevantné informácie, ktoré sú nevyhnutné na obnovu po iato ných meraní? Sú uložené data chránené pred náhodnými a neúmyselnými zmenami? Sú uložené namerané data chránené pred úmyselnými zmenami, ktoré je možné vykona jednoduchými všeobecnými softvérovými nástrojmi (pri triede rizík B&C) alebo špeciálnymi sofistikovanými softvérovými nástrojmi (pre triedy rizík D&E)? Je možné spätne z uložených nameraných dát autenticky zisti , z ktorého merania sú vygenerované? (B&C) Sú klávesy spracované tak, aby legálne relevantné data a data uchované v tajnosti a chránené pred odhalením s použitím jednoduchých softvérových nástrojov? (D&E) Sú klávesy a doprevádzajúce data spracované tak, aby legálne relevantné data a data uchované v tajnosti a chránené pred odhalením s použitím sofistikovaných softvérových nástrojov? Sú pridelené metódy použité ekvivalentne k elektronickému plateniu? Je užívate schopný si overi autentickos verejného k ú a? Vykoná softvér použití na overenie uložených nameraných dátových súborov zobrazenie alebo tla dát, skontroluje data, i neboli zmenené a upozorní ak sa vyskytnú nejaké zmeny? Existujú tam prostriedky, ktoré zabránia použi takéto zistené poškodené data? Sú namerané data ukladané automaticky po skon ení merania? Má dlhodobá pamä kapacitu dostato nú na ur ené ú ely?

L1 L2 L3

L4 L5

L6

L7 L8


4) Kontrolný záznam špecifických požiadaviek rozšírenia T

T1 T2 T3

Obsahujú prenášané data všetky relevantné informácie, ktoré sú nevyhnutné na prezentovanie alebo na alší postup nameraných výsledkov v prijímacom module? Sú prenášané data chránené pred náhodnými a neúmyselnými zmenami? Sú legálne relevantné prenášané data chránené pred úmyselnými zmenami, ktoré je možné vykona jednoduchými všeobecnými softvérovými nástrojmi (pri triede rizík B&C) alebo špeciálnymi sofistikovanými softvérovými nástrojmi


Poznámky* N/A

Nevyhovel

Vyhovel

Proces skúšania

Požiadavka

Kontrolný záznam pre požiadavky rozšírenia T

WELMEC WG7



(pre triedy rizík D&E)? Je možné aby program, ktorý prijíma prenášané relevantné data overoval ich autentickos a pridelil namerané hodnoty k jednotlivým meraniam? (B&C) Sú klávesy spracované tak, aby legálne relevantné T5 data a data uchované v tajnosti a chránené pred odhalením s použitím jednoduchých softvérových nástrojov? (D&E) Sú klávesy a doprevádzajúce data spracované tak, aby legálne relevantné data a data uchované v tajnosti a chránené pred odhalením s použitím sofistikovaných softvérových nástrojov? Sú pridelené metódy použité ekvivalentne k elektronickému plateniu? Je užívate schopný si overi autentickos verejného k ú a? Je zabránené, aby data, pri ktorých bolo zistené, že boli T6 poškodené sa používali? Je zabezpe ené aby merania neboli nedovolene ovplyvnené T7 oneskoreným pri prenose? Je zabezpe ené aby sa namerané data nestratili, pokia by T8 boli nedostupné služby siete? * V prípade odlišných softvérových požiadaviek je potrebné ich vysvetli . T4

5) Kontrolný záznam špecifických požiadaviek rozšírenia S

Poznámky* N/A

Nevyhovel

Vyhovel

Proces skúšania

Požiadavka

Kontrolný záznam pre požiadavky rozšírenia S

Obsahuje softvér, ktorý je predmetom právnej kontroly legálne relevantný softvér a všetky parametre? Je zabezpe ené, aby dodato né informácie vygenerované S2 legálne nerelevantnou as ou softvéru, ktoré sú zobrazené alebo vytla ené v protokole nebolo možné zmeni s informáciami, ktoré pochádzajú z legálne relevantnej asti? Je výmena dát medzi legálne relevantným a legálne S3 nerelevantným softvérom vykonaná cez ochranné softvérové rozhranie tak, že zah a kontroly vzájomného pôsobenia a toku dát? * V prípade odlišných softvérových požiadaviek je potrebné ich vysvetli . S1

6) Kontrolný záznam špecifických požiadaviek rozšírenia D

D1 D2 D3 D4

Je s ahovanie a následná inštalácia softvéru automatická? Je zabezpe ené, aby ochrana softvérového prostredia bola v súlade s úrov ou na dokon enie? Sú použité prostriedky, ktoré garantujú, že stiahnutý softvér je autentický a udáva, že stiahnutý softvér bol schválený NO? Sú použité prostriedky, ktoré garantujú, že stiahnutý softvér je autentický a udáva, že stiahnutý softvér nebol nedovolene menený po as s ahovania? Je garantované pridelenými technickými prostriedkami, že 112


Poznámky* N/A

Nevyhovel

Vyhovel

Proces skúšania

Požiadavka

Kontrolný záznam pre požiadavky rozšírenia D

WELMEC WG7



stiahnuté legálne relevantné softvéri sú dostato ne rozlíšite né v meradle pre následné kontroly? Je garantované technickými prostriedkami, že len softvér D5 môže zah a výlu ný konsenzus užívate a alebo vlastníka meradla, ak je pridelený? * V prípade odlišných softvérových požiadaviek je potrebné ich vysvetli .

12.4 Informácie, ktoré majú by sú as ou certifikátu skúšky typu Pokia celá dokumentácia je predmetom skúšky, vykonaná validácia a výsledky, požaduje sa presným výber informácii obsiahnutých v správe o skúške pre certifikát skúšky typu (TEC). Toto sa týka nasledovných informácii, ktoré by mali by zahrnuté v TEC: •

Odkaz na dokumentáciu, ktorá je predkladaná na skúšku typu,

•

Identifikácia a popis elektronických (hardvérových) komponentov ( iastkových zostáv, modulov), ktoré sú dôležité pre softvér / funkciu IT meradla,

•

Preh ad softvérového prostredia, ktoré je nevyhnutné k výkonu softvéru,

•

Preh ad modulov SW, ktoré sú pod právnou kontrolou (vrátane oddelenia SW, ak sa implementoval),

•

Preh ad a identifikácia hardvérového a softvérového (ak je relevantné) rozhraní, ktoré sú dôležité pre softvér / IT funkcie meradla (vrátane infra erveného rozhrania, Bluetooth, bezdrôtovej LAN,...),

•

Identifikácia a popis umiestnenia softvérových komponentov v meradle (t.j. EPROM, procesor, pevný disk,...), ktoré je potrebné zaplombova alebo zabezpe i ,

•

Inštrukcia, ako skontrolova identifikáciu softvéru (pre metrologický doh ad).

•

V prípade elektronického zaplombovania: inštrukcie pre inšpekciu kontrolného záznamu.


WELMEC WG7

13



Krížové referencie pre softvérové požiadavky MID na lánky a prílohy MID

(Popis verzie MID: Smernica 2004/22/ES, 31. marec 2004)

13.1 Stanovené softvérové požiadavky, vz ah k MID .

P1

P2 P3 P4 P5 P6 P7

U1

Požiadavka Význam Základná príru ka P Dokumentácia výrobcu

lánok / Príloha . (AI = Príloha I) AI-9.3

AI-12 lánok 10 Softvérová identifikácia AI-7.6 AI-8.3 Ovplyvnenie cez užívate ské AI-7.1 rozhranie Ovplyvnenie cez komunika né AI7.1 rozhranie AI-8.1 Ochrana proti náhodným alebo AI-7.1, AI-7.2 neúmyselným zmenám AI-8.4 Ochrana proti úmyselným AI-7.1 zmenám AI-8.2, AI-8.3, AI-8.4 Ochrana parametre AI-7.1 AI-8.2, AI-8.3, AI-8.4 Základná príru ka U Dokumentácia výrobcu

AI-9.3

U9

AI-12 lánok 10 Softvérová identifikácia AI-7.6 AI-8.3 Ovplyvnenie cez užívate ské AI-7.1 rozhranie Ovplyvnenie cez komunika né AI7.1 rozhranie AI-8.1 Ochrana proti náhodným alebo AI-7.1, AI-7.2 neúmyselným zmenám AI-8.4 Ochrana proti úmyselným AI-7.1 zmenám AI-8.2, AI-8.3, AI-8.4 Ochrana parametre AI-7.1 AI-8.2, AI-8.3, AI-8.4 Autentickos softvéru AI-7.1, AI-7.2, AI-7.6 a prezentácia výsledkov AI-8.3 AI-10.2, AI-10.3, AI-10.4 Ovplyvnenie iným softvérom AI-7.6

L1

Rozšírenie L Kompletnos uchovávaných dát

U2 U3 U4 U5 U6 U7 U8

2

)

AI7.1 AI-8.4 AI-10.2

MID Význam

Informácie nesené a priložené k meradlu Zhoda hodnotenia Technická dokumentácia Vhodnos Ochrana proti zneužitiu Vhodnos Vhodnos Ochrana proti zneužitiu Vhodnos Ochrana proti zneužitiu Vhodnos 2 Ochrana proti zneužitiu Vhodnos Ochrana proti zneužitiu Informácie nesené a priložené k meradlu Zhoda hodnotenia Technická dokumentácia Vhodnos Ochrana proti zneužitiu Vhodnos Vhodnos Ochrana proti zneužitiu Vhodnos Ochrana proti zneužitiu Vhodnos Ochrana proti zneužitiu Vhodnos Ochrana proti zneužitiu Vhodnos Ochrana proti zneužitiu Indikácia výsledku Vhodnos Vhodnos Ochrana proti zneužitiu Indikácia výsledku

Poznámka: Pokia ide o obsahy, lánok 7.1 smernice MID-Prílohy I nie je vydaný ako „Vhodnos “ ale ako „Ochrana proti zneužitiu“ (paragraf 8)


WELMEC WG7

. L2 L3 L4 L5 L6 L7 L8 Lx

T1 T2 T3 T4 T5 T6 T7 T8

Požiadavka Význam

Rozšírenie T Úplnos prenesených dát

AI-7.1 AI-8.4 Ochrana proti náhodným alebo AI-7.1, AI-7.2 neúmyselným zmenám AI-8.4 Integrita dát AI-7.1 AI-8.4 Autentickos prenesených dát AI-7.1 AI-8.4 Dôveryhodnos k ú ov AI-7.1 AI-8.4 Zaobchádzanie s poškodenými AI-7.1 datami AI-8.4 Oneskorenie pri prenose AI-7.1 AI-8.4 Dostupnos služieb prenosu AI-7.1 AI-8.4 Rozšírenie S Realizácia rozdelenia softvéru

S2

Zmiešané indikácie

S3

Ochrana softvérového rozhrania

D3 D4 D5

lánok / Príloha . (AI = Príloha I)

WELMEC 7.2, vydanie 2 MID Význam

Ochrana proti náhodným alebo AI-7.1, AI-7.2 Vhodnos neúmyselným zmenám AI-8.4 Ochrana proti zneužitiu Integrita dát AI-7.1 Vhodnos AI-8.4 Ochrana proti zneužitiu Autentickos uložených dát AI-7.1 Vhodnos AI-8.4 Ochrana proti zneužitiu AI-10.2 Indikácia výsledku Dôveryhodnos k ú ov AI-7.1 Vhodnos AI-8.4 Ochrana proti zneužitiu Na ítanie uložených dát AI-7.2 Vhodnos AI-10.1, AI-10.2, AI-10.3, Ochrana proti zneužitiu AI-10.4 Automatické ukladanie AI-7.1 Vhodnos AI-8.4 Ochrana proti zneužitiu Kapacity pamäte a kontinuita AI-7.1 Vhodnos Všetko z rozšírenia L AI-11.1 alšie spracovanie dát na ukon enie obchodnej transakcie

S1

D1 D2


AI-7.6 AI-10.1 AI-7.1, AI-7.2, AI-7.6 AI-10.2 AI-7.6

Rozšírenie D Mechanizmus s ahovania AI-8.2, AI-8.4 Autentickos s ahovaného softvéru AI-7.6 AI-8.3, AI-8.4 AI-12 Integrita s ahovaného softvéru AI-7.1 AI-8.4 Jednozna nos legálne AI-7.1, AI-7.6 relevantného s ahovaného AI-8.2, AI-8.3 softvéru AI-12 Súhlas k s ahovaniu AI-7.1, AI-7.6 Rozšírenie I (Špecifické softvérové požiadavky na meradlo)


Vhodnos Ochrana proti zneužitiu Vhodnos Ochrana proti zneužitiu Vhodnos Ochrana proti zneužitiu Vhodnos Ochrana proti zneužitiu Vhodnos Ochrana proti zneužitiu Vhodnos Ochrana proti zneužitiu Vhodnos Ochrana proti zneužitiu Vhodnos Ochrana proti zneužitiu Vhodnos Indikácia výsledku Vhodnos Indikácia výsledku Vhodnos Ochrana proti zneužitiu Vhodnos Ochrana proti zneužitiu Zhoda hodnotenia Vhodnos Ochrana proti zneužitiu Vhodnos Ochrana proti zneužitiu Zhoda hodnotenia Vhodnos

WELMEC WG7

. I1-1, I2-1, I3-1, I4-1 I1-2, I2-2, I3-2, I4-2 I1-3, I2-3, I3-3, I4-3 I1-4, I2-4, I3-4, I4-4 I1-5, I2-5, I3-5, I4-5 I1-6, I2-6, I3-6, I4-6 I2-7


Požiadavka Význam

lánok / Príloha . (AI = Príloha I)

WELMEC 7.2, vydanie 2 MID Význam

Odhalenie poruchy

AI-6 MI-001-7.1, MI-002-3.1, MI-003-4.3.1, MI-004-4

Spo ahlivos Špecifické požiadavky na distribu né meradlá

Prostriedky na zálohovanie

AI-6 MI-001-7.1, MI-002-3.1, MI-003-4.3.1, MI-004-4


Prostriedky na budenie a obnovenie

AI-6 MI-001-7.1, MI-002-3.1, MI-003-4.3.1, MI-004-4


Interné rozhodnutie

MI-002-5.3, MI-003-5.2

Špecifické požiadavky na distribu né meradlá

Zabránenie kumulatívnych hodnôt

zresetovaniu AI-8.5 nameraných

Indikácia pre zákazníkov

Ochrana proti zneužitiu

AI-7.2 AI-10.5

Ochrana proti zneužitiu Indikácia výsledku Špecifické plynomery Špecifické plynomery

I2-9

Prijate né riešenie pre MI-002-5.2 monitorovanie životnosti batérie Prijate né riešenie pre MI-002-9.1 monitorovanie prepo ítava a objemu plynu iastkové skúšanie MI-002-5.5

I6-1

Odhalenie poruchy

MI-006-IV, MI-006-V

I6-2

Prostriedky na zálohovanie

MI-006-IV, MI-006-V

Diskontinuálne s ítavacie váhy Diskontinuálne s ítavacie váhy

I2-8

Špecifické plynomery

požiadavky

na

požiadavky

na

požiadavky

na

a kontinuálne a kontinuálne

13.2 Interpretácia lánkov a príloh MID k Softvérovým požiadavkám MID Príru ka k softvéru

MID lánok / Príloha . (AI = Príloha I) 1, 2, 3 4 (b) 5 až 9

Význam

as

Komentár

Požiadavka .

lánku

Nesúvisí so softvérom Definície, Úprava Prenos legálne relevantných dát ... iastkových zostáv Základné príru ky aplikované iastkové zostavy Nesúvisí so softvérom 116


T.x na P, U

WELMEC WG7


WELMEC 7.2, vydanie 2 Príru ka k softvéru

MID lánok / Príloha . (AI = Príloha I)

Význam

as

10

lánku

Technická dokumentácia

11 až 27 AI-1 až AI-5

Komentár

Dokumentácia návrhu, výroby a operácii. Umož uje posúdi zhodu. Všeobecný popis meradla. Popis elektronických zariadení s ná rtmi, logickými diagramami, všeobecnými P1, U1 softvérovými informáciami. Umiestnenie plomby alebo zna ky. Podmienky na kompatibilitu s rozhraním a iastkovou zostavou. Nesúvisí so softvérom

Príloha I

Nesúvisí so softvérom

Spo ahlivos

Odhalenie poruchy, zálohovanie, Obnovenie, reštartovanie

AI-7

Vhodnos

Neexistujú žiadne vlastnosti, ktoré by umož ovali ne estné použitie: minimálna možnos neúmyselného zneužitia.

AI-8

Ochrana proti zneužitiu

AI-6

AI-8.1

Neexistuje ovplyvnenie pripojením ostatných zariadení.

AI-8.2

Zabezpe enie; evidencia a intervencia

AI-8.3

Identifikácia softvéru; evidencia intervencie

AI-8.4

Ochrana uložených alebo prenesených dát

AI-8.5

Nezresetovaniu kumulatívnych registrov

AI-9

Informácie nesené a priložené k meradlu

AI-9.1 AI-9.2 AI-9.3 AI-9.4 až AI9.8 AI-10 AI-10.1

Požiadavka .

I1-1 až I1-3, I2-1 až I2-3, I3-1 až I3-3, I4-1 až I4-3, I6-1 až I6-3, P3 – P7, U3 – U8, L1 – L5, L7, L8 T1 – T8 S2, D3, D4 P4, U4 P6, P7, U6, U7, D1, D4 P2, P6, P7, U2, U6, U7, U8, D2, D4 P5 – P7, U5 – U7, L1 – L5, T1 – T8 D1 – D3 I1-5, I2-5, I3-5, I45

Kapacita merania L8 (zvyšné poznámky nerelevantné pre softvér) Nesúvisí so softvérom Inštrukcie pre montáž, ..., podmienky pre P1, U1 kompatibilitu s rozhraním, iastkovými zostavami alebo meradlami Nesúvisí so softvérom

Indikácia výsledku

Indikácia prostredníctvom zobrazenia


U8, L6, S2

WELMEC WG7


WELMEC 7.2, vydanie 2 Príru ka k softvéru


Význam

as

lánku

AI-10.2 AI-10.3 AI-10.4 AI-10.5 AI-11

alšie spracovanie dát na ukon enie obchodnej transakcie

AI-11.1 AI-11.2 AI-12 A1 až H1 MI-001-1 až MI-001-6

Zhoda hodnotenia Prílohy A1 až H1

Záznam z nameraných výsledkov pomocou trvácnych prostriedkov. Trvácny dôkaz z nameraných výsledkov a informácia na identifikáciu transakcie. Okamžité hodnotenie zhody s požiadavkami smernice MID

U8, L1, L4, L6, S2 U8, L6, S2 U8, S2 I1-6, I2-6, I3-6, I46

L1 – L8 L1, L6 P1, P2, U1, U2, D2, D4

Žiadne požiadavky na vlastnosti meradla Nesúvisí so softvérom Odhalenie poruchy Prostriedky na zálohovanie Prostriedky na budenie a obnovenie

MI-001-7.1.3 až MI-001-9

I1-1 až I1-3

Nesúvisí so softvérom Príloha MI-002 Nesúvisí so softvérom Odhalenie poruchy Prostriedky na zálohovanie Prostriedky na budenie a obnovenie

MI-002-3.1 MI-002-3.1.3 až MI-002-5.1

I2-1 až I2-3

Nesúvisí so softvérom Prijate né riešenie pre monitorovanie životnosti batérie Interné rozhodnutie

MI-002-5.2 MI-002-5.3 MI-002-5.4 až MI-002-8 MI-002-5.5 MI-002-5.6 až MI-002-8

I2-7 I2-4

Nesúvisí so softvérom iastkové skúšanie

I2-9

Nesúvisí so softvérom Prijate né riešenie pre monitorovanie životnosti batérie

MI-002-9.1 MI-002-9.2 až MI-002-10 MI-003-1 až MI-003-4.2

alebo trvalého záznamu. Váha výsledku, nezamenenie s alšími údajmi. Výtla ok alebo záznam ahko itate ný a permanentný. Pre priamy predaj: prezentácia výsledkov z oboch strán. Pre distribu né meradlá: displej pre zákazníka.

Požiadavka .

Príloha MI-001

MI-001-7.1.1, MI-001-7.1.2

MI-002-1 až MI-002-2

Komentár

Nesúvisí so softvérom Príloha MI-003 Nesúvisí so softvérom


I2-8

WELMEC WG7


Príru ka k softvéru


Význam

as

lánku

MI-003-4.3 MI-003-5.1 MI-003-5.2 MI-003-5.3 až MI-003-7 MI-004-1 až MI-004-4.1


Komentár

Odhalenie poruchy Prostriedky na zálohovanie Prostriedky na budenie a obnovenie Nesúvisí so softvérom Interné rozhodnutie

Požiadavka .

I3-1 až I3-3 I3-4

Nesúvisí so softvérom Príloha MI-004 Nesúvisí so softvérom Odhalenie poruchy Prostriedky na zálohovanie Prostriedky na budenie a obnovenie

MI-004-4.2 MI-004-4.3 až MI-004-7

I4-1 až I4-3

Nesúvisí so softvérom Príloha MI-005

MI-006-IV až MI-006-V

Príloha MI-006 Diskontinuálne a kontinuálne s ítavacie váhy

Odhalenie poruchy Prostriedky na zálohovanie

Príloha MI-007

Príloha MI-008

Príloha MI-009

Príloha MI-010


I6-1 až I6-2

WELMEC WG7

14



Literatúra

[1]

Smernica 2004/22/ES Európskeho parlamentu a Rady z 31. marca 2004 o meradlách. Úradný vestník Európskej únie L 135/1, 30.4.2004

[2]

Požiadavky na softvér a príru ka o validácii, verzia 1.00, 29. október 2004, Európsky vývoj siete „MID-Softvér“, íslo kontraktu G7RT-CT-2001-05064, 2004

[3]

Požiadavky na softvér na základe smernice o meradlách, WELMEC 7.1, Vydanie 2, 2005

15

História revízie

Vydanie

Dátum

Dôležité zmeny

1

Máj 2005

Prvé vydanie príru ky

2

Apríl 2007 Doplnenie a vylepšenie termínov v asti 2 Edita né zmeny v astiach 4.1 a 5.1 Doplnenie klasifikácie pre softvérovú identifikáciu v asti 4.2, požiadavky P2 a asti 5.2, požiadavky U2 Doplnenie v požiadavke L8, ur enie poznámky 1. Doplnenie vysvetlenia k požiadavke S1, ur enie poznámky1. Nahradenie požiadavky D5 pripomienkou. Zmena triedy rizika pre meracie zostavy na kvapaliny okrem vody. Zmena triedy rizika pre váhy. Viacero malých edita ných zmien v dokumente. Pridanie tejto tabu ky revízie.

Tabu ka 15-1: História revízie


WELMEC WG7

16



Index

kontrolný záznam 7, 22, 31, 60, 107 autentifikácia 7, 38, 47, 58, 109 autentickos 9, 32, 33, 38, 39, 41, 40, 47, 56, 58, 105, 106, 108, 109 základná konfigurácia 7, 8, 12, 15, 34, 35, 51, 55, 100, 101 jednoú elové 7, 13, 17, 36, 37, 53, 57 certifikácia k ú ov 9 kontrolný záznam 13, 14, 62, 99, 101, 102, 103, 104, 105, 106, 107 kontrolný sú et 8, 17, 20, 25, 29, 30, 32, 36, 37, 38, 45, 46, 59 obvod 22, 74, 79, 101 príkaz 15, 16, 17, 18, 19, 20, 24, 25, 26, 27, 28, 41, 54, 102, 104 komunika né rozhranie 7, 19, 27, 104, 108 dôveryhodnos 39, 48, 109 krížové referencie 108 dátová doména 54 tok dát 18, 20, 26, 28, 52, 54, 101, 106 meradlá rozmerov 94 priama dôvera 39, 48 dokumentácia 13, 16, 17, 18, 19, 20, 21, 22, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 35, 36, 37, 38, 39, 40, 41, 42, 44, 45, 46, 47, 48, 49, 50, 52, 53, 54, 56, 57, 58, 59, 60, 63, 65, 66, 69, 70, 71, 72, 75, 76, 77, 80, 81, 86, 87, 91, 96, 97, 98, 101, 104, 107, 108, 111 elektromery 74, 75, 77, 78, zabudovaný 15, 34, 62, 90, 100, 101 íta udalostí 7, 22, 60, 71 analyzátory výfukových plynov 95 odhalenie poruchy 20, 62, 64, 68, 74, 79, 86, 109, 110, 111, 112, 113, plynomer 68, 69, 70, 72, 73, 110 hash algoritmus 9, 25, 37, 46 mera tepla 79, 80, 82 identifikácia 8, 16, 17, 22, 24, 25, 32, 35, 38, 40, 44, 47, 52, 58, 60, 67, 73, 77, 82, 101, 104, 107, 108, 111 indikácia 53, 70, 71, 76, 88, 100, 108, 109, 110, 111 integrita 7, 9, 37, 38, 40, 46, 47, 56, 58, 59, 108, 109 konfigurácia IT 7, 10, 12, 103 k ú ové ovládanie 18, 26 právna kontrola 8 legálne relevantný 7, 8, 12, 15, 23, 34, 43, 51, 55, 60, 62, 67, 73, 77, 82, 88, 91, materializované miery 93 pamä 21, 22, 30, 34, 62, 71, 104 MID 8, 9, 10, 12, 61, 64, 66, 68, 70, 73, 74, 76, 78, 79, 81, 83, 84, 85, 90, 93, 94, 95, 97,

100, 108, 110 sie 8, 15, 16, 23, 24. 34, 36, 43, 46, 47, 48, 50, 106 uzavretá 7, 23, 43, 46, 47, 48, 55, 62 otvorená 8, 23, 43, 46, 55, 62 notifikovaná osoba (NO) 13, 17, 25, 42 opera ný systém 15, 23, 24, 26, 27, 29, 30, 34, 51, 62, 103 parameter 7, 8, 20, 22, 24, 29, 31, 34, 51, 52, 54, 63, 66, 67, 70, 71, 73, 76, 77, 81, 82, 88, 89, 91, 96, 104, 106, 108 typovo-špecifický 8, 16, 22, 24, 31, 63, ochranné rozhranie 53, 54 štruktúra verejného k ú a 9, 39, 48, trieda rizika 8, 9, 12, 13, 14, 30, 61, 63, 67, 73, 78, 82, 83, 89, 92, 94, 95, 96, 97, 98, 101 zabezpe i 7, 21, 22, 30, 31, 56, 58, 104, 107 podpis 9, 37, 38, 39, 40, 41, 46, 47, 48, 49, 58 algoritmický 9, 30, 37, 46, elektronický 9, 37, 46, 58, k ú 9, s ahovanie softvéru 7, 8, 10, 15, 19, 21, 27, 52, 56, 60 rozdelenie softvéru 8, 10, 12, 15, 33, 51, 52, 55, 66, 72, 77, 81 nízka úrove 51 sofistikované nástroje 37, 39, 46, 48, 96, 105, 106 špecifické požiadavky 10, 12, 16, 34, 40, 42, 64, 68, 74, 79, 83, 84, 90, 93, 94, 95, 101, 105, 106, 107, 109, 110 napáli 32 ukladanie 7, 8, 15, 20, 23, 29, 31, 34, 35, 36, 37, 38, 39, 40, 41, 42, 48, 52, 62, 65, 69, 70, 75, 76, 80, 86, 87, 91, 103 integrované 7, 15, 34, 37, 103 dlhodobé 7, 8, 10, 12, 34, 35, 42, 62, 67, 73, 77, 82, 90, 100, 101, 105 iastková zostava 8, podprogram 52, 54, 65, 69, 75, 80, 86 TEC 8, 17, 25, 32, 56, 107 taxameter 90, 91, 92, správa o skúške 99, 100, 103, 104, 107 jednozna nos 60 prenášanie 7, 8, 10, 12, 15, 19, 27, 42, 43, 44, 45, 46, 47, 49, 50, 52, 103, 106 dôveryhodné centrum 9, 39, 48, typ P 7, 8, 10, 12, 15, 16, 23, 34, 55, 62, 64, 67, 68, 73, 74, 78, 79, 82, 84, 89, 90, 92, 94, 95, 101, 104 typ U 8, 10, 12, 15, 23, 24, 34, 43, 51, 55, 62, 67, 73, 78, 82, 84, 89, 90, 92, 94, 95, 101, 104 užívate ské rozhranie 8, 15, 16, 18, 23, 24, 26,


WELMEC WG7


34, 41, 62, 104, validácia 9, 13, 100, 101, 107 vodomer 64, 65, 67 váha 41, 61, 84, 88, 89



ES o meradlách)

Recommend Documents