Skip to main content

Third Party Onboarding

This document is your guide to connect to the Mobilidata ecosystem, each step comes with an explanation. If something remains unclear, please reach out to us. The different steps in the Third Party Onboarding proces have different proces owners on Mobilidata side:

Ben Helsen and Erika Decorte (AWV) are the process owners of step 1 (preparations and collaboration contracting), part A (Expression of interest, including scoping of collaboration):

Tom De Pryck (AWV) is the process owner of step 1 (preparations and collaboration contracting), part B (Collaboration contract):

Wim Vandenberghe and Marcel Wiggerts (AWV) are the process owners of step 2, technical connection process initiation:

Side note

To simplify the process, the connection type has been split up in 3 different types. If anything is unclear, please reach out to your process owner(s).

info

Every connecting party has to set up a Connection Agreement, and in case of privacy-related data also a Protocol, with AWV in order to process the gained data in an orderly and legal way. To facilitate this process, Mobilidata has created a set of template files that can be used as a starting point for the needed Connection Agreement and Protocol. These can be downloaded here. Note that this template bundle also contains an NDA template in case this would be desired to be in place.

Step 1: Preparations and connection agreement​

A. Expression of interest​

Tell us who you are and what you would like to get out of the Mobilidata connection. If still needed, we can help you to determine the scope of use cases you would need connection to. You can count on our discretion, but if desired we can also sign an NDA before organising these discussions. An NDA template is provided, and can be downloaded here.

tip

Access is granted use case per use case. Go to the use case overview to see which use cases are available and could be of interest for you.

On our side we would like to get to know your organization and type of business to do a check that your business matches the Mobilidata goals of improving road safety, traffic throughput and reducing emissions. General company information and a small company introduction, your website, your contact personal data… is what we require for this.

B. Connection Agreement​

After reading the documentation and expressing your interest, you will have a clear understanding of what Mobilidata is and what it can do for you. Thus, the connection agreement is the next step.

Mobilidata connection is free of charge, but we do need a set of mutually agreed clauses and conditions so both parties clearly understand their rights and obligations. These are covered in the so called Connection Agreement. In case of use cases considered to contain privacy-sensitive data according to the GDPR, a Protocol should also be signed between both parties. This document can be seen as the needed Data Processing Agreement.

Depending on the use cases you want to connect and the type of cooperation for those use cases, 3 options arise (select to see more):

This is the most simple type of connection. You only need to listen to the Mobilidata interchange. You will not provide any information in return.

tip

Your selection of connection type will be consistent throughout this entire page.

Combinations of these 3 options are possible (example: iTLC + read only all the other use cases). In that case read both steps, and you will see you can skip some. Ask your process owner if there is something unclear.

warning

A formal connection agreement with all necessary addenda depending on the type of connections covering technical/GDPR topics/Communication/… is prepared, reviewed, and signed by both parties before Step 2 can start.

Step 2: Technical connection process initiation​

After the connection agreement is signed, the technical connection process can start. This process is slightly different for each type of connection. Select the type of connection you are interested in to see the exact steps.

A. Publisher ID and Prefix Service Provider​

info

If you are going to publish information to the Mobilidata Interchange, you will need a unique Publisher ID as specified in the C-Roads specifications. For iTLC interaction, there is also a Prefix Service Provider needed as specified in the CROW specifications.

Publisher ID​

Not applicable

Prefix Service Provider​

Not applicable

B. Testbed​

info

Before interacting with one of the intelligent Traffic Lights use cases, either for standard or special vehicles or pedestrians/byciclists, interaction with the testbed is mandatory. The testbed is a simulation environment that allows you to test your application against the Mobilidata interchange. This is a good way to get to know the Mobilidata interchange and to test your application before going live. At the moment, only intelligent Trafficlight test modules are present, other functionality will follow.

Practice makes perfect - before connecting to traffic lights on-street you will need to prove that you are up to this job by making a connection with our testbed and running all necessary (relevant) tests.

Additional information about the testbd can be found at: Testbed and test process (Dutch)

IP whitelisting​

To connect with the MI of the testbeds (AMQP header variable: dtap=testbed), your IP address needs to get whitelisted. To do this, you need to send an email to the Mobilidata servicedesk, operated by Be-Mobile

The email to servicedesk@be-mobile.com must contain:

  • Subject: company name wants to connect to the Mobilidata interchange
  • Which use cases do you need (use case list)
  • Public static IP address for all possible connections
  • Your PublisherID

The servicedesk will whitelist your IP address (The servicedesk will reply within approximately 2 weeks) and now you can connect to the testbed:

The Testbed certification process​

A testbed environment has been set up where interaction with a full setup of iTLC can be tested. Before interacting with the real iTLC in the streets, a certificate must be achieved in the testbeds. More information can be found on the documentation of the testbeds. iVRI Lab

In the testbeds you can choose to have your resources connected via VPN or embed them in the testbeds. For both processes a resource manager component is to be set up in the testbeds. More information can be found in the docs of the testbeds.

C. SSL-certificate​

info

To make a connection to the Mobilidata interchange on any environment (acceptance/production), a certificate signing request (CSR) is required according to international C-ROADS TLS-SSL specifications. It serves the secured identification process when connecting to Mobilidata. The Certificate Authority in Mobilidata is the Flemish administration. No other CA's are supported.

This (dutch only) document illustrates how to generate a CSR: https://assets.vlaanderen.be/image/upload/v1628695506/Handleiding_CSR_sf7f0q.pdf . Note that the work to generate the CSR ends at paragraph 3.4. Once you completed that one, you have the CSR file that you can email to the process owners of step 2, mentioned in the beginnen of this page. This means that you should not be aware of any VO-DCBAAS details mentioned in the last part of that document, the Mobilidata process owners will take care of those for you. These process owners will provide you with the certificate in return as soon as possible (this could take 2 weeks), but only if the connection agreement of step 1 has been signed by both parties.

In the CSR creation proces you need to fill in a FQDN (fully qualified domain name) in the CN field (common name). You can choose it based upon the logic:

<company>-service-provider-development.mobilidata.vlaanderen.be

or

<company>-service-provider-acceptance.mobilidata.vlaanderen.be

or

<company>-service-provider-production.mobilidata.vlaanderen.be

It is recommended to create three different CSR files, one for each of the above FQDN's. As a result, you will receive three different certificates from Mobilidata. This allows you to setup three different parallel connections to the Interchange. This is crucial if you want to continue development of your solution after you have put your first version in production. Note that sometimes in IT deployments the SAN field of the CRS is used to combine one certificate for multiple domeins (SAN stands for Subject Alternative Name). However, the Interchange does not support the SAN field, it only checks the CN field when a connection is established. Therefore it is needed to create 3 different CSR files, and there is no need to fill in the SAN field when creating the CSR.

Antother field in the CSR that you however should not forget to fill in, is the organizationName field. There you can fill in 'Your short company name'

warning

The system of the Flemish administration cannot handle non-BE country codes. So be sure to use BE as country code in the CSR, even if you are not a Belgian organisation.

Once you received your certificate, to establish the actual connection you will need two other pieces of information. The first one is the SSL certificate of the root CA of the Flemish government. You can download that from https://documenten.pki.vlaanderen.be/ . The other one is the public key of the Interchange. This one should be sent automatically by the Interchange when you try to connect for the first time.

The received SSL-certificate has a limited validity, e.g. one or two years. The standard approach towards renewal is that you create a new public/private keypair, create a new CSR, and send it to the step 2 proces owners to get a new certificate for the oncoming period. It is your own responsibility to keep track of the validity period of your certificates, and to request new ones on time.

Note that if your technical setup requires a relatively large amount of certicates that need to be requested, the option exists that the right to create certificates for your domain gets delegated to you. This will require you to have a more detailed understanding of the technical processes on our side (the VO-DCBAAS system), but allows you to create your new certificates yourself. It will still require manual steps from your side, delegated automated certificate renewal is not supported. If you wish to explore this delegation option, please contact the step 2 proces owners.

info

Note for the step 2 proces owners: the details on the steps you need to take internally to create the certificates based on the received CSR files are not described here since this is a publicly accessable web page. A document with these details can be found on the MD3V internal drive, in the WP1/T1.8 folder.

D. Connection setup​

The next step is setting up the actual connection.

The request to set up the connection is submitted by the step 2 proces owners. They do so by creating a new Service Request ticket on the Be-Mobile Mobilidata servicedesk (Jira), where only they have acess to. The servicedesk will reply within approximately 2 weeks. To ask the step 2 proces owners to take this action, an email with all needed information needs to be sent to the step 2 proces owners by the newly connecting party.

IP whitelisting

The MI is only reachable for whitelisted IP addresses. This means that you need a static IP address and communicate it to us, so it can be whitelisted. Make sure to give us the public IP address of your environment. (thus NOT private ranges like 10.xxx or 192.xxx or 172.xxx)

This email must contain:

  • Subject: company name wants to connect to the Mobilidata interchange
  • Which use cases do you need (ISO Causecode), and/or static API usage
  • Common name = FQDN (same as you use in the CSR)
  • Short description of the reason for connection
  • Public static IP address for all possible connections
Tip

Once you are whitelisted and the configuration setup is made in the MI, in the tutorial section you will find a technical guide on how to connect and send and receive messages.

Tags:
Last updated on by Wim Vandenberghe