5. izdanje WELMECWELMEC 7.2 5. izdanje WELMEC Evropska saradnja u oblasti zakonske metrologije...

WELMEC 7.2 5. izdanje

WELMEC Evropska saradnja u oblasti zakonske metrologije

Vodič za softver (Direktiva 2004/22/EC za merila)

(Izmene u poređenju sa 4. izdanjem označene su plavom bojom)

Mart 2012.

WELMEC WG7 Vodič za softver WELMEC 7.2, 5. izdanje

2

WELMEC Evropska saradnja u oblasti zakonske metrologije

WELMEC predstavlja saradnju između službi zakonske metrologije sa državama članicama Evropske unije i EFTA. Ovaj dokument je jedan od brojnih vodiča koje je objavio WELMEC kako bi proizvođačima merila i odgovornim notifikovanim telima dao uputstva za procenu usaglašenosti njihovih proizvoda. Vodiči su isključivo savetodavnog karaktera i kao takvi ne nameću ograničenja ili dodatne tehničke zahteve mimo onih koji su sadržani u odgovarajućim direktivama. Mogu se prihvatiti alternativni pristupi, ali navedene smernice u ovom dokumentu predstavljaju prihvaćen stav WELMEC-a o tome kako treba slediti najbolje prakse.

Objavio:

WELMEC sekretarijat

Thijsseweg 11 NL - 2629 JA Delft Holandija E-pošta: [email protected] Telefon: + 31 15 269 17 09 fax: + 31 15 285 05 07 Web lokacija: www.welmec.org


3

Vodič za softver

(Direktiva 2004/22/EC za merne instrumente)

Sadržaj

Predgovor ............................................................................................................................ 5

1 Uvod ................................................................................................................................. 6

2 Terminologija .................................................................................................................... 7

3 Kako da koristite ovaj vodič ............................................................................................ 10

3.1 Opšta struktura vodiča ............................................................................................. 10

3.2 Kako da izaberete odgovarajuće delove vodiča ....................................................... 12

3.3 Kako da radite sa tabelom zahteva .......................................................................... 13

3.4 Kako treba raditi sa kontrolnim listama .................................................................... 13

4 Osnovni zahtev za ugrađeni softver u namenskim merilima (Tip P) ............................... 14

4.1 Tehnički opis ............................................................................................................ 14

4.2 Posebni zahtevi za tip P ........................................................................................... 15

5 Osnovni softverski zahtevi za merila koja koriste univerzalni računar (Tip U) ................ 22

5.1 Tehnički opis ............................................................................................................ 22

5.2 Posebni softverski zahtevi za tip U .......................................................................... 23

6 Dodatak L: Dugoročno skladištenje mernih podataka .................................................... 33

6.1 Tehnički opis ............................................................................................................ 33

6.2 Posebni softverski zahtevi za dugoročno skladištenje ............................................. 34

7 Dodatak T: Prenos mernih podatak putem komunikacione mreže ................................. 42

7.1 Tehnički opis ............................................................................................................ 42

7.2 Posebni softverski zahtevi za prenos podataka ....................................................... 43

8 Dodatak S: Razdvajanje softvera ................................................................................... 50

8.1 Tehnički opis ............................................................................................................ 50

8.2 Posebni softverski zahtevi za razdvajanje softvera .................................................. 51

9 Dodatak D: Preuzimanje softvera koji podleže zakonskoj kontroli .................................. 54

9.1 Tehnički opis ............................................................................................................ 54

9.2 Posebni softverski zahtevi ....................................................................................... 55

10 Dodatak I: Softverski zahtevi specifični za instrument .................................................. 60

10.1 Vodomeri ............................................................................................................... 62

10.2 Gasomeri i uređaji za konverziju zapremine .......................................................... 67


4

10.3 Brojila aktivne električne energije........................................................................... 74

10.4 Merila toplotne energije .......................................................................................... 80

10.5 Merni sistemi za neprekidno i dinamičko merenje količina tečnosti koje nisu voda 85

10.6 Merila ..................................................................................................................... 86

10.7 Taksimetri .............................................................................................................. 92

10.8 Materijalizovane mere ............................................................................................ 95

10.9 Merila dimenzije ..................................................................................................... 96

10.10 Analizatori izduvnih gasova ................................................................................. 97

11 Definicija klase rizika .................................................................................................... 98

11.1 Opšti princip ........................................................................................................... 98

11.2 Opis nivoa za zaštitu, pregled i usaglašenost ........................................................ 98

11.3 Nastajanje klase rizika ........................................................................................... 99

11.4 Tumačenje klasa rizika .......................................................................................... 99

12 Obrazac za izveštaj o testiranju (uključujući kontrolnu listu) ....................................... 100

12.1 Obrazac opšteg dela izveštaja o testiranju .......................................................... 101

12.2 Aneks 1 izveštaja o testiranju: Kontrolne liste kao podrška izboru odgovarajućih

skupova zahteva .......................................................................................................... 104

12.3 Aneks 2 izveštaja o testiranju: Posebne kontrolne liste za odgovarajuće tehničke

delove .......................................................................................................................... 105

12.4 Informacije koje treba da se uključe u sertifikat o ispitivanju tipa ......................... 108

13 Unakrsno upućivanje za softverske uslove MID direktive na članove i anekse MID

direktive ........................................................................................................................... 109

13.1 Navedeni softverski zahtevi, upućivanje na MID direktivu ................................... 109

13.2 Tumačenje članova i aneksa iz MID direktive sa softerskim zahtevima iz MID

direktive ....................................................................................................................... 112

14 Reference i literatura .................................................................................................. 115

15 Istorija izmena ............................................................................................................ 115

16 Indeks ......................................................................................................................... 116


5

Predgovor

Vodič koji čitate zasnovan je na „Vodiču za softverske zahteve i validaciju“, Verzija 1.00 od 29. oktobra 2004. godine koji je sastavila i objavila Evropska mreža za razvoj „MID-Softver“. Mrežu je od januara 2002. do decembra 2004. godine podržavala Evropska komisija pod brojem ugovora G7RT-CT-2001-05064.

Vodič je isključivo savetodavnog karaktera i kao takav ne nameće ograničenja ili dodatne tehničke zahteve mimo onih koji su sadržani u odgovarajućim MID direktivama. Mogu se prihvatiti alternativni pristupi, ali navedene smernice u ovom dokumentu predstavljaju prihvaćen stav WELMEC-a o tome kako treba slediti najbolje prakse.

Iako je Vodič orijentisan na instrumente koji su obuhvaćeni uredbama MID direktive, rezultati su opšte prirode i primenjivi su van njega.

4. izdanje i najnovije 5. izdanje razmatraju dodatno iskustvo stečeno na osnovu primene Vodiča.


6

1 Uvod

Ovaj dokument pruža smernice svima onima koji se bave primenom Direktive za merila (MID), pogotovo za merila koja imaju softver. On se obraća kako proizvođačima merila, tako i notifikovanim telima koja su odgovorna za procenu usaglašenosti merila.

Čitanjem ovog Vodiča može se pretpostaviti da postoji usaglašenost sa zahtevima koji se nalaze u MID direktivi, a koji se odnose na softver. Nadalje se može pretpostaviti da svi naknadno obavešteni organi prihvataju ovaj vodič kao usklađeno tumačenje Direktive o merilima koja se odnosi na softver. Kako bismo pokazali u kakvoj su vezi definisani zahtevi iz ovog Vodiča sa odgovarajućim zahtevima MID direktive, o ovaj Vodič smo umetnuli unakrsna upućivanja u vidu Aneksa (Poglavlje 13).

Prethodnik ovog Vodiča je bio Vodič 7.1 koji je sastavila WELMEC Radna grupa 7. Oba Vodiča su zasnovana na istim principima i izvedena iz zahteva Direktive o merilima. Vodič 7.1 je prepravljen i dalje postoji (2. izdanje), ali sada služi samo u informativne svrhe, dok je Vodič 7.2 taj koga preporučuje WELMEC za izradu softvera, ispitivanje i validaciju merila koje kontroliše softver, a koja su u skladu sa Direktivom o merilima.

Najnovije informacije koje se odnose na Vodiče i rad WELMEC Radne grupe 7 dostupne su na web lokaciji: http://www.welmecwg7.ptb.de.


7

2 Terminologija

Terminologija koja je objašnjena u ovom odeljku opisuje reči koji se koriste u ovom vodiču. Data su pozivanja na standardne ili sve druge izvore, ako je definicija potpuna ili su najvažniji delovi uzeti iz nje.

Prihvatljivo rešenje: Izrada ili princip softverskog modula, hardverske jedinice ili funkcije koje se smatraju da su u skladu sa određenim zahtevima. Prihvatljivo rešenje nudi primer kako određeni zahtevi mogu da se ispune. Ovo ne prejudicira bilo koje drugo rešenje koje takođe ispunjava zahteve.

Hronološki zapis revizija: Softverski brojač (npr: „brojač događaja“) i/ili zapis sa informacijama (npr: „sistem za evidenciju događaja“) o izmenama na softveru ili parametrima koji podležu zakonskoj kontroli.

Autentifikacija: Verifikacija utvrđenog ili navodnog identiteta korisnika, procesa ili uređaja.

Osnovna konfiguracija: Izrada merila u odnosu na osnovnu arhitekturu. Postoje dve različite osnovne konfiguracije: namenska merila i merila koja koriste univerzalni računar. Termini su shodno ovome primenjivi i na podsklopove.

Namenska merila (tip P): Merilo koje je specijalno koncipirano i napravljeno za konkretni zadatak. Kompletna softverska aplikacija je shodno tome izrađena za svrhe merenja. Za više informacija pogledajte Poglavlje 4.1.

Zatvorena mreža: Mreža nepromenjivog broja učesnika sa poznatim identitetom, funkcionalnošću i lokacijom (pogledajte takođe Otovorena mreža).

Interfejs za komunikaciju: Elektronski, optički, radio ili drugi tehnički interfejs koji omogućava automatsko prolaženje informacija među delovima merila, pod-sklopovima ili eksternim uređajima.

Parametri specifični za uređaj: Parametar koji podleže zakonskoj kontroli sa vrednostima koje zavisi od svakog instrumenta. Parametri specifični za uređaj obuhvataju parametre kalibracije (npr. podešavanje mernog opsega, ostala podešavanja ili korekcije) i parametre konfiguracije (npr. maksimalna vrednost, minimalna vrednost, jedinice merenja, itd.). Oni mogu da se podešavaju ili biraju samo kada je instrument u posebnom režimu rada. Parametri specifični za uređaj mogu da se klasifikuju na one koji mogu da se osiguraju (nepromenjivi) i na one kojima može da pristupa (podesivi parametri) ovlašćena osoba, npr: vlasnik instrumenta ili njegov prodavac.

Nepromenjivi softver: Deo softvera koji je definisan kao nepromenjiv pri ispitivanju tipa, tj. promenjiv samo pri odobrenju notifikovanog tela. Nepromenjivi deo je u svakom pojedinačnom instrumentu isti.

Integrisano skladište: Neprenosivo skladište koje je deo merila, npr. RAM, EEPROM, čvrsti disk.

Integritet podataka i softvera: Garancija da podaci i softver nisu podvrgnuti bilo kakvim neovlašćenim izmenama prilikom njihovog korišćenja, prenosa ili skladištenja.

IT konfiguracija: Izrada merila u odnosu na IT funkcije i karakteristike koje su – u pogledu zahteva – nezavisne od funkcije merenja. Postoje četiri IT konfiguracije koje se razmatraju u ovom vodiču: dugotrajno skladištenje mernih podataka, prenos mernih podataka, preuzimanje softvera i razdvajanje softvera (pogledajte takođe Osnovna konfiguracija). Zahtevi se shodno ovome primenjuju i na pod-sklopove.

Parametar koji podleže zakonskoj kontroli: Parametar merila ili pod-sklopa koji je predmet zakonske kontrole. Razlikujemo sledeće tipove parametara koji podležu zakonskoj kontroli: parametri specifični za tip i parametri specifični za uređaj.

Softver koji podleže zakonskoj kontroli: Programi, podaci i parametri specifični za tip koji pripadaju merilu ili pod-sklopu, i koji definišu ili ispunjavaju funkcije koje su predmet zakonske kontrole.


8

Dugoročno skladište za merne podatke: Skladište koje se koristi za čuvanje mernih podataka spremnih nakon završenog merenja za kasnije svrhe koje podležu zakonskoj kontroli (npr: zaključenje komercijalne transakcije).

Merilo: Bilo koji uređaj ili sistem koji ima funkciju merenja. Pridev „merni“ se izostavlja ukoliko može da se isključi zabuna. [MID, Članak 4]

Merila koja koriste univerzalni računar (tip U): Merila koja se sastoje od računara opšte namene, obično sistema koji je zasnovan na računaru radi obavljanja funkcija koje podležu zakonskoj kontroli. Sistem tipa U se pretpostavlja ako nisu ispunjeni zahtevi za namensko merilo (tip P).

Otvorena mreža: Mreža arbitrarnih učesnika (uređaja sa proizvoljnim funkcijama). Broj, identitet i lokacija učesnika može biti dinamički i nepoznat ostalim učesnicima (pogledajte takođe Zatvorena

mreža).

Klasa rizika: Klasa za tipove merila sa uporedivom procenom rizika.

Preuzimanje softvera: Proces automatskog prenosa softvera do odredišnog merila ili hardverske jedinice pomoću svih tehničkih sredstava iz lokalnog ili daljinskog izvora (npr. zamenjivog uređaja za čuvanje podataka, prenosivog računara, udaljenog računara) putem proizvoljnih veza npr. direktnih linkova, mreža).

Identifikacija softvera: Sekvenca čitljivih znakova softvera koji su neraskidivo povezani sa softverom (npr. broj verzije, kontrola).

Razdvajanje softvera: Nedvosmisleno razdvajanje softvera na softver koji podleže zakonskoj

kontroli i softver koji ne podleže zakonskoj kontroli. Ako nema razdvajanja sofvera, smatra se da celokupan softver podleže zakonskoj kontroli.

Pod-sklop: Hardverski uređaj (hardverska jedinica) koja funkcioniše samostalno i zajedno sa ostalim pod-sklopovima (ili mernim instrumentima) sa kojima je kompatibilan [MID direktiva, Član 4] sačinjava merilo.

Prenos mernih podataka: Prenos mernih podataka putem mreža za komunikaciju ili ostalih sredstava ka daljinskom uređaju na kom se dalje obrađuju i/ili koriste u zakonski regulisane svrhe.

TEC: Sertifikat o ispitivanju tipa.

Specifičan parametar za tip: Softver koji podleže zakonskoj kontroli sa vrednošću koja isključivo zavisi od vrste instrumenta. Specifični parametri za tip deo su softvera koji podleže zakonskoj

kontroli. Oni su nepromenjivi pri ispitivanju tipa instrumenta.

Korisnički interfejs: Interfejs koji obrazuje deo instrumenta ili mernog sistema koji omogućava prenos informacija između ljudskog korisnika i merila ili njegovog hardvera ili softverskih delova, kao što su npr. prekidač, tastatura, miš, ekran, monitor, štampač, ekran na dodir. Validacija (provera valjanosti): Potvrda ispitivanjem i pružanjem objektivnih dokaza (tj. informacija koje mogu da se dokažu kao istinite, koje su zasnovane na činjenicama dobijenim posmatranjem, merenjem, testriranjem itd.) da su ispunjeni posebni zahtevi za predviđenu upotrebu. To su u ovom slučaju zahtevi koji se odnose na MID direktivu.

Sledeće definicije su prilično specifične. Koriste se samo u nekim dodacima i za klase rizika D ili više.

Hash algoritam: Algoritam koji komprimuje sadržaj bloka podataka u broj sa definisanom dužinom (hash kôd) tako da izmena bilo kog bita u bloku podataka u praksi vodi do drugog hash kôda. Hash algoritmi su odabrani tako da teoretski postoji veoma mala verovatnoća da dva različita bloka podataka imaju isti hash kôd.

Algoritam potpisa: Algoritam za šifrovanje koji šifruje (kodira) čisti tekst u šifrovani teks (šifrovani ili tajni tekst) korišćenjem ključa za šifrovanje potpisa i koji omogućava dekodiranje šifrovanog teksa ako je odgovarajući ključ za dešifrovanje potpisa dostupan.

Ključ za šifrovanje potpisa: Bilo koji broj ili niz znakova koji se koriste za kodiranje i dekodiranje informacija. Postoje dve različite klase ključa za šifrovanje potpisa: simetrični i asimetrični sistemi ključa. Simetrični ključ podrazumeva korišćenje istog ključa od strane pošiljaoca i primaoca. Sistem


9

ključa se naziva asimetričnim ako su ključevi za pošiljaoca i primaoca različiti, ali kompatibilni. Obično je ključ pošiljaoca poznat pošiljaocu, a ključ primaoca je javan u definisanom okruženju.

Sistem javnog ključa (PKS): Par od dva različita ključa za šifrovanje potpisa, od kojih se jedan zove tajni ključ, a drugi javni ključ. Da biste proverili integritet i autentičnost informacija, hash vrednost informacija koju generiše hash algoritam je šifrovana sa tajnim ključem pošiljaoca radi kreiranja potpisa, koji kasnije dešifruje primalac koristeći javni ključ pošiljaoca.

PKI infrastruktura: Organizacija koja garantuje pouzdanost sistema javnog ključa. Ovo obuhvata odobrenje i distribuciju digitalnih sertifikata svim članovima koji učestvuju u razmeni informacija.

Sertifikacija ključeva: Proces vezivanja vrednosti javnog ključa sa pojedincem, organizacijom ili drugim subjektom.

Elektronski potpis: Kratak kôd (potpis) koji je nedvosmisleno dodeljen tekstu, bloku podataka ili binarnoj datoteci softvera radi dokazivanja integriteta i autentičnosti zapamćenih ili prenesenih podataka. Potpis se kreira pomoću algoritma potpisa i tajnog ključa za šifrovanje potpisa. Generisanje elektronskog potpisa se obično sastoji iz dva koraka: (1) hash algoritam prvo komprimuje sadržaj informacija koji treba da bude potpisan u kratkoj vrednosti, (2) zatim algoritam potpisa kombinuje ovaj broj sa tajnim ključem kao bi se potpis generisao.

Centar za pouzdanost: Udruženje koje s pouzdanošću generiše, čuva i izdaje informacije o autentičnosti javnih ključeva osobama ili drugim identitetima npr. merilima.


10

3 Kako da koristite ovaj vodič

Ovaj odeljak opisuje organizaciju vodiča i objašnjava kako ga treba koristiti.

3.1 Opšta struktura vodiča Vodič je organizovan u obliku strukturiranih skupova tabela sa zahtevima. Opšta struktura vodiča prati klasifikaciju merila na osnovne konfiguracije i klasifikaciju takozvanih IT konfiguracija. Skup zahteva je dopunjen posebnim zahtevima za instrumente.

Prema tome, postoje tri vrste obaveznih skupova: 1. Zahtevi za dve osnovne konfiguracije merila (pod nazivom tip P i U) 2. Zahtevi za četiri IT konfiguracije (pod nazivom dodaci L, T, S i D)

3. Posebni zahtevi za instrumente (pod nazivom dodaci I.1, I.2, ...). Prvi tip zahteva važi za sve instrumente. Drugi tip zahteva odnosi se na sledeće IT funkcije: dugoročno skladištenje mernih podataka (L), prenos mernih podataka (T), preuzimanje softvera (D) i razdvajanje softvera (S). Svaka celina sa zahtevima važi samo ako postoji odgovarajuća funkcija. Poslednji tip je zbirka dodatnih posebnih zahteva za instrumente. Numerisanje u dokumentu je isto kao i kod posebnih aneksa za instrumente iz MID direktive. Skup tabela sa zahtevima koje mogu da se primene na dato merilo je šematski prikazan na Slici 3-1.

Slika 3-1: Vrsta skupova sa zahtevima koje treba da se primene na instrument

Šeme u narednoj slici 3-2 prikazuju postojeće skupove zahteva.

Zahtevi za jednu od osnovnih konfiguracija merila

Zahtevi za IT konfiguracije koje se primenjuju

Specifični zahtevi za instrument koji se primenjuje


11

Slika 3-2: Pregled skupova zahteva

Softverski zahtevi za osnovne konfiguracije merila

Softverski zahtevi za IT konfiguracije

Zahtevi za namenska merila (Tip P)

Zahtevi za merila koja koriste univerzalne računare (Tip U)

a Tabela zahteva P1

Tabela zahteva P2

Tabela zahteva U1

Tabela zahteva U2

Zahtevi za dugoročno skladište podataka koji podležu zakonskoj kontroli (Dodatak L)

Zahtevi za prenos podataka koji podležu zakonskoj kontroli (Dodatak T)

Zahtevi za razdvajanje softvera (Dodatake S)

Uslovi za preuzimanje softvera podataka podleže zakonskoj kontroli (Dodatak D)

Tabela zahteva L1

Tabela zahteva L2

Tabela zahteva Т1

Tabela zahteva Т2

Vodomeri

Gasomeri

Brojila električne energije

Merila toplotne energije

Merači tečnosti

Merilo

Tabela zahteva l1-1

Softverski zahtevi specifični za instrument

Tabela zahteva S1

Tabela zahteva S2

Tabela zahteva D1

Tabela zahteva D2

Tabela zahteva l2-1

Tabela zahteva l3-1

Tabela zahteva l4-1

Tabela zahteva l5-1

Tabela zahteva l6-1


12

Zahtevi iz ovog vodiča se pored opisane strukture, razlikuju po klasama rizika. Opisano je šest klasa rizika koje su numerisane od A do F sa pretpostavkama povećavanja rizika. Najniža klasa rizika A i najviša klasa rizika F se za sada ne koriste. One su nosioci eventualnih slučajeva, koji će u budućnosti postati neophodni. Preostale klase rizika od B do E obuhvataju sve klase instrumenata koje su obuhvaćene MID direktivom. Štaviše, one pružaju dovoljan prostor u slučaju promene procene rizika. Klase su navedene u Poglavlju 11 ovog vodiča i isključivo su informativnog karaktera.

Svako merilo mora da se dodeli klasi rizika, jer su pojedini softverski zahtevi koji treba da se primene regulisani klasom rizika kojoj instrument pripada.

3.2 Kako da izaberete odgovarajuće delove vodiča Ovaj sveobuhvatan vodič za softver može da se primeni na veliki dijapazon instrumenata. Vodič je u svojoj formi modularan. Odgovarajući skupovi zahteva mogu lako da se izaberu ako se pridržavate sledeće procedure.

Korak 1: Izbor osnovne konfiguracije (P ili U)

Treba da se primeni samo jedan od dva skupa zahteva. Odlučite sa kojom je osnovnom konfiguracijom instrument u skladu: namenski instrument sa ugrađenim softverom (tip P, pogledajte poglavlje 4.1) ili instrument koji korisi univerzalni računar (tip U, pogledajte Poglavlje Napaka! Vira sklicevanja ni bilo mogoce najti.). Ako vas ne interesuje ceo instrument već samo njegov pod-sklop, onda se shodno tome odlučite za pod-sklop. Celokupan skup zahteva primenite na odgovarajuću osnovnu konfiguraciju.

Korak 2: Izbor važećih IT konfiguracija (dodaci L, T, S i D)

IT konfiguracije se sastoje iz: dugoročnog skladišta za podatke koji podležu zakonskoj kontroli (L), prenosa podataka koji podležu zakonskoj kontroli (T), razdvajanja softvera (S) i preuzimanja softvera koj podleže zakonskoj kontroli (D). Odgovarajuće obavezne celine, zvane modularni dodaci, nezavisne su jedna od drugih. Izabrane celine zavise samo od IT konfiguracije. Ako je izabrana proširena celina, onda ona mora u potpunosti da se primeni. Odlučite se za važeće modularne dodatke, ako ih ima, i shodno tome ih primenite (Slika 3-2).

Korak 3: Izbor posebnih zahteva za instrument (dodatak I)

Izaberite, ako ih ima - korišćenjem odgovarajućeg posebnog dodatka za instrument I.x – posebne zahteve za instrument koji važe i shodno tome ih primenite (Slika 3-2).

Korak 4: Izbor važeće klase rizika (dodatak I)

Izaberite klasu rizika u odgovarajućem posebnom dodatku za instrument I.x , podpoglavlje I.x.6. U njemu se klase rizika mogu definisati jedinstveno na klasu merila ili dalje razdvajati na kategorije, oblasti primene itd. Nakon izbora važeće klase rizika, treba da se razmotre samo odgovarajući zahtevi i smernice za validaciju.


13

3.3 Kako da radite sa tabelom zahteva Svaka tabela zahteva sadrži tačno definisane zahteve. Ona se sastoji se iz definisanog teksta, napomena, dokumentacije koja treba da se obezbedi, smernica za validaciju i primera prihvatljivih rešenja (ako su dostupni). Sadržaj unutar tabele zahteva može dodatno da se deli u skladu sa klasama rizika. Šematski prikaz tabele zahteva nalazi se na Slici 3-3.

NaNaNaNazivzivzivziv zahtevazahtevazahtevazahteva

Glavna konstatacija zahteva (na kraju se razlikuje po klasama rizika)

Napomena (obim primene, dodatna objašnjena, izuzetni slučajevi, itd.)

Dokumentacija koja treba da se obezbedi (na kraju se razlikuje po klasama rizika)

Smernice za validaciju za jednu klasu rizika

Smernice za validaciju za

drugu klasu rizika

...

Primer prihvatljivog rešenja za jednu klasu rizika

Primer prihvatljivog rešenja za drugu klasu rizika

...

Slika 3-3: Struktura tabele zahteva

Tabela zahteva predstavlja tehnički sadržaj zahteva zajedno sa smernicama za validaciju. Ona se odnosi kako na proizvođača tako i na notifikovano telo u oba pravca: (1) koji treba da razmotre zahtev kao minimalan zahtev i (2) da ne stavljaju zahteve van ovog zahteva.

Napomene za proizvođača:

- Obratite pažnju na glavnu konstataciju i posebne napomene. - Obezbedite dokumentaciju po potrebi. - Prihvatljiva rešenja su primeri koji su u skladu sa zahtevom. Nisu obavezni da se prate. - Smernice za validaciju su informativnog karaktera.

Napomene za notifikovana tela:

- Obratite pažnju na glavnu konstataciju i posebne napomene.

- Pratite smernice za validaciju. - Potvrdite kompletnost obezbeđene dokumentacije.

3.4 Kako treba raditi sa kontrolnim listama Kontrolne liste su metode kojima se obezbeđuje obuhvaćenost svih zahteva od strane proizvođača ili ispitivača u okviru poglavlja. One su deo izveštaja o ispitivanju. Budite svesni da je priroda kontrolnih lista sumiranje, i da one ne prave razliku između klasa rizika. Kontrolne liste ne zamenjuju definicije zahteva. Pogledajte tabele zahteva da biste videli kompletne opise. Procedura:

- Prikupite kontrolne liste koje su neophodne u skladu sa izborom opisanim u koracima 1,2 i 3 u odeljku 3.2.

- Prođite kroz kontrolne iste i dokažite da li su ispunjeni svi zahtevi.

- Popunite kontrolne liste kao što se traži.


14

4 Osnovni zahtev za ugrađeni softver u namenskim merilima (Tip P)

Skup zahteva u ovom poglavlju se primenjuje na namenska merila ili pod sklopove instrumenta koji je namenski. Validacija za podsklopove je uključena čak i ako se izričito ne pominje u tekstu. Ako merilo koristi univerzalni računar (računar opšte namene), skup zahteva u narednom poglavlju mora da se odnosi na (tip U instrument). Zahtevi za tip U instrument takođe moraju da se koriste ako se naknadni tehnički opis za namenske instrumente ne podudara.

4.1 Tehnički opis Tip P instrument je merilo koje ima ugrađen IT sistem (uopšteno, to je sistem zasnovan na mikroprocesoru ili mikrokontroleru). Odlikuju ga sledeće karakteristike:

• Namena čitavog aplikativnog softvera je merenje. Ovo obuhvata i funkcije u skladu sa zakonskom kontrolom i ostalim funkcijama.

• Namena korisničkog interfejsa je merenje, odnosno on se obično nalazi u operativnom režimu rada koji podleže zakonskoj kontroli. Moguće je prebacivanje na operativni režim rada koji nije u skladu sa zakonskom kontrolom.

• Ako postoji operativni sistem, on nema korisnički komandni intefejs koji je dostupan korisniku (za učitavanje ili izmenu programa, slanje komandi operativnom sistemu, promenu okruženja aplikacije itd.).

Tip instrumenta P može da ima dodatna svojstva i funkcije koje su obuhvaćene sledećim proširenjima zahteva:

• Softver je dizajniran i tretira se kao celina, osim ako je primećeno razdvajanje softvera u skladu sa dodatkom S.

• Softver je nepromenljiv i nema sredstava za programiranje ili izmenu softvera koja podležu zakonskoj kontroli. Preuzimanje softvera je dozvoljeno samo ako se poštuje dodatak D.

• Interfejsi za prenos mernih podataka putem otvorenih ili zatvorenih mreža za komunikaciju su dozvoljeni (treba poštovati dodatak T).

• Skladištenje mernih podataka na integrisano skladište ili na daljinsko ili prenosivo skladištu je dozvoljeno (treba poštovati dodatak L).


15

4.2 Posebni zahtevi za tip P Klase rizika od B do E

P1: Dokumentacija Pored specifične dokumentacije koja je potrebna za svaki od sledećih zahteva, dokumentacija treba u osnovi da

sadrži:

a. Opis softvera koji podleže zakonskoj kontroli.

b. Opis tačnosti mernih algoritama (npr. obračun cena i zaokruživanje algoritama).

c. Opis korisničkog interfejsa, menija i dijaloga.

d. Nedvosmislenu identifikaciju softvera.

e. Pregled hardvera sistema, npr. topologija blok dijagrama, vrsta računara, tip mreže, itd. ako nije opisano u

uputstvu za upotrebu.

f. Uputstvo za upotrebu.

Klasa rizika B Klasa rizika C Klasa rizika D

P2: Identifikacija softvera Softver koji podleže zakonskoj kontroli biće jasno identifikovan. Identifikacija softvera je neraskidivo povezana sa

samim softverom. Ona se prikazuje na komandi ili u toku rada.

Napomene: 1. Promene na metrološki

odgovarajućem softveru zahtevaju informacije od notifikovanog tela. Notifikovano telo odlučuje da li je neophodna ili ne nova jedinstvena identifikacija softvera. Nova identifikacija softvera je potrebna samo ako su promene na softveru dovele do promena na odobrenim funkcijama ili karakteristikama.

Napomene: 1. Pored 1 klase rizika B: Svaka promena na softveru koji podleže

zakonskoj kontroli definiše se kao nepromenjiva i pri ispitivanju tipa zahteva novu identifikaciju softvera. Ako celokupan softver/firmver koji podleže zakonskoj kontroli nije definisan kao nepromenjiv, možda postoji dodatni deo koji se tretira kao za B, čak i za klase rizika C. Međutim, ukoliko tehnički nije moguće ostvariti jednu identifikaciju softvera za nepromenjivi deo (npr. CRC zbir provere generisan isključivo putem nepromenjivog dela izvršnog kôda) i jednu za ostale (npr. broj verzije), kompletan softver/firmver treba da se definiše kao nepromenjivi i može da se identifikuje pomoću kontrole.

2. Identifikacija softvera mora da bude jednostavno prikazana za verifikaciju i inspekciju (jednostavno znači sa standardnim korisničkim interfejsom, bez dodatnih alata).

3. Identifikacija softvera treba da ima strukturu koja jasno identifikuje verzije koje zahtevaju ispitivanje tipa i one koje to ne radi.

4. Ako funkcije softvera mogu da se promene pomoću specifičnih parametara za tip, svaka funkcija ili varijanta se mogu odvojeno identifikovati, ili se kompletan paket može identifikovati kao celina.

Potrebna dokumentacija: Dokumentacija treba da navede identifikaciju softvera i opiše kako se identifikacija softvera kreira, na koji način je neraskidivo povezana sa samim softverom, kako može da mu se pristupiti radi pregledanja i kako je struktuiran u cilju razlikovanja izmena na verzijama sa ili bez zahtevanja ispitivanja tipa.

Potrebna dokumentacija (pored dokumentacije koja je potrebna za klase rizika B i C): Dokumentacija treba da prikaže mere koje su preduzete za zaštitu indentifikacije softvera od falsifikovanja.

Smernice za validaciju:

Provere na osnovu dokumentacije:

• Ispitati opis generisanja i vizuelizacije identifikacije softvera. • Proverite da li su svi programi koji izvršavaju funkcije koje podležu

zakonskoj kontroli jasno identifikovani i opisani tako da je i notifikovanom telu i proizvođaču jasno koje softverske funkcije su obuhvaćene identifikacijom softvera, a koje nisu.

• Proverite da li je proizvođač isporučio nominalnu vrednost identifikacije (broj verzije ili funkcionalna kontrola). Ovo mora biti navedeno u sertifikatu o ispitivanju.

Funkcionalne provere: • Identifikacija softvera može da se vizualizuje kao što je opisano u

dokumentaciji. • Predstavljena identifikacija je tačna.

Smernice za validaciju (pored smernica za klase rizika B i C): Provere na osnovu dokumentacije:

• Proverite da li su mere koje su preduzete za zaštitu od falsifikovanja odgovarajuće.


16

Primer prihvatljivog rešenja: • Identifikacija softvera koja podleže zakonskoj kontroli sastoji se iz dva dela. Deo (A) treba da se promeni, ako

promene na softveru zahtevaju nov pregled. Deo (B) ukazuje samo na manje izmene na softveru npr. ispravke grešaka, koje ne zahtevaju nov pregled.

• Identifikacija se generiše ili prikazuje na komandi. • Deo (A) indentifikacije sastoji se iz

broja verzije ili TEC broja. • Deo (A) identifikacije sastoji se iz automatski generisanog pregleda

softvera koji podleže zakonskoj kontroli koji je definisan kao nepromenjiv pri ispitivanju tipa. Za ostale softvere koji podležu zakonskoj kontroli, deo (A) predstavlja broj verzije ili TEC broj.

• Primer prihvatljivog rešenja za obavljanje kontrole je CRC-16 algoritam.

Dodaci za klasu rizika E

Potrebna dokumentacija (pored dokumentacije koja je potrebna za klase rizika B i C): Izvorni kôd koji sadrži generisanje identifikacije.

Smernice za validaciju (pored smernica za klase rizika B i C):

Provere na osnovu izvornog kôda: • Proverite da li su svi odgovarajući softverski delovi obuhvaćeni algoritmom za generisanje identifikacije.

• Proverite ispravnu implementaciju algoritma.


17

Klasa rizika B Klasa rizika C Klasa rizika D P3: Uticaj putem korisničkog interfejsa Komande unete putem korisničkog interfejsa nesmeju nedopustivo da utiču na softver i merne podatke koji

podleže zakonskoj kontroli.

Napomene: 1. Komanda može biti jedan ili niz aktiviranja prekidača ili tastera koji se obavljaju ručno. 2. To znači da je svaka komanda nedvosmisleno dodeljena za pokrenutu funkciju ili izmenu podataka. 3. To znači da aktiviranje prekidača ili tastera koji nisu propisani ili dokumentovani kao komande, nemaju

nikakav uticaj na funkcije instrumenata i merne podatke.

Potrebna dokumentacija: Ako instrument može da prima komande, dokumentacija treba da sadrži: • Kompletnu listu komandi (npr. stavke menija) zajedno sa izjavom o

kompletnosti. • Kratak opis njihovog značenja i uticaja na funkcije i podatke merila.

Potrebna dokumentacija (pored dokumentacije koja je potrebna za klase rizika B i C):

• Dokumentacija treba da prikaže mere koje su preduzete za validaciju kompletnosti dokumentacije koja se odnosi na komande.

• Dokumentacija treba da sadrži protokol koji navodi testove za sve komande.

Smernice za validaciju: Provere na osnovu dokumentacije:

• Procenite da li su sve dokumentovane komande prihvatljive, odnosno da li im je dozvoljeno da utiču na funkcije merenja (i odgovarajuće podatke) ili nije.

• Proverite da li proizvođač dostavio eksplicitnu izjavu o kompletnosti dokumentacije koja se odnosi na komande.

Funkcionalne provere:

• Sprovedite praktične testove (nasumične provere) na dokumentovanim i nedokumentovanim komandama. Ukoliko ih ima, testirajte sve stavke menija.


• Proverite da li su preduzete mere i test protokoli odgovarajući za visok nivo zaštite.

Primer prihvatljivog rešenja: Postoji softverski modul koji prima i tumači komande iz korisničkog interfejsa. Ovaj modul pripada softveru koji podleže zakonskoj kontroli. On prosleđuje isključivo dozvoljene komande ostalim softverskim modulima koji podležu zakonskoj kontroli. Sve nepoznate ili nedozvoljene sekvence aktiviranja prekidača ili tastera se odbijaju i ne utiču na softver ili podatke merenja koji podleže zakonskoj kontroli.


Potrebna dokumentacija (pored dokumentacije koja je potrebna za klase rizika B i C): Izvorni kôd instrumenta.

Smernice za validaciju (pored smernica za klase rizika B i C): Provere na osnovu izvornog kôda: • Proverite izradu softvera i da je protok podataka koji se odnosi na komande nedvosmisleno definisan u

softveru koji podleže zakonskoj kontroli i da li može da se verifikuje. • Pretražite nedopustiv protok podataka od korisničkog interfejsa ka domenima koji treba da se zaštiti. • Proverite sa alatima ili ručno da li su komande ispravno dekodirane i da nema nedokumentovanih komandi.


18

Klasa rizika B Klasa rizika C Klasa rizika D P4: Uticaj putem interfejsa za komunikaciju Komande koje su unešene putem interfejsa za komunikaciju merila ne smeju nedopustivo da utiču na softver i

merne podatke koji podležu zakonskoj kontroli.

Napomene: 1. To znači da je svaka komanda nedvosmisleno dodeljena za pokrenutu funkciju ili izmenu podataka. 2. To znači da signali ili kôdovi koji nisu utvrđeni i dokumentovani kao komande nemaju uticaja na funkcije i

podatke instrumenta. 3. Komande mogu biti niz električnih (optičkih, elektromagnetnih, itd.) signala na ulaznim kanalima ili kôdovi u

protokolima za prenos podataka. 4. Ograničenja za ovaj zahteva se obustavljaju kada se preuzima softver u skladu sa dodatkom D. 5. Ovaj zahtev važi samo za interfejse koji nisu plombirani.

Potrebna dokumentacija:

Ako instrument ima interfejs dokumentacija treba da sadrži:

• Kompletan spisak svih komandi zajedno sa izjavom o kompletnosti.

• Kratak opis njihovog značenja i njihov uticaj na funkcije i podatke merila.

Potrebna dokumentacija: (pored dokumentacije koja je potrebna za klase rizika B i C): • Dokumentacija treba da

prikaže mere koje su preduzete za validaciju kompletnosti dokumentacije koja se odnosi na komande.

• Dokumentacija treba da sadrži prokol koji navodi testove za komande ili bilo koju drugu odgovarajuću meru za dokazivanje ispravnosti.



• Razmotrite da li su sve dokumentovane komande prihvatljive, odnosno da li je njihov uticaj na funkcije merenja (i odgovarajuće podatke) dozvoljen ili nije.

• Proverite da li je proizvođač dao jasnu izjavu o kompletnosti dokumentacije koja se odnosi na komande.


Sprovedite praktične testove (nasumične provere), koristeći perifernu opremu, ako je na raspolaganju.

Napomena: Ako nije moguće zanemariti neprihvatljive uticaje na funkcije merenja (ili odgovarajuće podatke) putem interfejsa i shodno tome izmeniti softver, onda sertifikat o ispitivanju mora da ukaže da je interfejs nezaštićen i opiše potrebna srestva za obezbeđivanje/plombiranje. Ovo takođe važi i za interfejse koji nisu opisani u dokumentaciji.



Primer prihvatljivog rešenja: Postoji softverski modul koji prima i tumači komande iz korisničkog interfejsa. Ovaj modul je deo softvera koji podleže zakonskoj kontroli. On prosleđuje samo dozvoljene komande ostalim softverskim modulima koji podležu zakonskoj kontroli. Sve nepoznate ili nedozvoljene sekvence signala ili kôda se odbijaju i ne utiču na softver ili podatke merenja koji podležu zakonskoj kontroli.


19

Dodaci za klase rizika E



Provere na osnovu izvornog kôda: • Proverite izradu softvera i da je protok podataka koji se odnosi na komande nedvosmisleno definisan u softveru

koji podleže zakonskoj kontroli i da može da se verifikuje. • Pretražite nedoupustiv protok podataka od korisničkog interfejsa ka domenima koji treba da se zaštiti. • Proverite sa alatima ili ručno da li su komande ispravno dekodirane i da nema nedokumentovanih komandi.

Klasa rizika B Klasa rizika C Klasa rizika D P5: Zaštita od slučajnih ili nenamernih izmena Softver i merni podaci koji podležu zakonskoj kontroli moraju da se zaštite od slučajnih ili nenamernih izmena.

Napomene: Mogući razlozi za slučajne izmene i greške pored primenjenih najnovijih tehnika implementacije su: nepredvidljivi fizički uticaji, uticaji izazvani korisničkim funkcijama i zaostalim nedostacima softvera. Ovaj zahtev obuhvata: a) Fizičke uticaje: Zapamćeni podaci merenja moraju da se zaštite od oštećenja ili brisanja u slučaju

pojavljivanja greške, ili će greška biti otkrivena. b) Korisničke funkcije: Potvrda se traži pre brisanja ili izmene podataka. c) Neispravnost softvera: Treba preduzeti odgovarajuće mere za zaštitu podataka od nenamernih izmena do

kojih može doći neispravnom izradom programa ili programskih grešaka, npr. provera verovatnosti.

Potrebna dokumentacija: Dokumentacija treba da prikaže mere koje su preduzete za zaštitu softvera i podataka od nenamernih izmena.



• Proverite da li je zbir provere programskog kôda i odgovarajućih parametara automatski izrađen i verifikovan. • Proverite da do zamene podataka ne može da dođe pre isteka perioda za skladištenje podataka koji je

proizvođač predvideo i dokumentovao. • Proverite da li je u slučaju da korisnik želi da izbriše datoteke sa podacima merenja izdato upozorenje. Funkcionalne provere:

• Proverite praktičnim nasumičnim proverama da li je pre brisanja podataka merenja dato upozorenje, ako je brisanje uopšte moguće.

Primer prihvatljivog rešenja: • Slučajna izmena softvera i podataka merenja može da se proveri izračunavanjem kontrolnog zbira za

odgovarajuće delove, uporedi sa nominalnom vrednošću i zaustavi ako je nešto izmenjeno. • Podaci merenja se ne brišu bez prethodnog odobrenja, npr, dijaloga sa izjavom ili prozora koji traži potvrdu

brisanja. • Za otkrivanje greške pogledajte takođe Dodatak I.


Potrebna dokumentacija (pored dokumentacije koja je potrebna za klase rizika B, C i D): Izvorni kôd instrumenta.

Smernice za validaciju (pored smernica za klase rizika B, C i D):

Provere na osnovu izvornog kôda:

• Proverite da li su preduzete mere za otkrivanje izmena (grešaka) odgovarajuće.

• Ukoliko je dobijen zbir provere, proverite da li je obuhvatio sve delove softvera koji podleže zakonskoj kontroli.


20

Klasa rizika B Klasa rizika C Klasa rizika D P6: Zaštita od namernih izmena Softver koji podleže zakonskoj kontroli biće obezeđen od neprihvatljivih izmena, učitavanja ili zamene

hardverske memorije.

Napomene: 1. Instrument bez interfejsa: Manipulacija programskog kôda može biti moguća manipulacijom fizičke

memorije, odnosno memorija se fizički uklanja i zamenjuje lažnim softverom ili podacima. Da bi se sprečilo da do ovoga dođe, treba da se zaštiti kućište instrumenta ili sama fiziča memorija od neovlašćenog uklanjanja.

2. Instrument sa interfejsom: Interfejs obuhvata samo one funkcije koje su predmet ispitivanja. Sve funkcije u interfejsu podležu pregledu (pogledajte P4). Tamo gde interfejs treba da se koristi za preuzimanje softvera, on mora biti u skladu sa dodatkom D.

3. Smatra se da su podaci dovoljno zaštićeni samo ako ih obradi softver koji podleže zakonskoj kontroli. Ako se softver koji podleže zakonskoj kontroli promeni nakon odobrenja, treba pratiti zahteve iz dodatka S.


Dokumentacija treba da obezbedi garanciju da softver koji podleže zakonskoj kontroli neće moći da se menja bez dozvole.

Potrebna dokumentacija (pored dokumentacije koja je potrebna za klase rizika B i C): Treba prikazati mere koje su preduzete za zaštitu od namernih izmena.


• Proverite da li su dokumentovana sredstva za zaštitu od neovlašćene razmene memorije koja sadrži softver dovoljna.

Ako memorija može da se programira u povezanom strujnom kolu (bez demontaže), proverite da li režim za programiranje može da se onemogući električnim putem, i da li sredstva za onemogućavanje mogu da se obezbede/plombiraju. (Za proveru objekata za preuzimanje pogledajte dodatak D)

Funkcionalne provere

• Praktično testirajte režim za programiranje i proverite da li radi onemogućavanje.

Smernice za validaciju (pored smernica za klase rizika B i C ): Provere na osnovu dokumentacije:

• Proverite da li preduzete mere odgovaraju visokom nivou zaštite u poređenju sa zahtevanim najvišim nivoom.

Primer prihvatljivog rešenja:

Instrument je plombiran i intefejsi su u skladu sa zahtevima P3 i P4.




Provere na osnovu izvornog kôda: • Proverite u izvornom kôdu da li su mere koje su preduzete za otkrivanje namernih izmena odgovarajuće.


21

Klasa rizika B Klasa rizika C Klasa rizika D P7: Zaštita parametara Parametri koji ispravljaju karakteristike merila koje podležu zakonskoj kontroli treba da se obezbede od

neovlašćene izmene.

Napomene: 1. Parametri specifični za tip isti su za svaki uzorak tipa i nalaze se u opštem delu programskog kôda. Stoga se

zahtev P6 odnosi na njih. 2. Zaštićeni parametri specifični za uređaj mogu da se menjaju pomoću tastature, prekidača ili putem interfejsa,

ali samo pre nego što su zaštićeni. 3. Podesivi parametri specifični za uređaj mogu da se menjaju nakon obezbeđivanja.


Dokumentacija treba da opiše sve parametre koji podležu zakonskoj kontroli, njihove opsege i nominalne vrednosti, gde su zapamćeni, kako mogu da se pregledaju, kako su obezbeđeni i kada, odnosno pre ili nakon verifikacije.

Potrebna dokumentacija (pored dokumentacije koja je potrebna za klase rizika B i C): Treba da se prikažu mere koje su preduzete za zaštitu parametara.



• Proverite da li je nemoguće menjati ili podešavati zaštićene parametre specifične za uređaj nakon obezbeđivanja.

• Proverite da li su svi odgovarajući parametri koji su u skladu sa listama (navedenim u Dodatku I, ako ih ima) klasifikovani kao obezbeđeni.


• Testirajte režim za podešavanje (konfiguracija) i proverite da li onemogućavanje funkcioniše nakon obezbeđivanja.

• Proverite klasifikaciju i stanje parametara (obezbeđeni/podesivi) na ekranu instrumenta, ako je predviđena odgovarajuća stavka menija.

Smernice za validaciju (pored smernica za klase rizika B i C): Provere na osnovu dokumentacije: • Proverite da li preduzete mere odgovaraju visokom nivou zaštite u poređenju sa zahtevanim najvišim nivoom.

Primer prihvatljivog rešenja: a) Parametri su obezbeđeni plombiranjem instrumenta ili kućišta memorije i onemogućavanjem omogući/onemogući ulaza memorijskog kola pridruženim džamperom ili prekidačem koji je plombiran.

Hronološki zapis revizija:

b) Brojač događaja beleži svaku izmenu vrednosti parametra. Trenutni broj može da se prikaže i uporedi sa početnom vrednošću bročaja koja je zabeležena pri poslednoj zvaničnoj verifikaciji i koja je neizbrisivo obeležena na instrumentu.

c) Izmene na parametrima se beleže u sistemu za evidenciju događaja. To je zapis sa informacijama koji se pamti u memoriji koja ne gubi sadržaj nakon isključenja napajanja. Softver koji podleže zakonskoj kontroli automatski generiše svaki unos i sadrži: • Identifikaciju parametara (npr. naziv) • Vrednost parametra (postojeću ili prethodnu vrednost) • Vremenska oznaka promene Sistem za evidenciju događaja ne može da se briše ili menja, a da se ne ošteti plomba.

÷

Klasa rizika E Potrebna dokumentacija (pored dokumentacije koja je potrebna za klase rizika B i C): Izvorni kôd prikazuje način obezbeđivanja i pregledanja parametara koji podležu zakonskoj kontroli.


Provere na osnovu izvornog kôda: • Proverite u izvornom kôdu da li su mere koje su preduzete za zaštitu parametara odgovarajuće (npr. režim za

podešavanje je onemogućen nakon obezbeđivanja).


22

5 Osnovni softverski zahtevi za merila koja koriste univerzalni računar (Tip U)

5.1 Tehnički opis Skup softverskih zahteva u ovom odeljku odnose se na merila koja su zasnovana na računaru opšte namene. Tehnički opis mernog sistema tipa U nalazi se ispod. U suštini, treba uzeti u obzir sistem tipa U mora ako nisu ispunjeni zahtevi za tip P instrument (pogledajte poglavlje 4.1).

Konfiguracija hardvera

a) Modularan sistem opšte namene zasnovan na računaru. Računarski sistem može da bude samostalan deo zatvorene mreže, npr. Ethernet, token-ring LAN ili deo otvorene mreže, npr. Internet.

b) Pošto je sistem opšte namenski, senzor bi normalno trebalo da bude van računarske jedinice i povezan sa njim pomoću zatvorenog linka za komunikaciju. Međutim, link za komunikaciju bi takođe trebalo da bude otvoren, npr. mreža, pri čemu bi nekoliko senzora moglo da bude povezano.

c) Korisnički intefejs može da se prebaci na režima rada, koji ne podleže zakonskoj kontroli, na onaj koji poleže, i obrnuto.

d) Skladište može biti nepromenjivo, npr. čvrsti disk, ili prenosivo, npr. diskete, CD-RW.

Konfiguracija softvera

e) Može da se koristi bilo koji operativni sistem dogod mogu da se ispune sledeći zahtevi. Pored aplikacije merila, na sistemu se istovremeno takođe mogu naći i druge softverske aplikacije. Delovi softvera, npr. aplikacija merila podleže zakonskoj kontroli i nakon odobrenja ne može nedozvoljeno da se menja. Delovi koji ne podležu zakonskoj kontroli mogu da se menjaju.

f) Operativni sistem i upravljački programi na nižem nivou, npr upravljački program videa, upravljački programi štampača, upravljački programi diska, itd., ne podležu zakonskoj kontroli osim ako nisu posebno programirani za određeni merni zadatak.


23

5.2 Posebni softverski zahtevi za tip U Klase rizika od B do E

U1: Dokumentacija Pored specifične dokumentacije koja je potrebna za svaki od sledećih zahteva, dokumentacija treba u osnovi da

obuhvata:

a. Opis softverski funkcija koje podležu zakonskoj kontroli, značenje podataka, itd.

g. Opis tačnosti mernih algoritama (npr. obračun cena i zaokruživanje algoritama).

b. Opis korisničkog interfejsa, menija i dijaloga.

c. Identifikacija legalnog softvera.

d. Pregled hardvera sistema, npr. topologije blok dijagrama, vrste računara, tipa mreže, itd. ako nije opisano

u uputstvu za upotrebu.

e. Pregled korištenih delova operativnog sistema, bezbednosnih aspekata korištenog operativnog sistema,

npr. zaštita, korisnički nalozi, privilegije, itd.

f. Uputstvo za upotrebu.


U2: Identifikacija softvera Softver koji podleže zakonskoj kontroli biće jasno identifikovan. Identifikacija softvera je neraskidivo povezana

sa samim softverom. Ona se prikazuje na komandi ili u toku rada.

Napomene: 1. Identifikacija izuzima upravljačke

programe na nižem nivou, npr. upravljačke programe videa, upravljačke programe štampača, itd., ali obuhvata upravljačke programe koji su posebno programirani za specifične zadatke koji podležu zakonskoj kontroli.

2. Izmene na softveru koji podleže zakonskoj kontroli zahtevaju informacije od notifikovanog tela. Notifikovano telo odlučuje da li je nova jedinstvena identifikacija softvera neophodna ili ne. Nova identifikacija softvera je potrebna samo ako su promene u softveru dovele do promena na odorenim funkcijama ili karakteristikama.

Napomene: 1. Ograničenje za 1B: Upravljački programi (na nižem nivou) koji

su definisani kao odgovarajući pri ispitivanju tipa biće identifikovani.

2. Dodatak uz 2 klasu rizika B: Svaka promena na programskom kôdu koji podleže zakonskoj kontroli koja je definisana kao nerpomenjiva pri ispitivanju tipa ili promene parametara specifičnih za tip zahtevaju novu identifikaciju softvera. Ako ceo softver/firmver koji podleže zakonskoj kontroli nije definisan kao fiskni, možda postoji dodatni deo koji se tretira kao u klasi rizika B, čak klasi rizika C. Međutim, ukoliko tehnički nije moguće realizovati jednu identifikaciju softvera za nepromenjivi deo (npr. CRC zbir provere generisan isključivo nepromenjivim delom izvršnog kôda) i jednu za ostale (npr. broj verzije), celokupan softver treba da se definiše kao nepromenjiv i identifikuje sa kontrolnim zbirom.

5. Ako su funkcije koje podležu zakonskoj kontroli i obračun zadatka merenja zaštićene posebnom konfiguracijom operativnog sistema, onda odgovarajuće konfiguracione datoteke moraju da imaju dodatnu identifikaciju.

6. Identifikacija softvera mora da bude jednostavno prikazana za verifikaciju i inspekciju (jednostavnim sredstvima standardnog korisničkog interfejsa, bez dodatnih alata.)

7. Identifikacija softvera treba da ima strukturu koja jasno identifikuje verzije koje zahtevaju ispitivanje tipa i one koje to ne zahtevaju.

3. Identifikacije mogu da se primene na različite nivoe, npr. za dovršavanje programa, modula, funkcija, itd. 4. Ako softverske funkcije mogu da se prebace pomoću parametara, svaka funkcija ili varijanta mogu

odvojeno da se identifikuju, ili kompletan paket može da se identifikuje kao celina. Potrebna dokumentacija: Dokumentacija će navesti identifikacije softvera i opisati kako se identifikacija softvera kreira, na koji način je neraskidivo povezana sa samim softverom, kako može da mu se pristupi radi pregledanja i kako je struktuiran kako bi mogle da se razlikuju izmene na verzijama sa i bez zahteva za ispitivanje tipa.

Potrebna dokumentacija (pored dokumentacije koja je potrebna za klase rizika B i C): Dokumentacija će prikazati mere koje su preduzete za zaštitu indentifikacije softvera od falsifikovanja.


24



• Pregledajte opis za generisanje i vizuelnu proveru identifikacije softvera.

• Proverite da li su svi programi koji podležu zakonskoj kontroli jasno identifikovani i opisani tako da je jasno i notifikovanom telu i proizvođaču koje softverske funkcije su obuhvaćene identifikacijom softvera, a koji nisu.

• Proverite da li je proizvođač isporučio nominalnu vrednost identifikacije (broj verzije ili funkcionalna kontrola). Ovo mora da se navede u uverenju o ispitivanju. Funkcionalne provere:

• Proverite da li identifikacija softvera može vizualno da se proveri kao što je opisano u dokumentaciji.

• Proverite da li je prikazana identifikacija tačna.


Proverite da li su preduzete mere za zaštitu od falsifikovanja odgovarajuće.

Primer prihvatljivog rešenja: • Identifikacija softvera koji podleže zakonskoj kontroli se sastoji iz dva dela. Deo (A) treba da se promeni, ako

izmene na softveru zahtevaju nov pregled. Deo (B) ukazuje na manje izmene na softveru npr. ispravke grešaka, koje ne zahtevaju nov pregled.

• Identifikacija se generiše ili prikazuje na komandi.

• Deo (A) indentifikacije se sastoji iz broja verzije ili TEC broja. Da bi se sprečila njegova izmena sa jednostavnim softverskim alatima, pamti se u binarnom formatu u izvršnoj programskoj datoteci.

• Deo (A) identifikacije sastoji se iz automatski generisanog kontrolnog zbira nepromenjivog kôda. Kod ostalih softvera koji podležu zakonskoj kontroli, deo (A) je broj verzije ili TEC broj. Da bi se sprečila njegova izmena sa jednostavnim softverskim alatima, pamti se u binarnom formatu u izvršnoj programskoj datoteci.

• Prihvatljivo rešenje za izvođenje kontrolnog broja je CRC-16 algoritam.

• Prihvatljivi algoritmi za zbir provere su CRC-32 ili hash algoritmi kao što su SHA-1, SHA-2, MD5, RipeMD160 itd.


Potrebna dokumentacija (pored dokumentacije koja je potrebna za klase rizika B i C): Izvorni kôd koji sadrži generisanje identifikacije.


Provere na osnovu izvornog kôda: • Proverite da li su svi odgovarajući softverski delovi obuhvaćeni algoritmom za generisanje identifikacije.

• Proverite ispravnu implementaciju algoritma.


25

Klasa rizika B Klasa rizika C Klasa rizika D U3: Delovanje putem korisničkog interfejsa Komande unete putem korisničkog interfejsa neće nedopustivo uticati na softver i podatke merenja koji podležu

zakonskoj kontroli.

Napomene: 1. To znači da je svaka komanda nedvosmisleno dodeljena za pokrenutu funkciju ili izmenu podataka. 2. To znači da aktiviranje prekidača ili tastera koji nisu propisani ili dokumentovani kao komande nemaju

nikakav uticaj na funkcije instrumenata i merne podatke. 3. Komanda može biti jedna ili niz radnji koje obavlja operater. Korisnik mora da prati uputstva vezano za

dozvoljene komande. 4. Funkcije za izmenu konfiguracije operativnog sistema koja podleže zakonskoj kontroli neće se nuditi

korisniku niti lokalno niti daljinski. Konfiguracija je obezbeđena od nedozvoljenih izmena.

÷

5. Korisnički komandni interfejs treba da budezatvoren, tj. korisnik ne može da učitava programe, piše programe ili izvršava komande na operativnom sistemu.

Potrebna dokumentacija: Dokumentacija treba da sadrži: • Kompletnu listu komandi (npr. stavke menija) zajedno sa

izjavom o kompletnosti. • Kratak opis njihovog značenja i uticaja na funkcije i podatke

merila. • Opis kako se postiže bezbedna konfiguracija operativnog

sistema. Dodela uloga (naloga) u operativnom sistemu (npr.„administrator“, „korisnik“, „zadatak merenja“). Dodela dozvolaodobrenih za ove uloge.

• Dokumentacija daljinske kontrole za funkcije operativnog sistema (npr. pokrenutih usluga) i sredstava zaštite (npr. konfiguracija zaštitnog zida).

Potrebna dokumentacija (pored dokumentacije koja je potrebna za klase rizika B i C):

• Dokumentacija će prikazati mere za potvrdu kompletnosti dokumentacije koja se odnosi na komande.

• Dokumentacija treba da sadrži protokol koji navodi testove za sve komande.


• Procenite da li su sve dokumentovane komande prihvatljive, odnosno da li imaju dozvoljen uticaj na funkcije merenja (i odgovarajuće podatke) ili ga uopšte nemaju.

• Proverite da li je proizvođač dostavio eksplicitnu izjavu o kompletnosti dokumentacije koja se odnosi na komande.

• Proverite mere za obezbeđivanje operativnog sistema. Funkcionalne provere:

• Sprovedite praktične testove (nasumične provere) na dokumentovanim i nedokumentovanim komandama. Testirajte sve stavke menija ukoliko ih ima.



Prihvatljivo rešenje: • Modul u softveru koji podleže zakonskoj kontroli filtrira nedozvoljene komande. Samo ovaj modul prima

komande, i on ne može da se zaobiđe. Svaki lažni ulaz se blokira. Korisnik se prilikom unošenja komandi pomoću posebnog softverskog modula kontroliše ili savetuje. Ovaj vodeći modul je neraskidivo povezan sa modulom koji filtrira nedozvoljene komande.

• Kod korišćenja mernog sistema, podešen je samo nalog sa ograničenim dozvolama. Pristup adiministratorskom nalogu je blokiran u skladu sa U6.

•


Potrebna dokumentacija (pored dokumentacije koja je potrebna za klase rizika B i C): Izvorni kôd softvera koji podleže zakonskoj kontroli.


26


Provere na osnovu izvornog kôda: • Proverite izradu softvera i da je protok podataka koji se odnosi na komande nedvosmisleno definisan u

softveru koji podleže zakonskoj kontroli i da li može da se verifikuje. • Pretražite nedoupustiv protok podataka od korisničkog interfejsa ka domenima koji treba da se zaštiti. • Proverite sa alatima ili ručno da li su komande ispravno dekodirane i da nema nedokumentovanih komandi.

Klasa rizika B Klasa rizika C Klasa rizika D U4: Delovanje putem interfejsa za komunikaciju Unos komandi putem neplombiranog interfejsa za komunikaciju merila neće nedozvoljeno uticati na softver i

podatke merenja koji podležu zakonskoj kontroli.

Napomene: 1. To znači da je svaka komanda nedvosmisleno dodeljena za pokrenutu funkciju ili izmenu podataka. 2. To znači da signali ili kodovi koji nisu definisani i dokumentovani kao komande nemaju uticaja na funkcije i

podatke instrumenta. 3. Komande mogu biti niz električnih (optičkih, elektromagnetnih, itd.) signala na ulaznim kanalima ili kôdovi u

protokolima za prenos podataka 4. Ograničenja ovog zahteva se obustavljaju kada se preuzima softver u skladu sa dodatkom D.

5. Odgovarajući softverski delovi koji tumače komande koje podležu zakonskoj kontroli smatraće se softverom koji podleže zakonskoj kontroli.

6. Ostali softverski delovi mogu da koriste obezbeđeni interfejs pod uslovom da ne ometaju ili falsifikuju prijem ili prenos komandi ili podataka koji podležu zakonskoj kontroli.

5. (Umesto 5B/C) Svi programi i programski delovi koji su uključeni u prenos i prijem komandi ili podataka koji podležu zakonskoj kontroli moraju da se nadgledaju softverom koji podleže zakonskoj kontroli.

6. (Umesto 6B/C) Interfejs koji prima ili prenosi komande ili podatke koji podležu zakonskoj kontroli mora biti namenjen toj ulozi i može da ga koristiti isključivo softver koji podleže zakonskoj kontroli. Međutim standardni interfejsi nisu izuzeti ako su metode zaštite softvera imlementirane u skladu sa dodatkom T.

7. Ako operativni sistem omogućava daljinsku kontrolu ili daljinski pristup, U3 zahtevi se primenjuju na interfejs za komunikaciju, odnosno na povezani daljinski terminal. Pored toga deo T mora da se uzme u obzir kod prenosa između računara i terminala.


Dokumentacija treba da sadrži:

• Kompletan spisak svih komandi zajedno sa izjavom o kompletnosti.

• Kratak opis njihovog značenja i njihov uticaj na funkcije i podatke merila.

• Opis kako se postiže bezbedna konfiguracija operativnog sistema. Dodela uloga (naloga) u operativnom sistemu (npr. „administrator“ i „korisnik“). Dodela dozvola odobrenih za ove uloge.

• Dokumentacija daljinske kontrole funkcija operativnog sistema (npr. pokrenutih usluga) i sredstava za obezbeđivanje (npr. konfiguracija zaštitnog zida).

Potrebna dokumentacija: (pored dokumentacije koja je potrebna za klase rizika B i C): • Dokumentacija će prikazati mere koje su

preduzete za validaciju kompletnosti dokumentacije koja se odnosi na komande.

• Dokumentacija treba da sadrži prokol koji navodi testove za komande ili bilo koju drugu odgovarajuću meru za dokazivanje ispravnosti.


27



• Procenite jesu li sve dokumentovane komande odobrene, odnosno da li im je dozvoljeno da utiču na softver koji podleže zakonskoj kontroli (i odgovarajuće podatke merenja) ili nije.

• Proverite da li je proizvođač dao jasnu izjavu o kompletnosti dokumentacije koja se odnosi na komande.

• Proverite mere za obezbeđivanje operativnog sistema.


Sprovedite praktične testove (nasumične provere), koristeći perifernu opremu, ako je dostupna.



Primer prihvatljivog rešenja: Postoji softverski modul koji prima i tumači podatke iz interfejsa. Ovaj modul pripada softveru koji podleže zakonskoj kontroli. On samo prosleđuje dozvoljene komande na druge softverske module koji podležu zakonskoj kontroli. Sve nepoznate ili nedozvoljene komande se odbijaju i ne utiču na softver ili podatke merenja koji podležu zakonskoj kontroli.

Pristup operativnom sistemu putem intefejsa je ograničen (pogledajte U3/U6).

•




Provere na osnovu izvornog kôda: • Proverite izradu softvera i da je protok podataka koji se odnosi na komande nedvosmisleno definisan u

softveru koji podleže zakonskoj kontroli i da li može da se verifikuje. • Pretražite nedoupustiv protok podataka od korisničkog interfejsa ka domenima koji treba da se zaštiti. • Proverite sa alatima ili ručno da li su komande ispravno dekodirane i da nema nedokumentovanih komandi.


28

Klasa rizika B Klasa rizika C Klasa rizika D U5: Zaštita od slučajnih ili nenamernih izmena Softver i merni podaci koji podležu zakonskoj kontroli moraju da se zaštite od slučajnih ili nenamernih izmena.

Napomene: 1. Do nenamernih izmena može doći:

a. Neispravnom izradom programa, npr. neispravnim funkcionisanjem petlje, promenom opštih promenjivih u funkciji, itd.: izbegavanje zahteva testiranje.

b. Zloupotrebom operativnog sistema; izbegavanje zahteva programere koji su dovoljno upoznati sa operativnim softverom koji se koristi.

c. Slučajna izmena ili brisanje zapamćenih podataka i programa (pogledajte takođe Dodatak L); d. Neispravno dodeljivanje mernih podataka prenosa. Merenja i podaci koji pripadaju jednom prenosu

merenja ne smeju da se mešaju sa podacima iz drugog prenosa zbog neispravnog programiranja ili skladištenja; izbegavanje zahteva testiranje koliko je to moguće i dodatne zahteve za potvrdu radnji gde može biti od koristi.

e. Fizički uticaji (elektromagnetna interferencija, temperatura, vibracija, itd.) izbegavanje zahteva samoproveru softvera.

Potrebna dokumentacija: Dokumentacija treba da navede preduzete mere za zaštitu softvera i podataka od nenamernih izmena.

Potrebna dokumentacija (pored dokumentacije koja je potrebna za klase rizika B i C): Dokumentacija će prikazati preduzete mere za potvrdu efikasnosti mera zaštite.



• Proverite da li je zbir provere programskog kôda i odgovarajućih parametara automatski generisan i verifikovan.

• Proverite da do zamene podataka ne može da dođe pre isteka perioda za skladištenje podataka koji je proizvođač predvideo i dokumentovao.

• Proverite da li je u slučaju da korisnik želi da izbriše datoteke sa podacima merenja izdato upozorenje.



Smernice za validaciju (pored smernice za klase rizika B i C):

Provere na osnovu dokumentacije: • Proverite da li su preduzete mere odgovarajuće za visok nivo zaštite.

Primer prihvatljivog rešenja: • Prevencija od neispravne izrade programa – ovo je van delokruga ovih klasa rizika. • Zloupotreba operativnog sistema, zamena ili brisanje zapamćenih podataka i programa - proizvođači treba

u potpunosti da iskoriste zaštitu ili pravo na privatnost koje operativni sistem ili programski jezik omogućavaju.

• Slučajna izmena programa i datoteka sa podacima može da se proveri izračunavanjem kontrolnog zbira za odgovarajući kôd, i uporedi sa nominalnom vrednošću i zaustavi ili odgovarajuće reaguje ako je kôd izmenjen, ako su obuhvaćeni parametri ili podaci.

• Ako operativni sistem to dozvoljava, preporučuje se da se uklone sva korisnička prava za brisanje, premeštanje ili izmenu softvera koji podleže zakonskoj kontroli, a pristup kontroliše putem uslužnih programa. Preporučuje se kontrola pristupa programima i podacima korišćenjem lozinki, kao što je upotreba mehanizama „samo za čitanje“. Kontrolor sistema treba da vrati prava u prethodno stanje samo kada je to potrebno.





• Proverite da li su preduzete mere za otkrivanje izmene (grešaka) odgovarajuće.

• Ukoliko je zbir provere ostvaren, proverite da li je obuhvatio sve delove softvera koji podleže zakonskoj kontroli.


29

Klasa rizika B Klasa rizika C Klasa rizika D U6: Zaštita od namernih izmena

Softver i merni podaci koji podležu zakonskoj kontroli moraju biti zaštićeni od nedozvoljene izmene.

Napomene: 1. Izmene čija je namera prevara mogu da se pokušaju:

a. Izmenom programskog kôda kao i integrisanih podataka – ako je programski kôd izvršni format (.exe), onda je dovoljno zaštićen klasama rizika B i C.

b. Izmenom zapamćenih podataka merenja – pogledajte Dodatak L.

2a Treba preduzeti metode koje razmatraju mogućnosti operativnog sistema kako bi se upotrebom operativnog sistema sprečile zamene odobrenog softvara sa onim neodobrenim. (pogledajte takođe U3). Pogledajte dodatak D za ovlašćeno preuzimanje softvera.

2b Uređaj za masovno skladištenje podataka u kom se pamte odgovarajuće konfiguracione datoteke, programi i parametri, treba da bude zaštićen od fizičke razmene.

3. Treba preduzeti korake za zaštitu od izmena softvera koji podleže zakonskoj kontroli korišćenjem operativnog sistema ili nekog drugog lako dostupnog i upravljivog alata (pogledajte takođe U3).

4. Delovi i funkcije operativnog sistema koji imaju implementiranu zaštitu mernog sistema treba smatrati softverom koji podleže zakonskoj kontroli, koji kao takav treba zaštititi.

Napomene:

1. Nivo zaštite treba da bude isti kao za elektronsko plaćanje.

Uopšteno govoreći, univerzalni računar odgovara samo ovoj klasi rizika uz dodatni hardver za zaštitu.


Dokumentacija treba da obezbedi garanciju da se softver i zapamćeni podaci merenja neće moći nedozvoljeno menjati.

Potrebna dokumentacija (pored dokumentacije koja je potrebna za klase rizika B i C): Treba prikazati mere koje su preduzete za zaštitu.

Smernice za validaciju: Slučaj 1: Zatvoreni komandni interfejs softvera koji podleže zakonskoj kontroli. Provere na osnovu dokumentacije: • Softverski moduli se automatski pokreću. • Korisnik nema pristup operativnom sistemu na računaru. • Korisnik nema pristup ostalim softverima osim onim odobrenim. • Daje se pismena izjava da nema skrivenih funkcija za zaobilaženje

zatvorenog komandno interfejsa.

Slučaj 2: Operativni sistem i/ili softver kome korisnik može da pristupi. Provere na osnovu dokumentacije: • Generiše se zbir provere kôda mašine softverskih modula. Softver koji podleže zakonskoj kontroli ne može da se pokrene ako je kôd falsifikovan.

Smernice za validaciju (pored smernica za klase rizika B i C ): Provere na osnovu dokumentacije:


Primer prihvatljivog rešenja: • Programski kôd i podaci mogu da se zaštite metodama kontrole. Program izračunava svoji soptsveni kontrolni broj koji poredi sa željenom vrednošču koja je skrivena u izvršnom kôdu. Ako samoprovera ne uspe, program se blokira. • Bilo koji algoritam potpisa treba da bude dugačak najmanje 2 bajta; CRC-16 kontrolni broj sa tajnim inicijalnim vektorom (skriven u izvršnom kôdu) biće zadovoljavajući. (Pogledajte takođe Dodatke L i T). • Neovlašćeno rukovanje softverom koji podleže zakonskoj kontroli može da se kontroliše kontrolom pristupa ili atributima zaštite privatnosti operativnog sistema. Nivo administracije ovih sistema biće obezbeđen plombiranjem ili sličnim metodama. • Pristup administratorskom nalogu je a) blokiran za sve ili b) odobren samo za osobe koje su ovlašćene u skladu sa nacionalnim zakonima za tržišni nadzor.

Rešenje a) Nasumična automatski generisana lozinka, koja nikome nije poznata. Izmena konfiguracije koja podleže zakonskoj kontroli je moguća isključivo novim podešavanjem operativnog sistema.

Rešenje b) Lozinka koju je izabralo ovlašćeno lice, koja je sakrivena i zapečaćena u koverti ili u/na kućištu.

Primer prihvatljivog rešenja: • Programski kôd može da se

obezbedi skladištenjem softvera koji podleže zakonskoj kontroli u dodeljenoj priključnoj jedinici koja je plombirana. Dodatna komponenta može na primer, da sadrži „memoriju samo za čitanje“ i mirko kontroler.


30

• Zaobilaženje metoda zaštite operativnog sistema direktnim upisivanjem u masovna skladišta ili fizičkom zamenom sprečava se plombiranjem.




Provere na osnovu izvornog kôda: • Proverite komunikaciju sa dodatnim bezbednosnim hardverom.

• Proverite da li su izmene na programima ili podacima otkrivene i da li se u tom slučaju izvršavanje programa zaustavlja.

Klasa rizika B Klasa rizika C Klasa rizika D U7: Zaštita parametra

Parametri koji podležu zakonskoj kontroli treba da se zaštite od neovlašćene izmene.

Napomene: 1. Parametri specifični za tip isti su za svaki uzorak tipa i nalaze se u opštem delu programskog kôda,

odnosno delu softvera koji podleže zakonskoj kontroli. Stoga se zahtev P6 odnosi na njih. 2. Parametri specifični za uređaj: • „Zaštičeni“ parametri specifični za uređaj mogu da se izmene pomoću tastature, prekidača ili putem

interfejsa, ali samo pre same zaštite. Zbog toga što sa parametrima specifičnim za uređaj može da se rukuje pomoću jednostavnih alata na univerzalnim računarima, oni neće biti zapamćeni na standardnim

skladištima unverzalnog računara. Pamćenje ovih parametara je moguće samo na dodatnom hardrveru. • Podesivi parametri specifični za uređaj mogu da se menjaju nakon zaštite. Potrebna dokumentacija:

Dokumentacija treba da opiše sve parametre koji podležu zakonskoj kontroli, njihove opsege i nominalne vrednosti, gde su zapamćeni, kako se mogu pregledati, kako su obezbeđeni i kada, odnosno pre ili nakon verifikacije.

Potrebna dokumentacija (pored dokumentacije koja je potrebna za klase rizika B i C): Treba da se prikažu mere koje su preduzete za zaštitu parametara.



• Proverite da li je metod zaštite parametara specifičnih za tip odgovarajući.

• Proverite da parametri specifični za uređaj nisu zapamćeni u standardnim skladištima unverzalnog računara, već na odvojenom hardveru koji može da se plombira i onemogući za upisivanje.


• Testirajte režim za podešavanje (konfiguracije) i proverite da li onemogućavanje funkcioniše nakon zaštite.

• Proverite klasifikaciju i stanje parametara (obezbeđen/podesiv) na ekranu instrumenta, ako je ponuđena odgovarajuća stavka menija.

TEC treba da navede parametre koji su podesivi i kako mogu da se pronađu.

Smernice za validaciju (pored smernica za klase rizika B i C): Provere na osnovu dokumentacije: • Proverite da li preduzete mere

odgovaraju visokom nivou zaštite u poređenju sa zahtevanim najvišim nivoom.

Primer prihvatljivog rešenja: • Parametri specifični za tip zapamćeni su na priključenom skladištu, koje je plombirano kako bi se

onemogućilo uklanjanje, ili direktno na senzorskoj jedinici. Upisivanje parametara je zabranjeno plombiranjem upisivog prekidača u onemogućeno stanje. Hronološki zapis revizija je moguć u kombinaciji sa zaštićenim hardverom (pogledajte P7).

• Podesivi parametri su zapamćeni na standardnom skladištu univerzalnog računara.




31

Smernice za validaciju (pored smernica za klase rizika B i C): Provere na osnovu izvornog kôda: • Proverite da li su preduzete mere za zaštiti parametara odgovarajuće.


U8: Autentičnost softvera i prikazivanje rezultata Treba da se koriste metode kojima se obezbeđuje autentičnost softvera koji podleže zakonskoj kontroli.

Garantovaće se autentičnost prikazanih rezultata.

Napomene: 1. Neće biti moguće na prevaru simulirati (prevariti) odobreni softver koji podleže

zakonskoj kontroli koriščenjem mogućnosti operativnog sistema ili drugih lako dostupnih i upravljivih alata.

2. Prikazani rezultati mogu da se prihvate kao autentični, ako prikazivanje obavlja softver koji podleže zakonskoj kontroli.

Napomene:

1. Ograničenje za 1BC, 2BC: Metode su obavezne radi zaštite od namerne zloupotrebe, uključujući simulaciju koja je zasnovana na dodatnom hardveru.

3. Prikazane vrednosti merenja treba da budu razumljive i u pratnji informacija koje su neophodne da bi se izbeglo mešanje sa drugim informacijama (koje ne podležu zakonskoj kontroli).

4. Razmatranjem mogućnosti operativnog sistema, na univerzalnom računaru će se tehničkim sredstvima obezbediti da samo odobreni softver čija svrha podleže zakonskoj kontroli, može da obavlja funkcije koje podležu zakonskoj kontroli (npr. senzor treba da radi samo sa odobrenim programom).

5. Tehničkim sredstvima treba da se obezbedi softveru koji podleže zakonskoj kontroli redovna provera njegovog integriteta i autentičnosti (vremenski intervali) tokom njegovog izvršavanja.

Potrebna dokumentacija: Dokumentacija treba da opiše na koji način će se garantovati autentičnost softvera.

Potrebna dokumentacija (pored dokumentacije koja je potrebna za klase rizika B i C): Treba prikazati preduzete mere zaštite.

Smernice za validaciju: Provere na osnovu dokumentacije: • Pregled treba da utvrdi da je softver koji podleže zakonskoj kontroli generisao

prikazivanje i kako se prevara putem programa koji ne podležu zakonskoj kontroli može sprečiti.

• Proverite da zadatke koji podležu zakonskoj kontroli može isključivo da obavlja odboreni softver koji podleže zakonskoj kontroli.

Funkcionalne provere: • Proverite posredstvom vizuelne kontrole da li se prikazivanje rezultata

adekvatno razlikuje od ostalih informacija koje se takođe mogu prikazati. • Proverite u skladu sa dokumentacijom da li su prikazane informacije

kompletne.

Smernice za validaciju (pored smernica za klase rizika B i C): Provere na osnovu

dokumentacije:



32

Primer prihvatljivog rešenja: Formalne metode: 1. Identifikacioni deo (B) softvera (zbir provere, broj verzije ili TEC broj, pogledajte U2) koji naznačava softver

se poredi sa željenom vrednošću u TEC. Tehničke metode: 1. Prozor aplikacije za merenje se generiše od strane softvera koji podleže zakonskoj kontroli. Potrebne

tehničke mere za prozor su: • Programima koji ne podležu zakonskoj kontroli treba da se zabrani pristup mernim vrednostima sve dok se

merne vrednosti ne navedu. • Prozor se povremeno osvežava. Pridruženi program proverava da li se nalazi na vrhu steka prozora i da

korisnici ne mogu da zatvore prozor ili da ga pomere van vidljivog prostora dogod se merenje ne završi. • Obrada mernih vrednosti se zaustavlja uvek kada se ovaj prozor zatvori ili kad nije u potpunosti vidljiv. Uputstvo za upotrebu (i TEC) treba da sadrže kopiju prozora u informativne svrhe. 2a Senzorska jedinica šifruje merne vrednosti sa ključem koji je poznat odobrenom softveru koji je instaliran na

univerzalnom računaru (npr. broj verzije). Samo odobreni softver može da dešifruje i koristi merne vrednosti, dok neodobreni programi na unverzalnom računaru ne mogu, jer ne znaju koji je ključ. Za upotrebu ključa pogledajte Dodatak T.

2b Pre slanja mernih vrednosti, senzor na univerzalnom računaru pokreće sekvencu rukovanja softverom koji podleže zakonskoj kontroli na osnovu tajnih ključeva. Samo ukoliko program na univerzalnom računaru komunicira ispravno, senzorska jedinica šalje svoje vrednosti merenja. Za upotrebu ključa pogledajte dodatak T.

3. Ključ koji se koristi u 2a/2b može da se izabere ili unese u senzorsku jedinicu i softver na univerzalnom računaru bez uništavanja plombe.

3. Ključ koji se koristi u 2a/2b je hash kôd programa na univerzalnom računaru. Svaki put kada se softver na univerzalnom računaru promeni, treba da se unese novi ključ u senzorsku jedinicu i plombira.


Potrebna dokumentacija (pored dokumentacija koja je potrebna za klase rizika B i C): Izvorni kôd softvera koji podleže zakonskoj kontroli.


Provere na osnovu izvornog kôda: • Proverite da li softver koji podleže zakonskoj kontroli generiše prikazane rezultate merenja. • Proverite da li su sve preduzete mere, kojima se garantuje autentičnost softvera, odgovarajuće i ispravne

(npr. zadaci koji podležu zakonskoj kontroli mogu da se obavljaju samo sa odobrenim softverom koji podleže zakonskkoj kontroli).

Klase rizika od B do E

U9: Uticaj drugih softvera Softver koji podleže zakonskoj kontroli treba da se izradi tako da ostali softveri ne mogu nedopustivo da utiču

na njega.

Napomene: 1. Ovaj zahtev podrazumeva razdvajanje softvera na softver koji podleže i koji ne podleže zakonskoj

kontroli na osnovu razmatranja najkvalitetnijeg softverskog inžinjeringa ili objektno orjentisanih koncepata. Treba pogledati dodatak S. Ovo je stadardan slučaj za univerzalne računare.

2. Savremeni operativni sistemi dozvoljavaju pregrađivanje jednog softverskog dela od drugog visokih perfomansi. Operativni sistem treba što je manje moguće da se konfiguriše za određenu svrhu merenja. Nepotrebne funkcije treba da se onemoguće ili deinstaliraju. Konfugiracione datoteke i skripte operativnog sistema koje uspostavljaju ovo razdvajanje treba zaštititi od izmena.


Pogledajte dodatak S. Smernice za validaciju:

Pogledajte dodatak S. Primer prihatljivog rešenja:

Pogledajte dodatak S.


33

6 Dodatak L: Dugoročno skladištenje mernih podataka

Ovo je dodatak koji sadrži posebne zahteve za ugrađeni softver za namenska merila (tip uslova P) i softver za merila koja koriste univerzalni računar (tip uslova U). On opisuje zahteve za skladištenje mernih podataka kada je merenje fizički dovršeno do tačke u vremenu kada su završeni svi procesi koje softver koji podleže zakonskoj kontroli treba da dovrši. Ovaj dodatak takođe može da se primeni na dugoročno skladištenje podataka.

6.1 Tehnički opis Skup zahteva iz ovog dodatka važi samo ako je uključeno dugoročno skladištenje mernih podataka. On se odnosi samo na one merne podatke koji podležu zakonskoj kontroli. U sledećoj tabeli su navedene tri različite tehničke konfiguracije za dugoročno skladištenje. Kod namenskog uređaja, uobičajena je varijanta integrisanog skladištenja: ovde je skladište deo metrološki neophodnog hardvera i softvera. Kod instrumenata koji koriste univerzalni računar, uobičajena je druga varijanta: upotreba postojećih resursa, npr. čvrstih diskova. Treća varijanta je prenosivo skladište: u ovom slujaču sladište može da ukloni sa uređaja, koji može da bude namenski uređaj ili univerzalni računar, i koji može da se odnese na neko drugo mesto. Kada se sa prenosivog skladišta preuzimaju podaci u zakonski primenjive svrhe, npr. vizualizacija, štampanje računa, itd., uređaj za preuzimanje podleže zakonskoj kontroli.

Integrisano skladište

Jednostavan instrument, koji je namenski, nema eksterne upotrebljive alate ili dostupna sredstava za uređivanje ili izmenu podataka, integrisano skladište za podatke merenja ili parametre, npr. RAM, fleš memorija, čvrsti disk. Skladište za uinverzalni računar

Univerzalni računar, grafički korisnički interfejs, višenamenski operativni sistem, zadaci koji podležu zakonskoj kontroli i koji ne podležu zakonskoj kontroli postoje paralelno, skladište može da se ukloni sa uređaja ili sadržaji mogu da se kopiraju bilo gde unutar ili van računara. Prenosivo ili daljinsko (eksterno) skladište

Arbitratni osnovni instrument (namenski instrument ili instrument koji koristi univerzalni računar), skladište može da se skine sa instrumenta. To mogu biti, na primer, flopi diskovi, fleš kartice ili daljinske baze podataka povezane putem mreže.

Tabela 6-1: Tehnički opis dugoročnih skadišta


34

6.2 Posebni softverski zahtevi za dugoročno skladištenje Zahtevi navedeni u ovom odeljku treba da se primenjuju uz jednan skup zahteva, za osnovne namenske instrumente ili za instrumente koji koriste univerzalni računar.

Klasa rizika B Klasa rizika C Klasa rizika D L1 Kompletnost zapamćenih mernih podataka

Zapamćene merne vrednosti moraju da sadrže sve odgovarajuće informacije potrebne za rekonstrukciju

prethodnog merenja.

Napomene: 1. Zapamćene merne vrednosti mogu biti potrebne za kasnije, npr. radi provere faktura. Svi podaci koji su

potrebni u zakonske i metrološke svrhe treba da budu zapamćeni zajedno sa mernim vrednostima. Potrebna dokumentacija:

Opis svih oblasti skupova podataka. Smernice za validaciju:


• Proverite da li su sve potrebne informacije za odgovarajuće zakonske i metrokoše potrebe sadržane u skupu podataka.

Primer prihvatljivog rešenja: • Zakonski i metrološki kompletan skup podataka se sastoji iz sledećih polja:

° Mernih vrednosti sa (s) sa tačnim rešenjem ° Zakonski ispravne jedinice merenja ° Cene za jedinicu ili cene koja treba da se plati (ako je primenjivo) ° Mesta i vremema merenja (ako je primenjivo) ° Identifikacije instrumenta ako je primenjivo (eksterno skladište)

• Podaci su zapamćeni sa istom rezolucijom, vrednostima, jedinicama itd. kao što je naznačeno ili odštampano na dostavnici.


Potrebna dokumentacija (pored dokumentacije koja je potrebna za klase rizika B, C i D): Izvorni kôd koji generiše skupove podataka za skladištenje.

Smernice za validaciju (pored smernica za klase rizika B, C i D): Provere na osnovu izvornog kôda:

• Proverite da li su skupovi podataka ispravno izrađeni.


35

Klasa rizika B Klasa rizika C Klasa rizika D L2: Zaštita od slučajnih ili nenamernih izmena Zapamćeni podaci moraju da se zaštite od slučajnih ili nenamernih izmena.

Napomene: 1. Fizički uticaji mogu da izazovu slučajne izmene. 2. Nenamerne izmene može da izazove korisnik uređaja. Obaveze vođenja podataka mogu zahtevati podatke

koji pripadaju plaćenim ili fakturama koje su istekle i koje s vremena na vreme treba da se brišu. Treba koristiti automatska ili polu-automatska sredstva kako bi se obezbedilo brisanje samo određenih podataka i izbegavanje slučajnog brisanja „živih“ podataka. Ovo je pogotovo važno za mrežne sisteme i daljinska i prenosiva skladišta kod kojih korisnici ne mogu da shvate značaj podataka.

3. Primalac treba da izračuna zbir provere i uporedi ga sa priloženom nomilanom vrednošću. Ako se vrednost podudara, skup podataka je validan i može da se koristi; u suprotnom, mora da se izbriše ili označi kao nevažeći.

Potrebna dokumentacija: Opis mera zaštite (npr. algoritam kontrolnog zbira, uključujući dužinu generatorskog polinoma).

Potrebna dokumentacija (pored dokumentacije koja je potrebna za klase rizika B i C): Dokumentacija će prikazati mere koje su preduzete za potvrdu efikasnosti mera zaštite.


• Proverite da li je generisan zbir provere za podatke. • Proverite da li softver koji podleže zakonskoj kontroli, koji čita podatke

i izračunava zbir provere, zaista upoređuje izračunate i nominarne vrednosti.

• Proverite da do zamene podataka ne može da dođe pre isteka perioda za skladištenje podataka koji je proizvođač predvideo i dokumentovao.

• Proverite da li je u slučaju da korisnik želi da izbriše datoteke sa podacima merenja izdato upozorenje.





• Proverite da li su preduzete mere odgovarajuće nivou visoke zaštite.

Primer prihvatljivog rešenja: • Da bi se otkrile izmene podataka nastale usled fizičkih uticaja, izračunava se zbir provere sa CRC-16

algoritmom za kompletan skup podataka i umeće u skup podataka koji treba da se zapamti. • Napomena: Algoritam nije tajan i nasuprot uslovu L3, nije ni inicijalan vektor CRC-registra, niti generatorski

polinom, odnosno zaveštalac u algoritmu. Inicijalni vektor i generatorski polinom su poznati programima koji kreiraju i verifikuju kontrolne zbirove.

• Datoteke merenih podataka/faktura mogu da se zaštite prilaganjem automatske oznake sa datumom prilikom kreiranja i zastavice ili etikete na kojima se navodi da li su fakture plaćene/neplaćene. Uslužni program može samo da briše/premešta datoteke, ako su fakture plaćene ili istekle.

• Merni podaci se neće brisati bez prethodne autorizacije, npr. izjave u dijalogu ili prozoru koji traži potvrdu brisanja.

• Merni podataci mogu automatski da se zamene ako postoji adekvatna zaštita zapisa koji treba da se sačuvaju. Parametar koji utvrđuje broj dana pre nego što merni podaci mogu da se izbrišu, može da se podesi ili zaštiti pri incijalnoj verifikaciji na osnovu potreba korisnika i veličine skladištenih podataka. Instrument će se zaustaviti ako je memorija puna i svi zapisi nedovoljno stari da se zamene. U tom slučaju se može izvršiti ručno brisanje (bez prethodnog odobrenja). U slučajevima kada je prekid merenja problematičan (npr. komunalna merila), veličina skladišta mora biti dovoljna da bi se izbegao prekid zbog nedovoljnog memorijskog prostora.


Potrebna dokumentacija (pored dokumentacije koja je potrebna za klase rizika B, C i D): Izvorni kôd koji ostvaruje zaštitu skladištenih podataka.

Smernice za validaciju (pored smernica za klase rizika B, C i D ):

Provere na osnovu izvornog kôda: • Proverite da li su preduzete mere za zaštitu zapamćenih podataka odgovarajuće i da li se pravilno sprovode.


36

Klasa rizika B Klasa rizika C Klasa rizika D L3: Integritet podataka

Zapamćeni merni podaci moraju da se zaštite od namernih izmena.

Napomene: 1. Ovaj zahtev se primenjuje na sve vrste

skladišta, osim na integrisana. 2. Zaštita mora da se primeni od namernih

izmena načinjenih od strane jednostavnih softverskih alata.

3. Jednostavni zajednički softverski alati su lako dostupni i upravljivi, kao što su npr. poslovni paketi.

Napomene: 1. Ovaj zahtev se primenjuje na sve vrste skladišta, osim

na integrisana. 2. Zaštita mora da se primeni od namernih izmena

sprovedenih od strane jednostavnih softverskih alata. 3. „Sofisticirani softverski alati“ su na primer funkcije za

otklanjanje grešaka, rekompajleri, alati za razvoj softvera, itd.

4. Nivo zaštite će biti isti kao onaj potreban za elektronsko plaćanje.

5. Zaštita se ostvaruje elektronskim potpisom sa algoritmom koji garantuje da nepostoji ni jedan isti rezultat potpisa u drugim skupovima podataka.

Napomena: Čak iako algoritam i ključ ispune visok nivo, tehničko rešenje sa standardnim personalnim računarom neće ostvariti ovaj nivo zaštite pod uslovom da nema odgovarajućih metoda zaštite programa koji potpisuju ili verifikuju skup podataka (pogledajte Osnovni vodič U za univerzalne računare, komentar na zahtev U6-D).

Potrebna dokumentacija: Treba da se dokumentuje metod kojim se obavlja zaštita.

Potrebna dokumentacija (pored dokumentacije koja je potrebna za klase rizika B i C): Treba prikazati preduzete mere.



• Ako se koristi zbir provere ili potpis: Proverite da li su zbir provere ili potpis

izrađeni za kompletan skup podataka. Proverite da li softver koji podleže zakonskoj kontroli, koji čita podatke i izračunava zbir provere ili dešifruje potpis, zaista upoređuje izračunate i nominalne vrednosti.

• Proverite da li se tajni podaci (npr. početna vrednost ključa ako se koristi) čuvaju u tajnosti od špijuniranja sa jednostavnim alatima.


• Proverite da li je program za povraćaj odbio faksifikovani skup podataka.




Primer prihvatljivog rešenja: Neposredno pre ponovnog korišćenja podataka, vrednost kontrolnog zbira se ponovno izračunava i upoređuje sa zapamćenom nominalnom vrednošću. Ako se vrednost podudara, skup podataka je važeći i može da se koristi; u suprotnom mora da se izbriše ili označi kao nevažeći. Prihvatljivo rešenje je algoritam CRC-16. Napomena: Algoritam nije tajan, ali nasuprot uslovu L2, inicijalni vektor CRC-registratora ili generatorski polinom (odnosno delilac u algoritmu) mora da bude. Inicijalni vektor i generatorski polinom su poznati samo programima koji generišu i verifikuju kontrolne zbirove. S njima mora da se postupa kao sa ključevima (pogledajte L5).

Primer prihvatljivog rešenja: Umesto CRC-a, izračunava se potpis. Odgovarajući algoritam potpisa bi bio jedan od hash algoritama, npr. SHA-1 ili RipeMD160, u kombinaciji sa šifrovanim algoritomom kao što su RSA ili Elliptic Curves. Minimalna dužina ključa je 768 bita (RSA) ili 128-160 bita (EC).


37


Potrebna dokumentacija (pored dokumentacije koja je potrebna za klase rizika B i C): Izvorni kôd koji ostvaruje integritet zapamćenih podataka.


Provere na osnovu izvornog kôda: • Proverite da li su preduzete mere za zaštitu zapamćenih podataka odgovarajuće i da li se pravilno sprovode.

Klasa rizika B Klasa rizika C Klasa rizika D L4 Autentičnost zapamćenih mernih podataka Zapamćeni merni podaci moraju biti u stanju da mogu da se autentično prate unazad do merenja koje ih je

izradilo.

Napomene: 1. Autentičnost mernih podataka može biti potrebna za kasnije, npr. za proveru faktura. 2. Autentičnost zahteva ispravno dodeljivanje (povezivanje) mernih podataka sa merenjem koje je izradilo.

podatke. 3. Autentičnost pretpostavlja identifikaciju skupova podataka. 4. Da bi se obezbedila autentičnost, šifrovanje podataka nije nužno potrebno.


Opis metode koja se koristi za obezbeđivanje autentičnosti.

Potrebna dokumentacija (pored dokumentacije koja je potrebna za klase rizika B i C): Treba prikazati preduzete mere zaštite.



• Proverite da li postoji ispravno povezivanje između svake merne vrednosti i pripadajućeg merenja.

• Ako se koriste zbir provere ili potpis, proverite jesu li zbir provere ili potpis izrađeni za kompletan skup podataka.

• Proverite da li se tajni podaci (npr. početna vrednost ključa ako se koristi) čuvaju u tajnosti od špijuniranja sa jednostavnim alatima.


• Proverite da li su odgovarajući zapamćeni podaci i podaci odštampani na etiketi ili fakturi identični.




Primer prihvatljivog rešenja: Zapamćeni skup podataka sadrži sledeća polja za podatke (pored polja definisanih u L3): • Jedinstveni (trenutni) identifikacioni broj. Identifikacioni broj se kopira i na dostavnicu. • Vreme kada je merenje izvršeno (vremenska oznaka). Vremenska oznaka se takođe kopira i na dostavnicu. • Identifikacija merila koje je generisalo vrednost. • Potpis koji se koristi za obezbeđivanje integriteta podataka može istovremeno da se koristi za obezbeđivanje

autentičnosti. Potpis obuhvata sva polja iz skupa podataka. Pogledajte zahtev L2, L3. • Etiketa može da navede da merne vrednosti mogu da se porede sa referentnim podacima na uređajima za

skladištenje koji podležu zakonskoj kontroli. Naimenovanje je prikazano poređenjem indentifikacionog broja ili vremenske oznake koja je odštampana na dostavnici sa onima koji su na zapamćenom skupu podataka.


Potrebna dokumentacija (pored dokumentacije koja je potrebna za klase rizika B i C): Izvorni kôd koji generiše skupove podataka za skladištenje i ostvaruje potvrdu identiteta.


Provere na osnovu izvornog kôda: • Proverite da li su skupovi podataka ispravno izrađeni i pouzdano autorizovani.


38

Klasa rizika B Klasa rizika C Klasa rizika D L5: Poverljivost ključeva Sa ključevima i pratećim podacima mora da se postupa kao sa podacima koji podležu zakonskoj kontroli i oni

moraju da se čujavu u tajnosti i štite softerskim alatima od kompromitovanja.

Napomene: 1. Ovaj zahtev važi samo ako se koristi tajni ključ. 2. Ovaj zahtev važi za pamćenje mernih podataka, koji su

eksterni na merilima ili koji se realizuju na unverzalnim računarima.

3. Zaštita mora da se primeni na namerne izmene koju sprovode zajednički jednostavni softverski alati.

4. Ako je pristup tajnom ključu onemogućen, npr., plombiranjem kućišta ili namenskog uređaja, nisu potrebna dodatna sredstva za zaštitu softvera.

Napomene: 1. Ovaj zahtev se primenjuje na skladište koje

se nalazi na univerzalnim računarima i na eksterno skladište.

2. Zaštita mora da se primeni na namerne izmene koju sprovode zajednički jednostavni softverski alati.

3. Koristiće se odgovarajuće metode koje su iste kao za elektronsko plaćanje. Korisnik mora biti u mogućnosti da verifikuje autentičnost javnog ključa.


Opis upravljanja ključevima i sredstava za čuvanje ključeva i pridruženih tajnih informacija.

Potrebna dokumentacija: (pored dokumentacije koja je potrebna za klase rizika B i C): Treba prikazati mere koje su preduzete za zaštitu.



• Proverite da tajnost informacija neće biti ugrožena.



Primer prihvatljivog rešenja: Tajni ključ i prateći podaci se čuvaju u binarnom formatu u izvršnom kôdu softvera koji podleže zakonskoj kontroli. Stoga nije jasno na kom nalogu ovi podaci treba da se čuvaju. Softverski sistem ne nudi nikakve funkcije za prikaz ili uređivanje ovih podataka. Ako se CRC algoritam koristi kao potpis, inicijalni vektor ili generatorski polinom imaju ulogu ključa.

Primer prihvatljivog rešenja: Tajni ključ je zapamćen u hardverskom delu koji može fizički da se plombira. Softver ne nudi nikakve funkcije za prikaz ili uređivanje ovih podataka. Napomena: Tehničko rešenje sa standardnim ličnim računarom ne bi bilo dovoljno da se osigura visok nivo zaštite ako nema odgovarajućih sredstava hardverske zaštite za ključ i ostale tajne podatke (pogledajte osnovni vodič za univerzalne računare U6).

1) Infrastruktura javnih ključeva: Javni ključ skladišta koji podleže zakonskoj kontroli je sertifikovan od strane ovlašćenog Centra za pouzdanost.

2) Direktna pouzdanost: Nije neopodno uključiti centar za pouzdanost ako su obe strane, po prethodnom dogovoru, u mogućnosti direktno da čitaju javni ključ merila na uređaju koji podleže zakonskoj kontroli a koje prikazuje odgovarajući skup podataka.


Potrebna dokumentacija (pored dokumentacije koja je potrebna za klase rizika B i C): Izvorni kôd koji realizuje upravljanje ključem.


Provere na osnovu izvornog kôda: • Proverite da li su preduzete mere za upravljanje ključem odgovarajuće.


39


L6: Povraćaj zapamćenih podataka Softver koji se koristi za verifikaciju zapamćenih skupova mernih podataka treba da prikažu ili odštampaju

podatke, provere ima li izmena na podacima, i upozore da li je došlo do izmena. Podaci otkriveni kao oštećeni ne

smeju da se koriste.

Napomene: 1. Zapamćeni merni podaci će možda biti potrebni kasnije, npr. za ispitane transakcije. Ako postoji sumnja na

ispravnost dostavnice ili etikete, treba omogućiti identifikaciju zapamćenih mernih podataka sa spornim merenjem bez dvosmislenosti (pogledajte takođe L1, L3, L4 i L5).

2. Identifikacioni broj (pogledajte L1) mora biti odštampan na dostavnici/etiketi za korisnika zajedno sa obrazloženjem i pozivanjem na skladištenje koje podleže zakonskoj kontroli.

3. Verifikacija podrazumeva proveru integriteta, autentičnosti i ispravno dodeljivanje zapamćenih mernih podataka.

4. Verifikacioni softver koji se koristi za prikazivanje ili štampanje zapamćenih podataka podleže zakonskoj kontroli.

5. Za zahteve specifične za instrument, pogledajte Dodatak I.

Potrebna dokumentacija: • Opis funkcija programa za povraćaj. • Opis otkrivanja oštećenja. • Uputstvo za upotrebu za ovaj program.




• Proverite da li softver za povraćaj upoređuje izračunate i nominalne vrednosti.

• Proverite da li je softver za povraćaj deo softvera koji podleže zakonskoj kontroli.


• Proverite da li program otkriva oštećene skupove podataka.

• Izvršite nasumične provere i verifikujte da povraćaj obezbeđuje sve potrebne informacije.



Primer prihvatljivog rešenja: Skup podataka se iz skladišta čita pomoću programa za verifikovanje, a potpis za sva polja sa podacima se ponovo izračunava i upoređuje sa zapamćenom nominalnom vrednošću. Ako se obe vrednosti podudare, skup podataka je ispravan, u suprotnom se podaci ne koriste i brišu ili ih program označava nevažećim.


Potrebna dokumentacija (pored dokumentacije koja je potrebna za klase rizika B i C): Izvorni kôd programa za povraćaj.


Provere na osnovu izvornog kôda: • Proverite jesu li preduzete mere za povraćaj, verifikaciju potpisa itd. odgovarajuće i da li se pravilno sprovode.


40

Klasa rizika B Klasa rizika C Klasa rizika D L7: Automatsko skladištenje

Podaci merenja moraju automatski da se skladište kada se merenje završi.

Napomene: 1. Ovaj zahtev se primenjuje na sve vrste skladišta. 2. Ovaj zahtev znači da funkcija skladištenja ne sme da zavisi od odluke operatera. Ipak, kod nekih vrsta

instrumenata, npr. merila, se traži odluka ili komanda operatera o tome da li se rezultati prihvataju ili ne. Drugim rečima, možda postoje neka srednja merenja koja neće biti zapamćena (na primer tokom učitavanja ili pre nego što se količina zahtevanog prozivoda nađe na prijemniku opterećenja). Međutim, čak i u ovom slučaju će se rezultati automatski pamtiti nakon što operater prihvati rezultate.

3. Kod slučajeva celokupnog skladištenja, pogledajte zahtev L8.


Potvrda da je skladištenje automatski obavljeno. Opis grafičkog korisničkog interfejsa.



• Proverite nasumičnim proverama da su merne vrednosti automatski zapamćene nakon merenja ili da je prihvatanje merenja dovršeno. Proverite da nema dugmadi ili stavki menija koje prekidaju ili onemogućavaju automatsko skladištenje.

Primer prihvatljivog rešenja: Nepostoje stavke menija ili dugmad u grafičkom korisničkom interfejsu (GUI) koja podržavaju ručno pokretanje skladištenja mernih rezultata. Vrednosti merenja su uvijene u skup podataka zajedno sa dodatnim informacijama kao što su vremenska oznaka i potpis odmah nakon merenja, odnosno prihvatanja merenja.




Provere na osnovu izvornog kôda: • Proverite da li su preduzete mere za automatsko skladištenje odgovarajuće i da li se pravilno sprovode.


41

Klasa rizika B Klasa rizika C Klasa rizika D L8: Kapacitet i kontinuitet skladišta

Dugoročno skladište mora da ima kapacitet koji je dovoljan za svhru.

Napomene: 1. Kada je skladište puno ili uklonjeno/isključeno iz instrumenta, biće dato upozorenje operateru. Upozorenje

nije neophodno, ako je strukturom obezbeđeno da se samo zastareli podaci mogu zameniti. Za dodatne neophodne radnje, pogledajte specifične uslove za merila (Dodatak I).

2. Uredba koja se odnosi na minimalan period za skladištenje mernih podataka ne potpada pod ovaj zahtev, već pod nacionalne propise. Vlasnik ima obavezu da poseduje instrument koji ima dovoljnan kapacitet skladišta kako bi ispunio uslove koji su primenjivi za njegovu aktivnost. Notifikovano telo za EC isptivanje tipa će samo proveriti da li su podaci zapamćeni i ispravno preuzeti i da li se novi prenosi blokiraju kada je skadište puno.

3. Takođe je izvan obima ovog zahteva zahtevati određene natpise na uređaju koji se tiču kapaciteta skladišta ili neke druge prateće informacije koje dozvoljavaju izračunavanje kapaciteta. Međutim, proizvođač treba da dostavi informacije o kapacitetu.


Opis upravljana izuzetnim slučajevima prilikom pamćenja mernih vrednosti. Smernice za validaciju:


• Proverite da li je proizvođač naveo kapacitet skladišta ili formulu za njegovo izračunavanje. • Proverite da do zamene podataka ne može da dođe pre isteka perioda za pamćenje podataka koji je

proizvođač predvideo i dokumentovao. Funkcionalne provere:

• Proverite da li je korisniku izdato upozorenje u slučaju da želi da izbriše datoteke koje sadrže podatke merenja (ako je brisanje uopšte moguće).

• Proverite da li je upozorenje izdato ako je skladište puno ili uklonjeno.

Primer prihvatljivog rešenja: • Kod merenja sa prekidima koja mogu lako i brzo da se zaustave, npr. merenje, merenje goriva, itd.,

merenje može da se dovrši čak iako skladište postane nedostupno. Merilo ili uređaj treba da imaju bafer koji je dovoljno velik za pamćenje trenutnog prenosa. Nakon toga, ni jedan novi prenos ne može da se pokrene, a baferovane vrednosti se čuvaju za kasniji prenos na novo skladište.

• Merenja koja se ne prekidaju, npr. merenje energije, zapremine, itd., ne trebaju poseban srednji bafer jer su ta merenja uvek kumulativna. Kumulativni registar može kasnije da se pročita i prenese do skladišta, kada skladište bude ponovo dostupno.

• Merni podaci mogu automatski da se zamene uslužnim programom koji proverava jesu li merni podaci zastareli (odnosi se na nacionalne propise za odgovarajući vremenski period) ili da li je faktura plaćena. Uslužni program će od korisnika tražiti dozvolu za brisanje i podaci će se brisati redom počev od najstarijih.)


Potrebna dokumentacija (pored dokumentacije koja je potrebna za klase rizika B, C i D): Izvorni kôd koji ostvaruje pamćenje podataka.


Provere na osnovu izvornog kôda: • Proverite da li su preduzete mere za skadištenje odgovarajuće i da li se pravilno sprovode.


42

7 Dodatak T: Prenos mernih podatak putem komunikacione mreže

Ovo je dodatak za softverske zahteve za osnovne vodiče P i U. On mora da se koristi samo ako se merni podaci prenose putem komunikacionih mreža na udaljeni uređaj na kom se dalje obrađuju i/ili se koriste u svrhe koje podležu zakonskoj kontroli. Ovaj dodatak ne važi ako nema naknadne obrade podataka koja podleže zakonskoj kontroli. Ako se softver preuzima na uređaj koji podleže zakonskoj kontroli, primenjuju se zahtevi iz dodatka D.

7.1 Tehnički opis Skup zahteva iz ovog dodatka se primenjuje samo ako je uređaj koji se razmatra povezan na mrežu i prenosi ili prima merne podatke koji podležu zakonskoj kontroli. U sledećoj tabeli su definisane tri mrežne konfiguracije. Najjednostavnija je niz uređaja i svi oni podležu zakonskoj kontroli. Učesnici (uređaji) su nepromenjivi kod zakonske verifikacije. Varijanta ovome (zatvorena mreža, delimično podleže zakonskoj kontroli) je mreža sa učesnicima (uređajima) koji ne podležu zakonskoj kontroli, ali su svi poznati i tokom rada se ne menjaju. Otvorena mreža nema ograničenja po pitanju identiteta, funkcionalnosti, prisustva i lokacije učesnika.

Opis konfiguracija Zatvorena mreža, u potpunosti podleže zakonskoj kontroli Samo je nepromenjiv broj učesnika (uređaja) sa jasnim identitetom, funkcionalnošću i lokacijom povezan. Svi uređaji podležu zakonskoj kontroli. Nema ni jednog uređaja u mreži koji ne podleže zakonskoj kontroli. Zatvorena mreža, delimično podleže zakonskoj kontroli Fiksni broj učesnika (uređaja) sa jasnim identitetom i lokacijom je povezano na mrežu. Ne podležu svi uređaji zakonskoj kontroli, te je stoga njihova funkcionalnost nepoznata. Otvorena mreža Arbitrarni učesnici (uređaji sa arbitrarnim funkcijama) mogu da se povežu na mrežu. Identitet i funkcionalnost uređaja koji učestvuje može da bude nepoznat ostalim učesnicima. Bilo koja mreža koja sadrži uređaje koji podležu zakonskoj kontroli sa IR ili bežični mrežni komunikacioni interfejsi se smatraju otvorenom mrežom.

Tabela 7-1: Tehnički opis komunikacione mreže.


43

7.2 Posebni softverski zahtevi za prenos podataka Klasa rizika B Klasa rizika C Klasa rizika D

T1: Kompletnost prenesenih podataka Preneseni podaci moraju da sadrže sve relevantne informacije koje su potrebne za prikazivanje ili za dalju

obradu rezultata merenja u prijemnoj jedinici.

Napomene: 1. Metrološki deo skupa podataka koji se prenose sastoji se iz jedne ili više vrednosti merenja sa tačnim

rešenjem, zakonski ispravne merne jedinice, i zavisi od od primene jedinične cene ili cene koja treba da se plati i mesta merenja.


• Dokumentujte sva polja skupa podataka. Smernice za validaciju:


• Proverite da li su sve informacije za dalju obradu mernih vrednosti u prijemnoj jedinci nalaze u skupu podataka.

Primer prihvatljivog rešenja: Skup podataka se sastoji iz sledeća polja: • Mernih vrednosti sa tačnim rešenjem • Zakonski ispravne jedinice merenja • Jedinične cene ili cena koja treba da se plati (ako je primenjivo) • Vremena i datuma merenja (ako je primenjivo) • Identifikacije instrumenta ako je primenjivo (prenos podataka) • Mesta merenja (ako je primenjivo)


Potrebna dokumentacija (pored dokumentacije koja je potrebna za klase rizika B, C i D): Izvorni kôd koji generiše skup podataka za prenos.



• Proverite da li su skupovi podataka ispravno izrađeni.


44


T2: Zaštita od slučajnih ili nenamernih izmena

Preneseni podaci će se zaštititi od slučajnih ili nenamernih izmena.

Napomene: 1. Fizički uticaji mogu izazvati slučajne izmene podataka. 2. Korisnik uređaja može izazvati nenamerne izmene. 3. Treba da se obezbede metode kojima će se otkriti greške u prenosu.

Potrebna dokumentacija: Opis algoritma kontrolnog zbira, ako se koristi, uključujući dužinu generatorskog polinoma. Opis alternativnog metoda ako se koristi.

Potrebna dokumentacija (pored dokumentacije koja je potrebna za klase rizika B i C): Dokumentacija će prikazati mere koje su preduzete za potvrdu efikasnosti mera zaštite.



• Proverite da li je izrađen zbir provere podataka. • Proverite da li softver koji podleže zakonskoj kontroli koji prima

podatke ponovo izračunava zbir provere i poredi ga sa nominalnom vrednošću koja se nalazi u skupu podataka.



• Proverite da li su preduzete mere odgovarajuće za visok nivo zaštite.

Primer prihvatljivog rešenja: 1) Da biste otkrili izmene na podacima, zbir provere sa CRC-16 algoritmom se izračunava za sve bajtove skupa

podataka koji treba da se prenesu. Neposredno pre no što se podaci ponovo koriste, primalac ponovo izračunava vrednost kontrolnog zbira i poredi je sa priloženom nominalnom vrednošću. Ako se vrednost podudara, skup podataka je važeći i može da se koristi, u suprotnom mora da se izbriše ili označi kao nevažeći.

Napomena: Algoritam nije tajan i nasuprot zahtevu T3, nije ni inicijalni vektor CRC-registratora, niti generatorski polinom tj. delilac algoritma. Incijalni vektor i generatorski polinom su poznati programima koji kreiraju i verifikuju kontrolne zbirove. 2) Koristite sredstva koja su obezbeđena protokolima za prenos, npr. TCP/IP, IFSF.


Potrebna dokumentacija (pored dokumentacija koja je potrebna za klase rizika B, C i D): Izvorni kôd koji ostvaruje zaštitu prenesenih podataka.

Smernice za validaciju (pored smernica za klase rizika B, C i D ):

Provere na osnovu izvornog kôda: • Proverite da li su preduzete mere za zaštitu prenesenih podataka odgovarajuće.


45

Klasa rizika B Klasa rizika C Klasa rizika D T3: Integritet podataka

Preneseni podaci koji podležu zakonskoj kontroli moraju softveskim alatima da se zaštite od namernih izmena.

Napomene: 1. Ovaj zahtev se primenjuje samo na mreže koje su

otvorene ili samo za one koje podležu delimičnoj zakonskoj kontroli, i ne primenjuje se na zatvorene mreže.

2. Zaštita mora da se primeni protiv namernih izmena koje sprovode zajednički jednostavni softverski alati.

3. Jednostavni zajednički softverski alati su lako dostupni i upravljivi alati, kao što su npr. poslovni paketi.

Napomene: 1. Ovaj zahtev se primenjuje na otvorene mreže i

zatvorene mreže koje delimično podležu zakonskoj kontroli.

2. Zaštita se ostvaruje elektronskim potpisom sa algoritmom koji garantuje da nema identičnih rezultata potpisa u ostalim skupovima podataka.

3. Zaštita mora da se primeni protiv namernih izmena koje sprovode posebni sofisticirani softverski alati.

4. „Sofisticirani softverski alati“ su, na primer, funkcije za otklanjanje grešaka, rekompajleri, alati za razvoj softvera, itd.

5. Nivo zaštite treba da bude jednak onom koji je potreban za elektronsko plaćanje.

Napomena: Čak iako algoritam i ključ ispune visok nivo, tehničko rešenje sa standardnim personalnim računarom neće ostvariti ovaj nivo zaštite pod uslovom da nema odgovarajućih metoda zaštite programa koji potpisuju ili verifikuju skup podataka (pogledajte Osnovni vodič U za univerzalne računare, komentar na zahtev U6-D).

Potrebna dokumentacija :

Opis metode zaštite.




• Ako se koristi zbir provere ili potpis: Proverite da li su zbir provere ili potpis izrađeni za

celokupan skup podataka. Proverite da li softver koji podleže zakonskoj

kontroli, koji podatke podatke, ponovo izračunava zbir provere ili dešifruje potpis i poredi ga sa nominalnom vrednošću u skupu podataka.

• Proverite da li se tajni podaci (npr. početna vrednost ključa ako se koristi) štite u tajnosti sa jednostavnim alatima od špijuniranja.




Primer prihvatljivog rešenja: • Zbir provere je generisan iz skupa podataka koji

treba da se prenese. Neposredno pre ponovnog korišćenja podataka, vrednost kontrolnog zbira se ponovno izračunava i upoređuje sa nominalnom vrednošću koja se nalazi u primljenom skupu podataka. Ako se vrednost podudara, skup podataka je važeći i može da se koristi; u suprotnom mora da se izbriše ili označi kao nevažeći.

• Prihvatljivo rešenje je algoritam CRC-16. Napomena: Algoritam nije tajan, ali nasuprot uslovu T2, inicijalni vektor CRC-registratora ili generatorski polinom (odnosno delilac u algoritmu) su tajni. Inicijalni vektor i generatorski polinom su poznati samo programima koji generišu i verifikuju kontrolne zbirove. Sa njima mora da se postupa kao sa ključevima (pogledajte T5).

Primer prihvatljivog rešenja: • Umesto CRC-a, izračunava se potpis.

Odgovarajući algoritam potpisa bi bio na primer jedan od hash algoritama, npr. SHA-1 ili RipeMD160, u kombinaciji sa šifrovanim algoritomom kao što su RSA ili Elliptic Curves. Minimalna dužina ključa je 768 bita (RSA) ili 128-160 bita (EC).

• Zaštita je obezbeđena nekim protokolima za prenos, npr. HTTPS


46

Dodaci za klasu rizika E Potrebna dokumentacija (pored dokumentacije koja je potrebna za klase rizika B i C): Izvorni kôd koji ostvaruje integritet prenesenih podataka.


Provere na osnovu izvornog kôda: • Proverite da li su preduzete mere za garantovanje integriteta prenesenih podataka odgovarajuće.

Klasa rizika B Klasa rizika C Klasa rizika D T4: Autentičnost prenesenih podataka

Prijemni program prenesenih odgovarajućih podataka, treba da može da verifikuje autentičnost i dodelu

mernih vrednosti određenom merenju.

Napomene: 1a U mreži koja ima nepoznate učesnike (uređaje), potrebno je bez dvosmislenosti identifikovati poreklo

podataka merenja koji su preneseni. (Autentičnost se oslanja na identifikacioni broj skupa podataka i mrežnu adresu).

1b U zatvorenoj mreži svi učesnici su poznati. Nisu potrebna dodatna IT sredstva, već će topologija mreže (broj učesnika) ostati nepromenjiva pečaćenjem.

2. Nepredviđena kašnjenja su tokom prenosa moguća. Za ispravno dodeljivanje primljenih mernih vrednosti određenom merenju, mora se beležiti vreme merenja.

3. Kako bi se obezbedila autentičnost, šifrovanje mernih podataka nije nužno potrebno.

Potrebna dokumentacija: Mreža sa nepoznatim učesnicima: Opis IT mera za ispravno dodeljivanje mernih vrednosti merenju. Zatvorena mreža: Opis hardverskih sredstava koja čuvaju broj učesnika u mreži. Opis inicijalne identifikacije učesnika.




• Proverite da li postoji ispravno povezivanje između vrednosti merenja i odgovarajućeg merenja.

• Proverite da li su podaci digitalno potpisani kako bi se obezbedila njihova tačna identifikacija i provera identiteta.



Primer prihvatljivog rešenja: • Svaki skup podataka ima jedinstven (trenutni) identifikacioni broj, koji može da sadrži vreme kada je

merenje obavljeno (vremenska oznaka). • Svaki skup podataka sadrži informacije o poreklu podataka merenja, odnosno serijski broj ili identitet merila

koje je generisalo vrednost. • U mreži sa nepoznatim učesnicima, autentičnost se garantuje ako skup podataka nosi nedvosmisleni

potpis. Potpis obuhvata sva ta polja iz skupa podataka. • Primalac skupa podataka provera prihvatljivost svih podataka.


Potrebna dokumentacija (pored dokumentacije koja je potrebna za klase rizika B i C): Izvorni kôd uređaja za slanje i primanje.


Provere na osnovu izvornog kôda: • Proverite da li su preduzete mere za garantovanje autentičnosti prenesenih podataka odgovarajuće.


47


T5: Poverljivost ključeva Sa ključevima i pratećim podacima mora da se postupa kao sa podacima koji podležu zakonskoj kontroli i oni

moraju da se čuvaju u tajnosti i softerskim alatima štite od kompromitovanja.

Napomene: 1. Ovaj uslov se primenjuje samo ako u sistemu postoji tajni

ključ. (Obično se ne nalazi u zatvorenim mrežama). 2. Zaštita mora da se primeni na osnovu namernih izmena

sprovedenih zajedničkim jednostavnim softverskim alatima.

3. Ako je sprečen pristup tajnim ključevima npr. pečaćenjem kućišta namenskog uređaja, dodatna softverska zaštita nije potrebna.

Napomene: 1. Ovaj uslov se primenjuje samo ako u sistemu

postoji tajni ključ. (Obično se ne nalazi u zatvorenim mrežama).

2. Zaštita mora da se primeni protiv namernih izmena sprovedenih zajedničkim sofisticiranim softverskim alatima.

3. Primljene vrednosti merenja se čitaju iz skupa podataka i njihov potpis se proverava pomoću javnog ključa otpremnog merila (ili uređaja koji izrađuje odgovarajući skup podataka). Primalac pomoću ove provere može da dokaže da vrednost i potpis pripadaju jedno drugom.

4. Koristiće se odgovarajuće metode koje su iste kao za elektronsko plaćanje.


Opis upravljanja ključem i metodama za čuvanje ključeva i sličnih informacija o tajnama.




• Proverite da tajne informacije ne mogu da se ugroze.



Primer prihvatljivog rešenja: Tajni ključ i prateći podaci se čuvaju u binarnom formatu u izvršnom kôdu softvera koji podleže zakonskoj kontroli. Stoga nije jasno na kom nalogu ovi podaci treba da se čuvaju. Softverski sistem ne nudi nikakve funkcije za prikaz ili uređivanje ovih podataka. Ako se CRC algoritam koristi kao potpis, inicijalni vektor ili generatorski polinom imaju ulogu ključa.

Primer prihvatljivog rešenja: Tajni ključ je zapamćen u hardverskom delu koji može fizički da se plombira. Softver ne nudi nikakve funkcije za prikaz ili uređivanje ovih podataka. Napomena: Tehničko rešenje sa standardnim ličnim računarom ne bi bilo dovoljno da se osigura visok nivo zaštite ako nema odgovarajućih sredstava hardverske zaštite za ključ i ostale tajne podatke (pogledajte osnovni vodič za univerzalne računare U6).

3) Infrastruktura javnih ključeva: Javni ključ skladišta koji podleže zakonskoj kontroli je sertifikovan od strane ovlašćenog Centra za pouzdanost.

1) Direktna pouzdanost: Nije neopodno uključiti centar za pouzdanost po prethodnom dogovoru, ako su obe strane u mogućnosti direktno da čitaju javni ključ merila na uređaju koji podleže zakonskoj kontroli koji prikazuje odgovarajući skup podataka.


48


Potrebna dokumentacija (pored dokumentacije koja je potrebna za klase rizika B i C): Izvorni kôd koji ostvaruje upravljanje ključem.


Provere na osnovu izvornog kôda: • Proverite da li su preduzete mere za upravljanje ključem odgovarajuće.


T6: Rukovanje oštećenim podacima

Podaci koji su otkriveni kao oštećeni ne smeju da se koriste.

Napomene: 1. Iako komunikacioni protokoli obično ponavljaju prenos sve dok ne uspe, ipak je moguće da se primi oštećeni

skup podataka.

Potrebna dokumentacija: Opis otkrivanja grešaka u prenosu ili namernih izmena.

Potrebna dokumentacija (pored dokumentacije koja je potrebna za klase rizika B i C): Treba prikazati preduzete mere za ispravno rukovanje oštećenim podacima.


Provere na osnovu dokumentacije i funkcionalnih provera:

• Proverite da se oštećeni podaci neće koristiti na osnovu isporučenog koncepta



Primer prihvatljivog rešenja: Kada program koji prima skupove podataka otkrije raskorak između skupa podataka i nominalne vrednosti potpisa, on prvo pokušava da rekonstruiše originalnu vrednost ako je dosupno više informacija. Ako rekonstrukcija ne uspe, on izdaje upozorenje korisniku, ne izbacuje mernu vrednost i

• postavlja zastavicu u posebno polje skupa podataka (polje statusa) sa značenjem „nije važeće“

ILI

• briše oštećeni skup podataka.


Potrebna dokumentacija (pored dokumentacije koja je potrebna za klase rizika B i C): Izvorni kôd prijemnog uređaja.


Provere na osnovu izvornog kôda: • Proverite da li su preduzete mere za rukovanje oštećenim podacima odgovarajuće.


T7: Kašnjenje prenosa

Kašnjenje prenosa ne sme nedozvoljeno da utiče na merenje.

Napomene: Proizvođač mora da istraži merenje vremena prenosa podataka i garantuje da se i pod najgorim uslovima neće nedozvoljeno uticati na merenje.


Opis koncepta, kako je merenje zaštićeno od kašnjena prenosa.


• Proverite koncept i da kašnjenje prenosa ne utiče na merenje.


Implementacija protokola prenosa za field buses (industrijske mrežne sisteme).


49


Potrebna dokumentacija (pored dokumentacije koja je potrebna za klase rizika B i C): Izvorni kôd koji ostvaruje prenos podataka.


Provere na osnovu izvornog kôda: • Proverite da li su preduzete mere za rukovanje kašnjenjem prenosa odgovarajući.

Klasa rizika B Klasa rizika C Klasa rizika D T8: Dostupnost usluga prenosa

Ako mrežne usluge postanu nedostupne, ni jedan merni podataka ne sme da se izgubi.

Napomene: 1. Korisnik sistema merenja ne sme biti u mogućnosti da ošteti podatke merenja sprečavanjem prenosa. 2. Poremećaji u prenosu dešavaju se slučajno i ne mogu da se izuzmu. Otpremni uređaj mora biti u stanju da

upravlja ovom situacijom. 3. Reakcija instrumenta ukoliko usluge prenosa postanu nedostupne zavisi od principa merenja (pogledajte Deo

I).


Opis mera zaštite u slučaju prekida prenosa ili drugih otkazivanja.


• Proverite implementirane metode radi zaštite od gubitka podataka. • Proverite koje mere su predviđene u slučaju greške kod prenosa. Funkcionalne provere:

• Nasumične provere će pokazati da li su odgovarajući podaci izgubljeni usled prekida prenosa. Primer prihvatljivog rešenja: 1) Kod merenja koja se prekidaju koja mogu lako i brzo da se zaustave, npr. merenje, merenje goriva, itd.,

merenje može da se dovrši čak iako prenos ne radi. Međutim, merilo ili uređaj za slanje koji podležu zakonskoj kontroli, mora da ima bafer koji je dovoljno velik za skladišti trenutnu transkaciju. Nakon ovoga, ni jedna nova transakcija ne može da se pokrene, a baferovane vrednosti se čuvaju za kasniji prenos. Za ostale primere, pogleajte deo I.

2) Merenja koja se ne prekidaju, npr. merenje energije, zapremine, itd., ne trebaju poseban srednji bafer jer su ta merenja uvek kumulativna. Kumulativni registar može kasnije da se pročita i prenosi kada je veza ponovo proradi.


Potrebna dokumentacija (pored dokumentacije koja je potrebna za klase rizika B i C): Izvorni kôd koji ostvaruje prenos podataka.


Provere na osnovu izvornog kôda: • Proverite jesu li preduzete mere za reagovanje na uslugu prekinutog prenosa odgovarajuće.


50

8 Dodatak S: Razdvajanje softvera

Razdvajanje softvera je opcionalna metodologija izrade koja proizvođaču omogućava jednostavnu izmenu softvera koji podleže zakonskoj kontroli. Ako je razdvajanje softvera primenjeno, onda se ovaj dodatak uzima u ozbir pored osnovnih zahteva za tipove P i U.

8.1 Tehnički opis Softver koji kontroliše merila ili sisteme generalno složeno funkcioniše i sadrži module koji podležu zakonskoj kontroli i module koji ne podležu. Bilo bi korisno za proizvođača i ispitivača – iako nije propisano - da razdvoje ove softverske module unutar mernog sistema.

U sledećoj tabeli opisane su dve varijante razdvajanja softvera. Obe varijante su obuhvaćene skupom zahteva.

Opis Softver se razdvaja nezavisno od operativnog sistema u okvir domena aplikacije, odnosno nivoa programskog jezika (Razdvajanje softvera na nižem nivou). Napomena: Ova funckija je moguća kako na namenskim uređajima, tako i na univerzalnim računarima. Softverski moduli koji treba da se odvoje, ostvaruju se kao nezavisni objekti operativnog sistema. (Razdvajanje softvera na višem nivou). Napomena: Ova vrsta razdvajanja softvera je obično moguća samo na univerzalnim računarima. Primeri su nezavisni izvršni programi, dinamički povezane biblioteke itd.

Tabela 8-1: Tehnički opis razdvajanja softvera

Zaštita od nedopustivih izmena mernih vrednosti i parametara je indirektno pomenuta jer programer softverskih delova koji ne podležu zakonskoj kontroli, ne sme da da mogućnost korisniku mernog sistema da ih ošteti. Ali, to u svakom slučaju treba da razmatra programer (sa ili bez razdvajanja), dok su odgovarajući zahtevi navedeni u osnovnim delovima P i U (Poglavlja 4 i 5) ovog vodiča.


51

8.2 Posebni softverski zahtevi za razdvajanje softvera Klasa rizika B Klasa rizika C Klasa rizika D

S1: Realizacija razdvajanja softvera Treba da postoji softverski deo koji sadrži sve softvere i parametre koji podležu zakonskoj kontroli, a koji su

jasno razdvojeni od ostalih softverski delova.

Napomene: 1. U slučaju razdvajanja na niskom nivou, sve programske jedinice (podprocedure, procedure, funkcije,

klase, itd.) i u slučaju razdvajanja na višem nivou svi programi i biblioteke ° koji doprinose izračunavanju merne vrednosti ili utiču na nju, ° koji doprinose pomoćnim funkcijama kao što su prikazivanje podataka, bezbednost podataka,

pamćenje podataka, identifikacija softvera, preuzimanje softvera, prenos ili pamćenje podataka, verifikaciju primljenih ili zapamćenih podataka, itd. pripadaju softveru koji podleže zakonskoj kontroli.1

2. Sve promenjive, privremene datoteke i parametri koji utiču na merne vrednosti ili na funkcije ili podatke koji podležu zakonskoj kontroli pripadaju softveru koji podleže zakonskoj kontroli.

3. Sam zaštitni softverski interfejs (pogledajte S3) je deo softvera koji podleže zakonskoj kontroli. 4. Softver koji ne podleže zakonskoj kontroli sastoji se iz preostalih programskih jedinica, podataka ili

parametara koji nisu gore navedeni. Izmene na ovim delovima su dozvoljene bez obaveštavanja notifikovanog tela pod uslovom da se prate kasniji zahtevi za razdvajanje softvera.

Potrebna dokumentacija: Opis zaštitnog interfejsa je opisan u gore navedenim napomenama.

Potrebna dokumentacija (pored dokumentacije koja je potrebna za klase rizika B i C): U dokumentaciji treba prikazati ispravnu primenu razdvajanja softvera.

Smernice za validaciju: Provere na osnovu dokumentacije: • Proverite da li su svi delovi koji podležu zakonskoj kontroli, a koji

su spomenuti u napomenama 1 do 3, uključeni u softver koji podleže zakonskoj kontroli.


• Proverite da li je razdvajanje softvera ispravno obavljeno.


Kao što je opisano u samom uslovu.





• Proverite izradu softvera i da li je protok podataka koji se odnosi na podatke koji podležu zakonskoj kontroli nedvosmisleno definisan u softveru koji podleže zakonskoj kontroli i da li može da se verifikuje.

• Proverite (npr. na osnovu analize protoka podataka sa alatima ili ručno) da su sve programske jedinice, programi ili biblioteke koje su uključene u obradu mernih vrednosti registrovane u softveru koji podleže zakonskoj kontroli.

• Pretražite neprihvatljiv protok podatka od delova koji ne podležu zakonskoj kontroli do domena koji treba da se zaštite.

1

Napomena:

Razdvajanje na nižem nivou: Objedinjavanje softverskih jedinica na nivou programskog jezika ili programskih delova za objedinjavanje (odnosno podprocedura, procedura, funkcija, klasa) u cilju formiranja programskog dela koji podleže zakonskoj kontroli. Ostatak programa je deo koji ne podleže zakonskoj kontroli. Razdvajanje na višem nivou: Objedinite sve softverske delove u jedan objekat koji je prepoznatljiv operativnom sistemu (program, DLL, itd). Ostatak softvera je deo koji ne podleže zakonskoj kontroli.


52

Klasa rizika B Klasa rizika C Klasa rizika D S2: Mešane oznake Dodatne informacije koje je izradio softver, a koje ne podležu zakonskoj kontroli, mogu samo da se prikažu na

ekranu ili odštampaju ako se neće mešati sa informacijama koje potiču iz dela koji podleže zakonskoj kontroli.

Napomene: S obzirom da programer softvera koji podleže zakonskoj kontroli možda nema informacije o prihvatljivosti oznaka, proizvođač je odgovoran za garantovanje ispunjenja zahteva svih prikazanih informacija. Potrebna dokumentacija:

Opis softvera koji izvršava oznaku. Opis kako se informacije koje podležu zakonskoj kontroli štite od obmanjivih oznaka koje generiše softver koji ne podleže zakonskoj kontroli.

Potrebna dokumentacija (pored u dokumentacije koja je potrebna za klase rizika B i C): U dokumentaciji treba prikazati izvršenje mešanih oznaka.



• Procenite pomoću vizuelne provere da se dodatne informacije generisane softverom koji ne podleže zakonskoj kontroli, koje su prikazane na ekranu ili odštampane, neće mešati sa informacijama koje dolaze iz softvera koji podleže zakonskoj kontroli.


• Proverite da li je realizovana implementacija mešane oznake ispravna.

Primer prihvatljivog rešenja: • Informacije koje treba da se prikažu na softveru koji podleže zakonskoj kontroli, prenose se putem

zaštitnog interfejsa (pogledajte S3) na softver koji podleže zakonskoj kontroli. One iza interfejsa prolaze kroz filter koji otkriva nedozvoljene informacije. Dozvoljene informacije se zatim umeću na oznaku koju kontroliše softver koji podleže zakonskoj kontroli.

• Na ekranu u obliku prozora (univerzalni računar) softver koji podleže zakonskoj kontroli proverava u kratkim vremenskim intervalima da li je prozor sa informacijama koji podleže zakonskoj kontroli stalno vidljiv na vrhu niza prozora. Ako je sakriven, smanjen ili van okvira, softver daje upozorenje ili zaustavlja izlaz i obradu mernih vrednosti. Kada je merenje završeno, prozor za zakonske svrhe može da se zatvoriti.





• Proverite da li softver koji podleže zakonskoj kontroli generiše pokazivanje merne vrednosti.

• Proverite da se ova oznaka ne može menjati ili potisnuti programom koji ne podleže zakonskoj kontroli.


53

Klasa rizika B Klasa rizika C Klasa rizika D S3: Zaštitni softverski intefejs Razmena podataka između softvera koji podleže i koji ne podleže zakonskoj kontroli mora da se obavlja

putem zaštitnog interfejsa koji obuhvata interakcije i protok podataka.

Napomene: 1. Sve interakcije i protoci podataka neće nedopustivo uticati na softver koji podleže zakonskoj kontroli

uključujući dinamičko ponašanje procesa merenja. 2. Neće biti nedvosmislenih zadataka na komandama koji se putem softverskog interfejsa šalju na

pokrenutu funkciju ili izmena podataka na softveru koji podleže zakonskoj kontroli. 3. Kôdovi i podaci koji nisu izričiti i dokumentovani kao komande, ne smeju na bilo koji način uticati na

softver koji podleže zakonskoj kontroli. 4. Interfejs treba u potpunosti da se dokumentuje, a sve ostale nedokumentovane interakcije ili protok

podataka (zaobilaženje interfejsa) programator softvera koji podleže zakonskoj kontroli niti programator softvera koji ne podleže zakonskoj kontroli ne sme da izvršava.

Napomena: Programeri su odgovorni za praćenje ovih ograničenja. Tehničke metode za sprečavanje zaobilaženja softverskog interfejsa nisu moguće. Programer zaštitnog interfejsa treba da bude upoznat sa ovim zahtevom. Potrebna dokumentacija: • Opis softverskog interfejsa, pogotovo koji domeni podataka

izvršavaju interfejs. • Kompletna lista svih komandi zajedno sa izjavom o kompletnosti. • Kratak opis njihovog značenja i uticaja na funkcije i podatke merila.

Potrebna dokumentacija (pored dokumentacije koja je potrebna za klase rizika B i C): U dokumentaciji treba prikazati izvršenje softverskog interfejsa.

Smernice za validaciju: Provere na osnovu dokumentacije: • Proverite da li su funkcije softvera koje podležu zakonskoj kontroli,

koje mogu da se aktiviraju putem zaštitnog softverskog interfejsa, definisane i opisane.

• Proverite da li su parametri koji mogu da se razmenjuju putem interfejsa, definisani i opisani.

• Proverite da li je opis funckija i parametara ubedljiv i kompletan.


dokumentacije:

• Proverite da li je izvršavanje softverskog interfejsa ispravno.

Primer prihvatljivog rešenja: • Domeni podataka softverskog dela koji podleže zakonskoj kontroli enkapsulirani su objavljivanjem samo

lokalnih varijabli u delovima koji podležu zakonskoj kontroli. • Interfejs se izvršava kao podrutina koja pripada softveru koji podleže zakonskoj kontroli, a poziva se iz

softvera koji ne podleže zakonskoj kontroli. Podaci koji treba da se prenesu na softver koji podleže zakonskoj kontroli prenose se kao parametri podrutine.

• Softver koji podleže zakonskoj kontroli filtrira neprihvatljive komande interfejsa.



Smernice za validaciju (pored smernice za klase rizika B i C):

Provere na osnovu izvornog kôda: • Proverite izradu softvera i da li je protok podataka nedvosmisleno definisan u softveru koji podleže

zakonskoj kontroli i da li može da se verifikuje. • Proverite sa alatima ili ručno protok podatka kroz softverski interfejs. Proverite je li celokupan protok

podataka između delova dokumentovan (bez zaobilaženja izričitog softverskog interfejsa). • Pretražite neprihvatljiv protok podatka od delova koji ne podležu zakonskoj kontroli do domena koji treba

da se zaštiti. • Proverite da li su komande, ako ih ima, ispravno dekodirane i da nema postojećih nedokumentovanih

komandi.


54

9 Dodatak D: Preuzimanje softvera koji podleže zakonskoj kontroli

Ovaj dodatak će se koristi za preuzimanje softvera koji podleže zakonskoj kontroli dogod su metrološke karakteristike nepomenjene i dok se izjava o usaglašenosti primenjuje, npr. ispravke grešaka. Ove zaheve treba razmatrati uz osnovne zahteve za tipove P i U opisane u Poglavlju 4 i 5 ovog vodiča.

9.1 Tehnički opis Softver može da se preuzme samo na merila koja karakterišu sledeća svojstva:

Konfiguracija hardvera

Ciljni uređaj podleže zakonskoj kontroli. To može biti namensko merilo (Tip P) ili ono zasnovano na univerzalnom računaru (Tip U). Komunikacioni linkovi za preuzimanje mogu biti direktni, npr. RS 232, USB, putem zatvorene mreže delimično ili u potpunosti pod zakonskom kontrolom, npr. Ethernet, token-ring LAN, ili putem otvorene mreže, npr. Interneta.

Konfiguracija softvera

Celokupan softver ciljnog uređaja može da podleže zakonskoj kontroli ili može da ima razdvajanje softvera. Preuzimanje softera koji podleže zakonskoj kontroli mora da prati uslove navedene ispod. Ako u merilu nema razdvajanja softvera, onda se zahtevi navedeni ispod primenjuju na sva preuzimanja.

Tabela 9-1: Tehnički opsi konfiguracija za preuzimanje softvera


55

9.2 Posebni softverski zahtevi Klasa rizika B Klasa rizika C Klasa rizika D

D1: Mehanizam preuzimanja Preuzimanje i naknadna instalacija softvera biće automatska, nakon čega mora da se osigura da će zaštita softverskog okruženja biti na odobrenom nivou.

Posebne napomene: 1. Preuzimanje će biti automatsko da bi se obezbedilo da postojeći nivo zaštite ne bude ugrožen. 2. Ciljni uređaj ima nepromenjivi softver koji podleže zakonskoj kontroli, koji sadrži sve funkcije provere koje

su potrebne za ispunjenje zahteva od D2 do D4. 3. Instrument treba da bude u mogućnosti da otkrije da je došlo do neuspešnog preuzimanja ili instalacije.

Izdaće se upozorenje. Ako su preuzimanje ili instalacija bili neuspešni ili prekinuti, originalan status merila će ostati nepromenjen. U suprotnom, instrument će prikazati trajnu poruku o grešci,a njegovo metrološko funkcionisanje biće sprečeno sve dok se uzrok greške ne ispravi.

4. Nakon uspešnog dovršavanja instalacije, sva sredstva zaštite biće vraćena u prvobitno stanje osim ako je preuzeti softver ovlašćeno od notifikovanog tela u okviru TEC-a da ih izmeni.

5. Tokom preuzimanja i naknadne instalacije preuzetog softvera, merenje će biti onemogućeno ili će se garantovati ispravno merenje.

6. Zahtevi za rukovanje greškom koji su opisani u Dodatku I, mogu da se primene ako tokom preuzimanja dođe do greške. Broj ponovnih pokušaja instalacije biće ograničen.

7. Ako zahtevi iz D2 do D4 ne mogu da se ispune, biće i dalje moguće preuzeti softverski deo koji ne podleže zakonskoj kontroli. U tom slučaju treba da se ispune sledeći uslovi: • Na osnovu dodatka S postoji jasna odvojenost između softvera koji podleže i koji ne podleže

zakonskoj kontroli. • Celokupan softverski deo je nepromenjiv, odnosno ne može da se preuzme ili izmeni bez lomljenja

plombe. • U TEC-u je navedeno da je preuzimanje softvera koji podleže zakonskoj kontroli prihvatljivo.

8. Biće moguće onemogućiti mehanizam za preuzimanje softvera sredstvima podešavanja koja se moraju zaštititi (prekidač, obezbeđeni parametar) za države članice u kojima preuzimanje softvera za instrumente koji su u upotrebi nije dozvoljeno. U tom slučaju, neće biti moguće da se preuzme softver koji podleže zakonskoj kontroli bez oštećenja zaštite.

Potrebna dokumentacija: Dokumentacija treba ukratko da opiše automatsku prirodu preuzimanja, proveru, instalaciju, na koji način se garantuje nivo zaštite po dovršavanju, šta se dešava ukoliko dođe do greške.

Potrebna dokumentacija (pored dokumentacije koja je potrebna za klase rizika B i C): U dokumentaciji treba prikazati realizaciju mehanizma za preuzimanje.

Smernice za validaciju: Provere na osnovu dokumentacije: • Proverite dokumentaciju o tome kako se upravlja procedurom

preuzimanja. • Proverite da li se preuzimanje i instalacija obavljaju automatski, da li

je merilo zaključano (ako je potrebno) i da zaštita softvera nije ugrožena nakon preuzimanja.

• Proverite da postoji nepromenjiv softver koji podleže zakonskoj kontroli za autentičnost i proveru integriteta.

• Proverite da tokom preuzimanja softvera merenje nije moguće ili da se garantuje ispravno merenje.

• Funkcionalne provere:

• Obavite najmanje jedno preuzimanje softvera da biste proverili ispravnost preuzimanja softvera.


dokumentacije: • Proverite da li je realizacija preuzetog mehanizma ispravna.


56

Primer prihvatljivog rešenja: Rezident uslužnog programa u nepromenjivom delu softvera koji:

a. Rukuje sa pošiljaocem i proverava saglasnost b. Automatski blokira merenje osim ako se može garantovati ispravno merenje c. Automatski preuzima softver koji podleže zakonskoj kontroli u bezbednoj oblasti d. Automatski sprovodi provere koje se zahtevaju u dodacima D2 do D4 e. Automatski instalira softver na ispravnoj lokaciji f. Vodi brigu o održavanju, npr. briše suvišne datoteke, itd. g. Osigurava da se bilo koja uklonjena zaštita koja omogućava preuzimanje i instalaciju automatski

zamenjuje na odobreni nivo dovršavanja. h. Pokreće odgovarajuće procedure rukovanja greškom ako do greške dođe


Potrebna dokumentacija (pored dokumentacije koja je potrebna za klase rizika B i C): Izvorni kôd nepromenjivog softverskog dela odgovornog za upravljanje procesom preuzimanja.

Smernice za validaciju (pored smernice za klasu rizika B i C):


• Proverite da li su mere preduzete za upravljanje procesom preuzimanja odgovarajuće.


57


D2: Autentifikacija preuzetog softvera Koristiće se metode kao garancija da je preuzeti softver autentičan, i da ukažu da je notifikovano telo odobrilo

preuzeti softver.

Posebne napomene: 1. Pre nego što se preuzeti softver bude koristio po prvi put, merilo će automatski proveriti da je:

a. Softver autentičan (da nije lažna simulacija). b. Softver odobren za taj tip merila.

2. Sredstva pomoću kojih softver identifikuje svoj odobreni status od strane notifikovanog tela, će se zaštititi kako bi se sprečilo falsifiovanje statusa notifikovanog tela.

3. Ako preuzeti softver ne prođe bilo koji od gore navedenih testova, pogledajte D1. 4. Ako proizvođač hoće da promeni ili ažurira softver koji podleže zakonskoj kontroli, on će odgovorno

notifikovano telo obavestiti o željenim promenama. Notifkovano telo će odlučiti li je postojećem Sertifikatu o ispitivanju tipa (TEC) neophodan dodatak ili ne. Kod preuzimanja softvera je potrebno da postoji identifikacija softvera koja je nedvosmisleno dodeljena odobrenoj verziji softvera.

Potrebna dokumentacija: Dokumentacija treba da opiše:

• Na koji način se garantuje autentičnost identifikacije softversa.

• Na koji način se garantuje autentičnost odobrenja notifikovanog tela.

• Kako se garantuje da je preuzeti softver odobren za tip merila na koji je preuzet.

Potrebna dokumentacija (pored dokumentacije koja je potrebna za klase rizika B i C): U dokumentaciji treba prikazati obavljena potvrda indentiteta.


Provere na osnovu dokumentacije i funkcionalne provere:

• Proverite u dokumentaciji kako se sprečava preuzimanje lažnog softvera.

• Proverite funkcionalnim testovima da je preuzimanje lažnog softvera sprečeno.

Funkcionalnim testovima obezbedite proveru autentifkacije u skladu sa dokumentacijom.

Smernice za validaciju (pored smernica za klase rizika B i C): Provere na osnovu dokumentacije: • Proverite da li su preduzete mere

odgovarajuće za visok nivo zaštite u odnosu na zahtevani najviši nivo.

Primer prihvatljivog rešenja: 1. Autentičnost Iz razloga celokupnosti (pogledajte D3) generiše se elektronski potpis za softverski deo koji

treba da se preuzme. Autentičnost se garantuje ako ključ koji je zapamćen na nepromenjivom softverskom delu instrumenta, potvrdi da potpis potiče od proizvođača.

2. Notifikovano telo. Ključ se pamti na nepromenjivom softverskom delu pre inicijalne verifikacije. 3. Tačan tip mernog instrumenta

Provera tipa instrumenta zahteva automatsko podudaranje indentifikacije tipa instrumenta koji je zapamćen na nepromenjivom softverskom delu instrumenta, sa listom kompatibilnosti priloženom na softveru.

4. Odobrenje notifikovanog tela Ako je autentičnost zagarantovana korišćenjem ključa proizvođača, onda se može pretpostaviti odobrenje notifikovanog tela.

4. Odobrenje notifikovanog tela Da biste proverili da li je softver zaista odobren, jedna mogućnost je da celokupan preuzeti odobreni softver sadrži potpis odgovornog autoriteta. Javni ključ odgovornog autoriteta je zapamćen na merilu i koristi se za automatsku proveru potpisa priloženog uz softver. Može se vizuelno pregledati na instrumentu kako bi se uporedio sa ključem koji je izdao odgovorni autoritet.


58


Potrebna dokumentacija (pored dokumentacije koja je potrebna za klase rizika B i C): Izvorni kôd nepromenjivog softverskog dela odgovornog za proveru autentičnosti preuzetog softvera.

Smernice za validaciju (pored smernica za klasu rizika B i C):

Provere na osnovu izvornog kôda: • Proverite da li su preduzete mere za proveru autentičnosti odgovarajuće.

Klasa rizika B Klasa rizika C Klasa rizika D D3: Integritet preuzetog softvera Koristiće se sredstva kojim se garantuje da preuzeti softver nije nedopustivo izmenjen tokom preuzimanja.

Napomene: 1. Pre nego što se preuzeti softver bude koristio po prvi put, merilo će automatski proveriti da li je preuzeti

softver nedopustivo izmenjen. 2. Ako preuzeti softver ne prođe ovaj test, pogledajte D1.


Dokumentacija treba da opiše na koji način se garantuje integritet softvera.

Potrebna dokumentacija (pored dokumentacije koja je potrebna za klase rizika B i C): U dokumentaciji treba prikazati metode za obezbeđivanje integriteta.

Smernice za validaciju: • Funkcionalnim testovima obezbedite proveru

identiteta softvera nakon preuzimanja u skladu sa dokumentacijom.



Primer prihvatljivog rešenja: • Integritet može da se demonstrira izvođenjem

zbira provere softvera koji podleže zakonskoj kontroli i upređivanjem sa zbirom provere priloženim uz softver (pogledajte takođe U2 za primer prihvatljivog rešenja).

• Prihvatljivi algoritam: CRC, tajni incijalni vektor, dužina 32 bita. Inicijalni vektor je zapamćen u nepromenjivom softerskom delu.

Primer prihvatljivog rešenja: • Generišite hash vrednost softvera koji treba da

se preuzme (algoritmi npr. SHA-1, RipeMD-160) i dešifrujte ga (RSA, eliptične krive) sa odgovarajućom dužinom ključa.

• Ključ za dešifrovanje je zapamćen na nepromenjivom softverskom delu.


Potrebna dokumentacija (pored dokumentacije koja je potrebna za klase rizika B i C): Izvorni kôd nepromenjivog softverskog dela odgovornog za proveru integriteta preuzetog softvera.

Smernice za validaciju (pored smernica za klasu rizika B i C):

Provere na osnovu izvornog kôda: • Proverite da li su preduzete mere za proveru integriteta odgovarajuće.


59


D4: Praćenje preuzetog softvera koji podleže zakonskoj kontroli Odgovarajućim tehničkim metodama se jemči da će se preuzimanja softvera koji podleže zakonskoj kontroli

adekvatno pratiti u okviru instrumenta za naknadne kontrole.

Napomene: 1. Ovaj zahtev omogućava organima kontrole, koji su odgovorni za metrološko nadgledanje instrumenata

koji podležu zakonskoj kontroli, da prate unazad preuzimanja softvera koji podleže zakonskoj kontroli na određen vremenski period (koji zavisi od nacionalnog zakonodavstva).

2. Metode i zapisi praćenja deo su softvera koji podleže zakonskoj kontroli i kao takvi treba da budu zaštićeni.

Potrebna dokumentacija: Dokumentacija će: • Ukratko opisati na koji način su metode praćenja

implementirane i zaštićene. • Navedite kako može da se uđe u trag preuzetom softveru.

Potrebna dokumentacija (pored dokumentacije koja je potrebna za klase rizika B i C): U dokumentaciji treba prikazati metode omogućavanja praćenja.



• Proverite da li su sredstva praćenja implementirana i zaštičena.


• Nasumičnim proverama proverite funkcionalnost metoda.

Smernice za validaciju (pored smernica za klase rizika B i C): Provere na osnovu dokumentacije: • Proverite da li preduzete mere

odgovaraju visokom nivou zaštite u poređenju sa zahtevanim najvišim nivoom.

Primer prihvatljivog rešenja: • Hronološki zapis revizije. Merilo može biti opremljeno sistemom za evidenciju događaja koji automatski

beleži bar datum i vreme preuzimanja, indentifikaciju preuzetog softvera koji podleže zakonskoj kontroli, identifikaciju preuzete strane i unos uspešnog preuzimanja. Unos se generiše pri svakom pokušaju preuzimanja bez obzira na uspešnost.

• Nakon što se dostigne ograničenje u sistemu za evidenciju događaja, tehničkim metodama će se obezbediti nemogućnost daljih preuzimanja. Hronološki zapisi revizije mogu da se izbrišu samo lomljenjem fizičke ili elektronske plombe koje organi inspekcije mogu ponovo da se zapečate.


Potrebna dokumentacija (pored dokumentacije koja je potrebna za klase rizika B i C): Izvorni kôd nepromenjivog softverskog dela koji je odgovoran za praćenje procesa preuzimanja i upravljanje hronološkim zapisima revizije. Smernice za validaciju (pored smernica za klasu rizika B i C):


• Proverite da li su preduzete mere za praćenje procesa preuzimanja odgovarajuće.

• Proverite da li su preduzete mere za zaštitu hronološkog zapisa revizija odgovarajuće.

Saglasnost o preuzimanju

Pretpostavlja se da će proizvođač merila adekvatno informisati svog korisnika o softverskim ispravkama, posebno o delu koji podleže zakonskoj kontroli, a da korisnik neće odbiti da ga ažurira. Dalje se pretpostavlja da će se proizvođač i korisnik, odnosno vlasnik instrumenta dogovoriti o odgovarajućem postupku preuzimanja u zavisnosti od upotrebe i lokacije instrumenta.


60

10 Dodatak I: Softverski zahtevi specifični za instrument

Ovaj dodatka služi kao dopuna opštim softverskim zahtevima iz prethodnih poglavlja i ne može se posmatrati odvojeno od delova P ili U i ostalih dodataka (pogledajte Poglavlje 3). On odražava postojanje MI-x aneksa specifičnih za instrumente u MID direktivi i sadrži specifična stanovišta i zahteve za merila ili sisteme (ili podsklopove). Ovi zahtevi međutim, ne prevazilaze zahteve iz MID direktive. Ako se OIML preporuke ili ISO/IEC standardi pominju, to se radi samo ako mogu da se smatraju normativnim dokumentima u smislu MID direktive i ako to omogućava usklađeno tumačenje zahteva iz MID direktive.

Osim softverskih aspekata specifičnih za instrument i zahteva, Dodatak I sadrži dodeljivanje klase rizika specifične za instrument (ili kategoriju) koje obezbeđuje skladan nivo ispitivanja softvera, zaštitu i usklađenost softvera.

Dodatak I je za sada samo početni nacrt koji odgovarajuća WELMEC Radna grupa koja poseduje određena znanja treba da dovrši. Stoga Dodatak I ima „otvorenu strukturu“, odnosno nudi osnovu koja je – pored inicijalnog dodeljivanja klase rizika – samo delimično popunjena (npr. za komunalna merila i vage sa automatskim funkcionisanjem). Može takođe da se koristi i za ostale MID direktive (ili instrumente koje ne potpadaju pod MID direktivu), u skladu sa stečenim iskustvima i donetim odlukama odgovarajuće WELMEC radne grupe. Numerisanje x podpoglavlja 10.x prati numerisanje određenog Aneksa MI-x MID direktive. Instrumenti koje ne potpadaju pod MID direktivu mogu da se dodaju počev od poglavlja 10.11.

Postoje različita softverska stanovišta specifična za merila koja mogu da se razmatraju za određeni tip x merila. Sa ovim stanovištima treba postupati sistematski i to: svako podpoglavlje 10.x treba da bude podeljeno na odeljke 10.x.y gde y podrazumeva sledeća stanovišta.

10.x.1 Posebne uredbe, standardi i ostali normativni dokumenti

Treba napomenuti da ove uredbe, standardi i ostali normativni dokumenti (npr. OIML preporuke) specifični za instrument (ili kategoriju), ili WELMEC smernice mogu da pomognu kod primene softverskih zahteva specifičnih za instrument (ili kategoriju) kao tumačenje zahteva iz Aneksa I MID direktive i specifičnih aneksa MI-x.

Obično se posebni softverski zahtevi primenjuju uz one opšte iz prethodnog poglavlja. U suprotnom treba jasno navesti da li posebni softverski zahtevi zamenjuju jedan (ili više) opštih softverskih zahteva, ili da li se jedan (ili više) softverskih zahteva (are) ne primenjuju, i razlog za to. 10.x.2 Tehnički opis

Ovde mogu da se navedu: - primeri najčešćih specifičnih tehničkih konfiguracija, - primena delova P, U i dodaci tim primerima, i - korisna (specifična za instrument) kontrolna lista za proizvođača i ispitivača.

Opis treba da ima - principe merenja (kumulativno merenje ili pojedinačno nezavisno merenje; merenje

koje se ponavlja i merenje koje se ne ponavlja; statičko i dinamičko merenje) i - otkrivanje greške i reakcija; moguća su dva slučaja:

a) Prisustvo greške je očigledno ili može lako da se proveri ili postoje hardverska sredstva koja otkrivaju grešku,

b) Prisustvo greške nije očigledno ili ne može lako da se proveri ili nema hardverskih sredstava koja otkrivaju grešku.

U drugom slučaju (b) otkrivanje greške i reakcija zahtevaju odgovarajuća softverska sredstva i samim tim i odgovarajuće softverske zahteve.

- Konfiguracija hardvera; treba rešavati najmanje sledeća pitanja: a) Postoji li modularan, opštenamenski računarski sistem ili namenski instrument koji

ima ugrađen sistem koji podleže zakonskoj kontroli?


61

b) Da li je računarski sistem samostalan, ili je deo zatvorene mreže, npr. Ethernet, token-ring LAN, ili deo otvorene mreže, npr. Internet?

c) Da li je senzor odvojen (odvojeno kućište i odvojeno napajanje) od sistema tipa U ili je delimično ili u potpunosti integrisan u njega?

d) Da li korisnički interfejs uvek podleže zakonskoj kontroli (za tip P i tip U instrumente) ili može da se prebaci na operativni režim rada koji ne podleže zakonskoj kontroli?

e) Da li je predviđeno dugoročno pamćenje podataka? Ako jeste, da li je u tom slučaju skladište lokalno (npr. čvrsti disk) ili daljinsko (npr. fajl server)?

f) Da li je medijum za pamćenje nepromenjiv (npr. interni ROM) ili prenosiv (npr. flopi disk, CD-RW, smart-media kartica, memorijski štapić)?

- Konfiguracija softvera i okruženje, treba rešavati najmanje sledeća pitanja: a) Koji se operativni sistem koristi ili može da se koristi?

b) Da li se ostale softverske aplikacije nalaze na sistemu pored softvera koji podleže zakonskoj kontroli?

c) Postoji li softver koji ne podleže zakonskoj kontroli koji može slobodno da se modifikuje nakon odobrenja?

10.x.3 Posebni softverski zahtevi

Ovde kao i u prethodnom poglavlju treba na sličan način navesti posebne softverske zahteve i prokomentarisati ih.

10.x.4 primeri funkcija i podataka koji podležu zakonskoj kontroli

Ovde mogu da se navedu primeri

- parametara specifičnih za uređaj (npr. pojedinačni parametri konfiguracije i kalibracije specifičnih merila),

- parametara specifičnih za tip (npr. specifični parametri koji su nepromenjivi i ispitivanje tipa), ili

- zakonski primenjive, specifične funkcije.

10.x.5 Ostala stanovišta

Ovde mogu da se spomenu ostala stanovišta, npr. specifična dokumentacija koja je potrebna za ispitivanje tipa (softver), specifični opisi i uputstva, koji treba da se nađu u sertifikatu o ispitivanju tipa ili ostalim stanovištima (npr. zahtevima koji se odnose na mogućnosti za obavljanje ispitivanja).

10.x.6 Dodela klase rizika

Ovde treba da budu definisane odgovarajuće klase rizika za instrumente tipa x. To može da se obavi

- uopšteno (za sve kategorije u okviru određenog tipa), ili

- u zavisnosti od polja primene, ili kategorije, ili drugih aspekata ako ih ima.


62

10.1 Vodomeri

10.1.1 Posebne uredbe, standardi i ostali normativni dokumenti

Države članice mogu – u skladu sa Članom 2 MID dirketive – propisati vodomer za stambenu, komercijalnu i laku industrijsku upotrebu koji je u skladu sa uredbama MID direktive. Posebni zahtevi iz ovog poglavlja zasnovani su isključivo na Aneksu MI-001.

OIML preporuke i standardi nisu razmatrani.

10.1.2 Tehnički opis

10.1.2.1 Konfiguracija hardvera

Vodomeri se obično ostvaruju kao namenski uređaji (tip P u ovom dokumentu).

10.1.2.2 Konfiguracija softvera Ona je specifična za svakog proizvođača, ali treba očekivati da se prate preporuke koje su navedene u glavnom delu ovog vodiča.

10.1.2.3 Princip merenja Vodomeri stalno meri zapreminu vode koja prolazi. Utrošena zapremina vode se prikazuje na instrumentu. Koriste se razni principi.

Izmerena zapremina ne može da se ponovi.

10.1.2.4 Otkrivanje greške i reakcija Zahtev MI-001, 7.1.2 bavi se elektromagnetnim smetnjama. Postoji potreba da se ovaj zahtev protumači za softverski kontrolisane instrumente zato što je otkrivanje prekida i opravak moguć samo međusobnom saradnjom određenih hardverskih delova i određenog softvera. Sa softverske tačke gledišta nije bitno koji je bio razlog za poremećaj (elektromagnetni, električni, mašinski i sl.): sve procedure oporavka su iste.


63

10.1.3 Posebni softverski zahtevi (vodomeri)

Klasa rizika B Klasa rizika C Klasa rizika D I1-1: Oporavak od greške

Softver će se oporaviti od poremećaja u normalno stanje rada.

Napomene:

Datumski označene situacije treba da se podignu kako bi se omogućilo evidentiranje perioda neispravnog rada. Potrebna dokumentacija:

Kratak opis mehanizma za oporavak od greške i kada je pozvan.

Smernice za validaciju: Provere zasnovane na dokumentaciji: • Proverite da li je izvođenje oporavka od greške adekvatno. Funkcionalne provere: • Nema dodatnih pored onih koje su završene tokom ispitivanja tipa za potvrdu ispravnog funkcionisanja u

prisustvu definisanih količina na koje se utiče. Primer prihvatljivog rešenja:

Kontrola hardvera se resetuje preko ciklično obrađenog mikroprocesora podprograma kako bi se sprečilo pokretanje kontrole. Ako neka funkcija nije obrađena ili – u najgorem slučaju – mikroprocesor visi u arbitrarnoj beskonačnoj petlji, ne dolazi do resetovanja kontrole i ona se pokreće nakon određenog vremenskog perioda.

Klasa rizika B Klasa rizika C Klasa rizika D I1-2: Objekti za rezervno kopiranje Treba da postoji objekat koji u slučaju poremećaja, obezbeđuje periodično pravljenje rezervne kopije

podataka koji podležu zakonskoj kontroli, kao što su merne vrednosti i trenutni status procesa. Ovi podaci

treba da se pamte u skladištu koje se ne gubi nakon isključenja napajanja.

Napomene:

Podeoci pamćenja moraju biti dovoljno mali kako bi nesklad između sadašnjih i sačuvanih kumulativnih vrednosti bio mali.


Kratak opis podataka koji su rezervno kopirani i kada se to dogodilo. Izračunavanje maksimalne greške koja se može javiti za kumulativne vrednosti.



• Proverite da li se svi podaci koji podležu zakonskoj kontroli čuvaju u skladištu koje se ne gubi nakon isključenja napajanja i da li mogu da se vrate u prethodno stanje.

Funkcionalne provere: • Nema dodatnih pored onih koji su završeni tokom ispitivanja tipa za potvrdu ispravnog funkcionisanja u


Podaci koji podležu zakonskoj kontroli se rezervno kopiraju kao što se zahteva (npr. svakih 60 minuta)


64


I1-3: MID-Aneks I, 8.5 (sprečavanje resetovanja kumulativnih mernih vrednosti) Kod komunalnih merila prikaz ukupne isporučene količine ili prikazi iz kojih može da se izvede ukupna

isporučena količina, celokupno ili delimično pozivanje na kojem je osnova za plaćanje, neće moći da se

resetuju tokom korišćenja.

Napomene:

Kumulativni registri merila mogu da se resetuju pre nego što se stave u upotrebu.


Dokumentacija o metodama zaštite od resetovanja registara zapremine.



• Proverite da se kumulativne merne vrednosti koje podležu zakonskoj kontroli ne mogu resetovati a da ne ostave trag.


• Nema dodatnih pored onih koje su završene tokom ispitivanja tipa za potvrdu ispravnog funkcionisanja u prisustvu definisanih količina na koje se utiče.

Primer prihvatljivog rešenja: Registri zapremine su zaštićene od izmena i resetovanja na isti način kao i parametri (pogledajte P7).


I1-4: Dinamičko ponašanje Softver koji ne podleže zakonskoj kontroli neće negativno uticati na dinamičko ponašanje merni proces.

Napomene:

• Ovaj zahtev se primenjuje uz S-1, S-2 i S-3, ako je razdvajanje softvera ostvareno u skladu sa dodatkom S.

• Dodatni zahtev za aplikacije merila u realnom vremenu obezbeđuje da softver koji ne podleže zakonskoj kontroli neće nedopustivo uticati na dinamičko ponašanje softvera koji podleže zakonskoj kontroli, odnosno resursi softvera koji podležu zakonskoj kontroli neće biti nedopustivo umanjeni nezakonskim delom.


• Opis hijerarhija prekida.

• Dijagram vremenskog rasporeda softverskih zadataka. Ograničenja proporcionalnog vremena izvršavanja zadataka koji ne podležu zakonskoj kontroli.



• Dokumentacija o ograničenjima proporcionalnog vremena izvršavanja zadataka koji ne podležu zakonskoj kontroli je dostupna za programera softverskih delova koji ne podležu zakonskoj kontroli.


• Nema dodatnih pored onih završenih tokom ispitivanja tipa za potvrdu ispravnog funkcionisanja u prisustvu definisanih količina na koje se utiče.


Hijerarhija prekida je dizajniran tako da izbegava negativne uticaje.


65

Klasa rizika B Klasa rizika C Klasa rizika D I1-5: Utisnuta identifikacija softvera

Identifikacija softvera se obično prikazuje na ekranu. Izuzetak za vodomere biće utisnuta identifikacija

softvera na pločici sa nazivom instrumenta koja je prihvatljivo rešenje ako su ispunjenih sledeći zahtevi A,

B i C:

A. Korisnički interfejs nema nikakvu sposobnost kontrole da aktivira oznaku identifikacije softvera na

ekranu ili ekran tehnički ne dozvoljava prikazivanje identifikacije softvera (mehanički brojač).

B. Instrument nema interfejs za komunikaciju identifikacije softvera.

C. Nakon proizvodnje merila, nije moguća promena softvera ili je moguća samo u slučaju promene

hardvera ili hardverskog dela.

Napomene:

• Proizvođač hardvera ili dotične hardverske kompoomente je odgovoran za ispravno označavanje softverske identifikacije na dotičnom hardveru.

• Primenjuju se sve ostale posebne napomene P2/U2. Potrebna dokumentacija:

• U skladu sa P2/U2.



• U skladu sa P2/U2. Funkcionalne provere:

• U skladu sa P2/U2. Primer prihvatljivog rešenja:

Otisak identifikacije softvera na pločici sa nazivom instrumenta.

10.1.4 Primeri parametara koji podležu zakonskoj kontroli

Vodomeri imaju parametre kao što su konstante za proračune, konfiguraciju itd., ali i za uspostavljanje funkcionalnosti uređaja. Što se tiče identifikacije i zaštite parametara i skupova parametara, pogledajte zahteve P2 i P7, vodič P.

U nastavku su navedeni neki tipični parametri za vodomere. (Ova tabela će se ažurirati kada WELMEC radna grupa 11 donese odluku o konačnom sadržaju.)

Parametar Zaštićen Podesiv Komentar Faktor kalibracije x

Faktor linearizacije x

10.1.5 Ostala stanovišta Kod primena u domaćinstvu se očekuje da preuzimanje softvera (Dodatak D, Poglavlje 9) neće biti od velikog značaja.

Kumuliranje energije ili registar zapremine kod merila u domaćinstvu ne predstavlja dugoročno skladište u smislu Dodatka L (Poglavlje 6). Za instrument koji meri samo kumulativnu energiju/zapreminu, nije nepohodna primena dodatka L.


66

10.1.6 Dodela klase rizika U skladu sa odlukama nadležne WELMEC Radne grupe 11 (2. sastanak, 3/4 mart 2005.), za sada se smatra da je sledeća klasa rizika odgovarajuća i da treba da se primeni, ako se ispitivanje softvera na osnovu ovog uputstva obavlja za (softverski kontrolisane) vodomere:

- Klasa rizika C za tip P instrumente Konačna odluka, međutim, još nije donesena i RG 11 će razmotiriti ovu stavku koja se odnosi na diskusiju o odovarajućim klasama rizika za tip U instrumente.


67

10.2 Gasomeri i uređaji za konverziju zapremine

10.2.1 Posebne uredbe, standardi i ostali normativni dokumenti

Države članice mogu – u skadu saČlanom 2 MID direktive – propisati gasomere i uređaje za konverziju zapremine za stambenu, komercijalnu i laku industrijsku upotrebu koji su u skladu sa uredbama MID direktive. Posebni zahtevi iz ovog poglavlja zasnovani su isključivo na Aneksu MI-002.

OIML preporuke i standardi nisu razmatrani.


10.2.2.1 Konfiguracija hardvera Gasomeri i uređaji za konverziju zapremine se obično ostvaruju kao namenski uređaji (tip P u ovom dokumentu). Mogu da imaju jedan ili više ulaza za eksterne senzorske jedinice i merilo i uređaji za konverziju mogu biti različite hardverske jedinice.

10.2.2.2 Konfiguracija softvera Ona je specifična za svakog proizvođača, ali se obično očekuje da sledite preporuke koje su navedene u glavnom delu ovog vodiča.

10.2.2.3 Princip merenja Gasomeri stalno memorišu količinu gasa koja prolazi kroz njih. Utrošena zapremina se prikazuje na instrumentu. Koriste se razni principi. Uređaj za konverziju se koristi za izračunavanje zapremine u standardnim uslovima. Konverter može biti integralni deo merila.

Merenje zapremine ne može da se ponovi.

10.2.2.4 Oktrivanje greške i reakcija

Zahtev MI-002, 4.3.1 se bavi elektromagnetnim smetnjama. Postoji potreba da se ovaj zahtev protumači za softverski kontrolisane instrumente zato što je otkrivanje prekida i opravak moguć samo međusobnom saradnjom određenih hardverskih delova i određenog softvera. Sa softverske tačke gledišta nije bitno koji je bio razlog za poremećaj (elektromagnetni, električni, mašinski i sl.): sve procedure oporavka su iste.


68

10.2.3 Posebni softverski uslovi (gasomeri i uređaji za konverziju zapremine)


Softver treba da se oporavi od prekida u normalno stanje rada.

Napomene:


Kratak opis mehanizma za oporavak od greške i kada je pozvan. Smernice za validaciju: Provere zasnovane na dokumentaciji: • Proverite da li je realizacija oporavka od greške adekvatna. Funkcionalne provere: • Nema dodatnih pored onih koje su završene tokom ispitivanja tipa za potvrdu ispravnog funkcionisanja

u prisustvu definisanih količina na koje se utiče.




I2-2: Objekti za rezervno kopiranje Treba da postoji objekat koji u slučaju poremećaja, obezbeđuje periodično pravljenje rezervne kopije


treba da se pamte u stabilnom skladištu.

Napomene:



Kratak opis podataka koji su rezervno kopirani i kada se to dogodilo. Izračunavanje maksimalne greške koja može da se javi za kumulativne vrednosti.



• Proverite da li se svi podaci koji podležu zakonskoj kontroli čuvaju u skladištu koje se ne gubi nakon isključenja napajanja i da li mogu da se vrate u prethodno stanje.

Funkcionalne provere: • Nema dodatnih pored onih koje su završene tokom ispitivanja tipa za potvrdu ispravnog funkcionisanja

u prisustvu definisanih količina na koje se utiče. Primer prihvatljivog rešenja:

Podaci koji podležu zakonskoj kontroli se rezervno kopiraju kao što se zahteva (npr. svakih 60 minuta)


69


I2-3: MI-002, 5.2 (podobnost oznake) Prikaz ukupne nekorigovane zapremine mora da ima dovoljan broj cifara da obezbedi da se oznaka ne vrati

na inicijalnu vrednost kada brojilo radi na 8000 sati pri Qmax.

Napomene:


Dokumentacija unutrašnje zastupljenosti registra zapremine.



• Proverite da li je kapacitet skladišta dovoljan. Primer prihvatljivog rešenja: Tipične vrednosti za domaći gasomer su: Qmax = 6 m3/h. Zahtevani opseg je 48000 m3. (postojeći elektronski gasomeri prikazuju do 99999 m3


I2-4: MID-Aneks I, 8.5 (sprečavanje resetovanja kumulativnih mernih vrednosti) Kod komunalnih merila prikaz ukupne isporučene količine ili prikazi iz kojih može da se izvede ukupna



Napomene:









Primer prihvatljivog rešenja: Registri zapremine su zaštićene od izmena i resetovanja na isti način kao i parametri (pogledajte P7).


70


I2-5: MI-002, 5.2 (trajanje izvora napajanja) Trajanje namenskog izvora napajanja treba da bude najmanje pet godina. Nakon 90% njegovog trajanja,

prikazaće se odgovarajuće upozorenje.

Napomene: Trajanje se ovde koristi u smislu dostupnog energetskog kapaciteta. Ako izvor napajanja može da se izmeni na terenu, parametri i podaci koji podležu zakonskoj kontroli se neće oštetiti tokom prelaska.

Potrebna dokumentacija: Dokumentacija o kapacitetu napajanja, maksimalnom trajanju (nezavisno od potrošnje energije), merama za utvrđivanje potrošene ili dostupne energije, opisu sredstava za upozorenje o niskoj raspoloživoj energiji.


• Proverite da li su preduzete mere odgovarajuće za praćenje raspoložive energije.

Primer prihvatljivog rešenja: Radni sati ili iznenadni događaji uređaja se broje, skladište u memoriji koja ne gubi sadržaj nakon isključenja napajanja i porede sa nominalnom vrednošću trajanja baterije. Ako je isteklo 90% trajanja, prikazuje se odgovarajuće upozorenje. Softver otkriva razmenu izvora energije i resetuje brojač. Drugo rešenje bi bilo kontinuirano praćenje stanja napajanja.


I2-6: MI-002, 9.1 (elektronski uređaj za konverziju) Elektronski uređaj za konverziju treba da je stanju da otkrije kada radi van operativnog(ih) opsega koji(e) je

proizvođač naveo, za parametre koji su odgovorni za tačnost merenja. U tom slučaju, uređaj za konverziju

mora da zaustavi integraciju konvertovane količine, i može odvojeno da sabere konvertovanu količinu za

vreme dok je radio van operativnog(ih) opsega.

Napomene:

Na ekranu će se prikazati naznaka o stanju neizvršavanja.


Dokumentacija o različitim registrima za konvertovanu količinu i količinu greške.


• Proverite da li su preduzete mere odgovarajuće za upravljanje neobičnim uslovima rada.

Primer prihvatljivog rešenja: Softver prati odgovarajuće ulazne vrednosti i poredi ih sa predefinisanim ograničenjima. Ako su sve vrednosti u okviru ograničenja, konvertovana vrednost je integrisana u normalan registar (dodeljena promenjiva). Inače sabira količinu u drugoj promenjivoj. Drugo rešenje bi bilo da postoji jedan kumulativni registar, ali da se beleži početni i krajnji datum, vreme i registruju vrednosti perioda van opsega u sistemu za evidenciju događaja (pogledajte P7). Obe količine mogu da se naznače. Korisnik može jasno da utvrdi i razlikuje redovne oznake i oznake greške pomoću indikacije statusa.


71


I2-7: MI-002, 5.5 (element provere) Gasomer treba da ima element provere koji će omogućiti sprovođenje testova u razumnom vremenu.

Napomene: Element provere za ubrzanje vremenski zahtevnih procedura testiranja se obično koristi za testiranje pre instalacije i normalnog rada. Tokom režima provere koriste se isti registri i softverski delovi kao za vreme standardnog režima rada.


Dokumentacija o elementu provere i uputstva za aktivaciju režima provere.


• Proverite da li sve vremenski zahtevne procedure za testiranje gasomera mogu da se dovrše sredstvima elementa provere.

Primer prihvatljivog rešenja: Vremenska osnova internog sata može da se ubrza. Procesi koji traju npr. nedelju dana ili čak godinu dana i prepunjenost registara mogu da se testiraju u režimu provere u vemenskom rasponu od samo nekoliko minuta ili sati.

Klasa rizika B Klasa rizika C Klasa rizika D I2-8: Dinamičko ponašanje Softver koji ne podleže zakonskoj kontroli neće negativno uticati na dinamičko ponašanje procesa merenja.

Napomene:




• Opis hijerarhije prekida.

• Dijagram tajminga softverskih zadataka. Ograničava proporcionalno vreme izvršavanja zadataka koji ne podležu zakonskoj kontroli.



• Dokumentacija o ograničenjima proporcionalnog vremema izvršavanja zadataka koji ne podležu zakonskoj kontroli za programera softverskih delova koji ne podležu zakonskoj kontroli.


• Nema dodatnih pored onih koji su završeni tokom ispitivanja tipa za potvrdu ispravnog funkcionisanja u prisustvu definisanih količina na koje se utiče.


Hijerarhija prekida je dizajnirana tako da izbegava negativne uticaje.


72


Identifikacija softvera se obično prikazuje na ekranu. Izuzetak za gasomere i uređaje za konverziju

zapremine biće utisnuta identifikacija softvera na pločici sa nazivom instrumenta koja je prihvatljivo rešenje

ako su ispunjenih sledeći zahtevi A, B i C:



B. Instrument nema interfejs za komunikaciju identifikacije softvera.

C. Nakon proizvodnje merila, nije moguća promena softvera ili je moguća samo u slučaju promene hardvera ili hardverskog dela.

Napomene:










Gasomer i uređaji za konverziju zapremine često imaju puno parametara. Oni se koriste kao konstante za izračunavanje, kao parametri konfiguracije itd., ali takođe i za podešavanje funkcionalnosti uređaja. U pogledu identifikacije i zaštite parametara i skupova parametara pogledajte zaheve P2 i P7, vodič P.

U tekstu ispod su navedeni neki tipični parametri za gasomere i uređaje za konverziju zapremine. (Ova tabela će se ažurirati kada WELMEC radna grupa 11 donese odluku o konačnom sadržaju).




Kumuliranje energije ili registar zapremine kod merila u domaćinstvu ne predstavlja dugoročno skladište u smislu Dodatka L (Poglavlje 6). Za instrument koji meri samo kumulativnu energiju/zapreminu, nije nepohodna primena dodatka L. 10.2.6 Dodela klase rizika U skladu sa odlukama nadležne WELMEC Radne grupe 11 (2. sastanak, 3/4 mart 2005.), za sada se smatra da je sledeća klasa rizika odgovarajuća i da treba da se primeni, ako se ispitivanje


73

softvera na osnovu ovog uputstva obavlja za (softverski kontrolisane) uređaje za konverziju zapremine:

- Klasa rizika C za instrumente tipa P Konačna odluka, međutim, još nije donesena i RG 11 će razmotiriti ovu stavku koja se odnosi na diskusiju o odovarajućim klasama rizika za tip U instrumente.

RG11 razmatra da se funkcionalnost za plaćanje unapred i intervala merenja doda onim osnovnim mernim funkcijama utvrđenim u Aneksu MI-002 MID direktive, stoga nijedna veća kategorija rizika nije dodeljena ovim varijantama osim osnovnim tipovima brojila koji su već obuhvaćeni ovim vodičem za softver. Međutim, osnovna funkcija merenja treba da se proceni, uz sve ostale P tipove, zajedno sa ostalim procenama koje se smatraju neophodnim kako bi se pokazalo da pripadajući softver koji obezbeđuje te funkcije ne utiče neprihvatljivo na osnovno merenje.


74

10.3 Brojila aktivne električne energije

10.3.1 Posebni propisi, standardi i ostali normativni dokumenti

Države članice mogu – u skadu saČlanom 2 MID direktive - propisati brojila aktivne električne energije za upotrebu u domaćinstvu, poslovnom prostoru i lakoj industriji koja su u skladu sa uredbama MID direktive. Posebni zahtevi iz ovog poglavlja zasnovani su isključivo na Anesku MI-003.


Brojila aktivne električne energije uzimaju napone i merenja struje kao ulazni podatak, izvode aktivnu električnu energiju iz njega, i to integrišu u odnosu na vreme kako bi dali aktivnu električnu energiju.


Brojila aktivne električne energije se obično realizuju kao namenski uređaji (tip P u ovom dokumentu). Oni mogu imati jedan ili više ulaza i mogu da se koriste u kombinaciji sa spoljnim mernim transformatorima.


10.3.2.3 Princip merenja Brojila aktivne električne energije neprekidno meri aktivnu električnu energiju utrošenu u kolu. Vrednost utrošene energije se prikazuje u instrumentu. Koriste se razni pretvarači i multiplikatori principa.

Merenje energije ne može da se ponovi.

10.3.2.4 Otkrivanje greške i reakcija

Zahtev MI-003, 4.3.1 se bavi elektromagnetnim smetnjama. Postoji potreba da se ovaj zahtev za softverski kontrolisane instrumente protumači zato što je otkrivanje poremećaja i opravak moguć samo međusobnom saradnjom određenih hardverskih delova i određenog softvera. Sa softverske tačke gledišta nije bitno koji je bio razlog za poremećaj (elektromagnetni, električni, mašinski i sl.): sve procedure oporavka su iste.


75

10.3.3 Posebni softverski zahtevi (brojila aktivne električne energije)



Napomene:


Kratak opsi mehanizma za oporavak od greške i kada je pozvan. Kratak opis sličnih testova koje je sproveo proizvođač. Smernice za validaciju: Provere zasnovane na dokumentaciji: • Proverite da li je izvođenje oporavka od greške adekvatno. Funkcionalne provere: • Nema dodatnih pored onih koje su završene tokom ispitivanja tipa za potvrdu ispravnog funkcionisanja

u prisustvu definisanih količina na koje se utiče.



Klasa rizika B Klasa rizika C Klasa rizika D I3-2: Objekti za rezervno kopiranje Treba da postoji objekat koji u slučaju poremećaja, obezbeđuje periodično pravljenje rezervne kopije


treba da se pamte u skladištu koje se ne gubi nakon isključenja napajanja.

Napomene:

Ako se objekat za rezervno kopiranje koristi za oporavak od greške, mora da se izračuna minimalan interval kako bi se osiguralo da kritična izmena vrednosti nije prekoračena.


Kratak opis podataka koji su rezervno kopirani i kada se to dogodilo.



• Proverite da li se svi podaci koji podležu zakonskoj kontroli sačuvani u skladištu koje se ne gubi nakon isključenja napajanja i da li mogu da se vrate u prethodno stanje.

Funkcionalne provere: • Nema dodatnih pored onih koje su završene tokom ispitivanja tipa za potvrdu ispravnog funkcionisanja

u prisustvu definisanih količina na koje se utiče. Primer prihvatljivog rešenja:

Podaci koji podležu zakonskoj kontroli su rezervno kopirani kao što se zahteva (npr. svakih 60 minuta)


76


I3-3: MI-003, 5.2 (podobnost oznake) Prikaz ukupne energije mora da ima dovoljan broj cifara kako bi se osiguralo da se naznaka ne vrati na

početnu vrednost, kad brojilo bude radilo 4000 sati pri punom opterećenju (I = Imax, U = Un i PF = 1).

Napomene:

Potrebna dokumentacija: Dokumentacija o unutrašnjem opisu registra električne energije i pomoćnih količina (promenjive vrste).



Proverite da li je kapacitet skladišta dovoljan.

Primer prihvatljivog rešenja: Tipične vrednosti za trofazno brojilo električne energije su: Pmax (4000h) = 3*60 A * 230 V * 4000h = 165600 kWh. Ovo zahteva untrašnji opis od 4 bajta.

Klasa rizika B Klasa rizika C Klasa rizika D I3-4: MID-Aneks I, 8.5 (sprečavanje resetovanja kumulativnih mernih vrednosti) Kod komunalnih merila prikaz ukupne isporučene količine ili prikazi iz kojih može da se izvede ukupna



Napomene:






• Proverite da kumulativne merne vrednosti koje podležu zakonskoj kontroli ne mogu da se resetuju bez dokaza intervencije.


• Nema dodatnih onim koje su završene tokom ispitivanja tipa radi potvrde ispravnog funkcionisanja. Pogledajte P3 i P4.

Primer prihvatljivog rešenja: Registri za energiju su zaštićeni od izmena i resetovanja na isti način kao i parametri (pogledajte P7).


77


I3-5: Dinamičko ponašanje Softver koji ne podleže zakonskoj kontroli neće negativno uticati na dinamičko ponašanje procesa merenja.

Napomene:





• Dijagram tajminga softverskih zadataka. Ograničava proporcionalno vreme izvršavanja zadataka koji ne podležu zakonskoj kontroli



• Dokumentacija o ograničenjima za proporcionalno vreme izvršavanja zadataka koji ne podležu zakonskoj kontroli za programera softverskih delova koji ne podležu zakonskoj kontroli.




Hijerarhija prekida je dizajnirana da izbegne negativne uticaje.


78

Klasa rizika B Klasa rizika C Klasa rizika D I3-6: Štampana identifikacija softvera

Identifikacija softvera se obično prikazuje na ekranu. Izuzetak za brojila aktivne električne energije biće

utisnuta identifikacija softvera na pločici sa nazivom instrumenta koja je prihvatljivo rešenje ako su

ispunjenih sledeći zahtevi A, B i C:



B. Instrument nema interfejs za komunikaciju identifikacije softvera. C. Nakon proizvodnje merila, nije moguća promena softvera ili je moguća samo u slučaju promene


Napomene:


• Primenjuju se sve ostale posebne napomene P2/U2.









Elektronska komunalna merila često imaju puno parametara. Oni se koriste kao konstante za izračunavanje, kao parametri konfiguracije itd., ali takođe i za podešavanje funkcionalnosti uređaja. U pogledu identifikacije i zaštite parametara i skupova parametara pogledajte zaheve P2 i P7, vodič P.

U tekstu ispod su navedeni neki tipični parametri za brojila aktivne električne energije. (Ova tabela će se ažurirati kada WELMEC radna grupa 11 donese odluku o konačnom sadržaju).




Kumuliranje energije ili registar zapremine kod merila u domaćinstvu ne predstavlja dugoročno skladište u smislu Dodatka L (Poglavlje 6). Za instrument koji meri samo kumulativnu energiju/zapreminu, nije nepohodna primena dodatka L. 10.3.6 Dodela klase rizika U skladu sa odlukama nadležne WELMEC Radne grupe 11 (2. sastanak, 3/4 mart 2005.), za sada se smatra da je sledeća klasa rizika odgovarajuća i da treba da se primeni, ako se ispitivanje


79

softvera na osnovu ovog uputstva obavlja za (softverski kontrolisane) brojila aktivne električne energije:


RG11 razmatra da se funkcionalnost za plaćanje unapred i intervala merenja doda onim osnovnim mernim funkcijama utvrđenim u Aneksu MI-003 MID direktive, stoga nijedna veća kategorija rizika nije dodeljena ovim varijantama osim osnovnim tipovima brojila koji su već obuhvaćeni ovim vodičem za softver. Međutim, osnovna funkcija merenja treba da se proceni, uz sve ostale P tipove, zajedno sa ostalim procenama koje se smatraju neophodnim da se pokaže da pripadajući softver koji obezbeđuje te funkcije ne utiče neprihvatljivo na osnovno merenje.


80

10.4 Merila toplotne energije


Države članice mogu – u skadu sa Članom 2 MID direktive – propisati merila toplotne energije za upotrebu u domaćinstvu, poslovnom prostoru i lakoj industriji koji su u skladu sa uredbama MID direktive. Posebni zahtevi iz ovog poglavlja zasnovani su isključivo na Anesku MI-004. OIML preporuke iili IEC standardi nisu razmatrani.



Merila toplotne energije se obično realizuju kao namenski uređaji (tip P u ovom dokumentu). Merila toplotne energije su ili kompletan ili kombinovani instrument koji se sastoji iz podsklopova senzora protoka, para senzora temperature, i računske jedinice, kao što je definisano članom 4(b) MID u direktivi, ili njihovim kombinacijama.


10.4.2.3 Princip merenja Merila toplotne energije konstantno meri potrošenu energiju u sistemu za grejanje. Potrošena toplotna energija se prikazuje na instrumentu. Primenjeni su razni principi.

Merenje energije ne može da se ponovi.

10.4.2.4 Otkrivanje greške i reakcija Zahtevi MI-004, 4.1 i 4.2 se bave elektromagnetnim smetnjama. Postoji potreba da se ovaj zahtev za softverski kontrolisane instrumente protumači zato što je otkrivanje poremećaja i opravak moguć samo međusobnom saradnjom određenih hardverskih delova i određenog softvera. Sa softverske tačke gledišta nije bitno koji je bio razlog za poremećaj (elektromagnetni, električni, mašinski i sl.): sve procedure oporavka su iste.


81

10.4.3 Posebni softverski zahtevi (merila toplotne energije)



Posebne napomene:


Kratak opsi mehanizma za oporavak od greške i kada je pozvan.

Smernice za validaciju: Provere zasnovane na dokumentaciji: • Proverite da li je izvođenje oporavka od greške adekvatno. Funkcionalne provere: • Nema dodatnih pored onih završenih tokom ispitivanja tipa za potvrdu ispravnog funkcionisanja u

prisustvu definisanih količina na koje se utiče.




I4-2: Objekti za rezervno kopiranje Treba da postoji objekat koji u slučaju poremećaja, obezbeđuje periodično pravljenje rezervne kopije


treba da se zapamte u skladištu koje se ne gubi nakon isključenja napajanja.

Posebne napomene:



Kratak opis podataka koji su rezervno kopirani i kada se to dogodilo. Izračunavanje maksimalne greške koja može da se javi za kumulativne vrednosti.



• Proverite da li se svi podaci koji podležu zakonskoj kontroli sačuvani u skladištu koje se ne gubi nakon isključenja napajanja i da li mogu da se vrate u prethodno stanje.

Funkcionalne provere: • Nema dodatnih pored onih koji su završeni tokom ispitivanja tipa za potvrdu ispravnog funkcionisanja u


Podaci koji podležu zakonskoj kontroli su rezervno kopirani kao što se zahteva (npr. svakih 60 minuta)


82

Klasa rizika B Klasa rizika C Klasa rizika D I4-3: MID-Aneks I, 8.5 (sprečavanje resetovanja kumulativnih mernih vrednosti) Kod komunalnih merila prikaz ukupne isporučene količine ili prikazi iz kojih može da se izvede ukupna



Posebne napomene:

Kumulativni registri merila mogu da se resetuju pre nego što se stave u upotrebu. Potrebna dokumentacija:







Primer prihvatljivog rešenja: Registri za zapreminu su zaštićeni od izmena i resetovanja istim metodama kao i parametri (pogledajte P7).

Klasa rizika B Klasa rizika C Klasa rizika D I4-4: Dinamičko ponašanje Softver koji ne podleže zakonskoj kontroli neće negativno uticati na dinamičko ponašanje procesa merenja.

Posebne napomene:





• Dijagram tajminga softverskih zadataka. Ograničava proporcionalno vreme izvršavanja zadataka koji ne podležu zakonskoj kontroli.



• Dokumentacija o ograničenjima proporcionalnog vremena izvršavanja zadataka koji ne podležu zakonskoj kontroli za programera softverskih delova koji ne podležu zakonskoj kontroli.




Hijerarhija prekida je dizajnirana da izbegne negativne uticaje.


83


Identifikacija softvera se obično prikazuje na ekranu. Izuzetak za merila toplotne energije biće utisnuta

identifikacija softvera na pločici sa nazivom instrumenta koja je prihvatljivo rešenje ako su ispunjenih

sledeći zahtevi A, B i C:

A. Korisnički interfejs nema nikakvu sposobnost kontrole da aktivira oznaku identifikacije softvera na ekranu ili ekran tehnički ne dozvoljava prikazivanje identifikacije softvera (mehanički brojač).

B. Instrument nema interfejs za komunikaciju identifikacije softvera. C. Nakon proizvodnje merila, nije moguća promena softvera ili je moguća samo u slučaju promene


Posebne napomene:










Merila toplotne energije imaju parametre kao što su konstante za izračunavanje, za konfiguraciju itd., ali takođe i za podešavanje funkcionalnosti uređaja. U pogledu identifikacije i zaštite parametara i skupova parametara pogledajte zaheve P2 i P7, vodič P.

U tekstu ispod su navedeni neki tipični parametri za merila toplotne energije. (Ova tabela će se ažurirati kada WELMEC radna grupa 11 donese odluku o konačnom sadržaju).




Kumuliranje energije ili registar zapremine kod merila u domaćinstvu ne predstavlja dugoročno skladište u smislu Dodatka L (Poglavlje 6). Za instrument koji meri samo kumulativnu energiju/zapreminu, nije nepohodna primena dodatka L.

10.4.6 Dodela klase rizika Za sada, a u skladu sa odlukama nadležne WELMEC Radne grupe 11 (2. sastanak, 3./4. mart 2005.), smatra se da je sledeća klasa rizika odgovarajuća i da treba da se primeni, ako se ispitivanje softvera na osnovu ovog uputstva obavlja za (softverski kontrolisana) merila toplotne energije:


84



85

10.5 Merni sistemi za neprekidno i dinamičko merenje količina tečnosti koje nisu voda

Merni sistemi za neprekidno i dinamičko merenje količina tečnosti koje nisu voda podležu uredbama MID direktive. Posebni zahtevi se nalaze u aneksu MI-005. Do sada nisu razmatrani niti ovi specifični zahtevi, niti bilo koji normativni dokumenti.

Tačke 10.5.1 - 10.5.2 će biti popunjene ako se ukaže potreba u budućnosti.

10.5.3 Posebni softverski zahtevi (merni sistemi za tečnosti koje nisu voda)

Klasa rizika B Klasa rizika C Klasa rizika D I5-1: Štampana identifikacija softvera

Identifikacija softvera se obično prikazuje na ekranu. Izuzetak za komponente mernih sistema za tečnosti

koje nisu voda biće utisnuta identifikacija softvera na pločici za tip komponente koja je prihvatljivo rešenje

ako su ispunjeni sledeći zahtevi A, B i C:


ekranu ili ekran tehnički ne dozvoljava prikazivanje identifikacije softvera ili nema ekrana na instrumentu.

B. Instrument nema interfejs za komuniciranje identifikacije softvera.

C. Nakon proizvodnje instrumenta nije moguća promena softvera ili je moguća samo u slučaju promene hardvera ili hardverskog dela.

Posebne napomene:

• Indikator koji prikazuje identifikaciju softvera mora biti neizbrisiv i neprenosiv.


• Primenjuju se sve ostale posebne napomene P2/U2.







Primer prihvatljvog rešenja:


Odeljci 10.5.4 i 10.5.5 će biti popunjeni ako se u budućnosti ukaže potreba. 10.5.6 Dodela klase rizika Na osnovu rezultata upitnika (2004) WELMEC Radne grupe 7 koji su predmet budućih odluka nadležne WELMEC Radne grupe, za sada treba da se primeni sledeća klasa rizika ako se ispitivanje softvera na osnovu ovog vodiča obavljaju za (softverski kontrolisane) merne sisteme za neprekidno i dinamičko merenje količina tečnosti koje nisu voda.

- Klasa rizika C


86

10.6 Merila Merila se dele na dve glavne kategorije:

1. Vage sa neautomatskim funkcionisanjem (NAWI), i 2. Vage sa automatskim funkcionisanjem (AWI).

Dok je većina AWI vaga regulisana MID direktivom, NAWI vage nisu; one su i dalje regulsane Evropskom regulativom 90/384/EEC. Stoga se vodič za softver WELMEC 2.3 odnosi na NAWI vage, dok se ovaj vodič za softver primenjuje na AWI vage.

Posebni zahtevi u okviru ovog odeljka zasnovani su na Aneksu MI-006 i normativnim dokumentima koji su pomenuti u 10.6.1 i koliko je god moguće podržavaju tumačenje zahteva iz MID direktive.


5 kategorija vaga sa automatskim funkcionisanjem (AWI) podležu uredbama Aneksa MI-006 MID direktive:

- Automatske vage za pojedinačno merenje (R51)

- Automatske dozirne vage (R61)

- Automatska vaga sa sabiranjem diskontinuiranih rezultata merenja (R107)

- Automatska vaga sa sabiranjem kontinuiranih rezultata merenja (R50)

- Automatska vaga za merenje mase šinskih vozila u pokretu (R106) Brojevi u zagradama se odnose na odgovarajuće OIML preporuke koje predstavljaju normativne dokumente u smislu MID direktive. Pored toga, WELMEC je objavio WELMEC Vodič 2.6 koji podržava testiranje automatskih vaga za pojedinačno merenje.

Postoji jedna kategorija AWI vaga koje nisu regulisane MID direktivom: - Automatske vage za merenje vozila u pokretu (R134)

AWI vage iz svih kategorija mogu da se ostvare kao tip P ili tip U, i svi dodaci odgovaraju svim kategorijama.

Međutim, iz ovih 6 kategorija, samo automatske vage sa sabiranjem diskontinuiranih rezultata merenja i automatske vage sa sabiranjem kontinuiranih rezultata merenja su zahtevani instrumenti kod posebnih softverskih zahteva (pogledajte 10.6.3). Razlog za to je što se merenje tokom relativno dugog vremenskog perioda nagomilava i ne može da se ponovi u slučaju značajnog kvara.



Automatska vaga sa sabiranjem diskontinuiranih rezultata merenja je automatska dozirna vaga koja određuje masu sklaištenih proizvoda (npr. zrna) njihovim deljenjem na odvojene mase. Sistem se obično sastoji iz jedne ili više automatske vage sa sabiranjem diskontinuiranih rezultata merenja podržane na mernom pretvaraču, napajanja i elektronskih kontrola i pokazivačkog uređaja.

Automatska vaga sa sabiranjem kontinuiranih rezultata merenja je automatska vaga sa sabiranjem kontinuiranih rezultata merenja koja meri masu proizvoda dok traka prolazi kroz merni pretvarač. Sistem se obično sastoji iz transportne trake, valjaka, prijemnika opterećenja na mernim pretvaračima, napajanja, elektronskih kontrola i pokazivačkog uređaja. Postojaće metode za podešavanje zategnutosti trake.


87

10.6.2.2 Konfiguracija softvera Ona je specifična za svakog proizvođača, ali obično treba očekivati da se prate preporuke koje su navedene u glavnom delu ovog vodiča.

10.6.2.3 Princip merenja U slučaju automatske vage sa sabiranjem diskontinuiranih rezultata merenja proizvoda u rasutom stanju se unosi u silos i meri. Masa svake odvojene mase se određuje uzastopno i sabira. Svaka odvojena masa se zatim dodaje proizvodu u rasutom stanju.

U slučaju automatskih vaga sa sabiranjem kontinuiranih rezultata merenja masa se kontinuirano meri dok proizvod prolazi kroz prijemnik opterećenja. Merenja se obavljaju u odvojenim vremenskim jedinicama koje zavise od brzine trake i sile na prijemniku opterećenja. Nema namerne podpodele proizvoda ili prekida transportne trake kao kod automatske vage sa sabiranjem diskontinuiranih rezultata merenja. Ukupna masa prestavlja sjedinjavanje odvojenih uzoraka. Treba napomenuti da prijemnik opterećenja može da koristi tezometrijske merne pretvarače ili druge tehnologije kao što su vibrirajuća žica.

10.6.2.4 Neispravnost Spojevi na traci mogu da generišu šok efekat, koji može da dovede do pogrešnih događaja prilikom podešavanja na nulu. Kod automatske vage sa sabiranjem diskontinuiranih rezultata merenja, jedan ili više mernih rezultata odvojenih masa može da se izgubi pre sabiranja.

10.6.3 Posebni softverski zahtevi (automatske vage sa sabiranjem diskontinuiranih rezultata i automatske vage sa sabiranjem kontinuiranih rezultata merenja)

Aneks MI-006 MID direktive, Poglavlje IV, Odeljak 8, Poglavlje V, Odeljak 6, bavi se elektromagnetnim smetnjama. Postoji potreba da se ovi zahtevi tumače za softverski kontrolisane instrumente zato što su otkrivanje poremećaja (greške) i naknadni oporavak mogući samo međusobnom saradnjom određenih delova hardvera i određenog softvera. Sa softverske tačke gledišta, nije važno koji je bio razlog za poremećaj (elektromagnetni, električni, mašinski i sl.): sve procedure oporavka su iste.


88

Klasa rizika B Klasa rizika C Klasa rizika D I6-1: Otkrivanje greške

Softver treba da otkrije da je došlo do poremećaja normalnog rada.

Posebne napomene:

Pri otkrivanju greške:

a. Kumulativno merenje i ostali podaci koji podležu zakonskoj kontroli će se automatski sačuvati u skladištu koje se ne gubi nakon isključenja napajanja (pogledajte zahtev I6-2), i

b. Automatska vaga sa sabiranjem diskontinuiranih rezultata merenja ili automatska vaga sa sabiranjem kontinuiranih rezultata merenja će se automatski zaustaviti, ili će se dati vidljivi signal ili zvučni alarm (pogledajte Potrebna dokumentacija)

Potrebna dokumentacija: Kratak opis šta je sve provereno, šta je potrebno za pokretanje procesa otkrivanja greške, koja radnja je preduzeta za oktrivanje kvara. Ako prilikom otkrivanja greške nije moguće automatski bez kašnjenja zaustaviti sistem za prenos (npr. usled bezbednosnih razloga), dokumentacija treba da sadržati opis kako se postupa sa neizmerenim materijalom ili propisno uzeti u obzir.



• Proverite da li je otkrivanje greške odgovarajuće.

Funkcionalne provere: • Ako je moguće: simulirajte određene greške u hardveru i proverite da li su otkrivene i da li na njih reaguje

softver kao što je opisano u dokumentaciji. Primer prihvatljivog rešenja:

Kontrola hardvera se resetuje putem ciklično obrađenog mikroprocesora podprograma kako bi se sprečilo pokretanje kontrole. Pre resetovanja, potprogram proverava funkcionisanje sistema, npr. da li su svi potprogrami koji podležu metrološkoj kontroli obrađeni tokom poslednje pauze. Ako bilo koja funkcija nije obrađena ili – u najgorem slučaju – mikroprocesor visi u proizvoljnoj beskonačnoj petlji, ne dolazi do resetovanja kontrole i ona se pokreće nakon određenog vremenskog perioda.


89

Klasa rizika B Klasa rizika C Klasa rizika D I6-2: Objekti za rezervno kopiranje Treba da postoji objekat koji će u slučaju poremećaja obezbediti pravljenje rezervne kopije podataka koji

podležu zakonskoj kontroli, kao što su merne vrednosti i trenutni status procesa.

Napomene:

a. Karakteristike stanja i važnih podataka treba da se zapamte u skladištu koje se ne gubi nakon isključenja napajanja.

b. Ovaj zahtev se obično odnosi na kontrolisani objekat za skladištenje koji obezbeđuje automatsko kreiranje rezervnih kopija u slučaju poremećaja. Periodično rezervno kopiranje je prihvatljivo samo ako kontrolisani objekat za pamćenje nije dostupan zbog hardverskih ili funkcionalnih ograničenja. U tom izuzetnom slučaju razmaci između pamćenja moraju biti dovoljno mali, odnosno maksimalna moguća neusaglašenost između sadašnjih i sačuvanih vrednosti mora biti u okviru definisanog razlomka maksimalne dozvoljene greške (pogledajte Potrebnu dokumentaciju).

c. Objekti rezervnog kopiranja treba da sadrže odgovarajuće mogućnosti za podizanje sistema kako sistem za merenje, kao i njegov softver, ne bi upali u neodređeno stanje usled poremećaja.


Kratak opis mehanizama za rezervno kopiranje i podataka koji su rezervno kopirani i kada se to dogodilo. Specifikacija ili proračun maksimalne greške do koje može doći za kumulativne vrednosti ako se rezervno kopiranje ostvaruje ciklično (periodično).



• Proverite da li su svi podaci koji podležu zakonskoj kontroli sačuvani u slučaju poremećaja.

Funkcionalne provere: • Proverite simuliranjem poremećaja da li mehanizam za rezervno kopiranje radi kao što je opisano u

dokumentaciji. Primer prihvatljivog rešenja:

Kontrola hardvera se pokreće kada nije ciklično resetovano. Ovaj alarm aktivira prekid na mikroprocesoru. Dodeljeni prekid rutine odjednom prikuplja merne vrednosti, vrednosti stanja i osale relevatne podatke i smešta ih u skladište koje se ne gubi nakon isključenja napajanja, npr. EEPROM ili drugo odgovarajuće skladište.

Napomena: Pretpostavlja se da kontrolni prekid ima najviši prioritet prekida i može da dominira bilo kojom normalno obradom ili bilo kojom proizvoljnom beskonačnom petljom, odnosno kontrola programa uvek preskoči na prekid rutine ako se pokrene kontrola.


90

10.6.4 Primeri funkcija i podataka koji podležu zakonskoj kontroli

Tabela 10-1: Primeri fukcija i podataka specifičnih za uređaj i tip koje podležu zakonskoj kontroli (DF, DD, TF, TD) za AWI vage u poređenju sa onim na vagama sa neautomatskim funkcionisanjem (R76). VV označava vrednosti varijable.

Funkcije/podaci Tip OIML Preporuka Br.

50 51 51 61 76 106 107 (X) (Y)

Izračunavanje težine TF, TD X X X X X X X

Analiza stabilnosti TF, TD X X X X X X

Izračunavanje cene TF, TD X X

Zaokruživanje algoritma za cenu TF, TD X X

Raspon (osetljivosti) DD X X X X X X X

Ispravke za nelinearnost DD (TD) X X X X X X X

Maks, Min, e, d DD (TD) X X X X X X X

Jedinice merenja (e.g. g, kg) DD (TD) X X X X X X X

Vrednost prikazane težine (zaokruženo na multiplikatore e ili d)

VV X X X X X

Tara, predefinisana tare VV X X X X X

Jedinična cena, cena koja treba da se plati VV X X X

Vrednost težine u internoj analizi VV X X X X X X X

Signali statusa (npr. indikacija nule, stabilnost ravnoteže)

TF X X X X X X X

Poređenje stvarne vrednosti u odnosu na zadatu vrednost

TF X X

Objava automatskog otiska, npr. prekid automatske operacije

TF X X

Vreme zagrevanja TF (TD) X X X X X X X

Prekid između funkcija TF X X

Npr. podešavanje nule/tare X X X X

Automatska/neauotmatska operacija, X

Podešavanje nule/sabiranje X X

Beleženje pristupa dinamičkom podešavanju

TF (VV) X X

Maksimalna stopa rada/opseg radnih brzina (dinamičko merenje)

DD (TD) X X X X X X

(Proizvod) -parametri za izračunavanje dinamičke težine

VV X X X

Predefinisana vrednost težine VV X X

Širina opsega podešavanja DD (TD) X X

Kriterijum za automatsko podešavanje nule (npr. vremenski interval, kraj ciklusa merenja)

DD (TD) X X X X X

Minimalno pražnjenje, ocenjena minimalna popuna

DD X X

Ograničavanje vrednost značajne greške (ako nije 1e ili 1d)

DD (TD) X X

Ograničavanje vrednost baterije DD (TD) X X X X X X X

Tabela 10-1: Primeri funkcija i podataka specifičnih za uređaj i tip koji podležu zakonskoj kontroli


91

Označene funkcije i parametri će se verovatno pojaviti na različitim vrstama merila. Ako je neka od njih prisutna, ona se onda tretira kao „da podleže zakonskoj kontroli“. Tabela međutim ne predstavlja obaveznu listu koja ukazuje na to da bilo koja pomenuta funkcija ili parametar moraju da postoje u svakom instrumentu.

10.6.5 Ostala stanovišta

Nema

10.6.6 Dodela klase rizika

Na osnovu odluke nadležne WELMEC Radne grupe (24 sastanak RG2, 22./23. januara 2004.), klasa rizika „B“ za sada može generalno da se primeni na sve kategorije AWI vaga bez obzira na tip (P ili U).

Međutim, kao rezultat upitnika RG7 (2004), sledeća diferencijacija u odnosu na tip P i U instrumenata, kao i u odnosu na automatske vage sa sabiranjem diskontinuiranih rezultata merenja i automatske vage sa sabiranjem kontinuiranih rezultata merenja (= „vage sa sabiranjem“) se čini prikladnom, o kojoj će se ponovo raspravljati na WELMEC RG2 (odluka sa 25. sastanka RG2, 14/15 oktobra 2004.):

- Klasa rizika B za tip P instrumente (osim vage sa sabiranjem)

- Klasa rizika C za tip U instrumente i vage sa sabiranjem tipa P i U


92

10.7 Taksimetri Taksimetri podležu uredbama MID direktive. Posebni zahtevi se nalaze u Aneksu MI-007. Ni ovi posebni zahtevi, niti bilo koji normativni dokumenti još nisu razmatrani.


Evropski standard EN50148 koji bi mogao da postane normativni dokument u smislu MID direktive, još nije uzet u razmatranje. Objavljen je dokument sa uputstvima za taksimetre kao rezultat projekta MID-procedura. Ovaj dokument će u budućnosti biti osnova WELMEC vodiča. Osim toga je napravljen i prvi nacrt OIML Preporuke o taksimetrima. OIML dokument, međutim, još uvek ne može da se koristi kao normativni akt (stanje iz oktobra 2004).


Taksimetar kao što je definisano MID direktivom, meri trajanje vožnje, i izračunava razdaljinu (MID direktiva ne obuhvata upotrebu izlazne vrednosti generatora signala rastojanja) i izračunava cenu prevoza za putovanje na osnovu važeće tarife.

Postojeći taksimetri koristite ugrađenu arhitekturu, što znači da su taksimetri namenski instrumenti (tip P) u smislu ovog ovog. U budućnosti se očekuje da će taksimetri takođe biti proizvedeni korišćenjem univerzalnih računara (tip U).

10.7.2 Posebni softverski zahtevi

MID Aneks MI-007, 9:

U slučaju smanjenja napona na vrednost koja je niža od donje granice rada koju je naveo proizvođač, taksimetar će:

- nastaviti ispravno da radi ili će nastaviti sa ispravnim funkcionisanjem bez gubitka podataka koji su bili dostupni pre pada napona, ako je pad napona privremen usled ponovnog pokretanja uređaja,

- prekinuti postojeće merenje i vratiti se na poziciju „slobodan“ ako je napon pao na duži period.

Taksimetar takođe mora da ima dugoročno skladište, podaci treba da su dostupni u taksimetru najmanje 1 godinu, pogledajte MI-007, 15.2.


93

Klasa rizika B Klasa rizika C Klasa rizika D I7-1: Objekti za rezervno kopiranje Treba da postoji objekat koji će automatski rezervno kopirati najvažnije podatke, npr. merne vrednosti i

trenutni status procesa ukoliko dođe do pada napona na duži period.

Posebne napomene:

1) Ovi podaci treba da su zapamte u skladištu koje se ne gubi nakon isključenja napajanja.

2) Detektor nivoa napona otkriva kada treba skladištiti merne vrednosti.

3) Objekti za rezervno kopiranje treba da sadrže mogućnosti podizanja sistema kako taksimetar i softver ne bi otišli u neodređeno stanje.


Kratak opis podataka koji su rezervno kopirani i kada se to dogodilo.


Provere na osnovu dokumentacvije:

• Proverite da li je oporavak greške odgovarajući.

Funkcionalne provere: • Nema dodatnih pored onih koje su završene tokom ispitivanja tipa za potvrdu ispravnog funkcionisanja u


Detektor nivoa napona inicira prekid kada nivo napona traje 15 sekundi. Pripisani prekid rutine prikuplja merne vrednosti, vrednosti stanja i ostale odgovarajuće podatke i čuva ih u skladištu koje se ne gubi nakon isključenja napajanja npr. EEPROM. Nakon rasta naponskog nivoa, podaci se vraćaju u prethodno stanje i nastavlja se sa radom ili se zaustavlja (pogledajte MI-007, 9).

Napomena: Pretpostavlja se da se nivo prekida napona ima visok prioritet prekida i može da dominira bilo kojom normalno obradom ili bilo kojom proizvoljnom beskonačnom petljom, odnosno kontrola programa uvek prelazi na prekid rutine ako napon padne.

10.7.4 Primeri funkcija i podataka koji podležu zakonskoj kontroli

U narednoj tabeli su navedeni neki tipični parametri taksimetra.

Parametar Zaštičeno Podesivo Komentar k-faktor x Impulsa po km

Tarife x x Jedinica valute/km, Jedinica valute/h Parametri interfejsa x Stopa brzine itd.


94

10.7.5 Ostala stanovišta

Preporučuje se da se Direktiva o automobilima ili bilo koji drugi propis koji je kreiran preispita kako bi se videlo koji su zahtevi za generatore signala rastojanja vozila koji se koriste kao taksi vozilima. Preliminarni predlog glasi: Za vozila koja će se koristiti kao taksi vozika važe sledeći zahtevi:

1. Generator signala rastojanja daje signal sa rezolucijom od najmanje 2 m. 2. Generator signala rastojanja daje stabilan signal pri svakoj brzini. 3. Generator signala rastojanja mora da definiše karakteristike u pogledu nivoa napona,

raspona impulsa i odnosa brzine i frekvencije. 4. Mogućnost obavljanja testiranja...


Na osnovu rezultata iz upitnika WELMEC RG7 (2004) i uz poštovanje budućih odluka nadležne WELMEC Radne grupe, za sada treba da se primeni sledeća klasa rizika, ukoliko se sprovode pregledi softvera na osnovu ovog vodiča a za (softverski kontrolisane) taksimetre:

- Klasa rizika C za tip P instrumente

- Klasa rizika D za tip U instrumente


95

10.8 Materijalizovane mere Materijalizovane mere su u skladu sa uredebama MID direktive. Posebni zahtevi se nalaze u Aneksu MI-008.

Materijalizovane mere u smislu Aneksa MI-008 MID direktive, koje će biti predmet budućih kretanja i odluka, se ne smatraju softverski kontrolisanim merilima. Stoga se ovaj vodič za softver za sada ne odnosi na materijalizovane mere.


96

10.9 Merila dimenzije Merila dimenzije su u skladu sa uredbama MID direktive. Posebni uslovi se nalaze u Aneksu MI-009. Ni ovi posebni zahtevi niti bilo koji normativni dokumenti još nisu razmatrani.

Odeljci 10.9.1 - 10.9.5 će biti popunjeni ako se u budućnosti ukaže potreba.


Na osnovu rezultata iz upitnika WELMEC RG7 (2004) i uz poštovanje budućih odluka nadležne WELMEC Radne grupe, za sada treba da se primeni sledeća klasa rizika, ukoliko se sprovode pregledi softvera na osnovu ovog vodiča a za (softverski kontrolisane) merila dimenzije:

- Klasa rizika B za tip P instrumente

- Klasa rizika C za tip U instrumente


97

10.10 Analizatori izduvnih gasova Analizatori izduvnih gasova su u skladu sa uredbama MID direktive. Posebni uslovi se nalaze u Aneksu MI-010. Ni ovi posebni zahtevi niti bilo koji normativni dokumenti još nisu razmatrani.

10.10.1 - 10.10.5 će biti popunjeni ako se u budućnosti ukaže potreba.


Na osnovu rezultata iz upitnika WELMEC RG7 (2004) i uz poštovanje budućih odluka nadležne WELMEC Radne grupe, za sada treba da se primeni sledeća klasa rizika, ukoliko se sprovode pregledi softvera na osnovu ovog vodiča a za (softverski kontrolisane) analizatore izduvnih gasova:

- Klasa rizika B za tip P instrumente

- Klasa rizika C za tip U instrumente


98

11 Definicija klase rizika

11.1 Opšti princip Zahtevi iz ovog vodiča su diferencirani prema (softverskim) klasama rizika. Rizici se odnose na softver merila i ne na bilo koje druge rizike. Iz praktičnih razloga se koristi kraći termin „klasa rizika“. Svako merilo mora biti dodeljeno klasi rizika, zato što su pojedini softverski zahtevi koji će se primeniti regulisani klasom rizika kojoj pripada instrument. Klasa rizika je definisana kombinacijom odgovarajućih nivoa potrebnih za zaštitu softvera, ispitivanjem softvera i usaglašenošću softvera. U svakoj kategoriji postoji tri nivoa: nizak, srednji i visok.

11.2 Opis nivoa za zaštitu, pregled i usaglašenost Sledeće definicije se koriste za odgovarajuće nivoe.

Nivo zaštite softvera

Nizak: Ne zahtevaju se posebne mere zaštite od namernih izmena. Srednji: Softver je zaštićen od načinjenih namernih izmena pomoću lako dostupnih i

jednostavnih zajedničkih softverskih alata (npr. uređivača teksta).

Visok: Softver je zaštićen od načinjenih namernih izmena korišćenjem sofisticiranih softverskih alata (funkcije za otklanjanje grešaka i uređivači čvrstog diska, alati za razvoj softvera, itd.).


Nizak: Obavlja se standardno ispitivanje tipa funkcionalnog testiranje instrumenta. Nije potrebno dodatno testiranje softvera.

Srednji: Pored ispitivanja na nižem nivou, softver se ispituje na osnovu njegove dokumentacije. Dokumentacija sadrži opis funkcija softvera, opis parametara, itd. Praktični testovi softverski podržanih funkcija (nasumične provere) mogu da se sprovode radi provere verodostojnost dokumentacije i efikasnosti mera zaštite.

Visok: Pored srednjeg nivoa, sprovodi se dubinsko testiranje softvera, obično na osnovu izvornog kôda.


Nizak: Funkcionalnost implementiranog softvera za svaki pojedinačni instrument je u skladu sa odobrenom dokumentacijom.

Srednji: Uz nivo usaglašenosti „nisko“, u zavisnosti od tehničkih funkcija, softverski delovi će se definisati kao nepromenjivi pri ispitivanju tipa, odnosno promenjivi samo u okviru odobrenja notifkovanog tela. Nepromenjivi deo će biti isti u svakom pojedinačnom instrumentu.

Visok: Softver koji je implementiran u pojedinačnim instrumentima biće potpuno identičan sa odobrenim.


99

11.3 Nastajanje klase rizika Od 27 teoretski mogućih nivoa, samo 4 ili najviše 5 su praktično od interesa (klase rizika B, C, D i E, na kraju F). One obuhvataju sve klase instrumenata koje potpadaju pod uredbu MID direktive. Štaviše, one pružaju dovoljno mogućnosti za slučaj promene procene rizika. Klase su definisane u tabeli ispod.

Klasa rizika Zaštita softvera Ispitivanje tipa Stepen usaglašenosti softvera

A nizak nizak nizak

B srednji srednji nizak

C srednji srednji srednji

D high srednji srednji

E visok visok srednji

F visok visok visok

Tabela 11-1: Definicija klase rizika

11.4 Tumačenje klasa rizika

Klasa rizika A: Ovo je najniža klasa rizika. Nema posebnih mera koje su potrebne za zaštitu od namernih izmena softvera. Ispitivanje softvera je deo funkcionalnog ispitivanja uređaja. Usaglašenost se zahteva na nivou dokumentacije. Ne očekuje se da se svaki instrument klasifikuje kao instrument klase rizika A. Međutim, uvođenjem ove klase, stoji otvorena mogućnost.

Klasa rizika B: U poređenju sa klasom rizika A, zaštita softvera je potrebna na srednjem nivou. Shodno tome, nivo ispitivanja je unapređen na srednji nivo. Usaglašenost je ista u odnosu na klasu rizika A.

Klasa rizika C: U odnosu na klasu rizika B, nivo usaglašenosti se podiže na „srednji“. To znači da softverski delovi mogu da se proglase nepromenjivim pri ispitivanju tipa. Ostatak softvera treba da bude u skladu na funkcionalnom nivou. Nivoi zaštite i ispitivanja ostaju nepromenjeni u odnosu na rizik B klase.

Klasa rizika D: Značajna razlika u odnosu na klasu rizika C je unapređenje nivoa zaštite na „visok“. Pošto nivo ispitivanja ostaje nepromenjen na „srednji“, mora da se obezbedi dovoljno informativna dokumentacija kako bi se pokazalo da su mere zaštite koje su preduzete odgovarajuće. Nivo usaglašenosti ostaje nepromenjen u odnosu na klasu rizika C.

Klasa rizika E: U odnosu na klasu rizika D, nivo ispitivanja je unapređen na „visok“. Nivoi zaštite i usklađenosti ostaju nepromenjeni.

Klasa rizika F: Nivoi u pogledu svih aspekata (zaštita, ispitivanja i usaglašenost) su podešeni na „visok“. Kao kod klase rizik A, ne očekuje se da se bilo koji instrument klasifikuje kao instrument F rizika. Međutim, uvođenjem ove klase, ostaje otvorena mogućnost.


100

12 Obrazac za izveštaj o testiranju (uključujući kontrolnu listu)

Ovo je obrazac za izveštaj o testiranju koji se sastoji iz glavnog dela i dva aneksa. Glavni deo sadrži opšte izjave o predmetu koji se testira. On u praksi mora na odgovarajući način da se prilagodi. Aneks 1 se sastoji iz dve kontrolne liste kao pomoć pri izboru odgovarajućih delova vodiča koji treba se primene. Aneks 2 se sastoji iz specifičnih kontrolnih listi koje se odnose na odgovarajuće tehničke delove vodiča.Oni se preporučuju kao pomoć proizvođačima i ispitivaču kao dokaz da su razmotrili sve primenljive uslove.

Uz obrasac izveštaja o testiranju i kontrolne liste, u poslednjem stavu ovog poglavlja su navedene informacije potrebne za potvrdu o ispitivanju tipa.


101

12.1 Obrazac opšteg dela izveštaja o testiranju

Izveštaj o testiranju br. XYZ122344

Merač protoka, model DF101 kompanije Dynaflow

Validacija softvera

(n aneksi)

Komisija

Direktiva o merilima (MID) pruža osnovne zahteve za određena merila koja se koriste u Evropskoj uniji. Softver merila se validira i pokazuje usaglašenost sa osnovnim zahtevima MID direktive.

Validacija je zasnovana na izveštaju WELMEC MID Vodiča za softverske zahteve WELMEC Vodič 7.2), u kom su protumačeni i objašnjeni neophodni softverski zahtevi. Ovaj izveštaj opisuje ispitivanje softvera koje je potrebno za potvrdu usaglašenosti sa MID direktivom.

Klijent

Dynaflow P.O. Box 1120333 100 Rejkjavik, Island

Davalac preporuke: G. Bjarnur Sigfridson

Predmet testiranja

Merač protoka DF100 kompanije Dynaflow je merilo namenjeno za merenje protoka u tečnostima. Definisan opseg je od 1 l/s do 2000 l/s. Osnovne funkcije instrumenta su:

- Merenje protoka u tečnostima

- Prikaz izmerene zapremine

- Interfejs za pretvarač

Merač protoka je u WELMEC Vodiču 7.2 opisan kao:

- Namensko merilo (ugrađeni sistem)

- Dugoročno skladište podataka koji podležu zakonskoj kontroli Merač protoka DF100 je nezavisan instrument sa priključenim pretvaračem. Pretvarač je pričvršćen na instrument i ne može da se isključi. Izmerena zapremina se prikazuje na ekranu. Komunikacija sa ostalim uređajima nije moguća.

Ugrađeni softver merila a je razvio

Dynaflow, P.O. Box 1120333, 100 Rejkjavik, Island.


102

Verzija validiranog softvera je V1.2c. Izvorni kôd se sastoji iz sledećih datoteka:

main.c 12301 bajtova 23. nov. 2003.

int.c 6509 bajtova 23. nov. 2003.

filter.c 10897 bajtova 20. okt. 2003.

input.c 2004 bajtova 20. okt. 2003

display.c 32000 bajtova 23. nov. 2003.

Ethernet.c 23455 bajtova 15. jun 2002.

driver.c 11670 bajtova 15. jun 2002.

calculate.c 6788 bajtova 23. nov. 2003.

Validacija je potpomognuta sa sledećim dokumentima proizvođača:

- DF 100 Uputstvo za upotrebu

- DF 100 Uputstvo za održavanje

- Opis softvera DF100 (dokument internog dizajna od 22. nov. 2003.)

- Šema elektronskog kola DF100 (crtež br.222-31, od15. okt. 2003.) Konačna verzija predmeta testiranja je dostavljena 25. novembra 2003. Nacionalnoj laboratoriji za testiranje i merenje.

Postupak pregleda

Validacija je obavljena u skladu sa WELMEC 7.2 Vodičem za softver, broj 1 (preuzeto sa lokacije www.welmec.org).

Validacija je obavljena u periodu od 1. novembra do 23. decembra 2003. Pregled je obavio Dr. K. Fehler 3. decembra u sedištu kompanije Dynaflow u Rejkjaviku. Ostale validacije su obavili Dr. K. Fehler i M. S. Probleme u Nacionalnj laboratoriji za testiranje i merenje.

Validirani su sledeći zahtevi: - Posebni zahtevi za ugrađeni softver za namensko merilo (tip P) - Dodatak L: Dugoročno skladištenje podataka koji podležu zakonskoj kontroli

Kontrolna lista za izbor konfiguracije nalazi se u aneksu 1 ovog izveštaja.

Na ovaj instrument se primenjuje klasa rizika C.

Primenjeni si sledeći metodi validacije:

- Identifikacija softvera

- Kompletnost dokumentacije

- Pregled priručnika za upotrebu

- Funkcionalno testiranje

- Pregled izrade softvera

- Pregled softverske dokumentacije

- Analiza protoka podataka

- Simulacija ulaznih signala

Strana 2 / 3


103

Rezultat

Sledeći zahtevi iz WELMEC Vodiča za softver 7.2 su validirani bez pronađenih grešaka:

- P1, P2, P3, P5, P6, P7 (zahtev P4 se smatra neprimenjivim.)

- L1, L2, L3, L4, L5, L6, L7 Kontrolne liste za P-zahteve nalaze se u aneksu 2.1 ovog izveštaja. Kontrolne liste za L-zahteve nalaze se u aneksu 2.2 ovog izveštaja. Pronađene su dve komande koje nisu prvobitno opisane u priručniku za operatera. Dve komande su unešene u priručnik za operatera od 10. decembra 2003.

Greška u softveru, koja je mesec februar ograničila na 28 dana i u prestupnoj godini, pronađena je u softverskom paketu V1.2b. Ispravljena je u V1.2c.

Softver kompanije Dynaflow DF100 V1.2c ispunjava osnovne zahteve Direktive o merilima.

Rezultat se primenjuje samo na testirani proizvod.

Nacionalna softverska laboratorija za testiranje i merenje

Dr. K.E.I.N. Fehler M. S.A.N.S Probleme

Tehnički menadžer Tehnički referent

Datum: 23. decembar 2003.

Strana 3 / 3


104

12.2 Aneks 1 izveštaja o testiranju: Kontrolne liste kao podrška izboru odgovarajućih skupova zahteva Prva kontrolna lista pomaže korisniku da odluči koja osnovna konfiguracija P ili U važi za instrument koji se testira.

Odluka o tipu instrumenta

(P)

Primedbe

1 Da li je celokupan aplikativni softver konstruisan za merenje?

(D)

2 Ako postoji softver opšte namene, da li je dostupan ili vidljiv korisniku?

(N)

3 Da li je korisnik sprečen da pristupi operativnom sistemu, ako može da se prebaci na opreativni režim rada koji ne podleže zakonskoj kontroli?

(D)

4 Da li su implementirani program i softversko okruženje nepromenjivi(osim ispravki)?

(D)

5 Da li postoje bilo kakva druga sredstva za programiranje?

(N)

Popunite prazna polja na odgovarajući način

Samo ako se svi odgovori na 5 pitanja mogu dati kao u koloni (P), onda se primenjuju zahtevi iz dela P (poglavlje 4). U svim ostalim slučajevima moraju da se primene zahtevi iz dela U (poglavlje 5).

Druga kontrolna lista pomaže pri donošenju odluke koja IT konfiguracija se primenjuje na instrument koji se testira.

Odluka o predviđenim dodacima

Pre

dv.

do

dat

ak

DA

NE

N

ije

pri

men

jivo

Pri

med

be

L Da li uređaj može da skladišti merne podatke na integrisanom skladištu ili na daljinskom ili prenosivom skladištu?

T Da li uređaj ima interfejse za prenos podataka na uređajima koji podležu zakonskoj kontroli ILI uređaj koji prima podatke iz drugog uređaja podleže zakonskoj kontroli?

S Postoje li softverski delovi koji imaju funkcije koje ne podležu zakonskoj kontroli, i da li se želi da se ti softverski delovi promene nakon odobrenja tipa?

D Da li je učitavanje softvera moguće ili poželjno?

Razmotrite predviđeni dodatak u svim pitanjima na koje ste odgovorili sa DA !


105

12.3 Aneks 2 izveštaja o testiranju: Posebne kontrolne liste za odgovarajuće tehničke delove

1) Kontrolna lista osnovnih uslova za tip P instrument

Kontrolna lista za tip P instrument

Zah

tev

Pro

ced

ure

te

stir

anja

Pro

šao

Nij

e p

roša

o

Nij

e p

rim

enjiv

o

Primedbe*

P1 Da li zahtevana dokumentacija proizvođača ispunjava zahtev P1(a-f)?

P2 Da li je identifikacija softvera ostvarena kao što se traži u P2?

P3 Jesu li komande unete putem korisničkog interfejsa onemogućene da nedopustivo utiču na softver i merne podatke koji podležu zakonskoj kontroli?

P4 Da li su komande koje su unete putem neplombiranog intefejsa za komunikaciju instrumenta sprečene da nedopustivo utiču na softver i merne podatke koji podležu zakonskoj kontroli?

P5 Da li su softver i merni podaci koji podležu zakonskoj kontroli zaštićeni od slučajnih ili nenamernih izmena?

P6 Da li je softver koji podleže zakonskoj kontroli zaštičen od neprihvatljive izmene, učitavanja ili zamene hardverske mermorije?

P7 Da li su parametri koji popravljaju karakteristike merila koje podležu zakonskoj kontroli zaštičeni od neovlašćene izmene?

* Pojašnjenja su potrebna ako postoje odstupanja od softverskih zahteva.

2) 2) 2) 2) Kontrolne liste osnovnih zahtevaKontrolne liste osnovnih zahtevaKontrolne liste osnovnih zahtevaKontrolne liste osnovnih zahteva za za za za tiptiptiptip UUUU instrumentinstrumentinstrumentinstrument

Zah

tev

Pro

ced

ure

te

stir

anja

Pro

šao

Nij

e p

roša

o

Nij

e p

rim

enjiv

o

Primedbe*

U1 Da li zahtevana dokumentacija proizvođača ispunjava zahtev U1(a-g)?

U2 Da li je identifikacija softvera ostvarena kao što se traži u U2?

U3 Da li su komande koje su unete preko korisničkog interfejsa onemogućene da nedopustivo utiču na softver i merne podatke koji podležu zakonskoj kontroli?

U4 Da li je sprečeno da komande koje su unešene putem neplombiranog interfejsa instrumenta za komunikaciju, nedopustivo utiču na softver i merne podatke koji podležu zakonskoj kontroli?

U5 Da li su softver i merni podaci koji podležu zakonskoj kontroli zaštićeni od slučajnih ili nenamernih izmena?

U6 Da li su parametri koji podležu zakonskoj kontroli zaštićeni od nedozvoljene izmene?

U7 Jesu li zakonski relevantni parametri obezbeđeni od neovlašćene izmene?

Kontrolna lista za tip U instrument


106

3) Kontrolna lista posebnih zahteva u dodatku L

Kontrolna lista zahteva dodatka L

Zah

tev

Pro

ced

ure

te

stir

anja

Pro

šao

Nij

e p

roša

o

Nij

e p

rim

enji

vo

Primedbe*

L1 Da li zapamćeni merni podaci sadrže sve odgovarajuće informacije potrebne za rekonstrukciju ranijeg merenja?

L2 Jesu li zapamćeni podaci zaštićeni od slučajnih i nenamernih izmena?

L3 Jesu li zapamćeni merni podaci zaštičeni od nenamernih izmena koje su načinjene jednostavnim zajedničkim softverskim alatima (za klasu rizika B i C) ili posebnim sofisticiranim softverskim alatima (za klasu rizika D i E)?

L4 Da li zapamćeni merni podaci mogu autentično da se prate unazad do merenja koje ih je generisalo?

L5 B i C) Da li se ključevi tretiraju kao podaci koji podležu zakonskoj kontroli i čuvaju tajno i štite od opasnosti jednostavnim softverskim

alatima?

D i E) Da li se ključevi i pripadajući podaci tretiraju kao podaci koji podležu zakonskoj kontroli i čuvaju tajno i štite od opasnostisofisticiranim softverskim alatima? Da li su odgovarajuće metode ekvivalentne elektronskom plaćanju koje se koristi? Da li je korisnik u stanju da verifikuje autentičnost javnog ključa?

L6 Da li softver koji se koristi za verifikaciju zapamćenih skupova mernih podataka podešava prikaz ili štampa podatke, proverava da li je bilo izmena na podacima, i izdaje upozorenje ako dođe do izmene? Da li ima otkrivenih sredstva za zaštitu podataka koja su se koristila oštećena?

L7 Da li ima mernih podataka koji se automatski pamte nakon što se merenje završi?

L8 Da li dugoročno skladište ima kapacitet koje je dovoljno za namenjenu svrhu?


U8 Da li se garantuju korišćene metode koje obezbeđuju autentičnost softvera koji podleže zakonskoj kontroli i autentičnost rezultata koji su prikazani?

U9 Da li je softver koji podleže zakonskoj kontroli izrađen tako da ostali softveri neće nedozvoljeno uticati na njega?



107

4) Kontrolna lista posebnih zahteva dodatka T

Kontrolna lista zahteva dodatka T

Zah

tev

Pro

ced

ure

te

stir

anja

Pro

šao

Nij

e p

roša

o

Nij

e p

rim

enjiv

o

Primedbe*

T1 Da li preneseni podaci sadrže sve relevatne informacije koje su neophodne da se prikaže ili nastavi proces merenja rezultata u prijemnom modulu?

T2 Da li su preneseni podaci zaštićeni od slučajnih ili nenamernih izmena?

T3 Da li su podaci koji podležu zakonskoj kontroli zaštičeni od namernih izmena koje su načinjene jednostavnim zajedničkim softverskim

alatima (za klase rizika B i C) ili posebnim sofisticiranim softverskim

alatima (za klase rizika D i E)?

T4 Da li je moguće da program koji prima prenesene relevantne podatke,verifikuje njihovu autentičnost i dodeli merne vrednosti određenommerenju?

T5 B i C) Da li se ključevi tretiraju kao podaci koji podležu zakonskoj kontroli i čuvaju tajno i štite od opasnosti jednostavnim softverskim

alatima?

D i E) Da li se ključevi i pripadajući podaci tretiraju kao podaci koji podležu zakonskoj kontroli i čuvaju tajno i štite od opasnosti sofisticiranim softverskim alatima? Da li su odgovarajuće metode ekvivalentne elektronskom plaćanju koje se koristi? Da li je korisnik u stanju da verifikuje autentičnost javnog ključa?

T6 Da li su podaci, koji su otrkiveni kao oštećeni, zaštićeni od upotrebe?

T7 Da li je osigurano da se na merenje neće nedozvoljeno uticati kašnjenjem prenosa?

T8 Da li je osigurano da se nijedan merni podatak neće izgubiti ako mrežne usluge budu nedostupne?


5) Kontrolne liste posebnih zahteva dodatka S

Kontrolna lista zahteva dodatka S

Zah

tev

Pro

ced

ure

te

stir

anja

Pro

šao

Nij

e p

roša

o

Nij

e p

rim

enjiv

o

Primedbe*

S1 Da li softver koji podleže zakonskoj kontroli sadrži sve zakonski relevantne podatke i parametre?

S2 Da li je osigurano da dodatne informacije, ostvarene softverskim delom koji ne podleže zakonskoj kontroli koje su prikazane na ekranu ili ispisu, neće moći da se zamene sa informacijama koje potiču od dela koji podleže zakonskoj kontroli?

S3 Da li se razmena podataka između softvera koji podleže i koji ne podleže zakonskoj kontroli, obavlja putem zaštitnog softverskog interfejsa koji obuhata kontrolu interakcije i protok podataka?



108

6) Kontrolne liste posebnih zahteva dodatka D

Kontrolna lista zahteva dodatka D

Zah

tev

Pro

ced

ure

te

stir

anja

Pro

šao

Nij

e p

roša

o

Nij

e p

rim

enjiv

o

Primedbe*

D1 Da li su preuzimanje i naknadna instalacija softvera automatski? Da li je okruženju po završetku obezbeđen odgovarajući nivo zaštite softvera?

D2 Da li su metode koje su korišćene za garantovanje preuzetog softvera autentične, i da li pokazuju da je notifikovano telo odobrilo preuzeti softver?

D3 Da li metode koje su korišćene za garantovanje preuzetog softvera nisu nedozvoljeno menjane tokom preuzimanja?

D4 Da li se odgovarajućim tehničkim sredstvima garantuje da preuzimanja softvera koji podležu zakonskoj kontroli mogu adekvatno da se prate instrumentom za naknadnu kontrolu?


12.4 Informacije koje treba da se uključe u sertifikat o ispitivanju tipa Dok je celokupan izveštaj o ispitivanju zapravo dokumentacija predmeta koji se ispituje, za sertifikat o ispitivanju tipa (TEC) je potrebno sprovesti validaciju i rezultate, i određen izbor informacija koje se nalaze u izveštaju o ispitivanju. Ovo se odnosi na sledeće informacije, koje na odgovarajući način treba uključiti u TEC:

• Upućivanje na dokumentaciju koja je dostavljena za ispitivanje tipa,

• Identifikacija i opis elektronskih (hardverskih) delova (podsklopovi, moduli) koji su bitni za softver/IT funkciju merila,

• Pregled softverskog okruženja, koje je potrebno za rad softvera,

• Pregled softverskih modula koji podležu zakonskoj kontroli (uključujući razdvajanje softvera, ako je implementirano),

• Pregled i identifikacija hardvera i softverskih (ako je prikladno) interfejsa koji su važni za softver/IT funkciju merila (uključujući infracrveno, Bluetooth, bežični LAN, ...),

• Identifikacija i opis lokacija softverskih delova u merilima (odnosno EPROM, procesor, čvrsti disk...) koji treba da se plombira ili obezbedi,

• Uputstva za proveru identifikacije softvera (za metrološki nadzor),

• U slučaju elektronskog plombiranja: uputstvo za inspekciju hronoloških zapisa revizije.


109

13 Unakrsno upućivanje za softverske uslove MID direktive na članove i anekse MID direktive

(Odgovarajuća MID verzija: Direktiva 2004/22/EC, 31. mart 2004.)

13.1 Navedeni softverski zahtevi, upućivanje na MID direktivu

Uslov MID Ne Naziv Član/Aneks br.

(AI = Aneks I) Naziv

Osnovni vodič P

P1 Dokumentacija proizvođača AI-9.3

AI-12 Član 10

Informacije koje potpadaju pod i idu uz instrument Procena o usaglašenosti Tehnička dokumentacija

P2 Identifikacija softvera AI-7.6 AI-8.3

Podesnost

Zaštita od ošećenja P3 Uticaj putem korisničkog

interfejsa AI-7.1 Podesnost

P4 Uticaj putem interfejsa za komunikaciju

AI-7.1 AI-8.1

Podesnost

Zaštita od ošećenja P5 Zaštita od slučajnih i

nenamernih izmena AI-7.1, AI-7.2 AI-8.4

Podesnost

Zaštita od ošećenja P6 Zaštita od nenamernih izmena AI-7.1

AI-8.2, AI-8.3, AI-8.4

Podesnost2

Zaštita od ošećenja P7 Zaštita parametra AI-7.1

AI-8.2, AI-8.3, AI-8.4 Podesnost

Zaštita od ošećenja Osnovni vodič U

U1 Dokumentacija proizvođača AI-9.3

AI-12 Član 10

Informacije koje potpadaju pod i idu uz instrument Procena o usaglašenosti Tehnička dokumentacija

U2 Identifikacija softvera AI-7.6 AI-8.3

Podesnost

Zaštita od ošećenja U3 Uticaj putem korisničkog

interfejsa AI-7.1 Podesnost

U4 Uticaj putem interfejsa za

komunikaciju AI-7.1 AI-8.1

Podesnost

Zaštita od ošećenja U5 Zaštita od slučajnih i

nenamernih izmena AI-7.1, AI-7.2 AI-8.4

Podesnost

Zaštita od ošećenja U6 Zaštita od nenamernih izmena AI-7.1

AI-8.2, AI-8.3, AI-8.4

Podesnost

Zaštita od ošećenja U7 Zaštita parametra AI-7.1

AI-8.2, AI-8.3, AI-8.4

Podesnost

Zaštita od ošećenja U8 Autentičnost softvera i

prikazivanje rezultata AI-7.1, AI-7.2, AI-7.6 AI-8.3 AI-10.2, AI-10.3, AI-10.4

Podesnost

Zaštita od ošećenja Naznaka rezultata

U9 Uticaj drugog softvera AI-7.6 Podesnost

Dodatak L

L1 Kompletnost zapamćenih podataka

AI-7.1 AI-8.4 AI-10.2 Podesnost


2 Napomena: Što se tiče sadržaja u Stavu 7.1 Aneks I MID direktive, nije stvar „Podesnosti“ već „Zaštite od oštećenja“ (stav 8)


110

L2 Zaštita od slučajnih i nenamernih izmena

AI-7.1, AI-7.2 AI-8.4

Podesnost

Zaštita od ošećenja L3 Integritet podataka AI-7.1 AI-8.4 Podesnost

Zaštita od ošećenja L4 Authentičnost zapamćenih

podataka AI-7.1 AI-8.4 AI-10.2

Podesnost


L5 Poverljivost ključeva AI-7.1 AI-8.4

Podesnost

Zaštita od ošećenja L6 Povraćaj zapamćenih podataka AI-7.2

AI-10.1, AI-10.2, AI-10.3, AI-10.4

Podesnost Naznaka rezultata

L7 Automatsko pamćenje AI-7.1 AI-8.4

Podesnost

Zaštita od ošećenja L8 Kapacitet skladišta i kontinuitet AI-7.1 Podesnost

Lx Sve iz dodatka L AI-11.1 Dalja obrada podataka radi zaključivanja transakcije prometa

Dodatak T

T1 Kompletnost prenesenih podataka

AI-7.1 AI-8.4

Podesnost

Zaštita od ošećenja T2 Zaštita od slučajne izmene AI-7.1, AI-7.2

AI-8.4 Podesnost

Zaštita od ošećenja T3 Integritet podataka AI-7.1

AI-8.4 Podesnost

Zaštita od ošećenja T4 Authentičnost prenesenih

podataka AI-7.1 AI-8.4

Podesnost

Zaštita od ošećenja T5 Poverljivost ključeva AI-7.1

AI-8.4 Podesnost

Zaštita od ošećenja T6 Rukovanje oštećenim podacima AI-7.1

AI-8.4 Podesnost

Zaštita od ošećenja T7 Kašnjenje prenosa AI-7.1

AI-8.4 Podesnost

Zaštita od ošećenja T8 Dostupnost usluga prenosa AI-7.1

AI-8.4 Podesnost

Zaštita od ošećenja

Dodatak S

S1 Realizacija razdvajanja softvera AI-7.6, AI-10.1 Podesnost Naznaka rezultata

S2 Mešovita indikacija AI-7.1, AI-7.2, AI-7.6 AI-10.2

Podesnost Naznaka rezultata

S3 Zaštitni interfejs softvera AI-7.6 Podesnost

Dodatak D

D1 Mehanizam za preuzimanje AI-8.2, AI-8.4 Zaštita od ošećenja D2 Autentičnost preuzetog softvera AI-7.6

AI-8.3, AI-8.4 AI-12

Podesnost Zaštita od ošećenja Procena usaglašenosti

D3 Integritet preuzetog softvera AI-7.1, AI-8.4 Podesnost Zaštita od ošećenja

D4 Sledljivost preuzimanja softvera koji podleže zakonskoj kontroli

AI-7.1, AI-7.6 AI-8.2, AI-8.3 AI-12

Podesnost Zaštita od ošećenja Procena usaglašenosti

Dodatak I (softverski zahtevi specifični za instrument)


111

I1-1, I2-2, I3-1, I4-1

Otkrivanje greške AI-6 MI-001-7.1, MI-002-3.1, MI-003-4.3.1, MI-004-4

Pouzdanost Posebni zahtevi za komunalna merila

I1-2, I2-2, I3-2, I4-2

Objekti za rezervno kopiranje AI-6 MI-001-7.1, MI-002-3.1, MI-003-4.3.1, MI-004-4


I1-3, I2-3, I3-3, I4-3

Mogućnost podizanja sistema i vraćanje u prethodno stanje

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


I1-4, I2-4, I3-4, I4-4

Interna rezolucija MI-002-5.3, MI-003-5.2 Posebni zahtevi za komunalna merila

I1-5, I2-5, I3-5, I4-5

Sprečavanje resetovanja kumulativnih mernih vrednosti

AI-8.5 Zaštita od ošećenja

I1-6, I2-6, I3-6, I4-6

Naznaka za korisnika AI-7.2 AI-10.5 Podesnost Naznaka rezultata

I2-7 Acc. Sol. za praćenje trajanja baterije

MI-002-5.2 Posebni uslovi za gasomere

I2-8 Acc. Sol. za praćenje konvertera zapremine gasa

MI-002-9.1 Posebni uslovi za gasomere

I2-9 Element testiranja MI-002-5.5 Posebni uslovi za gasomere

I6-1 Otkrivanje greške MI-006-IV, MI-006-V Automatske vage sa sabiranjem diskontinuiranih rezultata merenja i automatske vage sa sabiranjem kontinuiranih rezultata merenja

I6-2 Objekti za rezervno kopiranje MI-006-IV, MI-006-V Automatske vage sa sabiranjem diskontinuiranih rezultata merenja i automatske vage sa sabiranjem kontinuiranih rezultata merenja


112

13.2 Tumačenje članova i aneksa iz MID direktive sa softerskim zahtevima iz MID direktive

MID Vodič za softver

Član/Anek br.

(AI = Aneks I) Značenje Komentar Zahtev br.

Deo člana

1, 2, 3 Nema posebnih softverskih primena

4(b) Definicije, ugovori, Razvrstavanje podsklopova

Prenos podataka koji podležu zakonskoj kontroli... Osnovni vodiči koji se primenjuju na podsklopove

T

P, U

5 do 9 Nema posebnih softverskih primena

10 Tehnička dokumentacija Dokumentacija dizajna, proizvodnje i funkcionisanja. Omogućiti procenu o usaglašenosti. Opšti opis instrumenta. Opis eletronskih uređaja sa crtežima, dijagramima protoka logike, opšte informacije o softveru. Lokacija plombi i oznake. Uslovi za kompatibilnost sa interfejsima i podsklopovima.

P1, U1

11 do 27 Nema posebnih softverskih primena

Aneks I

AI-1 do AI-5 Nema posebnih softverskih primena

AI-6 Pouzdanost Otkrivanje greške, rezervno kopiranje, vraćanje u prethodno stanje, ponovno pokretanje

11- 1 do I1-3, 12- 1 do I2-3, 13- 1 do I3-3, 14- 1 do I4-3, I6-1 do I6-2

AI-7 Podesnost Nema funkcija kojima se olakšava zloupotreba; minimalne mogućnosti za nenamernu zloupotrebu.

P3 - P7, U3 - U8, L1 - L5, L7, L8 T1 - T8, S2, D3, D4

AI-8 Zaštita od oštećenja

AI-8.1 Nema uticaja povezivanjem ostalih uređaja. P4, U4

AI-8.2 Obezbeđivanje; dokaz o intervenciji P6, P7, U6, U7, D1, D4

AI-8.3 Identifikacija softvera; dokaz o intervenciji P2, P6, P7, U2, U6, U7, U8, D2, D4

AI-8.4 Zaštita zapamćenih ili prenesenih podataka P5 - P7, U5 - U7, L1 - L5, T1 - T8 D1 - D3

AI-8.5 Nema resetovanja kumulativnih registara I1-5, I2-5, I3-5, I4-5

AI-9 Informacije koje potpadaju pod i idu uz instrument.

AI-9.1 Kapacitete merenja

(ostatak stavki ne odgovara softveru)

L8

AI-9.2 Nema posebnih softverskih primena


113

AI-9.3 Uputstva za instalaciju, ..., uslovi za usklađenost sa interfejsom, podsklopovi ili merila.

P1, U1

AI-9.4 do AI-9.8

Nema posebnih softverskih primena

AI-10 Naznaka rezultata

AI-10.1 Naznaka putem ekrana ili čvrstog diska. U8, L6, S2

AI-10.2 Značaj rezultata, nema zabune sa dodatnim naznakama.

U8, L1, L4, L6, S2

AI-10.3 Štampanje ili zapis koji su lako čitljivi i koji ne mogu da se izbrišu.

U8, L6, S2

AI-10.4 Kod direktne prodaje: prikazivanje rezultata obema stranama.

U8, S2

AI-10.5 Kod komunalnih merila: ekran za korisnike. I1-6,I2-6, I3-6, I4-6

AI-11 Dalja obrada podataka radi zaključivanja transakcije prometa

AI-11.1 Beleženje mernih rezultata trajnim metodama. L1 - L8

AI-11.2 Trajni dokaz mernog rezultata i informacije za identifikaciju transakcije.

L1, L6

AI-12 Procena usaglašenosti Spremna evaluacija usaglašenosti u skladu sa zahtevima Direktive.

P1, P2, U1, U2, D2, D4

Aneksi od A1 do H1

A1 do H1 Nema zahteva za funkcije instrumenata

Aneks MI-001

MI-001-1 do MI-001-6


MI-001-7.1.1, MI-001-7.1.2

Elektromagnetni imunitet Otkrivanje greške Objekti za rezervno kopiranje Mogućnost podizanja sistema i vraćanje u prethodno stanje

I1-1 do I1-3

MI-001-7.1.3 do MI-001-9


Aneks MI-002

MI-002-1 do MI-002-2


MI-002-3.1 Elektromagnetni imunitet Otkrivanje greške Objekti za rezervno kopiranje Mogućnost podizanja sistema i vraćanje u prethodno stanje

I2-1 do I2-3

MI-002-3.1.3 do MI-002-5.1

Nema specifičnih softverskih prikladnosti

MI-002-5.2 Podesnost Prihvatljivo rešenje za praćenje trajanja baterije

I2-7

MI-002-5.3 Podesnost Inerna rezolucvija I2-4 MI-002-5.4 do

MI-002-8


MI-002-5.5 Podesnost Element testiranja I2-9 MI-002-5.6 do

MI-002-8


MI-002-9.1 Uređaji za konverziju zapremine Podesnost

Prihvatljivo rešenje za praćenje konvertera zapremine gasa

I2-8


114

MI-002-9.2 do MI-002-10


Aneks MI-003

MI-003-1 to MI-003-4.2


MI-003-4.3 Dozvoljeni efekat prelaznih elektromagnetnih fenomena

Otkrivanje greške Objekti za rezervno kopiranje Mogućnost podizanja sistema i vraćanje u prethodno stanje

I3-1 do I3-3

MI-003-5.1 Nema posebnih softverskih primena

MI-003-5.2 Podesnost Interna rezolucija I3-4 MI-003-5.3 do

MI-003-7


Aneks MI-004

MI-004-1 do MI-004-4.1


MI-004-4.2 Dozvoljeni uticaji elektromagnetnih smetnji

Otkrivanje greške Objekti za rezervno kopiranje Mogućnost podizanja sistema i vraćanje u prethodno stanje

I4-1 do I4-3

MI-004-4.3 do MI-004-7


Aneks MI-005

Aneks MI-006

MI-006-IV, MI-006-V

Automatske vage sa sabiranjem diskontinuiranih rezultata merenja i automatske vage sa sabiranjem kontinuiranih rezultata merenja

Otkrivanje greške Objekti za rezervno kopiranje

I6-1 do I6-2

Aneks MI-007

Aneks MI-008

Aneks MI-009

Aneks MI-010


115

14 Reference i literatura

[1] Direktiva 2004/22/EC Evropskog parlamenta i saveta od 31. marta 2004. godine o merilima. Službeni list Evropske unije L 135/1, 30.4.2004.

[2] Vodič za softverske zahteve i validaciju, verzija 1.00, 29. oktobar 2004., Mreža evropskog razvoja „MID-Softver“, broj ugovora G7RT-CT-2001- 05064, 2004.

[3] Softverski zahtevi u skladu sa Direktivom za merila, WEMEC 7.1, 2. izdanje, 2005.

15 Istorija izmena

Broj Datum Značajne izmene

1 Maj 2005. Vodič prvi put objavljen.

2 April 2007. Dodatak i proširenje zahteva u odeljku 2

Uvodne izmene u odeljcima 4.1 i 5.1

Izmena pojašnjenja za identifikaciju softvera u oodeljku 4.2, zahtev P2 i odeljku 5.2, zahtev U2.

Izmena u zahtevu L8, Posebna napomena 1.

Dodavanje objašnjena u zahtevu S1, Posebna napomena 1.

Zamena zahteva 5 sa napomenom.

Promena klase rizika za merne sisteme za tečnosti koje nisu voda.

Promena klase rizika za merila. Razne manje uređivačke izmene u

dokumentu. Dodatak ovoj tabeli izmena.

3 Mart 2008. Dodavanje izuzetaka za naznaku identifikacije softvera: novi zahtevi I1-5, I2-9, I3-6, I4-5 i I5-1.

4 Maj 2009. Ograničenje oblasti primene preuzetog softvera, razjašnjenje identifikacionih uslova u vezi sa preuzimanjem softvera Revizija zahteva P2 i U2: Brisanje nevažećih delova teksta.

5 Maj 2011. Revizija poglavlja 5 (deo U): Napredovanje u pogledu operativnih sistema

Zamena termina „komponenta“ sa ostalim odgovarajućim terminima u vodiču radi izbegavanja nesprazuma

Dodatak zahtevu D1 u odeljku 9.2, uvođenjem podešavanja koje mora da se zaštititi mehanizmu preuzimanja

Preciziranje zapomena u zahtevima P2 i U2 u odeljcima 4.2 i 5.2, odnosno u vezi sa identifikacijom softvera

Proširenje primera prihvatljivih rešenja u zahtevu L2 (odeljak 6.2) i u zahtevu U8 (odeljak 5.2)

Tabela 15-1: istorija izmena


116

16 Indeks

hronološki zapis revizije, 7, 22, 31, 60 autentifikacija, 7, 38, 47, 58, 113 autentičnost, 9, 32, 33, 38, 39, 40, 47, 56, 58, 59, 109, 110, 112, 113 osnovna konfiguracija, 7, 8, 10, 12, 107 namenski, 7, 12, 15, 34, 35, 51, 55 sertifikacija ključa, 9 kontrolna lista, 13, 107, 108, 109, 110, 111 kongtrolni zbir, 8, 17, 20, 25, 29, 37, 45 kolo, 22 komanda, 16, 17, 18, 19, 24, 25, 26, 28, 41, 54 Intefejs za komunikaciju, 19, 108 poverljivost, 39, 48, 113 unakrsno upućivanje, 112 domen podataka, 54 protok podataka, 18, 20, 27, 28, 52, 54, 110 dimenzionalno merilo, 98 direktno poverenje, 39, 48 dokumentacija, 13, 16, 24 brojila električne energije, 76, 77 ugrađeno, 7, 15, 34, 62 sistem za evidenciju događaja, 7, 22, 60 analizator izduvnih gasova, 99 otkrivanje greške, 20, 62, 114, 115, 116, 117 gasomer, 69, 114 hash algoritam, 9, 25, 37, 46 merila toplotne energije, 82 identifikacija, 8, 16, 17, 22, 24, 25, 33, 35, 38, 40, 44, 47, 52, 58, 60, 108 indikacija, 53, 92, 113 integritet, 7, 9, 37, 38, 40, 46, 47, 56, 58, 59, 112, 113 IT konfiguracija, 7, 10, 12, 107 aktivacija ključa, 18, 26 zakonska kontrola, 8 koji podleže zakonskoj kontroli, 7, 8, 16, 21, 29, 33, 51, 54, 55, 63 materijalizovane mere, 97 memorija, 21, 22, 34, 62, 108 MID, 6, 8, 12, 61 mreža, 7, 8, 16, 23, 24, 34, 43, 47, 50, 110 zatvoreno, 7, 8, 23, 43, 46, 47, 48, 55, 62

otovoreno, 7, 8, 23, 43, 46, 55, 62 notifikovano telo (NB), 13, 42 operativni sistem, 15, 23, 24, 26, 29, 30, 34, 51, 62, 107 parametar, 7, 8, 22, 100, 112 specifičan za tip, 8 zaštitni interfejs, 52, 53, 54, 56, 110, 113 struktrura javnog ključa, 9 klasa rizika, 8, 9, 12, 61, 63, 100, 101 bezbedan, 7, 21, 22, 30, 31, 57, 58, 108 algoritam potpisa, 9, 37, 46 elektronski, 9, 37, 46, 58 ključ, 9 preuzimanje softvera, 7, 8, 10, 15, 19, 21, 27, 52, 56, 60 razdvajanje softvera, 8, 10, 12, 15, 33, 51, 52, 55, 113 nizak nivo, 52 sofisticirani alati, 37, 39, 46, 48, 100, 110 posebni zahtevi, 12, 34, 87, 94, 97, 98, 99, 109, 110, 111 prevara, 32 integrisano skladište, 7, 15, 34, 37, 107 dugoročno, 7, 8, 10, 34, 42, 109 podsklop, 8 podrutina, 54 taksimetar, 94 TEC, 17, 25, 31, 33, 56, 111 izveštaj o testiranju, 103 sledljivost, 60 prenos, 7, 8, 10, 12, 15, 19, 42, 43, 44,45, 46, 47, 49, 50, 52, 107, 109, 113, 114 centar za poverenje, 9, 39, 48 tip P, 7, 10, 12, 15, 16, 23, 34, 55, 62, 96, 98, 99, 108 tip U, 8, 12, 15, 34, 96, 98, 99, 108 korisnički interfejs, 8, 15, 16, 18, 23, 24, 26, 27, 34, 62, 108, 112 validacija, 13 vodomer, 64 merilo, 41, 61, 88

5. izdanje WELMECWELMEC 7.2 5. izdanje WELMEC Evropska saradnja u oblasti zakonske metrologije...

Documents

Transcript of 5. izdanje WELMECWELMEC 7.2 5. izdanje WELMEC Evropska saradnja u oblasti zakonske metrologije...