Fleetrun
Hecterra
NimBus
Other apps
Wialon for Android/iOS
Logistics
Wialon Local
Wialon Hosting
Distance Tag
WiaTag
Configurator
Contents
By date
NimBus Conceptual Diagram
  • technical_consulting

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

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.

Before you start using NimBus, you must have Depot activated for the client's account. It is a global container that includes various NimBus elements. Activation is carried out through an account with dealer rights, which is located one level above the client's account in the hierarchy. For simplicity, Depot is not shown in the diagram.

Stages of work

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.

Explanation of diagram elements

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.

You can speed up the creation of stops, routes, schedules, and operation patterns by importing them from a GTFS file.

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.

In this article, when mentioning drivers, we are talking about people who drive public transport. The Drivers module, with which we work in Wialon, is not used in NimBus.

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:

  • Through the Online tab, where all stops of the routes and the location of units on them are displayed.
  • Through the Dashboard tab, where the entire Depot statistics are collected.
  • Through Notifications, namely through online notifications for the dispatcher and server notifications.

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.

Assigning units to the ride

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.

Preliminary manual assignment to the schedule

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.

Automatic assignment to the ride when visiting a stop

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.

This assignment method is the only option to work with relative schedules, which do not indicate the exact time of visiting stops, but the time from the first to each of the following stops.

Manual assignment to the ride

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.

Manual unit assignment on the Rides page takes priority, even if the automatic assignment for the route is enabled and there are assigned units in the ride schedules.

Using blocks

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:

  • start of the route — the garage, the 2nd stop and then the 1st one.
  • direct route — the 1st stop, the 2nd, the 3rd and then the 4th one.
  • return route — the 4th stop, the 3rd, the 2nd and then the 1st one.
  • end of the route — the 1st stop, the 2nd and then the garage.

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).

 Example of sequential addition of blocks

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.

Oleg Zharkovsky,Wialon Trainer

10
  • 10
  • 25
  • 30
Thank you for your feedback!
Report a mistake
Text with the mistake Comment
Maximum 500 characters