Understanding the requirements

24th January 2024

It’s a common occurrence – we receive a request for pricing to measure a parameter or series of parameters on telemetry. But to do our job properly and give you the best service we need more information, and that’s why we will always go back to you requesting more information, ideally via a call or video conference. For us to make the right recommendation we need a set of key information allowing us to design the right solution, but also ensuring you are aware of what we can and cannot do. Failure to do this step properly will result in misunderstanding, bad assumptions and a solution that will not do what you want it to. So, what is the key information we want to confirm with you from the outset.

What do you want to measure?

Confirmation of parameters. Even if not fully known at the time of request it is better to consider them at this point. It will usually be far more expensive to add something retrospectively, rather than plan it into a solution from the start. It is always easier to take away things.

Frequency. How often do you want to measure, and how quickly do you want the data available on your desktop. Seems simple, but a high frequency will likely change the design of the power requirements. We want to marry power solutions to what you need and not under (or over) solution.

Where does the data need to go? There may be a requirement to send data to a specific location or person or system.

How critical is the data?

What is the impact to you of not having the data when you need it. Not having the data can have different consequences depending on the use-case and it is critical we understand that.  Why? – because we can then design a solution that fits with the criticality. For example – building in redundancy, using different sensor types and accuracy ranges, amending the frequency of recordings to name a few.

Criticality will determine support requirements. What solution needs to be designed for support in terms of management and maintenance. If something goes wrong what are the expectations to recovery?

Where will the system be deployed?

Access. Where is the site and how do you get to it? Further to the site where is the actual location for the monitoring. For installation we need access so need to confirm the logistics of getting there. Do we need to consider health and safety requirements like working at height or enclosed space. We also need to consider getting the equipment there. Sending equipment with batteries is increasingly more difficult and time consuming so there may be better options.

Security. Does the site have a vandalism risk. Do we need to consider below ground installation? Are there animals in the area (e.g. farming) that we need to design protection from.

Power. What power is available at the installation location. We need to then design how we connect to it, or if none how we power with solar and batteries. If solar, is there anything that may obstruct the efficiency of the panel.

Installed and planned infrastructure. We need to consider what is on site now, and what may be there in the future. For example, a new building construction may be clear now, but in 6 months new builds, infrastructure may interfere with a deployed solution. Can we plan around that in the design.

What options are there for connectivity? The system needs to be able to communicate with a network. Installation underground, basements, interference may have an impact on this and may therefore change how we establish connection to a network.

Future proofing

What’s next? Is this a permanent installation or timebound. Is it likely to be a growing network e.g. construction with multiple phases. Does the installation need to move at a later point?

The above list is not exhaustive but highlights why requirements are key. They need to be understood, realistic and documented. Requirements enable us to design a system fit for purpose, but also to the level that is required. They also form part of the test plan (see later blog). Without clear requirements we can both over and under design solutions, both scenarios generating avoidable costs which could be extensive.

We ask the questions to make sure we provide what you need to meet your requirements.

David van Walt, Grayswood January 2024