Manual de Orientação do Contribuinte Brasil-ID Identificador de Veículo e Carga Eletrônico - IVC-e

Versão Preliminar

Versão 1.0

Data de publicação: 22/10/2013

Sistema Nacional de Identificação, Rastreamento e Autenticação de Mercadorias

1 Introdução

2 Considerações Iniciais

2.1 Identificador de veículos de carga eletrônico

2.1.1 Descrição Simplificada do Modelo Operacional

3 Arquitetura de comunicação

3.1 Modelo Conceitual

3.2 Padrões Técnicos

3.2.1 Padrão de Comunicação

3.2.2 Padrão de Certificado Digital

3.2.3 Padrão de assinatura digital com chave assimétrica

3.2.4 Validação de Assinatura Digital pelo BackOffice Fiscal

3.2.5 Resumo dos padrões técnicos

3.3 Modelo Operacional

3.3.1 Serviços Síncronos

3.3.2 Serviços Assíncronos

3.4 Padrão de mensagens dos web services

3.4.1 Cabeçalho da mensagem

3.4.2 Corpo da Mensagem

3.4.3 Validação da estrutura XML das mensagens dos web services

3.4.4 Schemas XML das mensagens dos web services

3.5 Web Services

3.5.1 Mídia (tag sem ser inicializada)

3.5.2 IVC-e (tag inicializada)

3.5.3 Tipos definidos

3.6 Serviços disponibilizados por Mensagens

3.6.1 Mensagem de Leitura

4 Anexos

4.1 Leiaute do IVC-e

4.2 Schema Relacionado aos métodos da tag

4.3 Schema Relacionado aos métodos do IVC-e

 - Tabelas

TABELA DE CONTROLE E VERSIONAMENTO

Este documento está sendo publicado em caráter preliminar, de forma a permitir que as entidades conveniadas ao programa Brasil-ID possam ter acesso à informações que são necessárias para o desenvolvimento de tecnologia voltadas a este projeto ou então para integração de pilotos utilizando os padrões e tecnologias que pertencem ao escopo do Brasil-ID.

As informações listadas neste documento estão sujeitas as alterações, de acordo com a evolução do projeto como um todo. Toda e qualquer decisão tomada com base nestas informações preliminares são de única e exclusiva responsabilidade da entidade que a tomou, de forma que os órgãos responsáveis pelo Brasil-ID não tem nenhuma responsabilidade sobre os riscos e eventuais prejuízos que possam ser causados por eventuais alterações deste documento.

LISTA DE SIGLAS E ABREVIATURAS

CCD     Comitê Certificador Designado

CSS     Console de Solicitação de Serviço

CT-e     Conhecimento de Transporte Eletrônico

ETL     Extraction, Transformation and Load

EP     Envelope Protetor

HTTP     HyperText Transfer Protocol Secure

IVC-e     Identificador de Veículo de Carga Eletrônico

OBUID     On Board Unit Identificator, refere-se ao código identificador único de um determinado transponder

RFID     Radio-Frequency IDentification

SHA     Secure Hash Algorithm

SLD     Sistema de Leitura de Dispositivo

SOAP     Simple Object Access Protocol

URL     Uniform Resource Locator

WSDL     Web Services Description Language

XML     EXtensible Markup Language

1 INTRODUÇÃO

O presente documento tem por objetivo apresentar as especificações e critérios técnicos necessários para a utilização do BON-BrID por meio da tecnologia do Identificador de Veículos de Carga Eletrônico (“IVC-e”). O documento apresenta a finalidade desta tecnologia e sua arquitetura de comunicação para auxiliar na utilização por parte dos contribuintes na implementação de aplicativos que sigam as recomendações deste documento.

Tendo em vista a complexidade do sistema e abrangência do projeto, envolvendo diferentes fornecedores de equipamentos e sistemas, o projeto de arquitetura de comunicação visa oferecer interfaces padronizadas de envio e recebimento de dados de forma otimizada e segura. Entre essas interfaces estão os Web Services, que utilizam o XML como modelo de codificação de dados e os serviços de Mensageria que não dependem exclusivamente de um mecanismo síncrono para envio de dados, ou seja, um serviço em que os produtores das informações e os seus consumidores não precisam estar conectados ao mesmo tempo (online).

O documento está dividido em: (1) Introdução, (2) Considerações Iniciais, (3) Arquitetura de comunicação e (4) Anexos.

2 CONSIDERAÇÕES INICIAIS

O escopo do IVC-e no BON-BrID contempla a utilização em território nacional de um transponder RFID para identificação automática de veículos de carga em circulação, assim como, dos eventos associados ao veículo.

A utilização desta tecnologia permite ao contribuinte a visualização de eventos que compõem o fluxo logístico realizado. A visualização é possível com base em informações reais obtidas através do identificador por meio da tecnologia de radiofrequência e protocolos de comunicação que devem ser utilizados pelos participantes 1 .

2.1 IDENTIFICADOR DE VEÍCULOS DE CARGA ELETRÔNICO

O identificador de veículos de carga eletrônico (“IVC-e”) é um transponder RFID semi-ativo que identifica unicamente o veículo e contém informações de cadastro retiradas de seu documento com validade fiscal como o Certificado de Registro e Licenciamento de veículos.

O fluxo do IVC-e contempla operações relacionadas com a mídia de gravação até operações relacionadas com a utilização do identificador, ou seja, desde a gravação de um novo transponder, sua inicialização como IVC-e no sistema do Back Office, até a passagem do veículo com o IVC-e instalado em um equipamento de leitura RFID e a obtenção dos dados.

Para facilitar o entendimento, neste documento o IVC-e é tratado também como transponder ou tag que é a mídia antes da inicialização para tornar-se IVC-e.

2.1.1 DESCRIÇÃO SIMPLIFICADA DO MODELO OPERACIONAL

Neste documento serão apresentadas as interfaces de comunicação da mídia que origina o IVC-e, tratada como tag e do IVC-e já inicializado no sistema do Back Office.

O fluxo de operação inicia-se com a requisição por parte da fábrica de tags, através de um aplicativo cliente, de uma lista de novos identificadores para transponder fabricados, esta requisição exige a aprovação pelo Comitê Certificador Designado 2 , enquanto o resultado da aprovação não for disponibilizado o aplicativo cliente fará a consulta do estado da solicitação.

Após a aprovação da requisição, o estado da requisição é alterado e a fábrica pode recuperar a lista de identificadores de transponder solicitada. Em seguida, a fábrica deve registrar os envelopes protetores (EPs - mecanismo de segurança para evitar a clonagem de mídias, representado por um número aleatório gerado pelo fabricante da mídia), tornando a tag pronta para ser vendida a uma operadora.

O registro de uma venda é realizado pela fábrica por meio do envio da lista de identificadores de transponder à operadora associada, esta operação deve ser confirmada pela operadora, efetivando a compra de tags.

Após a compra, a operadora deve inicializar a tag e instalá-la no veículo, realizando o vínculo entre IVC-e e veículo. A partir deste momento, o IVC-e está ativo e pode ser utilizado no fluxo logístico do veículo para obtenção de eventos de passagem que permitam a visualização das informações.

3 ARQUITETURA DE COMUNICAÇÃO

Esta seção aborda as interfaces de comunicação do Back Office utilizadas no contexto do IVC-e.

3.1 MODELO CONCEITUAL

O BON-BrID proverá Web Services para utilização do IVC-e nas seguintes funcionalidades:

a) Mídia (tag sem ser inicializada)

1) Requisição de identificadores de transponders

2) Recuperação de identificadores de transponders

3) Confirmação de requisição de identificadores de transponders

4) Cancelamento de requisição de identificadores de transponders

5) Registro de envelope protetor

6) Registro de venda

7) Recuperação de Informações sobre a venda

8) Confirmação de venda

9) Cancelamento de venda

10) Recuperação do estado da venda

b) IVC-e (tag inicializada)

1) Inicialização de tag como IVC-e

2) Recuperação do estado da inicialização de tag como IVC-e

3) Vínculo entre IVC-e e veículo

4) Registro de passagem de IVC-e

5) Decodificação do bloco cifrado do IVC-e

6) Cancelamento de IVC-e

Os Web Services disponibilizam diversas funções para a troca de informações entre os equipamentos e sistemas clientes (equipamentos de obtenção de dados em campo e aplicativos clientes das operadoras e fábricas, por exemplo) e o BackOffice Fiscal. Nele também há mecanismos de segurança e integridade das mensagens.

O fluxo de comunicação é iniciado pelo aplicativo do cliente por meio da chamada de um método do Web Service com a solicitação do serviço desejado. Uma mensagem de resposta com o estado da solicitação é retornada, confirmando o recebimento da solicitação de serviço ao aplicativo do cliente.

A solicitação de serviço é atendida na mesma conexão ou é armazenada em filas de processamento nos casos de serviços mais onerosos, resultando em melhor aproveitamento dos recursos de comunicação e de processamento. Os serviços podem ser síncronos ou assíncronos em função da forma de processamento da solicitação de serviços:

a) Serviços síncronos - após receber uma requisição o sistema executa o comando e retorna o resultado desta ao aplicativo cliente de forma imediata, não sendo necessária a consulta posterior do estado;

b) Serviços assíncronos - após receber uma requisição o sistema retorna um token de serviço que deve ser consultado de forma periódica para obtenção do resultado da solicitação pelo aplicativo cliente, uma vez que o estado retornado for satisfatório o processamento da consulta é concluído.

A Figura 3-1 apresenta um diagrama conceitual com o fluxo de comunicação entre os aplicativos clientes e o BON-BrID.

3.2 PADRÕES TÉCNICOS

3.2.1 PADRÃO DE COMUNICAÇÃO

A comunicação entre os sistemas de informações dos clientes e o BackOffice Fiscal é baseada em Web Services, e utiliza-se da Internet como meio físico de comunicação com uso do protocolo HTTP.

O modelo de comunicação segue o padrão de Web Services definido pelo WS-I Basic Profile. A troca de mensagens entre os Web Services do BackOffice Fiscal e os sistemas clientes será realizada no padrão SOAP, com troca de mensagens XML no padrão Style/Enconding: Document/Literal, wrapped. A opção “wrapped” representa a chamada aos métodos disponíveis com a passagem de mais de um parâmetro.

Exemplo de mensagem:

3.2.2 PADRÃO DE CERTIFICADO DIGITAL

O certificado digital utilizado no BackOffice Fiscal será emitido por uma Entidade Certificadora credenciada, nos formatos do tipo A1 ou A3, devendo conter o identificador da entidade titular do certificado.

Os certificados digitais serão exigidos durante a assinatura e transmissão de mensagens entre o BackOffice Fiscal, equipamentos e sistemas. O certificado digital será utilizado para identificação das entidades, informando ao BackOffice, o responsável pela transmissão das mensagens, devendo ter a extensão Extended Key Usage com permissão de "Autenticação Cliente".

3.2.3 PADRÃO DE ASSINATURA DIGITAL COM CHAVE ASSIMÉTRICA

O acesso às funcionalidades do IVC-e através da implementação de um aplicativo cliente exige a utilização de uma chave assimétrica de segurança no padrão RSA 2048bits.

A criação de um par de chaves RSA (privada e pública) é feita com os comandos Open SSL ³ :

As mensagens enviadas aos Web Services do BackOffice Fiscal são documentos eletrônicos elaborados no padrão XML e devem ser assinados digitalmente utilizando a chave privada do cliente que deve possuir sua chave pública previamente cadastrada no BON-BrID.

O IVC-e utiliza um subconjunto do padrão de assinatura XML com o seguinte leiaute:

Tabela 3-1 - Leiaute do padrão de assinatura XML

³ OpenSLL: http://www.openssl.org/docs/HOWTO/keys.txt

Sendo que a assinatura digital do documento eletrônico XML deverá atender aos seguintes padrões adotados:

a) Padrão de assinatura: “XML Digital Signature”, utilizando o formato “Enveloped” (http://www.w3c.org/TR/xmldsig-core/);

b) Certificado digital: Emitido por AC credenciada (http://www.w3c.org/2000/09/xmldsig#X509Data);

c) Cadeia de Certificação: EndCertOnly (Incluir na assinatura apenas o certificado do usuário final);

d) Tipo do certificado: A1 e A3;

e) Tamanho da Chave Criptográfica: Compatível com os certificados A1 e A3 (1024bits) ou A4 (2048 bits);

f) Função criptográfica assimétrica: RSA 2048 bits (http://www.w3c.org/2000/09/xmldsig#rsa-sha1);

g) Função de “message digest”: SHA-1 (http://www.w3c.org/2000/09/xmldsig#sha1);

h) Codificação: Base64 (http://www.w3c.org/2000/09/xmldsig#base64);

i) Transformações exigidas, úteis para realizar a canonicalização do XML enviado para realizar a validação correta da Assinatura Digital:

1) Enveloped (http://www.w3c.org/2000/09/xmldsig#enveloped-signature);

2) C14N (http://www.w3.org/2001/10/xml-exc-c14n#).

j) Adição do campo Signature no final do corpo da mensagem com o identificador (id) do aplicativo cliente.

Diagrama de entrada exemplificando a assinatura digital:

3.2.4 VALIDAÇÃO DE ASSINATURA DIGITAL PELO BACKOFFICE FISCAL

Para a validação da assinatura digital, seguem as regras que serão adotadas pelo BackOffice Fiscal:

A. Calcular o hash da mensagem para verificar que a mesma não foi alterada;

B. Validar o campo Signature por um id válido para recuperar a assinatura;

C. Verificar a autenticidade da assinatura;

3.2.5 RESUMO DOS PADRÕES TÉCNICOS

A Tabela 3-2 resume os principais padrões técnicos utilizados.

Tabela 3-2 - Resumo dos padrões técnicos

3.3 MODELO OPERACIONAL

Com base na definição apresentada na seção 3.1 sobre serviços síncronos e assíncronos, os serviços do IVC-e são implementados da seguinte forma:

Tabela 3-3 - Modelo operacional

3.3.1 SERVIÇOS SÍNCRONOS

A Figura 3-3 ilustra as etapas executadas no processo ideal:

⁴ No caso de mensageria o Registro de passagem tem comportamento assíncrono.

Figura 3-3 - Ilustração de serviço síncrono

1) O aplicativo cliente inicia a conexão enviando uma mensagem de solicitação de serviço para o Web Service de recepção de solicitação de serviços;

2) O Web Service recebe a mensagem de solicitação e encaminha ao aplicativo do IVC-e responsável pelo processamento;

3) O aplicativo do IVC-e recebe a mensagem e realiza o processamento, retornando o resultado do processamento ao Web Service;

4) O Web Service recebe a mensagem de resultado e encaminha ao aplicativo cliente;

5) O aplicativo cliente recebe a mensagem de resultado do processamento e, se não houver outra mensagem, encerra a conexão.

3.3.2 SERVIÇOS ASSÍNCRONOS

A Figura 3-3 ilustra as etapas executadas no processo ideal:

Figura 3-4 - Ilustração de serviço assíncrono

1) O aplicativo cliente inicia a conexão enviando uma mensagem de solicitação de serviço para o Web Service de recepção de solicitação de serviços;

2) O Web Service de recepção de solicitação de serviços recebe a mensagem e inicia o processamento da mensagem em segundo plano;

3) O Web Service de recepção de solicitação de serviços retorna o recibo da solicitação de serviço (token);

4) O aplicativo cliente recebe o token de solicitação;

5) O cliente aguarda um período de tempo e inicia nova consulta;

6) O cliente realiza a consulta no servidor;

7) A execução do processo em segundo plano é finalizada no servidor;

8) O estado da execução do serviço é retornado ao cliente.

3.4 PADRÃO DE MENSAGENS DOS WEB SERVICES

3.4.1 CABEÇALHO DA MENSAGEM

As chamadas dos Web Services fornecidos pelo Back Office e seus retornos são feitos através de mensagens, as quais o cabeçalho segue o seguinte padrão de composição:

 - Security: informação de segurança que compreende todo o resto do cabeçalho;

 - Signature: informação de assinatura do cliente utilizada para verificação da autenticidade da mensagem;

 - SignedInfo: toda a informação que será posteriormente assinada;

 - CanonicalizationMethod: mecanismo de canonicalização da mensagem para evitar interpretação incorreta de mensagens;

 - SignatureMethod: método RSA-sha1 utilizado para assinar a mensagem;

 - Reference: campo que origina a geração de hash para garantir autenticidade da mensagem;

 - Transforms: lista de procedimentos Transform;

 - Transform: uma instância de procedimento para evitar geração incorreta do hash;

 - DigestMethod: método utilizado para geração de hash;

 - DigestValue: é o resultado do hash;

 - SignatureValue: assinatura do signedInfo resultante.

3.4.2 CORPO DA MENSAGEM

As chamadas dos web services fornecidos pelo Back office e seus retornos são feitos através de mensagens, as quais o corpo segue o seguinte padrão:

Figura 3-5 - Padrão de mensagem dos Web Services

3.4.3 VALIDAÇÃO DA ESTRUTURA XML DAS MENSAGENS DOS WEB SERVICES

As mensagens trocadas pelos web services devem estar de acordo com o padrão definido nas seções 3.4.1 e 3.4.2 sendo que o controle de padronização da mensagem é feito diretamente pelo servidor Web do Back Office.

Deste modo, os aplicativos clientes implementados devem estar preparados para gerar mensagens dentro do padrão definido, sendo que mensagens fora do padrão serão descartadas pelo servidor.

3.4.4 SCHEMAS XML DAS MENSAGENS DOS WEB SERVICES

Um Schema XML define o conteúdo do documento XML, descrevendo os seus elementos, organização, regras de preenchimento de conteúdo e de obrigatoriedade de cada elemento ou grupo de informação.

Toda mudança de leiaute das mensagens dos Web Services implica atualização do respectivo Schema XML e, as modificações podem ser causadas por necessidades técnicas ou solicitações, sendo que serão adequadamente informadas aos interessados. Exemplo de schema XML:

3.5 WEB SERVICES

Os Web Services disponibilizam os serviços que serão utilizados pelos aplicativos clientes e no BON-BrID será fornecido um Web Service por serviço, existindo um método para cada tipo de serviço. Os webservices listados nesta seção pertencem aos schemas XML BackofficeBrasilIdIVCe.xsd e BackofficeBrasilIdTag.xsd e o significado dos campos das tabelas encontra-se no anexo 4.1 deste documento.

As URLs dos Web Services encontram-se nos schemas XML 4.2 e 4.3 anexos neste documento, por meio das quais é possível obter o WSDL (Web Services Description Language) de cada Web Service. O processo de utilização dos Web Services sempre é iniciado através do envio de uma mensagem nos padrões XML e SOAP, através do protocolo HTTP e a ocorrência de qualquer erro na validação dos dados recebidos interrompe o processo com a disponibilização de uma mensagem adequada.

3.5.1 MÍDIA (TAG SEM SER INICIALIZADA)

3.5.1.1 REQUISIÇÃO DE IDENTIFICADORES DE TRANSPONDERS

Serviço de requisição de identificadores de transponders (requisitaTID) para serem usados em um determinado lote de tag's. Oferecido pelo BON-BrID para permitir a requisição de novos identificadores de transponders por meio de aplicações clientes da fábrica de tag.

Tabela 3-4 - Mensagem de requisição de TID’s

Diagrama simplificado de entrada:

Tabela 3-5 – Mensagem de resposta de requisião de TID’s

Diagrama simplificado de resposta:

3.5.1.2 RECUPERAÇÃO DE IDENTIFICADORES DE TRANSPONDERS

Serviço de recuperação de identificadores de transponders (recuperaTID) oferecido pelo Back Office para obter o resultado da requisição previamente realizada pela fabrica, por meio do requisitaTID.

Tabela 3-6 – Mensagem de recuperação de TID’s

Figura 3-8 - Diagrama de entrada recuperaTIDs

Tabela 3-7 – Mensagem de resposta de recuperação de TID’s

Figura 3-9 - Diagrama de saída recupera TIDs Response

3.5.1.3 CONFIRMAÇÃO DE REQUISIÇÃO DE IDENTIFICADORES DE TRANSPONDERS

Serviço fornecido para que o CCD 5 (Comitê Certificador Designado) realize a confirmação (ou recusa) da requisição da lista de identificadores de transponders (confirmaRequisicaoTID), feita pela fabrica de tags por meio do requisitaTID. Se o CCD não confirmar a requisição o fluxo é encerrado.

Tabela 3-8 – Mensagem de confirmação de requisição de TID’s

Figura 3-10 - Diagrama de confirma Requisição TIDs

Tabela 3-9 – Mensagem de resposta de confirmação requisição de TID’s

⁵ O Comitê Certificador Designado (CCD): é o encarregado de aprovar as requisições de emissão de identificadores de transponderes (TIDs) para o processo de fabricação dos transponders.

Figura 3-11 - Diagrama de Confirma Requisição TIDs Response

3.5.1.4 CANCELAMENTO DE REQUISIÇÃO DE IDENTIFICADORES DE TRANSPONDERS

Serviço fornecido para permitir o cancelamento de uma requisição de identificadores (cancelaRequisicaoTID) para os casos em que a confirmaRequisicaoTID tiver resultado negativo (CCD não confirmar) ou para quando a fábrica desejar cancelar a requisição.

Tabela 3-10 – Mensagem de cancelamento de requisição de TID’s

Figura 3-12 - Diagrama de Cancela requisição TIDs requisitaTIDs

Tabela 3-11 – Mensagem de resposta de cancelamento de requisição de TID’s

Figura 3-13 - Diagrama de Cancela Requisição TIDs Response

3.5.1.5 REGISTRO DE ENVELOPE PROTETOR

Serviço fornecido para que a fábrica realize o registro do envelope protetor (EP) da tag (registraEP), caracterizando a associação entre EP e identificador de tag (tagID). O EP é um mecanismo de segurança para evitar a clonagem de mídias e o seu registro torna a tag pronta para ser vendida a uma operadora.

Tabela 3-12 – Mensagem de registro de envelope protetor

Figura 3-14 - Diagrama Registra EP

Tabela 3-13 – Mensagem de resposta de registro de envelope protetor

Figura 3-15 - Diagrama de Registra EP Response

3.5.1.6 REGISTRO DE VENDA

Serviço fornecido pelo Back office para que a fábrica realize o registro de venda de um lote de tags (registraVenda) para uma operadora, previamente cadastrada.

Tabela 3-14 – Mensagem de registro de venda

Figura 3-16 - Diagrama de Registra Venda

Tabela 3-15 - Mensagem de resposta de registro de venda

Figura 3-17 - Diagrama Registra Venda Response

3.5.1.7 RECUPERAÇÃO DE INFORMAÇÕES SOBRE A VENDA

Serviço fornecido para que a operadora obtenha informações das tags utilizadas na transação de compra e venda (recuperaDadosVenda).

Tabela 3-16 – Mensagem de recuperação de informações sobre a venda

Figura 3-18 - Diagrama de Recupera Dados venda

Tabela 3-17 – Mensagem de resposta de recuperação de informações sobre a venda

Figura 3-19 - Diagrama de Recupera Dados Venda Response

3.5.1.8 CONFIRMAÇÃO DE VENDA

Serviço do BON-BrID fornecido para assegurar que uma venda de lote de tags, previamente registrada pela fábrica com o registraVenda, só seja efetivada após a confirmação de compra por parte da operadora (confirmaCompra).

Tabela 3-18 – Mensagem de confirmação de venda

Figura 3-20 - Diagrama de Confirma Compra

Tabela 3-19 - Mensagem de resposta de confirmação de venda

Figura 3-21 - Diagrama Confirma Response

3.5.1.9 CANCELAMENTO DE VENDA

Serviço utilizado para cancelar uma operação de venda de tags.

Serviço fornecido para permitir o cancelamento de uma venda de lote de tags (cancelaVenda). Utilizada nos casos em que a confirmaVenda tiver resultado negativo (Operadora não confirmar).

Tabela 3-20 – Mensagem de cancelamento de venda

Figura 3-22 - Diagrama Cancela Venda

Tabela 3-21 - Mensagem de resposta de cancelamento de venda

Figura 3-23 - Diagrama de Cancela Venda Response

3.5.1.10 RECUPERAÇÃO DO ESTADO DA VENDA

Serviço utilizado para que a fabrica obtenha o estado da venda de lote de tags (recuperaStatusVenda), previamente realizada para uma operadora, por meio de um token.

Tabela 3-22 – Mensagem de recuperação do estado da venda

Figura 3-24 - Diagrama Recupera Status Venda

Tabela 3-23 - Mensagem de resposta de recuperação do estado da venda

Figura 3-25 - Diagrama Recupera Status Venda response

3.5.2 IVC-E (TAG INICIALIZADA)

3.5.2.1 INICIALIZAÇÃO DE TAG COMO IVC-E

Serviço (inicializaIvceTag) que permite para que uma Operadora inicialize um IVC-e (Identificador de Veículo de Carga Eletrônico), através de um CSS 6 (Console de Solicitação de Serviço), para que futuramente possa ser instalado em um veículo.

Tabela 3-24 – Mensagem de inicialização de Tag IVC-e

⁶ CSS: Entidade responsável por comunicar-se com a EGC e realizar comandos para operação do ECT.

Figura 3-26 - Diagrama de Inicializa IVC-e TAG

Tabela 3-25 - Mensagem de resposta de inicialização de Tag IVC-e

3.5.2.2 RECUPERAÇÃO DO ESTADO DA INICIALIZAÇÃO DE TAG COMO IVC-E

Serviço (recuperaStatusInicializacao) fornecido pelo Back Office para que a operadora possa recuperar o estado da inicialização de um IVC-e (Identificador de Veículo de Carga Eletrônico).

Tabela 3-26 – Mensagem de recuperação do estado da inicialização de Tag IVC-e

Figura 3-28 - Diagrama Recupera Status Inicializado

Tabela 3-27 - Mensagem de resposta de recuperação do estado da inicialização de Tag IVC-e

Figura 3-29 - Diagrama de Recupera Status Inicialização response

3.5.2.3 VÍNCULO ENTRE IVC-E E VEÍCULO

Serviço (vinculaIVCe) fornecido para que uma Operadora notifique a vinculação de um IVC-e (Identificador de Veículo de Carga Eletrônico) com um veículo, através de um CSS (Console de Solicitação de Serviço).

Método síncrono utilizado pela operadora Brasil-id através de um Console de Solicitação de Serviços (CSS) para notificar a instalação de um IVC-e previamente inicializado em um veículo

Tabela 3-28 – Mensagem de vínculo entre IVC-e e veículo

Figura 3-30 - Diagrama de Vincula IVC-e

Tabela 3-29 - Mensagem de resposta de vínculo entre IVC-e e veículo

Figura 3-31 - Diagrama de Vincula IVC-e Response

3.5.2.4 REGISTRO DE PASSAGEM DE IVC-E

Serviço (passagem) fornecido pelo BON-BrID para efetuar o registro no BON-BrID da passagem de um IVC-e (Identificador de Veículo de Carga Eletrônico) por um SLD 7 (Sistema de Leitura de Dispositivo).

Tabela 3-30 – Mensagem de registro de Passagem de IVC-e

Figura 3-32 - Diagrama de Passagem

Tabela 3-31 - Mensagem de resposta de registro de Passagem de IVC-e

Figura 3-33 - Diagrama de entrada requisitaTID

⁷ SLD: Sistema de Leitura de Dispositivo é um conjunto composto de sensores e equipamentos instalados para a detecção de passagem dos veículos e outras entidades participantes do projeto.

3.5.2.5 DECODIFICAÇÃO DO BLOCO CIFRADO DO IVC-E

Serviço (decodificaIVCe) que permite que um SLD (Sistema de Leitura de Dispositivo) possa decodificar um Transponder para registrar a passagem com a tag previamente validada.

Tabela 3-32 – Mensagem de decodificação do bloco cifrado do IVC-e

Figura 3-34 - Diagrama de decodifica IVC-e

Tabela 3-33 - Mensagem de resposta de decodificação do bloco cifrado do IVC-e

Figura 3-35 - Diagrama de decodifica IVC-e Response

3.5.2.6 CANCELAMENTO DE IVC-E

Serviço (cancelaIVCe) fornecido pelo BON-BrID para permitir que uma Operadora possa cancelar um IVC-e (Identificador de Veículo de Carga - Eletrônico) associado a um veículo, inutilizando seu uso no contexto do sistema.

Tabela 3-34 – Mensagem de cancelamento de IVC-e

Figura 3-36 - Diagrama de Cancela IVC-e

Tabela 3-35 - Mensagem de resposta de cancelamento de IVC-e

Figura 3-37 - Diagrama de Cancela IVC-e ResponseTipos definidos

3.5.3 TIPOS DEFINIDOS

3.5.3.1 TIDEP

Estrutura utilizada para associar informação entre Id de Tag (Tid) e envelope protetor (EP) durante a comunicação dos web Services.

Tabela 3-36 - Tipo TIDEP

3.5.3.2 WSTOKEN

Estrutura de dados que contém o token de requisição de serviço. Este token é usado nas operações assíncronas de web services, vinculando a chamada corrente com uma pré-estabelecida (iniciada).

Tabela 3-37 - Tipo WSToken

3.5.3.3 WSVEICULO

Estrutura que armazena os dados do veículo na comunicação do Web Service.

Tabela 3-38 - Tipo WSVeiculo

3.5.3.4 WSRESULT

Estrutura padrão de retorno utilizada em todos os métodos de Web Services. O wsResult define um conjunto enumerado de possíveis códigos, indicando o tipo de erro e sua origem como mostra a tabela a seguir:

Tabela 3-39 - Tipo WSResult

Tabela 3-40 – Nomes de retorno

3.6 SERVIÇOS DISPONIBILIZADOS POR MENSAGENS

A interface de mensagens está especificada por Protocol Buffers (também chamado protobuf) se assemelha ao código de linguagens usuais de programação, como C++ e Java. Ela é apresentada em arquivos .proto que descrevem, basicamente, a estrutura dos dados, seus tipos e ordem de armazenamento. Cada arquivo especifica estruturas de mensagens para comunicação que serão interpretadas pelo BackOffice Fiscal. Na sequência são apresentados os arquivos e formato das mensagens utilizadas na comunicação.

3.6.1 MENSAGEM DE LEITURA

Mensagem de leitura de passagem de veículos.

Tabela 3-41 - Mensasagem de leitura

4 ANEXOS

4.1 LEIAUTE DO IVC-E

Observações importantes para entendimento do Leiaute do IVC-e:

1) Abreviações utilizadas nas colunas de cabeçalho do leiaute:

a) Coluna #: Identificador da linha da tabela;

b) Coluna Campo: Identificador do nome do campo. Como a nomenclatura dos nomes dos campos foi padronizada, um nome de campo é utilizado para identificar campos diferentes. A diferenciação dos campos é realizada considerando as tags de grupo.

c) Coluna Ele:

A - indica que o campo é um atributo do Elemento anterior;

E - Indica que o campo é um Elemento;

CE - Indica que o campo é um Elemento que deriva de uma Escolha (Choice);

G - Indica que o campo é um elemento de Grupo;

CG - Indica que o campo é um Elemento de Grupo que deriva de uma Escolha (Choice);

ID - Indica que o campo é um ID da XML 1.0;

RC - Indica que o campo é uma key constraint (Restrição de Chave) para garantir a unicidade e presença do valor.

d) Coluna Pai: Indica o nível hierárquico do item na estrutura;

e) Coluna Tipo:

N - Campo numérico;

C - Campo alfanumérico;

D - Campo data.

f) Coluna Ocorrência: x-y, onde x indica a ocorrência mínima e y a ocorrência máxima;

g) Coluna Tamanho: x-y, onde x indica o tamanho mínimo e y o tamanho máximo; a existência de um único valor indica que o campo tem tamanho fixo, devendo-se informar a quantidade de caracteres exigidos, preenchendo-se os zeros não significativos; tamanhos separados por virgula indicam que o campo deve ter um dos tamanhos fixos da lista;

h) Coluna Dec: Decimais

i) O tamanho máximo dos campos Tipo “C”, quando não especificado, é 60 posições.

4.2 SCHEMA RELACIONADO AOS MÉTODOS DA TAG

Schema BackofficeBrasilIdTag.xsd

targetNamespace: http://webservices.brasil-id.org.br/tag/

Elements Complex types Simple types
cancelaRequisicaoTIDs cancelaRequisicaoTIDs wsResult
cancelaRequisicaoTIDsResponse cancelaRequisicaoTIDsResponse

cancelaVenda cancelaVenda

cancelaVendaResponse cancelaVendaResponse

confirmaCompra confirmaCompra

confirmaCompraResponse confirmaCompraResponse

confirmaRequisicaoTIDs confirmaRequisicaoTIDs

confirmaRequisicaoTIDsResponse confirmaRequisicaoTIDsResponse

recuperaDadosVenda recuperaDadosVenda

recuperaDadosVendaResponse recuperaDadosVendaResponse

recuperaStatusVenda recuperaStatusVenda

recuperaStatusVendaResponse recuperaStatusVendaResponse

recuperaTIDs recuperaTIDs

recuperaTIDsResponse recuperaTIDsResponse

registraEP registraEP

registraEPResponse registraEPResponse

registraVenda registraVenda

registraVendaResponse registraVendaResponse

requisitaTIDs requisitaTIDs

requisitaTIDsResponse requisitaTIDsResponse

tidEP

wsToken
schema location: C:\Program Files\Altova\Common2013\Schemas\xmldsig\files\xmldsig-core-
schema.xsd
attributeFormDefault:

elementFormDefault: qualified
targetNamespace: http://www.w3.org/2000/09/xmldsig#


Elements Complex types Simple types
CanonicalizationMethod CanonicalizationMethodType CryptoBinary
DigestMethod DigestMethodType DigestValueType
DigestValue DSAKeyValueType HMACOutputLengthType
DSAKeyValue KeyInfoType

KeyInfo KeyValueType

KeyName ManifestType

KeyValue ObjectType

Manifest PGPDataType

MgmtData ReferenceType

Object RetrievalMethodType

PGPData RSAKeyValueType

Reference SignatureMethodType

RetrievalMethod SignaturePropertiesType

RSAKeyValue SignaturePropertyType

Signature SignatureType

SignatureMethod SignatureValueType

SignatureProperties SignedInfoType

SignatureProperty SPKIDataType

SignatureValue TransformsType

SignedInfo TransformType

SPKIData X509DataType

Transform X509IssuerSerialType

Transforms

X509Data
 

XML Schema documentation generated by XMLSpy Schema Editor http://www.altova.com/xmlspy

4.3 SCHEMA RELACIONADO AOS MÉTODOS DO IVC-E

Schema BackofficeBrasilIdIVCe.xsd

targetNamespace: http://webservices.brasil-id.org.br/ivce/

schema location: C:\Program Files\Altova\Common2013\Schemas\xmldsig\files\xmldsig-core-schema.xsd

attributeFormDefault:

elementFormDefault: qualified

targetNamespace: http://www.w3.org/2000/09/xmldsig#

]

XML Schema documentation generated by XMLSpy Schema Editor http://www.altova.com/xmlspy