Anexos I a IV
ANEXOS
do Regulamento de Execução (UE) …/… da Comissão
que estabelece disposições pormenorizadas que garantem condições uniformes na implementação da interoperabilidade e na compatibilidade do equipamento de pesagem a bordo, nos termos da Diretiva 96/53/CE do Conselho
ANEXO I
Disposições gerais para o equipamento de pesagem a bordo («OBW»)
1.
Disposições gerais
1,1.
Estão incluídos no âmbito de aplicação do presente regulamento os seguintes tipos de sistemas de OBW:
a)
Sistema dinâmico: sistema de OBW que determina o peso mediante a recolha e o tratamento de informações relativas aos parâmetros captados com o veículo em movimento, tais como acelerações, forças de tração ou de travagem, e que não ocorrem com o veículo parado;
b)
Sistema estático: sistema de OBW que determina o peso mediante informações obtidas a partir de parâmetros que são captados com o veículo parado, tais como a pressão numa mola pneumática.
1.2.
O presente regulamento é aplicado em duas fases:
a)
O OBW de fase 1 a que se refere o ponto 5.2;
b)
O OBW de fase 2 a que se refere o ponto 5.3;
1.3.
O OBW deve calcular o peso total e, opcionalmente, o peso por eixo.
1.4.
O OBW deve compreender os seguintes elementos:
a)
Uma unidade-veículo («MVU»), colocada no veículo a motor;
b)
Opcionalmente, uma TU no reboque ou no semirreboque;
c)
Sensores;
d)
Para a fase 2, uma estação STI-C em cada veículo que disponha de uma MVU ou de uma TU.
1.5.
A MVU e a unidade-reboque podem consistir cada uma numa única unidade de processamento ou estar divididas em unidades diferentes.
2.
Unidade-veículo («MVU»)
A MVU deve:
a)Recebe a carga por eixo enviada pela TU, se esta existir;
b)Recolhe os dados relativos ao peso provenientes dos sensores do veículo a motor;
c)
Trata a informação disponível e calcula os valores do peso correspondentes.
3.
Unidade-reboque («TU»)
Quando estiver presente, a TU:
a)
Recolhe os dados relativos ao peso provenientes dos sensores do reboque ou do semirreboque, trata a informação disponível e calcula os pesos por eixo resultantes desses dados;
b)
Transfere os valores do peso por eixo para o veículo a motor.
4.
Cálculo do peso
4.1.
Nos sistemas dinâmicos, deve ser calculado um primeiro valor do peso o mais tardar 15 minutos após o veículo começar a avançar, devendo o peso ser em seguida recalculado pelo menos de 10 em 10 minutos.
4.2.
Nos sistemas estáticos, os valores do peso devem ser calculados a cada minuto quando a ignição estiver ligada e o veículo estiver parado.
4.3.
O peso deve ser calculado com uma precisão à centena de quilos ou superior.
5.
Troca de informação entre o veículo a motor e os reboques ou semirreboques de um conjunto de veículos
5.1.
Cada reboque ou semirreboque deve disponibilizar ao veículo a motor os valores do peso calculados de acordo com os pontos 5.2 ou 5.3, conforme aplicável.
5.2.
OBW de fase 1
5.2.1.
Deve ser atribuída a cada reboque ou semirreboque uma posição no conjunto de veículos no quadro de uma atribuição do endereço dinâmica, tal como estabelecido na norma ISO 11992-2:2014.
5.2.2.
Uma vez terminada a fase de atribuição do endereço, a TU de cada reboque ou semirreboque deve transferir para a MVU a soma das cargas por eixo ou a carga por eixo, em conformidade com a descrição constante dos pontos 6.5.4.7 e 6.5.5.42 da norma ISO 11992-2:2014.
5.2.3.
As mensagens relativas à soma das cargas por eixo ou à carga por eixo devem seguir as especificações estabelecidas na norma ISO 11992-2:2014 para os tipos de mensagens EBS22 e RGE22.
5.2.4.
O formato, o encaminhamento e as gamas de parâmetros gerais das mensagens devem ser conformes com os pontos 6.1, 6.3 e 6.4 da norma ISO 11992-2:2014.
5.3.
OBW de fase 2
A troca de informação entre o veículo a motor e os reboques ou semirreboques rebocados deve efetuar-se através das estações STI-C, como estabelecido no anexo II.
5.4.
Podem utilizar-se especificações diferentes tanto para os OBW de fase 1 como para os de fase 2, desde que o equipamento OBW do veículo a motor e dos reboques ou semirreboques seja compatível com essas especificações.
6.
Preparação dos dados e sua transferência para a DSRC-VU
A MVU, na fase 1, ou a estação STI-C do veículo a motor, na fase 2, transmitem ao módulo DSRC-VU os dados do sistema de pesagem a bordo («OWS») em conformidade com o anexo III.
Figura 1.
Exemplo de configuração do OBW num conjunto de veículos camião/semirreboque de fase 1
Sensores do veículo a motor
Troca de informação entre a MVU e a TU de acordo com a norma ISO 11992-2:2014
Figura 2.
Exemplo de configuração do OBW num conjunto de veículos camião/semirreboque de fase 2
7.
Informação sobre o peso transmitida ao condutor
O condutor deve receber num visor informação relativa pelo menos ao peso total.
8.
Exatidão
8.1.
A exatidão do peso calculado deve ser de ± 5 %, no mínimo, quando o veículo estiver carregado a mais de 90 % do seu peso máximo autorizado.
8.2.
Não obstante o disposto no ponto 8.1, para o OBW de fase 1 a exatidão pode ser de ±10%, no mínimo.
ANEXO II
DISPOSIÇÕES ESPECÍFICAS PARA O OBW DE FASE 2
1.
O presente anexo aplica-se exclusivamente ao OBW de fase 2.
2.
O veículo a motor e os reboques ou semirreboques do conjunto de veículos que possuam uma unidade-reboque («TU») devem estar equipados com uma estação STI-C ligada à unidade do veículo a motor («MVU») ou à TU do veículo correspondente. A MVU e a TU podem estar integradas nas respetivas estações STI-C.
3.
A MVU e a TU transmitem às estações STI-C a que estão ligadas a informação necessária para a transmissão das mensagens em conformidade com o ponto 4.3 do presente anexo.
Figura 3. Exemplo de fluxo de mensagens num OBW de fase 2
Peso por eixo do reboque ou do semirreboque, violação da segurança, erro de comunicação
Peso por eixo do veículo, peso total, violação da segurança...
4.
Troca de informação entre o veículo a motor e o reboque ou semirreboque
4.1
A troca de informação sobre o peso entre o veículo a motor e os reboques ou semirreboques deve efetuar-se através de uma ligação sem fios estabelecida entre as estações STI-C do veículo a motor e as dos reboques ou semirreboques, em conformidade com as normas EN 302 663-V1.1.1, com exceção do ponto 4.2.1, EN 302 636-4-1-V1.3.1, EN 302 636-5.1-V2.1.1 e a norma europeia sobre a aplicação OBW para as estações STI-C que será desenvolvida pelo ETSI.
4.2.
As mensagens trocadas pelas estações STI-C devem ser protegidas tal como previsto no ponto 5.1.
4.3.
Devem ser transmitidas as seguintes informações entre as estações STI-C:
-
a) Peso por eixo dos reboques ou semirreboques rebocados;
-
b) Mensagens contendo incidentes de «erro de comunicação OBW»: é desencadeado um incidente de erro de comunicação OBW quando as estações STI-C não conseguirem estabelecer uma comunicação recíproca segura em conformidade com o ponto 5.1 em mais de três tentativas;
-c) Mensagens contendo um incidente de «tentativa de violação da segurança»: é desencadeado um incidente de tentativa de violação da segurança sempre que o OBW detetar uma tentativa de manipulação do OBW como indicado no ponto 5.2 e no apêndice.
4.4.
O formato das mensagens necessárias para a fase de atribuição do endereço e para a transmissão das informações referidas no ponto 4.3 deve ser estabelecido na norma sobre a aplicação OBW referida no ponto 4.1.
5.
Disposições de segurança
5.1.
Comunicação segura entre as estações STI-C
5.1.1.
A comunicação entre as estações STI-C deve ser protegida em conformidade com a norma europeia ETSI TS 103 097-V1.3.1 e com a norma europeia sobre a aplicação OBW para STI-C referida no ponto 4.1.
5.1.2.
Em conformidade com a política de certificação para a implantação e o funcionamento de sistemas cooperativos de transporte inteligentes europeus, adotada pela Comissão, as estações STI-C devem obter:
a)
Uma credencial de inscrição emitida por uma autoridade de registo, que as autorize a funcionar como estações STI-C para efeitos de pesagem a bordo.
b)
Vários certificados de autorização emitidos por uma autoridade de autorização, que lhes permitam funcionar no ambiente STI-C como parte integrante do OBW.
5.2.
Proteção contra tentativas de violação da segurança
A proteção do OBW de fase 2 contra tentativas de violação da segurança deve ser assegurada em conformidade com o apêndice do presente anexo.
APÊNDICE DO ANEXO II:
Certificação de segurança para o OBW de fase 2
1.
A MVU e a TU devem ter certificação de segurança de acordo com o sistema de critérios comuns. No presente apêndice, a MVU e a TU passam a ser referidas como «OBW-VU».
2.
Os requisitos mínimos de segurança a cumprir pela OBW-VU devem ser definidos num objetivo de segurança («ST») de acordo com o sistema de critérios comuns.
3.
Os ST devem ser redigidos pelo fabricante do equipamento a certificar e aprovados por um organismo governamental de certificação de segurança de TI organizado no âmbito do Grupo de Trabalho Conjunto de Interpretação (JIWG) que apoia o reconhecimento mútuo de certificados sob a égide do SOGIS-MRA europeu (Acordo de Reconhecimento Mútuo de Certificados de Avaliação da Segurança da Tecnologia da Informação).
4.
A porta de ligação V2X e o módulo de segurança de hardware das estações STI-C devem ter certificação de segurança em conformidade com os perfis de proteção da porta de ligação V2X e do módulo de segurança de hardware desenvolvidos pelo Consórcio para a Comunicação Car2Car.
5.
A certificação de segurança da OBW-VU deve ter o nível de garantia EAL2. Contudo, se o tacógrafo for utilizado como MVU, deve ser certificado de acordo com um nível de garantia EAL4 aumentado pelos componentes de garantia ATE_DPT.2 e AVA_VAN.5, tal como estabelecido no apêndice 10 do anexo IC do Regulamento (UE) 2016/799.
6.
Elementos que devem ser protegidos pelo ST
Devem ser protegidos os seguintes elementos:
a)
Mensagem da OBW-VU: qualquer mensagem que seja enviada ou recebida por um módulo pertinente da OBW-VU contendo informações necessárias para o cálculo do peso.
Os módulos do OBW pertinentes são as unidades de hardware e software da OBW-VU que tratam informações que, se forem alvo de ataques, podem resultar num cálculo errado do peso total ou do peso por eixo pelo OBW.
Uma OBW-VU pode consistir num único módulo pertinente ou ser constituída por vários módulos pertinentes, em conformidade com o ponto 1.5 do anexo I, caso em que o ST deve identificá-los.
b)
Mensagem sobre o peso: mensagem que contém o peso total ou o peso por eixo calculado pela OBW-VU.
c)
Dados de calibração: informação que é introduzida na memória da OBW-VU a fim de calibrar o OBW.
d)
Informação de auditoria: informações sobre as tentativas de violação da segurança correspondentes às ameaças elencadas no presente apêndice.
e)
Software da OBW-VU: software utilizado na OBW-VU para executar e apoiar as funções do OBW que é pertinente para o cálculo do peso e a deteção de tentativas de violação da segurança.
Figura 4. Exemplo de mensagens da OBW-VU e mensagens sobre o peso que devem ser protegidas numa MVU composta por dois módulos pertinentes
7.
Ameaças a prever no ST
O ST deve prever as seguintes ameaças:
a)
T.OBW-VU_message_spoof: um intruso poderia falsificar as mensagens do OBW-VU de modo que o OBW-VU calcule incorretamente o peso total ou o peso por eixo.
b)
T.OBW-VU_message_tamper: um intruso poderia adulterar as mensagens do OBW-VU de modo que o OBW-VU calcule incorretamente o peso total ou o peso por eixo.
c)
T.Weight_message_spoof: um intruso poderia falsificar as mensagens sobre o peso a fim de alterar o peso calculado pelo OBW-VU.
d)
T.Weight_message_tamper: um intruso poderia adulterar as mensagens sobre o peso a fim de alterar o peso calculado pelo OBW-VU.
e)
T.Audit_spoof: um intruso poderia falsificar as mensagens com informação de auditoria.
f)
T.Audit_tamper: um intruso poderia adulterar as mensagens com informação de auditoria.
g)
T.Calibration_tamper: um intruso poderia inserir valores errados como dados de calibração, a fim de induzir o OBW-VU a calcular incorretamente o peso.
h)
T.Software_tamper: um intruso poderia modificar ou substituir o software do OBW-VU para alterar o cálculo normal do peso.
i)
T.Stored_Data_tamper: um intruso poderia tentar modificar ou apagar a informação relevante armazenada no OBW-VU, incluindo informação de auditoria.
8.
Os objetivos de segurança do OBW-VU são os seguintes:
a) O.Plausibility_validation: o OBW-VU deve verificar se a informação de uma mensagem recebida num módulo pertinente, proveniente dos sensores ou de outro módulo, é fiável com base na sua plausibilidade.
b)
O.OBW-VU_stored_information_protection: o OBW-VU deve poder proteger o software e os dados armazenados contra a adulteração.
c)
O.Notification: o OBW-VU deve poder notificar uma tentativa de violação da segurança.
9.
Relação lógica
a)
T.OBW-VU_message_spoof é tratada por O.Plausibility_validation e por O.Notification.
b)
T.OBW-VU_message_tamper é tratada por O.Plausibility_validation e por O.Notification.
c)
T.Weight_message_spoof é tratada por O.Plausibility_validation e por O.Notification.
d)
T.Weight_message_tamper é tratada por O.Plausibility_validation e por O.Notification.
e)
T.Audit_spoof é tratada por O.Plausibility_validation e por O.Notification.
f)
T.Calibration_tamper é tratada por O.Plausibility_validation e por O.Notification.
g)
T.Software_tamper é tratada por O.OBW-VU_stored_information_protection e por O.Notification.
h)
T.Stored_data_tamper é tratada por O.OBW-VU_stored_information_protection e por O.Notification.
Quadro 1 — Relação lógica dos objetivos de segurança
|
|
O.Plausibility_validation
|
O.OBW-VU_stored_information_protection
|
O.Notification
|
|
T.OBW_message_spoof
|
X
|
|
X
|
|
T.OBW_message_tamper
|
X
|
|
X
|
|
T.Weight_message_spoof
|
X
|
|
X
|
|
T.Weight_message_tamper
|
X
|
|
X
|
|
T.Audit_spoof
|
X
|
|
X
|
|
T.Audit_tamper
|
X
|
|
X
|
|
T.Calibration_tamper
|
X
|
|
X
|
|
T.Software_tamper
|
|
X
|
X
|
|
T.Stored_data_tamper
|
|
X
|
X
|
ANEXO III
Preparação dos dados e transferência da informação para o REDCR
1.
O presente anexo, que complementa o apêndice 14 do anexo IC do Regulamento (UE) 2016/799 (seguidamente «apêndice 14»), especifica os requisitos para a preparação e transferência de dados OWS do veículo a motor para o leitor de comunicações de deteção rápida à distância («REDCR»).
2.
Transferência de dados do sistema de pesagem a bordo («OWS») para o OBW de fase 1
2.1.
Os dados OWS devem ser fornecidos pela unidade-veículo («MVU») à unidade-veículo de Comunicações Dedicadas de Curto Alcance («DSRC-VU»).
2.2.
A MVU deve:
2.2.1.
Estruturar os dados OWS com as informações recebidas da MVU e da unidade-reboque («TU»), de acordo com a estrutura indicada no ponto 6;
2.2.2.
Transferir os dados OWS para a DSRC-VU, para transmissão ao REDCR.
Figura 5. Transmissão de dados OWS da MVU para o REDCR no OBW de fase 1
3.
Transferência de dados OWS para o OBW de fase 2
3.1.
Os dados OWS devem ser fornecidos à DSRC-VU pela estação STI-C do veículo a motor.
Figura 6. Transmissão de dados OWS da estação STI-C para o REDCR no OBW de fase 2
Estação de STI-C
no veículo a motor
3.2.
A estação STI-C do veículo a motor deve:
3.2.1.
Estruturar os dados OWS com as informações recebidas da MVU e das estações STI-C dos reboques ou semirreboques, de acordo com a estrutura indicada no ponto 6;
3.2.2.
Proteger os dados OWS como estabelecido no ponto 8, e
3.2.3.
Transferir os dados OWS para a DSRC-VU, para transmissão ao REDCR.
4.
A transferência de dados entre a DSRC-VU e a MVU (fase 1) ou a estação STI-C do veículo a motor (fase 2) deve ser efetuada conforme estabelecido no ponto 5.6 do apêndice 14, entendendo-se por VU quer a MVU, quer a estação STI-C, consoante a fase.
5.
Comunicação entre a DSRC-VU e o REDCR
5.1.
A comunicação entre a DSRC-VU e o REDCR deve ser efetuada através da interface definida pelas normas CEN DSRC EN 12253, EN 12795, EN 12834, EN 13372 e ISO 14906, conforme referido na Diretiva 96/53/CE do Conselho.
5.2.
O protocolo de transação para descarregamento de dados OWS através da ligação da interface DSRC de 5,8 GHz deve ser o mesmo utilizado para os dados RTM no ponto 5.4.1 do apêndice 14. A única diferença é que o identificador de objeto relativo à norma TARV se refere à norma ISO 15638 (TARV), parte 20, relativa a WOB/OWS.
5.3.
Os comandos utilizados para uma transação OWS devem ser os mesmos que figuram no ponto 5.4.2 do apêndice 14 para uma transação RTM.
5.4.
A sequência de comandos de interrogação para os dados OWS deve ser a mesma que figura no ponto 5.4.3 do apêndice 14 para os dados RTM.
5.5.
O mecanismo de transferência de dados e a descrição de transação DSRC devem ser os mesmos que figuram nos pontos 5.4.6 e 5.4.7 do apêndice 14. O quadro de serviço do veículo deve, no entanto, ser adaptado para a transmissão de dados OWS. Por conseguinte, a marca Rtm-ContextMark deve ser substituída por uma marca Ows-ContextMark, cujo identificador de objeto se refere à norma ISO 15638 (TARV), parte 20, relativa a WOB/OWS.
5.6.
Os parâmetros da interface física DSRC são os mesmos que figuram no ponto 5.3 do apêndice 14.
6.
Estrutura dos dados
O módulo ASN.1 para os dados DSRC na aplicação OWS é definido do seguinte modo:
TarvOws {iso(1) standard(0) 15638 part20(20) version1(1)} DEFINITIONS AUTOMATIC TAGS
::= BEGIN
IMPORTS
— atributos e elementos de dados das importações provenientes do CEF que são utilizados para as OWS
LPN
From EfcenApplication {ISO (1) Norma (0) 14906 aplicação (0) version5 (5)}
Parâmetros de função das importações provenientes da definição da interface de aplicação do EFC
SetRMIRq
From EfcenApplication {ISO (1) Norma (0) 14906 aplicação (0) version5 (5)}
Parâmetros de função das importações provenientes da definição da interface de aplicação do EFC
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)};
-- Definições das funções OWS:
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})
-- Definições dos atributos OWS:
OwsData :: = SEQUENCE {
OWSPayload SignedDataPayload, -- SignedData in accordance with ETSI 103097 v1.3.1, only for Stage 2 OBW
}
OwsPayload :: = SEQUENCE {
recordedWeight
INTEGER (0..65535),
-- 0= Total peso medido do veículo pesado de mercadorias com uma resolução de 10 Kg.
maximumTechnicalWeight
INTEGER (0..65535),
-- 0= technically permissible representa a massa máxima em carga tecnicamente admissível do veículo ou conjunto de veículos, conforme declarada pelo fabricante, com 10 Kg resolução, só para a fase 2.
axlesConfiguration OCTET STRING SIZE (4),
-- 0= 20 bits allowed for the number of axles for 10 axles.
axlesRecordedWeight OCTET STRING SIZE (26),
-- 0= Peso Registado para cada eixo com uma resolução de 10 Kg. .
tp15638Timestamp
INTEGER(0..4294967295)
-- Timestamp of current record
tp15638DSRCcommunicationError
BOOLEAN,
-- Registo de um erro de comunicação entre o MVU e o DSRC nos últimos 10 dias
tp15638OBWCommunicationError
BOOLEAN,
-- Registo de um erro de comunicação
tp15638SecurityBreachAttempt
BOOLEAN,
-- Registo de tentativa de violação da segurança
}
Ows-ContextMark ::= SEQUENCE {
standardIdentifier StandardIdentifier, -- identificador da parte da TARV e da sua versão
}
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,
-- valores entre 16 e 255 reservados a utilização ISO/CEN
}}
FIM
7.
Elementos dos dados OWS, ações realizadas e definições:
Os dados OWS são calculados pela MVU (fase 1) ou pela estação STI-C do veículo a motor (fase 2) de acordo com o quadro 1.
Quadro 1: Elementos dos dados OWS, ações realizadas e definições:
|
Elemento de dados OWS
|
Ação efetuada pela estação STI-C do veículo a motor:
|
Observação
|
Definição de dados ASN.1
|
|
OWS1
Peso total
|
É gerado um valor inteiro.
|
Último peso total medido
|
recordedWeight
INTEGER (0..65535),
|
|
OWS2
Massa máxima em carga tecnicamente admissível
|
É gerado um valor inteiro.
|
Massa máxima em carga tecnicamente admissível, declarada pelo fabricante
|
maximumTechnicalWeight
INTEGER(0..65535)
|
|
OWS3
Configuração dos eixos do veículo
|
É gerada uma cadeia de 4 octetos.
|
Configuração dos eixos
|
Configuração dos eixos
OCTET STRING SIZE (4),
|
|
OWS4
Peso por eixo
|
É gerada uma cadeia de 26 octetos.
|
Peso por eixo
|
axlesRecordedWeight
OCTET STRING SIZE (26),
|
|
OWS5
Peso total com registo de tempo
|
É gerado um valor inteiro.
O valor do OWS2 é fixado em relação à hora do registo atual do peso total.
|
Selo temporal do peso registado atual
|
tp15638Timestamp
INTEGER (0..4294967295),
|
|
OWS6
Erro de comunicação DSRC
|
É gerado um valor booleano.
É atribuído um valor TRUE à variável tp15638DSRCcommunicationError se o OBW tiver registado pelo menos um incidente do tipo Erro de Comunicação com a DSRC-VU nos últimos 30 dias.
DE CONTRÁRIO, se não tiverem ocorrido incidentes nos últimos 30 dias, é atribuído um valor FALSE.
|
1 (TRUE), indica um erro de comunicação entre o OBW e a DSRC-VU nos últimos 30 dias
|
tp15638DSRCcommunicationError,
BOOLEAN,
|
|
OWS7
Erro de comunicação OBW
|
É gerado um valor booleano.
É atribuído um valor TRUE à variável tp15638CommunicationError se o OBW tiver registado pelo menos um incidente de erro de comunicação dentro do OBW nos últimos 30 dias.
DE CONTRÁRIO, se não tiverem ocorrido incidentes nos últimos 30 dias, é atribuído um valor FALSE.
|
1 (TRUE), indica um erro de comunicação dentro do OBW nos últimos 30 dias
|
tp15638OBWCommunicationError,
BOOLEAN,
|
|
OWS8
Tentativa de violação da segurança
|
É gerado um valor booleano.
É atribuído um valor TRUE à variável tp15638SecurityBreachAttempt se o OBW tiver registado pelo menos um incidente de tentativa de violação da segurança nos últimos 2 anos.
DE CONTRÁRIO, se não tiverem ocorrido incidentes de tentativa de violação da segurança nos últimos 2 anos, é atribuído um valor FALSE.
|
1 (TRUE), indica uma tentativa de violação da segurança do OBW nos últimos 2 anos
|
tp15638SecurityBreachAttempt
BOOLEAN,
|
sendo que
a)
recordedWeight representa o peso medido total do veículo ou conjunto de veículos com uma precisão à dezena de quilos, conforme definido na norma EN ISO 14906. Por exemplo, um valor de 2 500 representa um peso de 25 toneladas.
b)
axlesConfiguration representa a configuração do veículo ou conjunto de veículos como número de eixos.
A configuração é definida com a máscara de 20 bits (aumentada a partir da norma EN ISO 14906).
Uma máscara de 2 bits representa a configuração de um eixo com o seguinte formato:
-
O valor 00B significa que o valor está «indisponível», porque o veículo não tem equipamento para tomar o peso no eixo.
-
O valor 01B significa que o eixo não está presente.
-
O valor 10B significa que o eixo está presente e que o peso foi calculado e recolhido e é fornecido no campo axlesRecordedWeight.
-
O valor 11B é reservado para utilizações futuras.
Os seis últimos bits são reservados para utilizações futuras.
Quadro 2: Distribuição de bits para o OWS2
|
Número de eixos
|
|
|
Número de eixos do trator
|
Número de eixos do reboque
|
|
|
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
|
00/01/10/11
|
00/01/10/11
|
00/01/10/11
|
RUF
(6 bits)
|
c)
axlesRecordedWeight representa o peso específico registado para cada eixo com uma precisão à dezena de quilos. Utilizam-se dois octetos para cada eixo. Por exemplo, um valor de 150 representa um peso de 1 500 kg.
d)
maximumTechnicalWeight representa a massa máxima em carga tecnicamente admissível do veículo ou conjunto de veículos, conforme declarada pelo fabricante. Este valor só deve ser fornecido para a fase 2. Para a fase 1, é atribuído um valor de 0.
8.
Assinatura dos dados OWS
8.1.
Na fase 1, os dados OWS não são assinados; os dados OWS em texto simples são transferidos da MVU para a DSRC-VU.
8.2.
Na fase 2, os dados OWS devem ser assinados na estação STI-C do veículo a motor e transferidos dessa estação para a DSRC-VU, em conformidade com as seguintes disposições:
8.2.1.
A estrutura dos dados protegidos é estabelecida em conformidade com os pontos 5.1 e 5.2 da norma ETSI TS 103 097-V1.3.1.
8.2.2.
O tipo SignedData referido no ponto 5.2 da ETSI TS 103 097-V1.3.1 deve cumprir os seguintes requisitos:
a)
O tipo HashAlgorithm deve ser definido como sha256.
-
b)
O tipo SignerIdentifier deve ser definido como «digest».
c)
O tipo SignedDataPayload corresponde aos dados OWS conforme definidos no ponto 7.
d)
O tipo HeaderInfo está limitado aos seguintes cabeçalhos de segurança:
-
O componente psid deve ser igual a 0.
-
O componente generationTime tal como definido na norma IEEE Std 1609.2.
-
O componente expiryTime deve estar ausente.
-
O componente generationLocation deve estar ausente.
-
O componente p2pcdLearningRequest deve estar ausente.
-
O componente missingCrlIdentifier deve estar ausente.
-
O componente encryptionKey deve estar ausente.
-
O componente inlineP2pcdRequest deve estar ausente.
-
O componente requestedCertificate deve estar ausente.
8.2.3.
O módulo ASN.1 para o tipo Signature é definido do seguinte modo:
Signature ::= CHOICE {
ecdsaNistP256Signature EcdsaP256Signature,
ecdsaBrainpoolP256r1Signature EcdsaP256Signature,
...,
ecdsaBrainpoolP384r1Signature EcdsaP384Signature
}
EcdsaP256Signature ::= SEQUENCE {
rSig EccP256CurvePoint,
sSig OCTET STRING (SIZE (32))
}
EccP256CurvePoint ::= CHOICE {
x-only OCTET STRING (SIZE (32)),
fill NULL, -- consistency with 1363 / X9.62
compressed-y-0 OCTET STRING (SIZE (32)),
compressed-y-1 OCTET STRING (SIZE (32)),
uncompressedP256 SEQUENCE {
x OCTET STRING (SIZE (32)),
y OCTET STRING (SIZE (32))
}
}
8.2.4.
O certificado de assinatura é o certificado que figura no certificado de autorização que a estação STI-C utiliza para a transação entre a estação STI-C e o REDCR, em conformidade com o ponto 6 da norma ETSI TS 103 097-V1.3.1.
8.2.5.
Ao receber a mensagem, o REDCR verifica o certificado e utiliza a chave pública incluída nesse certificado para ler a assinatura dos dados OWS.
9.
O protocolo de aplicação e o tratamento de erros para os dados OWS são os mesmos que figuram nos pontos 5.6.2 e 5.7 do apêndice 14.
10.
Na fase 2, os dados OWS podem também ser transmitidos diretamente ao REDCR da autoridade responsável pela aplicação através da estação STI-C do veículo a motor, em vez de através da DSRC-VU. Nesse caso, o REDCR deve ser também uma estação STI-C.
ANEXO IV
INSPEÇÕES PERIÓDICAS
1.
O equipamento de pesagem a bordo («OBW») deve ser submetido a inspeções periódicas mediante a pesagem do veículo ou do conjunto de veículos em dispositivos de pesagem certificados em conformidade com o artigo 5.º, n.º 2, alínea b), do presente regulamento, tais como plataformas pesa-eixos portáteis ou uma báscula de pesagem.
2.
Devem ser submetidos a inspeção os seguintes veículos:
a)
Veículos a motor;
b)
Reboques e semirreboques que disponham de uma unidade-reboque («TU»)
3.
Os reboques e semirreboques sujeitos a inspeção nos termos do ponto 2 devem estar fixados a um veículo a motor quando da inspeção. Os veículos a motor destinados a rebocar semirreboques devem estar fixados a um semirreboque quando da inspeção.
4.
A inspeção periódica deve consistir no seguinte:
a)
Um ensaio com três cargas, que deve ser efetuado dois anos após a matrícula do veículo e posteriormente de quatro em quatro anos;
b)
Um ensaio com uma carga única, que deve ser efetuado dois anos após o ensaio com três cargas e posteriormente de quatro em quatro anos.
Quadro 3: Sequência da realização das inspeções periódicas
|
Ensaio
|
Três cargas
|
Carga única
|
Três cargas
|
Carga única
|
Três cargas
|
Carga única
|
Três cargas
|
...
|
|
Número de anos após a data de matrícula do veículo
|
2
|
4
|
6
|
8
|
10
|
12
|
14
|
...
|
5.
Ensaio com três cargas
Um ensaio com três cargas é efetuado carregando o veículo com três cargas diferentes, cujos valores devem ser calculados do seguinte modo:
a)
Uma carga compreendida entre 45 % e 55 % da massa máxima em carga tecnicamente admissível do veículo;
b)
Uma carga compreendida entre 65 % e 75 % da massa máxima em carga tecnicamente admissível do veículo;
c)
Uma carga compreendida entre 90 % e 100 % da massa máxima em carga tecnicamente admissível do veículo;
6.
O ensaio de carga única é efetuado carregando o veículo com uma carga correspondente a pelo menos 90 % da massa máxima em carga tecnicamente admissível do veículo.
7.
No que diz respeito aos reboques e semirreboques que disponham de uma TU e aos veículos a motor destinados a rebocar um semirreboque, as cargas indicadas nos pontos 5 e 6 devem ser calculadas em relação à massa máxima em carga tecnicamente admissível do conjunto de veículos.
8.
Disposições específicas para os OBW dinâmicos
8.1.
Se a massa máxima em carga tecnicamente admissível do veículo ou do conjunto de veículos exceder o peso máximo autorizado, as cargas indicadas nos pontos 5 e 6 devem ser calculadas em relação ao peso máximo autorizado.
8.2
A fim de obter do OBW um valor de carga, o veículo ou conjunto de veículos deve ser conduzido ao longo de uma determinada distância em condições específicas, a definir nas diretrizes do fabricante.
9.
Considera-se que o veículo não passou a inspeção quando:
a)
O valor da carga visualizado no OBW correspondente à carga entre 90 % e 100 % da massa máxima em carga tecnicamente admissível do veículo referida no ponto 5, alínea c), não está em conformidade com os valores medidos pelo dispositivo de pesagem certificado, com o nível de exatidão estabelecido no ponto 8 do anexo I, e
b)
Os valores das cargas visualizados no OBW correspondentes às cargas entre 45% e 55% e entre 65% e 75% da massa máxima em carga tecnicamente admissível do veículo referidas no ponto 5, alíneas a) e b), não estão em conformidade com os valores medidos pelo dispositivo de pesagem certificado, com um nível de exatidão de ±15%.
10.
Se o veículo não passar a inspeção, o OBW deve ser submetido a nova inspeção no prazo máximo de dois meses após a inspeção precedente.
11.
Flexibilidade das inspeções periódicas:
A fim de facilitar a realização das inspeções periódicas de tipos específicos de veículos, e a fim de reduzir o impacto das inspeções periódicas nas atividades habituais dos condutores e dos transportadores, os Estados-Membros podem ponderar a aplicação das seguintes possibilidades de flexibilidade aos veículos matriculados no seu território:
a)
Os valores das três cargas referidos no ponto 5 podem ser obtidos ao longo de um período de três meses;
b)
A pesagem efetiva do veículo pode ser efetuada em dispositivos de pesagem certificados não pertencentes às instalações das oficinas de OBW referidas no artigo 5.º do presente regulamento, desde que a operação de pesagem seja supervisionada por um funcionário de uma oficina de OBW. O proprietário do veículo deve fornecer à oficina de OBW a prova de que a pesagem foi efetuada com um dispositivo de pesagem certificado;
c)
No que diz respeito aos veículos ou conjuntos de veículos cuja configuração específica torna tecnicamente impossível exceder o peso máximo autorizado em condições normais de utilização (p. ex. os camiões-cisterna), as cargas referidas nos pontos 5 e 6 podem ter outros valores; no caso do ensaio com três cargas, a diferença entre duas cargas consecutivas deve corresponder pelo menos a 15 % do peso máximo autorizado.