Izvedbena uredba Komisije (EU) 2016/799 z dne 18. marca 2016 o izvajanju Uredbe (EU) št. 165/2014 Evropskega parlamenta in Sveta za določitev zahtev glede konstrukcije, preskušanja, namestitve, delovanja in popravila tahografov in njihovih sestavnih delov (Besedilo velja za EGP)
4. 4   Gegevensstructuren DSC_37 De semantische structuur van de via de 5,8 GHz DSRC-interface uitgewisselde gegevens stemt overeen met de in dit aanhangsel vervatte beschrijving. In dit punt wordt uiteengezet hoe deze gegevens worden gestructureerd. DSC_38 De payloadgegevens (RTM-gegevens) bestaan uit de samenvoeging van: 1. EncryptedTachographPayload data, zijnde de codering van de in punt 5. 4. 5 van ASN. 1 gedefinieerde TachographPayload. De coderingsmethode wordt nader toegelicht in aanhangsel 11. 2. DSRCSecurityData, zoals gespecificeerd in aanhangsel 11. DSC_39 De RTM-gegevens worden aangeroepen met RTM-attribuut=1 en overgebracht in RtmContainer=10. DSC_40 Rtm-ContextMark identificeert het deel van de ondersteunde norm uit de TARV-normenreeks (voor RTM is dit deel 9). De ASN. 1-module voor de DSRC-interfacegegevens in de RTM-toepassing wordt als volgt gedefinieerd: Tekst van het beeld TarvRtm {iso(1) standard(0) 15638 part9(9) version1(1)} DEFINITIONS AUTOMATIC TAGS ::= BEGIN IMPORTS -- Imports data attributes and elements from EFC which are used for RTM LPN FROM EfcDsrcApplication {iso(1) standard(0) 14906 application(0) version5(5)} -- Imports function parameters from the EFC Application Interface Definition SetMMIRq FROM EfcDsrcApplication {iso(1) standard(0) 14906 application(0) version5(5)} -- Imports the L7 DSRCData module data from the EFC Application Interface Definition Action-Request, Action-Response, ActionType, ApplicationList, AttributeIdList, AttributeList, Attributes, BeaconID, BST, Dsrc-EID, DSRCApplicationEntityID, Event-Report-Request, Event-Report- Response, EventType, Get-Request, Get-Response, Initialisation-Request, Initialisation-Response, ObeConfiguration, Profile, ReturnStatus, Time, T-APDUs, VST FROM EfcDsrcGeneric {iso(1) standard(0) 14906 generic(1) version5(5)}; -- Definitions of the RTM functions: RTM-InitialiseComm-Request ::= BST RTM-InitialiseComm-Response::= VST RTM-DataRetrieval-Request::= Get-Request (WITH COMPONENTS {fill (SIZE(1)), eid, accessCredentials ABSENT,iid ABSENT, attrIdList}) RTM-DataRetrieval-Response::= Get-Response {RtmContainer} (WITH COMPONENTS {. , eid, iid ABSENT}) RTM-TerminateComm::= Event-Report-Request {RtmContainer}(WITH COMPONENTS {mode (FALSE), eid (0), eventType (0)}) RTM-TestComm-Request::= Action-Request {RtmContainer} (WITH COMPONENTS {. , eid (0), actionType (15), accessCredentials ABSENT, iid ABSENT}) RTM-TestComm-Response::= Action-Response {RtmContainer} (WITH COMPONENTS {. , fill (SIZE(1)), eid (0), iid ABSENT}) -- Definitions of the RTM attributes: RtmData ::= SEQUENCE { encryptedTachographPayload OCTET STRING (SIZE(67)) (CONSTRAINED BY { -- calculated encrypting TachographPayload as per Appendix 11 --}), DSRCSecurityData OCTET STRING } TachographPayload ::= SEQUENCE { tp15638VehicleRegistrationPlate LPN -- Vehicle Registration Plate as per EN 15509.  tp15638SpeedingEvent BOOLEAN, -- 1= Irregularities in speed (see Annex 1C) tp15638DrivingWithoutValidCard BOOLEAN, -- 1= Invalid card usage (see Annex 1C) tp15638DriverCard BOOLEAN,-- 0= Indicates a valid driver card (see Annex 1C) tp15638CardInsertion BOOLEAN, -- 1= Card insertion while driving (see Annex 1C) tp15638MotionDataError BOOLEAN, -- 1= Motion data error (see Annex 1C) tp15638VehicleMotionConflict BOOLEAN, -- 1= Motion conflict (see Annex 1C) tp156382ndDriverCard BOOLEAN, -- 1= Second driver card inserted (see Annex 1C) tp15638CurrentActivityDriving BOOLEAN, -- 1= other activity selected; -- 0= driving selected tp15638LastSessionClosed BOOLEAN, -- 1= improperly, 0= properly, closed tp15638PowerSupplyInterruption INTEGER (0. 127), -- Supply interrupts in the last 10 days tp15638SensorFault INTEGER (0. 255),-- eventFaultType as per data dictionary -- All subsequent time related types as defined in Annex 1C. tp15638TimeAdjustment INTEGER(0. 4294967295), -- Time of the last time adjustment tp15638LatestBreachAttempt INTEGER(0. 4294967295), -- Time of last breach attempt tp15638LastCalibrationData INTEGER(0. 4294967295), -- Time of last calibration data tp15638PrevCalibrationData INTEGER(0. 4294967295), -- Time of previous calibration data tp15638DateTachoConnected INTEGER(0. 4294967295), -- Date tachograph connected tp15638CurrentSpeed INTEGER (0. 255), -- Last current recorded speed tp15638Timestamp INTEGER(0. 4294967295) -- Timestamp of current record2 } Rtm-ContextMark ::= SEQUENCE { standardIdentifier StandardIdentifier, -- identifier of the TARV part and its version RtmCommProfile INTEGER { C1 (1), C2 (2) } (0. 255) DEFAULT 1 } RtmTransferAck ::= INTEGER { Ok (1), NoK (2) } SIZE (1. 255) Tekst van het beeld StandardIdentifier ::= OBJECT IDENTIFIER RtmContainer ::= CHOICE { integer [0] INTEGER, bitstring [1] BIT STRING, octetstring [2] OCTET STRING (SIZE (0. 127,. )), universalString [3] UniversalString, beaconId [4] BeaconID, t-apdu [5] T-APDUs, dsrcApplicationEntityId [6] DSRCApplicationEntityID, dsrc-Ase-Id [7] Dsrc-EID, attrIdList [8] AttributeIdList, attrList [9] AttributeList{RtmContainer}, rtmData [10] RtmData, rtmContextmark [11] Rtm-ContextMark, reserved12 [12] NULL, reserved13 [13] NULL, reserved14 [14] NULL, time [15] Time, -- values from 16 to 255 reserved for ISO/CEN usage }} END 5. 4. 5   Elementen van RtmData, uitgevoerde acties en definities DSC_41 De VU berekent de gegevenswaarden waarmee de beveiligde gegevens in de DSRC-VU worden geactualiseerd, overeenkomstig de regels in tabel 14. 3. Tabel 14. 3 Elementen van RtmData, uitgevoerde acties en definities (1) RTM Data Element (2) Action performed by the VU   (3) ASN.  1 definition of data RTM1 Vehicle Registration Plate The VU shall set the value of the tp15638VehicleRegistrationPlate data element RTM1 from the recorded value of the data type VehicleRegistrationIdentification as defined in Appendix 1 VehicleRegistrationIdentification Vehicle Registration Plate expressed as a string of characters RTM2 Speeding Event The VU shall generate a Boolean value for data element RTM2 tp15638SpeedingEvent. The tp15638SpeedingEvent value shall be calculated by the VU from the number of Over Speeding Events recorded in the VU in the last 10 days of occurrence, as defined in Annex 1C. If there is at least one tp15638SpeedingEvent in the last 10 days of occurrence, the tp15638SpeedingEvent value shall be set to TRUE. ELSE if there are no events in the last 10 days of occurrence, the tp15638SpeedingEvent shall be set to FALSE. 1 (TRUE) — Indicates irregularities in speed within last 10 days of occurrence RTM3 Driving Without Valid Card The VU shall generate a boolean value for data element RTM3 tp15638DrivingWithoutValidCard. The VU shall assign a value of True to the tp15638DrivingWithoutValidCard variable if the VU data has recorded at least one event in the last 10 days of occurrence of type “Driving without an appropriate card” event as defined in Annex 1C. ELSE if there are no events in the last 10 days of occurrence, the tp15638DrivingWithoutValidCard variable shall be set to FALSE. 1 (TRUE) = Indicates invalid card usage RTM4 Valid Driver Card The VU shall generate a boolean value for data element RTM4 tp15638DriverCard on the basis of the data stored in the VU and defined in Appendix 1. If no valid driver card is present the VU shall set the variable to TRUE ELSE if a valid driver card is present the VU shall set the variable to FALSE 0 (FALSE) = Indicates a valid driver card RTM5 Card Insertion while Driving The VU shall generate a boolean value for data element RTM5. The VU shall assign a value of TRUE to the tp15638CardInsertion variable if the VU data has recorded in the last 10 days of occurrence at least one event of type “Card insertion while driving. ” as defined in Annex 1C. ELSE if there are no such events in the last 10 days of occurrence, the tp15638CardInsertion variable shall be set to FALSE.  1 (TRUE) = Indicates card insertion while driving within last 10 days of occurrence RTM6 Motion Data Error The VU shall generate a Boolean value for data element RTM6. The VU shall assign a value of TRUE to the tp15638MotionDataError variable if the VU data has in the last 10 days of occurrence recorded at least one event of type “Motion data error” as defined in Annex 1C. ELSE if there are no such events in the last 10 days of occurrence, the tp15638MotionDataError variable shall be set to FALSE. 1 (TRUE) = Indicates motion data error within last 10 days of occurrence RTM7 Vehicle Motion Conflict The VU shall generate a Boolean value for data element RTM7. The VU shall assign a value of TRUE to the tp15638vehicleMotionConflict variable if the VU data has in the last 10 days recorded at least one event of type Vehicle Motion Conflict (value ‘0A’H ). ELSE if there are no events in the last 10 days of occurrence, the tp15638vehicleMotionConflict variable shall be set to FALSE. 1 (TRUE) = Indicates motion conflict within last 10 days of occurrence RTM8 2nd Driver Card The VU shall generate a Boolean value for data element RTM8 on the basis of Annex 1C (“Driver Activity Data” CREW and CO-DRIVER). If a 2nd valid driver card is present the VU shall set the variable to TRUE ELSE if a 2nd valid driver card is not present the VU shall set the variable to FALSE 1 (TRUE) = Indicates a second driver card inserted RTM9 Current Activity The VU shall generate a booleanvalue for data element RTM9. If the current activity is recorded in the VU as any activity other than “DRIVING” as defined in Annex 1C the VU shall set the variable to TRUE ELSE if the current activity is recorded in the VU as “DRIVING” the VU shall set the variable to FALSE 1 (TRUE) = other activity selected; 0 (FALSE) = driving selected RTM10 Last Session Closed The VU shall generate a boolean value for data element RTM10. If the last card session was not properly closed as defined in Annex 1C the VU shall set the variable to TRUE.  ELSE if the last card session was properly closed the VU shall set the variable to FALSE 1 (TRUE) = improperly closed 0 (FALSE) = properly closed RTM11 Power Supply Interruption The VU shall generate an integer value for data element RTM11. The VU shall assign a value for the tp15638PowerSupplyInterruption variable equal to the longest power supply interruption according to Article 9, Reg (EU) 165/2014 of type “Power supply interruption” as defined in Annex 1C. ELSE if in the last 10 days of occurrence there are have been no Power supply interruption events the value of the integer shall be set to 0. — Number of power supply interruptions in last 10 days of occurrence RTM12 Sensor Fault The VU shall generate an integer value for data element RTM12. The VU shall assign to the variable sensorFault a value of: — 1 if an event of type ‘35’H Sensor fault has been recorded in the last 10 days, — 2 if an event of type GNSS receiver fault (either internal or external with enum values ‘51’H or ‘52’H) has been recorded in the last 10 days. — 3 if an event of type ‘53’H External GNSS communication fault has been recorded in the last 10 days of occurrence. — 4 If both Sensor Fault and GNSS receiver faults have been recorded in the last 10 days of occurrence — 5 If both Sensor Fault and External GNSS communication faults have been recorded in the last 10 days of occurrence — 6 If both GNSS receiver fault and External GNSS communication fault have been recorded in the last 10 days of occurrence — 7 If all three sensor faults, have been recorded in the last 10 days of occurrence ELSE it shall assign a value of 0 if no events have been recorded in the last 10 days of occurrence — sensor fault one octet as per data dictionary RTM13 Time Adjustment The VU shall generate an integer value (timeReal from Appendix 1) for data element RTM13 on the basis of the presence of Time Adjustment data as defined in Annex 1C. The VU shall assign the value of time at which the last time adjustment data event has occurred. ELSE if no “Time Adjustment” event.  as defined in Annex 1C is present in the VU data it shall set a value of 0 Time of the last time adjustment RTM14 Security Breach Attempt The VU shall generate an integer value (timeReal from Appendix 1) for data element RTM14 on the basis of the presence of a Security breach attempt event as defined in Annex 1C. The VU shall set the value of the time of the latest security breach attempt event recorded by the VU. ELSE if no “security breach attempt” event as defined in Annex 1C is present in the VU data it shall set a value of 0x00FF. Time of last breach attempt — Default value =0x00FF RTM15 Last Calibration The VU shall generate an integer value (timeReal from Appendix 1) for data element RTM15 on the basis of the presence of Last Calibration data as defined in Annex 1C. The VU shall set the value of time of the latest two calibrations (RTM15 and RTM16), which are set in VuCalibrationData defined in Appendix 1. The VU shall set the value for RTM15 to the timeReal of the latest calibration record. Time of last calibration data RTM16 Previous Calibration The VU shall generate an integer value (timeReal from Appendix 1) for data element RTM16 of the calibration record preceding that of the last calibration ELSE if there has been no previous calibration the VU shall set the value of RTM16 to 0. Time of previous calibration data RTM17 Date Tachograph Connected For data element RTM17 the VU shall generate an integer value (timeReal from Appendix 1). The VU shall set the value of the time of the initial installation of the VU. The VU shall extract this data from the VuCalibrationData (Appendix 1) from the vuCalibrationRecords with CalibrationPurpose equal to: ‘03’H Date tachograph connected RTM18 Current Speed The VU shall generate an integer value for data element RTM18. The VU shall set the value for RTM16 to the last current recorded speed at the time of the latest update of the RtmData. Last current recorded speed RTM19 Timestamp For data element RTM19 the VU shall generate an integer value (timeReal from Appendix 1). The VU shall set the value for RTM19 to the time of the latest update of the RtmData. Timestamp of current TachographPayload record 5. 4.  6   Mechanisme voor gegevensoverdracht DSC_42 Eerder gedefinieerde payloadgegevens worden na de initialisatiefase opgevraagd door de REDCR en vervolgens door de DSRC-VU verzonden binnen het toegewezen tijdvenster. De REDCR gebruikt het Get-commando om de gegevens op te halen. DSC_43 Voor elke uitwisseling via DSRC-interfaces worden de gegevens gecodeerd op basis van PER (Packed Encoding Rules). 5. 4. 7   Gedetailleerde beschrijving van transacties via DSRC-interfaces DSC_44 De initialisatie wordt uitgevoerd overeenkomstig de voorschriften DSC_44 tot en met DSC_48 en de tabellen 14. 4 tot en met 14. 9. Bij aanvang van de initialisatiefase verzendt de REDCR een frame met een dienstrooster radiobaken (BST) overeenkomstig EN 12834 en EN 13372, punten 6. 2, 6,3, 6,4 en 7. 1, waarvan de instellingen worden gespecificeerd in de onderstaande tabel 14. 4. Tabel 14. 4 Initialisatie: instellingen BST-frame Field Settings Link Identifier Broadcast address BeaconId As per EN 12834 Time As per EN 12834 Profile No extension, 0 or 1 to be used MandApplications No extension, EID not present, Parameter not present, AID= 2 Freight&Fleet NonMandApplications Not present ProfileList No extension, number of profiles in list = 0 Fragmentation header No fragmentation Layer 2 settings Command PDU, UI command In de onderstaande tabel 14. 5 worden de instellingen van tabel 14. 4 verduidelijkt aan de hand van een praktijkvoorbeeld, met aanduiding van de bitcodering. Tabel 14. 5 Initialisatie: voorbeeld inhoud BST-frame Octet # Attribute/Field Bits in octet Description 1 FLAG Start flag 2 Broadcast ID Broadcast address 3 MAC Control Field Command PDU 4 LLC Control field UI command 5 Fragmentation header No fragmentation 6 BST Initialisation request SEQUENCE {     OPTION indicator BeaconID SEQUENCE { ManufacturerId INTEGER (0. 65535) NonMand applications not present       Manufacturer Identifier 7     8     IndividualID INTEGER (0. 134217727) } 27 bit ID available for manufacturer 9 10 11 12 Time INTEGER (0. 4294967295) 32 bit UNIX real time 13 14 15 16 Profile INTEGER (0. 127,…) No extension. Example profile 0 17 MandApplications SEQUENCE (SIZE(0. 127,…)) OF { No extension, Number of mandApplications=1 18 SEQUENCE {     OPTION indicator EID not present OPTION indicator Parameter not present AID DSRCApplicationEntityID } } No extension. AID= 2 Freight&Fleet 19 ProfileList SEQUENCE (0.  127,…) OF Profile } No extension, number of profiles in list = 0 20 FCS Frame check sequence 21 22 Flag End Flag DSC_45 Bij ontvangst van een BST verzendt de DSRC-VU een verzoek om toewijzing van een tijdvenster, als bedoeld in EN 12795 en EN 13372, punt 7. 1. 1, zonder specifieke RTM-instellingen. In tabel 14. 6 staat een voorbeeld van de bitcodering. Tabel 14. 6 Initialisatie: frame-inhoud verzoek om toewijzing van tijdvenster Octet # Attribute/Field Bits in octet Description 1 FLAG Start flag 2 Private LID Link address of specific DSRC-VU 3 4 5 6 MAC Control field Private window request 7 FCS Frame check sequence 8 9 Flag End Flag DSC_46 De REDCR beantwoordt dit verzoek door een tijdvenster toe te wijzen, als bedoeld in EN 12795 en EN 13372, punt 7. 1. 1, zonder specifieke RTM-instellingen. In tabel 14. 7 staat een voorbeeld van de bitcodering. Tabel 14. 7 Initialisatie: frame-inhoud toewijzing van tijdvenster Octet # Attribute/Field Bits in octet Description 1 FLAG Start flag 2 Private LID Link address of the specific DSRC-VU 3 4 5 6 MAC Control field Private window allocation 7 FCS Frame check sequence 8 9 Flag End Flag DSC_47 Bij ontvangst van het toegewezen tijdvenster verzendt de DSRC-VU het dienstrooster voertuig (VST), als bedoeld in EN 12834 en EN 13372, punten 6. 2, 6,3, 6. 4 en 7. 1, volgens de in tabel 14. 8 gespecificeerde instellingen en binnen het toegewezen tijdvenster voor verzending. Tabel 14. 8 Initialisatie: instellingen VST-frame Field Settings Private LID As per EN 12834 VST parameters Fill=0, then for each supported application: EID present, parameter present, AID=2, EID as generated by the OBU Parameter No extension, Contains the RTM Context Mark ObeConfiguration The optional ObeStatus field may be present, but shall not be used by the REDCR Fragmentation header No fragmentation Layer 2 settings Command PDU, UI command DSC_48 De DSRC-VU ondersteunt de toepassing „Freight and Fleet”, geïdentificeerd door toepassingsidentificator (AID) ‘2’. Mogelijk worden andere toepassingsidentificatoren ondersteund, maar die staan niet in deze VST, aangezien de BST alleen AID=2 vereist. Het veld „Toepassingen” bevat een lijst van ondersteunde toepassingen in de DSRC-VU.  Voor elke ondersteunde toepassing wordt een verwijzing naar de toepasselijke norm opgegeven, met name Rtm-ContextMark, bestaande uit een objectidentificator die de bijbehorende norm voorstelt, het deel van de norm (deel 9 voor RTM) en in voorkomend geval de versie daarvan, alsook een EID die door de DSRC-VU wordt gegenereerd en die aan deze toepassing gekoppeld is. In de onderstaande tabel 14. 9 worden de instellingen van tabel 14. 8 verduidelijkt aan de hand van een praktijkvoorbeeld, met aanduiding van de bitcodering. Tabel 14. 9 Initialisatie: voorbeeld inhoud VST-frame Octet # Attribute/Field Bits in octet Description 1 FLAG Start flag 2 Private LID Link address of the specific DSRC-VU 3 4 5 6 MAC Control field Command PDU 7 LLC Control field UI command 8 Fragmentation header No fragmentation 9 VST SEQUENCE { Initialisation response Fill BIT STRING (SIZE(4)) Unused and set to 0 10 Profile INTEGER (0. 127,. ) Applications SEQUENCE OF { No extension. Example profile 0 11 No extension, 1 application 12 SEQUENCE {     OPTION indicator EID present OPTION indicator Parameter present AID DSRCApplicationEntityID No extension. AID= 2 Freight&Fleet 13 EID Dsrc-EID Defined within the OBU and identifying the application instance. 14 Parameter Container { No extension, Container Choice = 02, Octet string 15   No extension, Rtm Context Mark length = 8 16 Rtm-ContextMark::= SEQUENCE { StandardIdentifier standardIdentifier Object Identifier of the supported standard, part, and version. Example: ISO (1) Standard (0) TARV (15638) part9(9) Version1 (1). First octet is 06H, which is the Object Identifier Second octet is 06H, which is its length. Subsequent 6 octets encode the example Object Identifier Note that only one element of the sequence is present (the optional RtmCommProfile element is omitted) 17 18 19 20 21 22 23 24 ObeConfiguration Sequence {     OPTION indicator ObeStatus not present EquipmentClass INTEGER (0. 32767)   25   26 ManufacturerId INTEGER (0. 65535) Manufacturer identifier for the DSRC-VU as described in ISO 14816 Register 27 28 FCS Frame check sequence 29 30 Flag End Flag DCS_49 De REDCR leest vervolgens de gegevens door een Get-commando te verzenden, zoals gedefinieerd in EN 13372, punten 6. 2, 6. 3 en 6. 4 en in EN 12834, met de in tabel 14. 10 gespecificeerde instellingen. Tabel 14. 10 Overzicht: instellingen GET. request-frame Field Settings Invoker Identifier (IID) Not present Link Identifier (LID) Link address of the specific DSRC-VU Chaining No Element Identifier (EID) As specified in the VST.  No extension Access Credentials No AttributeIdList No extension, 1 attribute, AttributeID = 1 (RtmData) Fragmentation No Layer2 settings Command PDU, Polled ACn command In tabel 14. 11 wordt aan de hand van een voorbeeld verduidelijkt hoe de RTM-gegevens worden gelezen. Tabel 14. 11 Overzicht: voorbeeld GET. request-frame Octet # Attribute/Field Bits in octet Description 1 FLAG Start flag 2 Private LID Link address of the specific DSRC-VU 3 4 5 6 MAC Control field Command PDU 7 LLC Control field Polled ACn commando, n-bit 8 Fragmentation header No fragmentation 9 Get. request SEQUENCE { Get request OPTION indicator Access Credentials not present OPTION indicator IID not present OPTION indicator AttributeIdList present Fill BIT STRING(SIZE(1)) Set to 0. 10 EID INTEGER(0. 127,…) The EID of the RTM application instance, as specified in the VST. No extension 11 AttributeIdList SEQUENCE OF { AttributeId }} No extension, number of attributes = 1 12 AttributeId=1, RtmData. No extension 13 FCS Frame check sequence 14 15 Flag End Flag DSC_50 Bij ontvangst van een verzoek om gegevens op te halen (Get-commando) verzendt de DSRC-VU een antwoord met de opgevraagde gegevens, zoals gedefinieerd in EN 13372, punten 6. 2, 6. 3 en 6. 4 en in EN 12834, met de in tabel 14. 12 gespecificeerde instellingen. Tabel 14. 12 Overzicht: instellingen GET. response-frame Field Settings Invoker Identifier (IID) Not present Link Identifier (LID) As per EN 12834 Chaining No Element Identifier (EID) As specified in the VST. Access Credentials No Fragmentation No Layer2 settings Response PDU, Response available and command accepted, ACn command In tabel 14. 13 wordt aan de hand van een voorbeeld verduidelijkt hoe de RTM-gegevens worden gelezen. Tabel 14. 13 Overzicht: voorbeeld inhoud antwoordframe Octet # Attribute/Field Bits in octet Description 1 FLAG Start flag 2 Private LID Link address of the specific DSRC-VU 3 4 5 6 MAC Control field Response PDU 7 LLC Control field Response available, ACn command n bit 8 LLC Status field Response available and command accepted 9 Fragmentation header No fragmentation 10 Get. response SEQUENCE { Get response OPTION indicator IID not present OPTION indicator Attribute List present OPTION indicator Return status not present Fill BIT STRING(SIZE(1)) Not used 11 EID INTEGER(0. 127,…) Responding from the RTM application Instance.  No extension, 12 AttributeList SEQUENCE OF { No extension, number of attributes = 1 13 Attributes SEQUENCE { AttributeId No extension, AttributeId=1 (RtmData) 14 AttributeValue CONTAINER { No extension, Container Choice = 1010. 15 RtmData 16 17 … … n }}}} n+1 FCS Frame check sequence n+2 n+3 Flag End Flag DSC_51 De REDCR verbreekt vervolgens de verbinding door een Event_Report, Release-commando te verzenden overeenkomstig EN 13372, punten 6. 2, 6. 3 en 6. 4 en EN 12834, punt 7. 3. 8, zonder specifieke RTM-instellingen. In tabel 14. 14 staat een voorbeeld van de bitcodering voor het Release-commando. Tabel 14. 14 Verbindingsverbreking Frame-inhoud Event_Report Release-commando Octet # Attribute/Field Bits in octet Description 1 FLAG Start flag 2 Private LID Link address of the specific DSRC-VU 3 4 5 6 MAC Control field The frame contains a command LPDU 7 LLC Control field UI command 8 Fragmentation header No fragmentation 9 EVENT_REPORT. request SEQUENCE { EVENT_REPORT (Release) OPTION indicator Access Credentials not present OPTION indicator Event parameter not present OPTION indicator IID not present Mode BOOLEAN No response expected 10 EID INTEGER (0. 127,…) No extension, EID = 0 (System) 11 EventType INTEGER (0. 127,…) } Event type 0 = Release 12 FCS Frame check sequence 13 14 Flag End Flag DSC_52 De DSRC-VU dient het Release-commando niet te beantwoorden. De verbinding wordt daarop verbroken. 5. 4. 8   Beschrijving van de testtransactie via DSRC-interfaces DSC_53 Zoals vastgelegd in aanhangsel 11 „Algemene beveiligingsmechanismen” moeten met behulp van het hierboven toegelichte Get-commando volledige tests, met inbegrip van gegevensbeveiliging, worden uitgevoerd door personen die over de nodige bevoegdheden beschikken om toegang te krijgen tot beveiligingsprocedures. DSC_54 Zoals voorgeschreven in aanhangsel 11 „Algemene beveiligingsmechanismen” en in aanhangsel 9 „Lijst van minimaal vereiste typegoedkeuringstests” moeten op het ogenblik van inbedrijfstelling en bij periodieke controles tests worden uitgevoerd. Niettemin kan de basisfunctie voor communicatie op afstand via DSRC-interfaces worden getest met behulp van het Echo-commando. Deze tests kunnen niet alleen worden vereist op het ogenblik van inbedrijfstelling of bij periodieke controles, maar ook indien de bevoegde controleautoriteit dit verlangt of indien de tachograafverordening zulks voorschrijft (zie punt 6 hieronder). DSC_55 Om deze basistest uit te voeren, verzendt de REDCR het Echo-commando tijdens een verbindingssessie, dat wil zeggen nadat de initialisatiefase met succes is voltooid.  De volgorde van interacties is derhalve vergelijkbaar met die van een ondervraging: —    Stap 1 De REDCR verzendt een dienstrooster radiobaken (BST) met de toepassingsidentificatoren (AID's) in de lijst van ondersteunde diensten. Voor RTM-toepassingen is dit doorgaans de dienst waarvan de AID gelijk is aan 2. De DSRC-VU onderzoekt de ontvangen BST en verzendt een antwoord indien blijkt dat in de BST de toepassing „Freight&Fleet” (AID=2) wordt aangeroepen. Indien de REDCR geen AID=2 verzendt, beëindigt de DSRC-VU de transactie met de REDCR. —     Stap 2 De DSRC-VU verzendt een verzoek om toewijzing van een tijdvenster. —     Stap 3 De REDCR verzendt een toegewezen tijdvenster. —     Stap 4 De DSRC-VU verzendt binnen het toegewezen tijdvenster een frame met het dienstrooster voertuig (VST). Deze VST bevat een lijst van alle toepassingen die deze DSRC-VU ondersteunt in het domein „Freight&Fleet” (AID=2). De verschillende toepassingen worden geïdentificeerd door unieke elementidentificatoren (EID's), gekoppeld aan een parameterwaarde die de ondersteunde toepassing aangeeft. —     Stap 5 De REDCR analyseert de ontvangen VST. Indien de VST als irrelevant wordt beschouwd (bijvoorbeeld een VST ontvangen van een DSRC-VU die geen RTM-VU is), verbreekt de REDCR de verbinding (Release-commando). Wordt de ontvangen VST geschikt bevonden, dan begint de REDCR de toepassing te concretiseren. —     Stap 6 De REDCR verzendt een Echo-commando naar de betrokken DSRC-VU, en wijst een tijdvenster toe. —     Stap 7 De DSRC-VU verzendt binnen het toegewezen tijdvenster een Echo-antwoordframe. De gegevensuitwisseling in het kader van een Echo-commando wordt verduidelijkt aan de hand van het praktijkvoorbeeld in de volgende tabellen. DSC_56 De initialisatie wordt uitgevoerd overeenkomstig punt 5. 4. 7 (DSC_44 tot en met DSC_48) en tabellen 14. 4 tot en met 14. 9. DSC_57 De REDCR verzendt een Action, Echo-commando overeenkomstig ISO 14906 met 100 gegevensbytes en zonder specifieke RTM-instellingen. De inhoud van het door de REDCR verzonden frame wordt verduidelijkt in tabel 14. 15. Tabel 14. 15 Voorbeeld van het Action, Echo-verzoekframe Octet # Attribute/Field Bits in octet Description 1 FLAG Start flag 2 Private LID Link address of the specific DSRC-VU 3 4 5 6 MAC Control field Command PDU 7 LLC Control field Polled ACn commando, n-bit 8 Fragmentation header No fragmentation 9 ACTION. request SEQUENCE { Action request (ECHO) OPTION indicator Access Credentials not present OPTION indicator Action parameter present OPTION indicator IID not present Mode BOOLEAN Response expected 10 EID INTEGER (0.  127,…) No extension, EID = 0 (System) 11 ActionType INTEGER (0. 127,…) No extension, Action type ECHO request 12 ActionParameter CONTAINER { No extension, Container Choice = 2 13 No extension. String length = 100 octets 14   Data to be echoed … … 113 }} 114 FCS Frame check sequence 115 116 Flag End Flag DSC_58 Bij ontvangst van het Echo-verzoek verzendt de DSRC-VU een Echo-antwoord van 100 bytes waarin het ontvangen commando wordt weergegeven overeenkomstig ISO 14906, zonder specifieke RTM-instellingen. In tabel 14. 16 wordt de bitcodering verduidelijkt aan de hand van een voorbeeld. Tabel 14. 16 Voorbeeld van het Action, Echo-antwoordframe Octet # Attribute/Field Bits in octet Description 1 FLAG Start flag 2 Private LID Link address of the specific VU 3 4 5 6 MAC Control field Response PDU 7 LLC Control field ACn command n bit 8 LLC status field Response available 9 Fragmentation header No fragmentation 10 ACTION. response SEQUENCE { ACTION response (ECHO) OPTION indicator IID not present OPTION indicator Response parameter present OPTION indicator Return status not present Fill BIT STRING (SIZE (1)) Not used 11 EID INTEGER (0. 127,…) No extension, EID = 0 (System) 12 ResponseParameter CONTAINER { No extension, Container Choice = 2 13 No extension. String length = 100 octets 14   Echoed data … … 113 }} 114 FCS Frame check sequence 115 116 Flag End Flag 5. 5   Naleving van Richtlijn (EU) 2015/71 5. 5. 1   Overzicht DSC_59 Ter ondersteuning van Richtlijn (EU) 2015/719 met betrekking tot de maximaal toegestane afmetingen en gewichten voor zware vrachtvoertuigen wordt voor het downloaden van OWS-gegevens via de 5,8 GHz DSRC-interface hetzelfde transactieprotocol gebruikt als voor de RTM-gegevens (zie 5. 4. 1). Het enige verschil is dat de objectidentificator van de TARV-norm verwijst naar deel 20 van de norm ISO 15638 (TARV) met betrekking tot WOB/OWS. 5. 5. 2   Commando's DSC_60 Voor de OWS-transactie wordt hetzelfde commando gebruikt als voor een RTM-transactie. 5. 5. 3   Volgorde van ondervragingscommando's DSC_61 De volgorde van ondervragingscommando's voor OWS-gegevens is identiek aan die voor RTM-gegevens. 5. 5. 4   Gegevensstructuren DSC_62 De payloadgegevens (OWS-gegevens) bestaan uit de samenvoeging van: 1. EncryptedOwsPayload data, zijnde de codering van de in punt 5. 5. 5 van ASN. 1 gedefinieerde OwsPayload. Zoals gespecificeerd in aanhangsel 11, wordt dezelfde coderingsmethode toegepast als voor RtmData. 2. DSRCSecurityData, berekend met dezelfde algoritmen als voor de RtmData, zoals gespecificeerd in aanhangsel 11. 5. 5.  5   ASN. 1-module voor de OWS-transactie via DSRC-interface DSC_63 De ASN. 1-module voor de DSRC-interfacegegevens in de RTM-toepassing wordt als volgt gedefinieerd: Tekst van het beeld TarvOws {iso(1) standard(0) 15638 part20(20) version1(1)} DEFINITIONS AUTOMATIC TAGS ::= BEGIN IMPORTS -- Imports data attributes and elements from EFC which are used for OWS LPN FROM EfcDsrcApplication {iso(1) standard(0) 14906 application(0) version5(5)} -- Imports function parameters from the EFC Application Interface Definition SetMMIRq FROM EfcDsrcApplication {iso(1) standard(0) 14906 application(0) version5(5)} -- Imports the L7 DSRCData module data from the EFC Application Interface Definition Action-Request, Action-Response, ActionType, ApplicationList, AttributeIdList, AttributeList, Attributes, BeaconID, BST, Dsrc-EID, DSRCApplicationEntityID, Event-Report-Request, Event-Report- Response, EventType, Get-Request, Get-Response, Initialisation-Request, Initialisation-Response, ObeConfiguration, Profile, ReturnStatus, Time, T-APDUs, VST FROM EfcDsrcGeneric {iso(1) standard(0) 14906 generic(1) version5(5)}; -- Definitions of the OWS functions: OWS-InitialiseComm-Request ::= BST OWS-InitialiseComm-Response::= VST OWS-DataRetrieval-Request::= Get-Request (WITH COMPONENTS {fill (SIZE(1)), eid, accessCredentials ABSENT, iid ABSENT, attrIdList}) OWS-DataRetrieval-Response::= Get-Response {OwsContainer} (WITH COMPONENTS {. , eid, iid ABSENT}) OWS-TerminateComm::= Event-Report-Request {OwsContainer}(WITH COMPONENTS {mode (FALSE), eid (0), eventType (0)}) OWS-TestComm-Request::= Action-Request {OwsContainer} (WITH COMPONENTS {. , eid (0), actionType (15), accessCredentials ABSENT, iid ABSENT}) OWS-TestComm-Response::= Action-Response {OwsContainer} (WITH COMPONENTS {. , fill (SIZE(1)), eid (0), iid ABSENT}) -- Definitions of the OWS attributes: OwsData :: = SEQUENCE { encryptedOwsPayload OCTET STRING (SIZE(51)) (CONSTRAINED BY { -- calculated encrypting OwsPayload as per Appendix 11 --}), DSRCSecurityData OCTET STRING } OwsPayload :: = SEQUENCE { tp15638VehicleRegistrationPlate LPN -- Vehicle Registration Plate as per EN 15509. recordedWeight INTEGER (0. 65535), -- 0= Total measured weight of the heavy goods vehicle -- with 10 Kg resolution. axlesConfiguration OCTET STRING SIZE (3), -- 0= 20 bits allowed for the number -- of axles for 10 axles. axlesRecordedWeight OCTET STRING SIZE (20), -- 0= Recorded Weight for each axle -- with 10 Kg resolution. tp15638Timestamp INTEGER(0. 4294967295) -- Timestamp of current record } Ows-ContextMark ::= SEQUENCE { standardIdentifier StandardIdentifier, -- identifier of the TARV part and its version } StandardIdentifier ::= OBJECT IDENTIFIER OwsContainer ::= CHOICE { integer [0] INTEGER, bitstring [1] BIT STRING, octetstring [2] OCTET STRING (SIZE (0. 127,. )), universalString [3] UniversalString, beaconId [4] BeaconID, t-apdu [5] T-APDUs, dsrcApplicationEntityId [6] DSRCApplicationEntityID, dsrc-Ase-Id [7] Dsrc-EID, attrIdList [8] AttributeIdList, attrList [9] AttributeList{RtmContainer}, reserved10 [10] NULL, OwsContextmark [11] Ows-ContextMark, OwsData [12] OwsData, reserved13 [13] NULL, reserved14 [14] NULL, time [15] Time, -- values from 16 to 255 reserved for ISO/CEN usage }} END 5. 5.  6   Elementen van OwsData, uitgevoerde acties en definities De elementen van OwsData worden gedefinieerd ter ondersteuning van Richtlijn (EU) 2015/719 met betrekking tot de maximaal toegestane afmetingen en gewichten voor zware vrachtvoertuigen („vrachtwagens”). Ze hebben de volgende betekenis: — recordedWeight is het gemeten totale gewicht van de vrachtwagen, uitgedrukt in een hoeveelheidseenheid van 10 kg als bedoeld in EN ISO 14906. Zo komt een waarde van 2 500 bijvoorbeeld overeen met een totaal gewicht van 25 ton. — axlesConfiguration is de opbouw van de vrachtwagen wat het aantal assen betreft. De opbouw wordt gedefinieerd met het volgende 20-bits masker (overeenkomstig EN ISO 14906). Een 2-bits masker stelt de opbouw van een as voor in het volgende formaat: — De waarde ‘00B’ betekent „niet beschikbaar” omdat het voertuig niet uitgerust is met apparatuur om de asbelasting te registreren. — De waarde ‘01B’ betekent dat er geen as aanwezig is. — De waarde ‘10B’ betekent dat een as aanwezig is, dat de asbelasting werd berekend en geregistreerd en beschikbaar wordt gesteld in het veld axlesRecordedWeight. — De waarde ‘11B’ is gereserveerd voor toekomstig gebruik (RFU). De laatste vier bits zijn gereserveerd voor toekomstig gebruik (RFU). Aantal assen   Aantal assen trekker Aantal assen oplegger/aanhangwagen 00/01/10/11 00/01/10/11 00/01/10/11 00/01/10/11 00/01/10/11 00/01/10/11 00/01/10/11 00/01/10/11 00/01/10/11 00/01/10/11 RFU (4 bits) — axlesRecordedWeight is de specifieke asbelasting die voor elke as werd geregistreerd, uitgedrukt in een hoeveelheidseenheid van 10 kg. Voor elke as worden twee bytes gebruikt. Zo komt een waarde van 150 bijvoorbeeld overeen met een totale asbelasting van 1 500 kg. De andere gegevenstypes worden vastgelegd in punt 5. 4. 5. 5. 5. 7   Mechanisme voor gegevensoverdracht DSC_64 Voor de overdracht van OWS-gegevens tussen het ondervragingssysteem en de DSRC-module in het voertuig wordt hetzelfde mechanisme gebruikt als voor RTM-gegevens (zie 5. 4. 6). DSC_65 De gegevensoverdracht tussen het platform dat de gegevens over de maximale gewichten verzamelt, en de DSRC-module in het voertuig berust op de in punt 5. 6 gedefinieerde fysieke verbinding, interfaces en protocollen. 5. 6   Gegevensoverdracht tussen DSRC-VU en VU 5. 6. 1   Fysieke verbinding en interfaces DSC_66 De verbinding tussen de VU en de DSRC-VU kan bestaan uit een fysieke kabel of een draadloze BLE-verbinding voor korteafstandscommunicatie op basis van Bluetooth v4. 0.  DSC_67 De volgende voorschriften moeten worden nageleefd, ongeacht de gekozen fysieke verbinding en interface: DSC_68 a) De verbinding tussen de VU en de DSRC-VU moet berusten op een open industrienorm zodat verschillende fabrikanten in aanmerking komen voor de levering van de VU en de DSRC-VU, met inbegrip van de diverse uitvoeringsvormen daarvan. De VU wordt verbonden met de DSRC-VU door middel van i) een vaste kabel met een lengte van ten minste 2 m die via een goedgekeurde Straight DIN 41612-conforme 11-pens H11-stekker van de DSRC-VU wordt aangesloten op een soortgelijke DIN/ISO-conforme contrastekker van de VU, ii) een BLE(Bluetooth Low Energy)-verbinding, iii) een standaardverbinding die voldoet aan ISO 11898 of SAE J1939. DSC_69 b) De definitie van de interfaces en verbinding tussen de VU en de DSRC-VU moet ondersteuning bieden aan de in punt 5. 6. 2 gedefinieerde commando's van het toepassingsprotocol. DSC_70 c) De VU en de DSRC-VU moeten de gegevensoverdracht via de verbinding ondersteunen wat prestaties en stroomvoorziening betreft. 5. 6. 2   Toepassingsprotocol DSC_71 Het toepassingsprotocol tussen de VU-inrichting voor communicatie op afstand en de DSRC-VU staat in voor de periodieke gegevensoverdracht tussen de VU en de DSRC-VU. DSC_72 De belangrijkste commando's zijn: 1. Verzoek om initialisatie van de communicatieverbinding 2. Antwoord op het verzoek om initialisatie van de communicatieverbinding 3. Gegevens verzenden met de identificator van de RTM-toepassing en de door RtmData gedefinieerde payloadgegevens 4. Ontvangstbevestiging van de gegevens 5. Verzoek om verbreking van de communicatieverbinding 6. Antwoord op het verzoek om verbreking van de communicatieverbinding DSC_73 In ASN1. 0 kunnen de vorige commando's als volgt worden gedefinieerd: Tekst van het beeld Remote Communication DT Protocol DEFINITIONS ::= BEGIN RCDT-Communication Link Initialization - Request ::= SEQUENCE { LinkIdentifier INTEGER } RCDT-Communication Link Initialization - Response::= SEQUENCE { LinkIdentifier INTEGER, answer BOOLEAN } RCDT- Send Data ::= SEQUENCE { LinkIdentifier INTEGER, DataTransactionId INTEGER, RCDTData SignedTachographPayload } RCDT Data Acknowledgment :: SEQUENCE { LinkIdentifier INTEGER, DataTransactionId INTEGER, answer BOOLEAN } RCDT-Communication Link Termination - Request ::= SEQUENCE { LinkIdentifier INTEGER } RCDT-Communication Link Termination - Response::= SEQUENCE { LinkIdentifier INTEGER, answer BOOLEAN } End DSC_74 Beschrijving van de commando's en parameters: — wordt gebruikt om de communicatieverbinding te initialiseren. Dit commando wordt door de VU verzonden naar de DSRC-VU. De verbindingsidentificator (LID) wordt ingesteld door de VU en doorgegeven aan de DSRC-VU om een specifieke communicatieverbinding op te sporen.  (Opmerking: dit is bedoeld ter ondersteuning van toekomstige verbindingen en andere toepassingen/modules, zoals weging aan boord van het voertuig). — wordt door de DSRC-VU gebruikt als antwoord op het verzoek om de communicatieverbinding te initialiseren. Dit commando wordt door de DSRC-VU verzonden naar de VU. Het commando geeft als resultaat van de initialisatie ‘1’ (Geslaagd) of ‘0’ (Mislukt). DSC_75 De communicatieverbinding wordt uitsluitend geïnitialiseerd na installatie, kalibrering en inschakeling van de motor/VU. — wordt door de VU gebruikt om de getekende RCDTData (dat wil zeggen de gegevens van de communicatie op afstand) naar de DSRC-VU te verzenden. De gegevens worden iedere 60 seconden verzonden. De parameter DataTransactionId identificeert de specifieke datatransmissie. De verbindingsidentificator (LID) wordt ook gebruikt om te waarborgen dat de verbinding juist tot stand is gebracht. — wordt door de DSRC-VU verzonden om feedback te geven aan de VU over de gegevensontvangst via het commando dat wordt geïdentificeerd door de parameter DataTransactionId. Het antwoord heeft de waarde ‘1’ (Geslaagd) of ‘0’ (Mislukt). Indien een VU meer dan drie antwoorden met de waarde ‘0’ ontvangt of indien de VU geen RCDT-Data Acknowledgment ontvangt voor een eerder verzonden RCDT–Send Data met een specifieke DataTransactionId, genereert en registreert de VU een voorval. — wordt door de VU verzonden naar de DSRC-VU om de verbinding voor een specifieke verbindingsidentificator (LID) te verbreken. DSC_76 Bij het herstarten van de DSRC-VU of een VU moeten alle bestaande communicatieverbindingen worden verbroken om te vermijden dat er „hangende” verbindingen bestaan als gevolg van de plotselinge uitschakeling van een VU. — wordt door de DSRC-VU verzonden naar de VU ter bevestiging van het door de VU verzonden verzoek om de verbinding voor de specifieke verbindingsidentificator (LID) te verbreken. 5. 7   Behandeling van fouten 5. 7. 1   Registratie en doorgifte van de gegevens in de DSRC-VU DSC_77 De gegevens worden in beveiligde vorm beschikbaar gesteld aan de DSRC-VU door de VUSM. De VUSM controleert of de gegevens juist zijn geregistreerd in de DSRC-VU. Eventuele fouten in de gegevensoverdracht van de VU naar het geheugen van de DSRC-VU worden geregistreerd en gemeld op basis van een voorval van het type EventFaultType met de enum-waarde ‘62’H Fout in de inrichting voor communicatie op afstand, alsook met de tijdaanduiding. DSC_78 Om interne communicatiestoringen van de VU te registreren, houdt de VU een bestand bij met een unieke naam die eenvoudig identificeerbaar is voor de controleurs.  DSC_79 Indien de VUPM er niet in slaagt VU-gegevens van de beveiligingsmodule te verkrijgen (om die aan de DSRC-VU door te geven), wordt deze storing geregistreerd op basis van een voorval van het type EventFaultType met de enum-waarde ‘62’H Fout in de inrichting voor communicatie op afstand, samen met de tijdaanduiding. De communicatiestoring wordt vastgesteld indien het bericht meer dan drie keer na elkaar niet wordt ontvangen voor het bijbehorende bericht (dat wil zeggen met dezelfde DataTransactionId in de berichten ). 5. 7. 2   Fouten in de draadloze communicatie DSC_80 Communicatiefouten worden behandeld overeenkomstig de desbetreffende DSRC-normen, met name EN 300 674-1, EN 12253, EN 12795, EN 12834 en de toepasselijke parameters van EN 13372. 5. 7. 2. 1   Fouten in codering en handtekening DSC_81 Fouten in codering en handtekening worden behandeld zoals toegelicht in aanhangsel 11 „Algemene beveiligingsmechanismen”, en worden niet opgenomen in foutmeldingen die verband houden met de gegevensoverdracht via DSRC-interfaces. 5. 7. 2. 2   Registratie van fouten Als dynamisch instrument voor draadloze communicatie functioneert de DSRC-interface in een onzekere omgeving die wordt gekenmerkt door uiteenlopende weersomstandigheden en (storings)invloeden van buitenaf. Dit is met name het geval bij gebruik van de draagbare REDCR in combinatie met rijdende voertuigen. Bijgevolg moet onderscheid worden gemaakt tussen de ‘mislukking’ van een leesbewerking en een ‘foutconditie’. Bij transacties via een draadloze interface komt het vaak voor dat leesbewerkingen mislukken. In dit geval wordt doorgaans een nieuwe poging ondernomen door de BST opnieuw te verzenden en de transacties nogmaals uit te voeren. In de meeste gevallen wordt de communicatieverbinding dan met succes tot stand gebracht en worden de gegevens met succes overgedragen, tenzij het gecontroleerde voertuig zich inmiddels buiten bereik bevindt. Om een leesbewerking met succes uit te voeren, worden doorgaans meerdere (nieuwe) pogingen ondernomen. Een leesbewerking kan mislukken doordat de antennes niet juist zijn gekoppeld (storing bij het ‘richten’) of doordat een van de antennes is afgeschermd. Een antenne kan opzettelijk worden afgeschermd, maar ook ongewild als gevolg van de fysieke aanwezigheid van een ander voertuig, radiostoringen, in het bijzonder van in de 5,8 GHz-frequentieband werkende WiFi-apparatuur of andere publiek toegankelijke draadloze communicatienetwerken. Verder kan een leesbewerking mislukken als gevolg van radarstoringen of ongunstige weersomstandigheden (bijvoorbeeld onweer) of doordat het gecontroleerde voertuig zich buiten het bereik van de DSRC-communicatieapparatuur bevindt. Afzonderlijke gevallen waarin leesbewerkingen mislukken kunnen per definitie niet worden geregistreerd om de eenvoudige reden dat er geen communicatie heeft plaatsgehad.  Indien de controleambtenaar een specifiek voertuig wil controleren door de DSRC-VU ervan te ondervragen, maar er niet in slaagt gegevens over te brengen, kan dat ook het gevolg zijn van opzettelijke manipulatie. Daarom heeft de controleambtenaar een hulpmiddel nodig om dit voorval in een logboek te registreren en collega's in het vervolgtraject te waarschuwen dat er mogelijk sprake is van een inbreuk. Zo kunnen deze collega's het voertuig tegenhouden en aan een nadere controle onderwerpen. Aangezien de communicatie mislukt is, kunnen daarover echter geen gegevens in de DSRC-VU worden geregistreerd. Bijgevolg moet deze rapportage deel uitmaken van het functionele ontwerp van de REDCR. Technisch gezien is het ‘mislukken’ van een leesbewerking niet hetzelfde als het optreden van een ‘fout’. In het kader van de tachograaftoepassing betekent een ‘fout’ dat een onjuiste waarde werd verkregen. De gegevens zijn al beveiligd wanneer ze aan de DSRC-VU worden doorgegeven. Bijgevolg moet de verstrekker van de gegevens ze verifiëren (zie punt 5. 4). Gegevens die vervolgens via de ether worden overgebracht, ondergaan cyclische redundantiecontroles (CRC) op het niveau van de communicatieverbinding. Een geslaagde CRC betekent dat de gegevens juist zijn. Indien de CRC mislukt, moeten de gegevens opnieuw worden verzonden. De kans dat gegevens waarvoor de CRC mislukt toch met succes worden overgebracht, is statistisch gezien zo klein dat ze te verwaarlozen is. Indien de CRC mislukt en er geen tijd is om de juiste gegevens opnieuw te verzenden en te ontvangen, is het resultaat geen fout, maar de concretisering van een mislukte leesbewerking. Het enige betekenisvolle gegeven dat over deze ‘mislukking’ kan worden geregistreerd, is het aantal keren dat transacties met succes werden geïnitialiseerd, zij het zonder succesvolle gegevensoverdracht naar de REDCR. DSC_82 De REDCR registreert bijgevolg — met tijdaanduiding — hoeveel keren de initialisatiefase van een ondervraging via de DSRC-interface met succes werd voltooid, maar de transactie niettemin werd beëindigd voordat de REDCR de gegevens met succes heeft kunnen ophalen. Deze gegevens worden aan de controleambtenaar beschikbaar gesteld en opgeslagen in het geheugen van de REDCR. De daartoe gebruikte middelen hangen af van het productontwerp of van de specificaties van de bevoegde controleautoriteiten. Het enige betekenisvolle gegeven dat over de ‘fout’ kan worden geregistreerd, is het aantal keren dat de REDCR er niet in geslaagd is de ontvangen gegevens te decoderen. Dit heeft echter alleen te maken met de doelmatigheid van de REDCR-software.  Zelfs na decodering kunnen gegevens semantisch gezien betekenisloos zijn. DSC_83 De REDCR registreert bijgevolg — met tijdaanduiding — het aantal mislukte pogingen om de via de DSRC-interface ontvangen gegevens te decoderen. 6   TESTS BIJ INBEDRIJFSTELLING EN PERIODIEKE CONTROLE VAN DE FUNCTIE VOOR COMMUNICATIE OP AFSTAND 6. 1   Algemeen DSC_84 In het kader van de functie voor communicatie op afstand worden twee tests uitgevoerd: 1) Een Echo-test om de draadloze tweerichtingsverbinding tussen de DSRC-REDCR en de DSRC-VU te bevestigen. 2) Een beveiligingstest tussen bron en bestemming om te waarborgen dat een werkplaatskaart toegang kan krijgen tot de gecodeerde en getekende gegevens van de VU die via de draadloze communicatieverbinding worden verzonden. 6. 2   Echo-commando De specifieke testvoorschriften in dit punt zijn bedoeld om na te gaan of de tweerichtingsverbinding tussen DSRC-REDCR en DSRC-VU volledig operationeel is. Dankzij het Echo-commando kunnen werkplaatsen of testcentra voor typegoedkeuring de werking van de DSRC-interface testen zonder toegang te moeten krijgen tot beveiligingsreferenties. De bediener van het testapparaat hoeft bijgevolg alleen een verbinding via de DSRC-interface te initialiseren (door een BST met AID=2 te verzenden) en daarna het Echo-commando te verzenden. Indien de DSRC-interface operationeel is, ontvangt hij daarna het antwoord op het Echo-commando. Zie punt 5. 4. 8 voor meer informatie. Indien dit antwoord correct wordt ontvangen, mag ervan worden uitgegaan dat de DSRC-interface (tweerichtingsverbinding tussen DSRC-REDCR en DSRC-VU) correct functioneert. 6. 3   Tests om de beveiligde gegevensinhoud te bevestigen DSC_85 Met deze test wordt de beveiligde gegevensstroom tussen bron en bestemming bevestigd. Voor deze test moet de DSRC-testlezer worden gebruikt. De DSRC-testlezer voert dezelfde functies uit en wordt geïmplementeerd overeenkomstig dezelfde specificaties als de door controleambtenaren gebruikte lezer. Het enige verschil is dat de gebruiker van de DSRC-testlezer wordt geauthenticeerd op basis van een werkplaatskaart, en niet op basis van een controlekaart. De test kan worden uitgevoerd op het ogenblik dat de slimme tachograaf voor het eerst wordt geactiveerd of na afloop van de kalibreringsprocedure. Zodra de tachograaf is geactiveerd, genereert de voertuigunit de beveiligde gegevens voor vroegtijdige detectie, en geeft die door aan de DSRC-VU. DSC_86 De werkplaatsmedewerker plaatst de DSRC-testlezer op een afstand tussen 2 en 10 m vóór het voertuig. DSC_87 Vervolgens brengt de werkplaatsmedewerker een werkplaatskaart in de DSRC-testlezer om de voertuigunit te ondervragen en gegevens over vroegtijdige detectie te verkrijgen.  Indien de ondervraging met succes verloopt, leest de werkplaatsmedewerker de ontvangen gegevens om de integriteit ervan te controleren en zeker te stellen dat ze juist werden gedecodeerd. (*1)  – Downlink parameters subject to conformance testing in accordance with relevant parameter test from EN 300 674-1 (*2)  – Uplink parameters subject to conformance testing in accordance with relevant parameter test from EN 300 674-1 Aanhangsel 15 MIGRATIE: DE COËXISTENTIE VAN VERSCHILLENDE GENERATIES APPARATUUR BEHEREN INHOUDSOPGAVE 1. DEFINITIES 497 2. ALGEMENE BEPALINGEN 497 2. 1. Overzicht van de overgang 497 2. 2. Interoperabiliteit tussen VU's en kaarten 498 2. 3. Interoperabiliteit tussen VU's en bewegingssensoren 498 2. 4. Interoperabiliteit tussen voertuigunits, tachograafkaarten en apparatuur voor het downloaden van gegevens 498 2. 4. 1 Kaarten rechtstreeks downloaden met intelligente toepassingsgerichte apparatuur (IDE) 498 2. 4. 2 Het downloaden van een kaart via een voertuigunit 499 2. 4. 3 Het downloaden van een voertuigunit 499 2. 5. Interoperabiliteit tussen VU's en kalibratieapparatuur 499 3. BELANGRIJKSTE STAPPEN IN DE PERIODE VÓÓR DE DATUM VAN INVOERING 499 4. BEPALINGEN VOOR DE PERIODE NA DE DATUM VAN INVOERING 499 1. DEFINITIES Met het oog op de toepassing van dit aanhangsel wordt verstaan onder: slim tachograafsysteem : zoals gedefinieerd in deze bijlage (hoofdstuk 1: definitie bbb); tachograafsysteem van de eerste generatie : zoals gedefinieerd in deze verordening (artikel 2: definitie 1); tachograafsysteem van de tweede generatie : zoals gedefinieerd in deze verordening (artikel 2: definitie 7); datum van invoering : zoals gedefinieerd in deze bijlage (hoofdstuk 1: definitie ccc); Intelligente toepassingsgerichte apparatuur : apparatuur die wordt gebruikt voor het downloaden van gegevens, zoals gedefinieerd in aanhangsel 7 van deze bijlage. 2. ALGEMENE BEPALINGEN 2. 1. Overzicht van de overgang In de preambule van deze bijlage wordt een overzicht gegeven van de overgang tussen de tachograafsystemen van de eerste en de tweede generatie. In aanvulling op de bepalingen van deze preambule: — zijn bewegingssensoren van de eerste generatie niet interoperabel met voertuigunits van de tweede generatie. — begint de installatie van bewegingssensoren van de tweede generatie in voertuigen op hetzelfde ogenblik als de installatie van voertuigunits van de tweede generatie. — apparatuur voor het downloaden van gegevens en kalibreren moet evolueren om het gebruik van beide generaties controleapparaten en tachograafkaarten te ondersteunen. 2. 2.  Interoperabiliteit tussen VU's en kaarten Er wordt van uitgegaan dat tachograafkaarten van de eerste generatie interoperabel zijn met voertuigunits van de eerste generatie (overeenkomstig bijlage IB bij deze verordening), en dat tachograafkaarten van de tweede generatie interoperabel zijn met voertuigunits van de tweede generatie (overeenkomstig bijlage 1C bij deze verordening). Voorts zijn ook de onderstaande voorschriften van toepassing. MIG_001 Behoudens het bepaalde in voorschrift MIG_004 en MIG_005, mogen tachograafkaarten van de eerste generatie verder worden gebruikt in voertuigunits van de tweede generatie tot het einde van hun geldigheidsduur. De houders kunnen evenwel vragen ze te vervangen door tachograafkaarten van de tweede generatie zodra deze beschikbaar zijn. MIG_002 Het moet mogelijk zijn elke geldige bestuurders-, controle- en bedrijfskaart van de eerste generatie te gebruiken in voertuigunits van de tweede generatie. MIG_003 Werkplaatsen kunnen dit definitief onmogelijk maken, zodat tachograafkaarten van de eerste generatie niet meer worden aanvaard. Dit mag alleen gebeuren nadat de Europese Commissie is gestart met een procedure die tot doel heeft werkplaatsen te verzoeken dit te doen, bijvoorbeeld tijdens elke periodieke inspectie van de tachograaf. MIG_004 Voertuigunits van de tweede generatie mogen alleen werkplaatskaarten van de tweede generatie kunnen gebruiken. MIG_005 Om de werkingsmodus te bepalen, houden voertuigunits van de tweede generatie alleen rekening met het type geldige kaarten dat wordt ingebracht, ongeacht de generatie. MIG_006 Elke geldige tachograafkaart van de tweede generatie kan in voertuigunits van de eerste generatie worden gebruikt op exact dezelfde wijze als hetzelfde type tachograafkaarten van de eerste generatie. 2. 3. Interoperabiliteit tussen VU's en bewegingssensoren Er wordt van uitgegaan dat bewegingssensoren van de eerste generatie interoperabel zijn met voertuigunits van de eerste generatie, en dat bewegingssensoren van de tweede generatie interoperabel zijn met voertuigunits van de tweede generatie. Voorts zijn ook de onderstaande voorschriften van toepassing. MIG_007 Voertuigunits van de tweede generatie kunnen niet worden gekoppeld aan en gebruikt met bewegingssensoren van de eerste generatie. MIG_008 Bewegingssensoren van de tweede generatie kunnen worden gekoppeld aan en gebruikt met uitsluitend voertuigunits van de tweede generatie of met beide generaties voertuigunits. 2. 4. Interoperabiliteit tussen voertuigunits, tachograafkaarten en apparatuur voor het downloaden van gegevens MIG_009 Apparatuur voor het downloaden van gegevens kan worden gebruikt met slechts één generatie van voertuigunits en tachograafkaarten of met beide. 2. 4.  1   Kaarten rechtstreeks downloaden met intelligente toepassingsgerichte apparatuur (IDE) MIG_010 De gegevens worden gedownload door IDE van tachograafkaarten van één generatie die in hun kaartlezers worden ingebracht, met gebruikmaking van de beveiligingsmechanismen en het downloadprotocol van deze generatie, en alle gedownloade gegevens hebben het formaat dat voor deze generatie is gedefinieerd. MIG_011 Om de controle van bestuurders door autoriteiten van buiten de EU mogelijk te maken, is het ook mogelijk om gegevens van bestuurders- (en werkplaats-)kaarten van de tweede generatie te downloaden op exact dezelfde wijze als van bestuurders- (en werkplaats-)kaarten van de eerste generatie. Een dergelijke download omvat: — de en van niet-ondertekende EF's, — het en van niet-ondertekende EF's (1ste generatie), — de andere gegevensbestanden van de EF's (in DF) die worden gevraagd door de eerste generatie van het downloadprotocol. Deze informatie wordt beveiligd met een digitale handtekening, volgens de beveiligingsmechanismen van de eerste generatie. Een dergelijke download omvat geen gegevensbestanden van EF's die alleen aanwezig zijn in bestuurders- (en werkplaats-)kaarten van de tweede generatie (gegevensbestanden van EF's in DF). 2. 4. 2   Het downloaden van een kaart via een voertuigunit MIG_012 De gegevens worden gedownload van een kaart van de tweede generatie die is ingebracht in een voertuigunit van de eerste generatie, met gebruikmaking van het downloadprotocol van de eerste generatie. De kaart reageert op exact dezelfde wijze als een kaart van de eerste generatie op de commando's van de voertuigunit en de gedownloade gegevens hebben hetzelfde formaat als gegevens die zijn gedownload van een kaart van de eerste generatie. MIG_013 De gegevens worden gedownload van een kaart van de eerste generatie die is ingebracht in een voertuigunit van de tweede generatie met gebruikmaking van het in aanhangsel 7 van deze bijlage gedefinieerde downloadprotocol. De voertuigunit zendt commando's naar de kaart op precies dezelfde wijze als een voertuigunit van de eerste generatie, en de gedownloade gegevens beantwoorden aan het formaat dat is gedefinieerd voor kaarten van de eerste generatie. 2. 4. 3   Het downloaden van een voertuigunit MIG_014 Voor het downloaden van gegevens van een voertuigunit van de tweede generatie wordt gebruik gemaakt van de beveiligingsmechanismen van de tweede generatie en van het in aanhangsel 7 van deze bijlage gespecificeerde downloadprotocol.  MIG_015 Om controle-autoriteiten van buiten de EU de mogelijkheid te geven om bestuurders te controleren en werkplaatsen van buiten de EU de mogelijkheid te geven om gegevens van voertuigunits te downloaden, kan het ook mogelijk zijn om gegevens van voertuigunits van de tweede generatie te downloaden met de beveiligingsmechanismen en het downloadprotocol van de eerste generatie. De gedownloade gegevens hebben hetzelfde formaat als gegevens die zijn gedownload uit een voertuigunit van de eerste generatie. Deze mogelijkheid kan worden geselecteerd via commando's in het menu. 2. 5. Interoperabiliteit tussen VU's en kalibratieapparatuur MIG_016 Kalibratieapparatuur is in staat kalibraties te verrichten van tachografen van elke generatie, met gebruikmaking van het kalibreringsprotocol van deze generatie. Kalibratieapparatuur kan worden gebruikt met één generatie tachografen of met beide. 3. BELANGRIJKSTE STAPPEN IN DE PERIODE VÓÓR DE DATUM VAN INVOERING MIG_017 Testsleutels en -certificaten worden uiterlijk 30 maanden voor de datum van invoering ter beschikking gesteld van de fabrikanten. MIG_018 De interoperabiliteitstesten zijn uiterlijk 15 maanden voor de datum van invoering klaar om van start te gaan, op verzoek van fabrikanten. MIG_019 Officiële sleutels en certificaten worden uiterlijk 12 maanden voor de datum van invoering ter beschikking gesteld van de fabrikanten. MIG_020 De lidstaten kunnen uiterlijk 3 maanden voor de datum van invoering werkplaatskaarten van de tweede generatie afgeven. MIG_021 De lidstaten kunnen uiterlijk 1 maand voor de datum van invoering alle types tachograafkaarten van de tweede generatie afgeven. 4. BEPALINGEN VOOR DE PERIODE NA DE DATUM VAN INVOERING MIG_022 Na de invoering geven de lidstaten alleen nog tachograafkaarten van de tweede generatie af. MIG_023 Fabrikanten van voertuigunits / bewegingssensoren mogen voertuigunits / bewegingssensoren van de eerste generatie blijven produceren zolang deze worden gebruikt op het terrein, zodat defecte onderdelen kunnen worden vervangen. MIG_024 Fabrikanten van voertuigunits / bewegingssensoren kunnen het behoud van de typegoedkeuring van voertuigunits / bewegingssensoren van de eerste generatie waarvoor reeds typegoedkeuring is verkregen, vragen en krijgen. Aanhangsel 16 ADAPTER VOOR VOERTUIGEN VAN DE CATEGORIEËN M1 EN N1 INHOUD 1. AFKORTINGEN EN REFERENTIEDOCUMENTEN 501 1. 1. Afkortingen 501 1. 2. Referentienormen 501 2. ALGEMENE KENMERKEN EN FUNCTIES VAN DE ADAPTER 502 2. 1. Algemene beschrijving van de adapter 502 2. 2. Functies 502 2. 3. Beveiliging 502 3. EISEN VOOR HET CONTROLEAPPARAAT WANNEER EEN ADAPTER IS GEÏNSTALLEERD 502 4. FABRICAGE EN FUNCTIONELE VEREISTEN VAN DE ADAPTER 503 4. 1. Totstandbrenging van interfaces en aanpassing van inkomende snelheidsimpulsen 503 4. 2.  Invoering van de inkomende impulsen in de ingebouwde bewegingssensor 503 4. 3. Ingebouwde bewegingssensor 503 4. 4. Veiligheidsvoorschriften 503 4. 5. Prestatiekenmerken 504 4. 6. Materialen 504 4. 7. Merktekens 504 5. INSTALLATIE VAN HET CONTROLEAPPARAAT WANNEER EEN ADAPTER WORDT GEBRUIKT 504 5. 1. Installatie 504 5. 2. Verzegeling 505 6. CONTROLES, INSPECTIES EN HERSTELLINGEN 505 6. 1. Periodieke controles 505 7. TYPEGOEDKEURING VAN HET CONTROLEAPPARAAT WANNEER EEN ADAPTER WORDT GEBRUIKT 505 7. 1. Algemeen 505 7. 2. Functioneel certificaat 506 1. AFKORTINGEN EN REFERENTIEDOCUMENTEN 1. 1. Afkortingen TBD Nog vast te stellen VU Voertuigunit 1. 2. Referentienormen ISO16844-3 Road vehicles — Tachograph systems — Part 3: Motion sensor interface 2. ALGEMENE KENMERKEN EN FUNCTIES VAN DE ADAPTER 2. 1. Algemene beschrijving van de adapter ADA_001 De adapter levert beveiligde bewegingsgegevens die permanent representatief zijn voor de snelheid en afgelegde afstand van het voertuig aan de aangesloten VU. De adapter is alleen bestemd voor voertuigen die overeenkomstig deze verordening met een controleapparaat moeten worden uitgerust. De adapter wordt alleen geïnstalleerd en gebruikt in de onder (yy) ”adapter” van bijlage IC gedefinieerde voertuigtypen, wanneer het mechanisch niet mogelijk is een ander bestaand type bewegingssensor te installeren dat verenigbaar is met de bepalingen van deze bijlage en met de aanhangsels 1 tot en met 16 daarbij. De adapter mag geen mechanische interface met een bewegend deel van het voertuig omvatten, maar moet aangesloten zijn op de snelheids-/afstandsimpulsen die worden gegenereerd door geïntegreerde sensoren of alternatieve interfaces. ADA_002 Een bewegingssensor waarvoor typegoedkeuring is verleend (volgens de voorschriften van deze bijlage IC, punt 8, Typegoedkeuring van controleapparaten en tachograafkaarten) wordt gemonteerd in de adapterbehuizing, die eveneens een impulsomvormer omvat welke de inkomende impulsen invoert in de ingebouwde bewegingssensor. De ingebouwde bewegingssensor zelf wordt aangesloten op de voertuigunit, zodat de interface tussen de voertuigunit en de adapter voldoet aan de eisen van ISO16844-3. 2. 2. Functies ADA_003 De adapter heeft de volgende functies: — fungeert als interface en past de inkomende snelheidsimpulsen aan, — invoering van de inkomende impulsen in de ingebouwde bewegingssensor, — alle functies van de ingebouwde bewegingssensor die beveiligde bewegingsgegevens aan de voertuigunit leveren. 2. 3. Beveiliging ADA_004 Er hoeft geen veiligheidscertificering van de adapter te worden uitgevoerd overeenkomstig de in aanhangsel 10 bij deze bijlage vastgestelde algemene beveiligingsdoelstelling voor de bewegingssensor. In plaats daarvan zijn de in punt 4. 4 van dit aanhangsel gespecificeerde veiligheidseisen van toepassing. 3.  EISEN VOOR HET CONTROLEAPPARAAT WANNEER EEN ADAPTER IS GEÏNSTALLEERD Uit de in de volgende hoofdstukken vermelde eisen blijkt hoe de voorschriften van deze bijlage moeten worden verstaan wanneer een adapter wordt gebruikt. Tussen haakjes is het nummer van het voorschrift van bijlage IC vermeld. ADA_005 Het controleapparaat van een voertuig dat met een adapter is uitgerust, moet voldoen aan alle voorschriften van deze bijlage, tenzij anders gespecificeerd in dit aanhangsel. ADA_006 Wanneer een adapter is geïnstalleerd, omvat het controleapparaat kabels, de adapter (met inbegrip van een bewegingssensor) en een voertuigunit [01]. ADA_007 De functie voor het detecteren van voorvallen en/of fouten van het controleapparaat wordt als volgt gewijzigd: — wanneer de stroomvoorziening van de ingebouwde bewegingssensor [79] gedurende meer dan 200 milliseconden wordt onderbroken, veroorzaakt de voertuigunit, wanneer deze zich niet in de kalibreringsmodus bevindt, het voorval ”onderbreking in de stroomvoorziening”; — wanneer de normale gegevensstroom tussen de ingebouwde bewegingssensor en de voertuigunit wordt onderbroken en/of wanneer zich een fout voordoet in de integriteit van de gegevens of in de authenticatie van de gegevens tijdens de gegevensuitwisseling tussen de ingebouwde bewegingssensor en de voertuigunit [83], veroorzaakt de voertuigunit het voorval ”fout in de bewegingsgegevens”; — wanneer zich een ander voorval voordoet dat de beveiliging van de ingebouwde bewegingssensor aantast, wanneer deze zich niet in kalibreringsmodus bevindt, veroorzaakt de voertuigunit het voorval ”poging tot inbreuk op de beveiliging” [85]; — wanneer zich een fout in de ingebouwde bewegingssensor voordoet, wanneer deze zich niet in kalibreringsmodus bevindt, veroorzaakt de voertuigunit het voorval ”fout in het controleapparaat” [88]. ADA_008 De fouten van de adapter die door het controleapparaat kunnen worden vastgesteld, zijn die welke verband houden met de ingebouwde bewegingssensor [88]. ADA_009 De kalibreringsmodus van de voertuigunit moet het mogelijk maken de ingebouwde bewegingssensor automatisch te verbinden met koppelen de voertuigunit [202, 204]. 4. FABRICAGE EN FUNCTIONELE VEREISTEN VAN DE ADAPTER 4. 1. Totstandbrenging van interfaces en aanpassing van inkomende snelheidsimpulsen ADA_011 De inputinterface van de adapter aanvaardt frequentie-impulsen die representatief zijn voor de snelheid van het voertuig en de afgelegde afstand. De elektrische kenmerken van de inkomende impulsen zijn: nader vast te stellen door de fabrikant. Aanpassingen die alleen kunnen worden uitgevoerd door de fabrikant van de adapter en de goedgekeurde werkplaats die de adapter heeft geïnstalleerd, maken de correcte interface tussen de adapterinput en het voertuig mogelijk, voor zover van toepassing.  ADA_012 De inputinterface van de adapter moet, voor zover van toepassing, in staat zijn de frequentie-impulsen van de inkomende snelheidsimpulsen te vermenigvuldigen met of te delen door een vaste factor, teneinde het signaal te herleiden tot het in deze bijlage gedefinieerde bereik van de k-factor (4 000 tot 25 000 impulsen/km). Deze vaste factor mag alleen worden geprogrammeerd door de fabrikant van de adapter en door de goedgekeurde werkplaats die de adapter heeft geïnstalleerd. 4. 2. Invoering van de inkomende impulsen in de ingebouwde bewegingssensor ADA_013 De inkomende impulsen, eventueel aangepast zoals hierboven uiteengezet, worden zodanig in de ingebouwde bewegingssensor ingevoerd dat elke inkomende impuls door de bewegingssensor wordt gedetecteerd. 4. 3. Ingebouwde bewegingssensor ADA_014 De ingebouwde bewegingssensor wordt gestimuleerd door de ingevoerde impulsen, waardoor hij bewegingsgegevens kan voortbrengen die accuraat de beweging van het voertuig weergeven, alsof er een mechanische interface bestond tussen de sensor en een bewegend deel van het voertuig. ADA_015 De identificatiegegevens van de ingebouwde bewegingssensor worden door de voertuigunit gebruikt om de adapter te identificeren [95]. ADA_016 De in de ingebouwde bewegingssensor opgeslagen installatiegegevens worden geacht de installatiegegevens van de adapter te vertegenwoordigen [122]. 4. 4. Veiligheidsvoorschriften ADA_017 De behuizing van de adapter wordt zodanig ontworpen dat ze niet kan worden geopend. Ze wordt verzegeld, zodat pogingen om ermee te knoeien gemakkelijk kunnen worden vastgesteld (bijv. door een visuele inspectie, zie ADA_035). De verzegeling moet voldoen aan dezelfde eisen als zegels van bewegingsopnemers [398 tot en met 406] ADA_018 Het mag niet mogelijk zijn de ingebouwde bewegingssensor los te maken van de adapter zonder het zegel/de zegels van de adapterbehuizing of het zegel tussen de sensor en de adapterbehuizing te verbreken (zie ADA_034). ADA_019 De adapter moet ervoor zorgen dat bewegingsgegevens uitsluitend kunnen worden verwerkt en afgeleid van de adapterinput. 4. 5. Prestatiekenmerken ADA_020 De adapter moet volledig operationeel zijn binnen het door de fabrikant vastgestelde temperatuurbereik. ADA_021 De adapter moet volledig operationeel zijn binnen het vochtigheidsbereik van 10 % tot 90 % [214]. ADA_022 De adapter moet tegen overspanning, polariteitomkering en kortsluiting worden beveiligd [216]. ADA_023 De adapter moet: — reageren op een magnetisch veld dat de detectie van beweging van het voertuig stoort. In dat geval, wordt door de voertuigunit een fout in de sensor [88] geregistreerd en opgeslagen, ofwel — een aftastelement bevatten dat beschermd is tegen, of ongevoelig is voor, een magnetisch veld [217].  ADA_024 De adapter moet voldoen aan het internationale reglement VN ECE R 10 met betrekking tot elektromagnetische compatibiliteit en moet tegen elektrostatische ontladingen en stootspanning worden beveiligd [218] 4. 6. Materialen ADA_025 De adapter moet voldoen aan beschermingsklasse (nader vast te stellen door de fabrikant, afhankelijk van de installatiepositie) [220, 221]. ADA_026 De kleur van de adapterbehuizing moet geel zijn. 4. 7. Merktekens ADA_027 Op de adapter moet een opschriftenplaatje worden bevestigd waarop de volgende gegevens zijn vermeld: — naam en adres van de fabrikant van de adapter, — onderdeelnummer van de fabrikant en bouwjaar van de adapter, — goedkeuringsmerkteken van het type adapter of van het type controleapparaat met adapter, — de datum waarop de adapter is geïnstalleerd, — het voertuigidentificatienummer van het voertuig waarin de adapter is geïnstalleerd. ADA_028 Op het opschriftenplaatje moeten ook de volgende bijzonderheden worden vermeld (indien niet direct leesbaar aan de buitenzijde van de ingebouwde bewegingssensor): — naam van de fabrikant van de ingebouwde bewegingssensor, — onderdeelnummer van de fabrikant en bouwjaar van de ingebouwde bewegingssensor, — goedkeuringsmerkteken van de ingebouwde bewegingssensor. 5. INSTALLATIE VAN HET CONTROLEAPPARAAT WANNEER EEN ADAPTER WORDT GEBRUIKT 5. 1. Installatie ADA_029 Adapters voor installatie in voertuigen mogen alleen worden geïnstalleerd door voertuigfabrikanten of door erkende werkplaatsen die gemachtigd zijn om digitale en slimme tachografen te installeren, te activeren en te kalibreren. ADA_030 Een erkende werkplaats die een adapter installeert, stelt de inputinterface in en selecteert de verdeelverhouding van het inputsignaal (indien van toepassing). ADA_031 Een erkende werkplaats die een adapter installeert, verzegelt de adapterbehuizing. ADA_032 De adapter wordt zo dicht mogelijk geïnstalleerd bij het deel van het voertuig dat de inkomende impulsen levert. ADA_033 De kabels voor de stroomvoorziening van de adapter zijn rood (positief) en zwart (aarding). 5. 2. Verzegeling ADA_034 De volgende verzegelingseisen zijn van toepassing: — de behuizing van de adapter wordt verzegeld (zie ADA_017), — de behuizing van de ingebouwde sensor wordt verzegeld aan de adapterbehuizing, tenzij het onmogelijk is de sensor uit de adapterbehuizing te verwijderen zonder het zegel/de zegels van de adapterbehuizing te verbreken (zie ADA_018), — de adapterbehuizing wordt verzegeld aan het voertuig, — de verbinding tussen de adapter en de apparatuur die de inkomende impulsen verstuurt, wordt aan beide uiteinden verzegeld (voor zover redelijkerwijze mogelijk). 6. CONTROLES, INSPECTIES EN HERSTELLINGEN 6. 1.  L_2016139PL. 01000101. xml 26. 5. 2016    PL Dziennik Urzędowy Unii Europejskiej L 139/1 ROZPORZĄDZENIE WYKONAWCZE KOMISJI (UE) 2016/799 z dnia 18 marca 2016 r. w sprawie wykonania rozporządzenia Parlamentu Europejskiego i Rady (UE) nr 165/2014 ustanawiającego wymogi dotyczące budowy, sprawdzania, instalacji, użytkowania i naprawy tachografów oraz ich elementów składowych (Tekst mający znaczenie dla EOG) KOMISJA EUROPEJSKA, uwzględniając Traktat o funkcjonowaniu Unii Europejskiej, uwzględniając rozporządzenie Parlamentu Europejskiego i Rady (UE) nr 165/2014 z dnia 4 lutego 2014 r. w sprawie tachografów stosowanych w transporcie drogowym (1), w szczególności jego art. 11 i art. 12 ust. 7, a także mając na uwadze, co następuje: (1) Rozporządzeniem (UE) nr 165/2014 wprowadzono tzw. drugą generację tachografów cyfrowych (tzw. tachografów inteligentnych), które obejmują połączenie z urządzeniem GNSS (globalny system nawigacji satelitarnej), urządzenie wczesnego wykrywania na odległość oraz interfejs do inteligentnych systemów transportowych. Należy ustanowić specyfikacje dotyczące wymogów technicznych w zakresie budowy tachografów inteligentnych. (2) Urządzenie wczesnego wykrywania na odległość, przewidziane na mocy art. 9 ust. 4 rozporządzenia (UE) nr 165/2014, powinno przekazywać funkcjonariuszowi kontroli drogowej dane z tachografu cyfrowego oraz informacje dotyczące mas oraz masy przypadającej na osie całego zespołu pojazdów (ciągnika i przyczep lub naczep), zgodnie z dyrektywą 96/53/WE Parlamentu Europejskiego i Rady (2). Powinno to umożliwić skuteczną i szybką kontrolę pojazdów przez organy kontrolne, przy zmniejszeniu liczby urządzeń elektronicznych w kabinie pojazdu. (3) Zgodnie z dyrektywą 96/53/WE, w przypadku urządzenia wczesnego wykrywania na odległość należy stosować normy CEN DSRC (3), o których mowa we wspomnianej dyrektywie, w zakresie częstotliwości 5795–5805 MHz. Ponieważ ten zakres częstotliwości jest wykorzystywany również na potrzeby elektronicznych systemów pobierania opłat, a także w celu uniknięcia zakłóceń między aplikacjami służącymi do pobierania i kontroli opłat drogowych, funkcjonariusze służb kontrolnych nie powinni używać urządzenia wczesnego wykrywania na odległość na placu poboru opłat. (4) Należy wprowadzić w tachografie inteligentnym nowe mechanizmy zabezpieczeń na potrzeby utrzymania poziomu bezpieczeństwa tachografu cyfrowego, aby wyeliminować obecne luki w zakresie bezpieczeństwa. Jednym z takich zagrożeń jest brak daty ważności certyfikatów cyfrowych. W celu uwzględnienia najlepszych praktyk w dziedzinie bezpieczeństwa zaleca się unikanie stosowania certyfikatów cyfrowych bez dat ważności. Okres ważności normalnie użytkowanych przyrządów rejestrujących powinien wynosić 15 lat, licząc od dnia wystawienia certyfikatu cyfrowego przyrządu rejestrującego. Przyrządy rejestrujące powinny być wymieniane po upływie tego okresu ważności. (5) Zapewnienie bezpiecznych i wiarygodnych informacji o położeniu jest niezbędnym elementem skutecznego działania tachografów inteligentnych.  Dlatego też należy zapewnić ich kompatybilność z usługami dodanymi oferowanymi przez program Galileo, określonymi w rozporządzeniu Parlamentu Europejskiego i Rady (UE) nr 1285/2013 (4), aby poprawić bezpieczeństwo tachografów inteligentnych. (6) Zgodnie z art. 8 ust. 1, art. 9 ust. 1 oraz art. 10 ust. 1 i 2 rozporządzenia (UE) nr 165/2014, stosowanie mechanizmów zabezpieczających wprowadzonych przez to rozporządzenie powinno rozpocząć się po 36 miesiącach od wejścia w życie niezbędnych aktów wykonawczych, aby umożliwić producentom opracowanie nowej generacji tachografów inteligentnych oraz uzyskanie świadectw homologacji typu od właściwych organów. (7) Zgodnie z rozporządzeniem (UE) nr 165/2014, pojazdy zarejestrowane po raz pierwszy w państwie członkowskim po upływie 36 miesięcy od wejścia w życie niniejszego rozporządzenia Komisji, powinny być wyposażone w tachograf inteligentny spełniający jego wymogi. W każdym przypadku wszystkie pojazdy użytkowane w państwie członkowskim innym niż ich państwo członkowskie rejestracji powinny zostać wyposażone w tachograf inteligentny spełniający wymogi w ciągu 15 lat od daty rozpoczęcia stosowania tych wymogów. (8) Rozporządzeniem Komisji (WE) nr 68/2009 (5) zezwolono na stosowanie – w okresie przejściowym upływającym dnia 31 grudnia 2013 r. – adaptera, aby umożliwić instalowanie tachografów w pojazdach kategorii M1 i N1. Biorąc pod uwagę trudności techniczne związane z poszukiwaniem rozwiązania alternatywnego dla stosowania adaptera, eksperci z sektora motoryzacji i tachografów wraz z Komisją stwierdzili, że żadne alternatywne rozwiązanie dla adaptera nie jest wykonalne bez poniesienia przez branżę wysokich kosztów, które byłyby nieproporcjonalne do rozmiaru rynku. W związku z tym należy bezterminowo dopuścić stosowanie adapterów w pojazdach kategorii M1 i N1. (9) Środki przewidziane w niniejszym rozporządzeniu są zgodne z opinią komitetu, o którym mowa w art. 42 ust. 3 rozporządzenia (UE) nr 165/2014, PRZYJMUJE NINIEJSZE ROZPORZĄDZENIE: Artykuł 1 Przedmiot i zakres stosowania 1. Niniejsze rozporządzenie ustanawia przepisy niezbędne do jednolitego stosowania następujących aspektów dotyczących tachografów: a) zapisywanie położenia pojazdu w pewnych punktach podczas dziennego okresu pracy kierowcy; b) wczesne wykrywanie na odległość możliwych przypadków manipulowania tachografami inteligentnymi lub ich niewłaściwego użytkowania; c) interfejs do inteligentnych systemów transportowych; d) wymogi administracyjne i techniczne dotyczące procedur homologacji typu dla tachografów, w tym mechanizmy zabezpieczające. 2. Budowa, sprawdzanie, instalacja, kontrola, użytkowanie i naprawa tachografów inteligentnych i ich elementów składowych muszą być zgodne z wymogami technicznymi określonymi w załączniku 1C do niniejszego rozporządzenia. 3. 