Using the OpenTripModel in Simacan

Within Simacan we strongly believe that using open standards will improve productivity and the quality of the communication we have with other parties. As a result we are heavily invested in OTM5 and increasingly provide more APIs using this standard. OTM stands for Open Trip Model and is a communication format & protocol specifically tailored for the domain of traffic and logistics.

Usage of OTM on the Simacan platform

otm5 landscape

Within Simacan you can currently send and/or receive data in the OTM5 format in the following places:

  • Planned trips in the universal planning inbox. Ensuring trip data is visible in the Control Tower and ready to be monitored. The first step in the monitoring process on the Simacan platform.
  • Enrich existing trips with coupled vehicle information using the OTM couple call. Whenever the vehicle information is not known during the planning, it can be provided afterwards, for example by the carrier.
  • Receive updates on planned data that is updated either in the Control Tower or by some transport management system connected to Simacan. So whenever trips and vehicle information are inserted using the above two methods, it will also result in updates in the planning-push, that might be useful for the party executing the trips.
  • Send real-time location updates (GPS points) of the vehicle to the Simacan platform. This information is combined with the earlier provided planning to monitor trips and create exceptions whenever a planning is expected to be out of sync with reality.
  • Receive real-time estimated arrival times on stops of a trip, so systems can automatically inform or act on projections that differ from the original planned data and share prjoected delivery times.
  • Retrieve consignments, either by their unique UUID, or grouped for all locations that are at one point present on a certain location. The consignment API contains all information relevant for loading, unloading and the contents of these consignments.
  • Receive completed trips together with their originally planned data, so that they can be compared and serve as input for future planned trips.

Processes

we can identify the following processes on the Simacan platform. Note that some of these steps can happen in another order or (nearly) at the same time:

  1. Trips get created within the Simacan platform (either through OTM messages or other formats). These trips can optionally be coupled to a vehicle in the planning.
  2. This results in a OTM5 planning being send to consumers of the planned-trip-to-otm export service. Naturally, only parties with the proper authorization and active subscriptions will be notified.
  3. Updates on previously shared trips, through the UI or using the same insertion method as before. Regardless of the method, OTM5 updates will be send via the planning-push.
  4. If no vehicle was present in the planning, one can be provided manually in the Simacan Control Tower, or automatically using the OTM5 couple call. Again regardless of the method, updates will be shared using the planning-push.
  5. Trips can be cancelled (manually or automatically). A trip with the status cancelled without actions will be shared in the planning-push.
  6. Trips are assigned to another carrier. For the original carrier the trip is now effectively cancelled, so a message will be shared using the planning-push as in step 5. The newly assigned carrier & the shipper will receive an updated planning no different than any of the updates explained in step 2. and 3.
  7. A device in the vehicle driving the trip emits GPS updates. These updates are used within the Simacan platform to calculate ETAs and recognize exceptions. Parties subcribed to the ETA push will receive ETA messages for the trip that the GPS update came in for. Each GPS update triggers an ETA recalculation and could result in new ETAs being shared by the ETA push. However the Control Tower might bundle GPS updates whenever multiple are processed at the same time.
  8. A trip is completed. Subscribers of the Realized trip push will get a message containing both the planned and realized times.

OTM Profiles

Since different use cases require different kinds of messages OTM has introduced the concept of profiles. Basically having clear rules for OTM5 should be used in different situations.

Within Simacan we support three different type of profiles: 1. The Trip profile, the most common type of message within Simacan. This is used for planning intake & data export, including the planning push, realisation push & ETA push. 2. The FMS profile to send real-time GPS updates. 3. The Consignment profile, for tracking consignments that potentially are part of many trips before arriving at their final destination.

Versioning of messages

Whenever Simacan wants to make updates to the messages send via either the planning-push or the realized trips push they fall into one of two categories:

  1. Additions, new properties that were not used before. These can and will be added without the need of any subcribers to do anything, they can and simply will ignore data and create support whenever suited.
  2. moving or deleting properties. This naturally will result in subcribers in receiving different messages than before, likely resulting in failures. Obviously this is unaccetable and therefore Simacan has introduced the notion of versioned profiles. Whenever we see the need to update the existing messages we will create a new profile and only upgrade to this version for each subcriber whenever suited. At the moment only two profiles exist, aptly named profile1 and profile2.