While training partners, the team of trainers noticed that users do not always understand the relationship of elements in our niche applications. This is especially evident if a partner plans to create a proprietary solution based on the application. To solve the problem, we created this diagram. It will give you a general idea of how NimBus works, although it may not be optimal for learning the application from scratch.
Obligatory elements (★) are elements without which the creation or full use of other elements is impossible.
The obligatory elements of NimBus include stops, routes, schedules, units, and rides. Other elements are optional, but will make the work with the application more convenient or provide users with new opportunities.
In the diagram, a dotted line distinguishes two stages of work with the application: configuration and operation. It is assumed that the Wialon administrator and/or fleet engineer configures the elements on the diagram's left side before the everyday use of NimBus begins.
I should note that the Units element is intentionally located in such a way as to belong to both stages of work. This is because there are different ways to assign units to rides, depending on the operation mode of a transport company, which will be discussed later in the article.
The NimBus configuration starts with adding Stops. You can do this manually by creating circles of a certain radius or polygons consisting of many points, or by importing from a KML file. Each stop can belong to one or more types according to the types of transport visiting it: bus, trolleybus, tram, route taxi. You can also create a stop without selecting any type of transport.
Then, stops of the same type are combined into Routes with a specific number. If the route is circular (its first and last stop coincide), you should enable the respective option when creating it. If the route is not circular, you should create separate routes that will have the same number but a different description, to monitor its direct and return directions. If units can go to the depot/garage from the middle of the route, such short route versions should also be created as separate routes with the same number but a different description.
In the route properties, you should create Schedules, i.e., specify the visit time for each stop. You can also assign a Unit to the schedule that will perform a ride at this time.
Operation patterns, which are essentially calendars indicating work days, can be applied to schedules if these schedules are used not every day, but, for example, only on weekends, or all week except Monday, or only in summer, and so on.
Creating Blocks is not an obligatory step, but it can simplify the work with the application in the future. A block is a driver's plan for their work shift, and it consists of schedules that they must complete on routes with a certain number. Units can be assigned not to separate schedules, but to blocks, i.e., to a set of several schedules. An example of creating blocks will be discussed in the last section of the article.
At this point, the configuration stage is almost completed. It only remains to mention that NimBus uses Units that are created in the Wialon interface.
During operation, the dispatcher will track Rides on the same-name tab, which displays current and planned departures of units on routes according to the schedule. The displaying of rides can be grouped by route, unit, or block. With the help of notation keys, this tab displays issues with rides that the dispatcher must respond to. Arising issues are usually resolved by canceling the ride or changing the unit assigned to the ride, which will be covered in more detail in the next section of this article.
There are several ways to control units in real time in NimBus:
To analyze historical data, it is convenient to use Reports of different types.
Unauthorized users (for example, passengers) can use Locator, which shows routes and units performing rides.
On the diagram, several arrows go from Units to other elements, which means that units can be assigned by different methods. In this section, we'll consider all possible assignment options.
But first, it should be noted that the complete list of units available to the user is displayed on the Units tab in the route properties, and if necessary, they can be associated with the route by marking the units in the list and clicking Save.
This option is used for schedules with a fixed time, i.e., if it's known in advance when and which unit should go on the route every day.
For each of these schedules, you can select an Assigned unit from the drop-down menu. At first, this menu displays a list of units associated with the route, but after clicking on the chain icon in the menu, all units available to the user will be visible.
This option is used when the ride is performed by the first unit that went on it.
If you enable the Assign units automatically option on the Units tab in the route properties, NimBus will track all units associated with the route and will assign to the ride the unit that visits the first stop before the others.
If a unit does not go to the ride according to a fixed schedule, the dispatcher can change it manually in the drop-down menu on the Rides tab.
Also, manual assignment can be used if it's not known in advance which unit will perform the ride on a certain day. In this case, you do not need to assign units to schedules, and all the work will be done only through the Rides tab.
Since a ride is a departure of a unit according to a schedule, and a block is a set of schedules, the unit can be assigned manually to the entire block at a time.
Usually block is the most complicated term for new NimBus users to understand, since most people are passengers and have never looked at the operation of fleets, tram depots, etc. as drivers or dispatchers do. To understand the essence of blocks, let's consider the following example, and you'll see how you can put in order multiple schedules of the same route using blocks.
Suppose there is 1 garage and 4 stops combined into route #32. For simplicity, let's assume that the distance between successive stops or between the garage and the following stop takes 10 minutes.
Route #32 has 4 versions with different descriptions:
Each route taxi must go to the route from the garage, drive the direct route and the return route 3 times, and then come back to the garage. The break between each direct route and return route pair will be 9 minutes. There will be 3 route taxis in total, the first one leaves the garage at 8:00, and the following taxis leave it within 23 minutes of each other.
As a result, we get planned rides along 4 created routes:
In my opinion, understanding even such a few elements can already be quite difficult, so let's try to add blocks.
Each block is meant for a separate route taxi. You'll need to choose schedules for it one by one, considering the breaks: start (way to the 1st stop), direct route, return route, a 9-minute break, direct route, return route, a 9-minute break, direct route, return route, end (way to the garage).
At first, a lot of schedules will be displayed on the page, but step by step, the amount of information displayed will decrease, since one schedule cannot be used in several blocks.
The number of schedules before the creation of blocks:
The creation of a block named Taxi 1:
The creation of a block named Taxi 2:
The creation of a block named Taxi 3:
After adding all the blocks, the result will look like this:
As a result, the dispatcher can see the amount of work for the current day for a particular unit, and, consequently, for a particular driver. Also, using blocks, it will be easier for the dispatcher to assign units to several rides at once.