Does the System match
What was Planned.


Is the system what was planned, or worse still was it even planned? It may have been purchased, installed, configured, and even commissioned but none of these, in any combination, deem the system as planned.

Planning is clearly defined in the section on "planning the system" and will clearly indicate if this extremely vital stage was left by the wayside. If it was, then all is not lost. Many systems have been pulled from the dregs and made to work through disassembling and reassembling, sometimes with enough spares left over to make even a bigger system.

Let's just clear up a possible misunderstanding. We are not dealing here with a system that was working for years and has suddenly gone belly up. That is dealt with later. Here we are concerned with the system that has never got off the ground, it's always limped along or cannot operate in its entirety (it may well operate successfully in sections).


Was the requirement understood? :

This is a two pronged fork. Either the actual requirement itself was not understood, or there was the belief that the product would satisfy the requirement (or both of the above). These appear different but they are in essence the same. If there was a belief the product could satisfy the requirement then there was an initial misunderstanding of the requirement and/or what was required from the product. Oh, did you save time by skipping over the technical specs and instead you believed the salesman!? Unfortunately there is still no cure for this condition!

The starting point in this exercise is redefining what is required of both the system and the products. There is no easy way of saying this but you will now need to turn back to "Defining the Requirement", from the introduction to conducting the radio tests. For your convenience all links in this section open up a new window allowing you to keep an electronic finger at this page in the 'book'.


Can the system be salvaged? :

First of all, if the system is not as it was planned then this is the first step. It needs to be proved the system is capable of functioning as was intended. This means removing all the little extras that were added along the path of design to implementation. At this point we can successfully measure the spare capacity available in respect of radio channel use and I/O (remembering extra I/O uses more radio channel).

If the planning was at fault and the true requirement and the product's abilities and limitations known, we can attempt to salvage what we have of a system and attempt to resurrect it to working status.

This can take form in a few varied ways. The requirement can be changed to suit the product, or the product or system upgraded to suit the requirement (the latter possibly including the purchasing of extra modules if required).

There is one shortcut that is permitted at this time and that is jumping quickly to "Really yes to radio" and "Conducting the radio test". Ah, caught you out. You should have already gone back to this. That's ok, we're all human, and that is why these shortcuts exist. The real reason they are here is because this is probably the major reason new systems fail, borderline comms! Another shortcut (I know - I'm really kind), read "On the Edge" to determine if this is possibly the problem. If not, then it's back to some serious digging. Whenever we're personally called in to investigate a limping system the very first thing we do is conduct a full system radio path test. This usually irritates the client but his annoyance is usually quickly abated with the discovery of the faulty link.


Replanning with what's available:

Replanning the system usually means cutting down to a level the system can handle. However, there are two other avenues that may be available for consideration, splitting or combining the requirements.

Splitting the requirement into smaller bits, with each bit being handled by less units, could result in everything working more efficiently. An original scenario may be that both the data from a number of outstations is being collected on the same channel as a MODBUS link operating through intelligent interfaces i.e. only transmitting what has changed. This could be split into a system that collects all the data and the MODBUS link being accomplished on a separate radio channel through radio modems. The result of the split being a probable 4 times increase in the amount of traffic that can be relayed.

In direct contrast, a multitude of requirements be combined into one system. There may be a few water control systems all operating independently of one another but as each is trying to use the radio channel as soon as it becomes free results in a very badly congested radio channel.

Combining the systems would result in less radio traffic as each unit, now belonging to the same radio system, will have a more intelligent approach to its transmitting sequence. Maybe the addition of a SCADA system is proposed and levels can be collected in one central point and broadcast to multiple locations.

If it turns out that new, more suited products be the only answer to a very unhappy situation then, unless there has been a total change in operating frequency, usually the most expensive part of the system can be salvaged being the antennas and related hardware. This may not appear as the most expensive part of the system until all the time and labour is added to the initial cost of the hardware. Most of the installation time of a radio telemetry system is the antennas and hardware, very little being on the radio modules themselves.


| | Ask a Question |

05.02.01