Legalize / Nederland / Ministeriële regeling

Regeling specificaties en typegoedkeuring boordcomputer taxi

Type Ministeriële regeling

Publication 2020-12-19

State In force

Source BWB

artikelen 370

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.

Artikel 3.2. Levenscyclus 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.

Artikel 3.3. Entiteiten

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

Artikel 3.3.1. Subjecten - middelen

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:

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 mogen door erkende werkplaatsen met een programmatuurrevisie worden uitgevoerd na een succesvolle authenticatie met een keuringskaart.

Indien naar het oordeel van de Dienst Wegverkeer bij/na het implementeren van een bepaalde programmatuurrevisie geen kalibratie van de boordcomputer benodigd is, dan mag die programmatuurrevisie ook buiten een erkende werkplaats door eenieder op de boordcomputer geïmplementeerd worden indien deze zich in operationele modus met werkingsniveau basis bevindt en er geen gebruikerssessie actief is.

Teneinde de blijvend correcte werking van de boordcomputer te kunnen waarborgen, moet de boordcomputer ten aanzien van het implementeren van programmatuurrevisies de volgende acties uitvoeren:

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

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

Artikel 3.3.2. Subjecten - gebruikers

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, waaronder externe gegevensdragers en ook te beschouwen als externe gegevensdragers, t.b.v. toezichthouders voor het uitlezen en eventueel verwerken van gegevens.

S.KALIBRATIEMIDDELEN

Fysiek aan de TOE gekoppelde hulpmiddelen, waaronder externe gegevensdragers en ook te beschouwen als externe gegevensdragers, t.b.v. een erkende werkplaats voor het uitlezen van gegevens en/of het ijken, kalibreren, activeren en deactiveren van de TOE.

S.BEDRIJFSMIDDELEN

Fysiek of logisch aan de TOE gekoppelde hulpmiddelen, waaronder externe gegevensdragers en ook te beschouwen als externe gegevensdragers, t.b.v. de vervoerder voor de overdracht van gegevens van en naar de bedrijfsadministratie.

Artikel 3.3.3. Objecten

Fysiek of logisch aan de TOE gekoppelde hulpmiddelen, waaronder externe gegevensdragers en ook te beschouwen als externe gegevensdragers, voor de overdracht van programmatuurrevisies naar de TOE.

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.

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

Artikel 3.4. Begrenzingen van 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

Artikel 4. Beveiligingsprobleem

Artikel 4.1. Beveiligingsbeleid

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, bestaande uit O.VASTE_SYSTEEMGEGEVENS, O.VARIABELE_SYSTEEMGEGEVENS en O.PROGRAMMATUURGEGEVENS.

O.VASTE_SYSTEEMGEGEVENS

Vaste gegevens van de TOE, zoals de naam van diens fabrikant, het serienummer en het bouwjaar.

O.VARIABELE_SYSTEEMGEGEVENS

Wijzigbare gegevens van de TOE, waaronder het kenteken van de auto en O.INSTELLINGSGEGEVENS.

O.INSTELLINGSGEGEVENS

Die subset van O.VARIABELE_SYSTEEMGEGEVENS die aan kalibratie onderhevig is.

O.PROGRAMMATUUR

Artikel 4.2. Aannames3NB: 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.

O.PROGRAMMATUURGEGEVENS

Versie-identificerende (vaste) gegevens van O.PROGRAMMATUUR, waaronder een versienummer en een goedkeuringsnummer. De O.PROGRAMMATUURGEGEVENS van de op de TOE operationele O.PROGRAMMATUUR vormen eveneens een subset van O.SYSTEEMGEGEVENS.

O.PROGRAMMATUURREVISIE

De combinatie van een versie van O.PROGRAMMATUUR die is bedoeld om de op de TOE operationele O.PROGRAMMATUUR of delen daarvan te vervangen, een O.KALIBRATIEINDICATIE en een O.VERVANGBARE_VERSIES.

O.KALIBRATIEINDICATIE

Een vast attribuut van een O.PROGRAMMATUURREVISIE dat aanduidt of het vervangen van de op de TOE operationele O.PROGRAMMATUUR met de in de O.PROGRAMMATUURREVISIE opgenomen O.PROGRAMMATUUR wel (positief) of niet (negatief) gevolgd moet worden door kalibratie van O.INSTELLINGSGEGEVENS.

O.VERVANGBARE_VERSIES

Een in een O.PROGRAMMATUURREVISIE opgenomen criterium (zoals een lijst of wildcard) waarmee een versienummer kan worden vergeleken om te bepalen of het met dat criterium correspondeert.

Ter verduidelijking is in de onderstaande figuur de samenhang van de op de TOE aanwezige O.SYSTEEMGEGEVENS en de op de TOE operationele O.PROGRAMMATUUR en hun subobjecten / attributen grafisch weergegeven.

Eveneens ter verduidelijking is in de onderstaande figuur de opbouw van een O.PROGRAMMATUURREVISIE opgenomen.

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 een routeplanningsapplicatie.

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

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.

Artikel 4. Beveiligingsprobleem

P.VASTLEGGEN

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

P.BEWAREN_EN_BORGEN

De TOE bewaart de vastgelegde gegevens zodat:

P.ACTIES

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

P.UITVOEREN_GEGEVENS

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

De TOE kan

uitvoeren naar een extern bedrijfsmiddel (op afstand of lokaal) indien

P.INVOEREN_GEGEVENS

De TOE kan gegevens invoeren, afhankelijk van de ingebrachte boordcomputerkaart:

De TOE kan, onafhankelijk van het bestaan van een gebruikerssessie:

P.VEILIG_UPDATEN

De TOE kan zijn operationele programmatuur updaten met de programmatuur uit een (van een extern updatemiddel afkomstige) programmatuurrevisie indien de TOE heeft vastgesteld dat

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 extern kalibratiemiddel met uitzondering van positiegegevens. Positiegegevens kunnen alleen worden overgebracht naar extern handhavingsmiddel als er tijdens P.DEACTIVERING op de TOE wordt aangemeld met achtereenvolgens S.KEURINGSKAART en S.INSPECTIEKAART.

Artikel 4.2. Aannames3NB: 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.

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. Na activering kan de TOE door een erkende werkplaats middels deactivering weer in inactieve toestand worden teruggebracht. De cyclus van activering en deactivering door erkende werkplaatsen kan zich gedurende de levensduur van de TOE meerdere keren herhalen.

Voertuigfabrikanten, installateurs en/of erkende werkplaatsen zullen de integriteit van de TOE beschermen zolang de TOE zich niet in actieve toestand bevindt.

OE.DEACTIVERING

OT.AUDIT

Artikel 6. Functionele beveiligingseisen

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

Artikel 6.1. Beveiligingsrollen

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

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

Artikel 6.2. Identificatie en Authenticatie

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.INVOEREN_GEGEVENS

De TOE kan gegevens invoeren volgens de regels van P.INVOEREN_GEGEVENS.

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:

OT.VEILIG_UPDATEN

De TOE kan zijn operationele programmatuur updaten met de programmatuur uit een (van een extern updatemiddel afkomstige) programmatuurrevisie indien de TOE heeft vastgesteld dat

OE.VOOR_ACTIVERING

Voertuigfabrikanten, installateurs en/of erkende werkplaatsen zullen de integriteit van de TOE beschermen zolang de TOE zich niet in actieve toestand bevindt.

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:

Artikel 6.3. Bct-toegangsbeleid

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:

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:

OE.SYSTEEMKAART

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

OE.BOORDCOMPUTERKAART

De omgeving van de TOE dient boordcomputerkaarten te bevatten die:

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, O.PROGRAMMATUUR en O.POSITIEGEGEVENS.

OE.VEILIG_UPDATEN

De omgeving van de TOE dient programmatuurrevisies aan te leveren waarvan, voorafgaand aan het door de fabrikant aan de programmatuurrevisie aanbrengen van enig integriteits- en authenticiteitskenmerk,

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

FMT_SMR.2 Restricties op gebruikersrollen

Artikel 6.4. Handtekeningen

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

FMT_SMR.2.3 De TSF zal de volgende regels afdwingen:

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:

Artikel 6.5. Beveiligingsaudit

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:

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:

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:

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

FTA_SSL.3 Automatisch beëindigen van een sessie

FTA_SSL.3.1 De TSF beëindigt een kaartsessie:

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, S.BEDRIJFSMIDDELEN en S.UPDATEMIDDELEN op basis van hun aanwezigheid op de daarvoor bestemde interface, alvorens handelingen te verrichten namens de desbetreffende subjecten.

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 handelingen4Er zijn geen relevante beveiligingsattributen..

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

Artikel 6.6. Bescherming van de BCT

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:

FDP_ACF.1.3 -7Vervallen.

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

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 geëxporteerd.

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

Artikel 7. Garantieniveau

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, S.UPDATEMIDDELEN of S.TAXAMETER.FDP_ITC.1.2 De TSF negeert attributen wanneer gegevens worden ingelezen door de TSF.

Artikel 6.4. Handtekeningen

FDP_DAU.2 Data authenticatie met identiteit

Artikel 8.1.1. Beveiligingsbeleid

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.

FAU_GEN.1 Genereren van gebeurtenisgegevens8Er wordt geen door de CC voorgedefinieerd niveau van gebeurtenissen gebruikt.

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

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

als een storing of fout is opgetreden tevens:

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

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

FAU_SAA.1 Detectie van potentiële inbreuk op beveiliging

Artikel 8.1.2. Aannames

FAU_ARP.1 Automatische respons op gebeurtenissen

FAU_ARP.1.1 De TSF geeft een waarschuwingsignaal op het leesvenster wanneer een beveiligingsrelevante 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 -11Vervallen. Er worden geen maximum quota geëist.

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

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.

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 detecteren12Dat 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..

Artikel 8.2. Beveiligingsdoelstellingen voor de TOE

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 ONBEKEND, TOEZICHTHOUDER, WERKPLAATS en VERVOERDER de mogelijkheden bieden om de integriteit van de op de TOE operationele O.PROGRAMMATUUR, waaronder de TSF uitvoerbare programmatuurcode (executables), te verifiëren.

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.

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

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

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 en OT.AUTHENTICATIE_BOORDCOMPUTERKAART.

P.BEWAREN_EN_BORGEN

Het bewaren van de gegevens wordt ondervangen door:

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

Het onweerlegbaar koppelen aan de TOE wordt ondervangen door:

Het onweerlegbaar koppelen aan de boordcomputerkaarthouder wordt ondervangen door:

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

P.ACTIES

Artikel 8.3. Afhankelijkheden

P.UITVOEREN_GEGEVENS

Bijlage 2. Bij de regeling specificaties en typegoedkeuring boordcomputer taxi

Artikel 1. Definities

Deze wordt direct ondervangen door OT.INVOEREN_GEGEVENS, OT.AUTHENTICATIE_BOORDCOMPUTERKAART en OE.BEDIENING.

Artikel 2. Algemeen

Artikel 2.1. Doel

P.DEACTIVERING

Artikel 8.1.2. Aannames

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

Artikel 2.3. Snelheidseis gegevenslevering

Deze wordt direct ondervangen door OE.BEDIENING.

Artikel 2.4. Bestandsformaat

Deze wordt direct ondervangen door OE.SENSOREN.

Artikel 2.5. Overbrengingsprotocol

Deze wordt direct ondervangen door OE.SYSTEEMKAART.

Artikel 2.6. Totstandkoming gegevenslevering

Deze wordt direct ondervangen door OE.BOORDCOMPUTERKAART.

A.BOORDCOMPUTERKAARTHOUDER

Artikel 2.6.1. Periode gegevenslevering

A.PRINTER

Deze wordt direct ondervangen door OE.PRINTER.

A.VOOR_ACTIVERING

Deze wordt direct ondervangen door OE.VOOR_ACTIVERING.

OT.AUDIT

Artikel 2.6.2. Verwerking gegevenslevering

Deze wordt gerealiseerd door FAU_GEN.1 die specificeert welke gegevens er van welke gebeurtenissen worden vastgelegd.

Dit wordt ondersteund door:

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:

Artikel 2.7. Authenticatie en autorisatie

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

Artikel 2.8. Integriteit

OT.KOPPELEN_AAN_SYSTEEMKAART

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

Artikel 2.8.1. Integriteit exportbericht

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

OT.OPSLAAN

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

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:

OT.INVOEREN_GEGEVENS

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

Artikel 2.8.2. Integriteit geregistreerde gegevens

Deze wordt direct gerealiseerd door FPT_PHP.1.

OT.BEWAKING_INTEGRITEIT

Deze wordt direct gerealiseerd door FPT_TST.1.

OT.VEILIG_UPDATEN

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

De volgende afhankelijkheden zijn niet vervuld:

Gegevensoverbrengingsinterface Boordcomputer Taxi

Versie 2.2

Artikel 2.9. Foutafhandeling

Datum 8 december 2014

Inhoud

Bij onderstaande foutsituaties moet de boordcomputer de bijbehorende foutmelding tonen:

Artikel 1. Definities

Artikel 2. Algemeen

Aan dit document wordt gerefereerd als ‘Gegevensoverbrengingsinterface Boordcomputer Taxi Versie 2.2’. Deze versie dateert van 8 december 2014’.

Artikel 2.1. Doel

Artikel 2.2. Hardware koppeling

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

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:

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:

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.

Artikel 3.6. Integriteit gegevens

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 is, 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 ‘Coördinaten’, ‘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:

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

Artikel 2.6.2. Verwerking gegevenslevering

Artikel 3.7.1. Naamgeving

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’.

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’.

De boordcomputer kent zes gegevensleveringen, te weten ‘Ritadministratie’, ‘Arbeids-, rij- en rusttijden’, ‘Coördinaten’, ‘Gebeurtenis’, ‘Onderzoek’ en ‘Chauffeurskaartdata’. Deze gegevensleveringen worden elk in een exportbericht vanuit de boordcomputer overgebracht. Dit exportbericht is een XML bericht dat bestaat uit een gegevenslevering-element zoals gespecificeerd in één van de artikelen 3 t/m 8, gevolgd door een element met een elektronische handtekening berekend over het gegevenslevering-element en de identificatie van de sleutel gebruikt voor het berekenen van de elektronische handtekening.

Artikel 4.2. Functionele berichtstructuur

Voor het genereren en de opmaak van de elektronische handtekening wordt gebruik gemaakt van de W3C Recommendation ‘XML Signature Syntax and Processing Version 1.1’ (XMLDSIG11) van 11 april 2013. De XMLDSIG11 specificatie (http://www.w3.org/TR/xmldsig-core1/) is een door het World Wide Web Consortium (W3C) ontworpen standaard voor de XML syntax en het genereren van elektronische handtekeningen.

Het XML exportbericht bestaat uit een -element met daarin een van de gegevenslevering-elementen , , , , of , gevolgd door een -element. Het gegevenslevering-element bevat een resultaatbericht van een gegevenslevering zoals gespecificeerd in één van de artikelen 3 t/m 8. Het -element is opgebouwd conform de XMLDSIG11 specificatie en bevat achtereenvolgens de elementen

Artikel. 4.3 Technische berichtstructuur

Het element in eender welke van de zes bovenstaande XML exportberichten heeft altijd de volgende, aan de XMLDSIG11 conformerende, opbouw:

Toelichting:

Artikel 2.8.2. Integriteit geregistreerde gegevens

Bepaalde gegevenssets, 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 elke soort gegevenslevering in artikel 3 t/m 8 wordt aangegeven welke gegevensset dit betreft, op welke momenten deze gegevensset met een elektronische handtekening worden ondertekend en als zodanig moeten worden vastgelegd en met welke private sleutel die ondertekening moet gebeuren.

Artikel. 4.5 Volgorde gegevens

Voor een gegevensset die bij vastleggen elektronisch ondertekend wordt, wordt een tekenbericht gegenereerd. Dit tekenbericht is, op enkele uitzonderingen na, gelijk aan het (corresponderende) XML exportbericht:

Artikel. 4.6 Integriteit gegevens

Ook het element van het tekenbericht wijkt op slechts enkele onderdelen af van die van het XML exportbericht:

Na generatie van het tekenbericht wordt de waarde van het element als element opgeslagen bij de gegevens waarover de elektronische handtekening is berekend. Het tekenbericht zelf hoeft niet te worden opgeslagen, zolang de getekende gegevens in de vorm waarin zij werden getekend kunnen worden gereproduceerd. Dat betekent dat de boordcomputer, behalve de gegevens die het element vormen, het certificaat dat voor ondertekening werd gebruikt, moet vastleggen.

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

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

Artikel 2.8.3. Processchema’s

Artikel 4.7.1. Naamgeving

Van de output van de groen gekleurde deelprocessen kan het tekenbericht (zonder ) worden samengesteld. De 256-bytes RSA handtekening zou daarna gebruikt kunnen worden voor het completeren van het tekenbericht, maar moet in ieder geval worden gearchiveerd in de boordcomputer.

Figuur 3 geeft een mogelijk proces voor samenstellen van de elementen van een exportbericht weer. Het exportbericht kan worden geassembleerd met de output van de groen gekleurde deelprocessen.

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:

Artikel 2.9.2. Technische fouten

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

Opmerkingen:

Artikel 3. Ritadministratie

Voor het bericht ‘Ritadministratie’ worden de volgende gegevens en functionele en technische berichtstructuur onderkend:

Voor de legenda van het bovenstaande overzicht wordt verwezen naar artikel 10.

Artikel 3.2. Ritadministratie.xsd

De onderstaande Ritadministratie.xsd wordt gebruikt.

Artikel 3.3. 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.4. Integriteit gegevens

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

Artikel 5.6. Integriteit gegevens

De ritadministratie bevat een element en bevat de elementen en . Het element bevat de volgende ritgegevens:

Artikel 5.7. Overige kenmerken

Artikel 3.5. Overige kenmerken

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

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

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

Artikel 3.5.2. Berichtgrootte

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

Artikel 4. Arbeids-, rij- en rusttijden

Artikel 4.1. Gegevens en functionele en technische berichtstructuur

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

Voor de legenda van het bovenstaande overzicht wordt verwezen naar artikel 10.

Toelichting:

Artikel 4.2. Arbeidstijden.xsd

De onderstaande Arbeidstijden.xsd wordt gebruikt.

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 elk in oplopende volgorde van volgnummer worden opgenomen.

Artikel 4.4. 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 en bevat de elementen en . Het element bevat de volgende arbeidstijd gegevens:

Artikel 6.4. Gebeurtenis.xsd

Bij het samenstellen van bericht ‘Arbeids-, rij- en rusttijden’ moeten de gegevens van het element onveranderd worden overgenomen uit de boordcomputer. Het berekenen van de ‘Elektronische handtekening chauffeur’ of ‘Elektronische handtekening boordcomputer’ van het 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 element.

Artikel 4.5. Overige kenmerken

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

Artikel 6.6. Integriteit gegevens

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

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

Bij het samenstellen van de het bericht ‘gebeurtenis’ moeten de gegevens van het 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 element.

Artikel 5.1. Gegevens en functionele en technische berichtstructuur

Voor het bericht ‘Coördinaten’ worden de volgende gegevens en functionele en technische berichtstructuur onderkend:

Artikel 6.8. Overige kenmerken

Artikel 5.2. Coordinaten.xsd

De onderstaande Coordinaten.xsd wordt gebruikt.

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.4. Integriteit gegevens

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

Artikel 5.5. Overige kenmerken

De naamgeving van de gegevenslevering ‘Coördinaten’ is als volgt:

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

Artikel 5.5.2. Berichtgrootte

Artikel 6. Gebeurtenis

Als gegevensformaat wordt gebruik gemaakt van XML.

Voor het bericht ‘Gebeurtenis’ worden de volgende gegevens en functionele en technische berichtstructuur onderkend:

Artikel 7.4. Onderzoek.xsd

Voor de legenda van het bovenstaande overzicht wordt verwezen naar artikel 10.

Artikel 6.2. Gebeurtenis.xsd

De onderstaande Gebeurtenis.xsd wordt gebruikt.

Artikel 6.3. Volgorde gegevens

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

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

Artikel 7.7. Overige kenmerken

Artikel 7.7.1. Naamgeving

Bij het samenstellen van het bericht ‘Gebeurtenis’ moeten de gegevens van het 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 element.

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

Artikel 6.6. Overige kenmerken

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

Artikel 6.6.1. Naamgeving

Artikel 8.1. Gegevens

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

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

Artikel 7. Onderzoek

Voor het bericht ‘Onderzoek’ worden de volgende gegevens en functionele en technische berichtstructuur onderkend:

Artikel 8.3. Technische berichtstructuur

Toelichting:

De onderstaande Onderzoek.xsd dient te worden gebruikt.

Artikel 7.3. 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.4. Integriteit gegevens

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

Artikel 8.6. Integriteit gegevens

Het bericht ‘Onderzoek’ bevat het element en nul of meer elementen. Elke instantie van een van beide elementen bevat de elementen en . Het element bevat elk van deze gevallen dezelfde gegevens:

Het element bevat de elektronische handtekening van het bijbehorende element.

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

Bij het samenstellen van bericht ‘Chauffeurskaartdata’ moeten de gegevens van het 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 element.

Artikel 7.5.1. Naamgeving

Artikel 8.7.1. Naamgeving

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

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

Artikel 8. Chauffeurskaartdata

Voor het bericht ‘Chauffeurskaartdata’ worden de volgende gegevens en functionele en technische berichtstructuur onderkend:

Bijlage 3. bij de Regeling specificaties en typegoedkeuring boordcomputer taxi

Artikel 1. Definities

Toelichting:

Artikel 8.2. Chauffeurskaartdata.xsd

Artikel 8.3. Volgorde gegevens

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

Artikel 8.4. Integriteit gegevens

Artikel 2.3. Fysieke interface (FI)

Artikel 2.4. Logische interface (LI)

Artikel 2.4.1. Algemene eisen

Artikel 8.5. Overige kenmerken

Artikel 8.5.1. Naamgeving

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

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

Het bericht ‘Chauffeurskaartdata’ is maximaal 200 Kbyte groot.

Artikel 9. Toelichting specificaties gegevensleveringen en algemene XSD

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.

De toelichting bij elk van de functioneel/technische specificaties van een gegevenslevering uit artikelen 3 t/m 8 bestaat uit de navolgende legenda:

Artikel 9.2. Algemene XML schema definities in bcttypes.xsd

De berichtstructuren uit artikelen 3 t/m 8 maken allen gebruik van een algemene XSD: bcttypes.xsd. Dit is een XML schema definitie zonder default namespace en zonder targetNamespace. Daardoor neemt het de default namespace en targetNamespace van elke XML schema definitie die bcttypes.xsd ’include’ aan. Dit effect heet: ‘chameleon include’.

Artikel 2.4.3.4. Bericht A_TARIEFINFO

De inhoud van bcttypes.xsd is als volgt:

Ook BTW kan gezien worden als een tarief.

In deze bijlage wordt verstaan onder:

Artikel 2. Eisen en Ontwerp

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

Artikel 2.4.3.6. Bericht A_RITBEDRAG

Hierin zijn twee niveaus te onderscheiden:

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

Een korting wordt als negatief TOESLAG_BEDR weergegeven.

Artikel 2.4. Logische interface (LI)

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

Artikel 2.4.2. Eisen met betrekking tot gegevensrepresentatie

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

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.

Artikel 2.4.3.9. Bericht VR_TAXAMETER_INFO

Totale berichtgrootte: 8 bytes

Artikel 2.4.3.2. Bericht A_STATUS

Artikel 2.4.3.3. Bericht VR_TARIEFINFO

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

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.

Artikel 2.4.3.13. Bericht F_LENGTE_INCORRECT

Ook BTW kan gezien worden als een tarief.

Artikel 2.4.3.14. Bericht F_GEEN_STX

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

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.

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

Artikel 2.4.3.7. Bericht VR_TOTALEN

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

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.

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

Artikel 31a

De fabrikant voorziet erin dat de pin-code van de boordcomputerkaart gedeblokkeerd en gewijzigd kan worden op de wijze zoals gespecificeerd in de paragrafen 8.1, 8.3 en 8.4 van bijlage 4.

§ 3. Typegoedkeuring boordcomputer

§ 4. Overgangs- en slotbepalingen

Bijlage 1. bij de Regeling boordcomputer taxi

Beveiligingsprofiel Boordcomputer Taxi (PP-BCT)

Versie 1.8

Datum 6 februari 205

Inhoud

Artikel 2. Afkortingen, acroniemen, definities en referenties

Dit document is het ‘Beveiligingsprofiel Boordcomputer Taxi’ (PP-BCT) Versie 1.8, 6 februari 2015.

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:

Artikel 2.4. Afkortingen en acroniemen

Artikel 3. Overzicht van de TOE

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 Infrastructuur en Milieu. Systeemkaarten zijn geen onderdeel van de TOE.

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

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.

Artikel 3.2. Levenscyclus van de TOE

Artikel 3.3. Entiteiten

Artikel 3.3.1. Subjecten – middelen

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

S.UPDATEMIDDELEN

Artikel 3.3.2. Subjecten – gebruikers

Artikel 3.3.3. Objecten

Gegevens over de vervoerder, waaronder autorisaties voor het gedurende een bepaalde periode onafhankelijk van een kaartsessie uitlezen van de TOE, zoals zijn vastgelegd op de TOE.

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

O.GEBEURTENISGEGEVENS

De combinatie van TOE uitvoerbare code en gegevens zoals de CA certificaathiërarchie(ën) nodig voor het verifiëren van de geldigheid en authenticiteit van certificaten van boordcomputer- en systeemkaarten, alsmede de bij dat geheel behorende O.PROGRAMMATUURGEGEVENS.

Artikel 3.4. Begrenzingen van de TOE

Artikel 4.2. Aannames3NB: 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.

A.BEDIENING

Artikel 5. Beveiligingsdoelstellingen

OT.AUDIT

OT.AUTHENTICATIE_BOORDCOMPUTERKAART

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

Artikel 5.2. Beveiligingsdoelen voor de omgeving

OE.PRINTER

Artikel 6. Functionele beveiligingseisen

Artikel 6.1. Beveiligingsrollen

FMT_SMR.2.1 De TSF kent de volgende gebruikersrollen:

Artikel 6.2. Identificatie en Authenticatie

FIA_AFL.1 Falen van authenticatie (FIA_AFL)

Artikel 6.3. BCT-toegangsbeleid

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

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

FDP_DAU.2 Data authenticatie met identiteit

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

Artikel 6.5. Beveiligingsaudit

FAU_SAA.1.1 De TSF beschouwt de in FAU_GEN.1.1 met een – gemarkeerde gebeurtenissen als beveiligingsrelevant.

Artikel 6.6. Bescherming van de BCT

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.

Artikel 7. Garantieniveau

Artikel 8. Rationale

Artikel 8.1.1. Beveiligingsbeleid

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

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

P.INVOEREN_GEGEVENS

P.VEILIG_UPDATEN

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

A.BEDIENING

A.SENSOREN

A.SYSTEEMKAART

A.BOORDCOMPUTERKAART

Deze wordt direct ondervangen door OE.BOORDCOMPUTERKAARTHOUDER.

Artikel 8.2. Beveiligingsdoelstellingen voor de TOE

OT.AUDIT

OT.VASTLEGGEN

Dit wordt ondersteund door:

OT.KOPPELEN_AAN_BOORDCOMPUTERKAART

OT.FYSIEKE_BEVEILIGING

Artikel 8.3. Afhankelijkheden

Bijlage 2. bij de Regeling specificaties en typegoedkeuring boordcomputer taxi

Versie 2.2

Inhoud

In deze bijlage wordt verstaan onder:

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.4. Bestandsformaat

Artikel 2.6. Totstandkoming gegevenslevering

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

Artikel 2.6.2. Verwerking gegevenslevering

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

Artikel 2.8.1. Integriteit exportbericht

Het XML exportbericht kent, afhankelijk van de omsloten gegevenslevering, een van de volgende structuren:

Voor de namespace en de structuur van het betreffende element wordt verwezen naar de artikelen 3.4, 4.4, 6.4, 7.4, respectievelijk 8.4.

Artikel 2.8.3. Processchema’s

Een mogelijk proces voor samenstellen van de elementen voor een tekenbericht en het genereren van de elektronische handtekening over die elementen is weergegeven in figuur 2.

Artikel 2.9. Foutafhandeling

Artikel 2.10. Overige kenmerken

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

Het element bevat de elektronische handtekening van het bijbehorende Data element.

Artikel 3.5. Overige kenmerken

Artikel 3.5.2. Berichtgrootte

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

Artikel 4. Arbeids-, rij- en rusttijden

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

Artikel 4.2. Arbeidstijden.xsd

De onderstaande Arbeidstijden.xsd wordt gebruikt.

Artikel 4.3. Volgorde gegevens

Artikel 4.4. Integriteit gegevens

Het element bevat de elektronische handtekening chauffeur of elektronische handtekening boordcomputer van het bijbehorende element.

Artikel 4.5. Overige kenmerken

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

Artikel 4.5.2. Berichtgrootte

Artikel 5. Coördinaten

Voor het bericht ‘Coördinaten’ worden de volgende gegevens en functionele en technische berichtstructuur onderkend:

Voor de legenda van het bovenstaande overzicht wordt verwezen naar artikel 10.

Artikel 5.3. Volgorde gegevens

Artikel 5.5.2. Berichtgrootte

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

Artikel 6. Gebeurtenis

Voor het bericht ‘Gebeurtenis’ worden de volgende gegevens en functionele en technische berichtstructuur onderkend:

Artikel 6.4. Integriteit gegevens

Het bericht Gebeurtenis bevat een element en het element bevat de elementen en . Het element bevat de volgende gegevens:

Het element bevat de elektronische handtekening boordcomputer van het bijbehorende element.

Artikel 6.5. Codetabel

Artikel 6.6. Overige kenmerken

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

Artikel 6.6.2. Berichtgrootte

Artikel 7. Onderzoek

Voor de legenda van het bovenstaande overzicht wordt verwezen naar artikel 10.

Artikel 7.2. Onderzoek.xsd

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

Artikel 7.5. Overige kenmerken

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

Artikel 7.5.2. Berichtgrootte

Artikel 8. Chauffeurskaartdata

Voor het bericht ‘Chauffeurskaartdata’ worden de volgende gegevens en functionele en technische berichtstructuur onderkend:

Voor de legenda van het bovenstaande overzicht wordt verwezen naar artikel 10.

Artikel 8.2. Chauffeurskaartdata.xsd

De onderstaande Chauffeurskaartdata.xsd wordt gebruikt.

Artikel 8.4. Integriteit gegevens

Chauffeurskaartdata wordt ondertekend met een elektronische handtekening. Voor het plaatsen van de elektronische handtekening wordt gebruik gemaakt van de private sleutel behorende bij het handtekeningcertificaat van de chauffeurskaart.

Het bericht ‘Chauffeurskaartdata’ bevat een element en bevat de elementen en . Het element bevat de base64 representaties van de binaire inhoud van de chip-bestanden ‘EF.Driver_Activity_Data’ en ‘EF.BCT_Certificates’, zoals overgenomen uit de chauffeurskaart, in de volgende respectievelijke elementen:

Het element bevat de elektronische handtekening chauffeur van het bijbehorende element.

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

Artikel 8.5.2. Berichtgrootte

Artikel 9. Toelichting specificaties gegevensleveringen en algemene XSD

Bijlage 3. bij de Regeling specificaties en typegoedkeuring boordcomputer taxi

Artikel 1. Definities

Artikel 2. Eisen en Ontwerp

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

Artikel 2.2. Algemene interface eisen

Artikel 2.3. Fysieke interface (FI)

Artikel 2.4.1. Algemene eisen

Artikel 2.4.3. Eisen aan de berichtstructuur

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

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

Artikel 2.4.3.6. Bericht A_RITBEDRAG

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

De raadpleging van dit document komt niet in de plaats van het lezen van het oorspronkelijke Staatsblad of de Staatscourant. Wij aanvaarden geen aansprakelijkheid voor eventuele onnauwkeurigheden die voortvloeien uit de omzetting van het origineel naar dit formaat.

Deze tekst wordt gepubliceerd onder de eigen hergebruiksvoorwaarden van BWB, niet onder een licentie van Legalize of van het publieke domein. BWB
CC0 1.0 Universeel (publiek domein)