When Severe Weather Dictates Hardware Design Schedules

When Severe Weather Dictates Hardware Design Schedules

January 17, 2017 2:29 pm Published by

Understory produces weather data and insights. This information is collected with hardware that we design, deploy, and manage. And when severe weather dictates hardware design schedules, it gets complicated.

Understory’s hardware detects what happens during severe weather. One of the unique features of our hardware is that it detects hail. As it turns out, hail is difficult to reproduce in a lab which means the only way to verify our design is to have our weather stations in the path of an actual storm. In order to get all the weather data to our customers, including hail detection, we must be ready before the next storm season. This must include the time to manufacture the hardware and install the weather stations throughout the cities that are of interest to insurance companies.

A guest blog from Kenny Koller, Understory Lead Embedded Engineer

Time dwindles when severe weather dictates hardware design schedulesA friend, who is an engineer, is fond of saying that when developing products, you have quality, features, and time. Pick two. This is not a perfect model as these items are not completely independent of one another but it is a useful way to think about the trade offs related to designing something and delivering it. If you have extra time (you won’t), you can spend it developing new features or improving the quality of what has already been developed.

How can we use our simplified product development model to meet this goal if the time to do so is fixed? One knob we can turn is quality. It would be unpopular to suggest that every feature ever dreamed of is added and let quality fall where it will. It is equally unpopular to think that hardware can be designed to an arbitrarily high level of quality. This is where engineers begin asking for specifications such as ‘how exactly must we measure the size of hail?’ and ‘what is the minimum spacing of the weather stations?’. To answer these questions, it requires a good understanding of what customers need and sometimes–as can be the case with new technology–what is anticipated that our customers will need. The former requires effective relationships with the customer. The latter requires imagination and creativity.

Another way to increase our likelihood of success is to only build what is absolutely necessary. Although this appears to be simple, there is almost always differences in opinion. This is where quality, features, and time Quality needs to be spot on when severe weather dictates hardware schedulescan be used as a tool to check ourselves. We all want to succeed in providing data to our customers but the business pressure must be kept in check with our ability to deliver quality hardware and software.

I mentioned that hail is not readily created in a laboratory. This leads to one of the easier tasks in product development at Understory: Inspiring engineers to emulate the impact of hail (which distills down to asking adults to smash things together). Some of the techniques are more effective than others but nearly all of them are fun. While we still need severe weather and storms to verify our technology we have learned plenty from these experiments.

Testing is another area that consumes time. We must verify that our hardware actually works. Eliminating unnecessary features and creating well-defined specifications can help reduce the time required to verify a design.

Although I left it out of our development model let’s consider cost and its ramifications. To make our ground truth technology work we must build many stations. To make ground truth work as a business we must keep our cost per station low. This can be accomplished by simplifying the hardware, making things easier to manufacture, and streamlining the deployment. But these are things easier said than done. What I have learned is that there is a limit to what can be worked out on paper. Once this point has been reached it is time to build something and learn from it. This must be done even if it costs more than can be sustained by the long term business model. This is usually accomplished by building prototypes whose quality and features can be sacrificed to meet a deadline imposed by a storm season.

Other articles you might like:

What Data Powers Your Weather App?

How do you measure hail, wind speed and rain?

Why isn’t the forecast for weather accurate?