Shipment The process of transferring a package from A to B can be stored in a shipment. You can think of transport by plane, truck, train, etc. During this transfer, the package will be monitored by multiple devices. The connection between devices and shipments can be made with ShipmentAssociations. A shipment can have an event profile assigned to monitor any discrepancies during transit.
SubShipment A sub-shipment is part of a larger shipment (master shipment) but can be used to split device monitoring/event profiling. You can, for example, have an “inside” and “outside” of a shipment, for monitoring inside a package and outside of a package.
Device A monitoring device which is capable of sampling temperature, humidity, light, shock or any other parameter. The data can be retrieved in multiple ways. This can either by pushed to our servers by the device itself or manually uploaded over API or through the SmartView portal.
ShipmentAssociation The link between a device and a shipment. This link contains information about the time this association was started and the time this associated ended. Any data that is coming in for that device during this period will be considered to belong to the related shipment.
Milestone A marker somewhere along the process that can indicate something special happening. (In case of a shipment it could mean that a shipment arrived at some stop-over station)
Event Profile A set of rules to monitor the data of the devices coming in. An event profile can be assigned to shipments and sectors. Any incoming data will be checked on the rules of the event profile. If it’s exceeding any of those rules we will create an excursion and send an alarm (by email or SMS) to the configured users.
Excursion Whenever a violation of any of the defined event rules occurs we will create an excursion describing when a violation of that rule occurred. End users should take action based on these excursions by checking what is going on. After they checked they can either acknowledge or close an excursion by providing some information about what triggered this excursion and how it is resolved.
Root Cause A reason for why an excursion occurred. There can be various reasons why the excursion occurred, to streamline the way that excursions can be resolved we use root causes to determine what really triggered this excursion to happen.
Product A physical product that is being shipped. A product can have a set of stability rules containing alarm thresholds to determine if the product can still be used or not. This stability will be calculated against those rules, based on the samples of the connected devices (through shipment or sector associations). A product also can have storage conditions that should be met while transferring or storing this product. Those storage conditions should be seen as a global temperature range in which this product should be transferred/stored.
Storage Condition A range to define between which temperatures a product should be transferred or stored. This range will be used in reports and graphs to indicate if a product has been outside of this ‘safe’ zone.
Customer This is the customer that a shipment is made for.
Location A physical location that is used to store packages. Each location consists of multiple sectors. Packages will mostly be stored for a longer time here.
Sector The actual place in the location where this package is stored. There can be sectors containing different storage conditions like a very cold fridge and a room with ambient temperature. All those different sectors will be capable of storing and monitoring a different kind of packages. Also, these packages will be monitored by an event profile to notify about any discrepancies.
SectorAssociation To be able to monitor packages in a sector we will need devices being linked to a sector. That is where the SectorAssociation is used for. In a SectorAssociation, you can define the period a device is linked to a sector. All data from the device during this period will be used to monitor that specific sector.
