Regeling houdende regels voor de specificaties en de typegoedkeuring van boordcomputers taxi (Regeling specificaties en typegoedkeuring boordcomputer taxi)

12 juli 2010

Nr. CEND/HDJZ-2010/954 sector S&W

De Minister van Verkeer en Waterstaat,

Gelet op de artikelen artikel 22, eerste en derde lid, 23, derde lid, en 24 van de Wegenverkeerswet 1994;

Besluit:

§ 1 Begripsbepalingen

Artikel 1

In deze regeling wordt verstaan onder:

activering:

handeling waarmee de boordcomputer aan de auto wordt gekoppeld, volledig operationeel wordt en alle functies kan uitvoeren;

authenticiteit:

eigenschap dat informatie afkomstig is van een persoon of inrichting, waarvan de identiteit kan worden geverifieerd;

auto:

auto waarmee taxivervoer wordt verricht;

bedrijfsvergrendeling:

vergrendeling waarmee de in de boordcomputer opgeslagen gegevens herleidbaar zijn naar de vervoerder waarvoor deze opgeslagen zijn;

beproeving:

test, of serie tests, die door de boordcomputer kan worden uitgevoerd om fouten te ontdekken en die automatisch of door de gebruiker van de boordcomputer kan worden geïnitieerd;

beschikbaarheid:

mate waarin de boordcomputer of componenten van de boordcomputer zonder belemmering toegankelijk zijn voor geautoriseerde gebruikers;

bestuurder:

bestuurder die taxivervoer verricht;

beveiligingsgegevens:

specifieke gegevens ter ondersteuning van de beveiligingsfuncties;

bewegingsgegevens:

gegevens betreffende snelheid en afgelegde afstand van de auto die door de bewegingsopnemer of de positiebepalingssensor aan de boordcomputer worden aangeleverd;

bewegingsopnemer:

instrument, of een deel ervan, gekoppeld aan de boordcomputer dat een signaal in de vorm van een impuls afgeeft over de beweging van de auto op basis waarvan de boordcomputer de afgelegde afstand van de auto kan bepalen;

boordcomputer:

apparaat ten behoeve van de registratie van de gegevens, bedoeld in artikel 79, derde, vierde en vijfde lid, van het Besluit personenvervoer 2000;

boordcomputerkaart:

een geheugenkaart als bedoeld in artikel 1, onderdeel h, van het Besluit personenvervoer 2000;

CEN:

door het Comité Européen de Normalisation uitgegeven norm;

chauffeurskaart:

kaart als bedoeld in artikel 1, onderdeel i, van het Besluit personenvervoer 2000;

constante van de boordcomputer:

getal dat de waarde aangeeft van het ingangssignaal van de bewegingsopnemer dat nodig is ter aanwijzing en registratie van een afgelegde afstand van één kilometer, uitgedrukt in impulsen per kilometer;

coördinaten:

een aanduiding om de positie van de auto op de aarde vast te leggen ten opzichte van het World Geodetic System 1984 coördinatenstelsel;

elektronische handtekening:

een handtekening die voldoet aan de eisen, bedoeld in artikel 15a, eerste tot en met vijfde lid, van Boek 3 van het Burgerlijk Wetboek;

ETSI:

door de European Telecommunications Standards Institute uitgegeven norm;

fabrikant:

persoon of instantie die verantwoordelijk is voor alle aspecten van de goedkeuringsprocedure, bedoeld in artikel 22, eerste lid, van de Wegenverkeerswet 1994;

FIPS PUB:

een Federal Information Processing Standards Publication;

geaccrediteerde Common Criteria testinstelling:

een testinstelling die beschikt over een accreditatie op grond van de Common Criteria for Information Technology Evaluation delen 1, 2 en 3, versie 3.1, in combinatie met de Common Methodology for Information Technology Evaluation versie 3.1.;

gebruikersgegevens:

door de boordcomputer geregistreerde en opgeslagen gegevens, anders dan beveiligingsgegevens en systeemgegevens;

geheugen:

niet-volatiel elektronisch geheugenmedium dat in de boordcomputer is ingebouwd;

HDOP-waarde:

Horizontal Dilution Of Precision waarde;

IETF:

door de Internet Engineering Taskforce uitgegeven norm;

inspectiekaart:

aan de met het toezicht op de naleving belaste persoon afgegeven boordcomputerkaart die de desbetreffende persoon identificeert en waarmee de controlemodus van de boordcomputer kan worden geactiveerd;

ISO:

door de International Organisation for Standardisation uitgegeven norm;

ISO-IEC:

door de International Organisation for Standardisation en de International Electrotechnical Commission uitgegeven norm;

kaartsessie:

periode tussen het ingeven van de boordcomputerkaart en het wegschrijven van de afsluitende gegevens op de boordcomputerkaart door de boordcomputer;

keuringskaart:

kaart als bedoeld in artikel 1, onderdeel j, van het Besluit personenvervoer 2000;

kilometerstand:

de door de boordcomputer getotaliseerde afgelegde afstand met de auto, zowel bij vooruitrijden als bij achteruitrijden, overeenkomend met de totale door de auto afgelegde afstand;

minister:

minister van Verkeer en Waterstaat;

NEN:

door de Stichting Nederlands Normalisatie-instituut uitgegeven norm;

NEN-EN:

door de European Committee for Electrotechnical Standardisation uitgegeven norm die door de Stichting Nederlands Normalisatie-instituut is aanvaard als Nederlandse norm;

NEN-ISO:

door de International Organisation for Standardisation uitgegeven norm die door de Stichting Nederlands Normalisatie-instituut is aanvaard als Nederlandse norm;

ondernemerskaart:

door de minister aan een vervoerder afgegeven boordcomputerkaart die de desbetreffende vervoerder identificeert en waarmee de bedrijfsmodus van de boordcomputer kan worden geactiveerd;

ongeldige boordcomputerkaart:

ingetrokken boordcomputerkaart, defecte boordcomputerkaart, of een boordcomputerkaart waarvan de geldigheidsduur nog niet is begonnen of reeds is verstreken;

overbrengen:

kopiëren van de gegevens, of een gedeelte daarvan, en het kopiëren van de bijbehorende elektronische handtekening die in het geheugen van de boordcomputer of op de chauffeurskaart zijn opgeslagen;

plaatselijke tijd:

UTC gecorrigeerd met een in te geven aantal uren voor de tijdzone en een automatische correctie voor de zomertijd;

positiebepalingssensor:

instrument, of een deel ervan, gekoppeld aan de boordcomputer dat een signaal afgeeft aan de boordcomputer over de locatie van de auto op basis van verkregen informatie van een satelliet positiebepalingsysteem;

registreren:

in het geheugen van de boordcomputer vastleggen van gegevens en gebeurtenissen;

richtlijn 2007/46/EG:

richtlijn nr. 2007/46/EG van het Europees Parlement en de Raad van de Europese Unie van 5 september 2007 tot vaststelling van een kader voor de goedkeuring van motorvoertuigen en aanhangwagens daarvan en van systemen, onderdelen en technische eenheden die voor dergelijke voertuigen zijn bestemd (PbEU L 263);

ritadministratie:

gegevens, bedoeld in artikel 79, derde en vierde lid, van het Besluit personenvervoer 2000;

sensor:

eenheid die onderdeel uitmaakt van de boordcomputer of rechtstreeks gekoppeld is aan de boordcomputer en die informatie automatisch aanlevert aan de boordcomputer;

systeemgegevens:

specifieke gegevens ter ondersteuning of noodzakelijk voor het functioneren van de boordcomputer of voor identificatie en instellingen van de boordcomputerfuncties;

systeemkaart:

door de minister afgegeven geheugenkaart met chip die de boordcomputer in staat stelt een elektronische handtekening te plaatsen;

UTC:

Universal Time Coordinated;

verplaatsingsopnemer:

instrument, onderdeel uitmakende van de boordcomputer dat de boordcomputer in staat stelt autonoom een verplaatsing van de auto waar te nemen;

vervoerder:

vervoerder als bedoeld in artikel 1, onderdeel k, van de Wet personenvervoer 2000 en werkgever als bedoeld in artikel 1:1, eerste lid, onderdeel a, van de Arbeidstijdenwet, die taxivervoer verricht.

§ 2 Specificaties van de boordcomputer

§ 2.1 De onderdelen van de boordcomputer

Artikel 2

• 1. De boordcomputer bestaat uit ten minste:

  • a. een verwerkingseenheid;

  • b. een geheugen;

  • c. een tijdklok;

  • d. een ISO 7816 kaartinterface;

  • e. een systeemkaart, verzegeld in een ISO 7810 ID-000 kaartinterface;

  • f. een positiebepalingssensor of een interface voor de positiebepalingssensor;

  • g. een verplaatsingsopnemer, een interface voor de bewegingsopnemer;

  • h. een gegevensoverbrengingsinterface als beschreven in bijlage 2;

  • i. een interface voor de taxameter als beschreven in bijlage 3;

  • j. een leesvenster;

  • k. voorzieningen voor de invoer van gebruikersgegevens.

• 2. De boordcomputer kan door middel van additionele verbindingen aan andere inrichtingen worden gekoppeld, of daarmee geïntegreerd worden.

• 3. Een verbinding of integratie met de boordcomputer, als bedoeld in het tweede lid, leidt er niet toe dat de boordcomputer niet langer voldoet aan deze regeling.

• 4. De boordcomputer voldoet aan de bijlagen 1, 2 en 3 bij deze regeling.

Artikel 3

• 1. De boordcomputer beschikt over een interne autonome tijdklok. Deze is voortdurend operationeel en levert de UTC, met een maximale onnauwkeurigheid van tachtig delen per miljoen.

• 2. De UTC wordt gebruikt voor datering in de boordcomputer.

• 3. Indien ingeschakeld, controleert en corrigeert de boordcomputer ten minste eenmaal per uur automatisch de eigen UTC met behulp van een extern signaal, waarbij de eerste controle binnen vijf minuten na inschakelen plaatsvindt.

• 4. De resolutie van de tijdklok is één seconde of nauwkeuriger.

• 5. De boordcomputer hanteert ISO-8601 voor de numerieke presentatie van datum en tijd.

• 6. Om de plaatselijke tijd zichtbaar te maken kan in de activerings- en keuringsmodus met stappen van een half uur het verschil worden ingegeven ten opzichte van de UTC.

• 7. Bij een externe stroomonderbreking van minder dan twaalf maanden blijft de interne autonome tijdklok functioneren.

Artikel 4

• 1. De boordcomputer heeft vier werkingsmodi:

  • a. operationele modus;

  • b. controlemodus;

  • c. activerings- en keuringsmodus;

  • d. bedrijfsmodus.

• 2. De operationele modus, bedoeld in het eerste lid, onderdeel a, heeft drie werkingsniveaus:

  • a. basis;

  • b. arbeidstijd;

  • c. taxivervoer.

• 3. Het werkingsniveau basis is tevens een geïntegreerd onderdeel van de controlemodus, activerings- en keuringsmodus, en de bedrijfsmodus.

• 4. De boordcomputer wisselt naar de volgende werkingsmodus afhankelijk van het type boordcomputerkaart dat in de kaartinterface is ingebracht en koppelt hier een gebruikersgroep aan overeenkomstig de volgende tabel:

  Type boordcomputerkaart	Werkingsmodus	Gebruikersgroep
  Geen	Operationele modus: Basis	ONBEKEND
  Chauffeurskaart	Operationele modus: Arbeidstijd	BESTUURDER
  Inspectiekaart	Controlemodus	TOEZICHTHOUDER
  Keuringskaart	Activerings- en keuringsmodus	WERKPLAATS
  Ondernemerskaart	Bedrijfsmodus	VERVOERDER

• 5. In afwijking van de tabel, bedoeld in het vierde lid, leidt het invoeren van een inspectiekaart tijdens de deactivering, bedoeld in artikel 23, niet tot het automatisch selecteren van de controlemodus.

• 6. De boordcomputer wisselt na een handmatig verzoek van de bestuurder daartoe tussen de werkingsniveaus van de operationele modus. Het werkingsniveau basis is daarbij altijd ingeschakeld.

• 7. Indien het werkingsniveau taxivervoer is ingeschakeld, is tevens het werkingsniveau arbeidstijd ingeschakeld.

• 8. Indien er geen chauffeurskaart aanwezig is stelt de boordcomputer de bestuurder in staat om bij het inschakelen van het werkingsniveau arbeidstijd handmatig het burgerservicenummer, bedoeld in de Wet algemene bepalingen burgerservicenummer, invoeren.

• 9. De boordcomputer gebruikt de werkingsmodi om de voor die modi geldende toegangsregels voor toegangsrechten tot functies, objecten en gegevens toe te passen.

• 10. Indien in de operationele modus het werkingsniveau arbeidstijd of taxivoer actief is, leidt het invoeren van de inspectiekaart tot het pauzeren van de operationele modus, inclusief de betreffende kaartsessie. Na het afsluiten van de controlemodus wordt de operationele modus hervat.

Artikel 5

• 1. De bewegingsopnemer levert impulsen aan de boordcomputer.

• 2. Het opnemen van de afgelegde afstand vindt automatisch plaats op basis van impulsen en de constante van de boordcomputer.

• 3. De afgelegde afstand, bedoeld in het tweede lid vertoont tijdens gebruik per duizend meter ten hoogste een afwijking van plus of min twee procent ten opzichte van de werkelijk afgelegde afstand.

• 4. De auto wordt verondersteld zich in de toestand rijden te bevinden wanneer gedurende een periode van vijf seconden door de boordcomputer, op basis van de bewegingsopnemer, ten minste een verplaatsing van veertien meter wordt waargenomen.

• 5. De verplaatsingsopnemer is binnen de behuizing van de boordcomputer aangebracht en is van buitenaf niet bereikbaar.

• 6. De verplaatsingsopnemer meet de resulterende versnelling die de boordcomputer in verschillende richtingen ondervindt.

• 7. De auto wordt verondersteld zich in de toestand verplaatsen te bevinden wanneer er door de boordcomputer, op basis van de verplaatsingsopnemer, gedurende een periode van ten minste drie seconden een versnelling van ten minste 2 m/s² wordt waargenomen.

Artikel 6

• 1. Als de boordcomputer is ingeschakeld bepaalt de positiebepalingsensor continue de positie van de auto.

• 2. De positiebepalingsensor levert met vaste intervallen de positiegegevens van de auto aan de boordcomputer.

• 3. De positiegegevens, bedoeld in het tweede lid, bevatten ten minste de volgende gegevens:

  • a. de coördinaten;

  • b. of er een positie bepaald is;

  • c. het aantal satellieten op basis waarvan de positie van de auto bepaald is;

  • d. de HDOP-waarde uitgedrukt in een getal tussen nul en vijftig;

  • e. het tijdstip van de positiebepaling.

• 4. De twee-dimensionale wortel uit het gemiddelde kwadraat van de afstand tussen door de positiebepalingssensor geleverde coördinaten en de werkelijke positie is kleiner dan 10 meter.

• 5. De boordcomputer stelt op basis van de door de positiebepalingsensor geleverde informatie eenmaal per minuut de positie van de auto vast en registreert deze positie.

• 6. De positiegegevens, bedoeld in het vijfde lid worden zodanig opgeslagen dat zij alleen overeenkomstig artikel 23, derde lid, overgebracht kunnen worden.

Artikel 7

• 1. De boordcomputer stelt op basis van gegevens van de bewegingsopnemer en de constante van de boordcomputer continu de kilometerstand beschikbaar.

• 2. De resolutie van de kilometerstand is 100 meter of nauwkeuriger.

• 3. De boordcomputer gebruikt de gemeten posities van de positiebepalingsensor om afstanden te meten en daarmee de afstandsbepaling met de bewegingsopnemer te controleren.

• 4. De controle tussen beide afstandsbepalingen, bedoeld in het derde lid, vindt steeds plaats op basis van de positiegegevens van een traject van 1000 meter waarbij de snelheid van de auto steeds hoger was dan tien kilometer per uur.

• 5. Het verschil tussen de door beide sensoren berekende afstand bedraagt hierbij minder dan drie procent.

§ 2.2 Registratie door de boordcomputer

Artikel 8

• 1. De boordcomputer verwerkt en registreert gegevens op zodanige wijze dat de vertrouwelijkheid, integriteit en beschikbaarheid van de gegevens gewaarborgd zijn.

• 2. De authenticiteit, integriteit en onweerlegbaarheid van de in het geheugen opgeslagen gegevens wordt gegarandeerd aan de hand van een elektronische handtekening.

Artikel 9

• 1. De boordcomputer registreert in de operationele modus, werkingsniveau arbeidstijd, de arbeids-, rij- en rusttijden, bedoeld in de artikelen 5:4, tweede en derde lid, 5:6, en 5:9, van de Arbeidstijdenwet en de artikelen 2.5:1, 2.5:2, 2.5:3, 2.5:4, 2.5:5, 2.5:6, eerste lid, en 2.5:7, van het Arbeidstijdenbesluit vervoer van de bestuurder en maakt daarbij het volgende onderscheid:

  • a. rijtijd;

  • b. andere werkzaamheden dan rijden;

  • c. pauze.

• 2. De boordcomputer registreert iedere wijziging in het arbeidstijdpatroon, het tijdstip en de datum van deze wijzigingen en de aanwezigheid van een boordcomputerkaart in de kaartlezer.

• 3. De bestuurder kan in de operationele modus, werkingsniveau arbeidstijd, handmatig de aanvang en het einde van een pauze aangeven. Een bij de aanvang van de pauze actief werkingsniveau taxivervoer wordt hiermee automatisch afgesloten.

• 4. De bestuurder kan aan het begin van een kaartsessie handmatig aangeven dat hij nadat de voorgaande kaartsessie is afgesloten nog andere werkzaamheden dan rijden heeft uitgevoerd, of pauze heeft genoten. De boordcomputer legt hierbij vast of het andere werkzaamheden dan rijden of pauze betreft, en de datum en tijd van het begin en het einde hiervan.

• 5. De boordcomputer zorgt er bij het afsluiten van een kaartsessie voor dat over de gegevens, bedoeld in het eerste lid, een elektronische handtekening wordt geplaatst door de chauffeurskaart en dat deze gegevens worden gekopieerd naar de chauffeurskaart.

• 6. Indien er geen chauffeurskaart in de boordcomputer aanwezig is, wordt de elektronische handtekening door de boordcomputer geplaatst met behulp van de systeemkaart.

• 7. De boordcomputer toont de gegevens waarover een elektronische handtekening geplaatst wordt.

Artikel 10

• 1. De boordcomputer registreert in de operationele modus, werkingsniveau taxivervoer, per rit de ritadministratie en draagt zorg voor een aantoonbaar volledige registratie.

• 2. De boordcomputer kan de ritadministratie per zitplaats gelijktijdig bijhouden.

• 3. De boordcomputer registreert op het moment van optreden het beginpunt en het eindpunt van de rit in coördinaten.

• 4. Indien de coördinaten van het beginpunt of het eindpunt van de rit niet beschikbaar zijn op het moment van optreden, vindt deze registratie alsnog plaats zodra deze coördinaten beschikbaar komen.

• 5. De boordcomputer neemt de prijs van het vervoer per rit en eventuele toeslagen over uit de in de auto aanwezige taxameter.

• 6. Indien het niet mogelijk is om de prijs van het vervoer per rit of de in rekening gebrachte toeslagen over te nemen uit de in de auto aanwezige taxameter, kunnen de prijs van het vervoer per rit of de toeslagen handmatig door de bestuurder in de boordcomputer worden ingevoerd.

• 7. In de boordcomputer kan in de operationele modus, werkingsniveau taxivervoer, handmatig de aanvang en het einde van de rit worden ingegeven en kan worden aangegeven of sprake is van een beladen of een onbeladen rit.

• 8. Direct na de beëindiging van een rit wordt door de boordcomputer met de systeemkaart een elektronische handtekening geplaatst over de ritadministratie voor de desbetreffende rit.

§ 2.3 Ritbewijs

Artikel 11

De boordcomputer stelt in de operationele modus, werkingsniveau taxivervoer, ten behoeve van het afdrukken van een ritbewijs ten minste de volgende gegevens, inclusief een korte aanduiding van het gegeven, ter beschikking:

• a. het personenvervoernummer dat staat aangegeven op de vergunning, bedoeld in artikel 4, derde lid, van de Wet personenvervoer 2000;

• b. het kenteken van de auto;

• c. het telefoonnummer van de vervoerder, dan wel het telefoonnummer van de instantie waarmee de vervoerder is overeengekomen dat klachten over taxivervoer door deze instantie in behandeling worden genomen;

• d. het telefoonnummer van het Landelijk Klachtenmeldpunt Taxivervoer;

• e. het nummer van de chauffeurskaart van de bestuurder;

• f. de plaatselijke datum en tijd bij het vertrek en de aankomst van de rit;

• g. de coördinaten van de vertrek- en de aankomstplaats van de rit;

• h. de afgelegde afstand van de rit in kilometers;

• i. het ritbedrag;

• j. opbouw van het ritbedrag, per tariefsoort bestaande uit het aantal eenheden en het bedrag per eenheid;

• k. de eventueel in rekening gebrachte toeslagen, en

• l. de totaalprijs.

§ 2.4 De werking van de boordcomputer

Artikel 12

• 1. In de bedrijfs-, controle- en activerings- en keuringsmodus kan de boordcomputer op verzoek vanuit het geheugen gegevens overbrengen naar externe gegevensdragers via een overbrengingsinterface.

• 2. In de bedrijfsmodus kunnen alleen de gegevens die zijn vastgelegd behorende bij de actieve bedrijfsvergrendeling worden overgebracht.

• 3. De overbrenging van deze gegevens en de overbrengingsinterface, bedoeld in het eerste lid, voldoen aan de eisen die zijn vastgelegd in bijlage 2.

• 4. In de bedrijfsmodus kan de overbrenging van deze gegevens tevens via een andere overbrengingsinterface plaatsvinden.

• 5. Opgeslagen gegevens worden door de overbrenging niet verwijderd of veranderd.

Artikel 13

• 1. Onverminderd artikel 12 is het toegestaan om in elke modus gegevens via een andere verbinding naar een voor deze verbinding geautoriseerd bedrijf over te brengen.

• 2. Op een overbrenging als bedoeld in het eerste lid, zijn de gegevenstoegangsrechten van de bedrijfsmodus van toepassing.

Artikel 14

• 1. Direct nadat het contact van de auto ingeschakeld is, wordt de boordcomputer automatisch ingeschakeld, tenzij de boordcomputer al ingeschakeld is.

• 2. De boordcomputer kan uitsluitend handmatig uitgeschakeld worden nadat het contact is uitgeschakeld.

• 3. Indien een stroomonderbreking heeft plaatsgevonden en de stroomvoorziening is hersteld, wordt de boordcomputer automatisch teruggebracht in de staat waarin de boordcomputer zich bevond voordat de stroomonderbreking optrad.

Artikel 15

• 1. Het vergaren van gegevens vindt plaats met behulp van sensoren, tenzij de verplichte informatie niet via een sensor kan worden verkregen.

• 2. Indien het vergaren van gegevens niet automatisch plaatsvindt met behulp van sensoren wordt de bestuurder in staat gesteld om de desbetreffende informatie handmatig in te voeren ofwel kan de verplichte informatie via een externe inrichting worden ingevoerd waarna de bestuurder de informatie handmatig kan accepteren.

• 3. Uitsluitend de laatste handmatig ingevoerde en geaccepteerde informatie kan door de bestuurder worden geannuleerd. Deze handeling wordt door de boordcomputer geregistreerd.

• 4. De sensoren die worden gebruikt voor de automatische gegevensregistratie genereren en communiceren de benodigde gegevens op betrouwbare wijze.

Artikel 16

• 1. De tijd dat de auto rijdt, terwijl in de operationele modus het werkingsniveau arbeidstijd is geselecteerd, wordt automatisch geregistreerd als rijtijd, tenzij er sprake is van een pauze.

• 2. De tijd waarin de auto stilstaat terwijl in de operationele modus het werkingsniveau arbeidstijd is geselecteerd, wordt automatisch geregistreerd als andere werkzaamheden dan rijden, tenzij er sprake is van een pauze.

Artikel 17

• 1. De boordcomputer detecteert het inbrengen en uitnemen van boordcomputerkaarten en de aanwezigheid van een boordcomputerkaart in de kaartinterface.

• 2. De boordcomputer negeert ingebrachte ongeldige boordcomputerkaarten.

• 3. Bij het inbrengen van een boordcomputerkaart leest de boordcomputer de noodzakelijke gegevens af om het kaarttype, de kaarthouder en de geldigheid van de kaart vast te stellen en registreert deze gegevens onmiddellijk.

• 4. De boordcomputer leest van de chauffeurskaart tevens de noodzakelijke gegevens af om de eerder gebruikte auto, de datum en het tijdstip van het einde van de laatste kaartsessie en de op dat moment geselecteerde activiteit te identificeren en om te controleren of de laatste kaartsessie correct is afgesloten en registreert deze gegevens onmiddellijk.

• 5. Het lezen van een boordcomputerkaart, als bedoeld in het derde en vierde lid, neemt maximaal vijf seconden in beslag.

• 6. Indien zich een fout voordoet bij het lezen van de boordcomputerkaart, voert de boordcomputer dezelfde leesopdracht maximaal drie keer uit.

• 7. De boordcomputer authenticeert de houder van de boordcomputerkaart direct bij het inbrengen van de boordcomputerkaart op basis van een persoonlijk identificatie nummer.

• 8. De boordcomputer geeft selectieve toegangsrechten tot gegevens en functies op basis van het type boordcomputerkaart dat wordt ingevoerd, zoals beschreven in bijlage 1.

• 9. De boordcomputer zorgt ervoor dat een kaartsessie kan worden geblokkeerd. Het blokkeren van een kaartsessie, bedoeld in bijlage 1, artikel 6.2, vindt plaats wanneer een boordcomputerkaart wordt uitgenomen zonder dat door de gebruiker is aangegeven dat de sessie beëindigd dient te worden.

• 10. De boordcomputer werkt nadat een kaartsessie is gestart de gegevens die op een geldige chauffeurskaart zijn opgeslagen bij met de volgende gegevens:

  • a. het kenteken van de auto, en

  • b. het nummer van de ondernemerskaart van de vervoerder zoals vastgelegd in de ingeschakelde bedrijfsvergrendeling.

• 11. De boordcomputer werkt op het moment van optreden de gegevens die op een geldige chauffeurskaart zijn opgeslagen bij met de gegevens, bedoeld in artikel 9, eerste lid.

• 12. Indien zich een fout voordoet bij het schrijven van gegevens naar de boordcomputerkaart, voert de boordcomputer dezelfde schrijfopdracht maximaal drie keer uit.

• 13. Voordat een kaart wordt uitgenomen zorgt de boordcomputer ervoor dat de kaartsessie volledig en succesvol wordt beëindigd. Het beëindigen van de kaartsessie vereist de aanwezigheid van de boordcomputerkaart in de kaartlezer, een doelbewuste handeling van de houder van de boordcomputerkaart en is alleen mogelijk indien de auto niet rijdt. Na het beëindigen van een kaartsessie schakelt de boordcomputer automatisch over naar de operationele modus, werkingsniveau basis.

• 14. De verwerking, bedoeld in het dertiende lid, neemt maximaal vijf seconden in beslag.

• 15. De boordcomputer stelt de bestuurder in staat de op de chauffeurskaart opgeslagen gegevens, bedoeld in artikel 9, eerste lid, over te brengen naar de boordcomputer, conform hetgeen gesteld in bijlage 2, artikel 8.

Artikel 18

• 1. De boordcomputer functioneert op correcte wijze met de systeemkaart.

• 2. De boordcomputer gaat tijdens de inschakeling na of het serienummer, bedoeld in artikel 22, tweede lid, onderdeel b, overeenkomt met het serienummer van de boordcomputer, zoals vastgelegd op chip van de systeemkaart.

Artikel 19

• 1. De boordcomputer beheert de bedrijfsvergrendelingen die een vervoerder aanbrengt in de bedrijfsmodus.

• 2. De bedrijfsvergrendeling verhindert inzage in de geregistreerde gegevens voor anderen dan de vervoerder voor wie de gegevens zijn geregistreerd, met uitzondering van de houder van een inspectie- of werkplaatskaart.

• 3. Indien de ondernemerskaart in de kaartlezer wordt ingebracht wordt de bedrijfsvergrendeling automatisch ingeschakeld, waarna de ondernemerskaart kan worden uitgenomen.

• 4. Een bedrijfsvergrendeling bestaat uit de registratie van het personenvervoernummer dat staat aangegeven op de vergunning, bedoeld in artikel 4, derde lid, van de Wet personenvervoer 2000, het aan de vervoerder toegekende unieke nummer, als bedoeld in artikel 9, onderdeel a, van de Handelsregisterwet 2007, het nummer van de ondernemerskaart, de datum en het tijdstip van de inschakeling en, voor zover van toepassing, de datum en het tijdstip van de uitschakeling van de bedrijfsvergrendeling.

• 5. Een bedrijfsvergrendeling schakelt automatisch uit wanneer een andere vervoerder de vergrendeling inschakelt.

• 6. Bij de eerste bedrijfsvergrendeling voor de betreffende vervoerder stelt de boordcomputer de ondernemer in staat handmatig de gegevens, bedoeld in artikel 11, onderdelen c en d, in te voeren.

• 7. De boordcomputer stelt de vervoerder in staat om via de bedrijfsvergrendeling de gegevens, bedoeld in het zesde lid, te wijzigen.

Artikel 20

• 1. De boordcomputer kan alle geregistreerde gegevens lezen.

• 2. Het geheugen houdt bij normaal gebruik alle geregistreerde gegevens ten minste 52 weken vast, met uitzondering van de gegevens, bedoeld in de artikelen 6, vijfde lid, en 22, tweede en vijfde lid.

• 3. De gegevens, bedoeld in artikel 6, vijfde lid, worden gedurende 104 weken in het geheugen vastgehouden.

• 4. Wanneer de geheugencapaciteit volledig gebruikt is komen de meest recente gegevens in de plaats van de oudste gegevens, met uitzondering van de gegevens bedoeld in artikel 22, tweede en vijfde lid.

• 5. Een stroomonderbreking van minder dan twaalf maanden beïnvloedt de in het geheugen opgeslagen gegevens niet.

• 6. De identificatiegegevens, bedoeld in het artikel 22, tweede en vijfde lid, worden nooit beïnvloed door een stroomonderbreking.

Artikel 21

• 1. Indien op basis van deze regeling geen andere informatie getoond behoeft te worden, toont de boordcomputer standaard de volgende gegevens:

  • a. de werkingsmodus en eventueel het werkingsniveau, bedoeld in artikel 4, eerste en tweede lid;

  • b. de kilometerstand, en

  • c. de plaatselijke datum en tijd.

• 2. Op verzoek van de gebruiker toont de boordcomputer de gegevens, bedoeld in artikel 22 tweede en vijfde lid.

• 3. Op verzoek van de gebruiker toont de boordcomputer, naast de gegevens bedoeld in het eerste lid en tweede lid, gegevens waarvoor de gebruiker geautoriseerd is.

• 4. Getoonde gegevens komen overeen met geregistreerde gegevens.

• 5. Het leesvenster is ingeschakeld indien de boordcomputer is ingeschakeld.

§ 2.5 Activering, deactivering en onderzoek van de boordcomputer

Artikel 22

• 1. Voordat de activering van de boordcomputer plaatsvindt worden, met uitzondering van de gegevens, bedoeld in het tweede lid, geen gegevens geregistreerd.

• 2. De boordcomputer registreert de volgende identificatiegegevens van de boordcomputer voor de levensduur van de boordcomputer:

  • a. de naam van de fabrikant;

  • b. het serienummer van de boordcomputer;

  • c. het versienummer en de datum van installatie van de programmatuur;

  • d. het versienummer en de datum van installatie van programmatuurrevisies;

  • e. het bouwjaar, en

  • f. het goedkeuringsnummer.

• 3. De activering van de boordcomputer vindt plaats in de activerings- en keuringsmodus.

• 4. Wanneer de boordcomputer zich in de niet-geactiveerde toestand bevindt wordt de activeringsfunctie van de boordcomputer automatisch opgestart bij de eerste invoer van een keuringskaart.

• 5. Bij de activering van de boordcomputer worden de volgende gegevens tot het moment van deactivering geregistreerd:

  • a. het kenteken van de auto;

  • b. de kilometerstand van de auto bij activering;

  • c. de datum en het tijdstip van de activering;

  • d. het nummer van de keuringskaart;

  • e. de constante van de boordcomputer in impulsen per kilometer;

  • f. de effectieve omtrek van de wielbanden in millimeters;

  • g. de bandenmaat van de auto;

  • h. de aanwezigheid van een koppeling met de taxameter, en

  • i. resultaat van het activeringsonderzoek en eventuele opmerkingen.

• 6. De boordcomputer stelt de gebruiker tijdens de activering in staat de impulsen te tellen om te komen tot de constante van de boordcomputer.

Artikel 23

• 1. De deactivering van de boordcomputer vindt plaats in de activerings- en keuringsmodus.

• 2. Bij de deactivering van de boordcomputer worden alle in het geheugen geregistreerde gegevens overgebracht naar een externe gegevensdrager, met uitzondering van de gegevens, bedoeld in artikel 6, vijfde lid.

• 3. Onverminderd het tweede lid kunnen de gegevens, bedoeld in artikel 6, vijfde lid, na een verzoek daartoe, uitsluitend bij deactivering worden overgebracht nadat naast de authenticatie op basis van een keuringskaart tevens een authenticatie op basis van een inspectiekaart heeft plaatsgevonden.

• 4. De ingevolge het tweede en derde lid overgebrachte gegevens worden na een succesvolle overbrenging ervan gewist, met uitzondering van de gegevens, bedoeld in artikel 22, tweede lid.

Artikel 24

• 1. Het onderzoek van de boordcomputer vindt plaats in de activerings- en keuringsmodus.

• 2. Tijdens het onderzoek registreert de boordcomputer de volgende gegevens tot deactivering:

  • a. de datum en het tijdstip waarop het onderzoek wordt uitgevoerd;

  • b. het nummer van de keuringskaart, en

  • c. het resultaat van het onderzoek en eventuele opmerkingen.

• 3. Tijdens het onderzoek kunnen de gegevens, bedoeld in artikel 22, vijfde lid, onderdelen e tot en met h, aangepast worden. De nieuw ingevoerde gegevens worden tot deactivering geregistreerd en door de boordcomputer gebruikt.

• 4. Indien de gegevens, bedoeld in artikel 22, vijfde lid, onderdelen e tot en met g, worden aangepast, worden de oude gegevens niet overschreven.

§ 2.6 Gebeurtenissen, fouten en storingen

Artikel 25

• 1. De boordcomputer is voorzien van een diagnosemechanisme dat ten minste het volgende vaststelt:

  • a. gebeurtenissen als bedoeld in bijlage 1, artikel 6.5, onderdeel FAU_GEN1.1;

  • b. fouten als bedoeld in artikel 26, eerste lid;

  • c. storingen als bedoeld in artikel 26, derde lid.

• 2. Het diagnosemechanisme is niet toegankelijk voor de gebruiker of uitschakelbaar door de gebruiker.

• 3. Bij het opstarten voert de boordcomputer een zelfbeproeving uit. De zelfbeproeving bevat ten minste een verificatie van de integriteit van de uitvoercode van de boordcomputer, een verificatie van de integriteit van geregistreerde systeemgegevens en het bestaan van storingen als bedoeld in artikel 26, zevende lid.

• 4. Naast de zelfbeproeving als bedoeld in het derde lid, kan op ieder gewenst moment een ingebouwde beproeving worden gestart. De ingebouwde beproeving stelt de gebruiker in staat vast te stellen of de boordcomputer op correcte wijze functioneert.

• 5. Op het moment van optreden registreert de boordcomputer de gebeurtenis, fout of storing, waarbij per optreden ten minste de gegevens worden vastgelegd zoals beschreven in bijlage 1, artikel 6.5, onderdeel FAU_GEN.1.2.

• 6. De boordcomputer beschikt bij normaal gebruik over voldoende opslagcapaciteit voor het vastleggen van gebeurtenissen, fouten en storingen over een periode van ten minste 52 weken.

Artikel 26

• 1. Een fout treedt op wanneer de correcte werking van de boordcomputer gedurende korte tijd wordt onderbroken.

• 2. De boordcomputer detecteert ten minste de volgende fouten:

  • a. een integriteitfout in de uitvoercode;

  • b. een integriteitfout in de systeemgegevens;

  • c. een integriteitfout in de opgeslagen gebruikersgegevens;

  • d. een integriteitfout bij de gegevensuitvoer naar de chauffeurskaart;

  • e. een fout in de registratiefunctie;

  • f. een fout die de beveiliging, bedoeld in artikel 31, van de boordcomputer in gevaar brengt;

  • g. een fout bij de gegevensuitvoer naar externe inrichtingen;

  • h. een fout bij het gebruik van de systeemkaart;

  • i. een fout bij het gebruik van de boordcomputerkaart;

  • j. een fout in de bewegingsensor;

  • k. een fout in de positiebepalingsensor;

  • l. een fout in de koppeling met de taxameter.

• 3. Een storing treedt op wanneer een onderbreking in de correcte werking van de boordcomputer door een gebeurtenis of fout een permanent karakter heeft.

• 4. De boordcomputer detecteert ten minste de volgende storingen:

  • a. een storing in de werking van de registratiefunctie;

  • b. een storing in de werking van de beveiligingsfuncties;

  • c. een storing in de werking van de sensoren;

  • d. een storing in de overbrenging naar een externe interface zoals beschreven in bijlage 2;

  • e. een storing in de werking van de systeemkaart;

  • f. een storing in de werking van de boordcomputerkaarten.

• 5. Bij het vastleggen van gebeurtenissen, fouten en storingen koppelt de boordcomputer daar een code aan, zoals beschreven in bijlage 2, artikel 6, zevende lid.

• 6. Zolang de correcte werking van de beveiligingsfuncties, bedoeld in artikel 31, gegarandeerd is, blijft de boordcomputer na het detecteren van een fout doorgaan met het registreren van gegevens. Deze gegevens worden zodanig in de boordcomputer geregistreerd dat ze herkenbaar zijn als zijnde geregistreerd gedurende een periode waarin zich één of meerdere fouten hebben voorgedaan.

• 7. De boordcomputer staakt het uitvoeren van verdere handelingen wanneer een storing wordt gedetecteerd als bedoeld in het vierde lid, onderdelen a, b, c en e.

Artikel 27

• 1. Het optreden van de onderstaande gebeurtenissen leidt tot een fout als bedoeld in artikel 26, tweede lid, onderdeel i:

  • a. het inbrengen van een ongeldige boordcomputerkaart;

  • b. het inbrengen van een chauffeurskaart waarvan blijkt dat de datum en het tijdstip van de laatste registratie op de chauffeurskaart, op een later tijdstip valt dan de actuele datum en het tijdstip van de boordcomputer;

  • c. het niet op een juiste wijze afsluiten van een kaartsessie;

  • d. het inbrengen van een chauffeurskaart waarvan blijkt dat de laatste kaartsessie niet juist is afgesloten;

  • e. het ontstaan van onvoldoende opslagcapaciteit op de chauffeurskaart;

  • f. een niet-succesvolle authenticatiepoging;

  • g. het gedurende een periode van 28 kalenderdagen gebruiken van de operationele modus, werkingsniveau arbeidstijd, zonder geldige boordcomputerkaart.

• 2. .*Het optreden van de onderstaande gebeurtenissen leidt tot een fout als bedoeld in artikel 26, tweede lid, onderdeel e:

  • a. het ontstaan van onvoldoende opslagcapaciteit op het geheugen van de boordcomputer, en

  • b. een onderbreking van ten minste vijf seconden in de stroomvoorziening van de boordcomputer.

• 3. Het optreden van een toestand verplaatsen zonder dat er een toestand rijden wordt waargenomen leidt tot een fout als bedoeld in artikel 26, tweede lid, onderdeel j, tenzij er een toestand rijden is vastgesteld in de 20 seconden voor of na het optreden van de toestand verplaatsen.

• 4. Het gedurende vijf minuten niet kunnen verkrijgen van positiegegevens leidt tot een fout als bedoeld in artikel 26, tweede lid, onderdeel k.

• 5. Een afwijking die de waarden, bedoeld in artikel 7, vijfde lid, overschrijdt leidt tot een fout als bedoeld in artikel 26, tweede lid, onderdelen j en k.

• 6. Het optreden van gebeurtenissen die kunnen duiden op het in gevaar brengen van de beveiliging van de boordcomputer, bedoeld in artikel 31, leidt tot een fout als bedoeld in artikel 26, tweede lid, onderdeel f.

• 7. Het vanuit de bedrijfsmodus gedurende 365 kalenderdagen niet overbrengen van gegevens bedoeld in artikel 1, leidt tot een fout als bedoeld in artikel 26, tweede lid, onderdeel g.

Artikel 28

• 1. Het optreden van fouten als bedoeld in artikel 26 tweede lid onderdelen a, b, of c, leidt tot een storing bedoeld in artikel 26 vierde lid, onderdeel b.

• 2. Het meer dan tien maal optreden binnen 30 kalenderdagen van een gebeurtenis als bedoeld in artikel 27, tweede lid, onderdeel b, leidt tot een storing als bedoeld in artikel 26 vierde lid, onderdeel a.

• 3. Het langer dan 24 uur bestaan van de fout, bedoeld in artikel 26, tweede lid, onderdeel j of onderdeel k, leidt tot een storing als bedoeld in artikel 26, vierde lid, onderdeel c.

• 4. Het optreden van de fout, bedoeld in artikel 26, tweede lid, onderdeel f, leidt tot een storing als bedoeld in artikel 26, vierde lid, onderdeel b.

• 5. Het meer dan 100 maal optreden binnen een kalenderdag van een gebeurtenis als bedoeld in artikel 26, tweede lid, onderdeel j, leidt tot een storing als bedoeld in artikel 26, vierde lid, onderdeel c.

Artikel 29

• 1. De boordcomputer waarschuwt de gebruiker zodra het volgende wordt gedetecteerd:

  • a. het optreden en eindigen van fouten in de werking van de boordcomputer genoemd in artikel 26, tweede lid;

  • b. het optreden en eindigen van storingen in de werking van de boordcomputer genoemd in artikel 26, vierde lid.

• 2. De waarschuwingssignalen worden in ieder geval in visuele vorm weergegeven.

• 3. De waarschuwingssignalen zijn zowel overdag als ’s nachts duidelijk afleesbaar en herkenbaar en bevinden zich binnen het gezichtsveld van de bestuurder.

• 4. Indien zich een fout of gebeurtenis voordoet als bedoeld in het eerste lid, onderdelen a en b, wordt de reden van de waarschuwing getoond. Deze waarschuwing blijft zichtbaar totdat de gebruiker handmatig bevestigt de waarschuwing te hebben opgemerkt.

§ 2.7 Eisen aan het functioneren van de boordcomputer

Artikel 30

• 1. De boordcomputer voldoet aan de eisen die zijn neergelegd in NEN-ISO 10605.

• 2. De boordcomputer voldoet aan de eisen die zijn neergelegd in NEN-EN-IEC 60068-2-1 en NEN-EN-IEC 60068-2-2 en functioneert naar behoren binnen het temperatuurbereik van –20 °C tot +70 °C.

• 3. De boordcomputer voldoet aan de eisen die zijn neergelegd in NEN-EN-IEC 60068-2-30 en functioneert naar behoren binnen het vochtigheidsbereik van 10% tot 90% relatieve vochtigheid.

• 4. De boordcomputer is beveiligd tegen kortsluiting, overspanning en polariteitomkering.

• 5. De boordcomputer is bestand tegen kortstondige onderbrekingen of voedingspanningvariaties die worden veroorzaakt door het starten van de auto.

§ 2.8 Beveiligingseisen

Artikel 31

• 1. De boordcomputer is voorzien van beveiligingsfuncties die de juiste en betrouwbare werking van de boordcomputer waarborgen.

• 2. De beveiligingsfuncties, bedoeld in het eerste lid, voldoen aan de beveiligings-doelstellingen en de beveiligingseisen bedoeldin bijlage 1.

• 3. De boordcomputer verifieert programmatuurrevisies door middel van een programmatuur veiligheidscertificatie, voordat deze in de boordcomputer geïmplementeerd worden.

• 4. De boordcomputer biedt de mogelijkheid om informatie meer dan één keer te voorzien van een elektronische handtekening.

• 5. Bij het plaatsen van de elektronische handtekening blijft de informatie in de oorspronkelijke vorm behouden. De handtekening wordt als bijlage aan de ondertekende informatie toegevoegd, zodat de oorspronkelijke gegevens leesbaar zijn voor applicaties die geen elektronische handtekening ondersteunen.

§ 3 Typegoedkeuring boordcomputer

Artikel 32

• 1. De Dienst Wegverkeer kan op aanvraag en na betaling van het daarvoor door deze dienst vastgestelde tarief een typegoedkeuring verlenen aan een fabrikant voor een boordcomputer die voldoet aan de in paragraaf 2 opgenomen eisen.

• 2. De aanvraag en behandeling van een typegoedkeuring als bedoeld in het eerste lid geschieden met inachtneming van de in richtlijn 2007/46/EG daaromtrent gegeven voorschriften.

Artikel 33

• 1. Bij een aanvraag als bedoeld in artikel 32, eerste lid, overlegt de fabrikant in elk geval de volgende bescheiden in de Nederlandse of Engelse taal:

  • a. de specificaties volgens welke de boordcomputer is gebouwd;

  • b. een certificaat dat is afgegeven door een voor Common Criteria geaccrediteerd certificatielichaam dat door Nederland is erkend, waaruit blijkt dat de boordcomputer voldoet aan de in bijlage 1 bij deze regeling opgenomen specificaties;

  • c. de documenten die behoren bij het in onderdeel b bedoelde certificaat waarin de beveiligingsdoelstellingen en de door de certificerende instelling gemaakte opmerkingen zijn opgenomen;

  • d. één of meerdere testrapporten die zijn opgesteld door een testinstelling die werkt overeenkomstig ISO-IEC 17025, dan wel overeenkomstig kwaliteitsstandaarden die aantoonbaar een vergelijkbaar beschermingsniveau bieden, waaruit eenduidig blijkt:

    • 1°. dat de boordcomputer voldoet aan de in paragraaf 2 opgenomen eisen voor zover deze eisen niet vallen onder het certificaat als bedoeld in onderdeel b, en

    • 2°. op welke wijze dat is vastgesteld;

  • e. een schriftelijke en ondertekende verklaring van de fabrikant waarin deze verklaart dat hij de boordcomputer gaat produceren en dat de ingevolge onderdeel a overgelegde technische specificaties identiek zijn aan de technische specificaties waarvoor het beveiligingscertificaat en de in onderdeel d bedoelde testrapporten zijn afgegeven;

  • f. een beschrijving van de organisatorische maatregelen die zijn of zullen worden getroffen teneinde te borgen dat de te produceren boordcomputers zullen overeenstemmen met het goedgekeurde type, en

  • g. een gebruikers- en installatiehandleiding.

• 2. Bij een aanvraag als bedoeld in artikel 32, eerste lid, wordt door de fabrikant voor de keuring een exemplaar van de boordcomputer ter beschikking van de Dienst Wegverkeer gesteld.

• 3. De Dienst Wegverkeer kan in verband met de uitvoering van de typegoedkeuring bij de testinstelling die één of meerdere door de fabrikant overgelegde testrapporten, bedoeld in het eerste lid, onderdeel d, heeft opgesteld, nadere gegevens opvragen of een onderzoek ter plaatse uitvoeren voor zover dit nodig is voor de beoordeling van deze testrapporten.

• 4. De fabrikant draagt zorg voor de medewerking van de door hem ingeschakelde testinstellingen aan het in het vorige lid bedoelde opvragen van gegevens of uit te voeren nader onderzoek.

Artikel 34

• 1. De Dienst Wegverkeer houdt op de door deze dienst te bepalen wijze toezicht op de typegoedkeuring voor boordcomputers.

• 2. Het toezicht, bedoeld in het eerste lid geschiedt met inachtneming van de in richtlijn 2007/46/EG daaromtrent gegeven voorschriften.

• 3. Indien niet voldaan wordt aan de in richtlijn 2007/46/EG vermelde verplichtingen, wordt de fabrikant in staat gesteld de geconstateerde tekortkomingen binnen een door de Dienst Wegverkeer te bepalen termijn te herstellen en kan het toezicht worden geïntensiveerd.

Artikel 35

De fabrikant stelt de Dienst Wegverkeer onverwijld in kennis van de voorgenomen of reeds uitgevoerde wijzigingen ten aanzien van de boordcomputer.

Artikel 36

Een typegoedkeuring voor een boordcomputer vervalt van rechtswege zodra voor de registratie, verkoop of het in het verkeer brengen van nieuwe boordcomputers zwaardere eisen van kracht worden, tenzij:

• a. in richtlijn 2007/46/EG anders is bepaald, of

• b. bij het van kracht worden van de zwaardere eisen anders is bepaald.

§ 4 Overgangs- en slotbepalingen

Artikel 37

• 1. Van een wijziging van de normbladen waarnaar in deze regeling verwezen wordt, doet de minister mededeling in de Staatscourant.

• 2. Een wijziging in een normblad heeft voor deze regeling pas rechtsgevolgen op 1 januari van het jaar volgende op dat waarin de mededeling bedoeld in het eerste lid heeft plaatsgevonden.

Artikel 38

Met een boordcomputer als bedoeld in deze regeling wordt gelijkgesteld een boordcomputer die rechtmatig is vervaardigd of in de handel is gebracht in een andere lidstaat van de Europese Unie dan wel rechtmatig is vervaardigd in een staat, niet zijnde een lidstaat van de Europese Unie, die partij is bij daartoe strekkend of mede daartoe strekkend verdrag dat Nederland bindt, en die voldoet aan eisen die een beschermingsniveau bieden dat ten minste gelijkwaardig is aan het niveau dat met de nationale eisen wordt nagestreefd.

Artikel 39

De Regeling boordcomputer taxi wordt ingetrokken.

Artikel 40

Deze regeling wordt aangehaald als: Regeling specificaties en typegoedkeuring boordcomputer taxi.

Artikel 41

Deze regeling treedt in werking met ingang van 1 oktober 2010.

Deze regeling zal met de toelichting in de Staatscourant worden geplaatst.

De Minister van Verkeer en Waterstaat,

C.M.P.S. Eurlings.

BIJLAGE 1

Artikel 1 Introductie

Deze bijlage is een beveiligingsprofiel (Protection Profile) voor de voertuigcomponenten van de boordcomputer in overeenstemming met de Common Criteria versie 3.1. Het beveiligingsprofiel geeft een beschrijving van het door de boordcomputer te implementeren beleid, de te realiseren beveiligingsdoelstellingen, en de te behalen beveiligingseisen, alsmede het vereiste garantieniveau voor de boordcomputer, zoals afgeleid is bij een eerdere afhankelijkheids- en kwetsbaarheidsanalyse.

Dit beveiligingsprofiel voor de boordcomputer is opgesteld voor de Inspectie Verkeer en Waterstaat van het Ministerie van Verkeer en Waterstaat.

Artikel 2 Afkortingen, acroniemen, definities en referenties

Artikel 2.1 PP Referentie

Dit document is het ‘Beveiligingsprofiel Boordcomputer Taxi’ (PP-BCT) versie 1.3, 9 februari 2010.

Artikel 2.2 Claim voor voldoen aan de Common Criteria

Dit beveiligingsprofiel voldoet aan Common Criteria versie 3.1 Revisie 2. Hoewel de ‘International English’ versie is gebruikt voor het ontwikkelen van dit beveiligingsprofiel, is (met toestemming van het certificeringsschema) dit profiel in het Nederlands.

Dit beveiligingsprofiel:

• is CC Deel 2 conform;

• is CC Deel 3 conform;

• is EAL3 conform;

• claimt niet te voldoen aan andere beveiligingsprofielen;

• vereist strikte conformering van andere beveiligingsprofielen (PPs) of beveiligingsspecificaties (STs) die aan dit beveiligingsprofiel willen voldoen.

Artikel 2.3 Notities

Dit document volgt de naamgeving en notaties voor beveiligingsprofielen volgens de Common Criteria standaard. Er zijn unieke labels toegewezen aan entiteiten zodat deze gemakkelijk terug te vinden zijn. De labels beginnen met één van de onderstaande karakters:

A	Assumption (aanname)
O	Object (object)
OE	Security objective for the Environment (omgevingsdoelstellingen)
OT	Security objective for the TOE (beveiligingsdoelstelling)
P	Organisational Security Policy (beleid)
S	Subject (persoon, middel of een proces)

Artikel 2.4 Afkortingen en acroniemen

CC	Common Criteria (referentienorm)
CEN	European Committee for Standardization
CWA	N Workshop Agreements
EAL	Evaluation Assurance Level (garantieniveau)
EH	Elektronische handtekening
EPROM	Erasable Programmable Read Only Memory
ETSI	European Telecommunications Standards Institute
FIPS	Federal Information Processing Standards
GNSS	Global Navigation Satellite System
IEC	International Electrotechnical Commission
IETF	Internet Engineering Task Force
ISO	International Organisation for Standardisation
PIN	Personal identification number (PIN-code)
PP	Protection Profile (Beveiligingsprofiel)
PKI	Public Key Infrastructure (publieke sleutel methodiek)
PUB	Public
ROM	Read Only Memory (ROM-geheugen)
RFC	Request for Comments
SFP	Security Function Policy
SFR	Security Functional Requirement (Beveiligingseis)
SHA	Secure Hash Algorithm
ST	Security Target (Beveiligingsspecificatie)
TOE	Target of Evaluation (onderwerp van de evaluatie)
TS	Technical Standard
TSF	TOE Security Functionality
TSFI	TSF Interface

Artikel 2.5 Referentienormen

De TOE wordt getoetst conform het normenkader van Common Criteria for Information Technology Security Evaluation, versie 3.1, revisie 2, September 2007.

De TOE ondersteunt de volgende standaarden wanneer cryptografische bewerkingen dienen te worden uitgevoerd:

• Het SHA cryptografische algoritme voor hash functies zoals gedefinieerd in de ISO/IEC 10118-3, FIPS PUB 180-2 en ETSI TS 102 176-1 standaarden;

• ETSI TS 101 733 Electronic Signature Formats en de FIPS PUB 186-2 standaarden voor elektronische handtekeningen;

Artikel 3 Overzicht van de TOE

Artikel 3.1 Beschrijving van de TOE

De TOE is een controleapparaat bedoeld voor installatie in auto’s gebruikt voor taxivervoer. Het doel is om handhavingprocessen te helpen uitvoeren door de elektronische registratie van de ritadministratie en de arbeids-, rij- en rusttijden en het op aanvraag ter beschikking stellen van deze informatie aan bevoegde personen ter controle.

De TOE kent vier werkingsmodi, te weten: operationele modus, controle modus, activering/keuringsmodus en bedrijfsmodus. De operationele modus kent drie werkingsniveaus: basis, arbeidstijd en taxivervoer. Wanneer taxivervoer wordt aangeboden of arbeidstijd plaatsheeft, selecteert de bestuurder handmatig het corresponderende werkingsniveau. In de operationele modus, werkingsniveau arbeidstijd of taxivervoer, worden gegevens geregistreerd over de uitgevoerde taxiritten en de arbeids-, rij-, en rusttijden van de bestuurder. De aanvang en het beëindigen van een rit wordt door een actieve bedieningshandeling van de bestuurder bij de TOE kenbaar gemaakt. Hierbij dient de beladingtoestand (beladen/onbeladen) te worden aangegeven.

Daarnaast draagt de TOE in alle modi zorg voor het beschikbaar stellen van de basisgegevens tijd en afgelegde afstand, en de positie van het voertuig. In het werkingsniveau basis wordt ook de registratie van gebeurtenissen gevoerd. In de operationele modus is het werkingsniveau basis een apart werkingsniveau. In de overige modi integreert de TOE de basis functionaliteit met de overige functionaliteit van de betreffende modus.

De TOE bestaat ten minste uit een verwerkingseenheid, een geheugen, een tijdklok, een ISO 7816 kaartinterface, een ISO 7810 ID-000 kaartinterface ten behoeve van de systeemkaart, een positiebepalingssensor of een interface voor de positiebepalingssensor, een verplaatsingsopnemer, een interface voor de bewegingsopnemer, een gegevensoverbrengingsinterface, een interface voor de taxameter, een leesvenster en voorzieningen voor de invoer van gebruikersgegevens.

De TOE kan door middel van additionele verbindingen aan andere inrichtingen worden gekoppeld, of daarmee geïntegreerd worden.

Toegang tot de TOE wordt verleend door middel van een boordcomputerkaart met PIN-code en voorzien van een (authenticatie)certificaat. Er worden vier gebruikersrollen voorzien, te weten bestuurder, toezichthouder, werkplaats en vervoerder. De omschakeling tussen werkingsmodi gebeurt door het plaatsen van de correcte boordcomputerkaart in de TOE. Er worden vier verschillende kaarten onderscheiden, te weten: chauffeurskaart, inspectiekaart, keuringskaart en ondernemerskaart. Boordcomputerkaarten maken geen onderdeel uit van de TOE.

Bij aanvang van de dienst dient een chauffeurskaart in de TOE te zijn geplaatst. De bestuurder meldt zich aan met de chauffeurskaart en een persoonlijk identificatie code (PIN-code). De TOE registreert de persoonlijke arbeids-, rij- en rusttijden van de bestuurder en slaat deze op in het interne geheugen van de TOE en op de chauffeurskaart.

In voorkomende gevallen heeft een chauffeur geen kaart en dan dient hij zijn burgerservicenummer in te voeren. Dit burgerservicenummer dient alleen voor identificatie, en wordt door de TOE verder niet gecontroleerd.

De boordcomputerkaarten voor de bestuurder zijn voorzien van een certificaat voor het elektronisch identificeren van de persoon en het ondertekenen van geregistreerde gegevens.

De TOE gebruikt een systeemkaart welke is voorzien van certificaten voor identificatie van de TOE en het plaatsen van elektronische handtekeningen. Het certificaat ten behoeve van de TOE wordt in de productiefase in de vorm van de systeemkaart geïmplementeerd in de TOE. Deze certificaten worden uitgegeven onder verantwoordelijkheid van de Minister van Verkeer en Waterstaat. Systeemkaarten zijn geen onderdeel van de TOE.

De TOE voert gegevens uit naar een leesvenster en kan gegevens ter beschikking stellen ten behoeve van een externe printer en externe inrichtingen.

De operationele omgeving van de TOE geïnstalleerd in de auto is weergegeven in onderstaande figuur.

Figuur 1

De systeemkaart plaatst een elektronische handtekening (EH) per uitgevoerde rit over alle ritgegevens terstond nadat de bestuurder heeft aangegeven dat de rit teneinde is.

De chauffeurskaart plaatst een elektronische handtekening bij het einde van de dienst van de bestuurder over de arbeids-, rij- en rusttijden van de bestuurder gedurende de dienst. Hiervoor wordt het persoonsgebonden certificaat van de chauffeurkaart gebruikt waarbij de bestuurder vooraf zijn goedkeuring verleent door het ingeven van de PIN-code van de chauffeurskaart.

De systeemkaart plaatst een elektronische handtekening over de geregistreerde gegevens wanneer deze worden opgeslagen en wanneer deze worden uitgevoerd naar een externe gegevensdrager.

De koppeling van bestuurder aan de geregistreerde gegevens en de waarborging van de integriteit en authenticiteit van de gegevens wordt in onderstaande figuur geïllustreerd:

Figuur 2

Artikel 3.2 Levenscyclus van de TOE

De typische levenscyclus van een TOE wordt geïllustreerd door onderstaande figuur. Het verkrijgen van een typegoedkeuring is een verantwoordelijkheid van de fabrikant. Eventuele reparaties worden uitgevoerd door, of onder verantwoordelijkheid van, de fabrikant. Installatie van eventuele nieuwere versies van programmatuur (software updates), mogen door erkende werkplaatsen worden uitgevoerd gedurende een periodieke controle.

Figuur 3

Artikel 3.3 Entiteiten

Voor de TOE zijn de volgende types van entiteiten (subjecten en objecten) relevant:

Artikel 3.3.1 Subjecten - middelen

S.BEWEGINGSOPNEMER

Het instrument, of een deel ervan, gekoppeld aan de TOE dat een signaal in de vorm van een impuls afgeeft over de beweging van de auto op basis waarvan de TOE de afgelegde afstand van de auto kan bepalen.

S.POSITIEBEPALINGSSENSOR

Het instrument, of een deel ervan, gekoppeld aan de TOE dat een signaal afgeeft aan de TOE over de locatie van de auto op basis van verkregen informatie van een satelliet positiebepalingsysteem.

S.BOORDCOMPUTERKAART

De geheugenkaart met chip voor gebruik in de TOE waarmee de TOE de identiteit van de kaarthouder kan vaststellen en waarop gegevens kunnen worden opgeslagen.

S.SYSTEEMKAART

De geheugenkaart met chip die de TOE in staat stelt een elektronische handtekening te plaatsen.

S.PRINTER

Een externe inrichting waaraan gegevens beschikbaar kunnen worden gesteld voor het afdrukken op papier.

S.TAXAMETER

De geijkte externe inrichting voor het bepalen van de ritprijs op basis van een tarievenstructuur.

S.HANDHAVINGSMIDDELEN

Fysiek aan de TOE gekoppelde hulpmiddelen t.b.v. toezichthouders voor het uitlezen en verwerken van gegevens.

S.KALIBRATIEMIDDELEN

Fysiek aan de TOE gekoppelde hulpmiddelen t.b.v. een erkende werkplaats voor het ijken, kalibreren en activeren van de TOE.

S.BEDRIJFSMIDDELEN

Fysiek aan de TOE gekoppelde hulpmiddelen t.b.v. de vervoerder voor de overdracht van gegevens naar de bedrijfsadministratie.

Artikel 3.3.2 Subjecten - gebruikers

S.CHAUFFEURSKAART

Een aan de bestuurder afgegeven boordcomputerkaart waarmee de boordcomputer de identiteit van de desbetreffende bestuurder kan vaststellen, een elektronische handtekening kan plaatsen, en waarmee de operationele modus van de TOE kan worden geactiveerd.

S.INSPECTIEKAART

Een aan de met het toezicht op de naleving belaste persoon afgegeven boordcomputerkaart die de desbetreffende persoon identificeert en waarmee de controlemodus van de boordcomputer kan worden geactiveerd.

S.KEURINGSKAART

Een aan een erkende werkplaats afgegeven boordcomputerkaart die de desbetreffende werkplaats identificeert en waarmee de activerings- en keuringsmodus van de boordcomputer kan worden geactiveerd.

S.ONDERNEMERSKAART

Een aan een vervoerder afgegeven boordcomputerkaart die de desbetreffende vervoerder identificeert en waarmee de bedrijfsmodus van de boordcomputer kan worden geactiveerd.

Artikel 3.3.3 Objecten

O.BASISGEGEVENS

De tijd, afgelegde afstand en gegevens betreffende verplaatsing zoals bijgehouden door de TOE.

O.ARBEIDSTIJDGEGEVENS

De arbeids-, rij- en rusttijden gegevens van de bestuurder zijnde de rijtijd, pauze en andere werkzaamheden dan rijden geregistreerd door de TOE.

O.RITGEGEVENS

De gegevens per individuele rit bestaande uit ten minste de begin- en eindlocatie, de begin- en einddatum en tijd, afgelegde afstand, de ritprijs, de beladingstoestand en identiteit van de bestuurder geregistreerd door de TOE.

O.BEDRIJFSGEGEVENS

Gegevens over de vervoerder zoals zijn vastgelegd op de TOE.

O.KAARTHOUDERGEGEVENS

Gegevens opgeslagen op de boordcomputerkaart ingebracht in de TOE.

O.POSITIEGEGEVENS

Gegevens betreffende de locatie van de auto die door de S.POSITIEBEPALINGSSENSOR aan de TOE worden aangeleverd.

O.BEWEGINGSGEGEVENS

Gegevens betreffende snelheid en afgelegde afstand die door S.BEWEGINGSOPNEMER of S.POSITIEBEPALINGSSENSOR aan de TOE worden aangeleverd.

O.GEBEURTENISGEGEVENS

Gegevens geregistreerd door de TOE met betrekking tot routinematige en uitzonderlijke gebeurtenissen op basis waarvan analyses mogelijk zijn en de verantwoordelijke gebruiker of proces kan worden bepaald.

O.SYSTEEMGEGEVENS

Specifieke gegevens ter ondersteuning of noodzakelijk voor het functioneren van de TOE of voor identificatie en instellingen van de TOE functies.

Artikel 3.4 Begrenzingen van de TOE

De TOE (Target of Evaluation) is de selectie van hardware en software en bijbehorende handleidingen die uiteindelijk wordt geëvalueerd. De TOE moet alle functionaliteit omvatten die nodig is om aan de eisen in dit profiel te voldoen, maar mag daarnaast ook andere zaken bevatten, zoals bijvoorbeeld een routeplanningsapplicatie.

De minimale omvang van de TOE wordt schematisch weergegeven in onderstaande figuur:

Figuur 4

Alle onderdelen die in deze afbeelding binnen de grijze omheining worden weergegeven moeten onderdeel zijn van de TOE. Dus bijvoorbeeld de (voertuig) sensor voor bewegingsgegevens (bewegingsopnemer) en de positiebepalingssensor (GNSS) hoeven geen deel uit te maken van de TOE maar de aansluiting van deze sensoren weer wel

Andere zaken die in deze figuur zijn weergegeven (zoals de taxameter en de printer), mogen onderdeel zijn van de TOE, hoewel dit niet altijd praktisch is. Ook extra software en hardware die niet in deze figuur zijn weergegeven (zoals de bovengenoemde routeplanningsapplicatie) mogen deel uitmaken van de TOE.

Daarnaast is het toegestaan om extra hardware of software binnen de fysieke behuizing van de TOE op te nemen, zonder dat deze hardware of software meteen onderdeel worden van de TOE. Het is echter niet toegestaan om tijdens de evaluatie van de TOE aan te nemen dat deze extra hardware of software vertrouwd of goedaardig is: de evaluatie van de TOE dient ondubbelzinnig aan te tonen dat de TOE nog steeds voldoet aan dit Beschermingsprofiel als deze opgenomen hardware of software niet vertrouwd of goedaardig is.

Artikel 4 Beveiligingsprobleem

Artikel 4.1 Beveiligingsbeleid

P.VASTLEGGEN

De TOE legt de volgende gegevens vast, afhankelijk van de werkingsmodus en het actieve werkingsniveau:

• Operationele modus basis: In ingeschakelde toestand registreert de TOE altijd de positie- en gebeurtenisgegevens. Indien een boordcomputerkaart is ingebracht registreert de TOE de identiteit van de kaarthouder;

• Operationele modus arbeidstijd: Na een selectie van het werkingsniveau arbeidstijd registreert de TOE de positie- en gebeurtenisgegevens en de arbeidstijdgegevens. Het werkingsniveau arbeidstijd wordt automatisch geselecteerd door het inbrengen van de chauffeurskaart, en kan zonder chauffeurskaart handmatig geselecteerd worden na het invoeren van een burgerservicenummer. Indien een boordcomputerkaart is ingebracht registreert de TOE de identiteit van de kaarthouder, indien identificatie plaats vindt met een burgerservicenummer, dan registreert de TOE dit burgerservicenummer;

• Operationele modus taxivervoer: Na een handmatige selectie van het werkingsniveau taxivervoer, registreert de TOE de positie- en gebeurtenisgegevens, de arbeidstijdgegevens en de ritgegevens. Indien een boordcomputerkaart is ingebracht registreert de TOE de identiteit van de kaarthouder, indien identificatie plaatsvindt met een burgerservicenummer, dan registreert de TOE dit burgerservicenummer;

• Controlemodus: De TOE registreert de positie- en gebeurtenisgegevens en de identiteit van de kaarthouder;

• Activering/keuringsmodus: De TOE registreert de positie- en gebeurtenisgegevens en de identiteit van de kaarthouder;

• Bedrijfsmodus: De TOE registreert de positie- en gebeurtenisgegevens en de identiteit van de kaarthouder.

P.BEWAREN_EN_BORGEN

De TOE bewaart de vastgelegde gegevens zodat:

• wijzigingen van de gegevens detecteerbaar zijn;

• de gegevens onweerlegbaar gekoppeld zijn aan de TOE;

• de gegevens onweerlegbaar gekoppeld zijn aan de boordcomputerkaart.

P.ACTIES

De TOE kan de volgende acties uitvoeren, afhankelijk van de werkingsmodus, het actieve werkingsniveau en de ingebrachte boordcomputerkaart:

• Selecteren van de juiste werkingsmodus;

• Activering, deactivering en onderzoek van de TOE;

• Instellen van de bedrijfsvergrendeling;

• Detecteren en registreren van storingen¹;

• Detecteren en registeren van fouten²;

• Detecteren en registeren van gebeurtenissen;

• Gegevens tonen op een leesvenster;

• Gegevens overbrengen naar een externe gegevensdrager;

• Gegevens overbrengen van de chauffeurskaart naar de TOE;

• Gegevens overbrengen naar een externe inrichting;

• Gegevens beschikbaar stellen t.b.v. een printer;

• Geven van waarschuwingssignalen.

P.UITVOEREN_GEGEVENS

De TOE kan de geregistreerde gegevens uitvoeren, afhankelijk van de ingebrachte boordcomputerkaart:

• Geen kaart, authenticatie op basis van burgerservicenummer:

  • ritgegevens van de huidige sessie naar een leesvenster;

  • arbeids-, rij- en rusttijden van de huidige sessie naar een leesvenster;

  • ritgegevens van de huidige sessie naar een uitvoerinterface voor een printer;

  • arbeids-, rij- en rusttijden van de huidige sessie naar een uitvoerinterface voor een printer;

• Chauffeurskaart:

  • eigen ritgegevens naar een leesvenster;

  • eigen arbeids-, rij- en rusttijden naar een leesvenster;

  • eigen arbeids-, rij- en rusttijden naar de chauffeurskaart;

  • eigen ritgegevens naar een uitvoerinterface voor een printer;

  • eigen arbeids-, rij- en rusttijden naar een uitvoerinterface voor een printer.

• Inspectiekaart: alle gegevens met uitzondering van positiegegevens en beveiligingsgegevens,

  • naar een leesvenster;

  • naar een uitvoerinterface voor een printer;

  • naar een extern handhavingsmiddel of externe gegevensdrager overbrengen.

• Keuringskaart: alle gegevens met uitzondering van positiegegevens en beveiligingsgegevens,

  • naar een leesvenster;

  • naar een uitvoerinterface voor een printer;

  • naar een extern kalibratiemiddel of externe gegevensdrager overbrengen.

• Keuringskaart, na actieve handeling gevolgd door Inspectiekaart: de positiegegevens naar een extern handhavingsmiddel of externe gegevensdrager overbrengen.

• Ondernemerskaart: alle gegevens vastgelegd in de bedrijfsvergrendeling voor de desbetreffende ondernemer met uitzondering van positiegegevens en beveiligingsgegevens,

  • naar een leesvenster;

  • naar een uitvoerinterface voor een printer;

  • naar een extern bedrijfsmiddel of externe gegevensdrager overbrengen.

P.DEACTIVERING

De TOE kan met behulp van een keuringskaart worden gedeactiveerd. Alle gegevens opgeslagen op de TOE tijdens de deactivering worden overgebracht naar een externe gegevensdrager met uitzondering van positiegegevens. Positiegegevens kunnen alleen worden overgebracht naar externe gegevensdrager(s) of externe inrichtingen als er tijdens P.DEACTIVERING op de TOE wordt aangemeld met achtereenvolgens S.KEURINGSKAART als S.INSPECTIEKAART.

Artikel 4.2 Aannames³

A.BEDIENING

Er wordt verondersteld dat de bestuurder van de auto de TOE juist bedient en correct het werkingsniveau, de beladingtoestand en het moment van aanvang en beëindiging van een rit selecteert.

A.SENSOREN

Er wordt verondersteld dat de gegevens aangeboden op de sensorinterface(s) correct zijn.

A.SYSTEEMKAART

Er wordt verondersteld dat de systeemkaart

• een certificaat bevat welk onweerlegbaar is gekoppeld met de TOE;

• alle gegevens die door de TOE worden aangeboden correct ondertekent;

• de handtekening terugstuurt naar de TOE.

A.BOORDCOMPUTERKAART

Er wordt verondersteld dat een ingebrachte boordcomputerkaart

• een certificaat bevat welk onweerlegbaar is gekoppeld met de boordcomputerkaarthouder;

• alle gegevens die door de TOE worden aangeboden correct ondertekent;

• de handtekening terugstuurt naar de TOE.

A.BOORDCOMPUTERKAARTHOUDER

Er wordt verondersteld dat boordcomputerkaarthouders hun boordcomputerkaart niet aan derden uitreiken en hun PIN-code geheim houden.

A.PRINTER

Er wordt verondersteld dat gegevens die worden aangeboden ten behoeve van een aangesloten printer, correct worden afgedrukt door die printer.

A. VOOR_ACTIVERING

De TOE wordt in inactieve toestand geleverd aan voertuigfabrikanten, installateurs en/of erkende werkplaatsen. Deze zullen de TOE installeren waarna een erkende werkplaats de TOE zal kalibreren en vervolgens activeren.

Voertuigfabrikanten, installateurs en/of erkende werkplaatsen zullen de integriteit van de TOE beschermen totdat de TOE is geactiveerd.

Artikel 5 Beveiligingsdoelstellingen

Artikel 5.1 Beveiligingsdoelen voor de TOE

OT.AUDIT

De TOE legt beveiligingsrelevante gebeurtenisgegevens vast en toont deze op het beeldscherm.

OT.AUTHENTICATIE_BOORDCOMPUTERKAART

De TOE zal een ingebrachte boordcomputerkaart authenticeren door middel van zowel:

• een door de eigenaar van de boordcomputerkaart in te brengen PIN;

• een op de boordcomputerkaart aanwezig certificaat.

OT.VASTLEGGEN

De TOE legt gegevens vast volgens de regels van P.VASTLEGGEN en zodanig dat de geregistreerde gegevens een correcte afspiegeling zijn van de waarden aangeboden op de sensorinterface(s).

OT.KOPPELEN_AAN_SYSTEEMKAART

De TOE zal gegevens die geregistreerd dienen te worden aan de systeemkaart aanbieden ter ondertekening met een elektronische handtekening.

OT.KOPPELEN_AAN_BOORDCOMPUTERKAART

De TOE zal arbeids-, rij- en rusttijden van de bestuurder die geregistreerd dienen te worden, aan de chauffeurskaart aanbieden ter ondertekening met een elektronische handtekening.

OT.OPSLAAN

De TOE zal gegevens die geregistreerd dienen te worden opslaan. De gegevens zullen gezamenlijk worden opgeslagen met de elektronische handtekeningen over deze gegevens.

OT.UITVOEREN_GEGEVENS

De TOE kan geregistreerde gegevens uitvoeren volgens de regels van P.UITVOEREN_GEGEVENS. Tenzij gegevens worden uitgevoerd naar printer of leesvenster worden de bij de gegevens opgeslagen elektronische handtekeningen eveneens uitgevoerd.

OT.FYSIEKE_BEVEILIGING

De TOE biedt fysieke weerstand zodanig dat het openmaken van de TOE in een laboratorium kan worden vastgesteld.

OT.BEWAKING_INTEGRITEIT

De TOE zal de integriteit van de gegevens ten minste bewaken door:

• Het testen van de integriteit van opgeslagen gegevens bij het opstarten van de TOE (O.SYSTEEMGEGEVENS), op verzoek van een gebruiker of bij het overbrengen van gegevens;

• Het testen van de correcte werking van de TOE en de S.SYSTEEMKAART bij het opstarten van de TOE of op verzoek van een gebruiker.

Artikel 5.2 Beveiligingsdoelen voor de omgeving

OE.VOOR_ACTIVERING

De TOE wordt in inactieve toestand geleverd aan voertuigfabrikanten, installateurs en/of erkende werkplaatsen. Deze zullen de TOE installeren waarna een erkende werkplaats de TOE zal kalibreren en vervolgens activeren.

Voertuigfabrikanten, installateurs en/of erkende werkplaatsen zullen de integriteit van de TOE beschermen totdat de TOE is geactiveerd.

OE.SENSOREN

De omgeving van de TOE dient ervoor zorg te dragen dat de gegevens die worden aangeboden op de sensorinterface(s) correct zijn. Dit kan bijvoorbeeld door:

• correcte installatie van TOE en sensoren in het voertuig;

• controle van het voertuig op manipulatie van sensoren en/of aansluiting.

OE.PRINTER

De omgeving van de TOE dient ervoor zorg te dragen dat de gegevens die worden aangeboden door de TOE aan de printer correct worden afgedrukt. Dit kan bijvoorbeeld door:

• correcte installatie van TOE en printer in het voertuig;

• controle van het voertuig op manipulatie van printer en/of aansluiting.

OE.BEDIENING

De omgeving van de TOE dient ervoor zorg te dragen dat de bestuurder van de auto correct gebruik maakt van de mogelijkheden om het werkingsniveau, de beladingtoestand, het begin en einde van een rit en de aanvang en einde van de dienst te selecteren. Dit kan bijvoorbeeld door:

• handleidingen en instructies;

• opleiding en training;

• ergonomisch ontwerp van de TOE en montage in de auto.

OE.SYSTEEMKAART

De omgeving van de TOE dient een systeemkaart te bevatten die:

• een certificaat bevat welk onweerlegbaar is gekoppeld met de TOE;

• alle gegevens die door de TOE worden aangeboden correct ondertekent;

• de handtekening terugstuurt naar de TOE.

OE.BOORDCOMPUTERKAART

De omgeving van de TOE dient boordcomputerkaarten te bevatten die:

• een certificaat bevat welk onweerlegbaar is gekoppeld met de boordcomputerkaarthouder;

• alle gegevens die door de TOE worden aangeboden correct te ondertekent;

• de handtekening terugstuurt naar de TOE.

OE.BOORDCOMPUTERKAARTHOUDER

Boordcomputerkaarthouders dienen hun boordcomputerkaart niet aan derden uit te reiken en hun PIN-code geheim te houden. Bestuurders mogen maar één geldige chauffeurskaart in hun bezit hebben.

OE.DEACTIVERING

De TOE wordt buiten gebruik gesteld (deactivering) door erkende werkplaatsen. De opgeslagen gegevens worden hierbij verwijderd met uitzondering van O.SYSTEEMGEGEVENS en O.POSITIEGEGEVENS.

Artikel 6 Functionele beveiligingseisen

De functionele beveiligingseisen zijn verdeeld in een aantal functionele groepen. Iedere groep bevat één of meer onderling samenhangende eisen. De groepen zijn:

• Beveiligingsrollen: Deze definiëren de verschillende rollen en modussen van de TOE, en hoe deze rollen worden aangenomen.

• Identificatie en Authenticatie: Deze definiëren hoe boordcomputerkaarten en andere randapparatuur worden geïdentificeerd en waar nodig geauthenticeerd.

• BCT-toegangsbeleid: Hier wordt beschreven wat wordt vastgelegd, en wie daar wat mee mag doen.

• Handtekeningen: Hier wordt beschreven hoe handtekeningen worden gevraagd aan Systeemkaart en Boordcomputerkaart

• Beveiligingsaudit: Hier wordt beschreven hoe welke systeemgebeurtenissen worden geregistreerd en hoe deze zijn beschermd

• Bescherming van de BCT: Hier wordt beschreven hoe de fysieke beveiliging van de BCT werkt en hoe de integriteit wordt gewaarborgd.

Artikel 6.1 Beveiligingsrollen

FMT_SMR.2 Restricties op gebruikersrollen

FMT_SMR.2.1 De TSF kent de volgende gebruikersrollen:

• BESTUURDER

• TOEZICHTHOUDER

• WERKPLAATS

• VERVOERDER

• ONBEKEND

FMT_SMR.2.2 De TSF kan rollen met gebruikers associëren

FMT_SMR.2.3 De TSF zal de volgende regels afdwingen:

• De rol BESTUURDER wordt aangenomen (en de werkingsmodus wordt Operationele Modus Arbeidstijd) als S.CHAUFFEURSKAART is ingebracht en geauthenticeerd, of als geen S.BOORDCOMPUTERKAART is ingebracht en de gebruiker met het burgerservicenummer is ge-identificeerd.

• De rol TOEZICHTHOUDER wordt aangenomen (en de werkingsmodus wordt Controle Modus) als S.INSPECTIEKAART is ingebracht en geauthenticeerd

• De rol WERKPLAATS wordt aangenomen (en de werkingsmodus wordt Activerings/Keuringsmodus) als S.KEURINGSKAART is ingebracht en geauthenticeerd

• De rol VERVOERDER wordt aangenomen (en de werkingsmodus wordt Bedrijfsmodus) als S.ONDERNEMERSKAART is ingebracht en geauthenticeerd

• De rol ONBEKEND wordt aangenomen (en de werkingsmode wordt Operationele Modus Basis) als:

• Geen kaart is ingebracht en de gebruiker heeft zich niet met burgerservicenummer ge-identificeerd

• Wel een kaart is ingebracht maar de authenticatie faalt

Artikel 6.2 Identificatie en Authenticatie

FIA_UID.1 Tijd van identificatie (Boordcomputerkaarten)

FIA_UID.1.1 De TSF staat het registreren van de O.POSITIEGEGEVENS, en O.GEBEURTENISGEGEVENS namens de gebruikersrol ONBEKEND toe, voordat een gebruiker is geïdentificeerd.

FIA_UID.1.2 De TSF eist dat S.CHAUFFEURSKAART, S.INSPECTIEKAART, S.KEURINGSKAART, en S.ONDERNEMERSKAART succesvol zijn geïdentificeerd op basis van de identiteit weergegeven in het certificaat op die boordcomputerkaart, alvorens andere handelingen te verrichten namens de desbetreffende gebruiker.

FIA_UAU.1 Tijd van authenticatie (Boordcomputerkaarten)

FIA_UAU.1.1 De TSF staat het registreren van de O.BASISGEGEVENS, O.ARBEIDSTIJDGEGEVENS, O.RITGEGEVENS, O.POSITIEGEGEVENS, O.BEWEGINGSGEGEVENS en O.GEBEURTENISGEGEVENS namens de gebruikersrol ONBEKEND toe, voordat een gebruiker is geauthenticeerd.

FIA_UAU.1.2 De TSF eist dat S.CHAUFFEURSKAART, S.INSPECTIEKAART, S.KEURINGSKAART en S.ONDERNEMERSKAART succesvol zijn geauthenticeerd op basis van:

• Een minimaal 4 karakter lange PIN (deze authenticatie wordt door S.CHAUFFEURSKAART, S.INSPECTIEKAART, S.KEURINGSKAART en S.ONDERNEMERSKAART uitgevoerd en het resultaat wordt door deze aan de TSF gerapporteerd), en

• Verificatie van het certificaat op de boordcomputerkaart.

FIA_AFL.1 Falen van authenticatie (FIA_AFL)

FIA_AFL.1.1 De TSF detecteert wanneer vijf (5) opeenvolgende niet-succesvolle authenticatiepogingen plaatsvinden gerelateerd aan het authenticeren van dezelfde S.CHAUFFEURSKAART, S.INSPECTIEKAART, S.KEURINGSKAART of S.ONDERNEMERSKAART

FIA_AFL.1.2 Als er vijf (5) opeenvolgende niet-succesvolle authenticatiepogingen zijn gedetecteerd, dan zal de TSF:

• een gebeurtenis genereren ;

• de gebruiker waarschuwen;

• aannemen dat de gebruikersrol ONBEKEND is.

FIA_UAU.6 Herauthenticeren

FIA_UAU.6.1 De TSF zal S.CHAUFFEURSKAART, S.INSPECTIEKAART, S.KEURINGSKAART en S.ONDERNEMERSKAART herauthenticeren onder de volgende condities:

• bij het plaatsen van een elektronische handtekening door een boordcomputerkaart;

• bij het invoeren van de boordcomputerkaart;

• bij het opheffen van een geblokkeerde kaartsessie;

• bij herstel van de stroomvoorziening na een onderbreking

FTA_SSL.2 Blokkeren van een sessie op initiatief van een gebruiker

FTA_SSL.2.1 De TSF zal S.BOORDCOMPUTERKAART toestaan een sessie te blokkeren door het uitnemen van S.BOORDCOMPUTERKAART zonder dat is aangegeven dat de sessie van de gebruiker is beëindigd en als de auto zich in de toestand stilstaan bevindt door middel van:

• het wissen van het scherm

• het blokkeren van alle invoerapparatuur behalve die benodigd is voor het opheffen van de blokkering

FTA_SSL.2.2 De TSF eist dat de volgende handelingen plaatsvinden alvorens de blokkering op te heffen:

• het opnieuw inbrengen van dezelfde S.CHAUFFEURSKAART waarvoor de kaartsessie is geblokkeerd.

FTA_SSL.3 Automatisch beëindigen van een sessie

FTA_SSL.3.1 De TSF beëindigt een kaartsessie:

• als een geblokkeerde S.CHAUFFEURSKAART sessie niet binnen 60 minuten wordt hervat;

• meteen als een andere S.BOORDCOMPUTERKAART wordt ingebracht dan waarvoor de TSF is geblokkeerd, tenzij

  • de TSF in de toestand P.DEACTIVERING is geplaatst door een S.KEURINGSKAART waarna een S.INSPECTIEKAART wordt aangeboden, of

  • in de Operationele Modus Arbeidstijd of Operationele Modus Taxivervoer een S.INSPECTIEKAART wordt aangeboden;

• als in een sessie van een S.ONDERNEMERSKAART, S.INSPECTIEKAART of S.KEURINGSKAART gedurende 5 minuten geen handelingen aan de TSF verricht.

FIA_UID.2 Identificatie voor enige actie (Systeemkaart)

FIA_UID.2.1 De TSF identificeert S.SYSTEEMKAART op basis van de identiteit weergegeven in het machine-gebonden certificaat zoals vastgelegd op de systeemkaart verbonden met de TOE, alvorens handelingen te verrichten namens S.SYSTEEMKAART.

FIA_UID.2 Identificatie voor enige actie (Overigen)

FIA_UID.2.1 De TSF identificeert S.BEWEGINGSOPNEMER, S.POSITIEBEPALINGSSENSOR, S.PRINTER, S.TAXAMETER, S.HANDHAVINGSMIDDELEN, S.KALIBRATIEMIDDELEN EN S.BEDRIJFSMIDDELEN op basis van hun aanwezigheid op de daarvoor bestemde interface, alvorens handelingen te verrichten namens de desbetreffende subjecten.

Artikel 6.3 BCT-toegangsbeleid

FDP_ACC.2 Volledige toegangscontrole

FDP_ACC.2.1 De TSF dwingt het toepassen van het BCT-toegangsbeleid af voor alle subjecten, alle objecten en alle handelingen⁴.

FDP_ACC.2.2 De TSF garandeert dat alle verrichtingen tussen een subject gecontroleerd door de TSF en een object gecontroleerd door de TSF zijn onderworpen aan een toegangscontrole SFP.

FDP_ACF.1 Toegangscontrole op basis van attributen

FDP_ACF.1.1 De TSF dwingt het toepassen van het BCT-toegangsbeleid af voor objecten voor alle subjecten en alle objecten.

FDP_ACF.1.2 De TSF dwingt de volgende regels af om te bepalen of een verrichting tussen gecontroleerde subjecten en gecontroleerde objecten is toegestaan:

• TSF zal:

  • Altijd O.BEWEGINGSGEGEVENS inlezen, samenvatten, en samen met de tijd⁵ en de gegevens betreffende verplaatsing beschikbaar stellen als O. BASISGEGEVENS

  • Altijd O.POSITIEGEGEVENS inlezen en vastleggen;

  • O.ARBEIDSTIJDGEGEVENS vastleggen in Operationele Modus Arbeidstijd en Operationele Modus Taxivervoer;

  • O.RITGEGEVENS vastleggen in Operationele Modus Taxivervoer.

  NB: Als gegevens worden vastgelegd dan is dat inclusief de elektronische handtekening⁶

• BESTUURDER mag:

  • de eigen O.RITGEGEVENS en O.KAARTHOUDERGEGEVENS tonen op een leesvenster;

  • O.ARBEIDSTIJDENGEGEVENS opslaan op de S.CHAUFFEURSKAART;

  • O.ARBEIDSTIJDENGEGEVENS van de S.CHAUFFEURSKAART overbrengen naar de TOE;

  • O.RITGEGEVENS en O.KAARTHOUDERGEGEVENS uitvoeren naar S.PRINTER.

• TOEZICHTHOUDER mag alle O.BASISGEGEVENS, O.ARBEIDSTIJDENGEGEVENS, O.RITGEGEVENS, O.BEDRIJFSGEGEVENS, O.KAARTHOUDERGEGEVENS, O.GEBEURTENISGEGEVENS en O.SYSTEEMGEGEVENS

  • tonen op een leesvenster;

  • uitvoeren naar S.PRINTER;

  • uitvoeren naar S.HANDHAVINGSMIDDELEN of externe gegevensdragers.

• TOEZICHTHOUDER mag, mits de TOE is gedeactiveerd, O.POSITIEGEGEVENS

  • uitvoeren naar S.HANDHAVINGSMIDDELEN of externe gegevensdragers.

• WERKPLAATS mag de TOE deactiveren.

• WERKPLAATS mag O.SYSTEEMGEGEVENS aanpassen

• WERKPLAATS mag alle O.BASISGEGEVENS, O.RITGEGEVENS, O.ARBEIDSTIJDENGEGEVENS, O.BEDRIJFSGEGEVENS, O.KAARTHOUDERGEGEVENS, O.GEBEURTENISGEGEVENS en O.SYSTEEMGEGEVENS

  • tonen op een leesvenster;

  • uitvoeren naar S.PRINTER;

  • uitvoeren naar S.KALIBRATIEMIDDELEN of externe gegevensdragers.

• VERVOERDER mag alle O.BASISGEGEVENS, O.ARBEIDSTIJDENGEGEVENS, O.RITGEGEVENS, O.BEDRIJFSGEGEVENS, O.KAARTHOUDERGEGEVENS, O.GEBEURTENISGEGEVENS en O.SYSTEEMGEGEVENS geregistreerd gedurende de periode dat de TSF voor de desbetreffende vervoerder is vergrendeld of vergrendeld geweest (bedrijfsvergrendeling)

  • tonen op een leesvenster;

  • uitvoeren naar S.PRINTER;

  • uitvoeren naar S.BEDRIJFSMIDDELEN of externe gegevensdragers.

FDP_ACF.1.3 –⁷

FDP_ACF.1.4 De TSF zal expliciet toegang van subjecten naar objecten weigeren gebaseerd op de volgende regel:

• Alle niet in FDP_ACF.1.2 genoemde toegang is niet toegestaan

FDP_ETC.2 Export van gegevens met attributen

FDP_ETC.2.1 De TSF dwingt het gebruik van het BCT-toegangsbeleid af wanneer O.BASISGEGEVENS, O.ARBEIDSTIJDENGEGEVENS, O.RITGEGEVENS, O.POSITIEGEGEVENS, O.BEDRIJFSGEGEVENS, O.GEBEURTENISGEGEVENS en O.SYSTEEMGEGEVENS gegevens worden overgebracht naar externe gegevensdragers of inrichtingen buiten de TSF.

FDP_ETC.2.2 De TSF exporteert gegevens inclusief de bijbehorende elektronische handtekening over deze gegevens, behalve als deze naar S.PRINTER of het leesvenster worden geexporteerd.

FDP_ETC.2.3 De TSF garandeert dat de elektronische handtekening onlosmakelijk is geassocieerd met de geëxporteerde gegevens.

FDP_ETC.2.4 De TSF dwingt de volgende regels af wanneer gegevens worden geëxporteerd van de TSF:

• De TSF handhaaft de rangschikking van gegevens (berichtvolgorde) bij gegevensoverdracht naar externe gegevensdragers of inrichtingen;

FDP_ITC.1 Import van gegevens zonder attributen

FDP_ITC.1.1 De TSF dwingt het gebruik van het BCT-toegangsbeleid af wanneer gegevens worden ingelezen van S.BOORDCOMPUTERKAARTEN, S.BEWEGINGSOPNEMER, S.POSITIEBEPALINGSSENSOR, S.HANDHAVINGSMIDDELEN, S.KALIBRATIEMIDDELEN, S.BEDRIJFSMIDDELEN of S.TAXAMETER.

FDP_ITC.1.2 De TSF negeert attributen wanneer gegevens worden ingelezen door de TSF.

FDP_ITC.1.3 De TSF dwingt de volgende regels af wanneer gegevens worden ingelezen door de TSF:

• De TSF verwerkt gegevens alleen wanneer deze afkomstig zijn van:

  • de interne tijdklok van de TSF;

  • de interne verplaatsingsopnemer van de TSF;

  • contact signaal (ignition sense);

  • invoer door de gebruiker via het bedieningspaneel;

  • S.BEWEGINGSOPNEMER;

  • S.POSITIEBEPALINGSSENSOR;

  • S.BOORDCOMPUTERKAARTEN;

  • S.SYSTEEMKAART;

  • S.TAXAMETER.

Artikel 6.4 Handtekeningen

FDP_DAU.2 Data authenticatie met identiteit

FDP_DAU.2.1 De TSF kan een bewijs van de validiteit van gegevens genereren als volgt:

• Een hash van O.RITGEGEVENS wordt ondertekend door de S.SYSTEEMKAART over de volledige set van desbetreffende O.RITGEGEVENS direct bij het registreren van deze gegevens per individuele rit;

• Een hash van O.ARBEIDSTIJDGEGEVENS wordt ondertekend door S.CHAUFFEURSKAART direct bij het registreren van deze gegevens bij het beëindigen van de dienst van de bestuurder of het afsluiten van de kaartsessie;

• Een hash van O.ARBEIDSTIJDGEGEVENS wordt ondertekend door S.SYSTEEMKAART direct bij het registreren van deze gegevens indien de S.CHAUFFEURSKAART niet beschikbaar is;

• Een hash van alle gegevens overgebracht naar S.HANDHAVINGSMIDDELEN, S.BEDRIJFSMIDDELEN, S.KALIBRATIEMIDDELEN of externe gegevensdragers wordt ondertekend door de S.SYSTEEMKAART op het moment van de overdracht;

• Hashes van alle geregistreerde O.BASISGEGEVENS, O.ARBEIDSTIJDENGEGEVENS, O.RITGEGEVENS, O.POSITIEGEGEVENS, O.BEDRIJFSGEGEVENS en O.GEBEURTENISGEGEVENS worden ondertekend door S.SYSTEEMKAART.

FDP_DAU.2.2 De TSF levert S.BOORDCOMPUTERKAART een mogelijkheid om het bewijs van de integriteit en authenticiteit van de gegevens en de identiteit van de gebruiker die de gegevens heeft ondertekend te verifiëren.

FTP_ITC.1 Vertrouwd kanaal tussen TSFs

FTP_ITC.1.1 De TSF levert een communicatiekanaal tussen de TSF en de S.SYSTEEMKAART. Dit communicatiekanaal is gescheiden van andere communicatiekanalen, levert zekere identificatie van de eindpunten, en beschermt de data op het kanaal tegen wijzigen of lekken.

FTP_ITC.1.2 De TSF mag alleen zelf communicatie initiëren over het vertrouwde kanaal.

FTP_ITC.1.3 De TSF zal communicatie initiëren over het vertrouwde kanaal voor het door S.SYSTEEMKAART laten zetten van handtekeningen en het ontvangen van deze handtekeningen.

FCS_COP.1 Cryptografische operaties

FCS_COP.1.1 De TSF zal hash-operaties uitvoeren volgens zowel het SHA-1 en het SHA-256 cryptografische algoritme zoals gedefinieerd in de ISO/IEC 10118-3, FIPS PUB 180-2 en ETSI TS 102 176-1 standaarden.

Artikel 6.5 Beveiligingsaudit

FAU_GEN.1 Genereren van gebeurtenisgegevens⁸

FAU_GEN.1.1 De TSF genereert een gebeurtenis record van de volgende gebeurtenissen:

• het aanzetten van de TOE;

• het uitzetten van de TOE;

• het optreden van storingen⁹ in de werking van de TSF;

  • a. een storing in de werking van de registratiefunctie;

  • b. een storing in de werking van de beveiligingsfuncties;

  • c. een storing in de werking van de sensoren;

  • d. een storing in de overbrenging naar een externe interface

  • e. een storing in de werking van de systeemkaart;

  • f. een storing in de werking van de boordcomputerkaarten.

• het optreden van fouten¹⁰ in de werking van de TSF;

  • a. een integriteitfout in de uitvoercode;

  • b. een integriteitfout in de systeemgegevens;

  • c. een integriteitfout in de opgeslagen gebruikersgegevens;

  • d. een integriteitfout bij de gegevensuitvoer naar de chauffeurskaart;

  • e. een fout in de registratiefunctie;

  • f. een fout die de beveiliging van de boordcomputer in gevaar brengt;

  • g. een fout bij de gegevensuitvoer naar externe inrichtingen;

  • h. een fout bij het gebruik van de systeemkaart;

  • i. een fout bij het gebruik van de boordcomputerkaart;

  • j. een fout in de bewegingsensor;

  • k. een fout in de positiebepalingsensor;

  • l. een fout in de koppeling met de taxameter.

• het inbrengen van S.BOORDCOMPUTERKAART;

• het uitnemen van S.BOORDCOMPUTERKAART;

• het inbrengen van een ongeldige S.BOORDCOMPUTERKAART;

• het inbrengen van een S.CHAUFFEURSKAART waarvan blijkt dat de datum en het tijdstip van de laatste registratie op S.CHAUFFEURSKAART op een later tijdstip valt dan de actuele datum en tijdstip volgens de tijdwaarneming van de TSF;

• het niet juist afsluiten van de kaartsessie;

• het inbrengen van S.CHAUFFEURSKAART waarvan blijkt dat de laatste kaartsessie niet juist is afgesloten;

• het ontstaan van onvoldoende opslagcapaciteit;

• het verdwijnen van onvoldoende opslagcapaciteit;

• het ontstaan van onvoldoende opslagcapaciteit op de S.CHAUFFEURSKAART;

• het verdwijnen van onvoldoende opslagcapaciteit op de S.CHAUFFEURSKAART;

• het ontstaan van een onderbreking van ten minste 5 seconden in de stroomvoorziening van de TOE;

• het verdwijnen van een onderbreking van ten minste 5 seconden in de stroomvoorziening van de TOE;

• het begin van een periode waarin de contactgeschakelde voedingsbron is uitgeschakeld in de toestand rijden;

• het einde van een periode waarin de contactgeschakelde voedingsbron is uitgeschakeld in de toestand rijden;

• het vaststellen van een toestand verplaatsen door de verplaatsingsopnemer van de TOE wanneer er geen O.BEWEGINGSGEGEVENS van de S.BEWEGINGSOPNEMER worden verkregen;

• het begin van het niet kunnen verkrijgen van O.POSITIEGEGEVENS gedurende 5 minuten;

• het einde van het niet kunnen verkrijgen van O.POSITIEGEGEVENS gedurende 5 minuten;

• een afwijking van meer dan twee procent tussen de, met behulp van O.BEWEGINGSGEGEVENS en de constante van de boordcomputer in de O.SYSTEEMGEGEVENS, berekende afstand en de werkelijke afstand;

• een afwijking van meer dan drie procent tussen de O.BEWEGINGSGEGEVENS en de O.POSITIEGEGEVENS;

• het ontstaan van een onderbreking in de koppeling met S.TAXAMETER;

• het verdwijnen van een onderbreking in de koppeling met S.TAXAMETER;

• het overbrengen van gegevens inclusief de naam van de gebruikte interface;

• het activeren van de TSF;

• het keuren van de TSF;

• het deactiveren van de TSF;

• het vergrendelen van de TSF;

• het inschakelen van een werkingsmodus inclusief naam werkingsmodus;

• het uitschakelen van een werkingsmodus inclusief naam werkingsmodus;

• het begin van rijden in de operationele modus werkingsniveau taxivervoer zonder S.CHAUFFEURSKAART;

• het einde van rijden in de operationele modus werkingsniveau taxivervoer zonder S.CHAUFFEURSKAART;

• het detecteren van een niet-succesvolle authenticatiepoging;

• het installeren van een programmatuurrevisie.

• starten of stoppen van audit- en beveiligingsfuncties;

• het uitblijven of weigeren van een elektronische handtekening door S.CHAUFFEURSKAART of S.SYSTEEMKAART;

• niet-geautoriseerde wijziging van de TSF configuratie;

• toegang tot het gebeurtenissenlogboek.

FAU_GEN.1.2 De TSF legt per gebeurtenis ten minste de volgende informatie vast zoals die geldt op het moment van optreden:

• een automatisch gegenereerd oplopend volgnummer;

• type van de gebeurtenis (de gebeurteniscode);

• de datum en het tijdstip als gecoördineerde wereldtijd;

• de kilometerstand;

• de verplaatsingstoestand van de auto (rijden/stilstaan);

• de werkingsmodus en werkingsniveau van de TOE;

• waar relevant, de uitkomst van de gebeurtenis;

• waar relevant, aanvullende relevante informatie;

als een storing of fout is opgetreden tevens:

• de gebeurteniscode van de aanleiding voor de storing of fout;

als een S.BOORDCOMPUTERKAART is ingebracht in de TSF tevens:

• het kaartnummer en kaartsoort;

• de gebruikeridentificatiecode;

als geen S.BOORDCOMPUTERKAART is ingebracht, maar de gebruiker is geïdentificeerd met een burgerservicenummer:

• het burgerservicenummer.

FAU_ARP.1 Automatische respons op gebeurtenissen

FAU_ARP.1.1 De TSF geeft een waarschuwingsignaal op het leesvenster wanneer een gebeurtenis wordt gedetecteerd.

FAU_STG.1 Bescherming van gebeurtenisgegevens

FAU_STG.1.1 De TSF beschermt de opgeslagen gebeurtenis records in O.GEBEURTENISGEGEVENS tegen ongeautoriseerd verwijderen.

FAU_STG.1.2 De TSF voorkomt ongeautoriseerde aanpassingen in de opgeslagen gebeurtenis records in O.GEBEURTENISGEGEVENS.

FAU_STG.4 Voorkomen van verlies van gebeurtenisgegevens

FAU_STG.4.1 De TSF overschrijft de oudste gebeurtenis records met nieuwere wanneer de opslagcapaciteit voor de O.GEBEURTENISGEGEVENS vol is.

FRU_RSA.2 Maximum en minimum quotas

FRU_RSA.2.1 –¹¹

FRU_RSA.2.2 De TSF garandeert een minimum hoeveelheid opslagcapaciteit voldoende voor 365 dagen van normaal gebruik tegelijkertijd te gebruiken voor:

• O.BASISGEGEVENS;

• O.RITGEGEVENS;

• O.POSITIEGEGEVENS;

• O.BEDRIJFSGEGEVENS;

• O.GEBEURTENISGEGEVENS;

FPT_STM.1 Tijd

FPT_STM.1.1 De TSF is in staat om betrouwbare tijdsregistraties uit te voeren in de Universal Time Coordinated met een afwijking van ten hoogste één (1) seconde en een resolutie van één (1) seconde of nauwkeuriger.

Artikel 6.6 Bescherming van de BCT

FPT_PHP.1 Passieve detectie van fysieke aanvallen

FPT_PHP.1.1 De TSF zal een laboratorium in staat stellen om fysieke aanvallen ondubbelzinnig te detecteren¹².

FPT_PHP.1.2 De TSF zal het mogelijk maken om te bepalen dat fysieke aanvallen op de TSF, de S.SYSTEEMKAART of de verbinding tussen TSF en de S.SYSTEEMKAART hebben plaatsgevonden.

FPT_TST.1 Testen van de TSF

FPT_TST.1.1 De TSF zal een verzameling zelf-testen doen bij het opstarten om de correcte werking van de TSF te demonstreren.

FPT_TST.1.2 De TSF zal TOEZICHTHOUDER, WERKPLAATS en VERVOERDER de mogelijkheden bieden om de integriteit van de TSF data te verifiëren.

FPT_TST.1.3 De TSF zal TOEZICHTHOUDER, WERKPLAATS en VERVOERDER de mogelijkheden bieden om de integriteit van de TSF uitvoerbare programmatuurcode (executables) te verifiëren.

Artikel 7 Garantieniveau

Voor de typegoedkeuring van de boordcomputer wordt een Common Criteria garantieniveau vereist van ten minste EAL3. Dit niveau analyseert de geclaimde beveiligingsfuncties door middel van een analyse van functionele en interface specificatie, (gebruikers)documentatie en een beschrijving van de architectuur van de boordcomputer. De analyse wordt ondersteund met onafhankelijk testen, verificatie van de testresultaten van de ontwikkelaar een beperkt onderzoek naar zwakheden. Daarnaast worden aspecten van de gebruikte ontwerpmiddelen, configuratiebeheer en leveringsprocedures beschouwd.

In combinatie met een uitgebreid en formeel geëvalueerd beveiligingsprofiel (Protection Profile), een periodiek onderzoek en actieve handhaving, kan aannemelijk worden gemaakt dat goedgekeurde boordcomputers voldoende weerstand zullen bieden tegen de onderkende dreigingen en dat gebrekkig functionerende boordcomputers kunnen worden opgespoord.

Artikel 8 Rationale

Artikel 8.1 Beveiligingsdoelstellingen

Deze sectie bevat een uitleg dat de beveiligingsdoelstellingen het gehele beveiligingsprobleem adresseren. Dit beveiligingsprobleem bestaat uit drie delen:

• Dreigingen: Dit profiel bevat geen dreigingen, dus er is ook geen uitleg

• Beveiligingsbeleid: Zie sectie 8.1.1

• Aannames: Zie sectie 8.1.2

Artikel 8.1.1 Beveiligingsbeleid

Deze sectie bevat een uitleg dat de beveiligingsdoelstellingen alle delen van het beveiligingsbeleid implementeren.

P.VASTLEGGEN

Deze wordt direct ondervangen door OT.VASTLEGGEN. Daarnaast vindt indirecte ondersteuning plaats door OT.FYSIEKE_BEVEILIGING.

P.BEWAREN_EN_BORGEN

Het bewaren van de gegevens wordt ondervangen door:

• OT.OPSLAAN, wat de gegevens en alle elektronische handtekeningen opslaat.

Het detecteren van de wijzigingen in de vastgelegde gegevens wordt ondervangen door:

• Het aanbieden van de gegevens aan de systeemkaart (OT.KOPPELEN_AAN_SYSTEEMKAART) en het door deze ondertekenen van de gegevens (OE.SYSTEEMKAART);

• Het aanbieden van gegevens aan de boordcomputerkaart (OT.KOPPELEN_AAN_BOORDCOMPUTERKAART) en het door deze ondertekenen van de gegevens (OE.BOORDCOMPUTERKAART).

Het onweerlegbaar koppelen aan de TOE wordt ondervangen door:

• Het aanbieden van de gegevens aan de systeemkaart (OT.KOPPELEN_AAN_SYSTEEMKAART) en het door deze ondertekenen van de gegevens (OE.SYSTEEMKAART);

• Dat de systeemkaart een certificaat bevat welk onweerlegbaar is gekoppeld aan de TOE (OE.SYSTEEMKAART).

Het onweerlegbaar koppelen aan de boordcomputerkaarthouder wordt ondervangen door:

• Het aanbieden van gegevens aan de boordcomputerkaart (OT.KOPPELEN_AAN_BOORDCOMPUTERKAART) en het door deze ondertekenen van de gegevens (OE.BOORDCOMPUTERKAART);

• Dat de boordcomputerkaart een certificaat bevat welk onweerlegbaar is gekoppeld aan de boordcomputerkaarthouder (OE.BOORDCOMPUTERKAART);

• Dat de boordcomputerhouder zich authenticeert met een PIN bij het insteken van de kaart (OT.AUTHENTICATIE_BOORDCOMPUTERKAART);

• Dat de boordcomputerhouder zijn kaart veilig bewaart en zijn PIN geheim houdt. (OE.BOORDCOMPUTERKAARTHOUDER).

Daarnaast vindt indirecte ondersteuning plaats door OT.FYSIEKE_BEVEILIGING, OT.AUDIT en OT.BEWAKING_INTEGRITEIT.

P.ACTIES

Deze wordt direct ondervangen door OT.AUDIT, OT.UITVOEREN_GEGEVENS, OT.AUTHENTICATIE_BOORDCOMPUTERKAART en OE.BEDIENING. Daarnaast vindt indirecte ondersteuning plaats door OT.FYSIEKE_BEVEILIGING en OT.BEWAKING_INTEGRITEIT.

P.UITVOEREN_GEGEVENS

Deze wordt direct ondervangen door OT.UITVOEREN_GEGEVENS, OT.AUTHENTICATIE_BOORDCOMPUTERKAART en OE.BEDIENING. Daarnaast vindt indirecte ondersteuning plaats door OE.PRINTER.

P.DEACTIVERING

Deze wordt direct ondervangen door OE.DEACTIVERING (voor deactivering en verwijderen gegevens) en OT.UITVOEREN_GEGEVENS (voor wat betreft het uitvoeren van gegevens).

Artikel 8.1.2 Aannames

Deze sectie bevat een uitleg dat de beveiligingsdoelstellingen alle aannames implementeren.

A.BEDIENING

Deze wordt direct ondervangen door OE.BEDIENING.

A.SENSOREN

Deze wordt direct ondervangen door OE.SENSOREN.

A.SYSTEEMKAART

Deze wordt direct ondervangen door OE.SYSTEEMKAART.

A.BOORDCOMPUTERKAART

Deze wordt direct ondervangen door OE.BOORDCOMPUTERKAART.

A.BOORDCOMPUTERKAARTHOUDER

Deze wordt direct ondervangen door OE. BOORDCOMPUTERKAARTHOUDER.

A.PRINTER

Deze wordt direct ondervangen door OE.PRINTER.

A. VOOR_ACTIVERING

Deze wordt direct ondervangen door OE.VOOR_ACTIVERING.

Artikel 8.2 Beveiligingsdoelstellingen voor de TOE

OT.AUDIT

Deze wordt gerealiseerd door FAU_GEN.1 wat vastlegt welke gebeurtenisgegevens beveiligingsrelevant zijn, en welke gegevens er daarvoor worden vastgelegd.

Dit wordt ondersteund door:

• FPT_STM.1 die aangeeft dat er een klok is die nauwkeurig de tijd aangeeft (zodat de juiste datum en tijd wordt opgeslagen bij de gebeurtenisgegevens)

• FAU_ARP.1 die aangeeft dat deze gegevens ook allemaal worden getoond op het display

• FAU_STG.1 die aangeeft dat de gegevens niet zo maar kunnen worden verwijderd of veranderd

• FRU_RSA.2 dat vastlegt dat er genoeg opslagruimte moet zijn voor 365 dagen normaal gebruik

• FAU_STG.4 dat vastlegt dat oude gegevens worden overschreven als de opslagruimte vol raakt

OT.AUTHENTICATIE_BOORDCOMPUTERKAART

Deze wordt gerealiseerd door FIA_UID.1 (Boordcomputerkaarten) en FIA_UAU.1 (Boordcomputerkaarten) welke de I&A regels voor boordcomputerkaarten geven

Dit wordt ondersteund door:

• FIA_AFL.1 die aangeeft wat er gebeurd bij falende authenticatie

• FIA_UAU.6 die aangeeft dat er onder sommige omstandigheden nogmaals moet worden geauthenticeerd

• FTA_SSL.2 die tijdelijke blokkade van een sessie toelaat

• FTA_SSL.3 die aangeeft wanneer een sessie wordt afgebroken

OT.VASTLEGGEN

Deze wordt gerealiseerd door FDP_ACC.2 en FDP_ACF.1 die de regels van P.VASTLEGGEN implementeren.

Dit wordt ondersteund door:

• FIA_UID.2 (Overigen) die S.BEWEGINGSSENSOR en S.POSITIEBEPALINGSSENSOR identificeren;

• FDP_ITC.1 die vastlegt dat gegevens mogen worden ingelezen van S.BEWEGINGSSENSOR en S.POSITIEBEPALINGSSENSOR

• FRU_RSA.2 die vastlegt dat er genoeg opslagruimte moet zijn voor 365 dagen normaal gebruik;

OT.KOPPELEN_AAN_SYSTEEMKAART

Deze wordt gerealiseerd door FDP_DAU.2 die het zetten van een handtekening implementeert. Dit wordt ondersteund door:

• FIA_UID.2 (Systeemkaart) die S.SYSTEEMKAART identificeert.

• FCS_COP.1 die een hash genereert (de hash wordt getekend ipv de gegevens)

• FTP_ITC.1 die ervoor zorgdraagt dat de hash niet wordt veranderd voordat deze wordt getekend

• FDP_ACF.1 die specificeert dat de handtekening ook wordt opgeslagen

OT.KOPPELEN_AAN_BOORDCOMPUTERKAART

Deze wordt gerealiseerd door FDP_DAU.2 die het zetten van een handtekening implementeert. Dit wordt ondersteund door:

• FIA_UID.2 (Boordcomputerkaart) die S.BOORDCOMPUTERKAART identificeert.

• FCS_COP.1 die een hash genereert (de hash wordt getekend in plaats van de gegevens)

• FDP_ACF.1 die specificeert dat de handtekening ook wordt opgeslagen

• FMT_SMR.2 die de verschillende rollen specificeert die bij de verschillende boordcomputerkaarten horen

OT.OPSLAAN

Zie OT.VASTLEGGEN, OT.KOPPELEN_AAN_SYSTEEMKAART en OT.KOPPELEN_AAN_BOORDCOMPUTERKAART. Daarnaast wordt dit ondersteund door:

• FRU_RSA.2 die vastlegt dat er genoeg opslagruimte moet zijn voor 365 dagen normaal gebruik

OT.UITVOEREN_GEGEVENS

Deze wordt gerealiseerd door FDP_ACC.2 en FDP_ACF.1 die de regels van P.UITVOEREN_GEGEVENS implementeren. Dit wordt ondersteund door:

• FMT_SMR.2 die de verschillende rollen definieert;

• FIA_UID.1 (Overigen) die de verschillende soorten randapparatuur identificeert waar naar toe kan worden uitgevoerd;

• FDP_ETC.2 die ervoor zorg draagt dat de elektronische handtekening mee wordt uitgevoerd.

OT.FYSIEKE_BEVEILIGING

Deze wordt direct gerealiseerd door FPT_PHP.1.

OT.BEWAKING_INTEGRITEIT

Deze wordt direct gerealiseerd door FPT_TST.1

Artikel 8.3 Afhankelijkheden

De volgende afhankelijkheden zijn niet vervuld:

• FMT_MSA.3 (van FDP_ACF.1 en FDP_ITC.1): aangezien er geen attributen worden gebruikt, hoeven de attributen ook niet te worden geinitialiseerd;

• FDP.ITC.1 of FDP_ITC.2 of FCS_CKM.1 (van FCS.COP.1): aangezien hashing geen sleutels gebruikt, hoeven de sleutels ook niet te worden geïmporteerd of gegenereerd;

• FCS_CKM.4 (van FCS_COP.1): aangezien hashing geen sleutels gebruikt, hoeven de sleutels ook niet te worden vernietigd;

• FAU_SAA.1 (van FAU_ARP.1): aangezien iedere gebeurtenis op het leesvenster wordt getoond, is FAU_SAA niet nodig aangezien deze bedoeld is om selecties/combinaties van gebeurtenissen te maken.

BIJLAGE 2 BIJ DE REGELING SPECIFICATIES EN TYPEGOEDKEURING BOORDCOMPUTER TAXI

Artikel 1 Definities

In deze bijlage wordt verstaan onder:

a. XML:

eXtensible Markup Language;

b. USB:

Universal Serial Bus;

c. ritadministratie.xsd:

XML schema definitie van het resultaatbericht van de gegevenslevering ritadministratie;

d. arbeidstijden.xsd:

XML schema definitie van het resultaatbericht van de gegevenslevering Arbeids-, rij en rusttijden;

e. coordinaten.xsd:

XML schema definitie van het resultaatbericht van de gegevenslevering coördinaten;

f. gebeurtenis.xsd:

XML schema definitie van het resultaatbericht van de gegevenslevering gebeurtenis;

g. onderzoek.xsd:

XML schema definitie van het resultaatbericht van de gegevenslevering onderzoek;

h. chauffeurskaartdata.xsd:

XML schema definitie van het resultaatbericht van de gegevenslevering chauffeurskaartdata.

Artikel 2 Algemeen

Artikel 2.1 Doel

In dit artikel worden de gemeenschappelijke kenmerken beschreven die gelden voor de gegevensleveringen ‘Ritadministratie’, ‘Arbeids-, rij- en rusttijden’, ‘Coördinaten’, ‘Gebeurtenis’, ’Onderzoek’ en ‘Chauffeurskaartdata’.

Artikel 2.2 Hardware koppeling

De overbrengingsinterface die gebruikt wordt voor de gegevensoverbrenging naar een externe gegevensdrager is een USB poort. Er geldt:

• a. de USB poort moet aantoonbaar compliant zijn met de specificaties zoals opgesteld door het USB Implementers Forum, Inc.;

• b. de USB poort is een USB type A connector.

De snelheidseis, als beschreven in artikel 2.3, is leidend bij de keuze van USB 1.1 of hoger. Als de snelheidseis van alle gegevensleveringen (‘Ritadministratie’, ‘Arbeids-, rij- en rusttijden’, ‘Coördinaten’, ‘Gebeurtenis’ ’Onderzoek’ en ‘Chauffeurskaartdata’) beschreven in deze bijlage gehaald kan worden met USB 1.1 (12 Mbit/s) dan is USB 1.1 toegestaan, zo niet dan moet USB 2.0 (480 Mbit/s) of hoger gebruikt worden.

Artikel 2.3 Snelheidseis gegevenslevering

Na opvragen van een gegevenslevering moet het corresponderende XML bericht binnen de volgende termijnen beschikbaar zijn op het externe gegevensdrager:

• Bestand tot 3 Mbyte binnen 10 seconden;

• Voor iedere Mbyte die het bestand groter is kan de termijn met 3 seconden worden vergroot.

Artikel 2.4 Bestandsformaat

Voor externe opslagmedia moet het bestandssysteem FAT32 ondersteund worden.

Artikel 2.5 Overbrengingsprotocol

De boordcomputer fungeert als host en neemt het initiatief voor gegevensoverdracht naar de externe gegevensdrager.

Artikel 2.6 Totstandkoming gegevenslevering

Om een gegevenslevering tot stand te laten komen, stelt de boordcomputer de houder van een boordcomputerkaart in staat om:

• a. zich met de boordcomputerkaart te authenticeren;

• b. de externe gegevensdrager met de overbrengingsinterface van de boordcomputer te verbinden;

• c. op de boordcomputer één of meerdere gegevensleveringen te selecteren. Standaard zijn alle gegevensleveringen waarvoor de gebruiker is geautoriseerd geselecteerd;

• d. op de boordcomputer een periode in te voeren waarover gegevens opgevraagd moeten worden voor de betreffende gegevenslevering(en).

• e. op de boordcomputer de betreffende gegevenslevering(en) over de ingevoerde periode met één gebruikershandeling starten.

Nadat alle geselecteerde gegevensleveringen succesvol zijn afgerond en de berichten met de gegevens beschikbaar zijn op de externe gegevensdrager, toont de boordcomputer een melding dat de gegevens beschikbaar zijn;

Artikel 2.6.1 Periode gegevenslevering

De periode, als bedoeld in artikel 2.6, onderdeel d, bedraagt per levering maximaal 1 jaar, met uitzondering van de gegevenslevering ‘Onderzoek’ die geen maximum periode kent, en de gegevenslevering ‘Chauffeurskaartdata’ die de periode van de arbeids-, rij- en rusttijdendata van de chauffeurskaart overneemt.

De standaardwaarde voor ‘Datumtijd begin periode’ is het tijdstip van opvragen minus 29 kalenderdagen, met uitzondering van de gegevenslevering ‘Onderzoek’, waar ‘Datumtijd begin periode’ standaard leeg is, en de gegevenslevering ‘Chauffeurskaartdata’, waar de standaarwaarde voor ‘Datumtijd begin periode’ overeenkomt met het oudste record op de chauffeurskaart. ‘Datumtijd einde periode’ is standaard leeg. Als bij opvragen van een gegevenslevering ‘Datumtijd begin periode’ leeg, wordt deze gevuld met de datum en het tijdstip van de activering. Is ‘Datumtijd einde periode’ leeg, dan wordt ‘Datumtijd einde periode’ gevuld met de datum en het tijdstip waarop het bericht wordt samengesteld;

In de gegevenslevering ‘Coordinaten’, ‘Gebeurtenis’ en ‘Onderzoek’ worden alle gegevens opgenomen die binnen de opgevraagde periode vallen.

In de gegevenslevering ‘Ritadministratie’, ‘Arbeidstijd’ en ‘Chauffeurskaartdata’ worden alle gegevensets opgenomen die de gevraagde periode, inclusief grenzen, overlappen. In de onderstaande tabel is de selectie voor deze gegevensleveringen verder uitgewerkt. Alle gegevensets worden opgenomen die voldoen aan één van de onderstaande condities:

Conditie 1	Datumtijd begin gegevenset ligt vóór Datumtijd begin periode en Datumtijd einde gegevenset is gelijk aan Datumtijd begin periode
Conditie 2	Datumtijd begin gegevenset ligt vóór Datumtijd begin periode en Datumtijd einde gegevenset ligt ná Datumtijd begin periode en Datumtijd einde gegevenset ligt vóór Datumtijd einde periode
Conditie 3	Datumtijd begin gegevenset ligt vóór Datumtijd begin periode en Datumtijd einde gegevenset ligt ná Datumtijd einde periode
Conditie 4	Datumtijd begin gegevenset is gelijk aan Datumtijd begin periode en Datumtijd einde gegevenset ligt ná Datumtijd begin periode en Datumtijd einde gegevenset ligt vóór Datumtijd einde periode
Conditie 5	Datumtijd begin gegevenset is gelijk aan Datumtijd begin periode en Datumtijd einde gegevenset is gelijk aan Datumtijd einde periode
Conditie 6	Datumtijd begin gegevenset is gelijk aan Datumtijd begin periode en Datumtijd einde gegevenset ligt na Datumtijd einde periode
Conditie 7	Datumtijd begin gegevenset ligt na Datumtijd begin periode en Datumtijd begin gegevenset ligt voor Datumtijd einde periode en Datumtijd einde gegevenset ligt na Datumtijd begin periode en Datumtijd einde gegevenset ligt voor Datumtijd einde periode
Conditie 8	Datumtijd begin gegevenset ligt na Datumtijd begin periode en Datumtijd begin gegevenset ligt voor Datumtijd einde periode en Datumtijd einde gegevenset is gelijk aan Datumtijd einde periode
Conditie 9	Datumtijd begin gegevenset ligt na Datumtijd begin periode en Datumtijd begin gegevenset ligt voor Datumtijd einde periode en Datumtijd einde gegevenset ligt na Datumtijd einde periode
Conditie 10	Datumtijd begin gegevenset is gelijk aan Datumtijd einde periode en Datumtijd einde gegevenset ligt na Datumtijd einde periode

De tabel kan als volgt gevisualiseerd worden. Alle gegevenssets behalve gegevensset 11 en 12 worden in het bericht opgenomen.

Figuur 1

Artikel 2.6.2 Verwerking gegevenslevering

Aanvragen van een gegevenslevering is een synchrone aanvraag die direct verwerkt moet worden.

Als de boordcomputer bezig is met de verwerking van een aanvraag voor een gegevenslevering, dan is het niet mogelijk om dezelfde gegevenslevering of een andere gegevenslevering aan te vragen zolang de huidige aanvraag niet is afgerond.

Het is wel eenvoudig mogelijk om een aanvraag te onderbreken. Na onderbreken van de huidige aanvraag is een nieuwe aanvraag van een gegevenslevering direct (< 1 seconde wachten) mogelijk.

De overige functies van de boordcomputer blijven functioneren als de boordcomputer bezig is met het verwerken van een aanvraag voor een gegevenslevering ‘Ritadministratie’, ‘Arbeids-, rij- en rusttijden’, ‘Coördinaten’, ‘Gebeurtenis’, ‘Onderzoek’ of ‘Chauffeurskaartdata’.

Overschrijven van een bericht op de externe gegevensdrager met dezelfde naam, is alleen toegestaan na een bevestiging van de gebruiker.

Artikel 2.7 Authenticatie en autorisatie

Aanvragen van de gegevensleveringen ‘Ritadministratie’, ‘Arbeids-, rij- en rusttijden’, ‘Coördinaten’, ‘Gebeurtenis’, ’Onderzoek’ en ‘Chauffeurskaartdata’ moet alleen mogelijk zijn voor daartoe geauthenticeerde en geautoriseerde gebruikers.

Artikel 2.8 Integriteit

De door de boordcomputer geregistreerde gegevens worden voorzien van een elektronische handtekening zodat achteraf de authenticiteit en integriteit van deze gegevens kan worden vastgesteld. Voor het aanmaken van de elektronische handtekeningen worden de boordcomputerkaarten gebruikt.

De integriteit van gegevens wordt onderverdeeld in ‘integriteit exportbericht’ en ‘integriteit geregistreerde gegevens’.

Artikel 2.8.1 Integriteit exportbericht

De boordcomputer kent zes gegevensleveringen, te weten ‘Ritadministratie’, ‘Arbeids-, rij- en rusttijden’, ‘Coördinaten’, ‘Gebeurtenis’, ’Onderzoek’ en ‘Chauffeurskaartdata’. Deze gegevensleveringen worden allen in een exportbericht vanuit de boordcomputer overgebracht. Dit exportbestand bestaat uit een gegevenlevering zoals gespecificeerd in artikel 3 t/m 8, in combinatie met de bijbehorende elektronische handtekening.

Voor het genereren van het exportbericht en de bijbehorende elektronische handtekening wordt gebruik gemaakt van XAdES-BES. De XAdES specificatie (www.w3.org/TR/XAdES) is een door het World Wide Web Consortium (W3C) ontworpen standaard voor de XML syntax van elektronische handtekeningen.

Het XML exportbericht bestaat uit een <Envelope>-element met daarin een <Gegevenslevering>-element en een <Signature>-element. Het <Gegevenslevering>-element bevat een resultaatbericht van een gegevenslevering zoals gespecificeerd in artikel 3 t/m 8. Het <Signature>-tag bevat de corresponderende elektronische handtekening en informatie over de totstandkoming van deze handtekening.

Het XML exportbericht kent, conform de XAdES-BES specificatie, de volgende opbouw:

Toelichting:

• a. de <Gegevenslevering>-tag bevat het resultaat bericht van een gegevenslevering.

• b. de <DigestValue>-tags bevatten de waarden van digests van de elementen Gegevenslevering en KeyInfo. Hierbij wordt gebruik gemaakt van onderstaande algoritmen.

• c. de <SignatureValue>-tag bevat de elektronische handtekening op basis van de digest value en het onderstaande Signature algoritme.

• d. de <X509Certificate>-tag bevat het certificaat met de publieke sleutel van de boordcomputer.

De volgende algoritmen worden voor het genereren van het exportbericht gebruikt:

Onderwerp	Algoritme	URI
Digest	SHA-1 of SHA-256	www.w3.org/2000/09/xmldsig#sha1 of www.w3.org/2001/04/xmlenc#sha256
Encoding	Base64	www.w3.org/2000/09/xmldsig#base64
Signature	RSA met SHA-1 of RSA met SHA-256	www.w3.org/2000/09/xmldsig#rsa-sha1 of www.w3.org/2001/04/xmldsig-more#rsa-sha256
Canonicalization	Canonical XML	www.w3.org/TR/2001/REC-xml-c14n-20010315
Transformation	Enveloped Signature	www.w3.org/2000/09/xmldsig#enveloped-signature

De keuze van het algoritme voor de Digest en de Signature is afhankelijk van het certificaat op de kaart waarmee de handtekening wordt gezet. Als dit certificaat met ‘RSA met SHA-256’ is ondertekend MOET SHA-256 worden gebruik. In de overige gevallen kan met SHA-1 worden volstaan.

Artikel 2.8.2 Integriteit geregistreerde gegevens

Een aantal gegevens, die door de boordcomputer taxi worden geregistreerd, dienen vanaf het moment van vastleggen de waarborg van integriteit en authenticiteit te bevatten. In de specificatie van de gegevensleveringen in artikel 3 t/m 8 wordt aangegeven of de betreffende gegevens bij het vastleggen met een elektronische handtekening worden ondertekend. Hierbij wordt aangegeven welke private sleutel hiervoor gebruikt moet worden.

Voor een gegeven dat bij vastleggen elektronisch ondertekend wordt, wordt een tekenbericht gegenereerd. Over dit tekenbericht wordt met behulp van XadES-BES een elektronische handtekening geplaatst.

Het tekenbericht bestaat uit een <Envelope>-element met daarin een <Data>-element en een <Signature>-element. Het <Data>-element bevat de XML representatie van het te tekenen gegeven zoals gespecificeerd in de xsd’s in artikel 3 t/m 8. Het <Signature>-tag bevat de corresponderende elektronische handtekening en informatie over de totstandkoming van deze handtekening.

Toelichting:

• a. de <Data>-tag bevat de te tekenen data opgemaakt volgens het corresponderende xsd.

• b. de <DigestValue>-tags bevatten de waarden van digests van de elementen Data en KeyInfo. Hierbij wordt gebruik gemaakt van de algoritmen zoals genoemd in artikel 2.8.1.

• c. de <SignatureValue>-tag bevat de elektronische handtekening op basis van de digest value en het Signature algoritme zoals genoemd in artikel 2.8.1.

Na generatie van het tekenbericht wordt de waarde van het element <SignatureValue> als <Integriteit> element opgeslagen bij de gegevens, die gezamenlijk het <Data> element vormen, en waarover de elektronische handtekening is berekend. Het tekenbericht hoeft niet te worden opgeslagen, zolang het <Data> element dat is getekend kan worden gereproduceerd.

Het genereren en vastleggen van de elektronische handtekening over het <Data> element vindt plaats bij het vastleggen van de gegevens die het Data element vormen.

Bij het samenstellen van een exportbericht worden de gegevens van het <Data> element onveranderd overgenomen uit de administratie op de boordcomputer. Het <Data> element wordt opnieuw geproduceerd, en moet exact gelijk zijn aan het <Data> element waarvoor een elektronische handtekening is berekend bij vastleggen van het gegeven. De geregistreerde elektronische handtekening moet worden overgenomen in het <Integriteit> element, het is niet toegestaan om de elektronische handtekening opnieuw te berekenen.

Artikel 2.8.3 Processchema

Een mogelijk proces voor het tekenen van gegevens en het exportbericht is weergegeven in figuur 2.

Figuur 2

Artikel 2.9 Foutafhandeling

Bij het opvragen van de gegevensleveringen kunnen foutsituaties optreden. Hierbij kan onderscheid gemaakt worden tussen functionele fouten, technische fouten en niet volledige gegevens.

Artikel 2.9.1 Functionele fouten

Bij onderstaande foutsituaties moet de boordcomputer de bijbehorende foutmelding tonen:

Foutsituatie	Afhandeling
Boordcomputer is niet vergrendeld sinds laatste activering	Verwerking gegevenslevering(en) stopt en de boordcomputer toont de melding ‘Boordcomputer is niet vergrendeld sinds laatste activering’
Er is geen externe gegevensdrager verbonden met de overbrengingsinterface van de boordcomputer als de gebruiker een gegevenslevering start	Verwerking gegevenslevering(en) stopt en de boordcomputer toont de melding ‘Geen externe gegevensdrager beschikbaar’
‘Datumtijd begin periode’ bevat geen geldige waarde als de gebruiker een gegevenslevering start. ‘Datumtijd begin periode‘ is verplicht.	Verwerking gegevenslevering(en) stopt en de boordcomputer toont de melding ‘Datumtijd begin periode bevat geen geldige waarde’
‘Datumtijd einde periode’ bevat geen geldige waarde als de gebruiker een gegevenslevering start. ‘Datumtijd einde periode‘ mag leeg zijn.	Verwerking gegevenslevering(en) stopt en de boordcomputer toont de melding ‘Datumtijd einde periode bevat geen geldige waarde’
‘Datumtijd einde periode’ ligt voor ‘Datumtijd begin periode’ als de gebruiker een gegevenslevering start.	Verwerking gegevenslevering(en) stopt en de boordcomputer toont de melding ‘Datumtijd einde periode ligt voor Datumtijd begin periode’
Overige functionele foutsituaties	Verwerking gegevenslevering stopt en de boordcomputer toont een foutmelding.

Artikel 2.9.2 Technische fouten

Foutsituatie	Afhandeling
Exporteren van een bericht naar de externe gegevensdrager gaat fout	Verwerking gegevenslevering(en) stopt en de boordcomputer toont de melding ‘Exporteren van een bericht naar de externe gegevensdrager is niet gelukt’
Overige technische foutsituaties	Verwerking gegevenslevering stopt en de boordcomputer toont een foutmelding.

Artikel 2.9.3 Onvolledige gegevens

Het niet volledig zijn van gegevens op de boordcomputer mag geen reden zijn om een resultaat bericht niet te exporteren.

Artikel 2.10 Overige kenmerken

Kenmerk	Invulling
Tekenset bericht	ISO 8859-1 (Latin 1).
Encoding bericht	UTF-8

Artikel 3 Ritadministratie

Artikel 3.1 Gegevens

Voor de ritadministratie worden de volgende gegevens onderkend:

Entiteit	Attribuut
PERIODE
	Datumtijd begin periode
	Datumtijd einde periode
AUTO
	Kenteken
VERVOERDER
	KvK-nummer
	P-nummer
ONDERNEMERSKAART
	Ondernemerskaart volgnummer
CERTIFICAAT BOORDCOMPUTER
	Publieke sleutel boordcomputer
BESTUURDER
	BSN
	Chauffeurskaart volgnummer
RIT
	Rit volgnummer
	Mutatiecode
	Datumtijd registratie
	Type rit
	Coördinaat beginpunt rit
	Datumtijd begin rit
	Km stand begin rit
	Coördinaat eindpunt rit
	Datumtijd einde rit
	Km stand einde rit
	Ritprijs
INTEGRITEIT
	Elektronische handtekening boordcomputer
	Datumtijd handtekening

Toelichting:

• a. de PERIODE is het tijdvak waarover de gebruiker de ritadministratie heeft opgevraagd

• b. RIT wordt per BESTUURDER uniek geïdentificeerd door een volgnummer.

• c. er zijn 2 mogelijke waarden voor ‘Type rit’: ‘Beladen rit’ en Onbeladen rit’.

• d. een RIT moet ondertekend worden met de elektronische handtekening van de boordcomputer om de integriteit van de ritgegevens achteraf te kunnen bepalen. Daartoe bevat INTEGRITEIT het attribuut ‘Elektronische handtekening boordcomputer’.

• e. de Ritprijs is in eurocenten

Artikel 3.2 Functionele berichtstructuur

De functionele berichtstructuur ziet er als volgt uit:

BERICHT
	Datumtijd samenstellen bericht					V
	PERIODE					1..1, V
	Datumtijd begin periode					V
	Datumtijd einde periode					V
	AUTO					1..1, V
	Kenteken					V
	CERTIFICAAT BOORDCOMPUTER					1..1, V
	Publieke sleutel boordcomputer					V
	VERVOERDER					1..*, V
	KvK-nummer					V
	P-nummer					V
		ONDERNEMERSKAART				1..*, V
		Ondernemerskaart volgnummer				V
			RIT			0..*, V
				ATA		1..1, V
				Rit volgnummer		V
				Mutatiecode		V
				Datumtijd registratie		V
				Type rit		V
				Coordinaat beginpunt rit		V
				Datumtijd begin rit		V
				Km stand begin rit		V
				Coordinaat eindpunt rit		O
				Datumtijd einde rit		O
				Km stand einde rit		O
				Ritprijs		O
					BESTUURDER	1..1, V
					BSN	V
					Chauffeurskaart volgnummer	V
				INTEGRITEIT		1..1, O
				Elektronische handtekening boordcomputer		V
				Datumtijd handtekening		V

Toelichting:

• a. de linkerkolom beschrijft de hiërarchische structuur van het bericht.

• b. de rechterkolom beschrijft voor alle entiteiten de cardinaliteit (1..1, 0..*) en (Verplicht, Optioneel)

• c. voor een RIT wordt de bestuurder opgenomen in het bericht.

Opmerking:

• a. alleen als de chauffeurskaart niet beschikbaar is tijdens registratie van een RIT moet Chauffeurskaart volgnummer van de BESTUURDER gevuld worden met nullen.

• b. de attributen ‘Coordinaat eindpunt rit’, ‘Datumtijd einde rit’, ‘Km stand einde rit’, ‘Ritprijs’ en de entiteit INTEGRITEIT zijn verplicht tenzij de RIT nog niet is beëindigd.

• c. de mutatiecode van een RIT is ‘I’ als het volgnummer van de RIT voor de eerste keer wordt geregistreerd. De I staat voor Insert.

• d. annuleren van de laatste handmatig ingevoerde ‘Aanvang rit’ is mogelijk. Het te annuleren record bevat alleen gegevens van het begin van de rit (‘Rit volgnummer’, ‘Mutatiecode’, ‘Datumtijd registratie’, ‘Type rit’, ‘Coordinaat beginpunt rit’ , ‘Datumtijd begin rit’ en ‘Km stand begin rit’). Annuleren moet op de volgende manier worden aangegeven:

  • d1. de gegevens van het te annuleren record worden ongewijzigd ondertekend met de elektronische handtekening van de boordcomputer.

  • d2. een nieuwe record wordt geregistreerd met de volgende gegevens: het volgnummer is gelijk aan het volgnummer van het te annuleren record uit d1, mutatiecode is ‘D’, ‘Datumtijd registratie’ is het tijdstip van registreren van dit nieuwe record, en de waarden van de overige attributen zijn gelijk aan de waarden van de overeenkomstige attributen van het te annuleren record. Ook dit record moet ondertekend worden met de elektronische handtekening van de boordcomputer.

• e. annuleren van de laatste handmatig ingevoerde ‘Einde rit’ is mogelijk. Het te annuleren record bevat zowel gegevens van het begin van de rit (‘Volgnummer’, ‘Mutatiecode’, ‘Datumtijd registratie’, ‘Type rit’, ‘Coordinaat beginpunt rit’, ‘Datumtijd begin rit’ en ‘Km stand begin rit’) als einde van de rit (‘Coordinaat einde rit’, ‘Datumtijd einde rit’, ‘Km stand einde rit’, ‘Ritprijs’). Annuleren moet op de volgende manier worden aangegeven:

  • e1. de gegevens van het te annuleren record worden ongewijzigd ondertekend met de elektronische handtekening van de boordcomputer als dit nog niet is gebeurd.

  • e2. een nieuwe record wordt geregistreerd met de volgende gegevens: het volgnummer is gelijk aan het volgnummer van het te annuleren record uit e1, mutatiecode is ‘D’, ‘Datumtijd registratie’ is het tijdstip van registreren van dit nieuwe record, en de waarden van de overige attributen zijn gelijk aan de waarden van de overeenkomstige attributen van het te annuleren record. Ook dit record moet ondertekend worden met de elektronische handtekening van de boordcomputer.

  • e3. een volgend nieuw record wordt geregistreerd met de volgende gegevens: het volgnummer is gelijk aan het volgnummer van het te annuleren record uit e1, mutatiecode is ‘M’, ‘Datumtijd registratie’ is het tijdstip van registreren van dit nieuwe record, de waarden van de attributen ‘Type rit’, ‘Coordinaat begin rit’ , ‘Datumtijd begin rit’ en ‘Km stand begin rit’ zijn gelijk aan de waarden van de overeenkomstige attributen van het te annuleren record, en de attributen ‘Coordinaat einde rit’ , ‘Datumtijd einde rit’, ‘Km stand einde rit’ en ‘Ritprijs’ zijn initieel leeg om gevuld te worden bij het opnieuw uitvoeren van de handmatige actie ‘Einde rit’.

Artikel 3.3 Technische berichtstructuur

Als gegevensformaat wordt gebruik gemaakt van XML.

Mapping functionele berichtstructuur naar technische berichtstructuur:

Functionele berichtstructuur	Technische berichtstructuur
Datumtijd samenstellen bericht	DatTdSmBr
PERIODE	Periode
Datumtijd begin periode	DatTdBegPr
Datumtijd einde periode	DatTdEndPr
AUTO	Auto
Kenteken	Kntkn
CERTIFICAAT BOORDCOMPUTER	CertificaatBCT
Publieke sleutel boordcomputer	PbSlBc
VERVOERDER	Vervoerder
KvK-nummer	KvKnr
P-nummer	Pnr
ONDERNEMERSKAART	Ondernemerskaart
Ondernemerskaart volgnummer	OkVgNr
RIT	Rit
DATA	Data
Rit volgummer	RtVgNr
MutatieCode	MtCd
Datumtijd registratie	DatTdReg
Type rit	Type
Coördinaat beginpunt rit	LocBeg
Datumtijd begin rit	DatTdBeg
Km stand begin rit	KmStdBeg
Coördinaat eindpunt rit	LocEnd
Datumtijd einde rit	DatTdEnd
Km stand einde rit	KmStdEnd
Ritprijs	Prijs
BESTUURDER	Bestuurder
BSN	BSN
Chauffeurskaart volgnummer	ChVgNr
INTEGRITEIT	Integriteit
Elektronische handtekening boordcomputer	ElHdBc
Datumtijd handtekening	DatTdHd

Artikel 3.4 Ritadministratie.xsd

De onderstaande ritadministratie.xsd wordt gebruikt.

Artikel 3.5 Volgorde gegevens

De geselecteerde ritten moeten gegroepeerd per vervoerder, en daarbinnen per ondernemerskaart, in oplopende volgorde van volgnummer worden opgenomen in de ritadministratie.

Artikel 3.6 Integriteit gegevens

Alle ritten worden ondertekend worden met een elektronische handtekening op basis van de private sleutel van de systeemkaart.

De ritadministratie bevat een element <Rit> en <Rit> bevat de elementen <Data> en <Integriteit>. Het <Data> element bevat de volgende ritgegevens:

• RtVgNr

• MtCd

• DatTdReg

• Type

• LocBeg.Lat en LocBeg.Lon

• DatTdBeg

• KmStdBeg

• LocEnd.Lat en LocEnd.Lon

• DatTdEnd

• KmStdEnd

• Prijs

• Bestuurder.BSN

• Bestuurder.CkVgNr

Het <Integriteit> element bevat de elektronische handtekening van het bijbehorende Data element.

Bij het samenstellen van de ritadministratie moeten de gegevens van het <Data> element onveranderd worden overgenomen uit de ritadministratie op de boordcomputer. Het berekenen van de ‘Elektronische handtekening boordcomputer’ van het <Data> element van een <Rit> wordt gedaan bij het beëindigen van de rit. De vastgelegde ‘Elektronische handtekening boordcomputer’ wordt per <Rit> onveranderd overgenomen in het onderliggende <Integriteit> element.

Artikel 3.7 Overige kenmerken

Artikel 3.7.1 Naamgeving

De naamgeving van de gegevenslevering ‘ritadministratie’ is als volgt:

Ritadministratie_Kenteken-DatumtijdSamenstellenBericht_DatumtijdBeginPeriode _DatumtijdEindePeriode.xml.

Hierbij worden de cursief gedrukte gegevens gevuld met de corresponderende registratiewaarde. De volgende formaten worden hierbij gebruikt:

○ DatumtijdSamenstellenBericht:	CCYYMMDDHHMMSS;
○ DatumtijdBeginPeriode:	CCYYMMDDHHMM;
○ DatumtijdEindePeriode:	CCYYMMDDHHMM.

Artikel 3.7.2 Berichtgrootte

Bij 100 ritten is het bericht ‘ritadministratie’ maximaal 100 Kbyte groot.

Artikel 4 Arbeids-, rij- en rusttijden

Artikel 4.1 Gegevens

Voor het bericht ‘Arbeids-, rij- en rusttijden’ worden de volgende gegevens onderkend:

Entiteit	Attribuut
PERIODE
	Datumtijd begin periode
	Datumtijd einde periode
AUTO
	Kenteken
VERVOERDER
	KvK-nummer
	P-nummer
ONDERNEMERSKAART
	Ondernemerskaart volgnummer
BESTUURDER
	BSN
	Chauffeurskaart volgnummer
CERTIFICAAT
	Publieke sleutel chauffeur
	Publieke sleutel boordcomputer
ARBEIDSTIJD
	Arbeidstijd volgnummer
	Datumtijd registratie
	Datumtijd begin arbeidstijd
	Datumtijd einde arbeidstijd
RIJTIJD
	Rijtijd volgnummer
	Datumtijd registratie
	Datumtijd begin rijtijd
	Datumtijd begin rijtijd
PAUZE
	Pauze volgnummer
	Mutatiecode
	Datumtijd registratie
	Datumtijd begin pauze
	Datumtijd begin pauze
ANDERE WERKZAAMHEDEN
	Andere werkzaamheden volgnummer
	Mutatiecode
	Datumtijd registratie
	Datumtijd begin andere werkzaamheden
	Datumtijd einde andere werkzaamheden
INTEGRITEIT
	Elektronische handtekening chauffeur
	Elektronische handtekening boordcomputer
	Datumtijd handtekening

Toelichting:

• a. de PERIODE is het tijdvak waarover de gebruiker de arbeidstijden heeft opgevraagd

• b. ARBEIDSTIJD wordt per BESTUURDER uniek geïdentificeerd door een volgnummer.

• c. RIJTIJD wordt per BESTUURDER uniek geïdentificeerd door een volgnummer.

• d. PAUZE wordt per BESTUURDER uniek geïdentificeerd door een volgnummer.

• e. ANDERE WERKZAAMHEDEN wordt per BESTUURDER uniek geïdentificeerd door een volgnummer.

• f. ARBEIDSTIJD, inclusief bijbehorende voorkomens van RIJTIJD, PAUZE en ANDERE WERKZAAMHEDEN, moet ondertekend worden met een elektronische handtekening om de integriteit van de gegevens achteraf te kunnen bepalen. Indien de chauffeurskaart aanwezig is wordt getekend met de elektronische handtekening van de chauffeur, indien de chauffeurskaart niet aanwezig is wordt getekend met de elektronische handtekening van de boordcomputer.

Opmerkingen

• a. de mutatiecode van een PAUZE of ANDERE WERKZAAMHEDEN is ‘I’ als het volgnummer van de PAUZE of ANDERE WERKZAAMHEDEN voor de eerste keer wordt geregistreerd. De I staat voor Insert.

• b. annuleren van de laatste handmatige actie is mogelijk. Voor PAUZE en ANDERE WERKZAAMHEDEN moet dit op volgende manier worden aangegeven:

  • b1. de bestaande PAUZE of ANDERE WERKZAAMHEDEN wordt niet gewijzigd.

  • b2. een nieuwe PAUZE of ANDERE WERKZAAMHEDEN wordt geregistreerd met het volgnummer van de PAUZE of ANDERE WERKZAAMHEDEN die geannuleerd moet worden.

  • b3. Datumtijd registratie van de nieuwe PAUZE of ANDERE WERKZAAMHEDEN is het tijdstip van registratie van de nieuwe PAUZE of ANDERE WERKZAAMHEDEN.

  • b4. Mutatiecode van de nieuwe PAUZE of ANDERE WERKZAAMHEDEN is ‘D’ om aan te geven dat de PAUZE of ANDERE WERKZAAMHEDEN met dit specifieke volgnummer geannuleerd moet worden.

• c. voor de structuur van het bericht ‘Arbeids-, rij- en rusttijden’ zie de artikelen over ‘Functionele berichtstructuur’ en ‘Technische berichtstructuur’.

• d. voor datatypen zie artikel over ‘Technische berichtstructuur’

Artikel 4.2 Functionele berichtstructuur

De functionele bericht structuur ziet er als volgt uit:

BERICHT
	Datumtijd samenstellen bericht						V
	PERIODE						1..1, V
	Datumtijd begin periode						V
	Datumtijd einde periode						V
	AUTO						1..1, V
	Kenteken						V
	VERVOERDER						1..*, V
	KvK-nummer						V
	P-nummer						V
		ONDERNEMERSKAART					1..*, V
		Ondernemerskaart volgnummer					V
			BESTUURDER				0..*, V
			BSN				V
			Chauffeurskaart volgnummer				V
				CERTIFICAAT			1..1, V
				Publieke sleutel chauffeur			O
				Publieke sleutel boordcomputer			O
				ARBEIDSTIJD			0..*, V
					DATA		1..1, V
						Arbeidstijd volgnummer	V
						Datumtijd registratie	V
						Datumtijd begin arbeidstijd	V
						Datumtijd einde arbeidstijd	V
						RIJTIJD	0..*, V
						Rijtijd volgnummer	V
						Datumtijd registratie	V
						Datumtijd begin rijtijd	V
						Datumtijd einde rijtijd	V
						PAUZE	0..*, V
						Pauze volgnummer	V
						MutatieCode	V
						Datumtijd registratie	V
						Datumtijd begin pauze	V
						Datumtijd einde pauze	V
						ANDERE WERKZAAMHEDEN	0..*, V
						Andere werkzaamheden volgnummer	V
						MutatieCode	V
						Datumtijd registratie	V
						Datumtijd begin andere werkzaamheden	V
						Datumtijd einde andere werkzaamheden	V
					INTEGRITEIT		1..1, V
						Elektronische handtekening chauffeur	C
						Elektronische handtekening boordcomputer	C
						Datumtijd handtekening	V

Toelichting:

• a. de linkerkolom beschrijft de hiërarchische structuur van het bericht.

• b. de rechterkolom beschrijft voor alle entiteiten de cardinaliteit (1..1, 0..*) en (Verplicht, Optioneel). De rechterkolom beschrijft voor alle attributen (Verplicht, Optioneel).

• c. ook in de taxivervoermodus zonder chauffeurskaart moeten ARBEIDSTIJD, RIJTIJD, PAUZE en ANDERE WERKZAAMHEDEN worden vastgelegd. Alle voorkomens van ARBEIDSTIJD, RIJTIJD, PAUZE en ANDERE WERKZAAMHEDEN die zijn vastgelegd zonder chauffeurskaart worden per VERVOERDER uitgeleverd voor een BESTUURDER met het handmatig ingegeven BSN en het Chauffeurskaart volgnummer gevuld met nullen.

• d. een bericht bevat per BESTUURDER de optionele attributen ‘Publieke sleutel chauffeur’ en ‘Publieke sleutel boordcomputer’ waarvan precies 1 attribuut verplicht gevuld moet worden. Als de BESTUURDER bekend is moet het attribuut ‘Publieke sleutel chauffeur’ gevuld worden, als de bestuurder onbekend is moet het attribuut ‘Publieke sleutel boordcomputer’ gevuld worden.

• e. een bericht bevat per ARBEIDSTIJD de optionele attributen ‘Elektronische handtekening chauffeur’ en ‘Elektronische handtekening boordcomputer’ waarvan precies 1 attribuut verplicht gevuld moet worden. Als de bijbehorende BESTUURDER bekend is moet het attribuut ‘Elektronische handtekening chauffeur’ gevuld worden, als de bestuurder onbekend is moet het attribuut ‘Elektronische handtekening boordcomputer’ gevuld worden.

Artikel 4.3 Technische berichtstructuur

Als gegevensformaat wordt gebruik gemaakt van XML.

Mapping functionele berichtstructuur naar technische berichtstructuur

Functionele berichtstructuur	Technische berichtstructuur
Datumtijd samenstellen bericht	DatTdSmBr
PERIODE	Periode
Datumtijd begin periode	DatTdBegPr
Datumtijd einde periode	DatTdEndPr
AUTO	Auto
Kenteken	Kntkn
VERVOERDER	Vervoerder
KvK-nummer	KvKnr
P-nummer	Pnr
ONDERNEMERSKAART	Ondernemerskaart
Ondernemerskaart volgnummer	OkVgNr
BESTUURDER	Bestuurder
BSN	BSN
Chauffeurskaart volgnummer	CkVgNr
CERTIFICAAT	Certificaat
Publieke sleutel chauffeur	PbSlCh
Publieke sleutel boordcomputer	PbSlBc
ARBEIDSTIJD	Arbeidstijd
DATA	Data
Arbeidstijd volgnummer	ArVgNr
Datumtijd registratie	DatTdReg
Datumtijd begin arbeidstijd	DatTdBeg
Datumtijd einde arbeidstijd	DatTdEnd
RIJTIJD	Rijtijd
Rijtijd volgnummer	RtVgNr
Datumtijd registratie	DatTdReg
Datumtijd begin rijtijd	DatTdBeg
Datumtijd einde rijtijd	DatTdEnd
PAUZE	Pauze
Pauze volgnummer	PzVgNr
Datumtijd registratie	DatTdReg
Datumtijd begin pauze	DatTdBeg
Datumtijd einde pauze	DatTdEnd
ANDERE WERKZAAMHEDEN	AndrWrkzmhdn
Andere werkzaamheden volgnummer	AwVgNr
MutatieCode	MtCd
Datumtijd registratie	DatTdReg
Datumtijd begin andere werkzaamheden	DatTdBeg
Datumtijd einde andere werkzaamheden	DatTdEnd
INTEGRITEIT	Integriteit
Elektronische handtekening chauffeur	ElHdCh
Elektronische handtekening boordcomputer	ElHdBc
Datumtijd handtekening	DatTdHd

Artikel 4.4 Arbeidstijden.xsd

Het onderstaande Arbeidstijden.xsd wordt gebruikt.

Artikel 4.5 Volgorde gegevens

De geselecteerde arbeidstijden moeten gegroepeerd per vervoerder, en daarbinnen per ondernemerskaart, en daarbinnen per bestuurder in oplopende volgorde van volgnummer worden opgenomen. Binnen een arbeidstijd moeten de rijtijd, pauze en andere werkzaamheden in oplopende volgorde van volgnummer worden opgenomen

Artikel 4.6 Integriteit gegevens

Alle arbeidstijden worden ondertekend met een elektronische handtekening. Voor het plaatsen van de elektronische handtekening wordt gebruik gemaakt van de private sleutel van de chauffeurskaart indien deze aanwezig is, en van de private sleutel van de systeemkaart indien de chauffeurskaart niet aanwezig is.

De ‘Arbeids-, rij- en rusttijden’ bevat een element <Arbeidstijd> en <Arbeidstijd> bevat de elementen <Data> en <Integriteit>. Het <Data> element bevat de volgende arbeidstijd gegevens:

• ArVgNr

• DatTdReg

• DatTdBeg

• DatTdEnd

• Rijtijd

• RtVgNr

• DatTdReg

• DatTdBeg

• DatTdEnd

• Pauze

• PzVgNr

• MtCd

• DatTdReg

• DatTdBeg

• DatTdEnd

• AndrWrkzmhdn

• AwVgNr

• MtCd

• DatTdReg

• DatTdBeg

• DatTdEnd

Het <Integriteit> element bevat de elektronische handtekening chauffeur of elektronische handtekening boordcomputer van het bijbehorende <Data> element.

Bij het samenstellen van bericht ‘Arbeids-, rij- en rusttijden’ moeten de gegevens van het <Data> element onveranderd worden overgenomen uit de boordcomputer. Het berekenen van de ‘Elektronische handtekening chauffeur’ of ‘Elektronische handtekening boordcomputer’ van het <Data> element moet gebeuren bij het beëindigen van een arbeidstijd. De vastgelegde ‘Elektronische handtekening chauffeur’ of ‘Elektronische handtekening boordcomputer’ moeten per arbeidstijd onveranderd worden overgenomen in het onderliggende <Integriteit> element.

Artikel 4.7 Overige kenmerken

Artikel 4.7.1 Naamgeving

De naamgeving van de gegevenslevering ‘arbeidstijd’ is als volgt:

Arbeidstijd_Kenteken-DatumtijdSamenstellenBericht_DatumtijdBeginPeriode _DatumtijdEindePeriode.xml.

Hierbij worden de cursief gedrukte gegevens gevuld met de corresponderende registratiewaarde. De volgende formaten worden hierbij gebruikt:

○ DatumtijdSamenstellenBericht:	CCYYMMDDHHMMSS;
○ DatumtijdBeginPeriode:	CCYYMMDDHHMM;
○ DatumtijdEindePeriode:	CCYYMMDDHHMM.

Artikel 4.7.2 Berichtgrootte

Bij 100 arbeidstijden is het bericht ‘arbeidstijd’ maximaal 120 Kbyte groot.

Artikel 5 Coördinaten

Artikel 5.1 Gegevens

Voor het bericht ‘Coördinaten’ worden de volgende gegevens onderkend:

Entiteit	Attribuut
PERIODE
	Datumtijd begin periode
	Datumtijd einde periode
AUTO
	Kenteken
VERVOERDER
	KvK-nummer
	P-nummer
ONDERNEMERSKAART
	Ondernemerskaart volgnummer
COORDINAAT
	Coordinaat volgnummer
	Datumtijd registratie
	Breedtegraad
	Lengtegraad
	Werkingsmodus
	Werkingsniveau

Toelichting:

• a. de PERIODE is het tijdvak waarover de gebruiker de coördinaten heeft opgevraagd

• b. COORDINAAT wordt per VERVOERDER uniek geïdentificeerd door een volgnummer.

Opmerkingen:

• a. voor de structuur van het bericht ‘Coördinaten’ zie de artikelen over ‘Functionele berichtstructuur’ en ‘Technische berichtstructuur’.

• b. voor datatypen zie artikel over ‘Technische berichtstructuur’

Artikel 5.2 Functionele berichtstructuur

De functionele bericht structuur ziet er als volgt uit:

BERICHT
	Datumtijd samenstellen bericht				V
	PERIODE				1..1, V
	Datumtijd begin periode				V
	Datumtijd einde periode				V
	AUTO				1..2, V
	Kenteken				V
		VERVOERDER			1..*, V
		KvK-nummer			V
		P-nummer			V
			ONDERNEMERSKAART		1..*, V
			Ondernemerskaart volgnummer		V
				COORDINAAT	0..*, V
				Coordinaat volgnummer	V
				Datumtijd registratie	V
				Breedtegraad	V
				Lengtegraad	V
				Werkingsmodus	V
				Werkingsniveau	V

Toelichting:

• a. de linkerkolom beschrijft de hiërarchische structuur van het bericht.

• b. de rechterkolom beschrijft voor alle entiteiten de cardinaliteit (1..1, 0..*) en (Verplicht, Optioneel).

• c. de rechterkolom beschrijft voor alle attributen (Verplicht, Optioneel).

• d. in werkingsmodus ‘Operationele modus’ is het attribuut ‘Werkingsniveau’ verplicht.

Opmerkingen:

• a. alle coördinaten met een datumtijd registratie die ligt voor het tijdstip van de laatste activering van de boordcomputer worden gegroepeerd bij dezelfde AUTO - VERVOERDER - ONDERNEMERSKAART combinatie. Het kenteken, KvK-nummer, P-nummer en het volgnummer van de ondernemerskaart worden in deze groepering uitgevuld met nullen.

• b. alle coördinaten die zijn geregistreerd na het tijdstip van de laatste activering worden geleverd met het kenteken van de auto, het KvK-nummer en P-nummer van de vervoerder en het volgnummer van de ondernemerskaart waarvoor de coördinaten zijn geregistreerd.

• c. alleen de werkingsmodus ‘Operationele Modus’ kent meerder werkingsniveaus. Bij de overige modi wordt werkingsniveau ‘Basis’ aangehouden.

Artikel 5.3 Technische berichtstructuur

Als gegevensformaat wordt gebruik gemaakt van XML.

Mapping functionele berichtstructuur naar technische berichtstructuur:

Functionele berichtstructuur	Technische berichtstructuur
Datumtijd samenstellen bericht	DatTdSmBr
PERIODE	Periode
Datumtijd begin periode	DatTdBegPr
Datumtijd einde periode	DatTdEndPr
AUTO	Auto
Kenteken	Kntkn
VERVOERDER	Vervoerder
KvK-nummer	KvKnr
P-nummer	Pnr
ONDERNEMERSKAART	Ondernemerskaart
Ondernemerskaart volgnummer	OkVgNr
COORDINAAT	COORD
Coordinaat volgnummer	VgNr
Datumtijd registratie	Dt
Breedtegraad	Lat
Lengtegraad	Lon
Werkingsmodus	Md
Werkingsniveau	Nv

Artikel 5.4 Coordinaten.xsd

Het onderstaande Coordinaten.xsd wordt gebruikt.

Artikel 5.5 Volgorde gegevens

De geselecteerde coördinaten moeten gegroepeerd per kenteken, en daarbinnen per vervoerder, en daarbinnen per ondernemerskaart, in oplopende volgorde van volgnummer, in het bericht worden opgenomen.

Artikel 5.6 Integriteit gegevens

Het bericht ‘Coördinaten’ wordt ondertekend met een elektronische handtekening van de boordcomputer. De afzonderlijke coördinaten worden niet ondertekend.

Artikel 5.7 Overige kenmerken

Artikel 5.7.1 Naamgeving

De naamgeving van de gegevenslevering ‘coordinaten’ is als volgt:

Coordinaten_Kenteken-DatumtijdSamenstellenBericht_DatumtijdBeginPeriode _DatumtijdEindePeriode.xml.

Hierbij worden de cursief gedrukte gegevens gevuld met de corresponderende registratiewaarde. De volgende formaten worden hierbij gebruikt:

○ DatumtijdSamenstellenBericht:	CCYYMMDDHHMMSS;
○ DatumtijdBeginPeriode:	CCYYMMDDHHMM;
○ DatumtijdEindePeriode:	CCYYMMDDHHMM.

Kenteken is het kenteken van de auto waarin de boordcomputer als laatste is geactiveerd.

Artikel 5.7.2 Berichtgrootte

Een bericht ‘coordinaten’ bevat maximum 1440 coördinaten per dag, wanneer de auto continue rijdt en 1 coördinaat per minuut wordt vastgelegd. Voor de periode van een dag geeft een bericht van maximaal 236 Kbyte. Per jaar is het bericht ‘coordinaten’ maximaal 84 Mbyte groot.

Artikel 6 Gebeurtenis

Artikel 6.1 Gegevens

Voor het bericht ‘Gebeurtenis’ worden de volgende gegevens onderkend:

Entiteit	Attribuut
PERIODE
	Datumtijd begin periode
	Datumtijd einde periode
AUTO
	Kenteken
VERVOERDER
	KvK-nummer
	P-nummer
ONDERNEMERSKAART
	Ondernemerskaart volgnummer
CERTIFICAAT BOORDCOMPUTER
	Publieke sleutel boordcomputer
GEBEURTENIS
	Gebeurtenis volgnummer
	Code
	Datumtijd registratie
	Km stand
	Status rijden auto
	Werkingsmodus
	Werkingsniveau
	Aanvullende relevante informatie
BESTUURDER
	BSN
	Chauffeurskaart volgnummer
INTEGRITEIT
	Elektronische handtekening boordcomputer

Toelichting:

• a. de PERIODE is het tijdvak waarover de gebruiker de gebeurtenissen heeft opgevraagd

• b. GEBEURTENIS wordt per VERVOERDER uniek geïdentificeerd door een volgnummer.

• c. BESTUURDER is verplicht als tijdens het optreden van de gebeurtenis de werkingsmodus ‘Operationele Modus’ actief is in het werkingsniveau ‘Arbeidstijd’ of ‘Taxivervoer’,.

• d. alleen de werkingsmodus ‘Operationele Modus’ kent meerder werkingsniveaus. Bij de overige modi wordt werkingsniveau ‘Basis’ aangehouden.

• e. een GEBEURTENIS moet ondertekend worden met de elektronische handtekening van de boordcomputer om de integriteit van de gegevens achteraf te kunnen bepalen. Daartoe bevat INTEGRITEIT het attribuut ‘Elektronische handtekening boordcomputer’.

• f. het attribuut ‘Status rijden auto’ wordt ingevuld op basis van gegevens van de verplaatsingsopnemer.

Opmerkingen:

• a. voor de structuur van het bericht ‘Gebeurtenis’ zie de artikelen over ‘Functionele berichtstructuur’ en ‘Technische berichtstructuur’.

• b. voor datatypen zie het artikel over ‘Technische berichtstructuur’

Artikel 6.2 Functionele berichtstructuur

De functionele bericht structuur ziet er als volgt uit:

BERICHT
	Datumtijd samenstellen bericht					V
	PERIODE					1..1, V
	Datumtijd begin periode					V
	Datumtijd einde periode					V
	AUTO					1..1, V
	Kenteken					V
	CERTIFICAAT BOORDCOMPUTER					1..1, V
	Publieke sleutel boordcomputer					V
	VERVOERDER					1..*, V
	KvK-nummer					V
	P-nummer					V
		ONDERNEMERSKAART				1..*, V
		Ondernemerskaart volgnummer				V
			GEBEURTENIS			0..*, V
				DATA		1..1,V
				Gebeurtenis volgnummer		V
				Code		V
				Datumtijd registratie		V
				Km stand		V
				Status rijden auto		V
				Werkingsmodus		V
				Werkingsniveau		V
				Aanvullende relevante informatie		O
					BESTUURDER	1..1,V
					BSN	V
					Chauffeurskaart volgnummer	V
				INTEGRITEIT		1..1,V
				Elektronische handtekening boordcomputer		V
				Datumtijd handtekening		V

Toelichting:

• a. de linkerkolom beschrijft de hiërarchische structuur van het bericht.

• b. de rechterkolom beschrijft voor alle entiteiten de cardinaliteit (1..1, 0..*) en (Verplicht, Optioneel).De rechterkolom beschrijft voor alle attributen (Verplicht, Optioneel).

• c. door het vullen van het attribuut ‘Aanvullende relevante informatie’ kan waar relevant aanvullende informatie worden toegevoegd voor een bepaalde code.

Opmerkingen:

• a. alleen als de chauffeurskaart niet beschikbaar is tijdens registratie van een GEBEURTENIS moet Chauffeurskaart volgnummer van de BESTUURDER gevuld worden met nullen.

Artikel 6.3 Technische berichtstructuur

Als gegevensformaat wordt gebruik gemaakt van XML.

Mapping functionele berichtstructuur naar technische berichtstructuur:

Functionele berichtstructuur	Technische berichtstructuur
Datumtijd samenstellen bericht	DatTdSmBr
PERIODE	Periode
Datumtijd begin periode	DatTdBegPr
Datumtijd einde periode	DatTdEndPr
AUTO	Auto
Kenteken	Kntkn
VERVOERDER	Vervoerder
KvK-nummer	KvKnr
P-nummer	Pnr
ONDERNEMERSKAART	Ondernemerskaart
Ondernemerskaart volgnummer	OkVgNr
GEBEURTENIS	Gbrtns
DATA	Data
Gebeurtenis volgnummer	GbVgNr
Code	Code
Datumtijd registratie	DatTdReg
Km stand	KmStd
Status rijden auto	StRdnAt
Werkingsmodus	WrkngsMds
Werkingsniveau	WrkngsNv
Aanvullende relevante informatie	AanvInfo
BESTUURDER	Bestuurder
BSN	BSN
Chauffeurskaart volgnummer	CkVgNr
INTEGRITEIT	Integriteit
Elektronische handtekening boordcomputer	ElHdBc
Datumtijd handtekening	DatTdHd

Artikel 6.4 Gebeurtenis.xsd

Het onderstaande Gebeurtenis.xsd wordt gebruikt.

Artikel 6.5 Volgorde gegevens

De geselecteerde gebeurtenissen moeten gegroepeerd per vervoerder, en daarbinnen per ondernemerskaart, in oplopende volgorde van volgnummer, in het bericht worden opgenomen.

Artikel 6.6 Integriteit gegevens

Alle gebeurtenissen worden ondertekend op basis van de private sleutel van de boordcomputer.

Het bericht Gebeurtenis bevat een element <Gebeurtenis> en het element <Gebeurtenis> bevat de elementen <Data> en <Integriteit>. Het <Data> element bevat de volgende gegevens:

• GbVgNr

• Code

• DatTdReg

• KmStd

• StRdnAt

• WrkngsMds

• WrkngsNv

• AanvInfo

• Bestuurder.BSN

• Bestuurder.CkVgNr

Het <Integriteit> element bevat de elektronische handtekening boordcomputer van het bijbehorende <Data> element.

Bij het samenstellen van de het bericht ‘gebeurtenis’ moeten de gegevens van het <Data> element onveranderd worden overgenomen uit de administratie op de boordcomputer. Het berekenen van de ‘Elektronische handtekening boordcomputer’ van het Data element van een Rit moet gebeuren bij het optreden van de gebeurtenis. De vastgelegde ‘Elektronische handtekening boordcomputer’ moet per gebeurtenis onveranderd worden overgenomen in het onderliggende <Integriteit> element.

Artikel 6.7 Codetabel

In de onderstaande tabel staat de in het bericht op te nemen code per gebeurtenis vermeld.

Code	Omschrijving
S001	een storing in de werking van de registratiefuntie
S002	een storing in de werking van de beveiligingsfuncties
S003	een storing in de werking van de sensoren
S004	een storing in de overbrenging van gegevens naar een externe interface zoals beschreven in deze bijlage
S005	een storing in de werking van de systeemkaart
S006	een storing in de werking van de boordcomputerkaart
F001	een integriteitsfout in de uitvoercode
F002	een integriteistfout in de systeemgegevens
F003	een integriteitfout in de opgeslagen gebruikersgegevens
F004	een integriteitfout bij de gegevensuitvoer naar de chauffeurskaart
F005	een fout in de registratiefunctie
F006	een fout die de beveiliging van de boordcomputer in gevaar brengen
F007	een fout bij de gegevensuitvoer naar externe inrichtingen
F008	een fout bij het gebruik van de systeemkaart
F009	een fout bij het gebruik van de boordcomputerkaart
F010	een fout in de bewegingsensor
F011	een fout in de positiebepalingsensor
F012	een fout in de koppeling met de taxameter
M001	het aanzetten van de boordcomputer
M002	het uitzetten van de boordcomputer
M003	het inbrengen van een boordcomputerkaart
M004	het uitnemen van een boordcomputerkaart
M005	het inbrengen van een ongeldige boordcomputerkaart
M006	het inbrengen van een chauffeurskaart waarvan blijkt dat de datum en het tijdstip van de laatste registratie op de chauffeurskaart, op een later tijdstip valt dan de actuele datum en het tijdstip van de boordcomputer
M007	het niet op een juiste wijze afsluiten van een kaartsessie
M008	het inbrengen van een chauffeurskaart waarvan blijkt dat de laatste kaartsessie niet juist is afgesloten
M009	het ontstaan van onvoldoende opslagcapaciteit op het geheugen van de boordcomputer
M010	het verdwijnen van onvoldoende opslagcapaciteit op het geheugen van de boordcomputer
M011	het ontstaan van onvoldoende opslagcapaciteit op de chauffeurskaart
M012	het verdwijnen van onvoldoende opslagcapaciteit op de chauffeurskaart
M013	het ontstaan van een onderbreking van ten minste 5 seconden in de stroomvoorziening van de boordcomputer
M014	het verdwijnen van een onderbreking van ten minste 5 seconden in de stroomvoorziening van de boordcomputer
M015	het begin van een periode waarin de contactgeschakelde voedingsbron is uitgeschakeld in de toestand rijden
M016	het einde van een periode waarin de contactgeschakelde voedingsbron is uitgeschakeld in de toestand rijden
M017	het optreden van een toestand verplaatsen zonder dat er sprake is van een toestand rijden
M019	het begin van het niet kunnen verkrijgen van positiegegevens gedurende 5 minuten
M020	het einde van het niet kunnen verkrijgen van positiegegevens gedurende 5 minuten
M021	een afwijking van meer dan twee procent tussen de, met behulp van bewegingsgegevens van de bewegingsopnemer en de constante van de boordcomputer, berekende afstand en de werkelijke afstand
M022	een afwijking van meer dan drie procent tussen de berekende afstand op basis van gegevens van de bewegingsopnemer en positibepalingsensor
M023	het overbrengen van gegevens inclusief de naam van de externe interface
M024	gebeurtenissen die kunnen duiden op het in gevaar brengen van de beveiliging van de boordcomputer
M025	het activeren van de boordcomputer
M026	het keuren van de boordcomputer
M027	het deactiveren van de boordcomputer
M028	het inschakelen van een bedrijfsvergrendeling van de boordcomputer
M029	inschakelen van een werkingsmodus inclusief naam werkingsmodus
M030	het uitschakelen van een werkingsmodus inclusief naam werkingsmodus
M031	het begin van rijden in de operationele modus werkingsniveau taxivervoer zonder chauffeurskaart
M032	het einde van rijden in de operationele modus werkingsniveau taxivervoer zonder chauffeurskaart
M033	het detecteren van een niet-succesvolle authenticatiepoging
M034	installeren van een programmatuurrevisie
M035	starten van audit- en beveiligingsfuncties
M036	stoppen van audit- en beveiligingsfuncties
M037	het uitblijven of weigeren van een elektronische handtekening
M038	niet-geautoriseerde wijziging in de configuratie van de boordcomputer
M039	toegang tot het gebeurtenissenlogboek

Artikel 6.8 Overige kenmerken

Artikel 6.8.1 Naamgeving

De naamgeving van de gegevenslevering ‘gebeurtenis’ is als volgt:

Gebeurtenis_Kenteken-DatumtijdSamenstellenBericht_DatumtijdBeginPeriode _DatumtijdEindePeriode.xml.

Hierbij worden de cursief gedrukte gegevens gevuld met de corresponderende registratiewaarde. De volgende formaten worden hierbij gebruikt:

○ DatumtijdSamenstellenBericht:	CCYYMMDDHHMMSS;
○ DatumtijdBeginPeriode:	CCYYMMDDHHMM;
○ DatumtijdEindePeriode:	CCYYMMDDHHMM.

Artikel 6.8.2 Berichtgrootte

Bij 100 gebeurtenissen is het bericht ‘gebeurtenis’ maximaal 100 Kbyte groot.

Artikel 7 Onderzoek

Artikel 7.1 Gegevens

Voor het bericht ‘Onderzoek’ worden de volgende gegevens onderkend:

Entiteit	Attribuut
PERIODE
	Datumtijd begin periode
	Datumtijd einde periode
AUTO
	Kenteken
CERTIFICAAT BOORDCOMPUTER
	Publieke sleutel boordcomputer
IDENTIFICATIE BOORDCOMPUTER
	Naam fabrikant
	Serienummer
	Versienummer
	Bouwjaar
	Goedkeuringsnummer
PROGRAMMATUUR
	Versienummer
	Datumtijd installatie
ACTIVERINGSONDERZOEK
	Volgnummer
	Km stand
	Datumtijd onderzoek
	Constante boordcomputer
	Effectieve omtrek wielband
	Bandenmaat
	Koppeling taxameter
	Resultaat
	Opmerking
PERIODIEK ONDERZOEK
	Volgnummer
	Km stand
	Datumtijd onderzoek
	Constante boordcomputer
	Effectieve omtrek wielband
	Bandenmaat
	Koppeling taxameter
	Resultaat
	Opmerking
WERKPLAATS
	Erkenningsnummer
	Keuringskaart volgnummer
INTEGRITEIT
	Elektronische handtekening boordcomputer

Toelichting:

• a. de PERIODE is het tijdvak waarover de gebruiker de onderzoeken heeft opgevraagd

• b. ACTIVERINGSONDERZOEK wordt uniek geïdentificeerd door een volgnummer

• c. PERIODIEK ONDERZOEK wordt uniek geïdentificeerd door een volgnummer

• d. Constante boordcomputer is in impulsen per kilometer

• e. Effectieve omtrek wielband is in millimeters

• f. Bandenmaat is in inches

Opmerkingen:

• a. voor de structuur van het bericht ‘Onderzoek’ zie de artikelen over ‘Functionele berichtstructuur’ en ‘Technische berichtstructuur’.

• b. voor datatypen zie artikel over ‘Technische berichtstructuur’

Artikel 7.2 Functionele berichtstructuur

BERICHT
	Datumtijd samenstellen bericht			V
	PERIODE			1..1, V
	Datumtijd begin periode			V
	Datumtijd einde periode			V
	AUTO			1..1, V
	Kenteken			V
	CERTIFICAAT BOORDCOMPUTER			1..1, V
	Publieke sleutel boordcomputer			V
	IDENTIFICATIE BOORDCOMPUTER			1..1, V
	Naam fabrikant			V
	Serienummer			V
	Versienummer			V
	Bouwjaar			V
	Goedkeuringsnummer			V
		PROGRAMMATUUR		1..*, V
		Versienummer		V
		Datumtijd installatie		V
	ACTIVERINGSONDERZOEK			1..1, V
		DATA		1..1, V
		Volgnummer		V
		Km stand		V
		Datumtijd onderzoek		V
		Constante boordcomputer		V
		Effectieve omtrek wielband		V
		Bandenmaat		V
		Koppeling taxameter		V
		Resultaat		V
		Opmerking		V
			WERKPLAATS	1..1, V
			Erkenningsnummer	V
			Keuringskaart volgnummer	V
		INTEGRITEIT		1..1, V
		Elektronische handtekening boordcomputer		V
		Datumtijd handtekening		V
	PERIODIEK ONDERZOEK			0..*, V
		DATA		1..1, V
		Volgnummer		V
		Km stand		V
		Datumtijd onderzoek		V
		Constante boordcomputer		V
		Effectieve omtrek wielband		V
		Bandenmaat		V
		Koppeling taxameter		V
		Resultaat		V
		Opmerking		V
			WERKPLAATS	1..1, V
			Erkenningsnummer	V
			Keuringskaart volgnummer	V
		INTEGRITEIT		1..1, V
		Elektronische handtekening boordcomputer		V
		Datumtijd handtekening		V

Artikel 7.3 Technische berichtstructuur

Als gegevensformaat wordt gebruik gemaakt van XML.

Mapping functionele berichtstructuur naar technische berichtstructuur:

Functionele berichtstructuur	Technische berichtstructuur
Datumtijd samenstellen bericht	DatTdSmBr
PERIODE	Periode
Datumtijd begin periode	DatTdBegPr
Datumtijd einde periode	DatTdEndPr
AUTO	Auto
Kenteken	Kntkn
CERTIFICAAT BOORDCOMPUTER	CertificaatBCT
Publieke sleutel boordcomputer	PbSlBc
IDENTIFICATIE BOORDCOMPUTER	IdentificatieBCT
Naam fabrikant	Nmfb
Serienummer	SrNr
Versienummer	VrNr
Bouwjaar	BwJr
Goedkeuringsnummer	GdKrgsNr
PROGRAMMATUUR	Programmatuur
Versienummer	VrNr
Datumtijd installatie	DatTdIns
ACTIVERINGSONDERZOEK	Activeringsonderzoek
DATA	Data
Volgnummer	VgNr
Km stand	KmStd
Datumtijd onderzoek	DatTdOndrzk
Constante boordcomputer	CnstBCT
Effectieve omtrek wielband	EffOmtrkWlbd
Bandenmaat	BdMt
Koppeling taxameter	KpTxMtr
Resultaat	Rslt
Opmerking	Opm
WERKPLAATS	Werkplaats
Erkenningsnummer	ErkNr
Keuringskaart volgnummer	KkVgNr
INTEGRITEIT	Integriteit
Elektronische handtekening boordcomputer	ElHdBc
Datumtijd handtekening	DatTdHd
PERIODIEK ONDERZOEK	Periodiek onderzoek
DATA	Data
Volgnummer	VgNr
Km stand	KmStd
Datumtijd registratie	DatTdOndrzk
Constante boordcomputer	CnstBCT
Effectieve omtrek wielband	EffOmtrkWlbd
Bandenmaat	BdMt
Koppeling taxameter	KpTxMtr
Resultaat	Rslt
WERKPLAATS	Werkplaats
Erkenningsnummer	ErkNr
Keuringskaart volgnummer	KkVgNr
INTEGRITEIT	Integriteit
Elektronische handtekening boordcomputer	ElHdBc

Artikel 7.4 Onderzoek.xsd

Het onderstaande Onderzoek.xsd dient te worden gebruikt.

Artikel 7.5 Volgorde gegevens

Als eerste wordt het geselecteerde activeringsonderzoek in het bericht opgenomen. Daarna worden de geselecteerde periodieke onderzoeken in oplopende volgorde van volgnummer in het bericht opgenomen.

Artikel 7.6 Integriteit gegevens

Het activeringsonderzoek en de periodiek onderzoeken worden ondertekend op basis van de private sleutel van de boordcomputer.

Het bericht ‘Onderzoek’ bevat de elementen <activeringsonderzoek> en <periodiek onderzoek>. De elementen <activeringsonderzoek> en <periodiek onderzoek> bevatten elementen <Data> en <Integriteit>. Het <Data> element bevat voor beide onderzoeken dezelfde gegevens:

• VgNr

• KmStd

• DatTdOndrzk

• CnstBCT

• EffOmtrkWlbd

• BdMt

• KpTxMtr

• Rslt

• Werkplaats.ErkNr

• Werkplaats.KkVgNr

Het <Integriteit> element bevat de elektronische handtekening van het bijbehorende Data element.

Bij het samenstellen van het bericht ‘Onderzoek’ moeten de gegevens van het <Data> element onveranderd worden overgenomen uit de registratie op de boordcomputer. Het berekenen van de elektronische handtekening van het <Data> element van een ‘Onderzoek’ wordt gedaan bij het afronden van een onderzoek. De vastgelegde elektronische handtekening wordt per onderzoek overgenomen in het onderliggende <Integriteit> element.

Artikel 7.7 Overige kenmerken

Artikel 7.7.1 Naamgeving

De naamgeving van de gegevenslevering ‘onderzoek’ is als volgt:

Onderzoek_Kenteken-DatumtijdSamenstellenBericht_DatumtijdBeginPeriode _DatumtijdEindePeriode.xml.

Hierbij worden de cursief gedrukte gegevens gevuld met de corresponderende registratiewaarde. De volgende formaten worden hierbij gebruikt:

○ DatumtijdSamenstellenBericht:	CCYYMMDDHHMMSS;
○ DatumtijdBeginPeriode:	CCYYMMDDHHMM;
○ DatumtijdEindePeriode:	CCYYMMDDHHMM.

Artikel 7.7.2 Berichtgrootte

Bij 10 onderzoeken is het bericht ‘onderzoek’ maximaal 10 Kbyte groot.

Artikel 8 Chauffeurskaartdata

Artikel 8.1 Gegevens

Voor het bericht ‘Chauffeurskaartdata’ worden de volgende gegevens onderkend:

Entiteit	Attribuut
PERIODE
	Datumtijd begin periode
	Datumtijd einde periode
BESTUURDER
	BSN
	Chauffeurskaart volgnummer
CERTIFICAAT
	Publieke sleutel chauffeur
CHAUFFEURSKAARTDATA
	Data overgenomen van chauffeurskaart
INTEGRITEIT
	Elektronische handtekening chauffeur
	Datumtijd handtekening

Toelichting:

• a. de PERIODE bestrijkt het eerste tot en met het laatste record op de chauffeurskaart

• b. CHAUFFEURSKAARTDATA bevat de BASE64 gecodeerde weergave van de binaire inhoud van het bestand EF.Driver_Activity_Data, overgenomen van de chauffeurskaart

Opmerkingen

• a. voor de structuur van het bericht ‘chauffeurskaartdata’ zie de artikelen over ‘Functionele berichtstructuur’ en ‘Technische berichtstructuur’.

• b. voor datatypen zie artikel over ‘Technische berichtstructuur’

Artikel 8.2 Functionele berichtstructuur

De functionele bericht structuur ziet er als volgt uit:

BERICHT
	Datumtijd samenstellen bericht			V
	PERIODE			1..1, V
	Datumtijd begin periode			V
	Datumtijd einde periode			V
	BESTUURDER			1..1, V
	BSN			V
	Chauffeurskaart volgnummer			V
		CERTIFICAAT		1..1, V
		Publieke sleutel chauffeur		V
	CHAUFFEURSKAARTDATA			0..1, V
		Data		V
		INTEGRITEIT		1..1, V
			Elektronische handtekening chauffeur	V
			Datumtijd handtekening	V

Toelichting:

• a. de linkerkolom beschrijft de hiërarchische structuur van het bericht.

• b. de rechterkolom beschrijft voor alle entiteiten de cardinaliteit (1..1, 0..*) en (Verplicht, Optioneel). De rechterkolom beschrijft voor alle attributen (Verplicht, Optioneel).

Artikel 8.3 Technische berichtstructuur

Als gegevensformaat wordt gebruik gemaakt van XML.

Mapping functionele berichtstructuur naar technische berichtstructuur

Functionele berichtstructuur	Technische berichtstructuur
Datumtijd samenstellen bericht	DatTdSmBr
PERIODE	Periode
Datumtijd begin periode	DatTdBegPr
Datumtijd einde periode	DatTdEndPr
BESTUURDER	Bestuurder
BSN	BSN
Chauffeurskaart volgnummer	CkVgNr
CERTIFICAAT	Certificaat
Publieke sleutel chauffeur	PbSlCh
CHAUFFEURKAARTDATA	ChKrtData
Data	Data
INTEGRITEIT	Integriteit
Elektronische handtekening chauffeur	ElHdCh
Datumtijd handtekening	DatTdHd

Artikel 8.4 Chauffeurskaartdata.xsd

Het onderstaande Chauffeurskaartdata.xsd wordt gebruikt.

Artikel 8.5 Volgorde gegevens

De chauffeurskaartdata wordt overgenomen zoals deze wordt aangetroffen op de chauffeurskaart.

Artikel 8.6 Integriteit gegevens

De chauffeurskaartdata wordt ondertekend met een elektronische handtekening. Voor het plaatsen van de elektronische handtekening wordt gebruik gemaakt van de private sleutel van de chauffeurskaart.

De ‘Chauffeurskaartdata’ bevat een element <ChKrtData> en <ChKrtData> bevat de elementen <Data> en <Integriteit>. Het <Data> element bevat de base64 gecodeerde informatie zoals overgenomen uit de chauffeurskaart

Het <Integriteit> element bevat de elektronische handtekening chauffeur van het bijbehorende <Data> element.

Bij het samenstellen van bericht ‘Chauffeurskaartdata’ moeten de gegevens van het <Data> element onveranderd worden overgenomen uit de chauffeurskaart. Het berekenen van de ‘Elektronische handtekening chauffeur’ moet gebeuren zodra deze data van de chauffeurskaart is overgenomen. De vastgelegde ‘Elektronische handtekening chauffeur’ moet onveranderd worden overgenomen in het onderliggende <Integriteit> element.

Artikel 8.7 Overige kenmerken

Artikel 8.7.1 Naamgeving

De naamgeving van de gegevenslevering ‘Chauffeurskaartdata’ is als volgt:

Chauffeurskaartdata_BSN_Chauffeurskaartvolgnummer-DatumtijdSamenstellenBericht_DatumtijdBeginPeriode _DatumtijdEindePeriode.xml.

Hierbij worden de cursief gedrukte gegevens gevuld met de corresponderende registratiewaarde. De volgende formaten worden hierbij gebruikt:

○ DatumtijdSamenstellenBericht:	CCYYMMDDHHMMSS;
○ DatumtijdBeginPeriode:	CCYYMMDDHHMM;
○ DatumtijdEindePeriode:	CCYYMMDDHHMM.

Artikel 8.7.2 Berichtgrootte

Het bericht ‘Chauffeurskaartdata’ is maximaal 200 Kbyte groot.

BIJLAGE 3 BIJ DE REGELING SPECIFICATIES EN TYPEGOEDKEURING BOORDCOMPUTER TAXI

Artikel 1 Definities

In deze bijlage wordt verstaan onder:

a.	d (achtervoegsel)	Geeft aan dat een getal in decimale notatie is.
b.	ETX	Teken dat het einde van een bericht aangeeft (03h).
c.	h (achtervoegsel)	Geeft aan dat een getal in hexadecimale notatie is.
d.	STX	Teken dat het begin van een bericht aangeeft (02h).

Artikel 2 Eisen en Ontwerp

Artikel 2.1 Interface identificatie en diagrammen

Een overzicht van de complete interface is te zien in Figuur 1 hieronder.

Figuur 1 – Overzicht van de interfaces

Hierin zijn twee niveaus te onderscheiden:

• 1. Fysieke interface (FI)

  De fysieke interface bestaat uit een RS-232 verbinding.

• 2. Logische interface (LI)

  Deze interface is een directe communicatie-interface.

Artikel 2.2 Algemene interface eisen

EIS-AL-1

De indeling van de interfaces volgens het OSI model is als in Tabel 1:

Tabel 1 – Overzicht fysieke interface

OSI laag	Invulling
Laag 1: Fysiek	RS-232 verbinding
Laag 2: Data	Serieel, 8N1, 9600 baud
Laag 3: Netwerk	Niet aanwezig
Laag 4: Transport	STX, lengte, berichtdata, CRC, ETX, byte stuffing
Laag 5: Sessie	Niet aanwezig
Laag 6: Presentatie	Niet aanwezig
Laag 7: Applicatie	berichtdata = [berichttype, data]

Artikel 2.3 Fysieke interface (FI)

EIS-FI-1	De interface is gebaseerd op een RS-232 interface.
EIS-FI-2	De interface is bestand tegen kortsluiting
EIS-FI-3	De interface voldoet aan richtlijn 2004/104/EC voor elektromagnetische compatibiliteit.
EIS-FI-4	De interface voldoet aan de eisen die zijn neergelegd in NEN-ISO 10605 met betrekking tot elektrostatische ontlading.
EIS-FI-5	De interface voldoet aan mechanische omgevingsklasse M3 zoals beschreven in Europese Richtlijn 2004/22/EG.
EIS-FI-6	De fysieke interface voldoet aan de eisen die zijn neergelegd in NEN-EN-IEC 60068-2-1 en NEN-EN-IEC 60068-2-2 en functioneert naar behoren binnen een temperatuursbereik van -20° C tot 70° C.
EIS-FI-7	De fysieke interface voldoet aan de eisen die zijn neergelegd in NEN-EN-IEC 60068-2-30 en functioneert naar behoren bij een relatieve luchtvochtigheid van minimaal 10% en maximaal 90%.
EIS-FI-8	De boordcomputer is voorzien van een door de fabrikant te kiezen connector, waarmee de aansluitwijze van de bekabeling zoals gespecificeerd in Tabel 2 kan worden ondersteund. De connector dient in de markt vrij verkrijgbaar te zijn. Zowel de connector als de kabel voldoet ook aan 0.
EIS-FI-9	Voor aansluiting van de Taxameter op de boordcomputer wordt gebruik gemaakt van bekabeling waarmee de elektrische signalen van de fysieke interface worden aangesloten zoals gespecificeerd in Tabel 2, waarbij de standaard pinbezetting van de gekozen connector moet worden gebruikt.

Tabel 2 – Aansluitwijze bekabeling

Functie aan zijde boordcomputer	Functie aan zijde taxameter	Opmerking
Tx+	Rx+	Data van boordcomputer naar Taxameter.
Tx-	Rx-
Rx+	Tx+	Data van Taxameter naar boordcomputer
Rx-	Tx-
Signal Ground	Signal Ground

EIS-FI-10	Voor het aansluiten van TX+/TX- op RX+/RX- (data van boordcomputer naar Taxameter en omgekeerd) wordt in de bekabeling gebruik gemaakt van Twisted Pair verbindingen.
EIS-FI-11	Voor apparaten met zowel de functie boordcomputer als taxameter is het toegestaan intern een afwijkende interface toe te passen, indien de in dit document gespecificeerde interface ook op het apparaat geïmplementeerd is.

Artikel 2.4 Logische interface (LI)

Artikel 2.4.1 Algemene eisen

EIS-LI-1

Alle berichten over de logische interface zijn in binair formaat. De byte order is zoals in Tabel 3 hieronder aangegeven, waar het getal 32597d (=7F55h) met datatype integer wordt verstuurd. Hierbij geeft de volgorde aan welke byte als eerste wordt verstuurd.

Tabel 3 – Byte volgorde

Volgorde	Waarde van het voorbeeld
1^e byte	7Fh
2^e byte	55h

EIS-LI-2	De berichtenstroom bestaat uit een vraag- en antwoordproces. Van de zijde van de boordcomputer worden uitsluitend vraagberichten, dus berichttypen 4 t/m 49 gestuurd. Van de zijde van de taxameter worden uitsluitend berichttypen > 50 gestuurd, dus alleen antwoordberichten of foutberichten.
EIS-LI-3	Indien er een fout optreedt in het vraag- en antwoordproces wordt in plaats van een antwoordbericht een foutmeldingsbericht gestuurd, waarbij het berichttype de desbetreffende foutmelding beschrijft. Indien dit niet toereikend is kan bericht F_NIET_STANDAARD gebruikt worden. Indien er meerdere foutmeldingen tegelijkertijd optreden dient de meest ernstige fout te worden gekozen. Een bericht bevat altijd één vraag of één antwoord (of foutmelding).

Artikel 2.4.2 Eisen met betrekking tot gegevensrepresentatie

EIS-LI-4

Alle berichten over deze interface zullen beginnen met startteken 02h (hierna aangeduid met STX) en eindigen met stopteken 03h (hierna aangeduid met ETX). In de rest van het bericht komt teken 02h en 03h niet voor. Om deze tekens toch in data mogelijk te maken is escape teken 1Bh beschikbaar. De escape waarden van de gereserveerde tekens zijn:

Tabel 4 – Escape karakters

Teken	Escape waarde
02h	1B12h
03h	1B13h
1Bh	1B1Bh

EIS-LI-5

Een veld is één van de volgende datatypen:

Tabel 5 - Datatypen voor velden

Datatype	Bereik	Toelichting
Byte	[0..255]
Datum en tijd	[1 jan 2000 0:00:00 31 dec 2225 23:59:59]	YY	Aantal jaar vanaf het jaar 2000, byte. Eerste byte in dit veld
		MM	Maand, [1..12], byte, na YY
		DD	Dag, [1..31], byte, na MM
		HH	Uur, [0..23], byte, na DD
		MM	Minuut, [0..59], byte, na HH
		SS	Seconden, [0..59], byte. Laatste byte in dit veld
Integer	[–32768 , 32767]	2 bytes, hoogste byte eerst.
Long	[–2147483648, 2147483647]	4 bytes, hoogste byte eerst, gevolgd door de één na hoogste byte etc.
Single	Volgens IEEE 754-1985	4 bytes, hoogste byte eerst, gevolgd door de één na hoogste byte etc.
String	Lengte [0..255], gevolgd door karakters met bereik [32..126]	Tekenreeks van maximaal 256 karakters. Eerst dient de lengte opgegeven te worden, gevolgd door de karakters. Er is geen 0h eindteken. De karakters zijn 8-bits ASCII, met de restrictie tot karakters 32 t/m 126.

Artikel 2.4.3 Eisen aan de berichtstructuur

EIS-LI-6

Een bericht heeft het volgende formaat:

Tabel 6 – Formaat van een bericht

Byte	Naam	Waarde	Toelichting
1	Start of text (STX)	02h	Identificatie van de start van een bericht
2,3	Lengte bericht	0..65535	Aantal bytes van de berichtdata van het bericht, plus het berichttype en de CRC. Hoogste byte eerst.
4	berichttype	4..255
5+n	Data	0..255	Data is optioneel voor enkele typen berichten.
(5,6)+n	CRC	0..65535	CRC16 van de data en het berichttype. Hoogste byte eerst.
7+n	End of text (ETX)	03h	Identificatie einde bericht

EIS-LI-7	De berichtlengte is gelijk aan het aantal bytes tussen STX en ETX, waarbij het bericht zonder byte stuffing wordt beoordeeld. Indien een bericht ontvangen is dient eerst byte stuffing verwijderd te worden alvorens de berichtlengte te berekenen.
EIS-LI-8	De gebruikte CRC methode is 16 bits CRC-CCITT, met als polynoom x^16 + x^12 + x^5 + 1. De CRC wordt berekend over byte 4 tot byte 5+n, dus over het berichttype en de data. De CRC is berekend voordat byte stuffing toegepast, vergelijkbaar met 0.
EIS-LI-9	Een berichttype wordt gekenmerkt door een getal van 4 t/m 255. Een overzicht van berichttypes is hieronder gegeven (decimaal).

Tabel 7 – Berichtnummers, de nummers zijn decimaal

Berichttype (decimaal)	Naam	Toelichting
Vraagberichten
4	VR_STATUS	Datum en tijd, Functiestand, Tarief identificatie
5	VR_TARIEFINFO	Datum en tijd, Tarief informatie
6	VR_RITBEDRAG	Datum en tijd, Functiestand, Ritbedrag
7	VR_TOTALEN	Datum en tijd, Totalisatordata
8	VR_TAXAMETER_INFO	Datum en tijd, Constante afstandssignaalgenerator, Beveiligingsdatum, Identificatie taxi
Antwoordenberichten
54	A_STATUS	Datum en tijd, Functiestand, Tarief identificatie
55	A_TARIEFINFO	Datum en tijd, Tarief informatie
56	A_RITBEDRAG	Datum en tijd, Functiestand, Ritbedrag
57	A_TOTALEN	Datum en tijd, Totalisatordata
58	A_TAXAMETER_INFO	Datum en tijd, Constante afstandssignaalgenerator, Beveiligingsdatum, Identificatie taxi
Foutberichten
100	F_BERICHT_ONBEKEND	Fout: berichtnummer onbekend
101	F_CRC_INCORRECT	Fout: CRC niet correct
102	F_LENGTE_INCORRECT	Fout: berichtlengte niet correct. Wordt gestuurd indien: • het veld lengte ontbreekt in een bericht • de waarde van het veld lengte niet correct is • de minimale berichtlengte onjuist is • het bericht uit meer bytes bestaat dan is toegestaan
103	F_GEEN_STX	Fout: Begin van bericht niet gedetecteerd (2x ETX gedetecteerd zonder STX)
104	F_GEEN_ETX	Fout: Einde van bericht niet gedetecteerd (2x STX gedetecteerd zonder ETX)
105	F_NIET_STANDAARD	Fout: Niet gedefinieerde fout, bevat aanvullende informatie
106	F_VELD_ONGELDIG	Fout: Een opgegeven veld is ongeldig.

Artikel 2.4.3.1 Bericht VR_STATUS

Het bericht VR_STATUS wordt gebruikt om de status van de taxameter op te vragen. Voor de situatie waarin de taxameter ingesteld is om niet te functioneren indien de interface niet functioneert is er een extra veld beschikbaar. Dit veld is om aan de taxameter duidelijk te maken of de interface softwarematig inactief dan wel operationeel is. Zo kan er gecontroleerd worden of de fysieke interface in beide richtingen correct functioneert zonder dat de taxameter deze controle hoeft te interpreteren als goed werkende verbinding.

EIS-LI-10	De data in het bericht VR_STATUS heeft het volgende formaat:

Status interface

Byte

[10h = interface inactief, 11h = interface operationeel]

Totale berichtgrootte: 8 bytes

EIS-LI-11	Het veld ‘status interface’ mag alleen de status ‘operationeel’ bevatten indien:
	• Dit door de boordcomputer gewenst is
	én
	• Er gedurende de laatste 15 seconden ten minste één geldig antwoordbericht van de taxameter is ontvangen.
EIS-LI-12	Er zal vanuit de richting van de boordcomputer minimaal eens per 5 seconden een VR_STATUS bericht gestuurd worden over de interface.

Toelichting: dit is ten behoeve van de functionaliteit van het automatisch uitschakelen van de taxameter. De taxameter dient uit te vallen indien er 15 seconden geen statusbericht is ontvangen met ‘Status interface’ = ‘interface operationeel’.

Artikel 2.4.3.2 Bericht A_STATUS

Het antwoord op het bericht VR_STATUS. Hierin geeft de taxameter de functiestand aan en de identificatie van het huidige tarief. Dit TARIEF_ID dient overeen te komen met de tariefgroepen die met bericht VR_TARIEFINFO kunnen worden opgevraagd. De informatie in dit bericht kan door de boordcomputer gebruikt worden om een overgang van de functiestand te detecteren.

EIS-LI-13	De data in het bericht A_STATUS heeft het volgende formaat:

DATUM_EN_TIJD	Datum	Huidige datum en tijd in de taxameter
FUNCTIESTAND	Byte	[10h = ‘vrij’, 11h = ‘tarief’, 12h = ‘te betalen’]
TARIEF_ID	Byte [0..255]	Identificatie van het huidige tarief

Totale berichtgrootte: 15 bytes

Artikel 2.4.3.3 Bericht VR_TARIEFINFO

Dit bericht is voor het opvragen van tariefinformatie. Totale berichtgrootte: 7 bytes

EIS-LI-14	Het bericht VR_TARIEFINFO bevat geen ‘data’.

Artikel 2.4.3.4 Bericht A_TARIEFINFO

Het bericht A_TARIEFINFO is het antwoord op het bericht VR_TARIEFINFO. Hierin is per tarief een identificatienummer, een omschrijving, een tarief per eenheid en een omschrijving van de eenheid aangegeven. Deze gegevens worden per tarief verstrekt.

Ook BTW kan gezien worden als een tarief.

EIS-LI-15	De data in het bericht A_TARIEFINFO heeft het volgende formaat:

DATUM_EN_TIJD		Datum	Huidige datum en tijd in de taxameter
TARIEF_AANTAL		Byte [0..255]	Aantal tarieven
Herhalen per tarief, dus TARIEF_AANTAL keer
tariefX	Id	Byte	Identificatie tariefX
tariefX	omschrijving	String	Omschrijving van tariefX, bijvoorbeeld 'kilometerprijs' of 'BTW laag tarief'
tariefX	tarief per eenheid	Single	Tarief per eenheid
tariefX	omschrijving eenheid	String	Omschrijving eenheid van tariefX, bijvoorbeeld ‘km’ of ‘Eurocent'
tariefX	Percentage	Byte	0 = nee, 1 = ja, zie toelichting
Einde herhalen per tarief

Totale berichtgrootte: variabel, 14 bytes + (5 + tekstlengte) * TARIEF_AANTAL

Indien het tarief een percentage betreft dient bij de berekening het tarief per eenheid door 100 gedeeld te worden.

Artikel 2.4.3.5 Bericht VR_RITBEDRAG

Dit bericht is bedoeld om het ritbedrag op te vragen, bijvoorbeeld nadat er een functiestand overgang van de taxameter is gedetecteerd. Totale berichtgrootte: 7 bytes

EIS-LI-16	Het bericht VR_RITBEDRAG bevat geen ‘data’.

Artikel 2.4.3.6 Bericht A_RITBEDRAG

Het bericht A_RITBEDRAG is het antwoord op het bericht VR_RITBEDRAG. Hierin staat de functiestand en het ritbedrag vermeld. De functiestand is hier nogmaals opgenomen zodat er zekerheid is dat op het moment van opvragen de functiestand en het ritbedrag op het zelfde moment zijn uitgelezen.

EIS-LI-17	De data in het bericht A_RITBEDRAG heeft het volgende formaat:

DATUM_EN_TIJD	Datum	Huidige datum en tijd in de taxameter
FUNCTIESTAND	Byte	[10h = ‘vrij’, 11h = ‘tarief’, 12h = ‘te betalen’]
TOTAALBEDRAG	Single	Totaal ritbedrag in Eurocenten inclusief toeslagen
RITBEDRAG	Single	Ritbedrag in Eurocenten
RIT_VERTREKTIJD	Datum	Datum en tijd van het vertrek van de rit
RIT_AANKOMSTTIJD	Datum	Datum en tijd van de aankomst van de rit
AFSTAND_RIT	Long	Totale door de taxi afgelegde afstand in honderden meters voor de betreffende rit
TARIEF_AANTAL	Byte	Aantal toegepaste tarieven in ritbedrag
Herhalen per tarief, dus TARIEF_AANTAL keer
TARIEF_ID	byte	Identificatie tariefX, overeenkomstig de tarieven in A_TARIEFINFO
TARIEF_EENH	Single	Aantal eenheden tariefX
Einde herhalen per tarief
TOESLAG_AANTAL	byte	Aantal toegepaste toeslagen in ritbedrag
Herhalen per toeslag, dus TOESLAG_AANTAL keer
TOESLAG_OMSCHR	String	Omschrijving toeslag
TOESLAG_BEDR	Single	Toeslag bedrag in Eurocenten
Einde herhalen per toeslag

Totale berichtgrootte: variabel, minimaal 29 bytes, maximaal 65535 bytes

Een korting wordt als negatief TOESLAG_BEDR weergegeven.

Artikel 2.4.3.7 Bericht VR_TOTALEN

Dit bericht is voor het opvragen van de totalisatordata. Totale berichtgrootte: 7 bytes

EIS-LI-18	Het bericht VR_TOTALEN bevat geen ‘data’.

Artikel 2.4.3.8 Bericht A_TOTALEN

Het bericht A_TOTALEN is het antwoord op het bericht VR_TOTALEN. Het bericht bevat de totalisatordata.

EIS-LI-19	De data in het bericht A_TOTALEN heeft het volgende formaat:

DATUM_EN_TIJD	Datum	Huidige datum en tijd in de taxameter
AFSTAND_TOT	Long	Totale door de taxi afgelegde afstand in honderden meters
AFSTAND_TAR	Long	Totale door de taxi afgelegde afstand in honderden meters in de stand tarief
AANT_RIT_BET	Long	Totaal aantal betaalde ritten
BEDR_TOESLAG	Long	Totaal geldbedrag in Eurocenten dat in rekening is gebracht als toeslag
BEDR_RITBEDR	Long	Totaal geldbedrag in Eurocenten dat in rekening is gebracht als ritbedrag

Totale berichtgrootte: 33 bytes

Artikel 2.4.3.9 Bericht VR_TAXAMETER_INFO

Dit bericht is voor het opvragen van de constante van de afstandssignaalgenerator, de beveiligingsdatum en de identificatie van de taxi. Totale berichtgrootte: 7 bytes

EIS-LI-20	Het bericht VR_TAXAMETER_INFO bevat geen ‘data’.

Artikel 2.4.3.10 Bericht A_TAXAMETER_INFO

Het bericht A_TAXAMETER_INFO is het antwoord op het bericht VR_TAXAMETER_INFO. Het bericht bevat de constante van de afstandssignaalgenerator, de beveiligingsdatum en de identificatie van de taxi. Dit bericht is bedoeld om de taxameter te identificeren.

EIS-LI-21	De data in het bericht A_TAXAMETER_INFO heeft het volgende formaat:

DATUM_EN_TIJD	Datum	Huidige datum en tijd in de taxameter
CONSTANTE_SG	Integer	Aantal impulsen per km
BEVEILIGINGS_D	Datum	Datum en tijd waarop de taxameter is beveiligd
TAXI_ID	String	Tekst ter identificatie van de taxi

Totale berichtgrootte: variabel, minimaal 22 bytes, maximaal 278 bytes

Artikel 2.4.3.11 Bericht F_BERICHT_ONBEKEND

Het bericht F_BERICHT_ONBEKEND is een foutmelding die gestuurd wordt bij het ontvangen van een vraagbericht met een onbekend berichttype. Totale berichtgrootte: 7 bytes.

EIS-LI-22	Het bericht F_BERICHT_ONBEKEND bevat geen ‘data’.

Artikel 2.4.3.12 Bericht F_CRC_INCORRECT

Het bericht F_CRC_INCORRECT is een foutmelding die gestuurd wordt bij het ontvangen van een vraagbericht met een onjuiste CRC. Totale berichtgrootte: 7 bytes.

EIS-LI-23	Het bericht F_CRC_INCORRECT bevat geen ‘data’.

Artikel 2.4.3.13 Bericht F_LENGTE_INCORRECT

Het bericht F_LENGTE_INCORRECT is een foutmelding die gestuurd wordt bij het ontvangen van een vraagbericht met een onjuiste minimale of maximale berichtlengte. Totale berichtgrootte: 7 bytes.

EIS-LI-24	Het bericht F_LENGTE_INCORRECT bevat geen ‘data’.

Artikel 2.4.3.14 Bericht F_GEEN_STX

Het bericht F_GEEN_STX is een foutmelding die gestuurd wordt bij het ontvangen tweemaal een ETX teken zonder het tussentijds ontvangen van een STX teken. Totale berichtgrootte: 7 bytes

EIS-LI-25	Het bericht F_GEEN_STX bevat geen ‘data’.

Artikel 2.4.3.15 Bericht F_GEEN_ETX

Het bericht F_GEEN_ETX is een foutmelding die gestuurd wordt bij het ontvangen tweemaal een STX teken zonder het tussentijds ontvangen van een ETX teken. Totale berichtgrootte: 7 bytes

EIS-LI-26	Het bericht F_GEEN_ETX bevat geen ‘data’.

Artikel 2.4.3.16 Bericht F_NIET_STANDAARD

Het bericht F_NIET_STANDAARD is een foutmelding die gestuurd wordt indien er een fout optreedt die niet gedefinieerd is in een van de overige foutberichten. Er wordt een omschrijving van de fout meegestuurd.

EIS-LI-27	De data in het bericht F_NIET_STANDAARD heef het volgende formaat:

FOUT_OMSCHR

String

Tekst met omschrijving van de opgetreden fout.

Totale berichtgrootte: variabel, minimaal 8 bytes, maximaal 264 bytes

Artikel 2.4.3.17 Bericht F_VELD_ONGELDIG

Het bericht F_VELD_ONGELDIG is een foutmelding die gestuurd wordt indien er een ongeldig veld gedetecteerd is in het vraagbericht. Bijvoorbeeld voor een ongeldige waarde in het veld ‘Status interface’ van het bericht VR_STATUS. Totale berichtgrootte: 7 bytes

EIS-LI-28	Het bericht F_VELD_ONGELDIG bevat geen ‘data’.

Artikel 2.4.4 Eisen met betrekking tot de performance

EIS-LI-29	Na het ontvangen van een vraagbericht dient het begin van een antwoord binnen 0,5 seconden verstuurd te zijn. De maximale verzendduur van een bericht bedraagt het dubbele van de tijd van het verzenden van een bericht op maximale snelheid.
EIS-LI-30	Opeenvolgende bytes worden met een tussentijd van maximaal 100ms verstuurd.
EIS-LI-31	Indien een vraagbericht is ontvangen wordt binnen de tijd als gespecificeerd in 0 een antwoordbericht (of indien van toepassing een foutbericht) teruggestuurd.

Artikel 2.5 Prioriteit en afhankelijkheid van eisen

Prioriteit 1 is de hoogste, 3 de laagste.

Tabel 8 – Prioriteiten van eisen.

Prioriteit	Eisen
1	Alle EIS-AL
2	Alle EIS-FI
3	Alle EIS-LI

TOELICHTING

Algemeen

1. Inleiding

Met deze regeling wordt invulling gegeven aan de artikelen 22, eerste en derde lid, 23, derde lid, en 24 van de Wegenverkeerswet.

In deze regeling zijn de eisen opgenomen waaraan een boordcomputer voor taxi’s moet voldoen en is de procedure voor de aanvraag en verlening van de typegoedkeuring neergelegd. Doel van deze boordcomputer is de digitalisering van de huidige handmatige registratie van de arbeids-, rij- en rusttijden, als vastgelegd in de Arbeidstijdenwet en het Arbeidstijdenbesluit vervoer en van de ritadministratie, als vastgelegd in het Besluit personenvervoer 2000.

De invoering van een boordcomputer in alle auto’s waarmee taxivervoer wordt verricht heeft als voordelen:

• a. een betrouwbaardere registratie van ritgegevens en arbeids-, rij- en rusttijden;

• b. een verbetering van de controle- en handhavingsactiviteiten;

• c. het minimaliseren van mogelijke frauduleuze praktijken doordat de consument op basis van de ritgegeven op het ritbewijs gemakkelijker actie kan ondernemen en eventueel tot het indienen van een klacht kan overgaan;

• d. een vermindering van de administratieve lasten, en

• e. een betere en meer volledige informatieverstrekking aan de consument door de afgifte van een ritbewijs.

Deze regeling vervangt de Regeling boordcomputer taxi, die is gepubliceerd op 11 november 2009 (Stcrt. 17001) en nog niet in werking was getreden. Op de reden voor deze vervanging wordt onder punt 2 nader ingegaan.

2. De boordcomputer

De boordcomputer is een digitaal systeem dat met behulp van boordcomputerkaarten de mogelijkheid biedt om verplichte gegevens over ritten, tarieven en rij- en rusttijden te registreren en aan te leveren. In deze regeling zijn de functionele en technische eisen waaraan de boordcomputer moet voldoen vastgelegd.

Naast de eisen met betrekking tot registratie en aanlevering hebben de functionele eisen betrekking op de sensoren die de boordcomputer in staat stellen de afgelegde afstand te meten. Hiertoe zijn twee sensoren voorzien, te weten een pulssensor en een GPS-sensor. Door gebruik te maken van twee sensoren die elkaar controleren, kunnen een aantal vormen van fraude beter worden voorkomen.

Op grond van de Regeling boordcomputer taxi, die door de onderhavige regeling wordt vervangen, was één eenvoudige vorm van fraude niet te voorkomen. Door de ontvangst van de GPS-antenne te verstoren en de pulsgever los te koppelen van de boordcomputer zou er gereden kunnen worden zonder dat de kilometers worden geregistreerd. De boordcomputer zou slechts registreren dat er geen GPS-dekking is. Nadat de frauduleuze kilometers zouden zijn verreden zou de chauffeur kunnen terugkeren naar de locatie waar de fraude begon, en de sensoren in de oude staat terugbrengen. De registratie van de boordcomputer zou volledig lijken, maar zou een aantal kilometers missen.

Deze vorm van fraude is thans opgelost door extra functionaliteit in de boordcomputer. Deze functionaliteit stelt de boordcomputer in staat om autonoom, dat wil zeggen zonder signalen van buitenaf, beweging in het voertuig op te merken.

De toevoeging van deze sensor, de verplaatsingsopnemer, heeft een zodanig aantal wijzigingen tot gevolg in de regeling en in de bijlagen, dat er ten behoeve van de overzichtelijkheid voor gekozen is om de regeling in haar geheel opnieuw vast te stellen.

Er wordt geen specifieke apparatuur of uitvoeringsvorm van de boordcomputer verplicht gesteld. De fabrikanten kunnen de apparatuur naar eigen inzicht ontwikkelen in samenspraak met de taxibranche. Om te garanderen dat de boordcomputer werkt conform deze regeling moeten de apparaten waarin deze functionaliteit gerealiseerd is goedgekeurd zijn. De procedures omtrent het gebruik van de boordcomputer en de kaarten, de erkenning van werkplaatsen en de activering van boordcomputers worden vastgelegd in aparte ministeriële regelingen.

De vaststelling van de functionaliteiten van de boordcomputer is geschied in nauw overleg met de taxibranche, de consumentenorganisaties en de vakbonden. Zoals hierboven is omschreven, ziet deze er als volgt uit:

• a. de digitale registratie van de ritadministratie;b. de digitale registratie van de arbeids-, rij- en rusttijden;c. de mogelijkheid tot aansluiting van bedrijfsapparatuur; d. het printen van een ritbewijs;

• e. de automatische positiebepaling van begin- en eindlocatie van de ritten; en

• f. de mogelijkheid om autonoom beweging in het voertuig op te merken.

Daarnaast zal de boordcomputer gebruik maken van een elektronische handtekening om de integriteit en de herkomst van de in de boordcomputer opgeslagen en gegenereerde gegevens te waarborgen.

Het staat de fabrikant en de taxiondernemer vrij om de boordcomputer uit te breiden met aanvullende functies, mits dit de werking van de voorgeschreven functionaliteit niet beïnvloedt en de goedgekeurde beveiligingsfuncties van de boordcomputer gehandhaafd blijven. De voorgeschreven functionaliteit en beveiligingsfuncties strekken er immers mede toe dat de bescherming van persoonsgegevens in voldoende mate en in overeenstemming met de Wet bescherming persoonsgegevens is geborgd. Genoemde functies strekken zich echter niet uit over de door fabrikanten en taxiondernemers zelf te ontwikkelen aanvullende functies. Fabrikanten en taxiondernemers zullen er bij de ontwikkeling van deze aanvullende functies dan ook voor zorg moeten dragen dat het bepaalde in de Wet bescherming persoonsgegevens in acht wordt genomen.

Uitsluitend op punten waar het noodzakelijk is om een uniformiteit in handelingen te bereiken zijn technische eisen opgenomen. Dat geldt voor de eisen die aan beveiliging worden gesteld (bijlage 1), voor de overbrenging van gegevens en de overbrengingsinterface (bijlage 2) en voor de interface ten behoeve van een koppeling van de taxameter aan de boordcomputer (bijlage 3). Aangezien de boordcomputer naar verwachting door verschillende fabrikanten op de markt zal worden gebracht, is het belangrijk om op deze drie terreinen gedetailleerde eisen te stellen.

Bijlage 1 bevat een beschrijving van het beveiligingsprofiel van de boordcomputer dat in overeenstemming is met de Common Criteria for Information Technology Security Evaluation, versie 3.1. Deze Common Criteria zijn een internationale standaard (ISO-IEC 15408) voor de certificering van computerbeveiliging. Met behulp van het Common Criteria raamwerk zijn de beveiligingseisen in bijlage 1 opgesteld, waarna deze door de fabrikanten kunnen worden geïmplementeerd.

Een testlaboratorium kan vervolgens met behulp van hetzelfde raamwerk evalueren of aan de eisen is voldaan.

Het beveiligingsprofiel geeft een beschrijving van de door de boordcomputer te neutraliseren bedreigingen en van de te realiseren beveiligingsdoelstellingen. Voorts worden de vereiste beveiligingsfuncties gespecificeerd en wordt de vereiste minimumsterkte van de beveiligingsmechanismen en het vereiste garantieniveau voor de boordcomputer vastgesteld. Met de boordcomputer kunnen, overigens net als bij de huidige handmatige registratie, persoonsgegevens beschikbaar komen zodat het van belang is om beveiligingsmechanismen in het leven te roepen. De vastgelegde gegevens dienen dusdanig te worden geregistreerd en verwerkt dat de privacy van de taxichauffeur kan worden gewaarborgd. Gegevens waarbij inbreuk kan ontstaan op de persoonlijke levenssfeer van de taxichauffeur dienen alleen toegankelijk te zijn voor bevoegde personen onder vastgelegde omgangsregels. In overeenstemming met de Wet bescherming persoonsgegevens worden daarom aanvullende maatregelen getroffen (Privacy Enhancing Technologies).

In bijlage 2 is vastgelegd aan welke eisen de overbrenging van gegevens en de overbrengingsinterface moeten voldoen. Zo wordt bereikt dat de boordcomputer ten behoeve van handhavingsdoeleinden op een uniforme wijze gegevens ter beschikking stelt. In bijlage 3 wordt een uniforme, open ingang beschreven. Deze interface maakt mogelijk dat in principe iedere taxameter aan een willekeurige boordcomputer kan worden gekoppeld. Op deze manier wordt voorkomen dat er op de Nederlandse markt praktisch gezien uitsluiting plaatsvindt van bepaalde taxameters.

De boordcomputer raakt niet aan richtlijn 2004/22/EG betreffende meetinstrumenten. In die richtlijn is ook het meetinstrument taxameter opgenomen. De boordcomputer heeft een andere functie dan de taxameter. De boordcomputer registreert de arbeids-, rij- en rusttijden en de ritadministratie, terwijl de taxameter de prijs van een taxirit berekent. Wel zal de door de taxameter berekende ritprijs worden geregistreerd in de boordcomputer.

3. De goedkeuringsprocedure

In deze regeling is de typegoedkeuring van boordcomputers door de Dienst Wegverkeer opgenomen. De typegoedkeuring geschiedt op grond van artikel 22, eerste en derde lid, van de Wegenverkeerswet. De Dienst Wegverkeer behandelt niet alleen de aanvragen om typegoedkeuring, maar houdt ingevolge artikel 23, eerste lid, van de Wegenverkeerswet 1994 ook na het verlenen van typegoedkeuring toezicht op de overeenstemming van productie waardoor wordt geborgd dat de boordcomputers die door een fabrikant worden geproduceerd identiek zijn aan de boordcomputer waarvoor de typegoedkeuring is verleend.

Uitgangspunt bij het proces van de typegoedkeuring is dat de aanvraagprocedure bij de Dienst Wegverkeer pas start nadat de fabrikant door middel van testen en certificering zelf heeft laten vaststellen dat de door hem ontwikkelde boordcomputer voldoet aan de gestelde eisen. Hierdoor houdt de fabrikant de regie over de test- en certificeringfase en kan hij deze fase naar eigen goeddunken laten aansluiten op of zelfs deels integreren in de fase van de productontwikkeling. Productcertificering en het testen van de boordcomputer vergen een intensieve interactie tussen de fabrikant en de betreffende testinstelling waarbij het aanpassen van de boordcomputer dan wel de bijbehorende specificaties eerder regel dan uitzondering is. Hierbij kan de fabrikant zelf de volgorde van de verschillende testen bepalen en een eigen keuze voor een bepaalde testinstelling maken, bijvoorbeeld omdat deze testinstelling veel ervaring heeft met de door de betreffende fabrikant gebruikte software. Tegenover deze voordelen staat echter wel dat de fabrikant ook de verantwoordelijkheid draagt voor de kwaliteit en volledigheid van de uitgevoerde testen en opgeleverde testrapporten.

Op aanvraag van een fabrikant beoordeelt de Dienst Wegverkeer of een boordcomputer voldoet aan de eisen die daartoe in paragraaf 2 zijn opgenomen. Daarbij wordt ook getoetst of de overeenstemming van productie afdoende is geborgd. Goedkeuring wordt slechts verleend indien de Dienst Wegverkeer op grond van de aanvraag kan vaststellen dat de boordcomputer aan alle gestelde eisen voldoet. Daarbij geldt niet als beoordelingscriterium of de testrapporten twijfels oproepen of hiaten vertonen, maar of op grond van de testrapporten buiten redelijke twijfel komt te staan dat de betreffende boordcomputer aan alle eisen voldoet. Indien daarover op één of meer punten onvoldoende duidelijkheid bestaat, wordt goedkeuring geweigerd. De kwaliteit van de beproevingen en de daarvan opgestelde testrapporten speelt een cruciale rol bij de beoordeling. De Dienst Wegverkeer hecht waarde aan het gebruik van algemeen erkende en wetenschappelijk onderbouwde werkwijzen en normenstelsels en de algemene kwaliteitsborging die door de betreffende testinstelling wordt toegepast. Als de testen zijn uitgevoerd door testinstellingen die werken met internationaal geaccepteerde normenkaders en de kwaliteit van hun werk hebben geborgd door middel van accreditatie of certificatie, kan dit leiden tot een meer marginale en daarmee snellere toetsing door de Dienst Wegverkeer. Immers, in deze gevallen wordt de kwaliteit voor een belangrijk deel geborgd door de toepassing van reeds bewezen werkwijzen en methodieken.

De scherpe beoordelingsmaatstaf hangt samen met het feit dat het hier gaat om de goedkeuring van een controleapparaat dat onder meer de gegevens gaat genereren waarop handhavingsbesluiten zullen worden gebaseerd, dan wel op grond waarvan door de betreffende toezichthouder wordt geconcludeerd dat er geen sprake is van een overtreding van de geldende wet- en regelgeving. Als de Dienst Wegverkeer een typegoedkeuring verleent, mag er dan ook geen enkele twijfel over bestaan dat het apparaat aan alle gestelde eisen voldoet. Het is daarmee de verantwoordelijkheid van de fabrikant om aan de hand van zijn aanvraag en de daarbij gevoegde stukken buiten twijfel te stellen dat de door hem te produceren boordcomputer voldoet aan alle gestelde eisen.

Door middel van het vaststellen van een aanvraagformulier en overige administratieve voorschriften kan de Dienst Wegverkeer zoveel mogelijk vooraf duidelijkheid verschaffen over de wijze waarop de aanvragen en de testrapporten moeten worden ingericht. Ook verstrekt de Dienst Wegverkeer desgevraagd vooraf informatie aan fabrikanten en testhuizen over de aanvraagprocedure en de beoordeling van testrapporten. De Dienst Wegverkeer kan indien dit nodig is voor een juiste beoordeling van de aanvraag een nader onderzoek verrichten of laten verrichten. Bijvoorbeeld ter beoordeling van de waarde van de verrichtte beproevingen of de waardering van toegepaste onderzoeksmethodieken.

Als aan alle eisen wordt voldaan, kan een goedkeuring worden verleend en mogen boordcomputers van dit type worden ingebouwd in taxi’s. Aanvullend aan de onderhavige typegoedkeuring wordt ook voorzien in een activeringskeuring die na de inbouw van een boordcomputer in een individuele taxi moet plaatsvinden. Doel van deze keuringen is te borgen dat iedere taxi beschikt over een goed functionerende en betrouwbare boordcomputer.

Een zeer belangrijk deel van de eisen waaraan de boordcomputer moet voldoen wordt afgedekt door een beveiligingscertificaat op ten minste niveau EAL 3 dat door een Common Criteria geaccrediteerde testinstelling is afgegeven. Alleen testhuizen die daartoe volgens Common Criteria zijn geaccrediteerd kunnen dit certificaat afgeven nadat zij hebben vastgesteld dat een boordcomputer voldoet aan de gestelde beveiligingseisen. Het daartoe benodigde beveiligingsprofiel (ook wel ‘protection profile’ genoemd) is in bijlage 1 van de regeling opgenomen.

In het kader van de Common Criteria wordt een vastgestelde werkwijze gehanteerd die voldoende waarborgen bevat om de beveiligingseisen af te dekken. In het kader van deze werkwijze wordt door de testinstelling tezamen met het beveiligingscertificaat een daarbij behorend Certification Report en Security Target verstrekt. Hierin worden onder meer de eventueel door de testinstelling bij de certificering gemaakte opmerkingen opgenomen. Ook deze stukken dienen bij de aanvraag te worden overgelegd zodat een goede beoordeling door de Dienst Wegverkeer mogelijk is.

4. Administratieve lasten bedrijfsleven en bedrijfseffecten

De gevolgen voor de administratieve lasten en de bedrijfseffecten van deze regeling zijn niet separaat beoordeeld, maar zijn in overleg met het Adviescollege toetsing administratieve lasten meegenomen bij de wijziging van het Besluit personenvervoer 2000, het Arbeidstijdenbesluit vervoer en het Reglement rijbewijzen in verband met de invoering van de boordcomputer taxi, de afschaffing van de vergunning voor collectief personenvervoer en een technische wijziging in verband met het elektronisch vervoerbewijs. De wijzigingen van de regelgeving die nodig zijn voor de invoering van de boordcomputer taxi betreffen immers een op elkaar afgestemd geheel van regelgeving waarvoor een integrale beoordeling van de gevolgen voor de administratieve lasten op zijn plaats is. De totale jaarlijkse administratieve lasten voor bedrijven dalen na de invoering van de boordcomputer taxi met ruim € 4,6 miljoen per jaar. De administratieve lasten die tot de typegoedkeuring van de boordcomputer zijn te herleiden, zijn berekend op € 299.100,–.

5. Handhaving: toezicht en controle

In de controlemodus ondersteunt de boordcomputer de uitvoering en handhaving van wet- en regelgeving. De toezichthouders kunnen de gegevens die op de boordcomputer en op de boordcomputerkaarten geregistreerd zijn overbrengen (downloaden). Tevens zal de handhavingsapparatuur deze gegevens kunnen interpreteren. Deze handhavingsapparatuur valt buiten de reikwijdte van deze regeling.

De Dienst Wegverkeer verleent niet alleen de goedkeuring maar heeft ten aanzien hiervan ook een controlerende en handhavende taak. Zo ziet de Dienst Wegverkeer toe op het naleven van de aan de goedkeuring verbonden voorwaarden. Indien een fabrikant de overeenstemming van productie onvoldoende waarborgt, kan de Dienst Wegverkeer de verleende goedkeuring intrekken.

6. Advies Overlegorgaan personenvervoer

Het ontwerp van paragraaf 2 van deze regeling en de bijbehorende bijlagen is op 4 februari 2008 voorgelegd aan het Overlegorgaan personenvervoer (OPV). Het OPV heeft op 13 februari 2008 een rapport uitgebracht over de ontwerpregeling. Het OPV heeft op 9 mei 2008 een rapport uitgebracht over de ontwerpregeling van paragraaf 3 van deze regeling, de typegoedkeuring. In dit tweede rapport wordt aangegeven dat de organisaties in het OPV op enkele kanttekeningen na instemmen met de regeling van de goedkeuring. De kanttekeningen met betrekking tot de toelichting zijn verwerkt. Voorts is een kanttekening gemaakt bij het feit dat in de aanhef bij de conceptregeling een verwijzing naar artikel 9:1, eerste lid van de Arbeidstijdenwet ontbreekt. Terecht wordt opgemerkt dat ook artikel 9:1, eerste lid, van de Arbeidstijdenwet een basis biedt voor de bevoegdheid van de Dienst Wegverkeer om een typegoedkeuring te verlenen aan een boordcomputer, maar ook artikel 22, eerste lid, van de Wegenverkeerswet 1994 geeft daartoe een rechtsgrond. Met deze regeling is gekozen voor de rechtsgrond van de Wegenverkeerswet 1994 en de toezichtsbevoegdheden die de Dienst Wegverkeer daarbij op grond van artikel 23 van genoemde wet heeft.

Het OPV constateert in het rapport van 13 februari 2008 dat het de bedoeling is dat de totale ritprijs wordt afgedrukt. Het OPV stelt als wijziging daarop evenwel voor dat het nieuwe systeem middels een bewerking ook moet voorzien in extra informatie over toeslagen (bijv. koffers dragen) en kortingen. Het ritbewijs geeft dan weer: de ritprijs, de toeslagen/kortingen en de eindprijs. Voorts wordt gevraagd in de toelichting nader in te gaan op de motivering om spraakherkenning voor speciale groepen reizigers niet mogelijk te maken. Tenslotte heeft het OPV zich afgevraagd hoe met de registratie van fooien omgegaan moet worden. Het OPV spreekt de voorkeur uit voor een handmatige vermelding van de gegeven fooi op het ritbewijs.

In artikel 11 is aan de gegevens die de boordcomputer beschikbaar dient te stellen ten behoeve van het ritbewijs een aantal gegevens toegevoegd. Er wordt onderscheid gemaakt tussen de prijs van het vervoer per rit (de ritprijs), eventueel in rekening gebrachte toeslagen en de totaalprijs. In de regeling is geen verplichting opgenomen ten aanzien van fooien. Vervoerders kunnen dit bedrag – zoals het OPV voorstelt – handmatig op het ritbewijs laten opnemen door de desbetreffende chauffeur. Indien vervoerders gegevens ten aanzien van fooien wel door de boordcomputer beschikbaar willen laten stellen dan mag dat ook. In de toelichting bij artikel 11 is een passage opgenomen over het niet opnemen van spraakherkenning. Voorts acht het OPV het gewenst dat de boordcomputer zoveel mogelijk gegevens automatisch kan registreren, ook die over de ritopbouw en toeslagen. Het OPV steunt daarom het beeld dat de nieuwe taxameter op basis van de Metrologiewet in de toekomst standaard zal worden.

De toelichting is uitgebreid naar aanleiding van de opmerkingen van het OPV over het uitlezen van de digitale gegevens in de boordcomputer en op de boordcomputerkaarten op het bedrijf.

Het OPV wijst er ten slotte op dat - met de harde waarborg dat alleen met toestemming van het Openbaar Ministerie (OM) toegang tot deze gegevens kan worden verkregen - de GPS- coördinaten ook tijdens de privéstand van de boordcomputer moeten worden geregistreerd. Aan deze opmerking van het OPV is gevolg gegeven. De regeling is zodanig aangepast dat ook indien er geen sprake is van taxivervoer toch GPS-data worden vastgelegd. Daarbij is uitdrukkelijk aandacht besteed aan de privacy van de bestuurder.

7. Onderdeel van totale overig regelgeving

Deze regeling vormt een onderdeel van de totale regelgeving die nodig is om het gebruik van de boordcomputer te verplichten. De wettelijke basis voor invoeringvan de boordcomputer taxi is gelegen in het Besluit personenvervoer 2000 en het Arbeidstijdenbesluit vervoer. Naast de onderhavige regeling die is gebaseerd op de Wegenverkeerswet 1994, wordt ook voorzien in een Regeling betreffende het gebruik van de boordcomputer en de verschillende boordcomputerkaarten (zoals de chauffeurskaart, de inspectiekaart en de ondernemerskaart) en in een regeling met betrekking tot de erkenning van werkplaatsen en de activering van boordcomputers.

8. Notificatie

De ontwerp-regeling met de technische specificaties is op 16 juni 2008, op 23 december 2008 en op 17 februari 2010 ingevolge richtlijn 98/34/EG ter notificatie voorgelegd. Hierop zijn geen reacties ontvangen.

Artikelsgewijs

Artikel 2

Artikel 2 bepaalt uit welke elementen de boordcomputer bestaat.

Tijdens de productie wordt de boordcomputer door de fabrikant voorzien van een systeemkaart. De systeemkaart heeft de vorm van een SIM-kaart, zoals in mobiele telefoons gebruikelijk wordt toegepast. De systeemkaart bevat onder andere het serienummer van de boordcomputer, de typeaanduiding van de boordcomputer en de naam van de fabrikant. Zo wordt bereikt dat de digitale handtekening die de systeemkaart plaatst onlosmakelijk aan de boordcomputer wordt verbonden.

Onderdeel van de boordcomputer vormt de interface voor de bewegingsopnemer en de interface voor de positiebepalingssensor of de positiebepalingssensor zelf. Deze bepaling houdt in dat de positiebepalingssensor soms niet en de bewegingsopnemer nooit onderdeel uitmaakt van de boordcomputer, bedoeld in deze regeling. Dit laat onverlet dat voor een correcte werking van het apparaat wel vereist is dat deze sensoren gekoppeld zullen moeten worden aan de boordcomputer. Om dit te bereiken is de verplichting opgenomen dat de boordcomputer op correcte wijze functioneert en dat er een activeringsonderzoek uitgevoerd dient te zijn alvorens de boordcomputer wordt gebruikt.

Het tweede en derde lid bepalen dat het toegestaan is om de boordcomputer door middel van additionele verbindingen aan andere inrichtingen te koppelen. Zo wordt mogelijk gemaakt dat er bedrijfsapparatuur aan de boordcomputer gekoppeld kan worden. Het staat de fabrikant en taxiondernemer vrij deze apparatuur aan de boordcomputer te koppelen, zolang dit er maar niet toe leidt dat dit de juiste en betrouwbare werking van de boordcomputer schaadt of ertoe kan leiden dat onzorgvuldig met persoonsgegevens wordt omgegaan. Ten aanzien van deze additionele apparatuur geldt dat bij de ontwikkeling en het gebruik ervan wel rekening gehouden moet worden met het bepaalde in de Wet bescherming persoonsgegevens als het gaat over de privacy van bijvoorbeeld de werknemer en de consument. In dit verband wordt nog verwezen naar het gestelde onder paragraaf 3.

Artikel 3

De boordcomputer registreert datum en tijd op basis van Universal Time Coordinated (UTC). De registratie op basis van UTC komt voort uit het uitgangspunt om de boordcomputer zo min mogelijk te laten interpreteren. Bij UTC wordt geen correctie voor zomer of wintertijd toegepast. Verder wordt UTC meegezonden via de satelliet positiebepalingsystemen waardoor het eenvoudig wordt om de tijd te verifiëren. De boordcomputer gebruikt UTC zodat er geen interpretatieverschillen kunnen ontstaan bij keuringen en controles. De tijd die door de boordcomputer aan de gebruiker wordt getoond is de plaatselijke tijd.

Artikel 4

De boordcomputer kent vier werkingsmodi, te weten: een operationele modus, een controle modus, een activerings- en keuringsmodus en een bedrijfsmodus. De eerste twee modi zijn een afspiegeling van de bedrijfsprocessen ondersteund door de boordcomputer, terwijl de keurings- en bedrijfsmodi er zijn om de boordcomputer te configureren voor de specifieke gebruiksomstandigheden. Er worden vier gebruikersrollen voorzien, te weten bestuurder, toezichthouder, werkplaats en vervoerder. Voor elke gebruikersrol geldt een specifieke werkingsmodus. De omschakeling tussen de verschillende modi geschiedt doordat er een andere boordcomputerkaart geplaatst wordt in de boordcomputer. Er worden vier verschillende boordcomputerkaarten onderscheiden, te weten: chauffeurskaart, inspectiekaart, keuringskaart en ondernemerskaart.

De standaard werkingstoestand van de boordcomputer is de operationele modus. Deze operationele modus bestaat weer uit drie werkingsniveaus: basis, arbeidstijd en taxivervoer. Het werkingsniveau basis is altijd ingeschakeld. Ook als daarnaast de controle-, bedrijfs- of activerings en keuringsmodus is ingeschakeld. De bestuurder zal handmatig de andere twee werkingsniveaus in moeten schakelen. Indien er taxivervoer wordt verricht zal in het werkingsniveau taxivervoer de ritadministratie bijgehouden worden. Er is dan tevens sprake van arbeidstijd. Dit houdt in dat ook het werkingsniveau arbeidstijd ingeschakeld moet zijn. In dit werkingsniveau worden de arbeids-, rij- en rusttijden geregistreerd. Indien een bestuurder geen taxivervoer verricht, maar wel werkzaamheden verricht, is het werkingsniveau taxivervoer uitgeschakeld, maar vindt wel een arbeidstijd plaats in het desbetreffende werkingsniveau.

De boordcomputer dient tevens de toegang van iedere gebruiker te beperken in overeenstemming met de werkingsmodi. Bovendien zal de boordcomputer voldoende gedetailleerde informatie moeten vastleggen over de handeling met of door de boordcomputer verricht om aantoonbaar te maken dat de geregistreerde gegevens juist zijn verkregen en correct zijn verwerkt.

Artikelen 5, 6 en 7

De afstandmeting in de boordcomputer komt tot stand door gebruikmaking van twee sensoren, een bewegingsopnemer en een satelliet positiebepalingsensor. Als bewegingsopnemer kan een bestaande voertuigsensor worden gebruikt. Voor de positiebepaling is vooralsnog voornamelijk het Global Positioning System (GPS) beschikbaar. Op termijn zal hier Gallileo aan toegevoegd kunnen worden. Er zijn geen specifieke technische voorschriften hoe de sensoren en de boordcomputer onderling dienen te zijn verbonden. Leveranciers zijn bijvoorbeeld vrij om voor de koppelingen tussen de verschillende componenten de Controller Area Network (CAN-bus) te gebruiken.

Door de afstand te bepalen door gebruikmaking van twee verschillende sensoren wordt deze meting nauwkeuriger en minder fraudegevoelig. De afgelegde afstand wordt primair gemeten met de bewegingsopnemer en wordt geverifieerd met de positiebepalingsensor.

Om fraude met de bewegingsopnemer te voorkomen is de boordcomputer in staat om autonoom een verplaatsing van de auto vast te stellen met behulp van de verplaatsingsopnemer.

Daarnaast levert de positiebepalingsensor tevens per rit de begin- en eindpositie van de auto. Artikel 6 bepaalt dat de boordcomputer met een interval van één maal per minuut de positiegegevens van de auto vastlegt. Deze positiegegevens worden dus in alle werkingsmodi geregistreerd. Reden voor de opslag van deze positiegegevens is het feit dat er nog een aantal handmatige handelingen blijft bestaan. Zonder het handmatig inschakelen van het werkingsniveau taxivervoer kan de boordcomputer niet vaststellen dat er taxivervoer verricht wordt. Evenmin kan de boordcomputer vaststellen of er sprake is van een beladen of van een onbeladen rit zonder dat de bestuurder dit in de boordcomputer invoert. Deze handmatige handelingen vormen voor de kwaadwillende bestuurder of vervoerder een mogelijkheid om fraude te plegen. Indien er sprake is van een vermoeden van fraude is het belangrijk om – in zeer beperkte gevallen – de positiegegevens van de auto te kunnen achterhalen.

Om de privacy van de bestuurder van de auto te beschermen is de inzage in deze gegevens tot een minimum beperkt. Geen van de in artikel 4 onderscheiden gebruikers heeft rechtstreeks toegang tot deze positiegegevens. In artikel 79, derde en vierde lid, van het Besluit personenvervoer 2000 is vastgelegd dat op de vervoerder de verplichting rust om via de boordcomputer een aantal gegevens te registreren. Het niet naleven van deze bepaling vormt via artikel 118 van het Besluit personenvervoer 2000 een strafbaar feit als bedoeld in artikel 1, onder 4°, van de Wet op de economische delicten. Op grond van artikel 18 en 19 van de Wet op de economische delicten zijn opsporingsambtenaren in het belang van de opsporing bevoegd tot inbeslagneming van daartoe vatbare voorwerpen en tot het vorderen van inzage in gegevens en bescheiden. Op basis daarvan is het mogelijk om inzage te vorderen in de in de boordcomputer vastgelegde positiegegevens. Om oneigenlijke inzage in deze positiegegevens te voorkomen is via de toegangsrechten die de verschillende boordcomputerkaarten bieden geborgd dat geen van de houders van deze kaarten toegang heeft tot de positiegegevens. Uitsluitend indien er sprake is van een vermoeden van overtreding van artikel 79 van het Besluit personenvervoer 2000 kan op aangeven van een opsporingsambtenaar in de zin van de Wet op de economische delicten inzage plaatsvinden in de positiegegevens. Die situatie kan zich voordoen indien er een vermoeden bestaat dat een bestuurder taxivervoer heeft verricht terwijl hij dit niet als zodanig in de boordcomputer heeft geregistreerd. Op verzoek van de desbetreffende opsporingsambtenaar kunnen de positiegegevens bij de deactivering van de boordcomputer uit het apparaat gehaald worden. Zie daarvoor ook de toelichting bij artikel 23. Een dergelijke minimale toegangsmogelijkheid tot deze positiegegevens is in overeenstemming met de eisen van proportionaliteit die de Wet bescherming persoonsgegevens voorschrijft. Immers, uitsluitend bij een vermoeden van fraude mag een opsporingsambtenaar toegang verkrijgen tot genoemde positiegegevens. De inbreuk op de privacy blijft daarmee beperkt tot die gevallen.

Artikel 8

De boordcomputer verwerkt en registreert gegevens op een betrouwbare wijze. Dit komt tot uiting in het waarborgen van de vertrouwelijkheid, integriteit en beschikbaarheid van de op de boordcomputer geregistreerde gegevens. De vertrouwelijkheid van deze gegevens wordt geborgd doordat zij alleen zijn in te zien door kaarthouders die voor inzage in die gegevens, of een deel daarvan, gemachtigd zijn. De boordcomputer moet daarnaast garanderen dat de geregistreerde gegevens gedurende een bepaalde periode beschikbaar zijn.

Door gebruik te maken van een elektronische handtekening over de geregistreerde gegevens is het niet mogelijk om deze gegevens ongemerkt te veranderen. Hierdoor is de integriteit van de gegevens gewaarborgd. Bijkomend effect van het gebruik van een elektronische handtekening is dat identiteit van degene die de handtekening plaatst onomstotelijk vast komt te staan.

Artikel 9

De boordcomputer legt het arbeids-, rij- en rusttijdenpatroon van de bestuurder vast. De arbeids-, rij- en rusttijden worden opgeslagen op de persoonsgebonden chauffeurskaart én op het geheugen van de boordcomputer. Doordat de rij- en rusttijden ook op de chauffeurskaart geregistreerd worden heeft de bestuurder altijd volledige beschikking over zijn eigen rij- en rusttijdenadministratie, ook als hij zijn werkzaamheden op meerdere voertuigen heeft uitgevoerd. Op de boordcomputer worden de rij- en rusttijden opgeslagen van de verschillende bestuurders die werkzaamheden op het voertuig hebben uitgevoerd.

De geregistreerde arbeids-, rij- en rusttijden worden door de chauffeurskaart voorzien van een elektronische handtekening. De boordcomputer toont op het leesscherm de gegevens waarover de elektronische handtekening wordt gezet. Voor het plaatsen van de elektronische handtekening is het noodzakelijk om een PIN-code in te voeren. Indien er geen chauffeurskaart in de boordcomputer is ingebracht zal de boordcomputer de gegevens met behulp van een systeemkaart van een elektronische handtekening voorzien.

Om een volledig overzicht van zijn arbeids-, rij- en rusttijden te krijgen moet de bestuurder zijn kaart buiten de boordcomputer met een kaartlezer uitlezen. Hiervoor is specifieke programmatuur vereist.

Artikel 10

Naast de arbeids-, rij- en rusttijden registreert de boordcomputer de ritadministratie. In artikel 79, derde en vierde lid, van het Besluit personenvervoer 2000 is vastgelegd welke gegevens daartoe worden geregistreerd. Het is ook mogelijk om per zitplaats een ritadministratie bij te houden. De boordcomputer slaat deze ritadministratie, die voertuiggebonden is, op in het geheugen. Artikel 79 eist onder andere dat de totale ritprijs wordt vastgelegd. De ritprijs wordt via een koppeling met de aanwezige taxameter in de boordcomputer gebracht ofwel de bestuurder voert hiertoe handmatig de ritprijs in. Indien de in het voertuig aanwezige taxameter in staat is om de benodigde gegevens aan de boordcomputer aan te leveren is deze koppeling verplicht. Alleen als de taxameter hier niet toe in staat is mag de bestuurder de benodigde gegevens handmatig op de boordcomputer invoeren.

Het is essentieel dat de herkomst van gegevens kan worden getraceerd en dat eventuele wijzigingen van geregistreerde gegevens kunnen worden ontdekt. Bovendien zal de vastlegging dusdanig moeten plaatsvinden dat de herkomst onbetwistbaar is (onweerlegbaarheid). Daarnaast is het essentieel dat de juiste werking van de boordcomputer kan worden gecontroleerd en dat de eventuele wijzigingen en fouten bij het verder verwerken of uitwisselen van de gegevens kunnen worden gedetecteerd. Om dit te bereiken plaatst de boordcomputer onder meer per uitgevoerde rit een elektronische handtekening over alle ritgegevens met de systeemkaart van de boordcomputer. Ondertekening van de boordcomputer met behulp van de systeemkaart waarborgt dat de geregistreerde gegevens altijd kunnen worden herleid naar de desbetreffende boordcomputer.

Artikel 11

Aan het einde van de rit stelt de boordcomputer gegevens ter beschikking voor het afdrukken van een ritbewijs ten behoeve van de klant. Hoewel ook overwogen is om ten behoeve van blinden en slechtzienden een voorziening te treffen van een gesproken ritbewijs, is besloten hiertoe niet over te gaan. Het toevoegen van de eis van een gesproken ritbewijs zou een erg kostbare aangelegenheid inhouden, terwijl het om een vrij kleine groep gebruikers gaat.

Bovendien geldt dat het merendeel van deze groep gebruik maakt van zogenaamd contractvervoer, in plaats van straattaxivervoer. De opdrachtgevers (zoals gemeenten, zorgverzekeraars) van deze vorm van taxivervoer zouden aan taxivervoerders bij de gunning van een contract de eis kunnen stellen dat men zorgt voor een boordcomputer die wèl een gesproken ritbewijs kan leveren. De eisen die in deze regeling zijn opgenomen staan hieraan in ieder geval niet in de weg.

Dit ritbewijs bevat onder meer het P-nummer van de ondernemersvergunning, kenteken van de auto, informatie om een klacht te kunnen indienen, het nummer van de chauffeurskaart, de datum en het tijdstip waarop de rit is uitgevoerd, de afgelegde afstand en de totale prijs van de rit inclusief toeslagen. Ook worden de coördinaten van de vertrek- en aankomstplaats van de rit ter beschikking gesteld door de boordcomputer ten behoeve van het ritbewijs. Het staat de vervoerder overigens vrij om meer gegevens op het ritbewijs de plaatsen dan dit artikel vereist. Zo is het bijvoorbeeld mogelijk dat een ondernemer naast het P-nummer van de vergunning ook zijn bedrijfsnaam vermeldt.

Voor dit moment is gekozen om de vermelding van de coördinaten van de vertrek- en aankomstplaats verplicht te stellen in plaats van straatnamen. Deze coördinaten kunnen op diverse internetsites eenvoudig worden herleid tot een straatnaam en plaats. Het Ministerie van Verkeer en Waterstaat zorgt dat er een site voor de consumenten beschikbaar komt. Een verplichte vertaling door de boordcomputer van de coördinaten tot straatnaamniveau in de boordcomputer zelf zou inhouden dat alle boordcomputers voorzien zouden moeten worden van accuraat kaartmateriaal. Het is op dit moment nog niet goed mogelijk om de betrouwbaarheid van die vertaling te garanderen. Boordcomputers zouden namelijk uitgerust kunnen zijn met onbetrouwbare kaarten. Op vrijwillige basis zullen er hoogstwaarschijnlijk wel systemen op de markt komen die naast de coördinaten ook de straatnaam op het ritbewijs plaatsen. Het is goed voorstelbaar dat taxiondernemers die gebruik maken van deze systemen ervoor kiezen om het ritbewijs uit te breiden met de straatnamen.

De totale ritprijs bestaat uit de prijs voor het vervoer en de eventuele toeslagen voor aanvullende diensten. Er zijn momenteel nog vrijwel geen taxameters op de markt die de opbouw van de totale ritprijs inzichtelijk kunnen maken en deze ook kunnen overbrengen naar de boordcomputer. Taxameters die voldoen aan de eisen zoals die zijn vastgelegd in de Metrologiewet en onderliggende regelgeving kunnen dergelijke informatie in ieder geval wel leveren. Het is op basis van de Metrologiewet echter nog toegestaan om taxameters in de handel te brengen en te gebruiken die een goedkeuring hebben op basis van oudere regelgeving. Onderzocht wordt of de taxameter die voldoet aan de eisen zoals gesteld in de Metrologiewet op korte termijn verplicht kan worden gesteld voor alle auto’s waar taxivervoer mee verricht wordt. Omdat er op dit moment nog voertuigen op de markt zijn die zijn uitgerust met taxameters die de prijs niet kunnen doorgeven aan de boordcomputer maakt deze regeling mogelijk dat de totale prijs van het vervoer handmatig in de boordcomputer kan worden ingevoerd.

De boordcomputer hoeft op basis van deze regeling alleen gegevens ter beschikking te stellen voor het afdrukken van het ritbewijs. Dat betekent dat de printer zelf niet binnen de reikwijdte van deze regeling valt. In de auto dient wel een ritbewijs afgedrukt te kunnen worden voor de consument.

Artikelen 12 en 13

De boordcomputer kan, in de bedrijfsmodus, de activerings- en keuringsmodus- en de controlemodus, gegevens exporteren naar een opslagmedium of extern aangesloten systeem. Daartoe beschikt de boordcomputer over een overbrengingsinterface ten behoeve van de gegevensoverdracht naar externe bedrijfs- en handhavingsapplicaties. In bijlage 2 van de regeling worden zowel de overbrengingsinterface als het overbrengingsformaat verplichtend vastgelegd. Zo wordt een uniforme, fabrikant-onafhankelijke gegevensoverbrenging ten behoeve van het toezicht bereikt. Aangezien artikel 6 bepaalt dat de positiegegevens zodanig opgeslagen worden dat zij alleen bij deactivering overgebracht en ingezien kunnen worden zijn deze positiegegevens uitdrukkelijk uitgezonderd van de standaard gegevensoverbrenging zoals die vastgelegd is in de artikelen 12 en 13. Het gegevensformaat van overdracht van deze gegevens wordt ook in bijlage 2 gespecificeerd. Indien er gegevens worden overgebracht dan dient hiervan registratie plaats te vinden op de boordcomputer zodat dit bij een eventuele latere controle kan worden getraceerd.

Minstens zo belangrijk is dat de gegevens ook nadat deze zijn overgebracht naar een externe gegevensdrager herleidbaar blijven naar de desbetreffende boordcomputer. Hierbij moet niet alleen de herkomst kunnen worden geverifieerd, maar eveneens moet kunnen worden vastgesteld dat de gegevens niet zijn gewijzigd. Om dit te bereiken plaatst de boordcomputer een elektronische handtekening over alle uitgevoerde gegevens met het certificaat van de boordcomputer zoals deze is vastgelegd in de systeemkaart van de boordcomputer. Bovendien behoort de boordcomputer de beveiligingskenmerken, zoals de elektronische handtekening zelf, mee uit te voeren als een integraal onderdeel van de overgebrachte gegevens. Op deze wijze kan onafhankelijk van de boordcomputer later de integriteit en authenticiteit van de gegevens onweerlegbaar worden geverifieerd.

Naast de gegevensoverbrenging via de in bijlage 1 vastgelegde overbrengingsinterface kunnen er op twee andere manieren gegevens worden overgebracht.

In artikel 12, vierde lid, wordt de mogelijkheid geboden om de gegevens conform de in bijlage 3 gespecificeerde gegevensopmaak via een andere overbrengingsinterface over te brengen. Daarbij kan bijvoorbeeld gedacht worden aan een GPRS-verbinding.

Aan de overbrenging van gegevens, bedoeld in artikel 13, worden geen eisen gesteld voor wat betreft de opmaak van de gegevens en de te gebruiken interface. Deze gegevens zijn derhalve niet geschikt voor toezichtsdoeleinden, aangezien deze gegevens niet voorzien hoeven te zijn van een elektronische handtekening in de zin van deze regeling. De taxiondernemer kan hiermee aanhaken op bestaande communicatiesystemen tussen voertuig en bedrijf. Op een dergelijke overbrenging zijn altijd de gegevenstoegangsrechten van de bedrijfsmodus van toepassing.

Artikel 14

De boordcomputer wordt automatisch ingeschakeld zodra het contact van de auto wordt ingeschakeld. Het is ook mogelijk om de boordcomputer eerder handmatig aan te zetten. Als de auto wordt uitgeschakeld blijft de boordcomputer ingeschakeld. Het uitschakelen van de boordcomputer geschiedt handmatig. Zo wordt voorkomen dat bij het uitschakelen van de motor van de auto bij bijvoorbeeld wachten op de standplaats, of voor een brug, ook de boordcomputer uitgeschakeld wordt.

Artikel 15

In principe vindt de registratie van gegevens automatisch plaats met behulp van sensoren. Het gaat dan bijvoorbeeld om de registratie van de afgelegde afstand. Een aantal gegevens kan mogelijk niet automatisch worden verkregen. Deze gegevens worden handmatig door de bestuurder ingevoerd. Gedacht moet worden aan bijvoorbeeld het begin en einde van de rit en van de pauze. Ook wordt handmatig ingegeven of sprake is van een beladen of een onbeladen rit. Ook is het mogelijk dat deze gegevens via een externe inrichting worden ingevoerd, bijvoorbeeld via de centrale. In dat geval dient de bestuurder de informatie handmatig te accepteren.

Artikelen 17 en 18

De minister geeft de boordcomputerkaarten en een systeemkaart uit. Deze kaarten worden gebruikt om gebruikers en systemen op een sterke wijze te authenticeren. De specificaties van deze kaarten, inclusief de werking ervan, zijn afzonderlijke regelingen opgenomen. Hierdoor wordt de interoperabiliteit tussen de kaarten en de boordcomputers van, naar alle waarschijnlijkheid, verschillende fabrikanten gegarandeerd. De boordcomputerkaarten kunnen immers in verschillende typen boordcomputers worden gebruikt.

Vanaf het moment dat een boordcomputerkaart in de boordcomputer wordt geplaatst is er een kaartsessie actief tussen de kaart en de boordcomputer. Het starten van de kaartsessie wordt gebruikt om de identiteit van de kaarthouder vast te stellen, waarbij deze een persoonlijk identificatienummer, of PIN, invoert. Hiermee worden de door de boordcomputer geregistreerde gegevens aan de kaarthouder gekoppeld. Tijdens de sessie worden de arbeids-, rij- en rusttijdengegevens op het moment van optreden op de kaart opgeslagen. De boordcomputer waarborgt ook een correcte afsluiting van de kaartsessie. Tijdens deze afsluiting wordt door de chauffeurskaart een elektronische handtekening over de arbeids-, rij- en rusttijden van de kaarthouder geplaatst, zoals deze worden opgeslagen op de boordcomputer. Het afsluiten van de sessie vindt plaats door het ingeven van de PIN-code over de kaart door de kaarthouder.

De boordcomputer is in staat om zelfstandig een elektronische handtekening te plaatsen met behulp van de systeemkaart. Deze handtekening wordt gebruikt om de integriteit van de geregistreerde data te kunnen waarborgen. De systeemkaart bestaat uit een chip met daarop het noodzakelijke cryptografisch sleutelmateriaal en corresponderende certificaten om deze elektronische handtekening te zetten. De boordcomputer dient dusdanig te zijn ontworpen dat gegarandeerd is dat alleen het sleutelmateriaal van de systeemkaart kan worden gebruikt en dat het sleutelmateriaal zowel logisch als fysiek beschermd is door opslag op, en gebruik via, de systeemkaart.

Artikel 19

Door de boordcomputer te vergrendelen voor een bedrijf, is bij de boordcomputer bekend voor welke vervoerder de auto wordt ingezet. Wordt de auto gedeeld met meerdere vervoerders, dan dient voordat de taxi wordt ingezet voor een andere vervoerder, de boordcomputer hiervan in kennis te worden gesteld. Dit gebeurt door de ondernemerskaart van de betreffende vervoerder te plaatsen in de boordcomputer en de bedrijfsvergrendeling te activeren voor deze vervoerder. De boordcomputer kent slechts één actieve bedrijfsvergrendeling.

Een bedrijfsvergrendeling bestaat uit de registratie van:

het personenvervoernummer dat staat aangegeven op de vergunning;

het aan de vervoerder toegekende nummer van de Kamer van Koophandel;

het nummer van de ondernemerskaart;

de datum en het tijdstip van de inschakeling;

en, voor zover van toepassing, de datum en het tijdstip van de uitschakeling van de bedrijfsvergrendeling.

Bij voertuigen die door meerdere bedrijven worden gebruikt, worden de gegevens per bedrijf gescheiden opgeslagen in het geheugen van de boordcomputer. De bedrijfsvergrendeling waarborgt dat de toegang tot de bedrijfsgebonden gegevens alleen kan plaatsvinden door het desbetreffende bedrijf waarvoor deze ritten zijn uitgevoerd, en overige bevoegde partijen zoals werkplaatsen en toezichthouders.

Artikelen 20 en 21

In de artikelen 20 en 21 wordt aan de boordcomputer de eis gesteld de geregistreerde gegevens te kunnen lezen en tonen, voor zover de gebruiker hiertoe geautoriseerd is. Dat geldt uitdrukkelijk niet voor de positiegegevens van de auto, aangezien artikel 6 bepaalt dat deze zodanig opgeslagen worden dat zij alleen bij deactivering kunnen worden ingezien. In artikel 20, derde lid, is vastgelegd dat de positiegegevens van de auto gedurende 104 weken worden opgeslagen.

Artikelen 22, 23 en 24

In de activeringsmodus wordt de boordcomputer geconfigureerd voor gebruik. Hierbij worden statische gegevens vastgelegd zoals kenteken en kilometerstand van de auto ten tijde van de activering. Daarnaast worden in de activeringsmodus de noodzakelijk ijkingparameters vastgelegd. Daarbij moet gedacht worden aan de parameters voor de constante van de boordcomputer en het instellen van de plaatselijke tijd.

Bij een eventuele deactivering van de boordcomputer dienen alle opgeslagen gegevens van de boordcomputer eerst te worden veiliggesteld op een extern medium. Hierbij kan een werkplaats door middel van het plaatsen van een keuringskaart alle gegevens veiligstellen. Na de overbrenging van deze gegevens worden deze na handmatige bevestiging gewist.

Voor het overbrengen van de positiegegevens is een speciale deactiveringsprocedure ontwikkeld. Positiegegevens kunnen slechts overgebracht worden nadat er authenticatie heeft plaatsgevonden op basis van een keuringskaart én een inspectiekaart. Uitsluitend een combinatie van die twee kaarten (het zogenaamde ‘vier ogen principe’) geeft toegang tot de positiegegevens van de auto. Door toepassing van dit ‘vier ogen principe’ wordt voorkomen dat de positiegegevens al te gemakkelijk toegankelijk zijn en wordt de privacy van de bestuurder geborgd. Alleen indien de positiegegevens succesvol zijn overgebracht worden ze na een handmatige bevestiging gewist. Positiegegevens die niet worden overgebracht blijven in het geheugen van de boordcomputer opgeslagen.

Artikelen 25 tot en met 29

Het diagnosemechanisme van de boordcomputer is in staat fouten, storingen en situaties die de betrouwbare werking of beveiliging van de boordcomputer en opgeslagen gegevens aantasten, te herkennen. Hiertoe voert de boordcomputer zelftesten uit en verifieert de boordcomputer de gebruikte programmatuur. Daarnaast controleert de boordcomputer continu de eigen werking en stelt verschillen tussen waargenomen waarden van verschillende sensoren vast. Wanneer een gebeurtenis wordt vastgesteld, wordt dit geregistreerd.

De boordcomputer interpreteert gebeurtenissen en fouten, en constateert op basis van deze interpretatie of er sprake is van een fout of storing. Buiten de in de regeling genoemde fout- en storingsituaties is het, afhankelijk van de implementatiekeuzes door de fabrikanten, mogelijk dat er andere fouten of storingen optreden. De fabrikant is verantwoordelijk om alle fouten en storingen die de werking van de boordcomputer aantasten vast te leggen.

De gebruiker van de boordcomputer is in staat om door middel van de ingebouwde beproeving op elk moment te controleren of de boordcomputer nog op de juiste manier werkt. De ingebouwde beproeving stelt ook de toezichthouder in staat om vast te stellen of de boordcomputer correct functioneert.

In een aparte regeling wordt aangegeven welke handelingen door de gebruiker moeten worden uitgevoerd bij het constateren van een onjuiste werking van de boordcomputer.

Artikel 30

Om te waarborgen dat de boordcomputer goed functioneert in de voor elektronische apparatuur ‘onvriendelijke voertuig omgeving’ wordt een aantal minimale eisen gesteld. Deze eisen zijn zeker niet uitputtend, want het is primair aan de fabrikant om te zorgen voor een onder normale gebruiksomstandigheden naar behoren functionerende boordcomputer. Er is bijvoorbeeld niet gespecificeerd tegen welke trillingen de boordcomputer bestand moet zijn en van welk materiaal ze dient te worden geconstrueerd. Via de beveiligingseisen worden wel minimale eisen aan de robuustheid en inbraakbestendigheid gesteld.

Artikel 31

De boordcomputercomponenten die de correcte werking van de beveiligingsfuncties moeten garanderen dienen zorg te dragen dat de correcte werking niet kan worden geschonden dan wel dat bij constatering van onjuist functioneren verdere handelingen worden gestaakt. Daarnaast wordt gebruik gemaakt van elektronische handtekeningen om geregistreerde gegevens onweerlegbaar te koppelen aan de boordcomputer waarmee deze zijn vastgelegd of aan de bestuurder. In bijlage 1 zijn de eisen waaraan de beveiligingsfuncties moeten voldoen vastgelegd.

Met programmatuur van de boordcomputer wordt bedoeld de programmatuur die nodig is om de functies zoals voorgeschreven in deze regeling te kunnen uitvoeren. Het is mogelijk om naast de programmatuur van de boordcomputer additionele programmatuur op hetzelfde platform te installeren en gebruiken.

Bij het plaatsen van de elektronische handtekening wordt geen versleuteling van de informatie toegepast zodat deze informatie in de oorspronkelijke vorm blijft. De handtekening wordt als bijlage aan de ondertekende informatie toegevoegd, zodat de oorspronkelijke gegevens leesbaar zijn voor applicaties die geen elektronische handtekening technologie ondersteunen.

De boordcomputerkaarten en de systeemkaart zijn voorzien van technologie om elektronische handtekeningen te kunnen plaatsen. De in bijlage 1 voorgeschreven standaarden moeten in de boordcomputer ondersteund worden om op een juiste manier met deze kaarten te kunnen werken.

Artikel 32

De aanvraag om een typegoedkeuring wordt ingediend bij de Dienst Wegverkeer en wordt in behandeling genomen nadat het hiervoor vastgestelde tarief door de aanvrager is betaald. De aanvraag en de behandeling van de aanvraag geschieden met inachtneming van de kaderrichtlijn 2007/46/EG van het Europees Parlement en de Raad van de Europese Unie van 5 september 2007 tot vaststelling van een kader voor de goedkeuring van motorvoertuigen en aanhangwagens daarvan en van systemen, onderdelen en technische eenheden die voor dergelijke voertuigen zijn bestemd. De typegoedkeuring van boordcomputers taxi betreft een zogenaamde ‘nationale typegoedkeuring’ als gedefinieerd in artikel 3, aanhef en onder 3, van voornoemde richtlijn.

Artikel 33, eerste lid

Dit artikellid geeft aan welke bescheiden er bij de aanvraag om typegoedkeuring van een boordcomputer moeten worden overgelegd. De stukken kunnen zowel in de Nederlandse, als in de Engelse taal worden ingediend. Dit is niet alleen van belang voor fabrikanten die in het buitenland zijn gevestigd, maar ook voor de door de fabrikanten in te schakelen testhuizen.

Centraal staan hierbij het beveiligingscertificaat met de daarbij behorende documenten en de testrapporten. Op grond van deze documenten moet de Dienst Wegverkeer kunnen vaststellen dat de boordcomputer buiten twijfel voldoet aan alle beveiligingseisen en aan alle technische en functionele eisen.

Beveiligingscertificaat

Het beveiligingscertificaat moet zijn afgegeven door een testhuis dat beschikt over een accreditatie op grond van Common Criteria en ten minste EAL3 conform zijn. Deze internationale accreditatie staat borg voor een zeer hoogwaardig beoordelingstraject dat doorgaans meerdere maanden in beslag zal nemen en met veel waarborgen is omkleed. De in het kader van de common criteriacertificering relevante stukken zijn elektronisch beschikbaar via www.commoncriteriaportal.org. Ook de in bijlage 1 opgenomen beveiligingsdoelstellingen zijn in de vorm van een zogenaamd beveiligingsprofiel (protection profile) op deze site terug te vinden.

Aan de hand van het beveiligingsprofiel moet de fabrikant beveiligingsdoelstellingen (‘security target’) laten opstellen, waarmee een vertaalslag wordt gemaakt van het algemene beveiligingsprofiel naar de specifieke boordcomputer van de fabrikant. De Common Criteria testinstelling zal vervolgens beoordelen of de boordcomputer van deze fabrikant voldoet aan deze beveiligingsdoelstellingen. Bij het Common Criteria certificaat wordt een Certification Report gevoegd waarin de opmerkingen zijn opgenomen die bij het verleende certificaat behoren en die van belang zijn voor een juiste waardering van het certificaat.

Bij de beoordeling van de aanvraag door de RDW zullen de bij het certificaat behorende beveiligingsdoelstellingen en de in het Certification Report gemaakte opmerkingen een belangrijke plaats innemen. Uiteraard zal daarbij ook worden beoordeeld of de beveiligingsdoelstellingen een correcte implementatie van het beveiligingsprofiel vormen.

Testrapporten

De fabrikant is in beginsel vrij bij de keuze voor één of meerdere testinstellingen die testen of de boordcomputer voldoet aan de technische en functionele eisen. Daarbij wordt alleen de eis gesteld dat de testinstelling ten minste moet werken overeenkomstig ISO-IEC 17025 dan wel overeenkomstig kwaliteitsstandaarden die aantoonbaar een vergelijkbaar beschermingsniveau bieden.

Het is de fabrikant die met de testinstelling contracteert en daarbij bepaalt wat er getest wordt en op welke wijze. Dat brengt met zich dat het ook de fabrikant is die verantwoordelijk is voor de omvang van de tests (wat is er precies getest?) en de kwaliteit van de uitgevoerde tests en de daarover opgestelde testrapporten. Deze kwaliteit hangt van meerdere factoren af, maar kan worden samengevat met het criterium dat de Dienst Wegverkeer op grond van deze testrapporten buiten twijfel moet kunnen vaststellen dat de betreffende boordcomputer volledig aan alle technische en functionele eisen voldoet. Biedt de boordcomputer bijvoorbeeld alle noodzakelijke functionaliteiten? En is ook getest of de boordcomputer bij strenge vorst nog goed functioneert? Op grond van de testrapporten moet de Dienst Wegverkeer onder meer kunnen vaststellen welke tests er zijn uitgevoerd, op welke wijze en onder welke omstandigheden dat is gebeurd en wat de resultaten hiervan zijn.

Overeenstemming van productie.

Ook dient bij de aanvraag een beschrijving te worden overgelegd waarin wordt aangegeven welke organisatorische maatregelen worden getroffen om te borgen dat de te produceren boordcomputers zullen overeenstemmen met het goedgekeurde type. Dit is eveneens een belangrijk onderdeel van de aanvraagprocedure, het gaat er immers om dat de uiteindelijk op de markt te brengen boordcomputers voldoen aan alle gestelde eisen. Naast het beoordelen van de boordcomputer die ter typegoedkeuring wordt aangeboden, is het dan ook van groot belang dat de te produceren boordcomputers identiek zijn aan de boordcomputer die is getest en waarvoor een typegoedkeuring is verleend. Na verlening van de typegoedkeuring wordt door de Dienst Wegverkeer toezicht gehouden op het overeenstemmen van de productie met de verleende typegoedkeuring.

Artikel 33, tweede, derde en vierde lid

Bij de aanvraag wordt door de aanvrager één exemplaar van de boordcomputer ter beschikking gesteld. Indien nodig kan de Dienst Wegverkeer bij wijze van second opinion één of meerdere testen of testonderdelen herhalen of laten herhalen door een daartoe gekwalificeerde testinstelling. Het is dan ook van groot belang dat de bij de aanvraag overgelegde testrapporten zodanig zijn opgesteld dat de uitgevoerde tests controleerbaar en reproduceerbaar zijn. Indien dit nodig is kan de Dienst Wegverkeer nadere gegevens over de uitgevoerde testen opvragen.

Artikelen 34 en 35

Deze bepalingen zien op het door de Dienst Wegverkeer te houden toezicht op de typegoedkeuringen. Op de fabrikant rust een inlichtingenplicht, hij dient de Dienst Wegverkeer in kennis te stellen van voorgenomen wijzigingen ten aanzien van de boordcomputer. De inlichtingenplicht geldt ook voor de reeds uitgevoerde wijzigingen, waardoor de verplichting blijft bestaan als een doorgevoerde wijziging niet of niet volledig vooraf is gemeld.

Op de fabrikant rust ook de verplichting om een zodanige administratie te voeren dat de Dienst Wegverkeer in het kader van het te houden toezicht kan vaststellen dat en hoe de overeenstemming van productie door de fabrikant wordt geborgd. De Dienst Wegverkeer vult de wijze waarop hij toezicht zal houden nader in.

Artikel 36

Een verleende typegoedkeuring vervalt in beginsel van rechtswege zodra zwaardere eisen van kracht worden. Bij het van kracht worden van de zwaardere eisen kan hiervan worden afgeweken. Dit zal voornamelijk afhangen van de de aard en ernst van de zwaardere eisen. Zo kan dit in geval van het verzwaren van de beveiligingseisen na gebleken fraude met boordcomputers anders worden beoordeeld dan wanneer er slechts een lichte verzwaring van een functionele eis worden doorgevoerd. Het van rechtswege vervallen van een typegoedkeuring moet worden onderscheiden van de bevoegdheid van de Dienst Wegverkeer tot intrekking van een typegoedkeuring ingevolge artikel 25 van de Wegenverkeerswet 1994.

Artikel 37

Deze bepaling ziet op alle normen waarnaar in de regeling wordt verwezen, zoals NEN, NEN/EN, NEN/ISO, Common Criteria, ISO-IEC, CEN, ETSI, etcetera, etcetera.

Artikel 38

Deze bepaling betreft een zogenaamde gelijkstellingsbepaling. Verklaringen van goedkeuring die zijn afgegeven in andere lidstaten van de Europese Unie of in andere staten die partij zijn bij een (mede) daartoe strekkend verdrag dat Nederland bindt, worden onder bepaalde voorwaarden gelijkgesteld met een door de Dienst Wegverkeer verleende typegoedkeuring. Deze verklaringen van goedkeuring moeten zijn afgegeven door een goedkeuringsinstelling uit een andere lidstaat die door haar nationale overheid is aangewezen om verklaringen van goedkeuring te verlenen. Daarnaast moet deze verklaring zijn afgegeven op basis van onderzoekingen die een beschermingsniveau bieden dat ten minste gelijkwaardig is aan het niveau dat met de nationale onderzoekingen wordt nagestreefd.

Bijlage 1

In deze bijlage zijn de beveiligingsdoelstellingen en -eisen opgenomen. Uitgangspunt daarbij is dat waar mogelijk wordt aangesloten bij erkende (Europese) normen en standaarden. De beveiligingsaspecten van de boordcomputer zijn dermate belangrijk dat zonder een controleerbaar afdoende integere en onweerlegbare registratie van gegevens het doel van de boordcomputer in gevaar komt. De beveiligingseisen moeten daarom op een eenduidige wijze zijnvastgelegd, ongeacht de wijze waarop een fabrikant de beveiligingsmaatregelen daadwerkelijk realiseert. Bovendien moet door een onafhankelijke partij kunnen worden vastgesteld dat een boordcomputer voldoet aan de beveiligingseisen. Binnen Europa wordt hiervoor het Common Criteria raamwerk gehanteerd. Binnen dit raamwerk wordt een zogenaamd Protection Profile document vereist waarin op een formele manier de eisen te stellen aan het systeem worden gedocumenteerd. Dit document dient een op zich zelfstaand document te zijn waaruit de bedreigingen blijken waar tegen de boordcomputer bestand moet zijn en de omgeving waarbinnen de boordcomputer wordt ingezet. De opbouw en inhoud van het document zijn vastgelegd in de Common Criteria norm. Bijlage 1 is op 5 december 2008 gecertificeerd door het Nederlands Schema voor Certificatie op het gebied van IT-Beveiliging (NSCIB) en kan hierdoor binnen het Common Criteria raamwerk worden gebruikt.

Bijlage 2

Deze bijlage bevat een beschrijving van een viertal overbrengingsinterfaces. Het gaat om de overbrengingsinterfaces 'Ritadministratie', 'Arbeids-, rij- en rusttijden', 'Coördinaten' en Gebeurtenis'. De structuur, betekenis en integriteit van de gegevens die overgebracht worden via deze overbrengingsinterfaces naar een externe gegevensdrager zijn eenduidig beschreven. Er is zo’n gedetailleerde beschrijving opgenomen om te kunnen garanderen dat de boordcomputers van de verschillende fabrikanten de gegevens identiek aanleveren. Deze garantie is nodig opdat de gegevens geautomatiseerd verwerkt kunnen worden. Voor het eenduidig vastleggen van de structuur, betekenis en integriteit van de gegevens wordt gebruik gemaakt van de open standaarden XML, XSD en XMLDSIG. Het gebruik van open standaarden is in overeenstemming met de eis van NORA (Nederlandse Overheid Referentie Architectuur) die de rijksoverheid voor haar communicatie, zowel intern als met de buitenwereld, hanteert. Daardoor wordt de leveranciersonafhankelijkheid vergroot.

Bijlage 3

Bijlage 3 beschrijft een uniforme, open ingang, ten behoeve van de koppeling van de boordcomputer aan een willekeurige taxameter. Zo wordt mogelijk gemaakt dat taxameters op een vrij gemakkelijke en eenduidige manier aan de boordcomputer gekoppeld kunnen worden. Dit vraagt overigens wel om een op deze ingang aangepaste taxameter.

Indien deze ingang achterwege gelaten zou worden bestaat het risico dat er op de Nederlandse markt vanwege de inrichting van de boordcomputer uitsluiting plaatsvindt van bepaalde taxameters.

De Minister van Verkeer en Waterstaat,

C.M.P.S. Eurlings.

---

1 Een storing treedt op wanneer een onderbreking in de correcte werking van de boordcomputer door een gebeurtenis of fout een permanent karakter heeft.

2 Een fout treedt op wanneer de correcte werking van de boordcomputer gedurende korte tijd wordt onderbroken.

3 NB: Dit zijn zaken die in de CC worden aangenomen als zijnde waar. Ze worden niet gecontroleerd. Mochten ze in de praktijk niet waar worden gemaakt, dan is het zeer aannemelijk dat de TOE niet zijn doelen zal bereiken.

4 Er zijn geen relevante beveiligingsattributen.

5 Zie FPT_STM.1

6 Zie FDP_DAU.2

7 Vervallen.

8 Er wordt geen door de CC voorgedefinieerd niveau van gebeurtenissen gebruikt.

9 Een storing treedt op wanneer een onderbreking in de correcte werking van de boordcomputer door een gebeurtenis of fout een permanent karakter heeft.

10 Een fout treedt op wanneer de correcte werking van de boordcomputer gedurende korte tijd wordt onderbroken.

11 Vervallen. Er worden geen maximum quota geëist.

12 Dat wil zeggen dat de fysieke aanvallen detecteerbaar moeten zijn door een laboratorium (zoals het NFI), maar niet noodzakelijk detecteerbaar hoeven te zijn door bijvoorbeeld een toezichthouder.