The Internet of Things (IoT) is growing in popularity, so naturally, more and more companies want to be involved. The concept of connecting simple sensors and controllers to the internet isn’t a new one, but many companies are intrigued by the popularity and have become interested in created a machine-to-machine (M2M) product.

However, some of these companies aren’t fully aware of what creating an M2M application entails from an engineering perspective. Then they end up creating a product using the wrong technology, rendering their creation less functional or too costly down the line.

In response to these issues, we’ve outlined five things that you and your engineering team need to know before you begin building your M2M application. Following these steps will ensure that you avoid many common pitfalls and frustrations.

5 Things Your Engineering Team Needs To Know Before Building An M2M Application

1. Don’t overpromise battery life.

No company wants to be known for overpromising and under-delivering. However, this can happen when you’re building an M2M application, if you’re not careful. Let’s look at some cautionary hypothetical situations.

Let’s say a startup company has the ambitious idea for a smart doorknob that opens with a smartphone app. Before they create this product, they need to understand that the battery will be on the job all of the time. If their plan is to power the doorknob via cellular or Bluetooth, they need to take into account all of the processes that the battery must run.

Eventually—maybe sooner than later—the battery will die and need to be recharged, which is a hassle for the user. Additionally, the battery’s capacity will decrease over time due to the constant cycle of charging and discharging. This process, known as de-rating, forces the user to eventually purchase a new battery, and needs to be accounted for when planning for power budgets.

Or, perhaps a dog-lover decides he’s tired of losing Fido, and sets out to create a GPS-driven dog tracking device that uses a cellular network. He’s certain that it’s a great idea and that there’s a market for the product. But before he moves forward with production, he has to ensure that the device actually stays alive long enough for the customer to track their lost canine companion. This isn’t an easy feat, because the amount of battery power (and cellular data, for that matter) it takes to run GPS mapping is quite a bit more than many engineers assume.

2. Understand the difficulty of mechanical design and creating firmware in IoT.

The time, expense, and pain of mechanical design is often overlooked in IoT. A lot of hardware and software electrical engineers focus on the components, but don’t spend a lot of time thinking of housing design. Depending on the product, the organization may think about outsourcing this task to industrial designers who create product housing that looks great and works the way it’s supposed to. It’s important to set aside the appropriate funds to mechanical design early on, so there aren’t any surprises later in the budget allocation process.

Creating firmware is no walk in the park, either. For example, take Apple’s most popular product: the iPhone. The amount of money Apple has spent to develop a small handset is in the billions. This is a pretty extreme example, but it’s important for businesses to understand how much money it may take to create their firmware. In fact, it may be downright out of reach for many small companies to create an IoT firmware product, simply because it’s too difficult to create and too expensive to outsource.

3. Realize the real cost of supply chain management in product development.

Supply chain management—which entails the sourcing, purchasing, and logistics of all of the materials that make up your product—needs to be a top priority. Even if your product is world-class, you have to ensure that every business decision you make during product development makes sense. Otherwise, you’re going be late to market and over budget.

If a company is creating a circuit board with hundreds of parts, the engineers involved in selecting the bill of materials (BOM) need to fully understand the costs for all the non-commoditized components, and the sales channel the components are coming from. If components are selected solely off of the information from the manufacturer’s data sheet, or because of what their sales reps say, you’ll be doing your product a major disservice.

4. Understand how your device will be provisioned after production.

If you are creating an M2M application that runs off of Personal Area Networks, which are traditional network connections like Wi-Fi or Bluetooth, you’ll need to address the issues of provisioning. This is incredibly important and shouldn’t be overlooked.

Take smart home thermostat systems, for example. These have become quite popular in the past few years, with products like Nest taking over the market. In order for their smart thermostat to work, it must be correctly provisioned (or configured) to work with the customer’s Wi-Fi network. The customer has to give the application access to their closed network—usually by giving the device their Wi-Fi password—which is fairly standard for these types of product. While Nest has made their user interface (UI) simple, some manufacturers haven’t figured out how to make their UI user-friendly. When it is difficult for a customer to provision the product they’ve purchased correctly, it lowers customer satisfaction.

5. Add up your costs.

Most M2M applications require some type of network connection, usually to an internet based server which runs the application software. Companies often rely on cellular, thinking the only expense they will have is paying for their data every month. But this isn’t the case.

Let’s imagine that an organization is creating a smart parking meter system. The city they're implementing the parking meters in has space for 10,000 meters, so they figure that the cost of cellular—the network option they've chosen to run their smart parking meters from—will be worth the opportunity cost their meters could bring in the long-term. But, once they start running the numbers, they realize that they haven't taken into account some of the other expenses associated with creating an M2M product.

For GSM based systems, one of these costs is the PTCRB (PCS Type Certification Review Board) certification. This process was established to help the creators of M2M applications running off of cellular networks receive a third-party certification, ensuring that the device being analyzed meets certain criteria. This certification is then given to the cellular network carrier (like AT&T or Verizon) to prove that the M2M application running off their network is secure. This process is both time consuming (it can take months to be certified) and costly (running upwards of $200,000). Some production teams will choose to pre-certify modules to skip this costly step. But even if they choose this route, they will still have to cough up roughly $30,000 for carrier certification.

In Summary

As you can tell, there are more costs, efforts, and difficulties associated with developing an M2M application than meets the eye. The best thing you can do to avoid this frustration is to plan for these issues before you begin the design and production processes. It’ll save you a lot of time and effort down the line, and it will ensure that you don’t have to reconfigure your system to run on a different technology.

new industrial whitepaper-1

Jennifer Halstead

Written by Jennifer Halstead

Jennifer Halstead, MBA, CPA brings more than 20 years financial industry experience to Link Labs. She began her career in finance within the pharmaceutical industry and has continued in both public accounting and private companies. She passed the CPA exam with the 3rd highest score in the state and completed her MBA with an accounting concentration (summa cum laude). Jennifer has worked with several software companies and has led multiple venture financing, merger and acquisitions deals. She has helped companies expand internationally and has managed the finance department of a startup to 33 consecutive quarters of growth prior to acquisition. After the acquisition, she served as the Controller of Dell Software Group’s Data Protection Division where she managed a portfolio of multiple hardware and software products to scale and achieve over triple-digit growth worldwide in 18 months. Jennifer brings a depth of finance experience to the Link Labs team.

Related Blogs

Asset Tracking, BLE Asset Management logistics

How To Integrate Trailer Tracking Into Telematics

Asset Tracking, BLE Asset Management

The 3 P's of IoT Innovation

Subscribe to Link Labs' blog weekly update!

Subscribe

Subscribe to Link Labs' blog weekly update!